政府投资项目计划说明

2024-05-02

政府投资项目计划说明（精选6篇）

篇1：政府投资项目计划说明

政府采购项目注意事项说明

随着各区域的政府采购项目（以下简称政采）逐渐增多，为方便各业务人员更加清晰政采流程及各节点注意事项，特此编制本说明。

一、政采中的角色：

1、采购人：采购人即政府相关部门，对于我们公司业务来讲，通常为当地的农业农村局或土肥站，也称“发包方”。

2、：

代理人：代理人通常是指经过采购人授权来组织招标工作的机构，通常为 XX 招标代理公司。

3、供应商：供应商通常是指投标的生产厂家、经销商等，除有明确规定的供应商主体外，一般情况下供应商均为企业主体非个人。（我方或客户方）

4、联合体：联合体是指两家以上的独立非相关联的法人主体，就同一标段而共同组成的临时供应组织。

5、评审委员：评审委员通常由采购人或代理人组织成立，成员一般在当地的评审委员库中提取，评审组包括行业专家或非本行业的招标评委。（暗标时该团队会通过第三方单独向供应商收取“评审费”）

二、采购文件（招标文件、采购公告）中应注意的事项 1、报名时间、报名方式、报名地点、所带资质 1.1 线上报名：通常报名时间为 5 个工作日，如线上报名，需明确是否需要提前办理当地的 CA 证书（即企业信息入库资格，U 盘外形）。如新办，由项目地的业务人员到指定办理点办理后寄回公司，并确保

在报名截止前 1 个工作日能收到。

1.2 线下报名：通常报名时需要营业执照原件、法人授权委托书、相关资质证明等文件。按报名截止时间倒算，应在报名截止时间前 1 个工作日由公司邮寄到项目地业务人员手中，因此需要业务人员根据快递时间提前在钉钉提报原件使用审批。

1.3 报名前必须明确报名主体是生产厂商还是经销商，以便给予产品调整的空间；同时明确是主投方还是陪标方。报名前必须对此标的关系深度评估，无论我方还是客户方有多大的把握和关系能中标。

1.4 费用：购买 CA 证书、报名等相关费用，计入大区费用。、采购内容、采购金额、供货地点、供货时间 2.1 采购内容中的产品要符合公司现有的产品体系，不得以外部产品做为投标产品。

2.2 项目总价及每吨单价必须要依照公司价格体系核算，如存在负偏差且偏差额度较小的情况，需单独向销售总监申请。

2.3 供货时间要根据货量来计算生产、运输等时间消耗，以免造成延时违约。、分包、质疑与澄清的时间及方式 3.1 分包是指在某一个项目内，不同的产品或不同的服务内容而形成的独立小包，各小包之间无任何关联。所以我们必须要明确我们将要投哪一个产品或服务，即对应相应的“包号”。

3.2 质疑与澄清是指对采购文件内不明白或有冲突的事项而提出的疑问，根据采购文件要求的方式由供应商向代理人提出。、递交标书时间、开标时间、开标地点、开标方式、所带资料原件 4.1 线下纸质投标的递交标书时间一般情况下与开标时间为截止时间，即在开标当日规定的时间前携带封装好的纸质投标文件（标书）到指定的开标地点递交。

4.2 线上投标的递交时间按采购文件内要求的截止时间前上传，通常为开标前一个工作日。

4.3 开标时间无论是线上或线下均为统一时间。

4.4 开标地点：如线下开标，则前往采购文件内注明的指定地点、指定开标厅（会议室）；如线上开标，则无需派人前往，但应在开标前规定的时间内线上签到，并且在开标时间依照线上开标厅的指令进行投标文件的解密。在开标结束前，应保证投标用电脑正常工作、网络畅通，人员不得离开电脑，以备时时答疑或二次报价。

4.5 所带资料原件请提前通过钉钉申请审批，审批通过后由销售部负责借出核对资料的完整性，并快递至业务人员指定地址，确保最晚开标前 1 日到达。如有两地的同一原件使用日期相临，且快递无法保证时效的情况下，销售部会采用其他方式传递原件，以保投标正常进行。

