软件开发项目实施与管理方案（纯方案18页）.docx

1技术方案21.1 项目实施与管理21.2 质量保障管理61.3 风险管理措施91.4 培训服务1415售后服务161.6 商务及其他要求17风险识别风险识别主要是通过管理者经验和项目组集体讨论发现可能对软件工程过 程、正在开发的软件或者开发机构产生重大威胁的风险。风险一般有可预料（包 括已知的）风险和不可预料风险，主要有下列种类：（1）合同风险。签订的合同不科学、不严谨，项目边界和各方面责任界定 不清等是影响项目成败的重大因素之一。（2）需求变更风险。需求变更是信息系统项目经常发生的情况，必要的需 求变更是正常的，但是无限度的需求变更会让项目实施过程陷入低效率重复的境 地，影响整体质量。（3）沟通不良风险。项目组与项目各干系方沟通不良是影响项目顺利进展 的一个非常重要的因素。（4）缺乏领导支持风险。上层领导的支持是项目获得资源（包括人力资源、 财力资源和物料资源等）的有效保障，也是项目遇到困难时项目组最强有力的 “后台支撑”。（5）进度风险。项目对进度都有明确的要求，有的还非常苛刻，项目进度 的延迟意味着违约或市场机会的错失。（6）质量风险。用户对项目质量有明确要求，有的也很高，如果项目组成 员要全时在不同层面关注并保持质量，避免质量风险。（7）系统性能风险。项目一般都有性能要求，当系统性能要求较高时，项 目组就需要关注项目的性能风险。（8）工具风险。项目开发和实施过程，所必须用到的管理工具、开发工具、 测试工具等是否能及时到位、到位的工具版本是否符合项目要求等，是项目组需 要考虑的风险因素。（9）技术风险。技术因素是一个非常重要的因素，项目组一定要本着项目 的实际要求，选用合适、成熟的技术，不能无视项目的实际情况而选用一些虽然 先进但并非项目所必须且自己又不熟悉的技术。（10）团队成员能力和素质风险。团队成员的能力（包括业务能力和技术能 力）和素质，对项目的进展、项目的质量具有很大的影响，项目经理在项目的建 设过程需要实时关注该因素。(H)团队成员协作风险。团队成员是否能齐心协力为项目的共同目标服务,是影响进度和质量的关键因素。(12)人员流动风险。项目成员特别是核心成员的流动给项目造成的影响是 严重的，人员的流动轻则影响项目进度，重则导致项目无法继续。(13)工作环境风险。工作环境(包括办公环境和人文环境)的好坏直接影 响项目成员的工作情绪和工作效率。(14)系统运行环境风险。目前，大部分项目系统集成和软件开发是分开进 行的，系统赖以运行的硬件环境和网络环境的建设进度对软件系统是否能顺利实 施具有相当大的影响。(15)分包商风险。部分项目可能会涉及到将系统的部分功能分包出去，这 时项目组就需要关注项目的分包商风险。项目从计划到实施都存在着这样那样的风险，上述风险是从整体对可能出现 的情况进行的归纳，针对本项目而言，风险识别重点关注以下三个方面。一是需求风险。主要是指需求不确定性的风险，比如：由于系统使用者对系 统将要实现的目标是模糊的、笼统的，而对于具体的需求不能准确描述；而且系 统受使用者的个人习惯、知识背景影响较大，在系统范围和系统性能方面也存在 着很多不确定性因素；另外，由于企业在发展过程中不断进行的业务流程调整等, 都会给系统带来较大的需求不确定性风险，甚至是陷于需求膨胀的状态，便系统 难以满足使用者的需求，难以适应企业发展的需要。二是管理风险。项目管理本身就是一项具有风险性的工作，而数据分析项目 由于是通过对其他系统的整合，来获取分析所必需的数据，其数据来源可能是多 个相关系统，对项目的协调管理工作要求更高。因此，其管理风险主要表现在: 工作缺乏计划性或是有计划而不能严格执行;管理工作的随意性、盲目性比较大; 没有充分意识到风险管理的重要性，因而没有充分分析可能存在的风险和应该采 取的风险应对策略；项目团队内部沟通不够，导致开发人员对系统设计的理解存 在偏差等等。三是技术风险。基于SOA的地理信息系统技术发展较快，相对也比较成熟, 如何将地理信息系统技术与二三维态势显示结合起来，用丰富高效的分析工具和 展现手段，展示态势信息，是本项目的主要技术风险。要重点关注技术的适用性和实用性，不盲目追求高新和炫目，把技术落到实处，及时识别从用户需求到技 术实现中不切实际的想法和做法。风险分析在进行风险分析时，要逐一考虑每个识别出的风险，并对风险出现的可能性 和严重性作出判断，最后根据风险严重程度的大小按顺序制成表格，如下表所示。随着有关风险可用信息的增多和风险管理计划的实施，风险出现的可能性和 对这一风险的影响后果。表5风险分析表风险出现的可 能性后果开发机构的财务出现问题，必须削 减项目预算小灾难性招聘到不符合项目技术要求的职员大灾难性在项目的非常时期，关键性职员生 病中等严重要复用的软件组件有缺陷，限制了 项目的功能中等严重需求发生变化，主体设计要返工中等严重开发机构重新调整，由新的管理层 负责该项目大严重系统使用的数据库的处理速度不够 快中等严重低估了软件开发所需要的时间大严重CASE工具不能被集成大可容忍客户不了解需求变更对项目造成的 影响中等可容忍职员所需的培训跟不上中等可容忍低估了缺陷的修补率中等可容忍低估了软件的规模大可容忍CASE工具产生的编码效率低中等可以忽 略133风险控制措施风险分析活动分析的目的在于建立处理风险的策略。而风险规避的最好方式 是把风险控制在项目启动阶段，把损失减小到最小程度。基于以上对风险的识别 与分析，本项目采取以下措施来规避或减小风险：一是建立畅通的沟通渠道和沟通策略。需求的不确定性风险很大程度上是由 沟通不畅引起的。因此，在需求调研阶段，要多和应用部门沟通，了解他们真正 的需求，最好能将目标系统的模型向应用部门演示，并得到反馈意见，直到双方 都达成共识;形成双方认可的验收方案和验收标准，并做好变更控制和配置管理, 尽量降低需求不确定性风险。二是配备高素质的项目管理人员。安排具有丰富的项目管理经验，具备系统 项目管理知识的人员来担任项目经理，通过制定有效的项目管理计划，并认真执 行落实，提高项目的可控性。风险不是静止的、一成不变的，它会随着项目状况 的变化而变化，因此，风险管理必须被作为一个日常的正式活动列入项目工作计 划，成为项目管理人员的一个重要工作。三是建立一支协作高效的项目团队。明细项目整体管控、业务与需求分析、 技术与系统开发、测试与安装运维等各团队的职责，形成一个合作的项目工作团 队，共同理解项目目标、建设内容和建设方法，严格执行项目实施各项制度，熟 练运用项目管理、系统开发、系统测试工具，顺畅沟通，密切协作，从整体和全 局的角度分析解决问题，共同控制项目进度，共同为项目质量把关。四是制定科学的风险管理计划。从风险管理的角度对项目规划或计划进行审 核，建立“风险清单”，对每个可能存在风险的表现、范围、时间做出尽量准确 的判断并对风险进行监控，提前做好应对准备。如针对需求风险，要制定相应的 需求变更控制；针对技术锁定风险，要安排的核心技术人员全程参与开发等。五是选择合适的开发技术。虽然在系统设计时需要考虑新技术的发展和技术 的先进性问题，但“最好的不一定是最合适的，最合适的才是最好的”，如果项 目组的人员对所需开发技术不熟，在满足业务需求的前提下，尽可能采用熟悉的 技术来减轻项目在成本或进度方面的影响，也可以事先进行培训来减轻对项目的 影响，以避免因技术瓶颈导致的项目失败。六是采用快速原型和迭代模型进行开发。尽管前期会对应用部门进行需求调 研和需求分析，但应用部门的需求往往会随着时间的推移、业务发展的变化而有 所变化，因此，研发团队要强调敏捷开发，在确保质量的情况下，缩短上线周期， 尽快满足用户需求，并持续为用户提供有价值的软件。同时，以迭代法取代传统 的瀑布法开发过程，加强各阶段与用户的沟通，对各个功能逐步完善，可以降低 各种不确定因素带来的实现风险，每个迭代过后，软件都向目标接近一步，即使 目标发生改变，迭代模型也比其他筛选和建立目标的开发模型，更便于转向新目 标。项目风险管理是一种特殊的规划方式，对任何一个软件项目，我们可以有最 佳的期望值，但更应该要有最坏的准备一一只有正视风险，我们才能更好地管理 风险，规避风险，直至消除风险，获得项目的成功。1.4 培训服务本项目产品面向平台开发，公司将对客户技术人员进行完整有效的用户培训, 培训提供不少于1次的系统培训，每次培训人数不限，每次培训时间安排不少于 1个工作日8个学时。培训将对招标方的各类管理和技术人员提供免费且完整有 效的系统使用管理、运行维护和调试运行支持培训服务，使招标方的系统管理员 能独立完成系统的日常维护、系统性能调优、系统排故工作，同时提供完善的系 统文档和相关的培训资料作为平台产品提供商和应用系统实施商，产品和应用系统的培训是进行系统 配置和维护的必要步骤，将主要针对系统管理和维护人员、系统开发人员进行培 训，使其掌握仿真模型组件库的安装、配置和使用，系统的配置和维护方法，应 用系统的开发方法，熟练查阅各种技术文件和维护手册的能力。1.4.1 4.1培训目标通过对系统的一系列操作培训，使参与培训的相关人员熟练掌握系统操作过 程及步骤，利用测试环境进行实际的操作演练巩固培训成果，借助培训考核系统 对培训的效果进行核查，并通过在线帮助系统进行实时性的操作指导，为系统的 顺利上线提供保障。主要培训目标包括：(1)掌握开发平台的安装、配置和使用(2)掌握应用系统的配置和维护方法(3)掌握应用系统的使用方法(4)熟练查阅各种技术文件和维护手册的能力1.4.2 培训方式系统培训主要采用以下几种方式进行：(1)研讨式交流对系统的业务模型、需求规格、功能精化设计、数据模型设计以及系统运行 维护等采用研讨式交流，以加深对标准化设计系列成果的共同理解，业务能力得 到提升，思想上达成一致，促进信息化人才梯队建设。(2)集中授课培训对系统的具体操作人员将采用集中授课方式进行培训L让各培训对象根据自 己的实际工作需要熟练掌握跟自己岗位密切相关的操作步骤和方法，编制教材供 学员课前学习，课后回顾，为系统的正式上线做好充分的人力准备。(3)指导咨询培训在系统上线、运行和维护期间，对各级应用人员进行指导、咨询和进一步培 训I,对操作中的具体问题采用电话、邮件、即时通信工具等方式进行解答和交流， 并通过在线帮助系统提供实时的操作指导。为保证培训效果，将提供不少于一次的集中培训，多次研讨式交流，以及随 时的指导咨询。143培训内容项目实施在不同的项目阶段需要完成不同的培训，具体分为业务交流培训、 应用操作培训、技术及系统维护培训等。现场培训包括集中培训和个别培训，集中培训完成相应的培训内容，个别培 训由实施人员负责，根据培训对象需要制定培训内容和计划。提供专门制作的培训教材，培训教材与提供的最新版本的软件系统相一致。(1)业务交流培训包括对平台系统和各业务分系统的交流培训，采用研讨式交流的形式，主要 在需求调研期间开展。(2)应用操作培训系统的用户是应用操作培训的主体，因此每个应用操作培训都需要具有针对 性，必须根据培训目标和内容确定相关的用户，否则培训效果将大打折扣。所以 培训的内容需要与参与培训人员的岗位进行搭配，必须充分考虑到用户的实际工 作情况进行合理安排。因此，应用操作培训主要以业务类为单位设计培训课程，以集中式授课形式 开展。应用操作培训包括对平台系统和各业务分系统的应用操作培训。(3)技术开发培训指对系统的软件实现方面具体细节的技术培训I,使参与培训的人员掌握利用 平台软件进行业务构件标准化设计和开发的方法，培养出一批业务软件设计和开 发专业人才，为系统的建设和升级提供保证。(4)系统维护培训指对系统管理方面具体细节的技术培训I,使参与培训的人员掌握系统应用部 署和管理维护的方法，培养出一批懂业务、通技术的系统化专业人才，为系统的 运行维护提供保证。1.4.4 培训计划针对本项目所涉及的产品和技术，公司负责提供免费培训服务。提供给客户 详细的培训教材，培训教材应包括典型的案例，且该案例可在相关系统设备上进 行练习和实际操作。培训采用集中授课和分散答疑辅导两种模式，集中授课参加 培训的人数不受限制，提供不少于1次的系统培训，每次培训人数不限，每次培 训时间安排不少于1个工作日8个学时。1.5 售后服务1.5.1 故障处理措施和应急处理方案(1)对于一般故障情况，我公司在接到故障告知后，半小时响应甲方提出的需求，并在24小时内提供解决方案。（2）对于紧急突发故障或重大故障，我公司将调动精锐力量，以充足的能 力应对故障；同时取消休假，尽可能早的完成任务。1.5.2 售后服务措施我公司有以下具体实行的售后服务措施：（1）为了保障售后服务工作，我公司将建立专门的技术保障项目小组来支 持运行售后服务工作。（2）项目负责人为技术保障项目小组组长，组员包括项目技术负责人负责 技术支持、商务负责人负责资源协调、调试人员负责调试和故障检修，研发人员 负责技术方案变更。（4）自验收合格之日起质保期3年。（5）我公司对提供的货物在质保期内，因产品质量而导致的缺陷，必须免 费提供包修、包换、包退服务。（6）我公司须在“三包”范围内无偿提供该货物的技术培训和技术支持。（7）我公司就所提供的货物必须在半小时内响应，24小时内到达现场，维 修并解决问题。（8）我公司将提供一份易损易耗件清单，并具有长期提供货物易损耗零配 件的能力。（9）我公司负责用户现场安装调试验收和免费培训。培训内容包括软件安 装、系统使用、系统维护等内容。1.6 商务及其他要求161付款方式付款方式：合同生效后支付全额的30%,验收合格后支付全额的60%,余下 10%作为质保金一年后结算。1.6.1 保密义务我公司对本项目尽到保密义务，不得以任何方式传播本项目的技术资料，如 我司未中标应对招报价过程中产生的所有文件资料及时进行销毁，不得留存相关 信息资料。若发生泄密事件，我公司愿承担相应法律责任。1.6.2 专利权要求专利权要求：我公司保证使用方在使用该货物或其任何一部分时，不受第三 方侵权指控。1技术方案1.1 项目实施与管理1.1.1 项目管理原则（1）使用项目管理方法、工具和完善的项目进度计划监控跟踪管理体系， 使各项目子工作流和子任务能高效率地分发和配合。项目管理人员有条不紊、及 时地参与问题的解决和可能产生的延期，调动资源来解决问题，保证整个项目进 度按照计划进行。（2）提升项目实施的能力，通过跟踪项目的绩效和对于项目技术、财务状 态和进度的检测和管理，来达到循环提升的效果。（3）完善的项目质量保证体系以保证项目质量，保证项目进度。（4）降低项目成本，通过有丰富经验的团队管理人员，降低重复劳动、提 高工作效率并减少可能的过失，来降低项目不必要的付出。1.1.2 项目周期管理依据项目进度要求，本项目研制周期为合同签订后18个月，计划在签订合 同后1个月完成软件概要设计,在签订合同后15个月内完成软件初步开发任务, 提交试用版给用户试用，用户提出改进意见后，在签订合同后18个月内完成开 发完善修改，组织进行软件验收。系统研制总体计划具体进度安排如下:（1）合同商议阶段（2天）；（2）概要设计阶段（1个月）;（3）详细设计阶段（2个月）;（4）编码调试阶段（12个月）;（5）试用完善阶段（2个月）；（6）交付验收阶段（28天）。1.1.3 项目人员安排公司成立专门的项目领导和实施组织团队，在公司领导的统一指挥下完成项 目工作。具体项目实施团队及人员职责分工如下表所示。（项目核心成员需具有 同类项目的实施经历，在下表项目经历中填写，其他人员可不填该项）114 项目阶段管理通过质量管理责任的分配，通过如下几个方面来进行质量保证的实施过程:1.1.1.1 目进度管理项目计划的制定为工程项目实施、管理和支持工作、项目进度、成本、质量 及过程产品的有效控制打下了良好的基础，以便所有相关人员能够按照该计划有 条不紊地开展工作；制定项目计划，必须获得相关干系人的认可，并以此作 为项目跟踪的基础。项目进度是项目进行是否顺利的最直观表现。制定合理的项目计划首要前提 是选择从事类似规模和类似业务项目的有经验的项目负责人参加制定项目进度 计划。项目计划由项目负责人制定，由项目各小组组长、项目成员、质量保证人员 参加一起进行评审。评审过程主要讨论项目计划的可行性，对其中不合理的地方 提出修改意见，对计划中不合理的地方进行修改完善，并由质量保证人员对其结 果进行跟踪处理，以确保项目计划完整性、可行性，项目计划评审通过后，交由 配置管理人员进行配置管理。在计划实施过程中，按项目计划中里程碑为界限，将整个开发周期划分为若 干阶段。根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成 的任务时间，动态跟踪和动态调整，以利于项目质量保证的实施。实际运作中，质量保证人员在对项目执行过程进行检查时，对于发现的项目 偏差，以质量审计报告的形式提交项目负责人。由项目负责人组织人员对计划进 行维护，对于已经变动的项目计划，由配置管理进行配置管理。1.1.1.2 需求分析管理需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的 经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是 困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。 从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放 大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发 影响系统的工期和系统的质量。本项目中，将邀请招标方参与需求调研，以便保证需求调研质量，同时形成 用户需求说明书。需求评审时会同双方管理层、项目实施层共同进行，对于通过 用户确认的需求，交由配置管理员形成需求基线。用户需求在招标方确认后，由系统分析人员形成软件需求分析报告，同时对 软件需求分析报告进行评审，对于评审通过的软件需求分析报告可以交由测试人 员进行测试计划和测试用例的编写。对于开发过程存在的需求变动，招标方填写变更申请单发给项目经理，在质 量保证人员参加的情况下，对这个变更进行评审，由项目经理组织项目组成员一 起讨论实施变更的可行性及实施后所带来的影响，对于影响小的变更直接记录， 大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同 步变更。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这 时，我们将变更报告提交给招标方并召开协调会议，讨论变更取舍问题或是项目 进度变更问题。决定变更之后，由项目负责人组织实施变更，测试人员检测变更结果，而质 量保证人员监督变更实施过程，并协助配置管理员对变更后的成果进行配置管理。 变更实施完后，运行前还需要协助用户一同测试并由招标方签字后同意方可上线。1.1.1.3 系统设计管理优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的 设计方法，需要针对项目的结构、项目的特征和用户的需求来分析。本项目中将 安排我公司高级系统架构师担当项目总体设计师，汇同总体设计组完成系统设计。另外对公共类模块的开发。由总体设计组通过对用户需求的仔细研究，尽可 能的识别出公共类，并进行定义和设计，以减少重复工作。对于项目组提供的设 计文档，由项目经理组织，质保小组成员参与，对其设计文档进行评审，及时发 现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、 测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发, 提供项目组。最后交由配置管理员进行设计文档的版本控制。1.1.1.4 统实现管理系统实现的目的是依据系统设计文档，由程序员进行程序编写，以便实现设 计要求，系统实现过程中，开发人员需要对模块进行代码走查和交叉单元测试, 以保证模块代码质量。软件实现也就是代码的生产过程。根据上一阶段形成的设 计文档，程序员在完成代码之后，可以开始编码并且进行代码走查和单元测试。 对于测试完成的程序可以交由配置管理人员进行配置管理。1.1.1.5 测试管理系统开发涉及到一系列的过程，每一个过程都有可能引入缺陷(Bug),本系 统质量的好坏直接关系到正常使用和日后的维护。在开发过程中，我们将质量控 制贯穿于所有阶段和所有参与系统的人员中，包括系统分析、设计和编码。分阶 段的评审和测试是软件质量的有力保障。系统存在平台测试和应用系统的测试以及最终的测试。由于测试也存在协调 的问题，如错误具体定位，在应用系统发现一个错误，到底是应用系统的自身的 错误还是中间件存在的错误，需要测试人员进行准确的判断。为了达到良好的测试目的，本系统测试工作由测试组来完成。从测试方法上来说，分为黑盒测试和白盒测试：黑盒测试：着重于测试软件系统的外部特性；根据系统的设计要求，每一项 功能都要进行逐个测试，检查其是否达到了预期的要求，是否能正确地接受输入, 是否能正确地输出结果。白盒测试：由于软件的所有源代码都要由项目组成员编写，对其内部的逻辑 规则和数据流程，都要进行测试，以检查其代码编写是否符合设计要求。从测试策略上来说分为集成测试和系统测试：集成测试：在所有模块都通过了单元测试后，将各个模块组装在一起，进行 组装测试，用于发现与接口相联系的问题。在通过组装测试后，将经过单元测试 的模块组装成一个符合设计要求的软件结构。系统测试：在本项目通过了以上的测试步骤后，与其它系统元素（如硬件服 务器、网络系统等）进行集成测试和系统级的确认测试，将各种可能的缺陷完全 排除掉，从根本上保证系统的长期稳定运行。系统维护管理本项目中，技术支持小组的任务一方面是保证对项目客户的跟踪服务，另一 方面是确保该项目的技术咨询工作。系统维护期，对于一般性的错误，如操作不当等引起的问题，全部由技术支 持小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制 流程，填写变更申请，经项目组讨论分析可行方案在由技术支持小组实施，通过 测试后方可提交用户。在这个过程中质量人员需要对维护过程和维护记录单进行 检查。项目成果交付需提交的成果如下表:表4成果表序号成果名称数量1实验平台硬件系统1套2实验平台软件系统1套3实验平台用户手册1套1.2 质量保障管理质量管理内容1.2.1.1 编制和评审质量计划制定质量保证计划：依据项目计划及项目质量目标确定需要检查的主要过程 和工作产品，识别项目过程中的干系人及其活动，估计检查时间和人员，并制定 出本项目的质量保证计划。质量保证计划的主要内容包括：例行审计和里程碑评审，需要监督的重要活 动和工作产品，确定审计方式，根据项目计划中的评审计划确定质量保证人员需 要参加的评审计划。明确质量审计报告的报送范围。质量保证计划的评审：质量保证计划需要经过评审方能生效，以确保质量保 证计划和项目计划的一致性。经过批准的质量保证计划需要纳入配置管理。当项 目计划变更时，需要及时更改和复审质量保证计划。1过程和工作产品的质量检查根据质量保证计划进行质量的审计工作，并发布质量审计报告。审计的主要内容包括：是否按照过程要求执行了相应的活动，是否按照过程 要求产生了相应的工作产品。本项目中对质量的控制主要体现在不同阶段的审计 当中。121.3不符合项的跟踪处理对审计中发现的不符合项，要求项目组及时处理，质量保证人员需要确认不 符合项的状态，直到最终的不符合项状态为“完成”为止。122质量管理职责我公司在开发项目上按照规范化软件的生产方式进行生产。每个项目除配备 了项目开发所需角色外，还专门配备了质量保证小组、配置管理小组、测试小组 来确保质量管理的实施，确保各阶段均严格落实“问题归零”要求。122.1质量保证小组职责质量保证小组作为质量保证的实施小组，在项目开发的过程中几乎所有的部 门都与质量保证小组有关。质量保证小组的主要职责是：以独立审查方式，从第 三方的角度监控软件开发任务的执行，分析项目内存在的质量问题，审查项目的 质量活动，给出质量审计报告。就项目是否遵循已制定的计划、标准和规程，给 开发人员和管理层提供反映产品和过程质量的信息和数据，使他们能了解整个项 目生存周期中工作产品和过程的情况，提高项目透明度，从而支持其交付高质量 的软件产品。质量保证人员依据质量保证计划，通过质量审计报告向项目经理及有关人员 提出已经识别出的不符合项，并跟踪不符合项的解决过程，通过审计周报或者审 计月报向项目经理提供过程和产品质量数据，并与项目组协商不符合项的解决办 法。质量保证小组的检测范围主要包括：项目的进度是否按照项目计划执行，用 户需求是否得到了用户的签字确认，软件需求是否正确的反映了用户的需求，是 否将每一项用户需求都映射到软件需求；系统设计是否完全反映了软件需求；实 现的软件是否正确的体现了系统设计；测试人员是否进行了较为彻底的和全面的 测试；客户验收和交接清单是否完备；对于系统运行中出现的问题，维护人员是 否记录了详细的维护记录；配置管理员是否按照配置管理计划建立了基线，是否 严格控制变更过程，是否对配置库进行了维护。1.2.2.2 配置管理小组职责配置管理活动的目的是通过执行版本控制、变更控制、基线管理等规程，借 助配置管理工具的使用，来保证整个生命周期过程产生的所有配置项的完整性、 一致性和可追溯性。配置管理是对工作成果（阶段工作成果和产品成果、进展状 态成果）的一种有效保护形式，是反映项目及其工作产品的过去、现在、动态的 资料和数据集中管理体现。配置管理小组的主要职责包括：根据项目计划制定配置管理计划，建立配置 库，为项目组人员分配配置库权限，创建需求、设计、开发、测试、交付阶段的 基线。当纳入基线库的工作产品发生变更时，严格按照配置项变更控制过程执行 变更，变更后建立新的基线。1.2.2.3 测试小组职责作为质量控制的主要手段，如同软件开发一样，测试在执行之前，测试小组 制定软件测试计划、测试用例的编写和执行工作。本项目中，测试可以分为如下几种类型：代码走查、单元测试、集成测试、 系统测试。为了保证程序的质量，开发人员需要对同伴的代码进行代码走查，同 时对自己编写的程序进行单元测试，确保程序编译、运行正确。测试人员根据软件需求分析报告进行软件集成测试用例和系统测试用例的 编写。对编写完成的测试用例提交项目组进行评审，同时质量保证人员对评审过 程和工作产品进行监测。测试人员根据测试计划和测试用例执行测试用例，并对发现的缺陷进行记录, 只有这样才能确保项目组开发的软件产品满足用户需求。在完成集成测试之后， 可以进行软件系统测试，系统测试包括对软件进行功能测试、性能测试、安全测 试、压力测试。只有进行了系统测试软件测试才是完整的。系统测试在本项目中 占有重要的地位,性能要求有可能改变软件的设计,为避免造成软件的后期返工， 测试在性能上需要较大的侧重。1J风险管理措施在项目开发过程中存在固有的不确定性，这些不确定性主要产生于：宽泛定 义的需求（需求随客户要求的改变而改变），对软件开发所需的时间和资源的估 算困难，以及项目组成员技术上的差异等。因此，风险管理过程是一个贯穿项目 全过程的迭代进行的过程，从最初的计划制定开始，项目就处于被监控状态以检 测可能出现的风险。随着有关风险信息的增多，需要重新进行分析，需要确定风 险的优先级。对风险规避和应急计划要进行修正。本公司将从风险识别、风险分析和风险评价去认识项目风险，并以此为基础 合理的地使用各种风险应对措施、管理方法技术和手段，对项目风险实行有效控 制，妥善处理风险事件造成的不利后果，以最少的成本保证项目总体目标实现的 管理工作。项目风险管理的重要性很大程度上就是避免资源的浪费。