Agile Methodology and System Analysis
University of Missouri, St Louis
November
29, 2006
Introduction
to Agile Methodology
Principles
of Agile Methodology
Steps
of Agile System Analysis Process
Agile
Requirements Best Practices
Agile Analysis
Risks and Rewards
References
Agile- denoting the quality of being agile; readiness;
nimbleness, activity, dexterity in motion”- software
development methods are attempting to offer an answer to the eager business
community wanting lighter weight and faster and nimble software development
processes. This is especially the case with rapidly growing and volatile
internet software industry as well as for the emerging mobile environment[Abrahhamson,2002].
According
to Highsmith and Cockburn(2001),
“ what is new about agile methods is
not the practices they use, but their recognition of people as the primary
drivers of project success, coupled with intense focus on effectiveness and
maneuverability. This yields new combinations of values and principles that
define an agile view of the world.
Cockburn
defines the core of agile software development methods as the use of light but
sufficient rules of project behavior and the use of human-and communication
oriented tools. The agile process is both light and sufficient. Lightness is a
means of remaining maneuverable. Sufficiency is a matter of staying in the game(Cockburn, 2002).
Miller(2001) gives the following
characterization to agile software processes from the fast delivery point of
view, which allows shortening the life-cycle of projects:
Modularity
on development process level
Iterative
with short cycles enabling fast verifications and corrections
Time
bound with iteration cycles from one to six weeks.
Parsimony
in development process removes all unnecessary activities.
Adaptive
with possible emergent new risks
Incremental
process approach that allows functioning application building in small steps
Convergent
approach minimizes the risk
People-oriented
i.e., agile processes favor people over processes and technology
Collaborative
and communicative working style.
Favaro(2002) discusses the emergence of strategies
for confronting a vague process showing changing requirements. He proposes an
iterative development paradigm as the common denominator of agile processes. Requirements
may be introduced, modified, or removed in successful iterations.
A
basic set of commonsense approaches emerging from agile software development processes
have been suggested by Ambler (2002a) as follows:
People
matter
Less
documentation is possible
Communication
is a critical issue
Modeling
tools are not as useful as thought
Big
up-front design is not required.
Thus,
the focal points of light and agile methods are simplicity and speed. In
development work, accordingly, the development group concentrates only on the
functions needed at first hand, delivering them fast, collecting feedback and reacting
to received information. A development method is agile
if it is incremental ( small software releases with
rapid cycles), cooperative( customer and developers working constantly together
with open communication), straightforward( the method itself is easy to learn and
to modify), and adaptive( able to make last minute changes)[Dave,2005]. Initially,
agile methods were called "lightweight methods." In 2001, prominent
members of the community met at Snowbird and adopted the name "agile
methods." Later, some of these people formed The Agile Alliance, a non-profit
organization that promotes agile development. Early agile methods—created prior
to 2000—include Scrum (in management) (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and DSDM (1995)[Wikipedia,24].
Principles of Agile Methodology:
The
principles of Agile Methodology(AM)
which are reflected in the Agile Manifesto
also are[Martin,2002]:
Customer
satisfaction by rapid, continuous delivery of useful software
Working
software is delivered frequently (weeks rather than months)
Working
software is the principal measure of progress.
Even
late changes in requirements are welcomed.
Close,
daily, cooperation between business people and developers
Face-to-face
conversation is the best form of communication.
Projects
are built around motivated individuals, who should be trusted
Continuous
attention to technical excellence and good design.
Simplicity
Self-organizing
teams
Regular
adaptation to changing circumstances
Although
agile methods differ in their practices, they share a number of common
characteristics, including iterative development, and a focus on interaction,
communication, and the reduction of resource-intensive intermediate artifacts.
(Cohen et al., 2004) The suitability of agile methods in general can be
examined from multiple perspectives. From a product perspective, agile methods
are more suitable when requirements are emergent and rapidly changing; they are
less suitable for systems that have high criticality, reliability and safety
requirements, although there is no complete consensus on this point (Cohen et
al., 2004). From an organizational perspective, the suitability can be assessed
by examining three key dimensions of an organization: culture, people, and
communication. In relation to these areas a number of key success factors have
been identified (Cohen et al., 2004):
The
culture of the organization must be supportive of negotiation
People
must be trusted
Fewer
but more competent people
Organizations
must live with the decisions developers make
Organizations
need to have an environment that facilitates rapid communication between team
members
Most
people have the perception that the deliverable from the “analysis phase”
is a set of “analysis” documents and artifacts. This perception is a result of
waterfall practices. For Waterfall,
the deliverable is an analysis document. Waterfall
methodologies believe that the status of a project can be determined from
these interim deliverables. The main reason is that they are tangible and can
be measured by “thud factor” and the complexity of their contents. The analysis
documents do not show what is unknown about the project, that is, the true
risks associated with the project. The analysis documents also state the
requirements as absolute that makes them difficult to challenge by the
development team. Users place undue confidence in the documents because so much
effort has been placed in them. Business Analysts in Waterfall methodologies
invest significant effort in the documents because they are the visible means
by which they will be judged. Business users, project managers and business
analysts all focus on the documentation which causes a reinforcing spiral. Huge
amounts of effort are placed in making sure the last T is crossed and I is dotted. None of this effort makes its way into the final
software. The end result is that business analysts spend a majority of their
time on creating documentation rather than performing analysis, that is,
learning about the problem[Matts,2003].
Agilists see the Analyst role as creating documentation. This is
because Waterfall Business Analysts spend the majority of their time creating
documentation. They do not see real value activity that is learning about the
problem. Agile analysis is
highly iterative and incremental process where developers and project stakeholders
actively work together to understand the domain, to identify what needs to be
built, to estimate that functionality, to prioritize the functionality, and in
the process optionally producing artifacts that are just barely good enough. What
agile analysis isn’t is:
It
isn’t a phase of a project
It
isn’t a task on a project schedule
It
isn’t a means unto itself [Ambler, 2006c]
What is agile
analysis? An
agile analysis effort exhibit the following traits:
- Agile analysis should be
communication rich.
Agile developers prefer warm communication techniques such as face-to-face
discussion and video conferencing over cold techniques such as
documentation and email. Agile developers prefer to work as closely as
possible to their project stakeholders, following AM’s active stakeholder
participation practice wherever possible.
- Agile analysis is highly iterative. Analysis and design
activities both rely on each other: estimating is part of analysis yet
that relies on some design being performed to identify how something could
be implemented and your design efforts rely on sufficient analysis being
performed to define what needs to be built. Hence analysis is
iterative.
- Agile analysis is incremental. Agile analysis is
incremental, that you don’t need to build systems all in one go.
This philosophy supports the incremental approach favored by common agile
software processes where the work is broken done into small, achievable
“chunks” of functionality. These chunks should be implementable within a short period of time, often as
little as hours or days.
- Agile analysis explores and
illuminates the problem space.
Your primary goal is to identify and understand what your project
stakeholders need of your system. Furthermore, this information
needs to be communicated to everyone involved with the project, including
both developers and stakeholders. This promotes understanding of,
and agreement with, the overall vision of your project.
- Agile analysis includes estimation
and prioritization of requirements. It is during estimation and prioritization of
requirements where software development becomes “real” for project
stakeholders. It is very easy to say that you want something but
much hard to agree to a price for it, let alone to trade it off for
something that is immediately more important to you.
- Agile analysis results in artifacts
that are just good enough.
If any artifacts are created at all as the result of the agile analysis (by
following the AM practice discard temporary models after all) they should
be either agile models or agile documents. Such artifacts are
typically far from perfect, they just barely fulfill their purpose and no more[Ambler,2004d].
The agile way
of thinking breaks both the temporal constraint, and the structural coupling of
analysis. In an agile project the analysis is not done all up front, nor is it
directly map-able to the internal structure of the software[Agarwal et al 2000].
In an agile
project, analysis is performed through collaboration between the business stakeholders
(possibly represented by business analysts), and the developers. Together they
identify features that the system will be required to perform. Features are
broken down into small tasks that can be completed in a month or less. The
developers estimate these tasks based upon past history in order to establish
their cost. Then, the stakeholders decide the priority of the tasks by weighing
their cost against their importance to the business. This priority then sets
the order in which the tasks will be developed.
Clearly, in
order to establish tasks that are less than a month in length, and then
estimate those tasks, a considerable amount of design must be performed. This
includes at least a rough understanding of the datasets, data transformations,
and user interfaces that the application must deal with. Thus, completion of
analysis depends upon design.
At the same
time a significant amount of business analysis must be performed to understand
what the features and tasks must be before they can be estimated. Thus, design
depends upon analysis. This mutual dependence of analysis and design completely
breaks the temporal constraint. Neither can be done without the other.
On the other
hand, the design required to break the system into small tasks, and estimate
those tasks does not necessarily imply anything about the internal structure of
the software. It need not identify classes, relationships, and methods. Rather
those tasks, and their estimates, describe external behaviors that are visible
and demonstrable to the stakeholders. The temporal constraint is further
weakened because the system can be designed, analyzed, and implemented
concurrently. It is not necessary for all the features to be estimated and
broken down into tasks before implementation begins. Indeed, the stakeholders
could choose a few of the most important features. The team could break them
into tasks, estimate them, prioritize them, and choose a month’s worth of the
highest priority tasks to implement. Indeed, in an agile project they repeat
this activity[Ambler,2002b].
Steps of Agile System Analysis Process
While software system analysis is a
complex and hard activity, people use it many years, so there should be some
patterns and guides. In fact the process can be described with just several
steps. All of them are important and in general could not be skipped[Dubakov, 2006].
1. Identify System Users
This is the most important question. If
you miss with users, you will build the wrong solution. All further analyses
will relay on defined user roles, so be very careful with this first step.
Typical questions:
Who
will use the system?
2.
Define Main Users Goals
Each user in the system has specific
goals. One user role will use system not very frequently to solve just a few
problems, while another user role will use system about 2 hours per day and
resolve many complex problems. Why user will use this system? What problems
will it solve? Typical questions:
What
I (as a user ___) want to achieve with help of the system?
3.
Define System Usage Patterns
Each user has common behavioral patterns.
For example, Manager comes at work and start checking yesterday results. Or
Frequent Flyer wants to optimize travel expenses for the next month, or sales person
having a call with existing unhappy customer. Or Resource Manager handles requests
on additional developers for 3 projects simultaneously. All these are typical
usage patterns. This is the best starting point for functional solution. You
clearly see the real problems, you understand them well, you have all you need
to be creative and invent simple, effective and elegant solution. Typical
questions:
What
are the typical user behaviors (daily, specific situations, etc.)?
4.
Invent Functional Solution to Meet Users Goals and Usage Patterns
This is just a logical continuation of
previous step, but maybe the most complex step. Here you think how to solve
exact problem, discuss the solution, jump to steps 5-6, refine the solution,
write down it and move to the next usage pattern. Typical questions:
What
is the best way to satisfy usage pattern?
5.
Define Main Navigation Paths
This and next steps usually performed
together with step 4. Usually it is hard to invent great solution without
tracking user paths and sketching some UI areas. In fact it is better to stay
off UI as far as you can. In discussions replace all phrases like "Then
User clicks Leads link in the top menu and sees leads list" with
"Then User sees leads list". Concentrate on information user need on
each step, not on links and clicks. Good navigation path looks like this:
User:
- Quickly
add new lead into the system
- See leads
list
- Find
leads added yesterday
- See
additional details for each yesterday lead
There is no UI in the list above, just
information. Typical questions:
What
functional areas/action should user execute to complete usage pattern?
How
many areas required to complete user goal in specific
pattern?
6.
Create UI Mockups
UI mockups are great to have a quick look
at possible users/system interaction. Dashboard sketches are perfect. Forget
about cool tools like Visio, Dreamweaver or any other UI prototyping tool. Dashboard
sketches are the fastest, easiest and exciting thing to work with. You will
group around dashboard with markers in hands and discuss where to place system
settings link with great enthusiasm. Everyone can draw with a marker, but it is
just not possible with computer. With marker in hand everyone feels that s/he
can improve this UI and bring in cool ideas. Here is the place where team
spirit rises! Draw UI sketch, make a photo on digital camera and put all photos
in a single shared space.
7.
Polish UI Elements
There is always a possibility to make
things better, to improve something here and there. It is a good attitude. You
should think about UI details of most important features that will be
implemented right after the project start. But be careful,
don't spend much time on UI perfection, likely it will change during
development anyway. And never polish UI for features that will be implemented
in 3+ months ahead of current date, with great possibility it will be a waste
of time. Typical questions:
Can
we improve UI to reduce clicks, provide better visibility, etc?
After all the steps above you will end up
with solid understanding of future system, with the most important artifacts in
hands and clear starting point.
Artifacts
from Agile Analysis:
The
artifacts created taking an agile approach to analysis are different than the
ones created as the result of traditional analysis in a way. They are in
fact the same types of artifacts, a use case diagram is a use case diagram
after all, but the way in which they are created are
different. The artifacts are created following the principles and
practices of AM; they are just barely good enough and are often discarded so as
to travel light[Ambler, 2002a].
Table
1 lists common artifacts used during analysis modeling
and suggests a simple tool with which you could create such an artifact
Table
1. Candidate artifacts for analysis modeling[Ambler,19].
|
Artifact |
Simple Tool |
Description |
|
Activity
Diagram |
Whiteboard |
UML
activity diagrams are used during analysis modeling to explore the logic of a
usage scenario (see below), system use case, or the flow of logic of a
business process. In many ways activity diagrams are the
object-oriented equivalent of flow charts and data-flow diagrams (DFDs). |
|
Class
Diagram |
Whiteboard |
Class
diagrams show the classes of the system, their inter-relationships (including
inheritance, aggregation, and association), and the operations and attributes
of the classes. During analysis you can use class diagrams to represent
your conceptual model which depict your detailed understanding of the problem
space for your system. |
|
Constraint
definition |
Index
card |
A
constraint is a restriction on the degree of freedom you have in providing a
solution. Constraints are effectively global requirements for your
project. |
|
CRC
model |
Index
cards |
A
Class Responsibility Collaborator (CRC) model is a collection of standard
index cards, each of which have been divided into three sections, indicating
the name of the class, the responsibilities of the class, and the
collaborators of the class. Like class diagrams, CRC models are used
during analysis modeling for conceptual modeling. |
|
Data
flow diagram (DFD) |
Whiteboard |
A
data-flow diagram (DFD) shows the movement of data within a system between
processes, entities, and data stores. When analysis modeling a DFD can
be used to model the existing and/or proposed business processes that your
system will support. |
|
Entity/Relationship
(E/R) diagram (data diagram) |
Whiteboard |
E/R
diagrams show the main entities, their data attributes, and the relationships
between those entities. Like class diagrams E/R diagrams can be used
for conceptual modeling, in many ways E/R diagrams can be thought of as a
subset of class diagrams. |
|
Flow
chart |
Whiteboard |
Flow
charts are used in a similar manner to activity diagrams. |
|
Robustness
diagrams |
Whiteboard |
Robustness
diagrams can be used to analyze usage scenarios to identify candidate classes
and major user interface elements (screens, reports, ...). |
|
Sequence
diagram |
Whiteboard |
Sequence
diagrams are used to model the logic of usage scenarios. Sequence
diagrams model the flow of logic within your system in a visual manner,
enabling you to both explore and validate your logic. |
|
State
chart diagram |
Whiteboard |
State
chart diagrams depict the various states, and the transitions between those
states, that an entity exhibits. During analysis modeling state chart
diagrams are used to explore the lifecycle of an entity that exhibits complex
behavior. |
|
System
use case |
Paper |
A
use case is a sequence of actions that provide a measurable value to an
actor. A system use case includes high-level implementation decisions
in it. For example, a system use case will refer to specific user
interface components – such as screens, HTML pages, or reports. System
use cases will also reflect fundamental architectural decisions, such as the
use of ATMs versus cell phones to access your bank account. |
|
UI
prototype |
Whiteboard |
A
user interface (UI) prototype models the user interface of your system.
As a part of analysis modeling it enables you to explore the problem space
that your system addresses in a manner that your project stakeholders
understand. Remember, the user interface is the system to most
people. |
|
Usage
scenario |
Index
card |
A
usage scenario is exactly what its name indicates – the description of a
potential way that your system is used. |
|
Use
case diagram |
Whiteboard |
The
use-case diagram depicts a collection of use cases, actors, their
associations, and optionally a system boundary box. When analysis
modeling a use case diagram can be used to depict the business functionality,
at a high-level, that your system will support. It can also be used to
depict the scope of the various releases of your system via the use of color
or system boundary boxes. |
Towards
Agile Analysts
Fundamentally
the activities performed by traditional business software analysts (BSAs) are varied, but a crucial goal was always to improve
the communication between developers and project stakeholders. In many
“traditional” organizations that meant that BSAs
formed a bridge between the two groups, a definite improvement in many
situations, although at the same time erected barriers. Now is the time
to take the next step, to become more agile and have BSAs
become the communication mentors/coaches on project teams[Ambler,
2002a].
Agile
methodology (AM) suggests that development teams follows
the practice ‘active stakeholder participation’ that they work closely with
their project stakeholders. The goal of this practice is to reduce the
feedback loop and thereby improve communication. However, the way that
you work with your stakeholders will in part be determined by your team’s
organization. An interesting implication is that the role that a BSA
takes on changes dramatically based on the communication options available to
your team. There are three categories of team organization that need to
be considered with respect to how an “Agile BSA” will act on a project team[Ambler, 2006]:
One
room – Developers and Stakeholders are Co-Located
Over
the wall – Single Location But Not Co-Located
Across
the network – Dispersed/Distributed Development
Agile
software development teams embrace change, accepting the idea that requirements
will evolve throughout a project. Agilists
understand that because requirements evolve over time that any early investment
in detailed documentation will only be wasted. Instead agilists will do just enough initial modeling to identify
their project scope and develop a high-level schedule and estimate.During
development they will model storm in a just-in-time manner to explore each
requirement in the necessary detail[Fernandez, 2001].
Because
requirements change frequently you need a streamlined, flexible approach to
requirements change management. Agilists want
to develop software which is both high-quality and high-value, and the easiest
way to develop high-value software is to implement the highest priority
requirements first. Agilists strive to truly
manage change, not to prevent it, enabling them to maximize stakeholder ROI.
Figure 1 overviews the agile approach to
managing requirements, reflecting both Extreme Programming (XP)’s
planning game and the Scrum
methodology. The software development team has a stack of prioritized and
estimated requirements which needs to be implemented – XPers
will literally have a stack of user stories written on index cards.
The team takes the highest priority requirements from the top of the stack
which they believe they can implement within the current iteration. Scrum
suggests that one should freeze the requirements for the current iteration to
provide a level of stability for the developers. If this is done then any
change to a requirement being currently implementing should be treated as just
another new requirement[Cockburn 2002].
Why
Requirements Change
People
change their minds for many reasons, and do so on a regular basis. This
happens because[Miller, 2001]:
- They missed a requirement. A stakeholder will be
working with an existing system and realize that it's missing a feature.
- They identified a defect. A bug, or more importantly
the need to address the bug, should also be considered a requirement.
- They realize they didn't understand their
actual need. It's
common to show a stakeholder your working system to date only to have them
realize that what they asked for really isn't what they want after
all. This is one reason why active
stakeholder participation and short iterations are important to your
success.
- Politics.
The political landscape within your organization is likely dynamic (yes,
I'm being polite). When the balance of political power shifts
amongst your stakeholders, and it always does, so do their
priorities. These changing political priorities will often motivate
changes to requirements.
- The marketplace changes. Perhaps a competitor will
release a new product which implements features that your product
doesn't.
- Legislation changes. Perhaps new legislation
requires new features, or changes to existing features, in your
software.
The
bottom line is that if the requirements are frozen early in the lifecycle, then
one is pretty much guaranteed that the system built will not be what people
need, instead it would be what the users wanted initially. That's not a great strategy for success.
Agile Requirements Best Practices[Ambler, 2005 e]:
1. Stakeholders
actively participate
3. Take
a breadth-first approach
4. Model
storm details just in time (JIT)
5. Your
goal is to implement requirements, not document them
6. Create
platform independent requirements to a point
10. Adopt
stakeholder terminology
13. Turn
stakeholders into developers
14. Treat
requirements like a prioritized stack
Agile
Risks, Agile Rewards[Smith, 2005]:
In managing project risks on various
projects, some common risks tend to occur in most of the projects in the
following areas.
Product Definition
Product
managers lack experience in creating user stories.
User
interface requirements currently unclear.
Regional
markets not yet decided.
Development
Technology
issues such as remote communication, data access and component frameworks.
Product
managers located remotely.
Some
team members not assigned full time.
Communication
issues due to language barriers.
Quality
Variations
in applying the unit test framework.
Providing
functionality competes with delivering high quality.
Environment
Inadequate
modeling tool for applying agile software engineering practices, such as
test-driven development.
Software
production unstable due to differences between developer-build and
production-build environments.
Test
hardware not available in time.
Sales
and Distribution
Launch
programs not yet defined.
Sales
staff training measures open.
User
and service documentation may not be translated into all target languages in
time.
10 Tips for Successful
Agile Analysis[Ambler, 2004d].
1. Active stakeholder participation is
crucial.
You need to work together closely with your stakeholders to explore the
business domain in detail. They must be available to supply information, to
model with you, to provide feedback, and to make timely decisions.
2. Agile software development is an
evolutionary process.
When you're analysis modeling on an agile project, you'll typically focus
on a very small subset of the requirements at a time. For example, on an XP
project, you and your programming pair may work with a project stakeholder to
analyze a single user story, one of hundreds, and then move on to design and
implement it. This analysis effort often takes several minutes, depending on
the nature of the user story, as does the design effort. Then you'll spend
several hours or days implementing the requirement only to start again with a
new user story. Other agile approaches, such as Feature-Driven Development ( http://www.featuredrivendevelopment.org
), may invest a bit more time in analysis and design but they still work in a
similar, evolutionary manner.
3. Analysis isn't a phase.
Analysis is something you'll do on a daily basis as an agile developer, because
you're working in an evolutionary manner. It involves working with your
stakeholders, as well as your fellow developers, to understand the problem
domain whenever you need to. Analysis could be something as simple as asking a
stakeholder, "What did you mean by this?", or as complex as drawing
several diagrams to explore an aspect of what you're building. It's a much more
informal than formal process, requiring open and honest communication.
4. Multiple models.
Effective developers realize that each type of model has its strengths and
weaknesses; therefore they need to apply the right model(s) for the job at
hand. Because software development is complex, you quickly realize that you
need to know about a wide range of models in order to be effective.
5. You typically need only a subset of the
models.
Although there are many modeling techniques available to you,
the fact is that any given project team will require only a subset.
Think of it like this: In your toolbox at home, you have a wide array of
screwdrivers, wrenches, pliers and so on. For any given repair job, you'll use
only a few of those tools -- different jobs, different tools. You never need
all of your tools at once, but over time you'll use all of them in a variety of
manners.
6. Models evolve over time.
You may start with an essential use case but quickly decide to evolve it into
several system use cases. Or you may decide to develop a collection of
Object-Role Model (ORM) diagrams on a whiteboard as input into your
design-level UML class diagram, which in turn will evolve into Java source
code. It's quite common to discard the interim artifacts and keep only the
final products -- remember Agile Modeling (AM)'s Travel Light principle.
7. Analysis models need to be just barely good
enough.
Keep your models as simple and lightweight as possible. Focus on understanding,
not documentation. Use the simplest, most inclusive tools available. Recognize
that your models don't need to be perfect.
8. Each model can be used for a variety of
purposes.
Data flow diagrams can be used as both an analysis technique to explore your
existing business processes as well as a design technique to redefine them.
Similarly, Class Responsibility Collaborator models can be used for both
analysis and design and use cases for requirements, analysis and sometimes even
design.
9. Modeling lines are often blurred.
The traditional concept of development phases -- requirements, analysis,
designs, coding, testing and deployment -- has left many people with the idea
that we need to distinguish among various types of modeling. Yet when a
stakeholder describes a requirement, such as the need to capture a student's
home address, we'll often work through the phases within seconds of each other.
We'll start thinking about what the user interface should look like, the
various data elements that will be captured, the need for an Address class, the
possibility of applying the Contact Point pattern, the need for an Address
table in the database, and how to code it all in Java, moving from requirements
through analysis through design to code without stopping to create a complete
requirements model or a complete analysis model, and so on. While it's
important to ask questions such as what do you need (requirements), what does
that mean (analysis), and how are we going to build it (design), often we'll be
doing so in an iterative, not a serial manner.
10. Use your stakeholders' terminology.
Don't force artificial, technical jargon onto your project stakeholders.
They're the ones the system is being built for; therefore, you should use their
terminology to model the system.
The
nature of analysis has changed. Several decades ago analysis was seen as
a transformational process within a serial project lifecycle. With the
rising popularity of object-orientation in the 1980s and 1990s analysis was
soon seen as part of an iterative and incremental process, and in the new
millennia the nature of analysis is transforming once again. Today
analysis is better envisioned as a highly collaborative, iterative, and
incremental endeavor involving both developers and stakeholders. The evolution
of the analysis process necessitates an evolution in the way that business
system analysts (BSAs) work, and in many situations
this role arguably disappears in favor of developers who are generalizing
specialists.
References:
- Ambler, Scot W .2006 c. Agile
Analysis.. Ambysoft.
Inc. http://www.agilemodeling.com/essays/agileAnalysis.htm
- Ambler Scott. 2004 d, May, 06. The
Agile Analysis Top 10. Dr Dobbs Portal. Architecture and Design. http://www.ddj.com/dept/architect/184415819
- Ambler Scott. 2005 e, September.
Agile Requirements Best Practices.
- http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
- Fowler, Martin.2002 The New Methodology. http://www.martinfowler.com/articles/newMethodology.html
- Matts, Chris. 2003.Why
Agilists Think Up-Front Analysis is inherently
un-Agile. http://abc.truemesh.com/archives/000105.html
- Dubakov, Michael. 2006, June 5. 7 Steps of
Agile System Analysis Process. TargetProcess. http://www.targetprocess.com/blog/2006/06/7-steps-of-agile-system-analysis.html
- Martin, Robert C. 2002, Feb 27. On
Analysis. http://www.agilealliance.org/system/article/file/834/file.pdf
- Fernandez, Edurado
B. Building Complex object Oriented Systems with Patterns and XP. 2001,
Aug. http://www.agilealliance.org/system/article/file/1084/file.pdf
- Smith,
- Dave, Thomas. 2005, May, June. Agile
Programming: Design to Accommodate Change. IEEE Software. Vol. 22, No. 3
- Highsmith J and Cockburn A.2001. Agile
Software Development: The Business of Innovation. Computer Vol 34, Iss. 9. 120-122.
- Cockburn, A. 2002. Agile Software
Development.
- Miller, D and Lee. J. 2001. The People
Make the Process: Commitment to Employees, Decision Making, and
Performance. Journal of Management. Vol. 27. 163-189.
- Favaro, J. 2002. Managing Requirements for
Business Value. IEEE Software. Vol 19. 15-17
- Ambler, S. W. 2002a. Agile Modeling:
Effective Practices for Extreme Programming and the Unified Process.
- Ambler S. W. 2002b. Lessons in
Agility from Internet Based Development. IEEE Software. Vol. 19, Iss. 2. 66-73
- Ambler, Scot W. Rethinking the Role
of Business Analysts. http://www.agilemodeling.com/essays/businessAnalysts.htm
- Ambler, S W. Artifacts of Agile
Development. http://www.agilemodeling.com/artifacts/
- Cohen, D., Lindvall,
M., & Costa, P. 2004. An introduction to agile methods. In Advances
in Computers (pp. 1-66).
- Agarwal, R and Prasad, J.2000. A field
study of the adoption of software process innovation by information
systems professionals. IEEE Transactions on Engineering Management. Vol.
47, Iss. 3. 295-308
- Anonymous. What is Agile Development. http://www.agilealliance.org/show/2
- Abrahhamson, Pekka et
al. 2002. Agile Software Development Methods: Review and Analysis. VTT
Publications.
- http://en.wikipedia.org/wiki/Agile_programming