2.4 理想的、真实的和现实的项目计划外文翻译资料

毕业设计(论文)外文翻译

译文：

2.4 理想的、真实的和现实的项目计划

计划过程对于成功的软件系统开发是必不可少的。如图2-5所示，规划开始于对将要构建什么、如何构建软件系统、实际构建系统以及如何在操作环境中使用系统的基本理解。成功的开发工作的关键是定期和事件驱动的基础上审查开发活动，以确保(1)正确地合并了客户需求和(2)有信息可用来做出关于下一步要做什么的智能决策。

图2-5利用你的经验来调整一般的生命周期，你定义了具体的管理、开发和产品保证任务要完成，以及相关联的估计资源、里程碑和时间表.

图2-5显示了通用的生命周期可以定制为适合您特定情况的生命周期。通过利用卖方和客户的经验，可以定义一套特定的可负担得起的生命周期阶段和系统规程活动。可以为每个生命周期阶段定义具体的管理、开发和产品保证任务、里程碑、计划和资源。在客户和卖方之间的相互作用中不可或缺的是CCB。CCB是一个商业论坛，客户和卖家在其中进行交互，以确保构建了客户想要的东西。许多(如果不是大多数的话)软件系统开发项目都存在沟通不畅的问题——客户到卖家，卖家到客户，开发人员到用户，产品保证人员到经理，等等。CCB有助于降低沟通风险。我们再怎么强调CCB的重要性也不为过。计划尽快建立一个CCB。

在这一点上，我们以一种简化的方式描述了与说明性生命周期相关的软件开发活动。特别地，我们说明了以下三个潜在的生命周期:

• 传统的系统工程.

6个阶段的生命周期，使用系统工程来产生详细的规格文件和计算机代码。

• 原型.

一个三周期的生命周期，使用原型来细化那些没有被很好理解的需求。

• 信息工程.

6个阶段的生命周期，使用信息工程来开发逻辑设计，然后使用计算机辅助软件工程(CASE)工具生成物理实现。

这三个例子为软件系统开发项目的规划提供了额外的见解。这里的目的仅仅是介绍这些“量身定制的”生命周期，供您在定义自己的特定管理、开发和产品保证任务时考虑。这些生命周期是从卖方的角度提出的，因为卖方负责开发产品。在某些情况下，SOW可能指定要使用客户的生命周期。卖方的项目计划应该考虑到实现可能是不熟悉的软件系统开发生命周期的学习曲线。

传统的系统工程生命周期实例

图2-6是我们三个生命周期示例中的第一个。此图将一般的四阶段生命周期描述为以下六个阶段的系统工程生命周期:

图2-6这6个阶段的生命周期通过将HOW分为两个独立的阶段-初步设计和详细设计，为设计活动增加了可见性。当HOW被评估为特别危险时，这样的可见性是可取的。上面显示的示例活动需要在每个生命周期阶段的项目计划中进行处理。计划应该说明与这些活动评估的风险相对应的活动的多次迭代。

• 需求定义
• 初步设计
• 详细设计
• 编码
• 生产/部署
• 操作和使用

下面将描述这六个阶段中的每一个。

需求定义阶段

这一阶段的活动集中在软件要做什么——也就是说，由硬件、软件和人的综合操作来执行的功能。在软件生命周期的这个阶段，这三个通用系统组件的作用可能并不明显。这些成分之间的边界可能是无定形的。然而，随着实际项目工作的展开，这些边界将得到更好的理解。在系统的生命周期中，这个子集的元素可能会随着做出关于硬件要做什么和人员要做什么(因此软件要做什么)的决定而改变

