软件生命周期和配置管理
一、软件开发生命周期（SDLC）
1、从0到1
计划 分析 设计 实施 测试 维护
2、从1到n
很多个版本
二、传统的软件过程模式
两种基本类型：
1、线性
2、迭代
不同模式的关键质量考虑因素：
1、用户的参与（适应变化）
2、发展效率，软件管理的复杂性
3、软件的质量
现有的模型：
瀑布模型、v模型、增量模型、原型法、螺旋模型
三、不同模型的介绍和比较
1、瀑布型
瀑布模型又称为经典生命周期，他提出了一个系统的，顺序的软件开发方法。通过概念，启动，分析，设计，施工，测试，实施和维护最终提供完整的软件支持
缺点：1、实际项目很少遵循该顺序，虽然线性模型可以加入迭代，但是它是用间接的方式实现的，容易造成混乱。
2、客户难以清楚的描述所有的需求，而瀑布模型要求客户明确的需求，很难适应许多项目在开始阶段的不确 定性。
3、客户要有足够的耐心，只有在项目接近尾声的时候才能得到可执行程序。对于系统存在的重大缺陷，如果 在可执行程序评审之前没有得到发现，将可能造成很大的风险。
4、在某些项目中会导致阻塞状态，由于任务之间的依赖性，开发团队一些成员要等待另一些成员工作完成， 等待时间可能超过花在工作生产上的时间
2、v型
瀑布模型的延伸
v模型描述了质量保证工程与沟通、建模以及早期构建相关工程的关系。随着沿着v模型左侧步骤向下推进，基本问题需求逐步细化，形成了对问题及解决方案的详尽且技术性的描述。一旦编码结束，团队沿着v 模型向上推进，本质执行了一系列测试，这些测试验证了团队沿着v 模型左侧向下推进时所生的每个模型。实际上v 模型和瀑布模型没有本质上的区别。但是v模型提供了一种将验证和确认动作应用于早期软件工程工作的直观方法。
3、增量模型
在许多情况下，初始的软件需求有明确的定义，但是整个开发过程却不宜单纯运用线性模型。同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。在这种条件下，需要选用一种以增量的形式生产软件产品的过程模型。例如，采用增量模型开发文字处理软件，在第一个增量中提供基本的文件管理、编辑和文档生成功能;在第二个增量中提供更为复杂的编辑和文档生成功能;在第三个增量中提供拼写和语法检查功能;在第四个增量中提供高级页面排版功能。需要注意的是，任何增量的过程流都可能使用下一节中讨论的原型范型。注：如果你的客户要求你在一个不可能完成的时间内提交作品，那么向他建议届时肢体叫一个或几个增量，此后再提交其他的几个增量
4、原型模型
很多时候，客户定义了软件的一-些基本任务，但是没有详细定义功能和特性需求。另一种情况下，开发人员可能对算法的效率、操作系统的适用性和人机交互的形式等情况并没有把握。但是通常情情况下，采用原型开发范型(prototyping paradigm)是最好的解决办法。虽然原型可以作为一个独立的过程模型，但是更多的时候是作为一种技术。当需求很模糊的时候，原型开发模型都能帮助软件开发人员和利益相关者更好地理解究竟需要做什么。原型开发范型开始于沟通。软件开发人员和其他利益相关者建议定义软件的整体目标，明确已知的需求，并大致勾画出以后再 客户有一个合理进一步定义的东西。然后迅速策划一个原型开发选代并进行建模(以“快 的要求，但是对速设计”的方式)。快速设计要集中在那些最终用户能够看到的方面(比如细节）。没有思路，那么不妨先开发。快速设计产生了一个原型。对原型进行部署，然后由利益相关者进行评估。根据利益相关者的反馈信息，进一步精炼软件的需求。在原型系统不断调整以满足各种利益相关者需求的过程中，采用迭代技术，同时也使开发者逐步清楚用户的需求。
5、螺旋模型
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害.风险驱动。
四、敏捷开发和极限编程（xp）
敏捷开发宗旨：
一：个体及交互比流程与工具更具价值
二：可用的软件比冗长的文档更有价值三：与客户的协作比合同谈判更有价值
四：对变化的响应比遵循计划更有价值
十二个原则：
1.我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
2.即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3.经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5.围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
7.可运行软件是进度的首要度量标准。
8.敏捷过程提倡可持续的开发速度。责任人(sponsor). 开发者和用户应该能够长期保
持稳定的开发速度。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
10.简单一使不必做的 工作最大化的艺术一是必 要的。
11.最好的架构、需求和设计出自于自组织团队。
12.每隔-定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。
并不是每一个敏捷过程模型都同等使用这12项原则，一些模型可以选择忽略(或至少
淡化)一项或多项原则的重要性。然而，上述原则定义了一种敏捷精神，这种精神贯穿于本
章提出的每一个过程模型。
极限编程：
极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、此外还扩展了第五个价值观：谦逊（Modesty）。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。
主要要求：1、配对编程 2、任务版和进度控制
五、软件配置管理（SCM）
1、scm在软件中的任务是跟踪和控制软件的变化。
2、SCM的做法包括版本控制和设置基线。
3、为什么要进行版本控制（SCM）？
对于个人：
恢复到过去的版本；
比较两个不同的版本；
将完整版本历史记录推送到其他位置；
从该版本撤回到历史版本；
对于团队合作：
在多个合作者中间通信分享合并工作；
记录不同开发人员的个性化作品以进行审核；
4、cmdb（配置管理数据库和签入迁出审核）
5、基线
在计算机术语中，基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
6、（1）本地版本控制系统（LVCS）——本地完整仓库（少用）
简介：在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版 本的文件内容。大多数采用某种简单的数据库来记录文件的历次更新差异。
优点：简单、很多系统中都有配置
适合管理文本文件
缺点：不支持网络
支持类型单一
（2）集中式版本控制系统（CVCS）——服务器完整的仓库
简介：有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
优点：适合多人团队协作开发
代码集中话管理
缺点：单点故障
必须连网操作，无法单击本地工作
（3）分布式版本控制系统（DVCS）——本地和服务器都有完整的仓库
简介：客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
可以指定和若干不同的远端代码仓库进行交互。这样，你就可以在同一个项目中，分别和不同工作小组的人相互协作。
最常用：Git、Mercurial（HG）
优点：适合多人团队协作开发
代码集中化管理
可以离线工作
每个计算机都是一个完整仓库
7、版本控制特点
a， 可靠：只要我们需要，就可以保持版本不变; 允许备份；
b,多个文件：跟踪项目的版本，而不是单个文件
c,有意义的版本：有什么变化，他们为什么做？
d,恢复：全部或部分恢复旧版本
e,比较版本
f,审查历史：整个项目或个人档案
g,不仅仅是代码：散文，图像......
h,它应该允许多个人一起工作：
- 合并：结合与以前的通用版本不同的版本
- 跟踪责任：谁做了这个改变，谁触及了那行代码？
- 并行工作：允许一个程序员自己工作一段时间（不放弃版本控制）
- 工作进行中：允许多个程序员共享未完成的工作（不中断别人，不放弃版本控制）