Did you forget your: Username / Password ?

Sponsors

TechWell

Home

Articles

Five Imperatives for Application Lifecycle Management

Written by Carolyn Pampino

Many organizations are faced with hastened delivery schedules due to competitive pressures and the need to innovate. Yet software development is difficult, and the software systems that are maintained and delivered by the world’s IT and device development organizations are astoundingly complex. Teams challenged by reduced time to delivery must do so without increasing their budgets or sacrificing quality. Their strategy, instead, must be to improve software development efficiency. A solution to this dilemma is to improve Lifecycle Collaboration with Application Lifecycle Management.

Designed for the execution of a software delivery project, Application Lifecycle Management solutions coordinate people, processes, and tools in an iterative cycle of integrated software development activities, including planning and change management, requirements definition and management, architecture management, software configuration management, build and deployment automation, application security, and quality management. In addition to the capabilities, the fundamental features of an ALM solution include traceability across lifecycle artifacts, process definition and enactment, and reporting.

The most important benefit of an ALM solution is coordinating the people, processes, information, and tools involved in a project to deliver innovation to your stakeholders. Because there is no one-size fits all solution, we advise our clients to focus on the following imperatives as they implement an ALM approach best suited to their environment and culture:

Integrated planning
Traceability of related artifacts
Development intelligence
Automation and Collaboration
Continuous process improvement

Integrated Planning
We plan because we want to know when we are done. The only way to know when the work is complete is to ensure the plans are fully integrated with project execution and always up to date. The following table provides several typical dos and don’ts related to planning.

Don’t	Do
Have plans that live outside of ALM environment.	Use plans that are fully integrated with execution, manage tasks for the entire team, not just the tasks of developers. Provide Plan transparency, where plans are visible and accessible to everyone on the team. Use plans that make it easy to understand the load, easy to see what your team is currently working on in taskboards.
Rely on manual, error-prone updates.	Use plans with information at your fingertips, and a user interface that makes it trivial to update plan information in the context of the work. Use a plan that provides multiple views on the same data such as Ranked Lists, Planned Time, Taskboard, Work breakdown, by Iteration, or Roadmap (traditional) view. Practice continuous planning using lifecycle queries and project dashboards to respond to changing events on the team.
Create an environment where requirements, development and test Plans are disconnected and managed separately, or not at all.	Plan across the entire team, not silos, by linking and populating development and test plans from requirements. Ensure individual requirements, development work items and test cases are all linked.
Separate from team activities and assignments.	Updating time spent directly from the work item makes easy to keep accurate plans. Instantly see the impact of changes to delivery dates. Use Planned time to balance the load across team members.
Rely on disconnected from metrics on past team experiences.	Easily instantiate project plans into individual and team activities

The following image illustrates how updating time spent directly from the work item in a matter of seconds makes easy to keep accurate plans.

0. Updating the time spent on a work item keeps plans accurate

The following three images show the same Sprint plan using different views. Using different views helps the team balance the work, plan effectively and respond to changes more quickly.

1. A Planned Time view illustrates when team members have more work than the others.

2. An electronic taskboard view can be used across geographic locations by agile teams.

3. A roadmap illustrates tasks over days and weeks in a more traditional view.

The IBM Rational Collaborative Lifecycle Management Solution offers fully integrated real time planning. The image below shows a Release Plan in Rational Team Concert containing links to a related Product Backlog, a collection of requirements in Rational Requirements Composer, and a test plan in Rational Quality Manager.

4. Planning includes taking the requirements and test plans into account

Traceability
Traceability isn’t simply one of those “nice to have” capabilities in the software development lifecycle. Traceability helps you understand what everyone else on the team is doing. For example, while the requirements analyst knows very well what requirements she has written, she still needs to know whether a given requirement will be addressed during a specific development iteration and, if so, which one. Or she wants to know if the implementation of that requirement has been tested and with what result.

An ALM solution that allows for lifecycle artifact traceability helps teams to answer the hard questions about requirements and risk management. By linking related artifacts, teams are better equipped to answer questions such as “which requirements are affected by defects?” and “which work items are ready for test?”

5. Important questions answered by an ALM solution

Traceability helps the requirements analyst understand what the rest of the team is doing and how it impacts the overall workload. If you are working in a regulatory compliance environment, traceability helps you answer auditor’s questions such as “What changes went into this build, tests where run and with what result?” Here are typical dos and don’ts associated with traceability:

Don’t	Do
Work in disconnected project repositories, or cobble together a disparate set of tools.	Seek products built with open interfaces. Seek vendors who understand and support the ALM integration challenges. Invest in tools with a longer-term integration roadmap in mind.
Enter links manually after the fact, it’s easy to forget, hard to enforce.	Integrated tools make it easy to establish as the project executes. See image of linked Defect 76 below.
Build your own integration based on proprietary API’s.	Choose a solution with open services (OSLC) for linking data across the lifecycle.
Choose a one-size-fits-no-one solution.	Invest in a loosely coupled, integrated ALM solution that is built to scale and support open and flexible integrations. A single ALM repository will not scale to fit your needs over time. Times change, new products emerge; your ALM solution needs to be flexible enough to move with the times. Do you really want to face that data migration challenge?
Do traceability for traceability sake.	Identify a few meaningful questions or set one goal and institute a “just enough” approach for linking related artifacts. For example, link requirements and test cases, link test cases and development work items. Try one and get good at it before doing more.
Rely on reports that go stale after you’ve created them.	Leverage a system that shows the traceability links directly on the plan, or that uses queries that identify gaps, such as “Plan items without requirements” and “Plan items without test cases”, and “Defects blocking test.”
Ignore, hide from or hope to pass regulatory audits	Invest in an ALM solution that makes traceability easy to do, maintain and report against.

