Software tools are now coming out with ALM options, but though a tool may have an ALM component, each company will use it differently.
The methods through which a software development company uses (or doesn't use) ALM is indicative of how well its end product will meet criteria for being successful. ALM processes should be defined and agreed upon by all internal and external stakeholders involved during and after application development. A single person or role can not take the place of a multi-faceted process. Sometimes projects fall into the reins of a project manager who dictates process based on his or her view of what process should be-- though he or she is more concerned with scope, time and cost. The impact of process and ALM (how well the requirements meet the expectations of the customers) is the quality assurance department's responsibility.
Below are 11 steps that can help you achieve successful application lifecycle management.
- Define the roles that should be part of the ALM. Define who is responsible for each role
in information technology, software technology, quality assurance, software testing, the lines of
business, and on the customer's side.
- Define the goals and objectives of each role. If this step isn't followed through, then
the details of each role will not be understood and the question of "what do I do?" will never be
clear. This step helps to avoid the "he-said / she said" and finger-pointing.
- Anticipate a certain amount of internal-process dependency. Outline and illustrate what
work and which roles will depend upon your actions and deliverables. If this is not clearly
documented, other people working on the project may assume that time is not important, or
deliverables can be delayed or covered up if done incorrectly. A proper ALM process ensures that
all levels of work are done correctly and follow quality standards.
- Develop a risk and contingency plan. Every role and each step in the process has the
potential to make waves if something goes wrong. Make sure you think about how a missed deadline or
objective could be rectified without a major disruption to the overall ALM process. If the risks
are not understood from the beginning of the project, then you will be constantly working in
"ticking time bomb" environment. Problems affecting time, functionality, quality, outputs,
security, performance, schedule and cost can all add to the risk of the end product, the
application and the customers. Thus, it is always better to be proactive with a constructive,
- Prepare a process. It is important that you outline a flowing pathway of communication
and documentation. This is where the SDLC comes into play and defines how a company and/or
department will operate.
- Foresee each individual's potential output. Understand the capabilities of each person
on your team and set expectations accordingly.
- Plan … plan again … and plan some more! If you couldn't already tell, detailed planning
is a must for ALM to be successful. Each role must be defined so that when a project is
started each role's objectives, dependencies and needs are known.
- Know how communication affects your clients and other external stakeholders. When you
interface with a client and that client expects something in return, how will you involve them in
the process? Communication between you and your customers is crucial, since the earlier
your clients are involved the more they will feel a part of the process; they will be more likely
to accept your thoughts and ideas.
- Set up quality assurance checkpoints to ensure your ALM process is working. This step is
usually conducted by a quality analyst, whose job is to ensure that all processes are running like
clockwork. (A quality analyst is not to be confused with a software tester whose role should
have already been defined in step number one.) When a project is being run by a project manager,
they often want to also manage ALM – but if this occurs it is difficult to provide good quality
assurance since there is little or no opportunity for outside evaluation. Quality checkpoints by a
quality analyst help create balance within process.
- Work toward continual improvement. At the end of the first lifecycle attempt, it is QA's
responsibility to delineate what went right and what went wrong in order to correct any bumps in
the process. A "lessons learned" document should be prepared and presented to all of the key
stakeholders, internally and externally, and discussion should ensue about how to improve the
process for the next attempt. If not, then a process truly does not exist. This tends to happen if
one person or team is "running the show" rather then a collective group.
- Provide governance. After a constructive baseline is set, all process changes must go through a formal procedure to ensure new rules and changes within the company's adoption of the ALM process. This is why step number nine (quality assurance checkpoints) is so important. QA monitors the processes that put into place. Governance then works hand-in-hand with regulatory in-house and external audits for standards and assurance.
A successful ALM process is one that is understood by the all of the individuals involved in the project – not one of which is invisible, including external stakeholders such as customers. Every company is unique and the same can be said for their processes and technology; but if software development organizations start using the 11 steps outlined above, they will be on their way to better ALM design and a more successful future.
About the author:
Dr. John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.
This was first published in November 2010