Ch0 题型

1. 选择题（多选）：3x10【分点罗列】

2. 看图分析：10x2【图表】

3. 分析题：10【基础知识】

4. 建模分析题：20【分析一个系统】

5. 综合应用题：30【整个流程】

PDF版笔记

参考资料

WWWsy03 - Overview

WWWsy03 has 3 repositories available. Follow their code on GitHub.

https://github.com/WWWsy03

练习题

Ch1 软件的本质

1.1 软件的本质

• 软件开发时间长的原因
1. 需求调研不清，导致开发时不断迭代
2. 分析、设计等建模不规范，过程控制不规范
3. 开发过程中培训欠缺，导致开发质量低

• 为什么在软件交付用户之前找不到所有错
1. 理论上业务路径是无穷的，测试只能测基本业务，不能cover全部
2. error不仅在分析建模时会被发现，运行过程中也会出现error

• error、failure、defect区分
• error：开发过程中出现的各种问题
两种error检查的技术：
• review technology 评审技术
• testing technology 测试技术
• failure：交付之后运行的结果不符合顾客的需求，failure可能由一个或多个error导致
• defect：运行过程中出现failure的error

• 开发进度评估测量：measure progress，甘特图可以很好的解决过程的跟踪问题

• DevOps：development in operations，软件开发人员和订正人员(Ops)之间的沟通合作

• 微服务：将整个Web应用组织为一系列小的Web Service，这些小的Web Service可以独立的编译部署，并通过各自的API接口相互通信，彼此相互协作，作为一个整体为用户提供服务，但可以独立进行扩展。优点：一个微服务出错不会影响其他

软件的定义与软件工程的定义(3+3)

1. 是计算机程序，指令代码——程序 完成软件的特性，功能，性能 等所需要的
instructions (computer programs) that when executed provide desired features, function, and performance
feature：特性，非功能性需求，如可以执行、兼容性、可扩展性
function：与非功能性需求对应
performance：性能，feature的一部分

2. 是数据结构——数据 使得程序可以充分利用操纵信息所使用的
data structures that enable the programe to adequately manipulate information

3. 是描述性信息——文档 描述程序操作使用的硬拷贝和虚拟形式的
descriptive information in both hard copy and virtual forms that describe the operation and use of the programs.

软硬件生命周期曲线 (2)

软件应用领域 (7)

1. System Software 系统软件（偏底层）：eg.操作系统软件（应用软件运行在这之上）——算法核心\路由器里的软件

2. Application Software 应用软件：解决特定需求的独立应用程序。

3. Engineering/scientific Software 工程/科学软件：eg. matlab

4. Embedded Software 嵌入式软件：例如家电内部的，汽车内部的 ——操作系统特殊，硬件交互性强，错误较难以定义

5. Product-line Software 产品线软件：为不同用户提供特定功能

6. Web/mobile App：browser-based

7. AI Software 人工智能软件：机器人，博弈，模式识别（语音图像），自动驾驶，自然元素处理（文本）

遗留软件 Legacy Software

• 特点(3)：longevity（时间久远）、business criticality（业务关键性，数据难以移植、风险大、很少重新开发）、poor quality（可读性差、文档混乱）

• 遗留系统演化原因(4)：
1. 【环境】适应新环境、新技术 new tech adapted
2. 【业务】实现新的业务需求 enhanced implementation
3. 【数据】扩展使得可以与更多的系统交互 extend
4. 【系统架构】需要重新部署来适应新环境 re-architected

1.2 软件的演变

• 网页应用、移动设备、云计算、产品线软件

▲ 云平台架构 Cloud Computing (4)

1. IaaS 资源层或基础设施层 Infrastructure as a Service
由服务器集群组成，有集群之后可在物理机上创建虚拟机来最大化资源利用率
管理硬件

2. 虚拟层
KVM、XEN等将硬件资源虚拟化

3. PaaS 中间件层或平台层 Platform as a Service
该层是云平台的核心层，负责资源监测、预警、优化决策
Nginx、k8s（Kubernetes，一种开放源码的容器集群管理系统，能够实现自动化部署、扩展容器集群、维护等功能）

4. SaaS 应用层或软件服务层 Software-as-a-Service
给用户提供可视化界面

Ch2 软件工程

2.1 软件工程的定义

▲ 软件工程的定义 (3)

1. 【工程在软件中的应用，SDQ】系统的、规范的、可量化的方法应用于软件开发、运行、维护
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application ofengineering to software.
可量化的：定量的对项目进行评审（review），例如error in specification per page

2. 【对1中的研究方法】
The study of approaches as in (1).

▲ 软件工程的层次 (4)

1. 质量：软件开发要工程化，核心是提高质量

2. 过程化：回答如何提高质量

3. 方法：方法贯穿在过程中，UseCase建模，数据库设计方法，架构方法，分析方法，设计方法，测试方法等多种方法

4. 工具：现在很多方法和技术都工具化了，有软件工程的工具统称为CASE（computer-aided software engineering 计算机辅助软件工程）

2.2 软件过程

对Process的分解

Process→细分为若干activity→细分为若干action→细分为最小的task，task是最小单元，原子性，高内聚

• activity: 力求实现一个广泛的目标——e.g：stakeholder的沟通

• action: 包含一组产生主要工作产品的任务——e.g：架构设计；一个action要有主要工作产品work product(e.g 架构模型)

• task: 侧重于产生实际结果的小而明确的目标——e.g：单元测试

▲ 过程框架 Process Framework (2)

1. Framework Activity 正常开发活动【开发维度】
需求调研，需求分析，设计，coding等

2. Umbrella Activity 普适性活动【管理维度】
普适性活动贯穿于整个软件开发过程
普适性活动的目的
• 提高软件开发过程中的工作产品的质量
软件质量是在开发过程中形成的，通过活动、管理，提高软件开发质量
• 控制进度，保障质量，规避风险
milestone：经过framework activity和umbrella activity后可以交付给下一个阶段

▲ 通用过程框架包含的活动 Framework Activity (5)

1. Communication
需求收集requirement gathering，需求模型诱导elicitation

2. Planning (umbrella activities)
planning是一个大的，阶段的计划（如人员安排等），有很多template

3. Modeling
需求分析建模(requirement analysis modeling)，概要设计(high-level design/architecture design)，组件设计(detailed design/component design)

4. Construction
coding，testing（unit、integration、system、acceptance）

5. Deployment
release，delivery，feedback，support 交付、部署、反馈、支持

