|
|
知识路径： > 嵌入式系统的项目开发与维护知识 > 系统开发过程及其项目管理 > 系统开发的项目管理基础知识及其常用管理工具 > 开发过程管理知识及工具 >
|
被考次数：8次
被考频率：中频率
总体答错率：50%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：掌握
相关知识点：40个
|
|
|
|
|
产品开发生命周期通常使用过程模型进行表示。过程模型习惯上也称为开发模型，它是系统开发全部过程、活动和任务的结构框架。典型的开发过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。
|
|
|
|
|
|
瀑布模型是将系统生存周期各个活动规定为依线性顺序连接的若干阶段的模型，也称为线性模型。它包括需求分析、设计、实现、测试、运行和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落，如下图所示。
|
|
|
|
|
|
|
|
瀑布模型为系统的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于系统需求很明确的软件项目的模型。
|
|
|
|
瀑布模型假设一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现产生。瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或三个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统的能力。在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。
|
|
|
|
瀑布模型的一个变体是V模型，如下图所示。V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。
|
|
|
|
|
|
|
|
|
|
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如下图所示。当使用增量模型时，第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
|
|
|
|
|
|
|
|
增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了第一个版本，因此可以减少用户需求的变更；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。
|
|
|
|
增量模型有以下不足之处：如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
|
|
|
|
|
|
并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型（rapid prototype）这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况，是一种演化模型（Evolutionary Model）。当系统规模不是很大也不太复杂时，采用该方法比较好。
|
|
|
|
原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型。原型模型如下图所示。
|
|
|
|
|
|
|
|
原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。
|
|
|
|
根据使用原型的目的不同，原型可以分为探索型原型、实验型原型和演化型原型3种。探索型原型的目的是要弄清目标的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型的目的是验证方案或算法的合理性，是在大规模开发和实现前，用于考查方案是否合适、规格说明是否可靠等。演化型原型的目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。
|
|
|
|
|
|
对于复杂的大型系统，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。螺旋模型是一种演化模型。
|
|
|
|
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，如下图所示。在每个螺旋周期分为如下4个工作步骤。
|
|
|
|
|
|
|
|
（1）制订计划。确定系统的目标，选定实施方案，明确项目开发的限制条件。
|
|
|
|
（2）风险分析。分析所选的方案，识别风险，消除风险。
|
|
|
|
|
|
（4）用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。
|
|
|
|
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。
|
|
|
|
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高产品的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了系统开发的风险。在使用螺旋模型进行系统开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。
|
|
|
|
喷泉模型（water fountain model）
|
|
|
|
喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性，如下图所示。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，需求分析活动结束后才开始设计活动，设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。
|
|
|
|
|
|
|
|
喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行。其优点是可以提高项目开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大。
|
|
|
|
形式化方法模型（Formal Methods Model）
|
|
|
|
形式化方法是用于将复杂系统建模为数据实体的技术，是建立在严格数学基础上的一种开发方法，其主要活动是生成计算机软件形式化的数学规格说明。
|
|
|
|
形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。
|
|
|
|
|
|
统一过程的特色是“用例和风险驱动，以架构为中心，迭代的增量开发过程”。迭代的意思是将整个产品开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。
|
|
|
|
|
|
（1）起始阶段（inception phase）。起始阶段专注于项目的初创活动，产生的主要工作产品有构想文档（vision document）、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划（阶段及迭代）、业务模型以及一个或多个原型（需要时）。本阶段的里程碑是生命周期目标。
|
|
|
|
（2）精化阶段（elaboration phase）。精化阶段在理解了最初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求（包括非功能需求）、分析模型、体系结构描述、可执行的体系结构原型、初步的设计模型、修订的风险列表、项目计划（包括迭代计划、调整的工作流、里程碑和技术工作产品）以及初始用户手册。本阶段的里程碑是生命周期架构。
|
|
|
|
（3）构建阶段（construction phase）。构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、系统构件、集成的增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册和对于并发增量的描述）。初始运作功能。
|
|
|
|
（4）移交阶段（transition phase）。移交阶段关注于系统提交方面的工作，产生系统增量，产生的主要工作产品有提交的系统增量、β测试报告和综合用户反馈。本阶段的里程碑是产品发布版本。
|
|
|
|
（5）生产阶段（production phase）。生产阶段对持续使用的软件进行监控，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求。
|
|
|
|
在每个迭代中，有5个核心工作流：捕获系统应该做什么的需求工作流，精化和结构化需求的分析工作流，用系统构架实现需求的设计工作流，构造系统的实现工作流，验证实现是否如期望那样工作的测试工作流。
|
|
|
|
统一过程的典型代表是RUP（Rational Unified Process），主要针对前4个技术阶段。RUP是UP的商业扩展，完全兼容UP，但比UP更完整、更详细。
|
|
|
|
|
|
敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在产品开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。
|
|
|
|
敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。
|
|
|
|
（1）极限编程（XP）。XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。
|
|
|
|
|
|
.5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
|
|
|
|
.12个最佳实践：计划游戏（快速制订计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40个小时、现场客户和编码标准。
|
|
|
|
（2）水晶法（Crystal）。水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。
|
|
|
|
（3）并列争球法（Scrum）。并列争球法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。。
|
|
|
|
（4）自适应软件开发（ASD）。ASD有6个基本的原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。
|
|
|
