软件工程 作业题谷歌翻译及参考资料汇总

第三章作业：

3.2

   讨论3.1节所描述的不同过程流之间的区别。你是否能够确定适用于所描述的每种通用流的问题类型?

1、讨论3.1节所描述的不同过程流之间的区别。你是否能够确定适用于所描述的每种通用流的问题类型？
线性过程流从沟通到部署顺序执行五个框架流程
答：（1）线性过程流不能很好地适应变化，但是如果一个团队正在构建一个与他们之前做过的事情相似的例行产品，那么它是好的。b)迭代过程流通过在开发中间工作产品时构建审查机会来更好地处理变化。通常在构建涉及开发团队新技术的系统时使用。
（2）演进过程模型通常用于需要快速开发的项目(如WebApps)，但需要以可控的方式避免不必要的返工。
（3）迭代过程流通过在开发中间工作产品时构建审查机会来更好地处理变化。通常在构建涉及开发团队新技术的系统时使用。
（4）并行过程流具有允许对由子系统组成的系统同时开发自包含的工作产品的潜力。
————————————————
Problem:
Discuss the differences among the various process flows described in Section 3.1. Can you identify types of problems that might be applicable to each of the generic flows described?
Answer:
The software engineering process basically defines 5 framework activities. They are communication, planning, modeling, construction and deployment. They four types of process flow begin with communication activity.
软件工程过程基本上定义了5个框架活动。它们是沟通，规划，建模，建设和部署。它们有四种类型的流程流，从通信活动开始。

Difference between the various process flows are described in section 3.1 are given in table below:-
各工艺流程之间的差异在3.1节中描述如下表所示：-

The problems that are faced by the generic flows described in section 3.1 are:-
第 3.1 节中描述的通用流所面临的问题是：-

• Linear process flow:
• 线性工艺流程：

o Unpredicted integration issues can crop up.
o 可能会出现不可预测的集成问题。

o Defects can be traced to previous activities that is they are identified later.
o 缺陷可追溯到以前的活动，即以后识别它们。

o It is difficult for clients to state all requirements just initially.
o 客户很难在一开始就说明所有要求。

• Iterative process flow:
• 迭代工艺流程：

o It can lead to a blocking state.
o 它可能导致阻塞状态。

o More time is spent waiting than for production
o 等待时间多于生产时间

• Evolutionary process flow:
• 演进过程流程：

o Project team waits for the earlier activity to finish.
o 项目团队等待较早的活动完成。

o Developers can end up making compromises in implementation.
o 开发人员最终可能会在实现中做出妥协。

• Parallel process flow:
• 并行工艺流程：

o It can cause confusion in the project team as it proceeds.
o 它可能会在项目团队中引起混乱。

o It demands a good experts in risk assessment.
o 它需要一个好的风险评估专家。

————————————————
版权声明：本文为CSDN博主「/1」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mike6606/article/details/112865032
第四章作业：

4.2

  详细描述三个适于采用原型模型的软件项目
2.6详细描述三个适用于采用原型模型的软件项目。 

答:相对容易的原型模型几乎总是涉及人机交互和/或复杂计算机图形软件应用

程序，有时适合原型模型是某些类别的数学算法，命令驱动系统和其他应用在没有实时交互时结果可以很容易地检查。难以用原型模型的应用程序，包括控制和过程控制功能许多种类的实时应用程序和嵌入式软件。
Answer:
Software applications that are relatively easy to prototype almost always involve human-machine interaction.
相对容易制作原型的软件应用程序几乎总是涉及人机交互。

When the customer has a legitimate need but is clueless about the details then develop a prototype as a first step. A customer defines a set of general objectives. For these applications that are amenable to prototyping are certain classes of mathematical algorithms, subset of command driven systems and other applications where results can be easily examined without real-time interaction.Example software projects for prototyping.
当客户有合法需求但对细节一无所知时，作为第一步开发原型。客户定义一组一般目标。对于这些适合原型设计的应用程序，某些类别的数学算法，命令驱动系统的子集以及其他无需实时交互即可轻松检查结果的应用程序。用于原型设计的示例软件项目。

(1) Web based projects:
（1） 基于网络的项目：

Like any other projects, web based projects also have users, requirements, schedules to be met and quality goals. Aspects of project management, requirements management, change control and quality management are applicable to web projects also.
与任何其他项目一样，基于Web的项目也有用户，要求，要满足的时间表和质量目标。项目管理，需求管理，变更控制和质量管理的各个方面也适用于Web项目。

The difficulty in fully specifying the requirements at the beginning of the project makes the conventional waterfall model unsuitable for web application development. In the traditional prototyping model, the prototype is essentially for capturing the requirements and is thrown away as soon as purpose is served.
在项目开始时完全指定需求的困难使得传统的瀑布模型不适合Web应用程序开发。在传统的原型模型中，原型本质上是用于捕获需求，一旦达到目的就会被丢弃。

(2) Projects that need better human – computer interfaces will benefit a lot from the prototyping
（2）需要更好的人机界面的项目将从原型设计中受益匪浅

(3) Many engineering & scientific projects that involves large investments follow partying.
（3）许多涉及大额投资的工程/科学项目都遵循聚会。

————————————————
版权声明：本文为CSDN博主「/1」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mike6606/article/details/112868505
————————————————

第四章作业：

4.6

    可以合用几种过程模型吗？ 如果可以，举例说明。
2.10可以合用几种过程模型吗,如果可以，举例说明。 

答:过程模型可以合用，每个模型都有个有点不同的处理流程，但都执行相同的通用框架活动集:沟通，规划，建模，施工和交付/反馈。例如线性顺序模型可以作为一个有用的过程模型，在被固定的情况下，要求工作以线性的方式继续进行，直至完成。在这情况下，开发者可能无法确定一种算法的效率，一个操作系统的适应性或应采取的人机交互的形式。在这之中，以及许多其他场合原型模型可以提供最好的办法。在其他情况下，以渐进的方式可能是有意义的和螺旋模型的流动可能是有效率，特殊过程模型具有许多的一个或多个传统的特性。
Problem:
Is it possible to combine process models? If so, provide an example.
Answer:
Combine Process Models
合并流程模型

Yes, it is possible to combine the software process models.
是的，可以组合软件过程模型。

Some possibilities to combine of software process models are given below,
下面给出了一些组合软件过程模型的可能性，

1. Evolutionary process model.
   1）进化过程模型。

2. Incremental process model.
   2） 增量流程模型。

3. The spiral model.In the evolutionary process models create gradually more complete version of software and a complete cycle of activities is repeated for each version.In the Incremental process model produces a series of releases that provide more functionality for customer needs and increments are individually designed tested and delivered at successive points of time.In the spiral model produces the potential for fast development of progressively more complete versions of the software. It combines the features of the prototyping model and the waterfall model.Example projects:
   3）螺旋模型。在进化过程中，模型逐渐创建更完整的软件版本，并且为每个版本重复一个完整的活动周期。在增量流程模型中，生成一系列版本，这些版本为客户需求提供了更多功能，并且增量经过单独设计，并在连续的时间点交付。在螺旋模型中产生了快速开发逐步更完整的软件版本的潜力。它结合了原型模型和瀑布模型的功能。示例项目：

Let us consider the case study of department of defense.
让我们考虑一下国防部的案例研究。

It follows waterfall model or an incremental model. But if we need to develop software based on some other software features, go with component based model. If time is the major factor apply rapid application model.
它遵循瀑布模型或增量模型。但是，如果我们需要基于其他一些软件功能开发软件，请使用基于组件的模型。如果时间是主要因素，应用快速应用模型。

Hence we can combine evolutionary, incremental and spiral process models to develop single software. In medical and research projects also we can combine these process models.
因此，我们可以结合进化，增量和螺旋过程模型来开发单个软件。在医学和研究项目中，我们也可以结合这些过程模型。
————————————————
版权声明：本文为CSDN博主「/1」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mike6606/article/details/112868505
————————————————

第四章作业：

4.8

 开发质量“足够好”的软件，其优点和缺点是什么？也就是说，当我们追求开发速度胜过产品质量的时候，会产生什么后果？
2.12开发质量“足够好”的软件，其优点和缺点是什么,也就是说，当我们追求开发速度胜过产品质量的时候，会产生什么后果, 

答:开发质量“足够好”的软件可能会碰到死亡线(截止时间)，但质量会是比

较好的。当追求开发速度超过了产品的质量，这可能会导致许多缺陷，该软件可能需要更多的测试，设计和实施工作。需求定以的不是很清楚，可能需要不断地改变。半调子和速度过快开发都可能导致无法检测到重大的项目风险。质量太差可能导致过多的质量问题和频繁的返工。
答：开发质量“足够好”的软件的好处是产品或软件将满足最后期限，但它可能导致交付的软件质量较低。当速度比产品质量更重要时，可能会导致许多缺陷，软件可能需要更多的测试、设计和实现工作。需求可能没有很好的定义，并且可能需要不断地改变。半心半意和速度可能导致风险管理无法发现主要的项目风险。太少的质量可能导致质量问题和后期的返工。
Problem:
What are the advantages and disadvantages of developing software in which quality is “good enough”? That is, what happens when we emphasize development speed over product quality?
Answer:
The advantages of developing software in which quality is “good enough” are
开发质量“足够好”的软件的优势是
• Completeness – All the requirements are reflected in the software
•完整性 - 所有要求都反映在软件中
• Conciseness – Compactness
• 简洁 – 紧凑
• Reliability – No faulty outputs
• 可靠性 – 无故障输出
• Improved user satisfaction.
• 提高用户满意度。
• Reduced cost of maintenance
• 降低维护成本
• Efficiency – Amount of computing resources and cost required by a program to perform a function.
•效率 - 程序执行功能所需的计算资源和成本的数量。
• Consistency.
• 一致性。

We have to compromise with the advantages of quality software, where speed is major constraint but the speed has its own pros and cons.//We have to compromise with the advantages of quality software, where speed is major constraint but the speed has its own pros and cons.
我们必须与高质量软件的优势妥协，其中速度是主要限制因素，但速度有其自身的优缺点。我们必须与高质量软件的优势妥协，其中速度是主要限制因素，但速度有其自身的优缺点。
• Developing in short intervals resulting in miniature software projects and releasing the product in mini – increments but short iterations may not add enough functionally leading to significant delays in final iteration.
在短时间内开发，导致微型软件项目，并以迷你增量发布产品，但短迭代可能无法在功能上增加足够的功能，导致最终迭代出现重大延迟。

• Speedy software promotes strong collaborative atmosphere and dynamic gathering of requirements but dependency on strong cohesive teams and individual commitment to the project
快速的软件促进了强大的协作氛围和动态的需求收集，但依赖于强大的凝聚力团队和个人对项目的承诺
————————————————
版权声明：本文为CSDN博主「/1」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mike6606/article/details/112868505

————————————————

第四章作业：

4.11

统一过程和UML是同一概念吗？请解释你的答案。
2.15统一过程和UML是同一概念吗,解释你的答案。 

答:UML提供了必要的技术支持和面向对象的软件工程实践。但它并不提供流程框架来指导项目团队，在他们的技术应用中。在近几年中，雅各布森， Rumbaugh和Booch制定的统一过程中框架使用UML的面向对象的软件工程。今天，统一的流程和UML被广泛应用于各种面向对象的项目。

它们不是统一概念。统一过程是一种建模方法，是对UML使用最全面，最复杂的一种。UML定义了基本元素，定义了语法，但是如果要做一个软件项目，还需要有方法指导。统一过程是与UML集成最好，最完整的软件方法。统一过程并非是因为UML才诞生，是归纳和整理了很多在实践中总结出来的软件工程的最佳实践，是一个采用了面向对象思想，使用UML作为软件分析设计语言，并且结合了项目管理，质量管理等许多软件工程知识综合而成的一个非常完整和庞大的软件方法。今天统一的流程和 UML 被广泛应用于各种面向对象的项目。
Are the Unified Process and UML the same thing? Explain your answer.
Answer:
Unified process and UML

No, Unified process and the UML is not the same thing.
不，统一进程和UML不是一回事。
Unified process:
统一流程：

The Unified process is a type of framework, which is used for UML in software engineering. It is a popular iterative and incremental software development process which should be customized for specific organization or project.
统一流程是一种框架，用于软件工程中的 UML。这是一个流行的迭代和增量软件开发过程，应该针对特定的组织或项目进行定制。

Unified Modeling Language (UML):
统一建模语言 （ UML）：

UML is a standardized general – purpose modeling language in the field of software engineering. It is a modeling notation and language consists of a technology which supports the object-oriented (and conventional) software engineering practice.
UML是软件工程领域的标准化通用建模语言。它是一种建模符号，语言由支持面向对象（和传统）软件工程实践的技术组成。

And also, UML is a graphical language for visualizing, specifying, and constructing the artifacts of software – intensive systemExplanation:
而且，UML是一种图形语言，用于可视化，指定和构造软件的工件 - 密集型系统解释：

Both UML and unified process appears to be same thing on projects of all kinds. But there is a slight difference.
在各种项目中，UML和统一过程似乎是一回事。但略有不同。

1. UML is applied in the unified process.

2. 在统一流程中应用 UML。

3. UML does not provide the process framework to guide project teams in their application of the technology.

4. UML不提供流程框架来指导项目团队应用该技术。

5. Unified Process is a process framework in which UML may be applied as part of software engineering activities.

6. 统一流程是一个流程框架，其中 UML 可以作为软件工程活动的一部分进行应用。

A model is a complete description of a system from a particular perspective. But the UML alone is not enough. A process defines Who is doing? What, When to do it and How to reach a certain goal
模型是从特定角度对系统的完整描述。但仅靠UML是不够的。一个过程定义了谁在做什么？什么，何时做以及如何达到某个目标

Example:
例：

Agile Development is the process, it should use UML notation for produced diagrams as well."
敏捷开发是一个过程，它也应该使用UML符号来生成图表。
————————————————
版权声明：本文为CSDN博主「/1」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mike6606/article/details/112868505