规划中组件开发流程程序文件

1、规划中组件开发流程程序文件程序文件 规划中组件开发流程2003年 月 日起生效 文件号 编制 审核 批准 版 次1.0 日期 日期 日期 共31页第10页1 目的及适用范围1.1 为规范规划中组件开发过程，提高组件开发的效率和质量，建立侏罗纪自己的组件库，充分发挥组件可复用性的优势，特制定本程序；1.2 本程序文件适用于侏罗纪公司规划中的组件开发；1.3 本程序文件由侏罗纪公司 制定，其解释权及修改权属于 ；1.4 本程序文件从2003年 月 日起执行；2 职责2.1 研究院负责组件规划.开发和组件库的建设；2.2 质量控制部负责对组件开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符

2、合规范的成果放入资源中心存档；3 规划中组件开发流程3.1 项目总监编写组件规划，下发给组件部部门经理；3.2 组件部部门经理依据组件规划进行组件研发立项，制订组件研发项目计划，并交给项目总监评审，若未通过，组件部部门经理对研发项目计划进行修改；3.3 若通过评审，组件部部门经理进行研发项目的总体设计，质量控制部对总体设计进行质量检验，若未通过质量检验，组件部部门经理修改总体设计，若通过质量检验，质量控制部将相应的成果放入资源中心存档，同时组件部部门经理对组件部专题组提出组件开发需求；3.4 组件部专题组接到组件开发需求后进行组件研发，并将研发成果交给组件部部部门经理进行内容评审，若未通过，组

3、件部专题组对研发成果进行修改；3.5 若通过内容评审，质量控制部对研发成果进行质量检验，若未通过质量检验，组件部专题组修改研发成果，若通过质量检验，质量控制部将研发成果放入资源中心归档，组件部部门经理进行研发项目的项目总结，同时组件部核心平台组对经过检验的研发成果进行框架组装；3.6 质量控制部对项目总结进行质量检验，若未通过质量检验，组件部部门经理修改项目总结，若通过质量检验，质量控制部将相关成果和文档放入资源中心存档；4 相关文件4.1 组件规划说明书4.2 项目计划4.3 综合评审记录4.4 组件设计说明书4.5 质量控制组件设计说明书评审记录4.6 组件开发需求4.7 开发进度周报等组

4、件研发相关文档4.8 内容验收单4.9 软件缺陷报告等相关测试文档4.10 框架组装说明4.11 项目总结4.12 资源中心验收单 组件规划说明书 公司三年组件规划1.2.3. 公司年度组件计划1.2. 签发人： 时间 （组件研发）项目计划 项目名称 项目编号 项目经理 项目任务描述 项目总时间及关键里程碑设置 项目人力资源 项目费用预计 审批人意见： 总监： 副总监： 执委会： 备注：抄送财务部.人力资源部 时间 综合评审记录（公司） 评审对象（项目名称及编号） 评审项类（如合同.投标方案等） 评审人 时间 业务板块(产品中心.项目中心.服务中心.营销中心)评审意见 财务部评审意见 质量控制

5、部评审意见 技术委员会评审意见 专家委员会评审意见 最终意见： 通过 修改 修改内容 时间 组件设计说明书 组件设计说明书编制的目的是说明对程序的设计考虑，包括程序的基本流程.程序的组织结构.模块划分.接口设计。运行设计.数据结构设计和出错处理设计等，编制组件设计说明书的内容 要求如下：1.引言1.1编写目的1.2背景1.3定义1.4参考资料2.总体设计2.1需求规定2.2运行环境2.3基本设计概念和处理流程 说明组件的基本设计概念和处理流程，尽量使用图表的形式。2.4结构 用一览表及框图的形式说明组件的元素（各层模块.子程序.公用程序等）的划分，扼要说明每个元素的标识符和功能，分层次地给出各

6、元素之间的控制与被控制关系.2.5功能需求与程序的关系 说明各项功能需求的实现同各块程序的分配关系2.6尚未解决的问题 说明在设计过程中尚未解决而设计者认为在完成之前必须解决的各个问题。3.接口设计3.1外部接口3.2内部接口4.运行设计4.1运行控制 说明每一种外界的运行控制的方式方法和操作步骤。5.组件数据结构设计5.1逻辑结构设计 给出所使用的每个数据结构的名称.标识符以及它们之中每个数据项.记录.的标识.定义.长度及它们之间的层次相互关系。5.2物理结构设计 给出所使用的每个数据结构中的每个数据项的存储要求，访问方法6.系统出错处理设计6.1出错信息6.2补救措施 组件开发需求模板 V

