Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-19T03:01:48Z

Njdesai2: /* Adoption and Effectiveness of Agile Methodologies */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

[[File:AgileDevelopmentna.png]]

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

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

===Extreme Programming===
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

===Dynamic Systems Development Method===
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

===Crystal===
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

===Learn Software Development===
Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole.
Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

===Feature Driven Development===
FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results.
FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

===Other Methodologies===
Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue.
Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types.
Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

==Comparison of different agile methodologies==

[[File:Agile_comp.jpg]]

===Limitations of Agile Methodologies===
The biggest limitation of agile methodologies is how they handle larger teams. Cockburn and Highsmith both conclude that “Agile development is more difficult for larger teams…as size grows coordinating interfaces become a dominant issue,”. Both Larry Constantine and Martin Fowler also believe that agile with face-to-face communication breaks down and becomes more difficult and complex with developers more than 20. In contrast, heavyweight and plan-driven methods scale better to large projects.

Agile methodologies have a strong emphasis on customer involvement. The customer is considered as part of the development team throughout the whole development of the software. The Standish Group research topped this by providing the second most important factor for a project success is user involvement according to IT executive mangers opinion. According to Boehm, “Agile methods work best when such customers operate in dedicated mode with the development team, and when their tacit knowledge is sufficient for the full span of the application”. Again these methods risk tacit knowledge shortfall. If you have one customer participant then unless they are committed, knowledgeable, collaborative and empowered then there is some chance that you would have a unified set of requirements. However if you have many customers you would have different viewpoints and conflicts between them. This risk could be reduced in plan-driven methods by using documentation, planning, architecture reviews and independent expert project reviews to compensate for on-site customer negligence.

Another factor of agile methodologies that could cause problems is the interpretation of the agile manifesto principle, “Working Software over Comprehensive Documentation”. Boehm questions the applicability of agiles’ emphasis on simplicity. Based on XP’s concept of YAGNI precept: “You Aren’t Going to Need It,” believes that doing extra work to get rid of architectural features that do not support the current version. This might cause misconceptions for the developers. This approach can be useful when the future requirements are highly unpredictable. However where future requirements are predictable, Boehm states “this practice not only throws away valuable architecture support for them, it also creates problems with the customers who want developers to believe that their priorities and evolution requirements are worth accommodating”.

==Adoption and Effectiveness of Agile Methodologies==

'''Small team'''
-
Agile teams are restricted in size for several reasons:
The team has to self-organize, implying an efficient order emerging from
temporary chaos. Obviously this process would be too long for larger teams.

−
Team members have to be able to communicate spontaneously with each other
and with other stakeholders (i.e. without setting up meetings, sending emails,
etc.).

−
All team members participate in the day-to-day management (tasks, changes,
impediments, etc.).

−
Team members need to understand what others are doing (cross-functional
perspective, team ownership), help each other with ease, and collaborate without
centralized control.

−
The team has to be co-located (this limitation will be examined later).
As you can see, agile is a highly participative style of software development.
Therefore, the number of participants significantly affects the efficiency of the process.
The daily scrum of the Scrum agile methodology perfectly illustrates this limitation. The
daily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrum
word for team leader) goes around the table and each team member mentions the status
of tasks and other issues such as impediments or changes. I managed Scrum teams of
sizes varying from 3 to 8, and I must admit that in my opinion 8 is about the upper limit.
Beyond this size, communication becomes inefficient.
Assuming that large projects tend to require large teams, this restriction naturally
extends to project size.

'''Collocated team'''

Agile emphasizes that face-to-face, spontaneous conversation is the best form of
communication. While we can certainly agree on the benefits of this form of
communication, it severely limits agile applicability. Moreover, this agile principle extends
beyond the development team since other stakeholders such as business analysts are
required to be collocated.
What does it mean in practice? Imagine that a team member has a question concerninga use case. She should be able to get up, walk 10 meters, ask the business analyst orkey user for clarification, and get back to work. Consequently, office space has to bephysically arranged according to agile projects so that all stakeholders involved in dailyactivities are located at the same place (let's say within a minute of walking distance).
We can easily think of a number of situations where this limitation prevents using agile:

−
Office space organized by departments: In most organizations, offices are
organized by departments such as IT, marketing, accounting, sales, and so on.
Moving people around according to agile projects is unrealistic. Even if it was
possible, it would negatively affects other parts of the business.

−
Distributed environment: Developers are often distributed throughout the
organization, whether in the same branch or in different branches (or working
from home). Just like for the previous point, moving these people is unrealistic.

−
Subcontracting: Many organizations partly or completely outsource software
development. Assuming that some roles such as business analysts or key users
would be located at the company, this situation doesn't comply with the agile
collocation principle.

'''Team ownership vs. individual accountability'''

Agile development stresses the importance of team ownership in order to improve
teamwork and therefore overall results. Team ownership is a very appealing concept,
but how can we implement it since an organization's performance-reward system
assesses individual performance and rewards individuals, not teams?

If we rely exclusively on individual accountability, we tend to generate selfish behavior
that can affect teamwork. If we rely exclusively on team assessment, we overlook that
individuals perform differently in a given team, creating opportunities for underperforming
team members to get away with it and lessening incentives to perform in a superior way.
Obviously we have to find a way to take both these perspectives into account.
Actually this problem can be solved elegantly by defining two levels of performance-
reward:

−
Team level: The team is perceived as a single entity from management's point of
view. Management assesses teams' performance and allocates rewards to
teams in the form of points.

−
Individual level: Team leaders (or whatever the title is) evaluate teams
members rewarding them with points.
In order to have a short feedback loop, assessment should be done frequently (every
month for example) using a lightweight system incurring very little administrative
overhead.

Thanks to this kind of system, we encourage teamwork but we still take individual
contribution into account, effectively reaching a balance between team ownership and
individual accountability.

==Conclusion==

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements
facilitated by direct user involvement in the development process. Serena’s application lifecycle management
tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and
enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral
and can be applied equally well to agile as well as more traditional serial development processes, so
they can support all the development activities within an enterprise.

Any team could be agile, regardless of the team size, but size is an issue because more people make
communication harder. There is much experience from small teams. There is less for larger teams, for
which scale-up strategies need to be applied.

• Experience is important for an Agile project to succeed, but experience with actually building systems
is much more important than experience with Agile methods. It was estimated that 25%-33% of the
project personnel must be “competent and experienced”, but the necessary percentage might even be as
low as 10% if the teams practice pair programming due to the fact that they mentor each other.

• Reliable and safety-critical projects can be conducted using Agile Methods. The key is that performance
requirements are made explicit early, and proper levels of testing are planned. It is easier to address
critical issues using Agile Methods since the customer gives requirements, makes important
things explicit early and provides continual input.

• Agile Methods require less formal training than traditional methods. Pair programming helps minimize
what is needed in terms of training, because people mentor each other. This is more important than
regular training that can many times be completed as self-training. Training material is available in particular
for XP, Crystal, Scrum, and FDD.

• The three most important success factors are culture, people, and communication. Agile Methods need
cultural support otherwise they will not succeed. Competent team members are crucial. Agile Methods
use fewer, but more competent people. Physically co-located teams and pair programming support
rapid communication. Close interaction with the customer and frequent customer feedback are critical
success factors.

• Early warning signs can be spotted in Agile projects, e.g. low morale expressed during the daily meeting.
Other signs are production of “useless documentation” and delays of planned iterations.

• Refactoring should be done frequently and of reasonably sized code, keeping the scope down and local.
Large-scale refactoring is not a problem, and is more feasible using Agile Methods. Traditional
“BDUF” is a waste of time and doesn’t lead to a learning experience. Big architectural changes do not
need to be risky if a set of automated tests is maintained.

• Documentation should be assigned a cost and its extent be determined by the customer. Many
organizations demand more than is needed. The goal should be to communicate effectively and
documentation should be the last option.

==References==

http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

http://www.gatherspace.com/static/agile_software_development.html

http://www.agilesherpa.org/intro_to_agile/agile_methodologies/

http://www.agiledeveloper.com/presentations/AgileMethodologies.pdf

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-19T03:01:30Z

Njdesai2: /* Adoption and Effectiveness of Agile Methodologies */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-19T02:36:00Z

Njdesai2: /* Adoption and Effectiveness of Agile Methodologies */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

[[File:AgileDevelopmentna.png]]

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

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

===Extreme Programming===
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

===Dynamic Systems Development Method===
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

===Crystal===
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

===Learn Software Development===
Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole.
Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

===Feature Driven Development===
FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results.
FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

===Other Methodologies===
Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue.
Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types.
Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

==Comparison of different agile methodologies==

[[File:Agile_comp.jpg]]

===Limitations of Agile Methodologies===
The biggest limitation of agile methodologies is how they handle larger teams. Cockburn and Highsmith both conclude that “Agile development is more difficult for larger teams…as size grows coordinating interfaces become a dominant issue,”. Both Larry Constantine and Martin Fowler also believe that agile with face-to-face communication breaks down and becomes more difficult and complex with developers more than 20. In contrast, heavyweight and plan-driven methods scale better to large projects.

Agile methodologies have a strong emphasis on customer involvement. The customer is considered as part of the development team throughout the whole development of the software. The Standish Group research topped this by providing the second most important factor for a project success is user involvement according to IT executive mangers opinion. According to Boehm, “Agile methods work best when such customers operate in dedicated mode with the development team, and when their tacit knowledge is sufficient for the full span of the application”. Again these methods risk tacit knowledge shortfall. If you have one customer participant then unless they are committed, knowledgeable, collaborative and empowered then there is some chance that you would have a unified set of requirements. However if you have many customers you would have different viewpoints and conflicts between them. This risk could be reduced in plan-driven methods by using documentation, planning, architecture reviews and independent expert project reviews to compensate for on-site customer negligence.

Another factor of agile methodologies that could cause problems is the interpretation of the agile manifesto principle, “Working Software over Comprehensive Documentation”. Boehm questions the applicability of agiles’ emphasis on simplicity. Based on XP’s concept of YAGNI precept: “You Aren’t Going to Need It,” believes that doing extra work to get rid of architectural features that do not support the current version. This might cause misconceptions for the developers. This approach can be useful when the future requirements are highly unpredictable. However where future requirements are predictable, Boehm states “this practice not only throws away valuable architecture support for them, it also creates problems with the customers who want developers to believe that their priorities and evolution requirements are worth accommodating”.

==Adoption and Effectiveness of Agile Methodologies==

'''Small team'''
-
Agile teams are restricted in size for several reasons:
The team has to self-organize, implying an efficient order emerging from
temporary chaos. Obviously this process would be too long for larger teams.

−
Team members have to be able to communicate spontaneously with each other
and with other stakeholders (i.e. without setting up meetings, sending emails,
etc.).

−
All team members participate in the day-to-day management (tasks, changes,
impediments, etc.).

−
Team members need to understand what others are doing (cross-functional
perspective, team ownership), help each other with ease, and collaborate without
centralized control.

−
The team has to be co-located (this limitation will be examined later).
As you can see, agile is a highly participative style of software development.
Therefore, the number of participants significantly affects the efficiency of the process.
The daily scrum of the Scrum agile methodology perfectly illustrates this limitation. The
daily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrum
word for team leader) goes around the table and each team member mentions the status
of tasks and other issues such as impediments or changes. I managed Scrum teams of
sizes varying from 3 to 8, and I must admit that in my opinion 8 is about the upper limit.
Beyond this size, communication becomes inefficient.
Assuming that large projects tend to require large teams, this restriction naturally
extends to project size.

