软件开发概述--敏捷模式

软件开发生命周期

SDLC--Software Development Life Cycle.

传统的软件开发生命周期有:

  瀑布模型:顺序进行,只有完成上一个阶段才能开启下一个阶段,将软件生命周期分为:制定计划、需求分析、软件设计、编写程序、软件测试及运行维护六个基本活动。优点是为项目提供了按阶段划分的检查点及关注点,必须为其提供模板来使分析、设计、编码、测试、支持有一个共同的指导。缺点是各个阶段划分固定,其间产生大量文档,极大地增加了工作量,用户只有等到整个过程的末期才能看到开发成果,增加了开发风险,不适应用户需求的变化。
  原型模型:建立样品,逐步求精,又称为样品模型,借用已有系统或构建样品作为原型模型,通过对样品的改进满足客户的需求。其优点是可以让开发和用户在原型上达成一致,减少设计中的错误和开发中的风险,缩短开发周期,降低成本。缺点是客户与开发者对原型的理解有差异不适合准确的原型设计,也限制了开发人员的创新。
  螺旋模型:一般系统级应用使用螺旋模型,其引入了风险分析。它是一种演化软件开发过程模型,兼顾了原型模型的迭代和瀑布模型的系统化及严格监控。优点是设计上的灵活性更易于适应客户的需求变化,客户有效的交互保证了项目的正确方向及可控性。缺点是需要具备相当丰富的风险评估经验及专门的知识,而过多的迭代会增加开发成本,延迟交付时间。

敏捷开发

敏捷开发以用户的需求进化为核心,持续迭代的方式进行开发。软件项目在构建初期切分成多个子项目,各个子项目的成果经过测试均具备可视、可集成和可运行使用的特征。敏捷的目标是提高开发效率和响应能力。

敏捷开发模型:

敏捷宣言:

  个体交互高于流程和工具
  可工作软件高于理解文档
  客户协作高于合同协商
  响应变化高于遵循计划

敏捷原则:  

  通过早期和连续型的高价值工作交付满足“客户”。
  大工作分成可以迅速完成的较小组成部门。
  识别最好的工作是从自我组织的团队中出现的,
  为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。
  创建可以改善可持续工作的流程。
  维持完整工作的不变的步调。
  欢迎改变的需求,即时是在项目后期。
  在项目期间每天与项目团队和业务所有者开会。
  在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。
  通过完车的工作量计量工作进度。
  不断地追求完善。
  利用调整获得竞争优势。

敏捷名词一览:

  Scrum: 橄榄球运动的一个专业术语,表示"争球"的动作,把一个开发流程的名字取名为Scrum,意味着大家要像打橄榄球一样迅速、富有战斗激情、高效的工作。  
  Scrum Team: 开发团队,主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每个成员必须有很强的自我管理能力,同时具有一定的表达能力,成员可以采用任何工作方式,只要能达到Sprint目标。
  Product Owner: 产品负责人,主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果
  Scrum Master: 流程管理员,主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发之间的沟通障碍,使得客户可以直接驱动开发
  Sprint burn-down chart:Sprint燃尽图,它显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。
  Product backlog list:产品待办列表,指一个产品或项目期望的、排列好优先级的功能列表。
  Sprint backlog list:Sprint待办列表,Sprint任务清单,从Product backlog list中拉取出来的一部分。
  Sprint:短距离赛跑的意思,这里指一次迭代,周期为2周到1个月时间,即,我们把一次迭代的开发内容以最快的速度完成的过程称为Sprint。
  User story:用户故事,从用户的角度来描述用户渴望得到的功能。

敏捷实践

TDD--测试驱动开发:Test Drive Development,即从测试的角度来检验整个项目。其原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。其基本思路是通过测试来推动整个开发的进行,它是将需求分析、设计、质量控制量化的过程。TDD过程:明确需要完成的功能,针对该功能编写测试用例,编译不通过的测试代码,编写相应的功能代码,执行测试代码直到测试通过,对代码进行重构并保证测试通过,循环完成所有功能的开发。即 不可运行---可运行---重构。TDD原则:独立测试、测试列表、测试驱动、先写断言、可测试性、及时重构、小步前进。

BDD--行为驱动开发:Behavior Drive Development, 是对TDD的一种补充,或者说是TDD的一个分支,与测试概念相比,行为是一种更自然的开发驱动因素,考虑行为会自然而然地促使你先编写规范类,成为一个非常有效的实现驱动因素。测试驱动开发让我们明白测试先行的道理,但是并没有明确告诉我们测试什么,你写出一个测试,但它们不会告诉你应该发生什么也不会告诉你实际预期是什么,它不清楚需求到底是什么。而行为驱动开发旨在帮助开发人员确定应该测试什么。而且行为驱动开发提供了一种通用语言来避免客户与开发之间的不一致,从而实现设计与测试相结合来开发产品。

结对编程:两个程序员在一个计算机上共同工作,一个人输入代码,另一个人审查他输入的每一行代码。优点是程序员互帮互助,可以得到能力上的互补且让编程环境有效贯彻设计及增强代码和产品质量,并有效减少bug,在编程中互相讨论可能更快更有效地解决问题。缺点也很明显,编程人员习惯不同引起的麻烦,或对一个问题争吵不休,若交谈内容与工作无关,反而分散注意力导致效率低下等等。

代码重构:对软件代码做任何更动以增加可读性或简化结构而不影响输出结果。重构的目的是:持续性改进设计,帮助发现隐藏的代码缺陷,提高编程效率。一般重构方法有:封装成员变量,提取方法,一般化类型,方法重命名等。

