项目生命周期模型
2021-10-17 14:19:35 3 举报AI智能生成
登录查看完整内容
项目生命周期模型是一个用于规划、执行和控制项目从开始到结束的框架。它通常包括四个阶段：启动、规划、执行和收尾。在启动阶段，项目经理确定项目的目标和范围，并组建项目团队。在规划阶段，项目经理制定详细的计划，包括时间表、预算和资源分配。在执行阶段，项目团队按照计划执行任务，并监控进度和质量。最后，在收尾阶段，项目经理评估项目的成功与否，并完成所有必要的文档和报告。这个模型可以帮助项目经理更好地管理项目，确保项目按时按质完成。
作者其他创作
大纲/内容
启动项目
组织和准备
执行项目工作
结束项目
通用项目生命周期结构中典型的成本与人力投入水平
成本与人力投入在开始时较低，在工作执行期间达到最高，并在项目快要结束时迅速回落
风险与不确定性在项目开始时最大，并在项目的整个生命周期中随着决策的制定与可交付成果的验收而逐步降低
随项目时间而变化的变量影响
通用生命周期的特征
项目生命周期的特征
瀑布模型是一个经典的软件生命周期模型
瀑布模型将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段
概念
阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的输入。
利用这一输入，实施该项活动应完成的工作内容
给出该项活动的工作成功，作为输出传给下一项开发活动
对该项活动的实施工作成果进行评审
特点
以相对来说较小的费用来开发软件
每个开发阶段的质量都有保证，减少返工
文档精细，降低了沟通成本，有利于及早发现问题
优点
无法解决软件需求不明确或不准确的问题
风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会
由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程
缺点
通常是对用户需求非常明确的项目
规模小，需求简单，功能单一的项目
需求清晰明了且时间要求宽松的软件开发项目
用户有一定的能力，对需求的表述是确切的
适用的项目类型
瀑布模型
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来
使得软件的增量版本的快速开发成为可能
在螺旋模型中，软件开发是一系列的增量发布
开发过程具有周期性重复的螺旋线状
制定计划：定软件目标，选定实施方案，弄清项目开发的限制条件；
风险分析：分析所选方案，考虑如何识别和消除风险；
实施工程：实施软件开发（需求、设计、编码、测试等按螺旋周期推进）
客户评估：评价本轮的开发结果，提出修正建议，计划下一轮的工作。
一个螺旋式周期可分为
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
减少了过多测试或测试不足
维护和开发之间并没有本质区别
风险管理成本太高，在风险分析中，对项目组成员要求高
风险驱动的，关注风险，风险分析后决策是否继续进行项目
螺旋模型强调了风险分析，特别适用于庞大而复杂的、需求不明朗，高风险的系统
螺旋模型
核心工作流从技术角度描述迭代模型的静态组成部分，包括：业务建模、需求获取、分析与设计、实现、测试、部署
在迭代的过程中，每个阶段都包括不同比例的所有活动
迭代模型
图上的迭代模型，水平方向为时间维，从组织管理的角度描述整个软件开发生命周期
分四个阶段：初始、细化、构造、移交，可以进一步描述为周期（Cycle）、阶段（Phase）、迭代（Iteration）
图中阴影部分描述了不同的工作流，在不同的时间段内工作量的不同，几乎所有的工作流在所有的时间段内具有工作量，只是大小不同而已
迭代模型介绍
初始阶段：系统地阐述项目的范围，选择可行的系统架构，计划和准备业务案例
细化阶段：细化构想，细化过程和基础设施，细化架构并选择构件
构造阶段：资源管理、控制和过程最优化，完成构件的开发并依评价标准进行测试，依构想的验收标准评估产品的发布
移交阶段：同步并使并发的构造增量集成到一致的实施基线中，与实施有关的工程活动（商业包装和生产、人员培训等），根据完整的构想和需求集的验收标准评估实施基线
阶段
适用于需求不甚明确、难度比较大的软件开发
V模型
V模型由左右两边组成，是一个对称的结构，非常明确的表明了测试过程中存在的不同的级别
并且非常清晰的描述了这些测试阶段和开发阶段的对应关系
单元测试：验证软件单元是否按照单元规格说明（详细设计说明）正确执行，集保证每个最小的单元能够正常运行，通常由开发人员来执行
集成测试：检查多个单元是否按照系统概要设计描述的方式协同工作。集成测试的主要关注点是系统能够成功编译，实现了主要的业务功能，系统各个模块之间数据能够正常通信等
系统测试：验证整个系统是否满足需求规格说明
验收测试：从用户的角度检查系统是否满足合同中定义的需求或者用户需求
四个测试阶段的区别
V模型体现的主要思想是开发和测试同等重要，左侧代表的是开发活动，而右侧代表的是测试活动
V模型针对每个开发阶段，都有一个测试级别与之相对应
测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应
V模型用于需求明确和需求变更不频繁的情形
V模型的特点
灵活性差，依赖于早期进行的需求调查，不能适应需求的变化
需求和技术都是被充分确定和理解的
原型化模型
原型化模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互
再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品
在实际的项目过程中，借助于组织过程资产以及快速模型软件，一般在需求分析的时候，就可以建立一些简单的原型
不要求一定要对系统做全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解
先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求
实际可行
具有最终系统的基本特征
构造方便、快速、造价低
原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的，系统分析、设计与实现都是随着对一个工作模型的不断修改而同时完成的，相互之间并无明显界限，也没有明确分工
系统开发计划就是一个反复修改的过程
在系统真正实现以后就放弃不用了
抛弃型原型
此类原型的构造从目标系统的一个或几个基本需求出发，通过修改和追加功能的过程逐渐丰富，演化成最终系统
用户需求不完全或不确定；
对总体的轮廓先建立一个用户需求原型，然后进行评价和反馈；
对原型进行扩充、改进和求精；完成最终系统
没有考虑软件的整体质量和长期的可维护性。
大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计
进化型原型
分类
客户能提出一般性的目标，但不能标出详细的输入、处理及输出需求；或开发者不能确定算法的有效性、操作系统的适应性、及人机交互的形式。
用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；
开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式
融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。
把软件产品作为一系列的增量构件来分析、设计、编码、测试和发布
第一阶段增量往往是核心产品
每一阶段增量均为可发布一个版本，早期的增量是最终产品的“可拆卸”版本
由于初始增量是后续增量的基础，所以如果要对初始增量的需求进行修改，可能会影响后续的增量。
增量过多会造成管理成本超支，影响进度
人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人力实现下一个阶段增量。同时人员可以并行工作。
需求明确部分可以分阶段实现，逐步优化系统需求，逐步集成系统元素
阶段交付，当配备的人员不能在设定的期限内完成产品时或者客户/市场要求进度急迫时，提供了一种先推出核心产品的途径，这样阶段交付部分功能给客户，对客户起到镇静剂的作用。
适用于需求逐渐清晰的软件项目
产品可以分割成不同的阶段分别完成
增量模型
项目生命周期模型
0 条评论
回复 删除
下一页