典型的普适性活动 (8)

1. Software Project Tracking & Control
软件项目跟踪控制（如：人员计划，发挥成员特长能力，了解人员是tracking，调整人力是control）

2. Risk Management
风险管理是定量管理，（例如，人员流失跳槽风险，新技术，云平台不熟悉，数据库不熟悉等...）
风险管理三个阶段：risk management是task但也是umbrella activity
1. risk identification：风险定位
头脑风暴，相关经验，专家建议
2. risk mitigation：风险缓解
针对优先级高的risk制定计划
3. risk tracking：风险追踪
用于核对plan是否起效，一般在develop activity结束时总结一次

3. Software Quality Assurance (SQA)
软件质量保证——定义和实施确保软件质量所需的活动；(编程管理，代码规范，需求规约等）有Checklist，在过程中随时进行检查

4. Technical Reviews
review发现error，对此进行修改，或再进行review，最后进行audit，达成milestone

5. Measurement
测度，对schedule进行测量，对不同时间和schedule的偏差进行度量metric，对发现的缺陷进行度量，对人员工作量进行度量等
发现errors，对errors计数是measure；对measure进行计数是metric

6. Software configuration
软件配置管理; 比如用 Github 进行管理，configuration item，check in - check out的一个基本单元，如修订后的用例规约也算

7. Reusability Management
可重用性管理，前提是重构，让代码和类标准化(可以复用)；

8. Work product preparation & production
工作产品准备和生产，包括创建工作产品所需的活动，例如模型、文档、日志、表格和列表。项目过程中的文档等常数需要整理出来，形成标准化。

流程调整的体现 Process Adaption (9)

1. activity, action, task的总体流程（overall flow）以及它们之间的相互依存关系，有的流程可以根据项目情况裁剪掉

2. action和task在每个framework activity中的定义程度，每个任务要做到什么程度可以调整

3. work product的定义要求的差别

4. QA质量保证Activity实施的方法

5. 项目跟踪控制和控制类Activity实施的方法

6. 过程progress描述的的严格和详细的程度

7. stakeholder的参与度（可能是使用完反馈，也可能是直接干预开发）

8. 团队的自主程度

9. 类似项目有没有类似经验（prescribed）

2.3 软件工程的实践

实践的精髓 (4)

1. 理解问题
交流(requirement gathering)、计划(planning)，实质是需求调研、需求工程，主要是解决以下具体问题：
1. 谁是利益相关者（stack holder，customer）
2. 不确定因素，数据、功能和特性（特性还包括一些非功能需求，如安全性，performance，都很重要）
3. 问题能否划分，需求能否分解，减小粒度（在UML里和Use Case,Class Diagram相关）
4. 问题可以可视化表现，分析模型（analysis model）能否建立;

2. 策划解决方案
根据上一个阶段的结果，进行建模（数据，功能等角度），提供一种解决方案（比如：框架，接口，界面，数据库的设计），核心是概要设计与详细设计，具体是指：
1. 有无相似的模式可以复用，（设计模式，相似项目，数据，功能，非功能需求等)；
2. 类似的问题有无解决方法，有无可复用的解决方案元素；
3. 子问题能否被定义，子问题的解是否显而易见的（软件架构）;
4. 能否以一种能够有效实施的方式来表示解决方案？能否创建设计模型(design model)？

3. 实施计划
核心是代码生成与项目实现（code generation and implementing solution）
1. 解决方案是否符合计划？ 源代码是否可以追溯到设计模型（你的代码要对应设计架构，比如说，哪部分代码对应了某功能的微服务）
2. 解决方案的每个组成部分(component)是否正确？ 设计和代码是否已经过审查（review 是Umbrella Activity），或者更好，是否已将正确性证明应用于算法

4. 检查结果
核心是测试与质量保证（testing and quality assurance），具体解决以下问题：
1. 是否可以测试解决方案的每个组成部分?（单元测试,每个类都有状态图State Diagram,利用状态图进行测试），是架构设计的重要依据) 是否实施了合理的测试策略(testing strategy)
2. 解决方案是否产生符合所需数据、功能和特征的结果？ 软件是否根据所有利益相关者的要求进行了验证(validate->也叫system testing系统测试)？

开发原则 (7)

1. 存在价值 the reason it all exists
项目的价值是什么，能不能带来生成效益

2. 保持简洁 KISS(Keep It Simple Stupid)
架构简单清晰明了

3. 保持视图 maintain the vision
保持每个阶段可见，可视化，using类图或其他工具

4. 关注使用者 what you produce, others will consume
软件做完后有没有受众面，对客户有作用（输入输出）

5. 面向未来 be open to the future
可扩展性，比如,接口不写死, 类便于修改维护

6. 提前计划复用 plan ahead for reuse
代码尽量标准化，提前考虑组件复用性前瞻性，降低成本

7. 认真思考 think

2.4 软件开发的误区

软件开发的误区 (4)

1. management myths
• 现有的标准和流程可能未被广泛使用或者不够灵活适应现代软件工程实践
• 增加程序员可能导致更多延误

2. customer myths
• 目标不明确会导致项目失败，后期引入需求会大幅度提高成本

3. practitioners myths
• 程序写完之后要进行SQA，这是一个持续的过程
• 编写好的文档可以减少重做工作，加快交付进度

Ch3 软件过程

3.1 通用过程模型

• generic process model，区分：framework和umbrella是通用过程框架（process framework）

▲ 通用开发模型 (8)

1. 需求调研（requirement gathering/elicitation）

2. 需求分析建模（requirement analysis）

3. 概要设计建模（high-level design）

4. 详细设计建模（component level design）

5. 编程（coding）

6. 测试（testing）

7. 部署（release）

8. 维护（maintenance）

▲ 工作流种类 Process Flow (4)

1. 线性流 Linear

2. 迭代流 Iterative



• communication和planning反复迭代，是由于
• 有错误等，反复迭代
• 需求变更
• 技术和业务更深层的理解
• 在construction中，testing时发现需求不明确，又要回到communication阶段进行沟通

3. 演化流 Evolutionary



螺旋上升，本质是迭代开发
• 在planning阶段发现有communication的问题，但不回去，而是记录下来直到把本次迭代做完，不论有多少问题，都先进行完本次开发
• increment release：和单纯的迭代流不同，每次迭代完必须要有一个可展示的产品

4. 并行流 Parallel



• planning和modeling同时做，在communication时导出需求，可以进行planning，同时明确的部分可以进行modeling

3.2 定义一个框架活动

