软件项目管理制度v11.docx
《软件项目管理制度v11.docx》由会员分享，可在线阅读，更多相关《软件项目管理制度v11.docx（20页珍藏版）》请在冰豆网上搜索。
软件项目管理制度v11
软件项目管理制度V1。
0
一、概述
1.1目的
本标准把软件项目的管理和开发分为多个过程,并为各个过程的实施提供参考方法和相关文档的定义及规范.
1.2应用范围
本标准适用于与所有软件开发类项目的管理。
1.3限制
本标准主要叙述软件项目的管理过程和开发过程，不包含项目的获取、供应、改进过程。
本标准虽然为软件项目的管理和开发的过程提供参考方法和相关文档的定义及规范，但不规定如何完成各过程中包含的活动和任务的细节。
1.4本标准内容简介
项目管理工作覆盖整个软件开发项目生命周期,“管理制度"就是落实到管理过程中的一些基本要素，这里将其分为两大部分：
软件项目管理过程部分
1、项目章程制定
2、项目计划管理
3、项目风险管理
4、项目变更管理
5、项目评审制度
6、项目会议制度
7、项目评审制度
8、项目文档管理
软件项目开发过程部分
1、需求分析
2、基本设计
3、详细设计
4、程序编制
5、系统测试
6、业务培训
7、系统运行
8、项目完成及回顾
二、软件项目管理办法
软件项目管理的过程决定项目的方向、质量和开发周期.
2.1项目章程制定
2.1.1定义
项目章程：
项目可以是已经确定的,也可以是有意向但还未确定的，由项目经理及系统分析人员（或设计人员）对项目相关方进行调查研究,包括项目实施对象的隶属关系、业务类型，项目业务结构组成，开发范围,项目提出方性质、希望达到目标、预计实施时间，项目具体负责人、联系人等，明确甲乙双方责任及义务。
2.1。
2目的
正式确认项目的启动，任命项目经理，赋予项目经理在项目活动中应用相关资源的权力,并为项目成员提供一个项目状况的概述对项目进行跟踪和全面调查研究,包括实施对象人员情况、业务情况、隶属关系、竞争对手等，为合同签订和下一步针对需求分析的调研工作做准备。
2.1。
3负责人
项目经理、系统分析人员（或设计人员）.
2。
1。
4任务
对项目相关方进行调查研究,包括实施对象人员情况、组织机构、业务组成、隶属关系、技术需求、竞争对手等。
对项目进行跟踪，实时了解实施对象与项目相关的动态.
对项目可行性进行分析。
估算项目所需人员的结构组成、实施时间及实施成本。
确定项目实施（设计、开发）具体人员.
明确项目相关方负责人、联系人等人员配置。
确定项目启动。
2。
1。
5形成文档
《项目章程》：
项目名称、项目提出、项目实施对象简述、项目实施人员安排、预计实施时间、系统结构组成概述等.
2.2项目计划管理
2.2.1定义
项目总体计划：
在项目周期内确定和组织全部生产经营活动的综合规划，包括项目整体工期规划，项目任务分解，项目阶段任务的确定，各阶段任务工期规划，各方面资源配置规划等。
总体规划侧重于以项目阶段任务为单位制定计划，指明要取得的各种结果，为合理地利用人力、物力和财力资源提供前提.
计划跟踪与监督：
是对计划执行情况和项目实施情况的反馈，校验计划与实际工作情况的偏差,并评估阶段工作的质量,为计划的修正和实际工作的调整提供前提。
计划调整：
当因自身或外界原因造成实际工作进度、工作质量与计划发生偏差并且影响到下阶段工作内容时，需要对整体计划、阶段计划或周计划进行评估和调整，并形成新版本的计划。
2。
2.2目的
对项目整体工期进行合理规划；
明确项目组成，将项目任务进行分解，确定项目阶段任务,并且落实项目人员的职责；
对各阶段任务的工期进行规划；
对项目人力、物力和财力资源等各方面资源配置进行规划；
在实际工作中制定短期计划,并对计划及实施情况进行跟踪，以达到实时校验工作进度和质量的偏差，并及时对计划进行调整，保证项目工期和质量；
2.2。
3负责人
项目总体计划：
项目经理;
项目周计划:
项目经理、模块设计人员;
计划跟踪与监督：
项目经理、模块设计人员；
计划调整：
项目经理。
2。
2。
4任务
记录项目日志，记录项目各关键时间点的事件内容作为项目跟踪的依据。
制定项目总体计划，依据对项目总体情况的调研和项目管理经验制定项目总体计划，对项目整体工期进行合理规划；
明确项目组成，确定项目阶段任务和各阶段任务的起止时间及所需天数,并且落实项目人员的职责.软件开发项目的阶段一般包括:
总体规划、业务调研、需求分析、基本设计、网络设计、设备采购、网络施工、机房装修、详细设计、程序编制、单体调试、系统集成、数据准备、业务培训、试运行、系统上线;
对项目计划的完成情况进行跟踪，可以利用项目管理软件或相应的记录文档，对计划的进度和完成质量进行校验,如有偏差，需分析原因并制定应对方案.
2.2.5形成文档
《项目日志》：
以天为单位记录项目关键事件、关键时间点。
《项目总体计划表》：
以表格的形式列出项目的阶段，标记出各阶段实施计划的起始日期，计算出所需天数（或周数）；
《项目开发进度表》：
可以利用项目管理软件（Project）或相应的记录文档,记录从项目启动开始，每个项目成员计划完成的工作内容。
《计划调整记录表》：
记录从项目启动开始，每次计划调整的原因、内容、涉及人、调整时间及调整后的方案等信息。
2.3项目风险管理
2。
3.1定义
项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程。
在项目启动之前要进行项目可行性分析，总体评估项目实施的风险;在项目启动后要注重项目风险的预测和应对方案的制定。
2.3。
2目的
项目风险管理是对包括项目的可行性、实施方案的设计、潜在的技术、成本和进度安排风险等方面的管理，以保证项目实施进度、项目质量和成本控制。
2。
3.3负责人
项目经理.
2。
3.4任务
项目可行性分析：
在项目启动之前要充分分析论证项目实施的可行性，包括项目实施成本需求、人力资源需求、技术力量需求、工期需求等方面,以及此项目对公司业务的市场占有率、未来发展的战略意义等方面，并提出项目可行与否的依据.
风险预测：
在项目确立后要对项目中可能存在的潜在风险进行预测,如设计方案的可行性,使用技术的成熟程度，项目组成人员的能力等。
风险应对：
对可预测的风险制定相应的预案;对项目进行过程中已经发生的问题制定相应的应对措施，以保证项目的顺利进行。
2.3。
5形成文档
《可行性分析报告》：
分析项目技术难度、实施成本、实施时间等因素，论证是否可行，并提出依据。
可行性分析应该在项目情况概述阶段完成.
《项目风险预测与应对预案》:
对项目中可能存在的风险进行预测，并制定相应的应对方案.
2.4项目变更管理
2.4.1定义
项目变更管理是指项目组织为适应项目运行过程中与项目相关的各种因素的变化,保证项目目标的实现而对项目计划进行相应的部分变更或全部变更，并按变更后的要求组织项目实施的过程。
项目变更主要的有以下几种：
项目范围变更、项目进度变更、项目合同变更、项目人力资源的变更、费用预算变更。
引起变更的因素：
一是来自外部的变更要求，如客户要求修改工作范围和需求等或因不可抗拒的自然因素而推迟项目实施进度等。
二是内部的变更要求,如为解决实施中发现的设计错误而修改设计或测试中发现的一些错误而修改源码甚至设计等。
项目变更控制：
是指建立一套正规的程序对项目的变更进行有效的控制，从而更好地实现项目的目标目的。
2.4。
2目的
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。
2.4。
3负责人
项目经理。
2.4.4任务
针对项目实际情况建立一套正规的变更程序，明确变更的具体流程、变更的提出方及责任、变更的审核方及责任和变更影响的评估方及责任。
对项目的变更需求进行审核,并由审核方签字落实审核结果。
对项目变更的影响进行评估，得出评估结论并由评估方签字落实评估结果。
在经过各方认可的情况下对项目的变更进行实施。
针对变更情况修改项目进度、调整项目人员等，必要时进行合同变更.
2。
4。
5形成文档
《项目变更流程》:
针对项目实际情况建立一套正规的变更流程。
《项目变更申请表》:
变更提出方在变更提出时需填写变更申请。
《项目变更审核表》：
项目变更需由项目的审核方（如甲方项目经理、项目管理方负责人、项目实施方项目经理等）进行审核，并记录审核结果.
《项目变更影响评估表》：
项目变更需由影响的评估方（如甲方项目经理、项目管理方负责人、项目实施方项目经理等）进行评估,并记录评估结果.
《项目变更记录表》:
项目变更通过审核和评估后，在客户、项目管理方和项目实施方均认可的情况下由项目实施方进行实施，记录下此次变更内容、结果及对项目的影响等。
2.5项目评审制度
2.6.1定义
针对项目各阶段形成的设计、文档、代码、进度表的质量进行综合评价.
2。
6。
2目的
确保项目的进度和质量在可控范围内。
2。
6。
3负责人
公司管理层和技术项目部评审负责人。
2。
6.4任务
确定开发周期制定是否合理.
确定各项系统设计是否科学、合理、准确。
审核项目文档是否符合公司或甲方要求的规范.
审核代码编写是否符合规范.
2。
4。
5形成文档
《项目审核表》：
记录评审项目、内容、结论、调整及修改建议。
2.6项目会议制度
2.6.1定义
针对项目制定的会议类型、开会时间、会议频次、与会人员等与会议相关的制度。
2。
6。
2目的
明确项目会议时间、频次、与会人员等规定，为项目沟通联系、项目问题讨论、项目进度把握提供平台。
2.6.3负责人
项目经理和项目管理人员。
2.6.4任务
确定项目会议类型,如项目例会、项目阶段评审会、项目临时讨论会等，及不同类型会议的与会人员要求。
例如项目确定有项目例会，要求项目经理和主要设计人员必须参加。
确定不同会议类型的频次和开会时间，例如项目例会定为每周五下午三点，有因特殊情况不开则另行通知.
2.4.5形成文档
《项目会议制度》：
记录与项目各类型会议相关的规定，可根据项目复杂度具体安排。
《会议记录》：
记录并保存会议的内容。
2.7项目文档管理
2。
7。
1定义
项目文档管理，是指在一个系统（软件）项目管理、开发进程中将提交的文档进行统一管理的过程。
细分文档的生命周期，一般包括:
创建、审批、发布、修改、分发、签收、追缴、归档、废止与恢复。
2.7.2目的
将项目相关文档统一收集、统一发布、分类管理、规范命名、规范格式、管理版本、归档保存。
2.7。
3负责人
项目管理人员.
2.7。
4任务
明确文档编写格式：
在项目文档编写前明确文档编写的统一标准格式，如文档的字体大小、段落行距、页眉页脚等，可以参照公司统一标准执行。
建立文档编写模板，规范文档结构.
文档分类：
定义软件项目各个阶段所要编写的文档，并将其分类,例如会议记录类，基本设计类。
规范文档命名：
规范各个阶段所要编写的文档的命名方式，例如《XXX项目需求说明书20120101》，其中“20120101”为文档上交日期。
创建文档目录：
在明确项目各个阶段所要编写的文档和文档分类后，创建文档目录，列出所有文档名、所属类别、最后版本、负责人、评审人及文档完成情况，并创建具体文档的超链接。
文档评审：
依据文档编写规范和文档编写模板对收集上来的文档进行格式校对和内容评审,通过后统一发布。
如没有通过校对,则退回修改,以新版本重新上交校对和评审。
文档版本管理：
可以借助VSS等版本控制软件管理文档版本，保存并区分文档各个版本，明确标记文档的最新版，以保证每次修改都是对最新版的修改.
文档归档保存：
对通过校对和评审的定稿文档标记为“评审版”或“完成版”,并归档保存。
2.7.5形成文档
《文档编写格式规范》：
不需要每个项目都重新制定文档编写格式规范，可以参照公司统一标准执行，但是项目文档编写前必须明确依据的标准。
《项目文档目录》：
可以在项目初期就明确项目每个阶段所要编写的文档,将其命名并编入文档目录统一管理文档版本和完成情况.
2.8项目源码管理
2.8.1定义
软件项目开发过程中对程序源代码、数据库表、索引、触发器、存储过程创建脚本、相关环境设置等进行定期备份和归档管理.
2.8.2目的
对程序源代码进行版本控制、备份和归档，保证程序的安全。
2.8.3负责人
项目经理和项目管理人员.
2。
8。
4任务
版本控制:
在开发过程中对程序源代码进行版本控制，常用的方式是使用SVN或VSS版本控制软件控制程序版本。
程序备份归档:
定期对程序源代码、数据库表、索引、触发器、存储过程创建脚本、相关环境设置等进行全备份并进行异地存储以保证程序安全，对已经完成的程序或脚本进行归档，统一保存。
建立程序源代码目录:
对所有程序，包括客户端程序、服务器端程序、数据内触发器、存储过程、函数等程序代码建立程序源代码目录，清晰管理源程序。
2。
8。
5形成文档
《程序源代码目录》：
包括程序名、编程语言（C#、VB、SQL等）、所属系统模块、编制人、最后修改日期、修改人等信息.
三、软件项目阶段定义
3.1需求分析
3.1.1定义
需求分析指的是在开发一个新的或改变一个现有的计算机软件系统时描述新系统的目的、范围、业务流程和功能时所要做的所有的工作.需求分析是软件开发项目中的一个关键过程.在这个过程中,系统分析员和软件设计师调研现行业务，确定用户的需要，分析和寻求系统的解决方案。
3.1.2目的
调研用户组织机构、业务特点、业务流程，确定用户的具体需求,分析并提出具体的解决方案，明确开发范围、具体功能、本系统与其它系统的关联关系、用户对系统的技术要求等,并进行详细描述。
需求分析是编写技术附件的基础,为合同的签订提供依据，也是系统设计、开发的基础和依据。
3.1.3负责人
项目经理、软件设计人员.
3.1.4任务
对用户的组织机构、业务特点、业务流程、具体需求进行调研；
明确项目背景:
包括项目的提出（如项目提出方、开发此项目的目的），系统隶属关系及其它关联，用户特点，约束（如费用、交付日期）等；
业务现状描述：
明确开发依据,确定开发业务范围和系统实现的主要目标。
对前期业务调研的结果进行汇总，具体体现为组织机构图、工艺流程图、现行业务流程图、业务功能层次图和现有帐票/报表一览表.
功能需求描述：
分析用户的需求和调研结果，对应业务功能层次图,详细描述系统将实现的业务功能。
明确技术需求:
包括用户对本系统在技术层面提出的需求和本系统对用户或其它相关联系统的技术需求，包括现有计算机系统及运行环境的约束、接口约束、精度要求、时间特性要求和灵活性要求等。
问题备忘：
记录本阶段未解决的问题或可能存在的问题预测.
对需求分析内容进行评审，并得到用户的签字认可。
3.1.5形成文档
《调研分析报告》：
包括组织机构图、工艺流程图、现行业务流程图、业务功能层次图、现有帐票/报表一览表、业务功能模块等.
3.2基本设计
3.2.1定义
基本设计也称为概要设计，是软件系统设计中将业务逻辑优化改造为系统内处理流程的重要过程，是系统最终功能层次的具体体现,并对每个功能的处理过程进行详细描述.
3.2.2目的
将软件系统需求转换为系统内的设计。
确定系统内的具体功能模块和模块内的具体功能层次.
将现行业务的处理流程进行优化改造，形成系统内的新处理流程，明确每个新处理流程所要求的输入信息和所产生的输出信息。
对系统内具体模块所包含的具体功能进行详细描述，明确每个功能的实现过程及其所产生的结果和主要数据信息,为数据库表结构设计提供基础.
3.2.3负责人
项目经理和设计人员.
3.2.4任务
确定系统的具体功能层次结构，绘制功能层次图。
将现行业务的处理流程进行优化改造，明确新处理流程所要求的输入信息和所产生的输出信息，明确功能模块之间的关联关系,对应功能层次图中的具体功能，绘制业务流程图。
对系统内每个模块所包含的具体功能进行详细描述，明确每个功能的实现过程及其产生的结果和主要数据信息，明确本系统与其它系统的接口关联关系、通讯方式和具体通讯内容，对应功能层次图中的具体功能进行业务功能描述。
对基本设计内容进行评审，并得到用户的签字认可。
3.2.5形成文档实用性原则
《概要设计报告》包括以下部分：
Ø《功能层次图》：
明确系统内功能层次结构,（格式见附录）。
Ø《业务流程图》：
展示优化改造后的业务流程，（格式见附录）。
Ø《业务功能描述》：
对业务功能和与接口系统的通讯方式、通讯内容进行详细描述。
Ø《系统编码规则表》：
说明支持系统运行所需引用或建立的编码,包括对象、长度、格式、规则等，例如日期、单据号等格式。
Ø《模块一览表》:
对应功能层次图，列出在详细设计阶段需要设计的所有程序/模块。
Ø《集成测试计划》：
列出测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的,例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等,给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境.培训、准备输入数据等）。
说明测试各环节的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法。
3.3详细设计
3.3.1定义
详细设计是指在软件设计过程中基本设计完成后，明确了系统内的具体功能层次和所有功能的具体处理方式的基础上，针对系统内功能的实现即程序编制所做的设计，在详细设计的过程中可同时进行程序的编制。
3.3.2目的
明确本系统与其它系统的接口关系、通讯方式和具体通讯内容，编写通讯设计文档和接口电文描述表。
明确系统内涉及所有的数据信息及数据之间的关联关系,进行数据库表结构设计.
结合《模块一览表》,对每一个程序进行画面设计和前后台程序规格说明书的编写，程序员将结合画面设计和程序规格说明书的内容编制程序.
详细设计是程序编制的基础和铺垫，所做的工作是为了更好的指导程序的编制.
3.3.3负责人
设计人员和程序员.
3.3.4任务
编写接口描述表，确定通讯工具、通讯方式、IP、端口号和双方电文具体数据项约定。
编写数据库表结构设计书，并创建数据库表、主键、索引、视图等，可以使用PowerDesigner数据库表设计工具.
编写画面设计书，依据统一的设计风格设计画面,明确画面内所显示窗口中数据的来源（表、视图）、检索条件、具体数据项名称、类型、精度限制、是否主键等和按钮等控件的命名和摆放位置。
编写程序规格说明书，具体描述每个程序模块，包括画面、函数、对象、后台进程程序等的具体命名、功能、处理逻辑、触发时序、输入输出限制和涉及数据库表等内容。
画面设计书和程序规格说明书是指导程序员编程的重要依据，其详细程度、准确程度和可读性将直接影响程序员对程序编制内容的理解。
3.3.5形成文档，依据实用性原则设计，具体格式件附录
《应用系统间接口内容定义表》:
定义系统内部外部接口，例如:
通讯用电文的ID、具体数据项名称、类型、精度、顺序及内容备注等信息。
《数据库设计》：
规划设计数据库用户、模式、表空间名称、大小等信息。
设计数据库表名称、所属模式、表空间及具体字段名称、类型、精度、主键、索引等内容。
《程序界面设计》:
依据统一设计风格设计程序画面,可以用Word画图工具展示界面布局，也可以用编程工具（如VB）布置窗体格局后抓图展示画面布局。
明确画面内所显示数据窗口中数据的来源（表、视图）、检索条件、具体数据项名称、类型、精度限制、是否主键等和按钮等控件的命名和摆放位置.
《数据流程设计》:
数据流是组织中信息运动的抽象，是信息逻辑系统模型的主要形式。
这个模型不涉及硬件、软件、数据结构与文件组织，它与对系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能,即所开发的系统在信息处理方面要做什么。
《算法设计》：
描述系统主要业务逻辑的算法,例如：
运输总量的计算公式、GPS定位算法等。
3.4程序开发
3.4.1定义
编制程序代码,实现相应的系统功能。
3.4.2目的
将设计的具体内容在系统内实现。
3.4.3负责人
设计人员和程序员.
3.4.4任务
设计人员制定程序编制进度计划和程序模板,指导程序员编程，并考核程序编制进度。
程序员依据画面设计书、程序规格说明书、程序模板和程序开发规范编写程序，并对程序进行单体测试，测试完成的程序交予程序设计人员。
3.4.5形成文档
《程序编制进度计划》：
对程序编制时间进行管理，掌控工作执行情况。
《单元测试用例》：
用来证明一个独立的单元是否实现了详细设计说明书中要求，详细列出每项测试中所使用的输入数据及选择这些输入数据的策略，说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。
3.5系统测试
3.5.1定义
指对一个完成了全部或部分功能的程序在正式使用前的检测,以确保该程序能按预定的方式正确地运行。
3.5.2目的
发现程序错误、缺陷和隐含陷阱。
3.5.3负责人
设计人员、程序员和测试人员。
3.5.4任务
制定测试计划,制定程序组合测试计划和结合业务功能的综合测试计划。
单元测试，在编程阶段,由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法.单元测试主要发现编程和详细设计中产生的错误，着重测试程序执行结果、模块接口、重要的执行通路、出错处理及边界条件等。
集成测试，在单体程序组合之后，由设计人员测试模块整体功能和模块间关联功能，着重测试数据流的通畅性、完整性，模块间的借口和通信问题及异常情况处理等。
依据软件需求说明书检查系统的功能、性能及其他特征是否与用户的需求一致；由业务人员依据基本设计中的业务流程设计测试系统功能表是否正确,数据结果是否完成等，并按照正式应用的操作方式测试系统功能。
3.5.5形成文档
《集成测试计划》：
由程序设计者制定并测试模块整体功能和模块间关联功能。
由业务人员或操作人员测试系统内部及与外部接口的功能。
《单元测试报告》：
程序员在开发程序过程中对每个编制完成的单体程序进行测试，并记录测试情况，编写测试报告.
《集成测试报告》:
由项目总体负责人记录集成测试的进度及结果。
3.6业务培训
3.6.1定义
软件开发项目中的业务培训是指对软件系统的用户关于软件系统的操作方式、操作流程等进行的培训.
3.6.2目的
使用户会使用软件系统的相应功能。
3.6.3负责人
设计人员和程序员。
3.6.4任务
设计人员或程序员在系统功能全部确定后编写操作手册和技术手册,在正式培训前递交用户负责人。
项目负责人根据用户实际情况确定培训方式，编制培训计划,可以采用集中培训的方式或随操作岗位按班培训的方式。
在每次培训后需要填写培训记录，记录每位用户的培训效果。
每个岗位的用户至少培训两次，重点岗位或操作较难的岗位可以增加培训次数,或提供实验环境熟练操作。
3.6.5形成文档
《操作手册》：
针对操作人员的描述系统功能操作方式、流程的文档。
《培训计划》：
根据用户实际情况确定培训方式,编制培训计划。
《培训记录》：
记录每位用户的培训效果，必要时附加评分。
3.7系统运行
3.7.1定义
经过综合测试的软件系统在进行过业务培训后，布置正式环境，布置客户端，分配系统内用户权限，准备运行数据，正式投入使用的过程.
3.7.2目的
使软件系统顺利投入使用。
3.7.3负责人
项目经理、设计人员。
3.7.4任务
布置正式环境，按照系统规划配置正式环境,将数据库、通讯中间件配置、开发环境下的前后台程序移植到正式环境并进行测试。
布置客户端,可以由我们提供需安装的客户端软件、编译后的可执行程序和客户端配置方法等，用户方自行布置客户端。
布置客户端的时候可以同时安装远程控制软件,核对客户端IP地址表,以方便维护。
分配系统权限，对系统内的功能按岗位、角色分配使用权限，可以由用户方自行分配权限。
准备运行
升级会员 