时间: 2024-11-10 08:10:21

软件开发概述--敏捷模式的相关文章

敏捷软件开发 – ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式

设计运行在简易台灯中的软件.台灯由一个开关和一盏灯组成.可以询问开关是开着还是关着,也可以让灯打开或者关闭. 下面设计了一个简易的模型.Switch对象可以轮询实际开关的状态,并且可以发送相应的turnOn和turnOff消息给Light. 这个设计违反了两个设计原则:依赖倒置(DIP)和开放-封闭(OCP).对DIP的违反是明显的,Switch依赖了具体类Light.DIP告诉我们要优先依赖于抽象类.对OCP的违反虽然没有那么明显,但是更加切中要害.我们之所以不喜欢这个设计是因为它迫使我们在任

敏捷软件开发 – NULL OBJECT模式

考虑以下代码 Employee e = Db.GetEmployee("Bob"); if(e != null && e.IsTimeToPay(today)) { e.Pay(); } 大多数人曾经由于忘记对null进行检查而受挫.该管用手法虽然常见,但却是丑陋且易出错的. 通过让Db.GetEmployee抛出一个异常而不是返回null,可以减少出错的可能性.不过,try/catch块对比null的检查更加丑陋. 可以使用NULL OBJECT模式来解决这些问题.通

传统软件开发与敏捷软件开发的比较

本篇博客分别基于软件开发生命周期和范围管理这两个不同的方面对传统软件开发方法和敏捷软件开发方法进行分析比较,希望与读者分享交流. 传统方法: 从本质来讲,传统软件开发方法是一个软件开发架构,其开发过程是通过一系列阶段顺序展开的.通常,这一方法不能很好地表达和描述用户的需求,而且在项目整个开发周期的所有阶段都有需要不断完善的文档. 敏捷方法: 软件行业飞快发展,软件技术不断创新,客户期望迅速变化,考虑到需要克服传统开发方法的缺点,敏捷开发在近十年来兴起,以其灵活性,易操作性得到软件行业的广泛关注.

软件开发概述

                                                                                       (一)软件开发概述 1.1   软件,程序与计算机语言 软件是为完成某些特定功能而编写的一到多个程序文件的集合 计算机是由电子元件组成的. 1.2  程序语言的发展 1.2.1 机器语言 电子元件的特点是他们有两种很稳定的状态:导电或不导电.早期的计算机程序员用0表示计算机不通电的状态,用1表示计算机通电的状态,然后通过集成

第一章软件开发概述思维导图

第一章软件开发概述思维导图

传统软件开发VS敏捷软件开发

在上世纪60年代,由于计算机的计算能力显著提升,人们需要处理问题的复杂程度也得到提升,导致了一系列问题比如项目运行超过预算.项目运行超过时间.软件十分低效.软件质量很低.软件无法满足需求.项目缺乏管理,代码难以维护.软件难以交付,称为软件危机.人们意识到,软件开发不仅仅是让程序员编写程序那么简单,而是一项工程,需要科学的开发方法,从而人们提出了软件工程的概念,采用工程化的方法对软件开发进行管理.而在当今,软件工程中软件开发方法主要分为传统软件开发和敏捷软件开发.本文主要介绍这两种软件开发方法以及

[书摘]《敏捷软件开发: 原则、模式与实践》第一部分:敏捷开发

面向对象设计的原则 单一职责 开放-封闭 Liskov替换原则 依赖倒置原则 接口隔离原则 重用发布等价原则 共同封闭原则 共同重用原则 无环依赖原则 稳定以来原则 稳定抽象原则 人的重要性 交付产品的关键因素是人,而不是过程.(敏捷 Agile) 人与人之间的交互式复杂的,并且其效果从来都是难以预期,但却是工作中最为重要的方面. ------ Tom DeMacro 和 Timothy Lister<人件> 有凝聚力的团队将具有最强大的软件开发力量. 敏捷软件开发宣言 我们一直在实践中探寻更

敏捷软件开发:原则、模式与实践(笔记)

一.敏捷软件开发宣言 1.个体和交互 > 过程与工具 a)人是获得成功最为重要的因素: b)合作.沟通以及交互能力要比单纯的编程能力更为重要: c)团队的构建要比环境的构建重要. 2.可以工作的软件 > 面面俱到的文档 a)文档应该短小并突出主题: b)在给新的团队成员传授知识方面,最好的两份文档是代码和团队: c)直到迫切需要并且意义重大时,才来编制文档. 3.客户合作 > 合同谈判 a)成功的项目需要有序.频繁的客户反馈. 4.响应变化 > 遵循计划 a)构建计划时,应该确保计

敏捷软件开发---闲话敏捷

第一篇状态模式,其实比本文更先发表.但是我终觉得要写点什么,来开始我的敏捷的旅程.知道看了bob大叔这本书 以后,我才知道敏捷到底是怎么回事,纯属个人东拉西扯,所以就叫闲话敏捷. <敏捷软件开发>问世与2003年,距今已有13个年头了,能够历久长盛不衰,必然有其光辉的一面. 以下都是个人的经验结合<敏捷>讲解和分享一些东西. 敏捷软件开发 乍一看有点摸不着头脑,不知道是什么东西. 软件开发从计算机问世直接快60个年头了.软件也从非常简单的机器语言,到现在的面向对象. 在这个过程中,