南邮软件工程(双语)学习指南与复习资料

软件工程复习

1. 适用对象：南邮计算机学院全部专业，计科为双语教学，其他专业为中文教学可适当参考

2. 题型：判断题(T/F， 5题，10分)，问题分析（5题，30分），理解与沟通（3题，30分），分析设计（2题，30分）

3. 开卷考试，英文答题

4. 往年试卷：传送门

5. 想要文件可私信（收取一定费用）

零、常用英语词汇

• 多态 Polymorphism

• 利益相关者 stateholder

• 版型 stereotype

• 基于构件的软件工程 Component-Based Software Engineering, CBSE

• 体系结构原型 Archetype

• 增量 increment

• 重构 refactor

• 原型 Prototyping（旨在快速构建软件系统的一个或多个初步版本，供用户和开发团队评估和反馈。原型的主要目的是在开发早期阶段验证需求、设计和功能，减少项目风险，确保最终产品满足用户需求。）

• CRC (类-职责-协作者 是一种面向对象的设计工具，用于描述类、它们的职责和它们之间的协作。)

一、软件和软件工程（第一章）

1.软件和硬件的区别（P5-6）

1. Software is developed or engineered it is not manufactured in the classical sense.

2. Software doesn’t “wear out” but it does deteriorate.

3. Although the industry is moving toward component-based construction, most software continues to be custom-built.

1. 硬件是可替换的（零件统一标准，例如自行车的脚蹬坏了可以直接用一个新的脚蹬替换），软件是需要理解用户需求的基础上产生的。

2. 软件的要求比较高，不能大规模生产，要根据不同客户的需求进行生产。（用户提出需求，开发者确定需求）

3. 目前软件的发展方向是组件式发展，即可以修改部分模块。

软件=程序+数据+文档

软件和硬件失效率的解释：

硬件失效率曲线（左图）：

• 硬件的失效率随着时间的推移表现为一个“浴缸曲线”。
• 初始阶段的高失效率（称为“婴儿死亡率”），这是由于初期故障较多。
• 中期失效率较低且稳定。
• 最后阶段失效率再次升高，表示硬件开始“磨损”并逐渐失效。

软件失效率曲线（右图）：

• 软件的失效率在初始阶段较高，主要由于早期的缺陷和错误。
• 随着时间推移，失效率下降，但并不会像硬件那样达到一个恒定的低值，而是随着修改和更新（如图中标注的“更改”）可能再次升高。
• 这种波动的失效率是由于每次修改可能引入新的错误，导致失效率上升，随后再下降到一个较低的水平，但不会完全稳定。

2.软件过程（P10-11）

分为框架活动（the process framework）和普适性活动（umbrella activities）

框架活动：沟通（communication）、计划（planning）、建模（modeling）、构建（construction）部署（deployment），是和产生软件产品直接相关的

普适性活动是管理的，和软件产品生产不直接相关，贯穿于整个项目过程（applied throughout a software project）

Description of the Five Framework Activities (6 points)

1. Communication: Involves gathering requirements through stakeholder meetings, interviews, and discussions to understand the project goals and constraints.
2. Planning: Entails defining the project scope, estimating costs, scheduling tasks, and allocating resources to create a project plan.
3. Modeling: Focuses on creating design models, such as UML diagrams, to represent the system architecture and components.
4. Construction: Involves the actual coding, testing, and debugging of the software components to build the system.
5. Deployment: Includes delivering the completed software to users, providing documentation, and training, and ensuring the system operates as intended in its environment.

Adjustments for Different Projects (9 points)

1. Project Size: Smaller projects may require less formal communication and modeling activities, while larger projects may need detailed planning and comprehensive modeling.
2. Team Experience: Experienced teams might streamline certain activities, while less experienced teams may need more detailed documentation and reviews.
3. Project Complexity: Complex projects may require more iterative modeling and testing phases, whereas simpler projects can move more linearly through the phases.
4. Stakeholder Involvement: Projects with high stakeholder involvement may need more frequent communication and feedback loops.
5. Risk Management: High-risk projects might require more extensive planning and risk mitigation strategies.
6. Timeline Constraints: Projects with tight deadlines may need to prioritize key features and possibly adopt agile methodologies for iterative development.

3.软件工程的本质（P12）

1. Understand the problem (communication and analysis).

2. Plan a solution (modeling and software design).

3. Carry out the plan (code generation).

4. Examine result for accuracy (testing & quality assurance).

理解问题（需求分析）、制定计划（需求建模和软件设计）、执行计划（生产代码）、检查结果（测试准确性）

4.软件工程的设计原则（P14-15）

• The Reason It All Exists - provide value to users.

• KISS (Keep It Simple, Stupid!) - design simple as it can be.

• Maintain the Vision – clear vision is essential.

• What You Produce, Others Will Consume.

• Be Open to the Future - do not design yourself into a corner.

• Plan Ahead for Reuse – reduces cost and increases value.

• Think! – placing thought before action produce results.

最重要的两条规则：
1.面向未来（Be Open to the Future）：体系结构的设计

例如女士养宠物的例子中，目前女士提出的是养猫，但是如果只实现养猫的话，不具有可扩展性，即无法面向未来，所以应该实现宠物的抽象类，这样以后女士提出养狗、鸟等不同宠物时，不用修改太多，这里就是用到了多态的概念

2.提前计划复用（Plan Ahead for Reuse）：降低项目成本，提升价值

包括知识复用（分析结果复用，即分析模型）、方法复用（设计结果复用，设计模型）、软件成分复用（代码复用），继承是共性局限性大（共性东西少），结构化关联

5.封装、继承、多态

程序中实现多态（同样的行为调用不同的服务）的方法：

1. 子类继承父类（子类重写父类的方法，父类的变量指向子类的对象）

2. 具体类实现接口 （具体类重写接口的方法，用接口类指向具体类的对象）

Inheritance:

1. The subclass overrides methods of the superclass.
2. The superclass reference points to the subclass object.

Implementation:

1. The concrete class overrides methods of the interface.
2. The interface reference points to the concrete class object.

动态联编（dynamic binding）和滞后联编（late binding）是多态的概念，表示只有程序运行起来的时候才能真正确定子类对象，如女士养宠物中，宠物是一个抽象类，有猫狗等具体实现类，只有运行调用的时候才能知道是猫还是狗

静态联编（static binding）是重载的概念，编译过程就已经确定，不会涉及抽象类的变量

重载实现：

public class Driver {
    private String name;
    public Driver(String name) {
        super();
        this.name = name;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public void drive(Car c) {
        c.go(new Address("东北"));
    }
    public void drive(Car c, Address dest) {
        c.go(dest);
    }
}

多态实现：

public class Driver {
    private String name;

