推荐第1篇：软件开发项目管理实施方案.
项目管理实施方案
作为一个项目管理者,如何要成功的做好项目管理;首先必须先要明白的是在特定的领域中赋予这个角色所要实现的目标、承担的职责、以及项目管理者的具体工作内容是什么? 从我个人的浅见和角度以及我们所从事的IT领域来分析回答以上三个问题。 第一:目标
作为一个项目的管理者,必须要明确的知道自己的工作目标;我个人认为项目管理者的目标无非就是以下两点:
1、就是清晰明确地了解项目利害关系者的需求和期望,努力做到满足项目利害关系者的不同需求;项目利害关系者包括:项目团队成员和项目团队外成员(比如各部门的部门负责人和市场人员,客户等。
2、就是保证开发项目按需按时保质的完成。第二:职责
作为项目的管理者,首先要端正态度,要明确知道自己的工作职责,认识到这份工作职责的本质。项目管理者不是来管人的,而是来支持人的,是来协调资源的,是来营造一个适合团队成员比较认同的工作环境和氛围的,是来为一个共同的目标和大家一起战斗共同成长的。可以大概概括成以下几点:
1、建立有效的工作流程保证项目的顺利进行。
2、制定详细周密的项目计划。
3、跟踪,推动项目按计划进行。
4、积极解决项目过程中出现的问题和冲突。
5、调动开发团队的积极性,创造力,推动团队成员在项目过程中不断成长。
6、项目风险识别、风险评估、风险解决和风险管理策略以及做好突发风险的应急预案。
7、实现目标
第三:项目管理者的具体工作内容
最后一个是项目管理者的具体工作内容,作为项目管理者必须清晰的知道自己的工作范围和所要做的工作内容以及工作重心,分为以下六点:
1、项目前期阶段
对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求讨论,明确项目的目标、价值;确定项目范围、功能及优先级。组建项目团队,特别要搞清楚项目的key person(对产品有决定权的人。项目启动会议,相关的
利害关系人员都必须参加。
该阶段完成后的成果:确认后的最终软件需求规格说明书文档。
2、分析设计阶段
根据确认后的软件需求规格说明书,制定项目进度计划,工作任务分解(WBS;资源申请,项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源;数据库设计;系统设计;文档(包括Use Case、Demo系统原型、Test Case等;评审会议。
该阶段完成后的成果: A、User Case(系统用例; B、DEMO(系统原型;
C、系统设计文档(概要设计和详细设计; D、数据库设计文档。
最后对完成的成果,包括User Case和设计文档等进行评审。
3、执行阶段(开发和测试
准备开发环境、测试环境;跟踪,推动项目按计划进行;以周报的形式通报项目的进展情况。对项目的阶段成果进行评估,以确保该阶段完成的质量,包括代码审核、SQL 审核等。对需求变更进行控制管理;对项目风险进行管理;测试阶段BUG FIXED及改进、收集反馈意见。
4、发布阶段
包括制定项目发布计划,用户培训,发布上线。
5、上线后监控
数据监控(日志、服务器状态,根据监控出现的问题,及时进行BUG FIXED及改进或做补丁升级。
6、结束阶段
产品交付,项目总结会。
第四:基于以上三个问题所做的应对细则
要做好项目管理,并能确实解决好以上三个问题,实现目标、履行职责、完成工作中的具体内容,从我个人这几年的工作经验和面临的一些问题,还有所积累的一些项目管理中的
一些知识以及自己的观察和思考的角度看,应该要努力做好以下这几个方面的具体工作:
1、项目开发时间的估算
制定项目进度时间表的时候,需要估算每个任务所需的时间,其中开发任务中模块的分配和时间估算是其中最主要的部分;在分配模块和估算开发时间时需要遵循的原则和目标:
1、保证项目整体的进度。
2、有助于确保开发编码的质量。
3、有助于提高开发编码的速度。
在公司现有的技术框架下,开发人员主要的工作是投入在具体的商业逻辑上。通常每个模块所需的开发时间取决于以下三个因素:
1、所负责模块的商业逻辑的复杂程度。
2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度。
3、该模块技术实现上是否有技术难点;这里所谓的技术难点定义是:在现有系统中还未实现的、开发人员自身也未没接触过的技术。对于这样的难点,开发者没有相关的代码可以参考,自己也没有经验,所以需要投入一些时间研究解决。
模块分配和开发时间估算的步骤:
1、在划分好模块后,首先自己先估算一下每个模块所需要的开发时间。
2、然后召集所有开发人员,讨论模块的分配和开发时间估算。将划分好的模块,让开发人员从中挑选他们感兴趣的模块。这样做可以提高开发人员的主动性和参与性。在分配模块的时候还需从以下几方面考虑,以确保开发的速度和质量: A、相同类似的模块由同一人负责开发,比如用户管理的增删改由同一开发者负责。
这样做的好处就是开发者对相关逻辑会更加熟悉,同时接口的定义也会比较明确,沟通的成本比较低,同时功能实现的缺陷也相应的会降低。
B、技术难度比较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对这块逻辑比较了解的人负责。
3、模块分配完后,开发人员评估自己负责开发的模块所需要的时间。在此过程中最好做到要和开发者比较详细的讨论每个模块的技术实现,以便使时间的估算更加准确。
4、对开发人员估算的时间进行确认。在确认过程中作为项目管理者应参考以上提到的三个因素,同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的,将与技术人员探讨其中的缘由。对于时间周期比较长的任务,尽量将任务通过再细分的手段细化任务,争取每个任务的最长时间不超过3天;时间周期越长的任务,不确定性越高,风险也越高,越有可能成为项目的瓶颈,影响项目的进度。
2、Code Review Code Review是保证项目中代码质量非常重要的一个环节,在这一环中我们公司做的非常欠缺,把关不严格;这是导致每次测试后出现大量bug的主要原因,这一环需要纳入绩效考核中,实行责任追究制,实施重点监控。出现这样的薄弱环节,造成这样的原因,我想也是有很多因素造成的;比如开发人员对需求不是很明确,以自己比较主观的因素去完成任务的;还有对整个系统业务逻辑没有正确的清晰的认识的原因,以及对项目组成员培训不到位的原因等众多因素纠集在一起才产生的。
如何做好这方面的工作?首先编码要有“编码规范”文档,Code Review要有“代码审
核规范”文档:记录代码实现应该遵循的标准。通过这两个文档来规范开发人员的代码实现,代码编写者必须要严格按照规范来进行;代码审核者根据这些标准来Code Review代码,同时在Code Review过程中不断完善该文档。
在做好这些前期工作的前提下,分以下几个步骤来实施:
1、检查开发者的代码实现是否遵循了编码规范。
2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议。
3、代码编写者和代码审核者坐在一起,由代码编写者按照Use Case依次讲解自己负责
的代码和相关逻辑,从Web层-到Manage层再到Dao层;
4、代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的bug;对这
些bug记录在案。
5、代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。代码需要一
行一行静下心来看。同时代码又要全面的看,以确保代码整体上设计优良。
6、代码审核者根据审核的结果编写“代码审核报告”,“审核报告”中记录发现的问题
及修改建议,然后把“审核报告”发送给相关人员。
7、代码编写者根据“代码审核报告”给出的修改意见,修改好代码,有不清楚的地方
可积极向代码审核者提出。
8、代码编写者bug fixed完毕之后给出反馈。
9、代码审核者把Code Review中发现的有价值的问题更新到\"代码审核规范\"的文档中, 对于特别值得提醒的问题可群发email给所有技术人员。如果通过以上步骤,还因为是代码编写者的原因而出现严重的缺陷问题,将通过绩效考核来加深代码编写者的印象,并在周报会议上做通报批评。
3、需求变更管理
需求变更管理也是项目管理中最重要的一个环节,对需求变更管理的有效性将直接影响项目的成功与否。
对待需求变更的态度:
1、需求变更是不可避免的。
2、需求变更要必须被管理。
3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险。需求变更管理的目标:
1、相关的干系人必须清楚地了解发生的变更。
2、变更处于有效的管理中。
3、尽量降低变更带来的风险。
通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现上述的目标。需求变更流程:
1、确定需求的基准线。将以User Case作为需求基准线,在User Case确认之后的任何需求改变,都需要走需求变更流程,这一环节我们基本没有,期间有时候使的工
作很混乱,也就是因为没有一个规范的变更流程而造成的;如果建立了这么一个流程规范和机制,需求变更没有走这个流程的将不被认可。
2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。
3、项目管理者评估该需求变更。针对接收到的需求变更的要求,召集相关人员讨论该需求变更的合理性、可行性,实施的代价以及对项目的影响。包括可能影响的项目范围,进
度,费用,质量等计划。项目管理者作为项目的负责人,对项目的成功与否负有主要的责任。所以需求变更的决策者应该由项目管理者承担。
4、需求变更确认后由专人将需求变更记录下来,通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括(客户方,需求分析人员,测试人员,相关开发人员。需求变更记录格式如下: 序号变更提出时间变更描述变更类型(是 对原有需求 的修改还是 新增需求 原因变更提出 者
开发人员对进度的 影响(工 作量
1 2
5、确定变更的负责人。承担需求变更的具体工作,比如基线控制,对需求变更的记录,并通知相关人员。
6、相关人员接收到确认的需求变更后,做以下事情。需求分析人员修改需求说明书和User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。
7、按照变更后的计划实施项目,并进行检查,跟踪,对变更后的实施反馈和可能出现的问题及时沟通和处理。
8、需求冻结。项目越到后期,需求变更对项目的影响就越大,所以在一定时候要进入需求冻结阶段,不再接收新需求或需求的变更。
4、风险管理
风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程,贯穿于整个项目过程中,风险管理包括风险识别、风险评估、风险解决以及风险管理策略。
在项目的实施过程中需要不断地识别和应对风险,并加以有效的控制,风险管理的好与坏直接影响项目的实施效果,从某种意义上讲,项目实施对于项目管理者就是识别、分析、应对、控制风险的过程,使项目的约束性目标和质量目标朝有利的方向发展。
项目不同于日常任务,它有明确的起止时间和目标,要在明确的范围、时间和成本约束下,达到相应的质量标准,并取得用户的满意。影响项目成败的因素涉及方方面面,并且风险伴随着项目的始终,是客观存在的,作为一个项目管理者,应该具备良好的风险控制意识,善于识别风险并分析风险的影响,从中发现影响目标的风险点,并施
加影响或采取应对措施,把风险的负面影响降到最低,并且风险控制应该贯穿项目始终。
风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面,导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。下面将详细描述一下这些问题以及出现这些问题时的应对方案:
1、目标以及需求不明确
为了市场竞争或内部管理决策的需要,业务部门提出的需求往往要求的时间比较紧迫,需求的提出大多停留在几张纸或口头的传达上,没有形成正式的业务需求文档,在没有明确的需求范围的情况下,有时为了迎合业务部门的口味匆匆开工,过程中用户不断地提出新的想法,技术人员开始疲于奔命和应付,很难保证项目的进度和质量,也难以取得业务部门的认可。所以,在项目的前期一定要采取相应的手段或措施,与业务部门共同明确项目目标、需求范围,充分考虑现有的时间和资源约束,将需求排定优先级, 对于关键的需求优先实现， 其他辅助性的根据过程中的具体情况进行滚动式计划， 并取 得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统 原型等手段让用户在前期充分暴露自己的想法和需求。
2、范围蔓延以及需求变更 在有了明确的目标和需求范围的情况下， 需求的变更还是不可避免的， 业务部门在 看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控 制， 新的需求的加入通常会影响已实现的需求， 并且对项目进度和成本产生很大的影响。 项目管理者针对这种情况一定要采取严格的变更控制流程， 不能碍于面子， 否则最终的 结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相 关团队成员进行分析及评估， 作为是否实施的依据， 变更控制负责人根据分析结果判断 是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际 情况下可以采取一些软措施缓解矛盾。 需求变更风险：需求已经打上了基线，但此后仍然有变更
发生，对项目造成影响。 如何减少此类风险的发生？ 前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。 找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户，所有的需求要经 过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确 认、User Case 确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变 更时， 严格按照需求变更流程执行。 在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。
3、代码质量或返工风险 质量风险主要指开发代码的质量。 如何提高开发人员开发的质量？在制定项目计划 时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有 时开发人员为了赶进度在比较紧张的时间需要完成指定的任务， 可能就存在很大的开发 质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这 个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的 主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，code review 时严格考核。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对 指导开发非常重要。 返工是项目组最不愿意看到的，既浪费人力、物力和财力，又影响团队积极性。需 求不明确或范围没有有效控制都可能造成返工， 另外造成返工的原因是质量没有达到用 户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是 100%完成， 但一到最后系统交互测试或集成的时候就会发现一大堆问题， 不得不花费很大精力回头 排查、修改程序，造成这种情况的主要原因是过程中质量保证没有做到位，把大部分问 题留在了后面。 这就需要在项目实施过程中采取有效的措施来规避返工的风险， 通常的 做法有同行评审， 比如概要设计完成之后， 邀请其他项目组的技术专家进行技术评审以 发现架构设计问题； 管理评审， 通过组织级的质量审计看产品以及实施过程是否满足质 量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要 求的代码，走查通常能够发现 50%-70%的错误；每日构建，这是一种非常有效的方法， 可以避免把各部分的集成问题拖到最后， 并且能够及时发现相应的错误， 日构建一般在 项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。
4、人员技能和资源的不足 项目实施过程中由于人员技能欠缺造成的进
度延后和软件质量问题并不少见， 一个 熟练的技术人员完成同样一个任务需要 3 天，但一个生手可能就需要 7-10 天。项目管
理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求， 针对不同的 角色，及时采取相应的技能培训，以保证项目的顺利实施。如果对于项目中某些部分专 业性特别强或新技术，短期内又不能快速建立技能的情况，可以考虑将该块任务外包， 借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分 析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何减少 此类风险的发生？在项目开始前的技术评估阶段， 明确技术难点， 提前安排人员进行攻 克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找 可替代方案。 这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风 险在后期或中期出现。 项目所需人力资源无法按时到位， 导致资源风险。 如何减少此类风险的发生？这个 就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。
5、缺乏良好的团队协作 软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各 模块最终要集成在一起形成一个有机的整体， 这就需要各小组之间的密切配合， 界定清 楚工作界面及接口关系， 并在实施过程中持续地沟通交流和共享， 首先团队要融为一体， 产出的软件才能融为一体。 这是一个团队的软实力， 团队之间的协作好坏也将是个潜在 的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。 项目风险管理的要点：
1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生 的风险不属于风险管理的范畴。这也将是考验一个项目管理者的经验和知识对能否 管理好风险至关重要的内容。
2、对不可预期的风险，项目管理者要有潜在的风险意识评估，做好一些可操作性的预 案准备。
3、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的 必要条件。
4、风险报告是项目团队以及领导了解项目风险的一个有效手段。风险报告的格式： 序号 风险简介 对项目的影响 解决方案或对策
5、团队管理 团队就是一组个体为实现共同的目标而相互依赖、一起工作的共同体。 团队工作顾名思 义就是团队成员为实现这个共同的目标而付出的共同努力， 项目团队的工作是否有效直接关 系到
项目的成败。 团队管理是个渐进的过程。世界上只有完美的团队，没有完美的个人。好的高效的团队 不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化，这需要大家共 同的努力。
1、营造良好的工作环境和氛围。
2、建设优秀或鲜明的团队文化。
3、保持高效的沟通。
6、项目会议 组织会议是项目管理者日常工作中一项非常重要的工作任务， 项目过程中很多重要的决 定都是在会议中做出的，也有很多由于不成功的会议而对项目本身造成了不好的影响。 首先看看不成功的会议常常表现为哪些形式：
1、会议氛围不好，参与者发言不踊跃；
2、会议讨论常常偏离主题；
3、会议没有取得预期的结果；
4、会议时间常常一拖再拖。这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的， 很多人都对这样的会议都有抵触情绪， 对此也是深恶痛绝。 以下是组织会议时应该注意的问 题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：
1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有 可能取得成功，这是会议成功的充分条件。
2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要 希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只 是一个发表想法的人，他不用对会议的成功承担责任。
3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。组织会议的十一条最佳实践：
1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。
2、提前发出会议议程，以便会议参与者知道他们来做什么。
3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确 保必要人物都在的情况下一次会议参与者越少效果越好。
4、提前预约参与者的时间，以确保他们能按时到场。
5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在 开场时说： A、再一次强调会议的目标，我们来做什么。 B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会， 主要是讨论做还是不做以及告知大家我们要做什么， 而不要把太多的精力放在讨论 如何做上面。 C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人 的讲 话，等别人说完你再说等等。
6、会议过程中时刻注意引导和控制会议，以确保会议按照目
标进行。一次会议的氛围 是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。
7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成 果之一。
8、会议要有结论。我们常在会议上听到有人说：\"大家讨论了这么半天，结论呢？\"。 没有结论的会议是没有意义的。
9、会议后别忘发会议纪要，以及一些 Action，什么人什么时候做什么。
10、会议后的 action 执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知 了会议的效果。 否则会让大家感觉到这是一个可无可无的会议， 大家以后参与的积极性 也会降低。很多会议往往都不注意这一点。
11、按时结束的会议会受到所有人的欢迎。
7、版本控制 版本控制也是项目管理者的一个重要工作内容之一， 一个项目或产品的完成不可能是一 步到位的，在项目完成的后期可能会有多个不同的版本的发布（开发版本，测试版本，发布 版本等） 。需要做好版本的管理和控制。
8、项目总结 在项目完成后，总结整个完成项目的过程和经历，为下一次的项目启动提供参考经验， 完善不足，避免在类似的项目中出现可能存在的相同的错误发生。
推荐第2篇：软件开发项目总结报告
2005年软件开发项目总结报告
2005年，公司规模迅速扩大，公司管理的自动化程度不断提高，许多软件系统已不能满足不断扩大的管理要求，除了要升级原有的软件系统外，新的系统开发需求成倍增加，因而，本年度内扩充了软件应用及开发工程师扩大到30人。 2004年与2005年间，随着面向目标软件平台的普及，新的高效的软件开发模式也在中国软件业不断成熟，整体开发整体水平有了很大的提高，我公司也引进一些新的开发工具，实践了迭代开发等先进的管理方法。
05年内我们主要完成了供应协同平台，固定资产管理，合理化建议，商用空调信息管理系统，基础文档管理系统 等新的项目。由于开发管理的改进，本年度，软件开发效率提高较大，虽然用户需求增加很快，我们软件设计功能满足率仍然达到了95%,由于引进了专业的软件代码单元测试方法，软件测试的代码覆盖率增加到75%，软件的BUG率大幅下降，质量大幅提高，项目完成率提高到85%。 虽然本年度软件开发从质量，效率上都有较大提高，但通过分析，仍然发现了一些不足之处，需要采取相应的改进措施：
一、由于人员效率的提高，对用户需求的响应时间缩短到4天，比去年提高了50%，但评估完成时间只提高了10%根据分析，评估响应时间较长的原因主要是：
(1)、使用的开发方法有所改变，对开发时间的评估不是太熟练；
(2)、开发人员的专业知识有所增强，但对由于开发任务较重，对有些专业领
域的熟悉还不够。
二、关键用户访谈率及关键用户对需求的认同率都有所提高，都达到了90%
以上，但仍然有所不足，主要原因如下：
(1)、在忙季，仍然有的关键用户抽不出时间来接受访谈；
(2)、由于有些需求分析人员经验不足，对部分需求的分析不够透彻、准确；
三、每个功能模块平均的BUG数仍然有2个，单元测试覆盖率只达到75%，
分析原因如下：
(1)、开发工具的限制，目前的开发工具，对界面部分进行单元测试仍然不能
自动进行，而用户界面开发占系统功能的很大一部分；
(2)、软件开发人员的原因：由于软件人员紧张，项目任务多，交期短，所以
在开发时，所以，虽然在技术上，将界面程序进一步分拆开来进行更多覆盖率的测试可以提高测试率，但实际上，由于时间原因，大部分工程师都没有这样做，开发出的软件代码缺乏时间整理，并尽量通用化，也是软件质量没有进一步提高的原因；
四、项目的按时完成率仍然不够高，平均只有85%，分析原因如下：
(1)、用户需求变更太频繁：由于用户需求变更太随意，太频繁，仍然是按时
完成率提高的主要障碍。
(2)、软件需求分析设计人员的原因：由于设计的不合理，分析用户需求不够
透彻和全面，架构设计不合理，导致软件开发变更及错误多，也导致了软件项目的开发延迟；
综上所述，为了顺利实现计算机中心06年目标，我们计划改进措施如下：
内部的改进措施：
1、加大对新人培养力度，不但培养新进开发人员的技术能力，同时注意提高他们对业务的熟悉程度；
2、贯彻岗位知识能力模型，要求严格达标；做到合适的人在合适的位置做合适的事；
3、加强软件开发管理，培养团队合作精神，加强软件过程控制；
4、优化设计开发方法：加强设计标准化、模块化；提高软件开发效率；
外部的改进措施提议如下：
1、提高业务部门对软件开发过程的了解；
2、培养用户需求的分析能力；
3、加强与用户的沟通，让用户参与到设计中来；
推荐第3篇：软件开发项目建议书
报告说明《软件开发项目建议书》是中经先略针对软件开发项目编制的项目论证建议书是拟上项目单位向政府项目管理部门申报的项目申请。也是企业和投资者挑选项目的依据。软件开发建议书的审批过程实际就是国家根据有关投资政策、产业政策对软件开发项目进行比较筛选综合评定项目的必要性。软件开发项目是中经先略根据国民经济的发展、国家和地方中长期规划、产业政策、生产力布局、国内外市场、所在地的内外部条件提出的软件开发项目的建议文件是对拟建软件开发项目提出的框架性的总体设想。《软件开发项目建议书》主要包括软件开发项目总论、软件开发项目建设的必要性和条件、软件开发项目建设规模与产品方案、软件开发项目技术方案、软件开发项目设备方案和工程方案、软件开发项目投资估算及资金筹措、软件开发项目效益分析、结论等。报告目录第一章总论
一、项目名称
二、承办单位概况新建项目指筹建单位情况技术改造项目指原企业情况
三、拟建地点
四、建设内容与规模
五、建设年限
六、概算投资
七、效益分析第二章软件开发项目建设的必要性和条件
一、建设的必要性分析
二、建设条件分析包括场址建设条件地质、气候、交通、公用设施、征地拆迁工作、施工等、其它条件分析政策、资源、法律法规等
三、资源条件评价第三章软件开发项目建设规模与产品方案
一、建设规模达产达标后的规模
二、产品方案拟开发产品方案第四章软件开发项目技术方案、设备方案和工程方案
一、技术方案
1、生产方法包括原料路线
2、工艺流程
二、主要设备方案
1、主要设备选型列出清单表
2、主要设备来源
三、工程方案
1、建、构筑物的建筑特征、结构及面积方案附平面图、规划图
2、建筑安装工程量及“三材”用量估算
3、主要建、构筑物工程一览表第五章软件开发项目投资估算及资金筹措
一、投资估算
1、建设投资估算先总述总投资后分述建筑工程费、设备购置安装费等
2、流动资金估算
3、投资估算表总资金估算表、单项工程投资估算表
二、资金筹措
1、自筹资金
2、其它来源第六章软件开发项目效益分析
一、经济效益
1、销售收入估算编制销售收入
估算表
2、成本费用估算编制总成本费用表和分项成本估算表
3、利润与税收分析
4、投资回收期
5、投资利润率
二、社会效益第七章结论
推荐第4篇：软件开发项目管理
管理目标
1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。
2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。
3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。
执行概述
1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。
2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。
3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。
4、解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨部门协调等几个方面。
5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。
6、风险识别、风险控制以及风险的预案。
项目管理
1、需求阶段
对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。
组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。
2、设计阶段
根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。
设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。
该阶段交付成果需要进行评审。
3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。
项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。
测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。
4、发布阶段
包括制定项目发布计划，用户培训，发布上线。
5、试运行阶段
数据监控(日志、服务器状态)，根据监控出现的问题，及时进行处理，改进性能问题，特定情况执行补丁升级。
6、收尾阶段
产品交付，项目总结会。
常见问题
1、开发时间的估算
制定项目计划时，需要估算每个任务所需的时间，其中主要是开发任务中模块的分配和时间估算，在公司现有的技术框架下，开发人员主要的工作是投入在具体的业务逻辑实现上。通常单个模块开发时间取决于以下因素：
1、负责模块的业务逻辑的复杂程度。
2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度)。
3、模块技术实现上是否存在难点，所谓的技术难点定义是：在现有系统中还未实现的、开发人员自身未没接触过的技术。对于这样的难点，开发者没有相关的代码可以参考，自己也没有经验，所以需要投入学习时间用于研究解决。
模块分配和开发时间估算的步骤：
1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。
2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下：
A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。
B、技术难度较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。
3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。在此过程中应
4、对开发人员估算的时间进行确认。在确认过程中作为，项目管理者将预估时间和开与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。 发人员估算时间进行比较。那些差异较大的，与人员探讨其中的缘由。对于时间周期比较长的任务，将任务拆分为更小的子任务，每个任务的完成时间为8-24工时，消除时间周期较长的任务，避免不确定性影响项目的进度。
2、CodeReview CodeReview是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工；关于CodeReview执行，首先应有编码规范和代码审查规范。通过这两个文档来规范开发人员的代码实现，代码编写者必须要严格按照规范来进行；代码审核者根据这些标准来CodeReview代码，同时在CodeReview过程中需要不断完善该文档。
CodeReview一般可按以下步骤实施：
1、检查开发者的代码实现是否遵循了编码规范。
2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。
3、代码编写者和代码审核者坐在一起，由代码编写者按照UseCase依次讲解自己负责的代码和相关逻辑，代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug，对这些bug记录在案。
4、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要检查Bug。同时全面兼顾，确保代码整体上结构优良；审核完毕后，代码审核者编写“代码审核报告”记录发现的问题及修改建议，提交给相关人员。
5、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。
6、代码编写者bugfixed完毕之后给出反馈。
7、代码审核者把CodeReview中发现的有价值的问题更新到\"代码审核规范\"的文档中，对于特别值得提醒的问题可群发email给所有技术人员。
3、需求变更管理
需求变更管理也是项目管理中最重要的一个环节，对需求变更管理的有效性将直接影响对待需求变更的正确态度：
1、需求变更是不可避免的。
2、需求变更要必须被管理。
3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。 需求变更管理的目标：
1、相关的干系人必须清楚地了解发生的变更。
2、变更处于有效的管理中。
3、尽量降低变更带来的风险。
通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。需求变更流程：
1、确定需求的基准线。将以UserCase作为需求基准线，在UserCase确认之后的任项目的成功与否。 何需求改变，都需要走需求变更流程。
2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。
3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。项目管理者对项目的成功与否负有主要的责任。需求变更的决策应由项目管理者做出。
4、需求变更确认后，由专人将生成需求变更单记录下来，通知给项目中所有关系人。
5、确定变更的负责人。承担需求变更的具体工作，比如基线控制，对需求变更的记录，并通知相关人员。
6、相关人员接收到确认的需求变更后，需求分析人员修改需求说明书和UserCase的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。
7、按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现的问题及时沟通和处理。
8、需求冻结。项目越到后期，需求变更对项目的影响就越大，所以在一定时候要进入需求冻结阶段，不再接收新需求或需求的变更。
4、风险管理
影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，常见风险如下：
1、目标以及需求不明确
为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有正式的业务需求文档，在没有明确的需求范围的情况下，有时为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。
在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。
2、项目目标扩大以及需求变更
在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。
前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户)，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。
3、代码质量风险
质量风险主要指开发代码的质量。在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响很大。开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重要。
往往有这样一种情况，每个团队成员按照项目计划报告进度都是100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题。这需要在项目实施过程中采取有效的措施来规避风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题；管理评审，通过组织级的质量审计看产品以及实施过程是否满足质量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要求的代码，走查通常能够发现50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。
4、人员技能和资源的不足
项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见，一个熟练的技术人员完成同样一个任务需要3天，但一个新手可能就需要7-10天。项目管理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训，以保证项目的顺利实施。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。
5、缺乏良好的团队协作
软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。
6、项目会议
组织会议是项目执行过程中一项非常重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，不成功的会议会对项目本身造成了不好的影响。
不成功的会议通常表现为如下形式：
1、会议氛围不好，参与者发言不踊跃；
2、会议讨论常常偏离主题；
3、会议没有取得预期的结果；
4、会议时间常常一拖再拖。
这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：
1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能取得成功，这是会议成功的充分条件。
2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只是一个发表想法的人，他不用对会议的成功承担责任。
3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。组织会议的十一条最佳实践：
1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。
2、提前发出会议议程，以便会议参与者知道他们来做什么。
3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确保必要人物都在的情况下一次会议参与者越少效果越好。
4、提前预约参与者的时间，以确保他们能按时到场。
5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说： A、再一次强调会议的目标，我们来做什么。
B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。
C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人的讲话，等别人说完你再说等等。
6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。
7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。
8、会议要有结论。我们常在会议上听到有人说：\"大家讨论了这么半天，结论呢？\"。没有结论的会议是没有意义的。
9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。
10、会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这一点。
11、按时结束的会议会受到所有人的欢迎。
推荐第5篇：软件开发项目总结报告
项目总结报告
项目题目：
课程阶段:
学生姓名指导教师 班级编号
提交日期
北京翰子昂郑州实训中心项目总结报告
目录
第一章 项目基本情况 ..........
1.1
1.1.1
1.1.2
1.2
1.2.1
1.2.2
1.2.3 项目概况 ...............项目简介 ...............指导老师 ...............项目过程的基本回顾 ............项目时间 ...............主要项目内容 ...........主要项目过程 ...........
第二章 项目任务与完成情况 ............
2.1
2.2
2.3
2.4 本人承担的主要工作 ............完成项目任务的技术方案与步骤 .........项目中的问题及解决方法 ...............项目任务的完成情况 ............
第三章 项目总结..............
3.1
3.1.1
3.1.2
3.2 项目的心得 .............项目的收获 .............项目的体会 .............问题与探讨 .............参考文献 .............致谢 ................
推荐第6篇：软件开发项目合同
软件开发合同书
甲方：
乙方： 深圳市凯路网络技术有限公司
鉴于甲方委托乙方软件开发，帮助甲方树立企业形象，扩大宣传，拓宽销售渠道，为明确双方责任，根据中国相关法律经双方协商，签订此合同，以期双方共同遵守。
甲方在此委托乙方进行_软件的开发，为明确双方责任，经友好协商，双方达成以下协议：
第一条：项目的内容、价款、开发进度、交付方式由“合同附录”载明。
第二条：甲方的权利和义务
１、提供专人与乙方联络。
２、提供所有需要开发需求的资料给乙方。
３、按照“合同附录”的要求，及时支付费用。
４、甲方将在著作版权法的范围内使用本合同标的及相关作品、程序、文件源码，不得将其复
制、传播、出售或许可给其它第三方。
５、甲方对合同中的系统软件、页面设计，程序开发享有排它的使用权。
第三条：乙方的权利和义务
１、提供专人与甲方联络。
２、按照“合同附录”的要求，使用甲方资料，进行软件的开发。
３、在“合同附录”要求的期限内，完成软件的开发，并通知甲方进行验收。
４、在验收期内甲方要求下，对不合格地方进行修改。
５、本合同标的及相关作品、程序、文件源码的版权属于乙方。(版权归属应该为嘉源公司)
第四条：验收
１、验收标准有以下几条：
（a）、甲方可以通过任何上网的计算机访问这个软件
（b）、软件系统中不存在任何错误或系统运行错误，图片链接错误（以甲方提供的开发需求为准）。（功能符合开发需求，开发需求需要清晰界定功能）
（c）、网络程序运行正常。
２、验收期为一周。
第五条：违约责任
1、任何一方有证据表明对方已经、正在或将要违约，可以中止履行本合同，但应及时通知对方。若对方继续不履行、履行不当或者违反本合同，该方可以解除本合同并要求对方赔偿损失。
2、因不可抗力而无法承担责任的一方，应在不可抗力发生的3天内，及时通知另一方。
3、一方因不可抗力确实无法承担责任，而造成损失的，不付赔偿责任。本合同所称不可抗力是指不能预见、不能克服并不能避免且对一方当事人造成重大影响的客观事件，包括但不限于自然灾害如洪水、地震、火灾和风暴等以及社会事件如战争、*、政府行为等。
第六条：保密条款
双方应严格保守在合作过程中所了解的对方的商业及技术机密，否则应对因此造成的损失进行赔偿。
第七条：其它
1、如果本合同任何条款根据现行法律被确定为无效或无法实施，本合同的其它所有条款将继续
有效。此种情况下，双方将以有效的约定替换该约定，且该有效约定应尽可能接近原约定和本合同相应的精神和宗旨。
2、“合同附录”规定的有效期满，本合同自动失效。届时双方若愿意继续合作，应重新订立合同。
3、本合同经双方授权代表签字并盖章，自签订日起生效。
4、本合同一式两份，双方当事人各执一份，具有同等法律效力。
第八条：以上条款如有未尽事宜，经甲、乙双方协商后加以补充。
5、付款方式：项目总费用为八千元(人民币),在签定合同当日内预付总项目费用的百分之三十，在软件完成后交付总项目费用的百分之四十，测试用两个月没问题后再付剩下的总项目费用的百分之三十。
甲方：乙方：
甲方代表：乙方代表：
电话：电话：
电子信箱：电子信箱：
日期：日期：
合同附录
>
关于购买OA系统信息:
1在线邮局（增加部门群和全公司两个功能）
新邮件发邮件发件箱收邮件废邮件
2个人文件夹
私人文件夹公共文件夹管理员管理
3办公用品管理
办公用品种类领取办公用品审核领用表发放办公用品资料管理
4人事管理
企业员工资料企业员工统计 企业部门员工 员工调职管理员工培训管理员工考勤管理 5权限设置
部门管理权限职位权限管理用户帐号设置用户权限设置系统维护设置 6系统帮助
系统帮助信息管理帮助类别输入帮助信息
7常用资料
公共信息查询常用公共网址手机与IP地址查用邮编查询万年日历查询世界时间查询常用信息查询常用网址查询酒店饭店查询常用邮编查询列车资料查询航班资料查询单位换算查询媒体资料查询
8个人办公(能否增加部门工作计划)
个人工作计划部门工作计划员工工作任务
9通讯助理
个人通讯录内部通讯录外部通讯录手机短消息
10通知管理
通知管理发送通知已发通知已收通知我的通知（做到按部门发送） 11通告管理(发布通告)
发布通告管理通告浏览通告
12考勤管理+值班管理(能否放在一起,算一个模块)
设置考勤时间开始考勤今日考勤统计日考勤统计月考勤统计值班管理值班记录
推荐第7篇：软件开发项目工作计划要求
Project 2002使用要求
软件开发项目工作计划要求
1.所有新建软件开发项目必须使用Project 2002进行项目管理， 2.编写要求如下：
1.1 在甘特图视图中编写项目计划，其中任务内容、工期、开始时间、完成时间和资源名称为必填内容；计划安排的内容要便于跟踪，工期不能太长。
1.2 使用【链接】功能，关联任务之间的先后关系。
1.3 计划输入完毕，使用菜单【工具】->【跟踪】->【保存比较基准】保存计划的比较基准。
1.4 将计划发布到Project Server服务器上，具体发布方法见附件。 3.计划更新周期
各项目必须至少每半个月更新一次计划的进度，并发布到Project Server服务器上。 4.项目计划负责人
每个项目必须指定专人进行项目计划的管理，并上报到信息中心。工作内容有计划变更、计划跟踪和计划发布等。
Project 2002使用要求
附件：Project Server 2002 项目发布方法
2.设置Project Server 的协作信息。
1.在Project 2002中建立项目计划，设定任务名称、工时、工期和资源。
2.1 在【协作】->【选项】->【常规】选项中输入项目经理的名字。
2.2 在菜单【协作】->【协作】选项中：
在【MS Project Server】中输入：http://172.16.1.252/projectserver 在【MS Project Server 标识】中选择 Project Server用户名。 单击按钮【测试连接】，如果成功则弹出对话框：
否则就说明URL地址输入错误，请确认。
Project 2002使用要求
3.任务发布：
3.1．如果是
Project 2002使用要求
在【站点】中输入http://172.16.1.252
3.2．如果删除了某个资源的工作分配，则选择【协作】->【发布】->【新建或者更改的工作分配】。
3.3.如果更新了计划进度，则选择发布【协作】->【发布】->【项目计划】。 3.4．如果修改了任务内容，则选择【协作】->【发布】->【重新发布工作分配】。
注意：Project文件的存放目录一旦发布之后就不要再修改了，否则Project Server在更新的时候找不到文件的存放位置，无法更新。 4.项目经理的使用：
通过IE，登录到Web页面，输入自己的名字，初始是空密码，登陆成功后可以修改密码。
如果是
推荐第8篇：软件开发项目保密协议
保密协议
甲方：
乙方：
鉴于：
甲乙双方在履行《xxx》项目开发过程中，甲方将向乙方披露其保密信息（包括甲方内部数据），以及双方在合作过程中乙方已经或者将要知悉甲方的保密信息，为明确甲乙双方的保密义务，保护甲方的商业秘密不受侵犯，经协商一致，达成如下协议：
第一条保密信息的范围
1、保密信息是指由甲方通过文字、电子或数字方式或媒介向乙方提供的，在提供时明确标记有“保密”的，以及虽未标记为“保密”但属于甲方的生产经营数据、报表、图幅、报告及技术信息。口头传达并在传达同时认定为属于保密的信息应当视为保密信息。甲方相关的业务和技术方面有保密要求的资料信息。
保密信息还包括本项目研发中形成的双方共有技术、产权、软件成果、研究思路。保密信息包括但不限于：
（1）数据库所有的数据；
（2）客户或潜在客户的身份及其他相关信息、客户联系方式和客户销售策略等；
（3）市场研究结果，市场渗透资料，及其他市场信息；
（4）销售和市场计划、规划及策略；
（5）销售额、成本和其他财务数据；
（6）经营秘密、技术秘密、设计及专有的经营和技术信息，与本协议所涉及产品及其程序设计、源码等有关的方法、经验、程序、步骤；
（7）产品、零件及服务的供应源；
（8）任何其他秘密工艺、配方或方法；
（9）本项目研发形成的双方共有技术、产权、软件成果、研究思路在成果申报之前。
2、保密信息不包括以下信息：
（1）甲方已经公布于众的资料，但不包括甲乙双方或其代表违反本协议规定未经授权所披露的；
（2）乙方已经独立开发的及未曾违反任何法律、法规或甲方的任何权利的信息，并且该等信息是在乙方依照本协议条款从甲方获悉该等信息之前独立开发的；
（3）乙方在依照本协议条款从甲方获悉之前已经占有的信息，并且就乙方所知乙方并不需要对该等信息承担任何具有约束力的保密义务；
（4）在双方签订本协议以后并非由于乙方的过错而被公众所知的信息；
（5）乙方在未违反其对甲方承担的任何义务的情况下从第三方获得的信息。
第二条保密信息的使用
1、乙方应使所有保密信息得到最严格的保密，并且除为促进软件新产品发展，或本协议允许的用途外，不得使用该等保密信息。
在履行上述义务时，乙方均应采取不低于与保护其自身保密信息所用措施同样严格的措施，并责成其每一位有可能得到保密信息的董事、管理人员、雇员或代理人分别就本协议涉及的保密内容签订一份与本协议所列条款同样严格的保密协议。
2、除非事先取得甲方的书面同意，否则乙方不得复制、出版或向第三方披露任何保密信息。
3、如果具有司法管辖权的法庭或政府主管部门要求乙方披露保密信息，乙方应事先通知甲方，使甲方能够查验需要披露的保密信息。
4、本协议在终止后的2年内仍完全有效。期满后乙方如需对外披露保密信息，事先必须经过甲方书面同意。
第三条保密信息的所有权
本协议的任何规定均不得被视为向乙方授予任何保密信息的任何专有权、转让权或所有权。项目研发形成的软件产品、知识产权等属双方共有。
第四条文件退还
如果双方同意终止《xxx》项目合作，乙方应在双方同意终止后的10日内，向甲方退还全部保密信息及其全部副本（不论其是否是在计算机磁盘、光盘读取器、光盘、硬盘或软件中或在纸张载体上存储、保存或记录的）；如果乙方退还上述保密信息及其全部副本为不可行，则该乙方应将其销毁，或者从计算机或其他电子系统中将其删除或抹掉。
第五条违约责任
乙方如果违反其在本协议项下的义务，应赔偿甲方因上述违约而导致的全部实际损失，包括但不限于法律费用。
第六条其他约定
1、乙方在本协议项下的义务对其法定继承人和许可受让人均有约束力。
2、本协议受中华人民共和国法律管辖并按中华人民共和国法律解释。对因本协议或本协议各方的权利和义务而发生的或与之有关的任何事项和争议、诉讼或程序，本协议双方不可撤销地接受中华人民共和国法院的管辖。
3、除非双方采用书面形式，否则对本协议的任何修改均属无效。
4、本协议有效期为2014.x.xx—2015.x.xx。
5、本协议一式四份，双方各持二份，每份皆具有同等法律效力。
6、本协议在双方签字盖章之日起生效。
甲方：（盖章）
负责人：（签名）
年月日
乙方：（盖章）
法定代表人／委托代理人：（签名）
年月日
推荐第9篇：浅谈软件开发项目管理
浅谈软件开发项目管理
摘要：在软件项目开发的过程中，软件项目管理的成功与否是决定一个项目是否能够顺利高效率完成的重要保证。但是我国大部分的软件企业在进行项目管理时都存在着各种问题，从而使项目不能顺利有效地完成。文章探讨了在项目管理过程里出现的常见问题，并给出了相应的解决策略。
关键词：软件项目管理；项目经理；项目计划
软件行业在现在的众多行业里是一个极具挑战性和创造性的行业，体现了软件开发者的智慧和汗水，同时软件开发是一项复杂的系统工程。牵涉到许多方面的因素，在实际工作中，经常会出现各种各样的问题，甚至会面临失败。如何总结、分析失败的原因。得出有益的教训，对于项目开发人员来说，是在今后的项目中取得成功的关键。
一、软件开发中实行项目管理的意义
项目管理就是在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求，实际上就是通过项目各方干系人的合作，把各种资源应用于项目，以实现项目的目标，满足项目干系人的需求，其本质就是对时间、质量和成本的管理。随着软件开发的深入、各种技术的不断创新以及软件产业的形成，人们越来越意识到软件过程管理的重要性，管理学的思想逐渐融入软件开发过程中，项目开发的管理日益受到重视。
二、目前在软件项目管理中存在的误区
现在大多数企业都认识到了在项目中进行管理的重要性，但是仍然有许多企业在实施项目管理的过程中存在着这样那样的误区，主要表现在：
1 项目经理不够专业。在软件企业中，缺乏专业的项目管理人员来实施项目管理及担任项目经理，通常被任命的项目经理主要是因为他们能够在技术上独当一面，但是他们在管理方面特别是项目管理方面的知识比较缺乏。
2 项目计划缺乏纲领性。项目经理对总体计划、阶段计划的作用认识不足，因此制定总体计划时比较随意，不少事情没有仔细考虑：阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。
3 缺乏有效的管理意识。部分项目经理不能从总体上把握整个项目，而是埋头于具体的技术工作，造成项目组成人员之间忙的忙、闲的闲，计划不周、任务不均、资源浪费。有些项目经理没有很好的管理方法，不好安排的工作只好自己做，使项目任务无法有效、合理地分配给相关成员，以达到“负载均衡”。
4 缺乏有效的沟通制度和机制。在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足，造成各做各事、重复劳动，甚至造成不必要的损失：有些人没有每天定时收邮件的习惯，以至于无法及时接收最新的信息。
5 风险管理意识淡泊。有些项目经理没有充分意识到风险管理的重要性，对计划书中风险管理的章节简单应付了事，随便列出几个风险，随便地写一些简单的对策，对于后面的风险防范起不到什么指导作用。
6 项目干系人的不确定性。在范围识别阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以至于无法得到完整需求或最终经权威用户代表确认的需求：或者是多个用户代表各说各话、昨是今非，但同时又要求项目尽早交付：项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。
7 缺乏项目团队的合理分工。项目团队内部有时由于各阶段不同角色或同阶段不同角色之间的责任分工不够清晰而造成工作互相推诿、责任互相推卸的现象；有时各阶段不同角色或同阶段不同角色之间的责任分工比较清晰，但是各项目成员只顾完成自己那部分任务，不愿意与他人协作。这些现象都将造成项目组内部资源的损耗，从而影响项目进展。
三、解决软件项目管理中存在的误区的有效策略
要想解决上面描述的误区，归根到底还是要从管理学的角度入手，即在软件项目的开发过程中加入过程管理的内容，这样我们可以在软件开发中对各个过程的质量加以控制，从而达到保证软件产品质量的目的。为了有效提高管理水平，我们应该努力做到：
1 项目经理接受系统的项目管理知识培训是非常必要的，有了专业领域的知识与实践，再加上项目管理知识与实践和一般管理的知识和经验的有机结合，必能大大提高项目经理的项目管理水平。
2 计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。提高项目经理的计划意识，采用项目计划制定相关知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估。
3 加强项目管理方面的培训，并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。技术骨干在担任项目经理之前，最好能经过系统的项目管理知识，特别是其中的人力资源管理、沟通管理的学习，并且在实际工作中不断提高自己的管理素质，丰富项目管理经验，提高项目管理意识。
4 制定有效的沟通制度和沟通机制，提高沟通意识：采取多种沟通方式，提高沟通的有效性。通过制度规定对由于未及时收取邮件而造成损失的责任归属；对于特别重要的内容要采用多种方式进行有效沟通以确保传达到位，例如：除发送邮件外还要电话提醒、回执等，重要的内容还要通过举行各种会议进行传达。
5 通过学习项目管理知识掌握风险识别、量化、对策研究、反应控制的工具和方法，掌握项目风险管理所必备的知识。通过加强对项目规划中风险管理计划的审核提高项目组的风险管理意识。总结本行业项目中常见的风险及其对策作为风险管理计划中必要的风险内容，并切实评估相应对策的有效性和可行性。
6 项目的目的就是实现项目干系人的需求和愿望。项目干系人管理应当从项目的启动开始，项目经理及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。
7 项目经理应当对项目成员的责任进行合理的分配并清楚地说明，同时应强调不同分工、不同环节的成员应当相互协作，共同完善。
实施有效的项目管理绝非易事，对于软件企业而言，这不是一个小的改变，而是一种变革，企业需要为此付出艰苦的努力，同时，成熟有效的项目管理无疑将对企业起着至关重要的作用，项目管理的水平将是企业核心竞争力之一。
推荐第10篇：2003年软件开发项目总结报告
2003年软件开发项目总结报告
随着市场经济的进一步完善及全球经济一体化进程加快，企业面临着激烈的市场竞争，企业内部、外部信息交流已成为企业发展、参与市场经济竞争的迫切需要。企业引入先进的信息处理技术，增加信息共享程度，不仅提高了工作效率、降低成本，而且也提高企业管理的科学性和自动化程度。信息已成为企业生存与发展的基础，在原有系统的基础上，计算机中心于2003年开始加大信息管理系统的开发，已到年底，开发项目也基本上完成了；
为了总结03年所有开发项目的整个开发及管理过程，我们选取2个比较大的软件项目来分析，项目为：出口技术支持网站管理系统、模具管理系统；在这两个具有代表性的项目中，我们清晰的看到了我们在项目开发过程中的成果及所存在的不足和应该改进的地方，总的说来，设计开发的功能基本上达到了用户需求的75%，用户也能够开始使用我们开发的系统来达到其管理目的。如出口技术网站为国外的客户提供了方便快捷的了解到我们公司的空调产品及技术信息、空调配件信息等等。模具管理系统最大程度的实现了模具信息的共享，各使用部门可以方便的查询模具的位置、进度、状态、申请单、试模、验收、合格、模具的调拨、报废等等信息；查询模具的相关信息信息由原来的1-2天缩短为10分钟之内。产品型号、零件图号统一维护，规范管理，出错比例大大下降。而且在更改零件图号的情况下，基础数据更改，其它相关文件的同一数据会随之更改，减少系统维护量提高了生产部编制模具生产任务单的工作效率，缩短了模具制造任务传递时间，查询新的开模单更方便快速，由原来的至少半天缩短为10分钟之内汇总改模单情况由原来的多人每日手工填写改进为阶段一次汇总，时间仅须20分种左右，大大提高了效率，模具台账能显示所有的模具汇总及分配情况；
虽然相关项目基本上达到了预期的目的，但是，反思在整个项目的需求提出、项目评估、需求分析、项目计划、总体设计、详细设计、测试计划、实施的各个环节，我们都有工作不足之处，特别是某些关键控制点上面，我们有一些失误，当然，原因是多方面的，有果必有其因。下面我们从关键控制点上面来分析我们在项目开发过程中存在的问题、原因分析及改进措施：
一、从用户提出需求，到需求响应时间，我们需要9天时间，而需求评估完成时间需要15天左右，这就是我们存在的一些问题，导致需求响应时间及评估完成时间比较长的原因有如下几方面：
(1)、由于计算机中心软件开发人员不够：各应用系统的支持人员及软件开发人员加起来才8个，公司各子应用系统有几十个，ERP的各个子系统及模块就有将近20个，一个员工要支持5到6个功能子系统的维护； (2)、分工不明确：软件开发人员往往身兼数职，跨多个职能领域，应用用户习惯找谁就认定那个人，什么事都找该员工；工作效率就相对低下；
二、关键用户访谈率及关键用户对需求的认同率都比较低，关键用户访谈率只有70%，而关键用户对需求的认同率只有68%；为什么会有这样的结果了，分析原因如下：
(1)、由于计算机中心人员紧张：有时没有办法访谈所有的关键用户，只能找几个评估时认为特关键的用户；
(2)、被访谈用户原因：由于被访谈用户事情太多，往往在提出需求以后，抽不出时间来接受访谈；另外有些用户只局限于本部门或者本岗位来考虑问题，不愿意从公司层面或者大局来考虑；
(3)、用户不重视：有些需求是由于用户部门领导要求，跟得比较紧，但是如果部门领导没有跟得紧的情况下，用户就不那么急了，就算立了项，也不能很好的配合；
(4)、软件需求分析人员原因：由于需求分析人员经验不足，导致需求不够明确，不能了解到用户需求背后的真正目的；
三、设计功能满足率比较低，只有75%，功能点BUG数比较多，每个功能模块平均的BUG数有15个之多，函数注释率只有10%左右，各功能点的测试覆盖率只有40%，分析原因如下：
(1)、用户需求不明确：有些用户在接受访谈时说的需求，及在需求确认时都没有问题，但是到软件功能设计出来以后，却完全不是这么回事，用户就会解释说当时没想清楚；
(2)、软件开发工具的原因：软件开发人员使用的开发工具不够实用，很多工发工具能检查出来的BUG，没有办法检查出来，需要开发人员自已检查； (3)、软件开发人员的原因：由于软件人员紧张，项目任务多，交期短，所以在开发时，没有多少时间去写程序代码的注释，况且有些开发人员也根本没有注释的习惯，没有多少时间去完整的测试各个功能点；把测试的任务有时就直接交给用户了；
四、系统架构变更次数过多，一个项目平均下来变更6次之多，原因如下： (1)、系统设计人员的原因：由于系统设计人员在架构设计时，没有考虑到系统架构的灵活性；不易于扩展；一旦用户的需求有变化，系统架构就必须重新修改；
(2)、用户需求变更太频繁：由于用户的需求很随意变更的，加大了系统设计的难度，导致了系统架构变更；
五、项目的按时完成率比较低，平均下来只有60%，分析原因如下： (1)、用户需求变更太频繁：由于用户需求变更太随意，太频繁，导致有些开发工作完成，又必须推倒重来，做了很多无用工作；另外有些用户只局限于本部门或者本岗位来考虑问题，不愿意从公司层面或者大局来考虑；造成重复工作，重复设计；
(2)、软件开发人员的原因：由于软件开发人员不够，项目多，任务紧，一个人身兼数职，也是造成软件开发项目推迟的直接原因；另外，软件开发人员专业技术水平不够，有些功能开发要花太多的时间去研究，寻找解决方案，也导致了项目的延迟；
(3)、系统架构变更太多：导致有些程序开发工作无用，必须重新开发； (4)、软件需求分析设计人员的原因：由于设计的不合理，分析用户需求不够透彻和全面，架构设计不合理，导致软件开发变更及错误多，也导致了软件项目的开发延迟；
(5)、软件开发工具及开发方法落后：由于软件开发人员没有太多的时间去研究使用新的，先进的开发工具，也没有太多时间去学习新的开发方法，导致软件的开发速度慢，开发出来的程序BUG多，程序没有多少可重用性，也导致了软件项目的开发延迟；
综上所述，为了配合公司的发展，满足公司对信息化建设的要求，顺利实现计算机中心04年目标，我们必须针对软件开发项目中存在的问题采购行之有效的改进方案，计划改进措施提议分为内部及外部：
内部的改进措施提议如下：
1、增加人员配置，解决人手严重不够的问题；
2、明确分开，重新划分业务小组；
3、明确岗位职责，细分软件项目开发所需要的各个岗位；
4、制定岗位知识能力模型，对每个岗位要求的能力必须定义清楚，要求严格达标；不达标的必须重新培训；做到合适的人在合适的位置做合适的事；
5、加强专业技能培训；
6、加强软件开发管理，培养团队合作精神，加强软件过程控制；
7、优化设计开发方法：加强设计标准化、模块化；提高软件开发效率；
8、加强业务培训，更实际的了解业务需求；
外部的改进措施提议如下：
1、加强业务部门对系统了解；
2、培养用户需求的分析能力；
3、加强与用户的互动及双向沟通，让用户参与到设计中来；
4、引导用户的软件需求，培养用户从公司层面或者大局来提出需求；
第11篇：软件开发项目个人承包协议
XXXX平台系统开发个人包干协议
甲方：广州xx生态科技有限公司
乙方： 身份证：
甲乙双方就“xxxxxx平台系统”开发项目签订个人包干协议，乙方为甲方在职员工，根据甲方公司项目管理及绩效考核方式，与乙方签订工作协议：
1、甲方评估项目开发时间及开发需求给乙方，乙方根据项目时间节点完成系统开发要求，甲方只考核乙方开发成果；
2、在项目开发阶段，甲方有权提出修改意见并评估乙方的进度时间；
3、个人项目包干期间，甲方不限制乙方办公地点及上班时间，需要与其他同事对接的工作内容必须提前沟通协调好；
4、乙方月薪为人民币：元，现“XXXX平台系统”包干项目所需时间2个月，即2018年7月日至2018年9月日完成系统开发及对接，总薪酬为人民币元，社保、公积金及其他公司福利正常享受，开发期间，甲方每月发放乙方人民币3500元，项目测试合格并交付后，发放余款元；
5、乙方必须进行代码注释及业务逻辑规范，并在项目完成后，移交代码至公司服务器统一管理，若不按要求进行工作规范，甲方有权追究乙方相关责任，及扣罚相应赔偿金。
第12篇：软件开发项目商业计划书
软件开发项目商业计划书
目前，中国软件产业的快速增长已成为拉动我国经济增长的关键点之一。工信部部长李毅中表示，IT行业为我国经济增长做出了十分重要的贡献，软件在 IT行业发展中举足轻重，成为推动经济增长和创造经济机会的催化剂。因此发展和扶持软件产业，是一个国家提高国家竞争力的重要途径，也是参与全球化竞争所必须占领的战略制高点。而《中国软件产业发展战略研究报告》也指出全球软件产业在发展过程中的网络化已成为第一发展趋势。
从2000年到2010年这十年间，中国软件产业发展较快，产业规模增速迅猛。2009年软件服务业销售收入同比增长20%，是所有行业里面唯一增长20%以上的产业。2007年软件收入5834.3亿。2007年的前五年，平均的增速接近40%，07年的速度与五年前相比增加了五倍多。企业数14373家，平均增速是25%，07年较02年增长了3倍。从业人员达到152.9万。到了2009年，我国软件产业完成软件业务收入9513亿元，同比增长25.6%，增速比上年低4.2个百分点，是2000年的16倍；软件出口196亿美元，是2000年的49倍。面对金融危机，虽然软件产业的增长速度有所放缓，但总体增长水平依然强劲。
第一部分 摘要
一、项目背景
二、项目简介
三、项目竞争优势
四、融资与财务说明
第二部分软件开发行业市场分析
一、软件开发行业发展现状
二、目标市场分析
三、竞争对手分析
四、小结
第三部分 公司介绍
一、公司基本情况
二、组织架构
三、管理团队介绍
第四部分 产品介绍
一、产品介绍
二、产品的新颖性/先进性/独特性
三、产品的竞争优势
第五部分 研究与开发
一、已有的技术成果及技术水平
二、研发能力
三、研发规划
第六部分 产品制造
一、生产方式
二、生产设备
三、成本控制
第七部分 市场营销
一、企业发展规划
二、营销战略
三、市场推广方式
第八部分 融资说明
一、资金需求及使用规划
（一）项目总投资
（二）固定资产投资（土地费用、土建工程、淀粉糖装饰、设备、预备费、工程建设其他费用、建设期利息）
（三）流动资金
二、资金筹集方式
三、投资者权利
四、资金退出方式
第九部分 财务分析与预测
一、基本财务数据假设
二、销售收入预测与成本费用估算
三、盈利能力分析
1、损益和利润分配表
2、现金流量表
3、计算相关财务指标（投资利润率、投资利税率、财务内部收益率、财务净现值、投资回收期）
四、敏感性分析
五、盈亏平衡分析
六、财务评价结论
第十部分 风险分析
一、风险因素
二、风险控制措施
第13篇：物业公司住宅小区物业项目管理系统软件开发实施方案
物业公司住宅小区物业项目管理系统
软件开发实施方案
1.前言
对物业公司而言，高质量的物业管理能提高物业市场竞争力，使开发企业的房产畅销，加速资金周转。同时，完善的物业管理能为开发商树立良好的企业形象，吸引更多的房地产交易商和消费者。在环境效益上，住宅区内的环境和布局、治安等与整个建设风貌融为一体，提高了房地产业的综合效益。
2.项目概述
本公司住宅小区物业业务增多，对物业管理软件的需求呈上升趋势，公司股东会议决定投入资金开发一套小区物业项目管理软件，提供有关住宅小区物业管理用信息网，并能够尽可能采用各种计算机和通信技术，为住户提供快速、准确和渠道多样的服务。因此，开发这样一套小区物业项目管理系统软件成为很有必要的事情，为了完成该软件，本文制定出相应的详细计划。
3.功能需求
3.1.功能介绍
典型的小区物业管理系统主要应具有以下管理功能：
a) 系统用户管理；管理使用该系统的用户信息，包括系统用户的添加、修改、
删除；
b) 楼盘信息管理：管理小区中楼盘的基本信息，包括楼盘信息的添加、修改、
删除、查询；
c) 住户信息管理：管理小区住户的各种信息，包括住户信息的添加、修改、
删除、查询；
d) 停车场管理：管理停车场的各种信息，包括停车场信息的添加、修改、删
除、查询；
e) 物业收费管理：管理小区内的各种收费项目，比如水费、电费、物业费等，
包括收费项目的添加、修改、删除、查询；
f) 住户报修管理：管理住户报修信息，包括住户报修信息的添加、修改、删
除、查询；
g) 住户投诉管理：管理住户投诉信息，包括住户投诉信息的添加、修改、删
除、查询。
3.2.开发过程
“小区物业管理系统”的开发过程是根据软件的生命周期的原理和方法进行的，包括以下几个阶段：
a) 确定课题，根据需要制定相应的项目计划，并完成项目计划书； b) 对软件进行可行性分析，并完成可行性分析报告；
c) 对小区进行调研并了解软件的需求分析，完成需求分析说明书； d) 软件的总体设计和详细设计，并完成相应文档； e) 根据要实现的功能，完成软件的编码； f) 对开发的软件进行测试； g) 确认和评审； h) 交付使用。
××物业公司小区物业项目管理系统WBS分解:
3.3.工作任务的分配及人员分工
软件开发过程中的工作任务的分配及人员的分工如下表所示：
3.4.开发和运行环境
小区物业管理系统开发和运行环境如下：
a) 开发环境：windows XP b) 开发工具：×××编程语言 c) 数据库管理系统：×××数据库平台 d) 运行环境：windows 98/XP/2000
3.5.项目进度
项目单代号网络图：
项目里程碑图：
计划
3.6.费用开支
软件开发过程中的费用开支如下：
4.项目关键问题
a) 项目计划制定的不详细时，后期工作不好做；
b) 需求分析做不到位的话，软件可能不能满足用户的需求；
c) 系统各个小模块不能很好的融合到一起，使其成为一个有机的整体； d) 数据流图和关系模型的建立。
5.总结分析
其实，任何一个项目在执行过程中都会碰到许多问题的，评价一个项目是否成功并不能以碰到问题的多少作为标准，其标准应是按时、保质实现预先确定的各项指标，比如说系统的功能、系统的性能等，完成合同要求内容，也要提供优质的服务，搞好与客户关系；同时也要规范管理，为公司今后的工作积累技术信息，市场信息，人才资源和管理经验，提升企业形象，保障事业的进一步发展。
总之，项目成败取决于很多因素，项目管理中的沟通是关系到项目成败的关键之一。大型的IT应用项目不仅仅是一个技术工作，更是一场管理变革。
第14篇：软件开发项目实训总结
软件项目实训总结
时间过的好快啊，为期三个礼拜的实训生活即将结束了，短短的三个礼拜让我们收获很大，专业知识、编程水平都有很大的提高。刚开始三天的高强度的课程安排让我们受益匪浅；接下来的上机实训又让我们可以巩固了课程。这让我觉得实习生活充实而有意义。辅导老师配好了环境之后，我们开始了项目的制作，这次项目实训算是自己小学期间主要完成的项目。最后，自己的努力还是有收获的，看着电脑上记录得满满的代码，看着自己的项目最终能够运行成功，就觉得很有成就感。
在本次的实训中，除了让我明白工作中需要能力，素质，知识之外，更重要的是学会了如何去完成一个任务，懂得了享受工作。当遇到问题，冷静，想办法一点一点的排除障碍，到最后获取成功，一种自信心由然而生，这就是工作的乐趣。有时候也需要虚心请教，从别人的身上真得能学习到不自己没有的东西，每一次的挫折只能使我更接近成功。除此以外，我还学会了如何更好地与别人沟通，如何更好地去陈述自己的观点，如何说服别人认同自己的观点。这次所学知识与实际的应用，理论与实际的相结合，让我大开眼界。也是对以前所学知识的一个初审吧！这次实习对于我以后学习、找工作也真是受益菲浅，在短短的一个星期中让我初步从理性回到感性的重新认识，也让我初步的认识这个社会，对于以后做人所应把握的方向也有所启发！相信这些宝贵的经验会成为我今后成功的重要的基石。
在此，我非常感谢学院领导和指导老师对这次实训的大力支持。
第15篇：软件开发项目实训方案
软件开发实训项目方案
——北京中科海教育科技有限公司
一.实训公司介绍
科海集团是在1983年5月由中国科学院和北京市海淀区政府联合创办，是中关村最早成立的高新技术企业，国内知名的IT企业，与“四通、融通、京海、科海”并称为中关村的“两通两海”。2003年，科海集团投资创办北京金科海科技发展有限公司。2004年，公司被认定为中关村高新企业。
北京中科海教育科技有限公司是以软件开发为主的高科技公司，专注于技术提高用户体验为目标，我们追求软件产品的最优化，致力于为客户打造最实用的软件产品。我们主要致力于全球中小型企业信息化系统的开发工作，包括CRM，ERP，协同系统等。涉及政府，房地产，医药等多个行业。同时为广大客户提供全方位的网络综合信息化服务及多层次电子商务解决方案。协助企业创建完备出色的互联网信息平台，利用现代科技手段把握机遇，并创造更高价值。其下属的全资子机构，北京新科海学校致力于IT职业技能培训业务，牢固树立以就业为导向，以服务为宗旨的办学理念，多年来培养了大量的IT领域高技术专门人才，为区域经济和社会发展做出了巨大贡献。
二.关于大学生就业实训
2009年，全国应届高校毕业生将达到万人，加上往年未就业的高校毕业生，就业需求极大。而另一方面，受当前经济形势影响，出现了企业用工需求下降、现有岗位非正常流失等新情况、新问题，致使当今大学生就业问题显得尤为突出。与此同时，当今高等教育和社会需求之间并不能很好地衔接，企业需要的是复合型、实用技能型人才，而高校毕业生所受教育普遍存在与其日后从事岗位所需的实践技能脱节的问题，学历层次不等于技能层次。
按照教育服务市场需求、服从产业结构调整的原则，改造现有高校课程设置结构、调整专业培养方向、强化实用技能培训、为学生提供就业项目实训等创新培养模式成为必然。
为推进高等教育、职业培训与社会需求相衔接，北京中科海教育科技有限公司推出IT领域大学生就业实训项目，本课程由IT企业为新入职技术职位员工的内训课程改造而来，主要针对高校计算机及相关专业毕业生，通过专业的项目开发训练，让学员们在完
成项目的过程中巩固在学校里学习到的基础知识。获得实用、领先的就业经验技能；增加求职竞争力，并在其职业生涯第一年拥有明显优势；在职人员可以丰富自己的职业技能，开拓更为广阔的职业道路。
三.实训项目介绍
Java软件开发实训项目
实训目标：
软件开发实训课程，通过一个完整的软件开发项目，使具有一定编码基础、但没有或只有很少实际工作经验的学员能够了解软件项目开发的整个过程，并最终具备编写项目可行性研究报告、项目开发计划书、软件需求文档、概要设计和详细设计文档、用户手册及项目开发总结报告的能力。
实训项目资料：
-
-
-
-
-
-
-
-
开发环境配置手册项目需求文档项目概要设计文档项目详细设计文档项目数据库设计文档程序代码规范开发流程规范程序代码质量控制规范
项目一: 内容管理系统CMS设计与实现
内容管理系统（Content Management System，CMS）内容管理系统是企业信息化建设和电子政务的新宠，也是一个相对较新的市场，CMS其实是一个很广泛的称呼，从一般的博客程序，新闻发布程序，到综合性的网站管理程序都可以被称为内容管理系统。
在CMS领域，在各个层面都有极多地优点，在政府上网，学校上网，商业门户，信息港，地方门户网，等各种设计到文章发布和用管理的网站建设中。其特点/优势如下：
- 可以针对各种内容进行分类和发布管理。可以针对不同类型的用户发布不
同的内容，可以将各种内容进行分类。
- 可以任意定义内容类型与多媒体支持。
- 用户接口可编辑性强，可以根据客户要求订做用户接口和风格模块。
- 可分布式管理。站点管理和维护人员无须集中在同一个办公室，甚至都不
用在同城，全球任何一个有网络的地方都可以让您实现高效率的管理。
- 可开发性强，可以针对不同的需求进行专门的开发。
容易使用。用户不必具备计算机编程基础、只需根据用户操作手册（或经
过简单演示）就可以轻松地管理并运作整套系统。
系统开发与运行环境：
-服务器：基于Intel构架的企业服务器
-操作系统：Microsoft Windows 200x/XP
-支持环境：Tomcat/WebLogic Server、JDK
-数 据 库：Oracle
-编程语言：Java、Servlet、JSP、Javabeans、HTML
-设计工具： Dreamweaver、Photoshop、Eclipse等
-客户端：IE6.0以上
前提知识/技术：JavaSE、Java Web编程（JSP/Servlet/JavaBean）、数据库应用、JDBC编程。
项目二: 网络实时通讯系统设计与实现
实时通讯系统（Real-time Communication System，RCS）也称“即时通讯工具”，用于实现网络即使通讯——利用有效硬件，如电脑、视频、可视电话、手机等，在这些终端硬件上安装实时通讯程序，如QQ、ICQ、MSN、网易POPO等，只要双方都安装有同样的这种程序，然后利用网络连接在线，就可以类似面对面交流一样，实行语音、文字、视频等的实时交流。
系统开发与运行环境：
-服务器/客户端：主流PC
-操作系统：Microsoft Windows 200x/XP
-支持环境：Sun JDK
-数 据 库：Oracle
-编程语言：Java SE
-设计工具：UltraEdit/Jcreator/Eclipse等
前提知识/技术：JavaSE、Java GUI编程、Java Scoket编程、多线程编程、数据库应用、JDBC编程。
-
四.实习特色及优势
实训周期：
项目实训时间由院校和我公司双方协商，实训学时：80学时（两周）。
资深专家
行业内资深技术专家亲自指导，他们在技术、项目及职业发展方面的经验与成就，为参加实习的学生提供最直接高效的实习效果。
全真项目
项目也是至关重要的因素，学生实习的项目就是公司真实开发的项目，代表了当前国际国内IT行业最主流的技术方向及应用领域。
赠送资料
凡参加暑期实训的学员均赠送java学习视频教程一套
五． 时间安排
暑期项目实训时间定于2009年7月20日－2009年7月31日，周一至周五全天实训。
7月20日－7月24日 项目实训
7月27日－7月31日 项目实训
7月26日参观北京奥林匹克公园（免费）
除了暑期之外，其他时间，也欢迎各个大学联系我们，组织学生参加我们的免费实训（为期两周，无任何学习费用，食宿自理）。
六.后勤保障及服务
接待
我们提供从车站到实习公司的一站式接待服务，院校及学生无需为交通、接站、入住基地等事宜操心。
食宿
公司统一安排食宿，安全卫生便捷，以保证所有学生能全身心投入到实习中去。真正感觉北京IT行业的良好氛围。
住宿费一天25元，楼房，24小时热水，有空调。
七.联系方式
联系人：高老师
北京中科海教育发展有限公司
电话：010- 8260889
2、82617627
第16篇：软件开发项目管理应用(4天)
软件开发项目管理应用（4天）
一、课程目的
为了加强企业信息科技部门建设，提升信息科技部门人员管理技能，充分掌握并应用项目管理的流程、工具和方法，从而提高IT项目实施的效率和效益。拟开展企业信息化项目管理应用培训，经培训使参训人员能用项目管理方法论指导企业信息规划和IT项目建设。
二、课程收益
熟悉项目管理概念和工具技术的应用
了解项目实施和监控过程方法
理解企业信息科技部门IT项目管理体系，掌握企业信息中心项目化管理应用。
三、授课方式
课程讲解、实战训练、案例研讨、模板演示、讨论引导
四、课程对象
分管领导，部门经理、项目经理、项目成员、信息中心人员及对项目管理有兴趣的员工。
六、课程大纲
破冰
（一）项目管理过程活动梳理
1.1项目与项目管理
1.1.1信息化项目管理应用
1.1.2项目管理过程活动流程介绍
1.1.3美国项目管理学会(PMI)项目管理专业人员(PMP)考试制度 □ 问题解答
1.2.软件开发项目管理过程
1.2.1软件开发项目生命周期选择
1.2.2.1新版项目管理思想生命周期的化繁为简
1.2.2.2 HP项目生命周期模型介绍与研讨
实战训练1：确定企业项目生命周期方法与模型
1.3.软件开发项目实施组织环境和项目管理因素
1.3.1软件开发项目组织环境：环境—方法—人—工具
1.3.1.1项目组织环境对项目的影响
1.3.2项目接口与支撑体系
模板演示1：IT项目多功能团队接口/界面和工作关系管理
1.3.3软件开发项目管理状况分析
1.3.3.1项目目标和过程成功要素
1.3.3.2导致项目失败的12大因素
（二）软件项目管理方法技术实操演练
2.1项目启动
2.1.1成功的软件开发项目启动
2.1.1.1项目分类（IT工程类项目、软件开发类项目、系统维护类项目……）
4.1.1.2软件开发项目组织类型与项目利害关系者分析管理
4.1.1.3项目角色管理与职责矩阵
2.1.2项目经理选择与项目经理的责权利
2.1.2.1项目经理应该具备哪些能力标准和素质要求
2.1.2.2没有合格项目经理怎么办?
演示：技术型项目经理如何转到技术管理型项目经理
2.1.3软件开发项目经理的两个权利来源
2.2项目规划
2.2.1约定开发过程规则,是项目管理流程,制度,模板和控制的基础保障
2.2.2如何定义软件开发项目的多目标性
2.2.3从软件开发项目需求管理到完成概要设计
2.2.3.1业务需求如何转换为技术需求,技术需求如何转换为产品需求
2.2.3.2需求的接口界面
2.2.3.3如何杜绝需求评审走过场
2.2.3.4项目不断提出需求变更应该如何应对？
2.2.3.5项目需求变更的应对措施：时段法、版本法、有无法……
2.2.3.6如何与业务部门达成需求变更流程规则？
案例研讨：中兴通讯如何管理定性需求
2.2.4 IT项目规划进度规划
2.2.4.1软件开发活动的逐渐明晰与PERT估算方法应用
2.2.4.2中国移动软件开发项目活动工期估算方法介绍
2.2.4.3如何使计划适应变化？
2.2.4.4可操作性和可控计划是如何做出来的？
2.2.4.5三级计划制定的时间点
2.2.4.6开发计划制定的步骤和注意事项
2.2.5、IT项目资源规划
项目多、时间紧、人员少，项目如何确保满足业务要求，过程中又如何实施进度监督与控制，资源或需求发生变化后的进度基准如何确定，对项目进度应如何评价？
2.2.5.1如何调节资源使用的高峰低谷
2.2.5.2进度压缩在软件开发中的应用
2.2.5.3如何通过绩效杠杆调节软件架构师、开发人员和测试人员的协同工作
2.2.5.3.1软件开发项目的考核KPI和考核方法
2.2.5.3.2如何设置开发项目激励奖金？
2.2.5.3.3软件开发项目经理如何评价项目成员绩效？
2.2.6 IT项目费用规划
2.2.6.1费用估算
2.2.6.1.1费用估算依据
2.2.6.1.2费用估算方法
2.2.6.1.3准备金分析
2.2.6.1.4实现价值分析
2.2.7 软件项目质量规划
2.2.7.1 IT项目管理与ISO
2.2.7.2 IT项目与CMM
2.2.7.3 IT质量规划
2.2.7.4SPPP、SQA、QC和SCM
2.2.7.5质量管理工具(益本比分析、基准对照、实验设计、因果图、控制图、流程图、直方图、帕累托图、趋势图、散点图、统计抽样、检查)
2.2.8 制订项目管理计划
2.2.8.1项目管理计划的作用
2.2.8.2项目管理计划的适应范围与应用裁剪
2.2.8.3项目管理信息系统、配置管理系统、变更控制系统之关系与作用 模板介绍：项目管理计划模板介绍
2.3.软件开发项目指导、执行与控制
2.3.1如何实现软件开发项目的过程可控、可视、可度量
2.3.2项目绩效状态报告
模板演示:IBM软件开发项目绩效状态报告模板
2.3.3软件开发项目经理如何指导项目成员执行项目任务
案例研讨:某集团信息中心如何通过建立项目化运作机制,解决项目资源冲突问题
2.3.4如何保证各配合部分提交的工作包是符合质量的?
2.3.5风险应对与监控
2.3.5.1风险规划,让项目防患以未然
2.3.5.2谁来识别项目风险?如何识别项目风险?
2.3.5.3如何评估风险给项目带来的机遇或影响?
2.3.5.4风险评审、风险审计、风险责任
2.3.5.5为什么需要对风险进行集中管理
模板演示:风险管理列表
2.3.6如何规避同样的问题重复发生
模板演示:问题管理流程模板示例介绍
2.4.软件开发项目收尾
2.4.1项目验收
2.4.2项目总结
2.4.3项目后评估
2.4.4如何做好项目移交
2.4.5项目成员解散
模板演示:软件开发项目总结报告
2.5.软件开发多项目管理
2.5.1多项目管理工作方式
2.5.1.1项目群管理
2.5.1.2项目组管理
2.5.1.3项目总监与项目池、资源池
2.5.1.4多项目的多级控制
(三)软件开发项目的激励方法
3.1软件开发项目团队建设与激励
3.1.1软件开发项目经理权利类型
3.1.1.1职位权利,强制权利,奖赏权,专家权,个人魅力,权威权利
3.1.2项目经理领导与管理方式
3.1.2.1专制型,民主型,协商专制型,协调型,引导者
3.1.3软件项目团队建设活动
3.1.3.1例行活动、项目阶段重大成果……
3.1.3.2软件开发团队激励:项目管理之星、项目攻关荣誉奖、月度之星、季度明星、BUG克星……
模板演示:软件开发团队建设指导模板
3.1.4软件开发项目激励方法
3.1.4.1需求法,双因素法,XY方法,期望法,光环法
3.1.4.2项目激励方式:荣誉奖、积分卡、发表扬信、公告、宣传,奖赏
3.1.5项目团队绩效评估
现场训练:抱团打天下
(四)软件开发项目的有效沟通
4.1项目沟通技巧
4.1.1项目沟通渠道计算
4.1.2项目沟通类型
4.1.3项目沟通模型
4.1.4如何将技术语言转换成业务语言进行有效沟通
4.1.5有效的项目沟通影响因素
游戏:项目沟通模拟游戏
4.1.6沟通宝典：项目利害关系者政治关联分析法
案例研讨:根据案例资料识别和管理项目利害关系者
4.2常见的冲突及解决技巧
4.2.1冲突来源
4.2.2有效的冲突管理思维
4.2.3项目冲突的五种有效解决方法
4.2.3.1规避,缓和,折中,正视问题,妥协 课程总结
培训联系:左老师
电话:021-63233980
手机:13818969074
QQ:2749919646
邮箱:zuozl@tsinghui.com
第17篇：软件开发项目计划书格式（优秀）
正文
一、项目计划书格式
根据《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 标准、条约和约定
列出在本项目开发过程中必须遵守的标准、条约和约定。例如：相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。
“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得；“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。
软件开发计划
版本
[注：以下提供的模板用于
Rational Unified Proce。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=正文）。]
修订历史记录
日期
版本
说明
作者
目录
1. 简介
1.1 目的
1.2 范围
1.3 定义、首字母缩写词和缩略语
1.4 引用
1.5 概述
2. 项目概述
2.1 项目的目的、规模和目标
2.2 假设与约束
2.3 项目的可交付工件
2.4 软件开发计划的演进
3. 项目组织
3.1 组织结构
3.2 外部接口
3.3 角色与职责
4. 管理流程
4.1 项目估计
4.2 项目计划
4.2.1 阶段计划
4.2.2 迭代目标
4.2.3 发布版
4.2.4 项目时间表
4.2.5 项目资源分配
4.2.5.1 人员配备计划
4.2.5.2 资源获取计划
4.2.5.3 培训计划
4.2.6 预算
4.3 迭代计划
4.4 项目监测与控制
4.4.1 需求管理计划
4.4.2 进度控制计划
4.4.3 预算控制计划
4.4.4 质量控制计划
4.4.5 报告计划
4.4.6 评测计划
4.5 风险管理计划
4.6 收尾计划
5. 技术流程计划
5.1 开发案例
5.2 方法、工具和技术
5.3 基础设施计划
5.4 产品验收计划
6. 支持流程计划
6.1 配置管理计划
6.2 评估计划
6.3 文档计划
6.4 质量保证计划
6.5 问题解决计划
6.6 分包商管理计划
6.7 流程改进计划
7. 其他计划
8. 附录
9. 索引
软件开发计划
1.
简介
[软件开发计划的简介应提供整个文档的概述。它应包括此软件开发计划的目的、范围、定义、首字母缩写词、缩略语、引用和概述。]
1.1
目的
[阐明此软件开发计划的目的。]
1.2
范围
[简要说明此软件开发计划的范围：它的相关项目，以及受到此文档影响的任何其他事物。]
1.3
定义、首字母缩写词和缩略语
[本小节应提供正确理解此软件开发计划所需的全部术语、首字母缩写词和缩略语的定义。
这些信息可以通过引用项目词汇表来提供。]
1.4
引用
[本小节应完整地列出此软件开发计划中其他部分所引用的所有文档。
每个文档应标有标题、报告号（如果适用）、日期和发布组织。 列出可从中获取这些引用的来源。这些信息可以通过引用附录或其他文档来提供。
对于软件开发计划，所引用工件的列表中应包括：
_
迭代计划
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
需求管理计划
评测计划
风险管理计划
开发案例
业务建模指南
用户界面指南
用例建模指南
设计指南
编程指南
测试指南
手册风格指南
基础设施计划
产品验收计划
配置管理计划
评估计划（仅当该计划是单独的计划时，但它通常是文档计划
质量保证计划
问题解决计划
SDP 的6.2 节）
_
分包商管理计划
_
流程改进计划]
1.5
概述
[本小节应说明此软件开发计划中其他部分所包含的内容，并解释文档的组织方式。]
2.
项目概述
2.1
项目的目的、规模和目标
[简要说明此项目的目的与目标，以及此项目将要交付的可交付工件。]
2.2
假设与约束
[列出此计划所依据的假设和对项目的所有约束（如预算、人员、设备、时间表等）。]
2.3
项目的可交付工件
[以表格的形式列出将在项目中创建的工件，包括目标交付日期。]
2.4
软件开发计划的演进
[以表格的形式列出软件开发计划的提议版本，以及在计划外修订与重新发行此计划需符合的标准。]
3.
项目组织
3.1
组织结构
[说明项目团队（包括管理人员和其他复审委员会）的组织结构。]
3.2
外部接口
[说明项目与外部组织联系的方式。
对于每个外部组织，应确定其内部和外部联系人的姓名。]
3.3
角色与职责
[确定将负责各个核心工作流程、工作流程明细和支持流程的项目组织单位。]
4.
管理流程
4.1
项目估计
[提供所估计的项目成本与进度、这些估计所依据的基础，以及项目中将重新进行估计的时间点和情况。]
4.2
项目计划
4.2.1
阶段计划
[包括以下内容：
_
工作细分结构
(WBS)
_
显示项目各阶段或迭代的时间分配情况的时间线或甘特图
_
确定主要里程碑及其成就标准
确定所有重要的发布点和演示版]
4.2.2
迭代目标
[列出每次迭代将要实现的目标。]
4.2.3
发布版
[简要说明每个软件发布版，并指出它是否是演示版、Beta 版等。]
4.2.4
项目时间表
[用图表显示完成迭代与阶段、发布点、演示版及其他里程碑的目标日期。]
4.2.5
项目资源分配
4.2.5.1
人员配备计划
[在此处确定所需人员的数目和类型，以及项目阶段或迭代需要的任何特殊技能或经验。]
4.2.5.2
资源获取计划
[说明您将如何发现并得到项目所需的人员。]
4.2.5.3
培训计划
[列出项目团队成员需要的所有特殊培训，以及完成这些培训的目标日期。]
4.2.6
预算
[按照
WBS 和阶段计划分配成本。]
4.3
迭代计划
[通过引用的方式将各项迭代计划附加在本节中。]
4.4
项目监测与控制
4.4.1
需求管理计划
[通过引用附加。]
4.4.2
进度控制计划
[说明以何种方法按照所计划的时间表监控项目进展，以及如何在需要时执行纠正操作。]
4.4.3
预算控制计划
[说明以何种方法按照项目预算监控项目开支，以及如何在需要时执行纠正操作。]
4.4.4
质量控制计划
[说明将在何时、以何种方法来控制项目可交付工件的质量，以及如何在需要时执行纠正操作。]
4.4.5
报告计划
[说明将生成的内部和外部报告，以及报告发布的频率和范围。]
4.4.6
评测计划
[通过引用附加。]
4.5
风险管理计划
[通过引用附加。]
4.6
收尾计划
[说明有序地完成项目所要执行的活动，其中包括人员重新分配、项目材料存档、事后检查汇报及报告等。]
5.
技术流程计划
5.1
开发案例
[通过引用附加。]
5.2
方法、工具和技术
[以引用的方式列出所记录的项目技术标准：
_
业务建模指南
_
用户界面指南
_
用例建模指南
_
设计指南
_
编程指南
_
测试指南
_
手册风格指南]
5.3
基础设施计划
[通过引用附加。]
5.4
产品验收计划
[通过引用附加。]
6.
支持流程计划
6.1
配置管理计划
[通过引用附加。]
6.2
评估计划
[作为软件开发计划的一部分，本小节说明项目的产品评估计划，并介绍评估所使用的技术、标准、指标和过程；评估将包括走查、检查和复审。请注意，评估计划是对测试计划的补充，但软件开发计划中并不包括测试计划。]
6.3
文档计划
[通过引用附加。]
6.4
质量保证计划
[通过引用附加。]
6.5
问题解决计划
[通过引用附加。]
6.6
分包商管理计划
[通过引用附加。]
6.7
流程改进计划
[通过引用附加。]
7.
其他计划
[列出合同或法规所要求的其他计划。]
8.
附录
[供
SDP 读者使用的其他材料。]
9.
索引
第18篇：软件开发项目奖金发放制度
软件开发项目奖金计算及发放制度
（试用稿）
第一条 综述
为调动公司软件研发人员的工作积极性，提高软件的开发质量和开发效率，促进研发人员深入市场，及时跟踪软件产品的使用情况，在公司现有绩效考评制度基础上制定此制度。 第二条 管理办法
公司软件项目实行目标管理。 第三条 执行范围
1）本制度适用于从事软件项目开发的人员。
2）本制度适用于软件项目开发运行全生命周期，即需求调研、软件设计、软件开发及测试、软件运行维护。 第四条 整体考核目标
1）品质 2）工期
详见《软件项目立项申请表》。 第六条 奖金成立
1、部门主管根据市场需求，填写《软件项目立项申请表》并经需求提出项目主管、技术总监、技术副总、董事长签字同意。
2、技术副总、董事长认为可立项软件，下发《软件项目立项申请表》填写，经技术总监、项目负责人确认工期及缺陷数目。第六条 奖金构成
1、基础奖金总额：
1）合同类项目：项目奖金的发放额度在项目合同签订后确定，原则上不得超过所研发的软件合同金额的8％，不低于合同金额的5％，具体额度由部门经理、总工程师、技术总监协商，董事长最终确定。
2）投入类项目：由公司直接投入项目，在明确项目内容后，部门经理、总工程师、技术总监计算项目人员工时，核算投入金额报技术副总、财务总监、董事长确认项目总投入额。原则上以软件投入总金额的10％作为项目开发奖金。
3）当发生大市场变化，需要重新确定奖金发放额度时，可由部门经理提出，经过技术总监、主任工程师、技术副总、总经理重新协商后，董事长最终确定。
2、奖金构成：
1）项目承担部门奖励（奖励1）
奖金总金额的60%为工期奖金；发放对象：项目设计、开发、测试参与人员。
奖金总金额的40%为品质奖金；发放对象：项目设计、开发、测试参与人员。
2）应用奖金（奖励2）
应用奖金（奖励2）=奖励1的5%-8%。发放对象：应用部参与人员。 3）维护奖金（奖励3）
维护奖金（奖励3）=奖励1的5%-8%。发放对象：运维部参与人员。
4）特殊奖励（奖励4）
特殊奖励（奖励4）=最高为奖金总金额的10%为特殊奖励； 第七条 奖金浮动
1、工期奖金：项目提前完成时，按比例增加奖金发放额度，滞后时按比例减少发放额度。增减上限为奖金基础数额的50%。比例计算方法为：浮动比例＝（计划工作日-实际工作日）/计划工作日。当增加比例大于50％时，按50％计算，当增加比例小于-50%时，按-50%计算。当项目未完成立项时所计划的质量目标时，此条无效。
例如，项目计划用100天完成，项目组实际用了80天，确定的工期基础奖金额度为1万元，则浮动比例为（100-80）/100=20%，实际实际工期奖金额度为10000×(1+20%)=12000元。项目计划用100天完成，项目组实际用了120天，则浮动比例为（100-120）/100=-20%，实际每例的奖金额度为10000×(1-20%)=8000元。
2、品质奖金：
当项目未完成立项时所计划的质量目标时，按比例减少奖金发放额度，比例计算方法为： 减少比例＝（实际缺陷数量-计划缺陷数量）/计划缺陷数量 当减少比例大于50％时，按50％计算，当减少比例小于0时，按0计算。
例如，项目的计划缺陷数为100，实际缺陷数为120，确定的基础奖金额度为10000元，则减少比例为（120-100）/100=20%，实际每例奖金额度为10000×(1-20%)=8000元。
开发过程中，在内部质量审核时，由于存在质量问题或不符合标准等问题，被下达《软件整改通知单》进行整改的，每下达一次《软件整改通知单》，扣除项目组研发人员项目品质奖金总额度的10％。 第八条 奖金发放
1、工期奖金：按项目进度里程碑，采用每个月度按项目完里程碑奖金数额发放；
2、品质奖金：项目通过上线验收，进入试运行阶段后，经主任工程师、技术总监、技术副总验收，按品质控制要求确定品质奖金实际发放数额。由部门经理提供人员奖金表，部门主管及技术负责人一次发放50%，另外50%作为质量保证金累积进入个人年终奖或半年奖；其余参与人员一次发放60%，另外40%作为质量保证金累积进入个人年终奖或半年奖；公司系统质量保证期间为3个月-6个月。
3、实发应用奖励（奖励2）：应用部经理核算本部门参加项目人员的工作量并进行百分制打分，确定个人发放比率，与项目工期奖励同期发放。
4、运维奖励（奖励3）：核算本部门参加项目人员的工作量并进行百分制打分，确定个人发放比率，与项目工期奖励同期发放。
5、特殊奖励：由部门主管提出特殊人员奖励名单（1-2人），交主任工程师、技术总监、技术副总审核，提交公司董事长，由公司董事长签字一次性发放。
（注明：上述奖金发放个税由个人承担） 第九条 休假奖励
采用项目奖励后，不再发放加班费，采用休假奖励方式调休。执行条件：
1、工期奖金>100%；
2、品质奖金>80%。
执行办法：工期提前完成的自然日/3=部门轮休日。
例如提前完成工期10天，工期奖金110%，10/3=3.33天，部门获得带薪休假天数3天。 第十条 后续品质控制
1、试运行阶段：公司系统上线试运行质量阶段为1个月-2个月，在系统试运行期间，以故障发生数目以及处理时间为指标测评系统运行品质，计算方法如下：
1）故障缺陷发生4小时内解决，不累计缺陷数目；部门主管可不上报该缺陷；
2）故障缺陷4-12小时内解决，按0.5X故障次数累积缺陷数目，部门主管必须上报缺陷； 3）故障发生12小时-24小时解决，按1.0系数计算缺陷数目，部门主管必须上报缺陷；
4）故障发生解决时间超过24小时，按2.0系数计算缺陷数目，部门主管必须上报缺陷；
5）故障无法解决，必须重新架构系统，一次性全部扣除质量保证金。
6）故障瞒报，发生一次故障瞒报，一次性全部扣除质量保证金。 奖金扣除处理：
1）测试人员提报：扣除项目组质量奖金直接发放到发现该缺陷的公司员工；
2）用户提交：直接扣除提留质量奖励。
2、正式运营阶段：如果有“一级缺陷”未在测试中或试运行阶段被发现，而在后续的正式运营中被发现的，从缺陷被发现之日起，测试人员不再获得该项目奖金，并全额扣除项目组人员的质量保证金。除“一级缺陷”以外缺陷，由部门经理指定人员维护。
第十一条 工期加急免责期限
项目因公司业务需要，工期明显缩短导致无法保证完整测试周期的，项目主管可按项目测试周期申请加急免责期，其最高时间长度为项目实际测试周期。 第十二条 奖金重新设置
当项目产品由于技术升级等原因，经公司技术副总审核通过、重新立项升级后，分配比例重新确定，奖金发放时限按新项目计算。 第十三条 管理责任
由于项目组备份不及时和备份管理不到位造成项目资料丢失，致使开发周期延误的，每发生一次扣发项目负责人项目奖金的30％，直至全部扣发。造成重大损失的，全部扣发项目负责人项目奖金，并根据具体情况追究其责任,是否为重大损失由技术副总确认。 第十四条 试用期限
本制度试用2015年4月1日-2015年12月31日，正式使用或调整另行通知。
第19篇：软件开发项目经理(项目管理软件方向)岗位职责
1.负责项目管理软件的全部开发管理工作。2.负责开发工作计划的制订、任务安排、工作检查和考核。3.负责项目管理软件相关的开发代码、配套文档的管理工作。4.负责开发队伍的建设和培养。
第20篇：政府采购招投标项目合同软件开发
软件委托开发服务合同 合同编号：【】
本合同由以下双方根据平等自愿原则，协商一致在北京市朝阳区签订：
甲方：【】 住所：【】 授权代表人：【】 邮编：【】 联系电话：【】 传真：【】
乙方：【】
营业执照注册号：【】 法定住所：【】 法定代表人：【】 邮编：【】 联系电话：【】 传真：【】 账户名称：【】 开户银行：【】 公司账号：【】
本《软件委托开发服务合同》（以下简称“本合同”）经甲、乙双方友好协商签订，双方就软件开发事宜达成以下合同内容。
第一条 软件开发内容
甲方委托乙方就【】项目进行软件开发(详见附件一投标文件《投标
1
第二条
第三条
第四条
第五条
文件名称》)，乙方应按甲方要求及标准（详见附件二《软件开发要求及标准》）在约定期限内，向甲方提交下列开发工作成果【】。
软件开发期限
乙方应在【本合同签订后x天内】/【 年 月 日之前】，完成全部开发服务内容，并向甲方提供全部开发工作成果。
验收
甲方有权对乙方开发工作成果进行验收，经甲方验收不合格的，甲方有权要求乙方在指定期限内采取弥补措施，乙方采取弥补措施之后再次提交甲方验收。经乙方【三】次弥补仍未能经甲方验收合格的，甲方有权单方解除合同，不予支付合同款。
合同总价款及结算
本合同总价款为【】元人民币（大写：【】），该费用已包含本合同项下全部费用，包括但不限于税费、开发费、测试费等。除此以外乙方无权要求甲方因本合同支付其他任何费用。
本合同生效后【】个工作日内甲方支付合同总价款的【】%，即【】元人民币（大写：【】）；经甲方对乙方开发工作成果验收合格后【】个工作日内，甲方向乙方支付余款【】%，即【】元人民币。 甲方付款【前/后】，乙方应向甲方提供合法税务发票。
服务承诺
1、乙方应按约定的服务内容、服务期限为甲方提供服务。甲方有权书面通知乙方在指定期限内报告开发进度及开发情况。
2、甲方有对服务进度及服务内容进行抽查检验的权利，甲方有在抽验后书面通知乙方在指定时间内进行改正的权利。
3、乙方严格遵守中华人民共和国法律、法规及合同对有关技术资料及技术的要求。
4、乙方确保其提供的本合同项下的所有产品、技术、资料和服务，不会侵犯第三方的知识产权或所有权，否则经甲方书面告知并同意乙方全权处理且予以配合后，乙方将承担由此造成的一切经济损失和法律责任。
2
第六条
第七条
5、乙方派出人员在甲方服务期间，因故意或过失给甲方造成相应损失的，乙方应承担相应的赔偿责任。
风险承担
1、在本合同履行过程中，因无法克服的技术困难，有可能致使研究开发失败或者部分失败的，乙方应在知晓该等事项之日起1个工作日内通知甲方，同时采取措施减少损失。甲方获得通知，同意变更开发内容或解除本合同的，双方另行签署书面协议。
2、乙方没有及时通知并采取适当措施，致使研究开发失败或者部分失败的，乙方承担合同不能履行的全部风险，甲方不予支付合同款。
知识产权
1、技术成果的归属：本合同项下委托开发完成技术成果的知识产权（包括但不限于申请专利的权利、单独转让专利的权利、技术成果的使用权、技术成果的收益权等）归属于甲方。乙方仅享有专利发明人署名权。
2、技术秘密成果的归属：本合同项下的技术秘密成果的使用权、转让权归属于甲方，甲方享有全部技术秘密的收益权。
3、新技术成果的归属：甲方在乙方所开发的技术成果基础上开发、研制形成的技术成果（包括但不限于程序、文件、资料等）的知识产权归甲方所有。
4、乙方保证乙方提供的服务以及开发的技术成果不存在任何侵犯第三方知识产权的情形。如果第三方声称乙方向甲方提供的服务以及开发的技术成果侵犯其知识产权，并已就此对甲方或乙方提起（包括威胁提起或很可能提起）法律诉讼程序或知识产权行政执法程序（简称侵权诉讼），则知悉上述事项的一方应立即通知合同对方，甲方有权：（1）暂停履行对侵权诉讼所涉服务或技术成果的采购或支付义务直至侵权诉讼完全解决，并要求乙方自担费用向甲方提供与该第三方协商、诉讼、和解所需的一切协助（包括但不限于向甲方提供证明侵权不存在的各类证据、派出人员参加协商、诉讼或会谈等）；且（2）甲方有权选择与该第三方达成和解，并由乙方支付和
3
第八条第九条第十条 解协议所约定的全部费用以及甲方因侵权诉讼而遭受的全部损失或费用（包括但不限于诉讼/仲裁费、律师费、交通费、通讯费、差旅费、对第三方的损害赔偿金、行政处罚罚款、获取该产品或服务相应使用许可的费用、因停止使用或修改、替换侵权威胁所涉及的产品或服务而遭受的损失等）。如果甲方选择继续参加侵权诉讼法律程序，乙方应当赔偿甲方因侵权诉讼及履行生效法律裁判而需支付的费用或遭受的损失，但生效法律裁判认定乙方产品或服务不存在侵犯第三方知识产权情形的除外。
5、不论本合同是否解除或终止，本条款持续有效。
保密义务
1、乙方应对其知晓的甲方的商业、技术、市场、管理、人事、财务等任何方面的信息和资料予以保密，未经甲方事先书面同意，乙方不得披露、使用或以任何方式处置上述信息、资料，并应促使其员工、关联方承担相同保密义务，如果乙方员工、关联方违反上述保密义务，视为乙方违反保密义务。
2、乙方违反保密义务的，应当对甲方因此所遭受的损失承担赔偿责任。如果乙方在本合同有效期内违反保密义务，甲方同时还有权提前终止本合同。
3、不论本合同是否解除或终止，本条款持续有效。
不可抗力
1、由于发生不可抗力事件（如战争、暴动、严重火灾、水灾、台风、地震、政府行为和禁令等事件），致使合同任一方不能履行合同义务时，遭受不可抗力事件影响的一方负有在不可抗力事件发生之日起【15】日内尽快通知合同对方和采取合理措施减少对方损失的义务。
2、遭受不可抗力事件影响的一方在履行前述义务后免除违约责任。但其合同义务不因此免除。经合同双方协商同意，合同履行时间可合理延长，延长时间相当于因事件发生受到影响的时间。
违约责任
1、乙方违反本合同约定义务的，甲方有权要求乙方在指定期限内采
4
取弥补措施，乙方未能弥补的，视为乙方违约，乙方应向甲方支付相当于合同总金额【百分之三】的违约金。
2、乙方延期履行的，每延期一日，按合同总金额【千分之三】的比例向甲方支付延期履行违约金。
3、因乙方过错造成甲方或第三方损失的，乙方应赔偿甲方或第三方全部直接损失。
4、甲方有权直接在未支付的合同总金额中扣除本条约定的违约金及赔偿金。
第十一条 争议管辖
本合同项下发生的争议，由双方当事人协商解决；协商不成的，由甲方所在地人民法院管辖。
第十二条 本合同自双方法定代表人或授权代表签字并加盖公章之日起生效。本合同一式两份，双方各执一份，具有同等法律效力。本合同的任何变更、补充或修改，应由双方协商一致并签署书面协议。
第十三条 通知与送达
任何一方根据本合同规定向另一方发出的通知应以书面形式作出，并以邮寄/快递、传真、专人送达方式发送。如以邮寄/快递方式发送，以邮寄/快递回执上注明的收件日期为送达日期。如以传真方式发送，收到传真机发出的确认信息后，视为送达。如专人送达，被送达人签署后，视为送达。各方联系信息以本协议文首所列为准，一方联系信息变化后，该方应在联系信息变化之前将变化情况书面通知其他方，否则该方应自行承担相应的风险、责任和后果。
第十四条 本合同中出现的“日”，除非明确写明为工作日，否则为自然日。 第十五条 本合同附件作为本合同内容的一部分，与本合同具有同等法律效力。 附件一：投标文件《投标文件名称》 附件二：《软件开发要求及标准》
5
（本页为签署页） 甲方：
（公章）
授权代表人（签字）：
【】年【】月【】日
乙方：
（公章）
法定代表人或授权代表人（签字）：
【】年【】月【】日
附件一：投标文件《投标文件名称》
附件二：《软件开发要求及标准》
