文章目录

• 概述
• • 1.1 什么是软件
  • 1.2 ==优良软件的属性==
  • 1.3 工程与工程活动
  • 1.4 软件危机
  • 1.5 什么是软件工程
  • 1.6 软件过程与软件生命周期
  • 1.7 软件工程方法
  • 1.8 ==软件项目的成功要素==
  • 1.9 职业与道德责任
• 软件过程
• • 2.1 瀑布模型（顺序模型）
  • 2.2 进化式开发模型
  • 2.3 增量式开发
  • 2.4 基于构件的软件工程
  • 2.5 敏捷软件开发
• 需求工程
• • 3.1 需求分析基础
  • 3.2 需求工程过程
  • 3.3 结构化分析建模
  • 3.4 UML与面向对象分析方法
  • • 3.4.1 理解uml
    • 3.4.2 需求导出工作流程
    • 3.4.3 需求精化工作流程
    • ==重点==
  • 3.5 需求有效性验证
• 设计工程
• • 4.1 软件工程中的设计
  • 4.2 设计概念
  • • 4.2.1 模块化（理解）
    • 4.2.2 信息隐藏与独立性
    • 4.2.3 抽象（理解）
    • 4.2.4 逐步求精（理解）
  • 4.3 体系结构设计
  • • 4.3.1 数据中心体系结构
    • 4.3.2 客户/服务器体系结构
    • 4.3.3 分层体系结构
  • 4.4 体系结构视图
  • 4.5 控制模型
  • 4.6 鲁棒性分析
  • 4.7 用户界面设计过程
  • 4.8 界面设计的一般原则
  • 4.9 错误消息
  • 4.10 帮助系统设计
• 软件实现与验证
• • 5.1 程序设计与调试
  • 5.2 验证和有效性确认
  • 5.3 用来实现V&V目标的测试模型
  • 5.4 V&V过程的两种基本方法
  • 5.5 V&V规划
  • 5.6 系统开发的V模型
  • 5.7 软件测试阶段活动
  • 5.8 集成测试
  • 5.9 测试用例设计
  • 5.10 ==等价划分测试==
  • 5.11 结构化测试
  • 5.12 逻辑覆盖法
  • 5.13 基本路径测试
• 软件维护
• • 6.1 系统变更与进化
  • 6.2 软件维护与维护成本
  • 6.3 预防性维护/软件再工程
  • 6.4 软件再工程过程模型
• 软件项目管理
• • 7.1 软件项目管理基础
  • 7.2 ==软件项目管理中的4P==
  • 7.3 ==项目策划任务集==
  • 7.4 软件项目的成本构成
  • 7.5 项目进度安排
  • 7.6 配置管理

概述

1.1 什么是软件

• 软件 = 程序 + 数据 + 相关文档
• 专业化开发的软件包括
  • 计算机程序
  • 数据结构
  • 配置文件、系统文档、用户文档

1.2 优良软件的属性

• 可维护性
• 可依赖性
• 有效性
• 可用性

1.3 工程与工程活动

共性特征：
– 大规模设计与建造
– 复杂问题与目标分解
– 团队协作与过程控制

1.4 软件危机

软件危机指的是软件发展过程中逐渐出现的一系列严重的问题。
软件工程是能够解决软件开发严重问题的有效途径

1.5 什么是软件工程

• 软件工程是设计软件生产各个方面的一门工程学科
• 方面包括：
  • 软件生命周期的各个方面
  • 人为因素
  • 经济因素
  • 法律因素
• 软件工程的另一种说法（IEEE【IEEE93】）：
  • 将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件
  • 研究上述方法

1.6 软件过程与软件生命周期

• 软件过程是指开发或制作软件产品的一系列活动及其成果
• 所有的软件过程包括四个基本活动：
  • 描述
  • 开发
  • 有效性验证
  • 进化
• 软件生命周期是软件过程的另一种形象描述，通常包括需求定义、分析与描述、软件设计、实现、测试、维护与退役等活动。

1.7 软件工程方法

• 软件工程方法是软件生命周期中使用的一整套技术方法的集合，包括系统模型描述、约束规则、设计建议、过程指南等元素。
• 软件方法经历的四个阶段：
  • 面向过程
  • 面向对象
  • 面向构件
  • 面向服务
