WRUP 实践

RUP 软件工程管理概述

软件工程模型

  • 瀑布式开发
  • 迭代式开发
  • 敏捷开发模型

瀑布式开发

传统的瀑布式开发, 也就是从需求到设计, 从设计到编码, 从编码到测试, 从测试到提交, 大概这样的流程;

它要求每一个开发阶段都要做到最好, 特别是前期阶段, 设计的越完美, 提交后的成本损失就越少. 以前很多从事的外包项目就是这样的流程.

但是这里面有个问题, 就是开发途中发现之前的需求不合格、需要重新设计等问题, 都要留到下一个版本的开发中了.

所以, 瀑布式开发的过程中是比较机械化的, 按流程走下来, 要求每一个流程都要按规范走完.

当然它也有好处的, 从开发者的角度上说, 当你进入开发阶段时, 项目的文档是非常详细的, 像每个按钮点击后, 前台发生什么变化, 后台又怎么处理, 都详细的描述, 开发者只需编码就可以了…

迭代式开发

迭代式开发适合在一些需求信息不明确的项目中, 它不要求每一个阶段的任务做的都是最完美的, 而是明明知道还有很多不足的地方, 但先可以不去完善它, 而是把主要功能先搭建起来, 以最短的时间, 最少的损失先完成一个”不完美的成果物”直至提交.

这样在开发过程中遇到需求的变化时, 所带来的影响要比瀑布式开发小.

然后再通过客户或用户的反馈信息, 在这个”不完美的成果物”上逐步进行完善.

而现在的很多项目中, 需求在项目进行中变化的事儿经常见, 所以显得迭代式开发的优势较瀑布式开发更明显一些.

目前迭代式开发里面比较出名就是 RUP, 称为统一过程.

敏捷开发模型

在迭代式开发时, 遇到比较小的项目, 就有人思考, 能不能”反应”更迅速一点, 文档再少一点, 迭代周期更减少一点…

于是敏捷开发模型就应运而生了, 可以说, 它是在迭代式开发的基础上”进化”而来, 是一种极限迭代, 比较出名的有下面两种开发模型:

  • XP, Extreme Programming (极限编程)
  • Scrum, Scrum 的英文意思是橄榄球运动的一个专业术语, 表示”争球”的动作, 把一个开发流程的名字取名为 Scrum, 我想它的意思是开发团队在开发一个项目时, 大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它.

这两个我们后面的笔记会详细介绍.

RUP 软件工程

RUP 初窥

RUP (统一过程) 是一种以用例驱动、以体系结构为核心、迭代及增量的软件过程模型, 由 UML 方法和工具支持, 广泛应用于各类面向对象项目.

如下就是一个标准的 RUP 软件工程图 (图左上角为原点):

纵轴 表示了工作流程的静态结构, 共 9 个工作流程, 前 6 个流程就是一个正常的软件的生命周期, 称为核心流程, 后面的 3 个流程是辅助流程, 将贯穿项目始终, 也称为支持流程, 像搭建版本控制系统、搭建问题追踪系统、管理开发日志等, 都是属于这个流程.

横轴 代表了制定开发过程的时间, 显示 RUP 的动态特征, 通过迭代式软件开发的周期、阶段、迭代和里程碑等动态信息表示, 它将纵轴上的每个工作流程都划分为 4 个阶段, 每个阶段以一个主要里程碑结束, 所以本质上说每个阶段都是两个里程碑之间的时间跨度.

RUP 4 阶段

初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界.

为了达到该目的必须识别所有与系统交互的外部实体, 在较高层次上定义交互的特性.

本阶段具有非常重要的意义, 在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险.

对于建立在原有系统基础上的开发项目来讲, 初始阶段可能很短.

初始阶段结束时是第一个重要的里程碑: 生命周期目标 (Lifecycle Objective) 里程碑.

生命周期目标里程碑评价项目基本的生存能力.

细化阶段

细化阶段的目标是分析问题领域, 建立健全的体系结构基础, 编制项目计划, 淘汰项目中最高风险的元素.

为了达到该目的, 必须在理解整个系统的基础上, 对体系结构作出决策, 包括其范围、主要功能和诸如性能等非功能需求.

同时为项目建立支持环境, 包括创建开发案例, 创建模板、准则并准备工具.

细化阶段结束时第二个重要的里程碑: 生命周期结构 (Lifecycle Architecture) 里程碑.

生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量.

此刻, 要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案.

构造阶段

