软件公司质量管理体系模板.doc

软件公司质量管理体系

192

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。

秘　密
仅限于内部使用

质量管理体系培训教材
( 一)

北京博思美亚科技发展公司

目　录

公司标准软件过程体系文件导读 2
软件生命周期模型 2
软件开发过程 2
技术类评审 2
项目估算指南 2
标准软件过程总体裁剪指南 2

公司标准软件过程体系文件导读
目　录
1、 概述 2
1.1　目的 2
1.2　适用范围 2
1.3　引用文件 2
1.4　术语 2
1.5　参考资料 2
2、 公司标准软件过程的开发 2
2.1　开发历程 2
2.2　公司标准软件过程总体结构 2
3、 软件过程体系文件 2
3.1　过程管理 2
3.2　软件开发过程 2
3.3　项目管理 2
3.4　资源管理 2
3.5　指南性文件 2

1、 概述
1.1　目的
本文件对公司软件过程及其体系文件的总体结构进行描述, 为与软件过程的开发、 维护、 改进、 执行、 管理和跟踪等有关的人员学习、 理解和使用软件过程体系文件提供指南。
1.2　适用范围
适用于SEPG、 高层经理、 项目经理、 软件开发人员、 测试人员、 软件质量保证人员、 软件配置管理人员及其它支持人员为了按规范开展各自的业务活动, 学习、 理解和使用软件过程体系文件。
1.3　引用文件
无。
1.4　术语
无。
1.5　参考资料
•《Software Project Management Guidebook》( Version 2.0) , Process Strategies, Inc.
•《软件工程－实践者的研究方法》, ( 美) Roger S. Pressman著, 黄柏素、 梅宏译, 机械工业出版社出版, 1999年10月
•《实践中的CMM－INFOSYS公司实施软件项目之过程》, 潘卡•杰罗特著, 杨慧鸣、 李光龙泽, 7月
2、 公司标准软件过程的开发
2.1　开发历程
为了使软件过程保持长期稳定并能持续改进, 必须开发组织( 即公司) 级的标准软件过程。为此, 公司组织了以软件工程过程组( SEPG) 为主体的标准软件过程开发和文件编写组, 具体实施上述任务。公司标准软件过程是在公司范围内的软件项目全面执行CMM二级的基础上, 在软件工程一般理论的指导下, 收集公司全部软件项目所采用的软件过程, 经过分析、 归纳、 提炼、 分类、 总结等一系列步骤开发而成; 又在开发标准软件过程的基础上, 形成了描述这些标准软件过程的相互关联的程序文件体系。
本程序文件体系对组成标准软件过程的基本软件过程要紧, 以及软件过程要素之间的关系( 软件过程结构) 进行描述, 描述的重点放在过程的可操作性上。另外, 与此相关联, 开发或编写了公司的软件过程数据库、 与软件过程相关的文档库、 软件生命周期描述文件和标准软件过程裁剪指南。它们和公司标准软件过程一起, 组成了公司的软件过程资产。
公司的软件过程资产为规范公司软件项目的软件过程提供了基础和保证。各软件项目按标准软件过程裁剪指南, 根据项目的实际情况( 主要是客户需求) 对公司标准软件过程进行裁剪, 开发适合项目特定特性的项目软件过程; 项目软件过程开发的重点在软件过程的可用性, 以及附加到该项目的价值。项目以项目定义的软件过程为基础, 制订项目软件开发计划; 按计划执行项目的软件开发活动, 产生相应的软件工作产品及其它开发成果; 开发过程中的数据以及项目结束后进行总结的数据, 经过一定的手续, 反馈到公司的软件过程数据和软件过程相关文档库, 丰富公司的软件过程资产。如此重复循环, 促使软件过程得以持续改进。
以上过程和关系能够用图1表示。图中:
表示实体, 例如”分配到软件的需求”
表示活动, 例如”选择项目的软件生命周期”
图中上半部分用粗线框围起来的部分即公司的软件过程资产部分, 它由描述公司标准软件过程的程序文件、 软件过程数据库、 与软件过程相关的文档库、 软件生命周期描述文件和标准软件过程裁剪指南组成。
下半部分则描述公司软件过程资产的利用过程: 软件项目按标准软件过程裁剪指南, 根据项目的实际情况( 主要是客户需求) 对公司标准软件过程进行裁剪, 开发适合项目特定特性的项目软件过程; 制订项目软件开发计划, 并按计划执行项目的软件开发活动; 将项目数据( 包括开发过程中的数据以及项目结束后进行总结的数据) 反馈到公司的软件过程数据库和软件过程相关文档库。

