软件工程导论简述

第1章 创建一个程序

1. 需求：鉴于每项需求都会有成本，客户可能会了解了相关费用后，决定不再需要它们。

2. 功能需要求：一个程序要做什么？

   • 输出格式：不同的平台可能输出格式有所差异。
   • 排序：考虑升降，按字母、数字，那个在前那个在后，字母是大写还是小写？
   • 特殊情况、边界和错误情况

3. 非功能需求：为了实现这个程序要做什么，需要哪些方式。

   • 性能、实时性：从时间角度考虑
   • 可修改：从维护方面考虑
   • 安全性：
   • 可用性：不可直接度量，通过最终用户在特定的可用性测试中报告的可用性进行限定。

4. 设计约束

   • 用户界面：如GUI
   • 典型和最大输入规模：为了选择更适合的算法。
   • 平台：那个平台的资源更有助于设计。（比如库）
   • 进度：最后期限取决于客户。

5. 设计决策：考虑编程语言和算法。

6. 测试：

   • 验收测试：客户测试
   • 验证测试：开发人员测试，程序正不正常。

7. 估算工作量:成本估算+进度计划

8. 实现：

   • 最重要的规则一致性：遵守编程语言的规范（大家都知道的，比如Java的命名）
   • 命名:一致性，易描述
   • 先保证能正常工作
   • 了解标准库：这是优秀的程序员花心思写的，能用的就不要造轮子，可以节约时间。
   • 检查代码：编译器和人一起检查，保证正确性。

第2章 构建一个系统

1. 构建一个系统的特征：关注系统的问题，系统有多个组件组成。随着需求的增多，伴随着组（部）件数量的增多，从而需要一个术语去衡量——规模和复杂度
2. 规模：组件的数量
3. 复杂度：广度和深度
   • 广度（组件的规模）
     • 主要的功能
     • 各功能区域内的功能点
     • 与其他外部的接口
     • 并发用户
     • 数据的类型和数据的结构
   • 深度(组件之间的交互)：涉及不同项之间的连接和关系
     • 连接：数据共享或控制转移
     • 关系：分层，顺序，循环，递归等
4. 开发和支持的技术考虑
   • 问题设计和分解：把复杂问题简化的方法
     • 分解
     • 分离
     • 模块化
     • 增量迭代：补
   • 技术和工具考虑：
     • 编程语言
     • 开发工具
     • 数据库
     • 网络
     • 中间件
     • 其他技术组件，比如代码版本控制
   • 过程和方法：
     • 软件开发过程：在生产软件过程中的一组任务，以及这些任务的输入和输出、顺序和流程、前置条件和后置条件。
5. 开发和支持的非技术考虑
   • 工作估量和进度计划
   • 任务和沟通：任务不同，人员分配不同+人力资源

第3章 工程化软件

3.1、软件失败的示例和特点：要想做出一个成功的项目就必须要避免失败，所以关注和研究失败软件项目的数量和软件产品中遇到的缺陷数量是软件工程学科的特色。

• 项目失败：同样的错误依旧重复出现——关注失败项目的必要性，基于失败项目的研究得出的一些经验：
  • 项目成功的4个原因：
    （1）用户的参与：
    （2）高级管理层的支持：
    （3）明确的需求声明：
    （4）恰当的规划：
  • 挑战性项目：已经完成且可运行的一些项目，但该项目超出预算、超出预计实践或缺少初始规约中的一些功能特征。
  • 挑战性项目失败的前3个原因
    （1）用户输出不足
    （2）需求和规约不完整
    （3）需求和规约变更
  • 挑战性项目最终被取消的3个原因：
    （1）需求不完整
    （2）用户参与不足
    （3）资源不足
    问题指向：可以发现基本离不开用户和用户需求
• 软件产品失效：项目失败的一部分，侧重类型的问题，如成本超支，或计划超时等。
  • 软件产品失效的来源以及分布——Jones的文献
    • 需求错误：12.5%
    • 设计错误：24.17%
    • 编码错误：38.33%——占大头
    • 文档错误：13.33%
    • 错误修正错误：11.57%
  • 问题指向——归于编码问题。
• 协调和其他关注点：不单单只是代码问题，还有其他问题。
  • 管理层的决心和领导力
  • 对业务和技术流程的周密规划
  • 对业务和技术流程的周密规划
  • 熟练和经验丰富的顾问
  • 对项目的持续关注和监督
  • 在需要时愿意进行修改和调整
• 将用户问题+编码问题+其他问题进一步提炼，形成完成高质量软件的3项基本管理策略是：
  • 重点关注软件开发环境
  • 规范的开发过程
  • 系统地度量成本、进度计划和绩效目标。

总结：通过对失败项目和成功项目分析，得出了问题主要在用户、编码和辅助其他一些问题上面，形成能够识别出成功软件组织的度量工具——3项基本的管理策略。
3.2、软件工程

• 什么是软件工程：程序员不了解用户需求，用户看不懂程序员写的用户手册。认识到软件行业也需要有自己的规范，软件工程的概念诞生。
• 软件工程的定义：由于其广度和短暂历史很难用一句话说清楚，看其过程。
  • Ian Sommerrville:其重点是高性价比地开发高质量软件系统。
  • Shari Pfleeger: 软件工程是用计算机工具来解决问题的
  • 权威定义:美国计算机学会（ACM）和IEEE计算机学会发布《软件工程本科学位计划课程指南》确定了该领域的范围，强调了3个不同来源的定义。
    • F.L.Bauer:建立并使用健全的工程原理（方法），以便经济地获得可靠得、可以在真实机器上运行的软件。
    • CMU/SEI-90-TR-003：软件工程是一种工程的形式，它应用计算机科学和数学原理，以获得成本效益好的软件问题解决方案。
    • IEEE标准610-1990：对开发、运行和维护软件所采用的系统的、规范的、可量化的方法。
