目前信息化工作的日常开展主要依托OA系统、ITSM系统、JIRA系统等进行,虽能在一定程度上满足日常办公及条线工作管理的需要，但是普遍存在管理流程割裂、数据信息不一致的情况，同时仍有大量工作的开展依托手工台账方式进行,信息技术相关管理制度、规范指引也无法得到系统的有效支持，对IT条线进一步释放生产力、提高工作效率造成了严重制约!为了填补信息化日常管理场景在信息系统支持方面的空白，打通IT条线相关管理场景和作业流程，迫切需要建设一个流程化、标准化、智能化的IT作业管理平台，以充分满足IT条线的工作需要。
由于项目开发产品的复杂、技术架构的多样、人力资源的储备等问题，在工作中往往不能达到合理协同。环节衔接依靠手工、任务资源分配不合理、关联任务依赖关系无法清晰展示、风险区不能及早识别、问题不能溯源定位、自动化程度低等,这些都严重阻碍了研发项目在开发产品过程中的工作效率和软件质量，同时引发了一系列过程控制风险问题。
因此需要一款简单易用、功能强大、项目组成员愿意使用的研发项目控制管理平台软件来满足研发项目产品开发的项目管理、产品开发需求。
2. 项目主要建设内容
实现项目启动-需求-设计—编码—测试-发布与变更的全生命周期项目管
理。
支持层次化的组织结构管理 组织结构、角色和人员配置 提供灵活的参数化设置 。
通过工作流引擎,可以方便灵活的自定义工作流程。
系统支持开放式设计,能够提供方便灵活的与外系统集成的能力,可以实
现与第三方系统的对接。 具备安全的资源信息保护体系 。
1
灵活全面的项目配置管理 、缺陷管理、需求管理功能. 方便灵活的二次开发能力。
实现项目的透明化管理，定制各类统计报表为项目管理者提供多维度的
数据展现，实时掌控项目进展与绩效。
实现项目全面信息的整合和闭环控制,包括项目进度、工时、工作量、质
量、资源、偏差分析、项目变更控制等。
对IT工作流程所涉及的各方面数据标准，包括IT预算、项目、需求、
运维等进行统一，建立IT工作信息的标准化数据基础；
将信息化相关的管理制度、规范通过系统管控的方式进行固化落实, 确
保IT工作实务流程和规章制度的一致性;
将IT工作流程及配套制度规范相关的风险管控点、信息安全管控点通过
系统方式进行固化落实，确保全方位、无死角的覆盖；
对IT工作的质量效能监督检查进行系统化支持，提高检查的效率、准确
性和针对性；
通过工作流程的打通、信息数据的共享，实现对信息化建设工作的多维
度、透视化管理，满足各层级管理需要。
3. 项目建设原则及目标
3.1. 项目建设原则
实现项目启动—需求—设计-编码-测试-发布与变更的全生命周期项目管
理。
支持层次化的组织结构管理 组织结构、角色和人员配置 提供灵活的参数化设置 。
通过工作流引擎，可以方便灵活的自定义工作流程。
系统支持开放式设计，能够提供方便灵活的与外系统集成的能力,可以实
现与第三方系统的对接。 具备安全的资源信息保护体系 .
灵活全面的项目配置管理 、缺陷管理、需求管理功能。
2
方便灵活的二次开发能力.
实现项目的透明化管理,定制各类统计报表为项目管理者提供多维度的
数据展现，实时掌控项目进展与绩效.
实现项目全面信息的整合和闭环控制，包括项目进度、工时、工作量、
质量、资源、偏差分析、项目变更控制等.
3.2. 建设目标
为提高IT项目管理水平,实现IT管理及相关日常管理工作的数据化、流程化、标准化和自动化管理，减少技术、管理人员工作负担，提高工作效率,特启动本系统采购与定制化工作,该系统将作为公司IT部工作平台，能够作为一个企业级多项目管控平台与信息共享平台，实现项目过程规范化、精细化管理，满足企业中长期发展要求.
该系统需要具备IT全过程管理能力,能够将部门管理、项目管理、质量管理、研发管理和个人工作融入到一个集成的工作平台，将知识和成果沉淀下来，将制度和管理体系固化下来，将技术管理人员的工作明确和展示出来，将各个业务、产品管理条线串接起来。系统要能减少多头管理负担，形成领导、产品条线、部门、项目和个人的综合管控视图，减少开发、测试等一线人员、质量人员、项目经理的事务性工作。系统还需要为部门、项目和个人的量化考核提供全方位数据和能力支持。
系统要支持项目在线管理，支持按阶段管理项目任务,实现对项目全生命周期管理。对工作任务、计划节点、工作总结、存在问题等内容的在线管理、图表展现和统计分析,支持公司领导、部门领导、PMO、质量负责人、项目负责人和项目组成员间的多层次信息沟通和资源共享,支撑项目过程管理节点、周工作、月总结、大事记等工作信息共享。能够跟踪全部项目关键节点进展情况，查看项目阶段成果、评审/审批意见和问题及处理情况，可减少各类报表，为各类项目IT流程提供引导,减少各类事务性工作，项目组能够随时查看和处置项目组内部交流情况和上级审批情况，可自动生成各类质量记录报表，支持人员在岗、加班、休假和请销假情况的登记、审批、查看、统计、分析和输出功能。
3
系统最终要集项目管理、开发管理、沟通协作、质量管理、部门管理、知识平台、绩效管理于一身，做到理念先进、功能完备、易学易用、稳定可靠、安全保密,成为公司IT管理工作的基础软设施.
本期DevOps运营体系建设项目是以数据和质量为核心，以电子化为手段。解决传统瀑布开发模式中各个环节相对割裂，从需求、研发、测试到生产运营整个周期相对较长，跨部门间的沟通效率低下，难以满足当前的业务需求。为突破瓶颈并改善现状，现以敏捷开发为出发点,按照DevOps的理念,进行合作外包管理系统落地、敏捷开发管理（含电子看板）建设、DevOps工具链建设。
建立合作外包管理平台，统一承载业务支撑网业务外包领域涉及到的各项能力，实现合作伙伴信息、合同信息、需求工单、工作量信息、考核结果等各个纬度信息的可追溯、可关联、可共享，并通过统一视图可从全视角纵览外包管理的整个生命周期.
建立需求敏捷开发流程管理系统（含电子看板），实现高效严谨的需求敏捷开发流程管理，解决研发过程中的责任不清、进度不明、信息不畅等诸多弊病。电子看板能满足开发团队进行细化需求管理、敏捷开发管理、Bug 追踪管理、代码共享与连接、版本发布管理、部署与运维管理、研发日报/周报、工作效率评估和追踪.从而实现研发流程管理到工作效率评估全流程管理.
建立DevOps敏捷工具链平台，在构建、部署、测试、交付等开发过程中,自动化一切值得自动化的过程。在建设开发、测试和发布自动化流水线过程中，通过流水线整合、改造一系列工具链，实现端到端整体能力的打通，实现交付能力的全面提升，保证软件产品的交付的质量和效率.最终保证快速实现业务需求,通过自动化流水线快速实现发布上线，保证业务可靠、高效运行。
4. 需求分析
(1) 工作流引擎
4
系统应提供可灵活定制、可视化编辑、可靠性高、可监控的强大的工作流引擎，能够对上述各管理域提供必要的、充分的流程支持。
具体应支持但不限于如下特性： • • • • • • • •
支持单一审核、多人顺序、多人并行、多人抢占四种办理方式； 支持条件流； 支持子流程;
支持多路并发与归并； 支持异步提交； 支持协办功能； 支持知会功能；
支持驳回、撤回、转办、催办、交办、撤转、加签、减签、会签、传阅等各种常用操作； • • • • • • • • • • • • •
支持催办功能、并可根据办理时限等条件设定自动催办； 支持待办人员按照预设规则、条件进行自动计算； 可以对表单、表单字段的访问权限进行精确设置； 支持进入、离开节点事件； 支持自动办理节点； 支持动态流程； 支持流程合并； 支持暂停、恢复功能; 支持手工强制结束流程； 支持替换节点办理人员； 支持办理节点跳转； 支持办理节点驳回；
支持流程实例与流程修改的更新同步.
(2) 表单引擎
5
系统应提供可灵活定制、可视化编辑、所见即所得、可靠性高的表单引擎。具体应支持但不限于如下特性:
•
支持各种常见表单控件，并可维护自定义控件，实现表单的即时配置、生成； •
能够将生成的表单数据与工作流引擎生成的工作流实例有机集成，并可根据表单要素设置各类条件、策略、规则、表达式等驱动工作流运转，实现流程各个环节业务的应用； •
能支持与用户和组织管理、权限管理等的有机整合，实现统一的配置维护管理能力.
(3) 智能搜索引擎
系统应提供基于权限的、支持全文检索方式的、高效率的智能搜索引擎，让用户可以在IT作业管理平台直接查询到有权限查看的所有数据，包括结构化数据以及各种非结构化文档数据。
注：如能引入大数据相关技术更佳。 (4) 数据交换引擎
系统内数据交换
主要指通过设定数据报送任务及模板，可组织进行批量格式数据的报送及汇总整理。 系统间数据交换
主要指支持IT作业管理平台通过数据平台和各周边系统进行批量数据交换。
(5) 作业调度引擎
6
对于IT作业管理平台需要进行的作业（如定时任务、跑批处理等）
进行统一调度管理，对于作业执行异常的情况，可以通过短信、邮件等方式及时提供告警。
(6) 接口管理引擎
对于IT作业管理平台提供的接口的状态进行管理及运行情况的记录
（包括但不限于被调用次数、调用成功情况、响应时长等),支持进行在线重启；
对于IT作业管理平台调用的其他系统的接口的状态进行管理，并可
记录调用次数、响应时长等；
对于接口状态异常的情况，可以通过短信、邮件等方式及时提供告
警。
(7) 工作台
工作台为提供用户使用的工作界面,支持工作台面板的个性化配置，
根据权限可设置相关功能模块.
1、 系统管理功能
IT作业管理平台应能提供丰富强大的系统管理功能,包括但不限于： 用户管理 角色管理
基于组织的、角色的、岗位的、业务关系等多种方式的权限管理(含菜单、
数据、功能、流程等） 工作流程管理 业务单据管理 基础数据管理 日志管理、审计 系统运行监控
7
查询、统计功能
2、 IT作业管理平台移动版本
在IT作业管理平台运转成熟后，着手搭建该平台的移动版本，可支持手机、PAD等智能终端设备使用方式.用户可通过移动版随时登录查看和处理各项任务。
移动终端门户应基于当前主流成熟技术建设(如 HTML5等),主要针对主流智能手机和PAD等终端设备（支持IOS和Android系统），视觉效果和使用效果要充分保证。
3、 系统间对接需求
对接系统名称 内网门户 说明 统一用户及组织机构 单点登录及待办信息推送 和移动门户对接,在移动门户上提供IT作业管理平台相关功能的操作界面 OA系统 IT立项审批单（项目信息) IT服务单-开发需求类(需求信息） IT服务单-运维服务类（运维请求信息） 合同审批单及合同台账库(合同信息） ITSM系统 事件信息 上线发布请求 服务请求 变更请求 邮件系统
发送提醒邮件 8
短信平台 发送提醒短信、密码找回等 5. 系统现状
目前信息化工作的日常开展主要依托OA系统、ITSM系统、JIRA系统等进行，虽能在一定程度上满足日常办公及条线工作管理的需要，但是普遍存在管理流程割裂、数据信息不一致的情况，同时仍有大量工作的开展依托手工台账方式进行，信息技术相关管理制度、规范指引也无法得到系统的有效支持，对IT条线进一步释放生产力、提高工作效率造成了严重制约!为了填补信息化日常管理场景在信息系统支持方面的空白，打通IT条线相关管理场景和作业流程，迫切需要建设一个流程化、标准化、智能化的IT作业管理平台，以充分满足IT条线的工作需要.
6. 项目系统建设方案
6.1. 系统定位与结构
作为一个流程化、标准化、智能化的IT作业管理平台，它的建设定位于“作业流程全贯通”、“数据标准全统一”、“制度规范全落地”、“风险管控全方位”、“质量效能监督全过程”等五个方面,通过IT作业管理平台的建设，希望达到如下目标：
对现有IT工作流程进行全面打通和整合，并结合财险公司发展新常态下
对信息化建设工作的新要求，对相关工作流程进行优化和再造； 对IT工作流程所涉及的各方面数据标准,包括IT预算、项目、需求、运
维等进行统一，建立IT工作信息的标准化数据基础；
将信息化相关的管理制度、规范通过系统管控的方式进行固化落实, 确
保IT工作实务流程和规章制度的一致性；
将IT工作流程及配套制度规范相关的风险管控点、信息安全管控点通过
系统方式进行固化落实,确保全方位、无死角的覆盖；
9
对IT工作的质量效能监督检查进行系统化支持，提高检查的效率、准确
性和针对性；
通过工作流程的打通、信息数据的共享,实现对信息化建设工作的多维
度、透视化管理，满足各层级管理需要。
6.2. 业务模型
IT作业管理平台主要包括IT作业管理平台整体框架实施、基础性功能(工作流引擎、表单引擎、数据交换引擎、作业调度引擎、接口管理引擎、工作台等)以及主要管理功能（规划计划管理、IT预算管理、项目管理、需求管理、架构管理、基础资源管理、组织机构管理、合作商管理、质量效能管理、开发管理、发布管理、运维管理、信息安全管理、风险管理），以及IT作业管理平台的移动版本。
6.3. 技术架构
核心功能是以项目管理为核心和主线,集成了项目计划、项目监控、需求管理、测试管理、交付物管理、资源管理、评审管理、外包商管理、合同管理、度量分析等完整的功能模块.并提供各种项目管理过程的统计报表。
完整的覆盖了CMMI二级和三级中的大部分的核心过程域。可以有效的协助CMMI的质量体系认证过程。提高CMMI的质量体系建设效率，是过程体系落地有效工具。
6.4. 数据架构
系统内数据交换
主要指通过设定数据报送任务及模板，可组织进行批量格式数据的报送及汇总理.
系统间数据交换
10
主要指支持IT作业管理平台通过数据平台和各周边系统进行批量数据交换.
6.5. 权限机制
维护单位（部门）的人员信息。功能包括增、删、改人员，人员顺序调整以及搜索，人员的角色授权和权限列表授权等功能
维护系统角色机及其权限设置。功能包括增、删、改角色及其角色授权和查看角色人员列表等功能
管理用户、角色的页面元素授权。功能包括页面元素人员授权、页面元素角色授权
6.6. 部署模式 6.7. 详细建设方案
6.7.1. 合作外包管理子系统
6.7.1.1. 合作伙伴管理
6.7.1.1.1. 台账统一管理
以资产设备管理为核心、集资产设备日常管理维护、辅助决策、报表自动统计等功能为一体采用先进的管理平台。满足企业审计、资产清查、国务院机关事务管理局、财政、国资委（或其他政府部门）提出的资产设备上报、统计要求.建立统一的台帐管理制度，台帐的内容至少包括所有不同类别合作伙伴的合同清单，清单中应包括合同金额、服务质量标准、服务条款、付款约定等关键信息，这些信息可通过与公司级合同管理系统进行功能整合或建立接口的方式获取，以实现在合作外包管理系统中的统一展示、统一管理、统一统计报表。
11
6.7.1.1.2. 台账定期审核
台帐信息要以年度为单位发送到部门领导进行审核,提供线上审核能力，部门各级领导和技术人员应经常查阅资料、记录、台帐的登录情况，对记录中反映的问题应及时 进行分析，并有明确答复。IT部门专工应每日审阅本专业的日志、报表和台帐，安培专工定期审阅班组安全活动及技术培训台帐 并签名，部门领导每月不定期检查各专工台帐。合同中是否包含了合作伙伴所提供的产品或服务内容、工作量需求、质量考核标准、结算付款约定、安全保密协议、知识产权约定等重点条款。可通过与公司级OA系统进行功能整合或建立接口的方式,将对上述条款的审核过程及审核结果记录并统一展示在合作外包管理系统中。 6.7.1.1.3. 人员管理
管理人员的扩展信息，包括查看和审核。人员扩展信息可以包括各类奖励、论文、著作等。设置个人信息。包括个人基本信息、密码、头像、补充信息、消息来源、其他设置等 6.7.1.1.4. 工时管理
系统支持领导或者项目经理对工时进行审核。公司审核的功能特点有: 可以支持一级审核，也可以支持二级审核机制。 可以单个工时审核，也可以批量进行审核。 审核不通过的工时，可以重新修正。
可以通过配置决定，是否审核不通过的工时纳入统计
工时审核界面如下图： 6.7.1.1.5. 考核管理
查看本项目相关的请销假和加班情况。可以按人、时间、类型查询过滤，输出汇
总报表。展示项目人员日报中填写的项目进展情况.可以按人员、时间过滤，并输出报表。从项目成员和参与部门维度查看挣值和报工数据。
12
6.7.1.1.6. 合作伙伴结算付款
考核评分结果体现在合作伙伴结算与付款中，可从合作伙伴台帐、合同台帐中直接调用查看财务报账单等相关结算付款依据，财务报账单中应体现考核结果.
6.7.1.2. 合同管理
6.7.1.2.1. 合同统一管理
管理合同、客户/供应商、合同标的物及合同付款信息，并对合同进展和财务进行监控.包括合同付款、标的物、检查点、款项、发票要求等信息，可以设置提醒时间。支持单个合同授权。监控合同进展以及合同财务。 6.7.1.2.2. 合同条款审核 合同的实体条款和程序条款 合同审核与一万小时定律
合同审核时,应树立以合同履行为中心的理念
区分通用条款和商业条款,有助于提高合同审核的效率和突出重点 6.7.1.2.3. 合同监控回顾
用于监控合同审核情况.可以查看合同、在某时间段内审批流程。能够查看部门人员在各个项目中的合同签订量. 6.7.1.2.4. 合同结束付款
核评分结果体现在合作伙伴结算与付款中，可从合作伙伴台帐、合同台帐中直接调用查看财务报账单等相关结算付款依据，财务报账单中应体现考核结果。
13
6.7.1.3. 需求管理
需求管理作为软件工程管理的业务基础,所以整个系统需要对需求有全面的支撑能力，能对需求做全生命周期的管理，能在组织范围内协作并管理需求和功能点,能够管理和需求相关的功能或技术设计文档。
需求管理过程中，应当支持工作流管理、审批管理功能，并支持自定义工作流及相应的模版. 6.7.1.3.1. 需求入口
项目或者产品的需求来源有很多： 来自于市场客户的需求 来自行业规范的需求
来自于公司内部业务部门提出的需求 项目优化或者问题解决带来的需求
对于上述几个需求来源,北京奥博思PowerProject可以通过创建新需求，批量导入Word或者Excel需求，进入到北京奥博思PowerProject的需求列表中。
这个列表列出需求的标题,每个需求的详细描述,优先级，期望完成时间等属性。业务负责人员可以根据实际需要进行编辑与管理。
需求列表如下图：
当需求的方案成型以后，需求负责人可以提交需求，进入受理阶段. 6.7.1.3.2. 工作量跟踪和考核
人员报工，包括工时填报、工时审核、工时统计.项目成员可以每天填写工作中的时间投入及工作内容。
14
6.7.1.3.3. 工作量评估
可以关联计划中的任务,可以关联需求,关联缺陷等。实现领导或者项目经理对工时进行多级审核.实现多维度的工时统计报表，包括从项目的维度也包括从部门和人的维度统计工时。 6.7.1.3.4. 开发需求管理
(1)、开发任务管理
支持对开发任务的全生命周期管理,暨从开发任务的启动至开发任
支持对开发任务的灵活分配、指派，可具体到处室、板块、人员、乙方团队
等；
支持对开发任务的拆分,以及开发任务间关联关系的建立;
对于每个开发任务,提供概览页面，包括任务详细信息、关联任务、详细进展、
最新活动、人力资源使用情况、风险等;
支持在开发任务流转过程中,对流程的灵活配置、修改、调度，且在流程变更
后，原有的流程可顺利完成；
支持对开发任务相关过程性文档的归集、整理； 对于开发任务的查找，支持灵活、自定义的查找方式； 提供对于开发任务的多维度统计功能.
（2)、开发资源管理
支持对开发团队及开发资源的管理；
对于每个开发团队，提供概览页面，包括团队人员组成、承担的任务信息、
工作量情况等; 6.7.1.3.5. 需求后评估
支持定期开展IT需求征集工作，在征集工作中可以创建IT需求; 系统支持IT需求拆分为子需求，子需求可以在信息部各处室流转，支持对
于子需求的评估（涉及系统、预计金额、预算类型等）；
15
系统支持汇总评估结果，并按照需求提出方、涉及信息技术部处室、涉及系
统、预算金额、预算类型等维度生成统计表。
6.7.2. 敏捷开发管理子系统
以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征.换言之,就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
6.7.2.1. 电子看板
Backlog和敏捷任务直观展现,目视化管理（VM，Visual Management)的一种表现形式，即对数据、情报等的状况一目了然地表现，主要是对于管理项目、特别是情报进行的透明化管理活动。它通过利用形象直观而又色彩适宜的各种视觉感知信息来组织现场生产活动，目视管理依据人类的生理特征,在生产现场充分利用信号灯、标识牌、符号颜色等方式来发出视觉信号，鲜明准确地刺激人的神经末梢,快速地传递信息，形象直观地将潜在的问题和浪费现象都显现出来。以便任何人都可以及时掌握管理现状和必要的情报，从而能够快速制定并实施应对措施
6.7.2.1.1. 新建需求工单
需求分析阶段,按照评估阶段拆分的子需求，分配给需求负责人进行需求分
析，分析完成后汇总分析结果由需求部门确认；支持上传需求成果物以及相关轨迹和要素，形成需求成果物的基线管理；
需求实施阶段,支持按照子需求创建开发任务，并按照开发管理功能对开发任
务进行管理,在需求、子需求层面体现开发任务数量及进度;
需求验收阶段，开发负责人填写验收环境，由需求负责人进行第一次验收，
并填写验收结果,需求负责人验收通过后，提交需求部门验收,需求部门验收通过后进入上线阶段；
16
需求上线阶段，支持按照开发任务安排上线工作，通过发布管理完成系统上
线,在需求、子需求层面体现上线进度； 6.7.2.1.2. 用户故事管理
用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则,如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。 6.7.2.1.3. 计划任务分配
敏捷开发也非常强调计划的重要性,但制定的过程却非常灵活。在敏捷开发迭代初期，开发人员会和客户一起按照需求的优先级和依赖关系制定一个2—6周的开发计划。这个计划的灵活性在于计划的构成不是按照任务数量来规定时间，而是根据时间来制定任务量,这就解决了需求变更导致的计划改变等问题. 确认工时 确定用户素材
估算用户素材所需时间 6.7.2.1.4. 需求池
需求管理模块包括统一需求入口、工作量评估、工作量跟踪和考核、工作量结算和付款、需求后评估构成。 6.7.2.1.5. 每日站会
在Scrum方法中,Scrum 会议非常重要，整个会议可能会比较混乱粗略，但推进度的目标却非常清晰明确,并促使团队齐心协力朝共同目标迈进。团队应召开每日 Scrum会议，以便确定下一天所需执行的工作，以最大可能地履行其承诺. 团队的每个成员都应该描述自上次会议以来所做的工作。他们计划在当天完成的工作，以及可能对其他团队成员产生影响或需要获得其他团队成员帮助的任何问题或障碍.Scrum主管严格控制会议结构，确保会议准时开始并在15分钟或
17
更短时间内结束。 SCRUM组严格遵守 timebox原则，每天的日站会准时开始，每次都严格的控制在十五分钟之内,会议的进展也严格围绕daily SCRUM的三个主题进行. 6.7.2.1.6. 故事验收 可获得反馈 能运行
可提交Alpha测试的 6.7.2.1.7. 迭代看板
在敏捷开发的实践当中，通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践。通过可视化的任务看板我们可以达到如下几个目的： 1. 可视化管理团队的目标；2. 明确目标的优先级；3。 明确目标分解后的任务项；4. 可视化管理任务的进展状况. 6.7.2.1.8. 迭代评审会看板
敏捷的任务看板通常每个迭代一个,看板的结构通常包括如下几个列: Story - 这一列代表的是用户故事，用户故事是敏捷开发中的需求表达方
式，每个用户故事代表了从产品的用户视角表达的一条用户需求。用户故事这一列放的是这个迭代需要完成的所有用户故事,这些故事加在一起就是这个迭代的目标。这些故事通常按照优先级从上到下排列。
Todo - 这一列代表的是待办任务项，用户故事会被分解为对应的技术任
务，这些待办的技术任务放到Todo列。 Doing - 进行中的任务,放正在进行的任务.
Done — 完成的任务，放已经完成的任务和用户故事。
在任务看板上除了有4个列之外，还要为每个用户故事建立一个泳道，通过
泳道来管理故事和任务的对应关系。
18
6.7.2.1.9. 质量分析看板
通过使用看板系统，我们可以将团队的在做任务限制在一个设定的能力阈值内，根据已完成任务的交付速率来平衡交给团队的工作需求。
看板提供了视觉化的直观管理感受，它能迅速暴露那些影响团队效能的问题，因此，在使用看板管理的团队所面临的挑战是：如何专注于解决问题以维持稳定的工作流。
看板很好的展示下游环节的当前状态，根据已完成工作确定前一环节可以投入多少资源,而不是前面环节使劲投入,不管后面环节是否能应对。
看板也为质量和过程中出现的问题供了可见性，使得缺陷、瓶颈、变异性以及经济成本等因素对工作流与交付速率的影响变得更明显。仅就使用看板来限制在做任务这一做法，就能促成更高的质量和更高的效能。
通过看板建立团队稳定的任务节奏,实现始终如一的可靠交付，这能够帮助团队与客户、依赖的相关部门、供应商、价值流下游合作伙伴建立信任关系。而信任关系对每一方都是非常重要的. 6.7.2.1.10. 迭代燃尽图
系统可自动根据敏捷任务构建燃尽图,用来观察项目过程中完成的实际工作量与剩余时间的关系。在项目完成之前，可视化显示需要完成的工作并预测当前进度能否按时完成。
日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。
6.7.2.2. 需求成果管理
支持成果物的基线管理和版本管理：
1)每个成果物支持独立的版本管理; 2）同一个文档支持版本间的差异比较；
19
3）同一类型的文档可以进行合并； 4）支持每个文档的编辑权限独立控制；
成果物的条目化、层次化管理:
1)支持成果物的导入导出，支持WORD文档导入后直接按照文档结构进行章节分层，支持在线编辑完成后直接导出为WORD格式;
2）支持成果物的图、文、表等形式的编辑； 3)支持条目的移动、复制、拖拽等操作； 4）支持查看条目的变动历史；
支持需求跟踪矩阵,建立需求、项目、系统、开发任务、测试用例、
缺陷等之间的跟踪关系；
支持需求变更管理，支持记录需求变更依据、将变更与条目进行关
联、支持查看变更记录、通过变更依据分析产生的影响及被变更影响的条目；
支持成果物的管理，如移动文档归属、对文档进行授权、跨项目的
文档复制等功能；
支持所有成果物的全文检索,支持自定义搜索模板； 需求变化自动通知;
支持需求条目设置内部流程，可以在各环节之间相互流转状态，支
持记录流转记录、支持查看流程图； 支持需求属性扩充，可自定义表单； 支持ECXEL模板下载及导入检查;
支持需求条目详细关联问题的跟踪及管理。
6.7.2.2.1. 创建列表
创建需求条目列表，并且根据需求改变可配置列表表头.
20
6.7.2.2.2. 创建迭代计划
在项目初期先挑选系统核心架构的需求来实现,待系统核心架构完成后，再在系统核心架构的基础上不断的添加其他功能模块，通过累加开发的方式，来不断的完善系统，并在完善系统时，对系统的瑕疵或不足,不断的进行重构和改进设计工作。通过多个迭代的敏捷开发，并且每个迭代都会产生一个可使用的产品。
每次只设计和实现这个产品的一部分， 逐步逐步完成的方法叫迭代开发， 每次设计和实现一个阶段叫做一个迭代。在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度（如3周)的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试.
6.7.2.3. 敏捷团队角色配置管理
管理必须在其所涉及的整个实践领域内不断地促进内容和环境的转换。由于内容和环境经常会变化，所以转换必须纳入例行的迭代中。为此，管理人员必须保证信息的共享和理解。
项目过程和结果的完全可预见性 总是有且只有一个客户 专注于指挥与控制 很少或者不涉及内容管理 只管理输入-输出
6.7.2.4. 质量分析流程管理
1）、检查计划管理
支持质量效能检查计划、检查任务的建立和维护，并对相应计划、
任务的执行情况进行跟踪监督； 支持对检查结果的整理及导出.
21
（2）、检查流程及检查点管理
支持检查流程及检查点的建立和维护，并设置相应的质量效能目标
及告警阈值。
(3)、检查问题记录及后续处理情况跟踪管理
支持从各工作环节中按照设定的规则，自动收集质量效能问题； 支持各工作环节主动报送质量效能事件；
支持对于质量效能问题的解决进展进行跟踪，并可根据需要触发告
警、提示或其他工作流程。
6.7.2.4.1. 下发质量分析待办 6.7.2.4.2. 记录生成
6.7.2.5. 测试流程管理
支持对测试用例的管理； 支持对测试计划的管理; 支持对测试资源的管理；
支持系统缺陷的跟踪管理，包括集成测试BUG和UAT阶段BUG的跟踪管
理。
6.7.2.5.1. 流程模板
测试计划管理的具体功能流程如下：
支持测试计划和测试轮次的测试生命周期管理 每个计划的每个轮次都可以创建或者导入测试用例 一个项目可以有多个测试计划
测试流程界面如下图:
22
6.7.2.5.2. 扫描结果反馈
支持集成已建开源性能测试工具，并且可以从集成的第三方或开源工具中获取测试报告，实时反馈，并支持测试用例测试结果汇总和各版本测试问题对比等分析功能。输出报告支持定制化输出检查报告展示。 6.7.2.5.3. 回退方案及测试通知
测试管理要实现对项目测试过程中相关文档、测试活动和阶段、缺陷以及测试结果的统一管理，能够形成并且建立完善的测试用例库，以此来指导测试过程。 1) 测试说明文档管理。系统支持创建和管理测试说明文档，其中，测试说明文
档由测试用例构成；支持测试说明文档的复制、合并、导入和导出功能，支持将测试说明导出到Word。测试用例可以关联需求和产品，方便进行需求覆盖分析。
2) 测试活动和阶段管理。支持测试活动和阶段的统一管理，测试活动由不同的
测试阶段构成，每一个测试阶段都可以关联一个测试说明文档。测试活动和阶段可以在不同的系统之间导入和导出.导入操作将更新关联文档的测试结果，使得测试结果能够及时更新。
3) 测试结果记录.可以对测试用例中的每一个步骤的测试结果进行记录,对整个
用例的测试结果进行总结,支持缺陷的记录，同时能够追踪缺陷对应的测试操作步骤和方法。记录的测试结果为进行测试统计分析提供真实有效的数据。 4) 测试任务分配与处理。测试阶段用例可以直接指派到个人，或者以任务的方
式指派到个人，个人登录后能够看到自己负责的测试用例,并能执行和记录测试结果。
5) 建立一个名为“测试用例库”的项目，将所有的测试用例汇集在该项目中.
其他项目可直接引用该项目中的用例（具体到某条用例的直接引用）。修改后的用例可以再次入用例库，并有版本管理和历史记录。
6) 测试用例的维护（添加、更新、删除等)仅在该项目中进行，可统一管理测试
用例.
23
7) 测试用例（包括测试用例中的所有信息）可以详细导入导出,采用Excel格式
或CSV格式。
8) 统计分析和报表输出。支持按阶段对测试活动进行统计,能够统计测试用例通
过比例和测试覆盖比率，统计测试过程中发现的缺陷数量，统计报表内容可以直接输出到Word。 9) 测试步骤带上所有步骤信息功 6.7.2.5.4. 缺陷汇总
缺陷管理是对测试过程中发现的缺陷进行管理,包括缺陷的建立，处理，转发，修复,验证，关闭等完整的缺陷处理流程。
缺陷管理的功能有:
支持对缺陷处理流程的自定义,完全由用户决定缺陷的处理过程 支持对缺陷提交表单的自定义,由用户提出表单需求进行定制实施 提供灵活的缺陷查询功能，可以保持查询条件
支持多维度的缺陷统计功能，提供统计图表（柱状图，饼状图等） 下图是缺陷列表界面： 下图是缺陷处理流程图： 下图是缺陷统计图:
6.7.3. 工具链管理子系统
支持流水线自定义，如新增开发提交流水线，定制化开发需要的流水线工具，提供定制化能力。
提供流水线模板，可快速根据实际环境进行对接接入。至少内置开发流水线、测试流水线和发布流水线。支持流水线执行过程的可视化,并可查看日志及扫描报告等，具备历史日志记录及审计报告能力和执行过程的可视化管理能力。
24
流水线执行过程可视化,包含各环节执行时间、执行错误日志输出等,操作结果直观呈现。
6.8. 系统割接方案
7. 下一期规划建设建议
1、需求方的高层质量目标这个是最重要的,多数情况下就是客户和直接发起领导的高层意图，比如速度快、界面美观、高质量等定性的指标,能够指示质量关注重点。2、公司运营管理的总体要求比如配合项目/产品需要多长时间完成、成本多少等等，这个通常是限制，要在这个大的限制下做好质控，不能说为了达到90％的测试覆盖率,而让项目成本超标，那就不是测试的本来目的了。3、设计、开发的要求要了解开发人员的工作习惯、使用的工具/平台/构架,有些事情是开发工具解决不了的问题,不要硬生生通过“文字\"反馈给开发人员,应该先有个沟通，在形成一定共识的基础上设计测试计划，对于设计或构架等难于解决的问题，也要有渠道反馈给管理层，以做风险应对，而不要针锋相对非逼着研发人员修改，最后可能会出现拖延、误修复等更严重的问题。4、测试的要求了解公司的质量管理要求、策略、制度、流程,更重要的是了解执行测试的人员的实际能力和经验。如果这份测试计划包括了定义的测试操作（也即是测试用例），那这部分是不能因人而异的,如果说测试计划是为了指导测试人员开发测试用例并指明测试工作安排的，则可以考虑根据执行人员的经验水平进行繁简处理调整，如果都是初级人员,则测试计划就要写得细一些；如果都是高级人员，则可以把测试计划的执行主体部分写的宽泛一些.5、实施的要求这里包括项目/产品的实施人员、运维人员、销售人员的意见,比如项目后期的运维方式、系统的版本控制、自动更新、授权许可机制等。这些虽然不是软件的主体目标，但是却与公司运营息息相关,所以也必须在测试策略中予以考虑。
25
8. 相关案例清单 9. 项目实施方案
9.1. 项目实施总体方案
建设管理软件采购是一项复杂、长期的系统工程，为保证工程能够顺利地进行实施，必须要制定科学、合理、切实可行的实施计划。一方面要从组织上进行落实，成立强有力的项目领导小组和经验丰富的项目实施队伍；另一方面要制定严格的时间进度表,明确各里程碑的时间。同时还要制定工作原则，以指导项目的全面实施。
1．用户方项目小组的成员，争取参与项目的全过程
用户方成立领导亲自挂帅的项目小组,在调研、设计、编码、安装调试、测试、培训、运行、验收、售后服务等项目的各个阶段,配合系统开发方的工作，一方面可以培训自己的技术维护队伍，为系统的使用保驾护航；另一方面，在开发过程中，协调用户方和开发方的关系，保证项目的顺利进行，及时发现问题,并对项目进度和质量进行监督。
2．采用“两手抓”的方针，一手抓开发、一手抓使用
对于软件项目，之所以称为一个工程，很大程度上是因为软件项目的建设,除了技术因素外，还有很多的非技术因素需要考虑，并且必须被得到重视.衡量一个软件项目是否成功，很大程度上不是看这个软件项目采用了多么先进的技术，而是软件对用户来说是否实用，是否能够帮助用户解决许多预期的问题。国内很多软件项目的失败，很大程度上是使用抓得不够。建议在项目的试运行过程中，在抓系统维护的同时，也要狠抓系统的使用，开发方和用户方齐心协力帮助业务人员从原来的手工处理转到计算机辅助处理上来，在业务人员适应计算机辅助业务处理的过程中，尽可能早发现系统中存在的问题，从而最大可能地使系统保质保量的按时完成。
3．数据同程序同等重要
26
该系统的建设，数据位于首要的地位,程序的编写完成，仅仅意味着系统完成了一半,数据的收集、整理、录入，对系统的建设来说同等重要。在项目实施过程中，一定要重视系统中数据的录入工作，充分估计数据处理的难度，在系统建设之初，就将数据工作提到议事日程上来，安排相应的资金、时间等，将数据工作落到实处，只有这样才能争取系统早日达到实用化。
9.2. 项目实施方法论
1、实施准备：该阶段达成目标包括:明确甲方（客户方）乙方（实施方)双方的项目经理人员，组建双方实施小组;双方项目组成员清楚和理解项目实施的目标和方法；双方项目组共同拟定一份项目实施主计划，规划出整个项目的实施进程；公司高层信息化建设知识和管理理念的培训;召开项目启用大会。双方确认成果有:项目组织/通讯录、项目实施主计划/资源需求计划、系统环境部署建议、工作任务书、项目章程、项目预算计划、质量保证计划、项目实施标准文档、阶段成果评估。该阶段里程碑：里程碑：召开项目启动会.
2、蓝图设计：该阶段达成目标包括：让客户了解软件系统的功能、管理思想以及应用流程（知己)；了解客户业务和需求，分清主次，合理不合理（知彼);进一步界定细节需求边界；在业务调研的基础上帮助企业发现并确定企业现存的主要问题，分析这些问题,并找出导致这些问题的原因，编制业务规划;产品需求匹配，确定需求差异，做特殊业务处理的二次开发准备；编写解决方案初稿。双方确认成果包括：业务解决方案初稿、个性化开发方案、系统编码方案、系统参数配置方案、接口方案.该阶段里程碑：需求分析报告确认和业务解决方案确认。
3、系统建设：该阶段达成目标包括：培训及知识转移；测试业务蓝图设计方案的可行性和有效性;准备将蓝图设计转换成公司实际操作流程,进行解决方案的优化与验收.双方确认成果有：测试计划/方案、培训总结报告、静态数据准备方案及表单、方案测试报告和解决方案终稿。该阶段里程碑：解决方案验收。
4、上线切换：该阶段达成目标:完成上线前的相关准备工作、保证动态数据的按质按量完成；系统正式上线;完成新旧的系统替换工作；新系统可以处理企
27
业的日常业务.双方确定成果：客户内部支持体系、系统权限配置方案、最终用户培训总结、用户标准操作手册、切换方案、系统切换报告、上线切换报告。该阶段里程碑：上线准备与切换总结。
5、上线及上线支持：该阶段达成目标包括：系统正式上线后的实施支持，保证客户可以正常应用系统进行日常业务处理；人员的有序撤离/更换,引入运维，保证服务的长期性；做好项目总结，完成项目的整体验收工作。双方确定成果有：日常维护策略、用户系统管理制度、系统运行问题记录单 、项目总结报告（质量报告）、系统验收报告、内部评审报告、项目交接记录单、项目维护合同。该阶段里程碑：项目验收。
9.3. 项目组织架构
需求分析阶段
首先需要经双方协调，形成《需求调研计划》及《需求调研大纲》,确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容,经双方同意后按此计划开始调研。调研正式开始前项目开发组应检查所有必要的准备工作已经圆满完成。
项目开发组根据调研中系统实际技术需求和各个子系统的业务需求，编写并向工程领导小组提交符合CMM LEVEL 3规范要求的《系统需求分析报告》，并由项目组评审，不合格的部分进一步完善调研；评审通过后由双方共同签署评审意见，并正式生效.
对于软件生产过程而言，需求阶段是整个过程中最重要的阶段，需求分析成果的好坏将直接导致项目的成功与否，因此合作双方在此阶段多投入是值得的。而且一旦评审通过并生效，则需求报告将成为系统的设计、开发、测试、实施试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其它因素的改变而变更,如需进行此种变更，需经双方项目负责人协商确定.
总体设计阶段
28
项目开发组通过对系统的功能、运行和性能要求加以分析，产生一个高层次的系统结构、软件结构、接口和数据格式的设计，并向工程领导小组提交《系统设计报告》（其中包括数据库设计）,组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划,评审通过后由双方共同签署评审意见，并正式生效，作为后续软件开发和测试的基础。
该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定，并需向工程领导小组汇报。
详细设计阶段
项目开发组在《系统设计报告》的基础上，对功能和性能要求进一步加以分析和细化并且把软件的详细设计文档化，向工程领导小组提交《系统详细设计报告》，并由项目组组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划,评审通过后由双方共同签署评审意见，并正式生效，作为后续软件开发和测试的基础。
该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定，并需向工程领导小组汇报
系统开发阶段
根据前面的设计结果，由双方的现场实施负责人、技术负责人讨论确定详细的开发计划，并向工程领导小组提交《项目开发计划》；工程领导小组对《项目开发计划》进行审查，由双方签字后正式生效，并将作为软件开发阶段的项目管理和监控依据,项目开发小组要严格据此计划控制项目进度,按时向工程领导小组汇报工作进展.
为了使用户能够及时获知项目的进展情况，开发小组需要每周向用户相关领导提交《项目客户周报》，用户项目组可以随时对项目的工作情况进行检查。
系统实施和试运行阶段
29
首先需要经双方交流协调，形成《项目实施计划》，确定现场实施的准备工作、人员和日程安排、培训计划、阶段目标等内容，经双方负责人签字后生效,按此计划开始现场实施。正式开始现场实施前项目开发组应检查所有必要的准备工作是否已经完成。
现场工作首先要进行软件在服务器端的安装和调试，包括数据库中各类对象的生成，初始化数据，原有系统的重要数据的转换导入，前后台软件的安装，配置参数调整等工作;完成后需向系统维护人员提交《数据库安装目录》，《软件安装方法》文件,并协助用户进行软件安装。
软件安装完成并确认可在系统正常运行后,开始相关业务人员的培训；在培训开始之前需要由双方协商形成《培训计划》，明确培训环境、条件及方式，参加人员，课程课时等详细内容，由双方现场实施负责人签字后生效，并分别开始着手准备，在既定时间内完成。
培训过程中由工程师提供《培训考勤记录》,培训应该脱产、集中、封闭进行，并要求所有参加人每日必须两次考勤；培训完成后由双方共同进行《培训总结》，针对培训效果确定是否达到目标，是否再增加培训课程；对以上内容用户项目组须进行必要的考核和奖惩，培训工程师有权对参加培训人员进行客观评价。
培训顺利完成后将开始软件在试点部门试用，将向用户提交编译后的前后台软件，《软件使用操作手册》，《软件功能清单》，这两种文档将详细描述软件的使用过程，软件所包含的全部系统功能模块。
软件试用期内用户的主要工作是根据《软件功能清单》所列的系统功能模块，检查公司所提交的软件是否满足《系统需求分析报告》、《系统设计报告》的规定，列出未完成及含有较严重、明显错误的模块清单形成《软件问题及修改记录》并提交给公司继续完善；此段时间可以对软件的细节性问题进行测试、验证，但主要精力还是应放在模块级功能的检查上,如果所有模块都已开发并可以进入试运行，其设计方法、技术可行性也都能够满足最终软件的需要,则用户各
30
相关业务负责人、现场实施负责人需要签署各子系统的《软件交付书》,表明软件已在现场安装、调试、培训完成，基本可以进入软件试运行;此后在软件功能模块一级上不应再发生大的变化，如需要修改功能模块设计，则需由双方项目负责人协商解决。
试运行期内用户负责组织针对《软件功能清单》所列的系统功能模块进行现场的系统测试，包括新旧两套系统并行工作一段时间进行验证,使每个功能模块都得到基本确认；对于其中发现的问题和软件的细节性修改意见，需以《软件问题及修改记录》的书面形式提交给公司;公司修改完成后立即提交到现场，用户负责组织立即对软件进行确认回归测试，如验证问题已修改需要在《软件问题及修改记录》中予以说明。通过试运行及修改后证明已经基本完成的模块，用户应组织相关的业务负责人在《软件功能清单》中逐项确认。
项目验收阶段
在试运行期内系统存在一定的细节性问题是工程项目不可避免的问题，特别是随着用户应用的逐渐深入，此类需求会逐级提出,此类问题不属于系统的致命性错误;因此当试运行期内所发现的真正的“问题和错误”收敛到一定数目以下时，各业务子系统经过一段时间的并行工作新系统已基本可靠，就可以切换到正式运行阶段,开始正式运行。
正式运行后，由用户提出验收要求，双方共同制定《项目验收计划》,组成项目验收小组，共同进行项目验收。此时公司将向用户提交验收的各类文档,包括对系统开发过程进行总结的《项目总结》，《项目技术报告》，最终的完整的《数据库字典》等。
验收工作将由用户组织的专家组对系统进行全面的验收和鉴定,并出具项目验收小组领导签字的《项目验收报告》,并签署验收意见,公司在此过程中将全程参与，在现场进行验收前的维护工作。
系统正式运行及维护阶段
31
公司承诺对系统软件提供服务保证期，在保证期内提供免费的软件升级和维护服务；在保证期外，公司继续为系统的维护提供技术支持，对于软件升级提供优惠服务.
维护期的具体工作方式请见售后服务承诺部分，所有维护工作，包括软件出现问题修改、细节性功能的增强，用户都要以《软件问题及修改记录》的书面形式提交给公司，修改完成后用户应组织相关的业务负责人进行确认，并在《软件功能清单》中说明;如遇紧急情况可事后补齐。
各阶段辅助文档
《现场工作日程安排计划》，在实施中的各阶段，对于所发生的需要在现场进行较长时间工作的情况,如果在《需求调研计划》、《项目开发计划》、《项目实施计划》、《培训计划》等工作计划中未包含,则需要在工作开始前双方共同制订好《现场工作日程安排计划》，并严格据此执行,需要双方现场实施负责人签字生效.
《现场工作周报》，在现场实施工作中,为了把阶段性的工作任务具体落实完成,需要合作双方每周一之前由公司实施工程师与用户组共同制定本周的工作计划,给出每个工作日上、下午的工作内容，以及双方的准备工作.计划制定完成后用户项目组向所有相关部门和领导发布，开始执行；实施中双方互相监督按照原计划开展工作；周五时双方负责人共同对本周计划执行情况进行总结，对原计划填写工作总结，详细描述各项计划的完成情况，未完成的部分应写明未完成原因和责任归属,必要时双方协商一起进行加班处理,力争按时完成；对于不能按时完成的必须调整到下周计划中进行.
《用户项目报告》,对于实施中各阶段较长时间不在用户现场进行的，或项目处于用户试运行、维护期的情况，为了使用户能够及时获知项目的进展情况和公司开发小组的工作情况,公司将在开发阶段每周向用户相关领导提交此报告，维护期内每月至少提交一次.
32
《阶段评估报告》，实施中当某一阶段性目标实现后，公司将对该阶段双方联合开发组的工作情况进行总结，编写该报告并向工程领导小组提交，及时总结经验教训，为下阶段工作打好基础。
实施过程提交文件汇总
以下是对上面的实施过程中将产生的文件汇总说明： 阶段 评审级别 名称 《需求调研计划》 作用 变更控制 确定需求调研的准备工作、内容、方法方双方现场实施负责人 需求调研 《需求调研大纲》 《系统需求分析报告》 《系统设计报设计 告》（其中包括数据库设计） 《系统详细设计报告》 软件开发 软件测试 《测试总结报
双方现场实施负责人 式及人员和日程安排 明确用户业务需求 描述整个系统软件的模块设计，详细设计,数据库设计，供开发编码使用 软件开发的日程进度,分工,检查点设置,提交成果等计划 符合ISO9000质量双方项目负责人 双方项目负责人 双方项目负责人 双方现场实施负责人 双方现场实施负责人 《项目开发计划》 《测试计划》 双方项目负责人 《测试问题卡》 保证体系规定的功能测试、同行间测试文档 33
告》 软件现场实施 《培训计划》 系统培训 《培训考勤记录》 培训记录，培训效果《培训总结》 总结，是否达到目标 《数据库安装目录》 系统安装 《软件安装方法》 《软件使用操作手册》 《软件功能清单》 所提交软件全部模块结构划分,功能描述 软件已在现场安装、 《软件交付书》 调试、培训完成，基本可以进入试运行证明 实施中发现的软件 《软件问题及修改记录》 问题和用户提出的具体修改意见，以及对其所作修改和确认记录 项目验
《项目实施计划》 确定现场实施准备双方现工作、人员和日程安排、场实施负责培训计划、阶段目标等 人 明确培训环境条件及方式，参加人员，课程课时等要求 双方现场实施负责人 双方项目负责人 双方现场实施负责人 现场安装、调试和提交软件的相关文档 用户系统人员 用户系统负责人 《验收计划》 开发过程项目总结，技术总结,数据库设计字34
收 《验收报告》 典等验收相关文档 《项目总结》 《项目技术报告》 《数据库字典》 日常工作 《现场工作日程安排计划》 需在现场进行较长时间的一般工作日程安排 较长时间不在用户双方现场实施负责人 双方现场实施负责人 《用户项目报告》 现场时向用户信息服务系统汇报项目进展和工作情况， 《现场工作周报》 双方现现场工作周计划 场实施负责人 某阶段性目标实现双方现场实施负责人 《阶段评估报告》 后进行总结，向工程领导小组提交,为下阶段打好基础 9.4. 项目计划
项目推进计划：
为了有效地保证系统开发的质量，整个系统建设的全过程划分为准备、设计、开发、实施和运行阶段，每个阶段完成相应的任务，确保信息系统的建设。
如下图所示：
35
9.5. 项目管理
9.5.1. 沟通管理
9.5.1.1. 小组工作管理 9.5.1.2. 汇报机制 9.5.1.3. 通知机制 9.5.1.4. 会议制度 9.5.1.5. 项目例会制度
9.5.2. 进度管理
9.5.2.1. 项目计划编制 9.5.2.2. 计划编制类型 9.5.2.3. 进度控制
9.5.3. 问题管理
9.5.3.1. 问题管理原则 9.5.3.2. 问题管理办法 9.5.3.3. 问题管理流程
9.5.4. 变更管理
9.5.4.1. 需求变更 9.5.4.2. 计划变更
10. 项目培训和知识转移10.1. 培训目标 10.2. 培训计划
36
因篇幅问题不能全部显示，请点此查看更多更全内容