TAO[三] 第二章 项目管理框架

第一章  项目管理框架

　　TAO模型是一个实践模型，它能够直接映射到软件项目的实际中去。在本章中，定义了软件项目的管理框架，主要包括项目生命周期、人员组织，流程规范等方面内容。最后，再花一节的篇幅，来着重阐述TAO模型是如何被映射到实际项目中去的。

1                人员组织结构

　　软件的生产过程，人员是非常重要的方面。它在很大程度上决定了项目的成败。在TAO模型中，给出了项目执行过程中的各类人员的定义。在后面的描述中，涉及到人员参与时，引用此处的人员角色定义。
1.1               客户

　　客户，是指最终软件项目拥有者以及使用者。将来软件的拥有者与使用者决定了项目的两个重要方面：软件价值的确认与实现。拥有者对于软件的接收确认了软件的价值，而使用者在日常工作中的使用，真正使得软件价值得以发挥。
1.2               项目经理

　　在这里，项目不是一个职务名称，而是一个角色名称。它是指能够调动已分配给项目的所有资源，使其为项目服务的人员。

　　有很多项目中，项目经理并不具有充分调动已分配给项目的资源的权力。所以说，这时，即使他被称之为项目经理，也不符合此处的定义。根据这样的定义，有很多企业的研发部经理，甚至小软件公司的老总，在部分地承担着项目经理的角色。

1.3               分析人员

　　分析人员，协同客户发现需求，特别是隐含需求，并将其文档化。

　　需要注意的是，分析人不是在做翻译工作，而更多地是记录工作。并且，他能够从用户反映的需求点中，找出各项需求点的联系，发现需求与需求之间的缝隙，从而揭示出用户所忽略的需求。

　　分析人员不能创造需求，只在必要的情况下，改变需求的描述方式。任何由分析人员发现的需求，或者分析人员对于需求的描述方式做的任何变动，都需要与客户进行沟通，并得到确认。
1.4               设计人员

　　设计人员的职责分为两部分：将用户业务领域需求，翻译为技术领域的需求；根据具体的开发技术，定义软件的技术细节。

　　设计人员是对于用户需求的第一次翻译。在其工作过程中，分析人员有责任验证其翻译的准确性。在必要和可能的情况下，客户可以适当参与。

　　设计人员不能够修改需求。即使在设计过程中，发现了需求的缺陷，也只是将其记录下来，由分析人员去处理。

　　而工作的第二部分，也就是详细设计部分内容。在这一过程中，技术上的需求将会被基于具体开发技术定义的软件所实现。
1.5               开发人员

　　开发人员完成设计人员所设计的基于开发技术定义的技术细节，到代码的转换。

　　一般而言，在分析人员完成详细分析之后，需求已经被分解为一个个小的，用软件规格说明书定义好的开发语言元素，比如类、函数、属性等。而这时，开发人员的工作就是将这些规格说明书实现反映到代码中去。
1.6               测试人员

　　测试人员是用于验证项目各阶段执行过程中，每一次翻译的准确性。

　　单元测试用于验证开发人员将软件规格说明书翻译成代码的准确性。

　　系统测试用于验证分析人员将需求翻译成系统设计的准确性。

　　集成测试与接收测试，是用于验证分析人员将用户业务需求记录下来的准确性。

　　在项目中，并不是只有职位名称为测试工程师的，才是测试人员。比如，客户执行接收测试时，此时，客户就扮演了测试人员的角色。
2                软件生命周期

　　软件项目是有生命周期的。

　　常见的生命周期划分为：分析、设计（包括概要设计与详细设计）、开发、测试（包括单元测试、系统测试、集成测试以及接收测试）、用户手册与培训、部署、维护这样几个部分。
2.1               分析

　　分析是明确用户需求的过程。简单地说，也就是弄清楚用户想要什么样的软件。通常意义上讲，我们都同意这一阶段是非常重要的，因为需求不正确，后续的工作就是无本之木、无源之水。

　　而需求往往又是最难明确的。从静态角度来讲，客户往往对于需求的描述是概要的，不完全的，他们往往关注于事情的一些重要方面，而忽略细节；从动态角度来讲，因为客户方实际业务的变化，需求也在不断地发生着变化。

　　因为需求变化的客观存在，在TAO模型中，对于需求的预设前提是：
　　在项目执行的任何一个时间点，需求都可能发生变化。
2.2               设计

　　如果说在分析阶段，是试图用用户能够理解的语言来描述需求。那么，在设计阶段，则是将需求翻译成技术人员能够理解的内容。而这个翻译的工作，是由设计人员来完成的。

　　因为在项目执行的任何一个时间点，需求都可能发生变化，那么，就意味着，在项目的任何一个时间点，项目的设计都可能发生变化。

　　设计包括概要设计与详细设计两部分。通常而言，概要设计是对于需求的第一次翻译，它将需求直接映射为技术上性定义，而不涉及这些技术定义如何被实现。详细设计是对概要设计的再一次翻译，也就是对于需求的再次翻译。经过详细设计之后，需求中的内容在已经以文档的形式实际可行。经过这一阶段之后，开发人员已经能够开始着手为实现需求而编写代码了。
2.3               开发

　　开发是对于需求翻译的最后一步。这最后一步，就像是"一次惊险的跳跃"，实际需求到实际产品的转化。

　　需要说明的，完全规范的开发工作，是应该完全依照详细设计文档的规定进行的。但是，由于在传统的开发模式下，详细设计文档与代码之间的同步，是一个工作量非常大而繁锁的工作，以致于常常出现代码与详细设计文档不一致的情况。

