管理数据服务项目执行流程程序文件doc.docx

上传人:b****4 文档编号:24471903 上传时间:2023-05-27 格式:DOCX 页数:23 大小:269.90KB
下载 相关 举报
管理数据服务项目执行流程程序文件doc.docx_第1页
第1页 / 共23页
管理数据服务项目执行流程程序文件doc.docx_第2页
第2页 / 共23页
管理数据服务项目执行流程程序文件doc.docx_第3页
第3页 / 共23页
管理数据服务项目执行流程程序文件doc.docx_第4页
第4页 / 共23页
管理数据服务项目执行流程程序文件doc.docx_第5页
第5页 / 共23页
点击查看更多>>
下载资源
资源描述

管理数据服务项目执行流程程序文件doc.docx

《管理数据服务项目执行流程程序文件doc.docx》由会员分享,可在线阅读,更多相关《管理数据服务项目执行流程程序文件doc.docx(23页珍藏版)》请在冰豆网上搜索。

管理数据服务项目执行流程程序文件doc.docx

管理数据服务项目执行流程程序文件doc

美文欣赏

1、走过春的田野,趟过夏的激流,来到秋天就是安静祥和的世界。

秋天,虽没有玫瑰的芳香,却有秋菊的淡雅,没有繁花似锦,却有硕果累累。

秋天,没有夏日的激情,却有浪漫的温情,没有春的奔放,却有收获的喜悦。

清风落叶舞秋韵,枝头硕果醉秋容。

秋天是甘美的酒,秋天是壮丽的诗,秋天是动人的歌。

2、人的一生就是一个储蓄的过程,在奋斗的时候储存了希望;在耕耘的时候储存了一粒种子;在旅行的时候储存了风景;在微笑的时候储存了快乐。

聪明的人善于储蓄,在漫长而短暂的人生旅途中,学会储蓄每一个闪光的瞬间,然后用它们酿成一杯美好的回忆,在四季的变幻与交替之间,散发浓香,珍藏一生!

3、春天来了,我要把心灵放回萦绕柔肠的远方。

让心灵长出北归大雁的翅膀,乘着吹动彩云的熏风,捧着湿润江南的霡霂,唱着荡漾晨舟的渔歌,沾着充盈夜窗的芬芳,回到久别的家乡。

我翻开解冻的泥土,挖出埋藏在这里的梦,让她沐浴灿烂的阳光,期待她慢慢长出枝蔓,结下向往已久的真爱的果实。

4、好好享受生活吧,每个人都是幸福的。

人生山一程,水一程,轻握一份懂得,将牵挂折叠,将幸福尽收,带着明媚,温暖前行,只要心是温润的,再遥远的路也会走的安然,回眸处,愿阳光时时明媚,愿生活处处晴好。

5、漂然月色,时光随风远逝,悄然又到雨季,花,依旧美;心,依旧静。

月的柔情,夜懂;心的清澈,雨懂;你的深情,我懂。

人生没有绝美,曾经习惯漂浮的你我,曾几何时,向往一种平实的安定,风雨共度,淡然在心,凡尘远路,彼此守护着心的旅程。

沧桑不是自然,而是经历;幸福不是状态,而是感受。

6、疏疏篱落,酒意消,惆怅多。

阑珊灯火,映照旧阁。

红粉朱唇,腔板欲与谁歌?

画脸粉色,凝眸着世间因果;未央歌舞,轮回着缘起缘落。

舞袖舒广青衣薄,何似院落寂寞。

风起,谁人轻叩我柴扉小门,执我之手,听我戏说?

7、经年,未染流殇漠漠清殇。

流年为祭。

琴瑟曲中倦红妆,霓裳舞中残娇靥。

冗长红尘中,一曲浅吟轻诵描绘半世薄凉寂寞,清殇如水。

寂寞琉璃,荒城繁心。

流逝的痕迹深深印骨。

如烟流年中,一抹曼妙娇羞舞尽半世清冷傲然,花祭唯美。

