企业管理北大青鸟：项目开发计划.docx

《企业管理北大青鸟：项目开发计划.docx》由会员分享，可在线阅读，更多相关《企业管理北大青鸟：项目开发计划.docx（34页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、企业管理北大青鸟：项百开发计划招聘网站设计项同开发计划第一局部、引言L1编写的本计划编写目的是更清晰地理解招聘网站设计项钉的业务要求，明确工程需要做的工 作，并为保证工程在预算、日期和质量方面的要求提供可执行的依据，包含了范圉、战度安 排、质量控制、预算和变更等在内的明确的计划和安排，以切实能保证项口能在控制中完成。1.2背景说明：A、软件系统的名称：招聘网站设计工程B、任务提出者：668Job在线科技开展有F艮公司开发者：北大青鸟Aptech产品开发部本项口将实现668Job的原型局部，并且在该原型的基础上此行功能的犷展和需求的界 京，最终完成的版本将在ww.668Job .cn网玷上使用。

2、提供互张网上的求取、招聘誉记和 搜索服务。C、本条统将存储用户信息，668Job将与其他的余统共享这些注册信息，共享的系统可能是 668Job电子邮件系统、668Job电子杂志分发系统。这些系统之间不提供应用程序级别的接口，数据共享通过SQLServer数据库表的公共访 问来实现。本系统将使用SQL Server 2000作为数据库存储条统，SQL Server 2000企业版将由 668Job 6行购买。1.3定义668Job668Job在线，全称是668Job在线科技开展有F艮公司；（说明：1、以上的工作，可以在更细的层次上进行分解，例如17,可以分别为查询界面、增加的界 面和删除的询问词

3、的设计等，系统测试可以分斛为测试平台的搭建、测试用例的编写、条统 各功能点的测试、测试记录的埴写、测试忍结和总结报告等多个工作单元。2、以上的工作分斛，不存在时间先后的次序。）按照工作分解结构，取责分配如下：J JJj人员工作包及说明J张总明董树声杨城莫青雁李明生C1：需求调查SPPAC2：编写需求文档PAC3：工程初步评估和初步安排会议APPPPC4：工程正式启动会议APPPPDI ：计划会议、工程专题讨论D2：汇总和编写工程计划D3：项口计划的审核和分发执行D4：系统的名体设计相关内家D5：数据库设计相关内衮D6：模块设计：数据库实现、访问控制脚本D7：模块设计：页面逐转和页面样式D8：模

4、块设计：个人数据管理D9：模块设计：数据查询D10：整理和编制详细设计，作为编码的依据D11：设计评审11：模块实现：编吗实现D612：模块实现：编吗实现D713：模块实现：编吗实现D814：模块实现：编吗实现D915：准备数据库和测试数据16：单元测试和调试：1117：单元测试和调试：1218：单元测试和调试：1319：单元测试和调试：14110： 16、17、18、19之间的接口测试Ill：条统的组合和条统测试112：系统测试报告和反响113 ：郝助工程和帮助文件制作114：安装工程和安装配置115：安装包测试116：编写配置指南117：编写功能和操作说明118：中期评估119：后期评估T

5、h文件归档T2：运行测试T3 ： B测试和峰值测试T4：程序、界面、手册的反债和修订T5：功能讲斛、管理员培训T6：工程总结T7：工程结束和团队解散参与人员；A负责人员；S确认审核人员；32接口人员负责接口工作的人员及他们的取责，包括：A、工程经理负责张忠明负责同用户的组织接口事务，包括变更和事务协调等；系统分析员董树声负责用户的技术接口，包括一些技术方案的演示和确认；产品专员李明生负责同用户的人际接口，包括文档、密科、垓训和一些事务性的沟通。B、项口经理负责张惠明负责组织内部的接。，包括工程选度报告，济源协调等；C、工程经理负责张惠明负责处理合同方面的接口；以上的接口事务，在上面的职责分配图