• 软件工程与软件相关性:软件和生活息息相关，它带来很大的价值，但是软件被非法复制盗取，引入了软件知识产权问题。

3.3、软件工程职业和道德规范：工程技术专业有专业工程师，软件工程方面有工程师执照

• 软件工程道德准则：站在不危害社会的角度上面对软件工程师给出了7条原则+对高层的1条原则：
  • 1、符合公众利益。
  • 2、在1的基础上，按照客户和雇主最佳利益原则行事。
  • 3、产品和相关修改：符合最高专业标准。
  • 4、在专业判断中保持诚信和独立性。
  • 5、提高符合公共利益的专业诚信度和声誉。
  • 6、同事之间平等地对待和支持。
  • 7、终生学习，提高职业道德水平。
  • 8、高层（软件工程经理和领导人）认可并体长管理软件开发和维护的职业道德。
• 职业行为
  • IMB企业早期的价值观
    • 尊重他人，争取公平
    • 尽其所能去执行
    • 遵守法律
  • 这些简单的指导也适用更为具体的情况
    • 处理信息的隐私问题。
    • 处理质量问题和问题解决方案
    • 处理项目估算和项目协调
    • 处理复用和知识产权问题
    • 处理按群问题。

3.4、软件工程的原则

• 早期的Davis的30项原则：这里只介绍最重要的其中15项。
  • 前2项：软件产品的质量属性（与之同级的其他软件产品属性可维护性、易安装性、可用性、可重复性、互操作性、可修改性）：
    • 1、质量放在首位
    • 2、高质量的软件是可能的
  • 后13项：致力于解决软件开发和支持的管理和技术：
    • 3、尽早向客户提供产品
    • 4、在编写需求之前确定问题：
    • 5、评估可选设计方案
    • 6、使用适当的过程模型
    • 7、在不同阶段使用不用的语言
    • 8、最小化智力差距：对真实问题与计算机解决方案
    • 9、将技术置于工具之前
    • 10、在使之更快之前，请确保其正确性
    • 11、检查代码
    • 12、好的管理比好的技术更重要
    • 13、人是成功的关键
    • 14、勿盲目跟风
    • 15、承担责任
• 更现代的Royce十大原则：
  • 这十大原则是基于：“基础开发过程本质上是迭代的。”这一假设的深刻影响——现代化的体现。
    • 1、基于架构优先的方法建立过程
    • 2、建立一个迭代过程，以通过此过程尽早解决风险
    • 3、强调基于组件的开发，以减少编码工作量
    • 4、应该建立变更管理来处理迭代过程。
    • 5、增强迭代开发过程的环境（称为双向工程），以通过自动化工具在多个制品上频繁地进行多次变更。
    • 6、使用基于模型和计算机可处理的符号来进行设计。
    • 7、建立质量控制和项目进度评估的客观过程，包括评价所有的中间制品。
    • 8、为能够更早地评估中间制品，使用基于演示的方法，将其转换为用户场景的可执行演示。
    • 9、计划增量式发布多个版本，每个版本有一组使用场景组成，并在细节上逐步演化
    • 10、建立一个可配置的过程，因为没有一个过程适合所有的软件开发。
• Wasserman提出的八大软件工程基础概念：
  • 注解：尽管软件行业正在发生变化，但是有8个软件工程概念保持稳定。
    • 1、抽象化
    • 2、分析、设计的方法和表示法
    • 3、用户界面原型
    • 4、模块化和架构
    • 5、复用
    • 6、生命周期和过程
    • 7、度量
    • 8、工具和集成环

第4章 软件过模型

4.1、软件过程

任何项目都可以通过需求、设计、编码、单元测试、发布、支持和维护来一步一步地完成。但是并不是所有的软件工程师都是这样想的。这节主要是统一这个过程。

• 软件过程模型的目标

  • 目标：系统地协调和控制必须执行的任务提供指导，以实现最终产品和项目目标。
  • 过程模型的定义
    • 一系列需要执行的任务
    • 每个任务的输入和输出
    • 每个任务的前置条件和后置条件
    • 任务的顺序和流程

    开发软件被视为协调和控制的中介，无需软件开发过程；
    软件开发被视为说明性路线图，则需要软件开发过程；比如，设计文档，用户指南。

• “最简单”的过程模型

  • 最简单：直指软件开发核心——编码，又叫做“编码-修复模型”
  • 归结为一个循环：编码——编译——单元测试
    
  • 有两个区域值需要关注
    • 问题陈述：经常是不清楚或不完整的
    • 单元测试：随之单元测试也不完整

4.2、传统的过程模型

介绍早期的基本的软件开发模型。

• 瀑布模型
  • 称为“经典软件生命周期模型”
  • 最早提出人：Royce
  • 名如其状，由它代表的过程衍生出来的
    
  • 其优点
    • 必须在第一步中指定需求(先决条条件)。
    • 包含发布前的四个主要任务：需求、设计、实现和测试。这期间会产生大量文档，所以又称此模型为文档驱动方法。
    • 每个阶段的输出按顺序传递给下一个阶段。
    • 可以根据在特定的、可识别的阶段间的移动顺序跟踪软件项目。
• 主程序员制制团队方法
  • 是一种协调和管理方法，非软件过程。
  • Fred Brooks《人月神话》描述，归功于Harlan Mills(IBM公司)
  • 一个团队中的主刀外科医生（主程序员），把任务分配给其他专家，由他来指导所有工作的执行。
