软件项目管理的理论与实践

软件项目管理的理论与实践（精选8篇）

软件项目管理的理论与实践 篇1

软件项目管理的理论与实践

摘要：本文在探讨CMM/CMMI、敏捷编程等相关理论的基础上，结合软件开发实践，提出了平衡敏捷与纪律的软件管理思想，并探讨了融合敏捷与CMM/CMMI的最佳实践。

关键词：CMM/CMMI，敏捷 当CMM遭遇敏捷

本世纪初，在国务院18号文件《鼓励软件产业和集成电路产业发展的若干政策》的推动，以及鼎新、东软等先驱软件企业的带动下，国内掀起了一阵CMM风暴（CMM于2000年升级为CMMI，文中在不特别针对某个具体版本时，使用CMM泛指CMM/CMMI），软件企业的CMM/CMMI评估形成了一股席卷全国的潮流。据CSDN统计，截止到2010年9月，我国通过CMM/CMMI评估的企业已达到1300家，全球排名第二。一时之间，CMM似乎成为了衡量软件企业开发能力的唯一标准，成了发展我国信息技术行业的银弹。然而，自2005年开始，一些有识之士就已经认识到CMM的局限性，纷纷撰文提出质疑。目前，随着越来越多软件企业CMM神话的破灭，CMM已经完全走下神坛。现在打开百度，搜索CMM的相关内容，除去概念、介绍性的文章外，对其持否定态度占了绝大部分，继续力挺CMM的文章几乎绝迹。由此可见，中国的软件界已经从CMM的狂热阶段转入理性阶段。

在CMM由盛转衰的同时，以强调人本、效率为核心的敏捷思想开始悄然兴起。从Kent Beck的极限编程（eXtreme Programing，简称XP）和敏捷联盟的敏捷宣言中，中国程序员开始听到CMM外的声音。而随着Martin Fowler、Robert Martin等敏捷大师登陆中国，数届敏捷大会在北京召开，整个中国软件界掀起了一股以务实、高效、简约为特征的敏捷风。目前，软件行业的媒体、杂志上，充斥着介绍XP、Scrum等敏捷方法的专题文章，秉承敏捷思想进行管理的软件企业随处可见，敏捷成了过程改进的最热门话题。

面对CMM的盛极而衰和敏捷的方兴未艾，我们不禁要问：CMM到底怎么了？敏捷真的适合我们吗？我们该何去何从？ CMM怎么了

我第一次接触CMM是2000年。在此之前，我一直试图寻找一套软件开发标准，曾经学习过GB 85-88和IEEE-830、IEEE-12207等软件工程标准，但一知半解，远没有形成一个系统化过程的概念。CMM的丰富、广博确实让我眼前一亮，好象打开了一面通向世界软件技术的窗户，看到了从未想象过的世界。但是，CMM那些繁复的规定和要求，又让我望而却步，“可远观而不可亵玩焉”。2002年，在信产部政策的推动下，各地方政府纷纷出台了奖励政策，稍具规模的软件公司，都在跃跃欲试地准备CMM评估，CMM才真正走到我们面前，虽然当时还不完全了解CMM到底能带给我们什么。

其后几年，CMM/CMMI成了我工作的一部分，我对它有了更深刻的了解。可以说，CMM是中国软件行业规范化的启蒙者。CMMI-DEV 1.2的22个PA、48个特定目标、165个特殊实践，覆盖到了软件开发和管理的方方面面，让我们真正了解到什么是软件管理。每个职业软件人，无论是开发者还是管理者，都有必要了解、掌握这些内容。作为一个指导软件企业过程改进的框架，CMMI提供了阶段型和连续型两种方法论，并通过5个通用目标、17个通用实践，清晰地描绘了一条软件企业走向成熟的路线。比如CMMI-DEV 1.2 Ⅱ级的目标，就是“管起来”，无论你用什么方法，只要把计划、度量、需求、配置、质量保证等内容管起来，就认为是达到了Ⅱ级。当Ⅱ级积累到一定程度，认为各项目间有必要共享各自的经验的时候，就可以向Ⅲ迈进了。遗憾的是，我们在引进CMM的过程中，犯了急功近利的毛病，囫囵吞枣，没有真正按照框架的精神踏踏实实地进行过程改进，导致了CMM的水土不服。究其原因，我觉得问题应该出在以下几个方面：

1.CMM的移植问题。CMM起源于美国国防部和国家宇航局，所针对的都是大型项目。这些项目失败的成本巨大，对软件质量要求非常之高，因此，对过程的精细程度要求非常之高。在制定模型时，为了做到方法的完备性，所制定的过程框架又涵盖了各种情形，使过程模型更加复杂化。在移植到中国后，由于评估时间等的压力，我们并没有充分地消化CMM的精髓，没有考虑我们企业所能承受的成本，没有根据项目的实际情况进行有效裁剪，而是僵化地全套照搬，建立了过于复杂的管理流程，形成了大量面面俱到却无人问津的过程制品，反倒失去了对项目核心的掌控，导致生产效率降低，产品质量下降。而过程改进人员又普遍脱离了开发实践，CMM成了教条，使开发人员产生了反感情绪。

2.CMM缺少工程方法。CMM是一个能力标准，只讲要做什么，却没讲怎么做。例如CMMI-DEV 1.2 Ⅱ级的7个PA，全部是项目管理的内容，基本未提及工程方法。CMMI-DEV 1.2 Ⅲ的11个PA，虽然涉及到RD、TS、PI等技术领域的内容，但只提了宏观要求，并未涉及细节。这种设计方式，是因为CMM的创建者假定软件企业已经具备了适合本企业的、完整有效的软件工程方法论。我国企业在引进CMM前，基本上还没有形成自己的软件过程和文档体系，而是寄希望于CMM来改善这种情况。在CMM实施中，又普遍存在重管理轻技术的观点，忽视了企业资产的建立，通常是照办咨询公司提供的模板，没有进行有效的本地化，没有认真探索适合自身的工程方法，从而导致管理先进、技术落伍的不良状态，也从根本上违背了CMM“过程改进”的基本思想。

3.CMM不适合小型项目。CMM起点很高，对各个环节要求极严，是真正的重量级方法。对周期短、回报小、资源不足的小型项目来说，使用CMM的成本太高，可以说是得不偿失。这一点，在CMM刚刚进入中国时，SEI的专家们曾反复声明，CMM的创始人Watts Humphrey老先生也一再强调。在CMM之后，Humphrey先生又建立了用于小规模团队的TSP（Team Software Process）模型和用于个人的PSP（Personal Software Process）模型，作为CMM的补充。在为波音公司的IT部门进行CMM咨询时，Humphrey先生根据各部门的实际情况，分别制定了实施CMM Ⅲ、CMM Ⅱ、TSP、PSP的不同方案。由此可见，CMM并不是放诸四海而皆准的银弹，无论是公司还是项目，选择CMM，都应该根据自己的实际情况进行理性的选择，而不应该生搬硬套，以命令的形式强制推行。反过来，如果选择了CMM，就要提供足够的资源，否则就会事与愿违，反倒降低效率，影响产品进度和质量。

4.CMM的知识更新问题。CMM初稿是在1986年提出的，87年正式发布1.0版。它的基本内容，都是基于瀑布模型设计的。按照《人件》和《最后期限》的作者Tom DeMarco的说法，“CMM 已经有超过 20 年的历史，它的成功经验都是在 1985 年前获得的。CMM 试图将一个固定的模型强加于一个日新月异的行业之上，它鼓励你效仿 IBM 在 1970 年代所采用的软件开发方式。僵化，不敢面对变化，这是如今的软件业最忌讳的。”2006年8月发布的CMMI-DEV 1.2版本，开始寻求对这一局限进行突破，但是进展甚微。例如，目前迭代式开发已经被公认是先进的开发组织模式，可以有效应对变化。而CMM在某些方面却限制了迭代的应用。比如里程碑式的需求评审、设计评审，就是典型的瀑布模型的影响，与迭代方法中随着开发的深入逐步获取需求的思路完全矛盾，造成了两者的冲突，客观上限制了基于迭代的新式工程模型的应用。

5.实施过程中理论和实际的脱离。国内的CMM实施，最头疼的就是找不到合适的SEPG和QA人选。按照CMM的思想，SEPG和QA应该来自具有丰富开发经验的技术人员，能在开发过程中得到软件人员的尊重，并给予全方位的指导，从而得到客观的洞察力。而我们的软件企业通常比较年轻，人才积累少，SEPG和QA的软件经验普遍不足，兼之过于追求理论上的完美，不注重跟踪过程执行情况，不注重收集反馈信息，导致我们的流程、制度脱离开发实际，引起开发人员反感。正如软件界泰斗Boehm博士所说的那样，“过程改进黑暗面的诱惑力是巨大的，实施者们很容易受其诱惑而陷入只追求表面文章的黑暗面之中”。这样的过程改进只注重满足标准，片面追求过程与规范的符合度，脱离了软件开发实践，忽略了实践对理论的验证、反馈，违背了过程改进的初衷，偏离了提高效率、提高软件质量的根本目标。敏捷的特征

以CMM为代表的传统意义上的软件方法学描述，通常“能够”处理任何大小的项目，而实际上真正的困难就来自于如何对这些方法加以裁剪以适合较小的项目。针对这种理论与实际的脱节现象，敏捷方法应运而生。相对于CMM这样的重量级方法，敏捷方法常被认为是“轻量级”方法。敏捷的倡导者认为，软件产品开发无法一开始就能定义产品最终的规程，开发过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。开发团队应有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

相对于传统方法，敏捷方法更重视“人”在软件研发中的作用，重视效率，重视对变化的积极响应，倡导迭代式开发，反对机械地盲从既有过程，反对面面俱到、堆积如山却无人问津的文档。自1996年敏捷先驱Kent Beck提出极限编程思想后，敏捷方法得到了广泛响应，敏捷爱好者于2001年成立了敏捷联盟，并发表了敏捷宣言：

 注重个人及互动 胜于 过程和工具  注重可用的软件 胜于 详尽的文档  注重客户协作 胜于 合同谈判  注重响应变化 胜于 恪守计划

2002年后，敏捷方法得到了迅猛发展。其中影响至深、波及至广的当属极限编程（XP）和Scrum方法。

