项目启动
项目和项目管理
目标
- 在限定时间内；
- 在一定的成本内；
- 在要求的质量水平上；
- 高效使用资源；
- 获得客户认可。
过程和活动
过程：项目启动、项目计划、项目执行、项目跟踪与控制和项目收尾
活动：计划制定、团队管理、成本控制、质量保障、度量、过程管理、进度跟踪与控制、⻛险管理、配置管理
软件质量保障
活动：就是各种评审
质量模型
功能性、可靠性、易用性、效率、可维护性、和可移植性
评审
- 在规划阶段（Planning），制定审查计划，决定审查会议的次数，安排每次审查会议的时间、地点、参与人员、审查内容等等。
- 在总体部署阶段（Overview），向所有参与审查会议的人员描述待审查材料的内容、审查的目标以及一些假设，并分发文档。
- 在准备阶段（Preparation），审查人员各自独立执行检查任务。在检查的过程当中，他们可能会被要求使用检查清单、场景等检查方法。检查中发现的问题会被记录下来，以准备开会讨论或者提交给收集人员。
- 在审查会议阶段（Inspection Meeting），通过会议讨论，识别、确认、分类发现的错误。
- 在返工阶段（Rework），修改发现的缺陷。
- 在跟踪阶段（Follow-up），要确认所有发现的问题都得到了解决，所有的错误都得到了修正。
质量度量
测度
是为了描述软件产品而提供的定量指标
- 代码行数
测量
进行测度的活动称为测量
度量
是软件产品 在特定属性上的量化测度程度
- 基于所有对象的代码行测度可以建立平均代码行数、最大代码行数、最小代码行数
软件配置管理
定义
用技术的和管理的指导和监督方法，来标识和说明配置项的功能和物理特征，控制对这些特征的变更，记录和报告变更处理及其实现状态，并验证与规格需求的一致性
配置项
置于软件配置管理之下的软件配置的各种有关项目，包括：
- 各类管理文档
- 评审记录与文档
- 软件文档
- 源码及其可执行码
- 运行所需的系统软件和支持软件
- 有关数据
- ……
基线：：已经经过正式评审的规格说明或产品，可以作为进一步开发的基础，并且只有通过正式的变更控制过程才
版本控制
示意图
模式
Lock-modify-unlock solution
Copy-modify-merge solution
变更控制的过程
需求基础
需求基础
需求的层次
- 业务需求
- 系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统
- 用户需求
- 执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么
- 例：系统应该允许客户经理添加、修改或者删除会员个人信息
- 系统需求
- 用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节
- 例：在接到客户经理的请求后，系统应改为客户经理提供所有会员的个人信息。
需求分类
需求图谱
项目需求
过程需求
系统需求
软件需求
- 功能需求
- 性能需求
- 速度
- 容量
- 吞吐量
- 负载
- 实时性
- 质量属性
- 可靠性：上传下载时，如果网络故障，系统不能出现故障
- 可用性：系统的可用性要达到98%
- 安全性：收银员只能查看，不能修改、删除VIP顾客的信息
- 可维护性：如果要加新功能，要能够在2人月内完成
- 可移植性：服务器要能在1人月内从win7更换到solaris 10操作系统
- 易用性：使用系统1个月的收银员进行销售处理的效率要达到10件商品/分钟
- 对外接口
- 约束
- 数据需求（非标准类型的软件需求类别，而是功能需求的补充）
软件体系结构基础
软件体系结构的发展
- 1969年第一次提到软件体系结构
理解软件体系结构
概念和定义
一个软件系统的体系结构规定了系统的计算部件和部件之间的交互
Wiki：Software architecture is the realization of non-functional requirements, while software design is the realization of functional requirements.
要素：
- 高层抽象
- 关注利益相关者
- 设计方案
区分物理与逻辑
- 逻辑更高层
- 逻辑-抽象，物理-实现
- 逻辑意味着更高的视角
高层抽象
好处：
- 直观，便于理解
- 验证正确性
- 关注度分离，降低复杂度
部件、连接件、配置
连接件是一个与部件平等的单位
部件与连接件是比类、模块等软件单位更高层次的抽象
部件
在系统架构中封装处理和数据的元素被称为软件组件
组件通常提供特定于应用程序的服务
原始部件：可以直接被实现为相应的软件实现机制
复合部件：由更细粒度的部件和连接件组成,复合部件通过局部配置将其内部的部件和连接件连接起来,构成一个整体
连接件
原是连接件：可以直接被实现为相应的软件实现机制
复合连接件：由更细粒度的部件和连接件组成,复合连接件通过局部配置将其内部的部件和连接件连接起来,构成一个整体
配置
体系结构风格初步
Main Program and Subroutine Style 主程序/子程序风格
部件：procedures , functions and module
连接件：calls between them
设计决策与约束
- 基于声明-使用(程序调用)关系建立连接件,以层次分解的方式建立系统部件, 共同组成层次结构。（构成方式）
- 每一个上层部件可以“使用”下层部件,但下层部件不能“使用”上层部件,即不允许逆方向调用（单向调用）
- 系统应该是单线程执行。主程序部件拥有最初的执行控制权,并在“使用”中将控制权转移给下层子程序（单线程）
- 子程序只能够通过上层转移来获得控制权,可以在执行中将控制权转交给下层的子子程序,并在自身执行完成之后必须将控制权还交给上层部件（控制单向传递）
实现
- 功能分解
- 集中控制
效果
优点：
- 流程清晰，易于理解
- 强控制性
缺点：
- 程序调用是一种强耦合的连接方式,非常依赖交互方的接口规格,这会使得系统难以修改和复用（强耦合，难修改、复用）
- 程序调用的连接方式限制了各部件之间的数据交互,可能会使得不同部件使用隐含的共享数据交流,产生不必要的公共耦合,进而破坏它的“正确性”控制能力。（有公共耦合，破坏“正确性”的控制力）
应用
主要用于能够将系统功能依层次分解为多个顺序执行步骤的系统。
一些使用结构化方法(自顶向下或自底向上)建立的软件系统也属于主程序/子程序⻛格。
Object-Oriented Style 面向对象风格
组件：object or module
连接件：function or invocations (methods).
设计决策及约束
- 依照对数据的使用情况,用信息内聚的标准,为系统建立对象部件。每个对象部件基于内部数据提供对外服务接口,并隐藏内部数据的表示。（构建方式）
- 基于方法调用(Method Invocation)机制建立连接件,将对象部件连接起来。（连接方式）
- 每个对象负责维护其自身数据的一致性与完整性,并以此为基础对外提供“正确”的服务
- 每个对象都是一个自治单位,不同对象之间是平级的,没有主次、从属、层次、分解等关系
实现
- 任务分解
- （委托式）分散式控制
效果
优点：
- 内部实现的可修改性
- 易开发、易理解、易复用的结构组织
缺点：
- 接口的耦合性
- 标识(Identity)的耦合性
- 副作用：面向对象式⻛格借鉴了面向对象的思想,也引入了面向对象的副作用,因此更难实现程序的“正确性”。例如,如果 A 和B 都使用对象 C,那么 B 对 C 的修改可能会对 A 产生未预期的影响。再例如对象的重入(Reentry)问题:如果 A 的方法f()调用了 B 的方法 p(),而 p()又调用了 A 的另一方法 q(),那么就可能使得 q()失败,因为在 q()开始执行时,A 正处于 f()留下的执行现场,这个现场可能是数据不一致的。
应用
适用于那些能够基于数据信息分解和组织的软件系统,这些系统:
- 主要问题是标识和保护相关的数据信息;
- 能够将数据信息和相关操作联系起来,进行封装
Layered Style 层次风格
Components: typically collections of procedures or objects.
Connectors: typically procedure calls or methods invocations under restricted visibility
设计决策与约束
- 从最底层到最高层,部件的抽象层次逐渐提升。每个下层为邻接上层提供服务, 每个上层将邻接下层作为基础设施使用。也就是说,在程序调用机制中上层调用下层。
- 两个层次之间的连接要遵守特定的交互协议,该交互协议应该是成熟、稳定和标准化的。也就是说,只要遵守交互协议,不同部件实例之间是可以互相替换的。
- 跨层次的连接是禁止的,不允许第 I 层直接调用 I+N(N>1)层的服务
- 逆向的连接是禁止的,不允许第 I 层调用第 J(J<I)层的服务
实现
- 关注点分离（每层逐次抽象）
- 层间接口使用固定协议（固定控制）
效果
优点：
- 设计机制清晰,易于理解。
- 支持并行开发。
- 更好的可复用性与内部可修改性。
缺点：
- 交互协议难以修改。
- 性能损失。
- 难以确定层次数量和粒度
应用
分层⻛格适用于具备下列特性的系统:
- 主要功能是能够在不同抽象层次上进行任务分解的复杂处理;
- 能够建立不同抽象层次之间的稳定交互协议;
- 没有很高的实时性能要求,能够容忍稍许的延迟;
Model-View-Controller Style
Changes in their states are propagated to the view subsystems
The model subsystems are designed such that they do not depend on any view or controller subsystems
设计决策和约束
效果
优点：
- 易开发性。视图和控制的可修改性
- 具有一定的可修改性优势
- 适宜于网络系统开发的特征
缺点：
- 复杂性：MVC 将用户任务分解成了表现、控制和模型三个部分,这增加了系统的复杂性,不利于理解任务实现
- 模型修改困难