The image below shows a traceability view in Release Plan containing links to requirements and test cases. It also has a column to identify defects affecting the plan items. This demonstrates an integrated plan with traceability reporting. Rather than relying on stale and occasionally run traceability reports, using an integrated plan with a built-in traceability view makes the gaps are obvious and easy to address through out the project.

6. A release plan with coverage across the development, requirements and test teams

When traceability links are established, the IBM Rational Collaborative Lifecycle Management solution leverages these links to automatically create traceability links on defects. The image below shows a defect with traceability links. The traceability links to the test result, test case, test plan, plan-item and requirement, are automatically generated when a defect is submitted by a tester.

7. Lifecycle links on a defect illustrate the impacted test cases, plan items and requirements

Development Intelligence
According to Capers Jones,[1] projects with strong measurement practices have much better success rates than those that do not.

8. Projects with measurement practices have a better chance of succeeding

For example, the three measurements listed below are practiced by less than a 50% of all organizations in the Capers Jones study:

Quality measures: 45%
Productivity measures: 30%
Complete measures: 15%

Here are our suggested dos and don’ts regarding measurement practice:

Don’t	Do
Ignore performance measures.	Define performance metrics that are appropriate for your organization. Simple metrics such as Build Duration, Build Pass/Fail rate are simple place to start if you haven’t already.
Take a ‘big bang’ approach to instituting measures and metrics.	Identify a weak spot. Choose a practice to implement improvement. Determine how you will measure the improvement. Choose a tool that collects and reports on the team’s activity using the data from integrated planning (Imperative 1 above)

Expect to get it right the first time.	Conduct retrospectives and identify the next set of improvements.
Try to manually collect data by hounding the team for status reports.	Use live dashboards that provide transparency of information and dashboard reports based on data coming from the team’s activity.

The image below shows reports on the development team within a project dashboard. As work items are updated, the reports reflect the activity and trends of the team.

9. A dashboard with reports and metrics to measure improvement

Dashboards and reports are key part of an ALM solution for measuring and responding to a team’s progress.

Collaborate and Automate
Collaboration isn’t just about being friendly and collegial with each other. Collaboration contributes to higher quality and improved value to the stakeholders, which means that team collaboration is a key to innovation. Collaboration tools within an ALM solution can improve a team’s ability to connect with each other, to respond to changing events, and to improve project predictability.

Collaboration tools can also help teams focus on what matters. Teams should seek every opportunity to automate manual, non-creative tasks. A good ALM solution enables build and test automation, but automation can also apply to status reporting and information access. Project and personal dashboards play an important role in bringing automated information to the team by providing transparency into their work and access to real-time data with team reports and queries. A well-designed user interface automates access to information, by bringing information to the user instead of forcing a manual ‘context switch’ to access another application. This form of automation naturally leads to better collaboration.

Don’t	Do
Create an environment of silo’d teams and disconnected data that is hard to access by other members of the team.	Track all tasks across the disciplines across the life cycle. Unified team shares linked data. Use lifecycle queries to answer more meaningful questions such as “Which requirements are affected by defects?” Hovering a mouse over link provides information about the artifact at the other end of the link.
Manually collect status reports	Collaboration is also about knowing what is going on without having to ask, team activites/events and changes are easily accessible and visible to every one Dashboards and lifecycle queries provide real-time status of the team’s progress. Mini, personal dashboards are always accessible through out the user interface.
Rely on email discussions. Important discussions are lost to email and chat archives--project records are missing the “real reason” for decisions	All discussions in work items integrated on the plan. ALM environment becomes an essential “archeological tool” for understanding the past, speeding later enhancements
Lengthy “on-ramp” for new team members	New team members can easily understand the context of activities

The image below shows a dashboard mashup with widgets containing information from Rational Team Concert, Requirements Composer, and Quality Manager. The information in the dashboard provides up to date status about the project.

10. Mashup dashboards provide transparency across the team

The image below shows a “mini dashboard” that is always accessible from the side of the UI and is dockable on left or right. It serves as a portable mini personal dashboard that goes with a user wherever they go within the ALM solution, and can be shown or hidden at any time.

11. A mini dashboard is accessible through out the user interface

The image below shows a mini dashboard for a user in Rational Team Concert. On this mini dashboard is a widget displaying changes to requirements in Requirements Composer. This is a mini dashboard mash up. Hovering the mouse over the link to the requirement causes a rich hover to appear with information about the status of a requirement in Requirements Composer. Users in need of instant information gratification will quickly become addicted to using mini dashboards!

