软件工程学概述

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

典型表现：

对软件开发成本和进度估计的不准确性

用户对“已完成”的软件系统不满意的现象经常发生

软件产品质量往往靠不住

软件常常不可维护

软件通常没有适当的文档资料

软件成本在计算机系统总成本中所占的比例逐年上升

软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

​

软件危机产生原因：

与软件本身的负责度有关

软件开发与维护的采用的方法和技术不正确

忽视文档的重要性

消除软件危机的方法：

意识到，程序只是完整软件产品的一个组成部分，软件是程序，数据，相关文档的完整集合

注重团队合作，组织良好，管理严密，各类人员协同配合。

软件工程的特征：

软件工程关注大型程序的构造

软件工程的中心课题是控制复杂性

软件经常变化

开发软件的效率非常重要

和谐合作是开发软件的关键

软件必须有效地支持它的用户

在软件工程领域通常是具有一种文化背景的人替具有另一种文化背景的人创造产品

软件工程基本原理：

用分阶段的生命周期计划严格管理

坚持进行阶段评审

实行严格的产品控制

采用现代程序设计技术

结果应能够清楚的审查

开发小组成员应该少而精

承认不断改进软件工程实践的必要性

软件生命周期：

软件定义

问题定义：通过对客户的调查，系统分析员扼要地写出关于问题性质，工程目标，工程规模的书面报告。经过讨论和必要修改，这份报告应得到客户的确认

可行性研 究：系统分析员进行一次简化压缩的系统分析和设计的过程，研究问题的范围，探索这个问题是否值得解决（对客户而言着重考虑投入与回报的问题），是否有可行的解决方案

需求分析：此阶段确定目标系统必须具备哪些功能。客户通常不能完整准确表达要求，系统分析员必须与用户密切配合，充分交流信息，得出经过用户确认的系统逻辑模型。通常用数据流图，数据字典，简要的算法表述系统的逻辑模型。此阶段的重要任务是，用正式文档准确记录目标系统的需求，又称”规格说明书“

软件开发

总体设计（概要设计）：概要说明如何实现系统，通常至少提出低，中，高成本3中方案，权衡利弊，推荐一个最佳方案，由用户决定。此阶段还有一个主要任务，就是设计程序的体系结构，确定程序由哪些模块组成以及模块间的关系

详细设计（模块设计）：具体化概要设计阶段提出的解决方案，类似工程蓝图，应该包含必要的细节，程序员可以根据他们写出实际的代码。在此阶段将详细设计每个模块，确定实现模块功能所需要的算法和数据结构

编码和单元测试：翻译详细设计，写出正确的容易理解，容易维护的程序模块

综合测试：此阶段的关键任务是通过各种类型的测试时软件达到预定的要求，最基本的测试时集成测试和验收测试。必要时对用户进行培训使用。根据测试结果分析预测软件可靠性。应该用正式文档把测试计划，详细测试方案，详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分

运行维护：通过各种必要维护活动是系统持久满足客户需要

软件过程：为了获得高质量软件所需要完成的一系列任务的框架，共组步骤

瀑布模型：传统软件工程方法学基本上采用该模型，传统瀑布模型过于理想化，实际的瀑布模型是带反馈环的。当后面阶段发现前面阶段的错误，需要返回前面阶段修改。

阶段具有顺序性和依赖性

推迟实现的观点

质量保证的观点：1.每个阶段必须完成规定的 合格的文档。2.每个阶段结束前要对所完成的文档进行评审

优点：可强迫开发人员采用规范的方法，严格规定了每个阶段必须提交的文档；要求每个阶段交出的产品都必须经过质量保证小组的仔细验证

缺点：文档驱动，需求常常是动态变化的。


实际瀑布模型，传统没有反馈环

快速原型模型：第一步先建立一个能反应用户主要需求的原型系统给用户使用，用户反馈修改意见。迭代数次，一旦用户认为原型系统能够完成所需工作，开发人员便据此书写规格说明文档。

优点：基本能做到线性顺序开发。原型要快速，原型系统内部结构不重要。



增量模型（渐增模型）：构件式开发，再协调整体。

优点：1.短时间可交付主要功能 2.逐步增加产品功能，使用户有足够时间学习适应新产品 3.容易维护，开放性好

缺点：前期设计花费时间多，要求开始实现各个构件之前完成全部需求分析



螺旋模型：（常用于内部大规模系统开发）风险驱动，在开发过程中必须及时识别和分析风险，采取适当措施消除或减少风险危害，需要具有丰富风险评估的开发人员



喷泉模型：

Rational统一过程：

敏捷过程：

个体和交互胜过过程和工具

可以工作的软件胜过面面聚到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

极限编程（敏捷过程最富盛名的一个）：

客户作为开发团队的成员

使用该用户素材

短交付周期

验收测试

结对编程

测试驱动开发

集体所有

持续集成

可持续的开发速度

开放的工作空间

及时调整计划

简单的设计：使设计和计划要在本次迭代过程中完成的用户素材完全匹配

重构：在不改变系统行为的前提下，重新调整和优化系统的内部结构，以降低复杂性，消除荣誉，增加灵活性，提高性能。

使用隐喻：整个系统联系在一起的全局视图，描述体统如何工作，以及用何种方式添加新功能到系统

极限编程和整体开发的过程：

项目组针对客户提出的用户故事（用例）进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行试探（提出相关技术难点的试探性解决方案）。

项目组在隐喻和用户故事的基础上，根据客户设定的优先级制定交付计划。

开始多个迭代开发过程（通常每个迭代历时1~3周），在迭代期间产生的新用户故事不在本次迭代内解决。

开发出的新版本软件通过测试验收后交付用户

微软过程基本准则：

项目计划应该兼顾未来的不确定因素

用有效地风险管理来减少不确定因素的影响。

经常生成并快速地测试软件的国度版本，从而提高产品的稳定性和可预测性

采用快速循环，递进的开发过程

用创造性的工作来平衡产品特性和产品成本

项目进度表应该具有较高稳定性和权威性

使用小型项目组并发完成开发工作

在项目早起把软件配置项基线话，项目后期则冻结产品

在使用原型验证概念，对项目进行早起论证

把零缺陷作为追求的目标

里程碑评审会的目的是改进工作，切勿相互指责

微软软件的生命周期：

规划阶段：

确定产品目标

获取竞争对手的信息

完成对客户和市场的调研分析

确定新版本产品应该具备的主要特性

确定相对于前一版本而言，新版本应该解决的问题和需要增加的功能

设计阶段：当完成70%的产品需求分析，进可以进入设计阶段

根据产品目标编写系统的特性规格说明书。这份规格说明书主要描述软件特性，系统结构，各构件间的相关性以及接口标准

从系统高层开始着手进行系统设计，主要完成下述工作：

简明扼要描述整个系统的设计方案

绘制系统结构图

确定系统中存在的风险

分析系统的可重用性

划分出系统中的子系统，给出各个子系统和各个构件的规格说明

根据产品特性规格说明书制定开发计划

开发阶段

稳定阶段：进行测试，发布，重点在真实环境下的使用和操作

发布阶段