4.6 费用：标书制作费用、原件快递费用由大区承担。、废标 5.1 资质文件不全、无法人授权委托书、采购文件中注明的登记证没有或登记证中的产品通用名、产品形态等不符合要求都会造成废标。

5.2 未按要求时间送达指定地点、未密封或密封不符合要求、未按采购文件要求签字或盖章的（以采购文件中要求为准，其他口头要求均

无效）都会造成废标。

5.3 按照《招标法》规定，一般招标最低不能低于 3 家供应商的有效投标，因此如果 3 家中的 1 家造成废标，很大可能会造成该项目“流标”，而导致重新报名、投标。

5.4 未按规定时间提交投标保证金的将视为废标。投标保证金由项目地业务人员通过钉钉申请交付，申请时必须注明项目名称、项目地、收款方名称及账号，并且注备“投标保证金”字样。、评分标准评审成员会按采购文件中的各评分标准分值项给予投标企业评分，除标准内规定的废标项外，其他的内容均不能造成废标，仅为综合评估的缺失。但在制作标书时我们要尽全面的按评分项编制，特别是技术部分的各种方案、措施等。

三、政采投标分工及流程 1、分工 1.1 双方共同制作投标文件。

1.2 销售部负责：商务文件制作、配合对接生产、研发部门的数据、资料获取、装订密封投标文件、配合整理开标所需原件并邮寄、线上相关事务处理。

1.3 业务人员负责：技术文件中的产品定位、报价、提供委托代理人的证件照片及信息、编制服务或技术方案、采购人和代理人的关系维护及线下相关事务、参加现场开标。、流程

2.1 销售部线上获取信息不定期发送给区总，或业务人员从客户处获取信息。

2.2 反馈给区总和销售总监助理判断该项目可行性。

2.3 由业务人员落实报名时间和方式，并办理当地的 CA 证书。销售部配合准备报名资料。

2.4 将 CA 证书和招标文件（如自行下载的需提供网址）寄回公司。

2.5 投标文件电子版制作完毕回传业务人员，经其确认后，销售部安排打印、装订、盖章、封包，随原件一并快递寄出。

篇2：政府投资项目计划说明

一、表格构成（一）政府集中采购计划表

（二）部门集中采购计划表

（三）分散采购计划表

（四）协议采购计划表

二、表格填报及概念说明

（一）政府采购计划表填报范围为主管部门及下属国家机关、事业单位、团体组织。企业单位不纳入填报范围。

（二）政府采购计划表由主管部门组织填写、汇总、并细化至基层预算单位，主管部门本级政府采购计划包含在政府采购总计划之内。

（三）部门报送政府采购计划表时，应同事附上本级及二级预算单位和基层预算单位政府采购计划表。

（四）单位填报政府采购计划表时，应根据本政府集中采购目录及政府采购限额标准，将采购项目按集中采购、部门集中采购、分散采购、协议采购项目进行分类，分别填报集中采购计划表、部门集中采购计划表、分散采购计划表和协议采购计划表。

（五）“品目代码”：集中采购计划表按本政府集中采购目录中的品目代码填写；分散采购计划案A.货物类、B.工程类、C.服务类三大类填写。

（六）“预算资金”是指财政一般预算支出（含政府性基金和

纳入预算管理的行政事业性收费、罚没收入等非税收入安排的支出），包括预算资金和预算执行中追加的资金。

（七）“纳入财政管理的其他资金”是指按规定缴入财政专户或经财政部门批准留用的非税收入等纳入财政管理的财政性资金。

（八）“视同财政性资金”是指以财政性资金作为还款来源的借贷资金、以事业单位和团体组织占有或使用的国有资产作担保的借贷资金。

（九）“单位自筹资金”是指采购单位按照政府采购拼盘项目要求，按规定用单位自有资金安排的资金。

（十）“需求时间”填写交货时间或工程开工时间。

（十一）“单位代码”按照省级单位部门预算的单位代码填列。

篇3：政府投资项目计划说明