小项目框架活动的定义动作 (1)

• action：电话交流

• tasks：
1. 和stakeholder通过电话交流；
2. 商量需求和开发的笔记
3. 将笔记组织成一个简单的需求书面(written)声明；
4. 和stakeholder用电子邮件进行审阅和通过

▲ 大项目框架活动的定义动作 (6)

1. inception 启发

2. elicitation 诱导需求
功能需求和非功能需求function requirement and non-function requirements)→requirement gathering

3. elaboration 细化
建模，用UML各种diagram对需求内容进行抽象

4. negotiation 协商
甲方讨论需要和不需要的需求，需求规约，需求分析，与3存在迭代

5. specification 规约

6. validation 确认

3.3 定义一个任务集

任务集的构成 (4)

1. 软件工程工作的任务 work tasks

2. 相关的工作产品 products

3. 质量保证点 quality assurance points

4. 项目里程碑 project milestone

需求调研的任务集

1. 找stakeholder交流（写名单、预约开会）

2. 展示用户调研成果（user scenario，以use case的形式）

3. 根据反馈进行调整，得到final list

4. 使用质量优先级来排序，对合理的进行打包

5. 标注分享和不清楚的地方，商量评审方法

▲ Coding过程的任务集 (8)

1. 分析理解详细设计（检查规约完整性等）

2. 定义接口（确定算法以及数据结构，对内、对外接口）；

3. 准备环境写代码

4. (单元测试）自我测试self-testing（算法复杂度时间性能）refactor重构（测试后对大项目可能要重构，规范性的）

5. SQA软件质量保证（组织评审会、预审阶段、修改处理情况review and audit）

6. code end（里程碑任务milestone）

提高系统性能的方法 (5)

1. 后端的数据库设计（冗余设计，表空间划分，范式）（高访问量的几张表不能放在一个表空间里）；

2. 架构设计architecture design；

3. 前端和后端的接口（交易频繁的分到不同接口支流中）；

4. 前端本身的memory使用，和后端的通讯；

5. 模拟工具测试得到性能

3.4 过程模式 Process Pattern

过程模式描述模板 (9)

3.5 过程评估与改进

• 基于CMMI的内部过程改进评估 CBAIPI

• SPICE (ISO/IEC15504) 是不同与CMMI的国际软件评估框架

▲ 软件成熟度模型 CMMI (5)

• KPA：key process area，告诉了要做什么（what to do）来到达下一个阶段

1. Initial 【初始】
一种初始的，无政府的状态

2. Repeatable 【标准】
在这个级别一些好的方法和经验在其他项目可以复用
需求管理、软件项目计划、项目跟踪与监督、质量保证、软件配置管理
关键在于①template（文档） ②tools（工具） ③minority&control过程控制（MS-project过程控制软件）

3. Defined 【文档规范】
已定义级，在这个级别，可以根据自身项目情况进行定义，采取同行评审的方式
机构过程焦点（过程能否细分）、机构过程定义、培训大纲、综合软件管理、产品工程

4. Managed 【定量】
可管理级
定量过程管理（defect定量，size项目规模，effort开发精力，schedule日程偏差）、软件质量管理（review检查、revoke发现问题返工、所有测试unit/integration/system）

5. Optimize 【敏捷度】
优化级
缺陷预防、技术更新管理、过程更改管理

标准的CMMI评估方法 SCAMPI (5)

1. initiating 启动

2. diagnosing 诊断

3. establishing 建立

4. acting 行动

5. learning 学习

Ch4 过程模型

4.1 惯用过程模型 Prescriptive Process Models

• 惯用过程模型，这种模型旨在为软件开发提供结构和秩序。

• prescriptive规定了一系列过程元素：framework activities ，SE actions，tasks，work product，quality assurance，change control mechanisms

▲ 瀑布模型 the Waterfall Model (6)

1. 顺序执行（项目发生变更时就不适用，导致混乱）

2. 少量反复与迭代

3. 为V模型的发展提供了理论支持

4. 客户在很长时间后才能看到可以运行的版本

5. 存在block states，会形成阻塞（容错率低，且在项目后期发现难以修复，and阻塞状态）

6. 客户通常很难明确地陈述所有要求（项目开始时便有很强的不确定性）

1. estimating 评估，用于量化评估的两个模型：function point，use case point

2. scheduling 比如waterfall模型中各个阶段的工作具体要多少人，人员安排好、时间计划好

3. tracking

▲ V模型 V-Model (7)

1. acceptance testing → requirements modelling
验收测试是面向用户的，用户不知道实现细节而是以需求为依据，所以是需求层面的（需要用到需求规约和需求分析规约），即Requirement Modeling 验收测试的依据是需求规约和需求分析规约

2. system testing → requirements modelling
把编好的程序放在各种集成环境下
需要参照需求规约中的功能建模（文字描述需求与use case diagram），模拟actor进行一系列的功能测试

3. system testing → architectural design
如果在功能测试中测试失败了，需要查看不同功能模块（已经完成单元测试）的接口，在概要建模中有对于不同地方接口的定义。

4. integration testing → architectural design
是看单元、模块、组件之间的集成
与子系统之间的写作有关，涉及接口、数据库、软件结构设计，需要参考接口设计，数据设计，软件体系架构设计，故看architectural design

5. integration testing → component design
组件之间的集成，需要用到component design

6. unit testing → component design
复杂的代码中如何传参，参数指向什么很复杂，需要查看component design 和 详细设计规约

7. unit testing → code generation
需要看到底层代码的实现

▲ 增量过程模型 Incremental Process Models (5)

1. 需要向用户快速提供一组有限的软件功能，之后再完善和扩展，进行增量补充

2. 有一些内容可以交叉并行

1. 每一次增量都是一个waterfall，一次增量内不主张迭代

2. 第一个增量是核心产品，解决了基本需求，之后完善

3. 每一次的版本都可运行

4. 不同增量之间可以交叉，可以并行开发，如第2个做coding时，第3个可做需求建模

5. 每次增加的功能需求数量固定

• 演化过程模型 Evolutionary Process Model
强调模型迭代 iteration
适用场景：complex、preview、requirement
• 系统复杂，模型演化需求变更
• 短时间出一个功能有限的版本
• 核心需求明确，细节未知

▲ 原型模型 Prototype (2)

1. 【没用】：成型不一定可靠，static的，没有考虑到整体软件质量与长期可维护性，真正的开发需要做到SQA

2. 【不改】：在实现上（如操作系统、编程语言、算法）做出妥协，以便让原型快速工作。

Q:为什么云南婚姻登记系统不适合用原型模型？

A：原型模型一般用于控制在本系统内部的系统，婚姻系统会有大量与外部联网的接口，比如户籍、公安这些，原型很难把这些外部的东西也展现出来，所以不推荐

▲ 螺旋模型 Spiral Model (4)

1. 迭代模型，每次迭代circuit后会得到一个work product（可以是规约）

2. 每个阶段都和waterfall一样都要产生产品，每个阶段都要得到一个结果，每次迭代过程都严格遵守waterfall

3. CPMCD这五个步骤是可裁剪的（可以去掉一些环节）

4. 适用于一些比较大的项目，是在整个软件的生命周期都适用的

Ch5 敏捷开发

5.1 敏捷性含义 Agility

敏捷开发提出的背景

1. 软件产品变化迅速且不断演变

2. 敏捷软件工程哲学鼓励客户满意度和早期的软件交付；小型、高度动力化的项目团队；非正式方法；最少化的软件工程工作产品；以及整体开发的简化。

3. 可调动积极性，管理者（manager）、客户（customer）、终端用户（user）在一个团队中工作

4. 敏捷模型的第一版不同于增量模型，不一定是核心需求，而且后续可以不断地改，开发过程也相对简约，中间产品数量少

5.2 敏捷性与改变成本

修改的构成 (3)

1. corrected 纠错

2. adapation 适应性修改

3. enhancement 新功能添加

▲ 改变成本图的理解 Change Cost (2)

• 回归测试（Regression Testing）是一种软件测试，其目的是确保已经修改的代码仍然符合其原有规格，并且新的修改没有对现有功能造成不良影响。

1. 随着软件开发逐步变化，需求变更可能需要改的部分越多（例如：还在modelling阶段和coding阶段change cost完全不同，coding阶段cost会大得多）

2. 变更多了之后，回归测试成本越来越高，最终翘了上去

5.3 敏捷过程 Agile Process

敏捷开发解决的问题 (3)

1. 【无法预测需求】没有办法提前预测需求是什么，会怎么改，优先级如何

2. 【难以进行设计】design和construction有交叉，过程中的activity是串联的。这样比较难去预测多少design在construction之前是必要的

3. 【实际与预想不同】分析analysis, 设计design, 构建construction和测试testing和预想的不同

5.4 极限编程 XP Process

• spike解决方案（spike solutions prototypes）：实现并评估设计，例如有一个机器模型的算法模块，比较复杂，就先把这个原型写出来再测一下，没问题了再放进去，在真正实现开始时就降低风险

• refactoring 重构：进化代码并简化内部设计，代码写完之后要查一下，如果有不规范的就要重新弄一下，消除代码冗余，使代码通用化、标准化

• continuous integration 连续集成：第一次迭代可能就是把所有的集成，第二次迭代就把后来改的迭代到之前的版本上，建立尽早发现错误的“冒烟测试”环境。

• project velocity computed 项目完成速率：来估算团队在特定迭代或冲刺期间完成多少工作的能力。

▲ 极限编程过程的框架活动 (4)

1. Planning 导出需求
• user stories：用use case构建描述user story，即为用例图中include/extend的部分，验收依据，这里是指这一次迭代选择的，不是所有的；注意拆分大的故事（三个开发周以上）
• values：客户基于特征或功能的整体业务价值为story分配优先级，划分依据：【时间、重要性、风险】
1. 业务上重要性
2. 此功能(story)是否有高风险(high risk)
3. 交付时间(deadline要求）
• acceptance test criteria：根据故事进行验收测试，给出其流程
• 迭代计划

2. Design
• CRC卡片：class-responsibility-collaborator card，包含类里面的属性+方法，以及类之间的协作与交互
• Spike Solution：快速构造算法原型进行测试

3. Coding
• 结对编程：相互检查，写出unit test覆盖逻辑
• 持续集成：将之前写好的和补充上去的进行集成测试，冒烟测试
• 重构：为了代码复用，消除代码冗余，使代码通用化、标准化

4. Testing
• 单元测试：增加test case，结对测试的再测一遍
• 回归测试：修改后的测试
• test suite 测试套件，方便测试
• 验收测试：story全部测试一遍

5. Release
software increment project velocity要计算，衡量完成的占比，调整计划

5.5 其他敏捷过程模型 Scrum and DevOps

• Scrum是轻量级的软件开发过程模型，增量的、迭代的过程，每个迭代结束有可交付的增量

• backlog：需求（用户故事，功能独立、高内聚）列表

• sprint：开发周期的最小迭代周期

▲ 敏捷原则 (4)

1. 个体与交互 > 过程与工具

2. 可以工作的软件 > 面面俱到的文档

3. 客户协作 > 合同谈判

4. 响应变化 > 遵循计划

Scrum角色 (3)

1. 【PO】产品负责人（Product Owner）：产品经理
• 确定产品的功能。
• 决定发布的日期和发布内容。
• 为产品的 ROI(Return On Investment)负责。
• 根据市场价值确定功能优先级。
• 每个 Sprint，根据需要调整功能和优先级（每个 Sprint 开始前调整）。
• 接受或拒绝接受开发团队的工作成果。

2. 【SM】Scrum负责人（Scrum Master）：连接项目负责人与团队领导
• 保证团队资源完全可被利用并且全部是高产出的。
• 保证各个角色及职责的良好协作。
• 解决团队开发中的障碍。
• 作为团队和外部的接口，屏蔽外界对团队成员的干扰。
• 保证开发过程按计划进行，组织 Daily Scrum(每天都开会), Sprint Review（例如每周开一次来看看做得怎么样） and Sprint Planning meetings（开个会来调整计划之类的）。

3. 团队（Team）：跨职能、自组织、整体
• 一般情况人数在 5-9 个左右
• 团队要跨职能 （包括开发人员、测试人员、用户界面设计师等）
• 团队成员需要全职。（有些情况例外，比如数据库管理员） （不能说谁只干开发这种）
• 在项目向导范围内，尽一切努力做任何事情已确保达到 Sprint 的目标。
• 高度的自组织能力。 （self-organizing，项目的协调，工作内部的调整）
• 向 Product Owner 演示产品功能。
• 团队成员构成在 sprint 内不允许变化。 （在一次迭代内人员不做调整）
• 团队整体向产品开发负责。

燃尽图 Burn Down Chart

• 直观的反映了 Sprint 过程中，剩余的工作量情况

• 随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量呈上升态势

Sprint 过程 (4)

1. Sprint 计划会议

2. Scrum每日站会

3. Sprint评审会议

4. Sprint回顾会议

▲ DevOps的工作流程 (4+4)

1. 持续开发 development
软件交付物被分解并在多个迭代中开发，将增量交付给质量保证团队进行测试。

2. 持续测试 testing

3. 持续集成 integration

4. 持续部署 deployment

5. 持续监控 monitoring

Ch7 软件工程实践原则

7.1 软件工程知识

7.2 核心原则

软件工程的核心原则的表现 Core Principal (2)

1. 流程级别（process level）
在执行framework activity和umbrella activity时，导航流process flow（process model包含了process flow），并产生一组软件工程work product

2. 实践级别（practice level）
建立了一个值和规则的集合（collection of values and rules），即在分析问题，设计解决方案，实施解决方案并测试解决方案时，该规则是指南，并最终部署软件

▲ 定义一个软件过程的原则 (8)

1. Be Agile

2. Focus on quality at every step

3. Be ready to adapt 做好适配的准备必考
选择process model后可以不断调整以适应项目（如裁减等）

4. Build an effective team

5. Establish mechanisms for communication and coordination

6. Manage change

7. Assess risk 风险评估（如人员跳槽）

8. Create work products that provide value for others

▲ 引导实践的原则 (8)

1. Divide and conquer 分而治之

2. Understand the use of abstraction 理解和进行分析抽象
• requirement用use-case抽象表达
• 把数据库设计按entity，加上属性找relation，画出E-R图进行抽象
• 最后进行代码的抽象

3. Strive for Consistency 前后一致（后一个以前一个为依据）

4. Focus on the Transfer of infomation 注意信息的转换（接口）

5. Build software that exhibits effective modularity 构建具有有效模块化的软件（类就是模块化），即类的定义

6. Look for Pattern 寻找（已有）模式

7. When possible, represent the problem and its solution from a number of different perspectives 多角度看问题

8. Remember that someone will maintain the software 版本控制，保证人员调整后能接上工作

7.3 引导框架活动的原则

▲ 概要设计建模的构成 (3)

▲ 代码重构的方法 (7)

1. 重命名：类、接口、方法、属性

2. 抽取代码：一段代码抽取为另一个方法

3. 封装字段：字段成属性

4. 抽取接口：将类的属性、方法抽取组成接口，该类自动实现该接口

5. 方法内局部变量变成参数

6. 删除参数

7. 重排参数

▲ 部署包含的任务deployment (3)

1. delivery 交付

2. support 支持

3. feedback 反馈

Communication的原则 (10)

1. Listen 听

2. Prepare before communicate 交流时要准备好

3. someone should Facilitate the activity 要有一个负责人来协调推动

4. Face-to-Face communication is best 最好面对面交流

5. take Notes and document decision 交流记笔记

6. strive for Collaboration 在需求调研时通力协作(别吵架，情商要高)

7. Stay focused：Modularize your discussion；模块化你的决策(大家发生冲突时，把发生冲突的部分分解，模块化继续讨论，这点挺重要的)

8. If something is unclear, draw a picture 有不清楚的地方就画图 画图抽象

9. Once you agree to something, move on. (b) If you can’t agree to something, move on. (c) If a feature or function is unclear and cannot be clarifified at the moment, move on 某事一达成一致就过，达不成一致的也过，有不清晰现阶段无法弄明白的地方也过，继续并记录在案日后解决；

10. Negotiation is not a contest or a game. It works best when both parties win 沟通不是竞赛，追求双赢

Planning的原则 (10)

1. Understand the scope of the project 确定项目的范围和边界才能planning

2. Involve Stakeholders in the panning activity 要和甲方紧密交流，囊括进计划

3. Recognize that paning is Iterative planning是迭代的

4. Estimate based on what you know 基于已知的来进行估算工作量

5. consider Risk as you define the plan 计划时需要考虑风险
对于已经识别的风险，把风险管理作为一个任务在计划中体现；对于未识别的风险，留一定的缓冲buffer空间（风险+预备处理方案）

6. be Realistic 现实点，实事求是

7. Adjust Granularity as you define the plan 做计划时要定义计划的粒度，并调整粒度

8. define how you intend to ensure Quality 制定计划以保证质量（比如review)

9. describe how you intend to accommodate Change 描述如何适应变更

10. Track&Adjust the plan frequently 跟踪计划，并根据需要实时调整计划

Modelling的原则 (10+5+10)

• 敏捷开发模型总体原则：【粗略、少建模、简单、易于变更、目的性、调整、有用、易懂、直觉、反馈】
1. The primary goal of the software team is to build software, not create models 软件团队的主要目标是构建软件，而不是创建模型，模型不用太过细致，目的不是建模，建模是为了帮助开发
2. Travel light—don’t create more models than you need 要多少才建模多少，少建模型，开发过程轻量级
3. Strive to produce the simplest model that will describe the problem or the software 模型尽量简单
4. Build models in a way that makes them amenable to change 模型要易于在不同迭代过程中进行变更（变更时要做版本控制，是前面提到的）
5. Be able to state an explicit purpose for each model that is created 模型都要有清晰的目的
6. Adapt the models you develop to the system at hand 调整模型，适应待开发系统
7. Try to build useful models, but forget about building perfect models 建立实用的模型，建模就是为了开发用的，不必完美（强调敏捷，为下一阶段做准备）
8. Don’t become dogmatic about the syntax of the model. If it communicates content successfully, representation is secondary 构建模型的方法不必死板，不用全部按照规范，只要能辅助理解需求即可；如果它成功通信了，怎么表示是次要的。建模就是为了表达开发的一些关键元素，可以灵活使用
9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have reason to be concerned 直觉告诉你模型不太ok时，仔细检查
10. Get feedback as soon as you can 及时反馈（通过daily meeting等）

• 需求建模：【范围、功能、行为（状态、时序）、分层、细节】
1. The information domain of a problem must be represented and understood 首先要进行数据建模产生类图，分析类图建模：目的是构建一个初步的类图
2. The functions that the software performs must be defined 定义好软件功能。即：需要进行功能建模 就是activity model
3. The behavior of the software (as a consequence of external events) must be represented 行为建模
4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion 这些模型都要不断细化 尽可能细化分层
5. The analysis task should move from essential information toward implementation detail analyse的task应该从基本信息转向实施细节，为后面设计建模和代码服务，细化之后的模型都要为开发实现服务

• 设计建模：【对应、架构设计、数据设计、接口设计、UI、组件独立低耦合、易懂、迭代、不拖累】
1. Design should be traceable to the requirements model设计要遵循需求建模。设计应追溯到需求模型（和前面的内容前后一致，Strive for consistency)，也就是说，设计建模以分析建模作为依据 requirement model 主要是针对需求分析建模,把需求分析细化变成需求分析建模 所有的设计以需求规约为依据
2. Always consider the architecture of the system to be built 概要设计中的软件体系结构（看上面）设计十分重要 architechture 是指architechture design 包含软件体系结构设计、数据库设计、接口设计
3. Design of data is as important as design of processing functions数据设计：包括两个：数据结构设计和数据库设计（看上面）与功能设计一样重要
4. Interfaces (both internal and external) must be designed with care内部接口(类内的，类方法之间的都是内部接口)和外部接口设计
5. User interface design should be tuned to the needs of the end user. However, in every case, it should stress ease of use 用户界面设计，要求简易且面向用户需求（一般用prototype model)
6. Component-level design should be functionally independent 组件设计应该在功能上独立，功能的独立性,做到低耦合（调用的时候，传的参数尽量少）
7. Components should be loosely coupled to one another and to the external environment 组件之间，组件与外部环境之间松散耦合
8. Design representations (models) should be easily understandable 设计模型应该容易理解,设计的各种状态图、模型之类的得让人能看懂
前八个原则很重要
9. The design should be developed iteratively 设计应迭代进行,为写代码服务
10. Creation of a design model does not preclude an agile approach 设计模型不应该拖累排除敏捷方法

