软件工厂最佳项目实践模型
本文选材自
Sundy的《软件工厂最佳项目实践模型》并稍作整理，侵权删！
软件工厂生产的原则特征
本模型描述了软件工厂的最佳实践方式。它本身也是一套有效的部署经验验证的商业化软件的开发方法。之所以称为“最佳实践”，不仅仅是因为他们具有可以量化的价值，并且被许多成功的机构、成功的项目所运用，并且在Sundy的十年开发生涯中不断积累的结果。
为了使软件工厂整个团队有效利用最佳实践模型，我们为每个团队成员提供了必要的准则、工具和模板。并且明确指出软件工厂的原则特征：
1. 迭代的开发软件
2. 开发与质量控制双线并行
3. 量化可追溯的需求管理
4. 使用基于构建的体系结构
5. 标准且可视化的软件建模
6. 验证每一个步骤
7. 控制变更
一、迭代的开发产品
面对当今复杂的软件系统，使用连续的开发方法：如首先定义整个问题，设计完整的解决方案，编制软件并最终测试产品，是不可能的。需要一种能够通过一系列细化，若干个渐进的反复过程而生成有效渐进方案的迭代方法。通过软件工厂的迭代方法，极大地减少了项目的风险性。迭代方法通过可验证的方法来帮助减少风险---经常性的，可执行版本使最终用户不断的介入和反馈。因为每个迭代过程可执行版本中，开发队伍停留在生产结果上，频繁的状态检查帮助确保项目按时进行迭代化方式同样使得需求，特色，日程上战略性的变化更为容易。
二、开发与质量控制双线并行
软件测试，或者称之为质量控制(QC)，不再是软件开发过程中的一个环节，而是贯穿软件开发整个生命周期的流程。在如今质量为先导的软件开发思路面前，测试已经不局限于单纯的验证某个模块，某个系统与需求的一致性。而是从初始化阶段就积极主动的把握质量关口。因此看来，质量控制是与开发过程同等重要的流程。甚至还是开发流程的把关流程。双线并行，早已经是我们所期待的了。软件工厂对此作出了明确定义。
三、量化可追溯的需求管理
软件工厂详细描述了如何提取，组织和文档化需要的功能和限制：跟踪和文档化折中方案和决策：捕获和进行商业需求交流。过程中用例和场景的使用被证明是捕获功能需求的卓越办法，并确保由它们来驱动设计，实现和软件的测试，使最终系统能够满足最终用户的需要。它们给开发和发布系统提供了连续的和可跟踪的线索。
四、使用基于构建的体系结构
该过程在全力以赴开发之前，关注与早期的开发和健壮可执行体系结构的基线。它描述了如何设计灵活的、可容纳修改的、直观便于理解的，并且促进有效软件重用的弹性结构。软件工厂要沉淀基于构件的软件开发。甚至于沉淀出构件工厂。要知道构件是实现清晰功能的模块、子模块。软件工厂根据构件工厂提供各种现有构件并且与之系统化，为之后的项目迭代做好关键准备。真正实现工业级重构。
五、标准且可视化的软件建模
开发过程显示了对软件如何可视化建模，捕获体系结构和构件的架构和行为。这允许你隐藏细节和使用“图形构件块”来书写代码，保持设计和实现的一致性，促进明确的沟通。软件工厂利用Rational的UML进行成功而又标准的可视化软件建模。
六、验证每一个步骤
拙劣的应用程序性能和可靠性，不断延期的进度是软件生产失败过程中的主因。软件工厂指定了每个步骤的阈值，对每个步骤进行验证。过程评估被内建于过程，所有的活动包括全体成员，使用客观的度量和标准，而不是事后型来检讨责任。每一个步骤都明确完成才进入后续的开发。
七、控制变更
管理变更的能力。确定每个修改是可接受的、能被跟踪的。在变更不可避免的环境中是必须的。开发过程描述了如何控制、跟踪和监控修改以确保成功的迭代开发。它同时指导如何通过隔离修改和控制整个软件产物(例如：模型，代码，文档)的修改来为每个开发者建立安全的工作区。另外，它通过描述如何自动化集成和建立管理使小队如同单个单元来工作。
软件工厂生产的动态阶段
RUP迭代开发过程
这张图大家都知道，是RUP迭代开发模型图。在软件工厂看来，这个是不完整的。
V模型
这张图，大家或许也知道，这是迭代式测试过程的V模型。就软件工厂看来，它也是不完善的。
软件工程厂提出了W双线生产模型，如下图：
W模型
由W模型图可知，软件工厂项目生产过程包括两个主要过程：开发和质量控制
二者之间是相互独立又是息息相关密不可分的。
开发阶段从设计到实现是个逆向过程。前者是自顶而下；后者是自底而上。同样，质量控制阶段从设计到实现也是个逆向过程。前者是自顶而下；后者是自底而上。
开发阶段与质量控制阶段又是一一对应的。例如需求分析完成后，质量控制也可以完成验收测试设计。
质量控制阶段又隐含着对开发阶段的审核。开发阶段大部分过程的审核皆由控制部门来实现。
一、开发阶段
项目评估
项目评估阶段的目标是：评估项目的级别、风险，项目需要投入的资源，并且出可行性方案
本阶段是非常重要的阶段，就是项目的基石。若项目评估未通过，则直接不再继续下面的步骤，并且反馈给相关人。若项目评估通过，则需要确立项目的级别，项目组织结构，项目从属事项等。这个阶段关注的是项目中进行工程的业务和需求方面的主要风险。对于建立在原有系统上的开发项目来说，项目评估阶段的时间可能很短。
目标：
- 明确客户各个阶段使用目标以及软件的基本架构
- 估计出潜在的风险
- 评估项目使用的人力、财力、物力等资源
- 对整个项目做最初的项目成本即日程估计
- 确立软件项目立项是否可行
产出：
- 项目评估表
- 项目立项书(若通过评估)，包括业务上下文，验收规范，成本预计等
- 原始核心需求文档(客户提供)
- 项目计划V1(概要)
里程碑：
- 就是否参与这个项目已经定论
- 项目级别已经定论
- 项目投入资源以及主要风险承担者已经定论
- 风险承担者就范围定义，成本/日程估计达成共识
- 项目开发环境搭建完成
如果无法通过这些里程碑，则项目可以被取消或者仔细地重新考虑
阶段评审的工作和需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 项目评估表 | PS(Project Senate) | 完成 |
| 项目立项书 | PS(Project Senate) | 完成 |
| 原始需求书 | PM | 具备 |
| 项目计划V1(包含项目开发计划，项目测试计划) | PM PDM PTM | 完成项目计划的第一个版本，也就是概要版本，不细化到具体的人员分配和具体功能细节。 |
| 开发服务器及开发环境 | SE(Support Engineer) | 完成或者确立 |
| 项目管理服务器及管理环境 | SE(Support Engineer) | 完成或者确立 |
| 项目仓库框架 | SE(Support Engineer) | 完成 |
| 责任人确立 | PS(Project Senate) | 确立项目经理，开发经理，测试经理以及项目外的干系人(客户方代表)选 |
| 用户接口原型(可选) | UID(UI Designer) | 主要是界面原型 |
需求分析
项目需求分析需要达到的目标是明确分析客户的需求，并且量化成需求分析设计文档。以达到确立商业用例及系统边界的目的。
为了达到该目的，必须对系统具有“英里宽和英寸深”的现象。体系结构的决策必须在理解整个系统的基础上作出：它的范围，主要功能和性能等非功能性需求。
项目需求分析阶段是项目成功细化的关键保障。我们对需求的确立也是我们后面阶段工作的前提保障。常用的一句话：“正确的需求才有正确的软件”。
目标：
- 自顶而下明确客户系统模块划分
- 明确80%客户系统的商业用例
- 明确角色分配以及流程走向
- 使用UML用例量化需求，完成需求报告
产出：
- 蓝图文档：核心项目需求，关键特色，主要约束的总体蓝图
- 原始用例模型(完成80%)
- 原始项目术语表
- 原始商业案例，包括业务的上下文，验收规范，成本预计
- 原始的风险评估
- 一个或多个原型
里程碑：
- 风险承担者就范围定义，成本/日程估计达成共识
- 以客观的主要用例证实对需求的理解
- 成本/日程，优先级，风险和开发过程的可信度
- 被开发体系结构原型的深度和广度
- 实际开支与计划开支的比较
如果无法通过这些里程碑，则项目可能被取消或者仔细地重新考虑
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 需求分析图UML | PDA(Project Demand Analyst) | 完成 |
| UI原型 | UID(UI Designer) | 模型覆盖率100% |
| 需求分析报告(可选) | PDA Leader | 具备 |
| 项目计划V2(需求阶段的详细计划及执行情况) | PDA | 细化到需求阶段的每日工作量和人员分配 |
| 客户沟通记录及确认签字 | PDA,Customer | 每次沟通的记录表以及客户签字确认 |
概要设计
项目概要设计阶段主要是指根据业务用例和用户需求所做的架构设计，我们也称之为系统设计。这部分即包括设计的描述(画出设计图)，也包括设计的实现(编码实现)。而概要设计也是项目的骨架搭建，关注与接口之间的端对端关系
目标：
- 完成概要设计图
- 明确模块以及模块之间的接口定义
- 覆盖原型的所有主要功能模块
产出：
- 概要设计图
- 概要设计书(可选)
- 项目框架代码，接口定义代码
里程碑:
风险承担者对目前的项目框架方案达成一致
架构设计基本完成
模块与接口设计完成
需求不断迭代确立
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 概要设计图UML | AD(Architecture Designer) | 完成 |
| 概要设计书(可选) | ||
| DBMS实现 | ||
| 项目计划V3(架构设计阶段) | PDA | 细化到概要设计阶段的每日工作量和人员分配 |
| 概要设计评估表 | PS | 通过 |
| 概要设计代码实现 | AD | 实现代码结构 |
详细设计
详细设计主要是为了对各个功能模块和各个子系统进行细节白盒设计，如果说架构设计是采用黑盒的分析方式，则详细设计就要关注流程，路径和逻辑。属于白盒的范畴。详细设计要完成对各个功能的函数级别的设计。但无需完成具体代码。
目标：
- 完成详细设计UML
- 实现详细设计的代码
产出：
- 详细设计图UML
- 详细设计书
- 详细的模块级别源代码
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 各模块详细设计图UML | MD(Model Designer) | 完成数量不定的各个模块详细设计 |
| 详细设计书(可选) | MD | |
| DBMS实现 | ||
| 项目计划V4(详细设计阶段) | PDA | 细化到概要设计阶段的每日工作量和人员分配 |
| 详细设计评估表 | PS | 通过 |
| 详细设计代码实现 | MD | 实现代码结构 |
编码实现
编码实现是工程的最下层细化阶段。其目的就是根据架构设计和详细设计实现和完成每个函数，每个类，每个模块，每个子系统，最终构成我们整个源代码部分。这个阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详尽的单元测试。
目标：
- 根据设计完成具体函数的编写工作
- 所有的功能代码被单元测试
产出：
- 开发日志
- 源代码及相关文件
- 单元测试源代码文件
- Code Review报告
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 开发日志 | 持续填写 | |
| 源代码及相关文件 | ||
| 单元测试源代码 | ||
| CodeReview |
单元验证
单元验证的目的是保证我们每个unit编码的健壮性。我们要求手动编码的单元验证函数覆盖率在100%，流程分支覆盖率在80%以上，条件分支覆盖在80%以上，边界值以及等价类覆盖在50%以上。
目标：
- 根据完成的功能函数进行单元测试，验证健全性
- 对完成代码进行边界值验证，分支验证，等价类验证以及常规验证
产出：
单元测试代码
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 单元测试源代码 | Developer | |
| 单元测试结果报告 |
集成构建
集成构建主要是指非表现层的各个模块之间，各个层级之间的接口组合。
目标：
- 除了界面层的最后搭建之外，其余层次之间的接口组合要完成。
- 通过质量控制组的测试。
产出：
集成构建进度表
集成构建覆盖表
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 集成构建进度表 | Developer | |
| 集成构建覆盖表 | ||
| 集成构建评估表 |
系统构建
系统构建首先是要对表现层与集成构建结果进行对接，其次，系统构建要与非业务功能模块进行对接。
目标：
- 完成系统的整体构建，达到内部测试的要求
产出：
- 完整的系统产品
- 系统构建的进度表
- 系统构建覆盖表
- 系统构建评估表
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 系统构建的进度表 | Developer | |
| 完整的系统产品 | ||
| 系统构建覆盖表 | ||
| 系统构建评估表 |
项目交付
阶段评审工作需要达到的状态列表
| 产品 | 责任人 | 应该达到的状态 |
|---|---|---|
| 项目验收检查表 | Developer | |
| 项目竣工表 | ||
| 项目用户手册 | ||
| 项目内测报告 |
二、质量控制阶段
- 测试需求确立
- 验收测试设计
- 系统测试设计
- 集成测试设计
- 单元测试检验
- 集成测试
- 系统测试
- 验收测试
- 项目交付
软件工厂生产的静态结构
开发流程定义了“谁”“何时”“如何”做“某事”，四种主要的建模元素来表达。
角色
软件工厂角色及只能如下：
| 角色(中英文) | 工作职能描述 | 担任此角色能力界定 |
|---|---|---|
| PM(项目经理) | 1.项目及产品研发管理，对项目成败直接负责 2.项目用人建议及学生的挑选 3.项目参与人员的培养和训练 4.与外包客户的沟通，包括售前，售后 5.参与售前项目需求工作 | 1.3年以上的相关软件开发经验 2.熟悉相关项目语言 3.带领过8人以上团队开发过成熟商业项目，有成功案例 |
| PDM(项目开发经理) | 1.项目及产品开发管理，主要管理项目中的开发团队，直接对项目经理负责 2.积极接受培养及自我培养。负责对各个小组的组长直接管理 3.制定产品开发计划，把握产品开发进度 4.协调与测试团队的合作，紧密的与测试经理配合 | 1.2年以上相关软件开发经验 2.熟悉相关项目语言 3.能独立完成同类项目 4.具有多个商业项目开发成功案例 |
| PTM(项目测试经理) | 1.项目及产品测试管理，主要管理项目中的测试团队，直接对项目经理负责 2.积极接受及自我培养，负责对各个测试小组的组长直接管理 3.指定产品测试计划，带领测试团队完成测试任务，把握产品测试计划 4.监控产品开发进度，监控开发团队开发质量 5.协调与开发团队的合作，紧密把握开发团队质量及进度 | 1.2年以上相关软件开发及软件测试经验 2.熟悉相关项目语言 3.能独立完成同类项目 4.具有多个商业项目开发及测试成功案例 5.熟悉软件测试各个流程 6.具备一定的技术管理能力 |
| SE(支持工程师) | 1.开发服务器及开发环境平台搭建 2.项目管理服务器及管理环境搭建 3.项目仓库构建 4.进行每日构建 5.项目中相关文档的收集，整理及汇总 6.进行项目配置管理 | 1.熟悉各类服务器系统，Windows，Linux， Unix 2.熟悉各操作系统上软件工厂开发环境的搭建 3.熟悉网络基础 4.熟练掌握各版本控制系统的管理 5.系统的学习过软件配置管理内容 6.熟练搭建各类应用服务器，web服务器 7.具有软件开发能力，能进行每日构建工作 |
| UED(用户体验设计师) | 1.根据用户体验设计软件布局，美化等工作 2.根据需求原型文档，做出美化后的软件界面效果图 3.参与到需求过程中，设计用户体验 4.根据设计的效果图，发布成静态网页，并且提供切好的素材(包括logo、按钮等) | 1.具有较强的客户沟通能力 2.具有较强的美术功底及审美能力 3.具有软件界面设计经验 4.熟练掌握各类设计工具(PS，Dreamwaver，Corldraw等) 5.具有强烈的改善客户体验意识 |
| UIE(用户接口工程师，前端工程师) | 1.根据UED提供的效果图及素材，归化整体页面设计 2.编写DIV+CSS的界面实现 3.公用界面组件的编写和规划 4.Masterpage公用模板的编写及规划 5.公用界面客户端脚本库的编写 | 1.深厚的网页制作功底 2.对Photoshop，Fireworks等工具基本掌握 3.熟练编写DIV+CSS的页面布局方式 4.熟练编写JavaScript等客户端脚本 5.熟悉项目相关语言及开发工具，有一定的后端代码编写能力 |
| PDA(项目需求分析师) | 1.项目需求阶段进行需求分析的主要人员 2.与项目经理，UED一起参与项目的需求阶段 3.负责需求阶段素材及资料的收集整理 4.负责需求阶段与客户确认工作 5.完成功能规格说明书的编写 6.配合UED完成界面原型的设计和实现 7.负责需求分析报告的编写 | 1.较强的沟通能力及逻辑思维 2.熟练使用Rose等UML建模工具 3.熟练使用Office等各类制图，成文工具 4.有较强的文案文字功底 5.系统的学习和研究过软件需求分析过程与技能 6.有较强的自我学习能力 |
| AD(架构设计师) | 1.项目及产品的架构设计 2.完成项目概要设计 3.完成项目概要设计相关文档 4.指定各类继承接口 | 1.3个以上项目的架构设计经验 2.熟悉软件开发各类模式，并且善于总结模式 3.熟练使用UML工具 4.熟悉项目开发语言及工具 5.具有较强的编程功底 |
| MD(模块设计师) | 1.根据概要设计，完成分配的模块详细设计 2.详细设计文档的实现 3.详细设计代码的实现 | 1.熟练使用UML工具 2.熟悉项目开发语言及工具 3.具有较强的编程功底 |
| DE(开发工程师) | 1.根据详细设计进行编码实现 2.完成自己模块的单元测试 3.填写开发日志 | 1.熟悉项目开发语言及工具 2.能正面压力工作 3.不排斥加班 4.熟练使用UML及版本控制工具 |
| TE(测试工程师) | 1.根据开发工程师提交代码进行各阶段测试 2.设计测试用例 3.执行测试工作 4.填写Buglist 5.填写测试日志 | 1.熟悉项目开发语言及工具 2.能正面压力工作 3.不排斥加班 4.熟练使用UML及版本控制工具 5.熟悉测试理论 6.熟练编写测试用例 7.熟练使用各类测试工具(loadrunner等) |
| DG(开发组长) | 1.管理7人以内的开发工程师 2.制定短期目标点 3.抓小组成员执行力，监督小组开发工作 4.也是一名开发工程师，参与开发 5.制定小组开发计划 | 1.熟悉项目开发语言及工具 2.能正面压力工作 3.不排斥加班 4.熟练使用UML工具及版本控制工具 5.具有较强的责任心 6.具有一定的组织能力 |
| TG(测试组长) | 1.管理7人以内的测试工程师 2.制定短期目标点 3.抓小组成员执行力，监督小组测试工作 4.也是一名测试工程师，参与测试 5.制定小组测试计划 | 1.熟悉项目开发语言及工具 2.能正面压力工作 3.不排斥加班 4.熟练使用UML及版本控制工具 5.熟悉测试理论 6.熟练编写测试用例 7.熟练使用各类测试工具(loadrunner等) 8.具有较强的责任心 9.具有一定的组织能力 |
活动
产物
工作流
软件工厂生产的工作流
-
工程工作流(开发阶段)
- 项目评估工作流
- 需求分析工作流
- 概要设计工作流
- 详细设计工作流
- 编码实现工作流
- 单元验证工作流
- 集成构建工作流
- 系统构建工作流
- 项目交付工作流
-
工程工作流(质量控制阶段)
- 测试需求确立工作流
- 验收测试设计工作流
- 系统测试设计工作流
- 集成测试设计工作流
- 单元测试检验工作流
- 集成测试工作流
- 系统测试工作流
- 验收测试工作流
- 项目交付工作流
-
审核工作流
- 项目评估审核工作流
- 需求分析设计审核工作流
- 概要设计审核工作流
- 详细设计审核工作流
- 编码Review工作流
- ...
-
支持工作流
- 项目管理工作流
- 配置和变更控制工作流
- 环境工作流
