如何开发/管理一个项目

如何管理一个项目，这是个沉重的话题。实际上，目前很多人都是凭借经验进行项目管理和开发，事实上管理项目是有着大量的方法论，这些方法论整理起来被人归纳成了一个学科，名字叫做软件工程，接下来的内容将会归纳总结里面的一些要点，如果你有意成为一个项目管理者，请必须了解一下这些基础知识。

软件系统模型

开始一个项目之前，你需要做好准备，那就是建立系统模型，有了抽象的模型，才会有具像的实现。

• 在软件开发中，软件系统模型大体可分为两类：概念模型和软件模型。
• 概念模型是创建在需求层上的，它描述了系统是什么。
• 软件模型是建立在抽象层上的，它描述了实现概念模型的软件解决方案。
• 软件模型可进一步分为设计模型、实现模型和部署模型。

需求

特征

一个完整的需求需要有以下特征：

1. 必要的：该需求是用户所要求的（产品经常会提一些伪需求，比如说在帖子列表添加个一键评价，点击了就回复666，但实际上没有用户想毫无感情地666，所以这是伪需求，不满足该条件的请拒绝）；
2. 无歧义的：该需求只能用一种方式解释（这个就不用解释了，遇到有歧义的需求请问清楚）；
3. 可测的：该需求可以进行测试；
4. 可跟踪的：该需求可以从一个开发阶段跟踪到另一个开发阶段（意思就是这个需求不会因为开发的进行变得模糊、不清晰）；
5. 可测量的：该需求是可测量的（意思就是实现这个需求不能无限耗费人力物力，说好这个需求两个人一天能做完，就两个人一天真的能做完）。

类别

1. 功能需求：系统或系统构件必须执行的功能
2. 非功能需求：分为性能需求、外部接口需求、设计约束需求、质量属性需求。

怎么发现需求

名称	情况	成功条件	风险
自悟	自己想	要比你的最终客户拥有更多的一样弄领域和过程方面的知识和丰富的想象力，也就是你要比你的用户更加清楚用户要啥	无法验证你想出来的东西是不是你的用户想要的
交谈	跟你的客户聊	你能提出正确的问题，回答人能揭示需求本质的能力	可能会获得一堆需求，而且越来越多，不断增长，可能还会推翻你之前的需求，可能导致超出项目成本和进度的限制（甚至可能被你的开发揍一顿）
观察	你去看你的用户怎么用你的软件	你需要有洞察事物本质的能力	1. 你的用户会抵触你的观察（很明显侵犯隐私了）2. 用户会觉得你是不是这软件没做好或者哪里需求不到位所以老是来看我，对你的软件产生怀疑
小组会	项目组的人全部叫出来开会讨论需求	你小组的人有不同观点，并且有良好的发现需求的能力，能揭示需求中存在的问题，最重要的是需求能跟用户达成共识	会议组织不到位就凉了，而且天天开会你的项目组的人也受不了，可能会提出矛盾需求
提炼	针对已有的部分需求文档，看线上反馈情况，进行提炼	你需要有想象力和需求标识能力，包括熟悉相关的技术标准	跟自悟一样，你不能知道你发现的需求是否是对的

需求规约

需求规约就是怎么写一个需求表，因为形式很多，所以最好就根据实际情况进行，这里不做规定，但是必须包含以下几个特征

1. 重要性和稳定性：需求要根据重要程度和稳定程度分优先级，例如：基本需求、可选需求和期望需求。
2. 可修改的：在不过多地影响其他需求的情况下，可以容易地修改一个单一需求。
3. 完整的：没有被遗漏的需求。
4. 一致的：不存在互斥的需求。

为什么需求规约很重要？（概念性东西）

1. 是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
2. 对于项目的其余大多数工作，需求规约是一个管理控制点。
3. 对于产品/系统的设计，需求规约是一个正式的、受控的起点。

结构化方法

结构化需求分析

1. 为什么要这么做？

   为了应对三大挑战：

    - 问题空间理解。（假如让你开发一个八字排盘App，但是你又不懂八字，所以要开发出一个高质量、满足用户要求的App，就不容易了）
    - 人与人之间的通信。（开发过程长、活动多、任务重，项目组成员多，直接面对面沟通起来难免有遗漏、误解等，所以这也是一个挑战）
    - 需求的变化性。（需求是不断变化的，所以这是软件开发人员面临的挑战）
   

   一种好的需求技术应该具有以下基本特征：

    1. 提供方便通信的机子，例如，在不同开发阶段，使用对相关人员易于理解的语言。
    2. 鼓励需求分析人员使用问题空间的术语思考问题，编写文档。
    3. 提供定义系统边界的方法。
    4. 提供支持抽象的基本机制，例如，"划分"，"功能抽象"，"结构抽象"等。
    5. 为需求分析人员提供多种可供选择的方案。
    6. 提供特定的技术，适应需求的变化等。
   

2. 几种基本术语的解释

   (1) 数据流：数据流是数据的流动，用于表达在分析中所要使用的、用于表达”客体”的信息，用箭头表示。
   大概长这样：

   (2) 加工：加工是数据变换的单元，即它接受输入的数据，对其进行处理，并产生输出。 大概长这样 (3) 数据存储：数据存储是数据的静态结构。 大概长这样(可以是横的或者竖的) (4) 数据源和数据潭: 数据源是数据流的起点，数据潭是数据流的归宿地。数据源和数据潭是系统之外的实体，可以是人、物或其他软件系统。 大概长这样

3. 数据流图

   把上面的元素组成起来就是数据流图了
   大概长这样

   

   几个要点：1）数据流起到连接其他实体的作用，实体可以是加工、数据存储、数据源和数据潭；2）加工之间可以有多个数据流，这些数据流之间可以没有任何关系，数据流图也不表明他们的先后次序；3）对于一个比较大的软件系统，往往需要采用多层次的数据流图。

