软件工程第二周作业

软件工程第二次作业

林育锋

本周加强了相关课程的学习，虽然离自己能够独立编程还有一定差距，但还是在不断进步的路上，争取继续进步。

一、理论学习               

下面按照要求，将完成学习方面的 主要方面汇报如下：

1.慕课学习方面：将软件工程第二章、第三章进行了学习

 

      第二章学习的收获是：对代码编写规范的要求，以及一些简单的代码改错的能力；本章重点强调了实践的重要性，介绍了几种基建环境，同时对死亡游戏进行了代码编写的演示，接下来尽量进行实践练习最重要。第二章配套练习方面成果：

第三章学习的收获是：对黑盒测试和白盒测试等方法的理解，有利于对代  码编程的检查能力，找到检验代码的方法。配套练习方面成果：

 

2.阅读构建之法讲义的个人开发技术:主要讲述了评审在代码编程中的作用，以及正式评审和非正式评审的区别、作用、方式、效果等方面。大致内容如下：

翻译：

　　软件评审是软件过程工作流程的“过滤器”。太少了，水流就“脏”了。太多了，水流就慢成了涓涓细流。评审应用于软件工程的各个阶段，用于发现错误和缺陷。软件评审“purify”软件工程工作产品，包括需求和设计模型、代码和测试数据。使用度量标准，您可以确定哪些评审起作用并强调它们，同时从流程中删除无效的评审以加速流程。

原文:

　　Software reviews are a “filter” for the software process work flow. Too few, and the flow is “dirty.” Too many, and the flow slows to a trickle. Reviews are applied at various points during software engineering and serve to uncover errors and defects. Software reviews “purify” software engineering work products, including requirements and design models, code, and testing data. Using metrics, you can determine which reviews work and emphasize them and at the same time remove ineffective reviews from the flow to accelerate the process.

翻译：

它是什么？你在开发软件工程工作产品时会犯错误。只要你努力，非常努力，在错误交付给最终用户之前发现并改正它们，这一点并不丢人。技术评审是在软件过程早期发现错误的最有效机制。

是谁干的？软件工程师与他们的同事一起进行技术评审，也称为同行评审。正如我们在第3章和第4章中所讨论的，有时在这些审查中包括其他利益相关者是明智的。

为什么重要？如果在过程的早期发现错误，则纠正错误的成本更低。此外，随着过程的进行，错误有一种放大的方式。因此，一个相对较小的错误，如果在这个过程的早期没有得到处理，可以在项目的后期放大为一组主要的错误。最后，评审通过减少项目后期所需的返工量来节省时间。

步骤是什么？我们的评审方法将根据您选择的评审类型而有所不同。总的来说，虽然并非所有的步骤都用于每种类型的审查：计划、准备、安排会议、指出错误、作出更正（在审查之外进行）和核实更正是否已正确执行，但都采用了六个步骤。什么是工作产品？评审的结果是已发现的问题和/或错误的列表。此外，还指出了工作产品的技术状态。我如何确保我做得对？首先，选择适合您的开发文化的审查类型。遵循成功评审的指导原则。如果你所做的评论导致了更高质量的软件，那么你做得对。

原文:

　　What is it? Y ou’ll make mistakes as you develop software engineering work products. There’s no shame in that—as long as you try hard, very hard, to find and correct the mistakes before they are delivered to end users. T echnical reviews are the most effective mechanism for finding mistakes early in the software process. Who does it? Software engineers perform technical reviews, also called peer reviews, with their colleagues. As we discussed in Chapters 3 and 4, sometimes it is wise to include other stakeholders in these reviews. Why is it important? If you find an error early in the process, it is less expensive to correct. In addition, errors have a way of amplifying as the process proceeds. So a relatively minor error left untreated early in the process can be amplified into a major set of errors later in the project. Finally, reviews save time by reducing the amount of rework that will be required late in the project. What are the steps? Y our approach to reviews will vary depending on the type of review you select. In general, six steps are employed, although not all are used for every type of review: planning, preparation, structuring the meeting, noting errors, making corrections (done outside the review), and verifying that corrections have been performed properly. What is the work product? The output of a review is a list of issues and/or errors that have been uncovered. In addition, the technical status of the work product is also indicated. How do I ensure that I’ve done it right? First, select the type of review that is appropriate for your development culture. Follow the guidelines that lead to successful reviews. If the reviews that you conduct lead to higher-quality software, you’ve done it right.

翻译：

　　可作为软件工程的一部分进行许多不同类型的评审。每个人都有自己的位置。如果讨论了技术问题，围绕咖啡机举行的非正式会议是一种审查形式。向客户、管理人员和技术人员的听众正式介绍软件架构也是一种评审形式。然而，在这本书中，我们将重点放在技术或同行评议上，例如非正式评议、演练和检查。从质量控制的角度来看，技术评审（TR）是最有效的过滤器。TR由软件工程师和其他利益相关者为所有项目团队成员执行，是发现错误和提高软件质量的有效手段。

原文:

　　Many different types of reviews can be conducted as part of software engineering. Each has its place. An informal meeting around the coffee machine is a form of review, if technical problems are discussed. A formal presentation of software architecture to an audience of customers, management, and technical staff is also a form of review. In this book, however, we focus on technical or peer reviews, exemplified by casual reviews, walkthroughs, and inspections. A technical review (TR) is the most effective filter from a quality control standpoint. Conducted by software engineers and other stakeholders for all project team members, the TR is an effective means for uncovering errors and improving software quality.

翻译：

16.1软件缺陷的成本影响

　　在软件过程的上下文中，缺陷和错误是同义词。两者都意味着在软件发布给最终用户（或软件过程中的另一个框架活动）之后发现的质量问题。在前面的章节中，我们使用术语错误来描述软件工程师（或其他人）在软件发布给最终用户（或软件过程中的另一个框架活动）之前发现的质量问题。

原文:

16.1 cost impact of software Defects

Within the context of the software process, the terms defect and fault are synonymous. Both imply a quality problem that is discovered after the software has been released to end users (or to another framework activity in the software process). In earlier chapters, we used the term error to depict a quality problem that is discovered by software engineers (or others) before the software is released to the end user (or to another framework activity in the software process).

翻译：

程序错误、疏漏和缺陷（bugs errors defects这几个近义词不好翻译）

　　软件质量控制的目标，在更广泛的意义上，质量管理一般是为了消除软件中的质量问题。这些问题被称为程序错误、疏漏和缺陷等。这些术语是同义的，还是有细微的区别？在本书中，我们对错误（在软件发布给其他利益相关者或最终用户之前发现的质量问题）和缺陷（只有在软件发布给最终用户或其他利益相关者之后才发现的质量问题）进行了明确的区分。1我们之所以做出这种区分，是因为错误和缺陷有很大的不同经济、商业、心理和人的影响。作为软件工程师，我们希望在客户和/或最终用户遇到错误之前发现并纠正尽可能多的错误。我们希望避免缺陷，因为缺陷（合理地）使软件人员看起来很糟糕。然而，值得注意的是，这本书中对错误和缺陷的时间区分并不是主流思想。软件工程界的普遍共识是缺陷和错误、错误和bug是同义的。也就是说，遇到问题的时间点与用来描述问题的术语没有关系。支持这种观点的部分理由是，有时很难明确区分发布前和发布后（例如，考虑敏捷开发中使用的增量过程）。无论您选择如何解释这些术语，请认识到发现问题的时间点确实很重要，并且软件工程师应在其客户和最终用户遇到问题之前尽最大努力找到问题。

原文:

　　Bugs, Errors, and Defects The goal of software quality control, and in a broader sense, quality management in general, is to remove quality problems in the software. These problems are referred to by various names—bugs, faults, errors, or defects, to name a few. Are these terms synonymous, or are there subtle differences between them? In this book we make a clear distinction between an error (a quality problem found before the software is released to other stakeholders or end users) and a defect (a quality problem found only after the software has been released to end users or other stakeholders).1 We make this distinction because errors and defects have very different economic, business, psychological, and human impacts. As software engineers, we want to find and correct as many errors as possible before the customer and/or end user encounter them. We want to avoid defects—because defects (justifiably) make software people look bad. It is important to note, however, that the temporal distinction made between errors and defects in this book is not mainstream thinking. The general consensus within the software engineering community is that defects and errors, faults, and bugs are synonymous. That is, the point in time that the problem was encountered has no bearing on the term used to describe the problem. Part of the argument in favor of this view is that it is sometimes difficult to make a clear distinction between pre- and postrelease (e.g., consider an incremental process used in agile development). Regardless of how you choose to interpret these terms, recognize that the point in time at which a problem is discovered does matter and that software engineers should try hard—very hard—to find problems before their customers and end users encounter them.

翻译：

　　如果考虑软件过程改进，从一个过程框架活动（例如建模）传播到另一个过程框架活动（例如构造）的质量问题也可以称为“缺陷”，因为该问题应该在工作产品（例如设计模型）被“发布”到下一个活动之前被发现。正式技术评审（FTR）的主要目标是在将错误传递给其他软件工程活动或发布给最终用户之前发现错误。技术评审的明显好处是早期发现错误，这样它们就不会传播到软件过程的下一步。许多行业研究表明，在软件过程中，设计活动引入了50%到65%的错误（最终是所有的缺陷）。然而，审查技术已经被证明在揭示设计缺陷方面有高达75%的效率[Jon86]。通过检测和消除这些错误的很大一部分，评审过程大大降低了软件过程中后续活动的成本。我们已经知道这一点几十年了，但是仍然有许多开发人员不相信花在评审上的时间几乎总是少于重写错误代码所需的时间[Yad17]。

原文:

　　If software process improvement is considered, a quality problem that is propagated from one process framework activity (e.g., modeling) to another (e.g., construction) can also be called a “defect” because the problem should have been found before a work product (e.g., a design model) was “released” to the next activity.The primary objective of a formal technical review (FTR) is to find errors before they are passed on to another software engineering activity or released to the end user. The obvious benefit of technical reviews is the early discovery of errors so that they do not propagate to the next step in the software process. A number of industry studies indicate that design activities introduce between 50 and 65 percent of all errors (and ultimately, all defects) during the software process. However, review techniques have been shown to be up to 75 percent effective [Jon86] in uncovering design flaws. By detecting and removing a large percentage of these errors, the review process substantially reduces the cost of subsequent activities in the software process. We have known this for decades, and yet there are still many developers who do not believe the time spent on reviews is almost always less than the time required to rewrite bad code [Yad17].

翻译：

16.2缺陷放大与消除

　　缺陷放大是40年前提出的一个概念[IBM81]。它有助于证明花费在软件评审上的努力是合理的。本质上，缺陷放大使以下论点成为软件工程工作流程早期引入的错误（例如，在需求建模过程中）并且未被发现，在设计过程中可以并且经常会被放大为多个错误。如果这些错误没有被发现（使用有效的审查），它们本身可能会在编码过程中进一步放大为更多的错误。一个早期引入而未被发现和纠正的单一错误，可以在随后的过程中放大为多个错误。缺陷传播是一个术语，用于描述未发现的错误对未来开发活动或产品行为的影响[Vit17]。随着开发团队深入到软件过程中，查找和修复错误的成本会增加。缺陷放大和传播加剧了这种简单的现实，因为一个单一的错误可能在下游变成多个错误。查找和修复单个错误的成本可能很大，但查找和修复由单个早期错误传播的多个错误的成本实际上更大。要进行评审，您必须花费时间和精力，开发组织必须花钱。然而，缺陷放大和传播的现实让人毫不怀疑，你可以现在支付，或者以后支付更多。这就是技术债务（第11章）的全部内容。

原文:

　　Defect amplification is a concept originally proposed almost four decades ago [IBM81]. It helps to justify the effort expended on software reviews. In essence, defect amplification makes the following argument—an error introduced early in the software engineering work flow (e.g., during requirement modeling) and undetected, can and often will be amplified into multiple errors during design. If those errors are not uncovered (using effective reviews), they themselves may be further amplified into still more errors during coding. A single error introduced early and not uncovered and corrected can amplify into multiple errors later in the process. Defect propagation is a term used to describe the impact an undiscovered error has on future development activities or product behavior [Vit17]. As a development team moves deeper into the software process, the cost of finding and fixing an error grows. This simple reality is exacerbated by defect amplification and propagation because a single error may become multiple errors downstream. The cost of finding and fixing a single error can be signficant, but the cost to find and fix multiple errors propagated by a single earlier error is substantially more significant. To conduct reviews, you must expend time and effort, and your development organization must spend money. However, the reality of defect amplification and propagation leaves little doubt that you can pay now or pay much more later. This is what technical debt (Chapter 11) is all about [Xia16] [Vit17].

 

翻译：

16.3审查指标及其使用

　　作为良好软件工程实践的一部分，技术评审是许多需要采取的行动之一。每一项行动都需要投入人力。由于可用的项目工作是有限的，所以对于软件工程组织来说，通过定义一组可用于评估其有效性的度量标准来理解每个操作的有效性是很重要的（第23章）。

尽管可以为技术评审定义许多度量，但相对较小的子集可以提供有用的洞察力。可以为进行的每次评审收集以下评审指标：

原文:

　　Technical reviews are one of many actions that are required as part of good software engineering practice. Each action requires dedicated human effort. Because available project effort is finite, it is important for a software engineering organization to understand the effectiveness of each action by defining a set of metrics (Chapter 23) that can be used to assess their efficacy.

Although many metrics can be defined for technical reviews, a relatively small subset can provide useful insight. The following review metrics can be collected for each review that is conducted:

翻译：

准备工作，Ep。

在实际审查会议前审查工作产品所需的工作量（人-小时）∙

评估工作量，Ea。

实际审查期间花费的工作量（实际工时）∙

返工工作量，Er。

致力于纠正审查期间发现的错误的工作（当面工时）∙

审查工作，Ereview。

表示评审工作措施的总和：Ereview=Ep+Ea+Er∙

工作产品尺寸（WPS）。衡量已审查工作产品的大小（例如，UML模型的数量、文档页面的数量或代码行的数量）

∙发现的小错误，Errminor。发现的可归类为次要错误的数量（需要的纠正工作少于某些预先指定的工作量）∙

发现的主要错误，Errmajor。发现的可归类为主要错误的数量（需要超过一些预先指定的努力才能纠正）∙

发现的总错误，Errtot。表示找到的错误总数：Errtot=Errminor+Errmajor

 

错误密度。表示每单位审核工作产品发现的错误：错误密度=Errtot除以WPS

原文:

Preparation effort, Ep.

The effort (in person-hours) required to review a work product prior to the actual review meeting ∙

Assessment effort, Ea.

The effort (in person-hours) that is expended during the actual review ∙

Rework effort, Er.

The effort (in person-hours) that is dedicated to the correction of those errors uncovered during the review ∙

Review effort, Ereview. Represents the sum of effort measures for reviews: Ereview = Ep + Ea + Er ∙

Work product size (WPS). A measure of the size of the work product that has been reviewed (e.g., the number of UML models, the number of document pages, or the number of lines of code) ∙

Minor errors found, Errminor. The number of errors found that can be categorized as minor (requiring less than some prespecified effort to correct) ∙

Major errors found, Errmajor. The number of errors found that can be categorized as major (requiring more than some prespecified effort to correct) ∙

Total errors found, Errtot. Represents the sum of the errors found: Errtot = Errminor + Errmajor ∙

Error density. Represents the errors found per unit of work product reviewed: Error density =Errtot

翻译：

　　如何使用这些指标？作为一个例子，考虑一个需求模型，它被审查以发现错误、不一致和遗漏。可以用几种不同的方法计算误差密度。假设需求模型包含18个UML图，作为32个描述材料总页面的一部分。审查发现18个小错误和4个大错误。因此，Errtot=22。错误密度是每个UML图1.2个错误，或者每个需求模型页面0.68个错误。如果对许多不同类型的工作产品（如需求模型、设计模型、代码、测试用例）进行了评审，则可以根据所有评审发现的错误总数计算每次评审未发现的错误百分比。此外，还可以计算每个工作产品的误差密度。一旦为跨多个项目执行的多个审阅收集了数据，错误密度的平均值使您能够在审阅新文档之前估计要在其中找到的错误数。例如，如果一个需求模型的平均错误密度是每页0.68个错误，而一个新的需求模型是40页长，一个粗略的估计表明，您的软件团队将在文档评审期间发现大约27个错误。如果您只发现9个错误，那么您要么在开发需求模型方面做得非常好，要么您的评审方法不够彻底。

原文:

　　How might these metrics be used? As an example, consider a requirements model that is reviewed to uncover errors, inconsistencies, and omissions. It would be possible to compute the error density in several different ways. Assume the requirements model contains 18 UML diagrams as part of 32 overall pages of descriptive materials. The review uncovers 18 minor errors and 4 major errors. Therefore, Errtot = 22. Error density is 1.2 errors per UML diagram, or 0.68 errors per requirements model page. If reviews are conducted for a number of different types of work products (e.g., requirements model, design model, code, test cases), the percentage of errors uncovered for each review can be computed against the total number of errors found for all reviews. In addition, the error density for each work product can be computed. Once data are collected for many reviews conducted across many projects, average values for error density enable you to estimate the number of errors to be found in a new document before it is reviewed. For example, if the average error density for a requirements model is 0.68 errors per page, and a new requirements model is 40 pages long, a rough estimate suggests that your software team will find around 27 errors during the review of the document. If you find only 9 errors, you’ve either done an extremely good job in developing the requirements model or your review approach was not thorough enough.

翻译：

　　很难实时衡量任何技术评审的成本效益。软件工程组织只有在完成评审、收集评审度量、计算平均数据、然后（通过测试）测量软件的下游质量之后，才能评估评审的有效性及其成本效益。回到前面的例子，需求模型的平均错误密度被确定为每页0.68。纠正一个小的模型错误所需的工作（在审查之后）被发现需要4人小时。重大需求错误所需的工作量为18人小时。检查收集的审阅数据，您会发现小错误的发生频率大约是大错误的6倍。因此，您可以估计，在审查期间查找和更正需求错误的平均工作量约为6人小时。测试期间发现的与需求相关的错误平均需要45人小时才能找到并纠正（没有关于错误的相对严重性的数据）。使用所记录的平均值，我们得到：每个错误节省的工作量=测试-电子视图=45-6=39人-小时/错误

原文:

　　It is difficult to measure the cost effectiveness of any technical review in real time. A software engineering organization can assess the effectiveness of reviews and their cost benefit only after reviews have been completed, review metrics have been collected, average data have been computed, and then the downstream quality of the software is measured (via testing). Returning to the previous example, the average error density for requirements models was determined to be 0.68 per page. The effort required to correct a minor model error (immediately after the review) has been found to require 4 person-hours. The effort required for a major requirement error has been found to be 18 person-hours. Examining the review data collected, you find that minor errors occur about six times more frequently than major errors. Therefore, you can estimate that the average effort to find and correct a requirements error during review is about 6 person-hours. Requirements-related errors uncovered during testing require an average of 45  person-hours to find and correct (no data are available on the relative severity of the error). Using the averages noted, we get: Effort saved per error = Etesting − Ereviews = 45 − 6 = 39 person-hours/error

翻译：

　　由于在需求模型的评审过程中发现了22个错误，将节省大约858个工时的测试工作。这只是针对需求相关的错误。与设计和代码相关的错误将增加整体效益。节省的底线努力导致更短的交付周期和更好的上市时间。本节中的示例表明这可能是正确的。更重要的是，用于软件评审的行业数据已经收集了30多年，并使用图16.1所示的图表进行了定性总结。参考该图，在软件增量开发的早期，当使用评审时所花费的努力确实会增加，但是这种评审的早期投资会带来回报，因为测试和纠正工作会减少。需要注意的是，具有审查的开发部署日期早于没有审查的部署日期。评论不需要时间，它们可以节省时间！

原文:

　　Because 22 errors were found during the review of the requirements model, a savings of about 858 person-hours of testing effort would be achieved. And that’s just for requirements-related errors. Errors associated with design and code would add to the overall benefit. The bottom line—effort saved leads to shorter delivery cycles and improved time to market. The example presented in this section suggests this may be true. More importantly, industry data for software reviews has been collected for more than three decades and is summarized qualitatively using the graphs shown in Figure 16.1. Referring to the figure, the effort expended when reviews are used does increase early in the development of a software increment, but this early investment for reviews pays dividends because testing and corrective effort is reduced.It is important to note that the deployment date for development with reviews is sooner than the deployment date without reviews. Reviews don’t take time; they save it!

翻译：

16.4审查类型的标准

　　技术评审可以分为正式评审和非正式评审，也可以介于这两个极端之间。选择正式程度是为了与要构建的产品类型、项目时间线和工作人员相匹配。图16.2描述了技术评审的参考模型[Lai02]，该模型确定了有助于评审程序的四个特征。每个参考模型特性都有助于定义评审程序的级别。当

（1）明确定义了评审员的不同角色，

（2）有足够的评审计划和准备，

（3）定义了评审的不同结构（包括任务和内部工作产品）时，评审的形式就增加了，

（4）评审员对所做的任何更正进行跟踪。

　　这个模型中没有提到的一个元素是评论本身的频率。如果您使用的是包含相对较短的sprint的敏捷原型模型（第4章），那么您的团队可能会选择不太正式的评审，因为评审经常发生。这通常意味着缺陷会越来越快被发现。为了理解参考模型，让我们假设您已经决定查看safehomeassered.com的接口设计。你可以用各种不同的方式做到这一点，从相对随意到极其严格。如果您认为临时方法是最合适的，您可以让一些同事（同事）检查接口原型，以发现潜在的问题。你们所有人都决定不做任何预先准备，但你们将以一种合理的结构化方式评估原型，首先考虑布局，其次考虑美观，之后再考虑导航选项，等等。作为设计师，你决定做一些笔记，但没有什么正式的。

原文:

　　Technical reviews can be classified as either formal or informal or somewhere in between these two extremes. The level of formality is chosen to match the type of product to be built, the project time line, and the people who are doing the work. Figure 16.2 depicts a reference model for technical reviews [Lai02] that identifies four characteristics that contribute to the formality with which a review is conducted. Each of the reference model characteristics helps to define the level of review formality. The formality of a review increases when (1) distinct roles are explicitly defined for the reviewers, (2) there is a sufficient amount of planning and preparation for the review, (3) a distinct structure for the review (including tasks and internal work products) is defined, and (4) follow-up by the reviewers occurs for any corrections that are made. An element that is not presented in this model is the frequency of the reviews themselves. If you are using an agile prototyping model (Chapter 4) that contains relatively short sprints, your team may opt for less formal reviews because the reviews are happening fairly often. This usually means that defects are caught sooner and more often. To understand the reference model, let’s assume that you’ve decided to review the interface design for SafeHomeAssured.com. You can do this in a variety of different ways that range from relatively casual to extremely rigorous. If you decide that the casual approach is most appropriate, you ask a few colleagues (peers) to examine the interface prototype in an effort to uncover potential problems. All of you decide that there will be no advance preparation, but that you will evaluate the prototype in a reasonably structured way—looking at layout first, aesthetics next, navigation options after that, and so on. As the designer, you decide to take a few notes, but nothing formal.

翻译：

　　但如果界面对整个项目的成功至关重要呢？如果人类的生活依赖于符合人体工程学的界面呢？你可能会认为有必要采取更严格的方法。将成立一个审查小组。团队中的每个人都有一个特定的角色来领导团队，记录发现，展示材料，等等。在评审之前，每个评审员都有权访问工作产品（在本例中是接口原型），并花时间查找错误、不一致和遗漏。将根据审查前制定的议程执行一系列具体任务。审查的结果将正式记录下来，小组将根据审查的结果决定工作产品的状态。审查小组成员还可以核实所作的更正是否正确。在这本书中，我们考虑两大类技术评论：非正式评论和更正式的技术评论。在每个类别中，可以选择许多不同的方法。以下各节将介绍这些内容。

原文:

　　But what if the interface is pivotal to the success of the entire project? What if human lives depended on an interface that was ergonomically sound? You might decide that a more rigorous approach was necessary. A review team would be formed. Each person on the team would have a specific role to play—leading the team, recording findings, presenting the material, and so on. Each reviewer would be given access to the work product (in this case, the interface prototype) before the review and would spend time looking for errors, inconsistencies, and omissions. A set of specific tasks would be conducted based on an agenda that was developed before the review occurred. The results of the review would be formally recorded, and the team would decide on the status of the work product based on the outcome of the review. Members of the review team might also verify that the corrections made were done properly. In this book we consider two broad categories of technical reviews: informal reviews and more formal technical reviews. Within each category, a number of different approaches can be chosen. These are presented in the sections that follow

翻译：

16.5非正式审查

　　非正式评审包括与同事对软件工程工作产品进行简单的桌面检查、为评审工作产品而举行的临时会议（涉及两人以上）或成对编程的评审导向方面（第3章）。简单的桌面检查或与同事进行的非正式会议就是一次回顾。然而，由于没有事先规划或准备，没有议程或会议结构，也没有对所发现的错误采取后续行动，这种审查的效力远远低于更正式的做法。但是一个简单的桌面检查可以并且确实发现错误，否则可能会进一步传播到软件过程中。提高桌面检查评审效率的一种方法是为软件团队生产的每个主要工作产品开发一套简单的评审清单2。清单中提出的问题是通用的，但它们将在评审人员检查工作产品时起到指导作用。例如，让我们重新检查safehomeassered.com的接口原型的桌面检查。设计师和一位同事不只是在设计师的工作站上玩原型，而是使用界面检查表检查原型：∙

布局是否使用标准惯例设计？从左到右？从上到下？

演示文稿是否需要滚动？

是否有效地使用了颜色和位置、字体和尺寸？

所有导航选项或功能是否在同一抽象级别上表示？

是否所有导航选项都有清晰的标签？

　　等等。评审员发现的任何错误或问题由设计人员记录，以便日后解决。桌面检查可以临时安排，也可以作为良好软件工程实践的一部分强制进行。一般来说，要审查的材料数量相对较少，而花在桌面检查上的总时间也不超过1或2小时。在第3章中，我们以如下方式描述了成对编程：XP建议两个人在一个计算机工作站上一起工作，为一个故事创建代码。这为实时问题解决（两个头往往比一个头好）和实时质量保证提供了一种机制。成对编程（第3.5.1节）可描述为连续的桌面检查。结对编程鼓励在创建工作产品（设计或代码）时进行连续评审，而不是在某个时间点安排评审。这样做的好处是可以立即发现错误并提高工作产品质量。一些软件工程师认为，在成对编程中内置的固有冗余是浪费资源。毕竟，为什么要给一个人能完成的工作指派两个人？这个问题的答案可以在16.3节中找到。如果成对编程所产生的工作产品的质量明显优于个人的工作，那么与质量相关的节省就足以证明成对编程所隐含的“冗余”是合理的。

原文:

　　Informal reviews include a simple desk check of a software engineering work product with a colleague, a casual meeting (involving more than two people) for the purpose of reviewing a work product, or the review-oriented aspects of pair programming (Chapter 3). A simple desk check or a casual meeting conducted with a colleague is a review. However, because there is no advance planning or preparation, no agenda or meeting structure, and no follow-up on the errors that are uncovered, the effectiveness of such reviews is considerably lower than more formal approaches. But a simple desk check can and does uncover errors that might otherwise propagate further into the software process. One way to improve the efficacy of a desk check review is to develop a set of simple review checklists2 for each major work product produced by the software team. The questions posed within the checklist are generic, but they will serve to guide the reviewers as they check the work product. For example, let’s reexamine a desk check of the interface prototype for SafeHomeAssured.com. Rather than simply playing with the prototype at the designer’s workstation, the designer and a colleague examine the prototype using a checklist for interfaces: ∙ Is the layout designed using standard conventions? Left to right? Top to bottom? ∙ Does the presentation need to be scrolled? ∙ Are color and placement, typeface, and size used effectively? ∙ Are all navigation options or functions represented at the same level of abstraction? ∙ Are all navigation choices clearly labeled? and so on. Any errors or issues noted by the reviewers are recorded by the designer for resolution at a later time. Desk checks may be scheduled in an ad hoc manner, or they may be mandated as part of good software engineering practice. In general, the amount of material to be reviewed is relatively small and the overall time spent on a desk check spans little more than 1 or 2 hours. In Chapter 3, we described pair programming in the following manner: XP recommends that two people work together at one computer workstation to create code for a story. This provides a mechanism for real-time problem solving (two heads are often better than one) and real-time quality assurance. Pair programming (Section 3.5.1) can be characterized as a continuous desk check. Rather than scheduling a review at some point in time, pair programming encourages continuous review as a work product (design or code) is created. The benefit is immediate discovery of errors and better work product quality. Some software engineers argue that the inherent redundancy built into pair programming is wasteful of resources. After all, why assign two people to a job that one person can accomplish? The answer to this question can be found in Section 16.3. If the quality of the work product produced as a consequence of pair programming is significantly better than the work of an individual, the quality-related savings can more than justify the “redundancy” implied by pair programming.

 

　　3下载熟悉不同编程语言代码规范方面：下载Pycharm软件，并进行简单的调试。

二、实践学习      

   以慕课编程为例，学习Pycharm等集成环境中自动进行代码规范检查与性能测试如下：

　　1、完成了pycharm平台的搭建

  　　 

　　2.电脑太老，死机状态经常出现。

三、总结

　　 初次使用Pycharm，不熟悉的地方很多，下载软件后，发现电脑死机次数较多，难以进行正常的编程学习，计划后期先把理论部分好好先巩固好，后期再学校去在找一个好点的电脑进行实际操作。现在想想恰是这些，更是体现了资金的电脑知识还是很缺乏，学习软件工程这门课的需要，相信在更多的尝试和探索中会有更大的进步。同时，感觉软件工程相关课程学习时，还是需要有人指点下就更好了，期待开学，学习效率就会有很大的提高。

 

 

 

 

软件工程第一次作业

林育锋

一、个人情况介绍

       本人林育锋，在职人员。目前录取为舰船材料方向，本科和研究生都没怎么学习过软件编程，除了会点C语言，工作这么多年，也忘记等差不多了，借这次选修软件工程这门课程，好好补补课，感谢各位同仁的帮助和不啬赐教。

二、阅读讲义后的读后感

       阅读相关讲义后，发现本门课程需要有一定的编程基础，而本门课程更是一门系统的学科，不仅会编程，而且会测试，会设计等，要求比较高，等学会了基本可以达到比较专业的人员水平，感觉差距挺大。有挑战，才是动力。决定先试试，说不定就成功了呢。

三、实践学习

　　目前还没有开始实践，准备接下来开始边学习python语言，边开始编程实践。

四、学习记录

　　1、对学堂在线中软件工程课程第一章的学习，学习成果和测试如下所示：

 　　        

　　2、Python 编程语言的基础学习，从学习时间2月18日开始进行。

五、总结

       初次注册博客，完全是为了学习要求，使用有很多不会操作的地方，目前连上传一篇博文都没有很好地完成，主要还是电脑知识的缺乏和对微博的操作不熟悉所致。软件工程既是自己选的一门课，原先的主要目标就是增长自己的电脑软件编程能力，虽然是我选择的两门选修课中的一门，尽最大努力学好才是关键，何况还有教员的指导帮助。