（计算机应用技术专业论文）基于用例的软件开发的进度度量方法.pdf

摘要 在当今的软件开发中，软件产品不能按时交付已经成为一种常见现象， 造成这种现象出现的重要原因就是在软件开发过程中缺乏足够的开发进度的 相关信息，管理人员的决策缺少进度数据支持。论文在研究软件度量技术和 用例的基础上，提出种基于用例的进度度量方法，该度量方法通过度量以 用例为单位的各开发单元的进展来实现进度的度量，可以为项目的不同干系 人提供不同级别的进度相关信息。 估算是进度度量的基础，论文对用例点估算技术进行了一定的研究，然 后提出了两个扩展方法，一是使用模糊集理论扩展用倒复杂度权重因子表， 使权重因子能够更准确地反映事务数目的变化，从而使估算的结果更准确。 二是采用分解技术扩展用例点方法使之能够实现对单个用例的估算，支持论 文建立的进度度量方法。 论文建立的进度度量方法包括两个方面的核心内容：进度度量构造和实 例化度量构造的度量规程。 进度度量构造中的度量模型以相关人员提供的工作日志作为基础，按照 迭代式软件开发的特点计算进度；同时度量模型也考虑了项目开发过程中错 误和需求变更引发的工作量对进度的影响，从而使度量的进度更具有实际意 义。度量构造中的分析模型对项目的进度信息进行分析和比较，为项目管理 人员的决策提供数据支持。 进度度量规程定义了实施进度度量的基本过程、主要活动、参与角色及 收集和组织数据的机制。重点阐述与进度度量的数据收集相关的活动。 最后，论文结合实际案例对进度度量方法进行了分析和检验。 关键词进度度量，软件度量，软件估算，用例，用例点，迭代 ：= 一：圭鳖茎坠兰堡兰三：一= ：= ：= a b s t r a c t i nc u r r e n ts o f t w a r ed e v e l o p m e n t ，i th a sb e c o m eau s u a lp h e n o m e n o nt h a t s o f t w a r ep r o d u c tc a n tb ed e l i v e r e do nt i m e t h el a c ko fp r o g r e s si n f o r m a t i o ni s a ni m p o r t a n tc a u s e ，w h i c hr e s u l ti np o o rd a t as u p p o r ta b o u tp r o g r e s st om a n a g e r s t h i sp a p e rr e s e a r c h e ss o f t w a r e m e t r i c sa n du s ec a s e ，t h e nan e wm e t h o do f p r o g r e s sm e t r i c si sp r o p o s e d ，w h i c hg e tp r o g r e s si n f o r m a t i o nb ym e a s u r i n ge a c h d e v e l o p m e n tu n i tb a s e do nu s ec a s e ，a n dp r o v i d ep r o g r e s si n f o r m a t i o no n d i f f e r e n tl e v e lt od i f f e r e n tp r o j e c tr e l a t i v e e s t i m a t i o ni st h eb a s eo fp r o g r e s sm e t r i c s ，s ot h i sp a p e rr e s e a r c h e st h eu c p ( u s e c a s e p o i n t ) e s t i m a t i o nm e t h o df i r s t l y , t h e n t w oe x t e n s i o n so fu c pi s p r o p o s e d 。o n ee x t e n d su s ec a s ec o m p l e x i t yw e i g h tt a b l eu s i n gf u z z ys e t ，w h i c h m a k e sw e i g h tf a c t o rb ea b l et or e f l e c tt h ec h a n g eo fn u m b e ro ft r a n s a c t i o nm o r e p r e c i s e l y ；t h eo t h e rm a k e su c p c a ne s t i m a t eas i n g l eu s ec a s eb yd e c o m p o s i t i o n ， w h i c hc a np r o v i d ee s s e n t i a ls u p p o r tt ot h em e t r i c sm e t h o dt h ep a p e rp r o p o s e d t h em e t h o do fs o f t w a r ed e v e l o p m e n tp r o g r e s sm e t r i c sb a s e do nu s ec a s e t h i sp a p e rp r o p o s e dc o n s i s t so fp r o g r e s sm e a s u r e m e n tc o n s t r u c ta n dp r o g r e s s m e a s u r e m e n tp r o c e d u r e s t h em e a s u r e m e n tm o d a lo fm e a s u r e m e n tc o n s t r u c ti sb a s e do nt h ew o r k r e p o r t r e l a t i v ew o r k e rp r o v i d e d t h ep r o g r e s si sc a l c u l a t e da c c o r d i n gt ot h e i t e r a t i v es o f t w a r ed e v e l o p m e n ta n da l s oc o n s i d e r st h ei m p a c to fe f f o r tc a u s e db y r e q u i r e m e n tc h a n g ea n de r r o ro fd e v e l o p m e n t ，w h i c hm a k e st h ep r o g r e s sm o r e p r a c t i c a l t h ea n a l y s i sm o d a lo fm e a s u r e m e n tc o n s t r u c ta n a l y s e sp r o g r e s sa n d c o m p a r e i tw i t hp l a n ，w h i c hp r o v i d ed a t as u p p o r tt ot h ed e c i s i o no fm a n a g e r t h ep r o g r e s sm e a s u r e m e n tp r o c e d u r e sd e f i n et h eb a s i cp r o c e s s ，m a j o r a c t i v i t i e s ，r e l a t i v ea c t o r sa n dm e c h a n i s mo fd a t ac o l l e c t i o na n ds t r u c t u r e ，w h i c h i sn e c e s s a r yt op u tm e a s u r e m e n tc o n s t r u c ti np r a c t i c e f i n a l l y , s e v e r a le x a m p l e si nw h i c ht h em e a s u r e m e n tm e t h o di s i n t r o d u c e d a r ea n a l y z e da n dd i s c u s s e d k e y w o r d s p r o g r e s sm e t r i c s ，s o f t w a r em e t r i c s ，s o f t w a r ee s t i m a t i o n ，u s e c a s e ，u s ec a s ep o i n t ，i t e r a t i o n 1 1 第1 章绪论 1 1 课题的提出背景及意义 出于技术进步，在广泛的应用领域内不断地对更大型的、更健壮的和更 可靠的软件提出更多的需求，相应地对软件项目管理的需求也在增长。对于 软件项目管理的实际状况，很多机构进行了调查和统计。 美国专门从事跟踪i t 项目的权威机构s t a n d i s hg r o u pf 斯坦迪什集 团) 对2 3 0 0 0 个项目进行了研究，结果表明：存在6 6 的项目超出 了时问，5 5 的项目超出了预算，项目平均用掉了计划时间的 2 2 0 “。 美国项目管理学会( p m i ) 的一项统计数据表明，4 3 的i t 项目完 成后超出预算，6 2 的i t 项目超期完成“j 。 由此可见软件项目的超期、超支已经成为了一个很普遍的现象，这给软 件开发人员和产品使用者的工作都带来了很大影响，也造成了相当的经济损 失。造成这种现象的重要原因之一，就足在项目开发过程中对项目的实际进 度没有足够的信息，只是依靠模糊的估计，日积月累的进度偏差最终导致 了项目的超期、超支。 软件度量本身并不能解决这些蜘题，但是它可以澄清并聚焦于你对这些 问题的理解。进一步说，当对产品和过程的属性进行有序度量后，可以为项 目管理和过程改进活动提供一个有效的基础。在项目开发的过程中通过对项 目进度的度量获取项目的进展情况，可以帮助我们尽早发现问题，进而采取 有效措施确保实现目标。 本论文的课题提出正是基于这一背景，e t 的是通过对软件度量技术和目 前广泛使用的用例驱动的软件开发进行研究，提出一个基于用例的软件开发 的进度度量方法，帮助项目团队在项目开发过程中获得准确的项目进展数据 从而评估项目进展，尽早发现问题，采取有效手段，保证项目的最终成功。 = = = = = = = = = = = = = ：= ：型! 薹奎塑圭兰堡兰圣= ：= ：= ： ：。：= ：! ：= ： 1 2 论文研究的主要工作 图l 一1 论文研究工作结构圈 在面向对象的分析和设计中，用例已经是一种被软件开发人员广泛使用 的技术，用于捕获和描述软件系统的功能需求。用例是一个简单、显而易见 的想法，并且用例定义了产品的功能需求和框架，因此以用例及用例模型为 基础进行进度度量是论文的一个目标。 在实现基于用例的软件开发的进度度量中，首先要完成对用倒的规模和 工作量的估算，准确的估算是成功的进度度量的基础。因此论文需要对目前 基于用例模型的估算技术进行一定的研究，研究估算技术的目的主要有两 个，一个是使基于用例的估算更准确、更合理，另一个目的就是使目前基于 用例模型的估算能够支持论文所提出的进度度量方法。 传统上，组织项目的方法是使其按顺序( 一次且仅一次) 完成每个工作 流程。这就产生了瀑布式生命周期，这通常会导致在随后的实施阶段( 当第 一次构建产品并开始测试时) 出现集成“堆积”。在整个分析、设计和实施阶 段隐藏下来的问题会在这时暴露出来：并且，随着较长调试周期的开始，项 目的进度会逐渐停顿下来。为使项目继续进行，一种较灵活( 并且风险更 小) 的方法是多次执行各个开发工作流程，从而更好地理解需求、设计出强 壮的构架、组建好开发组织并最终交付渐趋完善的实施成果，这被称为迭代 式生命周期。论文需要对迭代式生命周期进行一定的研究使提出的进度度量 方法适应迭代式生命周期模型。 论文的进度度量方法包括两个方面的内容：进度度量构造和进度度量规 程，度量构造是用来将对于进度信息的需要与可度量概念联系起来的详细结 构，度量构造构建的重点是度量函数和分析模型；度量规程定义了收集和组 织数据的机制，要求按此数据来实例化一个度量构造。在度量的描述方面， 论文采用了p s m ( p r a c t i c a ls o f t w a r em e a s u r e m e m ) 的规定，需要对p s m 进行 一定程度的研究。 论文所建立的进度度量方法使用了几个项目组的实际数据进行了应用和 检验，对于在实际案例中的表现及评价，我们也进行了一定范围以内的跟踪 与研究。 总之，沦文的主要工作和研究成果在于，通过研究用例、软件估算和软 件度量技术，对用例点估算方法进行一定程度的改进和扩展，使之能够支持 论文所提出的进度度量方法，同时使估算结果更准确。在扩展的用例点估算 的基础上，提出一种基于用例的进度度量方法，包括进度度量构造和度量规 程，最后通过实际案例对进度度量方法进行了检验。 1 2 1 扩展的用例点方法 扩展的用例点方法主要包括两个方面的内容： 采用模糊集理论扩展用例点估算方法中的权重表，使权重表能更准 确地反映事务数目的变化。 采用分解执行者的方法扩展用例点估算方法，使其能够估算单个用 例的规模和工作量。 论文对用例点方法的扩展将使估算的结果更能反映实际情况，同时对单 个用例的估算将在项目进度计划的制定以及进度度量方面具有重要作用。 1 2 2 进度度量构造 进度度量构造是将进度信息需要与可度量概念联系起来的详细结构，本 文通过度量各用例的工作单元的进展来实现对进度的度量。进度度量构造是 进度度量的中枢，在进度度量构造这一章里重点介绍了度量函数和分析模 上海师范大学硕士学位论文 型，用度量函数计算进度时考虑需求变更和错误引发工作量对进度的影响， 使度量的进度更具有实际意义；分析模型分析进度时为项目的不同干系人提 供不同的指示器，满足不同的干系人对项目进度的信息需要。 1 2 3 进度度量规程 度量规程定义了收集和组织数据的机制，要求按此数据来实例化一个度 量构造，本文的度量规程建立了实例化度量构造的基本规程，定义了实施进 度度量的基本过程、主要活动、参与角色及相关的支持环境。重点阐述与进 度度量的数据收集相关的活动。 1 2 4 案例研究 对论文的进度度量方法在几个项目中的使用情况进行跟踪，重点讨论了 进度度量方法和扩展的用例点估算方法在m h s o a 办公自动化系统中的应 用状况和应用效果，通过案例的研究来检验进度度量方法的有效性并发现存 在的问题。 1 3 论文的组织 论文的组织共分为八章。 第1 章：绪论。阐述了论文的研究背景以及论文的主要研究工作。 第2 章：基于用例的软件估算研究。对基于用例的软件估算技术进行研 究。 第3 章：软件度量研究。研究迭代式软件开发生命周期模型、软件度 量、进度度量的研究现状等 第4 章：扩展的用例点估算算法。扩展目前的用例点估算算法使之既能 够进行项目整体规模、工作量的估算r t l 够进行单个用例的规模和工作量的 估算。 第5 章：进度度量构造。介绍了论文建立的度量构造，重点是度量函数 和分析模型。 第6 章：进度度量规程。进度度量规程定义了实施进度度量的基本过 程、主要活动、参与角色及收集和组织数据的机制，重点阐述与进度度量的 数据收集相关的活动。 第7 章：案例研究。结合实际案例对进度度量方法的应用进行了分析和 检验。 第8 章：总结。对论文的总结以及对进一步研究的展望。 上海师范大学硕士学位论文 第2 章基于用例的软件估算研究 2 1 引言 本章主要对用例和基于用例的软件估算技术进行研究，包括两个方面 用例和基于用例的软件估算技术，重点研究用例点估算技术。 2 2 用例概述 2 2 1 用例的发展现状 用例( u s ec a s e ) 的概念是由j a c o b s o n 3 1 ，在1 9 9 2 年首次提出。发展到现 在主要形成了两个学派，一个是以u s ec a s e 之父j a c o b s o n 为代表的 r a t i o n a l 学派。该学派认为用例( u s ec a s e ) 的概念是“与系统进行对话时行 为相关的事务系列的描述。r u p ( r a t i o n a lu n i f i e dp r o c e s s ) 4 1 中关于用例的定 义是“一系列带变量的动作描述，系统由此对特定用户产生有价值的可见结 果。”一个用例要求有一个量化的结果，从单个线索的需要提交。做为量化 结果的组成，目标要么成功要么失败，没有其它的情况。用例具有前置条件 和后置条件。另一个学派是以a l i s t a i rc o c k b u m 为代表，该学派认为用例 ( u s ec a s e ) 的概念是“代表系统中各个项目相关人员之间就系统的行为所达 成的契约”。提出请求的项目相关人员被称为主执行者( p r i m a r ya c t o r ) 。系统 对任一执行者所做出的响应，要保证所有项目相关人员的利益不受侵犯。根 据执行者做出的请求和请求涉及的条件，系统将执行不同的行为序列，每一 行为序列称之为一个场景，一个用例是多个不同场景的集合，这种模型被认 为是应用最成功的模型。 用例模型包括主角、用例以及它们之间的关系。主角代表了必须与系统 交换信息的所有事物，包括通常所谓的用户。当主角使用系统的时候，系统 执行一个用例。好的用例是一个事务序列，该序列为主角提供一个可评测的 价值结果，用例集合是系统的完整功能。 第2 章基于甩例的软件估算研究 2 2 2 用例技术在需求获取中的应用现状 2 2 2 1 概念模型 a l i s t a i rc o c k b u r n 在2 0 0 1 年提出了需求分析中的利益模型( i n t e r e s t ) f 5 j 以及项目相关人员f s t a k e h o l d e r ) 模型，c o c k b u m 的利益和项目相关人员模型 如下： 用例( u s ec a s e l ：代表系统中各个项目相关人员之间就系统的行为 所达成的契约。用例描述了在不同的条件下，系统对某一项目相关 人员的请求所做出的响应。 项目相关人员( s t a k e h o l d e r ) ：指契约的参与者，是对用例的行为具 有特定利益的人或物。 2 2 2 2 用例的表示方法 执行者( a c t o r ) ：任何具有行为的人或物。 项目相关人员( s t a k e h o l d e r ) ：对被讨论系统的行为有特定兴趣的人 物。 主执行者( p r i m a r ya c t o r ) ：启动与被讨论系统的一次交互活动，从而 达到某目标的人或物。 用8 0 ( u s ec a s e ) ：规定被讨论系统行为的契约。 范围( s c o p e ) ：界定被讨论的系统。 前置条件和保h ：( p r e c o n d i t i o na n dg u a r a n t e e ) ：在用例执行之前和执 行后必须满足的条件。 主成功场景f m a i ns h c c e s ss c e n a r i o ) ：一切顺利的情况。 扩展( e x t e n s i o a ) ：场景执行过程中出现的不同情况。 扩展中的编号：在主成功场景中不同情况发生时所处的执行步骤号 码。 2 2 2 3 用例的粒度 用例的粒度问题是自从用例技术出现以来至今一直困扰大家的一个问 题。大家都在追求一种形式化的或者是原则性的东西来确定用例的粒度侧。 这方面的资料非常少。国外的m a r kc o l l i n s c o p e 提出了一种使用r s i 的方 式来控制用例的粒度的方法。该方法将用例分为需求用例( r e q u i r e m e n t ) 、服 务用例f s e r v i c e ) 和接口用例( i n t e r f a c e ) - - - 类。 需求用例( r e q u i r e m e n t ) 主要描述商业过程，需求用例的细节驱动系 统的整个开发过程，但是并不定义系统的功能。 上海师范大学硕士学位论文 服务用例( s en r i c e ) 详细的描述了独立于任何接口的系统需要实现的 功能 接口用例( i n t e r f a c e ) 负责把需求用例和服务用例连接起来。 2 3 软件估算技术 2 3 1 软件估算概述 软件估算是软件项目开发的一种活动，其目的就是通过对软件项目的规 模、工作量、进度、关键计算机资源进行科学地预测，从而对项目开发做出 严肃、合理的承诺，指导软件开发的整个过程。 2 3 2 软件估算内容 软件项目估算是一种预测技术，它试图预测软件项目各项工作任务所需 要的工作时间、成本以及完成各项任务的跨度时间( 进度) 。软件项目估算根 据估算对象的不同，一般可以分为对软件产品规模的估算、对软件项目工作 量和成本的估算、对软件项目进度的估算、对项目的关键计算机资源的估算 和对软件风险的估计等几个方面。 2 3 3 软件估算的现状 从目前的研究和应用来看，软件估算技术主要包括：基于模型的估算技 术、专家判定技术、面向学习的估算技术、回归技术、合成技术。 基于模型的估算技术具有使用方便、适用面广的优点，但是，模型是用 过去的经验数据来校准，在没有经验数据的情况下这些方法会比较困难。专 家判定估算技术以专家的经验为基础，而且人为的判断比较灵活，缺点是受 估算者的个人经验影响较大。面向学习的估算技术对过去的和现在的经验知 识进行学习的基础上对新项目做出估算，与基于模型的估算技术相似，依赖 经验数据。回归分析技术是用于创建经验模型并校准经验模型的流行技术， 具有简单和使用方便等特点。许多现有的成本估算模型( 如c o c o m oi i 、 s l i m 等1 都使用了回归分析技术。合成技术是将两个或两个以上的技术结 合起来以得到更准确的估算结果，它同时具备各技术的优点，因此应用较广 泛。 矍! 茎重三里型墼墼丝篁兰至垒 ； 总之，国内外软件项目的管理目前正逐步向规范化发展，软件佶算也是 如此。除专家经验估算方法外，估算是可以量化的，并非依据个人经验直接 得出一个结果，在结果的评审上可以有据可依，并且可以将大量项目的数据 和估算结果积累形成历史经验库，项目数据得以保存，便于组织开发利用。 2 3 4 用例点估算方法 捕捉软件项目的功能需求时，常使用用例模型。用例建模是一项业界广 泛使用的技术，用于描述和捕捉软件系统的功能需求。既然用例和场景技术 己成为需求采集和分析的标准部分，并且它们捕捉了用户需求的精确描述， 那么，基于用例和场景，而不是诸如功能点和代码行等其他技术，进行开发规 模和资源的估算工作，是很有意义的。基于用例的估算的另一个优点是，通 过使用现代需求管理工具，可维护其双向可跟踪能力。可以在用例和多种软 件工程工件之间，维护这种双向可跟踪能力，包括设计、编码、测试、配置 管理、架构和部署等相关的工件。 用例点方法( u s ec a s ep o i n tm e t h o d ) 1 6 1 是g u s t a vk a r n e r 在1 9 9 3 年提出的 在面向对象开发方法中基于用例去估算项目的规模及工作量的一种方法，这 种方法是对f p a 及m k i i f p a 方法上的改进，但又与f p a 有着本质的不 同。这种方法的基本思想是利用己经识别出的用例和执行者，根据他们的复 杂度分类，计算用例点，然后利用用例点和工作量的换算，得到项目开发所 需的以人小时数为单位的工作量。由于用例是基于使用的和以用户为中心 的，而不是面向系统或面向设计的，因而它比功能点和代码行方法有更高的 健壮性和稳定性。 k a r n e r 的用例点方法的主要步骤是，首先，将用例模型中的角色按照 简单、一般和复杂三个等级来分类，并统计每类角色的数量，分别乘以各自 的权重系数( w e i g h t i n gf a c t o r ) ，然后相加，得出总的“未调整角色权重 ( u n a d j u s t e da c t o r w e i g h t ，u a w ) ”。然后，依据用例中的事务数量( 包括备 选流中的交易) ，将用例按照简单、一般和复杂三个等级来分类，并按如下 步骤计算未调整用例权重( u n a d j u s t e du s ec a s ew e i g h t s ，u u c w ) ：统计每类 用例的数量，分别乘以各自的权重系数，然后把这些乘积相加。最后，将 u a w 和u u c w 相加，得到未调整用例点( u n a d j u s t e du s ec a s ep o i n t s ， u u c p ) 。接下来，基于技术系数和环境系数调整用例点的值。每个系数是 介于o 到5 之间的一个值，具体由它们对整个项目的假定影响来确定，得到 上海师范大学硕士学应论文 已调整用例点( u s ec a s ep o i n t s ， u c p ) 。最终，u c p 要乘以一个代表生产 力的历史数据的系数，比如，每个用例点2 0 人时( p e r s o nh o u r ) ，得到项目 估算结果完成项目所需的人时总数。图2 - 1 浣明了使用用例点方法的主 要步骤。 用例 图2 1 用例点估算步骤 1 ) 计算总的未调整执行者权重a w ) 。 。 执行者( a c t o r ) 是指任何与系统直接进行交互的、具有行为的事物。根据 执行者与系统之间交互的复杂度，将其分为简单，中等，复杂三个类别，并 对每一个类别分配一个权重因子如表2 1执行者复杂度权重因子分配表所 不a 执行者类型判断规则 权重因子 简单 一个己定义好应用程序接口( a p i ) 的外部系统 1 中等 需要通过某种通信协议f 如t c p i p ) 与之交互的 2 系统：或者通过终端和系统交互的人 复杂通过图形界面或者w e b 页与应用程序进行交 3 互的人 表2 - 1 执行者复杂度权重因子分配表 项目的未调整执行者的权重( u a w ) n 用下面的式计算得到： 第2 章基于用例的软件估算研究 总的未调整活动者权重= 善相应类别的活动者数量+ 权重因子 2 1 计算未调整用例权重( u u c w ) 根据用例场景中所描述的事务数来判断。事务定义为一系列的任务的原 子集，这些任务要么一起完全执行，要么一起均不执行。这种分类的基础是 用例中的事务数，包括扩展场景中的事务也必须计算在内。根据事务复杂度 分类的规则表如表2 - 2 所示。 用例的类型判断规则权重因子 简单事务的数目小于等于3 5 中等事务的数目在4 到7 之间 1 0 i 复杂复杂事务的数目多于或等于7 个 1 5 表2 - 2 根据事务分类的用例复杂度权重因子表 项目的未调整用例权重( u u c w ) 利用下面的式子计算得到： 总的未调整用例权重( u u c w ) = v 相应类别的用例数量- 权重因子 锑 3 1 计算未调整用例点( u u c p ) 将未调整用例权重( u u c w ) 和未调整执行者权重( u a w ) 相加，即可得到 未调整用例点u u c p ，计算如下式： u u c p = u a w + u u c w 4 ) 计算技术复杂度仃c f ) 用例描述的仅仅是行为( 功能) 需求。然而规模估算时，不能仅考虑功能 需求，非功能性需求以及项目风险对于项目规模的影响也是很大的，忽略了 它们，会造成严重的低估。因此进行规模估算时，必须将非功能需求和风险 同时考虑进来。在用例点估算方法，k a m e r 以功能点分析方法为原型，提出 了技术复杂度因素，用来体现项目的非功能性需求对项目的影响，技术因素 表中所包含的1 3 个因素中的分布式系统，可移植性、并发性、易用性、安 全性等都属于非功能需求。 具体信息如表： l 因子l 描述l 权重i 相关性 上海师范大学硕士学位论文 t 1 分布式系统 2 5 t 2 响应或者吞吐量绩效目标 2 4 t 3 终端用户效率( 联机) 1 3 t 4 复杂的内部处理 13 t 5 代码必须是可重用的 14 t 6 易于安装 0 54 t 7 易于使用 0 55 t 8 可移值 12 t 9 易于变更 14 t 1 0 并发性 1 4 t 1 1 包括特殊的安全特征 2 5 t 1 2 提供对第三方的直接访问性 13 t 1 3 特殊的用户培训设施 1l 袭2 - 3 技术因子权重表 利用上表可以计算t f a c t o r ： 低c t o r - 。著彤+ r 技术复杂度t c f 的计算如下式： t c f = 0 6 + f 0 0 1 + t f a c t o r ) k a r n e r 提出的这1 3 个技术因素来源于功能点方法，所以用例点中的技 术因素和功能点中的技术因素有些类似。表中的因素的权重用于说明估算人 员所指定的参数的技术难度是多少。而因素相关度，说明每一个因素对于项 目影响的程度。一般来说，不需要去改变因素的权重，而只需改变相关度的 值，用于来说明这些特定的因素对于项目的影响相关程度。比如：o ：表示 无任何影响，3 ：表示具有中等程度的影响度，5 ：表示影响极大。 5 ) 计算环境复杂度( e f ) 用例点方法比功能点方法多一个环境因素列表，主要目的是利用项目所 存在的风险来调整软件的规模。大部分因素来自于项目组背景、项目及项目 组所存在的风险等会对估算结果产生影响的因素。例如：采用具有丰富的应 用程序开发经验的人员完成任务的时间会远远少于只有一点经验或没有经验 的新员工。环境因子见表 l 因子 描述权重 相关性 f 1 r u p 的熟练掌握程度 13 至：耋董三里型墼竺丝篁苎丝塞 f 2 应用程序开发经验 0 55 f 3 面向对象开发经验 1 55 f 4 先导分析人员能力 0 5 4 f 5 积极性 l 3 f 6 稳定的需求 25 f 7 兼职工作人员 1 1 f 8 编程语言的难度 1 52 表2 - 4 环境园子权重表 利用上表可以计算e f a c t o r ： e f a c t o r = 2 艺彬+ r 环境因素( e f ) ，如：e f = i 4 + ( 一0 0 3 + e f a c t o r ) 因素的权重和相关性与技术因素的权重和相关性相似，这里不再做重复 阐述。 6 1 计算调整用例点( u c p ) 利用t c f 和e f 对未调整用例点的影响重新进行估算可得到调整用例 点，如：u c p = u u c p + t c f e f 7 ) 规模与工作量的换算 用例点方法在1 9 9 3 年k a m e r 最初提出时，建议每个用例点的工作量为 2 0 人时，而r i b u 在k a r n e r 的研究基础之上，认为这个工作量应该是在1 5 至3 0 个人时之间【7 1 。s c h n i d e r 和w i n t e r s 在1 9 9 8 年提出了一种计算工作量 的方法，利用已经设定的环境复杂度因素来推测，在e 1 一e 6 中的值超过3 的因素个数加上e 7 e 8 中低于因素3 的个数，如果其总和小于等于2 ，则每 用例点需2 0 人时，如果总和在3 _ 4 之间，则需要2 8 人时，如果总和大于 4 ，则说明有太多的环境因素对于项目的影响重大，需要重新调整项目组的 构成。规模和工作量的换算如下式： 工作量( 人时) = 用例点数+ 每用例点工作量( 人时) 2 3 5 基于用例的估算的其它技术研究 基于用例的估算还有其他方法，其中一种是使用用例模型作为统计功能 点的手段，然后再进一步获得工作量的估算值【8 】；还有一种方法是，将用例 上海师范大学硕t 学位论文 模型用作估算代码行数的手段，然后再进一步获得工作量的估算值( a n d a 2 0 0 1 ) 。上述两种方法试图利用业界广泛应用的基于功能点和代码行的估算 方法。前一种方法中，尽管用例的概念和功能点的很多概念近似，但并不完 全等价，所以转换的规则比较复杂，并不能很好地得到运用。后者将用例向 代码行转换，这要求和特定的语言绑定，造成了它的局限性，不利于不同语 言实现的项目间进行比较，这同样具有代码行方法的缺点。 昌量! 量圣竺璧兰至彗 3 1 引言 第3 章软件度量研究 论文提出的进度度量方法是指在采用迭代式生命周期模型的软件开发 中，以用例为单位进行软件开发的进度度量，所以需要对迭代式生命周期模 型、度量技术以及目前的进度度量现状进行研究。 3 2 迭代式生命周期模型 3 2 1 传统开发流程的问题 传统的软件开发流程是一个文档驱动的流程，它将整个软件开发过程划 分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务( 文档) 后 才能够进入下一个阶段。 图3 - 1 传统的开发流程一瀑布模型 随着我们所开发的软件项目越来越复杂，传统的瀑布型开发流程不断地 暴露出以下问题： 需求或设计中的错误往往只有到了项目后期才能够被发现。 对于项目风险的控制能力较弱项目风险在项目开发较晚的时候才能 够真正降低。 软件项目常常延期完成或开发费用超出预算项目开发进度往往会被 ：= ：= ：一：童些茎堡丝塞圣= = 一一：= 。：= ： 意外发生的问题所打乱。 3 2 2 采用迭代式开发控制项目风险 为了解决传统软件开发流程中的问题，我们可以采用迭代化的开发方法 来取代瀑布模型。在瀑布模型中，需要完成的是整个软件系统开发这个大目 标。在迭代化的方法中，将整个项目的开发目标划分为一些更易于完成和达 到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。迭代 就是为了完成一定的阶段性目标而所从事的一系列开发活动，在每个迭代开 始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个 迭代过程包含了需求、设计、实施( 编码) 、部署、测试等各种类型的开发 活动，迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定 下一次迭代的目标。 图3 - 2 迭代式软件开发 与传统的瀑布式开发模型相比较，迭代化开发具有以下特点： 允许变更需求 逐步集成元素 尽早降低风险 保证项目开发进度 3 3 软件度量概述 度量是指在现实的世界中，把数字或符号指定给实体的某一属性，以便 以这种方式根据己明确的规则来描述它们。 第3 章软件度量研究 同其他工程技术活动一样，软件工程活动中同样需要度量，而且由于软 件产品的特殊性，度量的地位更加重要且更具挑战性。在软件开发的历史 中，二十世纪6 0 年代末期大型软件所面临的软件危机直接反映的是软件产 品质量和开发周期无法控制的问题，而更深一步反映出的则是软件管理中的 问题。对于管理层人员来说，没有对软件开发过程的可见度就无法管理；同 时对看到的事物如果没有适当的度量或适当的准则去判断、评估和决策，也 无法进行优秀的管理。我们说软件工程的方法论主要任务之就是在提供可 见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科，这就需 要使用度量。在软件工程活动中，度量贯穿于开发周期的各个阶段：管理者 需要预测和检查开发不同阶段的费用、进度，找出是什么原因影响了费用和 进度；软件工程师定制度量以监视不断演进的系统，检查系统设计的正确 性，用严格的度量术语来规范编码，指定对软件质量和性能的要求，使得这 些要求是可测试的，以及度量当前已存在的产品属性以便预测将来的产品等 等。 最早在1 9 5 8 年r u b e y 和h u r t w i c k 提出了软件度量学，希望用软件度量 学的方法来科学地评价软件质量，更有力她对软件开发过程进行控制和管 理，合理地组织和分配资源，制定切实可行的软件开发计划，以低成本获得 高质量软件。1 9 7 0 年h a l s t e a d 提出了软件科学( s o f t w a r es c i e n c e ) 的概念，他 认为任何一门学科要成为科学，必须理论和实践结合，而软件度量学正是反 映了这种结合的学科。b o e h m 于1 9 7 6 年提出，对软件属性不能仅有定性的 研究，还必须有定量的研究，软件度量学正是顺应这种趋势而产生的，现在 软件度量学已成为软件工程的一个研究方向。 3 4 度量术语定义 在软件度量的描述方面，本文采用p s m ( p r a c t i c a ls o f t w a r em e a s u r e m e n t ) 的规定，p s m 中定义的术语来自国际标准i s o i e c ( 即“软件度量过程”) 中的度量信息模型i 引。在阐述本论文的进度度量方法之前将首先描述一些关 键术语。 为生成项目度量产品，图3 3 概括地描述了信息需要是如何演化成为度 量计划的。度量策划应首先标识：管理人员或工程师为支持制定项目决策所 需的一个具体的信息需要。从操作意义上来讲，项目决策通常都与项目策 划和执行相关，但是也可以从战略和组织级的需求开始。一些有助于满足 已定义的信息需要的数据可以通过度量许多不同的软件过程元素和产品特 征来获得。这些过程元素和产品特性称为软件实体( s o f t w a r ee n t i t y ) 。可度 量概念是关于实体的概念，即为了满足一个信息需要而度量的一些实体。 例如，一个分配给某一软件任务的经费和资源的决策者都相信：生产率是 与将要执行的软件任务的类型相关的。因此，生产率就是用于处理己定义 的信息需要的可度量概念。确定生产率要求度量诸如软件产品和过程那样的 实体。有许多方法可用于计算生产率，在这个层次上，生产率仍仅仅是一 个可度量概念。最后，可度量概念可以形式化为一种度量构造，它严格地 指定了要度量什么以及如何对数据进行合并以产生满足信息需要的结果。在 这个示例中，两个可应用的度量是软件规模和工作量。度量规程定义了收 集和组织数据的机制，要求按此数据来实例化一个度量构造。 信息需要、度量构造和度量规程组合合成一个度量计划。度量计划的 执行产生了响应项目信息需要的信息产品。信息产品作为度量过程的输出， 是提供给决策制定者的指示器、解释和建议的集合。 p s m 定义了7 个通用的信息分类以及相应的度量映射，具体参见表 3 - 1 。 3 4 1 度量构造 图3 - 3 信息需要演化成度量计划的过程 度量构造是将用来满足指定的信息需要的可度量事物联系起来的详细结 构，度量构造是度量过程的中枢。图3 - 4 亥1 i n 了度量构造的基本结构，实际 度量的对象包括软件过程和产品的特定属性，如规模、工作量和缺陷数。度 量构造描述了相关软件属性是如何量化并转化成提供决策制定基础的指示器 的。一个单一的度量构造可以包括三个度量类型或层次：基本度量、派生度 一一董：耋竺堡垒兰塑圣 量和指示器。 ：辨。 璃 幽3 - 4 度量构造的细节 以下将简单描述图3 4 中的度量构造的构件。 3 4 1 1 属性( 可度量的) 可度量的属性是个软件实体的可区别的特性或者特征，一个实体可以 有很多属性，只有一部分是适合于度量的。 3 4 1 2 基本度量 基本度量是由一个指定的度量方法定义的对单个属性的度量。执行度量 的方法产生一个度量的值。度量方法的类型依赖于用来量化特定属性的操作 的自然特性，方法的类型有两种：主观方法和客观方法 3 4 1 3 派生度量 派生度量是一种度量或数量，它被定义成两个或多个基本度量或派生度 量的一个函数，派生度量获取多于一个属性的信息。度量函数是一种执行两 个或多个基本度量或派生度量值的合并的算法或计算。 3 4 1 4 指示器 指示器是提供指定属性的估计或评价的度量，该属性是从涉及已定义的 信息需要的分析模型中派生。指示器是度量分析和决策制定的基础，因此指 示器是要提供给度量用户的。分析模型是一个具有相关决策准则的包括两个 蓊燮 一 、， 磊 一 ，漕 上海师范大学硕士学位论文 或多个基本度量或派生度量的算法和计算。分析模型产生与已定义的信息需 要相关的评价。决策准则是一些数字阀值、目标或界限，用于确定行动或 进一步调查的需要，决策准则帮助解释度量结果。决策准则可以源自历史数 据、计划或直观判断。 3 5 度量信息分类 面向对象软件工程中并没有给出一个标准的度量集合( 只给出了度量定 义的标准) ，因此有必要定义一个标准度量集合以便于分析。d u m k e l l 0 1 认为 由于在面向对象的软件开发环境中软件度量直接与“过程”、“产品”、“资 源”这三大组件相关，因此他把软件度量主要分为三种：“过程度量”、“产 品度量”、“资源度量”三种。而p s m ( 实用软件度量) 将软件度量的信息分为 七大类，具体分类信息如表3 - 1 所示。 信息分类可度量概念预期度量 进度和进甓完成的里程碑里程碑同期 羡键路径的性能缓冲时间 工作单元的进展已跟踪的需求 已测试的需求 已打丌的问题报告 已关闭的问题报眚 已完成的评审 已打开的变更请求 已解决的变更请求 已设计的单元 己编码的单元 试图执行的测试用例 己通过的测试用例 尚末解决的行动项 已完成的行动项 增量式能力已集成的构件 已集成的功能 资源和费用个人工作量员工水平 开发【：作量 经验水平 员_ l 说明 ，至! 耋竺丝堡苎至塞 财务性能b c w s，b c w p， a c w p 预算 费用 环境和支持资源需要的数量 可用的数量 可用的时间 已用的时间 产品规模和稳定性 物理规模和稳定性数据库规模 构件 接口 代码行 功能规模和稳定性需求 功能变更 功能点 产品质量功能正确性缺陷 缺陷的延续时间 技术性能水平 可维护性恢复的时间 圈复杂度 效率 利用率 吞吐量 响应时间 可移植性些标准间的依从性 可用性操作员错误 可靠性