6、中已经进行了表述。3.3进度最后的工程网络图如下：完成工程至少需要的时间用红色的线表示，工程的关键路彳空为：1 - 2-3 -4 - 10-11- 14-15-18 -22 -24-25 -26 - 32 -33 -34-36-37-38 对应的时间为：3+3+4+5+4+1 + 1+3+5+2+5+4+4+1+2+6+4+1 + 1=58 （工作日） 预留20%作为整体浮动时间，实际需要的工作日为70。在并行一些工作的条件下，工程预计完成的时间在三个月左右。C2 3工程的开始日期为2003 -9 一 1日，工程的里程碑（阶段点）时间:ftftftftft.9/89/2010/1211/411

7、/24（说明：可以制作一张工程的日历，说明工程针对于日期的更详细的信息，这可以借助于Microsoft Project 2000等工程管理软件来完成，此处略。）3.4预算按照以上工作包的估算如下表:（单修 元） 工作包及说明办公费差旅希机时费咨料费设备希其他合计C1：需求调查2000100020020010004400C2：编写需求文档20002000C3：初步评估100050006000（件间的其他单项费用估算略）合计10000300010000200020000900054000分阶段的开发费用统计如下表:阶段 名称人工据用(人月)机时(小时)其他(元)工程 管理余统分析软件 设计编程 调

8、试数据 录入其他 人工终端 小时主机 小时外存 .史间其他 费用出差 资料其他 希用SA&SSDRAPDDDCD&UUTIT&STIS&A CTSSDD(说明：以上实际数字的填写略。)SA&SD(System Analysis & Software Definition Phase)：系统分析与软件定义阶段；RA(Requirements Analysis Phase)：需求分析阶段；PD(Preliminary Design Phase)：概要设计 阶段；DD(Detailed Design Phase)：详细设计阶段；CD&UT(Coding & Unit Testing Phase)：编

