软件配置管理
- 软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术，贯穿于整个软件生命周期。
版本管理
- 版本管理主要包括两个方面的工作：
- 一方面要规范化不同开发人员之间的合作方式，必须能够保证一个人的工作不会被其它人意外的覆盖；
- 另一方面是要确保每个人工作的对象是当前需要的版本而且能够为后续开发提供基础。
- 累进式的开发过程可能随时有一些新想法和实现，但随后又被抛弃掉，这就需要有方便回到先前工作状态的机制。
- 版本管理系统的核心工作是对项目软件或者项目文档的管理，把存储所有项目内容的数据库称为版本仓库（repository），版本仓库可以理解为一个存储着所有开发历史的数据库，与通常意义的数据库不同，它一般是在现有文件系统上的高效实现。
- 所有纳入版本仓库进行管理的各种软件资产统称为软件配置项，包括各种文档、数据以及代码等。
- 配置项在其生命周期的特定时间点上通过正式评审而进入正式受控的一种状态，称之为基线（baseline）。
- 作为配置管理的基础，基线可理解为软件配置项的一个稳定版本，基线为后续开发活动提供了信息的稳定性和一致性。
- 版本系统对于冲突问题的解决通常存在两种方法。
- 第一种方法被称为是悲观的方法，原理是第一个检出文件的人将会拥有对该文件的排它锁。好处在于能够保证一个文件只由一个人同时进行编辑并且不会导致任何的冲突发生。
- 第二种是乐观的方法，开发人员可同时对文件进行编辑，但涉及如何合并修改和冲突的解决。
- 版本系统与其它工具联合使用会发挥出更大的价值。
构建管理
- 构建（Build）管理系统的主要任务是描述最终软件产品的结构和生成过程。
- 对于小型的开发项目，构建系统的作用是调用编译器，然后根据编程语言的不同，使用不同的链接器生成可执行文件并执行。
- 对于大型的项目，在构建的构成中还要确保只有那些被修改的部分，才有必要进行重新编译和链接。除了编译这项主要的工作外，围绕文件的处理还有其他重要的任务，如目标软件在生成后应指定在系统中安装的具体位置等
- 借助命令行等工具进行手工执行，如Shell或Dos等
- 开发较为大型系统时，需要引入专门的Build管理工具，如C或C++常用的Make工具和Java中的Ant工具。
- 更大型的项目可引入持续集成来进行更为复杂的构建管理
- 在构建管理的应用领域，Ant和Make工具的主要作用：
- 提供边界条件的管理，如系统配置以及其它相关变量；
- 命令链的执行管理，其描述了从某些对象出发构建新对象的过程及其结果位置等。
发布管理
- 发布管理（Release）的主要作用是协调在合适的时间对合适的用户交付合适产品的保证。
- 软件资源、软件开发过程以及开发人员的分散化，导致软件发布管理的复杂化。
- 软件开发不是一蹴而就的过程。
- 发布管理是对项目管理的一个有效补充。
变更管理
- 软件生存周期内全部的软件配置是软件产品的真正代表，必须使其保持精确。
- 软件过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件过程的下一步骤。
- 软件变更管理包括建立控制点和建立报告与审查制度。
- 变更管理还包括对用户的确认以及使其随时掌握变更的进度以及细节，如责任人等内容。
项目计划与跟踪
项目计划
- 除了开发的方法、技术以及开发环境，项目管理是项目成功与否的又一重要因素。
- 与技术实现的关注点不同，项目管理主要关注组织和管理层面的内容。
- 项目计划实际上是一个对项目规模、工作量、成本、进度等方面的估算，同时将人员、时间、计算机资源等各类资源统筹安排，对项目的成功起到非常重要的作用。
- 准确且系统地评估出项目的实际成本几乎是不可能的，能够理解项目成本估算的方法并建立起估算过程的概念，并使得估算趋于准确。
- 项目经理在项目中处于一个核心的领导地位，他负责项目在整体上的计划、进度控制等工作，
工作分解WBS
- 在项目计划的开始，第一步是要决定哪些任务需要完成。这个工作可以通过一种叫做工作分解结构（Work Breakdown Structure，WBS）的机制进行展开，其中将任务按照层次的结构由上到下逐步进行分解，
- 每项工作任务同时也给出了对应的工作量，使用单位“人天（PD）”表示。
- 对每项工作包应存在两个评估值——期望的工作量和为潜在问题预留的缓冲量。
软件规模估算
- 项目成本的估算对于项目的成功起到非常重要的作用。
- 软件规模的估算可以基于分解的方法，项目可以按照WBS的方式分解为子项目。
- 评估方式采用“类比”的方法，即参照以往相似项目的实际工作量导出一个估算的结果。
- 一种系统化的评估方法是功能点分析，是一项可以进行认证的评估技术。
- 功能点分析需要准确的理解当前所有的用户功能，并尽可能的将每个功能归到以下的5种任务类型之中：
- 内部逻辑文件（ILF，内部数据）：在待开发系统内部处理的数据，如开发的类本身。
- 外部结构文件（EIF，引用数据）：从开发系统的外部引入并进行处理的数据。
- 外部输入（EI，输入）：从开发系统外部的输入，并由此对数据展开处理，如数据以某种格式约定（输入掩码）从系统外部的输入。
- 外部输出（EO，输出）：在待开发系统中实现业务计算结果外部的输出，比如数据以某种形式的输出格式（输出掩码）或对其它系统的错误消息输出。
- 外部查询（EQ，查询）：从外部系统发出的对数据信息的查询，对数据的查询格式、报告以及分析，不包括其它需要的附加- 计算。
- 然后对功能的复杂度进行考虑，简单的可以分为三个级别：容易、中等和复杂，分别赋予不同的权值。
- 接下来基于对各个功能点的估算结果利用一个模板计算出未调整（无权重）的功能点分值。
- 无权重的功能点力求对用户所有的功能需求进行评价，在大多数的评估方法中往往还需要考虑到一些影响因素，即该项目的一些约束或边界条件的影响。
- 将上述因素进行整理和归类，作为每个功能点的权值影响纳入计算，按照权重计算公式进行综合，然后作用于无权重功能点值，进而产生最终的有权重的功能点值。
开发成本估算：CoCoMo
- CoCoMo模型是模型的集合，根据项目的级别或种类选取其中不同的模型使用，这里主要针对项目开始的早期设计模型进行介绍。
- CoCoMo模型最大的用处在于提供工作量估算的公式（PM, person months），并以此作为项目计划调度和优化的基础，公式的基本形式为：
- Size是指不含注释的程序长度，又称为KDSI（Kilo-Thousands of Delivered Source Instructions），因此其基本的单位是千代码行。
- 公式中表示每个影响因子的变量EMi。
- 总体上：
- CoCoMo模型综合了对项目有较大影响的一系列边界条件
- 模型还提供了根据实际情况对影响因子进行调整的机会。
- CoCoMo模型实际的表现与评估者本身的经验也有着直接的关系。
任务安排与工程网络图（!）
- 为了更好的完善计划，除了需要合理的估算每个工作包的工作量外，还需要识别出彼此之间的依赖关系，即理清工作任务的优先级和顺序性。
- 工作任务之间的依赖关系可以通过工程网络图进行展现，其中没有给出最小和最大工作量，而是关注每个工作包持续的时间状况。
- 持续时间分析的好处是了解和掌握工作被分解到工作包后的并行情况。
- 确定最小持续时间的路径又被称为是关键路径，每个处于关键路径上的工作包如果遇到计划外的延期则意味着整个项目的拖延。（参考数据结构关键路径）
- 复杂项目计划中很重要的一个工作就是在关键路径上尽可能少的安排工作包，这样也能够在计划中为工作包产生更多的时间缓冲。
- 每个项目计划以及所有项目员工的总体分配方案是彼此依赖的复杂系统，不仅要使得员工的工作负担尽量均衡也要使得项目尽可能快的进展下去，这对项目的计划提出了更高的要求。
项目组织与甘特图（!）
甘特图
- 为了能够进行人员的安排，还要确定每个工作包对应的角色。
- 员工的素质和能力又会影响项目计划的调整，如进行必要的培训和指导。
- 项目计划要根据不同的条件和实际项目进行中的情况对计划进行适时的动态调整。
- 项目计划常使用甘特图（Gantt chart）图对计划进行描述，包括工作包、依赖、责任人、完成比例等。
- 实心菱形标识出里程碑的位置，表示在此位置可以对现有进度进行评审，并可根据需要对计划进行较大调整甚至终止项目。
- 内部里程碑，开发单位内部进行的进度评审；
- 外部里程碑，客户在此了解当前项目的进展并对产品进行部分的验收。
软件质量保证
- 时间、成本与质量在项目管理中常常相提并论。在这三个方面找到均可以满意的模式，并遵守这种模式，持续地进行管理工作是质量管理的最终目标。
- 质量管理的学派和观点：
- 戴明理论的核心是“目标不变、持续改善和知识积累”，预防胜于检验。
- 朱兰理论的核心思想是适用性，适用性是通过遵守技术规范，使项目符合或者超过项目相关人及客户的期望。
- 克鲁斯比理论的核心思想是质量定义符合预先的要求，质量源于预防，质量的执行标准是零缺陷，质量是用非一致成本来衡量的。
- 田口玄一核心思想是应用统计技术进行质量管理，通过损失函数来决定产生未满足目标产品的成本。
- 全面质量管理(TQM)是指通过全体员工的参与、改进流程、产品、服务和公司文化，达到在百分之百时间内生产百分之百的合格产品，以便满足顾客需求。
- 软件项目的质量管理指的是保证项目满足其目标要求所需要的过程，质量管理的关键是预防重于检查，事前计划好质量，而不是事后检查。
- 软件质量保证(SQA)包括：
(1) SQA过程；
(2)具体的质量保证和质量控制任务(包括技术评审和多层次测试策略)；
(3)有效的软件工程实践(方法和工具)；
(4)对所有软件工作产品及其变更的控制；
(5)保证符合软件开发标准的规程；
(6)测量和报告机制。 - 软件质量保证要素有：
- 标准：IEEE 、ISO及其他标准化组织制定的软件工程标准和相关文件。要确保遵循所采用的标准，并保证所有的工作产品符合标准。
- 评审和审核：技术评审是由软件工程师执行的质量控制活动，目的的是发现错误。审核是一种由SQA人员执行的评审，意图是确保软件工程工作遵循质量准则，