高校实验室资源管理系统论文信息学院Word文档格式.docx

1、能够跟踪实验预约后的具体实施情况,实现高校实验室开放网络的实验预定。进入二十一世纪以来, 实验室管理系统提出了愈来愈高的能力要求。CMMI是由美国卡内基梅隆大学软件工程研究所提出来一种可用于软件开发组织进行开发能力持续建设、提升开发系统质量的模型。本文针对CMMI如何在高校内部软件开发组织中应用进行研究。第一章 绪论1.1国内外研究背景CMM的成功促使其他学科也相继开发类似的过程改进模型，例如系统工程、需求工程、人力资源、集成产品开发、软件采购等等，从CMM衍生出了一些改善模型，比如：（1） SW-CMM （Software CMM） 软件CMM（2） SE-CMM （System Engin

2、eering CMM） 系统工程CMM（3） SA-CMM （Software Acquisition CMM） 软件采购CMM（4） IPT-CMM （Integrated Product Team CMM） 集成产品群组CMM（5） P-CMM （People CMM） 人力资源能力成熟度模型为了以示区别，国内外很多资料把CMM叫做SW-CMM。按照SEI原来的计划，CMM的改进版本2.0应该在1997年11月完成，然后在取得版本2.0得实践反馈意见之后，在1999年完成准CMM2.0版本。但是，美国国防部办公室要求SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI，原因

3、是在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆， CMMI就是为了解决怎么保持这些模式之间的协调。 CMMI（Capability Maturity Model Integration）即能力成熟度集成模型，这是美国国防部的一个设想，他们想把现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件采购方法的改革；第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。就软件而言，CMMI是SW-CMM的修订本。它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科学和更周密的优点。SEI在发表CMMI-SE/S

4、W 1.0版时，宣布大约用两年的时间完成从CMM到CMMI的过渡。 CMMI项目更为工业界和政府部门提供了一个集成的产品集，其主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。 由业界、美国政府和卡内基梅隆大学软件工程研究所率先倡导的能力成熟度模型集成（CMMI）项目致力于帮助企业缓解这种困境。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够重总体上改进组

5、织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。与原有的能力成熟度模型类似，CMMI也包括了在不同领域建立有效过程的必要元素，反映了业界普遍认可的最佳实践；专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。在此前提下，CMMI为企业的过程构建和改进提供了指导和框架作用；同时为企业评审自己的过程提供了可参照的行业基准。1.2 目前实验管理现状和问题（一）开放实验内容单一。开放实验内容单一,缺乏多学科的综合性和交叉性,实验室按课程设置依附于课堂教学,缺乏创新性。操作性和验证性实验还是占多数,学生被束缚在教师制定的框架中,只能按照设计好的模式步骤去实验,极大

6、地限制了学生创新思维能力的提高。（二）开放时间缺乏制度化。开放时间不太明确,现行的实验室往往是在教师讲授课堂内容的相关专题时才临时决定通知实验室管理人员开放实验室。而且由于是45分钟的课堂实验,学生并不能按照自己的想法自由地做实验,完全处于一种被动的状态,由于缺乏必要的开放时间,所以在很大程度上限制了学生综合实验的兴趣以及能力的培养和提高。（三）仪器维护低效率。由于实验室管理缺乏制度化和经费困难等原因,实验室管理人员人手有限。同时,学生数量的增多,使得实验室的仪器、设备、材料往往因此而不能得到及时的维护,损耗快,造成了一定的资源浪费。（四）实验室财产易丢失。目前实验室的固定资产一般不会丢失,但

7、是一些易耗的小物品,往往因为缺乏管理的规范,有时会被一些学生顺手牵羊,实验室管理人员无法每天定时地清理相关仪器的数量,因而在一定程度上造成了实验室财产的丢失。（五）实验室的经费投入较少。实验室的投入主要是构建实验室的场所、仪器、设备。一方面,经费投入机制不健全,缺少在实验室建设和发展长远规划指导下的经费投入机制,使实验室的建设难以进入良性循环;另一方面,针对基础课教学实验而言,缺乏多渠道筹措资金的能力,经费来源单一。（六）实验室评估机制的欠缺。现行的实验室考试主要还是考核学生对规定内容的掌握程度,它对于学生掌握所学知识有作用,但是距离通过实验室教学全面提升学生的素质、培养其相关的技能尚有很大差