• 增量模型
  • 定义：是一种把大型问题分成多个部分，每个部分遵循由瀑布模型。
    
  • 第一个增量可以作为版本1，其他功能在第二增量上形成版本2，著如此类
  • 各个版本之间是独立开发的，不用担心影响整个开发过程：时间角度。
  • 前一个版本的缺陷可以通过后续版本优化：维护方面
• 螺旋模型
  • 定义：是系统发展生命周期的模型。它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。
    
  • 由美国软件工程师巴里·勃姆于1988年5月在他的文章《一种螺旋式的软件开发与强化模型》
  • 应包含的步骤
    • 明确本迭代阶段的目标、备选方案以及应用备选方案的限制；
    • 对备选方案进行评估，明确并解决存在的风险，建立原型；
    • 当风险得到很好的分析与解决后，应用瀑布模型进行本阶段的开发与测试；
    • 对下一阶段进行计划与部署；
    • 与客户一起对本阶段进行评审；
      4.3、一个更加现代的过程
• RUP是什么？——RUP的基础
  • RUP的全称是Rational Unified Process，它是一个软件过程框架。
  • RUP的基础组成是什么？
    • 用例和需求驱动
    • 以体系结构为中心
    • 迭代和增量
• RUP的阶段
  • 为什么要分阶段？迭代开发中如果没有严格控制和协调，整个软件开发过程会陷入混乱，为了使得项目成功，就必须对开发过程做控制，跟踪，监控，和修改，这些形成了体系化结构，而这四个阶段就是这流程下大方向上的把控。
  • 四个阶段
    • 初始阶段：计划阶段，主要目标如下
      • 确定软件项目的范围并明确其目标；
      • 创建关键的用例以及驱动体系结构和设计的主要场景
      • 建立一些体系结构和早期设计的备选方案
      • 估算进度计划和所需资源
      • 计划实现、测试、集成和配置方法
      • 评估潜在风险
      • 总结：就是明确项目的目的是什么？结合现有的用例和体系结构的设计的场景，把目标带入进去，评估进度，资源，修改方法，建立出一套适合这个需求的方案。
    • 细化阶段：最关键的阶段
      • 建立系统中所有主要和关键的需求：把握主要，忽略次要。
      • 建立并展示基线设计：最基础的设计
      • 建立实现、测试和集成的平台和方法：这个基线设计所需要的环境
      • 建立所有商定目标的测量和量度：与目标衡量
      • 组织并建立实现、测试和集成中所需的所有资源：具体所需的资源
    • 构造阶段：生产阶段，落实阶段
      • 在估算的成本内即使完成
      • 实现一个可发布的版本，以进行一组受限的Alpha测试
      • 为了实现项目的目标，确立还需要完成的剩余活动。
    • 交付阶段：把产品放到具体环境下测试，看出现那些问题，修复这些问题。对用户进行培训，这个软件怎么结合手册使用？然后根据提出来的目标进行评估最后的软件，并作出做出发布决定。
      • 建立正式发布的最终软件产品
      • 建立软件的用户准备和验收
      • 建立支持准备
      • 获得发布和部署许可。

4.4、进入和退出标准：迄今为止，对软件开发过程都强调顺序和协调性，但是对每一项活动什么时候开始，什么时候结束却没有任何指导？进入标准和退出标准就是解决这个问题的度量指导。

• 进入标准：一项活动开始的条件
  • 所需制品
  • 所需人员
  • 所需工具
  • 需要对执行的活动和进行定义
  • 所有规约都已经有客户和其他利益相关者评审过
  • 评审过程中发现的异常都已经被修改
  • 修改后的规约被各方接受
  • 前四条基础条件，后三条：站在用户需求角度和软件品质角度考虑的
• 退出标准：对后三条的审核
  • 所有的制品都被评审过
  • 纠正所有错误或预先确认好百分比的错误
  • 执行下游活动的人员统一并接受这些制品

4.5、过程评估模型——>站在开发角度和用户使用角度来评估软件的好坏

• SEI的能力成熟度模型：度量软件开发成熟度水平的框架
  • 名称：能力成熟度模型为Capability Maturity Model，简称CMM,最初由SEI提出。
  • 划分标准：依据软件组织在实践中采取不同的关键软件开发过程活动归其成熟等级。
  • 成熟等级有5个级别：依次从最不成熟——>最成熟数为：
    • 初始级： ——>第1级：最不成熟
    • 可重复级：——>第2级
    • 已定义级：——>第3级
    • 已管理级：——>第4级
    • 优化级： ——>第5级：最成熟数
  • 第1级：组织内没有过程，当其在不同过程中进行定义、实践并不断改进时，它的成熟度会提升一个级别。
  • 第2级：6个关键过程(1)~(6)
    • (1)需求管理
    • (2)软件项目跟踪和监督
    • (3)软件质量保证
    • (4)软件项目计划
    • (5)子合同管理
    • (6)软件配置管理
    • 这些过程在相似项目中可以重复取得成功，但要越迁3级需要以下7个关键过程
    • (7)组织过程焦点
    • (8)培训计划
    • (9)软件产品工程
    • (10)同时评审
    • (11)组织过程定义
    • (12)集成关键管理
    • (13)组间协调
  • 第3级:（1)~(13)
    • (14)定量的过程管理
    • (15)软件质量管理
    • 具备这2个关键过程，就会从第3级别提高到第4级
  • 第4级：(1)~(15)
    • 想要从第4级别提升到第5级，还需要以下3个关键过程
    • (16)缺陷预防
    • (17)技术变更管理
    • (18)过程变更管理
  • 第5级：(1)~(18)
