北大青鸟：项目开发计划

1、21CN图书有限公司BookShop系统项目开发计划第一部分、引言1.1编写目的本计划编写目的是更清晰地理解21CN图书有限公司BookShop系统案例分析项目的业务要求，明确项目需要做的工作，并为保证项目在预算、日期和质量方面的要求提供可执行的依据，包含了范围、进度安排、质量控制、预算和变更等在内的明确的计划和安排，以切实能保证项目能在控制中完成。1.2 背景说明：A、系统名称：21CN图书有限公司BookShop系统案例研究项目（V1.0）B、任务提出者：21CN图书有限公司开发者：北大青鸟Aptech产品开发部实现完成的系统将供Internet用户使用，所应用的网络系统是该系统的内部局域

2、网和Internet。C、本系统将是独立的系统，目前不与21CN图书有限公司的财务系统和其他资料系统提供接口，所产生的输出都是独立的。本系统将使用SQL Server 2000作为数据库存储系统，SQL Server 2000企业版将由21CN图书有限公司自行购买。1.3定义PSProduct Statement，产品说明，在此指需求分析说明；WBSWork Breakdown Structure，工作分解结构，面向可交付成果的工作分解；RAWResponsibility Assignment Matrix，职责分配矩阵，描述在不同阶段和人员配备情况；NDGNetwork Diagram gu

3、idelines，描述项目进度指导路线的网络图；ADM箭线图法，实现NDG的方法之一；Critical Path在NDG中描述项目的关键路线；Milestone Chart项目的里程碑图，标识项目的关键进程点；受控文件北大青鸟Aptach内部已经形成标准的规范性文件，在执行过程中做强制性的要求；21CN图书有限公司系统21CN图书有限公司使用的“21CN图书有限公司BookShop系统案例分析项目”最后的软件产品的简称；1.4参考资料相关的文件包括：A、 21CN图书有限公司的内部文件核准21CN图书有限公司BookShop系统案例研究项目；B、 21CN图书有限公司BookShop系统案例研

4、究项目分析会议备忘录；C、 21CN图书有限公司21CN图书有限公司BookShop系统案例研究项目可行性分析；D、 21CN图书有限公司21CN图书有限公司BookShop系统案例研究项目需求说明书；E、 21CN图书有限公司21CN图书有限公司BookShop系统案例研究项目概要设计说明书；参考资料：A、 北大青鸟Aptech ACCP3.0 Year2基于软件开发项目的毕业设计；B、 国家标准项目开发计划（GB856T88）；C、 莱克公司的人力资源管理项目的项目开发计划；合同：A、21CN图书有限公司21CN图书有限公司BookShop系统案例研究项目合同 20031002 - 2；第

5、二部分、项目概述2.1工作内容为完成本项目，需要按照需求分析、设计、评审、编码、测试、安装和维护等不同的阶段来进行，其中，本计划不考虑维护阶段所做的工作。需求分析明确本项目所开发产品的特性，并对不同的功能组进行划分，并得到用户方的确认。设计阶段将该需求转化为计算机的模型，并且对实现的功能进行分配，详细设计还将提供各模块、任务、功能点的详细规划。评审分布在项目的阶段点，是质量保证的一部分，评审活动用于确定和调整与需求的偏差，以确保最后的产品符合初始提出的要求。编码实现将按照软件产品设计所描述的内容，编写代码实现软件各部分的功能。测试部分包括对实现过程中的错误的修改、功能的改进的一些活动，同时包括

6、了各子系统、模块、功能点的组合和连调。以上的过程中，包含了不同阶段的文档输出工作，并且上一阶段的输出，通常作为下一阶段的输入而存在。详细的工作包和任务的分配，请参考第二部分执行计划的工作分解结构。2.2主要参加人员本项目全职参与人员包括：人员名称主要职责或职务成员技能说明张惠明项目经理项目的规划、指导，数据库的设计董树声系统分析、设计人员系统分析，ASP.NET界面设计杨城程序员软件工程师，参与ASP.NET编码和接口设计、系统连调董勇程序员软件工程师，参与ASP.NET编码和接口设计。系统连调杨过程序员软件工程师，参与ASP.NET编码和接口设计。系统连调李海程序员软件工程师，参与ASP.N

