Chapter 1 - Software Process

Software Development life cycle (SDLC)

一个描述软件开发项目每个阶段所进行的活动的框架。

A framework that describes the activities performed at each stage of a software development project.

Waterfall Model (software life cycle, classical life cycle and linear sequential model)

优点

0. 易于理解和使用
1. 给没有经验的职员staff提供框架structure
2. 阶段性成果被充分理解 milestones are well understood
3. 建立稳固的需求 set requirements stability
4. 易于管理和控制(Good for management control)

缺点

0. 不能在上一个阶段结束之前开启下一个阶段phase
1. 软件在最后一个阶段才能被投入使用
2. 开发不够灵活 因为分给了不同的独立的阶段
3. 需求必须被充分理解、

何时使用

0. 需求很清晰
1. 产品的定义十分坚固
2. 技术被完全理解
3. 开发现有产品的新版本 New version of existing product
4. 把现有的产品移植到新平台

Prototype Model

原型是一个系统的初始版本，用于展示概念和尝试设计方案。 一般来说，在这种模式下，开发人员听取客户的意见，设计一个原型，然后对原型进行测试。 这个过程不断重复，直到系统的所有要求都被确定，并且可以为系统设计一个复杂的系统。

A prototype is an initial version of a system used to demonstrate concepts and try out design options. Generally in this model developers listen to customer, design a prototype and then the prototype is tested. The procedure is repeated until all the requirements of the system are identified and a complex system can be designed for the system

用途

原型可以用在以下方面 在需求工程过程中，帮助进行需求征询和验证。 在设计过程中，探索选择和开发。 在测试过程中，运行背对背的测试。 需求不稳定或需要澄清，作为瀑布模型的需求澄清阶段。 开发用户接口。

A prototype can be used in: ▪ The requirements engineering process to help with requirements elicitation and validation. ▪ In design processes to explore options and develop . ▪ In the testing process to run back-to-back tests. ▪ Requirements are unstable or have to be clarified as the requirements clarification stage of a waterfall model. ▪ Develop user interfaces.

RAD model

何时使用

▪ Reasonably well-known requirements. ▪ User involved throughout the life cycle ▪ Project can be time-boxed ▪ Functionality delivered in increments ▪ High performance not required ▪ Low technical risks ▪ System can be modularized

合理的知名要求。 用户参与整个生命周期 项目可以分时段进行 功能以递增方式交付 不需要很高的性能 技术风险低 系统可以模块化

优势

缩短周期时间和提高生产力，用更少的人意味着更低的成本 时间箱方法减少了成本和进度风险 客户参与整个周期，将无法实现客户满意度和业务需求的风险降到最低。 重点从文件转移到代码。 使用建模概念来捕获有关业务、数据和流程的信息。

Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code. Uses modeling concepts to capture information about business, data, and processes.

缺点

RAD需要足够的人力资源，以便在大型和可扩展的项目中建立适当数量的RAD团队。 RAD的开发者和消费者应该致力于快速的活动。 不合适的情况。 一个非模块化的系统。 技术风险很高时。

▪ RAD requires sufficient human-resources to create the right number of RAD teams in a large and scalable projects. ▪ RAD developers and costumers should be committed to the rapid-fire activities. ▪ Unsuitable cases: ▪ A non-modularized system. ▪ When technical risk is high.

Evolutionary model

优点

客户参与到过程中。 更有可能满足用户的要求。 早期和频繁的测试。 更有可能发现问题。 风险较低。 适用于中小型系统

Customer involvement in the process More likely to meet the user requirement. Early and frequent testing More likely to identify problems. Lower risk. Suitable for small to medium sized system

缺点

The process is intangible

The process is unpredictable

System are poorly structurued

system may not even converge to a final version

Incremental model

何时使用

Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology

风险、资金、时间表、计划的复杂性，或对早期实现效益的需要。 大多数要求是预先知道的，但预计会随着时间的推移而变化。 需要尽早将基本功能推向市场 在开发时间较长的项目上 在有新技术的项目中