图1　公司软件过程资产的开发和利用
2.2　公司标准软件过程总体结构
图2为公司标准软件过程的总体结构。由于本公司的产品( 项目) 除了纯软件产品( 项目) 外, 还包括软件和硬件兼有的产品( 项目) , 考虑到过程的完整性以及便于理解软件过程和其它过程之间的接口关系, 图中的项目开发过程反映了软件和硬件兼有的产品的整个开发过程, 但其中非软件过程部分均采用虚线, 以示区别。
有关内容说明如下:
( 1) 项目、 项目生命周期和软件生命周期
项目是由一组有起止日期、 相互协调的受控活动组成的独特过程, 该过程要求达到符合包括时间、 成本和资源等约束条件在内的规定要求的目标, 其结果将产生产品。而软件项目则是为了开发软件产品( 包括系统) 而建立的项目。项目和产品都具有一定的生命周期。
项目生命周期是指从项目启动到项目结束为止的时间间隔。项目生命周期一般包括:
•初期策划阶段( 主要是可行性分析) ;
•开发策划阶段( 开发前的人、 财、 物等的计划和准备) ;
•实施阶段( 具体实施项目开发计划, 保证项目的质量、 成本、 进度的顺利完成) ;
•结束阶段( 评审、 鉴定及项目交付和组织结束工作) 。
在整个项目生命周期, 所涉及的过程能够分为两类:
•项目开发过程( 和被开发产品的实现直接相关) ;
•项目管理过程( 对项目的开发过程进行管理和控制) 。
软件生命周期则是指软件产品的生命周期, 即是指从设想－软件产品开始到软件不再供使用为止的时间间隔。软件生命周期一般包括: 概念阶段、 需求阶段、 设计阶段、 实现阶段、 测试阶段、 安装和调整阶段、 运行和维护阶段, 有时还包括退役阶段。
显然, 项目生命周期和软件生命周期在时间上是相关的, 但在概念上是完全不同的。一般来说, 项目生命周期不会超过该项目所开发的软件产品的生命周期。
( 2) 项目开发过程
图中的下部表示项目的开发过程。它从客户需求开始, 经过系统分析, 将客户需求分解成软件部分的需求和硬件部分的需求( 从此处项目将分成软件项目和硬件项目两部分) 。其中, 软件项目从软件需求定义阶段、 设计阶段、 实现阶段、 测试阶段、 验收交付阶段到项目总结, 表示整个软件开发的结束。一般来说, 作为软件开发项目到此就意味着结束了, 但软件产品的生命周期并未结束。软件产品交付后, 将经历使用过程中的维护阶段( 维护阶段的时间可能和项目合同有关) , 直到最后产品退役。
( 3) 项目管理过程
图中的中部表示项目的管理过程, 即对项目的开发过程实施管理的过程。对于软件和硬件兼有的项目来说, 项目管理的主要过程如下:
•初期策划( 主要针对系统分析、 可行性分析进行策划) ;
•开发策划( 开发前的人、 财、 物等的计划和准备) ;
•项目跟踪与监控( 对项目初期的系统分析、 可行性分析, 以及项目开发过程中软件需求定义、 设计、 实现、 测试、 验收交付等活动进行跟踪与监控) ;
•软件质量保证( SQA, 对项目的软件过程和软件产品的符合性进行质量监控, 它贯穿于软件项目的始终) ;
•软件配置管理( SCM, 为确保软件产品的完整性和正确性进行的管理, 它贯穿于软件项目的始终) ;
•需求管理( 为确保满足客户需求进行的管理, 它贯穿于项目的始终) ;
•评审过程( 包括同行评审等技术类评审和计划评审等管理类评审) ;
•项目结束处理( 包括项目的鉴定、 验收、 交付, 以及进行项目总结) 。
另外, 在项目管理活动中, 还可能有以下管理过程:
•项目培训;
•组间协调等。
( 4) 过程资产
本公司的软件过程资产分两个层次: 公司级资产和项目级资产。
a.　公司级资产
包括:
•过程数据库( 含软件过程和其它过程的资产) ;
•过程相关文档库;
•人力资源库。
b.　项目级资产
包括:
•项目控制数据库( 项目经理控制, 用于保存项目数据, 以便对项目进行跟踪与监控) ;
•SQA管理库( SQA控制, 用于保存项目的软件质量保证数据) ;
•SCM管理库( SCM控制, 用于保存项目的软件配置管理数据) ;
•SCM库( SCM控制, 用于保存项目的所有配置项) 。
经过一定的手续, 项目的项目控制数据库和SQA管理库中的数据, 经过选择, 将补充到公司的过程数据库和过程相关文档库中。
另外, 根据实际需要, 总部一级也可能需要有人力资源库。

