Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:54:41Z

Bschanda: /* Adaptive Software Development (ASD) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

Image Courtesy :http://norvig.com

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

Image Courtesy http://www.codeproject.com/KB/architecture

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.htm Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

Image Courtesy: http://www.agilemodeling.com/essays/fdd.htm

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Image Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

Image Courtesy: http://www.agilemodeling.com/

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

Image Courtesy: http://www.ambysoft.com/unifiedprocess/agileUP.html

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:53:30Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

Image Courtesy http://www.codeproject.com/KB/architecture

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.htm Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

Image Courtesy: http://www.agilemodeling.com/essays/fdd.htm

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Image Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

Image Courtesy: http://www.agilemodeling.com/

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:52:40Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.htm Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

Image Courtesy: http://www.agilemodeling.com/essays/fdd.htm

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Image Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:52:08Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

Image Courtesy http://www.codeproject.com/KB/architecture/DSDM/dsdm1.jpg

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.htm Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

Image Courtesy: http://www.agilemodeling.com/essays/fdd.htm

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:50:45Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

Image Courtesy http://www.codeproject.com/KB/architecture/DSDM/dsdm1.jpg

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

Image Courtesy: http://www.agilemodeling.com/essays/fdd.ht

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:50:18Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.Image Courtesy http://www.codeproject.com/KB/architecture/DSDM/dsdm1.jpg

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

Image Courtesy: http://www.agilemodeling.com/essays/fdd.ht

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:49:45Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.
Image Courtesy http://www.codeproject.com/KB/architecture/DSDM/dsdm1.jpg

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

Image Courtesy: http://www.agilemodeling.com/essays/fdd.ht

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:49:17Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.
Image Courtesy : http://www.codeproject.com/KB/architecture/DSDM/dsdm1.jpg

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:46:24Z

Bschanda: /* Lean Software Development (LSD) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

=== Lean Software Development (LSD)===

[http://en.wikipedia.org/wiki/Lean_software_development 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.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:44:14Z

Bschanda: /* Why Agile? */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:43:49Z

Bschanda: /* What is Agile ? */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:42:49Z

Bschanda: /* What is Agile ? */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://en.wikipedia.org/wiki/Sprint_(software_development) sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===

[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

[[Image:Ada.gif]]

=== Scrum ===

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

[[Image:Scrum.gif]]

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

[[Image:Dsdm.jpg]]

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.

[[Image:Crystal.jpg]]

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

[[Image:LifecycleFDD.gif]]

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

[[Image:Lean_Software_Development.jpg]]

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

[[Image:BestPractices.jpg]]

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

[[Image:LifecycleAgileUP.gif]]

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

== Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

== References and Links ==

#http://agilemethodology.org/
#http://en.wikipedia.org/wiki/Scrum_%28development%29
#http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
#http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
#http://www.agilemodeling.com/essays/fdd.htm
#http://en.wikipedia.org/wiki/Lean_software_development
#http://www.agilemodeling.com/
#http://www.ambysoft.com/unifiedprocess/agileUP.html
#http://www.agiledata.org/essays/differentStrategies.html
#http://balagan.org.uk/work/agile_comparison.htm
#http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:30:32Z

Bschanda: /* Why Agile? */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===
[[Image:Ada.gif]]
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

=== Scrum ===

[[Image:Scrum.gif]]

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===
[[Image:Dsdm.jpg]]

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color. [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

==6) Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:30:04Z

Bschanda: /* What is Agile ? */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

[http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===
[[Image:Ada.gif]]
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

=== Scrum ===

[[Image:Scrum.gif]]

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===
[[Image:Dsdm.jpg]]

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color. [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

==6) Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:28:08Z

Bschanda: /* Crystal */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===
[[Image:Ada.gif]]
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

=== Scrum ===

[[Image:Scrum.gif]]

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===
[[Image:Dsdm.jpg]]

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color. [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

== Strengths and Weaknesses ==
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Strengths'''
| align="center" style="background:#f0f0f0;"|'''Weaknesses'''
|-
| XP ||Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. ||Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns.
|-
| Scrum ||Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. ||Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement.
|-
| Lean ||Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. ||Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt.
|-
| FDD ||Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. ||Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models.
|-
| AUP ||Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. ||Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here.
|-
| Crystal ||Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The \"human\" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. ||Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn\'t work, as Crystal was not designed to be upward or downward compatible.
|-
| DSDM ||An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. ||Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.
|-
|
|}

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Condition'''
| align="center" style="background:#f0f0f0;"|'''XP'''
| align="center" style="background:#f0f0f0;"|'''Scrum'''
| align="center" style="background:#f0f0f0;"|'''Lean'''
| align="center" style="background:#f0f0f0;"|'''FDD'''
| align="center" style="background:#f0f0f0;"|'''AUP'''
| align="center" style="background:#f0f0f0;"|'''Crystal'''
| align="center" style="background:#f0f0f0;"|'''DSDM'''
|-
| Small Team ||√ ||√ ||√ ||X ||X ||- ||√
|-
| Highly Volatile Requirements ||√ ||√ ||√ ||√ ||- ||- ||X
|-
| Distributed Teams ||X ||√ ||√ ||√ ||√ ||X ||X
|-
| High Ceremony Culture ||X ||X ||- ||- ||√ ||- ||√
|-
| High Criticality Systems ||X ||- ||- ||- ||- ||√ ||X
|-
| Multiple Customers / Stakeholders ||X ||√ ||√ ||- ||- ||- ||X
|-
|
|}

Reference : http://www.devx.com/architect/Article/32836/0/page/4

==6) Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Methodology'''
| align="center" style="background:#f0f0f0;"|'''Summarizing Phrase'''
|-
| XP ||Simplicity
|-
| Scrum ||Prioritized Business Value
|-
| Lean ||Return on Investment (ROI)
|-
| FDD ||Business Model
|-
| AUP ||Manage Risk
|-
| Crystal ||Size and Criticality
|-
| DSDM ||Current Business Value
|-
|
|}

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:19:29Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===
[[Image:Ada.gif]]
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

=== Scrum ===

[[Image:Scrum.gif]]

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===
[[Image:Dsdm.jpg]]

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

==6) Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:19:07Z

Bschanda: /* Dynamic Systems Development Method (DSDM) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===
[[Image:Ada.gif]]
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

=== Scrum ===

[[Image:Scrum.gif]]

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===
[[Image:Dsdm.jpg]]
[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

==6) Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

File:Dsdm.jpg

2009-11-19T02:18:26Z

Bschanda:

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:15:34Z

Bschanda: /* Adaptive Software Development (ASD) */

'''A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES'''

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

# Adaptive Software Development (ASD)
# Scrum
# Dynamic Systems Development Method (DSDM)
# Crystal
# Feature Drive Development (FDD)
# Lean Software Development (LSD)
# Agile Modeling (AM)
# Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===
[[Image:Ada.gif]]
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

=== Scrum ===

[[Image:Scrum.gif]]

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

== Comparing Development Methods ==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Method'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''When to Use It'''
| align="center" style="background:#f0f0f0;"|'''Primary Modeling Artifacts'''
|-
| Agile Data (AD) ||A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. ||Tailor the AD philosophies and techniques into other evolutionary processes. ||Agile data models
|-
| Agile Model Driven Development (AMDD) ||A partial, practices-based method which describes techniques for effective modeling and documentation of systems. ||Tailor the AM principles and practices into other agile or near-agile processes. ||Apply the right artifact for the situation at hand.
|-
| Agile MSF (Microsoft Solutions Framework) ||TBD ||TBD ||TBD
|-
| Agile Unified Process (AUP) ||An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. ||When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you\'re accustomed to, or simply something that\'s free. ||Use-case model UML sequence diagrams UML class model Physical data model
|-
| Code and Fix ||A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called \"hacking\" or \"immature development\". ||For throw-away prototypes. ||Source code
|-
| Data-Driven Approach ||This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology ||Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple “CRUD” (Create Read Update Delete) business application. ||Conceptual data model Logical data model Deployment architecture Physical data model
|-
| Dynamic System Development Method (DSDM) ||This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. ||Development of a user interface intensive system. Complex business application. ||Functional prototype Design prototype
|-
| Enterprise Unified Process (EUP) ||A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. ||Need to manage a portfolio of projects, including but not limited teams following the RUP. You have been successful at several RUP projects and wish to now take the full system lifecycle into account. ||Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts
|-
| Extreme Programming (XP) ||An agile development method that focuses on the critical activities required to build software. ||Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. ||User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards
|-
| Feature-Driven Development (FDD) ||An agile development method based on short iterations which includes explicit modeling activities. ||Small project team (4-20 people). Requirements are uncertain. Team willing to follow a modeling driven approach. ||Domain class/object model Features UML Sequence diagrams UML class model
|-
| Glacial Methodology ||TBD ||TBD ||TBD
|-
| ICONIX ||A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right. ||Small to medium sized project teams (4 to 20 people). Business application development. ||Use-case model Robustness diagrams UML Sequence diagrams UML class model
|-
| ISO/IEC 12207 ||A multi-phase software process that includes development, operation, and retirement of software-based systems. ||Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. ||Shall statements Logical data model Logical process model Physical data model Physical process model
|-
| MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) ||TBD ||TBD ||TBD
|-
| Object Oriented Software Process (OOSP) ||A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Personal Software Process (PSP) ||A prescriptive software process for individual developers. ||1 (see the TSP for the group version) ||TBD
|-
| Rational Unified Process (RUP) ||A rigorous, four-phase software development process which is iterative and incremental. ||Medium to large project teams (10+ people). ||Use-case model System architecture model UML Sequence diagrams UML class model Physical data model
|-
| Scrum ||An agile method whose focus is on project management and requirements management. Often combined with XP. ||Any size project ||Varies, depending on the development process (XP, ...) which you use Scrum with.
|-
| Team Software Process (TSP) ||TBD ||TBD ||TBD
|-
| Test Driven Development (TDD) ||An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development ||Any size project ||Tests
|-
|
|}

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

==6) Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

File:Ada.gif

2009-11-19T02:11:32Z

Bschanda:

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:00:15Z