8、距。1.3 实验室资源管理系统随着学校规模的扩大，实验室建设和管理的问题也渐渐暴露出来：（一）实验设备、仪器、低值耐用品等没有较好地建立信息库，以供查询其基本信息及使用状态，不利于对这些实验设备的维护；对仪器设备的领用、借用、修理、报废的处理仍处于手工处理阶段，处理过程繁琐，容易出现纰漏，造成设备流失；实验耗材的管理也带有较大的主观随意性，容易造成耗材浪费。仪器设备信息统计过程复杂，占用大量工作时间，耗材消耗情况不能够得到很好统计。（二）实验室教学管理工作处于手工处理阶段。实验教学计划、课程大纲、实验安排完全手工操作给实验教学管理带来繁重的工作负担；对教学过程和成绩评定没有建立详细的信息管理和

9、记录，从而无法充分保证教学效果，积累教学经验；实验室主管部门和实验室之间没有方便快捷的协作通道，教师和学生之间也缺少很好的沟通桥梁，难以适应开放式的实验教学的需要。（三）没有建立完整的实验项目、人员、设备数据库和实验室建设、管理文档库。造成每逢评估检查或数据上报就要加班加点赶材料，使本来就繁重的工作更加繁重，本来就紧缺的人手更加紧缺。随着学校管理变革的逐步推进，实验室建设的进一步规范化、复杂化，学校实验室管理工作也变得更加繁重和复杂。这就迫切需要用计算机来进行辅助管理，以简化实验室主管部门的工作。学校已建成覆盖整个校园的计算机网络系统，使用计算机网络来进行实验室管理成为了必然，特别是实验室开放

10、选课给传统的实验室管理提出新的挑战。为了把学校建设成为在国际上有一定影响的国内高水平大学的宏伟目标，我们建议充分利用现有条件，建立实验教学和管理的信息系统，实现实验教学全过程的计算机管理，减轻实验室管理人员的工作负担，提供工作效率和服务水平，加强实验室主管部门对设备和材料的计划、采购、维修和使用的宏观控制和管理，以节约成本，提高利用，强化管理，并为本科教学评估和实验室评估提供原始资料和翔实数据，为学校的评建工作作贡献。1.4 研究的内容目的和意义实验室信息管理系统（Laboratory Information Management System 英文缩写LIMS）是将以数据库为核心的信息化技术

11、与实验室管理需求相结合的信息化管理工具。以ISO/IEC17025:2005-5-15检测和校准实验室能力的通用要求（国标为GB 15481）规范为基础，结合网络化技术，将实验室的业务流程和一切资源以及行政管理等以合理方式进行管理。通过系统分析，配合分析数据的自动采集和分析，大大提高了实验室的检测效率；降低了实验室运行成本并且体现了快速溯源和痕迹，使传统实验室手工作业中存在的各种弊端得以顺利解决。目前实验室信息管理系统在西方发达国家的应用相对比较成熟，我们国家经过多年发展，很多实验室也开始逐渐认识到信息化在管理中的作用，纷纷开始引入实验室信息管理系统。 实验室信息管理系统也不断在各个行业进行不

12、断的改进和提升。 相信随着科技的不断进步，和产品功能的不断完善，实验室信息系统将完全可以实现各种虚拟化在线实验室。第二章 CMMI及其关键过程域2.1 管理需求1.什么是CMMI?软件工程学会（SEI），集成的能力成熟度模型（CMMI）是描述产品开发（包括系统工程和软件工程）的能力成熟度模型。SEI把CMM描述成为包含一个或多个关键因素的有效流程，同时也描述了如何从杂乱的，不成熟的流程到规则的，成熟的具有更高质量和效率的流程。CMMI是对软件成熟度模型（SW-CMM），系统工程成熟度模型（SECM）和集成的产品开发成熟度模型（IPD-CMM）的最佳实践的建立和扩展。难道流程改进不会耗费时间和金

