软件工程外文翻译————————————————————————————————作者：————————————————————————————————日期：译文学院：电气与信息工程学院专业：软件工程学号：1245536227姓名：闫雨涛指导教师：吴惠英江苏科技大学2015 年 5 月 30 日软件工程Roger S.Pressman概念：软件项目管理开始于全体项目计划的一系列活动。

在这个项目开始之前，管理者和软件团队必须预估要做的工作量、需要多少资源、从开始到结束花费的时间。

无论何时都要进行估算，我们观察未来并且接受一定程度不确定的必然发生的事情。

引用Frederick Brooks。

人员：软件管理者，使用从客户和软件工程师处获得的信息以及从过去的项目手机的软件度量数据。

为什么重要：你会在不知道你将要花多少钱的情况下建造房子吗？当然不会，而且因为大多数情况下基于计算机系统的产品的成本大大超出建造一栋大房子，因此，在你开始创建软件前开发一个估算似乎是合理的。

步骤：估算从产品的范围的描述开始。

在范围被”界定”前，不可能得出一个有意义的估算。

然后问题被分解为一组较小的问题，而且这些问题的每一个均通过使用历史数据和经验作为指南进行估算。

明智的做法是使用至少两种不同的方法（作为交叉检查）来产生你的估算。

问题复杂度和风险需在最终的估算给出前被考虑。

产品：一个简单的表，描述将完成的任务，将实现的功能以及各自涉及的版本，工作量和时间，同时也生成一个所需项目资源的列表。

保障措施：这是很困难的。

因为在项目已经完成前，你将不可能真正知道。

然而，如果你有经验且遵循系统化的方法，用可靠的历史数据生成估算，用至少两种不同的方法创建估算数据点并考虑复杂度和风险因素，那么你可以确信你已经得出了你的最好估算。

软件项目管理过程从一组活动开始，它们被称为项目计划。

在项目可以开始前，管理者和软件小组必须估算将要完成的工作，将需要的资源以及从开始到完成所需要的时间。

无论何时进行估算，我们都是预测未来，并会接受某种程度的不确定性。

引用FrederuckBrooks[BRO75]的话：我们的估算技术发展缓慢，更为严重的是，它们隐含了一个不正确的假设，即”一切都会好的”......因为我们对自己的估算没有把握，软件管理者常常缺少让人们得到一个好产品的信心。

虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行。

对时时间以及工作量进行评估又用的技术确实存在。

过程和项目度量可以定量估算的生成提供历史的视角和强有力的输入，过去的（所有参与人员的）经验可以非测量的辅助估算的开发和评审。

因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有他我们就会塔错车。

5.1对估算的观察一位总经理曾经被问到：在选择一个项目管理者时，什么特质是最重要的？他的回答是：”具有在错误真正发生之前就能知道的能力”。

我们还可以加上：”在未来还是一团迷雾的时候就有勇气进行估算”。

估算一个软件开发工作的资源，成本及进度需要经验，得到以前的有用信息进行估算。

估算具有与生俱来的风险，而正是这种风险导致了不确定性。

项目复杂性对计划中固有的不确定性具有重大影响。

不过，复杂性是一个相对的测量，受到对以前工作的熟悉程度的影响。

一个复杂的电子商务应用的第一次开发者可能认为他是非常复杂的，然而一个正在开发其10个电子商务Web站点的软件小组会认为这样的工作是非常普通的。

一系列定量的软件复杂度测量已经被提出[ZUS97]，这样的测量被应用于设计或代码级，并因此而难于在软件计划中被使用（在设计和代码存在前）。

不过，关于复杂性的其他一些更为主观的评估（如第4章描述的功能点复杂度调整因子）可以在早期的计划过程中建立。

项目规模是另一个影响估算准确性和效力的因素，随着规模的增长，软件中各个元素之间的相互依赖性也迅速增加。

估算中采用的一个重要方法，问题分解，也因为分解出来的元素仍然很大而变得更为困难，解释Murphy定律:”所有可能出错的地方都会出错”，如果有更多的事情可能更改，那就更多的事情将会失败。

结构不确定性的程度也会对估算的风险产生影响。

在这里，结构是指需求能被固定的程度，功能能被分解的容易程度以及必须要处理的信息的层次性。

历史信息的可用程度对估算的风险有较强的的影响，通过回顾过去，我们能够效仿好的地方，且避免以前遇到的困难，总体风险也会降低。

风险是由资源、成本及进度建立的定量估算去测量的，如果对项目范围理解很差或项目需求不断变化，不确定性及风险就会很高。

软件计划者应该要求功能。

性能以及接口定义（包含在系统规范中）的完全性。

计划者，尤其是客户，应该认识到软件需求的变化意味着成本及进度的不稳定，然而项目管理者不应该为估算所困扰。

现代软件工程方法（如演化软件过程模型）支持开发的迭代视图，在这类方法中，当用户改变需求时，有可能会重新审查估算（在知道更多信息后）并修改之。

5.2项目计划目标软件项目计划的目标是提供一个框架，使得管理者能够对资源、成本及进度进行合理的估算。

这些估算是软件项目开始是在一个限定的时间框架内所做的，并且随着项目的进展不断更新。

此外，估算应该定义”最好的情况”及”最坏的情况”，使得项目的结果能够限制在一定范围内。

项目计划的目标是，通过发现一个信息实现的。

该过程最终导致能够进行合理的估算。

在以下各节中，我们讨论了与软件项目计划相关的每一个活动。

5.3软件范围软件项目计划的第一个活动是确定软件范围。

在系统工程阶段分配给软件的功能及性能，应该加以评估来建立一个项目范围，该范围在管理级及技术级均是可理解的。

