专业软件项目计划书（通用14篇）

计划书是一种规划和安排具体工作或活动的书面材料，它能够帮助我们明确目标并有序地进行工作。我想我们需要写一份计划书了吧。计划书范文中的案例和经验可以帮助我们更好地理解和掌握计划书的要点和写作技巧。

专业软件项目计划书（通用14篇）篇一

编写本文档的目的是确保项目包括成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。是项目管理团队确定、记载、核实、管理和控制项目范围的指南。此文当中包括制作工作分解结构，并确定如何维持与批准该工作分解结构；规定如何正式核实与验收项目已完成可交付成果。

1.2 参考资料

1.3 重要术语

2005：软件开发语言

visual studio 2005 软件开发环境

2.1 系统与项目的定义

本系统是建立在c/s系统架构下基于sql server数据库，技术分析、设计、开发用于酒店信息化管理的。该系统基本满足了酒店管理方面的需求，用户界面友好。系统对用户（主要是酒店管理层及员工）数据有效地实现了信息电子化处理，从而降低了人工劳动并增加信息的准确性。本系统的基本信息有客房、餐饮、财务及人力资源等，用户登录系统后根据权限操作这些基本信息。

要实现的功能模块包括4个方面，第一个方面是客房管理子系统，包括客房登记、客房预定、工作报表、信息查看及最重要的客房部经理管理模块；第二个方面是餐饮管理子系统，包括点单、埋单、预定、换台及最重要的餐饮部经理管理模块；第三个个方面是财务管理子系统，包括财务预算的查看及发布审核、财务报表的生成等；最后一个方面是人力资源管理子系统，包括员工信息的录入、查看及绩效考核等。

2.2 系统开发背景与目标

在信息高度发达的今天，酒店业务涉及的各个工作环节已经不再仅仅是传统的住宿、结算业务，而是更广、更全面的服务性行业代表。酒店宾馆作为一个服务性行业，从客房的营销即客人预订开始，到入住登记直至最后退房结账，整个过程应该能够体现以宾客为中心，提供快捷、方便的服务。给宾客一种顾客至上的享受。提高酒店的管理水平，简化各种复杂操作，在最合理、最短时间内完成酒店业务规范化操作，这样才能令旅客舒适难忘，增加宾客回头率。而对酒店业内激烈的竞争形势，各酒店均在努力拓展其服务领域的广度和深度。虽然信息化不是酒店走向成功的关键因素，但它可以帮助那些真正影响成败的要素发挥更大的作用。因此，采用全新的酒店管理系统，将成为提高酒店的管理效率，改善服务水平的重要手段之一。

酒店行业的激烈竞争使得争取客源、提高酒店入住率、制定正确营销策略已经成为一项重要的任务，借助蓬勃发展的it工具来拓展其能力已经成为许多酒店的首选。

计算机管理系统在数据保存、数据交换方面的快速可靠，是手工操作不能完成的。

酒店管理系统的设计目标：

1）采用先进的分布式数据处理技术，以提高管理工作的质量、效率和规范性；

3）旨在提高酒店的管理效率，减免手工处理的繁琐和误差。及时、准确地反应酒店的工作情况、经营情况，从而提高酒店的服务质量，获得更好的经济效益；实现客房管理的规范化、自动化。

2.3 用户需求概述及系统主要功能

开发技术选择与理由

开发酒店管理系统，软硬件方面选择的是可视化的visual 2005和sql server 2000数据库，windows xp操作系统等。

vb拥有图形用户界面（gui），可以轻易的使用ado连接数据库,程序员可以轻松的使用vb提供的组件快速建立一个应用程序,以上都是组员熟悉的语言和数据库，所以技术方面是绝对可行的。综上所述，我们完全有能力完成酒店管理系统的最终实现。

专业软件项目计划书（通用14篇）篇二

专业软件项目计划书（通用14篇）篇三

专业软件项目计划书（通用14篇）篇四

软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。

软件是由计算机程序和程序设计的概念发展演化而来的，是在程序和程序设计发展到一定规模并且逐步商品化的过程中形成的。软件开发经历了程序设计阶段、软件设计阶段和软件工程阶段的演变过程。

软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。

【目录】。

第一部分摘要。

一、信息系统公司概况描述。

二、信息系统公司的宗旨和目标。

三、信息系统公司目前股权结构。

四、已投入的资金及用途。

五、信息系统公司目前主要产品或服务介绍。

六、市场概况和营销策略。

七、主要业务部门及业绩简介。

八、核心经营团队。

九、信息系统公司优势说明。

十、目前信息系统公司为实现目标的增资需求:原因、数量、方式、用途、偿还。

十一、融资方案(资金筹措及投资方式及退出方案)。

十二、财务分析。

1.财务历史数据。

2.财务预计。

3.资产负债情况。

第二部分综述。

第一章信息系统公司介绍。

一、信息系统公司的宗旨。

二、信息系统公司简介资料。

三、各部门职能和经营目标。

四、信息系统公司管理。

1.董事会。

2.经营团队。

3.外部支持。

第二章技术与产品。

一、技术描述及技术持有。

二、产品状况。

1.主要产品目录。

2.产品特性。

3.正在开发/待开发产品简介。

4.研发计划及时间表。

5.知识产权策略。

6.无形资产。

三、信息系统产品生产。

1.资源及原材料供应。

2.现有生产条件和生产能力。

3.扩建设施、要求及成本，扩建后生产能力。

4.原有主要设备及需添置设备。

5.产品标准、质检和生产成本控制。

6.包装与储运。

第三章信息系统市场分析。

一、信息系统市场规模、市场结构与划分。

二、目标市场的设定。

三、产品消费群体、消费方式、消费习惯及影响市场的主要因素分析。

五、市场趋势预测和市场机会。

六、行业政策。

第四章竞争分析。

一、有无行业垄断。

二、从市场细分看竞争者市场份额。

三、主要竞争对手情况:公司实力、产品情况。

四、潜在竞争对手情况和市场变化分析。

五、信息系统公司产品竞争优势。

第五章信息系统市场营销。

一、概述营销计划。

二、信息系统销售政策的制定。

三、信息系统销售渠道、方式、行销环节和售后服务。

四、主要业务关系状况。

五、信息系统销售队伍情况及销售福利分配政策。

六、促销和市场渗透。

1.主要促销方式。

2.广告/公关策略、媒体评估。

七、信息系统产品价格方案。

1.定价依据和价格结构。

2.影响价格变化的因素和对策。

八、销售资料统计和销售纪录方式，销售周期的计算。

九、信息系统市场开发规划，销售目标。

第六章投资说明。

一、资金需求说明(用量/期限)。

二、资金使用计划及进度。

三、投资形式(贷款/利率/利率支付条件/转股-普通股、优先股、任股权/对应价格等)。

四、资本结构。

五、回报/偿还计划。

六、资本原负债结构说明。

七、投资抵押。

八、投资担保。

九、吸纳投资后股权结构。

十、股权成本。

十一、投资者介入公司管理之程度说明。

十二、报告。

十三、杂费支付。

第七章投资报酬与退出。

一、股票上市。

二、股权转让。

三、股权回购。

四、股利。

第八章风险分析。

一、资源风险。

二、市场不确定性风险。

三、研发风险。

四、生产不确定性风险。

五、成本控制风险。

六、竞争风险。

七、政策风险。

八、财务风险。

九、管理风险。

十、破产风险。

文档为doc格式。

专业软件项目计划书（通用14篇）篇五

1.1编写目的。

1.2背景。

1.3定义。

1.4参考资料。

1.5标准、条约和约定。

2项目概述。

2.1项目目标。

2.2产品目标与范围。

2.3假设与约束。

2.5应交付成果。

2.5.1需完成的软件。

2.5.2需提交用户的文档。

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其它经费预算。

7关键问题。

8专题计划要点。

1.1编写目的。

说明编写这份项目计划的目的，并指出预期的读者。

作用:本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。

注意这里的“目的”不是“项目目标”，而是为了说明本文档的目的与作用。

“项目目标”在2.1中说明。

意义:使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。

开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定，项目生命周期所有活动的行动基础，以便项目团队根据本计划书开展和检查项目工作。”

例如可以这么写:为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。

常见的问题:把项目本身的“项目目标”误作编制项目开发计划的目的。

1.2背景。

主要说明项目的来历，一些需要项目团队成员知道的相关情况。

主要有以下内容:。

项目的名称:经过与客户商定或经过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“xx系统”开发的项目名称是“xx系统开发”。

项目的委托单位:如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方;如果是自行研发的软件产品，项目的委托单位就是本企业。

项目的用户(单位):软件或网络的使用单位，可以泛指某个用户群。

注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。

如海关的报关软件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。

项目的任务提出者:本企业内部提出需要完成此项目的人员，一般是领导或商务人员;注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。

如果是内部开发项目，则两者的区别在于前者指人，后者指单位。

项目的主要承担部门:有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门(也有的分为不同事业部)。

项目的特点就是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。

需要根据项目所涉及的范围确定本项目的主要承担部门。

项目建设背景:从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。

这有利于项目成员更好地理解项目目标和各项任务。

例句:根据《某部关于某建设工作的实施意见》精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。

目前对于某建设工作的工作主要采用计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划，某建设工作单位手工上报建设工作进度情况的方式，而全市的建设工作有数百个，加上前期建设工作的数量和今后某市建设发展的趋势，建设工作的数量将越来越多，原来的工作模式已经越来越无法适应市委市政府的要求。

因此，充分利用现代信息化、因特网的优势，建立“某市某建设工作信息报送反馈系统”，提高某建设工作信息报送反馈工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。

软件系统与其他系统的关系:说明与本系统有关的其他系统，说明它们之间的相互依赖关系。

这些系统可以是这个系统的基础性系统(一些数据、环境等必须依靠这个系统才能运行)，也可以是以这个系统为基础的系统，或者是两者兼而有之的关系、互相依赖的系统。

例句:本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在市政府网站。

软件系统与机构的关系:说明软件系统除了委托单位和使用单位，还与哪些机构组织有关系。

例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。

1.3定义。

列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。

注意尽量不要对一些业界使用的通用术语进行另外的定义，使它的含义和通用术语的惯用含义不一致。

1.4参考资料。

