三．配置管理

　　是什么

　　关于配置管理（Software Configuration Management-简称SCM）的概念在各类书籍中都能够看到，大部分的书籍都是从英文翻译过来的，而翻译书籍的人可能并不一定是和计算机学科有关联的，就算是也不一定在配置管理上有一定的经验。所以我想并不是每一个从事软件开发的人员都能够确切的理解它、把握它。概念的东西毕竟都是虚幻的，只有实际的运用了才能够变成自己的东西。

　　书上的定义我就不想说了，有兴趣的话大家可以去看书。我在这里想说说自己对于配置管理的看法和理解。配置管理可以简单地一句话说成是版本控制管理。而什么是版本控制，我想在使用计算机的人应该都会知道软件版本的概念，而我们的配置管理就是要对软件的版本进行控制管理。这个就是我们通常意义上说的配置管理了。而真正在团队开发中的配置管理并不仅仅是版本的控制管理，还应该涉及到代码协调、履历追踪、品质检查等等细节的问题。

　　为什么

　　为什么我们要在软件的开发过程中引入配置管理？其实不为什么，只是我们需要所以我们引入。在个人软件开发中只要你觉得你的水平够高，肯定不会发生Rollback，或者你只是在制作1+1=2这一类的简单程序时我想你也可能用不到配置管理。

　　在前面我也曾经提到过，软件的开发是team行为，是合作，而不是个人英雄主义的自我表现，不可否认在小项目上存在着个人软件开发，但是我想就算是个人软件的开发（简称PSP：Personal Software Programming-英文全称不知道是不是这样的，不大记得了）也不得不使用到配置管理。

　　有人把配置管理称为软件开发的一种艺术，以前在老外写的一本书上看到过，N多年以前的事情了，具体是什么书名已经不记得了。其实这样的说法也不算为过，配置管理就是对软件开发过程中的产品（这里为什么说产品，而不是代码，因为我们的软件开发还包括各类文档，会议记录等等）进行标识、追踪、控制的过程，目的就是为了减少一些不可预料的错误，提高生产率。

　　怎么做

　　怎么做就是要用到一些软件开发过程中使用的配置管理的工具了。大概在七十年代加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概念，之后他又成立了一家名为软件工具的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了软件配置管理的重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，早期比较有代表性的有：Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，这两种工具对日后的配置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。而如今我们最为常用的，且使用简单的要算VSS（Microsoft Virsual Source Safety）、CVS（Configuration Version System）了，此外还有一些价格昂贵、使用复杂的，比如：CCC Harvest、ClearCase等（需要一个专门的配置库管理员负责技术支持，还需要对开发人员进行较多的培训，可以说不适合我国的国情）。

　　VSS可能是国内目前使用的最多的配置管理软件之一，其实在国外很多的人都喜欢使用CVS。为什么，因为CVS是free的，而微软的VSS是要money的，为什么国内还是有很多人使用VSS，原因我想大家都明白我就不说了。

　　其实没有配置管理工具，我们手工也能对软件的配置进行管理，只不过很繁琐，浪费了大量的人力物力，所以我们使用配置管理工具，而要成为一个好的配置管理工具应该具备什么样的功能：
并行开发支持 - 要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制。（对于这一点来说可能CVS比VSS做的更好，如果VSS不使用辅助工具SOS（Source Offsite）的话，那个公司或者是团队会把自己的VSS库共享到Internet上）

　　履历管理 - 也就是修改的历史记录的可追踪性。能够明确地知道什么时候，谁作了什么，为什么怎么做。从而达到管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。
版本控制 - 版本控制中最重要的一个概念就是Rollback，能够简单，明确地取得软件开发期间的任何一个历史版本。

　　过程控制 - 能够贯彻、实施开发规范，包括访问权限控制、开发规则的实施等。
　　产品发布管理 - 软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发布版本，我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以至始至终管理、跟踪工件版本间的关联。

　　本来谈一点关于VSS和CVS的配置和应用的，可是想想写起来会很多，而且还要贴图什么的，够麻烦的所以等以后有兴趣了再补上。
 
　　四．风险管理

　　是什么

　　项目管理中最容易被忽略而且是最难以管理的环节。在很多的情况下，许多人都不知道风险管理到底应该做些什么。其实风险是自始至终贯彻整个软件的开发过程的，没有一个做项目的team可以自豪地声称自己的开发没有任何风险。

　　什么是软件开发过程中所谓的风险，简单地理解可以认为是对软件开发过程中遇到的资金和进度等问题对项目的影响。风险的产生常常会使我们的进度迟缓，成本增加，甚至是软件项目无法实现。

　　我们可能无法根除风险，但是我们如果加强对风险产生的认识，对项目产生的风险进行有效的管理，就可以从最大限度上减少风险的发生，而这个就是我们风险管理的主题了。

　　面对风险的态度

　　很多的项目组可能不大注重风险管理，往往是到了风险确确实实地发生了，才回过神来开始面对，采取紧急的补救措施，试图能够快速的纠正，而这种被动的“救火”模式的风险认识存在着极大的危险，就是当对于风险的扑救失败以后可能会使得我们的项目处于水深火热之中。个人认为这种扑救的行为有点类似于寓言上所说的“亡羊补牢”。这种被动的风险策略是不可取的。

　　既然提到了风险管理，我们就要在风险尚未产生、形成之前，对风险进行辨识，并且评估风险出现的概率已经它们能够产生的影响，按风险有高到底排序，有计划地管理。这种做法正好和“亡羊补牢”式的被动风险管理方式相反，我们在这里采取了主动出击，就是这样做，我们也并不能从根本上防止未知风险的产生，我们能做的只是减少风险发生的可能，所以说风险的管理和我们的认知以及经验有一点的联系。

　　风险管理的要件

　　在计划项目书中写清如何进行风险管理。
　　在项目的预算中必须包含风险解决所需要的经费，已经它们可能产生的影响。
　　认识到风险在整个项目中是一个连续的过程，需要在项目进程中不断地进行。
　　风险管理计划（风险如何识别，量化风险，应对策略，风险监控）