目的如期交付（一期项目按计划已于2002年年底交付并投入运行）。其中采用PERT计划评审技术，标识各阶段的关键任务，允许一些任务的并行执行是比较成功的，划分的储蓄对公、信贷、联行三个组在详细设计与编码阶段的并行执行，缩短了整个项目的开发周期。重视文档的编写，效果也比较好，内部Notes的启用减少了通讯障碍，提高了生产率。安排本系统员工的积极参与也是成功的一面，参与过需求分析和确认测试的我方人员在系统上点过程中对培训辅导帮助很大，而参与概要设计起各阶段任务的三名高级程序员更为系统投入运行后的维护提供了方便。一方面，这些人员参与了从概要设计阶段起的各个阶段，熟悉了整个的实现过程；另一方面，这些员工熟悉业务，在后来的改正性、完善性维护方面起了很大的作用。
但是对人员的流动把握不足，尤其对乙方人员的流动更显得无可奈何。很大程度上带走了经验，也影响了进度。同时，也没有充分考虑到本系统内参与设计人员的流动。项目初期，本想增加候补人员的，但考虑到那样做还得培训，同时也增加通讯、交流的时间，担心反而会影响进度，所以未安排充分的候补人员。致使人员离去时只好再作调整，显得有些被动。所以对于人员的流动，现已作为一项约束，限制人员流动率不得高于某个百分点而在二期的开发合同中明确规定，相信会带来好处。
另外，在项目设计过程中未充分考虑代码的复用，复用程度比较低，三个组间复用的只是本项目公用的如记帐部分等，还有就是各自组内的代码积蓄了。开发效率比较低，也正因如此，不但延长了编码时间，而且还必须加强测试。如果能加大复用力度，在保证项目的进度和系统的质量方面会更完善些。
论软件过程的改进
摘要：
2001年8月，我参加了公司一个对原有产品进行升级的项目，担任项目经理一职。这个项目是在原有的产品上进行升级，系统架构由二层改为三层，并在功能上对原有系统进行扩充。同时考虑到以前我们做开发时，软件过程不规范，原有系统在设计、开发、维护、实施上存在一些弊端，开发出来的软件总存在这样那样的问题。我们在这个项目进行过程中，对软件过程进行了改进。以前我们做开发时，软件过程不规范，开发出来的软件总存在这样那样的问题，在这个项目里，我们努力做好项目规划、加强版本控制，采取了一些质量控制手段，如同行评审、专家评审、加强测试等，使软件的质量得到保证，同时也降低了开发成本。现在看来，这个项目在一定程度上是取得了成功，但还是存在一些问题，如采用工具方面，过程改进制度化方面，过程标准化与工程进度方面的矛盾等都有不如意的地方，后来公司都对这些问题有所认识，也在不断地进行改进，公司的软件过程已日渐成熟，并于去年顺利地通过了CMM3认证。 正文：
软件过程的改进是一项需要长期不断地进行下去的工作。以我们公司来说，做为一家软件公司，过去对软件的开发过程并不重视，接到项目后首先考虑的是如何用尽量短的时间来完成，而忽略了软件的质量，结果也往往是欲速则不达，甚至因为产品的不成熟使工期一拖再拖。 在2001年8月，我们要对公司原有的《城镇职工基本医疗保险》产品进行升级。这个产品是为了配合国家的公费医疗制改革，由公费医疗改为基本医疗保险而开发的。产品由各地劳动部门下属的医疗保险管理中心组织建设，中心机房设在医保中心，通过城域网连接到各定点医疗机构（医院和药店），参保职工可持医保卡在定点医疗机构直接消费，由医疗机构为病人垫付费用，事后再与医保中心结算。原产品为两层C/S结构，各定点医疗机构的前台为脱机消费，定时传送数据。这次产品升级首先将系统架构由原来的两层C/S升级为三层C/S，中间层采用比较流行的Weblogic或SilverStream做应用服务器，用J2EE实现业务逻辑，并采用标准的程序接口与各前台程序连接，以方便与第三方软件与我们的系统集成。网
36
络传输也由原来的定时传送改为实时连接，软件功能上也需要突破由于原产品设计时没考虑周全而带来的限制，如原系统为实现脱机消费，采用了IC卡带金方式，但系统设计时没有考虑到IC卡本身可能存在质量问题，而经常发生医保个人帐户透支问题，在新系统中我们就采用了个人帐户在医保中心统一管理，IC卡只是作为一个身份识别的工具来解决这个问题。因此在项目起动时，对这个产品的定位就是一个全新的产品，而不是对原有产品进行修改。在这个项目里,我担任了项目经理一职。
1、做好项目规划 在项目的规划阶段，我们意识到公司原有的软件过程存在很大的弊端，首先，原来的软件过程中，设计与开发职责不分，甚至存在分析、设计、开发、测试全由一个人承担的做法，这样做不但是对人力资源的浪费，同时软件质量也得不到保证。开发和测试由一人承担，不利于测试出软件中存在的错误，整个过程由一个人来做，做出来的软件究竟对不对，没有一个说法，只有到最后程序拿给用户去用时问题才能暴露出来。再者在这样的过程中，开发人员往往会忽略文档的重要性，这对后期的维护也会带来一些问题。针对这一点，我们首先将项目组分为设计、开发、测试三个组，设计和开发组由系统总设计师负责，测试组有一个专门的组长。设计组负责软件的分析和设计，形成设计文档，设计文档首先要做同行评审，评审内容一般是文档的规范性以及对开发人员的指导性方面，同行评审后由系统总设计师来做专家评审，评审的内容是设计是否符合业务需求。开发组负责根据设计人员的设计文档编写出代码，代码编写出来后要通过同行评审，评审内容是代码的编写是否符合编码规范、是否具有可读性和可维护性。测试组负责根据需求和设计文档编写测试用例，并对开发出来的代码进行测试。通过这样的改进，我们充分调动了各员工的积极性，也明确了各自的责任，使得整个过程处于受控状态。
2、加强版本控制
在原来的软件过程中，我们对软件的版本控制不严密，没有采用必要的工具，而是完全由版本控制员手工进行操作，且版本控制员还要兼一部分开发任务。在这种情况下，版本控制经常出问题，有时同一代码被不同的人员同时修改，有时将本应发给甲用户的程序发给了乙用户，又或者开发人员自以为自已手上的代码是最新的，而出现已改过的BUG又重复出现的现象。这样做的另一个问题是版本的历史很难追踪，由什么人在什么时候做了什么样的修改完全没法掌握。在这个项目里，我们意识到这一点，首先，设立了专门的版本控制人员，同时使用了ClearCase版本控制软件，所有对文档和代码的修改必须先从版本控制服务器上Check Out，改完后再Check In。这样做就杜绝了版本的覆盖问题，而且版本历史也是一目了然，任何修改都会形成日志，这也为问题责任的追究提供了依据。
3、加强测试工作
在这个项目里，我们特别加强了测试人员的作用。在这之前，公司也设立过测试部，但由于存在部门之间的沟通问题，测试部很难参与到项目中来，即使参与进来也发挥不了应有的作用，测试部曾一度被撒消。这一次参与测试的是新成立的测试部，而测试人员加入到项目组，业务上测试组是受项目经理领导，人事上仍受测试部领导并考核。这样做，首先消除了测试与开发之间的沟通隔阂，而测试人员也少了其他项目的打扰，可以专心只为一个项目做测试。而以前出现的因部门间隔不让测试人员参与直接由开发人员自已测试的情况也就不存在了。
由于以前的软件过程存成那么多的问题，使我们的产品不是一个成熟的产品，不成熟的产品后期施工的成本是很高的，因为存在太多的问题，维护人员要做大量的维护，而前期开发并没有留下什么文档，也给后期的维护带来很多困难，维护人员每修改一段代码首先需要读懂原来的程序，往往读不懂时就直接在原来的程序上加上一段通过设置条件来跳过原来的代码，这样使得程序越来越难读懂，问题也越改越多。这样的产品拿到一个点去施工时往往需要二个月甚至更长的时间。在这次的升级中，由于采用了较好的软件过程，产品的成熟度得到了很大的提高，而设计文档也是我们这一次重点控制的对象。这样的产品为后期的施工提供了很好的条件，现在，产品在一个点的实施时间可以缩短到四十天以内，大大地减少了施工成本。
而好的设计文档也为产品的本地化修改提供了好的条件，维护人员读懂设计文档比读懂程
37
序要容易得多，在这样的基础上做修改出现的问题也越来越少。
尽管在这个项目里我们做了这么多的改进，但也存在不少的问题，首先我们使用的ClearCase版本控制软件存在问题，这个软件要求所有开发人员将自已的机器加入到由服务器控制的域里，否则，就只能取到版本快照而不能进行版本更新。由于这样做，域管理员具有比本机超级用户更高的权力来控制每台机器，使得开发人员不愿意这样做，于是出现了多人用服务器超级用户远程控制服务器来取版本的现象，使得版本的责任追究出现问题。而我们使用的ClearCase版本不支持Windows XP，也使这个版本控制软件的使用出现了问题。
另外，我们的软件过程制度化方面也没做好，在项目的早期，各项工作流程都被很好的执行，各种文档也非常完整。由于我们这一次的升级只是针对的整个产品的一个部分进行的，在这之后我们又对这个产品进行了一次更大的升级，使得我们的产品能覆盖更大的范围。但后面的这次升级由于规模比这一次大，人员也大量的增加了。而新加入进来的人员并没有很好地进行规范培训，好的软件过程标准也没有形成有效的制度，再加上项目工期非常紧，包括同行评审、专家评审这样的流程都开始有些流于形式甚至被忽略。开发组编码时也没有完全按制定的规范进行。因此，产品质量上就出来了一些反复。我们这个产品是个可分可合的产品。因些在后来的产品实施上出现了这样一种情况：如果一个点只实施前一次升级的那部分，施工难度很小，能在短期内完工，本地化开发工作也很好完成。而要全面实施整个产品的话，工期就会被拖得很长，本地化开发工作也存在很大的问题。
针对出现的这种情况，我们公司意识到了软件过程改进的重要性，针对版本控制软件问题，我们改用了功能虽然没有ClearCase强，但更适合于我们的VSS。而在制度化方面，更是下了大力气，从印度请来了专家为我们的改进做参谋，现在公司的情况已有很大改观，各项制度已不再流于形式，而公司更是在并在去年年底顺利地通过了CMM3的认证。软件过程改进的路还很长，但有一点是不变的，只有通过软件过程的改进，我们的产品才能不断地走向成熟。也只有产品成熟了，我们才能在竞争中永远立于不败之地。
应用CMM改进银行软件过程
摘要
我在某银行软件开发科室工作，长期从事商业银行中间业务应用的开发。在以往的中间业务产品开发过程中，存在许需求不明确；开发人员有章不循，依靠个人智慧，开发处于低水平的重复状态；项目的进度、质量难以保证等问题。
我们从2001年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论证，我们提出了要开发一套具有良好扩展性、通用的中间业务平台系统。为了避免在新平台的开发过程中继续出现上述问题，作为该项目的主要负责人，我在中间业务开发团队引入ＣＭＭ，采取了一些有效的策略和方法，主要包括：进行CMM培训和咨询工作；重新制定中间业务开发规范；做好需求管理；加强过程的跟踪和监督等。我们成功实施了银行中间业务软件过程的改进，开发了高质量的中间业务平台。CMM是全面持续的过程改进，笔者从定量过程管理和人员组织管理方面，提出了今后的努力方向。 正文
中间业务是指银行利用自己的网点、设备、网络、信息等优势，以中间人的身份接受客户委托，提供各类金融服务并收取相应手续费的业务。作为银行业务新的利润增长点及重要的吸收存款手段，中间业务正日益受到国内各商业银行的重视。近年来，我所在银行根据业务发展的需要，通过陆续推出代发工资、代收电话费、代收水电费、代收学费、行政事业代收费等一系列代收代付的中间业务，在提高自身服务水平的同时，增强了在同业中的竞争能力。 一、中间业务开发过程中存在的问题
随着中间业务品种的增多和市场对中间业务要求的提高，中间业务系统越来越庞大与复杂，尽管我们中间业务开发团队不乏技术过硬的开发人员，还是经常出现项目不能按时完成；新的中间业务项目上线时，软件质量不理想，其中包括一些明显的错误，如客户不能交费、重复扣
38
或少扣客户的费用，客户交费后打印不了发票等；而且文档不齐全，造成维护比较困难。作为中间业务开发团队的主要负责人，我召集了几名技术骨干总结了以往的经验教训，找出了存在的一些主要问题：
1、随意性决策较多。往往软件产品从立项阶段开始就成了“实验田”——软件产品做与不做，什么时候交付等多是凭个人的主观意愿，没有参考以往经验，也没有充分考虑资源的有效投入，导致开发的产品维护成本较高，“打补丁”现象较多，用户使用不方便。
2、有章不循。尽管我们科技部门比较注重规章制度的建设，也针对软件开发过程制定了大量的程序性文件，但由于没有严格的后续跟踪与监督机制，使软件开发的质量控制大打折扣。 3、依赖个人智慧。我们开发团队中不乏一些具有相当才干的项目经理和骨干人员，他们为研发银行软件产品做出了较大贡献。然而，由于他们的经验没有被很好地总结、归纳，并上升为整个开发团队的财富，致使有的项目负责人一走，开发质量就会下降，这说明软件产品的研发依赖于个人而不是整个开发团队。
4、“可视性”低。软件开发过程不透明，上级不了解下面在做什么，无法实时监控项目进展；下面的开发人员“报喜不报忧”。由此导致产品缺陷被慢慢积累起来，等看到结果为时已晚。
二、应用CMM改进中间业务平台开发过程
由于传统的中间业务系统产品开发平台多样化、缺少统一规范、产品分散、功能不足，大大影响了开发效率和增加了维护难度。为解决传统中间业务开发模式存在的诸多弊端，我们从2001年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论证，我们提出了要开发一套具有良好扩展性、通用的中间业务平台系统。为了避免在新平台的开发过程中继续出现上述问题，作为该项目的主要负责人，我考虑在中间业务开发团队引入ＣＭＭ，试图把个人的脑力劳动规范为有纪律的智力产品。
1、培训与开发过程规范的制定
在项目启动前，我们请了一家知名的培训机构，培训了CMM的基础理论，并结合一些软件开发公司实施CMM的案例讲解，促进了团队成员对CMM的认识和对软件过程实行规范管理的理解和支持。然后，我们分析开发部已有的规章制度存在的问题和缺陷，重新制定了中间业务开发规范。
首先定义出软件开发中的主要过程，参考CMM并针对中间业务开发的实际需要，确定了每个过程的具体工作内容。
其次确定了软件开发的具体方法，我们确立了面向对象的开发方法，并对每个开发过程定义了相应的具体文档，如系统计划阶段必须提交《系统开发计划》，需求分析阶段必须提交《软件需求规格说明书》。并定义了文档的格式和必须提交的内容。 最后，对每个过程划分相应的人员职责，即按照工作要求，进行人员分工，并确定具体的工作内容。
2、努力做好需求管理
在银行的软件研发过程中，需求管理是一个“老大难”问题。技术部门抱怨业务部门提出的需求不清晰，甚至提不出需求；业务部门抱怨技术部门对需求理解有偏差，开发的产品与初衷相去甚远。从ＣＭＭ的角度来说，业务部门提出的需求只是顾客需求，而在顾客需求中既有技术层面，也有非技术层面的，即便是技术层面的需求，也并非面面俱到都要开发，比如一些技术上不可行或者资源要求不能满足的需求就必须剔除。只有适合软件产品研发的需求才会被最终制作成规格说明。
在中间业务平台需求的制定过程中，我采取了以下措施： （1）组成业务部门与技术部门共同参与的需求组，需求提出后经过上级领导的评审和业务部门确认才实施开发。
39
（2）制定技术部门必须和业务部门商定需求变更流程和跟踪监督的机制，需求变更如何提出、由谁进行评审、由谁决定做与不做、对项目进度及对资源的影响如何等都应事先考虑。
3、加强过程的跟踪和监控
软件开发过程中，我们按照软件开发过程规范严格实施。在项目启动的初期，开发人员要花很大一部分时间写文档资料，工作压力比以前大多了，工作流程的改变，也导致一段时间内效率降低。大家逐渐习惯后，感觉文档是研发人员劳动成果最好的记录，工作比以前清晰，规范的文档减少了对某个人的依赖，使软件研发过程的上下环节紧密衔接。在整个过程中，我们得到所有的文档，并根据文档的内容对每个过程进行了检查。在进度控制方面，我首先制定了系统开发计划，要求开发人员填写工作量周报，并据此绘制项目进度图，随时了解项目进展，并适当调配人手，整个项目比计划略早完成。
在质量保证方面，银行软件产品质量对业务的开展尤为重要，它涉及银行的资金安全和自身信誉，因此必须确保软件开发产品质量。现在我国各银行并没有成立单独的质量保证机构，对质量的控制主要掌握在项目研发人员手中，为此ＣＭＭ建议成立专门的ＳＱＡ组，检查软件开发过程标准、规程的合理性。鉴于人手问题，我们没有成立专门的SQA小组，采用测试小组兼做SQA工作，对项目组的监督“对事不对人”，并定期公布监督结果。
三、经验和不足之处
经过近一年工作，我们完成了中间业务平台的开发，新的中间业务平台运行良好，受到了业务部门和技术部门高层的赞许。在该项目的开发中，由于引进了CMM，加强了软件过程管理，很好地解决了以前存在的四个问题。中间业务产品的开发目标更明确，提高了产品开发过程的可视性和可控性，从而在提高产品开发能力的同时提高了产品的质量；我的开发管理水平也得到了很大的提升。高层领导尤其对我们的开发流程和开发规范表示认可，并决定在整个开发部门推广。我将这次软件过程改进的成功实践归功于两个原因：一是基于我们长期中间业务开发的基础上总结出来的经验和教训，二是CMM原则与我们团队和项目本身的特点的有效结合。
然而，由于我们初次应用CMM，还有许多需要改进的地方：
1、我们仅运用了CMM的基本原则，整个软件过程的管理基本是定性的。过程改进的趋势是定量管理，必须采用合适的工具，如采用项目管理工具MS PROJECT控制项目进度，使用RATIONAL ROSE对需求分析和系统设计进行辅助设计，可预测和监控整个过程性能和产品质量，及时纠正偏差。
2、鉴于人手的问题，我们团队成员往往身兼设计、开发、测试、SQA数职，组织结构不合理、人员分工不清显然制约过程改进的实施，我们最近打算成立一个独立于开发部的质量控制部，分清设计、测试和质量保证的责任、界限和权限，使其在更高的层次上控制软件质量。 软件过程的改进是一个很大的课题和实践方向，在今后的工作中，我们将争取向CMM更高的级别努力。
论软件开发平台的选择与应用
摘要：
我校教务管理系统是在根据我校原来的教务管理系统不再适应现在发展的要求而立项开发的。目的是为教务工作有关部门提供优质、高效的业务管理和事务处理，建立完备、可靠和开放性的教务管理系统。
我有幸参加了新的教务管理系统的开发，担任项目管理、系统分析与设计等工作。本文结合工作的实际经历，简要讨论了软件开发平台的选择与应用。在软件开发平台的选择与应用过程中，我们本着平台的开放性、分布性和平台无关性的原则，根据我校的具体情况，通过对目前两种主流平台：J2EE和.NET的比较分析，和体系结构、应用平台的无缝集成、开发成本及易开发性的思考与研究，选择了.NET作为开发平台。使用Microsoft全新的集成开发环境Visual Studo.NET，采用ASP.NET、Web Service、ADO.NET和XML等技术进行系统开发。
40
系统分析师论文案例集PDF
