[管理学]第10章 软件过程的管理实践.ppt

软件过程管理 -Ch.10 软件过程的管理实践 软件过程的管理实践 不同的项目需要不同的方法论，一个项目的最佳过程是这个项目所能负担的最小过程。 ——Alistair Cockburn 本章提纲 10.1 IBM-Rational 业务驱动开发的过程管理 10.2 微软公司的软件开发过程模式 10.3 敏捷模型的软件过程管理 10.4 面向构件的软件过程 10.5 软件过程的自定义体系 10.1 IBM-Rational 业务驱动开发的过程管理 10.1.1 RUP的迭代过程 10.1.2 提高过程的适应性 10.1.3 需求开发和质量改进 10.1.4 架构设计和组件复用 10.1.5 跨团队协作 10.1.6 过程实施的最佳实践 10.1.1 RUP的迭代过程 初始阶段 主要成果是： 前景文档：对核心项目要求、关键性质、前景说明。 初始的项目术语表。 初始的用例模型和商业用例。 项目规划，其中明确阶段和迭代，一个或多个原型。 初始的风险评估和商业模型。 里程碑被评估的准则是： 相关共利益者对项目范围定义和成本/进度估计达成共识。 通过主要的用例将需求无二义地表达出来。 成本/进度估计、优先级、风险和开发过程的可信度。 开发出来的体系结构原型的深度和广度 细化阶段 成果是： 用例模型。 一些增加的需求 可执行的体系结构原型及其描述。 修订后的风险表和商业用例、开发用例，指定要使用的过程。 整个项目的开发计划。 初步的用户手册（可选）。 细化阶段被评估的准则是： 产品的前景是否稳定？体系结构是否稳定？ 可执行的演示是否强调了主要的风险元素，并得到解决？ 构造阶段的规划是否已经足够详细和准确，是否有可信度的评估支持？ 如果用当前的计划来开发整个系统，包括使用已定义的体系结构，是否所有相关共利益者对此都达成一致？ 构造阶段 β版，至少应该包括： 在特定平台上集成的软件产品。 用户手册和对当前版本的描述。 评估准则是： 产品版本是否足够稳定和成熟，可以在用户群中发布吗？ 是否所有相关共利益者都同意产品的发布？ 实际的资源支出和计划的支出的比值是否仍然可接受？ 交付阶段 主要工作有： β测试，确认新系统达到用户的预期。 与被取代的旧系统并行操作，以及功能性数据库的转换。 用户和维护人员培训。 向市场、分销商和销售人员进行新产品的展示。 交付阶段侧重向用户提交软件的活动，评估准则可以非常简单，也可能极其复杂。 用户是否满意？ 是否能够接受实际的和计划的资源支出的比？ 10.1.2 提高过程的适应性 早期开发活动的目标应是找出不确定性，在计划中逐渐提高精确性。 把项目划分为一组迭代过程以交付产品的增量价值来获得早期的、连续的用户反馈。 利用演示和反馈来调整开发计划。 包含并管理变更。 在生命周期尽早发现关键风险，通过不断评估所面对的风险，并在下一次迭代中消除或减少已知的风险。 同步的测试和验证是减少风险的重要手段之一。 10.1.3 需求开发和质量改进 1. 定义并理解业务过程和用户需求 2. 区分项目，需求与软件能力的优先次序 3. 尽早地并且不断地测试 4. 资源的复用 5. 整个团队在整个过程中关注质量 10.1.4 架构设计和组件复用 复用的问题之一是在开发时两个组件需要知道对方的存在。基于标准的接口和独立于平台和具体实现技术的。 软件开发的目标是设计、实现并验证一个架构。 降低复杂度和改善交流的方法是利用高级工具、框架和语言。 逐步建立起测试自动化，更有效地实施持续集成策略。 10.1.5 跨团队协作 自我管理团队的概念，激励团队成员达到最好表现。 鼓励跨职能的合作。 提供有效的合作环境。 集成化的跨业务、软件和运作团队间的合作。 各司其职，积极参与质量工作。 10.1.6 过程实施的最佳实践 起始阶段 细化阶段 构建和发布阶段 10.2 微软公司的软件开发过程模式 10.2.1 MSF的过程模型 10.2.2 MSF的团队模型 10.2.3 MSF过程模型的特点和原则 10.2.4 MSF过程模型的应用 10.2.1 MSF的过程模型 角色和任务 10.2.2 MSF的团队模型 6种基本角色，即程序管理、开发、测试、发布管理、用户体验和产品管理。这些角色和实现特定的关键质量目标有直接的关系，而关键质量目标能否达到是项目成功的标志。所以，MSF 团队模型的核心是技术项目必须符合各种利益相关人的需求。 两种类型的子团队 职能团队是由职能角色组织起来的单领域子团队。开发角色常常有一个或者多个职能团队来承担。 特性团队是跨专业的子团队，把主要精力放在构建解决案的特定特性或者能力上。 原则 10.2.3 MSF的特点和原则 目标驱动而非任务驱动。 外部可见的里程碑。 应提交项的变更管理。 递进的版本