系统架构设计师：软件开发基础知识

        本课题是为了解决 “软件危机”问题。

        软件开发方法是软件开发的方法学，通过软件开发方法研究，提高软件的质量、降低软件的成本。

        软件开发方法包括：软件生命周期、软件开发模型、软件重用技术、逆向工程及形式化开发方法

一、软件生命周期

            软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程成为软件生存周期。

            软件生存周期的提出是为了更好地管理、维护和升级软件，其中更大的意义在于管理软件开发的步骤和方法。

          GB8566-88中，软件生命周期划分为8个阶段：

1.可行性研究与计划。确定开发此软件的必要性、目标、范围、风险、成本，输出《可行性研究报告》和《软件开发计划》。

2.需求分析。有了目标和范围，需要对需求进行细致的分析，确定软件是什么样的。

3.概要设计。确定了软件的技术蓝图，把需求分析的结果转换为技术层面的设计方案：系统架构、子系统间的关系、接口规约、数据库模型、编码规范等。

4.详细设计。在概要设计的基础上，进行细化。有一些小工程可能省略这个阶段。

5.实现。编码和单元测试。

6.集成测试。也叫组装测试。

7.确认测试。是否与需求一致？是否达成预期的目标？

8.使用和维护。使用过程中，业务需求会变化、环境会变化，新的bug会出现，因此，需要不断维护。

二、软件开发模型

1. 瀑布模型。

        瀑布模型认为软件开发是一个阶段化的精确的过程，阶段间有明显的界限和反馈，一个阶段结束会有固定的文档或者代码输入下一个阶段。因此，瀑布模型是面向文档的软件开发模型。

        瀑布V模型是瀑布模型的一种变体。工程师们发现，缺陷无法避免，如何阶段都会在软件中引入缺陷，最后的测试也无法保证100%正确，只能争取在交付之前发现更多的缺陷。V模型就是增强了测试的瀑布模型：

        瀑布模型是经典的开发模型，具有以下缺点：

       一是需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果导出。

       二是难以适应变化，阶段之间有强依赖性，后期有变化，前面的所有阶段都需要修改。

       三是所有阶段都结束之后，才有交付产品。需要很长时间才会有结果。

       瀑布模型是文档驱动的，除了制造软件产品外，也将产生大堆的文档，大部分的文档对客户是没有意义的，整理编写这些文档需要花费大量的人力物力，所以瀑布模型是 重载过程 。

2.演化模型

         演化模型是做若干次瀑布模型的迭代，完成一个瀑布周期，又开始另外一个瀑布周期，不断演化、完善。根据不同迭代特点，分为螺旋模型、增量模型和原型法开发。

2.1 螺旋模型

        每一个周期包括：需求定义、风险分析、工程实现和评审。

     

        风险分析：风险识别、风险分析和风险控制。

        有了风险分析环节，螺旋模型适用于特别庞大而复杂、具有高风险的系统，软件交付时间长。

        螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。

        使用螺旋模型，需要具备相当丰富的风险评估经验和专业知识。

2.2 增量模型

        适用于技术架构成熟、风险较低，增量模型缩短初始版本的交付周期，提高用户对系统的可见度。

        增量模型有两种策略：

        一是增量发布方法。把软件划分为若干不同版本，每一个版本都是完整的系统，后一个版本在前一个版本的基础上进行开发，扩充前一个版本的功能。第一版本往往是系统的核心功能。

       二是原型法。原型法的每一次迭代都经过一次完整的生命周期，原型法用于加强用户参与度，提高需求的明确性。一般情况下，后期会抛弃最开始的原型，重新实现完整的系统。

3. 构建组装模型

       构件是独立的、自包容的，构件之间通过接口相互协作。

       优缺点：

      构件的自包容性让系统的扩展变得容易；构件可以重用；可以对软件进行不同颗粒度划分，任务分工清晰，可以并行开发；

      构件设计需要经验丰富的架构设计师；性能可能是一个问题；需要熟悉构件，增加了学习成本；第三方构件难以控制，最终会影响软件的质量。

三、统一过程

        统一过程（UP）是由Rational公司开发的一种迭代的软件过程，提供了完整的开发过程解决方案，可以降低风险，可以适应各种规模的团队和系统。

        横轴是时间主线，纵轴是不同阶段的工作流程，每一个阶段都是相互交叠配合的，但是每一个阶段都是侧重点：

初始阶段重点是业务建模，细化阶段重点是分析设计，构建阶段重点是构建和测试，交付阶段重点是重构、修改、测试和部署。

        纵轴是9个核心工作流：业务建模、需求、分析设计、实施、测试、部署、配置和变更管理、项目管理、环境。环境比较难以理解：在软件开发中，需要为各种工作准备相应的工作环境，在工作环境中需要包含必需的工具、活动的指南、活动的流程规范、工作产品的模板、基本的开发设施等。实际的公司很多时候是忽略了环境的，放羊式的管理，除了收获羊毛，啥也收获不了。

        UP是特点鲜明的开发模型：

        它是一个迭代的二维开发模型；采用不同迭代模式UP可以演变为演化模式或者增量模型；它容易控制软件开发的风险；未经裁剪的UP是一个重载过程。有人也称UP是一个以架构为中心的开发模型。

四、敏捷方法

        2001年2月在美国犹他州17位“无政府主义者”共同发表了《敏捷软件开发宣言》，指出：

尽早地、持续地向客户交付有价值的软件；

拥抱变化，即使在开发的后期；

经常交付可工作的软件；