7、ET编码和接口设计。系统连调王学兵程序员软件工程师，参与ASP.NET编码和接口设计。系统连调莫青雁测试工程师测试的产品化工作李明生文档工程师文档、需求分析和外部接口的一些工作项目其他间接的参与的人员，如客户的接口人员、公司的项目主管、评审专家等，在本文论述的地方进行说明。2.3产品项目的最后的产品和可交付物包括最后完成的软件包、相关的文档、手册、培训材料等，分别如下：2.3.1程序1、完成的软件系统最后完成的软件系统，其功能、模块和性能要求请参考文档21CN图书有限公司21CN图书有限公司BookShop系统案例研究项目需求说明书中关于产品特征的描述。最后完成的软件，要求是安装包的形式，并且

8、使用光盘的形式进行交付。2、数据库脚本程序：在系统遭受灾难的时候，客户方的系统管理员可以使用该脚本程序恢复数据库的结构。文档21CN图书有限公司21CN图书有限公司BookShop系统案例研究项目数据库脚本是该交付物的形式。2.3.2文件1、操作手册操作手册提供用户对软件系统的操作指导，要求同时提供.DOC格式的电子文档和至少一份打印稿。2、安装指南提供给甲方管理员关于对客户程序、数据库系统的安装指导，要求同时提供.DOC格式的电子文档和至少一份打印稿。3、培训资料相关的培训的资料要求提供给用户（具体的内容，在项目的后期进行确定）。2.3.3服务包括的服务集中在过程的后期，这些服务包括：A、产

9、品培训；在软件系统正式使用之前，需要提供给甲方使用人员为期两天的培训，参与培训人员由甲方确认，具体的日期、方式，在项目的后期确定。B、产品首次安装提供给甲方首次的数据库服务器的安装，包括10名以内客户程序的安装。具体的日期，在项目的后期双方进行确认。C、数据转换和系统初始化包括系统的用户、权限等，负责提供首次数据的输入工作，其他一些牵涉到的数据转换的工作，可以通过协商、补充协议等形式来解决。D、其他维护性的工作合同中所包含的其他维护性的工作。2.3.4非移交的产品非移交的产品包括过程记录和过程文档，包括：A、软件的源代码程序的源代码不提供给甲方，但不包括在HTML页面中的Script。B、安装

10、程序工程C、需求文档D、 过程评审记录包括需求、设计、实现和验证阶段的评审记录、评审报告，都不提交给甲方。E、 设计和规划文档包括产品设计、过程规划等方面的文档，不提供给甲方。F、 测试记录和测试报告以上非移交的产品，不得提供给其他的单位或者个人，或者用于其他的商业事务，详细的约定以合同为依据。2.4验收标准A、程序：程序中应包含的功能如下：1 图书查询功能标号（Ref#）功能R1.1按照出版社查询R1.2按照主题查询R1.3按照作者查询R1.4查询图书的详细信息2 图书选购功能标号（Ref#）功能R2.1将所选图书放进购物车R2.2可以修改购物车中图书的数量R2.3能够显示购物车中图书的总价

11、格R2.4取消此次购物R2.5生成新的订单R2.6将订单信息显示给客户，并且给客户发送电子邮件3 用户管理功能标号（Ref#）功能R3.1用户注册R3.2用户信息查询R3.3用户资料修改R3.4 用户注销4 订单查询功能标号（Ref#）功能R4.1根据用户名查询订单信息R4.2根据订单号查询订单的详细信息（包括订单的状态）数据库脚本在SQL Server 2000的查询分析器中能正确运行，创建的数据库能够支持程序的各项功能的运行，并且保证数据的准确性。B、文件操作手册、安装指南的规格满足GB86的相关标准，对应的内容应包括以上功能的各部分的说明，这些手册中所包含的专业词汇，甲方的系统管理员应能

12、够进行解释。培训材料的形式，可以是非正式的，并且可以是PPT讲演文稿、总结打印稿件等，形式由乙方确定。C、服务培训要求接受培训的成员80%以上能正常操作系统的主要功能；首次安装后，程序能够执行以上的功能，并且符合实际的业务规则；数据转换和系统初始化要求输入100名以内操作成员的数据；其他维护的要求按照合同规定的要求执行。2. 5完成项目的最迟期限项目的系统测试的最后完成日期为2003 12 1日，然后在2004 1 1之前，进行运行时测试，包括用户培训等服务活动的实施。系统在2004 1 1起，开始正式使用。3. 6本计划的批准者和批准日期本计划的批准人为产品开发部经理。本计划的正式批准日期为

