简述瀑布模型、增量模型、螺旋模型(含原型方法)的优缺点。
瀑布模型
优点
- 以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导,保证了阶段之间的正确衔接,能够及时发现并纠正开发过程中存在的缺陷,使产品达到预期的质量要求
- 推迟软件实现,强调在软件实现前必须进行分析和设计工作
- 降低软件开发的复杂程度,提高软件开发过程的透明性,提高软件开发过程的可管理性
缺点
- 强调过程活动的线性顺序
- 缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题
- 风险控制能力较弱
- 瀑布模型中的软件活动是文档驱动的,当阶段之间规定过多的文档时,会极大地增加系统的工作量
管理人员如果仅仅以文档的完成情况来评估项目完成进度,往往会产生错误的结论
增量模型
优点
增强客户对系统的信心
- 降低系统失败风险
- 提高系统可靠性
提高系统的稳定性和可维护性
缺点
增量粒度难以选择
- 确定所有的基本业务服务比较困难
螺旋模型
优点
- 引入了其他模型不具备的风险分析
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
- 成本容易计算
缺点
- 迭代次数不确定
- 不适合大团队
- 无法确定发布日期
简述 UP 的三大特点,其中哪些内容体现了用户驱动的开发,哪些内容体现风险驱动的开发?
- 用例驱动
- 迭代增量过程
- 以架构为中心
用例驱动体现了用户驱动开发。用例是从用户的角度, 用自然语言表达的, 所有利益相关者都应该理解。用例驱动意味着开发团队使用用例从需求收集通过代码和测试。
迭代增量过程体现了风险驱动开发。迭代增量开发有以下优点:(1)逐步趋向稳定(2)有效管理需求变化(3)持续集成(3)尽早接触整个系统(4)在线风险评估
UP 四个阶段的划分准则是什么?关键的里程碑是什么?
初始阶段
确定该系统是可行的。为系统建立业务案例 (Business Case) 并确定项目的边界。
里程碑:生命周期目标里程碑,包括一些重要的文档,如:项目构想 (Vision)、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务案例等。
精化阶段
建立在约束条件下构建系统的能力。分析问题领域,建立健全的体系结构基础,编制项目计划,完成项目中高风险需求部分的开发
里程碑:生命周期体系结构里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。
构建阶段
生成系统的 beta 版本。完成所有剩余的技术构件和稳定业务需求功能的开发,
并集成为产品,详细测试所有功能。
里程碑:初始运行能力 (Initial Operational Capability) 里程碑。包括可以运行的软件产品、用户手册等,它决定了产品是否可以在测试环境中进行部署。
移交阶段
向客户交付功能完备的系统。
里程碑:产品发布里程碑。确定最终目标是否实现,是否应该开始产品下一个版本的另一个开发周期。
IT 项目管理中,“工期、质量、范围/内容” 三个元素中,在合同固定条件下,为什么说“范围/内容”是项目团队是易于控制的?
在合同固定的条件下,对于工期和质量都在合同中有十分明确的规定,但是对于范围/内容的规定就相对没有十分严苛,所以范围/内容是项目团队易于控制的。
为什么说,UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据?
UP 是一个通用的过程模板,包含了很多开发指南、工件、开发过程所涉及到的角色说明等,具体应用时按照需要做裁剪。
① 确定本项目需要的工作流程;
② 确定每个工作流需要的工件;
③ 确定4个阶段之间的演进计划。以风险控制为原则,决定每个阶段实施的工作流,每个工作流的执行程度,生成的工件及其完成程度等;
④ 确定每个阶段内的迭代计划。规划 UP 的4个阶段中每次迭代开发的内容;
⑤ 规划工作流内部结构。用活动图 (Activity Diagram) 规划工作流中涉及的角色、角色负责的活动及产出的工件。
正是因为UP的模板清晰明确地规定了在开发过程中的任务,所以UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据。
使用截图工具(png格式输出),展现你团队的任务 Kanban,请注意以下要求
每个人的任务是明确的。即一周后可以看到具体成果
每个人的任务是1-2项。
至少包含一个团队活动任务