    public Driver(String name) {
        super();
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void drive(Vihecle v) {
        v.go(new Address("东北"));
    }

    public void drive(Vihecle v, Address dest) {
        v.go(dest);
    }
}

public class Address {
    private String name;

    public Address(String name) {
        super();
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

public abstract class Vihecle {
    public abstract void go(Address dest);
}

public class Car extends Vihecle {
    public void go(Address dest) {
        System.out.println("一路向北，驾着车，去了" + dest.getName());
    }
}

public class SubClass extends Vihecle {
    public void go(Address dest) {
        // 实现略
    }
}

public class Broom extends Vihecle {
    public void go(Address dest) {
        System.out.println("一骑扫帚上，笑呵呵，去了" + dest.getName());
    }
}

public class Test {
    public static void main(String[] args) {
        Driver d = new Driver("张三");
        Address ad = new Address("北京");
        d.setName("李四");
        System.out.println(d.getName());
        d.drive(new Car());
        d.drive(new Car(), ad);
    }
}

上述代码的类图

二、理解需求（第六章）

1.需求工程（P85）

是一个action，沟通----->策划----->建模----->构建----->部署，前三步属于需求工程，因项目而异

2.Establishing the Groundwork（根基）

1.stakeholder（P89）

• stakeholder利益相关者（对项目有直接或者间接贡献需求的人）

2.首次提问（P90-91）

三组问题，第一部分是目标与收益，第二部分是解决方案，第三部分是效率

注意考试会这三种问题各给出一种，问这个问题的重点和意义是什么，答案就是加粗部分

特点：上下文无关 ($context-free$)

The first set of questions focuses on the customer and other stakeholders and the overall project goals and benefits.

• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?

These questions help to identify all stakeholders who will have interest in the software to be built, and identify the measurable benefit of a successful implementation and possible alternatives to custom software development.

The second set of questions focuses on a solution.

• How would you characterize “good” output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution will be used?
• Will special performance issues or constraints affect the way the solution is approached?

These questions enable you to gain a better understanding of the problem and allows the customer to voice their perceptions about a solution.

The third set of questions (meta-questions) focuses on the effectiveness of the communication activity itself.

• Are you the right person to answer these questions? Are your answers “official”?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

These questions will help to “break the ice” and initiate the communication that is essential to successful elicitation.

3.Requirements Gathering（需求采集）P92

协作需求处理（开会），通过需求采集会议，来执行需求工程

三、需求建模（第七章）

基于场景的建模、基于类的建模、行为建模

1.<<include>>和<<extend>>

1. 画用例图，图中每个符号都不是多余的，向前反应需求，向后体现在代码中，用例图中的一个圈代表一个场景

2. <<include>>和<<extend>>

• <<include>>：表示强制性的包含关系。当执行事件 A 时，必然触发事件 B。用于提取公共功能和行为。

• <<extend>>：表示可选的扩展关系。当执行事件 A 且满足特定条件时，可以选择执行事件 B。用于描述可选行为和条件行为。

• 典型例题

User requirements described by <<include>>:

• Mandatory Behavior: The “Reserve Seat” use case includes the “Check Seat Availability” and “Install Seat” use cases. This means that whenever a user performs the “Reserve Seat” action, it will necessarily involve checking seat availability and installing the seat. The “Process Transaction” use case includes the “Generate Payment” use case, indicating that generating a payment is a required step in processing a transaction.

User requirements described by <<extend>>:

• Optional Behavior: The “Queue” use case extends the “Reserve Seat” use case. This extension means that while reserving a seat, the action of queuing might be performed under certain conditions (e.g., if all seats are initially booked and the user needs to wait for availability), but it is not a mandatory step every time “Reserve Seat” is executed.

2.面向对象的软件开发过程（画用例图的意义）（P113）

基于构件的软件工程（Component-Based Software Engineering, CBSE）

统一过程，用例驱动，面向对象的软件开发从画用例图开始，第一步是找actor（参与者，即各种角色使用软件的人和设备，比如教务管理系统里面学生、老师、教务管理人员），第二步找actor和系统之间的交互

Use-case as a “contract for behavior” and more formal than a user story.

• In essence, a use case captures the interactions that occur between producers and consumers of information and the system itself.

Use-cases are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).

1. What to write about?
2. How much to write about it?
3. How detailed to make your description?
4. How to organize the description?

3.类图中符号的含义

类之间的关系有泛化（继承）、关联、聚合、组合、依赖、实现

典型例题

In the class model shown in the figure, the meanings of “◊---->” and “◆---->” are as follows:

• “◊---->” represents an aggregation relationship. This means that the part (in this case, Engine) can exist independently of the whole (in this case, Car). The lifecycles of the whole and its parts are different, meaning that the parts can exist even if the whole is destroyed.
• “◆---->” represents a composition relationship. This means that the part (in this case, Mouth) cannot exist independently of the whole (in this case, Head). The lifecycles of the whole and its parts are the same, meaning that the parts cannot exist if the whole is destroyed.

User requirements:

• The aggregation relationship describes a user requirement where the Engine can be separately used or replaced without affecting the existence of the Car.
• The composition relationship describes a user requirement where the Mouth is an integral part of the Head, meaning the Mouth cannot exist if the Head does not exist.

4.对象图

对象图是类图的一张照片，变量和变量在某个时间点上存在的关系，程序在运行的过程中对象之间的链接关系，对象之间的关系就不是继承关联之类的，只有亲戚关系（即链接关系，因为对象是真实存在的）

左边的是类图，右边可能会询问哪些是该类的对象图，可以根据具体语义/环境关系，以及类图之间的关系来判断。

5.接口

实现设计类之间的可控连接（传统方法中叫模块之间的可控连接）、强调构件（即模块）的可替换性

6.设计模式

典型例题1（组合设计模式）

Answer to the Question

1. Using Composite Design Pattern
   To design and develop the system for the combination of fruit plates as shown in the figure, we use the Composite Design Pattern. This pattern allows us to compose objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly.

2. Key Classes and Relationships

   • Component(MyElement ): This abstract class declares the eat() method which will be implemented by all concrete classes.
   • Leaf (Apple, Banana, Pear): These classes represent individual fruits and implement the eat() method.
   • Composite (Plate): This class can contain other MyElement objects (either Apple, Banana, Pear, or other Plate objects). It provides methods to add and remove elements and implements the eat() method which iterates over its elements and calls their eat() method.

3. Design Highlights

   • Uniformity: Treats individual objects and compositions of objects uniformly.
   • Flexibility: Easily extendable by adding new types of fruits or plates.
   • Simplicity: Simplifies client code by allowing it to work with composite structures through a common interface.

典型例题2

1. Using Composite Design Pattern
   To design and develop a file system similar to the Windows resource manager as shown in the figure, we use the Composite Design Pattern. This pattern allows us to compose objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly.

2. Key Classes and Relationships

   • Component (FileSystemItem): This abstract class declares common methods such as open(), delete(), and rename(), which will be implemented by all concrete classes.
   • Leaf (File): Represents individual files and implements the methods defined in FileSystemItem.
   • Composite (Directory): Represents a directory that can contain other FileSystemItem objects (either File or other Directory objects). It provides methods to add and remove elements and implements the common methods declared in FileSystemItem.

3. Design Highlights

   • Uniformity: Treats individual files and directories uniformly.
   • Flexibility: Easily extendable by adding new types of files or directories.
   • Simplicity: Simplifies client code by allowing it to work with composite structures through a common interface.

7.行为建模（状态图和顺序图的区别）

状态图和顺序图的区别

状态图建模了一个对象的一生

顺序图建模了一个场景中对象发生的交互，自上而下有时间顺序

State Diagrams

State diagrams represent the active states of each class and the events (triggers) that cause changes between these active states.

• Active state models provide useful insights into the “life history” of an object, allowing for additional information to provide more depth in understanding the behavior of an object.

Key concepts include:

• Arrow: a transition from one active state of an object to another.
• Label on the arrow: the event that triggers the transition.
• Guard: a Boolean condition that must be satisfied for the transition to occur, depending on the passive state of the object.
• Action: occurs concurrently with or because of the state transition and generally involves one or more operations (responsibilities) of the object.

Sequence Diagram

Sequence diagrams can be used for behavioral modeling.

• They can show how events cause transitions from object to object.
• Once events have been identified by examining a use case, the modeler creates a sequence diagram — a representation of how events cause flow from one object to another as a function of time.

Sequence diagrams are a shorthand version of a use case.

典型例题

1. Sequence Diagram (图(a))
   Focus: Models interactions between objects in a specific scenario.
   Time Order: Shows the chronological order of messages exchanged, with events occurring from top to bottom.

2. State Diagram (图(b))
   Focus: Models the lifecycle of a single object.
   States and Transitions: Illustrates how an object transitions between different states based on events, capturing its entire lifecycle.

3. Explanation of Differences

• Sequence Diagram: Captures the interactions in a specific scenario, highlighting the sequence of messages between objects. It focuses on how different objects collaborate over time to complete a process.
• State Diagram: Captures the full lifecycle of an object, showing how it moves through various states in response to events. It emphasizes the dynamic behavior and state changes of a single object throughout its existence

四、设计（第八章）

设计过程、设计概念(重构、设计类)、设计模型

设计过程P142

1.显式需求和隐式需求

显式需求（explict requirements）是指用户说明的需求，即功能性需求，隐式需求(implict requirements)一般是非功能性需求（NFR,Non-functional requirements）

2.指导原则

共两组原则

1. Design should implement all explicit requirements contained in the requirements model, and it must accommodate all implicit requirements desired by stakeholders.

2. Design should be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.

3. Design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

A design should

1. exhibit an architecture (a) created using recognizable architectural styles or patterns, (b) composed of well-designed components, (c) implemented in an evolutionary fashion.

2. be modular (partitioned into elements or subsystems).

3. contain distinct representations of data, architecture, interfaces, and components.

4. lead to data structures that are drawn from recognizable data patterns.

5. contain functionally independent components.

6. lead to interfaces that reduce the complexity of connections between components and the external environment.

7. be derived using a repeatable method.

8. be represented using meaningful notation.

3.内聚与耦合（P149-152）

高内聚低耦合，内聚表示模块内部各个元素之间的关系，即模块内部元素各方法定义恰到好处；耦合是指模块与模块之间的关系，通过接口实现构建之间可控连接

• Cohesion:

  • Definition: It indicates the relative functional strength of a module.
  • Key Points:
    • It’s a natural extension of the information-hiding concept.
    • A cohesive module performs a single task, requiring little interaction with other components.

• Coupling:

  • Definition: It indicates the relative interdependence among modules.
  • Key Points:
    • It refers to the interconnections among modules.
    • Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

4.设计模型

1. 数据设计模型、体系结构设计、接口设计、构件级设计、部署级设计

2. 下面内容了解即可：

• Data design – using high level model depicting user’s view of the data or information (e.g., relational model).
  数据设计 – 使用高级模型描述用户视角的数据或信息（例如，关系模型）。
• Architecture design – show relationships & collaborations among major structured elements (specific analysis model soft- & hard-ware elements), implying by style, patterns, and constraints.
  架构设计 – 展示主要结构化元素之间的关系和协作（具体分析模型的软硬件元素），通过风格、模式和约束来体现。
• Interface design – interface depicts a set of operations describing the externally visible behavior of a class and provides access to its services.
  接口设计 – 接口描绘了一组操作，描述类的外部可见行为并提供对其服务的访问。
• Component-level design – the internal details of each component.
  组件级设计 – 每个组件的内部细节。
• Deployment-level design – indicates how software functionality and subsystems will be allocated in the physical computing environment that will support the software.
  部署级设计 – 指出软件功能和子系统如何在物理计算环境中分配，以支持软件。

5.接口的三个组成要素（分类）P157

用户接口、外部接口、内部接口

1.User Interface (UI)

• English: The user interface (UI) is the space where interactions between humans and machines occur. It encompasses the design and layout of a system’s visual elements, ensuring usability and a seamless user experience.
• Chinese: 用户界面（UI）是人机交互发生的空间。它包含系统视觉元素的设计和布局，确保可用性和无缝的用户体验。

2. External Interfaces to Other Systems

• English: External interfaces refer to the points of interaction where a system connects and communicates with other systems. These interfaces facilitate data exchange and integration, enabling systems to work together effectively.
• Chinese: 外部接口是系统与其他系统连接和通信的交互点。这些接口促进数据交换和集成，使系统能够有效地协同工作。

3. Internal Interfaces Between Various Design Components

• English: Internal interfaces are the connections within a system that link different design components. These interfaces allow for modular development, where components interact and integrate seamlessly within the system’s architecture.
• Chinese: 内部接口是系统内部连接不同设计组件的连接点。这些接口允许模块化开发，使组件在系统架构中无缝地交互和集成。

6.重构（P150）

通过重构可以使得设计容易集成、测试和维护，不改变接口，而改变其中的算法，即接口对外的功能保持不变，但是实现方式改变以增加效率

What is design refactoring?

• A reorganization technique of changing a software system in such a way that simplifies the design (or code) without altering functionality (and the external behavior) yet improves its internal structure.

When software is refactored, the existing design is examined for … that can be corrected to yield a better design.

• redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failure.

Why: is easier to integrate, to test, to maintain.

7.组织良好的设计类

• Problems in the Design (4 points)

  1. Role Confusion: The Driver class includes go() and stop() methods, which are responsibilities that should belong to the Car class, leading to unclear responsibilities.
  2. High Coupling: The Driver class directly controls the behavior of the Car class, increasing coupling between the classes, making maintenance and extension difficult.
  3. Poor Extensibility: Adding more vehicle operations would require frequent modifications to the Driver class, which does not comply with the open-closed principle.

• Evaluating a “Well-Organized” Design Class (6 points)

  1. Complete and Sufficient:
     • Each class should contain all necessary attributes and methods to fulfill its responsibilities but should not include unnecessary elements.
     • For example, the Car class should contain all methods related to vehicle operations, while the Driver class should only contain information and operations related to the driver.
  2. Primitiveness:
     • Methods within a class should be basic operations and should not be subdivided further.
     • For example, the Car class should have a drive() method that encompasses the implementations of go() and stop() without requiring the Driver class to handle these details.
  3. High Cohesion:
     • The methods and attributes within a class should be closely related and focused on a single responsibility.
     • For example, all methods in the Car class should directly relate to vehicle operations, and methods in the Driver class should relate to the driver’s actions and state.
  4. Low Coupling:
     • Dependencies between classes should be minimized, reducing direct interaction between classes.
     • For example, the Driver class should not directly control the Car class’s operations but should interact through an interface or an abstraction layer.

五、体系结构（第九章）

1.定义、重要性、决策（P164-166）

定义：软件的整体结构

• Architecture is not the operational software, it is a representation that enables a software engineer to:

  1. Analyze the effectiveness of the design in meeting its stated requirements,

  2. Consider architectural alternatives at a stage when making design changes is still relatively easy,

  3. Reduce the risks associated with the construction of the software.

重要性：最重要的就是利益相关者的沟通

1. Architecture provides a representation that facilitates communication among all stakeholders.

2. Architecture highlights early design decisions that will have a profound impact on all SE work that follows, and plays an important role in the success of the system as a runnable entity.

3. Architecture constitutes a relatively small model (a set of abstractions) of how the system components are structured and work together.

翻译

1. 架构提供了一种表示方式，促进所有利益相关者之间的沟通。

2. 架构强调早期设计决策，这些决策将对所有后续的软件工程工作产生深远影响，并在系统作为可运行实体的成功中发挥重要作用。

3. 架构构成了一个相对较小的模型（一组抽象），描述了系统组件如何结构化和协同工作。

决策：早期决策对项目成功起至关重要的部分，如女士养宠物（上面面向未来部分已经详细解释过）

2.风格与模式

• 风格实际描述一组通用的类别，是一个整体性描述

• 模式是局部范围内的，模式是一组抽象类（abstract class），不是写好的代码，如女士养宠物中宠物就是模式

风格与模式的区别P169
风格由四个部分组成：一组构件、一组连接件、一组约束、一个语义模型
What are the elements that make up the software architectural style?
Each style describes a system category that encompasses:

1. a set of components (e.g., a database, computational modules) that perform a function required by a system,
2. a set of connectors that enable “communication, coordination and cooperation” among components,
3. constraints that define how components can be integrated to form the system, and
4. semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

3.体系结构原型(模式)

体系结构原型（Archetype）对应的就是模式的概念

What is an archetype?

The target system architecture is composed of a relatively small set of archetypes.

• Archetype design is critical to the design of an architecture.

An archetype

• is a class or pattern that represents a stable element with a core abstraction for the target system.
• may be instantiated iteratively many different ways based on the behavior of the system.
• can be derived by examining the analysis classes defined as part of the requirements model.

课本上的家庭安保系统这个模型实质上也是组合设计模式

六、构件设计（第十章）

1.三组不同观点（什么是构件）

OO-View: a component contains a set of collaborating classes.

• A class is related to the problem domain and infrastructure domain.
• Classes are elaborated by defining all attribute data structures, describing process flow for operations, specifying messaging details for interfaces.

Traditional-View: a module is a functional element of a program.

• three types of modules: control, business, infrastructure.
• All modules require representations to be created for processing logic, the internal data structures, and an interface that enables the modules to be invoked and data to be passed to it.

A Process-Related View: CBSE, assembling architecture by reusing components or design patterns.

OO观点：一个组件包含一组协作的类。构件就是一组协作的类，一组类之间的关系

• 一个类与问题域和基础设施域相关。
• 类通过定义所有属性数据结构、描述操作的过程流程、指定接口的消息细节来进行详细说明。

传统观点：一个模块是程序的功能元素。构件就是模块可以直白理解为函数

• 三种类型的模块：控制、业务、基础设施。
• 所有模块都需要创建表示来处理逻辑、内部数据结构，以及使模块能够被调用和传递数据的接口。

过程相关观点：CBSE，通过重用组件或设计模式来组装架构。

2.设计原则P194

component design principles

开闭原则、里氏替换原则、依赖倒置原则、接口分离原则

1. Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification.”

2. Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base classes.”

3. Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions.”

4. Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one general purpose interface.”

翻译

1. 开放封闭原则 (OCP)：该原则建议软件实体（如类、模块和函数）应该对扩展开放，但对修改关闭。这意味着模块的行为可以通过扩展来增加功能，而无需修改其源代码，从而促进使用接口和抽象类。另外对于修改而言，仅仅只需要修改一个模块当中的内容，不需要修改其他模块当中的内容，不会蔓延。目标

2. 里氏替换原则 (LSP)：根据该原则，超类的对象应该可以被其子类的对象替换，而不会影响程序的功能。这确保了子类可以替代其父类，从而支持多态性。手段 利用里氏替换原则，实现了开放封闭原则

3. 依赖倒置原则 (DIP)：该原则提倡高层模块不应该依赖于低层模块，而是两者都应该依赖于抽象。此外，抽象不应该依赖于细节；细节应该依赖于抽象。这有助于减少软件组件之间的耦合。手段

4. 接口隔离原则 (ISP)：该原则指出，客户端不应该被迫依赖于它们不使用的接口。它建议为每组功能创建特定的接口，而不是使用单一的通用接口。这样可以确保系统更容易理解和维护，接口的大小正好满足需要。（瘦接口比胖接口更好）

对于这类题目常见的问题是，给出一个类图，问题：针对这样一个问题的设计方案，运用了什么样

的设计原则，体现了什么样的设计概念，它的的好处是什么？

1. 阐述面向对象的多态概念 – OO的概念

2. 这样的设计方案，运用了里氏替换原则和依赖倒置原则，解释一下这两个原则，从而实现了开闭原则，做到了对外延具有开放性，对修改具有封闭性；

3. 好处：可扩展性和可维护性

典型例题1（通过接口实现的多态）

1. Concept of Polymorphism

Polymorphism is a fundamental concept in object-oriented programming that allows objects of different classes to be treated as objects of a common superclass. It is achieved through method overriding, where a subclass provides a specific implementation of a method already defined in its superclass. In this context, TravelStrategy is an interface, and AirplaneStrategy, TrainStrategy, and BicycleStrategy are different implementations of this interface. The Person class can use any of these strategies interchangeably.

2. Principles Applied

• Open-Closed Principle (OCP): The system is open for extension but closed for modification. By defining the TravelStrategy interface, new travel methods can be added without modifying existing code. For instance, if a new travel strategy CarStrategy is introduced, it can be added by simply implementing the TravelStrategy interface.
• Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. In this design, any implementation of TravelStrategy can replace another without altering the functionality of the Person class.
• Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules but on abstractions. The Person class depends on the TravelStrategy interface (abstraction) rather than specific travel strategy implementations.

3. Replaceability and Maintainability and Extensibility

• Maintainability: The system is easy to maintain and extend. New travel strategies can be added with minimal changes to existing code, enhancing the system’s flexibility and reducing the risk of introducing bugs.
• Extensibility: New travel modes can be added easily by creating new strategy classes that implement the TravelStrategy interface. This does not require any changes to the existing classes.

典型例题2（通过继承实现的多态）

Open-Closed Principle:

• Classes are open for extension but closed for modification. The Shape class is the base, and new shapes (Rectangle, Circle, Polygon) extend it without altering its code.

Liskov Substitution Principle:

• Subclasses can replace the superclass without affecting functionality. Any Shape instance can be replaced with Rectangle, Circle, or Polygon, as they implement the same methods.

Dependency Inversion Principle:

• High-level modules depend on abstractions, not concrete classes. The system depends on the abstract Shape class, allowing easy substitution and addition of new shapes.

典型例题3（接口分离原则）

Interface Segregation Principle: The Interface Segregation Principle states that no client should be forced to depend on methods it does not use. This model adheres to this principle in the following ways:

1. Separation of Concerns:
   • The functionalities are divided into different interfaces: DeviceSet and VideoManagement. Each interface contains methods specific to its domain (e.g., device management vs. video management), ensuring that clients only implement and depend on methods relevant to their needs.
2. Concrete Implementation:
   • ConcreteService implements both DeviceSet and VideoManagement interfaces. This allows for a modular approach where the implementation class can be extended or modified without affecting the client code that relies on these interfaces.

典型例题4

Basic Object-Oriented Concepts Reflected in the Design (6 points)

1. Encapsulation: Each class (PlayerBody, PlayerArms, PlayerLegs, PlayerHead) contains its own attributes (position, orientation, color, speed) and methods (update(), display()).
2. Inheritance: Player class is a base class that provides common attributes and methods, which are inherited by the subclasses (PlayerBody, PlayerArms, PlayerLegs, PlayerHead).
3. Polymorphism: The subclasses (PlayerBody, PlayerArms, PlayerLegs, PlayerHead) override the update() and display() methods, allowing for different implementations.

Application of OO Principles to Satisfy OCP, DIP, and LSP (9 points)

1. Open-Closed Principle (OCP):
   • The design is open for extension but closed for modification. New player parts can be added as subclasses without modifying the existing Player class.
   • The interface GameRule allows for new rules and behaviors to be added without altering existing code.
2. Dependency Inversion Principle (DIP):
   • High-level modules (e.g., Player class) do not depend on low-level modules (e.g., PlayerBody, PlayerArms). Instead, both depend on abstractions (GameRule interface).
   • The Player class interacts with player parts through the GameRule interface, reducing dependency on specific implementations.
3. Liskov Substitution Principle (LSP):
   • Subclasses (PlayerBody, PlayerArms, PlayerLegs, PlayerHead) can replace the Player class without affecting the functionality. They provide their own implementation of update() and display(), adhering to the base class and interface contracts.
   • This ensures that derived classes can be used interchangeably with the base class, maintaining the integrity of the system.

高内聚，低耦合是我们设计的目标 P198-200

High cohesion and low coupling are the goals of our design

3.接口的作用

UML概念，通过接口实现可控连接（P203）、同时实现可替换性

回答接口的作用的问题中，应该注意从可控连接和可替换性两方面进行回答

典型例题

Controlled connection and Replaceability

1. Controlled connection between design classes: The ImageObserver interface allows the Motion component to control how it interacts with the Imaging component. By relying on the interface, Motion can invoke the imageUpdate() method without needing to know the specific implementation details of the Imaging component. This decouples the components and makes the system more flexible and easier to maintain.
2. Replaceability: Since Imaging implements the ImageObserver interface, it can be easily replaced with any other component that also implements this interface. This means if there is a need to update or change the image handling logic, a new class can be created that implements ImageObserver, and the Motion component can interact with the new class without any changes.

Scenario Description

• In this scenario, Motion relies on the ImageObserver interface to update images, while Imaging implements this interface to provide the actual image update functionality. This setup allows for flexible and maintainable code where the Motion component doesn’t need to know the specifics of how the image updates are handled, and the Imaging component can be swapped out easily if needed.

// ImageObserver 接口
public interface ImageObserver {
 boolean imageUpdate();
}

// Imaging 类实现了 ImageObserver 接口
public class Imaging implements ImageObserver {
 @Override
 public boolean imageUpdate() {
     // 图像更新的实现
     return true;
 }
}

// Motion 类使用 ImageObserver
public class Motion {
 private ImageObserver observer;

 public Motion(ImageObserver observer) {
     this.observer = observer;
 }

 public void updateImage() {
     observer.imageUpdate();
 }
}

// 主类展示功能
public class Main {
 public static void main(String[] args) {
     ImageObserver imaging = new Imaging();
     Motion motion = new Motion(imaging);
     motion.updateImage();
 }
}

七、软件测试（第十五章）

1.验证和确认(P285)

• 验证是保证正确实现特定功能（正确的构建产品）

• 确认是保证满足客户需求（构建正确的产品）

How does software verification differ from validation?

• Verification refers to the set of tasks that ensure that software correctly implements a specific function.
  • Verification: Are we building the product right?
• Validation refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements.
  • Validation: Are we building the right product?

2.测试角色

• 开发者测试（developers 写代码，以“交付”( delivery )为驱动力，是温和的(gently)）

• 独立测试组（independent test group (ITG) 从集成测试开始做 以“ 质量”( quality )为驱动力，尝试打破(break)）

• Software developers are always responsible for testing individual program components and ensuring that each performs its designed function or behavior.

• The role of an independent test group (ITG) is to remove the inherent problems associated with letting the builder test the thing that has been built.