邂逅的情劫,淡淡刻心。

那些碎时光,用来祭奠流年,可好?

8、缘分不是擦肩而过,而是彼此拥抱。

你踮起脚尖,彼此的心就会贴得更近。

生活总不完美,总有辛酸的泪,总有失足的悔,总有幽深的怨,总有抱憾的恨。

生活亦很完美,总让我们泪中带笑,悔中顿悟,怨中藏喜,恨中生爱。

9、海浪在沙滩上一层一层地漫涌上来,又一层一层地徐徐退去。

我与你一起在海水中尽情的戏嬉,海浪翻滚,碧海蓝天,一同感受海的胸怀,一同去领略海的温情。

这无边的海,就如同我们俩无尽的爱,重重的将我们包裹。

10、寂寞的严冬里,到处是单调的枯黄色。

四处一片萧瑟,连往日明净的小河也失去了光彩,黯然无神地躲在冰面下恹恹欲睡。

有母女俩,在散发着丝丝暖意的阳光下,母亲在为女儿梳头。

她温和的把头发理顺。

又轻柔的一缕缕编织着麻花辫。

她脸上写满笑意,似乎满心的慈爱永远装不下,溢到嘴边。

流到眼角,纺织进长长的。

麻花辫。

阳光亲吻着长发,像散上了金粉,闪着飘忽的光辉。

女儿乖巧地依偎在母亲怀里,不停地说着什么,不时把母亲逗出会心的微笑,甜美的亲情融化了冬的寒冷,使萧索的冬景旋转出春天的美丽。

11、太阳终于伸出纤纤玉指,将青山的柔纱轻轻褪去。

青山那坚实的肌胸,挺拔的脊梁坦露在人们的面前,沉静而坚毅。

不时有云雾从它的怀中涌起,散开,成为最美丽的语言。

那阳光下显得凝重的松柏,那苍茫中显现出的点点殷红,那散落在群山峰顶神秘的吻痕,却又增添了青山另外的神秘。

12、原野里那郁郁葱葱的植物,叫我们丝毫感受不到秋天的萧索,勃勃生机与活力仍在田间高山涌动。

谷子的叶是墨绿的,长而大的谷穗沉甸甸地压弯了昨日挺拔的脊梁;高粱仍旧那么苗条,满头漂亮的红缨挥洒出秋的风韵;那纵横原野的林带,编织着深绿浅黄的锦绣,抒写出比之春夏更加丰富的生命色彩。

13、终于,心痛,心碎,心成灰。

终于选择,在月光下,被遗忘。

百转千回,早已物是人非;欲说还休,终于咫尺天涯;此去经年,你我终成陌路。

爱你,终是一朵花开至荼糜的悲伤,一只娥飞奔扑火的悲哀。

14、世界这么大,能遇见,不容易。

心若向阳,何惧忧伤。

人只要生活在这个世界上,就有很多烦恼,痛苦或是快乐,取决于你的内心。

人不是战胜痛苦的强者,便是屈服于痛苦的弱者。

再重的担子,笑着也是挑,哭着也是挑。

再不顺的生活,微笑着撑过去了,就是胜利。

15、孤独与喧嚣无关,摩肩接踵的人群,演绎着身外的花开花谢,没谁陪你挥别走远的流年。

孤独与忙碌迥异,滚滚红尘湮没了心境,可少了终点的奔波,人生终究一样的苍白。

当一个人成长以后,在他已经了解了世界不是由鲜花和掌声构成之后,还能坚持自己的梦想,多么可贵。

16、生活除却一份过往和爱情外,还是需要几多的遐思。

人生并不是单单的由过往和爱情符号所组成的,过往是人生对所有走过岁月的见证;因为简单,才深悟生命之轻,轻若飞花,轻似落霞,轻如雨丝;因为简单,才洞悉心灵之静,静若夜空,静似幽谷,静如小溪。

1目的及适用范围

