软考-开发方法

原创

已于 2022-09-20 11:16:14 修改 · 1.6k 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#软件工程

于 2022-09-15 17:33:34 首次发布

导读

随着进入大规模软件开发的时代，软件系统变得非常复杂，也随着开发软件系统数量的增多，前辈们根据一些规则和经验总结出一些开发模型，遵循这些的开发模型会大大提高开发效率，每种开发模型都有特有的思想，本章用来总结和学习现有的一些软件开发模型。本章将介绍软件生命周期、软件开发模型、软件重用技术、逆向工程及形式化开发方法。

随着时间长河不断演进的各种思想，面向过程到面向对象再到面向服务等等，也总结出不同思想下的各种开发模型，例如强调过程，以文档驱动的瀑布模型；强调测试伴随始终，瀑布模型的变种V模型；对瀑布模型根据不同的渐进、迭代和不断深化思想的演化模型，又如根据演化模型增加风险分析所演变的螺旋模型；每个版本都可发布的增量模型；复用思想的构建组装模型、以及迭代思想的统一过程UP。

软件的生命周期

软件的生命周期指软件开始构思到不在使用而消亡的过程，生命周期的阶段划分不同的标准由不同的规定，在GB8566-88《软件工程国家标准-计算机软件开发规范》中将软件的生命周期分为8个阶段，分别为可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。

可行性研究与计划

在决定是否开发软件之前，首先需要进行可行性研究。通过可行性研究，来确定开发此软件的必要性，并根据可行性研究的结果初步确定软件的目标、范围、风险、开发成本等内容。从而指定出初步的软件开发计划。通过可行性研究，如果确定该软件具有研发的必要，则将产生《可行性研究报告》和《软件开发计划》

需求分析

对软件的需求进行细致的分析，来确定软件要做成什么样的。如果需求分析出现重大偏差，那么软件开发必然会偏离正确的道路，越走越远。尤其是需求分析的错误在开发后期才发现，修正的代价是非常大的。

概要设计

用于确定整个软件的蓝图，负责将需求分析的结果转化为技术层面的设计方案。该阶段需要确认系统架构、各子系统间的关系、结构规约、数据库模型、编码规范等内容，概要设计的结果将作为程序员的工作指南，供程序员了解系统的内部原理，并在其基础上进行详细设计和编码工作

详细设计

编码前的最后设计，在概要设计的基础上进行细化，如类设计。详细设计不是开发过程中必需的阶段，在规模较小、结构简单的系统中，详细设计往往被忽略，也有可能只有部分关键模块进行详细设计

实现

该阶段包括编码和单元测试，单元测试是指对刚刚编写出的一个小程序单元进行测试，如某一过程、方法或函数，有效的单元测试可以大大提高编码质量，降低系统缺陷率

集成测试

也称为组装测试，通过单元测试的程序不意味没有缺陷，当程序单元被集成在一起进行交互时，往往会出现单元测试中没有发现的问题，集成测试必须经过精心的组织，指定集成测试计划、确定如何将这些单元集成到一起，按照什么顺序进行测试，使用哪些测试等问题

确认测试

当完成集成测试后，软件之间的接口错误已经排除，这事需要验证软件是否同需求一致，是否达到预取目标，与集成测试一样，确认测试也需要进行计划和组织，逐步的验证软件系统同需求的一致性，主要是测试是否满足需求

使用和维护

即使通过了单元、集成、确认测试也不可能发现软件系统中全部的缺陷；软件系统的需求也会根据业务的发展变化而变化，因此在软件使用过程中，必须不断对软件进行维护，修正软件中的缺陷，修改软件中已经不能适应最新情况的功能或者增加新的功能，软件维护的过程会贯穿整个软件的使用过程，当使用和维护阶段结束后，软件也就会自然消亡，软件系统的生命周期结束

小结

1. 本章内容是对软件系统生命周期的梳理，需要记住有多少个阶段，每个阶段的作用以及输入和输出

2. 最后说明软件消亡不单单指废弃，废弃不在使用该项目只是消亡的一种，也会有重构的可能，可以理解涅槃重生。

软件开发模型

瀑布模型

主张软件开发是一个阶段化的精确过程，以文档进行驱动每个阶段且有每个阶段明显的界限，将上一个阶段的输出成果作为下一个阶段的目标，如同瀑布一样，从特定的阶段流向下一个阶段，软件过程分为需求分析、总体设计、详细设计、编码与调试、集成测试和系统测试阶段才能被准确的实现，每一个阶段都有回到前一个阶段的反馈线，反馈线的作用是当在后续阶段发现缺陷时，可以把这个缺陷反馈到上一个阶段进行修正。

从图中可以看出，软件开发的阶段划分时明确的，每个阶段到下一个阶段都有明确的分界线、每个阶段结束都会有固定的文档或源程序流入下一个阶段。

需求分析阶段结束后需要产出明确描述软件需求的文档；

总体设计阶段结束后需要产出描述软件总体结构的文档；

详细设计阶段结束后需要产出可以用来编码的详细设计文档；

编码阶段结束后需要产出源代码；

小结

当软件需求明确、稳定时可以采用瀑布模型按部就班的开发软件、但不适用于需求不明确或变化剧烈的情况，瀑布模型往往要到测试阶段才会暴漏出需求的缺陷，造成后期修改代价太大，难以控制开发的风险

V模型

瀑布模型的变种，用于解决瀑布模型发现缺陷时机过晚导致后期修改缺陷代价过大的问题，强调测试贯穿项目始终，期望在交付前能够发现更多的缺陷，对瀑布模型进行小小的改动形成了V模型，模型在编码与调试阶段转了个弯，形成了对称的V字。