图2　软件过程结构图

3、 软件过程体系文件
公司的软件过程体系文件的组成如图3所示。
软件过程体系文件
过程管理
项目管理
软件开发过程
资源管理
指南性文件
软件开发过程程序文件
标准软件过程开发与维护
过程描述文件编写规范( 一)
过程描述文件编写规范( 二)
质量管理体系
数据库管理和维护文件
软件生命周期模型描述文件
标识规范
术　语
文件控制程序
客户需求管理程序文件
项目策划程序文件
项目跟踪与监控程序文件
项目总结程序文件
软件质量保证程序文件
软件配置管理程序文件
组间协调程序文件
技术类评审程序文件
高层验证程序文件
培训程序
项目估算指南
标准软件过程总体裁剪指南
公司标准软件过程体系文件导读

图3　软件过程体系文件

按文件的使用目的, 公司的软件过程体系文件分为五类: 过程管理、 软件开发过程、 项目管理、 资源管理和指南。
3.1　过程管理
过程管理是指对软件过程进行管理, 此类文件的使用人员主要是对软件过程进行开发、 维护、 改进的人员, 例如SEPG成员、 项目经理、 SQA等。有关文件说明如下:
( 1) 标准软件过程开发与维护
•使用人员: SEPG和软件过程描述文件编写人员。
•内容提要: 本文件对如何开发和管理公司的标准软件过程、 如何编写软件过程描述文件、 如何编写标准软件过程裁剪指南等作出了规定。
( 2) 过程描述文件编写规范( 一)
•使用人员: 软件过程描述文件编写人员。
•内容提要: 为能分解成若干过程元素的较大过程编写的描述文件编写规范。
( 3) 过程描述文件编写规范( 二)
•使用人员: 软件过程描述文件编写人员。
•内容提要: 为没有明显的入口和出口准则的过程( 例如日常管理类的过程) 编写的描述文件编写规范。
( 4) 质量管理体系数据库管理和维护文件
•使用人员: SEPG、 项目经理、 SQA和数据库的管理和维护人员。
•内容提要: 本文件对公司的软件过程数据库和与过程相关文档库的管理和维护作出了规定。考虑到将来需要扩充ISO9001要求的其它数据库, 故起此名。
( 5) 软件生命周期模型描述文件
•使用人员: 项目经理以及参与项目软件过程定义的有关人员。
•内容提要: 本文件对公司所确定的软件生命周期模型进行描述, 作为公司的过程资产之一, 供项目选择适合项目情况的软件生命周期模型时参考。
( 6) 标识规范
•使用人员: 对被标识对象进行标识的人中员。
•内容提要: 为规范包括文件、 表格、 产品的标识而制订的规范。
( 7) 术语
•使用人员: SEPG和软件过程描述文件编写人员。
•内容提要: 本文件定义了本软件过程体系文件所使用的专用术语。
( 8) 文件控制程序
•使用人员: 文件管理人员。
•内容提要: 本文件对文件的编写、 评审、 批准、 发布、 发放、 回收等文件管理要求作出了规定, 是整个质量管理体系所要求的用于对受控文件进行管理的文件。
3.2　软件开发过程
软件开发过程是指与软件开发有关的过程, 相关文件的使用人员主要是和软件开发有关的人员。
( 9) 软件开发过程程序文件
•使用人员: 项目经理以及参与项目软件过程定义的有关人员。
•内容提要: 本程序文件针对本公司软件项目所采用的典型开发过程, 分解成过程要素进行描述, 供各软件项目根据标准软件过程裁剪指南, 定义项目自己的软件过程时使用。
3.3　项目管理
与项目管理有关的文件如下:
( 10) 客户需求管理程序文件
•使用人员: 项目经理、 SQA、 SCM和软件开发人员。
•内容提要: 本文件是为了确保项目满足客户需求和如何确保满足客户需求, 为项目编写的有关客户需求管理的程序文件。
( 11) 项目策划程序文件
•使用人员: 项目经理以及参与项目策划的其它有关人员。
•内容提要: 为指导软件项目进行项目的初期策划和开发策划而编写的程序文件。
( 12) 项目跟踪与监控程序文件
•使用人员: 高层经理、 项目经理、 SQA、 SCM和软件开发人员。
•内容提要: 指导软件项目在项目计划执行过程中如何对项目进行跟踪与监控的程序文件。
( 13) 项目总结程序文件
•使用人员: 项目经理、 SQA、 SCM和软件开发人员。
•内容提要: 指导软件项目在项目结束阶段如何进行项目总结的程序文件。
( 14) 软件质量保证程序文件
•使用人员: SQA、 项目经理、 SCM和软件开发人员。
•内容提要: 指导软件项目的SQA如何执行项目的软件质量保证活动, 以及项目的其它人员如何配合的程序文件。
( 15) 软件配置管理程序文件
•使用人员: SCM、 项目经理、 SQA和软件开发人员。
•内容提要: 指导软件项目的SCM如何执行项目的软件配置管理活动, 以及项目的其它人员如何配合的程序文件。
( 16) 组间协调程序文件
•使用人员: 项目经理、 SQA、 SCM和软件开发人员。
•内容提要: 项目在进行项目策划时, 应考虑有无组间协调的情况, 本程序文件提供这方面的要求和指导。
( 17) 技术类评审程序文件
•使用人员: 项目经理、 软件开发人员、 SQA以及其它参与评审的人员。
•内容提要: 本程序文件为项目进行技术类评审( 包括同行评审及其它类型的技术评审) 规定要求和提供指导。
( 18) 高层验证程序文件
•使用人员: 高层经理、 项目经理、 SQA、 SCM和软件开发人员。
•内容提要: 在公司标准软件过程的开发和改进以及项目在执行软件开发活动的过程中, 高层经理应在哪些环节进行验证, 如何进行验证? 项目的有关人员如何配合? 本程序文件为高层经理的验证活动提出要求并提供指导。
3.4　资源管理
资源管理主要包括人力资源、 设备、 环境等方面的管理。
( 19) 培训程序
•使用人员: 公司培训组、 高层经理、 项目经理、 SQA、 SCM和软件开发人员。
•内容提要: 对公司级培训和项目级培训的实施要求作出规定, 包括培训需求的收集、 培训计划、 培训实施和培训总结等。
3.5　指南性文件
当前提供以下指南性文件:
( 20) 项目估算指南
•使用人员: 项目经理及其它参与估算的人员。
•内容提要: 本指南为项目估算的方法( 例如: 规模估算、 工作量估算等) 提供指南。
( 21) 标准软件过程总体裁剪指南
•使用人员: 项目经理及其它参与项目软件过程定义的人员。
•内容提要: 总体裁剪指南是公司标准软件过程裁剪指南中的高层裁剪指南( 或一般性裁剪指南) 。它为软件项目在对公司标准软件过程进行裁剪时, 提供对一般性活动进行裁剪的指南; 裁剪结果为项目进行详细的过程裁剪提供框架性的指导方针( 详细裁剪指南分散在各程序文件的”详细裁剪指南”中) 。
( 22) 软件过程体系文件导读( 即本文件)
•使用人员: SEPG、 高层经理、 项目经理、 软件开发人员、 测试人员、 软件质量保证人员、 软件配置管理人员等为了按规范开展各自的业务活动, 需要学习、 理解和使用软件过程体系文件的所有人员。
•内容提要: 对公司标准软件过程开发的背景、 开发过程、 标准软件过程的总体结构, 以及相应的软件过程体系文件进行导读性的说明。

