软件工程复习（二）

第三章 软件过程结构

3.1 通用过程模型

通用过程框架定义了五种框架活动：

1. 沟通
2. 策划
3. 建模
4. 构建
5. 部署

过程流

在执行下一个活动前重复执行之前的一个或多个活动

采用循环的方式执行各个活动，每次循环都能产生更为完善的软件版本

将一个或者多个活动与其他活动并行执行

3.2 定义框架活动

3.3 明确任务集

任务集定义了为达到一个软件工程动作的目标所需要完成的工作。

例如，需求获取elicitation（通常称为“需求收集requirement gathering”）就是发生在沟通活动中一个重要的软件工程动作。

需求获取的目的是理解利益相关者对将构建的软件的需求

小型、相对简单的项目	大型、复杂软件项目

3.4 过程模式

过程模式：描述了软件工程工作中遇到的过程相关的问题、明确了问题环境并给出了针对该问题的一种或几种可证明的解决方案

Amler过程模式模板
模式名称： 应清楚地表达该模式在软件过程中的含义，比如，技术评审
驱动力（目的）： 模式使用环境及主要问题，以明确主要难点
类型： 步骤模式（定义框架活动）、任务模式（定义软件工程动作或任务）、阶段模式（定义框架活动序列）
启动条件： 模式应用前需满足的前提条件（输入）。需要明确：
（1）在此之前，整个开发组织或者开发团队内已有哪些活动
（2）已有哪些软件工程信息是项目信息
（3）过程的进入状态是什么
问题： 描述模式将要解决的具体问题
解决办法： 描述如何成功实现模式
结束条件： 描述模式成功执行之后的结果（输出）。模式结束时需要明确：
（1）必须完成哪些开发组织或是开发团队相关的活动
（2）过程的结束状态是什么
（3）产生了哪些软件工程信息或是项目信息
相关模式： 列举与该模式直接相关的其他过程模式
已知应用实例： 说明该模式可应用的具体实例。（什么场合使用）

例如

第四章 过程模型

4.1 惯用过程模型

目标：使软件开发更加有序
所有的软件过程模型都支持通用框架活动，但是每一个模型都对框架活动有不同的侧重
也称软件生存周期模型

瀑布模型

将软件生存周期的各项活动规定为依固定顺序连接（瀑布般）的若干阶段工作：即从用户需求规格说明开始，顺序地通过沟通、策划、建模、构建、部署过程，最终提供完整的软件和持续的技术支持
前提：需求必须是准确定义和相对稳定的
又称经典生命周期
特点：

• 各个阶段间具有顺序性和依赖性
• 推迟实现的观点：前面步骤完成后才考虑实现
• 质量保证的观点：每一阶段都需要有文档以及经过评审

问题：

• 瀑布模型需要明确的客户需求，但客户难以准确表达所有需求
• 得到可执行程序的时间太迟，滞后的缺陷导致陷入困境
• 可能导致一些阻塞，浪费过多等待时间
• 过于理想化，难以应对开发过程中的各种不确定因素

增量模型

前提：需求不明确或迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能

以迭代方式运行瀑布模型

优点：
- 能在较短时间内想用户提交 可完成部分工作 的产品
- 用户有较充裕的时间学习和适应新产品
- 易于保证核心功能正确
- 可以基于早期版本来获取需求
- 项目完全失败的风险小
- 可以为那些创新的功能开拓市场
- 规避了资源缺乏的风险

问题：

• 把用户需求转化为功能递增的不同版本可能比较难（很多时候各个功能联系紧密，难以完全分开）
• 难以确定所有版本共需的公用模块。（通常在进行设计时会考虑设计公用模式，但是每一个增量只考虑局部的设计，因此，全局的公用模块很难确定）

迭代式开发

演化模型是迭代的过程模型，每次迭代产生软件的一个更完整的版本
两种演化过程模型

原型模型

开始于沟通

前提
客户：提出了一些基本功能，但未详细定义输入、处理和输出需求
开发人员：可能对开发运行环境、算法效率、操作系统的兼容性和人机交互等情况不确定

