Page 84 - DCAP405_SOFTWARE_ENGINEERING

Unit 5: An Agile View of Process

FDD suggests exact programmer practices such as “Regular Builds” and “Component/Class Notes
Ownership”. FDD’s proponents claim that it scales more uncomplicatedly than other approaches,
and is better suited to larger teams. Unlike other agile approaches, FDD explains specific, very
short phases of work which are to be accomplished separately per feature. These include Domain
Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.

5.2.7 AM

Agile Modeling (AM) is a practice-based process for effectual modeling and documentation of
software-based systems. Simply put, Agile Modeling (AM) is a anthology of values, principles,
and practices for modeling software that can be applied on a software development project in an
effective and lightweight manner. As you see in Figure 5.3 AM is meant to be tailored into other,
full-fledged methodologies such as XP or RUP, enabling you to develop a software process
which truly meets your needs.

Figure 5.3: AM Enhances other Software Processes

The principles of AM, adopting and extending those of extreme Programming v1, are
communication, simplicity, feedback, courage, and humility. The keys to modeling success are
to have effectual communication between all project stakeholders, to strive to expand the simplest
solution possible that meets all of your needs, to obtain feedback regarding your efforts often
and early, to have the courage to make and stick to your decisions, and to have the humility to
admit that you may not know everything, that others have value to add to your project efforts.
AM is based on a collection of principles, such as the significance of assuming unfussiness when
you are modeling and acceptance change as you are working because requirements will change
over time. You should recognize that incremental change of your system over time enables
agility and that you should strive to obtain rapid feedback on your work to ensure that it
precisely reflects the needs of your project stakeholders. You should model with a purpose, if
you don’t know why you are working on something or you don’t know what the audience of the
model/document actually requires then you shouldn’t be working on it. Furthermore, you
need numerous models in your intellectual toolkit to be effective. A critical concept is that
models are not necessarily documents, a realization that enables you travel light by discarding
most of your models once they have fulfilled their purpose. Agile modelers believe that content
is more significant than representation, that there are many ways you can model the same
concept yet still get it right. To be an effective modeler you need to recognize that open and
honest communication is often the best policy to follow to ensure effective teamwork. Finally,
a focus on quality work is important because nobody likes to produce sloppy work and that
local adaptation of AM to meet the exact needs of your environment is important.
To model in an agile manner you will apply AM’s practices as suitable. Fundamental practices
comprise creating numerous models in parallel, applying the right artifact(s) for the situation,
and iterating to another artifact to continue moving forward at a steady pace. Modeling in small
increments, and not attempting to create the magical “all encompassing model” from your
ivory tower, is also fundamental to your success as an agile modeler. Because models are only
abstract representations of software, abstractions that may not be accurate, you should strive to

LOVELY PROFESSIONAL UNIVERSITY 77