Five Principles for Application Life Cycle Management

Editor's Notes

• #7: Often, when people hear about application lifecycle management, they interpret the terminology with things they know. Project Managers or Scrum Masters will think of the current scope of the project or the specific iteration/release that has a known scope and relatively short duration. Business Analysts, Product Managers, and Product Owners think of the product lifecycle management that has an uncertain scope and unclearly long duration. Architects, Designers, Developers, and Testers focus on software development lifecycle. Operations, Service Delivery, Program Managers and Portfolio Managers think of the deployment considerations, release documentation, and benefits realization.
• #8: Add each group’s specific preference to one tool to this confusion Requirements are in different places, tasks are in one place, test cases are incomplete, and the list goes on The single and central source of truth to what customer wanted and what we delivered is open for interpretation! The concept of application lifecycle management becomes murkier because all problems are treated like the same nail and the same hammer is used to solve everything. Total Cost of Ownership for the organization becomes high!
• #9: Often, people jump on to the Agile bandwagon and think “all their cure” has arrived! In fact, whether people do plan-driven project management or agile approaches to managing projects or a combination of hybrid approaches, the problems continue to remain if we don’t understand five principles that need to be in place for any tool of choice to manage the application lifecycle. Let us take a look at the latest state of agile survey published by Version One. This is an industry agnostic global survey where several hundreds of members share their input on the reasons for going agile. Perhaps because of the short time-focus on iterative and incremental delivery, 75% of the industry says accelerating software delivery is the reason for going agile? But, if time is fixed and scope is variable, only 46% people claim increased software quality? What good is a software without adequate quality? Agile’s claim to success was also that it allows change compared to plan driven approaches. Only when stakeholders are properly managed to control change, this claim can be true! That management of stakeholders is not associated only with agile! Don’t you think so? In fact, despite 64% of the industry’s claim to using agile as a framework to manage changing priorities, only 55% claim productivity increases and 49% see agile as a means to align business and IT. So, just going to agile is not going to be solution. People, process, and technology has to be integrated around the value proposition. The tool of choice across this people and process should enable this change!
• #10: Often, many confuse the application lifecycle management.
• #12: Strategic Benefits What does the customer want? Coordinated Planning How do we prioritize and deliver value? Complex Interdependencies Managing dependencies and risks to delivery Deliverable Integration Continuously build, adjust, and deliver Optimized Pace Sustain Operations along with delivery of new functionality
• #13: Refers to the degree of relationship between two or more components of the software developed. Common Myth is that Traceability is a one-way flow between requirements to traceability. It is not and any tool should support this bidirectional flow. Traceability is not just between requirements and test cases but should provide and report a seamless interdependency across all the artifacts. Traceability is also is related to the binary deployed to the test and production environments. Traceability promotes transition planning, succession planning, change impact analysis, test optimization, product component reuse.
• #15: People mix product development framework (agile), plan driven approach to project management (PMBOK, Prince2) with software development framework (SDLC often known as waterfall). The dependency is intricate. Common Myths involve the following practices leading to the use or non-use of a tool SDLC involves linear approach to software development Big Upfront Requirements gathering Gathering requirements upfront saves cost Project Management is not part of software development High degree of Software Development needed before initiating any work Customers sees work after ALL work is developed and tested Testers need not be involved early in requirements stage
• #17: Any tool that supports application lifecycle should integrate management and technical processes in to the development process. Decision making from governance therefore should be integrated with traceability across the development lifecycle. Source Code: The tool of choice should support managing the source code as part of software build process. Version Control: While source code managing supports at the coding level, version control aspect of the ALM tool should facilitate creating software build versions based on the actual files brought to build the resulting software. Quality Management: The reactive and product based focus of quality is the quality control. The ALM should enable what defects are coming from the existing build and resolved in subsequent builds. What potential test cases are also flagged for update based on changes in the requirements in a good ALM tool. But, it should also remove subjectivity in quality control by incorporating proactive and process based focus on quality. The ALM tool should provide this governance using workflow. Testing: The nature of business is that there will always be certain aspects of the business requirements that need manual testing. Yet, productivity gains result from continuously automating testing. A good ALM tool should provide interfaces to both these approaches. Deployment: A good deployment is also not only giving the training and documentation necessary but also facilitate them to provide interface to requirements. Some of these may be the non-functional requirements that provide better quality of care in the production environment.
• #18: Compliance to procedures and process is exponentially increasing with several regulations binding application development throughout its lifecycle. Understanding the types of information auditors look for as evidences of what happened carries a long way in how decisions made, who made, when they were made, etc. Sometimes, these things auditability should be at a level for even rolling out deployed changes impacting the cost of quality. Auditability should augment the version control and source code control within artifacts.
• #20: When delivering software, think of the following: Can customer service field the request from the customers and end-users? Can Service Operations sustain the application in the production environment? Often, requirements from these members are inadequately factored making it difficult to adhere to scale and sustain. Some of these operations work involve Event Management Incident Management Application Management Access Management A good application development lifecycle tool should allow operations provide input and allow integration of tools