软件构造-第二章-第一节-软件生命周期和版本控制

一、软件开发基本过程

1.1 软件生命周期

1. 软件开发生命周期——从0到1
   • 策划阶段：获取需求、制定计划
   • 架构师：系统分析（业务领域，what）、软件设计（语言、架构，how）
   • 编码实现、测试
   • 维护直至消失

图1-1 软件开发生命周期

2. 软件生命周期中的多版本——从1到n
   • 运用版本控制技术实现迭代更新 图1-1 软件开发生命周期
     

二、传统软件开发过程模型

2.1 软件开发过程

1. 两种典型过程
    - Linear 线性过程
    - Iterative 迭代过程(大致为线性过程加反馈)

   
   

2. 典型开发模型
    - Waterfall (Linear, non-iterative) 瀑布过程(线性，不迭代)
    - Incremental (non-iterative) 增量过程(不迭代)
    - V-Model (for verification and validation) V字模型(用于验证和确认)
    - Prototyping (iterative) 原型过程(迭代)
    - Spiral (iterative) 螺旋模型(迭代)

   
   

3. 选择合适的过程模型的依据
    - 用户参与程度有多大？即软件适应变化的能力
    - 开发效率/管理复杂度
    - 开发软件的质量

2.2 瀑布模型

1. 瀑布模型：
    瀑布模型将软件生存周期的各项活动规定为依固定顺序而连接的若干阶段工作。
2. 特点：
    瀑布模型规定了每一个阶段的输入，以及本阶段的工作成果，作为输出传入下一阶段；早期主流开发过程，适用于需求稳定的项目。
    简述为：
     • 线性推进
     • 阶段划分清楚
     • 整体推进
     • 无迭代
     • 管理简单
     • 无法适应需求增加/变化
3. 优缺点：
    优点：有设计前的规约和编码前的设计，易于管理；
    缺点：应对变化时，成本十分高。
   图2-1 瀑布模型开发过程
   

2.3 增量模型

1. 增量模型：
    运用分治的思想，将需求分段，成为一系列增量产品，每个增量内部仍使用瀑布模型；
    增量模型是瀑布模型的变形，拥有后者的全部优点，此外可以很快的迭代出第一版本。因此，选择最核心需求首先实现显得十分重要。
2. 特点：
    • 线性推进
    • 增量式（多个瀑布的串行）
    • 无迭代
    • 比较容易适应需求的增加

图2-2 增量模型开发过程

2.4 V模型

1. V模型：
    V模型表示可以视为瀑布模型的扩展的开发过程。

2. 特点：
    • 弯曲工艺步骤，而不是以线性方式向下移动在编码阶段之后向上移动，以形成典型的V形。
    • 展示开发生命周期的每个阶段与其相关测试阶段之间的关系。
    • 水平和垂直轴代表时间或项目的完整性（从左到右）和抽象水平（最粗粒度抽象）
    • 强调测试，可通过测试展示阶段形成的结果。

   
   图2-3 V模型开发过程
   

2.5 原型模型

1. 原型模型：
    指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。
    其核心是用交互的，快速建立起来的原型取代了形式的、僵硬的（不允许更改的）大部分的规格说明，用户通过在计算机上实际运行和试用原型系统而向开发者提供真实的、具体的反馈意见。

2. 优点：
    • 软件设计者和实施者可以在项目早期从用户那里获得有价值的反馈。
    • 客户可以比较软件制作的软件是否符合软件规范。
    • 它还使软件工程师能够深入了解初始项目估算的准确性以及提出的最后期限和里程碑是否可以成功实现。

3. 迭代：
    开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。循环往复这个过程，直到用户满意为止。时间代价高，但开发质量也高。

图2-4 原型模型开发过程

2.6 螺旋模型

1. 螺旋模型：
    采用一种周期性的方法来进行系统开发。
    多轮迭代基本遵循瀑布模式，每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代。
2. 优点：
   • 设计上的灵活性,可以在项目的各个阶段进行变更。
   • 以小的分段来构建大型系统,使成本计算变得简单容易。
   • 开发测试阶段结合瀑布模型的阶段可控，计划阶段结合原型模型的需求变化。
3. 缺点：
   • 难适用长周期的开发过程。
   • 风险分析阶段要求有专业人员参与。

图2-5 螺旋模型开发过程

三、敏捷开发

3.1 敏捷开发

1. 定义：
   通过快速迭代和小规模的持续改进，以快速适应变化。

   
   

2. 敏捷宣言：

   • 人的作用 胜于 过程管理和工具的使用（结对编程）
   • 可运行的软件 胜于 面面俱到的文档
   • 客户合作 胜于 合同谈判
   • 响应变化 胜于 遵循计划
     

图3-1 敏捷开发过程

3. 敏捷开发12原则：

   • 通过尽早的、持续的交付有价值的软件来使客户满意。
   • 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
   • 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
   • 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
   • 围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
   • 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
   • 工作的软件是首要进度度量标准。
   • 敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
   • 不断地关注优秀的技能和好的设计会增强敏捷能力。
   • 简单—-使未完成的工作最大化的艺术—-是根本的。
   • 最好的构架、需求和设计出自与自组织的团队。
   • 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
     