'''Collocated team'''

Agile emphasizes that face-to-face, spontaneous conversation is the best form of
communication. While we can certainly agree on the benefits of this form of
communication, it severely limits agile applicability. Moreover, this agile principle extends
beyond the development team since other stakeholders such as business analysts are
required to be collocated.
What does it mean in practice? Imagine that a team member has a question concerninga use case. She should be able to get up, walk 10 meters, ask the business analyst orkey user for clarification, and get back to work. Consequently, office space has to bephysically arranged according to agile projects so that all stakeholders involved in dailyactivities are located at the same place (let's say within a minute of walking distance).
We can easily think of a number of situations where this limitation prevents using agile:

−
Office space organized by departments: In most organizations, offices are
organized by departments such as IT, marketing, accounting, sales, and so on.
Moving people around according to agile projects is unrealistic. Even if it was
possible, it would negatively affects other parts of the business.

−
Distributed environment: Developers are often distributed throughout the
organization, whether in the same branch or in different branches (or working
from home). Just like for the previous point, moving these people is unrealistic.

−
Subcontracting: Many organizations partly or completely outsource software
development. Assuming that some roles such as business analysts or key users
would be located at the company, this situation doesn't comply with the agile
collocation principle.

==Conclusion==

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements
facilitated by direct user involvement in the development process. Serena’s application lifecycle management
tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and
enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral
and can be applied equally well to agile as well as more traditional serial development processes, so
they can support all the development activities within an enterprise.

Any team could be agile, regardless of the team size, but size is an issue because more people make
communication harder. There is much experience from small teams. There is less for larger teams, for
which scale-up strategies need to be applied.

• Experience is important for an Agile project to succeed, but experience with actually building systems
is much more important than experience with Agile methods. It was estimated that 25%-33% of the
project personnel must be “competent and experienced”, but the necessary percentage might even be as
low as 10% if the teams practice pair programming due to the fact that they mentor each other.

• Reliable and safety-critical projects can be conducted using Agile Methods. The key is that performance
requirements are made explicit early, and proper levels of testing are planned. It is easier to address
critical issues using Agile Methods since the customer gives requirements, makes important
things explicit early and provides continual input.

• Agile Methods require less formal training than traditional methods. Pair programming helps minimize
what is needed in terms of training, because people mentor each other. This is more important than
regular training that can many times be completed as self-training. Training material is available in particular
for XP, Crystal, Scrum, and FDD.

• The three most important success factors are culture, people, and communication. Agile Methods need
cultural support otherwise they will not succeed. Competent team members are crucial. Agile Methods
use fewer, but more competent people. Physically co-located teams and pair programming support
rapid communication. Close interaction with the customer and frequent customer feedback are critical
success factors.

• Early warning signs can be spotted in Agile projects, e.g. low morale expressed during the daily meeting.
Other signs are production of “useless documentation” and delays of planned iterations.

• Refactoring should be done frequently and of reasonably sized code, keeping the scope down and local.
Large-scale refactoring is not a problem, and is more feasible using Agile Methods. Traditional
“BDUF” is a waste of time and doesn’t lead to a learning experience. Big architectural changes do not
need to be risky if a set of automated tests is maintained.

• Documentation should be assigned a cost and its extent be determined by the customer. Many
organizations demand more than is needed. The goal should be to communicate effectively and
documentation should be the last option.

==References==

http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

http://www.gatherspace.com/static/agile_software_development.html

http://www.agilesherpa.org/intro_to_agile/agile_methodologies/

http://www.agiledeveloper.com/presentations/AgileMethodologies.pdf

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-19T02:33:52Z

Njdesai2: /* Adoption and Effectiveness of Agile Methodologies */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

[[File:AgileDevelopmentna.png]]

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

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

===Extreme Programming===
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

===Dynamic Systems Development Method===
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

===Crystal===
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

===Learn Software Development===
Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole.
Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

===Feature Driven Development===
FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results.
FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

===Other Methodologies===
Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue.
Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types.
Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

==Comparison of different agile methodologies==

[[File:Agile_comp.jpg]]

===Limitations of Agile Methodologies===
The biggest limitation of agile methodologies is how they handle larger teams. Cockburn and Highsmith both conclude that “Agile development is more difficult for larger teams…as size grows coordinating interfaces become a dominant issue,”. Both Larry Constantine and Martin Fowler also believe that agile with face-to-face communication breaks down and becomes more difficult and complex with developers more than 20. In contrast, heavyweight and plan-driven methods scale better to large projects.

Agile methodologies have a strong emphasis on customer involvement. The customer is considered as part of the development team throughout the whole development of the software. The Standish Group research topped this by providing the second most important factor for a project success is user involvement according to IT executive mangers opinion. According to Boehm, “Agile methods work best when such customers operate in dedicated mode with the development team, and when their tacit knowledge is sufficient for the full span of the application”. Again these methods risk tacit knowledge shortfall. If you have one customer participant then unless they are committed, knowledgeable, collaborative and empowered then there is some chance that you would have a unified set of requirements. However if you have many customers you would have different viewpoints and conflicts between them. This risk could be reduced in plan-driven methods by using documentation, planning, architecture reviews and independent expert project reviews to compensate for on-site customer negligence.

Another factor of agile methodologies that could cause problems is the interpretation of the agile manifesto principle, “Working Software over Comprehensive Documentation”. Boehm questions the applicability of agiles’ emphasis on simplicity. Based on XP’s concept of YAGNI precept: “You Aren’t Going to Need It,” believes that doing extra work to get rid of architectural features that do not support the current version. This might cause misconceptions for the developers. This approach can be useful when the future requirements are highly unpredictable. However where future requirements are predictable, Boehm states “this practice not only throws away valuable architecture support for them, it also creates problems with the customers who want developers to believe that their priorities and evolution requirements are worth accommodating”.

==Adoption and Effectiveness of Agile Methodologies==

'''Small team'''
-
Agile teams are restricted in size for several reasons:
The team has to self-organize, implying an efficient order emerging from
temporary chaos. Obviously this process would be too long for larger teams.

−
Team members have to be able to communicate spontaneously with each other
and with other stakeholders (i.e. without setting up meetings, sending emails,
etc.).

−
All team members participate in the day-to-day management (tasks, changes,
impediments, etc.).

−
Team members need to understand what others are doing (cross-functional
perspective, team ownership), help each other with ease, and collaborate without
centralized control.

−
The team has to be co-located (this limitation will be examined later).
As you can see, agile is a highly participative style of software development.
Therefore, the number of participants significantly affects the efficiency of the process.
The daily scrum of the Scrum agile methodology perfectly illustrates this limitation. The
daily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrum
word for team leader) goes around the table and each team member mentions the status
of tasks and other issues such as impediments or changes. I managed Scrum teams of
sizes varying from 3 to 8, and I must admit that in my opinion 8 is about the upper limit.
Beyond this size, communication becomes inefficient.
Assuming that large projects tend to require large teams, this restriction naturally
extends to project size.

==Conclusion==

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements
facilitated by direct user involvement in the development process. Serena’s application lifecycle management
tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and
enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral
and can be applied equally well to agile as well as more traditional serial development processes, so
they can support all the development activities within an enterprise.

Any team could be agile, regardless of the team size, but size is an issue because more people make
communication harder. There is much experience from small teams. There is less for larger teams, for
which scale-up strategies need to be applied.

• Experience is important for an Agile project to succeed, but experience with actually building systems
is much more important than experience with Agile methods. It was estimated that 25%-33% of the
project personnel must be “competent and experienced”, but the necessary percentage might even be as
low as 10% if the teams practice pair programming due to the fact that they mentor each other.

• Reliable and safety-critical projects can be conducted using Agile Methods. The key is that performance
requirements are made explicit early, and proper levels of testing are planned. It is easier to address
critical issues using Agile Methods since the customer gives requirements, makes important
things explicit early and provides continual input.

• Agile Methods require less formal training than traditional methods. Pair programming helps minimize
what is needed in terms of training, because people mentor each other. This is more important than
regular training that can many times be completed as self-training. Training material is available in particular
for XP, Crystal, Scrum, and FDD.

• The three most important success factors are culture, people, and communication. Agile Methods need
cultural support otherwise they will not succeed. Competent team members are crucial. Agile Methods
use fewer, but more competent people. Physically co-located teams and pair programming support
rapid communication. Close interaction with the customer and frequent customer feedback are critical
success factors.

• Early warning signs can be spotted in Agile projects, e.g. low morale expressed during the daily meeting.
Other signs are production of “useless documentation” and delays of planned iterations.

• Refactoring should be done frequently and of reasonably sized code, keeping the scope down and local.
Large-scale refactoring is not a problem, and is more feasible using Agile Methods. Traditional
“BDUF” is a waste of time and doesn’t lead to a learning experience. Big architectural changes do not
need to be risky if a set of automated tests is maintained.

• Documentation should be assigned a cost and its extent be determined by the customer. Many
organizations demand more than is needed. The goal should be to communicate effectively and
documentation should be the last option.

==References==

http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

http://www.gatherspace.com/static/agile_software_development.html

http://www.agilesherpa.org/intro_to_agile/agile_methodologies/

http://www.agiledeveloper.com/presentations/AgileMethodologies.pdf

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-19T02:33:27Z

Njdesai2: /* Adoption and Effectiveness of Agile Methodologies */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

[[File:AgileDevelopmentna.png]]

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

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

===Extreme Programming===
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

===Dynamic Systems Development Method===
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

===Crystal===
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

===Learn Software Development===
Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole.
Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

===Feature Driven Development===
FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results.
FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

===Other Methodologies===
Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue.
Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types.
Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

==Comparison of different agile methodologies==

[[File:Agile_comp.jpg]]

