软件综合项目管理新规制度v.docx

软件项目管理制度V1.0

目 录
一、 概述 4
1.1 目标 4
1.2 应用范围 4
1.3 限制 4
1.4 本标准内容介绍 4
二、 软件项目管理措施 4
2.1 项目章程制订 5
2.2 项目计划管理 5
2.3 项目风险管理 7
2.4 项目变更管理 7
2.5 项目评审制度 8
2.6 项目会议制度 9
2.7 项目文档管理 9
2.8 项目源码管理 10
三、 软件项目阶段定义 11
3.1 需求分析 11
3.2 基础设计 12
3.3 具体设计 13
3.4 程序开发 14
3.5 系统测试 15
3.6 业务培训 16
3.7 系统运行 16
3.8 项目标完成及回顾 17
四、 软件项目开发步骤 19
4.1 项目策划和需求分析 19
4.2 项目调研和评审 19
4.3 基础设计和评审 19
4.4 具体设计和评审 19
4.5 系统开发 19
4.6 系统测试 19
4.7 项目审核和内部验收 19
4.8 项目实施 19
4.9 项目验收 19
五、 开发人员进度检验和绩效考评 20
4.1 考评标准 20
4.2 考评标准 20

一、 概述
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项目需求说明书》，其中“”为文档上交日期。
创建文档目录：在明确项目各个阶段所要编写文档和文档分类后，创建文档目录，列出全部文档名、所属类别、最终版本、责任人、评审人及文档完成情况，并创建具体文档超链接。
文档评审：依据文档编写规范和文档编写模板对搜集上来文档进行格式校对和内容评审，经过后统一公布。如没有经过校对，则退回修改，以新版本重新上交校对和评审。
文档版本管理：能够借助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地址表，以方便维护。
分配系统权限，对系统内功效按岗位、角色分配使用权限，能够由用户方自行分配权限。
准备运行数据，准备系统运行所必需初始数据，能够采取人工录入或导入方法注入系统内。
制订系统上线计划，对应复杂软件系统或实时性很强生产管理洗头膏需要制订具体上线运行计划，协调安排全部和系统上线相关原因，必需时能够做上线前模拟上线。
3.7.5 形成文档
《布署说明文档》：具体说明程序上线布署全部步骤、网络和系统环境需求、外部先决条件、配合人员。
《系统上线计划》：制订上线具体步骤，具体时间安排。
《系统运行汇报》：统计系统运行情况、故障情况和运行结论。
3.8 项目标完成及回顾
3.8.1 定义
项目依据协议要求验收后，以签署完工文件作为项目完成标志。项目完成后对项目标文档、资料、源程序等进行归档，同时总结项目经验、教训、结果等。
3.8.2 目标
确定项目完成，归档项目资料，总结项目结果。
3.8.3 责任人
项目经理。
3.8.4 任务
在系统稳定运行后，依据协议要求协调用户和项目相关管理方对系统进行验收（通常要求系统稳定运行三个月可进行验收），在验收时需提供《运行汇报》，《验收汇报》，《维护方案》。
对项目标文档、资料、源程序等进行归档，同时总结项目经验、教训、结果等，形成项目总结汇报。
3.8.5 形成文档
《运行汇报》：统计系统稳定运行情况。。
《验收汇报》：统计系统内功效依据协议技术附件内容完成情况和验收时需要移交文档签收情况。
《维护方案》：统计系统维护方法、值班及响应时间和参与维护人员姓名及联络方法。
《项目质量综合评价汇报》：统计归档项目标文档、资料、源程序，评定项目质量，总结项目经验、教训、结果等。

四、 软件项目开发步骤
4.1 项目策划和需求分析
内部项目《项目提议书》、外部项目《可行性汇报》。
4.2 项目调研和评审
企业内部招募项目组长或推选项目组长。
进行项目调研，并编写《调研分析汇报》。
各项目组长候选人评选或推选项目组长进行项目答辩，确定项目组长。
评审并确定调研分析汇报。
成立项目组，制订《项目章程》。
4.3 基础设计和评审
编写《基础设计》和《集成测试计划》
基础设计评审（关键评审业务步骤设计、功效设计、集成测试计划）
4.4 具体设计和评审
编写《具体设计》。
《具体设计》评审。
4.5 系统开发
编制项目开发分工和各模块工期表，即《项目开发进度表》
《项目开发进度表》评审
编写《单元测试用例》
4.6 系统测试
单元测试并编写《单元测试汇报》。
集成测试并编写《集成测试汇报》。
4.7 项目审核和内部验收
对项目各项指标进行综合评审并编写《项目质量综合评审表》。
依据评审结果确定是否达成内部验收标准。
4.8 项目实施
编写《操作手册》和《培训计划》，对甲方进行业务培训。
编写《布署说明文档》和《系统上线计划》，开始按计划实施。
4.9 项目验收
依据甲方要求编写项目验收相关文档，比如：《系统上线汇报》、《项目验收汇报》

