首页
Python
Java
IOS
Andorid
NodeJS
JavaScript
HTML5
【
敏捷软件开发Note
】的更多相关文章
敏捷软件开发Note
[敏捷原则] 1.我们最优先要做的是通过尽早的.持续的交付有价值的软件为使客户满意. 初期交付的系统中所包含的功能越少,最终交付的系统的质量就越高.交付的越频繁,最终的产品质量就越高.敏捷实践会说早地.经常地进行交付. 2.即使到了开发后期,也欢迎改变需求.敏捷过程利用变化为为客户创造竞争优势. 3.经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好. 4.工作的软件是首要的进度度量标准. 5.敏捷过程提倡可持续的开发速度.责任人.开发者和用户应该能够保持一个长…
敏捷软件开发VS传统软件工程
敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中"人"的作用. 本文将介绍敏捷软件开发的历史背景与发展,…
敏捷软件开发 VS. 传统软件工程
敏捷软件开发 VS. 传统软件工程 软件工程这一术语1968年被提出,之后美国软件工程专家巴利·玻姆对十多年间研究软件工程的专家学者们提出的一些准则与信条,于1983年对提出软件工程的七条基本定理,将软件工程这一学科具体化,软件工程中开发与管理软件的方法也不断完备.而敏捷软件开发于2001年由Kent Beck和其他16位知名软件开发者提出,敏捷开发是人们对于传统软件开发方式的一种提出的新的挑战.本文将具体介绍软件传统工程与敏捷软件开发两种方法,并对两者进行对比分析. 一.传统软件工程 软件工程…
敏捷软件开发vs传统软件开发
摘要 本文介绍了传统软件开发(着重介绍了传统软件开发中常用的瀑布模型)和敏捷软件开发,以及敏捷开发和传统开发的对比. 一.传统软件开发 比较常用的几种传统软件开发方法:瀑布式开发.迭代式开发.螺旋开发作了对比分析. 瀑布式开发:1970年Winston Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模式,瀑布模型将软件生命周期划分为制定计划.需求分析.软件设计.程序编写.软件测试和运行维护等六个基本活动,并且规定了它们自上而下.相互链接的固定次序…
敏捷软件开发(4)--- TEMPLATE METHOD & STRATEGY 模式
1.TEMPLATE METHOD 泛型,也就是这个模式,是可以基于泛型的. 我们往往会有一些算法,比如排序算法.它的算法部分,我可以把它放在一个基类里面,这样具体类型的比较可以放在子类里面. 看如下冒泡排序算法: package com.joyfulmath.agileexample.template.method; /** * @author deman.lu * @version on 2016-06-09 10:04 */ public abstract class BubbleSort…
敏捷软件开发(3)---COMMAND 模式 & Active Object 模式
COMMAND 模式 command模式非常简单,简单到你无法想象的地方. public interface Command { void execute(); } 这就是一个command模式的样子.也许你会觉得,这有点多此一举吗.但是当你使用他的时候,command模式就会闪现光华. 这样一个场景:经理张三叫leader王二去开发一个项目, 王二就安排李四 去开发这个功能A. 李四何时执行,怎么执行就是他自己的事情了. UML图如上所示: 代码如下: public interface Co…
敏捷软件开发(1)--- STATE 模式
如果状态在运行过程中,不停的切换和改变,我们怎么办? 状态的迁移是我们生活和工程中非常普遍的一个概念.于是在数学上有一种理论来分析和解决这个问题. 有限状态机理论是一个非常成熟的理论,所有动作和流程的迁移可以归结为状态的迁移. 这个理论的前提是: 状态的数目是确定的,或者说是有限的. 状态的迁移方向是固定的,也就是有向的. 状态存储关于过去的信息,就是说:它反映从系统开始到现在时刻的输入变化.转移指示状态变更,并且用必须满足来确使转移发生的条件来描述它.动作是在给定时刻要进行的活动的描述.有多种…
敏捷软件开发:原则、模式与实践——第14章 使用UML
第14章 使用UML 在探索UML的细节之前,我们应该先讲讲何时以及为何使用它.UML的误用和滥用已经对软件项目造成了太多的危害. 14.1 为什么建模 建模就是为了弄清楚某些东西是否可行.当模型比要构建的真实实体便宜很多时,我们就会使用模型来研究设计. 14.1.1 为什么构建软件模型 当我们有一些确定的东西需要测试,并且使用UML要比使用代码测试的代价更低一些是,就使用UML.比如,我有一个关于某个设计的想法.我想知道团队中的其他开发人员是否认为它是一个好的想法,于是,我就在白板上画一幅UM…
敏捷软件开发:原则、模式与实践——第12章 ISP:接口隔离原则
第12章 ISP:接口隔离原则 不应该强迫客户程序依赖并未使用的方法. 这个原则用来处理“胖”接口所存在的缺点.如果类的接口不是内敛的,就表示该类具有“胖”接口.换句话说,类的“胖”接口可以分解成多组方法.每一组方法都服务于一组不同的客户程序.这样,一些客户程序可以使用一组成员函数,而其他客户程序可以使用其他组的成员函数. ISP承认一些对象确实需要非内敛的接口,但是ISP建议客户不应该看到它们作为单一的类存在.相反,客户程序看到的应该是多个具有内敛接口的抽象基类. 12.1 接口污染 如果子类…
敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则
第10章 LSP:Liskov替换原则 Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape…