CPT203 （1/N）

因为这门课挂了，正好拿来补考刷分，再重新学一遍，夯实基础。

基础目标定在80分吧。

下面的内容会随着我的学习进度时不时更新，包括前一年的两套试卷和解答。

摘要-

这门课描述了很多关于基本软件工程活动(fundamental software engineering activites)的问题，以及更重要的——用来解决这些问题的方法和工具。当课程结束时，学生们被期望可以认识/发觉在设计和建造重要计算机系统时存在的问题，并领会以面向对象的方法设计和开发软件系统及其组件的原理和实践，并且在实践的时候运用这些原理。

学习成果：

A-能够理解并描述以满足业务为目标的计算机系统在设计和构建时所涉及的问题和方法。

B-离解如何引出用户的需求，并将其纳入系统的设计中，同时能够识别相关的法律、社会、道德和专业问题。

C-认识到有必要确保设计方案的实施能够经过充分测试，以确保完成的系统符合规范(specification)。

D-应用面向对象的方法来设计和开发软件系统及其组件。

E-识别计算机系统操作中可能涉及的任何风险或安全方面的问题。

下面开始正文：

首先，我会按每周的内容来分割，伴随这进度的深入，我可能不再会按周来分类，而是按照内容来分类。其次，我会在相应的内容下面备注考试的点，以及在考试题下面表面该题需要掌握的内容来自于哪一部分的知识。

Week1: Introduction

记住这一句核心内容：软件工程是一门涉及软件生产的所有方面的工程学科。

首先，请注意，软件系统是抽象且无形的，它们不受材料性质的约束，不受物理规律的约束，也不受制造过程的约束。这意味着：

这些特性简化了软件工程，因为软件的潜力没有自然的限制。

但同时，这也意味着由于缺乏物理约束，软件系统可能很快变得极其复杂，难以理解，而且更改成本高昂。

通常情况下，会软件故障的主要原因是以下两个：

-增长的需求

-低期望值（Low Expectations，暂时先这么理解吧）

而专业的软件开发，通常由一个团队而不是个人来完成。

在开发的整个生命周期内，都需要进行维护和改变/更换（change）。

---注意，在这里上下所提到的专业的软件开发和专业软件的开发指的并不是同一事物---

而软件工程旨在支持专业的专业软件开发，而非个人编程（团队配合，以专业的模式去进行合作开发，而开发的目标软件通常也具有相当程度的专业性）。

•包括支持程序说明（program specification）、设计（design）、验证（validation）和演变/进化（evolution）的技术。

作为专业软件，它通常具有以下属性：

•严格的用户需求
•要求准确性和数据完整性
•更高的安全标准
•负载大时性能稳定
•需要技术支持等

软件工程的核心定义：

软件工程是一门工程学科，涉及软件生产的所有方面，从系统规范的早期阶段到系统投入使用后的维护。

软件工程方法：

系统的产生软件的软件工程方法被称作软件过程，有四个基本的活动是所有软件过程共同的：
•软件规范-specification
•软件开发-development
•软件验证-validation
•软件进化-evolution

此外，不同类型的系统需要不同的开发过程。
•例如，飞机上的实时软件必须在开发开始前完全指定。在电子商务系统中，规范和程序通常是一起开发的。

Week2: Software process

这一周主要讲述了软件过程的概念以及模型。同时提供了在一般情况下3种通用的软件过程模型以及其所需的大概时间。此外，还对需求工程（Requirement Engineering），软件的开发和测试，以及演变（Evolution）作出了额外介绍。

概念：软件过程是导致软件产品生产的一系列相关活动。它可能涉及到以下三点：

-从零开始开发软件。

-扩展和修改现有系统。

-配置和集成现有的软件或系统组件。

已有的软件工程有许多种，但一般情况下，都必须包含以下4种对软件过程至关重要的活动：

•软件规范-specification
•软件设计与实现-design and implementation
•软件验证-validation
•软件进化-evolution

而在实践中，它们本身是复杂的活动，同时活动下还包括许多子活动。同时还有支持过程活动，如文档和软件配置管理。

软件过程是复杂的，难以衡量的点在于——没有理想的软件过程，各种意外情况总会出现。

现今大多数组织已经开发了他们自己的软件开发过程，利用了组织中人员的能力和正在开发的系统的特定特征。例如：

•对于一个关键系统，一个非常结构化的开发过程是必需的。
•对于业务/商业系统，随着需求的快速变化，一个不那么正式、灵活的过程可能更有效。

软件过程一般分成两类：计划驱动和敏捷。

前者是指所有过程活动都提前计划好，并根据该计划来度量进度的过程。

而在敏捷过程中，计划是增量的，更容易更改过程以反映不断变化的客户需求。

软件过程模型：

概念：软件过程模型是软件过程的简化表示。

它们源自于对流传非常广泛/泛用性很高的流程模型的讨论，并从体系结构的角度(流程的框架，而不是具体活动的细节)来表示这些模型。