7、ersion1.组件简述 对组件要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书部分。2. 组件设计目标 这部分论述组件的设计目标，明确地说明哪些功能是组件决定实现而哪些是不准备实现的。同时，对于非功能性的需求例如性能.可用性等，亦需提及。如果组件有可视化部分，亦需有简单的界面描述或图型描述。需求说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的组件有什么特点和功能。在随后的相关文档中，将解释和设计是怎么来实现这些的。3 参考资料 列出本文档中所引用的参考资料。（至少要引

8、用需求说明书）4 修订版本记录 列出本文档修改的历史纪录。必须指明修改的内容.日期以及修改人。5 术语表 对本文档中所使用的各种术语进行说明。如果一些术语在需求说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。开发进度周报 开发进度周报的编制目的是及时向有关管理部门汇报组件开发的进展和情况，以便及时发现和处理开发过程中出现的问题。具体的内容要求如下：1.项目概要2.工程进度与状态2.1进度2.2状态3.下一周的工作计划4.建议 文档编号：Test005 版本编号：V1.00 密 级：中 北京侏罗纪软件开发有限公司 质量控制部文档 XX系统 之 xx系统 缺陷报告 文档编号：Tes

9、t005 版本号 ：V1.0 文 件 名：缺陷报告.doc 编 写：质量控制部 年 月 日 校 对： 年 月 日 审 核： 年 月 日 批 准： 年 月 日 程序文件 规划中组件开发流程2003年 月 日起生效 文件号 编制 审核 批准 版 次1.0 日期 日期 日期 共31页第15页 XXX系统之 XX系统 缺陷报告 版本1.0 修订历史记录 日期 版本 说明 作者1.0 首次的缺陷报告 质量控制部 缺陷报告 一.简介1.1目的 本文档作为XXX系统之的“缺陷报告”，有助于实现以下目标： A. 列出测试活动的主要内容。B . 列出测试活动的测试统计结果。C . 列出系统的主要缺陷。D . 对

10、于缺陷提出的修改建议。E . 由于本系统的某些需求尚未最后确定，目前只能对系统进行部分的功能测试及完全的用户界面测试。F . 本报告为针对测试活动的首次缺陷报告，以后的测试活动还会提交迭代的缺陷报告。G . 本文档提交给项目组的管理者及开发人员审阅。二.测试内容 下面的列表列出了本次测试活动的主要测试内容。2.1数据库测试 核实系统是否能访问数据库。2.2功能测试 核实2.3用户界面测试 浏览所有的用例，核实是否每个 UI 面板都易于理解。核实界面操作是否简单易行，图形显示是否清晰。三.测试统计结果及缺陷总结3.1数据库测试3.1.1核实系统是否能访问数据库。3.2功能测试3.2.1核实是否能

11、够浏览数据库中保存的电子化文档；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用户界面方面 文档编号：Test005 版本编号：V1.00 密 级：中 北京侏罗纪软件开发有限公司 质量控制部文档 XX系统 之 xx系统 缺陷报告 文档编号：Test005

12、版本号 ：V1.0 文 件 名：缺陷报告.doc 编 写：质量控制部 年 月 日 校 对： 年 月 日 审 核： 年 月 日 批 准： 年 月 日 程序文件 规划中组件开发流程2003年 月 日起生效 文件号 编制 审核 批准 版 次1.0 日期 日期 日期 共31页第23页 XXX系统之 XX系统 缺陷报告 版本1.0 修订历史记录 日期 版本 说明 作者1.0 首次的缺陷报告 质量控制部 缺陷报告 一.简介1.1目的 本文档作为XXX系统之的“缺陷报告”，有助于实现以下目标： H. 列出测试活动的主要内容。I . 列出测试活动的测试统计结果。J . 列出系统的主要缺陷。K . 对于缺陷提出

13、的修改建议。L . 由于本系统的某些需求尚未最后确定，目前只能对系统进行部分的功能测试及完全的用户界面测试。M . 本报告为针对测试活动的首次缺陷报告，以后的测试活动还会提交迭代的缺陷报告。N . 本文档提交给项目组的管理者及开发人员审阅。二.测试内容 下面的列表列出了本次测试活动的主要测试内容。2.1数据库测试 核实系统是否能访问数据库。2.2功能测试 核实2.3用户界面测试 浏览所有的用例，核实是否每个 UI 面板都易于理解。核实界面操作是否简单易行，图形显示是否清晰。三.测试统计结果及缺陷总结3.1数据库测试3.1.1核实系统是否能访问数据库。3.2功能测试3.2.1核实是否能够浏览数据