===Limitations of Agile Methodologies===
The biggest limitation of agile methodologies is how they handle larger teams. Cockburn and Highsmith both conclude that “Agile development is more difficult for larger teams…as size grows coordinating interfaces become a dominant issue,”. Both Larry Constantine and Martin Fowler also believe that agile with face-to-face communication breaks down and becomes more difficult and complex with developers more than 20. In contrast, heavyweight and plan-driven methods scale better to large projects.

Agile methodologies have a strong emphasis on customer involvement. The customer is considered as part of the development team throughout the whole development of the software. The Standish Group research topped this by providing the second most important factor for a project success is user involvement according to IT executive mangers opinion. According to Boehm, “Agile methods work best when such customers operate in dedicated mode with the development team, and when their tacit knowledge is sufficient for the full span of the application”. Again these methods risk tacit knowledge shortfall. If you have one customer participant then unless they are committed, knowledgeable, collaborative and empowered then there is some chance that you would have a unified set of requirements. However if you have many customers you would have different viewpoints and conflicts between them. This risk could be reduced in plan-driven methods by using documentation, planning, architecture reviews and independent expert project reviews to compensate for on-site customer negligence.

Another factor of agile methodologies that could cause problems is the interpretation of the agile manifesto principle, “Working Software over Comprehensive Documentation”. Boehm questions the applicability of agiles’ emphasis on simplicity. Based on XP’s concept of YAGNI precept: “You Aren’t Going to Need It,” believes that doing extra work to get rid of architectural features that do not support the current version. This might cause misconceptions for the developers. This approach can be useful when the future requirements are highly unpredictable. However where future requirements are predictable, Boehm states “this practice not only throws away valuable architecture support for them, it also creates problems with the customers who want developers to believe that their priorities and evolution requirements are worth accommodating”.

==Adoption and Effectiveness of Agile Methodologies==

Small team
-
Agile teams are restricted in size for several reasons:
The team has to self-organize, implying an efficient order emerging from
temporary chaos. Obviously this process would be too long for larger teams.
−
Team members have to be able to communicate spontaneously with each other
and with other stakeholders (i.e. without setting up meetings, sending emails,
etc.).
−
All team members participate in the day-to-day management (tasks, changes,
impediments, etc.).
−
Team members need to understand what others are doing (cross-functional
perspective, team ownership), help each other with ease, and collaborate without
centralized control.
−
The team has to be co-located (this limitation will be examined later).
As you can see, agile is a highly participative style of software development.
Therefore, the number of participants significantly affects the efficiency of the process.
The daily scrum of the Scrum agile methodology perfectly illustrates this limitation. The
daily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrum
word for team leader) goes around the table and each team member mentions the status
of tasks and other issues such as impediments or changes. I managed Scrum teams of
sizes varying from 3 to 8, and I must admit that in my opinion 8 is about the upper limit.
Beyond this size, communication becomes inefficient.
Assuming that large projects tend to require large teams, this restriction naturally
extends to project size.

==Conclusion==

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements
facilitated by direct user involvement in the development process. Serena’s application lifecycle management
tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and
enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral
and can be applied equally well to agile as well as more traditional serial development processes, so
they can support all the development activities within an enterprise.

Any team could be agile, regardless of the team size, but size is an issue because more people make
communication harder. There is much experience from small teams. There is less for larger teams, for
which scale-up strategies need to be applied.

• Experience is important for an Agile project to succeed, but experience with actually building systems
is much more important than experience with Agile methods. It was estimated that 25%-33% of the
project personnel must be “competent and experienced”, but the necessary percentage might even be as
low as 10% if the teams practice pair programming due to the fact that they mentor each other.

• Reliable and safety-critical projects can be conducted using Agile Methods. The key is that performance
requirements are made explicit early, and proper levels of testing are planned. It is easier to address
critical issues using Agile Methods since the customer gives requirements, makes important
things explicit early and provides continual input.

• Agile Methods require less formal training than traditional methods. Pair programming helps minimize
what is needed in terms of training, because people mentor each other. This is more important than
regular training that can many times be completed as self-training. Training material is available in particular
for XP, Crystal, Scrum, and FDD.

• The three most important success factors are culture, people, and communication. Agile Methods need
cultural support otherwise they will not succeed. Competent team members are crucial. Agile Methods
use fewer, but more competent people. Physically co-located teams and pair programming support
rapid communication. Close interaction with the customer and frequent customer feedback are critical
success factors.

• Early warning signs can be spotted in Agile projects, e.g. low morale expressed during the daily meeting.
Other signs are production of “useless documentation” and delays of planned iterations.

• Refactoring should be done frequently and of reasonably sized code, keeping the scope down and local.
Large-scale refactoring is not a problem, and is more feasible using Agile Methods. Traditional
“BDUF” is a waste of time and doesn’t lead to a learning experience. Big architectural changes do not
need to be risky if a set of automated tests is maintained.

• Documentation should be assigned a cost and its extent be determined by the customer. Many
organizations demand more than is needed. The goal should be to communicate effectively and
documentation should be the last option.

==References==

http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

http://www.gatherspace.com/static/agile_software_development.html

http://www.agilesherpa.org/intro_to_agile/agile_methodologies/

http://www.agiledeveloper.com/presentations/AgileMethodologies.pdf

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-19T02:27:59Z

Njdesai2: /* Introduction to Agile Software Development */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

[[File:AgileDevelopmentna.png]]

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

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

===Extreme Programming===
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

===Dynamic Systems Development Method===
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

===Crystal===
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

===Learn Software Development===
Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole.
Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

===Feature Driven Development===
FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results.
FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

===Other Methodologies===
Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue.
Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types.
Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

==Comparison of different agile methodologies==

[[File:Agile_comp.jpg]]

===Limitations of Agile Methodologies===
The biggest limitation of agile methodologies is how they handle larger teams. Cockburn and Highsmith both conclude that “Agile development is more difficult for larger teams…as size grows coordinating interfaces become a dominant issue,”. Both Larry Constantine and Martin Fowler also believe that agile with face-to-face communication breaks down and becomes more difficult and complex with developers more than 20. In contrast, heavyweight and plan-driven methods scale better to large projects.

Agile methodologies have a strong emphasis on customer involvement. The customer is considered as part of the development team throughout the whole development of the software. The Standish Group research topped this by providing the second most important factor for a project success is user involvement according to IT executive mangers opinion. According to Boehm, “Agile methods work best when such customers operate in dedicated mode with the development team, and when their tacit knowledge is sufficient for the full span of the application”. Again these methods risk tacit knowledge shortfall. If you have one customer participant then unless they are committed, knowledgeable, collaborative and empowered then there is some chance that you would have a unified set of requirements. However if you have many customers you would have different viewpoints and conflicts between them. This risk could be reduced in plan-driven methods by using documentation, planning, architecture reviews and independent expert project reviews to compensate for on-site customer negligence.

Another factor of agile methodologies that could cause problems is the interpretation of the agile manifesto principle, “Working Software over Comprehensive Documentation”. Boehm questions the applicability of agiles’ emphasis on simplicity. Based on XP’s concept of YAGNI precept: “You Aren’t Going to Need It,” believes that doing extra work to get rid of architectural features that do not support the current version. This might cause misconceptions for the developers. This approach can be useful when the future requirements are highly unpredictable. However where future requirements are predictable, Boehm states “this practice not only throws away valuable architecture support for them, it also creates problems with the customers who want developers to believe that their priorities and evolution requirements are worth accommodating”.

==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements
facilitated by direct user involvement in the development process. Serena’s application lifecycle management
tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and
enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral
and can be applied equally well to agile as well as more traditional serial development processes, so
they can support all the development activities within an enterprise.

Any team could be agile, regardless of the team size, but size is an issue because more people make
communication harder. There is much experience from small teams. There is less for larger teams, for
which scale-up strategies need to be applied.

• Experience is important for an Agile project to succeed, but experience with actually building systems
is much more important than experience with Agile methods. It was estimated that 25%-33% of the
project personnel must be “competent and experienced”, but the necessary percentage might even be as
low as 10% if the teams practice pair programming due to the fact that they mentor each other.

• Reliable and safety-critical projects can be conducted using Agile Methods. The key is that performance
requirements are made explicit early, and proper levels of testing are planned. It is easier to address
critical issues using Agile Methods since the customer gives requirements, makes important
things explicit early and provides continual input.

• Agile Methods require less formal training than traditional methods. Pair programming helps minimize
what is needed in terms of training, because people mentor each other. This is more important than
regular training that can many times be completed as self-training. Training material is available in particular
for XP, Crystal, Scrum, and FDD.

• The three most important success factors are culture, people, and communication. Agile Methods need
cultural support otherwise they will not succeed. Competent team members are crucial. Agile Methods
use fewer, but more competent people. Physically co-located teams and pair programming support
rapid communication. Close interaction with the customer and frequent customer feedback are critical
success factors.

• Early warning signs can be spotted in Agile projects, e.g. low morale expressed during the daily meeting.
Other signs are production of “useless documentation” and delays of planned iterations.

• Refactoring should be done frequently and of reasonably sized code, keeping the scope down and local.
Large-scale refactoring is not a problem, and is more feasible using Agile Methods. Traditional
“BDUF” is a waste of time and doesn’t lead to a learning experience. Big architectural changes do not
need to be risky if a set of automated tests is maintained.

• Documentation should be assigned a cost and its extent be determined by the customer. Many
organizations demand more than is needed. The goal should be to communicate effectively and
documentation should be the last option.

==References==

http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

http://www.gatherspace.com/static/agile_software_development.html

http://www.agilesherpa.org/intro_to_agile/agile_methodologies/

http://www.agiledeveloper.com/presentations/AgileMethodologies.pdf

File:AgileDevelopmentna.png

2011-11-19T02:25:52Z

Njdesai2:

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T04:08:10Z

Njdesai2: /* Conclusion */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

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

===Extreme Programming===
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

===Dynamic Systems Development Method===
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

===Crystal===
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

===Learn Software Development===
Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole.
Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

===Feature Driven Development===
FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results.
FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

===Other Methodologies===
Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue.
Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types.
Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

==Comparison of different agile methodologies==

[[File:Agile_comp.jpg]]

===Limitations of Agile Methodologies===
The biggest limitation of agile methodologies is how they handle larger teams. Cockburn and Highsmith both conclude that “Agile development is more difficult for larger teams…as size grows coordinating interfaces become a dominant issue,”. Both Larry Constantine and Martin Fowler also believe that agile with face-to-face communication breaks down and becomes more difficult and complex with developers more than 20. In contrast, heavyweight and plan-driven methods scale better to large projects.