业务人员和开发者紧密合作；

围绕士气高昂的团队进行开发，提供适宜的环境，足够的信任；

面对面沟通；

可以工作的软件是进度首要的度量方式；

可持续地开发；

不断追求优秀的技术和良好的设计；

要简单，尽可能减少工作量；

最好的架构、需求和设计都来自于一个自我组织的团队；

团队要定期总结如何才能更有效率，相应地调整。

        以上就是敏捷开发方法，其中极限编程（XP）比较普遍。

        XP是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。

XP 的四大价值观：

      一是沟通。比如结对编程。

      二是简单。够用即好。

      三是反馈。客户、管理层、开发团队，通过反馈达成信息的流转。

      四是勇气。有勇气面对快速开发，面对可能的重新开发。

XP的十二个最佳实践：

       1）计划游戏。快速计划，用户故事。

       2）小型发布。持续集成、小步快走。

       3）隐喻。寻求共识、发明共享语汇、描述架构。

       4）简单设计。设计不应该在编码之前一次性完成。

       5）测试先行。不能忽略测试。

       6）重构。要有重构的勇气。

       7）结对编程。强调人文主义，协作顺畅、知识交流和共享、团队稳定。

       8）集体代码所有制。代码属于所有人，公开、民主。

       9）持续集成。

       10）每周工作40小时。

       11）现场客户。把客户请到现场。

       12）编码标准。确保代码清晰、便于交流。

除了XP，敏捷开发方法还有特征驱动开发、Scrum、水晶方法等。

五、基于架构的软件设计

         ABSD是一种架构驱动方法，它有三个基础：

        一是功能的分解。   

        二是选择架构风格实现质量和业务需求。

        三是软件模板的使用。

六、需求分析

        开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细的技术需求，这包括面向用户、面向机器和其他软件系统的接口。同时，这也是一旦出错，将会该系统带来极大困难的部分，并且以后再对它进行修改也极为困难。

        软件需求可以分为几个层次：

1.业务需求（business requirements）。反映组织结构或者客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中给予说明。

2.用户需求（user requirements）。描述用户使用产品必须完成的任务，在用例文档或者方案场景中给予说明。

3.功能需求（functional requirements）。描述开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。

4.非功能需求（none-functional requirements）。描述系统展现给用户的行为和执行的操作等。包括：产品必须遵循的标准、规范和合约；外部界面的具体细节；性能要求；设计或者实现的约束条件；质量属性。

        软件需求说明书（SRS）是需求分析阶段的成果，不仅是系统测试和用户文档的基础，也是所有子系统项目规划、设计、编码的集成。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求说明书不应该包括设计、构造、测试或工程管理的细节。

        可以使用一下三种方法编写软件需求规格说明：

1.用好的结构化和自然语言编写文本型文档。

2.建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的编号、数据关系、逻辑流或对象类和它们的关系。

3.编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

七、结构化分析方法

        结构化分析方法（SA）是一种预先严格定义需求的方法，强调分析对象的数据流，其指导思想是自顶向下逐层分解。

八、聚合和耦合

        模块的独立程度有两个定性标准度量：聚合和耦合。

        聚合衡量模块内部各元素结合的紧密程度；

        耦合度量不同模块间相互依赖的程度；

        聚合程度从低到高排列：偶然聚合——逻辑聚合——过程聚合——时间聚合——通信聚合——顺序聚合——功能聚合

        耦合程度从低到高排列：数据耦合、控制耦合、公共耦合和内容耦合。

九、用例模型

        用例模型描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互；在系统的上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者的关键交互。用例建模可以描述利益相关者所看到的系统行为。

        获取需求的沟通和交流技巧：用户访谈；用户调查和联合讨论会议。

十、RAD（快速应用开发）模型

      RAD模型是一个增量型的软件开发过程模型，强调极短的开发周期。RAD模型是瀑布模型的一个高速变种，通过大量使用可复用的构件，采用基于构件的构造方法赢得快速开发。如果需求理解得好，而且项目范围明确，利用这种模型可以很快创建出功能完善的信息系统。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反馈。各个活动周期完成任务如下：

        1.业务建模：以什么信息驱动业务过程运转？要生成什么信息？谁生成它？信息流的去向是哪里？由谁处理？可以用数据流图

        2.数据建模：为支持业务过程的数据流，找数据对象集合，定义数据对象属性，与其他数据对象的关系构成数据模型，可以用E--R图

        3.过程建模：使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找，细化数据流图。

        4.应用程序生成：编写处理程序，重用已有构件或创建新的可重用构件，逐步搭建整个应用系统。

        5.测试与交付：大量构件重用，重点不在于构件的测试，重点在系统测试和集成测试，但是新创建的构件还是需要测试的。

缺点：1.模块或者功能点必须能够模块化；2.需求必须快速开发出来，需要客户高度配合；3.如果需要较高互操作性，风险比较高；4.构件之间需要通信，通信会成为系统性能瓶颈。

十一、基于构件的开发模型

        基于构件的开发模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或者多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化的，开发过程是迭代的。基于构件的开发模型由需求分析和定义、体系结构设计、构件库建立、应用软件构建、测试和发布5个阶段。

        基于构件的开发方法使得软件开发不再一切从头开始，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程，其优点是构件组装模型导致了软件的重用，提高了软件开发的效率，降低了费用，提高了可维护性。

        构件通用的标准，组装标准、通信标准，性能可能是瓶颈，需要精干、有经验的分析人员和开发人员。构件库的质量影响着产品质量。