• 四个阶段软件复用程度逐渐提升，软件开发效率越来越高。

1.8 软件项目的成功要素

• 按时交付
• 不超预算
• 满足用户要求

1.9 职业与道德责任

软件工程师应遵循的行为准则：

• 保密
• 工作能力
• 知识产权
• 计算机滥用

软件过程

2.1 瀑布模型（顺序模型）

瀑布模型的特点和使用情况

• 反映了工程设计的基本思想
• 把一个软件过程划分成几个界限清晰的阶段，而这些阶段有严格的顺序，导致很难对用户的需求变更做出及时的调整
• 只适合需求非常清楚、需求变更被严格限制的情况

2.2 进化式开发模型

• 基本思想：通过开发系统原型和用户反复交互以明确需求，是系统在不断调整与修改中得以进化成熟。又叫做原型式开发方法
  
  特点：
  • 系统不是作为一个整体交付，而是被分解成若干个可以单独交付的模块——增量，每个增量交付系统的部分功能
  • 用户的需求按优先级排队，优先级最高的需求被放入最早交付的增量中

  2.4 基于构件的软件工程

  • 软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程
  • 软构件是标准的、可互换的、经过装配可随时使用的软件模块
  • 软件复用的意义：
    • 使软件系统的开发不再“一切从零开始”，能够充分利用已有的知识和经验
    • 避免重复劳动，提高开发效率，降低开发成本
    • 避免全新开发可能引入的错误，提高软件质量

  基于构件的软件工程和瀑布模型的区别

  
• 适用情况
  • 中小规模的开发团队
  • 每个团队成员都可以参与决策
  • 需求变更频繁的项目
  • 风险高的项目

需求工程

3.1 需求分析基础

• 需求的两个不同层次的描述
  • 用户需求
    • 从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明
  • 系统需求
    • 一种结构化的文档，要运用一些专业的模型详细的描述系统的功能及其约束。
• 功能需求和非功能需求
  • 功能需求
    • 对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的描述。某些情况下还包括系统不应做什么
  • 非功能需求
    • 对系统提供服务或功能时受到的约束进行描述。
  • 领域需求
    • 这种需求来自于系统的应用领域，反映领域特征。可能是功能需求也可能是非功能需求。
  • 非功能需求往往更为关键，因为非功能需求表示的是系统的整体特征
  • 功能性需求描述应具备全面性和一致性
  • 非功能需求的常见问题是检验困难，描述时应该设定明确目标并设定可测试的度量标准
• 适用自然语言描述需求的准则
  • 设计一个标准格式
  • 使用一致的语言
  • 使用文本加亮来突出关键性需求
  • 尽量避免使用计算机专用术语

3.2 需求工程过程

数据流图的画法

3.4.3 需求精化工作流程

设计工程

4.1 软件工程中的设计

• 设计是一个把问题转换成解决方案的创造性过程
• 设计解决的是==“如何实现系统”==的问题
• 从工程管理的角度，软件设计可以分为概要设计（总体设计、系统设计）与细节设计（详细设计）

4.2 设计概念

4.2.1 模块化（理解）

• 把软件划分为可独立命名和编址的构件
• 目的：更好的解决问题

4.2.2 信息隐藏与独立性

• 模块应该是功能独立的
• 好处
  • 支持模块并行开发
  • 减少测试和后期维护的工作量
  • 整个系统扩充功能只需要插入新模块
• 模块独立性
  • 两个定性准则来度量：耦合性和内聚性
  • 耦合是模块之间相对独立性的量度，内举是模块功能相对强度的量度
  • 模块的内聚性越强，耦合性越弱，独立性越强

4.2.3 抽象（理解）

抽象就是抽出事物的本质特性而暂时不考虑它们的细节

4.2.4 逐步求精（理解）

• 早期的一种自顶向下设计策略
• 主要思想：针对某个功能的宏观描述，用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语言描述的算法实现为止
• 层次结构的上一层是下一层的抽象，下一层是上一层的求精

4.3 体系结构设计

