《软件工程》阅读笔记

题记

近几年虽然从事嵌入式软件工作，但是对设计开发的了解依旧不足，现实工作环境中迫于各种因素，例如项目周期或体系建设，设计开发的流程基本是不健全的。需求、设计、测试本该是研发工作的重点，经常因为时间紧张而一笔带过，风险评估不足，最终大量的实践花在编程和调试。工作过程也很少有时间重构代码，各个项目推进导致的功能堆积，让代码负债累累。由于需求、设计的缺失，导致测试工作也无法有效、有目的的开展，最终导致灾难性的恶行循环，问题无法收敛，开发人员做了大量的无用功。《软件工程》很好的解释了需求、设计、开发、测试之间的关系，以及每个环节的目的、方法、工具。特此摘抄主要章节。

1.2.2 软件工程的七条基本原理

        1、采用生命周期法管理软件开发过程。应该把整个软件项目开发过程划分成若干个阶段，精心制定每个阶段的工作计划，且对整个开发及维护工作进行严格管理。

        2、始终坚持施行阶段评审。在整个软件生命周期中的每个阶段都要进行严格的评审，尽早发现开发过程中的错误。上一阶段评审没有通过，就不能进入下一阶段工作。

        3、实行严格的产品控制。在实际开发工作中，因为周围环境的变化，客户改变需求是常态，软件企业无法阻拦客户提出新的需求，只能通过产品控制管理用户变更。

        4、使用现代的软件设计方法。经过实践验证，使用高级程序设计技术既可以提高软件的开发与维护效率，又可以提升软件产品质量。

        5、成果可以审查。软件成果是一种逻辑思维产品，为了让软件项目具有可见性，便于实施进度管理与控制，通常要依据项目的整体目标及最后期限，研究并确定团队职责、标准与内部分工，从而便于对每一步的成果进行审查。

        6、团队成员少而精。软件研发组织成员的素质应尽量高且数量不宜过多。

        7、必须意识到逐步改进并提升工程实践的重要性和必要性。

1.2.3 软件工程的四个发展阶段

        1、传统软件工程

        20世纪70年代初期，软件的开发主要采用“作坊式”。随着应用软件和系统软件的需求量不断增加，软件的规模、复杂程度也快速提高，出现团队效率低，开发成本高，开发进度和质量控制难等问题。软件危机不断加重，软件工程诞生。

        2、面向对象工程

        1980年至1990年，计算机领域专家重点关注面向对象技术，逐步构成了一个完整的软件开发方法与技术体系，随后面向对象的开发方法与技术获得迅速推广。

        3、面向过程工程

        随着软件规模及其业务复杂度不断提升，软件的开发时间跨度不断增长，并且开发人员数量也在增加，这提升了软件的开发管理难度。在软件开发的实践过程中，软件企业和研发人员逐渐意识到：提升软件质量与生产效率的关键是对“软件过程”进行有效的管理和控制，提出了对项目进行计划、质量保证、成本估算、软件配置管理等策略，逐步构建面向过程工程。

        4、面向构建工程

        20世纪90年代，基于构建（模块）的开发方法获得重要突破，可使用已经存在的且可复用的构建组装成一个软件，而不需要从头开始构建，从而提升软件效率和质量，同时降低了软件开发成本。

