2008-06-19 第六十八天讨论：项目实现过程和项目管理过程有何区别？

铅笔小星

大家好。我是一名项目管理的学习者，最近在学习中，始终对项目实现过程和项目管理过程这两个概念不清楚。

我听说在信息系统项目管理师中可以遇到大虾，请信息系统项目管理师大虾们，给小弟一些指导，以便我把这两个名词理解的更深！

不甚感激，谢谢。

vista

　　1.项目前期以及项目准备

　　在进行任何一项较大的项目时,首先要进行项目的可行性分析和研究,因为这些项目中的问题并不都有明显的解决办法,这样就很难在预定的时间、费用之内解决这些问题，如果这些问题没有可以行得通的解决办法，贸然开始这些项目，就可能导致项目的失败，造成巨大的损失。

　　1.1可行性分析

　　软件项目可行性研究的目的是用最小的代价和时间，确定该项目是否能够开发值得开发，其实质是要进行一次简化的、抽象的需求分析和设计过程，主要应从以下几个方面进行分析。

　　1.1.1技术可行性

　　对要开发项目的功能，性能和限制条件进行分析，确定在现有的资源条件下技术风险有多大，项目是否能够实现，现有的资源包括硬件、软件资源，现有的技术人员和技术水平，已经有的工作基础等，判断技术上是否可行，主要需要考虑以下几个问题:

　　(1)开发的风险 即在给定条件下 能否实现目标的功能和性能；
　　(2)资源的有效性；
　　(3)技术的发展性；

　　由于需求未经过详细的调研，存在模糊性和可能的变化，开发人员进行技术可行性评估时，存在比较大的风险，一旦出现估计的错误，将可能导致灾难性的后果。

　　1.1.2经济可行性
项目管理者联盟，项目管理问题。
　　进行软件开发项目的成本估算以及了解取得的效益估算，确定该项目是否值得开发，对于大多数项目，衡量经济可行性，应考虑一个“底线”，同时应考虑公司的长期经营策略，潜在市场前景等因素。

　　1.1.3社会可行性

　　应考虑项目是否存在任何侵权、责任等问题，考虑在现有的制度、法规下是否行得通，包括合同、责任、法律等多种因素。

　　1.2需求调研

　　在项目前期工作中，需求调研是其中最重要的一个环节，今后的许多工作都依赖于需求调研的结果，需求调研的过程是渐进的，在可行性分析阶段，主要关注的是项目规模、范围和重点的功能，在项目进入正是开发流程以后，我们需要更加全面、准确地了解系统的需求不重视需求过程的项目队伍将自食其果，需求工程中的缺陷将给项目成功带来极大风险。如:无足够用户参与导致产品无法被接受；用户需求的增加带来过度的耗费和降低产品的质量；模棱两可的需求说明可能导致时间的浪费和返工；用户增加一些不必要的特性和开发人员画蛇添足；过分简略的需求说明以致遗漏某些关键需求；忽略某类用户的需求将导致众多客户的不满；不完善的需求说明使得项目计划和跟踪无法准确进行。

　　1.3项目团队的组织

　　建立项目团队是项目开发过程的开始，一切工作都是由项目团队的成员完成的在整个项目的运行过程中，需要很多不同的角色参与到项目中，完成不同阶段的任务。所以在建立项目团队的过程中要把握好人员角色的划分、特别人员管理与激励、监督等。整个人员的管理是项目管理的关键，因为人是活的，而项目是死的，只要人员管理妥当，项目开发一般是不会出什么问题的。
项目管理者联盟，项目管理问题。
　　1.4项目开发计划

　　软件项目的特征之一就是需求的不确定性和开发过程中存在的技术风险，按照通常的方法，制定一个项目的计划应该是先根据项目的需求，进行详细的任务分解找出实现的方法，估计出项目的工作量，再根据项目资源的状况，制定出项目的计划。

