软件工程基础知识 一

软件生命周期和开发模型

 软件生命周期

软件如同生命一样也有生命周期，一个软件产品的生命周期为计划、分析、设计、编程、测试、维护直至被淘汰。

由于生命周期各阶段的划分尚不统一，所包含的世界内容也不完全相同，以下是具有代表性的4种：

1970年 Boehm定义的软件生命周期​​​​模型

 

1988年制定和公布的国家标准GB8566生命周期模型

 

1996年制定和公布的国家标准GB/T8566生命周期模型

1999年，Rational软件公司的3位软件工程大厦Ivar Jacobosn、Grady Booch和James Rumbaugh联合编写了一部跨世代的著作《统一软件开发过程》（The Unified Software Development Process，该书清楚的说明了支持整个软件生命周期的统一软件开发过程是一个用例驱动的、以架构为中心的、迭代与增量的开发过程，统一软件开发过程是在重复一系列组成软件生命周期的循环，每次循环都包括如下图所示的4个阶段和5种工作流：

尽管软件生命周期种各阶段划分的标准不统一，名称也不一致，但总体上还是包括了计划、分析、设计、编程、测试和维护等阶段，这本《统一软件开发过程》就是主要介绍分析、设计、测试和维护阶段的工作。

2、瀑布模型

瀑布模型严格遵循软件生命周期各阶段的固定顺序，上一阶段完成后才能进入到下一阶段，整个模型就像一个飞流直下的瀑布。

优点：可以强迫开发人员采用规范的方法；严格规定了各阶段必须提交的文档；要求每个阶段结束后，都要进行严格的评审。

缺点： 过于理性化，缺乏灵活性，无法在开发过程种逐渐明确用户难以确切表达或一时难以想到的需求，直到软件开发完成才发现与用户的需求有很大距离，此时必须付出高额代价才能纠正这一错误。

3、快速原声模型

快速原型是指快速建立起来的可以在计算机上运行的程序（它所完成的功能往往是最终软件产品功能的一个子集），或仅仅是一个演示界面（不具备实际可运行的功能）。快速原型模型的第一步是快速建立一个能反应用户主要需求的软件原型，然后让用户使用并进一步提出修改建议。。。然后一次次的修改使用，直到用户认为这个原型系统确实能够满足他们的需求，开发人员便可依此书写软件需求说明，并本机这份文档开发出可以满足用户真实需求的软件产品。

原型话方法基于这样一种客观事实：并非所有的需求在软件开发之前都能够准确的说明和定义，因此，它不追求也不可能要求对需求的严格定义，而是采用了动态定义需求的方法。

快速原型方法适用于需求不过明确的项目，具有广泛技能高水平的原型化人员是原型实施的重要保证。原型化人员应是具有经验与才干、训练有素的专业人员，衡量原型化人员能力的重要标准是他能否从用户的模糊描述种快速的获取实际的需求。

4、演化模型

演化模型也是一种原型化开发方法，与快速原型模型略有不同。在快速原型模型中，原型的用途是获知用户真正的需求，一旦需求缺点了，原型即被抛弃了。而演化模型开发的过程则是从初始模型逐步演化为最终软件产品的渐进过程，也就是说，快速原型模型是一种“抛弃式”的原型化方法，而演化模型则是一种“渐进式”的原型化方法。

5、增量模型

增量模型是第三种原型化开发方法，但他既非是“抛弃式”的，也非是“渐进式”的，而是“递增式”的。增量模型把软件产品划分为一系列的增量构件，分别进行设计、编程、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。如何将一个完整的软件产品分解成增量构件，因软件产品的特点和开发人员的习惯而异，但使用增量模型的软件体系结构必须是开放的，且加入新构件的过程必须简单方便。

6、螺旋模型

螺旋模型综合了瀑布模型和演化模型的优点，同时还增加了风险分析。螺旋模型包含了4个方面的活动：制定计划、风险分析、实施工程、客户评估。这4项活动恰好可以放在一个直角坐标系的4个象限，而开发过程恰似好像一条螺旋线。采用螺旋模型时，软件开发沿着螺旋线自内向外旋转，每转一圈都要对风险分析进行识别和分析，并采用相应的对策。螺旋形第一圈的开始可能是一个概念项目。从第二圈开始，一个新产品开发项目开始了，新产品的演化沿着螺旋形进程若干次迭代，一直运转到软件生命周期结束为止。