Construction的原则

• 写代码前：【理解问题、理解组件、语言、IDE、测试先行】
1. Understand of the problem you’re trying to solve 理解问题（详细设计）
2. Understand the component-level design 理解基本的设计原则和概念（看详细设计对不对）
3. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate 语言选择，满足要构建的软件的需求以及它将运行的环境
4. Select a programming environment that provides tools that will make your work easier. 环境选择（IDE等）
5. Create a set of unit tests that will be applied once the component you code is completed. 写代码前把测试用例写进去，测试先行（单元测试Unit Testing先创建）对于每一个类的方法，每个功能逻辑都写一个测试代码。测试先行！！

• 写代码时：【结构化编程、结对、数据结构、接口、条件逻辑、嵌套、注释、缩进】
1. Constrain your algorithms by following structured programming practice 结构化编程以写算法（结构化编程就是条件循环语句等（不要太多if嵌套））如果类中的方法涉及到算法，一定要考虑时间复杂度
2. Consider the use of pair programming 结对编程
3. Select data structures that will meet the needs of the design 选好数据结构，要满足设计需求
4. Understand the software architecture and create interfaces that are consistent with it 了解软件体系架构，创建与之一致的接口（也就是概要设计部分的文档内容）
5. Keep conditional logic as simple as possible 尽可能保证条件逻辑简单
6. Create nested loops in a way that makes them easily testable 嵌套循环不要太深，要保证嵌套循环的可测试性（尽量避免，但不可避免时要使得嵌套循环可以较简单地被测试）
7. Select meaningful variable names and follow other local coding standards 变量命名要规范有意义
8. Write code that is self-documenting 要有注释（不用太细）
9. Create a visual layout (e.g., indentation and blank lines) that aids understanding 代码布局要好，增强代码的可读性（比如缩进空行等）