13、2003 9 10 日，实施日期为2003 9 12日。第三部分、实施计划3.1工作任务的分解与人员分工本项目的工作分解结构如下： 产品设计D10：整理以上子系统的设计，编制系统详细设计D11：设计评审C4：项目首次会议：项目经理召开团队会议，进行早期的工作安排D1：项目计划会议，对项目的执行进行专题讨论设计阶段C3：评估会议：评估目标、风险、可行性和确定资源C2：需求说明：识别需求，并形成需求说明文档C1：需求调查：同用户接触，收集相关数据概念阶段D2：编写项目开发计划，进行规划和总体安排项目计划D3：项目计划的审核和发布D6：模块设计：数据表示Data模块以及系统框架SystemFrame

14、work模块设计D7：模块设计：数据访问模块DataAccess模块设计D4：针对需求提出计算机模型、逻辑设计、功能设计，形成概要设计文件D5：对数据库进行规范化和对象设计，并形成数据库设计文件D9：模块设计：Web页面模块设计D8：模块设计：商业逻辑BusinessRules模块和商业逻辑表示层模块BusinessFacadeI3：模块实现：商业逻辑BusinessRules模块和商业逻辑表示层模块BusinessFacadeI1：模块实现：数据表示Data模块以及系统框架SystemFramework模块设计实施阶段I2：模块实现：数据访问模块DataAccess模块设计I4：模块实现：W

15、eb页面模块设计I5：数据库的创建及测试数据的输入I11：组合以上的模块为系统，进行系统测试I10：对以上模块之间的接口进行测试，并进行调试I8：商业逻辑BusinessRules模块和商业逻辑表示层模块的单元测试和验证I7：数据访问模块DataAccess模块的单元测试和验证I6：数据库的访问控制程序的单元测试和验证I9：Web页面模块的单元测试和验证I12：整理系统测试文档，进行功能调整和改进I13：编写程序的帮助工程，编译和连接为系统的帮助文件I16：编写安装手册I15：软件打包和安装程序的测试I14：制作软件的安装程序、安装界面I17：整理开发文档，编写用户操作手册I18：项目的中期进

16、度评审I19：项目后期总体评估T1：收集质量记录、规划和设计文档，并进行文件的归档收尾阶段T3：输入系统的基本数据，进行数据转换工作T2：软件实地安装运行，可交付成果的验收T4：对用户表示不满意的程序、界面、手册进行修订T7：安排后期维护人员，解散项目团队T5：按合同的规定对用户进行培训T6：项目总结会议（说明：1、以上的工作，可以在更细的层次上进行分解，例如I9，可以分别为各个界面的设计等，系统测试可以分解为测试平台的搭建、测试用例的编写、系统各功能点的测试、测试记录的填写、测试总结和总结报告等多个工作单元。2、以上的工作分解，不存在时间先后的次序。）按照工作分解结构，职责分配如下： 人 员

17、工作包及说明张惠明董树声杨城董勇杨过李海王学兵莫青雁李明生C1：需求调查SPPPPPPAC2：编写需求文档PAC3：项目初步评估和初步安排会议APPPPPPPPC4：项目正式启动会议APPPPPPPPD1：计划会议、项目专题讨论APPPPPPPD2：汇总和编写项目计划SPD3：项目计划的审核和分发执行AD4：系统的总体设计相关内容APPPPPD5：数据库设计相关内容APD6：模块设计：数据库的访问控制程序APD7：模块设计：医生、病人、药品、帐单的操作PAPPPPPPD8：模块设计：主界面和D7相关的界面设计PAPD9：模块设计：聊天和通讯程序设计PAAAAAPD10：整理和编制详细设计，作为

18、编码的依据APPPPPPD11：设计评审API1：模块实现：编码实现D6PAI2：模块实现：编码实现D7PAI3：模块实现：编码实现D8AI4：模块实现：编码实现D9PAAAAAI5：准备数据库和测试数据PPAI6：单元测试和调试：I1PAI7：单元测试和调试：I2PAI8：单元测试和调试：I3PAI9：单元测试和调试：I4PAAAAAI10：I6、I7、I8、I9之间的接口测试APPPPPPPI11：系统的组合和系统测试APPPPPPPI12：系统测试报告和反馈PPPPPPPAI13：帮助工程和帮助文件制作PPPPPPAI14：安装工程和安装配置PPAI15：安装包测试APPPPPPI16：