9、外与单元测试阶段；IT&ST(Integrating & System Testing Phase)：组装与条统测试阶段；IS&AC(Installation & Acceptance Phase)：安装与险收阶段；TSSD(Total Software System Development Phase)：整个软件余统的开发阶段。(说明:1、以上的估算分别按照各项活动的累计进行估算；并且接软件开发的不同的照阶段给出一 个大体的估算数据，可以只用一种估算方法作为依据；2、项q的预算和估算可能由专门的工程财务管理系统来选行，工程计划中只要对该文档选行引用就可以了；3、得出的不同阶段的估算结果，可以

10、绘制本钱曲线，以对执行阶段的本钱进行控制，一般 的本钱曲线应该是一条类似于S形状的曲线，下列图是预算形成的本钱基准和实际花费的本钱 的比照曲线：累计本钱4、本钱比照曲线、本钱偏差是要求项百经理在工程进行过程中需要控制的一个重要方面；5、单项本钱的估算一般没有考虑管理费用，在实际工程运行的时候，需要在总金额上加上 一定比例的管理费用；例如以上管理希用的比例如果是20%,那么实际的费用是64800；6、一般的项自，都对本钱叔一定的储藏金，例如，以上估算结果的储藏金假设是10%,考虑 管理费用，最后的总预算是71280。）35关键问题影响整个工程成败的关键问题、技术难点和风险包括:风会类别风隈描述可

11、能性影响使用提嵩生产率工具所产生的讨划节余被过高地估计了。0.40.9计划、资源和产品定义都受客户或上级管理部门支配，而不平衡0.80.3预定日期提前，但没有对产品范围或可用资源作相应调整。0.60.6产品比估计的大（从准那么、功能点、模式等方面来看）。0.90.5管理审查/决策过程比预料的慢0.80.5非技术第三方任务花去的时间比预料的长（颔算审枇、法律审查 等人0.80.5最终和户坚持新要求。0.90.8即使递交的软件符合所要求的全产规格，但商业用户将不接受该 软件。0.80.9商业用户审查/决策过程比预料的慢。0.60.5最终用户最终发现产品不能令人满意，要求重新设计和重做。0.60.9

12、小组成员之间的冲突导致通信差、设计差、界面错误和额外工作。0.60.7人事工作比预料的慢。0.70.6正式手续太多（管傣性遵守软件政策和标准，。0.80.7开发不具不像预料的那样有效，开发者需要时间来创立有关工作， 或改用新工具。0.60.8r说明:L 以上列出的是可能影响项月开发，包括此度.本钱和质量的各方面最重要的一些风险和 对该风险的概率、影响的估计；2、以上的风险，是软件开发的风险对照表的一局部，在其他的工程开发中，风险分析也可 以采用风险对照表确定风险的概率和影响程度；然后在根据这些可能性和影响程度来到断是 否采取预防措施；上图中，分别使用了不同的颜色来反响风险的最后的程度。3、软件

13、开发风险对照表如下：风险类别风险描述可能影响规划风险讨划是根据使用工程问题专家CSEMJ的情况制定的，但是这 些成员没有得到。讨划言哆是必要的任务。使用提高生产率工具所产生的讨划节余被过高地估计了。讨划、济源和产品定义都受家户或上级管理部门支配，而不平 衡。讨划是乐观的“谈佳实例”（而不是现实的“预期实例”人计划是根据使用具体小组成员的情况制定的，但这些小组成员 没有得到。预定日期提苛，但没有对产品范囹或可用资源作相应调整。一项任务的推迟使附属任务一并推迟。作为对计划到计划的失察作出反响而作出的重新估讨过于乐 现，或忽略了工程历史。过大的计划压力降低生产率。项百规划在压力下被放弃。规划太差，不

14、能支持需要的开展速度。不能在分配的时间内制迨规定尺寸的产品。产品比估计的大（从准那么、功能点、模式等方面来看人努力比估计的大（队准那么、功能点、模式等方面来看人准那么或等级咨料库质量差，造成额外的测试、缺陷纠正和重做 工作。产品的不熟悉方面要花费比预料的更多的时间来设计和执行。任务先决条件（例如培训、其他工程的完成、获得工作许可证） 不能检时完成。组织风险产品缺少有效的高级管理发起人。产品在不明不由搁置的时间太长o解雇和削臧降低小组的能力。管理或销售部门坚持延长计划的技术决定。低效的小组结构降低生产率。管理审查/决策过程比预料的慢。预算削减打乱工程规划。管理部门作出挫伤开发小组的积极性的决定。

15、非技术第三方任务花费的时间比预料的长（做算审枇、法律审V 查等人规划太差，不能支持需要的开展速度。工程规划在压力下被放弃，导致混乱的、低效的开展。管理部门对豪情比对准确的状况报告强得更多，从而削弱它发 现和纠正问题的能力。未能到达里程碑。商业用户坚持新要求。最终和户坚持新要求。即使透支的软件符合所要求的全产规格，但商业用户将不接受 该软件。商业用户所期望的发梭速度是开发者不能到达的。商业用户最终发现产品不能令人满意。没有征求育业用户的意见，因此产品最终不符合用户期望，因 此必须重做。商业用户审查/决策过程比预料的慢。缺少商业用户参与审查过程、原型和规格，因而导致不稔定的 要求。商业用户通信比预

16、料的慢。商业用户微观管理开展过程。商业用户提供的组成局部不匹配，并且质量差。最终用户最终发现产品不能令人满意，要求重新设计和重做。最终和户不买进工程，因此不提供所需要的支持。没有征求最终用户意见，因此产品最终不符合用户期望，必须 重做。客户坚持新要求。家户对规划、原型和规格的审查/决策过程比预料的慢。家户将不参与对规划、原型和规格的审查过程，或不能这样做， 从而导致不稳定的要求和希时的修改。衮户通信时间（例如回答澄清要求问题的时间）比预料的慢。家户坚持延长计划的技术决定。衮户微观控制开发过程，导致进程比讨划的慢。家户提供的组成局部质量差，导致额外的测试、设讨和整合工 作，并导致额外的客户关东管

17、理。衮户批准的支持工具和环境不兼态，性能差，或者功能缺乏， 致使生产率降低。即使遗支的软件符合所要求的全部规格，但家户将不接受该软 件。家户所期望的开展速度是开发者不能到达的。小组结构效率低下。任务先决条件（例如培训、其他工程的完成、获得工作许可证） 不能按时完成O开发者与管理部门之间的关系差，延缓决策和持续轨行。小组成员不买进工程，因而不提供所需要的性能水平。积极性和土%低，从而降低生产率。缺少所需的规格，从而增加缺陷和重做工作。员工需要额外时间来学习不熟悉的软件工具或环境。员工需要额外时间来学习不熟悉的硬件工具或环境。员工需要颠外时间来学习不熟悉的编程语言。合同员工在工程完成前离开。长期员

18、工在工程完成前离开。项月后期增加新开发人员，并且额外的培训和通信希用降低现 有小组成员的效率。小组成员不能有效的协同工作。小组成员不买进工程O所需规格缺少增加。小组成员之间的冲突导致通信差、设计差、界面错误和额外工 作。有问题的小组成员没有退出小组，从而挫伤整个小组的积极 性。工程得不到更有资格做工程的人员。工程得到更有资格做工程的人员，但是出于政治或其他原因启 用他们的。找不到项百所需要的具有关键技能的人员。关键人员只有局部时间才能得到。工程得不到足够的人员。人事工作比预料的慢。缺少管理承诺。管理费用不合理。项月缺少有效的执行发起人。很难找到关键执行人。承包人和顾问不提供容许的组成局部。WB

19、SWork Breakdown Structure, X作分解结构，面向可支付成果的工作分解；RAWResponsibility Assignment Matrix,职责分配矩阵，描述在不同阶段和人员配备情况；NDGNetwork Diagram guidelines,描述项口进度指导路线的网络图；ADM希线图法，实现NDG的方法之一；Critical Path在NDG中描述项口的关键路线；Milestone Chart项口的里程碑图，林识项6的关键进程点；受控文件北大青鸟Aptech内部已经形成标准的规范性文件，在执行过程中做强制性性的要求；L4参考资料相关的文件包括：A、 668Job招聘

20、网站设计工程分析会议备忘录；B、招聘网玷设计工程可行性分析；C、招聘网玷设计工程需求分析；D、 招聘网站设计工程概要设讨；参考资料:A、北大青鸟Aptech ACCP3.0 Sem2基于软件开发工程的毕业设计；B、国家标准工程开发计划CGB856T88）；C、莱克公司的人力济源管理工程的工程开发计划； 合同：A、招聘网站设讨工程合同2003110254；（说明：引言局部在多个文档中出现，是为了在该文档被单独阅族的情况下，提供给阅读这以背景知识，同时增强不同的文档的独立性。）外部以来风险承包人和顾问提供的组成局部质量低得不能接受，因此必须增 加时间来提高质量。雇用承包人和盛况时间比预料的长。任务

21、先决条件（例如培训、其他工程的完成、获得工作许可证） 不能按时完成O承包人和顾问需要额外的时间来学习不熟悉的软件工具或环 境。承包人和顾问需要额外的时间来学习不熟悉的硬件工具或环 境。承包人和顾问需要额外的时间来学习不熟悉的编程语言。合同员工在工程完成前离开。工程后期增加新的开发承包人和顾问，并且额外培训的通信费 用降低现有小组成员的效率。小组成员之间的冲突导致通信差、设计差、界面错误和额外工 作。关键承包人和顾问只能局部时间才能得到O非技术第三方任务花费的时间比预料的长（颔算章叔、设备采贝 购审批、弟律审查人合同类型F艮制到工程的全部要求。找到卖主解决问题的可能性炎F艮制。培训包给第三方。提

22、供包给第三方。找不到帮助部门来斛决所有问题。导致在斛决问题方面浪费大 量时间。工程依赖卖主，因此控制是单方面的。不知道的额外费用不知不觉地进入项q o技术风险意易出错的模式所需要的测试、设计和执行工作比预料的多。不能接,更的低质量所需的测试、设计和执行工作比预料的多。错误用户界面的开发需要重新设计和执行。不需要的额外软件功能（钗金）的开发犷火计划。符合产品尺寸和速度F艮制所需要的时间比预料的多，包括重新 设计和重新执行的时间。与现有余统兼参和严格要求所需的测试、设计和执行比预料的 多。与其他系统、其他复杂条统或不受小组控制的其他余统的接合 要求导致意料之外的设计、执行和测试。在多操作条统下操作

23、的要求比预料的要花去更长的时间来满 足。在不熟悉的或未经枇准的软件环境下运行造成意料之外的问 题。在不熟悉的或未经枇准的硬件环境下运行选成意料之外的问 题。对组织来说是新品牌的某种组成局部的开发所花的时间比预 料的长。对仍在开发中的技术和依赖延长计划。产品取决于政府条例，这些条例意外地改变。产品取决于草拟的技术标准，这些标准意外地改变。在直到项口后期还不知道的工程问题方面不准确的进程跟踪 结果。初步质量担保活动被忽略。在直到工程后期还不知道的质量问题方面不准确的质量跟踪 结果。正式手续太少（缺少遵守软件政策和标准）。正式手续太多（管雄性遵守软件政策和标准人不充分的风险管理不能检测到主要工程风险

24、。过分简单的设计不能解决主要问题，因而导致重新设计和重新 执行。单独开发的组成局部不能农易地加以整合，因而需要重新设计 和重做。过分复杂的设计需要不必要的和无利可得的执行费用。很差的设计导致重新设计和重新执行。使用不熟悉的方法导致额外的培训时间和重述，以确定方法的 第一次误用。产品用低级语言（例如汇编语言）来执行，并且生产率比预料 彳氐O必要的功能不能用选择的准那么或等级咨料库质量差，造成额外 的测试、缺陷纠正和重做工作。使用提嵩生产率工具所产生的讨划节余被过高地估计了。开发不具不像预料的那样有效，开发者需要时间来创立有关工 作,或改用新工具。开发工具不是根据其技术优点来选择的，因而不能提供计

25、划中 的生产率。批准的支持工具和环境不兼家，性能差，或者功能缺乏。设备不能及时得到。设备能得到，但不够用（例如没有 ，没有联网，没有办公 用品等）。设备拥排不堪，有噪声，或受到破坏。开发工具在所需时间不到核。学习新工具的时间比预料的长，或者所分的阶段比预料的多。第四局部、支持条件支持本项百的开发所需要的条件和设施包括：4.1 计算机余婉支持硬件环境：CPU： PIII750或者更嵩频率ROM： 256或者更高内存支持磁.盘：8G软件支持：开发所用的掾作条统：Windows 2000 Server SP1开发工具：Visual Studio 6.0 SP4数据库东统：Microsoft SQL

26、Server 2000 企业版、IIS 5.0覆盖测试工具：Panororna需由用户承当的工作1、需求阶段用户需要提供1名部门主管、一名熟识业务的实施人员，就产品的功能、特性和要 求进行讨论和交流，用户方在需求说明编制完毕后，需要指定部门经理级或该职别以上 的主管进行需求确认。2、设讨阶段用户方需要指派一名代表参与设计评审的会议。3、编码和实施阶段中期和后期评审,用户方需要指派一名代表参与评审的会议。4,测试和控制用户方需要提供软件测试所需要的真实的数据。5、验收和维护用户方组织参与培训的管理人员。用户方负责需要安装、B测试和峰值测试的讨算机的环境的塔也。用户方提供数据转换所要求的原始数据。

27、维护工作的要求，用户需要捺照合同条款提供相应的条件。4.2 由外单位提供的条件（不适用人第五局部，专题计划要点5. 1配置管理计划配置管理所关心的问题涉及以下三点：1、仔细定义软件系统的支付物；2、严格控制对可交付物的变更；3、确保软件余统的可交付物与既定的或者经过核准修订的可交付物相一玫。北大青鸟Aptech所有的软件工程配置管理采用标准的表格模板，并遵循了标准：计算 机软件配置管理计划规范(GB/T 12505-1990),本局部加以引用。本局部可以作为变更控制的依据。计划名称招聘网站设计工程配置管理计划工程名称招聘网站设计工程开发单传北大青鸟Aptech产品开发部工程经理张惠明引言Q的1

28、、明确“招聘网站设计工程”产品开发的范囹、特征；2、对由于用户后期提出的范围改变、在设计中没有考虑周全的特征或者性能指标、牵制 性的改变等导致的变更申请，定义变更的控制程序；3、提供验收的标准和程序，确保可交付的产品符合用户既定的要求；4、提出资源和机构的支持要求；定义1、 WBS：工作分斛结构；参考前面的说明；2、 工程网络图：工程时间估算的活动时序图，参考以上的说明；参考 资科1、招聘网站设讨工程章程；2,招聘网站设计项百需求说明；3、招聘网站设计项百概要设讨；4,本计划的范囹管理局部；5、本计划的选度管理局部；6、计算机软件配置管理计划规范(GB/T 12505-1990)管理机构所有对

29、本工程范围、变更能施加影响的机构（团体）包括：1、甲方：668Job Online；2、乙方：北大青鸟Aptech；3、相关的专家和顾问；任务相关机构、人员对配置管理的任务包括：Q1：工程范围的提出；Q2：工程范囹确实定；Q3：工程范围的更改；Q4：更改后工程范囹的核实和验证；Q5：产品特征的过程管理；Q6：可交付物的特征、性能验收比照；人员 职责 说明1、山用户方高名君、工程实施方顾问组成员_张林、林更、胡邻一组成配置管理委员会，实四配置管理程序；2、用户方_直生茎负责代表甲方进行产品范囹的提出，提供必、要的资料和数据、提 出变更申请和对可交付物的验收评估；3、项（实趋方 李明生 负责工程初

30、期的资料收集、用户面淡、问题整理、并形成正式 的需求文件；4、在计划实题阶段，所有的变更要求必须由用户方嵩名君此行提出或者认可，所有的变更必须经过变更控制委员会的讨论（正式或者非正式的沟通，并杷变 更意见及时传递给工程实施方。5、工程收尾阶段，由用户方朱青、工程实题方张惠明共同进行产品审核,并记录审核结果，传造给变更控制委员会。管理计 划实现 （变更控 制程序）配置标识A：控制和实施阶段1、左突发事件的情况下工程经理可以对工程范囹比行变更，并左事后把变更说明提交至 到变更控制委员会；2、范囹变更通常牵涉到人员、去用、进度、风隈和质量等多个方面，所有的变更都要求 对这些方面的考虑和权衡，对于引起

31、这些方面明显的变动，需要更改这些方面的设 计，并且进行相关的记录；3、工程组其他成员可以对范囹提出变更意见，但必须埴写统一的倒题报告单形成正 式的变更请求；并鼓励每一个工程成员提出新方法、新工具以提高工程的开发进度， 但严格控制在未经讨论的擅自变更，这些变更指WBS中未规定的事情；4对于农户提出的变更，视变更影响的大小，首先须经变更控制委员会正式或者非正式 的讨论，把景后的变更意见交由工程经理实施；5、WBS中对每一个消拍资源的活动都进行了定义，但并不表示WBS是不可更改的， 所有经过变更都要求反映在WBS中，并且WBS所在的主文件以修改次数进行标识；6、范国基线的变更要严格控制，除非在不能挽

32、执的情况下，范囹基线不允许变更；花国 基线变更必须经过变更控制委员会正式的会议；7、程序的变更、代吗的更新所形成的软件的新的调试版本，以版本管理程序和源代吗管 理程序进行标识和记录，工程经理要确保当前使用的板本反响了最新的变更（附件 中规定了版本和源代码记录的模版J;8、变更的内衣、质量要求须同时遵循质量计划、质量标准的相关事项；9、用户手册、培训计划要求业务或对应功能相关的人员此行书写，并且按照进度计划中 所规定的最后日期进行审核，所有的修仃意见同时应通知变更控制委员会中实施方 的成员；B ：概念和计划阶段10、在需求描述阶段，实施方把用户所要求进行开发和设计的内盗清楚的理斛并楮述 为文档，

33、景终的正式范围说明需要经过包括变更控制委员会所有成员在内的正式评 审，并作为后续工作的依据；C：收尾阶段11、产品最后的验收依据是经过变更控制委员在计划阶段批准的,危圈说明，同时有效 的是可能对产品特征明细或者未明细的正式合同，合同附件具有同等的效力；12、可能需要返工或者返修的可交付物需要用户的正式认可，同时在工程计划中加以 说明；13、在用户接受产品并要求结束合同的同时，变更控制委员会对控制绩效进行忍结， 收集相关的文件、质量记录并进行归档，在这些工作完成后宣布斛散委员会；文档:问题报告单；版本请单；源代码清单；设计评审；需求评审Microsoft Visual SourceSafe 的版

34、本标识；配置 管理 活动程序：需求评审；设计评审； 工程中期评估； 工程验收评估；配置控制1、变更控制委员会在召开项百首次会议时进行组建；2、变更控制委员会只能在用户签署正式的产品接受文件后方可斛散，变更控制委员会K 对产品维护阶段的问题不承当责任；3、变更控制委员会的成员可以增加，但在人员计划中必须做必要的变更，本计划的相关 局部也需要修订；4、变更控制委员会有义务对产品的质量进行跟练和评价，有义务提出变更请求，以确保 工程最后的产品符合使用者的要求；配置状志审查1、公司的直接工程领导负责配JL委员会工作的审查；2、配置委员会负责产品的阶段性审查和评估，这些评估包括质量记录的抽样检查、产品

35、性能特征的指标检查和相关受控文件的更改过程合法性检查；3、工程经理对产品实施过程此行控制，纠正和预防措施将是两个最常用的手段，并且在 本工程中具有工作授权体宗所有的责任，这些责任中斌重要的是控制每一个工作包 的开始时间点；配置检查以及审核配置检查和评审的权F艮只有公司谩离领导层才能进行授权，在本工程中，所涉及的 内今包括配置委员会的成立、解散需要经过公司最高领导层的正式批准。公司策嵩领导层可以在工程阶段的任何时间此行配置检查和审核，并提出更改和提 高的指令和建议，这些指令或建议必须执行或者认真考虑。对供货单 住的控制（本工程在工程启动阶段已经确定系统的绝大局部功能4已完成，牵涉的采购管理局部非

36、常少，因而 本局部的描述左此弱化，但相关的变发生后，本局部要求清晰的说明）纪录 的收 集维 护和 保存A、软件调试版本的改变，要求填写版本清单，对半成品或者成品分别进行标识，源代码和版本都 需要同时进行备份；B、所有的阶段性评审和最后的评审，都需要填写评审报告；C、单元测试要求填写单元测试记录，对存在的问题的反映埴写余统问题报告，而对问题的改 进所做的工作用修改报告单进行埴写；D、组合测试和集成测试需要准备测试讨划，测试完毕后形成刎试报告。公司具有相关的企业标准、工作规程，并在制定的同时参考IS09001 2000的一些条款，关于质量记 录的收集和维护同时要求遵循公司的规范和惯例。备注上述所提

37、到的所有质量记录在附件中都有模板，这些模板都属于公司的受控文件。5. 2质量管理计划5. 2、1、依据A、质量政策北大青鸟Aptach科技开展在软件产品设计和开发方面通过了 IS09001 2000的 规范，同时制定了质量方针和质量目标：质量方针：通过严格和规范的过程管理、丈格化的流程开发，提嵩生产效率，为客户 提供稳定、晶用和符合要求的产舄条列质量目标：在软件方面的年纯利泗到达200万元，并以每年不低于40%的比率遁增。(以上质量方针和质量q标只是一个范例，并非北大青鸟Aptech公司事实上的质量目林。)本工程同时遵循和贯彻公司的质量方针和质量口标。B、范国说明参考招聘网站设讨工程需求说明。

38、C、标准和规范在质量方面，需要遵循的标准和规范包括：A、质量管理体余标准(GB/T 19001-2000), 2000-12-18,国彖质量技术监督局；B、计算机软件产品开发文档编制指南(GB/T 8567-88J ,1988-7-1,国彖质量技术监 督局；C、计算机软件质量保证计划规范(GB/T 12504-1990), 1990-11-15,国彖质量技术监 督局；D、北大青鸟Aptech公司质量手册2002-5-1 ；北大青鸟AptechE、北大青鸟Aptech公司程序文件2002-5-1 ；北大青鸟Aptech5. 2、2程序及过程本局部规定本项口全面质量管理所规定的实题过程，在WBS中

39、，所有的活动安排都是 与质量保证相关的，因而也是WBS元素项的说明。A,影响质量的因素在本项R中，影响质量的因素可以用以下的鱼骨剌图qSHKAWAil辑图、因故分析图） 来说明:鱼骨剌图的子可以进行多层分解，下面只简要说明影响因素以及本工程在这方面的预防 措施：A、人员：人员的技能水平、工作习惯、合作往往会对项百的质量产生直接的影响；本工程组的主要成员都具有计算机工程学士学住，并且至少具备三个以上的应用软 件开发经验，主要的成员在以前的一个项U中有过成功的合作经验；B、方法和技术本工程涉及的方法和技术包括关系数据库管理、查询管理、界面等应用技术，这些 技术都是林准和成熟的技术，所选择的团对成员

40、要求具有这方面的经验，以臧少培训的 支出和技术方面的风盒；C、沟通制定完备的沟通管理计划并执行，在下一节，你可以看到沟通计划、信息分发、绩 效报告等方面的内除D、工程的意义项百取得成功所具有的意义、团队收益以及个人绩效的评估在项口的首次会议就需 要明确，离昂的士气给工程带来的好处可以直接从质量方面表达。E、变更第二局部，工程概述2.1 工作内走为完本钱工程，需要按照需求分析、设计、评审、编码、测试、安装和维护等不同的阶 段来或行，其中，本计划不考虑维护阶段所做的工作。需求分析明确本工程所开发产品的特性，并对不同的功能组选行划分，并得到用户方的 确认。设计阶段将该需求转化为计算机的模型，并且对实

41、现的功能进行分配，详细设计还将提 供各模块、任务、功能点的详细规划。评审分布在项n的阶段点，是质量保证的一局部，评审活动用于确定和调整与需求的偏 差，以确保最后的产品符合初始提出的要求。编巧实现将检照软件产品设计所描述的内参，编写代码实现软件各局部的功能。测试局部包括对实现过程中的错误的修改、功能的改进的一些活动，同时包括了各子条 统、模块、功能点的组合和连调。以上的过程中，包含了不同阶段的文档输出工作，并且上一阶段的输出，通常作为下一 阶段的输入而存在。详细的工作包和任务的分配O请参考第二局部执行计划的工作分斛结构。2.2 主要参加人员本项百全期参与人员包括：人员名称主要职责或取务成员技能说明张总明项月经理工程的规划、指导，数据库的设计董树声系统分析员条统分析，页面设计杨城程序员软件工程师，参与脚本编码、条统连调莫青雁测试工程师测试的产品化工作李明生文档工程师文档、需求分析和外部接口的一些工作变更的控制对该工程质量的影响是比拟大的，这些变更包括叱度、本钱和产品特性 方面的要求的变更，为防止不必要的变更，产品组与用户共同成立了变更控制委员会, 所有不在需求文档中说明的要素，都需要通过变更控制委员会批准。F、测试和评估尽管本工程不是一个大的工程，测试（检查）和评估依然分别分为四个局部，包括 每个独立单元的测试、单元组合测试和集成的测试，在用户使用过程中还包括一些女选 型的测