7、喷泉模型

喷泉模型主要用于描述面向对象的开发过程。喷泉一词体系了面向对象开发过程的迭代和无间隙特征。迭代意味着模型中的开发活动常常需要多次重复，每次重复都会增加或明确以下目标系统的性质，但却不是对向前工作结构的本质性改动。无间隙是指开发活动（如分析、设计、编程）之间不存在明显的边界，而是运行各开发活动交叉、迭代地进行。

8、基于构件的模型

构件是一个具有可重用价值、功能相对独立的单元。基于构件的软件开发（Commponent Based Software Development  CBSB）模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库种的一个或多个软件构件，通过组合的手段高效率、高质量地构造应用软件系统的过程，基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。基于构件的开发模型由软件需求分析和定义、体系结构设计、应用软件构件、测试和发布5个阶段组成。

基于构件的开发方法使得软件开发不再一切从头开始，开发的过程是组件构件组装的过程，维护的过程就是构件升级、替换和扩充的过程，其优点是构件组装模型导致了软件的复用，提高了软件的开发效率；构件可由一方定义其规格说明，被另一方实现，然后供给给第三方使用；构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分布提交软件产品。

缺点：由于采用自定义的组装结构标准，缺乏统一的组装结构标准，引入具有较大的风险，可重用性和软件高效性不易协调，需要精干的、有经验的分析人员和开发人员，一半开发人员插不上手，客户满意度低；过分依赖于构件，构件库影响着产品质量。

9、快速应用开发模型（RAD）

快速应用开发（Rapid Application Development RAD）模型是一个增量型的软件开发过程模型，他强调极端的开发周期，RAD模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，基于构件的建造方法赢得快速开发。如果需求理解得好且约束了项目的范围，利用着种模型可以很快地创造出功能完善的“信息系统“。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。

RAD模型各个活动期所要完成的任务如下：

• 业务建模：以什么信息缺点业务过程运作？要生成什么信息？谁生成它？信息流的去向是哪里？由谁处理？可以辅之数据流图
• 数据建模：为支持业务过程的数据流，找数据对象集合，定义数据对象属性，于其他数据对象的关系构成数据模型，可以辅之E-R模型。
• 过程建模：使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理框。
• 应用程序生成：利用第四代语音（4GL）写出处理程序，重用已有构件或创造新的可重用构件，利用环境提供的工具自动生成并构造出整个应用系统。
• 测试与交付： 由于大量重用，一般只做总体测试，但新创建的构件还是要测试的。

与瀑布流相比，RAD模型不采用传统的第三代程序设计语音来创建软件，而是采用基于构件的开发方法，复用已有的程序结构（如果可能）或使用可复用构件，或创建可复用的构件（如果需要）。在所有情况下，均使用自动化工具辅之软件创造。很显然，在加上RAD模型项目上的实际约束需要”一个可伸缩的范围“。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到3个月的时间内完成，那么它就是RAD的一个候选者，每一个主要功能可有一个单独的RAD组来实现，最后再集成起来形成一个整体。

RAD模型通过大量使用可复用的构件加快了开发速度，对信息系统的开发特别有效。但是像所有其他软件过程模型一样，RAD方法也有其缺陷。

• 并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果哪一项功能不能够被模块化，那么构件RAD所需要的构件就会出问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。

• 开发者和客户必须在很短的实际完成一系列的需求分析，任何一方配合不当都会导致RAD项目的失败

• RAD只能用于信息系统开发，不适合技术风险很高的情况，当一个新应用要采用很多新技术或当新软件要求已有的计算机程序有较高的互操作性时，这种情况就会发生。

10、UP

UP（Unified Process，统一的开发过程）是一个统一的软件开发过程，是一个通用过程框架，可以应付种类广泛的软件系统，不同的应用领域、不同的组装类型、不同的性能水平和不同的项目规模。UP是基于构件的，这意味着利用它开发发软件系统是由构件构成的，构件之间通过定义良好的接口相互联系。在准备软件系统所有蓝图时，UP使用的统一建模语音是UML。

与其他软件过程相比，UP具有3个显著的特点：用例驱动、以框架架构为中心，迭代和增量。