19、编写安装指南PPPPPPAI17：编写用户操作指南PPAI18：中期评估API19：后期评估APT1：文件归档AT2：运行测试APT3：系统初始化和数据转换PPPPPAT4：程序、界面、手册的反馈和修订PPAT5：用户培训PAPT6：项目总结APPPPPPPPT7：项目结束和团队解散AP 参与人员；A 负责人员；S 确认审核人员；3.2接口人员负责接口工作的人员及他们的职责，包括：A、项目经理张惠明负责同用户的组织接口事务，包括变更和事务协调等； 系统分析员董树声负责用户的技术接口，包括一些技术方案的演示和确认； 产品专员李明生负责同用户的人际接口，包括文档、资料、培训和一些事务性的沟通。B、

20、 项目经理张惠明负责组织内部的接口，包括项目进度报告，资源协调等；C、 项目经理张惠明负责处理合同方面的接口；以上的接口事务，在上面的职责分配图中已经进行了表述。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。 在并行一些工作的条件下，项目预计完成的时间在三个月左右。（说明：非关键路径

21、活动所需要的时间，没有在项目网络图上标识。）I18 114C3、C4D313D1、D212321C1 3StartI5 3D4 4154D5D6 D7 D8 5 D9C 2 398765D10 4D11 11011T3 233I19 132I1731T2 63430181615I1 I2 I3 5 I41917T5I6 I7 I8 2 I9T4 435I1636I1523222120I10 529I142837T6 1I13T1 12724I12 4I11 4382625END项目的开始日期为2003 9 1日，项目的里程碑（阶段点）时间：明确了需求，并且正式准备开始项目的设计工作产品的详细设

22、计完成模块编码、单元测试和调试完成系统调试结束、手册编写完毕运行调试结束、用户接受. . . . . 9/8 9/20 10/12 11/4 11/24（说明：可以制作一张项目的日历，说明项目针对于日期的更详细的信息，这可以借助于Microsoft Project 2000等项目管理软件来完成，此处略。）3.4预算按照以上工作包的估算如下表： 费用项目(单位：元)工作包及说明办公费差旅费机时费资料费设备费其他合计C1：需求调查2000100020020010004400C2：编写需求文档20002000C3：初步评估100050006000 （中间的其他单项费用估算略）合计1000030001

23、0000200020000900054000分阶段的开发费用统计如下表：阶段名称人工费用(人月)机时(小时)其他(元)项目管理系统分析软件设计编程调试数据录入其他人工终端小时主机小时外存空间其他费用出差资料其他费用SA&SDRAPDDDCD&UTIT&STIS&ACTSSD（说明：以上实际数字的填写略。）SA&SD(System Analysis & Software Definition Phase)：系统分析与软件定义阶段；RA(Requirements Analysis Phase)：需求分析阶段；PD(Preliminary Design

24、 Phase)：概要设计阶段；DD(Detailed Design Phase)：详细设计阶段；CD&UT(Coding & Unit Testing Phase)：编码与单元测试阶段；IT&ST(Integrating & System Testing Phase)：组装与系统测试阶段；IS&AC(Installation & Acceptance Phase)：安装与验收阶段；TSSD(Total Software System Development Phase)：整个软件系统的开发阶段。（说明：1、以上的估算分别按照各项活动的累计进行估算

25、；并且按软件开发的不同的照阶段给出一个大体的估算数据，可以只用一种估算方法作为依据；2、项目的预算和估算可能由专门的项目财务管理系统来进行，项目计划中只要对该文档进行引用就可以了；3、得出的不同阶段的估算结果，可以绘制成本曲线，以对执行阶段的成本进行控制，一般的成本曲线应该是一条类似于S形状的曲线，下图是预算形成的成本基准和实际花费的成本的对比曲线：4、成本对比曲线、成本偏差是要求项目经理在项目进行过程中需要控制的一个重要方面；5、单项成本的估算一般没有考虑管理费用，在实际项目运行的时候，需要在总金额上加上一定比例的管理费用；例如以上管理费用的比例如果是20%，则实际的费用是64800；6、一

