-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path习题答案.txt
244 lines (200 loc) · 23.8 KB
/
习题答案.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
一、术语(29道)
1. 软件生存周期
软件生存周期(software life cycle)又称为软件生命期,生存期。是指从形成开发软件概念起,所开发的软件使用以后,直到失去使用价值消亡为止的整个过程。一般来说,整个生存周期包括计划(定义)、开发、运行(维护)三个时期,每一个时期又划分为若干阶段。每个阶段有明确的任务,这样使规模大、结构复杂和管理复杂的软件开发变得容易控制和管理。
SDLC的六个阶段:1. 定义及规划2.需求分析3. 软件设计4.程序编码5.软件测试6.运行维护
2. 项目
项目是指一系列独特的、复杂的并相互关联的活动,这些活动有着一个明确的目标或目的,必须在特定的时间、预算、资源限定内,依据规范完成。项目是为创造独特的产品、服务或成果而进行的临时性工作。
项目参数包括项目范围、质量、成本、时间、资源。
3. 里程碑
在制定项目进度计划时,在进度时间表上设立一些重要的时间检查点,这样一来,就可以在项目执行过程中利用这些重要的时间检查点来对项目的进程进行检查和控制。这些重要的时间检查点被称作项目的里程碑(Milestone)。
4. 软件度量
软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程,目的在于对此加以理解、预测、评估、控制和改善。
5. 功能点分析
功能点分析方法是最重要也是最有效的软件测量规模方法,它可以在项目早期就对软件项目进行测量,并在开发过程中不断地更新数据,从而实现一种持续一致的管理。从应用方面看,全球已经有成千上万个项目采用了功能点分析方法。从研究方面来看,功能点分析方法也已成为很多其他新型测量方法的基础。
功能点分析是项目工作量估算的一种常用方法,可用7个步骤概括:1.确定功能点计算的类型;2.确定计算范围和应用程序边界;3.确定所有数据功能及其复杂性;4.确定所有事务功能及其复杂性;5.得出未调整功能点计数;6得出基于系统基本特征的值调整因子;7.计算已调整功能点计数。
6. 工作分解结构(WBS)
WBS是项目管理重要的专业术语之一。WBS的基本定义 :以可交付成果为导向对项目要素进行的分组,它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中,还是在PMP,IPMP考试中,工作分解结构(WBS)都是最重要的内容之一。WBS总是处于计划过程的中心,也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。
7. 软件质量
软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。具体地说,软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的和隐含特征相一致的程度。 影响软件质量的主要因素,这些因素是从管理角度对软件质量的度量。可划分为三组,分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险(产品运行);可理解性、可维修性、灵活性、可测试性(产品修改);可移植性、可再用性、互运行性(产品转移)。
8. RMMM 计划(Risk Mitigation, Monitoring and Management Plan)
软件项目风险管理是软件项目管理的重要内容。在进行软件项目风险管理时,要辩识风险,评估它们出现的概率及产生的影响,然后建立一个规划来管理风险。风险管理的主要目标是预防风险。
软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现,如果项目风险变成现实,就有可能影响项目的进度,增加项目的成本,甚至使软件项目不能实现。如果对项目进行风险管理,就可以最大限度的减少风险的发生。
9. COCOMO 模型
结构性成本模型。它是由巴里·勃姆(Barry Boehm)提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式,本质上说是一种参数化的项目估算方法,参数建模是把项目的某些特征作为参数,通过建立一个数字模型预测项目成本(类似于居住面积作为参数计算的整体的住房成本)。
10. 项目计划评审技术
计划评审技术就是工程项目当作一种系统,用网络图或者表格或者矩阵来表示各项具体工作的先后顺序和相互关系,以时间为中心,找出从开工到完工所需要时间的最长路线,并围绕关键路线对系统进行统筹规划,合理安排以及对各项工作的完成进度进行严密的控制,以达到用最少的时间和资源消耗来完成系统预定目标的一种计划与控制方法。
11. 软件质量模型
一个软件的质量往往涉及到许多不同的质量属性,不同类型的软件所关注的质量属性也不尽相同。因此, 为了更好地理解、预测和评价软件和信息系统的质量, 人们建立了各种质量模型, 在软件生命周期的不同阶段对软件质量进行评测。常用的通用软件质量模型主要包括层次模型和关系模型, 它们在当前的软件开发中起到了一定的积极作用。
12. 基于时间的缺陷到达模式
产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标,缺陷到达模式可以提供更多的过程信息,有时即使得到的整体缺陷率是一样的,但其质量差异可能较大,原因就是缺陷到达的模式不一样。越多的缺陷到达越早,则测试过程质量就越好。无论是从测试进展的观点,还是从用户重新发现(customer rediscoveries)的观点来看,缺陷的过程跟踪是非常重要的,开发周期里大量的严重缺陷将有可能阻止测试的进展,也必然直接影响软件产品的质量和性能。定性的分析比较容易,测试团队越成熟,峰值到达得越早,有时可以在第一周末或第二周就达到峰值。这个峰值的数值取决于代码质量、测试用例的设计质量和测试执行的策略、水平等,多数情况下,可以根据基线(或历史数据)推得。从一个峰值达到一个低而稳定的水平,需要长得多的时间,至少是达到峰值所用的时间的4-5倍。这个时间取决于峰值、缺陷移除效率等等。
在测试阶段初期,缺陷率增长很快。在达到峰值后,就随时间以较慢的速率下降,降低到最低点——零点。
13. 软件过程
软件过程为一个为建造高质量软件所需完成的任务的框架,即形成软件产品的一系列步骤,包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
(课件)
人们在开发和维护软件机器相关产品时所涉及的各种活动、方法、实践和改革等。其中软件相关产品包括软件项目计划、设计文档、程序代码、测试用例和用户手册等。
14. 软件基本过程
软件获取、供应、开发、运行和维护的过程,包括需求分析、软件设计、编码等过程。
15. 软件支持过程
包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程(测试过程)、评审过程等。
16. 软件组织过程
对软件主要过程和支持过程的组织保证过程,包括管理过程、基础设施过程、改进过程和培训过程。
17. 过程框架
通过在软件过程环境中定义软件过程架构、软件过程改进规划图、软件过程评估、软件过程改进计划四项框架活动来建立适用于目标软件项目的基本概念结构。
18. 软件能力成熟度模型
软件能力成熟度模型是一种对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述形成的标准。CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化、使企业能够更好地实现商业目标。
19. 统一过程
统一过程主要分五个阶段:开启阶段(inception),细化阶段(elaboration),构建阶段(construction),移交阶段(transition),生产(production)。Rational Unified Process 是 Rational 公司开发和维护的过程产品。Rational Unified Process 是软件工程的过程。它提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下,确保满足最终用户需求的高质量产品。
20. 过程模式
一系列用来面向对象软件的通用技术、行为或各种任务、过程模式的一个重要特性在于,它只描述了一个软件开发人员应该做什么,而没有确切地说明应该做哪些细节。当过程模式能够被有组织的应用在一起时,它们就可以被用来为软件开发改进机构生成软件过程。因为过程模式并没有指定如何完成一个给定的工作,它们能够成为可复用的积木。软件开发人员可以据此来定制一个满足软件开发机构的特定需求的软件过程。
21. 个体软件过程
PSP个人软件过程 (Personal Software Process,PSP) 是一种可用于控制、管理和改进个人工作方式的自我持续改进过程,是一个包括软件开发表格、指南和规程的结构化框架。PSP与具体的技术(程序设计语言、工具或者设计方法)相对独立,其原则能够应用到几乎任何的软件工程任务之中。PSP能够说明个体软件过程的原则; 帮助软件工程师作出准确的计划;确定软件工程师为改善产品质量要采取的步骤;建立度量个体软件过程改善的基准;确定过程的改变对软件工程师能力的影响。
22. 团队软件过程 TSP
团队软件过程是为开发软件产品的开发团队提供指导,TSP的早期实践侧重于帮助开发团队改善其质量和生产率,以使其更好的满足成本及进度的目标。TSP被设计为满足2~20人规模的开发团队,大型的多团队过程的TSP被设计为大约最多为150人左右的规模。
团队软件过程(TSP)加上PSP帮助高绩效的工程师在一个团队中工作,来开发有质量保证的软件产品,生产安全的软件产品,改进组织中的过程管理。通过TSP,一个组织能够建立起自我管理的团队来计划追踪他们的工作、建立目标,并拥有自己的过程和计划。这些团队可以是纯粹的软件开发团队,也可以是集成产品的团队,规模可以从3到20个工程师不等。TSP团队在广泛领域里可能运用XP, RUP或其它方法。TSP使具备PSP的工程人员组成的团队能够学习并取得成功。如果你的组织运用TSP,它会帮助您的组织建立一套成熟规范的工程实践,确保安全可靠的软件。
23. 过程规范
过程规范就是对输入/输出和活动所构成的过程进行明文规定或约定俗成的标准。软件过程规范是软件开发组织行动的准则与指南,可以依据上述各类过程的特点而建立相应的规范,如软件基本过程规范、软件支持过程规范和软件组织过程规范。
24. 过程模型
所谓软件过程模型就是一种开发策略,这种策略针对软件工程的各个阶段提供了一套范形,使工程的进展达到预期的目的。对一个软件的开发无论其大小,我们都需要选择一个合适的软件过程模型,这种选择基于项目和应用的性质、采用的方法、需要的控制,以及要交付的产品的特点。
常见的模型包括瀑布模型、螺旋模型、增量模型、迭代模型、V模型等。
25. 配置管理
配置管理(Configuration Management,CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
26. 配置项
配置项指纳入配置管理范畴的所有项目。凡是纳入配置管理范畴的工作成果都是配置项(CI);一个纯软件的CIs通常也称为软件配置(CSCIs)。配置项主要有两大类:属于产品组成部分的工作成果;项目管理和机构支撑过程产生的文档。
每个配置项的主要属性有:名称、标识符文件状态、版本、作者、日期等。
27. 基线
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。
28. 预防性维护
预防性维护是软件产品交付后进行的修改,以在软件产品中的潜在错误成为实际错误前,检测和更正它们。
29. 适应性维护
计算机领域的各个方面发展变化十分迅速,经常会出现新的系统或新的版本,外部设备及其他系统原件经常在改变,而应用软件的使用时间,往往比原先的系统环境使用时间更为长久,因此,常需对软件加以改造,使之适应于新的环境。为使软件产品在新的环境下仍能使用而进行的维护,称为适应性维护。
二、简答题(15道)
1. 试给出在 SEI 的 CMMI 模型中采用过程评估和改进方法的两个优点和两个缺点。
过程域的层次划分便于以渐进方式进行改进,这会更为有效和持久。
过程域的划分使过程改进活动中心更为突出,也更容易管理。
有限的范围可以提供更精深的细节,并为与项目有关的过程提供指导。
CMMI目标和共性实践的描述方式使其可以适用于很多类组织和项目。
CMMI提供了成熟度级别(阶段式表示法)和能力级别(连续式表示法)作为确定和评价在过程改进上所取得的进步的方法。
CMMI对量度特别重视,这有助于确定过程改进活动的投资回报。
模型的规模可能导致读者的信息过载,或者引发“麻痹”,或者引发“盲目实施实践”。
独立过程域的数目之多使人们难以清楚地识别和理解它们的关系。
在某些时候,组织可能会开发出反映了这些过程域而没有反映业务运作的过程结构。
模型的精细程度可能会被理解成鼓励在一些简单过程就已经足够的情况下开发复杂而详细的过程。
对与项目无关的企业职能的支持非常有限。
特定实践和解释性指导倾向于以适用于大规模开发的方式措辞,对“微小改进”和“非开发”项目的解释上只提供非常有限的指导。
目标的意义并非总能得到理解,这会导致CMMI本身变成一个目标而不再是推动改进的手段。
实现CMMI目标的时间安排可能与短期业务循环无法保持一致。
2. 考虑你所在机构中所用的软件过程类型。使用 SEI 模型找出了多少个关键过程域?根据该模型,你所在机构的过程成熟度等级如何划定?
3. 若过程改进中包括度量人在过程中的工作,并对过程进行彻底的变更,这样的项目是否是不人道的?对过程改进会发生哪些抵触行为?
4. 给出 SEI 的 CMMI 不能适用的两个领域,并说明理由。
5. 如何将现有的软件开发向敏捷开发方法转换?期间会遇到哪些困难,如何解决?
困难:开发人员已经习惯了原有的开发方法,不愿学习新的开发方法;公司的决策层不确定实施敏捷后能够真正提高团队的开发效率
6. 分析比较 CMMI、ISO15504 和 6sigma 之间的共同点和区别。
ISO15504与CMMI,都共同着眼于质量和过程管理,两者都为了解决同样的问题。从一方面说他们是相互联系、相互补充的。两者都吸收了现代质量管理理论,都以“过程思维”为指导。ISO15504中的质量要素都可以对应到CMMI中关键过程区域特征上,而CMMI在生产过程中的管理重点,又弥补了ISO15504在微观管理上的不足。但是它们的基础是有差异的:ISO15504确定一个质量体系的最少需求,而CMMI模型更在注重持续过程改进。而且,ISO15504只建立了一个可接受水平,而CMMI是一个具有五个水平的评估工具。所以,在建立企业标准时,可以综合考虑ISO15504和CMMI的质量管理要求,使两者都能更好的发挥各自的优势。
ISO15504和六西格玛之间无论经营观念、管理体系,还是管理决策,都不可替换,对于组织质量管理工作而言,所起的作用也是各有千秋。首先,ISO15504族标准为组织的质量管理工作提供了一个基础平台,而六西格玛管理法给组织的质量管理工作带来了一个新的、垂直的方法体系。其次,通过ISO15504认证只能证明该组织已经具备保证本组织生产或提供服务达到国际基本标准的能力,但能否长期保持,还需采用一些有效的质量管理方法,以确保组织质量得到持续改进。而六西格玛管理就是一种非常优秀的方法,可以说二者是互相补充的。
CMMI和六西格玛有许多相似之处,但也有重要的差别。首先,CMMI是一个只应用于软件过程的特殊的质量活动,而六西格玛是在整个公司上实现并用来改进所有过程的。在降低偏差、量化性能、改进过程方面,CMMI可以看作是六西格玛的一个子集。其次,由于六西格玛强烈的以客户为中心,更加强调协同工作和基于事实做决策,所以可以更好的保证处理问题的正确性。
7. 软件过程为什么必须进行改进?
(软工课件)
凡是活动,都存在过程;凡是过程,都存在改进;凡是改进,都没有终点。软件过程改进的必要性主要表现在以下几点:
经过一段时间后,过程的性能区域降低;
客户有越来愈高的需求;
组织的过程是逐步成熟的;
组织的目标可能是变化的;
组织的环境是不断变化的;
竞争对手在改进。
8. 软件工程中引入软件过程的作用和意义是什么?
软件过程是软件生存期中的一系列相关软件工程活动的集合。每个软件过程是由一组工作任务、项目里程碑、软件工程产品和交付物、质量保证点等组成。
软件过程是为了获得高质量软件所需要完成的一系列任务的框架,它规定了完成各项任务的工作步骤。软件过程的优劣决定了软件质量的高低,好的过程是高效高质量的前提。
9. 软件过程改进中如何管理变革?
伙伴策略:依赖于个人之间的关系;利用研讨会、午餐会和活动来宣布和讨论需要改变的事情以及如何改变。
政策策略:试图通过影响官方和非官方的领导人,使强大的组织结构发生变革‘寻找和说服那些最受尊敬、有众多支持者的人。
经济策略:相信金钱具有最好的说服力;基于假设-人们的原动力的经济刺激。
对抗策略:基于假设-如果能够唤起并调动起人们对当前问题的不满和愤怒,他们会愿意改变;更多地依赖于策略家的说服力,是人们感到现存的问题,但不提倡暴力。
学术策略:假设如果你提供给人们足够的信息和正确的事实,他们会接受变革;通常产生雇主、专家和咨询的委员会的研究报告。
工程策略:假设工作性质发生变化,许多人员不得不改变;对组织结构方面问题的强调,导致对环境很敏感。
军事策略:依赖于严酷的武力或无知;时常被军队、警察、学生政治压力集团、政党所用重点是学习在斗争中使用武器;需要力量和敏捷,遵守纪律将受到奖励。
10. 软件过程改进的框架的构成是什么?每个构成部分的作用是什么?
软件过程改进的框架包括软件过程基础设施、过程改进路线图、软件过程评估方法和软件过程改进计划。
每部分作用是:
(1)软件过程基础设施
它包含组织管理基础设施和技术基础设施,可为软件过程改进的活动提供必要的条件和支持。
(2)过程改进路线图
它应提供表明有效软件过程特征的模型,以及逐步达到有效软件过程的途径,软件组织依靠路线图的指引可以朝着有效软件过程前进。事实上,CMM(软件能力成熟度模型)和SPICE提供的成熟度等级都属于这种路线图。当然,软件组织从自身的实际情况出发对这些模型所作的裁剪版本,只要是适用的也应看成是过程改进路线图。
(3)软件过程评估方法
它是评估软件组织现行和现用的软件过程、做法和基础设施的方法和技术。评估通常要对照过程改进路线图,评估的结果要能表明,从提高过程有效性方面看哪些是强项,哪些是弱项。改进措施应能导致过程成熟度沿着改进路线图提高过程成熟度。过程评估方法可以是公开适用的标准方法,例如SEI评估方法即基于CMM估价的内部过程改进CBA—IPI(CMMfbased appraisal for internal process improvement)或BOOTSTARAP方法,也是按SPICE规定的准则进行内部评估。
(4)软件过程改进计划
评估后把发现的问题转化为软件过程改进的行动计划。这包括为改进过程基础设施以及提高其有效性必须采取的措施,过程改进应能使改进的过程规范化并提高过程的有效性。
11. 描述在软件设计过程中的主要活动以及这些活动的输出。使用一个实体--‐关系图(E--‐R 图),说明在这些活动输出之间可能存在的关系。
主要活动:体系结构设计、接口设计、组件设计、数据库设计。
活动输出:系统体系结构、接口描述、组件描述、数据库描述。
12. 论述度量在软件过程改进中作用。
13. 什么叫集成化过程改进?它的意义是什么?
在软件过程的各种现代版本中,为适应各组织的学科,创建了不同的过程改进模型,开发了多种语言。这种多样性对于沟通问题产生不利影响。而集成化过程改进就是用来改变这种情况;通过提供一种单一的语言,使多种学科能够共享过程改进活动并关注一个统一的过程改进目标。
意义:
1) 成本效益被理解,过程改进所获得的成本节省非常可观。相对于采用多个模型,一个连续改进的组织如果采用了公共模型,就可以减少以下费用:采用模型和评估方法所需的培训费用;在相同组织或人员执行各种评估需要的费用;在数据仓库中维护冗余数据的过程资产;维护或采用多种模型的专业知识。
2) 重点明确,集成化过程改进计划可以弄清楚各种活动的目的和商业目标。通过大范围的各种过程改进活动的集成,更容易把实践人员和主管的队伍团结在过程改进的目标下。有改进重点,能统一和加强思想,高效的安排和使用匮乏的资源,并为跨越不同学科的过程改进提供一种共同语言。特别是一个其有公共术语和公共评估方法的单一模型提供这类重点。
3) 过程集成,过程集成和精益组织。集成过程改进的一个不太明显的收益是它对组织产生的“集成”影响。当过程的定义跨越了组织和学科的边界时,通常会产生新的理解和相互学习,从而使关键工作统筹化,并消除了冗余的不必要的活动。“烟囱式”的过程改进通常假定组织的接口是有效的。在跨部门进行改进过程时,该组织可另外得到过程重构的效果。这种简化持精益概念,即努力消除产品中的浪费,为客户提供
4)灵活性,集成所带来的最后一个效益是适应和利用业务式工程环境变化的能力
14. 制定软件过程改进计划的流程是什么?解释其中的主要活动的作用和目的?
(1)过程分析
考察和理解现有的过程,在一些情况下需要对过程的某些环节进行度量和定量分析,利用取得的数据来表明过程的状况。同时,这些数据可以用来与过程改进后的状况进行对比。
(2)确定改进
利用过程分析的结果,找出原有过程中质量、进度和成本的瓶颈。针对发现的问题,制定过程改进方案,提出需要采用什么规程、方法和工具的建议。
(3)过程变更
实施过程变更,把新的规程、方法和工具安置于合适的过程环节上,并且与其他的软件过程活动集成起来。
(4)培训
没有培训的过程变更在大多数场合注定要失败。有的单位在培训工作不够充分的情况下,强制推行过程变更,这样做不会收到好的效果。
(5)调整过程变更
在初步实施过程变更后,不可能立即收到圆满的效果,在过程修改后还可能会出现一些小的问题,这就需要进行适当的调整。此外,同时引入太多的变更是不切实际的。
15. 简述 CMMI--‐DEV V1.3 中每一成熟度等级所包含的过程域。
(课件)
成熟度等级2(7个):需求管理、项目计划、项目监督和控制、供应合同管理、度量和分析、过程和产品质量管理、配置管理
成熟度等级3(11个):需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成化项目管理、风险管理、决策分析和解决方案
成熟度等级4(2个):组织级过程性能、项目定量管理
成熟度等级5(2个):组织级改革和实施、因果分析和解决方案
三、论述题(7道)
1. 在什么情况下产品质量可能决定于开发团队的质量?举例说明什么类型的软件产品特别依赖于个人的天赋和能力。
2. ISO 9001:2008 标准中的 PDCA 循环,又叫戴明环,是美国质量管理专家休哈特博士首先提出的,由戴明采纳、宣传,获得普及,从而也被称为 “戴明环” 。它是全面质量管理所应遵循的科学程序。论述它在评估软件项目质量管理中的作用和意义。
戴明环为企业实施质量改进提供了一个周期模型,这个模型影响着当前大部分质量与过程改进方法。作为一个通用模型,软件企业同样可以采用它作为质量过程改进的方法,通过对问题的定义,确定改进机会,建立改进计划和目标,根据问题产生的原因实施改进,在改进实施中收集数据进行分析评价,从而进行持续的改进。通过采用戴明环方法,软件企业可以指定自己的质量过程改进路径。
3. 结合 CMMI 的实施,论述软件过程改进过程中主要阶段的作用。
(1) 远景阶段:该阶段中设置与前进的方向,拼出了前进的道路。它考虑到了未来的发展和在技术、经济、政策、市场和商业方面的变化。
(2) 策略阶段:策略描绘出达到的远景的途径和达到远景目标必须经过的实践步骤。
(3) 调动阶段:团结一致的调动当前的人力和资源,设计并实现相应的行动计划。
(4) 推动阶段:保持推动力,监控策略的成就,强化同盟关系。
(5) 实现阶段: 实现已制定的策略,否则过程改进会成为一种幻想。软件过程改进本身也是一个改变的过程,也应该经历上面提到的类似阶段
4. 复用的关键障碍之一是使软件工程师考虑利用现有的构件,而不是重新开发新构件,请建议 3 到 4 种软件组织可以用来激励软件工程师进行复用的方式。为了支持复用,应该采用什么技术?
5. 论企业软件过程改进的实施。请围绕 “企业软件过程改进的实施” 论题,依次从以下四个方面进行论述:
(1)叙述软件过程改进实施的主要活动。
(2)概要叙述你参与实施的企业软件过程改进项目以及你所担任的主要工作。
(3)论述该企业实施软件过程改进项目中如何根据企业的实际情况采用模型标准以及实施的主要方法和步骤。
(4)具体阐述该企业在实施软件过程改进的活动中所发现并解决的主要问题和效果。
6. 在当今 “3C” 的环境下,持续的改进是企业生存发展的永恒主题,其运用的工具不是单一的。某企业拟针对“某项服务顾客投诉率高”进行改进,在不同的阶段可采用哪些工具。
过程流程工具在各个阶段划分活动,然后划分可操作的检查项,通过清晰的记录在实施软件过程中发生的所有活动及活动执行者严格管理软件过程。
过程文档工具为文档提供编写模板,可以依据文档模板进行裁剪,定制每个项目的过程文档。使软件企业内部的各个项目质检能遵照一个标准化的文档编写流程并对文档进行管理。
评审工具提供标准的评审规程,项目可对之裁剪,形成本项目的评审规程,软件人员可使用它来进行评审并记录评审情况。
人员管理工具对实施过程的人员进行管理,人员执行某项活动后记录人员的相关信息,明确各个阶段和活动的执行人和责任人,便于责任的分析和处理。
7. 根据下图,分析说明 CMMI--‐DEV V1.3 中,五个工程类过程域之间的互动关系。
“需求开发”过程域提供需求至“技术解决方案”过程域,在此处需求被转换为产品架构、产品组件设计与产品组件。需求也被提供给“产品集成”过程域,在此处产品组件被组合起来,接口得到验证,以确保其符合“需求开发”过程域所提供的接口需求。
“技术解决方案”过程域开发产品组件的技术数据包,用于“产品集成”过程域或“供方协议管理”过程域。备选解决方案被考察,并基于已建立的准则选择最优设计。这些准则可以因产品不同而有显著区别,这取决于产品类型、操作环境、性能需求、支持需求以及成本或交付进度。选择最终解决方案的工作会用到“决策分析与解决”过程域中的特定实践。
“技术解决方案”过程域依赖于“验证”过程域中的特定实践,以在设计过程中并在最后的构建之前,执行设计验证与同级评审。
“验证”过程域确保选定的工作产品满足规定的需求。“验证”过程域选择工作产品与验证方法,用于对照规定的需求对工作产品进行验证。一般来说验证是一个增量式的过程,从产品组件的验证开始,通常以对完全组装了的产品进行验证为结束。
“确认”过程域的范围包括对产品、产品组件、选定的中间工作产品与过程的确认。这些已确认的要素常常需要再次验证与再次确认。确认中发现的问题往往在“需求开发”过程域或“技术解决方案”过程域中得到解决。
“产品集成”过程域在实施产品集成过程时使用了“确认”过程域与“验证”过程域中的特定实践。“验证”过程域的实践在产品集成之前验证了产品组件的接口与接口需求。接口验证是集成过程中的必要事件。在操作环境中进行产品集成时,就要使用到“确认”过程域中的特定实践。
四、应用题(6道)
1. 如何将现有的软件开发向敏捷开发方法转换?期间会遇到哪些困难,如何解决?
2. 总结本企业的基本过程模型。
3. 本单位是否需要引入新的软件开发方法?分析原因并给出措施。
4. 软件生存期与软件项目的生命期有什么区别?
5. 你所在单位或项目组进行了哪些度量活动?你认为有需要改进的地方吗?
6. 当前企业的业务都是在全球化、快速变化的环境中运营,传统的软件开发过程无法适应由此产生的快速软件需求。20 世纪 90 年代后期,一些软件开发人员在 “Agile Alliance 2001” 中系统地阐述了敏捷开发的原则,试图强调灵活性在快速且有效地生产软件中所发挥的作用。目前众多的软件生产企事业已经在实际的软件开发过程中接纳并实践了敏捷开发方法中的基本原则。
问题 1:敏捷开发有许多典型方法,包括极限编程(eXtreme Programming)、Scrum、Crystal、DSDM 等。请问这些方法共同的基本原则是什么?
主张简单、拥抱变化、可持续性、递增的变化、令Stakeholder投资最大化、有目的的建模、多种模型、高质量的工作、快速反馈、软件是主要目标、轻装前进
问题 2:敏捷开发的支持者往往夸大该方法的优点,但是在实践中,敏捷方法的基本原则有时确实很难实施。请用 200 字以内的文字说明敏捷方法中哪些原则在实践中难以实施。
客户的参与度旺旺依赖于客户参与的意愿和客户本身的代表性
团队成员的性格可能不适合激励的投入,可能无法做到与其他成员之间做良好的沟通
对系统中的变更做出优先级排序可能是极端困难的
维护系统的简化需要额外的工作,但迫于移交时间表的压力往往没有时间执行系统简化过程
问题 3:敏捷开发方法中最有名的极限编程。请说明极限中的结对编程(Pair Programming)的概念。
结对编程是极限编程实践之一,是指两位程序员肩并肩坐在同一工作台前合作完成同一个设计、同一个算法或同一段代码,并且两人的角色可以随时互换。结对编程能提高软件开发效率,很多国外的软件企业都热衷于结对编程。结对程序员之间的交流非常充分,甚至可以不同言语进行交流,只要简单的描述加手势就可以。这种模式已证明非常成功
问题 4:敏捷开发方法在具体实践过程中,往往需要开发环境或工具支持,一般称为快速应用开发技术和可视化开发技术。请用 150 字以以内的文字说明快速应用开发技术所包含的工具有哪些,并简要说明可视化开发技术的基本概念和技术原理。
数据库编程语言、与办公应用的连接、界面生成器、报告生成器
可视化开发就是在可视开发工具提供的图形用户界面上,通过操作界面元素,诸如菜单、按钮、对话框、编辑框、单选框、复选框、列表框和滚动条等,由可视开发工具自动生成应用软件。主要思想是利用图形工具和可重用部件来交互的编制程序。可视化开发一般基于事件驱动的原理