4. 建模过程

   1. 建立系统环境图，确立系统语境
   2. 自顶向下，逐步求精，建立系统的层次数据流图
   3. 定义数据字典。数据字典有3种基本结构表示：顺序结构，选择结构，重复结构。
      • 顺序结构是指数据A由数据B和数据C顺序构成的，并记为”+”。例如：学生成绩=姓名+性别+学号+科目+成绩，其中”=”号表达的是”定义为”.
      • 选择结构是指由数据A是由数据B或数据C定义的，即数据B不可能同时是B和C，并记为“|”，例如：性别=男|女
      • 重复结构是指数据A是由多个重复出现的数据B构成的，并记为”| |”，例如：学生成绩表=|学生成绩|
   4. 描述加工：该步的目标为依据系统的数据流图，给出其中每一加工的小说明。加工可以有3种表达工具。
      1. 结构化自然语言（自然语言描述）
      2. 判定表: 由条件类别，条件组合，操作，操作执行构成。举例如图
      3. 判定树。举例如图

5. 注意事项：

   1. 模型平衡问题
   2. 信息复杂性控制问题

6. 需求验证
   验证需求规格说明书中的每一单一需求是否满足5个性质，即必要性、无歧义性、可测性、可跟踪性、可测量性；验证需求规格说明是否满足4个性质，即重要性和稳定程度、可修改性、完整性和一致性。在必要时还需要验证其他特性，如设计无关性。

结构化设计

总体设计步骤

结构化设计方法基于自顶向下，功能分解的基本原则，针对两种不同类型的数据流图，分别提出了变换设计和事务设计。其中，变换设计的目标是将变换型数据流图映射为模块结构图，而事务设计的目标是将事务型数据流图映射为模块结构图。

1. 变换型数据流图和事务性和数据流图
   （1）变换型数据流图：具有比较明显的输入部分和变换部分之间的界面、变换部分和输出部分之间界面的数据流图，称为变换型数据流图；
   
   （2）事务型数据流图：数据到达一个加工T，该加工T根据输入的值，在其后若干动作序列中选出一个来执行，这类数据流图成为事务型数据流图。
   

2. 总体设计分为3个阶段。第一阶段为初始设计，在对给定的数据流图进行复审和精化的基础上，将其转化为初始的模块结构图。第二阶段为精化设计，依据模块“高内聚低耦合”的原则精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。第三阶段为复审阶段，对前两个阶段所得到的高层软件结构进行复审，必要时还可能需要对该软件结构做一些精化工作，这对软件的一些性质，特别是对软件质量的提高，将产生非常大的影响。

3. 天天扯着嗓子喊高内聚低耦合，到底什么是内聚什么是耦合？

   • 耦合：耦合是指不同模块之间相互依赖程度的度量
     • 内容耦合：当一个模块直接修改或操作另一个模块的数据，或当一个模块直接修改或操作，另一个模块的数据或一个模块不通过正常入口转入到一个模块时，这样的耦合被称为内容耦合。内容耦合是最高程度的耦合，应该尽量避免使用。
     • 公共耦合：两个或两个以上的模块共同引用一个全局数据项，这种耦合被称为公共耦合。在具有大量公共耦合的结构中，确定究竟是哪个模块给全局变量赋了一个特定的值是十分困难的。
     • 控制耦合：一个模块通过接口向另一个模块传递一个控制信号，接收信号的模块根据信号值进行适当的动作，这种耦合被成为控制耦合。
     • 标记耦合：若一个模块A通过接口向两个模块B和C传递一个公共参数，那么称模块B和C之间存在一个标记耦合。
     • 数据耦合：模块之间通过参数来传递数据，则称为数据耦合。数据耦合是最低的一种耦合形式。
   • 内聚：内聚是指一个模块内部各成分之间相互关联程度的度量
     • 偶然内聚：如果一个模块的各成分之间基本不存在任何关系，则称为偶然内聚
     • 逻辑内聚：几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。
     • 时间内聚：如果一个模块完成的功能必须在同一时间内执行（例如，初始化系统或一组变量），但这些功能只是因为时间因素关联在一起，则称为时间内聚。
     • 过程内聚：如果一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行，则称为过程内聚。
     • 通信内聚：如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚
     • 顺序内聚：如果一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚
     • 功能内聚：最理想的内聚是功能内聚，模块所有的成分对于完成单一的功能都是基本的。功能内聚的模块对完成其功能而言是充分必要的。
   • 启发式规则：无论是变换设计还是事务设计，都涉一个共同的问题，即“基于高内聚低耦合的原理，采用一些经验性的启发式规则，对初始的模块结构图进行精化，形成最终的模块结构图”。
   • 怎么做？
     1. 改进软件结构，提高模块独立性。
     2. 力求模块规模适中。
     3. 力求深度、宽度、扇出和扇入适中。深度：表示其控制的层数(不包括自身)；宽度：同一层次上模块总数的最大值；扇出：一个模块直接控制（调用）的下级模块数目；扇入：一个模块有多少个上级模块直接调用它。
     4. 尽力使模块的作用域在其控制域之内。作用域：受该模块内一个判定所影响的所有模块的集合；控制域：模块本身以及所有直接或间接从属于它的模块的集合。

详细设计步骤

1. 结构化程序设计
   包含三种基本控制结构：顺序结构、选择结构、循环结构
2. 详细设计工具
   1. 程序流程图 缺点：不是一种逐步求精的工具，过早地考虑程序的流程，不去考虑程序的全局结构；所表达的控制流，往往不受任何约束可随意转移，从而会影响甚至破坏好的系统结构设计；不易表示数据结构。
   2. 盒图（N-S图）
   3. PAD图（Problem Analysis Diagram）
   N-S图和PAD图支持“自顶向下逐步求精”的设计。可节省人工编码工作，有利于提高软件的可靠性和软件生产率
   4. 类程序设计语言（伪码/PDL）
      是一种用正文形式表示数据结构和处理过程的设计工具，PDL是一种“混合”的语言。
