-
目录
瀑布模型(面向文档的软件开发模型)
场景:适用于需求稳定、明确的项目。
过程:需求分析、总体设计、详细设计、编码和调试、集成测试和系统测试。
特点:是一种严格遵循软件生命周期各个阶段的固定顺序的模型,每个阶段划分明确,都有固定文档或源程序流入下一个阶段。需求分析是一切活动的基础。
缺点:
1. 由于需求不可能精确、完整的描述整个系统,造成后期维护工作繁重,这些维护工作大多都是在修正需求分析阶段引入的缺陷。
2. 难以适应变化,如果软件在后期出现需求变化,整个系统需要从头开始。
3. 交付时间长,需要等到所有阶段都结束才能交付产品,导致客户无法尽快确定需求是否满足。
4. 产生大量对客户无用的文档,确花费了大量人力,是一种重载过程。
-
演化模型
场景:适用于用户需求不明确,且软件完善周期较长的项目。
特点:从初始的模型中逐渐演化为最终软件产品,是一种“渐变式”原型法。可以看作是若干次瀑布模型的迭代,在迭代的过程中得以演化和完善。
缺点:
1. 需要对需求进行明确的拆分,能清晰识别需求边界。
2. 所有的产品需求一开始并不完全弄清楚,会给总体设计带来困难及削弱产品的完整性。
螺旋模型
场景:项目规模庞大,复杂且高风险。
特点:是瀑布模型和演化模型的结合,并增加了风险分析(引入非常严格的风险识别、风险分析、风险控制),支持用户需求动态变化。
过程:需求定义、风险分析、工程实现、评审。
缺点:1. 需要具有相当丰富的风险评估经验和专业知识。
2. 过多的迭代次数会增加开发成本,延迟提交时间。
增量模型
场景:在系统的技术架构成熟、风险较低的时候采用。
特点:提前进行集成测试和系统测试,缩短初始版本的发布周期,提高用户对系统的可见度
策略:
- 增量发布
特点:将系统划分为若干个不同的版本,每个版本都是一个完整的系统,后一版本以前一版本为基础进行开发,扩充功能,版本间的增量必须是均匀的。
- 原型法
特点:当用户需求不明确或技术架构中存在很多不可认知因素的时候,采用原型法。主要目的是获得精确的用户需求或验证架构的可用性,一般情况会在后期的开发中抛弃这个原型,重新实现完整的系统。
缺点:如何组织一个开放的结构使得该模型不会退化到建造修补模型。
构件组装模型
特点:独立的、自包容的,构件之前通过接口相互协作。
过程:设计构件组装、建立构件库、构建应用软件、测试与发布。
优点:
1. 构件的自包容性让系统更容易扩展
2. 更容易被重用,降低开发成本
3. 粒度更小,因此安排开发任务更加灵活。
缺点:
- 设计不良的构件难以实现构件的优点,需要经验丰富的系统架构师。
- 考虑重用度时往往会对其他方面做出让步,如性能等。
- 组装应用程序时,要求程序要熟练掌握构件,增加研发人员学习成本。
- 第三方构建质量难以控制,可能会影响最终软件质量。
统一过程(up)(迭代的软件过程,以架构为中心)
场景:一个通用的过程框架,适合于各种应用领域、组织水平、项目规模的项目。
过程:初始、细化、构建、交付。
- 初始阶段(目标里程碑):界定系统范围,明确系统目的,实现业务建模和需求分析。
- 细化阶段(架构里程碑):描述抽象的软件逻辑模型(分析),设计软件架构。
- 构建阶段(能力里程碑):完成系统构建(实施),并进行测试和部署。
- 交付阶段(发布里程碑):系统完全成熟或产品化,进入下一个阶段,对产品进行重构、修改、测试和部署。
优点:
- 采用强大的UML建模语言,能够在团队中形成统一规范和模板。
- 有很多成熟的商业软件提供整个开发周期的相关支持,极大的降低开发和管理成本,提高开发效率。
缺点:虽然UP是一个迭代的开发模型,但是本身并不属于敏捷开发,未经裁剪的up是一个重载过程。
敏捷开发模型
场景:适用于小规模软件或者小团队开发。
特点:是一种以人为核心、迭代、循序渐进的开发方法。
今天的文章七种常见软件开发模型有哪些_常用的数据模型「建议收藏」分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:http://bianchenghao.cn/76462.html