列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位，必要时说明得到这些文件资料和标准的途径。

本节与下一节的“标准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”，因为“参考”的不一定是“必须遵守”的。

常用资料如:。

本项目的合同、标书、上级机关有关通知、经过审批的项目任务书;。

属于本项目的其他已经发表的文件;。

本文档中各处引用的文件、资料，包括所要用到的软件开发标准。

1.5标准、条约和约定。

列出在本项目开发过程中必须遵守的标准、条约和约定。

例如:相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。

“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得;“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。

参考资料的内容应该涵盖“标准、条约和约定”。

2项目概述。

2.1项目目标。

设定项目目标就是把项目要完成的工作用清晰的语言描述出来，让项目团队每一个成员都有明确的概念。

注意，不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。

注意“要完成一个系统”只是一个模糊的目标，它还不够具体和明确。

明确的项目目标应该指出了服务对象，所开发软件系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。

项目目标应当符合smart原则:。

lsspecific明确的陈述。

lmmeasurable可以衡量的结果。

laattainable可以达成的目标。

lrrealistic合理的，现实的或者说是能和实际工作相结合。

lttrackable可以跟踪的。

项目目标可以进行横向的分解也可以进行纵向的分解。

横向分解一般按照系统的功能或按照建设单位的不同业务要求，如分解为第一目标、第二目标等等;纵向的分解一般是指按照阶段，如分解为第一阶段目标、第二阶段目标等等，或近期目标、中期目标、远期目标等等。

阶段目标一般应当说明目标实现的较为明确的时间。

一般要在说明了总目标的基础上再说明分解目标，可加上“为实现项目的总目标，必须实现以下三个阶段目标······”

2.2产品目标与范围。

根据项目输入(如合同、立项建议书、项目技术方案、标书等)说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。

对项目成果(软件系统)范围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。

软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。

产品目标如“提高工作信息报送反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强度。”

2.3假设与约束。

对于项目必须遵守的各种约束(时间、人员、预算、设备等)进行说明。

这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。

假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成。

如:“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”

约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。

假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性(概率)、造成的影响、应当采取的相应措施。

说明为实现项目的目标需要进行那些工作。

在必要时，可描述与合作单位和用户的工作分工。

注意产品范围与项目工作范围的不同含义。

产品范围界定:软件系统产品本身范围的特征和功能范围。

工作范围界定:为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。

产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照计划来检验的。

这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。

2.5应交付成果。

2.5.1需完成的软件。

列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。

其中软件对象可能包括:源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。

2.5.2需提交用户的文档。

列出需要移交给用户的每种文档的名称、内容要点及存储形式，如需求规格说明书、帮助手册等。

此处需要移交用户的文档可参考合同中的规定。

2.5.3须提交内部的文档。

可根据《gb8567-88计算机软件产品开发文件编制指南》附录o:“文件编制实施规定的实例(参考件)”结合各企业实际情况调整制定《软件开发文档编制裁减衡量因素表》。

根据《因素表》确定项目对应的项目衡量因素取值，以确定本项目应完成的阶段成果。

将不适用于本项目的内容裁减，以减少不必要的项目任务和资源。

根据因素取值列出本项目应完成的阶段成果，说明本项目取值所在的区间，将其他因素值区间删除。

2.5.4应当提供的服务。

根据合同或某重点建设工作需要，列出将向用户或委托单位提供的各种服务，例如培训、安装、维护和运行支持等。

具体的工作计划如需要编制现场安装作业指导书、培训计划等，应当在本计划“4.3总体进度计划”中条列出。

2.6项目开发环境。

说明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。

环境可能不止一种，如开发工具可能需要针对java的，也需要针对c++的。

有些环境可能无法确定，需要在需求分析完成或设计完成后才能确定所需要的环境。

2.7项目验收方式与依据。

说明项目内部验收和用户验收的方式，如验收包括交付前验收、交付后验收、试运行(初步)验收、最终验收、第三方验收、专家参与验收等等。

项目验收依据主要有标书、合同、相关标准、项目文档(最主要是需求规格说明书)。

3项目团队组织。

3.1组织结构。

说明项目团队的组织结构。

项目的组织结构可以从所需角色和项目成员两个方面描述。

所需角色主要说明为了完成本项目任务，项目团队需要哪些角色构成，如项目经理、计划经理、系统分析员(或小组)、构架设计师、设计组、程序组、测试组等等。

组织结构可以用图形来表示，可以采用树形图，也可以采用矩阵式图形，同时说明团队成员来自于哪个部门。

除了图形外，可以用文字简要说明各个角色应有的技术水平。

注意虽然有一些通用的结构可以套用，但各种不同规模、不同形式的项目组织结构是不一样的。

如产品研发项目可能就不需要实施人员(小组)，但需要知识转移方面的人员(小组)。

而软件编码外包的项目则不需要程序员，测试人员也可以适当地减少。

3.2人员分工。

确定项目团队的的每个成员属于组织结构中的什么角色，他们的技术水平、项目中的分工与配置，可以用列表方式说明，具体编制时按照项目实际组织结构编写。

以下是一个示例。

3.3协作与沟通。

项目的沟通与协作首先应当确定协作与沟通的对象，就是与谁协作、沟通。

沟通对象应该包括所有项目干系人，而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。

其次应当确定协作模式与沟通方式。

沟通方式如会议、使用电话、qq、内部邮件、外部邮件、quickplace、聊天室等等。

其中邮件沟通应当说明主送人、抄送人，聊天室沟通方式应当约定时间周期。

而协作模式主要说明在出现什么状况的时候各个角色应当(主动)采取什么措施，包括沟通，如何互相配合来共同完成某项任务。

定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等。

3.3.1项目团队内部协作。

本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。

3.3.2项目接口人员。

应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括:。

a、负责本项目同用户的接口人员;。

c、负责本项目同分包方的接口人员。

3.3.3项目团队外部沟通与协作模式。

项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。

本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录办法等内容。

明确最终用户、直接用户及其所在本企业/部门名称和联系电话。

明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。

确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。

4实施计划。

4.1风险评估及对策。

识别或预估项目进行过程中可能出现的风险。

应该分析风险出现的可能性(概率)、造成的影响、根据影响应该采取的对策，采取的措施。

风险识别包括识别内在风险及外在风险。

内在风险是指项目工作组能加以控制和影响的风险，如人事任免和成本估计等。

外在风险指超出项目工作组等控制力和影响力之外的风险，如市场转向或政府行为等。

风险的对策包括:避免:排除特定危胁往往靠排除危险起源;减缓:减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数;吸纳:接受一切后果，可以是积极的(如制定预防性计划来防备风险事件的发生)，也可以是消极的(如某些费用超支则接受低于预期的利润)。

对于软件开发项目而言，在分析、识别和管理风险上投入足够的时间和人力可以使项目进展过程更加平稳，提高项目跟踪和控制的能力，由于在问题发生之前已经做了周密计划，因而对项目的成功产生更加充分的信心。

1)工程/规模/进度上的风险。

2)技术上的风险。

3)用户体制上的问题。

4)其它:应该包含此处没有、但据推测有风险的项目。

4.2工作流程。

说明项目采用什么样的工作流程进行。

如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己创建的工作流程。

不同的流程将影响后面的工作计划的制定。

必要时画出本项目采用的工作流程图及适当的文字说明。

4.3总体进度计划。

这里所说的总体进度计划为高层计划。

作为补充，应当分阶段制定项目的阶段计划，这些阶段计划不在这份文档中，当要以这份总体计划为依据。

总体进度计划要依据确定的项目规模，列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果，在阶段时间安排中要考虑项目阶段成果完成、提交评审、修改的时间。

对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作，给出每项工作任务的预定开始日期、完成日期及所需的资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件(里程碑)。

例如。

需求评审。

设计评审。

表格中检查点/里程碑等阶段划分为举例，实际作业阶段划分、阶段成果等请根据项目需要确定。

制定软件项目进度计划可以使用一些专门的工具，最常用的是microsoft的project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但无法完全代替项目计划书，特别是一些主要由文字来说明的部分。

小规模的项目可简便地使用excel作为辅助工具。

关于如何使用这些工具不在此作详细说明。

1)对于系统需求和项目目标的掌握程度。

如开始时对于系统需求和项目目标只有比较数的了解，就只能制定出比较粗的进度计划，等到需求阶段或设计阶段结束，就应该进一步细化进度计划。

2)软件系统规模和项目规模，这两个不是一个概念。

软件系统规模往往是从功能点的估算或其他估算方式得来的，而项目规模还要考虑对文档数量与质量的要求，使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。

例如，完成一个大型的系统，在一定的时间内一个人或几个人的智力和体力是承受不了的。

由于软件是逻辑、智力产品，盲目增加软件开发人员并不能成比例地提高软件开发能力。

相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理方面的问题将更为严重。

3)软件系统复杂程度和项目复杂程度:和软件系统规模和项目规模一样，软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度，而项目的复杂程度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度，多项目情况下资源保障的情况，等等等等。

软件系统的规模与软件系统的复杂程度未必是成比例的关系;同样项目的规模与项目的复杂程度未必是成比例的关系。

4)项目的工期要求，就是项目的紧急程度。

有些项目规模大，却因为与顾客签订了合同，或者为了抢先占领市场，工期压缩得很紧，这时就要考虑如何更好地合理安排进度，多增加人选多采用加班的方式是一种万不得已的选择。

增加人选除了增加人的成本外必定会增加沟通的成本(熟悉项目任务所需要的时间);加班如果处理不好会造成情绪上的问题，也可能会因为过于忙碌而无法顾及质量，造成质量的下滑。

5)项目成员的能力。

这些能力包括项目经理的管理能力，系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力，以及企业或项目团队激发出这些能力的能力。

从另外一个角度看还有总体上对客户行业业务的熟悉程度;对于建模工具、开发工具、测试工具等技术的掌握程度;企业内部对行业业务知识和主要技术的知识积累。

4.4.1质量保证计划。

执行质量评审活动，对过程质量进行控制。

规模较大的项目应当单独编写《软件开发项目质量计划》。

根据gb/t12504计算机软件质量保证计划规范，内容包括:。

l引言(本章节包括质量计划的目的、定义、参考资料)。