螺旋模型

特点：
瀑布模型+原型+风向分析
迭代过程

螺旋上的第一圈可能表示“概念开发项目”
最后，可以用一圈螺旋表示“产品提高项目”
流程：
确定目标，选择方案，选定完成目标的策略
风险角度分析该策略
启动一个开发阶段
评价前一步的结果，计划下一轮的工作

4.2 专用过程模型

1.基于构件的开发
优点：能够使软件复用，减少项目开发费用，缩短开发周期
建模和构建活动开始于识别可选构件。这些构件有些设计成通用的软件模块，有些设计成面向对象的类或软件包。
步骤：
  1.对于该问题领域研究和评估可用的基于构件的产品
  2.考虑构件集成的问题
  3.设计软件架构以容纳这些构件
  4.将构件集成到架构中
  5.进行充分的测试以保证功能正常

2.形式化方法模型
主要活动是生成计算机软件形式化的数学规格说明，使得软件开发人员可以应用严格的数学符号来说明、开发、和验证系统

3.面向方面的软件开发
方面的需求定义那些对整个软件体系结构产生影响的横切关注点。
横切关注点：某个关注点涉及系统多个方面的功能、特性和信息。

4.3 统一过程

注重于客户沟通以及从用户的角度描述系统，强调软件体系结构的重要性
特点：用例驱动，以架构为核心，迭代并且增量
统一过程认识到与客户沟通以及从用户的角度描述系统并保持该描述的一致性的重要性

UML——统一建模语言
统一过程

1. 起始阶段
   包括客户沟通和策划活动
   定义软件的业务需求，提出系统大致的架构，制定开发计划
2. 细化阶段
   包括沟通和通用过程模型的建模活动
   扩展了体系结构
3. 构建阶段
   与通用软件过程中的构建活动相同。
   采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例
4. 转换阶段
   包括通用构件活动的后期阶段以及通用部署（交付和反馈）活动的第一部分
5. 生成阶段
   与通用过程的部署活动一致
   监控软件的持续使用，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求

4.4 产品和过程

产品（创造力、个性）和过程（按部就班，标准，流程）

在软件工程实践中，以下过程模型比较流行：
瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、形式化方法模型、敏捷过程模型、构件组装模型、并发开发模型等等

第五章 敏捷开发

惯用过程模型存在的主要缺陷

敏捷

• 敏捷宣言：
  • 个体与交互 胜过 过程与工具
  • 可用的软件 胜过 完备的文档
  • 客户协作 胜过 合同谈判
  • 响应变化 胜过 遵循计划
• 敏捷价值观：
  • 沟通 简单 反馈 勇气 尊重（谦逊）
• 什么是敏捷开发： 它是一种软件开发方法论，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进地开发软件

5.1 什么是敏捷

5.2 敏捷及变更成本

传统软件开发的变更：

• 变革的成本费用随着计划的进展成非线性增长（这种方法在软件开发团队收集需求时，即在项目的早期，相对容易适应变更）

敏捷的变更：

• 一个设计良好的敏捷过程“拉平”了变更成本曲线，使软件开发团队在没有超常规的时间和费用影响的情况下，在软件项目后期能够适应各种变化
• 敏捷过程包括增量交付。

5.3 什么是敏捷过程

基于敏捷原则进行的软件开发过程，视为敏捷过程

所谓“基于”，是指充分考虑，而不是全部包含

敏捷原则

敏捷过程的三大假设

1. 提前预测哪些需求是稳定的以及哪些需求会变更是非常困难的。同样，预测项目进行中客户优先级的变更也很困难。
2. 对很多软件来说，设计和构建是交错进行的。也就是两种活动应当顺序开展以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度
3. 分析、设计、构建和测试并不像我们所设想的那么容易预测（从制定计划的角度来看）

敏捷过程必须具有可适应性，但是原地踏步式的连续适应性变更收效甚微，因而敏捷软件过程必须增量地适应。
换言之，有自适应和增量提高的过程即是敏捷过程

敏捷团队成员及团队本身必须具备以下一些特点：

• 基本能力
• 共同目标
• 精诚合作
• 决策能力
• 模糊问题解决能力
• 相互信任和尊重
• 自组织（组织团队、组织过程、组织进度）

5.4 极限编程

极限编程Extreme Programming——使用的最为广泛的敏捷过程
三个特点：

• 是一些相互关联的准则和惯例的集合
• 追求变更曲线平坦化
• 适合于小团队、高风险的项目

极限编程过程
（1）策划
建立“故事”
评估“故事”
故事分组
形成基本承诺
对故事进行排序

故事：由客户谈论系统应该完成什么功能，然后用通俗的自然语言，使用自己的语汇，将其写在卡片上

（2）设计
严格遵循KIS（Keep It Simple）原则
鼓励使用CRC卡（类-责任-协作者）确定与当前软件增量相关的面向对象的类
建立可执行原型并评估
鼓励“重构”

KIS原则：即使用简单而不是复杂的表述。不鼓励额外功能性（因开发者假定以后会用到）设计。

（3）编码
先开发测试用例，然后再编码
结对编程（建议）
工作集成

（4）测试
单元测试应当使用一个可以自动实施的框架（因此易于执行并可重复），这种方法支持代码修改之后即时的回归测试策略
XP验收测试，也称客户测试（由客户主导）

工业极限编程（IXP）
XP的一种有机进化，合并了六个新实践

• 准备评估
• 项目社区
• 项目特许
• 测试驱动管理
• 回顾
• 持续学习

关于XP的争论
批评意见：

• 需求易变
• 矛盾的客户需求
• 需求的非正规表示
• 正规设计的缺乏

5.5 其他敏捷过程模型

• Scrum
  每一个框架活动中，发生于一个过程模式中的工作任务被称为一个冲刺（sprint）。冲刺中进行的工作（每一个框架活动中的冲刺的数目根据产品复杂度和规模大小而有所不同）适应于当前问题，由Scrum团队规定并常常作实时修改

Scrum例会（每天召开的短会）
三个问题：
1.上次例会后做了什么
2.遇到了什么困难
3.下次例会前计划做些什么

• 动态系统开发方法（DSDM）
  
  生命周期活动：

  • 可行性研究
  • 业务研究
  • 功能模型迭代
  • 设计和构建迭代
  • 实现

  应当注意：
  （1）增量不见得100%完成
  （2）增量置于操作环境以后可能需要改变

• 敏捷建模（AM）
  敏捷建模的原则：

  • 有目的的模型

  在构建模型之前，开发者心中应当有明确的目标（如与客户沟通信息有助于更好地理解软件的某些方面），一旦确定模型的目标，该用哪种类型的表达方式以及所需要的具体细节程度都是显而易见的

  • 使用多个模型

  描述软件可以使用多种不同的模型和表示法
  ，大多数项目只用到其中很小的部分就够了。AM建议从需要的角度看，每一种模型应当表达系统的不同侧面，并且应使用能够为那些预期的读者提供有价值的模型 。

  • 轻装上阵
  • 内容重于表达形式
  • 理解模型及工具
  • 适应本地需要

• 敏捷统一过程（AUP）
  
  每个AUP迭代执行以下活动：

  1. 建模
  2. 实现
  3. 测试
  4. 部署
  5. 配置及项目管理
  6. 环境管理

5.6 敏捷过程工具集

利用各种工具提升效率与产品质量

代表性工具
OnTime
Ideogramic UML
Together Tool Set

第六章 软件工程的人员方面

6.1 软件工程师的特质

七种特质：

• 责任感
• 对一些人的需求有敏锐的意识
• 坦诚
• 展现抗压能力
• 有高度的公平感
• 注重细节
• 务实

6.2 软件工程心理学

• 在个人层面，软件工程心理学注重待解决的问题、解决问题所需的技能及在模型外层建立的限制内解决问题的动机。
• 在团队和项目层面，团队能动性成为主要因素。在这一层面，成功是由团队结构和社会因素决定的。团队交流、合作和协调同团队成员的技能同等重要。
• 在外部层面，有组织的行为控制着公司的行为及其对商业环境的应对方式

