软件过程模式范文

软件过程模式范文（精选8篇）

软件过程模式 第1篇

核电设计院自行开发的软件一般涉及到一个或几个专业, 专业性强, 相对来说使用面较窄, 单个软件的开发量小。核电设计院一般均有信息技术部门, 归口管理应用软件开发、使用、维护, 一般根据设计专业人员的要求开展工具软件的开发;核电设计院按核电法规要求一般也有专业质量保证组织和人员。核电设计院ISO9000系列标准, 一般都建立完备的设计开发质量管理体系, 参与软件开发的人员对设计开发体系都较熟悉, 而目前软件业常用的质量管理体系是ISO9001标准和CMM模型[1], 因此核电设计院可以ISO9001体系为基础, 建立工程设计工具软件开发过程控制模式。

1 核电工程设计工具软件开发过程

产品的质量直接与用于建立产品的过程有关[2], 核电工程设计工具软件质量也直接与开发的过程相关。根据核电设计院软件开发的上述特点, 笔者总结了参与质保监督的设计工具软件开发过程, 把软件开发划分以下9个过程。

1.1 需求分析

软件开发人员需与设计专业人员一起讨论设计工具软件的功能需求, 开发人员在调研的基础上编制详细的需求分析报告。由于设计工具软件一般均是针对具体某个专业的领域提出, 需求相对集中, 可以尽量明确软件的功能要求, 避免后期需求的变化对开发的变更重复, 据统计, 需求的变更占项目总成本的40%[3]。获取需求应形成文档, 可追踪, 可测试, 并前后保持一致。

1.2 软件开发策划

在明确软件需求后, 可根据开发需求的清晰程度确定软件生存周期模型, 如是针对某个专业领域需求明确的软件开发任务, 可以采用瀑布型模型, 对于涉及多专业接口交换复杂的设计工具软件的需求, 可以根据主协办专业的需求变化, 采用迭代模型。后进一步策划开发过程中涉及的人力、软硬件资源需求、任务量, 进度安排, 一些重要的评审、测试的时机、频次。完整详细的策划保证后续开发过程的有序开展, 研究表明, 花在制订计划的时间投入产出比大约是1∶4[4]。

1.3 软件结构设计

根据需求分析和策划的进度、人力安排等等, 把需求转变为软件体系结构, 并标识软件中的各部件, 进行软件项的外部接口及软件各部件间接口的设计, 进行软件数据结构设计。此过程要保证需求都逐一分配到各部件, 分配的需求具有可追溯性, 能被验证。

1.4 软件详细设计

在结构设计的基础上, 进行编码、编译、测试单元级别的设计, 保证所有的需求都分配到软件单元, 并能测试。同时进行软件内、外部接口的详细设计, 数据库的详细设计。

1.5 开发评审

按照软件策划中的安排, 对软件开发过程或中间成果进行评审, 评价开发结果满足需求的能力, 并重点识别可能出现的问题, 提出改进措施。评审应明确:评审的目标;评审人员, 具体由哪些设计专业人员, 软件开发人员或外部专家参加;评审的准则, 如标准、适用的程序细则、软件策划书等;评审结论及改进意见。

1.6 开发验证

开发验证是确定已开发的软件是否满足需求分析的过程, 可由同小组内没有直接参与到该项软件开发的人员通过分析、评审 (例如检查或走查) 、演示等方式进行。开发的软件只有经过验证后才进行后续的测试和安装。验证发现的问题应当予以解决或说明。

1.7 开发测试

测试是从设计专业人员使用的角度出发, 确定已开发的软件是否满足开发的功能要求的过程。应当明确测试的类型、目标、范围、测试用例、测试数据和期望的结果。一般可以邀请设计专业人员参加。应记录测试的结果, 分析存在的问题及采取的措施。

1.8 安装和维护

核电设计院的设计专业软件一般均由软件开发人员统一安装。开发人员编制用户手册, 并对设计专业人员进行必要的培训。

1.9 开发的变更

在软件测试或是使用过程中, 文档化的收集设计专业人员对软件使用出现的问题, 识别并记录软件变更请求, 批准或否决请求, 实现、验证和发布已修改的软件, 并保证变更的可追溯性。软件的变更可作为配置管理的一部分。

2 核电工程设计工具软件开发程序策划

开发的设计工具软件会对设计成品软件产生质量影响, 根据《核电厂质量保证安全规定》 (HAF003, 1991) , 影响核电厂质量的活动都须按该活动的书面程序、细则来完成。同时为了规范软件的开发过程, 遵守明文规定的流程开发软件, 保证开发过程可以审核, 有必要策划设计工具软件的程序。

上述程序层次和大致数量与一般核电设计院的设计过程程序类似, 其与ISO9001中的设计和开发过程也无大的差别, 程序或细则中比本文第2节更详细控制措施, 可结合本单位习惯作法参考国标GB/T 19003 《软件工程 GB/T 19001-2000应用于计算机软件指南》予以细化。这些程序是在核电设计院已有ISO9001管理程序上添加的, 对于开发过程的文件控制、记录控制、人员培训等均可采用原管理程序, 其中《软件配置管理规定》可结合软件开发的变更、版本、软件项标识的管理统一编制。

3 核电工程设计工具软件开发过程质量保证

针对软件开发, 国内已经提出了相关的质量管理方法[5], 核电设计院质保人员可采用开发过程专项监督的方法, 验证开发过程与程序的符合性和有效性。软件监督被认为是质量保证的最佳实践之一, 有大量的数据证实它提高了公司的产品质量[6]。根据软件开发进展, 编制质量保证检查计划, 重点监督以下方面。

3.1 需求分析

检查需求获取的充分性, 设计专业间收集需求方法的适宜性。检查需求获取形成的资料和记录是否符合《用户需求管理规定》操作细则的要求?如何对获取的需要进行分析的?需求如何进行评审?评审发现了哪些问题, 如何解决的?如何对获取的需求逐一分配给软件项, 保证需求的可追溯性?

3.2 软件策划

检查软件策划的内容是否全部包括《软件开发策划书编制规定》操作细则要求的内容?根据需求分析对软件开发的人力安排、任务的测算与分配、进度安排、拟采用的开发模型与方法是否适宜?对与设计专业人员间的接口是如何策划的?对软件开发过程的评审、测试的时机、方法、人员如何安排的?

3.3 开发评审

检查有没按策划的时机和方法依照《软件设计评审规定》操作细则的要求进行评审?评审参与人员符合策划和操作细则要求吗?按照评审的准则得出了怎么样结论?重点关注评审中提出了哪些意见, 都是如何跟踪落实的?质保人员根据软件开发进展情况可直接参与评审过程, 对评审过程的符合性进行监督。

3.4 开发测试

检查测试的范围、目标、人员和方法符合策划和《软件测试规定》操作细则的要求吗?测试选择了哪些用例, 范围和数量符合操作细则要求吗?测试能否与需求相对应?测试的结果如何?测试的发现的问题是如何跟踪处理的?测试的记录是否完整?

