Application Lifecycle Management Part 2 of 5
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.
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.
Interdisciplinary roles
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 be
kept 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.
Why |
Developer |
Production |
Management |
Customer |
Versioning |
Keeps track of the changes |
Easily revert to a prior version |
No loss of data |
Reliability |
Continuous integration process |
Concentrate of developing software Early feedback Integrate with code from others |
Get high quality production code
|
Fewer errors Repeatable process Faster and shorter release cycle |
Early feedback Working software
|
Automated build |
No loss of valuable time |
Everything is coordinated by script |
Prevents mistakes |
Fast feedback cycles
|
Automated deployment |
Guarantee that production will receive the quality code Consistent and reliable process for deployment |
No manual intervention Reduces risk |
Increases the possible release cycle frequency and productivity |
High quality |
Task-based Development
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:
- Understanding your stakeholders and business context
- Mapping project expectations to outcomes more effectively
- Building more consumable software, making systems easier to deploy and use
- Enhancing alignment with stakeholder goals continuously
Business Context
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.
Requirements Gathering
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.
Fire up Visual Studio
From the File Menu, choose New Project
Navigate to other Project Types and Choose Visual Studio Solutions. Provide a name and location for your solution and click OK.
We shall now add a Modeling Project to the solution. Right click on the solution and choose Add > New Project from the resulting menu.
Choose a name and location for your Project and click OK.
We shall add the result of our brain storming meeting with the client to the Project. Right click on the Project and Add > New Item.
From the dialog window, choose UML Use Case Diagram and click Add.
There shall be a blank diagram surface that will be populated by dragging items from the toolbox and dropping them on the diagram surface.
We shall then populate the Use Case Diagram and end up with figure shown below.
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
References: