资源描述
程序文件
数据服务项目实施步骤
月 日起生效
文件号
编制
审核
同意
版 次
1.0
日期
日期
日期
共15页
第1页
1 目标及适用范围
1.1 为规范数据服务业务中项目实施过程,达成项目标成本、进度、质量统一,特制订本程序;
1.2 本程序文件适适用于侏罗纪企业数据服务项目提供;
1.3 本程序文件由侏罗纪企业 制订,其解释权及修改权属于 ;
1.4 本程序文件从 月 日起实施;
2 职责
2.1 数据服务部负责项目实施总体进程,并对实施最终止果负责;
2.2 主管副总负责在关键节点监控和协调资源;
2.3 质量控制部负责对项目实施过程中里程碑产生相关结果和文档进行质量控制,并将符合规范结果放入资源中心存档;
3 数据服务项目实施步骤
3.1 销售部签完协议后,数据服务业务项目经理(在项目销售步骤中准项目经理)制订《项目计划书》,交由主管副总审批,假如未经过,项目经理重新修改《项目计划书》;
3.2 假如审批认可,主管副总安排项目资源,假如需要,则填写《项目资源调度单》,同时将相关资料交给资源中心立案;
3.3 项目经理得到对应资源配置后,开始组建项目团体;
3.4 项目经理组建项目团体同时,制订项目实施方案,并经质量控制部审核,若未经过,项目经理对项目实施方案进行修改;
3.5 实施方案经过质量控制部审核后,项目经理和用户一起对实施方案进行协商和评审,若未经过,项目经理修改实施方案;
3.6 实施方案经过用户评审经过,进入资源中心存档,同时项目经理进行项目实施;
3.7 项目经理负责用户对项目实施结果进行评审,如未经过,项目经理对项目实施进行返工;
3.8 假如经过用户评审,项目经理进行项目总结,并将相关结果和文档交由质量控制部检验,如未经过,项目经理负责对未经过部分进行修改;
3.9 假如经过质量控制检验,项目经理将结果总结交给用户,同时相关结果和文档由质量控制部放入资源中心存档;
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) 待开发软件系统名称;
(2) 本项目标任务提出者、开发者、用户及实现该软件计算中心或计算机网络;
(3) 该软件系统同其它系统或其它机构基础相互来往关系。
1.3 参考资料
列出所用参考资料,如:
(1) 本项目标经核准计划任务书或协议、上级机关批文;
(2) 属于本项目标其它已发表文件;
(3) 本文件中各处引用文件、资料,包含所需用到软件开发标准。
(4) 列出这些文件资料标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料起源。
1.4 术语
列出本文件中用到专门术语定义和外文首字母组词原词组。
2. 数据逻辑描述
对数据进行逻辑描述时可把数据分为动态数据和静态数据。所谓静态数据,指在运行过程中关键作为参考数据,它们在很长一段时间内不会改变,通常不随运行而改变。所谓动态数据.包含全部在运行中要发生改变数据和在运行中要输入、输出数据。进行描述时应把各数据元素逻辑地分成若干组,比如函数、源数据或对于其应用更为合适逻辑分组。给出每一数据元名称(包含缩写和代码)、定义(或物理意义)度量单位、值域、格式和类型等相关信息。
2.1 静态数据
列出全部作为控制或参考用静态数据元素。
2.2 动态输入数据
列出动态输入数据元素(包含在常规运行中或联机操作中要改变数据)。
2.3 动态输出数据
列出动态输出数据元素(包含在常规运行中或联机操作中要改变数据)。
2.4 内部生成数据
列出向用户或开发单位中维护调试人员提供内部生成数据。
2.5 数据约定
说明对数据要求制约。逐条列出对深入扩充或使用方面考虑而提出对数据要求限制(容量、文卷、统计和数据元个数最大值)。对于在设计和开发中确定是临界性限制更要明确指出。
3. 数据采集
3.1 要求和范围
按数据元逻辑分组来说明数据采集要求和范围,指明数据采集方法,说明数据采集工作负担者是用户还是开发者。具体内容包含:
(1) 输入数据起源,比如是单个操作员、数据输入站,专业数据输入企业或它们一个分组;
(2) 数据输入(指把数据输入处理系统内部)所用媒体和硬设备。假如只有指定输入点输入才是正当,则必需对此加以说明;
(3) 接收者说明输出数据接收者;
(4) 输出数据形式和设备列出输出数据形式和硬设备。不管接收者将接收到数据是打印输出,还是CRT上一组字符、一帧图形,或一声警铃,或向开关线圈提供一个电脉冲,或常见介质如磁盘、磁带、穿孔卡片等,均应具体说明;
(5) 数据值范围给出每一个数据元正当值范围;
(6) 量纲给出数字度量单位、增量步长、零点定标等。在数据是非数字量情况下,要给出每一个正当值形式和含意;
(7) 更新和处理频度给出预定对输入数据更新和处理频度。假如数据输入是随机,应给出更新处理频度平均值,或改变情况某种其它度量。
3.2 输入负担者
说明预定对数据输入工作负担者。假如输入数据同某一接口软件相关,还应说明该接口软件起源。
3.3 处理
对数据采集和预处理过程提出专门要求,包含适合应用数据格式、预定数据通信媒体和对输入时间要求等。对于需经模拟转换或数字转换处理数据量,要给出转换方法和转换因子等相关信息,方便软件系统使用这些数据。
3.4 影响
说明这些数据要求对于设备、软件、用户、开发单位所可能产生影响,比如要求用户单位增设某个机构等。
项目总结
项目编号:
部门名称:
目录
1. 引言
2. 项目开发结果
2.1软件产品或软件项目
2.2关键功效和性能
2.3项目规模总结
2.4项目人员总结
2.5进度及工作量总结
3. 项目评价
3.1生产效率评价
3.2技术方法评价
3.3产品质量评价
3.4犯错原因分析
4. 经验和教训
1. 引言
说明实际参与人员、时间及工作划分:说明参与本项目标责任人、参与人员、起止时间及实际工作量。按项目开发阶段划分,细划每位开发人员在各开发阶段所用开发时间及实际工作量。
责任人:
起止时间:
计划工作量:
项目情况
阶段
参与人员
工作内容
起止时间
实际工作量
需求分析
A、B
等等
系统设计
编码
测试
其它
累计
2. 项目开发结果
2.1 软件产品或软件项目
2.1.1 软件产品或软件项目名称:给出该软件项目或软件产品在项目任务书或开发计划评审等文件中确定正式项目名称和项目编号;并给出该软件项目或软件产品正式同意公布版本标识。
2.1.2 程序量:按模块进行划分,给出该软件项目或软件产品源程序存贮容量。源代码用代码行来表示,可实施程序及其它程序可用字节来表示,文档可用页或字节来表示。(源代码一定要按模块来统计)
模块名称
代码行(千行)
字节数(KB)
源码
模块1
模块2
实施程序
等等
注:源码不填写“字节数”,实施程序只填写“字节数”。
2.1.3 存放介质:给出该软件项目或软件产品正式公布版本存放介质及所需存放介质及
其数量。
2.2 关键功效和性能
1)描述该软件项目或软件产品所实现功效,依据需要说明该软件项目或软件产
品相关性能指标。
2)和最初需求相比较,给出功效和/或性能上差异并说明原因。
2.3 项目规模总结
依据软件开发各阶段,总结该软件项目或软件产品完成功效模块数量和计划对比,给出对比图表,并对比较结果进行分析。
阶段
计划模块数
完成模块数
需求分析
系统设计
编码
测试
累计
2.4 项目人员总结
总结该软件项目或软件产品开发各阶段人员改变情况和计划对比,并对比较结果进行分析。
阶段
计划人数
实际人数
增加人数
降低人数
变感人数
需求分析
系统设计
编码
测试
总计
注:变感人数为人员更换数。
2.5 进度及工作量总结
总结该软件项目或软件产品实际完成所用时间及工作量和原计划对比。用图表来表示。
2.5.1 从开发人员角度进行总结:将每位开发人员开发该软件项目或软件产品起止时间和工作量和计划进行比较,给出对比图表,并对比较结果进行分析。
开发人员
计划时间
实际时间
是否按时
计划M
实际M
A
B
C
D
等等
2.5.2 从模块角度进行总结:将每一模块完成起止时间和工作量和计划进行比较,给出对比图表,并对比较结果进行分析。
模块名称
计划时间
实际时间
是否按时
计划M
实际M
模块1
模块2
模块3
模块4
总计
2.5.3 从开发阶段角度进行总结:将每一阶段完成起止时间和工作量和计划进行比较,给出对比图表,并对比较结果进行分析。
阶段
计划时间
实际时间
是否按时
计划M
实际M
需求分析
系统设计
编码
测试
总计
2.5.4 从工作量角度进行总结:将开发该软件项目或软件产品所用工作量和计划进行比较,给出因为软件问题汇报所增加工作量,给出对比图表,并对比较结果进行分析。
批复工作量
实际工作量
计划
增加
小计
2.5.5 从完成情况进行总结:将项目标总体进度和阶段进度和计划进行比较,说明此项目是正常完成、正常但增加工作量、延期但不增加工作量、即延期又增加工作量,并对比较结果进行分析。
计划时间
实际时间
批复工作量
实际工作量
结论
注:以最终一版开发计划中开发进度为准,批复工作量包含因为软件问题汇报增加工作量。
3. 项目评价
3.1 生产率评价
评价生产率能够有两种方法:代码行数和人月数比较,或修改BUG数和所用人月数比较。我们能够采取任何一个。假如采取第一个方法,应以模块为单位进行比较;假如采取第二种方法,应以各测试版本BUG数、修改BUG数、修改BUG所用工作量及修改单位BUG所用工作量进行比较,总结评价项目标开发效率及对应原因分析。
模块名称
代码行(千行)
工作量
代码行/工作量
模块1
模块2
等等
3.2 技术方法评价
总结该软件项目或软件产品开发时所采取各项技术。
3.3 产品质量评价
可参考以下多个方面进行产品质量评价。
1) 历次测试发觉BUG数;
2) 同种原因产生BUG数;
3) 同种类型BUG数
4) 各等级BUG数;
5) 同一BUG出现次数。
3.4 犯错原因分析
分别对以上多个情况绘制图表,进行原因分析。
次数
BUG数
原因
BUG数
类型
BUG数
等级
BUG数
BUG名
次数
4. 经验和教训
能够从以下几方面总结开发中取得经验及纠正错误或缺点等问题教训。
1) 管理人员管理水平;
2) 开发人员合理分工;
3) 项目软件经理PSM及开发人员技术水平;
4) 开发人员更换;
5) 开发人员配合及协作;
6) 用户亲密配合;
7) 需求及设计更改;
8) 开发过程中计划合理调整等等。
展开阅读全文