　　TAO模型很好的解决了这个问题。详细设计文档与代码，在项目执行过程中的任何时刻，都保持着完全的一致性。
2.4               测试

　　测试主要有四种：

　　单元测试

　　单元测试是在开发人员完成项目的代码编写之后进行的。它是用于验证某一代码片断的正确性。

　　系统测试

　　系统测试是在一个具有业务逻辑意义的部分完成之后，执行的测试。它是用于验证某一个业务逻辑是否被被正确的实现。系统测试规模可大可小，根据实际需要决定其规模。

　　集成测试

　　集成测试是在系统开发完成之后，用于验证当前系统与软、硬件环境以及其它软件互操作的协调性。

　　接收测试

　　与前面的测试不同，接收测试由软件的用户执行，而开发方提供协助的方式进行。它是由客户来验证系统最初设定的需求是否被实现的一种方式。
2.5               用户手册和培训

　　用户是需求的提出者，而项目组是需求的解决方案的提供者，最后，用户是需求的解决方案的使用者。只有当用户真正学会如何使用项目组提供的软件去解决业务中的问题时，软件才真正变得有价值。

　　一个好的用户手册，与组织良好的培训，是实现软件项目目标的重要保证。
2.6               部署

　　部署就是将软件部署到工作环境中去。

　　对于项目执行控制得很好的软件系统而言，部署只是一个简单的步骤。而对于很多管理不是很规范的项目而言，部署却是一个真正意义上的冒险，每天都在担心是否有新问题出现。
2.7               维护

　　在部署成功之后，软件进行维护状态。对于维护期的项目，开发方的责任就是使其达到规定的可用状态。
3                项目执行过程模型

　　软件技术发展这些年来，已经有了很多成熟的软件执行过程模型。常见的如瀑布式等。而在TAO模型中，项目的执行过程是一种被为迭代模型。更为详细情况，参见作者写的《迭代式项目执行框架》一书。

　　正如TAO模型远景中所描述的一样，在TAO模型下执行的项目，分析、设计、开发、测试、文档化都是实时同步完成。这就意味着，在项目的各个阶段，分析、设计、开发、测试及文档化的工作都在不同程度的开展着。所以，瀑布式模式中，只有在分析完成才能设计，设计完成才开发的模型就显得不适用。

　　迭代式项目执行框架

　　迭代式项目执行框架（IPEF: Iterative Project Execution Framework）是一个迭代框架。每一次迭代结束之后，项目都向前演进了一层。在本小节中，给出该框架的一个简要说明。

　　顾名思义，在迭代式项目执行框架中，项目的执行是通过一次次迭代展开的。在IPEF中，简单地分法，可以分为以下几个迭代：
3.1               第一次迭代：关注分析

　　第一次迭代，基本上对应于传统项目生命周期的分析阶段。与之不同的是，在此迭代中，分析人员、开发人员与测试人员已经介入工作，同时，文档化工作也在同步展开。

　　在此步迭代中，参与项目的各角色分工为：分析人员获取用户需求；分析人员确定需求的可实现性，并识别出项目的主要技术风险；开发人员开发项目原型，或代码示例，用于解决分析人员识别出来的技术风险；测试人员验证需求的可测试性，并给出接收性测试的计划。

　　在这一阶段中，分析是重点。当用户确认已知需求已被文档化后，此次迭代即告完成。

3.2               第二次迭代：关注设计

　　第二次迭代，在用户确认需求已被文档化后，即告开始。其工作内容，基本对应于传统生命周期理论的设计阶段。

　　在此步迭代中，参与项目的各角色分工为：分析人员评审设计人员设计的完整性；设计人员进行设计工作；开发人员验证设计的可实现性，并根据需求开发原型；测试人员验证设计的可测试性，并给出系统测试计划。

　　在这一次迭代中，设计是重点。当分析人员确认所有的需求已被设计之后，此次迭代即告完成。

3.3               第三次迭代：关注实现

　　第三次迭代，在分析人员确认所有的需求已被设计之后，即告开始。其工作内容，基本对应于传统生命周期理论的开发阶段。

　　在此步迭代中，参与项目的各角色分工为：分析人员跟踪需求变化；设计人员验证开发人员的代码与分析文档的一致性；开发人员编写代码；测试人员根据测试计划，执行单元测试及小规模系统测试。

　　在这一次迭代中，开发是重点。当设计人员确认所有的详细分析文档已经被转化为代码之后，此次迭代即告结束。

3.4               第四次迭代：关注测试

　　第四次迭代，在设计人员确认所有的详细设计都被转化为代码之后开始。

　　在此步迭代中，参与项目的各角色分工为：分析人员跟踪需求变化，并参与系统测试；设计人员参与系统测试；开发人员参与单元测试，并及时修正软件缺陷；测试人员执行测试。

　　在这一次迭代中，测试是重点。当所有已知的缺隐已被修正（或者某些缺陷可接受）的情况下，项目经理同意测试结束。
4                TAO模型到实践的映射

　　在实践中，每个企业都有自己执行项目的标准与规范，作为TAO模型本身，努力去适应这些规范。
4.1               项目过程模型映射

　　TAO模型推荐使用迭代项目执行框架，因为它能够最大限度地发挥TAO模型的能力。

　　在前面的描述中，我们也可能看到，迭代式项目执行框架本身，提供了到传统软件生命周期的映射。也就是说，如果项目希望仍然按照传统的瀑布式模型执行，TAO模型仍然可以发挥作用。
4.2               人员组织映射

　　在TAO模型中，只规定了角色。在实际的项目执行中，根据人员实际所赋以的职责，对应到相应角色 ，而不一定强求于职位名称的一致性。