14
1 软件、软件工程
软件生命周期模型 -- 增量模型
下一增量开发
定 确定 义 增量 需 内容 求 及其 框 优先
架级
设计 系统 体系
结构
增量开发
增量分析 增量设计 增量实现 测试 增量集成
下一增量内容的确定
用户使用增量产品 提出反馈意见：修
改、补充需求
和用户沟通探索下 一增量内容的初步
需求
系统
确认 测试 和用 户验 收测
特 等组成的，它只是一种态度，不是一个说明性过程 。
点
AM是对已有生命周期模型的补充，它本身不是一个完整的方法论，在 应用传统的生命周期模型时可以借鉴AM的过程指导思想 。
21
1 软件、软件工程
软件生命周期模型 -- 敏捷模型
1
个人和交互胜过过程和工具
响应变化胜过遵循计划
4
价值观
2
客户合作胜过合同谈判
验收完后，进行 的需求开发、设 计、编码和测试 活动
可能某个阶段的 的工作由客户完 成
6
1 软件、软件工程
软件生命周期/模型
软件 生命周期
同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、 成熟、衰亡等阶段，一般称为软件生命周期（Life Cycle）。
为了使规模大、结构复杂和管理复杂的软件开发变的容易控制和管理，人们把 整个软件生命周期划分为若干阶段，使得每个阶段有明确的任务，整理出软件 生命周期模型。
系统和软件需求分析
系统和软件需求 V&V，系统测试准备
概要设计
概要设计V&V 组装测试准备
详细设计
详细设计V&V 单元测试准备
交付
验收测试
部署 组装
系统测试 组装测试
单元测试
编码
1 软件、软件工程
软件生命周期模型 -- 快速原型模型
原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的
软件系统原型，满足用户的基本要求。
19
1 软件、软件工程
软件生命周期模型 -- 螺旋模型
优点
• 提高系统质量 • 降低项目风险；
缺点
• 难于管理 • 只适合于大风险大型复杂软件项目 • 软件开发人员要擅长风险分析
20
1 软件、软件工程
软件生命周期模型 -- 敏捷模型
沟通
简单
态度
勇气
反馈
谦逊
敏捷建模（Agile Modeling，AM）是由Scott W. Ambler从许多的软 件开发过程实践中归纳总结出来的一些敏捷建模价值观、原则和实践
软件项目流程培训
仅代表个人观点，欢迎讨论指点，请勿做商业用途
1
主讲人：**** ---------------------------------
职位：*********
2
培训内容导航
1 软件、软件工程
软件、软件工程、项目类型、生命周期
2 大家眼中的软件项目流程
众人的软件流程整合
3 标准的软件项目流程
CMMI、标准的软件项目流程
4 公司的软件项目流程
公司的人员、职责、软件项目流程
5 提问
学员回答培训相关问题、学员向培训师提问
3
1 软件、软件工程
软件
计算机系统中与硬件相互依存的另一部分，它是程序、文档的完整集合
其中：
程序是按实现设计的功能和性能要求执行的指令序列 文档是程序开发、维护使用有关的图文材料（例如用户手册、帮助文档等）
1 软件、软件工程
软件生命周期模型 -- 瀑布模型的改进 -- V 模型
制定计划 用户需求获取 系统和软件需求分析 概要设计 详细设计
编码
验收测试 系统测试 组装测试 单元测试
1 软件、软件工程
软件生命周期模型 -- 瀑布模型的改进 -- W 模型
制定计划 用户需求获取
用户需求V&V 验收测试准备
7、当所有 Story 完成，召开演示会议 1）我们要进行演示会议（Srpint Review Meeting），也称为 评审会议，产品负责人（需求提出者）和客户都要参加， 最好本公司老板也参加。 2）每一个开发成员都要向他们演示自己完成的软件产品 （这个会议非常重要，一定不能取消）；
每日站立会议： 每次会议控制在 15 分钟左右，每个人都必须发言， 并且要向所有成员当面汇报你昨天完成了什么，并 且向所有成员承诺你今天要完成什么，同时遇到不 能解决的问题也可以提出。
如何确定本次迭代要完成的 Srory？ 例如迭代周期一个月 20 个工作日，开发人员和测 试人员一共 10 人，那么确定要开发的 Story 总工 作量不能超过 20*10=200 人天，一般留出一部分 时间来做其他的事情，例如会议等，所以列入开 发范围的总工作量可以打个折，例如 170 人天。 （等历史项目的数据积累后，可以更好的决策这 个打折打多少）
实用的软件胜过面面俱到的文档
3 22
1 软件、软件工程
软件生命周期模型 -- 敏捷模型
敏捷开发
1、 需求来源：Backlog（待办库） 1）每个人都可以新增条目到待办库。 2）条目的类型可以是新需求（定义为 Story），也可以是 BUG（测试人员，或开发人员发现的问题）。 3）排序（RANK）很重要，决定条目被开发的优先顺序。 一般有人定期去调整这个顺序。 4）需求人员有新需求加进来，要定期告诉所有人。
软件 生命周期
模型
在整个软件开发的发展过程中，为了要从宏观上管理软件和开发和维护， 而对软件的发展过程进行归纳总结的软件生命周期的典型实践参考。
7
1 软件、软件工程
常见的软件生命周期模型
瀑布模型（V模型、W模型） 快速原型模型 增量模型
迭代模型 螺旋模型 敏捷模型
8
1 软件、软件工程
4
1 软件、软件工程
软件工程
英文名Software Engineering，是一门研究用工程化方法构建和维护有 效的、实用的和高质量的软件的学科。
它涉及到程序设计语言、数据库、软件开发工具、设计模式等方面。
目前比较认可的一种定义认为：
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去 开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能 够得到的最好的技术方法结合起来。
4、开发人员给出计划完成时间 1）开发人员计划出自己负责的每个 Story 的计划完成时间， 并提交给测试人员，方便测试人员安排测试计划。
5、开发人员开始编码 1）过程中，需要进行每日站立会议（Daily Scrum Meeting）， 会议要求如右图 2）每日站立会议后，每个人要更新看板（看板的定义如右图） 的任务状态和燃尽图（Sprint burn down） 3）过程中，版本负责人（项目经理）负责监控一个迭代，也就是每天都要有一个可以成功编译、 并且可以演示的版本
第二次 功能 C 增量 功能 D
需求 …
测试
第三次 增量
…
…
第一次 迭代
功能 A 功能 B 功能 C
需求 … 测试
第二次 迭代
细化功能A 细化功能B 细化功能C
需求 … 测试
第三次 迭代
…
…
第一次 迭代
（计划风评实施客评）
第二次 迭代
（计划风评实施客评）
计划
全部功能： 需求 功能 A 功能 B 设计 功能 C 功能 D 开发
缺点
• 整个的模型几乎都是以文档驱动的 ，这对于非专业的用户来说是难以 阅读和理解的。
• 无法解决软件需求不明确或不准确 的问题。很多的问题在最后才会暴 露出来，风险是巨大的。
• 当阶段之间规定过多的文档时，会 极大地增加系统的工作量。
• 开发者常常被不必要地耽搁。在项 目的开始和结束阶段会造成阻塞。
3、任务分解 1）开发人员各自回去进行 Story 分解，形成更细化的任务。 2）细到每个任务的工作量在 2 天内能完成
工作量评估方法： 开发人员、测试人员每人手上都有一套“计划纸牌” （每张纸牌代表不同的人天数），评估一个 STORY 的时候，所有参与评估的人员都同时举起一张纸 牌，采取少数服从多数和取中间值的原则，如果 A 和 B 两人的评估相差太大，则 A 和 B 分别表达观 点，重新讨论后重新评估。
2、 任务的估算与指派：计划会议（Plan Meeting） 1）全员参与，包括需求、开发、测试。 2）首先，会议上需求人员先进行 Story 的讲解 3）所有人对 Story 进行逐个评估工作量（评估方法如右图）， 每个 Story 的估算包含了开发和测试的时间。 4）根据迭代周期确定可完成的 Story（确定方法如右图）， 具体由 Story 的优先级，工作量，团队能力和版本时间 这些因素来决定。 5）开发人员开始挑选任务，一般让资历低一点的先挑。
个人总结：
要开发和维护一个软件，不仅需要最好的技术，还需要使用过程化的方法和 正确的管理。
5
1 软件、软件工程
项目类型
产品
合同项目
内部自用项目 维护项目
外包项目
自有产品的研发 ，对于需求要增 加市场调研报告 ，可行性分析报 告
具备完整生命周 期模型（从售前 到验收）
自主开发的项目 ，提供给公司内 部员工使用的， 满足公司的信息 化管理需求
软件生命周期模型 -- 瀑布模型
特 通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。 点 每个阶段经过严格的评审和测试。
每个阶段的结束和所有产品都要经过SQA审核同意。
1 软件、软件工程
软件生命周期模型 -- 瀑布模型
优点
• 提高了软件开发过程的透明性和可 管理性。
• 文档驱动型，便于产品的维护