软件项目管理实践作业

第一篇：软件项目管理实践作业

信息管理与信息系统专业软件工程作业

问题：UML中提供了哪9种图?试述每种图所描述的内容

1、用例图

描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

2、类图

类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。

3、对象图

与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。

4、活动图

描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。

5、状态图

描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类;该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。

6、序列图 (顺序图)

序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。

7、协作图

和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图;如果强调上下级关系，则选择协作图;这两种图合称为交互图。

8、构件图 (组件图)

描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。

9、部署图 (配置图)

是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员

第二篇：软件配置管理最佳实践

PMTeam杂志 Li Ben 编

现在大家都已经认识到了有效的软件配置管理工作对于提高团队开发效率、保障软件产品质量的重要意义，很多朋友也开始了在配置管理实施方面的一些研究，市场上我们也可以看到一些软件配置管理工具厂商针对具体配置管理工具提供的实施服务;但是，实施软件配置管理到底应该做哪些东西?团队的配置管理现状怎么评估?在哪些方面还可以进行改进?我们相信，这些问题可能正困扰着大多数研发主管和项目经理。

国外软件产业界在软件配置管理这个专题上已经进行了多年的理论和实践上的研究。在多年经验积累的基础上，产业界总结出来一系列“最佳实践”(Best Practices)，我们可以使用这些“最佳实践”来作为评估一个组织软件配置管理能力的标尺，也可以作为我们实施软件配置管理的指南。这些“最佳实践”包括：

1、 标识需要进行存储的工件(Artifact)并保障安全存储;

2、 控制并且审计(Audit)对于工件的修改;

3、 设立并管理基线(Baseline);

4、 记录并跟踪变更请求;

5、 维护稳定、一致的工作空间;

6、 支持对于工件和控件的并发修改;

7、 尽早集成、持续集成;

8、 保证软件构建的重现能力;

9、 以控件(Component)为单位实施版本控制;

10、 使用“活动”(Activity)来组织和整合版本集。

下文将介绍前5条最佳实践。

1、标识需要进行存储的工件(Artifact)并保障安全存储

在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件(Artifact)。对于一个软件开发组织来说，这些工件就构成了组织的核心资产。对于如现金、有价证券之类的资产，我们都会准备一个保险箱，好好地保存;对于软件资产，我们也需要相似的措施。所以，软件配置管理工作的第一步就是建立一个安全、可靠的存储库(Repository)，用于保存组织的核心软件资产。 这个库对于开发团队来说，就像是财务室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除此之外，随着

组织的增长，置于库中的数据会越来越多，为保证运行效率，库的可扩展性也是非常重要的一个属性。

对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。令人惊讶的是，很多软件组织在这方面都没有给予必要的重视，因而也给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。

在建立好存储库以后，需要做的工作就是确定将哪些工件置于库中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，则不将它们放入库中。我们把放入库中的文件称之为配置项(Configuration Item)。

2、控制并且审计(Audit)对于工件的修改

在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些工件的修改控制机制以及审计机制。

库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方(Who、When、Why、What)。 审计机制通常通过“检出/检入”(Check out/Check in)模式得到实现。在这种模式下，工件一旦入库，读写权限就变成只读(read only)，如果要对该工件进行修改，则需要通过“检出”这个步骤;在修改结束以后，如果希望将修改的成果入库，则需要通过“检入”这个步骤。在经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人把上边的过程称之为“版本控制”(Version Control)。在版本控制过程中，如果利用一些配置管理工具(或者版本控制工具)的支持，则可以自动地记录审计工作所需的四个“W”(Who、When、Why、What)。

3、设立并管理基线

通过审计机制我们可以保存一个工件完整的变更历史;但是一个项目通常是由成百上千个工件构成的，每个工件在变更过程中都会形成一系列的版本，如何确认系统在某个时刻分别由哪些工件的哪些版本构成?这就需要引入一个概念：配置(Configuration)。对于软件系统来说，在开发过程中某个时刻存储库中所有工件的一个“快照”(snapshot)，就形成一个“配置”。对于一些重要时刻的系统配置，我们可以使用基线(Baseline)来进行标志。

IEEE对于基线的定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变

简单地说，基线就是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于这个标准进行，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对它进行的变更都将记录为一个差值，直到建成下一个基线。

建立基线的主要原因是：重现能力、可追踪性和报告能力。

重现能力是指返回并重新生成软件系统给定发布版本的能力。可追踪性建立项目各种类型工件(需求、设计、实现、测试等)之间的横行依赖关系，其目的在于确保设计满足需求、代码实施

设计以及使用正确代码编译生成可执行文件。报告能力来源于一个基线内容同另一个基线内容的比较，基线比较有助于程序调试并生成发布说明(Release notes)。

建立基线有以下几个好处：

(1) 基线为开发工件提供了一个定点和快照。新项目可以从基线提供的定点之中建立。

(2) 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。

(3) 可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现被报告的错误。 在开发过程中，需要定期建立基线以确保团队开发人员的工作保持同步，通常，在项目生命周期中的里程碑处定期建立基线。

4、记录并跟踪变更请求

以上我们谈论的都是对于工件的变更活动的实施，下面我们要谈到的是软件配置管理的另一个方面：对于变更请求的管理。这是变更活动的源头。

著名的软件大师Brooks曾经谈到导致软件开发困难的一个原因就是软件的可变性。大家都知道，各种要素，如市场的变化、技术的进步、客户对于项目认识的深入等等，都可能导致软件开发过程中的变更请求的提出，而且承认这种变更请求的合理性也已经是工业界的共识。

但是，如果缺乏对于变更请求的有效的管理能力，纷至沓来的变更就会成为开发团队的噩梦。缺乏有效的变更请求管理会导致以下一些问题：

(1) 软件产品质量低下，对一些缺陷的修正被遗漏;

(2) 项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力;

(3) 开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况。

变更请求管理的复杂程度与变更的具体类型有关。简单地说，变更请求管理会涉及到变更请求的提交、变更请求的复审、变更任务分配、变更结果的验证等一系列活动。通常，变更请求管理的流程是：由请求者提交变更请求，变更控制委员会(Change Control Board，CCB)召开CCB复审会议对变更请求进行复审，以确定该请求是否为有效请求。如果是，则基于项目团队所确定的优先级、时间表、资源、变更难度、风险、严重性以及其他相关标准，判定对该变更的修改程序，并分配实施变更任务的人力资源和时间资源;变更任务实施人员负责实施该变更;实施结束以后提交验证人员，由验证人员负责对变更结果进行验证，如果变更成功则通知相关人员，否则由变更实施人员返工。

典型的变更请求管理如需求变更管理、缺陷追踪等。实施有效的变更请求管理有以下好处：

(1) 提高软件产品质量;

(2) 提高开发团队沟通效率;

(3) 帮助项目管理人员对产品状态进行客观的评估。

关于变更请求管理的详细过程以及相关准则PMT将在相关报告中阐述。

5、维护稳定、一致的工作空间

在我们把相关工件纳入集中的存储库、大家也都遵照“检出/检入”的工作模式对工件进行修改以后，下一步的工作就是要为每位开发人员设定“私有”的工作区，或者叫做工作空间。

工作空间通常以特定的基线为基础创建，要求能够做到为指定的任务方便地取出正确的工作版本建立私有工作空间;开发人员根据项目要求在自己的私有空间中对工件进行修改和测试活动，而与其他开发人员相对保持隔离，也就是说，自己的修改活动不会受到他人的影响，也不会影响到其他开发人员。但是，在保持隔离的同时，又应该提供相应的机制，当开发人员希望共享工作成果的时候，能够很方便地实现共享。

开发人员日常的开发工作都是在工作空间里进行的，因此，稳定性应该是工作空间首要的特性，只有高度稳定的工作空间才能保证开发人员的工作效率。

第三篇：软件项目管理的理论与实践

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

关键词：CMM/CMMI，敏捷

1 当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到底怎么了?敏捷真的适合我们吗?我们该何去何从?

2 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博士所说的那样，“过程改进黑暗面的诱惑力是巨大的，实施者们很容易受其诱惑而陷入只追求表面文章的黑暗面之中”。这样的过程改进只注重满足标准，片面追求过程与规范的符合度，脱离了软件开发实践，忽略了实践对理论的验证、反馈，违背了过程改进的初衷，偏离了提高效率、提高软件质量的根本目标。

