软件过程模型（精选12篇）
软件过程模型 篇1
热门行业软件的研制开发以及使用在人们的生活中占有重要地位，但是由于在软件研制开发的过程中不能够根据软件的性质进行很好的定义以及科学的进行管理，因此，在实际研制开发的过程中存在着一些不可避免的问题。要想切实的解决这类问题需要针对性的制定出有效可行的软件模型。分阶段的进行流程性的计划工作，对于软件模型进行重用裁剪，依据不同的需求制定软件。
1传统软件的开发过程研究
软件开发中真正的管理手段是根据软件过程模型，生产以及软件今后所要进行演化为目的进行的开发过程。最为经典的瀑布模型是根据自身的需求，从分析到设计再到最后阶段的编码和后续阶段所需要的都是阶段性进行整合的。瀑布模型在设计的过程中是属于结构化程序设计和开发并非属于以对象技术为基础的现代软件开发的。主要原因是：
1.1开发前期复杂性过于繁琐，有着特殊的线性特点。需要研发人员在开发的过程中进行阶段性分析，对于复杂的问题进行全面深入的了解。
1.2遇到问题时没有及时的进行反馈和更新，随着生产的进一步需要，即便有了好的想法也不能够被任用，出现错误的阶段无法及时的进行了解，当问题真正的暴漏出来才意识到在进行修改无论是在人力还是物力方面都存在着较大的浪费。
1.3软件的生产周期规划的不合理，开发人员在研制的过程中往往会注重编码和测试的工作，而最后进行系统分析和设计的时间减少。因此周期不合理科学的规划使得设计思想与现代的软件开发和设计产生了极大的反差。
1.4软件的综合性能少，不能够支持反复使用和健壮性，可扩展性等，也不易维护软件的性能。
对于大型的软件开发来说，是一项工程，因此在实施研发的过程中需要按照工程的一定顺序进行科学的有组织的生产管理。严格的按照所需要的进行整合分析，设计以及实现测试相统一的原则。对软件进行一系列的维护。选取最为合适的开发模型，利用最合适的设计方法生产出最有效，性能最高的软件产品。
2模型的不足的完善和构造的创新
软件的过程不是单方面组合的，而是由一系列的阶段，方法，技术和实践结合而成，一个足够灵活，有保障的软件模型能够为软件产品的研发提供可靠的参考性，研发人员可以依据它来进行开发和维护产品。在软件模型开发的过程中所有的活动都需要提供统一的保障，因此对参与活动的所有工作人员都需要提供一定的帮助和指导，这样有利于人员之间的有效沟通信用的开发。为了管理更加的便利，需要加大对过程演化的检测力度。准确的说，应该具备以下几个特点；
第一：按照规定的周期进行科学划分，管理阶段强化力度和制度，避免开发过程中的分裂现象。
第二：复杂问题可以延迟处理，但是要及时的进行反馈更新制度，提高应变能力。
第三：在合理的周期制度下，有效的支持各软件的再次使用。
第四：符合一定的要求标准，具有一定的特短能够扩展，可重用。
2.1阶段的划分
作为开发工作的第一次划分，这个阶段过程中模型首先要制定各个阶段开发和演化的时序和约束条件。建立一个系统的过度准则，以便于从一个阶段更好地过渡到下一个阶段。具体细分可详细到五个内容：
(1）初始阶段制定一个确切的目的，进行捕获具体需求，通过开发的周期工作而制定，科学合理应具备一定的可实施性。
(2）细化阶段，在初始阶段的基础上进行进一步的改进完善。制定一个详细的计划对整个阶段进行指导。
(3）构造阶段。构造阶段是开发部过程中最为重要的一个阶段，也是这个模型过程的核心，通过构造可以满足这个阶段的所需产品的数量和质量问题。完成系统可行性。
(4）实施阶段。是模型过程中最后一个操作阶段，实施阶段的目的是完成最终的操作，在修改无错后将系统转交并投入使用。
(5）维护阶段，这个阶段主要负责的是对系统的进一步更新和维护问题，进行信息的反馈。各个阶段的分化完成后，需要制定一个主要的周期任务对增量开发进行约束分管。
2.2迭代与增量的开发
大型的开发就像是一项工程，相对来讲比较困难，因此需要缩小管理的步骤进行软件产品的策略研发。将各个阶段划分为较小的部分进行实施，每个小项目作为一个独立的实体，在完成后，对其进行评估测评判断是否需要增加新要求。以便在下一个迭代的过程中进行弥补。而受控式的迭代是个有着严格的时间计划和详细规划的过程。因此需要研发人员根据实际情况进行有计划步骤的指导活动。
2.3活动和工作制品
一般来说迭代的过程拥有5个阶段，对资源的需求，整合分析，图样设计，产品的实现和使用测试。也可以将每个工作流程分为若干个小型项目，每个小项目只能生产一到两个工作制品。这种方式既保障了工作人员能够在正确的引导下进行工作也能保证产品的质量。
2.4详细过程的规划
根据制作过程，模型的初始阶段和实施阶段的迭代相对是比较简短的过程。初始阶段中需求工作流，根据软件开发的过程进行分析和设计。实施阶段主要是实现和测试工作流。而维护阶段是个特殊阶段不需要受控迭代。
3结束语
信息时代的快速发展，带动了生产企业和人们生活水平的提升，对面信息量大的时代生产企业和受众群众有了更高的需求，为满足人们的需求，应该尽量的在软件过程的模型化中研究出更易管理和扩展的功能。
摘要：近些年来,软件开发行业越来越受到人们的重视,无论是该行业的创造者还是生产者亦或是使用者,对该行业都给予极高的热情。但高亢的热情也无法使得产品能够十全十美,软件在实际开发的过程中存在的诸多的问题。主要原因是在软件开发组织的过程中不能够很好的进行定义和管理,无法构造出一个有效的可实施的模型。因此,本文主要针对软件过程的模型化进行研究。
关键词：软件过程,模型化,研究
参考文献
[1]王军.软件过程模型应用策略[J].计算机系统应用.2008(06)
[2]高禹,毕振波.软件开发过程模型的发展[J].计算机技术与发展.2008(07)
[3]荆心,雷聚超.以活动为中心的软件过程模型的改进研究[J].西安工业大学学报.2006(03)
[4]王勇,张发勇,周顺平.CMM质量保证的理论与实践[J].计算机工程与设计.2005(04)
[5]谷烽,姜云飞,毛明志.软件过程模型回顾与分析[J].现代计算机(专业版).2005(05)
软件过程模型 篇2
为解决该危机，必须进行软件过程管理与软件过程改进。
本文首先提出了过程思维的这一新理论概念;其次剖析了软件过程改进的框架;最后给出软件过程的评估方法。
【关键词】软件过程管理 软件过程改进 过程思维 CMM
一、产生背景
目前，软件行业正处于从手工作坊到在其它工业生产中普遍使用的工程化的进化之中。
人们通常都会感到“软件危机”的痛苦：软件的推出总是晚于计划，而成本却往往高于预算，但功能却往往没有预先设计的那么多，并且后期对软件产品的维护比较困难。
为了解决这个危机，软件开发领域中已经逐步开始引入软件过程管理与软件过程改进的概念。
软件过程改进是指在软件开发过程中除了应用先进的软件开发技术和软件开发方法外，还有一整套的软件管理和改进技术。
常见的软件过程改进方法有：CMM、ISO9000、ISO/IEC 15504 等，其中CMM又是事实上的软件过程改进的工业标准。
二、过程思维
“为了解决软件问题，重要的第一步就是将整个软件开发任务看作一个可控的，可度量的以及可改进的过程。”，倡导过程思维的先驱Watts Humphrey在他的著作中是这么阐述过程的。
过程思维也是一种自然的思维方式，我们所拥有的知识和经验实际上也是采用和过程相类似的方法保存在大脑中;但过程思维方式和传统思维方式有所不同。
对于一个软件项目组的成员来说，如果每个成员都能采用相同的过程思维方法，将会统一各个成员的工作目标，为实现最终的目标而共同努力。
如果软件的开发没有围绕过程为中心进行，往往会导致软件开发过程的混乱，使得开发人员不得不到处救急，来维护软件。
三、软件过程改进的框架
当有效的软件过程环境建立好了以后，过程环境中的机制有利于我们建立过程文化和过程架构。
软件过程改进的战略应该建立在当前的软件过程改进环境下的一个整体框架之上。
这些整体框架中标识出了软件过程改进中必须包括的关键的领域。
下面我们介绍一种软件过程的改进框架。
该软件过程的改进框架包括以下四个方面的内容：
(一)软件过程架构：支持过程环境需要两种类型的架构。
一为组织及管理方面的架构，包括角色和职责;另一为技术方面的架构，包括技术工具和相关的设备。
(二)软件过程改进规划图：它指定一个将要采用的软件过程模型，并且规划出实现高效的软件过程的步骤。
软件过程改进规划图为我们指明了实现软件过程所要经历的各个阶段及层次以及为了实现这些目标所必经的关键点。
这些过程模型可以是CMM/CMMI或者ISO/IEC 15504等。
(三)软件过程评估方法：它指出对组织当前软件过程，活动以及架构进行评估所采用的方法及技术.通常评估是根据软件过程改进规划图而进行的。
(四)软件过程改进计划：为进行软件过程改进，根据评估中所发现的各种问题，提出相应的改进解决方案。
通过实施软件过程改进计划，可以提高现有的软件过程水平。
构成框架的这四个部分是相互关联的，任何一个软件过程的改进策略都应该包括这几个部分，否则会造成冲突。
通常是先根据软件过程改进规划图对已有的架构进行评估，然后制定软件过程改进计划，再进行改进，从而达到改进规划图中的软件过程成熟度的级别。
四、基于CMM的软件过程改进
在软件过程改进中，关键要做好软件过程改进规划图的分析工作，并在此基础上进行软件过程评估分析。
下面结合CMM(Capability Maturity Model for Software---软件能力成熟度模型)综合分析软件过程改进。
(一)软件过程改进规划图
软件过程改进规划图会划分出过程改进中不同的阶段，并告诉我们在每一个阶段过程应该具备的特点和属性。
软件过程改进规划图中应该先定义好目标，然后通过过程改进活动提高整个组织的能力成熟度，并且达到最终的目标。
目前最为著名的过程改进规化图是由美国卡内基――梅隆大学软件工程研究所(SEI)提出的能力成熟度模型(CMM)。
CMM主要用于软件开发过程和软件开发能力的评估和改进，其目的是让从事软件开发的公司和人员从被动地去解决所碰到的难题转变为以成熟的、规范化的方式来解决问题，从而提高软件企业生产软件的能力和水平。
(二)软件过程评估
软件过程评估是对一个组织的软件过程进行评估与检查。
软件过程评估可以为我们提供关于当前组织内部所采用的软件过程状态的基本情况描述，而它正是我们进行软件过程改进的基础。
软件分析业中经常使用CMM进行过程评估与改进。
CMM是一个框架，是软件组织提高过程能力的一种途径。
CMM在设计时就以考虑到各种使用问题，所以评估组可以将CMM作为他们对组织内已存在过程进行评估的基础，从而确定出过程的强项和弱点(与CMM中过程定义有关的内容)。
这种评估方法通常分被描述为基于CMM的评估。
五、结束语
要克服软件生产中的这些不如人意的地方，我们就必须采用系统的改进方法。
对一个软件而言，要降低成本，提高效率，提高软件的质量，一个规范化的，系统的软件过程和质量改进方法是非常重要的。
总之，要有效的进行软件的开发，必须进行软件过程的改进，就必须要有效的过程环境，为了使过程环境更加有效，我们需要以下角色和机制的支持：明确的过程职责;关于过程的培训;对过程的度量;对过程执行情况的监控;来自于过程使用者的反馈;来自于外部环境的反馈;过程的强制和检测。
这样才能进行有效的过程改进，从而最终实现我们的目标以及提高软件的质量。
参考文献：
[1]吴天荣，智明.CMM在软件过程中的一些思考[J].福建电脑，，(5).
[2]刘莉，傅英亮，陶强.基本质量的软件过程研究[J].计算机工程与设计，2007，(5).
[3]陈新炜.软件外包服务中的CMM应用[J].商场现代化，2007，(1).
软件质量度量模型探讨 篇3
关键词：质量度量；模型
中图分类号：TP311.52 文献标识码：A文章编号：1007-9599 (2011)05-0000-01
Software Quality Measurement Model
Fan Xuedong
(Xi'an Institute of Foreign Affairs,Xi’an710077,China)
Abstract:With the growth demand for software projects,software
development process and quality metrics research is very active.How grasp goos software measure model relationship between analysis and software process,it is extremely important.As software measure system model used in the software development process,software quality improvement and protection value of a positive reality.In this paper,do the quality control of measurement model.
Keywords:Quality measure;Mode
一、度量体系模型分析：
目前计算机行业普遍认为：软件工程度量的方式分直接度量和间接度量两种：1.直接度量：对过程的直接度量包括度量投入的成本、完成的工作量等等；对产品的直接度量包括产生的代码行数LOC、文档的页数、缺陷数/千代码行、软件执行速度等等。2.间接度量：软件的正确性、效率、可靠性、可维护性、可用性等难以直接度量。一般通过对其他项目直接度量的结果进行分析，获取对本项目的间接度量结果。
从另一个方面看，软件度量又可以分为面向规模的度量、面向功能的度量、面向个人的度量。面向规模的度量用以收集与直接度量有关的软件工程输出的信息和质量信息；面向功能的度量提供直接度量的尺度；面向个人的度量收集个人工作方式与效率方面的信息。可以根据面向规模的基本度量数据作一些简单的计算分析，进行面向规模的生产率、质量和单位成本的间接度量，例如：生产率=KLOC/人月；质量=错误数/KLOC；单位成本=成本数/KLOC。坚持度量并记录度量结果，积累组织的历史数据。利用这些历史数据，能够更科学地把握自己的工程能力，对工程项目作出更为精确的估算。使用KLOC作为关键度量准则已经有大量的案例，并且许多著名的度量模型也直接以KLOC作为输入；但是，这种方法不适应采用非过程化语言开发的实践，对于项目估算也存在不便，因为在项目开发初期，也没有现成的KLOC数据可用。随着面向对象方法的应用，也有人提出了以系统的对象数作为基本度量单位进行规模度量的方法。面向功能的度量是对软件和软件开发过程的一种间接度量方法。这种方法并不把注意力集中在生产结果(KLOC)上，而是以软件应当满足的“功能性”、“实用性”作为度量原始依据。
二、软件质量度量
软件质量特性可以定义为一种层次模型。ISO9000标准中，中国国家软件产品标准中都对软件的质量及其度量要素进行了规定和描述。软件产品质量度量贯穿于软件工程过程的始终。产品交付前的质量度量为评价设计、编码、测试工作提供了一个量化根据。这一阶段的质量度量包括程序复杂性度量、模块有效性度量等；软件交付后，在运行维护阶段进行的度量主要关注软件中残存的反映可靠性的差错数和系统可维护性方面。
度量软件质量的标准是用户对软件的需求，不符合需求的软件便不具备质量。标准的软件工程过程中，定义了一系列开发准则，用来指导软件人员用工程化方法开发软件，若不遵循这些准则，软件质量就得不到保证。质量定义中所提到的“需求”，既包括明确定义了的需求，也包括隐含的需求。因此，软件的可扩充性、可维护性就成了支持实现隐含需求的质量指标。度量软件产品的质量，除了严格度量最终产品的质量之外，还应包含对需求分析产品、设计产品、编码产品、测试产品等所有软件产品的全面度量。软件质量的定性、定量度量，可在开发过程中，结合各项技术产品的度量来进行。如对需求分析产品完备性，设计产品对需求项覆盖程度，编码产品对设计实现情况，测试用例对需求项的覆盖情况，模块聚合度、耦合度情况的度量，都可以作为间接的质量度量方法。在许多软件质量度量方法中，使用最广泛的是事后度量或验收度量，它包括对产品的正确性、可维护性、完整性和可用性的度量。(1)正确性：软件是否能正确地执行所要求的功能。可以用缺陷数/KLOC来度量；在产品交付后，根据标准的时间周期(一般为一年)，按照反馈的用户报告中的缺陷数进行度量。(2)可维护性：利用平均变更时间MTTC(Mean Time To Change)间接度量软件的可维护性。(3)完整性：这个属性反映软件系统抗拒针对它的安全攻击(事故或人为)的能力。完整性 = ∑(1－危险性×(1－安全性))。其中，危险性指一定时间内特定攻击发生的概率，安全性是排除特定类型攻击的概率。两者都可以从估算或历史数据中得出。(4)可用性：即“用户友好性”。可以从四个角度度量：学习应用软件所花费的代价；为达到有效使用软件所花费的时间；使用软件带来的生产率净增值；通过问卷调查得到的用户的主观评价。还要注意度量陷阱。卡尔•威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱：1.缺乏管理承诺；2.度量得太多太早；3.度量得太少太晚；4.度量了错误的事项；5.度量定义不严密；6.度量用于评估个人；7.度量用于激励而非理解；8.仅仅收集但不使用数据；9.缺乏沟通和培训；10.曲解度量数据。
对软件生产率和软件质量的度量，管理者能够建立改进软件工程过程目标。从而对整个开发组织的工作产生直接的影响。从另一个角度来看，充分地了解工作能力的现状，就有可能确立正确的改进目标。所以，必须通过对能力、效率、质量的度量进行度量数据的收集、计算与分析，并且将历史度量数据、当前度量数据进行集成，建立工程过程的“度量基线”，利用基线来评估各类改进工作的效用，估算新项目的规模、工作量、预测成本、质量指标。度量基线由以往的软件开发项目收集到的度量数据构成。有人将其称之为“数字化的经验”。
三、结论
软件过程模型 篇4
GIS工程学来源于系统工程学, 软件工程学和地理信息科学的结合。系统学、系统工程学、软件工程学、地理信息科学都是其理论基石。GIS设计是利用软件工程的思想, 结合GIS软件开发的特点和开发目标, 制定GIS软件开发的项目计划, 并对软件的用户需求和可行性进行分析, 从而设计软件的技术实现方案, 最后对软件进行实施和维护。
2 软件工程
在了解软件工程之前先介绍软件危机, 它是一种现象, 是落后的软件生产方式无法满足迅速增长的计算机软件需求, 从而导致软件开发与维护过程中出现的一系列严重问题的现象。
软件工程是多学科、跨学科的一门学科, 它借鉴了传统工程学的原理和方法, 同时应用了计算机科学、数学、工程科学和管理科学的很多理论与知识, 以求高效地开发高质量软件。从20世纪60年代软件工程学的产生到现在, 软件工程演变了三代。分别是20世纪70年代以结构化分析、结构化设计和结构化编程的第一代软件工程又称传统软件工程;20世纪80年代以研究面向对象分析和设计的第二代软件工程又称对象工程;20世纪90年代以组件技术的研究发展而来的第三代软件工程又称组件工程。软件工程代与代之间没有鸿沟, 他们不仅交叉重叠, 也携手并进。
3 软件过程模型以及其在GIS设计的作用
软件过程是按照软件项目的进度、成本和质量要求, 开发和维护软件所必需的一系列有序活动的集合。软件工程模型是按照工程化的思想设计提出的指导策略, 是一个覆盖整个软件生存周期全部活动和任务的结构框架, 这个框架给出了软件开发活动各阶段之间的关系, 相应的工作方法与步骤。
3.1 瀑布模型
瀑布模型 (Waterfall Model) 又称生存周期模型。是由W.Royce于1970年提出来的, 也称为软件生存周期模型。其核心思想是按工序将问题化简, 采用结构化的分析与设计方法, 将逻辑实现与物理实现分开。
3.1.1 瀑布模型的原理
瀑布模型是一种线性模型, 软件开发的各项活动严格按照线性方式进行, 每一项开发活动均以上一项的活动结果为输入对象, 实施该项活动应完成的内容, 给出该项活动的工作结果作为输出传给下一项活动, 对该项活动实施的工作进行评审。若工作得到确认, 则继续进行下一项活动, 否则返回前项, 甚至更前项的活动进行返工。
3.1.2 瀑布模型在GIS设计的作用
由于瀑布模型是一种以文档作为驱动的模型;阶段之间存在有序性和依赖性;将逻辑设计与物理设计清楚的划分开, 尽可能的推迟程序的物理实现;具有质量保证的观点;清晰的提供了软件开发的基本框架的特点使其在软件工程中占有重要地位。
瀑布模型一般适用于功能完整、性能明确、无重大变化的GIS软件系统的开发。但同时也应注意瀑布模型因为过早的考虑程序实现, 常常导致大量返工;它的阶段间的依赖特征会导致工作中发生“阻塞”状态, 如果大的错误在软件生存周期的后期才发现, 将导致灾难性的后果;它各阶段之间的大量规范化文档和严密评审增加了项目工作量;缺乏灵活性, 特别是无法解决软件需求不明确或不准确的问题, 因此其应用具有一定局限性。
3.2 快速原型模型
快速原型模型 (Prototyping Model) 是在用户不能给出完整、准确的需求说明, 或者开发者不能确定算法的有效性、操作系统的适用性或人机交互形式等许多情况下, 根据用户的一组基本需求, 快速建造一个可运行的软件, 然后进行评估。同时也使开发者对将要完成的目标有更好的理解, 再进一步精化、调整原型, 使其满足用户的要求。
3.2.1 快速原型模型基本原理
快速原型模型从需求分析开始, 软件开发者和用户一起定义软件的总目标, 说明需求, 并规划出定义的区域, 然后快速设计软件中对用户可见部分的表示。快速设计导致了原型的建造, 原型由用户评估, 并进一步求精, 逐步调整原型使之满足用户需求, 这个过程是迭代的。详细过程:第一步, 弄清用户的基本信息需求;第二步, 开发初始原型系统;第三步, 用原型系统完善用户/设计者的需求;第四步, 修改和完善原型系统。
3.2.2 快速原型模型在GIS设计的应用
由于快速原型模型使系统更易维护、用户交互更友好;能得到良好的需求定义, 比传统的生存周期法好很多, 使开发者与用户充分交流, 以改进原先设想的、不尽合理的系统;可降低总体开发费用, 节约开发时间。
快速原型模型比较适合低风险和柔性较大的GIS软件系统的开发。但同时也应注意避免对于开发者不熟悉的领域把次要部分当作主要框架 (模型效应) ;原型的迭代不收敛于开发者预先的目标;它不太适合嵌入式软件、实时控制软件、科技数值计算软件的开发。
3.3 螺旋模型
螺旋模型 (Spriral Model) 是B.Boehm于1988年提出的。螺旋模型将瀑布模型与原型的迭代特征结合起来, 并加入两种模型均忽略了风险分析, 弥补了两者的不足。
3.3.1 螺旋模型的基本原理
螺旋模型可以看做是连接的弯曲了的线性模型。螺旋模型沿着螺线旋转, 在笛卡尔坐标的四个象限上分别表达了四个方面的活动, 即:制定计划, 确定软件目标, 选定实施方案, 弄清项目开发的限制条件;风险分析, 分析所选方案, 考虑如何识别和消除风险;实施工程, 实施软件开发;用户评估, 评价开发工作, 提出修正建议。
3.3.2 螺旋模型在GIS设计的应用
由于螺旋模型是一种风险驱动模型, 为项目管理人员及时调整管理决策提供了方便, 进而可降低开发风险;特别强调原型的可扩充性, 原型的进化贯穿了整个软件生存周期, 这将有助于目标软件的适应能力;原型可看做形式的可执行的需求规格说明书, 易于为用户和开发人员的共同理解。
螺旋模型支持需求不明确, 特别是较高风险的大型GIS软件系统的开发。但同时需要注意要求构造的原型的总体结构、算法、程序、测试方案应具有良好的可扩充性和可修改性;如果每次迭代的效率不高, 会导致迭代次数过多, 将会增加工作量和成本并有可能推迟提交时间;它要求开发队伍水平较高;它是出现较晚的新模型, 不如瀑布模型普及。
3.4 增量模型
增量模型 (Incremental Model) 融合了瀑布模型的基本成分和原型模型的迭代特征, 其实质就是分段的线性模型。
3.4.1 增量模型的基本原理
增量模型采用随着日程时间的进展而交错的线性序列, 每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时, 第一个增量往往是核心的产品, 也就是说第一个增量实现了基本的需求, 但很多补充的特征还没有发布。用户对每一个增量的使用和评估, 都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复, 直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
3.4.2 增量模型在GIS设计的应用
由于增量模型每次增量交付过程都可以总结经验和教训, 有利于后面的改进和进度控制;每个增量交付一个可操作的产品, 便于用户建立好模型做出反应, 易于控制用户需求;任务分配灵活, 将风险分布到几个更小的增量中, 降低了项目失败的风险。
增量模型适合初期的需求不够确定或需求会有变更的GIS软件系统开发。但同时需要注意至始至终需要用户亲密配合, 以免影响下一步进程;要避免把难题往后推, 首先完成的应该是高风险和最重要的部分;要避免退化为边做边改模型, 从而使软件的控制失去整体性;由于一些模块必须在另一个模块之前, 必须定义良好的接口。
3.5 面向对象的软件过程模型
传统的软件开发过程大多建立在软件生存周期概念的基础上, 螺旋模型、原型模型、增量模型等实际上都是从瀑布模型拓展或演变而来的, 通常把它们称为传统的软件过程模型。
面向对象的软件开发过程的重点放在软件生存周期的定义阶段。这是因为面向对象方法在开发早期就定义了一系列面向问题域的对象, 建立了对象模型。整个开发过程统一使用这些对象, 并不断地充实和扩展对象模型。
3.5.1 构件复用模型
面向对象技术将事物实体封装成包含数据和数据处理方法的对象, 并抽象为类。构件 (component, 也译为组件) 是软件系统中有价值的、几乎独立的并可替换的一个部分, 它在良好的定义体系结构语境内满足某项清晰的服务功能, 可以通过其他接口访问他的服务。经过适当的设计和实现的类也可以成为构件, 在基于构件的软件开发中, 软件由构件装配而成。
构件复用模型如图1-1所示, 它融合了螺旋模型的特征, 本质上是演化的, 并且支持软件开发的迭代方法, 它是利用预先包装好的软件构件的复用为驱动构造来应用程序。首先标识候选类, 通过检查应用程序操纵的数据及实现算法, 并将相关的算法和数据封装成一个类。把以往软件工程项目中创建的类存于一个类库或仓库中, 根具标识的类, 就可搜索该类库。如果该类存在, 就从类库中提取出来复用。如果该类不存在, 就采用面向对象方法开发它。以后就可以使用从库中提取的类及为了满足应用程序的特定要求而建造的新类。进而完成待开发应用程序的第一次迭代。过程流程后又回到螺旋, 最后进入构件组装迭代。
统一过程模型 (Rational Unifi ed Process, RUP) 具有较高知名度的原因之一恐怕是因为其提出者Rational软件公司聚集了面向对象领域三位杰出专家Booch、Rumbaugh和Jacobson, 同时它又是面向对象开发的行业标准语言——标准建模语言 (Unifi ed Modeling Language, UML) 的创立者, 是目前最有效的软件开发过程模型。
3.5.2. 1 统一过程模型的基本原理
统一过程首先建立了整个项目的不同阶段, 包括初始阶段、细化阶段、构造阶段、交付阶段。同时每个阶段中又保留了瀑布模型的活动, 这里称为工作流, 即从需求、分析到设计和实现、测试等活动。所以, 可以将其理解为一个二维坐标, 工作流是一个竖坐标, 阶段构成了横坐标。但是, 二维坐标不是统一过程的主要思想, 它的主要思想是每个竖坐标表示的活动可能会产生多次迭代, 每个迭代会随着横坐标 (阶段) 的进展而产生变更, 最终逐渐减少甚至消失, 如图1-2所示。四个阶段, 九个核心工作流, 十大要素。
3.5.2. 2 统一过程模型开发过程各个阶段的里程碑
RUP中软件生命周期在时间上被分解为四个顺序阶段, 每个阶段结束于一个主要里程碑。初始阶段结束时是第一个重要里程碑:生命周期目标里程碑。主要成果有:项目蓝图文档、初始的用例模型、初始的项目术语表、业务用例模型。细化阶段结束时是第二个重要的里程碑:生命周期结构里程碑。主要成果有:系统架构基线、UML静态模型、UML动态模型、UML用列模型、修订的风险评估、修订的用例、修订的项目计划、可执行的原型。构造阶段结束时是第三个重要的里程碑:初始功能里程碑。主要成果有:可运行的软件系统、UML模型、测试用例、用户手册、发布描述。在交付阶段的终点是第四个里程碑:产品发布里程碑。主要成果有:可运行的软件产品、用户手册、用户支持计划。
RUP十大要素包括:开发前景;项目计划;标识和减小风险;分配和跟踪任务;检查商业理由;设计组件构架;对产品进行增量式的构建和测试;验证和评价结果;管理和控制变化;提供用户支持。
3.5.2. 3 统一过程模型在GIS设计的应用
由于RUP中的每个阶段可以进一步分解为一次迭代。与瀑布模型比较, 统一软件过程模型具有降低了在一个增量上的开支风险;加快了整个开发工作的进度;迭代过程的这种模式使适应需求的变化更容易;它的迭代模型建立了简洁和清晰的过程结构, 为开发过程提供较大的通用性。
统一软件过程模型非常适合GIS软件系统的开发。但是我们需注意的是RUP只是一个开放过程, 并没有涵盖软件过程的全部内容, 例如它缺少关于软件运行和支持等方面的内容;没有支持多项目开发结构, 这在一定程度上降低了在开放组织内大范围实现重用的可能。
3.6 敏捷开发过程
“敏捷”一词意味着快速、简单、灵活。敏捷开发过程强调以人为本, 注重编程中人的自我特长发挥。强调软件开发的主体是程序, 文档是为软件开发服务的, 不是开发的主体。敏捷开发特别重视客户参与开发, 因为开发者不是客户业务的专家, 所以一定要客户来阐述实际的需求细节。编制周密的计划是为了最终软件的质量, 但是为了要适应客户需求的不断变化, 计划和设计要不断调整。
敏捷就是“快”, 要快就要充分发挥每个人的个性思维, 个性思维的增多会造成软件开发规范性、一致性和可复用性的下降, 因此把敏捷开发与传统的“瀑布式”开发有机地结合。支持敏捷开发过程的极限编程就是强调交流、简单、反馈和勇气。另外并不是所有的GIS软件项目都适合敏捷开发, 例如, 难以分解的大型GIS应用软件、需要分布式开发的应用GIS软件等不适合敏捷开发。
4 GIS设计的未来展望
至上世纪90年代GIS进入产业化的阶段发展以来, GIS已经是一个全球拥有超过十万开发人员和数十亿美元的产业。世界各国已经设计出大量实用化的地理信息系统, 常见的GIS软件已经超过400种。当今国内外GIS的重要发展趋势是将地理信息系统融入国家信息化和知识经济的主体, 为资源环境问题的研究提供高技术手段, 形成新的经济增长点, 提高国家的安全能力。为此在未来仍需要大力发展业务化的GIS运行系统, 提高GIS的应用水平和效益。
由于GIS软件不同于一般程序, 它的一个显著特点是规模庞大, 而且程序复杂性将随着程序规模的增加呈指数上升。因此现有的计算机软件工程方法也不完全的适用于GIS设计, 未来还需要工程师和系统分析人员在GIS项目工程实施过程中进行研究与探索, 努力发展适用的GIS软件开发方法。
摘要：GIS从20世纪60年代问世以来已经经沥了近60个春秋的飞速发展。但随着GIS软件数量的飞速增长和软件规模的扩大, GIS软件危机情况已日益严重, GIS设计也将面临更大的挑战。笔者结合软件工程学的理论和思想, 通过合理的选用软件过程模型来为GIS设计提供思路。
关键词：软件工程,GIS工程学,GIS设计,软件过程模型
参考文献
[1]李满春, 任建武, 陈刚, 周炎坤.GIS设计与实现[M].北京:科学出版社, 2006.
[2]李伟波, 刘永祥, 王庆春.软件工程[M].武昌:武汉大学出版社, 2010.
[3]刘光, 刘小东.地理信息系统二次开发实例教程[M].北京:科学出版社, 2004.
[4]吴洁明, 方英兰.软件工程实例教程[M].北京:清华大学出版社, 2010.
[5]俎晓芳.浅析统一软件开发过程与GIS软件开发[J].内江科技, 2006, 27 (6) :103-104.
[6]郭建文, 冯敏, 李新.统一软件过程与地理信息系统的应用开发[J].遥感技术与应用, 2003, 18 (6) 422-428.
软件过程工程实验题目 篇5
(注1：以下各题目除特殊标注外，完成时均不得超过2人为一组。注2：各组题目不得相同)
题目一：《教务管理系统之子系统----系内课程安排》
1、系统简介
每学期的期中，学院教务处分别向各系发出下学期的教学计划，包括：课程名、课程类别、课时、班级类别(本科、专科、高职)、班号等；系教学主管人员根据教学任务和要求给出各门课程的相关限制(如：任课教师职称、合班数、最高周学时数等)；任课教师自报本人授课计划，经所在教研室协调确认，将教学计划上交系主管教学的主任，批准后上报学院教务处，最终由教务处给出下学期全系教师的教学任务书。
假设上述排课过程全部为人工操作，现在要求改造为能利用计算机实现的自动处理过程。
2、技术要求及限定条件
(1)每位教师的主讲门数不得超过2门/学期；讲师以下职称的教师不能承担系定主课的主讲任务。
(2)系级干部的主讲课时不能超过4学时/周。
(3)本学期出现严重教学事故的教师不能承担下学期的主讲任务。(4)本系统的输入项至少应包含3个：教务处布置的教学计划、系教师自报的讲课计划和系定的有关讲课限制条件。(5)本系统的输出项至少应包含2个：教务处最终下达的全系教师教学任务书和系各教学班一学期的课程表(可不包含上课地点)。
题目二： 《学校教材订购系统》
1、系统简介
本系统可细化为二个子系统：销售系统和采购系统。
销售系统的主要工作过程为：首先由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、登记并返给教师或学生领书单，教师和学生即可去书库领书。
采购系统的主要工作过程为：若是脱销教材，则登记缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
以上系统的功能要求在计算机上实现。
2、技术要求及限定条件
1（1）当书库中的各种书籍数量发生变化(包括领书或进书)时，都应修改 相关的书库记录，如库存表或进/出库表。
(2)在实现上述销售和采购的工作过程时，需考虑有关单据的合法性验证（如：购书单、领书单等的有效性）。
(3)系统的外部项(Terminator)至少包含3个：教师、学生和教材工作人员。(4)系统的相关数据存储项(Data store)至少包含6个：购书表、库存表、缺书登记表、待购教材表、进/出库表
题目三：《影碟店管理系统》
1、系统简介
一个新的影碟店就要开张了，但它还没有一个用来管理影碟和顾客的系统，该店经理希望开发一套系统来实现该店的自动化管理，这个系统要求实现以下的功能：
(1)出租影碟
(2)收回或登记影碟
(3)创建该店所拥有的影碟的目录(4)显示某个影碟的详细信息(5)打印店中所有影碟的目录(6)检查某个影碟是否在店中(7)维护客户信息
(8)打印每个客户租借的影碟的目录
2、技术要求和限定条件
(1)影碟店有两个对象：影碟和顾客
影碟对象（电影的名字、主角的名字、制片人的名字、导演的名字、制片公司的名字、店中拷贝的数目等）。
顾客对象（顾客的姓名、顾客的账号、所租借的影碟的清单等）。(2)运用面向对象的设计方法（继承、重载）来进行系统设计。
题目四：《学校内部房产管理系统》
1、系统简介
该房产管理系统具有分房、调房、退房和咨询统计等功能。房产科把用户申请表输入系统后，系统首先检查申请表的合法性，对不合法的申请表系统将拒绝接受；对合法的申请表将根据类型分别进行处理。
如果是分房申请，则根据申请者的情况（年龄、工龄、职称、职务、家庭人口等）计算其分数，当分数高于阈值分数时，按分数高低将申请表插到分房队列的适当位置。每月最后一天进行一次分房活动，从空房文件中读出空房信息，如房号、面积、等级、单位面积房租等，把好房优先分配给排在分房队列前面的符合该等级住房条件的申请者，从空房文件中删除这个房号的信息，从分房队列中删掉该申请表，并把此房号的信息和住户信息一起写到住房文件中，输出住房分配单给住户，2 同时计算房租并将算出的房租写到房租文件中。
如果是退房申请，则从住房文件和房租文件中删掉有关的信息，再把此房号的信息写到空房文件中。
如果是调房申请，则根据申请者的情况确定其住房等级，然后在空房文件中查找属于该等级的空房，退掉原住房，再进行与分房类似的处理。
住户可以向系统询问目前分房的阈值分数、居住某类房屋的条件、某房号的单位面积和房租等信息。房产科可以要求系统打印出住房情况的统计表，或更改某类房屋的居住条件、单位面积和房租等。
2、技术要求及限定条件
(1)本系统可分为4个主要功能模块：分房、调房、退房和咨询(可不考虑统计功能)。
（2）系统的外部项(Terminator)至少包含4个：校内职工、校外住户、房管部门和主管房产领导。
（3）分房申请表的类型主要依据申请人的工作类型，如：教师、行政人员、后勤人员、特殊照顾对象等。
（4）分房申请者的分数计算原则及其他分房政策可由学生自定。
题目五：《学校内部工资管理系统》
1、系统简介
假设学校共有教职工约1000人，十个行政职能部门和八个系、部。每个月20日前各部门(包括各系、部)要将出勤情况表上报人事处，23日前人事处将人员出勤工资、奖金及扣款清单送财务处。财务处于每月月底将教职工的工资表做好并将数据送银行。每月初(3日前)将工资条发给各单位。若有员工调入、调出、校内调动、离退休等数据变化，则由人事处通知相关部门和财务处。
2、技术要求及限定条件
(1)本系统的数据存储至少应包含：工资表、工作总表、部门汇总表、扣税款表、银行发放表。
(2)除人事处、财务处外，其他职能部门和系、部名称可简化，如：系
1、系2......(3)工资、奖金及扣款细节可由学生自定。
题目六： 《学校校园网络管理信息系统》(注：本题目可以由3－4个学生构成一组来完成，每个学生重点考虑其中1－2个子系统的功能。承担本题目的学生在需求分析前应对学校各有关部门进行实际调研。)
1、系统简介
假设目前我校已完成校园网络硬件结构的设计和实现(总体结构采用网络拓扑结构和Client/Server模式)，各办公职能部门都已具备使用校园网的硬件环境。本管理信息系统应由各部门的子系统组成(如：校长/书记办公系统、教务管理系统、3 财务管理系统、人事管理系统、图书管理系统、学生管理系统等)，应能满足校内各部门在数据、文件、资料等公用信息传输的要求；各层领导能通过网络查询各部门的工作情况并传达有关指示；实现“无纸化”办公和全校数据共享。此外，各层领导、各系教师、各职能办公室都可以通过E－mail发信、留言；有关部门可在“公告牌”上发布消息，供大家浏览。
2、技术要求及限定条件
(1)系统的外部项(Terminator)至少应包含12个，如：校长/书记、校办、系办(至少考虑3个系)、教务处、财务处、人事处、图书馆、学生处等。(2)对于每个外部项，都应根据其不同的需要确定相关的功能需求，即根据外部项来划分相应的子系统功能(可认为不同”系办“的功能相同)。
(3)在确定各子系统功能时，要注意数据的保密性和相关用户的不同级别。
题目七： 《实验室设备管理系统》
1、系统简介
每学年要对实验室设备使用情况进行统计、更新，其中：(1)对于已彻底损坏的作报废处理，同时详细记录有关信息。
(2)对于有严重问题（故障）的要及时修理，并记录修理日期、设备名、修理厂家、修理费、责任人等信息。
(3)对于急需但又缺少的设备需以“申报表”的形式送交上级领导请求批准购买，新设备购入后，要立即进行设备登记（包括类别、设备名、型号、规格、单价、数量、购置日期、生产厂家，购买人），同时更新申报表的内容。
(4)随时对现有设备及其修理、报废情况进行统计、查询，要求能够按类别和时间段（某日期之前）查询。
2、技术要求及限定条件
(1)所有工作由专门的人员负责完成，其他人不得任意使用。
(2)每件新设备在做入库记录时均由系统根据类别自动顺序编号，形成设备号；设备报废要及时修改相关的设备记录且有领导认可。
(3)本系统的数据存储至少应包含：设备记录、修理记录、报废记录、购买申请。
(4)本系统的输入项至少包含：新设备信息、修理信息、申请购买信息、报废信息、具体查询统计要求。
(5)本系统的输出项至少包含：设备购买申请表、修理/报废注销/设备资金统计表。
题目八：《医院患者监护管理系统》
1、系统简介
某医院目前住院病人的监护工作主要由护士人工负责，这样做不仅需要大量护士，而且由于不能随时观察危重病人的病情变化，还会延误抢救时机。因此，该医 4 院计划开发一个以计算机为中心的患者监护管理系统。
2、技术要求及限定条件
（1）该系统应随时接收每个病人的生理信号（如：脉搏、体温、血压、心电图等），定时记录病人情况以构成患者日志。
（2）当某个病人的生理信号超出医生规定的安全范围时，该系统应向护士发出警告信息。
（3）护士根据需要可以随时要求本系统输出某个指定病人的病情报告。
题目九：《校园办公自动化系统—公文管理子系统》
1、系统概述
学校的各个部门在日常办公中经常会起草一些公文，需要上级主管部门领导（如：主管院长、校长等）批示，目前这些公文的管理、传递主要通过人工完成。为实现无纸化办公，特构建公文管理子系统。公文管理子系统主要分为两部分：发文管理和收文管理。发文管理用于处理本学校各个部门的党、政文件，各个部门向上级主管部门报送的请示、报告，相关联单位复函，发本校各单位文件材料；执行发文拟稿、核稿、会签、签发等管理工作，并提供了电子邮递、打印等功能。收文管理实现对校外单位的来文的登记、下发等操作。
2、技术要求及限定条件
(1)员工提出发文申请，填写发文稿纸。正文内容若有表格，则以附件的形式挂在发文稿纸上。在提交审批前，员工可对自己录入的内容进行修改、删除。员工将发文稿纸提交部门领导审批，对提交审批后的公文不能进行删除。员工可以对自己提交的公文进行当前状态的查询，包括所有经办人的办理意见汇总、该计划已经办的步骤、当前正在办理的步骤与下一步应该办理的步骤。
(2)部门领导对员工提交的发文可以进行流转、修改、退回。部门领导对本单位的发文进行审核，如果审核通过，将审核意见填入后将发文提交给秘书流转；如果审核未通过，填入审核意见后将发文退回到员工进行修改。部门领导可以对本单位的公文进行当前状态的查询，包括所有经办人的办理意见汇总、该计划已经办的步骤、当前正在办理的步骤与下一步应该办理的步骤。
(3)秘书可以对收到的发文稿纸进行流转、修改、退回。负责把发文单发送给上级主管领导审核，并负责接收。若上级主管领导不在由文书代替主任指定会签领导和签发领导。若上级主管领导不在，由秘书代替上级主管领导填写审核意见。负责把发文单发送给会签领导和签发领导。负责接收会签意见和签发意见。签发完毕后由秘书书填写缓急、密级、字号等。并把发文交由打字员打印。(4)必须给每个用户分配账号、口令、角色、权限。(5)要求实现活的流程的定义。
题目十：《销售数据分析系统》
1、系统简介
某公司有一批销售人员，这些销售人员每个月都出去销售该公司的产品。销售数据分析系统主要完成以下功能：公司能登记每个销售人员的基本信息；在每个月的月末，要将每个销售人员的销售额、销售人员ID、月份等信息记录 在文件或数据库中；在年终销售经理能看到全公司所有销售人员的销售业绩报告（要求做出曲线图以便比较分析）；能够记录、删除、查询每个销售人员的基本情况；能够按月份、月份、销售人员姓名、销售业绩等条件分类或组合查询销售情况。
2、技术要求及限定条件
(1)销售系统由系统管理人员维护、销售人员只能查询自己的销售情况，销售人员主管能查询所有销售人员的基本情况以及销售情况。(2)注意数据的一致性、完整性。
(3)离职的销售人员相关信息进入公司历史记录，并不从系统中彻底删除。(4)能够实现销售数据的定期备份。
★实验设备与环境
浅谈软件过程的改进 篇6
关键词：软件工程；SEI能力成熟模型
中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)12-21705-01
Discuss the Improvement of the Software Course Simply
WANG Wen-li
(Guangdong Lingnan Institute of Technology,Guangzhou 510663,China)
Abstract:Improvement of soft project in a problem land that is explored constantly soft project researcher in whole world. First of description of this text are organized unripely and a ripe difference while organizing, key definition and describe SEI ability ripe 5 ripe grade of model, propose one common system improvement model to develop course.
Key words:Soft project;Ripe model of SEI ability
1 引言
信息系統生命期(SDLC)由活动、产品和资源组成。活动是在一个SDLC中进行的动作，并且可以是高层分析至程序的编译或者测试之类的任何工作。产品是在SDLC期间产生的文档和程序。资源由人员、时间、金钱和设备等组成。在一个SDLC期间要使用它们，SDLC在某些文献以及讨论开发的研究中也看成是一个软件的过程。
全世界的软件工程研究人员都致力于改进软件过程。SEI（Software Engineering Institute）的能力成熟模型是一种软件过程改进的途径。本文基于这一框架来讨论软件过程的改进。在世界范围内有许多其他实践着的软件过程改进。本文选择这一途径进行讨论，是因为大量的出版物上有有关的文章、讨论及批评，并且在美国和许多其他地区普遍接受了它。在1986年，CMU软件工程研究所（SEI）在Mitre公司的帮助下，开始发展一种有助于开发人员改进他们的开发过程的系统开发过程成熟度框架。最初称为软件过程成熟度模型。
2 不成熟和成熟的系统开发组织
一个组织希望建立起改进信息系统开发过程的实用的目标时，首先必须理解不成熟系统开发组织和成熟的系统开发组织之间的差异。在一个不成熟的系统开发组织中，通常开发人员即兴提出系统开发过程。即使详细说明了一个特定的开发过程，也很少会坚持或强化这一开发过程。
描述不成熟系统开发组织的最好词语是“反应”。通常管理人员关注解决危机和“救火”上。经常性地超支，因为从来没有真正地估计过进度和预算。当人为的期限迫近时，软件产品功能、性能和质量往往受损。
最后，一个不成熟系统开发组织缺乏有目的的办法来评估软件产品质量、或解决发生的产品问题或过程问题。为保持或接近进度，经常减少取消试图提高软件产品质量的活动，例如用户介入，设计评审和测试。
成熟的系统开发组织可能在全机构范围内管理系统的开发和维护。管理人员可以准确地把系统开发过程传达给开发人员，开发人员根据计划的过程实施相应的活动。规定的开发过程是可用的，并和进行工作的实际途径相一致。通过受控的试验性测试和效益分析，确定必须改进过程时，就更新规定的开发过程。在项目范围内和贯通组织范围中都理解开发人员的作用和责任。
成熟系统开发组织的管理人员不断地监视系统产品的质量个制造产品的过程。坚持一个目标明确的、定量的方法来评估系统产品质量和分析产品的问题和过程的问题。基于历史上的行为制定进度和预算，因此是现实的，通常可以达到。
最后，一个成熟的系统开发组织使用一个纪律严明的系统开发过程，因为全体参与人员理解如此做的价值，企业的基础结构设施支持他们达到这一点。
过程改进（例如SEI的CMM）的目的是支持软件开发管理人员，开发人员和业务工作。而不是去责备和羞辱他们。软件过程改进的组织软件开发组织的管理人员之所以失败，常常就是因为害怕承认了软件开发过程真实情况所带来的后果。
3 SEI能力成熟模型的5个成熟阶段
一个系统开发过程是开发人员用来开发和维持信息系统的活动、方法、实践和变换的集合。如果一个软件的开发组织是成熟的，在其组织内具有较好的定义，并一贯地使用于开发过程。通过政策、标准和组织结构体现的系统开发过程是这种成熟性的自然产物。不要将成熟度和多年处于的状态等同。对于现在的讨论中，把成熟度等同于智慧的成熟和在应用知识上的智慧。所以一个软件开发组织成熟就相当于该组织能把通常认可的有关软件开发过程的知识应用于自己的软件开发工作中。
坚持连续地改进过程的思想，CMM为软件为软件组织的演进步伐提供有五个成熟度的框架，如图1所示。当软件组织达到一个成熟度级的框架时，每一个成熟度级为连续的过程改进中转向下一个成熟级打下基础。每一级都假定软件组织已经达到了在CMM指南规定的所有较低级别的要求。图2总结由CMM描述的关键过程区域。
图1 SEI能力成熟模型 图2 在能力成熟模型中的关键过程区域
第1级，初始级软件组织的一般特征是没有开发和维持系统的稳定的环境。这种组织极少能做到使软件开发按一个有序的开发过程进行。结果是发生一系列开发危机，一遇到问题，开发组成员放弃计划好的过程，并回到反复编码和测试。
第2级，可重复级软件组织的一般特征是有食用的政策和过程，并在系统开发中坚持使用。新项目的计划和承诺是基于相似的项目的经验。基本的管理控制是属于每个开发项目的一部分，管理人员跟踪费用、进度和识别问题。
用户需求和开发出来满足要求的工作产品是按基线进行，并控制其完整性，项目遵循标准；然而在第2级的组织中项目之间的过程可能不同。因为可以重复过去的成功经验，所以其项目计划和控制是稳定的。这些组织的过程能力是有规律的。
第3级，定义级按软件组织在相继项目上的稳定性和可重复性，所代表的全组织的标准和一致的系统开发过程来标志。这个过程的编写成文档，包括一个开发人员的过程部件和一个管理过程的部件。由于标准化，组织作为一个整体应当能够进行有效的系统开发时间。
因为在这一级的开发组织有一个很好的定义过程，管理人员对每个项目的技术过程有良好的洞察力。除此以外，在组织的标准化系统开发过程中包括了以下各方面的指南：(1)标准；(2)建立可读性准则；(3)开发输入；(4)完成工作的步骤；(5)工作验证步骤，例如同事评估；(6)开发输出；(7)决定完成准则。
第4级，管理级是建立了系统开发产品和系统开发过程的定量质量目标的几个为特征的组织，对于遍及所有项目的重要的系统开发过程都度量生产率和质量作为自制的度量程序的一部分。
整个组织维护一个过程数据库以收集和分析来自各项目确定过程的数据，这些组织的范围的度量建立了一个定量的基础，用于评估任一项目的过程和产品。每个项目通过在他们行为中减少与组织的可接受数量界限的差别来控制他们的过程和产品。在一个项目过程实施中有实质性的变动和随机变动加以区别，当已知的过程界限超出后，管理可以采取行动来纠正这种情况。第4级允许一个组织在确定的定量范围内对系统开发过程和产品质量具有预测趋势的能力。
第5级，优化级通过整个系统开发组织致力于连续的过程改进为标志。组织有适当的途径识别开发过程弱点和产品弱点，并用零缺陷目标化它们。过程数据库（来自第4级）用来对新技术和系统开发过程的变动进行费用—利益分析。探索最佳系统开发实践的革新在整个组织内部识别并传播。
项目小组分析缺陷以决定原因，对过程进行评估以避免已知类型的错误重现，并传播其他项目的经验。因为系统开发中低效益的主要原因是重复工作，所以减少重复工作可以说是每一级的目标。但是在第5级，它成为一个主要的关注点。
4 一个基本的系统开发过程改进模型
通过遵循这个简单的系统开发过程改进模型——ICASE，一个系统开发组织可以来达到其希望提高CMM的级别的目的。
I=调查，调查组织的系统开发过程的现有状态。在我们可以确定移向下一个级别之前，我们需要知道我们处于哪里。
C=建立，在组织内部建立一种意想。使开发人员和管理人员进入改进系统开发过程的概念中去。
A=行動，在组织中对必须要求的过程改进行动建立一张清单。
S=选择，选择一个计划以达到要求的行动。
E=执行，提交执行计划必须的资源。
最后，当开始并不断在CMM级进行改进时，反复这一过程。
5 小结
本文给出了对软件过程改进的概述。由于许多因素使软件创建的过程需要不断的改进。软件过程改进就是试图这样做的活动。按SEI能力成熟模型——给出软件开发成熟度的五个级别，给出了不成熟和成熟软件开发环境。在这之后，一个一般的系统开发过程改进模型，用ICASE缩写表示。本文简短地讨论ISO 9000过程改进标准作为结束。
如前所述，SEI的CMM不是仅有的系统开发度量模型。还有ISO 9000系列标准，以及可以通过全世界的咨询组织获得几个专利的方案。然而，CMM可能是所有系统开发度量模型当中编写最流行的文档方法。
参考文献：
[1]国刚.UML与Rational Rose 2003软件工程统一建模原理与实践教程[M].电子工业出版社,2006.
[2]符长青.信息系统工程监理[M].机械工业出版社,2006.
[3]周爱民.大道至简——软件工程实践者的思想[M].电子工业出版社,2007.
[4]赵池龙.软件工程实践教程[M].电子工业出版社,2005.
软件过程模型 篇7
软件公司采用同样的方式开发软件，通过软件配件的方式使他们在市场上取得了成功，软件配件是通过包的形式同软件一同发售的。软件配件被叫做组件或构件，很多学者从不同的角度给出了定义。一般认为可重用的二进制代码即为组件，组件观念和面向对象编程的对象思想很相似。一个组件是为了服务特定用途，具有独立功能的系统部件，比如：命令按钮，文本输入框等。组件就像模式一样强制开发人员采用已定义好的过程，将其插入到新软件系统中以满足的需求。
微软公司和SUN公司是主要的软件工具提供商，他们的工具被广泛用于应用软件开发。这两家公司和其他厂商也提供大量的组件使他们取得了成功。他们提出一个CBD过程模型，并且详细描述仓储在CBD中的重要性，让人们清晰地感受到CBD相比传统软件开发的优越性。
1 CBD过程模型研究现状
Bailey and Basili为组件重用和重设计提出了软件生命周期模型，模型提出的组件重用的五个策略：
1)分析现有程序，对可重用组件排序。
2)重新设计，消除特定领域的问题。
3)将可重用组件保存在仓库中。
4)以重用的方式构建独立状态组件并保存在仓库中。
5)利用组件开发新系统。
该模型还不是CBD的完整模型，但他的核心关注点在重用活动上。粗略的收集需求可能一个项目最终失败，这是由于需求的自然缺陷决定的。作者提出了构建软件的方法—基于知识的组件分类。通过知识将现有的组件表示、选择和整合到新的系统中。对重用工件的不同分类也有论述。这些是枚举，关键字，面和超文本，这边论文的目的是缓解基于知识的需求收集，但未提出全面的基于CBD的过程模型。
Eduardo Santana de Almeida等人提出了分布式CBD的渐进方法。这种方法基于两个阶段，第一阶段是组合问题域的需求并用面向对象的语言设计可用的组件，这些组件保存在仓库中，第二阶段是设计师根据需求从仓库中选择适当的组件来构建软件。作者没有提出一个足够清晰的过程模型，而且也需要特殊的工具支持。
Luiz Fernando Capretz等人提出了一种软件生命周期可用于面向对象的CBD构建。他主要的阶段是领域工程、系统分析、设计和实现。这个模型的主要问题是在设计阶段选择可重用组件，正常应该在分析阶段，进而分析师能够评估成本、时间安排、要求开发成果以及组件整合。
Hutchinson等人提出了四阶段的基于组件的开发过程模型。这是非常复杂的模型。核心的观念就是整合现有的和新开发的组件，而不是内部开发，仓库的概念没这篇文章没有体现。
Ning[11]的CBD过程模型包括的主要阶段是组件分析、架构设计、组件链接、组件生产和组件整合，作者修改了瀑布模型并这和了上面提到的阶段作为新的CBD过程模型。瀑布模型不适合商业应用，因为他重复的审核阶段。时间和成本消耗过程模型只适合研究项目。表1是对以上几个CBD过程模型的比较。
2基于CBD的过程模型
面向对象的过程模型是唯一能够表示对现有组件重用的过程模型，对象过程模型经过修改可以实现基于组件开发的重用。软件设计，构建和测试阶段体现了现有类的重用。本文提出的CBD过程模型的主要阶段有沟通、计划、分析与选择、可发与测试、评估，如图1。
项目开始通过与客户沟通获得基本的需求。初级用例在这个阶段开发出来。项目规格或提案文件在计划阶段完成。项目规格或提案文件包括可行性分析和风险评估，并提供成本效益分析(CBA)表。CBA表用于分析项目是否对客户可行。如果客户同意提案分析阶段才能开始。面向对象的过程模型能够依据CBD过程模型进行修改，所以新的分析阶段命名为分析与组件选择。这个阶段分析师收集详细需求并尝试定位和选择可重用组件，这里引入了组件仓库的概念，这些组件的之间的关系是确定的，而且组件的属性和行为也已经定义好，这个阶段需要最大化的重用组件，而不需要重复发明轮子。他将提高软件工程师的生产力和效率。基于面向对象模型的开发与测试阶段满足CBD过程模型的要求。被选择的组件依据新系统的需求进行修改和测试。对于新的组件要进行设计、开发和单元测试。对新开发的和重复使用的组件进行集成和系统测试。如果编程人员正在使用基于CORBA或RMI的架构，接口定义语言(IDL)可用于编码集成组件。面向对象的过程模型满足CBD过程模型的需要。客户需要评估和验证软件是否满足他们的实际需要。
3 仓库的角色和重要性
基于可重用组件的软件开发可以提高效率，仓库用于可重用组件的存储和管理，他的组要好处：分类、搜索、修改、测试、实施、版本控制、变更控制、最新和一致的文档。我们可以从多维仓库(一个或多个仓库组成)中选择和管理组件，多维仓库的好处在于基于领域的开发和分类。
4 CBD过程模型的优越性
基于组件开发的优点：可重用性、互操作性、可升级性、低复杂性、时间效益、成本效益、开发效率、可靠性、高质量。可重用性是基于CBD开发的重要特性，用ASP开发一个基于WEB的Email系统就是一个CBD应用的例子。协作数据对象的Windows NT服务器(CDONTS)是微软开发的邮件系统，这个组件能够用来开发类似的应用系统。一个特定工具的内嵌组件也放映了从用的好处，如微软VB的6.0文本框和命令按钮对象等，这些组件可以被频繁的使用，这就是VB6.0成为快速开发工具的原因。我们把经理花在业务开发实现上而不是基本的组件上。
CBD架构允许组件之间通信，使组件之间有互操作性，便于开发人员将系统整合到其他应用系统，不同银行ATM机上信息系统互联就是一个很好的例子。如果组件需要升级，对于WEB应用系统来说是很容易的，只需要用新组件替换原有组件而不需要更改应用系统。C/S架构用来开发分布式应用系统。这里有三中类型的C/S架构：1)将表示层，业务逻辑层和数据层封装在一起的应用系统比如微软的EXCEL和Access软件等。2)两层架构前端整合了表示层和业务逻辑层，后端是数据存储层，可以是Oracle SQLServer等。3)表示层，业务逻辑层和数据存储层作为独立的层次，即是三层架构或多层架构，前端我们可用JSP,Servlet表示，业务逻辑可以用EJB,DCOM等描述，后端可以用数据库或一般文件系统表示。
三层架构是目前用的最广的用于开发商业软件。商业逻辑随着商业环境的变化，很容易改变，这样只需要改变EJB或DCOM组件即可，而不需要太多改动表示层和数据持久层的代码。
CBD的一个优点就是不需要程序员关系组件内部是怎么工作的。他们只需要关系组件的接口以及怎样和他们的系统整合在一起。这就像一个司机一样，他不需要知道轿车的发动机是怎么运行的。对于程序员他们只要关注应用软件的业务逻辑而不去关系基本的组件，如文本框和按钮组件的实现。CBD是程序员从复杂的编程中脱离出来。他们可以是可重用的组件在类似的系统中频繁的应用，提高了开发效率，降低了开发成本，当然也使设计过程更有效率。可重用的组件第一次被使用后，彻底的被测试和维护，因此，可重用的组件相比新开发的组件更可靠更稳定，同时软件的质量也有一定程度的提高。可重用的组件得到了很好的测试和维护。新开发的组件需要大量的开发和维护，大量的缺陷没有被发现，软件质量受影响就是这个原因。
大量的案例也正名了基于CBD开发的重要性。Lim[12]表述，重用组件的项目总储蓄额冲410万美元增长到了560万美元，同时投资回报率也冲216%曾长到了410%。据他论述，重用代码的缺陷率是0.9每千行代码，而新开发的代码的缺陷率是4.1每千行代码，他通过两个项目的比较，一个项目是基于CBD开发，一个不是，基与CBD开发的系统时间只是没有基于CBD开发时间的51%。35%的软件质量得到了改善。
5 结束语
本文通过与传统软件开发的对比叙述了基于CBD的软件开发过程模型，并提出了一基于CBD的软件过程模型，同时讨论了仓库在CBD开发中的应用。通过以上的论述可以看出基于CBD开发的软件更具成本效益、节约时间和提高生产效率。一个可工作的原型系统将支持基于CBD的模型的。
参考文献
[1]冯冲,江贺,冯静芳.软件体系结构理论与实践[M].北京:人民邮电出版社,2004.
[2]Shaw M.Making Choices:A comparison of styles forsoftware architecture[J].IEEE Software,special issue onsoftware architecture,1995.
[3]覃征,何坚.软件体系结构[M].西安:西安交通大学出版社,2004.
软件过程模型 篇8
本文根据以往软件开发管理成功项目, 基于约束理论 (Theory of Constraints, 简称TOC) , 来分析软件开发项目管理过程中的风险管理和质量管理过程, 探究软件开发项目管理过程中的风险和质量管理有效方法, 并提出相应的风险和质量管理过程控制模型, 以供软件开发项目管理实践参考。
1 文献回顾
为了探究软件项目开发成功率不高的原因, 并提出相应的解决方案, 一些学者展开了相应的研究。有的学者从质量管理角度, 研究了一些质量管理方法和管理工具对项目管理的影响, 如全面质量管理的采用研究[5,6]、质量管理工具的采用和效果研究[7]、六西格玛质量管理方法的研究[8]等, 并对质量管理方法和实践进行了调研和实证研究, 提出了相应的项目管理质量改进建议, 对项目管理的成功保障提供了必要的理论和实践参考。有学者从风险控制和管理角度, 基于理论和实践, 进行了多方面的研究, 如识别影响项目成功的IT项目风险因素并提出避免和/或减轻风险的相关建议[1]、从风险管理过程 (如风险识别、风险分析、风险处理) 提出相应的分析控制模型[9]、从案例实证研究风险管理对于项目成功率的影响关系[10]等。由此可见, 软件项目开发过程, 风险管理和质量管理非常重要, 它贯穿于项目管理的整个过程, 多数项目管理过程和要素, 都可以纳入到风险管理和质量管理过程中, 任何一个管理过程, 无不蕴含着风险和质量问题, 它们中的任何一个过程出了问题, 都会对整个项目带来风险因素和质量问题。风险管理和质量管理是相辅相成的两个管理过程, 风险管理做不好, 如风险识别不清、不能进行有效分析和控制, 就会对项目质量带来隐患, 而项目质量控制不好, 如不能贯彻质量保证规范、质量过程管理松懈等, 也会给项目管理带来极大风险, 从而导致项目返工、成本上升和进度延误。因此, 软件项目的开发过程中, 项目风险管理和质量管理尤其重要。
约束理论 (Theory of Constraints, 简称TOC) [11]是以色列物理学家、企业管理顾问高德拉特博士 (Dr.Eliyahu M.Goldratt) 在他开创的优化生产技术 (Optimized Production Technology, OPT) 基础上发展起来的管理哲理, 该理论提出了在制造业经营生产活动中定义和消除制约因素的一些规范化方法, 以支持持续改进 (Continuous Improvement) 。高德拉特创立约束理论的目的是想找出各种条件下生产的内在规律, 寻求一种分析经营生产问题的科学逻辑思维方式和解决问题的有效方法, 即找出妨碍实现系统目标的约束条件, 并对它进行消除的系统改善方法。鼓-缓冲-绳法 (Drum-Buffer-Rope Approach, DBR法) 和缓冲管理法 (Buffer Management) , 就是基于TOC理论发展的适用过程管理方法。从TOC理论的主要内容来看, 它对项目管理的整个过程, 如成本管理、进度管理等, 具有较好的指导作用, 之前也有学者进行了相关的研究[12,13,14]。
本文认为, TOC的理念, 对于项目管理过程中的风险管理和质量管理, 也同样适用, 如风险识别、分析和控制, 质量过程分解和规范控制等, 都可以找出相应的约束资源和条件, 基于其DBR方法进行相应管理和控制。
2 案例分析
2.1 项目背景
2009年10月, 某公司 (出于商业考虑, 相关公司、软件项目等匿名处理) 应客户要求, 需要为某集团公司开发一套应用软件系统。该软件系统用于集团公司和分公司及分支机构多达300个网络节点之间的数据资料传输, 要求软件系统高效可靠、跨平台及安全可控等。考虑到该软件项目的其他潜在客户需求, 公司对该软件项目比较重视, 要求该软件项目既可满足该客户需求, 还能够作为正式软件产品向其他用户推广。该项目给予的开发经费共25万元, 并需要在合同签订之日起4个月之内完成, 时间和投入资源都比较有限。
2.2 项目要素分析
该项目的开发经理和小组成员通过该项目的各个关键要素分析, 识别此项目的关键风险和质量要素, 并采取了对应的管理办法。
2.2.1 已有基础和资源分析:
(1) 技术基础分析:公司在跨平台的开发、编译和可靠传输方面, 已经积累了丰厚成熟的技术, 并形成了可共用的API库, 新的项目可直接拿来复用, 不必重新开发。公司已有技术储备, 可以为此项目提供借鉴;
(2) 人力资源分析:公司是国内成立较早的软件开发企业, 积累和培养了一批技术人才。因此, 该项目经理要求公司为此项目组派一名经验丰富的研发人员, 要求熟悉公司相应的技术和产品, 能够解决复杂的相关技术问题;
2.2.2 约束资源和条件分析。
基于项目要求和现有基础分析, 此项目关键约束资源和条件, 有以下方面:
(1) 技术约束:该项目的初步分析, 技术上需要涉及前台界面开发和后台服务程序开发, 另外还需要突破一些关键的传输控制算法, 虽然可以重用公司积累的以往技术, 但还需要增量开发较多功能, 开发工作量较大;
(2) 人力约束:除了项目经理和公司已有一名经验丰富的研发人员之外, 其他人员都需要从公司外全新招聘, 而从开发内容和技术要求来看, 至少还需要从外部招聘三个研发人员, 要求这些人员技术熟练, 能够尽快融入项目角色;
(3) 时间约束:研发周期仅仅4个月, 因此需要尽快确定研发需求范围和设计方案, 合理调配研发人员, 在实践安排上会比较紧凑;
(4) 预算约束:由于预算只有25万元, 因此在研发人员的个数和熟练水平上, 需要精打细算, 人员不能过多 (人多则费用多) , 技术水平又不能太高 (熟练研发人员要求费用太高) , 因此需要发挥公司已有熟练技术人员的帮带作用, 以尽量少的人力来支撑项目研发。
2.2.3 关键风险分析。
根据上述项目要求及约束条件分析, 该项目存在以下关键风险:
(1) 需求范围风险:由于该软件应用在集团多个层面, 从集团总部层面反馈的需求往往不太具体, 因此需求存在不确定性风险。具体措施为借助销售资源, 通过多渠道调研用户的软件需求, 以避免需求偏离方向, 并为将来实际应用提供缓冲空间;
(2) 技术风险:虽然此项目的开发技术, 可部分借助公司历史积累技术和产品基础, 但多数需求需要重新开发, 工程量较大, 涉及多种技术, 因此需要充分发挥公司已有技术基础作用, 加强与公司内部技术经验丰富的开发人员沟通;
(3) 研发人员风险:研发人员多数需要重新招聘, 存在是否能够找得到及留住合适技术人员的风险。具体应对措施包括加强面试 (包括技术能力和职业操守方面的甄别等) , 在满足最低要求技术人员数量基础上, 额外招聘一名技术经验稍丰富技术人员进行资源缓冲, 并在开发中进行轮岗 (由于这些研发资源在本项目开发后, 还会留在项目组进行持续开发, 因此项目内开发人员在不同岗位轮岗, 在资源不增加情况下储备资源, 增加资源缓冲作用) , 经常进行走查和人员沟通, 避免人员流失风险;
(4) 时间风险:上述需求范围、技术和研发人员风险, 都会对项目进度带来风险, 因此需要针对上述风险因素和项目约束条件, 对项目管理过程进行控制, 妥善安排项目进度和任务资源分配, 消除进度和资源瓶颈, 尽量使得各个过程和阶段推进平稳, 保证整个项目的实践进度;
(5) 成本风险:成本的风险来源两个方面, 一是投入的人力资源数量和质量, 二是项目的进度。为了控制好整体项目成本, 本项目在人力资源的数量和质量方面进行了权衡, 根据项目的任务分解和总体设计方案, 在不同的任务配置相应技术能力程度不同的技术人员, 并在项目轮岗和帮带中促进一些技术能力稍低人员能力提升, 保证项目的进度, 做到成本总体可控。
2.2.4 质量管理要素分析。
质量管理同样贯彻项目管理的始终, 在整体项目管理计划中, 需要根据约束条件和公司及个人积累的知识经验, 转化为相应的操作性较强的过程管理规范, 以便在整个项目管理过程中控制好每一个环节的质量, 已达到总体项目质量可控。此项目的关键质量要素主要包括:
(1) 人员业务水平和工作态度:在项目管理的各个环节, 如计划编制、需求分析、设计编码、配置管理等, 无不与具体项目参与人员的业务水平和工作态度相关。因此, 在项目管理过程中, 需要根据需要进行人员培训和帮带, 并加强人员沟通和团队建设, 以提高整个团队的业务水平和士气, 从而提高每个任务的工作质量;
(2) 质量保障规范:要保障质量, 还需要制定操作性强的工作规范, 提供质量控制的尺度, 以指导项目管理过程中每个环节的工作, 从而改善项目质量;
(3) 过程控制:质量控制的关键, 在于过程控制, 因此需要在必要的关键环节, 加强项目参与人员之间的彼此走查或评审工作, 以保障每个关键环节的任务质量。
2.3 项目实施方法与结果
2.3.1 项目实施方法。
根据上述项目要素分析, 为了保证项目开发进度和费用可控, 在项目开发过程中, 有意为项目开发的关键环节, 预留一定的需求和资源缓冲。此项目主要过程, 包括以下方面:
(1) 整体管理:关键在项目管理计划部分, 确定好项目范围, 识别项目可能的风险, 并在项目内部和公司级别进行评审, 在初期阶段尽量发现潜在问题;
(2) 范围管理:关键在于通过销售渠道尽可能获取潜在用户需求, 并在内部讨论评审, 必要时开发相应原型, 尽量早地确定范围, 以免后期任务分解变更。另外, 为了保证此项目尽快形成可用的软件产品版本, 在立项评审时, 经过多次讨论筛选, 砍掉了应用价值不太重要和不紧迫的功能需求, 为软件项目开发留出一定的需求范围缓冲。此阶段需要尽量将工作任务分解细化, 并落实对应的匹配资源, 在后期中可逐渐细化求精;
(3) 时间管理:关键在于计划的编制和执行控制, 识别必要的风险并采取相应措施, 以避免项目管理过程中的关键节点延期。同时根据项目约束条件, 在项目的关键节点和任务, 留出必要的资源和时间富余缓冲, 以保证整个项目进度顺利进行;
(4) 质量管理:此项目的关键, 是利用了公司和个人积累的技术和管理经验, 编写了不同程度的可操作规范, 在关键项目过程进行项目成员之间的走查和评审, 以提高各个环节任务的质量;
(5) 人力资源管理:关键是招聘到合适的人才并能够留住人才, 因此在面试把关方面, 特别强调了面试人员的技术能力和工作态度, 并对加入团队的成员保持日常沟通, 加强团队建设。另外, 在投入人力数量方面, 按照经验估算的人力资源需求量为5人, 但为了考虑到项目计划中可能存在一些未考虑的工作任务和技术风险, 项目实际投入人力共计6人, 而多出1人并没有闲置, 而是将项目工作任务分解后, 相对均衡地分摊到团队各个成员上, 这样预留了人力资源缓冲。
(6) 风险管理:根据项目约束, 识别和分析项目风险, 并编制必要的项目风险管理计划, 对可能出现的风险采取对应的防控措施。其中很重要的一项措施, 就是在不影响项目进度和质量情况下, 将部分团队成员之间进行必要的轮岗, 使得每个成员能够掌握不止一项技能和更多项目有关知识, 这样既提高了成员个人能力, 又防止了人员流失所带来的岗位无人顶替风险。
2.3.2 项目实施结果。
由于该项目约束分析、计划和控制等执行较好, 在团队成员共同努力下, 终于在约定的时间周期、预算费用及公司内评审认可的项目范围内, 成功完成实施。该项目也存在一些不足之处, 如由于前期的一些约束条件因素, 如需求范围不是特别明确、团队成员多数是新进员工需要磨合、工期较短等, 导致在项目开发过程中, 为了控制关键过程中的关键任务按时完成, 团队成员经常安排了加班等不正常的项目管理办法。
该项目完成后, 形成了公司此类产品的第一个产品化版本, 并成功得到了第一个用户并实施。在后续工作中, 该项目团队成员根据用户反馈需求, 不断进行后续产品版本开发, 并基于前期的项目管理经验, 在小组范围内定期采用相互轮岗和走查措施, 对团队成员的整体工作能力提升及项目质量改进起到了较好的效果, 并控制了项目实施的风险。
3 风险和质量管理过程模型
根据约束理论和该软件项目的实施, 针对软件开的项目管理特点, 本文总结出基于走查和评审的风险与质量控制模型 (见图1) 和整体过程质量控制模型 (见图2) 。
图1所示模型类似目前软件开发中的敏捷开发方法, 如两人配对开发, 但略有不同。此模型是在必要的软件开发环节, 如编码、单元测试和详细设计等部分, 编写提供相应的检查规范, 如代码走查检查清单和规范要求、测试清单和规范要求等, 进行必要的成员之间工作成果检查, 以提高过程任务质量。图1模型中, 正常的活动流程是粗箭头所示, 而细箭头表示必要地走查、评审及反馈, 这样构建完整的流程及控制回路, 保证作业的质量, 其中, 检查和评审规范非常关键, 它直接决定了检查的效果和质量。在关键环节和关键任务, 进行必要的走查和评审非常关键, 它可以有效地控制项目管理过程中的关键任务质量, 从而保证整体的项目质量, 并控制项目开发过程风险。
根据图1模型, 将软件开发的总体过程进行分解, 对应的整个开发管理过程, 如图2所示。在纵向, 是整个软件开发的总体过程分解, 而这些过程每个节点的横向流程, 是针对这个环节的风险与质量控制过程和方法。在总体过程方面, 如项目立项、需求分析和总体设计环节, 可采用团队及组织层面的风险与质量控制方法;而在分解后的某些细节性的过程方面, 如详细设计、编码实现和单元测试环节, 可在项目成员之间采取必要的基于走查和评审的风险与质量控制方法。
对于软件项目的风险与质量管理, 其关键在于根据项目自身特点, 如约束条件、资源限制、技术特征等, 进行充分的风险识别, 这样才能进行对应的风险分析和采取对应的风险防控和质量管理措施。风险与质量管理存在于项目管理的各个过程, 在项目管理的各个过程域, 根据项目自身的约束条件, 进行分析和风险识别, 然后编制对应的项目风险与质量管理计划, 以便有效的进行风险防控和质量管理。
4 总结与展望
通过本文的案例分析, 本文发现在软件项目管理过程中, 根据项目约束条件, 进行必要地资源调配、资源缓冲等, 实施针对性的有效风险控制和质量管理, 并在项目中采用项目成员轮岗和彼此走查评审的项目管理方法, 能够提高风险控制和质量管理能力。另外, 本文根据约束理论和案例分析, 提出了相应的项目风险与质量管理过程模型, 可为软件开发项目的实践提供参考。
软件过程模型 篇9
计算机应用广泛, 计算机软件众多, 计算机已渗透到各个行业, 而且更新速度特快。
在软件知识缺乏系统性、内容繁杂的情况下, 我们不可能使用传统的方法循序渐进地、熟练掌握各种计算机软件知识。实际上存在“二八现象”, 就是80%的人使用20%最常用的软件, 比如Excel的决策模拟等功能很少人使用, 课堂教学不可能学习软件的全部功能, 更新太快又使得我们在学校进行计算机软件教学时不可能是最新的软件, 软件教学总是有一定的滞后性。根据软件的特点, 教学上选择的软件是最最常用的, 也只能教给学生最常用的功能, 而且软件版本只能是相对比较新。这样又使得学生出去工作时软件知识不够用, 版本低等情况, 可以大胆推测, 学生工作后使用的软件或软件的功能80%是要自学的。
“授人以鱼, 不如授人以渔”, 这种方法必然是软件教学方法的更好选择。
2 软件学习模型
如图1所示, 它以Bostrom等提出的计算机学习过程模型为基础进行教学修改, 增加了用户模型。它集成了认知心理学、教育心理学、信息科学和计算机科学等学科的研究成果。
模型组成部分包括:
1) 目标系统。用户将要学习软件。
2) 心理模型。用户对目标系统形成的心理表达。研究表明要取得良好的学习效果, 必须建立起正确的目标系统如何工作的心理模型, 尤其是面对新问题, 需要用户做一定程度的发挥。
3) 用户模型。系统开发者对用户特征的理解和表达。它包括用户的物理特征以及认知特点。为了使用户界面的设计真正符合用户的需要, 必须有一个正确的使用目标系统的用户模型。
4) 训练效果。主要从两方面考虑:用户对系统的理解程度;用户对系统感兴趣的程度。从训练效果我们可以看出用户的心理模型正确程度。
5) 个体差异。用户特性如可视能力等的差异。它影响训练效果。
在该模型中, 软件学习可看成是随着用户对软件的了解的深入, 他的心理模型不断完善、越来越复杂的过程。从图1可以看出软件学习有三种方式:直接使用该系统;以已有的知识、经验为基础, 通过类比、分析;通过培训, 给用户讲授正确的用户模型。
3 理论基础——语义Web与本体
3.1 语义Web和本体含义
语义的目标是对现有的Web进行扩充使Web中所有的信息都有明确的含义。
本体是共享概念模型的明确的形式化规范说明。
3.2 本体的建构方法
一般说来, 建构一个知识领域的本体, 包括以下5个步骤:
1) 确定本体的领域和范围。
2) 列举知识领域中重要的术语、概念。
3) 建立本体框架。
4) 设计元本体, 重用已有的本体, 定义领域中概念之间的关系。
a) 定义类及其层次关系。
b) 定义类的属性。
c) 定义属性值和创建实例。
5) 对领域本体进行编码、形式化选用合适的本体描述语言, 对上述建立的本体进行编码, 形式化。
4 描述方法——半边图模型
图是知识表示的形式化模型。图由顶点和边组成, 顶点是知识表示中的基本概念、基本模式等知识单元的抽象表达, 即顶点表示基元模式;顶点有若干属性, 不同顶点的属性可以互相识别与结合, 这样, 顶点之间就实现了关联, 在图中用边表示顶点之间的关联。
半边图模型中提出一个比顶点和边更基本的图元素, 称为可结合半边, 简称半边, 在自组图中, 顶点的属性表示为半边, 不同顶点的半边依据可结合性而结合起来称为边, 边就表示了顶点之间的关联。半边实现语义层次上的信息共享和交换。
4.1 主要概念
半边:半边是组成顶点的基本元素, 一个半边属于某个顶点且分为不同的半边类型, 半边与其它的半边可以相结合, 每个半边有权值, 一般取大于0的实数。这里权值用来表达语义的本体相似度。
顶点:顶点是组成图的基本元素, 顶点本身由有序的若干个半边组成。具有i个半边的顶点, 称为i度顶点。这里顶点表达软件知识点。
半边结合类型:称有序半边类型对为半边结合类型, 表示什么类型的两个半边可以结合在一起, 所有的半边结合类型所成的集合。这里用于表达知识的共享、交换与类比。
4.2 自组图聚合
图聚合算法实际上是聚类算法, 聚类是将物理或抽象对象的集合分组成为由类似的对象组成的多个类的过程。图就相当于抽象对象 (半边、顶点、边) 的集合, 图聚合就是对抽象对象的集合的分类。聚类算法的关键是对象之间相似性的评判标准, 不同的标准就会有不同的分类结果。任何一个具体的图聚合准则均涉及两个基本概念, 即图中的对象和对象之间的相似性。图中的对象有半边、顶点和边, 其中半边是组成图的最基本元, 但不能独立存在, 故不适合于作为图聚合的对象, 而顶点和边均为具有模式性质的独立基元要素, 所以适合于做图聚合的对象。图中的对象之间的相似性可以指顶点之间的相似性, 也可以指边之间的相似性。
4.3 自组图的归约
聚合子图是一些比较基本的、相对稳定的由基元要素构成的组合模式;若需认知更大范围的问题, 这些组合模式相对来说就可以认为是更高层次或更高观点下的“基元要素”, 也就是说, 在大范围、高层次的角度下, 组合模式可以看作是忽略细节内容的“点”, 只有这样, 才能有效地认知和处理复杂度不断增加的问题, 而不至于陷入过多的细节处理之中。
归约顶点:将图聚合为若干聚合子图后, 将每个子图对应为一个超顶点, 称为归约顶点。
归约半边与归约边:归约半边是归约顶点的半边, 是归约顶点与其它归约顶点相关联的工具, 不同的归约顶点的归约半边相结合构成归约边。
既然归约顶点与聚合子图相对应, 归约半边就应由聚合子图之间的各种可能关系类型抽象而得, 所以归约半边对应着聚合子图与其它聚合子图相交互的部分, 即聚合子图的子边界。而归约边对应着实际相连的分别属于不同聚合子图的两个子边界。按聚合子图的子边界之间的关系分析, 两个聚合子图之间的关系可以分为如下三种类型, 见图2-图4。
4.4 多层次自组织认知系统
使用半边图模型来抽象多层次自组织认知系统。
1) 可结合原子标识:可结合原子标识是基本的信息描述符号, 其核心特性为各原子标识之间的可结合性, 可结合原子标识与可结合半边相对应。
2) 简单粒:简单粒是可结合原子标识的组合体, 表示实际问题中的基本概念或基本模式, 简单粒与顶点相对应。
聚合粒:聚合粒是由简单粒通过可结合原子标识的结合性聚合而成的信息粒, 表示实际问题中的组合概念或组合模式, 聚合粒与半边图以及聚合子图相对应。将聚合粒对应为归约粒, 则聚合粒的相互作用则转化为归约粒的相互作用, 而归约粒在形式表达上与简单粒是一致的, 则归约粒之间的相互作用在形式上就与原子相互作用的运作规律保持一致。
3) 归约粒:归约粒是聚合粒的归约, 在形式上与简单粒的表达方式一致, 归约粒与归约顶点相对应。
4) 可结合归约标识:可结合归约标识是组成归约粒的基本要素, 在形式上与可结合原子标识的表达方式一致, 表示归约粒之间的相互作用, 其核心特性也为各归约标识之间的可结合性, 可结合归约标识与归约半边相对应。
5) 各个层次的信息粒之间的关系:初始层的信息粒只有初始层可结合原子标识和初始层简单粒, 这两种信息粒均来源于针对实际问题的人工原始设计。第一层可结合原子标识和第一层简单粒直接继承自初始层可结合原子标识和初始层简单粒, 第一层简单粒相互结合形成第一层聚合粒, 第一层聚合粒对应为第一层归约粒, 第一层聚合粒之间的关系抽象出第一层可结合归约标识。第一层归约粒传入第二层系统即为第二层简单粒, 第一层可结合归约标识传入第二层系统即为第二层可结合原子标识。以下类推。
5 语义、本体、半边图来构建新的计算机软件教学方法
5.1 计算机软件教学中本体的构建
当前计算机软件教学类比共享性差, 要想降低重复教学、学习带来的资源浪费, 提高学习质量, 需要形成更好的知识共享和重用机制。知识共享和重用的关键在于共享者对所共享的信息的含义要有一个共同一致的理解, 才能在语义层次实现信息的互操作, 进而实现更高层的、基于知识的智能应用。语义Web采用了本体的思想;本体是一种能有效表现概念层次结构和语义的模型, 提供对领域知识的共同理解, 确定领域内共同认可的词汇, 从而无论是人还是应用系统之间都能够有效地进行语义上的理解和通讯。也就是说, 本体使得不同软件的知识之间能够通信、共享和重用, 新的知识系统可以有
效地利用现有的知识系统, 而不必“从头学习”, 从而提高学习效率。
计算机软件种类很多, 每个软件包含许多知识点。计算机软件本体的构建实质就是研究单个知识点对象的属性特征和各知识点之间的相互关系, 使用本体技术将这些知识点及其相互关系形式化地表示并存储于计算机中。描述数据库分成3层, 底层是所有软件最基本操作, 高层是软件功能学习模型, 复杂的是中间层, 包含操作的描述以及各种操作之间分析、类比。
5.1.1 定义知识点类和类的层次结构
在本体中, 类的定义为共有某些属性而同属一组的一些个体的集合。类是本体中最主要的知识单元。多个类可以用“子类”关系组织为一个特定的层次
结构。最高层的类代表着最抽象的实体概念, 子类继承了其父类的抽象特性, 比其父类更具体或范围更小的实体概念。
如图5, 底层的就是知识点类, 在软件学习模型中, 首先使用方式1和3 (见图1) 来学习, 当掌握这些知识点后, 构建出上一层, 如学习了中的字体、字号等, 掌握后就是掌握了的字的设置。也就是一个知识点类。
5.1.2 定义知识点的相关属性
属性是关于类成员的一般事实以及关于个体的具体事实。在本体中, 属性能用来表述个体之间或者从个体到数值的关系。将个体关联到个体的属性称为对象属性, 将个体关联到数据类型的属性称为数据类型属性。
如“操作步骤”和“操作效果”是数据类型的属性, 值域为String。设定“”类具有“操作步骤”和“操作效果”属性, 这样就可以对类的个体“字号”等定义这两个属性。在软件学习模型中, 经过上一步的构建后, 这一步是构建知识点的属性。如字号的设置, 包含的属性有“操作步骤”和“操作效果”。
5.1.3 构造软件类
软件过程模型 篇10
软件过程可信度评估涉及指标很多、结构复杂, 既包含大量的客观指标也包含很多主观指标, 可归属于多指标决策 (Multi-Criteria Decision Making, MCDM) 问题。目前, 确定权重的方法很多, 其中T-S模糊神经网络 (Takagi-Sugeno Fuzzy Neural Network Model) 作为一种常用的多指标决策评估工具已经成功应用于许多数据分析领域。但是, 这种方法却很少用于软件可信度评估中。因此, 本文基于模糊理论特别是T-S模糊神经网络提出了软件过程可信性评估模型。
1 软件项目的可信度概述
1.1 软件项目的可信度定义
自20世纪70年代初, Morris首次提出可信性软件的概念以来, 软件的可信性问题就一直受到国内外学者的广泛关注。但是目前对于可信度定义并没有严格、一致的定义, 笔者通过对国内外学者的理论了解, 认为软件的可信度主要指软件实施过程中质量、成本、进度的可信控制, 以及最终软件产品的可信度。
1.2 软件过程的可信度及其内容
本文主要研究软件可信性的第一个主要方面软件过程可信, 通过对整个软件实施过程中的各种因素分析, 将软件过程划分为主要的三个研究对象, 即过程行为、过程产品、过程实体。并对三个对象的质量可信、成本可信和进度可信三个角度中的因素进行分析, 确立可信过程评价指标体系, 对整个软件实施过程进行全面系统的控制。
2 模糊神经网络方法研究
2.1 模糊神经网络的定义
模糊神经网络 (Fuzzy Neural Network, FNN) 就是模糊理论同神经网络相结合的产物, 它汇集了神经网络与模糊理论的优点, 集学习、联想、识别、信息处理于一体。人工神经网络是模拟人脑结构的思维功能, 具有较强的自学习和联想功能, 但却不能很好利用已有的经验知识;模糊系统相对于神经网络而言, 具有推理过程容易理解、专家知识利用较好, 但它同时又存在人工干预多、推理速度慢等缺点。如果将二者有机地结合起来, 可以起到互补的效果。
2.2 T-S模糊神经网络原理
(1) 前件网络
第一层为输入层;第二层每个节点代表一个语言变量值;第三层的每个节点代表一条模糊规则, 它的作用是用来匹配模糊规则的前件, 计算出每条规则的适用度;第四层的节点数与第三层相同, 它所实现的是归一化计算:
undefined
(2) 后件网络
它由r个结构相同的并列的子网络组成, 每个子网络产生一个输出量;输入层中第0个节点的输入值x0=1, 它的作用是提供模糊规则给后件中的常数项;子网络的第2层共有m个节点, 每个节点代表一条规则, 该层的作用是计算每一条规则的后件:
undefined
yk是各规则后件的加权和, 加权系数为各模糊规则的归一化适用度, 也是前件网络的输出用作后件网络第三层的连接权值。
3 基于T-S模糊神经网络建立评估模型
3.1 建立评价指标体系
软件过程可信度评估指标体系的建立是可信度评估的关键, 对软件过程可信度的分析是基于分解的思想, 将整个软件实施过程中的主要对象提炼出来, 其过程主要包含过程行为、过程产品、过程实体三个对象, 面向对象从不同角度分解成为质量可信指标, 成本可信指标和进度可信指标三个一级指标因素, 从而构建整个完整的评价指标体系。如下表所示:
本指标体系共涉及三个对象的40个影响评价指标, 将这些指标的采集统计数据作为模糊神经网络的输入值, 进而进行整个软件过程可信度的模型分析。
3.2 基于模糊神经网络的确定指标权重
(1) 建立模糊数学矩阵
①根据过程可信评价指标建立输入节点数学矩阵
A=[x11, x12, x13, …, x1 40;
x21, x22, x23, …, x2 40;
…, xij, …
…
xn1, xn2, xn3, …, xn40], 其中n为采集的数据组数。
xij表示第i组数据中第j个评价指标的数据值。i=1, 2, …, n;j=1, 2, …, 40。
②根据已完成软件的可信度水平数据建立输出层数据数学矩阵
B=[y1, y2, …ym…, yn ], 其中ym为第m个软件项目的可信度水平数据。m=1, 2, …, n。
③建立权重集合, 即各评价指标因素的相对重要性。
α=[ω1, ω2, ……, ω40]
上述步骤如下图所示。
(2) 确定模糊指标权重
训练模糊神经系统的方法很多, 有最快下降梯度法, 最小二乘法, 递归最小平方法, 麦夸尔特系统方法等。本文采用递归最小平方法对T-S模糊神经网络进行训练学习, 根据模糊神经网络原理进行权重的计算, 由模糊神经网络自身产生最后的指标相对重要性。即指标矩阵:α=[ω1, ω2, …, ω40]。
3.3 基于T-S模糊神经网络模型进行软件过程可信度评价
通过采集已完成的多个软件项目的40个评价指标和最终的软件可信度水平历史数据, 代入已经用MATLAB编制T-S模糊神经网络模型中, 可以得出软件过程各评价指标的有效权重, 从而建立起软件过程可信度评价模型。将其应用于新的待开发的或正在开发过程中的软件项目, 通过可信度评价模型预测可信度水平, 从而根据软件用户自身的需要进行调整。
4 应用举例
(1) 根据上述已经建立的软件过程可信度评价模型, 采集已完成的7个软件项目 (其中前五组为学习数据, 后两组为测试数据) 的40个评价指标数据建立整个评价指标矩阵A (各指标的评分为0～10, 分数越高表示该指标的可信水平越高) 。具体数据如下:
A=[ 5, 6, 6, 7, 8, 8, 7, 8, 9, 9, 7, 7, 8, 7, 5, 6, 6, 8, 7, 9, 8, 8, 7, 9, 8, 8, 9, 7, 7, 8, 7, 7, 8, 7, 8, 8, 8, 7, 7, 8;
6, 8, 6, 7, 6, 7, 7, 6, 8, 8, 7, 6, 6, 6, 6, 7, 6, 6, 5, 5, 7, 6, 7, 7, 7, 6, 8, 7, 8, 9, 7, 7, 6, 7, 6, 7, 7, 7, 6, 7;
6, 6, 5, 5, 7, 6, 6, 6, 7, 7, 5, 5, 6, 6, 5, 6, 6, 7, 6, 6, 6, 5, 7, 7, 6, 5, 7, 6, 6, 6, 7, 6, 6, 7, 6, 7, 6, 7, 6, 6;
8, 7, 8, 8, 9, 7, 8, 9, 9, 8, 9, 8, 8, 8, 8, 9, 8, 9, 8, 9, 9, 8, 9, 8, 8, 9, 9, 8, 8, 8, 7, 8, 8, 8, 9, 8, 7, 8, 9, 9;
5, 5, 6, 5, 4, 6, 7, 5, 4, 6, 5, 4, 6, 7, 5, 6, 6, 7, 4, 5, 5, 7, 6, 8, 6, 5, 7, 6, 5, 7, 6, 5, 6, 7, 6, 5, 7, 6, 6, 6;
6, 6, 5, 5, 7, 6, 6, 6, 7, 8, 5, 6, 6, 6, 5, 6, 6, 7, 6, 7, 6, 5, 7, 7, 6, 5, 7, 6, 7, 6, 7, 6, 6, 7, 6, 7, 6, 7, 6, 6;
8, 7, 8, 8, 9, 7, 8, 9, 6, 8, 9, 8, 7, 8, 8, 9, 7, 9, 8, 9, 9, 8, 9, 8, 7, 9, 9, 8, 8, 8, 7, 8, 8, 8, 9, 8, 7, 8, 7, 9 ]
(2) 邀请企业高层领导或第三方评估专家对7个软件项目可信度水平进行打分, 评分规则为1～10分。10分为最高可信度水平, 从而建立软件可信度输出矩阵B。具体数据如下:
B=[7.8;7.2;6.5;8.8;5.5;6.8;8.1]
(3) 将数据代入MATLAB建立的模糊神经网络模型中进行运算, 得到40个评价指标因素的权重 (编号顺序与3.1指标体系表中的标号一致) 以及测设的误差值, 具体结果如下所示:
得权重矩阵α
wts=Columns 1 through 7
-0.1525 0.4313 0.5228 -0.6186 0.7522 -0.6257 0.9039
0.5534 -0.3467 0.0995 -0.3902 -1.0135 -0.1946 0.7570
-2.3367 -0.8620 -1.4543 0.1940 0.1899 0.2029 -0.4109
0.7343 0.3222 -0.6582 0.1112 -0.5395 0.1896 -0.3425
-0.6807 -0.7200 -0.5971 -0.1163 -0.0866 0.3746 -0.7050
Columns 8 through 14
0.1681 0.1460 0.7522 0.2970 0.7692 -0.0603 -0.3955
-0.0196 -1.0305 -0.0792 0.1485 -0.4283 0.4911 -0.4581
0.0259 0.6350 0.5027 -0.8100 -0.9098 -0.0446 -1.1394
-0.7095 0.1963 0.4467 -0.4333 -0.1220 -0.4642 -0.2062
0.1473 -0.2708 -0.1236 0.0125 -0.4431 -0.3368 -0.4090
Columns 15 through 21
-0.0375 -0.1272 -0.1716 -0.3714 -0.3085 -0.6139 0.0446
-0.1889 0.4862 -0.8847 -0.7524 -0.2312 -0.2717 0.6115
-2.0230 -2.0912 -1.9810 -0.3167 -0.6771 -0.5100 0.0730
0.0718 -0.0791 -0.5199 0.5434 0.0324 -0.9222 -0.7727
0.2882 -0.8102 -0.3623 0.6398 -0.4630 0.6012 0.1504
Columns 22 through 28
0.4574 -0.2165 -0.3408 -0.1650 0.2093 -0.1827 -0.1665
0.0846 -0.3763 0.0782 0.3809 0.2444 -0.4611 -0.6735
0.4980 -0.4754 1.6675 0.1097 -0.7391 0.2703 -0.9976
-0.5975 0.6188 0.3456 0.4014 -0.4162 -0.8741 -0.5602
0.3119 -0.2135 0.0539 -0.8996 -0.6027 -0.0878 0.6023
Columns 29 through 35
0.9086 -0.4259 0.1924 0.6144 0.1108 0.5784 0.2200
0.2057 -1.2962 -0.6169 -0.1510 -0.4200 -0.0784 -0.4860
-0.0565 0.1082 -0.5000 -0.0910 -0.5158 -1.2168 0.2387
-0.3680 0.3240 0.2392 0.2661 -0.8255 -0.3495 0.4099
-0.3874 0.0334 0.2253 -0.7237 -0.5904 -0.7659 -0.2468
Columns 36 through 40
-0.6740 -0.1114 0.5834 1.0261 -0.3370
-0.0584 -0.1180 -0.4628 -0.4145 -0.4674
0.4247 1.4251 -0.7213 -0.8299 0.2824
0.7605 0.1620 -0.4474 0.5975 -0.2929
-0.8541 0.0938 -0.7828 -0.5305 -0.4678
error1= 0.2101 (此项为预测误差) ;
error2= -0.0408 0.2061 (误差2是第6个和第7个项目可信度水平预测值和实际值的差) ;
Y_forcast= 6.6654 8.7801 (第6个和第7个项目可信度水平预测值) ;
R=0.99999
以上结果可以看出影响软件过程可信度因素的权重, 模型运算的误差值很小, 回归系数R=0.99999, 拟合度高, 较小的误差说明了评价结果准确。应用此模型可以对其他的软件项目过程可信度进行评估, 从而进行定量分析进而改进整体的可信度水平。
5 结 论
基于T-S模糊神经网络建立的软件过程可信度评价模型, 可以全面地考虑影响软件项目实施过程的可信水平的多个因素, 从基于过程分解而来的过程行为、过程产品和过程实体三个对象进行了全面的质量、成本和进度管理, 把握住了过程管理的关键因素和主要目标, 使整个模型评价体系更加全面、可信, 从而保证了评价结果的准确性和有效性, 将定量与定性分析有机结合起来, 运用模糊神经网络直接进行运算, 不需要分析各因素之间复杂的逻辑关系, 并且充分地运用了专家资源和已有的经验、资料, 减少了个人主观臆断所带来的弊端, 使评价结果更科学、可信, 从而能更好的指导实践活动, 促进整个行业的良性发展。
参考文献
[1]蔡旭晖, 刘卫国, 蔡立燕.MATLAB基础与应用教程[M].北京:人民邮电出版社, 2009.
[2]丛爽.面向MATLAB工具箱的神经网络理论与应用[M].合肥:中国科学技术大学出版社, 2009.
[3]冉承新, 凌云翔.AHP—Fuzzy在仿真系统可信度综合评价中的应用[D].北京:国防科学技术大学人文与管理学院硕士论文, 2005.
[4]任晓慧.软件可信度量评估系统的设计与实现[D].聊城:聊城大学计算机学院, 2007.
[5]郭宁, 周晓华.软件项目管理[M].北京:清华大学出版社, 北京:北京交通大学出版社, 2007.
浅析软件测试中故障模型的建立 篇11
关键词：测试用例；故障模型；软件测试
中图分类号：TP311 文献标识码：A文章编号：1009-3044(2007)11-21632-02
Analysis of software testing based on fault model
YUAN Min,WANG Zhi-gang,LI Qiong
(College of Math and Computer Science, Hunan Normal University, Changsha 410081,China)
Abstract:With the high development of software,software testing becomes more and more important, There are many types of software faults with very high flexibility in software testing ,so the design for test case becomes most important. In this thesis,it aims at the indeterminacy of software test case,through at the building of fault model, makes use of the principle of FTA,designs test case for fault model adjudging software.
Key words:Software Testing;Fault Model;Test Case
1 软件测试
计算机的广泛应用,软件的复杂性和规模的不断扩大,使计算机软件质量问题日益受到关注。软件测试是提高软件质量的有效手段之一, 软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误。在软件测试过程中最关键的环节是软件测试用例的设计[1]。
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例
确定测试用例之所以很重要，原因有以下几方面。
(1)测试用例构成了设计和制定测试过程的基础;
(2)测试的“深度”与测试用例的数量成正比。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程也就越有信心。
判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和执行的测试用例的数量为依据的;
(3)测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排;
(4)测试设计和开发的类型以及所需的资源主要都受控于测试用例。
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例:一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错的提示文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、邏辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。
能发现到目前为止没有发现的缺陷的用例是好的用例；
作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。
测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
测试的目的是尽可能发现程序中存在的缺陷，需要在 给定的资源条件下尽可能达成目标，因此必须在测试计划阶段明确测试的目 标，一切围绕测试的目标进行。
除了资源上的约束外，测试用例的详细程度也需要根据需要确定。
测试用例不应该包含实际的数据；
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。测试用例中包含输入数据会带来维护、与测试环境同步之类的问题。
测试用例中不需要明显的验证手段；
很多测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统提示“订货成功”， 显然不是一个完整的用例，系统输出的“订货成功”就并不一定作为唯一的验证手段。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。
2 故障模型的建立
从大体方面来说，软件错误主要有五类，即疏忽错误、运行错误、清晰（或模糊）错误、速度错误和能力错误。不同的软件测试方法针对不同类型的错误，其查错效率不同。经验正，发现运行错误比发现忽略错误有效得多。具体来说，如果从软件错误性质的角度来划分软件错误的类型，主要有软件结构错误、数据错误、软件实现和编码错误、软件集成错误、软件系统结构错误和测试定义与测试执行错误[2]。对科学计算程序而言，最重要的是结构错误和数据错误。
软件测试可以看作是对错误空间的搜索，即要在数以百万计甚至更多的输入及其状态组合中，尽可能寻找更多的错误的状态及其组合。如果要确保每一个目标组合都被测试，那么测试必须是系统的；而且最终要定位错误，所以测试必须是集中的；最后因为测试需要使用大量的测试用例和大量的重复性测试，用人工测试几乎难以胜任，因此测试又是自动的。要满足上述三个测试条件必须建立故障模型[3]。
故障模型是测试的基础,也是一个测试方法成熟的重要标志。软件的错误表现为2个方面：（1）计算结果错误；（2）系统“死机”。导致第1类错误的故障相对来说是比较容易检测的。导致系统死机的故障其后果是严重的，这类故障由于一般其检测概率较小，也往往难以检测。死循环故障是最常见的能引起系统死机的故障，但这种故障由于其复杂性难以对其模型化，同时在许多情况下,死循环故障也比较容易暴露。对C++中几种能导致系统死机的典型故障进行了分析，这种故障的检测其意义重大,将这些典型的故障组合在一起，就构成了面向软件系统死机故障的故障模型。
故障模型是和语言本身相关的，不同的语言有着不同的故障模型。下面几种基于错误检测的故障模型是以JAVA和C++语言环境为背景。是软件中实实在在存在的故障，一旦这种故障发生，必能导致该软件发生错误，此类故障是应该尽量避免的[4]。
（1）数组越界故障的故障模型（OOBF）：设某数组定义为Array[min-max],若引用Array[i]且I
（2）存储泄漏故障模型（MLF）：设在程序的某处申请了大小为M的空间，凡在程序结束时M或者M的一部分没有被释放，或者多次释放M或M的一部分都是内存泄漏故障。MLF有3种形式（遗漏故障，不匹配故障，不相等的释放错误）使用未初始化变量故障模型（UVF）：存在一个路径，在该路经上使用前没有被赋初值的变量是使用未初始化变量故障。
（3）非法类型转换故障（long to short ,float to integer）：凡是类型转换可能导致错误的计算都是非法类型转换故障
（4）死码故障（DCF）：凡是程序中存在但没有任何用途的代码称为死码故障
（5）空指针使用故障（NPDF）：引用空指针或给空指针赋值的都是空指针使用故障
（6）资源泄漏故障（RLF）：在Java语言中，凡不能保证资源完全回收的计算都是资源泄漏故障，分为四种情况，简单泄漏；异常泄漏；交叉函数的情况和“静态”情况
（7）数据溢出故障（DOF）：凡是可能导致数据溢出的计算都是数据溢出故障
（8）非法计算类故障（ILCF）：指计算机不允许的计算
在软件中还存在另外一类故障，称之为安全漏洞，由于此类漏洞的存在，可能为人为攻击提供方便，一旦攻击成功，系统可能发生瘫痪，所造成的危害性更大，这种基于全漏洞的故障有以下几种故障模型。
（1）竞争条件（Race Condition）漏洞模型
当两个不同的函数共同对一个文件操作时，操作过程中存在一个时间差，利用这个时间差更改文件的某些属性可能导致后续的操作失败
（2）风险操作—随机数（Risky Operation-Weak Random Number）漏洞模型
当程序中用到随机函数如rand( ),random( )等时，由于这些随机函数的值是可以预测的，一旦使用随机数的值作为与文件操作或某些安全有关的操作时，将会存在安全问题。
（3）缓冲区溢出（Buffer Overflow）漏洞模型
当程序要在一个缓冲区内存储比该缓冲大小还要多的数据时，即会产生缓冲区溢出漏洞。
（4）被感染数据（Tainted Data）漏洞模型
当程序从外部获得数据时，它必须验证这些数据是否在程序的需求说明所规定的范围之内，否则，即是被感染的数据。
3 测试用例设计
基于故障模型的软件测试用例设计的难点是,引起故障发生的参数多,故障判决条件复杂,要保障测试的充分性,测试用例数量庞大,有时甚至达到无法忍受的程度。利用故障树分析(failure tree analysis , FTA) 原理结合测试用例设计等价类划分原则,对故障模型判决软件进行测试用例的设计,既可以提高测试的充分性,又能大大减少测试用例的数量。所设计的测试用例辅助设计软件在很大程度上提高了软件测试的自动化水平。
故障分析(FTA)是以故障树作为模型对系统经可靠性分析的一种方法。故障树分析把系统最不希望发生的故障状态作为逻辑分析的目标，在故障树中称为顶事件，继而找出导致这一故障状态发生的所有可能直接原因，在故障树中称为中间事件。再跟踪找出导致这些中间故障事件发生的所有可能直接原因。直追尋到引起中间事件发生的全部部件状态，在故障树中称为底事件。用相应的代表符号及逻辑们把顶事件、中间事件、底事件连接成树形逻辑图，责成此树形逻辑图为故障树。故障树是一种特殊的倒立树状逻辑因果关系图，它用事件符号、逻辑门符号和转移符号描述系统中各种事件之间的因果关系。
在进行测试用例设计时,可采用FTA 原理建立测试用例设计树，同时运用等价类划分方法进行测试用例设计。运用FTA 原理进行的测试用例设计，是根据故障判决模式画出故障树，将该树作为测试用例设计树，然后运用故障树原理获得该树的最小割集，将此最小割集作为软件测试用例设计的依据。软件测试用例设计树的建立步骤如下。
步骤1：对故障模式进行分析,确保对故障模式的理解准确无误；
步骤2：将故障模式作为顶事件,用矩形表示,如图1 所示；
步骤3：建树：将故障模式写在顶部矩形符号内，将引起故障发生的全部必要而又充分的直接故障参数类或参数置于相应的矩形符号或圆形符号中画出第二排，再根据故障模式与它们的逻辑关系用适当的逻辑门联结顶事件和这些直接故障参数类或参数。遵循此规则对参数类的判决也按此步骤进行，直到所有最低一排都是参数为止。这样,，就建立了一棵以给定顶事件为“根”，故障参数类为“节”，故障参数为“叶”的倒置的n级软件测试用例设计树[5]。
利用故障树分析原理中最小割集的求解方法,获得软件测试用例设计树的最小割集。此集合中的每个元素就是一个测试用例。
根据测试用例设计树中的逻辑“或门”会增加割集的数目，逻辑“与门”会增大割集容量的道理，从测试用例设计树的顶事件开始，把故障模式换成参数或参数类,参数类换成参数，遇到“与门”将输入的参数或参数类横向并列写出，遇到“或门”则将输入参数类或参数竖向串列写出，直到把全部逻辑门都置换成参数的矩阵为止。矩阵的每一行就代表一个割集，整个矩阵代表故障树的全部割集，再删去非最小割集，剩下的就是欲求的最小割集。最小割集中的每一个元素，就是一个测试用例。
4 结论
本文对软件测试方法及用例作了一定的介绍，针对软件的故障的五花八门，介绍了数种不同的软件故障模型，鉴于软件测试的复杂性和测试用例的重要性及其难以确定性，运用FTA 原理建立基于故障模型的软件测试用例，实验证明，通过此方法设计的测试用例充分、合理,在测试中能发现被测软件的重要缺陷，为委托部门避免重大损失，有效地提高被测软件的质量。
参考文献：
[1]郑人杰.计算机软件测试技术[M].北京：清华大学出版社，1992:25-28.
[2]Simeon Ntafos.On Random and Partition Testing[C].In:Software Engineering Notes,Proceedings of International Symposium on Software Tseting and Analysis,1998;23(2);42-48
[3]Musa JD.lannino A,Okumoto K.Software reliability measurement prediction application[M].McGraw-Hill,1987.ISBN 0-07-044093-X.
[4]Voas J.PIE:A dynamic failure-based technique.IEEE Transactions on software Engineering [A].1992,18(8):717-727.
[5]陆廷孝,郑鹏洲,何国伟,等.可靠性设计与分析[M].北京: 国防工业出版社,1995:159–183.
软件缺陷度量与软件过程管理 篇12
软件产品的生产过程是软件质量的形成过程, 所以只有在过程中实现良好的管理和质量控制, 才能得到一个质量合格的软件产品。软件缺陷就是其中的软件质量的负面影响因素。虽然所有的软件系统都不是尽善尽美的, 但是严重的质量问题会危及用户的使用, 从而危及企业的软件生产。
软件的开发阶段的缺陷管理和预防是非常重要的, 因为一旦制定了有问题的软件的设计方案, 会直接导致软件的质量隐患, 所以, 我们在研发阶段要尽可能的防止这种情况的发生, 将隐患扼杀在初始阶段。一般的做法是, 在软件研发的过程中要形成一个严谨的缺陷分析报告, 将关于软件的性能的各个方面的具体数据和资料综合整理出来, 对于存在安全隐患和易出现问题的环节做好一定的预防措施和预防方案。
2 问题描述
缺陷度量的技术的一个重要的指标和重要的作用就是对于软件系统中存在的问题的显示, 也就是对具体问题的描述。一般情况下, 软件的缺陷会分为大致的几种常见类型, 我们也可以根据这些类型, 做出不同的缺陷显示方法。正交分类方法ODC (Orthogonal Defects Classification) 作为一种常见的问题显示方法, 能够准确的显示问题, 一直被业内广泛的使用, 但是它也存在着技术上的缺陷, 就是解读方式比较复杂。另一种常见的方式是Thayer, 有点是比上一种方式的结果更精确, 但是解读起来也更加复杂。这两种方式的共同点在于都忽略了对于软件的过程的监控和分析, 这是一个非常严重的技术问题, 因为软件的研发过程才是质量问题的形成的重要阶段, 要控制质量问题, 就必须控制软件的研发过程, 所以, 我们想要找出新的监管和缺陷度量方法, 就要从控制过程的角度来分析。现在市场上的已经开发了几种缺陷管理系统工具, 例如Mercury公司的Quality Center, IBM公司的Rational系列管理工具, 微软公司的VSTS等。上述的几种技术都没有解决缺陷的分类问题, 导致了在软件过程的管理中的缺陷分类的薄弱。也直接导致了现有的缺陷管理工具在实用性和综合性方面的不完善, 上述的两种管理工具只是提供一些缺陷属性数量的简单统计结果, 要想得到一些更精确和更综合全面的分析结果, 用户不得不借助其他的统计方式。基于该目前市面上的工具的这样一种缺陷, 和软件过程管理的实际需要的不协调, 笔者制定了一种新的管理模型, 如图1。该模型可根据需要设计缺陷属性度量分类标准。在软件开发过程中通过缺陷管理系统采集缺陷数据, 运用缺陷分析方法实施缺陷分析, 把握缺陷发展趋势, 对软件项目开发过程进行综合评价。实施缺陷预防方案, 提高软件产品的开发质量。通过缺陷分析结果的反馈, 改进缺陷度量分类标准和分析目标, 提高缺陷分析结果的准确性。本文重点研究了缺陷分类方法和缺陷数据的分析方法, 并结合某项目中的缺陷数据实例进行了分析。
3 缺陷分类方法研究
3.1 缺陷分类的目的和原则
将软件的缺陷问题分类, 可以更好的管理和击破软件的缺陷问题。并且有益于分析缺陷产生的原因, 可以早到有计划的预防。缺陷分类方法应满足以下要求:准确地对发现的缺陷类型进行分类;缺陷分类类型之间应无重叠, 并尽可能多的覆盖开发过程中出现的分类;分类要与软件生命周期有机结合, 从软件过程的角度对软件缺陷进行分类。
3.2 缺陷度量属性分类
实施度量分析的最终目的是为了服务软件的研发和试验的各个阶段的顺利进行, 一旦发现问题可以及时纠正, 以免影响软件的研发和生产。在引言中曾提到, 软件缺陷的范围很广, 它贯穿于整个软件研发和生产试验的各个阶段, 是一种伴随着软件的整个过程的始终的应用, 所以它的重要程度也可想而知。一个缺陷需要记录许多相关的度量属性, 如何划分这些度量属性也是缺陷分类研究领域的一个热点。传统的分类方法主要目标是消除软件缺陷, 而不是对缺陷出现的原因进行一个正确的评估和解决方案的分析, 这样的分类方法是不利于软件的完善和发展的。所以, 一个全方位多角度的缺陷度量方式就应运而生。下面本文中将从缺陷度量属性设计的三个方面, 即描述属性、统计属性和控制属性来进行具体阐述。a.缺陷描述属性。缺陷描述属性是指:缺陷信息描述, 对于缺陷的各个方面和各个角度的描述, 既包括缺陷的时间, 产生原因也包括具体的解决方案的策划。b.缺陷统计属性。缺陷统计属性是指:缺陷生命周期状态, 缺陷流出的开发阶段, 缺陷流出的部门, 缺陷流出的功能模块, 缺陷表现类型, 缺陷的严重等级等基于缺陷数量统计其分布的属性。并且缺陷统计属性参考正交缺陷分类方法划分, 属性间没有相关性。c.缺陷控制属性缺陷控制属性是指:处理缺陷的角色, 缺陷的分配, 处理缺陷的时间, 缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。
4 缺陷度量过程管理
4.1 处理缺陷的角色
在软件开发过程中处理缺陷的四个负责人和所负责的任务的具体情况:报告人:将发现的缺陷登录到缺陷管理系统, 描述缺陷的表现形式和再现方法, 对缺陷进行简单分类, 由项目经理、组长对缺陷进行再分配, 缺陷修正完成后, 对其进行回归测试审核。负责人:负责缺陷的调查和修正工作, 分析缺陷引入的原因。组长:分配缺陷到负责人, 并对负责人已修正缺陷进行复查, 确保不会因为修正而引入新的缺陷产生, 分析缺陷流出原因。项目经理:分配缺陷到项目组, 定期总结缺陷分析报告, 把握缺陷发展趋势, 采取应对措施保证项目的进度及开发质量, 根据缺陷分析结果改进缺陷度量属性分类。
4.2 缺陷生命周期
缺陷生命周期是指缺陷从被报出之后, 到开始修正, 再测试直到该缺陷被完全消除的时间段。缺陷生命周期是影响软件研发的一个重要的指标和因素, 定期对缺陷各种状态信息的变化趋势进行总结, 是项目经理计划开发周期, 调整开发进度的重要依据。
4.3 缺陷分配管理流程
整个的缺陷的周期主要是指从发现到完全消灭的时间, 在这个时间内, 缺陷的分配管理流程主要包括:a.报告人登陆缺陷;b.管理人员分配缺陷给相关责任人;c.责任人调查并修正缺陷, 分析缺陷引入的原因;d.管理人员对修正结果进行复查, 分析缺陷流出的原因;e.报告人验证缺陷是否被正确。
结束语
软件的研发是一项非常复杂和严谨的工程, 所以在这个阶段要对软件的质量作出各个方面的监测和试验, 这样才能最大程度上减少软件的质量问题的发生概率, 而软件缺陷度量作为软件质量监测的一个重要方式, 应该引起我们有关的工程人员的足够重视, 不断在缺陷度量的技术上提升, 这样才更好的服务于我们的软件研发工作。
参考文献
[1]何荣勤.CRM原理.设计.实践[M].北京:电子工业出版社, 2006.