企业软件开发商业计划书样本.doc

软件开发商业计划书

-07-19   点击率： 2921

摘要
本文关键对软件开发项目计划书格式及关键内容编写关键点进行说明，对部分内容进行了举例说明。
关键词
项目、计划书、格式、编写说明
正文
一、项目计划书格式
依据《GB8567－88计算机软件产品开发文件编制指南》中项目开发计划要求，结合实际情况调整后《项目计划书》内容索引以下
1 引言
1.1 编写目标
1.2 背景
1.3 定义
1.4 参考资料
1.5 标准、条约和约定
2 项目概述
2.1项目目标
2.2产品目标和范围
2.3假设和约束
2.4 项目工作范围
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 其它经费预算
6.4 项目累计经费预算
7 关键问题
8专题计划关键点
二、项目计划书编写说明
1 引言
1.1 编写目标
说明编写这份项目计划目标，并指出预期读者。
作用本节是为了说明编制“项目计划书”亦即本文档意图和期望达成效果。注意这里“目标”不是“项目目标”，而是为了说明本文档目标和作用。“项目目标”在2.1中说明。
意义使项目组员和项目干系人了解项目开发计划书作用、期望达成效果。开发计划书作用通常全部是“项目组员和项目干系人之间共识和约定，项目生命周期全部活动行动基础，方便项目团体依据本计划书开展和检验项目工作。”
比如能够这么写为了确保项目团体按时保质地完成项目目标，便于项目团体组员愈加好地了解项目情况，使项目工作开展各个过程合理有序，所以以文件化形式，把对于在项目生命周期内工作任务范围、各项工作任务分解、项目团体组织结构、各团体组员工作责任、团体内外沟通协作方法、开发进度、经费预算、项目内外环境条件、风险对策等内容做出安排以书面方法，作为项目团体组员和项目干系人之间共识和约定，项目生命周期内全部项目活动行动基础，项目团体开展和检验项目工作依据。
常见问题把项目本身“项目目标”误作编制项目开发计划目标。
1.2 背景
关键说明项目来历，部分需要项目团体组员知道相关情况。关键有以下内容
项目名称经过和用户约定或经过立项手续统一确定项目名称，通常和所待开发软件系统名称有较大关系，如针对“XX系统”开发项目名称是“XX系统开发”。
项目委托单位假如是依据协议进行软件开发项目，项目委托单位就是协议中甲方；假如是自行研发软件产品，项目委托单位就是本企业。
项目用户（单位）软件或网络使用单位，能够泛指某个用户群。注意项目用户或单位有时和项目委托单位是同一个，有时是不一样。如海关报关软件、税务报税软件，委托单位是海关或税务机关，但使用用户或单位不仅有海关或税务机关，还包含需要报关、报税企业单位。
项目任务提出者本企业内部提出需要完成此项目人员，通常是领导或商务人员；注意项目任务提出者通常不一样于项目委托单位，前者通常是企业内部人员。假如是内部开发项目，则二者区分在于前者指人，后者指单位。
项目关键负担部门有些企业依据行业方向或工作性质不一样把软件开发分成不一样部门（也有分为不一样事业部）。项目特点就是其矩阵式组织，通常一个项目项目组员可能由不一样部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中多个组成。需要依据项目所包含范围确定本项目关键负担部门。
项目建设背景从政治环境上、业务环境上说明项目建设背景，说明项目大环境、来龙去脉。这有利于项目组员愈加好地了解项目目标和各项任务。
例句依据《某部相关某建设工作实施意见》精神，为了保障某建设工作正常实施，必需加强监督考评，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查关键内容，立即掌握进度，相关部门建立市某建设工作简报制度，立即反应全市某建设工作动态。
现在对于某建设工作工作关键采取计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划，某建设工作单位手工上报建设工作进度情况方法，而全市建设工作有数百个，加上前期建设工作数量和以后某市建设发展趋势，建设工作数量将越来越多，原来工作模式已经越来越无法适应市委市政府要求。所以，充足利用现代信息化、因特网优势，建立“某市某建设工作信息报送反馈系统”，提升某建设工作信息报送反馈工作效率，提升信息立即性、减轻各级相关工作人员劳动强度是很有必需和紧迫任务。
软件系统和其它系统关系说明和本系统相关其它系统，说明它们之间相互依靠关系。这些系统能够是这个系统基础性系统（部分数据、环境等必需依靠这个系统才能运行），也能够是以这个系统为基础系统，或是二者兼而有之关系、相互依靠系统。例句本系统中对外部办公部分如需要各个建设单位报送材料子系统应该挂在市政府网站。
软件系统和机构关系说明软件系统除了委托单位和使用单位，还和哪些机构组织相关系。比如部分系统需要遵守那些组织标准、需要经过那些组织机构测试才能使用等等、是否需要外包或和那些组织机构合作。
1.3 定义
列出为正确了解本计划书所用到专门术语定义、外文缩写词原词及汉字解释。注意尽可能不要对部分业界使用通用术语进行另外定义，使它含义和通用术语常见含义不一致。
1.4 参考资料
列出本计划书中所引用及相关文件资料和标准作者、标题、编号、发表日期和出版单位，必需时说明得到这些文件资料和标准路径。本节和下一节“标准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”，因为“参考”不一定是“必需遵守”。常见资料如
本项目协议、标书、上级机关相关通知、经过审批项目任务书；
属于本项目其它已经发表文件；
本文档中各处引用文件、资料，包含所要用到软件开发标准。
1.5 标准、条约和约定
列出在本项目开发过程中必需遵守标准、条约和约定。比如对应《立项提议书》、《项目任务书》、协议、国家标准、行业标准、上级机关相关通知和实施方案、对应技术规范等。
“参考资料”通常含有“物质”特征，通常要说明参考了什么，要说明在哪里能够取得；“标准、条约和约定”通常含有“精神”特征，通常是必需遵守，不说明在哪里能够取得。参考资料内容应该涵盖“标准、条约和约定”。
2 项目概述
2.1 项目目标
设定项目目标就是把项目要完成工作用清楚语言描述出来，让项目团体每一个组员全部有明确概念。注意，不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个凝目标，它还不够具体和明确。明确项目目标应该指出了服务对象，所开发软件系统最关键功效和系统本身比较深层次社会目标或系统使用后所起到社会效果。
项目目标应该符合SMART标准
l S Specific 明确陈说
l M Measurable 能够衡量结果
l A Attainable 能够达成目标
l R Realistic 合理，现实或说是能和实际工作相结合
l T Trackable 能够跟踪
项目目标能够进行横向分解也能够进行纵向分解♂向分解通常根据系统功效或根据建设单位不一样业务要求，如分解为第一目标、第二目标等等；纵向分解通常是指根据阶段，如分解为第一阶段目标、第二阶段目标等等，或近期目标、中期目标、远期目标等等。阶段目标通常应该说明目标实现较为明确时间。通常要在说明了总目标基础上再说明分解目标，可加上“为实现项目总目标，必需实现以下三个阶段目标······”
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总体进度计划”中条列出。
2.6 项目开发环境
说明开发本软件项目所需要软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。环境可能不止一个，如开发工具可能需要针对Java，也需要针对C++。有些环境可能无法确定，需要在需求分析完成或设计完成后才能确定所需要环境。
2.7 项目验收方法和依据
说明项目内部验收和用户验收方法，如验收包含交付前验收、交付后验收、试运行（初步）验收、最终验收、第三方验收、教授参与验收等等。项目验收依据关键有标书、协议、相关标准、项目文档（最关键是需求规格说明书）。
3 项目团体组织
3.1 组织结构
说明项目团体组织结构。项目组织结构能够从所需角色和项目组员两个方面描述。所需角色关键说明为了完成本项目任务，项目团体需要哪些角色组成，如项目经理、计划经理、系统分析员（或小组）、构架设计师、设计组、程序组、测试组等等。组织结构能够用图形来表示，能够采取树形图，也能够采取矩阵式图形，同时说明团体组员来自于哪个部门。除了图形外，能够用文字简明说明各个角色应有技术水平。
注意即使有部分通用结构能够套用，但多种不一样规模、不一样形式项目组织结构是不一样。如产品研发项目可能就不需要实施人员（小组），但需要知识转移方面人员（小组）。而软件编码外包项目则不需要程序员，测试人员也能够合适地降低。
3.2 人员分工
确定项目团体每个组员属于组织结构中什么角色，她们技术水平、项目中分工和配置，能够用列表方法说明，具体编制时根据项目实际组织结构编写。以下是一个示例。

3.3 协作和沟通
项目沟通和协作首先应该确定协作和沟通对象，就是和谁协作、沟通。沟通对象应该包含全部项目干系人，而项目干系人包含了全部项目团体组员、项目接口人员、项目团体外部相关人员等等。
其次应该确定协作模式和沟通方法。沟通方法如会议、使用电话、QQ、内部邮件、外部邮件、QuickPlace、聊天室等等。其中邮件沟通应该说明主送人、抄送人，聊天室沟通方法应该约定时间周期。而协作模式关键说明在出现什么情况时候各个角色应该（主动）采取什么方法，包含沟通，怎样相互配合来共同完成某项任务。定时沟通通常要包含项目阶段汇报、项目阶段计划、阶段会议等
3.3.1 项目团体内部协作
本节说明在项目开发过程中项目团体内部协作模式和沟通方法、频次、沟通结果统计措施等内容。
3.3.2 项目接口人员
应该说明接口工作人员即她们职责、联络方法、沟通方法、协作模式，包含
a、负责本项目同用户接口人员；
b、负责本项目同本企业各管理机构，如计划管理部门、协议管理部门、采购部门、质量管理部门、财务部门等接口人员；
c、负责本项目同分包方接口人员。
3.3.3 项目团体外部沟通和协作模式
项目团体外部包含企业内部管理帮助部门、项目委托单位、用户等等。本节说明在项目开发过程中项目团体内部和接口人员、用户沟通方法、频次、沟通结果统计措施等内容。明确最终用户、直接用户及其所在本企业／部门名称和联络电话。明确协作开发相关部门名称、经理姓名、负担工作内容和工作实施责任人姓名、联络电话。确定相关合作单位名称、责任人姓名、负担工作内容和实施人姓名、联络电话。
4 实施计划
4.1 风险评定及对策
识别或预估项目进行过程中可能出现风险。应该分析风险出现可能性（概率）、造成影响、依据影响应该采取对策，采取方法。风险识别包含识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响风险，如人事任免和成本估量等。外在风险指超出项目工作组等控制力和影响力之外风险，如市场转向或政府行为等
风险对策包含避免排除特定危胁往往靠排除危险起源；减缓降低风险事件预期资金投入来减低风险发生概率，和降低风险事件风险系数；吸纳接收一切后果，能够是主动（如制订预防性计划来防备风险事件发生），也能够是消极（如一些费用超支则接收低于预期利润）。
对于软件开发项目而言，在分析、识别和管理风险上投入足够时间和人力能够使项目进展过程愈加平稳，提升项目跟踪和控制能力，因为在问题发生之前已经做了周密计划，所以对项目成功产生愈加充足信心。
软件开发项目常见预估风险
1) 工程／规模／进度上风险
规模大，规模估算不正确甚至误差很大；就规模而言，用户要求交付期、费用很紧；预料外工作(测试未完时现场对应等)；
2) 技术上风险
使用新开发技术、新设备等，或是新应用组合，没有经验；是新行业或业务，没有经验；性能上要求很严；
3) 用户体制上问题
用户管理不严，恐怕功效决定、验收不能顺利地完成（或出现了延迟）；或恐怕功效会数次变更；和用户分担开发，恐怕工程会拖延（或出现了延迟）；用户或其它相关单位负担工作有可能延误；
4) 其它应该包含此处没有、但据推测有风险项目。
4.2 工作步骤
说明项目采取什么样工作步骤进行。如瀑布法工作步骤，原型法工作步骤、螺旋型工作步骤、迭代法工作步骤，也能够是自己创建工作步骤。不一样步骤将影响后面工作计划制订。必需时画出本项目采取工作步骤图及合适文字说明。
4.3 总体进度计划
这里所说总体进度计划为高层计划。作为补充，应该分阶段制订项目阶段计划，这些阶段计划不在这份文档中，当要以这份总体计划为依据。
总体进度计划要依据确定项目规模，列表项目阶段划分、阶段进度安排及每阶段应提交阶段结果，在阶段时间安排中要考虑项目阶段结果完成、提交评审、修改时间。
对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装布署、试运行、验收等工作，给出每项工作任务预定开始日期、完成日期及所需资源，要求各项工作任务完成前后次序和表征每项工作任务完成标志性事件（里程碑）。
比如

`

需求评审

设计评审
表格中检验点／里程碑等阶段划分为举例，实际作业阶段划分、阶段结果等请依据项目需要确定。
制订软件项目进度计划能够使用部分专门工具，最常见是MicrosoftProject作为辅助工具，功效比较强大，比较适合于规模较大项目，但无法完全替换项目计划书，尤其是部分关键由文字来说明部分。小规模项目可简便地使用EXCEL作为辅助工具。相关怎样使用这些工具不在此作具体说明。
制订软件项目进度计划应该考虑以下部分原因:
1）对于系统需求和项目目标掌握程度。如开始时对于系统需求和项目目标只有比较数了解，就只能制订出比较粗进度计划，等到需求阶段或设计阶段结束，就应该深入细化进度计划。
2）软件系统规耐项目规模，这两个不是一个概念。软件系统规模往往是从功效点估算或其它估算方法得来，而项目规模还要考虑对文档数量和质量要求，使用开发工具、新技术、多少复用、沟通方便程度、用户方情况、需要遵守标准规范等等等等。比如，完成一个大型系统，在一定时间内一个人或多个人智力和体力是承受不了。因为软件是逻辑、智力产品，盲目增加软件开发人员并不能成百分比地提升软件开发能力。相反，伴随人员数量增加，人员组织、协调、通信、培训和管理方面问题将更为严重。
3）软件系统复杂程度和项目复杂程度和软件系统规耐项目规模一样，软件系统复杂程度关键是考虑软件系统本身功效、架构复杂程度，而项目复杂程度关键是指项目团体组员组成、项目任务复杂程度、项目干系人复杂程度、需求调研难易程度，多项目情况下资源保障情况，等等等等。软件系统规模和软件系统复杂程度未必是成百分比关系；一样项目规模和项目复杂程度未必是成百分比关系。
4）项目工期要求，就是项目紧急程度。有些项目规模大，却因为和用户签署了协议，或为了抢先占领市场，工期压缩得很紧，这时就要考虑怎样愈加好地合理安排进度，多增加人选多采取加班方法是一个万不得已选择。增加人选除了增加人成本外肯定会增加沟通成本（熟悉项目任务所需要时间）；加班假如处理不好会造成情绪上问题，也可能会因为过于忙碌而无法顾及质量，造成质量下滑。
5）项目组员能力。这些能力包含项目经理管理能力，系统分析员分析能力、系统设计人员设计能力、程序员编码能力、测试人员测试能力，和企业或项目团体激发出这些能力能力。从另外一个角度看还有总体上对用户行业业务熟悉程度；对于建模工具、开发工具、测试工具等技术掌握程度；企业内部对行业业务知识和关键技术知识积累。
4.4 项目控制计划
4.4.1 质量确保计划
实施质量评审活动，对过程质量进行控制。规模较大项目应该单独编写《软件开发项目质量计划》。依据GB/T 12504 计算机软件质量确保计划规范，内容包含
l 引言（本章节包含质量计划目标、定义、参考资料）
l 管理（描述负责软件质量管理机构、任务及其相关职责）
l 文档（列出在该软件开发、验证和确定和使用和维护等阶段中需要编制文档，并描述对文档进行评审和检验准则）
l 标准、条例和约定（列出软件开发过程中要用到标准、条例和约定，并列出监督和确保实施方法）
l 评审和检验（要求所要进行技术和管理两个方面评审和检验工作，并编制或引用相关评审和检验规程，和经过是否技术准则。最少要进行软件需求评审、概要设计评审、软件验证和确定评审、软件系统功效检验、程序和文档物理检验）
l 软件配置管理（编制相关配置管理条款，或在“4.4.4 配置管理计划”中说明，或引用根据《GB/T 12505 计算机软件配置管理计划规范》单独制订文档）
l 工具、技术和方法（指明用于支持特定软件项目质量管理工作工具、技术和方法，指出它们目标和用途）
l 媒体控制（说明保护计算机程序物理媒体方法和设施，以免非法存取、意外损坏或自然老化）
l 对供货单位控制（供货单位包含项目承接单位、软件销售单位、软件开发单位。要求对这些供货单位进行控制规程，从而确保项目承接单位从软件销售单位购置、其它开发单位开发或从开发单位现存软件库中选择软件能满足要求需求。）
l 统计搜集、维护和保留（指明需要保留软件质量确保活动统计，并指出用于汇总、保护和维护这些统计方法和设施，并指明要保留期限）
4.4.2 进度控制计划
（可直接引用以下描述或依据项目情况制订本节内容）
本项目进度监控实施本企业《项目管理规范》，由本企业过程控制部门如质量管理部统一进行监控，并保留在监控过程中产生日常检验统计。
4.4.3 预算监控计划
说明怎样检验项目预算使用情况。依据项目情况需要制订。
4.4.4 配置管理计划
编制相关软件配置管理条款，或引用根据GB/T 12505单独制订《配置管理计划》文档。在这些条款或文档中，必需要求用于标识软件产品、控制和实现软件修改、统计和汇报修改实现状态和评审和检验配置管理工作等四方面活动。还必需要求用以维护和存放软件受控版本方法和设施；必需要求对所发觉软件问题进行汇报、追踪和处理步骤，并指出实现汇报、追踪和处理软件问题机构及其职责。
依据《GB/T 12505 计算机软件配置管理计划规范》，软件配置管理计划内容以下
l 引言（本章节包含质量计划目标、定义、参考资料）
l 管理（描述负责软件配置管理机构、任务、职责及其相关接口控制。）
l 软件配置管理活动（描述配置标识、配置控制、配置状态统计和汇报和配置检验和评审等到四方面软件配置管理活动需求。）
l 工具、技术和方法（指明为支持特定项目软件配置管理所使用软件工具、技术和方法，指明它们目标，并在开发者全部权范围内描述其使用方法）
l 对供货单位控制（供货单位是指软件销售单位、软件开发单位或软件子开发单位。必需要求对这些供货单位进行控制管理规程，从而使从软件销售单位购置、其它开发单位开发或从开发单位现存软件库中选择软件能满足要求软件配置管理需求）
l 统计搜集、维护和保留（指明要保留软件配置管理文档，指明用于汇总、保护和维护这些文档方法和设施，并指明要保留期限）