1.3.2 软件生存周期

        1、软件定义

        软件定义即对软件进行策划，主要是完成问题定义、可行性研究、项目启动等工作，明确“需要解决哪些问题”。

        问题定义。任务：项目需要解决哪些问题？经过调查和研究，系统分析员概要的写出关于任务性质、项目目标、项目规模的相关情况报告，经过讨论和研究分析，进行适当地修改，形成一份书面报告，并获得用户的确认。参与人员：客户经理、系统分析员。生成结果：问题定义报告。

        可行性研究。任务：对当前项目的功能需求、技术和市场情况进行调研，并结合实际进行初步分析，明确是否可以启动该项目。可行性研究是一次简化的软件分析与设计过程。可行性研究工作比较简短，只是从较高层次研究问题范围，研究该问题是否可以解决，是否值得解决，是否有可行的解决方案。参与人员：技术主管、技术人员。生成报告：可行性研究报告、技术方面的调研报告。

        可行性研究的任务是：确定软件的目标与规模大小，明确软件的约束条件和限制条件，对比多种可行方案的利弊，进而确定系统的目标是否可以实现。

        可行性研究不是解决问题，而是确定问题是否值得去解决。首先要进一步分析前一步的问题定义，然后系统分析员进行简要的需求分析，导出该系统的逻辑模型，最后从逻辑模型出发，探索出若干种主要解法，对每种解法都要仔细认真研究它的可行性。一般而言，可行性研究要从技术、经济、操作和法律四个方面研究每种解法的可行性，做出明确结论供用户参考。

        技术可行性：对要开发项目的功能、性能和限制条件进行分析，评价系统所采取的技术方案是否先进，能否达到目标，现有的技术人员的技术水平是否具备完成项目的能力。

        经济可行性：进行成本——效益分析，从开发所需的成本和资源、潜在的市场前景等方面进行估算，确定要开发的项目是否值得投资，即用代价和效益两个因素度量。

        操作可行性：分析该软件的操作流程是否适合用户的业务流程，在该应用领域和行业是否行得通。

        法律可行性：新系统的开发会不会引起侵权或违法，应该重点从合同、专利、版权等相关因素进行考虑。

        可行性研究的过程可以归纳为以下几个方面

        1、确定软件目标和规模。系统分析员需要访问用户单位的关键人员，认真查阅与软件实现相关的电子资料、纸质材料，对问题定义阶段报告复查确认，改正含糊或不准确的叙述，，无二义性的描述限制条件和约束条件。该阶段的工作可以确保软件开发人员清楚该项工作的目标。

        2、研究正在用的软件。正在用的软件是可行性研究阶段信息的重要来源，该软件已经在过去相当长的一段时间内辅助用户开展了很多工作，所以新开发的软件必然能够覆盖原软件的功能。此外，系统分析员需要询问用户并发现原软件的的某些缺点，确定新软件必须解决的问题。系统分析员还需要认真阅读并分析原软件的电子资料和纸质资料，并到工作计算机上考察原软件的情况。不过，研究原软件不要花费太多时间。此外，还要注意记录原软件与其他软件有没有数据通信，因为现实当中大多数软件都需要与其他软件进行数据交换。

        3、画出软件的逻辑模型。在设计软件的逻辑模型时，通常从用户使用的旧软件出发，先导出旧软件的逻辑模型，然后根据用户的要求和系统分析员的思路设计处新软件的逻辑模型，最后进一步完善该模型。在定义新软件的逻辑模型时，一般会采用数据流图，并用数据字典辅助工作。注意，当前阶段仍不是用户需求的分析阶段，只要总体上描绘较高层次的数据处理过程及数据流向即可。

        4、列出多种可行方案。系统分析员与用户必须共同复查上一步骤设计的逻辑模型，核查问题定义、目标和项目规模，若存在异议，要及时备注并修改，直到修改后的模型完全清晰的满足用户的要求。接着，系统分析员进一步细化方案，在经济效益，技术实现，操作时间，法律等层面对多个方案进行对比，去除不合适的方案，最后得到几个可行的具体方案。

        5、给出可行方案。依据可行性研究成果，软件开发人员应给出该项目是否可以开发，是否值得开发等相关结论。如果可以开发，选择其中一种最适合的方案，并阐明该方案是较优方案的理由，以供相关部门参考。

        6、拟定开发进度设想。系统分析员在可行性方案中需要提供一份开发进度计划，在该计划中，除了软件开发进度，还需要提出开发人员类别、数量及其他资源的需求情况，并且还需要估算软件开发每个阶段的开支。

        7、拟写可行性研究报告。将上述工作成果整理成翔实的文档，并邀请用户组织的相关人员组成评审组，对材料进行审查。

        在可行性研究阶段，通常会用系统流程图对实际软件系统进行概要描述。用途是：对于软件物理系统进行实际描述，进而作为全面了解软件业务处理流程和分析软件结构的依据。也就是系统分析员、管理人员、具体操作人员相互交流的工具。用符号描述软件的各个部件（包括应用程序、数据文件、DB、表格、人工处理过程等）的数据流向和业务处理过程。注意：不要对数据处理细节和控制过程描述的过于清晰，只需要自上而下逐层进行，同层的处理方法按照从左到右的顺序画出即可。

        项目启动。任务：由技术主管或相关负责人编制合同，启动项目，由项目经理制定项目初步计划。参与人员：技术主管、项目经理、技术人员。生成结果：任务计划书、项目合同。

        2、软件开发——需求分析

        需求分析不是解决问题，而是明确软件必须具有哪些功能、性能等，也就是说，“必须做什么”及其他性能指标的要求。

        任务：对项目进行详细的需求分析，并编写需求文档，需求分析文档需要通过技术部门主管的审核才能进入下一个步骤。

        在此阶段，用户非常清楚需要解决的问题，清楚必须做什么，但往往无法准确表达他们的要求，更不清楚如何用计算机解决这些问题。而项目小组成员知道如何实现，但是对特性用户的具体要求却完全不清楚。因此，在需求分析阶段，系统分析员必须与用户进行密切配合，充分沟通交流，才可以得到经过用户最终确认的软件逻辑模型。

        软件逻辑模型是软件设计与实现的基础，因此必须完整且准确的获取用户的实际要求。在这个阶段，需要用需求分析说明书将目标系统的需求准确的记录下来。参与者：项目经理、系统分析员、项目小组成员。生成结果：项目计划修订说明、需求分析说明书、静态页面效果图。

        需求分析任务——用户需求

        1、功能需求。软件必须实现的功能，通过功能列表列出如今必须实现的全部功能，该部分工作是最重要的。

        2、性能需求。所开发软件的技术性能指标，即系统需要满足哪些约束条件。通常情况下，性能需求包括软件平均响应时间、安全性、网络速率、服务器配置等。

        3、环境需求。系统在运行时需要各种软、硬件条件，比如服务器、操作系统、外设、数据库软件等。

        4、接口需求。是描述软件与外部环境通信接口的需求，常见的形式有硬件接口需求、用户接口需求、通信接口需求、软件接口需求等。

        5、界面需求。用户界面是人机交互的媒介，界面是否美观大方也是用户非常看重的。

        6、未来需求。系统分析员通过与用户交流，应该非常明确的列出不属于当前软件开发的内容，但是根据分析未来可能会提出来的需求。目的是：在软件设计过程中提前对软件将来可能的扩充和修改做好准备，一旦在确实需要时，软件能够比较容易地实现扩展或修改。

        需求分析任务——分析数据需求

        无论多么复杂的数据都是由数据元素组成的，可以使用数据字典对数据进行全面的描述和定义。不过数据字典具有明显的缺点，不够形象直观。通常情况下，为了提高需求的可理解性，一般会使用图形工具来辅助，比如要汇总软件的数据需求，常常通过建立数据模型的方法实现，对于一些十分复杂的数据结构，常用层次方框图和维纳图等工具辅助。

        需求分析任务——创建软件的逻辑模型

        结合上述获取的结果进行分析和确认，以分析软件的组成及主要元素是否全面，并用图文与符号结合的方式导出软件的逻辑模型，一般会用到数据流图、状态转换图、控制流图、数据字典和主要算法描述该逻辑模型。

        需求分析任务——编写软件需求报告

        汇总并组织编写软件需求报告的目标是明确定义目标软件的需求、软件构成和相关的接口。在签订合同时，软件需求规格说明书作为合同的必备附件是软件测试与验收过程中软件的确认和验收标准，也是软件开发的基础资料。软件需求规格书要准确体现用户的真实需求，具备容易理解、直观、容易修改等特点。尽可能采用标准的表格、图形和简单易懂的符号表示，尽量不用专业性太强的术语，以便能让只懂业务不懂技术的用户看懂，便于交流。

        需求分析任务——需求分析评审

        主要是查找需求分析过程中存在的缺陷、错误，然后组件评审小组，组织评审并修改需求和开发计划。

        需求分析步骤包括：

        1、获取用户需求

        2、提炼用户需求

        3、描述用户需求

        4、验证用户需求。系统分析员和用户一起对用户需求规格书进行仔细、严格的验证和审查。避免需求不清晰、二义性等问题。

        用户需求的获取方法包括：

        1、对重要用户组织访谈

        2、组件软件联合分析小组

        3、相关问题的分析、确认

        快速建立软件原型模型来获取需求

        在实际的软件开发中，当软件要求比较复杂，用户需求不明确时，在需求分析过程中开发一个系统原型，在此基础上进一步获取需求是很值得做的一件事情。

        基本思路是：在很短时间内建立起一个只包含基本数据库和基础功能的原型软件供用户试用，然后依据用户的意见再对原型软件实施多次修改，直到用户满意。一般通过以下六个问题判断是否适用快速原型法：

        1、当前用户的需求已经建立，并且需求是稳定的吗？

        2、软件开发人员与用户已理解目标软件的应用场景吗？

        3、当前的问题是否可以被模型化？

        4、用户是否可以明确系统的基本需求？

        5、是否存在模糊的需求？

        6、已知的需求中存在矛盾呢吗？

        如果工期不紧急且项目经费充足，开发一个原型系统是不错的选择，如果工期紧张或经费不足，可以上线一个类似的已经实施的软件项目，给用户一些账号进行测试，引导用户提出新需求。

        需求分析常用方法

        1、功能分解法

        将一个软件看作由若干个功能组合的集合，每个功能可进一步划分为若干子功能，一个子功能又可以继续分解为若干子功能。最终会产生主功能、子功能和功能接口。

        2、结构化分析方法

        是面向数据流的需求分析方法，是从问题空间到具体映射的方法，软件的功能由数据流图表示，即数据流图和数据字典共同组成的逻辑模型。建模工具有：数据流图、数据字典、结构化语言（顺序、循环、选择）、判定树、判定表、状态转移图。还有其他工具：层次方框图、维纳图、IPO图（输入——处理——输出）。

        3、软件开发——概要设计

        概要设计主要对软件的总体（外部）结构、组成模块、模块的层次结构、调用关系及功能进行设计，并对总体数据结构进行设计。

        任务：依据需求分析说明书进行总体设计，包括程序的系统流程、模块划分、功能分配、组织结构、数据结构设计、出错处理、接口设计、运行设计等，为下一步详细设计提供基础。对概要设计进行评审后，项目经理与技术主管一起协商确定项目小组成员。参与者：技术主管、项目经理、项目小组核心成员。生成结果：概要设计说明书。

        概要设计阶段的目标是确定软件系统的具体实现方案，给出软件的模块结构、编写总体设计文档等，即明确软件是由哪些模块构成的，厘清每个模块的功能、模块模块之间的调用关系和通信接口等。

        为了明确软件的结构，从实现的角度对软件较复杂的功能实施进一步分解。系统分析员将结合算法的描述分析数据流图中的每一个处理，若一个处理过程过于复杂，应将其进行适当分解，直到分解为若干较简单的功能为止。一般情况下软件的一个模块需要实现一个子功能。因此，软件的模块应该具有较清晰的层次结构，顶层的模块通过调用其下层的模块，实现软件的完整功能，并且下一层模块将继续调用下一层模块，实现软件的一个子功能，最下面的模块将实现具体功能。

        软件结构设计的准则：

        软件的体系结构是对复杂软件的抽象，较好的软件结构可以有效的处理多种个体的需求；在一定时间内，软件的体系结构需要保持稳定，从而确保软件接口的一致性；软件体系结构的好坏决定了未来软件是否高效、稳定、可靠。

        软件模块设计的准则：

        提高软件模块的内聚性，同时降低软件模块间的耦合性。比如，若干模块共享某个子功能，建议分解出来一个公共子模块，以定义一个内聚度更高的模块，便于其他模块调用，有时候，可以将耦合度高的模块合并，从而降低模块接口的复杂度。软件应该保持合理的深度、宽度以及扇入和扇出。软件深度是指软件结构中模块层次的数量，一定意义上反应软件的规模和复杂度，若软件深度过深，则表明软件的层数太多，应审查某些模块是否可以合并。软件的宽度是指在同一层次中存在的最大模块数。通常，宽度越大的系统，软件的结构也越复杂。模块的扇出是影响软件宽度的最大因素。软件扇出是指某个模块可以直接调用的模块数量。一般而言，一个较好的软件结构，平均扇出数不会大于9。高扇出意味模块过多，此时可以适当提高中间层次的模块数。但扇出过低也不行，如果扇出过低，会将下级模块分解成若干子模块，或者将其合并到上级模块。软件扇入是指某个模块被若干上级模块调用的数目。某个模块的扇入越高，表明共享该模块的上层模块数量越多。一般不要违背软件模块独立性原理，过分追求高扇入。通常，一个较好的软件结构，一般是第一层扇出要高，中间层次扇出低，下面层次扇入高。

        接口设计须简单化。软件模块接口的设计应该追求信息传递的简单化，并且要求其与模块功能一致。若模块接口过于复杂，将产生低内聚、高耦合的软件结构。

        模块规模需进行适当划分。为了提高模块的可读性，软件模块的设计不宜过大。

        软件设计的基础：

        模块化。可以将复杂问题分解为若干容易解决的小问题，从而使原来较难的问题变得容易解决。不断对问题进行分割，开发工作量并不会越来越小。随着模块数量增加，每个模块的规模变小，但模块间的通信增加，模块间接口需要的工作量持续增加。所以，软件模块化的过程必须致力于降低模块与外部的联系，提高模块的独立性，这样才能有效减低软件复杂度。逐步求精。为了可以集中精力解决关键的问题，要尽量推迟考虑问题的细节，依据该策略，软件的体系结构是经过逐步细化处理而设计出来的。经过对需求分析报告中的用户需求进行细化、精化，逐步将其转换成软件的层次结构，直到得出可以用一门语言表达的应用程序。局部化和信息隐藏。如何将一个软件分解成最合适的模块组合呢？局部化是指让某些关系密切的元素彼此靠近。当在软件测试阶段与软件维护阶段需对软件进行修改时，采用信息隐藏当作模块化设计的规范、标准会带来很多好处，对于软件其他部分而言，软件中绝大多数数据与过程时隐蔽的，因此在修改软件时，无论产生何种错误，传播到软件其他部分的可能性会降低。

        模块独立性——耦合

        1、数据耦合。两个模块之间使用参数交换信息，并且交换的信息仅限于数据，属于低耦合。

        2、控制耦合。当模块之间传递控制信息时，属于控制耦合，属于中等耦合。

        3、特征耦合。将整个软件的某个数据结构整体当作参数传递，不过被调用的模块仅仅使用其中一些参数，即为特征耦合，属于中等耦合。

        4、公共环境耦合。若两个模块经过某个公共数据环境进行相互作用，称为公共环境耦合，公共环境一般指全程变量，内存共享区，共享通信区，物理设备等。

        5、内容耦合。最高程度的耦合，如：某个模块访问其他模块内部的数据；某个模块不经过正常入口转到其他模块内部；两个模块中存在代码重叠的情况；某个模块存在多个入口。

        设计原则为：尽可能使用数据耦合，尽量少采用控制耦合和特征耦合，控制公共环境耦合的作用区域，摒弃内容耦合。

        模块独立性——内聚

        1、低内聚。某个模块实现一组具体的任务，这些任务之间的关系是松散的，这就是所谓的偶然内聚；在逻辑上，若某个模块实现的任务是相同或类似的，称之为逻辑内聚；若某个模块需要完成的任务要在某个时间内完成，称之为时间内聚。

        2、中内聚。某个模块的全部元素采用同一个输入数据或产生相同的输出数据，称之为通信内聚；某个模块内部的元素要以既定次序执行，且元素之间是相关的，称之为过程内聚。

        3、高内聚。若某个模块内部处理的元素和某一个功能密切相关，且该处理要按一定顺序执行，称为顺序内聚；若某个模块内部的全部处理元素归类为一个整体，实现一个单一功能，称为功能内聚，是最高程度的内聚。

        内聚程度：偶然<逻辑<时间<过程<通信<顺序<功能