4. 其他：

   • 要求极限的用户参与
   • 要求极限的小步骤迭代
   • 要求极限的认证、确认
   • 每个小迭代过程类似瀑布模型
     图3-2 敏捷开发与瀑布模型对比
     

3.2 极限编程

图3-3 极限编程过程

• 描述需求（利用story，情景对话表达用户需求）
• 设计阶段：做原型
• Coding：（TDD）测试驱动开发、结对编程、自动构建
• 测试阶段：持续集成、持续发布
• 冲刺模型
• 项目管理方式：任务墙、目标图

四、软件配置管理(SCM)

4.1 软件配置管理

1. 软件配置管理 Software Configuration Mgmt.(SCM)
    追踪和控制软件版本变化，包括代码、数据、文档和管理。

   
   

2. 配置管理的生命周期 Life Cycle of a Configuration Item(CI)
    随软件生命周期中的时间一起更新软件的所有组成部分，包括源代码，数据，文档，硬件，各种环境。

   
   

3. 软件配置项(SCI)及基线：

   • SCI是SCM的基本结构单元。
   • 基线：软件持续变化过程中的“稳定时刻”（例如：对外发布的版本）
   • 建立基线的原因： 重现性、可追踪性和报告。 图4-1 版本基线
     

4. 配置管理数据库(CMDB)

   • 配置管理数据库(CMDB)存储软件的各配置项随时间发生变化的信息+基线。
   • 配置管理数据库包含一个组织的IT服务使用的信息系统的组件的所有相关信息以及这些组件之间的关系。
   • 配置管理数据库提供一种对数据的有组织的检查和从任何想要的角度研究数据的方法。
     

4.2 版本控制(Versioning)

1. 版本及版本号：
    版本为软件的任一特定时刻（Moment）的形态指派一个唯一的编号，作为“身份标识”。
    在给定的版本号类别（主要，次要）中，这些数字通常按升序分配并对应软件的更新。

   
   

2. 版本控制重要性

   • 对个人来说：版本控制可以回滚到上一个版本；比较两个版本的差异；备份软件版本历史；获取备份；合并分支。
   • 对团队来说：可以在多个开发者之间共享和协作；记录每个开发者的动作，便于“审计”
     

3. 版本控制术语：

   • 仓库：即于SCM中的CMDB
   • 工作拷贝：在开发者本地机器上的一份项目拷贝
   • 文件：一个独立的配置项
   • 版本：在某个特定时间点的所有文件的共同状态
   • 变化：即code churn，两个版本之间的差异
   • HEAD：程序员正在其上工作的版本
     

4. 版本控制系统 Version Control System (VCS)

   • 本地版本控制系统(Local VCS)：仓库存储于开发者本地机器,无法共享和协作;
   • 集中式版本控制系统(Centralized VCS):仓库存储于独立的服务器，支持多开发者之间的协作;
   • 分布式版本控制系统(Distributed VCS):仓库存储于独立的服务器+每个开发者的本地机器。
     

五、Git作为配置管理工具

5.1 Git的整体架构

1. 四个仓库（本地有三个）

   • 工作目录(workspace)
   • 暂存区域(staging)（在menmory中，对用户不可见）（隐藏的.git文件夹中的stage，此目录并非真实存在）
   • 本地库(Local reposity)：源代码
   • 云端软件服务器(Remote reposity)（远程仓库） 图5-1 四个仓库及相互之间操作命令
     

2. Git仓库

   • git仓库的三部分：
     • .git目录，即本地CMDB
     • 工作目录，本地文件系统
     • 暂存区，隔离工作目录与Git仓库(物理上不存在)
   • 每一文件有三种状态：
     • Modified (已修改)
     • Staged (已暂存)
     • Committed (已提交)

3. Git中对象图结构

   • 每个结点保存：父结点、如提交时间的信息
   • CS还原差异，Git保存完整文件
   • Git对于重复文件，不复制文件，只修改指针
   • 减少冗余
   • 访问速度快

4. 分支代码

   • git(创建) branch(切换) -b(branch) iss53
   • git merge hitfix（合并）
   • git add把文件添加到暂存区，实际上就是把文件修改添加到暂存区；
   • git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
   • 关于Git的分支代码的详细解析请参考

5. 本地库和远程库

   • clone：将整个库完整的复制
   • fetch：将某一分支复制下来
   • push：将分支推送到服务器上
   • pull：将某一分支复制下来并合并在当前分支上

6. 传统VCS与Git对比：

   • 传统VCS记录文件改变情况。易对比不同版本中文件差异，但很难获取最后新版本情况，即很难创建分支。
   • Git：记录当前版本最新文件，不易获取变化，易获得当前版本文件。理论上可创建任意数量分支，且创建分支时间与git已有分支数目无关。 图5-2 传统VCS与Git对比
     

7. 注：

   • commit对象产生：commit命令；branch合并
   • git团队合作示例 图5-3 运用git的团队合作示例