6.3 软件团队

项目组成员形成团队，不仅是项目成功的保证，而且也能满足成员的需求

团队毒性
5个培育潜在含毒的环境

含毒环境	解决方法
狂乱的工作氛围	项目经理应该确保团队可以获取完成工作所需的所有信息；而且，主要目标一旦确定下来，除非绝对必要，否则不应该修改
重大挫折使得团队成员产生摩擦	给予软件团队尽可能多的决策权，增强团队信息
糟糕的软件过程（碎片式的或协调很差）	允许团队选择过程模型
成员角色模糊：导致责任不明，互相指责	团队应该建立责任机制，并规定一系列当团队成员未能完成任务时的纠正方法
反复地失败：导致丧失自行，士气低下	建立基于团队的信息反馈方法和解决问题的技术

6.4 团队结构

团队结构取决于组织的管理风格、团队里的人员数目与技能水平，以及问题的总体难易程度
规划软件工程团队结构应该考虑的7个项目因素

• 待解决问题的难度
• 开发程序的规模，以代码行或者功能点来度量
• 团队成员需要共同工作的时间（团队生存期）
• 能够对问题做模块化划分的程度
• 待开发系统的质量要求和可靠性要求
• 交付日期的严格程度
• 项目所需要的友好交流的程度

软件工程软对的四种组织模式

• 封闭模式（遵循传统的权力层级模式）
• 随机模式（松散地组织团队）
• 开放模式（既具有封闭式泛型的控制性，又包含随机式泛型的创新性的方式来组织团队）
• 同步模式（依赖问题的自然区分，不需要很多的交流就可以将成员组织起来共同解决问题）

最早的软件团队组织（封闭式模式）
主程序员团队
核心成员：

• 1个高级工程师（“主程序员”），负责计划、协调和评审团队的所有技术活动
• 技术人员（一般是2-5人），进行分析和开发活动
• 1个后备工程师，支持高级工程师的活动，并可以在项目进行过程中以最小的代价接替高级工程师的工作
  
  优点：
  • 实现了项目人员分工专业化
  • 降低了管理的复杂性，提高了工作效率
    缺点：
  • 现实社会中，缺乏同时具备高超管理才能和技术才能的“全才”

6.5 敏捷团队

小组沟通的有效性：

• 小组规模：随着规模的扩大，要保证所有的成员间的有效交流变得困难
• 小组结构：没有正规组织结构的组织（没有领导），沟通比较有效
• 小组构成：同类型的人易冲突
• 小组的物理工作环境：工作场所是推动或阻滞沟通的主要原因

挑选成员时考虑的因素：

• 应用领域方面的经验
• 编程语言与平台的经验
• 教育背景
• 沟通能力
• 适应性：主要反映学习能力
• 其它：工作态度、个性

开源项目：

• 团队主要由志愿者构成
• 沟通方式主要为电子邮件
• 成功关键：
  • 让志愿者对项目感兴趣：产品有用，对自己有提高
  • 核心成员应该是高手

6.6 社交媒体的影响

1. 博客
2. 微博
3. 论坛
4. 社交网站
5. 社区
6. 网址收藏夹网站

6.7 软件工程中云的应用

	Alpha Test	Beta Test
测试场所不同	Alpha测试是指把用户请到开发方的场所来测试	Beta测试是指在一个或多个用户的产所进行的测试
环境的不同	Alpha测试的环境受开发方控制	Beta测试环境不受开发方控制，开发商无法知道用户如何折磨软件
测试时间不同	Alpha测试时间比较集中，一般情况下比Beta测试先进行	Beta测试时间不集中

6.8 协作工具

例如Git，SVN

6.9 全球化团队

全球化软件开发（GSD）团队面临距离的挑战：

• 距离使交流复杂化
• 距离使得协调更困难
• 距离产生了由文化差异导致的障碍和复杂性
• 障碍和复杂性会减弱交流