V模型同瀑布模型一样需求分析阶段完成后来到总体设计阶段，但除了总体设计外，需求分析还用虚线指向了系统测试，这里指的是将需求分析的结果作为系统测试的准则，既需求分析阶段也将产生同软件需求一致的系统测试，以此类推，总体设计对应了集成测试、详细设计对应了单元测试，V模型不但保持了瀑布模型的阶段式文档驱动的特点，更强调了软件产品的验证工作

小结

关于需求分析指向系统测试，这里并不是实际测试工作，而是指在需求分析阶段可以根据分析后的需求(功能)形成系统测试的准则，也就是文档性质的东西，在写准则的时候就可以排除一些缺陷出来

虽然V模型可以解决一些瀑布模型的一些缺陷，但是还有部分问题无法解决，首先，瀑布模型中，需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果中导出的，一旦需求分析的结果存在偏差，那么后续的活动只能放大这个偏差，在错误的道路上越走越远。事实上，由于用户和开发着的立场、经验、知识与都不相同，不同的人对同一件事物的表述也不同，这就会造成需求分析的结果不可能精确、完整的描述整个软件系统，所以瀑布模型后期的维护工作相当繁重，这个问题是瀑布模型难以克服的。其次，难以适应变化。在瀑布模型中精确的定义了每一个极端的活动和活动结果，而每一阶段都紧密依赖于上一个阶段的结果，如果在软件后期出现需求的变化，整个系统又要从头开始，再次，使用瀑布模型意味着当所哟阶段都结束才能最终交付软件产品，所以在提出需求后需要相当长一段时间的等待才能够看到最终结果，才能发现软件产品究竟能不能满足客户端的需求，最后文档文档驱动型的瀑布模型除了制造出软件产品外还将产生一大堆的文档，大部分的文档对客户没有任何意义，但完成这个对客户没有意义的文档却要花费大量的人力，所以瀑布模型也是一种重载过程。

演化模型

瀑布模型变种之一，瀑布模型看起来很好，随着一个有一个阶段流过，软件系统就被建立起来，可以在实际应用开发中，人们发现很难一次性完全理解用户的需求、设计出完美的架构，开发出可用的系统，由于人的认知本身就是一个过程，这个过程是渐近的不断深化的。对于复杂问题”做两次“肯定能够做的更好，演化模型正是基于这个观点提出，一般情况下一个演化模型可以看作若干次瀑布模型的迭代，当完成一个瀑布模型后，重新进入下一个迭代周期，软件在这样的迭代过程中的到演化、完善。根据不同的迭代特点，可以演变为螺旋模型、增量模型和原型法。

螺旋模型

螺旋模型将瀑布和演化模型结合起来，不仅体现了两个模型的优点，而且还强调了其他模型忽略的风险分析，每一周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代，每迭代一次软件开发就向前进一个层次。

小结

在”瀑布模型“的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。把软件项目分解为一个个小项目，每个小项目都表示一个或多个主要风险，知道所有的主要风险因素都被确定。

强调风险分析，使得开发人员和用户对每个演化层出现的风险都有所了解，继而做出应用的反应，因此特别适用于庞大而复杂具有高风险的系统，支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供方便，有助于提高目标软件的适应能力，为项目管理人员即使调整管理决策提供了便利，从而降低了软件开发风险。但是也有其缺点，采用螺旋模型需要具有相当丰富的风险评估经验和专业知识。在风险较大的项目开发中，如果没有及时标识风险，势必会造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。

增量模型

演化模型的另一种形式。在系统的技术架构成熟、风险较低的时候，可以采用增量的方式进行系统开发，这样可以提前进行集成测试和系统测试，羧酸初始版本的发布周期，提高用户对系统的可见度。

增量模型通常由两种策略。

增量发布，首先做好系统的分析和设计工作，将系统划分为若干不同的版本，每一个版本都是完整的系统，后一版本以前一版本为基础进行开发，扩充前一版本的功能，在这种策略中第一版往往是系统的核心功能，可以满足用户最基本的需求，随着增量的发布，系统的功能逐步丰富完成。用户在很短的时间就会获得初始版本并进行试用，后续将试用产生的问题进行分析后由下一版本进行解决，降低系统风险，但需要注意每一个版本都是完整的、可用的。版本之间的增量要均匀。

原型法，与增量发布不同，原型法每一次迭代都经过一个完整的生命周期。当用户需求不明确或技术架构存在很多不确定因素时，可以采用原型法。在初始的原型中，针对一般性的用户需求进行快速实现，并不考虑算法的合理性或系统的稳定性，主要是用于获得精确的用户需求或验证架构的可用性，一般情况会在后面的开发中抛弃这个原型，重新实现完整系统，原型法由分为演化型原型与抛弃型原型

构件组装模型

随着软构建技术的发展，尝试利用软构件进行搭积木式的开发，即构件组装模型。在构建组装模型中，当经过需求分析定义出软件功能后，将对构件的组装结构进行设计，将系统划分为一组构件的集合，明确构件之间的关系。在确定了系统构建后，则将独立完成每个构件，这时既可以开发软件构件，也可以复用已有构件，当然可以购买或选用第三方的构件，构建是独立的，自包容的，因此架构的开发也是独立的，构件之间通过接口互相协作。

构件组装模式的优点有很多，构件的自包容性让系统的扩展变得更加容易；设计良好的构件可以更容易重用降低开发成本；构建的粒度较小，因此安排开发任务更加灵活，可以将开发团队分为若干组，并行的独立开发构件。当然鱼和熊掌不可兼得，也有很明显的缺点，对构件的设计需要经验丰富的架构设计师，设计不良的构件难以实现构件的优点，降低构件的重用度；考虑软件重用度时，往往会对其他方面做出让步，比如性能；使用构件组装应用程序时