3. 设计规约
   完成软件设计后，应产生设计规约，完整准确地描述满足系统需求规约所要求的的所有功能模块，以及伴随功能模块而出现的非功能机制。设计规约通常包括概要设计规约和详细设计规约。 概要设计规约指明高层软件体系结构，其主要功能如下： 1.系统环境等与设计有关的限定条件 2. 软件模块的结构（模块之间的接口及设计的数据流和主要数据结构）3. 模块描述（接口定义，模块处理逻辑，必要的注释等）4. 文件结构和全局数据文件的逻辑结构 5.测试需求 详细设计规约（包括各处理过程的算法和算法所涉及的全部数据结构的描述）主要作为软件设计人员与程序员之间交流的媒体。

UML

UML是一种图形化建模语言（Unified Modeling Language）

为了支持抽象分析和设计中的事物，UML给了八个基本术语，即类、接口、协作、用况、主动类、构件、制品、节点、

• 类： 类是一组拥有相同属性、操作、关系和语义的对象的描述。类主要用于抽象客观世界中的事物。
• 接口：每个操作描述了类、构件或子系统的一个服务，接口就是操作的一个集合。接口是对系统/产品的“接缝”予以模型化，表明了一个类、构件、子系统所需要得到的、且与实现无关的行为。
• 用况：用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果。
• 协作：协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交互内容
• 用况：用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的，可观察的结果。
• 主动类：主动类是一种至少具有一个进程或线程的类。
• 构件：构件是系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现。
• 制品：制品是系统中包含物理信息（比特）的、可替代的物理部件。
• 节点：节点是运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。

类在建模中的主要用途：

1. 模型化问题域中的概念
2. 建立系统的职责分布模型
3. 模型化建模中使用的基本类型

使用接口应注意的问题

1. 接口只可以被其他类目使用，而本身不能访问其他类目
2. 接口描述类的外部可见操作，通常是该类的一个特有限定行为。这些操作可以使用可见性、并发性、衍型、标记值和约束来修饰。
3. 接口不描述其中操作的实现，也没有属性和状态。据此可见，接口在形式上等价于一个没有属性、没有方法而只有抽象操作的抽象类
4. 接口之间没有关联、泛化、实现和依赖。但可以参与泛化、实现和依赖

表达关系的术语

关联：关联是一组具有相同结构、相同链的描述，是类目之间的一种结构关系。关联可以用一条连接两个类目的线段表示，并可对其命名，其结构可以具有方向性，用一个实心三角形来指示关联的方向。
    1. 关联名 。
    2. 导航：对于一个给定的类目，可以找到与之关联的另一个类目，这称为导航。
    3. 角色：角色是关联一端的类目对另一端的类目的一种呈现。
    4. 可见性：通过导航可以找到另一类目的实例，有时候需要限制访问。
    5. 多重性：类中对象参与一个关联的数目，成为该关联的多重性
    6. 限定符：限定符是一个关联的属性或属性表。
    7. 聚合：分类是增强客观实际问题语义的一种手段。聚合是对象之间（不是类之间）的一种结构关系。
    8. 组合：组合是聚合的一种特殊形式
泛化：泛化是一般性类目和它的较为特殊类目之间的一种关系。子类可以继承父类的属性和操作，同时也可以替换父类的声明。
    泛化的四种约束：完整、不完整、互斥、重叠
细化：细化是类目之间的语义关系，其中一个类目规约保证了另一个类目执行的契约。
依赖：依赖用于描述一个类目使用另一个类目的信息和服务，是一种使用关系。
    依赖的分类：绑定、导出、允许、示例、实例化、幂类型、精化、使用。
    
关联、泛化和细化都是一类特地类型的依赖。

使用这四种术语，可以模型化以下各种关系：
1. 结构关系（静态结构和动态结构）
    进行模型化时两种驱动方式：1.以数据驱动 2. 以行为驱动
2. 继承关系
3. 精化关系
4. 依赖关系

表达组合信息的术语————包

为了控制信息组织的复杂性，UML提供了组织信息的一种通用机制————包，支持形成一些可管理的部分。换言之，包可以作为“模块化”和“构件化”的一种机制。

包是模型元素的一个分组。一个包本身可以被嵌套在其他包中，并且可以含有子包和其他种类的模型元素。

通过在包的名字前加上一个可见性符号（+，-，#），来指示该包的可见性。

+ 表示对其他包而言都是可见的
# 表示对子孙包而言是可见的
- 表示对其他包而言都是不可见的

为了模型化包之间的关系，UML给出了两种依赖，即访问和引入。

• 访问：表明目标包中的内容可以被源包所引用，或被那些递归嵌套在源包中的其他包所引用。
• 引入：表明目标包中具有适当可见性的内容（名字）被加入到源包的公共命名空间中。

UML中用虚线加箭头的方式表示源包到目标包的依赖（访问和引入）。

UML术语的作用

1. 类用于抽象客观事物
2. 接口用于抽象事物之间的缝隙
3. 协作用于抽象协作性行为
4. 用况用于抽象功能
5. 主动类用于抽象并发行为
6. 构件用于抽象软件解中标识的成分
7. 制品用于抽象工作产品
8. 节点用于抽象计算单元
9. 关联用于抽象结构关系
10. 泛化用于抽象“一般/特殊”关系
11. 实现用于抽象精化关系
12. 依赖用于抽象使用关系

UML的模型表达式

1. 结构图和行为图
   结构图用于表达系统或系统成分的静态结构模型，给出系统或系统成分的一些说明性信息
   行为图用于表系统或系统成分的动态结构模型，给出系统或系统成分的一些行为信息
2. 类图、用况图、顺序图及状态图
   • 类图是可视化地表达系统静态结构功能模型的工具，使用类图所表达的系统静态结构模型，给出的是一些关于系统的说明性信息。
     
   • 用况图是一种表达系统功能模型的图形化工具，它包含六个模型元素，分别是主题、用况、参与者、关联、泛化、依赖
     
   • 顺序图由一组对象以及按时序组织的对象之间的关系组成，是一种交互图，包含对象之间传递的信息。控制操作包括选择执行操作、条件操作、并发迭代操作、迭代执行操作。
     
   • 状态图强调了从一个状态到另一个状态的控制流，是显示一个状态机的图。状态图由状态、事件和状态转移构成。使用状态图的作用有两个：一是创建一个系统的动态模型，二是创建一个场景的模型
     
3. 创建一个系统的类图的步骤
   • 模型化代建系统中的概念，形成类图中的基本元素
   • 模型化代建系统中的各种关系，形成该系统的初始类图
   • 模型化系统中的协作，给出该系统的最终类图
   • 模型化逻辑数据库模式
4. 信号事件、调用事件、时间事件和变化事件
   • 信号事件是一种异步事件，信号通常由状态机处理。如果没有定义对该事件的响应，那么事件均可能丢失。事件的丢失，就有可能引发接受者——状态机的一个错误的状态转移。
5. 状态转移所涉及的内容
   描述一个状态转换，一般涉及五个部分：
   1. 源状态：发生状态转移的那个状态
   2. 转移触发器：在源状态中由对象识别的事件，并且一旦满足其监护条件，则使状态发生转移。
   3. 监护条件：一个布尔表达式，当某个事件触发器接受一个事件时，如果该表达式有值为真，则触发一个转移；若有值为假，则不发生状态转移。
   4. 效应：一种可执行的行为
   5. 目标状态：转移完成后所处的状态
6. 最常用的控制操作子
   选择执行操作子：该操作子由两部分组成：一是监护条件，二是控制体
   条件执行操作子：控制体通过水平线将其分为一些部分，每一部分表示一个条件分支，每一分支有一个监护条件。
   并发执行操作子：该控制操作子的体通过水平线将其分为多个部分，每一部分表示一个并行计算。该控制操作子表明，当进入该控制操作子是，所有部分并发执行。
   迭代执行操作子：该控制操作子表明，只要在每一次迭代之前该监护条件为真，那么该控制体就反复执行，当该控制体上面的监护条件为假时，控制绕过该控制操作子。
7. 子状态机、简单状态和组合状态的概念
   子状态机：为了有效地组织状态、控制对象状态的复杂性，UML提供了组合状态，在一个状态机中引入了另一个状态机。被引入的状态机就称为子状态机。
   简单状态：子状态是被嵌套到另一状态中的状态。相对地，被引入的状态机就称为子状态机。
   组合状态：把含子状态的状态称为组合状态，组合状态可包含两种类型的子状态机，即非正交（顺序）子状态机和正交（并发）子状态机。

   RUP

RUP(Rational Unified Process)的特点

RUP的突出特点是，它是一种以用况（Use Case）为驱动的、以体系结构为中心的迭代、增量式开发。

1. 以用况为驱动
   以用况为驱动是指在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动。
2. 以体系结构为中心
   以体系结构为中心是指在系统的生存周期中，开发的任何阶段都要给出相关模型视角下有关体系结构的描述，作为构思、构造、管理和改善系统的主要标准。
3. 迭代、增量式开发
   迭代、增量式开发是指通过开发活动的迭代，不断地产生相应的增量。在RUP中，规定了四个开发阶段：初始阶段、精化阶段、构造阶段和移交阶段。

核心工作流

核心工作流：需求获取、分析、设计、实现和测试

需求获取

基本步骤	产生的制品
列出候选的特征	特征表
理解系统语境	领域模型或业务模型
捕获功能需求	用况模型
捕获非功能需求	补充需求或针对特殊需求的用况

业务用况模型和业务对象模型

1. 业务用况模型。业务用况模型是以用框图予以表达的
2. 业务对象模型。为了精化业务用况模型中的每一个业务用况，RUP引入了三个术语，用于表达参与业务的业务对象：工作人员、业务实体和工作单元。业务对象模型可通过交互图和活动图予以表达。

标识用况应注意的问题

1. 建立用况的结构中，应尽可能反映用况的实际情况。
2. 在用况的结构化中，不论是施加什么结构，新引入的用况都不应该太小或太大
3. 在建立用况的结构是，应尽量避免对用况模型中的用况功能进行分解。

需求分析

1. 分析类是类的一种衍型，分为边界类、实体类和控制类
2. 用况细化时一个协作，针对一个用况，其行为可用多个分析类之间的相互作用来细化，并记为用况细化。用况细化对用况模型中的一个特定的用况提供了一种直接跟踪的方式。
3. 分析包是一种控制信息组织复杂性的机制，提供了分析制品的一种组织手段。其主要特征为：体现问题的分离；高内聚、低耦合；尽可能体现一个系统的完整顶层设计，尽可能成为一些子系统或者成为一些子系统的组成部分。

具有良好结构的分析包的特征

1. 体现问题分离
2. 高内聚、低耦合。
3. 尽可能提现一个系统的完整顶层设计。

软件设计层上的术语

软件设计是满足需求规约所需要的软件结构。RUP为了满足系统/产品分析模型规约需求的软件结构，为设计层提供了是个术语：设计类、用况细化、设计子系统和接口，用于表达软件结构中的基本元素。

1. 设计类：一个设计类是对系统中实现一个类或类似构造的一个无缝抽象
2. 用况细化：用况细化是设计模型的一个协作，其中使用设计类及其对象，描述一个特定用况是如何予以细化的，是如何执行的
3. 设计子系统：设计子系统可以包含设计类、用况细化、接口，以及其他子系统，通过对其操作来显示其功能。
4. 接口：接口用于规约由设计类和设计子系统，必须提供与该接口操作对应的实现方法。

创建系统/产品用况模型的活动和任务

创建系统/产品用况模型的活动和任务如下

1. 活动一：发现并描述参与者
   任务1：发现参与者，即直接发现一些候选的参与者
   任务2：描述参与者，即对参与者进行命名并描述
2. 活动二：发现用况并对用况进行描述
   任务1：发现用况
   任务2：描述用况，即确定用况后对其进行描述
3. 活动三：确定用况的优先级，目的是在寻找参与者并对其进行描述和发现用况的并对用况进行描述的基础上确定哪些用况适合在早期的迭代中开发，哪些适合在后期的迭代中开发。
4. 活动四：精化用况。这一活动的目的是详细描述出每一用况的事件流，包括用况是怎样开始的，是怎样结束的，是怎样与参与者进行交互的，最终形成一系列精化的用况
5. 活动五：构造用户界面原型。这一活动的目的在于建造用户界面原型，使用户可以有效地执行用况。
6. 活动六：用况模型的结构化。需要进行以下工作。
   1. 抽取用况描述中的那些一般性的和共享的功能并使用泛化关系标识和描述那些共享功能
   2. 抽取用况描述附加的或可选的功能
   3. 标识用况之间的包含关系。通过用况模型的结构化，最终形成一个系统/产品的精化用户模型

创建系统/产品需求分析模型的活动和任务

1. 活动1：体系结构分析。该活动的目标是通过标识分析包和分析类，建立分析模型和体系结构“骨架”，并标识有关分析包和分析类的特定需求。
   任务1：标识分析包。该任务的基本输入是系统的用况模型
   任务2：处理分析包之间的共性
   任务3：标识服务包
   任务4：定义分析包的依赖，该任务的目标是发现相对独立的包，实现包的高内聚和低耦合
   任务5：标识重要的实体类，该任务的目标是标识在体系结构方面具有意义的实体类。
   任务6：标识分析包和重要实体类的公共特定需求，该任务的目标是依据需求获取阶段所标识的非功能需求，针对在分析期间所标识的包和分析类，标识它们的一些公共的特定要求。
2. 活动2：用况分析。该活动的目标是：一是标识那些在用况事件流执行中所需要的分析类和对象；二是将用况的行为分布到参与交互的各个分析对象；三是捕获用况细化上的特定需求。
   任务1：标识分析类，该任务的目标是标识在细化一个用况中所需要实体类、控制类和边界类，给出它们的名字、责任、属性和关系。
   任务2：描述分析类对象之间的交互。首先确定细化该用况所必要的交互，其次分派该用况的功能，最后根据其责任，发现该交互图中的各个链。
3. 活动3：类的分析。该活动的目标：一是标识并维护分析类的属性和关系；二是捕获分析类细化中的特殊需求。
   任务1：标识责任，通过组合一个类在不同用况细化中所扮演的角色来完成。
   任务2：标识属性
   任务3：标识关联和聚合
4. 活动4：包的分析。该活的目标是：一是确保分析包尽可能与其他包相对独立；而是确保分析包实现了它的目标；三是描述依赖，以益于可以估计未来的变化。

创建系统/产品设计模型的活动和任务

创建系统/产品设计模型的活动和任务如下：

1. 活动1：体系结构设计，该活动的目标是创建设计模型和部署模型，以及它们视角下的体系结构描述
   任务1：标识节点和它们的网络配置，网络配置通常使用一种三元模式：客户端、数据库功能、业务/应用逻辑
   任务2：标识子系统和它们的接口，目的是为了寻求一些复用的可能，而后随着设计模型的开发，在形成子系统结构中不断发现并烟花。
   任务3：标识在体系结构方面有意义的设计类和它们的接口。标识在体系结构方面有意义的设计类的基本思想是：初始可以依据在体系结构方面有意义的分析类来标识一些体系结构上具有重要意义的设计类。标识在系统体系结构方面有意义的设计类时，应注意主动类往往是一类在体系结构方面具有重要意义的类。
2. 活动2：用况的设计。其中分析模型用况细化分析是活动的输入、对应输出用况细化设计。
   为了实现用况设计的输入/输出，一般采用两种方法：
   1. 标识参与用况细化的设计类，首先基于分析模型研究相应用况细化分析中的分析类，来标识为细化这些分类所需要的设计类，然后基于用况的功能对每一个标识的设计类赋予相应的责任，最后为该细化创建一个类图，汇聚参与该用况细化的设计类，并给出类之间的关系。
   2. 标识参与用况细化的子系统和接口。
3. 活动3：类的设计。该活动的目标是完成用况细化设计中每一个类的角色设计，并完成有关每一类的非功能需求的设计。
   任务1：概括描述设计类，该任务的输入为分析类/接口。
   任务2：标识的操作，一般应依据分析类来标识设计类所提供的、所需要的操作，其中需要使用程序设计语言的语法来描述说标识的操作。
   任务3：标识属性，该任务的目标是标识设计类所需要的属性，并使用程序设计语言的语法给出属性的描述。
   任务4：标识关联和聚合。
   任务5：标识泛化，基于分析模型中分析类之间的泛化，可以发现设计模型中的很多泛化。
   任务6：描述方法，在设计期间一般用自然语言或适当的使用伪码对方法进行规约，但是在实现期间直接使用程序设计语言对方法进行规约。
   任务7：描述状态，有些设计对象是受状态控制的，即它们的状态确定了它们接受一个消息的行为。在这种情况下，使用一个状态图描述一个对象的不同状态转移是有意义的。
4. 活动4：子系统的设计。该活动的目标是：确保子系统尽可能独立于其他子系统或它们的接口；确保子系统提供正确的接口；确保子系统实现了它的目标，即给出了该子系统提供的那些接口所定义的操作的细化。

设计模型包含的元素

RUP设计的主要结果是设计模型，它尽量保持该系统具有分析模型的结构，并作为系统实现的输入，包含以下四个元素：

1. 设计子系统和服务子系统，以及它们的接口、依赖和内容。
2. 设计类以及它们具有的操作、属性、关系及其实现的需求。
3. 用况细化设计。
4. 设计模型视角下的体系结构描述。

用况模型与分析模型的比较