质量保证人员针对软件的开发全过程可策划监查, 验证开发过程的符合性, 明确整个开发过程是否受控, 确定程序体系适宜性。如笔者就对我院软件开发的全过程控制进行一次监查, 审核开发程序体系的适宜性, 对工程设计软件开发体系提出需改进方面建议, 保证了核电工程设计工具软件体系的持续改进。

4 结语

1) 核电设计院结合工程设计工具软件开发特点, 在已有的ISO9001管理体系基础, 结合开发人员熟悉的设计流程, 把软件开发识别为九个过程。

2) 按照核电法规要求, 编制相应的程序, 制定措施, 对核电工程设计工具软件开发过程予以控制。

3) 通过监督、监查的质量保证方法验证开发过程的符合性和有效性, 为核电工程设计工具软件的开发质量提供足够可信度。

4) 为核电设计院工程设计工具软件开发过程控制提供一个参考模式, 即过程识别、执行程序控制过程、质量保证监督过程的模式。该模式对核电工程设计工具软件开发有一定的应用价值。

参考文献

[1]PAULK MC, CURTIS B, CHRISSIS MB, et al.Capability maturity model version1.1[J].IEEE Software, 1993, 10 (4) :18-27.

[2]DERNING W E.Out of the Crisis[M].Cambridge:MIT Center for Advanced Engineering Study, 1982.

[3]BOEHM B.Improving software productivity[J].IEEE Computer, 1987, 9:43-57.

[4]JALOTE P.CMM in Practice:Processes for Executing Software Project at Infosys[M].Reading:Addison–Wesley, 2000.

[5]陈利剑, 曾一, 基于USDP的软件质量控制[J].计算机工程, 2003, 29 (16) :84-86.

软件过程改进 第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篇

目前, 高职学院主流的教学主体为教师的教学模式早已不能满足社会对人才的需求。这要求我们积极进行教学改革开展以学生为主体的教学模式的探索。混合式教学模式是教育信息化发展而出现的一种新教学模式。其意义在于将学生在网络上的自主学习和传统课堂上的教学相融合, 是多种教学方式、学习方式和教学媒体的整合。因此, 基于Moodle平台的高职软件技术专业混合式教育模式研究具有十分重要的意义。

2 Moodle平台简介

Moodle是一个开源课程管理系统 (CMS) , 是一个免费开放源代码的软件, 以社会建构主义为其主要的理论基础。Moodle是Modular Object-Oriented Dynamic Learning Environment的缩写, 即模块化面向对象的动态学习环境。在基于Moodle平台的教学活动中, 教师和学生都是主体, 彼此相互协作, 共同建构知识。Moodle平台有主要三个方面的功能:课程管理、学习管理和系统管理, 其中课程管理包括课程教学组织、教学资源组织、学生学习活动组织、学生评价组织等管理;学习管理包括:记录学习情况、下载学习资源、开展协作活动、测验与作用等;系统管理包括系统模块管理、课程管理、模块管理、用户管理和系统参数设置。Moodle平台有系统管理员、教师和学生三种用户角色。其中, 系统管理员主要负责搭建Moodle平台的软硬件环境, 可分为课程管理员和网站管理员。课程管理员负责课程的创建和管理, 网站管理员负责对Moodle平台进行配置和维护。教师角色中的主讲教师和辅导教师是按照权限不同来分的。主讲教师可以组织教学活动, 建设教学资源, 进行日常教学管理。可以为学生分组, 添加或注销学生, 可以授权辅导教师, 可以设置课程“密钥”。辅导教师不能参与课程设计, 只能组织学生的管理成绩、课外讨论、查看日志等, 在日常教学过程中监督学生的学习活动。在指定教师时, 如果不特定教师编辑权限, 该教师就默认为辅导教师。学生角色可以在线学习网络课程资源, 参加在线测试, 在线进行讨论, 并将自己的学习历程以及学习心得写在自己的博客上。学生可以建立一个在线档案, 包括照片和个人描述。

3基于Moodle平台的高职软件技术专业混合式教学模式的教学过程设计

混合式教学是指融合不同的教学模式和不同的应用方式来进行教学的一种策略, 它结合了课堂教学和网络教学的优势。下面以 《Java程序设计》这门课程为例来介绍如何基于Moodle平台进行混合式教学模式的教学过程设计。

3.1混合式教学模式的教学资源设计教学资源是混合式教学模式的基本保障, 主要指与所授课程相关的教学材料, 包括课程的教案、课程的课件、实训指导、教学大纲、复习题、拓展资料等。随着慕课的兴起, 在《Java程序设计》课程的教学资源设计中, 教师可将课程的教学内容制作成慕课放在Moodle平台上供学生课余时间观看。 既方便了课堂上未听懂的学生进一步学习, 也为基础好的学生提供了预习的资源, 增强了学生对知识的掌握程度。

3.2混合式教学模式的教学课程内容设计 《Java程序设计》课程的操作性强, 采用任务驱动的教学方式能督促学生课前预习、课后复习, 提高动手能力, 从而激发学习的兴趣。下面以《Java程序设计》中《类和对象实现》一节为例, 说明教学内容的设计。

3.2.1教学目标

3.2.2知识目标1类与对象概念与特征、属性和方法;2类与对象的关系;3定义类的语法;4创建类的对象, 使用对象的步骤。

3.2.3能力目标1运用面向对象程序设计思想分析类和对象特征;2会创建和使用类和对象。

a教学任务“人”是社会主体, 日常生活中要想描述一个人主要包括姓名、年龄、性别、体重、家庭地址等信息。任务要求在计算机中使用Java语言对“人类”进行描述, 并用Java代码实现, 最后打印出人的信息。b实训任务第一, 编写一个电脑类, 属性包括品牌、型号, 方法为显示电脑信息, 并测试类;第二, 编写一个手机类, 属性包括手机品牌、手机型号, 方法为显示手机信息, 并测试类。

3.3混合式教学模式的课堂教学活动设计课堂教学活动设计是混合式教学模式的关键。Moodle为教师和学生的互动提供了很好的平台, 学生可以针对教学内容展开讨论或者提出问题, 也可以发表自己的心得体会。教师可以在教学过程中设置测试来及时检验学生的学习效果, 还可以创建一些趣味性话题, 鼓励学生参与并给予加分奖励, 同时还要在Moodle平台中跟踪学生的发言, 并及时给出反馈。下面以 《Java程序设计》中《类和对象实现》一节为例, 说明教学活动的设计。

课前:将教学课件上传至Moodle平台, 供学生预习。

课中:1 (10分钟) 利用Moodle平台中的“测验”功能, 针对上创建一套试题来考查学生对上节课知识的掌握情况。2 (30分钟) 利用课件和案例演示讲解本次课知识点。3 (35分钟) 布置并指导学生完成实训任务。4 (15分钟) 总结并布置作业。