• 写代码的第一个代码版本完成后：【走查、单元测试、重构】
1. Conduct a code walkthrough when appropriate 进行一次代码审查

walkthrough: 走查。只读评审(e.g. Review)的一种方法，如一行一行地review

就是umbrella activity里面的formal technical review

2. Perform unit tests and correct errors you’ve uncovered Perform unit tests and correct errors you’ve 单元测试，手机错误
3. Refactor the code 重构代码，代码写好之后规范化，标准化，更好的能被别人复用（比如开发了个教务系统，可以形成类库，这样下次开发可以直接用）

• testing原则：【满足要求、计划、帕累托原则、从小到大、无穷、故障密度、静态测试、跟踪缺陷、正常用例】
测试的要求：查找错误（intend→大概率找到未发现→找到未发现）
1. All tests should be traceable to customer requirements 所有测试都应追溯到客户要求Requirement
2. Tests should be planned long before testing begins 在测试开始之前，应长期计划测试。
3. The Pareto principle applies to software testing 帕累托原则适用于软件测试
4. Testing should begin “in the small” and progress toward testing “in the large 测试应该开始从“小”中并进展到测试“大” (输入不可能覆盖全部情况，从小开始)
5. Exhaustive testing is not possible 穷尽Exhaustive的测试是不可能的
6. Apply to each module in the system a testing effort commensurate with its expected fault density 应用于系统中的每个模块，测试工作与其预期的故障密度fault desity相称
7. Static testing techniques can yield high results 静态测试技术static testing techniques可以产生高结果
8. Track defects and look for patterns in defects uncovered by testing 跟踪缺陷并寻找通过测试未覆盖的缺陷模式。也就是说，这些缺陷是否满足一些pattern
9. Include test cases that demonstrate software is behaving correctly 也要考虑演示软件行为正确的测试用例

Deployment的原则 (5)

1. Customer expectations for the software must be managed 处理好客户的预期

2. A complete delivery package should be assembled and tested 一个完整的部署包delivery package必须被汇集并测试

3. A support regime must be established before the software is delivered 必须在软件交付之前建立支持制度support regime

4. Appropriate instructional materials must be provided to end users 必须向用户提供教学材料（文档）

5. Buggy software should be fixed first, delivered later 先修bug再deliver

7.4 工作实践 Work Practice

软件工程前序知识 (9)

1. Interface （内部接口，外部接口和用户接口(界面)）

2. Conventions and templates (编程规范，功能、数据、行为建模的规范等；文档的模板，UseCase图构建的模板)

3. Layering (分层，抽象化）例如整个项目分子系统是一层，一个子系统分几个微服务又是一层，一个微服务分几个类又是一层

4. Algorithmic complexity

5. Hashing

6. Caching

7. Concurrency 要考虑并发性

8. Cloud computing 都放在云端

9. Relational database 设计合理的数据库

Ch8 需求

8.1 需求工程 Requirement Engineering

▲ 需求工程的任务 (7)

1. inception 初始化——项目启动阶段可追踪新
• 明确stackholder、多重观点、协作、边界、非功能性需求、可追踪性

2. elicitation 诱导——需求调研
• 协作收集需求（objects、services、constraints、performance & nonfunctional）
• 开发一个初步的（preliminary）使用场景（scenario）：画use case diagram
• 得到elicitation work product 获取工作产品，得到规约草稿

3. elaboration 阐述——细化进行建模
• 把前两个阶段得到的信息进一步拓展和细化
• 建立分析模型

4. negotiation 谈判——需求谈判
• 明确stackholder、获利方式、调和

5. specification 规约——形成2个规约
• 需求规约——文字描述，use case
• 需求分析规约——文字描述，功能建模，数据建模，行为建模

6. validation 验证——对规约进行评审
• 把模糊的、省略的、错误的（ambiguous，omission，error）部分改正

7. management 管理——对需求进行版本控制和管理

SafeHome系统需求

▲ 非功能性需求 (5)

1. 观感需求（界面需求）

2. 易用性与可执行需求（容量、利用率）

3. 安全性需求

4. 系统完整性需求

5. 可扩展性与可维护性

Ch9 需求建模：基于场景的方法

9.1 需求分析 Requirement Analysis

需求建模的目的 (3)

1. 描述用户想要什么

2. 为设计提供基础（概要设计&组件设计）

3. 定义需求的集合

需求分析、系统描述、设计模型的关系 (2)

1. 需求分析模型是建立起系统描述与设计模型的桥梁

2. 设计建模是在分析建模的基础上进行细化（两者没有明确边界）

分析建模的经验规则 (6)

1. Abstraction&Visible
模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。“不要陷入细节”即不要试图解释系统将如何工作。

2. Element
需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。

3. Delay
关于基础结构和其他非功能的模型应推延到设计阶段再考虑。
以下这些内容就可以先不考虑：
• 更细节的基础物件（e.g：数据库设计，前端界面等）
• 非功能需求和性能的建模细化（e.g 架构，算法，数据库设计等影响性能的因素）

4. Min-Coupling 低耦合，最小化整个系统内的关联。
在构建UseCaseDiagram时，需要注意每个UseCase尽量高内聚，状态图中也有体现（大状态分为多个子状态（粒度小，内聚性高），只有高内聚后才有低耦合

5. Value
要构建对Stakeholder有价值的需求模型，确认需求模型为所有利益相关者都带来价值。

6. Simple
业务简单化，尽可能保持模型简洁。

▲ 领域的输入与输出Domain Analysis (5+4)

1. 技术文档

2. 存在的以前做过的项目

3. 用户调查

4. 专家意见

5. 当前和未来需求

1. 类的分类（对class再分类，大的类化小）

2. 重复使用的标准（定义一个分析类复用的标准，要画类图，方法的功能、形参、实参）

3. 功能模型（对每个类进行功能建模，要把每个类的功能描述清楚）

4. 领域语言（如UML）

▲ 需求模型的方法 (4)

9.3 基于use case的UML模型

▲ 用例图绘制Use Case Diagram

 

关联、泛化、包含（必要构成、拆分）、拓展（错误处理）

▲ 状态图绘制State Diagram

• 注意开始与结束

• 圆角矩形里面都是状态

▲ 泳道图绘制Swim Lane Diagram

• 一种actor一个泳道

• 中间部分可以是平台

Ch10 需求建模：基于类的方法

10.1 定义分析类

1. 检查在Chapter 9 中的需求模型中的一部分usage scenarios

2. 对用例进行语法分析grammatical parse(每个UseCase检查有实义的名词或名词词组等)

语法分析中类的种类 (7)

1. External Entity 外部实体——系统外
其他的系统，设备，人；比如传感器，扫码器，等等

2. Things in Info Domain 属于信息域内的东西——系统内
比如：报表reports，展示display（比如显示控件里面的值很可能来自于分析类里面的字段），信号灯

3. Occurrences or Events 上下文中出现的事件——事情
比如：机器人完成一系列活动（这些例子都怪怪的）

4. Roles 角色（因为Role Class加一些属性可能是系统中的关键信息——人
比如：经理，工程师等

5. Organizational Units 组织单元——组织、组织机构
以group或team为单位、系统

6. Places 建立问题背景和系统的整体功能的地方——环境
比如：考试安排，则教室是一个分析类

7. Structures 结构或用于定义一类对象或相关类的对象——结构
往往与聚合有关系，如汽车管理系统中的汽车，轮胎等（聚合关系）；用于定义一类对象或相关类的对象可能有control panel

▲ 最终确定潜在类的方法 (6)

1. Retained Info 持久信息
需要保留存在数据库中的信息——持久信息 这个类中有需要保留的信息

2. Needed Service 需要服务
潜在类中有很多方法服务——服务（方法） 这个类中需要定义方法

3. Multiple Attributes 多属性
潜在类应该有多个属性→低耦合——多属性 类中有两个以上的属性
只有一个属性的潜在类往往并入到其他类中

4. Common Attributes 通用属性
潜在类有通用属性（泛化，父子关系，基础关系）——通用属性

5. Common Operations 通用方法
潜在类有通用方法——通用方法

6. Essential Requirements 需求相关
潜在类(外部实体，必须的生成和消费信息）几乎总是在需求模型中被定义为类(?)——需求相关 这些外部实体往往是一个分析类比如：camera，sensor（例如传感器的编号、类型、保修期这些属性都要数据库保存） 但是支付宝这种外部实体不是，因为这种外部类并不需要我们的管理，比如支付时间这些东西都是支付宝自己维护的，我们不用管，只要调接口就可以了

10.2 细化属性

1. 进一步study用例，一些名词词组或一些含数值信息的名词词组没有成为类，可能是依附于某些类的属性

2. 没有在用例描述中出现的词，通过data dict进行分解

10.3 定义操作

操作的广泛类别

1. 操作——操作以某种方式操纵数据（例如，添加，删除，重新格式化，选择）数据操作

2. 计算——执行计算的操作

3. 状态——询问对象状态的操作

4. 监控——监视对象以发生控制事件的操作。

10.4 CRC建模

▲ class的分类 (3)

1. 业务实体类：

2. 边界类：用于创建接口的类，管理实体类对象与用户之间的交互

3. 控制类：用于管理（设计后期才用）
• 实体对象的创建更新
• 边界类的实例化
• 管理一组对象之间的复杂通信
• 验证对象或用户和应用程序之间传送的数据

类的Responsibility指导思想 (5)

1. Distributed
系统的功能应该被均匀的划分到不同的类的属性中去，每个类只获取并执行少量的系统功能任务信息，这样系统的内聚性（同时达到高内聚，什么类就做什么样的事情）得到加权

2. General
属性和方法需要具有一定的通用性

3. Encapsulation
info和与它相关的behavior应该在同一类中。这实现了名为封装(encapsulation)的面向对象原则

4. Localized
一个东西的信息不应该被distributed而应该放在一个类中。一个Class应承担store和operate特定类型的信息的责任，实现了单一的功能

5. Shared
责任应在合适的情况下在相关类中共享，不同的类之间可能会共享属性和方法，比如有组合和聚合关系的类，往往会共享方法和属性

10.5 关联和依赖Associations and Dependencies

UML 类图教程

的 UML类图是用于构建和可视化的面向对象的系统的图形表示法。统一建模语言 (UML) 中的类图是一种静态结构图，它通过显示系统的以下内容来描述系统的结构：类，他们的属性，操作（或方法），以及对象之间的关系。…

https://zhuanlan.zhihu.com/p/456759825

▲ 聚合和组成的区别 aggregation composition

• 聚合表示一种“整体和部分”的关系，但部分可以独立于整体存在。它是一种较为松散的关系。例如，一所大学和它的部门，即使大学关闭了，这些部门依然可以存在。

• 组合也表示“整体和部分”的关系，但在这种关系中，部分不能独立于整体存在。它是一种更为严格或强烈的关系。例如，房子和房间的关系，房间不能脱离房子单独存在。

Ch11 需求建模：行为、模式和应用

• 行为建模：状态图、时序图

• 目的：构建对象动态的生命周期，经过各个状态的转换可以导出类的方法

▲ 状态图绘制

• 可以导出方法（例如Comparing状态访问数据库、加密解密、明文比对等方法）

• 会有自反方法（例如Locked在锁定时间未到的时候还会回到Locked）

• 在类级别状态图中，每个状态对应的方法请尽量调用类内方法，降低耦合

▲ 时序图绘制

• 相关类实例化对象的生命线上，是状态图中的状态

• 跨生命线的箭头表示类间协作（需少）

• 上图是正常流，异常流还需要再画

11.5 Web和Mobile应用的需求建模

前端需求建模的输出要求 (5)

1. 内容模型 Content Model 就是前端的对象、控件建模，控件怎么选择。选择内容对象和内容对象的布局，比如文本图形图像视频等数据，



• 来源：通过用例提供的场景，结合需求进行结构化控件
• 方法：data tree（蓝色表示还有下一级，又称为object。无子结点的是item）

2. 交互模型 Interaction Model 控件选好了，我要怎么交互。通过交互完成功能

3. 功能模型 Functional Model 定于用于内容对象的操作

4. 导航模型 Navigation Model 完成特定功能的导航（完成应用程序的总体导航策略）

5. 配置模型 Configuration Model 配置图，比如前端、后端、网络等配置

Ch12 设计理念

▲ 设计环节结构分析

• 最后一层应当是Design Class Diagram Design（得到分析类图，作为数据库设计基础）

• 倒数第二层是Software Architectural Design（属于architectural design，即概要设计）

• 完成体系结构设计后可以涉及到技术栈了（例如controller类设计）

• 接口设计时参考时序图（涉及到类之间接口）和状态图（涉及类内接口）

• 组件设计参考状态图（定义了内部方法）、时序图（如何跟其他类协作）、类图

衡量设计质量的属性 (5)

1. Functionality：系统功能是否满足了需求

2. Usability：是否有设计感、导航一致性、使用说明或提示

3. Reliability：是否能平稳运行（MTTF）

4. Performance：性能是否达标（运行速度、响应时间、资源消耗、效率）
• 影响因素：类方法数据结构不合适、数据库设计索引太多、类接口参数太复杂、体系结构设计不好、硬件确实不行

5. Supportability：包括可扩展性、可移植性、可服务性

Ch13 概要设计

13.6 系统架构设计 Architectural Design

▲ ACD系统体系结构图的分析

• 上游系统superordinate（要调用我们这个系统的系统）

• 下游系统subordinate（目标系统要访问的系统）

• 目标系统

• Actors

• Peers(同级系统,与目标系统同一个等级，与本系统进行交换的，双方面通信)。

Ch14 详细设计

• 详细设计需要定义接口、对于每一个功能逻辑将其抽象出来

• 在面向对象定义中就是类，但是也包含这个类与别人和别人与他的协作方法的设计，不单单是自己的

14.3 详细设计的指南

详细设计的步骤 (7)

1. 功能齐全
Identify all design classes that correspond to the problem domain. 确定系统所需要的功能是不是被所有设计类cover了

2. 辅助业务完成的类定义完全（GUI/持久类/访问os类/控制类）
Identify all design classes that correspond to the infrastructure domain. 辅助业务类完成工作的类是不是都设计了，例如：控制类、boundary 类、访问数据库的类、访问操作系统的类

3. 细化具体的类（协作、接口、属性、功能）
Elaborate all design classes that are not acquired as reusable components 对类进行细化，先不考虑重构的问题（跟翻译的不一样）
1. Specify message details when classes or components collaborate 确定会怎么协作 ，定义细节
2. Identify appropriate interfaces for each component根据上面的细节定义接口
3. . Elaborate attributes and define data types and data structures required to implement them.看看属性是不是合理 例：学生信息中一开始没有籍贯（因为学生类自己用不到，但是另一个类要用，就要把这个属性加上去）这其实也是项目可扩展性的一种体现
4. Describe processing flow within each operation in detail画出整体流程，要么伪代码要么activity diagram

4. 定义访问数据库的持久化类
Describe persistent data sources (databases and files) and identify the classes required to manage them描述持久层的数据源（数据库或文件）并定义数据管理类(是在概要设计中进行的）——对概要设计中的数据进行review (持久的数据和相关的类）

5. 细化状态图和时序图
Develop and elaborate behavioral representations for a class or component.把状态图和时序图再细化一下，看看有没有遗漏的属性和方法（状态图是定义方法的依据，时序图是定义接口的依据）

6. 绘制架构图中的细节
Elaborate deployment diagrams to provide additional implementation detail.画部署图，提供额外的实现细节(基于架构图）

7. 重构以增加代码合理性、可读性、复用性
Refactor every component-level design representation and always consider alternativity！！！考试会考refactor，对每一个类的代码进行重构，增加代码的可读性