软件工程导论 第1章 软件工程学概述.ppt

* 1988年，Barry Boehm正式发表了软件系统开发的“螺旋模型”。 * * * 径坐标(radial dimension)：迄今累积的成本 角坐标(angular dimension)： 螺旋形的进展，螺旋的每一圈对应一个阶段 螺旋模型沿着螺线旋转，在笛卡尔坐标的四个象限上分别表达了四个方面的活动 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件 风险分析：分析所选方案，考虑如何识别和消除风险 实施工程：实施软件开发 客户评估：评价开发工作，提出修正建议 沿螺线自内向外，每旋转一圈便开发出更为完善的一个新的软件版本 例如，在第一圈，确定了初步的目标、方案和限制条件以后，转入右上象限，对风险进行识别和分析。如果风险分析表明，需求有不确定性，那么在右下的工程象限内，所建的原型会帮助开发人员和客户，考虑其它开发模型，并对需求做进一步修正。客户对工程成果做出评价之后，给出修正建议。在此基础上需再次计划，并进行风险分析 在每一圈螺线上，风险分析的终点做出是否继续下去的判断。假如风险过大，开发者和用户无法承受，项目有可能终止。多数情况下沿螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。 * * …敏捷开发… 价值观 个体和交互胜过过程和工具【先构建团队，再配置环境】。 可以工作的软件胜过面面俱到的文档【迫切需要时，简明扼要】。 客户合作胜过合同谈判。 响应变化胜过遵循计划【计划必须有足够的灵活性和可塑性】。 …敏捷开发… 极限编程(XP)是在增量模型基础上发展起来的一种颇有争议的新的软件开发方法 确定客户希望产品支持的各种特性(情节,Stories ) 客户使用成本-效益分析方法选择每个后续的构件所应包含的特性 每一个构件被分成更小的部分，成为任务(tasks) 程序员首先制定出一个任务的测试用例 成对编程(pair programming) 把任务集成到产品的当前版本中 …敏捷开发… 极限编程的特点 XP小组的计算机设置在一个大房间的中心，大房间中有许多彼此相连的小隔间 一个客户代表一直与XP小组一起工作 没有一个人能够连续两周超时工作 没有规格说明，而是XP小组的所有成员一同完成规格说明、设计、代码和测试过程 重整(refactoring)：建造产品的过程中不断地调整设计 …敏捷开发 极限编程模型评价 XP 在一些中、小规模的项目上取得了成功 XP的长处在于当客户的需求模糊或经常改变时很适用 XP还没有得到充分的应用，不足以确定它是否能够兑现它早先的承诺 各种生命周期模型的比较 生命周期模型 优点 缺点 瀑布模型 文档驱动的有序方法 交付产品可能不符合客户的要求 快速原型模型 确保交付的产品符合客户的要求 还没有证明无懈可击 增量模型 增大投资的早期回报 要求开放的结构，可能退化为建造-修补模型 极限编程 增大投资的早期回报，客户的需求模糊时能很好地工作 还没有被广泛使用 螺旋模型 结合上述所有模型的特性 只能用于大型的内部软件产品，开发者必须精通风险分析和风险排除 小结 不同的生命周期模型有自己的优点，也有自己的不足 选择生命周期模型的标准为 组织 组织的管理 雇员的能力 具体产品的特性 最好的建议 “Mix-and-match” 生命周期 * * * * 将在第2~3，5~8章中详细介绍。 结构化分析详细见第二章补充知识。 * * * * * * * 据统计，软件维护占整个软件生存周期总工作量的10%至70%不等，由此可见软件维护的重要性 。 （1）改正性维护(占 17%～20%)：改正在特定的使用条件下软件中暴露出来的错误与缺陷，这些错误或缺陷在测试时并未被发现 ； （2）适应性维护(占18%～25% ) ：使软件产品能够适应变化了的运行环境，如操作系统版本的升级、机器配置的变化、软件使用对象的变化等； （3）完善性维护(占50%～60% ) ：为适应用户对软件功能、性能或接口方面提出的新要求以使产品更加完善与合理而进行的修改； （4）预防性维护(占4%左右) ：提高产品的可靠性和可维护性，减少今后维护的工作量，有利于系统和进一步改造或升级换代而进行的维护。 * * * 掌握瀑布模型 掌握快速原型开发模型 了解增量模型 掌握螺旋模型 了解极限编程 了解RUP * 1970年由Royce首先提出，如图所示。 20世纪80年代初，唯一被广泛接受的生命周期模型。 验证：在该阶段的文档已经完成并且该阶段的产品得到软件质量保证SQA（Software Quality Assurance）小组的认可。 反馈环：如果开发者需要在设计期间修订规格说明文档，则软件生产过程需要这个反馈环。 * 设计中的缺陷可能在实现期间显示出来。 例子1：一个实时系统的设计可能在实现时显示出