　　但是，再现实的工作中，项目的时间表往往是事先确定的，给开发留出的时间也是事先定好的。而我们能够利用的资源，主要是开发的人力资源，也被事先基本确定了，在被确定的这 2个前提条件下，我们如何根据项目的需求，合理地安排人力和时间，完成项目的开发，这是现实中项目经理经常遇到的问题如果事先确定的时间表是相对比较合理的，至少应该是我们够的到的。我们制定的开发计划才是有意义的，否则，按照这个时间表制定出来的计划只能失败的在这种情况下，项目经理唯一可以做的是对用户的需求进行剪裁，去掉某些耗时长而且不太重要的功能，或是在开发中适当降低质量要求，或许可以完成项目的进度。当然这必须最终要得到用户的认可。

　　2.项目开发过程管理

　　2.1 详细设计

　　在详细设计阶段，由于任务已经详细地分解，总体地解决方案和技术框架已经确立，详细设计地目的就主要是针对某个特定地模块或对象，根据需求，技术框架地要求和模块间接口，描述出我们实现功能的方法，主要内容包括：

　　（1）内部算法描述；
　　（2）内部数据组织；
　　（3）相关接口详细设计；

　　2.2设计评审

　　在设计完成后，必须安排设计评审以保证设计的质量，通常设计评审以小组内部的评审会的方式进行，参与人有项目小组内部的人员及其负责人，由开发者介绍其设计思路，其他人了解并对其设计质量进行评审。评审的内容主要包括：

　　（1）关键算法的可行性；
　　（2）接口是否符合概要设计的要求；

　　（3）技术清晰度是否符合设计标准；
　　（4）文档的完备性；

　　评审通过的设计，才能够开始编码工作，评审的结果应记录到开发文档当中。

　　2.3编码

　　在编码阶段，主要需要在编码工作结束后，进行代码审核，这项工作非常重要主要应该由项目小组的技术负责人完成，审核的目的并不是为了检验代码的正确性而是需要对编码是否按照规范进行审核。主要内容包括： 本文转自项目管理者联盟

　　（1）变量、包、方法等的命名是否符合规则；
　　（2）注释是否填写完整，是否符合规范；
　　（3）代码的可读性，编写风格是否符合规范；
　　（4）是否有明显的造成系统运行低效率的处理方法；
　　（5）公共变量的定义和使用；

　　2.4调试

　　编码工作完成以后，通常需要开发人员自己进行单元测试，有些部分需要编写相应的测试程序。应该避免发生这类的情况，有些开发人员任务自己不应该进行测试工作，在编写完代码以后，只要编译成功，就直接提交成果，将测试工作完全交给测试人员去做，这样做不仅仅给测试人员增加了许多的工作量，同时增加了许多因为交流产生的时间，造成进度的延迟，管理人员应该杜绝程序员的这样的思想，同时在管理中予以考虑，可以将提交成果产生的 bug数量作为考核程序员业绩的标准之一。
  
　　3.项目后期管理

　　3.1项目的验收

　　项目验收，是整个项目生命周期中最后一个环节。一般来说，软件项目的验收一般来说有2个阶段，第一个阶段是验收测试，当验收测试成功结束后，一般会有一个阶段的试运行阶段，只有当 2个阶段全部结束后，整个项目才算真正结束，可以收回全部的工程款，该软件也进入其运行维护期。验收测试应按照软件的需求，质量要求进行测试验收，需要甲乙双方共同建立验收小组，或请第三方测试机构进行验收测试，在验收测试之前，开发方应提供一系列的开发设计文档供验收测试使用。

　　3.2软件维护

　　编程大师曾说 “哪怕程序只有三行长，总有一天你也不得不对它维护”。很多软件产品不是一次性的买卖，比如在电信、金融等领域，有些软件系统要用十几年，对软件进行维护是必不可少的，软件公司的经理们没有哪一个喜欢被维护的费用吓一跳，但软件维护的代价通常是高昂的。对软件而言 “维护”是个不太直观的术语，因为软件产品在重复使用时不会被磨损，并不需要进行像对车辆或电器那样的维护，软件维护是人们对既丰富多彩又会令人心酸的活动的统称，其中丰富多彩的活动是指那些反映客观世界变化，能使软件系统更加完善的修改和扩充工作，令人心酸的活动是指那些永无休止，并且改了旧错却引起新错让人欲哭无泪的工作。
  
