CPT203软件工程个人复习笔记part1

前情提要：重点知识由红色和⭐标出，在目录中也能看到，实际重要！中文基本为谷歌翻译，专有名词可能有错。中英夹杂的原因是曾在小测中把压力测试（stress test）记成了pressure test😭tutorial里的东西没放进来只放了Lecture内容不过最好看看tutorial能加强理解。

Lecture1：Introduction

计算机软件和软件工程

Computer software is the product that software professionals build and then support over the long term. It encompasses computer programs and associated documentation that execute within a computer of any size and architecture . Software products may be developed for a particular customer or may be developed for a general market.

计算机软件是软件专业人员构建并长期支持的产品。 它包含在任何规模和体系结构的计算机中执行的计算机程序和相关文档。 软件产品可以为特定客户开发，也可以为一般市场开发

Software engineering is an engineering discipline that is concerned with all aspects of software production.

软件工程是一门涉及软件生产各个方面的工程学科。

软件错误的原因 consequence of software failure

Increasing demands 不断增长的需求
Low expectations 期望值低

专业软件开发的区别 Professional software development

developed for specific business purposes, for inclusion in other devices, or as software products
intended for use by someone apart from its developer
is usually developed by teams rather than individuals
It is maintained and changed throughout its life.

为特定业务目的而开发，用于包含在其他设备中，或作为软件产品
供除开发者之外的其他人使用
通常由团队而不是个人开发
在其整个生命周期内对其进行维护和更改。

专业软件通常有以下属性：

• Strict user requirements 严格的用户要求
• Required accuracy and data integrity 需求准确性和数据完整性
• Higher security standard 高安全标准
• Stable performance for heavy load 在高负荷下的稳定表现
• Required technical support 长期需求技术支持

⭐四项软件重要属性

Maintainability 可维护性
dependability and security 可靠性和安全性
efficiency 效率
acceptability 可接受性

其他的重要属性在《tutorial》里亦有记载：

Correctness, reusability, portability, usability, interoperability

南无三，实际重要！

⭐两种软件产品

Generic software products 通用软件产品

Customized software products 定制软件产品

两者的区别（1是generic 2是customize）：

specification 1.owned by the product developer. 2.owned by the customer.

通用软件产品类似微信可以随时增减功能，用户只能被动接受去适应。定制软件产品由用户提出如何更改，开发者不能擅自更改。

⭐软件恶化Software deterioration

Software is a logical rather than a physical system element. the failure rate curve for software should take the form of the “idealized curve” 

软件是逻辑系统元素而不是物理系统元素（不会磨损“wear out”导致故障）。所以故障率曲线可以是理想曲线

理想曲线（自动水印怎么去？）：

问题在于软件是不断更新的，更新的同时故障率又会到高点

实际曲线：

两种防止软件恶化的方法

1.reduce  software changes 减少软件更改次数

Work closely with the stakeholder to ensure requirements are correctly defined 确定需求被正确定义
Improve requirement study approach to achieve better requirements study 改进需求研究方法，实现更好的需求研究

2.reduce side effects after changes 减少更改后的副作用The software should be modular so that changes will not have a lot of side effects to other part of the software 模块化以减少对软件其他部分的副作用
The software must be maintainable 软件可维护
Comprehensive testing should put in place to reduce errors. 应进行全面的测试以减少错误

软件工程

为什么重要？

More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly.

个人和社会越来越依赖先进的软件系统。 我们需要能够经济、快速地生产可靠且值得信赖的系统。

It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of systems, the majority of costs are the costs of changing the software after it has gone into use

从长远来看，对软件系统使用软件工程方法和技术通常比仅仅像个人编程项目一样编写程序更便宜。 对于大多数类型的系统，大部分成本是软件投入使用后更改软件的成本

总结：需求大→需要经济快速生产→软件工程降低成本

⭐软件工程方法 software engineering approach

The systematic approach that is used in software engineering is sometimes called a software process.

软件工程中使用的系统方法有时称为软件过程。

