Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-04-03T04:09:58Z

Mdnevill:

==Introduction==
===Background===
Assignments in Expertiza have many components--due dates and topics, for example. Due dates and topics are objects in their own right (DueDate, SignupTopic); we need a way to have sets of due dates and topics associated with an assignment.
There are also separate forms to create and edit an Assignment and its components (Topics, Due Dates), these forms should be unified into one form for every component of an Assignment.
Also, it'd be nice if we could sort assignment due dates in order of next due.
===What Needs to be Done===
* Remove the separate New and Edit forms for assignment
* Create a form object to encapsulate the creation and editing of Assignments, Due Dates, and Topics
* Add the ability to sort Due Dates
====Classes====
* controllers/assignments_controller.rb
* controllers/due_date_controller.rb
* controllers/sign_up_sheet_controller.rb
* models/due_date.rb
* models/sign_up_topic.rb

====Objectives====
* All CUD (Create, Update, Delete) operations on Assignments, Due Dates, and Topics should be performed through an AssignmentFormObject
* Assignment, Due Date, and Topic views and controllers should be subsumed into a combined AssignmentFormObject view and controller
==Design and Implementation==
As a bit of background, form objects<ref>http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/</ref> could be thought of as a fake model that is not itself persisted but persists all its component models. The name comes from the idea that in many cases forms require information for several models at a time, rather than just one. Creating a series of forms to work with each model at a time is tedious and frustrating, both for the coder and for the end user. A form object fixes this problem by acting like a model. It can have validations, persistence strategies, and a save method that returns the object if and when it is saved, just like a model. Behind the scenes it is intelligently manipulating other models to provide this functionality transparently, encapsulating the required logic.

Our design uses one form object, AssignmentFormObject, to store data about the base Assignment model, Due Date, and Topic models associated to that Assignment. In this way we can achieve both objectives, utilizing the form object to create, update, and delete Assignments and associated Due Date and Topics without having to have separate controllers and views for each.

The form object inherits from ActiveRecord (though is not a subclass of) in order to be able to mass-assign attributes and create custom validations and Virtus<ref>https://github.com/solnic/virtus</ref> to handle attributes like a normal model. We need these custom validations because the attributes of the form object include arrays of attributes for models, something the default validations cannot handle on their own. In addition, we need to run validations on the parameters passed in for each of the models contained within the form object, again something that the default validations cannot do.

The logic behind persisting a form object is somewhat more complicated than a normal model (in which you very rarely have to override the default save operation). This is because form objects must persist several models at once, as shown below.
<nowiki>Assignment.transaction do
if @assignment.save

topics_list.each do |a|
a.assignment = @assignment
if !a.save
raise ActiveRecord::Rollback
end
end

due_dates_list.each do |a|
a.assignment = @assignment
if !a.save
raise ActiveRecord::Rollback
end
end</nowiki>
The form object starts a transaction (in order to guarantee that either everything or nothing is saved) then attempts to create (or update) the Assignment. If this succeeds, it moves on to the components of the Assignment, doing the same. If any one of these operations fails (for instance, if a topic is not able to be saved), the entire operation is rolled back, removing all of the partially saved changes and reverting to before the form object attempted to persist. In this way we make sure that the save operation is atomic like a normal model's save operation.

Because the form object can be treated like a model, writing a controller to populate views with it is just as easy as with a normal model, as shown.
<nowiki>
def create
@assignment_form_object = AssignmentFormObject.new(params)
if @assignment_form_object.save
alert("Form saved")
else
alert("Error saving form")
end
end
</nowiki>

===Changes to the View===
Basically, we have added the ability to add most of the same attributes to a new assignment as when editing an existing assignment. Previously, you could only
provide an assignment name, then you had to add due dates, etc. There are still some limitations to this process due to the complicated relationships between
models. To view the changes, navigate to "~/assignments/new". The addition of Rubrics and Review Strategies is currently not implemented for new assignments, and
this should be addressed in future works. In addition, you may only add one topic to a new assignment, then you must add more topics at the edit page.
The addition of due dates uses a partial view that is in need of refactoring. In addition some validation is necessary for date times. For submission due dates
and review due dates, please provide a date time.