极限编程是敏捷理论的先驱，“极限”的含义是将在开发中总结的最佳实践发挥到极至。例如，如果你认为迭代是好的，那么就将迭代的周期压缩至最小，甚至几天、几小时一次迭代。严格来说，极限编程并不是一套完整的方法论，而是一组核心理念和一套最佳实践的组合。XP倡导沟通、反馈、简单、勇气四个核心价值观，主张项目的设计、结构要保持简单，要注重沟通和用户反馈，要有勇气接受变化、重构代码。XP提出了项目计划（The planning game）、小版本（Small releases）、隐喻（Metaphor）、简单的设计（Simple design）、重构（Refactoring）、测试驱动（Test-driven）、结对编程（Pair programming）、代码共享（Collective ownership）、持续集成（Continuous integration）、不加班（40-hour week）、现场客户（On-site customer）、编码标准（Coding standards）等十二个核心实践，其中重构、测试驱动、小版本（迭代）、持续集成等实践已经成了敏捷思想的核心，被现代软件工程理论广泛接受。XP作为敏捷方法的先驱，最大贡献是为敏捷方法提供了大量基础实践。它的基本思想被各种敏捷方法广泛接受、继承，为敏捷的盛行奠定了基础。

Scrum方法的名字取源于英式橄榄球争球队，其用意就是要把体育比赛中那种团结、拼搏的精神施加于软件团队。和XP相比，Scrum提供了更具体的工程管理机制，从而使Scrum的可操作性更强。这也是近年来Scrum方法盛行的原因。Scrum方法的核心，是将开发过程分解为一系列小的迭代，每次迭代称为一个Sprint（冲刺）。每个Sprint通过计划会议明确任务，通过每日例会掌控进度、问题，通过评审会议总结成果。如此反复，经过一系列可控的“冲刺”，最终达成项目目标。其基本流程描述如下：

1.列举可以预知的所有任务，包括功能性和非功能性任务，形成所谓Backlog。2.将整个产品的Backlog分解成一系列Sprint Backlog，这个Sprint Backlog是按照目前的人力物力条件可以完成的。3.召开Sprint计划会议，划分、确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。Sprint的任务是以小时计算的，并不是按人天计算。

4.进入Sprint开发周期，在这个周期内，每天需要召开15分钟的每日Scrum例会。5.整个Sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner。该会议为外部会议，邀请干系人参加，一般不超过4小时。

6.团队成员最后召开Sprint retrospective meeting，总结问题和经验。该会议为内部会议，时间不超过3小时。

7.这样周而复始，按照同样的步骤进行下一次Sprint。

无论是XP还是Scrum，其基本思想都是互通的。它们所倡导的最佳实践，看似一个个独立活动，实际上具有很高的耦合度，不能孤立地执行。例如，XP的共享代码权，如果没有编码标准、结对编程作为基础，是很难实现的；小版本没有重构作为保障，会导致结构的混乱；Scrum的每日例会，要以“站立会议”的方式进行，以保证效率；Scrum的Sprint要以持续集成、重构等实践作为保证，否则无法维护产品的完整性和可靠性，等等。

敏捷以一种充满活力的方式，挑战了传统软件工程思想的沉闷，激起了全球软件人员的强烈反响。然而，任何事情都有其不利的一面，敏捷也是如此。敏捷无法管理大型项目，即使对比较适合敏捷的中小项目来说，敏捷也有自身的弱点，例如：

1.敏捷过于依靠个人素质和Team leader的领导能力，因此在团队成员较新，缺乏足够的经验、技巧和敬业精神时，敏捷会失效；

2.敏捷经常会被误解成不写文档。事实上，敏捷反对的只是面面具到、求全责备的文档和过程，而不排斥必要的文档。例如XP的12个核心实践，就提到项目计划、隐喻和简单的设计三个涉及文档的活动。敏捷只是提倡用一种更直接、更轻量、更易于理解的方式编写文档，而不是一概否定文档。

由此可见，以CMM为代表的传统方法和敏捷思想实际是事务对立统一的两个方面。传统方法强调过程、强调纪律，而敏捷方法强调个体、强调创造。如果将两种思想有机结合起来，取长补短，达到平衡，就能找出更合适的过程改进之路。平衡敏捷与规范

在敏捷与传统为谁是谁非的问题争论的不可开交的时候，一些有识之士已经在考虑两者的融合。其中比较有代表性的一位，是以创造了COCOMO模型、螺旋模型和经典名著《软件工程经济学》而闻名的Boehm博士。Boehm博士在2003年出版了《Balancing Agility an Discipline》一书，对平衡敏捷和规范的问题进行了详细的论述。该书的中文版《平衡敏捷与规范》也已经于2005年由清华大学出版社出版。可见，平衡敏捷与规范，已经是被国内外学者所认同的发展之路。敏捷与规范之争，大致可以归结为以下两个方面：

1.人与过程孰重孰轻之争，或者软件到底是“工程”还是 “艺术”之争； 2.质量尺度的把握，或者说，需要为质量付出多少成本。

人与过程之争，焦点是软件开发过程创造性的地位问题。CMM把软件开发过程看作一个工程过程，希望利用在制造业等传统行业中获得的经验来管理软件开发，对开发中的“个人英雄主义”行为持明确的否定态度，倍加推崇正确的过程、严格的工序和绝对的纪律。而敏捷方法的核心就是强调发挥个人或团队的创造性，主张按照项目特点选择过程。在敏捷专家看来，没有什么规范是固定不变的，所有过程都由人而定，都是为项目成功服务的。敏捷和规范各有所长，以CMM为代表的规范过程更适合需求明确的大型项目，而敏捷更适合具有挑战性的研究项目。

质量尺度的把握。CMM强调质量至上，不会因为效率牺牲质量。敏捷强调效率，一些敏捷方法提出了“满意质量”的概念。满意质量基于“任何事情都带来成本，而我们所想要的总是超过我们的支付能力；质量在本质上是有条件的和主观的；为了在软件方面达到完美，我们不得不解决许多困难问题、达成许多折衷和解决相互冲突的价值，完美不会很容易或机械性地实现”的基本前提，提出了满意质量的定义：（1）可带来足够的利益；（2）不存在致命性问题；（3）所带来的利益超过问题所造成的损失；（4）在当前条件下综合考虑所有因素后，进一步的改进所带来的损害大于其带来的帮助。满意质量否定了质量至上的观念，说明了敏捷思想更加务实的价值观。应该说，CMM的质量目标更适合作为一种文化或信念，而满意质量是对质量目标更理性的思考，更具有说服力和实用性。

敏捷强调个体、强调效率，但同时对个体素质要求较高，局限性较大。而CMM强调过程，强调质量，更适合于简单、重复的生产活动，很难应付复杂多变的情况。事实上，敏捷与规范正是软件开发过程中两个不可或缺的方面。过分强调自由，开发过程就会失控，回到软件危机前的“混沌”状态；而过分强调规范，又会导致僵化，扼杀人的主动性和创造力。因此，软件管理的目标，就是平衡敏捷和规范的矛盾，使开发活动高效、有序地进行。对已经通过了CMM/CMMI评估，但仍希望持续改进的软件企业，我觉得最直接的平衡方法，是用敏捷的观点重新审视既有规范，用效率观点重新评价各种管理活动，逐步剔除其僵化、低效的部分，最终达到平衡。具体方法可概括如下。

1.对项目分类进一步精细化，提供更丰富的生命周期模型，并提供与之相适应的模板和规范要求，使之能够尽量适应不同类型项目的情况。通过CMM/CMMI评估的企业所采用的流程规范，大多是继承自咨询公司提供的模板。虽然在改进过程中有适当裁减，但并未真正接受实践的检验，而且普遍不能支持新的生命周期模型。要想让规范更好地支持开发过程，帮助企业提高开发效率、产品质量，就应该不断吸纳新知识、新思想，不断建立新模型，使企业资产库不断得到扩充。另一方面，企业资产库对开发部门应该是开放的。开发人员是推动企业知识更新最积极的因素，管理人员应该积极支持、帮助、配合项目组使用创新方法、过程，认真跟踪、观察新方法的执行效果，及时总结经验教训，将新方法及时合并到企业资产库。

2.提供更灵活的裁减条件，减少不必要的中间环节，给予项目经理更多的控制权限。任何过程都有其局限性，而每个项目都有其特殊性，不可能通过机械地复制既有过程就达到复制成功的目的。这一点，SEI的专家也是认同的，CMM的Ⅱ级命名为“可重复级”，升级到CMMI时更名为“管理级”，就隐含了这个道理。软件不同于简单的生产加工活动，是一个充满挑战和创造性的工作，软件管理也不可能完全照搬企业管理的经验，而必须强调“人”，特别是项目经理在整个过程中的主导作用。给予项目经理更多的控制权限，尤其是过程裁减的权限，更有利于发挥项目经理的聪明才智，引导项目走向成功。这是敏捷思想的精髓所在。对开发过程中的管理活动，要深入分析其对具体项目的作用，才能作出是否需要的合理判断。以专家评审为例。理论上，专家评审可以集中专家的智慧，对开发活动肯定是有益的。但某些企业由于环境、业务复杂度、技术复杂度、人际关系等等原因，专家可能不愿意或没能力提供有效意见，这样评审就不能达到预期目的。如果评审成了走过场，就要引发深度思考，考虑评审所带来的收益是否大于付出的成本，并决定是否裁减评审活动了。裁减的最终决策权应该交给项目经理，而不是SEPG人员。因为项目经理要对项目总体负责，只有他最了解、最关注项目的成本、进度、质量，其它人员的意见都具有局限性、片面性。

3.管理体制要从实践中来，到实践中去。所有针对软件开发的管理活动，都是为了让开发工作更有效、更可靠、更可控，都是为开发服务的。敏捷的最大魅力，就是所有最佳实践都是来自于开发活动的，所以才会得到开发人员的广泛拥戴。因此，管理制度的制定，尤其是过程、文档模板的制定，要坚持实践是检验真理唯一标准的原则，坚持从开发实践中总结经验，积累财富。要杜绝闭门造车式的过程改进，无论多么完美的理论，都要经过实践检验后，才能验证其正确性。软件管理人员必须具备软件开发经验，并不断深入开发实践，体会规范的实际运用效果。管理规范要经过实践检验后才能形成制度，并且要考虑是否能为开发人员所接受，所增加的管理成本是否物有所值等因素。如果脱离了实际，制度就会僵化，变成阻碍开发工作的束缚，达到适得其反的目的。