l管理(描述负责软件质量管理的机构、任务及其相关的职责)。

l文档(列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则)。

l标准、条例和约定(列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施)。

l评审和检查(规定所要进行的技术和管理两个方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。

至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查)。

l软件配置管理(编制有关配置管理条款，或在“4.4.4配置管理计划”中说明，或引用按照《gb/t12505计算机软件配置管理计划规范》单独制定的文档)。

l工具、技术和方法(指明用于支持特定软件项目质量管理工作的工具、技术和方法，指出它们的目的和用途)。

l媒体控制(说明保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化)。

l对供货单位的控制(供货单位包括项目承办单位、软件销售单位、软件开发单位。

规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。

)

l记录的收集、维护和保存(指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限)。

4.4.2进度控制计划。

(可直接引用以下描述或根据项目情况制定本节内容)。

本项目的进度监控执行本企业《项目管理规范》，由本企业过程控制部门如质量管理部统一进行监控，并保留在监控过程中产生的日常检查记录。

4.4.3预算监控计划。

说明如何检查项目预算的使用情况。

根据项目情况需要制定。

4.4.4配置管理计划。

编制有关软件配置管理的条款，或引用按照gb/t12505单独制订《配置管理计划》文档。

在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。

还必须规定用以维护和存储软件受控版本的方法和设施;必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

根据《gb/t12505计算机软件配置管理计划规范》，软件配置管理计划内容如下:。

l引言(本章节包括质量计划的目的、定义、参考资料)。

l管理(描述负责软件配置管理的'机构、任务、职责及其有关的接口控制。

)

l软件配置管理活动(描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等到四方面的软件配置管理活动的需求。

)

l工具、技术和方法(指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法)。

l对供货单位的控制(供货单位是指软件销售单位、软件开发单位或软件子开发单位。

必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求)。

l记录的收集、维护和保存(指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施，并指明要保存的期限)。

5支持条件。

说明为了支持本项目的完成所需要的各种条件和设施。

5.1内部支持。

逐项列出项目每阶段的支持需求(含人员、设备、软件、培训等)及其时间要求和用途。

例如，设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境，逐项列出有关到货日期、使用时间的要求。

5.2客户支持。

列出对项目而言需由客户承担的工作、完成期限和验收标准，包括需由客户提供的条件及提供时间。

5.3外包(可选)。

列出需由外单位分合同承包者承担的工作、完成时间，包括需要由外单位提供的条件和提供的时间。

6预算。

6.1人员成本。

列出产品/项目团队每一个人的预计工作月数。

列出完成本项目所需要的劳务(包括人员的数量和时间)。

劳务费一般包括工资、奖金、补贴、住房基金、退休养老金、医疗保险金。

6.2设备成本。

设备成本包括:原材料费，设备购置及使用费。

列出拟购置的设备及其配置和所需的经费。

列出拟购置的软件及其版本和所需的经费。

使用的现有设备及其使用时间。

6.3其它经费预算。

列出完成本项目所需要的各项经费，包括差旅费、资料费、通行费、会议费、交通费、办公费、培训费、外包费等，包括:。

(1)差旅费(旅费、出租)(含补贴)。

(2)资料费(图书费、资料费、复印费、出版费)。

(3)通信费(市话长话费、移动通信费、上网费、邮资)。

(4)会议费(鉴定费、评审会、研讨费、外事费等)。

(5)办公费(购买办公用品)。

(6)协作费(业务协作招待费、项目团队加班伙食费)。

(7)培训费(培训资料编写费、资料印刷费、产地费、设备费)。

其他(检测、外加工费、维修费、消耗品、低易品、茶话会等)。

列出完成本项目需要的所有经费预算(上述各项费用之和)。

7关键问题。

逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目成败的影响。

8专题计划要点。

专题计划也就是因为项目的需要在本文档之外独立建立的计划，本节说明本项目开发中需要制定的各个专题计划的要点。

专题计划可能包括分合同计划、分项目计划、项目团队成员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装部署计划。

参考文献。

1.1编写目的。

1.2背景。

1.3定义。

1.4参考资料。

1.5标准、条约和约定。

2项目概述。

2.1项目目标。

2.2产品目标与范围。

2.3假设与约束。

2.5应交付成果。

2.5.1需完成的软件。

2.5.2需提交用户的文档。

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其它经费预算。

7关键问题。

8专题计划要点。

1.1编写目的。

说明编写这份项目计划的目的，并指出预期的读者。

作用:本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。

注意这里的“目的”不是“项目目标”，而是为了说明本文档的目的与作用。

“项目目标”在2.1中说明。

意义:使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。

开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定，项目生命周期所有活动的行动基础，以便项目团队根据本计划书开展和检查项目工作。

”

例如可以这么写:为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。

常见的问题:把项目本身的“项目目标”误作编制项目开发计划的目的。

1.2背景。

主要说明项目的来历，一些需要项目团队成员知道的相关情况。

主要有以下内容:。

项目的名称:经过与客户商定或经过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“xx系统”开发的项目名称是“xx系统开发”。

项目的委托单位:如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方;如果是自行研发的软件产品，项目的委托单位就是本企业。

项目的用户(单位):软件或网络的使用单位，可以泛指某个用户群。

注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。

如海关的报关软件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。

项目的任务提出者:本企业内部提出需要完成此项目的人员，一般是领导或商务人员;注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。

如果是内部开发项目，则两者的区别在于前者指人，后者指单位。

项目的主要承担部门:有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门(也有的分为不同事业部)。

项目的特点就是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。

需要根据项目所涉及的范围确定本项目的主要承担部门。

项目建设背景:从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。

这有利于项目成员更好地理解项目目标和各项任务。

例句:根据《某部关于某建设工作的实施意见》精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。

目前对于某建设工作的工作主要采用计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划，某建设工作单位手工上报建设工作进度情况的方式，而全市的建设工作有数百个，加上前期建设工作的数量和今后某市建设发展的趋势，建设工作的数量将越来越多，原来的工作模式已经越来越无法适应市委市政府的要求。

因此，充分利用现代信息化、因特网的优势，建立“某市某建设工作信息报送反馈系统”，提高某建设工作信息报送反馈工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。

软件系统与其他系统的关系:说明与本系统有关的其他系统，说明它们之间的相互依赖关系。

这些系统可以是这个系统的基础性系统(一些数据、环境等必须依靠这个系统才能运行)，也可以是以这个系统为基础的系统，或者是两者兼而有之的关系、互相依赖的系统。

例句:本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在市政府网站。

软件系统与机构的关系:说明软件系统除了委托单位和使用单位，还与哪些机构组织有关系。

例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。

1.3定义。

列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。

注意尽量不要对一些业界使用的通用术语进行另外的定义，使它的含义和通用术语的惯用含义不一致。

1.4参考资料。

列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位，必要时说明得到这些文件资料和标准的途径。

本节与下一节的“标准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”，因为“参考”的不一定是“必须遵守”的。

常用资料如:。

本项目的合同、标书、上级机关有关通知、经过审批的项目任务书;。

属于本项目的其他已经发表的文件;。

本文档中各处引用的文件、资料，包括所要用到的软件开发标准。

1.5标准、条约和约定。

列出在本项目开发过程中必须遵守的标准、条约和约定。

例如:相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。

“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得;“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。

参考资料的内容应该涵盖“标准、条约和约定”。

2项目概述。

2.1项目目标。

设定项目目标就是把项目要完成的工作用清晰的语言描述出来，让项目团队每一个成员都有明确的概念。

注意，不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。

注意“要完成一个系统”只是一个模糊的目标，它还不够具体和明确。

明确的项目目标应该指出了服务对象，所开发软件系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。

项目目标应当符合smart原则:。

lsspecific明确的陈述。

lmmeasurable可以衡量的结果。

laattainable可以达成的目标。

lrrealistic合理的，现实的或者说是能和实际工作相结合。

lttrackable可以跟踪的。

项目目标可以进行横向的分解也可以进行纵向的分解。

横向分解一般按照系统的功能或按照建设单位的不同业务要求，如分解为第一目标、第二目标等等;纵向的分解一般是指按照阶段，如分解为第一阶段目标、第二阶段目标等等，或近期目标、中期目标、远期目标等等。

阶段目标一般应当说明目标实现的较为明确的时间。

一般要在说明了总目标的基础上再说明分解目标，可加上“为实现项目的总目标，必须实现以下三个阶段目标······”

2.2产品目标与范围。

根据项目输入(如合同、立项建议书、项目技术方案、标书等)说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。

对项目成果(软件系统)范围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。

软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。

产品目标如“提高工作信息报送反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强度。

”

2.3假设与约束。

对于项目必须遵守的各种约束(时间、人员、预算、设备等)进行说明。

这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。

假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成。

如:“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”

约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。

假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性(概率)、造成的影响、应当采取的相应措施。

说明为实现项目的目标需要进行那些工作。

在必要时，可描述与合作单位和用户的工作分工。

注意产品范围与项目工作范围的不同含义。

产品范围界定:软件系统产品本身范围的特征和功能范围。

工作范围界定:为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。

产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照计划来检验的。

这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。

2.5应交付成果。

2.5.1需完成的软件。

列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。

其中软件对象可能包括:源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。

2.5.2需提交用户的文档。

列出需要移交给用户的每种文档的名称、内容要点及存储形式，如需求规格说明书、帮助手册等。

此处需要移交用户的文档可参考合同中的规定。

2.5.3须提交内部的文档。

可根据《gb8567-88计算机软件产品开发文件编制指南》附录o:“文件编制实施规定的实例(参考件)”结合各企业实际情况调整制定《软件开发文档编制裁减衡量因素表》。

根据《因素表》确定项目对应的项目衡量因素取值，以确定本项目应完成的阶段成果。

将不适用于本项目的内容裁减，以减少不必要的项目任务和资源。

根据因素取值列出本项目应完成的阶段成果，说明本项目取值所在的区间，将其他因素值区间删除。

2.5.4应当提供的服务。

根据合同或某重点建设工作需要，列出将向用户或委托单位提供的各种服务，例如培训、安装、维护和运行支持等。

具体的工作计划如需要编制现场安装作业指导书、培训计划等，应当在本计划“4.3总体进度计划”中条列出。

2.6项目开发环境。

说明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。