A rich hover on link from the Mini Dashboard

Continuous Process Improvement
Process is more than a documented set of procedures. We design processes based on best practices gleaned from industry experience as a means to improving a team’s behavior and to help them succeed. Most behavior is habitual. When you define or change a process, you are asking an entire team of people to change their habits and adopt behaviors that at first may be difficult to understand. It can be quite hard to change one habit in one person. Yet, process changes frequently require new ways of thinking and new modes of behavior for a multitude of people. A well-designed ALM solution allows you to change that process as you learn and improve the team dynamic.

Don’t	Do
Ignore process altogether or treat it like an unnecessary burden.	Realize that a well-defined process can help your team establish a rhythm and reduce unexpected problems from rogue behavior.
Define process improvements goals without making results of process improvement visible	Use dashboards to make area of improvements visible across the teams. For example, if you are struggling to burn down across an iteration, make the iteration burndown across the teams visible an dashboard, and watch the team start to burndown
Go overboard with “high ceremony” unless absolutely needed for your environment	Define a ‘just enough’ approach to improve upon where you are now.
Define a process and place it on a shelf or a hard drive for no one to ever see again	Use a tool that can ‘enact’ your process definition thus guiding the team toward the desired result at the exact time its needed.
Define process up front, don't change during the execution	Use tools that make it easy to tweak and adapt the process as the project executes and as the team learns and wants to improve
Institute process police	Let the tool govern behavior and refine it over time. Review the effectiveness of the process specification to ensure adequate results as part of your team retrospectives.

Rational Team Concert provides process specifications that you can use to get your teams up and running. These process specifications provide work item types, state transitions, and rules that govern how to use them. In addition, teams can modify the process to suit their needs. A process can be deployed to an entire project, or modified for a team within a project. Processes can even be modified ‘in flight’ to adapt to the changing conditions on the project. The image below shows the default set of work-item types that are defined by Team Concert’s out-of-the-box Scrum process template.

12. Work-item types that support Scrum, come out of the box in Rational Team Concert

Tools that support the process and guide team members toward the expected behavior are important elements in an ALM solution.

Choosing ALM solution for your team
Choose an ALM solution that supports and encourages collaboration regardless of role, organization, or geographic location. The IBM Rational Collaborative Lifecycle Management Solution meets the five imperatives described above. The solution consists of IBM Rational Team Concert, IBM Rational Quality Manager, and IBM Rational Requirements Composer.

Rational Team Concert integrates work item tracking, source control management, continuous builds, iteration planning, and highly configurable process support to adapt to the way you want to work, enabling developers, architects, project managers, and project owners to work together effectively. Rational Team Concert supports multi-platform development such as Java, .NET, and mainframe environments. Rational Team Concert has built-in integrations with Requirements Composer and Quality Manager, along with many other popular development tools. Learn more on the project Integrations page on Jazz.net.

Teams seeking to add rich requirements definition and management use Rational Requirements Composer. Requirements Composer is being extended to provide both requirements definition and management capabilities for fast-paced, market-driven project teams. Requirements Composer has built-in integrations with Team Concert and Quality Manager, along with many other popular tools. Learn more about Requirements Composer Integrations on Jazz.net.

Teams seeking to improve their ability to meet quality goals use Rational Quality Manager, which has built-in integrations to Rational Team Concert and Rational Requirements Composer. IBM Rational Quality Manager helps organizations optimize project quality with a single, shared test management hub that provides integrated lifecycle support across virtually any platform and type of testing. It provides a customizable, role-driven solution for test planning, creation, and execution as well as workflow control, tracking, and end-to-end traceability.

By using these products together teams can live up to the five ALM Imperatives described in this article. The imperatives are built in, and ready to help you improve your ability to deliver high quality software innovation. What’s great is that you don’t have to use all three to reap the reward. The products can be used in any pair, or all together.

We welcome you to visit Jazz.net to learn more about Rational Collaborative Lifecycle Management, powered by Jazz.

[1] Capers Jones, “Measurement, Metrics and Industry Leadership,” 2009, and Software Engineering Best Practices, McGraw Hill, 2010.

About the Author Carolyn Pampino is the Program Director for Strategic Offerings focused on IT Software Delivery. She is a member of the ALM leadership team at IBM Rational, working closely with the Jazz team leads to define the Collaborative Lifecycle Management road map and strategy. She contributes blog entries and recorded demonstrations to Jazz.net. Carolyn is a co-author of an eBook, titled "Scaling Agile with Collaborative ALM." She is also co-author of an IBM Redbook titled “Collaborative Application Lifecycle Management with Rational products”. She was a founding member of the team defining strategies for Rational and Tivoli product integrations, and contributed to Rational's acquisition of Build Forge. Prior to IBM, Carolyn was the Director of Product Management, Development, and Competitive Intelligence at BroadVision, Inc.

Carolyn thanks Erich Gamma, Kim Peter, Mike Perrow, Robyn Gold, and Fariz Saracevic for their contributions to this article, and the entire Jazz Foundation and Collaborative Lifecycle Management teams for creating an incredible solution!

Set as favorite

Bookmark

Email this