软件工程实施的几个重要思想文档格式.docx
- 文档编号:21564381
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:27
- 大小:50.02KB
软件工程实施的几个重要思想文档格式.docx
《软件工程实施的几个重要思想文档格式.docx》由会员分享,可在线阅读,更多相关《软件工程实施的几个重要思想文档格式.docx(27页珍藏版)》请在冰豆网上搜索。
6.12参照图6-4所示的风险参考水平值,该曲线是否总是如图显示的
那么匀称光滑,或者是否会有该曲线扭曲变形的情况存在?
如果有,请举出一个例子。
6.13做一些关于软件安全方面的研究,并写一份简单的报告。
可以参考
[LEV95]做为起点。
6.14描述五个软件安全和危险分析是主要关心对象的软件应用领域。
第7章项目进度安排及跟踪
在六十年代后期,一位热情的青年工程师①受命为一个自动制造应用软件项目“编写”计算机程序。
选择他的原因非常简单,因为在整个技术小组中他是唯一参加过计算机编程培训班的人。
这位工程师对汇编语言的IN和OUT指令以及Fortran语言略知一二,但是却根本不懂软件工程,更不用说项目进度安排和跟踪了。
他的老板给了他一大堆相关的手册,以及需要做些什么的口头描述。
年轻人被告知该项目必须在两个月之内完成。
他阅读了这些手册,想好了解决方法,就开始编写代码。
两周之后,老板将他叫到办公室询问项目进展情况。
“非常好,”工程师以年轻人的热情回答道,“这个项目远比我想象的简单。
我差不多已经完成了75%的任务。
”
老板笑了,说道:
“真是太棒了。
”然后他嘱咐年轻人继续努力工作,准备好一周后再汇报一次工作进度。
一周之后老板将年轻人叫到办公室,问他说:
“现在进度如何?
”“一切顺利,”年轻人回答说,“但是我遇到了一些小麻烦。
我会排除
这些困难,很快就可以回到正轨上来。
“你觉得在最后期限之前能否完成?
”老板问道。
“没有问题,”工程师答道。
“我差不多已经完成了90%。
”如果读者在软件领域中工作过几年,你一定可以将这个故事写完。
毫不
奇怪,青年工程师在整个项目工期内始终停留在90%的进度上,(在别人的
帮助下)直到交付期限之后一个月才做完。
在过去的30年间,这样的故事被不同的软件开发者重复了成千上万次。
我们不禁要问:
“为什么?
7.1基本概念
虽然软件延期交付的原因很多,但是大多数都可以追溯到下面列出的一个或多个根本原因上:
·
一个不现实的截止期限,由软件工程组以外的人所设立并强加给软件
工程组内的管理者和项目开发者。
客户需求发生变化,而需求的变化没有能够反映在项目进度的变化上。
对工作量和/或完成该工作所需的资源数量估计不足。
在项目开始时,没有将可以预测的和/或不可预测的风险考虑在内。
事先无法预计的技术困难。
事先无法预计的人力困难。
由于项目组成员之间的交流不畅而导致的延期。
项目管理者未能发现进度拖后,也未能采取行动解决这一问题。
在软件行业中,人们对过于乐观的(即“不现实的”)项目完成期限已经
司空见惯。
有时候设定截止时间的人认为这样的截止期限是合理的,但是常识告诉我们,合理与否还必须由完成工作的人来判断。
①这个故事是我的自传。
7.1.1关于“延迟”的评注
拿破仑曾经说过:
“任何同意执行一个他本人都认为有缺点的计划的指挥官都应该受到指责;
他必须提出自己的反对理由,坚持修改这一计划,最终甚至提出辞职而不是使自己的军队遭受惨败。
”这句话掷地有声,值得软件项目管理者们深思。
在第5和第6章中讨论的估算和风险分析活动,以及本章中涉及的进度安排技术,通常都需要在一个定义好的截止期限的约束之下实现。
如果最乐观的估算都表明截止期限是不现实的,一个胜任的项目管理者就应该“保护其队伍免受不适当的进度安排的压力并将这种压力反映给施加压力的一方”
[PAG85]。
不妨举例说明,假定一个软件开发小组的任务是构造一个医疗诊断仪器
的实时控制器,该控制器需要在9个月之内推向市场。
在进行了仔细的估算和风险分析之后,软件项目管理者得到的结论是在现有人员条件下,需要14个月的时间才能完成这一软件。
这位项目管理者下一步该怎么办?
闯进客户的办公室(这里的客户非常可能是市场或销售人员)并要求修改交付日期似乎不太现实。
外部市场压力决定了交付日期,届时必须发布产品。
而(从事业前途的角度出发)拒绝这一项目同样是鲁莽的。
那么应该怎么办呢?
在这种情况下,推荐以下的处理步骤:
1.使用从以前的项目中得到的数据,进行详细的估算。
确定项目的估算工作量和持续时间。
2.使用增量过程模型(参见第2章),制定一个软件开发策略,以能够在
规定的交付日期提供关键功能,而将其他功能的实现推到以后。
将这一计划做成文档。
3.与客户会谈并(用详细估算结果)来解释为什么规定的交付日期是不现
实的,一定要指出所有这些估算都是基于以往的项目实践,而且一定要指出为了在目前规定的交付期限完成项目,与以往相比在工作效率上必须提高的百分比①。
做如下解释将是恰如其分的:
“我认为在XYZ控制器软件的交付日期方面存在一个问题,我已经将一
份以往项目中生产率的简化明细分类表和以多种不同方式进行的项目估算提交给各位,你会注意到我已经假设与以往的生产率相比有20%的提高,但是我们仍然只能得到14个月而不是9个月的交付时间。
4.将增量开发策略作为可选计划提交给客户。
“我们有几个选择,而我希望各位能够在这些选择的基础上做出决策。
首先,我们可以增加预算,并引入额外的资源,以便使我们能够在9个月时间内完成这一工作。
但是应该知道由于时间限制过于苛刻,这样做将会增加质量差的风险②。
第二个方案是,去掉一部分需求中所列出的软件功能和特性。
由此得到功能稍弱的产品的最初版本,但是我们可以对外宣布全部功能,
①如果提高的百分比为10%到25%,则实际上是有可能如期完成这一项目的。
但更有可能的是,所需的队
伍效率的提高百分比要高于50%。
这是不切实际的期望。
②你还可以补充说,增加更多的人手不会成比例的缩短完成项目所需的时间。
并在总共14个月的时间内发布这些功能。
第三种选择是不顾现实条件的约束,而希望项目能够在9个月时间内完成。
结果是我们竭尽全力,但是却无法向用户提供任何功能。
我想你们会同意,第三种选择是不可接受的。
过去的历史和我们最乐观的估算都表明这是不现实的,是在选择一场灾难。
尽管这样做会有些抱怨,但如果你给出了基于准确的历史数据的可靠估算,那么最终的谈判结果将可能是选择1或者选择2。
不现实的交付期限就不存在了。
7.1.2基本原则
曾经有人请教著名的《神秘的人月》(TheMythicalMan-Month,见文献[BRO95])一书的作者FredBrooks,“软件项目的进度是如何延迟的?
”他的回答即简单又深刻:
“一天一次。
技术性项目(不论它是涉及到水力发电厂建设,还是开发一个操作系统)的现实情况是,在实现一个大目标之前必须完成数以百计的小任务。
这些任务中有些是处于主流之外,其实现不会影响到整个项目的完成时间;
其他任务则位于“关键路径”①之上,如果这些“关键”任务的进度拖后,则整个项目的完成日期就会受到威胁。
项目管理者的目标是定义所有项目任务,识别关键任务,然后跟踪关键
任务的进展以保证“一天一次”的发现进度拖延情况。
为了做到这一点,管理者必须建立一个具有一定详细程度的进度表,使得项目管理者能够监督进度,并控制整个项目。
软件项目进度安排是一种活动,它通过将工作量分配给特定的软件工程
任务,而将所估算的工作量分布于计划好的项目持续时间内。
但是,进度是随着时间的改变而不断演化的,注意到这一点至关重要。
在项目计划的早期,首先建立一个宏观的进度安排表。
该进度表标识所有主要的软件工程活动和这些活动影响到的产品功能。
随着项目的进展,宏观进度表中的每个条目都被精化成一个“详细进度表”。
于是(完成一个活动所必须实现的)特定软件任务被标识出来,并进行进度安排。
可以从两个不同的视角考察软件开发项目的进度安排。
第一个视角,基
于计算机的系统的最终发布日期已经确定(而且不能更改)。
软件开发组织在这一约束下将工作量分布在预先确定的时间框架内。
第二个视角,假定大致的时间界限已经讨论过,但是最终发布日期是由软件开发组设定的,工作量以一种能够最好地利用资源的方式加以分布,且在对软件进行仔细分析之后才定义最终发布日期。
但不幸的是,第一种情况发生的频率远远高于第二种情况。
同软件工程的所有其他领域一样,有一些基本原则能够指导软件项目的进度安排:
划分:
项目必须被划分成若干可以管理的活动和任务。
为了实现项目的划分,对产品和过程都需要进行分解(参见第3章)。
相互依赖性:
各个被划分的活动或任务之间的相互关系必须是确定的。
有些任务必须顺序发生;
而其他的则可以并发进行。
有些活动只有在其他活
①在本章中后面将详细讨论“关键路径”。
动产生的工作产品完成时才能够开始,而其他的则可以独立进行。
时间分配:
必须为每个被调度的任务分配一定数量的工作单位(例如,若干人天的工作量)。
此外,必须为每个任务指定开始和结束日期,这些日期是与工作完成的方式相互依赖的(全职还是兼职)是工作方式的函数。
工作量确认:
每个项目都有预定数量的人员参与。
在进行时间分配时,项目管理者必须确保在任意时段中分配给任务的人员数量不会超过项目组中的人员数量。
例如,一个项目分配了3名员工参加(即,每天可分配的工作量
为3人天②)。
在某一天中,需要完成7项并发的任务,每个任务需要0.50人天的工作量,在这种情况下,所分配的工作量就大于可用于分配的工作量。
定义责任:
每个被调度的任务都应该指定某个特定的小组成员来负责。
定义结果:
每个被调度的任务都应该有一个定义好的结果。
对于软件项目而言,结果通常是一个工作产品(例如一个模块的设计)或某个工作产品的
一部分。
通常将多个工作产品组合成“可交付产品”。
定义里程碑:
每个任务或任务组都应该与一个项目里程碑相关联。
当一个或多个工作产品经过质量复审(参见第8章)并且得到认可时,标志着一个里程碑的完成。
随着项目进度的发展,上述每一条原则都会被用到。
7.2人员与工作量之间的关系
在一个小型软件开发项目中,只需一个人就可以完成需求分析、设计、编码和测试。
随着项目规模的增长,必然涉及到更多的人员参与(我们几乎不可能负担让一个人工作十年来完成10人年工作量的奢侈!
)。
许多负责软件开发工作的管理者仍然坚信一个普遍存在的荒诞想法(参
见第1章):
“即使进度拖后,我们也总可以增加更多的程序员,并在后期跟上进度”。
不幸的是,在项目后期增加人手通常产生一种破坏性影响,其结果是使进度进一步拖延。
后来增加的人员必须学习这一系统,而培训他们的人员正是过去一直在工作着的那些人,当他们进行教学时,就不能完成任何工作,而项目也进一步被拖延。
除去学习系统所需的时间之外,新加入人员将会增加人员之间通信的路
径数量和整个项目中通信的复杂度。
虽然通信交流对于一个成功的软件开发项目而言绝对是必不可少的,但是每增加一条新的通信路径就会增加额外的工作量,从而需要更多的时间。
7.2.1一个例子
让我们来考虑一个有4名软件工程师的项目,在单独完成项目时,每个工程师的工作能力都是每年生产5000LOC,而当这4位工程师被编入一个项目组时,有6条可能的通信路径。
每条路径都将花费原本可以用于软件开发的工作时间。
由于增加了通信成本,我们将假定每增加一条通信路径将会使项目组的生产率(以LOC计算)降低250LOC/年。
因此项目组的生产率为20000
②实际上由于与工作无关的会议、病假、休假和各种其他原因,可供分配的工作量要少于3人天。
但是在
本书中,我们将假定员工时间是100%可用的。
-(250×
6)=18500LOC/年,比期望数字低了7.5%①。
上述项目组承担的为期一年的项目现在只剩下两个月时间,但是已经落
后于进度,这时又加入了2名工程师。
于是通信路径激增为14,在交付之前剩下的两个月时间里,新增加成员的生产能力为840×
2=1680LOC。
而目前的项目组生产率为20000+1680-(250×
14)=18180LOC/年。
尽管上述例子仅仅是对现实情况的粗略简化,但是它足以揭示另一个关键性的问题:
参加软件项目的工作人员数量与整体生产率之间的关系不是线性的。
那么基于上述的人员-工作关系,是不是说项目组会降低生产效率呢?
如果通信可以提高软件质量的话,答案断然是“不”。
实际上,由软件工程小组进行的正式技术复审(参见第8章)将得到更好的分析和设计,更重要的是,这样可以降低直到测试阶段才能发现的错误数量(从而减小测试的工作量)。
因此,如果以项目完成时间和客户满意程度来衡量,生产率和质量都将确实提高。
7.2.2一个经验关系
请回忆一下在第5章介绍的“软件方程式”[PUT92],我们可以看到在完成项目的时间与投入项目中的人员的工作量之间存在着高度非线性关系。
交付的代码(源代码语句)行数L与工作量和开发时间之间的关系可以用下面的公式表示:
L=P×
(E/B)1/3t4/3
其中E是以人月为单位的开发工作量;
P是一个生产率参数,它反映了导致高质量软件工程工作的各种因素的综合效果(P通常取值在2,000到28,
000之间);
B是特殊技术因子,在0.16到0.39之间取值,是所生产软件的
规模的函数;
t是以月为单位的项目持续时间。
将上述软件方程式重排,可以得到关于开发工作量E的计算公式:
E=L3/(P3t4)(7.1)
其中E是在软件开发和维护的整个生命周期内所需的工作量(以人年计算),t是以年计算的开发时间。
通过引入平均劳动力价格因素($/人年),开发工作量的计算公式还能够与开发成本相关联。
这一方程式引出了一些有趣的结果。
考虑一个复杂的实时软件项目,估
计需要33,000LOC,12个人年的工作量。
如果为项目组分配8个人,项目大约可以用1.3年时间完成。
但是如果将交付时间延长到1.75年,则公式(7.1)中的模型所具有的高度非线性特性将导致如下结果:
E=L3/(P3t4)~3.8人年
这意味着通过将截止时间推迟6个月,我们可以将项目组人数从8降低
到4人!
这一结果的有效性有待考证,但是其含意却十分清楚:
通过在略为延长的时间内使用较少的人员,可以实现同样的目标。
7.2.3工作量分布
①也可以做出以下辩驳:
如果通信是高效的,就可以提高所进行的工作的质量,从而降低返工工作量,并
提高每个项目组成员的生产率。
辩驳成立!
在第五章中讨论的每种软件项目估算技术最终都归结为对完成软件开发
所需人月(或者人年)的估算。
一种推荐的在定义和开发阶段之间的工作量分布通常被称为“40-20-40规则”①。
40%或者更多的工作量分配给前端的分析和设计任务。
类似比例的工作量用于后端测试。
你可以推断出编码工作(大
约20%的工作量)没有被着重强调。
这种工作量分布只应被当作指导原则。
各个项目的特点决定了其工作量
分布。
用于项目计划的工作量很少超过2%到3%,除非提交给组织的项目计划费用极大,而且具有高风险。
需求分析大约占用10%到25%的工作量,用于分析或原型开发的工作量应该与项目规模和复杂度成正比的增长。
通常有
20%到25%的工作量用于软件设计,用于设计复审和随之而来的迭代开发也必须列入考虑之中。
因为在软件设计时投入了相当的工作量,随后的编码工作就变得相对简单。
15%到20%的工作量就可以完成这一工作。
测试和随之而来的调试工作将占用30%到40%的软件开发工作量。
软件的重要性决定了所需测试工作的份量,如果软件系统是人命相关的(即,软件错误可能使人丧命),就应该考虑分配更高的测试工作量比例。
7.3为软件项目定义任务集合
在第二章中,我们描述了多种不同的过程模型。
这些模型为软件开发提供了不同的范型。
如果不考虑一个软件项目组选择的是线性顺序范型、迭代开发模型、演化开发模型、并发开发模型还是组合使用这些模型,则过程模型都是由一个任务集合组成的,它使得软件项目组能够定义、开发和最终维护计算机软件。
没有一个普遍适用于所有软件项目的任务集合。
适用于大型复杂系统的
项目任务集合可能对于小型且相对简单的项目而言就过于复杂。
因此一个有效的软件过程应该定义一组“任务集合”,各个任务集合的设计可以满足不同类型项目的要求。
一个任务集合包括一组软件工程工作任务、里程碑和交付产品,为了完
成某一特定项目就必须完成这些任务。
一个项目所选择的任务集合必须为最终获得高质量的软件产品提供充分的规程要求,但同时又不能让项目组负担不必要的工作。
任务集合的设计应该可以应用于不同类型的项目和不同的严格度。
尽管很难建立一个全面详尽的分类结构,但是大多数软件组织接手的项目一般属于下述类型:
概念开发项目:
项目的目的是为了探索某些新的商业概念或者某种新技术的应用。
新应用开发项目:
根据特定的客户需求而承担的项目。
应用增强项目:
对现有软件进行最终用户可察觉的功能、性能或界面的修改。
①现在对于大型软件开发项目而言,通常多于40%的全部项目工作量用于分析和设计任务。
因此从严格意
义上讲,“40-20-40”,的名称已经不再适用。
应用维护项目:
以一种最终用户不会立即察觉到的方式对现有软件进行纠错、适应或者扩展。
再工程项目:
为了全部或部分重建一个现有(遗留)系统而承担的项目。
即使在单一的项目类型中,也会有许多因素影响任务集合的选择。
当将这些因素综合考虑时,就会构成一个称为“严格度”的指示量,它将应用于
所采用的软件过程中。
7.3.1严格度
即使只考虑某种特定类型的项目,所采用的软件过程的严格度也会相当不同。
严格度是众多项目特性的函数。
例如,小型的非主要商业性质的项目的严格度一般可以小于大型复杂的主要业务应用程序。
但是应该注意到,所有项目都必须以一种能够按时得到高质量的发布产品的方式来实施。
可以定义如下的4种不同程度的严格度:
随意的:
使用了所有过程框架活动(参见第2章),但只需要一个最小的任务集合。
一般情况下,将保护性任务最小化,并将文档需求降低。
所有基本的软件工程原则仍然都是适用的。
结构化的:
在项目中将使用过程框架。
框架活动和适用于这种项目类型
的相关任务,以及为保证高质量所需的保护性活动将得到应用。
SQA、SCM、文档和度量任务将以一种经过优化的有效方式进行。
严格的:
整个过程将按照一种能够确保高质量的严格规程要求应用于项
目之中。
所有保护性活动都将被采用,且要建立健壮的文档。
快速反应的:
该项目将使用过程框架,但是由于某种紧急情况①的出现,只应用了那些为保持软件系统质量所必须完成的任务。
在应用程序/产品交付给客户之后再完成“回填工作”(即开发一套完整的文档,进行额外的复审)。
项目管理者必须开发一种系统化的方法用以选择适用于特定项目的严格度。
为了做到这一点,需要定义项目适应性准则并计算“任务集合选择因子”
的值。
7.3.2定义适应性准则①
适应性准则用于确定一个项目中使用软件过程的严格度。
我们为软件项目定义了以下11条适应性准则:
项目的规模。
潜在的用户数量。
任务的关键性。
应用程序的寿命。
需求的稳定性。
客户与开发者之间通信的容易程度。
①紧急情况应该非常罕见(在软件工程的讨论范围内,发生这种情况的工作不应该超过10%到20%)。
紧
急情况与项目工期紧张是不同的。
①出现在本节中的适应性准则与后面一节出现的TSS计算都是根据《自适应的过程模型》改编的。
其复制得到了R.S.Pressman&Associates,Inc.的许可。
欲知有关详情,请发电子邮件给info@.
应用技术的成熟度。
性能约束。
嵌入式/非嵌入式特性。
项目人员配置。
再工程因素。
每一条适应性准则都被赋予一定的等级分数,取值在1到5之间。
其中
1代表需要使用较小子集的过程任务,且整体的方法学及文档需求为最小的项目;
而5则代表需要采用全部过程任务,且整体的方法学及文档需求相当高的项目。
7.3.3计算任务集合选择因子的值
为一个项目选择适当的任务集合,应该按照下述几个步骤进行:
1.复审7.3.2节中给出的每个适应性准则,根据项目特点为它们赋予适当的等级分数(从1到5)。
这些等级分数应该输入到表7-1中。
2.复审赋予每个适应性准则的加权因子。
加权因子的取值在0.8到1.2之间,表明了对在当前环境中开发的软件类型而言特定适应性准则的相对重要性。
如果需要,则可以进行修改,以反映当前的环境。
3.将表7.1中的等级分数与加权因子相乘,再乘以表示当前项目类型的
条目点乘数。
条目点乘数在0到1之间取值,表示该适应性准则与项目类型之间的相关程度。
对应于各个适应性准则的相乘结果:
等级分数×
加权因子×
条目点乘数
分别放入表7-1的“乘积”栏中。
4.计算“乘积”栏中所有条目的平均值,并将结果放入标记着“任务集合选择因子(TSS)”的空格中。
这个值将用于帮助你选择最适用于当前项目的任务集合。
表7-1计算任务集合选择因子
适应性准则等级分数权重条目点乘数乘积
概念新应用增强维护再工程项目规模—1.2001111—用户数量—1.1001111—业务关
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 实施 几个 重要思想