软件生命周期模型
目　录
1、 概述 2
1.1　目的 2
1.2　适用范围 2
1.3　引用文件 2
1.4　术语 2
1.5　参考资料 2
2、 软件生命周期模型描述 2
2.1　瀑布模型 2
2.2　原型＋瀑布模型 2
2.3　增量模型 2
2.4　增量的迭代过程模型 2
2.5　快速应用开发模型 2
3、 几种模型的比较 2
4、 其它模型采用说明 2
5、 附录 2

1、 概述
1.1　目的
描述公司级定义的软件生命周期模型, 供项目策划时根据项目的具体情况选择或裁剪使用, 由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。
1.2　适用范围
适用于本公司的软件项目策划。
1.3　引用文件
•《软件开发过程程序文件》( QMS-OP01-V1.0)
•《标准软件过程开发和维护》( QMS-PSM01-V1.0)
•《项目策划程序文件》( QMS-PTM02-V2.0)
1.4　术语
•软件生命周期－从软件设想开始到软件不再使用而结束的时间周期。软件生命周期一般包括系统分析、 软件需求分析、 设计、 实现、 测试、 验收、 运行和维护各阶段, 有时还包括退役阶段。
•软件过程－有关开发和维护软件及其相关产品( 例如: 项目计划、 设计文档、 代码、 测试用例、 用户手册等) 的活动、 方法、 实践和变更的集合。
1.5　参考资料
•《软件工程Java语言实现》, Stephen R. Schach著, 袁兆山等译, 机械工业出版社, 1999年9月
•《软件工程实践者的研究方法》, Roger S. Pressman著, 黄柏素、 梅宏等译, 机械工业出版社, 1999年10月
•《Software Project Management Guidebook》, Frank J. Koch著, 7月
•《实用软件工程》郑人杰、 殷人昆、 陶永雷著, 清华大学出版社, 1997年4月
•《软件需求》, Karl E. Wiegers著, 陆丽娜、 王忠民、 王志敏等译, 机械工业出版社, 7月
•《统一软件开发过程》, Ivar Jacobson、 Grady Booch、 James Rumbaugh著, 周伯生、 冯学民、 樊东平等译, 机械工业出版社, 1月
2、 软件生命周期模型描述
所有的项目软件开发过程都应遵循一个生命周期模型, 每个模型都具有能够帮助实际软件项目进行控制及协调的特征。定义生命周期模型的目的在于将本质上无序的活动有序化, 在开发策划期间, 必须仔细考虑项目的特征和目标之后, 再选择生命周期模型。本文件根据组织内项目的类型, 描述常见的几个软件生命周期模型, 项目可根据实际情况选择或按规定剪裁使用, 但应注意与公司的标准软件开发过程相兼容。见附录”软件过程结构图”, 其中的项目软件开发过程即为一个选择瀑布模型的典型项目过程。
2.1　瀑布模型
( 1) 模型描述
该模型首先由Royce[1970]提出, 又称线性顺序模型, 包括图2－1所示的典型的几个阶段, 其重要特点是: 只有当一个阶段的文档已编制好, 且该阶段的产品得到SQA认可后, 该阶段才算完成; 测试或验证在每个阶段都必须执行; 一旦产品完成提交用户, 其后的任何修改均属于维护阶段。
如果需求明确、 能较好理解且较稳定, 能够考虑选择瀑布模型。

