软件开发在整个的软件生产过程中处于一个非常重要的阶段。一个失败的软件项目不仅导致项目的投入资金的损失，同时更重要的是企业失去了抢占项目的市场的时间。这对于企业可能是最大的损失，尤其对于规模相对较小的企业来说，更是冲击很大。因此，提高项目开发的成功率，不仅降低了项目的风险，同时对项目以后的拓展也是非常重要的。

首先，在这里根据目前业届的实际情况和失败的项目案例，分析一下导致软件项目失败的原因。

软件的开发的管理与控制包括两方面的内容：一是软件开发的技术（软件工程），其次是软件的开发管理。软件工程是从技术的角度来规范软件开发的管理和控制。对于软件的项目的技术实现取决于技术人员的素质以及项目的合理化分析等方面。目前利用强大的可利用资源，在软件项目的方案上基本可以达到要求。

软件开发项目中经常会出现两种极端的情况：一种是创造了新的生产率和质量的纪录；一种则完全是一场灾难，不是软件项目被取消就是拖延了很长的时间。根据现在行业中的一些实例和专家的总结，首先我们看一下什么情况下为一个失败的软件项目：

1、 由于费用超支或计划执行超时而终止。

2、 完成计划的时间或费用超过了原计划的50% 。

3、 由于质量或性能的原因引起客户的纠纷。

为何在软件项目的开发中会出现的以上的结果，下面按照影响程度得到小顺序着重指明了5种错误的实践方式。

1、 有软件开发的历史数据

缺乏软件开发的历史数据时大多数软件项目失败的关键所在，这样的结论也许是很多人感到吃惊，但事实就是如此。没有一个可靠的软件开发的历史数据会使项目经理、程序员、客户对于软件开发的过程缺少清醒的认识。

假设现在有一个软件项目，而这个项目还没有一个软件公司在30个月内完成。一个负责的经理作了一个比较细致和保守的估计，然后告诉的客户和的手下他认为这个项目需要30-32个月的时间完成。然而常常有这样的情况发生：客户和程序员要求把实践压缩到20个月。客户一方面希望软件尽可能的造投入使用而产生经济效益，一方面也像压缩项目实践作为一个讨价还价的筹码；而程序员方面可能过于自信，一方面尽早的结束项目也能使他们多赚点钱。而此时由于手上没有此软件项目开发的历史数据，在客户和程序员的压力下同意了20个月的软件开发计划。在项目的开始阶段发现计划被拖延了，于是开始向程序员们施加压力，要求他们加快进度，程序员为了追求进度而不得部把其他指标放在一边，这些为题不断的积累下来而项目经理却蒙在鼓里。到了项目的中后期这些质量问题会不断的暴露出来，而且是互相关联并且难于解决，甚至有些是系统设计的问题，这时才发现好多模块要推倒重来，20个月的开发计划变成了天方夜谭。

软件开发的历史数据是反映软件开发队伍的能力的标尺，没有了这个标尺，就无法对软件的开发过程有一个清醒的认识。

2、 忽视使用软件费用估值软件和计划工具软件

国内的软件公司大多数处在“十几条枪，一个手工作坊”的水平上，在承接软件开发的项目之后往往是通过几位骨干任务讨论得到软件的开发费用和进度计划。在其中并为详细的分析和利用一些软件费用的估计工具包。有了这些依据就可以驳回客户和程序员的无理要求并且能精确的项目控制项目的执行。

3、 忽视用户的需求的变动

尽管最初的用户的需求在签订开发合同时已经包含在绣球说明书中，但在整个开发周期中期望用户的需求一直保持部便是不大可能的，因为用户对于如何应用计算机软件并没有一个成熟的经验。在项目的惊醒中用户的需求会不断的增长，一般情况下用户的需求以每月1%的速率增加，如果一个项目在12个月内完成，最终将有超过10%的改动。每月1%只是个经验数据，一个缺乏计算机应用经验的用户会更频繁的改变和增加他的要求。因此在做项目的费用和时间估计时一定要考虑用户需求的变化。一种比较明智的方法是在签订合同是把用户需求的改动和经济利益联系。如果用户增加和改动了需求，那么软件的交付日期可以推迟，费用也应增加。