这些通用模型不是软件过程的最终描述，它们是过程的抽象，可以用来解释软件开发的不同方法。

我们可以将它们看作过程框架，它可以被扩展和调整以创建更具体的软件工程过程。

总而言之，模型并不会告诉你具体怎么做，而是告诉你在这种情况下还需要去执行的是什么。

在这里，我们讨论3个模型:

1-瀑布模型：

该模型采用规范、开发、验证和演进的基本过程活动，并将它们表示为单独的过程阶段，如需求规范、软件设计、实现、测试，等等。如图所示：

由于从一个阶段到另一个阶段的级联，这个模型被称为“瀑布模型”或软件生命周期。瀑布模型是计划驱动过程的一个例子，而

这一幅图——瀑布模型的主要阶段直接反映了基本的开发活动：
•需求分析和定义
•系统和软件设计
•实现和单元测试
•集成和系统测试
•操作维护

原则上，每个阶段的结果是一个或多个被批准(签字)的文件。在前一个阶段结束之前，不应该开始下一个阶段。在实践中，这些阶段重叠并相互提供信息。软件过程不是一个简单的线性模型，而是涉及到从一个阶段到另一个阶段的反馈。每个阶段产生的文件可能必须加以修改，以反映所作的更改。

同时，由于生产和批准文档的成本，使用迭代开发可能是昂贵的，这会涉及大量的返工。因此，在少量的迭代之后，冻结开发的某些部分是正常的，比如规范，然后继续后面的开发阶段。问题留给以后解决，如忽略或编程处理。这种过早地冻结开发任务可能意味着系统无法交付用户所期望的东西。

在最后的生命周期阶段(操作和维护)，软件投入使用。发现了原始软件需求中的错误和遗漏。出现程序和设计错误，并确定了对新功能的需求。因此，这个系统必须不断发展，才能继续发挥作用。进行这些更改(软件维护)可能涉及重复前面的过程阶段。

总结：
在瀑布模型中，每个阶段都会产生文档。这使得过程可见，因此管理人员可以根据开发计划监视进度。它的主要问题是不灵活地将项目划分为不同的阶段。必须在过程的早期阶段做出承诺，这使得很难对客户需求的变化做出响应。原则上，瀑布模型只应该在需求被很好地理解并且不太可能在系统开发期间发生根本变化的情况下使用。

2-增量式开发模型：

这种方法将规范、开发和验证活动交织在一起。系统以一系列版本(增量)的形式开发，每个版本都在前一个版本的基础上增加功能。如图：

增量开发是基于开发初始实现的想法，将其暴露给用户评论，并通过几个版本对其进行改进，直到开发出一个足够的系统。在这个模型中，规范、开发和验证活动是交错的，便于活动之间进行快速的反馈。增量式软件开发是敏捷方法（大三下学期的软件工程团队开发会使用敏捷开发）的基本组成部分，对于大多数业务、电子商务和个人系统来说，它比瀑布式方法更好。

通过增量开发软件，在开发过程中对软件进行更改会更便宜、更容易。系统的每个增量或版本都包含了客户需要的一些功能。通常，系统的早期增量包括最重要或最迫切需要的功能。这意味着客户可以在开发的相对早期阶段评估系统，看看它是否交付了所需的东西。如果没有的话，只需要更改当前增量，并可能为以后的增量定义新功能。

与瀑布模型相比，增量开发有三个重要的好处:
1.适应不断变化的客户需求的成本降低了。
2. 对于已经完成的开发工作，更容易得到客户的反馈。
3.更快速地向客户交付和部署有用的软件是可能的，即使它没有包括所有的功能。

从管理的角度来看，增量方法存在两个问题:
1.过程不可见。
2.随着新增量的添加，系统结构趋于退化。

增量开发的其他问题包括:
1.大型组织的官僚程序随着时间的推移而演变，这些程序和更非正式的迭代或敏捷过程之间可能不匹配。
2.外部法规(如，会计法规)需要正式的过程。

总结：
增量开发的问题对于大型的、复杂的、长生命周期的系统变得特别尖锐，因为是由不同的团队来开发系统的不同部分。大型系统需要一个稳定的框架或体系结构，处理系统部分的不同团队的责任需要根据该体系结构明确定义。这必须提前计划，而不是逐步发展。

3-面向重用软件对象的开发模型（Reuse-Oriented）：

在大多数软件项目中，存在一些非正式的软件重用形式。这种非正式的重用与其所使用的开发过程无关。在21世纪，以现有软件的重用为重点的软件开发过程得到了广泛的应用。面向重用的方法依赖于大量的可重用软件组件和用于组合这些组件的集成框架。如图：

有三种类型的软件组件可以在面向重用的流程中使用:
-根据服务标准开发的Web服务，可用于远程调用。
-对象的集合，这些对象被开发成一个包，并与组件框架(如. net或J2EE)集成。
-为在特定环境中使用而配置的独立软件系统。