26、般的项目，都对成本留一定的储备金，例如，以上估算结果的储备金若是10%，考虑管理费用，最后的总预算是71280。）3.5关键问题影响整个项目成败的关键问题、技术难点和风险包括：风险类别风险描述可能性影响使用提高生产率工具所产生的计划节余被过高地估计了。0.40.9计划、资源和产品定义都受客户或上级管理部门支配，而不平衡0.80.3预定日期提前，但没有对产品范围或可用资源作相应调整。0.60.6产品比估计的大（从准则、功能点、模式等方面来看）。0.90.5管理审查/决策过程比预料的慢0.80.5非技术第三方任务花费的时间比预料的长（预算审批、法律审查等）。0.80.5最终和户坚持新要求。0.90

27、.8即使递交的软件符合所要求的全产规格，但商业用户将不接受该软件。0.80.9商业用户审查/决策过程比预料的慢。0.60.5最终用户最终发现产品不能令人满意，要求重新设计和重做。0.60.9小组成员之间的冲突导致通信差、设计差、界面错误和额外工作。0.60.7人事工作比预料的慢。0.70.6正式手续太多（官僚性遵守软件政策和标准）。0.80.7开发不具不像预料的那样有效，开发者需要时间来创建有关工作，或改用新工具。0.60.8（说明：1、以上列出的是可能影响项目开发，包括进度、成本和质量的各方面最重要的一些风险和对该风险的概率、影响的估计；2、以上的风险，是软件开发的风险对照表的一部分，在其他

28、的项目开发中，风险分析也可以采用风险对照表确定风险的概率和影响程度；然后在根据这些可能性和影响程度来判断是否采取预防措施；上图中，分别使用了不同的颜色来反应风险的最后的程度。3、软件开发风险对照表如下：风险类别风险描述可能影响规划风险计划是根据使用项目问题专家（SEM）的情况制定的，但是这些成员没有得到。计划省略是必要的任务。使用提高生产率工具所产生的计划节余被过高地估计了。计划、资源和产品定义都受客户或上级管理部门支配，而不平衡。计划是乐观的“最佳实例”（而不是现实的“预期实例”）。计划是根据使用具体小组成员的情况制定的，但这些小组成员没有得到。预定日期提前，但没有对产品范围或可用资源作相应

29、调整。一项任务的推迟使从属任务一并推迟。作为对计划到计划的失察作出反应而作出的重新估计过于乐观，或忽略了项目历史。过大的计划压力降低生产率。项目规划在压力下被放弃。规划太差，不能支持需要的发展速度。不能在分配的时间内制造规定尺寸的产品。产品比估计的大（从准则、功能点、模式等方面来看）。努力比估计的大（从准则、功能点、模式等方面来看）。准则或等级资料库质量差，造成额外的测试、缺陷纠正和重做工作。产品的不熟悉方面要花费比预料的更多的时间来设计和执行。任务先决条件（例如培训、其他项目的完成、获得工作许可证）不能按时完成。组织风险产品缺少有效的高级管理发起人。产品在不明不白的前其被搁置的时间太长。解雇

30、和削减降低小组的能力。管理或销售部门坚持延长计划的技术决定。低效的小组结构降低生产率。管理审查/决策过程比预料的慢。预算削减打乱项目规划。管理部门作出挫伤开发小组的积极性的决定。非技术第三方任务花费的时间比预料的长（预算审批、法律审查等）。规划太差，不能支持需要的发展速度。项目规划在压力下被放弃，导致混乱的、低效的发展。管理部门对豪情比对准确的状况报告强得更多，从而削弱它发现和纠正问题的能力。未能达到里程碑。商业用户坚持新要求。最终和户坚持新要求。即使递交的软件符合所要求的全产规格，但商业用户将不接受该软件。商业用户所期望的发展速度是开发者不能达到的。商业用户最终发现产品不能令人满意。没有征求

31、商业用户的意见，因此产品最终不符合用户期望，因此必须重做。商业用户审查/决策过程比预料的慢。缺少商业用户参与审查过程、原型和规格，因而导致不稳定的要求。商业用户通信比预料的慢。商业用户微观管理发展过程。商业用户提供的组成部分不匹配，并且质量差。最终用户最终发现产品不能令人满意，要求重新设计和重做。最终和户不买进项目，因此不提供所需要的支持。没有征求最终用户意见，因此产品最终不符合用户期望，必须重做。客户坚持新要求。客户对规划、原型和规格的审查/决策过程比预料的慢。客户将不参与对规划、原型和规格的审查过程，或不能这样做，从而导致不稳定的要求和费时的修改。客户通信时间（例如回答澄清要求问题的时间）