在构建阶段, 所有剩余的构件和应用程序功能被开发并集成为产品, 所有的功能被详细测试.

从某种意义上说, 构建阶段是一个制造过程, 其重点放在管理资源及控制运作以优化成本、进度和质量.

构建阶段结束时是第三个重要的里程碑: 初始功能 (Initial Operational) 里程碑.

初始功能里程碑决定了产品是否可以在测试环境中进行部署.

此刻, 要确定软件、环境、用户是否可以开始系统的运作.

此时的产品版本也常被称为 “beta” 版.

交付阶段

交付阶段的重点是确保软件对最终用户是可用的.

交付阶段可以跨越几次迭代, 包括为发布做准备的产品测试, 基于用户反馈的少量的调整.

在生命周期的这一点上, 用户反馈应主要集中在产品调整, 设置、安装和可用性问题, 所有主要的结构问题应该已经在项目生命周期的早期阶段解决了.

在交付阶段的终点是第四个里程碑: 产品发布 (Product Release) 里程碑.

此时, 要确定目标是否实现, 是否应该开始另一个开发周期.

在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合.

RUP 周期

RUP 模型采用迭代开发, 通过多次迭代执行开发工作流, 逐步确定一部分需求分析和风险, 在设计、实现并确认这部分后, 再去做下一部分的需求分析、设计、实现和确认工作, 依次进行下去, 直到整个项目完成, 这样能够在逐步集成中更好的理解需求, 构建一个健壮的体系结构.

软件生命周期

1、问题的定义及规划 (上图中叫业务建模)

此阶段是软件开发方与需求方共同讨论, 主要确定软件的开发目标及其可行性.

2、需求分析

在确定软件开发可行的情况下, 对软件需要实现的各个功能进行详细分析. 需求分析阶段是一个很重要的阶段, 这一阶段做得好, 将为整个软件开发项目的成功打下良好的基础”唯一不变的是变化本身”, 同样需求也是在整个软件开发过程中不断变化和深入的, 因此我们必须制定需求变更计划来应付这种变化, 以保护整个项目的顺利进行.

3、软件设计

此阶段主要根据需求分析的结果, 对整个软件系统进行设计, 如系统框架设计, 数据库设计等等. 软件设计一般分为总体设计和详细设计. 好的软件设计将为软件程序编写打下良好的基础.

4、程序编码

此阶段是将软件设计的结果转换成计算机可运行的程序代码. 在程序编码中必须要制定统一, 符合标准的编写规范. 以保证程序的可读性, 易维护性, 提高程序的运行效率.

5、软件测试

在软件设计完成后要经过严密的测试, 以发现软件在整个设计过程中存在的问题并加以纠正. 整个测试过程分单元测试、组装测试以及系统测试三个阶段进行. 测试的方法主要有白盒测试和黑盒测试两种. 在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试, 以减少测试的随意性.

6、运行维护

软件维护是软件生命周期中持续时间最长的阶段. 在软件开发完成并投入使用后, 由于多方面的原因, 软件不能继续适应用户的要求. 要延续软件的使用寿命, 就必须对软件进行维护. 软件的维护包括纠错性维护和改进性维护两个方面.

RUP 中的核心流程

业务建模工作流

产生五个工作产品, 即商业逻辑建模 (USE CASE)(ROSE)、业务需求说明书 (MS WORD)、专业词汇表 (英汉对照) (MS WORD)、风险说明 (MS WORD)、复审说明书.

需求工作流

为了确保开发人员构建正确的系统, 要了解目标组织的结构及机制;

要明确目标组织中当前存在的问题并确定改进的可能性;

确保客户、最终用户和开发人员就目标组织达成共识;

导出支持目标组织所需的系统需求, 建立系统需求模型: 用例图.

分析设计工作流

将系统需求转换为未来系统的设计, 逐步开放强壮的系统架构, 使设计适合于实施环境, 为提高性能而进行设计;

根据需求工作流中的用例图建立分析模型: 时序图等.

实施工作流

要定义代码结构, 以构件的方式实施类和对象, 对已开发的构件按类和单元来测试, 并且将结果集成到可执行的系统中;

建立开发模型: 类图、状态图等.

测试工作流

对各个类进行单元测试, 测试工作流包括核实对象之间的交互, 核实软件的所有构件是否正确集成, 核实所有需求是否已经正确实施, 确定缺陷, 确保在部署软件之前将风险降到最低.

部署工作流

目的是成功的生成版本并将软件分发给最终用户, 部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动, 包括: 软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助, 在有些情况下, 还可能包括计划和进行 beta 测试版、移植现有的软件和数据以及正式验收.

RUP 中的支持工作流

  • 团队架构
  • 里程碑计划
  • 每日站会
  • 持续构建 (CI)
  • 问题追踪
  • 自动化部署
  • 版本控制
  • 文档控制
  • 需求变更控制
  • 资源变更控制
  • 问题、知识管理 (wiki)
  • 工具、资源共享

WRUP 最佳实践模型

WRUP 由麦子学院的 Sandy 老师从 RUP 的基础上进化而来, 主要是增加了 TDD 驱动开发 (测试驱动开发).

原则特征

本模型描述了 WRUP 最佳实践方式, 它本身也是一套经过部署、验证有效的商业化软件开发方法.

之所以称为 “最佳实践”, 不仅仅是因为他们具有可以量化的价值, 并且被许多成功的机构、成功的项目所运用, 并且是在 Sundy 的十年开发生涯中不断积累的结果.

为了使整个团队有效的利用最佳实践模型, 我们为每个团队成员提供了必要准则、工具和模板, 并且明确指出其原则特征:

  • 迭代的开发软件
  • 开发与质量控制 (TDD) 双线并行
  • 量化可追溯的需求管理
  • 标准且可视化的软件建模
  • 验证每一个步骤
  • 控制变更

核心流程

WRUP 提出了 W 双线生产模型, 如下图:

即: 开发与质量控制 (TDD) 双线并行.

由 W 模型图可知, 项目生产过程包括两个主要过程: 开发 和 质量控制.

二者之间是相互独立又是息息相关密不可分的, 例如开发过程的需求分析完成后, 质量控制过程也可以完成验收测试设计.

质量控制过程又隐含着对开发阶段的审核, 开发过程大部分的审核皆由质量控制部门来实现.

W 模型对上一节学到的 RUP 图形 Y 轴进行了拆分和细化:

RUP WRUP
业务建模 项目评估
需求 需求分析
分析设计 概要设计
详细设计
实施 编码
单元验证
集成构建
系统构建
测试 质量控制过程
部署 项目交付

可以看到, 关键就是把测试移到专门的质量控制过程, 由质量控制部门来实现, 并贯穿始终, 这个应该可以认为是 TDD 驱动开发 (测试驱动开发) 的变种.

项目评估

项目评估阶段的目标是: 评估项目的级别、风险、项目需要投入的资源, 并且出可行性方案.

本阶段是非常重要的阶段, 是项目的基石, 若项目评估未通过, 则直接不再继续下面的步骤, 并且反馈给相关人; 若项目评估通过, 则需要确立项目级别、项目组织结构、项目从属事项等.

这个阶段关注的是项目中进行工程的业务和需求方面的主要风险, 对于建立在原有系统上的开发项目来说, 项目评估阶段的时间可能很短.

本阶段的主要目标如下:

  • 明确客户各个阶段使用目标以及软件基本架构
  • 估计出潜在风险
  • 评估项目使用的人力，财力，物力等资源
  • 对整个项目做最初的项目成本及日程估计
  • 确立软件项目立项是否可行

这个阶段的产出是:

  • 项目评估表
  • 项目立项书 (若通过评估)，包括业务上下文，验收规范，成本预计等
  • 原始核心需求文档 (客户提供)
  • 项目计划 V1 (概要)

阶段结束是一个里程碑标准:

  • 就是否参与这个项目已经定论
  • 项目级别已经定论
  • 项目投入资源以及主要风险承担者已经定论
  • 风险承担者就范围定义，成本/日程估计达成共识
  • 项目开发环境搭建完成

如果无法通过这些里程碑, 则项目可以被取消或者仔细地重新考虑.

阶段评审的工作和需要达到的状态列表:

产品 责任人 应该达到的状态
项目评估表 PS (Project Senate) 完成
项目立项书 PM (Project Manager) 完成
概要原始需求书 PM 具备
项目计划 V1 (包含项目开发计划，项目测试计划) PM / PDM / PTM 完成项目计划的第一个版本, 也就是概要版本, 不细化到具体的人员分配和具体功能细节.
开发服务器及开发环境 SE (Support Engineer) 完成或者确立
项目管理服务器及管理环境 SE (Support Engineer) 完成或者确立
项目仓库框架 SE (Support Engineer) 完成
责任人确立 PS (Project Senate) 确立项目经理, 开发经理, 测试经理以及项目外的干系人 (客户方代表) 选.
用户接口原型 (可选) UID (UI Designer) 主要是界面原型