• SEI的能力成熟度集成模型
  • 能力成熟度集成模型为Capability Maturity Model Integrated,简称CMMI
  • 从CMM的升级到CMMI
  • 而这个介绍的是CMMI应用到软件过程模型的CMMI-SW模型
  • CMMI-SW模型有两种表示方式：
    • 连续式
    • 阶段式
  • 前面早期软件开发过程讲究连续式，以及发展过程中出现的阶段式(基于连续式的)，这里又引入一个关键概念——CMMI的过程域。
  • CMMI的过程域(基于阶段式)：它是覆盖四大类的25个主要过程域：过程管理、项目管理、工程、支持。
  • 过程管理（5个）
    • 1)组织过程焦点
    • 2)组织过程定义
    • 3)组织培训
    • 4)组织过程绩效
    • 5)组织创新与部署
  • 项目管理（8个）
    • 1)项目规划
    • 2)项目监督与控制
    • 3)供应商协议管理
    • 4)集成化项目管理
    • 5)风险管理
    • 6)集成化团队
    • 7)集成化供应商管理
    • 8)量化项目管理
  • 工程（6个）
    • 1)需求开发
    • 2)需求管理
    • 3)技术解决方案
    • 4)产品集成
    • 5)验证
    • 6)确认
  • 支持（6个）
    • 1)配置管理
    • 2)过程和产品质量保证
    • 3)测量与分析
    • 4)组织集成环境
    • 5)决策分析与解决方案
    • 6)因果分析与解决方案

4.6、过程定义和通信

软件开发过程就是进行活动的载体，具体说名过程就类似于构建软件系统本身。
项目中因为用户陈述问题不够完整，必然开过过程中存在理解偏差的问题，修改再所难免，为了使得修改后的过程让所有的参者都知晓，必须要对修改的内容进行明确的定义，形成大家都了解的规范，这是人与人之间的交流协作，为通信。

• 软件过程的规范：

  • 包含项目中的活动
  • 执行这些活动的顺序

• 这个规范被进一步完善：

  • 活动：对过程中所包含的每一项活动的详细描述
  • 控制：每项活动有必要的进入和退出标准，以及每项活动的执行顺序
  • 制品：每项活动的输出结果
  • 资源：执行活动的人
  • 工具：可用于提高活动性能的工具

第5章 新兴过程方法

5.1、什么是敏捷过程：

• 简单定义：是短周期迭代产生软件，并允许更大设计变化的一些类软件开发过程。
• 对理解敏捷开发的特征
  • 短周期的版本发布和迭代：将工作分块，频繁发布。
  • 增量设计：因为早期对软件了解不够，所以一点一点开发，不要一下子都完成。
  • 用户参与：开发是以用户需求为目标的，所以让用户持续提供反馈。
  • 最少的文档：必要的文档（大部分实际上是代码）
  • 非正式沟通：不要繁文缛节
  • 变化：拥抱变化，需求和环境变化，就积极寻找好的办法来应对。

5.2、为什么使用敏捷过程?

基于传统开发的缺点，提出来更能适应节奏的敏捷过程。下面看一下，针对传统的开发过程的确定，敏捷过程是怎么提出对应的解决方案的？

传统软件过程的缺点	敏捷过程的提出的解决措施
漫长的开发过程	短周期的版本发布和迭代
无法适应不断变换的需求	变化
假设在项目开始之前就完全理解需求	增量设计，知道一点开发一点
过分依赖于开发人员的努力	用户参与
复杂的方法：活动和产品规范过于详细，理解费时	最少(必要)的文档
多余/重复:有些文档信息强制性，多种形式维护	非正式沟通

5.3、一些过程方法

选几个代表性(典型的)的敏捷过程

• 极限编程（简称XP)：

  • 最早最广为人知的敏捷开发方法之一
  • 来源于Kent Beck在克莱斯勒汽车公司（Chrysler Corporation）名为C3的项目使用
  • XP的核心价值观如下
    • 团队成员与客户之间的频繁沟通
    • 设计和代码的简单性
    • 多层反馈。单个开发人员，或者结对开发人员，用户。
    • 用于执行艰难但必要的决定。不适用XP。
  • XP遵循的5个基本原则(从核心价值观抽象来的)：核心理论
    • 1、快速反馈：使用结对便编程、单元测试、集成以及短周期迭代。
    • 2、简单。方法
    • 3、增量式变化：效地变化累加
    • 4、拥抱变化：为未来保留预选项
    • 5、优质工作：
  • XP非中心原则：辅助理论
    • 持续学习
    • 初始投资少
    • 为胜利而战
    • 具体实验
    • 公开、诚实地共同
    • 随着人的本能工作
    • 承担责任
    • 适应当地
    • 轻装上阵
    • 如实地测量
  • XP的12个关键实践：具体实践
    • 计划：使用业务优先，技术评估相结合，来评估版本特性
    • 短周期发布：
    • 隐喻:简单说法
    • 简单设计：系统设计
    • 测试驱动开发：向自动化靠拢
    • 改进设计：系统结构
    • 结对编程：确保所有的产品代码的都是由两个程序员在同一台计算机或设备上编写的。所有代码至少由其中一个审查。
    • 集体所有权:整个团队拥有代码的所有权。任何人都可随时更改系统中的任何代码。
    • 持续集成：每此完成任务后，集成系统并每天构建系统。检错。
    • 可持续的步调：只以你能为维持的步调工作；只要能维持设备工作，一天可以干6h的活都可。
    • 现场客户：让客户参与团队，提供反馈。
    • 编码标准：规范，修改维护方便。