概要设计示例

        4、软件设计——详细设计

        详细设计主要对模块的功能、性能等在技术层面进行完整准确的描述，并转化成过程描述。

        任务：在该阶段，需要对软件的每个模块的设计方案进行说明，若一个软件比较简单，层次偏少，也可以不单独编写，相关内容可以与概要设计说明书一起编写。

        设计软件的详细规格说明书是该阶段的主要任务，依据详细规格说明书，项目小组成员根据它们可以写出代码。在此过程中，将每个模块进行详细设计，明确完成各模块功能需要的算法和数据结构。参与者：项目小组成员、项目经理。生成结果：详细设计说明书、项目计划确定版本。

        详细设计的主要任务：

        明确每个模块采用的算法；明确每个模块使用的数据结构；明确每个模块设计的接口；设计测试用例。

        结构化程序设计的概念：

        若一个程序的代码只有顺序、选择、循环三种控制结构，而且每个代码仅有一个入口与一个出口，就表明该程序是结构化的。一般具有四个特征：一个入口；一个出口；无死语句；无死循环。

        详细设计工具：

        程序流程图、盒图（N-S图）、问题分析图（PAD图）。

        没有正确或错误的人机界面，只有友好或不友好的人机界面。

        用户界面设计问题：

        人机响应时间；帮助设施；出错处理。交互式软件提供的出错信息具有以下特点：用户可以理解软件描述的问题；反馈的信息有助于软件从错误状态恢复到正常状态；反馈的信息可以指出错误可能导致的后果，便于用户重视该问题，并及时提出解决方案；无论发生什么操作失误，软件提示信息都不能责怪用户。人机交互重点考虑下列问题：命令通常有控制序列、键入命令、功能键三种，本次设计采用哪种形式？是不是提供的命令操作序列需要投入的时间和精力过大，忘记命令怎么办？是否可以向用户提供缩写的命令序列或自定义命令操作序列？

        用户界面设计原则：

        让客户掌控软件，而不是软件掌控客户；尽量降低用户的记忆量；始终保持人机界面的一致性，保持外观一致性，设计界面前，务必充分了解用户，熟悉业务流程，尽量不改变用户的习惯，除了保持界面风格一致性，还应保持术语一致性。

        5、软件设计——编码实现

        编码实现需要软件工程师写出正确且容易理解和维护的程序模块。软件工程师应当依据目标系统的要求和环境，选择一种或多种开发语言，将详细设计说明书中的要求转换成程序代码，并且测试编写好的每个模块。参与者：项目经理、软件工程师、美工。生成结果：软件版本说明、软件产品规格说明。

        6、软件设计——调试（测试）

        为了确保软件质量，需要完成调试任务，主要是用各种工具和方法对软件的功能、性能进行检测。任务：项目经理提交测试申请后，由测试部门对软件实施测试，项目小组要配合测试部门完成错误部分的修改工作。参与者：测试部门人员、项目经理、软件工程师。生成结果：测试申请书、测试计划书、测试报告。

        7、软件设计——系统验收

        对项目验收工作进行归档。参与者：技术主管、项目经理、用户。生成结果：项目所有文档和程序。

        8、软件维护

        该阶段主要是对交付并部署应用的软件产品进行必要的维护，并保存相关维护文档。该阶段的主要目的是让软件持续满足用户的工作需要。软件交付并投入使用后，发现软件错误时，应该加以维护，当软件的运行环境改变时，应当适当修改软件适应新的环境，当用户有新的需求时，应该及时完善软件以满足用户的要求。每一次维护工作实质上就是一次经过压缩和简化的开发过程。