一个软件范围的陈述必须具有边界的。

软件范围描述了将被处理的数据和控制、功能、性能、约束、接口及可靠性。

在范围陈述中给出的功能被评估，并在某些情况下被进一步精华已在估算开始之前提供更多的细节。

因为成本及进度估算都是面向功能的，所以某种程度的分界常常是很有用的。

性能方面的考虑包含处理及响应时间的要求。

约束标识了外部硬件、可用内存或其他已有系统等对软件的限制。

5.3.1获取定义软件范围所需的信息在软件项目开始时，事情总是某种程度的模糊不清。

已经定义了要求并确立了基本的目标和目的，但定义软件范围所需的信息却还没有被定义。

在客户和开发者之间建立通信的桥梁并使通信过程顺利开始的最常用的技术是举行一个初步的会议或访谈。

软件工程师和客户之间的第一次回忆可能就像青年男女的第一次约会那么尴尬。

两方都不知道说什么或问什么，两方都担心它们所说的话会被误解，两方在想会有什么结果，两方都希望事情赶快完成，但同时，两方都希望能够成功。

不管怎样，通信必须要开始。

Gause和Weinberg建议分析员开始是可以问一些与项目无关的问题，也就是说，一组使你对总体情况有一个基本了解的问题，需要解决方案的人，所期望的解决方案的性质，以及对第一次见面的效果的评价等。

第一组语境无关的问题主要集中于客户。

总体目标及收益上。

例如，分析员可能会问：谁提出了关于这项工作的要求？谁将使用这个解决方案？成功的解决方案将获得什么经济利益？是否有另一种解决方案来源？下一组问题使得分析员能够对问题有一个更好的理解，使得客户能够谈出他或她对于解决方案的想法：你认为一个成功的解决方案所产生的好的效果应该具有什么特征？这个解决方案针对什么问题？你能给我显示一下该解决方案将使用的环境吗？是否有什么特殊的性能问题或约束会影响该解决方案被实现的方式？最后一组问题主要集中于回忆的效果。

Gause和Weinberg称这些为原问题，并推荐了下免得问题列表：你是回答这些问题的最合适的人吗？你的回答是否是正式的？我的提问与你想要的问题相关吗？我是否问了太多了问题呢？是否还有其他人能够提供更多的信息？是否还有其他我应该问你的问题？这些问题能够帮助打破僵局并开始建立项目范围所必需的通信活动。

但这种问答会议的形式并不是一定会成功的。

事实上，形式仅应用于第一次见面之后，应被结合了问题解决协商及规定等多种方式的会议形式所取代。

客户和软件工程师经常有一个无意识的”我们和它们”的思维定势。

不是作为一个小组工作去标志和精华需求。

而是各方面定义自己边界并通过一系列的备忘录。

正式意见书。

文档以及提问和回答会话而通信。

历史已经证明，这样的方法不能很好的工作。

误解大量存在，重要的信息被忽略，而且成功的工作关系永不能建立。

根据这些问题有很多独立研究者提出了一种收集需求的面向小组的方法，能够用于帮助建立项目的范围。

一种方法被称为便利的应用鬼月技术，该方法鼓励建立由客户及开发者共同组成的联合小组，它们在一起工作，建议解决方案，以上不同的方法都描述了初步的需求合集。

5.3.2 可行性一旦范围已经被标志出来，人们自然会问：我们能够建造软件以满足该范围要求吗？项目是可行的吗？一个太过经常的情形是：软件工程师匆匆越过的这些问题，最终陷人从一开始就注定有问题的项目泥潭中。

并非每个事情就靠想想就是可行的，对软件而言更是如此，相反软件可行性更是如此，相反软件可行性有四个固定的条件：技术，项目是技术的可行的吗？他是具有先进水平的吗？缺陷可以减少到满足应用要求的成都吗？财政是财政可行的吗？开发可以在客户或市场可以支付的成本范围内完成吗？时间项目的完成时间可以击败竞争者吗？资源组织拥有成功所需要的资源吗？对某些在已建立的领域内的项目，这些问题的回答是容易的。

你以前已完成过这样的项目在经过几个小时或有时几周的调查后，你可确信你能够再次完成这样的项目。

在你的能力范围之外的项目却不会如此容易，一个小组可能不得不花费几个月去发现什么是一个新应用的中心的。

难于实现的需求，这些需求中的某些会带来使项目不可行的风险吗？这些风险刻意被克制吗？可行性小组应该研究高风险需求的体系结构和设计，以便可以回答这些问题。

在某些情形当小组得到否定的回答时，可能需要就减少需求进行谈判。

同时，卡通人员在用手指紧紧地敲打它们的大桌子上，经常的情况是它们气派的挥舞它们手中的粗雪茄，透过烟雾不耐烦的叫喊，足够了，开始进行。

很多这样开始的项目在几年后作为失败案例而出现在报纸上。

Putnam和Myers正确的指出仅仅范围定义是远远不够的，一旦范围被理解后，软件小组和其他人员必须工作已确定是否他能在上面提到的几个为内被完成。

这是估算过程中最重要的部分，虽然经常被忽略。

5.3.3 一个范围定义的例子与客户的通信使得我们可以定义被处理的数据和控制、必须被实现的功能、界定系统的性能和约束以及相关的信息。

举一个例子，考虑开发驱动一个传送带分类系统的软件。

对CLSS的范围陈述如下：传送带分类系统（CLSS）讲沿传送带方向移动的盒子进行分类，每一个盒子由一个包含零件号的条形码阅读器及一台PC所组成的分类站。