软件实施方案(三篇)_第1页
软件实施方案(三篇)_第2页
软件实施方案(三篇)_第3页
软件实施方案(三篇)_第4页
软件实施方案(三篇)_第5页
已阅读5页,还剩42页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件实施方案项目组织架构项目领导委员会负责对项目关键事项和重大问题进行议决,听取阶段性汇报,及对项目成果进行最终验收确认。职责:按照实施方案分工界面提供人员、设备、资金支持;审查确认项目实施总体计划,确认项目阶段目标的设置,并监督完成情况;参加项目会议,听取每周项目进展汇报;审阅周工作报告,监督项目进展;协调解决关键性、全局性问题;重大问题、解决方案的决策;总体验收。项目经理建议由一位资深人员共同担任项目总负责人职务,分别代表双方管理本项目、负责双方之间的联络,并且在这个合同的所有方面拥有代表本方的权力,并承担相关义务,并提供本工作说明书项下的服务他们将负责:定义项目管理流程、政策、和操作规程;管理项目进程、项目目标、和项目范围;规划项目总体进程;项目的全面沟通;向项目管理委员会报告项目总体状态。实施组实施组由实施顾问以及关键人员组成,他们将负责:针对硬件和网络环境条件制定项目实施方案的落实计划;根据系统方案进行系统操作层面的相关配置工作;完成具体的功能模块实施;解决最终用户在使用中遇到的问题。根据项目需要,安装及维护系统所需的系统环境、开发环境、网络环境等方面的工作负责系统的性能调优负责项目验收测试,并提交验收报告。实施方案的职责划分本项目需要甲乙双方应有明确的分工配合,建立很好的工作机制,才能保证项目成功。项目实施过程中本项目的成功依赖于双方的密切配合和通力合作。在项目实施过程中(包括需求分析、设计、系统安装、系统配置、开发、上线、培训等方面)项目的职责:在项目中所需第三方软件(指非标的物供应软件),将提供软件并提供此类软件的安装、配置和维护工作。在实施过程中负责项目管理、环境分析、安装调试及项目系统测试;进行关键用户培训与知识转移、方案设计。完成工作任务所必须的信息保证与项目有关的问题得到及时解决向最终用户说明新系统的功能、用途和业务规范设置用户权限协助制定并执行最终用户培训计划制定系统测试周期、测试脚本和所需测试业务并共同执行测试负责初期数据和基础数据的准备和整理工作建立项目环境和项目组织结构在保证实施质量的前提下,控制项目实施时间进度按时完成工程。上线后的运行维护阶段在本阶段,系统已经运行了一段时间,可能提出对系统的配置和一些新的要求。对于在项目实施过程中由于时间和资源限制没有全部完成的实施内容也在完善阶段进行补充。同时对用户的使用进行支持。此次项目中系统上线后的试运行定为两个月。职责:项目负责人应依据项目需求召开项目管理会议。保证系统上线后的稳定性安排支持人员,解决上线运用中最终用户出现的问题。系统维护人员,根据项目设计的流程维护上线后的投产环境,例如维护用户权限等,保证系统安全维护问题日志,关于软件问题应敦促软件提供商及时解决。施工准备为了持续有序地进行工程施工,必须认真做好技术准备、物资准备、施工现场准备、施工机具准备以及统筹安排施工力量和创造一切有利的施工条件,具体内容如下:技术准备1、组织工程技术人员深入学习图纸,就图纸中的问题和疑问与设计人员进行磋商讨论,做好细化设计。2、分解工程进度控制目标,编制施工计划;认真落实施工资源供应计划,严格控制进度目标。3、分解工程质量控制目标,建立健全施工质量体系;确定各个分项工程质量控制点,作好各分项工程的质量预控工作,并落实到人。4、编制施工预算,对材料、人工、机械设备的准备做到心中有数。5、编制各主要分项和关键工序的施工方案,进一步完善施工组织设计,并做好技术交底工作。新机房机柜分布图确认根据项目组对设备讨论的结果,设备在新机房机柜中的布置进行规划。新机房的机柜需根据上述规划,作出明确的标识,包括对每个机柜内设备和托板安装高度的标识。机房环境准备检查新机房环境是否符合运行要求,确认需要调整的项目,以便安排施工单位及时进行安装调整。UPS电源接地确认现场确认所有设备用插座都已妥善接地。电源保护地线的专用接地线电阻应小于1欧姆。测量零—地电压值应小于1V。功率及电压确认使用两路市电供电,总功率需完全满足系统消耗要求,储备功率充足。确认UPS单相和三相供电的条件,并根据需要计算新机房能耗指标。确认使用双电源切换系统的插座工作正常。机柜电源分配、PDU端口及类型确认PDU端口是否满足该机柜中的设备要求,PDU是否配备到每个机柜,每个机柜都具备双电源供应,电源容量设计合理,电流承载风险较小。但需要检查服务器设备放置规划,在各机柜中合理分配电源消耗,避免单个机柜消耗功率过大。根据每个机柜的安装设备规划,现场确认是否所有机柜上安装的PDU能提供足够的电源端口数量,尤其要将一些小的外围设备的电源端口需求考虑在内。特别注意小型机及存储安装位置所提供的电源条件,根据需要及早做调整。现场确认所有机柜上安装的PDU所提供的电源端口类型,对比目前设备可用的电源线类型,确认所需的额外电源线数量及是否需要提供特殊的插座类型。机房照明确认机房照明需满足机房典型照度及节能要求。地板确认新机房地板是否满足防静电、承重、冷气进风等的要求。特别确认小型机安装位置及运输路径的承重是否满足要求。空调工况确认确认空调系统工作状态,确保冷气循环达到能源效率所需。机房温度与湿度制冷温度及湿度达到机房运行标准并适当考虑节能要求。出风口压力确定冷气出口位置及压力,确认每个机柜的设备摆放位置合理,注意冷空气进风效率。热空气循环观察热空气循环走向,适当调整冷气出风口位置,注意热空气流动方向。机柜环境确认新机柜条件是否能与现有设备匹配,评估所需调整项目。机柜深度机柜深度是否满足机架及设备安装要求,注意机柜前门与机架前排安装孔的距离,尤其是针对一些前部接线的网络设备,以免前门无法关闭。机柜宽度机柜宽度是否满足机架及设备安装要求,尤其注意特殊规格的网络设备。机柜托板位置机柜托板是否满足设备安装位置要求。提早安排机柜供应商按所需高度安装到位。网络环境类布线测试确认检查综合布线测试报告,确认所有6类布线符合标准要求。类配线架检查使用6类线路测试设备,检查配线架与机架线路端口的联通性,对所有端口做网络联通性测试。光纤配线架检查利用光纤检验设备检查配线架与机架线路端口的联通性,对所有端口做网络联通性测试。机柜数据端口检查检查各机柜配线端口的联通性,验证各机柜端口数量与计划需求之间是否有差值。机柜标签查看机柜标签,确保机柜标签与设计一致。确认机柜安装位置的U标识与机柜布置图保持一致。交换机端口确认确认新机房交换机端口配置情况,根据网络设计方案,提前将各端口分配、连接到配线架,从而连接到各个机柜中去。需检验数据层的联通性。路由检查检查新机房的路由情况,确认与旧机房及各分支机构网络之间的路由处在正常状态。项目实施施工程序是整个项目建设成败的关键,在项目开展前制定出一个切实可行的方案,实现高质量的安全生产,才能向用户提供一个符合现在需求的质量优良的系统,更应为未来的维护和升级提供最大的便利、尽量节约资金。此系统工程实施是一个综合性很强的协调管理工作,其核心是行之有效的管理。我公司坚持“以人为本、共同发展”的企业理念,经过多年来实际工程的磨练,培养并且引进了一批成熟的技术设计人员和项目管理人员群。同时,不断探索工程实施的模式,组建整体作战的“联合舰队”,实现了将由本公司自己设计、自己工程安装的身体力行的工程模式转变为不断加强自身技术实力、质量保证体系和向外输出项目管理模式的头脑智慧型的模式,以控制项目成本、灵活整合组织的管理理念融合各个专业的项目施工队伍,在充分发挥双方资源的同时,大力开发社会资源优势,极大提高了承接大型项目的能力。项目组织管理在项目实施过程中,一方面需要与建设单位、各个专业施工单位进行协调,另一方面还要制定出最佳的工程进度计划,控制进度、监督质量、搞好安全生产。在不同工程阶段下资源的配置、组织与协调、质量安全生产是我公司在项目管理中的重点:1、人力、财力、物力资源的调配2、设计、施工、服务环节的进度监管3、设计、施工、服务环节的质量监管4、设计、施工、服务环节的安全监管5、对遵守法律法规的管理设备上架并加电将设备放置到机柜中,并用耳朵进行固定,然后进行加电,观察设备状态灯是否正常。设备上线将上线设备网络接口和网络交换机规划好的端口用普通的6类网线连接起来,同时进行标记,并绘制连接拓扑图。设备调试通过显示界面进行设备的开局调试,并将规划好的IP地址等信息配置好,实现网络通信,并启用各个功能模块,根据各个功能模块采集的数据进行汇总、分析。实施收尾经过测试及调试,各个系统工作正常,网络工作正常后清理实施现场,将安装的设备贴上相应的标签。项目实施管理过程总体计划对本项目我公司将采取与甲方紧密合作的方式,充分发挥合作双方各自优势完成整个项目的实施。根据项目实施的阶段和任务,邀请甲方的工作人员参与到项目管理和技术的每一项工作中来,联合成立相应的组织机构,进行有效的分工。双方共同负责对项目进行组织、实施和控制,并在项目实施的各里程碑到达时召开工程协调会,进行工程的总结、组织、协调工作。项目启动后,将由我公司项目计划控制小组定期召集工作会议,讨论各阶段任务的执行情况,分析存在的问题,提出改进方法,尤其注重讨论那些潜在的风险,提出相应的风险处理对策,并将会议结果及时通报给甲方,由甲方进行审核和确认,以确保项目按期高质量地完成。项目计划获取约定项目经理参与项目的准备工作,并且负责与售前项目的交接,获得项目的《工作说明书》,《工作说明书》是项目与客户及与公司的约定,项目经理还需要获得公司对项目的其他要求。这些信息是项目经理在项目启动阶段需要获取的基本信息,并作为编写项目计划的输入。编制项目计划确定项目概要:关于项目的编号、名称信息,本项目的工作说明书(SOW),项目建设目标、最终的可交付物,项目计划文档中使用的专业术语解释,制订项目计划过程中使用的参考资料。项目组织结构:项目组织结构描述了项目的人员与组织结构和项目人力资源分配的信息。项目估算:软件产品规模估算、成本估算、工作量估算、工作进度估算、关键资源的估算。制定风险管理计划:描述项目风险承受度的分析和项目组为有效管理风险所要采取的活动。确定项目里程碑和WBS:WBS是项目计划中重要的工作内容,通过对软件开发工作进行分解,并结合估算的进度要求,编写《项目WBS工作表》,表征每项工作任务完成的标志性事件即所谓“里程碑”。资源计划:分析项目的硬件设备需求、软件设备需求,以及工作环境、计划环境要求,并指定相应的责任人。交流沟通计划和培训计划。评审项目计划:项目经理将项目计划发给技术协调小组、甲方相关人员,并组织甲方确认工作,甲方确认工作采用管理评审的方式的进行,评审的内容主要针对人员组织、关键依赖、估算中的进度、里程碑、提交物和详细的WBS表、风险管理表等内容。根据评审结果对项目计划进行修订,修订后的项目计划要得到甲方项目负责人的确认。发布计划:项目经理将通过评审后的项目计划申请基线化,并通过邮件或会议的方式通知所有项目涉及人员。项目跟踪任务跟踪:明确项目中任务下达与跟踪的形式,包括了对任务计划、任务安排、任务跟踪这些活动的要求、相应的责任人及输出产物。事务跟踪:明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方法或工具、及相应的责任人,如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪等。甲方反馈:确定项目中对甲方反馈、建议、甚至抱怨的应对责任人(比如项目经理或设立专职的客户经理)和纪录跟踪的方式。状态报告:确定项目组需要向相关人或组织提交报告的信息,包括报告的对象、频度、报告文件名称。如:甲方、我公司的资深管理层的相应报告。项目跟踪和监督需要有下列具体的子活动:每周例会,必要时邀请甲方参加提交和通报QA周报告、配置状态报告、开发小组工作报告、测试小组工作报告和其他。总结项目的实际进展数据,并在项目周报中体现,主要数据包括项目的当前的工作绩效(产品的完成情况)、进度情况、缺陷总结、需求稳定度分析和变更发生情况。总结项目组存在的问题和分析项目进展的风险对重要问题的日常跟踪回顾在必要时出《项目偏差控制报告》。《项目偏差控制报告》是对估算出现偏差的一个总结报告。并决定是否需要修改项目计划。出会议纪要和项目工作周报。在必要时出项目工作月报。日常监督和跟踪工作、风险管理工作对项目周报中的项目问题进行跟踪对项目周报中的项目风险问题进行跟踪对项目周报中其他事项进行跟踪软件开发软件开发通常需要经过分析、设计、实现和运行维护等几个阶段;为了用工程化方式来有效的管理软件项目的全过程,软件项目生命周期也可以分成几个阶段。对软件项目生命周期的不同划分,形成不同的软件项目工程模型。目前在本软件开发实践中使用的标准软件项目生命周期,是以下几个阶段的不同排列组合。项目启动——需求分析——项目设计——核心开发——定制开发——产品发布——产品交付——初验——终验——维护。以下分别介绍我们开发中三类典型项目的组织标准软件项目生命周期。组织标准软件项目生命周期-----研发项目首先,在这里对软件项目生命周期中通用的公共活动进行必要描述:序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周报、不符合报告3软件配置管理配置审计报告、配置状态报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1实施项目可行性研究项目可行性报告2召开项目启动会议3制定项目计划项目计划书、项目软件配置管理计划书、项目软件质量保证计划书4同行评审活动评审报告、缺陷管理表需求分析序号关键活动工作产物/输出1编写需求规格书、需求跟踪矩阵需求规格书、需求跟踪矩阵2细化项目计划项目计划书、项目软件配置管理计划书、项目软件质量保证计划书3制定项目测试计划(包括方案)测试计划4同行评审活动评审报告、缺陷管理表项目设计序号关键活动工作产物/输出1概要设计概要设计规格书2详细设计详细设计书3细化项目测试计划(包括方案)测试计划4同行评审活动评审报告、缺陷管理表核心开发阶段序号关键活动工作产物/输出1编写代码代码2进行单元测试单元测试报告3持续集成测试测试状况报告4进行系统测试系统测试报告5文档编写用户手册、操作手册6同行评审活动评审报告、缺陷管理表产品发布序号关键活动工作产物/输出1发布版本版本发布报告2项目总结项目总结报告组织标准软件项目生命周期-----工程项目首先,在这里对软件项目生命周期中通用的公共活动进行必要描述:序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周报、不符合报告3软件配置管理配置审计报告、配置状态报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1召开项目启动会议2制定项目计划项目计划书、项目软件配置管理计划书、项目软件质量保证计划书3同行评审活动评审报告、缺陷管理表需求分析序号关键活动工作产物/输出1编写需求规格书、需求跟踪矩阵需求规格书、需求跟踪矩阵2细化项目计划项目计划书、项目软件配置管理计划书、项目软件质量保证计划书3制定项目测试计划(包括方案)测试计划4同行评审活动评审报告、缺陷管理表项目设计序号关键活动工作产物/输出1概要设计概要设计规格书2详细设计详细设计书3细化项目测试计划(包括方案)测试计划4同行评审活动评审报告、缺陷管理表核心开发阶段序号关键活动工作产物/输出1编写代码代码2进行单元测试单元测试报告3持续集成测试测试状况报告4进行系统测试系统测试报告5文档编写用户手册、操作手册6同行评审活动评审报告、缺陷管理表定制开发阶段序号关键活动工作产物/输出1编写代码代码2进行单元测试单元测试报告3持续集成测试测试状况报告4编制用户测试计划用户测试计划5进行系统测试系统测试报告6进行用户测试用户测试报告7文档编写用户手册、操作手册8同行评审活动评审报告、缺陷管理表产品发布/软件交付阶段序号关键活动工作产物/输出1发布版本版本发布报告2编制上线方案上线方案3系统上线上线总结报告软件维护阶段序号关键活动工作产物/输出1确认维护需求(包括BUG)需求变更申请单/Bug单2维护设计、开发设计书3内部测试修改测试单4用户测试用户测试报告5维护需求上线上线申请与批准报告6同行评审活动评审报告、缺陷管理表初验序号关键活动工作产物/输出1编制试运行报告试运行报告2用户验收测试用户验收报告3初验初验报告终验序号关键活动工作产物/输出1编制技术总结报告技术总结报告2编制项目总结报告项目总结报告3用户验收测试用户测试报告4终验终验报告组织标准软件项目生命周期-----维护项目首先,在这里对软件项目生命周期中通用的公共活动进行必要描述:序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周报、不符合报告3软件配置管理配置审计报告、配置状态报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1召开维护交接会议2制定维护项目计划维护项目计划3同行评审活动评审报告、缺陷管理表项目实施序号关键活动工作产物/输出1确认维护需求(包括BUG)需求变更申请单/Bug单2维护设计、开发设计书3内部测试修改测试单4用户测试用户测试报告5维护需求上线上线申请与批准报告6同行评审活动评审报告、缺陷管理表项目结束序号关键活动工作产物/输出1提交维护总结报告维护总结报告项目执行与控制任务跟踪:明确项目中任务下达与跟踪的形式,包括了对任务计划、任务安排、任务跟踪这些活动的要求、相应的责任人及输出产物。事务跟踪:明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方法或工具及相应的责任人,如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪等。甲方反馈:确定项目中对甲方反馈、建议、甚至抱怨的应对责任人(比如项目经理或设立专职的客户经理)和纪录跟踪的方式。状态报告:确定项目组需要向相关人或组织提交报告的信息,包括报告的对象、频度、报告文件名称。如:向甲方、资深管理层的相应报告。项目跟踪和监督需要有下列具体的子活动:每周例会,必要时邀请客户参加提交和通报QA周报告、配置状态报告、开发小组工作报告、测试小组工作报告和其他。总结项目的实际进展数据,并在项目周报中体现,主要数据包括项目的当前的工作绩效(产品的完成情况)、进度情况、缺陷总结、需求稳定度分析和变更发生情况。总结项目组存在的问题和分析项目进展的风险对重要问题的日常跟踪回顾在必要时出《项目偏差控制报告》。《项目偏差控制报告》是对估算出现偏差的一个总结报告。并决定是否需要修改项目计划。出会议纪要和项目工作周报。在必要时出项目工作月报。日常监督和跟踪工作、风险管理工作对项目周报中的项目问题进行跟踪对项目周报中的项目风险问题进行跟踪对项目周报中其他事项进行跟踪修改项目计划(包括子计划):当项目计划出现偏差时,需要对项目计划进行及时的调整。引起项目计划变更存在多种可能的因数,如原来的进度估计不准确、发生了没有估计到的问题、项目执行过程中的各种变更等等。项目计划应该定期的被检查,发现可能影响项目计划的变更因数,对这些因素进行分析,并在项目例会中确定是否要对项目计划进行调整。修改项目计划之前,必须首先编写《项目偏差控制报告》,该报告是修改项目计划的直接依据。在项目计划的修改前、修改后,需要通过《项目计划变更控制报告》,要求公司的管理层和甲方的管理层签字确认。在修改后的项目计划中,必须体现所有受项目计划变更的影响,并做对应的修改。项目计划修改后在必要时必须通过评审。项目计划变更后,需要通知与项目组相关的人员或组织。项目计划变更的工作流程示意图如下。通过项目计划的变更流程,实施对项目计划文档的控制和管理。项目验收与结束系统投入使用验收验收过程系统投入使用验收申请系统投入使用验收计划系统设备验收文档审查、环境检查制定投入使用测试大纲和测试方案投入使用测试制定系统割接计划和割接方案系统上线或割接验收标准系统基本功能已经开发完成,能够满足业务的基本要求,系统功能的进一步开发对已开发完成功能的使用不会造成影响时。验收成果《上线报告》系统初验验收过程系统稳定验证系统初验评审系统初验表决系统移交验收标准系统开发建设完成,满足业务要求后进行的验收。初验完成后,允许系统存在少量遗留问题。时限要求上线后3个月内。验收成果《初验报告》系统终验验收过程系统终验评审系统终验表决系统最终移交验收标准统完全符合合同要求,经过试运行,系统调整优化到满足目前各业务要求,且基本满足系统性能要求后进行的验收。时限要求初验后3个月内。验收成果《终验报告》项目结束按照合同约定免费维护期结束后项目结束。项目文档资料《技术建议方案》《需求规格书》《概要设计规格书》《详细设计规格书》《系统测试计划》《集成测试报告》《系统测试报告》《用户测试报告》《上线申请报告》《试运行报告》《用户维护手册》《用户使用手册》《数据字典》《技术总结报告》《系统初验报告》《系统终验报告》软件配置管理软件配置管理是项目运作的一个支撑平台,它将项目所有成员(包括公司中对项目负责的高层经理)的工作协同起来,实现高效的团队沟通,使工作成果及时共享。当然,这种支撑是贯穿项目的整个生命周期的。配置管理计划在实现软件配置管理计划的过程中,主要实现以下三个里程碑:A.建立软件配置管理小组:在项目总体组批准软件配置管理计划之后,立即成立软件配置管理小组;B.建立各阶段的配置基线:随着系统及其所属各子系统的任务书的评审和批准,建立起功能基线;随着总体组编写的《软件需求规格说明书》的批准,建立起指派基线;随着工程化软件系统的集成与系统测试的完成,建立起产品基线。C.建立软件库:在本项目所属的各个子系统的研制工作的开始,就建立起各个子系统的软件开发库,并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束,建立各个子系统的新的开发库,同时把这个阶段的阶段产品送入总的软件受控库,并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束,在配置管理小组的计算机上建立起软件产品库,并在各子系统的计算机上建立软件产品库的副本。基线库管理基线是项目每个配置项版本在特定时期的一个“快照”。它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。配置项基线化前核心思想:开发人员在每天下班之前将当天工作成果提交到开发库开发区。原则:允许多人对一个文件进行CHECKOUT操作。每天开始开发工作之前,所有开发人员访问开发库开发区将要修改的文件进行CHECKOUT操作。每天下班之前,所有开发人员将当天修改的文件进行CHECKIN操作,以及将当天新增的文件加入开发库开发区中。每天下班之前,配置管理员检查所有开发人员是否已经按要求完成第2步操作。配置管理员将开发库开发区锁住,将当前版本提取至测试区。配置管理员解锁并通知项目组开发人员。配置项基线化配置项符合以下任一项要求,才可将其纳入基线库:通过GRB评审或通过CCB审核或通过配置经理批准项目经理/技术经理填写“配置项纳入基线请求单”,配置经理审批,配置管理员建立基线。配置项基线化后核心思想:配置项基线化后纳入基线库,由配置管理员完全控制。原则:不允许多人对一个文件进行CHECKOUT操作,由配置管理员对此做严格控制。项目组所有人员需对基线库中的配置项进行变更,必须先填写变更单,该申请必须通过CCB审核。配置管理员根据变更单,将基线库需变更的配置项进行CHECKOUT操作或向变更修改人开放权限。当变更修改人完成变更后,将变更单提交给配置管理员,配置管理员或变更修改人更新基线库。项目经理/技术经理填写“配置项纳入基线请求单”,配置经理审批,配置管理员建立基线。配置管理实施流程识别配置项配置项基线化的要求配置经理确定项目配置项标识规定,配置项以及基线计划,GRB对其进行评审。配置经理在配置管理计划中明确系统版本升级策略。配置项包括:文档类配置项软件类配置项配置项标识规定技术文档表示规定:客户名称-项目名称-文档类型名称质量记录标识规定:客户名称-项目名称-文档类型名称–序号代码标识规定:项目启动阶段,由项目经理或技术经理负责提供,GRB审核。项目管理文档标识规定:会议纪要:客户名称-项目名称-文档类型名称–开会日期项目周报:客户名称-项目名称-文档类型名称–提交日期技术讨论记录:客户名称-项目名称-文档类型名称–讨论日期软件发布标识内部版本标识:内部版本号:X.Y.Z外部版本标识:版本号=VXX.XX.智慧交通,分别为:主版本号+次版本号+补丁号版本控制配置库开发库,基线库,发布库,这三库的目录结构都是相同的。项目经理,技术经理,测试经理裁减标准目录结构,共同确定项目目录结构,填写“项目配置管理库建库申请单”,提交至配置经理,将其纳入配置管理计划,配置管理员负责创建。开发库开发区用途开发阶段:为项目组所有成员提供私有的工作区域。数据来源项目组成员提交权限项目组所有人员:可读/可写测试区用途开发阶段:存放待测试的代码版本数据来源开发区权限配置管理员,测试人员:可读/可写其他人员:可读基线库用途存放项目过程中配置项的所有基线版本。数据来源开发库权限配置管理员:可读/可写其他人员:可读变更控制项目组所有人员需变更该库中的配置项,需按照变更控制流程严格执行。发布库用途存放待发布,已发布的系统版本。数据来源基线库权限配置管理员:可读/可写其他人员:可读发布管理变更控制变更申请当需要对基线或基线中的配置项修改时,变更申请人提交变更申请至CCB,变更申请工作内容包括:1、描述变更的需求或来源,说明变更的必要性;2、分析需要变更的内容;3、说明变更来源:需求变更:新增需求、需求变化、需求分析缺陷;设计变更:设计缺陷;上线系统代码变更:编码缺陷。变更评估变更申请提出以后,CCB评估该变更申请,变更决定的结果要求通知所有相关的人员。评估人员要求具备相关的业务、技术、项目、质量素质,以达到评估的效果。如果是变更涉及到客户的变更,或者是上线后的变更,CCB需要吸收客户负责人员参与。评估内容包括:变更申请内容。包括方案、性质、起因、对其他部分的影响;根据变更对系统其他部分的影响,分析变更的工作范围,进行工作的分解。(参见项目管理WBS)根据不同的变更,可能发生的工作范围包括:需求变更实施;设计变更实施;代码变更实施;项目计划变更实施,主要指进度相关;项目预算变更实施;其他相关的变更实施;以上各变更工作根据分析的结果决定先后关系。变更对进度、成本的影响和带来的风险。根据变更的WBS估算增加的工作量,从而得到变更对进度和成本的影响。其中成本以人工时为单位进行计算。评估结果有三种情况:拒绝变更:需要通知相关人员拒绝的原因。变更活动结束,或由申请人重新提出申请。提交管理评审:如果变更带来的进度和成本的变化超出项目经理所能控制的范围,由项目经理申请高层管理评审,请高层决定是否执行变更。如果否决则过程活动结束。提交管理评审的后续结果包含拒绝变更、接受变更两种。决定进行变更:如果决定接收变更则由项目经理根据关键路径图实施变更计划,并由CCB根据变更的类型、内容决定如何进行变更的验证,包括验证的人员和方式。变更实施变更实施指实际发生的对配置项的修改行为。变更实施是变更评估后的步骤,修改产生的影响已经在变更的评估中考虑。变更验证变更实施工作完成以后,提交指定的人员按指定的方式进行验证。需求和设计方面的变更内容采用文档评审的方式,代码方面变更内容进入测试流程。变更内容得到验证以后,执行配置管理流程,对应成果确定新的基线。质量保证产品的价值取决于产品的质量,软件质量的特性是多方面的。必须包括:与明确确定的功能和性能需求的一致性。即软件需求是质量度量的基础,缺少与需求的一致性就无质量可言。与明确成文的开发标准的一致性。不遵循专门的开发标准,将导致软件质量低劣。与所有专业开发的软件所期望的隐含的特性的一致性。忽视软件隐含的需求,软件质量将不可信。参与制订和评审项目的软件项目计划、标准和规程为项目软件过程的确定和裁剪提供建议;为软件生存周期各阶段工作指出并协助制定所依据的标准和规程;审查项目所选用的有关标准、规程与项目外部强制标准和规程的一致性;评审软件项目计划及选用的标准和规程;提供开发流程的咨询;验证计划、标准和规程是否可得到,且可用于评审和审核活动。制订项目SQA计划在软件项目计划制定的同时提出项目SQA计划初稿,SQA计划不应与软件项目计划的内容冲突。项目SQA计划制订并经QA经理的同意后,提交项目经理、软件工程组和配置管理人员进行评审。经过评审的项目SQA计划再经配置控制委员会的批准后,配置管理人员将SQA计划纳入配置管理。评审工作产品软件质量保证人员需要评审的工作产品包括但不限于:软件项目计划,软件配置管理计划,测试计划等。需要进行评审的具体工作产品详见SQA计划评审工作产品的目的是确保软件产品符合软件开发标准和规程的要求。在工作产品评审结束后的一个工作日内,软件质量保证人员应报告软件工作产品评审的结果。如果发现了不合格项,软件质量保证人员应向项目经理报告,并按审核后续活动的方法跟踪不合格项的处理,并验证不合格项的纠正结果直至关闭。过程审核依据项目SQA计划,软件质量保证人员在项目进行的各个阶段对软件研发过程和工作产品进行审核。当过程审核需要项目组提供支持和配合时,审核前应提前通知项目经理,通知可以用邮件或书面方式。项目经理在得到通知后应准备有关资料,与软件质量保证人员沟通以确定审核时间。实施审核前软件质量保证人员应根据标准检查单剪裁出审核检查单,剪裁后的检查单需经QA经理批准。审核报告:在现场审核结束的一个工作日内,软件质量保证人员应向项目经理和项目组提交审核报告。过程审核后续活动:软件质量保证人员对审核发现的问题,应在现场审核结束的一个工作日内报告给项目经理和项目组。软件质量保证人员在规定的日期后进行验证,验证合格则关闭不合格项;如验证不合格或未采取措施,软件质量保证人员应通过QA经理及时向项目总监报告;报告后,软件质量保证人员必须跟踪该项不合格的处理,必要时进行再验证。所有SQA审核报告、不符合报告等SQA的过程记录,都需要纳入配置管理进行管理和控制。SQA报告机制软件质量保证人员应向项目经理和项目组提交审核报告和工作产品评审报告(可和检查单合在一起)。对于在项目组层面未能关闭的不符合报告,应由项目总监裁决,软件质量保证人员跟踪后续活动。SQA活动的定期报告周报:软件质量保证人员为每一个项目准备一份SQA活动周报,其内容为软件质量保证人员一周内对某项目所开展的SQA活动和项目SQA计划状态等情况的总结。汇报对象是项目经理和QA经理。月报:SQA月报是QA经理每月对SQA活动的执行情况、项目SQA计划的进展情况和项目总监裁决不合格项等情况的总结。QA经理每月向项目总监汇报,并抄送SEPG组组长。风险管理风险管理约定“风险管理”的目的是识别潜在的问题,以便策划处理风险的活动和在必要时在整个项目生存周期中实施这些活动,缓解不利的影响,实现目标。风险管理是一个连续的前瞻性的过程,它是业务和技术管理过程的重要组成部分。风险管理需要处理可能危及关键目标的问题。应用持续风险管理的方法来确保有效地抵御和缓解项目生存周期中具有关键影响的风险。有效的风险管理包括,按照项目策划过程中所拟订的共利益者介入计划,与共利益者合作,早期识别风险。为了建立起能够自由而开放地揭示和讨论风险的环境,有必要在所有受影响的各方之间形成强有力的领导关系。项目总体实施方案项目总体推进计划为了有效地保证系统开发的质量,整个系统建设的全过程划分为准备、设计、开发、实施和运行阶段,每个阶段完成相应的任务,确保信息系统的建设。如下图所示:系统实施过程的质量保证活动说明在实施过程中将发生的重大质量保证活动或由此将产生的质量记录和产品,项目管理与开发阶段划分密切相关,因此主要按照项目实施的具体阶段划分说明。需求分析阶段首先需要经双方协调,形成《需求调研计划》及《需求调研大纲》,确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容,经双方同意后按此计划开始调研。调研正式开始前项目开发组应检查所有必要的准备工作已经圆满完成。项目开发组根据调研中系统实际技术需求和各个子系统的业务需求,编写并向工程领导小组提交符合CMMLEVEL3规范要求的《系统需求分析报告》,并由项目组评审,不合格的部分进一步完善调研;评审通过后由双方共同签署评审意见,并正式生效。对于软件生产过程而言,需求阶段是整个过程中最重要的阶段,需求分析成果的好坏将直接导致项目的成功与否,因此合作双方在此阶段多投入是值得的。而且一旦评审通过并生效,则需求报告将成为系统的设计、开发、测试、实施试运行和项目验收的基本依据之一,因此原则上用户需求将不再因为其它因素的改变而变更,如需进行此种变更,需经双方项目负责人协商确定。总体设计阶段项目开发组通过对系统的功能、运行和性能要求加以分析,产生一个高层次的系统结构、软件结构、接口和数据格式的设计,并向工程领导小组提交《系统设计报告》(其中包括数据库设计),组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划,评审通过后由双方共同签署评审意见,并正式生效,作为后续软件开发和测试的基础。该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定,并需向工程领导小组汇报。详细设计阶段项目开发组在《系统设计报告》的基础上,对功能和性能要求进一步加以分析和细化并且把软件的详细设计文档化,向工程领导小组提交《系统详细设计报告》,并由项目组组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划,评审通过后由双方共同签署评审意见,并正式生效,作为后续软件开发和测试的基础。该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定,并需向工程领导小组汇报。系统开发阶段根据前面的设计结果,由双方的现场实施负责人、技术负责人讨论确定详细的开发计划,并向工程领导小组提交《项目开发计划》;工程领导小组对《项目开发计划》进行审查,由双方签字后正式生效,并将作为软件开发阶段的项目管理和监控依据,项目开发小组要严格据此计划控制项目进度,按时向工程领导小组汇报工作进展。为了使用户能够及时获知项目的进展情况,开发小组需要每周向用户相关领导提交《项目客户周报》,用户项目组可以随时对项目的工作情况进行检查。系统实施和试运行阶段首先需要经双方交流协调,形成《项目实施计划》,确定现场实施的准备工作、人员和日程安排、培训计划、阶段目标等内容,经双方负责人签字后生效,按此计划开始现场实施。正式开始现场实施前项目开发组应检查所有必要的准备工作是否已经完成。现场工作首先要进行软件在服务器端的安装和调试,包括数据库中各类对象的生成,初始化数据,原有系统的重要数据的转换导入,前后台软件的安装,配置参数调整等工作;完成后需向系统维护人员提交《数据库安装目录》,《软件安装方法》文件,并协助用户进行软件安装。软件安装完成并确认可在系统正常运行后,开始相关业务人员的培训;在培训开始之前需要由双方协商形成《培训计划》,明确培训环境、条件及方式,参加人员,课程课时等详细内容,由双方现场实施负责人签字后生效,并分别开始着手准备,在既定时间内完成。培训过程中由工程师提供《培训考勤记录》,培训应该脱产、集中、封闭进行,并要求所有参加人每日必须两次考勤;培训完成后由双方共同进行《培训总结》,针对培训效果确定是否达到目标,是否再增加培训课程;对以上内容用户项目组须进行必要的考核和奖惩,培训工程师有权对参加培训人员进行客观评价。培训顺利完成后将开始软件在试点部门试用,将向用户提交编译后的前后台软件,《软件使用操作手册》,《软件功能清单》,这两种文档将详细描述软件的使用过程,软件所包含的全部系统功能模块。软件试用期内用户的主要工作是根据《软件功能清单》所列的系统功能模块,检查公司所提交的软件是否满足《系统需求分析报告》、《系统设计报告》的规定,列出未完成及含有较严重、明显错误的模块清单形成《软件问题及修改记录》并提交给公司继续完善;此段时间可以对软件的细节性问题进行测试、验证,但主要精力还是应放在模块级功能的检查上,如果所有模块都已开发并可以进入试运行,其设计方法、技术可行性也都能够满足最终软件的需要,则用户各相关业务负责人、现场实施负责人需要签署各子系统的《软件交付书》,表明软件已在现场安装、调试、培训完成,基本可以进入软件试运行;此后在软件功能模块一级上不应再发生大的变化,如需要修改功能模块设计,则需由双方项目负责人协商解决。试运行期内用户负责组织针对《软件功能清单》所列的系统功能模块进行现场的系统测试,包括新旧两套系统并行工作一段时间进行验证,使每个功能模块都得到基本确认;对于其中发现的问题和软件的细节性修改意见,需以《软件问题及修改记录》的书面形式提交给公司;公司修改完成后立即提交到现场,用户负责组织立即对软件进行确认回归测试,如验证问题已修改需要在《软件问题及修改记录》中予以说明。通过试运行及修改后证明已经基本完成的模块,用户应组织相关的业务负责人在《软件功能清单》中逐项确认。项目验收阶段在试运行期内系统存在一定的细节性问题是工程项目不可避免的问题,特别是随着用户应用的逐渐深入,此类需求会逐级提出,此类问题不属于系统的致命性错误;因此当试运行期内所发现的真正的“问题和错误”收敛到一定数目以下时,各业务子系统经过一段时间的并行工作新系统已基本可靠,就可以切换到正式运行阶段,开始正式运行。正式运行后,由用户提出验收要求,双方共同制定《项目验收计划》,组成项目验收小组,共同进行项目验收。此时公司将向用户提交验收的各类文档,包括对系统开发过程进行总结的《项目总结》,《项目技术报告》,最终的完整的《数据库字典》等。验收工作将由用户组织的专家组对系统进行全面的验收和鉴定,并出具项目验收小组领导签字的《项目验收报告》,并签署验收意见,公司在此过程中将全程参与,在现场进行验收前的维护工作。系统正式运行及维护阶段公司承诺对系统软件提供服务保证期,在保证期内提供免费的软件升级和维护服务;在保证期外,公司继续为系统的维护提供技术支持,对于软件升级提供优惠服务。维护期的具体工作方式请见售后服务承诺部分,所有维护工作,包括软件出现问题修改、细节性功能的增强,用户都要以《软件问题及修改记录》的书面形式提交给公司,修改完成后用户应组织相关的业务负责人进行确认,并在《软件功能清单》中说明;如遇紧急情况可事后补齐。各阶段辅助文档《现场工作日程安排计划》,在实施中的各阶段,对于所发生的需要在现场进行较长时间工作的情况,如果在《需求调研计划》、《项目开发计划》、《项目实施计划》、《培训计划》等工作计划中未包含,则需要在工作开始前双方共同制订好《现场工作日程安排计划》,并严格据此执行,需要双方现场实施负责人签字生效。《现场工作周报》,在现场实施工作中,为了把阶段性的工作任务具体落实完成,需要合作双方每周一之前由公司实施工程师与用户组共同制定本周的工作计划,给出每个工作日上、下午的工作内容,以及双方的准备工作。计划制定完成后用户项目组向所有相关部门和领导发布,开始执行;实施中双方互相监督按照原计划开展工作;周五时双方负责人共同对本周计划执行情况进行总结,对原计划填写工作总结,详细描述各项计划的完成情况,未完成的部分应写明未完成原因和责任归属,必要时双方协商一起进行加班处理,力争按时完成;对于不能按时完成的必须调整到下周计划中进行。《用户项目报告》,对于实施中各阶段较长时间不在用户现场进行的,或项目处于用户试运行、维护期的情况,为了使用户能够及时获知项目的进展情况和公司开发小组的工作情况,公司将在开发阶段每周向用户相关领导提交此报告,维护期内每月至少提交一次。《阶段评估报告》,实施中当某一阶段性目标实现后,公司将对该阶段双方联合开发组的工作情况进行总结,编写该报告并向工程领导小组提交,及时总结经验教训,为下阶段工作打好基础。实施过程提交文件汇总以下是对上面的实施过程中将产生的文件汇总说明:阶段名称作用评审级别变更控制需求调研《需求调研计划》《需求调研大纲》确定需求调研的准备工作、内容、方法方式及人员和日程安排双方现场实施负责人双方现场实施负责人《系统需求分析报告》明确用户业务需求双方项目负责人双方项目负责人设计《系统设计报告》(其中包括数据库设计)描述整个系统软件的模块设计,详细设计,数据库设计,供开发编码使用双方项目负责人双方现场实施负责人《系统详细设计报告》软件开发《项目开发计划》软件开发的日程进度,分工,检查点设置,提交成果等计划双方现场实施负责人双方项目负责人软件测试《测试计划》《测试问题卡》《测试总结报告》符合ISO9000质量保证体系规定的功能测试、同行间测试文档软件现场实施《项目实施计划》确定现场实施准备工作、人员和日程安排、培训计划、阶段目标等双方现场实施负责人双方项目负责人系统培训《培训计划》《培训考勤记录》《培训总结》明确培训环境条件及方式,参加人员,课程课时等要求培训记录,培训效果总结,是否达到目标双方现场实施负责人双方现场实施负责人系统安装《数据库安装目录》《软件安装方法》《软件使用操作手册》现场安装、调试和提交软件的相关文档《软件功能清单》所提交软件全部模块结构划分,功能描述用户系统人员《软件交付书》软件已在现场安装、调试、培训完成,基本可以进入试运行证明用户系统负责人《软件问题及修改记录》实施中发现的软件问题和用户提出的具体修改意见,以及对其所作修改和确认记录项目验收《验收计划》《验收报告》《项目总结》《项目技术报告》《数据库字典》开发过程项目总结,技术总结,数据库设计字典等验收相关文档日常工作《现场工作日程安排计划》需在现场进行较长时间的一般工作日程安排双方现场实施负责人双方现场实施负责人《用户项目报告》较长时间不在用户现场时向用户信息服务系统汇报项目进展和工作情况,《现场工作周报》现场工作周计划双方现场实施负责人双方现场实施负责人《阶段评估报告》某阶段性目标实现后进行总结,向工程领导小组提交,为下阶段打好基础项目管理方案项目范围管理项目管理范围包括本项目建设周期内各个阶段以及所有相关的建设单位、设备、软硬件、场地等内容,从软硬件采购、需求分析、系统设计、软件开发、系统集成、测试、验收、试运行、系统维护的全过程都包括在内,如项目启动、项目范围内容、项目范围变更等项,具体内容在项目实施前经详细讨论确定。项目进度管理针对本项目的进度管理从任务分解、时间进度安排到资源分配,每个阶段都有里程碑标志,每个阶段都须严格按照工期要求按时、保质完成,项目经理负责项目进度控制。项目风险管理通过对大量的风险事件进行分析,在本项目中下列事件出现的概率最大,影响也是最大的。如何使得将上述事件对项目造成的影响降低到最小,是项目风险管理的主要工作。首先需要预防上述事件的发生,其次当事件发生不可避免之后,应当采取必要的、事先准备好的措施进行工作,将风险对项目目标的影响降低到可以容忍的程度。技术风险集成指挥平台是一个采用先进的信息技术,在建设过程中需要与各个业务单位、多个技术支撑系统、多个业务系统之间接口。系统需要采集的数据量大、涉及的相关系统范围广,需要比较高的信息管理的专业知识。因此系统建设存在一定的技术风险,需要业主和系统建设方从系统开始建设之初,就要充分认识到该项目的技术难度,在系统调研、系统设计阶段就要进行反复的论证,在系统构架的时候尽可能采用国际上成熟的产品,借鉴相关的成功经验,同时系统的建设分步骤、分阶段进行,将技术难点逐个突破,力求将技术风险降至最低。需求风险平台的建设是一个项目周期较长、涉及相关部门较多、数据量大、系统功能要求高的复杂系统,只能在建设过程中与多家业务部门进行沟通,才能逐步明晰系统的需求。同时,由于GIS专业性较强,有些需求各业务部门人员根本不可能明确地提出,需要系统建设方根据已有的系统建设经验进行用户需求的引导。这些状况容易造成系统的需求不明确,或者系统的需求变更频繁,使得项目进展严重滞后,最后造成项目的失败。为了能够减少该项目需求不清和需求频繁变更的风险,需要用户和公司在项目初期做好充分的需求调研,切实理解各个业务部门在信息方面的业务需求,尽可能避免对需求的误解和片面性。同时,在系统建设过程中,严格遵守项目管理的规章制度,对项目需求变更进行严格的审核与控制,以保障项目的质量和进度。协调与沟通风险在系统建设过程中公司需要协调多个部门,与这些部门的沟通与协调可能直接影响到本项目的质量与进度。因此,建立高效的协调与沟通机制,减少相互之间的误解与拖延,是保障本项目成功实施的关键点之一。这需要各相关单位充分理解项目沟通管理的重要性,严格遵守项目管理的各项规章制度,提高协调沟通的效率,降低项目协调与沟通的风险。项目人员风险由于本项目周期较长,技术难度大,因此项目人员压力会随着项目的进展逐渐加大,工作效率也可能会随着项目的进展逐渐降低,造成工作效率低下,甚至会造成项目成员的不稳定。这就需要用户与公司相互理解,明确共同的目标,发挥团队精神,同时要合理规划项目进度,作到劳逸结合,提高项目人员的积极性,降低项目人员的风险。质量管理计划质量管理体系标准本项目实施应采用先进的质量管理模式和科学的质量管理体系和流程,并根据项目自身特点选用合适的质量控制规程。目前,本项目采用ISO9001质量标准和软件成熟度模型(CMM)两种控制规程。针对本项目,公司将采用GB/T19001-2000-ISO9001:2000质量体系标准,同时遵循SSE-CMM的安全实施标准,并在项目实施的过程中严格执行这些质量标准。质量控制过程本项目中,由项目经理制订质量控制计划,项目质量控制组进行审核。审核方面包括:质量控制措施是否足够、各个成员的质量责任是否明确合理,测试方法是否适用。质量评定计划为了加强项目质量管理和界定产品质量标准,本公司将制订适应于项目的检查验收规定和质量评定标准,确保工程质量。本项目中,应实行两级检查、两级验收制度。一级检查、二级检查和一级验收由本公司实施小组组织完成;二级验收由用户组织实施。各级检查验收严格按项目实施中制订的相应的检查验收规定和质量评定标准执行。对实施和验收过程中出现的重大技术问题,将上报用户协调处理,对一般质量问题的处理应予以书面记录。质量管理措施在项目实施过程中还将采取如下措施保障项目实施质量:(1)产品到货后,对所有硬件设备应进行加电检测,同时对所有软件产品进行安装、产品授权验证。(2)在项目实施前后对网络性能进行评估。(3)在系统部署完成后要在实际环境中进行网络连通性测试、安全策略验证和应用系统测试。(4)配合应用系统做好压力测试,根据压力测试结果调整系统配置。(5)项目实施后要进行一定时间的试运行,在试运行期间要重点监控网络环境的运行情况、安全策略的验证和业务应用系统运行情况,若出现的问题要及时查找原因并加以修正。(6)在试点实施过程中验证方案的可行性和正确性。软件质量控制阶段性评审软件质量保证过程包括对软件过程质量控制和软件产品质量控制。我公司在本系统项目组织中,由质量控制组负责质量控制和管理,采用软件度量过程采集信息对软件过程和软件产品的质量进行管理。对软件过程质量的控制通过量化并提取软件过程信息实现对软件过程的目标管理,量化的主要内容包括:产品质量、项目进度和资源占用。软件过程控制一般采用软件开发过程的节点控制的方法。软件开发过程的节点控制是提高软件开发的计划性和成功经验的可重复应用的重要支持手段。我公司在开发本系统的过程中,将充分利用该方法,确保本系统的高质、准时完成。在本系统的开发过程中,把涉及软件开发、应用的人员分为甲方、乙方,甲方代表各种层次的软件系统的用户,乙方代表软件开发商中各组织、各层次人员。软件系统的最终成功基于甲乙双方对软件开发过程的共同控制与管理,甲方侧重“需求”与“监督”职能,乙方侧重“供求”与“控制”职能。甲乙双方实现职能的基础是软件开发过程的可视性,即从甲乙双方角度得到软件开发过程的可见性。如下图所示:图(a)表示一个对甲乙双方可见性极差的过程,甲方给出需求后,经过乙方的开发过程得到的是最终结果,甲方对软件开发过程没法参与。乙方中只有具体的开发人员了解局部的软件过程,高层管理人员没法得到开发过程中具体的过程状态信息,不能根据过程状态做出决策。图(b)表示一个对甲乙双方可见性较好的软件过程,在软件开发过程的特定阶段设置阶段控制点(也称为里程碑),甲乙双方依据阶段成果,从各自的角度提出过程改善与修改意见,控制软件系统生产的质量、开发过程的效率及项目资源消费。测试测试是确保本系统质量的重要手段,不经过认真测试的系统是不能被用于生产的。虽然,对各阶段的文档的审核也可认为是测试,但本项目所指的测试是指对应用软件的测试。做好测试是测试组的责任,测试组是与开发组相互独立的两组,且需要相当的技术和经验,对业务的理解要十分透彻。为保证测试的效率和质量需要主意以下几点:1.建立高效合理的测试流程,包括:建立尽量模拟真实环境的业务数据模型(即运行业务的初始环境);对测试案例的设计要有深度和广度;特别在系统测试和验收测试阶段,安排好项目组的全体人员的任务和责任;做好测试阶段文档和源程序的版本控制;做好测试中发现的BUGS的记录及存档工作;对发现的任何BUGS都要做好原因分析并记录归档;做好回归测试;防止对程序的修改而引起的其他问题。软件测试是一个过程,涉及到软件生命周期的各个阶段。下图描述了软件测试过程模型:测试过程是与开发过程并行的,软件测试的实施过程是与改错过程既是交错的

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论