新设立的国家重点研发计划,瞄准国民经济和社会发展主要领域的重大、核心、关键技术问题。

负责科研项目具体管理的专业机构,将采取事业单位法人治理结构,并接受监督、审核和评估。

由科技部、财政部共同起草的《关于深化中央财政科技计划(专项、基金等)管理改革的方案》(以下简称《方案》)已经党中央、国务院批准,即将发布实施。《方案》提出,政府不再直接管理具体项目,而是通过公开统一的国家科技管理平台宏观统筹,依托专业机构来具体管理。

科技部、财政部相关负责人就《方案》的内容、实施意义和进度安排等,进行了解读。

科技计划整合成5类,解决科技资源“碎片化”,更加聚焦国家目标

科技计划是国家引领和指导科技创新的重要载体,体现了国家意志、政策取向、战略布局和发展重点,对全社会的科研活动具有风向标和指挥棒的作用。

科技部科研条件与财务司司长张晓原说,目前的科技计划是改革开放以来,服务于不同发展阶段的需求先后设立的,解了燃眉之急,取得了一大批成果。但不同计划之间缺乏统筹设计、通盘考虑,科研经费多头管理,“九龙治水”的局面,引发项目重复申报等问题。

他认为,科技计划体系的诸多问题,突出表现在科技资源“碎片化”和取向聚焦国家战略目标不够两方面。这也反映我国当前科技宏观管理体制和政府部门的职能定位,与新科技革命和产业变革的要求不适应。

据介绍,《方案》将优化整合中央财政科技计划(专项、基金等)布局,建立科技资源配置的新机制,形成高效运转的治理体系。新的科技计划(专项、基金等)体系,主要包括五个方面,即:国家自然科学基金、国家科技重大专项、国家重点研发计划、技术创新引导专项(基金)和基地与人才专项。

不同科技计划将有明确的分工,比如国家自然科学基金重点支持基础研究和科学前沿探索,增强我国源头创新能力;国家科技重大专项则聚焦国家重大战略产品和重大产业化目标,在设定时限内进行集成式协同攻关。

张晓原介绍,国家重点研发计划的设立,是《方案》的亮点和重大改革举措。

当前,从“科学”到“技术”到“市场”的演进周期大为缩短,基础研究、应用研究、技术开发等边界日趋模糊,成果转化更加迅捷。国家重点研发计划正是为适应这一新形势而部署的。根据《方案》,新设立的国家重点研发计划将整合国务院各相关部门现有的竞争性科技计划(专项、基金等),瞄准国民经济和社会发展各主要领域的重大、核心、关键技术问题,以重点专项的方式,从基础前沿、重大共性关键技术到应用示范进行全链条设计,一体化组织实施,使其中的基础前沿研发活动具有更明确的需求导向和产业化方向。

财政部教科文司司长赵路认为,新的科技计划体系,明确了各类计划的边界,解决了重复交叉、定位不清的问题,打破多头管理、科研人员四处跑项目的局面。同时,新的科技计划管理方案,有利于提高财政资金使用效益。通过整合,激活了存量,使有限的中央财政民口科研经费更加聚焦国家战略目标,集中力量办大事,着力突破制约发展“卡脖子”的重大科学技术问题。

张晓原说,体制机制障碍成为制约我国科技创新的重要因素,中央把优化整合科技计划(专项、基金等)列为当前着力推进的改革任务,就是要以科技计划改革为突破口,带动科技其他方面的改革向纵深推进。

政府抓战略、规划、政策和监督,专业机构管理科研项目按照《方案》的总体目标,本次改革要强化顶层设计,打破条块分割,建立具有中国特色的以目标和绩效为导向的科技计划(专项、基金等)管理体制。

为此,《方案》提出推进优化整合的五个原则,即转变政府科技管理职能、聚焦国家重大战略任务、促进科技与经济深度融合、明晰政府与市场的关系和坚持公开透明和社会监督。

在转变政府科技管理职能中,《方案》明确要求,政府各部门不再直接管理具体项目,不再管理资金和项目的具体分配,重点抓战略、抓规划、抓政策、抓监督。科研项目的具体管理工作由专业机构负责。