课后:创建讨论话题, 鼓励学生积极参与。

4总结

基于Moodle平台的混合式教学模式, 能够激发学生学习的兴趣, 提高学生的自主学习能力, 营造良好的学习环境。同时也存在一些问题, 可根据每个学校的需求, 进行二次开发, 增加功能, 更好地为教学服务。

摘要：目前, 高职软件技术专业的教学改革势在必行, 本文介绍了问题研究的必要性和Moodle平台的功能, 探讨了基于Moodle平台进行混合式教学的教学过程。

关键词：Moodle平台,混合式教学模式

参考文献

[1]李明, 胡春春.基于Moodle平台的“合作—探究”式网络教学平台研究[J].吉林省教育学院学报, 2011 (3) .

[2]熊小梅.基于Moodle平台的网络课程设计及应用[J].教育与职业, 2014 (02) .

[3]唐春玲, 蔡茜, 张曼.基于Moodle平台的远程教育的实践与研究[J].网友世界, 2014 (5) .

中小型软件企业的软件过程改进研究 第4篇

关键词：中小型软件企业,CMMI,软件过程改进

国际上采用的软件过程改进模型如CMM/CMMI是软件过程改进领域的重要成果,它是适用于软件企业质量管理和过程改进的重要标准。但是,这些模型主要是针对大型软件企业的,对于国内为数众多的中小型软件企业并不完全适合。因此,寻找一种适合国内中小型软件企业的软件过程改进框架显得非常重要。以下在分析和借鉴CMMI和SPP理论基础上,研究出了一个面向国内中小型软件的软件过程改进框架(Software Process Improvement Framework,SPIF)。

1 构建SPIF的理论基础

1.1 CMMI的过程域(KPA)

CMMI过程域分为四类,过程管理类,项目管理类,工程类和支持类。

过程管理类的过程域包括组织过程焦点(OPF)、组织过程定义(OPD)、组织培训(OT)、组织过程性能(OPP)和组织革新和部署(OID)。

项目管理类过程域包括项目策划(PP)、项目监督与控制(PMC)、供应商协议管理(SAM)、集成项目管理(IPM)、风险管理(RSKM)、集成团队(IT)和定量项目管理(QPM)。

工程类过程域包括需求开发(RD)、需求管理(REQM)、技术解决(TS)、产品集成(PI)、验证(VER)和确认(VAL)。

支持类过程域包括度量与分析(MA)、过程和产品质量保证(PPQA)、配置管理(CM)、组织集成环境(OEI)、原因分析和解决(CAR)、决策分析和解决(DAR)。

1.2 SPP理论

SPP(Simplified Parallel Process),“精简并行过程”是林锐博士于2002年提出来的。SPP是对CMMI3级以内各过程域的内容和要求作了“精简”处理而创作出一种“软件过程改进方法和规范”。它由众多的过程规范和文档模板组成,主要用于指导国内软件企业进行软件过程能力的持续地改进。CMMI是SPP的主要参考标准,但是SPP并不是对CMMI进行简化处理后的结果。两者都是用于指导软件过程改进的方法论,CMMI主要论述“应当做什么才能使软件过程能力达到CMMI某种等级”,而SPP则论述“应当怎样做才能使软件过程能力达到CMMI3级水平”。

2 面向国内软件企业软件过程改进框架(SPIF)的建立

2.1 SPIF中的过程域(KPA)组成

SPIF(Software Process Improvement Framework)的建立是基于CMMI2、CMMI3级中的KPA,SPIF中的KPA分别是需求管理、需求开发、系统设计、代码实现与测试、项目策划、项目监督与控制、立项管理、结项管理、度量与分析、过程与产品质量保证、配置管理,本框架结合了中小型软件企业的特点,具有较强的针对性。

2.2 SPIF中各KPA的分析

2.2.1 需求管理过程域

需求管理过程域是许多过程域实施的前提,其目的是管理项目的产品和产品构件的需求,标识哪些需求与项目计划及工作产品之间不一致。通过适当的步骤,确保需求在项目的各个层面上动态地保持一致,一旦出现不一致,则启动相关的处理过程域,使其调整到一致。

2.2.2 需求开发过程域

需求开发是一个重要的过程域,它的质量决定了研发产品的方向。如果需求没有把握准确,不仅产品在研发过程中需要返工,而且上市后不能满足客户的需求,那么必然使企业利润的获取大打折扣,从而影响企业的发展。其目的是产生和分析用户需求、产品需求和产品组件需求。

2.2.3 系统设计过程域

系统设计过程域是对产品的体系结构、用户界面、模块、数据库等进行设计,从而在需求和代码之间建立桥梁,指导开发人员去开发产品。

2.2.4 代码实现与测试过程域

代码实现与测试过程域的目的是根据的用户需求,系统架构,系统设计的要求编写并测试整个系统的代码,确保产品最终满足用户的需求。

2.2.5 项目策划过程域

项目策划是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排,制定出一些计划(包括高层的和细节的),使大家按照计划行事,最终顺利地达到预定的目标。其目的是为项目的开发和管理工作制定合理的行动纲领(即项目计划),使所有人员按照该计划有条不紊地开展工作。

2.2.6 项目监督和控制过程域

为了保证软件系统在预期的工作量内按时保质的完成,需要定期地对其主要项目进行跟踪、监测和调整,跟踪的对象通常有规模、工作量和成本、计算机资源、进度、风险和软件工程技术活动等。其目的是通过周期性的跟踪项目计划的各种参数,不断了解项目的进展情况,以便当项目实际进展状况明显偏离计划时能够及时适当地采取纠正措施。

2.2.7 立项管理过程域

通过规范化的流程,判断并采纳符合企业根本目标的立项建议,提供合适的资金和资源,使立项建议成为正式的项目,并进行相应的筹备活动。反之,拒绝不能给企业带来利益的立项建议,避免浪费人力资源、资金和时间。

2.2.8 结项管理过程域

结项管理过程域是对项目的有形资产和无形资产进行清算,以利用可复用的软件成果;对项目进行综合评估,如评估项目完成情况、项目质量、项目对企业的贡献等,评估报告可作为考核项目人员业绩的重要依据;总结经验教训,将产品入库,形成组织财富。

2.2.9 度量与分析过程域

现代软件工程理论认为,要想控制软件质量就必须进行软件度量,软件度可分为产品度量、项目度量和过程度量。它们分别对软件产品质量、软件项目实施质量和软件过程质量进行量化,软件度量是成功实施过程改进的保障。其目的是在于发展和维持度量能力,以便支持对管理信息的需要。

2.2.1 0 过程和产品质量保证过程域

过程和产品质量保证过程域引入的动机是为了有一个相对独立于项目的成员,能够以第三方角色保证项目组成员遵守事先的约定,遵守作业流程以及对产品制定的标准和规则,这就好像社会中的司法部门,起监督执行的作用。其目的是使工作人员和管理者能客观了解过程和相关的工作产品,确保所策划的过程得以实施,从而支持交付高质量的产品和服务。

