软件项目管理期末复习--项目过程模型

软件项目管理 项目过程模型

分析项目特征

分析项目是目标驱动的还是产品驱动的

分析项目其他特征

• 面向数据(data-oriented),如IS,还是面向过程控制(process-oriented),如ES

• 通用工具，如EXCEL，还是专用工具，航空公司座位预定系统

• 是否涉及需要专用工具支持的专门技术

• 如并发处理

• 基于知识的系统,如专家系统

• 是否有特殊的安全性要求

• 如系统故障危及人身安全的

• 系统所需软硬件环境特性是什么

对下列系统进行分类

1. 工资支付系统（面向数据或特定领域的应用系统）

2. 灌装企业的控制系统（包含嵌入式软件的过程控制或者工业系统）

3. 供水企业管理对企业供水计划的系统（使用图形的信息系统）

4. 支持项目管理的软件（通用信息系统软件包）

5. 供律师查询法律条文的系统 （信息手机的通用软件包）

识别高层的项目风险

• 产品不确定性：系统需求理解的准确性，用户在开始时有可能对系统应该什么样都无法确定。在某些环境中，精确而有效的需求描述可能迅速变得过时
• 过程不确定：在项目开始时需要选择方法或过程模型，或者一种新的工具，任何对原先采用的开发方法的变化都将引入不确定性
• 资源不确定性：项目进行中资源的数量可能发生变化

识别学院工资系统中的风险

• 金融和职员之间的矛盾

• 职员对系统不接受

• 缺少运行该系统的经验

• 缺少管理系统的计算机专业人员

• 需求变化

软件生存期模型特征

• 描述了开发的主要阶段
• 定义每一个阶段要完成的主要过程和活动
• 确定每一个阶段的输入和输出

瀑布模型

• 所有过程模型的祖宗
• 项目从开始到结束按照一定的顺序执行
• 瀑布模型是文档驱动的，各个阶段不交叉

瀑布模型适应于什么场合？有什么优缺点？

需求：很明确固定

方案：工作流程 线性

类似项目：短期项目等

瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如结构化技术）严格的规定了每个阶段必须提交的文档，要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证，瀑布模型的成功在很大程度上是由于他基本是一种文档驱动的模型

但文档驱动也成为他的一个主要缺点

实际项目很少按照该模型给出的顺序进行的

用户很难清楚地给出所有需求

用户必须有耐心等到系统开发完成

开发者常常被不必要的耽搁

V模型

需求很明确

方案很明确

类似项目：系统性能安全等有严格要求等

在( )生存期模型中,要求项目所有的活动都严格按照顺序执行,一个阶段的输出是下一个阶段的输入。

A.瀑布模型

B.原型

C.螺旋模型

D. V模型

论述瀑布模型软件开发方法的基本过程

瀑布模型规定了各项软件工程活动

包括制定软件项目计划

进行需求分析和定义

软件设计

程序编码

测试及运行维护，并且规定了他们自上而下，相互衔接的固定次序。如同瀑布流水，逐级下落。然后软件开发的实践表明：上述各项活动之间并非完全是自上而下，呈线性图示。实际情况是，每项开发活动均应具有以下特征

演化模型

• 开发过程中，软件产品需求不断变化
• 交付时间严格，必须交付功能有限版本，以应对竞争
• 理解的核心产品的需求，但其他扩展功能细节没有定义
• 软件工程师需要一种过程模型应对以上变化

演化模型是迭代开发模型，每次迭代是软件不断发展

如下常用的两种演化模型

• 原型开发模型
• 螺旋模型

原型

• 用户定义了一组一般性目标，但不能标识处详细的输出、处理及输出需求
• 开发者可能不能确定算法的有效性，操作系统的适应性或人机交互的形式
• 对需求不是很明朗

原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工

开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情）因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性

软件产品但交付给用户使用之后，维护便开始了，根据所需完成的维护工作种类的不同，可能需要返回到需求分析，规格说明，设计或编码等不同阶段

存在的问题