UP中的软件过程在世界上被分解为4个顺序，分别是初始阶段、细化阶段、构建阶段和交付阶段，每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否满足。如果评审结果令人满意，则可以进行下一个阶段。

四个阶段的核心任务分别为：

1）、初始阶段

• 明确地说明项目规模，这涉及到了环境及最重要的需求和约束，以便于可以得出最终产品的验收标准。
• 计划和准备商业理由。评估风险管理，人员配备，项目计划和成本/进度/收益率折中的备选方案。
• 综合考虑备选架构，评估设计和自制/外购/复用方面的折中，从而估算出成本、进度和资源。此处的目标在于通过一些概念的证实来证明可行性。该证明采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。初始阶段 的原型设计工作只需限制在确信解决方案可行性即可。该解决方案在细化和构件阶段实现。
• 准备项目环境，评估项目和组装，选择工具，决定流程中要改进的部分。

2）、细化阶段

• 快速确定构架，确认构架并为构架建立基线。
• 根据此阶段了解的最新信息改进前景，对推动构架和计划决策的最关键用例建立可靠的了解。
• 为构建阶段建立详细的迭代计划并为其建立基线。
• 改进开发方案，定位开发环境，包括流程和支持构建团队所需的工具和自动化支持。
• 改进构架并选择构件。评估潜在构件，充分了解自制/外购/复用决策，以便由把握地确定构建阶段的成本和进度。集成了所有构架构件，并按主要场景进行评估。通过这些活动得到的经验可能导致重新设计构架、考虑替代设计或重新考虑需求。

3）、构建阶段

• 资源管理、控制和流程优化
• 完成构件开发并根据已定义的评估标准进行测试。
• 根据前景的验收标准对产品发布进行评估

4）、产品化阶段（提交阶段）

• 执行部署计划。
• 对最终用户支持材料定稿。
• 在开发现场测试可交付产品
• 制作产品发布版
• 获得用户反馈
• 基于反馈调整产品
• 使得最终用户可以使用产品

基于UP的软件过程是一个迭代过程。通过初始、细化、构建和提交4个阶段就是一个开发周期，每次经过这4个阶段就会产生一代软件，除非产品退役，否则通过重复同样的4个阶段，产品将演化为下一代产品，但每一次的侧重点都将放在不同的阶段上们这些随后的过程称为演化过程。

在进度方面，所有阶段都各不相同。尽管不同的项目有很大的不同，但一个中等规模项目的典型初始开发周期应该预先考虑到工作量和进度时间的分配。

11、XP方法

XP方法即极限编程发，是民间方法中的一种，其他敏捷方法还要：自适应开发，水晶方法，特性驱动开发等。他们都有一个共同的特点，那就是都将矛头指向了“文档”，他们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则式“轻量级”方法。

在XP方法中提出了4大价值观：沟通、简单、反馈、勇气。5大原则：快速、反馈、简单性假设、逐步修改、提倡更改、优质工作。

12个最佳实践：

（1）计划游戏

计划游戏的主要思想就是先快速的制定出一份概要计划，然后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事以及后续的一次迭代的概要计划。

“客户辅之业务决策，开发团队负责技术决策”是计划游戏获得成功的前提条件。也就是说，系统的范围、下一次迭代的发布时间、用户故事的优先级应该有客户决定，每个用户故事所需的开发时间，不同可选技术的成本，如何组建团队、每个用户故事的风险以及具体的开发顺序应该有开发团队决定。

（2）小型发布

XP方法秉承的是“持续集成、小步快走”的哲学，也就是说每一次的版本应尽可能的小，当然，前提条件是每个版本有足够的商业价值，值得发布。

由于小型发布可以使集成更频繁，客户获得的中间结果越频繁，反馈也就越频繁，可以就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去，以实现更高的客户满意度。

（3）隐喻

相对而言，隐喻比较令人费解。根据词典中的解释是：“它是一种语音的表达手段，用来暗示字面意义不相似的事物直接的相似之处”。 如果能找到隐喻固然很好，但并不是每一种情况都可以找到恰当的隐喻，因此，没有必要强求，顺其自然即可。

（4）简单设计

强调简单的价值观，引出了简单性假设原则，落到实处就是“简单设计”实践。这个实践看上去似乎很容易理解，但却又经常被误解，许多批评者就指责XP忽略设计是不正确的。其实，XP的简单设计实践并不是要忽略设计，而是认为设计不应该在编码之前一次性完成，因为那样只能建立在“情况不会发送变化“或者”我们可以预见所有的变化“之类的谎言基础上的。

