软件开发模型范文

2024-06-10

软件开发模型范文（精选11篇）

软件开发模型第1篇

关键词：瀑布模型,快速原型模型,增量模型,螺旋模型

软件开发是一项极其复杂的脑力活动, 通常要将其分为若干阶段分步完成。制定计划、需求分析、设计、编码、测试及运行维护等活动组成了软件开发的生命周期。在开发产品或构建系统时, 遵循一个科学的、成熟的系统模型, 合理组织这些过程相当重要。这些模型好比路线图, 为软件工程师及管理人员提供了稳定、可控、有组织、有质量保证的开发蓝图。目前应用比较广的软件开发模型有:瀑布模型、快速原型模型、增量模型、螺旋模型。这些模型都有自己的适应场合, 各有利弊。

一、瀑布模型

1970年Win STon Royce提出了著名的“瀑布模型”, 直到20世纪80年代早期, 它一直是唯一被广泛采用的软件开发模型。该模型如图1所示。

该模型规定软件开发活动按照图示次序从上而下、相互衔接地进行, 如同瀑布流水般环环相扣逐级连接, 次序不能颠倒;并且该模型是文档驱动型, 每一阶段经过多次核实、验证后应产生相应的文档, 作为下一个过程继续的基础, 即前一阶段的输出文档成为后一阶段的输入。

(一) 优点。

可靠性高。因为每个阶段都有严格的论证, 保证相对正确后才进行下一步, 因而软件开发的质量有保证, 并且可以尽早发现隐患、减少风险、避免损失。

(二) 缺点。

一是时间周期长。瀑布模型由于有严格的顺序过程, 负责后面流程的成员要等待其所依赖的前一步的任务才能进行, 很有可能出现等待时间比开发时间长的“堵塞状态”, 同时也不利于人力资源的合理配置。二是不能应对变化的需求。毕竟需求分析阶段也不一定能百分百地获取用户需求, 况且软件行业日新月异需求变化越来越频繁, 用户一旦提出需求变更, 将会给软件开发带来灾难性的后果, 前期的工作有可能全部否定, 带来大量的人力、物力、财力的损耗。

二、快速原型模型

对于瀑布模型, 软件成果与客户见面的时间太晚, 不能灵活应对需求的变化。快速原型模型能够很好地克服这个困难。该模型要求尽早提出一个可视化的软件模型, 以便与用户沟通、讨论、分析, 使抽象的语言描述落实到具体的方案上。最初的模型可以是非全面的, 后经过用户的反馈不断进行修改, 直至用户满意认可。原型可以是页面形式、甚至是纸上画草图的形式。目前常用的原型工具有Axure, Prototype Composer, iRise, GUI Design Studio等。

(一) 优点。

一是尽早确定用户的模糊需求。用形象的软件原型进行沟通要胜过模糊不清的语言描述。二是“快”使得新产品更容易争取客户。

(二) 缺点。

原型一般是快速建立起来的, 比较粗糙, 漏洞比较多;而在此基础上建立的系统很有可能需要连续不断的修改, 甚至最初的模型会被彻底抛弃。

三、增量模型

该模型的核心思想是将整个软件任务划分成若干独立的功能模块 (或增量部分) 。先从核心功能模块开始, 分别进行软件的分析、设计、实现及集成测试, 一个模块测试完毕后再开始下一模块 (增量) 的开发工作, 直至整个系统开发完毕, 如图2所示。

(一) 优点。

一是由于增量模型可以最先把核心功能模块交付给用户, 因此能够解决用户的一些急用的功能;二是这种分批的交付方式使得公司能够更灵活地安排人员、资金, 这一点对于小企业来说尤为重要。

(二) 缺点。

主要体现在风险性上。由于每个模块是按流水线方式呈现的线性序列, 逐步进行需求分析、设计、实现并提交。前后模块的设计、开发交错进行并互相关联, 这时若前模块设计有误, 会影响以后的各模块, 因此此过程存在较大的潜在风险。

四、螺旋模型

在增量模型中, 我们提到了软件开发的风险。其实, 软件风险评估是软件开发过程的一个重要步骤, 少了这一步骤后果可能不堪设想。1988年, 软件系统开发的“螺旋模型”正式发表, 它强调了其他模型所忽视的风险分析, 特别适合于大型复杂的系统。螺旋模型是若干可发布的快速原型的迭代, 每个原型都要经过四个过程:一是制定计划:制定目标、选择方案。二是风险分析:这一步至关重要, 若分析不到位, 就失去了使用该模型的意义。使用该模型, 企业应具备专业的风险分析人员, 能够掌握风险分析的算法、工具, 有较强的分析经验。三是实施工程:按瀑布模型步骤进行设计、编码、测试等。四是客户评估:让客户提出该版本的修改意见, 也为下一版本做基础。重复以上四步, 直至生产出完整的、满意的产品。

(一) 优点。

显而易见, 最大限度降低需求阶段的风险是该模型最突出的优点。每生产出一个完善的软件版本, 都是在风险可控的情形下, 逐步迭代, 直到最终形成一个用户满意的产品。

(二) 缺点。

风险评估的关键是有优秀的风险分析人员, 该人员的素质如何、能否及时识别风险将成为最大的风险。

五、结语

以上介绍各模型没有优劣之分, 只有在某具体项目中适合不合适的区别。现将各模型的适用范围进行总结, 如表1所示。

探讨软件开发过程模型的发展论文第2篇

0引言

从第一个软件开发过程模型一“瀑布模型”的产生到现在，人们陆续推出了许多软件开发过程模型11。这些软件开发过程模型是如何产生和发展的?软件开发过程模型还会发展吗?软件开发过程模型如何发展?研究这些问题对于推动软件工程理论向前发展具有重要意义。下面对这些问题进行研讨。

1对几个典型的软件开发过程模型的分析

下面分析几个典型的软件开发过程模型的产生情况，通过分析，既可以看到它们的内容又可以了解它们产生的原因。同时，也可以从整体上看到软件开发过程模型发展的大致过程，在此基础上思考软件开发过程模型的产生和发展问题。

1.1瀑布模型的产生情况

早期的软件开发活动带有明显的个体化特征，非常不规范，随意性很强，人们错误地认为软件就是程序，对程序之外的数据和相关的文档材料没有给予重视，对编写程序之外的软件开发活动(如需求分析、概要设计、详细设计、软件维护等等)没有给予重视，结果出现了软件危机。软件危机的典型表现有:开发成本急剧上升、开发进度一再拖延、软件难以维护甚至无法维护、软件质量无法保证、开发出的产品不能满足用户需要，等等。为了摆脱软件危机，人们开始研究软件开发方法，1968年提出“软件工程”的概念，主要思路是将人类从事各种工程项目积累起来的行之有效的原理和方法应用于软件的开发和维护活动中。在这种情况下，1970年瀑布模型被推出。

计划到开发成功、交删，再到废弃不用，有一个完整的生命周期，称为软件的生命周期。瀑布模型按照软件的生命周期，将软件过程分为:问题定义、可行性研究、需求分析、概要设计、详细设计、编码、测试、维护等几个阶段。软件开发活动按顺序一个阶段接着一个阶段地进行，每个阶段完成一项特定任务，每个阶段的结果经审查合格后方能进入下一个阶段。瀑布模型严格地规定了每个阶段必须提交的文档，强迫开发人员采用规范的方法，要求每个阶段提交的产品必须经过专家的仔细验证。这样，软件质量得到了保证。由于各阶段提交了规范的文档，软件维护变得容易一些。瀑布模型的成功在很大程度上是由于它是文档驱动的模型。

瀑布模型的推出，是人们为了摆脱软件危机迈出的重要的一步。按照瀑布模型去进行软件开发活动，克服了开发中的个体随意性和不规范倾向，使软件开发有章可循，有效地遏制了日益蔓延的软件危机。

1.2快速原型化模型的产生情况

按照瀑布模型开发软件，虽然很有效，但灵活性不强，因为瀑布模型是按阶段顺序来操作的，必须在前一阶段的工作完成后才能进行下一阶段的工作。需求分析是一个重要的阶段，由于在开发早期用户的需求往往是模糊的，或由于某些原因用户的需求要发生变化，导致需求分析阶段的工作无法结束，造成下一阶段的概要设计工作无法进行。这时如果继续采用瀑布模型进行软件开发活动，显然不妥，因此为了解决这类软件开发问题，必须构建新的软件开发过程模型。在这种情况下，快速原型化模型被推出。

人们认识未知的事物，往往按照“实践、认识、再实践、再认识，逐步完善”的规律去做，经过反复多次的迭代式的实践和认识过程，达到基本了解事物情况的目的。快速原型化模型按照这个规律进行软件开发活动，首先快速建立一个能反映用户主要需求的原型系统，请用户在计算机上试用，通过试用，用户提出修改意见;开发人员按照用户意见快速地修改原型系统，然后再让用户试用;然后开发人员按照用户意见再去修改;如此反复多次，直到原型系统完全满足用户需求为止。

采用快速原型化模型进行开发活动，有效地解决了用户需求模糊不清和用户需求不断变化的问题。可以认为快速原型化模型是对瀑布模型的补充和完善，瀑布模型是用静止的观点来看待软件开发活动，将用户需求看成是固定不变的，这样实际上是将用户需求简单化了，这种理想状态实际很难找到。快速原型化模型是从变化的观点来看待软件开发活动，符合客观型化模型的这种观点。

1.3增量模型的产生情况

采用瀑布模型或采用快速原型化模型来开发软件时，是按照模型规定的开发过程，完成各开发环节的所有任务，得到一个完整的软件，将其提交给用户。面对软件规模越来越大、软件市场竞争越来越激烈、用户要求越来越高的形势，这样开发存在很多问题。当你将一个大的.完整产品提交给用户后，用户要花费很多时间来学习这个新产品，短时间内很难适应这个新产品，给工作中应用该产品带来不便;这个产品完整提交后，用户再去评价和提出修改意见就没有意义了。这样，使开发风险加大，使开发时间增长，使用户满意度降低。为了解决这个问题，必须构建新的软件开发过程模型。在这种情况下，增量模型被推出。

人们解决大问题时，往往是将大问题分解为若干个小问题，每个小问题比较容易解决(其中有一个小问题是核心的关键问题)将这些小问题分别给予解决(对于核心的关键问题首先给予解决)，那么大问题也就被解决了。一般来说，分解出的每个小问题具有相对独立性，即每个小问题与其它每个小问题联系不紧密，这样，既可以一个接着一个地顺序去解决每个小问题，也可以同时去解决多个小问题。增量模型按照这样的方法进行软件开发，将一个大的软件分解为一系列较小的“增量”，每个增量分别进行开发，通常开发的第一个增量是软件的核心部分，实现软件的基本需求。向用户一个增量接着一个增量地分批提交软件产品。采用增量模型，用户从拿到第一个增量时开始，就可以学习和熟悉软件，通过使用来评价软件及提出修改意见;开发人员根据用户对已经提交的增量的反馈，可以改进软件产品。这样，提交所有增量后，软件产品就达到比较完善的程度，也提高了用户满意度。

1.4螺旋模型的产生情况

软件开发从始到终都存在着风险，项目规模越大、软件越复杂，开发该项目所冒的风险就越大。并且风险具有不确定性，可能发生也可能不发生，但是一旦风险变为现实，就会造成损失，甚至产生恶性后果。因此，如何识别风险、预测风险、驾驭风险，将风险可能造成的危害消除或减少，是软件开发中必须要考虑的问题。但是在螺旋模型之前所提出的各种软件开发过程模型，都没有强调“风险分析”。在这种情况下，螺旋模型被推出。

其实人们做任何事情之前，都要考虑风险。如果存在风险，那么一定要想办法去消除，否则成功希望渺茫。螺旋模型是在结合瀑布模型和快速原型化模型的发框架上，带有瀑布模型的系统性、顺序性和“边开发，边评审”的特点。螺旋模型也是一种迭代模型，每一次迭代均可采用快速原型化模型方法，每一次迭代均作风险分析。螺旋模型由若干个螺旋周期组成，每一周期都包括需求定义、风险分析、工程实现和评审四个阶段，当项目按顺时针方向沿螺旋线移动时，每迭代一次，螺旋线就前进一个周期，软件开发又前进一个层次，系统又生成一个新版本(即构造一个新的原型，这个新原型是在风险被排除后得到的)，当迭代过程进行到用户允许或可接受的范围时，迭代结束。

螺旋模型的推出，强化了人们的风险意识。通过使用原型来降低风险是一种行之有效的方法。螺旋模型集成了瀑布模型和快速原型化模型的优点，又有自身的特点，是一个实用性很强的软件开发过程模型。