需求分析

项目需求分析需要达到的目标是明确分析客户的需求, 并且量化成需求分析设计文档, 以达到确立商业用例及系统边界的目的.

为了达到该目的, 必须对系统具有 “英里宽和英寸深” 的现象, 体系结构的决策必须在理解整个系统的基础上作出: 它的范围、主要功能和性能等非功能性需求.

项目需求分析阶段是项目成功细化的关键保障, 我们对需求的确立也是我们后面阶段工作的前提保障, 常用的一句话: “正确的需求才有正确的软件”.

本阶段需要达到的目标:

  • 置顶而下明确客户系统模块划分
  • 明确 80% 客户系统的商业用例
  • 明确角色分配以及流程走向
  • 使用UML用例量化需求，完成需求报告

这个阶段的产出:

  • 蓝图文档: 核心项目需求、关键特色、主要约束的总体蓝图
  • 原始用例模型
  • 原始项目术语表
  • 原始商业案例, 包括业务的上下文、验收规范、成本预计
  • 原始的风险评估
  • 一个或多个原型

阶段结束是一个里程碑标准:

  • 风险承担者就范围定义, 成本/日程估计达成共识
  • 以客观的主要用例证实对需求的理解
  • 成本/日程、优先级、风险和开发过程的可信度
  • 被开发体系结构原型的深度和广度
  • 实际开支与计划开支的比较

如果无法通过这些里程碑, 则项目可能被取消或者仔细地重新考虑.

阶段评审工作需要达到的状态列表:

产品 责任人 应该达到的状态
需求分析图 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 实现代码结构

关于概要设计和详细设计可参考我另一篇隙 <<12、WRUP 最佳案例>> 中的 [Design 设计目录]

编码实现

编码实现是工程的最下层细化阶段, 其目的就是根据架构设计和详细设计实现和完成每个函数、每个类、每个模块、每个子系统、最终构成我们整个源代码部分.

这个阶段, 所有剩余的构件和应用程序功能被开发并集成为产品, 所有的功能被详尽的单元测试.

编码实现的目标:

  • 根据设计完成具体函数的编写工作
  • 所有的功能代码被单元测试

产出:

  • 开发日志
  • 源代码及相关文件
  • 单元测试源代码文件
  • 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. 有较强的自我学习能力

工作职能描述:

  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. 具有一定的组织能力

Sandy 未写完, 只有这么多…

其实总结起来的话, 也就几点:

业务建模, 一般就是客户、市场等前线人员出具的 word 文档…

需求阶段, 以用例驱动, 也就是根据业务建模的 word 文档建立用例图及原型图.

设计阶段, 以类驱动, 根据需求阶段的产物建立时序图、类图、状态图等.

开发阶段, 就是根据设计阶段的产物去具体实现了.

当然, 现在大部分开发会把 设计阶段 和 开发阶段 结合, 一边开发开边设计 (重构).

测试、部署、交付就没什么可说的了…

WRUP 最佳案例

Sandy 共享了一份项目案例, 我放到了我的微云上.

项目结构

首先, Sandy 推荐的项目结构如下图所示:

  • 工程根目录 + Design: 设计目录 * 数据库建模、系统设计 (系统设计分为概要设计和详细设计, 说明比较长, 这里说不清, 下面单独说 Design 设计目录) + Help: 使用帮助目录 * 使用培训、帮助文档等等 + Logs: 日志目录 * 构建日志、个人日志等等 + Planning: 计划目录 * 会议记录、邮件沟通记录、周报 (针对整个项目的周报, 非个人)、个人日计划等等 + Publish: 发布目录 * 安装包、安装必读、客户验收文档等等 + Requirement: 需求目录 * 需求说明书、词汇对照表、风险说明、用例图、UI 原型、需求变更等等 + Source: 源码目录 + Study: 学习目录 * 开发新项目, 或多或少都会学习到新的知识, 参考新的源码, 这些项目的参考、学习文件都放在这 + Test: 测试目录 * Bug List 管理、测试报告 (测试用例) 等 + Readme.txt: 工程说明 * 这份源码是用来做什么的 * 如何去使用 * 项目中重要的文件和子目录的结构信息 * 每个目录都可以有个 Readme, 用来对当前目录的子目录做解释

