Application Life-Cycle Management - "Steps" Doing Projects

Application Life-Cycle Management - "Steps" Doing Projects

Postby RaulC » Thu Jan 31, 2013 10:01 am

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.


Development

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
Raul Cardoso - "Fail to Plan is Plan to Fail"
Skype: drkovr
RaulC
 
Posts: 5
Joined: Thu Jan 31, 2013 9:34 am
Location: Portugal
Profession:: Programmer

Return to Project Designers

Who is online

Users browsing this forum: No registered users and 1 guest

cron