项目开发

项目开发并不是一个简单的过程，我们需要遵循一些开发流程。一个项目的开发会被分成很多步骤来实现，每一个步骤都有自己的起点和终点。也正如此，使得开发过程中的每个步骤起点和终点在不同的软件项目中出现不同难度的“坎”，使其难于达到该步骤开始或是终结的条件，开发过程也就不会一帆风顺。

不同的开发模式其实就是将步骤的起点和终点重新定义，甚至重新组合排列，虽然任何一个开发模式最终目的都是完成软件项目的开发，但期间所经历的过程不一样，过程步骤之间的起点和终点的定义不同，所带来的“坎”也就不一样，项目周期自然各不相同。因此，根据软件项目的实际情况选择一个适合的开发模式能减少开发周期中“坎”的出现次数与难度，可以很大程度地缩短开发周期。

我们首先了解一下传统瀑布式开发流程，如图2-1所示。

图2-1  瀑布式（Waterfall）开发流程

瀑布模型是由W.W.Royce在1970年首先提出的软件开发模型，在瀑布模型中，开发被认为是按照需求分析、设计、实现、测试（确认）、集成和维护坚定而顺畅地进行的。线性模型太理想化，太单纯，以至很多人认为瀑布模型已不再适合现代的软件开发模式，几乎被业界抛弃。

我们向大家推荐的是统一开发流程RUP（Rational Unified Process），它是目前最流行的一套项目开发流程模式，其基本特征是通过多次迭代完成一个项目的开发，每次迭代都会带来项目整体的递增，如图2-2所示。

 

 

从纵向来看，项目的生命周期或工作流包括项目需求分析、系统分析和设计、实现、测试和维护。从横向来看，项目开发可以分为4个阶段：起始（Inception）、细化（Elaboration）、建造（Construction）和移交（transition）。每个阶段都包括一次或者多次的迭代。在每次迭代中，根据不同的要求或工作流（如需求、分析和设计等）投入不同的工作量。也就是说，在不同阶段的每次迭代中，生命周期的每个步骤是同步进行的，但权重不同。这是与传统瀑布式开发流程区别最大的地方。

2.1.1  项目生命周期

1．项目需求分析

需求分析阶段的活动包括定义潜在的角色（角色指使用系统的人，以及与系统相互作用的软、硬件环境）、识别问题域中的对象和关系，以及基于需求规范说明和角色的需要发现用例（use-case）和详细描述用例。

2．系统分析和设计

系统分析阶段是基于问题和用户需求的描述，建立现实世界的计算机实现模型。系统设计是结合问题域的知识和目标系统的体系结构（求解域），将目标系统分解为子系统，之后基于分析模型添加细节，完成系统设计。

3．实现

实现又称编码或开发阶段，也就是将设计转换为特定的编程语言或硬件，同时保持先进性、灵活性和可扩展性。在这个阶段，设计阶段的类被转换为使用面向对象编程语言编制（不推荐使用过程语言）的实际代码。这一任务可能比较困难，也可能比较容易，主要取决于所使用的编程语言本身的能力。

4．测试和维护

测试用于检验系统是否满足用户功能需求，以便增加用户对系统的信心。系统经过测试后，整个开发流程告一段落，进入运行维护或新的功能扩展时期。

2.1.2  项目开发阶段

1．起始阶段（The Inception Phase）

对于新的开发项目来说，起始阶段是很重要的。在项目继续进行前，我们必须处理重要的业务与需求风险。对于那些增强现有系统的项目，起始阶段是比较短暂的，但是其目的仍是确定该项目的实施价值及可行性。

起始阶段有4个重要活动。

— 制定项目的范围

— 计划并准备业务案例

— 综合分析，得出备选构架

— 准备项目环境

2．细化阶段（The Elaboration Phase）

细化阶段的目标是为系统构架设立基线（baseline），为在构建阶段开展的大量的设计与实施工作打下坚实的基础。构架是通过考虑最重要的需求与评估风险演进而来的，构架的稳定性是通过一个或多个构架原型（prototype）进行评估的。

3．构建阶段（The Construction Phase）

构建阶段的目标是完成系统开发。构建阶段从某种意义上来看是一个制造过程，其中，重点工作就是管理资源、控制操作，以优化成本、日程和质量。因此，在此阶段，管理理念应该进行一个转换，从起始阶段和细化阶段的知识产品开发转换到构建和交付阶段的部署产品的开发。

构建阶段的每次迭代都具有3个关键活动。

— 管理资源与控制过程

— 开发与测试组件

— 对迭代进行评估

4．交付阶段（The Transition Phase）

交付阶段的焦点就是确保软件对于最终用户是可用的。交付阶段包括为发布应用而进行的产品测试，在用户反馈的基础上做微小的调整等内容。在生命周期的这个时刻，用户反馈主要集中在精确调整产品、配置、安装，以及可用性等问题上。

交付阶段的关键活动如下：

— 确定最终用户支持资料

— 在用户的环境中测试可交付的产品

— 基于用户反馈精确调整产品

— 向最终用户交付最终产品

最后，作为补充，我们再简单介绍一种新的开发流程：敏捷开发和极限编程。

2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭的问题，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有SCRUM、Crystal、特征驱动软件开发（Feature Driven Development，简称FDD）、自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)。

极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合，使软件能以尽可能快的速度开发出来并向客户提供最高的效益。XP在很多方面都和传统意义上的软件工程不同，同时，它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。

XP具有12个过程，只有完全使用12个过程才是真正使用了XP，只是简单使用了其中一个方法并不代表使用了XP。XP的12个过程如下。

— 现场客户（On-site Customer）

— 计划博弈（Planning Game）

— 系统隐喻（System Design）

— 简化设计（Simple Design）

— 集体拥有代码（Collective Code Ownership）

— 结对编程（Pair Programming）

— 测试驱动（Test-driver）

— 小型发布（Small Release）

— 重构（Refactoring）

— 持续集成（Continous integration）

— 每周40小时工作制（40-hour Weeks）

— 代码规范（Coding Standards）

下面是极限编程的有效实践。

完整团队XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

计划博弈是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

结对编程所有的产品软件都是由两个程序员并排坐在一起在同一台机器上构建的。

测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净，具有表达力。

持续集成团队总是使系统完整地被集成。一个人拆入（Check in）后，其他所有人负责代码集成。

集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其他方面的开发。

编码标准系统中所有的代码看起来就好像是由一人单独编写的。

隐喻将整个系统联系在一起的全局视图，它是系统的未来影像，使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

可持续的速度团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。