用户看似乎看到的是软件的工作版本，其实原型只是用口香糖和打包绳拼凑起来的，为了使原型很快能够工作没有考虑软件的总体质量和长期的可靠性。当被告知该产品必须重建，才能使其达到高质量时，用户叫苦连天，会要求做一些修改，是原型成为最终的工作产品。如此，软件开发管理尝尝就放松了。

原型法

原型是项目系统中的一个方面或者多个方面的工作模型

• 抛弃型原型：用于实验某些概念，试验完系统将无用处
• 进化型原型：原型系统不断地被开发和被修正，最终他变为一个真正的系统

原型法的好处

• 从实践中学习
• 改善通信
• 改善用户参与
• 使部分已知的需求清晰化
• 验证描述的一致性和完整性
• 可能可以减少文档
• 减少了维护成本
• 特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误）
• 试验是否能产生期待的结果

原型法的缺点

• 用户有时误解了原型的角色，例如他们可能误解原型应该和真实系统一样可靠
• 缺少项目标准，进化原型法有点像编码修正
• 缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制
• 额外的花费：研究结果表明构造一个圆形可能需要10%额外花费
• 运行效率可能会受影响
• 原型法要求开发者与用户密切接触，有时这是不可能的，例如外包软件

在需求不清楚的软件项目中，原型开发模型常用来确认需求

从另外的角度看待原型

• 学生经常会做一些软件作业，这些作业被称为原型
• 但是作为一个原型必须描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容
• 在不同的阶段，原型具有不同的作用

原型起到作用的程度

• 实物模型
• 仿真交互
• 部分模型：水平、垂直（某些特性构造详细的原型）

那些需要进行原型？

• 人机界面
• 系统的功能

联系：何时引入原型系统

• 保险公司的经理需要通过个人计算机上的一个系统来访问管理信息，该系统价格必须合适，很多人怀疑是否经理真需要使用该系统
• 可行性研究阶段，采用实物模型的方法
• 支持客户销售人员通过电话回到有关客户询问汽车保险价格的系统
  • 设计用户对话界面时
• 保险公司考虑实施一个基于MS Access的电话销售系统，他们不知道是Access是否能够开发出相应界面的系统并具备足够快递相应时间

需求分析–》原型开发—》原型评价—》最终系统设计—》最终系统实现

使用原型模型的项目特征

需求明确

希望减少项目需求的不确定性

• 在开发时间紧迫，需要给用户提供一个功能有限的版本
• 在后续版本中，进行扩充和细化
• 可以选用增量模型

软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。例如

• 产品交付给用户后用户可能不满意
• 到了预定的交付日期软件可能还未开发出来
• 实际的开发成本可能超出预算
• 产品完成前一些关键的开发人员跳槽了
• 产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件等

螺旋模型的基本思想

• 使用原型及其他方法来尽量降低风险
• 结合原型的迭代和瀑布的系统 和可控性特点

可以看做是在每个阶段之前都增加了风险分析过程的快速原型模型

以风险为导向的声明期模型

从一个小反问的关键中心地带开始寻找风险因素，制定风险控制计划，并交付给下一个步骤，如此迭代。每次迭代讲项目扩展到一个更大的范围

螺旋模型优缺点

优势：随着迭代的增加，风险程度随之降低

缺陷：比较复杂，需要责任心，专注和管理方面的知识

v瀑布模型、V模型和快速原型生存期模型，说明这些模型适用于什么情况下的项目

增量模型

先完成一个系统子集的开发，再按同样的开发步骤增加功能（系统子集），如此递增下去直至满足全部系统需求

系统的总体设计在初始子集设计阶段就应做出设想

增量式fu持续地在确定的阶段向用户展示软件

和渐近原型不同，在增量式交付的时候，你明确知道下一步要完成什么工作，增量交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断的交付阶段性成果。

增量式交付

软件概念–》需求分析–》架构设计》增量式阶段1：详细设计、编码、测试

增量式阶段2：详细设计，编码，测试

增量式模型的优点