Bschanda: /* A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

''Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.''

__TOC__

== What is Agile ? ==

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

== Why Agile? ==

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>

== A Brief look at other Agile methodologies ==

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

=== Adaptive Software Development (ASD)===
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

=== Scrum ===
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

=== Dynamic Systems Development Method (DSDM)===

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

=== Crystal ===

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

=== Feature Drive Development (FDD)===

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

=== Lean Software Development (LSD)===

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

=== Agile Modeling (AM)===

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

=== Agile Unified Process (AUP)===

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

== Comparing Development Methods ==
The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

==Table 1.Comparing software development methods.==

Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

==6) Conclusion ==
As visible from the table of comparisons above each software development methodology is suited in a particular team and project setting .The project team and stakeholders need to decide on the methodology based on the size of team ,time required to develop and market the product and other parameters .The decision should help make the quality of product better and meet the deadline in time to market or sell the product .Below is table which summarizes each of the software development methodology in one phrase

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:59:43Z

Bschanda: /* Table 1.Comparing software development methods. */

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:44:21Z

Bschanda: /* 3.2)Scrum */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are:
the "ScrumMaster", who maintains the processes (typically in lieu of a project manager);
the "Product Owner", who represents the stakeholders;
the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

==4. Comparing Development Methods==
The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

==Table 1.Comparing software development methods.==

Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:39:54Z

Bschanda: /* Table 1.Comparing software development methods. */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

==4. Comparing Development Methods==
The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

==Table 1.Comparing software development methods.==

Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:17:47Z

Bschanda: /* 4. Comparing Development Methods */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

==4. Comparing Development Methods==
The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

==Table 1.Comparing software development methods.==
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:16:56Z

Bschanda: /* 4. Comparing Development Methods */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

==4. Comparing Development Methods==
The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:16:40Z

Bschanda: /* =4. Comparing Development Methods */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

===4. Comparing Development Methods===

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:16:27Z

Bschanda: /* 3.8) Agile Unified Process (AUP) */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

===4. Comparing Development Methods==

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:07:34Z

Bschanda: /* CONTENTS */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
<p> Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .</p>
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:07:07Z

Bschanda: /* 3.1) Adaptive Software Development (ASD) */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:06:49Z

Bschanda: /* 3.4) Crystal */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no "one-size-fits all" development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:06:08Z

Bschanda: /* 3.4) Crystal */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.
The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2
[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:05:27Z

Bschanda: /* 3.5 Feature Drive Development (FDD) */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.

The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication
as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:05:02Z

Bschanda: /* CONTENTS */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
Development costs and time to market are greatly reduced to inspect and adapt way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as analysis paralysis can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.

The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication
as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:04:16Z

Bschanda: /* CONTENTS */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.
Development costs and time to market are greatly reduced to "inspect and adapt" way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.

The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication
as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:02:00Z

Bschanda: /* 3.2)Scrum */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.

Development costs and time to market are greatly reduced to "inspect and adapt" way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==
[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.

The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication
as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:01:41Z

Bschanda: /* 3.2)Scrum */

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.

Development costs and time to market are greatly reduced to "inspect and adapt" way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

==3.3) Dynamic Systems Development Method (DSDM)==

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.

The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication
as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T00:55:42Z

Bschanda:

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.

Development costs and time to market are greatly reduced to "inspect and adapt" way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

3.3) Dynamic Systems Development Method (DSDM)

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

==3.4) Crystal==

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.

The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication
as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

==3.8) Agile Unified Process (AUP)==

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T00:53:42Z

Bschanda:

===A COMPARATIVE ANALYSIS OF OTHER AGILE METHODOLOGIES AND ASSESSING THEIR STRENGTHS AND WEAKNESSES===

Although, the most popular Agile methodology is Extreme Programming (XP) there are other other methodologies which are also used in the industry such as Adaptive Software Development (ASD), Scrum, Dynamic Systems Development Method (DSDM), Crystal etc. that we shall be covering in this Wikipedia. Moreover, we will perform a comparative analysis between these process models and conclude with the criteria for selecting a particular agile methodology.

==CONTENTS==

1) What is Agile ?

Agile methodology is a type of project management used for software development.This method uses incremental,iterative work cadences known as [http://agilemethodology.org/ sprints] to help teams deal with unpredictability in building software

2) Why Agile?

In a development life cycle Agile methodology provides many opportunities to access the direction of a project.This approach is achieved by sprints which are regular cadences of work,at the end of which teams must present a shippable increment of work.Agile methodology is hence "iterative" or incremental since it focuses on repetition of abbreviated work cycles as well as the functional product they yield.In contrast in waterfall methodology teams only have have one chance to get each aspect of a project right.Whereas in agile methodology throughout the life cycle of a project every aspect of a development - requirements ,design ,etc - is continually revisited.There is always time to steer the project in another direction when a team stops and re-evaluates the project every two weeks.

Development costs and time to market are greatly reduced to "inspect and adapt" way of development .Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress.The stakeholders get recurring opportunities to calibrate releases for success in real world as the team's work cycle is limited to two weeks .The probability of building the right product by the companies is hence high with agile methodology.Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace.In conclusion agile methodology is a very viable option for stakeholders and developers as it ensures to preserve product's critical market relevance and ensure's team's work does not wind up in a shelf .
3) A Brief look at other Agile methodologies.