2.2.1 1 配置管理过程域

配置管理过程域目的是运用配置标识、配置控制、配置状态统计和配置审计,建立和维护工作产品的完整性。

2.3 SPIF各KPA与CMMI2、CMMI3的对应关系

表1为SPIF的KPA与CMMI2、CMMI3级KPA的对应关系。

2.4 SPIF的评价

为了检验SPIF效果,特设置了一个评分规则,列出一系列评分指标及权重,并通过对中小型软件企业进行调研和邀请几位专家进行评价。具体评价过程如下:

1)列出10个评分指标,每个指标的分值满分为10分,这些指标是:(1)能否产生符合软件规格说明的软件;(2)软件过程能否完成客户提出的要求;(3)是否易于被软件工程师理解;(4)是否易于被软件工程师接受和使用;(5)每个过程是否能取得明确的结果且对外可见;(6)是否会出现过程错误;(7)能否受意外发生问题的干扰;(8)是否易于得到计算机辅助软件工程的支持;(9)过程可否随软件组织需求的变更而演进;(10)能否较快地完成软件开发而交付。

2)设定效果基准值:不及格(60分以下);及格(60-70);良好(70-85);优秀(85-100)。

3)邀请5位专家,针对评分表进行打分,最后得到五位专家的评分分别为75分、85分、90分、88分和78分。

4)综合专家打分结果,进行加权平均,计算最终评分结果为83.2分,与基准值进行比较,确定效果为良好。

通过以上评分过程及评分结果,说明SPIF确实能为中小型软件企业的软件过程能力的提高以较大的帮助,能够为软件组织带来科学的、合理的软件过程,从而为产生高质量的软件产品提供有力的保障。

3 结束语

SPIF是在综合考虑国内中小型软件企业特点的基础上以CMMI和SPP理论为基础构建的,其目的是帮助国内中小型软件企业的软件过程能力。今后的工作需要在更多实践的基础上对SPIF进一步规则化和细化,以提高其可操作性。

参考文献

[1]Dennis M.Ahern,Aaron Clouse,Richard Turner著.CMMI精粹—集成化过程改进实用导论[M].第二版.北京:清华大学出版社,2005.

[2]Neil S.Potter,et al.软件过程改进简明实践[M].北京:机械工业出版社,2003.

[3]Capability Maturity Model-Integration(CMMISM)Version1.1for Software Engineering[S].Staged Representation,2002.

[4]林锐,王慧文,董军.CMMI3级软件过程改进方法与规范[M].北京:电子工业出版社,2003.35-210.

[5]罗运模,谢志敏.CMMI软件过程改进与评估[M].北京:电子工业出版社,2004.22-118.

软件过程模式 第5篇

从最初作为硬件的附属物开始,软件已经发展到当今作为硬件设计的标准之一的时代。它有三个要素最为重要:应用,开发技术和开发管理。如何提高软件的质量将是所有软件企业所要面对及需要解决的问题。

2 如何界定项目的成功与否

2.1 项目失败的原因

项目被迫取消、不能按时交付使用、超过预算、质量低。

失败的原因可以是:人的因素、技术因素、政策因素、资金因素、方法因素。

人为因素――很少有项目管理人既能100%地满足项目的业务需求又能解决问题。此类问题包括了诸如人员流动、业务需求的稳定、业务需求的理解以及技能等因素,这些因素每一个都足以毁掉整个项目。

技术因素――技术因素也可能造成项目的失败。这些因素包括了诸如响应时间太长、数据传送带宽不够,以及不能在硬件平台上采用某种软件。

政策因素――政策因素是个人在公司中为了自身获得利益,或者至少从别人那里得到这些利益而进行的。它有4个等级,有公司级的政策、开发小组级的政策、个人级的政策何业务与IS的竞争政策。

资金因素――如果资金不足,那么项目注定要失败的。这个不是秘密,资金不足会挫伤项目小组成员的信心,他们可能会想抄近路,可能会忽略细节,并且设计出内容不够完整、结构松散的项目计划,最终导致项目的失败。荒谬的是,一个有充足资金的项目也会因为一些其他的原因而失败。过多的资金也会造成一系列的低效率和冗余的行为,这种情况也会分散项目管理人成功提交项目的注意力。

方法学――方法学对于项目的成功与否非常重要,然而过于的依靠方法学,或者要么完全抛弃它,最终也可能导致项目的失败。

2.2 成功的项目

人们都认为如果一个项目能够在预算内及时地完成所有的项目目标,那么这个项目就是成功的。项目也可以说是各种利益、条件、因素、行为和效果同时作用的产物,我们可以用预算、用户需求、时限、产品质量和用户的满意度来衡量项目是否成功。

项目成功的因素:

1)招募技术熟练、经验丰富的人员。

2)应用前沿的、但非极端前沿的技术。

3)运用正确的开发流程。

4)提供适当的工具。

5)应用源文档控制管理。

6)应用有效的评估方法。

7)将工作细化为小的目标。

8)应对不断出现的变化。

9)项目领导。

10)创新的氛围和文化。

3 有利于成功的前期过程

要成功的完成项目,首先要对项目的失败的原因进行分析,通过合理选择和裁剪软件过程,提高软件项目的成功率。

3.1 角色裁剪

风险决策的一般过程如图1。

决策过程中用到的数据如图2所示。

回避风险的主要责任者包括如下几种角色。

1)产品经理:极有可能导致市场失败;

2)项目经理:极有可能导致进度、成本失败;

3)架构角色:极有可能导致技术失败;

4)系统分析角色:极有可能导致需求失败;

5)质量角色:极有可能导致质量失败。

不同角色的主要责职如图3所示。

不同角色的主要能力要求如下所述:

1)产品经理:市场预测能力(市场营销能力);

2)项目经理:项目估计、项目组织、控制;

3)系统分析角色:系统分析能力(一般的技术能力);

4)架构角色:高的技术能力;

5)质量角色:中等的技术能力。

角色裁剪,即低可行性兼任,见表1。

需要重点声明的是:一个项目团队,团队的知识结果非常重要。

3.2 过程的裁剪

过程裁剪,即是指过程的内容可以进入下一个过程。例如:

1)裁剪“市场风险决策”,一般用于投标的项目;

2)裁剪“项目估算”,适合于约定可以迅速达成(比如:重复的项目)的场合。

有些不恰当的过程裁剪,比如市场风险较大的产品,裁剪“市场风险决策”,则可能会浪费“项目估算”或者“约定”花费的工作量。

也可把增加过程看做一种裁剪,比如增加估算过程1,估算过程2.

我们可以把增加的评审也当做一种过程的增加,或者反之。太长时间(比如2个月)不做项目管理评审,可能导致项目管理的低效;太短时间(比如1周)进行项目管理评审,可能导致评审不经济。

3.3 约定的说明