3 敏捷的特征

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

4 平衡敏捷与规范

在敏捷与传统为谁是谁非的问题争论的不可开交的时候，一些有识之士已经在考虑两者的融合。其中比较有代表性的一位，是以创造了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. 注重技术人才的培养。“盖成非常之事，必待非常之人”。两千年前的汉武帝，就已经认识到人才的重要性。正是因为具有不拘一格用人才的非凡气魄，汉武帝才能挖掘出卫青、霍去病这样的军事天才，建立不世之功。在软件行业，也不乏盖茨、裘伯军、王江民这样以一己之力获得巨大成功的先例。因此，软件研发，尤其是开拓性软件的研发，必须要有大批具有专业知识、超凡能力的“非常之人”。软件企业要具备容纳百川的胸怀，重视技术人才的挖掘、培养，提供钻研技术的环境，打造尊重技术的企业环境，造就技术过硬的拔尖人才，才能提高自身素质，建立企业的核心竞争力，在市场上保持竞争优势。

6 结束语

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

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

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

第四篇：软件项目综合实践心得体会(bistu勿用)

软件项目综合实践心得体会

这个学期的软件项目综合实践马上就要结束了，作为我们小组开发组的一员，通过一个学期系统的学习实践后我体会到了许多在基础课程中认识不到的经验和心得。

首先，软件工程项目是需要团体作业才能够完成的。团体作业就需要交流，有交流，就必然会有合作;有合作，就需要有分工;有分工，就需要有协调;有所有这些，就需要有管理。然而一个人的项目是否不需要管理?当然不是，因为有文档，有代码，有灵感，有经验，等等都需要管理。只是此刻的管理是自己完成的，可以更简单一点。我们已经有过一遍又一遍的调试以前已经fix过的bug体验，也有过一遍又一遍的查找以前自己实现过的技术的经历。软件工程的理论，在开发过程中的作用，就是指导如何做好管理，以取得软件的可用性、正确性和合理性。如果我们清楚知道这是它的目标，就可以抛开一些对自己不适用的枝节。

我认为软件工程中最重要的，最有实际意义的，是它界定了工作职能，从而也确定了责任归属。什么意思?说白了，就是什么人做什么事，出了问题谁负责。那么它是怎么界定工作职能的?是通过对软件开发流程的划分来实现的。软件工程把软件的开发划分成很多个相对独立的阶段，每一个阶段都有相关的人员来实现，也就有相关的人员来负责。分工不清，责权不明，是导致管理混乱的最主要的因素。所以即使是两个人的项目，也是需要软件工程来指导的，因为通过它，可以更好的知道如何可以合理分工，划分工作职权以取得最终的成果。当然，走教条主义的道路是非常愚蠢的。

软件开发的一个共识，是把一个大的项目划分成一些小的模块，再把小的模块划分成更小的模块。如果这些小模块是独立的(或者原来就是一个独立的项目)，那么软件工程至少可以提高它的重用性。对于一个软件工程观念不深的团队，不要期望他们在接手大的项目的时候可以使用软件工程，如果他们在小项目中不愿使用的话。前者的复杂度不是他们可以想象和承受的。

其次，通过这学期的实践，我才真的体会到，良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱。

以前在做实验提交文档的时候，总是有一种为了写文档而写文档，是被动的完成工作的感觉。但现在我认识到，维护良好的文档对于保证软件质量是必不可少的。对软件文档的深入接触，让我认识到文档本身就是软件产品，没有文档的软件，不能称其为软件，更谈不上为软件产品。软件文档的编制在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档，对于充分发挥软件产品的效益有着重要意义。

文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间起着桥梁作用。软件开发人员在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或工作报告，这些计划和报告都要提供给管理人员，并得到必要的支持。管理人员则可通过这些文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料，我们称此为用户文档。以上三种文档构成了软件文档的主要部分。

我们初级编程人员总是或多或少的存在对软件文档不够重视的现象，总是把工作重心放在代码编程上。结果编出的代码总是不能尽如人意，因此，在今后的工作与学习之中，我们应该给予软件文档的编制应有的重视，这样才能让开发出来的软件系统更符合客户要求，更少漏洞，更加完善，臻于完美，这也是我们软件开发人员所孜孜以求的。