• 在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品，从第一个构件交付之日起，用户就能做一些有用的工作。
• 整个软件产品被分解成许多个增量构建，开发人员可一个构件一个构件地逐步开发
• 逐步增加产品功能可以使用户有较充裕的实践学习和适应新产品，从而减少一个全新的软件可能带给客户组织的冲击
• 采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计及短多付出的劳动将在维护阶段获得回报
• 再把每个新的增量构建集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计的便于按这种方式进行扩充。向现有产品加入新构件地过程必须简单、方便。也就是说，软件体系结构必须是开放的。
• 开发人员既要把软件系统看做整体，又要看成可独立的构件，相互矛盾
• 多个构件并行开发，具有无法集成的风险

需求：基本明确，可能发生变化

市场、用户：对于市场和用户把握需要逐步了解

系统改造：需要一步一步实施

举例

• 采用增量模型开发文件处理软件
• 在第一个增量版本中提供基本功能：文件管理、编辑和文档生成
• 在第二个增量拌拌中，提供复杂的编辑和文档生成功能
• 在第三个增加版本中提供拼写和语法检查功能
• 在第四个增量版本中提供高级页面排版功能
• 在每个增量中，还可以使用原型模型，解决需求不明朗问题

没有足够开发人员

可以使用少量人员开发第一个增量，如果第一个增量（核心产品）用户反应不错，可以增加人员继续后续增量的开发，每开发一个增量，形成一个新的版本

利用增量开发规避技术风险

项目中需要一个新硬件设备，但该设备开发完成日期不确定，可以再早期增量开发中避免使用该硬件，可以保证部分功能提交给用户使用，不至于过分延期

可以构建一部分系统的模型,通过用户试用提出优缺点,最好选择( )生存期模型。

A.增量式模型

B.原型

C.螺旋模型

D. V模型

渐进式迭代模型

• 渐进式前进
• 阶段式提交

软件概念–》需求开发–》架构设计–》阶段一：细节设计，构件与发型 阶段二：细节设计、构件与发行 阶段n：细节设计，构建与发行

• 阶段式提交一个可运行的产品
• 关键的功能更早出现
• 早期预警的问题，避免缺陷蔓延
• 阶段性完成可以降低估计失误

假设你被任命为一家软件公司的项目负责人，

你的工作是管理该公司已被广泛应用的字处理软件的新版本开发。

由于市场竞争激烈，公司规定了严格的完成期限并且已对外公布。

你打算采用哪种软件生命周期模型？为什么？

对这个项目的一个重要要求是，严格按照已对外公布了的日期完成产品开发工作，因此，选择生命周期模型时，应该着重考虑哪种模型有助于加快产品开发的进度。使用增量模型开发软件时可以并行完成开发工作，因此能够加快开发进度

这个项目是开发该公司已被广泛应用的字处理软件的新版本，从上述事实至少可以得出3点结论：第一，旧版本相当于一个原型，通过收集用户对旧版本的反应，较容易确定对新版本的需求。没必要再专门建立一个原型系统来分析用户的需求。没必要在专门建立一个原型系统来分用户的需求。

第二该公司的软件工程师对字处理软件很熟悉，有开发字处理软件的丰富经验，具有采用增量模型开发新版字处理软件所需要的技术水平

第三，该软件受到广大用户的喜爱，今后很可能还要开发更新的版本，因此应该把软件的体系结构设计成开放式的。以利于今后的改进和扩充。

敏捷模型

• 敏捷组织提出得一个灵活开发方法
• 应对迅速变化需求的快速软件开发方法
• 是一种迭代的，循序渐进的开发方法

敏捷宣言

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

xp极限编程

是由knetbeck提出的一套针对业务需求和软件开发实践的规则

极限编程方法的实施原则

• 快速反馈
• 假设简单
• 包容变化

敏捷团队的特点

• 团队成员必须相互信任
• 团队成员的技能分布必须适合于要解决的问题
• 如果要保持团队的凝聚力，必须将坚持个人己见的人员排除于团队之外
• 团队时自足折叠自适应团队结构，使用constantine提出的随机、开放和同步式的范形
• 相当大的自主权

选择生存期的步骤

熟悉各种生存期模型—》评审、分析项目的特性–》选择适合项目的生存期模型-》标识生存期模型与项目不一致的地方并进行裁剪

医疗信息商务平台

小结

• 瀑布模型
• V模型
• 原型模型
• 增量模型
• 渐进式阶段模型
• 敏捷开发模型