• 任务：识别出组成系统的子系统并建立子系统的控制和通信框架
• 系统的组成：
  • 反映的是系统组织所采用的基本策略
  • 组成类型：
    • 数据中心体系结构
    • 客户/服务器体系结构
    • 抽象机或分层体系结构

4.3.1 数据中心体系结构

• 基本特点：所有共享数据放到一个中心数据库中，所有子系统都能从中存取数据
• 当系统中存在大量的数据共享时，数据中心模型是最常用的体系结构风格

4.3.2 客户/服务器体系结构

• 分布式系统模型
• 主要组成：
  • 一组为其他子系统提供服务的服务器
  • 一组向服务器请求服务的客户机
  • 连接客户机与服务器的网络

4.3.3 分层体系结构

• 把系统组织成一系列的层次，每一层提供一组服务
• 支持增量式开发，不同层次的服务可以单独交付
• 层与层之间以接口相联系

4.4 体系结构视图

• 软件体系结构式对系统构成与部分间联系的多角度描述，每一种模型只能描述系统的一个侧面
• 一个体系结构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体

4.5 控制模型

• 考虑子系统之间的控制流
• 两种一般性方法：
  • 集中式控制：一个子系统专门负责控制，控制其他子系统的启动与停止
    • 调用——返回模型
    • 管理者模型
  • 基于事件的控制：每个子系统都能够接受来自系统外部的事件并作出响应
    • 广播模型
    • 中断驱动模型

4.6 鲁棒性分析

4.8 界面设计的一般原则

• 用户熟悉
• 一致性
• 意外最小化
• 可恢复性
• 用户差异性

4.9 错误消息

• 错误消息应该是礼貌的、简明的、一致的、建设性的
• 能够分析不同错误信息提示的优劣，能够设计符合上述规则的消息提示

4.10 帮助系统设计

软件帮助系统不能是用户手册的简单复制

软件实现与验证

5.1 程序设计与调试

• 任务：把设计转换成程序以及在程序中去除错误，包括编程与调试两个过程
• 调试：程序要对自己开发的程序进行测试，程序中的一些明显的错误会被暴露出来并被根除

5.2 验证和有效性确认

• 验证：检查软件是否符合它的规格描述（不符合为“软件缺陷”）
• 有效性确认：检查软件是否满足客户的期待（要检查系统是否符合客户的真实愿望）

5.3 用来实现V&V目标的测试模型

• 缺陷测试
  • 目标：找出软件中的缺陷和不足，发现程序与规格描述之间的不一致性
  • 成功=找出了系统存在某个目前未知的缺陷
• 有效性测试
  • 目标：向开发者和用户证实系统满足了用户需求
  • 每个需求至少要有一个测试

5.4 V&V过程的两种基本方法

• 软件审查：通过对系统的各种静态成果进行检查和分析发现问题
• 软件测试：通过使用测试数据执行系统，检查运行结果来发现问题
• 测试的目的：揭示程序中存在错误
• 按照测试的不同目标可以把测试分成 有效性测试和缺陷测试
• 静态审查无法检验软件是否可用，也不能检验非功能需求，因此==程序测试是必不可少的，是起决定性作用的V&V技术
• 程序测试和静态审查通常是结合在一起使用的
• 测试和调试：测试和调试是不同的过程，通常交叉进行
  • 缺陷测试的目的是确定系统中存在缺陷
  • 调试考虑的是定位和修改缺陷
    

    5.7 软件测试阶段活动

    

  5.9 测试用例设计

  • 测试用例的基本构成：
    • 设计的输入
    • 期望的输出
    • 测试环境
    • 测试对象的描述
  • 通过设计输入数据和预计的输出来测试系统
  • 目的：建立一组测试用例集合，用尽可能少的测试代价有效的发现系统缺陷并证明系统能够满足需求
  • 常用方法：
    • 黑盒测试（功能测试）：划分测试与边界值分析
    • 白盒测试（结构测试）：结构化测试

  5.10 等价划分测试

  把数据输入域划分成若干等价类，等价类中的每个数据以同样的方式处理，因此对于揭露程序中的错误是等效的。这样就可以用较小的代价暴露较多的程序错误

  5.11 结构化测试

  • 根据软件的结构知识导出测试用例的测试方法
  • 目标：
    • 保证一个模块中的所有独立路径至少被执行一次
    • 对所有的逻辑值均需测试真假
    • 在上下边界以及可操作的范围内执行所有循环
    • 检验内部结构以确保其有效性
  • 相对黑盒测试，白盒测试能够发现更细小的缺陷

  5.12 逻辑覆盖法

  按照不同的测试目标，逻辑覆盖又可分为

  • 语句覆盖
  • 判定覆盖
  • 条件覆盖
  • 判定——条件覆盖
  • 条件组合覆盖
  • 路径覆盖
    其中，语句覆盖覆盖度最弱，路径覆盖最强

  5.13 基本路径测试

  分析控制结构的环路复杂度，并用这个复杂度为指南定义执行路径的基本集合，从而导出基本可执行路径集合，设计出测试用例并保证 每个可执行语句至少执行一次，而且每个条件在执行时都将分别取真假两种值
  

  