32、比预料的慢。客户坚持延长计划的技术决定。客户微观控制开发过程，导致进程比计划的慢。客户提供的组成部分质量差，导致额外的测试、设计和整合工作，并导致额外的客户关系管理。客户批准的支持工具和环境不兼容，性能差，或者功能不足，致使生产率降低。即使递交的软件符合所要求的全部规格，但客户将不接受该软件。客户所期望的发展速度是开发者不能达到的。小组结构效率低下。任务先决条件（例如培训、其他项目的完成、获得工作许可证）不能按时完成。开发者与管理部门之间的关系差，延缓决策和持续执行。小组成员不买进项目，因而不提供所需要的性能水平。积极性和士气低，从而降低生产率。缺少所需的规格，从而增加缺陷和重做工作。员工需要

33、额外时间来学习不熟悉的软件工具或环境。员工需要额外时间来学习不熟悉的硬件工具或环境。员工需要额外时间来学习不熟悉的编程语言。合同员工在项目完成前离开。长期员工在项目完成前离开。项目后期增加新开发人员，并且额外的培训和通信费用降低现有小组成员的效率。小组成员不能有效的协同工作。小组成员不买进项目。所需规格缺少增加。小组成员之间的冲突导致通信差、设计差、界面错误和额外工作。有问题的小组成员没有退出小组，从而挫伤整个小组的积极性。项目得不到更有资格做项目的人员。项目得到更有资格做项目的人员，但是出于政治或其他原因启用他们的。找不到项目所需要的具有关键技能的人员。关键人员只有部分时间才能得到。项目得不

34、到足够的人员。人事工作比预料的慢。缺少管理承诺。管理费用不合理。项目缺少有效的执行发起人。很难找到关键执行人。外部以来风险承包人和顾问不提供答应的组成部分。承包人和顾问提供的组成部分质量低得不能接受，因此必须增加时间来提高质量。雇用承包人和盛况时间比预料的长。任务先决条件（例如培训、其他项目的完成、获得工作许可证）不能按时完成。承包人和顾问需要额外的时间来学习不熟悉的软件工具或环境。承包人和顾问需要额外的时间来学习不熟悉的硬件工具或环境。承包人和顾问需要额外的时间来学习不熟悉的编程语言。合同员工在项目完成前离开。项目后期增加新的开发承包人和顾问，并且额外培训的通信费用降低现有小组成员的效率。小

35、组成员之间的冲突导致通信差、设计差、界面错误和额外工作。关键承包人和顾问只能部分时间才能得到。非技术第三方任务花费的时间比预料的长（预算审批、设备采购审批、法律审查）。合同类型限制到项目的全部要求。找到卖主解决问题的可能性受限制。培训包给第三方。提供包给第三方。找不到帮助部门来解决所有问题。导致在解决问题方面浪费大量时间。项目依赖卖主，因此控制是单方面的。不知道的额外费用不知不觉地进入项目。技术风险容易出错的模式所需要的测试、设计和执行工作比预料的多。不能接受的低质量所需的测试、设计和执行工作比预料的多。错误用户界面的开发需要重新设计和执行。不需要的额外软件功能（镀金）的开发扩大计划。符合产品

36、尺寸和速度限制所需要的时间比预料的多，包括重新设计和重新执行的时间。与现有系统兼容和严格要求所需的测试、设计和执行比预料的多。与其他系统、其他复杂系统或不受小组控制的其他系统的接合要求导致意料之外的设计、执行和测试。在多操作系统下操作的要求比预料的要花费更长的时间来满足。在不熟悉的或未经批准的软件环境下运行造成意料之外的问题。在不熟悉的或未经批准的硬件环境下运行造成意料之外的问题。对组织来说是新品牌的某种组成部分的开发所花的时间比预料的长。对仍在开发中的技术和依赖延长计划。产品取决于政府条例，这些条例意外地改变。产品取决于草拟的技术标准，这些标准意外地改变。在直到项目后期还不知道的项目问题方面