管理任务包括监测评估的风险和根据需要规划减轻风险战略。管理改进计划的预算和时间表。在生命周期的早期建立变更控制委员会(CCB)是重要的。随着项目的进展，客户和卖家都细化了他们对需要做什么的理解。这些项目动态导致了细化计划活动的需要。为了指定并同意改进，客户和卖方使用CCB会议作为一个论坛来记录商定的改进。评估风险、规划风险缓解战略、细化预算、持有CCB等，在整个生命周期阶段都要继续(如图中虚线箭头所示)。一旦构建了软件系统，管理人员就决定系统是否准备好交付给客户。这个决策的输入来自产品保证验收测试活动提供的可见性。验收测试帮助管理人员回答以下问题:构建的系统是否做了它应该做的事情?一旦系统交付给客户，卖方管理人员就会征求客户的反馈，以确保系统能够正常运行。在操作使用期间，管理层监控客户的反馈，并确定是否有后续工作。

开发任务包括开发一个操作系统概念。根据项目的总体规模，概念可能包括一页图表，一份详细的书面报告，或介于两者之间的内容。在操作系统概念中体现的每个软件功能的描述可能只是一个句子的定义，或者一个或多个段落，放大了功能的特定方面(例如，它的范围、定性性能、特征和/或子功能)。例如，一个系统的需求规格说明可能包含如下的陈述:

本软件应对当月下雨的天数进行月度统计。

随着项目的展开，需求定义阶段可能会重新进行，需求规格书可能会进一步详细如下:

如在24小时内降雨量达到至少0.02英寸，则雨日数应增加1。编写软件需求规范存在各种标准。电气和电子工程师协会(IEEE)就制定了这样一个标准。这个标准首次发布于1984年，并在1994年进行了修订，定义了良好需求规范的八个特征。这些特征包括“明确的”、“完整的”和“可追踪的”。这个标准为如何编写一个明确和完整的软件需求规范提供了指导。^[3]《IEEE软件需求规范推荐实践》。IEEE标准830-1993(纽约:电气和电子工程师学会，1994年4月8日)。

产品保证任务包括检查SOW一致性、正确性、模糊性、完整性、一致性、稳定性、可验证性、可修改性和可追溯性的需求。卖方的产品保证人员可以通过描述测试策略开始初步的测试工作。产品保证任务包括问以下基本问题:需求是可测试的吗?如果需求可能是不可测试的，那么向客户证明软件系统满足了客户的需求是很困难的。

初步设计阶段 这一阶段的活动集中于从软件要做什么到软件要如何完成什么的转换。管理任务从需求定义阶段继续进行。变更控制会议在必要时召开，以确保客户和卖方就如何将需求设计成预想的计算机代码达成一致。在达成一致的里程碑之前和之后，CCB会议的频率可能会增加。增加的会议频率有助于让管理层了解项目的进展情况，以便能够立即对任何潜在的问题作出反应。我们已经发现，当有更多的沟通时，客户的期望更经常地得到满足，并且卖方对其项目团队实际能够完成的工作的洞察力也很容易理解。因此，客户得到了想要的东西，而销售者能够更好地估计需要做什么才能确保成功完成。开发任务包括将在需求定义阶段定义的功能分配给软件和硬件(如果这个分配在需求定义阶段没有执行)。最终将成为计算机代码的大纲被指定。定义了主要的子系统，并分解了每个子系统中的顶层结构。在描述流入和流出系统的数据流的同时，还要描述每个子系统中将流入转换为流出的处理过程。定量的性能标准(例如，多快，多准确，多频繁)被指定。^[4][4] 这种定量的性能标准有时可以在需求定义阶段指定。例如，客户可能需要一个消息处理系统，由于消息量已知，该系统必须能够每小时处理指定数量的消息。然而，定量的性能标准经常来自客户需求的定性陈述。因此，这些量化标准表示了如何完成客户的要求——从而表示了设计。例如，客户可能要求展示逼真的人体运动动画。从这个(定性的)对逼真(相对于，比如说，定格或不稳定的)动画的要求，可以导出一个(定量的)软件设计性能标准，即软件必须在视频设备上每秒产生指定数量的显示图像。

产品保证任务包括验证和确认需求和初步设计，确定需求和初步设计是否符合已建立的项目标准，并根据测试策略开发测试程序

详细设计阶段

这一阶段的活动主要是在前一阶段的基础上展开设计大纲。

管理任务与初步设计阶段基本相同。管理层需要密切监视日程安排，一旦发现有日程安排单，就与客户见面。简单地说，好的管理并不令人惊讶。