优点

首先开发高风险或主要功能 每个版本都提供一个可操作的产品 客户可以对每个版本作出反应 采用 "分而治之 "的任务分解方法 降低初始交付成本 初始产品交付更快 客户尽早获得重要的功能 减少需求变化的风险

Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

缺点

需要良好的规划和设计。 需要早期定义一个完整的、功能齐全的系统，以允许 来定义增量。 需要有明确的模块接口（有些模块会在很长时间内被开发出来 在其他模块之前）。 完整系统的总成本并不低

Requires good planning and design. Requires early definition of a complete and fully functional system to allow for the definition of increments. Well-defined module interfaces are required (some will be developed long before others). Total cost of the complete system is not lower

Spiral model

何时使用螺旋模型 当创建一个原型是合适的时候 当成本和风险评估很重要时 对于中到高风险的项目 由于潜在的变化，长期的项目承诺并不明智 经济优先权的变化而不明智 用户不确定他们的需求 要求很复杂 新产品系列 预计会有重大的变化（研究和探索）

When to use Spiral Model When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)

螺旋模型的优势 对无法克服的风险提供早期指示，而不需要太多的成本 由于有快速的原型设计工具，用户可以尽早看到系统 关键的高风险功能首先被开发出来 设计不一定要完美 用户可以与所有的生命周期步骤紧密联系在一起 用户的早期和频繁的反馈 经常评估累积成本

Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently

螺旋模型的弱点 对小型或低风险项目来说，评估风险所花的时间太长了 规划、重新设定目标、进行风险分析和原型设计所花费的时间可能过长。 的时间可能过长 该模型很复杂 需要风险评估的专业知识 螺旋式发展可能无限期地持续下去 开发人员必须在非开发阶段重新分配工作 可能很难定义客观的、可验证的里程碑，以表明 准备好进行下一次迭代

Cumulative costs assessed frequently Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during non-development phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

Software engineering ethics

Confidentiality :You should normally respect the of your employers Competence : You should not knowingly accept work that is outside your competence. Intellectual property rights :You should be aware of local laws governing the use of intellectual property such as patents and copyright Computer misuse :You should not use your technical skills to misuse other people’s computers

保密性：你通常应该尊重你的雇主的隐私。 能力：你不应该故意接受你能力之外的工作。 知识产权 :你应该了解当地法律对知识产权的使用，如专利和版权。 滥用计算机 :你不应该使用你的技术技能来滥用其他人的计算机。

Chapter 2 - Agile software development

Program specification, design and implementation are inter-leaved The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation Frequent delivery of new versions for evaluation Extensive tool support (e.g. automated testing tools) used to support development. Minimal documentation – focus on working code

程序规范、设计和实施是相互交错的 系统是作为一系列的版本或增量来开发的，利益相关者参与版本规范和评估 频繁地交付新版本进行评估 使用广泛的工具支持（如自动测试工具）来支持开发。 最低限度的文档--重点是工作代码

用途

减少开支overheads in software process

the aim of agile requirements without too much rework

Problems with agile methods

It can be difficult to keep the interest of customers / users who are involved in the process. Team members may be not right to the strong involvement that describe agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to refined iterative development. Because of their focus on small, tightly-integrated teams, there are problems in scaling agile methods to large systems. Less emphasis on documentation - harder to maintain when you get a new team for maintenance

要保持参与过程的客户/用户的兴趣是很困难的。 团队成员可能不适合描述敏捷方法的强烈参与。 在有多个利益相关者的情况下，对变化进行优先排序可能很困难。 保持简单性需要额外的工作。 合同可能是一个问题，就像其他精炼迭代开发的方法一样。 因为他们专注于小型的、紧密结合的团队，所以在将敏捷方法扩展到大型系统时存在问题。 方法扩展到大型系统时存在问题。 不太重视文档--当你找一个新的团队进行维护时，更难维护。

XP- extreme programming

Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. ▪ New versions may be built several times per day;

▪ Increments are delivered to customers every 2 weeks;

▪ All tests must be run for every build and the build is only accepted if tests run successfully.

Scrum

Scrum是一种敏捷方法，侧重于管理迭代开发，而不是特定的 敏捷实践 项目经理的工作： - 在预算范围内按时交付所需系统 Scrum方法--管理迭代 Scrum有三个阶段 大纲规划阶段--总图和架构 冲刺周期释放系统的增量。项目结束阶段--最终交付、记录和审查经验教训

Chapter 3 - Requirement Engineering

What's a requirement

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function. May be the basis for a bid for a contract – therefore must be open to interpretation. May be the basis for the contract itself - therefore must be defined in detail.

它的范围可以从服务或系统约束的高级抽象声明到详细的数学功能规范。 这是不可避免的，因为需求可能具有双重功能。 可能是合同投标的基础--因此必须是开放性的解释。 可能是合同本身的基础--因此必须被详细定义。

Type of requirement

Business requirements

User requirements

Software requirements

Type of readers

Functional and nonfunctional requirements

Functional requirement:

These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations

这些是关于系统应该提供的服务、系统应该如何对特定的输入做出反应、以及系统在特定情况下应该如何表现的声明。

Non-functional requirements:

These are constraints on the services or functions offered by the system.

Non-functional requirements may affect the overall architecture of a system rather than the individual component

这些是对系统所提供的服务或功能的限制。

非功能需求可能会影响到系统的整体结构，而不是单个组件。

0. Performance requirements, such as response time, throughput, and scalability

性能要求，如响应时间、吞吐量和可扩展性

0. Security requirements, such as authentication, access control, and data protection

安全要求，如认证、访问控制和数据保护

0. Usability requirements, such as user-friendliness, learnability, and accessibility

可用性要求，如用户友好性、可学习性和可访问性

0. Compatibility requirements, such as compatibility with other systems, hardware, and software

兼容性要求，如与其他系统、硬件和软件的兼容性

0. Maintainability requirements, such as reliability, testability, and maintainability

1. Availability requirements, such as uptime, fail over, and disaster recovery

2. Adaptability requirements, such as configurability, extensibility, and portability

3. Compliance requirements, such as adherence to industry standards, regulations, and policies

4. Interoperability requirements, such as the ability to exchange data with other systems

5. Quality of service requirements, such as reliability, security, and performance guarantees.

   可维护性要求，如可靠性、可测试性和可维护性

   可用性要求，如正常运行时间、故障转移和灾难恢复

   适应性要求，如可配置性、可扩展性和可移植性

   合规性要求，如对行业标准、法规和政策的遵守。

   互操作性要求，如与其他系统交换数据的能力

   服务质量要求，如可靠性、安全性和性能保证。

Domain requirements

The system’s operational domain imposes requirements on the system. Domain requirements can be new functional requirements, constraints on existing requirements, or define specific computations. If domain requirements are not satisfied, the system may be unworkable.

系统的操作域对系统提出了要求。 领域要求可以是新的功能要求，也可以是对现有要求的约束，或者是对特定计算的定义。 要求的约束，或者定义特定的计算。 如果领域要求不被满足，系统可能就无法运行。

Domain requirements 的问题

• 可理解性(Understandability) 需求是用应用领域的语言来表达的，这往往不被开发系统的软件工程师所理解。 开发系统的软件工程师无法理解。
• 隐含性（Implicitness ) 领域专家对该领域了解得非常透彻，以至于他们没有想到要把领域需求明确化。 如果软件开发人员以错误的方式实现需求，就会导致问题。

• Understandability : Requirements are expressed in the language of the application domain This is often not understood by software engineers developing the system. • Implicitness Domain specialists understand the area so well that they do not think of making the domain requirements explicit which leads to problems later if software developer implements the requirements in the wrong way

Requirement Engineering

• Requirement elicitation
• Requirement analysis
• Requirement validation
• Requirement management

Software requirements specification(document)

The level of detail

取决于系统的类型和使用的开发模型

Chapter 4 - Architectural Design

Architecture Design concept- 架构设计基本概念

Architectural design is concerned with understanding how a system should be organized and designing the overall structure of that system.

架构设计涉及到理解一个系统应该如何组织，并设计该系统的整体结构。

Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them.

架构设计是设计和需求工程之间的关键环节，因为它确定了系统中的主要结构组件和它们之间的关系。

The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.

架构设计过程的输出是一个架构模型，它描述了系统是如何被组织成一组交流的组件的。

Software architecture is important because it affects the performance, robustness, and maintainability of a system.

软件架构很重要，因为它影响到系统的性能、稳健性和可维护性。

是什么？ - 它是如何组织系统设计系统的整体结构，设计和需求工程之间的关键环节，输出的是一个架构模型，它的重要性在于影响系统的性能，可维护性，健壮性

Architecture View - 架构视图

A logical view - 逻辑视图

A process view 过程视图

A development view 开发视图

A physical view - 物理视图

Architecture Pattern - 架构模式

0. MVC 模型

何时使用MVC模型

Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown.

有种方式来查看和互动数据时使用。当未来对数据的交互和呈现的要求不清楚时，也会使用。

优点

Allow data to change independently of its representation and vice versa 。

允许用户独立于表现形式更改 反之亦然

支持以不同的形式呈现相同的数据

缺点

当数据模型和交互比较简单的时候，可能会产生额外的代码和代码复杂度。

2. Layered architecture 分层体系结构

When to use

将系统组织成若干层，每个层都有相关的功能。

一个层为它的上层提供服务，最底层的层代表了整个系统都会使用的核心功能。

在现有基础上建立新的设施时使用

当开发工作分散在几个团队中，每个团队负责一层功能。

当有多层次的要求时。

优点

允许替换整个层 只要系统保持不变

Allows replacement of entire layers so long as the interface is maintained.

可以在每一层提供冗余设施（如认证），以增加系统的可依赖性

Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system

缺点

性能问题，处理一个请求的时候需要经过多个层的处理

在实践中，在各层之间提供一个完全干净的分离是很困难的，有可能高层不得不与低层直接互动，而不是哦通过紧随其后的层

In practice, providing a clean separation between layers is often difficult and a highlevel layer may have to interact directly with lower-level layers rather than through the layer immediately below it.

3. Repository Architecture

系统中的所有数据储存在一个大的仓库中可以被各个组件或者子系统获取

组件之间不直接交互，而是通过这个大仓库交互 repository

优点

各个组件之间相互独立，不需要知道相互之间的存在。

一个组件的造成的改变可以传播给所有组件

Changes made by one component can be propagated to all component

数据具有良好的一致性

缺点

一个组件的失败/错误会影响整个系统

也许在通过仓库组织所有的交互交流的时候会比较低效

在不同仓库之间分配仓库也许有点困难

Application types

Data processing application Transaction processing application Event processing system Language processing system

Chapter 5 - Design and implementation

复习Use case 和 sequence

Chapter 6 - Software Testing

Testing is to show that a program does what it is intended to do, and to discover program defects before it is put into use.

When you test software, you execute a program using artificial data.

测试是为了表明一个程序做了它想做的事情，并在投入使用前发现程序缺陷。

当你测试软件时，你使用人工数据执行程序。

Validation and verification

Validation: to ensure that the software meets the customer's expectation.

"Are we building the right product ?"

The software should do what the user really requires. 需要做用户需要的事情

Verification: to check that the software meets its stated functional and non-functional requirements

"Are we building the product right"

The software should conform to its specification. 遵守规范

置信度 - Required confidence level of software testing

置信度取决于三个因素

Software purpose

用于控制安全的系统置信度(confidence level)远高于为了展示新产品想法而开发的原型。

User expectations

当用户对于一个系统有不好的体验的时候，他们不会对系统的失败感到惊讶。