Agile methodologies have a strong emphasis on customer involvement. The customer is considered as part of the development team throughout the whole development of the software. The Standish Group research topped this by providing the second most important factor for a project success is user involvement according to IT executive mangers opinion. According to Boehm, “Agile methods work best when such customers operate in dedicated mode with the development team, and when their tacit knowledge is sufficient for the full span of the application”. Again these methods risk tacit knowledge shortfall. If you have one customer participant then unless they are committed, knowledgeable, collaborative and empowered then there is some chance that you would have a unified set of requirements. However if you have many customers you would have different viewpoints and conflicts between them. This risk could be reduced in plan-driven methods by using documentation, planning, architecture reviews and independent expert project reviews to compensate for on-site customer negligence.

Another factor of agile methodologies that could cause problems is the interpretation of the agile manifesto principle, “Working Software over Comprehensive Documentation”. Boehm questions the applicability of agiles’ emphasis on simplicity. Based on XP’s concept of YAGNI precept: “You Aren’t Going to Need It,” believes that doing extra work to get rid of architectural features that do not support the current version. This might cause misconceptions for the developers. This approach can be useful when the future requirements are highly unpredictable. However where future requirements are predictable, Boehm states “this practice not only throws away valuable architecture support for them, it also creates problems with the customers who want developers to believe that their priorities and evolution requirements are worth accommodating”.

==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements
facilitated by direct user involvement in the development process. Serena’s application lifecycle management
tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and
enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral
and can be applied equally well to agile as well as more traditional serial development processes, so
they can support all the development activities within an enterprise.

Any team could be agile, regardless of the team size, but size is an issue because more people make
communication harder. There is much experience from small teams. There is less for larger teams, for
which scale-up strategies need to be applied.

• Experience is important for an Agile project to succeed, but experience with actually building systems
is much more important than experience with Agile methods. It was estimated that 25%-33% of the
project personnel must be “competent and experienced”, but the necessary percentage might even be as
low as 10% if the teams practice pair programming due to the fact that they mentor each other.

• Reliable and safety-critical projects can be conducted using Agile Methods. The key is that performance
requirements are made explicit early, and proper levels of testing are planned. It is easier to address
critical issues using Agile Methods since the customer gives requirements, makes important
things explicit early and provides continual input.

• Agile Methods require less formal training than traditional methods. Pair programming helps minimize
what is needed in terms of training, because people mentor each other. This is more important than
regular training that can many times be completed as self-training. Training material is available in particular
for XP, Crystal, Scrum, and FDD.

• The three most important success factors are culture, people, and communication. Agile Methods need
cultural support otherwise they will not succeed. Competent team members are crucial. Agile Methods
use fewer, but more competent people. Physically co-located teams and pair programming support
rapid communication. Close interaction with the customer and frequent customer feedback are critical
success factors.

• Early warning signs can be spotted in Agile projects, e.g. low morale expressed during the daily meeting.
Other signs are production of “useless documentation” and delays of planned iterations.

• Refactoring should be done frequently and of reasonably sized code, keeping the scope down and local.
Large-scale refactoring is not a problem, and is more feasible using Agile Methods. Traditional
“BDUF” is a waste of time and doesn’t lead to a learning experience. Big architectural changes do not
need to be risky if a set of automated tests is maintained.

• Documentation should be assigned a cost and its extent be determined by the customer. Many
organizations demand more than is needed. The goal should be to communicate effectively and
documentation should be the last option.

==References==

http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

http://www.gatherspace.com/static/agile_software_development.html

http://www.agilesherpa.org/intro_to_agile/agile_methodologies/

http://www.agiledeveloper.com/presentations/AgileMethodologies.pdf

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T04:07:49Z

Njdesai2: /* Conclusion */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

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

===Extreme Programming===
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

===Dynamic Systems Development Method===
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

===Crystal===
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

===Learn Software Development===
Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole.
Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

===Feature Driven Development===
FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results.
FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

===Other Methodologies===
Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue.
Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types.
Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

==Comparison of different agile methodologies==

[[File:Agile_comp.jpg]]

===Limitations of Agile Methodologies===
The biggest limitation of agile methodologies is how they handle larger teams. Cockburn and Highsmith both conclude that “Agile development is more difficult for larger teams…as size grows coordinating interfaces become a dominant issue,”. Both Larry Constantine and Martin Fowler also believe that agile with face-to-face communication breaks down and becomes more difficult and complex with developers more than 20. In contrast, heavyweight and plan-driven methods scale better to large projects.

Agile methodologies have a strong emphasis on customer involvement. The customer is considered as part of the development team throughout the whole development of the software. The Standish Group research topped this by providing the second most important factor for a project success is user involvement according to IT executive mangers opinion. According to Boehm, “Agile methods work best when such customers operate in dedicated mode with the development team, and when their tacit knowledge is sufficient for the full span of the application”. Again these methods risk tacit knowledge shortfall. If you have one customer participant then unless they are committed, knowledgeable, collaborative and empowered then there is some chance that you would have a unified set of requirements. However if you have many customers you would have different viewpoints and conflicts between them. This risk could be reduced in plan-driven methods by using documentation, planning, architecture reviews and independent expert project reviews to compensate for on-site customer negligence.

Another factor of agile methodologies that could cause problems is the interpretation of the agile manifesto principle, “Working Software over Comprehensive Documentation”. Boehm questions the applicability of agiles’ emphasis on simplicity. Based on XP’s concept of YAGNI precept: “You Aren’t Going to Need It,” believes that doing extra work to get rid of architectural features that do not support the current version. This might cause misconceptions for the developers. This approach can be useful when the future requirements are highly unpredictable. However where future requirements are predictable, Boehm states “this practice not only throws away valuable architecture support for them, it also creates problems with the customers who want developers to believe that their priorities and evolution requirements are worth accommodating”.

==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements
facilitated by direct user involvement in the development process. Serena’s application lifecycle management
tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and
enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral
and can be applied equally well to agile as well as more traditional serial development processes, so
they can support all the development activities within an enterprise.

Any team could be agile, regardless of the team size, but size is an issue because more people make
communication harder. There is much experience from small teams. There is less for larger teams, for
which scale-up strategies need to be applied.
• Experience is important for an Agile project to succeed, but experience with actually building systems
is much more important than experience with Agile methods. It was estimated that 25%-33% of the
project personnel must be “competent and experienced”, but the necessary percentage might even be as
low as 10% if the teams practice pair programming due to the fact that they mentor each other.
• Reliable and safety-critical projects can be conducted using Agile Methods. The key is that performance
requirements are made explicit early, and proper levels of testing are planned. It is easier to address
critical issues using Agile Methods since the customer gives requirements, makes important
things explicit early and provides continual input.
• Agile Methods require less formal training than traditional methods. Pair programming helps minimize
what is needed in terms of training, because people mentor each other. This is more important than
regular training that can many times be completed as self-training. Training material is available in particular
for XP, Crystal, Scrum, and FDD.
• The three most important success factors are culture, people, and communication. Agile Methods need
cultural support otherwise they will not succeed. Competent team members are crucial. Agile Methods
use fewer, but more competent people. Physically co-located teams and pair programming support
rapid communication. Close interaction with the customer and frequent customer feedback are critical
success factors.
• Early warning signs can be spotted in Agile projects, e.g. low morale expressed during the daily meeting.
Other signs are production of “useless documentation” and delays of planned iterations.
• Refactoring should be done frequently and of reasonably sized code, keeping the scope down and local.
Large-scale refactoring is not a problem, and is more feasible using Agile Methods. Traditional
“BDUF” is a waste of time and doesn’t lead to a learning experience. Big architectural changes do not
need to be risky if a set of automated tests is maintained.
• Documentation should be assigned a cost and its extent be determined by the customer. Many
organizations demand more than is needed. The goal should be to communicate effectively and
documentation should be the last option.

==References==

http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

http://www.gatherspace.com/static/agile_software_development.html

http://www.agilesherpa.org/intro_to_agile/agile_methodologies/

http://www.agiledeveloper.com/presentations/AgileMethodologies.pdf

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T04:01:38Z

Njdesai2: /* Quality Management */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T04:01:21Z

Njdesai2: /* Change Management */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T04:01:10Z

Njdesai2: /* Limitations of Agile Methodologies */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:57:40Z

Njdesai2: /* Development */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:51:57Z

Njdesai2: /* References */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:51:43Z

Njdesai2: /* References */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:50:38Z

Njdesai2: /* Conclusion */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:47:38Z

Njdesai2: /* Controlling the Project */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:47:26Z

Njdesai2: /* Roles and Responsibilities */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:47:16Z

Njdesai2: /* Project Planning */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:46:30Z

Njdesai2: /* Project Initiation */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:37:07Z

Njdesai2: /* Other Methodologies */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:36:25Z

Njdesai2: /* Comparison of different agile methodologies */

File:Agile comp.jpg

2011-11-18T03:35:34Z

Njdesai2:

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T03:27:38Z

Njdesai2: /* Agile Methodologies */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:30:25Z

Njdesai2: /* Other Methodologies */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:30:06Z

Njdesai2: /* Agile Unified Process */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:29:51Z

Njdesai2: /* Adaptive Software Development */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:29:26Z

Njdesai2: /* Feature Driven Development */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:29:05Z

Njdesai2: /* Dynamic Systems Development Method */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:28:47Z

Njdesai2: /* Crystal Family of Methodologies */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:28:30Z

Njdesai2: /* Crystal Clear & Orange */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:28:12Z

Njdesai2: /* Scrum */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:27:56Z

Njdesai2: /* Extreme Programming */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:26:29Z

Njdesai2: /* Overview */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:24:11Z

Njdesai2: /* Agile planning activities */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

===Agile planning activities===
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:23:56Z

Njdesai2: /* Principles of Agile Manifesto */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

====Agile planning activities====
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:22:31Z

Njdesai2: /* Agile Manifesto */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

