软件工程与课件-SE02.ppt

SoftwareEngineering主要内容软件生命周期瀑布模型快速原型增量模型极限编程螺旋模型RUP2.1软件生命周期《计算机软件开发规范》（GB8566－8），软件生命周期包含：软件定义、软件开发、软件运行维护三个时期，并可以细分为可行性研究、项目计划、需求分析、概要设计、详细设计、编码实现与单元测试、系统集成测试、系统确认验证、系统运行与维护等几个阶段。软件定义期要开发什么样的软件？软件任务立项（项目立项报告）项目可行性分析（可行性分析报告）制定项目计划（软件项目开发计划）软件需求分析（软件需求规格说明书）以用户需求为基本依据，从功能、性能、数据、操作等多个方面，对软件系统给出完整、准确、具体的描述，用于确定软件规格软件开发期软件概要设计（概要设计说明书）软件系统的结构设计，用于从总体上对软件的构造、接口、全局数据结构和数据环境等给出设计说明模块是概要设计时构造软件的基本元素，概要设计中软件也就主要体现在模块的构成与模块接口这两个方面，主要以模块的内聚、耦合性两个指标来进行评价软件开发期（续）详细设计（详细设计说明书）概要设计为依据，用于确定软件结构中每个模块的内部细节（程序算法和模块内部的局部数据）编码和单元测试（带注释的源代码）编码必须按照“详细设计说明书”的要求逐个模块地实现基本模块的单元测试也往往和编码结合在一起进行软件开发期（续）软件系统集成测试（测试报告）软件系统组过程中，需要对整个软件系统进行集成测试，以确保软件系统在技术上符合设计要求，在应用上满足需求规格要求软件系统确认验证（项目开发总结）以用户为主体，以需求规格说明书中对软件的定义为依据，由此对软件的各项规格进行逐项地确认软件运行与维护期软件不断进化升级的过程，以使软件系统更加持久地满足用户的需要改正性维护适应性维护完善性维护2.2建造－修补模型“边做边改”模型建造－修补模型（续）优点可以用于探索某个函数或类的用法缺点：不能用于实际的软件开发对没有规格说明和设计文档的产品进行维护相当困难，而且发生回归错误的可能性也相当大从整个软件过程来说，特别是考虑到维护阶段的情况，实际上建造－修补模型的花费远远大于有正规的规格说明、经过详细设计的产品所需要的花费2.3瀑布模型是其它开发模型的源头瀑布模型将软件生命周期划分为需求分析、规格说明、软件设计、程序实现、软件集成和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落瀑布模型（续）第一个投入实际开发的有效模型，瀑布模型的成功主要得益于强制性原则：阶段产品与文档确认之前不进入下一个阶段，每个阶段必须经过软件质量保证（SoftwareQualityAssurance，SQA）小组的评审文档驱动原则：瀑布模型强调文档必须与产品同步，开发过程中和每个阶段的结束都要求有规范的文档瀑布模型（续）缺点：由于文档驱动原则，客户只能在整个产品完成编程之后才首次能够看到工作的产品，规格说明文档只存在于纸面上，客户因而不能真正理解产品本身会是什么样子（软件的不可见性）开发过程只能按阶段顺序向下进行，发现错误只能逐级回溯,为避免回溯错误，每个阶段修改后必须重新评审，其进度有可能被严重拖延，最终导致成本和质量的失控2.4快速原型开发模型使用瀑布模型，客户与开发人员对于需求的不同理解是造成软件开发失败的最大因素，如果能够在正式开发前在需求方面达成一致可有效地提高客户的满意度和软件的可用性，快速原型开发模型正是基于这样的思想而设计的快速原型开发模型（续）优点产品的开发基本上是线性的，最大程度避免回溯开发进度快：正式设计和编程前做了大量的沟通和准备工作，在开发过程回溯较少，因此整体上提高了开发的速度缺点需求人员和客户确定的展示性原型可能不利于设计人员的创新（应该只用做需求获取工具，第3章详述）2.5增量模型产品以一系列增量构件的形式设计、实现、集成和测试，每个构件（Builds）由一些代码块组成，这些代码块来自多个相互作用的模块，完成特定的功能在增量模型的每一个阶段，编写出一个新构件的代码后，集成到已完成的软件中，作为一个整体进行测试，当产品达到功能目标时，即满足了规格说明后，这个进程停止举例：文字处理系统的开发2.6极限编程增量模型的一种扩展主要特征根据效益分析，确定软件需求测试驱动成对编程每日构建极限编程基本要求极限编程小组的计算机设置在一个大房间中，大房间中有许多彼此相连的小隔间，保证程序员之间能有顺畅的交流一个客户代表始终和极限编程小组一起工作