这一章我们主要学习了团队和流程。团队简而言之就是开发一个软件工程的团队，那么团队究竟怎样在一起开发这一软件便有了多种多样的方法。

比如所有人都一起做的一窝蜂模式，但这样模式弊端很大，虽然都做了许多工作，但结合起来的成果可能还没有单人做的进度快。慢慢的发展出了一些其他的模式，比如我们在学校中，一个学霸主力，其他人打酱油，但这并不好。之后也出现了明星模式，社区模式等更好的模式

写了再改模式：这种便是我们学生中最为普遍的一种模式。不管代码怎么样，先写出来，甚至连语法错误都没有考究，整体做完后再针对问题进行修改。这种方法看似简单，但实际并不高效，会在查找和修正错误上浪费许多时间。对于以后工作中，复用性高，规模打的软件开发而言，这种模式显然不合理。

瀑布模型：瀑布模式就像其他行业的流水线一样，单向，有条理，规范性强，但它的不可逆性会很大程度上影响软件的后期功能扩充和维护。但如果产品需求明确，并且开发把握度高的情况下，这种模式也是可以采用的。不过对于那些用户需求不明确，需求扩展度较高的项目来说，采用瀑布模式就不能满足开发需求

Rational统一流程，即后面的统一建模：统一建模是近年来发展起来的一种软件设计模式，通过需求分析，建立多个模型，设计，最终实现软件的开发，已经是一种较为成熟的软件开发手段。它主要有以下四个阶段：

初始阶段——此阶段的目标是分析软件系统大概的构成，系统与外部系统的边界在哪里（我们的系统究竟和什么别的外部实体打交道），大致的成本和预算是多少，系统的风险主要来自哪里。成功度过初始阶段的项目会达到生命周期目标（LifecycleObjective）里程碑

细化阶段——它的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可扩展性等非功能需求。同时为项目建立支持环境，包括创建开发案例、创建模板并准备工具。细化阶段结束时，项目到达了第二个重要的里程碑：生命周期结构（Lifecycle Archi-tecture）里程碑

构造阶段——在这一阶段，团队开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。构造阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。此时的产品版本也常被称为“beta”版

交付阶段——这时候，团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代（beta1，beta2等），基于用户的反馈，团队利用这些迭代对系统进行修改、调整。除了对功能的调整，团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑

构建之法第五章读书心得