小型软件开发单位软件过程改进模型探讨.doc

小型软件开发单位软件过程改进模型探讨软件能力成熟度模型(CMM)被国际软件界公认为是软件工程学的一项重大成果。它既可用来科学地评定软件开发单位的软件能力成熟度等级,也可用来帮助软件开发单位进行自检,了解自己的强项和弱项,从而不断地完善单位的软件开发过程,确保软件质量,提高软件开发效率1。三分之二的软件公司只有20个或更少的雇员4。小公司常常为事务或大型系统的专用部分提供用户的特定解决目标。对这些公司而言,生产高质量的软件很重要,因为它将决定整个系统的质量。尽管小公司是占多数并生产重要的产品,但在过去的十年里,有关软件质量的探讨通常以大组织为目标,而对小组织未提出特定的要求。1小型组织中过程改进所面临的困难软件界从过程改进中所获的经验主要是源于大型组织执行CMM或建立ISO9001质量体系。尽管进程改进模型没有否定它们在小组织中的应用,但合适的数据很少。面对着公布的少量证据,很难去为小软件组织建立一个ISO9001合适的质量体系。一些研究者已经指出小公司面对的潜在障碍,特别是在改进活动的评估阶段。通过分析,我们认为困难主要表现在三个方面。1.1关于组织结构中相关的困难小型软件组织的结构最重要的是确定过程开始。通常这些组织缺乏对任务、职责以及过程的正式定义。他们主要关心日常事务,未做长期规划。小组织的文化也阻碍了他们生产大规模、高质量产品或满足用户不断增长的要求。关系到组织的结构,软件初始过程的困难被归纳为以下几点：(1)缺乏有质量意识的人员。在小型软件组织一般没有人员具有软件过程改进经验或接受过培训。大多数雇员很可能对其它组织质量的基本情况毫无所知。虽然他们知道概念和技术,但仍可能缺乏一种对解释他们自己组织所要求的质量模型基本原则的理解。(2)人员数量较少。由于人少,通常不可能成立专项过程改进小组。过程改进的努力对大多数高级技术人员成了一种额外的责任。然而这些人很少有改变现状的推动力,因为在当前结构中已形成了这样的现状。(3)有限的经费。小型软件组织通常运作小预算,且面对市场情况更显脆弱。甚至对改进工作(如评估和培训)所需最初的投资,对那些一夜间资金周转会改变的组织而言似乎都不能实现。因此对这些组织而言,为一个长期过程改进项目投入资源更加困难。(4)当前过程的状况。通常,小组织处于CMM一级。尽管对质量体系可接受的能力在CMM框架中不低于三级,并且也建立了ISO9001体系要求相似的能力。经验表明,从一级水平(公司)要达到三级能力成熟度需花费46年的时间。对大多数小公司而言,这样长时间的投入是不可能的。(5)非软件过程的问题。小组织常常缺乏与软件开发不直接关联的组织过程的成熟度需求。这在解决相关软件开发中的问题时带来了更多的困难。进一步说,它要求过程改进能在更多新领域中实行。(6)黑客文化。小型软件组织通常有黑客文化,极端时依靠一些非常有天赋的程序员。尽管这些人非常有效,但他们常常会超负荷。通常的问题是如果主角离开,没人能做任何事。每次改进的第一步包括主角,并且在分发消息和分配职责时均与其利益挂钩。(7)缺乏定量的数据。小型软件组织一般不能收集资料以度量过程和性能。这与他们未定义过程及他们运作的开发模式紧密相联。然而由于组织起步前的状况是未知的,并且很难去定量起步时的早期结果,所以缺乏定量的数据,这将为软件过程起步的带来困难。1.2关于软件过程改进模型的困难CMM和ISO9001这些广泛适用于软件过程改进的模型,它们从小组织中继承了许多问题,归纳为以下几点：(1)缺乏指导。质量模型,特别是ISO9001,解释那些已有的质量体系要素,然而对在何处开始,如何建立这些属性等问题上未能提供任何指导。CMM在这点上比ISO9001好,定义关键过程域将依靠现有的过程状况而着手。然而对小组织而言,没有资源去并行地开始所有关键过程域,也没有指导如何去进行。当以一个错误的顺序进行时,那么一个特定的过程域改进成果可能对开发者而言是肤浅的,结果是失败的。ISO9000-3和TicIt的研究尽管明确了一些ISO9001内容,但未能对软件组织提供充分的帮助。(2)缺乏行为知识。那些在软件过程改进上缺乏专家见解的小型软件组织,对于如何在其公司内运用一个质量模型的需求还需要详细的指导。在模型中行为知识缺乏,部分因为它依赖组织的状况、规模及资源。然而模型能提供一个定制框架,特别是在改进的初始阶段。(3)未能从小中受益。现在的过程改进模型未能受益于小规模的优势,即灵活性、快速反应性,以及容易交流特性。由于小型软件组织的成功很大程度上依靠它们,所以这些特征在改进初期被保留。例如严格的系统满足模型的需求,严格的系统更多依靠书面交流而不是直接交流。通过允许软件开发小组去直接涉及所有的活动,灵活性以及增强的交流被利用来更早更快地建立质量系统要素。(4)假设有多个领域的专家知识。现在的过程改进模型蕴含地假定了一个软件组织有资源去组成不同的小组,同时处理不同的过程问题。大部分需要在组织中建立的过程(例如度量程序),要求非常专业的知识。小组织由于人员受限,不能使模型适应于他们的现实需要。1.3关于小组织运作市场中的困难小组织运作市场有许多影响改进初期的独特属性。通常小组织更紧密地与用户联系,对于市场经济而言更脆弱。关于市场方面的困难总结如下：(1)易改变性。小型软件组织生产软件定位于数量较少的用户,它们更接近其用户。尽管更接近有助于组织了解用户需求,但它也带来了下列问题：客户以为改变软件是一件容易的事,随着环境的变化,他们随时提出变更需求。(2)投资的低回报。小型软件组织通常操纵有限用户的小型市场。如果组织不能扩展其市场,那么每个产品投资回报将低于公司的预期值。2在小型组织中软件过程改进：一种模型及其执行某软件公司(以下称为A公司)为了面向国际市场,选用ISO9001质量模型来提高质量。由于在A公司和ISO9001咨询公司内缺乏软件质量方面的专家,迫使A公司寻求外界的顾问帮助。A公司由7名程序员组成,它的主要产品是几个应用的集成系统,它为产品分发部门提供一完整解决方案。系统按小公司提出的要求定制。产品由600多个程序、总计40万行C语言代码组成。本文提出了一种软件过程模型,适合具有第一节所提困难的公司。模型的每个活动都要求所有相关人员的参与,有时甚至是整个开发小组,而小规模的组织使得这种参与可能性更高。因此在组织内部应将软件过程改进职责和积极性落实到所有员工。该模型综合了CMM定义关键过程域、ISO9001和ISO9000-3的需求和建议。模型为过程改进提供工作计划,并使ISO9001和CMM需求适应了小组织的现实。为了在组织中不让少数开发人员负担过重,同时保持必须的质量要素,过滤和改进待启动的活动、待产生的文档、待建立的角色。模型包括以下三个阶段。2.1准备阶段本阶段的主要目标是为过程改进启动准备组织。明确告知所有雇员目标、潜在的收益,以及起步的风险。每个人应该知道所期望的是什么,以及这些研究如何影响他们的日常活动。在准备阶段,组织需要完成以下三个活动：建立顶层管理约定。顶层管理约定是对任何质量起步阶段所必须的。如果顶层管理未展开这个项目,那么在行动前建立约定。论证顶层管理约定。一旦制定顶层管理的约定,管理者将向所有的雇员证实。这可以通过一个预备会议,也可通过在资源分配和重构方面的改进活动持续支持。评估过程当前状况。如果按照正式的CMM和ISO9001评估,小组织的评估过程可能会提供不正确的数据。面对面,自由式会见所有与软件开发相关联的个人,是在该模型中使用的一项技术。会见围绕一套问卷,参照为随后控制阶段定义的关键过程域,调查已有的软件实践。这些自由式的会见也提供了组织的文化信息,对明确改进初期潜在的障碍非常有效。该活动的结果以报告形式提交给顶层管理部门。准备阶段的执行在A公司的这个项目中,质量体系工作由首席执行官(CEO)负责。在预备性会议上,将该项目内容介绍给与会人员,并作出适当分工,需要时,作出资源分配。在执行完会见后,评估不仅提供了过程困难的鉴别,也提供了有价值的组织文化、人际关系以及不同小组的期望等信息。与CEO、软件经理、软件开发小组和客户援助小组的会见在3个整天内完成。会见讨论了更大范围的论题,包括公司的历史、长期的策略、管理问题、在软件开发中的实际操作,以及开发小组与其它部门、客户间的关系。评估结果显示A公司处于CMM一级,软件开发和管理的过程没有完全确定,而项目是基于日常事务以及个人决定来管理。会见也揭示了组织的几个问题,其中一些问题在潜意识中阻碍了改进过程的努力。这些问题包括开发队员的自信不强,开发人员过紧的进度安排,对软件工程原则不够充分的知识,组织的学习问题,缺乏反馈。另一方面,也观察到许多有益于改进初期的特性,如顶层管理的约定,对产品的信任度,以及高质量工作意愿。2.2控制阶段控制阶段的主要目标是建立严格的约定、成本、进度、变化的管理,所有这些都必须确保开发处于控制之下。为了能达到这个目标,本文引入的模型引导组织重点关注项目的计划及跟踪、配置管理以及产品工程等三个关键域。一个典型的小型软件组织缺乏对这些过程域的明确规程,但如果在一个域中存在这些规程,那么注意力将转向其它的。软件开发部门为每个过程域分配12人,形成多个研究小组,这些小组将从事以下所给的活动,这些活动的进度依赖于软件开发小组的工作量,而其中有些活动能够同时进行。(1)短训班。在通过有关特殊过程域的一般概念、技术的短期培训之后,采用短训班的形式讨论如何在组织内应用这些概念和技术,以及提交给整个软件开发小组的工具的有效性。(2)工具的选择。基于在短训班中建立的知识,在组织内选择使用一个合适的工具。工具选择的准则是由使用它的人来决定。除了每个过程域标准需求,还要考虑它易于被学习,价格合适,以及广泛的可利用率,并易于集成到当前环境中。(3)定义过程。基于在短训班上讨论过的信息,以及所选工具的特性,定义在特定过程域内待执行的活动。如果组织的目标是ISO9001认证,这些定义将形成质量体系的规程。对另一些组织,定义在这些过程域中如何实施,将有助于改进相关过程。(4)集成。一旦所有的小组都完成其独立的研究,需要举行几个集成会议以解决在不同过程域中的冲突。这些会议将有助于开发小组彼此了解,简化他们的日常活动,使他们所需建立的文档最少。已定义的所有过程应保持一致性。(5)试验项目。在试验项目中为了明确实际问题以及效果如何,应对所选择的工具、所定义的规程进行试验。因为这些活动中的大部分对软件小组而言是新的,一些问题也许只会在执行中碰到。执行控制阶段在A公司中,控制阶段的活动在任何可能的时候同时被执行。与每个过程域相关的活动相隔3个星期开始,每个7人开发小组的工作量保证在合理的限制以内。下面叙述在控制阶段的具体做法：小组用4天时间去研讨每个过程域。项目计划和跟踪小组包括软件经理、开发员等3人；配置管理小组包括低级、高级开发员各1人,1名咨询员；产品工程小组包括软件经理、开发员等3人。每个研究小组每45个月花1周时间开会讨论工具和规程。每个会议由相应的咨询员和小组成员参加。集成阶段,在2个月中每周有2次会议进行激烈的讨论-如何实施特殊的过程。这些会议由所有的咨询员以及每个研究小组派1名代表参加。为配置管理和项目管理选用微软工具。尽管这些工具不能提供全部功能特性,但它们价格合理,并且在Windows平台上能与其它工具集成。产品工程第一步是去执行逆向工程,以收集系统的设计和分析数据；然后购买一个便宜的工具CDOC,以从现有的C代码中收集数据,形成一个Access数据库,用以存储程序、文件、全局结构和它们的关系等信息；再用VB全面扩展此数据库,以助开发者去查询数据,建立报告,同时增加新的实体。经过较长时间的讨论,定义了基于源安全特征、配置管理的策略。配置小组为编译、备份和分发定义了一套新的规则。基于现有的标准确定一个正式的项目计划。此时项目被划分为几个构件,对每一个构件,应考虑完整生命周期,需要时,可销售早期的构件。经过较长时间讨论后定义产品的生产周期。简化了软件组要执行的活动,确定了在早期阶段所涉及的开发人员。在新的生命周期内利用工具辅助开发人员工作。工具检查相关的程序、文件,并在后来登记时更新数据库。定义并集成项目计划和跟踪,配置管理生命周期过程。变更管理被视为生命周期规程的特定情况。11用项目需求表和任务需求表追踪工作流。项目需求表来源于生产计划部,并维持有效性直到任务被交付给客户。任务需求表包括相应变更需求的信息,或软件小组在项目分析阶段定义的任务。表单存放在一个独立的数据库中。12在过程中生成表单,包括与它们正在使用的过程相关的度量信息。例如,任务需求表含有规模估计,以及由开发者所填的实际规模输入。另外定义一个独立的表单,用来收集个人开发者以周为单位的实际成效和时间耗费的数据。它们共同形成公司度量程序的基础。在控制阶段的最后活动,即试验项目,是与早期结果相符的。然而考虑到相关程序与其后的不一致,我们已决定延迟度量程序的应用一直到稳定阶段。小组成员勉强填写度量表单,并且这些表单如何填,何时填的不一致性降低了所收集数据的可靠性。因而如下的结果被观察到：a)软件小组的高积极性和自主性；b公司内基于软件小组的观点达成共识；c)公司内软件小组成为一个受尊敬的单位；d)生产处于严格的配置管理下；e)建立了项目管理原则,并且在预算内准时完成近期的项目。2.3稳定阶段在稳定阶段,在建立产品的组织和过程以及过程的质量中,严格运用产品工程。需求管理、正式测试和评审、质量保证是需要注意的过程域。在早期阶段定义的生命周期又依据这个阶段的结果来扩展。另一个要执行的关键任务是建立度量程序。一旦过程稳定其中一些在控制阶段确定的数据收集表单将被用于收集相关的过程信息。在控制阶段同样的活动将在新过程域中执行。换句话