最后，经过这学期软件工程实验的学习，深深感到用户需求对软件的重要性。成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。

需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。

还有就是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。

如果客户要求的功能与已有的系统很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。

总而言之，经过一学期的软工实验，深刻感到其重要性的同时也学到了不少的东西 ，将对我在今后的软件开发过程中起极大的作用。

第五篇：模拟项目与高职软件技术专业实践教学研究论文

摘要：加强教育教学质量监控，是教学质量和教学水平不断提高的必要手段，也是各级教学部门的重要职责。健全教学质量监控与保障体系，做好质量保障监督工作，应构建合适的质量监控体系。本文结合绵阳师范学院二级学院构建教学质量监控体系的探讨，阐述了如何建立合理规范的教学质量监控体系在提升教学质量的有效作用。关键词：教育教学质量;监控体系;构建

提高高等学校教学质量是高等教育发展的永恒主题，是学校的发展的核心。当前高校扩大招生规模，疏于教学质量管理使得教学质量成为了制约高等教育发展的关键。为此，各高校教育管理部门都在积极探索建立一套完整的教学质量监控体系以确保学校的教学质量。本文结合绵阳师范学院二级学院构建教学质量监控体系的探讨，阐述了如何建立合理规范的教学质量监控体系在提升教学质量的有效作用。

一、教学质量监控体系构建的作用与意义

(一)促进学校教学质量稳步提升。

教学质量是一个学校的生命线，是立校之本，如何提升教学质量、实现学校的可持续发展是目前各大高校的首要任务。因此建立和健全合理的监控体系来提升教学质量变得何等的重要，监控体系是高等学校对教学运行状况进行的评价、监督、对学校行为实施调节的反馈系统，是促进学校持续改进人才培养质量的支持体统。它是实现质量方针、目标的一种合理有效的手段，全面渗透到教育活动的全部环节，为教育质量提供全方位的保证。

(二)促进学生的全面发展。

“一切为了学生，为了一切的学生，为了学生的一切”，这充分体现了21世纪的高等教育应以学生为本，促进学生的全面发展，因此人才培养目标的实现关系着学校的生存与发展。构建教学质量管理监控系统的目的是提高教学质量，而学生是教学质量的最终承载者。因此，教学质量监控的最终目的是提高学生的知识能力和素质水平，促进学生的全面发展，让学生成功成才。

(三)提升学校的竞争力。

当前高等教育正处在从量的扩张转向质的跨越的历史性转折点，学校正处在发展的关键时期，既是加快发展的重要战略机遇期，又是应对各种挑战的战略竞争期。那么每所高校都应建立以人为本的教育质量监控措施，用素质教育的指标来引导和规范学校的办学行为，落实素质教育，提升学校核心竞争力，是当前每所学校追求的终极目标。

二、绵阳师范学院二级学院教学质量监控体系

绵阳师范学院二级学院以规范教学管理、提高教学质量为主旨，努力完善教学质量监控与保障体系，稳步提高教学质量，并取得了一定的成效，教学质量监控体系的构建分为两个部分：教学评估和教学督导。

(一)教学评估。

首先学院制定教师教学工作评估细则，评定教师教学工作等级，然后制定教研室主任工作评估细则，评定教研室主任工作等级。

(二)教学督导。

随时对课堂教学、实验教学进行检查、指导，与教师交流意见;参与教学过程的常规检查，重点检查教学大纲、教案、

日历、实践教学的情况，并提出督导意见和建议;参加每学期的期中教学检查工作，抽查部分期末试卷、毕业论文，发现教

学工作中存在的问题，找出影响教学质量的原因，提出改进意见和建议;定期或不定期召开师生座谈会，认真收集和及时反馈师生对教学工作的意见和要求;根据理论教学和实践教学管理中出现的突出问题，进行专题调查和研究，撰写调研报告。

教学质量督导具体又分为以下几个方面的评价：

1.督导员听课评价。

