1、2.5.3 须提交内部的文档2.5.4 应当提供的服务2.6 项目开发环境2.7 项目验收方式与依据3 项目团队组织3.1 组织结构3.2 人员分工3.3 协作与沟通3.3.1 内部协作3.3.2 外部沟通4 实施打算4.1 风险评估及对策4.2 工作流程4.3 总体进度打算4.4 项目监控4.4.1 质量操纵打算4.4.2 进度监控打算4.4.3 预算监控打算4.4.4 配置治理打算5 支持条件5.1 内部支持（可选）5.2 客户支持（对项目而言）5.3 外包（可选）6 预算（可选）6.1 人员成本6.2 设备成本6.3 其它经费预算6.4 项目合计经费预算7 关键问题8专题打算要点二、项目
2、打算书的编写讲明讲明编写这份项目打算的目的，并指出预期的读者。作用本节是为了讲明编制“项目打算书”亦即本文档的意图和希望达到的效果。注意那个地点的“目的”不是“项目目标”，而是为了讲明本文档的目的与作用。“项目目标”在2.1中讲明。意义使项目成员和项目干系人了解项目开发打算书的作用、希望达到的效果。开发打算书的作用一般差不多上“项目成员以及项目干系人之间的共识与约定，项目生命周期所有活动的行动基础，以便项目团队依照本打算书开展和检查项目工作。”例如能够这么写为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把关于在
3、项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。常见的问题把项目本身的“项目目标”误作编制项目开发打算的目的。要紧讲明项目的来历，一些需要项目团队成员明白的相关情况。要紧有以下内容项目的名称通过与客户商定或通过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“XX系统”开发的项目名称是“XX系统开发”。项目的
4、托付单位假如是依照合同进行的软件开发项目，项目的托付单位确实是合同中的甲方；假如是自行研发的软件产品，项目的托付单位确实是本企业。项目的用户（单位）软件或网络的使用单位，能够泛指某个用户群。注意项目的用户或单位有时与项目的托付单位是同一个，有时是不一样的。如海关的报关软件、税务的报税软件，托付单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。项目的任务提出者本企业内部提出需要完成此项目的人员，一般是领导或商务人员；注意项目的任务提出者一般不同于项目的托付单位，前者一般是企业内部的人员。假如是内部开发项目，则两者的区不在于前者指人，后者指单位。项目的要
5、紧承担部门有些企业依照行业方向或工作性质的不同把软件开发分成不同的部门（也有的分为不同事业部）。项目的特点确实是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要依照项目所涉及的范围确定本项目的要紧承担部门。项目建设背景从政治环境上、业务环境上讲明项目建设背景，讲明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。例句依照某部关于某建设工作的实施意见精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌
6、握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。目前关于某建设工作的工作要紧采纳打算部门手工编制年度打算、建设工作主管部门和建设工作实施单位联合手动编制进度打算，某建设工作单位手工上报建设工作进度情况的方式，而全市的建设工作有数百个，加上前期建设工作的数量和今后某市建设进展的趋势，建设工作的数量将越来越多，原来的工作模式差不多越来越无法适应市委市政府的要求。因此，充分利用现代信息化、因特网的优势，建立“某市某建设工作信息报送反馈系统”，提高某建设工作信息报送反馈工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是特不有必要和紧迫的任务。软件系统与其它系统的关系讲明
7、与本系统有关的其它系统，讲明它们之间的相互依靠关系。这些系统能够是那个系统的基础性系统（一些数据、环境等必须依靠那个系统才能运行），也能够是以那个系统为基础的系统，或者是两者兼而有之的关系、互相依靠的系统。例句本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在市政府网站。软件系统与机构的关系讲明软件系统除了托付单位和使用单位，还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。列出为正确理解本打算书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义
8、，使它的含义和通用术语的惯用含义不一致。列出本打算书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位，必要时讲明得到这些文件资料和标准的途径。本节与下一节的“标准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”，因为“参考”的不一定是“必须遵守”的。常用资料如本项目的合同、标书、上级机关有关通知、通过审批的项目任务书；属于本项目的其它差不多发表的文件；本文档中各处引用的文件、资料，包括所要用到的软件开发标准。列出在本项目开发过程中必须遵守的标准、条约和约定。例如相应的立项建议书、项目任务书、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技
9、术规范等。“参考资料”一般具有“物质”特性，一般要讲明参照了什么，要讲明在哪里能够获得；“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不讲明在哪里能够获得。参考资料的内容应该涵盖“标准、条约和约定”。2.1 项目目标设定项目目标确实是把项目要完成的工作用清晰的语言描述出来，让项目团队每一个成员都有明确的概念。注意，不要简单地讲成在什么什么时刻完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个凝的目标，它还不够具体和明确。明确的项目目标应该指出了服务对象，所开发软件系统最要紧的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。项目
10、目标应当符合SMART原则l S Specific 明确的陈述l M Measurable 能够衡量的结果l A Attainable 能够达成的目标l R Realistic 合理的，现实的或者讲是能和实际工作相结合l T Trackable 能够跟踪的项目目标能够进行横向的分解也能够进行纵向的分解向分解一般按照系统的功能或按照建设单位的不同业务要求，如分解为第一目标、第二目标等等；纵向的分解一般是指按照时期，如分解为第一时期目标、第二时期目标等等，或近期目标、中期目标、远期目标等等。时期目标一般应当讲明目标实现的较为明确的时刻。一般要在讲明了总目标的基础上再讲明分解目标，可加上“为实现项目
11、的总目标，必须实现以下三个时期目标2.2 产品目标与范围依照项目输入（如合同、立项建议书、项目技术方案、标书等）讲明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。对项目成果（软件系统）范围进行准确清晰的界定与讲明是软件开发项目活动开展的基础和依据。软件系统产品目标应当从用户的角度讲明开发这一软件系统是为了解决用户的那些问题。产品目标如“提高工作信息报送反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强度。2.3 假设与约束关于项目必须遵守的各种约束（时刻、人员、预算、设备等）进行讲明。这些内容将限制你实现什么、如何
12、样实现、什么时候实现、成本范围等种种制约条件。假设是通过努力能够直接解决的问题，而这些问题是一定要解决才能保证项目按打算完成。如“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”约束一般是难以解决的问题，但能够通过其它途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。假设与约束是针对比较明确会出现的情况，假如问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性（概率）、造成的阻碍、应当采取的相应措施。讲明为实现项目的目标需要进行那些工作。在必要时，可描述与合作单位和用户的工作分工。注意产品范围与项目工作范围的不同含义。产品范围界定软
13、件系统产品本身范围的特征和功能范围。工作范围界定为了能够按时保质交付一个有专门的特征和功能的软件系统产品所要完成的那些工作任务。产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照打算来检验的。这两个范围治理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。其中软件对象可能包括源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。列出需要移交给用户的每种文档的名称、内容要点及存储形式，
14、如需求规格讲明书、关心手册等。此处需要移交用户的文档可参考合同中的规定。可依照GB8567-88计算机软件产品开发文件编制指南附录O“文件编制实施规定的实例（参考件）”结合各企业实际情况调整制定软件开发文档编制裁减衡量因素表。依照因素表确定项目对应的项目衡量因素取值，以确定本项目应完成的时期成果。将不适用于本项目的内容裁减，以减少不必要的项目任务和资源。依照因素取值列出本项目应完成的时期成果，讲明本项目取值所在的区间，将其它因素值区间删除。依照合同或某重点建设工作需要，列出将向用户或托付单位提供的各种服务，例如培训、安装、维护和运行支持等。具体的工作打算如需要编制现场安装作业指导书、培训打算等
15、，应当在本打算“4.3总体进度打算”中条列出。讲明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置治理工具、网络环境。环境可能不止一种，如开发工具可能需要针对Java的，也需要针对C+的。有些环境可能无法确定，需要在需求分析完成或设计完成后才能确定所需要的环境。讲明项目内部验收和用户验收的方式，如验收包括交付前验收、交付后验收、试运行（初步）验收、最终验收、第三方验收、专家参与验收等等。项目验收依据要紧有标书、合同、相关标准、项目文档（最要紧是需求规格讲明书）。讲明项目团队的组织结构。项目的组织结构能够从所需角色和项目成员两个方面描述。所需角色要紧讲明为了完成本项
16、目任务，项目团队需要哪些角色构成，如项目经理、打算经理、系统分析员（或小组）、构架设计师、设计组、程序组、测试组等等。组织结构能够用图形来表示，能够采纳树形图，也能够采纳矩阵式图形，同时讲明团队成员来自于哪个部门。除了图形外，能够用文字简要讲明各个角色应有的技术水平。注意尽管有一些通用的结构能够套用，但各种不同规模、不同形式的项目组织结构是不一样的。如产品研发项目可能就不需要实施人员（小组），但需要知识转移方面的人员（小组）。而软件编码外包的项目则不需要程序员，测试人员也能够适当地减少。确定项目团队的的每个成员属于组织结构中的什么角色，他们的技术水平、项目中的分工与配置，能够用列表方式讲明，具
17、体编制时按照项目实际组织结构编写。以下是一个示例。项目的沟通与协作首先应当确定协作与沟通的对象，确实是与谁协作、沟通。沟通对象应该包括所有项目干系人，而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。其次应当确定协作模式与沟通方式。沟通方式如会议、使用电话、QQ、内部邮件、外部邮件、QuickPlace、谈天室等等。其中邮件沟通应当讲明主送人、抄送人，谈天室沟通方式应当约定时刻周期。而协作模式要紧讲明在出现什么状况的时候各个角色应当（主动）采取什么措施，包括沟通，如何互相配合来共同完成某项任务。定期的沟通一般要包括项目时期报告、项目时期打算、时期会议等3.3.1 项目
18、团队内部协作本节讲明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录方法等内容。3.3.2 项目接口人员应当讲明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括a、负责本项目同用户的接口人员；b、负责本项目同本企业各治理机构，如打算治理部门、合同治理部门、采购部门、质量治理部门、财务部门等的接口人员；c、负责本项目同分包方的接口人员。3.3.3 项目团队外部沟通与协作模式项目团队外部包括企业内部治理协助部门、项目托付单位、客户等等。本节讲明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录方法等内容。明确最终用户、直接用户及其所在本企业
19、部门名称和联系电话。明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。识不或预估项目进行过程中可能出现的风险。应该分析风险出现的可能性（概率）、造成的阻碍、依照阻碍应该采取的对策，采取的措施。风险识不包括识不内在风险及外在风险。内在风险是指项目工作组能加以操纵和阻碍的风险，如人事任免和成本可能等。外在风险指超出项目工作组等操纵力和阻碍力之外的风险，如市场转向或政府行为等风险的对策包括幸免排除特定危胁往往靠排除危险起源；减缓减少风险事件的预期资金投入来减低风险发生的概率，以及减
20、少风险事件的风险系数；吸纳同意一切后果，能够是积极的（如制定预防性打算来防备风险事件的发生），也能够是消极的（如某些费用超支则同意低于预期的利润）。关于软件开发项目而言，在分析、识不和治理风险上投入足够的时刻和人力能够使项目进展过程更加平稳，提高项目跟踪和操纵的能力，由于在问题发生之前差不多做了周密打算，因而对项目的成功产生更加充分的信心。软件开发项目常见预估的风险1） 工程规模进度上的风险规模大，规模估算不精确甚至误差专门大；就规模而言，用户要求交付期、费用专门紧；预料外的工作（测试未完时的现场对应等）；2） 技术上的风险使用新的开发技术、新设备等，或是新的应用组合，没有经验；是新的行业或业
21、务，没有经验；性能上的要求专门严；3） 用户体制上的问题用户治理不严，可能功能决定、验收不能顺利地完成（或者出现了延迟）；或者可能功能会多次变更；与用户分担开发，可能工程会拖延（或者出现了延迟）；用户或其它相关单位承担的工作有可能延误；4） 其它应该包含此处没有、但据推测有风险的项目。讲明项目采纳什么样的工作流程进行。如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也能够是自己创建的工作流程。不同的流程将阻碍后面的工作打算的制定。必要时画出本项目采纳的工作流程图及适当的文字讲明。那个地点所讲的总体进度打算为高层打算。作为补充，应当分时期制定项目的时期打算，这些时期打算不在这份
22、文档中，当要以这份总体打算为依据。总体进度打算要依据确定的项目规模，列表项目时期划分、时期进度安排及每时期应提交的时期成果，在时期时刻安排中要考虑项目时期成果完成、提交评审、修改的时刻。关于项目打算、项目预备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作，给出每项工作任务的预定开始日期、完成日期及所需的资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（里程碑）。例如需求评审设计评审表格中检查点里程碑等时期划分为举例，实际作业时期划分、时期成果等请依照项目需要确定。制定软件项目进度打算能够使用一些专门的工具
23、，最常用的是Microsoft的Project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但无法完全代替项目打算书，特不是一些要紧由文字来讲明的部分。小规模的项目可简便地使用EXCEL作为辅助工具。关于如何使用这些工具不在此作详细讲明。制定软件项目进度打算应当考虑以下一些因素:1）关于系统需求和项目目标的掌握程度。如开始时关于系统需求和项目目标只有比较数的了解，就只能制定出比较粗的进度打算，等到需求时期或设计时期结束，就应该进一步细化进度打算。2）软件系统规耐项目规模，这两个不是一个概念。软件系统规模往往是从功能点的估算或其它估算方式得来的，而项目规模还要考虑对文档数量与质量的要求，
24、使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。例如，完成一个大型的系统，在一定的时刻内一个人或几个人的智力和体力是承受不了的。由于软件是逻辑、智力产品，盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和治理方面的问题将更为严峻。3）软件系统复杂程度和项目复杂程度和软件系统规耐项目规模一样，软件系统的复杂程度要紧是考虑软件系统本身的功能、架构的复杂程度，而项目的复杂程度要紧是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度，多项目情况下资源保障的情况，等等等等
25、。软件系统的规模与软件系统的复杂程度未必是成比例的关系；同样项目的规模与项目的复杂程度未必是成比例的关系。4）项目的工期要求，确实是项目的紧急程度。有些项目规模大，却因为与顾客签订了合同，或者为了抢先占据市场，工期压缩得专门紧，这时就要考虑如何更好地合理安排进度，多增加人选多采纳加班的方式是一种万不得已的选择。增加人选除了增加人的成本外必定会增加沟通的成本（熟悉项目任务所需要的时刻）；加班假如处理不行会造成情绪上的问题，也可能会因为过于忙碌而无法顾及质量，造成质量的下滑。5）项目成员的能力。这些能力包括项目经理的治理能力，系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员
26、的测试能力，以及企业或项目团队激发出这些能力的能力。从另外一个角度看还有总体上对客户行业业务的熟悉程度；关于建模工具、开发工具、测试工具等技术的掌握程度；企业内部对行业业务知识和要紧技术的知识积存。4.4 项目操纵打算4.4.1 质量保证打算执行质量评审活动，对过程质量进行操纵。规模较大的项目应当单独编写软件开发项目质量打算。依照GB/T 12504 计算机软件质量保证打算规范，内容包括l 引言（本章节包括质量打算的目的、定义、参考资料）l 治理（描述负责软件质量治理的机构、任务及其相关的职责）l 文档（列出在该软件的开发、验证与确认以及使用与维护等时期中需要编制的文档，并描述对文档进行评审与
27、检查的准则）l 标准、条例和约定（列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施）l 评审和检查（规定所要进行的技术和治理两个方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查）l 软件配置治理（编制有关配置治理条款，或在“4.4.4 配置治理打算”中讲明，或引用按照GB/T 12505 计算机软件配置治理打算规范单独制定的文档）l 工具、技术和方法（指明用于支持特定软件项目质量治理工作的工具、技术和方法，指出它们的目的和用途）l 媒体操纵（讲明爱
28、护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化）l 对供货单位的操纵（供货单位包括项目承办单位、软件销售单位、软件开发单位。规定对这些供货单位进行操纵的规程，从而保证项目承办单位从软件销售单位购买的、其它开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。）l 记录的收集、维护和保存（指明需要保存的软件质量保证活动的记录，并指出用于汇总、爱护和维护这些记录的方法和设施，并指明要保存的期限）4.4.2 进度操纵打算（可直接引用以下描述或依照项目情况制定本节内容）本项目的进度监控执行本企业项目治理规范，由本企业过程操纵部门如质量治理部统一进行监控，并保留在监控过程
29、中产生的日常检查记录。讲明如何检查项目预算的使用情况。依照项目情况需要制定。编制有关软件配置治理的条款，或引用按照GB/T 12505单独制订配置治理打算文档。在这些条款或文档中，必须规定用于标识软件产品、操纵和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置治理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发觉的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。依照GB/T 12505 计算机软件配置治理打算规范，软件配置治理打算内容如下l 治理（描述负责软件配置治理的机构、任务、职责及其有关的接口操纵。l 软件配置治理活动（描述配置标识、配置操纵、配置状态记录与报告以及配置检查与评审等到四方面的软件配置治理活动的需求。l 工具、技术和方法（指明为支持特定项目的软件配置治理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法）l 对供货单位的操纵（供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行操纵的治理规程，从而使从软件销售单位购买的、其它开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置治理需求）l 记录的收集、维护和保存（指明要保存的软件配置治理文档，指明用