1.5构件组装模型的产生情况

面向对象技术出现之前所提出的各种软件开发过程模型，一般很少考虑“软件构件”的重复使用问题，即使编程时重复使用了一些库函数，量也不大，并且粒度小。因此，软件开发的任何一项工作基本是从头开始做，完整地做到尾。这样开发的缺点是成本高、时间长，当然出错的可能性也大。这里的“软件构件”一般指源代码，现在将需求规格说明、用户界面、软件体系结构等等也作为“软件构件”。人们考虑:如果在开发新软件时，能大量地重复使用已经开发过的软件中的内容，开发时间和成本不就降低了吗?又由于已经开发过的软件经过了严格的测试，重复使用这些内容在质量上当然是有保证的。面向对象技术的出现，为这个想法开辟了道路。在这种情况下，构件组装模型被推出。

重复使用的思想早已在许多领域广泛应用了，例如在工业生产中，重复使用各种零部件来组装生产新产品。在软件生产中，由于每个软件与其它软件都不同，在面向对象技术出现之前，重复使用难度比较大。面向对象技术将数据和操作该数据的算法封装在一起，做成一个个的“类”，将一个或多个相关“类”组合成一个“软件构件”，在某领域内使用过的所有“软件构件”被放到一个“软件构件库”中，这样为重复使用打下了基础，构件组装模型就是通过重复使用“软件构件库”中的软件构件来进行软件开发。使用构件组装模型开发软件时，根据被开发软件的目标和开发方案，选取软件构件库中的软件构件，组装成一个完整的软件版本。

构件组装模型的推出，使前人的劳动成果被有效地利用了起来。按此模型进行开发活动，可以节省时现，使软件开发工作开始进入一个新时代。

1.6几个软件开发过程模型产生情况小结

从以上分析几个典型的软件开发过程模型的产生情况可以看出：软件开发过程模型的出现，是人们为了消除软件危机、使软件开发活动有序化和规范化、高效率地得到高质量的软件产品而不断研究总结的结果，每一种新的软件开发过程模型的出现，都为当时软件开发遇到的某一类问题提供了解决方案，从而丰富了软件工程的内容，推动了软件工程理论向前发展。

2.促使软件开发过程模型发展的主要因素

现在已经有了这么多的软件开发过程模型，软件开发过程模型还会发展吗?答案是肯定的。通过上面的分析过程和深入的思考，可以得出促使软件开发过程模型发展的两个主要因素：

第一，客观世界的情况在变化，不断出现新的问题，需要用计算机处理。面对新情况和新问题，原有的软件开发过程模型无法胜任，因此需要推出新的软件开发过程模型来处理新情况和新问题。回顾软件开发过程模型的变化和发展的历史，许多软件开发过程模型是为了处理新情况和新问题而推出的。例如快速原型化模型是针对用户需求不完整和用户需求不断变化的情况而推出的。例如螺旋模型是针对风险控制问题而推出的。例如文献[5]所介绍的建立在面向Agent技术上的Gaia模型，是针对现有的软件开发过程模型在开发复杂分布软件系统时常常遇到困难而推出的。例如文献[6]所介绍的一种基于Agent的自适应软件过程模型，是针对软件过程所处的环境发生变化问题而推出的。

第二，人们希望软件开发的效率更高、质量更好、速度更快，因此人们不会满足现状，势必要研究并推出新的软件开发过程模型。例如构件组装模型的推出，就是人们不满足现状、遵循“重复使用”的思想所推出的软件开发过程模型。再如文献[7]所介绍轻载(敏捷)软件开发方法中的XP模型(极限编程)，也是人们不满足现状，针对传统模型存在的问题，按照新的理念所推出的软件开发过程模型。以上两个主要因素显然会长期存在，因此软件开发过程模型必然还要发展。

3.软件开发过程模型如何发展

既然还会有新的软件开发过程模型被推出，就是说软件开发过程模型还要发展，因此人们要思考软件开发过程模型如何发展这个问题。根据对软件开发过间.降低成本，软件质量也有紙构件组装模型的出程模型有关情况的分析研究，软件开发过程模型可以

按以下三个方向去发展：

第一，可以通过对现有模型进行改进、扩充、综合去发展。

结合新问题的内容，针对现有模型存在的适用面窄、考虑问题欠周到等情况，可以通过改进和扩充某个软件开发过程模型的内容而得到一个新模型，或者通过综合运用几种软件开发过程模型的内容而得到一个新模型。如文献[8]介绍的一种新的软件开发过程模型，是在瀑布模型基础上进行改进和扩充的结果。再如增量模型，是综合运用瀑布模型和快速原型化模型的结果。再如文献[9]介绍的一种新的软件开发过程模型，是综合运用瀑布模型和构件组装模型的结果。再如文献[10]介绍的一种新的软件开发过程模型，是综合运用构件组装模型和并行过程模型的结果。

第二，软件开发过程模型可以遵循新的思维方式去发展。

现有的软件开发过程模型，每一个都体现出各自不同的思维方式，例如瀑布模型是所有采用线性思维方式模型的典型代表，快速原型化模型是所有采用反复循环迭代思维方式模型的典型代表。遵循新的思维方式去发展，就是说，新建立的软件开发过程模型应该是新的思维方式的体现，即按照新的想法去组织软件开发活动。例如XP模型(极限编程)就是按照新的思维方式去发展起来的。从Agent具有自主性、反应性、社会性等角度看，各种面向Agent的软件开发过程模型都是按照新的思维方式发展起来的。

第三，软件开发过程模型可以借助新技术和新工具去发展。

任何软件开发过程模型都是建立在一定的技术和工具基础之上，技术和工具的进步对软件开发过程模型的影响是巨大的，当新技术和新工具出现后，传统的开发方式势必要被改变，所以说新技术和新工具会推动软件开发过程模型更新发展。如构件组装模型、基于体系结构的软件开发过程模型，就是在面向对象技术基础上发展起来的。再如RUP[12]模型，就是在UML这个开发工具基础上发展起来的。

4 结束语

软件工程方法模型浅析第3篇

关键词：软件开发模型；瀑布模型； V模型；迭代模型

中图分类号：TP311 文献标识码：A 文章编号：1006-3315（2014）09-120-001

一、前言

当今时代，软件的重要性与日俱增，从办公生活到休闲娱乐，日常生活中每时每刻都有软件的身影。企业要提高运作效率，家庭要提升生活质量，电商要提升营销精准度；政府要提升公众满意，无不需要依靠各种各样的软件。CRM、ERP、大数据、互联网APP，各式各样的软件正在改变着我们的生活，我们已经进入一个软件定义世界的时代。

在此背景下，软件开发也变得越来越至关重要，而作为软件开发管理的基础，软件工程方法的正确选择和应用将是软件开发项目成功的保障。

本文主要简要探讨一些常见的软件工程模型方法及其适用范围。

二、瀑布模型

瀑布模型（Waterfall Model）是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。该过程由一系列顺序的活动构成，每个活动分为输入、过程与输出三部分。其中上一项活动的输出被作为本活动的输入，利用这一输入实施该项活动应完成的内容，最后给出该项活动的工作成果输出，作为下一项活动的输入。

从上述描述中我们能够看出，传统的瀑布模型具有如下的优点：

（1）为项目提供了按阶段划分的检查点。使得软件开发过程从无序变为有序，使软件开发的工程管理变为可能。

（2）各项活动串行进行，当前一阶段完成后，只需要去关注后续阶段。软件工程管理变得简单清晰。

（3）它提供了一系列的模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型也存在如下致命缺点：

（1）各个阶段的划分完全固定且周期较长，极大地降低了开发效率。

（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

（3）项目管理更加注重过程，而容易忽视对目标及价值结果的关注。

（4）无法应对开发过程中出现的用户需求的变化。

（5）开发与测试活动割裂，导致测试人员天然的依附于开发人员。

综上，典型的瀑布模型相对来说比较理想化，适合那种开发周期固定、客户需求清晰的项目，当前几乎被业界抛弃，很难适应当今软件开发的需求。比如互联网应用软件很难使用瀑布模型来管理。

三、V模型

V模型一定程度上是典型瀑布模型的一种改良，可视为瀑布模型的延伸。主要是针对开发、测试活动割裂进行的改良。把测试设计工作提前到分析、设计、编码各阶段，一方面提升了开发效率，同时开发与测试同源，提升测试有效性。

典型的V模型开发流程包括：需求分析（系统测试分析）、概要设计（集成测试分析）、详细设计（单元测试分析）、编码、单元测试、集成测试、系统测试和发布。和瀑布模型的最大区别是测试设计分析的提前，比如单元测试分析。在瀑布模型中，单元测试是在编码后进行的，输入的是编码；而测试人员需要根据编码先设计单元测试用例，然后执行。这样将存在一个风险，即单元测试只能发现编码本身的问题，即使编码完全未按照详细设计进行，单元测试也无法发现。而在V模型中，开发人员、测试人员针对详细设计展开工作，开发人员编码的同时，测试人员编写单元测试用例，从而使得测试用例不受具体编码影响，能够更加准确的验证详细设计的意图。其他阶段类似。

V模型中，测试活动有更多的独立性和自主性，软件开发效率也有一定程度的提升。但是V模型无法解决瀑布模型的本质缺陷，如同样无法应对需求的不断变化，同样需要在版本开发后期才能验证成果等。

三、迭代模型

早在20世纪50年代末期，软件领域中就出现了迭代模型。通俗的讲，迭代模型就是将整个软件的开发分解成一个个的子特性开发（阶段），而针对每个阶段内部采用的还是类似瀑布模型的方法。每个迭代是一次完整的经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

与传统的瀑布模型相比较，迭代过程具有以下优点：

（1）由于每个迭代是整个系统的子系统，相对内容比较单一，各个阶段需要传递的信息量较小，不需要通过大量的文档进行传递。

（2）由于整个开发过程被拆分为独立的若干阶段，用户在每个阶段结束就可以提前看到开发成果。一方面能够及时对开发中出现的偏差进行纠正；另一方面由于能够及时看到工作成果，有利于开发人员的效率提升。

（3）相对于瀑布模型，迭代模型更加关注对软件目标、结果的关注，更加注重和最终用户的互动，以保证开发成果的质量。

（4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的，而迭代模型更能够适应这种需求的变化。

同样，迭代模型也存在其缺点，那就是对于项目经理和开发团队的要求更加高，并且需要团队成员之间更加的信任。因为迭代模型运作对于过程的监控较弱，更加关注面对面的交流与合作。

四、结束语

软件工程方法包含的内容很多，除了正确的选择模型方法以外，还包括各种能力域的工程方法，如计划管理、资源管理、财务管理、人员管理、价值管理、需求管理、风险管理等等。只有根据软件项目具体的情况和目标，选择正确的工程方法模型，并把这一系列的工程管理方法有机的结合起来，才能使得软件开发的结果可预期，质量可保证。

参考文献：

[1]软件工程-实践者的研究方法，（美）Poger S.Pressman

[2]钱乐秋.《软件工程》[M]北京：清华大学出版社，2005

软件开发项目风险模型分析第4篇

1.1 软件项目风险定义

软件开发项目的风险为软件项目在整个生命周期内,由于受各种环境的不确定性因素的影响,实际发生的成本、进度、质量等与预期结果的不利偏差。软件项目的风险具有以下的几个特点:第一,对于项目各组成部分之间的复杂关系,任何个人都不可能彻底地了解。第二,项目各个组成部分之间不是简单的线性关系。第三,项目时刻处于动态变化之中,平衡状态即使出现也只能是短暂的。第四,项目管理者不仅要面对技术和经济问题,还要面临一些非常复杂、非线性和不确定性极高的问题。

1.2 软件项目风险管理

软件项目风险管理是对有关软件项目、软件开发过程和软件产品损失的可能性,它涉及操作过程、组织过程和合同等相关参数主要包括资源制约、外界因素、供应商关系或合同制约的管理。

Boehom认为软件风险管理指的是“试图以一种可行的原则和实践,规范化地控制影响项目成功的风险,其目的是辨识、描述和消除风险因素,以免它们威胁软件的成功运作。”Hall认为软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程,该实践围绕目标设定、项目计划、执行、度量、改进和发现新信息六大科目展开。SEI在软件工程体系中提出软件风险管理是有关管理威胁开发软件产品计划风险的概念、方法和技术,包括风险辨识、分析、监控、减轻和计划。具体分成三个知识单元:风险分析、风险管理计划和风险监控。通过以上软件风险项目管理的不同观点,可以归纳出软件风险管理是一个为了避免和减小软件项目失败的风险,对软件风险进行识别、分析、计划、监控的管理过程。

2 经典软件项目风险管理模型

2.1 Boehm体系

Boehm于1991年详细描述了他的思想体系,其中把风险管理活动分成两大阶段,每一阶段含有三个步骤:第一阶段,风险估计阶段。此阶段可分为:风险辨识、风险分析,风险排序三个步骤。第二,风险控制阶段。此阶段可分为:编制风险管理计划,风险解决,风险监督三个步骤。

每一步骤都备有不少的相关实现技术,例如,风险辨识中给出了10大软件风险因素清单。同时还推荐了各个因素的相关处理意见及方法。从该清单出发,经理和工程师们能够进一步细化风险因素,并加以评估和化解。

2.2 Charette体系

1989年Charette设计了称为风险分析和管理的体系,两大阶段分别为分析阶段和管理阶段,每个阶段都内含三个过程,风险分析阶段分为:辨识、估计、评价;风险管理阶段分为:计划、控制、监督。每个阶段内的过程活动并不能完全分离,有相互重叠甚至交错反复的现象。Charette同时为各个过程提供了相应的战略思路、方法模型和技术手段,特别在风险的辨识和估计过程中,其中大多数是运筹学、系统科学中的模型应用。

2.3 SEI体系

SEI在软件风险管理方面作了大量的工作,1999年前后分别以技术报告和手册等形式公布了基于分类的风险辨识(TBQ)、连续风险管理(CRM)、软件风险评估(SRE)、软件采购风险管理成熟度模型(RM-CMM)和团队风险管理(TRM)。完整思想是想以TRM为框架,贯穿CRM思想,依托SRE过程,以TBQ等为基本手段,配合软件能力成熟度模型(SW-CMM)和(SA-CMM)完成软件的风险管理。

其中CRM思想如上图1所示,SRE过程分为合同签订、风险辨识和分析(RI&A)、中间报告、缓和战略计划(MSP)和最终报告5个阶段。SA-CMM与SW-CMM类似,前者是对获取软件产品或服务一方组织管理能力的描述,后者是对开发组织过程能力的描述。RM-CMM配合SA-CMM模型的5个成熟度等级和关键过程域(KPA),也提出了风险管理关键过程域(RM-KPA)的概念。RM-KPA的结构包括目标、为达成目标的活动和支持活动顺利开展的制度化特征。其中目标有3个:1)鼓励项目全体人员参与到所遇风险的辨识和缓和中来;2)在所有的项目职责中明确项目团队软件采购过程的风险辨识、分析和缓和;3)项目评审已识别出风险的状态。

2.4 Hall体系

Hall女士受SEI连续过程改进和PDCA质量管理方法的启发,提出了“6-学科模型”(Six-Discipline,6-D),如图2。图中E代表预想(Envision),这是把思想转换为目标和目的的学科,用于研究软件产品的远期规划;P代表计划(Plan),是要为软件目标分配资源的学科;W代表工作(Work),指生产产品计划的执行,工作的伴生产品是状态和不确定性;M代表度量(Measurement),指比较期望值和实际值的学科,两个值的差异用于调整项目计划;I代表改进(Improve)是指从过去的经验中学习的学科,它通过分析基准和项目度量结果,找出改进的方向;D表示发现(Discover),是指要预知未来的学科,是通过对工作中不确定性的评价和困惑的思考,思考机会和风险的均衡,预先指导计划和规划的改变。

3 软件项目风险管理模型分析

以上4种典型的软件项目风险管理体系各有特色,较早出现的两套体系(Boehm和Charette体系)偏重于理论结构的完善,不妨称为理论体系,后两套体系则偏重于实践应用,不妨称为实践体系。总体来说,理论体系结构完整,内容完善,并附带有与结构和内容相配套的不少方法和技术。体系构建者旁征博引,着重说明了为什么要这样做的道理,阐明了如何从其它学科,如运筹学、决策理论等中借用思想、方法和工具。但研究范围局限于软件项目的核心风险管理,研究对象主要是开发技术风险,很少论及实现体系思想所需要的保障措施,基本上只站在开发商一方讨论风险管理问题,操作性也显得不足,整体上看思想性大于技术性,对实施过程中人所发挥的作用估计不足,从一定程度上说有理想化的成份。

Boehm先生一直关注软件项目的风险管理问题,曾提出了围绕风险管理开展软件开发的方法,即螺旋模型,还从经济学角度论证了软件开发问题,并引入了构造型成本模型(COCOMO)。他最突出的贡献之一是建立了软件风险管理研究领域,提出了头10大风险清单的风险辨识思想,尽管有缺乏动态性的不足,但确实对后续研究产生了很大的影响,只是他的体系在计算风险当量时没有考虑效用因素。

Charette先生的体系从结构上看与Boehm体系只在用词不同,本质上区别不大(两者同在1989年独立提出软件风险管理体系)。Charette的体系中认识到了风险的投机性,也从步骤上强调了对组合风险的评价。但就如何获取单一风险估计值和组合风险分析效果,还缺乏可行的手段和措施,在风险的效用问题上只考虑了目标效用,而没有考虑到不同项目参与人的效用。另外,与Boehm一样,也没有考虑点概率值在实践应用中的不足。

两套实践体系最明显的特点是考虑到了体系的可操作性,体系中的理性思考以指导实践步骤为主要目的,基本上摒弃了复杂的数学运算,强调与软件开发过程的紧密结合,强调把划分好的任务落实到人的重要性,还绘制出了关键的风险管理实用表格,注意到了风险管理数据的形成和利用问题。但为保证复杂体系的一致实施,需要对实施人员进行专业化培训。SEI体系明确提出了软件采购方在项目风险管理中的地位和作用,注重发挥和要求采购方参与到风险管理中来。该体系基于风险分类结构辨识风险,组织了194个揭示风险的问题,设计了各项实施措施的场景,有些活动甚至详细规定到了需要在多少分钟内完成。为了简化风险管理的实施成本和实施难度,该体系将风险发生的可能性定义为非常可能、可能和不可能3种,把风险后果定义为灾难性的、严重的、次要的和可以忽略的4级,两项因素组合成的风险当量简化为高、中和低3档结果,不过这种做法在降低管理成本的同时也降低了管理精度。SEI体系的管理步骤多于技术、方法和工具,没有涉及到组合风险的处理,可以看出其主体思想是以简单的学术背景要求、方便的日常事务应用,再加上严格的管理规定达成IT项目风险管理效果。所以尽管技术要求不高,但实施成本不低,因此更适合于大型公司或开发大型项目时采用。但不足的是对如何取得预想方案中风险和机会的均衡重视不够,基本思路是改进项目管理,带动风险管理,管理范围仍以核心软件风险管理为主。也可以认为上述4套体系归属两个风险管理层次,一个是研究如何辨识、处理和消除风险的学科,一个是试图辨识并采取规避措施的行为或过程。照此理解前两套体系属学科层,后两套体系属过程层。以上4套体系总体都偏重解决开发活动内部的技术风险,在风险控制手段上也往往着眼于降低风险发生的可能性,而对如何规避风险后果措施不多。

参考文献

[1]黄梯云.管理信息系统[M].2版.北京:高等教育出版社,1999.

[2]薛华成.管理信息系统[M].3版.北京:清华大学出版社,1999.

[3]郑人杰.软件工程(高级)[M].北京:清华大学出版社,1999.

胜任能力模型开发七步法第5篇

2009-4-27 14:48:13人力资源管理2007年第11期李付鑫字体：小中大

案例背景：

A通信公司1996年12月成立，从一家代理中低端通讯产品的贸易公司起步，经过近10年的发展，公司业务规模迅速壮大、管理水平不断提高，现已成为中国最大规模、最具影响力的移动通信产品分销商之一。目前，该公司在包括北京、上海、广州、深圳、西安等特大城市以及全国几乎所有省会及区域性中心城市建立了30多家分公司与135个办事处，形成了覆盖全国、精细稳定的销售网络，年销售收入近200亿元。

随着公司业务的快速发展，员工队伍也在不断壮大：目前公司员工超过5000人，平均年龄29岁，且超过90%的员工学历为大专以上，为公司持续快速发展提供了充足力量源泉的同时也给人力资源管理带来巨大挑战：市场形势变幻莫测，公司组织结构和岗位不断调整；职业生涯发展通道单一，员工纷纷抱怨没有前途，人员流动率越来越高；公司业务发展迅猛，迫切需要更多独挡一面的人才，而公司在招人和用人的过程中经常因缺乏明确的标准而倍感困惑……这都表明基于职位的传统人力资源管理已经无法满足A通信公司持续发展的需要，为此，公司决策层要求人力资源部加强人力资源能力建设，尽快由基于职位的人力资源管理向基于能力的人力资源转变。胜任能力模型是基于能力的人力资源管理体系的基石，因此，公司人力资源部的首要任务便是联合咨询公司共同开发胜任能力模型。

案例解析：

需要开发什么样的胜任能力模型？

胜任力是员工履行岗位职责并能产生高绩效所需具备的一系列能力的组合。胜任力是知识与技能的整合，而不是简单组合，这些因素的整合引出的是可观察的和可测量的行为。胜任力与素质不能混为一谈，素质是指能驱使员工产生高绩效的一系列知识、经验、技能、个性、动机、内驱力、态度以及社会认知的组合，既包括冰山之上的知识和技能，也涵盖冰山之下的个性、内驱力等（见图一），而胜任力则更多地体现在冰山之上知识与技能的整合，直接表现为一系列看得见摸得着的行为。根据A公司的实际需求，项目组确定需开发的胜任能力模型是将员工胜任岗位工作职责所需要具备的核心能力提取出来形成的集合体，其基本结构包括能力及其定义、评价等级及相应的行为表现。

如何开发胜任能力模型？

通过初步访谈和沟通，结合胜任能力模型构建的标准流程和公司的具体情况，初步确立以下八个开发步骤：成立胜任能力模型开发项目组；职位梳理，划分职类职种；深度访谈，收集数据；数据编码、归类、分析，提炼岗位胜任能力；开发胜任能力框架；开发胜任能力手册；能力匹配，开发岗位胜任能力模型。

第一步：成立胜任能力模型开发项目组

项目总监由主管人力资源部的助理总裁担任，项目经理由人力资源部总监担任，项目组成员除咨询公司和人力资源部相关人员外，还有来自相关业务部的相关员工。第二步：职位梳理，划分职类职种

职位是公司战略、管理模式和组织结构落实执行的基本单元，同时又是人力资源管理的基础，项目组首先从三个方面（职位管理、职位设置、职位分析及结果应用）对公司的职位

体系进行梳理，并对公司的职位进行职类职种划分。职类是指根据公司战略要求与业务模式而形成的各种相关职种的集合，同一职类要求任职者具备的能力种类、履行的功能相同或相似。职种是指由同类职位分类归并而成，这些职位要求任职者具备的能力类别相同或相关，承担的职责与职能相似或相同。根据公司业务系统的不同，我们将其职位划分为管理类和专业类两大职类。根据管理类员工的功能定位和承担的职责的不同，考虑经营人才对公司的重要价值，将管理类划分为经营管理和职能管理两个职种；根据公司的价值链及职能域的不同，将专业类划分为人力资源、财务金融、市场、销售、供应链管理、行政管理、信息管理等七个职种。

第三步：深度访谈，收集数据

通过职位梳理和职类职种划分，初步确定以市场、销售和供应链管理三个职种为基础建立公司岗位胜任能力模型。数据收集可采用行为事件访谈（BEI）、主题专家会议、问卷调查、深度访谈与文献分析等方法，其中BEI法是开发胜任能力模型最科学的方法和工具。虽然BEI法的信度和效度上明显优于其他方法，但综合考虑时间和成本等因素，项目组决定直接采用深度访谈法与主题专家会议法相结合进行胜任能力数据的收集，先后对公司总部、深圳分公司、北区、CDMA事业部、北京分公司、西区、成都分公司进行了深入访谈，访谈主要围绕工作职责和绩效考核指标展开，共访谈112名员工并形成详细的访谈记录。第四步：数据编码、归类、分析，提炼岗位胜任能力

访谈结束后，项目组对访谈所获取的数据进行了编码、归类和分析，形成《A通信公司能力频度表〉

第五步：开发胜任能力框架

以胜任能力频度表为基础，结合咨询公司数据库和标杆企业的能力模型，历经五次主题专家会议，最后确定《A通信公司胜任能力框架》。通信公司胜任能力分为4种核心价值观、9种通用能力、17种管理能力和23种专业能力，其中核心价值观是指公司本质的和持久的一整套原则，深深根植于企业内部，它规定了员工的基本思维模式和行为模式；通用能力是全体员工需要具备的基本素质和技能；管理能力是公司员工需要具备的管理技能，包括战略管理、推动执行和人员管理三部分；专业能力是成功履行岗位职责所需掌握的专业知识与技能，三个职种又细分为市场、销售、供应链管理、财务管理和人力资源管理五部分。第六步：开发胜任能力手册

