软件开发方法

约定不等于承诺〃 2022-04-23 08:42 555阅读 0赞

软件开发方法目的在于提高软件质量，降低成本。

一、软件生命周期   
软件生存周期，分为8个阶段：   
1、可行性研究与计划   
2、需求分析   
3、概要设计   
4、详细设计   
5、实现   
6、集成测试   
7、确认测试   
8、使用和维护

二、软件开发模型   
大规模软件开发时代，有了各种各样的模式化开发方法，称为开发模型：   
（一）瀑布模型   
开发如同瀑布，从一个阶段流向下一个阶段。其思想认为软件开发是一个阶段化的精确过程，每一个步骤都划分得很明确，阶段之间有明显的界线。

经典的瀑布模型除了需求分析，每一个阶段，都可以有一个反馈指回上一阶段，作为修正机制。但缺陷总是无处不在，瀑布模型有了一个变体：瀑布V模型，即编码前的阶段，都与后面一个测试阶段对应：

![è¿éåå¾çæè¿°][SouthEast]  
当软件需求明确、稳定时，可以采用瀑布模型，一旦需求变动剧烈，往往到测试阶段才暴露，造成修改代价太大，风险难以控制。其缺点表现在：   
1、过于依赖需求分析，一旦偏差，后续会逐步放大；   
2、难以适应变化，一旦需求变更，需要推倒重来；   
3、交付要等到最后阶段；   
4、文档驱动，一大堆，浪费人力物力，对客户意义却不大。

瀑布模型是一种理想的状态，一个个阶段流过，软件就出来了。但是，人的认识有一个过程，不可能从一开始就什么都想得很好。

（二）演化模型   
若干次瀑布模型的迭代。   
根据迭代内容，演化模型可以演变为螺旋模型、增量模型和原型法开发。

（三）螺旋模型   
演化模型的变种。特点是强调风险，每次瀑布模型迭代前，引入风险控制。将软件项目分解成一个个小项目，每个都标识风险，直到所有风险都被确定。   
演化模型适合高风险项目。但对风险评估技能要求高，迭代过多，开发成本高。

（四）增量模型   
演化模型的另一变种。   
增量发布和原型法。   
增量发布将系统划分为若干版本，每一个版本都是完整的。版本的划分要均匀。   
原型法应对需求不明的情况，主要目的是获得用户需求。

（五）构件组装模型   
顾名思义。   
构件设计对架构师要求高；为照顾复用性，可能会牺牲性能；熟悉构件需要学习成本。

（六）统一过程   
统一过程（unified process,up）。二维模型，横轴是时间，纵轴是工作内容。

![è¿éåå¾çæè¿°][SouthEast 1]  
从时间看，历经起始、细化、构建和交付四个大阶段，然后每个大阶段会有一些小阶段；每个阶段都有相应的工作内容（纵轴），不过侧重点、所占比重不一样。

架构设计师在UP活动中除了设计系统架构，还要与需求人员、项目管理人员密切合作，细化软件架构，保持整个架构的概念完整性。UP是一个以架构为中心的开发模型。

（七）敏捷方法   
敏捷方法的核心是尽早交付，经常交付。   
1、极限编程（XP）   
敏捷方法中最成熟。   
特点：   
1）尽快反馈（有东西可看？）   
2）尽快制定总体计划   
3）自动测试   
4）提倡口头交流

一些关键词：

不过度设计（简单设计）   
持续集成   
结对编程   
测试驱动   
集体代码所有制   
现场客户   
重构

2、特征驱动开发（FDD）   
迭代开发，每一步都强调质量。   
1）角色定义   
FDD认为软件三个要素是：人、过程和技术。最重要的是人。FDD定义了6种人员角色：

项目经理   
首席架构设计师   
开发经理   
主程序员   
程序员   
领域专家

2）核心过程

![è¿éåå¾çæè¿°][SouthEast 2]  
3）最佳实践   
（1）代码个体所有，谁开发谁负责   
（2）审查

3、Scrum   
“争球”，一个来自于橄榄球运动的名词。   
增量迭代开发，整个开发过程由若干个短的迭代周期组成，一个短周期称为一个sprint，长度2到4周，甚至1周。   
scrum按照优先顺序对用户需求进行排序、开发，每个条目称为用户故事。   
 ![è¿éåå¾çæè¿°][SouthEast 3]  
关键词：产品代办事项 每日站会 用户故事 计划会议 迭代

4、水晶方法   
适合6人以下小团队。   
特征：团队融洽，紧密合作   
经常交付   
渗透式交流：团队成员在一个室内一起工作，有人提出问题或发起讨论，其他人可关注可不关注，气氛轻松自由。   
反思改进   
与专家沟通无阻   
自动化测试

5、其他敏捷方法   
开源，远程办公

（八）、软件重用   
软件重用也算一种开发方法？   
1、软件重用形式   
1）源代码重用   
2）架构重用   
3）应用框架重用   
4）业务建模重用   
5）文档及过程重用   
6）软构件重用   
构件，组件   
7）软件服务的重用   
SOA

（九）、基于架构的软件设计   
基于架构的软件设计（Architecture-Based Software Design，ABSD）是一种架构驱动方法。

所谓架构驱动，是指架构先行，需求获取和分析还没有完成(甚至远远没有完成)，就开始了软件设计。当然这不意味着需求获取和分析活动就可以终止，而是应该与设计活动并行。特别是在不可能预先决定所有需求时，例如产品线系统或长期运行的系统，快速开始设计是至关重要的。

ABSD有3个基础：   
功能分解   
选择架构风格来实现质量和业务需求   
使用软件模板

1、ABSD方法与生命周期

![è¿éåå¾çæè¿°][SouthEast 4]  
2、ABSD开发模型   
ABSDM。将这种基于架构的软件过程划分为   
架构需求、设计、文档化、复审、实现、演化6个子过程。

![è¿éåå¾çæè¿°][SouthEast 5]  
（十）形式化方法   
采用严格的数学方法和形式化规约语言（不同于我们平时所用的自然语言）来精确定义软件系统，包括描述和验证两部分。   
特点是描述精确，需求没有模糊和二义性，产生的软件可靠性高。   
不明觉厉。

[SouthEast]: /images/20220322/2f222a4e5fdc4151b8afcb4da3d4cb8f.png
[SouthEast 1]: /images/20220322/0f403e9beb33493e96cfd5276dc2cc72.png
[SouthEast 2]: /images/20220322/c208694a5ff846ec80bd9f52950feb19.png
[SouthEast 3]: /images/20220322/80aca8044383492b9202ee8ffa186fb9.png
[SouthEast 4]: /images/20220322/2d54f331199945a4be4d5b5cce1517b4.png
[SouthEast 5]: /images/20220322/b42331b4bf054c05b64561b9f324a971.png