软件工程中文讲义9Word文件下载.docx
《软件工程中文讲义9Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件工程中文讲义9Word文件下载.docx（73页珍藏版）》请在冰豆网上搜索。
L.B.S.Raccoon使用了分级几何表示，用以讨论软件工程过程的本质。
所有的软件开发都可以看成是一个问题循环解决过程，如图9.3所示。
其中包括4个截然不同的阶段：
状态捕获、问题定义、技术开发和方案综合。
状态捕获表示了事物的当前状态；
问题定义标识了需要解决的特定问题；
技术开发利用某些技术来解决问题；
方案综合导出最终的结果（如文档、程序、数据、新的事务功能、新的产品）。
图9.3问题解决循环的各个阶段
以上的问题循环解决过程可以用于软件工程的不同开发级别上。
它可用于考虑整个应用系统的宏观级，也可用于建造程序构件的中间级，甚至还可用于源代码行级。
因此，可以用分级几何表示来给出过程的理想化的视图。
首先定义一个分级几何表示的模式，然后相继地在更小的规模上递归地应用分级几何表示：
模式中嵌套模式。
在图9.4中，问题循环解决过程的每一个阶段又包含一个同样的问题循环解决过程，该循环中每一个步骤中还可以再包含另一个问题循环解决过程。
这样一直继续下去，直到某个合理的边界为止。
对于软件来说，就是源代码行。
问题
定义
状态
捕获
技术
开发
方案
综合
状态捕获
图9.4问题循环解决过程中阶段嵌套阶段
实际上，想要如图9.4那样清楚地划分这些活动是很困难的，因为在阶段内部常常会出现一些交叉的任务，它们还可能会跨越阶段。
不过，这种简化的视图表达了一个重要的思想：
不管软件项目选择了什么样的过程模型，但所有阶段，包括状态捕获、问题定义、技术开发、方案综合，在某个细节级别上都同时存在。
由于给出了如图9.4所示的递归的性质，上述的4阶段论不但可用于整个应用的分析，而且同样地可用于某一代码段的生成。
（3）过程建造技术
为使得软件过程模型适合于软件项目组的使用，需要开发一些过程技术工具，以帮助软件开发组织分析它们当前的过程，组织工作任务，控制和监控进度，管理技术质量。
使用过程技术工具，可以建造一个自动模型，模型包含前面提到的公共过程框架、任务集合及保护伞活动。
该模型一般表示成一个网络，对其加以分析，就能够确定典型的工作流程，考察可能导致减少开发时间、降低开发成本的可选的过程结构。
一旦创建了一个可接受的过程，就可以使用其它过程技术工具来分配、监视、甚至控制在软件过程模型中定义的所有软件工程任务。
软件项目组的每一个成员都可以使用这样的工具来开发检查表，列出所有将要执行的工作任务、将要产生的工作产品和将要实施的软件质量保证活动。
过程技术工具还可用于协调适合某一特定工作任务的其它CASE工具的使用。
2、软件项目管理过程
软件项目管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理。
管理的对象是进度、系统规模及工作量估算、经费、组织机构和人员、风险、质量、作业和环境配置等。
软件项目管理所涉及的范围覆盖了整个软件生存期。
为使软件项目开发获得成功，一个关键问题是必须对软件开发项目的工作范围、可能遇到的风险、需要的资源（人、硬／软件）、要实现的任务、经历的里程碑、花费工作量（成本），以及进度的安排等等做到心中有数。
而软件项目管理可以提供这些信息。
通常，这种管理在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，并且只有当软件开发工作最后结束时才终止。
（1）启动一个软件项目
在制定软件项目计划之前，必须先明确项目的目标和范围、考虑候选的解决方案、标明技术和管理上的要求。
有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。
项目的目标标明了软件项目的目的但不涉及如何去达到这些目的。
范围标明了软件要实现的基本功能，并尽量以定量的方式界定这些功能。
候选的解决方案虽然涉及方案细节不多，但有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，给出诸如交付期限、预算、个人能力、技术界面及其它许多因素所构成的限制。
（2）制定项目计划
制定计划的任务包括：
§
估算所需要的人力（通常以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）。
作出进度安排，分配资源，建立项目组织及任用人员（包括人员的地位、作用、职责、规章制度等），根据规模和工作量估算分配任务。
进行风险分析，包括风险识别、风险估计、风险优化、风险驾驭策略、风险解决和风险监督。
这些步骤贯穿在软件工程过程中。
制定质量管理指标：
如何识别定义好的任务？
管理人员对结束时间如何掌握，并如何识别和监控关键路径以确保结束？
对进展如何度量？
以及如何建立分隔任务的里程碑。
编制预算和成本。
准备环境和基础设施等。
（3）计划的追踪和控制
一旦建立了进度安排，就可以开始着手追踪和控制活动。
由项目管理人员负责在过程执行时监督过程的实施，提供过程进展的内部报告，并按合同规定向需方提供外部报告。
对于在进度安排中标明的每一个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。
可对资源重新定向，对任务重新安排，或者（做为最坏的结果）可以修改交付日期以调整已经暴露的问题。
用这种方式可以较好地控制软件的开发。
（4）评审和评价计划的完成程度
项目管理人员应对计划完成程度进行评审，对项目进行评价。
并对计划和项目进行检查,使之在变更或完成后保持完整性和一致性。
（5）编写管理文档
项目管理人员根据合同确定软件开发过程是否完成。
如果完成，应从完整性方面检查项目完成的结果和记录，并把这些结果和记录编写成文档并存档。
3、软件生产率和质量的度量
（1）软件度量
对软件进行度量，是为了表明软件产品的质量，弄清软件开发人员的生产率，给出使用了新的软件工程方法和工具所得到的（在生产率和质量两方面）的效益，建立项目估算的“基线"
，帮助调整对新的工具和附加培训的要求。
软件度量分为两类：
直接度量：
软件工程过程的直接度量包括所投入的成本和工作量。
软件产品的直接度量包括产生的代码行数（LOC）、执行速度、存储量大小、在某种时间周期中所报告的差错数。
间接度量：
产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性。
图9.5软件度量
只要事先建立特定的度量规程，很容易做到直接度量开发软件所需要的成本和工作量、产生的代码行数等。
但是，软件的功能性、效率、可维护性等质量特性却很难用直接度量判明，只有通过间接度量才能推断。
我们可进一步将软件度量如图9.5所示那样分类。
软件生产率度量主要关注软件工程过程的结果；
软件质量度量则指明了软件适应明确和不明确的用户要求（软件使用合理性）到什么程度；
技术度量主要关注软件的一些特性（如逻辑复杂性、模块化程度）而不是软件开发的全过程。
从图9.5中还可以看到另一种分类方法：
面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息。
面向功能的度量提供直接度量的尺度。
面向人的度量则收集有关人们开发软件所用方式的信息和人们理解有关工具和方法的效率的信息。
（2）面向规模的度量
面向规模的度量是对软件和软件开发过程的直接度量。
首先需要建立一个如表9.1所示的面向规模的数据表格，记录过去几年完成的每一个软件项目和关于这些项目的相应面向规模的数据。
表9.1面向规模的度量
项目
工作量（人月）
元（千）
规模（KLOC）
文档页数
错误数
开发人数
aaa-01
24
168
12.1
365
29
3
ccc-04
62
440
27.2
1224
86
5
fff-03
43
314
17.5
1050
64
6
…
对于每一个项目，可以根据表格中列出的基本数据进行一些简单的面向规模的生产率和质量的度量。
例如，可以根据表9.1对所有的项目计算出平均值：
生产率＝KLOC／PM（人月）
成本＝元／LOC
质量＝错误数／KLOC
文档＝文档页数／KLOC
（3）面向功能的度量
面向功能的软件度量是对软件和软件开发过程的间接度量。
面向功能度量的关注点在于程序的“功能性”和“实用性”，而不是对LOC计数。
一种典型的生产率度量法叫做功能点度量，该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能点FPs（FunctionPoints）。
功能点通过填写表9.2所示的表格来计算。
首先确定五个信息域的特征，并在表格中相应位置给出计数。
信息域的值以如下方式定义：
用户输入数：
各个用户输入是面向不同应用的输入数据，对它们都要进行计数。
输入数据应有别于查询数据，它们应分别计数。
用户输出数：
各个用户输出是为用户提供的面向应用的输出信息，它们均应计数。
这里的输出是指报告，屏幕信息，错误信息等，在报告中的各数据项不应再分别计数。
用户查询数：
查询是一种联机输入，它导致软件以联机输出的方式生成某种即时的响应。
每一个不同的查询都要计数。
文件数：
每一个逻辑主文件都应计数。
这里的逻辑主文件，是指逻辑上的一组数据，它们可以是一个大的数据库的一部分，也可以是一个单独的文件
外部接口数：
对所有被用来将信息传送到另一个系统中的机器可读写的接口（即磁带或磁盘上的数据文件）均应计数。
计数
表9.2功能点度量的计算
信息域参数
加权因数
简单
中间
复杂
用户输入数
□□□
4
=
用户输出数
7
用户查询数
文件数
10
15
外部接口数
加权计数
总计数
一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值。
使用功能点方法的机构要自行拟定一些准则以确定一个特定项是简单的、平均的还是复杂的。
计算功能点，使用如下的关系式：
FP＝总计数×
〔0.65＋0.01×
SUM（Fi）〕（9.1）
其中，总计数是由表9.2所得到的所有加权计数项的和；
Fi（i=1到14）是复杂性校正值，它们应通过逐一回答表9.3所提问题来确定。
SUM（Fi）是求和函数。
上述等式中的常数和应用于信息域计数的加权因数可经验地确定。
一旦计算出功能点，就可以仿照LOC的方式度量软件的生产率、质量和其它属性：
生产率＝FP／PM（人月）
成本＝元／FP
质量＝错误数／FP
文档＝文档页数／FP
表9.3计算功能点的校正值
评定每个校正因素的尺度是0―5
012345
没有影响偶然的适中的普通的重要的极重要的
Fi
1
系统是否需要可靠的备份和恢复？
2
是否需要数据通信？
是否有分布式处理的功能？
性能是否是关键？
系统是否将运行在现有的高度实用化的操作环境中？
系统是否要求联机数据项？
联机数据项是否要求建立在多重窗口显示或操作上的输入事务？
8
是否联机地更新主文件？
9
输入、输出、文件、查询是否复杂？
内部处理过程是否复杂？
11
程序代码是否要设计成可复用的？
12
设计中是否包含变换和安装？
13
系统是否要设计成多种安装形式以安装在不同的机构中？
14
应用系统是否要设计成便于修改和易于用户使用？
功能点度量是为了商用信息系统应用而设计的。
Jones将其扩充，使这种度量可以被用于系统和工程软件应用，称之为特征点FPs（FeaturePoints）。
特征点度量适合于算法复杂性高的应用。
实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，适于特征点度量。
为了计算特征点，可以象上面描述的那样，对信息域值进行计数和加权。
此外，需要对一个新的软件特征“算法”进行计数。
可定义算法为“在一个特定计算机程序内所包含的一个有界的计算问题。
”如矩阵求逆、二进位串转换为十进制数、处理一个中断等都是算法。
计算特征点可使用如表9.4所示的表格。
对于每一个度量参数只使用一个权值，并且使用等式（9.1）来计算总的特征点值。
表9.4特征点度量的计算
权值
算法
必须注意，特征点与功能点表示的是同一件事：
由软件提供的“功能性”或“实用性”。
事实上，对于传统的工程计算或信息系统应用，两种度量会得出相同的FP值。
在较复杂的实时系统中，特征点计数常常比只用功能点确定的计数高出20％到35％。
（4）软件质量的度量
质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。
在软件交付之前得到的度量提供了一个定量的根据，以做出设计和测试质量好坏的判断。
这一类度量包括程序复杂性、有效的模块性和总的程序规模。
在软件交付之后的度量则把注意力集中于还未发现的差错数和系统的可维护性方面。
特别要强调的是，软件质量的售后度量可向管理者和技术人员表明软件工程过程的有效性达到什么程度。
虽然已经有许多软件质量的度量方法，但事后度量使用得最广泛。
它包括正确性、可维护性、完整性和可使用性。
Gilb提出了它们的定义和度量。
①正确性：
一个程序必须正确地运行，而且还要为它的用户提供某些输出。
正确性要求软件执行所要求的功能。
对于正确性，最一般的度量是每千代码行（KLOC）的差错数，其中将差错定义为已被证实是不符合需求的缺陷。
差错在程序交付用户普遍使用后由程序的用户报告，按标准的时间周期（典型情况是1年）进行计数。
②可维护性：
包括当程序中发现错误时，要能够很容易地修正它；
当程序的环境发生变化时，要能够很容易地适应之；
当用户希望变更需求时，要能够很容易地增强它。
还没有一种方法可以直接度量可维护性，因此必须采取间接度量。
有一种简单的面向时间的度量，叫做平均变更等待时间MTTC（MeanTimeToChange）。
这个时间包括开始分析变更要求、设计合适的修改、实现变更并测试它、以及把这种变更发送给所有的用户。
一般地，一个可维护的程序与那些不可维护的程序相比，应有较低的MTTC（对于相同类型的变更）。
③完整性：
这个属性度量一个系统抗拒对它的安全性攻击（事故的和人为的）的能力。
软件的所有三个成分：
程序、数据和文档都会遭到攻击。
为了度量完整性，需要定义两个附加的属性：
危险性和安全性。
危险性是特定类型的攻击将在一给定时间内发生的概率，它可以被估计或从经验数据中导出。
安全性是排除特定类型攻击的概率，它也可以被估计或从经验数据中导出。
一个系统的完整性可定义为：
完整性＝∑（1－危险性×
（1－安全性））
其中，对每一个攻击的危险性和安全性都进行累加。
④可使用性：
即用户友好性。
如果一个程序不具有“用户友好性”，即使它所执行的功能很有价值，也常常会失败。
可使用性力图量化“用户友好性”，并依据以下四个特征进行度量：
为学习系统所需要的体力上的和智力上的技能；
为达到适度有效使用系统所需要的时间；
当软件被某些人适度有效地使用时所度量的在生产率方面的净增值；
用户角度对系统的主观评价（可以通过问题调查表得到）。
4、软件项目的估算
在做软件估算时往往存在某些不确定性，这将使得软件项目管理人员无法正常进行管理。
因为估算是所有其它项目计划活动的基石，且项目计划又为软件工程过程提供了工作方向，所以我们不能没有计划就开始着手开发，否则将会陷入盲目性。
（1）估算
估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。
估算本身带有风险。
增加风险的各种因素如图9.6所示。
图中的轴线表示被估算项目的特征。
图9.6估算与风险
项目的复杂性对于增加软件估算的不确定性影响很大。
复杂性越高，估算的风险就越高。
但是，复杂性是相对度量，它与项目参加人员的经验有关。
例如，一个实时系统的开发，对于过去仅做过批处理应用项目的软件开发组来说是非常复杂的，但对于一个过去开发过许多高速过程控制软件的软件小组来说可能就是很容易的了。
此外，这种度量一般用在设计或编码级，而在软件计划时（设计和代码存在之前）使用就很困难。
因此，可以在计划过程的早期建立其它较为主观的复杂性评估，如功能点复杂性校正因素。
项目的规模对于软件估算的精确性和功效影响也比较大。
因为随着软件规模的扩大，软件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法──问题分解会变得更加困难。
由此可知，项目的规模越大，开发工作量越大，估算的风险越高。
项目的结构化程度也影响项目估算的风险。
所谓结构性是指功能分解的简便性和处理信息的层次性。
结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。
历史信息的有效性也影响估算的风险。
回顾过去，就能够仿效做过的事，且改进出现问题的地方。
在对过去的项目进行综合的软件度量之后，就可以借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。
风险靠对不确定性程度定量地进行估算来度量，此外，如果对软件项目的作用范围还不十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。
计划人员应当要求在软件系统的规格说明中给出完备的功能、性能、接口的定义。
更重要的是，计划人员和用户都应认识到经常改变软件需求意味着在成本和进度上的不稳定性。
（2）软件的范围
软件项目计划第一项活动就是确定软件的范围。
应当从管理角度和技术角度出发，确定明确的和可理解的项目范围，明确地给出定量的数据（如同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等），指明约束条件和限制（如存储容量）。
此外还要叙述某些质量因素（如给出的算法是否容易理解、是否使用高级语言等）。
软件范围包括功能、性能、限制、接口和可靠性。
在估算开始之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节。
由于成本和进度的估算都与功能有关，因此常常采用某种程度的功能分解。
性能的考虑包括处理和响应时间的需求。
约束条件则标识外部硬件、可用存储或其它现有系统对软件的限制。
功能、性能和约束必须在一起进行评价。
当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。
功能、性能和约束是密切联系在一起的。
软件与其它系统元素是相互作用的。
计划人员要考虑每个接口的性质和复杂性，以确定对开发资源、成本和进度的影响。
接口的概念可解释为：
运行软件的硬件（如处理机与外设）及间接受软件控制的设备（如机器、显示器）；
必须与新软件链接的现有的软件（如数据库存取例程、子程序包、操作系统）；
通过终端或其它输入／输出设备使用该软件的人；
该软件运行前后的一系列操作过程。
对于每一种情况，都必须清楚地了解通过接口的信息转换。
软件范围最不明确的方面就是可靠性的讨论。
软件可靠性的度量已经存在，但它们在项目的这个阶段难得用上。
因此，可以按照软件的一般性质规定一些具体的要求以保证它的可靠性。
（3）软件开发中的资源
软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。
图9.7把软件开发所需的资源画成一个金字塔，在塔的底部有现成的用以支持软件开发的工具──硬件及软件工具，在塔的高层是最基本的资源──人。
通常，对每一种资源，应说明4个特性：
资源的描述，资源的有效性说明，资源在何时开始需要，使用资源的持续时间。
最后两个特性统称为时间窗口。
对每一个特定的时间窗口，在开始使用它之前就应说明它的有效性。
图9.7软件开发所需的资源
①人力资源
在考虑各种软件开发资源时，人是最重要的资源。
在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要。
计划人员根据范围估算，选择为完成开发工作所需要的技能。
并在组织状况（如管理人员、高级软件工程师等）和专业（如通信、数据库、微机等）两方面做出安排。
对于一些规模较小的项目（1个人年或者更少），只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤。
对一些规模较大的项目，在整个软件生存期中，各种人员的参与情况是不一样的。
图9.8画出了各类不同的人员随开发工作的进展在软件工程各个阶段的参与情况的典型曲线。
图9.8管理人员与技术人员的参与情况
一个软件项目所需要的人数只能在对开发的工作量做出估算之后才能决定。
②硬件资源
硬件是作为软件开发项目的一种工具而投入的，可考虑三种硬件资源：
宿主机（Hostmachine）──软件开发时使用的计算机及外围设备；
目标机（Targetmachine）──运行已开发成功软件的计算机及外围设备；
其它硬件设备──专用软件开发时需要的特殊硬件资源；
宿主机连同必要的软件工具构成一个软件开发系统。
通常这样的开发系统能够支持多种用户的需
升级会员 