Systems Lifecycle Management and Systems Delivery with CLM
Systems Lifecycle Management and Systems Delivery with CLM
In 2010 I led to the design of Systems Lifecycle Management and System Delivery scenario with Collaborative Lifecycle Management (CLM).
What is Systems Lifecycle Management and Systems Delivery with CLM
This is one of the scenarios in a family of CLM scenarios exploring the Lifecycle Management practices and how these practices are supported by the Rational tools built on Jazz, or integrated with Jazz.
As the foundational capabilities of Lifecycle Management (process integration between disciplines, traceability of artifact relationships, and project transparency and reporting) are common needs by any delivery project we use a shared approach to the CLM@scale scenario. The CLM@scale scenario outlines the project lifecycle, the roles in the project, and the common practices of a project. For the System Delivery scenario, we configure the System Engineering practices and System Delivery platform by extending the shared CLM@scale scenario. We explore the team workflows of a multi-disciplined project to deepen our understanding of how our systems customers can succeed with System Engineering practices using our Jazz products. We work from the ‘outside-in’ and ground the scenario in the challenges our customers face in delivering systems, or systems of systems, that integrate software, hardware, and electronics.
Design Objectives
The objectives of the System Delivery scenario are to Capture System Lifecycle Management and System Engineering workflows across a set of core products.
The shared objectives of the CLM@scale scenarios are focusing on
- Getting started. The consumability and administration of our integrated Jazz solution.
- Adopting practices. Adding agile delivery practices to team process
- Task management. Everyone on the team gets assigned tasks
- Planning and transparency. How status rolls up across projects
- Automation. Explore how events can be used to create interesting life cycle automation
- Measures. What reports and metrics are needed by the team to manage their project.
The System Delivery scenario extends the objectives by focusing on
- System Lifecycle Management. Solution completeness for a project of multi-disciplined teams
- System Engineering. How the team is performing system requirement engineering and architectural management with Jazz integrated tools.
- OSLC adoption. Linking of OSLC resources across a System Lifecycle Management Solution using OSLC.
- Traditional planning. How a traditional system delivery project is managed and integrated with an agile software team.
- Product planning and delivery. How teams defined and deliver product part structures and variants.
- System Delivery Measures. What measures are needed and how these are delivered to the teams through reports and dashboards
The Lifecycle
There are many representations of a project lifecycle. For example, a traditional sequential lifecycle, or an iterative lifecycle flow of incremental phases. System delivery teams tend to use the well-established ‘V-Model’ lifecycle models. Other system delivery teams adopt a spiral flow of incremental refinement. For this System Delivery scenario, we have taken a somewhat generalized approach to a project lifecycle by Flattening the V. This enables us to share a common scenario lifecycle flow across the CLM@scale and System Delivery scenarios. This generalized approach can support key lifecycle management aspects of both the commonly used V-model, and well as the iterative spiral model.
Looking at the V-Model we identify a set of key lifecycle phases; the system engineering phase that establishes the system requirements and architecture, the multi-disciplined engineering and validation teams that deliver the system through a sequence of milestones, the validation, acceptance, and release of the system delivery, and a continuous project management activity that leads the project to completion.
The lifecycle figure is using colors to identify the main focus and ownership of the lifecycle activities.
- Gray is used to indicating deployment and configuration activities performed by project administrators and leads, for example, the Inspect and Adapt phase.
- Blue is used to indicate activities performed by a cross-project team, for example, requirements analysis performed by the System Engineering team, or the project leadership team planning the project.
- Green is used to indicate activities performed by a development team. Such activities may be from multiple disciplines, like iteration planning, development, and component testing.
- Orange is used to indicate independent system tests and validation. Such activities are continuous through the lifecycle.
- Purple is used to indicate asset management activities. This lifecycle mainly focused on the system hand-off phase.
The generalized lifecycle, shared by the CALM scenarios, recognizes these phases and lay’s them down along a sequential time axis as individual iterations. Taking this approach we can see commonalities in lifecycle management capabilities and needs between applications development and system delivery. We can also explore common workflows that apply to any lifecycle approach. Where exceptions are found we explore them as extensions to the CLM@scale scenario.
The lifecycle, captured in the figure below, generalizes on the lifecycle phases of an end-to-end system release. The phases focus on the system engineering, planning, development, and delivery phases.
- The lifecycle starts with the project team preparing for the project (c.f. Inspect and Adapt in the figure). In this part, the project leads and administrators are preparing the system delivery platform, configuring the team practices and processes, and creating the required project areas across the System Delivery platform repositories.
- Once launched, the project moves into a System Engineering phase (c.f. Iteration 0 in the figure). The concept defining the release objectives is approved and the system engineering team is analyzing stakeholder requirements, and defining the system requirements, system use-cases, and system architecture. During this phase, the project plans and dependencies between sub-systems and teams are established and approved. For projects delivering systems of systems, it’s vital to establish and track such dependencies as the system delivery may cover multiple disciplines like software, hardware, and electronics. Parts may also be delivered by 3rd parties or sub-contractors. In this scenario, we are focusing the story on the interactions between the project plan and the dependencies to a software subsystem.
- The lifecycle proceeds with a sequence of iterations, or spirals, where the development teams are planning, developing, and integrating subsequent milestone releases of the system (c.f. Iteration 1 and 2 in the figure). The milestone releases are integrated and validated by an independent system verification team. As the project is prepared for its final release milestone the teams focus on release stabilization and system test (c.f. final Iteration in the figure below).
- At the end of the lifecycle, the system is transitioned to production or deployment. The team finalizes the release by acceptance testing and signing off on the release quality.
- As indicated in the figure below, aspects of teem steering are covered in each iteration. There is also project-level steering that measures and monitors the health of the project and the adoption rate of new development practices.
The System Delivery Organization
The system delivery scenario is using a common project organization and common project roles/persona from the CLM@scale scenario. The project is organized in teams of teams.
The system scenario extends the CLM scenario with a set of general teams and roles important to system delivery teams
- System Engineering team(s) that is responsible for capturing, analyzing, and prioritizing the system requirements.
- System Validation team(s) that is responsible for validating the integrated system against system requirements.
- System disciplines, like software/mechanics/electronics, that is responsible for developing and delivering their sub-systems for system integration of the product.
- The teams work from a common set of stakeholder requirements, system requirements, and an aligned project plan. The project will plan and track the schedule and resources for system integration and independent system test.
The System Delivery Platform Configuration
The scenario is using a core set of tools from the System Delivery platform that is built on Jazz or integrated with Jazz. These tools are
- Rational DOORS Next Generation
- Rational Rhapsody
- Rational Team Concert
- Rational Quality Manager
The System Delivery scenario is building out a richer end-to-end story from a core set of Open Services for Lifecycle Collaboration (OSLC) scenarios. These core scenarios capture the essence of the resources, steps, and CLM links.
The Practices for System Delivery
The System Delivery with CALM scenario is based on the practices and tool guidance provided with MCIF. These practices apply specifically to System Engineering phases and to agility@scale practices. The practices apply to specific lifecycle phases as indicated below.
Some of the practices and workflows are common across the CLM@scale scenarios, others (indicated with bold text below) are specific for the System Delivery with CLM scenario.
Jazz.netRead more about the IBM Engineering Lifecycle Management solutions on Jazz.net.
