项目管理项目执行流程文档格式.docx
《项目管理项目执行流程文档格式.docx》由会员分享,可在线阅读,更多相关《项目管理项目执行流程文档格式.docx(37页珍藏版)》请在冰豆网上搜索。
3定期战略质询流程
3.1决策委员会同意签订合同后,项目部项目经理(在项目销售流程中的准项目经理)制订《项目计划书》,交由执委会审批,如果未通过,项目经理重新修改《项目计划书》;
3.2如果审批认可,项目经理将项目计划递交给客户评审,若未通过,项目
经理修改《项目计划书》
3.3若客户评审通过,进行项目资源安排,若所需资源在项目中心本身内,由项目总监完成资源安排,若所需资源跨项目中心外的多个部门,由执委会完成资源安排;
3.4获得所需资源后,项目经理进行需求分析,交质量控制部进行质量检验,若质检未通过,项目经理修改需求分析;
3.5若质检通过,专家委员会对需求分析内容进行评审,若未通过,项目经理修改需求分析内容;
3.6若通过内容评审,项目经理将需求分析交给客户评审,若未通过,项目经理修改需求分析,若通过,项目经理进行总体设计,同时将相关成果和文档放入资源中心存档;
3.7质量控制部对总体设计进行质量检验,若未通过,项目经理修改总体设计,若通过,专家委员会对总体设计内容进行评审,若未通过内容评审,项目经理修改总体设计内容,
3.8若通过内容评审,项目经理将总体设计交给客户评审,若未通过客户评审,项目经理修改总体设计,若通过客户评审,项目经理安排项目进行系统实现,同时相关成果和文档放入资源中心存档;
3.9质量控制部对系统实现结果进行功能测试,若未通过,项目经理安排项目组成员修改系统实现;
3.10若通过功能测试,质量控制部进行质量检验,若未通过,项目经理安排项目组成员修改系统实现;
3.11若通过质检,专家委员会对系统实现进行验收,若未通过,项目经理安排项目组成员修改系统实现;
3.12若通过专家委员会验收,项目经理将系统实现相关成果交给客户验收,若未通过,项目经理安排项目组成员修改系统实现;
3.13若通过客户验收,质量控制部将相关成果和文档放入资源中心存档,同时项目经理安排项目组成果进行项目推广;
3.14项目经理进行项目总结,通过在质量控制部进行质检,若未通过,项目经理修改项目总结;
3.15若通过质检,质量控制部将相关成果和文档放入资源中心存档;
4相关文件
4.1《项目计划书》
4.2《项目资源调度单》
4.3《方案说明书》
4.4《需求分析说明书》
4.5《质量控制需求分析说明书评审报告》
4.6《总体设计说明书》
4.7《详细设计说明书》
4.8系统实现相关文档一一在系统实现流程中完成
4.9《客户验收单》
4.10《项目总结》
4.11《软件质量保证文档》
4.12《资源中心验收单》
项目计划书
项目名称
项目编号
项目经理
项目任务描述
项目总时间及关键里程碑设置
项目人力资源
项目费用预计
审批人意见:
总监:
副总监:
执委会:
备注:
抄送财务部、人力资源部
时间
项目资源调度单
抄送财务、人力资源部
软件需求分析说明书
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假定和约束
给出影响软件需求说明书中陈述的需求的每一个因素。
这些因素不是软件的
设计约束,但是它们的改变可能影响到需求说明书中的需求。
这些假定和约束条件可能包括:
管理方针;
运行环境,包括硬件设备和支持软件的限制;
与其他应用间的接口;
并行操作;
实时功能;
审查功能;
控制功能;
所需的高级语言;
通信协议;
应用的临界点;
安全保密方面的考虑等。
本节中描述的因素是软件需求所依据的基石,当这些基石发生不可抗拒或控制的改变时对产品需求将造成影响。
本节的内容不能用来陈述具体需求或强加若干特殊的设计约束,而应对具体需求部分中的某些具体需求或设计约束的描述提供理由。
3.具体需求
本章应包括软件开发者在建立设计时需要的全部细节。
本章的编写应该遵循如下基本原则:
遵循可验证性、无歧义性等的准则,对每一个需求细节作具体描述;
在软件需求说明书前言、项目概述、附录部分的有关讨论中,要提供对
任何一个具体需求交叉引用的背景;
按符合逻辑的和可读的方式组织;
详细描述每一个需求,使得该需求应达到的目标能够用指定的方法进行客观的验证。
【提醒注意】每一项需求的描述都应包括至少5个方面的内容:
功能需求;
性能需求;
属性
需求;
外部接口需求;
设计约束。
3.1功能需求
用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。
对于每一类功能或者有时对于每一个功能,这部分通常由引言、输入、处理、输出四个部分组成:
3.1.1引言
(1)描述该功能要达到的目标、所采用的方法和技术;
(2)清楚说明功能意图的由来和背景。
3.1.2输入
(1)详细描述该功能的所有输入数据,如:
输入源、数量、度量单位、时间
设定、有效输入范围(包括精度和公差)。
(2)操作员具体的操作控制细节的需求。
其中有名字、操作员活动的描述、
控制台或操作员的位置。
例如:
当打印检查时,要求操作员进行格式调
整。
(3)指明引用的输入接口资料。
3.1.3处理
描述为获得预期输出结果,对输入数据及中间参数进行的全部操作。
它包括
如下的说明:
(1)输入数据的有效性检查手段;
(2)操作的顺序和处理过程,包括事件的时间设定;
(3)异常情况的响应,例如:
溢出、通信故障、错误处理等;
(4)受操作影响的参数;
(5)降级运行的要求;
(6)用于把系统输入变换成相应输出的任何方法(方程式、数学算法、逻辑
操作等)。
(7)输出数据的有效性检查手段。
3.1.4输出
(1)详细描述该功能所有输出数据,例如:
输出目的地、数量、度量单位、
时间关系、有效输出的范围(包括精度和公差)、非法值的处理、出错
信息;
(2)指明引用的输出接口资料。
【技巧】可以用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性
地叙述对软件所提出的功能要求。
【提醒注意】对着重于输入输出行为的系统来说,需求说明书应指定所有有意义的输入、输
出对及其序列。
当一个系统要求记忆它的状态时,需要这个序列,使得它可以根据本次输入
和以前的状态做出响应。
这种情况犹如有限状态机。
3.2性能需求
从整体来说,本节应具体说明软件、或人与软件交互的静态或动态数值需求。
静态数值需求可能包括:
支持的终端数,支持并行操作的用户数,处理的文
卷和记录数,
表和文卷的大小等。
动态数值需求可能包括:
欲处理的事务和任务的数量,以及在正常情况下和
峰值工作条件下一定时间周期中处理的数据总量等。
所有这些需求都必须用可以度量的术语来叙述。
95%勺事务必须在小
于1s时间内处理完,不然,操作员将不等待处理的完成。
精度
说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
时间特性要求
说明对于该软件的时间特性要求,如对响应时间、更新处理时间、数据的转
换和传送时间、解题时间等的要求。
灵活性说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变
化的适应能力,如:
操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限的变化、计划的变化或改进等。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3软件属性需求
在软件的需求之中有若干个属性,下面列举一部分。
【提醒注意】下列属性决不能理解为是一个标准的或完整的清单,而应根据项目实际情
况予以列举。
3.3.1
正确性
3.3.2
健壮性
3.3.3
安全保密性
这里指的是保护软件的要素,以防止各种非法的访问、使用、修改、破坏或者泄密。
这个领域的具体需求必须包括:
利用可靠的密码技术,掌握特定的记录或历史数据集,给不同的模块分配不同的功能,限定一个程序中某些区域的通信,计算临界值的检查等。
334易使用性
335可理解性
3.3.6可维护性
这里规定若干需求以确保软件是可维护的。
例如:
软件模块所需要的特殊的
耦合矩阵,为微型装置指定特殊的数据/程序分割