软件工程导论

软件工程概述

• 软件组成：

1. 程序：能够运行的、能提供所希望的功能和性能的指令集
2. 数据：支持程序运行的数据
3. 文档：描述程序研制过程、方法、使用的记录

• 软件危机：

1. 定义：在软件开发及维护过程中遇到的一系列严重问题
2. 产生原因：
   1. 软件的复杂性
   2. 过高的期望
   3. 无处不在的变化（这是软件开发不变的主题）

• 软件工程：

1. 定义：
   1. 从技术和管理两个方面开发和维护计算机软件
   2. 将系统化、可量化的工程原则和方法应用于软件开发、运行和维护，以及对其中方法的理论研究
2. 主要目标：高效开发高质量软件，降低开发成本
3. 知识体系：
   1. 开发过程：对软件的需求、设计、构造、测试、维护
   2. 支持过程：对软件的配置管理、工程管理、工程过程、工程工具与方法、质量
4. 基本原理：
   1. 用分阶段的生命周期计划严格管理
   2. 坚持阶段评审
   3. 严格的产品控制
   4. 现代程序设计技术
   5. 结果能清楚审查
   6. 开发小组人员小而精
   7. 不断改进软件工程实践的必要性
5. 软件开发：
   1. 传统方法/结构化方法：
      • 静态的思想
      • 将软件开发过程划分为若干个阶段，顺序性，分而治之
      • 缺少灵活性，即应对未预料变化的能力
   2. 面向对象的方法：
      • 动态的思想
      • 对象中封装实体的静态属性和动态方法，主动多次迭代
      • 逻辑关系在结构上稳定，降低模型复杂性，保证了阶段间平滑过渡

• 系统工程：

1. 定义：为了更好达到系统目标，对系统的构成要素、组织结构、信息流动、控制机构等进行分析与设计的技术
2. 目的：确保在正确的时间用正确的方法做正确的事
3. 开发的解空间：
   1. 综合使用 用例、静态、动态、架构建模
   2. 描述软件需求、分析、设计模型

• 统一建模语言UML：

1. 意义：它提供了一整套对系统建模的基础设施，包括模型的表示、建模的方法，适用于不同的系统层次
2. ：UML是一种语言、工具，而不是一种方法

软件开发过程/软件开发生命周期

• 意义：软件开发过程/软件生命周期 是软件产品开发的任务框架和规范
• ：包含多种具体的软件过程

• 阶段：

1. 可行性分析与开发计划：确定软件项目是否能够开发、值得开发
2. 需求分析：对未来需要完成的功能进行详细分析，输出一份需求规格说明书
3. 软件设计：寻求系统求解的框架，输出概要设计、详细设计说明书
4. 编码：将软件设计的结果翻译成计算机语言可实现的程序代码
5. 软件测试：发现问题并纠正
6. 软件维护：延续软件使用寿命，持续时间最长

• 分类：

1. 传统生命周期模型：

   1. 瀑布模型：
      • 特点：
        1. 文档驱动：静态的开发形式，仅当一个阶段文档编制好，通过评审后才能进入下一个阶段
        2. 推迟实现：仅当对系统充分理解并完成需求规格说明和设计规格说明后才展开编写工作
        3. 质量保证：坚持各阶段结束前的评审活动，及早发现解决缺陷
        4. 计划驱动，擅长对系统整体把控协调，适合规模较大的系统开发、分布式的开发模式
      • 问题：
        1. 仅在开发早期和结束时才能接触系统，增大系统反工风险
        2. 变化来得越迟，付出代价越大
        3. 无法灵活应对变化发生，应用上有局限性
   2. 快速原型模型：
      • 特点：
        1. 快速构造一个软件原型，“需求分析”变为“原型开发”
        2. 适合全新的系统开发，用户能借助原型系统建立对未来系统的认识，降低因需求不明确带来的开发风险
      • 问题：
        1. 开发技术和工具不一定是实际项目需要的
        2. 快速原型可能不符合开发规范之后被完全抛弃
   3. 增量模型/演化模型
      • 特点：
        1. 将软件开发的各个阶段视为一系列增量构件
        2. 模型的每个阶段交付一个满足客户需求的可运行的产品子集
        3. 适应变化需求，降低开发风险
      • 缺点：
        1. 加入构建不能破坏以构造好的系统部分，要求开放式的体系结构
        2. 容易退化为“边做边改”的模型，对软件过程的控制失去整体性
   4. 螺旋模型
      • 特点：
        1. 风险驱动
        2. 支持软件重用，善于将软件质量作为特殊目标融入产品开发，强调可选方法和约束条件
        3. 支持内部的大规模软件开发
      • 缺点：
        1. 难以要求客户接受风险分析、做出相关反应
        2. 可能因为风险分析太大影响项目利润
        3. 要求软件开发者擅长寻找并准确分析风险
   5. 喷泉模型：
      1. 阶段间的无缝性，表示方法一致性
      2. 具有更多增量和迭代性质，各个阶段可以重叠，可嵌入子生存期