四项软件过程基本活动：
There are four fundamental activities that are common to all software processes: -
• Software specification 软件规格
• Software development 软件开发
• Software validation 软件验证
• Software evolution 软件演变

⭐影响软件的一般性问题

• Heterogeneity 异质性
• Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices.

• Business and social change 商业和社会变革
• Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software.

• Security and trust 安全和信任
• As software is intertwined with all aspects of our lives, it is essential that we can trust that software. 

软件工程多样性 SOFTWARE ENGINEERING DIVERSITY

Different types of systems need different development processes.

不同系统流程不同

两个主要方法：• Sequential • Iterative• 顺序 • 迭代

八种应用类型：

Stand-alone applications 独立应用，不用联网

Interactive transaction-based applications 交互应用，远程执行

Embedded control systems 嵌入式系统，控制硬件

Batch processing systems 批处理系统，处理大量数据

Entertainment systems 娱乐系统，用于娱乐

Systems for modeling and simulation 建模仿真系统，用于模拟物理现象（科学方面）

Data collection systems 数据收集系统，和传感器相连收集数据

Systems of systems 系统的系统（？）多个系统组成的系统

软件工程基础

• Systems should be developed using a managed and understood development process. Of course, different processes are used for different types of software. 
• Dependability and performance are important for all types of system. 
• Understanding and managing the software specification and requirements (what the software should do) are important. 
• Where appropriate, you should reuse software that has already been developed rather than write new software.

• 应使用受管理且易于理解的开发流程来开发系统。 当然，不同类型的软件使用不同的流程。
• 可靠性和性能对于所有类型的系统都很重要。
• 理解和管理软件规范和需求（软件应该做什么）很重要。
• 在适当的情况下，您应该重用已经开发的软件而不是编写新软件。

⭐Web-based software engineering

主要方法：Software reuse is the dominant approach for constructing web-based systems.

两个特点：Web-based systems should be developed and delivered incrementally.网页系统需要逐步开发交付

User interfaces are constrained by the capabilities of web browsers.用户界面受浏览器限制

⭐软件工程道德观 SE Ethic

software engineering is carried out within a social and legal framework that limits the freedom of people working in that area.软件工程是在限制该领域工作人员自由的社会和法律框架内进行的。

• You must also behave in an ethical and morally responsible way if you are to be respected as a professional engineer. 如果您想作为专业工程师受到尊重，您还必须以合乎道德和道德负责的方式行事。
• You should not use your skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession.您不应利用自己的技能和能力进行不诚实的行为或损害软件工程行业声誉的行为。

需要道德约束的例子：

• Confidentiality 
• Competence
• Intellectual property rights
• Computer misuse

⭐软件开发风险

• Does not work as expected未按预期工作
• Over budget超过预算
• Late delivery逾期送达
• Wrong requirement错误的要求
• User dislike it用户不喜欢它
• There are no customer没有顾客

失败原因：软件开发方向错了（没理解需求）

需要完全理解和验证需求Fully understand requirement and validate requirement

如何最小化风险：

•Communication with the client
• Feasibility studies
• Separation of requirements from designs
• Validate software requirements
• Milestones and releases
• Acceptance and user testing

•与客户沟通
• 可行性研究
• 需求与设计的分离
• 验证软件需求
• 里程碑和版本
• 验收和用户测试

Lecture2：Software processes

⭐必要流程

• Software specification 软件描述
• Software design and implementation 软件设计与实现
• Software validation 软件验证
• Software evolution 软件演变

区别

For a critical systems, a very structured development process is required.关键系统需要结构化流程

For non-critical systems, with rapidly changing requirements, a less formal, flexible process is likely to be more effective. 不关键的系统更灵活的流程更好 

⭐software processes are categorized as either plan-driven or agile processes.

软件流程分为计划驱动流程或敏捷流程。（plan-driven预先计划好更结构化agile后续能根据客户需求添加）

⭐软件流程模型 SOFTWARE PROCESS MODELS

