去年，我参与了一个不是很成功的项目，项目进度严重超期，开发员信心全无，大家互相推卸责任，对问题也是机械式的反应。总结后发现，项目不成功的很大一个原因没有一个符合自身特点的开发过程，在问题出现后没有任何预先制定的制度来协调，所以定义好一个符合自身特点的软件开发过程是保证软件质量的基础。
根据RUP的经验，我们把软件开发分成和RUP一样的四个阶段：初始化、精化、构建、部署四个阶段。由于我们是初试使用RUP开发过程，同时根据我们小组的特点我们把软件开发的目标定位在基本满足CMM 2的关键过程域（KPA），达到一些CMM 3的关键过程域上。我们制定了需求分析、变更与配置管理，项目管理，分析设计、测试等几个关键过程，通过对这些关键过程的定义来控制整个软件开发的活动。
需求分析关键活动是完成收集和定义软件开发需要的资源。根据开发项目性质的不同，需求分析的重点有所不同，比如对于数据库为主的项目我们就把重点放在项目的业务逻辑上，主要分析和比较业务逻辑之间的差别和实现，如简单的进销存项目，而对于与系统结合的比较紧密的项目，就把需求分析的重点放在接口的实现上及与平台相关的特性上，如网络数据包分析项目。实践证明注意到项目之间的差别对我们开展项目计划和制定项目计划都有
重要的意义。 变更和配置管理关键活动定义了当出现需求需要变更时采取的对策。我们采取的策略是：当需求出现变更的时候，所有成员都进行交流确定这个变更对项目进度的影响，然后综合考虑后确定是否要进行变更，一旦确定了对策，任何成员都必须无条件的执行，由于团队规模较小，这一活动相对容易实现。
项目管理关键活动主要是定义项目开发所需要的环境以及如何协调成员之间的进度。这个关键活动的实施我们是主要集中在版本控制上，利用现在流行的版本控制工具，如CVS，VSS都可以有效的管理和协调小团队的开发。
分析设计和测试这两个关键活动我们主要采用几个原则。第一，分析和设计适当分开。做分析的不能全去做做设计的，在设计中有不做分析的人才可能发现分析的缺陷，分析的鉴定应该由所有成员统一来执行。第二，设计和测试适当分开，开发员并不是很乐意去做繁杂的测试工作，而且开发员的测试思路都比较狭窄。第三，设计和文档编写员适当分开。设计员应该将精力放在设计上，可提供简单的样稿，具体的文档编写应该交与专人。实践证明，上述原则的应用是成功的。
除了上述的几个重要关键活动以外，RUP软件过程还定义了其他更为细的关键活动，在这里就不详细叙述了。
风险管理。
风险是最容易影响软件进度的因素，在开发项目的过程中往往由于某种突发事件而影响到整个开发进度。就我所经历的项目来看，项目大概可以分为为企业定制软件和通用的商业软件两类，而为企业定制软件的项目占多数。
不难看除，为企业定制软件的风险除了技术风险以外，商业风险等其他风险几乎没有，所以对于这类项目，我们就要把精力放在技术上，主要是预先判断采用的技术方案对项目的成功是否有推动作用，比如用VB去开发与操作系统结合得很紧密的项目就不太合适。除了这样的问题以外，当突发事件到来时，我们要严格按照定义好的流程去处理，切不可随意行事或按主观意思行事，当没有流程与之定义，应该征求成员的意见然后定义出一个大家都接受的流程,这样增加开发员的主人翁意识也是有帮助的。对于通用的商业软件，除了技术上的风险以外，商业风险也是很重要的，密切注意竞争对手的状态和市场对该项目的容纳程度也是项目成功的关键，由于实践不够，体会也不是很多。
团队组织。
小组的每个成员都是开发项目的主体，他们的行为直接影响到软件质量。一个成功的软件必然是有一个好的团队，所以开发项目时要充分尊重和调动团队的每个成员。
31
长久以来，我们都采用的是树型式管理(图1)。一个项目经理管着几个程序员，由项目经理分配任务，程序员按时完成任务，这个模式对项目经理的要求很高，项目成功的风险都由项目经理承担，成员的主动性也不够，一旦项目经理离开，整个项目就陷入瘫痪状态。这种模式比较适合于一个项目参加的都是新手，这些新手在项目经理的指导下完成任务。
比这种模式更为民主的模式是互相平等模式(图2)。在这种模式中，成员彼此之间互相平等，共同商讨问题，可以充分发挥出每个成员的主动性，但这种模式的问题在于当问题出现后容易耽误时间。要避免这种现象对成员的要求比较高，大家不要互相推卸责任，也不要互相扯皮，所以这种模式比较适合于小组成员具备较高的素质和技能。
结合这种模式就产生了第三种模式：混合管理(图3)。这种模式对于高级别的成员采用平等模式，对于新手采用树型式管理。
在几年的开发过程中，受到管理学的影响，我们采用了一种驱动式的管理模式(图4)。在这个模式中，项目经理不是直接管理其他成员的活动，而是类似于教练的角色在旁边不断的指导和纠正他们的行为，整个实际活动还是由成员自己完成。这种模式可以有效的分担项 目经理的压力，可以把项目经理从以往的转注于项目实现转移到管理的角色上来，项目经理根据成员的能力和特点不同，分配他们不同的角色，明确他们的责任，指导他们的行为，而项目经理注重管理，这种模式类似于足球队管理，在足球队中，教练不会自己上场，而是在场边确定中场、前锋、后卫之间的关系，把自己的战术贯彻下去，实际的操作还是有队员自己完成。
经过实践比较，我认为对于一个刚成立的团队第一种模式是比较合适的，当成员的意识和能力提高后，就要加大他们的参与性，采用第二种模式或第三种模式，当成员成熟后，采用第四中模式能够有效的提高成员的参与意识和责任意识，所以说软件开发中的每个成员都是管理的主体，只有成员的能力提高了，软件的质量也就有保证。
综上所述，软件过程的定义，风险的处理策略，团队的组织对软件质量的影响是最大的，在处理好这些问题之后，我们的软件质量有了大幅度的提高，而且我相信这些问题的解决是大规模软件开发的基石之一，也是软件组织成熟的标志之一。
论软件项目的进度管理
摘要
本文讨论了《电力行业工作票、操作票系统》的项目管理，在本项目中我作为项目负责人，承担了项目管理工作。
在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的工作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不足。
本文从合理的估算项目的工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面讨论了《电力行业工作票、操作票系统》项目管理的基本活动与方法，有效地控制开发进度，确保项目如期按质量完成。本系统在电力系统已经运行，状况良好，受到一致好评。 正文：
2003年2月，我参加了《电力行业工作票、操作票系统》的开发，担任项目管理工作。电力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业相关标准进行工作，《电力行业工作票、操作票系统》就是按照国家有关标准及电力行业操作规程设计的仿真系统。工作人员在施工前按照工作流程在此仿真系统上进行操作，严格遵守电力设施的逻辑闭锁关系，顺序执行。有效地防止不规范操作，确保电力设施及现场工作人员的安全，提高安全意识。
本系统由系统图编辑平台和工作票、操作票签发系统两大部分组成，其中系统图编辑平台
32
主要是编辑变电站、用电系统及变电站控制系统图，每一个电力设施对应一个对象，在系统图上都有相对应的部分，系统图真实地反映电力设施的布局及相互关系，生动形象又合乎技术标准，同时为第二部分提供操作对象。工作票、操作票签发系统主要是在系统图的基础上进行点击操作，每次点击对应一个对象即一个电力设施，根据电力设施的逻辑闭锁关系自动生成相应的工作票或操作票或提示操作不规范。
在本系统的开发过程中，我通过合理的估算项目工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面对项目进行管理，确保本系统如期按质量完成。
1、合理的估算项目工作量及技术难度
我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则。 本系统采用了面向对象的分析、设计等一系列面向对象技术，在本系统工作量的估算上根据功能点进行估算。将每个功能模块逐步分解，直至基本模块为止。我们将系统分为系统图编辑与工作票、操作票签发两个大的功能分别进行估算。系统图编辑部分主要是一个图形编辑系统。一种电力设施对应一个类，电力设施的技术参数及其操作对应相应类的属性和方法，电力设施图是由线段、圆、曲线、折线、多边形等基本图形组成，这些基本图形分别对应一个类，这些类又继承一个最基本的类。系统图编辑部分的工作量也就是这些类的实现，工作票、操作票签发部分用到了编辑平台的系统图，因此由大量的功能可以复用，这部分的功能划分同系统图编辑部分一样也是采用类作为基本结构，这样就比较准确的进行工作量的估算。
同时我们开发的这个系统是基于C/S结构的，由于C/S结构的系统我们公司有不少成功的案例，因此有不少的案例供我们参考。对于本系统的第二部分我们就是借鉴以前我们做过的基于C/S结构的系统，基于C/S结构的系统的框架基本上是一致的，数据库的设计、前台操作如对数据库进行添加、删除、修改、查询等一系列活动大体相同。正是如此，有大量的东西可供我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改。在工作量的估算上也有很好的借鉴作用。这对工作量的估算也是一个重要的参考，为工作进度安排提供了依据。 在技术上，我们重点考虑本系统与其他C/S结构的系统的不同之处，相同或相似之处我们认为没有技术难点。系统编辑平台主要是绘图，我们知道MFC的绘图功能确实强大，但是过于繁琐，功能封装不是十分完美，我们采用了Form++这个MFC扩展类库，这个扩展类库对图形操作封装得很好，大大降低了系统图编辑部分的难度，在界面设计上我们采用了BCG这个扩展类库，使得VC应用程序界面设计得如同Delphi等工具一样完美。同时减少了工作量，在工作安排上，技术难度相对大一点的部分我们安排经验丰富的程序员，同时也同其他工作组的成员商讨技术细节问题，同他们进行技术探讨。这样不至于因为某一技术细节而影响整个工程进度。
根据上述分析我们制定一个详细的进度表并定义相应的里程碑。 2、识别关键任务
系统图编辑部分是整个系统的基础，因为工作票、操作票签发部分是建立在该部分的基础之上，系统图编辑部分直接影响到整个项目。因此该部分是整个系统的关键部分，在这部分中每种电力设施所对应的类及其父类的定义是关键，因为所定义的类必须完整、准确地反映该电力设施的技术参数和操作。
工作票、操作票签发部分，是用户明确提出的要求实现的功能，直接面对用户，这部分的成功与否直接影响到该系统的质量，因此也是不容忽视的。
如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁。因此是本项目的关键任务。在进度控制时我们将其作为重点对象进行控制。
3、随时了解项目进度，必要时调整进度表
在确定项目开发计划时，我们制定了详细的进度表。我们在确定每一项任务时都确定该任务的工作量、开始时间、持续时间、结束时间。同时让每个小组成员知道自己所承担任务的时间表，小组成员根据自己的任务制定自己的详细工作计划。
工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成员对自己的工
33
作都要做工作日志，对自己每天的工作做详细记录。每周对自己的工作进展做出结论，向项目组汇报。在做结论时，不得使用“差不多”、“大概”、“完成了90%”…等模糊字眼。 而是采用某任务 “已经全部完成”、 或者“90％的工作全部完成”或者“再过1天全部完成”…等方式。每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目计划提供客观基础。
同时我们在项目进度计划中根据项目设计定义了相关的里程碑，在每个里程碑我们都采取小组会议形式对本阶段的工作进行确认、总结，对本阶段的进展情况做出结论，并决定是否调整下一阶段的进度计划。
在系统图编辑部分我们认为各电力设施所对应的类（包括其父类）定义完成为一个里程碑，每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的标准，这些类（包括其父类）的实现完成又为一个里程碑，……整个系统图编辑部分完成也是一个里程碑。每个里程碑的标准在系统设计时已经定义好。
结束语
《电力行业工作票、操作票系统》目前已经开发完毕，运行状况良好，受到一致好评。 在本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则，因为小组成员的各有特长，面向对象技术不是每个小组成员都熟练掌握，加之面向对象技术在我们公司还不是很成熟，必须有一个过渡，不能一下子转型，因此采用这种策略符合我们公司的现实情况。 由于项目进度管理得当，项目按期完成，我们小组赢得公司的好评，其他小组也研究我们的管理方式。当然项目管理方式多种多样，根据项目不同、人员不同管理模式应做调整而不是一成不变。适合本项目的管理模式才是最好的模式，先进的管理方法在不同的项目组中取得的效果是不同的，这有待于我们去研究，探索，实践，总结。
论软件项目的进度管理
摘要
2001年10月，我参与x x 市农村信用联社综合业务信息系统的开发工作，该系统面向交易、以客户为中心、采用大会计模式，并以会计核算为核心，实现本外币合一，将柜员管理与柜面业务有机地结合起来，以业务种类码来划分整个业务系统。该项目分为二期：第一期为柜面业务,为期14个月，已于2002年底完成；第二期为卡业务，为期一年，尚在开发中。
在该系统的开发中，我主要担任可行性分析、需求分析、概要设计和第一期项目的项目管理工作。我采用PERT计划评审技术，标识关键任务的同时，允许一些任务并行进行；着重考虑人员在整个项目开发过程中的安排；重视文档规范、命名规范，为减少员工之间的通讯障碍，还启用了Notes系统；跟踪和控制项目计划的执行等措施，保证了项目按期完成。但是，由于对人员流动估计不足，复用力度不够，给项目的进度管理带来了一定的困难。在以后的项目中，我们把限制人员流动率将作为一项合同约束。
正文
2001年10月，我参加了XX市农村信用联社综合业务信息系统（以下简称XX系统）的分析和开发，该系统由我联社与乙集团公司联合开发，系统采用C/S体系结构，主机采用两台IBM RISC/6000 S系列机，操作系统为IBM的AIX 4.3.3，数据库选用IBM 的DB2 UDB 6.1 ，磁盘阵列选用IBM的7133 SSA 串行存储体系结构，前台为SCO UNIX 5.0.5，中间件采用IBM Txseries CICS，编程语言采用SQL和C。
XX系统面向交易、以客户为中心、采用大会计模式，以县级联社为单位设立一个帐务系统，改变原来的储蓄、对公等总帐分开的做法，并以会计核算为核心，把整个帐务系统融合在一起，实现本外币合一，将柜员管理与柜面业务有机地结合起来，以业务种类码来划分整个业务系统，打破传统的业务品种和业务部门的界限。
XX系统分两期实现，第一期为期14个月，已于2002年年底完成并投入运行，主要完成农
34
村信用社柜面业务，包括储蓄（对私）、对公、信贷、系统内电子联行、通存通兑、与人行的天地对接、中间业务等；目前系统内共设机构87个，柜组415个，业务操作员三千余名。第二期为期一年，尚在开发中，主要为卡业务（包括与人行的一卡通、自办农信卡业务等）及客户自助业务（包括ATM、电话银行、网上银行等）。 在XX项目中，作为联合开发的甲方主要代表，我担任项目的可行性分析、需求分析、概要设计和一期项目的项目管理，跨地区通存通兑接口模块的详细设计与实现等工作。
软件开发项目进度管理是软件开发项目管理的一个重要内容，有效的进度管理是保证软件开发项目如期完成的重要环节。在XX一期项目软件的开发过程中，为保证软件按时完成，我采用PERT计划评审技术及一系列的方法和策略。
1、采用PERT计划评审技术标识关键任务
采用PERT计划评审技术标识关键任务。XX项目计划中规定了一期项目的的交付期限为2002年年底。整个一期项目长达14个月。在一期项目的开发过程中，采用的是 “改进型瀑布模型”，我们从可行性分析结果出发，使用快速原型方法来补充和完善需求说明，还对信贷部分的需求进一步细化。从设计阶段起的各阶段基本采用了传统的开发方法，各阶段的结束标志比较明显。所以在软件的开发过程中，我采用了PERT计划评审技术对开发过程中的各关键任务加以标识，允许关键任务以外的其他任务在机动期内伸缩。而关键任务的伸缩不得超过一周。当遇到关键任务延期时，我召集大家寻找原因，并由主要责任人签字。把这种责任作为业绩考核的一部分与收入挂钩。
在标识关键任务的同时, 根据PERT图，允许某些任务的并行。在概要设计阶完成并通过评审后，允许各子系统在详细设计阶段及实现阶段任务上的并行进行。我把系统划分成储蓄对公、信贷、联行三个子系统，在概要设计阶段的任务一完成，就将开发人员分成三个小组，分别进行上述三个子系统的详细设计与实现。实现了在这两个阶段上任务的并行，也确保了项目的如期完成。
2、着重考虑人员在整个项目开发过程中的安排
着重考虑人员在整个项目开发过程中的安排。我从各县联社抽调业务骨干，作为业务分析人员，提出并确认需求。考虑到本项目完成后的维护需要，在乙方开发人员大部分撤离后，维护任务将主要由我社一方承担，所以从概要设计阶段开始，我方派出了三名高级程序员，分别参与储蓄对公、信贷、联行子系统的设计，继而参与详细设计、编码实现，也为后来的维护作准备。
3、减少开发人员之间的通讯障碍，提高生产率 减少开发人员之间的通讯障碍，提高生产率为了确保项目的如期完成，我们事先规定了文档编写规范、命名规范，重视文档的编写、保管等工作。重视文档与设计的一致性，先修改文档，再修改程序，不至于因为文档与设计的不一致而影响工期，对跨越里程碑的文档修改设置严格评审。为了减少开发人员之间的通讯障碍，还启用了Notes系统，开发人员可以通过内部Mail进行交流，及时沟通，减少误解。
4、跟踪和控制项目计划的执行
跟踪和控制项目计划的执行。为确保本项目的如期完成，在项目开始后，我们定期召开各组长会议，让组长们报告各自小组的进展情况及遇到的问题。通过交流开发过程中遇到的问题，共同探讨解决方法。我对照计划，跟踪实际执行情况，如果项目进展顺利，在预算范围内，我会适当放松一些控制；但只要一有问题，我会尽可能帮助排解。例如，在编码及单元测试时，因为时间比较紧，尤其信贷组，按揭贷款和跨社多头贷款控制的编码过程中遇到些阻挠，测试也不够充分，加之个别人员流动，我只好调整计划，适当调整人员，还让信贷组开发人员加班加点。有时我也找个别开发人员交谈，以了解他们对开发进展情况的评价，以及他们个人遇到的一些问题。尽我所能帮他们解决问题。
在本项目的开发过程中，所有由于以上采取了以上的技术和方法，在很大程度上保证了项
35
系统分析师论文案例集PDF