4.10 软件项目开发步骤图

五、 开发人员进度检验和绩效考评
4.1 考评标准
软件开发人员绩效考评是全部软件企业全部深感棘手但又必需面正确问题。棘手原因是既不能进行计时处理、也不能进行计件处理。计时会造成出工不出力，计件（通常按代码条数）会挫伤优异软件人员主动性（一样实现一个功效，不一样层次软件人员实现过程差异很大，且质量不一样）。不过只要尊重部分必需标准，还是能够加以评定。这里提出六条标准：
1、 被考评对象必需有明确任务
项目经理或开发经理必需发出明确任务书：任务书中指定任务名称、任务内容、完成时限之、考评标准、向谁负责、任务难易程度（业务和技术两个方面）。难易程度由项目组组员集体评价。没有明确任务当然就无法考评。
2、 考评标准要综累计量量和非计量量
计量量如：完成时间、完成了多少功效、测试出多少缺点等，非计量量如：用户接收程度怎样、项目组合作情况怎样等等，要将这些原因综合考虑。
3、 要表现多劳多得、奖勤罚懒
高效、高质完成任务人员必需得到区分对待（调资、休假、奖金）。
4、 考评结果要立即和被考评对象沟通，许可争议协调。
5、 考评时间为项目正式验收后。
6、 被考评要提供周报月报之类内容，但不作为考评依据。我们只重视结果，也就是说依据结果认定过程。
4.2 考评标准
考评分为三方面：1.工作任务（占比70%），2.能力态度（占比30），3.遵守规章制度（减分项）
工作任务考评（70%）：
考评项
权重
说明
项目贡献
15%
所完成工作在项目中比重和技术难度。
工作完成立即性
20%
项目标关键里程碑（调研计划/方案输出，调研结论输出，设计完成，开发完成，上线完成）按时达成；承诺时间点达成。
工作质量
25%
开发中各个步骤工作质量,如需求调研,分析,设计,开发,单元测试,联调等任务，这些任务中完成是否高效高质,过程中是否极少出现错误及错误严重程度。
其它
10%
提出合理化提议并被采纳，发觉设计缺点避免质量事故

能力态度考评（30%）：
考评项
权重
说明
团体合作
10%
关注团体目标，和同事合作和沟通顺畅。合理分配工作时间，保持高效工作。分析本岗位工作和同事工作衔接点，将个人工作进度和相关同事分享；主动和她人配合，主动听取她人提议，对她人工作有提议时能立即指出。认同企业文化，含有良好沟通能力及职业规范操守，品德良好。
主动性和责任心
15%
愿意主动去负担更多工作，勇于面对更大挑战，含有创新意识和开拓精神，勇于负担责任。对领导安排工作或自己负责工作能够立即完成或立即推进。
其它
5%
态度端正，工作努力。

遵守规章制度考评：考评职员是否遵守企业和部门规章制度、步骤、规范，此考评项目是扣分项，对不遵守各项制度按企业要求进行对应减分。

工作任务和能力态度各单项评分标准：
ü 100+ 满足KPI要求（完成工作），不易超越，而且能影响她人
ü 100 满足KPI要求（完成工作），远超预期，或工作优异，能影响她人
ü 95 满足KPI要求（完成工作），有难度，而且超越预期要求
ü 90 满足KPI要求（完成工作），有一定难度
ü 80 满足KPI要求（完成工作），通常难度
ü 70 没有满足KPI要求（完成工作），通常难度，或，工作态度存在问题，影响团体
ü 60 严重影响工作进展，工作态度存在问题，影响团体
单项以5分为一阶，也就是最小打分单位为5分
各项得分需乘以其权重就是该项最终得分

测评总分计算公式：
总分 = 工作任务得分 + 能力态度得分 – 遵守规章制度考评得分