面向对象的Java与UML课件Chapter 05-01软件开发生命周期的阶段

• 输入：已构造的系统、业务说明、用例说明 、非功能性需求说明
• 输出：出错报告 or 成功的测试报告
• 方法：
– 业务过程和用例说明用来生成测试剧本
2020/7/30
Figure 5.5 Key inputs and outputs of the testing process
2020/7/30
维护
• 目的：保持系统功能，使之与需求一致
• 输入：代码错误报告 和 修改请求
• 输出：修改的分析、设计与实现
• 方法：
– 帮助台Call Center – 较小的系统改进，系统的后续开发
2020/7/30
5.2 瀑布法
• 瀑布：每一阶段依次进行，直到前面的阶段 结束，下一个阶段才能进行，每一个阶段使 用一个正式的方法来“结束”
面向对象的Java与UML课件Chapter 05－01软件开发生命周期的阶段
5.1 软件开发生命周期的阶段
• 大型IT项目是十分复杂的 • 复杂性的原因：对软件开发过程没有一个全
面、明确的概念
• 本章的目的：给出一个全面的过程和开发路 线图，大家应该注意全面的阶段，和怎样通 过这些阶段开展工作
• 关于软件开发阶段的问题：
• 目的：定义了系统将如何运作，以及对开发 和部署来说，如何把系统分解为可管理的部 分，产生一个系统构架的概要，并且建立基 于该构架的用例图。
• 输入：用例定义集合、对象模型集合、原型
• 输出：对象模型，支持用例的对象协作、对 象分组组成组件、组件与外部系统之间的用 户接口说明，以及数据库存储信息的数据模 型 2020/7/30
• 输入：业务模型、用例模型、原型以及详细 业务运作知识
• 输出：完全专用的用例和详细的对象模型， 确定了系统具有的信息和使用信息的方式
• 方法： 2020/7/30
Figure 5.2 Key inputs and outputs of systems analysis
2020/7/30
系统设计
2020/7/30
5.3.1 迭代方法和用例
• 迭代开发的核心：用例的概念
– 在需求阶段，充分识别用例 – 在系统分析阶段，详述他们 – 在设计和实施阶段，生成一个系统满足所选择的
用例集合 – 如果用例可以独立使用，那么就可以部署系统 – 进行其他用例的开发
2020/7/30
Figure 5.9 The tracing of use cases through the stages in iterative development
• 适用条件：
– 无论正是和非正式开发，都被广泛采用
2020/7/30
Figure 5.7 Depiction of the iterative approach as an expanding spiral of development
螺旋式扩张的系统按功能和质量成长
2020/7/30
Figure 5.8 The iterative approach in terms of stages
– 可能出现的问题：“越严重的问题越晚发现”
• 2输020/7/出30 ：业务模型（外部行为）、用例模型、
Figure 5.1 Key inputs and outputs of requirements analysis
2020/7/30
系统分析
• 目的：定义计算机系统的行为，以及如何与 计算机系统交互，使用被开发人员理解的语 言填写需求分析的细节。
– 统一过程：大量中间产物( Jacobson 1999 ) 20–20/7极/30 限编程：几乎没有阶段和中间产物
软件开发生命周期的阶段
• 每个开发项目都要经历这些阶段，不管是不 是正规，自觉的还是不自觉的
• 这些阶段并不必一个接一个的完成，他们可 以部分重叠及并行完成
– 需求分析 – 系统分析 – 系统设计 – 实现 – 测试 – 部署
• 后果
– 需求变化，产品过时 – 漫长的过程，可能造成信息的丢失 – 这样一个过程的动机
• 适用条件：
20–20/7需/30 求长期不变的情况下，才能采用
Figure 5.6 The waterfall life cycle
2020/7/30
5.3 迭代法
• 迭代法是广泛使用的方法
• 优点
– 如果需求变化，很多内容并不是固定不变的。开 发的系统能够被提前使用，交付系统的反馈可以 在将来的开发中改进
Figure 5.3 Key inputs and outputs of the design process
2020/7/30
实现
• 目的：产生了以组件构成的系统，把系统新 的部分整合到系统先前已构成的部分中去
• 输入：对象模型，对象协作、接口说明、构 架定义，数据模型
• 输出：源代码、编译过的组件、部署计划
2020/7/30
5.3.2 迭代控制方法
• 80/20原则 – 最为常见的功能最先开发
• MoSCoW优先次序 – Must一定要按期交付 – Should希望在本阶段交付 – Could有余下的时间和资源就尽可能将其实现 – Won’t明确在阶段内不交付
• 阶段开发用例表 – 列出了在一个阶段中的开发用例
• 方法：
– 对象模型转化为运行代码和数据库定义 20–20/7C/30 ASE工具部分转化后，再由编程人员完成
Figure 5.4 Key inputs and outputs of the implementatio
• 目的：功能和非功能满足需求，为开发提供 反馈
2020/7/30
需求分析
• 目的：需求分析决定了系统中各种项目相关 者的需要和期望，形成关于系统是做什么的 描述。
– 注意：语言被所有的项目相关者理解，并能对描 述达成一致意见
– 分类
• 功能需求——系统是做什么的 • 非功能需求——可靠性、鲁棒性、使用人数、交互界
面
• 输入： 现有业务过程 ＋ 组织目标
• 时间范围 – 阶段由时间范围控制——某时间段内工作在某个阶段上
2020/7/30
Table 5.1 Moscow prioritization for release of the system
2020/7/30