项目中组件开发流程程序文件.docx
《项目中组件开发流程程序文件.docx》由会员分享，可在线阅读，更多相关《项目中组件开发流程程序文件.docx（18页珍藏版）》请在冰豆网上搜索。
项目中组件开发流程程序文件
1目的及适用范围
1.1为规范项目中组件开发过程，使得项目部和研究院在项目执行中能够协调一致，充分发挥组件可复用性的优势，特制定本程序；
1.2本程序文件适用于侏罗纪公司项目中的组件开发；
1.3本程序文件由侏罗纪公司制定，其解释权及修改权属于；
1.4本程序文件从2003年月日起执行；
2职责
2.1项目部负责提出需求和进行验收，研究院负责组件开发和组件库的建设；
2.2质量控制部负责对组件开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成果放入资源中心存档；
3项目中组件开发流程
3.1研究院工程部接到项目部提出的需求分析后，进行组件设计，填写《组件设计说明书》，递交到质量控制部评审，若未通过评审，工程部对《组件体设计说明书》进行修改；
3.2若通过评审，质量控制部将相关文档放入资源中心存档，同时工程部通知研究院组件部核心平台组查询组件；
3.3组件部核心平台组在组件库中查询组件，若有所需要的组件，核心平台组进行框架组装，交给工程部进行系统定制；
3.4若没有所需要的组件，核心平台组向组件部专题组提出《组件需求单》。
组件部专题组进行组件研发，组件部部门经理对组件内容进行审核，若未通过，组件部专题组对组件进行修改，若通过，质量控制部对组件进行质量检验，若未通过，组件部专题组对组件进行修改，若通过，质量控制部将相关成果放入资源中心存档，同时核心平台组进行框架组装，交给工程部进行系统定制；
3.5工程部进行完系统定制后交给质量控制部进行功能测试，若未通过，工程部修改系统定制，若通过，质量控制部对相关成果进行质量检验。
3.6系统定制如果未通过质量检验，工程部修改系统定制；若通过质量检验，质量控制部将相关成果放入资源中心存档，同时工程部将定制的系统和组件交给项目经理验收后进行实施；
4相关文件
4.1《组件设计说明书》
4.2《评审规程》
4.3《质量控制组件设计说明书评审记录》
4.4《组件说明书》
4.5《框架组装说明》
4.6《组件开发需求》
4.7系统定制相关文件（略）
4.8《软件缺陷报告》等相关测试文档
4.9《项目部对组件的验收单》
4.10《内容验收单》
4.11《资源中心验收单》
《组件设计说明书》
组件设计说明书编制的目的是说明对程序的设计考虑，包括程序的基本流程、程序的组织结构、模块划分、接口设计。
运行设计、数据结构设计和出错处理设计等，编制组件设计说明书的内容要求如下：
1．引言
1．1编写目的
1．2背景
1．3定义
1．4参考资料
2．总体设计
2．1需求规定
2．2运行环境
2．3基本设计概念和处理流程
说明组件的基本设计概念和处理流程，尽量使用图表的形式。
2．4结构
用一览表及框图的形式说明组件的元素（各层模块、子程序、公用程序等）的划分，扼要说明每个元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系．
2．5功能需求与程序的关系
说明各项功能需求的实现同各块程序的分配关系
2．6尚未解决的问题
说明在设计过程中尚未解决而设计者认为在完成之前必须解决的各个问题。
3.接口设计
3．1外部接口
3．2内部接口
4.运行设计
4．1运行控制
说明每一种外界的运行控制的方式方法和操作步骤。
5.组件数据结构设计
5．1逻辑结构设计
给出所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、的标识、定义、长度及它们之间的层次相互关系。
5．2物理结构设计
给出所使用的每个数据结构中的每个数据项的存储要求，访问方法
6.系统出错处理设计
6．1出错信息
6．2补救措施
评审规程
状态：
草稿
标识号：
评审
当前版本：
1.0
初始版
前一版本：
修订版
发布日期：
摘要
本文详细描述了软件工作产品的评审规程。
将要执行评审的所有项目的软件工作产品都必须遵循该评审规程。
修改历史
日期
版本
作者
修改内容
评审号
更改请求号
1目的和范围
本文档主要描述了软件工作产品的评审过程，目的是能够及早和有效地发现并排除软件工作产品的缺陷。
2评审角色
在评审时有四种角色：
作者、评审组长、记录员及其他人员。
这些角色在评审会上要承担不同的职责。
角色的划分必须遵循下面的原则：
作者和评审组长是必须的角色，且不能为同一人
记录员可以是任何人员，也可由作者或评审组长兼任
其他人员在数量上没有限制，可以来自与项目相关的其它组织或部门
所有人员都必须具备相关的技术背景知识，对评审的软件工作产品有足够的了解，熟悉评审规程。
2.1作者
作者是指被评审的软件工作产品的作者，其主要职责如下：
准备相关的评审资料
完成评审后的修改工作
2.2评审组长
评审组长必须为该软件工作产品所属领域的高级技术人员，其主要职责如下：
指导作者组织并实施评审活动，对评审材料进行初审，确定参加评审的人员
按照评审规程主持评审会议
在评审会议上控制评审进度，提醒参加者不要在某一问题上花费过多时间
对评审中发现的问题进行分析判断，确定处理办法，建议为两类：
1.问题项：
当场确定为问题，需要解决
2.调查项：
无法确定是否为主要问题，需要进一步调查确认
决定评审结果（通过和再评审）
2.3记录员
记录员在评审会议中记录发现的问题及相关的数据，其主要职责如下：
填写评审记录表
作为评审员参与评审
2.4其他参与人员
其他人员评审软件工作产品，回答问题、参与讨论同时帮助解决问题。
所有的参与人员都必须严格遵循评审规程。
3评审过程
评审过程分为四个阶段，每一阶段都包含一定的任务描述，可以参考《评审活动检查表》执行评审。
《评审活动检查表》是帮助评审人员正确执行评审的工具，它与本章所描述的各阶段的具体活动是一致的。
评审过程的四个阶段为：
计划、准备、执行和整理。
每一阶段必须顺序地执行，才能保证评审成功。
下面将详细描述这四个步骤。
3.1计划阶段
这是评审的第一阶段，其每一步都有详细说明，只有计划阶段的任务完成后才能进入准备阶段。
3.1.1进入条件
软件工作产品满足规范要求
软件工作产品经过拼写检查
3.1.2目的
确保作者提供正确的评审材料
确保软件工作产品满足评审要求
确定评审员并明确其职责
3.1.3活动
作者准备评审所需的材料，包含被评审的软件工作产品、支持材料及评审表格等
技术委员会指定评审组长
评审组长检查进入标准是否满足
技术委员会确定参评人员。
也可由技术委员会委托评审组长确定需要参加评审的人员
评审组长确认作者准备好所需要的材料
评审组长与作者共同确定评审会议日程
3.2准备阶段
3.2.1进入条件
评审材料已准备好
参加者对被评审的软件工作产品具备必要的背景知识
评审组长确认评审材料符合要求
3.2.2目的
评审员明确自己的职责
所有评审员在评审之前得到评审材料
确保评审员在评审之前阅读评审材料，找出问题
3.2.3活动
作者发评审会议通知给所有评审员
作者将评审材料分发给所有评审员
评审组长标识软件工作产品的范围，强调重点，提取问题
评审组长熟悉议程，确保评审进度
评审员仔细阅读评审材料，在评审材料上做评注，找出问题
所有评审员记录自己准备所花费的时间
3.3执行阶段
执行评审必须召开评审会议，所有评审员进行面对面地讨论是必要的。
3.3.1进入条件
所有评审员得到评审材料
所有评审员根据自己的角色要求准备并且评审软件工作产品
所有评审员记录自己的准备时间。
本次评审的准备时间是所有评审员的准备时间之和
会议室和其它资源已经准备就绪
作者准备就绪，重要参加人员能够出席评审会议
3.3.2目的
找出、记录和分析所有问题
3.3.3活动
评审组长检查所有评审员是否已经做好评审的准备工作
记录员记录评审员的准备时间，开始评审
作者为软件工作产品逐项进行概要介绍
记录员在评审会议上记录发现的问题
所有评审员把重点放在讨论和提出问题上
评审员使用自己注释的评审材料对有问题的地方提出讨论
作者和评审员协助评审组长描述和分析问题，
发现一个问题后，评审组长确保该问题被正确记录
所有评审员提出对评审会议的改进建议，记录员在评审表上记录要点
评审组长确保评审完成
评审组长在评审组的协助下决定评审结果。
如果没有问题或发现的问题类型和数量容易改正和处理，其结果为“通过”，否则为“再评审”
如果需要“再评审”，可以只评审需要评审的部分。
评审组长记录需要再被评审的部分
3.4整理阶段
3.4.1进入条件
问题已被记录在评审表中
3.4.2目的
修正评审中发现的所有问题
确保所有需要进行调查的项目已经被分析，并且被排除
评审数据被记录
3.4.3活动
评审组长估计并跟踪修改问题所需时间
对于问题项，作者确保有问题记录
对于调查项，经研究后，如果是问题项，作者负责解决并记录在评审表中
作者修正所有问题项
评审组长协调所有评审员检查作者已修改过的内容。
如果没有问题，则评审结果定为“通过”，否则，评审组长应提出解决方案
所有评审员确认后，在评审表上签字
如果使用评审工具代替评审记录表，则作者在评审工具中生成一个新的评审记录表，填入相应内容并提交
4附录A评审活动检查表
阶段
作者
评审组长
其他评审员
计划
☐
☐接受评审组长角色并确定评审目标
☐准备评审材料
☐检查评审进入条件是否满足
☐同评审组长一起选择评审员
☐确定需要参加评审的人员
☐接受评审员角色
☐与评审组长共同
准备
☐确保评审材料准备好
☐核实进入条件
☐理解自己的职责
☐给所有评审员发评审会议通知
☐学习并且评注软件工作产品
☐学习并且评注软件工作产品
☐将被评审材料分发给所有评审员
☐熟悉评审议程
☐记录个人的准备时间
☐确保会议室和其它资源准备就绪
☐记录个人的准备时间
执行
☐介绍评审会议日程
☐控制评审进度
☐按时出席，提供准备时间
☐逐项概要介绍软件工作产品
☐分析问题
☐记录员记录所有评审员姓名及准备时间
☐决定评审结果
☐参加讨论并提出问题
☐记录员记录问题
☐所有评审员提出对评审会议的改进建议，记录员在评审表上记录要点
整理
☐改正评审所发现的问题
☐估计并跟踪需要修改问题所需时间
☐如果有评审工具，则生成一个新的评审记录表，填入相应内容并提交
☐检查修改内容的正确性
☐阅读并确认评审记录表内容的正确性
☐提交文档
☐签字
☐签字
注：
首先由技术委员会指定评审组长。
5附录B评审记录表
评审会日期：
_________________开始时间：
_________________结束时间：
_________________
评审会地点：
___________________________________________________________第_____次评审
评审主题：
__________________________________________________________________________
__________________________________________________________________________
软件工作产品名称：
________________________________软件工作产品大小：
_________SLOC/页
软件工作产品标识号：
____________________________版本号：
_______作者：
_______________
评审员及准备时间：
角色
姓名
准备时间（小时）
评审组长
作者
记录员
评审员
总和
问题记录：
序号
位置
描述
类型
状态
问题项
调查项
未解决
已解决
问题项
调查项
未解决
已解决
修改软件工作产品工作量（小时）：
___________________
评审结果：
□通过□再评审
改进建议：
__________________________________________________________________________
__________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
签字：
角色
姓名
签字
评审组长
评审员
6附录C评审通知
主题：
第次评审
期望准备时间：
评审会日期：
开始时间：
持续时间：
评审会地点：
软件工作产品名称：
软件工作产品标识号：
版本号：
作者：
评审组长：
记录员：
其他评审员：
议程：
起止时间
主题
软件工作产品信息：
软件工作产品标识号：
版本：
软件工作产品大小（SLOC/页）：
其它支持材料：
遵循标准：
其它：
《组件说明书》
1．组件描述
在这个部分叙述每个组件的细节，它的属性、它的方法。
在这之前必须从逻辑上对组件进行组织。
需要用结构图把组件划分好。
为每个组件做一个条目。
在系统组件模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。
对每个组件的每个属性详细说明：
名字、类型，如果属性不是很直观或者有约束（例如，每个组件的该属性必须有一个唯一的值或者值域是有限正整数等）。
对每个组件的每个方法详细说明：
方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。
如果对变量或者返回值由什么假定的话，必须在此说明。
列出它或者被它调用的方法需要访问或者修改的属性。
最后，提供可以验证实现方法的测试案例。
2.系统中的组件
2.1对象：
对象1
用途：
约束：
持久性：
2.1.1属性描述：
1.属性：
属性
类型：
描述：
约束：
2.1.2方法描述：
1.方法：
方法
返回类型：
参数：
返回值：
读取/修改的属性：
调用的方法：
处理逻辑：
测试例：
用什么参数调用该方法，期望的输出是什么......
3．动态模型
这部分的作用是描述组件如何响应各种事件。
例如，可以建立组件的行为模型。
一般使用顺序图和状态图。
4．非功能性需求
在这个部分，必须说明如何处理需求文档中指定的非功能性需求。
尽可能客观地评估系统应付每一个非功能性的需求的能力程度。
如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。
另外，你也需要对组件将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。
5．辅助文档
提供能帮助理解设计的相应文档。
《组件开发需求》模板
Version
1.组件简述
对组件要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书部分。
2.组件设计目标
这部分论述组件的设计目标，明确地说明哪些功能是组件决定实现而哪些是不准备实现的。
同时，对于非功能性的需求例如性能、可用性等，亦需提及。
如果组件有可视化部分，亦需有简单的界面描述或图型描述。
需求说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的组件有什么特点和功能。
在随后的相关文档中，将解释和设计是怎么来实现这些的。
3参考资料
列出本文档中所引用的参考资料。
（至少要引用需求说明书）
4修订版本记录
列出本文档修改的历史纪录。
必须指明修改的内容、日期以及修改人。
5术语表
对本文档中所使用的各种术语进行说明。
如果一些术语在需求说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
文档编号：
Test005
版本编号：
V1.00
密级：
中
北京侏罗纪软件开发有限公司
质量控制部文档
XX系统之
xx系统
缺陷报告
文档编号：
Test005版本号：
V1.0
文件名：
缺陷报告.doc
编写：
质量控制部年月日
校对：
年月日
审核：
年月日
批准：
年月日
XXX系统之
XX系统
缺陷报告
版本1.0
修订历史记录
日期
版本
说明
作者
1.0
首次的缺陷报告
质量控制部
缺陷报告
一.简介
1.1目的
本文档作为《XXX系统》之的“缺陷报告”，有助于实现以下目标：
A、列出测试活动的主要内容。
B、列出测试活动的测试统计结果。
C、列出系统的主要缺陷。
D、对于缺陷提出的修改建议。
E、由于本系统的某些需求尚未最后确定，目前只能对系统进行部分的功能测试及完全的用户界面测试。
F、本报告为针对测试活动的首次缺陷报告，以后的测试活动还会提交迭代的缺陷报告。
G、本文档提交给项目组的管理者及开发人员审阅。
二.测试内容
下面的列表列出了本次测试活动的主要测试内容。
2.1数据库测试
核实系统是否能访问数据库。
2.2功能测试
核实..
2.3用户界面测试
浏览所有的用例，核实是否每个UI面板都易于理解。
核实界面操作是否简单易行，图形显示是否清晰。
三.测试统计结果及缺陷总结
3.1数据库测试
3.1.1核实系统是否能访问数据库。
3.2功能测试
3.2.1核实是否能够浏览数据库中保存的电子化文档；
3.2.2核实是否能够查找和检索资料；
3.2.3核实是否能够实现资料文件的管理；
3.2.4核实是否能够实现资料文件图片的导入；
3.2.5核实是否能够实现资料文件图片的导出；
3.2.6核实是否能够实现资料的打印输出；
3.2.7核实是否具有灵活的显示模式，如放大、缩小等。
3.3用户界面测试
3.3.1窗口
3.3.2下拉式菜单和鼠标操作
3.3.3数据项
四.针对缺陷提出的建议
4.1功能方面4.2用户界面方面
资源中心验收单（式样）一式三份
序号
编号
成果题名
完成日期
提交日期
页数
密级
保管期限
备注
1
NAVIKENVer2.1
1998-8-21
72
长期
MO盘
2
多媒体办公自动化系统MOAS
1998-12-30
42
长期
磁盘
填表人：
成果管理员：
成果提交人：
卷内成果目录（式样）一式三份
序号
文件编号
责任者
题 名
日期
页次
备注
1
AT97004DP01
李峰
FAX
1997-3-31
1
2
NA504100A
王琛
乐器练习软件功能说明书
1997-4-3
4
3
AT97004SD01
李峰
乐器练习软件概要书
1997-4-3
64
4
NR506100A
王琛
AMORRTVer1.0开发计划
1997-4-25
102
第页/共页
升级会员 