结构化开发过程方法

　　传统的结构化开发过程方法描述了从软件需求分析定义到软件经过运行维护废止的跨越整个生存期的全部过程、活动和任务的结构框架。结构化的开发方法的每项开发活动一般有以下特征：

　　活动拥有严格的入口条件和出口条件定义，一般为接受上一项活动的一些经过评审的工作结果或工作对象，作为该项活动的入口条件;而将该项活动结束时输出的评审通过的工作成果或工作对象，作为该项活动的出口条件;一般上一活动的出口条件即是本次活动的输入条件。

　　明确的活动的操作过程规则定义，说明该项活动要完成的任务以及如何完成。

　　活动和工作可输出物必须经过评审通过确认，才可继续进行下一项活动。

　　瀑布开发模型

　　瀑布型是最常见的结构化开发方法。瀑布型规定了需求分析定义、设计、编码、测试的自上而下、相互衔接的结构化的开发过程。

　　瀑布方法把测试推迟到项目生命周期的最后阶段进行，当系统出现严重错误并且修改代价很大时，推迟发布日期在所难免了。而且瀑布模型使得开发中的很多关键成员例如开发、测试长期处于长期空闲状态，例如在紧张项目时期，测试人员最后阶段才开始介入测试，因为前期没有介入而学习和熟悉时间都不够，造成测试的缺失和不够深入。如何降低系统中的隐性bug，而使得开发人员更有自信的面对出产的代码呢?如何使测试人员能更快地熟悉系统，更有效的进行测试?“V模型“可以称为瀑布型的变形模式，它提出了测试提前的理念，测试在需求阶段就已经开始介入，以下是V模型的结构体系:

　　V模型

　　V模型提出了测试提前的理念，并给了大家带来了更加明晰的过程结构、完善严格的可输出物的评审体系来保障开发质量。但是“七过程十步骤“的过程的严谨性和复杂性也势必加长了开发周期。在实际使用中，V模型的变型模型经常使用，即概要设计不必等到系统测试计划(包含用例)完成并评审后再进行，而是可以和系统测试计划同步进行。此时两者依据的入口条件均是需求规格说明书。同样集成测试计划和详细设计也可以同步进行，如果单元测试计划和编码不是同一个人或者角色完成的化，也可以同步进行。V变型模型使得几个步骤可以同步进行，在实际开发项目使用中大大缩短了了开发周期。参见下面的“V”变形模型。

　　V模型的测试提前的理念和严谨质量保证体系使得V模型在实际项目中应用甚广，很多欧美、日本、中国等著名公司的外包业务中均要求合作方采用V模型作为其开发过程体系。

　　的确，瀑布模型和V模型为我们软件开发提供了有效的管理模式，结构化的开发过程比较严谨，并且以项目的阶段评审和文档控制方式对整个开发过程进行指导，从而保证软件产品可以及时交付，并且达到预期的质量要求。如果软件开发人员对所开发的项目需求已有了较好的理解或有较大的把握时，瀑布模型非常实用。

　　但是最为突出的缺点是该模型缺乏灵活性，特别是无法解决因为软件需求不准确而直接导致最后一些致命性后果出现，因为这些致命性的后果问题在瀑布型模型中直到开发过程最后快完成时才会被人察觉到。对开发人员而言，经常会有这种无意义的返工，而对用户而言，开发出的软件并不是他们真正需要的，甚至不可用或者用户根本用不上。

　　原型及螺旋模型

　　为弥补瀑布模型的不足，原型及螺旋模型法应运而生。

　　原型法中，开发人员并不是一上来就开始根据需求规格进行设计和代码开发，而是通过制作原型进行试验性开发，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。在实际中原型经常在需求分析定义的过程进行。原型法减少了瀑布模型中因为软件需求不明确而给开发工作带来的风险，因为在原型基础上的沟通更为直观，也为需求分析和定义，提供了新的方法。原型法的应用意义很广，瀑布和“V”模型而将原型法的思想用于需求分析环节，来解决因为需求不明确而导致产品出现严重后果的缺陷。

　　对于复杂的大型软件，开发一个原型往往达不到要求，为减少开发风险，在瀑布模型和原型方法的基础上的演进，出现了螺旋模型和以及大量使用的RUP。

　　敏捷方法

　　结构化的方法给了我们众多的规范，为了保障质量也需要我们产生很多过程文档作为阶段性评审的对象。结构化的开发方法更多的考虑了做事的流程和规范，而没有考虑人的因素，原则规范、模式、和实践都是非常重要的，但是我们知道开发过程是由人去实施的，使他发挥作用的也是人。人的重要性不言而喻，而且团队开发是由人组成的团队去完成的，人与人的交互是复杂的，并且效果也非常难以预期。敏捷方法近来得到了大量推广，敏捷组织也兼容并蓄，现在敏捷开发拥有众多的方法，最重要最有影响力的首推极限编程XP了，它是由一系列简单却互相依赖的实践组成，这些实践结合在一起形成了一个胜于部分结合的整体。极限编程涉及到的实践领域包括12个核心实践:现场客户和团队整体、规划策略和计划的制定、小发行版本计划、简单设计、客户测试、持续整合、重构、结对编程、代码共享、每周工作40小时、隐喻(用普通的语言和术语的集合用来预见和描述项目的功能)、编码标准和可持续步伐。这些实践也是XP的核心价值，所以敏捷开发并不是简陋粗糙作坊制开发的代名词。

