CSC/ECE 517 Fall 2009/wiki3 11 HJ3: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(28 intermediate revisions by the same user not shown)
Line 6: Line 6:




Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.   Simply put, Agile allows your team to identify the most critical features of the software that can be completed within a short time frame (normally 1 to 2 months), and it delivers a complete build with this set of limited features as the first iteration. Once that is done, you can move those features to production or continue on to the next iteration.  By breaking the releases into shorter stints, it allows you to gain quicker releases and to capture return on investment more quickly by putting the working (but limited) features into production sooner.  This is in stark contrast to the more traditional "Waterfall" approach, where you design all features upfront, code each one, test each one, then move into production. Agile projects are iteratively released to production months where Waterfall projects normally span a year or more before they are released to production.
Agile software development [http://en.wikipedia.org/wiki/Agile_software_development] is a software development methodologies based on iterative development throughout the life-cycle of the project. The term was coined in the year 2001 when the Agile Manifesto [http://en.wikipedia.org/wiki/Agile_Manifesto] was formulated.
 
Agile methods generally promote a disciplined project management process that promotes frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
 


== Extreme Programming (XP) ==
== Extreme Programming (XP) ==
Line 14: Line 13:
=== Overview ===
=== Overview ===


XP (eXtreme Programming) is a more radical agile methodology, focusing on the software development process and addressing the analysis, development and test phases with novel approaches aimed at making a substantial difference to the quality of the end product.
Extreme Programming (XP) [http://en.wikipedia.org/wiki/Extreme_Programming] is a radical agile methodology, focusing on the software development process and addressing the analysis, development and test phases with novel approaches aimed at making a substantial difference to the quality of the end product. XP is the most common used Agile method.
 
XP is successful because it stresses customer satisfaction.
XP empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.
XP emphasizes teamwork: managers, customers, and developers are all equal partners in a collaborative team.
XP implements a simple, yet effective environment enabling teams to become highly productive: the team self-organizes around the problem to solve it as efficiently and as fast as possible.


== Adaptive Software Development (ASD) ==
== Adaptive Software Development (ASD) ==
Line 21: Line 23:
=== Overview ===
=== Overview ===


Adaptive Software Development (ASD) is a software development process that grew out of rapid application development.  
Adaptive Software Development [http://en.wikipedia.org/wiki/Adaptive_Software_Development] is a software development process that grew out of rapid application development work which embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
ASD is based on a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant.


ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant.


The word “speculate” refers to the paradox of planning – it is more likely to assume that all stakeholders are comparably wrong for certain aspects of the project’s mission, while trying to define it. Collaboration refers to the efforts for balancing the work based on predictable parts of the environment (planning and guiding them) and adapting to the uncertain surrounding mix of changes caused by various factors – technology, requirements, stakeholders, software vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations with design, build and testing. During these iterations the knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes, thus leading to greater experience and eventually mastery in the problem domain. [1]
=== Strength ===


* Reduced cycle time and improved productivity
* Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs


=== Strength ===


*
=== Weakness ===
*
*
*


=== Weakness ===
* Risk of never achieving closure
* Requires a system that can be modularized
* Developers and customers must be committed to rapid-fire activities in an abbreviated time frame
* Accelerated development process must give quick responses to the user


*
*


=== Differences from XP ===
=== Differences from XP ===
In ASD, human relationship must have the ability to adapt whereas in XP, the human relationship is based on the work satisfaction.
In ASD, humans utilize technology as will whereas in XP, they utilize technology within predefined framework.
In ASD, the purpose of the development is the survival and thriving of organization whereas in XP, it is the product delivery while we are doing satisfying work.


== Scrum ==
== Scrum ==
Line 47: Line 51:
=== Overview ===
=== Overview ===


SCRUM is also an agile development method, which concentrates particularly on how to manage tasks within a team-based development environment.
Scrum [http://en.wikipedia.org/wiki/Scrum_%28development%29] is process of implementing Agile, where features are delivered in 30 day sprints. Scrum concentrates particularly on how to manage tasks within a team-based development environment.


[[Image: ScrumLargeLabelled.png| The Scrum Process]]


=== Strength ===
=== Strength ===


*  
* Iterative-incremental process
*  
* Based on modeling the problem domain and the system
*  
* Requirements are allowed to evolve over time.
*
* Traceability to requirements through the Product Backlog
* Architecture of the system drafted before the development engine is started
* Iterative development engine governed by careful planning and reviewing
* Active user involvement
* Simple and straightforward process
* Early and frequent releases, demonstrating functionality at the end of each iteration (sprint) of the development cycle


=== Weakness ===
=== Weakness ===


*  
* Integration is done after all increments are built
*  
* Lack of scalability
* Based on the assumption that human communication is sufficient for running projects of any size and keeping them focused
* Not necessarily seamless (details of tasks are not prescribed)
* No clear-cut design effort
* Model-phobic
* Models are not prescribed, leaving it to the developer to decide what model can be useful
* Lack of formalism


=== Differences from XP ===
=== Differences from XP ===


XP and Scrum are so different they are not really comparable.
Scrum is an agile management methodology. Whereas XP is an agile engineering methodology.
Scrum is the more likely starting point when the adoption of agile is driven by managementwhereas XP is the more likely starting point when the adoption of agile is driven by developers.


== Dynamic Systems Development Method (DSDM) ==
== Dynamic Systems Development Method (DSDM) ==
Line 69: Line 88:
=== Overview ===
=== Overview ===


DSDM is probably the most complete agile methodology, whereas SCRUM and XP are easier to implement and complementary because they tackle different aspects of development projects and are both founded on the same principles of agile development.
Dynamic System Development Method (DSDM)
DSDM is probably the original agile development method. DSDM was around before the term 'Agile' was even invented, but is absolutely based on all the principles we’ve come to know as agile development.
[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method#Comparison_to_other_IS_Development_Methods]is another approach to system development, which, as the name suggests, develops the system dynamically. This methodology is independent of tools, in that it can be used with both structured analysis and design approach or object-oriented approach.  
 
[[Image:320px-DSDM_Development_Process.svg.png|Model of the DSDM Software Development Process]]


=== Strength ===
=== Strength ===


*  
* most complete agile methodology
*  
* promotes team empowerment
*  
* more comprehensive job in showing its evolving character
*
 


=== Weakness ===
=== Weakness ===


*  
* harder to implement
*  
* many other organizations may already use DSDM, but are not yet ready to publicly commit to DSDM
 


=== Differences from XP ===
=== Differences from XP ===


While XP has been the first well known methodology to handle agile software process, it is perfectly suitable to integrate into a DSDM implementation, since many concepts of DSDM can improve XP with a robust requirements and project management mechanism.
But DSDM does distinguish itself from XP by the fact that it provides a tool and technique independent framework which allows users to fill in the specific steps of the process with their own techniques and software aids of choice.
DSDM  which focuses strongly on communication between all the stakeholders in the system strongly believes in commitment to the project to ensure a successful outcome.


== Crystal ==
== Crystal ==
Line 96: Line 121:
=== Strength ===
=== Strength ===


*  
* for projects with small teams
*  
* focuses on the people
*  
* easiest way to adopt a methodology that already fits
*
* supports fixed price contracts


=== Weakness ===
=== Weakness ===


*  
* processes is secondary
*
 


=== Differences from XP ===
=== Differences from XP ===


Crystal focuses on the people whereas XP focuses on the process which is secondary for Crystal.
Crystal is the best for small teams whereas XP allows you to work on a larger team.


== Feature Drive Development (FDD) ==
== Feature Drive Development (FDD) ==
Line 113: Line 140:
=== Overview ===
=== Overview ===


Feature Driven Development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.
Feature Driven Development (FDD) [http://en.wikipedia.org/wiki/Feature_Driven_Development] is an iterative and incremental software development process and is part of the Agile Alliance[http://en.wikipedia.org/wiki/Agile_Alliance#History]. FDD main purpose is to deliver tangible, working software repeatedly in a timely manner.
FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities.
FDD is a model-driven short-iteration process that consists of five basic activities.
Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process.  The term “client” in FDD is used to represent what Agile Modeling (AM) refers to as  project stakeholders or  eXtreme Programming (XP) calls customers.  FDD was first introduced to the world in 1999 via the book  Java Modeling In Color with UML, a combination of the software process followed by Jeff DeLuca’s company and Peter Coad’s concept of features. FDD was first applied on a 15 month, 50-person project for a large Singapore bank in 1997, which was immediately followed by a second, 18-month long 250-person project.  A more substantial description is published in the book  A Practical Guide to Feature-Driven Development as well as the  Feature Driven Development web site. 


[[Image:LifecycleFDD.gif|The Lifecycle of a FDD]]


As the name implies, features are an important aspect of FDD.  A feature is a small, client-valued function expressed in the form <action><result><object>.  For example, “Calculate the total of a sale”, “Validate the password of a user”, and “Authorize the sales transaction of a customer”.  Features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are to XP – they’re a primary source of requirements and the primary input into your planning efforts.


=== Strength ===


=== Strength ===
* focuses on regular delivery of client-valued features
* Success with above average developers
* Class ownership


*
*
*
*


=== Weakness ===
=== Weakness ===


*  
* Client are not on the team
*  
* No collective ownership


=== Differences from XP ===
=== Differences from XP ===
FDD is more structure than XP. Clients are on the team in XP.
FDD is identified as a process, whereas XP is more a set of principles.
XP formalizes the requirement you write the test first, whereas FDD has little to say on the subject of testing and certainly does not mandate writing the tests first.


== Lean Software Development (LSD) ==
== Lean Software Development (LSD) ==
Line 140: Line 168:
=== Overview ===
=== Overview ===


Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community.
Lean software development is a translation of lean manufacturing principles and practices to the software development domain which is adapted from the Toyota Production System, where a pro-lean subculture is emerging from within the Agile community.
Basically the lean manufacturing principles can also be applied to the software
Basically the lean manufacturing principles can also be applied to the software development process to resolve the issues.
development process to resolve the issues and to improve the process and obtain
 
better results.


=== Strength ===
=== Strength ===


*  
* obtain better results
*  
* improve the process
*  
* eliminate waste
*
* decide as late as possible
* deliver as fast as possible
 


=== Weakness ===
=== Weakness ===


*  
* assumption that customer requirements are static and can be defined by a predetermined system
*
 


=== Differences from XP ===
=== Differences from XP ===
XP is just the beginning. LSD goes at the cross team, enterprise level.


== Agile Modeling (AM) ==
== Agile Modeling (AM) ==
Line 163: Line 194:
=== Overview ===
=== Overview ===


Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems.  Simply put, Agile Modeling (AM) is a collection of  values,  principles, and  practices for modeling software that can be applied on a software development project in an effective and light-weight manner.  As you see in  Figure 1 AM is meant to be tailored into other, full-fledged methodologies such as  XP or  RUP, enabling you to develop a software process which truly meets your needs.
Agile Modeling (AM) is a collection of  values,  principles, and  practices for effective modeling of software-based syastems that can be applied on a software development project in an effective and light-weight manner.
Agile Modeling is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods.


Agile Modeling (AM) is a chaordic, practice-based methodology for effective modeling of software-based systems. The AM methodology is a collection of practices – guided by principles and values – that are meant to be applied by software professionals on a day-to-day basis.  AM is not a prescriptive process, in other words it does not define detailed procedures for how to create a given type of model, instead it provides advice for how to be effective as a modeler.  AM is “touchy-feely” in that it is not hard and fast – think of AM as an art, not a science.
=== Strength ===


An important concept to understand about AM is that it is not a complete software process. AM’s focus is on effective modeling and documentation. That’s it. It doesn’t include programming activities, although it will tell you to prove your models with code. It doesn’t include testing activities, although it will tell you to consider testability as you model. It doesn’t cover project management, system deployment, system operations, system support, or a myriad of other issues. Because AM’s focus in on a portion of the overall software process you need to use it with another, full-fledged process such as eXtreme Programming (XP), DSDM, SCRUM, the Agile Unified Process (AUP), or the Rational Unified Process (RUP).  You start with a base process, such as XP or RUP or perhaps even your own existing process, and then tailor it with AM (hopefully adopting all of AM) as well as other techniques as appropriate to form your own process that reflects your unique needs. Alternatively, you may decide to pick the best features from a collection of existing software processes to form your own process. For XP projects, AM explicitly describes how to improve productivity through addition of modeling activities whereas with for RUP projects it describes how to streamline modeling and documentation efforts to improve productivity.
* can be applied on a software development project in a more flexible manner than traditional modeling methods
* provides advice for how to be effective as a modeler
* focus is on effective modeling and documentation




=== Strength ===
=== Weakness ===


*  
* does not define detailed procedures for how to create a given type of model
*  
* is not a complete software process
*  
* doesn’t include programming  and testing activities
*
* difficult to apply where there are large teams


=== Weakness ===
=== Differences from XP ===


*
Because AM’s focus in on a portion of the overall software process you need to use it with another, full-fledged process such as XP.
*


=== Differences from XP ===
For XP projects, AM explicitly describes how to improve productivity through addition of modeling activities.


== Agile Unified Process (AUP) ==
== Agile Unified Process (AUP) ==
Line 189: Line 220:
=== Overview ===
=== Overview ===


Agile Unified Process (AUP) is a simplified version of the IBM Rational Unified Process (RUP) developed by Scott Ambler.[1] It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test driven development (TDD), Agile Modeling, agile change management, and database refactoring to improve productivity.
Agile Unified Process (AUP), who is a simplified version of the IBM Rational Unified Process (RUP) [http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process], describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test driven development (TDD)[http://en.wikipedia.org/wiki/Test_driven_development], Agile Modeling [http://en.wikipedia.org/wiki/Agile_Modeling], agile change management, and database refactoring [http://en.wikipedia.org/wiki/Database_refactoring] to improve productivity.
The Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques include test driven design (TDD), Agile Modeling, agile change management, and Database Refactoring to improve your productivity.
The Agile Unified Process, or Agile UP, is an ultra-lightweight variant of the Unified Process
(UP) which was developed by Grady Booch, James Rumbaugh and Ivar Jacobson ~ and is
marketed by IBM Rational as the Rational Unified Process (RUP). UP is an extensive
process framework that can be applied to a very wide range of projects and is then adapted
to the requirements of each individual project.The overall UP framework is often perceived as
complicated and the anti-thesis of agility as practised within eXtreme Programming (XP),
Scrum and DSDM, etc. The reality is that the Agile UP can be effectively applied as an agile
adaptation of the wider UP framework which is in widespread use.
Agile UP uses agile variants of the same basic practices and project phases as RUP, with the work
disciplines and work products simplified and reduced in number.
AUP is a simplified version of the Rational Unified Process (RUP).  It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP.  I've tried to keep the Agile UP as simple as possible, both in its approach and in its description.  The descriptions are simple and to the point, with links to details (on the web) if you want them.  The approach applies agile techniques include test driven development (TDD), Agile Model Driven Development (AMDD), agile change management, and database refactoring to improve your productivity.  


[[Image:LifecycleAgileUP.gif|The Lifecycle of an AUP]]


=== Strength ===
=== Strength ===


*  
* ultra-lightweight variant of the Unified Process
*  
* can apply to a very wide range of projects
*  
* is adapted to the requirements of each individual projects
*
* applies agile techniques to improve productivity
* large number of artifacts


=== Weakness ===
=== Weakness ===


*  
* perceived as complicated
*  
* more heavy than XP
 


=== Differences from XP ===
=== Differences from XP ===
AUP framework [http://en.wikipedia.org/wiki/Framework] is often perceived as the anti-thesis of agility as practiced within XP.
AUP uses agile variants of the same basic practices and project phases as RUP, with the work disciplines and work products simplified and reduced in number.
XProgrammers will likely find the AUP fairly heavy, and "traditional RUP" users may find that it's too streamlined. XP is used when Programmers need something lighter.  AUP is used when Progrmmers want a detailed, well-defined software process.


== References ==
== References ==

Latest revision as of 06:46, 30 November 2009

OTHER AGILE METHODS


Introduction

Agile software development [1] is a software development methodologies based on iterative development throughout the life-cycle of the project. The term was coined in the year 2001 when the Agile Manifesto [2] was formulated. Agile methods generally promote a disciplined project management process that promotes frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Extreme Programming (XP)

Overview

Extreme Programming (XP) [3] is a radical agile methodology, focusing on the software development process and addressing the analysis, development and test phases with novel approaches aimed at making a substantial difference to the quality of the end product. XP is the most common used Agile method. XP is successful because it stresses customer satisfaction. XP empowers your developers to confidently respond to changing customer requirements, even late in the life cycle. XP emphasizes teamwork: managers, customers, and developers are all equal partners in a collaborative team. XP implements a simple, yet effective environment enabling teams to become highly productive: the team self-organizes around the problem to solve it as efficiently and as fast as possible.

Adaptive Software Development (ASD)

Overview

Adaptive Software Development [4] is a software development process that grew out of rapid application development work which embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. ASD is based on a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant.


Strength

  • Reduced cycle time and improved productivity
  • Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs


Weakness

  • Risk of never achieving closure
  • Requires a system that can be modularized
  • Developers and customers must be committed to rapid-fire activities in an abbreviated time frame
  • Accelerated development process must give quick responses to the user


Differences from XP

In ASD, human relationship must have the ability to adapt whereas in XP, the human relationship is based on the work satisfaction. In ASD, humans utilize technology as will whereas in XP, they utilize technology within predefined framework. In ASD, the purpose of the development is the survival and thriving of organization whereas in XP, it is the product delivery while we are doing satisfying work.

Scrum

Overview

Scrum [5] is process of implementing Agile, where features are delivered in 30 day sprints. Scrum concentrates particularly on how to manage tasks within a team-based development environment.

The Scrum Process

Strength

  • Iterative-incremental process
  • Based on modeling the problem domain and the system
  • Requirements are allowed to evolve over time.
  • Traceability to requirements through the Product Backlog
  • Architecture of the system drafted before the development engine is started
  • Iterative development engine governed by careful planning and reviewing
  • Active user involvement
  • Simple and straightforward process
  • Early and frequent releases, demonstrating functionality at the end of each iteration (sprint) of the development cycle

Weakness

  • Integration is done after all increments are built
  • Lack of scalability
  • Based on the assumption that human communication is sufficient for running projects of any size and keeping them focused
  • Not necessarily seamless (details of tasks are not prescribed)
  • No clear-cut design effort
  • Model-phobic
  • Models are not prescribed, leaving it to the developer to decide what model can be useful
  • Lack of formalism

Differences from XP

XP and Scrum are so different they are not really comparable. Scrum is an agile management methodology. Whereas XP is an agile engineering methodology. Scrum is the more likely starting point when the adoption of agile is driven by managementwhereas XP is the more likely starting point when the adoption of agile is driven by developers.

Dynamic Systems Development Method (DSDM)

Overview

Dynamic System Development Method (DSDM) [6]is another approach to system development, which, as the name suggests, develops the system dynamically. This methodology is independent of tools, in that it can be used with both structured analysis and design approach or object-oriented approach.

Model of the DSDM Software Development Process

Strength

  • most complete agile methodology
  • promotes team empowerment
  • more comprehensive job in showing its evolving character


Weakness

  • harder to implement
  • many other organizations may already use DSDM, but are not yet ready to publicly commit to DSDM


Differences from XP

While XP has been the first well known methodology to handle agile software process, it is perfectly suitable to integrate into a DSDM implementation, since many concepts of DSDM can improve XP with a robust requirements and project management mechanism. But DSDM does distinguish itself from XP by the fact that it provides a tool and technique independent framework which allows users to fill in the specific steps of the process with their own techniques and software aids of choice. DSDM which focuses strongly on communication between all the stakeholders in the system strongly believes in commitment to the project to ensure a successful outcome.

Crystal

Overview

Crystal Clear is an agile methodology for projects with small teams, less than about 10 people in size. His focus is on the people, interaction, community, skills, talents, and communications with the belief that these are what have the first-order effect on performance. Process, he says, is important, but secondary.

Strength

  • for projects with small teams
  • focuses on the people
  • easiest way to adopt a methodology that already fits
  • supports fixed price contracts

Weakness

  • processes is secondary


Differences from XP

Crystal focuses on the people whereas XP focuses on the process which is secondary for Crystal. Crystal is the best for small teams whereas XP allows you to work on a larger team.

Feature Drive Development (FDD)

Overview

Feature Driven Development (FDD) [7] is an iterative and incremental software development process and is part of the Agile Alliance[8]. FDD main purpose is to deliver tangible, working software repeatedly in a timely manner. FDD is a model-driven short-iteration process that consists of five basic activities.

The Lifecycle of a FDD


Strength

  • focuses on regular delivery of client-valued features
  • Success with above average developers
  • Class ownership


Weakness

  • Client are not on the team
  • No collective ownership

Differences from XP

FDD is more structure than XP. Clients are on the team in XP. FDD is identified as a process, whereas XP is more a set of principles. XP formalizes the requirement you write the test first, whereas FDD has little to say on the subject of testing and certainly does not mandate writing the tests first.

Lean Software Development (LSD)

Overview

Lean software development is a translation of lean manufacturing principles and practices to the software development domain which is adapted from the Toyota Production System, where a pro-lean subculture is emerging from within the Agile community. Basically the lean manufacturing principles can also be applied to the software development process to resolve the issues.


Strength

  • obtain better results
  • improve the process
  • eliminate waste
  • decide as late as possible
  • deliver as fast as possible


Weakness

  • assumption that customer requirements are static and can be defined by a predetermined system


Differences from XP

XP is just the beginning. LSD goes at the cross team, enterprise level.

Agile Modeling (AM)

Overview

Agile Modeling (AM) is a collection of values, principles, and practices for effective modeling of software-based syastems that can be applied on a software development project in an effective and light-weight manner.

Strength

  • can be applied on a software development project in a more flexible manner than traditional modeling methods
  • provides advice for how to be effective as a modeler
  • focus is on effective modeling and documentation


Weakness

  • does not define detailed procedures for how to create a given type of model
  • is not a complete software process
  • doesn’t include programming and testing activities
  • difficult to apply where there are large teams

Differences from XP

Because AM’s focus in on a portion of the overall software process you need to use it with another, full-fledged process such as XP.

For XP projects, AM explicitly describes how to improve productivity through addition of modeling activities.

Agile Unified Process (AUP)

Overview

Agile Unified Process (AUP), who is a simplified version of the IBM Rational Unified Process (RUP) [9], describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test driven development (TDD)[10], Agile Modeling [11], agile change management, and database refactoring [12] to improve productivity.

The Lifecycle of an AUP

Strength

  • ultra-lightweight variant of the Unified Process
  • can apply to a very wide range of projects
  • is adapted to the requirements of each individual projects
  • applies agile techniques to improve productivity
  • large number of artifacts

Weakness

  • perceived as complicated
  • more heavy than XP


Differences from XP

AUP framework [13] is often perceived as the anti-thesis of agility as practiced within XP. AUP uses agile variants of the same basic practices and project phases as RUP, with the work disciplines and work products simplified and reduced in number. XProgrammers will likely find the AUP fairly heavy, and "traditional RUP" users may find that it's too streamlined. XP is used when Programmers need something lighter. AUP is used when Progrmmers want a detailed, well-defined software process.

References

XP

[1] http://www.extremeprogramming.org/

[2] http://en.wikipedia.org/wiki/Extreme_Programming

[3] http://ootips.org/xp.html

[4] http://xprogramming.com/index.php

ASD

[5] http://en.wikipedia.org/wiki/Adaptive_Software_Development

[6] http://norvig.com/adapaper-pcai.html

[7] http://dirkriehle.com/computer-science/research/2000/xp-2000.pdf

[8] http://www.softwareplanner.com/SE_SP_adaptive_software_mkt.asp

Scrum

[9] http://en.wikipedia.org/wiki/Scrum_%28development%29

[10] http://softwareplanner.com/Newsletters/newsletter_2008_02_SP.htm

[11] http://scrummethodology.com/

[12] http://www.agile-software-development.com/2008/04/extreme-programming-versus-scrum.html

DSDM

[13] http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

[14] http://www.ifi.uzh.ch/req/courses/seminar_ws03/14_Voigt_DSMD_Ausarbeitung.pdf

[15] http://www.freetutes.com/systemanalysis/sa2-dynamic-system-development-method.html

Crystal

[16] http://en.wikipedia.org/wiki/Crystal_Clear_%28software_development%29

[17] http://www.agilekiwi.com/crystal_clear.htm

FDD

[18] http://www.agilemodeling.com/essays/fdd.htm

[19] http://en.wikipedia.org/wiki/Feature_Driven_Development

[20] http://www.featuredrivendevelopment.com/node/519

LSD

[21] http://en.wikipedia.org/wiki/Lean_software_development

[22] http://www.poppendieck.com/

[23] http://www.projectperfect.com.au/downloads/Info/info_lean_development.pdf

[24] http://www.leansoftwareinstitute.com/art_ilsd.php

AM

[25] http://www.agilemodeling.com/essays/introductionToAM.htm

[26] http://en.wikipedia.org/wiki/Agile_Modeling

[27] http://www.ambysoft.com/books/agileModeling.html

[28] http://www.agilealliance.org/system/article/file/921/file.pdf

AUP

[29] http://www.ambysoft.com/unifiedprocess/agileUP.html

[30] http://en.wikipedia.org/wiki/Agile_Unified_Process

[31] http://en.allexperts.com/e/a/ag/agile_unified_process.htm

[32] http://www.radtac.co.uk/pdf/AUP.pdf

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_HJ3&oldid=30069"