Application Lifecycle Management-ALM
What is ALM?
ALM (application lifecycle management) represents the complete lifecycle of a product or an application, from conception through retirement. The term is used in the context of software applications, but it can be used in other types of systems as well.
The lifecycle of an application in many cases, includes these phases:
- Requirements specification
1. Requirements specifications
Start from the idea and the drawing board, make the business case and go from there to derive the requirements.
An application’s lifecycle should start from the drawing board, where the relevant stakeholders define what they need to have in the application to support their business cases. This is the source for creating the requirements.
Usually, requirements specification is done top-down, and this is the reason that in many cases requirements are shown as a hierarchical tree structure, where each node is a sub-requirement for it’s larger parent node.
Still, some development approaches, mainly the iterative ones, prefer to see requirements as “flatter structures” where the requirements are structured as Use Cases, and if necessary aggregated as Epics.
Part of good requirements specification practice is to categorize them (e.g., by module, feature, etc.) and to prioritize them: what is a must, what can come later, etc. In cases like these, a single hierarchical tree might not be convenient enough, and an alternative method (like PractiTest’s hierarchical filters) can provide a more appropriate solution.
2. Development phase
After the first stage, it’s time to start development of the application.
At the beginning, the team sits together and breaks down the application’s requirements into pieces and phases. A good practice at this point is to have representatives from the different teams present: development, testing, product marketing, support, IT, sales, etc. The idea here is to validate that the application being developed will answer all the real needs, and will be easy to use, test and deploy.
During the development phase, testers should begin preparing their tests-cases and environments for the testing phase. They should also be in constant contact with the developers, providing feedback on the application and if needed helping them to validate the features developed even before they are “formally released” to the testing team.
There are many different development methodologies, each of them with their own pros and cons (though this is outside the scope of this article). The most popular ones are: the iterative based (such as Agile), and the sequential (such as Waterfall).
3. Testing phase
During the testing phase, the testers’ role is to verify that the application complies with the requirements defined in the initial steps of the process. They also need to ensure that, even if this is not explicitly defined in the requirements, the application will meet the expectations of the users and all the other stakeholders that will need to support it throughout its lifecycle.
Testing actually starts during the development phase of the application’s lifecycle when developers should run unit and integration tests as part of their programming activities (today it is not uncommon to find Continuous Integration systems in many development teams). This is complemented by the work of the testing team which runs their verifications of all the features developed, as well as full integration testing of the entire system, once development is completed.
During the testing phase, the testers identify and report issues that need to be addressed by development. In cases where it is not clear whether the issues should be fixed (or even if there are bugs at all), the team should call upon experts from other departments to provide their input. The development and testing phases will end once the application reaches a quality and stability level that is good enough* for release. It is not practical or economical to aim for developing “perfect” products.
If all the phases up to this point of the application’s lifecycle (requirements, development and testing) were correctly performed, then this will ensure that the deployment and maintenance phases will be easier, smoother and as a result, less expensive.
(*Good enough is defined by the product marketing!)
4. Deployment and roll-out
The deployment and roll-out depend on the type of product:
- “On-Premises” Client-Server or Web-based application that needs to be released in some kind of installable format and then distributed, installed and configured on the customers’ server
- SaaS products – that need to be deployed on the internal servers of the company
- Client applications distributed to customers (via CD / Download)
- Non-software products with their own individual deployment and distribution process.
Each product type deployment has different attributes and specifications.
Maintenance is traditionally the longest stage of ALM, but it is also the one where the participation of the testing and development teams is usually the lowest.
As we said before, if the work during the previous phases was done effectively then the amount of product maintenance will be significantly less. Basically the closer the system is to the actual needs of the user, and the more issues that were caught during the testing / development phases, the fewer problems we will see during the maintenance and roll-out processes.
An important part of the maintenance phase is to define what is called retirement of the system which, basically is the time when users should stop working with the product and move either to a newer version or migrate to a different product altogether.
Application Lifecycle Management Tools
There are many products claiming to be ALM (application lifecycle management) tools, but the accepted industry standard that entitles a product to be called an “ALM tool” is that the tool:
- Covers more than one application lifecycle management phase
- Allows users to see the traceability between the different phases
- Shows entities history (i.e., who changed what and when)
PractiTest also has visibility into the traceability between each of the entities and in addition, maintains the history of every item and traceability between the types. For example, a Test can be connected to Requirement(s), validating that all requirements are tested.