Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T03:08:17Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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 [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf 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 : http://www.ibm.com/developerworks/rational/library/jun07/kroll/

=== 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 1
'''

{| {{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

'''Figure 1'''

[[Image:ProcessComparisons.jpg]]

== 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-19T03:06:24Z

Ruby Fan: /* 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 ? ==

[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.
 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 .

== 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 [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf 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 : http://www.ibm.com/developerworks/rational/library/jun07/kroll/

=== 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 1
'''

{| {{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

'''Figure 1'''

[[Image:ProcessComparisons.jpg]]

== 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-19T03:04:44Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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 : http://www.ibm.com/developerworks/rational/library/jun07/kroll/

=== 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 1
'''

{| {{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

'''Figure 1'''

[[Image:ProcessComparisons.jpg]]

== 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-19T03:04:05Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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 : http://www.ibm.com/developerworks/rational/library/jun07/kroll/

=== 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 1
'''

{| {{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

'''
Figure 1'''

[[Image:ProcessComparisons.jpg]]

== 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-19T03:03:28Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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 : http://www.ibm.com/developerworks/rational/library/jun07/kroll/

=== 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 1
'''

{| {{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
'''
Figure 1'''
[[Image:ProcessComparisons.jpg]]

== 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-19T03:02:19Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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 : http://www.ibm.com/developerworks/rational/library/jun07/kroll/

=== 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

[[Image:ProcessComparisons.jpg]]

== 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

File:ProcessComparisons.jpg

2009-11-19T03:01:56Z

Ruby Fan:

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:58:38Z

Ruby Fan: /* 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.
 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 .

== 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 : http://www.ibm.com/developerworks/rational/library/jun07/kroll/

=== 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:57:27Z

Ruby Fan: /* 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.
 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 .

== 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,www.ibm.com/.../rational/library/jun07/kroll/

=== 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:43Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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]]

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:11Z

Ruby Fan: /* Agile Modeling (AM) */

'''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.
 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 .

== 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]]

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:36Z

Ruby Fan: /* 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.
 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 .

== 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]]

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:51:28Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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:49:31Z

Ruby Fan: /* 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.''

__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.
 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 .

== 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:46:20Z

Ruby Fan: /* A Brief look at other Agile methodologies */

'''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.
 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 .

== 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:44:04Z

Ruby Fan: /* 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 ? ==

[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.
 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 .

== 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:38Z

Ruby Fan: /* References and Links */

'''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.
 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 .

== 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:39Z

Ruby Fan: /* 6) Conclusion */

'''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.
 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 .

== 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:37:58Z

Ruby Fan:

'''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.
 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 .

== 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

==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:36:17Z

Ruby Fan:

'''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.
 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 .

== 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 ===

[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:Dsdm.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

==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

File:LifecycleAgileUP.gif

2009-11-19T02:32:07Z

Ruby Fan:

File:BestPractices.jpg

2009-11-19T02:31:35Z

Ruby Fan:

File:Lean Software Development.jpg

2009-11-19T02:31:07Z

Ruby Fan:

File:LifecycleFDD.gif

2009-11-19T02:30:01Z

Ruby Fan:

File:Crystal.jpg

2009-11-19T02:28:39Z

Ruby Fan:

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T02:23:20Z

Ruby Fan:

'''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.
 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 .

== 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

== 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:04:45Z

Ruby Fan:

'''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.
 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 .

== 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.

=== 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:Scrum.gif

2009-11-19T02:03:42Z

Ruby Fan:

CSC/ECE 517 Fall 2009/wiki3 11 ab

2009-11-19T01:50:34Z

Ruby Fan:

===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.
 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 .

== 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

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 2 AJAXandMVC

2009-10-11T00:44:04Z

Ruby Fan:

'''AJAX AND MVC'''
----

''There are several MVC frameworks that can take advantage of the client-side processing facilities of AJAX. Our aim in writing this wiki page is to consider what parts of the MVC framework (views, controllers?) can migrate part of their functionality to AJAX. In analyzing this problem, we would be considering some server-side languages such as Java, PHP, and Ruby, as well as the .NET framework.''

__TOC__

=== What is MVC ? ===

[http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller '''Model–View–Controller (MVC)'''] is an architectural pattern used in software engineering. The pattern isolates business logic from input and presentation, permitting independent development, testing and maintenance of each.MVC is often seen in web applications where the view is the [http://en.wikipedia.org/wiki/Html HTML] or [http://en.wikipedia.org/wiki/Xhtml XHTML] generated by the app. The controller receives [http://en.wikipedia.org/wiki/HTTP#Request_methods GET] or [http://en.wikipedia.org/wiki/HTTP#Request_methods POST] input and decides what to do with it, handing over to domain objects (ie the model) which contain the business rules and know how to carry out specific tasks such as processing a new subscription.MVC helps to reduce the complexity in architectural design and to increase flexibility and reuse of code.

[[Image:ajaxandmvc.gif]]

=== What is AJAX ? ===
[http://en.wikipedia.org/wiki/AJAX AJAX] stands for Asynchronous JavaScript and [http://en.wikipedia.org/wiki/XML XML].It is a Web development technique for creating web applications. It Makes web pages more responsive by exchanging small amounts of data. It allows the web page to change its content without refreshing the whole page. A web browser technology is independent of web server software. It gives desktop application a feel good factor,by doing behind the scene server communication. A famous example: [http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=106230 Google's suggest] uses Ajax, and it also helped in making it popular.

Advantages:

Improves the user experience in,

# Analyzing information typed into browser in real time
# Provide a richer experience
# Increases responsiveness of web pages

Improve bandwidth utilization

# Only data which is required is retrieved from the server

How does the magic work??
[[Image:Ajax_fig1.png|left]] [[Image:ajax_fig2.png|none]]
AJAX runs in your browser.
Works with asynchronous data transfers(HTTP requests) between the browser and the web server.
HTTP requests are sent by [http://en.wikipedia.org/wiki/JavaScript JavaScript] calls without having to submit a form.
XML is commonly used as the format for receiving server data but plain text and some other format may be used as well.
 
Instead of loading a web page, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf.
 The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something. 
Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application

 
Technologies used in AJAX.
# JavaScript - JavaScript is a loosely typed object based scripting language supported by all major browsers and essential for AJAX interactions. JavaScript functions in a page are invoked as event handlers when an event in a page occurs such as a page load, a mouse click, or a key press in a form element.
# DOM - is API for accessing and manipulating structured documents. In most cases DOM represent the structure of XML or HTML documents.
# CSS - Allows you to define the presentation of a page such as fonts, colors, sizes, and positioning. CSS allow for a clear separation of the style from the content and may be changed pragmatically by JavaScript.
# HTTP - Understanding the basic request/response interaction model of HTTP is important for a developer using AJAX. You will be
exposed to the GET and PUT method when configuring an [http://en.wikipedia.org/wiki/XMLHttpRequest XMLHttpRequest] and HTTP response codes when processing callback.

Some of the drawbacks:[http://en.wikipedia.org/wiki/Ajax_%28programming%29]
# AJAX interfaces are substantially harder to develop properly than static pages. 
# Pages dynamically created using successive AJAX requests do not automatically register themselves with the browser's history engine, so clicking the browser's "back" button may not return the user to an earlier state of the AJAX-enabled page, but may instead return them to the last full page visited before it. Workarounds include the use of invisible IFrames to trigger changes in the browser's history and changing the anchor portion of the URL (following a #) when AJAX is run and monitoring it for changes. 
# Dynamic web page updates also make it difficult for a user to bookmark a particular state of the application. Solutions to this problem exist, many of which use the URL fragment identifier (the portion of a URL after the '#') to keep track of, and allow users to return to, the application in a given state. 
# Because most web crawlers do not execute JavaScript code, publicly indexable web applications should provide an alternative means of accessing the content that would normally be retrieved with AJAX, to allow search engines to index it. 
# Any user whose browser does not support JavaScript or XMLHttpRequest, or simply has this functionality disabled, will not be able to properly use pages which depend on AJAX. Similarly, devices such as mobile phones, PDAs, and screen readers may not have support for the required technologies. Screen readers that are able to use AJAX may still not be able to properly read the dynamically generated content. The only way to let the user carry out functionality is to fall back to non-JavaScript methods. This can be achieved by making sure links and forms can be resolved properly and do not rely solely on AJAX. In JavaScript, form submission could then be halted with "return false". 
# The same origin policy prevents some AJAX techniques from being used across domains, although the W3C has a draft of the XMLHttpRequest object that would enable this functionality. 
# AJAX opens up another attack vector for malicious code that web developers might not fully test for. 
# AJAX-powered interfaces may dramatically increase the number of user-generated requests to web servers and their back-ends (databases, or other). This can lead to longer response times and/or additional hardware needs. 
# User interfaces can be confusing or behave inconsistently when normal web patterns are not followed. 
# Due to multiple dependent asynchronous requests, you can’t rely on any order of operations in classical AJAX models. 

=== How does AJAX fit with MVC ? ===
Ajax functionality needs to be implemented first in the view in terms of the call made and then in controller for handling the call . The view should have the call to the Ajax action which is implemented in controller.
MVC Controller needs to have a ajax-action class to take whatever action is required on the business model in model. Action methods can do things like render different views, render a portion of the user interface defined within a partial view as opposed to the full page. It can be consider that any behavioral JavaScript as part of the Controller, including attaching events as well as sending HTTP requests.
AJAX tag libraries [http://ajaxtags.sourceforge.net/] can be to fit ajax into any framework.
 
Moreover, there has been AJAX MVC[http://ajax-mvc.sourceforge.net/] used for much smoother integration of ajax into mvc framework.

=== AJAX IN RAILS ===

[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provide support for AJAX in the form of helper methods. There is no need to add [http://en.wikipedia.org/wiki/JavaScript JavaScript] code in the view templates. Instead, the helper methods create the JavaScript code in the HTML page derived from the view templates. One of the ways this could be understood is through an example [http://onlamp.com/pub/a/onlamp/2005/06/09/rails_ajax.html] of link_to_remote() method which can be used to get the latest time from a server and display it on a web page.Here is a sample view template.

''' SERVER SIDE CODE '''
<pre>
<html>
<head>
<title>Ajax Demo</title>
<%= javascript_include_tag "prototype" %>
</head>
<body>
<h1>What time is it?</h1>
<div id="time_div">
I don't have the time, but
<%= link_to_remote( "click here",
:update => "time_div",
:url =>{ :action => :say_when }) %>
and I will look it up.
</div>
</body>
</html>

</pre>

What this view does this is that it gives a link to display the current time. The current time would be fetched in the background without refreshing the browser. Now, there are two main helper methods to do this job. One of them is javascript_include_tag() that includes the [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework Prototype JavaScript library]. This is included with Rails package and is a basic requirement to make use of AJAX functionality. The other is link_to_remote() call that talks to the remote server when a request for current time is made.
Here is a brief explanation of the parameters used in this method:

#'''click_here''' : this is the text for displaying the link
#'''time_div''' : it is the id of the HTML DOM element that would have the current time content
#'''url''' : refers to the server side action and it is say_when in this case

[[Image:ajaxinrails_fig1.png]] [[Image:ajaxinrails_fig2.png]]

The role of the index action is to render the index.html file which displays the ‘before’ view. The controller is named demo and is coded as,

''' SERVER SIDE CODE '''
<pre>
class DemoController < ApplicationController
def index
end

def say_when
render_text "The time is " + DateTime.now.to_s + ""
end
end
</pre>

When “click here” is clicked on we would see the ‘after’ view which is shown above. What happens over here is that when a user clicks on “click me” an [http://en.wikipedia.org/wiki/XMLHttpRequest XMLHttpRequest] is created by the browser and sent to the server where in the server invokes the say_when action and renders the HTML response fragment containing the current time. When the client side JavaScript receives the response it replaces the contents of the div with an id of time_div.Besides the above example, there are other AJAX helper methods like the form method, i.e., form_remote_tag(). Here, is a prototype for it.

<pre>
<%= form_remote_tag :url => { :action => 'create' },
:update => ‘ajax_result’ %>
<%= render :partial => ‘form’ %>
<%= submit_tag "Create" %>
<%= end_form_tag %>

<div id="ajax_result"></div>
</pre>

Ajax in Ruby has immense potential in its application and can add to the efficiency as well as to the looks of a web template. In order to get a more in depth foot in Ajax on Rails , there is a very popular book [http://oreilly.com/catalog/9780596527440 “Ajax on Rails”] by Scott Raymond and published by O’Reilly.

=== AJAX IN PHP ===

[http://en.wikipedia.org/wiki/PHP PHP] supports [http://en.wikipedia.org/wiki/JSON JSON] encoding by default, this allows you to pass complex data types back and forth between PHP and Javascript fairly easily.Consider this simple example.[http://www.ajaxf1.com/tutorial/ajax-php.html?page=2]

To demonstrate the AJAX PHP connection we will create a very simple form with 2 input fields. In the first field you can type any text and we will send this text to our PHP script which will convert it to uppercase and sends it back to us. 
[[Image:Ajax-mvc-php.PNG ]]

''' CLIENT SIDE CODE '''
<pre>
<script>
// Get the HTTP Object
function getHTTPObject(){
if (window.ActiveXObject)
return new ActiveXObject("Microsoft.XMLHTTP");
else if (window.XMLHttpRequest)//catches the response from the server
return new XMLHttpRequest();//this object is for AJAX PHP communication
else {
alert("Your browser does not support AJAX.");
return null;
}
}

// Change the value of the outputText field
function setOutput(){
if(httpObject.readyState == 4){
document.getElementById('outputText').value = httpObject.responseText;
}

}

// Implement business logic
function doWork(){
httpObject = getHTTPObject();
if (httpObject != null) {
httpObject.open("GET", "upperCase.php?inputText="
+document.getElementById('inputText').value, true);
httpObject.send(null);
httpObject.onreadystatechange = setOutput;
}
}
</script>

<form name="testForm">
Input text: <input type="text" onkeyup="doWork();" name="inputText" id="inputText" />
Output text: <input type="text" name="outputText" id="outputText" />
</form>
</pre>

''' SERVER SIDE CODE '''

Server side functionality is very simple compared to the client side. In the PHP code we just need to check the $_GET super-global array. Afterwards convert it to uppercase and echo the result.

<pre>
<?php
if (isset($_GET['inputText']))
echo strtoupper($_GET['inputText']);
?>
</pre>

=== AJAX IN .NET Framework ===

[http://en.wikipedia.org/wiki/ASP.NET ASP.NET] AJAX is the free Microsoft AJAX framework for building highly interactive and responsive web applications that work across all popular browsers. The ASP.NET AJAX framework includes Server-Side ASP.NET AJAX, Client-Side ASP.NET AJAX, the AJAX Control Toolkit, and the [http://en.wikipedia.org/wiki/JQuery jQuery] library. ASP.NET AJAX enables developers to choose their preferred method of AJAX development, whether it is server-side programming, client-side programming, or a combination of both.ASP.NET AJAX server-side controls such as the ScriptManager, UpdatePanel, and the UpdateProgress control to add AJAX functionality to an ASP.NET application without writing any JavaScript. For example, the UpdatePanel control enables you to update a portion of an ASP.NET page without requiring you to reload the entire page. The ScriptManager control enables you to manage browser history in an AJAX application by updating the browser back button after an AJAX request.

If you prefer to work directly with JavaScript then you can take advantage of client-side ASP.NET AJAX. The client-side ASP.NET AJAX Library provides a foundation for building rich client-side applications. The library simplifies cross-browser development of client-side applications. For example, the library enables you to call web services and create components and controls -- all through pure client-side JavaScript code.

One cool thing: AJAX Extensions for .NET
No need to modify server-side code
No javascript functions need to be added
AJAX can be enabled/disabled by changing one line of code (“Script Manager”)
Its as simple as 1 2 3 :)
# “Drag and Drop” Script Manager Control onto your form
# Place “Update Panels” around content you wish to have async updates for
# Add triggers to the update panels to tell them which events to update on.

=== AJAX IN JAVA ===

[http://en.wikipedia.org/wiki/Java Java] technology and AJAX work well together. Java technology provides the server-side processing for AJAX interactions. It can provide this through servlets, [http://en.wikipedia.org/wiki/JavaServer_Pages JavaServer Pages (JSP)] technology, [http://en.wikipedia.org/wiki/JavaServer_Faces JavaServer Faces (JSF)] technology, and web services. The programming model for handling AJAX requests uses the same APIs that you would use for conventional web applications. JSF technology can be used to create reusable components that generate the client-side JavaScript and corresponding server-side AJAX processing code.

Consider a simple example [http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html] where AJAX and java servlets interact.HTML page generated in JSP technology contains an HTML form that requires server-side logic to validate form data without refreshing the page. A server-side web component (servlet) named ValidateServlet will provide the validation logic.

[[Image:railsinjava_fig1.png]]

Ajax interaction as they appear in Figure:
# A client event occurs.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#event_occurs]
# An XMLHttpRequest object is created and configured. [http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#configure_xmlhttprequest]
# The XMLHttpRequest object makes a call.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#make_call]
# The request is processed by the ValidateServlet.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#serverside_processing]
# The ValidateServlet returns an XML document containing the result.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#xml_returned]
# The XMLHttpRequest object calls the callback() function and processes the result.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#post_process]
# The HTML DOM is updated.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#update_dom]

=== Conclusion ===

[http://en.wikipedia.org/wiki/Rich_Internet_application Rich Internet applications (RIA)] are web application that approximate the look and feel and usability of desktop application. It adds performance and rich GUI. AJAX enables RIA, which uses client-side scripting to make web applications more responsive. Ajax application separates client-side user interaction and server communication, and run them in parallel, reducing the delays of server-side processing normally experienced by user.

MVC frameworks in various languages like PHP, Rails, .NET etc provides well defined support to implement AJAX functionality. This article provided a brief overview of this support in Java, .NET, Rails and PHP.

=== References ===

* http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

* http://en.wikipedia.org/wiki/Ajax_%28programming%29

* http://www.ajaxf1.com/tutorial/ajax-php.html?page=2

* http://www.asp.net/ajax/

* http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html

* http://www.phpied.com/ajax-mvc/

CSC/ECE 517 Fall 2009/wiki1a 6 rf

2009-09-09T00:28:36Z

Ruby Fan:

''The objective over here is to examine the different functionality offered by the different IDEs for Ruby, such as Aptana, NetBeans, and RubyMine. And compare them along dimensions such as facilities, ease of use, system requirements, and support for the Ruby way of thinking.''

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,i.e.,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# Aptana Proponent’s View
## [http://blog.hulihanapplications.com/browse/view/12 Aptana View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]
## [http://www.mslater.com/tags/netbeans%20radrails%20aptana NetBeans View 4]
# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.Here, is the link for installing Ruby on Windows/Mac OS X/Linux: [http://www.ruby-lang.org/en/downloads/ Ruby Downloads]

For installing Rails in Windows use the RubyGems package manager to install it. Update the gem repository by entering,

<pre>gem update -–system</pre>

And then install Rails by executing the following statement,

<pre>gem install rails</pre>

The Mac and Linux versions come shipped with the most stable and versions of Ruby and Rails.For updating Rails enter,

<pre>sudo gem install rails</pre>

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 ,Ruby 1.8/Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more||1 GB of free disk space ||Size : 70.94 MB or more
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 min. screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more ||850 MB of free disk space ||Size : 74.82 MB or more
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 min. screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more||850 MB of free disk space ||Size : 52.22 MB or more
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements

CSC/ECE 517 Fall 2009/wiki1a 6 rf

2009-09-09T00:18:17Z

Ruby Fan: /* Software Requirements */

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,i.e.,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# Aptana Proponent’s View
## [http://blog.hulihanapplications.com/browse/view/12 Aptana View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]
## [http://www.mslater.com/tags/netbeans%20radrails%20aptana NetBeans View 4]
# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.Here, is the link for installing Ruby on Windows/Mac OS X/Linux: [http://www.ruby-lang.org/en/downloads/ Ruby Downloads]

For installing Rails in Windows use the RubyGems package manager to install it. Update the gem repository by entering,

<pre>gem update -–system</pre>

And then install Rails by executing the following statement,

<pre>gem install rails</pre>

The Mac and Linux versions come shipped with the most stable and versions of Ruby and Rails.For updating Rails enter,

<pre>sudo gem install rails</pre>

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 ,Ruby 1.8/Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more||1 GB of free disk space ||Size : 70.94 MB or more
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 min. screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more ||850 MB of free disk space ||Size : 74.82 MB or more
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 min. screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more||850 MB of free disk space ||Size : 52.22 MB or more
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements

CSC/ECE 517 Fall 2009/wiki1a 6 rf

2009-09-08T23:51:04Z

Ruby Fan: /* Hardware Requirements */

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,i.e.,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# Aptana Proponent’s View
## [http://blog.hulihanapplications.com/browse/view/12 Aptana View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]
## [http://www.mslater.com/tags/netbeans%20radrails%20aptana NetBeans View 4]
# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 ,Ruby 1.8/Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more||1 GB of free disk space ||Size : 70.94 MB or more
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 min. screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more ||850 MB of free disk space ||Size : 74.82 MB or more
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 min. screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (min)/1 GB (recommended)
|-
| Disk Space||Size : 71.9 MB (Eclipse plug-in) or more||850 MB of free disk space ||Size : 52.22 MB or more
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements

CSC/ECE 517 Fall 2009/wiki1a 6 rf

2009-09-08T18:15:26Z

Ruby Fan: /* Ease of Use */

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,i.e.,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# Aptana Proponent’s View
## [http://blog.hulihanapplications.com/browse/view/12 Aptana View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]
## [http://www.mslater.com/tags/netbeans%20radrails%20aptana NetBeans View 4]
# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 (support : Ruby 1.8 and Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Microsoft Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||1 GB of free disk space ||File size : 70.94 MB. No mention about the disk size
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 74.82 MB. No mention about the disk size
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 52.22 MB. No mention about the disk size
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements

CSC/ECE 517 Fall 2009/wiki1a 6 rf

2009-09-08T18:03:37Z

Ruby Fan: /* Hardware Requirements */

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,i.e.,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# Aptana Proponent’s View
## [http://blog.hulihanapplications.com/browse/view/12 Aptana View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]
# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 (support : Ruby 1.8 and Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Microsoft Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||1 GB of free disk space ||File size : 70.94 MB. No mention about the disk size
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 74.82 MB. No mention about the disk size
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 52.22 MB. No mention about the disk size
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements

CSC/ECE 517 Fall 2009/wiki1a 6 rf

2009-09-08T18:03:18Z

Ruby Fan: /* Ease of Use */

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,i.e.,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# Aptana Proponent’s View
## [http://blog.hulihanapplications.com/browse/view/12 Aptana View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]
# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Apatana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 (support : Ruby 1.8 and Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Microsoft Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||1 GB of free disk space ||File size : 70.94 MB. No mention about the disk size
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 74.82 MB. No mention about the disk size
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 52.22 MB. No mention about the disk size
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements

CSC/ECE 517 Fall 2009/wiki1a 6 rf

2009-09-08T15:06:13Z

Ruby Fan:

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,i.e.,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Apatana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 (support : Ruby 1.8 and Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Microsoft Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||1 GB of free disk space ||File size : 70.94 MB. No mention about the disk size
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 74.82 MB. No mention about the disk size
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 52.22 MB. No mention about the disk size
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements

CSC/ECE 517 Fall 2009/wiki1a 6 a1

2009-09-08T15:03:21Z

Ruby Fan: /* IDEs FOR RUBY */

__TOC__

== IDEs FOR RUBY ==

There are several IDEs that can be used as a tool in the development of Ruby and Ruby on the Rails project. Some of them are ActiveState Komodo5, 3rd Rail, Arachno Ruby, Mondrian Ruby, RubyMine , Netbeans, Eclipse plug-in such as Aptana RadRails. In the rest of the content to follow, we will be looking at mainly three Ruby developments IDEs ,that is,

# Aptana RadRails
# Netbeans
# RubyMine

== Facilities ==

The three IDEs for Ruby vouch to offer a number of useful facilities for Ruby projects. Here, is our analysis of the functionality or features offered on different IDEs. The measuring scale in comparing the three IDEs has been inherited from the Aptana site and extended to RubyMine.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|''' Aptana RadRails'''
| align="center" style="background:#f0f0f0;"|'''Netbeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| '''General'''||||||
|-
| ||||||
|-
| Price||Free||Free||Free
|-
| License Type||Open Source||Open Source||Open Source
|-
| Available Standalone or as Eclipse Plugin||Yes||No||No
|-
| ||||||
|-
| '''Interpreter Support/Bundling'''||||||
|-
| ||||||
|-
| Bundled JRuby Interpreter||Yes||Yes||Yes
|-
| Interpreter Support/Bundling||Yes||Yes||Yes
|-
| ||||||
|-
| '''Scriptability/Extensibility'''||||||
|-
| ||||||
|-
| Scriptable via Ruby||Yes||No||No
|-
| ||||||
|-
| '''Debugging / Profiling'''||||||
|-
| ||||||
|-
| Debugger||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby) ||Yes ( classic and ruby-debug for MRI; ruby-debug bundled with Jruby)
|-
| JavaScript Debugging||Yes||No||Yes
|-
| Profiler||Yes (Pro)||No||No
|-
| ||||||
|-
| '''Editors'''||||||
|-
| ||||||
|-
| HTML Editor||Yes||Yes||Yes
|-
| CSS Editor||Yes||Yes||Yes
|-
| JavaScript Editor||Yes||Yes||Yes
|-
| JSON Editor||Yes (Pro)||Yes||Yes
|-
| SQL Editor||Yes||Yes||Yes
|-
| YML Editor||Yes||Yes||Yes
|-
| RHTML/ERb Editor||Yes||Yes||Yes
|-
| XML Editor||Yes||Yes||Yes
|-
| ||||||
|-
| '''Ruby Editing'''||||||
|-
| ||||||
|-
| Code Completion||Yes||Yes||Yes
|-
| Type Inferencing||Yes||Yes||Yes
|-
| Ruby-specific search engine (Find usages)||Yes||Yes||Yes
|-
| Code analysis (warnings/errors/hints)||Yes||Yes||Yes
|-
| Type Hierarchy View||Yes||No||No
|-
| Call Hierarchy View||Yes||No||No
|-
| Mylyn Integration||Yes||No||No
|-
| Regular Expression Tester||Yes||No||No
|-
| Quick Outline||Yes||No||No
|-
| Spell Checking Support||Yes||Yes||No
|-
| Smart Indent||Yes||Yes||No
|-
| Mark Occurrences||Yes||Yes||No
|-
| ||||||
|-
| '''Refactoring'''||||||
|-
| ||||||
|-
| Rename||Yes||Yes||Yes
|-
| Convert Local Variable to field||Yes||No||No
|-
| Encapsulate Field||Yes||No||Yes
|-
| Extract Method||Yes||Yes||No
|-
| Extract Constant||Yes||Yes||No
|-
| Inline Class||Yes||No||No
|-
| Inline Local Variable||Yes||No||No
|-
| Inline Method||Yes||No||No
|-
| Merge Class Parts (internal to file and external)||Yes||No||No
|-
| Move Field||Yes||No||No
|-
| Move Method||Yes||No||No
|-
| Push Down Method||Yes||No||No
|-
| Pull Up Method||Yes||No||No
|-
| Split Local Variable||Yes||No||No
|-
| Override Method||No||No||Yes
|-
| Introduce Variable||No||Yes||Yes
|-
| ||||||
|-
| '''Testing'''||||||
|-
| ||||||
|-
| Test::Unit view||Yes||Yes||Yes
|-
| AutoTest||Yes||Yes||Yes
|-
| RSpec support||Yes||Yes||Yes
|-
| Cucumber||Yes||Yes||Yes
|-
| ||No||No||Yes
|-
| '''Rails Specific Functionality'''||||||
|-
| ||||||
|-
| Integrated rails-specific "shell"||Yes||No||No
|-
| Log Tail View||Yes||No||No
|-
| Embedded browser||Yes||No||No
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|}

== Ease of Use ==

The three IDEs provide a separate set of features and it is up to a programmer to decide what he is really looking for in order to develop his project in the most timely and efficient way possible. From the facilities tabulated above, Aptana Radrails stands out with respect to Netbeans and RubyMine. However, the proponents of the IDEs view their product better in terms of accuracy and speed in certain areas while promising to introduce new features in future. Some of the web links pointing to the ease of use of these IDEs are mentioned below:

# RubyMine Proponent’s View
## [http://www.infoq.com/articles/rubymine-dmitry-jemerov RubyMine View 1]
# NetBeans Proponent’s View
## [http://geekninja.blogspot.com/2008/03/rails-ides-netbeans-vs-apatana-radrails.html NetBeans View 1]
## [http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/ NetBeans View 2]
## [http://railsbalance.blogspot.com/2008/01/tried-very-hard-for-aptanaradrails.html NetBeans View 3]

The views expressed above are independent and in no way can be authenticated. The author of this wiki page has no intention of showing any bias to different IDE user's. The links are only adding to the list of reviews on the IDEs. This may possibly help the future Ruby Programmers in making a fair decision to go in for an IDE that fits their choice.

== System Requirements ==

=== Software Requirements ===

Before installing the IDE’s it is recommended to install the basic dependencies, i.e., Ruby, Ruby Gems and Rails.

=== Hardware Requirements ===

The hardware needs for a particular OS are tabulated below.

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''''
| align="center" style="background:#f0f0f0;"|'''Apatana RadRails'''
| align="center" style="background:#f0f0f0;"|'''NetBeans'''
| align="center" style="background:#f0f0f0;"|'''RubyMine'''
|-
| ||||||
|-
| Version ||Aptana 1.5.1||6.7.1 (support : Ruby 1.8 and Rails 2.1).||Version 1.1.1, Build 975
|-
| ||||||
|-
| '''Microsoft Windows''' ||(no preferences mentioned)||Vista/XP||Vista/2003/XP/2000
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||1 GB of free disk space ||File size : 70.94 MB. No mention about the disk size
|-
| Other||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Mac OS X''' ||(no preferences mentioned)||10.5 Intel/PPC||10.4 (Tiger) or MacOS X 10.5 (Leopard)
|-
| ||||||
|-
| Processor||G5 or Intel-based machine ||Dual-Core Intel/ Power PC G5||1.42 GHz G4, G5 or Intel-based Mac recommended
|-
| Memory||512 MB RAM||2 GB ||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 74.82 MB. No mention about the disk size
|-
| Others||Nil||Nil||Ruby SDK version 1.8.x or higher,1024x768 minimum screen resolution
|-
| ||||||
|-
| '''Linux'''||(no preferences mentioned)||Ubuntu 8.x||GNOME or KDE desktop
|-
| ||||||
|-
| Processor||Pentium 4-level processor ||2.6 GHz Intel Pentium IV or equivalent||Intel Pentium III/800 MHz or higher (or compatible)
|-
| Memory||512 MB RAM||2 GB||256 MB (minmum) and 1 GB (recommended)
|-
| Disk Space||File size : 71.9 MB as Eclipse plug in. No mention about the disk size||850 MB of free disk space ||File size : 52.22 MB. No mention about the disk size
|-
| Others||Nil||Nil||Sun JDK 1.6, Ruby SDK version 1.8.x or higher
|-
|
|}

== Support for the 'Ruby Way of Thinking' ==

The ideology behind the Ruby way of thinking is the Principle of Least Surprise or POLS which says that a program should be intuitive and least astonishing in its behavior or response. As told by Hal Fulton, the author of the “The Ruby Way”, the creators of Ruby want to have it as ‘Human Centric’ as possible. This would help the programmers to achieve their objectives without bothering about the complex idiosyncrasies of the language. This is done by hiding behind the complexity and only showing the relevant syntax needed to produce the desired output.

When it comes to the IDEs, we can apply the POLS on different IDEs design and the various tools/features they offer to assist a programmer in Ruby development. The parameters to evaluate an IDE in conjunction with the Ruby way of thinking could be defined as a function of the features such as run time performance, code debugging, refactoring and other tools that can definitely ease a programmer’s way. Therefore, with the above mentioned facilities the three IDEs certainly support the ruby way of thinking in different styles.

To read more about the Ruby way of thinking, click on the link to an article by Hal Fulton :[http://www.infoq.com/articles/what-is-the-ruby-way The Ruby Way of Thinking]

== References ==

'''Aptana RadRails'''

# http://aptana.com/taxonomy/term/61 - Aptana Ruby Features
# http://www.ibm.com/developerworks/opensource/library/os-ecl-radrails/ - Aptana Quick Start Tutorial
# http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration#Instructions_For_Eclipse_3.2 – Aptana Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Integrating_RadRails_with_Aptana#Aptana_M8a.2FEclipse_3.2.2FRails_plug-in_Instructions – RadRail Plugin for Eclipse
# http://www.aptana.com/docs/index.php/Aptana_System_Requirements - Aptana System Requirements

'''NetBeans'''

# http://www.netbeans.org/features/ruby/index.html - NetBeans Ruby Features
# http://www.netbeans.org/kb/docs/ruby/quickstart.html - NetBeans Quick Start Tutorial
# http://beans.seartipy.com/2008/06/09/setting-up-rails-development-environment-on-windows-vistaxp/ - Setting up Rails Development Environment
# http://wiki.netbeans.org/RubyDocumentation - NetBeans Ruby Documentation
# http://www.netbeans.org/community/releases/67/relnotes.html#system_requirements - NetBeans System Requirements

'''RubyMine'''

# http://www.jetbrains.com/ruby/features/index.html - RubyMine Features
# http://www.jetbrains.com/ruby/documentation/index.html - RubyMine Quick Start Tutorial
# http://www.jetbrains.com/ruby/webhelp/index.jsp - RubyMine Documentation
# http://www.jetbrains.com/ruby/download/index.html - RubyMine System Requirements