6.2 软件维护与维护成本

• 软件维护是指在软件交付使用之后，为了改正错误和满足新的需要而修改软件的过程
• 四种类型：
  • 纠正性维护
  • 适应性维护
  • 完整性维护
  • 预防性维护
• 维护成本
  • 维护成本一般会高于开发成本
  • 影响维护成本的有技术因素也有非技术因素
  • 开发阶段多投入有助于减少维护成本
  • 软件年龄越大，维护成本越高
• 影响维护成本的主要因素
  • 团队稳定性
  • 合同责任
  • 人员技术水平
  • 程序年龄结构

6.3 预防性维护/软件再工程

把今天的方法学应用到昨天的系统上，以支持明天的需求

6.4 软件再工程过程模型

• 这六种活动并非总以线性顺序发生
• 再工程范型是一个循环模型，其中的每个活动都可能被重复，且过程可以在完成任意一个活动之后终止

软件项目管理

7.1 软件项目管理基础

• 概念：为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动
• 目的：如何保证软件能够按时、按计划并满足用户需求规格的交付，即如何使用科学管理手段保障软件项目的成功

7.2 软件项目管理中的4P

• 人员
• 产品
• 过程
• 项目

7.3 项目策划任务集

1. 确定项目范围
2. 确定可行性
3. 分析风险
4. 确定所需资源
   a. 确定需要的人力资源
   b. 确定可复用的软件资源
   c. 标示环境资源
5. 估算成本和工作量
   a. 分解问题
   b. 使用规模、功能点、过程任务或用例等方法进行两种以上的估算
   c. 调和不同的估算
6. 制定项目进度计划
   a. 建立一组有意义的任务集合
   b. 定义任务网络
   c. 使用进度计划工具制定时间表
   d. 定义进度跟踪机制

弹性时间
网络图甘特图
关键路径上的关键任务无弹性时间
计算

7.4 软件项目的成本构成

• 硬件和软件成本
• 差旅费和培训费
• 工作成本（占比最高）
  • 项目开发人员的薪水
  • 社会保障和员工福利
• 经常性的管理费用
  • 办公场所、供暖和照明费用
  • 网络和通信费用
  • 图书馆、员工餐厅等方便设施的费用

7.5 项目进度安排

• 管理者需要把项目分解成若干个任务，并估算每个任务完成所需要的时间和资源，然后按照一定的顺序把这些任务组织起来
• 应协调并性任务，充分利用人力资源
• 要减少任务间的依赖，明确关键任务，保证按进度交付
• 项目调度过程
  
• 活动图与甘特图：掌握基本画法

7.6 配置管理

• 规定了：如何记录和处理所提议的变更，如何是系统变更与系统组件相关联，以及如何识别系统不同版本的方法
• 目的：控制由变更带来的成本和人力消耗
• 软件配置：
  • 概念：软件过程中产生的所有信息
  • 输出信息主要有三类：
    • 计算机程序
    • 描述计算机程序的文档
    • 数据
• 软件配置项：是在软件过程中置于配置管理之下的输出信息，通常表现为一组正式文档
• 基线：已经通过正式评审和批准的规格说明或产品，可以作为进一步开发的基础

来源：懒懒哇