13、钱吗？它的回报是什么？改进产品开发流程当然需要投资。但是，正确选择工具去支持这些流程能够加速流程实施和缩短产生回报的时间。企业运用CMMI或CMMI之前标准所收到的投资回报是有目共睹的。 在2003年10月份的报告中，SEI发现所有使用CMMI的企业都受益匪浅，包括：z查找和修复缺陷的成本降低了15%；修复一个缺陷的平均成本降低了30% z推出新版本的时间缩短了50%；软件开发能力提高了30% 大大提高了系统的部署质量，只出现了2%的错误 提高了客户满意度，相应的得到了更好的财务回 2.CMMI成熟度水平CMMI提供了级别式的和持续式的两种表示法。在本文中，将关注级别式表示法。CMMI定义了五

14、个级别（或水平）的过程成熟度（见图1）。CMMI鼓励企业先集中精力在那些可控制的过程域上，然后逐步将这些过程演变到更复杂的级别。本文将重点描述级别二和级别三中包含跟需求管理相关的过程域。图1：CMMI的五个级别过程域CMMI的过程域是一组相互关联，并且有一组可定义目标的最佳实践。图二表示了五个成熟度级别各自的过程域 图2：CMMI各级别的过程域本文将关注CMMI第二级别中的需求管理和第三级别中的需求开发及相关技术解决方案。一旦付诸实施，它们相互紧密联系，并协同运行 2. CMMI级别二的需求管理处在级别二的组织必须已经检查过一系列关键域，并建立起可重复性的流程。过程域：需求管理在该级别上，CM

15、MI对于需求管理过程域的目标是：“需求是可管理的。项目计划和产品开发间的不一致性是可以识别的。”所有产品的目标都是可以满足其责任人（Stakeholders）和客户（Customers）的需求，但它也必须遵守其内部功能上和质量上的约束。需求管理过程在这一点上起到了非常重要的作用。最近的Standish行业分析报告明确的指出， 50%的成功项目把成功归功于建立了良好的需求管理过程。为达到需求管理流程目标而必须建立的一系列最佳经验概括如下：组织必须定义一组需求CMMI中建议：“与需求提出者一起得出对需求的真正理解。“从项目参与者得到对需求的确认。任何需求管理过程的第一步都是确保所有的责任人（Sta

16、keholders）理解项目的目标和目标设立的原因。因此，在组织级别上必须建立一整套流程可以涵盖所有责任人参与需求的定义，并最终对这些需求达成一致。在项目的进展过程中，组织能够从最终的结果反向追踪到最初的目标，以确保两者的匹配度。除此之外，任何针对需求的修改都需经过审核。因此，为了建立和管理一整套具有良好定义的需求，需求管理工具应该能够让不同的用户查阅/修改需求文档，并可以识别需求的唯一性。用户也同样能够简便地建立起不同阶段的需求（例如，用户需求和产品需求）和项目的其他工件（例如设计和测试）间的可追溯性报告。需求管理工具同样也应该可以提供一套可审核的追踪过程，从而保证需求即使在发生变更的情况下

17、仍然可以得到实现。维护需求的修改历史也同样重要，因此需求管理工具也应该支持对需求文本的基线化版本管理。组织必须管理需求的变更“在项目中进行过程中管理需求变更。一旦需求建立被捕获或产生，所有的项目参与人员必须能够得到需求的最新信息。因此整个组织必须懂得：需求变更的提出和产生。.这些变更将对整个项目有怎样的影响。对于这些变更，相关责任人采取了怎样的一致行动。这些经过审批的变更是否已经反映到最终的产品。需求的变更是不可避免的，也是允许的，但必须加以管理和控制。相关工具必须提供一个可协作的，可配置的需求变更控制流程。用户在这个流程中必须能够：针对需求提交变更请求。在变更控制流程中，将单一需求项的多个变

18、更请求作为一个独立的条目进行管理。将相关的多个需求变更对应到一组需求上，以达到同步的更新。将需求变更分派给相关评审人员。能在线评审并评注需求变更，这样所有人都能够看见所有的评注。迅速全面的评估对某个变更对于需求，设计和测试的影响。根据评审人员的意见批准或拒绝变更请求。自动地实施批准的变更以确保不发生任何的错误。组织必须确保需求被满足 “必须维护/保持需求、项目计划和产品开发之间的双向可追踪性。只有完整的可追踪性才可以确保所有正确的需求都是以正确的方式实现的。因此，组织必须能够检查在开发过程的每一个阶段需求都被满足，并且说明最终产品的某一个具体特性是怎样反向对应到其需求的。没有工具的强有力支持，

