Database Reference
In-Depth Information
Table 6: Agile and traditional methods
Agile methods
Plan-driven methods
Developers
Agile, knowledgeable, co-located, and
collaborative
Plan-oriented, adequate skills, access
to external knowledge
Customers
Dedicated, knowledgeable, co-located,
collaborative, representative and empowered
Access to knowledgeable,
collaborative, representative, and
empowered customers
Requirements
Largely emergent, rapid change
Knowable early; largely stable
Architecture
Designed for current requirements
Designed for current and foreseeable
requirements
Refactoring
Inexpensive
Expensive
Size
Smaller teams and products
Larger teams and products
Primary objective
Rapid value
High assurance
mentation environment. These are so-called plan-driven (or design-driven) methods, where
the requirements at the beginning of the project are largely stable so that the fi xed, well-
thought plan can be followed during the development process (Boehm, 2002). Both types
of methodologies, agile and traditional, have their advantages and shortcomings depending
on particular project settings. Making a decision of using a particular method in a software
development project is in strong relation with the project nature, project environment and
involved stakeholders (Boehm, 2002) (Table 6).
Both agile methods and more traditional methods try to handle the software development
process under the constant changes in the environment. However, their focus is different as
to what types of changes they primarily deal with. Agile methods are focused on potential
changes of business requirements that can evolve during the project up to the fi nal release.
Therefore, they propose mechanisms to fl exibly capture these requirements, while the
challenges in making technology choices are left implicit, and are under the responsibility
of developers. On the other hand, more traditional, model-driven methods try to preserve
efforts made in constructing software architecture and design under the changes in available
advanced technology solutions. For these methods, business requirements are more or less
fi xed, written down in the form of contract between business users and developers. In real-
ity, it is essential to provide an effective strategy and mechanisms for protecting software
solutions from possible changing requirements coming from both sides. In the sequel of the
paper, we propose an implementation-independent, component-based approach for creat-
ing fl exible system architecture in an agile way and therefore provide a way of balancing
between business needs and technology solutions. Components as design level artifacts, not
just implementation code packages as suggested by the UML, can become a central point
of a new agile, service-oriented development approach.
INTEGRATING COMPONENTS
AND AGILE DEVELOPMENT
Common to all agile methodologies that propose some development practice is that
they assume an object-oriented development paradigm. XP creates CRC cards and object
diagrams, FDD combines objects and features, Agile Modeling extends the standard UML
