1.项目生命周期定义参考网站:http://wiki.mbalib.com/wiki/%E9%A1%B9%E7%9B%AE%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F
2.一个完整的项目生命周期一般分为:计划、需求分析、设计、编码、测试、发布、实施以及运行维护阶段。
参见下图标准过程:
3.软件过程模型是从项目需求定义直至经使用后废弃为止,跨越整个生存期的系统开发、运营维护所经历的全部过程、活动和任务的结构框架。
4.软件过程模型一般分为:瀑布模型、原型模型、螺旋模型、增量模型。
5. 5种项目生命周期模型
a.瀑布模型:
1) 特点
l 阶段间具有顺序性和依赖性:必须等前一阶段的工作完成之后,才能开始后一阶段的输入。对本阶段工作进行评审,若得到确认,则继续下阶段工作,否则返回前一阶段,甚至更前阶段。只有前一阶段输出正确,后一阶段才能正确。
l 推迟实现的观点:在编码之前,设置了需求分析与设计的各个阶段,分析与设计阶段的根本任务规定在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现。
l 质量保证的观点:
每个阶段都坚持两个做法:
规定文档,没有文档就没有完成该段任务。
每个阶段结束前都要对完成的文档进行评审,以便尽早发现问题,改正错误。
2) 缺点
l 依赖于早期进行的唯一的一次需求调查,不能适应需求的变化;
l 由于是单一流程,开发中的经验教训不能反馈应用于本产品的过程;
l 风险往往迟至后期的开发阶段才显露,因而失去及早纠正的机会。
3) 适用项目
l 需求清晰明了且时间要求宽松的软件开发项目;
l 规模小,需求简单,功能单一的项目
4) 阶段划分
计划阶段
需求阶段
设计阶段
编码阶段
测试阶段
发布阶段
实施阶段
运行维护阶段
b.原型模型:
原型模型快速建立起来的可以在计算机上运行的程序,他所能完成的功能往往是最终产品能完成的功能的一个子集。一般来说,根据客户的需要在很短的时间内解决用户最迫切需要,完成一个可以演示的产品,这个产品只实现部分功能。原型最重要的是为了确定用户的真正需求。
原型模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面,确有显著效果。软件系统的原型常用有以下形式:
抛弃型:开发原型为了获取需求,在原型开发之后,已获取了更为清晰的需求信息,原型无需保留而废弃;
渐进型:原型作为软件最终产品的一部分,可满足用户的部分需求,进一步在此基础上开发,则可增加需求,实现后再交付使用;
1) 特点
l 用户需求不完全或不确定;
l 针对总体的轮廓先建立一个用户需求原型,然后进行评价和反馈;
l 对原型进行扩充、改进和求精;
l 完成最终系统
2) 缺点
l 没有考虑软件的整体质量和长期的可维护性。
l 大部分情况是不合适的操作算法被采用目的为了演示功能,不合适的开发工具被采用仅仅为了它的方便,还有不合适的操作系统被选择等等。
l 由于达不到质量要求产品可能被抛弃,而采用新的模型重新设计。
3) 适用项目
l 客户能提出一般性的目标,但不能标出详细的输入、处理及输出需求;或开发者不能确定算法的有效性、操作系统的适应性、及人机交互的形式。
l 用户定义了一组一般性目标,但不能标识出详细的输入、处理及输出需求;
l 开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式
4) 阶段划分
抛弃型原型模型的阶段划分:
需求分析阶段--获取业务需求
原型实现阶段—主要是界面实现,业务流程用图形方式表示。
客户评价阶段--和客户确认,完善业务需求
渐进型原型模型的阶段划分:
需求分析阶段(需求分析、原型实现、客户评价)
设计阶段
编码阶段
测试阶段
发布阶段
实施阶段
运行维护阶段c.螺旋模型
将瀑布模型与原型模型结合起来,并且加入两种模型均忽略了的风险分析。
1) 特点
风险驱动的,关注风险,风险分析后决策是否继续进行项目
2) 优点
l 对可选方案和约束条件的强调有利于已有软件的重用,也有助于把软件质量作为软件开发的一个重要目标;
l 减少了过多测试或测试不足;
l 维护和开发之间并没有本质区别。
3) 适用项目
主要是用于大规模软件项目,需求不明朗,风险比较高的项目。
4) 阶段划分
螺旋模型沿着螺线旋转,自内向外每旋转一圈便开发出更完善的一个新版本。一个螺旋为一个阶段,每个螺旋式周期可分为:
l 制定计划: 确定软件目标,选定实施方案,弄清项目开发的限制条件;
l 风险分析: 分析所选方案,考虑如何识别和消除风险;
l 实施工程: 实施软件开发(需求、设计、编码、测试等按螺旋周期推进)
l 客户评估: 评价本轮的开发结果,提出修正建议,计划下一轮的工作。
d.增量模型
融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。把软件产品作为一系列的增量构件来分析、设计、编码、测试和发布。
1) 特点l 第一阶段增量往往是核心产品
l 每一阶段增量均为可发布一个版本,早期的增量是最终产品的“可拆卸”版本
2) 优点
l 人员分配灵活,刚开始不用投入大量人力资源,当核心产品很受欢迎时,可增加人力实现下一个阶段增量。同时人员可以并行工作。
l 需求明确部分可以分阶段实现,逐步优化系统需求,逐步集成系统元素
l 阶段交付,当配备的人员不能在设定的期限内完成产品时或者客户/市场要求进度急迫时,提供了一种先推出核心产品的途径,这样阶段交付部分功能给客户,对客户起到镇静剂的作用。
3) 适用项目
适用于需求逐渐清晰的软件项目
4) 阶段划分
计划阶段
第一阶段(需求、设计、编码、测试、发布)
第二阶段(需求、设计、编码、测试、发布)
第N阶段(需求、设计、编码、测试、发布)
发布阶段
实施阶段
运行维护阶段
e.V模型
最典型的V模型版本一般会在其开始部分对软件开发过程进行描述:
v-model是一种软件生存期模型,旨在提高软件开发的效率和有效性,是瀑布模型的一种改进,瀑布模型(Waterfall Model)将软件生命周期划分为计划、分析、设计、构建、测试和维护六个阶段,且规定了它们自上而下、相互衔接的固定次序,由于早期的错误可能要等到开发后期的测试阶段才能发现,所以带来严重的后果。 v-model就是在这点改进了瀑布模型,在软件开发的生存期,开发活动和测试活动几乎同时的开始,这两个并行的动态的过程就会极大的较少bug和error出现的几率。在v-model中,我认为一个关键词就是parallel,说起来简单,却是v-model的核心。
v-model包含了三个等级,分别是生存期模型,分配模型,功能性工具需求模型,生存期模型回答了“What has to be done?”的问题,阐述了应当实施哪些活动,应当产生哪些结果,诸如此类。分配模型回答了“How is it be done”,决定了在实施活动的时候应该使用什么方法,功能性工具需求模型回答了“What is used to do it”,采用什么样的工具来实现这些活动。所有这些等级中又是由4个子模块组成的,分别是项目管理模块(PM),系统开发模块(SD),品质保证模块(QA),配置管理模块(CM),这些模块的功能就显而易见了。