参考文献：

1. 邱菀华 沈建明 杨爱华等编著  现代项目管理导论 机械工业出版社  2002 年 10 月
2. 美 理查德 怀特黑德著 领导软件开发团队 电子工业出版社2002年 5月
3. 尼尔 怀特著 管理软件开发项目-通向成功的最佳实践  电子工业出版社2002 年 4 月
4. 刘积仁 康晓东 饶友玲主编  软件开发项目管理 人民邮电出版社  2002 年 2 月
5. 美 Joseph Raynus 著  CMM 软件过程改进指南  电子工业出版社  2002 年 3 月
6. 美Evelyn Stiller Cathie LeBlanc 著   基于项目的软件工程 面向对象研究方法 机械工业出版社  2002 年 6 月

[ 本帖最后由 vista 于 2008-6-19 19:22 编辑 ]

vista

两年来已经接触了4个项目，海宁，沧州，太和和大庆，从最初的数据库设计，部分功能的编码到后来的实施，现场开发，用户培训，后期维护，可以说除开最初的调研外，其他所有的过程都有过接触，各方面都有些心得，目前正在大庆协助同事完善系统，在这个过程中发现一些出现的问题和以前的项目实施大都相同，依靠以前的经验和教训，很快的提供了修改建议，鉴于提高以后的项目实现速度，就根据我这两年来几个项目的实施积累下的一些经验写写我认为的一种项目的实现过程和各过程中会遇到的一些问题以及要注意的一些问题，由于本人水平有限，不足之处还望指出。

      项目的实现过程我分成6个部分，需求调研，总体设计，前期编码及测试，现场编码及测试与系统建库，用户培训与现场维护和后期维护。

需求调研就是了解用户需求，编写需求说明书；

总体设计包括系统框架的搭建，数据库的设计和一些实现的约定等；

前期编码及测试包括按照需求上的功能实现的编码及测试，这个时候出来的成果往往只能达到用户60%左右的要求；

现场编码及测试与系统建库是同时进行的两个步骤，现场编码及测试是在项目实施地针对用户的实际需求对系统做出修改及测试，系统建库就是建立系统的基础数据和必备数据，针对GIS系统来说，基础数据就是图形数据，必备数据就是业务数据，这部分数据的建立依赖于用户的数据质量与数量；

用户培训与现场维护是项目实现的两个关键步骤，这个时候系统已经开始试运行或运行，也预示着我们的项目快接近尾声，但这两个项目也往往是最困难的两个步骤，依赖于用户的心理，系统的质量以及实施人员的应变能力等；

后期维护就是项目已经告一段落，只是在用户发现问题时对项目进行适当修改以保证系统的正常运行。

我接触到的4个项目中，需求调研是没有接触过，总体设计中做过数据库的设计和实现的约定，更多的时间是在项目实施阶段，就是前面提到第4，5个步骤，本文主要写写我个人对这些步骤的一些认识和经验。

      这里只写写在项目实现过程中对需求调研的一种认识和建议，在项目实现过程中往往会发现需求会很简单，很模糊不清，这里面包含很多方面的原因，包括用户的水平，业务的复杂度，调研人员的水平，对业务的理解能力，对系统的整体认识等等，目前我们在这方面不能对需求的结果有很高的要求，我们只要知道做什么就可以了，至于不清楚的地方可以记下来，系统实现时做的灵活些，等到现场实施时再与用户沟通。


       对需求的建议是除开系统的功能外，还要对实施地的现状有所描述，如硬件情况，网络情况，现有信息化程度以及用户的数据也要做相应的描述，这样可以更好的在项目实现过程中让参与人员从需求中挖掘出潜在的需求，也可以更好的理解需求，也为以后的项目实施做好心理准备。

[ 本帖最后由 vista 于 2008-6-19 19:23 编辑 ]