14、库中保存的电子化文档；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.引言32. 项目开发结果32.1软件产品或软件项目32.2主要功能和性能42.3项目

15、规模总结42.4项目人员总结52.5进度及工作量总结53. 项目评价73.1生产效率评价73.2技术方法评价73.3产品质量评价73.4出错原因分析84. 经验和教训81.引言 说明实际参加人员.时间及工作划分：说明参加本项目的负责人.参加人员.起止时间及实际工作量。按项目开发的阶段划分，细划每位开发人员在各开发阶段所用开发时间及实际工作量。负责人： 起止时间： 计划工作量： 项目情况 阶段 参加人员 工作内容 起止时间 实际工作量 需求分析 A.B 等等 系统设计 编码 测试 其它 合计2. 项目开发结果2.1 软件产品或软件项目2.1.1软件产品或软件项目名称：给出该软件项目或软件产品在项

16、目任务书或开发计划评审等文件中确定的正式的项目名称和项目编号；并给出该软件项目或软件产品正式批准发布的版本标识。2.1.2 程序量：按模块进行划分，给出该软件项目或软件产品的源程序的存贮容量。源代码用代码行来表示，可执行程序及其他程序可用字节来表示，文档可用页或字节来表示。（源代码一定要按模块来统计） 模块名称 代码行（千行） 字节数（KB） 源码 模块1 模块2 执行程序 等等 注：源码不填写“字节数”，执行程序只填写“字节数”。2.1.3 存储介质：给出该软件项目或软件产品正式发布版本的存储介质及所需存储介质及 其数量。2.2 主要功能和性能1）描述该软件项目或软件产品所实现的功能，根据需

17、要说明该软件项目或软件产 品的有关性能指标。2）与最初的需求相比较，给出功能和/或性能上的差异并说明原因。2.3 项目规模总结 根据软件开发的各阶段，总结该软件项目或软件产品完成的功能模块数量与计划的对比，给出对比图表，并对比较结果进行分析。阶段 计划模块数 完成模块数 需求分析 系统设计 编码 测试 合计2.4 项目人员总结 总结该软件项目或软件产品开发各阶段人员的变化情况与计划的对比，并对比较结果进行分析。阶段 计划人数 实际人数 增加人数 减少人数 变动人数 需求分析 系统设计 编码 测试 总计 注：变动人数为人员更换数。程序文件 规划中组件开发流程2003年 月 日起生效 文件号 编制

18、 审核 批准 版 次1.0 日期 日期 日期 共31页第31页2.5 进度及工作量总结 总结该软件项目或软件产品实际完成所用的时间及工作量与原计划的对比。用图表来表示。2.5.1 从开发人员的角度进行总结：将每位开发人员开发该软件项目或软件产品起止时间和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。开发人员 计划时间 实际时间 是否按时 计划M 实际M A B C D 等等2.5.2 从模块的角度进行总结：将每一模块完成的起止时间和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。模块名称 计划时间 实际时间 是否按时 计划M 实际M 模块1 模块2 模块3 模块4 总计2

19、.5.3 从开发阶段的角度进行总结：将每一阶段完成的起止时间和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。阶段 计划时间 实际时间 是否按时 计划M 实际M 需求分析 系统设计 编码 测试 总计2.5.4 从工作量的角度进行总结：将开2.5.5 发该软件项目或软件产品所用工作量与计划进行比较，给出由于软件问题报告所增加的工作量，给出对比图表，并对比较结果进行分析。批复工作量 实际工作量 计划 增加 小计2.5.6 从完成情况进行总结：将项目的总体进度和阶段进度与计划进行比较，说明此项目是正常完成.正常但增加工作量.延期但不增加工作量.即延期又增加工作量，并对比较结果进行分析。计划

20、时间 实际时间 批复工作量 实际工作量 结论 注：以最后一版的开发计划中的开发进度为准，批复工作量包括由于软件问题报告增加的工作量。3. 项目评价3.1 生产率评价 评价生产率可以有两种方法：代码行数与人月数比较，或修改BUG数与所用人月数的比较。我们可以采用任何一种。如果采用第一种方法，应以模块为单位进行比较；如果采用第二种方法，应以各测试版本的BUG数.修改的BUG数.修改BUG所用的工作量及修改单位BUG所用的工作量进行比较，总结评价项目的开发效率及相应的原因分析。模块名称 代码行（千行） 工作量 代码行/工作量 模块1 模块2 等等3.2 技术方法评价 总结该软件项目或软件产品开发时所采用的各项技术。3.3