'''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,
we value the items on the left more.

====Principles of Agile Manifesto====

====Agile planning activities====
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:20:07Z

Njdesai2: /* Agile Manifesto */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

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,
we value the items on the left more.

====Principles of Agile Manifesto====

====Agile planning activities====
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:18:17Z

Njdesai2: /* Agile planning activities */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
====Principles of Agile Manifesto====

====Agile planning activities====
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

'''Level 1''' - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

'''Level 2''' - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

'''Level 3''' - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

'''Level 4''' - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

'''Level 5''' - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:17:35Z

Njdesai2: /* Principles of Agile Manifesto */

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
===Agile Manifesto===
====Principles of Agile Manifesto====

====Agile planning activities====
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

Level 1 - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

Level 2 - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

Level 3 - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

Level 4 - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

Level 5 - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:14:43Z

Njdesai2: /* Introduction to Agile Software Development */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:14:28Z

Njdesai2: /* Introduction to Agile Software Development */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:13:14Z

Njdesai2: /* Introduction to Agile Software Development */

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:03:48Z

Njdesai2:

'''''6d. The Agile landscape.'''''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==

===Agile Manifesto===
====Principles of Agile Manifesto====
==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011/ch18 6d na

2011-11-18T01:03:12Z

Njdesai2: Created page with "'''''6d. The Agile landscape.''''' ''What are the main agile development methodologies? What are their origins? How do they differ? How widely are they practiced? What evide..."

'''''6d. The Agile landscape.''''' ''What are the main agile development methodologies? What are their origins? How do they differ? How widely are they practiced? What evidence exists for their effectiveness?''
---------------------

__TOC__
==Overview ==

==Introduction to Agile Software Development==

===Agile Manifesto===
====Principles of Agile Manifesto====
==Agile Methodologies==

===Extreme Programming===

===Scrum===

===Dynamic Systems Development Method===

===Crystal Family of Methodologies===

====Crystal Clear & Orange====

===Feature Driven Development===
===Adaptive Software Development===

===Agile Unified Process===
===Other Methodologies===
==Comparison of different agile methodologies==
===Project Initiation===

====Formality and Vision====

====Requirements Gathering====

===Project Planning===

===Roles and Responsibilities===

====Team Size and Visibility====
====Customer Involvement====

====Project Manager====
===Controlling the Project===
====Release Management====
====Communication====
===Change Management===

===Quality Management===

===Development===
==Adoption and Effectiveness of Agile Methodologies==

==Conclusion==

==References==

CSC/ECE 517 Fall 2011

2011-11-18T00:59:40Z

Njdesai2:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f mm]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4b ds]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4e gs]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[CSC/ECE 517 Fall 2011/ch4 4c dm]]

*[[CSC/ECE 517 Fall 2011/ch4 4g as]]

*[[CSC/ECE 517 Fall 2011/ch4 4g nv]]

*[[CSC/ECE 517 Fall 2011/ch4 4g ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4h kp]]

*[[CSC/ECE 517 Fall 2011/ch4 4h as]]

*[[CSC/ECE 517 Fall 2011/ch4 4j fw]]

*[[CSC/ECE 517 Fall 2011/ch4 4f rs]]

*[[CSC/ECE 517 Fall 2011/ch4 4i lc]]

*[[CSC/ECE 517 Fall 2011/ch17 5b uo]]

*[[CSC/ECE 517 Fall 2011/ch17 5b br]]

*[[CSC/ECE 517 Fall 2011/ch5 5d he]]

*[[CSC/ECE 517 Fall 2011/ch5 6d ny]]

*[[CSC/ECE 517 Fall 2011/ch6 6d sk]]

*[[CSC/ECE 517 Fall 2011/ch6 6e ch]]

*[[CSC/ECE 517 Fall 2011/ch6 6b ss]]

*[[CSC/ECE 517 Fall 2011/ch6 6b ra]]

*[[CSC/ECE 517 Fall 2011/ch6 6c sj]]

*[[CSC/ECE 517 Fall 2011/ch6 6a am]]

*[[CSC/ECE 517 Fall 2011/ch6 6e zj]]

*[[CSC/ECE_517_Fall_2011/ch6 6e gm]]

*[[CSC/ECE 517 Fall 2011/ch6 6f jd]]

*[[CSC/ECE 517 Fall 2011/ch6 6f va]]

*[[CSC/ECE 517 Fall 2011/ch6 6c p]]

*[[CSC/ECE 517 Fall 2011/ch6 6e gm]]

*[[CSC/ECE 517 Fall 2011/ch6 6c sm]]

*[[CSC/ECE 517 Fall 2011/ch18 6a sc]]

*[[CSC/ECE 517 Fall 2011/ch18 6d na]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch1 1g rn

2011-09-26T01:25:21Z

Njdesai2: /* Is scripting essentially synonymous with dynamic typing? */

<big>'''Object-Oriented Languages and Scripting'''</big>

==Introduction==
===Scripting Languages===
'''Definition''': A scripting language is a programming language that allows control of applications, giving it a sequence of work to do in a single batch[http://c2.com/cgi/wiki?ScriptingLanguage]
Scripting languages are usually used for gluing together pre-existing component and automation of manual work. They provide features like dynamic typing and extensibility that make them easy to learn. Scripting languages grew out of the need to shorten the traditional edit-compile-link-run process. As such, most of the scripting languages today are interpreted. However, this is not a defining feature; there are scripting languages that are compiled [http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/].

In this article we present an analysis of object-orientation in scripting. Specifically, we focus on what why object-orientation was introduced to the scripting arena, what advantages it brings to a scripting language and how scripting capabilities benefit object-orientation.

===Object-oriented Languages===
'''Definition''': An object-oriented language is a programming language that uses the "object" paradigm, consisting of members, method and their interactions to design application and computer programs. The fundamental ideology behind object-orientation is to model real world entities, either physical or conceptual as objects, their properties as data member, behavior as methods and relationships as interactions. The [http://www.kbcafe.com/articles/OOP.Concepts.pdf basic concepts] of object-oriented languages are [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf data abstraction], [http://web.cs.mun.ca/~donald/bsc/node13.html encapsulation], [http://download.oracle.com/javase/tutorial/java/concepts/inheritance.html inheritance], [http://download.oracle.com/javase/tutorial/java/IandI/polymorphism.html polymorphism] and [http://msdn.microsoft.com/en-us/library/ff649537.aspx modularity].

'''Note''': The intent of this article is not to provide an introduction to either scripting languages or object-oriented languages. We assume that the user has familiarity with basic [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] and [http://en.wikipedia.org/wiki/Scripting scripting concepts]. The case study presented requires intermediate knowledge of [http://www.perl.org/ Perl]. An excellent resource for learning Perl is [http://shop.oreilly.com/product/0636920018452.do Learning Perl].

==Advantages that object orientation bring to a scripting language==
===Provides encapsulation paradigm in gluing components===
An object-oriented approach allows multiple levels of encapsulation. The foremost use of scripts is to act as glue for pre-existing components [http://www.usenix.org/events/coots99/full_papers/neumann/neumann.pdf]. Since in scripting languages, code reuse is already provided by pre-existing components, encapsulation is the biggest advantage object-orientation brings to the table. Encapsulation lets us think about an object in isolation; encapsulation fits the human reasoning. Encapsulating data and functionality of various modules, possibly in different languages into a neatly packaged brand new object is perhaps the single most important objective of glue!

===Separate code into abstract pieces===
Procedural programming is the natural choice when writing scripts. Functionality in such scripts is broken down as procedures and variables. One of the major disadvantages of this approach is that it can get out of control when the complexity reaches a certain level. Using an object-oriented approach to scripting allows the programmer to separate code into classes that can be related to real-world entities. Providing classes with attributes and methods makes the code more readable, easier to extend and convenient to maintain [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/]. An abstract model makes implementation of complex system allows the program to follow a more natural flow.

===Reuse and customize things without changing source code===
Most of the popular object-oriented scripting languages like Perl, Python provide the programmer with vast libraries. Scripts typically use one or more library modules and build upon that [http://www.wiley.com/WileyCDA/WileyTitle/productCd-047039725X.html]. Object-orientation makes it easy to reuse and customize existing functionality without changes to the source code.

===Complex interactions within the system can be streamlined by the use of design patterns===
Design patterns are used to solve recurring problems within a given context. Patterns are created once and used many times. So, designing and creating patterns help in writing scripts as scripts are meant to use multiple times. Also many design patterns follow object oriented approach. Hence these patterns help in writing object oriented scripts.

===Case study===

'''Consider the following case which highlights the Advantages that object orientation bring to a scripting language:'''

One of the most common uses of scripting languages is for system administration. They are used extensively for automating system setup, configuration, and monitoring. Consider a system administrator who has the needs to run a monitor to obtain system statistics on his machines. For the sake of simplicity, we deal with hostname, system time, and disk usage as the metrics of interest. The following code shows an object-oriented Perl script that will serve his purposes:

<pre>
# DiskMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;

package DiskMonitor;

sub new {
my $class = shift;
my $self = { };
$self->{'usage'} = undef;
bless($self, $class);
}

sub getdiskusage {
my $self = shift;
$self->{'usage'} = `df -h`;
chomp $self->{'usage'};
return $self->{'usage'};
}

1;
</pre>

<pre>
# HostMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use Sys::Statistics::Linux;

package HostMonitor;
our @ISA = "Sys::Statistics::Linux";

sub new {
my $class = shift;
my %params = @_;
my $self = Sys::Statistics::Linux->new(@_);
$self->{'hostname'} = undef;
bless($self, $class);
}

sub gethostname {
my $self = shift;
$self->{'hostname'} = `hostname`;
chomp $self->{'hostname'};
return $self->{'hostname'};
}

1;
</pre>

<pre>
# Monitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use HostMonitor;
use DiskMonitor;

package SystemMonitor;

sub new {
my $class = shift;
my %param = @_;
my $self = {
'host' => HostMonitor->new(%param),
'disk' => DiskMonitor->new()
};
bless($self,$class);
}

sub displayStats {
my $self = shift;
my $hostname = $self->{'host'}->gethostname;
my $time = $self->{'host'}->gettime;
my $diskusage = $self->{'disk'}->getdiskusage;
print "For host : $hostname\n";
print "Time : $time\n";
print "Disk usage : $diskusage()\n";
}

1;
</pre>

<pre>
# displayStats.pl
#!/usr/bin/perl
use warnings;
use strict;
use SystemMonitor;

my $myMonitor = SystemMonitor->new();
$myMonitor->displayStats();
</pre>

Things to take away from this case study:
* The SystemMonitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a SystemMonitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.

* The SystemMonitor object encapsulates HostMonitor and DiskMonitor objects. This follows natural reasoning of having a consolidated monitor (like the dashboard of a car) with specific metric reporting components inside it (like the various dials on a dashboard).

* The HostMonitor extends [http://search.cpan.org/~bloonix/Sys-Statistics-Linux-0.60/lib/Sys/Statistics/Linux.pm Sys::Statistics::Linux], a pre-existing module obtained from CPAN . The Sys::Statistics::Linux provides with a lot metrics, however our system administrator needs the hostname also. Hence, HostMonitor uses all of the functionality Sys::Statistics::Linux provides, and add the missing method: gethostname(). Hence, we have reused a lot of existing code and customized the host monitoring component to our needs.

* Extending functionality of the SystemMonitor to collect some other statistics is easy. Suppose now we want our SystemMonitor to report network usage statistics. Just create a new Perl module NetworkMonitor that can obtain the required statistics about network usage and add it as a member of the SystemMonitor package.

* By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse.

==Advantages that scripting capability bring to an object-oriented language==
===Dynamic typing and extensibility reduce software development lifecycle===
Dynamic typing doesn’t require explicit declaration of variables before their use. Variables can be used as and when needed without worrying about their declaration and initialization. More importantly, since variable need not be declared, they also need not belong to a particular type. Hence, a variable can bound to objects of different types. Dynamic typing also opens the door for other features such as autovivification, where a variable reference is automatically created on dereferencing an undefined value. This dynamic typing and extensibility reduce the development time as the programmer has the freedom to bind and extended data structures at run time. It also makes the language less syntactically enforcing, making it easier to learn and use.

===Standard data representation===
A central property of scripting languages is the use of strings as the only representation of data [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf]. Hence, all integrated components use the same string interface for typing 6. An implication of dynamic typing is that there are no native data-types. Hence all data structures are inherently built upon the only common representation of data. As a consequence the programmer does not have to worry about type-casting and type-conversions when handling data from different components.

===Focus on functionality===
Allows application developers to concentrate primarily on the functionality, rather than worry about component fitting. Scripting languages have the ability to glue diverse implementations.

==Advantages to a scripting language that is not object oriented==
Most of the popular scripting languages today did not start out as object-oriented languages. Object-orientation was provided to them later on. The designers of the language envisioned use of scripting for writing easy to medium complexity code in a short time. However, these languages grew immensely popular that made object-orientation a necessity. As such, a performance of a non-object oriented script will always be better that an object-oriented one. Object-orientation adds an extra layer of abstraction that hurts performance. Having said that, todays processors are so fast that this difference is hardly noticeable.

==Similarity between scripting and dynamic typing==
Scripting languages are basically known as “Glue” languages, since scripts glue together various preexisting components or programs which may or may not be in same language. Dynamically typed languages generally use run time objects with tags containing their type information [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038]. In dynamic typing, types are associated with run time values rather than normal expressions written. It determines the type safety of operations at run time. It allows programmer not to write explicit type annotations on expressions. In other words, it allows a single variable to refer to values of different types at different points in the single program. Hence it helps scripting language to glue different components together. Some of the dynamic scripting languages are python, ruby, Perl while using user data types.
Scripting languages are interpreted, as most of the dynamic typing languages are, it does not mean all languages are dynamically typed such as objective C or Lisp. Also not all dynamically typed languages offer scripting functionality. Like Perl allows dynamic typing for user defined data types only, but it is used for scripting.

==References==

* [1] Scripting Language, ''unkown'' [http://c2.com/cgi/wiki?ScriptingLanguage]
* [2] Stefan Mischook [http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/ Scripting vs. programming: is there a difference?]
* [3] Gustaf Neumann and Uwe Zdun [http://www.usenix.org/events/coots99/full_papers/neumann/neumann.pdf 5th USENIX Conference on Object-Oriented Technologies and Systems]
* [4] Noah Gift [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/ From scripting to object-oriented Python programming]
* [5] Kak, Avinash [http://www.wiley.com/WileyCDA/WileyTitle/productCd-047039725X.html Scripting with objects] Wiley Publications, 2008
* [6] Neumann, Zdun [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf XOTcl - an Object-Oriented Scripting Language]
* [7] Lynn Greiner [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038 PHP, JavaScript, Ruby, Perl, Python, and Tcl Today: The State of the Scripting Universe]

CSC/ECE 517 Fall 2011/ch1 1g rn

2011-09-26T01:23:51Z

Njdesai2: /* Are there any advantages to a scripting language that is not object oriented? */

<big>'''Object-Oriented Languages and Scripting'''</big>

==Introduction==
===Scripting Languages===
'''Definition''': A scripting language is a programming language that allows control of applications, giving it a sequence of work to do in a single batch[http://c2.com/cgi/wiki?ScriptingLanguage]
Scripting languages are usually used for gluing together pre-existing component and automation of manual work. They provide features like dynamic typing and extensibility that make them easy to learn. Scripting languages grew out of the need to shorten the traditional edit-compile-link-run process. As such, most of the scripting languages today are interpreted. However, this is not a defining feature; there are scripting languages that are compiled [http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/].

In this article we present an analysis of object-orientation in scripting. Specifically, we focus on what why object-orientation was introduced to the scripting arena, what advantages it brings to a scripting language and how scripting capabilities benefit object-orientation.

===Object-oriented Languages===
'''Definition''': An object-oriented language is a programming language that uses the "object" paradigm, consisting of members, method and their interactions to design application and computer programs. The fundamental ideology behind object-orientation is to model real world entities, either physical or conceptual as objects, their properties as data member, behavior as methods and relationships as interactions. The [http://www.kbcafe.com/articles/OOP.Concepts.pdf basic concepts] of object-oriented languages are [http:// data abstraction], [http:// encapsulation], [http://download.oracle.com/javase/tutorial/java/concepts/inheritance.html inheritance], [http://download.oracle.com/javase/tutorial/java/IandI/polymorphism.html polymorphism] and [http://msdn.microsoft.com/en-us/library/ff649537.aspx modularity].

'''Note''': The intent of this article is not to provide an introduction to either scripting languages or object-oriented languages. We assume that the user has familiarity with basic [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] and [http://en.wikipedia.org/wiki/Scripting scripting concepts]. The case study presented requires intermediate knowledge of [http://www.perl.org/ Perl]. An excellent resource for learning Perl is [http://shop.oreilly.com/product/0636920018452.do Learning Perl].

==Advantages that object orientation bring to a scripting language==
===Provides encapsulation paradigm in gluing components===
An object-oriented approach allows multiple levels of encapsulation. The foremost use of scripts is to act as glue for pre-existing components [http://www.usenix.org/events/coots99/full_papers/neumann/neumann.pdf]. Since in scripting languages, code reuse is already provided by pre-existing components, encapsulation is the biggest advantage object-orientation brings to the table. Encapsulation lets us think about an object in isolation; encapsulation fits the human reasoning. Encapsulating data and functionality of various modules, possibly in different languages into a neatly packaged brand new object is perhaps the single most important objective of glue!

===Separate code into abstract pieces===
Procedural programming is the natural choice when writing scripts. Functionality in such scripts is broken down as procedures and variables. One of the major disadvantages of this approach is that it can get out of control when the complexity reaches a certain level. Using an object-oriented approach to scripting allows the programmer to separate code into classes that can be related to real-world entities. Providing classes with attributes and methods makes the code more readable, easier to extend and convenient to maintain [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/]. An abstract model makes implementation of complex system allows the program to follow a more natural flow.

===Reuse and customize things without changing source code===
Most of the popular object-oriented scripting languages like Perl, Python provide the programmer with vast libraries. Scripts typically use one or more library modules and build upon that [http://www.wiley.com/WileyCDA/WileyTitle/productCd-047039725X.html]. Object-orientation makes it easy to reuse and customize existing functionality without changes to the source code.

===Complex interactions within the system can be streamlined by the use of design patterns===
Design patterns are used to solve recurring problems within a given context. Patterns are created once and used many times. So, designing and creating patterns help in writing scripts as scripts are meant to use multiple times. Also many design patterns follow object oriented approach. Hence these patterns help in writing object oriented scripts.

===Case study===

'''Consider the following case which highlights the Advantages that object orientation bring to a scripting language:'''

One of the most common uses of scripting languages is for system administration. They are used extensively for automating system setup, configuration, and monitoring. Consider a system administrator who has the needs to run a monitor to obtain system statistics on his machines. For the sake of simplicity, we deal with hostname, system time, and disk usage as the metrics of interest. The following code shows an object-oriented Perl script that will serve his purposes:

<pre>
# DiskMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;

package DiskMonitor;

sub new {
my $class = shift;
my $self = { };
$self->{'usage'} = undef;
bless($self, $class);
}

sub getdiskusage {
my $self = shift;
$self->{'usage'} = `df -h`;
chomp $self->{'usage'};
return $self->{'usage'};
}

1;
</pre>

<pre>
# HostMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use Sys::Statistics::Linux;

package HostMonitor;
our @ISA = "Sys::Statistics::Linux";

sub new {
my $class = shift;
my %params = @_;
my $self = Sys::Statistics::Linux->new(@_);
$self->{'hostname'} = undef;
bless($self, $class);
}

sub gethostname {
my $self = shift;
$self->{'hostname'} = `hostname`;
chomp $self->{'hostname'};
return $self->{'hostname'};
}

1;
</pre>

<pre>
# Monitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use HostMonitor;
use DiskMonitor;

package SystemMonitor;

sub new {
my $class = shift;
my %param = @_;
my $self = {
'host' => HostMonitor->new(%param),
'disk' => DiskMonitor->new()
};
bless($self,$class);
}

sub displayStats {
my $self = shift;
my $hostname = $self->{'host'}->gethostname;
my $time = $self->{'host'}->gettime;
my $diskusage = $self->{'disk'}->getdiskusage;
print "For host : $hostname\n";
print "Time : $time\n";
print "Disk usage : $diskusage()\n";
}

1;
</pre>

<pre>
# displayStats.pl
#!/usr/bin/perl
use warnings;
use strict;
use SystemMonitor;

my $myMonitor = SystemMonitor->new();
$myMonitor->displayStats();
</pre>

Things to take away from this case study:
* The SystemMonitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a SystemMonitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.

* The SystemMonitor object encapsulates HostMonitor and DiskMonitor objects. This follows natural reasoning of having a consolidated monitor (like the dashboard of a car) with specific metric reporting components inside it (like the various dials on a dashboard).

* The HostMonitor extends [http://search.cpan.org/~bloonix/Sys-Statistics-Linux-0.60/lib/Sys/Statistics/Linux.pm Sys::Statistics::Linux], a pre-existing module obtained from CPAN . The Sys::Statistics::Linux provides with a lot metrics, however our system administrator needs the hostname also. Hence, HostMonitor uses all of the functionality Sys::Statistics::Linux provides, and add the missing method: gethostname(). Hence, we have reused a lot of existing code and customized the host monitoring component to our needs.

* Extending functionality of the SystemMonitor to collect some other statistics is easy. Suppose now we want our SystemMonitor to report network usage statistics. Just create a new Perl module NetworkMonitor that can obtain the required statistics about network usage and add it as a member of the SystemMonitor package.

* By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse.

==Advantages that scripting capability bring to an object-oriented language==
===Dynamic typing and extensibility reduce software development lifecycle===
Dynamic typing doesn’t require explicit declaration of variables before their use. Variables can be used as and when needed without worrying about their declaration and initialization. More importantly, since variable need not be declared, they also need not belong to a particular type. Hence, a variable can bound to objects of different types. Dynamic typing also opens the door for other features such as autovivification, where a variable reference is automatically created on dereferencing an undefined value. This dynamic typing and extensibility reduce the development time as the programmer has the freedom to bind and extended data structures at run time. It also makes the language less syntactically enforcing, making it easier to learn and use.

===Standard data representation===
A central property of scripting languages is the use of strings as the only representation of data [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf]. Hence, all integrated components use the same string interface for typing 6. An implication of dynamic typing is that there are no native data-types. Hence all data structures are inherently built upon the only common representation of data. As a consequence the programmer does not have to worry about type-casting and type-conversions when handling data from different components.

===Focus on functionality===
Allows application developers to concentrate primarily on the functionality, rather than worry about component fitting. Scripting languages have the ability to glue diverse implementations.

==Advantages to a scripting language that is not object oriented==
Most of the popular scripting languages today did not start out as object-oriented languages. Object-orientation was provided to them later on. The designers of the language envisioned use of scripting for writing easy to medium complexity code in a short time. However, these languages grew immensely popular that made object-orientation a necessity. As such, a performance of a non-object oriented script will always be better that an object-oriented one. Object-orientation adds an extra layer of abstraction that hurts performance. Having said that, todays processors are so fast that this difference is hardly noticeable.

==Is scripting essentially synonymous with dynamic typing?==
Scripting languages are basically known as “Glue” languages, since scripts glue together various preexisting components or programs which may or may not be in same language. Dynamically typed languages generally use run time objects with tags containing their type information [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038]. In dynamic typing, types are associated with run time values rather than normal expressions written. It determines the type safety of operations at run time. It allows programmer not to write explicit type annotations on expressions. In other words, it allows a single variable to refer to values of different types at different points in the single program. Hence it helps scripting language to glue different components together. Some of the dynamic scripting languages are python, ruby, Perl while using user data types.
Scripting languages are interpreted, as most of the dynamic typing languages are, it does not mean all languages are dynamically typed such as objective C or Lisp. Also not all dynamically typed languages offer scripting functionality. Like Perl allows dynamic typing for user defined data types only, but it is used for scripting.

==References==

* [1] Scripting Language, ''unkown'' [http://c2.com/cgi/wiki?ScriptingLanguage]
* [2] Stefan Mischook [http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/ Scripting vs. programming: is there a difference?]
* [3] Gustaf Neumann and Uwe Zdun [http://www.usenix.org/events/coots99/full_papers/neumann/neumann.pdf 5th USENIX Conference on Object-Oriented Technologies and Systems]
* [4] Noah Gift [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/ From scripting to object-oriented Python programming]
* [5] Kak, Avinash [http://www.wiley.com/WileyCDA/WileyTitle/productCd-047039725X.html Scripting with objects] Wiley Publications, 2008
* [6] Neumann, Zdun [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf XOTcl - an Object-Oriented Scripting Language]
* [7] Lynn Greiner [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038 PHP, JavaScript, Ruby, Perl, Python, and Tcl Today: The State of the Scripting Universe]

CSC/ECE 517 Fall 2011/ch1 1g rn

2011-09-09T01:45:14Z

Njdesai2: /* Complex interactions within the system can be streamlined by the use of design patterns */

<big>'''Object-Oriented Languages and Scripting'''</big>

==Introduction==
Scripting languages are usually used for gluing together pre-existing component and automation of manual work. They provide features like dynamic typing and extensibility that make them easy to learn. Scripting languages grew out of the need to shorten the traditional edit-compile-link-run process. As such, most of the scripting languages today are interpreted. However, this is not a defining feature; there are scripting languages that are compiled [http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/].

In this article we present an analysis of object-orientation in scripting. Specifically, we focus on what why object-orientation was introduced to the scripting arena, what advantages it brings to a scripting language and how scripting capabilities benefit object-orientation.

The intent of this article is not to provide an introduction to either scripting languages or object-oriented languages. We assume that the user has familiarity with basic [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] and [http://en.wikipedia.org/wiki/Scripting scripting concepts]. The case study presented requires intermediate knowledge of [http://www.perl.org/ Perl]. An excellent resource for learning Perl is [http://shop.oreilly.com/product/0636920018452.do Learning Perl].

==Advantages that object orientation bring to a scripting language==
===Provides encapsulation paradigm in gluing components===
An object-oriented approach allows multiple levels of encapsulation. The foremost use of scripts is to act as glue for pre-existing components [http://www.usenix.org/events/coots99/full_papers/neumann/neumann.pdf]. Since in scripting languages, code reuse is already provided by pre-existing components, encapsulation is the biggest advantage object-orientation brings to the table. Encapsulation lets us think about an object in isolation; encapsulation fits the human reasoning. Encapsulating data and functionality of various modules, possibly in different languages into a neatly packaged brand new object is perhaps the single most important objective of glue!

===Separate code into abstract pieces===
Procedural programming is the natural choice when writing scripts. Functionality in such scripts is broken down as procedures and variables. One of the major disadvantages of this approach is that it can get out of control when the complexity reaches a certain level. Using an object-oriented approach to scripting allows the programmer to separate code into classes that can be related to real-world entities. Providing classes with attributes and methods makes the code more readable, easier to extend and convenient to maintain [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/]. An abstract model makes implementation of complex system allows the program to follow a more natural flow.

===Reuse and customize things without changing source code===
Most of the popular object-oriented scripting languages like Perl, Python provide the programmer with vast libraries. Scripts typically use one or more library modules and build upon that [http://www.wiley.com/WileyCDA/WileyTitle/productCd-047039725X.html]. Object-orientation makes it easy to reuse and customize existing functionality without changes to the source code.

===Complex interactions within the system can be streamlined by the use of design patterns===
Design patterns are used to solve recurring problems within a given context. Patterns are created once and used many times. So, designing and creating patterns help in writing scripts as scripts are meant to use multiple times. Also many design patterns follow object oriented approach. Hence these patterns help in writing object oriented scripts.

===Case study===

'''Consider the following case which highlights the Advantages that object orientation bring to a scripting language:'''

One of the most common uses of scripting languages is for system administration. They are used extensively for automating system setup, configuration, and monitoring. Consider a system administrator who has the needs to run a monitor to obtain system statistics on his machines. For the sake of simplicity, we deal with hostname, system time, and disk usage as the metrics of interest. The following code shows an object-oriented Perl script that will serve his purposes:

<pre>
# DiskMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;

package DiskMonitor;

sub new {
my $class = shift;
my $self = { };
$self->{'usage'} = undef;
bless($self, $class);
}

sub getdiskusage {
my $self = shift;
$self->{'usage'} = `df -h`;
chomp $self->{'usage'};
return $self->{'usage'};
}

1;
</pre>

<pre>
# HostMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use Sys::Statistics::Linux;

package HostMonitor;
our @ISA = "Sys::Statistics::Linux";

sub new {
my $class = shift;
my %params = @_;
my $self = Sys::Statistics::Linux->new(@_);
$self->{'hostname'} = undef;
bless($self, $class);
}

sub gethostname {
my $self = shift;
$self->{'hostname'} = `hostname`;
chomp $self->{'hostname'};
return $self->{'hostname'};
}

1;
</pre>

<pre>
# Monitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use HostMonitor;
use DiskMonitor;

package SystemMonitor;

sub new {
my $class = shift;
my %param = @_;
my $self = {
'host' => HostMonitor->new(%param),
'disk' => DiskMonitor->new()
};
bless($self,$class);
}

sub displayStats {
my $self = shift;
my $hostname = $self->{'host'}->gethostname;
my $time = $self->{'host'}->gettime;
my $diskusage = $self->{'disk'}->getdiskusage;
print "For host : $hostname\n";
print "Time : $time\n";
print "Disk usage : $diskusage()\n";
}

1;
</pre>

<pre>
# displayStats.pl
#!/usr/bin/perl
use warnings;
use strict;
use SystemMonitor;

my $myMonitor = SystemMonitor->new();
$myMonitor->displayStats();
</pre>

Things to take away from this case study:
* The SystemMonitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a SystemMonitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.

* The SystemMonitor object encapsulates HostMonitor and DiskMonitor objects. This follows natural reasoning of having a consolidated monitor (like the dashboard of a car) with specific metric reporting components inside it (like the various dials on a dashboard).

* The HostMonitor extends [http://search.cpan.org/~bloonix/Sys-Statistics-Linux-0.60/lib/Sys/Statistics/Linux.pm Sys::Statistics::Linux], a pre-existing module obtained from CPAN . The Sys::Statistics::Linux provides with a lot metrics, however our system administrator needs the hostname also. Hence, HostMonitor uses all of the functionality Sys::Statistics::Linux provides, and add the missing method: gethostname(). Hence, we have reused a lot of existing code and customized the host monitoring component to our needs.

* Extending functionality of the SystemMonitor to collect some other statistics is easy. Suppose now we want our SystemMonitor to report network usage statistics. Just create a new Perl module NetworkMonitor that can obtain the required statistics about network usage and add it as a member of the SystemMonitor package.

* By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse.

==Advantages that scripting capability bring to an object-oriented language==
===Dynamic typing and extensibility reduce software development lifecycle===
Dynamic typing doesn’t require explicit declaration of variables before their use. Variables can be used as and when needed without worrying about their declaration and initialization. More importantly, since variable need not be declared, they also need not belong to a particular type. Hence, a variable can bound to objects of different types. Dynamic typing also opens the door for other features such as autovivification, where a variable reference is automatically created on dereferencing an undefined value. This dynamic typing and extensibility reduce the development time as the programmer has the freedom to bind and extended data structures at run time. It also makes the language less syntactically enforcing, making it easier to learn and use.

===Standard data representation===
A central property of scripting languages is the use of strings as the only representation of data [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf]. Hence, all integrated components use the same string interface for typing 6. An implication of dynamic typing is that there are no native data-types. Hence all data structures are inherently built upon the only common representation of data. As a consequence the programmer does not have to worry about type-casting and type-conversions when handling data from different components.

===Focus on functionality===
Allows application developers to concentrate primarily on the functionality, rather than worry about component fitting. Scripting languages have the ability to glue diverse implementations.

==Are there any advantages to a scripting language that is not object oriented?==
Most of the popular scripting languages today did not start out as object-oriented languages. Object-orientation was provided to them later on. The designers of the language envisioned use of scripting for writing easy to medium complexity code in a short time. However, these languages grew immensely popular that made object-orientation a necessity. As such, a performance of a non-object oriented script will always be better that an object-oriented one. Object-orientation adds an extra layer of abstraction that hurts performance. Having said that, todays processors are so fast that this difference is hardly noticeable.

==Is scripting essentially synonymous with dynamic typing?==
Scripting languages are basically known as “Glue” languages, since scripts glue together various preexisting components or programs which may or may not be in same language. Dynamically typed languages generally use run time objects with tags containing their type information [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038]. In dynamic typing, types are associated with run time values rather than normal expressions written. It determines the type safety of operations at run time. It allows programmer not to write explicit type annotations on expressions. In other words, it allows a single variable to refer to values of different types at different points in the single program. Hence it helps scripting language to glue different components together. Some of the dynamic scripting languages are python, ruby, Perl while using user data types.
Scripting languages are interpreted, as most of the dynamic typing languages are, it does not mean all languages are dynamically typed such as objective C or Lisp. Also not all dynamically typed languages offer scripting functionality. Like Perl allows dynamic typing for user defined data types only, but it is used for scripting.

==References==

* [1] Stefan Mischook [http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/ Scripting vs. programming: is there a difference?]
* [2] Gustaf Neumann and Uwe Zdun [http://www.usenix.org/events/coots99/full_papers/neumann/neumann.pdf 5th USENIX Conference on Object-Oriented Technologies and Systems]
* [3] Noah Gift [http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/ From scripting to object-oriented Python programming]
* [4] Kak, Avinash [http://www.wiley.com/WileyCDA/WileyTitle/productCd-047039725X.html Scripting with objects] Wiley Publications, 2008
* [5] Neumann, Zdun [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf XOTcl - an Object-Oriented Scripting Language]
* [6] Lynn Greiner [http://www.cio.com/article/446829/PHP_JavaScript_Ruby_Perl_Python_and_Tcl_Today_The_State_of_the_Scripting_Universe?page=4&taxonomyId=3038 PHP, JavaScript, Ruby, Perl, Python, and Tcl Today: The State of the Scripting Universe]

CSC/ECE 517 Fall 2011/ch1 1g rn

2011-09-09T01:11:48Z

Njdesai2: /* References */

<big>'''Object-Oriented Languages and Scripting'''</big>

==Introduction==
Scripting languages are usually used for gluing together pre-existing component and automation of manual work. They provide features like dynamic typing and extensibility that make them easy to learn. Scripting languages grew out of the need to shorten the traditional edit-compile-link-run process. As such, most of the scripting languages today are interpreted. However, this is not a defining feature; there are scripting languages that are compiled.

In this article we present an analysis of object-orientation in scripting. Specifically, we focus on what why object-orientation was introduced to the scripting arena, what advantages it brings to a scripting language and how scripting capabilities benefit object-orientation.

The intent of this article is not to provide an introduction to either scripting languages or object-oriented languages. We assume that the user has familiarity with basic [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] and [http://en.wikipedia.org/wiki/Scripting scripting concepts]. The case study presented requires intermediate knowledge of [http://www.perl.org/ Perl]. An excellent resource for learning Perl is [http://shop.oreilly.com/product/0636920018452.do Learning Perl].

==Advantages that object orientation bring to a scripting language==
===Provides encapsulation paradigm in gluing components===
An object-oriented approach allows multiple levels of encapsulation. The foremost use of scripts is to act as glue for pre-existing components. Since in scripting languages, code reuse is already provided by pre-existing components, encapsulation is the biggest advantage object-orientation brings to the table. Encapsulation lets us think about an object in isolation; encapsulation fits the human reasoning. Encapsulating data and functionality of various modules, possibly in different languages into a neatly packaged brand new object is perhaps the single most important objective of glue!

===Separate code into abstract pieces===
Procedural programming is the natural choice when writing scripts. Functionality in such scripts is broken down as procedures and variables. One of the major disadvantages of this approach is that it can get out of control when the complexity reaches a certain level. Using an object-oriented approach to scripting allows the programmer to separate code into classes that can be related to real-world entities. Providing classes with attributes and methods makes the code more readable, easier to extend and convenient to maintain. An abstract model makes implementation of complex system allows the program to follow a more natural flow.

===Reuse and customize things without changing source code===
Most of the popular object-oriented scripting languages like Perl, Python provide the programmer with vast libraries. Scripts typically use one or more library modules and build upon that. Object-orientation makes it easy to reuse and customize existing functionality without changes to the source code.

===Complex interactions within the system can be streamlined by the use of design patterns===
foo bar

===Case study===

'''Consider the following case which highlights the Advantages that object orientation bring to a scripting language:'''

One of the most common uses of scripting languages is for system administration. They are used extensively for automating system setup, configuration, and monitoring. Consider a system administrator who has the needs to run a monitor to obtain system statistics on his machines. For the sake of simplicity, we deal with hostname, system time, and disk usage as the metrics of interest. The following code shows an object-oriented Perl script that will serve his purposes:

<pre>
# DiskMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;

package DiskMonitor;

sub new {
my $class = shift;
my $self = { };
$self->{'usage'} = undef;
bless($self, $class);
}

sub getdiskusage {
my $self = shift;
$self->{'usage'} = `df -h`;
chomp $self->{'usage'};
return $self->{'usage'};
}

1;
</pre>

<pre>
# HostMonitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use Sys::Statistics::Linux;

package HostMonitor;
our @ISA = "Sys::Statistics::Linux";

sub new {
my $class = shift;
my %params = @_;
my $self = Sys::Statistics::Linux->new(@_);
$self->{'hostname'} = undef;
bless($self, $class);
}

sub gethostname {
my $self = shift;
$self->{'hostname'} = `hostname`;
chomp $self->{'hostname'};
return $self->{'hostname'};
}

1;
</pre>

<pre>
# Monitor.pm
#!/usr/bin/perl
use strict;
use warnings;
use HostMonitor;
use DiskMonitor;

package SystemMonitor;

sub new {
my $class = shift;
my %param = @_;
my $self = {
'host' => HostMonitor->new(%param),
'disk' => DiskMonitor->new()
};
bless($self,$class);
}

sub displayStats {
my $self = shift;
my $hostname = $self->{'host'}->gethostname;
my $time = $self->{'host'}->gettime;
my $diskusage = $self->{'disk'}->getdiskusage;
print "For host : $hostname\n";
print "Time : $time\n";
print "Disk usage : $diskusage()\n";
}

1;
</pre>

<pre>
# displayStats.pl
#!/usr/bin/perl
use warnings;
use strict;
use SystemMonitor;

my $myMonitor = SystemMonitor->new();
$myMonitor->displayStats();
</pre>

Things to take away from this case study:
* The SystemMonitor object seamlessly glues together pre-existing components: HostMonitor and DiskMonitor, one of the fundamental reasons of using a scripting language. It provides a SystemMonitor with the appearance of an intact and complete entity, hiding away the internal details of the parts that make it.

* The SystemMonitor object encapsulates HostMonitor and DiskMonitor objects. This follows natural reasoning of having a consolidated monitor (like the dashboard of a car) with specific metric reporting components inside it (like the various dials on a dashboard).

* The HostMonitor extends Sys::Statistics::Linux, a pre-existing module obtained from CPAN. The Sys::Statistics::Linux provides with a lot metrics, however our system administrator needs the hostname also. Hence, HostMonitor uses all of the functionality Sys::Statistics::Linux provides, and add the missing method: gethostname(). Hence, we have reused a lot of existing code and customized the host monitoring component to our needs.

* Extending functionality of the SystemMonitor to collect some other statistics is easy. Suppose now we want our SystemMonitor to report network usage statistics. Just create a new Perl module NetworkMonitor that can obtain the required statistics about network usage and add it as a member of the SystemMonitor package.

* By defining HostMonitor and DiskMonitor as modules, they are made available to other users for reuse.

==Advantages that scripting capability bring to an object-oriented language==
===Dynamic typing and extensibility reduce software development lifecycle===
Dynamic typing doesn’t require explicit declaration of variables before their use. Variables can be used as and when needed without worrying about their declaration and initialization. More importantly, since variable need not be declared, they also need not belong to a particular type. Hence, a variable can bound to objects of different types. Dynamic typing also opens the door for other features such as autovivification, where a variable reference is automatically created on dereferencing an undefined value. This dynamic typing and extensibility reduce the development time as the programmer has the freedom to bind and extended data structures at run time. It also makes the language less syntactically enforcing, making it easier to learn and use.

===Standard data representation===
A central property of scripting languages is the use of strings as the only representation of data [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf]. Hence, all integrated components use the same string interface for typing 6. An implication of dynamic typing is that there are no native data-types. Hence all data structures are inherently built upon the only common representation of data. As a consequence the programmer does not have to worry about type-casting and type-conversions when handling data from different components.

===Focus on functionality===
Allows application developers to concentrate primarily on the functionality, rather than worry about component fitting. Scripting languages have the ability to glue diverse implementations.

==Are there any advantages to a scripting language that is not object oriented?==
Most of the popular scripting languages today did not start out as object-oriented languages. Object-orientation was provided to them later on. The designers of the language envisioned use of scripting for writing easy to medium complexity code in a short time. However, these languages grew immensely popular that made object-orientation a necessity. As such, a performance of a non-object oriented script will always be better that an object-oriented one. Object-orientation adds an extra layer of abstraction that hurts performance. Having said that, todays processors are so fast that this difference is hardly noticeable.

==Is scripting essentially synonymous with dynamic typing?==
Scripting languages are basically known as “Glue” languages, since scripts glue together various preexisting components or programs which may or may not be in same language. Dynamically typed languages generally use run time objects with tags containing their type information. In dynamic typing, types are associated with run time values rather than normal expressions written. It determines the type safety of operations at run time. It allows programmer not to write explicit type annotations on expressions. In other words, it allows a single variable to refer to values of different types at different points in the single program. Hence it helps scripting language to glue different components together. Some of the dynamic scripting languages are python, ruby, Perl while using user data types.
Scripting languages are interpreted, as most of the dynamic typing languages are, it does not mean all languages are dynamically typed such as objective C or Lisp. Also not all dynamically typed languages offer scripting functionality. Like Perl allows dynamic typing for user defined data types only, but it is used for scripting.

==References==
* http://www.tcl.tk/doc/scripting.html
* http://msdn.microsoft.com/en-us/library/aa233158(v=vs.60).aspx
* http://www.ibm.com/developerworks/aix/library/au-scripting_to_oo/
* http://www.pdffinder.com/pdf/a-comparison-of-object-oriented-scripting-languages-python-and-ruby.html
* http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/
* [1] Neumann, Zdun [http://nm.wu-wien.ac.at/research/publications/xotcl-tclconf.pdf XOTcl - an Object-Oriented Scripting Language]
* [2] Gustaf Neumann and Uwe Zdun [http://www.usenix.org/events/coots99/full_papers/neumann/neumann.pdf - 5th USENIX Conference on Object-Oriented Technologies and Systems]