• 水晶系列方法

• 敏捷统一过程-RUP

• Scrum

• 看板方法：一个新增的敏捷方法

• 开源软件开发——与敏捷方法相似的成功模型

新兴的方法和过程总结：

方法	要点	敏捷性	纪律性
XP	曾经最流行的敏捷过程。需要高度的纪律性并遵守原则和实践。基于4个核心价值观(沟通、简单、反馈、勇气)，5个基本原则(快速反馈、简单、增量变化、拥抱变化、优质工作)，12个是实践	高	高
透明水晶	方法很轻量级。不需要遵守所有原则。基于7个原则：频繁交付、反思改进、密切交流、个人安全、焦点、预装间建立方便的联系、良好的技术环境。只是适用于小型项目和团队	高	低
橙色水晶	比透明水晶量级，适合更大的项目。对不同的功能有不同的团队。仍然不适合大型或者性命攸关的项目	中等	中等
Scrum	目前最流行的敏捷过程。它是一种可以适应并结合其他技术的严格方法。它为项目状态提供了明确的可见性，从长远来看，可以减少项目管理方面的工作量	高	高
RUP	框架，通常被实例化为一个非常重量级的过程。可以简化一个行对敏捷的过程。详见第4章	低-中等	高
看板	最小化在制品。为每个任务适用可视卡。在需要时通常集中资源来‘拉’前面的	高	低

敏捷与传统过程的特点对比

方面	敏捷	传统/重量级
需求	假设它们将发生变化。在项目开始时非正式收集需求，然后在每次迭代开始时收集。使用不断的用户交互替代正式需求	假设它们在项目期间不会改变。完整、详细的正式需求文档是成功的必要条件。在设计活实现开始后，对需求的任何更改都将是代价高昂的
规划	预先没有规划。在整个开发中以较小的增量进行计划	大多数活动都是预先规划好的
进度计划	只计划下一个活动的进度。如果需要调整范围，进度计划可能会发生变化	进度想读不灵活，并应该被遵守
设计	非正式和迭代	正式且提前完成，已知所有需求后进行
用户参与	关键，频繁，贯穿整个过程	仅在开始(需求征集和分析)和最后(验收测试)需求
文档	最小化，只有必要的。依靠源代码作为最终的文档	通常项目的每个阶段都需要有大量的正式文档
沟通	非正式进行，贯穿整个项目	主要依靠文档和正式备忘录于与会议
过程复杂性	相对较低。初始描述少于200也	高。RUP(2002)描述了100多件制品，9条规程，30个角度和4个阶段
开销	低	相对较高，虽然较小的项目可以减少开销

5.4、过程的选择

统一过程UP， Rational统一过程RUP
没有任何可以适应所有项目的过程，过程需要根据项目、组织文化和参与者进行调整。

5.4.1、每一种过程跟使用的项目和环境
敏捷过程与传统过程的项目对比

方面	敏捷(最典型的代表XP)	传统(最典型的RUP)
范围/规模	小，限于一个最多的10人的团队	更适合较大的项目。可扩展到最大的项目，也可以缩小为较小的项目
关键性	相对较低，没有调整时不适合于性命攸关的项目	使用于关键任务系统(可能只要是最小的修改)
人员	更适合善于团队合作、可以做好设计和编程的“好公民”。XP需要严格遵守某些做法	定义许多角色，这对于大多数人来说是适合的；不需要紧密地团队合作；只要团队成员能遵守规则，集和任何个性的成员都可以
企业文化	更适合拥有轻松文化、在同一地点工作的小型公司	更适合于可能有远程站点，文化更正式的大公司
稳定性	很容易应对需求或环境的改变	不那么适应变化。需求不会有太大变化的行对稳定环境。可以修改

5.4.2、敏捷过程的主要风险和缺点

• 可能不可扩展
• 严重依赖团队合作
• 依赖于频繁访问客户
• 文化冲突

5.4.3、敏捷过程的主要优点

• 过程复杂性低：
• 成本和开销低
• 有效低处理变化
• 快速的结果：
• 可用的系统：

第6章 需求工程

6.1、需求处理

需求是什么？需求是用户要求和期望的系统是什么？
需求工程是什么？ 需求工程:满足需求的一系列活动。
比如假设你变成了一台电脑，要和卫星人讲清楚人是什么？怎么了解？
用软件工程项目中涉及的需求工程活动来说：
1、获取：获取人的图片
2、文档化与定义：表象对人描述：一个头，两条胳膊，两条腿…
3、规约:较为深层次：能走路，使用火把…
4、原型化：形成了对人的原型，
5、分析：与其他猩猩区别
6、审查与确认：然后那个卫星人抓几个自以为的"人"与你确认
7、协商与认可：确定

• 需求处理的准备
  • 需求工程要采用的过程：类比从武汉去上海的线路选择
  • 需要的资源：要钱，干粮
  • 完成需求活动的时间安排：时间表
• 需求工程过程-a

一旦完成了需求工程的准备工作，就可以开始实际的需求开发了。
该过程开始于需求分析师对用户和客户的需求进行收集与获取。

软件需求规约(SRS)：是一个系统记录的完整、无歧义的、可度量的、详细的需求规约

• 需求过程过程-b:
  • 三个中心活动：从需求分析角度讲
    • 1、需求定义与文档化
    • 2、需求原型化
    • 3、需求审查
  • 不执行需求工程会面临什么问题？
    • 测试中没有可依赖的文档化需求。
    • 没有达成一致的需求来控制需求蔓延。
    • 没有文档化的需求来用于客户培训活客户支持活动。
    • 没有文档化的需求很难管理项目的进度和成本