胜任能力框架确定后便开始进行胜任能力手册的开发，即对每一项能力进行定义、分级并对每一级别进行行为界定。首先确定分多少级以及如何分级。结合公司的实际情况及标杆企业的操作实践，项目组决定分为4级，并研究确定了分级的基本原则：

1级（初级）：具有最基本的、有限的能力；在部门负责人的充分的帮助下可以开展与此能力相关的事项；能够描述基本的与该能力相关的概念。

2级（中级）：能熟练、独立地进行工具操作或运用所掌握的各方面知识,完成一般复杂度的事项；能够认知在应用该方面能力时可能遇见的潜在风险和机会；能够在作出决定的时候参考应用自己在该领域的过去经验。

3级（高级）：能精通某一方面的知识、流程或是工具的使用；能够应用该方面能力处理富有挑战性的和复杂的事项；能够指导小范围的团队展现该方面的能力。

4级（专家级）：能被征询意见，解决与该方面能力相关的复杂技术问题；能够对其所掌握的知识、流程或是工具提出战略性的建议或做出调整；能对事物的发展趋势及隐含的问题有足够的预见性和洞察力。

分级原则确定后便开始对每一项能力的4级进行行为界定。行为界定以访谈的相关数据为基础，结合工作职责进行梳理。行为界定必须基于能力本身而不是基于职位。行为界定主要有三种形式：一是单纯的行为描述；二是用事例说明；三是二者结合使用。根据公司的实际情况，以单纯的行为描述为主。示例如下：

第七步：能力匹配，构建岗位胜任能力模型

能力匹配主要分为两个阶段：能力匹配和定级。能力匹配可采用层次分析法、两两比较法和主题专家会议法。能力匹配完成之后，经与相关业务部门沟通反馈，确定每个职位所需要的能力。依此为基础，项目组对每个职位所需的能力进行定级，最后形成《A通信公司岗位胜任能力模型》。

基于图像模型开发课程网站的探究第6篇

关键词:图像模型;精品课程;课程网站;网站制作

精品课程的建设主要包括两个方面:一是课程资源建设,二是课程网站建设。课程资源建设是精品课程的核心;课程网站建设是资源的展示平台,是推进器、催化剂。没有充实的、富有特色的课程资源,精品课程建设将无从谈起,但没有网站的精美加工,再好的资源也将缺失表现力,无法被浏览者所理解。精品课程从立项到建设完成,时间紧、任务重,采用快速高效的课程开发模式建设课程网站是所有高校追求的目标。

一、精品课程网站建设现状

精品课程要求具有五个一流,即一流教师队伍、一流教学内容、一流教学方法、一流教材、一流教学管理,这不仅是针对课程资源建设,更是对网站制作者的考验。经历几年的发展,主要有以下几种开发形式:

1.采用系统平台制作课程网站

目前市场有很多精品课程开发平台,快速、高效、简单易用的特点被众多高校所追捧。但随着高校课程建设的深入,缺乏特色、创新成为采用平台建设网站的弊病,所有采用同系统制作的网站千篇一律,不同学科的重点内容无法得到有效展示。

2.聘请网络公司制作课程网站

课程建设团队的教师大部分时间需要处理课程资源内容,并且对于网站制作也不专业,聘请网络公司制作网站逐步取代采用平台开发课程。这样的网站优点是制作精美、有特色、技术含量高。但是缺点也很快暴露,由于公司技术员不懂得教学结构的安排,栏目的设计、后期的维护修改等成为最大的问题。

3.教育技术人员制作课程网站

教育技术人员精通网站技术,又熟悉教学设计和教学方法,关键是对精品课程建设的要求和指标有较为深入的研究,在某些方面可以指导教师如何更为合理地建设精品课程,因此请教育技术人员制作课程网站是最佳选择。但是由于各高校建设的课程门数多,人员缺乏、精力不够、影响其本职工作等都成为最大的障碍。

从以上课程建设的形式可以看出各有利弊,高校需要寻找一种更为便捷、有效、适合教师自主开发课程网站的方式,也便于高校今后开展大规模的课程建设。经过多年的实践探索,发现利用图像模型建设课程网站是一种行之有效的方式。

二、基于图像模型建设课程网站优点

1.网站整体设计统一

采用该技术开发网站是基于图形的,图片样式即是网站的雏形。课程网站主次页面的外观效果可直观显现,便于将页面风格统一,尤其是色彩色调和布局的统一。从历年国家精品课程建设过程看,发现很多网站的页面样式不统一,缺乏整体感,极大影响了精品课程的展示效果。

2.网站精美,不变形

由于精品课程网站有大量的教学资源需展示,网站首页作为第一张画面更应以最好的形象展示给观众。对比2003年到2009年的精品课程网站,可以明显看出网站页面美化度有了很大的提高。利用传统的网页技术,很难实现精美效果。但是利用图片模型来制作网站,将网站的设计思路转换为平面设计。图片设计比网站设计要简单、效果更好、不易变形、更直观,理念上的转变、方法上的变革彻底改变了网站内容的呈现效果。

3.网站制作更加简便、快速

图片模型一旦设计完成,那么网站制作将变得非常简单。只需将图片切割,就可以生成精美的静态网页,而且效果与图片一致。这时只需填充课程资源即可。

三、基于图像模型制作网站的流程

1.图片风格设计

根据课程特色和学科类别设计图片风格,这是网站制作的原则和基础。网站风格是给观众的第一印象,主要关注一下几个方面:

(1)结构一致性。网站结构是网站风格统一的重要手段,包括网站布局、文字排版、导航的统一等。首页模型设计结构是否一致,直接影响其他模型的风格。

(2)色彩的一致性。保持模型主体色彩的一致,只改变局部色块。这样做的优点是一个独特色彩的网站会给人留下深刻的印象,因为人的视觉对色彩要比布局更敏感,更容易在大脑中形成记忆符号。比如可选取一两种主要色彩,几种辅助色彩。

(3)导航统一。导航是网站的一项重要组成部分,导航设计合理对网站布局的影响很大,而且影响浏览整个网站的便捷性。

(4)特别元素的一致性。在网站平面设计中,个别具有特色的元素(如标志、象征图形等)重复出现,会给访问者留下深刻印象。比如网站结构在某一点上的变化,由直线变为圆弧、暗色点缀的亮色、色彩中的补色等等。

2.图片色彩设计

(1)色系一致性。采用相同色系设计图片模型是保持一致性的關键。所谓相同色系,是指几种色彩在360°色相环上位置十分相近,大约在45°左右或同一色彩不同明度的几种色彩。

(2)局部色调互补对比。局部运用对比色或互补色来增加变化,避免采用相同色系造成页面的单调。所谓对比色,是指色相环相距较远,大约在100°左右,视觉效果鲜亮、强烈。而互补色则是色相环上相距最远的连种色彩,即相距180°,其对比关系最强烈、最富有刺激性,往往使画面十分突出,特别适合突出重点栏目,但在使用中注意使用的度,否则容易造成色彩的花。

(3)过渡色调和。过渡色包括几种形式:两种色彩的中间色调、单色中混入黑、白、灰进行调和以及单色中混入相同色彩进行调和等等。过渡色能够神奇地将几种不协调的色彩统一起来。

3.图片版面设计

(1)分栏设计。课程网站的内页布局一般比较简单,即内页的一栏式、不等分两栏式、三栏式版面布局,但因为浏览器宽幅有限,一般不宜设计成三栏以上的布局。

(2)导航设计。版面布局中主要是考虑导航、必要信息和正文的布局关系。比较多的情况是采用顶部放置必要的信息,如课程名称、课程特色及导航条,或将导航条放在左侧而右侧,这样的布局结构清晰、易于使用。

4.切割图片,生成网页

图像模型设计完成,即可利用Photoshop切片工具切割页面,进而生成网页。

(1)切图。切图是网页设计中非常重要的一环,它是我们标明哪些是图片区域,哪些是文本区域的重要步骤。另外,合理的切图还有利于加快网页的下载速度。

(2)生成WEB页面。对已经切割完成的图片进行“另存为WEB页”操作即可生成静态课程网站框架,图片自动会生成一个html页面和images文件夹。

5.内容填充

资源内容的填充位置和显示大小在设计模型时已经设计完成,因此内容的填充样式要符合网站框架结构,否则会直接破坏前期设计的网站结构,影响整体风格,对此我们通常采用以下几种方式:

(1)将文档转换为swf文件。在精品课程建设中,大量的文字内容放入网页显示会出现排版异常、字体混乱情况,并且影响页面美观。常用的方法就是将Word、PPT等文档内容转化为swf文档后,插入课程网站。这样做的优点是字体、排版不变形,节约版面设计,保持页面美观,并且可对文档进行滚动、放大、缩小操作。这也是在精品课程建设过程中对大批量网络文档用的最多的方式。

(2)将文档转化为网页。将文档另存为web页,将此单独作为课程网站的一个页面。这对于单个简单排版的文档可以这样处理。如果文档中有图表、图片等复杂内容,则不适合采用此种方式。

(3)复制文字到网页。对于只有少量文字且简单排版文档的可先复制到记事本中,然后再复制到课程网页中。如果直接从文档复制到网页则也会出现排版异常现象。

(4)特殊效果文字显示。对于网站页面中需有特殊效果的文字插入,可通过互联网络查找相关特效代码,然后将整个特效代码拷贝到相应的网页代码位置即可。

6.细节调整

为使课程网站整个风格统一,尤其是文本内容格式统一,这就要用到CSS样式表。利用CSS样式表,可方便对整个网站主体文字的批量修改。因此充分利用CSS样式表,一方面可实现网站主体文字风格的统一,另一方面便于今后快速高效修改文字格式。

四、利用图像模型开发网站的注意点

1.模型像素设计

每个网站的大小(宽*高)都要符合浏览器的大小,页面过大的网页浏览器放不下,不方便浏览者观看内容,有时无法凸显特色栏目。因此页面大小在设计模型时就需要注意,通常页面大小为1024*768像素。

2.切片方式

对模型的切片转换到网页中是一个个拼接的表格,因此如何切片,先后顺序,切片的多少都会直接影响到后面课程资源内容的填充,因为表格极易被破坏。建议事先规划,保留PSD原图,多次尝试。

3.CSS样式表设计

利用样式表便于网站形成统一风格,样式表的设计可通过Dreamwaver进行设计,形成单独的文件,分别套用给每个网页,这样便于今后统一修改。

4.冗余代码清除

设计者在制作页面完成后,最好执行清理冗余代码操作,这样可使网页执行效率更高,占用容量更小。

参考文献:

[1] 教育部.关于启动高等学校教学质量和教学改革工程精品

课程建设工作的通知(教高[2003]1号)[EB/OL].http://

www.jpkcnet.com/new/zhengce/Announces_detail.asp?Announces_ID=13.

[2] 姚恩全.“三位一体”的精品课程建设范式研究[J].四川师

范大学学报(社会科学版),2006,(6):56-60.

[3] 杨世勇.对国家精品课程建设的思考[J].现代教育科学,

2004,(11):19-20.

[4] 王玲华.国家精品课程支持技术问题分析[J].济南职业学

敏捷软件开发的双迭代模型第7篇

关键词：敏捷方法,软件开发,双迭代,软件工程

1 背景和简介

随着信息技术和软件产业的不断发展,软件开发企业之间的竞争日趋激烈。人们希望软件能够更灵活、更准确地满足自己的需求,更快地适应商务环境和业务需求的种种变化。对此,一种形象的说法是,软件要变得更“软”。在这种情况下,对于一个软件开发企业来说,能否在软件开发过程中一方面有效地适应用户需求和商务环境的种种变化,另一方面控制好软件开发的周期和成本,提供高质量的软件,就成为该软件开发企业能否顺利发展壮大的关键。

到目前为止,多数软件开发项目仍然是一个混乱无序的活动。软件的开发并没有得到很好的规划,而是任由开发人员采用“边写边改”的方式进行开发。随着软件产品的复杂程度不断提高,这种缺乏计划的做法越来越成为各种麻烦的根源:无法估计软件开发所需的时间和资源,难以添加新的特性,产品中的 Bug 以不断增长的速度累积,等等。为了解决这些问题,人们引入了软件过程方法论,特别的,人们从已经成熟的领域和学科(建筑学是典型的例子)引入工程学的原理,强调事先计划的重要性,要求软件开发过程遵循严格定义的过程, 从而期望得到可控的软件开发过程,提高软件产品的质量和开发效率。这方面,最经典的方法是瀑布模型[1]。