===Affected Classes===
Changed existent classes
* controllers/assignments_controller.rb
* models/due_date.rb
* views/assignments/new.html.erb
* views/assignments/edit.html.erb
* views/assignments/edit/_add_signup_topics.html.erb
* views/assignments/edit/_due_dates.html.erb
* views/assignments/edit/_general.html.erb
* views/assignments/edit/_rubrics.html.erb

Added classes
* models/AssignmentFormObject.rb
* controllers/assignment_form_object_controller.rb
* helpers/assignment_form_object_helper.rb
* views/assignment_form_object/new.erb
* views/assignments/new/_add_signup_topics.html.erb
* views/assignments/new/_due_dates.html.erb
* views/assignments/new/_general.html.erb
* views/assignments/new/_late_policy.html.erb
* views/assignments/new/_review_strategy.html.erb
* views/assignments/new/_rubrics.html.erb

==Running the Project Locally==
In order to run the project locally (for feature testing or for running unit tests) please follow
these steps:
1. Clone the GitHub repository (https://github.com/losmescaleros/expertiza)
2. Run "bundle install"
3. Run "rake db:create:all"
4. If you have a database dump, run it. For this project, we used the one located here:
http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza_scrubbed_2014_03_14.sql.zip
"mysql -u root pg_development < expertiza-scrubbed.sql"
Note that this may not be the name of the zipped dump, but you can customize to your needs. You may
also need to specify your mysql password using "mysql -u root -p ..." depending on your mysql setup.
5. Run "exec rake db:migrate"
6. Run the rails server using "rails server -p 3000". You may substitute 3000 with a port number of
your choice.

===Running Tests===
For this project, we used RSpec for unit tests. These are located at spec/models/assignment_form_object_spec.rb. The tests
are primarily unit tests for the model, and it required a lot of testing of other models that were not well tested (or tested
at all) elsewhere.

==Future Work==
As with every project there are always more things to be done. With the use of a form object there are side benefits that we can take advantage of with more effort that we just didn't have time for. There are also some problematic areas we uncovered during the project that could use cleaning up. The following additional steps (or features) should be taken (or implemented) by anyone continuing with the project.
* Ability to add multiple sign up topics from a new form
* Ability to add rubric details from a new form
* Redo the due dates partial to be more readable and use rails conventions rather than JavaScript
* Redo the due dates partial in general, it is very messy and difficult to work with
* Relocate JavaScript scripts to another.js resource file rather than in-line in the html
* Eliminate the need to have multiple calls to the same controller methods for every table entry for due dates on the edit pages
==References==
<references/>

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T03:16:08Z

Mdnevill: /* Prototype Development */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms life cycle] of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Traditional_.28Waterfall.29_Development waterfall (traditional)] software development, [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Agile_Development agile] software development, and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Prototype_Development prototype] software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of the waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.

Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.

==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:

* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage of traditional development is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccuracy can trickle down until the last phase, and the final product may suffer many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result inaccuracies of 50-100%. Another disadvantage with the waterfall model is analyzing various risk factors. Potential risk factors include aspects like finances, resources, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be seen below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto" <ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms Scrum and Extreme Programming (XP)]. ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the project's success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized teams, using the planning game and collective ownership of the product.
* Face to face communication through paired programming, open space, on-site customers, the planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still tend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* It requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work. Prototyping is most commonly incorporated into agile software development and not used as stand-alone development process.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* Software Life Cycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T03:12:02Z

Mdnevill: /* Agile Development */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms life cycle] of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Traditional_.28Waterfall.29_Development waterfall (traditional)] software development, [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Agile_Development agile] software development, and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Prototype_Development prototype] software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of the waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.

Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.

==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:

* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage of traditional development is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccuracy can trickle down until the last phase, and the final product may suffer many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result inaccuracies of 50-100%. Another disadvantage with the waterfall model is analyzing various risk factors. Potential risk factors include aspects like finances, resources, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be seen below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto" <ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms Scrum and Extreme Programming (XP)]. ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the project's success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized teams, using the planning game and collective ownership of the product.
* Face to face communication through paired programming, open space, on-site customers, the planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still tend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* It requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* Software Life Cycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T03:08:01Z

Mdnevill: /* Traditional (Waterfall) Development */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms life cycle] of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Traditional_.28Waterfall.29_Development waterfall (traditional)] software development, [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Agile_Development agile] software development, and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Prototype_Development prototype] software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of the waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.

Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.

==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:

* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage of traditional development is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccuracy can trickle down until the last phase, and the final product may suffer many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result inaccuracies of 50-100%. Another disadvantage with the waterfall model is analyzing various risk factors. Potential risk factors include aspects like finances, resources, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be seen below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* Software Life Cycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T03:01:22Z

Mdnevill: /* Background */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms life cycle] of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Traditional_.28Waterfall.29_Development waterfall (traditional)] software development, [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Agile_Development agile] software development, and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Prototype_Development prototype] software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* Software Life Cycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T03:01:00Z

Mdnevill: /* Background */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms life cycle] of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Traditional_.28Waterfall.29_Development waterfall (traditional)] software development, phttp://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Agile_Development agile] software development, and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Prototype_Development prototype] software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* Software Life Cycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:59:19Z

Mdnevill: /* Background */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1_1w1m_bm#Terms life cycle] of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* Software Life Cycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:57:20Z

Mdnevill: /* Terms */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* Software Life Cycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:56:47Z

Mdnevill: /* Terms */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.
* software lifecycle - The process of planning, analysis, design, implementation, and maintenance that a piece of software undergoes.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:54:15Z

Mdnevill: /* Background */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.

[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 - Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:53:36Z

Mdnevill: /* Agile versus Waterfall Development in the Real World */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 - Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 - Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:53:18Z

Mdnevill: /* Agile versus Waterfall Development in the Real World */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Fig. 2.1 Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Fig. 2.2 Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:51:25Z

Mdnevill: /* Background */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Fig. 1.1 Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:50:13Z

Mdnevill: /* Agile versus Waterfall Development in the Real World */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|frame|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:46:24Z

Mdnevill: /* Terms */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
*[http://www.extremeprogramming.org/ Extreme Programming (XP)] - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:46:09Z

Mdnevill: /* See also */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
* Extreme Programming (XP) - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:45:54Z

Mdnevill: /* Terms */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies
* Extreme Programming (XP) - An agile development process that focuses on providing necessary aspects of a product in a timely manner, rather than delivering a monolithic product out of schedule.

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]

* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:43:42Z

Mdnevill: /* Terms */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum] - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]

* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:43:27Z

Mdnevill: /* See also */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* Scrum - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]

* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:43:04Z

Mdnevill: /* Terms */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* Scrum - Described as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal," which is in contrast to traditional, sequentially based strategies

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:40:42Z

Mdnevill: /* Terms */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==
* Scrum

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:40:06Z

Mdnevill: /* Comparison of Waterfall, Prototype, and Agile Development */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== Terms ==

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:38:38Z

Mdnevill: /* Agile versus Waterfall Development in the Real World */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

According to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:36:51Z

Mdnevill: /* Disadvantages */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:36:36Z

Mdnevill: /* Choosing the Right Methodology */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. Incorporating prototypes can help obtain feedback from stakeholders and provide a working model of certain aspects of the product. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-25T02:34:05Z

Mdnevill: /* Comparison of Waterfall, Prototype, and Agile Development */

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activities or projects, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps and strategies to complete a project, and the software development process is no different. These project management steps help determine the development process and lifecycle of a piece software. Certain management processes have been developed into models that describe exactly how to design, implement, and maintain software products. This article compares three such development models: waterfall (traditional) software development, agile software development, and prototype software development.