是软件流程的简化表示，课程中主要讨论下述三种模型

The waterfall model

模型图示

瀑布模型属于plan-driven process的一种，也叫software life cycle

理论上在上一阶段没完成前不能进行下一步，在实践中每个阶段会互相提供信息

迭代成本高，通常解决方法是在一定次数迭代后freeze部分开发阶段只做后面的，忽略掉可能的问题或后续解决。如果冻结过早会导致与客户需求不符

Operation and Maintenace阶段投入使用，根据反馈进行下次维护

在每个阶段会生成相应的文档document，优点是流程可见可监控进度，缺点是项目不灵活不好响应客户变化的需求

什么时候使用瀑布模型：充分理解需求并且客户需求不太可能发生大变化

Incremental development

模型图示

增量开发是agile process的基本组成，先开发一个早期版本，并在后续根据客户反馈逐渐更新版本

Specification, development, and validation这三项是交错的（interleaved）

增量开发在更改环节会更简单便宜，早期版本提供最重要/最急迫需要的功能以进行评测，每次增量的测评相对独立，其他需求会在后续的更新中逐渐加上

三个重要优势：

1.The cost of accommodating changing customer requirements is reduced. 根据客户需求进行更改的成本低
2.It is easier to get customer feedback on the development work that has been done. 做好的工作更易得到反馈
3.More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. 更快速的交付可用软件，暂时没有所有需求功能也行

劣势：

The process is not visible.进程不可见不好管理

System structure tends to degrade as new increments are added.系统结构会逐渐退化

在大型、生命周期长的系统中问题会更加凸显，因为团队开发需要稳定的框架结构→可以细化工作下派到每个团队。所以这种系统应该用plan-driven

Reuse-oriented software engineering

这个模型不是重点但是最好也看看

在面向重用的过程中可以使用三种类型的软件组件：

1.Web services 根据服务标准开发并可用于远程调用的Web 服务。
2.Collections of objects 作为包开发的对象集合，以便与.NET 或J2EE 等组件框架集成。
3.Stand-alone software systems 配置为在特定环境中使用的独立软件系统

优点和缺点：

减少要开发的软件数量，开发速度快。但是需求妥协可能背离原先需求，并且重用组件更新不可控

软件流程活动 Software process activity

瀑布模型里是organized in sequence增量里是interleaved

⭐Software Specification

理解和定义的过程，如果错误会影响后面所有进程，很关键

目的是生成一个需求文档，分为高级别要求high-level statement给客户以及详细系统描述detailed system specification给开发者

⭐Software Design and Implementation

目标是把系统描述转化成可执行系统

A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used. 

软件设计是对要实现的软件结构、系统使用的数据模型和结构、系统组件之间的接口以及有时使用的算法的描述。

Architectural design确认系统总体结构、主要组件(principal components)之间的关系和组合方式

Interface design定义组件间的接口

Component design设计每个组件结构

Database design设计数据库结构和数据如何表现

不同流程下的design output细节和表现形式不同，例如critical system要有详细说明的文档，而使用agile process时可以在程序代码中呈现

⭐Software Validation

verification and validation（v&v）确定系统符合自身描述并满足客户需要

主要以程序验证

三阶段测试：系统组件测试，集成系统测试（接口组件交互有没有问题），用户数据对系统测试

名字分别为Development testing ，System testing ，Acceptance testing

通常测试与开发同时进行，开发一点测试一点

Software Evolution

软件更改比硬件便宜

要把开发和维护当作一个演变过程而不是两个独立的部分

Lecture3：Agile method

背景：市场环境变化快，企业需求变化大，企业愿意牺牲质量快速得出短期可用的软件，同时用户也能通过得到的系统更加明确自身需求

⭐快速软件开发 Rapid Software Development

主要由增量开发

由一系列增量开发而不是作为单个单元unit开发，每次增量都包含新功能