6.2、需求获取与收集

• 获取高层次的需求：
  • 需求分析师需要寻求赞助软件项目的管理层和管理人员来了解背后的业务原理。
  • 高层次业务需求的信息类别：
    • 机会/要求：由于软件供应商带来的
    • 理由
    • 范围：库存控制和订单处理
    • 主要约束：软件分配的预算、时间表
    • 主要功能：列出客户需求的主要功能
    • 成功因素：机会/要求、取决于试运行软件时的用户训练程度。
    • 用户特性：付费客户关注的
• 获取详细的需求：承上，上一个步骤完成就是此步骤
  • 客户会根据现有的软件讨论一个特定的问题VS需求分析师要进行有想象力和技术性的对话————怎么才能使得它们控制在一定的范围，不至于失控呢？
  • 需求的6维度
    • 个人功能
    • 业务流
    • 数据、格式和信息需求
    • 带有其他接口的系统
    • 用户接口
      • 控制的转换(界面的唤醒)
      • 数据的转换(直接或通过数据库)
      • 收到回复(成功或失败，错误信息类型和消息)
      • 重试功能
    • 其他限制，如性能、可靠性和安全性

6.3、需求分析

• 通过业务流进行需求分析和聚类
  • 自然需求聚类遵循的6要素：——即上面的需求的6维度
• 通过面向对象进行需求分析和聚类
  • 用例：用户或参与者业务流上下文中，系统应当执行的一系列动作。
  • 面向对象OO
  • 此OO用例被用于描述系统的需求
  • 此OO用例也被用于需求的分析以及系统的设计与测试
  • 此OO用例描述什么？
    • 基本的功能
    • 该功能的任何前置条件
    • 该功能的被称为场景的时间流
    • 该功能的任何后置条件
    • 任何错误条件以及备选流
  • 因为对象(参与者)与系统有关，所以需求分析员应该提出以下问题？
    • 谁使用该系统？假设该系统是一台电脑，用电脑的人？
    • 谁操作并维护该系统？系统供应商
    • 其他什么系统使用该系统？物流系统用的就是电脑
    • 其他什么系统被该系统使用？
  • 怎么甄别一个好的OO用例
    • 参与者
    • 相关的用例
    • 边界条件
• 通过面向视点的需求定义进行需求分析和聚类
  • 什么是面向视点VORD：需求在不同的利益相关者看来是不一样的
  • 怎么贯彻VORD？（步骤）
    • 1、识别利益相关者与视点
    • 2、对视点进行结构化和分类，消除重复，并将共同视点放在一起（聚类）
    • 3、精化识别出的视点
    • 4、讲视点映射到系统与系统提供的服务
• 需求分析语排序
  • 对需求分类，聚类这是其中一部分，还受到其他约束
    • 有限的资源
    • 有限的时间
    • 有限的技术能力
  • 不是所有的需求都是同等重要的，它有优先级，什么是优先级?
    • 当前客户需求
    • 竞争和当前市场状况
    • 未来客户需求
    • 即时销售优势
    • 现有产品中的关键问题
• 需求可追踪性：为什么要追踪？验证所有需求是否已经开发、测试、打包和交付。
  • 不是所有的需求都可以追踪——Kotonaya和Sommerville列出了四类可追踪；
  • 四类可追踪性；
    • 1、正向向后可追踪性：将需求链接到文档源或创建它的人。
    • 2、正向向前可追踪性：将需求链接到设计和实现。
    • 2、反向向后可追踪性：将设计与实现反向链接到需求。
    • 4、反向向前可追踪性：将设计之前的文档链接到需求。

6.4、需求定义、原型化和审查

• 需求分析阶段的表示法
  • 最简单的：输入-处理-输出图
  • UML:
  • 数据流程序图DFD
    • 包括四个要素：数据来源和目的地，数据流、过程和数据存储
  • ER:描述实体之间的关系
• 主要专注于用户与系统交互——>用户界面
  • 需求分析用户界面的什么？
    • 视觉外观和显示
    • 与人交流的交互

6.5、需求规约与需求协商

• 对需求进行分析和审查后，将其纳入到软件需求规约（SRS）文件。
• 如何纳入？包括以下几个参数
  • 项目规模和复杂程度
  • 计划和预期的客户支持活动的数量
  • 估计和预期的客户支持活动的数量
  • 开发人员对目标领域的知识和经验
• IEEE标准：软件需求的规范，软件需求规约(SRS)
  • 简介：通过描述目的、范围、参考和术语的定义来提供概述。
  • 高层次描述：提供软件产品的一般描述及其主要功能、用户特征、主要约束和依赖关系的描述
  • 详细需求：内容包含
    • (1)、通过输入、处理和输出来详细说明每个功能需求；
    • (2)、包括用户界面、系统接口、网络接口、和硬件接口的接口说明；
    • (3)、详细说明性能需求；
    • (4)、诸如标准或硬件限制等设计约束的列表；
    • (5)、对诸如安全性、可用性和可恢复性等属性的附加说明；
    • (6)、任何额外的独特要求。

第7章 设计：架构与方法论

7.1、设计简介

• 1、理解了项目的需求，接下来就开始转化到设计了。
• 2、需求解决的是什么？设计解决的是如何？
• 3、架构设计阶段：对系统的一个宏观蓝图，通常划分为几个部分。详细设计阶段：对系统的一个微观细节，是对这几个部分的具体实现。

