第一章 软件工程概述

    1.1 软件危机

            软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重的问题。可概括为以下两个方面：

1. 如何开发软件，以满足对软件日益增长的需求；
2. 如何维护数量不断膨胀的已有软件。

            典型表现：

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

            1983年IEEE为软件下的定义：计算机程序、方法、规则、相关的文档资料及计算机上运行程序时所必需的数据。

 

    1.2 软件工程

            概述：软件工程时指计算机软件开发和维护的一门工程学科。

                        软件工程是包括技术和管理两方面的内容，是技术与管理结合所形成的工程学科。

            1.2.1 软件工程具有的本质特性：

1. 软件工程关注于大型程序的构造；
2. 软件工程的中心课题是控制复杂性；
3. 软件经常变化；
4. 开发软件的小笼包非常重要；
5. 和谐的合作是开发软件的关键；
6. 软件必须有效的支持他的用户；
7. 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品。

            1.2.2 软件工程原理：

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

 

1.3 软件生命周期

            软件生命周期由软件定义、软件开发和软件维护3个时期组成，每个时期又可进一步划分成若干阶段。

            软件定义时期的任务是：确定软件工程必须完成的总目标；确定工程的可行性；导出实现工程目标应采用的策略及系统必须完成的功能；估计完成该项目工程需要的资源和成本，并且制定工程进度表。这个时期的工作，通常称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分为3个阶段，即问题定义、可行性研究、需求分析。

            开发时期具体设计和实现在前一个时期定义的软件，他通常由下述4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。

            维护时期的主要任务是使软件持久地满足用户的需要。具体地说，软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新需求时应该及时改进软件以满足用户的新需要。需要团队维护时期不在进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。软件

软件生命周期

软件定义时期	1. 问题定义               「要解决的问题是什么？」 2. 可行性研究          「对于上一个阶段所确定的问题有行得通的解决办法吗？」 3. 需求分析              「为了解决这个问题，目标系统必须做什么」
软件开发时期	4. 总体设计              「概括地说，应该怎忙实现目标系统？」 5. 详细设计              「应该怎样具体的实现这个系统呢？」 6. 编码和单元测试 「写出正确的、容易维护的程序模块，并仔细测试编写出的每一个模块」 7. 综合测试              「通过各种类型的测试及相应的调试，使软件达到预定的要求」
软件维护时期	8. 软件维护             「通过各种必要的维护活动使系统持久的满足用户的需要」

 

1.4 软件过程

        软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。概括地说，软件过程描述为了开发出客户需要的软件，什么人（who）、在什么时候（when）、做什么事（what）以及怎样做（how）这些事以实现某一个特定的具体目标。

        1.4.1 瀑布模型

        使用的最早，应用得最广。

图1.1

图1.2

        特点：

1. 阶段间具有顺序性和依赖性
   1. 必须等前一个阶段的工作完成之后，才能开始后一阶段的工作；
   2. 前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
2. 推迟实现的观点
   1. 越早开始编程，后期更改需求的概率越大，所花费的代价也越大
3. 质量保证的观点

        优点：提高软件质量，降低维护成本，环节软件危机。

        缺点：模型缺乏灵活性，无法解决需求不明问题。用户不经过实践提出完整准确需求不切实际。

 

        1.4.2 快速原型模型

        快速建立反映用户主要需求的原型系统，反复由用户评价修正需求开发出这种产品。

图1.3

        优点：确定需求上优于瀑布模型(通过原型与用户交互)；提供学习手段，通过开发原型和演示原型对开发者和使用者了解系统都有积极作用，有的软件原型可以成为最终产品的一部分。

        缺点：快速建立的系统结构加连续修改可能导致产品质量低下，学习系统的内部结构可能不好。

        1.4.3 增量模型

        又称为渐增模型，开发软件时将软件产品作一系列增量构件设计、编码、集成和测试。

图1.4

图1.5

        区别于瀑布模型和快速原型模型：

        瀑布和快速原型模型是一次把满足所有需求产品提交给用户。增量模型，是分批向用户提交产品。

        优点：短时间向用户提交可以完成有用工作的产品；用户有充裕时间学习适应产品；软件结构必须开放，方便现有产品加入新构件。

        缺点：做到第三个优点比较困难。

        1.4.4 螺旋模型

螺旋模型的基本思想是：使用原型及其他方法来尽量降低风险。理解这种模型的一个简单方法，是把它看作在每个极端之前都增加了风险分析过程的快速原型模型。

笛卡尔坐标四象限表达四方面活动：

• 制定计划：确定目标、选定方案、设定约束条件。
• 风险分析：评估方案，识别和消除风险。
• 实施工程：软件开发
• 客户评估：评价开发工作，计划下一阶段工作。 

沿螺线自内向外每旋转一圈开发出更完善新版本。

        优点：大型软件开发项目由较好的风险控制；

        缺点：需要风险评估经验；契约开发通常需要事先指定过程模型和发布产品；普及不如前述模型；周期较长。

图1.6

        
        1.4.5 喷泉模型

        优点：无缝，可同步开发，提高开发效率，节省开发时间，适应面向对象软件。

        缺点：可能随时加各种信息，需求和资料，需严格的文件管理，审核难度加大。

图1.7

        1.4.6 Rational统一过程敏捷过程与极限编程

。。。

        1.4.7 敏捷过程与极限编程

。。。
        1.4.8 微软过程

        微软过程遵循下述的基本准则：

• 项目计划应该兼顾未来的不确定因素。
• 用有效的风险管理来减少不确定因素的影响。
• 经常生成并快速地测试软件的过渡版本，从而提高产品的稳定性和可预测性。
• 采用快速循环、递进的开发过程。
• 用创造性的工作来平衡产品特性和产品成本。
• 项目进度表应该具有较高稳定性和权威性。
• 使用小型项目组并发地完成开发工作。
• 在项目早期把软件配置项基线化，项目后期则冻结产品。
• 使用原型验证概念，对项目进行早期论证。
• 把零缺陷作为追求的目标。
• 里程碑评审会的目的是改进工作，切忌相互指责。

图1.8