Page 1 of 1

Application Life-Cycle Management - "Steps" Doing Projects

PostPosted: Thu Jan 31, 2013 10:01 am
by RaulC
Application Lifecycle Management (ALM)

Refers to the whole life of an Application. Since the moment any time or money is invested to it's very end (as in Dead).

ALM goals are: Maximize profit and Minimize errors by keeping activities synchronized.

ALM Tools: Allow high work flow between the activities. Using various “single-activity” tools is fine, as long as they are Integrated.

ALM activities are:

Governance (or Administration)

Starts before the Development Process and goes all the way until the Applications death (completely off-market and unsupported).

Match technology with project goal (stability, scalability, agility, efficiency).
Rules and Standards.
What to do and how to do.
Available resources (Deployment location, database, repository, integration)
Time and money expenses.
Shutting down dead Applications.


Starts shortly after Governance's start. Then comes back over and over again with every update.
Here, we can apply some Waterfall model (traditional way and easier to understand) , or do it with iterations (nowadays way).

The most basic Waterfall model would be:

1. Requirements – (Collect info, ideas, brainstorm, or just asking the client what he wants)
2. Design – Usually translates into using UML tools to specify our application. But also includes mock-ups, and I personally recommend making a Project Glossary (ex.: avoids “Life” being mistaken with “HP”)
3. Implementation (Code, do maps, models, music, the usual things everyone starts doing right away)
4. Integration/Validation (Put everything together, and check for bugs)
5. Maintenance (Go back if needed, apply fixes, give support,...)

Operations (or Maintenance)

Starts right after Deployment and extends to the Application's death.
Includes Managing and Monitoring your Application.


NOTE 1: None of this are strict rules. But rather a (very resumed, adapted and simplified) study I made based on professional standards and best practices. Even conceited Authors have lots of names for the sames things, but they all end up agreeing on those standards.

NOTE 2: 1. Requirements may often take place in Governance. And 5.Maintenance in Operations.

Personally I think this is very important. If you disagree or think there's something missing or wrong in this context, please give some Feedback.
Hope you enjoy it, and specially that it helps people :)

by Raul Cardoso