| 无双 回复于：2003-04-29 18:30:37
|
件开发过程生命周期模型
二、瀑布模型
瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品。如图所示：
[img:e15b0a0420]http://www.micsoftware.com/images/lifemodel.jpg[/img:e15b0a0420]
优点：
a.强调开发的阶段性；
b.强调早期计划及需求调查；
c.强调产品测试。
缺点：
a.依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
b.由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
c.风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。
这是最早存在的开发模型，并且现在使用的也比较多
|
| 无双 回复于：2003-04-30 19:05:20
|
瀑布模型的特点是首先是仔细的需求分析，开发组有步骤的制定一份功能(结构)说明，接着是概要设计，详细设计，然后才着手编码。编码结束后进行测试，然后才能发布软件。这看上去是很有逻辑的；只在理解后才开始构造。以这样严格的方式构造软件，工程师很明确每一步应该做什么。许多人提出了基本是基于这一模型的多种方法论；也有相当多的商业工具可以使这些步骤更机械化且不易出错。
瀑布模型各阶段的工作自顶向下从抽象到具体顺序进行。瀑布模型意味着在生命周期各阶段间存在着严格的顺序且相互依存。瀑布模型是早期软件设计的主要手段
瀑布模型依靠早期的需求分析，并且要求需求很明确
对于需求未定或是不断变化的软件不适合
现在这种模型一般用于做一些需求已明确的并很少变化的软件,不适于需求 不明确或是容易变化的软件（如你正在开发一个陌生的领域的软件，这时就不应该使用瀑布模型，但是如果你正在开发自己很熟悉领域的软件，就可以使用瀑布模型来加快开发速度）
由于需求已明确，所以不需要代码重构等方面的开销,因此效率较高
|
| 一无所有 回复于：2003-05-01 08:52:44
|
呵呵，可以做教科书用了。
|
| 无双 回复于：2003-05-01 12:55:38
|
内容是从网上找的
另外加上了我的理解
不知道会不会误导大家
希望大家能一起讨论
|
| 轩辕砍刀 回复于：2003-05-01 14:15:47
|
又学到了，谢
其它几个模型呢？
|
| 无双 回复于：2003-05-03 10:58:24
|
前几天出去玩了
现在继续写,原文是http://www.micsoftware.com/lifemodel.htm
感想是我自己加的
[code:1:ffe312549b]
阶段 主要工作 应完成的文档 应完成的文档质量控制手段
系 1．调研用户需求及用户环境 1．可行性报告 1．规范工作程序及编写文档
统 2．论证项目可行性 2．项目初步开发计划 2．对可行性报告及项目初步
需 3．制定项目初步计划 开发计划进行评审
求
需 1．确定系统运行环境 1．需求规格说明 1．在进行需求分析时采用成熟
求 2．建立系统逻辑模型 2．项目开发计划 的技术与工具，如结构化分析
分 3．确定系统功能及性能要求 3．用户手册概要 2．规范工作程序及编写文档
析 4．编写需求规格说明、用户 4．测试计划 3．对已完成的4种文档进行评审
手册概要、测试计划
5．确认项目开发计划
设 概 1．建立系统总体结构，划分功能模块
要 2．定义各功能模块接口 1．概要设计说明书 1．在进行系统设计时采用先进
设 3．数据库设计（如果需要） 2．数据库设计说明书（如果有）的技术与工具，如结构化设计SD、结构图SC
计 计 4．制定组装测试计划 3．组装测试计划 2．编写规范化工作程序及文档
3．对已完成的文档进行评审
详 1．设计各模块具体实现算法 1．详细设计说明书 1．设计时采用先进的技术与工具，如结构图SC
细 2．确定模块间详细接口 2．模块测试计划 2．规范工作程序及编写文档
设 3．制定模块测试方案 3．对已完成的文档进行评审
计
实 1．编写程序源代码 1．程序调试报告 1．在实现过程中采用先进的技术与工具，如结构图SC
2．进行模块测试和调试 2．用户手册 2．规范工作程序及编写文档
现 3．编写用户手册 3．对实现过程及已完成的文档进行评审
测 集 1．执行集成测试计划 1．系统源程序清单
成 2．编写集成测试报告 2．集成测试报告
试 测 1．测试时采用先进的技术和工具
试 2．规范工作程序及文档编写
验 1．测试整个软件系统（健壮性测试） 1．确认测试报告 3．对测试工作及已完成的文档进行评审
收 2．试用用户手册 2．用户手册
测 3．编写开发总结报告 3．开发工作总结
试
维 1．为纠正错误，完善应用而进行修改 1．故障报告 1．维护时采用先进的工具
2．对修改进行配置管理 2．修改报告 2．规范工作程序及编写文档
护 3．编写故障报告和修改报告 3．配置管理
4．修订用户手册 4．对维护工作及已完成的文档进行评审
[/code:1:ffe312549b]
|
| 无双 回复于：2003-05-06 18:17:14
|
原文所在网站已读不到
所以停止一段时间
如果以后也读不到的话
那么将会到其它网站上找资料
整理一下把各个模型写完
|
| 无双 回复于：2003-05-14 19:03:37
|
原网站可以继续访问
所以这个感想会继续写下去
如果各位有什么问题或见解可以讨论一下
三、演化模型
该模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。如图所示。
|
| 无双 回复于：2003-05-14 19:04:36
|
[img:f2a2ed5b73]http://www.micsoftware.com/images/lifemodel1.jpg[/img:f2a2ed5b73]
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。
|
| 无双 回复于：2003-05-14 19:05:47
|
优点：
a.任何功能一经开发就能进入测试以便验证是否符合产品需求。
b.帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型的试用而作出修改。
c.风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环作出比较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。
d.大大有助于早期建立产品开发的配置管理，产品构建（build ），自动化测试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。
e.开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与效率。
f.如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作的产品。
g.心理上，开发人员早日见到产品的雏型，是一种鼓舞。
h.使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价值的反馈。
i.可使销售工作有可能提前进行，因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。
缺点：
a.如果所有的产品需求在一开始并不完全弄清楚的话，会给总体设计带来困难及削弱产品设计的完整性，并因而影响产品性能的优化及产品的可维护性。
b.如果缺乏严格的过程管理的话，这个生命周期模型很可能退化为一种原始的无计划的“试－错－改”模式。
c.心理上，可能产生一种影响尽最大努力的想法，认为虽然不能完成全部功能，但还是造出了一个有部分功能的产品。
d.如果不加控制地让用户接触开发中尚未测试稳定的功能，可能对开发人员及用户都产生负面的影响。
|
| tian_feng 回复于：2003-05-18 21:20:58
|
请举个例子说明一下如何进行调查分析后的设计(概要设计和详细设计)
比如,我想编写一个为班主任管理各个学生成绩的一个软件,我如何进行这个初期的设计讷?
我是初学,还请各位多多指教.
|
| 无双 回复于：2003-05-19 12:53:56
|
先分析
你需要什么操作（查询、添加、删除等，一定要了解完）
要保存什么数据（姓名等，这也要知道）
要怎样的介面(web还是c/s形式的)
概要设计与详细设计部分
如果是小软件不用写
只是大软件才写
概要就是与设计语言无关的
定义主要接口
说明完成这个功能要多少类，每个类的接口怎样
详细就是定义实现，与语言相关
并且对每个类的实现也要写出来，以及类算法
论坛中旧帖也有设计文档的编写
你可以参考一下
|
| 无双 回复于：2003-05-24 18:12:56
|
四、螺旋模型
瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。该模型于1998年由美国TRW公司（B.W.Boehm）提出。软件项目风险的大小作为指引软件过程的一个重要因素，引入这一概念有可能使得软件开发被看作一种元模型，因为它能包容任何一个开发过程模型。
|
| 无双 回复于：2003-05-24 18:13:34
|
[img:6831e82472]http://www.micsoftware.com/images/lifemodel2.jpg[/img:6831e82472]
螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被取消。
另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员可作出决定让余下的开发工作采用另外的生命周期模型，如“演化模型”，“瀑布模型”，或自定的混合模型。
优点：
a.强调严格的全过程风险管理。
b.强调各开发阶段的质量。
c.提供机会检讨项目是否有价值继续下去。
缺点：
a.引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员，资金，和时间的投入。
|
| 无双 回复于：2003-05-24 18:13:55
|
五、软件生命周期模型的选择
对于需求明确的项目，建议采用演化模型。
对于规模小，需求简单，功能单一的项目，建议采用瀑布模型。
其他项目，一般采用迭代模型。
|