（5）测试先行

开发时先行列出测试标准，按照预定效果进行开发，即边开发边进行测试。相关隐喻有：”泥瓦匠砌墙“

（6）重构

重构是一种对代码进行改进而不影响功能实现的技术，XP需要开发人员在”问道代码的坏味道“时有重构的勇气。重构的目的是降低变化引发的风险使得代码优化更加容易。通常重构发送在以下两种情况下：

• 实现某个特性之前：尝试改变现有代码结构，以使得实现新的特性更加简单

• 实现某个特性之后：认证检测刚刚写完的代码，看是否能够进行简化。

在考虑重构时，应该要养成编写并经常运行测试代码的习惯，要先编写代码，在进行重构；将每一次增加功能都当作一次重构的时机；同时将每一个纠正错误也当作一次重构的时机。重构技术是对简单设计的一个良好补充，也是XP中重视”优质工作“的体现。

（7）结对编程

结对编程是指在开发中，程序语没两人一组，当甲编码时，乙在一旁检查，乙编码时反之。自从20世纪60年代开始，就有类似的实践在进行，长年以来的研究结果给出的结论是，结对编程的效率反而比单独编程更高。一开始虽然会牺牲一些速度，但慢慢的开发速度会逐渐加快。究其原因，主要是结对编程大大降低了沟通的成本，提高了工作质量。具体表现在以下几个方面：

• 所有的设计决策确保了不是由一个人做出的

• 系统的任何一个部分都肯定有至少两个人以上熟悉

• 几乎不可能有两个人都忽略的测试项或其他任务

• 结对组合的动态性是一个组织进行知识管理的好途径

• 代码总是能够保障被评审通过

而且XP方法集成其他最佳实践也能够使得结对编程更加容易进行：

• 编码标准可以消除一些无谓的分歧

• 隐喻可以帮助结对伙伴更好地沟通

• 简单设计可以使结对伙伴更了解他们所从事的工作。

结对编程被誉为XP保存工作质量、强调人文主义的一个最典型的实践，应用得当还能使得开发团队协作更加顺畅，知识交流与共享更加频繁，团队稳定性也会更加牢固。

（8）集体代码所有制

由于XP方法鼓励团队进行结对编程，而且任务结对编程的组合应动态搭配，根据任务及专业技能的不同进行最优组合，因此每一个人都会遇到不同的代码，代码的所有制就不再适用于私有，因为那样会给修改工作带来巨大的不便。

所谓集体代码所有制，就是团队中的每个成员都拥有对代码进行修改的权力，每个人都拥有全部的代码，也需要对全部的代码负责，同时XP强调代码是谁破坏的就应该由谁来修复。

（9）持续集成

持续集成要求XP团队每天尽可能的多次地做代码集成，每次都在确保系统运行的单元测试通过之后进行，这样就可以尽早的暴漏、消除由于重构、集体代码所有制所引入的错误，从而减少解决问题的痛苦。

（10）每周工作40小时

这是最让开发人员开心、管理者反对的一个最佳实践了，加班、再加班早已成为开发人员的家常便饭，也是管理者最常使用的一种策略。而XP方法认为，加班最终会扼杀团队的积极性，最终导致项目的失败，这样充分体现了XP方法关注人的因素比关注过程的因素更多一些。40并不少绝对的数，而是一个正常工作时间。

（11）现场客户

现场客户是XP强调沟通的又以表现。其强调的是开发团队应该和客户能够随时沟通，可以是面谈、在线聊天或是通过电话交流，当然面谈是必不可少的，其中的关键是开发人员需要客户做出业务决策以及需要进一步了解业务细节时，能够随时找到相应的客户。

（12）编码标准

编码标准是一个”雅俗共享“的最佳实践，无论是代表重型方法的UP、PSP还是代表敏捷方法的XP，都认为开发团队都应该拥有一个编码标准。XP方法认为编码标准可以避免团队在一些于开发进度无关的细枝末节问题上发生争论，而且会给重构、结对编程带来很大麻烦，不过XP方法 的编码标准的目的不是创建一个事无巨细的规则列表，而是只要能够提供一个确保代码清晰、便于交流的指导方针即可。