A software development methodology is a framework that is used to structure, plan and control the process of development. Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development. The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project. The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws. The advantages are:
* Being a linear model, it is very simple to implement.
* The amount of resources required to implement this model are minimal.
* Documentation is produced at every stage of the software's development. This makes understanding the product designing procedure, simpler.
* After every major stage of software coding, testing is done to check the correct running of the code.

==== Disadvantages ====
Ironically, the biggest disadvantage is one of its greatest advantages. While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ([http://wiki.expertiza.ncsu.edu/index.php/File:Waterfall_inaccuracy.PNG Fig 1]) an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible. Other disadvantages can be listed as below:
* It is very difficult to go back and change something that was not well-thought out in the concept stage.
* No working software is produced until late during the life cycle.
* Not a good model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product.
* Face to Face Communication through paired programming, open space, on-site customer, planning game.
* Sustainable base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt.
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests.
* The cost efficiency of pair programming can be questionable in certain situations.

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback. Major advantages of prototype model are:
* Repeated or continuous development helps in risk management
* Adaptability in the design in software engineering accommodates any number of changes, that may happen, during any phase of the project.
* Cost estimation becomes easy and the customer can gain control on administration of the new system since the prototype building is done in small fragments or bits.
* As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Major is that modules that are too insular may become ‘mini-projects’ consisting of just a few developers each. Each mini-project may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these mini-projects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype methodology could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided.

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://en.wikiversity.org/wiki/Crystal_Methods Crystal]
* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]
* [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology Choosing Your Software Development Process: Agile or Waterfall?]
* [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.4293&rep=rep1&type=pdf Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T04:29:04Z

Mdnevill:

[https://docs.google.com/a/ncsu.edu/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Writing Assignment 1b]
= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T04:19:11Z

Mdnevill: /* Methodology Summaries */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
|
*Complete solution
|
*Prototype versions
|
*Functional modules
|-
| '''Development process:'''
|
*Linear
|
*Milestones and integration
|
*Short iterations
|-
| '''Changes consist of:'''
|
*Changes are locked down
|
*Calibration
*Prototyping and integration
|
*Experimentation
*Improvement
*Re-prioritization
|-
| '''Feature set:'''
|
*Users specify all requirements at the start
|
*User requests are prototyped and later intergrated
|
*User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
|
*Structured and sequential
*Process-oriented
*Less re-work due to static specification
|
*Command-Control culture
*Heavy documentation
*Scope/requirements decided upfront
*Change demands high cost
|-
| '''Prototype'''
|
*Incremental approach with “milestones”
*Progress-oriented
*Moderate documentation
*Scope/requirements versioned and integrated versions
|
*Prototype culture
*Change demands considerable cost
*Moderate work in integrating the versions
|-
| '''Agile'''
|
*Iterative and incremental
*Collaboration culture
*Low documentation
*Scope/requirements easy to adapt and change
*Change demands least cost
|
*More re-work due to dynamic specification
|-
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T04:13:07Z

Mdnevill: /* Methodology Summaries */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! '''Traditional (Waterfall)'''
! '''Prototype'''
! '''Agile'''
|-
| '''Consists of:'''
| Complete solution
| Prototype versions
| Functional modules
|-
| '''Development process:'''
| Linear
| Milestones and integration
| Short iterations
|-
| '''Changes consist of:'''
| Changes are locked down
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| '''Feature set:'''
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! '''Advantages'''
! '''Disadvantages'''
|-
| '''Traditional (Waterfall)'''
| Structured and sequential, Process-oriented, Less re-work due to static specification
| Command-Control culture, Heavy documentation, Scope/requirement decided upfront, Change demands high cost
|-
| '''Prototype'''
| Incremental approach with “milestones”, Progress-oriented, Moderate documentation as, Scope/requirement versioned and integrated versions
| Prototype culture, Change demands considerable cost, Moderate work in integrating the versions
|-
| '''Agile'''
| Iterative and incremental, Collaboration culture, Low documentation, Scope/requirement easy to adapt and change, Change demands least cost
| More re-work due to dynamic specification
|-
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T04:01:54Z

Mdnevill: /* Choosing the Right Methodology */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Methodology Summaries ===
The following table gives a higher level view of the most important aspects of each methodology:
{| class="wikitable" border="1"
|-
!
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Consists of:
| Complete solution
| Prototype versions
| Functional modules
|-
| Development process:
| Linear
| Milestones and integration
| Short iterations
|-
| Changes consist of:
| Changes are locked down
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Feature set:
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
!
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Advantages:
| *Structured and sequential
|
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Disadvantages:
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:53:10Z

Mdnevill: /* Summary */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

=== Summary ===
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:52:54Z

Mdnevill: /* Choosing the Right Methodology */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

== Choosing the Right Methodology ==

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:52:14Z

Mdnevill: /* Disadvantages */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.

Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

=== Choosing the Right Methodology ===

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:51:53Z

Mdnevill: /* Disadvantages */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki"> [http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

=== Choosing the Right Methodology ===

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:48:21Z

Mdnevill:

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">

Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
Prototype modularity could also lead to individuals becoming singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less. In the same way, when only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided
[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>
[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

=== Choosing the Right Methodology ===

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:35:34Z

Mdnevill: /* Disadvantages */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed. Some common complaints about agile methodologies include:
* Requires too much cultural change to adopt
* It goes against basic human "psychology": people prefer to follow a process, have milestones, and are geared towards their own self-interests
* The cost efficiency of pair programming can be questionable in certain situations

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.
*Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
*Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
*When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided
==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>
[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

=== Choosing the Right Methodology ===

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:32:02Z

Mdnevill: /* Advantages */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly believe that people are the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles:
* Motivated individuals and self organized team using the planning Game and collective ownership of the product
* Face to Face Communication through paired programming, open space, on-site customer, planning game
* Sustainable base

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.
* Requires too much cultural change to adopt. 
* Go against "Human Psychology": many human factors goes against Agile methodologies, such as: People prefer to follow a process, No milestones, People self-interest, mini-dictatorships, Knowledge monopolies, Resource management vanish, customer dissatisfaction. 
* The cost efficiency of pair programming is questionable. 

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.
*Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
*Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
*When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided
==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>
[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

=== Choosing the Right Methodology ===

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:26:07Z

Mdnevill: /* Agile versus Waterfall Development */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly state their believe that people is the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles; 
* Motivated individuals and Self organized team: Planning Game, Collective ownership.
* Face to Face Communication: Pair programming, Open space, On-site customer, Planning game.
* Sustainable Base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.
* Requires too much cultural change to adopt. 
* Go against "Human Psychology": many human factors goes against Agile methodologies, such as: People prefer to follow a process, No milestones, People self-interest, mini-dictatorships, Knowledge monopolies, Resource management vanish, customer dissatisfaction. 
* The cost efficiency of pair programming is questionable. 

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.
*Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
*Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
*When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided
==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>
[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development in the Real World ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects. Accrding to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] within Microsoft. According to the survey, the top benefits of following agile development were improved communication and coordination among team members, quick releases and flexibility of design, and quicker response to changes. Some of the downsides of the agile development were coordination with other teams, losing sight of the big picture, and development and testing integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

=== Choosing the Right Methodology ===

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-20T03:22:02Z

Mdnevill: /* An Empirical Study in Agile Development */

= Comparison of Waterfall, Prototype, and Agile Development =

== Background ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.
[[ File:Waterfall_inaccuracy.PNG|thumb|1000px|alt=Inaccuracy in waterfall.|Inaccuracy in waterfall model]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion. Agile methodologies clearly state their believe that people is the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles; 
* Motivated individuals and Self organized team: Planning Game, Collective ownership.
* Face to Face Communication: Pair programming, Open space, On-site customer, Planning game.
* Sustainable Base.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.
* Requires too much cultural change to adopt. 
* Go against "Human Psychology": many human factors goes against Agile methodologies, such as: People prefer to follow a process, No milestones, People self-interest, mini-dictatorships, Knowledge monopolies, Resource management vanish, customer dissatisfaction. 
* The cost efficiency of pair programming is questionable. 

[[Image:dilbert-Interaction.gif|center]] 

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.
*Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
*Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
*When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided
==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>
[[Image:prototype.gif|center]]

== Empirical Studies in Agile Development ==
=== Agile versus Waterfall Development ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

People at Microsoft research lab have done extensive research on the application of agile development on large scale projects.According to the [http://research.microsoft.com/pubs/56015/agiledevatms-esem07.pdf Andrew Begel and Nachiappan Nagappan] dominant agile methodologies used are [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum],[http://en.wikipedia.org/wiki/Extreme_programming XP] and [http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) Crystal] with in Microsoft. According to the survey, the top benefit of following agile development was improved communication and coordination among team members, quick releases and flexibility of design-quicker response to changes. Some of the downside of the agile development were coordination with other teams, lose sight of big picture and dev/test integration.

[[File:diff_water_agile.png|thumb|1000px|alt=Full-length A graph that shows the advantage of agile over waterfall.|Development in waterfall and agile methodology]]

Acoording to [http://versionone.com/assets/img/files/ChaosManifest_2011.pdf The Chaos Manifesto], the graph below shows the specific results reported from a study conducted based on projects executed from 2002 to 2012. In 2002, agile projects made up less than 2% of over all projects and less than 5% of new application development projects. Today, agile projects account for almost 9% of all projects and 29% of new application development projects. The increase in project success rates can directly tie back to projects resolved through agile process.
[[File:Agile-Waterfall-Success-Failure-Rates.jpg|alt=Graph showing waterfall and agile success rates.|Waterfall and agile success rates]]

=== Choosing the Right Methodology ===

When it comes down to which model is better, neither the agile method, prototype or waterfall is inherently better than the other. Each method does have its uses. Waterfall tends to be best for static projects, where it's not likely that many changes will be made throughout the development process. Agile methodology would be a better option for smaller projects where changes are likely to made during the development process. One can consider ''taking best of all'' i.e., taking best aspects of waterfall, prototype and agile combining them in order to make the best possible software development process.

== Summary ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== See also ==
*[http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Survey of Agile Development Methodologies]
*[http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model Waterfall]
*[http://courses.cs.vt.edu/~csonline/SE/Lessons/Waterfall/index.html Waterfall modules]
*[http://www.extremeprogramming.org/ Extreme Programming]
* [http://agile.csc.ncsu.edu/crystal.html Crystal]
* [http://agile.csc.ncsu.edu/scrum.html Scrum]
* [http://courses.ncsu.edu/csc326/lec/001/lectures/ChooseProcess.pdf Choosing Your Software Development Process: Agile or Plan-driven?]
* [http://www.lib.ncsu.edu:2097/content/54rr5mbq291rc5cy/ Taken from Empirical Findings in Agile Methods]

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T22:25:05Z

Mdnevill: /* Examples */

= Comparison of Waterfall, Prototype, and Agile Development =

== Introduction ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

== Background ==
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that ''(Fig 1)'' an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.[[File:Waterfall_inaccuracy.PNG]]

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

== An Empirical Study in Agile Development ==
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

The advantage of agile over the traditional model is best explained by [http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm Scott W Amber] in the following graph:
[[File:Diff_agile_water.png]]

== Narration ==
The following table gives a higher level view of the variations between traditional (waterfall), prototype and agile development.
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Complete solution
| Prototype versions
| Functional modules
|-
| Linear development process
| Milestones and integration
| Short iterations
|-
| Lock-down change
| Calibration , prototyping and integration
| Experimentation, improvement and re-prioritization
|-
| Users specify all requirements at the start
| User requests are prototyped and later intergrated
| User requests embedded throughout the process
|}

The features, advantages and disadvantages of the three models are tabulated as follows:
{| class="wikitable" border="1"
|-
! Traditional (Waterfall)
! Prototype
! Agile
|-
| Structured and sequential
| Incremental approach with “milestones”
| Iterative and incremental
|-
| Process-oriented
| Progress-oriented
| People-Oriented
|-
| Command-Control culture
| Prototyping culture
| Collaboration culture
|-
| Heavy documentation
| Moderate documentation as versions
| Low documentation
|-
| Scope/requirement decided upfront
| Scope/requirement versioned and integrated
| Scope/requirement easy to adapt and change
|-
| Change demands high cost
| Change demands considerable cost
| Change demands least cost
|-
| Less re-work due to static specification
| Moderate work in integrating the versions.
| More re-work due to dynamic specification
|}

== Terminology ==

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T04:26:47Z

Mdnevill: /* An Empirical Study in Agile Development */

= Comparison of Waterfall, Prototype, and Agile Development =

== Introduction ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

== Background ==
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

== Examples ==
=== An Empirical Study in Agile Development ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]<ref name="Empirical studies of agile software development: A systematic review">[http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review]</ref>, published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

== Narration ==

== Terminology ==

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T04:25:19Z

Mdnevill: /* An Empirical Study in Agile Development */

= Comparison of Waterfall, Prototype, and Agile Development =

== Introduction ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

== Background ==
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

== Examples ==
=== An Empirical Study in Agile Development ===
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review], published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

== Narration ==

== Terminology ==

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T04:25:05Z

Mdnevill: /* = An Empirical Study in Agile Development */

= Comparison of Waterfall, Prototype, and Agile Development =

== Introduction ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

== Background ==
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

== Examples ==
== An Empirical Study in Agile Development ==
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review], published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

== Narration ==

== Terminology ==

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T04:24:52Z

Mdnevill: /* Examples */

= Comparison of Waterfall, Prototype, and Agile Development =

== Introduction ==
Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen. Project managers identify a number of steps/strategies to complete a project. This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

== Background ==
Software development methodology is a framework that is used to structure,plan and control the process of development.Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>.In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.
The first stage of waterfall model considers the development of the project with an initial project plan. This is essentially a blueprint that software developers will use to construct the product which remains constant throughout the various phases of the model. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.
Any project for which complete and consistent requirements are available is amenable to the waterfall model. In general, this will tend to be a very small project.The only large projects that are amenable to the waterfall model would be projects of re-engineering an existing system, where all the requirements are known well before starting the process of change.
==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Since the project plan is framed at a very early stage, the estimations can be inaccurate. The inaccurate measures trickles down till the last phase and the final product suffers many flaws. Studies as mentioned in <ref>https://dspace.mit.edu/bitstream/handle/1721.1/34801/57553849.pdf?sequence=1</ref> show that an estimate done at early stages result in 50-100% inaccurate. Another disadvantage with the waterfall model is analyzing various risk factors. List of potential risk factors include aspects like finance, resource, schedule and technology. Rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",<ref>[http://agilemanifesto.org/ The Agile Manifesto]</ref>, the agile software development process values:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Within agile development, there are several different types, including Scrum and Extreme Programming (XP). ([http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/ A more substantial list of agile methodologies with descriptions].)

==== Advantages ====

Agile software methodologies offer flexibility, promoting evolutionary development. As the product is developed, customer feedback and testing are incorporated simultaneously. <ref name="Waterfall: Evaluating The Pros And Cons">[https://www.udemy.com/blog/agile-vs-waterfall/ Agile Vs. Waterfall: Evaluating The Pros And Cons]</ref> In this manner, agile software development is especially beneficial when a customer's requirements are changing or unclear. Furthermore, as stated in the agile manifesto, agile methodologies promote teamwork and cohesion.

==== Disadvantages ====

The changing nature of agile software development makes things like schedule and budgets somewhat hard to predict. <ref name="Waterfall: Evaluating The Pros And Cons"></ref> While the collaborative nature of agile methodologies can be a benefit, it is also a hindrance, since team members are often involved for the life of the project. This requires designers to still attend to the project's changing specifications after initial design has been completed.

=== Prototype Development ===
The prototype development process can be used to provide a working model of a product or some aspect of the product for testing and feedback. This is often done during the early stages of development, and it provides the customer a means of proofing the product. <ref name="Software Prototyping and Agile Development">[http://www.impacttechnology.co.uk/software-consultancy/prototyping-agile-dev Software Prototyping and Agile Development]</ref> As the prototype often changes and evolves during the process, it is essentially used to figure out exactly how a component should work.

==== Advantages ====
Software prototyping essentially provides a means for agile software development because it opens a discussion about what customers want. Customers can use the prototype, see what they like and dislike, and this reduces the cost of making the change later in the project. As customers and software developers often have different vocabularies and interpretations of the requirements, a prototype allows customers and other users to provide more meaningful feedback.

==== Disadvantages ====
Because prototypes often do not depict the entire project, their use can lead to misinterpretation. The limited prototype can distract users from the big picture, which can lead to overlooking other solutions. In the case of customers, they may see a limited prototype as an insufficient substitute for the product as a whole, and they may not provide the beneficial feedback the prototype was intended for. Another problem is that too much time, effort, and money can be invested in a prototype that is intended to be thrown away. <ref name="Software Prototyping Wiki">[http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping Software Prototyping Wiki]</ref>

== Examples ==
=== An Empirical Study in Agile Development ==
The paper [http://www.producao.ufrgs.br/arquivos/disciplinas/507_artigo_3_empirical_systematic_review.pdf Empirical studies of agile software development: A systematic review], published in 2008, sought to determine how exactly agile software methodologies were being used in the real world. As agile was not a widely known concept until 2001, they analyzed published findings concerning agile software development between 2001 and 2005. During that time, a survey of American and European countries showed that only 14% of companies were using agile methodologies, while 49% were interesting in adopting them. During an analysis of some 36 papers, it was uncovered that customers often praised agile methodologies for letting them feel that they had complete control over the development process. In addition, customers reported that daily meetings kept them up to date on the product's status, and developers were often more clear about what their development objectives were. However, in some cases, the collaborative nature of agile methodologies proved difficult in outsourced projects, as some customers were required to become acclimatizes the working processes of outside developers.

From a developer's standpoint, many papers reported that developers felt more comfortable using an agile methodology like XP or paired programming. In particular, many developers reported that paired programming seemed to make the process quicker; however, they also reported that this process seemed more tiring, as it required intense concentration. Furthermore, Scrums were favored by developers, and they even led to a reduction in overtime in certain cases.

As for productivity, for the 36 papers studied, 42% reported an increase in productivity over traditional development methods. The majority of the productivity gain was often seen during the first iteration of the software. In addition, many of the papers reported reduced errors and better overall quality for products developed using agile methodologies.

== Narration ==

== Terminology ==

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T03:45:47Z

Mdnevill: /* Prototype Development */

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T03:29:30Z

Mdnevill: /* Background */

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T03:27:21Z

Mdnevill:

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T02:51:29Z

Mdnevill:

= Comparison of Waterfall, Prototype, and Agile Development =

== Introduction ==
This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

== Background ==
Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.

When following the waterfall model, during the Conception, Initiation, Analysis, and Design stages, the specifications for the project are permanent. This is essentially a blueprint that software developers will use to construct the product. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.

==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Furthermore, rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.

=== Agile Development ===
In contrast to traditional development, agile software development attempts to adapt nimbly to changing environments. These may include accelerated deadlines and changes in user requirements. According to the "agile manifesto",

== Examples ==

== Narration ==

== Terminology ==

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T02:46:59Z

Mdnevill:

= Comparison of Waterfall, Prototype, and Agile Development =

== Introduction ==
This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

== Background ==
Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

=== Traditional (Waterfall) Development ===
As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>[http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/# Understanding the pros and cons of the Waterfall Model of software development]</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.

When following the waterfall model, during the Conception, Initiation, Analysis, and Design stages, the specifications for the project are permanent. This is essentially a blueprint that software developers will use to construct the product. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.

==== Advantages ====
Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

==== Disadvantages ====
While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Furthermore, rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.

=== Agile Development ===

== Examples ==

== Narration ==

== Terminology ==

== References ==
<references />

CSC/ECE 517 Spring 2014/ch1 1w1m bm

2014-02-19T02:30:45Z

Mdnevill: