精华内容
下载资源
问答
  • 项目生命周期、开发生命周期与产品生命周期的区别
    千次阅读
    2020-11-18 09:38:25

    项目生命周期、开发生命周期与产品生命周期的区别

    项目生命周期

    项目生命周期是指项目从启动到完成开始到结束所经历的一系列阶段。
    项目生命周期的类别:预测型和适应型。

    开发生命周期

    开发生命周期是指在项目生命周期内与服务或产品的开发有关的一个或多个阶段。
    开发生命周期的类别:预测型、迭代型、增量型、适应型、混合型。
    1、预测型生命周期,也称为瀑布型生命周期,在生命周期的早期阶段确定项目范围、时间和成本。
    2、迭代型生命周期,项目范围通常在项目生命周期的早期确定,但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。
    3、增量型生命周期,通过在预定的时间区内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后,可交付成果具有了必要和足够的能力,才能视为完整。
    4、适应型生命周期,也被称为敏捷或变更驱动型生命周期,属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。
    5、混合型生命周期是预测型生命周期和适应型生命周期的组合。

    产品生命周期

    产品生命周期是指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

    更多相关内容
  • 安全开发生命周期(SDL)是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。安全应用从安全设计开始,软件的安全问题很大一部分是由于不安全的设计而引入的,微软用多年的...
  • 软件开发生命周期管理是指在软件立项 → 软件开发 → 软件维护 几个阶段中,通过相关工具与文档对开发流程进行监控与管理,以保证软件开发的进度与质量。 这个资源列举出了相应流程的输出文档。
  • 轻量级应用安全开发生命周期管理实践.pdf
  • 本文给大家介绍Activity的生命周期,如果大家学习过iOS的小伙伴的话,Activity的生命周期和iOS中ViewController的生命周期非常类似。生命周期,并不难理解。一个人的生命周期莫过于生老病死,花儿的生命周期就是花...
  • [软件安全开发生命周期].(美)霍华德等.扫描版。这是全书完整版,共355页,非常清晰。
  • 四、项目生命周期和开发生命周期

    千次阅读 2019-10-09 00:00:00
    一、简介 我们知道项目是暂时性、临时性的工作,具有开始时间和结束时间。正如达尔文进化论与马克思主义哲学认为:世界上任何事物都有其产生、发展和灭亡的过程(自然生命...开发生命周期: 项目生命周期内通常有...

    一、简介

    我们知道项目是暂时性、临时性的工作,具有开始时间和结束时间。正如达尔文进化论与马克思主义哲学认为:世界上任何事物都有其产生、发展和灭亡的过程(自然生命周期)。项目同样有其生命周期,即开始、计划、执行和结束。

    项目生命周期: 项目的生命周期是描述项目从开始到结束所经历的一系列阶段。
    项目生命周期类型: 预测型或适应型。

    开发生命周期: 项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关,这些阶段称为开发生命周期。
    开发生命周期类型: 预测型、迭代型、增量型、适应型或混合型。

    产品生命周期: 项目生命周期与产品生命周期相互独立, 产品生命周期可能由项目产生。产品生命周期是指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

    二、生命周期

    开发生命周期类型

    • 预测型生命周期(瀑布型生命周期)
    • 迭代型生命周期
    • 增量型生命周期
    • 适应型生命周期(敏捷型或者变更驱动型生命周期)
    • 混合型生命周期

    定义

    1. 预测型生命周期(瀑布型生命周期)

    在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。

    适用于充分了解产品,有厚实的行业基础(传统行业)。在早期就定制好所有计划,然后按计划执行,最后一次性交付。

    例如:一个厨师负责一个婚宴,婚宴的菜单,参加的人数,举办的时间早在1周前就已经确定,厨师只需要保证能根据菜单在举办婚宴的时间把一道道佳肴端上餐桌即可。面对这样需求明确,时间明确,成本明确的项目,最适合的就是预测型生命周期。

    至上而下,从前到后。

    2. 迭代型生命周期

    在生命周期的早期阶段确定项目范围,但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。

    适用于需要通过一系列重复的循环活动来渐进地完善产品质量的项目。

    例如:依然是那个厨师,他希望能改进红烧肉这道菜肴。那么他需要调味,出菜,试吃,收集反馈,再调味,出菜,试吃,收集反馈,再调味………………最终,达到改进红烧肉这道菜肴的目的。

    从粗略到精细,从模糊到清晰。

    3. 增量型生命周期

    预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后,可交付成果具有了必要和足够的能力,才能被视为完整的。

    适用于需要进行拆分,分布实施,已达到最终项目目标的项目。

    例如:依然是那个厨师,他希望做出一桌佳肴,但是他没有办法在一锅做出所有的菜肴,他只能是先做红烧肉,再做清蒸鲈鱼,再做糖醋里脊……,最终实现一桌美味菜肴的目的。

    每次只交付一部分,分步完成。

    4. 适应型生命周期(敏捷型或者变更驱动型生命周期)

    详细范围在迭代开始之前就得到了定义和批准。

    属于敏捷性、与迭代型或增量型(相似),区别是迭代和增量都是在预知需求的前提下,而适应更多的是响应变化对项目的需求和范围并不十分明确。

    适用于软件开发等,将项目划分为若干个短小的迭代周期,在每个周期都产出可验证的交付物,以此来获取用户反馈,从而最终产出可交付物。

    例如:依然是那个厨师,LY说她想吃个肉,问她想吃什么肉,她自己也不知道。于是厨师就只有尝试,先做了鸡肉,她说不好吃;又做了猪肉,她说还凑合,最后做了牛肉,她说这就是我想吃的。

    不断地更新迭代,最终完成。

    5. 混合型生命周期

    是预测型生命周期和适应型生命周期的组合。

    充分了解或有确定需求的项目要素遵循预测型开发生命周期,而仍在发展中的要素遵循适应型开发生命周期。

    连续区间

    从上图中可以看出:

    1. 预测生命周期的交付频率和变化频率都很低,因为它提前计划、连续执行,一次性交付。
    2. 迭代型生命周期则是变化频率高,因为它在不断进行反馈,进行调整。
    3. 增量型生命周期则是交付频率高,因为他不断地提交可交付物。
    4. 敏捷型生命周期则是结合了迭代生命周期和增量型生命周期的特点,既能适应不断的变化,又能快速交付,这就是为什么敏捷管理的优势。

    特点

    Stacey 矩阵

    1区: 需求明确,技术方案也确定,这类项目就叫做简单(Simple)项目。
    2区: 需求明确,技术却不明确,也就是说不知道怎么实现,这类项目就叫做复杂(Complex)的项目,也称为棘手的项目。例如:无人驾驶项目。
    3区: 技术确定,需求却不明确,这类项目叫做烧脑型(Complicated)项目。例如:开发一个APP,客户都没想好怎么做,只能边做边想,最好增量开发,分成多个阶段交付,减少推到重来的风险
    4区: 需求不明确,技术也不明确,这类项目叫做混乱型(Chaotic)项目,尽量不要碰,基本是要失败的。
    5区: 紫色区域,不属于前四种区域的其他项目,属于模糊型(Hazy)项目。需求和实现方案都不太明确,最好用敏捷开发,适应性强,灵活机动,拥抱变化

    【总结】

    正确认识项目生命周期,对科学规划项目工作,合理调配项目资源,正确管理、监控项目过程,有重要意义。

    展开全文
  • 软件开发过程和软件开发生命周期
  • 例如,软件开发过程 的定义引用自维基百科。本文仅仅是整理记录一些学习重点。如果您发现其中内容有侵权,请随时点击博客右侧的小企鹅进行联系或者直接私信我,我将第一时间进行处理! 概念   软件开发过程(英语...

      接受项目管理培训至今已经有三年时间了,一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头,从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验,希望可以帮助到从事项目管理的人!

      由于本文中的大多数术语都是一些规范或者约定俗称的概念,因此,本文的大部分内容都是来自于互联网。例如,软件开发过程 的定义引用自维基百科。本文仅仅是整理记录一些学习重点。如果您发现其中内容有侵权,请随时点击博客右侧的小企鹅进行联系或者直接私信我,我将第一时间进行处理!

    概念

      软件开发生命周期(Software Development Life Cycle,SDLC),又称为软件开发过程(Software Development Process),为软件的开发定义了一个框架,将自动化工具、软件开发方法和质量管理紧密结合在了一起,其各个阶段实现了软件的需求定义与分析、设计、实现、测试、交付和维护。软件开发过程是在开发与构建系统时应遵循的步骤,是软件开发的路线图。
    在这里插入图片描述
    上面这幅图是我在网上找到的(MBA智库),乍一看非常的复杂,甚至出现了哲学范畴的方法论。我个人感觉上图还是非常详细的。不过对于里面的细节并没有详细的介绍,后面我会介绍一下我的理解。

    SDLC 在有的资料里面也称为 系统开发生命周期(Systems Development Life Cycle, SDLC),且将它和软件开发生命周期等价。但是这两者其实是不一样的: 系统 = 软件 + 硬件 。不过他俩的内容基本是一致的。

      软件开发生命周期(SDLC)同时也是一种具有创建高质量软件的清晰定义过程的方法论。 这种 按时间分程 的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。具体而言,SDLC 方法侧重于软件开发的以下阶段:

    • 需求分析
    • 规划
    • 软件设计
    • 软件开发
    • 测试
    • 部署

    需要注意的是,我翻阅了大量介绍软件开发生命周期的文档,他们对于上面的阶段定义并不相同。如下是我在学习中找到的比较多的几种情况:
    在这里插入图片描述
      软件开发生命周期(SDLC)可被视作最早的形式化方法。SDLC 的主要想法是,在采用框架时应当“以审慎、结构化和方法化的方式开发信息系统。生命周期中的每个阶段,从概念提出到系统交付,都应当严格、依次地进行”。

      在实际的开发过程中,开发者们不断的总结归纳,最终形成了一些比较统一开发模式。这些开发模式就是一个个被称为软件开发过程模型(Software Development Process Models)。其中最著名的就应该是瀑布模型了。如下是一些常用的模型:
    在这里插入图片描述
    更进一步,一些业内的大佬还为某些过程模型制定了相应的规范。后面我们将介绍一些常见的过程模型。

      随着新的面向对象的设计方法和技术(包括后来的敏捷开发方法)的成熟,软件生命周期设计方法的指导意义正在逐步减少。但是,作为最早的开发方法,其为后续的软件开发影响深远(基本确立了软件开发的基本框架,说后续的方法基本都是对于 SDLC 的改进一点也不为过)。

      软件开发生命周期 ≠ \neq = 项目的开发周期 。企业项目中,软件开发生命周期 仅仅是项目开发周期的一部分。至于一个项目的具体阶段,则不同的公司有不同的规定(一般都有自己的标准指导文档)。

    软件开发方法论

      软件开发方法论(Software Development Methodology, SDM)框架是在 20 世纪 60 年代开始出现的。软件开发方法历史中的重要事件(引用自维基百科)有:

    我个人认为,软件开发生命周期(SDLC)可以分为宏观和微观两个维度。在宏观上,软件开发生命周期(SDLC)是指的软件开发的整个生命周期,其中包含各种方法论,工具等
    在这里插入图片描述
    在微观上,软件开发生命周期(SDLC) 本身就是一种方法论,这是由于历史遗留的原因,当初提出这个概念的时候其就是作为一种软件开发方法。
    在这里插入图片描述
    其中,比较特殊的就是快速应用程序开发和敏捷软件开发。

    快速应用程序开发

      快速应用程序开发(Rapid Application Development,RAD)是 SDLC 的一个替代品,它结合原型模型,将应用程序开发和 CASE工具的实现相结合。RAD 的优点是速度快,降低了开发成本,并且使用户更积极地参与开发过程。

    敏捷软件开发

      敏捷软件开发(Agile software development),又称敏捷开发,是一种从1990 年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。“敏捷”(Agile)一词由 “敏捷软件开发宣言”(Manifesto for agile software development)中开始推广,“敏捷软件开发宣言” 定义了相关的价值和原则。
    在这里插入图片描述
      同样在微观上,敏捷开发也可以被认为是指导软件开发过程的一种方法(称为敏捷开发模型)。但是,由于敏捷开发的优势,其逐渐发展为了一种方法论,有了一些列的规范,组织机构等。宏观上的敏捷开发中,包含各种具体的方法。

      敏捷开发更强调人的主观能动性,其价值观是:个体和互动高于流程和工具,工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划。其核心主要在于能够充分了解用户的痛点,将用户痛点分级,每次版本都只解决用户当前最大的痛点,然后通过快速开发的版本迭代满足用户需求从而占领市场,这也是 MVP(最小可用产品)的核心思维。

    敏捷式开发不仅仅是项目上的一种开发方式,同时也能指点我们在生活中采用 2/8 法则,抓住重点,用最小的力度来实现价值最大化。

      敏捷式开发的特性是能够持续性的对软件本体进行不断改造以及处理客户对软件开发过程中的不断介入。敏捷开发的主要优点在于其灵活性。 经过一次次例行的开发迭代期(iterations)后,在每一次迭代期的开始时小组便会考虑向软件引入新的特性和改变,也就不会特别跟随原有的开发要求。

      敏捷开发是现代软件开发中被广泛使用的范式。敏捷软件开发的框架不断的发展,两个最广泛被使用的是 ScrumKanban。敏捷软件开发是一个开发软件的管理新模式,用来替代以文档驱动开发的传统开发模式。

      总结一下就是,敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

       每隔一段时间,Digital.ai 就会发布一次关于敏捷开发的调查 STATE OF AGILE 并发布相应的 STATE OF AGILE 报告,并在 https://stateofagile.com/# 上进行公布。我们可以下载到对应的 PDF 文档。下面是最新的第 14 调查报告中的 敏捷开发方法使用情况:
    在这里插入图片描述
    该报告中有详细的记载关于敏捷开发的地域使用情况,行业使用情况等。

    敏捷软件开发宣言

      在 2001 年,十七名软件开发人员在犹他州的瓦萨奇山雪鸟滑雪胜地会面,讨论一些轻量级的开发方法,并由 Jeff Sutherland,Ken Schwaber 和 Alistair Cockburn 发起,一同发布了 “敏捷软件开发宣言”(Manifesto for Agile Software Development)。

      参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶方法、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

      这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站(http://www.agilemanifesto.org/)首页的《敏捷软件开发宣言》,他们称自己为“敏捷联盟”。
    在这里插入图片描述
    官网提供了各种语言版本的敏捷软件开发宣言。有兴趣的可以直接去官网查看。

    敏捷联盟

      敏捷联盟(Agile Alliance)是一个全球性的非盈利性成员组织,致力于支持那些探索和应用敏捷价值、原则和实践的人们,使构建软件解决方案更有效、更人性化、更可持续。官方网址:https://www.agilealliance.org/
    在这里插入图片描述

    结构化方法

      结构化编程(Structured programming),一种编程典范。它采用子程序、块结构、for 循环以及 while 循环等结构,来取代传统的 goto。希望借此来改善计算机程序的明晰性、质量以及开发时间,并且避免写出面条式代码。

    面向对象方法

      面向对象方法(Object-Oriented Method)是一种把面向对象的思想应用于软件开发过程中,指导开发活动的系统方法,简称OO (Object-Oriented)方法,是建立在“对象”概念基础上的方法学。

    过程模型

      过程模型就是指导软件开发过程的方法论。过程模型由五个基本的框架活动组成:沟通、计划、建模、构建和部署。他们之间的线性(linear)、迭代(iterative)、演进(evolutionary)和平行(parallel)关系会产生不同的模型。常见的过程模型包括:瀑布模型、V 模型、原型模型、增量模型、螺旋模型等。常见的软件测试模型包括 V 模型、W 模型、H 模型、X 模型和前置模型。

      过程模型(Process Models) 意图解决软件过程中的混乱,将软件开发过程中的沟通、计划、建模、构建和部署等活动(activities)有效地组织了起来。

    瀑布模型

      瀑布模型(Waterfall Model)是最早出现的软件开发模型,是传统软件开发方法的代表。在软件工程中占有重要的地位,它提供了软件开发的基本框架。1970 年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到 80 年代早期,它一直是唯一被广泛采用的软件开发模型。

      瀑布模型将软件生命周期划分为 制定计划、需求分析、软件设计、程序编写、软件测试和运行维护 等六个基本活动,并且规定了它们 自上而下、相互衔接的固定次序 ,如同瀑布流水,逐级下落。其 严格强调文档,前一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。
    在这里插入图片描述

    • 优点:
      1. 让软件开发过程有序可控,为项目提供了按阶段划分的检查点。瀑布模型的每个阶段都有明确的任务,每个阶段都有明确的交付产物,都有相应的里程碑。这些让整个过程更可控,而且能及早发现问题
      2. 当前一阶段完成后,您只需要去关注后续阶段
      3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
      4. 让分工协作变成可能。瀑布模型的六个阶段,也让软件开发产生相应的基础分工:项目经理、产品经理、架构师、软件工程师、测试工程师、运维工程师。
      5. 质量有保障。瀑布模型每个阶段都需要交付相应的文档,而文档的撰写和评审,可以帮助在动手之前把问题沟通清楚,想清楚。瀑布模型在编码结束后,会有严密的测试,只有测试验收通过后,才能上线发布,这些措施都让软件的质量更有保障。
    • 缺点:
      1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
      2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
      3. 没有迭代与反馈。瀑布模型对反馈没有涉及,所以对变化的客户需求非常不容易适应,瀑布就意味着没有回头路。
      4. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
      5. 瀑布模型的突出缺点是不适应用户需求的变化。
      6. 瀑布模型是一种软件文档的开发,把开发者变成流水线上的机器,大量重复性的工作让编程人员提不起兴趣,工作很枯燥,没有激情,编程成了一种没有创意的机械劳动,这让一向以高科技为标志的高级程序人员大为恼火。

      虽然现在瀑布模型已经不是最主流的开发模式。但是不管什么软件项目,不管采用什么开发模式,有四种活动是必不可少的,那就是需求、设计、编码和测试。而这四项活动,都是起源自瀑布模型,也是瀑布模型中核心的部分。 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度,可以方便地界定不同阶段的里程碑。

    V 模型

      1978 年 Kevin Forsberg & Harold Mooz 提出了 V 模型(也被称为验证和验证模型)。V 模型是一个著名的、以测试为驱动的开发模型,该模型强调开发过程中测试贯穿始终,是瀑布模型的一个变体。V 模型反映了开发过程和测试过程的关系,在测试软件的过程中起着非常重要的作用。测试依旧是开发生命周期中的阶段,与瀑布模型不同的是,有多个测试级别与开发阶段对应。
    在这里插入图片描述
      需求分析要分析用户的需要,整理出系统的需求(功能需求),会和用户面谈,建立 用户需求文档(user requirements document);概要设计是系统设计师根据用户需求文档,分析并理解要开发系统的业务流程的阶段,会产生 软件规格文档(software specification document),软件规格文档是开发阶段的蓝图;详细设计也称为低阶设计,会将设计的系统拆解为较小的单元或是模组,说明每一部分的内容,让程式设计者可以直接写程式。

      单元测试主要发现编程和详细设计阶段的错误,测试计划在详细设计阶段制定,在编码阶段完成;集成测试主要发现设计阶段产生的错误,测试计划在概要设计阶段制定,在详细设计阶段完成;系统测试计划在需求分析阶段制定,在概要设计阶段完成;验收测试(User Acceptance Test)计划会在需求分析阶段就订定,测试计划是由企业用户来进行。

    与瀑布模型一样,V 模式是一种传统软件开发模型,在当前互联网软件开发中,局限性还是比较大的!

    • 优点:
      1. 包含了底层测试(单元测试)和高层测试(系统测试)
      2. 清楚的标识了开发和测试的各个阶段
      3. 自上而下逐步求精,每个阶段分工明确,便于整体项目的把控
      4. 像计划、测试设计这样的测试活动会在编码之前很好地进行。这节省了很多时间。因此相比于瀑布模型,成功的几率更高。
    • 缺点:
      1. 测试与开发是串行进行的而不是并行,自上而下的顺序导致了,测试工作在编码之后,就导致错误不能及时的进行修改
      2. 实际工作中,需求经常变化,导致 V 模型步骤,反复执行,返工量很大,灵活度较低
      3. V 模型太过简单,无法准确的反映软件开发的过程,会让管理者有一种错误的安全感。V 模型反映了软件开发中,管理者的观点,适合专案管理者、会计师及律师,但不适合软件开发者及用户
      4. V 模型和瀑布模型一样,过程中产生大量文档,项目反应速度也越来越不能满足当前日新月异的需求和快速的更新换代的节奏。

      V 模型的软件开发不是以直线的方式进行,其过程在源代码阶段之前逐步往下,而在源代码阶段之后逐步往上,形成了 V 字形。V 模型指出了软件开发中的各阶段以及其对应软件测试阶段之间的关系。横轴表示时间或是项目的完成度,而纵轴表示抽象的程度(范围越大,越抽象的在越上方)。

      V 模型的中心思想是研发人员和测试人员需要同时工作,在软件做需求分析的同时就会有测试用例的跟踪。 这样可以尽快找出程序错误和需求偏离,从而更高效的提高程序质量,最大可能的减少成本,同时满足用户的实际软件需求。V 模型的重要意义在于,非常明确的表明了测试过程中存在的不同的级别,并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。

    1. 据说这是 IBM 的测试模型
    2. V 模型在汽车行业的影响深刻

    W 模型

      W 模型是由 Evolutif 公司提出,相对于 V 模型,W 模型增加了软件开发各阶段中同步进行的验证和确认活动。W 模型由两个 V 字型模型组成,一个 V 是开发的生命同期,另一个 V 是测试的生命周期,其明确表示出了测试与开发的并行关系(如下图)。
    在这里插入图片描述
      W 模型与 V 模型有一个很大的不同,就是 W 模型是一个并行的模型,V 模型是一个串行的模型。W 模型测试是从需求分析开始就开始了,而不是等到编码完成后才开始。并且测试阶段的划分更清楚,而不仅仅是单元测试、集成测试、系统测试,还包括前期的测试计划、测试方案等内容,这更符合现在企业测试的流程。W 模型具有以下特征:

    1. 测试阶段划分得更全面,不仅仅是单元测试、集成测试和系统测试。测试的对象不仅是程序,需求、设计等同样要测试
    2. 测试与开发是并行的,从需求测试就应该开始介入
    3. 提出尽早测试的概念,这样可以降低缺陷修复成本
    4. 测试对象不仅仅是程序,还包括需求或其他的相关文档

    W 模型仍然是以文档驱动的传统开发方式的一个变种

    • 优点:
      1. 开发伴随着整个开发周期,需求和设计同样要测试
      2. 更早的介入测试,可以发现初期的缺陷,修复成本低
      3. 分阶段工作,方便项目整体管理。
    • 缺点:
      1. 开发和测试依然是线性的关系,需求的变更和调整,依然不方便,样就无法支持迭代的开发模型
      2. 如果没有文档,根本无法执行 W 模型;对于项目组成员的技术要求更高!

    快速原型模型

      快速原型模型(Rapid Prototype Model)又称原型模型,它是增量模型的另一种形式;它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。下图显示了快速原型模型开发的基本步骤:
    在这里插入图片描述
      由于种种原因,在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的。快速原型是利用原型辅助软件开发的一种新思想。 经过简单快速分析,快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提高软件质量。

    • 优点
      1. 原型系统已经通过与用户交互而得到验证,克服瀑布模型的缺点,据此产生的规格说明可以正确地描述用户的需求。因此,在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
      2. 开发人员通过建立原型系统已经学到了许多东西(至少知道了“系统不应该做什么,以及怎么不去做不该做的事情”),因此,在设计和编码阶段发生错误的可能性也比较小,这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
    • 缺点
      1. 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下,因此不适合大型系统的开发(适合开发小型的、灵活性高的系统)。
      2. 使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新
      3. 所选用的原型(开发技术和工具)不一定符合主流的发展
      4. 快速原型模型是不带反馈环的,软件产品的开发基本上是按线性顺序进行的。

    现在很多互联网企业提供了各式各样的原型设计工具,例如:Mockplus、Balsamiq、Axure 等。

    增量模型

      增量模型(Incremental Model)融合了瀑布模型的基本成分(重复应用)和原型实现的迭代特征,该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。产品被分解为多个组件,每个组件都是单独设计和构建的。各个构件完成后逐渐并入已有的软件体系结构中。

      当使用增量模型时,第 1 个增量往往是核心的产品,即第 1 个增量实现了基本的需求,但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示:
    在这里插入图片描述
      在增量模型中,每个迭代阶段都得到开发,因此每个阶段都将经历软件开发生命周期的要求、设计、编码,最后是测试模块。每个阶段开发的功能都将添加到以前开发的功能上,在软件完全开发之前,该功能将重复。在每个增量阶段,都会进行审查,根据审查,下一阶段的决定将作出。

      增量模型与原型实现模型和其他演化方法一样,本质上是迭代的,但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本,但提供了为用户服务的功能,并且为用户提供了评估的平台。

      增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。

    增量模型的特征:

    1. 系统被分解成许多小型开发项目。
    2. 部分系统是为了生成最终系统而构建的。
    3. 首先满足最高优先级要求。
    4. 一旦开发递增部分,部分的需求将被冻结。

    增量模型的优缺点:

    • 优点
    1. 采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源。如果核心产品很受欢迎,则可增加人力实现下一个增量。因此,增量能够有计划地管理技术风险。
    2. 每次迭代后,应执行回归测试。在此测试期间,可以快速识别软件的故障元素,因为在任何单个迭代中很少进行更改。
    3. 测试和调试比其他类型的软件开发方法更容易,因为每次迭代时所做的更改相对较小。这允许对整个产品中的每个元素进行更有针对性的、更严格的测试。
    4. 客户可以响应功能并查看产品,以了解任何需要或有用的更改。
    5. 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型
    • 缺点
    1. 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构
    2. 在开发过程中,需求的变化是不可避免的。很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
    3. 如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析
    4. 随着产品增加了其他功能,可能会出现与系统体系结构相关的问题,而早期原型中并不明显
    5. 由增量产生的成本可能会超过组织的成本。

    增量理念也用于敏捷流程模型

    螺旋模型

      螺旋模型(Spiral Model)是巴利·玻姆(Barry Boehm)于 1988 年 5 月在他的文章《一种螺旋式的软件开发与强化模型》提出的。它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。螺旋模型最大的特点在于 引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。

      螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它,项目经理在早期就能够为客户实证某些概念。该模型是快速原型法,以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审 4 个阶段,由这 4 个阶段进行迭代。软件开发过程每迭代一次,软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:
    在这里插入图片描述

    • 优点
    1. 通过原型的创建,使软件开发在每个迭代的最初明确方向;
    2. 通过风险分析,最大程度地降低软件彻底失败造成损失的可能性;
    3. 在每个迭代阶段植入软件测试,使每个阶段的质量得到保证;
    4. 整体过程具备很高的灵活性,在开发过程的任何阶段自由应对变化;
    5. 每个迭代阶段累计开发成本,使支出状况容易掌握;
    6. 通过对用户反馈的采集,与用户沟通,以保证用户需求的最大实现;
    • 缺点
    1. 过分依赖风险分析经验与技术,一旦在风险分析过程中出现偏差将造成重大损失;
    2. 过于灵活的开发过程不利于已经签署合同的客户与开发者之间的协调;
    3. 由于只适用大型软件,过大的风险管理支出会影响客户的最终收益;

      螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。在需求不明确的情况下,适合用螺旋模型进行开发,便于风险控制和需求变更。

    敏捷开发方法

    见后续独立博文

    参考

    1. https://wiki.mbalib.com/wiki/%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B
    2. https://zhuanlan.zhihu.com/p/183798988
    3. https://blog.si-yee.com/2019/10/03/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E4%B9%8B%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B/
    4. https://zhuanlan.zhihu.com/p/29783716
    5. https://zhuanlan.zhihu.com/p/24417533
    6. https://zhuanlan.zhihu.com/p/150399191
    7. https://www.zhihu.com/question/20014400
    8. https://blog.csdn.net/qq_43725037/article/details/86213779
    9. https://www.cnblogs.com/zhuifeng-mayi/p/9853123.html
    10. https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/
    11. https://www.cnblogs.com/ITnoteforlsy/p/11938493.html
    12. https://www.guru99.com/v-model-software-testing.html
    13. https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm
    14. http://www.srcmini.com/35680.html
    15. https://zhuanlan.zhihu.com/p/56673435
    16. https://wiki.mbalib.com/wiki/%E5%A2%9E%E9%87%8F%E6%A8%A1%E5%9E%8B
    17. https://www.technotrice.com/incremental-model-in-software-engineering/
    18. https://melsatar.blog/2012/03/21/choosing-the-right-software-development-life-cycle-model/
    19. https://www.visual-paradigm.com/scrum/scrum-in-3-minutes/
    20. https://tech.gsa.gov/guides/popular_approaches/
    21. https://kknews.cc/tech/e8qgp9z.html
    展开全文
  • 软件开发生命周期汇总

    千次阅读 2020-09-21 06:28:14
    开发模型知识点中,软件生命周期的概念、各种开发模型的特点和应用场合。主要的开发模型有瀑布模型、增量模型、螺旋模型、喷泉模型、智能模型、V模型、RAD模型、CBSD模型、原型方法、XP方...

    在开发模型知识点中,软件生命周期的概念、各种开发模型的特点和应用场合。主要的开发模型有瀑布模型、增量模型、螺旋模型、喷泉模型、智能模型、V模型、RAD模型、CBSD模型、原型方法、XP方法、RUP方法等。

    瀑布模型

    瀑布模型也称为生命周期法,是生命周期法中最常用的开发模型,它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段,规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

    • 软件计划:主要确定软件的开发目标及其可行性。

    • 需求分析:在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段,这一阶段做得好,将为整个软件开发项目的成功打下良好的基础。

    • 软件设计:主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计、数据库设计等。软件设计一般分为总体设计(概要设计)和详细设计。

    • 程序编码:将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须制定统一、符合标准的编写规范,以保证程序的可读性,易维护性,提高程序的运行效率。

    • 软件测试:在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性。

    • 软件维护:软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求,要延续软件的使用寿命,就必须对软件进行维护。

    变换模型

    变换模型(演化模型)是在快速开发一个原型的基础上,根据用户在调用原型的过程中提出的反馈意见和建议,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产品。

    螺旋模型

    螺旋模型将瀑布模型和变换模型相结合,它综合了两者的优点,并增加了风险分析。它以原型为基础,沿着螺线自内向外旋转,每旋转一圈都要经过制订计划、风险分析、实施工程、客户评价等活动,并开发原型的一个新版本。经过若干次螺旋上升的过程,得到最终的系统。

    喷泉模型

    喷泉模型对软件复用和生命周期中多项开发活动的集成提供了支持,主要支持面向对象的开发方法。"喷泉"一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次,相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中,分析、设计和编码之间不存在明显的边界。

    V模型

    在开发模型中,测试常常作为亡羊补牢的事后行为,但也有以测试为中心的开发模型,那就是V模型。V模型只得到软件业内比较模糊的认可。V模型宣称测试并不是一个事后弥补行为,而是一个同开发过程同样重要的过程。

    V模型描述了一些不同的测试级别,并说明了这些级别所对应的生命周期中不同的阶段。在图中,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即测试过程的各个阶段。请注意在不同的组织中,对测试阶段的命名可能有所不同。V模型的价值在于它非常明确地表明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系:

    • 单元测试的主要目的是针对编码过程中可能存在的各种错误。例如:用户输入验证过程中的边界值的错误。

    • 集成测试的主要目的是针对详细设计中可能存在的问题,尤其是检查各单元与其他程序部分之间的接口上可能存在的错误。

    • 系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行。例如:在产品设置中是否达到了预期的高性能。

    • 验收测试通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。

    增量模型

    增量模型像原型实现模型和其他演化方法一样,本质上是迭代的。但与原型实现不同的是增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的"可拆卸"版本,但它们确实提供了为用户服务的功能,并且提供了给用户评估的平台。增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求,还需要更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。

    RAD模型

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

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

    • 业务建模:以什么信息驱动业务过程运作?要生成什么信息?谁生成它?信息流的去向是哪里?由谁处理?可以辅之以数据流图。

    • 数据建模:为支持业务过程的数据流,找数据对象集合,定义数据对象属性,与其他数据对象的关系构成数据模型,可辅之以E-R图。

    • 过程建模:使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找,即细化数据流图中的处理框。

    • 应用程序生成:利用第四代语言(4GL)写出处理程序,重用已有构件或创建新的可重用构件,利用环境提供的工具自动生成并构造出整个应用系统。

    • 测试与交付,由于大量重用,一般只做总体测试,但新创建的构件还是要测试的。

    基于构件的模型

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

    原型方法

    软件原型是所提出的新产品的部分实现,建立原型的主要目的是为了解决在产品开发的早期阶段的需求不确定的问题,其目的是明确并完善需求、探索设计选择方案、发展为最终的产品。原型有很多种分类方法。从原型是否实现功能来分,软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型,用来探索预期系统的一些特定行为,并达到细化需求的目的。水平原型通常只是功能的导航,但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型,实现了一部分功能。垂直原型主要用在复杂的算法实现上。

    XP方法

    XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比,其最大的不同在于:

    • 在更短的周期内,更早地提供具体、持续的反馈信息。

    • 迭代地进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断地发展它。

    • 依赖于自动测试程序来监控开发进度,并及早地捕获缺陷。

    • 依赖于口头交流、测试和源程序进行沟通。

    • 倡导持续的演化式的设计。

      依赖于开发团队内部的紧密协作。

      尽可能达到程序员短期利益和项目长期利益的平衡。

    RUP方法

    RUP(Rational Unified Process)是一个统一的软件开发过程,是一个通用过程框架,可以应付种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。RUP是基于构件的,这意味着利用它开发的软件系统是由构件构成的,构件之间通过定义良好的接口相互联系。在准备软件系统所有蓝图的时候,RUP使用的是统一建模语言UML.与其他软件过程相比,RUP具有三个显著的特点:用例驱动、以基本架构为中心、迭代和增量。RUP中的软件过程在时间上被分解为四个顺序的阶段,分别是初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审,以确定这个阶段的目标是否已经满足。如果评审结果令人满意,就可以允许项目进入下一个阶段。

    展开全文
  • 微服务[开发生命周期]

    万次阅读 2021-10-22 00:41:26
    在个体层面,开发者需要熟悉每一个微服务,即便它可能非常小,为了开发一个微服务,开发者会使用很多相同的技术框架和技术:Web应用框架、SQL数据库、单元测试、类库等等,这些都是开发者在开发应用程序时经常会用到...
  • 管理信息系统:第十二章 信息系统开发生命周期.ppt
  • 软件开发生命周期及各阶段文档

    千次阅读 2021-04-05 20:12:07
    软件开发生命周期及各阶段文档 本文主要有两方面内容: 软件开发生命周期各阶段 软件开发生命周期各阶段所涉及的文档 软件开发生命周期 软件开发生命周期定义: 软件从定义到消亡所经历的过程。 软件开发生命周期...
  • 软件开发生命周期模型总结

    千次阅读 2018-12-22 10:47:23
     虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段...
  • 软件安全开发生命周期;软件安全开发生命周期SDL 基于WEB应用程序的SDL;简介 安全需求分析 安全设计 安全编程 安全测试 安全部署及安全响应 ;简介 安全开发周期即Security Development Lifecycle (SDL)是微软提出的从...
  • 软件工程:软件开发生命周期 (SDLC)

    万次阅读 多人点赞 2019-02-11 17:28:30
    软件构建的基本概念之一 - 软件开发生命周期模型。或者只是SDLC模型。SDLC - 是一个连续的过程,从决定启动项目的那一刻开始,并在它完全从开发中移除的那一刻结束。没有一个单一的SDLC模型。它们分为主要组,每组都...
  • Team-Foundation-Server管理软件开发生命周期.ppt,帮助开发人员更好的进行软件开发各个阶段的管理和控制。
  • 软件安全开发生命周期-基础理论

    千次阅读 2018-05-25 17:32:02
    一、SDL简介SDL security development lifecycle(安全开发生命周期),是微软提出的从安全角度指导软件开发过程的管理模式。SDL是一个安全保证的过程,起重点是软件开发,它在开发的所有阶段都引入了安全和隐私的...
  •  在创建项目时,或许你会发现,在创建项目向导时多了一个选项,而且是默认选中的,那就是“安全开发生命周期(SDL)检查(C)”。如下图所示:  默认这个检查之后,再也不能好好撸代码了。对代码做了很多安全性检测,...
  • 软件开发生命周期及文档

    千次阅读 2017-04-14 17:20:13
    软件开发,同任何事物一样要经历孕育、诞生、成长、成熟、结束等阶段,称之为软件开发生命周期。 通常,软件开发生命周期包括可行性分析与项目开发计划、需求分析、设计、编码、测试、发布维护等。 1)可行性...
  • 2.1 软件开发生命周期模型

    千次阅读 2018-10-05 16:57:05
    软件开发生命周期模型描述了在软件开发项目的每个阶段开展的活动类型,以及这些活动在逻辑上和时间上是如何相互关联的。有许多不同的软件开发生命周期模型,每个模型都需要不同的测试方法。 2.1.1 软件开发和软件...
  • 软件开发生命周期的五个阶段

    千次阅读 2019-10-28 15:14:27
    一个软件从定义,开发,运行维护,直到最终要经历一个时期的过程 ,这个时期称为软件的生命周期 系统软件生命周期一般为分析,设计,实现和测试与维护这几个阶段, 分析阶段: 软件开发首先需要进行需求调研和分析...
  • 刚开始在学习使用 scanf 的时候,vs2017和vc++一直无法编译成功,总是报错,查询代码也没有问题,后来问了学长发现,是当时建项目的时候,没有勾选掉安全开发生命周期,导致检测不安全。 比如下面的错误 C4996 '...
  • RUP软件开发生命周期

    千次阅读 2018-10-25 11:30:44
    生命周期阶段 1.起始阶段-为项目建立一个业务案例 (1)意图: 建立业务模型用例 明确项目的范围 (2)结果: 项目的实际需求 初始的业务案例。包括:成功准则,风险评估,所需资源评估,显示主要里程碑进度表的阶段...
  • IEC62304 描述医疗行业的软件开发生命周期
  • 外包项目开发课程整理一:SDLC传统系统开发生命周期7个阶段 前言: 课程全称为:通过案例学习外包项目开发,是软件工程专业大三下的课程,我将根据中方外方ppt教授讲述内容及上网搜索的知识对本课程进行系统的整理,...
  • 安全开发生命周期

    2011-10-27 16:12:55
    描述安全开发生命周期SDL概念、模型及应用等
  • 《软件开发生命周期与统一建模语言UML》-曹静-电子教案-5243
  • 系统开发生命周期

    千次阅读 热门讨论 2016-11-27 17:06:48
    首先讲讲什么是系统开发生命周期,首先它是一个系统建立的过程,其次它是由系统分析员,软件工程师,程序员和用户共同建立的。 此过程分六个部分,每部分环环相扣,联系紧密,所以实际进行软件开发项目时一定要耐心...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 495,270
精华内容 198,108
关键字:

开发生命周期

友情链接: 水平集.zip