第三部分技术过程规范
本规范中将软件开发的整个技术过程分为五个顺序实施的工作流程，分别为需求、分析、设计、实现和测试。在一次迭代过程中，这五个工作流程从总体上是顺序的，但彼此之间又存在交叉和重叠。
9 需求
9.1 管理需求
执行角色
系统分析员
活动描述
通过访谈、问卷、审阅合同等形式收集用户需求；
通过走查等非正式形式评估需求收集结果，确保无需求重复、不一致、不清晰等问题；
*对于需求的变更请求，此时的变更请求应当已经过变更控制与项目复审委员会复审，可直接作为正式的需求；
在模型元素与需求之间建立可追踪性链接；
建立需求属性；
制品
需求集；
9.2 查找参与者和用例
执行角色
系统分析员
活动描述
命名并简述已发现的主角；
命名并简述已发现的用例，概述事件流并收集非功能性需求（记录在《增补需求》中）；
形成用例模型（描述用例间的关系并将参与者和用例打包）；
制品
用例模型（概要的）；
《增补需求》；
9.3 排列用例优先顺序
执行角色
构架设计师
活动描述
一般根据用例的重要性、风险来确定用例优先级；优先级可用数字表示，该数字表示该用例在那一次迭代中实现；优先级也可以用关键、重要、辅助等级来表示；
制品
用例模型（更新的）；
9.4 详细说明用例
执行角色
用例工程师
活动描述
建模某用例与其他用例、用例与参与者的关系；
详细说明用例事件流；
制品
用例（详细说明的）；
《SRS》；
9.5 原型化用户界面
执行角色
用户界面设计员
活动描述
用各种界面元素形成用户界面原型；
制品
用户界面原型；
9.6 组织用例模型
执行角色
系统分析员
活动描述
描述用例间的关系（包含、扩展、泛化），优化用例模型；
制品
用例模型（结构化的）；
9.7 复9.8 审需求
执行角色
需求复审员
活动描述
正式核实需求结果符合客户对系统的看法，建议召开复审会议，复审如下内容：
影响现有需求集的变更请求；
整个用例模型；
对用例及其图表的复审（适合每个用例）；
制品
《复审记录》；
10 分析
10.1 构架分析
执行角色
构架设计师
活动描述
编写构架概述，采取了使用大量图片、示意板或图标化图形的非正规形式来对构架进行概述，这部分工作通常只在项目早期进行；
定义子系统的高层组织，在构架分析中通常侧重于两个高层层次，即应用程序层和业务专用层；
根据该层次组织形成分析包，将一些紧密联系的用例分配给一个具体包，然后在该包中实现相应的功能，确定服务包，同一服务包中的分析类都用于相同的服务；
确定明显的实体类；
确定特殊需求，如分布与并发、永久性机制、安全性机制等；
制品
分析包（概要的）；
实体类（概要的）；
分析模型；
10.2 用例分析
执行角色
用例工程师
活动描述
确定边界类、实体类和控制类；为每个由人或其他系统充当的参与者确定一个主要的边界类；将参与某个用例实现的分析类收集到一个类图中；
描述分析类间的交互（主要用协作图实现）；
确定每个用例实现的所有需求（非功能性需求）；
制品
分析类（概要的）；
用例实现-分析；
10.3 形成分析类
执行角色
设计员
活动描述
确定分析类的职责，可以用类的成员函数来表示，但仅仅是概念上的；
确定分析类的属性，可以用类的成员变量来表示，但仅仅是概念上的；
确定分析类间的关系；
确定分析类特殊需求；
制品
分析类（完整的）
10.4 形成分析包
执行角色
设计员
活动描述
将相关性较强的分析类打包成一个分析包；
包间应遵循高内聚、低耦合的原则；
制品
分析包（完整的）
10.5 分析复10.6 审
不要求正式复审，但应当对分析过程的制品进行检查
执行角色
建议由构架设计师执行
活动描述
检查或复审分析类、分析包、用例实现-分析、分析模型；
制品
无
11 设计
11.1 构架设计
执行角色
构架设计师
活动描述
识别节点和网络配置，将这些元素映射到实施模型；
识别子系统及其接口（一般来讲一个子系统映射到一个分析包，子系统对应到一个可执行构件）；
识别对构架有重要意义的类（不要设计细节，数目不要太多），识别主动类（进程和线程），考虑并发要求，将这些主动类分布到具体的节点上；
制品
子系统（概要的）；
接口（概要的）；
设计类（概要的）；
实施模型（概要的）；
构架描述（设计模型和实施模型视图）；
11.2 用例设计
执行角色
用例工程师
活动描述
识别设计类，使用类图来表示参与某一用例的类；
描述设计对象间的交互（可以用序列图来表示对相间的交互）；
识别参与的子系统和接口；
描述子系统间的交互作用（用序列图）；
捕获实现性需求（非功能性需求）；
制品
子系统（概要的）；
接口（概要的）；
设计类（概要的）；
用例实现-设计；
11.3 形成设计类
执行角色
设计员
活动描述
根据分析类或接口来勾画一个设计类：边界类à用户界面类；实体类à数据库管理类；控制类à一个或一组类；
识别操作（跟踪分析类的职责、分析类的非功能性需求及接口）；
识别属性；
识别类之间的关系；
要对方法进行描述，尤其要对复杂的方法进行详细描述，可以由自然语言或伪码进行描述，也可以用状态图进行描述；
对于状态控制的设计对象，可以用状态图进行描述；
制品
设计类（完整的）；
11.4 形成设计子系统
执行角色
设计员
活动描述
形成设计子系统；
形成设计子系统的接口；
制品
子系统（完整的）；
接口（完整的）；
11.5 数据库设计
执行角色
数据库设计师
活动描述
在组件视图中创建数据库模型；
在逻辑视图中创建方案，将该方案分配给数据库；
在该方案中创建对象模型视图；
在方案中创建表、视图等；在表中创建列；
在数据模型视图中创建表之间的关系；
为数据库分配存储过程、触发器等行为；
制品
数据模型；
11.6 复11.7 审设计
执行角色
设计复审员
活动描述
复审设计模型总体，在先启阶段和精化阶段的早期，总体复审着重检测模型的整体结构，尤其重点检查分层和接口；
复审每个用例实现；
复审每个子系统（及其内容）或类（如果系统很小）；
制品
无；
11.8 复11.9 审构架
执行角色
构架复审员
活动描述
进行软件构架评估的最佳时机就是在精化阶段结束的时候。该阶段主要集中在对需求进行详尽研究，并建立构架的基线。构架复审由在该阶段的里程碑的流程确定。在此情形下，可以进行大范围的构架质量检查。
制品
无；
12 实现
12.1 构架实现
执行角色
构架设计师
活动描述
确定在生命周期早期对构架有重要意义的构件，以启动实现工作；
建立实现模型；
把可执行构件映射到节点上；
制品
实现模型；
构件（概要的，可能被映射到节点上）；
构架描述（实现模型和实施模型的视图）；
12.2 制定集成构造计划
执行角色
任意角色
活动描述
计划应实施哪些子系统，以及在当前迭代中按照什么顺序集成子系统；
根据一个完整的用例实现寻找要实现的构件并分配给不同的构造；
制品
实现模型；
《集成构造计划》；
12.3 实现一个子系统
执行角色
程序员
活动描述
当前构造所需的子系统内的每个类应当由实现子系统中的构件来实现；
当前构造所需的子系统的每个接口也应当由实现子系统实现；
制品
实现子系统（已完成设计的）；
接口；
12.4 实现一个类
执行角色
程序员
活动描述
实现成员函数；
制品
构件（完整的）；
12.5 单元测试
略。
12.6 集成系统
执行角色
任意角色
活动描述
验证工作版本并晋升基线；
制品
工作版本（更新的）；
12.7 复12.8 审代码
执行角色
代码复审员（可以由技术监督小组成员兼任）
活动描述
走查/审查代码是否符合《编码规范》，提出更改/返工意见；
制品
无；
13 测试
13.1 制定测试计划
执行角色
测试员
活动描述
确定测试需求，包括功能性需求（参与测试的用例）和性能需求；
确定测试优先顺序，一般分为：
H - 必须测试
M - 应该测试，只有在测试完所有 H 项后才进行测试
L - 可能会测试，但只有在测试完所有 H 和 M 项后才进行测试；
制定测试策略；
确定测试资源，包括人员、测试环境等；
制定测试进度；
形成《测试计划》；
制品
《测试计划》；
13.2 设计测试
执行角色
测试员
活动描述
确定并说明测试用例，测试用例应考虑分支情况；
构造用户说明如何执行测试用例的测试规程（若测试用例足够详细，测试规程可以省略）；
制品
测试用例；
《测试规程》；
13.3 实现测试
执行角色
程序员
活动描述
该部分主要用来产生测试构件以使测试自动化；该部分常用来产生测试数据、显示测试结果等；该步骤不是必需的；
制品
测试构件；
13.4 执行集成测试
执行角色
测试员
活动描述
对当前构造的每一个用例执行测试规程，或运行测试构件自动执行测试规程；
将测试结果与预期结果比较；
记录并提交缺陷；
制品
缺陷；
13.5 执行系统测试
执行角色
测试员
活动描述
与集成测试类似；
制品
缺陷；
13.6 评估测试
执行角色
测试员
活动描述
分析测试结果并提交变更请求；
评估基于需求的测试覆盖；
评估基于代码的测试覆盖；
确定是否达到了测试的完成标准和成功标准；
生成测试评估摘要；
制品
《测试评估摘要》；
本文地址：http://com.8s8s.com/it/it34784.htm