4.发现问题，量体裁衣，逐步实现过程改进。罗马不是一天建成的，任何进步都要有一个普及、接受、适应的过程。CMMI 的组织过程焦点（OPF）明确地列举了组织过程改进的方法。在CMM实施阶段，由于时间的压力，企业可能没有真正按照CMM的精神来实施过程改进，急于求全、求大，或多或少地存在制度与实际两层皮的情况。要改变这种状态，应该坚持持续改进的精神，改进要按照OPF的要求，评价组织过程，发现最薄弱环节，找出最紧迫的过程改进需要，制定改进计划，实施过程改进。按照这种方式，即使每次改进仅完成一个PA，只要真正落到实处，就会取得实际的进步。如此反复，企业就会得到真正的发展。如果违背了这个规律，一味求大求全，浮于表面，过程改进可能永远是一句空话。5平衡管理与技术

在平衡敏捷与规范的讨论中，还有一个不容忽视的问题，就是平衡管理与技术的关系。软件是一个技术密集型行业，是一种纯脑力劳动，技术对于项目成功的重要性，是不庸质疑的。在CMM登陆之前，我们普遍存在重技术、轻管理的现象。CMM作为一个管理框架，重点在于强调管理，正是对片面强调技术的纠正。然而，随着CMM思想的不断深入，又难免产生矫枉过正的情况，反倒让软件企业忘记了立身之本，忽略了技术的地位，造成管理至上的错误。管理与技术孰轻孰重？如何摆正管理与技术的关系？要想平衡管理与规范，这些问题都是不可避免的。

1.软件开发活动中技术的地位问题。软件不同于传统企业，软件产品的形成过程，主要依靠人的思维活动，是看不见、摸不着的。管理的目的，是为了引导人的思维活动按正确的方式发展，但是决不能替代人的思维。有人说，产生文档的根本原因，来自于项目经理的恐慌，因为项目经理无法感知、控制软件项目的进度和质量，只能依赖文档来进行监控。如果忽视了技术、技能的培养，忽视了软件人员的素质建设，思维就失去了基础，仅仅依靠管理、纪律，是不可能获得成功的。尤其在客户要求日益复杂、技术日新月异的今天，技术的重要性越发突出。一个良好的设计思路、技术决策，往往是觉得项目成功的关键。因此，应该正确认识技术在软件活动的地位，尊重知识，尊重技术，让管理为技术服务。

2.客观分析企业的状态。管理和技术是保证项目成功的两个决定因素，不能偏废。作为企业领导，要实现过程改进，就要客观分析企业的状态，分析清楚企业现在的弱项是管理还是技术，然后再制定相关政策，而不能想当然地片面强调某一方面，加剧不平衡状态。我个人认为，在没有实施任何认证的企业，忽视管理的可能性较大；在通过了ISO9000、CMM的企业，则往往夸大了管理，忽视了技术。

3.客观分析管理和技术的分别。面对企业在开发过程中暴露出来的问题，要进行客观、深入的分析，判断是管理问题还是技术问题，再采取相应措施。比如现在普遍存在的需求失控的问题，从表面上看，是需求开发（ReqD）和管理（ReqM）的问题。但是，如果深入到问题本质，可能会发现，需求变更是不可避免的。那么，就要从架构设计和开发过程方面找问题。例如可以采用组件式开发，让软件易于适应变化；可以使用原型法，让用户尽早看到产品；或者使用迭代式开发，及时规避风险，让产品逐步接近用户目标。如果死钻牛角尖，一味在需求调研、文档、评审上下功夫，就会事倍功半，降低效率。

4.注重技术人才的培养。“盖成非常之事，必待非常之人”。两千年前的汉武帝，就已经认识到人才的重要性。正是因为具有不拘一格用人才的非凡气魄，汉武帝才能挖掘出卫青、霍去病这样的军事天才，建立不世之功。在软件行业，也不乏盖茨、裘伯军、王江民这样以一己之力获得巨大成功的先例。因此，软件研发，尤其是开拓性软件的研发，必须要有大批具有专业知识、超凡能力的“非常之人”。软件企业要具备容纳百川的胸怀，重视技术人才的挖掘、培养，提供钻研技术的环境，打造尊重技术的企业环境，造就技术过硬的拔尖人才，才能提高自身素质，建立企业的核心竞争力，在市场上保持竞争优势。结束语

前文在剖析CMM的利弊的基础上，用敏捷观点重新审视了过程改进的方法，并阐述了软件企业中管理和技术的关系。最后，我们再回顾一下敏捷宣言，权作本文的结束语吧。

 注重个人能力，注重创新，注重互动，反对僵化的过程和低效的工具  注重编写好用的软件，反对面面具到却无人问津的文档  注重客户协作，避免生硬的商务谈判

 注重适应变化，响应变化，反对墨守成规，恪守计划

软件项目管理的理论与实践 篇2

对于自动测试工具, 网上有很多技术资料, 其中不少是开发厂商推出的宣传信息, 包含了夸张水分。部分老师对软件测试自动化的讲授理论过于理想, 学生对自动化测试工具的期望往往过高。甚至有一些软件测试大赛, 就以指定的自动测试工具的操作使用作为比赛的主要评分内容, 但参赛学生抱怨TA工具本身不能解决实际问题, 引起争议。其实, 自动化测试工具本身的使用价值是很有限的, 在很多实际测试项目中不实用。对那种不稳定、开发周期很短、一次性的软件等, 自动测试TA工具往往不适合。自动测试工具在功能测试中的价值是回归测试, 自动工具不能灵活发现更多的新问题。教学中需提醒学生对网上一些相关资料辩证地理解。

2 不少教材过于理论化

很多测试工程师认为当前不少软件测试教材过于偏重理论, 教材中包含了一些不实用的甚至与实践脱节的理论, 尤其是一些只适合特定类型项目的测试技术理论被不分适用条件地讲述。比如我们看到很多教材中强调“软件测试占软件开发总工作量的40%、总成本的30%~50%”, 其实这句话只符合部分项目的特点, 与实践中的多数项目情况不符, 真实的测试项目实践需要考虑质量、工期、成本等多方面的约束。又比如一些老师过于推崇白盒测试而轻视黑盒测试, 但事实上实践中很多真实测试项目中主要采用黑盒测试方法, 甚至一些专职的测试工程师工作多年几乎不用白盒测试方法 (白盒测试方法对于程序员自测较多采用) , 白盒测试方法在功能测试、系统测试中等几乎不用。笔者通过对数十个高校在校学生的软件测试的课程设计文档的观察, 发现在学校中测试文档的写作容易走形式, 普遍理论空洞、实用性差。这些过于偏重理论的教材容易降低学生学习的兴趣, 更容易误导学生的实践。没有有效地与实际项目结合, 导致学生学习主要为了考试分数, 而毕业找工作时才发现没有真正的软件测试能力。

3 对于微软的经验理论没有强调实践中的适用条件

通过对常用教材分析, 发现很多教材偏重于微软的技术理论和经验, 偏重于基于瀑布模型的开发过程的测试, 微软的技术主要针对通用型软件, 不一定适用于不同特点的具体项目。

而实践中实际项目复杂多样, 通用型软件项目只占少数, 多数属于需求定制型。很多开发过程本身没有采用瀑布模型, 无法采用被教材重点推广的V模型等。这就要求学生对微软技术的适用条件辩证地理解。

4 一些概念没有经过行业统一规范

软件测试课程发展时间短, 课本中的一些概念没有统一行业规范。比如功能测试的范围比较模糊, 有的教材中把安装测试、兼容测试、界面测试等都划归到功能测试中, 但有的教材把它们从功能测试中独立出来;性能测试概念的外延也百家争鸣, 有的认为它是一个大概念与功能测试并列, 但有的把它定义为和压力测试互不包含;在V模型中软件过程质量保证与软件测试岗位的工作范畴是基本相同的, 而普通软件公司中两者有明显的区别, 前者是管理岗位, 后者仅是技术岗位、主要是事后检查 (不包括需求分析、总体设计、详细设计等的审查) ;很多教材把检查代码是否符合规范作为单元测试的工作内容之一, 但在很多开发公司中检查代码是否符合规范不属于测试岗位工作内容。在软件测试技术中, 像这样的概念术语模糊的现象还较多, 容易导致学生在实践中的混乱、困惑。建议相关部门尽快给出审慎的规范。

5 一些集成测试过程理论的适用性存在问题

教材中经典的渐增集成测试方法包括自顶向下、自底向上、三明治方式等, 这几种集成测试方法理论上虽较为严谨, 但其测试过程没有考虑与开发过程的关联协调。实际项目中往往不允许这几种渐增集成测试方法的实施。开发人员往往希望已完成的模块在单元测试 (开发人员自测) 之后及早参与集成测试, 并且给测试的实施时间很短。这就要求渐增集成测试的过程要和实际的开发动态进展协调起来。如果采用书本上的自顶向下集成测试方法, 需要先集成顶层的模块, 测试它们与所驱动的模块之间的交互接口关系, 但其它非顶层模块可能先于这个顶层模块完成, 却要等到顶层模块集成测试完成之后才能被集成测试, 这显然是这些渐增集成测试方法的使用障碍。方法虽好但有苛刻的适用条件, 但绝大多数教材并不涉及这些方法的适用条件, 容易误导学生实践中生搬硬套。

6 教学实践及建议

6.1 教学中加强案例教学法及项目驱动教学法

笔者从2005年开始在软件测试教学中尝试案例教学法、项目驱动教学法, 要求学生边听课边做具体测试项目, 学生分组以项目为主线、教师为实践向导、学生为实践的主体, 相对于传统的课堂教学, 深感案例教学法、项目驱动教学法显著地增强了学生软件测试技术的实践能力。按照“学习-实践-反馈-修改提高”的原理引导学生修改完善, 提高项目阶段成果的质量。通过案例教学法及项目驱动教学法, 使得理论教学与真实项目实践无缝衔接。

6.2 应对软件测试教材进行标准审查

软件测试课程体系发展时间短, 教材良莠不齐, 一些概念的定义也没有全行业规范, 尤其是概念定义的内涵外延不完全统一、多数教材中没有对不通用的技术方法的适用条件加以说明等。建议行业中加强统一规范。

6.3 教师引导学生开阔技术理论视野

比如推荐参考资料、引导网上检索信息等。还有其它方法, 比如笔者曾经建立了QQ群, 联系到北京、上海、苏州、杭州、郑州等地公司的部分专职测试人员加入QQ群, 抽出每个教学班较好的学生代表加入 (QQ群几年下来已增加到近千人, 由于QQ群人数限制, 暂不能让所有学生加入) , 也会有已经毕业的从事专职测试岗位的学生在群中提一些实践问题, 有长期工程实践经验的老师都会认真提出建议, 这样在校学生在学习过程中已经对不同商业公司测试岗位的技术情况有了较多了解, 在校的理论学习与规范公司的软件测试实践无逢衔接, 开阔了理论视野。