Marketing environment

当软件产品的价格很低的时候，用户也许会乐意容忍它的低可信度 low reliability

Software inspection 软件检查

除了软件测试(software testing), verification and validation也许还涉及software inspection and reviews.

Inspection and reviews 检查系统需求，设计模型，程序源代码甚至建议的系统测试。

Inspection 不能检查 non-functional such as usability, performance.

Inpesction 优点

由于检查是一个静态过程，因此不必关心错误之间的相互作用。

无需额外费用即可检查不完整的系统版本。如果程序不完整，则需要开发专门的测试工具来测试可用的不见

检查还可以考虑程序更广泛的质量属性，例如符合标准，可移植性和可维护性。

测试的阶段

0. Development testing
1. Release testing
2. User testing

Development testing

0. Unit testing

应尽可能自动执行单元测试， 利用例如JUnit等单元测试框架去编写和运行测试。

2. Component testing
3. System testing

Release testing

0. Scenario testing

User Testing

0. Alpha testing

Alpha测试 软件用户和开发团队合作，在开发人员的现场测试软件

2. Beta testing

Beta测试 向用户提供软件版本，以允许他们进行试验并向开发人员提出他们发现的问题。

3. Acceptance testing

客户测试系统以决定系统是否已经准备好被系统开发人员接受并部署在客户环境。

Chapter 7 - Software Evolution

Software evolution

Change analysis

release planning

system implementation

releasing a system to customer

• 访问这些变化的成本和影响，以了解变化对系统的影响有多大，以及实施变化可能需要多少成本。
• 如果提议的改变被接受，则计划对软件系统进行新的发布。
• 在发布计划中，所有提议的变化（故障修复、适应性和新功能）都被考虑在内。

Necessity of Software evolution

需求随时间变化：组织的需求和工作方式可能会随着时间发生重大变化，因此软件需要改变以提高性能。

环境变化：随着工作环境的变化，组织需要引入具有更新特性的功能的软件以适应环境。

Error and bugs: 随着软件的使用时间增加，软件的精确性会降低，无法承受更加复杂的工作，因此有必要避免使用过时(obsolete)的软件。这些软件 need to undergo evolution to become more robust to take on more complex work.

安全风险：使用过时的软件可能会导致您处于各种基于软件的网络攻击的边缘。Expose暴露你的confidential data机密数据

For having new functionality and features：

为了提高性能和快速数据处理和其他功能，需要在整个生命周期种evolute软件，sothat stakeholders and clients of the product can work efficently.

Software reuse

• system reuse
• application reuse
• component reuse
• object and function reuse

好处

• Quick development 快速开发
• Effective use of specialists 技术专家们可以开发 reusable software to encapsulate their knowledge, instead of doing same work over and over agian.
• 低开发成本
• standard compliance

问题

• Creating, maintaining and using a component library
• Finding, understanding, and adapting reusable components
• Increased maintenance costs
• Lack of tool support 一些工具不支持development with reuse
• Not-invented-here syndrome

Chapter 8 - Component-based Software Engineering

CBSE is an approach to software development On reuse of software components

它时在面向对象的开发未能有效支持重用出现(emerge)的

单一的对象类过于详细和具体

组件比对象类更加抽象，可以被认为时独立的服务提供者，可以作为独立的实体存在

CBSE essentials

• Independent components specified by their interfaces
• Component standards to facilitate component integration
• Middleware that provides support for component inter-operability
• A development process that is geared to reuse

Element of a component model

• Interface
• Usage information
• Deployment and use

Chapter 9 - Service-oriented Architecture

SOA

开发分布式系统的一种手段，组件是独立的服务

可以在不同的计算机上执行

已经开发了标准协议来支持服务通信和信息交换

benefit

Services can be provieded locally orr outsource to external providers

服务可以在本地提供或者外包给外部供应商

服务是独立于语言的

可以保留对遗留系统的投资

通过简化的信息交换，促进了组织之间的信息交流