AFrame is a Solution development lifecycle that represents the "systems part" of a business
change and sits inside the broader business change cycle. AFrame
provides an "unambiguous language" within an organization. It forges links and
creates common understanding among all stakeholders of a project. This enables
IT to achieve a repeatable and predictable process that removes risk early in
the project lifecycle. AFrame is a scalable framework that can be
applied to all types of projects.
AFrame is structured in two dimensions: phases,
which represents the major steps that a project goes through over time, and activities,
which represent the logical activities that take place throughout the project.
The serial aspect of the lifecycle is captured in its phases and the iterative
nature of the lifecycle by the activities.
The phases of the lifecycle are like the seasons of the year. For
example, during Solution Planning youíll do the same sorts of activities that
you do during Build Solution, but the extent that you do them, and the order in
which you do them may change. During Solution Planning a project team will
spend a lot of time writing initial use cases in order to understand the scope
of their system, but if they write any code at all it is likely for user
interface (UI) prototyping. During Build Solution any use case work will likely
be to finalize the definition of a use case before writing the detailed source
code which implements it. During both phases you work on use cases and source
code, but in different ways.
Each phase ends with a well-defined milestone. At these points, the
stakeholders assess the project, including what has been done and the plans for
moving forward. A go/no-go decision is made about whether to proceed with the
project. Each phase has a specific set of goals and deliverables, which are
addressed within the iterations of the phase, so that the phase milestone may
There are three observations to be made concerning the phases:
1. Activities continue in each phase.
AFrame phases can be divided into one or more
iterations, although the term "increment" is more appropriate. Iterations
address only a portion of the entire system being developed (unlike the
waterfall approach, which attempts to do it all at once). Each iteration stage
has a fine-grained plan with a specific goal. Iterations build upon the work
done by previous iterations and assemble the final system incrementally. When
an iteration ends, in particular during the Build phase, a small subset of the
system has been completed which could conceivably be deployed to users as a
release, even if only as an alpha or beta version.
During a phase and sub-iterations you will alternate back and forth
between the activities (eg Requirements, Design, Build), performing each task
to the extent needed at the time, to achieve the goals of that iteration.
The activities are:
- Business Modelling
- Analysis and Design
- Configuration and Change Management
- Project Management
2. Work products evolve during each phase.
Work products Ė models, plans, source
code, and documents Ė evolve throughout the life of your project. Work products
arenít finished until you release your system into production, in fact you may
find that youíll be doing requirements modeling the day before you release.
3. Each phase ends with a go/no-go decision.
Your stakeholders must agree to move
forward into the next phase. This may entail reworking your strategy for
running the project, or they must agree to cancel the project. A project may be
cancelled because itís not acceptable due to quality concerns (e.g. lack of
appropriate documentation), it is deemed too expensive to deploy and/or support
(Business Case no longer valid), or the strategic direction for the company may
have changed. Although it is rare, it is possible that a project may even be
cancelled at the end of the Deploy phase.