37、不准确的进程跟踪结果。初步质量担保活动被忽略。在直到项目后期还不知道的质量问题方面不准确的质量跟踪结果。正式手续太少（缺少遵守软件政策和标准）。正式手续太多（官僚性遵守软件政策和标准）。不充分的风险管理不能检测到主要项目风险。过分简单的设计不能解决主要问题，因而导致重新设计和重新执行。单独开发的组成部分不能容易地加以整合，因而需要重新设计和重做。过分复杂的设计需要不必要的和无利可得的执行费用。很差的设计导致重新设计和重新执行。使用不熟悉的方法导致额外的培训时间和重述，以确定方法的第一次误用。产品用低级语言（例如汇编语言）来执行，并且生产率比预料的低。必要的功能不能用选择的准则或等级资料库质量差

38、，造成额外的测试、缺陷纠正和重做工作。使用提高生产率工具所产生的计划节余被过高地估计了。开发不具不像预料的那样有效，开发者需要时间来创建有关工作，或改用新工具。开发工具不是根据其技术优点来选择的，因而不能提供计划中的生产率。批准的支持工具和环境不兼容，性能差，或者功能不足。设备不能及时得到。设备能得到，但不够用（例如没有电话，没有联网，没有办公用品等）。设备拥挤不堪，有噪声，或受到破坏。开发工具在所需时间不到位。学习新工具的时间比预料的长，或者所分的阶段比预料的多。）第四部分、支持条件支持本项目的开发所需要的条件和设施包括：4.1计算机系统支持硬件环境：CPU：PIII750或者更高频率ROM

39、：256或者更高内存支持磁盘：8G软件支持：开发所用的操作系统：Windows 2000 Server SP1开发工具：Visual Studio 6.0 SP4数据库系统：Microsoft SQL Server 2000企业版覆盖测试工具：Panoroma4.2需由用户承担的工作1、需求阶段用户需要提供1名部门主管、一名熟识业务人员，就产品的功能、特性和要求进行讨论和交流，用户方在需求说明编制完毕后，需要指定部门经理级或该职别以上的主管进行需求确认。2、设计阶段用户方需要指派一名代表参与设计评审的会议。3、编码和实施阶段中期和后期评审，用户方需要指派一名代表参与评审的会议。4、测试和控制用

40、户方需要提供软件测试所需要的真实的数据。5、验收和维护用户方组织参与培训的人员。用户方负责需要安装的计算机的环境的搭建。用户方提供数据转换所要求的原始数据。维护工作的要求，用户需要按照合同条款提供相应的条件。4.3由外单位提供的条件（不适用）。第五部分、专题计划要点51 配置管理计划配置管理所关心的问题涉及以下三点：1、 仔细定义软件系统的交付物；2、 严格控制对可交付物的变更；3、 确保软件系统的可交付物与既定的或者经过核准修订的可交付物相一致。北大青鸟Aptech所有的软件项目配置管理采用标准的表格模板，并遵循了标准：计算机软件配置管理计划规范(GB/T 12505-1990)，本部分加以

41、引用。本部分可以作为变更控制的依据。计划名称21CN图书有限公司BookShop系统研究项目配置管理计划项目名称21CN图书有限公司BookShop系统研究项目开发单位北大青鸟Aptech产品开发部项目经理张惠明引言目的1、 明确“21CN图书有限公司BookShop系统研究项目”产品开发的范围、特征；2、 对由于用户后期提出的范围改变、在设计中没有考虑周全的特征或者性能指标、牵制性的改变等导致的变更申请，定义变更的控制程序；3、 提供验收的标准和程序，确保可交付的产品符合用户既定的要求；4、 提出资源和机构的支持要求；定义1、 WBS：工作分解结构；参考前面的说明；2、 项目网络图：项目时间

42、估算的活动拍序图，参考以上的说明；参考资料1、21CN图书有限公司BookShop系统研究项目章程；2、21CN图书有限公司BookShop系统研究项目需求说明；3、21CN图书有限公司BookShop系统研究项目概要设计；4、本计划的范围管理部分；5、本计划的进度管理部分；6、计算机软件配置管理计划规范(GB/T 12505-1990)管理机构所有对本项目范围、变更能施加影响的机构（团体）包括：1、 甲方：21CN图书有限公司；2、 乙方：北大青鸟Aptech；3、 相关的专家和顾问；任务相关机构、人员对配置管理的任务包括：Q1：项目范围的提出；Q2：项目范围的确定；Q3：项目范围的更改；Q