1) Adaptive Software Development (ASD)
2) Scrum
3) Dynamic Systems Development Method (DSDM)
4) Crystal
5) Feature Drive Development (FDD)
6) Lean Software Development (LSD)
7) Agile Modeling (AM)
8) Agile Unified Process (AUP)

==3.1) Adaptive Software Development (ASD)==
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] evolved out of the work by Jin Highsmith and Sam Bayer on the rapid application development. It follows the principle that continuous change to a process is a normal behaviour expected out of it. It differs from the traditional waterfall model in the sense that is has concurrent processes of speculate,collaborate, and learn cycles. Because of it, the project undergoes continuous changes at any stage of its development and is therefore, dynamic in operation. Some of the characteristics of an adaptive software development life cycle are that it is iterative, time-boxed, driven by risk, flexible to changes and it is overall focused on its mission.

==3.2)Scrum==

[http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] is an incremental framework that is iterative and used for managing complex work (such as new product development) and is categorized under agile software development.

Image Courtesy : http://www.methodsandtools.com/archive/archive.php?id=18

3.3) Dynamic Systems Development Method (DSDM)

[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method] (DSDM) is an agile software development methodology that is actually based upon the Rapid Application Development methodology. Of one of the principles in DSDM, user involvement is one of the main keys in running an efficient and effective project where both users and developers work together at t common workplace so that the decisions are accurate. Moreover, it is expected that all changes made during the development are reversible. Testing exists throughout the life-cycle of project. DSDM is an iterative and incremental approach that emphasises continuous user involvement.Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

3.4) Crystal

The development of Crystal Methods took place to encounter the variability of the environment and the characteristics that are unique to a project.The primary difference between RUP and Crystal is that while RUP generally starts with a plan-driven base methodology and tailors down for smaller, less critical projects, on the other hand, the Crystal according to the author Alistair Cockburn the base methodology should be “barely sufficient.” According to him , “You need one less notch control than you expect, and less is better when it comes to delivering quickly.”

According to another belief by Cockburn, Crystal is a family of methods because that there is no “one-size-fits all” development process. As such, the different methods are assigned colors arranged in ascending opacity; the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange, and Crystal Red.

The Crystal Methods emphasize the importance of people in developing software. "It focuses on people, interaction, community, skills, talents, and communication
as first order effects on performance. Process remains important, but secondary”. There are only two absolute rules of the Crystal family of methodologies. Firstly, incremental cycles should not exceed four months. Secondly, reflection workshops must be held after every delivery so that the methodology is self-adapting. Currently, only Crystal Clear and Crystal Orange have been defined

The Crystal Family of Methodologies.One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.
Image Courtesy : http://www.devx.com/architect/Article/32836/1763?supportItem=2

[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Comparison] of methods click on the link

==3.5 Feature Drive Development (FDD)==

[http://www.agilemodeling.com/essays/fdd.ht Feature-Driven Development](FDD) is a client-centric, architecture-centric, and pragmatic software process. 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.

==3.6) Lean Software Development (LSD)==

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. http://en.wikipedia.org/wiki/Lean_software_development.

Courtesy : IBM

==3.7) Agile Modeling (AM)==

[http://www.agilemodeling.com/ Agile Modeling] (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below . At a more detailed level 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.

3.8) Agile Unified Process (AUP)