《需求规格说明书》和《项目计划》是主要记录约定的地方,而《合同》是衍生物,因为:1)外部合同的签订时机取决于多种因素,比如市场战略的需要等;2)外部合同的形式和内容,取决于双方的要求。而《需求规格说明书》和《项目计划》是软件组织项目管理的真正需要。

需要注意的是,合同一般会在约定完成期间签署,否则,合同会有较大的风险。

4 有利于成功的后期过程

4.1 软件过程

1)与所有失败相联系的过程。同行评审,正式技术评审,正式管理评审;SQA;SCM;培训。

2)技术失败相联系的软件过程。系统分析、软件架构。

3)需求失败相联系的软件过程。需求开发、需求管理

4)质量失败。软件架构、测试过程、bug管理、Release过程。

5)进度失败/成本失败。进度估计、成本估计。

6)项目计划、项目监控、组间协调。CMM模型针对这些过程,都提出了重要的评价准则。

4.2 裁剪

1)过程裁剪:评审类型的选择;改变需求的过程。

2)模板定制:需求工作产品;设计工作产品。

3)工具选择:正如制定计划用Project98或Ms Office一样,进行工具的选择。

4.3 过程改进

过程对需求失败的影响曲线如图4所示。

改进产生缺陷的过程如图5所示。

提前缺陷的排除阶段如图6所示。

手段:同行评审、细化需求、设计阶段、细化测试阶段;采用迭代/增量的过程。

4.4 过程管理是项目管理的重要部分

理解了裁剪,才真正理解了软件过程。依据数据来裁剪过程会比较好,这是CMM4的要求。

裁剪过程,是基于经济性考虑的,而不是质量。

4.5 成功的因素和过程

根据Standish Group 1995,项目成功的因素如表2所示。

从以上资料可以得出应该优先关注的过程是:

1)优化需求工程,保证用户参与;

2)优化高层经理的支持过程;

3)优化项目管理的过程。

每个组织均有的过程数据,基于这种过程数据,才可以更好的进行过程改进。

4.6 过程管理的公理系统

1)过程不能无限细化。

公理的使用:裁剪软件过程,使得在过程质量与过程效率之间有一个较好的权衡。

2)风险决策尽可能提前。

公理的使用:采用Spiral模型和快速原型法。

3)尽可能实行并开发定律。

公理的使用:V模型;迭代/增量模型。

4)减少变更(返工)的发生。

公理的使用:工作产品的质量评价(比如,评审)。

5)质量在过程中。

公理的使用:CMM2级的SQA过程。

5 结束语

软件技术可以提高软件过程的性能,比如重用技术,可以有效地改善成本/质量/进度。软件过程不能解决技术创新不足,导致项目失败,但可以减少这种失败造成的损失。

归根到底,人的能力是导致失败的深层原因。过程的入口准则之一:过程执行者必须具备相应的能力。

在过程这方面,注意真是管理原理的应用,有助于提高一次性SPI软件过程改进的成功率;设立技术委员会,专家知识共享;加强技能管理;保证上岗人员的能力。基于以上的分析,建立“项目性能评价体系”,作为项目管理咨询的核心部分,将有益于过程改进工作。真正改进软件项目的过程,提高软件过程的效率与有效性,进而做到按期、质量、不超预算地开发出满足客户需求的软件产品才是软件企业真正所想要的。

参考文献

[1]SPIN.软件过程改进实践[M].北京:电子工业出版社,2004.

[2]Persse J.CMMI成功项目管理[M].李晓丽,李虎,刘东懿,译.北京:机械工业出版社,2008.

[3]Purba S,Shah B.如何成功管理一个软件项目[M].陈明,译.北京:中国铁道出版社,2003.

软件性能测试实施过程研究 第6篇

软件性能测试作为软件质量保证必不可少的环节,指的是软件系统或构件对于其及时性要求符合程度的指标;它是一种规范,可以用来量化更改业务指标所产生的影响,进而说明部署软件的风险。一般用响应时间、吞吐量每秒点击数等参数指标进行衡量。软件测试广义上分为压力测试、负载测试、强度测试、并发(用户)测试、容量测试、配置测试和可靠性测试等。

性能测试工具一般通过Winsock和HTTP等协议记录用户操作。软件系统的架构不同,协议的选择也不同。不同的软件测试工具的脚本语言不同,每种测试工具都有自身的特点,在实际应用中应选择适合软件架构性能测试工具。常用的测试工具有很多,有用于服务器存储子系统读写性能测试的Iometer、用于Linux服务器下I/O性能测试的Iozone、用于服务器的网络性能测试的NetPerf以及用于应用系统的负载性能测试工具QALoad,LoadRunner和Webload等。这些工具的功能强大,能自动生成测试报告。

1 性能测试的一般步骤

LoadRunner是惠普公司的软件性能测试产品,主要由虚拟用户发生器(VuGen)、压力调度和监控中心(Controller)、压力生成器(Load Generator)和结果分析工具(Analysis)组成。本文以LoadRunner为例,说明性能测试的一般步骤:

(1)确定用户要测试的业务。也就是通过需求分析,确定测试的目的和测试的性能指标(响应时间,并发用户数,吞吐量和资源利用率等)。

(2)通过用户对软件的操作和Vugen的录制功能记录并生成虚拟用户脚本。

(3)修改脚本,确定脚本能够回放成功。

(4)在Controller中根据需求配置测试场景。包括虚拟用户数、运行参数、用户增长方式、测试循环方式、用户退出方式和需要监视的性能指标等。

(5)执行测试场景。Controller控制Load Generator对被测系统的加压方式和行为,同时搜集被测系统各个环节的性能数据。Load Generator记录最终用户响应时间和脚本执行日志,并将数据传送到Controller中,由其进行结果的汇总。

(6)借助Analysis分析测试数据,设计调优方案。

(7)进行调优测试,重复测试过程,直至符合系统性能测试的要求。

2 测试方案设计及实施

2.1 测试需求分析和脚本录制

通过分析用户对软件的性能要求和阅读软件的需求分析文档,了解软件的类型、应用领域、所需环境和系统功能,确定测试的目的和性能指标。测试目的包括性能符合性验证、性能能力验证和性能调优。性能指标主要包括响应时间、并发用户数、吞吐量和资源利用率等。对测试的需求分析以确保使用测试工具创建的测试环境能够在测试中精确地反映应用程序的环境和配置,以及系统性能瓶颈所在。

分析软件中的典型用户,通过VuGen记录业务的操作流程创建脚本,不需要依赖客户端软件。脚本录制好后,通过对录制后的脚本添加事务、集合点和参数等,强化脚本,确保回放成功。

2.2 设计测试方案

脚本录制好后,设计测试方案。测试方案的设计关乎测试结果的准确程度。方案包括如何模拟实际用户的信息:虚拟用户组、Vuser运行的脚本和负载生成器。分析用户使用模型,定义系统的典型使用方式,考虑哪些用户使用该软件,每种用户的数量和典型任务,还应考虑任何可能影响系统响应时间的负载。本文采用LoadRunner的Controller,建立持续的负载,管理负载方案,利用日程计划定义用户什么时候访问系统,实现测试过程的自动化。