  • Only after the architecture is complete does an ITG become involved.
  • But ITG is involved in the entire process from analysis, design to test planning, with independence is directly responsible for the SQA team.
  • ITG personnel are paid to find errors.

• Developers and ITG work closely throughout a project to ensure that thorough tests will be conducted.

• 软件开发人员始终负责测试各个程序组件，并确保每个组件执行其设计的功能或行为。

• 独立测试组（ITG）的作用是消除让构建者测试已构建事物所带来的固有问题。

  • 只有在架构完成后，ITG才会介入。
  • 但ITG参与整个过程，从分析、设计到测试计划，独立性直接负责SQA团队。
  • ITG人员的工作是查找错误。

• 开发人员和ITG在整个项目中密切合作，以确保进行彻底的测试。

3.宏观步骤

单元测试（unit testing）----->集成测试(integration testing)----->确认测试(validation testing)----->系统测试(system testing)

1. Unit testing begins at the center of the spiral and concentrates on each unit (for example, component, class, or content object) as they are implemented in source code.

2. Testing progresses to integration testing, where the focus is on design and the construction of the software architecture. Taking another turn outward on the spiral.

3. Validation testing is where requirements established as part of requirements modeling are validated against the software that has been constructed.

4. In system testing, the software and other system elements are tested as a whole.

翻译

1. 单元测试就是分模块进行测试，对应详细设计，保证模块内无问题（单元测试应关注对项目成功至关重要的模块或那些被怀疑容易出错的模块。）

2. 集成测试一般是两个两个一起集成，有两种方法自下而上或者自上而下，采用深度优先比宽度优先好，因为深度优先表示一个软件运行出来的分量，主要就是接口（即概要设计）
   depth-first ensures that a software component is fully operational before moving on to the next component

3. 确认测试就是看写出来的软件功能和需求的软件功能是否一致，软件规格说明，是软件需求团队验收

4. 系统测试看写出的软件在整个系统下的情况，由客户验收

4.脚手架

• 脚手架 scaffolding 驱动程序 driver 桩 stub

• 脚手架是为了单元测试产生的

• 驱动程序就是主程序，是为了测试自己写的模块，让模块运行起来

• 桩是指替换真正的代码，只提供我们的模块测试所需的数据即可，因为目前讨论的是构建级别的测试，每个程序员只完成自己的任务，但是可能会调用别人的代码，这时只需要那部分代码运行的结果所产生的数据，即用桩进行替代

A driver is only a “main program”

• that accepts test-case data, passes such data to the component (to be tested), and prints relevant results.

Stubs (dummy subprogram) serve to replace modules invoked by the component to be tested.

• A stub uses the module’s interface, may do minimal data manipulation, prints verification of entry, and returns control to the module undergoing testing.

5.单元测试检查的错误

即上图中的五个部分，一般是用白盒测试（能看见代码），也可能用到黑盒（看不见代码）

• interface 接口 local data structures 局部数据结构 boundary conditions 边界条件

• independent paths 独立路径（不可能穷举测试，因此找重要路径） error handling paths 错误处理路径

PPT中的对五个部分的介绍：

1. Design unit test cases before coding for a component to ensure that code that will pass the tests.

2. Test cases are designed to cover the following areas:

3. The module interface is tested to ensure that information properly flows into and out of the program unit.

4. Local data structures are examined to ensure that stored data stored maintains its integrity during execution.

5. Independent paths through control structures are exercised to ensure all statements are executed at least once.

6. Boundary conditions are tested to ensure module operates properly at boundaries established to limit or restrict processing.

7. All error-handling paths are tested

6.白盒测试(P296-297)

保证所有独立路径至少被测试一次（测试为真或者为假都算）

典型例题

• 第一个问题是将流程图转化为流图，只要将顺序执行的结点合并即可

• 第二个问题是求环路复杂度，一共有三种求解方法：
  ​ 1. 求封闭区域的个数，复杂度为封闭区域个数+1，如上图中R1,R2,R3都为封闭区域
  ​ 2. 流图中 $V(edges)-V(nodes)+2$
  ​ 3. 流程图中分支点的数量（即菱形数量）+1

• 第三个问题是求所有的独立路径，独立路径的数量就是环路复杂度，要保证每一条分支路径都被走一遍，且一定要从起点走到终点，如上图中是从1到11

忽略红线（和同学讨论时画的，懒的改了）

7.黑盒测试

传统结构化编程中的等价类划分法

If an input condition

• specifies a range: one valid & two invalid

按范围分类

• requires a specific value: one valid & two invalid

按特定值分类

• specifies a member of a set: one valid & one invalid

按一个集合分类

• is Boolean: one valid & one invalid

按布尔值分类

OO中等价类划分

最小测试序列：就是account这个类最短生命周期的序列

设计测试类可以用是否改变状态来分类

8.面向对象的测试P302

类是组织单元，操作是基本测试单元，但是孤立的测试操作没有意义，因为 在面向对象的环境中，独立测试单个操作可能无效，因为多态性使得不同子类具有不同的属性和操作逻辑，其上下文环境也不同于其他子类。因此，测试用例必须考虑每个子类在其特定环境中的具体行为和交互。

To illustrate, consider a class hierarchy in which an operation X is defined for the superclass and is inherited by a number of subclasses. Each subclass uses operation X, but it is applied within the context of the private attributes and operations that have been defined for the subclass. Because the context in which operation X is used varies in subtle ways, it is necessary to test operation X in the context of each of the subclasses. This means that testing operation X in a stand-alone fashion (the conventional unit-testing approach) is usually ineffective in the object-oriented context.

八、集成测试（第十六章）

1.增量集成方式

增量集成方式（就是两两集成）

incremental integration: a program is constructed and tested in small increments, making errors easier to isolate and correct. Far more cost-effective!

自顶向下（ Top-Down Integration ）、自底向上（Bottom-Up Integration），自顶向下的深度优先搜索的优点

How does depth-first differ from breadth-first when using a top-down integration strategy?

• depth-first: integrates all components on a major control path of the program structure.
• breadth-first: incorporates all components directly subordinate at each level, moving across the structure horizontally.
• If depth-first integration is selected, a complete function of the software may be implemented and demonstrated. Early demonstration of functional capability is a confidence builder for all stakeholders.

2.持续集成

敏捷开发，Devops测试与运维，XP（ Extreme Programming 极限编程）

冒烟测试，新模块进入后要对整个系统完整性进行测试，判断新构件有没有对软件增加副作用

回归测试，不断执行已经测试过的用例子集

3.确认测试与验收测试

• 确认测试和验收测试同等地位、验收测试分为 $\alpha$ 测试（受控），$\beta$ 测试（客户验收）用户会给出需求，需要通过用户需求提取验收标准，根据验收的标准确认软件是否实现

• 验收是客户做的，确认是程序员做的

What are the key differences between validation testing goals and acceptance testing goals?

验证测试目标和验收测试目标之间的主要区别是什么？

• In validation testing, the test team seeks to ensure that each software function or performance characteristic conforms to its specification.
• In acceptance testing, the test team needs to ensure that the software works correctly for the intended user in his or her normal work environment.

4.系统测试

恢复测试：强制软件发生故障，验证其恢复能力

安全测试：验证保护机制是否能保护系统不受非法入侵

压力测试：以非正常数量、频率或容量的方式，破坏系统

性能测试：与压力测试结合，测试集成环境的软件性能

部署测试：配置测试多平台 OS 环境下的软件安装运行

九、软件配置管理（第十七章）

1.SCI 软件配置项(P324-327)

What information will make up the software configuration?

• Software configuration are work products that created by engineers during the software process.

computer programs (source code and executables), documentation (technical and user), data (internal and external to programs)

• 软件配置是工程师在软件过程中创建的工作产品。

• 计算机程序（源代码和可执行文件）、文档（技术文档和用户文档）、数据（程序内部和外部的数据）

1. In software configuration management (SCM) process, each work product is called a software configuration item (SCI).

2. In the extreme, an SCI could be considered to be a single section of a large specification or one test case in a large suite of tests.

3. More realistically, an SCI is all or part of a work product (e.g., a document, an entire suite of test cases, a named program component, a multimedia content asset, or a software tool).

4. Moreover, there is often a hierarchical structure between SCIs.

翻译

1. 在软件配置管理（SCM）过程中，每个工作产品称为软件配置项（SCI）。

2. 在极端情况下，SCI可以被认为是一个大规格的一部分或大型测试套件中的一个测试用例。

3. 更现实地说，SCI是工作产品的一部分或全部（例如，一个文档，一整套测试用例，一个命名的程 序组件，一个多媒体内容资产，或一个软件工具）。

此外，SCI之间通常存在分层结构。

2.基线(P327)

baseline 基线，当一个产品成为基线前可以随意变更（非正式变更），成为基线后一定是正式变更，可以理解为目前这个产品已经合理且存入库

The IEEE defines a baseline as:

• A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

A baseline is a milestone in the development of software

• that is marked by the delivery of one or more software configuration items and
• the approval of these SCI that is obtained through a formal technical review

IEEE 将基线定义为：

• 已经正式审查并达成一致的规范或产品，此后作为进一步开发的基础，并且只能通过正式的变更控制程序进行更改。

基线是软件开发中的一个里程碑

• 标志着一个或多个软件配置项的交付
• 通过正式的技术审查获得这些 SCI 的批准

3.变更控制过程

What are the steps in the change control process?

1. evaluate a change request, and submit a change report to CCA (change control authority). The CCA makes the final determination as to the status and priority of the change.
2. An ECO (engineering change order) is generated for each approved change.
3. Change SCIs are checked out from the project database subject by its access control parameters.
4. The modified SCIs is subjected to SQA procedures and checked into the project database.
5. Version control procedures are followed to produce the next version of the software. Adopting Synchronization control ensures that parallel changes made by different people do not overwrite with each other.

变更控制过程中的步骤是什么？

1. 评估变更请求，并将变更报告提交给CCA（变更控制机构）。CCA对变更的状态和优先级做出最终确定。
2. 对于每个批准的变更，生成一个ECO（工程变更单）。
3. 根据访问控制参数，从项目数据库中签出变更的SCI。
4. 修改后的SCI遵循SQA程序并签入项目数据库。
5. 遵循版本控制程序以生成软件的下一个版本。采用同步控制确保不同人员进行的并行变更不会互相覆盖。

十、过程模型(第二章)

传统过程模型、敏捷过程模型、基于项目的过程模型

1.传统过程模型

追求结构和顺序（structure and order）,预定义的可预测的，每个过程都可以描述为过程流

define a predefined set of process elements and a predictable process work flow.

• prescribe a set of process elements — framework activities, SE actions, tasks, work products, quality assurance, and change control mechanisms for each project.

• each process model also prescribes a process work flow — that is, the manner in which the process elements are interrelated to one another.

• strive for structure and order in software development.

• activities and tasks occur sequentially with defined guidelines for progress.

1.瀑布模型（ Waterfall Process Model ）文档驱动

经典的生命周期模型（文档驱动、阶段性、连续型），每个阶段都会产生文档作为里程碑，然后开始下一步的设计

Classic lifecycle model Document-driven: phase & continuous

Pros

• It is easy to understand and plan.
• It works for well-understood small projects.
• Analysis and testing are straightforward.

Cons

• It does not accommodate change well.
• Testing occurs late in the process.
• Customer approval is at the end.

经典生命周期模型 文档驱动：阶段性和连续性

优点

• 容易理解和计划。
• 适用于对需求明确的小型项目。
• 分析和测试直截了当。

缺点

• 不善于应对变更。
• 测试在过程中较晚进行。
• 客户审批在最后阶段进行。

2.原型模型（ Prototyping Process Model ）原型驱动

先把用户需求明确下来，再去写代码，是真原型，只有界面，后台没有什么业务逻辑，是原型驱动

原型 是一种快速构建的软件模型，用于展示和验证软件的设计和功能 ，即把客户需求通过界面展示，而后面的实现没有展示

3.螺旋模型（Spiral Process Model）风险驱动

每一圈都是软件版本（都是一个成果，每一圈都是瀑布），前一圈是后一圈的原型，是瀑布+原型结合，适合大型风险较高的项目，是风险驱动，每一圈都重新评估成本

4.统一过程模型（Unified Process Model）用例驱动

产生于面向对象，用例驱动，九个工作流（六个框架，三个普适性）

2.敏捷过程模型

1.敏捷的宣言

Agile Manifesto

A process model is working, it is necessary to adopt a realistic mechanism to ensure discipline while treating software engineers with tolerance.

What are the tradeoffs proposed by the “Agile Manifesto”?

1. individuals and interactions over processes and tools,
2. working software over comprehensive documentation,
3. customer collaboration over contract negotiation, and
4. responding to change over following a plan.

Agile is not antithetical to solid SE practice, and can be applied as an overriding philosophy for all software work.

敏捷宣言

一个过程模型在起作用时，有必要采用一种现实的机制来确保纪律，同时以一定程度宽容对待软件工程师（产生可控的错误）。

“敏捷宣言”提出的权衡是什么？

1. 个体和互动胜过过程和工具，
2. 可工作的软件胜过详尽的文档，
3. 客户协作胜过合同谈判，
4. 响应变化胜过遵循计划。

敏捷并不与稳固的软件工程实践对立，并且可以作为所有软件工作的指导理念。

2.敏捷哲学

与上面的宣言一一对应

agile philosophy

What are the key issues stressed by an agile philosophy?

1. Emphasis on rapid delivery of software that satisfies the customer
2. Recognition that change represents opportunity
3. Communication and collaboration between team members and customers
4. The importance of self-organizing teams

敏捷哲学

敏捷哲学强调的关键问题是什么？

1. 强调快速交付满足客户的软件
2. 认识到变化代表着机会
3. 团队成员与客户之间的沟通和协作
4. 自组织团队的重要性

3.Scrum Framework

一个冲刺（Sprint）就是一个研发周期，一个冲刺就是三到四周

待冲项（ Sprint Backlog ）：这个冲刺里面要干的事情，包括用户故事（User Stories）、 任务（Tasks） 、 缺陷修复（Bug Fixes） 、 技术改进（Technical Improvements）、 其他相关工作（Other Relevant Work）

各种会议如下

图中优先级高的颜色越深，燃尽图（哪些任务结束，哪些没有结束）

• Backlog Refinement Meeting — Developers work with stakeholders to create product backlog.

• Sprint Planning Meeting — Backlog partitioned into “sprints” derived from backlog and next sprint defined.

• Daily Scrum Meeting — Team members synchronize their activities and plan work day (15 minutes max).

• Sprint Review — Prototype “demos” are delivered to the stakeholders for approval or rejection.

• Sprint Retrospective — After sprint is complete, team considers what went well and what needs improvement.

• 待办事项梳理会议 — 开发人员与利益相关者合作创建产品待办事项。

• 冲刺规划会议 — 从待办事项中提取的内容划分为**“冲刺”**，并定义下一个冲刺。

• 每日构件会议 — 团队成员同步他们的活动并计划工作日（最多15分钟）。

• 冲刺评审 — 将原型**“演示”交付给利益相关者以供批准或拒绝**。

• 冲刺回顾 — 冲刺完成后，团队考虑哪些做得好以及哪些需要改进。

4.极限编程（Extreme Programming (XP)）

1. 策划：和用户沟通需求，用户讲故事，故事要有价值，故事就是功能，讲故事一定会指定相关的标准

2. 设计：倡导简单，$KIS$ 即 $keepitssimple$ ，用户需求分为正常需求（功能）、隐含需求（NFR）、令人兴奋的需求（需要把控好），用CRC卡（类的职责（包括自己可以完成，还有必须和协作者合作才能完成）与协作），$spike$ 解决方案就是需求不清的时候做原型

3. 编码：重构（保证接口不变的情况下改变接口的算法）与结对编程（ Pair Programming 两个人负责一个功能模块，一个人负责设计，一个人负责质量）

4. 后续单元测试与集成测试

3.基于项目的过程模型（第四章）

首个原型创建的重要性

Why should you create prototypes with deployment in mind?

• first prototype can to prove initial architectural is a feasible to delivering the required functionality while satisfying the performance constraints.
• prototype with deployment in mind is very important because can avoid taking shortcuts that lead to creating software that will be hard to maintain.
• As iterative prototype development occurs, should carefully consider the software architectural choices you make.
• It is very expensive to change the architecture of a software application once it has been released to end users around the globe.

为什么要在考虑部署的情况下创建原型？

• 第一个原型可以证明初始架构在满足性能约束的同时能够提供所需的功能。
• 考虑部署的原型非常重要，因为它可以避免采取捷径，从而创建难以维护的软件。
• 随着迭代原型开发的进行，应仔细考虑所做的软件架构选择。
• 一旦软件应用程序发布到全球终端用户，改变其架构将非常昂贵。

十一、项目管理与进度计划

1.4P

What are four P’s of effective project management?

• People — the most important element of a successful project.
• Product — the software to be built.
• Process — the set of framework activities and software engineering tasks to get the job done.
• Project — all work required to make the product a reality.

有效项目管理的四个P是什么？

• 人员（People） — 成功项目的最重要元素。
• 产品（Product） — 要构建的软件。
• 过程（Process） — 完成工作所需的一套框架活动和软件工程任务。
• 项目（Project） — 实现产品所需的所有工作。

2.软件工程师的素质（P75）

Traits of Successful Software Engineers

(要稍微扩展)

What are the characteristics of software engineers should possess?

• Sense of individual responsibility
• Has an acute awareness of the needs of other team members
• Brutal honesty
• Resilience under pressure
• Heightened sense of awareness
• Attention to detail
• Takes a pragmatic approach to software engineering

成功软件工程师的特质

软件工程师应该具备哪些特征？

• 个人责任感
• 对其他团队成员需求的敏锐意识
• 直言不讳
• 在压力下的韧性
• 高度的警觉性
• 注重细节
• 采取务实的软件工程方法

3.高效团队的特征（P77第二段到第四段）

Effective Team Attributes

此题也要扩展

What are the key attributes of an effective software teams?

• Sense of purpose.
• Sense of involvement.
• Sense of trust.
• Sense of improvement.
• Diversity of team member skill sets.

Translated Text:

有效团队的属性

有效的软件团队的关键属性是什么？

• 目标感。
• 参与感。
• 信任感。
• 改进意识。
• 团队成员技能的多样性。

4.影响团队的毒性因素和处理措施

What are the environment characteristics that can be considered toxic to software teams? How to avoid it?

Toxic factors:

1. Frenzied work atmosphere where team members waste energy and lose focus.
2. High frustration that causes friction among team members.
3. Fragmented or poorly coordinated process model that becomes a roadblock to accomplishment.
4. Unclear definition of team roles resulting in a lack of accountability and resultant finger-pointing.
5. Continuous and repeated exposure to failure that leads to a loss of confidence and poor morale.
6. Differing and incompatible team member human traits.

Avoiding Solution:

1. Be certain that the team has access to all information required to do the job.
2. Major goals and objectives should not be modified unless absolutely necessary.
3. Team should be given as much decision-making responsibility as possible.
4. Allow the team to select the process model.
5. Team should establish its own mechanisms for accountability.
6. Establish team-based techniques for feedback and problem solving.

5.项目团队结构P78

Team Structure of Project

What factors should be considered when selecting a team structure for project planning?

1. Difficulty of the problem to be solved.
2. Resultant program size in lines of code or function points.
3. Time that the team will stay together (team lifetime).
4. Degree to which the problem can be modularized.
5. Required quality and reliability of the system to be built.
6. Rigidity of the delivery date.
7. Degree of communication required for the project.

Understanding:

• Separate Human Resource Management and Project Development.
• Different companies have different organizational structures.
• The company’s organizational structure cannot be easily changed.
• Organizational management is not the duty of the project manager.
• Project manager should organize the team members of the project based on the nature and scale of the project.
• Excellent project team: depends on management style, number of personnel, skill level, and difficulty level of the problem.

6.问题分解和过程分解