Building blocks of ALM
This is the second blog on ALM, in my previous blog we introduced ALM. In this section, we shall look at what value does ALM add to your development process. We’ll also discuss how important it is to be focused on the stakeholders’ needs and use a task based approach. Then we shall introduce the tools that will enable you to implement and support these building blocks. Tools are important, but it’s also important to start with a stakeholder focus.
Developing a software application isn’t just about writing code. Once developed, code must be tested, approved, and deployed to the live environment where it must be maintained. Many programmers will expect their code to migrate to the live environment as soon as it is completed to see that their deliverables are used, whereas others understand that the release will be promoted when it’s tested and approved.
In this series, the developer is a person who not only develops or programs code but also has interdisciplinary skill set. Developers are skilled in coding, but they should know how to test, configure and ship features. As a consequence, some people don’t like to see the word developer used for programmer. They argue that everyone involved in delivering software is a developer, including the testers. All developers-programmers, testers, database administrators (DBAs), and other people on the team-need to take responsibility for quality and for ensuring that all testing, configuration and deployment activities are completed at the same time as the coding takes place.
Depending on their role within the organization, each person may have different focus. For instance, a developer should usually work in an isolated environment (with an IDE - Visual Studio) and then commit code only if it won’t break the build for the rest of the team. Continuous integration (CI) provides immediate feedback to developers if code committed to the trunk can’t successfully build. The Release Manager needs to have a clear overview of the status and must know whether the latest code (on the trunk) will build successfully and pass all the relevant unit and automated tests. The release manager should also bekept advised on the state of QA testing and should know the current version in production. Finally, the CIO and the CEO of a corporation (among other senior managers) want to see an automated and repeatable process with an audit trail.
ALM consists of several steps, including traditional versioning, and ends with deployment, always weighing the importance of the underlying business. All these aspects are important for individual stakeholders, as outlined in table 1 below.
Keeps track of the changes
Easily revert to a prior version
No loss of data
Continuous integration process
Concentrate of developing software
Integrate with code from others
Get high quality production code
Faster and shorter release cycle
No loss of valuable time
Everything is coordinated by script
Fast feedback cycles
Guarantee that production will receive the quality code
Consistent and reliable process for deployment
No manual intervention
Increases the possible release cycle frequency and productivity
Working in task-based way means that, first, all activities are based on specific requirements or tasks, often called work items. Task-based also means tracing each task and the changes it creates, and this becomes even more appealing if you span the tracing over all roles, phases and organization units, including production. When are you close to the maximum or improving your process? When the production crew (and any other stakeholders) not only host the final deployment units, but also know exactly which units are based on which sources. Additionally, you will know which sources were touched because of which changes were requested.
You can link requirements and defects to coding items, and vice versa. This referencing makes it much easier to validate that the work is done to plan and that the plan is getting done. This end-to-end referencing provides much scale than using the plain story cards that are used by some agile approaches. A basic premise of Agile ALM is that work should be aligned to the customer’s requirements. This approach requires:
So how do we put all these in context? We shall build a Web Application for a small brick & motor hobby shop that sells model airplanes. Our client would like to have an online store front to supplement in-store sales.
We shall meet with the client and have a brain storming session, based upon which we shall need to model these requirements and be able to track the same and come up with tasks that shall then be assigned to the members of the development team.
Other Links for Application Lifecycle Management
Application Lifecycle Management Part 1 of 5
Application Lifecycle Management Part 3 of 5
Application Lifecycle Management - Part 4 of 5
Application Lifecycle Management Part 5 of 5
Agile ALM: Lightweight tools and Agile strategies