以上仅为 Sandy 推荐的结构, 实际可按照需要进行调整, 例如:

  • Help (使用帮助目录) 可以归纳到 Publish (发布目录) 里
  • Logs (日志目录) 可以归纳到 Planning (计划目录) 里, 特别像个人日志和个人日计划完全可以结合, 每天早上先写好昨天的日志, 然后安排好今天的计划
  • 上面列出来的产出 (各种文档、报告) 不是必须的, 根据需要补充, 例如 Test (测试目录) 里的 Bug List, 如果你采用 Redmine 或者 Bugzilla 等问题追踪系统, 完全可以去除 Bug List
  • 如果你有完善的版本控制体系, 要求每天写提交日志, 那么个人日志也可以考虑省略, 演变成个人周报

Design 设计目录

参考文章:

UML在项目实施中的使用心得(概要设计阶段)

UML在项目实施中的使用心得(详细设计阶段)

上面两篇文章大概总结为:

在概要设计阶段使用 Deployment 图、Component 图、Sequence 图、StateMachine 图、Activity 图描述清楚技术架构、部署方式、内外接口、主要流程和数据库结构等等;

而在详细设计阶段使用 Class 图、Sequence 图、StateMachine 图、Activity 图与代码设计相结合, 描述实际代码中方法、属性间的关系及协作流程, 甚至需要伪代码.

可以看出来:

  • 概要设计是黑盒设计, 体现的是各模块间的关系
  • 详细设计是白盒设计, 体现代码中类、实例、方法、属性间的关系

一些人以为 UML 建模一上来就要画许多很精细的图, 这是误解 !!

如今敏捷开发一般不推荐详细设计, 将系统设计、概要设计、详细设计合并为架构 (Architecture) 设计, 对系统和架构作出一种初步、稳定的分解，是常见的一种敏捷开发、敏捷建模实践;

而且程序猿个个都有极强的创造精神, 有相当一部分不大喜欢别人把详细设计做的太细, 以便发挥下自己的创造力 (初级设计能力);

不过仁者见仁, 智者见智, 因为一个初级的程序猿如果先是看别人的设计, 然后再开始自己的设计, 也许学习曲线就不会那么陡峭, 日子也会过的舒服一点儿也未可知.

所以说, 如果一个团队里的新手较多, 还是推荐使用详细设计的, 否则不推荐使用.

需求分析

项目评估阶段

项目评估是做需求分析的首要条件, 当接到一个需求, 我们要先对这个需求做下评估, 确定能不能做, 如果能做的话, 才会去做需求分析.

  • 项目的设想和业务案例参考
  • 是否可行
  • 粗略估计成本
  • 能获取到的支持
  • ......

这个阶段一般是很快速的, 最短可能就是一次项目可行性研讨会…

产出:

  • 评估报告
  • 立项
  • 资源计划
  • 技术难点重点

需求分析阶段

需求阶段步骤
  • 第一次需求及设计 (评估及非功能)
  • 第二次需求及设计 (领域边界, 即系统可能包含哪些模块, 子系统)
  • 第三次需求及设计 (功能)
  • 第四次需求及设计 (界面)
  • 不断迭代

以上是细分后的情况, 大部分情况下, 可以只有 功能 和 界面.

迭代式需求

我们依照 RUP 流程, 先启 -> 精化 -> 构建 -> 产品化 的 4 个阶段, 总结出需求的四要素及五原则:

四要素:

  • 环境和前提 (给谁用, 用多久, 用在什么地方, 需不需要暴露接口等等)
  • R (静态), 系统、子系统、模块、子模块 (用例图中的 Package)
  • P (动态), 即上一步的静态结构的动态行为, 与上一步结合就形成了完整的用例图
  • 界面原型, 可用工具有 Visio、Axure、Mockups、Blend 等

五原则:

  • 沟通、建模、成文
  • 文不如表、表不如图
  • 至顶而下, 逐层细分
  • 业务 = (R & P)
  • 拥抱变化, 不断重构
三轴线

三轴线框架: X 横向功能需求, Y 纵向功能需求, Z非功能需求

X 轴是贯穿整个系统模块的, 是被依赖的功能模块, 比如权限系统

Y 轴是相对独立的功能需求, 例如菜单的顶层结构, 互不影响, 可以算是单独的功能性需求, 它不依赖别的模块

Z 轴是我们的非功能模块, 比如安全性, 健壮性, 美观性等等, 包括我们的日志系统, 也是非功能性需求

需求成文

在开发者角度, UML 就是文档、是”文”.

但是最终你还是要给客户、给老板需求报告, 虽说 “文不如表、表不如图”, 但他们看不懂 UML 图, 这时就需要把 UML 图转成 Word 文档了…