摘要：软件测试是一门实践性较强的课程, 针对软件测试课程教学中常见现象, 归纳了软件测试理论教学与工程实践的脱节之处。脱节之处较多, 这些理论与实践的偏差在很多高校普遍存在, 容易误导软件测试人才的培养效果。软件测试课程体系需要审慎地改革。

关键词：教学改革,软件测试,理论联系实际

参考文献

[1]刘勃, 刘玉, 钟国辉等.基于真实项目的实践教学体系探索[J].高等工程教育研究, 2012 (1) :80-83.

[2]聂长海.关于软件测试的几点思考[J].计算机科学, 2011 (02) :251-255.

[3]赵一丁, 刘凤华, 郑秋生等.仿真软件的被动测试与主动测试互补的研究[J].计算机科学, 2012 (12) :121-125.

软件项目管理的理论与实践 篇3

[关键词]软件开发；数据库；实践

1.大型软件后台的数据库的设计理论

1.1数据库设计的重要性

对于大型软件来说，其后台的数据库的建立是非常重要的，是计算机软件的核心部分。数据库设计指的就是对于指定的环境而建立一个最优的数据库模式，从而满足顾客以及开发者的各种需求。每个软件的后台都需要有其自身的数据库的运行，对于新建立的大型的软件来说，它的数据库更是非常复杂。对于软件来说，数据库管理系统主要提供的就是数据组织、操纵、维护、控制以及保护等一系列服务的系统。数据库主要就是进行数值的计算，同时还可以保护数据的安全性、完整性。同时，其自身还可以对出现的故障进行自我的修复和监控，最终保证整个软件能够正常的运行。开发软件的时候，如果数据库的设计出现问题的话，极有可能在软件运行一段时间的话造成应用的程序崩溃，对于软件后期的维护非常不利而且复杂的。由此可见，大型软件的开发过程中，后台数据库的设计是非常重要的。

1.2数据库设计的定义与特点

数据库（Database Design）是指根据用户的需求，在某一具体的数据库管理系统上，设计数据库的结构和建立数据库的过程。数据库系统需要操作系统的支持。由于大型软件开发过程中数据库更是费海沧复杂，因此，对于数据库的设计不能一蹴而就，更是需要相关的工作人员有耐心，反复探寻，逐步求精，最终完善数据库的设计为大型软件的开发做铺垫。数据库的设计尤其自身的特点。首先，数库的设计主要就是将硬件、软件以及干件相结合，干件指的就是技术与管理的界面。因此，可以数据库设计主要是三分技术，七分管理，再加上十二分的基础数据组合而成。其次，数据库的设计是与应用系统设计相结合的。还有就是数据共享性高，冗余度小，容易扩充。数据库主要就是针对顾客的需求而设计的，因此，共享度极高。数据库中的数据具有独立性。数据库中的数据是独立于使用的数据程序的。

1.3数据库设计的原则方法

对于大型软件的开发而言，数据库的设计非常复杂，但也会遵循一定的原则。首先，就是需要遵循其命名的规范化。在数据库设计过程中，不同的产品对应不同的命名，在对该对象进行编程的时候，代码上都应该采用大小写的字幕形式来进行命名，同时命名的长度也有要求，不能超过三十个字符。其次，就是对游标的使用要谨慎使用。对于一些大的数据集合而言，如果设计的时候使用游标来进行遍历数据时极易导致程序进入到一种漫长的等待甚至死机的状态。如果必须要使用游标的时候，可以首先建立一个临时的表，在表格中输入制定的数据，然后进行游标操作，从而提高有标的性能。除此之外，索引的使用也是有原则的。索引可以快速、准确的访问表中的数据。一般的，数据库有两种索引，一种是簇索引，并一种就是非簇索引，不论使用哪一种索引的形式，都会提高效率，但是，在插入、更新等一系列操作的时候性能就会大大降低。因此，为了方便在各项的数据页中留下足够的自由空间，应该设置比较小的填充因子。

还有就是要选择合理的数据类型。在进行数据库设计的过程中，设计者们要根据软件开发的产品的规格以及要求来进行数据类型的选择，最终提高数据库的使用性能。除了以上的原则之外，还有很多，比如事务的使用、调整数据库的性能等等都需要设计者们明确的知道，最终完善数据库的设计。

2.大型软件后台数据库的实践

2.1数据库设计的步骤

在设计数据库的时候，首先要先进行分析，因为数据库的建立主要是为用户提供方便的，因此，要根据用户数据库系统的使用要求和各种约束条件等，形成用户需求规约。用户的需求主要分为信息需求，处理需求以及安全性和完整性的需求。在进行设计的时候，设计者们一定要考虑全面。首先是信息需求，要注意对系统中数据的类型进行描述，同时使得信息更加全面。其次就是处理需求，要满足数据处理功能，同时考虑场合、操作、频率等因素对数据的影响。最后就是安全性和完整性的要求。主要就是积极的与数据库用户进行联系，最终熟悉全部的数据资料，从而更好地设计出数据库。除此之外，要进行数据库的概念设计。数据库中的数据信息是非常庞大的，因此，需要对其中的信息进行分类、聚集和概括，从而建立出抽象的概念数据模型。其次是逻辑设计。它主要就是使得概念数据模型形成一种逻辑模式。还有就是物理设计。它主要就是对数据库的结构做出调整，然后选择出合理的路径对数据进行储存。接着就是验证设计。它主要是通过一些典型的应用任务来对数据库进行验证、修改，最终完善设计。最后就是运行和维护设计。数据库会随着使用时间的推移而出现一些问题，这个时候就需要对其进行调整与修改。

2.2基于Borland Delphi的数据库的简介

下面将简单介绍Borland Delphi该软件的数据库的运行机制。Borland Delphi常用的数据库工具有数据库工作平台（Database Desktop）、数据库引擎（BDE）、数据库资源管理器（Database Explorer）、数据字典（Data Dictionary）、SQL监视器（SQL Monitor）、Datapump 等工具。数据库工作平台（Database Desktop）是Borland Delphi提供数据库管理的的工具，它在建立数据库应用程序的过程中其中至关重要的作用。Borland Delphi通过数据库引擎（BDE）讲数据库应用程序和数据库进行联系，通过BDE来读取本地的数据库。接下来就是数据库资源管理器（Database Explorer）。它主要负责的就是查看以及修改数据库中的信息。其次就是数据字典（Data Dictionary），如果使用者在浏览版面选择Dictionary页面的时候，它就发挥作用，可以使用了。SQL监视器（SQL Monitor）只有C/S中的Delphi具有，它主要就是对BDE于数据库中的客户的动态链接间的所有操作进行监控，先运行监视器程序，然后就是根据选择的对象而显示相关的信息。Datapump工具主要负责的是Delphi数据库数据之间的转移的工作。

结语

在大型软件的开发过程中，数据库的设计是至关重要的，因此，不仅要加强数据库设计的理论要求，同时要加强其实践分析，才能更好地设计出完美的数据库，最终使得软件更好地运营。

参考文献

[1]仇学敏.分析软件开发中数据库设计理论的实践[J].制造业自动化，2012（34）.

[2]李金靖.浅析软件开发中的数据库设计的理论和实践[J].计算机光盘软件与应用，2013（15）.

[3]戴杰.浅议软件开发中数据库设计理论的实践[J].电子制作，2012（12）.

项目中的沟通与理论实践 篇4

沟通的重要意义

PMBOK 等现代项目管理标准越来越强调项目中人际交往的重要性。出色的项目经理需要识别、理解和管理人际交往。毕竟，尽管许多项目的参与人员都具有所需学科专业知识，但团队成员仍需要了解项目的目标并就此达成共识，因为他们必须准确地知道个人及团队应该完成哪些工作才能实现项目目标。这就是需要进行有效沟通的原因，同时也是项目经理应担负起娴熟的沟通管理者角色的原因所在。同样，理解和平衡利益相关方的期望也需要沟通，这一方面的工作也需要以沟通管理作为关键的项目管理技术。

我们甚至可以认为，良好的沟通实际上是项目成功的关键因素，原因如下：

（1）项目需要相关人员进行合作及共享知识，而这些人员相互之间可能并不太熟悉，或者来自于不同的文化环境。

（2）项目需要各个利益相关方参与制订详细计划，而这些相关方应能互相信任和理解。（3）项目需要由多个管理层级做出复杂的决策。

（4）项目因其独特性而存在风险，所以，需要进行有效的风险管理，而有效的风险管理离不开有效的沟通（尤其是在危机期间）。

（5）正确而及时的沟通可以确保对项目状态做出正确的评估，从而为决策提供支持。为了对项目沟通进行有效管理，项目经理应将项目沟通的各种目的、目标和约束熟记于心，然后根据情况采用适当的技术（下文将会进行介绍）。

需要注意的是：

（1）项目经理应极力避免事必躬亲，这是项目经理常常陷入的一个误区。

（2）急于获得正确的沟通，导致缺乏经验的项目经理陷入过度沟通的误区，例如召开多余的会议、发送不相关或收件人不恰当的电子邮件等。与沟通不足一样，这同样会对项目造成负面影响。

（3）项目经理应牢记：自己既不是“电话交换机”，也不是“邮件转发器”，不应对项目中的所有沟通都要参与，因为一些问题在项目团队内就能得到很好的解决！过度控制可能会给项目沟通的质量带来致命的影响。

一般情况下，遵循沟通的第1条基本规则将会有所帮助：从项目经理的角度讲，所沟通的信息应能有利于项目的成功，或者缺少该信息会增加项目失败的可能性。

沟通的目的沟通指信息在生成方和接收方之间的传递，它的过程要比共享信息复杂。项目沟通至少存在五个不同的目的。

（1）第一个也是最明显的一个目的就是交换关于项目的信息。从最高层面讲，这主要指的是就项目的目标和可交付成果、项目背景（例如假设与约束等）以及项目的主题等有关项目的方面达成一致。从更低的层面讲，这还包括与工作包成果、未解决的问题和风险等相关的信息的沟通。