1.1为规范数据服务业务中项目执行过程,达到项目的成本、进度、质量的统一,特制定本程序;

1.2本程序文件适用于侏罗纪公司数据服务项目提供;

1.3本程序文件由侏罗纪公司制定,其解释权及修改权属于;

1.4本程序文件从2003年月日起执行;

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如果通过客户评审,项目经理进行项目总结,并将相关成果和文档交由质量控制部检验,如未通过,项目经理负责对未通过部分进行修改;

3.10如果通过质量控制检验,项目经理将成果总结交给客户,同时相关成果和文档由质量控制部放入资源中心存档;

4相关文件

4.1《立项报告》

4.2《项目计划书》

4.3《质量控制项目计划评审记录》

4.4《项目资源调度单》

4.5《数据要求说明书》

4.6《质量控制数据要求说明书评审记录》

4.7《数据要求说明书客户检验单》

4.8《项目成果客户验收单》

4.9《项目总结》

4.10《综合评审记录》

4.11《资源中心验收单》

 

项目计划书

项目名称

项目编号

项目经理

项目任务描述

项目总时间及关键里程碑设置

项目人力资源

项目费用预计

审批人意见:

总监:

副总监:

执委会:

备注:

抄送财务部、人力资源部

时间

项目启动计划评审记录

记录编号:

时间:

年月日

项目编号:

项目名称:

项目启动计划编号:

开发部门:

PM:

评审地点:

参加评审人员:

评审内容(评审中审议通过的内容在“□”中划“√”否则划“×”):

1)项目的目的是否明确?

2)对项目的规模是否进行估算?

3)是否进行项目启动的预算?

4)阶段输出结果是否明确?

5)其它方面

评审意见:

评审结论:

 

填表:

审批:

1.项目启动计划评审由项目管理部门组织评审。

2.评审完成后由开发体系决策层SMG批准。

3.本页不足记述结果时,可以加入附页,附页格式自行设计,总页数包括本页与所有附页。

第页/共页

开发计划评审记录

记录编号:

时间:

年月日

项目编号:

项目名称:

项目计划编号:

开发部门:

PSM:

评审地点:

参加评审人员:

评审内容:

评审意见:

评审结论:

 

填表:

审批:

1.开发计划评审由项目管理部门组织评审。

2.评审完成后由开发体系决策层SMG批准。

3.本页不足记述结果时,可以加入附页,附页格式自行设计,总页数包括本页与所有附页。

第页/共页

开发计划检查表(开发计划评审附页)

软件问题报告

记录编号:

-时间:

年月日

项目编号:

项目名称:

软件项编号:

软件项名称:

版本号:

问题描述:

 

报告人签字/日期:

修改描述(主要是修改后与修改前的对比,如所用资源的变化、提交时间的变化、功能的变化等):

 

修改人签字/日期:

填写:

审批:

1.问题描述栏中可以填写问题现象及其产生原因,如果有用户的书面说明,则可以直接引用。

2.修改描述一栏描述问题的确切原因、修改办法以及修改后的效果。

3.本页不足记述时,可以有附页,格式自定。

总页数包括本页与所有附页。

项目资源调度单

项目名称

项目编号

项目经理

项目的跨中心(部门)资源调度缘由

申请人

审批人

正式调用时间:

起:

止:

备注:

抄送财务、人力资源部

时间

数据要求说明书

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)开发过程中计划的合理调整等等。

 

综合评审记录(公司)

评审对象(项目名称及编号)

评审项类(如合同、投标方案等)

评审人

时间

业务板块(产品中心、项目中心、服务中心、营销中心)评审意见

财务部评审意见

质量控制部评审意见

技术委员会评审意见

专家委员会评审意见

最终意见:

通过

修改

修改内容

时间

资源中心验收单(式样)一式三份

序号

编号

成果题名

完成日期

提交日期

页数

密级

保管期限

备注

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

第页/共页

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 求职职场 > 简历

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1