注意, 这里的需求文档, 不是客户给的原始需求文档, 而你根据 UML 转化而来的文档, 是要提供给客户、老板的, 所以在大纲上, 也是遵循需求 4 要素, 简单的说, 就是用 word 文档解释 UML.

系统设计

什么是系统设计

到了这一步, 说明你最起码已经迭代过一轮需求分析了, 而系统设计, 就是根据需求分析阶段的产出 (即系统模块、功能要求等), 设计出一个符合 GRASP & SOLID 的软件架构 (什么是 GRASP & SOLID, 后面再介绍).

这个阶段的任务是:

  • 设计软件系统的模块层次结构
  • 设计数据库的结构
  • 设计模块的控制流程

这个阶段又分两个步骤: 概要设计和详细设计.

概要设计是黑盒设计, 解决软件系统的模块划分和模块的层次机构以及数据库设计, 详细设计是白盒设计, 解决每个模块的控制流程, 内部算法和数据结构的设计.

现在有些敏捷开发思想, 不推荐使用详细设计, 将系统设计阶段统称为架构设计.

也就是说, 这个阶段的任务从上面的三条, 变为两条 (即不进行详细设计, 不涉及具体算法、流程):

  • 设计软件系统的模块层次结构
  • 设计数据库的结构

另外要注意, 在需求阶段, 我们用用例图中的Package来表达系统、子系统、模块、子模块间的关系, 但这和系统设计阶段的模块层次不是一一对应的, 确切的说需求阶段的模块划分表达的是更上层的东西, 即功能模块的划分, 而系统设计阶段的模块划分则是从软件工程角度出发, 应该按 GRASP & SOLID, 是两种完全不同的概念.

GRASP & SOLID

SOLID, 这是描述设计原则的一个专业术语, 由我们可爱的代码整洁之道传教者鲍勃 (罗伯特C. 马丁) 大叔提出, 是一组用于指导我们如何写出”好代码”的原则.

SOLID 的解释为:

  • Single responsibility principle (单一职责原则)
  • Open/closed principle (打开/关闭原则)
  • Liskov substitution principle (里氏替换原则)
  • Interface segregation principle (接口隔离原则)
  • Dependency inversion principle (依赖倒置原则)

关于这几个原则的定义, 参考我另一篇笔记: 六大设计原则

GRASP, 全称为General Responsibility Assignment Software Pattern, 即通用职责分配软件模式, 它由《UML 和模式应用》 (Applying UML and Patterns) 一书作者 Craig Larman 提出.

GRASP 是对象职责分配的基本原则, 其核心思想是职责分配 (Responsibility Assignment), 用职责设计对象 (Designing Objects with Responsibilities).

GRASP 包括以下内容:

  • Information Expert (信息专家模式)
  • Creator (创造者模式)
  • Controller (控制器模式)
  • Low Coupling (低耦合模式)
  • High Cohesion (高内聚模式)
  • Polymorphism (多态模式)
  • Pure Fabrication (纯虚构模式)
  • Indirection (中介模式)
  • Protected Variations (受保护变化模式)

关于这几个模式的定义, 参考我另一篇笔记: 设计模式与 GRASP

GRASP 与 SOLID 是有相通的地方的:

  • Information Expert 与 Single responsibility principle
  • Protected Variations 与 Open/closed principle

GRASP & SOLID 是 GOF (二十三种设计模式) 的基础, GOF 只是在某些情景下对 GRASP & SOLID 的具体实践.

GRASP 以职责驱动设计, 什么是职责呢?

简单地说, 一个类或构件的职责包括两个方面: 一个是知道的事, 对于一个类来说就是他的属性; 一个是能做的事, 对于一个类来说就是他的方法.

  • “知道”职责 —— 表示这个类, 它”知道”些什么 + 了解私有封装数据 + 了解关联的对象 + 了解能够派生或计算的事物
  • “行为”职责 —— 表示这类类, 它可以”做”什么 + 完成对象初始化 + 执行一些控制行为

职责的分配可使用时序图或协作图来表达, 面向对象设计过程就是将责任分配给类的过程.

例子: 在一个销售软件中存在一个交费行为, 此时, 就可将交费识别为一个”行为”职责.

  • “行为”职责表示交费的行为, 需要创建一个付款记录的对象 Payment
  • “知道”职责必须知道付款记录类 Payment，知道如何记录及计算 Payment 类中的数据

  • 发现具有交费行为的对象 Sale
  • 发现了该类还关联另一个类对象 Payment