4、 忽视监督项目的进度

到目前为止，软件产业还没有一个标准的项目进度的核查标准。一个比较清晰的尺度是用已经事项的软件功能反映项目的进度。在一个软件项目中软件功能只是一个主要而非全部的任务。因此一个项目经理在监控项目执行是不应该值关注实现的软件功能，还要关心文档、测试、技术支持这些因素。一个优秀的项目经理部应该被手下的判断所迷惑，而应该按照一个比较客观的标准去深入的核查。

5、 忽视设计复查和代码复查

现在很多程序员很容易陷入一种工作模式：只做不想。他们更关心每天写了多少行代码，完成了几个模块。在这种态度下他们不愿意复查自己的工作，而席关于在软件测试阶段报隐藏的错误改正过来。在设计和代码编写阶段的复查比软件测试更能有效的消除错误，一些经验数据表明，在设计和代码复查时发现的错误是在同等工作量下软件测试发现的错误的两倍。

通过以上的五个方面的分析，我们可以得出结论：在项目的执行中，项目经理必须严格的监督项目的进度，对程序员不愿复查的坏习惯给于纠正。项目经理必须要从软件开发的历史数据和辅助工具包提供的数据中做出精确的估计，在做估计时也应该考虑为不断变化的用户需求留出富余量。

实现软件开发管理的规范化是实现软件高质量和提高软件开发效率的重要途径。设想一下，如果软件的开发阶段处在一种无计划和混乱的阶段，那么，可想而知，开发人员之间的协作的质量是难以保障的，同时软件开发人员和测试人员也是分离的。同样会导致软件的某些核心技术会集中到某个开发人员上，而并非在公司的掌握范围之内。当发生人员变动的时候，整个项目如果在继续进行和进行维护时，就像建楼时缺了一根重要的柱子，如果希望继续进行建筑，必须先准备这根柱子。更坏的情况会导致整个项目的失败和终止。

为了更高效，高质的进行软件开发，我们必须确定适合我们自己的统一的软件开发模式，根据这种模式做出相应的规范化的管理。利用这种统一的开发模式，我们提高我们团队的生产力。对于所有的关键开发活动它为每个团队成员提供了能使用准则、模板、工具指导来进行访问的知识基础。而通过对相同知识基础的理解，无论你是进行需求分析、设计、测试、项目管理或配置管理，均能确保全体成员共享相同的知识、过程和开发软件的视图。

2. 6个最佳实践的有效部署

本文描述了如何进行本公司的软件产品开发的方法，它将软件的需求到软件的交付形成了闭链，为软件的反复迭代开发提供了充分的基础。同时，为每个团队成员提供了必要准则模板和工具指导：

1．迭代的开发软件

2．需求管理

3．使用基于构件的体系结构

4．可视化软件建模

5．验证软件质量

6．控制软件变更_

迭代的开发产品——面对当今的复杂的软件系统，使用连续的开发方法：如首先定义整个问题，设计完整的解决方案，编制软件并最终测试产品，是不可能的。需要一种能够通过一系列细化，若干个渐进的反复过程而生成有效解决方案的迭代方法。迭代方法通过可验证的方法来帮助减少风险——经常性的、可执行版本使最终用户不断的介入和反馈。因为每个迭代过程以可执行版本告终，开发队伍停留在产生结果上，频繁的状态检查帮助确保项目能按时进行。迭代化方法同样使得需求、特色、日程上战略性的变化更为容易。

需求管理——本文描述了如何提取、组织和文档化需要的功能和限制；跟踪和文档化折衷方案和决策；捕获和进行商业需求交流。过程中用例和场景的使用被证明是捕获功能性需求的卓越方法，并确保由它们来驱动设计、实现和软件的测试，使最终系统更能满足最终用户的需要。它们给开发和发布系统提供了连续的和可跟踪的线索。

