软件工程实施的几个重要思想.doc_第1页
软件工程实施的几个重要思想.doc_第2页
软件工程实施的几个重要思想.doc_第3页
软件工程实施的几个重要思想.doc_第4页
软件工程实施的几个重要思想.doc_第5页
已阅读5页,还剩20页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

6.8 小结当对软件项目期望很高时,一般都会进行风险分析。不过,即使他们进 行这项工作,大多数软件项目管理者都是非正式地和表面上地完成它。花在 标识、分析、和管理风险上的时间可以从多个方面得到回报:更加平稳的项目进展过程;较高的跟踪和控制项目的能力;由于在问题发生之前已经做了 周密计划而产生的信心。风险分析需要占用大量项目计划的工作量。标识、预测、评估、管理、 及监控都要花费时间。但这是值得的。引用中国 2500 多年前的兵法家孙子的 话:“知己知彼,百战不殆”。对于软件项目管理者而言,这个“彼”指的 就是风险。思考题6.1 举出五个其他领域的例子来说明与被动风险策略相关的问题。6.2 描述“已知风险”和“可预测风险”之间的差别。6.3 在本章给出的所有风险检查表中的条目中增加三个额外的问题或主 题。6.4 你被要求建造一个软件以支持一个低成本的视频编辑系统。该系统 将录像带作为输入设备,将视频信息存在磁盘上,并允许用户对已经数字化 的视频信息进行各种编辑。对这类系统做一些调研,然后列出当你开始启动 该项目以建造视频编辑系统时,你将面临的技术风险是什么。6.5 你是一家大型软件公司的项目管理者。你被要求领导一个小组开发“下一代”字处理软件(见 3.3.2 节的简单描述)。为该项目建立一个风险表。6.6 描述风险因素和风险驱动因子之间的不同。6.7 为项目风险驱动因子建立一个加权方案。6.8 为图 62 中的三个风险建立风险缓解策略及特定的风险缓解活动。6.9 为图 62 中的三个风险建立风险监控策略及特定的风险监控活动。 确认你已经标识出了你需要监控的因素,并确定风险发生的可能性是否在变 高或变低。6.10 为图 62 中的三个风险建立风险管理策略及特定的风险管理活动。6.11 你能否想到一种情况:一个高概率、高影响的风险并不纳入 RMMM 计划的考虑之中?6.12 参照图 64 所示的风险参考水平值,该曲线是否总是如图显示的那么匀称光滑,或者是否会有该曲线扭曲变形的情况存在?如果有,请举出 一个例子。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 基本原则曾经有人请教著名的神秘的人月(The Mythical ManMonth,见文 献BRO95)一书的作者 Fred Brooks,“软件项目的进度是如何延迟的?” 他的回答即简单又深刻:“一天一次。”技术性项目(不论它是涉及到水力发电厂建设,还是开发一个操作系统) 的现实情况是,在实现一个大目标之前必须完成数以百计的小任务。这些任 务中有些是处于主流之外,其实现不会影响到整个项目的完成时间;其他任 务则位于“关键路径”之上,如果这些“关键”任务的进度拖后,则整个项 目的完成日期就会受到威胁。项目管理者的目标是定义所有项目任务,识别关键任务,然后跟踪关键任务的进展以保证“一天一次”的发现进度拖延情况。为了做到这一点,管 理者必须建立一个具有一定详细程度的进度表,使得项目管理者能够监督进 度,并控制整个项目。软件项目进度安排是一种活动,它通过将工作量分配给特定的软件工程任务,而将所估算的工作量分布于计划好的项目持续时间内。但是,进度是 随着时间的改变而不断演化的,注意到这一点至关重要。在项目计划的早期, 首先建立一个宏观的进度安排表。该进度表标识所有主要的软件工程活动和 这些活动影响到的产品功能。随着项目的进展,宏观进度表中的每个条目都 被精化成一个“详细进度表”。于是(完成一个活动所必须实现的)特定软件 任务被标识出来,并进行进度安排。可以从两个不同的视角考察软件开发项目的进度安排。第一个视角,基于计算机的系统的最终发布日期已经确定(而且不能更改)。软件开发组织在 这一约束下将工作量分布在预先确定的时间框架内。第二个视角,假定大致 的时间界限已经讨论过,但是最终发布日期是由软件开发组设定的,工作量 以一种能够最好地利用资源的方式加以分布,且在对软件进行仔细分析之后 才定义最终发布日期。但不幸的是,第一种情况发生的频率远远高于第二种 情况。同软件工程的所有其他领域一样,有一些基本原则能够指导软件项目的 进度安排:划分:项目必须被划分成若干可以管理的活动和任务。为了实现项目的 划分,对产品和过程都需要进行分解(参见第 3 章)。相互依赖性:各个被划分的活动或任务之间的相互关系必须是确定的。 有些任务必须顺序发生;而其他的则可以并发进行。有些活动只有在其他活 在本章中后面将详细讨论“关键路径”。动产生的工作产品完成时才能够开始,而其他的则可以独立进行。时间分配:必须为每个被调度的任务分配一定数量的工作单位(例如, 若干人天的工作量)。此外,必须为每个任务指定开始和结束日期,这些日期 是与工作完成的方式相互依赖的(全职还是兼职)是工作方式的函数。工作量确认:每个项目都有预定数量的人员参与。在进行时间分配时, 项目管理者必须确保在任意时段中分配给任务的人员数量不会超过项目组中 的人员数量。例如,一个项目分配了 3 名员工参加(即,每天可分配的工作量为 3 人天)。在某一天中,需要完成 7 项并发的任务,每个任务需要 0.50 人天的工作量,在这种情况下,所分配的工作量就大于可用于分配的工作量。 定义责任:每个被调度的任务都应该指定某个特定的小组成员来负责。 定义结果:每个被调度的任务都应该有一个定义好的结果。对于软件项 目而言,结果通常是一个工作产品(例如一个模块的设计)或某个工作产品的一部分。通常将多个工作产品组合成“可交付产品”。定义里程碑:每个任务或任务组都应该与一个项目里程碑相关联。当一 个或多个工作产品经过质量复审(参见第 8 章)并且得到认可时,标志着一个 里程碑的完成。随着项目进度的发展,上述每一条原则都会被用到。7.2 人员与工作量之间的关系在一个小型软件开发项目中,只需一个人就可以完成需求分析、设计、 编码和测试。随着项目规模的增长,必然涉及到更多的人员参与(我们几乎不 可能负担让一个人工作十年来完成 10 人年工作量的奢侈!)。许多负责软件开发工作的管理者仍然坚信一个普遍存在的荒诞想法(参见第 1 章):“即使进度拖后,我们也总可以增加更多的程序员,并在后期跟 上进度”。不幸的是,在项目后期增加人手通常产生一种破坏性影响,其结 果是使进度进一步拖延。后来增加的人员必须学习这一系统,而培训他们的 人员正是过去一直在工作着的那些人,当他们进行教学时,就不能完成任何 工作,而项目也进一步被拖延。除去学习系统所需的时间之外,新加入人员将会增加人员之间通信的路径数量和整个项目中通信的复杂度。虽然通信交流对于一个成功的软件开发 项目而言绝对是必不可少的,但是每增加一条新的通信路径就会增加额外的 工作量,从而需要更多的时间。7.2.1 一个例子让我们来考虑一个有 4 名软件工程师的项目,在单独完成项目时,每个 工程师的工作能力都是每年生产 5000 LOC,而当这 4 位工程师被编入一个项 目组时,有 6 条可能的通信路径。每条路径都将花费原本可以用于软件开发 的工作时间。由于增加了通信成本,我们将假定每增加一条通信路径将会使 项目组的生产率(以 LOC 计算)降低 250 LOC/年。因此项目组的生产率为 20000 实际上由于与工作无关的会议、病假、休假和各种其他原因,可供分配的工作量要少于 3 人天。但是在本书中,我们将假定员工时间是 100可用的。(2506)18500LOC/年,比期望数字低了 7.5。 上述项目组承担的为期一年的项目现在只剩下两个月时间,但是已经落后于进度,这时又加入了 2 名工程师。于是通信路径激增为 14,在交付之前 剩下的两个月时间里,新增加成员的生产能力为 84021680 LOC。而目前 的项目组生产率为 200001680(25014)18180LOC/年。尽管上述例子仅仅是对现实情况的粗略简化,但是它足以揭示另一个关 键性的问题:参加软件项目的工作人员数量与整体生产率之间的关系不是线 性的。那么基于上述的人员-工作关系,是不是说项目组会降低生产效率呢?如 果通信可以提高软件质量的话,答案断然是“不”。实际上,由软件工程小 组进行的正式技术复审(参见第 8 章)将得到更好的分析和设计,更重要的 是,这样可以降低直到测试阶段才能发现的错误数量(从而减小测试的工作 量)。因此,如果以项目完成时间和客户满意程度来衡量,生产率和质量都将 确实提高。7.2.2 一个经验关系请回忆一下在第 5 章介绍的“软件方程式”PUT92,我们可以看到在 完成项目的时间与投入项目中的人员的工作量之间存在着高度非线性关系。 交付的代码(源代码语句)行数 L 与工作量和开发时间之间的关系可以用下面 的公式表示:LP (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,000 LOC,12 个人年的工作量。如果为项目组分配 8 个人,项目 大约可以用1.3年时间完成。但是如果将交付时间延长到1.75年,则公式(7.1) 中的模型所具有的高度非线性特性将导致如下结果:EL3/(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.PressmanAssociates ,Inc.的许可。欲知有关详情,请发电子邮件给 .应用技术的成熟度。性能约束。嵌入式/非嵌入式特性。项目人员配置。再工程因素。每一条适应性准则都被赋予一定的等级分数,取值在 1 到 5 之间。其中1 代表需要使用较小子集的过程任务,且整体的方法学及文档需求为最小的 项目;而 5 则代表需要采用全部过程任务,且整体的方法学及文档需求相当 高的项目。7.3.3 计算任务集合选择因子的值为一个项目选择适当的任务集合,应该按照下述几个步骤进行:1.复审 7.3.2 节中给出的每个适应性准则,根据项目特点为它们赋予适 当的等级分数(从 1 到 5)。这些等级分数应该输入到表 71 中。2.复审赋予每个适应性准则的加权因子。加权因子的取值在 0.8 到 1.2 之间,表明了对在当前环境中开发的软件类型而言特定适应性准则的相对重 要性。如果需要,则可以进行修改,以反映当前的环境。3.将表 7.1 中的等级分数与加权因子相乘,再乘以表示当前项目类型的条目点乘数。条目点乘数在 0 到 1 之间取值,表示该适应性准则与项目类型 之间的相关程度。对应于各个适应性准则的相乘结果:等级分数加权因子条目点乘数分别放入表 71 的“乘积”栏中。4.计算“乘积”栏中所有条目的平均值,并将结果放入标记着“任务集 合选择因子(TSS)”的空格中。这个值将用于帮助你选择最适用于当前项目的 任务集合。表 7 1 计算任务集合选择因子适应性准则 等级分数 权重 条目点乘数 乘积概念新应用增强维护再工程 项目规模 1.20 0 1 1 1 1 用户数量 1.10 0 1 1 1 1 业务关键性 1.10 0 1 1 1 1 寿命 0.90 0 1 1 0 0 适应性准则等级分数权重 条目点 乘积 乘数 概念新应用增强维护再工程 需求稳定性 1.20 0 1 1 1 1 易于通信 0.90 1 1 1 1 1 技术成熟度 0.90 1 1 0 0 1 性能约束 0.80 0 1 1 0 1 嵌入式/非嵌入式 1.20 1 1 1 0 1 项目人员配置 1.00 1 1 1 1 1 互操作 1.10 0 1 1 1 1 再工程因素 1.20 0 0 0 0 1 任务集合选择因子(TSS) 7.3.4 解释 TSS 值并选择任务集合一旦计算好任务集合选择因子,就可以使用下述的指南帮助你选择一个 适用于项目的任务集合:任务集合选择因子取值 严格度TSS1.2 随意的1.0TSS3.0 结构化的 TSS2.4 严格的两个推荐任务集合之间的 TSS 取值的重叠是有意设定的,这用于说明在进行任务集合的选择时,定义出精确的边界是不可能的。在进行最后的分析 时,应该将任务集合选择因子的取值、以往的经验以及常识都作为项目任务 集合的选择因素。表 72 显示了在一个假想的项目中如何计算 TSS 的情况。项目管理者在“等级分数”一栏中选择等级分值,项目类型是“新应用开发”。因此其条 目点乘数应该从“新应用”一栏中选择。“乘积”一栏中条目的计算使用如 下公式等级分数加权因子条目点乘数TSS 的取值(“乘积”一栏中所有条目的平均值)是 2.8。使用上述的准则, 管理者可以选择使用结构化的或严格的任务集合。在考虑了所有项目因素之 后,可以作出最终决策。表 7 2 计算任务集合选择子:一个例子条目点乘数 乘积新应用 增强 维护 再工程项目规模 2 1.20 1 2.4 用户数量 3 1.10 1 3.3 业务关键性 4 1.10 1 4.4 寿命 3 0.9 1 2.7 需求稳定性 2 1.2 1 2.4 易于通信 2 0.9 1 1.8 技术成熟度 2 0.9 1 1.8 性能约束 3 0.8 1 2.4 嵌入式/非嵌入式 3 1.2 1 3.6 项目人员配置 2 1.0 1 2.0 互操作 4 1.1 1 4.4 再工程因素 0 1.2 0 2.8任务集合选择因子(TSS) 2.87.4 选择软件工程任务为了制定项目进度安排,必须将任务集合分布在项目时间表上。如 7.3 节所述,任务集合将根据项目类型和严格度的不同而有所不同。7.3 节中的 每种项目类型都可以使用线性顺序、迭代(如,原型模型)或者演化(如,螺旋 模型)等过程模型来实现。在某些情况下,项目类型可以从一种形式平滑的转 换为另一种形式。例如,成功的概念开发项目通常会演化成为新应用开发项 目,而新应用开发项目结束之后,可能又开始了一个应用增强项目。这种进 程是自然且可预测的,而不论是采用何种过程模型来组织。作为一个例子, 下面我们将考虑概念开发项目的主要软件工程任务。概念开发项目是在必须探索某些新技术是否可行时发起的。这种技术是否可行尚不可知,但是某个客户(如营销部门)相信其潜在利益的存在。概念 开发项目的完成需要应用下面所述的主要任务:确定概念范围:确定项目的整体范围。 初步的概念计划:确定组织的能力,以承担项目范围所规定的工作。 技术风险评估:评估与将要作为项目范围的一部分而被实现的技术相关联的风险。概念证明:阐明新技术在软件环境中的生命力。概念实现:以一种可以由客户方复审的方式实现概念的表示,且当概念 必须被卖给其他客户或管理者时能够用于“推销”的目的。客户对概念的反应:向客户索取对新技术概念的反馈,并以特定的客户 应用作为目标。快速浏览上述主要任务,你应该不会有何诧异。实际上概念开发项目的软件工程任务流程(以及其他所有类型的项目)与人们的常识相差无几。 软件开发组必须知道哪些任务是必须完成的(项目范围);项目组(或管理者)必须确定目前是否有人能够进行这一工作(计划);考虑与工作相关联的风 险(风险评估);以某种方式证明这种技术(概念的证明);并且将这种技术用 原型的方式实现出来,从而使客户能够对其进行评价(概念实现和客户评 价)。最后,如果这一概念是可行的,则必须将其产品版本开发出来(技术转 化)。有非常重要的一点需要注意,概念开发任务本质上是迭代的。这就是说, 一个实际的概念开发项目也许会通过多个有计划的增量步骤得以实现,每个 步骤都被设计成能够产生一个可供客户评价的可发布版本。如果选择使用线性过程模型,则每一个增量都被定义为如图 71 所示的 一个重复序列。在每个序列中,将使用保护性活动(参见第 2 章中的描述); 监控软件质量,且在每个序列的末尾,将产生一个可交付产品。随着逐次迭 代的过程,可交付产品应该向着在概念开发阶段已经定义的最终产品收敛。 如果选择的是演化开发模型,则从任务 1.1 到 1.6 的分布应该如图 72 中所 示。可以以类似的方式定义和使用关于其他项目类型的主要软件工程任务。7.5 主要任务的求精在 7.4 节中所描述的主要任务可以被用于定义项目的宏观进度表。例 如,概念开发项目中描述的任务可以用于定义该项目的任务网络(参见 7.6 节)。我们在本章前面曾经指出,必须将宏观进度表精化来创建一个详细的项目进度表。精化工作始于将每个主要任务分解为一组子任务(以及相关的工作 产品和里程碑)。作为任务分解的例子,我们考虑在 7.4 节中讨论的“确定概念范围”任 务。任务精化可以使用大纲格式完成,但是在本书中将使用一种过程设计语 言来阐明“确定概念范围”这一活动的流程:任务 I.1 确定概念范围I.1.1 标出需求、效益和潜在的客户;I.1.2 定义所希望的输出/控制和驱动应用程序的输入事件; Begin 任务 I.1.2I.1.2.1FTR:复审需求的书面说明I.1.2.2 导出一个客户可见的输出/输入列表 case of:mechanics mechanics质量功能配置 与客户会谈,以划分主要的概念需求; 会见最终用户;观察现有的解决问题的方法和当前的问题解决过程; 复审以往的要求和抱怨; 过程设计语言与 14 章中讨论的程序设计语言在语法上是类似的。 FTR 表示在此需要进行一次正式的技术复审(参见第 8 章)mechanics结构化分析 列出主要数据对象; 定义对象之间的关系; 定义对象的属性; mechanics对象视图 列出问题类; 确定类层次和类连接; 定义各个类的属性; endcaseI.1.2.3FTR:与客户一起复审输出/输入,并在需要时进行修改;endtask 任务 I.1.2I.1.3 为每项主要功能定义操作/行为; Begin 任务 I.1.3I.1.3.1 FTR:复审在任务 I.1.2 中得到的输出和输入数据对象; I.1.3.2 导出功能/行为模型;case of:mechanics mechanics质量功能配置 与客户会谈,以复审主要的概念需求; 会见最终用户;观察现有的解决问题的方法和当前的问题解决过程;建立一个功能/行为的层次结构概要; mechanics结构化分析 导出一个系统级别的数据流程图; 精化数据流程图,以便给出更多的细节; 为最底层精化图的功能书写处理过程说明; mechanics对象视图 定义与各个类相关的操作/方法;endcaseI.1.3.3 与客户一起复审功能/行为模型,并在需要时进行修改;endtask 任务 I.1.3I.1.4 把需要在软件中得到实现的技术要素分离出来; I.1.5 研究现有软件的可用性;I.1.6 定义技术可行性;I.1.7 对系统规模进行快速估算; I.1.8 创建一个“范围定义”; endtask 任务 I.1任务和用过程设计语言进行精化时标注的子任务共同构成了制定“确定 概念范围”这一活动的详细进度表的基础。7.6 定义任务网络任务和子任务之间基于其间顺序而存在相互依赖关系。而且当有多个人 参与软件工程项目时,多个开发活动和任务并行进行的可能性很大。在这种情况下,必须协调多个并发任务,以保证它们能够在后继任务需要其工作成 果之前完成。“任务网络”是一个项目的任务流程的图形表示。该网络有时被用作在 自动项目进度安排工具中输入任务序列和依赖关系的机制。任务网络的最简 单形式(当创建宏观进度表时使用)刻划了软件工程主要任务。图 73 显示了 一个概念开发项目的任务网络示意图。软件工程活动的并发本质导致了若干重要的调度需求。由于并行任务是 异步发生的,计划者必须确定任务之间的依赖关系,以保证项目朝着最终完 成的方向持续发展。另外,项目管理者应该注意那些位于关键路径之上的任 务,也就是说,为了保证整个项目的如期完成,就必须保证这些任务能够如 期完成。在本章的后面部分,我们将详细讨论这些问题。图 73 中所示的任务网络是宏观的,注意到这一点非常重要。在一个详 细的任务网络(详细进度表的前驱)中,应该对图 73 所示的各个活动加以扩 展。例如,应该扩展任务 I.1,以显示 7.5 节所述的精化中的所有详细任务。7.7 进度安排软件项目的进度安排与任何其他多任务工程工作的进度安排几乎没有太 多的差别。因此,通用的项目进度安排工具和技术不必做太多修改就可以应 用于软件项目。“程序评估和复审技术(PERT)”和“关键路径方法(CPM)”MOD83就是两种可以用于软件开发的项目进度安排方法。两种技术都是由较早的项目 计划活动中已经产生的信息来驱动的,这些信息包括:工作量的估算。产品功能的分解。适当的过程模型的选择。项目类型和任务集合的选择。 任务之间的依赖关系可以使用任务网络来定义。任务,有时也称作项目的“工作细分结构”(WBS),其定义可以是针对整个产品,也可以是针对单个功能进行的。PERT 和 CPM 两种方法都提供项目工作定量划分的工具,能支持软件计划 者(1)确定关键路径一决定项目持续时间的任务链;(2)通过使用统计模型为 单个任务建立最有可能的时间估算;(3)计算为特定任务定义其时间“窗口” 的边界时间。边界时间的计算对软件项目进度的安排十分有用。比如说,某个功能的 设计的推迟可能进一步导致其他功能开发的拖后。RiggsRIG81描述了一 些能够从 PERT 或 CPM 网络中得到的重?5 谋呓缡奔洌海*1)某个任务的最早 开始时间是当其所有前驱任务在最短的可能时间中完成时;(2)某个任务的最 晚开始时间是在不延迟项目最小完成时间的前提下,最晚启动该任务的时 间;(3)最早结束时间最早开始时间加上任务持续时间;(4)最晚结束时 间最晚开始时间加上任务持续时间;以及(5)总浮动量在保证进度的 前提下,调度任务时所允许的富余时间或回旋时间的总和。通过边界时间的 计算可以确定关键路径,并为管理者提供当任务完成时评估进展的量化方法。PERT 和 CPM 方法都已经在多种自动工具中得到实现,这些工具在几乎所 有个人电脑上都可以找到THE93。这类工具易于使用,且使得每一位软件 项目管理者都可以使用前述的进度安排方法。7.7.1 时间表在创建软件项目进度表时,计划者将从一组任务(工作细分结构)入手。 如果使用自动工具,就可以用任务网络或者任务大纲的方式输入工作细分结 构。然后为每一项任务输入工作量、持续时间和开始时间。此外,每一项任 务都必须被分配给特定的人员。上述输入的结果之一是产生“时间表(Timeline Chart)”,也叫做“甘 特图(Gantt Chart)”。可以为整个项目建立一个时间表,也可以为各个项目 功能或各个项目参与者分别开发各自的时间表。表 73 给出了时间表的格式,该图描述了一个新的字处理软件产品中 “确定概念范围”任务(参见 7.5 节)的软件项目进度安排。所有的项目任务 (对于“确定概念范围”)都在左边的栏中列出。水平条表示每个任务的持续 时间。当日历中同一时段中存在多个水平条时,就代表任务之间存在并发。 图中的菱形表示里程碑。一旦输入了生成时间表所需的信息,大多数软件项目进度安排工具都会生成“项目表”一个表格式的列表,列出所有项目任务、其计划的及实 际的开始与结束日期、以及各种相关信息(参见图 75)。项目表与时间表一 同使用,使得项目管理者能够跟踪项目的进展情况。7.7.2 跟踪进度项目进度为软件项目管理者提供了一张进度路线图。如果被正确制定, 项目进度表中应该定义在项目进展过程中必须被跟踪和控制的任务及里程碑。项目跟踪可 以通过以下方式得以实现:定期举行项目状态会议,由项目组中的各个成员分别报告进度和问题。评估所有在软件工程过程中所进行的复审的结果。确定正式的项目里程碑(表 7-3 中的菱形)是否在预定日期内完成。比较项目表(表 7-4)中列出的各项任务的实际开始日期与计划开始日 期。与开发者进行非正式会谈,获取他们对项目进展及可能出现的问题的 客观评估。实际上,有经验的项目管理者都会使用所有这些跟踪技术。 软件项目管理者使用“控制”的方法来管理项目资源、处理问题和指导项目参与者。如果一切顺利(即,项目在预算范围内按进度进行,复审结果表 明的确取得了实际进展,达到了各个里程碑),则几乎不必施加控制。但是如 果出现问题,项目管理者就必须施加控制,以便尽快解决问题。当问题得到诊断之后,可能需要增加额外的资源以解决问题:如可能需要雇佣新员工, 或者需要重新定义项目进度。表 7 4 一个项目表的例子工作任务 计划开始 实际开始 计划结束 实际结束 人员分配 工作量分配 附注I.1.1 标出需求和效益 会见客户 wk1,d1 wk1,d1 wk1,d2 wk1,d2 BLS 2p-d 标出需求和项目约束 wk1,d2 wk1,d2 wk1,d2 wk1,d2 JPP 1p-d 建立产品说明 wk1,d3 wk1,d3 wk1,d3 wk1,d3 BLS/JPP 1p-d里程碑:定义产品说明wk1,d3 wk1,d3 wk1,d3 wk1,d3I.1.2 定义希望的输出/控制 输入(OCI) 确定键盘功能 wk1,d4 wk1,d4 wk2,d2 BLS 1.5p-d 确定语音输入功能 wk1,d3 wk1,d3 wk2,d2 JPP 2p-d 确定交互模式 wk2,d1 wk2,d3 MLL 1p-d 确定文档诊断 wk2,d1 wk2,d2 BLS 1.5p-d 确定其他WP 功能 wk1,d4 wk1,d4 wk2,d3 JPP 2p-d 做OCI 文档 wk2,d1 wk2,d3 MLL 3p-dFTR :与客户复审OCI wk2,d3 wk2,d3 all 3p-d按要求修改OCI wk2,d4 wk2,d4 all 3p-d里程碑:定义OCI wk2,d5 wk2,d5I.1.3 定义功能 行为? ? ? ? ? ? ?在面对交付期限的巨大压力时,有经验的项目管理者有时会使用一种称为“时间盒”ZAH95的项目进度安排和控制技术。时间盒策略认识到完整 的产品可能难以在预定时间内交付,因此,应该选择增量软件开发范型,并 为每个增量的交付定义各自的进度。接着,对与每个增量相关的任务实行时间盒技术。这意味着通过对增量的交付日期倒退着推算,来调整每项任务的进度。在每项任务前后加上了一 个“盒子”,当任务触及其时间盒边界时(正负 10的范围内),则该项任务 停止,下一任务开始。对于时间盒方法的第一个反应通常是反面的:“如果工作尚未完成,我 们该如何继续?”答案就隐藏在工作的完成方式中。在遇到时间盒的边界时, 很可能任务的 90已经完成。余下的 10工作尽管重要,但是可以(1)被推 迟到下一个增量中,或者(2)在以后需要时再完成。项目朝着交付日期逐步进 展,而不是被某个任务“卡住”。 千万注意:进度延迟是某种潜在问题的症状。项目管理者的角色是论断出潜在的问题,并采取行动改正之。 爱挖苦人的人也许会想起一句谚语:“完成系统的前 90需要 90%的时间,完成剩下的 10%也要用 90%的时间”。7.8 项目计划软件工程过程中的每一步骤都应该产生可以被复审并能够作为后续步骤 的基础的工作产品。软件项目计划在计划任务结束时产生,它给出了基线的 成本及进度信息,这些信息将会在整个软件工程过程中被使用。软件项目计划是一种面向广大读者的相对简短的文档。它必须能够(1) 在软件管理者、技术人员和客户之间传达项目范围和资源信息;(2)定义风险 并提出有关风险管理技术的建议;(3)定义管理复审的成本和进度;(4)为与 项目相关的所有人员提供软件开发的整体方法;(5)概述如何保证质量及变化 的管理。表 7-5 给出了一个软件项目计划的大纲。针对不同的读者,所显示的成本和进度可能有所不同。如果计划只作为 内部文档使用,则应该给出各种成本估算技术所得到的结果。当计划在组织 以外发布时,应该给出一份经过整合的成本细分表(结合了所有成本估算技术 的结果)。类似的,进度信息的详细程度也应该随读者和计划正式程度的不同 而有所不同。软件项目计划不必过于冗长复杂,其目的是帮助确立软件开发工作的有 效性。该计划集中于“做什么”的一般性说明和特定的“多少资源”与“多 长时间”的说明。软件工程过程中的后续步骤将集中来完成项目的定义、开 发和维护。.引言 A.计划的目的 B.项目范围和目标1.范围说明2.主要功能3.性能问题4.管理及技术约束 .项目估算表 7 5 软件项目计划3.风险管理(意外事件计划) .进度 A.项目工作细分结构 B.任务网络 C.时间表(

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论