2. 敏捷生命周期模型：

   1. 遵循同样的原则：
      • 个体和互动》流程和工具
      • 工作的软件》详尽的文档
      • 客户合作》合同谈判
      • 响应变化》遵循计划
   2. 迭代：
      • 单位：用例/用户案例/用户故事Use Case，指用户通过系统完成的有价值的目标，而不是一个具体的功能。一个用例是用户与系统的完整交互
      • 思想：先构建后修改，通过多重反复，找到客户真正需要的软件
      • 过程：从多个层次（必要性、灵活性、安全性、舒适性、趣味性）满足用户需求，支持用例，从而逐渐缩小功能的不确定性
   3. 特点：
      • 增量交付
      • 迭代开发
   4. 优势：精确、质量、速度、投资回报率、高效的团队

   5. 极限编程Extreme Programming, XP：

      • 目的：降低需求变化的成本
      • 编程方式：结对编程Pair Programming，是同行评审Peer Review的极端表现和替代方式
      • 原则：
        1. 互动交流：不局限于通过文档交流
        2. 反馈：客户的实际使用、功能测试、单元测试能提供反馈信息
        3. 简单：从简单的系统入手，只创建当前今天需要的功能模块
        4. 勇气：鼓励应对较高风险的良好做法，如频繁重构、删除过时代码
        5. 团队：团队合作，相互尊重
      • 最佳实践Best Practice：可用于开发活动的实践，包括一系列核心的做法
        1. 小规模，频繁的版本发布，短迭代周期
        2. 测试驱动开发Test Driven Development
        3. 结对编程Pair Programming
        4. 持续集成Continuous Integration
        5. 每日站立会议Daily Stand-up Meeting
        6. 集体拥有代码Collective Code Ownership
        7. 系统隐喻System Metaphor

   6. 迭代式增量软件开发过程Scrum：与XP相比：更注重软件开发的系统化过程

      • Stage1: Product Backlog 从一个简单的想法开始，逐步细化直到可开发的程度，分成多个产品需求积压条目
      • Stage2: Sprint Planning Meeting 最重要的产品需求积压优先安排到下一个Sprint周期中，预先估计所有已经分配到的产品需求积压工作量，并对每个条目进行设计和任务分配
      • Stage3: Sprint Period 有固定的时间长度，多个sprint组成开发过程
        1. Daily Scrum Meeting：每个成员汇报各自进展，提出障碍。结束后都会有一个可以被使用的系统交付给客户
        2. Sprint Review：开发团队向客户演示新功能，客户提出意见和需求变化，以新的产品需求积压的形式保留下来，下一个Sprint周期实现
        3. Sprint Retrospective：总结上次Sprint周期中的优缺点
      • 四种主要角色：
        1. 产品拥有者Product Owner
        2. 涉众Stakeholder
        3. 专家Scrum Master
        4. 团队成员Team Member

   7. DevOps过程：由开发和运维组成

      • 核心目标：
        1. 开发、技术运营、质量保证部门之间的沟通协作整合
        2. 自动化和可持续交付

需求分析

• 目的：搞清楚用户真正想要的系统是什么，存在哪些约束条件

• 需求分析活动：

1. 首先需要分析人员借助各种手段熟悉相关业务领域
2. 需求准备：
   1. 可行性分析活动：
      • 明确系统功能性需求、边界位置、是否能顺利进行、潜在风险、风险影响程度、应对措施，给出解决方案
      • 评估系统初步开发费用，这是签订商务合同的依据
   2. 给出一份需求规格说明书：
      • 客户主导制定的用户需求文档
        1. 阅读对象：委托方/客户
      • 开发者主导制定的系统需求文档
        1. 阅读对象：开发者
        2. 对用户需求的细化和完善

3. 系统涉众：概念很宽泛，可以是系统原始需求的人、委托方、最终用户等等

   1. 最终用户：系统的实际使用者，是目标系统的直接涉众
   2. 投资者/出资方：主要关心目标的总成本、建设周期、未来收益等高层目标
   3. 业务提出者：业务方高层人员，目标是使现有的业务更加规范和高效
   4. 业务管理者：中层管理者，负责业务计划、生产、监督等环节，对业务流程、业务规则、业务模式由较深的理解
   5. 业务执行者：实际操作人员，与系统直接交互的人员
   6. 第三方：对标准、协议、接口等起限制作用
   7. 开发方：受托方利益代表，关心项目是否由经济利益、积累核心竞争力等
   8. 法律法规：对未来软件产品使用范围、市场推广等起着较大作用

4. 系统目标：

   1. 意义：是软件开发的纲领，且与涉众紧密相关，影响对涉众的取舍
   2. 要求：将目标明确定义，说明对这些目标验证的标准