7.2、架构设计

• 什么是软件架构？——系统的基本结构。

• Bass\Clenments和Kazman对软件架构的进一步定义：一个程序或计算系统的软件架构是指系统的结构或i这结构集合，它包含软件元素、这些元素的外部可视属性以及它们之间的关系。

• 几个注意点：

  • 每个系统都有一个架构。
  • 可能有不止一个。
  • 架构处理每个模块的外部属性。

• 什么是视图（视角）？

  • 视图：是系统结构的一个展示
  • Kruchten 提出并发展为4+1架构视图
    
    • 逻辑视图:逻辑视图和提供给最终用户的机能有关。会用统一建模语言（UML）来表现逻辑视景，包括有类别图、状态图等。
    • 过程视图：处理系统的动态层面，说明系统的过程以及通信的方式，着重在系统运行时的时间特性。表示过程视景的UML有时序图、通信图等。
    • 开发视图：从程序员的观点所看到的系统，着重软件的管理。会用到UML中的组件图来说明系统组件。
    • 实体视图：以系统工程师的观点来说明系统，这和软件组件在物理层上的拓扑有关，也和各组件之间的实体连接有关。
    • 情景：这种说明架构的方式是透过小型的用例或情景来进行，这是第五个观点。情景会叙述各对象、各过程之间交互的结果。也可以用来识别架构元素，也可叙述并且确认架构设计。这也是架构原形测试的起点。
  • 元架构知识：
    • 什么是元架构？
      • 元架构：系统有多个不同的架构，怎么描述这些架构之间的关系(同，异)？这些知识称为元架构。
    • 软件系统结构的3种描述角度？
      • 从架构风格或模式
      • 从架构策略
      • 从参考架构
    • 架构风格（或者模式）：从宏观看的
      • 什么是架构风格？一个架构的特征。
      • 常见的架构风格：
        • 管道和过滤器
        • 事件驱动：
        • 客户端-服务器
        • 模型-视图-控制器
        • 分层：
        • 数据库为中心：
        • 三层级：
    • 架构策略：争对具体的小问题。从微观看的
    • 参考架构：其他成熟的架构模板。起参考作用。

• 基于网络的Web参考架构——REST

  • 什么是REST?
  • 表现层状态转换（英语：Representational State Transfer，缩写：REST）
  • 为了解决什么问题？
  • 是Roy Thomas Fielding博士于2000年在他的博士论文[1]中提出来的一种万维网软件架构风格，目的是便于不同软件/程序在网络中互相传递信息。
  • 注意要点：REST是设计风格而不是标准。REST通常基于HTTP、URI、XML以及HTML这些现有的广泛流行的协议和标准。
  • REST架构风格最重要的6个架构限制条件：
    • 1、客户端-服务器（Client-Server）：目的是将客户端和服务器端的关注点分离。
    • 2、无状态（Stateless）：
    • 3、缓存（Cacheability）：
    • 4、统一接口（Uniform Interface）：
    • 5、分层系统（Layered System）：
    • 6、按需代码（Code-On-Demand，可选）：
  • 应用于Web服务： 符合REST设计风格的Web API称为RESTful API。它从以下三个方面资源进行定义：
    • 直观简短的资源地址：URI，比如：http://example.com/resources。
    • 传输的资源：Web服务接受与返回的互联网媒体类型，比如：JSON，XML，YAML等。
    • 对资源的操作：Web服务在该资源上所支持的一系列请求方法（比如：POST，GET，PUT或DELETE）。

7.3、详细设计

• 功能分解
• 关系型数据库设计
  • 1、数据建模阶段
  • 2、逻辑数据库设计阶段
  • 3、物理数据库设计阶段
  • 4、维护和部署阶段。
• 大数据设计：关系型数据库+非关系数据库
  • 有4个概念
    • 水平可扩展性：通过增加更多计算机而不是使得单台计算机更快来扩展系统的能力。
    • 分片：将键值存储的不同键存储在不同的计算机上。
    • 键值对存储：为每个键存储一个值，并且只允许通过键值进行简单查找的数据库。
    • 复杂对象数据库：直接存储复杂对象的数据库。
• 面向对象设计和UML
• 用户界面设计
• 进一步的设计问题

7.4、HTML-Script-SQL设计示例

• 什么是MVC?
  • MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
  • MVC模式最早由Trygve Reenskaug在1978年提出
  • 需要注意的是：MVC 不是一种技术，而是一种理念。
• MVC模式解决什么问题？
  • 为了实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。
• 模型（Model）:程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
• 视图（View）:界面设计人员进行图形界面设计。
• 控制器（Controller）:负责转发请求，对请求进行处理。
• MVC之间的交互：

  • 模型（Model） 用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“ Model ”有对数据直接访问的权力，例如对数据库的访问。“Model”不依赖“View”和“Controller”，也就是说， Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，从而，View 可以了解在数据 Model 上发生的改变。

  • 视图（View）能够实现数据有目的的显示（理论上，这不是必需的）。在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能，View 需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。

  • 控制器（Controller）起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据 Model 上的改变。
    

  • 用Javascript实现MVC模式

/** 模拟 Model, View, Controller */
var M = {}, V = {}, C = {};

/** Model 负责存放资料 */
M.data = "hello world";

/** View 负责将资料输出给用户 */
V.render = (M) => { alert(M.data); }

/** Controller 作为连接 M 和 V 的桥梁 */
C.handleOnload = () => { V.render(M); }

/** 在网页读取的时候呼叫 Controller */
window.onload = C.handleOnload;

第8章 设计的特征与度量