19、创建、维护和报告需求的追踪性是极其耗时和容易出错的。因此，工具必须能够确保迅速，简单地建立起追踪连接。为了达到CMMI的要求，不仅要在各个需求之间，而且也要在需求和项目计划和产品开发（例如设计和测试）之间建立可追踪性。需求管理工具必须能够收集/同步开发过程中所使用的其他工具中的信息，同时为了支持迭代和递增的开发流程，也必须在需求文本的不同版本间建立和维护可追踪性。一旦建立了追踪性，需求管理工具必须能够在一个窗口中查看需求之间，需求和计划，工件之间的关联状况。组织必须确保项目计划，开发产品和需求是一致的“必须识别出项目计划，开发产品和需求之间的矛盾（或不一致性）。识别这些矛盾可以确保组织的开发工

20、作是正确的，这样所有工作都遵从最新的相关信息并且没有忽视任何需求。因此，组织必须建立起一套流程以确保所有的项目计划，开发产品和需求保持一致。这套流程中包括评审，分析，和管理所发生的需求变更。项目计划和需求声明必须紧密关联，需求管理工具必须确保项目任务和需求数据是同步的，这样两者之间才可以建立起可追踪性。可追踪性的建立可以帮助我们更好地评估需求变更对项目的影响度。3. CMMI级别三的需求管理在CMMI级别三中，组织需要建立、归档所有项目中所使用的公共的和一致的流程。需求开发需求开发过程将解释如何抽取责任人的需要、导出用户的需求声明，并把这些用户需求进一步分析/总结成为相应的系统需求。CMMI对

21、需求开发定义了以下几个目标：组织必须能够将收集来的责任人的需求转换成用户需求“将收集来的责任人的需要，期望值，约束条件和接口定义转换成用户需求。在一般情况下，责任人的需要并没有被很好地定义和理解，这些需要甚至可能是不一致或相互矛盾的。一个责任人的典型代表必须参与产品开发的整个生命周期。在这个生命周期中，必须反复地定义，阐述和明确这些需求，最后总结出一组清晰的，被正确理解的用户需求。以上过程非常类似于邀请客户代表进入项目队伍参与全周期的开发工作。此外，对需求采集和阐释的技巧也是极其重要的，目前较流行的是Use Cases方法。Use Cases方法是一套在不同的使用场景下，从用户的角度出发，构造

22、和记录功能性需求的方法。单个的UseCase只能记录简单的文本，最好的方式是使用UML中的Use Case视图对一组UseCases进行描述，并表示它们之间的相关关系。因此，需求管理工具必须能够支持在文本说明的需求声明中插入相关的UML视图，并可将文本和视图同时显示在一个文档中。组织必须可从用户需求分析出系统需求“对用户需求进行推敲和细化以开发出对系统需求。对用户需求进行彻底的分析，识别出所有已暗示但没有被清晰表述的需求，再结合所开发目标产品的技术架构细节，可得出该产品的系统需求。系统需求根据产品的规模和复杂度，可细化成系统需求、子系统需求、模块需求等。在这个过程中，必须同时建立起不同需求之间

23、的可追踪性，为后续的决策指定提供参考，并支持需求变更影响度分析。根据CMMI要求，在技术架构的基础上，通过对用户需求的分析可推导出系统需求。因此，需求管理工具需要支持实现这种推导，这种推导的支持不仅包括在不同层次的需求之间创建可追踪性，还包括提供可分析上层需求的技术和相关方法。在UML建模方法中，可通过UseCase视图,Activity视图和Sequence视图等有效的方法来帮助分析和导出新的需求，上层的技术架构通过Architecture视图（也称为复合结构）进行描述。这些方法都要求在需求文档中建立模型，用来记录分析和决策过程，从而为下一步提出开发技术方案提供指导。组织必须能够验证需求:“

24、需求必须可以被分析和验证，同时必须开发出对“必需的功能性”的定义。当那些非正式的需要转化为正式的需求时，需求的分析和验证对于确定责任人需要、用户需求、系统需求等是否可行，是否可以在预算范围内达到，是否跟当前系统运行环境相匹配都是非常必要的。用于需求分析和验证的技术包括按时间顺序的使用场景验证需求，并提推导新的需求。场景方法是一种有效的采集，阐述和推导需求的方法，在这个方法中我们常用UML中的Activity视图或Sequence视图来表示场景。“必需的功能性”的定义是通过功能性分析建立起一整套功能性的架构。功能性分析描述了系统的行为，时序活动，输入输出以及其他所有对该系统应用的描述。功能性架构

25、则从逻辑上描述了一组功能（或服务）和需求是怎样相互满足的。UML的Activity视图能够从工作流的角度描述系统的活动行为，并且可以识别负责这些工作流的相应组件，这些视图在描述功能性分析，以及将需求进一步分配到子系统级别时非常有用。因此，需求管理工具应该能够支持图形化模型和文字性的需求说明存在于一个单一的文档形式中，并且这样文档形式可以支持不同层次间需求的追踪关系（无论这些需求是以文字形式还是以UML的图形化模型表示）。技术解决方案在这个过程域中，我们需要关注的是评估和选择设计方案，进行详细设计，最终实施。那么这些和需求管理又有什么关系呢？组织必须首先确保他们可以持续地开发出满足需求的解决方案

26、，一种方法就是通过验证所产生的设计来确保初始方案是正确的。在这个过程中，组织应该能够发现那些不切实际的，或因定义不够充分而无法实现的需求。同时，组织应该允许需求在整个设计过程中不断地充实变化，但这一点的前提死必须保证这些变化是可控制的。所以，可追踪性不仅体现在不同层次的需求之间（用户需求，系统需求，子系统需求等），也应该体现在需求和解决方案之间。我们应该保留从责任人要求到系统和子系统需求的分析过程和分析方法，以便我们在设计和编码阶段仍然可以遵循这些过程和方法。因此，需求管理工具应该能够让后续的系统设计者和开发者可以浏览、创建和维护最初的需求和他们设计之间的可追踪性，并以此检验后续设计/开发工作

27、对需求的依从性，以及对需求变更的影响度估计。由此，需求分析员和项目经理应该具有从系统责任人要求到系统具体设计/开发/测试间的可追踪性有一个完整概念，这个可追踪性可以让他们做到基于需求的项目过程监督，并可以保证所有的开发和测试工作与需求 保 持一致。 2.2软件系统开发策划1. 什么是模型 模型:所研究的系统、过程、事物或概念的一种表达形式模型可以是物理实体，也可以是某种图形或者是一种数学表达式。 用这种方法处理可以大大减少实验工作量，还有助于了解过程的实质。 因此传统的因次论、相似论方法不再适用，这时可用模型法进行研究。 50年来，大部分软件项目都成了令人头痛的业务活动。在许多商业活动中，软件

28、项目被取消或者是被延误的概率都是最高的。一旦开发完成交付用户使用后，就会暴露出大量的错误和产品的低可靠性。 Capers Jones,Software Quality 软件项目的成功率至今才只有35%左右，我们现正以每年平均1.7%的速度增长。若按此速度提高，到2014年也才只是达到50%的成功率。Joe Marasco, 30多年前，软件维护曾被描述为“冰山”，我们要对付水下那些看不见的，却是大量的潜在问题和成本。上世纪70年代初要解决“冰山问题”的成本已足以使一艘航母沉没。而今天，这块冰山却能轻易地让整个海军沉没海底。Roger Pressman 如何解决如何突破软件危机已经取得的共识重视软件过程与软件过程改进 Watts Humphrey 的著名论点： 软件系统的质量是由开发它所遵循的过程质量决定的 。 有什么样的过程质量就有什么样的软件产品质量 为使软件项目开发不延误交付，不超支更需要在开发过程中加以控制 要解决软件危机，首要任务是把软件活动视作可控的、可度量的和可改进的过程。 Watts Humphrey 的过程改进原则 过程改进是自上而下的 相关的每个人都要参与 有效的变更需有对过程目标的深入了解 变更需持续进行 软件过程变更需要自觉地努力和定期的强化 需要有必要的投入 许多支持过程改进的