本文测试某大学学报系统的登录功能的性能,模拟50个虚拟用户,同时登录本系统,如表1所示;并保持100个用户同时在线,如表2所示。

2.3 方案的实施

方案设计好后开始实施。本文的测试中,并发测试中实际在线的人数达到100人以上,且在线时间超过30分钟,测试结果软件达到要求。LoadRunner的压力调度和监控系统同时搜集被测软件的各个环节的性能数据,记录最终用户响应时间和脚本执行的日志。运行结束后,将数据传回监控系统,汇总测试数据。

LoadRunner的数据分析器Analysis读取测试数据,进行分析,确定瓶颈和软件系统的调优方案,对系统重复进行测试,确定软件系统的性能是否提高。本文同时对软件性能测试中的测试要点进行了分析,总结各测试指标对测试的影响以及它们之间的关系,给出测试报告。

3 结束语

软件系统性能测试是一项复杂的工作,有一定的偶然性。本文主要阐述了软件性能测试的主要过程和关键技术,并结合LoadRunner测试工具和实际软件进行测试实验,对提高软件产品的质量和可靠性提供了保障。本论文的不足之处在于没有对软件性能测试的各个指标以及它们之间的关系做出更详尽的分析,这是以后需要继续研究的内容。

参考文献

[1]陈江.软件性能测试研究与分析[J].福建质量管理,2009(03).

[2]韩明军.软件性能测试过程[J].信息技术与标准化,2007(11).

[3]朱怡雯,钱超,林勇.软件性能测试工具综述[J].中国金融电脑,2009(07).

[4]曹晋源.LoadRunner在软件性能测试中的应用[J].电脑开发与应用,2008(05).

[5]欧阳荣彬,郭陟,顾明.基于排队模型的软件性能测试框架研究[J].计算机工程,2006(03).

软件过程模式 第7篇

Hetzel在第一次软件测试会议中指出:软件测试就像一门艺术, 是带着找出错误的目的而执行程序的一个“破坏性”过程。Dijkstra则指出, 软件测试只能证明缺陷存在, 而不能证明缺陷消失。

Glenford Myers在《软件测试的艺术》一书中, 给出了软件测试的定义:软件测试是一个为了找出错误而执行程序/系统的过程。它强调软件测试是一个找错的过程, 而不仅仅证明系统是可以运行的过程。

项目经理通过分析软件测试中的数据信息, 不但可以评价软件产品的质量, 还能评价及改进软件研发过程。软件测试从本质上来说, 是一个取样规则 (sampling discipline) 。通过执行一些有代表性的但数量不多的测试用例得到的结果, 可以看出系统的性能。软件测试过程最出名的是“V模型”, 它包括单元测试、集成测试、系统测试、验收测试。

2 统计过程控制

统计过程控制SPC (Statistical Process Control) 及与其相关的控制图思想是在20世纪20年代, 由美国贝尔实验室的Walter A. Shewhart提出的。SPC的主要目的是控制产品的成本和质量。SPC即统计过程控制是一种借助数理统计方法的过程控制工具, 对生产过程进行分析评价及实时监控, 根据反馈信息科学地区分出生产过程中产品质量的正常波动与异常波动, 及时发现系统因素出现的征兆, 从而对生产过程的异常情况提出预警, 并采取措施消除其影响, 使过程维持在仅受偶然因素影响的受控状态, 以达到控制质量的目的。统计过程控制是应用统计学小概率原理来监控软件过程的运行。其原理是:在一次观测中, 小概率事件是不可能发生的, 一旦发生就认为系统出现问题。

控制图是用来实施控制生产过程中产品质量状况的统计工具, 通过把过程度量获得的数据以图示的方式表现出来, 让用户能直观地看出过程中存在的波动、异常和过程的趋势。控制图一般包括以下要素:中心线 (CL) 、上控制界限线 (UCL) 、下控制界限线 (LCL) 、样本统计量数值等。常用控制图有X图和R图、X图和S图、单点值和移动值域 (XmR) 图和u图。

3 运用SPC监控软件测试过程

3.1 研究现状

SPC已逐渐应用于软件测试过程中。2006年Hitachi软件工程所的Mutsumi Kmour在《Experiences of Applying SPC Techniques to Software Development Processes》一文中指出:对软件测试过程应采用多个度量属性监测测试过程质量, 包括评审速度、缺陷率、早期缺陷检测率和累计执行测试用例数。由于软件工程领域样本规模小, 所以规定过程失控的上下控制限为1 。

本文在Mutsumi Kmouru的基础上, 从软件测试过程的各阶段及每个阶段的稳定性监控两个维度加以研究, 系统地提出在软件测试过程中各个阶段如何应用SPC控制图作为统计工具。软件测试过程的特点是生产周期长, 短时间内无重复的过程。本文运用传统的SPC, 把组成软件测试过程的每个功能模块或个体作为一个样本, 所有的功能模块或个体在一起综合作用, 共同监控软件测试过程的稳定性。根据每个阶段的具体特征, 提炼出一些有代表性的度量属性, 度量的检查点要能反映软件测试过程的各阶段特征。结合Shewhart控制图的模型, 把度量属性灵活运用到X图、R图、XmR图以及u图中, 分析控制图, 进而对软件测试过程进行监控。

3.2 SPC在软件测试过程中的建模与监控

3.2.1 X、R图在测试计划中的应用

测试计划的评审过程属主观的评估过程, 因此可根据评审委员对整体测试计划提出的修正意见, 判定计划的可行性和计划过程的稳定性。评审人员对同一计划的多方面 (测试计划核心的5个要素是时间调度、资源分配、测试范围、风险控制、测试策略) 修正意见, 可以引申为在基本相同的条件下采集数据时, 将产品或过程属性特征度量分成一些自相容的系列集合 (分组) 。可以使用X图和R图评估计划过程的稳定性。

将测试计划的5要素作为5个变量:时间、资源、范围、风险控制、测试策略。把评审委员会每个成员对各变量的修正意见数目作为该变量的分组 (集合) , 可得度量统计表1。

根据X图和R图的计算公式以及表1中的测试计划评审数据, 得出以下公式:

(1) 每个变量分组的平均意见数目:

undefined

Xreviewer1XreviewerN为每个评审员提出的意见数目

(2) 根据每k个分组的平均, 计算总平均值:

undefined

(3) 每个变量分组的极差:

undefined

(4) X图和R图上下控制限的计算:

undefined

(5) 得出X图和R图, 并分析测试计划存在的问题。①若测试计划变量超出X图的上控制限, 则应分析该测试计划要素涉及的在设计方面存在问题, 这里应该特别重视;②若测试计划变量超出R图的上控制限, 则应分析在该要素涉及的方面, 评审员的立场是否存在较大的差异;③若测试计划变量超出X图的下控制限, 则表示在该要素涉及的方面评审员修正意见较少, 设计得比较好;④若测试计划变量超出R图的下控制限, 则表示评审员在这方面立场比较一致。