1.4 软件生存周期模型

        1、瀑布模型，即软件开发过程按照顺序进行，一步接着一步做的模型，该模型适合那些软件需求比较明确，开发技术成熟，项目管理较严格的场合。使用瀑布模型的项目具有以下三个特点：按照顺序开发软件；不可过早编程；确保软件质量。各个阶段必须按照要求完成相关文档资料的书写和汇总，并且每个阶段都要对书写的文档资料进行复审，以便及时发现相关隐患并排除。瀑布模型也有缺陷，即将软件实践中相互叠加的开发过程人为分成若干阶段。这样随着软件规模扩大，会产生越来越多的问题。因此，人们给瀑布模型增加了回溯和反馈的环节，对其加以改进。

        2、快速原型模型，思想是结合用户的实际需要，先快速开发一个浓缩的原型系统，并在此基础上与客户、潜在用户进行交流的模型。用户对原型系统进行评价，并提出改进意见，以便细化软件需求。开发人员通过逐步构建原型系统从而达到客户要求，继而准确获取用户的实际需求，最终依据详细且实际的需求组织开发软件。

        3、增量模型，可将一系列构建实施集成和测试，每个构建完成不同的功能，最终将其组合成一组具有完整功能的软件。增量模型的灵活性强，适用于需求不太明确、软件设计方案具有一定风险的项目。增量模型的缺陷：增量模型要求所研发的软件具有开放式的体系架构，原因是各个构件是人工逐步并入已经存在的软件体系结构中，因此加入的新构件不可以破坏已经实现的软件结构。增量模型的过程控制容易失去整体性，在实际的软件开发中，用户难免经常对需求产生变化，在这方面，增量模型的灵活性优于瀑布模型和快读原型模型，不过也很容易退化成一边做一边改的模型。