《智慧校园信息化建设项目实施计划方案.doc》由会员分享，可在线阅读，更多相关《智慧校园信息化建设项目实施计划方案.doc（70页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、智慧校园信息化建设项目实施计划方案1.1. 实施开发计划1.1.1. 总体思路实施计划将根据应用系统建设的情况，科学的安排人力、物力和资金的投入，在用户要求的时间段内，通过可伸缩的人员配置计划，有步骤分阶段的实现应用，同时考虑对用户投资的保护。我们建议项目规划为三个阶段进行：第一阶段：l 建设基础软件支撑平台l 建设学生综合管理与服务（除本科教务、研究生综合管理和成人教育管理）l 教职工综合管理与服务l 综合业务综合管理与服务（除数据仓库及统计决策系统）第二阶段：l 本科教务系统和研究生综合管理系统l 资产综合管理与服务第三阶段：l 建设数据仓库及统计决策系统l 成人教育管理系统1.1.2.
2、实施开发计划实施开发计划主要是描述整个项目过程中的不同阶段的任务进度计划，以及要达到的目标。里程碑标志是各个任务所对应的阶段性成果，同时也是下一阶段开始的检查点。技术实施计划主要关注项目交付物及确保这些交付物能及时提交的项目任务。技术计划在一个项目开始的时候建立，它描述了项目的主要任务。它是项目资源计划预测项目总的时间、成本，及衡量项目的总体进度的基本材料。实施开发计划的执行由项目经理控制，并根据项目情况制定不同的阶段性计划，资源计划和质量计划，通过对里程碑的检查点的监控，来控制整个项目的实施，以确保整个项目在质量控制和进度控制规定的范围内。根据学校对本期项目工期的时间要求，我们在编排项目实施
3、计划时，充分考虑了项目的特殊性及项目中基础平台和业务系统的实际实施情况，根据我公司的实施经验，在时间的控制上进行了合理的安排，以确保项目能够在学校规定的时间内顺利完成。第一阶段进度安排基础软件支撑平台（2010年4月至2010年12月）主要活动和安排时间跨度（月）主要工作需求调研1.5需求调研、页面原型制作、集成标准系统设计1概要设计、详细设计编码、测试1.5编码、单元测试压力测试和集成测试、集成平台搭建实施2.5现场功能测试、系统交付、两次迭代、系统培训等试运行2系统试运行、试运行记录验收0.5系统验收学生综合管理与服务（除本科教务、研究生和成人）（2010年4月至2011年7月）主要活动和
4、安排时间跨度（月）主要工作需求调研3需求调研、页面原型制作、集成标准系统设计4概要设计、详细设计编码、测试3.5编码、单元测试压力测试和集成测试、集成平台搭建实施3现场功能测试、系统交付、两次迭代、系统培训等试运行2系统试运行、试运行记录验收0.5系统验收教职工综合管理与服务（2010年4月至2010年12月）主要活动和安排时间跨度（月）主要工作需求调研2需求调研、页面原型制作、集成标准系统设计1.5概要设计、详细设计编码、测试1.5编码、单元测试压力测试和集成测试、集成平台搭建实施2.5现场功能测试、系统交付、两次迭代、系统培训等试运行1系统试运行、试运行记录验收0.5系统验收综合业务综合管
5、理与服务（除数据仓库及决策系统）（2010年4月至2010年10月）主要活动和安排时间跨度（月）主要工作需求调研1需求调研、页面原型制作、集成标准系统设计1.5概要设计、详细设计编码、测试1编码、单元测试压力测试和集成测试、集成平台搭建实施2现场功能测试、系统交付、两次迭代、系统培训等试运行1系统试运行、试运行记录验收0.5系统验收第二阶段进度安排本科教务系统（2011年3月至2012年3月）主要活动和安排时间跨度（月）主要工作需求调研2需求调研、页面原型制作、集成标准系统设计2.5概要设计、详细设计编码、测试2编码、单元测试压力测试和集成测试、集成平台搭建实施3现场功能测试、系统交付、两次迭
6、代、系统培训等试运行2系统试运行、试运行记录验收0.5系统验收研究生综合管理系统（2011年3月至2012年3月）主要活动和安排时间跨度（月）主要工作需求调研2需求调研、页面原型制作、集成标准系统设计2.5概要设计、详细设计编码、测试2编码、单元测试压力测试和集成测试、集成平台搭建实施3现场功能测试、系统交付、两次迭代、系统培训等试运行2系统试运行、试运行记录验收0.5系统验收l l l 资产综合管理与服务（2011年3月至2011年12月）主要活动和安排时间跨度（月）主要工作需求调研2需求调研、页面原型制作、集成标准系统设计2概要设计、详细设计编码、测试1.5编码、单元测试压力测试和集成测试
7、、集成平台搭建实施2.5现场功能测试、系统交付、两次迭代、系统培训等试运行1.5系统试运行、试运行记录验收0.5系统验收第三阶段进度计划数据仓库及统计决策系统（2011年11月至2012年3月）主要活动和安排时间跨度（月）主要工作需求调研0.5需求调研、页面原型制作、集成标准系统设计1概要设计、详细设计编码、测试1编码、单元测试压力测试和集成测试、集成平台搭建实施1现场功能测试、系统交付、两次迭代、系统培训等试运行1系统试运行、试运行记录验收0.5系统验收成人教育管理系统（2011年11月至2012年3月）主要活动和安排时间跨度（月）主要工作需求调研0.5需求调研、页面原型制作、集成标准系统设
8、计1概要设计、详细设计编码、测试1编码、单元测试压力测试和集成测试、集成平台搭建实施1现场功能测试、系统交付、两次迭代、系统培训等试运行1系统试运行、试运行记录验收0.5系统验收注：以上只是初步计划，具体实施计划时间表在中标后与学校商定。1.2. 质量计划在计划阶段需要采取步骤确保项目是完全按用户要求提供的交付物。每一个交付物的质量标准将被明确定义，用来制订质量保障计划。在质量计划中必须考虑抽查和定稿的流程，抽查的活动必须依据技术方案严格定义并记录成文档。因而进行的质量计划活动必须同技术计划集成在一起。在质量计划过程中，质量保证经理必须以独立的身份参与项目活动，以确保产品的质量。以下为质量管理
9、过程中的主要行为，它是具体的质量计划制定和执行的依据，在项目实施过程中根据项目情况制定详细的计划。质量计划主要的行为包括：l 项目提交物的定义和进度安排l 合约条款的回顾审查l 提交项和检查点的回顾审查l 系统测试l 错误管理和跟踪在执行质量计划的主要任务过程中，我们有以下各项内容。文档规范：l 程序和编程规范l 设计规范技术回顾审查程序：l 文档的回顾审查过程l 编码和检查点的回顾审查l 系统规格说明书的回顾审查l 系统设计和详细设计的回顾审查l 源代码的回顾审查测试程序：l 测试过程l 编制测试计划l 设计测试案例l 执行测试l 记录测试结果l 检查测试完成情况l 系统集成测试l 用户接受
10、测试1.3. 异常计划在成本和时间进度已经偏离原来的计划，或偏离的程度已经超出了项目委员会所建立的容忍程度，必须执行异常计划。作为风险管理中的重要一项，在具体的项目实施过程中必须详细描述异常偏离计划的原因、偏离的结果、建议改正的措施。本节的异常计划是从风险管理角度来说明异常出现的处理方法和依据。风险管理建立风险管理“前10位风险表”，它是在给定的时间内项目可能所面对的最高风险列表。风险列表将有助于项目负责人随时注意风险管理。“前10位”风险模版表优先级(当前的)优先级(前一周)风险描述风险所有人风险管理计划123.10在项目初期，项目负责人会准备一份初步风险列表，在项目过程中不断更新并保留至项
11、目结束。在项目发展过程中，更多的细节风险将会被界定并增加到风险列表中。列表是不是一定要有10项并不重要。列表内可有5 项甚至是15项风险。最重要的是必须定期地保持列表更新。项目负责人将每月回顾“前10位风险表”。他们会更新风险表，重新排列风险优先次序，并更新风险管理计划。这将有利于强迫他们定期地考虑到风险，并注意风险重要性的转变。有了项目范围内可见度的支持，风险列表可应用在全体项目人员上。下列是一份风险管理样本表，是我们风险管理中重要的一项内容。风险管理样本表风险管理样本表风险表述:需求清晰性 第二阶段的需求没有清楚列明优先级:2风险所有人:XXX发生的可能性:高影响范围:时间表，费用，质量影
12、响级别（如果没有风险管理）高风险管理将会分为两个级别:减低风险我们会在转变控制下把所有需求列在标书的范围外。如果有由这些转变因素引起的费用发生，额外的预算将被提出在设计与开发阶段开始前，我们将确认需求，这些需求都必须经XXX界定及认定的。我们会开发一个灵活及可升级系统设计来减少需求更改的影响在每个设计阶段的开始，我们将用原型来确保系统设计完全符合使用者的确切要求。我们会确保是根据当前版本的优先级需求详细的设计和编码破坏控制和容错计划在项目交付前，在按计划交付所有性能的前提下，要求项目负责人寻求客户的允许，首先交付高优先级的需求；并将低优先权需求的交付延迟至下一开发阶段任何延迟的合理需求更改所需
13、的额外的时间和资源的重要性和利用必须完全合理；否则，我们将拒绝需求更改或安排到下一版本影响级别(有风险管理):中1.4. 系统风险分析依据项目管理的相关规定，结合我们在以往项目的成功和失败的经验，我们进行了细致的分析，提出了大学的风险管理与质量保证计划。我们详细分析了整个开发过程，针对大学项目的要求，在半年的时间里实现校园网基础平台及业务系统的运行，在这个过程中会产生什么样的风险，并且阐述了我们是如何规避和应对这些风险的。同时介绍了我们以往的一些高校项目在执行过程中遇到的风险和问题，以及遇到问题后我们的应对措施。1.4.1. 需求阶段一、学校用户难以界定产品功能范围，希望要一个在任何平台、任何
14、情况下都适用的产品。“完美”是不存在的，导致双方不断确定、更改相应文档。应对措施：1）对用户进行软件需求的培训；2）项目初期明确方向，界定范围；3）使用原型开发；4）给用户演示已结束的类似项目，获取用户需求。二、随着用户对项目产品的不断了解（通过各种渠道），不断提出新的或者更加有难度的需求，造成频繁变更。应对措施：1）需求分析结果客户签字确认，如要更改已确认的需求，需双方进行联合评审，评估变更风险后方可实施；2）设计采用松耦合设计，降低非预期变更带来的影响范围；3）对于新需求，由双方沟通，采用非技术手段解决，或者留在以后版本处理；三、开发中途变更产品的硬件环境要求，导致软、硬件接口出现问题。应
15、对措施：1）对于硬件环境的变更必须及时评估对于设计的影响；2）设计方案应有较大弹性，以适应硬件环境的变化。1.4.2. 设计阶段一、阶段交付/迭代开发模型带来的风险迭代法虽然能减少软件系统的后期维护费用，降低因需求不明确带来的项目风险，但是初期交付原型本身功能设置不齐全、 性能不好，会导致原型的设计和使用超出预期的花费和时间，并且使客户产生项目是否能够实现的疑虑。应对措施：1）设立阶段目标；2）给客户进行设计及实现过程讲解，使客户要求的阶段交付目标尽量与阶段实现的目标相一致。二、在系统设计时为考虑软件平台的应用范围，不断修改设计，进行讨论，反复评审，始终拿捏不定，导致设计时间过长。应对措施：1
16、）寻求有经验、有判断权的领导作为项目组的核心力量，短时间内判断适用技术，确定模块性能；2）项目前期与用户充分交流，多调研需求，后快速开发，之后再进行升级；三、不像桌面程序的开发，发展时间长，已逐渐形成了一套规范，而WEB应用刚刚发展不长时间，很多东西仍延用桌面程序的要求，但桌面程序与WEB程序的不同导致这些规范不可能完全适用，甚至大部分的都不适用。而且WEB的表现形式决定了界面布局有着自己的特点，依赖程序员之间自发的保持界面一致很难达到希望的效果。应对措施：提供学校一套WEB界面设计规范；四、项目规模估计不足，不能在预定时间交付系统。应对措施：1）细化需求分析，做好任务分解；2）掌握先进估计方
17、法，使用估计工具；3）聘请专家进行估计或参与策划评审；4）设定弹性任务；五、开发任务未细化，任务遗漏，导致最终需求没有完成。应对措施：使用任务分解和需求跟踪矩阵技术（公司内的开发跟踪工具）；六、根据以往经验，对于系统性能的要求，各高校均有所差异，这种差异会给软件设计带来较大的影响。应对措施：1）向客户展示过去完成的较为成功的设计及实现的功能模块，说明已完成项目功能齐备、性能优异；2）通过平台及数据库的优化（我们是IBM及ORACLE的合作伙伴，厂商支持力度大）。1.4.3. 编码阶段一、由于修改代码时会涉及他人编写的代码，而且由于代码封装的不好，容易在某人的代码修改后给他人的代码代来影响。应对
18、措施：1）明确模块之间的相互依赖关系，对于依赖性较强的模块加强详细设计：2）明确人员沟通渠道，对于发现问题确保有合理的问题关闭机制；二、团体配合能力差，有些模块间接口定义不明确而导致开发返工。应对措施：1）详细定义模块间接口联系；2）加强开发规范的管理，在编码前再次强化开发规范管理的培训；1.4.4. 测试阶段一、测试设备陈旧落后，导致测试进展缓慢或者测试中得到的数据对用户意义不大。应对措施：确认测试环境，提前借用或购置设备；二、测试用例不完善。测试人员测试不全面，考虑不周，导致程序仍存在很多问题，无法结束项目。应对措施：1）测试人员参加需求评审或由PSM对测试人员进行软件需求的培训；2）加强
19、测试用例评审；三、对项目开发版本控制不力，在后期开发测试阶段出现版本错误，测试的版本不是最新的，导致无效工作。应对措施：1）编码结束后进行配置审计；2）测试过程中由测试人员控制配置库中的代码版本更新；1.4.5. 实施一、对实施人员和客户培训不到位，实施难度大。应对措施：1）项目任务紧张时也要求形成技术报告和用户手册作为培训资料；2）可以由实施人员和客户共同参与系统测试，达到一定培训效果；二、客户对开发人员依赖感过强，迟迟不肯验收。应对措施：1）做好领导层的工作；2）宣传讲解服务范围和公司服务管理的规范性；3）做好用户基层人员的培训工作；4）做好实施准备，确保规范性，确保每步实施完成的工作阶段
20、性得到确认；三、测试不充分，实施中发现从未遇到的问题，推迟验收。应对措施：测试人员加强对业务的了解，测试用例听取多方意见，包括各层次、水平的操作人员；四、现场与公司开发人员有多个版本接口，造成版本混乱，拖延沟通时间。应对措施：统一版本控制接口，专人发放程序；五、销售人员定义的合同存在二义性。应对措施：签订合同时技术人员参与，明确主要需求，并确定提出新需求不能超过需求的30，否则另外收费；1.4.6. 全过程一、人力资源分配不当，无法充分考虑项目组成员的个人喜好和对开发语言的熟悉程度，以及个人工作能力和工作任务的分配，导致人员的抵触情绪。应对措施：1）项目负责人充分了解成员具体特点，调查人员意愿
21、，分配任务前取得人员的认可；2）对于能力较差的人员负责的模块细致分析该模块的逻辑，确定不清晰的问题，增加人员参与该模块的编码；二、项目组重要成员流失或项目进行到一半，有些人员要出差去解决以前项目的问题，导致其负责的模块暂停。应对措施：1）日常保证文档质量和工作日志，使项目本身具备抗风险能力，弱化对人员的依赖性；2）安排相对稳定的人员参与项目，与开发人员加强沟通，帮助解决生活等方面问题，团结开发队伍；3）对于关键技术要保证至少两个人参与，可以由两个人负责两个模块的配对开发，既提高效率，降低接口复杂度，也避免人员变动的风险。1.5. 项目控制项目控制是对整个项目进行过程中的各种情况进行控制的一种手
22、段，通过对项目进度、项目质量、项目的提交等控制和管理，以确保项目能够在不超出预算的前提下按时保质保量完成。本节主要从管理控制、交付控制、缺陷管理、质量管理、文档管理和变更管理等方面进行描述。 1.5.1. 管理控制管理控制涉及项目活动的所有方面，控制活动以项目指导委员会会议、项目保证小组会议和其他的项目会议方式来进行。会议类型包括：项目启动会议 提供一个项目的良好开端，以确保如参照、目标、承诺、调整、计划和组织等词汇被清楚的定义、公布、理解并达成一致。进度会议 这是一个常规会议。在会议中，项目经理将汇报项目当前状况，并提供一个契机，让项目指导委员会解决那些项目经理无法解决的项目问题。会议召开的
23、频度由双方决定。最后阶段的评估 它在每个实施阶段的收尾部分进行。开发结案会议 这是项目指导委员会的最后一个会议，用来确认并接受新开发的系统，并正式宣布相关的开发阶段结束。关键点检查 这是一个定时进行的会议。项目经理检查相关交付物，确认项目的技术问题，并按需要采取相应的措施。1.5.2. 交付控制质量和技术控制主要针对特定阶段提交的交付物，而不是针对整个阶段的产品结果。目的是为了在开发阶段尽可能早的确认并改正错误。它通常采用下面的控制机制：质量抽查 每一次质量抽查，是指技术、质量保证及用户的相关人员对交付物进行检查，确定它已经完成、符合对它的描述、符合质量标准和相关的用户需求。变更控制 一个变更
24、是指与一个或多个交付物相关的并且事先未知的需求改变。它需要被记录并应采取适当措施加以控制以防变化扩大化。软件配置管理 软件配置管理提供一个正式的机制用来对交付物进行标记和归档，跟踪开发状态及它们之间的关系。缺陷管理 缺陷是指已被认为正式通过后的交付物发现技术上的异常问题。它需要被记录及改正以保持交付产品的完整性。风险管理 这个控制机制用来识别、评估、监控项目风险，使项目风险对项目的破坏程度降到最小。1.5.3. 缺陷管理缺陷管理是管理在系统验收测试中发现的、新系统运行过程中发现的错误的修改工作。发现的缺陷将被记录，而且修正过程需要被严格监控。缺陷是指新运行系统与开发前确定需求规格的差异（即接收
25、到的需求与完成的产品之间的差别），包括文档，用户界面，功能，以及性能。非偏离需求规格而引起的变动叫“变动请求”（CR）。CR将被按照变动管理的方法去报告和处理。详细描述见“变动管理”部分。缺陷跟踪系统为在系统开发过程中，能够即时提交缺陷，管理缺陷，分配、更新缺陷跟踪记录，必须建立缺陷跟踪系统。缺陷的管理包括：l 缺陷发现 l 缺陷提交l 缺陷分级l 缺陷分配l 解决缺陷l 再测试l 发布和完成缺陷状态每个缺陷将被分配一个状态。缺陷的处理过程可以通过观察每个缺陷的状态来完成缺陷监控。可能出现的状态有：项目缺陷状态表状态说 明活动的缺陷已经输入，还没有实施解决措施已解决缺陷已经分配，问题正在解决，
26、等待再测试。已完成缺陷已经测试过了，没有碰到更多问题重复属于重复性的缺陷优先缺陷比其它系统缺陷要优先处理缺陷发现大部分缺陷是在测试阶段发现的，如先前所讲，缺陷是文档中描述的需求与完成产品之间的差异。而系统改进方面的请求应按照“变动管理”方法处理。 缺陷提交每个项目组成员都可以提交缺陷，通常，大部分缺陷都是在系统测试阶段发现的。在这种情况下，缺陷要报告给项目经理，并且登记到缺陷管理系统。所有的缺陷将进入缺陷管理系统，它们应该包含以下信息：l 缺陷所在系统模块l 缺陷的详细描述 l 如果是功能缺陷，说明是否缺陷会再产生，以及再产生的步骤。l 严重度 根据发现问题的性质，缺陷的重要程度可以分为：缺陷
27、重要程度表严重度适 用 于S1防碍系统能力的发挥S2防碍运行和重要任务的完成，但是其他功能仍然可以用S3影响运行和重要任务完成，而且没有解决措施S4影响运行和重要任务完成，已经发现解决办法S5使操作员使用不方便和烦恼，但是不影响运行和关键任务处理使操作员使用不方便和烦恼，但不妨碍任务的完成S6其他影响缺陷一旦被接收，分配一个唯一编码，其状态为“活动”缺陷优先级缺陷管理长官要每天监控缺陷提交。根据缺陷的严重度和性质对缺陷分配一个优先级：l 高- 缺陷必须尽快改正l 中- 应该尽快修正。 但是，可以在所有高优先级别的缺陷修正之后做。l 低- 缺陷可以以后再改，不会影响系统运行。缺陷分配缺陷将按以下
28、顺序分配给开发者去改正：高，中，低。在软件开发和内部测试阶段，分配和解决缺陷可能不必获得项目经理的批准。软件开发者可以分配和解决所有必要的缺陷。然而，一旦一个版本已经选为基本版本，项目经理要进行影响分析，确定是否要解决该缺陷。在版本选择阶段，任何缺陷的修改必须获得配置管理员和项目经理的批准。解决缺陷当开发者收到缺陷时，要分析缺陷的成因，并分析原因和提出解决方案。其直接领导要立刻批准对应的分析和解决方法。批准之后，项目经理要分配时间去解决问题。为修改程序，需要从版本控制系统中借出源文件。对缺陷要做单元测试，以免影响系统其他部分。当缺陷改正后，有关文件要还回版本控制系统。在还回时，记录缺陷的编号和
29、简要描述。在缺陷管理系统里面，要更新缺陷的信息，加入缺陷分析和解决措施，以及修改过的文件。缺陷的状态应标为“正在解决中”，并分配给测试组进行重新测试。所有会影响文档的修补，如用户文档，要通知项目经理，以便采取响应行动。测试，布置和结束缺陷处于“正在解决中”状态，而且被发回测试组时，将进行再测试。测试组根据标准测试方法测试。如果再测试成功，将修改部分布置到生产系统中，要求用户再进行测试。如果没有问题，缺陷的状态就可以标志为“已完成”。如果缺陷仍然存在，或碰到新问题，缺陷要被发回负责处理的人。返回的缺陷要包含返回的原因和碰到的问题。返回的缺陷要被再评估，这个过程要不断重复直到缺陷解决为止。缺陷跟踪
30、和监控为确保一系列行动被执行，并且在要求时间内完成，缺陷应该由项目经理亲自进行跟踪和监控。1.5.4. 质量保证管理(QA)质量保证是一个有计划和系统化的质量管理过程，提供项目或产品遵守技术的需求的足够的信心。我们将依据质量法则来建立一套软件质量保证计划，来确保项目的标准和流程具有足够的质量水平，并将它贯穿在项目的始终。质量法则质量不仅仅是指软件产品的测试，它在软件的生产过程之中被不断建立。我们的质量保证的方法基于下列的质量法则：l 预防错误的产生l 确保错误尽可能早的被发现l 增加方式的设计、开发和测试，以减少无谓的错误l 根据需求，独立的开展测试工作（1）预防我们通过下列方式避免在开发过程
31、中产生错误：l 采用适当的软件工程的标准和流程l 独立的测试，确保满足项目的功能性和技术性的需求l 清晰地界定人员的角色、责任和交流的渠道l 高质量的输入，包括软件工具l 受过相应培训和有经验的人员（2）独立的检查和确认（质量控制）采用预先防范的策略可以大大减少错误的数量，但是错误并不能完全消除。因而，我们将 采用第二种防范手段，尽可能早的把开发过程中产生的错误检查出来并加以纠正。错误发现的越晚，纠正错误的代价就越高。我们将采用质量控制，例如技术审查（正式和非正式），在软件开发周期的各个阶段，在产品开发的各个关键点，需求、设计、文档和编码，而不仅仅把质量控制留在测试阶段。在这个阶段，纠正主要的
32、错误已经太迟了，纠正的成本也太高了。（3）技术审查我们将在所有主要的文档和软件模块提交之前，进行技术审查。审查的目的是为了评估一个特定的元素是否遵守下列规定：l 遵守规范l 符合相应的项目标准和流程l 以纳入变动控制的管理，因而所有的变动都能被正确的实现，并仅仅影响在变动描述所确定的地方l 技术审查包括在质量保证计划中，包括检查点的审查，同事间相互审查，预演和代码级的检查。（4）测试测试是指通过手工或自动的方式，对系统或系统中的组件执行检查或评估，它包括：l 确认满足指定的需求l 确认期望的和实际的结果之间的差异我们在系统验收测试之前，要对所有的软件进行系统集成测试。通过一个独立的测试团队来进
33、行内部测试，从保证公平的角度来说是很有必要的。质量保证的职责每个项目组的成员在开发和测试中都要遵循一个既定的流程。我们分配一个以独立身份出现的质量保证者（以下简称QAM）来定义这样一个流程。一个标准的流程是由书面的标准和流程组成并被定义在软件开发的环境中。质量不仅仅体现在项目产生的产品上，每一个参与项目的员工都要为他们自己的工作质量负责，项目经理为整个项目的质量负责。质量保证的行为我们分配一个独立的QAM来定义所有必需的软件质量保证的行为，包括在质量保证计划中。总的来说，这个QA的方案包括下列的行为：l 管理对管理的结构进行分析本身就是一种QA的行为，会影响到软件本身的质量。我们将为项目建立一
34、个相应的管理结构，结构中的每个角色都有清晰定义的任务和职责。l 文档QAM分析项目中的文档计划，确定与同类计划的相关标准的差异，并从项目管理的角度讨论这些差异。l 标准和实践QAM将监控所有的标准（如编程标准）和流程（如质量审查）并贯穿项目的始终。l 审查和稽核QAM将检查对项目审查和稽核工作的安排，确保它们对项目来说是充分的和必要的。l 测试运行软件并对软件进行测试，是软件开发质量控制的重要一部分。QAM将检查QA的这些行为相关的计划或报告，如测试计划，测试方案，测试数据和测试报告，为测试做好充分的准备。l 编码、文档和媒介控制QAM将检查所有的软件工程中使用到的流程、方法的正确行，以及文档
35、和其他媒介（如CD）是否在管理、存储、安全和版本控制方面被正确使用。1.5.5. 变更管理1.5.5.1. 配置管理和版本控制企业公司采用相应的配置控制程序来管理新系统的各个部分，包括文档，需求，设计，数据库设计，编码，文件和数据。并在项目实际实施的时候制定配置管理计划，并委任一名配置管理员。配置控制的目的是控制系统的物理和功能特性，确保整个系统的完整性。配置控制即是技术活动又是管理活动，它的过程包括：l 发现并定义系统中的配置项目；l 控制配置项目的版本和变动；l 记录和报告配置项目的状态；l 确认配置项目的完成和正确 配置项目发现和保存每个配置项目要有一个编号，用来区别有不同需求和实施要求
36、的其它项目。它还有一个版本号，用来标明该项目所处的阶段，在配置项目修改时，版本号要更新。配置系统要能够容纳新的配置项目，不必修改现存项目。配置项目要保存在软件库里面。为确保足够的安全以及对所有可交付软件项目的控制必须建立如下典型的软件库：名称状态开发库动态的主库控制的静态库静态的开发库是软件作为一系列模块进行开发和测试的动态库。主库是一个被控制的库，项目的放入和取出必须按规定并以一定的控制方式进行。例如，在单元测试成功之后，模块可以被转入到系统主库，然后供系统集成和系统测试。任何经过以上测试需要修改模块都要放回开发库，以供测试。当主库达到了一定程度的稳定后，就可以将它合成一个基准。每当基准发布
37、以后，相关主库都要进行拷贝生产静态库。之所以叫做静态库，因为以后不再更新，并且归档。配置变动控制只有当项目已经成为基准的一部分时，软件配置控制才能够进行，它主要控制：l 评估对配置项目的变动l 协调批准的变动在本项目的执行过程中，项目经理将与大学一起定义处理配置变动以及变动授权管理方法。作为对于已经通过的单元，系统的验收测试项目的变动，需要更高级别的授权。配置状态记录配置状态记录包括所有配置项目跟踪报告，并且贯穿整个系统开发周期中，配置项目状态将通过配置管理员来跟踪和控制：为有效进行配置状态记录，应该记录以下信息：l 每个基准版的日期，版本和问题；l 每份文档审阅以及文档修改的日期状态；l 每
38、份软件问题报告、修改请求、和修改报告的日期和状态；l 每个培置项目的总结描述。软件版本企业公司要在版本文档内记录软件的版本。后续版本要附一个版本说明。该说明列出了版本内的配置项目，并且说明其安装步骤。而且，所有已经修改的错误和已经合并的新的需求都要有记录。企业公司要在提交新版本之前重新测试修改过的软件。对于每个版本，本公司保证文档和代码的一致性，而且保存旧版本。1.5.5.2. 变动管理的方法产品的完整性需要通过变动管理来维持。用户需求的变化、系统需求的变化和系统设计的变化都被监控和跟踪，从而了解被批准变动的实施状态。控制变动的目的是为了确保只有经过批准的变动才能实施，确保变动情况传达到了相应
39、的有关方面，提供它们考虑和获得它们批准。用户需求、系统需求和系统设计文档在通过评审并批准后将作为基准。当一个文档变为基准以后，就自动进入变动控制范围。任何变动都需要提交变动请求。变动管理由以下四部分组成：l 变动请求 l 变动评估l 变动批准l 变动实施和跟踪 任何变动都要通过变动请求（CR）提出并提交到项目指导委员会进行批准。CR并不意味现存产品有任何错误。提出CR可能的理由有：l 用户希望修改系统某一 特性l 发现了新的需求l 项目组成员针对系统某一特性提出了一个改良的建议（1） 变动请求当有变动需要时，请求者将填表格，表格要包含以下信息： l 变动所影响的模块和系统l 变动的描述l 变动
40、的理由l 变动细节l 预计的影响收到CR后，项目经理将其编号，召开会议讨论。 （2）变动评估和批准当项目指导委员会收到CR后，要决定是批准还是否决。任何变动都要在会议之前做好研究。 项目服务控制人员将考虑请求的重要性，并进行影响分析。调查者要写影响分析报告，并发给项目指导委员一份。 变动的种类 根据影响分析报告，变动将被分为以下几类：类别1，变动影响到基准文档或者引起成本和进度变动。类别2，变动不影响基准文档，并且对于成本和进度影响可以忽略。如果委员会认为变动属于类别2，变动自动获批准，不要进一步行动。如果变动属于类别1，必须给出如何处理的建议。有两种可能性：-l 接受变动并建议变动何时实施l
41、 拒绝请求影响分级根据“影响分析报告”，变动的影响可以分为以下级别：变动影响级别表状态说 明高变动的实施非常重要，比如为符合合同的要求中很有必要实施，比如影响到运行效率低没有大的好处和影响，比如文档的修改装饰性改动很小，对系统的作用不可测量，例如修改操作手册的样式。根据CR的优先级和其他项目因素（比如，可用时间和资源），委员会可以决定是否建议实施变动。 影响分析影响分析是要确定对产品进行变动所需要的资源，时间，成本，以及风险。研究者应该准备“影响分析报告”。报告中应包含以下项目：l 提出者和其单位l 所建议的达到变化的简要方法l 技术优点评估l 潜在副作用评价l 总结对其他配置项目和系统功能的
42、总体影响l 必须考虑的限制l 预计对于项目成本和时间的变动l 评审和监督的标准l 建议可以采取的方法和不能采取的方法 （3）变动的批准变动请求应该有以下六状态：变动请求表未处理未有决定否决已决定不变动延后决定不在此项目中修改，留待以后去做同意批准实施进展中正在实施变动完成已经完成变动并经过审核在会议结束，CR应该处于以下状态之一：未处理，否决，延后，或批准。获得批准并且开始了实施工作，状态应为：进展中。所有工作完成，CR将处于“完成”状态。会议中请求的列表应记录在文档中，并且标明审批的状态，最后要委员会签署。在项目结束时，所有的CR应处于“否决”，“延后”，“完成”三种状态之一。（4） 变动实
43、施和跟踪根据委员会对变动的建议，有两种的行动可能发生。如果委员会建议是否决，将请求的状态记录为“完成”，如果委员会建议接受并批准了书面的对计划和成本的影响，本公司要实施变动的处理。1.5.6. 文档管理1.5.6.1. 主要文档的描述文档是指在项目实施过程中以及软硬件安装、操作、使用、测试、控制和维护过程中，参与项目的人员用来计划、设计、编辑、发布和维护所产生的纸质、电子和程序文件。在整个软件生存期中，各种半成品或成品文档被不断地生成、修改或补充。文档可被人和计算机阅读，它起到开发团队、用户之间起到桥梁作用，使项目能够进行控制、实施和评价，使项目得以顺利完成。根据项目实施过程，将提交下列内容：
44、1) 总体规划阶段：项目任务书、项目开发实施计划、开发人员安排、项目质量计划、质量保证计划、总体工程计划、阶段工作计划、文档编写计划、项目启动文档等2) 需求分析阶段：业务模型说明书、问题陈述书、USE CASE模型、USE CASE说明书、用户界面设计说明书、用户界面模型、术语表、系统需求规范、需求说明书、用户手册（系统功能说明）、硬件设备安装调试指南等；3) 系统设计阶段：系统设计报告、系统结构分析说明书、软件构架说明书、子系统设计说明书、类设计说明书、数据库设计说明书、系统数据字典、应用系统接口规范、系统测试方案、规范和预期结果、功能设计文档、设计评审报告等；4) 系统测试：测试计划、测
45、试规范、缺陷分析报告、测试环境核校验、代码审查表、测试方案、测试记录、测试验证表、测试报告、测试问题报告问题部分、测试问题报告解决部分、测试总结报告、系统安装报告、内部测试报告、系统操作手册、培训教材、系统测试结果、系统维护手册、系统维护流程、备份流程等；5) 用户测试：系统发布说明书、上线计划、上线及运行报告、系统培训教材、用户使用手册、系统管理员手册、系统验收报告等6) 系统试运行：系统维护手册（软、硬件）、系统故障诊断书、最终验收测试报告、应用软件源代码、相关图表、用户问题报告等7) 项目管理：项目计划、资源计划、变更控制计划、风险管理计划各文件内容说明表 文档名称项目启动文档(PID)目的记录推荐的项目组织，项目计划和项目控制方法。它应该包含本项目的有效管理的基本的信息。主要内容PID的内容包括：简介、项目定义、业务案例、组织、