Application lifecycle management (ALM) is not to be confused with the software development lifecycle (SDLC). While ALM is embedded within the SDLC, it is actually a more detailed interface that dictates how application development is conducted. In today's world, we can manage our application development in several different ways. Each company, manager and department has its own method of supervising what they do and how they conform with company standards when developing an application. For example, a company that develops software using a waterfall SDLC is quite different than a company that develops software using an agile SDLC.
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, reusable lifecycle.
- 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.