网站开发雇佣平台,百度网页制作html,苏州企业网站关键词优化,网站建设举措在计算机刚刚诞生的年代#xff0c;计算机是一种只有天才才能掌握的工具。人们对软件的认知仅仅停留在程序的层面上#xff0c;所谓的软件开发就是那些能够掌握计算机的天才们写的一些只有计算机才能理解的二进制序列。但随着技术的发展#xff0c;软件的复杂度不断提高计算机是一种只有天才才能掌握的工具。人们对软件的认知仅仅停留在程序的层面上所谓的软件开发就是那些能够掌握计算机的天才们写的一些只有计算机才能理解的二进制序列。但随着技术的发展软件的复杂度不断提高人们进入了大规模软件开发的时代。这时人们发现软件系统已经变得非常复杂需要遵循一定的开发方法才能取得成功于是称这些模式化的开发方法为开发模型。 一、瀑布模型 顾名思义瀑布模型就如同瀑布一样从一个特定的阶段流向下一个阶段如图 6-1所示。 1.瀑布模型的核心思想 瀑布模型认为软件开发是一个阶段化的精确的过程。就像要制造一艘航空母舰首先需要知道航空母舰的参数长、宽、高、排水量、航速等。在这些参数的技术上需要对航空母舰进行设计设计包括总体设计和详细设计。只有设计得一清二楚的图纸才能交付施工否则造出的零件肯定拼装不到一起。制造完毕后要把这些零件一个一个地拼装起来拼装成发动机、船舱等部分并检查这些部分是否符合设计标准这就是集成测试。最后把各个部分组合在一起造出一艘巨大的航母。软件要经过需求分析、总体设计、详细设计、编码、调试、集成测试和系统测试阶段才能够被准确地实现。在图 6-1 中每一阶段都有回到前一阶段的反馈线这指的是在软件开发中当在后续阶段发现缺陷的时候可以把这个缺陷反馈到上一阶段进行修正。 从图 6-1 中可以看出瀑布模型的一个重要特点软件开发的阶段划分是明确的一个阶段到下一个阶段有明显的界线。在每个阶段结束后都会有固定的文档或源程序流入下一阶段。在需求分析阶段结束后需要有明确的描述软件需求的文档总体设计结束后需要有描述软件总体结构的文档详细设计结束后需要有可以用来编码的详细设计文档而编码结束后代码本身被作为文档流到下一个阶段。因此也称瀑布模型是面向文档的软件开发模型。 当软件需求明确、稳定时可以采用瀑布模型按部就班地开发软件当软件需求不明确或变动剧烈时瀑布模型中往往要到测试阶段才会暴露出需求的缺陷造成后期修改代价太大难以控制开发的风险。 二、瀑布 V 模型 瀑布 V 模型是瀑布模型的一种变体。随着对瀑布模型的应用人们发现缺陷是无法避免的任何一个阶段都会在软件中引入缺陷而最后的测试也不能保证软件完全没有缺陷只能争取在交付前发现更多的缺陷。测试成为软件开发中非常重要的环节测试的质量直接影响到软件的质量。因此人们对瀑布模型进行了小小的更改提出了更强调测试的瀑布 V 模型如图 6-2 所示。 整个瀑布模型在编码与调试阶段转了个弯形成了一个对称的 V 字。瀑布 V 模型同标准瀑布模型一样在进行完需求分析后就将进入总体设计阶段但是除总体设计外需求分析还有一条虚线指向系统测试。这指的是需求分析的结果将作为系统测试的准则即需求分析阶段也将产生同软件需求一致的系统测试同时软件产品是否符合最初的需求将在系统测试阶段得到验证。以此类推总体设计对应了集成测试详细设计对应了单元测试。瀑布 V 模型不但保持了瀑布模型的阶段式文档驱动的特点而且更强调了软件产品的验证工作。 瀑布模型的缺点 虽然是经典的开发模型但瀑布模型中仍存在一些难以克服的缺陷即使是在改进的瀑布 V 模型中还是会存在。 首先在瀑布模型中需求分析阶段是一切活动的基础设计、实现和验证活动都是从需求分析阶段的结果导出的。一旦需求分析的结果不完全正确存在偏差那么后续的活动只能放大这个偏差在错误的道路上越走越远。事实上由于用户和开发者的立场、经验、知识域都不相同不同的人对同一件事物的表述也不同这就造成需求分析的结果不可能精确、完整地描述整个软件系统。所以瀑布模型后期的维护工作相当繁重而这些维护工作大多都是修正在需求分析阶段引入的缺陷。这个问题是瀑布模型难以克服的。 其次瀑布模型难以适应变化。在瀑布模型中精确地定义了每一个阶段的活动和活动结果而每一阶段都紧密依赖于上一阶段的结果。如果在软件的后期出现了需求的变化整个系统又要从头开始。 再次使用瀑布模型意味着当所有阶段都结束才能最终交付软件产品所以在提出需求后需要相当长一段时间的等待才能够看到最终结果才能发现软件产品究竟能不能够满足客户的需求。 最后文档驱动型的瀑布模型除了制造出软件产品外还将产生一大堆的文档大部分的文档对客户没有任何意义但完成这些对客户没有意义的文档却需要花费大量的人力。所以瀑布模型也是一种重载过程。 三、演化模型 瀑布模型看起来很好随着一个又一个阶段的流过软件系统就被建立起来了。可是在应用软件开发的过程中人们发现很难一次性完全理解用户的需求、设计出完美的架构开发出可用的系统这是由于人的认知本身就是一个过程这个过程是渐进的、不断深化的。对于复杂问题“做两次”肯定能够做得更好。那么对于软件开发这个复杂而且与人的认知过程紧密相关的事也应该是一个渐进的过程。 演化模型正是基于这个观点提出的。一般情况下一个演化模型可以看做若干次瀑布模型的迭代当完成一个瀑布模型后重新进入下一个迭代周期软件在这样的迭代过程中得以演化、完善。根据不同的迭代特点演化模型可以演变为螺旋模型、增量模型和原型法开发。 四、螺旋模型 螺旋模型将瀑布模型和演化模型结合起来不仅体现了两个模型的优点而且还强调了其他模型均忽略了的风险分析。螺旋模型的每一周期都包括需求定义、风险分析、工程实现和评审 4 个阶段由这 4 个阶段进行迭代软件开发过程每迭代一次软件开发就前进一个层次。采用螺旋模型的软件过程如图 6-3 所示。 螺旋模型的基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制。它把软件项目分解成一个个小项目每个小项目都标识一个或多个主要风险直到所有的主要风险因素都被确定。 螺旋模型强调风险分析使得开发人员和用户对每个演化层出现的风险都有所了解继而做出应有的反应。因此螺旋模型特别适用于庞大而复杂、具有高风险的系统对于这些系统风险是软件开发潜在的、不可忽视的不利因素它可能在不同程度上损害软件开发过程影响软件产品的质量。减小软件风险的目标是在造成危害之前及时对风险进行识别、分析决定采取何种对策进而消除或减少风险的损害。 与瀑布模型相比螺旋模型支持用户需求的动态变化为用户参与软件开发的所有关键决策提供了方便有助于提高目标软件的适应能力为项目管理人员及时调整管理决策提供了便利从而降低了软件开发风险。 但是不能说螺旋模型绝对比其他模型优越事实上螺旋模型也有其自身的缺点 1采用螺旋模型需要具有相当丰富的风险评估经验和专业知识。在风险较大的项目开发中如果未能及时标识风险势必会造成重大损失。 2过多的迭代次数会增加开发成本延迟提交时间。 五、增量模型 演化模型的另一种形式是增量模型。在系统的技术架构成熟、风险较低的时候可以采用增量的方式进行系统开发这样可以提前进行集成测试和系统测试缩短初始版本的发布周期提高用户对系统的可见度。 对于增量模型通常有两种策略。一是增量发布的办法。即首先做好系统的分析和设计工作然后将系统划分为若干不同的版本每一个版本都是一个完整的系统后一版本以前一版本为基础进行开发扩充前一版本的功能。在这种策略中第一版本往往是系统的核心功能可以满足用户最基本的需求随着增量的发布系统的功能逐步地丰富、完善起来。用户在很短的时间内就可以得到系统的初始版本并进行试用。试用中的问题可以很快地反馈到后续开发中从而降低了系统的风险。在应用增量模型中需要注意 1每一个版本都是一个完整的版本。虽然最初的几个增量不能完全地实现用户需求但这些版本都是完整的、可用的。 2版本间的增量要均匀这一点是很重要的。如果第一个版本花费一个月的时间而第二个版本需要花费 6 个月的时间这种不均匀的分配会降低增量发布的意义需要重新调整。 另一种策略是原型法。同增量发布不同原型法的每一次迭代都经过一个完整的生命周期。当用户需求很不明确或技术架构中存在很多不可知因素的时候可以采用原型法。在初始的原型中针对一般性的用户需求进行快速实现并不考虑算法的合理性或系统的稳定性。这个原型的主要目的是获得精确的用户需求或验证架构的可用性。一般情况下会在后面的开发中抛弃这个原型重新实现完整的系统。 六、构件组装模型 随着软构件技术的发展人们开始尝试利用软构件进行搭积木式的开发即构件组装模型。在构建组装模型中当经过需求分析定义出软件功能后将对构件的组装结构进行设计将系统划分成一组构件的集合明确构件之间的关系。在确定了系统构件后则将独立完成每一个构件这时既可以开发软件构件也可以重用已有的构件当然也可以购买或选用第三方的构件。构件是独立的、自包容的因此架构的开发也是独立的构件之间通过接口相互协作。 构件组装模型的一般开发过程如图 6-4 所示。 构件组装模型的优点如下 1构件的自包容性让系统的扩展变得更加容易 2设计良好的构件更容易被重用降低软件开发成本 3构件的粒度较整个系统更小因此安排开发任务更加灵活可以将开发团队分成若干组并行地独立开发构件。 鱼与熊掌不可兼得构件组装模型也有明显的缺点 1对构件的设计需要经验丰富的架构设计师设计不良的构件难以实现构件的优点降低构件组装模型的重用度。 2在考虑软件的重用度时往往会对其他方面做出让步如性能等。 3使用构件组装应用程序时要求程序员熟练地掌握构件增加了研发人员的学习成本。 4第三方构件库的质量会最终影响到软件的质量而第三方构件库的质量往往是开发团队难以控制的。