系统分析
软件需求分析
设　计
实　现
测　试
验　收
维　护

图2－1　瀑布模型

( 2) 缺点
由于其线性顺序的特点, 故只有在项目开发的后期才能得到具有全部功能的软件版本; 如果有未定义或未实施的需求, 将会引起重复劳动, 甚至开发出的产品不是用户所需要的。
( 3) 本企业适合的项目类型
操作系统产品; 译星产品; 嵌入式产品开发; 对日软件外包项目等。
2.2　原型＋瀑布模型
( 1) 模型描述
原型模型本身是一个迭代的模型, 是为了解决在产品开发的早期阶段存在的不确定性、 二义性和不完整性等问题, 经过建立原型使开发者进一步确定其应开发的产品, 使开发者的想象更具体化, 也更易于被客户所理解。原型只是真实系统的一部分或一个模型, 完全可能不完成任何有用的事情, 一般包括抛弃型和进化型两种, 抛弃型指原型建立、 分析之后要扔掉, 整个系统重新分析和设计; 进化型则是对需求的定义较清楚的情形, 原型建立之后要保留, 作为系逐渐增加的基础, 采用进化型一定要重视软件设计的系统性和完整性, 而且在质量要求方面没有捷径, 因此, 对于描述相同的功能, 建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发, 原型＋瀑布模型的开发流程如图2－2所示:

多次迭代原型逐渐完善
部分系统软件需求
或软件需求分析
原型设计
原型实现
原型测试
瀑布测试

图2－2　原型＋瀑布模型

以下情形建议考虑选择原型＋瀑布模型:
a.　项目包含一种新技术, 例: 新硬件、 新的开发语言、 新的系统架构等;
b.　需求不很清楚;
c.　存在关于性能、 可靠性和可行性方面的主要的、 未解决的问题;
d.　用户界面对系统成功是很关键的, 但不很清楚。
( 2) 缺点
由于原型并非最终产品, 如果原型不能利用, 可能导致成本的增加; 同时会引起客户的误解, 以为产品即将完成。
( 3) 本企业适合的项目类型
新领域的应用项目的开发; Web开发项目等。
2.3　增量模型
( 1) 模型描述
增量模型是一种进化软件过程模型, 融合了线性顺序模型的基本成分( 重复地应用) 和原型模型的迭代特征, 如下图所示。当使用增量模型时, 第一个增量往往是核心产品, 即实现了基本的需求; 核心产品交用户使用( 或进行更详细的复审) , 使用和/或评估的结果是下一个增量的开发计划, 该计划包括对核心产品的修改, 使其能更好的满足用户的需要, 并发布一些新增的特点和功能。增量模型和原型模型不一样, 强调每一个增量均要发布一个可操作产品。早期的增量是最终产品的”可拆卸”版本, 但能提供用户服务功能和用户评估的平台。增量模型开发流程见图2－3。

系统
分析
软件需求分析
软件结构设计
详细
设计1
实现1
测试1
验收1
详细
设计2
实现2
测试2
验收2
详细
设计n
实现n
测试n
验收n
维护
增量1
增量2
增量n

图2－3　增量模型

( 2) 缺点
由于增量模型的灵活性, 往往容易退化成边做边改方法, 使软件过程的控制丧失了整体性, 最终的产品也不是开放的, 而是成为维护人员的恶梦。
( 3) 本企业适合的项目类型
各种中、 大规模的项目类型; 已有系统技术路线发生改变但需求明确的移植类项目。
2.4　增量的迭代过程模型
( 1) 模型描述
该模型是一个不断迭代和增量的过程, 迭代过程首先要处理一组客户的业务需求, 这些业务需求合起来能够揙所开发产品的可用性。其次, 迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。一个增量不一定是对原有产品的增加, 特别在生命周期初期, 开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。在较后的阶段, 增量一般是对原有产品的增加。采用此种模型最好是基于构件和有相应的构件开发工具( 如: RUP、 配置管理工具等) 。

迭代1
系统
分析1
软件需求分析1

设计1

实现1

测试1

验收1
系统
分析2
软件需求分析2

设计2

实现2

测试2

验收2
系统
分析n
软件需求分析n

设计n

实现n

测试n

验收n
迭代2

迭代3

维护

图2－4　增量的迭代模型

( 2) 缺点
需要相当的风险评估的技术; 每个迭代循环控制不好会变成边做边改模式。
( 3) 本企业适合的项目类型
较复杂的应用项目。
2.5　快速应用开发模型
( 1) 模型描述
快速应用开发模型( RAD) 是一个线性顺序的软件开发模型, 强调极短的开发周期( 2－3个月) 。该模型是线性顺序模型的一个”高速”变种, 如果需求理解得很好, 且约束了项目范围, 就可经过使用基于构件或可得用软件包的建造方法获得快速开发。快速应用开发模型流程见图2－5。适用于信息系统应用软件的开发。

小组1
业务
建模1
数据
建模1
处理
建模1
应用
生成1

测试1
业务
建模2
数据
建模2
处理
建模2
应用
生成2

测试2
业务
建模n
数据
建模n
处理
建模n
应用
生成n

测试n
集成/测试

验收

维护
小组2

小组n

图2－5　快速应用开发模型

( 2) 缺点
对大型的、 但可伸缩的项目, RAD需要足够的人力以创立足够的RAD小组。RAD要求开发者和用户在一个很短的时间内完成一个系统, 如果双方中的任何一方没完成约定, 都会导致RAD项目失败。
( 3) 本企业适合的项目类型
具有可重用的构件库和CASE工具的应用项目; 信息系统等。
3、 几种模型的比较
软件生命
周期模型
是否首先定义好绝
大部分的需求?
是否有多个
开发周期?
是否有
中间软件发布
瀑布模型
有
无
无
原型＋瀑布模型
没有
有
有
增量模型
有
有
可能
增量的迭代模型
没有
有
有
快速应用开发模型
没有
有
可能
4、 其它模型采用说明
如果在实际工作中, 基于特定项目的经验积累和总结, 可能需要形成新的软件生命周期模型, 此时可依照一定的规程( 参见《标准软件过程开发和维护要求》、 《项目策划程序文件》) 将其定义和描述加入到本文件中。
5、 附录
附录1　软件过程结构图
说明: 图中”项目软件开发过程”一层延伸到产品退役, 即体现出软件的生命周期。采用不同的生命周期模型在该层面的”系统分析”和”软件开发”阶段对应不同的过程。

软件过程结构图

软件开发过程
目　录
1、 概述 2
1.1　目的 2
1.2　适用范围 2
1.3　引用文件 2
1.4　术语 2
1.5　参考资料 2
2、 过程总体描述 2
2.1　过程概述 2
2.2　结构描述 2
2.3　过程级裁剪指南 2
3、 过程元素 2
3.1　系统分析 2
3.2　软件需求分析 2
3.3　结构设计 2
3.4　详细设计 2
3.5　编码 2
3.6　集成测试 2
3.7　系统测试 2
3.8　验收 2
3.9　验收 2
3.10　软件问题管理 2
4、 附录 2
附录2.3－1　中大型软件工程项目的标准软件开发过程 2
附录2.3－2　中小型软件工程项目的标准软件开发过程 2
附录2.3－3　小型软件工程项目的标准软件开发过程 2
附录3.1－1　《系统架构和业务需求说明书》文档编写规范 2
附录3.1－2　《可行性分析报告》文档编写规范 2
附录3.1－3　《系统需求规格说明书》文档编写规范 2
附录3.2－1　需求分析方法指南 2
附录3.2－2　结构化分析法 2
附录3.2－3　面向对象分析法( OOA) 2
附录3.2－4　快速原型法 2
附录3.2－5　《软件需求规格说明书》文档编写规范 2
附录3.2－6　《测试计划》文档编写规范 2
附录3.3－1　《软件结构设计说明书》文档编写规范 2
附录3.4－1　《软件详细设计说明书》文档编写规范 2
附录3.5－1　《测试报告》文档编写规范 2
附录3.6－1　集成工作单 2
附录3.6－2　集成测试工作单 2
附录3.9－1　《软件维护实施计划》文档编写规范 2
附录3.10－1　软件问题报告单 2
附录3.10－2　软件问题状态登记表 2

1、 概述
1.1　目的
本程序文件定义了公司内部的软件开发过程, 以指导和规范软件项目中开发过程的定义和相应的实施。
1.2　适用范围
整个公司内的软件项目。
1.3　引用文件
《过程描述文件编写规范( 一) 》( QMS-PSM02-V1.0)
《标准软件过程的开发和维护》( QMS-PSM01-V1.0)
《软件生命周期模型描述文件》( QMS-PSM05-V1.0)
《客户需求管理程序文件》( QMS-PTM01-V2.0)
《技术类评审程序文件》( QMS-PTM09-V1.0)
《软件配置管理程序文件》( QMS-PTM09-V1.0)
《术语》( QMS-PSM07-V1.0)
1.4　术语
•过程: 把输入转换为输出的一组彼此相关的活动。
•构造: 将源代码进行编译、 连接、 生成目标代码的过程。
•构造环境: 主要指与源码一起进行编译、 连接的环境, 在C语言中一般是指由编译、 连接命令、 环境参数、 操作语句等构成的一系列脚本程序的组合。
•白盒测试: 基于源码进行的测试, 主要的形式包括语句覆盖、 分支覆盖、 路径覆盖等。
•黑盒测试: 基于目标代码的测试, 主要的形式为功能测试。
•回归测试: 对新增的功能或更正错误的部分( 包括与其相关的部分) 进行的测试, 而不是对软件系统全面的测试。
其它术语参见《术语》文件。
1.5　参考资料
•《软件能力成熟度模型CMM方法及其应用》, 杨一平等著, 人民邮电出版社, 4月
•《实践中的CMM－INFOSYS公司实施软件项目之过程》, 潘卡·杰罗特著, 杨慧鸣、 李光龙泽, 7月
•《Managing the Software Process》Watts S. Humphrey, Addison Wesley Longman, Inc, 1989
•《Recommended Approach to Software Development》 SEL-81-305, 1992.6
•《软件需求》, Karl E. Wiegers著, 陆丽那、 王忠民、 王志敏等译, 机械工业出版社, 7月
•《软件工程Java语言实现》, Stephen R. Schach著, 袁兆山等译, 机械工业出版社, 1999年9月
•《软件工程实践者的研究方法》, Roger S. Pressman著, 黄柏素、 梅宏等译, 机械工业出版社, 1999年10月
•国际－信息技术－软件生存周期过程指南　GB/T8566-
•军标－软件开发与文档编制　SJ20778-
2、 过程总体描述
2.1　过程概述
软件开发过程是指软件产品开发活动中所有阶段、 任务的组合。该过程可划分为一系列子过程, 包括: 系统分析、 软件需求分析、 设计、 编码、 测试、 验收、 维护, 每个子过程又由一系列任务和活动组成, 如设计过程又可分为结构设计和详细设计。
本程序文件描述公司通用的软件开发过程的组成( 称之为”过程元素”) 、 彼此之间的关系( 输入、 输出接口) , 以及相应的裁剪指南。具体的软件开发项目能够根据其范围、 规模和复杂度, 确定软件生命周期模型, 参见《软件生命周期模型描述文件》; 然后根据通用的软件开发过程和裁剪指南, 确定项目具体的软件开发过程。
本程序文件涉及的裁剪指南分为两个层次, 一层为过程级, 主要针对不同的项目所采取的过程的剪裁, 以定义不同的典型过程; 另一层为过程元素内部, 主要针对元素内部的各个任务的剪裁。
2.2　结构描述
软件开发过程在整个标准软件过程中的位置及组成见下图2.2－1。

图2.2－1　软件过程结构图
本程序文件所描述的软件开发过程的元素的组成见下表:
过程元素
阶段
需求分析
设计
实现
测试
验收
维护
系统分析
√

软件需求分析
√

结构设计

√

详细设计

√

编 码

√

集成测试

√
√

系统测试

√

验 收

√

维 护

√

每个过程元素的具体描述和工作要求见本程序文件第三节的”过程元素”描述。
2.3　过程级裁剪指南
活　动
可裁剪属性
选　择
裁剪指导方针
开发过程
全过程
( 附录2.3－1)
执行
执行
针对中大型软件工程项目或
系统需求明确完全自行设计、 实现的项目
简化过程1－1
( 附录2.3－2)
执行
执行
针对中小型软件工程项目
自编/移植软件
简化过程1－2
( 附录2.3－2)
执行
执行
针对中小型软件工程项目
自由软件
简化过程2－1
( 附录2.3－3)
执行
执行
针对小型软件工程项目
自编/移植软件
简化过程2－2
( 附录2.3－3)
执行
执行
针对中小型软件工程项目
自由软件
软件开发过程中的技术类评审方式
见《技术类评审程序文件》中相应裁剪指南
3、 过程元素
以下分别对软件开发过程中的各个元素进行描述。
3.1　系统分析
3.1.1　元素概述
系统分析的目的是形成一个清楚的、 完整的、 一致的和可验收测试的系统需求规格说明书, 与其它过程元素的关系如下图所示:
软件需求分析
硬件设计、 实现、 集成
系统