CSC/ECE 517 Fall 2011/ch5 6d ny: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(188 intermediate revisions by 2 users not shown)
Line 2: Line 2:




=='''Introduction'''==
=='''Introduction'''<ref>http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf</ref>==


Agile- denoting “the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion ” is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
It is a framework or frame of mind. A practitioner of Agile can use different methodologies within the framework to “do or be” Agile. Agile is our guiding principles that lay the foundation for building better software. In layman language, Agile methodology means cutting down the big picture into puzzle size bits, fitting them together when the time is right e.g. design, coding and testing bits. So, while there are reasons to support both the waterfall and agile methods, reasons such as better adaption of change, launchable product at the end of each cycle, usage of object oriented paradigms, emphasis on user requirements followed by the latter clarifies why many software and web design firms make the more appropriate choice of employing Agile methodology.


===== Definition=====
The term “[http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]” was introduced in 2001 by  [http://agilemanifesto.org/ Agile Software Development Manifesto] published by a group of software practitioners and consultants. The important aspects of this Manifesto are,
*Individuals and interactions over processes and tools.
*Working software over comprehensive documentation.
*Customer collaborations over contract negotiation.
*Responding to change over following plan.


===== Flowchart=====
==== '''Life Cycle'''<ref>http://www.techjini.com/ourapproach-methodologies.html </ref>====
===== Different Methodologies=====


[[File:Agile development flow-chart.jpg|thumb|400px|center|Agile Development Life cycle]]


=='''Different Methodologies'''==
Agile Software development processes are based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.Agile processes use feedback,rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.


====Extreme Programming====
==== '''Process'''====


Agile development involves the following steps:


====Definition====
'''Project Initiation:'''Set up and justify the project. Determine initial high level requirements.


===Origin===
'''Project Plan:'''
Plan out the project, everything after Project Initiation, including whether you're going to have the optional phases.


====FlowChart====
'''Elaborate Requirements (optional):'''
Very high level requirements are gathered during Project Initiation. These can optionally be expanded during an phase to Elaborate Requirements. Even is the requirements are "elaborated" they are still high level.


=====Usage=====
'''Architecture (optional):'''
The Agile approach is generally design for today and refactor tomorrow (at least in XP)..


 Fast – It gives instant feedback on the accuracy of your code.
'''Release:'''A Release is a piece of development where the customer gets some new software. Releases can be from 2 weeks to 6 months, but are usually 3 months long. Release have one or more timeboxes.  


 Design – For testing, the code is designed as small modules facilitating the reusability of the units.
'''Time box:'''A Timebox is 1 – 6 weeks long, but usually 3 – 4 weeks. The most important thing about a timebox is that the delivery date is fixed.


 Individuality – Each unit is designed independent of each other and tested individually making error identification easy.
===== '''Various kinds of agile techniques'''=====


 Efficiency - Bugs can be scanned in the probable bug prone code areas making debugging efficient.
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Extreme_Programming Extreme Programming(XP)]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Scrum Scrum]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Crystal_family_of_Methodologies Crystal family of Methodologies]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Feature_Driven_Development Feature Driven Development]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Rational_Unified_Process Rational Unified Process]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Dynamic_Systems_Development Dynamic Systems Development]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Adaptive_Software_Development Adaptive Software Development]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Open_Source_Software_Development Open Source Software Development]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Agile_Modelling Agile Modelling] 
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Pragmatic_Programming Pragmatic Programming]


 Understanding – Helps any reader, easily understand the methods’ functionality.
=='''Different Methodologies'''<ref>http://www.versionone.com/Agile101/Methodologies.asp </ref>==


=====Limitations of Unit Testing:=====
===Extreme Programming===


 Tedious Job for Complex Codes – Implementing and running test cases for complex codes is time consuming. Moreover, coding a unit test is as tedious as coding the target program itself.
[http://en.wikipedia.org/wiki/Extreme_programming ExtremeProgramming] is one of many AgileProcesses. It is also known as XP. XP is a disciplined approach to delivering high-quality software quickly and continuously.Extreme Programming(XP) has evolved from the problems caused by long development cycles of traditional development models; it appears to be based on trial and error programming!. It is first started as ‘simply an opportunity to get the job done’ with practices that had been found effective in software development process.


 Impact of Change in the Code Requirements - In an agile project that is accompanied with periodic changes in requirements will result in constant updating of test cases to match the latest developments.
[[File:Extreme-Programming-Lifecycle.jpg|thumb|400px|right]]
====Life cycle<ref>http://www.rajeevmisra.com/software/extreme-programming/ </ref>====
The Extreme Programming life cycle consists of the following phases,
*Exploration Phase: In this phase the team performs an architectural spike, during which they experiment with the features to envision the initial architecture.
*Planning Phase: This phase focuses primarily on identifying the most critical user stories and estimating the time required to implement it. A release will have one to many iterations, which are typically 2-to-4 weeks .
* Iteration phase: During this phase; development iteration phase involves iterative testing of the latest versions and eliminating the bugs based on the customer feedback.
*Productionizing Phase: During this phase the code is certified for releases based on the customer approval.


====Values====
Extreme Programming improves a software project in five essential ways;
*Communication: Extreme Programmers constantly communicate with their customers and fellow programmers
*Simplicity: They keep their design simple and clean.Thereby Teams perform the minimum work needed to meet requirements.
*Feedback: They get feedback by testing their software starting on day one.
*Respect: They deliver the system to the customers as early as possible and implement changes as suggested
*Courage: Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology.


=='''Testing Techniques'''==  
====Advantages====
*It is more Customer-focused (it’s all about user stories)
*It ensures Quality via frequent testing
*Constant focus on identifying and delivering the critical user stories
*It results in High visibility on project status
*It provides great support for volatile requirements


====Test-Driven Development(TDD)====  
====Disadvantages====
[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]is an advanced technique of using automated unit tests to drive the design of software. The result of using this practice is a comprehensive suite of unit tests that can be run at any time to keep track of the code development.
Although XP methodology can result in an improved process which is more efficient more predictable more flexible ,it also has weaknesses such as:
*Difficulty coordinating larger teams
*Can result in a never-ending project if not managed properly
*Tendency to not document thoroughly
*Predicting the precise features to be accomplished in a fixed time/budget


Here
===Scrum===
[http://en.wikipedia.org/wiki/Scrum_(development) Scrum Development] is a lightweight management framework with broad applicability for managing and controlling iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade. Over the last couple of years in particular, Scrum has garnered increasing popularity in the software community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.
 Test cases are written initially keeping in mind the final result.
 
 The initial test is conducted which eventually fails because of absence of a target code.
 
 The test suggests further steps to build/refactor an error free code and only those programs associated with the tests go into production.
 
 Tests are then re-conducted until satisfactory results are achieved.
 
[[File:TDD development cycle.png|thumb|400px|center|Development Cycle of TDD]]
 
====Behavior driven development (BDD)====
 
[http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior driven development (BDD)]is a software development technique that relies on the use of simple vocabulary. Tests are designed using natural language so that even a non-technical participant will be able to follow. BDD is an evolution in the thinking behind Test Driven Development but stresses extensively on the behavior aspect of the methods used in the code.
 
 
Eg: Tests result such as “the point cannot be created without code description” is more understandable than something like Test_category_ThrowsArgumentNullException .
 
 
=='''Frameworks'''==
 
A framework is a tool to support writing and running of a program. A Unit Test framework is a set of reusable libraries or classes for a software system. Code is written in these frameworks, they are capable of running and checking the test code by themselves.
 
Here, a unit test framework will evaluate the code based on a variety of inputs provided in the test case and check for the accuracy of results.
 
====Testing Framework Parlance:====
 
a. '''Test Case:'''  It is a main class where test methods are coded. All the units to be tested are inherited to this class.
 
 
b. [http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html '''Assertions (Test::Unit::Assertions):''']  An assertion is the main condition that when held true would result in successful culmination of the test. If the assertion fails then the test would generate an error message with pertinent information so that the programmer can make necessary changes.
 
 
c. '''Test Fixture:'''  A test fixture is used to clean up methods for conducting more than one test, eliminating duplication of methods.
 
 
d. '''Test Method:'''  It is a process to handle individual units referred for testing.
 
 
e. '''Test Runners:'''  Test Runners GUI’s that are used to conduct testing and provide with the results. Test runners such as Test::Unit::UI::Console::Test Runner and GTK test runners are used.
 
 
f. '''Test Suite:'''    It is a collection of tests.
 
 
 
We need a target code to conduct tests.
 
====Example Problem Statement for Target Code:====
To find whether a given point lies on the x-axis, y-axis or the origin.
 
Solution:  We write a class to define the position (x-axis, y-axis or origin) of the point.
 
====Code : Position of a Point====
class Point
attr_writer :xcoordinate
attr_writer :ycoordinate
def initialize(xcoordinate,ycoordinate)
  @xcoordinate = xcoordinate
  @ycoordinate = ycoordinate
end
#-----------Location of point on X-axis ----------------#
def isOnXaxis?
    if @ycoordinate == 0
    return true 
  end
end
#---------- Location of point on Y-axis ----------------#
  def isOnYaxis?
    if @xcoordinate == 0
      return true
  end
  end
#---------- Location of point on Origin-----------------#
  def isOnOrigin?
    if @xcoordinate == 0 && @ycoordinate == 0
    return true
  end
  end
end
 
=='''Testing Frameworks'''==
 
====Test::Unit====
 
=====Overview=====
 
a. It is based on the Test Driven Development Technique (TDD).
 
b. The Test::Unit framework integrates the following features:
1. Way of expressing individual tests.
 
2. Provides a framework for structuring the tests.
 
3. Has flexible ways of invoking the tests.
 
=====Process of Testing=====
 
=====a. Installation=====
 
Test::Unit framework is pre-installed on all Ruby versions.
 
=====b. Algorithm=====
 
 We use a UI is used to run the Test code and display the gathered results. Here, we have used the web based UI.
 
 Structuring the tests: Inherit the required classes.
 
a. Here, “point” class is inherited to call the target units which have to be tested.
 
b. The “test/unit” class is inherited for methods required to conduct testing.
 
 Write the test methods.
 
 Test methods are prefixed with test. Eg: test_examp where examp is the unit being tested.
 
 In the methods write Assertions comparing them with expected results for the target units.
 
 Text fixtures are optional; they can be used to clean the methods.
 
 Run the tests as Test::Unit test class name.rb
 
 To run only a particular method we can its name as classname.rb --name method
 
 If there are bugs, refactor the code.


 Repeat testing until all the bugs are fixed.
==== Life Cycle <ref>http://planmanup.blogspot.com/2010/08/software-development-methodology.html</ref>====
[[File:Agile Scrum Life Cycle.png|thumb|400px|right|Agile Scrum Life Cycle]]


=====Flowchart=====
====Characteristics:====
[[File:Test unit flowchart.png|thumb|400px|center|Development Cycle of TDD]]


=====CODE Test::Unit=====
Scrum is a process skeleton that contains sets of practices and predefined roles. The main roles in Scrum are:
require "Point"
require "test/unit"
class TestCase_Point < Test::Unit::TestCase
  def test_isOnXaxis
    assert(Point.new(3,0).isOnXaxis?)
    end
  def test_isOnYaxis
      assert(Point.new(0,4).isOnYaxis?)
  end
  def test_isOnOrigin
      assert(Point.new(3,4).isOnOrigin?)
  end
end


=====Result Test::Unit=====
1.the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager.
Below are the test results that are obtained after running the above test cases.


=====Failed output=====
2.the “Product Owner”, who represents the stakeholders and the business.
This is how the failed test cases are shown once we run the test cases,
[[File:Testunit failed.png|center|700px|center|Development Cycle of TTD]]


=====Passed output=====
3.the “Team”, a cross-functional group who do the actual analysis, design, implementation, testing, etc.
[[File:Testunit passed.png|center|800px|center|Development Cycle of TTD]]


=====Storing Test Files=====
====Advantages====
Test files can be stored in the same directory as the target file but eventually the directory gets bloated storing 2 files for the same target code. Instead we can store it in a separate test directory for better organization. Here, one must take care to clearly specify the path of the target code for inheritance purpose in the test file.
*It helps in saving time and money.
*Fast moving, cutting edge developments can be quickly coded and tested as the bugs can be easily fixed.
*Short sprints and constant feedbacks results in easier way to cope with the changes.
*Daily meeting helps in evaluating individual productivity. Thereby enhances the productivity of each of the team members.
*It is easier to deliver a quality product in a scheduled time.
====Disadvantages====


Eg: If point.rb is stored in the directory lib and test_point.rb is stored in the test directory then to inherit point.rb we specify the path.  
*Decision-making is entirely in the hands of the teams. And if the team members are not committed, the project will either never complete or fail.
require “../lib/point”
*It is good for small, fast moving projects as it works well only with small team.
----
*Absence of any of the team member during development can have huge inverse effect on the project development.


===Crystal family of Methodologies<ref>http://altnetpedia.com/Crystal.ashx </ref>===


====Shoulda====
Crystal methods are considered and described as “lightweight methodologies”. The Crystal family of methodologies views software development as a "cooperative game of invention and communication, with a primary goal of delivering working useful software and a secondary goal of setting up the next game". Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions. [http://alistair.cockburn.us/ Alistair Cockburn], the originator of Crystal, has released a book, “Crystal Clear: A Human-Powered Methodology for Small Teams”.
=====Crystal Family=====
Crystal is actually comprised of a family of methodologies,whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. And they are,
*Crystal Clear
*Crystal Yellow
*Crystal Orange
*Crystal Orange Web
*Crystal Red
*Crystal Maroon
*Crystal Diamond
*Crystal Sapphire


=====Overview=====
Crystal Clear is the lightest methodology in the family, suitable for co-located teams of up to 10 people. It is a lower-discipline methodology than XP (1st edition) but also requires some documentation.This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique


a. Shoulda is a library that allows us to write better and easily understandable test cases for the ruby applications compared to Test::Unit.
====Characteristics====
Crystal has seven core properties:  
*Frequent Delivery
*Reflective Improvement
*Osmotic Communication
*Personal Safety
*Focus
*Expert Users
*Automated Tests
*Configuration Management
*Frequent Integration.


b. It allows us to use the "it"-blocks from RSpec to define nice error-messages if a test fails.
===Feature Driven Development<ref>http://questpond.blog.com/2010/11/16/agile-development-part-2-2/ </ref>===


c. In other words it is improvised form of Test::Unit and Rspec. It works inside the Test::Unit — you can even mix Shoulda tests with regular Test::Unit test methods.
[http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development] is a model-driven, short-iteration process .  It is one of a number of Agile methodsfor developing software and forms part of the [http://en.wikipedia.org/wiki/Agile_Alliance Agile Alliance]. FDD was originally developed and articulated by [http://en.wikipedia.org/wiki/Jeff_De_Luca Jeff De Luca], with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occured as a result of collaboration between De Luca and OOD thought leader Peter Coad. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using its best eight practices.
[[File:FDD LifeCycle.jpg|thumb|400px|right|FDD Life cycle]]


=====Process of Testing=====
====Life cycle====
A typical life cycle of a Feature Driven Development can be represented as in the diagram.


====Characteristics====
The eight bets practices of FDD are as follows,


=====a. Installation=====
*Domain Object Modeling
*Developing by Feature
*Component/Class Ownership
*Feature Teams
*Inspections
*Configuration Management
*Regular Builds
*Visibility of progress and results


Shoulda is installed by running “gem install shoulda” in command prompt after setting the environment path as “…\Ruby\bin”
FDD recommends specific programmer practices such as "Regular Builds" and "Component/Class Ownership". FDD's proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other agile approaches, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These inc


=====b. Algorithm=====
====Advantages====
*As FDD involves in development of an already thought of an product , rather than examining the market and seeing what the consumer could benefit from.
*By using FDD the business sticks solely to what they are good at; they develop goods that fall under an area that they have both experience and knowledge in, creating something that should be, by all accounts, one of the best in its field.
*The smaller companies benefit a lot by employing this methodology as they dont have to spend money of technical manpower.


 Inherit all the classes involved in testing i.e. the target class and the shoulda library class. To achieve this add require "rubygems", require ”Point” and require "shoulda" to the test class.
====Disadvanatages====
*There may be no demand for your product, hence the business will struggle to make money.
*It requires a lot of background research on market product before developing.


 Then setup up a context “Point” (context is nothing but a region of code which deals with the functionality you are interested in.)
===Adaptive Software Development<ref>http://www.adaptivesd.com/articles/messy.htm </ref>===


 Then define a method starting with should “method name” do and then describe the entire method.
[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development] is a software development process that grew out of rapid application development work by [http://en.wikipedia.org/wiki/Jim_Highsmith Jim Highsmith] and Sam Bayer.ASD focuses mainly on the problems in developing complex,large systems. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
ASD eveolved as the software developer started to revise their management practices. ASD replaces the  traditional [http://en.wikipedia.org/wiki/Waterfall_model waterfall cycle] with a repeating series of speculate, collaborate, and learn cycles.


 Make proper assertions to test the functionality in your method.
====Life Cycle====
*Speculate:
[[File:ASD lifecycle.png|thumb|400px|right|]]
In complex environments, planning is a paradox.  "Planning," whether it is applied to overall product specifications or detail project management tasks, is too deterministic a word. It carries too much historical baggage. "Speculate" is offered as a replacement. When we speculate, it's not that we don't define a mission to the best of our ability.  So let's be honest, postulate a general idea of where we are going, and put mechanisms in place to adapt
*Collaborate:


=====Code shoulda=====
Managing in a complex environment is scary as hell -- it is also a blast. If we can't predict (plan), then we can't control in the traditional management sense. If we can't control, then a significant set of current management practices is no longer operable, or more specifically, only operable for those parts of the development process that are predictable. Collaboration, in this context, portrays a balance between managing the doing (the main thrust of traditional management) and creating and maintaining the collaborative environment needed for emergence. As projects become increasingly complex, the balance swings much more toward the latter.
require "rubygems"
*Learn:
require “Point”
require "test/unit"
require "shoulda"
class TestCase_Point_Shoulda < Test::Unit::TestCase
  context "Point" do
  should "lie on the X-axis " do
      assert(Point.new(3,0).isOnXaxis?)
  end
  should "lie on the Y-axis " do
      assert(Point.new(0,4).isOnYaxis?)
  end
  should "lie on the Origin" do
    assert(Point.new(0,4).isOnOrigin?)
  end
  end
end


=====Result=====
Collaborative activities build products. Learning activities expose those products to a variety of stakeholders to ascertain value. Customer focus groups, technical reviews, beta testing, and postmortems are all practices that expose results to scrutiny.
Below are the test results that are obtained after running the above test cases,


=====Failed Output=====
===Dynamic Systems Development===
[[File:Shoulda failed.png|center|800px|center|Development Cycle of TTD]]


=====Passed output=====
[http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Model], dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as [http://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the [http://www.dsdm.org/ DSDM Consortium] was created and convened in 1994 with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling Agile and iterative software development projects.
[[File:Shoulda passed.png|center|600px|center|Development Cycle of TTD]]
----


[[File:DSDM Project Phases.png|thumb|400px|right|DSDM Life cycle]]
====Life Cycle====
The diagram depicts the life cycle of the DSDM Methodology as shown.


====RSpec====
====Characteristics====


=====Overview=====
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.
a. RSpec is Behavior Driven Development Unit test tool for ruby.
Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using '''MoSCoW''' Rules:


b. It allows us to write an initial code specifications (spec) document. The spec document talks about the program’s function.
'''M''' – Must have requirements


c. Thereby, we can write the code based on the specifications (spec file).
'''S''' – Should have if at all possible


d. The (spec) document is written in Domain Specific Language which makes it simple for the programmer to handle.
'''C''' – Could have but not critical


e. Better understanding of the test cases compared to shoulda as the cases and notifications are more descriptive.
'''W''' - Won’t have this time, but potentially later


f. In other words it is improvised form of Test::Unit and Rspec. It works inside the Test::Unit — you can even mix Shoulda tests with regular Test::Unit test methods.
All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Extreme_Programming Extreme Programming] and the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Rational_Unified_Process Rational Unified Process].


=====Process of Testing=====
===Other Methodologies===
====Rational Unified Process====
[http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process Rational Unified Process]was developed by [http://en.wikipedia.org/wiki/Philippe_Kruchten Philippe Kruchten],[http://en.wikipedia.org/wiki/Ivar_Jacobson Ivar Jacobsen] and others at [http://en.wikipedia.org/wiki/Rational_Software Rational Corporation] to complement [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML(Unified Modelling language)],an industry-standard software modeling method.


=====a. Installation=====
RUP is an iterative approach for object-orieneted systems, and it strongly embraces use cases for modeling requirements and building the foundation for a system.RUP is inclined towards object-oriented development.
RSpec is installed by running “gem install rspec” in command prompt after setti ng the environment path as “…\Ruby\bin”
The lifespan of a RUP project is divided into four phases named Inception,Elaboration,Construction and Transition.These phases are split into iterations,each having a purpose of producing a demonstrable piece of software.The duration of an iteration may vary from two weeks or less up to six months.


=====b. Algorithm=====
====Open Source Software Development====


 We start by describing what our application behaves like. So we write down a specifications file.
[http://en.wikipedia.org/wiki/Open_source_software_development Open source software development] is the process by which [http://en.wikipedia.org/wiki/Open_source open source] software (or similar software whose [http://en.wikipedia.org/wiki/Source_code source code] is publicly available) is developed. These are software products “available with its [source code and under an [http://en.wikipedia.org/wiki/Open_source_license open source license] to study, change, and improve its design”. Examples of popular open source software products are Mozilla Firefox, Google Chrome etc..


 Using RSpec's “describe” block we describe the basic functions of the application.  
OSS in many ways follows the same lines of thought and practices as other agile methods. For example, the OSS development process starts with early and frequent releases, and it lacks many of the traditional mechanisms used for coordinating software development with plans, system level designs and defined process.  


 We then write the behaviors/expectations defining what we expect our system to behave like (expectations are similar to assertions in Test::Unit framework).
Typically, an OSS project consists of the following visible phases:


 There are two methods available for checking expectations: should() and should_not(). Spec::Expectations - Object#should(matcher) and Object#should_not(matcher).
*Problem discovery
*Finding volunteers
*Solution identification
* Code development and testing
*Code change review
*Code commit and documentation
*Release management


 The code returns list of all the methods to be implemented.
====Agile Modelling ====


 Main code implementing all the specified methods is written.
[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modeling] is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for Modeling software that can be applied on a software development project in a more flexible manner than traditional Modeling methods.
Agile Modeling is a supplement to other Agile methodologies such as:


 Then, a recheck is done for fulfillment of all the expectations.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Extreme_Programming Extreme Programming]


=====Code RSpec=====
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Rational_Unified_Process Rational Unified Process]


======Initial Requirement(spec)======
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch5_6d_ny#Scrum Scrum]


In the below code describe() method returns an ExampleGroup class(similar to TestCase in Test::Unit).
=='''Comparision'''==
The it()method returns an instance of the ExampleGroup in which that example is run.


require "Point"
[[File:Comparision.png|thumb|900px|center|]]
describe "The location of a point" do
  it "should check whether point lies on X-axis correctly"                       
  it " should check whether point lies on Y-axis correctly "
  it " should check whether point lies on Origin correctly "
end


The are two methods available to check the expectations and they are should and should_not.
=='''How widely these methodologies are used'''<ref>http://www.forrester.com/imagesV2/uplmisc/NN_AppDev2.pdf </ref>==
The result obtained by running the initial requirement doc by using $ spec rspec_test.rb is
[[File:Figure 1.png|thumb|300px|right|]]
Agile project management has entered the mainstream – incremental delivery is now common and (should be) expected for any new software development project. But,it still is in its naive stages in terms of the acceptance of the evolution in ideology that it demands.
****
Pending:
The location of a point should check whether point lies on X-axis correctly (Not Yet Implemented)
./02file.rb:2
The location of a point should check whether point lies on Y-axis correctly (Not Yet Implemented)
./02file.rb:3
The location of a point should check whether point lies on Origin correctly (Not Yet Implemented)
./02file.rb:5
Finished in 0.021001 seconds
4 examples, 0 failures, 4 pending
   
   
Hence it clearly says that the above methods are yet to be implemented. This helps us in developing the code more efficiently such that they pass the above tests
For small scale projects, averages of 58% of agile techniques are used when developing software. So for example if the respondent was using XP on a small scale project, 7 out of 12 XP techniques would be followed while the other 5 would either be changed or ignored to fit the project constraints and needs.
Code block with expectations :
Fewer respondents are following  agile techniques for medium and large scale  projects, as trends show that weighted  average of 34% and 22% respectively of the techniques were implemented in the projects.  
As the development of software increases, there is a corresponding decrease in the number of agile techniques used.  Furthermore, respondents tend to use heavyweight methods when the increase of project size, complexity, team, architecture, scope, and risks occur. 


require “Point”
Forrester’s Business Technographics® September 2006 North American And European Enterprise Software Survey indicates that 17% of North American and European enterprises currently use Agile processes and that another 29% are aware of them.Forrester believes that Agile adoption is actually higher than reported in this study. Based on the interactions with enterprise IT organizations, Forrester estimates that very few large enterprises use Agile for most of their projects.  
require "rubygems"
describe "The location of a point" do
  before(:each) do
    @point = Point.new(0,2)
  end
  it "should check whether point lies on X-axis correctly" do
    @point.isOnXaxis?.should be_true
  end
  it "should check whether point lies on Y-axis correctly" do
    @point.isOnYaxis?.should be_true
  end
  it "should check whether point lies Origin correctly" do
    @point.isOnOrigin?.should be_true
  end
end


=====Failed output=====
A recent survey conducted by Dr. Dobb’s Journal shows 41 percent of development projects have now adopted agile methodology, and agile techniques are being used on 65 percent of such projects.This is shown in the diagram.
Below are the test results that are obtained after running the above test cases,
[[File:Rspec failed.png|center|600px|center|Development Cycle of TTD]]
----


In retrospect,when is agile method not adopted? It primarily comes down to the people. If the people involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. Thus, agile cannot be imposed onto people.


====Cucumber====
=='''Evidence to support the effectiveness of Agile Development'''<ref>http://www.agilemodeling.com/essays/proof.htm </ref>==
Adopting and then tailoring a software process to meet your team’s needs is an important and difficult decision, one that is critical to your project’s success.  There are a myriad of choices. So it is important to  determine whether an agile development methodology works effectively within your environment.
There is growing survey evidence that agile works better than traditional.One of them is summarized in Figure 2.


Cucumber is becoming highly popular because of its easy coding features.
[[File:Figure 2.jpg|thumb|400px|center|]]


=====Overview=====


a. Cucumber is a Behavior Driven Development Unit test tool for ruby.
Above is the DDJ 2007 Project Success Survey that showed that when people define success in their own terms, Agile projects had a 72% success rate, compared with 63% for traditional and 43% for offshoring.  


b. It follows a similar pattern of RSPEC with some added features.
[[File:Figure 3.jpg|thumb|300px|right|]]
Craig Larman,in his book Agile and Iterative Development: A Manager's Guide makes a very good argument that proof exists that shows that many of the common practices within agile software development do in fact work, practices such as incremental delivery and iterative approaches which embrace change.  He also cites evidence which shows that serial approaches to development, larger projects, and longer release cycles lead to greater incidences project failure.  


c. It allows the behavior of a system to be written in the native language of the programmer as either specs or functional tests.
Effectiveness of agile methodology can be proved with feedback cycle which indicated the time in which response is obtained. Agile techniques are found to have very short feedback cycles, often on the order of minutes or hours whereas traditional techniques, such as reviews, inspections, and big requirements up front (BRUF) have feedback cycles on the order of weeks or months, making them riskier and on average more expensive.


d. It implements the GWT (Given, When, Then) pattern. Given is a behavior, accordingly coding is done. When all the specifications are met, then the tests are deemed successful.  
From the surveys and the present organizational scenario, people's experience with agile software development can be observed to be very positive, and that adopting agile strategies appears to be very low-risk in practice.


e. Cucumber itself is written in Ruby.
=='''Conclusion'''==
 
To conclude, agile software development stresses rapid iterations, small and frequent releases, and evolving requirements facilitated by direct user involvement in the development process.  
=====Process of Testing=====
This development isn’t managerial free-for-all. It requires discipline and adherence to processes, even when those processes are not burdensome.
 
When it comes to methodologies, each project is differentand and there is no '''one-size-fits-all''' solution.
=====a. Installation=====
Agile development is being adopted in the enterprise world widely and it is not long before agile would be part of the thinking process rather than a strategy.
If your Environment path is set to " ...\Ruby\bin" then open command prompt and run gem install cucumber.
 
=====b. Algorithm=====
 We first create a feature file to describe about our requirements.
 
 Then we will create a ruby file to give a code to implement the function.
 
 Then, a recheck is done for fulfillment of all the expectations.
 
=====Code Cucumber=====
 
The requirement(spec) file for the cucumber is given below,
Feature: Check the point location
  In order perform check
  As a user
  I want the two coordinates of a point
  Scenario: check the location on X-axis
  Given I have entered <xcoordinate>
  And  I have entered <ycoordinate>
  When I give check
  Then  The result should be <output>
 
The code implementation based on the above Requirement for Cucumber is as shown below,
require “Point”
require "rubygems"
Before do
@xcoordinate=3
@ycoordinate=0
end
Given /^I have entered <input(\d+)>$/ do |arg1|
  @point = Point.new(@xcoordinate,@ycoordinate)
end
When /^I give check$/ do
  @result = @point.isOnXaxis?
end
Then /^The result should be <output>$/ do
puts @result
end
----
 
====RIOT====
 
RIOT aids in speedy execution of test cases.
 
=====Overview=====
 
a. Riot does not run a setup and teardown functions before and after each test like in case of Test::Unit.
 
b. This is what speeds up the test execution.
 
c. Tests are written differently in RIOT. We only receive a Boolean output for our test case.
 
c. Here, assertions are done using a generalized attribute instead of specific variables.
 
=====Process of Testing=====
 
=====a. Installation=====
 
This can be installed by running “gem install riot” in command prompt after setting the environment path as “…\Ruby\bin”
 
=====b. Algorithm=====


 We inherit all the classes that are required.
=='''See also'''==
*[http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]


 A “Context” block is used to specify behavior of the class.
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall cycle]


 Now, a setup block does not use specific variables but instead uses a generalized attribute “topic” to access objects in assertions.
*[http://agilemanifesto.org/ Agile Software Development Manifesto]


 Assertions only return a boolean value. When using asserts, true indicates a pass while false indicates a fail.
*[http://en.wikipedia.org/wiki/Extreme_programming ExtremeProgramming]


=====Code RIOT=====
*[http://en.wikipedia.org/wiki/Scrum_(development) Scrum Development]
require “Point”
require "rubygems"
context "The point locater" do
  setup{Point.new(3,0)}
  asserts("Location on Xaxis") {topic.isOnXaxis?}.nil
end
----


*[http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development]


=='''Comparision between Frameworks'''==
*[http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]
[[File:Comparision.jpg]]
 
 
=='''Conclusion'''==
Test::unit is the traditionally used unit testing framework as it comes by default with ruby but based on the readability of the test cases Rspec is preferred by majority.
Below is the plot showing the comparison of the times taken to execute the test cases in various unit test frameworks,
 
[[File:Conclusion.png|center|600px|center|Development Cycle of TTD]]


Hence we can infer from the above tabulation that riot is faster compared to majority of the unit test Frameworks
*[http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Model]


Each of the frameworks have their specific advantages and are used depending upon the situation.
*[http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process Rational Unified Process]


==See also==
*[http://en.wikipedia.org/wiki/Open_source_software_development Open source software development]
*[http://www.ultrasaurus.com/sarahblog/2009/08/ruby-unit-test-frameworks/ Unit Testing Frameworks for Ruby]
*[http://stackoverflow.com/questions/1479361/what-is-the-community-preferred-ruby-unit-testing-framework Community Preferred Unit Testing Framework]


==External Links:==
*[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modeling]
*[http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit]
*[http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/ Ruby-doc]
*[http://rdoc.info/github/thoughtbot/shoulda/master/file/README.rdoc Shoulda]
*[http://rspec.info/ RSpec]
*[http://rspec.info/documentation/ RSpec Documentation]
*[https://github.com/thoughtbot/shoulda Shoulda]
*[http://cukes.info/ Cucumber]
*[http://en.wikipedia.org/wiki/Unit_testing Unit testing]
*[http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]
*[http://alexyoung.org/2009/10/26/riot-testing/ Riot]


==References:==
==External Links==
[http://www.mobilein.com/WhitePaperonUnitTesting.pdf R.Venkat Rajendran, White Paper on Unit Testing]
*[http://www.extremeprogramming.org/ Extreme Programming]


[http://ironshay.com/post/A-Mini-Review-Benchmark-of-Rubye28099s-Different-Testing-Frameworks.aspx Benchmark Conclusions]
=='''References'''==
<references/>

Latest revision as of 22:00, 20 November 2011

Agile Landscape


Introduction<ref>http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf</ref>

Agile- denoting “the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion ” is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It is a framework or frame of mind. A practitioner of Agile can use different methodologies within the framework to “do or be” Agile. Agile is our guiding principles that lay the foundation for building better software. In layman language, Agile methodology means cutting down the big picture into puzzle size bits, fitting them together when the time is right e.g. design, coding and testing bits. So, while there are reasons to support both the waterfall and agile methods, reasons such as better adaption of change, launchable product at the end of each cycle, usage of object oriented paradigms, emphasis on user requirements followed by the latter clarifies why many software and web design firms make the more appropriate choice of employing Agile methodology.

The term “Agile Software Development” was introduced in 2001 by Agile Software Development Manifesto published by a group of software practitioners and consultants. The important aspects of this Manifesto are,

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaborations over contract negotiation.
  • Responding to change over following plan.

Life Cycle<ref>http://www.techjini.com/ourapproach-methodologies.html </ref>

Agile Development Life cycle

Agile Software development processes are based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.Agile processes use feedback,rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

Process

Agile development involves the following steps:

Project Initiation:Set up and justify the project. Determine initial high level requirements.

Project Plan: Plan out the project, everything after Project Initiation, including whether you're going to have the optional phases.

Elaborate Requirements (optional): Very high level requirements are gathered during Project Initiation. These can optionally be expanded during an phase to Elaborate Requirements. Even is the requirements are "elaborated" they are still high level.

Architecture (optional): The Agile approach is generally design for today and refactor tomorrow (at least in XP)..

Release:A Release is a piece of development where the customer gets some new software. Releases can be from 2 weeks to 6 months, but are usually 3 months long. Release have one or more timeboxes.

Time box:A Timebox is 1 – 6 weeks long, but usually 3 – 4 weeks. The most important thing about a timebox is that the delivery date is fixed.

Various kinds of agile techniques

Different Methodologies<ref>http://www.versionone.com/Agile101/Methodologies.asp </ref>

Extreme Programming

ExtremeProgramming is one of many AgileProcesses. It is also known as XP. XP is a disciplined approach to delivering high-quality software quickly and continuously.Extreme Programming(XP) has evolved from the problems caused by long development cycles of traditional development models; it appears to be based on trial and error programming!. It is first started as ‘simply an opportunity to get the job done’ with practices that had been found effective in software development process.

Life cycle<ref>http://www.rajeevmisra.com/software/extreme-programming/ </ref>

The Extreme Programming life cycle consists of the following phases,

  • Exploration Phase: In this phase the team performs an architectural spike, during which they experiment with the features to envision the initial architecture.
  • Planning Phase: This phase focuses primarily on identifying the most critical user stories and estimating the time required to implement it. A release will have one to many iterations, which are typically 2-to-4 weeks .
  • Iteration phase: During this phase; development iteration phase involves iterative testing of the latest versions and eliminating the bugs based on the customer feedback.
  • Productionizing Phase: During this phase the code is certified for releases based on the customer approval.

Values

Extreme Programming improves a software project in five essential ways;

  • Communication: Extreme Programmers constantly communicate with their customers and fellow programmers
  • Simplicity: They keep their design simple and clean.Thereby Teams perform the minimum work needed to meet requirements.
  • Feedback: They get feedback by testing their software starting on day one.
  • Respect: They deliver the system to the customers as early as possible and implement changes as suggested
  • Courage: Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology.

Advantages

  • It is more Customer-focused (it’s all about user stories)
  • It ensures Quality via frequent testing
  • Constant focus on identifying and delivering the critical user stories
  • It results in High visibility on project status
  • It provides great support for volatile requirements

Disadvantages

Although XP methodology can result in an improved process which is more efficient more predictable more flexible ,it also has weaknesses such as:

  • Difficulty coordinating larger teams
  • Can result in a never-ending project if not managed properly
  • Tendency to not document thoroughly
  • Predicting the precise features to be accomplished in a fixed time/budget

Scrum

Scrum Development is a lightweight management framework with broad applicability for managing and controlling iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade. Over the last couple of years in particular, Scrum has garnered increasing popularity in the software community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.

Life Cycle <ref>http://planmanup.blogspot.com/2010/08/software-development-methodology.html</ref>

Agile Scrum Life Cycle

Characteristics:

Scrum is a process skeleton that contains sets of practices and predefined roles. The main roles in Scrum are:

1.the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager.

2.the “Product Owner”, who represents the stakeholders and the business.

3.the “Team”, a cross-functional group who do the actual analysis, design, implementation, testing, etc.

Advantages

  • It helps in saving time and money.
  • Fast moving, cutting edge developments can be quickly coded and tested as the bugs can be easily fixed.
  • Short sprints and constant feedbacks results in easier way to cope with the changes.
  • Daily meeting helps in evaluating individual productivity. Thereby enhances the productivity of each of the team members.
  • It is easier to deliver a quality product in a scheduled time.

Disadvantages

  • Decision-making is entirely in the hands of the teams. And if the team members are not committed, the project will either never complete or fail.
  • It is good for small, fast moving projects as it works well only with small team.
  • Absence of any of the team member during development can have huge inverse effect on the project development.

Crystal family of Methodologies<ref>http://altnetpedia.com/Crystal.ashx </ref>

Crystal methods are considered and described as “lightweight methodologies”. The Crystal family of methodologies views software development as a "cooperative game of invention and communication, with a primary goal of delivering working useful software and a secondary goal of setting up the next game". Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions. Alistair Cockburn, the originator of Crystal, has released a book, “Crystal Clear: A Human-Powered Methodology for Small Teams”.

Crystal Family

Crystal is actually comprised of a family of methodologies,whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. And they are,

  • Crystal Clear
  • Crystal Yellow
  • Crystal Orange
  • Crystal Orange Web
  • Crystal Red
  • Crystal Maroon
  • Crystal Diamond
  • Crystal Sapphire

Crystal Clear is the lightest methodology in the family, suitable for co-located teams of up to 10 people. It is a lower-discipline methodology than XP (1st edition) but also requires some documentation.This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique

Characteristics

Crystal has seven core properties:

  • Frequent Delivery
  • Reflective Improvement
  • Osmotic Communication
  • Personal Safety
  • Focus
  • Expert Users
  • Automated Tests
  • Configuration Management
  • Frequent Integration.

Feature Driven Development<ref>http://questpond.blog.com/2010/11/16/agile-development-part-2-2/ </ref>

Feature Driven Development is a model-driven, short-iteration process . It is one of a number of Agile methodsfor developing software and forms part of the Agile Alliance. FDD was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occured as a result of collaboration between De Luca and OOD thought leader Peter Coad. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using its best eight practices.

FDD Life cycle

Life cycle

A typical life cycle of a Feature Driven Development can be represented as in the diagram.

Characteristics

The eight bets practices of FDD are as follows,

  • Domain Object Modeling
  • Developing by Feature
  • Component/Class Ownership
  • Feature Teams
  • Inspections
  • Configuration Management
  • Regular Builds
  • Visibility of progress and results

FDD recommends specific programmer practices such as "Regular Builds" and "Component/Class Ownership". FDD's proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other agile approaches, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These inc

Advantages

  • As FDD involves in development of an already thought of an product , rather than examining the market and seeing what the consumer could benefit from.
  • By using FDD the business sticks solely to what they are good at; they develop goods that fall under an area that they have both experience and knowledge in, creating something that should be, by all accounts, one of the best in its field.
  • The smaller companies benefit a lot by employing this methodology as they dont have to spend money of technical manpower.

Disadvanatages

  • There may be no demand for your product, hence the business will struggle to make money.
  • It requires a lot of background research on market product before developing.

Adaptive Software Development<ref>http://www.adaptivesd.com/articles/messy.htm </ref>

Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer.ASD focuses mainly on the problems in developing complex,large systems. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. ASD eveolved as the software developer started to revise their management practices. ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles.

Life Cycle

  • Speculate:

In complex environments, planning is a paradox. "Planning," whether it is applied to overall product specifications or detail project management tasks, is too deterministic a word. It carries too much historical baggage. "Speculate" is offered as a replacement. When we speculate, it's not that we don't define a mission to the best of our ability. So let's be honest, postulate a general idea of where we are going, and put mechanisms in place to adapt

  • Collaborate:

Managing in a complex environment is scary as hell -- it is also a blast. If we can't predict (plan), then we can't control in the traditional management sense. If we can't control, then a significant set of current management practices is no longer operable, or more specifically, only operable for those parts of the development process that are predictable. Collaboration, in this context, portrays a balance between managing the doing (the main thrust of traditional management) and creating and maintaining the collaborative environment needed for emergence. As projects become increasingly complex, the balance swings much more toward the latter.

  • Learn:

Collaborative activities build products. Learning activities expose those products to a variety of stakeholders to ascertain value. Customer focus groups, technical reviews, beta testing, and postmortems are all practices that expose results to scrutiny.

Dynamic Systems Development

Dynamic Systems Development Model, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994 with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling Agile and iterative software development projects.

DSDM Life cycle

Life Cycle

The diagram depicts the life cycle of the DSDM Methodology as shown.

Characteristics

DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time. Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:

M – Must have requirements

S – Should have if at all possible

C – Could have but not critical

W - Won’t have this time, but potentially later

All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.

Other Methodologies

Rational Unified Process

Rational Unified Processwas developed by Philippe Kruchten,Ivar Jacobsen and others at Rational Corporation to complement UML(Unified Modelling language),an industry-standard software modeling method.

RUP is an iterative approach for object-orieneted systems, and it strongly embraces use cases for modeling requirements and building the foundation for a system.RUP is inclined towards object-oriented development. The lifespan of a RUP project is divided into four phases named Inception,Elaboration,Construction and Transition.These phases are split into iterations,each having a purpose of producing a demonstrable piece of software.The duration of an iteration may vary from two weeks or less up to six months.

Open Source Software Development

Open source software development is the process by which open source software (or similar software whose source code is publicly available) is developed. These are software products “available with its [source code and under an open source license to study, change, and improve its design”. Examples of popular open source software products are Mozilla Firefox, Google Chrome etc..

OSS in many ways follows the same lines of thought and practices as other agile methods. For example, the OSS development process starts with early and frequent releases, and it lacks many of the traditional mechanisms used for coordinating software development with plans, system level designs and defined process.

Typically, an OSS project consists of the following visible phases:

  • Problem discovery
  • Finding volunteers
  • Solution identification
  • Code development and testing
  • Code change review
  • Code commit and documentation
  • Release management

Agile Modelling

Agile Modeling is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for Modeling software that can be applied on a software development project in a more flexible manner than traditional Modeling methods. Agile Modeling is a supplement to other Agile methodologies such as:

Extreme Programming

Rational Unified Process

Scrum

Comparision

How widely these methodologies are used<ref>http://www.forrester.com/imagesV2/uplmisc/NN_AppDev2.pdf </ref>

Agile project management has entered the mainstream – incremental delivery is now common and (should be) expected for any new software development project. But,it still is in its naive stages in terms of the acceptance of the evolution in ideology that it demands.

For small scale projects, averages of 58% of agile techniques are used when developing software. So for example if the respondent was using XP on a small scale project, 7 out of 12 XP techniques would be followed while the other 5 would either be changed or ignored to fit the project constraints and needs. Fewer respondents are following agile techniques for medium and large scale projects, as trends show that weighted average of 34% and 22% respectively of the techniques were implemented in the projects. As the development of software increases, there is a corresponding decrease in the number of agile techniques used. Furthermore, respondents tend to use heavyweight methods when the increase of project size, complexity, team, architecture, scope, and risks occur.

Forrester’s Business Technographics® September 2006 North American And European Enterprise Software Survey indicates that 17% of North American and European enterprises currently use Agile processes and that another 29% are aware of them.Forrester believes that Agile adoption is actually higher than reported in this study. Based on the interactions with enterprise IT organizations, Forrester estimates that very few large enterprises use Agile for most of their projects.

A recent survey conducted by Dr. Dobb’s Journal shows 41 percent of development projects have now adopted agile methodology, and agile techniques are being used on 65 percent of such projects.This is shown in the diagram.

In retrospect,when is agile method not adopted? It primarily comes down to the people. If the people involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. Thus, agile cannot be imposed onto people.

Evidence to support the effectiveness of Agile Development<ref>http://www.agilemodeling.com/essays/proof.htm </ref>

Adopting and then tailoring a software process to meet your team’s needs is an important and difficult decision, one that is critical to your project’s success. There are a myriad of choices. So it is important to determine whether an agile development methodology works effectively within your environment. There is growing survey evidence that agile works better than traditional.One of them is summarized in Figure 2.


Above is the DDJ 2007 Project Success Survey that showed that when people define success in their own terms, Agile projects had a 72% success rate, compared with 63% for traditional and 43% for offshoring.

Craig Larman,in his book Agile and Iterative Development: A Manager's Guide makes a very good argument that proof exists that shows that many of the common practices within agile software development do in fact work, practices such as incremental delivery and iterative approaches which embrace change. He also cites evidence which shows that serial approaches to development, larger projects, and longer release cycles lead to greater incidences project failure.

Effectiveness of agile methodology can be proved with feedback cycle which indicated the time in which response is obtained. Agile techniques are found to have very short feedback cycles, often on the order of minutes or hours whereas traditional techniques, such as reviews, inspections, and big requirements up front (BRUF) have feedback cycles on the order of weeks or months, making them riskier and on average more expensive.

From the surveys and the present organizational scenario, people's experience with agile software development can be observed to be very positive, and that adopting agile strategies appears to be very low-risk in practice.

Conclusion

To conclude, agile software development stresses rapid iterations, small and frequent releases, and evolving requirements facilitated by direct user involvement in the development process. This development isn’t managerial free-for-all. It requires discipline and adherence to processes, even when those processes are not burdensome. When it comes to methodologies, each project is differentand and there is no one-size-fits-all solution. Agile development is being adopted in the enterprise world widely and it is not long before agile would be part of the thinking process rather than a strategy.

See also

External Links

References

<references/>

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch5_6d_ny&oldid=55988"