　　但敏捷开发以降低结构规范程度和严格程度，来使得更能满足不断变化的商业环境的需要，适应性更强。

　　开发方法评估、比较、应用

　　二维的开发过程方法评估框架，横坐标是方法的结构规范度，低规范度代表产生最少的文档且开发过程不是拘泥于工作规范，高规范度代表产生全面的文档且保持对制品的可追溯性并已建立变更控制委员会，纵向垂直坐标是瀑布模型和迭代模型。瀑布模型是一线形的开发方法，在项目后期进行集成和测试;迭代开发模型是风险驱动的开发方法，在项目早期实现架构并进行集成和测试。

　　敏捷开发方法使用文档和规范度较低的高迭代方法，这使得它更适用于小型的，不很复杂的需要快速投入市场的项目。但是现在敏捷开发过程还附加提供了对开发复杂项目的指导，使得这些过程的规范度更高。一些敏捷开发方法，例如XP和crystal的现在也开始应用到了一些大型而且较复杂的项目。随着项目规模的不断增大，需要对实践过程提供约来越多的指导。可以在开发方法比较评估框架图中看到，随着项目规模的不断增大，需要提供更多的指导、更高的规范度，这样就会使敏捷开发方法移向规范度更高的坐标系的右方。

　　结构化的开发方法，提供了较高规范度的过程，在高规范度的过程中一般具有以下特征：

　　完整详细的计划记录;

　　结构化的开发流程和模型;

　　严谨的开发步骤地输入输出条件;

　　生产很多与管理、用户需求、设计和测试的相关文档和制品;

　　对管理制品进行详细记录并通过版本工具进行管理;

　　创建并维护贯穿于用户需求、设计元素和测试制品的记录;

　　通过变更委员会评审变化;

　　仔细记录并跟踪检查结果;

　　低规范度的开发方法适用于需要适应快速变化商业环境，开发人员处在同一地方，小组规模不大，并且技术含量并不是太高的项目。

　　高规范度开发方法适用于复杂系统开发、大型团队和分布在不同地点的团队，使用这种方法通常可以生产出高质量易于维护的系统，但是开发系统得代价也相对较高，而且它与规范度低的开发方法相比需要更长时间才能适应市场变化。而生产需要

　　CMM软件能力成熟度模型，CMM并不对如何开发软件进行指导，软件开发需要瀑布模型、V模型、RUP、敏捷方法来指导，但是一些组织和CMM评估师认为生产越多的制品、执行更多的活动，过程就越好，如果只是为了在CMM评估中得到更高的级别而在过程中加入不需要的制品和活动，会导致开发过程十分臃肿、笨重和低效。CMM过分强调了专家评审、检查、传统的质量保证活动和详细计划，导致了不重视在项目早期进行持续集成并测试系统的结果，迫使开发团队使用瀑布模型，而不是迭代开发方法。

　　CMMI软件能力成熟度集成模型，更有效的吸收了风险驱动和迭代开发方法，鼓励实践者改进这些单独领域。CMM和CMMI均提供采用高规范度的方法进行迭代开发，CMM则倾向于采用瀑布模型开发，而CMMI则倾向于迭代开发。

　　自由智能化的开发方法

　　我们在开发的时候，总是会囿于一些现实条件，例如客户是否愿意和我们共同工作并且愿意及时和我们沟通他们的反馈呢?我们的项目团队成员来源于多个物理上的地方，面对面沟通不便，来自太多来自客户不同人员的反馈是否更有利于我们产品开发质量?是否一个经验及积累缺乏的团队，开始就适合采用极限编程呢?一系列的问题，我们都无法给予肯定或者否定的答案，在现实开发中，我们会遇到很多现实问题和可能有着各种个性化特殊的项目开发背景，从上面一章节中我们也看到了任何开发方法都有着其适用的范围，而且一些开发方法是有学习曲线需要同其他开发方法作为基础的，所以根据实际项目情况灵活选用各种方法的精华，组成个性化的自由职能开发方法，将为我们带来更多成功的项目实践。

　　例如将在“V”模型中需求分析中采用原型法，将有助于改善“V”模型无法适应需求变化的缺点。而且我们也知道XP的很多实践，可以脱离XP而应用到结构化开发方法中。在传统结构化的开发方法中逐步实现一些XP的实践，也是实现团队敏捷之路的登山杖。

　　熟悉了结构化开发、敏捷开发，将最终使我们走上自由智能开发之路。