User:NcsuOO517: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(47 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Overview ==
== Agile Software Development ==
A Class Responsibility Collaboration (CRC) card session is a useful procedure in designing object-oriented programs.  CRC cards provide a visual layout of how a program can be divided up into classes to optimize efficiency and organization.
Agile is rapidly becoming the most widely used software development methodology in the development world.  It uses a wide variety of practices to achieve a flexible and productive cycle, for the overall goal of delivering a product that meets the customer's requirements.  The underlying question is, is agile the right process for every situation?  Read on to learn the answer.


== History ==
=== Purpose ===
Class Responsibility Collaboration Cards were invented by Kent Beck and Ward Cunningham in 1989 when object-oriented programming was a new concept for most programmers.  They used the cards to teach object-oriented design in a way that procedural programmers could understand.  As object-oriented programming became more popular, the use of CRC cards expanded.  Their ease of use and ability to represent an entire program's functionality and interactions make them helpful for multiple stages of design; consequentially, they are now commonly used as a routine part of the software development process. [3]
The agile software development process is a relatively new process introduced in the 1990s [2].  The main purpose behind agile development is to address the inevitable changes that arise as the development process progresses.  It consists of short iterations of development, encouraging feedback after every iteration so that requirements can be adjusted accordingly.  "Agile is set up to strongly support garnering feedback and guiding the customer toward better understanding what they want and need" [1].  Consequently, the short iterations lead to lower risk and higher productivity in the development cycle [2].


== What does a CRC card look like? ==
=== Common Practices ===
=== Basics ===
Some common practices that are incorporated into the agile development process include, but are not limited to:
A CRC card is an index card that is divided into three sections: Class at the top, Responsibilities on the left and Collaborators on the right.
* '''Extreme Programming (XP)''' - XP includes such practices as iterative development, team continuity, shared code, and real customer involvement. [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf More about XP]
* '''Scrum''' - short, daily meetings held by all members of the team, in which each team member answers three questions:
** What did I do yesterday?
** What do I plan to do today?
** What obstacles are standing in my way? [3]
* '''Retrospectives''' - held at every iteration meeting, this practice involves each team member writing on an index card.  On one side they write what they think went well during the iteration; on the other, they write what they think did not go well.  The cards are then passed around and read by each other member of the team, which leads to a discussion about what was said.
* '''Feature driven development''' - a method of development in which a team plans, designs, and builds by feature, rather than requirement or by the project as a whole. Figure 1 below shows the process of feature driven development. [3]
* '''User stories''' - a story represents a feature that can be completed in one iteration. [3]
* '''Planning Poker''' - a practice held at each iteration meeting.  Each team member holds a set of "poker" cards that have numbers on them, typically 1, 2, 3, 5, 8, 13, 20, 40, and 100.  Team members use the cards to present their estimation of how many [http://agile.csc.ncsu.edu/SEMaterials/EstimatingPlanning.pdf story points] each user story will take to complete - 8 represents a full iteration.  If there is disagreement in estimations, team members discuss why they chose the number they did, and a re-vote is taken.  The process continues until the team members agree on an estimation number. [4]
* '''Team velocities''' - represent the number of story points a team is able to complete in one iteration.  The team velocity is used to decide how many points to assign for the next iteration, based on the "Yesterday's Weather" concept, or the idea that a velocity will remain consistent for each iteration. [4]
* '''[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_S6_km CRC Cards]''' - a method that uses index cards to visualize the design of a system by outlining the classes to be implemented, along with their associated responsibilities and collaborators. [2]


[[Image:s64_CRCbasic.jpg]]
[[Image:FDD.gif|center|Figure 1. Feature Driven Development Life Cycle]]


''Class'' - The name of the object the CRC card represents. The class name should be singular (i.e. Server, not Servers) and simple (Server, not Worker Who Takes Orders). [1]
=== To Agile or not to Agile? ===


''Responsibilities'' - The functions the class should implement. These typically correspond to the methods to be included in the class. One responsibility of a server would be to add an order to a kitchen queue.
Despite its growing popularity in the software industry, a [http://portal.acm.org.www.lib.ncsu.edu:2048/ft_gateway.cfm?id=1869467&type=pdf&CFID=113113249&CFTOKEN=65350389 recent study] indicates that agile may not be right for everyone. When adhering to the strict principles of agile, teams reported the following disadvantages of the agile process:
* Lack of customer involvement - made gathering requirements extremely difficult, leading to loss of productivity and rework.
* Contract negotiation problems - many customers want a "fixed deadline, fixed price, and fixed scope." Agile embraces change, which isn't possible with a fixed price project.
* Conflicts with design-intensive projects - due to this type of projects implementation, which basically starts with a full set of requirements, it was difficult to implement all aspects of agile.
* Superficial documentation - agile doesn't put much emphasis on documentation which is unacceptable for many projects.
* Adaptation to changing requirements not always needed - in which case, most agile methodologies become pointless.
* Difficulty breaking down the project - with complicated development, small user stories aren't always feasible.
* Distributed team discrepancies - some team collaboration tasks require face-to-face interaction which is lost when teams are spread out nationally or globally.


''Collaborators'' - A list of other classes that the current class will interact with. For example, a server only knows information about himself. In order for the server to add an order to the queue, he must retrieve information about the order (such as what dish it is). He must also interact with the queue to know where to put the order. [1]
Obviously the study proved that agile may not be right for everyone. In order to know which software development methodology is best for a team, it is important to look at all the options available and to understand what situations each methodology is best suited for.


=== Variations ===
== Other Software Development Methodologies ==
Just as there are variations in any software development process, some CRC cards have other features implemented.


''Main Responsibility'' - Defines the sole function of a class.  As there should only be one clearly defined main responsibility, this field is often useful in determining if a class should be split up into two or more individual classes.  It is typically featured underneath the Class box.
=== Waterfall ===


''Attributes'' - Any attributes to be associated with the class.  These typically correspond to the instance variables to be included in the class.  If attributes are included, they are featured on the back of the index card.
The Waterfall software development process is a plan driven methodology that must begin with a full, static set of requirements.  The process starts at the top of the "waterfall", as seen in Figure 2, and flows downward through the different phases in a linear fashion, like an actual waterfall [5].


For more information about optional features see [http://agile.csc.ncsu.edu/ShortLectures/CRC%20Cards/CRC%20Cards.html Laurie Williams' presentation] on CRC cards.
[[Image:WaterfallProcess.gif|center|Figure 2. The Waterfall Model]]


== A CRC Card Session ==
==== Waterfall vs. Agile ====


A CRC card session can be held by an individual, but it is more commonly held by a group.  As with many processes, a group is typically better for a CRC exercise since one person may think of something another does not.  Sessions can be held anytime in the development process.  At the beginning it is an excellent brainstorming exercise, but it is also useful for evaluating the design after development has been implemented. [2] Steps:
The waterfall method is effective when the development team is provided with a rigid set of requirements, and wishes to have more control over the project [5,6].  It does not require very much customer interaction as the requirements are already laid out [6].  If a customer insists on setting a timeline and budget, the Waterfall method is useful in ensuring that these restrictions are met [5]. It is generally used for large projects [7].


'''1. Brainstorm the Objects''': The session begins by reading through a scenario or use case for the program and highlighting all the objects, or interactive nouns, mentioned.  Each object is written on its own card as the class name.
The waterfall method is often criticized for leaving no room for change [5].  Defining all the requirements in the beginning without any modifications is not very realistic, nor does it provide any flexibility for the customer.  If problems are found in the end product, the process must start from the beginning again [6].


'''2. Add Responsibilities and Collaborators''': Once the initial objects are created, the action verbs related to an object become its responsibilities.  If a responsibility requires interaction with another object, the object should be listed as a collaborator. 
=== Iterative/Spiral ===


'''3. Divide and Merge Objects''': The scenario should be well thought out to include possible alternatives so that the cards are a good representation of the objects.  As the cards are built, it becomes clear that an additional object may need to be created to lighten the responsibilities of another; likewise, some objects may have only one small responsibility which can be merged with other objects.  The optional Main Responsibility field on the cards also helps with this merging and splitting process.  If the responsibilities cannot be summed up into one main responsibility, the object should probably be divided.
While the spiral and iterative methods are not identical, they have similar characteristics that can be grouped together to compare them to agile.  The iterative method emphasizes feature driven development by employing cycles of development.  It iterates between planning, development, and release (which can be internal).  After each release it is tested, reviewed, and reevaluated, and the cycle begins again.  The iterations leave room for change and improvements. [8]


The steps are repeated until a clean, clear, and concise design is represented on the cards.  For a more detailed breakdown of the CRC session steps, see Alistair Cockburn's memo on [http://alistair.cockburn.us/Using+CRC+cards Using CRC Cards].
[[Image:IterativeProcess.jpg|center|Figure 3. The Iterative Model]]  


The best way to understand the different steps of a CRC Card session is through an example.
The spiral method differs somewhat from the iterative method in that it can accommodate the deployment of multiple task simultaneously and in any order.  It is characterized by a definitive scope and expectations which must be managed accordingly. [9]


== Example ==
[[Image:SpiralProcess.gif|center|Figure 4. The Spiral Model]]


===Use Case: Checkout at a Grocery Store===
==== Iterative/Spiral vs. Agile ====
Agile incorporates iterative development into its process, along with a lot more - so why would someone want to cut out the "more"?  "Iterative projects are best suited for organizations that want incremental delivery but aren't yet willing to move to the more apparently free-form agile methods," writes Matthew Hotle [7].  Hotle points out that not all projects are suitable for agile development.  Iterative development supports a sequenced approach and rapid changes in requirements.  It often requires less time and resources than agile, and typically works for any size project.  With more interaction with the customer and organization of teams and tasks, it is easier to meet deadlines and cost restrictions [10].


'''Main Flow'''
Agile still dominates over iterative and spiral methods when the customer has very unstable requirements.  Its lack of structure and expectations of change provide the best solution in this situation. [7]


A customer brings a collection of products to a register.  The cashier scans the products.  The register displays the total cost, and the customer chooses a method of payment [S-1].  The customer finishes paying and the cashier hands the customer a receipt.
=== Rapid Application Development (RAD) ===


'''Subflows'''
The name speaks for itself - the Rapid Application Development (RAD) process is designed to speed up the development process.  RAD is a prototype-based process that emphasizes team collaboration and user involvement [11].  It is also an iterative process and graphically resembles the iterative model presented in Figure 2.  In order to achieve rapid solutions, RAD tends to skimp on the design phase and documentation [12].


S-1: Method of payment. If the customer chooses to pay with a card, the customer slides the card in the ATM machine and presses the appropriate buttons. If cash, the customer hands some amount of cash to the cashier [S-2].
==== RAD vs. Agile ====
RAD is useful when a customer wants a solution fast, without concern over extensive documentation or sustainable design.  With a team experienced in the RAD process and a controlled scope, a project can be delivered in a cost effective, timely manner [11]. RAD benefits from re-using code, so if a system already has a strong foundation, an extensive design and documentation may not be important [13].


S-2: Amount of cash.  The customer hands too little cash, and the cashier must prompt the customer for more [S-3].  The customer may hand too much, so the cashier returns the appropriate amount of change from the register to the customer.  The customer may also hand over exact change.
RAD is not appropriate for a customer's first client/server project [13].  If a customer places importance on sustainable design or documentation, agile or another method would definitely be the better choice.  Also, an inexperienced team would work much better under a different process.


S-3: Too little cash.  The customer could either hand over more, or may not have enough to pay for the purchase, in which case the cashier must remove one or more items from the order.
=== Rational Unified Process (RUP) ===
The Rational Unified Process (RUP) was designed to encourage both feedback and structure in development.  The process is broken down into four phases: inception, elaboration, construction, and transition.  RUP places high priority on risk management in all phases and on thorough documentation.  While it is considered an iterative process, most of the requirements are expected to be specified towards the beginning of development, giving RUP more of a linear feel. [14]


===CRC Session===
RUP was actually designed to be a process framework - it consists of many different processes that a development team can pick and choose from to implement for their specific project.  Because of this, RUP usually requires someone experienced with the methodology to help in choosing the appropriate techniques.  The different processes and their breakdown between the four phases are shown in Figure 5. [15]


'''1. Brainstorm the Objects'''
[[Image:RUP.jpg|center|Figure 5. The Rational Unified Processes]]


a. First we scan the use case for nouns:
==== RUP vs. Agile ====
For large projects, RUP dominates over agile.  RUP is also the preferred methodology when customers require more structure and adherence to a plan, or when customers have limited time for interaction [15]. However, RUP has failed in many cases because those who attempt to use it don't understand that it is a framework to be customized to fit their project's needs [12]. The process of tailoring RUP to the project can be time consuming and complex, therefore not ideal for projects on a strict timeline or budget [14].


''customer products register cashier cost payment_method card ATM_machine buttons cash change items order transaction receipt''
== Conclusion ==
Hoda's study proved that the full implementation of the agile methodology was not suitable for every project [1].  One conclusion resulting from the study was that "both Scrum and XP suit similar kinds of projects: a small, co-located team; an on-site or available customer representative; an emphasis on coding and testing early; and frequent feedback into updated requirements" [1].  Large projects, or those with limited available interaction within a team or with the customer, can benefit more from adopting other software development methodologies; if desired, a team can then integrate certain agile aspects, such as Scrum or user stories, within their process to form a hybrid that's best suited for their project [1, 5, 16].


b. Next we can eliminate obvious duplicates (this requires some logic!). For example, cash, card, payment_method, and change are all associated with money and can be combined. Here's a sublist of the nouns:
== References ==
 
[1] Hoda, Rashina et al. "[http://portal.acm.org.www.lib.ncsu.edu:2048/ft_gateway.cfm?id=1869467&type=pdf&CFID=113113249&CFTOKEN=65350389 Agility in Context]." ''Proceedings of the ACM international conference on Object oriented programming systems languages and applications.'' OOPSLA Conference 2010: 74-88. ACM DL.
''customer product register cashier money ATM_machine order receipt''
 
c. Finally we make cards for each of these objects.


[[Image:s64_initialCards2.jpg]]
[2] Williams, Laurie. "[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf A Survey of Agile Development Methodologies]." 2007.


'''2. Add Responsibilities and Collaborators'''
[3] Williams, Laurie. "[http://agile.csc.ncsu.edu/SEMaterials/ASDMethods.pdf Agile Software Development Methods and Practices]." 2009.


a. For responsibilities, we look for action verbs: "A customer ''brings'' a collection of products to a register." Again, we need to use some logic; is "to bring" a necessary responsibility for the customer?  This could depend on what the overall goal of the system is, but in this case the main focus is on the checkout process.  Perhaps to modify this statement, we could include a responsibility for the customer to ''add a product'' to the order.
[4] Williams, Laurie. "[http://agile.csc.ncsu.edu/SEMaterials/EstimatingPlanning.pdf Agile Estimating and Planning]." 2007.


[[Image:s64_responsibility.jpg]]
[5] Rising, Jim. "[http://www.managedmayhem.com/2009/05/06/sashimi-waterfall-software-development-process/ Sashimi Waterfall Software Development Process]." ''Managed Mayhem''. 06 May 2009.


b. Next, we must decide if the responsibility requires collaboration with other objects. For the customer to add a ''product'' to the ''order'', it appears the customer must interact with both the product and order objects.
[6] Kaushik, Preetam. "[http://www.brighthub.com/office/project-management/articles/50473.aspx Agile vs. Waterfall - Is There a Real Winner?]" ''Bright Hub''. 27 Sep 2009.


[[Image:s64_collaborators.jpg]]
[7] Hotle, Matthew. "[http://condor.depaul.edu/~dmumaugh/readings/handouts/SE477/Gartner%20Reports/waterfalls_products_and_proj_155147.pdf Waterfalls, Products and Projects: A Primer to Software Development Methods]." ''Gartner''. 26 Feb 2008.


c. We continue this until we have covered all of the flows in the use case. The resulting CRC cards should look something like this:
[8] Smith, S.E. "[http://www.wisegeek.com/what-is-iterative-development.htm What is Iterative Development?]" ''WiseGEEK''. 08 Sep 2010.


[[Image:s64_cards8.jpg]]
[9] Inmon, William H. et al. ''[http://books.google.com/books?id=a-qf-1mthiwC&pg=PA124&lpg=PA124&dq=success+spiral+method&source=bl&ots=tz0Jq_zkJd&sig=SktSZt1rv7BdHAS8suP4uliIDvI&hl=en&ei=q_7XTJ5HgbvyBrD-4cUG&sa=X&oi=book_result&ct=result&resnum=5&sqi=2&ved=0CCUQ6AEwBA#v=onepage&q=success%20spiral%20method&f=false DW 2.0: The Architecture for the Next Generation of Data Warehousing].'' Morgan Kaufmann: 2008.


'''3. Divide and Merge Objects'''
[10] Lucks, Steven. "[http://www.ecademy.com/node.php?id=82687 Agile / Extreme Programming or Spiral method - You Decide?]" ''Ecademy''. 07 Apr 2007.


By examining the generated cards it is clear to see that some need to be eliminated.  Money and receipt have no responsibilities attached to them because they are not interactive nouns, so they can be thrown out. Objects such as Product, ATM Machine, and Order have few responsibilities which all consist of "getter" methods.  On the other hand, Cashier has a seemingly large amount of responsibilities. It is not always obvious what the best course of action would be for these situations. After dividing, removing and merging cards, a final set may look similar to the following:
[11] Shelly, Gary B. and Harry J. Rosenblatt. ''[http://books.google.com/books?id=xZVJKFtYrlsC&pg=PA141&lpg=PA141&dq=success+rapid+application&source=bl&ots=0IjWx3DGrk&sig=OqbGDF35jVoqj7Q-rRfBa4y-wdA&hl=en&ei=PQvYTODvAsWAlAe7ovGBCQ&sa=X&oi=book_result&ct=result&resnum=10&sqi=2&ved=0CEYQ6AEwCQ#v=onepage&q=rad&f=false Systems Analysis and Design]''. Cengage Learning: 2009.
 
[[Image:s64_cards4.jpg]]
 
The CRC cards help to visualize each class, saving time on redesigning the actual program. This example showed that the merge of the product and order classes made sense; without the card session, this may not have been discovered and functionality would be repeated.  Similarly we can see that some responsibilities, such as calculating the total price of the order, could be redistributed to lighten the responsibilities of an overloaded object.  Also, even though some cards like Money and Receipt had no responsibilities, their removal caused the need to rethink the responsibilities of other classes to be sure all were addressed; this is evidenced by the new responsibilities of the Register class card.
 
== References ==


1. Ambler, Scott W. ''Class Responsibility Collaborator (CRC) Models.'' Ambysoft Inc, 2009. [http://www.agilemodeling.com/artifacts/crcModel.htm]
[12] Rooney, Dave. "[http://practicalagility.blogspot.com/2008/11/waterfall-vs-rad-vs-rup-vs-agile-scrum.html Waterfall vs. RAD vs. RUP vs. Agile (Scrum, XP, etc.)]" ''Practical Agility''. 18 Nov 2008.


2. Cockburn, Alistair. ''Using CRC Cards.'' 1999. [http://alistair.cockburn.us/Using+CRC+cards]
[13] Borysowich, Craig. "[http://it.toolbox.com/blogs/enterprise-solutions/rapid-application-development-rad-critical-success-factors-41638 Rapid Application Development (RAD) Critical Success Factors]." ''Observations from a Tech Architect: Enterprise Implementation Issues & Solutions''. 02 Oct 2010.


3. Wilkinson, Nancy M. ''Using CRC Cards: An Informal Approach to Object-Oriented Development.'' Cambridge University Press, 1998.
[14] Collins, Chris. "[http://ccollins.wordpress.com/2008/06/11/unified-process-vs-agile-processes/ Unified Process vs Agile Processes]." 11 Jun 2008.


4. Williams, Laurie. ''CRC Cards.'' 2006. [http://agile.csc.ncsu.edu/ShortLectures/CRC%20Cards/CRC%20Cards.html]
[15] Kousen, Kenneth A. "[http://www.snec-pmi.org/phpbb2/download.php?id=56&sid=2345437a9ca802c72c17d06da35e920f Software Development Process Models: RUP vs. Agile]." ''Kousen IT, Inc.'' 2006.


5. Williams, Laurie. ''Requirements Engineering.'' [http://agile.csc.ncsu.edu/SEMaterials/REUseCases.pdf]
[16] All, Ann. "[http://www.itbusinessedge.com/cm/blogs/all/agile-vs-waterfall-development-how-about-both/?cs=42035 Agile vs. Waterfall Development: How About Both?]" ''Business of Tech''. 01 Jul 2010.

Latest revision as of 18:32, 10 November 2010

Agile Software Development

Agile is rapidly becoming the most widely used software development methodology in the development world. It uses a wide variety of practices to achieve a flexible and productive cycle, for the overall goal of delivering a product that meets the customer's requirements. The underlying question is, is agile the right process for every situation? Read on to learn the answer.

Purpose

The agile software development process is a relatively new process introduced in the 1990s [2]. The main purpose behind agile development is to address the inevitable changes that arise as the development process progresses. It consists of short iterations of development, encouraging feedback after every iteration so that requirements can be adjusted accordingly. "Agile is set up to strongly support garnering feedback and guiding the customer toward better understanding what they want and need" [1]. Consequently, the short iterations lead to lower risk and higher productivity in the development cycle [2].

Common Practices

Some common practices that are incorporated into the agile development process include, but are not limited to:

  • Extreme Programming (XP) - XP includes such practices as iterative development, team continuity, shared code, and real customer involvement. More about XP
  • Scrum - short, daily meetings held by all members of the team, in which each team member answers three questions:
    • What did I do yesterday?
    • What do I plan to do today?
    • What obstacles are standing in my way? [3]
  • Retrospectives - held at every iteration meeting, this practice involves each team member writing on an index card. On one side they write what they think went well during the iteration; on the other, they write what they think did not go well. The cards are then passed around and read by each other member of the team, which leads to a discussion about what was said.
  • Feature driven development - a method of development in which a team plans, designs, and builds by feature, rather than requirement or by the project as a whole. Figure 1 below shows the process of feature driven development. [3]
  • User stories - a story represents a feature that can be completed in one iteration. [3]
  • Planning Poker - a practice held at each iteration meeting. Each team member holds a set of "poker" cards that have numbers on them, typically 1, 2, 3, 5, 8, 13, 20, 40, and 100. Team members use the cards to present their estimation of how many story points each user story will take to complete - 8 represents a full iteration. If there is disagreement in estimations, team members discuss why they chose the number they did, and a re-vote is taken. The process continues until the team members agree on an estimation number. [4]
  • Team velocities - represent the number of story points a team is able to complete in one iteration. The team velocity is used to decide how many points to assign for the next iteration, based on the "Yesterday's Weather" concept, or the idea that a velocity will remain consistent for each iteration. [4]
  • CRC Cards - a method that uses index cards to visualize the design of a system by outlining the classes to be implemented, along with their associated responsibilities and collaborators. [2]
Figure 1. Feature Driven Development Life Cycle
Figure 1. Feature Driven Development Life Cycle

To Agile or not to Agile?

Despite its growing popularity in the software industry, a recent study indicates that agile may not be right for everyone. When adhering to the strict principles of agile, teams reported the following disadvantages of the agile process:

  • Lack of customer involvement - made gathering requirements extremely difficult, leading to loss of productivity and rework.
  • Contract negotiation problems - many customers want a "fixed deadline, fixed price, and fixed scope." Agile embraces change, which isn't possible with a fixed price project.
  • Conflicts with design-intensive projects - due to this type of projects implementation, which basically starts with a full set of requirements, it was difficult to implement all aspects of agile.
  • Superficial documentation - agile doesn't put much emphasis on documentation which is unacceptable for many projects.
  • Adaptation to changing requirements not always needed - in which case, most agile methodologies become pointless.
  • Difficulty breaking down the project - with complicated development, small user stories aren't always feasible.
  • Distributed team discrepancies - some team collaboration tasks require face-to-face interaction which is lost when teams are spread out nationally or globally.

Obviously the study proved that agile may not be right for everyone. In order to know which software development methodology is best for a team, it is important to look at all the options available and to understand what situations each methodology is best suited for.

Other Software Development Methodologies

Waterfall

The Waterfall software development process is a plan driven methodology that must begin with a full, static set of requirements. The process starts at the top of the "waterfall", as seen in Figure 2, and flows downward through the different phases in a linear fashion, like an actual waterfall [5].

Figure 2. The Waterfall Model
Figure 2. The Waterfall Model

Waterfall vs. Agile

The waterfall method is effective when the development team is provided with a rigid set of requirements, and wishes to have more control over the project [5,6]. It does not require very much customer interaction as the requirements are already laid out [6]. If a customer insists on setting a timeline and budget, the Waterfall method is useful in ensuring that these restrictions are met [5]. It is generally used for large projects [7].

The waterfall method is often criticized for leaving no room for change [5]. Defining all the requirements in the beginning without any modifications is not very realistic, nor does it provide any flexibility for the customer. If problems are found in the end product, the process must start from the beginning again [6].

Iterative/Spiral

While the spiral and iterative methods are not identical, they have similar characteristics that can be grouped together to compare them to agile. The iterative method emphasizes feature driven development by employing cycles of development. It iterates between planning, development, and release (which can be internal). After each release it is tested, reviewed, and reevaluated, and the cycle begins again. The iterations leave room for change and improvements. [8]

Figure 3. The Iterative Model
Figure 3. The Iterative Model

The spiral method differs somewhat from the iterative method in that it can accommodate the deployment of multiple task simultaneously and in any order. It is characterized by a definitive scope and expectations which must be managed accordingly. [9]

Figure 4. The Spiral Model
Figure 4. The Spiral Model

Iterative/Spiral vs. Agile

Agile incorporates iterative development into its process, along with a lot more - so why would someone want to cut out the "more"? "Iterative projects are best suited for organizations that want incremental delivery but aren't yet willing to move to the more apparently free-form agile methods," writes Matthew Hotle [7]. Hotle points out that not all projects are suitable for agile development. Iterative development supports a sequenced approach and rapid changes in requirements. It often requires less time and resources than agile, and typically works for any size project. With more interaction with the customer and organization of teams and tasks, it is easier to meet deadlines and cost restrictions [10].

Agile still dominates over iterative and spiral methods when the customer has very unstable requirements. Its lack of structure and expectations of change provide the best solution in this situation. [7]

Rapid Application Development (RAD)

The name speaks for itself - the Rapid Application Development (RAD) process is designed to speed up the development process. RAD is a prototype-based process that emphasizes team collaboration and user involvement [11]. It is also an iterative process and graphically resembles the iterative model presented in Figure 2. In order to achieve rapid solutions, RAD tends to skimp on the design phase and documentation [12].

RAD vs. Agile

RAD is useful when a customer wants a solution fast, without concern over extensive documentation or sustainable design. With a team experienced in the RAD process and a controlled scope, a project can be delivered in a cost effective, timely manner [11]. RAD benefits from re-using code, so if a system already has a strong foundation, an extensive design and documentation may not be important [13].

RAD is not appropriate for a customer's first client/server project [13]. If a customer places importance on sustainable design or documentation, agile or another method would definitely be the better choice. Also, an inexperienced team would work much better under a different process.

Rational Unified Process (RUP)

The Rational Unified Process (RUP) was designed to encourage both feedback and structure in development. The process is broken down into four phases: inception, elaboration, construction, and transition. RUP places high priority on risk management in all phases and on thorough documentation. While it is considered an iterative process, most of the requirements are expected to be specified towards the beginning of development, giving RUP more of a linear feel. [14]

RUP was actually designed to be a process framework - it consists of many different processes that a development team can pick and choose from to implement for their specific project. Because of this, RUP usually requires someone experienced with the methodology to help in choosing the appropriate techniques. The different processes and their breakdown between the four phases are shown in Figure 5. [15]

Figure 5. The Rational Unified Processes
Figure 5. The Rational Unified Processes

RUP vs. Agile

For large projects, RUP dominates over agile. RUP is also the preferred methodology when customers require more structure and adherence to a plan, or when customers have limited time for interaction [15]. However, RUP has failed in many cases because those who attempt to use it don't understand that it is a framework to be customized to fit their project's needs [12]. The process of tailoring RUP to the project can be time consuming and complex, therefore not ideal for projects on a strict timeline or budget [14].

Conclusion

Hoda's study proved that the full implementation of the agile methodology was not suitable for every project [1]. One conclusion resulting from the study was that "both Scrum and XP suit similar kinds of projects: a small, co-located team; an on-site or available customer representative; an emphasis on coding and testing early; and frequent feedback into updated requirements" [1]. Large projects, or those with limited available interaction within a team or with the customer, can benefit more from adopting other software development methodologies; if desired, a team can then integrate certain agile aspects, such as Scrum or user stories, within their process to form a hybrid that's best suited for their project [1, 5, 16].

References

[1] Hoda, Rashina et al. "Agility in Context." Proceedings of the ACM international conference on Object oriented programming systems languages and applications. OOPSLA Conference 2010: 74-88. ACM DL.

[2] Williams, Laurie. "A Survey of Agile Development Methodologies." 2007.

[3] Williams, Laurie. "Agile Software Development Methods and Practices." 2009.

[4] Williams, Laurie. "Agile Estimating and Planning." 2007.

[5] Rising, Jim. "Sashimi Waterfall Software Development Process." Managed Mayhem. 06 May 2009.

[6] Kaushik, Preetam. "Agile vs. Waterfall - Is There a Real Winner?" Bright Hub. 27 Sep 2009.

[7] Hotle, Matthew. "Waterfalls, Products and Projects: A Primer to Software Development Methods." Gartner. 26 Feb 2008.

[8] Smith, S.E. "What is Iterative Development?" WiseGEEK. 08 Sep 2010.

[9] Inmon, William H. et al. DW 2.0: The Architecture for the Next Generation of Data Warehousing. Morgan Kaufmann: 2008.

[10] Lucks, Steven. "Agile / Extreme Programming or Spiral method - You Decide?" Ecademy. 07 Apr 2007.

[11] Shelly, Gary B. and Harry J. Rosenblatt. Systems Analysis and Design. Cengage Learning: 2009.

[12] Rooney, Dave. "Waterfall vs. RAD vs. RUP vs. Agile (Scrum, XP, etc.)" Practical Agility. 18 Nov 2008.

[13] Borysowich, Craig. "Rapid Application Development (RAD) Critical Success Factors." Observations from a Tech Architect: Enterprise Implementation Issues & Solutions. 02 Oct 2010.

[14] Collins, Chris. "Unified Process vs Agile Processes." 11 Jun 2008.

[15] Kousen, Kenneth A. "Software Development Process Models: RUP vs. Agile." Kousen IT, Inc. 2006.

[16] All, Ann. "Agile vs. Waterfall Development: How About Both?" Business of Tech. 01 Jul 2010.

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=User:NcsuOO517&oldid=40237"