[http://www.ambysoft.com/unifiedprocess/agileUP.html 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.

4. Comparing Development Methods

The leading development methods are compared in Table 1.The focus is not on use case modelling ,rather on high-level software processes therefore RUP and not detailed methods.The table lists the development methods that appear in reasonably common use and it is not exhaustive .Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.Figure 1 depicts a graph comparing the same processes.The table also indicates primary types of modeling artifacts that you are likely to create following each method.The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes.Some of the secondary models are not listed ,for example business rules and user interface prototypes on a RUP project ,since those artifacts are nto focus of the method .the primary focus of this table is to showcase different approaches to development ch of which has it’s own collection of primary modeling artifacts. Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.
It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.

Table 1. Comparing software development methods.
Method
Description
When to Use It
Primary Modeling Artifacts
Agile Data (AD) A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. Tailor the AD philosophies and techniques into other evolutionary processes. Agile data models
Agile Model Driven Development (AMDD) A partial, practices-based method which describes techniques for effective modeling and documentation of systems. Tailor the AM principles and practices into other agile or near-agile processes. Apply the right artifact for the situation at hand.
Agile MSF (Microsoft Solutions Framework) TBD TBD TBD
Agile Unified Process (AUP) An agile instantiation of the Unified Process (UP), a dramatic simplification of the RUP. When you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, or simply something that's free.
Use-case model
UML sequence diagrams
UML class model
Physical data model
Code and Fix A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". For throw-away prototypes. Source code
Data-Driven Approach
This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial.
For a humorous look, read The Glacial Methodology
Development of a data warehouse, although a usage-centered approach is still preferable.
Development of a simple “CRUD” (Create Read Update Delete) business application.
Conceptual data model
Logical data model
Deployment architecture
Physical data model
Dynamic System Development Method (DSDM)
This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s.
Development of a user interface intensive system.
Complex business application.
Functional prototype
Design prototype
Enterprise Unified Process (EUP)
A rigorous, seven-phase software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities.
Need to manage a portfolio of projects, including but not limited teams following the RUP.
You have been successful at several RUP projects and wish to now take the full system lifecycle into account.
Enterprise business model
Enterprise domain architecture model
Enterprise technical architecture model
Project-level artifacts
Extreme Programming (XP)
An agile development method that focuses on the critical activities required to build software.
Small, co-located project teams (4-10 people).
Requirements are uncertain.
Good relationship (potentially) exists with project stakeholders.
User stories
Architectural metaphor/strategy
Class responsibility collaborator (CRC) cards
Feature-Driven Development (FDD)
An agile development method based on short iterations which includes explicit modeling activities.
Small project team (4-20 people).
Requirements are uncertain.
Team willing to follow a modeling driven approach.
Domain class/object model
Features
UML Sequence diagrams
UML class model
Glacial Methodology TBD TBD TBD
ICONIX
A simple, modeling-driven method that can be instantiated as an improvement to the RUP or as an agile method in its own right.
Small to medium sized project teams (4 to 20 people).
Business application development.
Use-case model
Robustness diagrams
UML Sequence diagrams
UML class model
ISO/IEC 12207
A multi-phase software process that includes development, operation, and retirement of software-based systems.
Medium to large project teams (20+ people).
Mandated (e.g. by government) to follow this approach.
Shall statements
Logical data model
Logical process model
Physical data model
Physical process model
MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated) TBD TBD TBD
Object Oriented Software Process (OOSP) A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Personal Software Process (PSP) A prescriptive software process for individual developers. 1 (see the TSP for the group version) TBD
Rational Unified Process (RUP)
A rigorous, four-phase software development process which is iterative and incremental.
Medium to large project teams (10+ people).
Use-case model
System architecture model
UML Sequence diagrams
UML class model
Physical data model
Scrum An agile method whose focus is on project management and requirements management. Often combined with XP. Any size project Varies, depending on the development process (XP, ...) which you use Scrum with.
Team Software Process (TSP) TBD TBD TBD
Test Driven Development (TDD) An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development Any size project Tests

http://www.agiledata.org/essays/differentStrategies.html

There is another very good link to understand the usage of various Agile methodologies : http://balagan.org.uk/work/agile_comparison.htm

5 .Strengths and Weaknesses
Every methodology has it's strengths and weaknesses. The following table can be used in assessing the right methodology for working on a project.

Strengths Weaknesses
XP
Strong technical practices.
Customer ownership of feature priority, developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted approach, at least in the U.S.
Requires onsite customer.
Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns.
Scrum
Complements existing practices.
Self organizing teams and feedback.
Customer participation and steering.
Priorities based on business value.
Only approach here that has a certification process.
Only provides project management support, other disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique priorities for each requirement.
Lean
Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.
Does not specify technical practices.
Requires constant gathering of metrics which may be difficult for some environments to accommodate.
Theory of Constraints can be a complex and difficult aspect to adopt.
FDD
Supports multiple teams working in parallel.
All aspects of a project tracked by feature.
Design by feature and build by feature aspects are easy to understand and adopt.
Scales to large teams or projects well.
Promotes individual code ownership as opposed to shared/team ownership.
Iterations are not as well defined by the process as other Agile methodologies.
The model-centric aspects can have huge impacts when working on existing systems that have no models.
AUP
Robust methodology with many artifacts and disciplines to choose from.
Scales up very well.
Documentation helps communicate in distributed environments.
Priorities set based on highest risk. Risk can be a business or technical risk.
Higher levels of ceremony may be a hindrance in smaller projects.
Minimal attention to team dynamics.
Documentation is much more formal than most approaches mentioned here.
Crystal
Family of methodologies designed to scale by project size and criticality.
Only methodology that specifically accounts for life critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.
The "human" component has been considered for every aspect of the project support structure.
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Expects all team members to be co-located. May not work well for distributed teams.
Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one tester is expected to be on each project team.
Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

The next table shows a comparison among the methodologies based on certain parameters such as Small Team, Highly Volatile Requirements, Distrbuted Teams, High Ceremony Culture,High Criticality Sytems and Multiple Customers/Stakeholders. According to the author, the table does not represent any scientific metrics for evaluating the adoption criteria for any methodology. The aim is to help out a team in picking out the best possible methodology suitable for their project

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team √ √ √ X X - √
Highly Volatile Requirements √ √ √ √ - - X
Distributed Teams X √ √ √ √ X X
High Ceremony Culture X X - - √ - √
High Criticality Systems X - - - - √ X
Multiple Customers / Stakeholders X √ √ - - - X
Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.
Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Reference : http://www.devx.com/architect/Article/32836/0/page/4

6) Conclusion

7) References and Links

http://agilemethodology.org/

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

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://www.agilemodeling.com/essays/fdd.htm

http://en.wikipedia.org/wiki/Lean_software_development

