第10章信息系统开发

第10章信息系统开发10.1信息系统规划10.2系统复杂性与需求的重要性10.3软件开发模型10.4敏捷开发方法10.5系统分析与设计（结构化方法）10.6系统分析与设计（面向对象方法）2第10章信息系统开发3掌握软件开发模型掌握敏捷开发方法了解信息系统规划了解系统分析与设计的结构化方法了解系统分析与设计的面向对象方法学习目标3案例广东移动管理信息系统云计算体系研究10.1信息系统规划信息系统规划是一个识别支持企业战略和目标的信息系统的过程。常见的信息系统规划诺兰阶段模型法信息工程法价值链分析法企业系统规划法关键成功要素法信息系统建设的六个阶段（诺兰模型）单系统独立建设阶段

引入数据处理系统，不关注系统的经济效益，用户对信息系统抱着敬而远之的态度。

系统规模建设阶段

信息技术应用开始扩散，管理者开始关注系统投资的经济效益，但还不存在实质的控制。系统规划发展阶段

对管理信息系统的管控走向正规，启动了系统建设规划和项目管理计划。系统尝试整合阶段

从管理计算机转向管理信息资源，开始使用数据库和远程通信技术，努力整合现有的信息系统。系统综合支撑阶段

系统从支持单项应用发展到支持综合应用，组织开始评估信息系统建设的成本和效益。全面信息化阶段

正式的信息资源计划和控制系统投入使用，信息资源管理的效用充分体现出来。10.1信息系统规划——诺兰诺兰模型是第一个描述信息系统发展阶段的抽象化模型诺兰模型的假设：企业只有不断学习才能推动阶段间的转移10.1信息系统规划——BSP企业系统规划（BusinessSystemPlanning，BSP）法是对企业管理信息系统进行规划和设计的结构化方法BSP法主要基于利用信息技术和信息系统支持企业运营的思想，是把企业目标转化为信息系统战略的全过程BSP方法所支持的目标是企业各层次的目标，实现这种支持需要许多子系统。10.1信息系统规划——CSF关键成功因素法（CriticalSuccessFactors，CSF）可用来帮助进行信息系统规划和需求分析。关键成功因素总是与那些能确保企业具有竞争能力的方面相关的。在不同类型的业务活动中，关键成功因素会有很大的不同，即使在同一类型的业务活动中，在不同时间内，其关键成功因素也会不同。如产品性价比、用户体验、品牌理念……10.1信息系统规划——比较主要优点在于它对信息系统问题提出了一个全面的观点；而且能够明确显示信息系统功能在哪方面影响企业由于该模型的范围仅限于企业内的信息系统功能，成长阶段方法基本上是一个效率导向型方法成长阶段法使信息技术人员与其他人员一起考查企业工作的过程；而且能帮助企业对数据类有一个清晰的了解没有指明哪个信息系统应用最为重要，因此，其分析结果必须在能够定出信息系统应用优先次序的更大架构内解释企业系统规划法目的是要确定企业成功最重要的因素，并确保企业获得信息系统应用的支援。因此其重点放在商业环境下取得成功的关键因素上此方法注重企业的竞争性和有效性关键成功因素法10.2系统复杂性与需求的重要性系统需求环节中的主要问题（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；（2）忽略需求环节，再精心设计的软件也可能很难匹配用户的需求，导致要么被拒绝，要么花费昂贵的代价重建。（3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。10.2系统复杂性与需求的重要性（续）图10-1需求变更对系统开发成本的影响越早开始写代码，花费的时间越长！10.3软件开发模型软件开发模型(SoftwareDevelopmentModel)是指软件开发全部过程、活动和任务的结构框架。软件开发过程包括需求分析、设计、编码和测试等阶段，有时也包括维护阶段。典型开发模型生命周期模型（Lifecyclemodel）原型模型（Prototypemodel）螺旋模型（Spiralmodel）敏捷模型（Agilemodel）10.3软件开发模型（续）10.3.1生命周期模型（瀑布模型）图10-2生命周期模型确定系统、设定范畴、指定计划需求分析，避免后续阶段出现需求变更构建未来系统的技术蓝图技术框架、数据库和程序单元测试（通常由开发人员完成）、功能测试、系统集成测试以及用户接受测试保障系统持续满足业务需求，并进行必要的修补10.3软件开发模型（续）10.3.1生命周期模型——局限性该模型假设用户能够在项目开始阶段就明确自己的需求，并且能够清楚地表达给开发人员缺乏灵活性，是个线性的过程，不便于通过必要的迭代或并发活动澄清本来不够明确的需求要求阶段之间产生大量详尽的文档，作为后续开发工作的依据。需求，设计阶段的问题10.3软件开发模型（续）10.3.2快速原型模型原型的必要性在于：用户需要借助具体的设计来描述需求；用户缺乏想象设计效果的能力；用户没有能力对技术设计文档作评论；几乎不可能为用户界面提供一种完全、一致、可用的描述；有利于尽早开始进行有用户参与的连续性测试。10.3软件开发模型（续）10.3.2快速原型模型（续）图10-3快速原型模型举例：纪检监察部网站改版10.3软件开发模型（续）10.3.3螺旋模型螺旋模型将生命周期模型和快速原型模型结合起来，强调其他模型所忽略的风险分析，比快速原型模型更加适合于大型复杂系统螺旋模型沿着螺线进行若干次迭代：制定计划明确该阶段的目标从风险角度分析备选方案实施开发客户评价开发结果，提出建议10.3软件开发模型（续）10.3.3螺旋模型（续）图10-4螺旋模型10.3软件开发模型（续）10.3.3螺旋模型——局限性说服大客户接受这样的演进式系统开发可能比较困难，合同管理和项目控制都比较难螺旋模型强调风险分析，因此对软件开发人员要求较高，他们必须擅长识别和评估风险10.3软件开发模型（续）10.3.4敏捷模型敏捷模型是应对快速变化和不确定性需求的一种

软件开发论。敏捷开发方法Scrum极限编程（ExtremeProgramming,常缩写为XP）敏捷统一过程（AgileUnifiedProcess,常缩写为AUP）10.3软件开发模型（续）10.3.4敏捷模型（续）图10-5理想的XP生命周期10.4敏捷开发方法—以Scrum为例Scrum，暂译为“密集冲刺”，这是种轻量级敏捷项目管理方法，特别适合在需求多变不确定的情况下，以快速迭代和增量式开发软件系统和产品。三个基本原则是高可视度、频繁检查和适应高可视度（Visibility）指确保中间环节的可观察性；频繁检查（Inspection）提供了及时评估中间成果和发现问题的可能；适应（Adaptation）就是调整，对不符合标准的过程和操作进行修改和完善。Scrum敏捷项目管理目录敏捷的背景与动机敏捷宣言及原则敏捷方法的实践Scrum的角色Scrum流程和工作产品26Scrum是英语中橄榄球运动的一个专业术语，表示“争球”，有时也翻译成“密集冲刺”。软件项目的复杂性横轴代表需求的复杂度纵轴表示技术的复杂度还有人力资源的复杂度27敏捷开发模型举例——互联网时代的出版模式作者最开始的时候并没有想出一本书，而只是把多年的积累梳理出来写成了博客，凭借博客的成功最后得到了出版商和纸版读者的认可。在写成本书的过程中，作者是渐进式的进行的，每写完一个章节，放到博客上去征求读者的反馈，很多反馈意见在后面的章节或修订中及时地体现出来，这样就形成了与读者之间的良好反馈，在出版之前就锁定了大量的读者。这就是敏捷开发提倡的“增量迭代、及时交付”的思想。这种模式能最大程度地不偏离客户需求的本质。目录敏捷的背景与动机敏捷宣言及原则敏捷方法的实践Scrum的角色Scrum流程和工作产品29敏捷价值观之敏捷宣言30敏捷开发的核心思想是：以人为本，适应变化。敏捷价值观之敏捷宣言-1个体和交互胜过过程和工具人是软件项目获得成功最为重要的因素合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；31敏捷价值观之敏捷宣言-2可以工作的软件胜过面面俱到的文档过多的面面俱到的文档往往比过少的文档更糟软件开发的主要和中心活动是创建可以工作的软件直到迫切需要并且意义重大时，才进行文档编制编制的内部文档应尽量短小并且主题突出32敏捷价值观之敏捷宣言-3客户合作胜过合同谈判客户不可能做到一次性地将他们的需求完整清晰地表述在合同中为开发团队和客户的协同工作方式提供指导的合同才是最好的合同33敏捷价值观之敏捷宣言-4响应变化胜过循环计划变化是软件开发中存在的现实计划必须有足够的灵活性与可塑性短期的迭代的计划比中长期计划更有效JiangsuMicrosoftTechnologyCenter34敏捷开发的12个原则我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。围绕被激励起来的个人来构建项目。在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

敏捷开发的12个原则工作的软件是首要的进度度量标准。敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。简单化是根本（不做过度设计和预测）。最好的构架、需求和设计出自于自组织的团队。每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。目录敏捷的背景与动机敏捷宣言及原则敏捷方法的实践

Scrum的角色Scrum流程和工作产品37敏捷关键实践1——增量迭代每个迭代有一个大约为1～4周的时间框，在SCRUM里称为一次冲刺（超过1个月的详细计划往往偏差很大）每次迭代都应该有明确的目标每次迭代都应该有明确的可演示的工作成果迭代过程中项目团队应该尽量免受打扰迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解38敏捷关键实践2——面对面交流虽然如今通讯工具花样繁多，但面对面交流在某些场合下仍然是不可替代的；敏捷开发把交流缺失问题考虑在内，要求团队成员彼此直接协作，尽量创造面对面交流的机会；尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的。匿名共享需求文档只会打开曲解和误解之门，更不用说书面信息比口头交流还要慢很多。39敏捷方法的其它实践结对编程每日站立短会用户故事团队工作室频繁发布自组织团队重构40目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践Scrum的角色Scrum流程和工作产品41Scrum框架42www.海颐软件Scrum角色Scrum角色之ProductOwner产品负责人（ProductOwner）的职责如下：确定产品的功能。决定发布的日期和发布内容。为产品的profitabilityoftheproduct(ROI)负责。根据市场价值确定功能优先级。每个Sprint（即迭代周期），根据需要调整功能和优先级（每个Sprint开始前调整）。接受或拒绝接受开发团队的工作成果。44Scrum角色之ScrumMaster作为TeamLeader和Productowner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:保证团队资源完全可被利用并且全部是高产出的。保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口，屏蔽外界对团队成员的干扰。保证开发过程按计划进行，组织DailyScrum,SprintReviewandSprintPlanningmeetings。45Scrum角色之ScrumTeam一般情况人数在5-9个左右团队要跨职能（包括开发人员、测试人员、用户界面设计师等）团队成员需要全职。（有些情况例外，比如数据库管理员）在项目向导范围内有权利做任何事情已确保达到Sprint的目标。高度的自我组织能力。向ProductOwner演示产品功能。团队成员构成在sprint内不允许变化。46目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践Scrum的角色Scrum流程和工作产品4710.4敏捷开发方法—以Scrum为例10.4.2Scrum的过程框架图10-6Scrum过程框架Sprints(冲刺)Scrum的项目过程由一系列的Sprint组成。Sprint的长度一般控制在2-4周。通过固定的周期保持良好的节奏。产品的设计、开发、测试都在Sprint期间完成。Sprint结束时交付可以工作的软件。在Sprint过程中不允许发生变更。49Scrum框架50Scrum仪式之Sprint计划会议计划会议要有足够的时间取出部分产品需求做成sprint需求，并写成索引卡确定并细分每一个索引卡的故事（Story）进行工作认领（不是分配）确定每日站立会议的时间和地点确定好评审会议和回顾会议的日期Scrum仪式之Sprint计划会议JiangsuMicrosoftTechnologyCenter52Scrum仪式之每日Scrum会议(DailyScrum)每日Scrum会议，即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立进行。最好是每天早晨开，一般15分钟左右，时间比较短，也有利于团队成员安排好当天的工作。只有团队成员可以在例会上发言，其他人员有兴趣可以参加，但只能旁听，不能发言。每日Scrum会议由ScrumMaster主持，Scrum团队所有成员轮流回答以下3个问题：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困难？JiangsuMicrosoftTechnologyCenter53场景展示-每日站立会议Scrum任务板(TaskBoard)JiangsuMicrosoftTechnologyCenter56任务板（墙）展现了在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。通常的任务板是下面这个样子:场景展示-任务看板Scrum仪式之Sprint评审会议Sprint评审会用来演示在这个Sprint中开发的产品功能给ProductOwner.ProductOwner会组织这阶段的会议并且邀请相关的干系人参加。团队展示Sprint中完成的功能一般是通过现场演示的方式展现功能和架构不要太正式团队成员都要参加可以邀请所有人参加JiangsuMicrosoftTechnologyCenter59Scrum仪式之Sprint回顾会议JiangsuMicrosoftTechnologyCenter60团队的定期自我检视，发现什么是好的，什么是不好的。一般控制在15-30分钟每个Sprint都要做全体参加ScrumMaster产品负责人团队可能的客户或其它干系人Sprint回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。Scrum框架61Scrum物件之产品订单(ProductBacklog)一个需求的列表。一般情况使用用户故事来表示backlog条目理想情况每个需求项都对产品的客户或用户有价值Backlog条目按照商业价值排列优先级优先级由产品负责人来排列在每个Sprint结束的时候要更新优先级的排列JiangsuMicrosoftTechnologyCenter62Scrum物件之产品订单(ProductBacklog)JiangsuMicrosoftTechnologyCenter63Imp：重要性；Est：大致相当于一个“理想的人天（man-day）”Scrum物件之冲刺订单(SprintBacklog)管理Sprint的backlog:团队成员自己挑选任务，而不是指派任务对每一个任务，每天要更新剩余的工作量估算每个团队成员都可以修改Sprintbacklog，增加、删除或者修改任务JiangsuMicrosoftTechnologyCenter64Scrum物件之燃尽图(BurnDownChart)656667推荐书籍：《人月神话》第1章焦油坑第2章人月神话第3章外科手术队伍第4章贵族专制、民主政治和系统设计第5章画蛇添足第6章贯彻执行第7章为什么巴比伦塔会失败第8章胸有成竹第9章削足适履第10章提纲挈领第11章未雨绸缪第12章干将莫邪第13章整体部分第14章祸起萧墙第15章另外一面第16章没有银弹……1、人月神话：向一个已经延后的项目中投入更多的人力资源只会让它更延后2、没有银弹：没有一种策略，技术或者技巧可以极大地提高程序员的生产力10.5系统分析与设计—结构化方