用况模型	分析模型
使用客户语言来描述	使用开发者语言来描述
给出的是系统对外的视图	给出的是系统对内的视图
使用用况予以结构化，但给出的是外部视角下的系统结构	使用衍型类予以结构化，当给出的是内部视角下的系统结构
可以作为客户与开发者之间关于“系统应该做什么，不应该做什么”的契约	可以作为开发者理解系统如何勾画、如何设计和如何实现的基础
在需求之间可能存在一些冗余、不一致和冲突等问题	在需求之间不应存在冗余、不一致和冲突问题
捕获的是系统的功能，包括在体系结构方面有意义的功能	给出的是细化的系统功能，包括在体系结构方面具有意义的功能
定义了一些进一步需要在分析模型中予以分析的	定义了用况模型中每一个用况的细化

RUP实现活动

目标：基于设计类和子系统生成构件；对构件进行单元测试，进行集成和连接；把可执行的构件映射到部署模型。

输入	活动	执行者	输出
设计模型、部署模型、体系结构描述【设计模型、部署模型角度】	实现体系结构	体系结构设计者	构件【概述】、体系结构描述【实现模型、部署模型角度】
补充需求、用况模型、设计模型、实现模型【当前建造】	集成系统	系统集成者	集成建造计划、实现模型【连续的建造】
集成建造计划、体系结构描述【实现模型角度】、设计子系统【已设计】、接口【已设计】	实现子接口	构件工程师	实现子系统【建造完成】、接口【建造完成】
设计类【已设计】、接口【由设计类提供】	实现类	构件工程师	构件【完成】
构件【完成】、接口	完成单元测试	构件工程师	构件【已完成单元测试】

RUP测试活动

RUP的测试包括内部测试、中间测试和最终测试

输入	活动	输出
补充需求、用况模型、分析模型、设计模型、实现模型、体系结构的描述	计划测试	测试计划
补充需求、用况模型、分析模型、设计模型、实现模型、体系结构描述、测试计划	设计测试	测试用况 测试过程
测试用况、测试过程、实现模型	实现测试	测试构件
测试用况、测试过程、测试构件、实现模型	执行集成测试	缺陷
测试用况、测试过程、测试构件、实现模型	执行系统测试	缺陷
测试用况、测试模型、缺陷	评价测试	测试评价

软件测试

软件测试目标与软件测试过程模型

软件测试及目标

软件测试的定义为：按照特定规程发现软件错误的过程。其目的是检验它是否满足规定的需求，或清楚了解预期结构与实际结果之间的差异

软件测试与软件调试之间的区别

软件测试与软件调试相比，在目的、技术和方法等方面都存在很大区别，主要表现在以下几个方面。

1. 测试从一个侧面证明程序员的”失败”.调试是为了证明程序员的正确。
2. 测试以已知条件开始，使用预先定义的程序且有预知的结果，不可预见的仅是程序是否通过。调试一般是以不可知的内部条件开始，除统计性调试外，结果是不可预见的。
3. 测试是有计划的，并要进行测试设计。调试是不受时间约束的。
4. 测试是一个发现错误、改正错误、重新测试的过程。调试是一个推理过程。
5. 测试的执行是有规程的。调试的执行往往要求程序员进行必要推理。
6. 测试经常是由独立的测试组在不了解软件设计的条件下完成的。调试必须由了解详细设计的程序员完成。
7. 大多数测试的执行和设计可由工具支持。调试时，程序员能利用的主要工具是调试器。

测试过程模型

软件测试是一个有程序的过程，包括测试设计、测试执行以及测试结果比较。测试过程模型可分为三类：环境模型、被测对象模型和错误模型。

1. 环境模型：是对程序运行环境的抽象。程序运行环境又包括支持其运行的硬件、固件和软件，如计算机、终端设备、网卡、操作系统、编译系统、实用程序等。在软件测试过程中，建立环境模型的主要目的是，确定所发现的错误是否为环境造成的。
2. 被测对象模型：该模型是从测试的角度对程序的抽象。为了测试，必须简化程序，形成被测程序的抽象版本、即对象模型。
3. 错误模型：该模型是对程序中的错误及其分类的抽象。在软件测试中，往往需要定义“什么是错误”、“什么是一般性错误”、“什么是严重性错误”等，即要给出“错误模型”。

软件测试技术

1. 测试覆盖及其他们之间的基本关系
   软件测试技术大体上可分为两大类：一类是白盒测试技术，又称为结构测试技术，典型的是路径测试技术；另一种是黑盒测试技术，又称为功能测试技术，包括事务处理流程技术、状态测试技术、定义域测试技术等。白盒测试技术依据的是程序的逻辑结构，而黑盒测试技术依据的是软件行为的描述。

2. 路径测试技术的分类

   测试覆盖包括路径覆盖、分支覆盖、条件覆盖与条件组合覆盖。

   1. 路径覆盖：执行所以有可能穿过程序控制流程的路径。在路径测试中，该度量是最强的，一般是不可实现的。
   2. 语句覆盖：至少执行程序中所有语句一次
   3. 分支覆盖：至少将程序中的每一个分支执行一次
   4. 条件覆盖与条件组合覆盖：条件覆盖是指每个判定中所有的可能的条件的取值至少执行一次；条件组合覆盖是指设计足够的测试用例，使每个判定中所有可能的条件取值组合至少执行一次。

   这四种测试覆盖的测试覆盖率由弱到强的顺序是：语句覆盖 < 分支覆盖 < 条件组合覆盖 < 路径覆盖

3. 事务流测试步骤

   事务流测试步骤具体如下。
   第一步：获得事务流程图。
   第二步：浏览、复审。
   第三步：用例设计。
   第四步：测试执行。

4. 运用等价类划分技术进行测试的步骤

   具体测试步骤如下。
   第一步：建立等价类表
   第二步：为有效等价类设计测试用例
   第三步：为无效等价类至少设计一个测试用例

5. 边界值分析的使用原则

   边界值分析是一种常用的黑盒测试技术。使用边界值分析在设计测试用例时，可以遵循以下原则。

   1. 如果某个输入条件规定了输入值的范围，则应该选择正好等于边界值的数据，以及刚刚超过边界值的数据作为测试数据。
   2. 如果某个输入条件规定了值的个数，则可用最大个数、最小个数、比最大个数多1、比最小个数少1的数据作为测试数据
   3. 根据规格说明的每个输出条件，使用前面的原则1
   4. 根据规格说明的每个输出条件，使用前面的原则2
   5. 如果程序的规格说明中，输入域或输出域是有序集合，在实践中则经常选取集合的第一个元素、最后一个元素以及典型元素作为测试用例。
   6. 如果程序中使用了内部数据结构，则应该选择这个内部数据结构的边界上的值作为测试用例。
   7. 分析规格说明，找出其他可能的边界条件。

6. 使用因果图生成测试用例的步骤

   因果图技术是通过为判定表的每一列设计一个测试用例，从而实现测试用例的设计与选择的。该方法生成测试用例的基本步骤如下。

   1. 通过软件规格说明书的分析，找出一个模块的原因和结果，并给每个原因和结果赋予一个标识符
   2. 分析原因与结果之间以及原因之间对应的关系，并画出因果图。
   3. 在因果图上标识出一些特定的约束或限制条件。
   4. 把因果图转换成判定表。
   5. 把判定表的每一列拿出来作为依据，设计测试用例。

软件测试步骤

1. 单元测试
   单元测试主要检验软件设计的最小单元—模块。该测试以详细设计文档为指导，测试模块内的重要控制路径。一般来说，单元测试往往采用白盒测试技术。

2. 集成测试
   集成测试是软件组装的一个系统化技术，其目标是发现与接口有关的错误，将经过单元测的模块构成一个满足设计要求的软件结构。集成测试集中于模块组合的功能和软件结构检验。集成测试可“自顶向下”地进行，称为自顶向下的集成测试；也可以“自底向上”地进行测试，称为自底向上的集成测试

3. 有效性测试
   有效性测试的目标是发现软件实现的功能与需求规格说明书不一致的错误。因此有效性测试通常采用黑盒测试技术。

4. 系统测试
   系统测试验证将软件融于更大系统中时整个系统的有效性。

软件生存周期过程与管理

软件生存周期过程概述

1. 过程分类

   按过程主体把软件生存周期过程分为以下几个过程。

   1. 基本过程：是指那些与软件生产直接相关的活动集。该过程又可分为获取过程、供应过程、开发过程、运行过程和维护过程。
   2. 支持过程：是指有关各方按他们的目标所从事的一系列相关支持活动集。该过程又可分为文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程和问题解决过程。
   3. 组织过程：是指那些与软件生产组织有关的活动集。该过程又可分为设计过程、基础设施过程、培训过程和改进过程。

2. 系统语境的过程类
   系统语境的过程类包含四个过程组，分别是协议过程组、项目过程组、技术过程组和组织上项目使能过程组。

   1. 协议过程组包含两个过程：获取过程和供应过程。
   2. 项目过程组包含七个过程：项目规划过程、项目评价过程、决策管理过程、风险管理过程、配置管理过程、信息管理过程和测量过程。
   3. 技术过程组包含11个过程：利益攸关方需求定义过程、系统需求分析过程、系统体系结构设计过程、实现过程、系统集成过程、系统测试过程、软件安装过程、软件接受支持过程、软件运行过程、软件维护过程和软件销毁过程。
   4. 组织上使能过程组包含五个过程：生存周期模型管理过程、基础设施管理过程、项目包管理过程、人力资源管理过程和质量管理过程。

3. 组织上使能过程的作用。
   组织上使能的过程一般来说是组织层面上的工作，为项目的执行提供基本保障。该过程包含五个子过程。

   1. 生存周期模型管理过程：其任务为过程建立、过程评估、过程改进。
   2. 基础设施管理过程：其任务为过程实现、基础设施的建立、基础设施的维护。
   3. 项目包管理过程：项目初始化、项目包评估、项目结束处理。
   4. 人力资源管理过程：其任务为技能标识、技能开发、技能获取和供给、知识管理。
   5. 质量管理过程：其任务为质量管理、质量管理纠正措施。

过程描述

软件验证过程包括两个活动：过程实现和验证。其中验证活动有五个任务：需求验证、设计验证、代码验证，集成验证和文档验证。

一个过程可通过过程意图，期望的结果以及到达过程结果需要执行的活动和任务来描述。对于一个过程的完整技术上的描述，还应包括：达到过程意图和实现过程结果的方法或规程，以及过程和活动文档。

应用说明

1. 系统和软件的关系

   在《ISO/IEC系统与软件工程-软件生产周期过程12207-2008》标准中，把软件认为是整个系统的一个组成从部分，执行系统中所确定的功能主要包括三大功能：控制功能、耦合功能以及软件本身提供的功能。由于软件通常存在与一个系统的上下文中，因此软件产品或服务一般可被认为是系统的一个项或称为系统元素。

2. 剪裁过程及应用

   剪裁过程是使剪裁这一标准过程慢速以下特定情况或因素。

   1. 围绕一个组织，其中该组织在一个协议中使用了这一标准
   2. 影响一个项目，其中要求该项目满足一个引用该标准的协议
   3. 反映一个组织的需要，其中该组织要供给产品或服务

软件生存周期模型

1. 瀑布模型

   瀑布模型是将软件生存周期各个活动规定为按固定顺序链接的若干阶段的模型。这一模型规定了个开发阶段的活动：系统需求、软件需求、需求分析、设计、编码、测试和运行，并且自上而下具有相互衔接的固定顺序；还规定了每一个阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。

   瀑布模型的提出，对软件工程的主要贡献如下。

   1. 在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么进行规约。
   2. 在系统构造之前存在一个需求阶段，它鼓励规划系统结构。
   3. 在每一阶段结束时进行评审，从而允许获取方和用户的参与。
   4. 前一步可以作为下一步被认可的、文档化的基线，并允许基线和配置早期接受控制。

   瀑布模型的主要问题是：

   1. 要求客户能完整、正确和清晰地表达他们的需求；并要求开发人员一开始就要理解这一应用。
   2. 由于需求的不稳定性，使设计、编码和测试阶段都可能发生延期；并且当项目接近结束时，出现了大量的集成和测试工作。
   3. 在开始的阶段中，很难评估真正的进度状态；并且直到项目结束之前都不能演示系统的能力。
   4. 在一个项目的早期开发阶段，过分地强调了基线和里程碑处的文档；并可能需要花费更多的时间用于建立一些用处不大的文档。

2. 增量模型

   增量模型是一种非整体开发的模型。软件在该模型中逐渐开发出来，开发出一部分，向用户展示一部分，可让用户及早看到部分软件，及早发现问题。该模型具有较大的灵活性，适合软件需求不明确、设计方案有一定风险的软件项目。

3. 演化模型

   该模型主要针对事先不能完整定义需求的软件开发在用户提出待开发系统的核心需求的基础上，软件开发人员按照这一要求，首先开发一个核心系统并投入运行，以便用户能够有效地提出反馈，即精化系统、增强系统能力的需求；接着，软件开发人员根据用户反馈，实施开发的迭代过程；每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的，可管理的子集；如果在一次迭代中，有的需求不能满足用户的要求，可在下一次迭代中予以修正。

   主要特征：该模型显式地把需求获取扩展到需求阶段，既为了第二个构造增量，使用了第一个构造增量来精化需求。演化模型在一定程度上可以减少软件开发活动的盲目性。
   不足之处：在演化模型的使用中，即使很好地理解了需求或设计，也很容易弱化需求分析阶段的工作。

4. 螺旋模型

   螺旋模型将瀑布模型与增量模型结合起来，加入了两种模型均忽略了的风险分析，弥补了这两种模型的不足。因而它是一种风险驱动的模型。螺旋模型将开放过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。

   螺旋模型关注解决问题的基本步骤，即标识问题，标识一些可选方案，选择一个最佳方案，遵循动作步骤并实施后续工作。其一个突出特征是，在开发的迭代中实际上只有一个迭代过程真正开发了可交付的软件。螺旋模型与演化模型和增量模型相比，同样适用了瀑布模型作为一个嵌入的过程，但螺旋模型所关注的阶段以及它们的活动是不同的。如果项目的开发风险很大或客户不能确定系统需求，在更广泛的意义上来讲，还包括一个系统或系统类型的要求，这时螺旋模型就是一个很好的生存周期模型。

5. 喷泉模型

   喷泉模型体现了软件创建所固有的迭代和无间隙的特征。该模型主要用于支持面向对象技术的软件开发。由于对象概念的引入，使分析、设计、实现之间的表达没有明显间隙。

过程规划与管理

1. 创建一个软件项目生存周期过程的步骤

   1. 选择软件生存周期模型
   2. 细化所选择的生存周期模型
   3. 为每一个活动或任务标识合适的实例数目
   4. 确定活动的时序关系，并检查信息流
   5. 建立过程计划的文档

2. 软件评估中应考虑的影响因素

   1. 不管做怎么样的决策，都必须对所采取的的措施对生存周期过程所产生的影响进行评审，以便保证项目获得好的结果。在这一评估中，应考虑以下几方面的影响。
      1. 所要求的的“返工”
      2. 资源需求
      3. 实施时间
      4. 对项目和用户的益处
      5. 员工情绪

集成化能力成熟度模型（CMMI）

背景和原理

1. 过程改善

   历史过程改善，是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果

2. 过程域、专用目标和共用目标

   过程域是一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件
   专用目标是用于描述满足该过程域必须呈现的一些独有特征。经可以用于帮助确定一个过程域是否得以满足。
   共用目标用于描述产现制度化的该过程必须呈现的特征，仅用于确定一个过程域是否得以满足。

CMMI的模型部件

过程域类名	包括的过程域
项目管理类	项目规划 项目监控 定量项目管理 集成项目管理 风险管理 提供方协议管理
工程类	需求开发 需求管理 技术解决方案 产品集成 确认 验证
支持类	配置管理 过程和产品质量保证 测量与分析 原因分析与解决 决策分析与解决
过程管理类	组织过程定义 组织过程性能 组织过程培训 组织过程关注 组织创新与部署

CMMI的等级

1. 能力等级的组成

   能力等级是用来表征组织对一个过程域的改善，是不断改善一个给定过程域的一种手段。在CMMI中，针对每个过程域设定了6个能力等级，即0级：未完成级；1级：已执行级；2级：已管理级；3级：已定义级；4级：已定量管理级；5级：待续优化级。

2. 成熟度等级的组成

   在CMMI中，应用于一个组织过程改善的成熟度等级有5个。即1级：初始级；2级：已管理级；3级：已定义级；4级：已定量管理级；5级：持续优化级

3. 能力等级与成熟度等级之间的基本关系

   1. 能力等级与成熟度等级是互补的关系，两者都是一种过程改善路径，即表征组织对单一过程域的改进。
   2. 成熟度等级的路径可使组织针对单一过程域不断改善一组相关过程域，即表征组织对一组过程域的改进。
   3. 两种等级的2-5级使用了同样的名字

4. 达到各共用目标要实施的共同实践

   达到公用目标2、共用目标3、共用目标4和共用目标5所要实施的共同实践如下表所示

	所要实施的共用实践
共用目标2：把过程制度化为一个管理过程	GP2.1 建立组织策略 GP2.2 规划过程 GP2.3 提供资源 GP2.4 指派责任 GP2.5 培训人员 GP2.6 管理配置 GP2.7 标识相关利益方的参与 GP2.8 监控过程 GP2.9 客观地评估符合性 GP2.10 从高层管理的视觉评审状态
共用目标3：把过程制度化为一个已定义过程	GP3.1 建立一个已定义的过程 GP3.2 收信进信息 所要实施的共用实践
共用目标4：把过程制度化为一个已定量管理过程	GP4.1 为该过程建立定量目的 GP4.2 使子过程性能达到稳定
共用目标5：把过程制度化为一个持续优化过程	GP5.1 确保不断进行过程改善 GP5.2 收集问题的根本原因

完结