第一篇：软件项目管理报告案例
1．引言
1.1编写目的
该文档首先给出了整个系统的整体网络结构和功能结构的概貌，试图从总体架构上给出整个系统的轮廓，然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。其中对功能需求的描述采用了UML的用例模型方式，主要描述了每一用例的基本事件流，若有备选事件流则描述，否则则省略。而且还给出了非常直观的用例图。这些文字和图形都为了本文档能详细准确地描述用户的需求，同时也为用户更容易地理解这些需求的描述创造了条件。
1.2项目背景
a.所建议开发软件的名称：学生信息管理系统
b.项目的任务提出者：xxx学校。c.开发者：xxx软件开发公司。d.用户：全体师生。
e.实现软件的单位：软件3071软件开发公司。f.项目使用的软件：Microsoft access2003。g.系统：本软件应使用Microsoft Windows xp。1.3定义
本文档中没有用到专门术语的定义和缩写词的原文。1.4参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等，VISUAL BASIC程序设计——数据库篇，1999 [3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著，管理信息系统开发与应用，电子工业出版社，2003 [5] 软件工程，人民邮电出版社，2002年3月第一版
[6] 康博工作室，张红军，王红等缟著《Visual Basic中文版高级应用与开发指南》，人民邮电出版社，2001年4月第一版
[7] 林立军，程斌，翁迪恩缟著《Visual Basic 数据库开发指南》，西安电子科技大学出版社，2000年2月第一版
[8] 宋伟，吴建国等编著《中文Visual Basic编程基础》，北京，清华大学出版社
2．可行性研究的前提
2.1要求
通过调查,要求系统需要有以下功能:
⑴
要求有良好的人机界面;
⑵
较好的权限管理;
⑶
原始数据修改简单方便,支持多条件修改 ⑷
方便的数据查询，支持多条件查询;⑸
相应的权限下，删除数据方便简单，数据稳定性好；
⑹
数据计算自动完成，尽量减少人工干预;2.2目标 a.人力与设备费用的节省； b.处理速度的提高；
c.控制精度或生产能力的提高；
d.管理信息服务的改进； e.决策系统的改进； f.人员工作效率的提高。2.3条件、假定和限制
a.开发软件运行的最短寿命为一年。b.进行系统方案选择比较的期限：2周。c.经费来源和使用限制：自筹资金。
d.法律和政策方面的限制：本软件公司版权所有，未经作者允许，非法传播、复制，违者追究法律责任，后果自负。e.硬件CPU p3、内存256M.。f.软件：access2003。
g.运行环境：本软件应使用Windows2003、Windows xp操作系统。
h.开发环境：本软件应使用Windows2003、Windows xp开发。i.开发软件投入使用的最迟时间为2013年10月01日。2.4可行性研究方法
由于本系统管理的对象单一,都是在校学生，且每个数据内容具有较强的关联性，涉及的计算过程不是很复杂。因此，比较适合于采用数据库管理。且学校用于学生管理的微机都是PIII以上的机器，在存储量、速度方面都能满足数据库运行的要求。在技术难度方面，由于有指导老师的指导和相关参考文献，特别是网上资料，特别是参考其它程序的功能，因此完全可以实现
3．对现有系统的分析
3.1处理流程和数据流程 班级管理业务流程图： 档案管理业务流程图： 课程管理业务流程图： 成绩管理业务流程图 3.2工作负荷
现有系统所承担的工作只能实现档案管理的简单功能，无法适应目前工作 中处理大量数据的功能。3.3费用支出
开发这个项目总需三个人，4台计算机，一个可容纳6、7个人的办公室，必须有充足的物质做精神动力，每台计算机上必须有所需要的软件，比如：办公软件、数据库软件、截图软件等，必须有3000万元的准备开支。3.4人员
数据库管理人员1名，维护人员1名。
1、3.5设备
四台计算机,一台备用,一个工作室.一台打印机,扫描仪一台。3.6局限性
现有系统主要存在如下不足： 1）信息分散、共享性差 每个人的时间精力是有限的，大量的信息资源分散在不同的收集者手中，难于共享和发挥作用。还有就是用户毕业和离职时需要到不同的地方开办证明。2）信息的及时性、准确性差
数据的采集和处理部分靠人工，效率低、速度慢、滞后严重、反馈不及时，严重影响信息的反馈速度和质量，不能有效地、及时地提供基层决策需要的定量信息和领导决策需要的宏观定性信息。
4．所建议技术可行性分析 4.1对系统的简要描述
建议系统实现注册、查询等具体功能。4.2处理流程和数据流程
4.3与现有系统比较的优越性
系统实现学生教师查询各种信息。4.4采用建议系统可能带来的影响 4.4.1对现有软件的影响
需将计算机升级为CPU P3、内存256M，添加一台打印机。4.4.2对现有软件的影响
需要将Windows升级为2000以上。4.4.3对系统运行的影响
（1）用户的操作严格按照系统要求规程。
（2）要求创建系统管理员与普通用户两种登录方式，分权限管理。
（3）数据应有系统管理员手动输入系统，普通用户无权输入数据。
（4）对数据有保存要求，并且对数据存储，恢复的处理。
（5）输出报告以报表的形式打印出来。
（6）系统具有恢复和备份的功能。4.4.4对开发环境的影响
1、为了建立数据库，要求提供详细的数据资源。
2、为了开发和测验所建议系统而需要的计算机资源：CPU P3、内存256M。
3、如数据涉及保密与安全问题，应由专人负责录入。4.4.5对经费支出的影响
所建议系统的开发、设计经费开支：5000元。维持运行而需要的经费开支：1000元。4.5技术可行性评价
a.在限制条件下，完成功能目标的实现； b.利用现有技术，功能目标一定能达到；
c.对开发人员数量为5个人,每个人应对数据库知识有明确的了解，我们的组员都具有这种能力,一定按期完成工作；
d.在规定的期限内，开发顺利完成。5．所建议系统经济可行性分析 5.1支出
5.1.1基建投资
1、房屋和设施：500元。
2、ADP设备：1000元。
3、数据通讯设备500元。
4、环境保护设备200元。5.1.2经常性支出
1、设备的租金和维护费用：500元。
2、数据的通讯方面的租金和维护费用500元。
3、人员的工资和奖金开支：3000元。
4、其他经常性的开支：2000元。5.2收益/投资比 收益/投资比为3:1.5.3投资回收周期 投资回收周期为半年.5.4敏感性分析
1、应尽量延长系统生存周期，可延长至3年。
2、应是有效数据全部录入系统，使系统工作负荷量达到饱和。
3、应尽量提高系统的处理速度。
4、应提高设备和软件的配置。6．社会因素可行性分析 6.1法律因素
如果发现有侵权行为,必进行严格的处罚,本公司版权所有,未经作者的允许，禁止非法传播、复制，违者追究法律责任，后果自负。6.2用户使用可行性
本系统使用比较简单,适合普通用户操作,只要用户对说明书进行认真阅读,都可了解。7．其他可供选择的方案
方案有许多但本公司选择了这套方案,他具有自己的优越感,运用编制菜单栏来省去代码,这是界面有好起来,又降低了工作难度,进而宏的运用更简化了工作难度。除提供的建议方案的具体功能外，还需增加网络功能，未被推荐的理由是目前尚不具备开发条件，投入与效益不成比例。8.结论意见
结论意见可能是： a.可着手组织开发；
b.需待若干条件（如资金、人力、设备等）具备后才能开发； c.需对开发目标进行某些修改；
d.不能进行或不必进行（如技术不成熟，经济上不合算等）； e.其他。
三 软件项目计划
1.引言
1.1 编写目的
软件项目开发是一项系统而复杂的工作，它需要一个团队互相配合、分工协作。软件项目管理系统可以规范一个软件开发团队的日常工作，提高工作效率。
为了很好的管理整个开发过程，同时预算整个开发过程的费用及时间的安排，给开发人员，管理人员一个参照物，明白自己在每一个阶段所需要完成的任务，协助他们更好地完成开发工作。
预期的读者：开发人员，项目经理，测试人员 1.2 背景
a.学生信息管理系统 b.提出者：项目经理，开发者：XXX开发团队。1.3 定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。] 1.4 参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等，VISUAL BASIC程序设计——数据库篇，1999 [3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著，管理信息系统开发与应用，电子工业出版社，2003 [5] 软件工程，人民邮电出版社，2002年3月第一版
[6] 康博工作室，张红军，王红等缟著《Visual Basic中文版高级应用与开发指南》，人民邮电出版社，2001年4月第一版
[7] 林立军，程斌，翁迪恩缟著《Visual Basic 数据库开发指南》，西安电子科技大学出版社，2000年2月第一版
[8] 宋伟，吴建国等编著《中文Visual Basic编程基础》，北京，清华大学出版社 2.项目概述 2.1 工作内容 需求分析： 1~3个月 2 概要设计： 2~3个月 3 详细设计： 2~3个月 4 编码: 2~3个月 5 测试： 1个月 发布： 1个月 2.2 主要参加人员 参与者 个人情况
XX 软件工程专业学生，熟悉java语言，数据库编程 XX 软件工程专业学生，熟悉C#语言 XX 软件工程专业学生，有很好的网页设计能力
XX 软件工程专业学生，有良好的界面设计的能力和测试经验 XX 专业为软件工程，从事开发工作一年，能过独立地完成小型项目的整个开发过程
2.3 产品 2.3.1 程序
名称 编程语言 媒体形式 功能及能力
系统功能 C#+SQL Server 2000 文本 管理学生的学籍信息，统计学生的相关信息。学生信息的增加、修改、删除、查询 数据信息管理 C#+SQL Server 2000 文本 学生学籍信息管理，学生选课信息管理
基本业务 C#+SQL Server 2000 文本 学生注册、学籍信息维护，学生选课，老师管理班级信息。
信息浏览与查询 C#+SQL Server 2000 文本
管理员学生学籍信息浏览、查询
数据库 SQL Server 2000 数据库文件 数据库文件可以直接附加到本地的SQL Server 2000中的数据库中
学生学籍管理系统 C#+SQL Server 2000 CD光盘
程序的运行文件，运行之后只要发布之后就可以了 2.3.2.文件
需求说明书，安装指南，用户操作手册，预计可能出现故障及解决办法 2.3.3.服务
培训安装：系统测试完毕之后，2012年10月10日至12日两天的安装和使用的培训时间，主要是让用户适应本系统的运行环境与操作习惯 维护：系统出现故障时，用户可参照手册进行自行解决，如果解决不了，则派维护人员过去，系统的维护期2012年10月14日到2013年10月15日，超过期限将不再派人去维修 2.3.4.非移交的产品
整个系统全部的的代码不必要给用户，所使用的技术及参考的文献也可以自己保留，以及该软件所使用的技术文档，这些都是不用给用户的 3.实施计划
3.1 工作任务的分解与人员分工 1需求分析
负责人： 汪国志 参与人：汪国志 2 概要设计
负责人：汪国志 参与人：汪国志 3 实现
负责人：汪国志
参与人：汪国志，XXX，XXX，XXX，XXX，XXX 4 测试
负责人：汪国志 参与人：汪国志 5 维护及用户培训 负责人：汪国志 参与人：汪国志 3.2 接口人员 负责人：汪国志 参与人：汪国志
职责:统一接口，使不同层之间能通信 3.3 进度 1 需求分析
开始时间：2012-10-01 完成时间：2012-12-30 所需资源：客户的需求
完成标志：完成需求分析说明书 2 设计
开始时间： 2013-01-01 结束时间： 2013-03-01 所需资源： 需求分析说明书 完成标志： 概要设计说明书 3 编码实现
开始时间： 2013-03-01 结束时间： 2013-06-01 所需资源： 概要设计说明书，设配 完成标志： 系统能顺利运行 4 测试
开始时间： 2013-06-01 结束时间： 2013-08-01 所需资源： 能顺利运行的系统 完成标志： 修复现存的bug 5 移交 开始时间： 2013-08-01 结束时间： 2013-10-01 所需资源： beta版系统 6 培训 开始时间： 2013-10-01 3.4 预算
1.采购必要设备的投资： 网络平台的建设，包括了建设方式和联网建筑物数等等方面去计算，这一块需要200万左右；
服务器与存储系统，从发卡量和设备数量等估算，这一块需要100万左右； 射频卡终端，包括读写器与POS机，这一块需要20万左右。2.开发系统的投资：
按目前市场上一卡通管理系统的开发价格来看，开发所需的投大概在50万不等； 4.总计：:350万左右； 3.5 关键问题
本系统的操作过程简单，实现技术要求也不高，所以没有要特别列出的关键问题 4.支持条件 4.1 运行环境
a.开发软件运行的最短寿命为一年。b.进行系统方案选择比较的期限：2周。c.经费来源和使用限制：自筹资金。
d.法律和政策方面的限制：本软件公司版权所有，未经作者允许，非法传播、复制，违者追究法律责任，后果自负。
e.硬件CPU p3、内存256M.。f.软件：access2003。
g.运行环境：本软件应使用Windows2003、Windows xp操作系统。h.开发环境：本软件应使用Windows2003、Windows xp开发。4.2 需由用户承担的工作
数据库的初始化需要用户自己录入，这个应该在测试之前完成，所以编码之前，由开发人员做好数据库，然后由用户安排人录入初始数据库，且必须在2013年6月1日之前完成。4.3 需由外单位提供的条件
本项目希望得到委托商的资金支持，人员支持，如取需求时，能够提供部分食堂为我们的测试的提供支持环境，还有技术支持 5.专题计划要点
专题计划 要点
合同计划
在分析阶段拟定合同书，分析阶段一结束就签订合同，合同包括需求的定义，如出现任何问题，可以根据合同调解，以及费用的支付，在每个阶段结束之后，委托方需支付开发方多少现金
测试计划
包括单元测试，集成测试，系统测试计划，主要参照开发文档，拟定计划，具体到输入的格式，响应的时间，需求的确认
五 进度计划风险列表
1.最常见的进度计划风险
1）功能无限蔓延； 2）质量不定 3）计划过于乐观 4）设计欠佳 5）银弹综合症 6）研发导向开发 7）人员薄弱 8）签约商失败；
10）研发人员与客户的磨擦。2.进度计划风险完整列表
2.1 计划编制风险
1）计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；
2）计划是优化的，是“最佳状态”； 3）计划忽略了必要的任务；
4）计划基于使用特定的小组成员，而那个小组成员其实指望不上。5）在限定的时间内无法建成已定规模大小的产品； 6）产品规模比估计的要大一些； 7）工作量大于估算数；
8）进度已经拖延的项目在重新评估时过于优化或忽视项目历史； 9）过度的进度压力造成生产率下降；
10）目标日期提前，但没有相应地调整产品范围或可用资源； 11）一个任务的延迟导致相关任务的连锁反应；
12）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。2.2 组织和管理
1）项目缺乏一个有凝聚力的最高领导人；
2）由于前期乏力，项目长时间被搁置； 3）解雇和削减开支导致项目小组能力下降；
4）仅由管理层或市场人员进行技术决策，导致计划进度延长； 5）低效的项目组结构降低生产率；
6）管理层审查/决策的周期比预期时间长； 7）预算削减打乱项目计划；
8）管理层做出了打击项目组织积极性的决定； 9）非技术的第三方的工作比预期延长（如审批，采购等）； 10）计划性太差，无法适应期望的开发速度；
11）项目计划由于压力而放弃，导致开发混乱、低效；
12）管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。2.3 开发环境
1）设施没有及时到位； 2）设施到位，但不配套； 3）设施拥挤、杂乱或者破损； 4）开发工具未能及时到位；
5）开发工具不如期望那样有效，开发人员需要时间创建工作环境或切换新的工具；
6）开发工具的选择不是基于技术需求，不能提供计划要求的性能； 7）新开发工具的学习期比预期的长，内容繁多。2.4 最终用户
1）最终用户坚持新的需求；
2）最终用户对于最后交付的产品不满意，要求重新设计和重做； 3）最终用户不买进项目产品，无法提供后续支持；
4）最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。
2.5 客户
1）客户坚持新的需求；
2）客户对规划、原型和规格的审核/决策周期比预期长；
3）客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的重复；
4）客户答复的时间比预期长（如回答需求中需澄清的问题）； 5）客户坚持技术决策而导致进度计划延长；
6）客户对开发进度管理过细，导致实际进展变慢；
7）客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作；
8）客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作；
9）客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低；
10）客户不接受交付的软件，尽管它满足了所有的规格； 11）客户期望的开发速度是开发人员无法达到的。2.6 承包商
1）承包商没有按承诺交付组件；
2）承包商递交的组件质量低下无法接收，必须花时间改进质量；
3）承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。
2.7 需求
1）需求已经成为项目基准，但变化还在继续；
2）需求定义欠佳，而进一步的定义会扩展项目范畴； 3）添加额外的需求；
4）产品定义含混的部分比预期需要更多的时间。2.8 产品
1）错误发生率高的模块需要比预期更多的测试、设计和实现工作；
2）校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。
3）在一个或多上新兴领域推广计算机技术使得计划进度的延长不可预 4）由于软件功能的错误，需要重新设计和实现；
5）开发额外不需要的功能（镀金）延长了计划进度；
6）要满足产品规格与速度要求，需比预期更多时间，包括重新设计和实现的时间；
7）严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；
8）要求与其他系统、复杂系统或不受本项目控制的系统相连，导致无法预料的设计、实现和测试工作。
9）要求在不同操作系统下运行将花费比预期更长的时间；
10）在不熟悉或未经检验的软（硬）件环境中运行产生未预料的问题； 11）开发一种对组织全新的模块将比预期花费更长的时间； 12）依赖正在开发中的技术将延长计划进度。2.9 外部环境
1）产品依赖政府规章，而规章的改变将是不可预期的；
2）产品依赖草拟中的技术标准，而最后的标准将是不可预期的。2.10 人员
1）招聘人员所花时间比预期的长；
2）作为先决条件的任务不能按时完成（如培训、其它项目）； 3）开发人员和管理层之间关系不佳导致决策缓慢，影响全局；
4）项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平；
5）缺乏激励措施，士气低下，降低了生产能力； 6）缺乏必要的规范，增加了工作失误与重复工作；
7）某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言；
8）项目结束前，合同制人员离开团队，或雇员辞职；
9）项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；
10）项目组成员不能有效地一起工作；
11）由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作；
12）有问题的成员没有调离项目组，损害了项目组其他成员的积极性； 13）项目的最佳人选未加入项目组；
14）项目的最佳人选已加入项目组，但因其他原因未能合理使用； 15）没有找到项目急需的具有特定技能的人； 16）关键人物只能兼职参与； 17）项目人员不足；
18）任务的分配与人员技能不匹配； 19）人员工作的进展比预期的慢；
20）项目管理人员怠工导致计划和进度失效；
21）技术人员怠工导致工作遗漏或质量低下，工作需要重做。2.11 设计与实现
1）设计过于简单，无法确定主要事件，并导致重新设计和实现； 2）设计过于复杂，导致一些不必要的工作，影响实现效率； 3）设计质量低下，导致重复设计和实现
4）使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误；
5）产品采用低级语言来实施，导致生产率比预期的低；
6）一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新库或自选开发所要的功能；
7）代码和库质量低下，导致需要额外的测试、错误修正或重做； 8）过高估计了增强型工具对计划进度的节省量；
9）分别开发的模块无法有效集成，需要重新设计或重做。2.12 过程
1）大量的纸面工作导致进程比预期的慢；
2）进程跟踪不准确，导致无法预知项目是否已落后于计划进度； 3）前期的质量保证行为不真实，导致后期的重复工作；
4）质量跟踪不准确，导致无法得知影响进度的质量问题； 5）太不正规，导致沟通不足，质量问题和工作重做； 6）过于正规，导致过多耗时无用的工作；
7）向管理层撰写进度报告占用的开发人员的时间比预期的多； 8）风险管理粗心，导致没有发现重大的项目风险； 9）软件项目风险管理花费的时间比预期的多。
第二篇：软件项目管理实习报告
实习总结
从二零一二年七月九日开始到二零一二年七月二十日止，我们哈尔滨师范大学计算机系软件项目管理专业全体同学去北京海辉集团雅思晟实训中心开始我们的实习生活。
实习是每一个大学毕业生必须拥有的一段经历，它使我们在实践中了解社会、在实践中巩固知识。通过此次实习，我们将学校所学的会软件知识与实际相结合起来，不仅让我对整个软件应用方面有了详细而具体的认识，熟悉了软件的具体工作对象，也缩短了抽象的课本知识与实际工作的距离。
在实习中，我在公司指导老师的热心指导下，我积极参加小组讨论，和组员们配合完成了我们小组的项目。简短的实习生活，既紧张，又新奇，收获也很多。通过实习，使我对java有了深层次的感性和理性的认识。
“纸上得来终觉浅，绝知此事要躬行。”在短暂的实习过程中，我深深的感觉到自己所学知识的肤浅和在实际运用中的专业知识的匮乏，刚开始的一段时间里，对一些工作感到无从下手，茫然不知所措，这让我感到非常的难过。在学校总以为自己学的不错，一旦接触到实际才发现自己知道的是多么少，这时才真正领悟到“学无止境”的含义。通过实训中心老师的课堂讲解与企业化标准的培训，使我加深了对自己专业的认识。从而确定自己以后的努力方向。要想在短暂的实训时间内，尽可能多的学到东西，就需要我们跟老师或同学进行很好的沟通，加深彼此的了解。只有我们跟老师多沟通，让老师更了解我们，才能跟真切的对我们进行培训工作。由此，班级的文化“共享”就在生活中慢慢形成了。让我们知道了团队的力量。老师在实习周中所讲的，都是课本上没有而对我们又非常实用的东西，这又给我们的实训增加了浓墨淡采的光辉。我懂得了实际生活中，专业知识是怎样应用与实践的。在这些过程中，我不仅知道了职业生涯所需具备的专业知识，而且让我深深体会到一个团队中各成员合作的重要性，要善于团队合作，善于利用别人的智慧，这才是大智慧。靠单一的力量是很难完成一个大项目的，在进行团队合作的时候，还要耐心听取每个成员的意见，使我们的组合达到更加完美。
这次实训带给我太多的感触，它让我知道工作上的辛苦，事业途中的艰辛。让我知道了实际的工作并不像在学校学习那样轻松。软件行业的工作人员工作不是一个人的事情，而是一个团队的事情。软件开发中有许多的问题如。
需求分析不充分.如果需求分析不清晰、不完整、太笼统或者不具有可测试性，那么软件一定会出现问题。这就要求我们在动手开发之前一定要有完整的、详细的、可维护的、可测试的需求分析，而且该需求分析一定要得到各方的认可。不切实际的计划没有充分考虑问题的复杂性，把一个庞大的工程限定在非常短的时间之内，出现问题是不可避免的。因此，我们应该拿出足够多的时间作计划、设计、测试、修改错误、回归测试、整理文档，不要把长时间熬夜作为软件公司的家常便饭。不充分的测试在系统崩溃和用户强烈抱怨之前，没有人知道软件是不是存在问题。因此要尽早地开展测试，问题修改之后要尽快地进行回归测试，一定要给测试和修改问题留出足够的时间。不断增加新的特性在软件开发完成之后，不断有新的需求，这是最常见的问题。因此一定要最大限度地坚持最初的需求分析，如果万不得已，确实需要增加新的需求，那么一定要更改相关的计划。如果可能在设计阶段最好使用快速原型法，让用户知道他们希望的系统是个什么样子的，这样可以在初期更好地听从用户的意见。交流不充分如果开发人员与开发人员之间、开发人员与项目管理组之间、项目组和用户之间不能充分地交流的话，也会出现问题。因此，使用新闻组、电子邮件以及其他的网络化的错误跟踪工具等等方式来加强整个团队的沟通和交流是必要的。
人非生而知之，虽然我现在的知识结构还很差，但是我知道要学的知识，一靠努力学习，二靠潜心实践。没有实践，学习就是无源之水，无本之木。为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。
这次实训让我在一瞬间长大：我们不可能永远呆在象牙塔中，过着一种无忧无虑的生活，我们总是要走上社会的，而社会，就是要靠我们这些年轻的一代来推动。这就是我们不远千里来实训的心得和感受，而不久后的我，面临是就业压力，还是继续深造，我想我都应该好好经营自己的时间，充实、完善自我，不要让自己的人生留下任何空白！
实训中除了学到不少专业知识，也了解一些社会的现实性，包括人际交往，沟通方式及相关礼节方面的内容，对于团队开发来说，团结一致使我深有体会。团队的合作注重沟通和信任，不能不屑于做小事，永远都要保持亲和诚信，把专业理论运用到具体实践中，不仅加深我对理论的掌握和运用，还让我拥有了一次又一次难忘的开发经理，这是也是实训最大的收获。现在我对“一个人最大的财富是他的人生经历和关系网络”这句话非常的有感情，因为它确实帮了我们不少。除此课本上的知识毕竟有限。通过实训，我班同学都有这样一个感觉，课本上的理论知识与实际工作有很大差距，只有知识是远远不够的，专业技能急需提高。从最初的笨手笨脚，到现在可以较熟练的按照流程开发软件，这都与我班每个人的努力是分不开的。十几天的实训，教会了我们很多东西，同时也锻炼了大家踏实、稳重的能力，每个人都很珍惜这来之不易的实训机会。
在实际工作中经常会和不同的人打交道，然而他们的态度是不可恭维的，你会感觉到他的不耐烦以及他的高傲，所以这就需要学会沟通的方式及说话技巧，学会灵活面对。通过这十天的实训，我班同学都收获颇丰，总体来说对这次实训还是很满意的。尽管实训很累，每天早出晚归。但真的很感谢学校能够提供我们这样好的实训机会，以及北京海辉集团雅思晟实训中心给予我们的实训平台。我们深刻的了解到，只有经历过，才知道其中的滋味。对于我而言，喜欢体验生活，可以说通过这次实训，真真切切的让我了解了什么是软件开发，什么是软件工程，让我对于软件最初的观点也有了本质性的改变！程序员不仅仅是一份职业，更是一份细心+一份耐心+一份责任心=人生价值的诠释。即将走向工作岗位的我们更要不断加强自己的专业技能，社会不会要一个一无是处的人，所以我们要更多更快的从一个学校人向社会人转变。为此我们将会在以后的日子里继续努力，不断激励经验，不断磨砺自己，早日走向工作岗位。
时间过的好快啊，为十二天的实训生活即将结束了，短短的十二天让我们收获很大，专业知识、编程水平都有很大的提高。刚开始四天的高强度的课程安排让我们受益匪浅；接下来的上机实训又让我们可以巩固了课程。这让我觉得实习生活充实而有意义。辅导老师配好了环境之后，我们开始了项目的制作，这次项目实训算是自己小组间主要完成的项目。最后，自己的努力还是有收获的，看着电脑上记录得满满的代码，看着自己的项目最终能够运行成功，就觉得好神奇，很有成就感。
在本次的实训中，除了让我明白工作中需要能力，素质，知识之外，更重要的是学会了如何去完成一个任务，懂得了享受工作。当遇到问题，冷静，想办法一点一点的排除障碍，到最后获取成功，一种自信心由然而生，这就是工作的乐趣。有时候也需要虚心请教，从别人的身上真得能学习到不自己没有的东西，每一次的挫折只能使我更接近成功。除此以外，我还学会了如何更好地与别人沟通，如何更好地去陈述自己的观点，如何说服别人认同自己的观点。这次所学知识与实际的应用，理论与实际的相结合，让我大开眼界。也是对以前所学知识的一个初审吧！这次实习对于我以后学习、找工作也真是受益菲浅，在短短的十多天中让
我初步从理性回到感性的重新认识，也让我初步的认识这个社会，对于以后做人所应把握的方向也有所启发！相信这些宝贵的经验会成为我今后成功的重要的基石。
在这次实训中，我们以小组为单位开发项目。我们小组的项目是Super VCD一款简单的音乐软件。到目前为止，已经有很多种音乐软件，大部分都是以复杂功能为主，实现复杂音乐的管理，但是有些用户不需要那些功能繁琐的软件，只是需要一款能够满足用户简单的需求的音乐软件。
我们所要做的是一款简单的SuperVCD音乐软件，能够满足用户简单的管理音乐需求，操作简单。主要实现一些简单音乐的管理。
根据了解，一些用户对音乐软件只有一些简单的需求，主要有几个方面，首先是对文件的管理，第二，是对专辑的详细查询。SuperVCD的实体有music.db,images文件，服务器，客户端，用户界面。服务器和music.db之间为一对一的关系，服务器可从music.db文件获取音乐信息。images文件和服务器为多对一的关系，服务器可从images文件获取图片。服务器和客户端是一对多的关系，一个服务器可开启多个客户端客户端和用户界面是一对一的关系，一个客户端开启一个用户界面（不重复）。
我们按照老师的讲解，分配了小组。在小组中我们选了组长。组长按照我们各自所擅长的分配了我们组员的任务，设置了一个虚拟货币，按照奖惩机制进行分发货币。在进行工作时我们相互配合，帮助。终于在我们努力和老师的指导下我们完成了老师布置的项目。老师为我们讲解了软件架构设计要达到的目标。
软件架构设计要达到如下的目标：
可行性（Feasible）。架构具有可行性是架构设计的基石。
可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。
可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。可升级性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。
客户体验（Customer Experience）。软件系统必须易于使用。软件的最终用户很可能是不具有计算机专业技术的人员。
本部分设计主要涉及软件系统的动态建模和系统类图的详细设计。软件系统的动态模型分为交互模型和活动状态模型，其中的交互模型主要由顺序图和协作图构成，活动状态模型主要包括活动图和状态图。通过为软件系统项目建立动态模型，从而产生体现系统动态行为的可视化分析结果，包括对象的时间特征和对象为完成目标任务而相互进行通信的机制、对象行为的改变和状态变化情况，以及对象可能出现的各种活动状态等信息。
“千里之行，始于足下”，这十几天短暂而又充实的实习中，我认为对我走向社会起到了一个桥梁的作用，过渡的作用，是人生的一段重要的经历，也是一个重要步骤，对将来走上工作岗位也有着很大帮助。向他人虚心求教，遵守组织纪律和单位规章制度，与人文明交往等一些做人处世的基本原则都要在实际生活中认真的贯彻，好的习惯也要在实际生活中不断培养。
这次实习也让我深刻了解到，在工作中和同事保持良好的关系是很重要的。做事首先要学做
人，要明白做人的道理，如何与人相处是现代社会的做人的一个最基本的问题。对于自己这样一个即将步入社会的人来说，需要学习的东西很多，他们就是最好的老师，正所谓“三人行，必有我师”，我们可以向他们学习很多知识、道理。
通过实习能够加强和巩固理论知识，能够在实践中培养自己发现问题并运用所学知识分析问题和解决问题的能力，从而使我们在学校所学的知识能够应用到实践当中去。锻炼自己的实习工作能力，适应社会能力和自我管理的能力，提前感受工作的感觉，为以后的就业打下一定的基础。了解计算机软件技术在应用情况、需求情况和发展方向及前景。在实习单位学到一些自己在学校难以学到的知识，为毕业设计的顺利完成添砖加瓦。
回顾我的实习生活，感触是很深的，收获是丰硕的。通过实习，不仅培养了我的实际动手能力，也增加了我的实际操作经验，对软件项目管理专业所对应的工作也有了新的认识。实习让我学到了很多在课堂上学不到的知识，也让我更加看清自己的不足之处。通过这次实习，使我对今后的学习、发展方向有了更进一步的认识：学习不仅仅学的是理论知识，更重要的是学习如何将理论知识应用于实践，学习将工作做到尽善尽美。
第三篇：软件项目管理
软件项目经理所需的素质
许多人都以为项目经理总是与“理想与光荣”相伴的，其实作为一个有志于改进中国软件开发流程的项目经理来说，他们承担的更多的是“艰辛与痛苦”。
一个优秀的软件项目经理应该具备以下素质。
一、执着
可以这么说，在中国如果不执着是做不成任何事情的，因为在软件开发流程中推行各种规范和管理制度的时候，你可能遇到各种各样的阻力和障碍，如果没有应付挫折的思想和准备，你是很难推行成功的。要知道这样一个基本事实，项目管理成败的关键是：如果你不坚持，谁也不会坚持下去的。指望领导的扶持和群众的自觉是不可能的。只有坚定信念，努力打动别人，才能成功。
坚持到成功为止。只要决定上管理流程了，就不要后悔，唯有坚持，因为你拼命努力而实现了99%，你却不知，最后当你决定放弃的时候也许就是你要成功之时。要知道你准备放弃的时候可能正是对方也准备放弃之时，唯有坚持，你才能成功
二、亲和力
亲和力是指你和团队相互依赖，相互信任能力的大小。亲和力是你领导团队走向成功的基础，如果一个团队的向心力不够，各自为政，那么失败就会在身边陪伴你。要团队的每个成员都信任你，你必须要做到关心下属，主动与下属沟通，为下属争取合法权利等。关心下属就是在日常工作中对下属的工作状况，发展方向进行指导，避免其走弯路；在生活中也对其身体状况进行关心，促进身体和心理健康的恢复。
多找下属沟通是消除误会的润滑剂，同时也是了解下属内心真实想法唯一捷径。做项目经理的人，在某些事情上的处理的确会与人不同，也难以令人理解。这个时候只有多与下属沟通，逐步达成共识，争取大家的理解和支持。记住，没有下属的理解和支持，你永远无法实现项目管理的规范化。另外就是了解下属的真实想法，经常了解一下下属的真实想法有利于我们不断改进和调整流程，使生产流程更加符合本团队的实际。切记一点，做领导的一定要多尊重下属的想法，并且与之沟通，若一味等下属找自己，那么是一般下属与之水火不容要摊牌时，才会与你沟通，这样悔之晚矣。
为下属争取合法权利是项目经理的一项重要职责。敢负责任是项目经理基本素质，如果你不经常研究工作数据保障下属的合法权益时，你就很难让你的团队保持高效率。
三、品德高尚
“一撇一捺是个人，世世代代学做人。”在这个世界上最难做的就是做个品德高尚的人。试想一个思想猥亵的人很难取得成功，即使靠钻营取得也只是暂时的，他不可能取得长久的成功。只有品德高尚的人才能感染周围的人，使团队具有向心力，从成功走向成功。
人有三种，一种是仗势欺人，一种是持才压人，最后一种是以德服人。仗势欺人的人自持地位高而指三道四，自然是不可能团结人，更不可能获得成功；持才压人的人自持学识高而盛气凌人，或咄咄逼人。殊不知“闻到有先后，术业有专攻”，“尺有所长，寸有所短”，难以学到更高的知识，也就难以取得更大的成功。只有以德服人的人以自己的修养和品德感染人，勇于吃亏，乐于助人，以德报怨，只有这样才能使你对立面德人都不忍心伤害你，团结到一切可以团结到的人，拥有这样的环境，你怎么可能不成功。
勇于吃亏，首先要放下私心，如果一个人始终 围着自己转的人是不可能做到的。“人不为己，天诛地灭”是八十年代后出生的人心灵普遍反应；但是要记住人首先是社会中的人，如果脱离了社会，人恐怕已不会成其为人了。因此只有当你抛弃私心，主动为人，别人才会反过来支持你，帮助你。
乐于助人，是人类的一个良好品质，就象一首歌中所唱的“人字的结构就是相互支撑”。管理流程是不可能靠项目经理一个人维持的，必须要大家支持你。但是这却需要你多帮助别人，别人才会帮助你。不管团队成员发生什么事情，你要尽你所能去帮助他，这样团队才可能继续前进。
以德报怨，可能是人最难做到的。中国人就强调“人若犯我，我必犯人”，其实在这回中不会有真正的仇敌，大家明争暗斗的结果如果过20年后再去看的时候，保准一大半的人都会觉得不值得，许多人赌得就是一口气，将自己成功的希望给湮灭了。当你能用宽容喝善良对待你对立面的人的时候，还有什么东西能阻挡你成功？
“得道多助，失道寡助；多助之至，天下顺之，失道之至，亲戚叛之；以天下之所顺，攻亲戚之所叛；故君子有不战，战必胜矣。”
四、口才
良好的口才是项目经理打动项目成员的必备武器，当你拥有良好的口才将会使你无往不利。当年希特勒就是用他那天才般的口才征服了德国，使他的《我的奋斗》贯彻到每一个德国人的心中，从而成立了第三帝国。
要使自己的项目管理思想贯彻到每一个项目成员心中，就必须要做到以下的演讲原则：
1.根据项目成员的共同目标象他们制定演讲内容，只有让他们信服你才有意义；
2.调动听众的这种感官，诉之触觉、视觉、听觉，用黑板、姿势来辅助你的内容。
3.不断的总结效果，改进自己演讲宣传的接受度，如果效果不理想，尝试换一个方式来表达.调动听众的这种感官，诉之触觉、视觉、听觉，用黑板、姿势来辅助你的内容。
3.不断的总结效果，改进自己演讲宣传的接受度，如果效果不理想，尝试换一个方式来表达和描述。
4.让听众学以至用，只有他们积极反馈，才能更深入的听你的思想。
五、循序渐进
循序渐进，不急于求成是项目经理在项目管理中必需具备的品质，在中国CMM过程改进的热潮中，真正实现CMM管理的企业屈指可数，而以CMM改进过程实质性为企业带来质量提升和效益改进的公司更是寥落晨星。
为什么会出现这种情况？难道CMM真的不适应中国过情吗？不是，绝对不是。是这些企业的项目经理太心急，连CMM2还不知道怎么回事就直奔CMM3，他们忽视了事务发展的客观规律，凡事必须循序渐进。如果有一个企业在2年内通过了CMM4，我有十足的信心说，那是花钱买征；如果乐观一点，一个中小企业从CMM1走到CMM2大约要2年时间，大型企业只会更长，不会更短，因为他们需要在培训和沟通上付出更大的代价。
“循序渐进，循序渐进，再循序渐进。”这句巴斯德德经典名言同样适用于我们项目管理领域，他将逐步把我们带向成功。
六、持久求学
“书到用时方恨少，学至成时始知卑。”学无止境，我在生产实践中发现，整个项目管理过程改进就是“学习-培训-实施-发现问题-再学习”的循环过程，项目经理如果不学习将不能解决现实工作中出现的新问题，更不可能站在一个战略的角度来解决问题。
事实上，求学也不能没有目标，否则学到的知识太庞杂，而不能融会贯通，这样的知识对实际工作指导甚少，真正的知识是一个目标体系，严格按照流程来一步步的掌握我们所需要的知识。
最后，我总结一下中国项目经理所必需掌握的知识：
1.专业知识：数据结构、关系数据库、操作系统、软件工程、编译原理。（外国的项目经理可能不需要掌握）
2.管理知识：项目计划、项目配置管理、成本核算、风险预估、绩效考核。这是项目经理必须掌握的内容。
3.网络知识：服务器的架构、各种服务的配置。因为管理的大厦是基于软件的管理，没有一个服务管理的网络配合是不可以想象的。
4.“越过高峰，另一峰却又现”，这是中国项目经理在持续求学中会不停的挑战自我，向更高的山峰迈进。
七、敢负责任
一个人因为有责任才有生存的意义。一个人随着年龄的增长，责任感也会愈来愈重。成年时，法律也会赋予一些年少时没有的责任。同时地位逐渐提高，责任也会相对加重。
一个人惟有负责，才能产生做人的价值。所负责任愈大，价值就愈高。换句话说，有责任，生命才有意义。如果没有感受到自己该负的责任，即使年龄超过20岁，也不算是一个成年人。
因此，经理就是要负责任，如果不负责任就可以不要经理了！项目经理关系到一个项目的成败；对于公司他必须要承担及时汇报项目进度、成本核算和质量系数的责任，同时也必须保证项目组成员绩效考核，政策落实，预留人才储备等责任，是整个项目中责任最大的人，如果没有良好的心理素质和应对能力是无法担负责任的。
实际工作中项目经理主要要负责项目组的人员安排调度、工作分配、工作审核、工作跟踪、项目计划、项目汇报总结、成本核算、利润分配等职责。
八、以身作则
项目管理的一个重要工作就是定义各种规范和制定，但是这些规范和制度的执行除了靠项目经理的执着推行，口才宣传，力主培训、惩戒得当之外，关键还是在于项目经理的以身作则。如果项目经理自己都违反自己定义的条款的话，那么就别指望团队会自觉遵守这些规定。
作为一个管理者以身作则是最基本的素质，千万不要为自己违反规范和制度找各种借口，例如我我是公司只属考核，我因为某某更重要的事情而不得不违反。“只许周宫放火，不许百姓点灯”的话，是无法将规范和制度推入人心的。项目经理如果违反了规范，只有当众加重处罚，别无他法。
因此，鉴于规范制度的权威性主要还是靠项目经理自己，只有坚持以身作则，才能将自己优秀的管理思想贯穿下去，取得开发过程改进的成功。
九、要有威信
一个项目经理说话有没有人听，必须要靠威信，这种威信是靠自身的素质，而不是狐假虎威。靠高层领导的支持来强迫团队执行项目制度过程的话，是注定会失败的。因为团队成员不信任你，表面服从，实际消极怠工，就足以让流程实质瘫痪。
做事要有信用，说一不二，不能因为朋友关心就讲情面。公是公，私是私。平时可以稀稀拉拉，关键问题决不手软，不因为朋友关系妥协，这样才能树立威信，便于工作。
威信除了必要的威信之外，最主要的还是信用，项目经理在做事没有绝对把握的时候千万不要承诺，一旦承诺就无论如何一定要实现。否则，当实现不成功而丢失信用之后，再想让团队相信你，信任你就是非常困难的事情了。
十、善于总结
项目经理要善于总结，只有不断的总结才能不停的完善自己，成功的事情总结经验，失败的事情要总结教训，总结的过程就是不断改进的过程，这也是CMM规范所必需的素质。
总结
总结的过程要多吸取别人的意见，不要武断自己的结论。博人所长，综合起来才算趋于完美。这个原因有二：其一，项目经理不是孤立的一个人，而是必须融于团队之中，一个流程合不合理，不是由项目经理说了算，而是要由团队的成员说了算，注意倾听团队成员的真实感受，不断改进流程才能成功。中国的许多CMM改进失败，并不是项目经理知识能力不够，而是他们没有一起与团队总结，经多年经验，我们发现大多数规范，必须要有一套合理的软件支持才能成功，否则无论你的理想多先进，想靠程序员工作来提高过程质量的改进是不现实的。其二，“闻道有先后，术业有专攻”，项目经理不可能是全才，什么都懂。因此要和哪些与专攻方向不同的人一起总结。比如项目经理可能精通软件开发流程的改进，但是却不知道测试流程、网络管理流程、品质保证流程的改进，而这些流程又直接作用于软件开发流程。这个时候必须与测试人员、网管人员、质量保证人员共同探讨，找出一条切实可行的改进方案。
第四篇：软件项目管理案例分析20题
软件项目管理案例分析
案例分析一
问题1：
本项目申请国家技术创新基金100万元，但国家实际批准基金额度很可能会低于100万元，“项目投资来源”中应当说明：当国家实际批准基金低于申请额度时，如何补足二者之间的差额以及由此所引起的地方匹配基金的差额。
应重新召开股东大会并讨论以下议题：当国家实际批准基金低于申请额度时，公司是否愿意补足二者之间的差额以及由此引起的地方匹配基金的差额。
如果能够通过，应在“项目投资来源”中加注：当国家实际批准基金低于申请额度时，公司承诺补足二者之间的差额以及由此引起的地方匹配基金的差额（附新的公司股东大会决议）。问题2：
A，B双方以B方现有技术成果为基础进一步合作开发，应明确以下几个主要问题：（1）B方是以现有技术成果折价入股，还是将现有技术成果转让给A方；（2）如果是“技术转让”，应明确是“专利权转让”、“专利实施许可”、还是“技术秘密转让”？
（3）双方是否已就合作开发的新技术成果的所有权、使用权以及利益分成问题达成一致意见？
双方是否已正式签订“合作开发合同”或“技术转让合同”？ 问题3：
应主要从以下几方面分析项目技术的成熟性：
（1）关键技术成熟性分析（包括采用的现有成熟关键技术、已攻克的关键技术、待研究的关键技术等）；
（2）项目采用的关键技术是否获得国家、部门或地方科技计划的支持（已获得、尚未获得）及计划的名称、获得支持的时间；
（3）项目采用的关键技术是否通过技术鉴定（已鉴定、尚未鉴定）及鉴定单位、鉴定意见、鉴定时间。
案例分析二
问题1：
由项目执行偏差导致项目计划变更的各种诱发因素称为项目变更的内部因素。由项目目标变化导致项目计划变更的各种诱发因素称为项目变更的外部因素。问题2：
“B方首付资金未能按时交付”、“A方盲目确定进度目标”、“A方的前期设计有疏漏”、“A方编制的需求分析说明书未能准确、全面地表达B方的实际需求”、“B方自行负责的机房装修误期”、“A方开发人员跳槽”，属于项目变更的内部因素。
“证监会要求上市公司执行新的会计制度”、“B方因机构重组改变了业务流程”、“B方提出增加合同审计功能”、“B方行业主管部门发布了新的行业ERP实施规范”，属于变更的外部因素。问题3：
“A方盲目确定进度目标”、“A方的前期设计有疏漏”、“A方开发人员跳槽”，属于A方责任。由此而增加的项目经费，由A方承担。“需求分析时，B方表达不清，A方理解有误，双方沟通不够，A方编制的需求分析说明了书未能准确、全面地表达B方的实际需求，而B方未能及时指正”，属于双方责任，由此而增加的项目经费，由A、B双方协商分摊。
其余各条，无论B方是否负有责任，均应承担由此而增加的项目经费。问题4：
对于由内部因素引起的变更请求，变更评估的重点是确定最优变更方案。而对于外部因素引起的变更请求，变更控制委员会应重点评估变更的必要性。
案例分析三
问题1：
（1）没有清晰地了解到产品的范围，导致项目后期需求的蔓延；
（2）没有澄清模糊的项目范围，在安装服务器的问题上产生异议，最终增加了未计划到的工作；
（3）没有进行变更控制，以至于变更的结果不理想，导致反复地变更。问题2：
（1）变更工作没有得到确认，导致工作的结果不能够被认可；
（2）变更没有得到有效地执行。尤其当同时发生多个变更的时候，如果没有有效的控制很容易造成一些变更被忽略甚至遗漏；
（3）未控制的变更造成系统的混乱。软件系统是一个复杂的系统，系统间很多部件都存在关联，对其中某一部分进行更改可能会牵连到其他部分，造成整个系统的问题。
问题3：
范围控制是范围管理中重要的工作之一，范围控制的主要目的是控制变更的结果；保证所有被请求的变更都可以得到有效的处理；协调所有同变更相关的工作、资源和交付成果，让项目始终处在被控制的状态。范围控制的意义也在于此，通过范围控制，可以减少范围变更对项目造成的影响，降低风险，让项目处在可控制可跟踪的状态。
案例分析四
问题1：
分解项目WBS的一般过程如下：（1）识别可交付成果及有关工作；（2）确定工作分解结构的结构与编排；
（3）将工作分解结构的上层分解到下层的组成部分；（4）为工作分解结构组成部分提出并分配标识编码；（5）核实工作分解的程度是否必要且足够。问题2：
创建项目WBS时需要注意以下四点：（1）分解出的工作是充分且必要的；
（2）工作的独立性。即工作一旦开始，就可以在不中断的条件下完成；
（3）工作完成度的可判断性。即可以清楚地判断工作是否已经开始，工作完成了多少，以及工作是否已完成。
（4）工作的交付成果。即工作完成后将得到什么样的成果。问题3：
（1）在“同K企业负责人沟通后明确项目的范围”中，小张进行了范围定义的工作。之后小张又编写《关于***系统第三方系统测评计划备忘录》的文档，并发给企业K 负责人确认，让项目范围在各干系人中得到一致的认识。
（2）在“将配合第三方机构进行测评的工作加入到项目WBS”中，小张进行了范围控制的工作。
案例分析五 案例分析六
案例分析七
问题1：
公司负责人不应该把单纯的参数模型放在成本估计上，而要根据不同的情况，采用不同的方法，否则会使成本估计产生很大的偏差。
在做成本估计时建立参数模型只是其中一种方法。建立参数模型指在数学模型中运用项目特点（参数）来预测项目成本。建立参数模型的首要条件是建模所参考的历史数据的精确性程度。
但是实际情况是该项目由于需要改动的那个过程中有很多工作不是很清晰，而且这过程还会对其他5个过程产生一些影响，影响的程度也没有得到明确的界定。更重要的是，改动的流程过程占整个制造成本的36%,因此完全按照参数模型是不合适的。问题2：
由于王工程师能够准确地获得其他5个没有改动过程的详细成本信息，因此工程师在对已经明了的项目的5个过程应该采用建立参数模型法来对其进行成本估计。
而对那个需要改动的过程应该采用类比估算法，这是由于当对项目的详细情况了解甚少时（例如在项目的初期阶段），往往采用这种方法估算项目的总成本。问题3：
成本控制就是要保证各项工作要在它们各自的预算范围内进行。成本控制的基本方法是规定各部门定期上报其成本报告，再由控制部门对其进行成本审核，以保证各种支出的合法性，然后再将已经发生的成本与预算相比较，分析其是否超支，并采取相应的措施加以弥补。有效的成本控制的关键是经常及时分析成本绩效，尽早发现成本偏差和成本执行效率，这样就能在情况变坏之前及时有效地采取措施。
成本控制包括查找正、负偏差的原因，它必须与其他控制过程紧密地结合起来。成本控制实质上就是监控成本的正负偏差，分析偏差产生的原因，及时采取措施以确保项目朝着有利的方向发展。主要方法有成本变更控制系统、绩效衡量分析、项目绩效审核、电脑化工具、偏差管理等。
案例分析八
案例分析九
问题1：
不明确需求就进行开发，造成项目开发无法制定相应的计划。缺乏合理的项目开发计划，就无法保证项目的质量。
如果由于某种客观原因造成无法在软件项目开发之前明确这个需求，需要对这个软件项目进行阶段划分，在每个阶段中明确部分需求，并制定相应的开发计划。问题2：
该公司的张工应该尽可能早地明确整个软件项目的需求，制定相应的计划。
张工可以把整个项目的开发阶段进行划分，对每个阶段的需求进行分析，制定计划，执行计划。
B银行的赵工应该尽可能早地提出需求。
赵工在需求确定后如果需要变更请求，则要和张工一起协商，然后才能调整需求，并且对项目开发计划也进行相应的调整。赵工应该和张工一起分析，明确每个项目开发阶段的需求。问题3：
在项目的需求分析阶段，项目负责人和需求提出者需要仔细研究整个项目的相关业务逻辑，了解整个项目的需求。在需求得到明确的前提下，制定相应的开发计划。
在项目的实施阶段，需要对每个阶段的需求进行明确，制定相应的开发计划。保证了每一个阶段的开发质量，就能够保证整个项目的质量。
案例分析十
问题1：
该软件公司在明知原有系系统统已经投入使用的情况下，没有提前分析升级的风险并告知客户，此证券公司没有制定升级计划，没有和客户一起制定风险预案。
该证券公司在得知此软件公司要对他们正在使用的系统进行升级的情况下，没有主动向该软件公司了解升级可能引发的问题，没有制定必要的风险预案，以致出现问题时无法采取合理的补救措施，造成了一些损失。问题2：
现有系统由于一般已经投入使用，如果对其进行升级会有一定的风险。在进行升级以前，应该对其可能包含的风险和可能带来的问题进行仔细分析和评估，并有针对性地制定风险预案和升级计划。在升级失败或者出现问题影响系统使用的情况下，应该实施风险预案来保证系统的正常使用，尽可能地减少损失。问题3：
软件系统的升级和开发一样，也要制定相应的开发计划和质量保证计划。如果缺少必要的计划和质量保证措施，也会导致很大的问题。软件系统升级如果出现质量问题，带来的损失可能比开发过程中出现问题更严重。因为如果一个正在使用的系统出现问题或无法正常使用，可能带来一定的经济损失。因此我们必须像软件开发一样采取必要的质量保证手段来避免或尽可能地减少经济损失。针对升级可能出现的风险，为了保险起见，需要制定一套或多套见险预案，并且进行预演，一般在出现问题时顺利采取风险预案来尽可能减少或避免产生经济损失。
案例分析十一
问题1：
由于人力资源计划不合理或者客户在开发过程中的一些突发原因造成人力资源计划不足以应付项目的正常进行，项目管理人员则需要考虑增加人力资源。在组织内部因为人员紧张已经不能提供合适的开发人员，同时公司管理层不打算增加人员经费，项目组经过研究决定招聘一批实习生，这算是一个比较正常的解决问题的思路，但是由于是组织外的人员，所以会增加管理难度。同时由于在项目中期引入新的开发人员，也引入了新的风险：新的开发人员可能不能及时完成作为先决条件的任务（如培训及其他项目）；新的开发人员和项目管理层之间关系不佳，导致决策缓慢，影响全局；由于在工资待遇方面和正式员工有较大差距，且缺乏激励措施，士气低下，降低了生产率；新的开发人员中某些人员需要更多的时间适应还不熟悉的软件工具和环境；因为是在项目中后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；也许在所有新开发人员中没有找到项目急需的具有特定技能的人，等等。以上这些因素都可能对项目进度造成很坏的影响，有较大的隐患，项目管理人员必须有效控制由此带来的人员风险。问题2：
关于如何教育和引导刚加入公司的新雇员这个问题，随着公司产品的多样性和复杂性变得越来越棘手，而且新加入公司人员可能分别从事不同的工作，如程序员，程序经理，客户支持工程师，针对不同的角色应该制定不同的方案。
越来越多的公司都试图聘用能自学业务的人员，而不愿在培训项目、正规条例和流程或详细的产品记录上的投资。还可以通过熟练员工来教育新新雇员，这些熟练员工有经长、某些领域的专家以及正式指定的指导教师，他们除了本职工作外还要担负起教导新雇员的工作。这种方法使得大家觉得有权学习并自己决定学什么和不学什么，使得他们在公司里的作用灵活机动。例如对于程序经理的培训：刚开始时，新雇员的任务可能是一个单独的特性，并且在直到完成为止的这段时间内，都会有人对你进行密切地指导。随后，当这种工作已做得相当熟练之后，便会在更大的特性组中从事类似的工作，但指导会少得多。一段时期后，受训者会拥有一个小项目或一个大项目的一部分。同时，程序经理还可以受到一些正规的培训，包括一个供选修的培训项目。另外，还可以不定期举行经验推介会，届时会有经验丰富的程序经理介绍他们自已的经验。假设你是一个新进入公司的开发员，那么在头几天里，你会与经理们以及来自其他专业部门的高级人员会面，你会听到有关开发周期的一个方向性的简介，然后开发经理会立即派给你一个单独的任务或者让你与特性小组一起工作，你还可能被介绍给愿意当指导教师的高级开发员。
一般而言，你开始会从事相对容易的特性编码工作，这种工作需要的时间较少并且与其它特性关联甚少，并且高级人员（特性组长、领域专家、指导教师）随即非常仔细地检查你编写的代码。此外对开发领域人员应该有更加正规的定向的培训。例如，为新开发人员提供了几个为时几天的实习班，培训他们处理开发过程、产品、工具和其它专题。此外对于客户支持工程师的培训也是十分重要的。这主要是因为顾客不仅仅是购买产品，他们还要享受到优质的售后服务。所以，训练有素的客户支持工程师对于保持公司良好形象和提高为顾客服务的能力是至关重要的。客户支持工程师不必像开发员那样有必备的职业教育，但他们必须关于本公司产品如何工作的知识，并且实际上要在某种产品上具有专业知识。新的客户支持工程师在上岗之前，接受一段时间的专门培训。培训从基本的软件产品开始，同时他们还接受交际技巧，包括如何与顾客打交道等方面的一般性训练。作为定向培训的一部分，他们还接电话，与导师一道工作（每位技术员有一位导师）。在他们被分配处理客户的电话之前负责答复客户来信。问题3：
对日软件外包相对技术难度不高，但是质量要求相当苛刻，外包项目失败的例子不少。以下就对日软件外包常见的一些问题进行简单探讨。（1）日方SE认为理所当然的地方，很多细节不会在式样书中明确写出，或者说日方SE完全按照日本做设计的习惯写式样书，由于中日文化和思维习惯的差异，可能导致中国软件开发人员对这些习惯问题理解有误。
对策：积累经验，参照同类系统，提QA表确认。
（2）在产品提交期间，对于某些BUG，可能会出现这样的争执：中方开发人员说是由于日方的式样书没有写明确，式样书不够细致，日方设计人员说是中方理解式样书不对，有些地方不写也应该能自己理解。
对策：首先确保产品质量的交货时间；加强双方交流；加强测试。（3）有的项目是日方边设计，需要中方同步开发，中方开发人员认为式样书上写多少就做多少没有写的就不做。
对策：加强项目的交流，主动提出设计思考让日方人员确认是不是这样的意思。（4）中方开发人员的日语熟练程度不够。
对策：加强IT日语教育，开发人员至少达到能理解日语式样书的水平；配置专业的日语翻译辅助。
（5）对于一些中方开发人员在太在意的一些细节问题，例如：字体，颜色、对齐方式等，要求不够严谨。
对策：强化质量意识，建立开发和测试规范。
（6）开发过程的规范性与开发人员的态度：日本企业的开发管理，讲究中规中矩，非常重视文档的规范化管理，力求做到“凡事必求有据”；而中国企业在文档的规范化管理方面相对淡薄；日本企业项目管理对涉及的过程和文档，规定了极其严格的次序和样式，要求开发人员严格执行。而中国企业在具体执行方面，开发人员往往对这些规范和要求的遵照不够严谨。
对策：完全按照客户要求执行，包括文档，如：开发进度报告、测试用例、测试报告等；加强开发过程管理，规范开发过程，引入CMM模式；加强软件质量保证，如代码评审、文档审核、测试。
（7）中国企业的开发人员比较喜欢技术创新，在开发过程中对于一些技术问题提出自己的技术方案，可能会导致部分模块技术实现方式与整体要求有差异。
对策：完全尊重日本客户的文化和管理模式，积极提出技术建议；对于有要求遵照Sample代码或对具体技术实现细节有严格要求的，开发人员必须严格遵循，不允许采用自已的技术实现；加强代码审查（code review）。
（8）一些日本企业与中国企业的SE共同参与设计或交流的项目。
对策：在日本的合作伙伴企业派遣SE到项目现场进行设计；派遣中国SE到日本参与设计，设计完成后带回中国开发；日本企业短期派遣SE到中国。（9）软件外包知识产权保护与客户保密问题。
对策：严格保护日本客户商业秘密和知识产权；中国企业与日本企业签订保密协议；中国企业与开发人员签订保密协议。
（10）日本企业对中国企业开发进度的掌握。
对策：按照日本企业项目管理要求报告项目进度；分阶段交付。（11）远程协同合作开发的交流手段和方式。
对策：实时消息/语音/视频交流，例如：MSN Messenger, Yahoo Mesenger、视频会议系统、远程控制、远程协助、远程调试；Email、FTP；相互人才派遣，人才交流。
案例分析十二
问题1：
在一个软件产品整个的生命周期中，软件产品发布之后便进入漫长的软件维护阶段，而对于一些行业软件更是如此，后期的软件维护是非常重要的一个环节。在维护过程中通常要涉及到开发人员在现场对代码的维护，对数据和设备的维护，还可能需要根据用户要求对软件做相应的修改，有些可能涉及到重新开发或者发布新版本。当然后期维护也可能在一段时间内将会带来相当丰厚的收入，保持良好的客户满意度也将变得非常重要。现场开发人员不仅仅是完成维护工作，而且更多的是需要通过和用户沟通了解用户在使用软件过程中遇到的一些问题，帮助用户正确认识软件维护的目的，得到用户的支持和协助，使软件最大程度地帮助用户提高其工作效率，创造经济价值，在用户中建立起良好的口碑。同时现场人员也应该积极收集和整理用户提出的一些问题，善于总结和思考，将这些问题反馈给公司总部，将一些用户期望的功能发布在下一个版本当中，并且完善旧有版本中的缺陷。从这个角色出发，现场人员在一定程度上扮演了市场人员的角色，并且是接触最前线的用户，他们在做维护的同时，可以体会到用户使用软件的感受，从而得到最准确的市场信息，同时现场开发人员又是公司形象代表，每次现场工作都代表着公司的形象，所以公司需要设置专门的培训内容用于训练员工在外如何保持公司的良好形象同时做好宣传工作。问题2：
在软件开发过程中，团队协同开发，很容易出现软件版本管理不善带来的软件系统故障。代码经常会被新的版本替换而使某些开发人员的工作成果丢失。这样不仅会打击开发人员的工作热情，也不利于责任的明确。在现场开发的过程中，由于缺乏监督和管理，这种情况会更加普遍，如项目现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理，甚至只是开发人员的个人意见，并没有通过项目管理层的同意，这种处理方法就很容易造成总部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，从而造成系统故障的反复出现。此外，由于现场维护一般都会涉及到大量用户数据，程序的修改不仅会影响到软件功能，更可能产生很多垃圾数据，这些都是用户所不希望看到的，所以对现场代码的更改要严格控制，并且及时和总部版本保持一致，如微软公司出品的版本管理工具VSS就能够做到WEB访问，通过有效配置能够有效控制现场版本。
案例分析十三
问题1：
作为为项目经理面对项目问题应从更深层次上思考，要遵循项目管理原理，而不是浮于事务本身。项目经理张强在项目开始时就应制定详细的项目管理计划，应先考虑好可能要进行的项目沟通并加以执行，而不是在出现问题时才去弥补。沟通不完整的项目过程，大多数会顾此失彼，进一步导致项目问题的发生。一言纳之，张强的问题关键是没有计划，如果按软件过程能力成熟度模型CMM评价，该项目组织只能是初始级。
造成项目问题的原因有以下几点：
（1）沟通管理计划没有或不够详细；（2）没有重视部门间横向沟通；
（3）与客户沟通不到位，客户需求未能准确把握。问题2：
要实施高效的会议，首先是在会议前要有计划，通常会议计划来源于项目沟通管理计划，准备阶段通常按如下顺序实施：
（1）决定会议的宗旨和类型；
（2）分析会议的因果：本次会议同本部门目标的关系？本次会议同上、下次会议的关系？什么事可能会影响对本次会议的兴趣？
（3）明确涉及的、受影响的人和事；（4）制定会议成果说明；（5）决定要讨论的主题；（6）决定会议角色分配；（7）决定会场布置；
（8）计划会议议程表：非正式议程表、正式议程表（5W和1H）。
在会议过程中，有效地主持或参与会议则要注意按会议步骤逐项讨论议程，总结决定。在会议中应鼓励与会者积极参与，制止消极行为和不良意见。陈述信息要自信，态度要直接、坦率。对整个会议要注意掌握时间，记录重要备忘事项和决定。
会议跟踪也是一项重要工作。应自上而下逐级向必要的非与会者传达会议信息,制定行动计划完成分派的工作,确定计划以跟踪会上决定的工作进度。制定下次会议议程。问题3：
项目经理应明确自已的工作职责范围，对项目相关资源的安排在制定沟通管理计划时应有详细的描述。对项目进度、项目成果应及时与公司高层领导或干系人沟通。项目组织应建有基于Internet的软件开发交流平台，从而能调度、跟踪解决项目现场问题。
项目经理和项目人员应通过各种方式与客户多作交流，如QQ，MSN、电话、电子邮件等。合适的组合是项目团队中至少一人是客户方的代表，项目初始时团队成员应与客户方的软件使用人员经常地进行业务方面的交流。案例分析十四
问题1：
项目经理刘克勤的项目沟通管理是成功的。对于项目管理，除了掌握必备的项目基本方法和管理工具（如计划制定、预算编制等），对项目背景和目标有清楚的理解和认识外，最重要的一点就是与人交往的技巧。成功项目经理和失败项目经理的最大差别，可能就在于如何跟人打交道，如何跟客户打交道，如何跟公司领导打交道，如何跟项目成员打交道。问题2：
项目经理刘克勤在项目过程中，团队建设相当成功。他为团队成员间建立纽带，并通过各种行为加强信任和消除团队合作的障碍。其中最值的借鉴是尊重团队成员、采用多种方法沟通、进行深度对话。
案例分析十五
问题1：
我们都知道，信息应用系统的变更尤其频繁，而频繁的变更必然影响到信息工程项目的三大目标。通常与客户接触最多的是市场部项目经理，引导客户需求对项目经理就非常关键，项目经理引导得好，项目的开发就会非常顺利，反之，就会使项目组疲于奔命。
该项目中，市场部李工不断地提出新的需求时，张工“来者不拒”、疲于奔命、不停地更新项目计划，导致项目范围无法确定，工期和成本不可控制，团队成员工作目的也不明确。
风险应对策略一般分为四种：回避、转嫁、减轻、接受。回避风险指改变项目计划，以排除风险或条件，或者保护项目目标，使其不受影响。转嫁风险指设法将风险的后果连同应对的责任转移到第三方身上。减轻风险指设法把不利的风险事件的概率或后果降低至一个可接受的临界值。采取此项技术表明项目班子已经决定不打算为处置某项风险而改变项目计划，或者表明他们无法找到任何其他应对良策。该项目已经发生了严重的需求风险，张工采取补救措施应该包括减轻和接受。减轻风险的应对措施应能设法减轻风险的影响，其着眼点应放在影响程度最大的连接点上，张工应该与李工积极地沟通和谈判，使他们明白本期工程的重要意义，并承诺本期工程不是交钥匙项目，可为系统升级和扩容留有扩展接口，将来新的需求能够通过后续工程逐步开发实现,李工同意本期工程只实现大家最为关注的功能指标和性能指标;最常见的接受风险的应对措施为预留应急储备,或者简称储备,包括为已知风险留出时间、资金或资源。为接受的风险所预留的储备取决于按可接受风险水平计算所得影响的大小。张工应该申请启动项目风险储备金，通过增加资源成本、付出额外劳动使得项目回到正轨。问题2：
在设计系统架构时，项目管理经验不足、关键技术不明确、系统扩展性不佳、产品兼容性有问题、软件版本管理混乱等，均可能是影响系统正常运行的潜在隐患。在本期工程的机房设备平面设计中，张工团队起初大部分机架式的小型机集中摆放在一片较小区域内，从表面上看，提高了机房平面空间的使用率，但是由于未充分考虑到设备散热因素，造成了该区域的机房专用空调负荷过重而多次宕机。
后来，张工聘请了具备通信设计资质的专家负责工程设计，从机房空调、电源、布线、承重、消防等各个方面进行了详尽的勘察和设计。透过专家编制的工程设计，张工团队可以细致地了解有关机房设计的技术内涵和外延，并通过工程设计评审机制，一方面确立了工程设计的权威或指导作用，另一方面获得了专家们的可靠技术承诺，实现了工程设计风险的良性转移。问题3：
针对该项目的风险管理，提出以下几点建议作为参考。
（1）推广项目管理理念。项目团队主动向项目干系人及周边人介绍项目管理的先（2）
（3）
（4）进理念和方法，处处营造项目管理的氛围。团队成员积极参加项目管理培训，将所学用于工作和生活之中，并加以总结和升华，提升自已的竞争力。有效管理项目风险。项目经理自始至终负责制定项目风险管理计划和风险应对计划，并在每次项目例会时重点讨论项目风险，对风险发生概率和影响程度进行评估，由定性分析到定量分析，制定有效的预防、减轻或促进风险（机会）的应对方案。
多渠道沟通和谈判。保证多渠道沟通机制畅通，采用横向沟通方式和纵向沟通方式。灵活使用谈判手段和技巧，收集和掌握足够的有用信息，确保具有主动的话语权。处理好与项目干系人的关系，相互配合，实现共赢。
争取高层领导支持。高层领导对于项目成败至关重要。高层领导掌握项目团队所需的任何资源。通过邀请高层领导参加项目启动会、关键里程碑发布会、项目完工总结会等形式，既可以使高层领导关注项目、了解项目和推动项目，又可以提升项目及项目团队地位，有利于项目成功，有利于个人职业生涯发展。
案例分析十六
问题1：
对于紧急重要风险1措施如下：保障工程进度要求，确保NSS、BSS软件督导的调测力量；及时沟通，避免因为传输原因耽搁进度；确保工程质量，督导、督察人员将对合作方施工人员进行有效的指导和对工程质量进行有效监控。项目实施日报制，项目经理每日对省市公司网络部进行工程汇报，对于因为用户原因造成的进度耽搁明确指出来，分清双方责任。
对于紧急重要风险2措施如下：公司研发中心MSC、BSC、BTS人员现场进行信令跟踪，对切换不成功的原因进行定位，在A公司成立专门的小组，协助现场进行问题定位。如果是我方原因，中研相关部门进行程序修改，如果是对方原因则提供相关的信令分析文件，由项目经理和中研人员共同向局方解释，要求爱立信修改相关程序。计划工程的不同阶段分别举行三次移动公司、A公司、爱立信双频技术切换交流，讨论双方参数设置，移动公司负责总体监控双方的实施工作；在城市郊区话务量较小地区，开通5个基站进行单站以及双频配合测试，为全网开通积累经验。
对于紧急重要风险3措施如下：需要找到集团公司《关于建设中国移动1800M双频网的若干意见》文件原件，进行仔细分析，寻求解决方法。加强省公司高层的工作，通过客户关系工作期望给A公司工作上提供支持。对此事向公司总部反映，看看是否通过北京分部的工作使移动集团公司有所松动或是有其他变通方法。
对于紧急重要风险4措施如下：公司对城市1800M频段分地区进行测试，摸清干扰信号频段，通过调整频率规划规避部分干扰，争取多开通基站。了解目前使用1800M单位情况。协助移动与其进行交涉，争取占用单位能进行频率调整，解决1800M干扰问题。将此事汇报到移动公司高层，通过其与无委高层的沟通解决频占费的问题，并通过无委清理被其他单位占用的1800M频段。问题2：
该项目还存在以下几个问题：
（1）A公司将竞争对手的竞争风险分析不全面。A公司仅仅是从技术上进行了风险防范，对于其他方面A公司却没有任何措施。
（2）对于1800M干扰的风险问题，A公司制定的计划太松散，没有引起足够的重视。（3）对于1800M网络的建设目的A公司理解有些偏差。
调整的风险应对计划如下：（1）收集竞争对手问题，针对此提出A公司的解决方案。
（2）联合市场部，加强高层项目推动，突出A公司网络设备特点，建议用户在省会城市引入竞争，尽快开始1800M工程建设。
（3）加强干扰解决推动监控，加快进度，项目经理进行全程跟踪；
（4）对用户进行双频网建设思路进行新的引导，列举A公司在全国的双频网应用，列举A公司开通基站的指标数据。
问题3：
（1）进行调研，确定流动原因。
（2）在项目开始前，把缓解这些流动原因的工作列入风险管理计划。
（3）项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行。
（4）制定文档标准，并建立一种机制，保证文档及时产生。
（5）对所有工作进行细致详审，使更多人能够按计划进度完成自已的工作。（6）为每个关键性技术培养后备人员。
案例分析十七
问题1：
（1）对省内省外投标人提出了不同的资格要求。公开招标应该平等地对待所有投标人。
（2）乙单位提交保证金晚于规定时间,投标保证金是投标书的组成部分,应在投标截止日前提交。
（3）招标书发出时间为2004年12月15日，而投标截止时间为2004年12月30日，中间时间为15日，有违招投标法所要求的20日。
（4）投标截止时间与开标时间不同，《招投标法》规定开标应当在投标文件截止时间的同一时间公开进行。
（5）不应该是招标办主持开标会。开标会应由招标人或其代理人主持。（6）重新招标时候评委应为5人以上单数。
案例分析十八
问题1：
企业A向第三方（监理公司C）泄露承建单位（IT公司B）的技术机密，违反合同签订时保密约定要求，该措施不妥。问题2：
项目不可分割，属于一个整体，未经甲方企业A同意，此类项目不应分包。而公司B却和公司D签订此项目的分包合同，很显然，该合同无效。问题3：
企业A应该将公司B未付给公司D的所有款项（扣除保留金）付给公司D，并从应付给公司B的任何款项中如数扣回。
案例分析十九
知识产权是企业宝贵的无形资产，也是企业能够持续发展的前提之一，某软件公司A公司从事管理系统软件开发，程序员张某参加了A公司开发管理系统软件的工作，后辞职到另一个公司B公司任职。于是项目负责人将张某在该软件作品上的开发者署名更改为他人。问题1：
按照《计算机软件保护条例》的规定，自然人的软件著作权的保护期限为自然人终生及死亡后50年.问题2：
知识产权一般都具有法定的保护期限，一旦保护期限届满，权利将自行终止，成为社会公众可以自由使用的知识。商业秘密受法律保护的期限是不确定的，一旦为公众所周知，即成为公众可以自由使用的知识。问题3：
甲、乙两人同时在同一时间就同样的发明创造提交了专利申请,专利局将分别向各申请人通报有关情况,并对两件申请都不授予专利权。这种情况是否合理？
对于同一时间申请专利的情况，专利局可分别向各申请人通报有关情况，请他们自已协商解决这一问题，如果双方协商不成的，则两件申请都不授予专利权。问题4：
该项目负责人张某侵犯了开发者张某的身份权及署名权。问题5：
目前，我国已形成了相对完备的知识产权保护的法律体系，对软件形成一种综合性的法律保护，如源程序和设计文档作为软件的表现形式受《中华人民共和国著作权法》保护，同时作为技术秘密又受《中华人民共和国反不正当竞争法》。
第五篇：软件项目管理岗位竞聘报告
竞聘报告
尊敬的各位领导、各位同事：大家好！
今天我在这里，参加中心中层干部竞聘会议，这是一次难得的机会，一次检验、学习、提高的机会。
首先，借此机会，简单介绍一下我的情况，本人曾先后就读于上海XX大学计算机实用技术专业和上海交通大学计算机科学与技术专业，1998年-2000年参加NIIT软件学院海外课程进修，并获得该软件学院diploma证书，2002年获得微软认证高级软件开发者MCSD证书。2001年进入XXXX中心，正式成为中心的一员。在中心工作期间，始终承蒙领导抬爱和提拔，同事们的支持和帮助！
参加这次竞聘，我认为我具有以下几方面的优势：
1、长期的软件开发工作经验，我曾经在软件开发的各个环节上进行工作，熟练掌握和应用目前软件开发的几大主流工具和数据库存储系统，熟悉软件开发的标准和规范，累积了丰富的项目开发经验，由于软件开发工作本身的特殊性，使我在长期的工作中，养成了乐于学习、不断适应、善于接受新的理念的工作和学习习惯。
2、丰富的项目管理工作经验，在我进入软件开发这个行业的十多年期间，我曾先后管理和完成了各类软件项目的实施20余个，在项目管理的过程中体验了软件项目管理在执行过程中的各种情况和突发事件，积累了非常丰富的应对措施以及项目实施经验。
3、熟悉目前软件行业项目管理标准，在长期的实际工作中，本人熟悉了包括CMM，ISO级软件项目标准，并善于进行项目计划的制定，项目执行过程的流程改进，软件的开发组织，软件的质量保证以及项目文档及数据的存档管理工作。
对于今后工作的设想：
一、在中心整体战略布局下，积极配合部门经理，完成部门任务
保证项目开发过程的质量，全面降低程序开发过程中的人力成本。在不影响正常项目进程的情况下，组织资源，通过质量检查、节点评审、人力培训，整理和管理部门有效的技术资产，提高软件生命周期中的复用性，构建适用于本部门 1的软件业务的技术管理体系；
(1)制定相关的涉及到技术管理的制度流程规范；
(2)组织部门技术监督和审查、考核；
(3)组织执行技术库的构建，监督执行和推广验证技术管理的相关成果；
(4)组织相关技术、业务的培训任务；
(5)定期向部门、中心汇报技术管理工作成果计划、执行、评估结果；
(6)组织各个项目的过程评审活动；
(7)按照要求承担售前组织管理工作；
(8)在技术管理工作中协调相关部门和各个项目之间协同；
二、制定技术管理体系和目标规划
按照软件部的规划和部门未来前瞻性要求，紧密围绕实际业务，统筹规划、分布实施、立竿见影的原则，从制度规范流程、项目开发过程、人力规划三个层面展开具体工作。
（1）制度规范流程
加大技术管理在部门软件部制度规范体系中的体现，尤其是《考核及奖惩制度》、《项目经理制度》、《开发流程》、《实施流程》、等明确具体条款，项目归档备份和虚拟机服务器的管理；
（2）严格监控项目开发过程
监控项目经理在各具体项目执行过程中的技术管理工作：
检查各项目组质量保障工作的进展情况，定期检查、评估文档编制、编码规范，保证部门项目质量工作高质量、有序的完成；
组织项目阶段性技术评审；
推广应用各项有利于项目过程的各项实现辅助技术措施，例如：版
本管理（vss、cvs），bug工具（bugfree、excel），积极开展各项组内
交流学习；
明确要求项目经理在项目结束之后的总结归纳中，除了对项目进行系统分析之外，提交相关的开发经验、开发框架、控件和关键算法。
对于项目过程中的各项信息，都作为中心软件部共有的财产和资源，集中统一管理。
三、部门人力规划
软件部的员工都作为软件最具活力的成分，必须引导帮助其进行合理的职业规划。
主动调研部门人员的技术能力水平，制定人力培训计划。开展各项能力提升（培训、交流等），促进软件部员工技术能力体系稳步、快速的提升，改善具体工作执行能力；组建部门内专家团，汇聚技术精英，服务于部门，共享于部门。
四、检查监督各项目质量工作
随着软件部业务的明确和不断壮大，已完成和未完成、以及正在开始的项目数量越来越多，首先对以往各个项目的执行情况进行摸底。
（1）文档是否齐全，依据的标准，是否按照部门要求；
（2）代码设计是否规范，依据的标准，是否按照部门要求；
针对文档和代码两项重点工作，在过程中监督和检查各项目经理后续工作的质量执行情况。
五、组建专家团
参加项目专家团的人员仅限于在软件项目领域里富有专业技术能力的骨干技术人员和管理经验的项目管理人员。
项目专家团作为部门职能常设机构，负责处理的日常工作：议题的提出、专家团活动安排、意见汇总、提交活动报告、具体措施执行保障。
专家团主要承担部门内临时性任务，具体职责如下：
(1)承担项目实施方案的论证（售前）；
(2)承担对项目执行情况的检查、评估和验收工作：项目工作计划及执行状况、资源使用情况、项目节点性评审（需求、设计、开发、测试、验收）；
(3)承担领域为公司重点软件项目的重要技术问题的咨询和技术攻关工作；
(4)承担部门内部日常的知识管理，技术培训；
(5)参与部门项目运作过程中的制度、流程、规范修改性建议的提出；
(6)项目正常情况，专家团成员有组织的参与一线项目督察工作，检查项目组各项工作的进展情况和重大决策的落实情况；
(7)项目出现紧急情况，专家团成员有组织的参与一线项目实际具体工作；
六、实现应用“知识库管理”模块
围绕部门复用性管理的目标，部门项目的成果、经验等显式知识（业务介绍、技术构架、项目管理、解决方案）：
（1）架构
（2）控件
（3）模块化类库
（4）成果算法和函数
（5）开发经验技巧
（6）开发性接口
（7）测试与实施技巧
着手集部门之力服务于项目，完成主体知识管理的具体工作。为创建今后的技术核心团队以及产品化奠定基础。
七、按照计划进行部门培训任务
为了落实今后几年的任务，必须大力提高员工的能力，而培训是目前提高能力的重要措施。另外，实施制度与规范、测试制度与规范将由实施组统筹安排。与各项目有关的业务培训也将融合到各项目计划之中，并由各项目经理统一安排。
最后我要感谢一下中心为我们提供了这样一次公平竞聘的平台，给了我一次挑战和展现自我的机会，我今天竞聘的是软件技术部项目总监岗位一职，假如我竞聘成功，我将会认真地履行好我的职责，贯彻落实中心制定的目标，提升软件项目管理的品质，规范项目开发的流程，提升员工的工作热情！我有充分的自信和决心做好这项工作！
XX
2012年9月24日
点击咨询 