System user interfaces are often developed using an interactive development system that allows the interface design to be quickly created系统用户界面通常使用交互式开发系统来开发，该系统允许快速创建界面设计

其他方法有：

Adaptive software development 自适应软件开发
Agile methodologies 敏捷方法论
Spiral model 螺旋模型
Unified software development process 统一的软件开发流程

⭐Agile Methods

agile使开发人员可以专注于程序本身而不是设计和文档，最小化正式文档

好处之前写过了

agile manifesto敏捷宣言？

Individuals and interactions over processes and tools 个体的交互胜过流程和工具
Working software over comprehensive documentation 工作软件胜过全面的文档
Customer collaboration over contract negotiation 客户协作胜过协商合同
Responding to change over following a plan 响应变化胜过遵循计划

五个原则

五个原则：客户参与，增量递交，不规定过程，拥抱变化，保持简单

实践中难以成功的原因

1.客户是否愿意花时间并且代表所有利益相关者

2.团队成员性格可能不适合intense involvement

3.多个利益相关者参与下优先级难以评价

4.为了保持简单需要更多工作

5.客户难以接受非正式流程

6.软件需求文档通常是合同的一部分，且为增量开发制定合同难

7.agile method依赖于合同规定时间而不是特定需求，出现问题情况下不好分锅

维护相关（非重点）

agile method的维护关键不在于正式文档而在于高质量可读的代码以及系统需求文档。同时开发者团队应该减少人员更替，因为敏捷开发依赖于开发者对系统的了解而不需要借助文档，如果更换了开发者后来的很难与之前的有相同的开发思路和理解。

⭐计划开发与敏捷开发

要决定这两种开发的平衡就要先理解下列问题

Detail specification and design needed? 需要详细规格和设计吗？
Is incremental strategy realistic? 增量战略现实吗？
How large is the system? 系统有多大？
What type of system being developed? 正在开发什么类型的系统？
System life span? 系统寿命？
Available technologies and tools? 可用的技术和工具？
Organization of the team? 团队的组织？
Cultural issues? 文化问题？
Available skillsets? 可用的技能组？
External regulation? 外部监管？

Lecture4：Requirements Engineering

这节课的内容主要是Software Specification的细化

⭐背景

系统的需求是对系统该干什么的描述（用户对系统的需求）

Requirement Engineering 就是找出、分析、记录、检查这些需求的工程（也可以说是Software Specification）

⭐用户需求和系统需求

User requirements - Statements in a natural language plus diagrams to describe the services and constraint of a system 用自然语言的陈述加上图表来描述系统的服务和约束
System requirements - more detailed descriptions of the software system’s functions, services, and operational constraints. Can be part of the contract 对软件系统的功能、服务和操作约束的更详细描述。 可以作为合同的一部分

为什么合同中用系统需求比用户需求更好：

软件合同是一份具有法律约束力的文件，说明了期望和责任等。 与用户需求相比，系统需求包括更具体的信息，阐明了确切的需求。 因此，系统需求更适合在软件合同中使用。

⭐功能需求和非功能需求

Functional requirements

系统应提供的服务的陈述，服务在特定情况下如何反应和表现

表达为用户需求时通常以用户能理解的抽象方式描述（high-level）

表达为系统需求时会更详细

The functional requirements specification of a system should be both complete and consistent. 

系统的功能需求规范应该是完整且一致的。完整：所有需求都被定义 一致：需求不自相矛盾    （实践中很难做到。 原因：1.为复杂系统编写规范时易出错 2.利益相关者之间的需求不同

Non-functional requirements

系统提供的服务或功能的约束constraints，适用于整个系统而不是特定的单个系统服务或功能

与客户的需求不直接相关，类似：性能，安全性，可用性等

通常比个人的功能需求更重要  原因：未满足可能意味着整个系统都无法使用

影响系统整体框架而不是特定组件，单个非功能性需求可能产生多个功能性需求

非功能需求的分类

Product requirements 指定或约束软件的行为

Organizational requirements 源自客户和开发人员组织中的政策和程序的广泛系统要求