环境可能不止一种，如开发工具可能需要针对java的，也需要针对c++的。

有些环境可能无法确定，需要在需求分析完成或设计完成后才能确定所需要的环境。

2.7项目验收方式与依据。

说明项目内部验收和用户验收的方式，如验收包括交付前验收、交付后验收、试运行(初步)验收、最终验收、第三方验收、专家参与验收等等。

项目验收依据主要有标书、合同、相关标准、项目文档(最主要是需求规格说明书)。

3项目团队组织。

3.1组织结构。

说明项目团队的组织结构。

项目的组织结构可以从所需角色和项目成员两个方面描述。

所需角色主要说明为了完成本项目任务，项目团队需要哪些角色构成，如项目经理、计划经理、系统分析员(或小组)、构架设计师、设计组、程序组、测试组等等。

组织结构可以用图形来表示，可以采用树形图，也可以采用矩阵式图形，同时说明团队成员来自于哪个部门。

除了图形外，可以用文字简要说明各个角色应有的技术水平。

注意虽然有一些通用的结构可以套用，但各种不同规模、不同形式的项目组织结构是不一样的。

如产品研发项目可能就不需要实施人员(小组)，但需要知识转移方面的人员(小组)。

而软件编码外包的项目则不需要程序员，测试人员也可以适当地减少。

3.2人员分工。

确定项目团队的的每个成员属于组织结构中的什么角色，他们的技术水平、项目中的分工与配置，可以用列表方式说明，具体编制时按照项目实际组织结构编写。

以下是一个示例。

3.3协作与沟通。

项目的沟通与协作首先应当确定协作与沟通的对象，就是与谁协作、沟通。

沟通对象应该包括所有项目干系人，而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。

其次应当确定协作模式与沟通方式。

沟通方式如会议、使用电话、qq、内部邮件、外部邮件、quickplace、聊天室等等。

其中邮件沟通应当说明主送人、抄送人，聊天室沟通方式应当约定时间周期。

而协作模式主要说明在出现什么状况的时候各个角色应当(主动)采取什么措施，包括沟通，如何互相配合来共同完成某项任务。

定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等。

3.3.1项目团队内部协作。

本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。

3.3.2项目接口人员。

应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括:。

a、负责本项目同用户的接口人员;。

c、负责本项目同分包方的接口人员。

3.3.3项目团队外部沟通与协作模式。

项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。

本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录办法等内容。

明确最终用户、直接用户及其所在本企业/部门名称和联系电话。

明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。

确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。

4实施计划。

4.1风险评估及对策。

识别或预估项目进行过程中可能出现的风险。

应该分析风险出现的可能性(概率)、造成的影响、根据影响应该采取的对策，采取的措施。

风险识别包括识别内在风险及外在风险。

内在风险是指项目工作组能加以控制和影响的风险，如人事任免和成本估计等。

外在风险指超出项目工作组等控制力和影响力之外的风险，如市场转向或政府行为等。

风险的对策包括:避免:排除特定危胁往往靠排除危险起源;减缓:减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数;吸纳:接受一切后果，可以是积极的(如制定预防性计划来防备风险事件的发生)，也可以是消极的(如某些费用超支则接受低于预期的利润)。

对于软件开发项目而言，在分析、识别和管理风险上投入足够的时间和人力可以使项目进展过程更加平稳，提高项目跟踪和控制的能力，由于在问题发生之前已经做了周密计划，因而对项目的成功产生更加充分的信心。

1)工程/规模/进度上的风险。

2)技术上的风险。

3)用户体制上的问题。

4)其它:应该包含此处没有、但据推测有风险的项目。

4.2工作流程。

说明项目采用什么样的工作流程进行。

如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己创建的工作流程。

不同的流程将影响后面的工作计划的制定。

必要时画出本项目采用的工作流程图及适当的文字说明。

4.3总体进度计划。

这里所说的总体进度计划为高层计划。

作为补充，应当分阶段制定项目的阶段计划，这些阶段计划不在这份文档中，当要以这份总体计划为依据。

总体进度计划要依据确定的项目规模，列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果，在阶段时间安排中要考虑项目阶段成果完成、提交评审、修改的时间。

对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作，给出每项工作任务的预定开始日期、完成日期及所需的资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件(里程碑)。

例如。

需求评审。

设计评审。

表格中检查点/里程碑等阶段划分为举例，实际作业阶段划分、阶段成果等请根据项目需要确定。

制定软件项目进度计划可以使用一些专门的工具，最常用的是microsoft的project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但无法完全代替项目计划书，特别是一些主要由文字来说明的部分。

小规模的项目可简便地使用excel作为辅助工具。

关于如何使用这些工具不在此作详细说明。

1)对于系统需求和项目目标的掌握程度。

如开始时对于系统需求和项目目标只有比较数的了解，就只能制定出比较粗的进度计划，等到需求阶段或设计阶段结束，就应该进一步细化进度计划。

2)软件系统规模和项目规模，这两个不是一个概念。

软件系统规模往往是从功能点的估算或其他估算方式得来的，而项目规模还要考虑对文档数量与质量的要求，使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。

例如，完成一个大型的系统，在一定的时间内一个人或几个人的智力和体力是承受不了的。

由于软件是逻辑、智力产品，盲目增加软件开发人员并不能成比例地提高软件开发能力。

相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理方面的问题将更为严重。

3)软件系统复杂程度和项目复杂程度:和软件系统规模和项目规模一样，软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度，而项目的复杂程度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度，多项目情况下资源保障的情况，等等等等。

软件系统的规模与软件系统的复杂程度未必是成比例的关系;同样项目的规模与项目的复杂程度未必是成比例的关系。

4)项目的工期要求，就是项目的紧急程度。

有些项目规模大，却因为与顾客签订了合同，或者为了抢先占领市场，工期压缩得很紧，这时就要考虑如何更好地合理安排进度，多增加人选多采用加班的方式是一种万不得已的选择。

增加人选除了增加人的成本外必定会增加沟通的成本(熟悉项目任务所需要的时间);加班如果处理不好会造成情绪上的问题，也可能会因为过于忙碌而无法顾及质量，造成质量的下滑。

5)项目成员的能力。

这些能力包括项目经理的管理能力，系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力，以及企业或项目团队激发出这些能力的能力。

从另外一个角度看还有总体上对客户行业业务的熟悉程度;对于建模工具、开发工具、测试工具等技术的掌握程度;企业内部对行业业务知识和主要技术的知识积累。

4.4.1质量保证计划。

执行质量评审活动，对过程质量进行控制。

规模较大的项目应当单独编写《软件开发项目质量计划》。

根据gb/t12504计算机软件质量保证计划规范，内容包括:。

l引言(本章节包括质量计划的目的、定义、参考资料)。

l管理(描述负责软件质量管理的机构、任务及其相关的职责)。

l文档(列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则)。

l标准、条例和约定(列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施)。

l评审和检查(规定所要进行的技术和管理两个方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。

至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查)。

l软件配置管理(编制有关配置管理条款，或在“4.4.4配置管理计划”中说明，或引用按照《gb/t12505计算机软件配置管理计划规范》单独制定的文档)。

l工具、技术和方法(指明用于支持特定软件项目质量管理工作的工具、技术和方法，指出它们的目的和用途)。

l媒体控制(说明保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化)。

l对供货单位的控制(供货单位包括项目承办单位、软件销售单位、软件开发单位。

规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。

)

l记录的收集、维护和保存(指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限)。

4.4.2进度控制计划。

(可直接引用以下描述或根据项目情况制定本节内容)。

本项目的进度监控执行本企业《项目管理规范》，由本企业过程控制部门如质量管理部统一进行监控，并保留在监控过程中产生的日常检查记录。

4.4.3预算监控计划。

说明如何检查项目预算的使用情况。

根据项目情况需要制定。

4.4.4配置管理计划。

编制有关软件配置管理的条款，或引用按照gb/t12505单独制订《配置管理计划》文档。

在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。

还必须规定用以维护和存储软件受控版本的方法和设施;必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

根据《gb/t12505计算机软件配置管理计划规范》，软件配置管理计划内容如下:。

l引言(本章节包括质量计划的目的、定义、参考资料)。

l管理(描述负责软件配置管理的机构、任务、职责及其有关的接口控制。

)

l软件配置管理活动(描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等到四方面的软件配置管理活动的需求。

)

l工具、技术和方法(指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法)。

l对供货单位的控制(供货单位是指软件销售单位、软件开发单位或软件子开发单位。

必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求)。

l记录的收集、维护和保存(指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施，并指明要保存的期限)。

5支持条件。

说明为了支持本项目的完成所需要的各种条件和设施。

5.1内部支持。

逐项列出项目每阶段的支持需求(含人员、设备、软件、培训等)及其时间要求和用途。

例如，设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境，逐项列出有关到货日期、使用时间的要求。

5.2客户支持。

列出对项目而言需由客户承担的工作、完成期限和验收标准，包括需由客户提供的条件及提供时间。

5.3外包(可选)。

列出需由外单位分合同承包者承担的工作、完成时间，包括需要由外单位提供的条件和提供的时间。

6预算。

6.1人员成本。

列出产品/项目团队每一个人的预计工作月数。

列出完成本项目所需要的劳务(包括人员的数量和时间)。

劳务费一般包括工资、奖金、补贴、住房基金、退休养老金、医疗保险金。

6.2设备成本。

设备成本包括:原材料费，设备购置及使用费。

列出拟购置的设备及其配置和所需的经费。

列出拟购置的软件及其版本和所需的经费。

使用的现有设备及其使用时间。

6.3其它经费预算。

列出完成本项目所需要的各项经费，包括差旅费、资料费、通行费、会议费、交通费、办公费、培训费、外包费等，包括:。

(1)差旅费(旅费、出租)(含补贴)。

(2)资料费(图书费、资料费、复印费、出版费)。

(3)通信费(市话长话费、移动通信费、上网费、邮资)。

(4)会议费(鉴定费、评审会、研讨费、外事费等)。

(5)办公费(购买办公用品)。

(6)协作费(业务协作招待费、项目团队加班伙食费)。

(7)培训费(培训资料编写费、资料印刷费、产地费、设备费)。

其他(检测、外加工费、维修费、消耗品、低易品、茶话会等)。

列出完成本项目需要的所有经费预算(上述各项费用之和)。

7关键问题。

逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目成败的影响。

8专题计划要点。

专题计划也就是因为项目的需要在本文档之外独立建立的计划，本节说明本项目开发中需要制定的各个专题计划的要点。

专题计划可能包括分合同计划、分项目计划、项目团队成员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装部署计划。

说明本项目开发中需制订的各个专题计划(如分合同计划、开发人员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装计划等)的要点。

专业软件项目计划书（通用14篇）篇六

中国xx软件有限公司是以xx教授(原中国交大研究生)、xx教授(原中科院计算所研究生)携带在加拿大多年学习和研究的先进创新成果回国创业的一家软件企业。公司于20xx年7月在中国张江高科技园区注册，主要业务是开发具有自主版权和知识产权的大型通用数据库管理系统——xxsql，并基于xx数据库产品进行应用开发和推广。

xx软件的宗旨是以创新的核心技术为起点，以国际一流的专家为技术领路人，将核心技术转化成具有国际竞争力的商业产品，将xx软件建设成一个大型的基础软件和应用软件供应商。

xx软件的短期目标：基于xx数据库(xxsql)的“xx企业信息备份和搜索工具”能够在一些具体行业或项目中进行推广应用。初期市场开拓的目标在于建立和提高公司产品的信誉和客户对于产品的可接受程度，而非盲目追求数量增长。总之，首先使公司运营正常，实现良性现金流和一定的赢利空间，再求进一步发展，实现良好的投资回报。

xx软件的长期目标：开发和推广大型通用数据库管理系统及其应用产品。

公司目前的股份构成：

公司于20xx年7月成立，注册资金200万元人民币，主要用于产品的开发、测试，市场渠道的铺设。

公司成立以来成功申请了20xx年科技部中小企业技术创新基金(75万元)和20xx年中国市第一批软件和集成电路产业发展专项资金(50万元)。

公司的主要产品：“xx数据库管理系统(xxsql)”。

正在开发的产品有：“xx企业信息备份与搜索工具”。

公司还计划基于xx数据库建立“xx数据服务中心”，为广大中小企业用户提供数据集中维护及安全保障。

“xx数据库管理系统(xxsql)”是由两位创始人(xx、xx)在国外任教期间发明，通过与任教所在大学签定法律合同(见附件)，数据库的专利权、出版权及其相关知识产权都归属于两位创始人所有，目前数据库的所有知识产权已转到中国xx软件有限公司。

“xx企业信息备份与搜索工具”则是在中国研发的基于xx数据库的应用产品。中国xx软件有限公司拥有产品的所有知识产权。

目前企业搜索市场还处于起步阶段，还没有出现一家独大或几分天下的局面，因此，现在是进入企业搜索市场的最好时机。

xx的总体营销策略是：分别向中小企业、大型企业和服务运营商提供不同的细化产品，逐步开拓本地、国内、国际市场。

公司的核心团队由五人组成：

xx(公司创办人，现任总经理，x大学计算机系终身教授，人工智能专家);

王先生(x大学计算机系博士后，曾任加拿大著名软件公司高级系统分析师，数据库专家)。

公司的主要优势如下：

1) 企业搜索引擎的技术处在不断发展完善中，xx拥有自主的先进技术，创新能力强;

2) xx企业备份和搜索工具是基于xx自身的数据库产品研发的，充分利用了数据库的

高性能和安全机制，产品性价比高;

3) xx能快速灵活地向用户提供按需定制服务。

九、目前公司为实现目标的增资需求

为了抢占企业信息搜索的市场发展先机，xx需要的外部投资为750万元人民币，加上xx的预期销售收入及其他资金，致力于“xx企业信息备份与搜索工具”产品的市场开发。

公司计划在20xx年实现收支平衡，09年实现销售赢利，占据国内企业搜索市场有一定影响力的份额，打造xx软件品牌。

企业的产品经营和资本经营是相辅相成的，产品经营是基础，资本经营则是企业快速发展的助推器。公司此次计划筹集750万元的风险资金，主要用于“xx企业信息备份与搜索工具”的市场开发。

此次融资的资金筹措方式：股权融资(投资750万获取20%股权)或引进战略投资者。 投资方可通过股票上市或公司兼并的方式退出。

中国xx软件有限公司计划吸收750万元(人民币)风险资金，主要用于“xx企业信息备份与搜索工具”的市场开发。

投资方和xx软件有限公司可以组建新公司的方式或其他可行的方式进行合作，股份的最终分配方案可经由谈判确定。

专业软件项目计划书（通用14篇）篇七

说明编写这份项目开发计划的目的，并指出预期的读者。

1.2背景。

说明:。

a.待开发的软件系统的名称;。

b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;c.该软件系统同其他系统或其他机构的基本的相互来往关系。

1.3定义。

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料。

列出用得着的参考资料，如:。

a.本项目的经核准的计划任务书或合同、上级机关的批文;。

b.属于本项目的其他已发表的文件;。

c.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。

列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2项目概述。

2.1工作内容。

简要地说明在本项目的开发中须进行的各项主要工作。

2.2主要参加人员。

扼要说明参加本项目开发工作的主要人员的情况，包括他们的技术水平。

2.3产品。

2.3.1程序。

列出需移交给用户的程序的名称、所用的编程语言及存储程序的媒体形式，并通过引用有关文件，逐项说明其功能和能力。

2.3.2文件。

列出需移交给用户的每种文件的名称及内容要点。

2.3.3服务。

列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持的级别和服务的期限。

2.3.4非移交的产品。

说明开发集体应向本单位交出但不必向用户移交的产品(文件甚至某些程序)。

2.4验收标准。

对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。

2.5完成项目的最迟期限。

2.6本计划的批准者和批准日期

3实施计划。

3.1工作任务的分解与人员分工。

对于项目开发中需完成的各项工作，从需求分析、设计、实现、测试直到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。

3.2接口人员。

说明负责接口工作的人员及他们的职责，包括：

a.负责本项目同用户的接口人员;。

c.负责本项目同各分合同负责单位的接口人员等。

3.3进度。

对于需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作任务。

的预。

定开始日期、完成日期及所需资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件(即所谓“里程碑”)。

3.4预算。

逐项列出本开发项目所需要的劳务(包括人员的数量和时间)以及经费的预算(包括办公费、差旅费、机时费、资料费、通讯设备和专用设备的租金等)和来源。

3.5关键问题。

逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目的影响。

4支持条件。

说明为支持本项目的开发所需要的各种条件和设施。

4.1计算机系统支持。

逐项列出开发中和运行时所需的计算机系统支持，包括计算机、外围设备、通讯设备、模拟器、编译(或汇编)程序、操作系统、数据管理程序包、数据存储能力和测试支持能力等，逐项给出有关到货日期、使用时间的要求。

4.2需由用户承担的工作。

逐项列出需要用户承担的工作和完成期限。

包括需由用户提供的条件及提供时间。

4.3由外单位提供的条件。

逐项列出需要外单位分合同承包者承担的工作和完成的时间，包括需要由外单位提供的条件和提供的时间。

5专题计划要点。

专业软件项目计划书（通用14篇）篇八

一份好的项目计划书的特点是：关注产品、敢于竞争、充分市场调研，有力资料说明、表明行动的方针、展示优秀团队、良好的财务预计等几点，从而使合作伙伴会更了解项目的整体情况及业务模型，也能让投资者判断该项目的可盈利性。下面是关于软件项目计划书，请参考。

一、建设网站前的市场分析。

1、相关行业的市场是怎样的,市场有什么样的特点，是否能够在互联网上开展公司业务，软件项目计划书范文。

2、市场主要竞争者分析，竞争对手上网情况及其网站规划、功能作用。

3、公司自身条件分析、公司概况、市场优势，可以利用网站提升哪些竞争力，建设网站的能力（费用、技术、人力等）。

二、建设网站目的及功能定位。

2、整合公司资源，确定网站功能。根据公司的需要和计划，确定网站的功能：产品宣传型、网上营销型、客户服务型、电子商务型等。

3、根据网站功能，确定网站应达到的目的作用。

4、企业内部网（intranet)的建设情况和网站的可扩展性。

三、网站技术解决方案。

根据网站的功能确定网站技术解决方案。

1、采用自建服务器，还是租用虚拟主机。

2、选择操作系统，用unix,linux还是window2000/nt。分析投入成本、功能、开发、稳定性和安全性等。

3、采用系统性的解决方案（如ibm,hp）等公司提供的企业上网方案、电子商务解决方案？还是自己开发。

4、网站安全性措施，防黑、防病毒方案。

5、相关程序开发。如网页程序asp、jsp、cgi、数据库程序等。

四、网站内容规划。

1、根据网站的目的和功能规划网站内容，一般企业网站应包括：公司简介、产品介绍、服务内容、价格信息、联系方式、网上定单等基本内容。

2、电子商务类网站要提供会员注册、详细的商品服务信息、信息搜索查询、定单确认、付款、个人信息保密措施、相关帮助等。

3、如果网站栏目比较多，则考虑采用网站编程专人负责相关内容。注意：网站内容是网站吸引浏览者最重要的因素，无内容或不实用的信息不会吸引匆匆浏览的访客。可事先对人们希望阅读的信息进行调查，并在网站发布后调查人们对网站内容的满意度，以及时调整网站内容，工作计划《软件项目计划书范文》。

五、网页设计。

1、网页设计美术设计要求，网页美术设计一般要与企业整体形象一致，要符合ci规范。要注意网页色彩、图片的应用及版面规划，保持网页的整体一致性。

2、在新技术的采用上要考虑主要目标访问群体的分布地域、年龄阶层、网络速度、阅读习惯等。

3、制定网页改版计划，如半年到一年时间进行较大规模改版等。

六、网站维护。

