系统架构设计师-软件工程-软件开发方法

这是我参与更文挑战的第25天，活动详情查看： 更文挑战

前言

本文主要介绍系统架构设计师-软件工程-软件开发方法方面的内容。

软件开发方法

本节主要考察软件开发方法和软件开发模型

结构化法

• 用户需求第一位
• 严格区分工作阶段，每阶段有任务与成果
• 强调系统开发 过程的整体性和全局性
• 系统开发过程工程化:文档资料标准化
• 自顶向下:逐步分解(求精)

原型法

适用于 需求不明确的开发（做一个简易版先让用户提提不足）
包括抛弃型原型和进化型原型

面向对象方法

更好的复用性
关键在于建立一个全面、合理、统一的模型
分析、设计、实现三个阶段:没有明确的界限

面向服务的方法

SO方法有三个主要的抽象级别:操作、服务、业务流程
SOAD分为三个层次:基础设计层(底层服务构件)、应用结构层(服务
之间的接口和服务级协定)和业务组织层(业务流程建模和服务流程编排)
服务建模:分为服务发现、服务规约和服务实现三个阶段

软件开发模型

瀑布模型

地位：经典模型,提供了软件开发的基本框架。自上而下，如同瀑布一般，所以叫瀑布模式。
优点:

1. 各阶段划分清晰
2. 强调计划与需求分析（需要一个强有力的产品将需求分析的一干二净）
3. 适合需求稳定的产品开发（现实不可能存在的）

缺点:

1. 单一流程，不可逆
2. 风险显露得晚，纠正机会少（做好之后发现和产品想的不一样的次数太多了）
3. 测试只是其中一个阶段，缺乏全过程测试思想（所以在开发进行开发时，需要测试提前介入并跟产品开发进行测试用例的沟通）

演化模型

开发模式类似重复执行的多个瀑布模型，每次开发出的功能会成为这个产品的原型的新增功能，用户体验完之后，提出新的优化点，一般来说，每次循环在6周左右。

螺旋模型

螺旋模式是将瀑布和演化结合起来，不仅体现这两者的优点，还强调了风险分析。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险都有所了解，继而做出应有的反应。因此，螺旋模型特别适用于庞大而复杂、具有高风险的系统，对于这些系统，风险是软件开发潜在的、不可忽视的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。
减小软件风险的目标是在造成危害之前，及时对风险进行识别、
分析，决定采取何种对策，进而消除或减少风险的损害。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

1. 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
2. 风险分析：分析评估所选方案，考虑如何识别和消除风险；
3. 实施工程：实施软件开发和验证；
4. 客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

1. 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
2. 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
3. 软件开发人员需要具有相当丰富的风险评估经验和专业知识，准确地分析风险，否则将会带来更大的损失

增量模型

每一个增量均发布一个可操作的产品，一开始提交的是高风险和重要部分，要求每次必须很好地定义接口，因为每次新增量都会破坏原有开发产品，要是设计的不好那就会变成边做边改模型了。

构建组装模型

有点类似搭积木，在构建组装模型中，当经过需求分析定义出软件功能后，将对构件的组装结构进行设计，
将系统划分成一组构件的集合，明确构件之间的关系。个人认为有点微服务的感觉。
优点：

1. 构件的自包容性让系统的扩展变得更加容易
2. 设计良好的构件更容易被重用，降低软件开发成本
3. 构件的粒度较整个系统更小，因此安排开发任务更加灵活，可以将开发团队分成若干组，并行地独立开发构件。

鱼与熊掌不可兼得，构件组装模型也有明显的缺点：

1. 对构件的设计需要经验丰富的架构设计师，设计不良的构件难以实现构件的优点，降低构件组装模型的重用度。
2. 在考虑软件的重用度时，往往会对其他方面做出让步，如性能等。
3. 使用构件组装应用程序时，要求程序员熟练地掌握构件，增加了研发人员的学习成本。
4. 第三方构件库的质量会最终影响到软件的质量，而第三方构件库的质量往往是开发团队难以控制的。

统一过程

初始

开发者刚刚接入系统，此时最重要的工作是界定系统范围，明确系统目的。
在这一阶段，业务建模和需求工作成了重头戏

• 确定项目范围和边界
• 识别系统的关键用例
• 展示系统的侯选架构
• 估计项目费用和时间
• 评估项目风险

细化

开发者需要抽象出软件的逻辑模型，设计出软件的架构，在这一阶段，分
析设计工作是最主要的工程活动。

• 分析系统问题领域
• 建立软件架构基础
• 淘汰最高风险元素

构建

开发者需要基本完成系统的构建，使之成为一个完整的实体，并进行测试
和部署，在这一阶段，实施和测试是最主要的活动

• 开发剩余的构件
• 构件组装与测试

交付

软件系统需求已经完全成熟或产品化，或进入下一个版本。在这一阶段不可避免地要对软件系统进行重构、修改、测试和部署。

• 进行β测试
• 制作发布版本
• 用户文档定稿
• 确认新系统
• 培训、调整产品

极限编程

敏捷方法和其他方法论相比，最大的不同在于更短的周期，更早的反馈，大量的自动测试，减少沟通成本，开发团队内部紧密协作。