External requirements 源自系统及其开发过程外部因素的所有需求

非功能需求的可测试性

用户经常将非功能需求当作目标，如要求系统能快速上手且不会出错（无法评估测试）

这六项是非功能需求的一般测试要点

软件需求文档 

The software requirements document（或SRS（SR Specification））是开发者需要实现的正式文档，应包括用户需求和系统需求。

适合需求稳定的业务系统，尽管敏捷开发方法中认为它会快速过时，但是简短的支持文档依然有用。

详细程度与开发的系统类型和开发过程相关   例：critical system或外包开发就要详细，内部开发或迭代开发就能少点细节。

⭐软件需求文档的质量特性

• Correct
• Complete
• Unambiguous
• Verifiable
• Consistent
• Ranked for importance and/or stability
• Modifiable
• Traceable

⭐Requirements Engineering Processes

四大项高级活动：

评估系统是否对业务有用（可行性研究）
发现需求（获取和分析）
将这些要求转换成某种标准形式（规范）
检查需求是否正确定义了客户想要的系统（验证）。

螺旋视图迭代过程

⭐获取并分析需求 Requirements Elicitation and Analysis

软件工程师与客户合作去了解：软件应用领域、系统应提供的服务、系统所需性能、硬件限制等

与其相关的人物很多，例如最终用户、相关系统工程师、企业经理、领域专家、工会代表等

不同组织的工作流程不同，但是相同的是需求获取和分析是一个迭代的过程（如下图）

获取并分析需求的难点

1.利益相关者很难了解自身需求并能清晰描述出来，同时会提出一些不切实际的需求因为不知道计算机能实现什么不能实现什么（给我一个能识别用户手机壳颜色的应用）

2.利益相关者提供需求时用自己行业的术语并忽略了提供隐性知识

3.不同的利益相关者之间的需求会有冲突（写到这里才发现好像这些难点之前都提过）

4.政治因素和商业环境等外部因素会变化，影响系统的要求

发现需求 requirement discovery

指收集所需系统和现有系统的信息，并从这些信息中提取用户和系统需求的过程。

信息来源包括文档、系统利益相关者和类似系统的规范。

四个收集方法：

interviews 与利益相关者进行访谈，分为closed和open，封闭访谈以提前准备好的问题提问，开放访谈没有预先设置好的问题。有利于了解利益相关者如何和系统交互和面临的困难。难点在于上面的2
observation 观察 一种观察方法是Ethnography，分析师将自己沉浸在工作环境中，观察参与者所参与的实际任务。可以知道用户实际使用方式而不是流程定义的应该使用方式。
scenarios 预先设定一个场景进行讨论，
prototypes 原型

⭐规范要求 Requirements Specification

在需求文档中详细描述用户和系统需求，用户和系统需求应该清晰、明确、易于理解、完整和一致clear, unambiguous, easy to understand, complete, and consistent。

用户需求需要用让不了解技术的客户也能理解方式描述功能需求和非功能需求

系统需求是用户需求的扩展版本，要解释系统如何提供用户需求

实际上包含了一定的design部分，因为规范基于系统的初始框架制定，所以要先设计初始框架

为了自然语言规范可以用结构化自然语言Structured natural language 描述，也可以换成表格

⭐验证要求 Requirements Validation

因为SRS需要正确以防后期返工，所以验证很重要

五项检查：

Validity checks 有效性检查，确定系统需要执行的功能与提出的需求相同

Consistency checks 一致性检查，确定同一系统功能不自相矛盾

Completeness checks 完整性检查，确定文档包含所有需求

Realism checks 现实性检查，确定文档内容可以实践

Verifiability 可验证性，确定所有功能都可验证

验证技术：

Requirements reviews 审查者团队系统地分析需求，检查是否存在错误和不一致。

Prototyping 向最终用户和客户演示相关系统的可执行模型

Test-case generation 通过生成测试用例确定需求是否可以实现，难以生成测试用例→难以实现