开发任务包括详细规定软件结构以允许进行编码。考虑下面的简单示例。假设初步设计说明书包含以下声明:

[x天]每小时的降雨量之和。如果总和大于0.02英寸，将文件“降水量”中的“雨天”值加1。

假设在本阶段对初步设计规范进行了扩展，并增加了以下额外细节(粗体字):

[x天]每小时的降雨量之和。如果总和大于0.02英寸，将文件“降水量”中的“雨天”值加1。

理想情况下，详细设计阶段的细节级别应该是这样的:编码阶段的活动只不过是将设计文档中的文字简单地誊写成某种计算机语言。软件的详细设计就像一个硬件部件的工程图，显示了所有的部件，它们的尺寸，它们的互连，以及它们将从哪里建造的材料。在详细设计阶段，设计了系统运行所需的数据库。此外，还开发了用户文档(即规定操作软件的命令和其他程序的手册)。

产品保证任务包括验证和验证详细设计的需求，并检查设计的细节充分性。产品保证还准备计划和程序，以测试软件代码的后续阶段。完成测试计划和程序是一项耗时的工作。此外，很多时候开发工作没有按计划完成，并且影响产品保证进度。项目计划活动应该考虑到这些潜在的进度延误。

编码阶段

这一阶段的工作重点是将详细设计转化为计算机硬件能够理解的语言。

管理任务包括决定计算机代码是否已准备好交付给客户。这个管理决策部分地与发生的CCB会议，以及开发人员和产品保证人员进行的测试联系在一起。假设在生命周期的早期，客户和销售商管理人员建立了CCB作为获取协议的一个论坛。随着项目生命周期的展开，客户和销售者管理人员定期会面，讨论并同意需要做什么。产品保证人员与开发人员一起工作，以确保需求是可测试的，并且设计规范从逻辑上遵循可测试的需求。开发测试计划和详细的测试程序，并向客户展示。测试过程列出了要执行的按钮按压步骤。这些过程只是简单地比较测试人员所指定的被观察的内容(在需求和设计规范中详细说明)和实际观察到的内容(在实际的计算机代码中详细说明)。如果指定的内容与所观察到的内容相匹配，那么卖方管理人员可以在知情的情况下做出将产品发送给客户的决定。这个简单的例子说明了一种确定“接受标准”的方法，它可以呈现给潜在的客户。使用这种方法，卖方和客户管理都可以做出明智的决定来运送和接受产品。

开发任务包括编码活动，最终生成产品供用户在自己的环境中最终使用。CASE技术将设计阶段和编码阶段混合起来;此外，它还帮助开发人员布局逻辑设计，并提供自动生成物理计算机代码的功能。此外，CASE技术已经将计算机代码生成的一些负担从开发人员转移到了软件工具上。无论计算机代码是如何生成的，代码都必须在多个层次上进行测试，因为它被放在一起并完成集成。这种测试有助于确保计算机代码体现了详细的设计和用户的需求。

产品保证任务包括验收测试，以及检查软件或软件相关产品的相互一致性。在某种程度上，客户认可的验收测试计划和程序有助于使产品的验收成为一个有争议的问题。从卖方的角度来看，验收测试是一个有价值的规程。从客户的角度来看，验收测试有助于减少得不到所需要的东西的风险。

生产/部署阶段

这一阶段的活动集中于(1)在编码阶段的所有测试令人满意地完成后生成软件代码，(2)打包被测试的软件代码(使用用户文档)，以及(3)将其交付给客户以供操作使用。^{[5] [5]} 对于一些组织来说，“生产”软件代码可能意味着“批量生产”软件代码。这样的组织可能会产生成百上千甚至数百万份软件代码的拷贝，分发给他们的客户社区。

管理任务包括监视产品交付给客户，并征求客户对项目活动的反馈。这样的反馈用于改进整个软件系统开发过程。

开发任务包括从编码阶段到这些需求的定制产

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[261125]，资料为PDF文档或Word文档，PDF文档可免费转换为Word