【系统架构设计】开发方法（一）
软件生命周期
指软件自开始构思与研发到不再使用而消亡的过程。在GB8566-88（《软件工程国家标准–计算机软件开发规范》）中将软件生命周期划分为8个阶段：
- 可行性研究与计划 ： 如果确定该软件具有研发的必要，则将产生《可行性研究报告》和 ** 《软件开发计划》**。初步确定软件开发的目标和范围。
- 需求分析：对软件的需求进行细致的分析，确定软件要做成什么样的。
- 概要设计：确定整个软件的技术蓝图，负责将需求分析的结果转化为技术层面的设计方案。需要确定系统架构、各子系统间的关系、接口规约、数据库模型、编码规范等内容。
- 详细设计：进一步细化，如类的设计，但不是开发过程中必须的阶段，在一些规模小、结构简单的系统中可以省略。
- 实现：包括编码和单元测试。
- 集成测试
- 确认测试：当完成集成测试后，软件之间的接口方面的错误已经排除，这时需要验证软件是否同需求一致，是否达到了预期目标。
- 使用和维护
软件开发模型
瀑布模型
核心思想
当软件需求明确、稳定时，可以采用瀑布模型按部就班地开发软件，当软件需求不明确或变动剧烈时，瀑布模型中往往要到测试阶段才会暴露出需求的缺陷，造成后期修改代价太大，难以控制开发的风险。
瀑布V模型
由于缺陷时无法避免的，任何一个阶段都会在软件中引入缺陷，而最后的测试也不能保证软件完全没有缺陷。因此，提出了更强调测试的瀑布V模型。
缺点
-
由于需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果中导出的。而由于用户和开发者的立场、经验、知识域都不相同，不同人对同一个事物的表述也不同，这就造成需求分析的结果不可能精确、完整地描述整个软件系统，从而影响后续活动，给后期的维护工作带来繁重工作。
-
难以适应变化。因为在瀑布模型中精确地定义了每个阶段的活动和活动结果，而每个阶段都紧密依赖于上一阶段的结果，如果在软件的后期出现需求的变化，整个系统又要从头开始。
-
使用该模型意味着当所有阶段都结束才能最终交付软件产品，所以在提出需求后需要很长一段时间才能看到最终结果，才能发现软件产品究竟是否能够满足客户的需求。
-
文档驱动型的瀑布模型除了制造出软件产品外，还要产生一大堆的文档，大部分的文档对客户没有任何意义，但完成这些对客户没有意义的文档却需要花费大量的人力。所以瀑布模型也是一种重载过程。
ps ： 自顶向下设计，一次性设计出成品。
演化模型
一个演化模型可以看做若干次瀑布模型的迭代，当完成一个瀑布模型后，重新进入下一个迭代周期，软件在这样的迭代过程中得以演化、完善。根据不同的迭代特定，演化模型可以演化为螺旋模型、增量模型、原型法开发。
螺旋模型
将瀑布模型和演化模型结合，还强调了其他模型均忽略的风险分析。螺旋模型的每个周期都包括如下4个阶段，由这4个阶段进行迭代，软件开发过程每迭代一次，软件开发就前进一个层次。
适用于庞大而复杂、具有高风险的系统。该模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力，为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。
但需要具有相当丰富的风险评估经验和专业知识，在风险较大的项目开发中，如果未能及时标识风险，势必会造成重大损失。而且过多的迭代次数会增加开发成本，延迟提交时间。
增量模型
在系统的技术架构成熟、风险较低的时候，可以采用增量方式进行开发，这样可以提前进行集成测试和系统测试，缩短初始版本的发布周期，提高用户对系统的可见度。常用的2种策略：
一是增量发布的办法，就类似于手机APP的不同版本累加，每个版本都是一个完整的版本，虽然最初的几个增量不能完全实现用户需求，但这些版本都是完整的、可用的；而且版本间的增量要均匀的，如果第一个版本花费一个月时间，而第二个版本需要花费6个月时间，这种不均匀的分配会降低增量发布的意义，需要重新调整。
另一种是原型法 ，每一次迭代都经过一个完整的生命周期。当用户需求很不明确或技术架构中存在很多不可知因素的时候，可以采用原型法。在初始的原型中，针对一般性的用户需求进行快速实现，并不考虑算法的合理性或系统的稳定性。主要目的是获得精确的用户需求，或验证架构的可用性。一般情况下，会在后面的开发中抛弃这个原型，重新实现完整的系统。
构件组装模型
类似于组态。优点是：
- 构件的自包容性让系统的扩展变得更加容易
- 设计良好的构件更容易被重用，降低软件开发成本
- 构件的粒度较整个系统更小，因此安排开发任务更加灵活，可以将开发团队分成若干组，并行独立开发构件。
缺点是：
- 对构件的设计需要经验丰富的架构设计师，设计不良的构件难以实现构件的优点，降低构件组装模型的重用度
- 在考虑软件的重用度时，往往会对其他方面做出让步，如性能等
- 使用构件组装应用程序时，要求程序员熟练掌握构件，增加研发人员学习成本
- 第三方构件库的质量会最终影响到软件的质量，而第三方构件库的质量往往是开发团队难以控制的。
ps：现在微服务、组态这些其实类似构件组装模型的思想。
统一过程
统一过程（Unified Process ,UP）是由Rational 公司开发的一种迭代的软件过程，是一个优秀的软件开发模型，它提供了完整的开发过程解决方案，可以有效降低软件开发过程的风险，经过裁剪的UP可以适应各种规模的团队和系统。
在UP生命周期中共有4个里程碑：
- 目标里程碑 ：对应着先启阶段的结束，当开发者可以明确软件系统的目标和范围时即达到了该里程碑。
- 架构里程碑：主要hi明确稳定的系统架构
- 能力里程碑：当系统已经足够的稳定和成熟并完成Alpha 测试后，认为达到了第3个里程碑
- 发布里程碑：在达到发布里程碑前，需要完成系统的测试、完成系统发布和用户培训等工作。
UP的一些特点：
- UP是一个迭代的二维开发模型，在生命周期的每个阶段都可以进行需求、设计等活动，UP不但给出了迭代的生命周期，还给出了生命周期每个阶段的迭代指南。
- 采用不同迭代方式的UP可以演变为演化模型或增量模型
- UP的迭代特点使得更容易控制软件开发的风险
- 虽然UP是一个迭代的开发模型，但UP本身并不属于敏捷方法。相反，一般认为未经裁剪的UP 是一个重载过程。
- 在实际应用中可以根据具体问题对UP进行裁剪，从而使其可以适应各种规模的软件和开发团队。
ps : 简单说，UP是一个详细的模板，然后根据实际情况去删减不必要的部分，虽然说，未裁剪的UP是一个重载的过程。