8.1、设计描述
软件工程中都在追求描述对“好的设计”的度量，但都很难明确，在长期实践过程中唯有以下两个性质最为实用：

• 一致性
• 完整性

8.2、设计属性的传统特征
软件工程初期，把软件设计的重心放在编码上面，未曾关注过程架构这个层次。传统的软件工程度量也大抵都是这样的毛病，下面对关于早期的几个度量软件工程好坏的方法。

• Halstead复杂度度量
  • 核心观点:通过统计对源程序当中出现的操作符(数)的次数来度量。
  • 对于这种只统计词法，而忽略结构和逻辑的度量方法舍弃掉了。
• McCabe圈复杂度
  • 这个是比较科学的度量方法，它从程序的控制流程来计算，此度量方法作为一个评估流程图中线性独立路径的方式被保留了下来。
  • 公式：圈复杂度=图的边数E-图的结点数N+2连接的组件数量P,例如
    
• Henry-Kafura信息流
  • 这个也是从结构方面考量的度量方法，它用在模块的信息流，但是不适用复杂架构。
  • 信息流：模块之间、模块与环境之间的度量
    • 参数传递
    • 全局变量访问
    • 输入
    • 输出
  • 基于信息流基础上的另外两个指标：开创性的度量方式，后面有的方法也基于指标基础上。
    • 扇入：流入程序模块的信息流数量
    • 扇出：从程序模块流出的信息流数量
  • 核心公式：Cp=Cpix(扇入+删出)^2,其中Cp为Henry-Kafura信息流复杂度，Cpi程序模块p内部的复杂度。
• 高层次复杂度度量
  • 是一种基于扇入和扇出概念，考量程序内和程序间交互的一种度量方式。
  • 主要内从包括以下3种
    • 结构复杂度
    • 数据复杂度
    • 系统复杂度

8.3、“好”的设计属性——基于程序模块之间出来的概念
什么是好的设计，这一直是软件过程想要去度量的方式，从开始的6易于——>7内聚——>5耦合

• 6易于：但这些真的是判断好的设计吗？怎么去实现它们呢？
  • 易于理解
  • 易于变更
  • 易于重用
  • 易于测试
  • 易于整合
  • 易于编码
• 7内聚：从坏到好的排序如下，但这些并没有精确的数值去衡量，不能实用于需要精准的工程问题。
  • 偶然内聚
  • 逻辑内聚
  • 时间内聚
  • 过程内聚
  • 通信内聚
  • 顺序内聚
  • 功能内聚
• 5耦合：对于内聚不能解决实现易于特征，有发展出来了能够表现表征“易于”的耦合的概念，从差到好依次如下顺序表示
  • 内容耦合
  • 公共耦合
  • 控制耦合
  • 印记耦合
  • 数据耦合

8.4、面向对象设计度量
解决8.3节问题的面向对象设计度量方式出现了，它通过分解，高内聚和低耦合所保持的设计简单化的概念。

• 面向对象中的几个关键概念
  • 类
  • 继承
  • 封装
  • 多态
• 如何把它们之间关联，交互？接下来将探索对这些属性进行度量
• 面向对象中确定的6个C-K值衡量：
  • 1、各个类的方法加权和（WMC）
  • 2、继承树的深度（DIT）
  • 3、子节点数（NOC）
  • 4、对象类之间的耦合（CBO）
  • 5、类的响应（RFC）
  • 6、方法对内聚的缺乏（LCOM）
• 这6个C-K设计度量都直接或间接地与内聚和耦合概念相关。这些度量帮助软件设计人员更好地了解其设计的复杂度，并简化其工作。
• 面向方面的编程AOP
  • 是系统的关注点分离或方面分离概念的新演变。
• Demeter法则——度量准则，来源于一个AOP项目
  • 它通过写那种类中的方法的消息来限制对象的控制范围（降低对象的耦合度，并提高对象的内聚度）。
  • Demeter法则规定，一个对象应该发送消息到以下类型的对象
    • 当前对象本身
    • 当前对象的成员对象
    • 以参数形式传入到当前对象方法中的对象
    • 当前对象创建的对象
    • 调用当前对象方法返回的对象
    • 如果当前对象的成员对象是一个集合，那么集合中的元素也满足条件。
      8.5、用户界面设计
      作为软件工程的另外一个关注点，程序于用户的交互也在追求好。
• 好的UI特征
  • 确保所有界面都有一致的模式，给出的3个黄金法则
    • 给用户控制权
    • 减少用户记忆负担
    • 设计一致的用户界面
  • 由3个黄金法则衍生出的另外2个原则：
    • 1）用户操作在被中断时允许重新操作；
    • 2）用户默认值应该时最有意义的。
  • 经过这方面的发展，指出了页面设计方面的8个规则：
    • 1）保持一致
    • 2）允许高频用户使用快捷方式
    • 3）提供反馈
    • 4）关闭时提供提示对话框
    • 5）提供错误预防和简单的错误处理
    • 6）提供简单的操作回滚
    • 7）支持内部控制轨迹
    • 8）减少用户的短期记忆
• 易用性的评估和测量：UI设计要考虑以下关键因素
  • 在没有帮助的情况下完成任务的用户数
  • 完成每个任务的平均时间
  • 诱发帮助功能的平均次数
  • 在规定时间间隔内完成的任务数
  • 用户需要重复完成执行一个任务的地方以及重复执行的次数
  • 快捷方式的使用次数

第9章 实现

第10章 测试和质量保证

第11章 配置管理、集成和构建

第12章 软件支持和维护

第13章 软件项目管理

第14章 结语及当代软件工程的若干个问题。