http://www.agilemodeling.com/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agiledata.org/essays/differentStrategies.html

http://balagan.org.uk/work/agile_comparison.htm

http://www.devx.com/architect/Article/32836/0/page/4

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-15T01:25:16Z

Bschanda: /* References */

==Synchronizer token pattern==

==Introduction==

Developers of web sites face problem with maintaining normal control flow when there is multiple form submissions
The issue occurs when the user clicks on the submit button twice and the data is sent back to the client twice or when client access a previously bookmarked page . Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Synchronizer token pattern] is one such server side method in which once a submission is made a flag is set and on re-submission the stored value is compared and if it is a duplicate no action is taken . Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language) Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern in [http://en.wikipedia.org/wiki/PHP PHP]

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> [http://en.wikipedia.org/wiki/JavaScript Java Script] uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in [http://en.wikipedia.org/wiki/ASP.NET ASP] that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>Java struts solution - http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p> ASP .NET solution - http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>General HTML solution client side - http://drupal.org/node/69048</p>
<p>PHP solution -http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>ASP.NET solution - http://forums.techarena.in/software-development/1149257.htm</p>
<p>Ruby on rails solution - http://www.stackoverflow.com</p>
<p>Struts solution http://www.sbouchard.com/2009/01/19/synchronizer-token-pattern-in-struts </p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-15T01:24:40Z

Bschanda: /* References */

==Synchronizer token pattern==

==Introduction==

Developers of web sites face problem with maintaining normal control flow when there is multiple form submissions
The issue occurs when the user clicks on the submit button twice and the data is sent back to the client twice or when client access a previously bookmarked page . Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Synchronizer token pattern] is one such server side method in which once a submission is made a flag is set and on re-submission the stored value is compared and if it is a duplicate no action is taken . Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language) Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern in [http://en.wikipedia.org/wiki/PHP PHP]

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> [http://en.wikipedia.org/wiki/JavaScript Java Script] uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in [http://en.wikipedia.org/wiki/ASP.NET ASP] that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>Java struts solution - http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p> ASP .NET solution - http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>PHP solution -http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>ASP.NET solution - http://forums.techarena.in/software-development/1149257.htm</p>
<p>Ruby on rails solution - http://www.stackoverflow.com</p>
<p>Struts solution http://www.sbouchard.com/2009/01/19/synchronizer-token-pattern-in-struts </p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-15T01:21:23Z

Bschanda: /* Introduction */

==Synchronizer token pattern==

==Introduction==

Developers of web sites face problem with maintaining normal control flow when there is multiple form submissions
The issue occurs when the user clicks on the submit button twice and the data is sent back to the client twice or when client access a previously bookmarked page . Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Synchronizer token pattern] is one such server side method in which once a submission is made a flag is set and on re-submission the stored value is compared and if it is a duplicate no action is taken . Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language) Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern in [http://en.wikipedia.org/wiki/PHP PHP]

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> [http://en.wikipedia.org/wiki/JavaScript Java Script] uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in [http://en.wikipedia.org/wiki/ASP.NET ASP] that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-14T17:33:39Z

Bschanda: /* ASP.NET */

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language) Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern in [http://en.wikipedia.org/wiki/PHP PHP]

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> [http://en.wikipedia.org/wiki/JavaScript Java Script] uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in [http://en.wikipedia.org/wiki/ASP.NET ASP] that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-14T17:32:44Z

Bschanda: /* JavaScript */

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language) Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern in [http://en.wikipedia.org/wiki/PHP PHP]

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> [http://en.wikipedia.org/wiki/JavaScript Java Script] uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in ASP that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-14T17:32:03Z

Bschanda: /* PHP */

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language) Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern in [http://en.wikipedia.org/wiki/PHP PHP]

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> Java Script uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in ASP that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-14T17:31:11Z

Bschanda: /* Java */

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language) Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> Java Script uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in ASP that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-14T17:30:50Z

Bschanda:

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

[http://en.wikipedia.org/wiki/Java_(programming_language)Java] uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> Java Script uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in ASP that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki, various languages handle the problem of multiple form submission either by client side or server
side methods. Server side handling is more reliable as some web browsers do not support the disabling of button feature. Synchronizer token pattern is best solution as illustrated in Java .In most languages, for server side handling, a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database. Some websites just pop message to user to wait until action is completed. Overall Java script is best way to handle duplicate form submission </p>

==References==

<p> Below are some of the references for further reading </p>

<p>http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-10T00:45:19Z

Bschanda: /* References */

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

Java uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> Java Script uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in ASP that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki various languages handle the problem of multiple form submission either by client side or server
side methods.Server side handling is more reliable as some web browsers do not support the disabling of button feature .Synchronizer token pattern is best solution as illustrated in Java .In most languages for server side handling a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database.Some websites just pop message to user to wait until action is completed .Overall Java script is best way to handle duplicate form submission</p>

==References==

<p> Below are some of the references for further reading </p>

<p>http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-10T00:44:22Z

Bschanda: /* References */

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

Java uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> Java Script uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in ASP that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki various languages handle the problem of multiple form submission either by client side or server
side methods.Server side handling is more reliable as some web browsers do not support the disabling of button feature .Synchronizer token pattern is best solution as illustrated in Java .In most languages for server side handling a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database.Some websites just pop message to user to wait until action is completed .Overall Java script is best way to handle duplicate form submission</p>

==References==

<p> Java -http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p> Asp .Net - http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>Php - http://drupal.org/node/69048</p>
<p>Php - http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>

CSC/ECE 517 Fall 2009/wiki2 3 bd

2009-10-10T00:42:58Z

Bschanda: /* References */

==Synchronizer token pattern==

==Introduction==

Web application developers and designers face the problem with maintaining normal flow of control when multiple form submissions are made in a website .
This situation typically occurs when a user clicks more than once on a submit button before the response is sent back or when a client accesses a view by returning to a previously bookmarked page. Control flow sequence is particularly important to preserve when form submission involves transaction processing on the server. There are many solutions to the situation ,some websites just warn the user not to submit twice once a submission is made and to wait for the response .In other cases we have client side and server side solutions to the problem .Server side solution being more reliable than client side .In the client side model the button is disabled based on a flag which is set once first submission is performed .Below we discuss some the ways this is handled in different in
different languages -

==Java==

Java uses the server side solution to solve this problem .The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.
<p> Based on the above, the solution appears complete. But an element is missing: how do we specify/implement the alternate course of action when an invalid token is detected. In fact, given the case where the submit button is reclicked, the second request will cause the loss of the first response containing the expected result. The thread that executes the first request still runs, but has no means of providing its response to the browser. Hence, the user may be left with the impression that the transaction did not complete, while in reality, it may have successfully completed.This tip's proposed strategy builds on the Struts framework to provide a complete solution that prevents duplicate submission and still ensures the display of a response that represents the original request's outcome. The proposed implementation involves the abstract class SynchroAction, which actions can extend to behave in the specified synchronized manner. This class overrides the Action.perform() method and provides an abstract performSynchro() method with the same arguments. Below is the example implementation in Java using struts </p>
Eg Code:

<pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{ HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request))
{
try {
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors) request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty())
{
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true"); }
catch (IOException e)
{
throw e;
}
catch (ServletException e)
{
session.setAttribute(COMPLETE_KEY, "true");
throw e; } }

else {
{
throw it if (e != null) { if (e instanceof IOException) { throw (IOException) e; }
else if (e instanceof ServletException)
{ throw (ServletException) e;
} } context if ("request".equals(mapping.getScope()))
{ request.setAttribute(mapping.getAttribute(), f); }

else { session.setAttribute(mapping.getAttribute(), f); }
(ActionErrors) session.getAttribute(ERRORS_KEY));
session.getAttribute(FORWARD_KEY); }
else {
return forward; }

</pre>

As we can see from the above code that for a valid token the protected action is performed only once ,while the action is being performed any other requests are received then
they are directed to performInvalidToken() method until the action is completed ,this method simply returns an ActionForward named "synchroerror" ,this should lead to a form with a button for continue , this just resubmits without any parameters and nothing happens until action of first form submission is completed .When the action completes, it stores its forward, form, exception, and errors, if any, in the session, and it sets a flag to indicate it has completed. The first request coming after the action completion will get the forward, form, exception, and errors from the session and continue as if it was the first request itself.

==PHP==

The following method is one of the ways of creating a Synchronous token pattern

The below given code needs to be added to ur code

<pre>

<?php
session_start();
$secret=md5(uniqueid(rand(), true));
$_SESSION['FORM_SECRET']=$secret;
?>

Here uniqueid() is used to create Unique ID. Then md5() is used to create 32 character hash of this Unique ID. This unique id is stored in the session for later use. We also need to use a different session variable for each form.

Then we add a hidden field anywhere in the form using the below given code.
<input type="hidden" name="form_secret" id="form_secret"
value="<?php echo $_SESSION['FORM_SECRET'];?>" />

we need to compare the value of the hidden field with the value stored in the session. If the value is the same, that means its the first time. Hence process the form data. Now unset the values stored in this session. now when the user refreshes the page, the code for processing form will be skipped. It can be done as given below

<?php
session_start();
//get the hidden value
$form_secret=$_POST['form_secret'];
if(isset($_SESSION['FORM_SECRET'])) {
if(strcasecmp($form_secret,$_SESSION['FORM_SECRET'])===0) {
/*We need to have the form submission code here
*/
unset($_SESSION['FORM_SECRET']);
}else {
//this is the condition of key which is invalid
}
}else {
//this is the case where is secret key is no there
echo 'Form data has been processed once!';
}
?>

</pre>

==JavaScript==

<p> Java Script uses two methods to prevent Duplicate form submissions .The first method disables the button and the second method uses cookies to prevent multiple submissions.</p>

Eg:

<pre>
a.
<SCRIPT LANGUAGE="JavaScript" TYPE="text/JavaScript">
function formControl(submitted)
{ if(submitted=="1")
{ commentForm.Submit.disabled=true alert
("Thanks for your comments!") } } </SCRIPT>

</pre>
<p>
The JavaScript event that fires this script is the onClick event. You're telling it to disable the SUBMIT button after the button is clicked. At that point, the button value equals "1."
We included a JavaScript ALERT box in this example so that you'll know the form is working.
To tie this JavaScript to our form, we change the form's SUBMIT button to call the JavaScript function. This is done by adding an onClick event to the appropriate INPUT tag, as shown below.</p>

<pre>
<FORM action="" method="post" enctype="text/plain" name="commentForm">
How did you find our site? <input type="text" maxlength="30" size="20"><br><br>
<input type="submit" name="Submit" value="Send Comments and Get a Cookie" onClick="formControl(1)">
</FORM></pre>

<p>The problem with this approach is only Internet explorer supports the disable option ,so it is browser dependent.</p>
<p> Below is another approach in java script using cookies in browser</p>
<pre>
b.

The Below code has to be inserted into head section of our code

<script>  </script>
</pre>

<p>
When a user submits the form, the function sets an identifying cookie. Before the form processes, the function checks to see if there is already a cookie set. If not, the form handles the submission as normal. If there is a cookie, the user gets an alert box that says "You've already submitted your answers" and the form submission is blocked.
This is a good, cross-browser way to avoid duplicate submissions, but we have to be careful that user's browser must accept cookies and have JavaScript turned on for this method to work.</p>

==ASP.NET==

<p>
Here is an implementation in ASP that prevents duplicate form submission. In this implementation, we consider two ways of avoiding this problem. One is the Unsafe button method, where the button does not vanish after the user clicks the button. But at the same time does not consider two or more consecutive clicks, if done within a specified period of time, as a different request from the orginal one. The other method is the safe button method where the button vanishes after the button is clicked once and returns only after the request has been completed or timed out.</p>

<pre>
<%@ Page Language="VB" %>
<script runat="server">
Dim counter As Integer
Sub Page_Load()
If Session("counter") Is Nothing Then
counter = 0
Else
counter = CInt( Session("counter") )
End If
If IsPostBack Then
counter += 1
Session("counter") = counter
End If
Label1.Text = "Counter = " & counter.ToString()
SafeButton.Attributes.Add("onclick", "disableButton();return true")
End Sub

Sub Process_Click(sender As Object, e As EventArgs)
Dim i As Long
' 2-second delay
Dim endTime As DateTime = DateTime.Now.AddSeconds(2)
While DateTime.Now < endTime
End While
Label2.Text = "Finished @ " & DateTime.Now.ToString()
End Sub

Sub Button2_Click(sender As Object, e As EventArgs)
Session("counter") = 0
Label1.Text = "Counter = " & Session("counter").ToString()
End Sub

</script>
<html>
<head>
<script language="javascript">
function disableButton()
{
document.form1.SafeButton.style.visibility = "hidden";
}
</script>
</head>
<body>
<form runat="server" id="form1">
<p>
<asp:Label id="Label1" runat="server">Label</asp:Label>
</p>
<p>
<asp:Label id="Label2" runat="server">Label</asp:Label>
</p>
<p>
<asp:Button id="UnsafeButton" onclick="Process_Click" runat="server" Text="Unsafe Button"></asp:Button>
</p>
<p>
<asp:Button id="SafeButton" onclick="Process_Click" runat="server" Text="Safe Button"></asp:Button>
</p>
<p>
 <asp:Button id="Button2" onclick="Button2_Click" runat="server" Text="Clear Counter"></asp:Button>
</p>
<span id="span1"></span>
</form>
</body>
</html>
</pre>

<p>
As explained earlier, the Unsafe button allows users to click on submit multiple times. But clicking on the button again doesnt do anything, a two-second delay has been put into the button handler to emulate the time that a back-end process might take. So unless that time is up it doesnt effective count as a click.</p>
<p>
Even for the Safe button the same process runs. But in this case as soon as the button is clicked, it disappears, preventing you from being able to click it again until the processing (postback) is complete. This ensures that multiple form request is not sent by completely taking out the submit button. </p>

==Ruby On Rails==

Ruby on Rails uses the Submit button disabling method to prevent Multiple form submissions .It uses the submit_tag option .Below is the code that demonstrate this

<pre>
submit_tag "Submit", :disable_with => "Saving..."
</pre>

This adds behavior to the submit button to disable it once clicked, and to display "Saving..." instead of "Submit".

==Conclusion==
<p>
As illustrated in the above wiki various languages handle the problem of multiple form submission either by client side or server
side methods.Server side handling is more reliable as some web browsers do not support the disabling of button feature .Synchronizer token pattern is best solution as illustrated in Java .In most languages for server side handling a token is set once on submission and compared again on resubmission to check for duplicates ,this prevents the data from being inserted again into the database.Some websites just pop message to user to wait until action is completed .Overall Java script is best way to handle duplicate form submission</p>

==References==

<p> Support in Java -http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1</p>
<p>http://forums.asp.net/t/447620.aspx?PageIndex=1</p>
<p>http://drupal.org/node/69048</p>
<p>http://phpsense.com/php/prevent-duplicate-form-submission.html</p>
<p>http://forums.techarena.in/software-development/1149257.htm</p>
<p>http://www.stackoverflow.com</p>