1 软件工程学概述

一、软件危机

1.什么是软件危机

软件危机是指计算机软件的开发和维护过程中所遇到的一系列严重问题。

2.软件危机的典型表现

对软件开发成本和进度估计尝尝很不准确
用户对“已完成的”软件系统不满意的现象经常发生
软件产品的质量往往靠不住
软件常常是不可维护的
软件通常没有适当的文档资料
软件成本在计算机系统总成本中所占的比例逐年上升
软件开发生产率提高的素服，远远跟不上计算机应用迅速普及深入的趋势

3.产生软件危机的原因

软件本身的特点
软件开发与维护的方法不正确

4.消除途径

对软件的正确认识
技术措施
组织管理措施

二、软件工程

1.什么是软件工程

把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件
研究时提到的途径

2.软件工程的基本特性

软件工程关注于大型程序的构造
软件工程的中心课题是控制复杂性
软件经常变化
开发软件的效率非常重要
和谐地合作是开发软件的关键
软件必须有效地支持它的用户
在软件工程领域中通常由一种文化背景的人替具有另一种文化背景的人创造产品

3.软件工程的基本原理

用分阶段的生命周期计划严格管理
坚持进行阶段评审
实行严格的产品控制
采用现代程序设计技术
结果应能清楚地审查
开发小组的人员应该少而精
承认不断改进软件工程实践的必要性

4.软件工程方法学

传统方法学
面向对象方法学

三、软件工程生命周期

1.软件生命周期3个时期

①软件定义、②软件开发、③运行维护

2.声明周期的8个阶段

问题定义①
可行性研究①
需求分析①
总体设计②
详细设计②
编码和单元测试②
综合测试②
软件维护③

四、软件过程

1.瀑布模型（需求明确）

（1）定义

瀑布模型是一种软件开发流程模型，强调软件开发过程的顺序性和阶段性。在这个模型中，整个开发过程被划分为多个清晰的阶段，每个阶段必须完全完成，并通过相应的评审和验收，才能进入下一个阶段。瀑布模型的工作方式是自上而下的，像瀑布一样，前一个阶段的输出是后一个阶段的输入。

瀑布模型的典型开发阶段：

需求分析：收集和定义用户需求，明确系统功能和性能要求。
系统设计：在需求分析的基础上，设计系统架构、模块划分、数据结构和接口等。
编码实现：根据设计文档进行软件编码，逐步实现系统功能。
测试：在开发完成后，对软件进行功能、性能、兼容性等方面的全面测试，确保软件质量。
部署与维护：将系统交付给用户，进行部署，并在使用过程中进行维护和更新。

（2）特点

阶段性：开发过程被划分为若干个阶段，每个阶段有明确的目标和产出。每个阶段的完成都需要经过评审和验收，才能进入下一个阶段。
顺序性：瀑布模型是线性的，开发流程按固定顺序执行。每个阶段的输出是下一个阶段的输入，阶段间没有重叠。每完成一个阶段，开发人员才能继续进入下一个阶段。
文档驱动：瀑布模型强调文档化，每个阶段都需要有详尽的文档记录。例如，需求文档、设计文档、测试报告等都是关键的输出。
严格的依赖关系：一个阶段的输出必须完全符合下一个阶段的需求，前一个阶段的错误或遗漏必须在后续阶段解决，不支持并行或重复的工作。

（3）优缺点

优点：
- 过程结构清晰，容易管理和控制。
- 每个阶段有清晰的文档产出，便于项目跟踪和控制。
- 适合需求明确、稳定、变化较少的项目。
缺点：
- 需求变化不易处理。一旦需求发生变化，开发周期较长，修改成本高。
- 难以进行用户反馈和调整，直到测试阶段才会暴露问题。
- 不适用于复杂或探索性强的项目。

（4）适用范围