工程学的方法存在了很多年,但它在商业软件开发的领域中并没有取得人们原先所期望的成功,这主要是由于其自身的缺陷造成的。近几年来,新的软件开发模式,敏捷软件开发[2],逐渐成为一种潮流被越来越多的软件开发企业所采用。敏捷软件开发是一类方法的总称,与传统的工程学的方法不同,敏捷软件开发是一种“适应型”的方法[3]。敏捷软件开发认为用户需求始终是变化的,而且这种变化是无法预知的。因此它并不试图去限制或者预测用户需求的变化,而是在需求变化发生的时候迅速地做出调整适应这种变化。敏捷软件开发方法有很多不同的种类,如 XP[4],Scrum,Crystal 等等[5,6],细节上各有不同。但是同时这些敏捷软件开发方法都具有一些共同的特征:

(1) 重视迭代,将整个软件开发过程分为若干小的迭代周期,用快速迭代和增量式开发来对应用户需求的不断变化。

(2) 重视与客户的交流,要求尽早发布能够运行的阶段性软件版本,收集来自客户的反馈,并在反馈的基础上尽快推出更新的阶段性版本[7]。

(3) 重视在软件开发过程中采用各种最佳实践,尤其重视测试驱动开发和持续集成,认为它们是支持快速迭代的基石。

业界软件开发的实践证明,上面这些特征使得敏捷开发方法在面对复杂多变的商业环境和不断变化的用户需求时,相比传统的工程学的方法更加灵活高效。因此,敏捷软件开发方法逐渐成为软件开发过程研究中的一个热点,也在软件开发企业中得到越来越多的应用。

2 问题

如前所述,随着越来越多的软件开发企业采用了敏捷软件开发方法,也出现了许多成功的范例[8]。但是在这个过程中,由于当前敏捷开发方法自身的一些特点,许多软件企业,特别是那些原先缺乏软件过程相关建设的企业,在实施敏捷过程中往往会出现一些问题,从而未能达到预期的效果。下面是经过总结得到的一些典型问题:

(1) 测试驱动开发[9]是敏捷开发方法的核心要素之一。但是由于传统的原因,很少有软件企业能够有效地组织好测试的工作。一方面,软件开发小组中普遍存在测试力量薄弱、测试覆盖面不足的情况;另一方面,本该属于开发的一部分并由开发人员负责的单元测试常常和其他测试混为一谈,被推给测试人员完成。更糟糕的是,技术人员普遍轻视专职负责测试的工作。特别是面向软件最终用户、反映软件实际使用方式的 End-to-End 测试,由于含有较多手工测试的成分,技术人员出于自身职业生涯规划的考虑,往往是避之唯恐不及。这些因素综合起来,导致许多软件企业中所谓的“测试驱动开发”成了一句空话,完全不能起到应有的作用。

(2) 敏捷软件开发方法规定了在一个迭代过程中,每个活动的顺序执行,即当有新增需求或者已有需求发生变化时,后续的需求分析、代码开发、测试等活动都要顺序执行一次。而在某些情况下,需求的变化有可能不会引起代码的再次修改,或者代码的修改并不是以需求变化为驱动力的。

(3) 常见的迭代过程模型将软件开发划分成一个个迭代周期,每个周期包含一个传统意义上的开发过程,也就是从“需求分析->设计->编码实现->测试->交付”这样的一个完整链条[10]。然而在各个迭代周期之间,不同职责的人员工作量的分布可能有着明显的不同。例如,某软件开发的第n个周期内,开发任务极为繁重,而相关的测试工作则相对简单,导致开发人员加班加点而测试人员则无事可做;而到了第n+1个周期,情况则可能刚好相反。这样,在迭代开发过程中,为了让不同职责人员的进度在迭代周期之间进行同步,就会经常出现“等待其他人把这个周期内的工作做完”这类情况,导致人力的浪费,同时也容易打乱开发的节奏和进度。

为了解决上面提出的这些问题,本文设计了一个适用于敏捷软件开发方法的软件开发过程模型。这个模型最显著的特点是同时拥有两个互相独立的迭代过程,因此我们称之为“双迭代模型”。

3 双迭代模型

为了解决上一节所描述的、在实施敏捷开发方法的过程中出现的种种问题,本文提出了双迭代方法,将敏捷开发方法中的单个双迭代过程分解为两个迭代过程,需求分析/测试准备与代码开发这两大类活动相互独立。

双迭代模型将整个软件开发过程分成四个主要阶段,下面我们详细介绍各个阶段的内容以及两个团队在各个阶段的职责。

3.1 初始阶段

初始阶段是整个软件开发过程的第一个阶段,我们在这个阶段建立需求与测试团队,获取对开发目标和用户需求最初的理解。这个阶段包含下列具体步骤:

(1) 建立需求与测试团队。

(2) 需求与测试团队与客户和最终用户进行交流,获取对开发目标最基本的认识,同软件的客户建立沟通的方式和渠道,确定最终用户参与开发过程的代表。

(3) 需求与测试团队根据同客户的交流,创建最初的产品拟像。这里所说的“产品拟像”并不是指软件产品原型,而是一个能够在外观和用户交互这两方面示意性地“模拟”开发目标的某种演示。产品拟像的开发应该是极为快速和低开销的,因此虽然产品原型也可以被视为产品拟像,但我们并不建议采取这种做法。

(4) 将产品拟像交付客户试用,根据来自最终用户的反馈,修正和细化对用户需求的理解,并据此设计一组典型的、反映最终用户如何使用作为开发目标的软件的场景。

3.2 评估阶段

评估阶段是整个软件开发过程中承前启后的一个阶段。在通过产品拟像得到对开发目标和用户需求的最初认识之后,我们在这一阶段评估整个项目大致的规模、技术上存在哪些风险、并做出最初的设计。这个阶段包含下列具体步骤:

(1) 建立开发团队。

(2) 开发团队和需求与测试团队进行充分地交流,通过初始阶段中创建的产品拟像和最终用户如何使用开发目标的典型场景,来理解用户的需求。

(3) 开发团队根据当前对需求的理解,负责评估整个项目大致的规模、需要多少开发资源、技术上存在哪些风险,并做出最初的设计。在最初的设计完成后,开发团队已经可以转入下一个阶段了。

(4) 需求与测试团队根据开发团队做出的最初的设计,将初始阶段中得到的一组典型的、反映最终用户如何使用作为开发目标的软件的场景,转化为一组具有明确定义的End-to-End产品测试(可以是手工测试)。需求与测试团队需要在整个软件开发过程中维护这组测试。在转化完成之后,需求与测试团队可以转入下一个阶段。

这个阶段值得注意的一点,在于开发团队和需求与测试团队可以在不同的时刻转入下一阶段。也就是说,开发团队和需求与测试团队的进度在整个软件开发过程中不必时刻保持同步。这是双迭代模型的主要特点之一。在下一个阶段,它将会表现得更加明显。

3.3 双迭代阶段

这个阶段对应于一般软件开发过程中的迭代阶段,通过不断的迭代增量式地完成开发目标。但是这里我们有一个非常显著的不同:在双迭代模型中,需求与测试团队和开发团队各自执行自己独立的迭代过程,两个迭代的周期不需要严格的同步。也就是说,在很多情况下,开发团队不需要等待需求与测试团队完成当前的迭代周期就可以自行进入下一个迭代周期,反之亦然。

在这个阶段,需求与测试团队的一个迭代周期包含下列具体步骤:

(1) 从开发团队那里获取开发目标的一个新的阶段性版本(如果不存在则需要等待)。

(2) 评估最新的阶段性版本是否包含对最终用户而言足够显著的变化。这个评估应该既包括团队成员(特别是软件最终用户的代表)的主观判断,也应该包括客观的数据标准,例如对新版本执行最新的End-to-End产品测试,观察测试通过的情况,等等。

(3) 如果评估结果是当前版本不包含足够显著的变化,则当前迭代周期结束,进入下一个迭代周期。

(4) 如果评估结果是当前版本包含足够显著的变化,将这个新的阶段性版本交付最终用户试用,收集用户的反馈。在此基础上与用户展开交流,不断深化和修正对用户需求的认识和理解,对用户需求的变化及时做出反应。

(5) 在上述工作的基础上,修正和细化面向最终用户、反映软件实际使用方式的End-to-End产品测试(可以是手工测试)。需求与测试团队需要确保这些测试尽可能的全面和详尽,能够充分覆盖需求与测试团队当前对用户需求的理解和认识。特别的,当团队发现用户需求发生变化时,需要相应地修改End-to-End测试的集合。最后,在可能的范围内,需求与测试团队应该尽量自动化这些End-to-End测试。

(6) 对当前版本执行新的End-to-End产品测试,找出当前版本无法通过的测试,并将这些失败的测试用例以及相关的对用户需求的理解反馈给开发团队。

相应的,开发团队的一个迭代周期包含下列具体步骤:

(1) 总结上一个周期以来,对用户需求理解的变化。这个工作的主要依据是需求与测试团队提供的End-to-End产品测试,以及他们在运行测试之后给出的反馈。同时,这一步骤得到的结论需要与需求与测试团队进行沟通和确认。

(2) 根据上一步骤得到的需求,确定下一阶段性版本的目标,进行软件设计。特别的,“能够通过当前的End-to-End产品测试”必须作为一个主要的目标在这一步骤加以考虑。

(3) 根据上一步骤得到的设计,进行实际编码与实现。必须注意,单元测试被视为编码与实现的一部分,是开发团队在这一步骤的责任。

(4) 交付能够通过设计步骤时End-to-End产品测试的一个新的阶段性版本。

这里有两点需要指出:第一,开发团队在步骤(2)确定了设计之后,这一迭代周期的目标就固定为进行设计步骤时的End-to-End产品测试,即使在编码与实现步骤中,测试集合有了新的变化(这应该是一般情况)也是如此;第二,即使需求与测试团队在开发团队的一个迭代周期中并没有捕捉到新的需求或是对现有的需求加以深化(表现为End-to-End产品测试的集合保持稳定),开发团队也可以出于改善软件内部实现等目的开始一个新的迭代周期。

从上面的描述可以看出,两个团队的迭代循环有相当的独立性,可以各自并行地运行。换句话说,两者可以拥有不同的迭代周期,不需要严格的同步。两个迭代循环的联系在于,开发循环不断交付可用的阶段性版本给需求与测试循环,而需求与测试循环交付End-to-End产品测试集合给开发循环作为需求的起点。

随着两个团队的不断迭代,需求与测试循环交付的End-to-End测试集合逐渐收敛到用户的需求上,相应的,开发循环交付的阶段性版本收敛于最终的可用版本。何时满足这个终止条件从而能够转入下一阶段,由需求与测试团队决定。

3.4 交付阶段

在双迭代阶段结束以后,软件过程进入交付阶段。此时开发团队不再进行迭代,不再被允许引入新的特征,工作目标限制在修正已知的缺陷上。而需求与测试团队负责周期性地运行测试确保开发团队没有引入新的、导致软件不再满足特定用户需求的缺陷。当缺陷率下降到可以接受的比例时,发布最终的软件产品,软件开发过程结束。

4 模型的特点和优势

相对于现有的其他模型,双迭代模型具有下列显著的特点以及由此带来的优势:

(1) 需求与测试团队在软件开发过程中的不断快速迭代,保证了需求的细化和改变可以迅速地直接反映到需求循环产生的测试集合中。最终用户的代表直接参与需求循环,有助于保证需求捕捉的准确性和真实性。

(2) 双迭代模型所描述的开发过程内建地保证了测试驱动开发的模式。开发团队的每个迭代周期,都是以当前的End-to-End产品测试集合为需求和起点,将满足这一组测试作为这一轮迭代的首要目标。

(3) 专职负责测试的需求与测试团队同时具有捕捉用户需求的职能和业务专家的身份。这避免了传统模型中专职测试人员角色受限、地位不高的问题,使得更多优秀的人员能够愿意投入需求与测试团队,有助于解决传统上测试力量不足的问题。

(4) 在迭代过程中,开发循环和需求循环彼此独立,双方并不需要严格的同步,可以根据自身工作的特点较为自由地选择迭代的周期,从而避免了“等待其他小组完成当前周期”的现象,提高了人员的利用效率。

5 双迭代模型的实践与进一步的工作

5.1 模型的项目实践

蓝山人事管理系统是以提供人事资源管理为主要功能的应用软件。系统开发是基于“客户现场”的模式。“客户现场”强调客户在整个软件开发过程中的作用,包括在开发过程中不断地确认产品需求,反馈中间版本的使用效果等。在实践过程中,团队采用双迭代的敏捷软件开发模型进行软件开发,项目初始阶段,通过产品拟像,需求与测试团队得以在短时间内从客户代表中了解初步的系统需求。在双迭代阶段,需求与测试团队面对客户使用系统后提出的新的需求变化和bug改动,将End-to-End产品测试得到确实需要进行变动的需求提交给开发团队。较以往开发模式,双迭代模型大大提高了开发效率,对用户提出的系统需求都能很好地实现。

5.2 进一步工作

显然,现在的双迭代模型仍然是比较粗糙的,有许多后续工作尚待完成。这些工作主要可以分为三个方面:

(1) 正规化。目前对模型的描述仍然是很不精确的,应该考虑采用更加正规和形式化的描述手段。例如,可以考虑运用RUP[11]提供的语汇和框架,使之更加完整和精确。

(2) 进一步细化,使之更具现实中的可操作性。特别的,需求与测试团队这样一个概念在软件过程模型中是新的,一个双迭代模型中的需求与测试团队应该如何去构建,它的成员应该具有哪些技能,仍是一个有待细化的问题。

(3) 在双迭代模型中,End-to-End测试具有极为重要的地位,自动化这些测试的价值巨大,而这是当前软件测试技术的一个薄弱领域。如果能够整理发展出这方面的一些最佳实践,将会极大地提高双迭代模型运行的效率。

参考文献

[1]Ian Sommerville.软件工程[M].程成,译.6版.北京:机械工业出版社,2011.

[2]Robert C Martin.Agile software development:Principles,patterns,and practices[M].北京:中国电力出版社,2003.

[3]沈雷,沈备军.敏捷方法的研究与实践[J].计算机工程,2005,31(7):219-222.

[4]Barry Boehm.Get ready for agile methods,with Care[J].IEEE Com-puter,2002,35(1):64-69.

[5]张敬周,钱乐秋,朱三元.Agile方法研究综述[J].计算机应用研究,2002,19(6):1-3.

[6]Fowler M.Public versus published interfaces[J].IEEE Software,2002,19(2):18-19.

[7]雷剑文,陈振冲,李明树.超越传统的软件开发:极限编程的幻象与真实[M].北京:电子工业出版社,2005:35-40.

[8]向佐龙.敏捷管理方法在软件开发中的应用研究[D].武汉:武汉理工大学,2007:67-71.

[9]Kent Beck.测试驱动开发[M].张平平,译.北京:中国电力出版社,2004.

[10]谭庆平,毛新军,董威.软件工程实践教程[M].北京:高等教育出版社,2009.

软件故障模型驱动软件测试第8篇

1 软件故障与软件测试

蔡开元先生对软件失效机理进行了如下描述:软件错误是一种人为错误, 一个软件错误必定会产生一个或多个软件缺陷;当一个软件缺陷被激活时, 便产生一个软件故障。同一个软件缺陷在不同条件下被激活, 可能产生不同的软件故障;软件故障如果没有及时的容错处理, 便不可避免的导致软件失效, 同一个软件故障在不同条件下可能产生不同的软件失效。这样的复杂关系如图1所示。

图1可以很好地说明软件故障产生与测试的复杂性, 软件功能层面的失效往往是由各种特定的条件和环境决定的, 存在必然的复杂性和多样性。而测试虽然能从软件的不同层次开展测试, 但如果不能从问题的根源处着手, 要测试出全部问题是不可能的, 这也导致了测试再充分也不能保证测试后的软件没有问题。同样地, 我们也能看出, 如果从问题产生的根源出发开展软件的测试, 是可以将后续环境中无穷发散的问题解决的。这无疑是改善测试不确定性和盲目性的一个有效办法。

2 用软件故障模型驱动软件测试

软件故障模型 (SFMEA) 从发生的软件错误入手探究和分析导致软件故障模型, 是寻找软件问题产生的根源的一种有效方法, 是软件测试的基础。这里以成熟的动态内存故障模型为例阐述利用故障模型来驱动软件测试的方法。

2.1 动态内存故障分析

(1) 动态内存是一个自由存储区域, 编程人员根据需要, 利用编程语言提供的动态内存管理命令, 进行动态内存的分配、访问、回收等操作。各类操作后的结果与该内存区域当前所处状态紧密相关, 由此产生了动态内存使用过程中的各类问题, 在分析导致其错误的原因的基础上, 可以建立动态内存故障模型。如图2所示。

Start表示开始状态;Memory Allocate表示对内存进行动态内存分配, 若没有足够的动态内存, 则内存指针为N ULL;Ch ec k Memory检查动态内存分配的结果, 以保证后续动态内存操作的正确性;Access Memory表示对动态内存中的内容进行写、读、修改等操作;Free Memory表示动态内存操作结束, 进行动态内存的释放;End表示结束状态;

(2) 动态内存的四个核心操作缺一不可, 且在不同状态下操作也有约束, 由此导致了诸多与动态内存使用相关的问题, 如图3所示。

图3中的连线表示了引起动态管理错误出现的几种操作, 箭尾表示当前的动态内存管理状态, 箭头表示在当前状态下的操作请求, 将引起动态内存错误产生的操作请求进行分类, 可分为如下几类:1) Memory allocate操作请求引起的错误, 在图中, 6, 5, 7表示了与动态内存分配操作请求有关的错误。2) Check memory操作请求引起的错误, 图中连线10表示了动态内存检测操作有关的错误。导致错误发生的原因是在动态内存释放之后, 又对动态内存进行检测 (试图重新使用已回收的动态内存) 。3) Accessmemory操作请求有关的错误。在图中, 3、9表示了由内存访问引起的错误。导致该错误出现的原因有两个, 3表示在动态内存访问之前未进行指针P的检测, 本文将这种错误定义为空指针引用, 操作9表示在动态内存释放之后, 重新进行动态内存的访问, 从而造成动态内存的未分配使用错误。4) Freememory操作请求引起的错误, 1, 11表示了由动态内存回收操作引起的错误, 1表示没有进行动态内存的分配而进行动态内存的释放, 11表示在对指针变量P进行了动态内存的释放之后, 重新进行释放工作, 这两种情况是等价的, 即在没有可以用的动态内存的情况下, 尝试使用动态内存空间, 产生了动态内存未分配使用错误。5) 与end有关的错误。在图中, 2, 6, 8表示在程序结束阶段出现的错误, 导致错误产生的原因是在进行了动态内存的分配、检测或访问之后, 没有进行动态内存的释放, 因此, 造成了内存泄露的问题。

以上就是动态内存故障模型分析的核心部分, 这样的故障模型能从问题产生的根源出发阐述软件缺陷发生的机制, 为软件测试提供了一个寻求有效测试方法的窗口。

2.2 故障模型驱动软件测试

(1) 在有了软件故障模型之后, 在软件测试时即可针对这类故障的根源开展测试, 做到有的放矢, 达到通过测试将该类软件问题从程序中剔除的目的。动态内存故障模型从动态内存故障产生机理开展分析, 切入软件代码编写的最初级过程, 我们这里以C语言为例阐述利用动态内存故障模型驱动软件测试的过程。C语言中与动态内存管理相关的操作有几类, 可以分别与动态内存管理的四个阶段对应:1) 动态内存分配类操作:如malloc;calloc;realloc等动态内存分配类函数。2) 动态内存检测类操作:内存指针检测if (p!=NULL) , 动态内存初始化memset等操作。3) 动态内存读写访问类操作:各种动态内存空间赋值、引用、函数间的调用等, 都可能形成动态内存的读写操作。4) 动态内存释放类操作:如free等内存释放函数。

(2) 与故障模型进行对应之后 (见图4) , 即可开展软件测试工作, 最简单的方式就是采用人工走查代码的方式进行, 这类方法对程序结构简单、规模不大的程序还是很有效的, 可通过同行评审等方式开展, 能很快排除与动态内存故障模型相关的软件错误, 进而达到根除该类软件错误的目标。

(3) 软件系统高速发展的今天, 小规模、结构简单的程序越来越少, 动态内存管理越来越复杂, 通过简单的人工代码走查方式明显跟不上时代的发展, 随之各类软件测试工具供应商推出了多种软件测试工具来解决这种大规模复杂情况下的软件代码故障检测问题。比如klockwork、C++Test等等, 成为了帮助软件开发、测试人员发现并解决软件问题的有力工具, 其核心也是依据不同软件故障模型对程序代码进行检测, 提供明确的软件故障指示。针对动态内存管理故障模型, 检测软件一般通过数据流分析、制定检测规则、软件故障检测三个过程来检测问题。1) 数据流分析:程序中的数据流分析可以描述出程序的结构流程, 变量间的定值与引用关系, 为故障检测提供有力支撑, 主要方法有到达-定值数据流分析法和活跃变量数据流分析法。2) 制定检测规则:在数据流分析的基础上, 通过抽象命名, 把规则涉及实体进行命名, 再依据软件故障模型制定工具检测遵循的规则, 并将规则转化为方便工具自动处理的“语言”。3) 软件故障检测:在数据流分析和检测规则的基础上, 完成对软件特定故障的检测, 并提供个性化的展示、统计和分析能力。

综上所述, 在软件故障模型成熟之后, 据此开展更有效的软件测试活动是可行的, 也为软件自动化测试工具设计提供了依据。使用软件故障模型驱动软件测试可以按如图5所示流程开展。

首先在故障模型研究的基础上, 对需测试的对象按照故障模型进行实例化, 完成由模型向具体问题的转化;然后对模型实例进行分析, 研究发掘更优更有效的测试方法, 并用测试方法对对象进行测试确认, 不断循环分析和方法优化的过程, 直至找最适合的方法;用寻找到的方法对一类问题进行普适性确认, 因为故障模型本身就是从众多实例中抽象提炼出来的模型, 因此普适性验证重点关注方法的效率和重用度;对于重用度高, 通过工具可以大幅提高效率的方法还可设计自动化测试工具对方法进行固化。

3 结语

现代信息技术的不断发展, 软件应用已经无处不在, 通过软件故障模型来指导软件测试是提高软件可靠性的一个有效办法, 其核心是不断地总结提炼科学有效的软件故障模型, 在应用场景和方式也日趋复杂的今天形成准确的软件故障模型是件不容易的事情, 特别是从覆盖度上要能让软件故障模型覆盖所有的软件故障更是困难, 即便如此, 发掘和提炼软件故障模型仍然是值得的, 可以让测试更有针对性, 更自信, 更有效。提炼软件故障模型需要大量的工程实践作为基础, 通过假设故障存在、反向推理、实践验证的方式进行。当前软件故障模型偏重于由软件代码层次, 对软件应用环境、模式、行业特点等方面指导系统级测试的软件故障模型还很欠缺。完善软件故障模型并应用到测试行为当中还是一个很长期的过程。

参考文献

软件协同开发活动管理的三个模型第9篇

一、协同管理的软件组件对象模型

1.1概念

协同管理系统作为一种信息管理系统, 除了具有一般信息管理系统的功能外, 它还具有对协同信息的表述、存储、提取、查询和浏览等功能。

整体是由部分组成, 协同管理软件同样如此, 协同管理系统由多个局部系统组成。局部系统是协同管理系统的对象实例, 本身是一个对象, 同时它又是组件对象实例, 被其他对象管理。

1.2组件对象的关联和创建

协同管理系统中管理的各对象之间存在着复杂的关联, 以下是对其关联情况的概括描述:

在以上的描述中, 我们可以将数据库系统看成是一个独立创建的包含了大量软件组件对象的对象库。

对于软件组件对象的创建, 一般来说有两种创建方式, 一种是由部分到整体的创建方式, 就是先创建一个具体的软件组件对象, 然后由这个已创建好的软件组件对象再创建出更多的组件对象, 进而形成一个大的应用软件系统。另一种是由整体到部分的创建方式, 即先创建一个软件组件系统框架, 管理者根据需要创建许多的模块, 并给出设计要求, 具体的内部结构由开发者自主决定。开发者创建好的软件组件对象对其他开发者和用户都是开放的, 每个开发者或用户都可以根据自己的需要及兴趣检出任意一个组件对象, 也可以对其进行修改变动, 将改动后的组件对象再存回数据库中。

二、协同开发的关系模型

2.1自发组成的协作组

在一个开放的信息环境中, 协作组的成员并不是一成不变的, 可以事先确定, 也可以随时加入, 那么如何来管理整个协作组呢?本模型采用了“谁最后离开谁关门”的方式。举例说明:有A, B, C, D四人, 他们分别提取了同一个目标对象, 这样他们四人就组成了一个协作组, 在此协作组中的这四人彼此是可见的, 如果他们对所提取的同一对象完成改动工作的顺序是A→D→B→C, 那么先完成改动工作的人要将他所完成改动后的内容和要求发送给其他未完成改动的人, 最后的完成改动工作的开发者来实现改动的合并任务, 并且需要按照版本模型的规则将完成改动的内容存回数据库中。在该协作组中, 每个协作组中的成员在接收到其他成员的改动内容后都要将自己的改动与之合并, 之后发送给其他成员, 发送完毕后, 该成员可以退出协作组, 也可以留在协作组中作一些辅助性的工作。在该协作组中, 只有最后完成改动工作的人可以将改动结果送入数据库, 否则他所做的改动就会被覆盖。

2.2协同信息表

协同信息表为管理协作带来了方便, 在数据库中的每个组件对象, 都需要有一个协同信息表L (oi) , 根据开发者的加入和退出情况, 该协同信息表的内容会添加或者删除一个表项。作为协作组的成员, 他可以同时提取多个对象, 这时他就成为了多个协作组的成员。因此在工作时, 为了避免造成数据不一致现象的发生, 不仅要考虑单个组员在不同组中的工作状态, 还要考虑到不同组之间的协作情况和相互影响。

考虑一个协同数据库由几大功能模块构成, 这些模块形成系统的几大特性, 每一个特性可能都有若干候选选项。不同的选择组合使系统的功能会发生变化, 从这些意义上讲协同数据库可以表示为

其中Pi (i=1, …, m) 表示数据库中的特性;

其中pj (pi) (j=1, …, ni) 表示每个特性Pi的可能选择:

其中Ck (pi) (k=1, …, si) 表示每个特性选项Pi所包含的组件, 不同特性的候选及其所包含的组件对象数目可能是不同的, 在面向对象的系统中, 将特性模块也看成对象, 称之为特性选项对象, 若用Ok表示任何的组件对象, 即Ok可以代表Pi或Ck (pi) , 无论用户从数据库中提取了何种对象, 都可以形成协作组, 如图1, A, B, C, D分别提取了不同的组件对象, 从而产生了几个相应的协同信息表:

针对组个O1, O2, O3, O4, 就产生了3个协作组。

若所有被提取的对象Oi, Oj, …之间都没有关联和依赖, 或者有依赖和关联的对象Oi, Oj, …总是同属于一个协作组, 那么问题就变得简单了。

第一种情况使协作者可以简单地完成对象的接收合并或传送到其他协作者工作区;第二种情况 (如图1) 若只有对象O1, O2有关联, 它们与其他对象无关系, O3, O2尽管是被两个协作组提取修改, 但是它们是在两个协作组中同时被提取的, 因此, 响应的开发者也可以像第一种情况一样去对它们进行处理。

在协同管理中, 协作组通常以两种方式形成, 一种是以上我们介绍的协作组的成员通过从数据库中提取了共同的组件对象, 另一种则是因为合作任务的需要而组成。系统数据库中各软件对象之间存在着千丝万缕的联系和依赖, 这些关联和依赖在数据库中形成了一个关系图, 图中各个对象间形成了依赖链。每个系统用户在某一时间提取的内容是该系统数据库的子集。当协作开发者完成改动工作后不仅需要将改动后的结果发送给本协作组成员, 同时还要将改动结果发送给组件依赖的开发者。对象改动合并及数据库提取的最终实现要靠协同管理系统的版本控制机制和协同事务来实现。

三、协同管理的任务模型

3.1任务划分

对软件项目的任务进行划分和对目标进行管理和控制是协同管理系统的另一个目标。

根据开发项目或任务的场地不同可将任务分为原子任务和复合任务, 可以在一个工作区或场地内完成的任务被称做原子任务;而复合任务则是更复杂的需要有更多的协作来完成和实现的任务。假设一个任务用T来表示, T1是其中的一个子任务, 如果我们要在网上协同完成这个任务, 那么首先我们就要按照一定的原则把所要完成的这个复合任务划分成许多个读写集[R1, W1][R2, W2][R3, W3]…[Rn, Wn]。

对于一个复合任务的划分可以有两种方法, 一种方法是按照开发者成员数量划分, 即有几个人就划分成几个子任务。另一种方法是按照子系统的结构划分, 也就是根据所要完成的复合任务的模块进行的划分, 设该读访集中有N个模块, 那么每个R都是一个子任务的开始点, 这种划分方法也是软件工程中最常见的划分方法。

任务划分会对分析结果产生影响, 当两个读操作集重叠时不会产生影响, 但当一个读操作集与一个写操作集重叠时, 一个子任务会对另一个子任务产生影响, 当两个写操作集重叠时, 两个子任务有可能会对同一个组件进行改动, 波及覆时, 会使两个子任务间产生影响。通过对任务划分的分析和细化从而使一个复合任务内部的各个子任务间的的相互依赖关系尽可能的减少是提高效率, 改善工作质量的最好方法。通过影响分析方法可能改善协同工作的计划和调度, 影响分析方法也可以改善软件模块划分。复合任务经过初始的任务划分, 产生了若干个工作命令, 每个开发者接收到属于自己的工作命令, 建立了一个子任务网, 在子任务读写集之间重叠的开发者属于同一个协作组。

3.2任务调度

任务划分完成后, 复合任务的管理员或协调系统会进一步对子任务进行调度。一个复合任务被划分成若干个原子任务, 为了完成整个复合任务, 管理员会对分散于各个场地的子任务进行调度, 这种调度和实施的过程叫做事务处理。

摘要：本文就如何建立一个支持网络软件协同开发活动的环境和信息系统, 如何在此系统中进行任务划分和协同管理等方面展开了讨论, 提出了协同活动管理中对象性、关系性和任务性这3个方面的分析模型, 并进行了较为深入的设计和讨论, 它以软件组件对象为核心描述了对象模型;以“最后离开者关门原则”讨论了关系模型;以任务划分方法分析了任务模型。

关键词：协同开发,管理对象性,关系性,任务性

参考文献

[1]赵逢禹.软件协同设计[M].北京:清华大学出版社, 2010

[2]张海藩.软件工程导论[M].北京:清华大学出版社, 2012

[3]姜坤.基于动态工作流的网络协同办公系统建模方法研究[J].科技通报, 2012.8

[4]刘钢.异地合作设计服务研究与实现[D], 西安:西安交通大学, 2011

软件开发模型第10篇

1 理论概述

1.1 计算机支持的协同工作

“计算机支持的协同工作”定义为[2]:地域分散的一个群体借助计算机及其网络技术,共同协调与协作来完成一项任务。它包括协同工作系统的建设、群体工作方式研究和支持群体工作的相关技术研究、应用系统的开发等部分。目前CSCW的研究集中在协同设计、访问控制、协同机制等方面。

1.2 协作模型

协作模型是CSCW系统的核心和基础,其目的是描述群体协作的方式、机制、管理、协调以及对协作过程的控制等[3]。

在不同应用背景下的CSCW协同工作模型会有很大差异,从CSCW出现到发展至今产生了许多协作模型,如会话模型、会议模型、过程模型、活动模型以及层次抽象模型等,从各个不同的方面对群体协作加以抽象。会话模型定义了两人之间的交互协作关系;会议模型描述了多人之间进行交互协作的方式;过程模型和活动模型则是刻画了共同完成任务的协作各方的分工和协作过程。但现实世界中往往需要不同层次和不同方式的协作才能完成一项任务,单一的协作模型也就不足以能满足对协同任务的协作方式和过程的描述。因此,对于一些具体的任务往往要采用多种模型混合,按不同层次加以描述。

Flavio提出了以通信、会话和会议相结合的三层协作模型[4]来描述一个会议系统的协调控制的结构。而Vin H.M等人用会议、活动、合作三个层次来抽象群体协同动作[5]。清华大学在并行工程的基础上提出了面向对象多层次协同模型[2]。罗杰文等人把表示与推理应用到主体的具体设计中,提出基于动态描述逻辑的多主体协作模型[6]。

2 软件开发协作模型

在CSCW定义的基础上,软件协同开发可定义为:软件组织利用计算机网络、多媒体以及人机接口技术,将时间上分离、空间上分布、工作上相互依赖的多个协作成员及其活动有机地组织起来,共同完成某项软件开发任务的分布式协同工作过程。软件开发过程由一系列任务组成,任务往往由称为活动的子任务组成,而活动又可分解为更具体的操作,正是这种协同工作的层次结构决定了软件开发的协作模型是一种层次结构。

根据软件开发工作的层次特点,本文在清华大学的面向对象多层次协同模型的基础上提出任务、活动和操作三层结构的软件开发协作模型,将软件开发中的协同工作划分为任务模型层、活动模型层和操作模型层,分别采用下文介绍的过程模型、活动模型和会议、会话模型进行描述,如图1所示。

2.1 任务模型层

软件开发是一个复合过程,可以分解为一系列相互关联而又相对独立的串行或并行的任务或子任务,整个任务的集合构成了软件过程。对于不同的软件过程,任务划分的方式可能不同,如RUP就将软件过程划分为九个工作流,每个工作流可以看作一个粗粒度的任务。任务模型层具体使用“过程模型”来描述,使用项目管理技术或工作流技术来实现。任务模型层可以看作对软件过程的宏观分解,分解得到的结果是一个粗粒度的工作流。任务分解结构(Work Breakdown Structure,WBS)是项目任务分解的常用方法。

2.2 活动模型层

每项具体的任务可以分解为一系列相互关联而又相对独立的串行或并行的活动,形成一个工作流,涉及到具体的角色和资源。活动模型层具体使用“活动模型”来描述,使用活动理论或工作流技术来实现。活动模型层可以看作对软件过程的微观分解,分解得到的结果是一个细粒度的工作流。

2.3 操作模型层

每项活动由具体操作序列构成,操作可以看成特定时刻拥有特定权限的角色使用特定工具对工件的改变。操作之间的关系可以是串行或并行。操作可以分为独占操作、并发操作和协同操作,其中并发操作和协同操作是这一层主要解决的问题。操作模型层根据不同的协作情况使用“会话模型”、“会议模型”等来描述,使用具体的协作支持工具来实现。

3 软件开发协作模型的形式化定义

定义1基本元素集合E={ROL,RTF,TOL,GOL,USR},即角色集ROL,工件集RTF,工具集TOL,目标集GOL,成员集USR。

定义2操作OPR={ROL,RTF,TOL,fOPR},fOPR:RTF→2TOL是一个映射,描述工具和工件之间的对应关系。特定角色的操作为OPR rol={rol,RTF,TOL,fOPR},rol∈ROL,OPR rol∈OPR。描述特定角色使用特定工具在工件上的操作。

定义3活动ACT={ROL,OPR,f ACT},f ACT:ACT→2OPR是一个映射,描述活动和操作之间的映射关系。特定角色的活动为ACT rol={rol,OPR,f ACT},rol∈ROL,ACT rol∈ACT。活动由特定角色承担,由一组操作构成,活动和操作之间具有映射关系。

定义4活动结构关系ASR={ACT,f ASR},f ASR:ACT×ACT→{True,False}是一个映射,活动结构关系描述了一项任务中各个不同活动之间的亲子关系,如果两个活动之间存在着直接父子关系,则?ASR为True,否则?ASR为False。

定义5任务TSK={ROL,ACT,f TSK},f TSK:TSK→2ACT是一个映射,描述任务和活动之间的映射关系。特定角色的任务为TSK rol={rol,ACT,f TSK},rol∈ROL,TSK rol∈TSK。任务由特定角色承担,可以根据任务和活动之间的映射关系分解成若干相互协同的活动。

定义6任务结构关系TSR={TSK,f TSR},f TSR:TSK×TSK→{True,False}是一个映射,任务结构关系描述了不同任务之间的亲子关系,如果两个任务之间存在着直接父子关系,则f TSR为True,否则f TSR为False。

定义7访问控制关系ACC={ROL,OPR,RTF,fACC},f ACC:ROL×T→2OPR是一个映射,访问控制关系描述特定角色在特定时间T对工件所能进行的操作。

定义8角色扮演关系RAR={USR,ROL,fRAR},f RAR:USR×T→2ROL是一个映射,角色扮演关系描述群体活动中的成员在特定时间T承担的角色。特定用户的角色扮演关系为RARusr={usr,ROL,fRAR},usr∈USR,RARusr∈RAR。

定义9群体GRP={USR,f GGR},fGGR:G→2USR是一个映射,描述群体的结构关系。

定义10软件过程PRC={GRP,GOL,TSK,f PRC},f PRC:GOL→2TSK是一个映射,描述目标到任务的映射关系。协作开发过程定义为群体为共同目标所执行的一组任务。

定义11关系集合R={fOPR,f ACT,f ASR,f TSK,f TSR,fACC,f RAR,fGGR,f PRC},即操作关系fOPR,活动-操作映射关系,活动结构关系f ASR,任务-活动映射关系f TSK,任务结构关系f TSR,访问控制关系fACC,角色扮演关系fRAR,群体结构关系fGGR,目标-任务映射关系f PRC。

定义12软件开发协作模型SDCM可以描述为三元组。表示软件开发协作模型由基本元素E构成,执行任务TSK、活动ACT、操作OPR三层构成的软件过程PRC,并遵循R所确定的关系。

4 应用实例

软件开发协作模型适用于建立任何软件过程的协作模型。Rational统一过程(Rational Unified Process,RUP)是基于UML和构件式架构的迭代增量型开发过程,包括6个核心工作流:业务建模、需求分析、系统分析与设计、实现、测试和部署,3个支持工作流:配置与变更管理、项目管理和环境[7,8]。

RUP协作模型定义为:

PRC={Rational统一过程}

TSK={业务建模,需求,分析和设计,实现,测试,部署,配置和变更管理,项目管理,环境}

以下仅以“业务建模”为例展开,其他子过程的细化限于篇幅不再细述。

ACT业务建模={评估业务状态,描述当前业务,定义业务过程,精化业务过程定义,设计业务过程实现,精化角色和职责,探索过程自动化,开发领域模型}

OPR业务建模={ROL业务建模,RTF业务建模,TOL业务建模}

ROL业务建模={业务过程分析人员,业务设计人员,项目相关人员,业务评审员}

RTF业务建模={业务构想文档,业务用例模型,业务分析模型,目标组织评估,业务规则,补充业务规格说明,业务术语表,业务架构文档}

TOL业务建模={可视化业务建模,模型生成和维护}

5 结论

现有CSCW的理论与技术不完全适用于软件开发领域下的协同工作,有必要研究软件开发语境下的协作模型。针对软件协同开发的特点,本文在分析和利用现有协作模型的基础上,建立了任务、活动和操作三层结构的软件开发协作模型,对模型及其基本元素给出形式化定义,并应用于建立RUP协作模型。模型的应用实例证明该软件开发协作模型能够较好地描述软件开发过程的协作模式。

摘要：协作模型是CSCW系统的核心和基础,其目的是描述群体协作的方式、机制、管理、协调以及对协作过程的控制等。该文从软件协同开发的特点出发,在分析和利用现有协作模型的基础上,建立了任务、活动和操作三层结构的软件开发协作模型,给出模型及其基本元素的形式化定义,并将其应用于建立RUP协作模型。

关键词：计算机支持的协同工作,协作模型,软件开发,过程建模,统一软件过程

参考文献

[1]Bandinelli S,Di Nitto E,Fuggetta A.Supporting cooperation in the SPADE-1environment[J].IEEE Transactions on Software Engineering,1996,22(12):841-865.

[2]史美林,向勇,杨光信.计算机支持的协同工作理论与应用[M].北京:电子工业出版社,2000.

[3]郑庆华,李人厚.CSCW的一种建模与实现方法[J].计算机学报,1998(21):270-276.

[4]Depaoli F,Tisato F.A Model for Real Time Cooperation[R].Proc.of CSCW'91,1991.

[5]Robinson J A.Communications services architecture for CSCW[J].Computer Communications,1994,17(5).

[6]罗杰文,史忠植,王茂光,等.基于动态描述逻辑的多主体协作模型[J].计算机研究与发展,2006,43(8):1317-1322.

[7]Kruchten P.The Rational Unified Process an Introduction[M].Boston:Addison Wesley,2000.

软件开发模型第11篇

1 高校软件开发的特点

高校软件开发不同于成熟的软件组织软件开发,我们从人员组成,项目特点和管理组织分析了普通高校软件开发的特点。2.1成员组成特点

高校软件开发团队的成员一般都不是专业的软件开发人员,一般是由一个导师领导的多种人员组成的临时团队,完成一个具体的项目。具有以下特点。

1)成员来源多样性。一般高校软件开发团队都由导师,教师,研究生及本科生组成。以我们团队为例,由1名导师,2名教师,4名硕士生,2名本科生组成。

2)学历专业多样性。一般软件团队多由从博士到本科生,具有不同专业背景的人员组成。

3)年龄跨度大。商业软件开发组织多由青中年专职软件开发人员组成,而高校软件开发团队多有几十岁的教师和20岁左右的年轻学生组成。

4)技术背景差距大。一般都是根据临时的项目,临时组建的团队,团队成员往往具有不同的技术背景,在编程语言,分析设计能力,更人能力成熟度上都有较大的差异。

5)项目成员目的单纯性。开发团队的教师的目的就是完成横向的或纵向的科研项目,而学生的目的则是在进入社会前获得一次比较正规的专业化的培训。

1.2 项目的特点

高校从事软件项目开发的优势在于创新性、专业性和低成本性。所以高校主要从事以下两种项目的开发。

1)研发型软件。主要是指完成研究型项目的软件系统,用于验证相关研究的正确性或者将相关研究转化为具体生产力或半生产力。这类项目一般都具有创新性、结果不确定性、需求明确性、算法复杂性等特点。

2)企业定制型软件。高校软件开发团队完成的另外一类项目是由企业委托的应用型项目。这类项目一般都具有开发周期固定、项目规模较小、项目经费较少和领域性较强等特点。

1.3 组织管理的特点

高校软件开发团队是由教师和学生组成的临时性的非营利性的软件开发组织。在组织和管理上具有以下特点。

1)软件项目管理缺乏规范。普通软件开发组织都有正规的组织规范和管理规范,有成熟的软件开发过程,软件配置过程、软件质量管理过程实践。具有CMMI三级以上的组织能力成熟度。而高校软件开发团队成员一般都不具备较高的PSP能力,同时软件开发团队也是一个临时的组织,一般不具备规范的管理过程。

2)组织松散性。高校软件团队大部分是非利益性组织,团队成员组织在一起不为谋取薪水,因此没有严格的纪律和考核措施来管理团队成员。

3)非专职性。高校软件开发团队的教师一般还要承担教学和科研任务,学生还有课堂学习任务,软件开发更多的是利用课余时间进行。因此都非专职的软件开发人员。

4)易于沟通协作性。团队成员之间没有强力的利益关系和竞争关系,成员之间关系融洽。各成员具有共同的爱好和热情聚集在一起完成一个软件项目。在地理上团队成员一般都分布在一个实验室。这决定了团队成员之间易于沟通交流,易于团队协作,易于发挥集体的力量解决实际问题。

1.4 高校软件开发的好处与优势

组织好高校软件开发对社会、教师和学生都有好处。高校是培养高等专业人才的地方,这里有大量思维活跃、具有创新思维的人才,每年高校都有大量创新性的研究成果产生。但是其中真正能够转化为生产力的并不多。重要原因是研究和生产,研究和市场脱节。高校软件开发可以直接在高校就将研究成果转化为直接的生产力。教师通过完成纵向和横向的科研项目也可以增加收入,为更多的研究打下物质基础。学生通过参与实际的软件项目开发,可以在毕业前获得宝贵的将理论用于实践的机会。

2 改造的XP敏捷模型

2.1 XP敏捷模型介绍

XP(Extreme Programming)极限编程是由Kent Beck提出的一种“轻量级”的软件开发方法,他建议XP应用于规模小、进度紧、需求变化大、质量要求严格的项目[3]。

XP强调适应而非预测,以人为中心、非以过程为中心[1]。XP敏捷模型的核心价值观是沟通、反馈、简化和勇气。XP的最佳实践是:现场客户,计划博弈,系统隐喻,简化设计,集体所有权,结对编程,测试驱动开发,小型发布,重构,持续集成,每周工作40小时和编程规范。

以上可以看出,XP提倡的最佳实践和实用的项目、团队类型和高校软件开发组织具有天生的一致性,但是XP所提倡的重视沟通、简化中间过程、不重视文档和集体拥有代码要求团队成员具有均衡的能力与高校软件开发团队实际情况不太符合。因此我们对XP过程模式进行了改造以更好地使用高校软件开发。

2.2 基于原型模型对XP模型的改造

针对高校软件开发的团队、项目、管理上的特点,我们对XP模型主要进行了一下4条改造。

首先,针对高校软件开发团队成员技术能力差距大的特点,针对一个具体的项目,从业务领域知识到软件实现技术,教师、学生之间都有较大的差距。我们在进行以XP为指导的软件具体开发过程之前,首先进行项目的抛弃型原型模型开发。我们采用分析用户需求,提取核心功能和对本团队有技术难点的部分进行开发原型系统。通过原型系统的开发一方面使团队成员熟悉了相关的开发语言、开发流程、软件架构和业务领域知识。尤其是能帮助刚进入项目组的低年级学生进入软件开发的角色。另一方面,原型系统对于研究型项目能够辨别算法的正确性,确定是否有进一步研发必要,对于企业定制软件可以通过可以运行的原型系统帮助开发团队与用户充分交流,较准确地确定软件的初始需求。引入原型模型后,改造的XP模型项目开发过程如图1所示。

其次,针对XP模型,重视合作,现场交流,省略文档等中间过程的问题。由于学生3-4年既要毕业,并且由于学习的需要一般学生在大学阶段能够从事软件开发的时间为1-2年,所以高校软件开发团队人员的更替较为平凡,怎样将个人的经验和积累成为整个软件开发组织的经验和技术积累,是高校软件软件开发团队需要解决的问题。我们要求项目的需求分析和设计阶段具备完善的项目文档。UML是一种通用的面向对象的标准建模语言,在需求阶段采用用例图和活动图对系统进行建模,设计阶段用类图、包图、部署图、时序图、活动图、协作图进行建模。与XP迭代开发一致,我们将文档纳入版本配置管理库,一次迭代一个新的文档版本。甚至项目完成后,还要对文档进行梳理和总结。这些文档成为整个开发团队的持续价值。新加入团队的成员可以通过这些文档获得宝贵的开发经验和方法。也为后续项目维护打下了基础。

再次,XP模型强调简化设计,快速满足用户要求。由于高校开发团队一般由导师领导,一般都有固定的研究方向,所开发的项目往往类型比较单一,所设计的领域也比较单一。所以我们在XP简化设计的基础上引入了RUP模型的以架构为中心,基于构件开发的技术。这可以分清系统每一部分的责任,使每一部分具有清晰的边界,同时可以有效复用团队过去开发和研究的成果。同时也降低了软件性能、可靠性等方面的风险。

最后,XP强调集体拥有代码,系统的架构由整个团队负责。这要求开发团队成员具有均衡的能力。其与高校软件开发团队成员是开发经验、技术背景差距都很大的实际情况相矛盾。我们对XP的改造是:由开发团队中的技术实力较强的教师充当系统架构师。他拥有全部核心代码,同时系统的关键变更必须由系统架构师最终决定。

3 应用开发实践

3.1 在线投稿系统简介

在线投稿系统是为方便作者投稿,编辑管理稿件,专家审稿的一个Web应用系统。主要功能包括作者注册个人信息,作者在线投稿,作者在线查询稿件,编辑查询稿件,编辑处理稿件,专家查询待审稿件,专家审理稿件,专家修改个人信息,管理员进行专家管理,作者管理,编辑管理,栏目管理,系统维护管理等。

在线投稿系统的技术难点在于:1)稿件处理流程的控制;2)综合专家信息,稿件类别和推荐专家进行综合决策审稿专家;3)可靠的邮件服务。业务需求主要模糊的领域:1)稿件处理模式;2)专家审稿模式。

3.2 改造的XP模型的应用实践

以下简单介绍改造的XP模型的重要最佳实践在“在线投稿系统”开发中的应用。

1)开发原型系统,分析编辑部的稿件处理模式,完成整个稿件处理流程的原型系统,同时开发可靠的邮件服务系统。

2)做好计划,根据在线投稿系统的特点,我们确定系统进行2次迭代,第一次迭代由充当架构师的教师完成系统的三层架构,确定系统的主要结构。完成稿件处理的流程和专家审稿模式。第二次迭代完成稿件投稿、查询等其余功能。每一次迭代有需求和设计的版本。用UML统一进行建模。每一次迭代产生一个可运行的版本。

3)重构,设计阶段强调组建式开发,每完成一个主要功能模块,由项目组长组织进行代码重构,强调功能单一,可复用性高,结构松散。

4)双人编程,由两个人共同完成同一功能模块,一老一新进行搭配,主要由老成员完成代码,新成员完成代码走查和单元测试。

5)集体拥有代码,软件项目配置管理库,所有成员具有相同的阅读权限,不同模块的成员相互走查代码,任何问题都由全团队成员一起讨论。