Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-18T20:22:48Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.

== Introduction ==

To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.

Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change
throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and
emphasizes collaboration between developers and the rest of the team, including business people.

Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope
and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding
and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues
throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software
being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall
feature set is expected to occur as outside opportunities or threats arise.

In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant
feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three
principles – or values – are of particular interest:

* Quality software development
* Iterative flexibility
* Continuous improvement

===Quality Software Development===
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e.
provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an
“iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration.
Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile
development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.

===Iterative Flexibility===
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The
iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to
customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and
because each iteration is short, new requirements can be introduced and prioritized very quickly.

===Continuous Improvement===
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do
their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance
occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult
or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and [http://en.wikipedia.org/wiki/Quality_assurance Quality Assurance] process transparent to the developers who originate the code, further contributing to their learning and facilitating future
improvements and coding efficiencies.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Complementing agile : extending to newer agile methodologies==

Separating Design from Engineering: Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers write code and design the implementation of systems—that is what they are good at. They are not good at understanding how people work, creating effective and intuitive user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what engineers do best. The weakness of agile methods is that they give little guidance in figuring out what to tell the engineers to do.

Core Team: Possible agile solutions would be to start with a core team which builds out a simple business case in a test-driven manner. This first phase will build out enough of most of the architecture. With a small team, a full agile methodology works without modification. When a significant portion of the architecture is built, it is time to divide the project by growing the development team and splitting up into smaller subteams to grow the project into a fully functional software system.

Role of an architect: While there is no traditional architect role in most agile development methodologies, in large teams, it is often beneficial to reintroduce a modified version of this role. The architect is a member of the team with significant design and development talent and experience and he has to understand the ‘whole’ application code-base. The architect is hands-on and pairs with others on the team frequently and will be a participant in many agile modeling design sessions on the whiteboard. This helps keep away redundancies.

Continuous Integration: While each sub-team will have their own build running, agile methodology suggests having a 'brain' team that will have to create a master build that builds all sub-teams code and/or deploy their binary files. The master build will run frequently by pulling down the last successful builds for sub projects, compile and deploy the whole project and run the tests. In case of failure the brain team has to identify the problem and resolve it or take it to the responsible sub team to resolve it.

Refactoring: In large projects Refactoring sometimes becomes very expensive process and may take a month to be done. Some design ahead may be done to save expensive major refactoring later. For the conquer team when it’s still early on the project, to avoid large complicated refactoring some extra time should be spent for designing for future known requirements. Having the overall picture of use cases will make it easier to predict future requirements and create a design that will handle them. This design ahead is allowed only during the conquer phase of the project and will only apply to core systems, frameworks and similar subsystems of the system which may be more expensive to be re-factored.

Tests: To reduce the cost of refactoring, the team may depend on functional tests more than unit tests. Functional tests test the functionality of the system and in general do not depend on the system design. Unit tests should still be created for test driven development and for critical pieces of the system that may cause the system to break. Tests that are created after the development and tests created for reported bugs should be functional tests. Having less unit tests will lead to more time spent in debugging issues and functional tests cannot pin point problems but having a better design through constant refactoring will reduce the development time much more than the extra time being spent in debugging issues. Functional test should be documented in each test to describe the test scenario, expected results and differences between test scenarios.

These are some of the recommended practices that will help mediate some of the problems in applying agile design methodologies to projects. There are also some difficulties with applying these practices such as with the master build, with communication between teams, with extreme designing to get useless frameworks, and care should be taken to avoid them.

Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches. Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven development.

To further understand how Agile methods help complement other design methodologies, consider a case in point:

'''Agile design methodology working with Contextual Design methodology '''

Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.

Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.

Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.

Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.

Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.

== Summary ==

In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# [http://www.agileproductdesign.com/useful_papers/beyer_rapid_cd.pdf An Agile User-Centered Method: Rapid Contextual Design by Hugh Beyer1, Karen Holtzblatt1, Lisa Baker2]
# [http://www.innovatetoday.net/white_papers/ProductDev/Agile_in_a_non_agile_world_whitepaper.pdf Being Agile in a Non-Agile World By David West]

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-18T20:13:27Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.

== Introduction ==

To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.

Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change
throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and
emphasizes collaboration between developers and the rest of the team, including business people.

Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope
and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding
and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues
throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software
being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall
feature set is expected to occur as outside opportunities or threats arise.

In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant
feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three
principles – or values – are of particular interest:

* Quality software development
* Iterative flexibility
* Continuous improvement

===Quality Software Development===
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e.
provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an
“iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration.
Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile
development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.

===Iterative Flexibility===
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The
iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to
customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and
because each iteration is short, new requirements can be introduced and prioritized very quickly.

===Continuous Improvement===
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do
their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance
occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult
or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and [http://en.wikipedia.org/wiki/Quality_assurance Quality Assurance] process transparent to the developers who originate the code, further contributing to their learning and facilitating future
improvements and coding efficiencies.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Complementing agile : extending to newer agile methodologies==

Separating Design from Engineering: Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers write code and design the implementation of systems—that is what they are good at. They are not good at understanding how people work, creating effective and intuitive user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what engineers do best. The weakness of agile methods is that they give little guidance in figuring out what to tell the engineers to do.

Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches. Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven development.

To further understand how Agile methods help complement other design methodologies, consider a case in point:

'''Agile design methodology working with Contextual Design methodology '''

Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.

Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.

Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.

Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.

Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.

== Summary ==

In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# [http://www.agileproductdesign.com/useful_papers/beyer_rapid_cd.pdf An Agile User-Centered Method: Rapid Contextual Design by Hugh Beyer1, Karen Holtzblatt1, Lisa Baker2]
# [http://www.innovatetoday.net/white_papers/ProductDev/Agile_in_a_non_agile_world_whitepaper.pdf Being Agile in a Non-Agile World By David West]

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-18T20:09:44Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.

== Introduction ==

To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.

Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change
throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and
emphasizes collaboration between developers and the rest of the team, including business people.

Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope
and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding
and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues
throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software
being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall
feature set is expected to occur as outside opportunities or threats arise.

In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant
feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three
principles – or values – are of particular interest:

* Quality software development
* Iterative flexibility
* Continuous improvement

===Quality Software Development===
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e.
provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an
“iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration.
Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile
development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.

===Iterative Flexibility===
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The
iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to
customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and
because each iteration is short, new requirements can be introduced and prioritized very quickly.

===Continuous Improvement===
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do
their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance
occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult
or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and [http://en.wikipedia.org/wiki/Quality_assurance Quality Assurance] process transparent to the developers who originate the code, further contributing to their learning and facilitating future
improvements and coding efficiencies.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Complementing agile : extending to newer agile methodologies==

Separating Design from Engineering: Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers write code and design the implementation of systems—that is what they are good at. They are not good at understanding how people work, creating effective and intuitive user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what engineers do best. The weakness of agile methods is that they give little guidance in figuring out what to tell the engineers to do.

Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches. Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven development.

To further understand how Agile methods help complement other design methodologies, consider a case in point:

'''Agile design methodology working with Contextual Design methodology '''

Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.

Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.

Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.

Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.

Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.

== Summary ==

In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker
# [http://www.agileproductdesign.com/useful_papers/beyer_rapid_cd.pdf An Agile User-Centered Method: Rapid Contextual Design by Hugh Beyer1, Karen Holtzblatt1, Lisa Baker2]
# [http://www.innovatetoday.net/white_papers/ProductDev/Agile_in_a_non_agile_world_whitepaper.pdf Being Agile in a Non-Agile World By David West]

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-18T19:59:50Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.

== Introduction ==

To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.

Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change
throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and
emphasizes collaboration between developers and the rest of the team, including business people.

Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope
and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding
and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues
throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software
being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall
feature set is expected to occur as outside opportunities or threats arise.

In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant
feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three
principles – or values – are of particular interest:

* Quality software development
* Iterative flexibility
* Continuous improvement

===Quality Software Development===
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e.
provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an
“iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration.
Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile
development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.

===Iterative Flexibility===
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The
iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to
customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and
because each iteration is short, new requirements can be introduced and prioritized very quickly.

===Continuous Improvement===
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do
their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance
occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult
or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and [http://en.wikipedia.org/wiki/Quality_assurance Quality Assurance] process transparent to the developers who originate the code, further contributing to their learning and facilitating future
improvements and coding efficiencies.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Complementing agile : extending to newer agile methodologies==

Separating Design from Engineering: Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers write code and design the implementation of systems—that is what they are good at. They are not good at understanding how people work, creating effective and intuitive user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what engineers do best. The weakness of agile methods is that they give little guidance in figuring out what to tell the engineers to do.

Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches. Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven development.

To further understand how Agile methods help complement other design methodologies, consider a case in point:

'''Agile design methodology working with Contextual Design methodology '''

Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.

Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.

Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.

Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.

Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.

== Summary ==

In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-18T19:57:22Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.

== Introduction ==
To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.

Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change
throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and
emphasizes collaboration between developers and the rest of the team, including business people.

Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope
and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding
and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues
throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software
being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall
feature set is expected to occur as outside opportunities or threats arise.

In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant
feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three
principles – or values – are of particular interest:

* Quality software development
* Iterative flexibility
* Continuous improvement

===Quality Software Development===
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e.
provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an
“iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration.
Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile
development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.

===Iterative Flexibility===
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The
iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to
customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and
because each iteration is short, new requirements can be introduced and prioritized very quickly.

===Continuous Improvement===
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do
their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance
occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult
or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and [http://en.wikipedia.org/wiki/Quality_assurance Quality Assurance] process transparent to the developers who originate the code, further contributing to their learning and facilitating future
improvements and coding efficiencies.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Complementing agile : extending to newer agile methodologies==

Separating Design from Engineering: Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers write code and design the implementation of systems—that is what they are good at. They are not good at understanding how people work, creating effective and intuitive user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what engineers do best. The weakness of agile methods is that they give little guidance in figuring out what to tell the engineers to do.

Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches. Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven development.

To further understand how Agile methods help complement other design methodologies, consider a case in point:

'''Agile design methodology working with Contextual Design methodology '''

Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.

Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.

Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.

Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.

Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.

== Summary ==

In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-18T19:54:59Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.

== Introduction ==
To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.

Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change
throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and
emphasizes collaboration between developers and the rest of the team, including business people.

Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope
and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding
and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues
throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software
being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall
feature set is expected to occur as outside opportunities or threats arise.

In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant
feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three
principles – or values – are of particular interest:

* Quality software development
* Iterative flexibility
* Continuous improvement

===Quality Software Development===
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e.
provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an
“iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration.
Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile
development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.

===Iterative Flexibility===
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The
iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to
customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and
because each iteration is short, new requirements can be introduced and prioritized very quickly.

===Continuous Improvement===
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do
their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance
occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult
or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and [http://en.wikipedia.org/wiki/Quality_assurance Quality Assurance] process transparent to the developers who originate the code, further contributing to their learning and facilitating future
improvements and coding efficiencies.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Complementing agile : extending to newer agile methodologies==

Separating Design from Engineering: Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers write code and design the implementation of systems—that is what they are good at. They are not good at understanding how people work, creating effective and intuitive user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what engineers do best. The weakness of agile methods is that they give little guidance in figuring out what to tell the engineers to do.

Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.

Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.

Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.

Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.

Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.

Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches. Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven development.

== Summary ==

In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-18T19:52:49Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.

== Introduction ==
To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.

Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change
throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and
emphasizes collaboration between developers and the rest of the team, including business people.

Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope
and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding
and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues
throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software
being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall
feature set is expected to occur as outside opportunities or threats arise.

In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant
feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three
principles – or values – are of particular interest:

* Quality software development
* Iterative flexibility
* Continuous improvement

===Quality Software Development===
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e.
provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an
“iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration.
Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile
development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.

===Iterative Flexibility===
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The
iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to
customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and
because each iteration is short, new requirements can be introduced and prioritized very quickly.

===Continuous Improvement===
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do
their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance
occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult
or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and [http://en.wikipedia.org/wiki/Quality_assurance Quality Assurance] process transparent to the developers who originate the code, further contributing to their learning and facilitating future
improvements and coding efficiencies.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Complementing agile : extending to newer agile methodologies==

Separating Design from Engineering: Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers
write code and design the implementation of systems—that is what they are good at.
They are not good at understanding how people work, creating effective and intuitive
user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what
engineers do best. The weakness of agile methods is that they give little guidance in
figuring out what to tell the engineers to do.

Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.

Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.

Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.

Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.

Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.

Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches.

Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight
management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven
development.

In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-17T15:18:02Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can complement other design methodologies. Section 1 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 2 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 3 takes up a few design methodologies and focuses on how agile complements them.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

*''' Individuals and interactions''' over processes and tools

*'''Working software''' over comprehensive documentation

* '''Customer collaboration''' over contract negotiation

* '''Responding to change''' over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Study of a few Design methodologies and How Agile Complements Them==

===Separating Design from Engineering ===

Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers
write code and design the implementation of systems—that is what they are good at.
They are not good at understanding how people work, creating effective and intuitive
user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what
engineers do best. The weakness of agile methods is that they give little guidance in
figuring out what to tell the engineers to do.

Core Team: Possible agile solutions would be to start with a core team which builds out a simple business case in a test-driven manner. This first phase will build out enough of most of the architecture. With a small team, a full agile methodology works without modification. When a significant portion of the architecture is built, it is time to divide the project by growing the development team and splitting up into smaller subteams to grow the project into a fully functional software system.

Role of an architect: While there is no traditional architect role in most agile development methodologies, in large teams, it is often beneficial to reintroduce a modified version of this role. The architect is a member of the team with significant design and development talent and experience and he has to understand the ‘whole’ application code-base. The architect is hands-on and pairs with others on the team frequently and will be a participant in many agile modeling design sessions on the whiteboard. This helps keep away redundancies.

Continuous Integration: While each sub-team will have their own build running, agile methodology suggests having a 'brain' team that will have to create a master build that builds all sub-teams code and/or deploy their binary files. The master build will run frequently by pulling down the last successful builds for sub projects, compile and deploy the whole project and run the tests. In case of failure the brain team has to identify the problem and resolve it or take it to the responsible sub team to resolve it.

Refactoring: In large projects Refactoring sometimes becomes very expensive process and may take a month to be done. Some design ahead may be done to save expensive major refactoring later. For the conquer team when it’s still early on the project, to avoid large complicated refactoring some extra time should be spent for designing for future known requirements. Having the overall picture of use cases will make it easier to predict future requirements and create a design that will handle them. This design ahead is allowed only during the conquer phase of the project and will only apply to core systems, frameworks and similar subsystems of the system which may be more expensive to be re-factored.

Tests: To reduce the coast of refactoring, the team may depend on functional tests more than unit tests. Functional tests test the functionality of the system and in general do not depend on the system design. Unit tests should still be created for test driven development and for critical pieces of the system that may cause the system to break. Tests that are created after the development and tests created for reported bugs should be functional tests. Having less unit tests will lead to more time spent in debugging issues and functional tests cannot pin point problems but having a better design through constant refactoring will reduce the development time much more than the extra time being spent in debugging issues. Functional test should be documented in each test to describe the test scenario, expected results and differences between test scenarios.

These are some of the recommended practices that will help mediate some of the problems in applying agile design methodologies to projects. There are also some difficulties with applying these practices such as with the master build, with communication between teams, with extreme designing to get useless frameworks, and care should be taken to avoid them.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-17T15:12:58Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can complement other design methodologies. Section 1 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 2 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 3 takes up a few design methodologies and focuses on how agile complements them.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

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

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Study of a few Design methodologies and How Agile Complements Them==

===Separating Design from Engineering ===

Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers
write code and design the implementation of systems—that is what they are good at.
They are not good at understanding how people work, creating effective and intuitive
user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what
engineers do best. The weakness of agile methods is that they give little guidance in
figuring out what to tell the engineers to do.

Core Team: Possible agile solutions would be to start with a core team which builds out a simple business case in a test-driven manner. This first phase will build out enough of most of the architecture. With a small team, a full agile methodology works without modification. When a significant portion of the architecture is built, it is time to divide the project by growing the development team and splitting up into smaller subteams to grow the project into a fully functional software system.

Role of an architect: While there is no traditional architect role in most agile development methodologies, in large teams, it is often beneficial to reintroduce a modified version of this role. The architect is a member of the team with significant design and development talent and experience and he has to understand the ‘whole’ application code-base. The architect is hands-on and pairs with others on the team frequently and will be a participant in many agile modeling design sessions on the whiteboard. This helps keep away redundancies.

Continuous Integration: While each sub-team will have their own build running, agile methodology suggests having a 'brain' team that will have to create a master build that builds all sub-teams code and/or deploy their binary files. The master build will run frequently by pulling down the last successful builds for sub projects, compile and deploy the whole project and run the tests. In case of failure the brain team has to identify the problem and resolve it or take it to the responsible sub team to resolve it.

Refactoring: In large projects Refactoring sometimes becomes very expensive process and may take a month to be done. Some design ahead may be done to save expensive major refactoring later. For the conquer team when it’s still early on the project, to avoid large complicated refactoring some extra time should be spent for designing for future known requirements. Having the overall picture of use cases will make it easier to predict future requirements and create a design that will handle them. This design ahead is allowed only during the conquer phase of the project and will only apply to core systems, frameworks and similar subsystems of the system which may be more expensive to be re-factored.

Tests: To reduce the coast of refactoring, the team may depend on functional tests more than unit tests. Functional tests test the functionality of the system and in general do not depend on the system design. Unit tests should still be created for test driven development and for critical pieces of the system that may cause the system to break. Tests that are created after the development and tests created for reported bugs should be functional tests. Having less unit tests will lead to more time spent in debugging issues and functional tests cannot pin point problems but having a better design through constant refactoring will reduce the development time much more than the extra time being spent in debugging issues. Functional test should be documented in each test to describe the test scenario, expected results and differences between test scenarios.

These are some of the recommended practices that will help mediate some of the problems in applying agile design methodologies to projects. There are also some difficulties with applying these practices such as with the master build, with communication between teams, with extreme designing to get useless frameworks, and care should be taken to avoid them.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-17T15:12:21Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can complement other design methodologies. Section 1 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 2 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 3 takes up a few design methodologies and focuses on how agile complements them.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

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

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Study of a few Design methodologies and How Agile Complements Them==

===Separating Design from Engineering ===

Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers
write code and design the implementation of systems—that is what they are good at.
They are not good at understanding how people work, creating effective and intuitive
user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what
engineers do best. The weakness of agile methods is that they give little guidance in
figuring out what to tell the engineers to do.

Core Team: Possible agile solutions would be to start with a core team which builds out a simple business case in a test-driven manner. This first phase will build out enough of most of the architecture. With a small team, a full agile methodology works without modification. When a significant portion of the architecture is built, it is time to divide the project by growing the development team and splitting up into smaller subteams to grow the project into a fully functional software system.

Role of an architect: While there is no traditional architect role in most agile development methodologies, in large teams, it is often beneficial to reintroduce a modified version of this role. The architect is a member of the team with significant design and development talent and experience and he has to understand the ‘whole’ application code-base. The architect is hands-on and pairs with others on the team frequently and will be a participant in many agile modeling design sessions on the whiteboard. This helps keep away redundancies.

Continuous Integration: While each sub-team will have their own build running, agile methodology suggests having a 'brain' team that will have to create a master build that builds all sub-teams code and/or deploy their binary files. The master build will run frequently by pulling down the last successful builds for sub projects, compile and deploy the whole project and run the tests. In case of failure the brain team has to identify the problem and resolve it or take it to the responsible sub team to resolve it.

Refactoring: In large projects Refactoring sometimes becomes very expensive process and may take a month to be done. Some design ahead may be done to save expensive major refactoring later. For the conquer team when it’s still early on the project, to avoid large complicated refactoring some extra time should be spent for designing for future known requirements. Having the overall picture of use cases will make it easier to predict future requirements and create a design that will handle them. This design ahead is allowed only during the conquer phase of the project and will only apply to core systems, frameworks and similar subsystems of the system which may be more expensive to be re-factored.

Tests: To reduce the coast of refactoring, the team may depend on functional tests more than unit tests. Functional tests test the functionality of the system and in general do not depend on the system design. Unit tests should still be created for test driven development and for critical pieces of the system that may cause the system to break. Tests that are created after the development and tests created for reported bugs should be functional tests. Having less unit tests will lead to more time spent in debugging issues and functional tests cannot pin point problems but having a better design through constant refactoring will reduce the development time much more than the extra time being spent in debugging issues. Functional test should be documented in each test to describe the test scenario, expected results and differences between test scenarios.

These are some of the recommended practices that will help mediate some of the problems in applying agile design methodologies to projects. There are also some difficulties with applying these practices such as with the master build, with communication between teams, with extreme designing to get useless frameworks, and care should be taken to avoid them.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-17T15:12:01Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can complement other design methodologies. Section 1 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 2 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 3 takes up a few design methodologies and focuses on how agile complements them.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

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

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Study of a few Design methodologies and How Agile Complements Them==

===Separating Design from Engineering ===

Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers
write code and design the implementation of systems—that is what they are good at.
They are not good at understanding how people work, creating effective and intuitive
user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what
engineers do best. The weakness of agile methods is that they give little guidance in
figuring out what to tell the engineers to do.

Core Team: Possible agile solutions would be to start with a core team which builds out a simple business case in a test-driven manner. This first phase will build out enough of most of the architecture. With a small team, a full agile methodology works without modification. When a significant portion of the architecture is built, it is time to divide the project by growing the development team and splitting up into smaller subteams to grow the project into a fully functional software system.

Role of an architect: While there is no traditional architect role in most agile development methodologies, in large teams, it is often beneficial to reintroduce a modified version of this role. The architect is a member of the team with significant design and development talent and experience and he has to understand the ‘whole’ application code-base. The architect is hands-on and pairs with others on the team frequently and will be a participant in many agile modeling design sessions on the whiteboard. This helps keep away redundancies.

Continuous Integration: While each sub-team will have their own build running, agile methodology suggests having a 'brain' team that will have to create a master build that builds all sub-teams code and/or deploy their binary files. The master build will run frequently by pulling down the last successful builds for sub projects, compile and deploy the whole project and run the tests. In case of failure the brain team has to identify the problem and resolve it or take it to the responsible sub team to resolve it.

Refactoring: In large projects Refactoring sometimes becomes very expensive process and may take a month to be done. Some design ahead may be done to save expensive major refactoring later. For the conquer team when it’s still early on the project, to avoid large complicated refactoring some extra time should be spent for designing for future known requirements. Having the overall picture of use cases will make it easier to predict future requirements and create a design that will handle them. This design ahead is allowed only during the conquer phase of the project and will only apply to core systems, frameworks and similar subsystems of the system which may be more expensive to be re-factored.

Tests: To reduce the coast of refactoring, the team may depend on functional tests more than unit tests. Functional tests test the functionality of the system and in general do not depend on the system design. Unit tests should still be created for test driven development and for critical pieces of the system that may cause the system to break. Tests that are created after the development and tests created for reported bugs should be functional tests. Having less unit tests will lead to more time spent in debugging issues and functional tests cannot pin point problems but having a better design through constant refactoring will reduce the development time much more than the extra time being spent in debugging issues. Functional test should be documented in each test to describe the test scenario, expected results and differences between test scenarios.

These are some of the recommended practices that will help mediate some of the problems in applying agile design methodologies to projects. There are also some difficulties with applying these practices such as with the master build, with communication between teams, with extreme designing to get useless frameworks, and care should be taken to avoid them.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki3 7 f1

2009-11-17T15:10:23Z

Moonriver:

This wikipedia article focuses on how [http://en.wikipedia.org/wiki/Agile_software_development Agile] software development methodology can complement other design methodologies. Section 1 highlights the advantage of agile over traditional models, like the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model]. Section 2 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 3 takes up a few design methodologies and focuses on how agile complements them.

== Agile vs Traditional Methodologies ==

The agile manifesto focuses on

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

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

===Advantages of the agile method===

* Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

* Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

* Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

* Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

* However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

==Challenges in Applying Agile Methodologies==

* [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

* Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as [http://en.wikipedia.org/wiki/Contextual_design Contextual Design] to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

== Study of a few Design methodologies and How Agile Complements Them==

===Separating Design from Engineering ===

Much of the distinctiveness (and much of the value) of agile methods comes from the
clear separation of responsibilities they bring to the development process. Developers
write code and design the implementation of systems—that is what they are good at.
They are not good at understanding how people work, creating effective and intuitive
user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what
engineers do best. The weakness of agile methods is that they give little guidance in
figuring out what to tell the engineers to do.

Possible agile solutions would be to start with a core team which builds out a simple business case in a test-driven manner. This first phase will build out enough of most of the architecture. With a small team, a full agile methodology works without modification. When a significant portion of the architecture is built, it is time to divide the project by growing the development team and splitting up into smaller subteams to grow the project into a fully functional software system.

While there is no traditional architect role in most agile development methodologies, in large teams, it is often beneficial to reintroduce a modified version of this role. The architect is a member of the team with significant design and development talent and experience and he has to understand the ‘whole’ application code-base. The architect is hands-on and pairs with others on the team frequently and will be a participant in many agile modeling design sessions on the whiteboard. This helps keep away redundancies.

Continuous Integration: While each sub-team will have their own build running, agile methodology suggests having a 'brain' team that will have to create a master build that builds all sub-teams code and/or deploy their binary files. The master build will run frequently by pulling down the last successful builds for sub projects, compile and deploy the whole project and run the tests. In case of failure the brain team has to identify the problem and resolve it or take it to the responsible sub team to resolve it.

Refactoring: In large projects Refactoring sometimes becomes very expensive process and may take a month to be done. Some design ahead may be done to save expensive major refactoring later. For the conquer team when it’s still early on the project, to avoid large complicated refactoring some extra time should be spent for designing for future known requirements. Having the overall picture of use cases will make it easier to predict future requirements and create a design that will handle them. This design ahead is allowed only during the conquer phase of the project and will only apply to core systems, frameworks and similar subsystems of the system which may be more expensive to be re-factored.

Tests: To reduce the coast of refactoring, the team may depend on functional tests more than unit tests. Functional tests test the functionality of the system and in general do not depend on the system design. Unit tests should still be created for test driven development and for critical pieces of the system that may cause the system to break. Tests that are created after the development and tests created for reported bugs should be functional tests. Having less unit tests will lead to more time spent in debugging issues and functional tests cannot pin point problems but having a better design through constant refactoring will reduce the development time much more than the extra time being spent in debugging issues. Functional test should be documented in each test to describe the test scenario, expected results and differences between test scenarios.

These are some of the recommended practices that will help mediate some of the problems in applying agile design methodologies to projects. There are also some difficulties with applying these practices such as with the master build, with communication between teams, with extreme designing to get useless frameworks, and care should be taken to avoid them.

== References==

# [http://virtual.vtt.fi/virtual/xp2006/ XP 2006 Website]
# [http://www.agile200x.org/ Agile Development Conference]
# Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
# Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
# Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
# Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
# An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-13T15:45:25Z

Moonriver:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>