需求明确且固定：项目在开始前，所有的需求都已经清晰定义，并且不容易发生变化。比如一些企业内部的管理系统、政府或军事系统等。
技术成熟：所使用的技术和工具已经非常成熟，不会发生技术上的重大变化。
项目规模较小或中等：项目团队成员较少，开发周期相对较短。
不要求频繁的用户反馈：用户对系统的需求不易变化，开发过程中的反馈不需要很频繁。
需求不明确或变化频繁的项目：如果项目需求不明确，或者客户频繁提出新的需求或修改现有需求，瀑布模型就不太适用。这种情况下，采用更灵活的模型（如敏捷开发）会更合适。
技术不确定的项目：如果技术方案或架构在开发过程中会有较大变动，瀑布模型也可能不适用。

2.快速原型模型（需求不明确+小型开发）

（1）定义

快速原型模型是一种通过快速开发原型来与用户进行交互，并根据反馈不断改进和完善系统需求的开发方法。原型是系统的一个初步、简化版本，通常功能有限，但可以用于演示和获取用户反馈。

基本过程：

需求收集：收集用户对系统的初步需求，但不需要完全详细和完善的需求文档。
构建原型：根据初步的需求，开发一个可运行的原型系统。这个原型可能并不包含完整的功能，而是重点展示关键特性。
用户评估与反馈：将原型交给用户使用，获取他们的反馈。用户根据原型可以更清晰地描述自己的需求和期望。
修改和完善原型：根据用户的反馈，修改和增强原型的功能，再次展示给用户。
重复迭代：通过多次迭代，逐步完善原型，直到最终系统符合用户需求。

（2）特点

迭代和反馈：快速原型模型强调通过与用户的频繁互动和反馈来改进系统。用户可以在每一轮迭代中看到一个逐步完善的系统，确保最终产品与需求匹配。
快速开发：开发初期不需要完善的需求分析和详细的设计，而是先构建一个快速原型，快速展示基本功能。
高用户参与：用户在整个开发过程中有较强的参与感，能直接影响产品的功能和特性。
需求不完全定义：在早期阶段，不需要完全定义所有的需求。需求是随着原型的开发和用户反馈逐渐明晰的。
原型不完整：原型系统并非最终产品，可能只包含最核心的功能，并且在后续开发中会进行重新设计和扩展。

（3）适用范围

快速原型模型适用于一些需求不明确、变化频繁或难以在初期完全定义的项目，尤其是用户需求较为模糊或不稳定的情况。

适用的项目特点：

需求不明确或容易变化：在需求不完全明确或经常变化的情况下，快速原型模型可以通过早期的原型来帮助明确需求。
高度用户参与的项目：如果项目需要与用户频繁沟通，并且用户的反馈对项目成功至关重要，快速原型模型非常合适。
需要用户反馈来确定功能的项目：如产品设计类、UI/UX相关项目、创新型项目等，需要不断修改和迭代来满足用户的期望。
时间紧迫，需要快速交付原型的项目：快速原型模型能够在较短的时间内交付可运行的系统原型，帮助尽早展示和验证核心功能。

不适用的项目：

需求相对固定、明确的项目：如果需求在项目开始前已经很明确，且不容易变动，使用传统的开发模型可能更加高效。
大型、复杂的系统：当系统规模非常庞大时，使用快速原型模型可能会导致后期代码重构和设计混乱，增加开发和维护成本。

（4）优缺点

优点：

需求发现与确认：能够帮助发现和确认系统需求，特别是在需求不完全明确的情况下，用户可以通过原型系统更直观地提出需求。
高用户满意度：由于用户在开发过程中有较多的参与，且能够直接看到自己的反馈被实现，因此用户满意度较高。
快速迭代与改进：通过快速的原型开发和用户反馈，能够迅速发现问题并进行改进，避免了过多的初期投入。
降低开发风险：通过原型的不断演示和反馈，能够早期发现潜在的问题和误解，减少后期开发的风险。

缺点：

原型不代表最终系统：由于原型只是一个简化版本，原型的设计和实现往往不符合最终系统的架构要求，因此后期可能需要大量的重构和调整。
可能导致过度依赖用户反馈：过度依赖用户的反馈可能导致需求的过度变化，增加了开发的复杂性。
时间和资源消耗：虽然原型开发较快，但不断迭代和修改可能会消耗大量的时间和资源，尤其是当需求变化频繁时。
技术细节可能被忽略：由于原型主要关注功能展示，可能忽略了系统架构、性能优化等技术细节，导致后期系统不稳定。