基于构件的体系结构——该过程在全力以赴开发之前，关注于早期的开发和健壮可执行体系结构的基线。它描述了如何设计灵活的，可容纳修改的，直观便于理解的，并且促进有效软件重用的弹性结构。构件是实现清晰功能的模块、子系统。它们被组装为良好定义的结构，或是特殊的底层结构如Internet、CORBA和COM等的工业级重用构件。

可视化软件建模——开发过程显示了对软件如何可视化建模，捕获体系结构和构件的构架和行为。这允许你隐藏细节和使用“图形构件块”来书写代码。可视化抽象帮助你沟通软件的不同方面，观察各元素如何配合在一起，确保构件模块一致于代码，保持设计和实现的一致性，促进明确的沟通。

验证软件质量——拙劣的应用程序性能和可靠性是戏剧性展示当今软件可接受性的特点。从而，质量应该基于可靠性、功能性、应用和系统性能根据需求来进行验证。

控制软件的变更——管理变更的能力——确定每个修改是可接受的，能被跟踪的——在变更不可避免环境中是必须的。

3. 开发阶段

这是开发过程沿时间的动态组织结构_

软件生命周期被分解为周期每一个周期工作在产品新的一代上。本文将周期又划分为四个连续的阶段。

初始阶段
细化阶段
构造阶段
交付阶段

每个阶段终结于良好定义的里程碑——某些关键决策必须做出的时间点，因此关键的目标必须被达到。

主要的里程碑

开发过程中的阶段和主要的里程碑

每个阶段均有明确的目标。

3.1 初始阶段

初       始

细       化

构       建

交       付

初始阶段的目标是为系统建立商业案例和确定项目的边界。

为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。它包括识别所有用例和描述一些重要的用例。商业案例包括验收规范、风险评估、所需资源估计、体现主要里程碑日期的阶段计划。

本阶段具有非常重要的意义，在这个阶段中关注的是整个项目进行工程中的业务和需求方

面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段的时间可能很短。

本阶段的主要目标如下：

明确软件系统的范围和边界条件，包括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定
明确区分系统的关键Use-case和主要的功能场景
展现或者演示至少一种符合主要场景要求的候选软件体系结构
对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出)
估计出潜在的风险(主要指各种不确定因素造成的潜在风险)
准备好项目的支持环境

初始阶段的产出是:

蓝图文档:核心项目需求、关键特色、主要约束的总体蓝图
原始用例模型完成（完成10%～20%）
原始项目术语表(可能部分表达为业务模型)
原始商业案例,包括业务的上下文,验收规范(年度映射、市场认可等等)，成本预计
原始的风险评估
一个或多个原型

3.1.1 里程碑：生命周期的目标里程碑

构建

交付

生命周期

目标

初始阶段结束时是第一个重要的里程碑：生命周期目标里程碑。初始阶段的评审标准：

风险承担者就范围定义、成本/日程估计达成共识
以客观的主要用例证实对需求的理解
成本/日程、优先级、风险和开发过程的可信度
被开发体系结构原型的深度和广度
实际开支与计划开支的比较

如果无法通过这些里程碑则项目可能被取消或仔细地重新考虑。

3.1.2 文档标准

阶段评审的文档和需要达到的状态列表：

产品（按照重要性排序）	应达到的状态
Vision(SA)	核心需求，关键特色和主要约束都已形成文档
Business Case(PM)	建立并已确认
Risk List & Risk Management(PM)	早期的项目风险已经归档
Business Rules(BPA)	核心业务规则已经归档
Stakeholders Request & Target Organization Assessment (BPA)	完成
Business Architecture Document & Supplementary Business Specification(BPA)	完成
Software Development Plan(PM)	标识出早期的阶段、持续时间和相关目标；SDP中的资源估计(主要是对时间、项目组成员和开发环境等成本的估计)应该和Business Case保持一致。资源估计可以包括直到产品交付的整个项目，也可以只估计到细化阶段就可以了。对于完整的项目估计来说，可能是非常粗略的。这些估计将在随后的每个阶段和循环过程中不断细化、精确和修正。根据项目要求的不同，SDP中可以包含一个或多个专门的计划文档，此外，SDP中的工作指导类文档至少应该有草案的形式。
Product Acceptance Plan(PM)	已经评审并建立基线，该计划在随后的循环过程中如果出现了附加的需求将加以细化
Development Case(PE)	基于UML 建立,可以修改或扩展,已形成文档并通过评审
Project-Specific Templates(PE)	整个项目的相关模版已准备好
Use-case Modeling Guidelines(SA)	已纳入基线
Tools(TS)	所有支持项目的工具已经选好下一步循环工作必需的工具安装完毕
Glossary(SA)	主要的术语已经定义并经过评审
Use-case Model(Actors, Use cases)(SA,UID,UCS)	重要的Actors和Use-case已经标识出来,最为关键的Use-case的事件流框架形成
User Interface Prototypes (UID)	主要界面原型
Business Use-case Model和Business Object Model (Organization Unit, Business Use-case Realization, Business Entity, Business Worker)(BPA & BD)	系统中用到的关键概念已经形成文档并经过评审
Prototype (可选)	针对Vision或Business Case或者某个特定风险准备好一个或多个概念原型
Requirement Management Plan & Requirement Attribute Repository (SA)	RMP完成准备好需求属性库

3.1.3 补充说明

1．角色说明

· 系统分析员——SA(System Analyst)

· 用户界面设计员——UID(UI Designer)

· 业务流程分析员——BPA(Business Process Analyst)和业务设计员BD(Business Designer)

· 程序工程师——PE(Process Engineer)

· 工具专家——TS(Tool Specialist)

2．需求类主要文档

· 想象性描述——Vision

· Use-case 模型（包括核心Use-case实现相关的对象模型）——Use-case Model

· 业务Use-case模型（含业务对象模型，包括角色、组织、单元、整体等）

· 业务结构文档和附加业务说明——Business Architecture Document & Supplementary Business Specification

· 业务规则——Business Rules

· 术语表——Glossary

· 需求管理计划和需求属性库——Requirement Management Plan & Requirement Attribute Repository

3． PM类主要文档

· 业务场景——Business Case

· 风险列表和风险管理计划——Risk List & Risk Management Plan

· 软件开发计划——SDP(Software Development Plan)

· 问题解决计划,评测计划，进度计划，质量评估计划

· 工作顺序——Work Order

· 项目纪录

4． PE类主要文档

· 项目相关模版——Project-specific Template

· 开发案例

3.2 细化阶段

初       始

细       化

构       建

交       付

细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。

为了达到该目的，必须对系统具有“英里宽和英寸深”的观察。体系结构的决策必须在理解整个系统的基础上作出：它的范围主要功能和如性能等非功能性需求。

容易引起争论，细化阶段是四个阶段中最关键的阶段。该阶段结束时硬“工程”可以认为已结束，项目则经历最后的审判日：决策是否项目提交给构建和交付阶段。对于大多数项目，这也相当于从移动的、轻松的、灵巧的、低风险的运作过渡到高成本、高风险并带有较大惯性的运作过程。而过程必须能容纳变化，细化阶段活动确保了结构、需求和计划是足够稳定的，风险被充分减轻，所以可以为开发结果预先决定成本和日程安排。概念上，其逼真程度一致于机构实行费用固定的构建阶段的必要程度。

在细化阶段，可执行的结构原形在一个或多个迭代过程中建立，依赖于项目的范围、规模、风险和先进程度。工作量必须至少处理初始阶段中识别的关键用例，关键用例典型揭示了项目主要技术的风险。通常我们的目标是一个由产品质量级别构件组成的可进化的原型，但这并不排除开发一个或多个探索性、可抛弃的原型来减少如：设计/需求折衷，构件可行性研究，或者给投资者、顾客即最终用户演示版本等特定的风险。

本阶段的主要目标如下：

确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度
针对项目的软件结构上的主要风险已经解决或处理完成
通过完成软件结构上的主要场景建立软件体系结构的基线
建立一个包含高质量组件的可演化的产品原型
说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内
建立好产品的支持环境

初始阶段的产出是：

用例模型（完成至少80%）—— 所有用例均被识别大多数用例描述被开发
补充捕获非功能性要求和非关联于特定用例要求的需求
软件体系结构描述
可执行的软件原型
经修订过的风险清单和商业案例
总体项目的开发计划，包括纹理较粗糙的项目计划，显示迭代过程和对应的审核标准
指明被使用过程的更新过的开发用例
用户手册的初始版本（可选）

3.2.1 里程碑：生命周期的结构里程碑

初       始

细       化

构       建

交       付

生命周期

    结构

细化阶段结束是第二个重要的里程碑:生命周期的结构里程碑.此刻,检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

主要的审核标准包括回答以下的问题：

产品的蓝图是否稳定
体系结构是否稳定
可执行的演示版是否显示风险要素已被处理和可靠的解决
构建阶段的计划是否足够详细和精确；是否被可靠的审核基础支持
如果当前计划在现有的体系结构环境中被执行而开发出完整系统，是否所有的风险承担人同意该蓝图是可实现的
实际的费用开支与计划开支是否可以接受

如果无法通过这些里程碑，则项目可能被取消或仔细地重新考虑。

3.2.2 文档标准

阶段评审的文档和需要达到的状态列表：

产品（按照重要性排序）	应达到的状态
Prototypes	针对系统的关键功能和主要结构场景建立的一个或多个可执行的结构化原型
Risk List & Risk Management Plan (PM)	更新并经过评审
Development Case(PE)	根据早期的项目管理经验加以细化。为构建小组提供支持的开发环境、过程、工具和各种自动化工具已经到位
Project-Specific Templates(PE)	文档模版已经用于建立软件文档产品
Tools(TS)	用于细化阶段的工具已经安装
Software Architecture Document和Refercence Architecture(AR)	已经创建并纳入基线，其中包括详细描述对软件结构构成重大影响的use-case(通过Use-case图),对关键的实现机制和设计元素的标识,外加对流程和部署的定义和描述
Analyse_Design Model(包括所有的子产品,包括对象模型、设计类、子系统和包、接口、事件、静态结构图、动态序列图、活动图、状态转移图等主要内容)（AR,D）	已经定义并纳入基线,对于和软件结构构成重大影响的use-case的实现已经定义,相关的行为已经分配到适当的设计元素中。组件已经标识出来，创建/购买/复用决定做出，选好的结构化组件针对主要场景已经加以集成和评估，从这些活动中获得的教训可能会导致重新设计，软件结构重新考虑替代的设计方案和对需求的重新思考
Data Model(DD)	定义并纳入基线，主要的数据库元素已经设计出来并通过评审
Implementation Model(and all constituent artifacts,including Components)(AR,IMP)	早期结构已经创建主要组件已经确认并原型化
Vision(SA)	基于本阶段获得的新的信息加以细化。对形成软件结构和计划决策起主要作用的use-case建立一个稳固的理解
Software Development Plan(PM)	更新并扩展到构建和移交阶段
Guidelines,such as Design Guidelines and Programming Guidelines.	工作知道已经用于指导相关工作
Use-case Model(Actors,Use Cases)(SA,UCS)	Use-case 模型基本完成。所有的use-case已经标识出来,所有的Actors也已标识出来,大多数use-case(从需求分析中捕获的)的说明都已提供
Software Requirement Specification(UCS)	纳入基线
User Interface Prototype(UID)	完成
Supplementary Specifications(SA)	捕获非功能需求的辅助规范已经形成文档并经过评审
Business Case(PM)	如果结构化工作中发现了新的导致变更基本项目假定的问题,本文档将加以更新
User Manual and other Training Material(TW,CB)	基于use-case形成早期版本

3.2.3 补充说明

1．角色说明

· AR(Architect),D(Designer),DD(Database Designer),IMP(Implementer)

· TW(Technical Writer),CB(Course Builder)

2．需求类主要文档

· 想象性描述——Vision

· Use-case 模型（包括Actors,Use-cases,Use-case Realization）

· 需求分析说明书和附加说明——SRS & Supplementary Specification

· 用户界面原型——User Interface Prototype

3． PM类主要文档

· 风险列表——Risk List

· 软件开发计划——SDP(Software Development Plan)

· 业务场景——Business Case

4．分析和设计类文档

· 软件结构文档和相关结构——Software Architecture Document & Reference Architecture

· 分析设计模型（包括对象模型，设计类，包，子系统，接口，事件和图）——Analysis Design Model(Include Object Model, Design Class, Package, Subsystems, Interface, Event and Diagrams)

· 执行模型（包括子系统，组件）——Implementation Model(Include Subsystems, Component)

· 数据模型—— Data Model

· 原型——Prototype

5．细化阶段需求建模结束,概要和详细设计工作也基本结束,一部分和结构相关的组件已经开始编码

6．本阶段可以分为两个子阶段，第一个子阶段是以概要设计结束（完成软件体系结构设计）和需求建模基本结束为标志，此阶段主要参与人员是SA(& Use-case Specifier)和Architect.可以称为概要设计阶段。此后是详细设计阶段，在详细设计阶段，需求建模只剩下Refine System Definition和Manage Change Requirements 两项主要工作.对于分析和设计工作来说,可能会有多个设计人员(包括Designer, Database Designer,甚至部分 Implementers)参与进来,这时,Architect主要对软件的整体体系结构负责。

7．需求评审可以在概要设计结束和详细设计开始时进行。

3.3 构建阶段

初       始

细       化

构       建

交       付

在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详尽的测试。

构建阶段，从某种意义上说，是重点在管理资源和控制运作以优化成本、日程、质量的生产过程。就这一点而言，管理的理念经历了初始阶段和细化阶段的智力资产开发到构建阶段和交付阶段可发布产品的过渡。

许多项目规模大的足够产生许多平行的增量构建过程，这些平行的活动可以极大地加速版本发布的有效性；同时也增加了资源管理和工作流同步的复杂性。健壮的体系结构和易于理解的计划是高度关联的。换言之体系结构上关键的质量是构建的容易程度。这也是在细化阶段平衡的体系结构和计划被强调的原因。

本阶段的主要目标如下：

通过优化资源和避免不必要的返工达到开发成本的最小化
根据实际需要达到适当的质量目标
据实际需要形成各个版本（Alpha, Beta, and other test release）
对所有必须的功能完成分析、设计、开发和测试工作
采用循环渐进的方式开发出一个可以提交给最终用户的完整产品
确定软件、站点、用户都为产品的最终部署做好了相关准备
达成一定程度上的并行开发机制

构建阶段的产出是可以交付给最终用户的产品。它最小包括：

特定平台上的集成产品
用户手册
当前版本的描述

3.3.1 里程碑：初始功能里程碑

初始

细化

初始可执行功能

创建阶段结束是第三个重要的项目里程碑（初始功能里程碑）。此刻，决定是否软件、环境、用户可以运作而不会将项目暴露在高度风险下。该版本也常被称为Beta版。

构建阶段主要的审核标准包括回答以下的问题：

产品是否足够稳定和成熟得发布给用户
是否所有的风险承担人准备好向用户移交
实际费用与计划费用的比较是否仍可被接受

如果无法通过这些里程碑，则移交不得不被延迟。

3.3.2 产品状态

本阶段里程碑处的产品和相关状态如下:

产品（按重要性排序）	达到里程碑时的状态
“The System”(IN)	准备好进入Beta测试
Deployment Plan(DM)	开发、评估并已纳入基线
Implementation Model ( and all constituent artifacts,including Components)(AR,IMP)	从细化阶段的模型扩展到所有组件、完成
Test Plan, Test Procedure, Test Use-case, Test Results, Workload Analysis Document(TD,T)	完成
Training Materials(TW,DB)(可选)	手册和培训资料基本完成
Design Model(and all constituent artifacts)(D)	更新并完成
Development Case(PE)	基于早期项目经验完成、为支持产品移交小组的环境、工具和自动化工具已经到位
Project-Specific Templates(PE)	已经用于建立软件产品文档
Tools(TS)	支持产品构建的工具已经安装
Data Model(DD)	更新，包括所有支持持久存储的元素(e.g. tables, indexes, object-to-relational mappings, etc.)
Supplementary Specifications(SA)