3.2.2 XmR图在设计测试用例中的建模

测试用例的多少不仅直接体现了测试对系统需求测试的覆盖程度, 也确定了测试过程的主要工作量。测试覆盖率 (测试用例与需求数比值) , 表明了测试对需求覆盖的广度及深度。每个系统需求可以细分为多个功能点, 每个功能点有一个或一个以上的测试用例来覆盖, 运用每个功能点的测试用例数作为测试用例覆盖度的度量。功能点之间相互独立的离散性决定了该数值的相互独立性, 但是从测试覆盖深度一致性的角度观察, 每个功能点需要测试的用例数目存在可置信范围一致性。因此对于每个功能点的测试用例数, 运用XmR控制图来监测不同功能点的测试用例覆盖数目的一致性, 从而在测试用例评审时获取测试用例数目不符合SPC控制图曲线的功能点, 通过增删用例的方式, 调整测试效率与测试充分性的平衡。

统计处理方法如表2所示。

(1) 计算每个功能点FPi的测试用例数量Xi移动范围:

第RPi移动范围=mRi=|Xi+1-Xi|

1in-1 (11)

(2) 计算所有功能点FPi的测试用例数量平均移动范围:

测试用例数量平均移动范围=

undefined (12)

(3) 计算XmR控制图的中线:

undefined (13)

平均移动值域中线undefined

(4) 计算XmR控制图的上下控制限, d2、D4由值域数据的离中趋势和偏差系数简表得到。

自然过程上限undefined

自然过程下限undefined

移动值域的上控制限undefined

(5) 得出XmR控制图, 并分析设计测试的过程是否处于效率和充分性的平衡状态。①如某个功能点的测试用例数量超出自然过程上限, 则需针对此功能点作进一步分析, 通过将此功能点与其它复杂度一致的功能点的用例数目和测试角度作比较, 找出此功能点是否存在过度测试问题, 或其它的功能点是否存在测试覆盖不足问题。若是前者, 则需要考虑删减冗余测试用例;若是后者, 则表明测试用例整体设计的覆盖深度不足, 需对其它的功能点重新分析, 适当增加功能点;②如某个功能点的测试用例数量超出自然过程下限, 其分析和处理过程与i类似。

3.2.3 u图在执行测试中的建模

在一个稳定的测试系统内 (即人员稳定且软件系统质量稳定) , 测试执行将呈现一个稳定的步进势态, 因此衡量测试执行是否按计划进行, 是否处于稳定状态, 可以通过观察某时段内测试进度来实现。测试通过率的度量反映了某一时刻被测系统的质量, 为了体现此度量的时间特性, 下面引入时间参数j, 通过记录在某一单位时段j的各系统模块测试通过率来刻划此时间段内的测试执行过程的稳定性, j可为天或周, 计算公式为单位时间段j通过的测试用例/单位时间段j执行的测试用例总数。根据u图的特性, 它是一种计数型控制图, 它绘制的是每个样本中的单位平均缺陷数, 即描述了样本数变化时每个单元的缺陷数。所以用计算单位测试用例的不通过率 (模块i中不通过的测试用例数量/模块i中测试用例数量) 来检测系统的质量。

根据测试系统的稳定性特征, 单位时间内相互独立的模块内测试不通过率将处于一致的“机会域”。采集多个模块单位时间内测试不通过率, 利用SPC的u图模型运算后, 可以过滤超出“机会域”的模块, 寻找这类模块的可归属因素。

表3说明了如何运用u图进行监测。

(1) 计算中线值u, 用所有模块不通过的测试用例总数除以所有模块的测试用例总数:

undefined

(2) 计算每个模块的测试用例不通过率的控制上限和控制下限

undefined

重复运用上述公式, 把每个模块的测试用例不通过率上下控制限都计算出来。

(3) 得出j时段的u图, 并分析执行测试过程中是否处于可控状态。

①若有模块的“测试用例不通过率”超过控制上限, 则表示通过的测试用例数低于通常规律, 需要检查是否是由于模块本身的代码质量出现问题, 并找出该模块的可归属原因;②若有模块的“测试用例不通过率”超过控制下限, 则表示通过的测试用例数高出通常规律。排除其它测试的主观因素原因后, 确定确实是该模块的代码质量高, 则要总结经验, 继续发扬;③在每个j时段内, 重复运用u图, 以观察不同测试和开发阶段模块的质量。

3.2.4 XmR在跟踪测试缺陷中的建模

缺陷生命周期的长度, 一定程度上反映了测试和开发团队协同工作的效率, 对于考察缺陷修复期的过程的稳定性起着重要的作用, 因此可以通过监控缺陷的生命周期长度, 即从初始化到关闭所用的时间, 来监测系统中各缺陷的严重程度, 从而为分析系统中开发和测试的薄弱环节提供依据。

项目组可以定期把该阶段关闭的缺陷进行生命周期时间的统计, 然后应用XmR图进行监测。

(1) 计算每个缺陷Di的生命周期长度Xi移动范围。

Di移动范围=mRi=|Xi+1-Xi| (19)

(2) 计算所有缺陷生命周期长度的平均移动范围。

缺陷生命周期长度平均移动范围=undefined

(3) 计算XmR控制图的中线:

undefined

平均移动值域中线:undefined

(4) 计算XmR控制图的上下控制限, d2、D4由值域数据的离中趋势和偏差系数简表得到。

自然过程上限undefined

自然过程下限undefined

移动值域的上控制限undefined

(5) 得出XmR控制图, 并分析跟踪测试缺陷的过程是否处于稳定状态。

①若有缺陷的生命周期长度超出自然过程上限, 则分析该缺陷在生命周期中的哪个阶段花费的时间最长, 是什么因素导致该阶段持续这么长时间, 解决过程中遇到什么问题, 该缺陷涉及软件的什么部分, 是否影响软件其它相关的部分。可将这类问题列入重点开发指南和测试指南, 为以后类似的项目开发和测试提供有效的借鉴;②若有缺陷的生命周期长度超出自然过程下限, 则该缺陷的处理时间低于平均水平, 分析该缺陷是否由于测试人员测试环境搭建出现问题, 或该缺陷由微小的错误导致, 并总结快速发现和修复缺陷经验。

4 结束语

本文提出以SPC统计思想对软件测试过程进行管理, 借助统计数据使项目管理者作出决策的方法。定义和使用以过程为重点的度量, 为软件测试过程提供早期反馈及持续的监控和管理。度量的检查点要能反映软件测试过程的各阶段特征。本文在软件测试流程制定测试计划、设计测试用例、执行测试和跟踪缺陷4个关键活动中, 提炼出一些有代表性的度量数据, 结合Shewhart控制图的模型, 根据软件测试本身固有的性质, 把度量数据灵活运用到X图、R图、XmR图以及u图中, 然后分析控制图, 进而对软件测试过程进行监控。