3.增量模型（短时分批提交）

（1）定义

增量模型是一种迭代式的软件开发方法。与瀑布模型的严格顺序不同，增量模型将开发过程分为多个小的、可管理的增量，每个增量是系统的一个功能模块。每个增量都是功能完整且可交付的版本，在完成后交付给用户使用，并根据用户的反馈来进行下一轮的增量开发。增量模型允许系统在开发过程中逐步增添新功能，直至完成整个系统。

基本过程：

需求分析：在项目开始时进行需求分析，并根据需求将系统分解为多个功能模块，决定各个增量的优先级和开发顺序。
开发第一个增量：开发最基础的增量，通常是系统的核心功能，或者一个可以独立运行的小模块。这个增量完成后可以交付给用户。
交付和反馈：第一个增量完成后，交付给用户使用并收集用户反馈，确保系统的基本功能正常运行并满足初步需求。
开发后续增量：根据用户的反馈，开发下一个增量，逐步增加系统的功能。在每个增量开发过程中，都可能会调整和完善系统。
反复迭代：每个增量完成后都进行评估和反馈，逐步增加系统功能，直到整个系统开发完成。

（2）特点

增量模型的主要特点如下：

逐步交付功能：系统的功能是分阶段交付的，每个增量都是一个功能完整的可交付版本。每个增量增加新的功能或改进现有功能。
灵活性和适应性：增量模型允许开发过程中根据用户的反馈调整需求，开发团队可以灵活应对需求变化。
用户参与：用户在每个增量交付后都会参与评审和反馈，确保系统更符合实际需求。
早期交付和测试：每个增量都可以在早期阶段交付给用户并进行测试，这有助于及早发现问题并修正。
并行开发：不同增量可以并行开发，特别是在系统中不同功能模块之间相对独立的情况下，能够加快开发进度。

（3）适用范围

增量模型适用于那些需求逐步明确、需求变化不大、或者期望在开发过程中逐步完善的项目。它尤其适用于复杂系统，开发过程中可以逐步增加功能。

适用的项目特点：

需求逐步明确：如果项目的需求不完全明确，可以通过增量开发来逐步定义系统需求，每个增量都可能对需求进行改进。
复杂的、庞大的系统：对于功能庞大、复杂的系统，增量模型能够将开发工作分解为多个小模块，降低系统开发的复杂度。
需要快速交付的项目：增量模型适合那些需要尽早交付部分功能、让用户提前使用的项目。这样可以确保系统早期功能能尽早投入使用。
用户反馈重要的项目：对于需要频繁获取用户反馈的项目，增量模型可以通过每个增量的交付获取反馈，不断优化系统。

不适用的项目：

需求已经完全明确的项目：如果需求非常明确且稳定，增量模型可能会增加开发复杂性，因为它要求频繁的迭代和反馈。
时间和预算非常紧张的项目：增量模型需要多个增量的开发，可能导致项目周期延长，如果没有足够的时间和预算，可能不适用。

（4）优缺点

优点：

早期交付和使用：增量模型允许在开发初期就交付部分功能，用户可以早期体验系统并提出改进建议。
灵活性高：每个增量都可以根据用户的反馈进行调整和改进，适应需求变化。
风险降低：通过逐步交付，每个增量都可以作为一个独立的小项目进行评估和测试，能够及早发现问题，减少后期开发的风险。
提升用户满意度：由于开发过程中用户频繁参与，能够更好地满足用户需求，提升用户满意度。
并行开发：增量开发的特点之一是可以并行开发多个模块，适用于开发过程中可以分工明确的项目。

缺点：

前期需求分析较难：虽然增量开发过程强调灵活性，但如果在前期需求分析阶段不充分，也可能导致后续增量的需求不清晰或不一致。
可能导致系统集成复杂：多个增量开发后，最终集成时可能会面临集成困难，尤其是在增量之间依赖较多的情况下。
重复开发的风险：在不同增量中可能存在重复开发的情况，尤其是当需求变化频繁时，可能导致开发资源的浪费。
项目管理复杂性增加：增量模型要求对多个增量进行管理，尤其是当增量之间有较多依赖时，可能会增加项目管理的复杂性。

4.螺旋模型（庞大、复杂、高风险）

（1）定义

螺旋模型是由 巴里·博姆（Barry Boehm） 在 1988 年提出的一种软件开发过程模型。该模型将开发过程看作是一个螺旋形的循环，每个循环都经过一系列的活动，并在每个迭代中进行风险评估、规划和验证。每一次迭代（或称为螺旋圈）都生成一个原型，并逐步完善系统，直至最终完成。

螺旋模型的每个阶段都由以下四个主要部分组成：

目标设定和需求分析：明确当前阶段的目标、需求和约束条件。
风险评估和解决方案设计：识别和分析项目中的潜在风险，评估不同解决方案的可行性，并选择最佳的解决方案。
原型开发和测试：开发系统的原型，并进行测试与验证，获取用户反馈。
评估和规划下一个阶段：根据反馈评估当前阶段的成果，并为下一个阶段制定计划。

（2）特点

迭代式开发：螺旋模型采用多个迭代（循环）开发，每个循环包含需求分析、设计、原型开发、测试和反馈等步骤。每次迭代后都会更新需求和设计，并根据用户反馈和测试结果进行改进。
风险管理：螺旋模型强调风险管理，每个循环都会识别和评估项目中的潜在风险，采取措施解决这些风险。这使得螺旋模型特别适合用于高风险、需求不确定性大的项目。
原型开发：与原型模型相似，螺旋模型通过开发原型来验证需求和设计的正确性，原型的不断迭代能够帮助开发团队在开发过程中逐步完善系统。
用户参与：每个循环结束后，都会获取用户的反馈，这样用户可以持续参与项目的开发，确保最终交付的系统满足需求。
灵活性和适应性：螺旋模型强调持续改进和灵活调整，开发过程可以根据实际情况进行调整和优化。

（3）适用范围

螺旋模型适用于那些需求不完全明确、技术复杂或者存在高风险的项目。特别是在项目需求变化频繁或不确定时，螺旋模型能提供更多的灵活性和风险控制。

适用的项目特点：

需求不完全明确或不稳定的项目：如果项目的需求在开发过程中可能会发生变化，螺旋模型能够逐步开发并不断根据反馈调整需求。
高风险的项目：对于技术复杂、可能存在较大技术风险的项目，螺旋模型能够通过每个迭代的风险评估来降低整体风险。
大型和复杂的项目：适合那些较为复杂的系统，尤其是那些系统功能复杂、对质量要求高的项目。
需要频繁用户反馈的项目：如果项目需要用户频繁参与和验证，螺旋模型非常适合，因为它强调持续的用户反馈和原型测试。
创新性或探索性的项目：适用于那些技术上具有探索性或创新性、无法完全预见需求和解决方案的项目。

（4）优缺点

优点：

强大的风险管理：螺旋模型通过持续的风险评估和管理，能够有效应对项目中潜在的风险，确保项目在开发过程中不偏离轨道。
灵活性高：随着每个迭代周期的进行，需求和设计可以根据反馈进行灵活调整，项目的开发能够很好地适应变化。
逐步交付：每个迭代后都会交付一个可用的原型，用户可以在早期体验系统的部分功能，提早提供反馈。
用户参与性强：由于每个循环都涉及用户反馈，因此用户的参与度很高，可以确保系统更符合用户的需求。
适应性强：螺旋模型可以应对需求不确定性，适用于复杂或创新的项目。

缺点：

过程复杂且耗时：螺旋模型的开发过程较为复杂，需要多次的评估、原型开发和反馈，可能会导致开发周期较长，增加开发成本。
对项目管理要求高：由于螺旋模型包含多个迭代和阶段，因此对项目的管理和协调要求较高，尤其是在团队成员较多、任务较复杂时。
难以掌握成本和时间：由于项目开发周期较长且每个迭代都涉及风险评估、原型开发和反馈收集，难以在项目初期准确预测最终的成本和时间。
可能存在过度开发：由于迭代过程中原型的频繁修改和更新，可能导致开发的内容过度开发，尤其是需求尚不明确时。

5.喷泉模型（迭代、无缝）

（1）定义

喷泉模型是一种基于原型和增量的开发模型，其特点是软件开发过程中的各个阶段（如需求分析、设计、编码、测试等）不是线性进行的，而是通过反复的迭代和反馈来逐步完善系统。该模型的各个阶段可以重叠进行，每个阶段都可以在开发过程中进行改进和更新。“喷泉”的比喻说明了该模型的特性：像喷泉一样，水从中心点喷出，逐渐流向四周，而过程则不断反复进行，阶段之间不完全线性，而是相互交错、不断迭代。

（2）特点

迭代和并行：不同的开发阶段（如需求分析、设计、编码和测试等）不必按照固定的顺序进行。每个阶段可以并行执行，并且不断反复进行，不断改进。
反复的开发过程：在喷泉模型中，需求分析、设计、编码、测试等各个阶段不会一次性完成，而是会循环执行，每个阶段会根据前一轮的反馈和开发结果进行改进和优化。
灵活性高：喷泉模型强调过程的灵活性，允许在开发过程中根据变化的需求调整系统设计和实现。这使得它特别适合需求不稳定或经常变化的项目。
用户反馈驱动：在开发过程中会频繁地收集用户反馈，系统可以根据这些反馈进行调整。这保证了开发的方向更加贴近实际需求。
快速原型：喷泉模型通常会快速生成原型，让用户能够在较早的阶段看到系统的初步效果，并给出反馈。原型开发和需求确认是喷泉模型中的关键组成部分。

（3）适用范围

喷泉模型适用于那些需求不明确或者可能发生变化的项目。它特别适用于：

需求不确定或变化频繁的项目：喷泉模型的灵活性和迭代特点使它适合需求不完全明确或者频繁变化的项目。
小型和中型项目：喷泉模型的快速迭代过程适用于规模较小、开发周期较短的项目，能够通过原型快速展示系统的初步效果并加以调整。
快速开发和原型验证：如果项目需要快速交付可用版本，或者需要进行原型开发以验证需求和设计，喷泉模型非常适合。

（4）开发过程

喷泉模型的开发过程由多个迭代阶段组成，其中每个阶段都可以是并行的，而每次迭代都会在前一次的基础上进行完善。其过程通常包括以下步骤：

需求分析和设计：开始时进行高层次的需求分析，并制定初步设计。这一阶段相对简略，目标是确定系统的基本框架和功能需求。
原型开发：根据初步需求和设计开发一个可用的原型系统。原型的主要目的是验证需求和设计是否符合用户期望。
用户反馈：将原型交给用户，并收集反馈。这些反馈将用于调整系统需求和设计。
功能完善和测试：根据用户的反馈，进一步开发系统，增加新的功能，修改原有设计，进行单元测试和集成测试。
重复循环：这些过程不断重复，每次迭代都改进和完善系统，直到系统功能和质量符合预期要求。

（5）优缺点

优点：

灵活性高：喷泉模型通过反复的迭代和开发，能够快速响应需求变化，非常适合那些需求不确定或经常变化的项目。
快速原型交付：喷泉模型强调早期交付原型，能够让用户尽早看到系统，并提供反馈，从而确保开发方向的正确性。
用户参与：由于每次迭代都需要用户反馈，用户能够持续参与到开发过程中，保证系统的开发更加符合用户需求。
适应性强：在开发过程中可以随时调整方向，满足项目中出现的新需求或变化。
低成本的风险管理：由于开发过程中不断收集用户反馈，能够及早识别潜在的风险并进行调整，避免开发过程中出现重大错误。

缺点：

开发进度难以预测：由于每个阶段可以反复进行，开发进度不容易预估，可能导致项目周期和成本超支。
容易陷入无休止的修改：如果用户的需求变动频繁或不明确，开发团队可能陷入不断修改的循环中，导致项目难以按时交付。
管理复杂性：喷泉模型的多次迭代和反馈可能导致项目管理复杂，尤其是当需求不断变化时，可能很难有效管理项目的进度和资源。
文档不足：喷泉模型中，各个阶段往往交替进行，可能导致项目文档不完善，从而影响后期的维护和升级。