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
Table of Contents
- ALM Phases:
- Application Lifecycle Management Tools
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)
Here are a few things to consider when looking to purchase an ALM:
- The ALM should be your focal point for the entire process. This is why you should choose a tool that covers or integrates with tools that cover all lifecycle management aspects such as Requirement management, computer programming, software testing and more.
PractiTest, for example, has Requirements, Issues (for the development phase), and Test Management capabilities, and integrates with any 3rd party tool you work within your development process – in other words, all the phases described above that are needed for testing.
- You should always be able to track your progress and trace your artifacts to their source and back. This traceability is crucial when trying to solve issues that arose during the development or deployment stages.
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.
- Having all the data in one place is not enough. You need to be able to make sense out of it by dynamically organizing the data according to your needs and by analysing and visualizing the data to better process it and present it to other stakeholders.
PractiTest has an advanced reporting mechanism that lets you visualize any aspect of your data in multiple ways.
What are the most important things to look for in an ALM suite?
- A tool that covers the majority of the application lifecycle, either internally or with robust integrations
- Traceability between all artifacts - using an ALM, you will need to track and provide evidence in different stages of the product lifecycle. Being able to trace each artifact to its source and related items is important for a smooth workflow.
- Robust data visualization - having all the data is not enough, you need to make sense out of it, and so do your colleagues. Choose a tool like Practitest that had a dynamic representation of information, multiple graphs and dashboards and an advanced reporting mechanism for further data analysis.
Why use an ALM suite?
When developing a program, all entities must be inter-connected and there should be end-to-end management of the process. With the right ALM, you can visualize and control your entire process thus spotting and fixing problematic areas, improving your team communication and releasing better software to the end-users.
In which industry is using an ALM tool most common?
ALM solutions are used in any market vertical that involves software development. Starting in the Telecom and IT industry, through healthcare, banking & insurance, energy and more. No matter the industry, if you have a software development operation, you should use an application lifecycle management tool.
What are the advantages of using an ALM tool?
By using an Application Lifecycle Management tool, you improve the quality of your product, your team’s work, your client’s satisfaction and your business ROI.
- Make faster and wiser decisions - With the right ALM, you gain full visibility into your product’s status. When you have an overall picture in place, you can plan ahead more wisely.
- Align the development goals with the business goals - In PractiTest you can have your requirement linked to the tests that cover them and to the issues that are related to them. You can create dashboard charts and export reports to visualize this traceability which gives you the ability to coordinate the development - testing - business work and objectives better than ever.
- Improve your teamwork and communication - The fact that all information is in one system, improves the communication between the teams and inside each team. This doesn’t only improve the process but also affects the team work; when you have visibility to what each team member is doing, you can better manage their work and each member can make sure he does what is expected of him.
- Improve the quality of the product - In PractiTest, you can notice problematic areas in real-time and understand the possible risk they might raise. Based on this knowledge you can make concrete decisions on how to fix it and whether it should delay a release or not.