参考文献

[1] W HETZEL.The Complete guide to software testing, 2nd Edition[M]. QED Inf.Sc.Inc, 1998.

[2]ANTONIA BERTONLINO.Software testing research:achieve-ments, Challenges, dreams, Future of Software Engineering (FOSE'07) [C].IEEE, 2007.

[3] GLENFORD J.Myers.The art of software testing 2nd Edition[M]. John Wiley and Sons, 2004.

[4] LJUBOMIR LAZIC.The software testing challenges and methods[C]. SIEMES d.o.o, Radoja Dakica 7, 11070 Beograd, Serbia&Montenegro, IEEE, 2008.

[5] WILLIAN A.FLORAC, ANITA D.CARETON.Measuring the software process-statistical process control for software process improvement[M].Pearson Education, 2002.

[6]LAZIC, LH, VELASEVIC, D.I MASTORAKIS.Software testingprocess management by applying six sigma[C].WSEAS Joint Con-ference program, MATH 2004, IMCCAS 2004, ISA 2004andSOSM 2004, Miami, Florida, USA, April 21-23, 2004.

[7] MUTSUMI KOMURO.Experiences of applying SPC techniques to software development processes[C]. ICSE'06, May 20-28, 2006, Shanghai, China.

[8] JOAO W.CANGUSSU, RAYMOND A.DECARLO, ADITYA P.MATHUR.Monitoring the software test process using statistical process control: a logarithmic approach[C].ACM, 158-167, 2003.

[9] WATTS S.HUMPHREY.Introduction to the personal software Process[M]. ADDISON WESLEY, 1997.

软件过程模式 第8篇

一、GIS软件的概念

GIS软件全称地理信息系统 (Geographic Information System) , 它是一款能提供存储、显示、分析地理数据功能的软件, 主要包括数据管理、数据操作[1]。

从应用角度来说, GIS软件主要由硬件、数据、软件、人员和方法五部分组成, 其中影响GIS软件正常运转的因素是软件, 不同的软件系统对应不同的GIS软件。

二、软件工程常见模型

影响人们生活的软件工程模型主要有六种:瀑布模型、螺旋模型、增量模型、快速原型模型、迭代模型、V模型。

瀑布模型是一个软件开发构架, 其核心思想是按工序将问题化简, 便于软件在运转时分工协作, 是最早的软件工程模型, 应用范围广;而螺旋模型是一种演化软件开发过程模型, 它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控, 较瀑布模型的应用范围更窄;增量模型是一款融合了瀑布模型的基本成分和原型实现的迭代特征的模型, 它能评估软件的新特征和功能;快速原型模型能很快开发出软件系统的原型, 展现软件特定功能;而其他两种软件工程应用范围较小, 所以在GIS软件的过程模型选择中不予考虑。

三、软件工程下GIS软件的过程模型选择方法

3.1 增加开发过程的敏捷性

在软件工程开发中, 要发挥软件自身特点, 增加软件运行的灵活性。软件工程开发出来的目的就是为了更好地方便学习生活, 所以在研究过程中, 要注意“以人为本”, 从自身的实际需要出发。如学校举办职业技能大赛时, 要求确定一处食堂选址, 在参赛的时候, 我们就要结合软件工程和GIS技术, 用软件工程强大的计算功能, 计算出食堂占地面积, 用GIS软件确定在学校范围内最佳食堂位置, 在这个选址过程中, 就要结合自己学校的实际情况, 如果软件工程和GIS软件确定的最佳区域是教学楼区域, 就要更换食堂选址, 选择比较宽阔的其他位置, 在新确定的位置区域在用两种软件相结合计算出最佳位置。

增加开发过程的敏捷性, 大学生要发挥主观能动性, 根据学习实际需要调整软件工程的具体程序, 在研发过程中, 要发挥想象, 致力于创新型软件工程的开发, 用新颖的软件产品去影响GIS软件系统, 与生活有机结合。

3.2 传统软件模型在GIS软件中的应用

传统软件模型在GIS软件中的应用, 主要是指瀑布模型、螺旋模型和快速原型模型。因为瀑布模型要求GIS软件性能稳定、功能完整, 相对其他两种传统模型来说, 它对GIS软件的要求较高, 所以它在GIS软件过程模型选择中的应用范围较小, 瀑布模型的工作量巨大, 在运行过程中要求“零失误”, 一旦出现偏差, 就会使得软件工程整个系统瘫痪。 螺旋模型是最近几年才被开发出来的新模型, 适用于高风险的GIS软件过程模型。螺旋模型的开发成本较高, 对研究团队也有一定的要求。快速原型模型与螺旋模型正好相反, 它适用于低风险的GIS软件, 能很好地帮助开发团队节约资金, 能够改进GIS软件中不合理的系统, 能够实时掌控整个软件工程模式和GIS技术。传统软件工程模式都能较好的与GIS软件融合, 形成一种新的GIS技术过程模型, 只有根据自己实际的需要, 选择合适的过程模型, 才能更好地利用各项软件技术, 方便生活。

3.3 利用GIS过程软件建立对象模型

GIS软件收集空间数据的前提下, 利用软件工程, 对数据进行统一记录, 在软件结构中建立对象模型。在这种模型中, 要不断填充数据资料, 使GIS软件能具有各项清晰的服务功能, 如定位、计算等。如在学校教学楼发生了火灾, 需要立即救援, 如何安排最佳的人员撤离路线、配备合理的运输和灭火设施?在这个过程中, 需要我们马上建立软件工程中的对象模型, 计算教学楼火灾最严重的区域, 建立救灾模型, 用GIS软件进行定位, 安排最恰当的施救人员和救火方案, 确保老师和学生生命财产安全。从这个实例中我们可以看出, 利用GIS软件建立对象模型的重要性。

对象模型非常适合GIS软件过程系统的开发, 加强对软件运行的控制, 增加项目开发结构, 加大对象模型在GIS软件中身亡应用程度。

结束语:随着我国经济不断发展, 软件工程开发与GIS软件过程模型相互融合交错, 慢慢建立起一种新的软件体系, 基于这种现状, 在学习生活中加强GIS软件过程模型的选择也越来越重要。不断完善软件工程与GIS软件的各项开发, 还需要大学生和软件工作者共同努力。

摘要：当代大学生要合理利用软件工程结合GIS软件, 创造出多层次的过程模型, 方便自己学习生活。本文通过介绍GIS软件的基本概念和软件工程的常见模型, 进而结合各类模型特点探讨了在软件工程的环境下的GIS软件具体选择方法。

关键词：软件工程,GIS软件,过程模型,方法

参考文献

[1]周艳萍, 张淑娟.云计算技术的GIS软件工程模式研究[J].电脑知识与技术, 2014, 01:207-208+218.