第三章 软件构造过程与配置管理
第三章 软件构造过程与配置管理
- 第三章 软件构造过程与配置管理
- Software Development Lifecycle(SDLC)软件开发生命周期
- From 0 to 1 从无到有
- From 1 to n 从有到好
- 传统软件开发模型
- 两种基本的方式
- 五种模型
- 选择模型的依据
- Agile Development（敏捷开发）
- 敏捷宣言
- 极限编程
- SCM和VCS
- 软件配置管理
- 版本控制和基线的建立
- CMDB ：配置管理数据库
- Git
- 实际的三个区域
- Git仓库的三个部分
- 文件的三个状态
- Object Graph
- 和传统的VSC对比
- git 命令
- 软件构建的一般流程
- (1) Programming
- (2) Review and static code analysis（代码评审）
- (3) Dynamic code analysis / profiling
- (4) Debugging and Testing
- (5) Refactoring
第三章 软件构造过程与配置管理
Software Development Lifecycle(SDLC)软件开发生命周期
From 0 to 1 从无到有
From 1 to n 从有到好
传统软件开发模型
两种基本的方式
线性过程
- 用户需求要明确，不易更改
迭代过程
- 各阶段给用户反馈确定需求
五种模型
瀑布过程（Waterfall (Linear, non-iterative)）
在概念、启动、分析、设计、构建、测试、实施和维护阶段，进展被视为稳步向下流动（如瀑布），易于使用，但事后更改代价高昂。
特点
- 线性推进
- 阶段划分清楚
- 整体推进
- 无迭代
- 管理简单
- 无法适应需求增加/变化
增量过程（ Incremental (non-iterative)）
切成小模块，每次开发一个小模块
要求
- 每个小增量都能单独运行
- 新开发的不能影响之前开发的
特点
- 线性推进
- 增量式（多个瀑布的穿行）
- 无迭代
- 比较容易适应需求的增加
V字过程（V-Model (for verification and validation)）
每个阶段进行验证测试
原型过程（Prototyping (iterative) ）
先开发一个原型(一般是一个可运行的界面)，供用户评价，在圆形的基础上不断地迭代发现用户变化的需求，如果原型不好也可抛弃
优点
- 开发者早期可以从用户获得有价值的反馈
- 开发质量高，但时间代价高
- 适应用户的变化
缺点
- 未经过整体分析设计，整体架构不好
螺旋模型（Spiral (iterative)）
非常复杂的过程：
- 多轮迭代基本遵循瀑布模式
- 每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代
适用于大程序，风险不确定的程序，高质量的程序
选择模型的依据
- 用户参与程度有多大？–适应变化的能力
- 开发效率/管理复杂度
- 开发出的软件的质量
Agile Development（敏捷开发）
- 通过快速迭代和小规模的持续改进，以快速适应变化。
- 适用于需求不稳定的程序，当需求不稳定时，敏捷模型大于原型模型
- Agile = 增量 + 迭代，每次迭代处理一个小规模增量
- 极限的用户参与，极限的小步骤迭代，极限的确认 / 验证
敏捷宣言
- 不注重文档
- 适应变化，而不是遵循合同
- 客户参与开发过程中
- 每天团队交互
极限编程
- 列出需求不要文档，先写测试，编程目的是过测试。
SCM和VCS
Software Configuration Management (SCM) and Version Control System (VCS)
软件配置管理
- 追踪和控制软件的变化
- 软件的任何组成部分（源代码、数据、文档、硬件、各种环境）都可能随着软件生命周期中的时间而更新。
- 软件配置项：软件中发生变化的基本单元（例如：文件）
版本控制和基线的建立
版本控制
为软件的任一特定时刻（ Moment ）的形态指派一个唯一的编号，作为"身份标识"
为什么需要版本控制
- 回滚到上一个版本
- 比较两个版本差异
- 备份软件版本历史
- 获取软件备份
- 合并版本
- 多个开发者之间共享和协作
- 记录每个开发者的动作，便于“审计”
版本控制的术语
- Repository 仓库：即于SCM中的CMDB
- Working copy 工作拷贝：在开发者本地机器上的一份项目拷贝
- File 文件：一个独立的配置项
- Version or revision 版本：在某个特定时间点的所有文件的共同状态
- Change or diff 变化：即code churn，两个版本之间的差异
- Head 程序员正在其上工作的版本
版本控制方法
Local VCS（本地版本控制系统）
- 仓库存储于开发者本地机器
- 无法共享和协作
Centralized VCS （集中式版本控制系统）
- 仓库存储于独立的服务器
- 支持多开发者之间的协作
Distributed VCS（分布式版本控制系统）
- 仓库存储于独 立的服务器 + 每个开发者的本地机器
- 难同步
基线的建立
- 基线：软件持续变化过程中的“稳定时刻”（例如：对外发布的版本）
CMDB ：配置管理数据库
- 存储软件的各配置项随时间发生变化的信息+基线
Git
实际的三个区域
- workspace
- Local repository
- Remote repository
注意：staging只是将文件打上标签
Git仓库的三个部分
- .git directory 本地的CMDB
- 工作目录：本地文件系统
- 暂存区：隔离工作目录和Git仓库
文件的三个状态
- 已修改
- 已暂存
- 已提交
Object Graph
版本之间的演化关系图
一条边 A->B 表征了"在版本 B 的基础上作出变化，形成了版本 A "
有向无环图
历史图中的每个节点都是项目的一个提交，是该时间点所有文件的完整快照。
- 除了初始节点，每个commit指向一个父亲
- 多个commit指向同一个父亲：分支
- 一个commit指向两个父亲：合并
只存储变化的文件，不变的文件存的是文件指针
和传统的VSC对比
传统VCS
- 存储版本之间的变化（行）
Git
- 存储发生变化的文件，不变化的文件不重复存储
git 命令
git checkout -b xx 创建并切换分支
git checkout -d xx 删除分支
git checkout xx 切换分支
git merge xx 合并到当前分支，注意原分支还在
git commit
git fetch origin 一定要先获取最新版本
git push origin xx
示例
软件构建的一般流程
(1) Programming
Construction languages
从用途上划分
编程语言（C,C++）
建模语言（例如UML）
配置语言（XML,JSON）
- 配置程序
构建语言（XML）
从形态上划分
- 基于语言学的构造语言
- 基于数学的形式化构造语言
- 基于图形的可视化构造语言
Programming tools
集成开发环境
- Source code editor with intelligent code completion, code refactoring tool 源代码编辑器、智能代码补全工具、代码重构工具
- File management tool 文件管理
- Library management tool 库管理
- Class browser, object browser, class hierarchy diagram 软件逻辑实体可视化
- Graphical User Interface (GUI) builder 图形化用户界面构造器
- Compiler, interpreter 编译器、解释器
- Build automation tools 自动化build工具
- Version control system 版本控制系统
- Extensible by more external third-party tools 外部的第三方工具
(2) Review and static code analysis（代码评审）
旨在发现在初始开发阶段被忽视的错误，提高整体质量
形式
Formal code review 正式的代码评审会议
Lightweight code review 轻量级的代码评审
- 两个人一起编程Pair programming
Static code analysis 利用工具进行的静态代码分析
- 该过程提供了对代码结构的理解，有助于确保代码符合行业标准。
- 自动化工具可以帮助程序员和开发人员进行静态分析。
目的
- 改进代码
- 提升程序员，相互学习
(3) Dynamic code analysis / profiling
- 动态分析：要执行程序并观察现象、收集数据、分析不足
- 对代码的运行时状态和性能进行度量，发现代码中的潜在问题
(4) Debugging and Testing
- 测试：发现程序是否有错误
- 调试：定位错误、发现错误根源
(5) Refactoring
- 重构：在不改变功能的前提下优化代码（不改变外部行为的前提下改善内部结构）
- 重新排列代码，进行一系列小的、保留语义的转换，让代码更易于维护和修改
第三章 软件构造过程与配置管理相关推荐
- 【软件体系结构】考点总结 第三章 软件体系结构风格 XJU
软件体系结构 第三章 软件体系结构风格 前言 本文为XJU本科期间博主根据 <软件体系结构原理.方法与实践>第二版所作的期末考点总结,因为是课堂重点总结,所以有些重要知识点没有涵盖还请 ...
- HIT 软件构造 过程、系统、工具
软件构造的一般流程 编码,重构,调试,测试,性能分析,代码评审,构建,发布 coding 从用途上划分:编程语言.建模语言.配置语言.构建语言 从形态上划分:基于语言学的构建语言.基于数学的形式化构造 ...
- 《软件质量保证与测试》学习笔记【第三章 软件测试过程所需技能】
目录 第三章 软件测试过程所需技能(软件测试计划书) 前言 3.1软件测试计划 1.软件测试计划书的定义 2.软件测试计划的作用 3.如何制定软件测试计划 4.IEEE测试计划模板 第三章 软件测试过 ...
- 1-1 软件构造过程中的多维视图
本节目标: 本节大纲: 随着时间的推移,人们对软件的认识的变化: 软件不能脱离外部环境: 软件构造的多个维度: 时间:瞬时(某一天某个时间点).周期(变化情况) 编码:构建开发(代码的结构.多少类.类 ...
- 《软件工程》第三章——软件设计综述
1. 软件设计的任务与目标 任务和目标:以软件需求规格设计说明书为依据,根据其提出的系统目标,进行数据设 计(数据结构),系统结构设计(软件系统的体系结构),过程设计(吧结构转换为软件的过程性描述), ...
- 【软件构造】第一章 软件构造基础（1）
一．软件构建多维视图 1. 什么是软件 (1)构成 ·程序Program:UI, Algorithms, Utilities, APIs, test cases, etc ·数据Data:files, ...
- 【软件构造】课件精译（三）软件生命周期与配置管理
一.本章概述 1.软件开发的生命周期 2.传统软件开发模型(瀑布模型.增量模型.V模型.原型法.螺旋模型) 3.敏捷开发和极限编程 4.协同软件开发 5.软件配置管理 6.Git 7.总结 二.本章目 ...
- 构建之法第三章软件工程师的成长
1.现在的我以及我的同学们都还不能够被称之为软件工程师,在各个方面我们都有很多的不足,与那些计算机大佬相比我们也就是大菜鸟,所以我会朝着自己的目标努力. ①我会选择C,但是我希望无论他的技术有多么娴熟 ...
- 第三章 软件需求分析
软件需求分析是软件开发期的第一个阶段,基本任务是准确地回答"系统必须做什么?"这个问题.软件需求分 析是整个系统开发的基础.在此阶段结束前,系统分析员应该写出软件需求规格说明书( ...
最新文章
- 如何设置VSS源代码管理工具使用KDiff3
- Cordova各个插件使用介绍系列（七）—$cordovaStatusbar手机状态栏显示
- 【TarsosDSP】TarsosDSP 简介 ( TarsosDSP 功能 | 相关链接 | 源码和相关资源收集 | TarsosDSP 示例应用 | TarsosDSP 源码路径解析 )
- CPU 以字节为单位编址，而 C 语言指针以指向的数据类型长度作自增和自减。
- 拓扑排序排课系统_视频结构化人脸布控系统
- 前端面试题集锦（二）之CSS部分
- vim显示行号_使用 vim 不得不看的 2 个 tips
- 填表法解“银行家算法”问题
- Ubuntu镜像源下载
- 微软终于屈服和妥协：宣布加入 OpenJDK，贡献构建Java生态
- 多线程与多进程(4)
- 精通JavaScript系列目录
- CAD三维图自动生成三视图
- 巧配交换机防止同网段ARP***典型实例
- 车内看车头正不正技巧_科二曲线行驶技巧图解，蜀黍手把手教你过关！
- options请求(复杂请求)
- 分享b2b2c带商家入驻中英繁多语言海外电商带商品库一键铺货商城源码
- java多线程实现动态效果_java多线程实现礼花绽放的效果，
- 论文写作: 实验效果不好怎么办?
- 股票中的做T的是什么意思？