43、4：更改后项目范围的核实和验证；Q5：产品特征的过程管理；Q6：可交付物的特征、性能验收对比；人员职责说明1、 由用户方_高名君_、项目实施方顾问组成员_张林、林夏、胡邻_组成配置管理委员会，实施配置管理程序；2、 用户方_高名君_负责代表甲方进行产品范围的提出，提供必要的资料和数据、提出变更申请和对可交付物的验收评估；3、 项目实施方 李明生 负责项目初期的资料收集、用户面谈、问题整理、并形成正式的需求文件；4、 在计划实施阶段，所有的变更要求必须由用户方_高名君_进行提出或者认可，所有的变更必须经过变更控制委员会的讨论（正式或者非正式的沟通），并把变更意见及时传递给项目实施方包松。5、 项

44、目收尾阶段，由用户方_朱青_、项目实施方 张惠明 共同进行产品审核，并记录审核结果，传递给变更控制委员会。管理计划实现（变更控制程序）A：控制和实施阶段1、 在突发事件的情况下项目经理可以对项目范围进行变更，并在事后把变更说明提交到变更控制委员会；2、 范围变更通常牵涉到人员、费用、进度、风险和质量等多个方面，所有的变更都要求对这些方面的考虑和权衡，对于引起这些方面明显的变动，需要更改这些方面的设计，并且进行相关的记录；3、 项目组其他成员可以对范围提出变更意见，但必须填写统一的问题报告单形成正式的变更请求；并鼓励每一个项目成员提出新方法、新工具以提高项目的开发进度，但严格控制在未经讨论的擅自

45、变更，这些变更指做WBS中未规定的事情；4、 对于客户提出的变更，视变更影响的大小，首先须经变更控制委员会正式或者非正式的讨论，把最后的变更意见交由项目经理实施；5、 WBS中对每一个消耗资源的活动都进行了定义，但并不表示WBS是不可更改的，所有经过变更都要求反映在WBS中，并且WBS所在的主文件以修改次数进行标识；6、 范围基线的变更要严格控制，除非在不能挽救的情况下，范围基线不允许变更；范围基线变更必须经过变更控制委员会正式的会议；7、 程序的变更、代码的更新所形成的的软件的新的调试版本，以版本管理程序和源代码管理程序进行标识和记录，项目经理要确保当前使用的版本反应了最新的变更（附件中规定

46、了版本和源代码记录的模版）；8、 变更的内容、质量要求须同时遵循质量计划、质量标准的相关事项；9、 用户手册、培训计划要求业务或对应功能相关的人员进行书写，并且按照进度计划中所规定的最后日期进行审核，所有的修订意见同时应通知变更控制委员会中实施方的成员；B：概念和计划阶段10、 在需求描述阶段，实施方把用户所要求进行开发和设计的内容清楚的理解并描述为文档，最终的正式范围说明需要经过包括变更控制委员会所有成员在内的正式评审，并作为后续工作的依据；C：收尾阶段11、 产品最后的验收依据是经过变更控制委员在计划阶段批准的范围说明，同时有效的是可能对产品特征明细或者未明细的正式合同，合同附件具有同等的

47、效力；12、 可能需要返工或者返修的可交付物需要用户的正式认可，同时在项目计划中加以说明；13、 在用户接受产品并要求结束合同的同时，变更控制委员会对控制绩效进行总结，收集相关的文件、质量记录并进行归档，在这些工作完成后宣布解散委员会；配置管理活动配置标识文档：问题报告单；版本清单；源代码清单；设计评审；需求评审 Microsoft Visual SourceSafe的版本标识； 程序：需求评审；设计评审；项目中期评估；项目验收评估；配置控制1、 变更控制委员会在召开项目首次会议时进行组建；2、 变更控制委员会只能在用户签署正式的产品接受文件后方可解散，变更控制委员会对产品维护阶段的问题不承担责任；3、 变更控制委员会的成员可以增加，但在人员计划中必须做必要的变更，本计划的相关部分也需要修订；4、 变更控制委员会有义务对产品的质量进行跟综和评价，有义务提出变更请求，以确保项目最后的产品符合使用者的要求；配置状态审查1、 公司的直接项目领导负责配置委员会工作的审查；2、 配置委员会负责产品的阶段性审查和评估，