（2）第二个目的是项目决策的沟通，这与第一个目的紧密相关。这些包括战略决策的沟通（如通过/不通过及其他里程碑决策的沟通），以及工作包决策和任务分配的沟通。对于前一类沟通，重点是让每一个人都能知晓，而对于后一类沟通，即使在高度民主的文化背景下，某一方（例如项目发起人、指导委员会或项目经理）也会在决策后要求他人（例如团队成员）执行。

（3）前两个沟通目的还可能会伴随着另外一个目的，即获得对自己或他人想法的认可。这尤其常见于启动会过程中，这时，所有上述三个目的相互影响：告知团队成员有关项目的信息，沟通项目的战略决策（例如项目目标和范围定义），使项目获得团队的认可。

（4）交流意见是沟通的另一重要目的。这不仅指项目经理应为其项目团队成员的工作情况提供反馈，也包括批准或拒绝，以及接收来自项目团队成员和利益相关方的反馈。

（5）最后，广泛的软性沟通还有另外一个目的，即建立相互信任、相互尊重和相互理解的氛围，这是构建项目团队的前提。尽管包括项目经理在内的管理人员常常会为此开展各种活动（例如综合会议等），但软性沟通仍是沟通过程固有的一部分，并且同样可以为上述目的服务。当然，这并非要求项目经理必须成为一个“医生”或“神父”式的人。项目经理的角色介绍了项目沟通的目的后，现在我们分析一下项目经理在沟通过程中的角色。

实际上，根据沟通活动目的的不同，项目经理扮演着以下四种不同的角色。

（1）协调员——促成项目团队内部及与项目利益相关方的良好沟通，并为之提供支持，使项目内的沟通更加容易和有效。好的协调员能够让人们掌握正确的沟通工具；安排和主持会议，并做到会议顺利、及时、中肯，参会人员适当；

确保每个人都有机会同他人分享信息，任何人接收到的信息都是相关的；识别并解决沟通问题等。这些也可以归为“沟通管理”。这一角色要求项目经理能够识别沟通需求并解决项目中影响良好沟通的问题。

（2）通信员——“产生”并发布信息。项目经理是项目团队的信息源之一，提供有关影响项目的外部因素的信息。项目经理还是为项目团队和利益相关方提供与项目相计划有关的整体状况信息的信息源。另外，项目经理还是项目决策、任务分配、未解决问题和风险的信息源。

这一角色实际上由两个子角色构成：

①在项目经理作为信息的最初来源的时候（例如项目状态分析），是信息生成者； ②在其他情况下，项目经理“处理”、标准化和集成他人提供的信息（例如识别风险和未解决的问题），是信息集成者。如果项目经理不能出色地履行这一角色的职能，就会导致项目瓶颈的出现。

（3）听众 ——简单讲，这主要指的是项目经理要去“听别人说的话”。这意味着，不仅要让信息源能够方便地为项目经理提供信息，同时项目经理还要能够分辨信息是否相关，并在信息含糊不清时能够要求做进一步说明。此时，要在获得大量信息和不鼓励提供信息（例如，不对信息提供者做出回应）两个极端之间寻求平衡。整体而言，由于项目经理在没有相关信息的情况下是无法进行管理的，因此信息过量比信息不足要好一些。

（4）利益相关方需求管理员——这是一个复杂的角色，在一定程度上会涵盖上述三个角色，目标是了解和平衡利益相关方需求。项目经理应识别重要的利益相关方并将其分类，然后根据其与项目的利益相关程度和其影响项目变更的权力大小选择适当的沟通策略，这还要求项目经理能够识别关键利益相关方的信息偏好和需求。制订沟通计划显然，项目经理的作用在沟通过程中极为重要。实际上，据一些资料显示，与沟通相关的活动会占去项目经理7 0 % 以上的时间。

对于所有的项目管理活动来说，沟通都需要正确的计划，这些计划要解决以下问题：（1）项目经理应使用哪种沟通形式、媒介、工具和技术？（2）要沟通的信息的形式和内容应该是怎样的？

（3）正常情况下，谁应该向谁沟通哪些内容？上报路径怎样？

（4）在例外情况下，谁应该向谁沟通哪些内容？在进一步深入探讨之前，了解一下沟通的第2 条基本准则可能会有所帮助，这一准则适用于大多数项目：信息发送方应确保信息接收方接收到并理解了这一信息。

如果项目经理借助技术手段（例如通过电子邮件发送通知）和某些简单的程序（例如询问一些控制性问题）将这一原则应用于自己的活动中，那么离成功就不远了。另一方面，尽管应鼓励团队成员在其沟通中应用这一原则，但要强制执行却可能会很困难。这意味着，项目经理不仅应充分发挥作为沟通协调员这一角色的作用，还应在作为信息接收方时扮演积极的“听众”，为信息发送者提供必要的反馈。换句话讲，项目经理应将获取并理解有用信息视为自己的责任。有一种有争议的说法，认为如果不考虑项目背景，项目管理实际上是一项非常简单的工作。尽管这一说法在某种程度上有些偏颇，但对沟通却是适用的。我们可以考虑下列因素：

（1）项目利益相关方和团队成员的文化背景可能存在很大不同。从沟通角度讲，项目经理应解决以下问题：

1）哪些沟通方式比较礼貌而易被接受？举例来说，公开批评某个人的表现是否恰当？在某些高层人员下属在场的情况下，是否可以和他们讨论问题？任务应采用何种方式分配？

2）特定消息（口头及非口头）有什么含义？“可能”确实表示的是“可能”还是实际指的是“不”？点头的意思是理解、同意还是注意？评价反映出的是某个人的真正观点还是仅仅出于礼貌？

3）哪些情绪可以表露？微笑意味着鼓励、挑衅还是不明白？可以开玩笑吗？ 4）是否存在与性别或年龄相关的文化规则？确实，在全球化的进程中，尤其是在跨国公司内，会存在一些列沟通标准。但是，项目经理却应该确保自己能够正确处理各种信息形式和内容，提前进行一些分析可能会有所帮助。

（2）尽管组织文化和标准可以限制上述问题带来的影响，但同时也会带来其他限制。项目沟通通常不应强制人们采用某种完全不同于其日常工作方式的标准。例如，从项目角度看，全部采用书面沟通在某种程度上可能是比较理想的，但是却不能在基于口头沟通的团队工作环境中强制采用这种方式。跨权力层级的沟通理论上可能是比较高效的，但是在层级严格的组织结构中却不实用。

（3）技术基础设施和可用的IT工具影响沟通方式的实用性。这与项目的物质条件和地理环境密切相关。典型的问题包括：）如果让团队成员在家工作，他们是否可以收发电子邮件？

2）团队成员是否拥有可以与项目经理联系的公司移动电话？这项工作是否能跨国？ 3）如果项目在地域上是分散的，那么如何以及在哪里组织会议？（4）在考虑组织模式的同时，项目经理还应考虑项目实际会涉及到的人员： 1）他们是否有足够的条件使用所获得的沟通工具？

2）他们的教育和培训水平是否能让其就项目经理希望了解到的信息进行沟通？ 3）他们是否掌握足够的语言技能？

4）他们是否在某些能力上存在欠缺，从而制约其沟通能力的发挥？

（5）最后也是很重要的一条：整体的管理模式可能会影响项目决策的沟通方式。尽管项目经理可能拥有所需的全部沟通技能，但重要的项目决策仍需要与上层管理人员进行沟通，以获得他们的认可。现在，可能的沟通障碍都已明了（希望如此），接下来项目经理应该做的就是制订沟通计划。在此，我们提出第3条基本准则：项目沟通应能及时改变，在选择沟通媒介和技术时，就应考虑到这一点。

在项目的启动和计划阶段（涉及讨论、头脑风暴、研讨会等类似活动）常常以主要利益相关方参与的整个项目团队内部的对等沟通为主。

项目经理主要把自己的角色定位为沟通过程的主持人和协调员，努力在对项目的理解上使各方达成一致，以完成计划过程并获得利益相关方的满意。这时，更注重的是完备性，而不是时间性。

执行阶段则相反：在执行阶段，信息的时间性对于项目决策的正确与否变得极为重要。因此，有可能项目经理管理启动或计划阶段的技能非常出色，而管理执行阶段的技能却不行。从本质上讲，项目沟通过程的计划实际上是制定满足利益相关方和团队成员沟通需要的规则，并选择适当的媒介与技术为这些规则提供支持。在进一步深入之前，项目经理首先应识别关键项目利益相关方，他们或者与项目有很大利益关系，或者对项目有很大决定权，这在很大程度上决定着沟通他们的沟通需求。

这样，就有了第4条基本准则：关键利益相关方更希望所进行的沟通与他们的偏好一致，而不是与项目经理的偏好一致。这样，项目经理就可以对典型信息进行分类，然后定义可能的发送方、接收方、信息传递过程中可能会发生的事件（还可能包括次数与时间点）、媒介以及考虑了利益相关方需求的形式（包括所用的模板）。在这一阶段，重要的是根据利益相关方的期望和成功的项目管理实践经验选择最为有效的沟通媒介（会议、电话、电子邮件等）、工具（文档共享系统、视频会议设备）、文档模板等，同时，要考虑项目的组织结构（指挥链、团队结构及工作组等）、后勤能力以及上文所述的环境因素等。结果可以表示为沟通矩阵的形式。更高级的沟通矩阵还应考虑上报规则。不过，这一工具仅适用于定义结构化沟通，例如绩效及状态报告、工作分配、指导委员会会议及类似的活动。由于非结构化沟通或偶然性沟通并不太适合这种方案，因此，应该根据最佳实践的指导，以与特定沟通方式相关的沟通规则集作为沟通矩阵的补充。

项目矩阵和沟通规则都将反映在项目执行组织的标准和实践中。沟通矩阵、沟通规则集以及必要的辅助信息构成了共同管理计划，该计划通常是整个项目管理计划的一部分。因此，应将沟通管理计划提供给项目利益相关方和团队成员。

对于复杂项目来说，这一工作可能要在以此为主题的单独会议中完成。在上文中，我们介绍了沟通的意义和目的、项目经理在沟通中的角色以及如何制订正确的沟通计划等。对于项目沟通来说，还有一方面内容至关重要，即沟通工具与技术的选择和使用，在下一期中，我们将重点探讨这方面的内容，包括会议及其他一些常用的沟通工具和技术。沟通工具与技术

这一部分，我们将深入了解当前比较常用的项目沟通方式以及一些易于实施的成功实践。1.会议

会议是迄今为止项目中最为常见的沟通方式，但人们对它却褒贬不一。通常，会议的目的包括：

①项目启动与计划活动，这些活动旨在理解和定义项目； ②共享与解释有关项目状况、未解决的问题与风险的信息； ③制定项目决策；

