1《立项建议书》....................................................................................... 1
2《软件项目投标书》................................................................................. 6
3《软件产品开发任务书》........................................................................... 7
4《软件开发计划书》............................................................................... 10
5《用户需求报告》.................................................................................. 14
6《需求规格说明书》............................................................................... 18
7《需求报告 / 需求规格说明书评审记录表》.................................................. 22
8“图书馆信息系统”............................................................................... 24
9《概要设计说明书》............................................................................... 25
10《详细设计说明书》.............................................................................. 30
11《用户使用手册》................................................................................. 34
12《用户安装手册》................................................................................ 35
13《测试报告》...................................................................................... 36
14软件质量保证关键过程域SQA................................................................. 39
15《CMM软件质量保证过程文件》.............................................................. 42
16《CMM软件质量保证程序文件》.............................................................. 44
17《软件质量保证计划》........................................................................... 46
1《立项建议书》
《立项建议书》编写参考指南
1．引言（Introduction）
1.1 目的（Purpose）
本文档是软件立项书，目的是代替可行性分析。
1.2 范围（Scope）
本文档只适应于软件立项。
1.3 术语定义（Terms Glossary）
对软件组织内部和外部有关的行业术语、专用名词进行定义。
[1] ……
[2] ……
1.4 参考资料（References）
对书写该立项书所用到的有关资料进行说明。
[1] ……
[2] ……
1.5 相关文档（Related Documents）
当该文档变更时，可能对其他文档产生影响，受影响的文档叫做相关文档，需将它们一一列出。
[1] ……
[2] ……
1.6 版本更新记录（Version Updated Record）
任何一次版本创建或维护更新，都要追加一条记录。一个版本创建只有一次，但对它的维护更新可能有多次。大版本升级一次，定义为创建一次，如V1.0到V2.0。而V1.0到V1.1，只是维护更新一次。版本更新记录格式，如表3-2所示。
表3-2 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2001/01/03 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2001/02/10 |
网络版功能维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．项目概述及架构（Project Summary and Framework）
2.1 项目概述（Project Summary）
宏观上说明该项目是什么、能干什么、要求干得怎么样。
2.2 项目架构（Project Framework）
宏观上描述该项目的架构：单机结构、C/S结构、B/S结构。并说明结构具体详细的运行平台：硬件的要求、操作系统的要求、数据库管理系统的要求、对外接口的要求。
3．客户群分析（Client Analysis）
3.1 客户群定位（Client Orientation）
单机结构、C/S结构、B/S结构对应哪三种客户群，每种客户群的数量、素质、市场前景等。
3.2 当前客户群分析（Current Client Analysis）
当前客户群是指已签订合作协议或将要签订合作协议的客户群，分析他们的数量、素质、市场前景等。
3.3 潜在客户群分析（Latency Client Analysis）
潜在客户群是指将来可能发展的客户群，分析他们的数量、素质、市场前景等。
4．项目功能（Project Function）
4.1 单机版功能（Stand-alone Function）
单机版功能，如表3-3所示。
表3-3 单机版功能
|
编号 |
功能名称 |
功能描述 |
输入内容 |
输出内容 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
4.2 网络版功能（Network Function）
网络版功能，如表3-4所示。
表3-4 网络版功能
|
编号 |
功能名称 |
功能描述 |
输入内容 |
输出内容 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
4.3 互联网络版功能（Internet Function）
互联网络版功能，如表3-5所示。
表3-5 互联网络版功能
|
编号 |
功能名称 |
功能描述 |
输入内容 |
输出内容 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
5．项目性能（Project Performance）
5.1 响应时间（Response Time）
单机结构（包括主机多用户结构，即H/T结构）、C/S结构、B/S结构三种架构的终端数量，要求响应时间小于0.XX秒。
5.2 处理速度（Disposal Speed）
C/S结构、B/S结构两种架构的后台结算方式，结算速度分析。
5.3 最大终端负载（The Highest Terminal Load）
C/S结构、B/S结构两种架构的并发处理最大终端（用户）负载数量分析。
以上性能要求，最好也用列表的形式给出。
6．项目接口（Project Interface）
6.1 金融接口（Finance Interface）
金融接口列表，如表3-6所示。
表3-6 金融接口列表
|
编号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
6.2 政府接口（Government Interface）
政府接口列表，如表3-7所示。
表3-7 政府接口列表
|
编号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
6.3 互联网接口（Internet Interface）
互联网接口列表，如表3-8所示。
表3-8 互联网接口列表
|
编号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
7．投入产出分析（Analysis of the Devotion and the Output）
7.1 人力资源投入（Manpower Devotion）
人力资源投入，如表3-9所示。
表3-9 人力资源投入
|
阶段名称 |
需求岗位 |
需求人数 |
工作量（人/月） |
到岗日期 |
|
需求分析 |
分析师 |
|
|
|
|
概要设计 |
设计师 |
|
|
|
|
详细设计 |
设计师 / 高级程序员 |
|
|
|
|
编码 |
程序员 |
|
|
|
|
测试 |
测试员 |
|
|
|
|
包装与发布 |
包装师 |
|
|
|
|
总人数： |
总工作量（人/月）： |
|||
7.2 设备资源投入（Facility Devotion）
设备资源投入，如表3-10所示。
表3-10 设备资源投入
|
设备名称 |
规格型号 |
数量 |
单价（元） |
金额（元） |
到位日期 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7.3 其他经费资源投入（Other Outlay Devotion）
其他经费资源投入，如表3-11所示。
表3-11 其他经费资源投入
|
开支项目 |
开支金额（元） |
支付日期 |
支付方式（现金/支票） |
备注 |
|
|
|
|
|
|
|
|
|
|
|
|
|
项目总投入（人力费用+设备费用+其他经费资源投入）经费（元）： |
||||
7.4 产出分析（Output Analysis）
产出分析，如表3-12所示。
表3-12 产 出 分 析
|
|
单机版单价（元） |
单机版 数量 |
C/S版单价（元） |
C/S版数量 |
B/S版单价（元） |
B/S版数量 |
年产出合计金额（元） |
|
第1年 |
|
|
|
|
|
|
|
|
第2年 |
|
|
|
|
|
|
|
|
第3年 |
|
|
|
|
|
|
|
8．开发计划（Development Scheme）
8.1 进度计划（Plan Scheme）
开发进度计划，如表3-13所示。
表3-13 进 度 计 划
|
阶段名称 |
需求分析 |
概要设计 |
详细设计 |
编码 |
测试 |
包装与发布 |
|
第1周进度 |
|
|
|
|
|
|
|
第2周进度 |
|
|
|
|
|
|
|
第3周进度 |
|
|
|
|
|
|
|
第4周进度 |
|
|
|
|
|
|
|
第5周进度 |
|
|
|
|
|
|
|
…… |
|
|
|
|
|
|
8.2 评审计划（Review Scheme）
各里程碑的评审计划，如表3-14所示。
表3-14 评 审 计 划
|
阶段名称 |
评审日期 |
评审地点 |
主持人 |
参加人 |
应交文档 |
|
需求分析 |
|
|
|
|
|
|
概要设计 |
|
|
|
|
|
|
详细设计 |
|
|
|
|
|
|
测试报告 |
|
|
|
|
|
|
包装 |
|
|
|
|
|
9．案例分析（Cases Analysis）
案例分析包括成功案例和失败案例分析。
9.1 国外案例分析（Cases Analysis in Foreign Countries）
案例1：……
案例2：……
9.2 国内案例分析（Cases Analysis in China）
案例1：……
案例2：……
10．风险分析（Risk Analysis）
10.1 需求风险（Risk of Requirement）
指项目组对用户需求获取的途径和能力有何风险，用户主动配合需求的程度。
10.2 政策风险（Risk of Policy）
指国家政策、行业政策、企业内部政策的变化对项目将会产生有利或不利的影响。
10.3 资源风险（Risk of Resource）
指开发和运行所需资源的风险程度。
10.4 技术风险（Risk of Technology）
指项目组采用新技术的风险程度。如最新开发工具的风险程度、最新设计思想的风险程度。
10.5 技能风险（Risk of Skill）
指项目组成员掌握新技术的风险程度。
2《软件项目投标书》
表3-15 《软件项目投标书》编写参考指南
|
序号 |
章节名称 |
章节内容 |
|
1 |
项目概况 |
按照招标书的内容，陈述项目概况 |
|
2 |
总体解决方案 |
按照招标书的要求，提出项目的总体解决方案： 网络结构总体方案 系统软件配置方案 应用软件设计方案 系统实施方案 |
|
3 |
项目功能、性能和接口描述 |
应用软件的具体功能点列表 应用软件的具体性能点列表 应用软件的具体接口列表 |
续表
|
序号 |
章节名称 |
章节内容 |
|
4 |
项目工期、进度和经费估算 |
项目工期（单位：人月）估算 项目进度估算：需求、设计、编程、测试、验收的时间表 项目经费（单位：人民币元）估算 |
|
5 |
项目质量管理控制 |
质量标准 质量管理控制方法 项目开发和管理的组织结构及人员配备 |
|
6 |
附录 |
附录1：本软件公司的特点与强项简介 附录2：本软件公司的成功案例 附录3：本软件公司的资质证明材料 |
3《软件产品开发任务书》
《软件产品开发任务书》正文样本
任务书名称：大型商业MIS产品开发任务书。
下达日期：1999/04/01。
发出部门：XX公司研发中心。
接受部门：研发中心商业软件部。
1．目标
（1）做成商业MIS产品，其产品化程度要求很高。因此，一切信息都要规范化、标准化、代码化。保证在产品实施时，其客户化工作只需录入代码和修改代码，绝对不允许修改数据结构和表结构；
（2）配合市场销售部门、全国各地的分支机构和产品代理商，第一年开拓市场3~5个客户，第二年占领10% 的商业MIS市场。
2．功能模块划分及要求
大型商业MIS软件产品拟分为以下6个功能模块，要求每个功能模块具有高内聚、低耦合、信息隐蔽的性质，如表3-16所示。
表3-16 大型商业MIS产品的6个功能模块
|
序号 |
模块名称 |
功能要求 |
|
1 |
商业物流配送中心管理 |
商业物流采购、配送 |
|
2 |
大型商场（大型连锁超市）管理 |
商品零售 |
|
3 |
便利店（小型连锁超市）管理 |
商品零售 |
|
4 |
远程数据交换管理 |
点对点通信 |
|
5 |
电子商务模块 |
网上订货、销售 |
|
6 |
商业类库管理 |
基础类库、商业类库、构件库管理 |
3．功能模块详述
大型商业MIS软件，从组织结构上来说包括三个层次：
（1）物流配送中心
（2）大型商场（大型连锁超市）
（3）便利店（小型连锁超市）
作为一个完整的商业MIS系统来说，物流配送中心与大型商场（大型连锁超市）之间会发生物流、资金流、信息流的关系；大型商场（大型连锁超市）与便利店（小型连锁超市）之间也会发生物流、资金流、信息流的关系；而物流配送中心与便利店（小型连锁超市）之间没有任何关联。若将这三个模块分开来看，它们又可以各自独立成为一个单独的小型商业系统来使用。实际上，本大型商业MIS系统完成后，可以对功能模块进行组合或拆分，使其成为如下5个不同的小型商业MIS系统，供用户选择：
（1）物流配送中心 ＋ 大型商场（大型连锁超市）＋ 便利店（小型连锁超市）的完整的商业MIS软件。
（2）物流配送中心 ＋ 大型商场（大型连锁超市）的商业MIS软件。
（3）大型商场（大型连锁超市）＋ 便利店（小型连锁超市）的商业MIS系统。
（4）物流配送中心MIS系统。
（5）大型商场的商业MIS系统。
作为本软件的第一层，物流配送中心可以具有多个配送仓库，它根据大型商场（大型连锁超市）的需要以及各个仓库库存情况，向供应商订货，进行货物采购；并根据订货的情况进行配货，组织运输工具进行发货；期间，还伴随着向供应商付款、索取发票，以及向客户催款、开出发票等等。大型商场（大型连锁超市）作为本软件的第二层，除了要进行本商场的各种业务管理外，还要向上级物流配送中心订货、付款、索取发票，向下级便利店（小型连锁超市）送货，收取钱款等等。便利店（小型连锁超市）作为本软件的第三层，一要进行本商场的各种业务管理；二要根据库存情况，向大型商场（大型连锁超市）要货，并定期将销售金额上交给大型商场（大型连锁超市）。
考虑到目前有些商场，已经有了其他的商业管理软件，虽然软件还有不完善的地方，但已经购买前台POS机。为了给客户节省开支，有效地将前台POS机利用好，所以，本系统的前台销售软件就要做两个版本：Windows 版本与DOS 版本。
由于配送中心与大型商场（大型连锁超市）之间、大型商场（大型连锁超市）与便利店（小型连锁超市）之间在物理位置上有一定的距离，所以，它们之间的网络连接也是一个需要重视的大问题。本系统考虑采用两种解决方案：一是采用DDN专线（或光缆），本方案数据传输速度快，性能高，程序设计、实现都很简单，但用户每月都要支付价格不低的线路费用，这种方案比较适合那些经济实力比较雄厚的用户；二是采用电话线，用X.25通信协议，此方案数据传输速度稍慢，但也能满足用户需要，程序设计和实现要复杂许多，用户每月支付的线路费用将大幅度下降。
随着计算机网络技术的飞速发展，电子商务在流通领域的应用也越来越多。本MIS系统也准备在电子商务方面有所扩展，条件允许，可以实现网上订货、网上销售，甚至网上货币支付。
作为一个软件企业，应该不断地提取、积累自己的软件资源。不同开发平台的开发规范、商业类库、应用框架、构件、中间件等都是十分重要的软件资源，是软件公司的基础建设。因此，在设计、编码之前，要制订相应的开发规范，要组织开发、设计、管理一些类库和构件库。
软件产品是软件公司的财富来源，而软件的有效加密是保护公司产品、产权的有效手段，更是保障公司效益的有效途径。所以，还要考虑软件加密算法设计。
4．功能模块任务分配
根据研发中心商业软件部目前的人员情况，本系统的项目经理由商业软件部副经理亲自担任，负责整个系统的规划、设计、协调与实施；商业软件部主任工程师担任产品经理，负责项目的整体需求、数据库设计与Alpha测试。整个项目分为4个任务组，各个任务组组长在项目实施阶段，承担小项目经理职责。4个任务组的人数及开发任务，如表3-17所示。
表3-17 任务组的人数及开发任务
|
任务组 |
人数 |
具体开发任务 |
|
第1任务组 |
4 |
1）POS机模块改造 2）利用X.25协议进行远程数据交换 3）电子商务模块 |
|
第2任务组 |
6 |
物流配送中心管理模块。本模块的主要功能包括：货物的采购管理，配送中心的库存管理，货物的销售管理三大部分 1）货物的采购管理包括：供应商管理，采购计划管理，订货管理，货物验收管理，退货管理，应付账款管理，应收发票管理，往来账管理等 2）库存管理包括：货位管理，入库管理，出库管理，盘库管理等 3）销售管理包括：客户管理，销售定单管理，配货管理，运输工具管理，发货管理，退货管理，应收账款管理，应付发票管理，往来账管理等 |
|
第3任务组 |
6 |
1）全局数据库设计 2）商业管理模块（包括大型商场与便利店的管理）。本模块的主要功能包括：货物的采购管理，退货管理（退给供应商），价格管理，库存管理，销售管理，前台销售管理，退货管理（客户退货管理），应付、应收账款管理，发票管理，送货管理（给便利店送货），收款管理（便利店上交金额）等等 |
|
第4任务组 |
2 |
1）PowerBuilder 开发规范 2）PowerBuilder 类库建设 3）构件的提取和构件库的管理 4）产品的加密处理 5）安装盘的制作 |
5．数据库与开发工具的选择
考虑到数据库的性能与价格比，数据库首选Sybase，其次是MS SQL Server。由于这两个数据库的天然联系，使得两个版本的程序设计的差异将十分微小。数据库设计工具采用PowerDesigner，程序开发工具选择为PowerBuilder 。某些PowerBuilder 不宜实现的功能，可由 VC++ 去完成。文档制作工具为Office 和PowerDesigner。
6．开发进度计划
研发中心商业软件部现有18人进入了本项目组。根据以往的实际工作经验，下面列出研发进度，如表3-18所示。
表3-18 进度计划（1999/04/01-1999/10/15）
|
阶段名称 |
需求分析 |
概要设计 |
详细设计 |
编码 |
测试 |
包装 |
发布 |
|
|
第1周进度 |
需求培训 |
|
|
|
|
|
|
|
|
第2周进度 |
需求获取 |
|
|
|
|
|
|
|
|
第3周进度 |
需求获取 |
|
|
|
|
|
|
|
|
第4周进度 |
需求获取 |
|
|
|
|
|
|
|
|
第5周进度 |
需求确认 |
|
|
|
|
|
|
|
|
第6周进度 |
|
概要设计 |
|
|
|
|
|
|
|
第7周进度 |
|
概要设计 |
|
|
|
|
|
|
|
第8周进度 |
|
概要设计 |
|
|
|
|
|
|
|
第9周进度 |
|
|
详细设计 |
|
|
|
|
|
|
第10周进度 |
|
|
详细设计 |
|
|
|
|
|
|
第11周进度 |
|
|
详细设计 |
|
|
|
|
|
|
第12周进度 |
|
|
详细设计 |
|
|
|
|
|
|
第13周进度 |
|
|
|
编码 |
|
|
|
|
|
第14周进度 |
|
|
|
编码 |
|
|
|
|
|
第15周进度 |
|
|
|
编码 |
|
|
|
|
|
第16周进度 |
|
|
|
编码 |
|
|
|
|
|
第17周进度 |
|
|
|
编码 |
|
|
|
|
|
第18周进度 |
|
|
|
编码 |
|
|
|
|
|
第19周进度 |
|
|
|
编码 |
|
|
|
|
|
第20周进度 |
|
|
|
|
Alpha测试 |
|
|
|
|
第21周进度 |
|
|
|
|
Alpha测试 |
|
|
|
|
第22周进度 |
|
|
|
|
Alpha测试 |
|
|
|
|
第23周进度 |
|
|
|
|
Alpha测试 |
|
|
|
|
第24周进度 |
|
|
|
|
Beta测试 |
|
|
|
|
第25周进度 |
|
|
|
|
Beta测试 |
|
|
|
|
第26周进度 |
|
|
|
|
|
包装 |
|
|
|
第27周进度 |
|
|
|
|
|
|
发布 |
|
|
第28周进度 |
|
|
|
|
|
|
|
机动 |
7．评审计划
各里程碑的评审计划，如表3-19所示。
表3-19 里程碑评审计划
|
阶段名称 |
评审日期 |
评审地点 |
主持人 |
参加人 |
应交文档 |
|
需求分析 |
1999/05/05 |
公司第一会议室 |
部门经理 |
项目组成员 |
用户需求报告/需求规格说明书 |
|
概要设计 |
1999/05/26 |
公司第一会议室 |
部门经理 |
项目组成员 |
概要设计说明书 |
|
详细设计 |
1999/06/25 |
公司第一会议室 |
项目经理 |
项目组成员 |
详细设计说明书 |
|
Alpha测试 |
1999/09/12 |
公司第一会议室 |
项目经理 |
测试人员 |
Alpha测试报告 |
|
Beta测试 |
1999/09/26 |
客户单位 |
项目经理 |
客户代表 |
Beta测试报告 |
|
包装 |
1999/09/31 |
公司第一会议室 |
部门经理 |
销售人员 |
包装光盘，用户指南，广告材料 |
附件：《商业MIS立项建议书》，此处省略。
4《软件开发计划书》
《软件开发计划书》编写参考指南
1．引言（Introduction）
1.1 目的（Purpose）
本章提供整个软件开发计划的综述。主要是确定以下内容：
（1）软件生存周期的选取及裁剪。
（2）软件规范、方法和标准的选择。
（3）软件工作产品的规模估计。
（4）软件工作量和成本的估计。
（5）软件进度表的制定。
（6）软件风险的估计。
（7）软件项目培训计划。
1.2 范围（Scope）
说明该软件开发计划的范围，简要描述软件开发计划的内容。一般而言，对于一个较大的软件项目（工期6个人月以上），计划书包括如下内容：
（1）软件规模估计
（2）工作模块计划
（3）人力资源计划
（4）其他资源计划
（5）进度安排计划
（6）配置管理计划（可单独做一个计划）
（7）质量保证计划（可单独做一个计划）
1.3 术语定义（Terms Glossary）
将该软件开发计划中的术语、缩写词进行定义。包括用户应用领域与计算机领域的术语与缩写词等。例如：
[1] 软件相关组：指软件配置管理组、文档支持组、测试组。
[2] 软件质量保证组：指计划和实施软件质量保证活动的人员的集合。
1.4 参考资料（References）
说明该软件开发计划使用的参考资料，如项目的用户需求报告、商务合同、用户领域的资料等，每一个文件、文献要有标题、索引号或文件号，发布或发表日期以及出版单位。
[1] ……
[2] ……
1.5 相关文档（Related Documents）
当该文档变更时，可能对其他文档产生影响，受影响的文档叫相关文档，需将它们列出。
[1] ……
[2] ……
1.6 版本更新记录（Version Updated Record）
版本更新记录格式，如表4-8所示。
表4-8 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2001/02/06 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2001/02/25 |
成本估算维护 |
|
…… |
|
|
|
|
|
|
|
|
|
|
|
|
2．项目概述（Project Summary）
2.1 项目的目的（Project Purpose）
说明该软件项目的目的。
2.2 项目的范围（Project Scope）
本章的内容，主要参照《立项建议书》/《合同》与《用户需求报告》中相关章节，简要描述该软件项目的实现范围：
（1）主要功能点列表
（2）主要性能点列表
（3）主要接口列表
（4）本软件项目与其他软件项目之间的关系
（5）项目实施方面的限制等内容
2.3 项目的使用对象（Project Reader）
在本章节中，要识别出顾客与最终用户，对顾客与最终用户的情况要有简单描述，如最终用户的教育水平、技术水平及本系统的使用频度等。
3．项目组织（Project Organization）
项目组织是为开发项目而组建的队伍。建议以框图的方式表示项目的组织结构，并对每一组织的负责人和职责加以说明。可能的项目组织单元，如：
（1）项目管理组
（2）质量保证组
（3）配置管理组
（4）软件工程组
（5）测试组
（6）需求管理组
各组织说明如下：
（1）项目管理组，执行SPP和SPTO过程，对项目实施负全部责任。
（2）质量保证组，执行SQA过程，负责项目过程与产品的质量控制和报告。
（3）配置管理组，执行SCM过程，负责项目产品的版本、配置管理以及配置库状态报告。
（4）软件工程组，执行软件项目工程过程，负责项目产品的开发和维护工作。
（5）测试组，执行软件项目测试过程，负责项目产品的测试。
（6）需求管理组，负责对需求基线和需求变更进行管理。
4．软件生存周期（Software Life Cycle）
本章节记录项目策划生存期定义的工作结果，需要描述的主要内容：
（1）项目生存期框图
（2）项目生存期说明
5．规范、方法和标准（Criterion，Means，Standard）
本章节中需要描述采用的供开发和维护软件用的规范、方法和标准。
6．任务与工作产品（Task and Work Products）
项目任务和工作产品，是指根据项目生存期阶段划分的任务，和相应阶段的工作产品。记录项目生存期各阶段确定的需重点控制的阶段任务和工作产品。建议以表格的形式，列出生存期各阶段的任务和工作产品。项目包含的任务，如：
（1）需求分析
（2）系统设计
（3）系统实现
（4）测试
（5）产品交付
（6）产品维护
项目可能包含的产品，如：
（1）需求分析说明书
（2）规格分析说明书
（3）系统设计说明书
（4）源代码
（5）各种测试报告
（6）用户手册
（7）软件问题维护记录
7．工作产品、任务规模、工作量估计（Estimates of Work Product，Task Size and Workload）
项目规模估算是为了确定项目所需的人工。需要描述的主要内容有：
（1）对软件工作产品规模估计依据的简要描述。
（2）每种任务和工作产品规模估计的结果。
（3）规模估算的结果，建议用《任务规模和工作量估算表》的形式列出。
8．成本估计（Estimates of Costs）
成本估计，是指对项目完成过程中耗费的人力、物力、财力资源的估算。成本估计应按类别进行估算，可能的成本估算类别，如：
（1）直接人工
（2）直接费用
（3）间接成本
（4）制造费用
（5）管理费用
（6）不可预见费用
9．关键计算机资源计划（Critical Computer Resource Plan）
项目的关键计算机资源计划，是指系统在开发环境、测试环境、及用户目标环境中，对关键计算机资源，如计算机存储能力、计算机处理器速度、通信通道容量、服务器处理能力等的估计，使之能满足软件开发、测试、运行的要求。
10．软件项目进度计划（Software Project Schedule）
件项目进度计划，是对项目的进度、人员工作分工所做的计划，此计划依据上述各章的估算和分析结果，计划方式建议采用表格的形式。若采用工具制定项目计划，应将工具生成的图表作为项目计划的附件。本章节中需要描述的主要内容有：
（1）软件项目每个阶段的进度时间表
（2）设定的里程碑
（3）评审时间
（4）缓冲时间
11．配置管理计划（可单独做一个计划）（Configuration Management Planning）
本书单独作为一章论述。
12．质量保证计划（可单独做一个计划）（Software Quality Assurance Planning）
本书单独作为一章论述。
13．风险分析（Risks Analysis）
项目风险分析，是指对可能发生的将会对项目按预期时间、资源和预算完成产生重大影响的事件的分析包括：
（1）被识别出的重大风险事件：政策风险、技术风险、技能风险等。
（2）易发生重大风险事件的高风险区域：用户需求、设计、测试、运行平台等。
（3）重大风险事件的级别：功能不全、性能不稳、迅速受限制等。
（4）拟采取的预防措施：增加投入、纠错、延时等。
（5）风险事件发生后建议采用的处理措施：更改计划、降低难度系数等。
14．设备工具计划（Equipment and Tools Planning）
项目设备工具计划，是根据项目的工作指派及进度确定项目所需要的设备和工具，以确保设备工具在任务执行前到位，保证项目任务的顺利执行，在本计划中应包含以下几方面的内容：
（1）所需的设备
（2）基本的要求
（3）应到位的时间
15．培训计划（Training Planning）
项目的培训计划，应根据项目的特点和项目组成员技能情况，制定出项目组成员所需的培训内容，培训计划中应包含以下几方面：
（1）培训内容
（2）培训时间
（3）教员
（4）接受培训的人员
（5）培训目的（应达到的效果）
16．项目评审（Project Reviews）
项目评审，是对项目策划过程所做的定期性评审。其内容可分为：
（1）评审点
（2）评审周期
（3）评审层次
（4）评审条款和措施
（5）管理评审活动中提交的工作产品（列出被评审的工作产品）
17．度量（Measurement）
度量是按规定在项目进行过程中，需要采集的度量数据，以便量化地反映项目的进展情况，为管理者提供对项目进展的适当的可视性，同时度量数据是项目过程改善的数据基础。应规定项目度量值的记录人（一般为项目经理或其指定人员）、记录时间（一般以定期评审为基础）和记录的数据。常用的度量数据如：
（1）项目过程的评审次数
（2）项目计划修改次数
（3）项目各阶段的人员投入（各阶段投入的人月数）
（4）各类任务耗用时间统计（如设计、编码、测试、文档编写等）
（5）工作产品统计（如文档字数、功能点数、用况数、源代码行数等）
5《用户需求报告》
《用户需求报告》编写参考指南
1．概述（Summary）
本文档是进行需求规格定义、项目策划、概要设计的基础，也是用户进行验收的依据。
1.1 用户简介（User Synopsis）
在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行关于功能、进度、成本、性能等方面的平衡决策。
对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。
1.2 项目的目的与目标（Purpose and Aim of Project）
项目的目的是对开发本系统意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的, 项目的范围应能确保项目的目标可以达到。
对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统目标。
1.3 术语定义（Terms Glossary）
将该用户需求报告中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。
1.4 参考资料（References）
说明该用户需求报告使用的参考资料，如：
[1] 商务合同
[2] 招标书
[3] 用户领域的资料
[4] 用户需求调查表
[5] 参照的标准
每一个文件、文献要有标题、或文件号，发布或发表日期以及出版单位。
1.5 相关文档（Related Documents）
说明用户需求报告的变更，以及可能受变更影响的其他相关文档，如：
[1] 项目开发计划
[2] 需求规格说明书
1.6 版本更新信息（Version Updated Record）
版本更新记录格式，如表5-11所示。
表5-11 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2001/02/18 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2001/02/26 |
账本格式维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．现有系统描述（System in Existence）
2.1 组织结构与职责（Organizing Framework and Function）
将用户的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围很有帮助。取得用户的组织结构，是需求获取步骤中的工作任务之一。
2.2 岗位定义（Role Definition）
用户环境中的企业岗位和组织结构一样，也是分析人员理解企业业务的基础，是需求获取的工作任务，同时也是分析人员提取对象的基础。每个岗位的职责可以进行详细的描述，建议采用表格的形式，如表5-12所示。
表5-12 岗 位 定 义
|
编 号 |
岗 位 |
所在部门 |
职 责 |
相关的业务 |
|
1008 |
采购员 |
业务部 |
商品采购、合同签订、供应商选择 |
进货、合同管理 |
|
1009 |
…… |
|
|
|
|
|
|
|
|
|
对用户岗位的识别，也包括使用了计算机系统后的系统管理人员岗位。
2.3 作业流程（Busywork Flow）
企业的作业流程，首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图、Use case图、程序流程图加上文字说明。
图形可以将流程描述得很清楚，但是还要附加一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述的内容，需要用文字进行详细描述。
2.4 单据、账本、报表（Bill of Document，Account and Report）
现行系统中用户正在使用的正式的或非正式的单据、账本、报表等可以收集起来，并进行穷举、分类、归纳。单据、账本、报表是用户系统中信息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。
2.4.1 单据（Bill of Document）
单据的格式可用表格描述，如表5-13所示。
表5-13 单据的描述格式
|
单据名称 |
|
|
用途 |
|
|
使用单位 |
|
|
制作单位 |
|
|
频率 |
|
|
高峰时数据流量 |
|
各数据项的详细说明如下：
|
序号 |
数据项中文名 |
数据项英文名 |
类型、长度、精度 |
数据项的取值范围 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
|
3 |
|
|
|
|
2.4.2 账本（Account）
因为账本上的数据是统计数据，所以一个账本一般对应一张中间表，账本的格式可用表格描述，如表5-14所示。
表5-14 账本的描述格式
|
账本名称 |
|
|
用途 |
|
|
使用单位 |
|
|
制作单位 |
|
|
频率 |
|
|
高峰时数据流量 |
|
各数据项的详细说明如下：
|
序号 |
数据项中文名 |
数据项英文名 |
数据项类型、长度、精度 |
数据来源 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
|
3 |
|
|
|
|
2.4.3 报表（Report）
因为报表上的数据是统计数据，所以一个报表一般对应一张中间表，报表的格式可用表格描述，如表5-15所示。
2.5 存在的问题（Existent Question）
在现行的系统中，决策层、管理层、操作层各存在哪些方面的问题需要计算机来解决，尤其是决策层、管理层这些问题中包含了用户的需求与期望，有些问题是新系统可以解决的，有些问题则不是。
表5-15 报表的描述格式
|
报表名称 |
|
|
用途 |
|
|
使用单位 |
|
|
制作单位 |
|
|
频率 |
|
|
高峰时数据流量 |
|
各数据项的详细说明如下：
|
序号 |
数据项中文名 |
数据项英文名 |
数据项类型、长度、精度 |
数据来源 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
|
3 |
|
|
|
|
2.6 可能的变化（Possible Change）
对于现行的系统，将来可能会有哪些变化，需要在此描述。企业中的变化是永恒的，系统分析员需要描述哪些变化可能引起系统范围变更。
3．目标系统功能需求（Function of Target System）
3.1 功能需求分析（Function Analysis）
决策层、管理层、操作层各有哪些具体功能要求。
3.2 功能需求点列表（Function List）
在功能需求分析完成后，要详细列出用户需求功能点列表，提供给后续设计、编程、测试中使用，更是为了用户测试验收中使用。功能需求点列表的格式，如表5-16所示。
表5-16 功能需求点列表
|
编 号 |
功 能 名 称 |
使 用 部 门 |
使 用 岗 位 |
功 能 描 述 |
输 入 内 容 |
输 出 内 容 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
4．目标系统性能需求（Performance of Target System）
4.1 时间要求（Time Request）
如：
（1）响应时间，如查询的最长等待时间。
（2）更新处理时间，如记账的最长时间。
（3）数据的转换和传送时间，如远程数据传输的时间要求。
（4）解题时间。
4.2 空间要求（Space Request）
如：
（1）支持的终端数。
（2）支持的并行操作的使用者数。
（3）处理的文件和记录数。
（4）表和文件的大小规模（要按可预见的增长，对数据及其分量的存储要求做出估算）。
（5）处理任务的数量。
（6）在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数。
（7）对输入和输出数据的精度要求。
（8）对处理和传输过程中的精度要求。
4.3 性能需求点列表（Performance List）
详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。需求性能点列表的格式，如表5-17所示。
表5-17 性能需求点列表
|
编 号 |
性能名称 |
使用部门 |
使用岗位 |
性能描述 |
输入内容 |
输出内容 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
5．目标系统界面与接口需求（Interface of Target System）
5.1 界面需求（Interphase Requirement）
界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义，某些功能模块的特殊的界面要求。
（1）输入设备：键盘、鼠标、条码扫描器、扫描仪等；
（2）输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等；
（3）显示风格：图形界面、字符界面、IE界面等；
（4）显示方式：1024*768、640*480等；
（5）输出格式：显示布局、打印格式等。
5.2 接口需求（Interface Requirement）
与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。
（1）与系统特殊外设的接口，如CT机、磁共振、柜员机（ATM）、IC卡、盘点机等。
（2）与中间件的接口，要列出接口规范、入口参数、出口参数、传输频率等。
应在此列举出所有的外部接口名称、接口标准、规范。外部接口列表，如表5-18所示。
表5-18 外部接口需求点列表
|
编 号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
6．目标系统其他需求（Other Requirements of Target System）
6.1 安全性（Security）
6.2 可靠性（Dependability）
6.3 灵活性（Agility）
6.4 特殊需求（Special requirements）
如：
（1）进度需求：系统的阶段进度要求。
（2）资金需求：投资额度。
（3）运行环境需求：平台、体系结构、设备要求。
（4）培训需求：用户对培训的需求，是否提供多媒体教学光盘。
（5）推广需求：推广的要求，如在上百个远程部门推广该系统，是否要有推广的支持软件。
7．目标系统假设与约束条件（Suppose and Restriction of Target System）
假设与约定条件是对预计的系统风险的描述, 如：
（1）法律、法规和政策方面的限制。
（2）硬件、软件、运行环境和开发环境方面的条件和限制。
（3）可利用的信息和资源。
（4）系统投入使用的最晚日期。
（5）需求中的风险分析：技术风险、技能风险、时间风险、资源风险。
6《需求规格说明书》
《需求规格说明书》编写参考指南
1．概述（Summary）
本文档是进行项目策划、概要设计和详细设计的基础，也是软件企业测试部门进行内部验收测试的依据。
1.1 用户简介（User Synopsis）
在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行功能、进度、成本、性能等方面的平衡决策。
对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。
1.2 项目的目的与目标（Purpose and Aim of Project）
项目的目的是对开发本系统的意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的, 项目的范围应能确保项目的目标可以达到。
对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统的目标。
1.3 术语定义（Terms Glossary）
将该需求规格说明书中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。
1.4 参考资料（References）
说明该用户需求报告使用的参考资料，如：
[1] 商务合同
[2] 招标书
[3] 用户领域的资料
[4] 用户需求调查表
[5] 用户需求报告
[6] 参照的标准
每一个文件、文献要有标题、或文件号，发布或发表日期以及出版单位。
1.5 相关文档（Related Documents）
[1] 项目开发计划
[2] 概要设计说明书
[3] 详细设计说明书
1.6 版本更新信息（Version Updated Record）
版本更新记录格式，如表5-19所示。
表5-19 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2001/03/03 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2001/03/16 |
业务模型维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．目标系统描述（System in Target）
2.1 组织结构与职责（Organizing Framework and Function）
将目标系统的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围很有帮助。取得用户的组织结构，是需求获取步骤中的工作任务之一。
2.2 角色定义（Role Definition）
用户环境中的企业角色，和组织机构一样，也是分析人员理解企业业务的基础，是需求获取的工作任务，同时也是分析人员提取对象的基础。每个角色的授权可以进行详细的描述，建议采用表格的形式，如表5-20所示。
表5-20 角 色 定 义
|
编号 |
角色 |
所在部门 |
职 责 |
相关的业务 |
|
1008 |
采购员 |
业务部 |
商品采购、合同签订、供应商选择 |
进货、合同管理 |
|
1009 |
|
|
|
|
|
|
|
|
|
|
对用户角色的识别也包括使用了计算机系统后的系统管理人员。
2.3 作业流程（业务模型）（Busywork Flow）（Operation Model）
目标系统的作业流程是对现有系统作业流程的重组、优化与改进。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图、Use case图、其他示意图的形式。
图形可以将流程描述得很清楚，但是还要附加一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述的内容，需要用文字进行详细描述。
2.4 单据、账本、报表（Bill of Document，Account and Report）
目标系统中用户将使用的正式单据、账本、报表等，并进行穷举、分类、归纳。单据、账本、报表是用户系统中信息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。
2.4.1 单据（Bill of Document）
因为单据上的数据是原始数据，所以一种单据一般对应一个实体，一个实体一般对应一张基本表。单据的格式可用表格描述，如表5-21所示。
表5-21 单据的描述格式
|
单据名称 |
|
|
用途 |
|
|
使用单位 |
|
|
制作单位 |
|
|
频率 |
|
|
高峰时数据流量 |
|
各数据项的详细说明如下：
|
属性中文名 |
属性英文名 |
属性类型、长度、精度 |
属性的值域 |
Pk/fk |
|
|
|
|
|
|
|
|
|
|
|
|
2.4.2 账本（Account）
因为账本上的数据是统计数据，所以一个账本一般对应一张中间表，账本的格式可用表格描述，如表5-22所示。
表5-22 账本的描述格式
|
账本名称 |
|
|
用途 |
|
|
使用单位 |
|
|
制作单位 |
|
|
频率 |
|
|
高峰时数据流量 |
|
各数据项的详细说明如下：
|
序号 |
数据项中文名 |
数据项英文名 |
数据项类型、长度、精度 |
数据项算法 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
|
3 |
|
|
|
|
2.4.3 报表（Report）
因为报表上的数据是统计数据，所以一个报表一般对应一张中间表，报表的格式可用表格描述，如表5-23所示。
表5-23 报表的描述格式
|
报表名称 |
|
|
用途 |
|
|
使用单位 |
|
|
制作单位 |
|
|
频率 |
|
|
高峰时数据流量 |
|
各数据项的详细说明如下：
|
序号 |
数据项中文名 |
数据项英文名 |
数据项类型、长度、精度 |
数据项算法 |
|
1 |
|
|
|
|
|
2 |
|
|
|
|
|
3 |
|
|
|
|
2.5 可能的变化（Possible Change）
对于目标系统，将来可能会有哪些变化，需要在此描述。企业中的变化是永恒的，系统分析员需要描述哪些变化可能引起系统范围变更。
3．目标系统功能需求（Function of Target System）
3.1 功能需求分析（Function Analysis）
决策层、管理层、操作层各有哪些具体功能要求。
3.2 功能需求点列表（功能模型）（Function List）（Function Model）
在功能需求分析完成后，要详细列出用户需求功能点列表，提供给续设计、编程、测试中使用，更是为了用户测试验收中使用。需求功能点列表的格式，如表5-24所示。
表5-24 功能需求点列表
|
编号 |
功能名称 |
使用部门 |
使用岗位 |
功能描述 |
输入 |
系统响应 |
输出 |
|
1 |
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
4．目标系统性能需求（Performance of Target System）
4.1 时间要求（Time Request）
如：
（1）响应时间，如查询的最长等待时间。
（2）更新处理时间，如记账的最长时间。
（3）数据的转换和传送时间，如远程数据传输的时间要求。
（4）解题时间。
4.2 空间性能（Space Request）
如：
（1）支持的终端数。
（2）支持的并行操作的使用者数。
（3）处理的文件和记录数。
（4）表和文件的大小规模（要按可预见的增长，对数据及其分量的存储要求做出估算）。
（5）处理任务的数量。
（6）在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数。
（7）对输入和输出数据的精度要求。
（8）对处理和传输过程中的精度要求。
4.3 性能需求点列表（性能模型）（Performance List）（Performance Model）
详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。需求性能点列表的格式，如表5-25所示。
表5-25 性能需求点列表
|
编号 |
性能名称 |
使用部门 |
使用岗位 |
性能描述 |
输入 |
系统响应 |
输出 |
|
1 |
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
5．目标系统界面与接口需求（Interface of Target System）
5.1 界面需求（Interphase Requirement）
界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义，某些功能模块的特殊的界面要求。
（1）输入设备：键盘、鼠标、条码扫描器、扫描仪等；
（2）输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等；
（3）显示风格：图形界面、字符界面、IE界面等；
（4）显示方式：1024×768、640×480等；
（5）输出格式：显示布局、打印格式等。
5.2 接口需求点列表（接口模型）（Interface Requirement）（Interface Model）
（1）与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。
（2）与系统特殊外设的接口，如CT机、磁共振、柜员机（ATM）、IC卡、盘点机等。
（3）与中间件的接口，要列出接口规范、入口参数、出口参数、传输频率等。
应在此列举出所有的外部接口名称、接口标准、规范。外部接口列表，如表5-26所示。
表5-26 接口需求点列表
|
编号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
6．目标系统其他需求（Oher Requirement of Target System）
6.1 安全性（Security）
6.2 可靠性（Dependability）
6.3 灵活性（Agility）
6.4 特殊需求（Special Requirement）
如：
（1）进度需求：系统的阶段进度要求。
（2）资金需求：投资额度。
（3）运行环境需求：平台、体系结构、设备要求。
（4）培训需求：用户对培训的需求，是否提供多媒体教学光盘。
（5）推广需求：推广的要求，如在上百个远程的部门推广该系统，是否要有推广的支持软件。
7．目标系统假设与约束条件（Suppose and Restriction of Target System）
假设与约定条件是对预计的系统风险的描述,如：
（1）法律、法规和政策方面的限制。
（2）硬件、软件、运行环境和开发环境方面的条件和限制。
（3）可利用的信息和资源。
（4）系统投入使用的最晚时间。
（5）需求中的风险分析：技术风险、技能风险、时间风险、资源风险。
7《需求报告 / 需求规格说明书评审记录表》
《用户需求报告 / 需求规格说明书评审记录表》
（Review Table of Requirements）
|
项目名称 |
|
项目经理 |
|
||||
|
评审阶段 |
用户需求报告/需求规格说明书 |
第 次评审 |
|||||
|
评审组组长 |
|
评审时间 |
|
评审地点 |
|
||
|
评审组成员 |
|
||||||
|
不符合项跟踪记录（Check list of noncompliance items） |
|||||||
|
不符合项名称 |
不符合项内容 |
限期改正时间 |
实际改正时间 |
测试合格时间 |
测试员签字 |
审计员签字 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
评审意见 |
|
||||||
|
评审结论 |
|
||||||
评审组长签字： 评审组成员签字：
表5-28 《需求变更管理表》
（Modification Table of Requirements）
|
项目名称 |
|
申请日期 |
|
|
用户名称 |
|
审批日期 |
|
|
变更原因 |
|
实际变更日期 |
|
|
原来需求 |
|
||
|
变更内容 |
|
||
|
审批意见 |
|
||
申请人： 审批人：
8“图书馆信息系统”
“图书馆信息系统”数据模型设计案例
“图书馆信息系统”的概念数据模型CDM（见图6-10）和物理数据模型PDM（见图6-11）分析。
首先，介绍一下在E-R图中实体的表示法，如图6-10所示。一个矩形框表示一个实体，框内第一部分（第一行）的文字表示该实体的名称，如“图书”。第二部分表示该实体的多个属性，每个属性占一行，如“图书号、书名、单价、作者”等。带下划线的属性为主关键字，即主键PK（或主码），如“图书号”。两个实体之间的关系，用一条连线表示。关系有三种：一对一关系，就是一条连线；一对多关系，多的一端是一个三叉线（ERwin工具中为一个黑色小圆球）；多对多关系，两端都是三叉线。连线的一端若有一个小圆圈，则表示非强制型的关系；连线的一端若有一个小十字架，则表示强制型的关系。
图6-10 “图书馆信息系统”的概念数据模型CDM
系统的E-R图又称为系统的概念数据模型CDM，有了它以后，利用PowerDesigner工具，就能自动生成物理数据模型PDM。
首先分析“图书馆信息系统”的概念数据模型CDM，如图6-10所示。因为图书馆的主要功能不外乎两点，藏书与为读者服务。其他许多功能都是围绕这两项功能而展开的。所以“图书馆信息系统”的主要实体是“图书”和“读者”。
“图书”的属性有图书号、书名、作者、出版社、单价等，“读者”的属性有读者号、姓名、电话等。
由于一本图书可以被多个读者在不同时间借阅，一名读者又可以一次或多次借阅多本图书，所以该两个实体之间是多对多的关系。为了消除这个多对多关系，在两者之间插入第3个实体，该实体取名为“借还书”。“借还书”至少有两个属性：借书还书时间、借书还书标志。另外，它还有两个外键，图书号和读者号。当增加“借还书”这个实体之后，原来一个多对多的关系，现在变为两个一对多的关系：“图书”对“借还书”，“读者”对“借还书”。 “图书馆信息系统”中还有许多其他实体，它们都是围绕这3个主要实体及其关系而展开的。这3个实体是“图书馆信息系统”的核心。例如，“书库”和“单位”这两个实体，就是分别围绕“图书”和“读者”而展开的。“书库”表示图书存放在什么地方，以及该书是否借出，即该本书的架位号、架位地址，以及借出标志位的状态。由于一个架位号上可放多本书，所以“书库”和“图书”是一对多的关系。同样，“单位”表示读者在什么单位，即该读者的单位名称、单位地址和单位电话等，由于一个单位可有多个读者，所以“单位”和“读者”是一对多的关系。以上实体、属性、关系如图6-10所示。
图6-11 “图书馆信息系统”的物理数据模型PDM
再来分析“图书馆信息系统”的物理数据模型PDM，如图6-11所示。此PDM是由CDM生成的。不难发现：在生成PDM的过程中，凡是CDM中的一对多的关系，主表中的主键PK都自动拷贝到子表中去，作为子表的外键FK，这就是数据库设计工具PowerDesigner的一项功能。该PDM比较整齐规范，那是因为在生成之后进行了手工调整。
9《概要设计说明书》
《概要设计说明书》编写参考指南
1．导言（Introduction）
本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。
1.1 目的（Purpose）
本文档的目旨在推动软件工程的规范化，使设计人员遵循统一的概要设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。
1.2 范围（Scope）
本文档用于软件设计阶段的概要设计，它的上游（依据的基线）是《需求分析规格书》，它的下游是《详细设计说明书》，并为《详细设计说明书》提供测试的依据。
软件概要设计的范围是：软件系统总体结构设计、全局数据库和数据结构设计、外部接口设计、主要部件功能分配设计、部件之间的接口设计等方面的内容。该范围应覆盖《需求规格说明书》中的功能点列表、性能点列表、接口列表。
1.3 命名规则（Naming Rule）
变量对象命名规则：申明全局变量、局部变量对象的命名规则。
数据库对象命名规则：申明数据库表名、字段名、索引名、视图名等对象的命名规则。
1.4 术语定义（Terms Glossary）
术语定义或解释一般用表格形式给出，如表6-5所示。
表6-5 术语定义或解释表
|
序 号 |
术 语 名 称 |
术 语 定 义 |
|
1 |
总体结构 |
软件系统的总体逻辑结构。按照不同的设计方法，有不同的总体逻辑结构。若采用面向功能或面向数据的设计方法，则总体逻辑结构为一树形的功能模块结构图。若采用面向对象或面向部件（构件）的设计方法，则总体逻辑结构为部件（构件）的组装图 |
|
2 |
外部接口 |
本软件系统与其他软件系统之间的接口，接口设施可以是中间件。接口描述包括：传输方式、带宽、数据结构、传输频率、传输量、传输协议 |
|
3 |
数据结构 |
数据结构包括：数据库表的结构、其他数据结构等 |
|
4 |
概念数据 模型CDM |
关系数据库的逻辑设计模型，叫做概念数据模型。主要内容包括一张逻辑E-R图及其相应的数据字典 |
|
5 |
物理数据 模型PDM |
关系数据库的物理设计模型，叫做物理数据模型。主要内容包括一张物理表关系图及其相应的数据字典 |
|
6 |
视图 |
在基表或其他视图之上建立的一张虚表，叫做视图，它具有物理表的许多性质，在数据处理和授权上很有用 |
|
7 |
角色 |
数据库中享有某些特权操作的用户，叫做角色。角色的权利通过授权来实现 |
|
8 |
子系统 |
具有相对独立功能的小系统叫做子系统。一个大的软件系统可以划分为多个子系统，每个子系统可由多个模块或多个部件组成 |
|
9 |
模块 |
具有功能独立、能被调用的信息单元叫做模块。模块是结构化设计中的概念 |
|
10 |
内部接口 |
软件系统内部各子系统之间、各部件之间、各模板之间的接口，叫做内部接口。接口描述包括：调用方式、入口信息、出口信息等 |
|
11 |
相关文件 |
相关文件是指当本文件内容变更后，可能引起变更的其他文件。如需求分析报告、详细设计说明书、测试计划、用户手册 |
|
12 |
参考资料 |
参考资料是指本文件书写时用到的其他资料。如各种有关规范、模板、标准、准则 |
1.5 参考资料（References）
[1] 用户需求报告
[2] 软件开发合同
[3] 数据库设计规范
[4] 命名规范
1.6 相关文档（Related Documents）
[1] 《详细设计说明书》
[2] 源程序清单
[3] 测试计划及报告
[4] 《用户使用手册》
1.7 版本更新记录（Version Updated Record）
版本更新记录格式，如表6-6所示。
表6-6 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2001/02/18 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2001/02/26 |
E-R图维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．总体设计（Design of Collective）
2.1 总体结构设计（Design of Collective Structure）
软件系统的总体逻辑结构，按照不同的设计方法，有不同的总体逻辑结构。本指南以结构化设计方法为主，画出系统总体结构图，列出系统的功能模块清单编号、名称、功能，并尽可能描绘出功能模块之间的关系。若用面向对象的Rose工具进行分析和设计，则遵照Rose的要求进行。
总体结构示意图，如图6-13所示。
图6-13 总体结构示意图
2.2 运行环境设计（Design of Running Environment）
该软件系统的运行环境：
硬件平台：
（1）服务器的最低配置要求
（2）工作站的最低配置要求
（3）外设的要求
软件平台：
（1）服务器操作系统
（2）数据库管理系统
（3）中间件
（4）客户端的操作系统
（5）客户端的平台软件
网络平台：
（1）通信协议
（2）通信带宽
2.3 子系统清单（Subsystem List）
子系统清单，如表6-7所示。
表6-7 子系统清单
|
子系统编号 |
子系统英文名 |
子系统功能简述 |
子系统之间的关系 |
|
SS1 |
|
|
|
|
SS2 |
|
|
|
|
SS3 |
|
|
|
2.4 功能模块清单（Function Module List）
功能模块清单，如表6-8所示。
表6-8 功能模块清单
|
模 块 编 号 |
模块英文名 |
模块功能简述 |
模块的接口简述 |
|
M 1-1 |
|
|
|
|
M 1-2 |
|
|
|
|
M 2-1 |
|
|
|
|
M 2-2 |
|
|
|
3．模块（部件）功能分配（Functional Distribution of Module）
具有功能独立、能被调用的信息单元叫做模块。模块是结构化设计中的概念，部件是面向对象设计中的概念。
模块功能分配的目的，就是为了将具有相同功能的模块合并，从中提取公用模块，形成公用部件，按照构件或中间件的方式加以实现，作为本系统的公用资源，甚至作为公司级组织的公用资源，从而充实公司级的构件库或中间件库，优化系统设计，加快开发速度，提高开发质量。
3.1 专用模块功能分配（Functional Distribution of Expert Module）
专用模块功能分配，如表6-9所示。
表6-9 专用模块功能分配
|
专用模块编号 |
模块英文名 |
模块详细功能分配 |
模块的接口标准 |
|
M1-1 |
|
|
|
|
M1-2 |
|
|
|
|
M2-1 |
|
|
|
|
M2-2 |
|
|
|
3.2 公用模块功能分配（Function Distribute of Public Module）
公用模块功能分，如表6-10所示。
表6-10 公用模块功能分配
|
公用模块编号 |
模块英文名 |
模块详细功能分配 |
模块的接口标准 |
|
G-1 |
|
|
|
|
G-2 |
|
|
|
|
G-3 |
|
|
|
4．数据结构设计（Design of Data Structure）
数据库设计的工具目前主要有3个：ERwin，PowerDesigner，OracleDesigner。后面两种工具都支持中文的概念数据模型设计，并能自动将概念数据模型转换为物理数据模型，自动生成建表程序和主键索引程序。前面一种工具只能支持英文的物理数据模型设计。3个工具的共同特点是都能生成E-R图及其相应的数据字典。
4.1 数据库表名清单（DB Table List）
数据库表名清单，如表6-11所示。
表6-11 数据库表名清单
|
序号 |
中文表名 |
英文表名 |
表功能说明 |
|
1 |
|
|
|
|
2 |
|
|
|
|
3 |
|
|
|
4.2 数据库表之间关系说明（Relation of DB Table）
可以用E-R图表示，也可以用文字说明。
4.3 数据库表的详细清单（Particular List of DB Table）
每个表的详细清单内容包括：表名、字段中文名、字段英文名、字段的类型、宽度、精度、主键/外键、空否、取值约束（默认值、最大值、最小值）、索引否。同时要指出该表的索引：索引文件名、索引字段名、索引特性（主键索引、惟一索引unique、聚集索引clustered）。详细清单可以用列表给出，如表6-12所示。
表6-12 表名：XXXX
|
序号 |
字段中文名 |
字段英文名 |
类型、宽度、精度 |
取值约束 |
空否 |
默认值 |
主键/外键 |
索引否 |
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
|
4.4 视图设计（View Design）
视图设计与授权有关，设计时参照需求文档的用户授权范围。视图设计中要给出视图的中文名、英文名，视图中的中文列名、英文列名、类型、宽度、精度，每一列的具体算法，对应的基本表名。
4.5 其他数据结构设计（Design of Other Data Structure）
此小节描述系统的其他数据结构设计内容。
5．接口设计（Interface Design）
对应每一个接口，都要详细列出下列内容。
（1）接口名称
（2）接口内容
（3）接口设施
（4）接口的数据结构
（5）接口的传输速率（Mbps）
（6）接口带宽
（7）接口协议
6．其他设计（Other Design）
本章描述前面没有说明的设计。
7．设计检查列表（Check-up List of Design）
按照需求文档的功能、性能和接口3个列表，设计出概要设计检查列表，以检查概要设计是否覆盖需求分析，没有覆盖就是不符合项，并将检查结果列出。
7.1 功能设计检查列表（Check-up List of Function Design）
功能设计检查列表，如表6-13所示。
表6-13 功能设计检查列表
|
编号 |
功能名称 |
使用部门 |
使用岗位 |
功能描述 |
输入内容 |
系统响应 |
输出内容 |
是否覆盖 |
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
|
7.2 性能设计检查列表（Check-up List of Performance Design）
性能设计检查列表，如表6-14所示。
表6-14 性能设计检查列表
|
编号 |
性能名称 |
使用部门 |
使用岗位 |
性能描述 |
输入内容 |
系统响应 |
输出内容 |
是否覆盖 |
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
|
7.3 接口设计检查列表（Check-up List of Interface Design）
接口设计检查列表，如表6-15所示。
表6-15 接口设计检查列表
|
编号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
是否覆盖 |
|
1 |
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
10《详细设计说明书》
《详细设计说明书》编写参考指南
1．导言（Introduction）
本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。
1.1 目的（Purpose）
本文档的目旨在推动软件工程的规范化，使设计人员遵循统一的详细设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。详细设计的详细程度，应达到可以编写程序的程度。
1.2 范围（Scope）
本文档用于软件设计阶段的详细设计，它的上游（依据的基线）是《概要设计说明书》，它的下游是源程序清单及单元测试计划，并为单元测试报告提供测试依据。该范围应覆盖《概要设计说明书》中的功能点列表、性能点列表、接口列表。
软件详细设计的范围是：各子系统的公用模块实现设计、专用模块实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等。
按照3层结构（B/A/S）的布局，详细设计应从下面3个方面进行。数据库服务器上的面向数据的设计：数据字典物理设计、基本表物理设计、中间表物理设计（报表设计）、临时表物理设计、视图物理设计、存储过程物理设计、触发器物理设计。应用服务器上的面向业务逻辑的设计：接口数据设计、中间件设计、数据通信传输设计、可视构件设计、非可视构件设计、角色授权设计、功能点设计（功能点列表设计）。浏览器上的面向对象的设计：录入修改界面设计、浏览查询界面设计、登录注册界面设计、信息发布界面设计。
1.3 术语定义（Terms Glossary）
术语定义，如表6-16所示。
表6-16 术语定义
|
序号 |
术语名称 |
术 语 定 义 |
|
1 |
详细设计 |
在概要设计的基础上，对其功能模块或部件进行实现设计，使编程人员据此能顺利书写出程序代码 |
|
2 |
存储过程 |
存放在数据库服务器上的一段程序，它能被其他程序调用，以完成对数据库表的某些规定操作 |
|
3 |
触发器 |
存放在数据库服务器上的一段程序，当触发条件满足时它就被执行，以完成对数据库表的某些规定操作 |
|
4 |
算法 |
详细设计中实现某项功能的数据处理方法及处理流程 |
1.4 参考资料（References）
[1] 《概要设计说明书》
[2] 《需求分析说明书》
[3] 《软件合同》
[4] 命名规范
[5] 程序设计规范
[6] 界面设计规范
1.5 相关文档（Related Documents）
[1] 源程序清单
[2] 单元测试计划及报告
[3] 《用户使用手册》
1.6 版本更新记录（Version Updated Rcord）
版本更新记录，如表6-17所示。
表6-17 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2001/0318 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2001/03/26 |
报表4格式维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．模块实现设计（Implemental Design of Module）
功能模块包括：登录注册模块、信息发布模块、菜单模块、录入修改模块、查询统计模块、数据处理模块、报表输出模块、前台网站模块、后台处理模块、数据传输与接收模块等等。详细设计是面向模块的，或者说是面向部件（或构件）的，不是面向组织结构或部门单位的。一个组织或单位，根据角色的授权，可以挂上某些功能模块。若为C/S或B/A/S结构，则要说明该模块运行在哪一层上。
2.1 公用模块设计（Design of Public Module）
公用模块的提取与设计特别重要，设计它的目的是为了复用，因此它直接影响到系统的详细设计、编程、运行的质量。每个公用模块的设计要包括如下内容：
（1）模块编号：按照命名规则，如：G-XXX，将此公用模块编号写上。
（2）模块名称：此公用模块的英文名。
（3）模块功能：详细列出此公用模块的所有功能。
（4）模块背景描述：对背景进行简单的描述。为什么需要此模块功能，其上下文环境。涉及业务背景内容，与需求相结合。
（5）模块算法设计：用伪语言（例如，if…endif，case…endcase， do…enddo，…）详细描述出此公用模块的算法，标准是使程序人员据此能顺利地书写程序。
（6）模块调用方法：详细列出调用的方式、入口参数、出口参数、异常处理。
（7）模块编写者：编写者姓名。
（8）模块编写日期：编写日期：yyyy/mm/dd。
（9）模块修订者：修订者姓名。
（10）模块修订日期：修订日期：yyyy/mm/dd。
（11）模块测试者：测试者姓名。
（12）模块测试日期：测试日期：yyyy/mm/dd。
2.2 专用模块设计（Design of Expert Module）
非公用模块是为了处理一些特殊需求，它不可复用，每个非公用模块设计包括如下内容：
（1）模块编号：按照命名规则，如：M1-XXX，将此专用模块编号写上。
（2）模块名称：此模块的中文名。
（3）模块功能：详细列出此模块的所有功能。
（4）模块背景描述：对背景进行简单的描述。为什么需要此模块功能，其上下文环境。涉及业务背景内容，与需求相结合。
（5）模块算法设计：用伪语言（例如，if…endif，case…endcase， do…enddo，…）详细描述出此专用模块的算法，标准是使程序人员据此能顺利地书写程序。
（6）模块编写者：编写者姓名。
（7）模块编写日期：编写日期：yyyy/mm/dd。
（8）模块修订者：修订者姓名。
（9）模块修订日期：修订日期：yyyy/mm/dd。
（10）模块测试者：测试者姓名。
（11）模块测试日期：测试日期：yyyy/mm/dd。
2.3 存储过程设计（Design of Storage Process）
存储过程是一种特殊的公用模块，它在数据库服务器上执行，这里将它单独列出来，规定其详细设计模板为：
（1）存储过程中文名：此存储过程的中文名。
（2）存储过程英文名：此存储过程的英文名。
（3）存储过程功能: 详细描述其功能。
（4）存储过程算法: 用伪语言详细描述其算法，使编程人员据此能顺利书写程序。
（5）存储过程调用方式：详细列出调用的方式、入口参数、出口参数、异常处理。
（6）模块编写者：编写者姓名。
（7）模块编写日期：编写日期：yyyy/mm/dd。
（8）模块修订者：修订者姓名。
（9）模块修订日期：修订日期：yyyy/mm/dd。
（10）模块测试者：测试者姓名。
（11）模块测试日期：测试日期：yyyy/mm/dd。
2.4 触发器设计（Design of Trigger）
触发器也是一种公用模块，不过它是隐式执行，这里将它单独列出来，规定其详细设计模板为：
（1）触发器中文名：此触发器的中文名。
（2）触发器英文名：此触发器的英文名。
（3）触发器功能：详细描述其功能。
（4）触发器算法：用伪语言详细描述其算法，使编程人员据此能顺利书写程序。
（5）触发器激活条件：详细描述其激活条件，使编辑人员据此能顺利书写程序。
（6）触发器编写者：编写者姓名。
（7）触发器编写日期：编写日期：yyyy/mm/dd。
（8）触发器修订者：修订者姓名。
（9）触发器修订日期：修订日期：yyyy/mm/dd。
（10）触发器测试者：测试者姓名。
（11）触发器测试日期：测试日期：yyyy/mm/dd。
注意：过多地使用触发器反而会使系统的效率降低。因此，凡是能用存储过程代替触发器功能的地方，一律用存储过程来实现。
3. 接口实现设计（Implemental Design of Interface）
每个外部接口实现模块的设计要包括如下内容：
（1）接口中文名称：此接口的中文名。
（2）接口英文名称：此接口的英文名。
（3）接口内容与功能：详细描述接口的内容与功能，如实现数据传输或数据交换。
（4）接口硬件设施：详细描述接口的硬件设施，如交换机、传感器或输出设备。
（5）接口软件或中间件：详细描述接口软件或中间件的名称、功能、使用方法、生产厂商。
（6）接口的数据结构：详细描述接口的数据结构，如文件结构、数据库表结构。
（7）接口的传输速率（Mbps）：定量说明每秒最大流量。
（8）接口带宽：定量说明带宽，如XXMbps。
（9）接口协议：说明具体协议。
（10）接口程序的算法：用伪语言详细描述其算法，使编码人员据此能顺利书写程序。
（11）接口编写者：编写者姓名。
（12）接口编写日期：编写日期：yyyy/mm/dd。
（13）接口修订者：修订者姓名。
（14）接口修订日期：修订日期：yyyy/mm/dd。
（15）接口测试者：测试者姓名。
（16）接口测试日期：测试日期：yyyy/mm/dd。
4．其他实现设计（Other Implemental Designs）
本章描述前面没有说明的设计。如部门角色授权设计、界面设计、包装设计、维护设计等。
4.1 角色授权设计（Accredited Design of Role）
授权表的横坐标表示角色（部件、单位或岗位），纵坐标表示功能模块，“●”表示授权。该授权表是工作站上菜单设计的依据，如表6-18所示。
表6-18 角色授权设计
|
模块名 |
角色1 |
角色2 |
角色3 |
角色4 |
角色5 |
|
|
模块英文名1 |
● |
|
|
|
|
|
|
模块英文名2 |
|
|
● |
● |
|
|
|
模块英文名3 |
|
● |
● |
|
● |
|
|
模块英文名4 |
● |
|
|
|
● |
|
|
模块英文名5 |
● |
● |
|
● |
|
|
|
模块英文名6 |
|
● |
|
|
● |
|
|
模块英文名7 |
|
|
● |
|
|
|
|
模块英文名8 |
|
● |
|
● |
|
|
|
… |
|
|
● |
|
● |
|
4.2 其他详细设计（Other Particular Designs）
根据需要进行设计。如界面设计、包装设计、维护设计等。
5．详细设计检查列表（Check-up List of Design）
按照概要设计文档的功能、性能和接口3个列表，设计出详细设计检查列表，以检查详细设计是否覆盖概要，没有覆盖就是不符合项，并将检查结果列出。
5.1 功能设计检查列表（Check-up List of Function Design）
功能设计检查列表，如表6-19所示。
表6-19 功能设计检查列表
|
编号 |
功能名称 |
使用部门 |
使用岗位 |
功能描述 |
输入内容 |
系统响应 |
输出内容 |
是否实现 |
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
|
5.2 性能设计检查列表（Check-up List of Performance Design）
性能设计检查列表，如表6-20所示。
表6-20 性能设计检查列表
|
编号 |
性能名称 |
使用部门 |
使用岗位 |
性能描述 |
输入内容 |
系统响应 |
输出内容 |
是否实现 |
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
|
5.3 接口设计检查列表（Check-up List of Interface Design）
接口设计检查列表，如表6-21所示。
表6-21 接口设计检查列表
|
编号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
是否实现 |
|
1 |
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
《概要设计说明书/详细设计说明书评审记录表》
（Review Table of Design）
|
项目名称 |
|
项目经理 |
|
|||
|
评审阶段 |
概要设计说明书/详细设计说明书 |
第 次评审 |
||||
|
评审组组长 |
|
评审时间 |
|
评审地点 |
|
|
|
评审组成员 |
|
|||||
|
不符合项跟踪记录 |
||||||
|
不符合项名称 |
不符合项内容 |
限期改正时间 |
实际改正时间 |
测试合格时间 |
测试员签字 |
审计员签字 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
评审意见 |
|
|||||
|
评审结论 |
|
|||||
评审组长签字： 评审组成员签字：
11《用户使用手册》
《用户使用手册》编写参考指南
1．前言(Preface)
提供手册的概述，在此可以说明编写这份手册的目的、指明本手册的读者。
1.1 内容简介(Introduction)
简单地介绍编写背景，系统适用的用户。
1.2 基本概念(Basic Concept)
说明定义的术语在本手册中的含义。
1.3 主要功能(Mostly Function)
对系统进行简单讲解和功能介绍。
1.4 操作流程(Operate Flow)
操作流程说明。全面模拟用户操作，从安装、进入、初始化、到用户具体操作，对整个流程进行描述。
1.5 步骤说明(Step Show)
针对操作流程的每一步进行说明。如果在使用说明中有相应的解释，应指明用户查找的位置。
2．功能(Function)
这部分包括用户使用的所有功能，是用户使用手册的最重要的部分，要详细描述。
2.1 使用流程(Use Flow)
描述具体功能的使用顺序。如果功能之中有分类，比如，有些功能用户用不到，有些用得到，就要分开写流程。
2.2 具体描述(Description)
描述顺序是按照使用流程的每一步进行的。
2.3 进行此功能的业务介绍(Operation Introduce)
对此功能进行简单介绍，说明所能完成的功能。
2.4 操作步骤(Handle Step)
用鼠标选择相应的功能，进入相应的界面，进行功能键以及栏目的介绍。
2.5 举例(Example)
针对某一功能，对于一些比较难的问题，应该进行举例说明。
2.6 特殊提示及注意事项(Prompt and Notice)
在使用说明中，每一部分都会归纳一些问题，需要提示用户或者让用户注意，应按照以下规定的格式进行编写：字体采用仿宋字，字号采用小五号字。
3．附录(Appendix)
对一些在正文中描述不够详尽的地方，可在附录中进行补充；用户经常遇到的问题及问题解答也可放在附录中。
12《用户安装手册》
《用户安装手册》编写参考指南
1．前言(Preface)
指明编制该手册的目的和预期的读者，简介该系统的运行环境：操作系统OS，数据库系统DBMS，C/S二层结构或B/A/S三层结构，界面特点，以及技术特色。
1.1 内容简介(Introduction)
介绍本书提供的几个部分：简单介绍大概内容。
1.2 使用约定(Use Assumpsit)
提示：安装过程的一些好的方法。
注意：安装过程中特殊注意的地方。
警告：指出危险动作或状态，否则，会对您的安装造成破坏。
2．单机版的安装及配置(Installation and Configuration for PC)
2.1 运行环境(Run Environment)
（1）硬件环境：列出运行本系统所要求的硬设备的最小配置。微机要求包括型号、内存、硬盘，显示器要求，以及一些其他的I/O设备。
（2）软件环境：列出运行本系统所需要的支持软件。如操作系统，程序语言以及数据库管理系统。
2.2 安装单机版(Installation for PC)
（1）简单介绍单机版打包光盘的定义和内容。
（2）介绍该系统单机版的安装步骤。
2.3 安装后的系统配置(Configuration After Installation)
介绍系统安装之后，查看该系统配置信息的情况，以确定是否需要改动，是否是最优配置。
另外，运行系统的时候，有时会出现数据库联接不成功。在这部分应介绍会有哪几种可能的原因，并分别简述。
3．网络版的安装及配置(Installation and Configuration for Network)
3.1 运行环境(Run Environment)
除了对硬件环境提出要求外，对软件环境的要求应列出运行本系统所需的操作系统、与操作系统兼容的网络环境、程序语言以及数据库管理系统。
另外，还应简单介绍一下安装网络和数据库所需注意事项和可参考的工具书。
3.2 安装网络版(Installation for Network)
介绍该系统网络版的安装步骤。
如何进行系统环境配置。
数据库的默认用户及口令等。
3.3 安装后的系统配置(Configuration after Installation)
4．附录(Appendix)
附录1
安装过程提供的技术支持。说明技术支持的几种方式，及常见安装疑难问题解答。
附录2
参考资料，应写上书名、版本号、作者、出版社、出版日期。
13《测试报告》
《测试报告》编写参考指南
1. 概述(Summary)
1.1 项目简介(Project Synopsis)
在本章节中简介项目的基本情况。
1.2 术语定义(Terms Glossary)
将该测试报告中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。
1.3 参考资料(References)
说明该测试报告使用的参考资料，如：
[1]《商务合同》
[2]《用户需求报告》
[3]《需求规格说明书》
1.4 版本更新信息(Version Updated Record)
版本更新记录格式，如表9-3所示。
表9-3 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2002/02/18 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2002/02/26 |
不符合项测试 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. 目标系统功能需求(Function of Target System)
由《用户需求报告》/《需求规格说明书》拷贝到的功能需求点列表，如表9-4所示。
表9-4 功能需求点列表
|
编号 |
功能名称 |
使用部门 |
使用岗位 |
功能描述 |
输入内容 |
输出内容 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
3. 目标系统性能需求(Performance of Target System)
由《用户需求报告》/《需求规格说明书》拷贝到的需求性能点列表，如表9-5所示。
表9-5 性能需求点列表
|
编号 |
性能名称 |
使用部门 |
使用岗位 |
性能描述 |
输入内容 |
输出内容 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
4. 目标系统接口需求(Interface of Target System)
由《用户需求报告》/《需求规格说明书》拷贝到的接口列表，如表9-6所示。
表9-6 外部接口需求点列表
|
编号 |
接口名称 |
接口规范 |
接口标准 |
入口参数 |
出口参数 |
传输频率 |
|
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
5. 功能测试报告(Report for Function Test)
搭建功能测试平台，使测试平台与运行平台一致。按照功能点列表内容，设计测试用例（输入/输出内容），进行现场测试，记录测试数据，评定测试结果。测试活动的记录格式，如表9-7所示。
表9-7 功能测试记录
|
编号 |
功能名称 |
功能描述 |
用例输入内容 |
用例输出内容 |
发现问题 |
测试结果 |
测试时间 |
测试人 |
|
1 |
|
|
|
|
|
√ |
|
|
|
2 |
|
|
|
|
|
√ |
|
|
|
3 |
|
|
|
|
|
√ |
|
|
|
4 |
|
|
|
|
|
× |
|
|
6. 性能测试报告(Rreport for Performance Test)
搭建性能测试平台，使测试平台与运行平台一致。按照性能点列表内容，设计测试用例（输入/输出内容），进行现场测试，记录测试数据，评定测试结果。测试活动的记录，如表9-8所示。
表9-8 性能测试记录
|
编号 |
性能名称 |
性能描述 |
用例输入内容 |
用例输出内容 |
发现问题 |
测试结果 |
测试时间 |
测试人 |
|
1 |
|
|
|
|
|
√ |
|
|
|
2 |
|
|
|
|
|
√ |
|
|
|
3 |
|
|
|
|
|
× |
|
|
|
4 |
|
|
|
|
|
√ |
|
|
7. 接口测试报告(Report for Interface Test)
搭建接口测试平台，使测试平台与运行平台一致。按照接口列表内容，设计测试用例(输入/输出内容)，进行现场测试，记录测试数据，评定测试结果。测试活动的记录，如表9-9所示。
表9-9 接口测试记录
|
编号 |
接口名称 |
入口参数 |
出口参数 |
传输频率 |
发现问题 |
测试结果 |
测试时间 |
测试人 |
|
1 |
|
|
|
|
|
× |
|
|
|
2 |
|
|
|
|
|
√ |
|
|
|
3 |
|
|
|
|
|
√ |
|
|
8. 不符合项列表(Check List of Noncompliance Items)
将测试中的所有不符合项(Bug项)，整理后分别记录到表9-10、表9-11和表9-12中。
表9-10 功能测试不符合项列表
|
编号 |
功能名称 |
功能描述 |
用例输入内容 |
用例输出内容 |
发现问题 |
测试结果 |
测试时间 |
测试人 |
|
1 |
|
|
|
|
|
× |
|
|
|
2 |
|
|
|
|
|
× |
|
|
|
3 |
|
|
|
|
|
× |
|
|
|
4 |
|
|
|
|
|
× |
|
|
表9-11 性能测试不符合项列表
|
编号 |
性能名称 |
性能描述 |
用例输入内容 |
用例输出内容 |
发现问题 |
测试结果 |
测试时间 |
测试人 |
|
1 |
|
|
|
|
|
× |
|
|
|
2 |
|
|
|
|
|
× |
|
|
|
3 |
|
|
|
|
|
× |
|
|
|
4 |
|
|
|
|
|
× |
|
|
表9-12 接口测试不符合项列表
|
编号 |
接口名称 |
入口参数 |
出口参数 |
传输频率 |
发现问题 |
测试结果 |
测试时间 |
测试人 |
|
1 |
|
|
|
|
|
× |
|
|
|
2 |
|
|
|
|
|
× |
|
|
|
3 |
|
|
|
|
|
× |
|
|
以上不符合项，限期XX天内改正。改正完毕后重新进行回归测试。
9. 测试结论(Test Verdict)
当测试完成之后，测试组应对本次测试做出结论。格式如下：
测试日期：
测试地点：
测试环境：
参与测试的人员：
列出系统的强项：
列出系统的弱项：
列出不符合项的统计结果：
测试组组长签字：
测试组成员签字：
14软件质量保证关键过程域SQA
CMM2中“软件质量保证”关键过程域SQA详细说明文档
Software Quality Assurance
(a key process area for Level2：Repeatable)
软件质量保证的目的，是向管理者提供软件项目正在使用的过程和正在构造的产品的可视性。
软件质量保证包括评审和审计软件产品及活动，以验证它们符合相应的规程和标准，给项目经理和其他有关经理提供评审和审计结果。
在软件项目的早期阶段，软件质量保证组与软件项目一起工作，制定计划、标准和规程等。这些计划、标准和规程，将增加软件项目的价值，并将满足项目和组织方针上的要求。通过参与制定计划、标准和规程，软件质量保证组帮助确保这些计划、标准和规程适合项目的需要，并且帮助验证这些计划、标准和规程对完成整个软件生存周期中的评审和审计将是适用的。软件质量保证组在整个生存周期内评审项目活动，审计软件工作产品，并就软件项目是否遵守已制定的计划、标准和规程等，为管理者提供可视性。
首先，在软件项目内部处理符合性问题，如可能的话就解决它。对于那些无法在软件项目组内部解决的问题，软件质量保证组逐级上递该问题到恰当层次的管理者那里以求解决。
这个关键过程域，只包括该组履行软件质量保证功能的实践。而识别软件质量保证组要评审和审计的具体活动和工作产品的实践，一般包含在其他关键过程域的验证实施共同特性之中。
（作者注：为了实现软件质量保证的目的，CMM规定了该KPA有“4个目标、1项约定、4项能力、8项活动、1项测量、3项验证”，该KPA的17个关键实践KP，就分布在“执行约定、执行能力、执行活动、测量和分析、验证实施”之中，具体内容简述如下。）
目标（Goals）
目标1：软件质量保证活动是有计划的。
目标2：软件产品和活动遵守适用的标准、规程和需求，能得到客观验证。
目标3：受影响的组和个人接到了软件质量保证活动和结果的通知。
目标4：高级管理者处理在软件项目内部不能解决的不符合问题。
执行约定（Commitment to Perform，CO）
约定1：项目遵守书面的实施软件质量保证(SQA)的组织方针。
该方针一般规定：
1．对全部软件项目，SQA功能到位；
2．SQA有一个向高级管理者报告质量问题的独立渠道，它独立于：
——项目经理
——项目软件工程组
——其他软件有关组
其他软件有关组的例子有：
──软件配置管理组
──文档支持组
组织必须确定一种组织机构，它在组织的战略经营目标和经营环境中，支持那些引发独立性要求的活动，例如SQA。
独立性应该表现在：
──给担当SQA角色的个人提供组织上的自由度，使它们成为高级管理者在软件项目中的“耳目”。
──使担当SQA角色的个人，免受管理者对他们正在评审的软件项目的所做的性能评价的影响。
──使高级管理者相信，正在报告的有关项目过程和产品的信息是客观的。
3．高级管理者定期评审SQA活动和结果。
执行能力（Ability to Perform，AB）
能力1：存在负责协调和实施项目的SQA组（即SQA组）。
一个组是负责一组作业或活动的部门、经理和个人的集合。组的规模可以变化，可以包括一个受指派的非全日制的单个个人，也可以包括几个从不同部门指派来的非全日制的个人或几个全日制的个人。建立一个组时，应考察的因素包括指派的作业和活动、项目的规模、组织机构和组织文化。某些组，例如，软件质量保证组，集中注意力于项目活动；而其他组，例如，软件工程过程组，则集中关注全组织的活动。
能力2：为进行SQA活动提供足够的资源和投资。
1．指派一个经理，专门负责项目的SQA活动。
2．指派一个在SQA方面博学的、并有权采取监督行动的高级经理，接受和处理软件不符合问题。
——在SQA中，处在向高级经理报告链上的全部经理，均是在SQA的任务、责任和权利方面富有独到见解、富于智慧和决策能力的管理者。
3．保证支持SQA活动的工具好用。
支持工具的例子有：
──工作站
──数据库程序
──电子表格程序
──审计工具
能力3：SQA组的成员要接受培训，以利于完成他们的SQA活动。
培训的例子有：
──软件工程技巧和实践
──软件工程组和其他软件有关组的岗位及职责
──用于软件工程的标准、规程和方法
──软件项目的应用领域
──SQA的对象、规程和方法
──SQA组对软件活动的参与
──SQA方法和工具的有效使用
──人员间的交流
能力4：软件项目的成员接受有关SQA组的任务、职责、权利和价值的定向培训。
执行活动（Activities Performed，AC）
活动1：按照已建档的规程为软件项目制定SQA计划。
该规程一般规定：
1．SQA计划的制定是在项目策划的早期阶段，平行于整个项目策划。
2．受影响的组和个人评审该SQA计划。
受影响的组和个人的例子有：
──项目软件经理
──其他软件经理
──项目经理
──顾客的SQA代表
──SQA组负责解决其报告不符合问题的高级经理
──软件工程组（包括全部小组，如软件设计小组及软件作业领导）
3．对计划进行管理和控制。
“管理和控制”意味着，在给定时间（过去或现在）内使用的工作产品的版本是已知的（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“管理和控制”更高程度的控制，则工作产品可置于配置管理的完备规范之下，正如在“软件配置管理”关键过程域中所描述的。
活动2：按照SQA计划进行SQA组的活动。
该计划包括：
1．SQA组的职责和权利
2．SQA组的资源要求（包括员工、工具和设施）
3．SQA组活动的进度表和投资
4．SQA组参加制定项目的软件开发计划、标准和规程的情况
5．确定将由SQA完成的评价
待评价的产品和活动的例子有：
──运行软件和支持软件
──可交付的和不可交付的产品
──软件和非软件产品（例如，文档）
──产品开发和产品验证活动（例如，运行测试用例）
──生成产品时所从事的活动
6．将由SQA组进行的审计和评审。
7．将用做SQA组评审和审计基础的标准和规程。
8．用于对不符合性问题建立文档和进行跟踪直至结束的规程。
这些规程可以作为计划的一部分而纳入计划，也可以通过对包含它们的其他文档进行索引的方式而纳入计划。
9．要求SQA组生成的文档。
10．就SQA活动给软件工程组和其他相关组提供反馈信息的方法和频率。
活动3：SQA组参与准备和评审项目的软件开发计划、标准和规程。
1．SQA就以下几个方面对计划、标准和规程提供咨询和评审：
——对组织方针的符合性
——对外部强加的标准和要求的符合性（例如，工作陈述所要求的标准）
——适合项目使用的标准
——在软件开发计划中应阐述的专题
——项目指定的其他领域
2．SQA组验证计划、标准和规程已到位，并可用于评审与审计软件项目。
活动4：SQA组评审软件工程活动，以验证符合性。
1．用软件开发计划和指定的软件标准及规程，进行评价活动。
参考其他关键过程域中的验证实施共同特性，以便找到包括由SQA组进行特定评审和审计的实践。
2．对偏差进行鉴别和建立文档，并跟踪到结束。
3．验证纠正措施。
活动5：SQA组审计指定的软件工作产品，以验证其符合性。
1．在交付给顾客之前，评价可交付的软件产品。
2．对照指定的软件标准、规程和合同要求，评价软件工作产品。
3．对偏差进行鉴别和建立文档，并跟踪到结束。
4．验证纠正措施。
活动6：SQA组定期向软件工程组报告其活动的结果。
活动7：按照已文档化的规程，对软件活动和软件工作产品中所鉴别出的偏差，建立文档并加以处理。
该规程一般规定：
1．将不符合软件开发计划和指定的项目标准及规程的问题写成文档，并在可能处，与有关的软件作业领导、软件经理或项目经理，一起加以解决。
2．有些不符合软件开发计划和指定标准及规程的问题，不能与软件作业领导、软件经理或项目经理一起加以解决，将这些不符合问题写成文档，并提交给指定的接收不符合问题的高级经理。
3．定期评审提交给高级经理的不符合问题，直至解决它们为止。
4．对不符合问题的文档进行管理和控制。
活动8：SQA组和顾客的SQA人员一起，适时地对软件质量保证的活动和发现进行定期评审。
测量与分析（Measurement and Analysis，ME）
测量1：进行测量，并将测量结果用于确定SQA活动的成本和进度状态。
测量的例子有：
──SQA活动的里程碑完成的情况与计划做比较。
──在SQA活动中完成的工作、所花费的工作量、所消耗的资金与计划做比较。
──产品审计和活动评审的次数与计划做比较。
验证实施（Verifying Implementation，VE）
验证1：高级管理者定期参与评审SQA活动。
高级管理者定期评审的主要目的，是在合适的抽象层次上，及时地了解和洞察软件过程活动。评审间隔应满足组织的需求，只要已有报告例外情况的合适机制许可，间隔可以长些。
参考“软件项目跟踪和监督”关键过程域的验证1，以便找到包括高级管理者监督评审典型内容的实践。
验证2：项目经理定期地、按事件驱动方式参与评审SQA活动。
参考“软件项目跟踪和监督”关键过程域的验证2，以便找到包括项目管理者监督评审典型内容的实践。
验证3：独立于SQA组的专家，定期评审SQA组的活动和软件工作产品。
15《CMM软件质量保证过程文件》
《CMM软件质量保证过程文件》编写参考指南
1．引言(Introduction)
1.1 目的(Purpose)
本文档是软件质量保证过程的定义，它规定了角色、进入准则、输入、活动、输出、结束准则等。
1.2 范围(Scope)
本文档只适应于软件质量保证过程。
1.3 术语定义(Terms Glossary)
[1] 软件相关组：指软件配置管理组、文档支持组、测试组。
[2] 软件质量保证组：指计划和实施软件质量保证活动的人员的集合。
1.4 参考资料(References)
[1] Mark C. Paulk等人，《The Capability Maturity Model Guidelines for improving the software process》，Carnegie Mellon University Software Engineering Institute
[2] Mark C. Paulk，《Key practices of the Capability Maturity Model》，Version 1.1，1993
1.5 相关文档(Related Documents)
[1] 《软件质量保证程序文件》
1.6 版本更新记录(Version Updated Record)
版本更新记录，如表12-8所示。
表12-8 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2002/03/03 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2002/03/16 |
进入准则维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．软件质量保证过程(SQA Process)
──参与角色(Roles)
R1：软件质量保证组。
R2：项目经理。
R3：软件工程组代表。
R4：软件相关组代表。
R5：高级经理。
──进入准则(Entry Criteria)
E1：软件项目立项报告或下达任务书。
E2：组织的责任人到位，且经过软件质量保证过程的培训。
──输入(Inputs)
I1：《立项建议书》或《项目合同》。
I2：《软件开发计划》。
──活动(Activities)
A1：SQA组成员与项目经理共同选定开发过程中的标准和规范，并参与《软件开发计划》的评审。
A2：SQA成员按软件质量保证程序文件编制《SQA计划》，并经过相关组及个人的评审。
A3：SQA成员按《SQA计划》/《软件开发计划》，参与软件项目的定期或事件驱动的评审与审计活动。
A4：SQA组对审计出的不符合项，按程序文件进行跟踪处理。
A5：SQA组按程序文件，及时向相关组及个人报告其活动结果。
A6：负责软件质量保证的高级经理，处理软件项目内部不能解决的不符合项。
──输出(Outputs)
O1：软件质量保证计划。
O2：软件工程活动评审报告。
O3：软件工作产品审计报告。
O4：不符合项跟踪报告。
──结束准则(Finish Criteria)
F1：软件项目终止。
──评审与审计(Reviews and Audits)
RA1：SQA主管定期参与评审SQA活动。
RA2：项目经理定期或并事件驱动地参与评审SQA活动。
──测量(Measurements)
M1：SQA组成员按程序文件记录SQA活动实际投入的资源、工作量、进度等数据。
──培训(Training)
T1：对SQA组成员进行SQA知识定向培训。
T2：对非SQA组成员，进行软件工程知识定向培训。
──工具(Tools)
T1：MS Word。
T2：MS Project。
16《CMM软件质量保证程序文件》
《CMM软件质量保证程序文件》编写参考指南
1．引言(Introduction)
1.1 目的(Purpose)
本文档是《软件质量保证过程文件》的补充文件，它规定了《软件质量保证过程文件》中的工作产品定义和执行步骤。
1.2 范围(Scope)
本文档规定了软件质量保证活动的工作产品及其执行步骤。
1.3 术语定义(Terms Glossary)
[1] 工作产品，是指软件生存周期各个阶段所产生的文档化的阶段成果，它包括开发文档、管理文档及软件产品。如软件开发计划、概要设计说明书、源程序等。
1.4 参考资料(References)
[1] Mark C. Paulk等人，《The Capability Maturity Model Guidelines for improving the software process》，Carnegie Mellon University Software Engineering Institute
[2] Mark C. Paulk，《Key practices of the Capability Maturity Model》，Version 1.1，1993
1.5 相关文档(Related Documents)
[1] 《软件质量保证过程文件》
1.6 版本更新记录(Version Updated Record)
版本更新记录，如表12-9所示。
表12-9 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2002/03/09 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2002/03/26 |
术语定义维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．软件质量保证过程(SQA Process)
2.1 软件质量保证策划程序(SQA Planning)
──工作产品(Work Product)
W1：SQA计划。
W2：SQA计划评审报告。
──执行步骤(Execute Step)
E1：SQA组为软件项目指派SQA成员，并确定其岗位职责。
E2：SQA成员在项目早期，参与制定该软件项目的SQA计划。
E3：SQA成员与项目经理协商识别出该项目的质量保证对象，即该项目的工作产品。
E4：参照《软件质量保证计划制定指南》，制定出该项目的《SQA计划》。
E5：SQA成员估算每个质量保证活动的工作量和所需资源。
E6：项目经理、SQA组、软件相关组评审《SQA计划》。
E7：项目软件开发计划更改时，SQA成员适时调整《SQA计划》。
2.2 定期或事件驱动的评审与审计(Periodic Review and Audit or Review and Audit Driven by Event)
──工作产品(Work Product)
W1：评审报告。
W2：不符合项跟踪表。
──执行步骤(Execute Step)
E1：按照SQA计划，项目组提交工作产品给SQA成员。
E2：SQA成员对提交的工作产品进行评审或审计。
E3：SQA成员填写《评审报告》及《不符合项跟踪表》。
2.3 跟踪处理不符合项(Tracking and Resolution of Noncompliance Items)
──工作产品(Work Product)
W1：不符合项跟踪表。
──执行步骤(Execute Step)
E1：SQA成员对每次质量保证活动后产生的不符合项，编制《不符合项跟踪表》。
E2：SQA成员将《不符合项跟踪表》通知项目经理，项目组解决后反馈给SQA成员。
E3：SQA成员对解决的内容进行验证。
E4：SQA成员将项目经理解决不了、或不能由项目经理解决的问题，提交给高层经理解决。
E5：SQA成员对高层经理解决的情况，进行跟踪记录。
2.4 报告活动结果(Report of Activity Results)
──工作产品(Work Product)
W1：SQA工作报告。
──执行步骤(Execute Step)
E1：SQA成员编制《SQA工作报告》。
E2：SQA成员将《SQA工作报告》提交给相关经理、相关组及个人。
2.5 软件质量保证管理评审(Assurance Review of Software Quality)
──工作产品(Work Product)
W1：SQA管理过程评审报告。
──执行步骤(Execute Step)
E1：SQA组长定期或以事件驱动方式组织召开SQA管理过程评审会。
E2：参加评审会的成员为高级经理、项目经理、独立于SQA组的外部专家。
E3：SQA组长整理《SQA管理过程评审报告》，并改进SQA组的工作。
2.6 记录测量数据(Record of Measurement Data)
──工作产品(Work Product)
W1：软件质量保证活动度量表。
──执行步骤(Execute Step)
E1：项目组的SQA成员，每周记录软件质量保证活动，填写到《软件质量保证活动度量表》；
E2：SQA成员定期或项目完成后，将度量记录汇总，通报给高级经理和项目经理。
17《软件质量保证计划》
《软件质量保证计划》编写参考指南
1．引言(Introduction)
1.1 目的(Purpose)
软件质量保证计划建立的目的，是为了使软件质量保证组及项目组双方能以此软件质量保证计划为依据，执行一系列的SQA活动，从而对软件过程和软件产品的质量提供可视性管理。
1.2 范围(Scope)
本文档适应于软件项目的质量保证全过程。
1.3 术语定义(Terms Glossary)
[1] 软件质量：指软件产品满足用户明确和隐含需求的能力特性的总和。
[2] 软件质量保证组：指计划和实施软件质量保证活动的人员集合。
1.4 参考资料(References)
[1] 列出有关的参考资料1。
[2] 列出有关的参考资料2。
1.5 相关文档(Related Documents)
[1] 列出有关的软件合同。
[2] 列出有关的软件任务书。
1.6 版本更新记录(Version Updated Record)
版本更新记录格式，如表14-3所示。
表14-3 版本更新记录
|
版本号 |
创建者 |
创建日期 |
维护者 |
维护日期 |
维护纪要 |
|
V1.0 |
王大林 |
2001/04/03 |
— |
— |
— |
|
V1.0.1 |
— |
— |
王小林 |
2001/04/18 |
管理机构维护 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2．管理机构(Management Organization)
2.1 机构(Organization)
质量保证活动组织关系图见图14-1，它给出了软件组织内部与软件质量保证活动有关的各个小组及个人之间的关系。
图14-1 质量保证活动组织关系图
2.2 职责(Responsibility)
说明与软件质量保证活动有关的各个小组及个人的责任，如表14-4所示。
表14-4 与软件质量保证活动有关的各个小组及个人的责任
|
小组及个人名称 |
责 任 |
|
高级经理 |
负责小组之间、部门之间、组织内外的沟通协调 |
|
项目经理 |
负责整个软件项目的业务、技术、资源、活动 |
|
软件质量保证组长 |
保证软件项目的标准、规程、约定得到遵守 |
|
软件质量保证成员 |
制定软件质量保证计划，组织软件质量保证活动，书写软件质量保证报告。重点是对软件工作产品进行评审与审计 |
续表表
|
小组及个人名称 |
责 任 |
|
测试组 |
制定测试计划、用例，组织测试活动，书写测试报告 |
|
软件工程组 |
软件工程项目的分析、设计、编程、测试、培训、实施 |
|
配置管理组 |
软件基线、配置项的认定，配置活动审定，配置资源保证 |
|
同行专家 |
同行专家（外部专家）评审 |
3．质量保证活动(SQA Activities)
表14-5是《软件质量保证计划任务进度表》(Schedule for SQA)（又称软件质量保证活动表），该表是根据《软件质量保证程序文件》的内容制定的，建议读者将两者结合起来阅读。
表14-5 软件质量保证计划任务进度表
|
序 号 |
工作产品名称 |
组 织 者 |
参 加 者 |
计划日期 |
实际日期 |
计划工作量 |
实际工作量 |
计划资金 |
实际资金 |
计划评审次数 |
实际评审次数 |
|
1 |
《SQA计划》 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
2 |
《SQA计划》评审报告 |
SQA成员 |
项目经理、软件相关组及个人 |
|
|
|
|
|
|
|
|
|
3 |
《用户需求报告》评审报告 |
项目经理 |
用户、SQA成员、软件相关组、外部专家 |
|
|
|
|
|
|
|
|
|
4 |
《用户需求报告》不符合项跟踪表 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
5 |
《软件需求规格说明书》评审报告 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
6 |
《软件需求规格说明书》不符合项跟踪表 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
7 |
《概要设计说明书》评审报告 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
8 |
《概要设计说明书》不符合项跟踪表 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
续表表
|
序 号 |
工作产品名称 |
组 织 者 |
参 加 者 |
计划日期 |
实际日期 |
计划工作量 |
实际工作量 |
计划资金 |
实际资金 |
计划评审次数 |
实际评审次数 |
|
9 |
《详细设计说明书》评审报告 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
10 |
《详细设计说明书》不符合项跟踪表 |
SQA成员 |
项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
11 |
《Alpha测试报告》评审报告 |
SQA成员 |
项目经理、测试组 |
|
|
|
|
|
|
|
|
|
12 |
《Beta测试报告》评审报告 |
项目经理 |
用户、SQA成员、测试组 |
|
|
|
|
|
|
|
|
|
13 |
《用户使用手册》评审报告 |
SQA成员 |
项目经理、SCM组、软件相关组 |
|
|
|
|
|
|
|
|
|
14 |
《用户安装手册》评审报告 |
SQA成员 |
项目经理、SCM组、软件相关组 |
|
|
|
|
|
|
|
|
|
15 |
《系统管理手册》评审报告 |
SQA成员 |
项目经理、SCM组、软件相关组 |
|
|
|
|
|
|
|
|
|
16 |
《SQA工作报告》评审报告 |
SQA组长 |
高级经理、项目经理、软件相关组 |
|
|
|
|
|
|
|
|
|
17 |
《SQA管理过程》评审报告 |
SQA组长 |
高级经理、项目经理、外部专家 |
|
|
|
|
|
|
|
|
|
18 |
软件质量保证活动度量表 |
SQA成员 |
高级经理、项目经理 |
|
|
|
|
|
|
|
|
其中，用户需求报告评审和Beta测试报告评审的组织者均为项目经理，这是因为这两次评审均需用户参与，并且要用户确认。
4．工具、技术和方法(Tools，Technique and Methods)
根据需要，指明SQA计划中用到的工具、技术和方法。
5．对供货商的控制(Controls to the Suppliers)
供货商包括软件外包商和软件产品销售商，对外包商承包开发软件的过程管理，要按照CMM2的关键过程域“软件子合同管理”(Software Subcontract Management)进行管理。对销售软件产品的销售商，要按照软件组织事先定义好的标准进行控制。
6．活动记录的收集和整理(Collecting，Maintaining and Keep Records)
对SQA计划实施中的活动记录要整理入库，长期保存，由它可生成《软件质量保证活动度量表》，送给高级经理、项目经理阅读。