Introduction

Overview

aim42 organizes software improvement in three major phases (Analyze, Evaluate and Improve), build around some crosscutting activities.

Why is software being changed?

Software systems, at least most of those that are practically used, are changed all the time. Features are added, modified or removed, user interaction is streamlined, performance is tuned, changes to external interfaces or systems are reflected. The reasons for changing a system can be grouped into four categories (see [ISO-14764]):

• Corrective changes
  • fixing failures within the software system
• Adaptive changes
  • data structures we rely on have been changed
  • external interfaces have been changed - our system has to cope with these changes
  • some technology, framework or product used within the system is not available any longer and needs to be replaced
• Perfective changes
  • operational costs have to be reduced
  • maintenance costs have to be reduced
  • existing documentation does not reflect the truth (any more)
  • resource consumption needs to be optimized
  • system needs to work faster
  • system needs to become more reliable or fault-tolerant
  • people need new features
  • system needs to be integrated with new neighbour
  • system needs to comply to new regulations or laws
  • system needs new or improved user interface
  • existing features have to be modified or removed
• Preventive changes
  • technical debt has to be reduced

You see - lots of good reasons :-)

Why does software need improvement?

The most important reason is depicted in the following diagram: The cost-of-change of most software increases heavily over time… making those people really unhappy that have to pay for these changes (called maintenance, evolution, new-features or else).

An additional effect of long-term maintenance of software is the strong decrease in understandability: When a system matures it becomes more and more difficult to understand its inner workings, changes become increasingly risky and consequences of changes become difficult to foresee which can lead to quite blurry effort estimations.

These negative effects share a few common root causes:

1. lack of conceptual integrity
2. internal disorder
3. overly complex internal structure, either of source code or data
4. overly complex concepts (cross-cutting solutions for fine-grained problems)
5. overly complex or inappropriate internal processes
6. inappropriate selection of technology (frameworks, libraries or languages)
7. (you surely can find a few more…)

Long-term Goal

In the beginning, though, everything was fine: nice coupling and cohesion, appropriate technologies, well written code, understandable structures and concepts (see figure Goal: Maintainable Software)

But as more and more changes, modifications, tweaks and supposed optimizations were performed under growing time and budget pressure, things got nasty. The maintainers piled up so called technical debt (we software folks call it quick-hacks, quick-and-dirty-fixes, detours or abbreviations). We’re quite sure you know what we’re talking about - we experienced it over and over again, it seems to be the normal situation, not the (bad) exception.

Investment in methodical and systematic software architecture improvement will have the following effect.

How does aim42 work?

Three Simple Phases

aim42 works in a phased iterative manner:

1. Analyze: collect issues: problems, risks, deficiencies and technical debt within your system and your development process. Focus on problems in this phase, not on potential solution approaches. In addition, develop (and document) an understanding of internal structures, concepts and architectural approaches.
2. Evaluate: determine the “value” of issues and their solutions (improvements)
3. Improve: systematically improve code and structures, reduce technical debt, remove waste and optimize.

These three phases are performed iteratively - as explained below. Several cross-cutting practices and patterns should be applied in all phases, for example documenting results, Collect Opportunities for Improvement or long- and short-term planning activities.

Common Terminology

aim42 relies on a common terminology, a small set of fundamental concepts.

An issue is any problem or risk in the system or the processes around it, and a cause is the reason behind one or several issues. An improvement resolves issues, at a cost, and may change risks on the way. Issues have a cost too: the pain they cause over time. The domain model defines these terms in detail.

Iterative Approach

In compliance with modern agile development methodologies, aim42 fundamentally depends on iteration and feedback between the phases.

Within each phase, you collect both issues and opportunities for improvement, as depicted in the illustration below:

Issues and improvements need to be

• related to each other: No idea of improvement without an existing issue - as we do not want to optimize “because we can”.
• evaluated in some business-compatible unit (e. g. Euro, $) as described above. See Evaluate.

Patterns and Practices Provide No Guarantee

We are very sure that aim42 can work for your system or your organization. But (yes, there’s always a but) we cannot guarantee: Maybe your software is so extraordinary, so very special, that it needs other treatments.

Maybe your organization does not fit our prerequisites or is way more advanced than we anticipated in our approach…

You have to use all practices, patterns and approaches of aim42 at your own risk and responsibility. We (the aim42 contributor team) can by no means be held responsible for any results of applying aim42.