④讨论和解决与项目主题相关的问题； ⑤建立团队； ⑥解决冲突。

显然，在一次会议中，可能会有多个目的交织在一起。但是通常来讲，如果会议有明确、唯一的目的，而且不需要参会者在思维方式上做出重大转变，则会更加富有成效。基于这一观察结果，产生了一些技术，其中包括Edwardde Bono的“六顶思考帽”（SixThinking Hats）方法。

使用这种方法时，每个参会者都要“戴上相同颜色的帽子”，而每一种颜色的“帽子”代表了一种特定的思维方式：白帽子表示实事求是，红帽子表示从感觉出发，黑帽子表示危机感或风险导向，黄帽子表示积极或成功导向，绿帽子表示创新，蓝帽子表示过程控制。

更通俗地讲，这意味着以找到项目解决方案为目的的创造性的头脑风暴会议不应与分析性的风险分析会议合并在一起进行，因为对于参会者来说，在角色之间进行转换可能会比较困难。因此，认识到这一情况后，经验丰富的项目经理通常会根据项目的特点安排不同类型的会议，例如：①项目（或项目阶段）启动会；②计划会；③决策会（如指导委员会会议）；④定期的团队会议；⑤项目评审会，如状态评审会、里程碑或阶段评审会以及最终评审会等；⑥经验教训总结会；⑦冲突解决会；⑧正式的项目收尾会议。

对于这些会议，其安排方式、所用技术和做法等可能会因目的及参会者的不同而有所差异。不过，遵守以下第5条基本规则可能会有所裨益：仅组织必要的会议，因为只有这样的会议才会有成果。要安排高效的会议，逐一考虑下列问题可能会有所帮助（理想情况下，对每个问题的回答都应为“是”）：

①所安排的会议是否有明确的目的？

②相对于其他方式来说，会议是否是达到这一目的的最佳方式？ ③会议是否有主题和议程？

④如果以前召开过相同主题的会议，这次的会议是否会参考那些会议？ ⑤需要参会的人员名单是否明确？

⑥会议议程中是否考虑了届时将参会的人员？ ⑦会议主持人是否明确？ ⑧会议的时间和地点是否明确？ ⑨在确定会议时间和地点的时候是否考虑了参会者的到会情况？

⑩是否会提供适当的技术手段？组织良好、主持人明确的会议很容易被参会者欣然接受。下面是一些简单的一般规则：

（1）应提前向所有参会者（应区分必须参加者和选择参加者）发出会议邀请，并注明主题、议程和预期成果。如果需要参会者事先准备材料，也应告知参会者。由于很难在会议召开之前确保所有人都能够到会，因此，项目经理常常将会议安排在一个固定时间（例如每个周二下午两点）。

（2）伴有可视展示的会议通常更受欢迎。简单的可以是一张议程幻灯片，而详细的则可以采用多张幻灯片来阐述会议各个方面的内容。理想情况下，每张幻灯片都应对会议目的和议程做出提醒。

（3）应做好会议记录，以便参会者能在日后回顾一下自己的发言、意见和会议成果，以及了解自己做出的承诺。会议记录可以零散，但要详细，即便这样做是“多余”的，也仍可用来对以后的会议进行优化。由于会议的信息量可能会非常大，因此最安全的做法是在会议进行过程中做好记录，以避免产生误解。实践中，可以在会议结束时将会议记录展示给大家，这样，参会者就可以审核一下自己的发言，并做一些必要的修正。

（4）会议记录文件应便于搜索、结构清晰。内容通常包括会议摘要（主题、议程等）及以下部分：会议期间提供的信息、制定的决策、行动计划（责任人、行动内容以及时间）、未解决的问题以及对交换文件的引用（如果有）等。

（5）比较好的做法是，早点到会并检查一下是否一切就绪。如果有幻灯片，在会议开始时就应该已开始放映或做好了放映准备。

（6）会议应按时开始。有时，为了等待重要客人而不得不推迟一段时间，即使如此，出于礼貌，也应征得已经到会人员的同意。在会议过程中，要做好以下工作：①确保参会者有机会相互认识和了解各自的身份；②介绍会议主题和预期成果；③提出会议议程建议并征求意见——可能有人希望增加会议内容；④选择一个人做会议记录（或者自己做）；⑤积极地对会议进行管理，要使会议按照计划的范围和时间框架（包括会间休息）进行，并要保持参会者的活跃程度。在会议结尾环节，要做好以下工作：①感谢参会者抽出时间参加会议； ②总结会议情况及会议成果；③告知接下来的工作。这些规则适用于某些特定类型的会议，而由高层管理人员参加的启动会可能会更加正式，或者可以分成正式与非正式两部分。

2.电话、电子邮件、电话会议和视频会议电话、电子邮件、电话会议和视频会议也是常用的项目沟通方式。这些方式同样存在最佳实践，不过这些内容不在本文讨论范围之内。

3.其他工具和技术

项目管理IT系统能够通过时间表记录、任务进度报告、问题记录、风险报告等功能为结构化沟通提供最佳支持，对此，本文不再进行讨论。需要强调的是，尽管项目经理通常并不能只为了一个项目而订购一套新的IT系统，但却应该对现有基础设施能实现的功能做出调查。

使用专用项目管理IT系统进行沟通时，也存在一些问题： ①项目参与者需要学会使用该系统；

②项目参与者可能更愿意使用传统的沟通手段，而不愿意使用这一系统，例如，他们可能更愿意查看邮箱，而不习惯查看系统消息；

③关键的利益相关方可能还没有使用该系统。对这些问题的解决可能已在项目经理的能力范围之外，因而应被置于整个管理框架内。

另外，在实际中还有一些沟通工具比较常用：

（1）谈话是电话和电话会议的一种很好的替代方式。谈话的侵扰性更低，并且仍然具有同步性。谈话记录可以被保存起来，以用于以后的项目文档。缺点是谈话一般进行得比较缓慢，而且录音方式不能记录下表情。

（2）文档共享是一种可以让参与者在自己的计算机上查看会议主持人屏幕内容的沟通方式。在一些文档共享方案中，主持人还可以让参与者进行操作，对演示的文档进行更改。这是一种非常有用的方法，可与电话会议或视频会议一起使用，进行协同工作。总结

软件项目管理的理论与实践 篇5

深化行政管理体制改革的理论与实践

【作者】高小平/靳江好/沈荣华

【摘要题】行政管理体制改革

【正文】

党的十六大报告提出了深化行政改革的目标和主要任务，在许多方面都有较大突破和发展。改革的目标是进一步转变政府职能，改进管理方式，推进电子政务，提高行政效率，降低行政成本，形成行为规范、运转协调、公正透明、廉洁高效的行政管理体制。重点是转变政府职能，依法规范中央与地方的职能和权限，推进政府机构改革、行政执法体制改革、事业单位改革和国有资产管理体制改革，建立和完善决策机制、权力监督和制约机制，大力推进电子政务建设等项内容。

(一)建立服务型政府

建立服务型政府是近年来理论界和各级政府在深化行政改革中提出的一个目标选择。服务型政府本质上是社会本位、民本位，政府管什么不管什么，全看社会和公民是否需要，并以此来作为政府职能定位的依据，它与传统的以官本位、权力本位为特征的管制型政府相比较，是两种不同的管理理念和管理方式。将建立服务型政府作为新时期行政改革的一个目标选择，将有助于从新的视角，把行政改革和政府职能转变引向深入。在实践中，已有越来越多的地方政府认识到建立服务型政府的必要性，着手改革以往“重管理、轻服务”的政府管理方式。上海、南京、珠海等地政府纷纷提出创建服务型政府的目标，并在创新服务、社会评议、减少管制等方面进行了有益探索。

我国中央、省级政府的主要功能要于决策和宏观调控，在管理上具有宏观性、调控性和间接性的特点，同时在决策和管理上也要体现我国服务型政府的本质要求;省以下地方政府直接面对社会、企事业单位和公众提供公共服务。因此，不同层级政府的职能定位应有所不同，中央和省级政府可以作为以宏观管理为主的“决策――服务型政府”，省以下地方政府应为以公共服务为主的“服务型政府”。

(二)建立面向市场的政府

建立面向市场、亲市场、以市场为导向的政府等提法的涵义大体相同，都是指在政府与市场的关系上，凡是市场能发挥优势或能做的事，都应当由市场来做，充分发挥市场的作用。强调政府要面向市场，将有利于进一步明确市场经济条件下政府与市场的关系，促进政府职能转变。政论要起好“掌舵”作用、催化作用、促进作用，而不是“划桨”作用、大包大揽作用;也有助于将政府发挥职能作用的主要方向，放在加强宏观调控上，放在创造有效率的市场环境上，围绕市场行使好调节、培育、监管和服务职能。

(三)建立责任政府

责任政府的提法，主要是为了按照依法行政的要求，强化政府责任。在以往权力高度集中的行政体制下，政府权力与责任严重脱节和失衡，强调权力配置而忽视追究责任，重视行使权力而忽视承担责任，注重虚置监督形式而忽视追究责任。

现阶段推行依法行政的关键，在于强化政府责任，使权力的责任挂钩，建立责任政府。为此，下一步行政改革应力争取得以下突破：一是赋予权力的同时必须明确责任;二是健全政府责任制度，制定落实法定质询、罢免等追究责任的具体程序，创设引咎辞职、责令辞职等易于实施的责任制度;三是推行行政执法责任制度，并与政府外部评议制度相挂钩;四是加大执法监督的独立性、公开性和民主参与。

(四)依照公共管理理念转变管理模式

公共管理是从发达国家引进的管理理念，核心涵义在于公共性，突出强调管理主体的多元化，管理导向的`社会化，公共服务的市场化等新的观念，与传统意义上的“行政管理”有较大的差别。

在实践中，各级政府开始运用这一理论，转变职能，改进管理，推进改革。例如，财政部门提出了建立“公共财政体制”的目标，人事部门提出了人力资源管理战略，深圳等地政府提出了政府职能从无限到有限、从部门性转向公共性、从政府单一治理转向社会共同治理等项改革目标，都是十分有益的探索。

(五)借鉴企业经验提高政府效能

将企业管理经验引入政府管理，是许多国家行政改革中采用的做法，尽管这种做法在理论上存在很多争议，但引进企业管理经验促进了政府管理创新，并取得了较好效果，已成为不争的事实。

软件项目管理的理论与实践 篇6

为了全面展示“十一五”期间取得丰硕的教学成果，推动各教育单位及广大教育工作者的经验交流，由教育部中国智慧研究会教育研究所、国家基础教育实验中心总课题组、中国教育学会心理行动研究、中国管理科学院、中国教师杂志社、中央教育研究部等单位将隆重举办 “全国教育管理理论与实践论坛”并征集各级教育行政主管部门领导、名优校长和实践最前沿的作品、论文，教学教研及课题成果，推出大型丛书之一《全国教育管理与实践创新探索》，旨在为全国各级教育行政主管部门和数十万学校（院）介绍先进管理经验、探讨教育体制改革、荟萃前沿理论、追踪重大课题、报道教科研成果等，展现当代教育行政主管部门领导名优校长与时俱进、积极创新、勇于改革、科学管理的崇高品德和精神风貌。现将征稿事项要求如下,请各校通力协作，做好组稿工作。

一、具体事项如下:

1.征稿对象

各级教育行政主管部门领导、教研人员，学校教育管理工作者和广大教职员工。

2.征稿内容

①教育行政管理理论研究成果和实践经验总结。

②中小学的办学思想、教师队伍管理、教育教学管理、教育教学创新、素质教育、学科教育教学、教材教法研究（新课程、新课标）、优秀教案、教学经验、电教信息技术及信息化成果、学校思想政治工作等。

3．征稿说明

①文章篇幅以每篇2000-3500字为宜，题目下方并依次注明姓名、单位、详细地址、邮编、电子邮箱、联系电话等。

②对应征稿件不收取任何费用。该书为16开精装版。出版后，将其直接发送到部分教育行政部门、高等院校、图书馆、中小学校等；同时赠送教育部、教育行业协会、新闻出版社和入编单位。

③征稿时间从现在起,截止到2010年4月底。征稿以纸质文本和电子文档两种形式报送教体局基教股。

软件项目中需求管理的探索与实践 篇7

软件需求在软件产品的整个生命周期中占有十分重要的位置。我们应该看到,它是软件项目的依据和出发点,无论是软件的开发还是软件的维护都是以软件需求作为前提的。如果将软件需求比做是一座建筑物的地基,一点都不夸张。因此,重视需求工作,重视软件需求的质量,可以为后续的工作打下良好基础,否则可能会给开发的成本、周期以及产品的质量带来严重的影响,造成不良的后果。据调查显示,在众多失败的软件项目中,需求管理失误原因约占到45%。

在项目开发工作中,很多人对需求的认识还远远不够,有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因,以上种种原因都表明做好软件需求开发是一项系统工作,而不是简单的技术工作,只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识,并在实践中加以应用,才能真正做好需求的开发和管理工作。

2 什么是软件需求和需求工程

2.1 软件需求的定义

按照IEEE-STD-610标准的定义,软件需求是用户为解决某个问题或是为实现某个目标,要求软件必须满足的能力。软件需求可能由分配给软件的需求得到,也可能由用户或最终用户提出。软件需求主要分为3个层次,如图1所示。

1)业务需求:指客户对软件的高层次目标要求。

2)用户需求:指用户使用软件必须达到的要求和完成的任务。

3)功能和非功能需求:规定了开发人员必须实现的需求,它的实现满足上述业务需求和用户需求。通常以需求规格说明书的形式体现。

4)非功能性需求包括过程需求和外部需求。过程需求包括交付需求、实现需求、遵循的标准,外部需求包括安全性、性能、机密性、互操作性等。

2.2 需求工程的定义

需求工程是系统工程或软件工程中解决需求问题的一个崭新领域。其目标在于使工程得到的产品能够准确、真实的体现客户的需求,令客户满意。需求分析的过程,也叫做需求工程和需求阶段,它包括了需求开发和需求管理两个部分。

需求开发是指从信息收集、分析和评价到编写文档、评审等一系列产生需求的活动,分为四个阶段:获取需求、分析需求、定义需求和验证需求。这四个阶段不一定是遵循线性顺序的,他们的活动是相互独立和反复的。需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。它包括:变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

3 需求开发过程中存在的问题

需求开发过程中存在的任何问题,最终导致的结果都是需求变更。为了顺利的提供高质量的软件产品,按照开发人员的观点,软件需求应该是清晰、正确、稳定的。所谓稳定是指:希望用户一次提供所有需求,并且以后不再改变,但这往往是不现实的。用户在开发过程中变更先期确定的需求的现象非常普遍,也就是说需求变更是不可完全避免的。从开发人员的角度来看,可以把需求变更的原因分为两类:

3.1 内部原因

由于开发人员需求开发工作的缺陷使得需求发生了变更,主要有两种情况:

1)需求分析、定义、评审工作不够充分,使得需求规格说明书中隐含着问题,到下一阶段才发现。例如:为了赶工期忽视了需求的质量、需求开发的方法不当。

2)需求开发过程中,与客用户的沟通不充分或开发人员的经验缺乏,没有挖掘出用户的潜在需求。

3.2 外部原因

外部原因是指开发人员外部的原因引起的需求变更,主要是用户的原因。

1)随着用户对需求的理解逐渐深入,可能会有新的想法,所以会要求改变原来的需求。

2)业务变化导致软件需求发生变化。计算机运行环境发生变化,导致需求发生变更。如计算机硬件、系统软件等发生了变化。

3)相关制度、法律法规发生了变化导致需求变更。

无论何种原因引起的需求变更,开发人员都要积极面对。因为需求绝对不变更是不可能的。好的需求开发方法和管理的方法会对降低需求变更对系统开发产生的影响。

4 需求开发与管理的一些方法

需求开发是一项复杂的工作,使用的方法也很多,不同的开发方式有不同的方法,这里简单介绍一些相关的方法。

4.1 需求开发方法

需求开发有很多最佳实践以及好的方式方法,下面根据实践经验介绍几种有效的方法。

1)RUP与UML的结合

RUP(Rational Unified Process):Rational公司推出的一种软件考法过程框架,UML(Unified Modeling Language):统一建模语言。业界已经证实,RUP与UML的结合是一种最佳实践。因为RUP过程框架,能够有效的指导我们,有条不紊的进行需求开发工作。同时UML又能直观、形象的表达出我们想要表达的意思。图形化的需求建模会让开发人员和用户对需求的理解保持一致。这对于需求质量的提高会有很大的帮助。

2)绘制关联图

绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。

3)可行性分析

在允许的成本、性能要求下,分析每项需求实施的可行性,提出需求实现相关风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。

4)需求优先级

确定功能实现的优先级。根据优先级来确定每个产品版本要实现的需求。

5)系统原型法

原型法是一个非常有用的获取需求的方法,不论系统规模的大小,都非常适用。有时用户用语言难以表达出他们的意思,所以通过真实的应用界面会更好的引导用户提出他们的潜在需求。

6)图形分析模型

绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系,找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

7)数据字典

数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员和用户使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项,确保客户与开发小组是使用一致的定义和术语。

4.2 需求管理方法

需求管理主要是对需求变更、需求状态的管理。主要包括以下几个方面:

1)确定需求变更控制过程。

制定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此过程。

2)进行需求变更影响分析。

评估每项需求变更,以确定它对项目计划安排和其它需求的影响,明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。

3)建立需求基准版本和需求控制版本文档。

确定需求基准,这是项目各方对需求达成一致认识时刻的一个快照,之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。

4)维护需求变更的历史记录。

将需求变更情况写成文档,记录变更日期、原因、负责人、版本号等内容,及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传,应指定专人来负责更新需求。

5)跟踪每项需求的状态。

可以把每一项需求的状态属性(如已推荐的,已通过的,已实施的,或已验证的)保存在数据库中,这样可以在任何时候得到每个状态类的需求数量。

6)衡量需求稳定性。可以定期把需求数量和需求变更(添加、修改、删除)数量进行比较。过多的需求变更“是一个报警信号”,意味着问题并未真正弄清楚。

5 需求分析评价标准

如何判断需求规格说明的好坏,不同的软件工程规范都有自己的一套标准,这里向大家介绍一个比较常见的NASA SEL推荐方法,它是由美国国家航空和航天局软件工程实验室开发的五大常用国际软件工程规范之一,它对软件需求过程的评价标准是:清晰、完整、一致、可测试。

1)清晰:目前大多数的需求分析采用的仍然是自然语言,自然语言对需求分析最大的弊病就是它的二义性,所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语+动作的简单表达方式。需求分析中的描述一定要简单,千万不要采用疑问句、修饰这些复杂的表达方式。除了语言的二义性之外,注意不要使用行话,就是计算机术语。需求分析最重要的是和用户沟通,可是用户多半不是计算机的专业人士,如果在需求分析中使用了行话,就会造成用户理解上的困难。

2)完整:需求的完整性是非常重要的,如果有遗漏需求,则不得不返工,在软件开发过程中,最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是,需求的遗漏是常发生的事情,这不仅仅是开发人员的问题,更多发生在用户那里。要做到需求的完整性是很艰难的一件事情,它涉及到需求分析过程的各个方面,贯穿整个过程,从最初的需求计划制定到最后的需求评审。

3)一致:一致性是指用户需求必须和业务需求一致,功能需求必须和用户需求一致。在需求过程中,开发人员需要把一致性关系进行细化,比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系,就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

4)可测试:一个项目的测试从什么时候开始呢?有人说是从编码完成后开始,有人说是编码的时候同时进行单元测试,编码完成后进行系统测试,这些结论都不完全正确。实际上,测试是从需求分析过程就开始了,因为需求是测试计划的输入和参照。这就要求需求分析是可测试的,只有系统的所有需求都是可以被测试的,才能够保证软件始终围绕着用户的需要,保证软件系统是成功的。

6 结束语

需求管理是软件开发的整个生命周期中最基础、最关键的部分,随着软件开发研究与实践水平的推进,需求开发也越来越受到企业与开发管理人员的重视。本文提出的需求技术与需求管理方法意在让更多的人能够充分意识到需求管理的决定性作用,能够在长期的实践中对需求技术与需求管理方法进行不懈的探索与研究,推进软件开发水平与开发能力的飞跃和提高。

参考文献

[1]李明.需求管理中数据和信息的关系及应用[J].UML软件工程组织技术期刊,2008,(4).

[2]毛明志,沈贤义,黄春贤.基于特性的软件需求管理工具的研究与应用[J].计算机技术与发展,2007(5).

[3]郑人杰,王纬,王方德,等.基于软件能力成熟度模型(CMM)的软件过程改进方法与实施[M].北京:清华大学出版社,2003.

软件项目管理的理论与实践 篇8

［关键词］项目教学法 软件开发 教学模式 PowerBuilder

［作者简介］牛军涛（1969- ），男，河南襄城人，河南质量工程职业学院信息工程系主任，高级程序员，讲师，硕士，研究方向为数据库、软件工程。（河南 平顶山 467000）

［中图分类号］G642.3［文献标识码］A［文章编号］1004-3985（2007）27-0131-02

一、问题的提出

CCC2002指出：“计算机科学与技术学科除了具有较强的科学性外，还具有较强的工程性。”计算机课程的教学应该是面向设计的，特别是计算机软件开发类课程，如“面向对象程序设计”“数据库技术与应用”“软件工程”“软件开发工具与环境”更具有极强的实践性。对这类课程的教学，必须突出其工程性和实践性。我们于2004年在教学实践中开始尝试以项目为导向的教学策略，取得了良好效果。下面以PowerBuilder课程的教学为例，予以详细阐述。

Powerbuilder 是一套十分优秀的计算机应用系统开发工具，具有面向对象的开发方法和可视化的开发界面。它不仅能设计传统的高性能、基于客户机/服务器（Client/Server）体系结构的应用系统，还能方便地构建和实现分布式系统。随着Internet的飞速发展，Powerbuilder提供了对OLE、OCX、跨平台等技术的全面支持，因此也成为World Wide Web应用环境下的开发利器。由于Powerbuilder的上述优点，目前不少高校选用其作为“数据库开发”和“软件开发工具与环境”相关课程的背景环境，它也成为很多高校学生毕业设计所选用的开发工具。

1.传统教学模式的缺点。传统的计算机课程教学一般是采取知识结构驱动的教学法，教师循序渐进地讲授一门课程的知识点，学生按部就班地学习知识点。虽然大多数教学环节也有实例，但是对于整个课程来说，这些实例彼此是没有联系的、孤立的。这种教学模式的主要缺点是：其一，学生在学习过程中难以看到当前所学的局部知识的用途，缺乏学习的兴趣和内在动力，容易产生厌倦情绪。其二，学生在学习中难以抓住重点，往往过分注重细节，以至于淹没在知识细节的海洋中，难以把握整体的知识框架。其三，主要是以教师为中心，学生只是被动的听讲和练习，难以激发学生的积极性、主动性。其四，学生所掌握的知识是零碎的、不系统的，缺乏对一门课程的整体把握能力。其五，学生学完课程后，即使考试成绩很好但仍然缺乏实际操作能力，对一个完整项目的整个分析和设计过程不甚清楚，不能把所学的知识完整地应用起来，解决实际问题时很茫然。

2.项目教学法。学生学习一门软件开发与设计课程的主要目的不仅是为了学习一些关于这门课程的知识，更重要的是为了“掌握”和“运用”，即在掌握了基本的概念和关键的技术要点后，具有实际的应用开发能力。对于计算机专业的学生，采用多种模式、启发自主学习、重视实践环节、培养创新意识、树立团队精神显得尤为重要。我们在长期的教学实践和开发实践的基础上，在教学中运用了基于项目的教学法。它是教与学互动的模式，基本思路是：以一个完整的软件开发项目贯穿整个课程教学过程的始终，以项目的构建过程为线索安排教学步骤，整个教学过程由项目任务来驱动。学生在学习过程中参与一个完整项目的分析、设计、实现全过程，在课堂教学中把理论和实践教学有机地结合起来。学生不再是被动的接受者，而是积极的参与者。这种开放性、创新性的教育思想和模式，有利于克服以往教学模式的弊端，促进学生在计算机信息管理应用方面实际水平的提高。

二、项目的选择

在基于项目的教学法中，项目选择是一个非常关键的问题。所选择的项目应该具有以下特点：一是项目应具有一定的代表性。虽然一个项目不可能具有某类问题的全部特征，但要能反映问题的本质特征。二是项目应具有一定的实用性。项目最好来源于实际工作需求，尽可能选择与实际需要相结合的项目，可结合科研任务、技术开发项目、信息工程建设的需要及实际应用的需要进行选择。三是项目的规模要适中。项目规模过大则在一门课程的教学时数内难以完成，学生也难以把握；项目规模过小则难以涵盖主要的知识点，也缺乏整体性和挑战性。四是任课教师对所选项目应当非常熟悉，最好是教师亲自开发的项目。五是项目应贴近学生的生活，这样既可增强学生的兴趣，也便于学生理解和接受，使学生专注于项目的技术问题。基于以上考虑，我们在Powerbuilder课程的教学实践中，选用了“高校学生管理信息系统”作为项目案例。系统主要模块如图1所示。

三、教学设计过程

1.分析“高校学生管理信息系统”的项目需求和系统主要功能模块。把一个项目分成若干个模块，每个模块根据对应的知识点再分成若干部分课堂教学内容，将教学目标和内容融入对实际项目的理解和实践中。教学过程实际就是项目的建构过程。具体做法是：每一个教学单元围绕一个主题，提出项目设计目标，然后利用项目的设计过程，讲解教学内容，最后给学生布置项目任务。

2.项目教学的整体构想。项目教学的实施按照以下步骤进行：（1）认识Powerbuilder集成开发环境，建立一个新的Workspace和一个新的Application。（2）掌握窗口：窗口的创建、属性、常用函数、事件、基本窗口编程，并创建系统主窗口。（3）学习和掌握PowerScript语言。（4）创建学生数据库以及数据表。（5）学习和掌握常用的窗口控件：命令按钮，单选钮、复选框、分组框、编辑框、编辑掩码控件等，并创建信息录入窗口。（6）学习和掌握数据窗口技术。这一部分是Powerbuilder的核心内容，也是学习的重点内容。（7）学习和掌握高级窗口控件：下拉列表框、树状视图等，并创建信息查询窗口。（8）菜单的使用。建立系统主菜单，对前面创建的窗口进行统一管理。（9）学习和掌握SQL语句，创建信息修改等窗口。（10）学习和掌握游标，创建学生成绩管理等窗口。（11）进行功能调试和系统测试。（12）将Application编译成可执行文件，制作安装盘，交付使用。

3.项目教学的实施案例一。一是主题，包括窗口与常用控件。二是项目任务，指创建学生基本信息录入窗口，如图2所示。三是教学目标，主要是学习和掌握常用的窗口控件：命令按钮，单选钮、复选框、分组框、编辑框、编辑掩码控件。四是教学过程。在此环节中学习创建窗口对象，熟悉各种窗口控件及特性，学会对象属性、方法的引用格式，以及事件过程的创建，让学生创建一个窗口，实现向student表添加本班同学信息的功能，使学生深入理解和掌握面向对象分析问题的方法。

4.项目教学的实施案例二。一是主题，指数据窗口技术。二是项目任务，指创建学生信息综合查询窗口，如图3所示。三是教学目标，指学习和掌握数据窗口技术，包括让学生掌握数据窗口对象和数据窗口控件的概念、分清两者的区别；使学生掌握事务对象的概念；使学生掌握数据库连接和断开的概念和方法；使学生掌握数据提取的概念和方法，在以上四项的基础上使学生熟练掌握使用数据窗口的步骤。四是教学重点和难点分析。数据窗口技术是PowerBuilder的核心专利技术，数据窗口能够从5种数据源提取数据，并且开发者可以从11种显示风格中进行选择，这样开发者能利用这种技术方便、直观、简捷地操作数据库，从而可以把精力主要放在应用系统功能的实现上，提高了开发效率。因此，掌握数据窗口技术是使用PowerBuilder进行软件开发的关键。由于这一部分进入的新概念较多，数据窗口的使用步骤也较为复杂，因此掌握数据窗口技术也是本课程的一个难点。

5.教学过程。一是提出项目任务。二是概述数据窗口技术，激发学生兴趣和积极性。三是演示使用数据窗口画笔创建数据窗口对象：dw_student。四是演示创建一个新窗口，添加数据窗口控件：d_student。五是演示通过数据窗口控件的属性设置和编写代码这两种方法，将数据窗口控件与数据窗口对象建立关联。六是演示编写代码。连接数据库，提取数据，修改数据库的数据，断开连接等。七是给学生布置项目任务。让学生通过数据窗口控件在窗口对象做学生表、课程表及三表连接的修改、删除和查询及浏览页面，并且和窗口对象创建的浏览页面进行比较。八是给学生布置拓展任务。要求学生在学习了“学生”信息更新和查询知识后，独立完成“课程”“成绩”等查询窗口的设计，以收到举一反三之功效。

四、考核方式

采用项目教学法必须进行课程考核方式的改革，考核方式为形成性考核、期末笔试和整个项目完成情况考核三部分相结合的方式，所占比例分别为20∶40∶40。形成性考核主要是对学生的平时作业、学习过程中的学习行为表现、上机实践环节等方面进行考核评价；笔试考核学生对基本概念、基本理论、基本技能的掌握；项目完成情况考核主要考核学生综合运用所学知识解决问题和实际开发设计的能力。

五、教学效果

基于项目的教学法在实践性较强的计算机课程教学中，具有无可比拟的优点。它使学生能够融会贯通地掌握一门课程的精髓，强化学生的计算机应用软件开发能力，提高学生以计算机软件工程的原则对开发项目的分析、架构、设计、管理、文档编写等能力，为学生毕业后继续在计算机技术方面的发展奠定良好的基础，培养学生的合作共事能力和团队协作精神。

我们采用项目教学法两年多来，收到了明显的成效。从下表可以看出，学生无论是考试及格率，还是职业技能鉴定通过率和毕业设计良好以上比例，与以前相比都有了明显提高。

尤为可喜的是，由于学生的实际软件开发能力得到了明显提高，其就业竞争力也大大增强。有三名学生通过Internet把自己的设计作品上传给某软件企业，得到了企业的认可，获得了去该软件公司从事专业软件开发工作的机会。

计算机技术与应用的飞速发展，促使我们必须对传统的计算机课程教学模式进行改革，不断更新教学观念、教学内容、教学方法、教学手段。基于项目的教学法，虽已取得了一定成效，但也面临挑战。如项目教学法对教师的教学水平提出了更高的要求，要求教师不仅要具有一定的理论水平，还要具备较为丰富的开发经验。教育者将在今后的教学实践中继续探索，以达到提高学生专业技能和综合素质的目的。

［参考文献］

［1］郑阿奇.PowerBuilder实用教程［M］.北京：电子工业出版社，2005.