张晓原说,政府不直接管理项目,是我国科技管理方式上的重大转变,也是对政府职能转变的一项重大挑战。

赵路说,政府不直接参与项目管理,将重点放在规划、布局、管理监督上,不仅有利于杜绝“跑部拿钱”的现象,还能倒逼政府转变职能,为科技创新提供好的服务。他说,依托专业机构管理科技项目,是国际上主要国家的通行做法。专业机构的设置又有多种模式,有的独立于政府部门之外,有的隶属于政府部门,还有委托社会化的非营利机构管理。根据我国实际情况,当前,主要依托现有具备科研管理专长的单位进行改造,形成若干符合要求的专业机构。随着科技体制改革和事业单位分类改革的深化,将促进专业机构逐步市场化和社会化。

张晓原表示,按照《方案》,将制定统一的专业机构管理制度和标准,专业机构要接受监督、审核、评估。专业机构将采取事业单位法人治理结构,而不简单的是某一个部门的下属单位。

《方案》还要求建立公开统一的国家科技管理平台。除明确规定依托专业机构管理项目外,还提出建立联席会议制度。联席会议将负责审议科技发展战略规划、科技计划(专项、基金等)的布局与设置、战略咨询与综合评审委员会的设立、专业机构的遴选择优等事项。此外,还将设立战略咨询和综合评审委员会,统一对科技发展战略规划和科技计划(专项、基金等)提供决策咨询。

张晓原表示,联席会议由科技部牵头,财政部、发改委等相关部门参加,部门和人选都固定下来,将会经常沟通,审议科技规划、调整科技计划(专项、基金等)布局,以保证决策的科学性。

今年启动国家科技管理平台建设,2017年完成体系整合优化

值得一提的是,本次改革针对的是所有实行公开竞争方式的中央财政科技计划(专项、基金等),它们占到中央财政民口科研经费一半以上,但不包括稳定支持的项目。

张晓原说,由于本次改革涉及现有科技计划体系的调整和相关政府部门科技管理职能的转变,较为艰巨和复杂。将按照整体设计、试点先行、逐步推进的原则开展,通过撤、并、转等方式,对现有科技计划(专项、基金等)按五类进行优化整合,大幅减少科技计划(专项、基金等)数量,整合形成的科技计划(专项、基金等)按照新的组织实施方式运行。

据介绍,2014年启动公开统一的国家科技管理平台建设,对部分具备条件的科技计划(专项、基金等)进行优化整合,在重点领域先行组织部分重点专项进行试点。2015年至2016年,基本建成公开统一的国家科技管理平台,基本完成各类科技计划(专项、基金等)的优化整合,实现科技计划(专项、基金等)安排和预算配置的统筹协调。经过3年的改革过渡期,到2017年,全面按照优化整合的新科技计划(专项、基金等)体系运行。届时,现有各类科技计划经费渠道将不再保留。

张晓原说,在3年过渡期内,对已经立项的研究项目将按照原有办法管理,直至完成结项。在此改革期间设立的新项目,将遵照《方案》的新管理方式施行。

篇4：政府将抛出新的投资计划

由于与刺激政策相关的投资增速放缓，重工业生产明显减速，二季度中国的GDP增长回落到10.3%。由于基数效应的变化，这样的减速是预料之中的。预计随着房地产调控措施的影响进一步显现，GDP增速将在2010年四季度降低至8-8.5%。2010年全年的GDP增长预计将为9.5-10%，而2011年将为8.7%。

在固定资产投资中，到目前为止房地产投资的迅猛增长部分抵消了基础设施投资减速的影响。同时，制造业的投资也已经开始恢复。未来，我们预计疲软的销售及停滞的价格将会导致新房开工下降和建筑业活动的减速，从而拉低房地产投资增速。正如我们过去多次说过的，房地产建设的放缓将会在2010年晚些时候带来对大宗商品和建筑材料需求的下滑，进一步压低重工业生产的增长。