总结：
优点在于减少了软件的开发数量，从而降低了成本和风险。这通常也会导致更快的软件交付。

然而，需求妥协是不可避免的，这可能导致系统不能满足用户的真实需求。
此外，当可重用组件的新版本不受使用它们的组织的控制时，对系统发展的一些控制就会丢失。

软件过程活动：

真正的软件过程是技术、协作和管理活动的交错序列，其总体目标是指定、设计、实现和测试软件系统。规范、开发、验证和演进这四个基本过程活动在不同的开发过程中以不同的方式组织。在瀑布模型中，它们是按顺序组织的。在增量开发中，它们是交织在一起的。这些活动如何进行取决于所涉及的软件、人员和组织结构的类型。

软件规范：

软件规格说明或需求工程是理解和定义：
系统需要哪些服务的过程，并确定系统运作和发展的制约因素。

需求工程是软件过程中一个特别关键的阶段，因为这个阶段的错误不可避免地会导致系统设计和实现的后续问题。

需求工程过程的目的是产生一个商定的需求文档，该文档指定了一个满足涉众需求的系统。
需求通常以两个层次的细节来表示：
•终端用户和客户需要一份高层次的需求声明。
•系统开发人员需要更详细的系统规范 。

在需求工程过程中有四个主要活动:
•可行性研究
•需求提取和分析
•需求规范
•需求验证

软件设计与实现：

软件开发的实现阶段是将系统规范转换为可执行系统的过程。它总是涉及软件设计和编程的过程，但是，如果使用增量开发方法，也可能涉及细化软件规格说明。软件设计是对要实现的软件结构、系统使用的数据模型和结构、系统组件之间的接口，有时还包括所使用的算法的描述。

设计师不会立即完成设计，而是反复开发设计。他们在开发自己的设计时不断地回溯以纠正早期的设计，从而增加了正式性和细节性。

设计活动：
体系结构设计，确定系统的整体结构、主要组件(有时称为子系统或模块)、它们的关系，以及它们如何分布。

接口设计，定义系统组件之间的接口。这个接口规范必须是明确的。

组件设计，也就是选择每个系统组件并设计它将如何运行。
对预期功能的简单说明。
要对可重用组件进行的更改的列表。
详细的设计模型(模型驱动方法)。

数据库设计，设计系统数据结构以及如何在数据库中表示这些结构。

设计输出：

设计输出的细节和表现形式变化很大。
•对于关键系统，必须制作详细的设计文件，对系统进行精确和准确的描述。
•如果使用模型驱动的方法，这些输出可能主要是图表。
•在使用敏捷开发方法的情况下，设计过程的输出可能不是单独的规范文件，而是在程序代码中表示。

模型驱动开发(MDD)或模型驱动工程(Schmidt, 2006)，其中软件的模型是在不同的抽象级别上创建的。

这些模型被充分详细地开发，因此可以从它们生成可执行系统。软件开发工具可以用于从MDD生成一个框架程序。

这包括定义和实现接口的代码，在许多情况下，开发人员只需要添加每个程序组件的操作细节。

软件验证（Validation）：

更通常的讲，是检测（verification）和校验（Validation）。它旨在表明：
一个系统既符合它的规范；
又能满足系统客户的期望；

程序测试(使用模拟测试数据执行系统)是主要的验证技术。校验还包括检查过程，例如检查和评审，在软件过程从用户需求定义到程序开发的每个阶段。

3个阶段的测试过程包括测试系统组件，然后测试一个完整的系统，最后用客户的数据测试系统。测试过程的各个阶段如下:
•开发（Development）测试——组成系统的组件由开发系统的人员进行测试。每个组件都是独立测试的，没有其他系统组件。
•系统（System）测试——系统组件被集成以创建一个完整的系统。此过程涉及查找由于组件之间的意外交互和组件接口问题而导致的错误。
•验收（Acceptance）测试——这是测试过程的最后阶段，在系统被接受投入使用之前。该系统使用系统客户提供的数据进行测试，而不是使用模拟测试数据。

总结：
通常，组件开发和测试过程是相互交织的。程序员编写他们自己的测试数据，并在开发代码时逐步测试代码。如果使用增量开发方法，则应在开发时对每个增量进行测试，这些测试基于该增量的需求。当使用计划驱动的软件过程时(例如，对于关键系统开发)，测试是由一组测试计划驱动的。一个独立的测试人员团队根据这些预先制定的测试计划工作。

软件演进（Evolution）：

一旦决定制造硬件，更改硬件设计是非常昂贵的。但是，可以在系统开发期间或之后的任何时候对软件进行更改。即使是大范围的更改也比相应的系统硬件更改要便宜得多。历史上，软件开发过程和软件发展过程(软件维护)之间一直存在分歧。人们认为软件开发是一种创造性的活动，在这个活动中，软件系统从一个最初的概念发展到一个工作系统。然而，他们有时认为软件维护是枯燥和无趣的，而不是两个独立的过程，更现实的是把软件工程看作一个进化的过程。