督导员一般由有多年教学经验的教师特别是教学法的教师或离退休的返聘人员组成。他们都有多年的教学经验，清楚一线教学的具体要求和程序，能够对教师进行准确的评估。同时能对教师教学质量提出客观、公正的要求和建议。受评教师在讲授内容上是否突出重点、难点;对教材的处理是否有独到之处;在教学过程中是否把本质的内容讲得透彻;是否运用最佳教学方法等，督导员一目了然。督导员听完每堂课后及时的和教师沟通、交流、提出自己的建议，这都对教师特别是青年教师的成长、教学质量的稳步提高帮助很大。

2.同行互评。

学院全体教师互相听课，进行互评，填写《课堂教学质量互评表》。同行教师尤其是同一课程的不同任课教师互相听课，能汲取别人的教学经验，改善自身的缺点。同行评估指标主要集中在教学内容、教学方法、教学要求上。比如该课程是否吸收学科新成果、是否思路清晰、重点突出、难易适中;能否注重学生思维方式的传授、能力的培养;能否采用启发式的教学;是否严格遵循教学大纲和教学计划授课，普通话是否标准，是否严格执行考勤等。在互相听课后，及时地与教师进行交流，互谈自己的意见和想法，促进教师的共同提高。

3.学生评教。

学生评教体现了“以人为本”观念，增强了教师的服务意识，学生评教给学生提供了“敢说真话、敢发真言”的平台，有利于促进师生之间的交流沟通，有利于建立起和谐的师生关系。良好、及时的沟通都是提升教学质量的前提。

学生参与教学评价，也在一定程度上促使教师每堂课必须做好准备，要求不再是死板的传授知识，必须要充分调动学生的学习积极性，教给学生科学的学习方法和研究方法。这样，教师课前就要精心钻研教材、查阅大量的文献资料、深知国内外的研究现状、懂得教育学的知识，深知教育教学方法。因此，学生评教能够促使教师时刻想着学生、时刻关心学生、时刻为自己的上课做好准备。这样对老师的成长也起着不可替代的作用!

4.信息员反馈。

教学信息员一般由教学秘书担任，学期结束后，信息员都会开展学生座谈会对老师们进行客观公正的评价，召集教学督导员进行交流，记录学生和督导员反馈的意见，收集整理这些

反馈意见，及时有效地反馈给教师，使教师们都能够及时了解信息，继续发扬优点，弥补不足，提高自己的教学质量。

三、如何有效地构建教学质量监控体系

(一)建立合理的教师考核体系。

教师的劳动是辛苦的富有的创造性劳动，每位教师的创造性都不一样，与个人的兴趣爱好、敬业精神，宽松自由的外部环境等息息相关。所以高校应根据教师的教龄长短，工作阅历和教学经验等方面的实际问题，创造科学的考核体系，积极实施青年导师制，帮助青年教师尽快成长，提升教学质量。

(二)构建合适的课程考核体系。

课程的考核，也就是教学的终极目标教学效果的体现现主要是以闭卷考核方式进行，本人觉得应根据课程特点、教学内容和对象的不同，注重课程考核方式创新，采取形式多样的考核模式，比如：公共任选课程以论文或开卷考试方式进行;实验课程的考核以学生设计综合性、设计性实验的方式考核;专业考查课程的考核以查阅相关专业文献资料写论文的方式进行，闭卷考试可以以试题库考核模式、半开放考核模式—一页小抄写上公式带入考场方式进行;英语课程的口语考试以随堂进行口语测试的方式进行。总之，考核体系应该具有合理性、多样性，每门课程的考核都应体现自身的特点，都能准确反映老师的教学效果，学生的真实水平。

(三)合理扩大招生。

学校应根据自身事业发展的实际需要，本着努力挖掘办学潜力的前提下合理扩大招生规模，控制师生比，这样才能稳固教学秩序、巩固教学质量，教学质量的高低才是一个学校具有国际竞争力的法宝。

参考文献：

【1】高天虹，赵丹，《教学质量监控体系在高校教学工作中的地位和作用》高等建筑教育，2004年6月，13(2):111~113.

【2】王俊林等，《构建科学教学质量监控体系提高教学质量》，牡丹江医学院学报，2009，30(2):99~100.

【3】周治淼等，《浅析学生在教学质量监控中的作用》教学改革与管理，2009.5.

【4】庞丽娟等，《课程考核质量监控体系的实践》，西安建筑科学大学学报，2008年3月，27(1).