我们预计经济增长将会“软着陆”，但下行的风险将来自两方面：发达经济体的二次探底；以及重工业行业增长下滑超预期（由于低于预期的建筑业活动和更多高耗能企业的关停）。如果这两方面的因素重叠在一起，GDP增速则有可能在2010年四季度或2011年一季度低于8%。

通胀将实现“神奇”的3%

从2010年年初开始，我们一直认为CPI通胀不是一个大问题，2010年全年平均应该在3%左右。尽管如此，6月CPI通胀下滑至2.9%还是有些意外。如我们所预料的，由于季节效应和一些一次性因素的消退，食品价格环比下降。同时，如服装、耐用品这些核心制成品的价格保持不变或有所下降，同样符合我们一贯的看法—目前全球的产出缺口会抑制核心通胀。但是，居住价格（包括房租、水电、装修材料及自有房成本）环比停止上涨有些让人惊讶。

在未来的几个月中，我们预计CPI通胀会再次回升至3%以上，随后在2010年年末回落。这是基于我们的以下假设：政府在今年会继续保持年度新增信贷7.5万亿的目标；对能源和资源价格的上调会推迟到2011年。我们继续保持今年CPI通胀为3%的预测，但把2011年的通胀预测下调到3.5%。

出口引擎并未真正回归

在最近强劲的出口增长基础上，我们2010年全年出口增长预测从18%上调到24%。6月出口增长了44%，最近几个月超过了进口增长。因此，贸易顺差从今年1季度的143亿美元反弹到二季度的412亿美元。除去价格因素的影响，我们预测净出口将在2010年给GDP增长贡献一个百分点。相比于2009年的-4个百分点的贡献，这是一个巨大的转折。

但这是否就意味着中国的出口引擎又回来了，贸易顺差占GDP的比重将回到上升的趋势呢？答案是否定的。确实，今年投资减速的影响已经被出口的强劲增长所抵消。但是，由于基数效应以及出口需求反弹的淡出，我们预测在2010年四季度出口增速将降到10%以下（有可能在12月零增长）。在中期，我们认为净出口对GDP增长的贡献率将降至零，尽管贸易顺差的绝对值仍会很大。这将支持我们对人民币兑美元汇率的预测—人民币兑美元今年将升值4%，并在随后的几年中继续以每年3-5%的速度升值。

关注新的投资计划

由于经济已经减速，对经济过热和资产泡沫的忧虑已经缓解。但同时对经济增长硬着陆的担心却已浮现。一方面，有人认为还需要更多的紧缩措施来压低房地产价格。而同时有人呼吁出台新的刺激或是放松宏观政策来预防中国经济出现“二次探底”。持后一种观点的人或许认为对中国来说，8%的GDP增速是太低了，而低于8%则意味着衰退。

我们认为目前经济活动的减速符合我们软着陆的预测，并估计政府在将来几个月仍会保持目前的宏观政策基调。对决策者来说，2010年上半年11%的GDP增速以及目前40%以上的出口增长很难说应该放松政策或推出新的刺激措施。

就房地产行业而言，决策者很有可能会等待目前调控措施的影响完全显现，而后再决定是否需要出台新的政策或是改变目前的政策方向。我们不认为房产税会很快出台。

货币政策方面，我们预测：（1）今年的信贷目标不会改变（新增贷款7.5万亿，贷款增长18%）；（2）2010年不会加息；加息有可能会等到2011年二季度初开始；（3）短期不会提高存款准备金率，但会增加央票的发行来冲销外汇资金的流入（估计在未来一年外汇流入将会重新增加）。

篇5：软件项目计划书编写说明

一、项目计划书格式

根据《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 编写目的

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

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

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

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

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

1.2 背景

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

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

项目的委托单位：如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方；如果是自行研发的软件产品，项目的委托单位就是本企业。项目的用户（单位）：软件或网络的使用单位，可以泛指某个用户群。注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。如海关的报关软件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。