1、服务器及相关软硬件的维护，对可能出现的`问题进行评估，制定响应时间。

2、数据库维护，有效地利用数据是网站维护的重要内容，因此数据库的维护要受到重视。

3、内容的更新、调整等。

4、制定相关网站维护的规定，将网站维护制度化、规范化。

七、网站测试。

网站发布前要进行细致周密的测试，以保证正常浏览和使用。主要测试内容：

1、服务器稳定性、安全性。

2、程序及数据库测试。

3、网页兼容性测试，如浏览器、显示器。

4、根据需要的其他测试。

八、网站发布与推广。

1、网站测试后进行发布的公关，广告活动。

2、搜索引掣登记等。

九、网站建设日程表。

各项规划任务的开始完成时间，负责人等。

十、费用明细。

各项事宜所需费用清单。

以上为网站规划书中应该体现的主要内容，根据不同的需求和建站目的，内容也会在增加或减少。在建设网站之初一定要进行细致的规划，才能达到预期建站目的。

专业软件项目计划书（通用14篇）篇九

甲方在此委托乙方进行xx软件的开发，为明确双方责任，经友好协商，双方达成以下协议：

第一条：项目的功能、平台架构、开发进度、交付方式等内容由载明。

第二条：甲方的权利和义务。

1.提供专人与乙方联络。

2.提供项目所需要的所有资料交给乙方，并保证资料的正确性。

3.及时支付费用，保证项目的开发费用及时到位。

4.本合同的相关作品、程序、文件源码的版权属甲方所有。

第三条：乙方的权利和义务。

1.提供专人与甲方联络。

2.按照项目进度要求及时完成系统的开发，同时保证项目质量。

3.协助甲方完成所开发系统的实施、培训以及维护。

4.开发完毕，乙方应将系统的文档、源代码移交给甲方，不得将其应用在其他企业。

5.不得将甲方开发内容泄露给第三方。

第四条：验收。

2.验收期限为2天时间。

第六条：付款方式。

1.合同签订后1个工作日内，甲方向乙方支付合同总价30%的预付款。

2.试运行完毕，甲方向乙方支付合同总价70%的合同款;。

第七条：维护。

2.甲方需要改动或需要委托乙方进行二次开发，甲方应同乙方另订协议，作为合同的附件，另收开发费用。

第八条违约责任。

1.任何一方有证据表明对方已经、正在或将要违约，可以中止履行本合同，但应及时通知对方。若对方继续不履行、履行不当或者违反本合同，该方可以解除本合同并要求对方赔偿损失。

2.因不可抗力而无法承担责任的一方，应在不可抗力发生的3天内，及时通知另一方。

3.一方因不可抗力确实无法承担责任，而造成损失的，不付赔偿责任。本合同所称不可抗力是指不能预见、不能克服并且不能避免的客观事件，包括但不限于自然灾害如洪水、地震、火灾和风暴等以及社会事件如战争、**、政府行为等。

第九条其它。

1.如果本合同任何条款根据现行法律被确定为无效或无法实施，本合同的其他所有条款将继续有效。此种情况下，双方将以有效的约定替换该约定，且该有效约定应尽可能接近原约定和本合同相应的精神和宗旨。

2.本合同经双方授权代表签字并盖章，自签订日起生效。

3.本合同一式两份，双方当事人各执一份，具有同等法律效力。

乙方：甲方。

法人代表：法人代表：

代理人：代理人：

日期：年月日日期：年月日

地址：地址：

电话：电话：

传真：传真：

开户银行：开户银行。

帐号：帐号：

专业软件项目计划书（通用14篇）篇十

软件产品，特别是行业解决方案软件产品不同于一般的商品，用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容，每个阶段下面有不同的工作事项，各个阶段之间都是承上启下关系，上一阶段的顺利完成是保证下一阶段的工作开展的基础。下面将按照每个项目实施阶段分别介绍。

此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。

此阶段主任务：

公司：在。

合同。

签定后，指定项目经理，成立项目组，授权项目组织完成项目目标。

公司项目组：进行前期项目调研，与用户共同成立项目实施组织，编制《总体项目计划》，召开项目启动会。

商务经理：配合公司项目组，将积累的项目和用户信息转交给项目组。将项目组正式介绍给用户，配合项目组建立与用户的联系。

用户：成立项目实施组织，配合前期调研和召开启动会，签署《总体项目计划》和《项目实施协议》。

1、成立项目组。

部门经理接到实施申请后，任命项目经理，指定项目目标，由部门经理及项目经理一起指定项目组成员及成员任务，并报总经理签署《项目任务书》。

2、前期调研。

项目经理及项目组成员，在商务人员配合下，建立与用户的联系，对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中，商务经理积累了大量的信息，项目组首先应收集商务和合同信息，并与商务经理一起识别那些个体和组织是项目的干系人，确定他们的需求和期望，如何满足和影响这些需求、期望以确保项目能够成功。

《项目总体计划》是一个文件或文件的集合，随着项目信息不断丰富和变化，会被不断变更，主要介绍项目目标、主要项目阶段、里程碑、可交付成果。通常包括以下几方面内容：

4、启动会。

项目组与用户共同召开的宣布项目实施正式开始的会议。

会程安排如下：

共同组建项目实施组织，实施组织的权利和职责；双方签署《项目实施协议》。

项目组介绍《项目总体计划》和《项目实施协议》，包括以下内容：

项目目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配（包括用户的）；

项目实施中项目管理的必要性和如何进行项目管理，项目的质量如何控制；

项目实施中用户的参与和领导的支持的重要作用；

阶段验收、技术交接和项目结束后如何对用户提供后续服务。

此阶段的主要工作是软件公司的项目实施人员向用户调查用户对系统的需求，包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等，实施人员调研完成后，会编写《需求调研分析手册》，并交付用户进行确认，待用户对《需求调研分析手册》上所提到的需求确认完毕后，项目实施人员将以此为依据进行软件功能的实现。如果用户又提出新的需求，实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。需求调研阶段具体包括如下内容：

1、进行需求调研准备。

2、编制《需求调研计划》。

3、内部评审是否通过《需求调研计划》，项目组、部门经理、商务等人员根据合同要求和项目实际情况对《需求调研计划》草稿进行评审，如评审通过，则在稍后的时间内签署，如评审不通过则重新修改。

4、用户是否签署《需求调研计划》，如用户签署《需求调研计划》，则作为以后需求调研工作的指南。否则重新修改。

5、《需求调研计划》是否有变更，如果计划存在变更，则执行变更控制流程，否则按计划进行后续工作。

7、需求调研，项目组以《需求调研手册》为依据，从业务流程、单据使用、打印格式、报表查询几个方面展开深入和全面的调研，并搜集用户的个性化需求。

8、需求调研分析根据调研的结果，项目组和公司其他技术部门将进一步进行分析，确定合理、可行的需求，将分析结果形成《需求分析报告》草稿。

9、内部评审是否通过《需求分析报告》。项目组、部门经理、公司其他技术部门的人员对《需求分析报告》草稿进行评审，如评审通过，则在稍后由用户签署，如评审不通过则重新修改，直至内部评审通过。

10、编写及发出《需求分析报告确认通知》。项目组编写《需求分析报告确认通知》，发给用户，确定进行需求确认的相关事宜，告之相关部门及人员安排好工作，准时参与需求确认工作，为顺利完成需求确认工作做准备。

11、用户是否确认《需求分析报告》。如果用户确认，并签署了《需求分析报告》，则需求调研阶段工作结束，进行后续的软件功能实现的工作；如没有确认，则进一步进行调研、分析，直至用户最终确认并签署《需求分析报告》。双方签署了《需求分析报告》，需求调研工作结束之后，如果用户提出新的需求或是变更已有的需求，则执行需求新增及变更流程。

此阶段的主要工作是项目实施人员根据需求调研阶段确认的《需求调研分析手册》中的用户需求内容进行具体软件功能的实现工作。在软件功能实现的过程中，项目实施人员将记录软件实现的详细过程。便于公司售后服务之用。每一个实施技术人员必须严格按照要求记录、存档。按照调研要求的所有功能实现完毕后，项目实施人员将编制《软件功能确认表》，将定制好软件功能待用户确认，用户根据《软件功能确认表》上的功能逐一确定软件功能是否达到要求，对不满足要求的功能，项目实施人员将会记录下来并进行功能修改，直到满足用于要求。

此阶段的主要工作是项目实施人员指导用户进行系统标准化资料的准备工作，并对用户进行初装资料的软件操作培训，以便用户能够及时的将标准资料录入系统，初装完成后，项目实施人员会对资料初装的情况进行核查，为以后具体业务功能的开展做好基础。

系统培训阶段工作是整个项目实施工作中比较重要的工作，用户对软件的操作功能是否熟练将直接影响到后面的软件应用效果，所以软件公司和用户双方要对此阶段的工作给予足够的重视。要充分认识培训的重要性和艰巨性。在项目实施之前对用户的相关人员进行系统和规范的产品培训是非常必要的，达到让用户了解软件产品，最终自己能够解决使用中的具体的问题。

此阶段的培训工作中将用户参加产品培训的人员划分为三个层次：决策层、技术层、操作层，对不同层次的用户参加产品培训人员的培训内容分别是：

决策层：领导在实施中的作用与重要性、决策查询。

维护层：系统维护知识、操作方法。

操作层：操作方法。

具体的培训工作流程为：

1、调研培训信息：在培训开始前3天由用户实施负责人，将参加培训的部门和人员情况填入《受训部门汇总表》、《受训人员情况一览表》。

2、编制培训计划：结合调研结果，与用户实施负责人商议具体培训内容、时间，场地，人员等。项目组编制《培训计划》。

3、签署培训计划：用户签署《培训计划》，进一步确认培训安排。

4、发培训通知：培训开始前2天，按照签署的《培训计划》，将培训内容、时间，场地，人员等信息通知用户实施负责人。

5、搭建培训环境：公司项目组在培训开始前，将培训环境搭建及检查妥当，将培训提纲及培训手册准备好。

6、组织培训：公司项目组培训负责人与用户实施负责人组织相关人员参加培训，按培训制度严格考核。由用户将考勤情况填入《培训人员签到表》。

7、培训考核：公司项目组培训负责人与用户实施负责人组织受训人员参加上机及理论考试。

8、培训总结：公司项目组培训负责人与用户实施负责人一起将出勤情况及考核情况做出总结，填入《培训及考核统计表》，及时向相关负责人汇报。

此阶段的主要工作是在用户真实环境下，对用户网络及硬件设备进行测试，对软件系统进行容量、性能压力等测试测试及试运行的目的在于确保系统各项功能均能正常使用，并且符合用户签署的《需求分析报告》中描述的需求，同时把尽可能多的潜在问题在正式运行之前发现并改正；同时目的还在于在正式运行前用户的有关人员能进一步提高操作水平，掌握操作规范。此阶段的主要工作内容为：

1、编制计划：与用户实施负责人商议具体测试及试运行时间，地点，人员等安排，项目组编制《测试及试运行计划》。

2、签署计划：用户签署《测试及试运行计划》，进一步确认测试及试运行安排。

3、发测试及试运行通知：在测试及试运行开始前2天，按照签署的《测试及试运行计划》，将时间，地点，人员等信息通知用户实施负责人。

5、组织测试及试运行：用户相关各级领导给予全面配合，组织相关人员进行测试及试运行。

公司项目组负责担当指挥，检查用户人员组织情况并给予指导，跟踪检查如下情况：

跟踪单据流转状况。

跟踪新资料登录环节。

观察业务流程执行状况。

观察操作人员操作表现。

观察系统运行速度及异常表现。

观察关键数据的正确性。

及时纠正错误操作、对于新发生的问题及时与相关人员沟通，确定解决办法。

6、测试及试运行总结：测试及试运行完成，总结试运行中设备、软件的运行情况，总结试运行中业务流程和操作环节的情况，以书面总结形式将测试及试运行结果通知相关负责人。

此阶段是对项目总体的完成情况进行验收。验收分阶段进行，在每一项目阶段结束时，用户对这一阶段的可交付成果进行验收，在测试及试运行结束后，对系统进行总体验收。

专业软件项目计划书（通用14篇）篇十一

说明编写这份项目计划的目的，并指出预期的读者。

作用：本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。注意这里的“目的”不是“项目目标”，而是为了说明本文档的目的与作用。“项目目标”在2.1中说明。

意义：使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定，项目生命周期所有活动的行动基础，以便项目团队根据本计划书开展和检查项目工作。”

例如可以这么写：为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。

常见的问题：把项目本身的“项目目标”误作编制项目开发计划的目的。

1.2背景。

主要说明项目的来历，一些需要项目团队成员知道的相关情况。主要有以下内容：

项目的名称：经过与客户商定或经过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“xx系统”开发的项目名称是“xx系统开发”。

项目的委托单位：如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方;如果是自行研发的软件产品，项目的委托单位就是本企业。

项目的用户(单位)：软件或网络的使用单位，可以泛指某个用户群。注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。如海关的报关软件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。

项目的任务提出者：本企业内部提出需要完成此项目的人员，一般是领导或商务人员;注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。如果是内部开发项目，则两者的区别在于前者指人，后者指单位。

项目的主要承担部门：有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门(也有的分为不同事业部)。项目的特点就是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要根据项目所涉及的范围确定本项目的主要承担部门。

项目建设背景：从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。

例句：根据《某部关于某建设工作的实施意见》精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。

目前对于某建设工作的工作主要采用计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划，某建设工作单位手工上报建设工作进度情况的方式，而全市的建设工作有数百个，加上前期建设工作的数量和今后某市建设发展的趋势，建设工作的数量将越来越多，原来的工作模式已经越来越无法适应市委市政府的要求。因此，充分利用现代信息化、因特网的优势，建立“某市某建设工作信息报送反馈系统”，提高某建设工作信息报送反馈工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。

软件系统与其他系统的关系：说明与本系统有关的其他系统，说明它们之间的相互依赖关系。这些系统可以是这个系统的基础性系统(一些数据、环境等必须依靠这个系统才能运行)，也可以是以这个系统为基础的系统，或者是两者兼而有之的关系、互相依赖的系统。例句：本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在市政府网站。

软件系统与机构的关系：说明软件系统除了委托单位和使用单位，还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。

1.3定义。

列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义，使它的含义和通用术语的惯用含义不一致。

1.4参考资料。

列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位，必要时说明得到这些文件资料和标准的途径。本节与下一节的“标准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”，因为“参考”的不一定是“必须遵守”的。常用资料如：

本项目的合同、标书、上级机关有关通知、经过审批的项目任务书;。

属于本项目的其他已经发表的文件;。

本文档中各处引用的文件、资料，包括所要用到的软件开发标准。

1.5标准、条约和约定。

列出在本项目开发过程中必须遵守的标准、条约和约定。例如：相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。

“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得;“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。

2.1项目目标。

设定项目目标就是把项目要完成的工作用清晰的语言描述出来，让项目团队每一个成员都有明确的概念。注意，不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个模糊的目标，它还不够具体和明确。明确的项目目标应该指出了服务对象，所开发软件系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。

项目目标应当符合smart原则：

lsspecific明确的陈述。

lmmeasurable可以衡量的结果。

laattainable可以达成的目标。

lrrealistic合理的，现实的或者说是能和实际工作相结合。

lttrackable可以跟踪的。

项目目标可以进行横向的分解也可以进行纵向的分解。横向分解一般按照系统的功能或按照建设单位的不同业务要求，如分解为第一目标、第二目标等等;纵向的分解一般是指按照阶段，如分解为第一阶段目标、第二阶段目标等等，或近期目标、中期目标、远期目标等等。阶段目标一般应当说明目标实现的较为明确的时间。一般要在说明了总目标的基础上再说明分解目标，可加上“为实现项目的总目标，必须实现以下三个阶段目标······”

2.2产品目标与范围。

根据项目输入(如合同、立项建议书、项目技术方案、标书等)说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。对项目成果(软件系统)范围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。产品目标如“提高工作信息报送反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强度。”

2.3假设与约束。

对于项目必须遵守的各种约束(时间、人员、预算、设备等)进行说明。这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。

假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成。如：“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”

约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。

假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性(概率)、造成的影响、应当采取的相应措施。

2.4项目工作范围。

说明为实现项目的目标需要进行那些工作。在必要时，可描述与合作单位和用户的工作分工。

注意产品范围与项目工作范围的不同含义。

产品范围界定：软件系统产品本身范围的特征和功能范围。

工作范围界定：为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。

产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。

2.5应交付成果。

2.5.1需完成的软件。

列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。其中软件对象可能包括：源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。

2.5.2需提交用户的文档。

列出需要移交给用户的每种文档的名称、内容要点及存储形式，如需求规格说明书、帮助手册等。此处需要移交用户的文档可参考合同中的规定。

2.5.3须提交内部的文档。

可根据《gb8567-88计算机软件产品开发文件编制指南》附录o：“文件编制实施规定的实例(参考件)”结合各企业实际情况调整制定《软件开发文档编制裁减衡量因素表》。根据《因素表》确定项目对应的项目衡量因素取值，以确定本项目应完成的阶段成果。将不适用于本项目的内容裁减，以减少不必要的项目任务和资源。

根据因素取值列出本项目应完成的阶段成果，说明本项目取值所在的区间，将其他因素值区间删除。

2.5.4应当提供的服务。

根据合同或某重点建设工作需要，列出将向用户或委托单位提供的各种服务，例如培训、安装、维护和运行支持等。具体的工作计划如需要编制现场安装作业指导书、培训计划等，应当在本计划“4.3总体进度计划”中条列出。

说明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。环境可能不止一种，如开发工具可能需要针对java的，也需要针对c++的。有些环境可能无法确定，需要在需求分析完成或设计完成后才能确定所需要的环境。

2.7项目验收方式与依据。

说明项目内部验收和用户验收的方式，如验收包括交付前验收、交付后验收、试运行(初步)验收、最终验收、第三方验收、专家参与验收等等。项目验收依据主要有标书、合同、相关标准、项目文档(最主要是需求规格说明书)。

3.1组织结构。

说明项目团队的组织结构。项目的组织结构可以从所需角色和项目成员两个方面描述。所需角色主要说明为了完成本项目任务，项目团队需要哪些角色构成，如项目经理、计划经理、系统分析员(或小组)、构架设计师、设计组、程序组、测试组等等。组织结构可以用图形来表示，可以采用树形图，也可以采用矩阵式图形，同时说明团队成员来自于哪个部门。除了图形外，可以用文字简要说明各个角色应有的技术水平。

注意虽然有一些通用的结构可以套用，但各种不同规模、不同形式的项目组织结构是不一样的。如产品研发项目可能就不需要实施人员(小组)，但需要知识转移方面的人员(小组)。而软件编码外包的项目则不需要程序员，测试人员也可以适当地减少。

3.2人员分工。

确定项目团队的的每个成员属于组织结构中的什么角色，他们的技术水平、项目中的分工与配置，可以用列表方式说明，具体编制时按照项目实际组织结构编写。以下是一个示例。

3.3协作与沟通。

项目的沟通与协作首先应当确定协作与沟通的对象，就是与谁协作、沟通。沟通对象应该包括所有项目干系人，而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。

3.3.1项目团队内部协作。

本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。

3.3.2项目接口人员。

应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括：

a、负责本项目同用户的接口人员;。

c、负责本项目同分包方的接口人员。

3.3.3项目团队外部沟通与协作模式。

项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录办法等内容。明确最终用户、直接用户及其所在本企业/部门名称和联系电话。明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。

4.1风险评估及对策。

风险的对策包括：避免：排除特定危胁往往靠排除危险起源;减缓：减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数;吸纳：接受一切后果，可以是积极的(如制定预防性计划来防备风险事件的发生)，也可以是消极的(如某些费用超支则接受低于预期的利润)。

对于软件开发项目而言，在分析、识别和管理风险上投入足够的时间和人力可以使项目进展过程更加平稳，提高项目跟踪和控制的能力，由于在问题发生之前已经做了周密计划，因而对项目的成功产生更加充分的信心。

1)工程/规模/进度上的风险。

2)技术上的风险。

3)用户体制上的问题。

4)其它：应该包含此处没有、但据推测有风险的项目。

4.2工作流程。

说明项目采用什么样的工作流程进行。如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己创建的工作流程。不同的流程将影响后面的工作计划的制定。必要时画出本项目采用的工作流程图及适当的文字说明。

4.3总体进度计划。

这里所说的总体进度计划为高层计划。作为补充，应当分阶段制定项目的阶段计划，这些阶段计划不在这份文档中，当要以这份总体计划为依据。

总体进度计划要依据确定的项目规模，列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果，在阶段时间安排中要考虑项目阶段成果完成、提交评审、修改的时间。

对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作，给出每项工作任务的预定开始日期、完成日期及所需的资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件(里程碑)。

设计评审。

表格中检查点/里程碑等阶段划分为举例，实际作业阶段划分、阶段成果等请根据项目需要确定。

制定软件项目进度计划可以使用一些专门的工具，最常用的是microsoft的project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但无法完全代替项目计划书，特别是一些主要由文字来说明的部分。小规模的项目可简便地使用excel作为辅助工具。关于如何使用这些工具不在此作详细说明。

1)对于系统需求和项目目标的掌握程度。如开始时对于系统需求和项目目标只有比较数的了解，就只能制定出比较粗的进度计划，等到需求阶段或设计阶段结束，就应该进一步细化进度计划。

2)软件系统规模和项目规模，这两个不是一个概念。软件系统规模往往是从功能点的估算或其他估算方式得来的，而项目规模还要考虑对文档数量与质量的要求，使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。例如，完成一个大型的系统，在一定的时间内一个人或几个人的智力和体力是承受不了的。由于软件是逻辑、智力产品，盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理方面的问题将更为严重。

3)软件系统复杂程度和项目复杂程度：和软件系统规模和项目规模一样，软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度，而项目的复杂程度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度，多项目情况下资源保障的情况，等等等等。软件系统的规模与软件系统的复杂程度未必是成比例的关系;同样项目的规模与项目的复杂程度未必是成比例的关系。

4)项目的工期要求，就是项目的紧急程度。有些项目规模大，却因为与顾客签订了合同，或者为了抢先占领市场，工期压缩得很紧，这时就要考虑如何更好地合理安排进度，多增加人选多采用加班的方式是一种万不得已的选择。增加人选除了增加人的成本外必定会增加沟通的成本(熟悉项目任务所需要的时间);加班如果处理不好会造成情绪上的问题，也可能会因为过于忙碌而无法顾及质量，造成质量的下滑。

5)项目成员的能力。这些能力包括项目经理的管理能力，系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力，以及企业或项目团队激发出这些能力的能力。从另外一个角度看还有总体上对客户行业业务的熟悉程度;对于建模工具、开发工具、测试工具等技术的掌握程度;企业内部对行业业务知识和主要技术的知识积累。

4.4.1质量保证计划。

执行质量评审活动，对过程质量进行控制。规模较大的项目应当单独编写《软件开发项目质量计划》。根据gb/t12504计算机软件质量保证计划规范，内容包括：

l引言(本章节包括质量计划的目的、定义、参考资料)。

l管理(描述负责软件质量管理的机构、任务及其相关的职责)。

l文档(列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则)。

l标准、条例和约定(列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施)。

l评审和检查(规定所要进行的技术和管理两个方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查)。

l软件配置管理(编制有关配置管理条款，或在“4.4.4配置管理计划”中说明，或引用按照《gb/t12505计算机软件配置管理计划规范》单独制定的文档)。

l工具、技术和方法(指明用于支持特定软件项目质量管理工作的工具、技术和方法，指出它们的目的和用途)。

l媒体控制(说明保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化)。

l对供货单位的控制(供货单位包括项目承办单位、软件销售单位、软件开发单位。规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。)。

l记录的收集、维护和保存(指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限)。

4.4.2进度控制计划。

(可直接引用以下描述或根据项目情况制定本节内容)。

本项目的进度监控执行本企业《项目管理规范》，由本企业过程控制部门如质量管理部统一进行监控，并保留在监控过程中产生的日常检查记录。

4.4.3预算监控计划。

说明如何检查项目预算的使用情况。根据项目情况需要制定。

4.4.4配置管理计划。

编制有关软件配置管理的条款，或引用按照gb/t12505单独制订《配置管理计划》文档。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施;必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

说明为了支持本项目的完成所需要的各种条件和设施。

5.1内部支持。

逐项列出项目每阶段的支持需求(含人员、设备、软件、培训等)及其时间要求和用途。

例如，设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境，逐项列出有关到货日期、使用时间的要求。

5.2客户支持。

列出对项目而言需由客户承担的工作、完成期限和验收标准，包括需由客户提供的条件及提供时间。

5.3外包(可选)。

列出需由外单位分合同承包者承担的工作、完成时间，包括需要由外单位提供的条件和提供的时间。

6.1人员成本。

列出产品/项目团队每一个人的预计工作月数。

列出完成本项目所需要的劳务(包括人员的数量和时间)。

劳务费一般包括工资、奖金、补贴、住房基金、退休养老金、医疗保险金。

6.2设备成本。

设备成本包括：原材料费，设备购置及使用费。

列出拟购置的设备及其配置和所需的经费。

列出拟购置的软件及其版本和所需的经费。

使用的现有设备及其使用时间。

6.3其它经费预算。

列出完成本项目所需要的各项经费，包括差旅费、资料费、通行费、会议费、交通费、办公费、培训费、外包费等，包括：

(1)差旅费(旅费、出租)(含补贴)。

(2)资料费(图书费、资料费、复印费、出版费)。

(3)通信费(市话长话费、移动通信费、上网费、邮资)。

(4)会议费(鉴定费、评审会、研讨费、外事费等)。

(5)办公费(购买办公用品)。

(6)协作费(业务协作招待费、项目团队加班伙食费)。

(7)培训费(培训资料编写费、资料印刷费、产地费、设备费)。

其他(检测、外加工费、维修费、消耗品、低易品、茶话会等)。

列出完成本项目需要的所有经费预算(上述各项费用之和)。

逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目成败的影响。

专题计划也就是因为项目的需要在本文档之外独立建立的计划，本节说明本项目开发中需要制定的各个专题计划的要点。专题计划可能包括分合同计划、分项目计划、项目团队成员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装部署计划。

专业软件项目计划书（通用14篇）篇十二

白盒测试包括语句测试，判定测试，条件测试，判定-条件测试，条件组合测试和路径测试。

黑盒测试应用等价类划分法，边界值分析法，判定表分析，因果图法，正交试验法，功能图法和错误推测法。

压力测试，同时让很多人同时登录系统，测试同时最大登录数，以便做好系统的压力测试，以便防止同时过多的学生和教师登录时产生的系统崩溃，同时做好相应的对策。

三、教学管理系统的安装计划。

由于教学管理系统的特殊性，所以面对不同的人员要安装不同的系统。首先是学校的高级管理人员（例如校长，书记，年级主任），要有修改系统内容的权利，所以要安装最高级的系统，而任课教师只能查看与自己有关的课程与上课时间，同时拥有上传课件，教学相关软件的权利，所以要再安装教师机用的教学系统，而学生，在每个学生入学的时候要发放的安装程序，学生的权限最低，只有查看自己所选课程和下载相关课件和课程相关软件的权利。

专业软件项目计划书（通用14篇）篇十三

通过实施人力资源管理系统，提高人力资源部在日常人力资源操作性等事务的工作效率，为高层提供即时的高效的人力资源资数据查询、分析，为高层提供决策依据。同时有利于人力资源内部流程的规范与再造优化，以便更好地为员工（我们的客户）提供更好的服务。

1、人事管理类：人事档案履历管理、企业构架管理、入职/离职管理、合同管理、变动管理、奖惩管理及相应的统计分析、报表，支持领导查询。

2、考勤管理类：由于公司原有一个完善的考勤系统，现有系统只是导入原有考勤系统的数据。

3、招聘管理类：招聘需求分析、人员需求预测、招聘计划、招聘效果分析、招聘成本分析。

4、培训与发展类：

培训需求调查、培训计划、培训记录（员工、教师）、培训津贴计算、培训课程管理、培训成本分析，给个人提供职业生涯规划、建设人才梯队、给个人提供给予职位及发展需求的培训服务。

5、绩效考核管理类：导入相应的考核数据，为薪资提供数据。

6、薪资福利管理类：薪资政策设定、薪资公式设定、薪资报表、工资单、个人所得税表、社保管理、住房公积金管理。

本项目由人力资源部主管***批准，总经理***审核实施。

本项目涉及部门：总经办、人力资源部、财务部、网络部

项目主席：***

项目负责人：***

项目成员：****、****……

1、软件：采用市场上购买的hrms软件

2、硬件：采用组装服务器

系统软件是基于微软sql数据库运行，采用c/构架，个人用户装载客户端进行操作。

3、成本：总投资约***元

1、软件风险:由于我们采用的是盗版软件，有不可遇见的问题，现已经完成了初步的各个模块的测试，但是没有完成真实模拟的测试。

2、功能风险：由于此软件没有真实地进行全面的测试，需要在模拟运行一段时间后才能得知其实际运行能力。

3、人员风险：不见得每个人都是喜欢用这个系统，上这系统一开始比如有很多的数据录入工作加上一些不习惯或者其他因素，一定会有人员有抵触情绪，这需要主管的大力推行和及时开导解决。

1、前期工作（一个月）

2、实施准备阶段（1周）

资料准备；项目实施会议，确定实施时间表，确定人员工作细则；确定项目监督人员；hrms培训；系统安装调试，模拟测试。

3、模拟运行及用户化（2周）

资料上传；用户化，客户端安装，个人工作准则确定。

4、切换运行（一天）

实时工作上线切换，解决软件当中的问题；切换验收。

5、新系统运行

持续的维护及应用创新，及时新人的培训。

专业软件项目计划书（通用14篇）篇十四

第一章项目概述(理论。

教学。

时可用“引言”)。

1.1目的。

1.2项目背景。

1.3项目的范围和目标。

1.3.1范围描述(问题定义阶段产生，对应的文档为：《系统目标与范围说明书》)。

1.3.3性能(可选)。

1.3.4技术约束(可选)。

第二章项目估算。

2.1使用的历史数据2.2使用的评估技术。

2.3工作量、成本、时间估算。

第三章风险评估。

3.1风险识别。

列出最高的10大风险(数字10是参考)。

3.2风险应对策略。

对列出的风险应有哪些策略去应对。

第五章关键问题。

可以是技术因素、也可以是非技术因素，总而言之，是系统成败的最重要因素。

开发平台、开发工具、数据库平台。

第七章人员组织。

人员及其角色。

第八章附录。

相关文档、资料、数据等。