项目的任务提出者：本企业内部提出需要完成此项目的人员，一般是领导或商务人员；注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。如果是内部开发项目，则两者的区别在于前者指人，后者指单位。项目的主要承担部门：有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门（也有的分为不同事业部）。项目的特点就是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要根据项目所涉及的范围确定本项目的主要承担部门。

项目建设背景：从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。例句：根据《某部关于某建设工作的实施意见》精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。

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

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

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

1.3 定义

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

1.4 参考资料

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

本项目的合同、标书、上级机关有关通知、经过审批的项目任务书；属于本项目的其他已经发表的文件；

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

1.5 标准、条约和约定

列出在本项目开发过程中必须遵守的标准、条约和约定。例如：相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得；“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。项目概述

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.1 组织结构

说明项目团队的组织结构。项目的组织结构可以从所需角色和项目成员两个方面描述。所需角色主要说明为了完成本项目任务，项目团队需要哪些角色构成，如项目经理、计划经理、系统分析员（或小组）、构架设计师、设计组、程序组、测试组等等。组织结构可以用图形来表示，可以采用树形图，也可以采用矩阵式图形，同时说明团队成员来自于哪个部门。除了图形外，可以用文字简要说明各个角色应有的技术水平。注意虽然有一些通用的结构可以套用，但各种不同规模、不同形式的项目组织结构是不一样的。如产品研发项目可能就不需要实施人员（小组），但需要知识转移方面的人员（小组）。而软件编码外包的项目则不需要程序员，测试人员也可以适当地减少。3.2 人员分工

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

3.3 协作与沟通

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

其次应当确定协作模式与沟通方式。沟通方式如会议、使用电话、QQ、内部邮件、外部邮件、QuickPlace、聊天室等等。其中邮件沟通应当说明主送人、抄送人，聊天室沟通方式应当约定时间周期。而协作模式主要说明在出现什么状况的时候各个角色应当（主动）采取什么措施，包括沟通，如何互相配合来共同完成某项任务。定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等

3.3.1 项目团队内部协作

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

3.3.2 项目接口人员

应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括： a、负责本项目同用户的接口人员；

b、负责本项目同本企业各管理机构，如计划管理部门、合同管理部门、采购部门、质量管理部门、财务部门等的接口人员；

c、负责本项目同分包方的接口人员。3.3.3 项目团队外部沟通与协作模式

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

4.1 风险评估及对策

识别或预估项目进行过程中可能出现的风险。应该分析风险出现的可能性（概率）、造成的影响、根据影响应该采取的对策，采取的措施。风险识别包括识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响的风险，如人事任免和成本估计等。外在风险指超出项目工作组等控制力和影响力之外的风险，如市场转向或政府行为等

风险的对策包括：避免：排除特定危胁往往靠排除危险起源；减缓：减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数；吸纳：接受一切后果，可以是积

极的（如制定预防性计划来防备风险事件的发生），也可以是消极的（如某些费用超支则接受低于预期的利润）。

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

规模大，规模估算不精确甚至误差很大；就规模而言，用户要求交付期、费用很紧；预料外的工作(测试未完时的现场对应等)； 2)技术上的风险

使用新的开发技术、新设备等，或是新的应用组合，没有经验；是新的行业或业务，没有经验；性能上的要求很严； 3)用户体制上的问题

用户管理不严，恐怕功能决定、验收不能顺利地完成（或者出现了延迟）；或者恐怕功能会多次变更；与用户分担开发，恐怕工程会拖延（或者出现了延迟）；用户或其他相关单位承担的工作有可能延误；

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

4.2 工作流程

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

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

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

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

需求评审

设计评审

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

定。

制定软件项目进度计划可以使用一些专门的工具，最常用的是Microsoft的Project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但无法完全代替项目计划书，特别是一些主要由文字来说明的部分。小规模的项目可简便地使用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 记录的收集、维护和保存（指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施，并指明要保存的期限）支持条件

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

逐项列出项目每阶段的支持需求（含人员、设备、软件、培训等）及其时间要求和用途。例如，设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境，逐项列出有关到货日期、使用时间的要求。5.2 客户支持

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

5.3 外包（可选）

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