This session starts by listing the roles presumed involved in the SSE solution. Key scenarios for practitioner productivity are discussed. Design improvements are presented and reviewed with the attendees. Areas of additional practitioner productivity discussed.
In this IBM® Redbooks® publication, we provide a blueprint for Collaborative Application Lifecycle Management (CALM) and show how the new IBM Rational® products support this evolving market. Driven by the business demands of global software delivery, many large organizations are seeking guidance in how to incorporate agile methods.
In this book, we provide a reference scenario and tool architectures for deploying the new IBM Rational products into an existing enterprise environment. We also provide a set of blueprints that define each of the key disciplines in the development life cycle to help you understand the domain and how the Rational products support the need of that discipline. Our primary focus is to highlight the value of CALM by providing a user view of the solution that is used to support a distributed enterprise development team that incorporates aspects of the “Agility-at-Scale” approach.
While most Redbooks publications provide details about a single product, this book provides a “green-thread” reference scenario that details one end-to-end path through an iteration of a software development project. The scenario demonstrates a reference architecture for an enterprise that uses the new Rational Jazz technology-based products along with the existing Rational team products. The scenario includes Rational Build Forge® Enterprise Edition, Rational ClearCase®, Rational ClearQuest®, and Rational RequisitePro®, and introduces Rational Quality Manager, Rational Requirements Composer, Rational Software Analyzer, and Rational Team Concert.
The leading ALM solution from IBM is the Collaborative Lifecycle Management (CLM), which consists of Rational Requirements Composer (aka Rational DOORS NG), Rational Team Concert, Rational Quality Manager, and Rational Design Manager. The Jazz platform is strategic for implementing the Rational solution for CLM. The Jazz platform is all about collaboration; it allows individual products to integrate better and more easily, and allows the users of those products who take on distinct roles to work more effectively together than has historically been possible. The Jazz platform supports a more collaborative approach to ALM tools and their users. The approach is open. It leverages the standards used by the Internet. Just as the internet works with data spread around the world, the approach is to allow development team data to be spread around an organization, and yet to have development artifacts as easily accessible as surfing the world-wide-web. Through the support for OSLC, integrations can be provided for Jazz-based products. Additionally, third-party vendors and customers can consume or provide their own OSLC interfaces to support heterogeneous environments made up of Rational, third party, and/or customer solutions. The combination of Jazz and OSLC provides the ability to have unprecedented collaboration, transparency, automation, and traceability.
The artifact information model used by the Collaborative Lifecycle Management solution, adopted and extended in the IoT Collaborative Engineering solution, is radically different compared to classic change management and lifecycle tools like Rational Clear Quest. In CQ the complete lifecycle was managed in the complex schema. In CALM the state is distributed over a network of linked and related artifacts. User research on the use of schema-based change management systems identified user pain points
Research at our enterprise clients reports on similar pain points in establishing a state schema, resulting in years in negotiating a corporate-wide schema in ClearQuest that managed the lifecycle of Change Requests as a single state model.
The artifact information model used by the Collaborative Lifecycle Management solution, adopted and extended in the IoT Collaborative Engineering solution, is radically different compared to classic change management and lifecycle tools like Rational Clear Quest. In CLM the state is distributed over a network of linked and related artifacts.
Let’s consider an example by walking the structure in the diagram
Based on our research we formulated the ‘ALM Principles’ that was validated by our sponsors
In 2009 I co-led the publishing of the CALM Redbook together with Carolyn Pampino and a group of Rational SMEs. The Redbook provides a blueprint for Collaborative Application Lifecycle Management by using an end-to-end reference scenario for deploying the new Rational products and ‘Agility at Scale’ into an existing enterprise environment. The scenarios produced for the Redbook cover Change Management, Requirements Management, Enterprise Integration Builds, and Test Management. It also discusses metrics for team success in Application Lifecycle Management.
“ALM is the thread that ties the development lifecycle together” – Forrester analyst Carey Schwaber”From this generalized CLM@scale lifecycle we focus the System Delivery scenario on a story in six acts. These acts focus the scenario on exploring key workflows and lifecycle capability requirements of a System Lifecycle Management solution and are designed to answer a primary lifecycle question that is critical to the success of the project. The six acts cover aspects of configuring the project, planning the project, delivering a part of the system, managing changing requirements, stabilizing the system release, and hand-off of the release.
Act 1 – Inspect and Adapt
The project admin(s) and the project lead(s) are set up and configuring lifecycle management for the project. This act covers upgrading the system delivery platform to the latest release of the products. It also covers the deployment of new tools and capabilities in the system delivery platform. The act also includes how the project environment is configured and related CLM repositories are linked. Finally, it explores how the team selects an improvement strategy and how the practices and process automation used by the project is configured and deployed to the system delivery platform.
Act 2 – System Engineering / Plan Release. This act explores System engineering, Project release planning, and how these two practices interact in a System Delivery project. The act explores how system requirements engineering is supported by the tools on the System Delivery platform, and how Stakeholder Requirements, System Requirements, System Use-Cases, System Architecture relate to the project Iteration plans and Test Plans.
Act 3 – Complete a System Requirement. In this act one of the software delivery teams are planning, modeling, delivering, and integrating a sub-system use-case. This explores the use of model-driven development using the System Delivery platform. It also explores new development collaboration workflows using Modeling and CLM scenarios. The CLM@scale scenario reference this act as Complete a Story.
Act 4- Respond to Change. Requirements Change Management is a key capability for System Delivery teams. This act explores how new formal change requests are submitted, triaged, how the impact from change is analyzed, and how requirements are updated, reviewed, approved, and baselined.
Act 5 – Stabilize. Lifecycle Management with Jazz enables rich capabilities for monitoring project health through CLM queries. This act explores how reporting and Jazz Dashboards help the team ensure quality and prepare for the release.
Act 6 – Deliver. The team is handing off the system release.
Acts are broken into scenes to explore smaller, concrete goals. Browse the links above to learn more about the scenes in each act.
The actors in the System Delivery scenario share common CLM scenarios personas. In some cases, the role name may be adjusted to suit the vocabulary and needs of the scenario. In summary, for this scenario, we use the following teams and roles
The System Delivery scenario story starts with the project team preparing the System Delivery platform for the new project. Andy, one of the project admin(s), deploys or updates the system delivery platform tools. Scott, the development lead, configures the discipline processes and reports for the project. Some of the steps in the scenes below are shared across the CALM scenarios. Other steps are scenario extensions for the System Delivery platform.
In this act, we are deepening our understanding about
* Scenario extensions for system delivery
In this act, we explore how the project is started. Our focus is on System Engineering and Project Planning.
The first scene explores how Ursula, the product manager, is establishing the concept for the project through managing the stakeholder needs and managing the proposal and approval of the system delivery project. We then switch to the next scene where the System Engineering team captures the system requirements, system use-cases, and how traceability is established between the system requirements. In the following two scenes, we explore how the project leadership team is transforming the prioritized system requirements into a project plan, development plans, and test plans. In the final scene, the project leaders are reviewing, approve, and baselining the project plans.
In this act, we are deepening our understanding about
This act in the scenario focuses on two areas in the lifecycle management resource structure; the system requirements, and the plans of the project.
In this act, we use the System Development practices to explore how the team uses the System Delivery platform to realize system requirements as part of one increment/iteration.
The software sub-system team (in the system delivery project) is using an agile approach to iterative (incremental/spiral) development. Each project iteration is planned for about 4-6 weeks. The objective of each iteration is to realize and validate a set of system requirements and use-cases, resolve prioritized defects and change requests, and integrate the sub-systems into a complete integrated demonstrator/prototype of the system product.
There are potentially many details to explore in this act. We primarily focus the exploitation on two workflows
In this act, we are deepening our understanding about
This act in the scenario focuses on the lifecycle resources managed by one of the development teams. It expands the resource structure established in Act 2 in the context of the realization of a system requirement. The key lifecycle resources are
In this act, we explore the Requirements Change Management capability in the System Delivery platform.
In Act 1 the team approved a set of requirements. In this Act a change request has come in that impacts the baselined plan. We explore the steps of how the team agrees to accept it, which changes the requirements, the dev & test teams also respond to the change.
The Requirements Change Management scenario outlines a set of core OSLC resources
This act in the scenario expands the lifecycle resources to explore the relations to project planning and realization and validation of the changed requirement. These resources include
The system project is approaching its delivery. The focus of the remaining iteration/increment is to stabilize the release. Process changes where deliveries require approvals. But the main focus is on the system versification
In this act, we are deepening our understanding about
Jazz.netIn 2010 I led to the design of Systems Lifecycle Management and System Delivery scenario with Collaborative Lifecycle Management (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.
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
The System Delivery scenario extends the objectives by focusing on
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.
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 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
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
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 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.netThis whitepaper guides enterprise teams in adopting new Jazz-based tools to improve their team performance. Such teams are often expected to stay integrated with existing project or corporate change management workflows and require tool interoperability that integrates the new and existing change management tool solutions
Systems delivery is often divided into multiple categories, for example, systems engineering, project management, software engineering, and quality management. These categories interconnect across the systems delivery life cycle, performing distinct tasks and creating distinct life cycle work products. The IBM Rational Workbench for Systems and Software Engineering software is a life cycle management solution that supports such collaborative tasks and linking of the life cycle work products. The Workbench also enacts the systems delivery workflows and provides task management capabilities to effectively run the systems delivery project.
The new IBM Redpaper is intended for systems delivery teams who require an integrated solution for systems life cycle management for systems and software engineering. It illustrates how proven methodologies and best-of-breed tools, such as Rational DOORS, Rational Rhapsody, Rational Team Concert, and Rational Quality Manager, can help you design high-quality products that meet customer requirements during the innovation process for smarter products. The paper was produced by IBM Rational Solution Architect Mats Göthe and Chief Evangelist Bruce Douglass. We provide an expert look into the processes and best practices that enable effective product development.
The product line engineering capability adds a Configuration Management menu to the practitioner tools in the IBM IoT Continuous Engineering solution. The menu provides commands to select a configuration context and perform actions on the current configuration context. is a baseline or stream that contains a set of versioned artifacts. A global configuration represents a physical or logical piece of a product offering. It gathers configurations for itself and other contributing applications in IoT Continuous Engineering solutions.
The Configuration Management menu allows users to choose a Project Area configuration of the project area currently opened in the application. The menu also allows users to choose a Global Configuration context. Once a configuration has been chosen, the user may use the Configuration Management menu to create new streams or baselines. Users may also deliver changes from or into the currently selected baseline.
The hill for PLE states that “Hill 1: Teams enjoy configuration management in and across their ALM tools” and that “With minimal impact to current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.”
The hill for PLE states that “Hill 1: Teams enjoy configuration management in and across their ALM tools” and that “With minimal impact to current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.”
User research identifies the need to scope the capabilities on the Configuration Management menu to the right level of user maturity
Early playback of Configuration Management menu
Running code prototypes of Configuration Management Application
Released version of Configuration Management Application
Global Configuration Management integrates with the following CLM applications.
The hills for PLE state that
The Global Configuration Tool
User stories for the administration of global configurations
User stories for working with global configurations
Early playback of Configuration Management
Running code prototypes of Configuration Management Application
Released version of Configuration Management Application
In 2014 I was leading the design concepts for Product Line Engineering in the IoT Continuous Engineering solution.
The industry is making amazing IoT innovations in the products, systems, and applications that impact most of our daily lives: from the smallest transistors in the latest microprocessor making the simplest THINGS smarter to the most advanced products like cars, airplanes, transportation systems, city infrastructures and globe-spanning electronic networks we now take for granted. Increasingly powerful yet inexpensive hardware, embedded and cloud-based software, and ubiquitous network connectivity are enabling new levels of intelligence, interconnections, and instrumentation.
The price we pay for this progress is increasing complexity in the designs, development processes, and supply chains needed to create these smarter products and systems. In many industries, development teams are finding their old development processes and tools to be insufficient to meet the challenges. For example, Engineering teams in auto companies have traditionally focused on mechanical engineering; now the majority of the requirements they must address are expressed in software running on the many processors networked together in a modern car.
Smartphone device manufacturers employ an army of programmers to manage the torrent of monthly changes in the Android operating system and evolve their proprietary value-adds. IT application development managers deal with extensive supply chains as they seek to optimize cost, quality, and time to market.
The IBM continuous engineering solution is a set of engineering and development tools that help systems engineers, application developers, and embedded developers work together to create product lines of smart and connected products.
A product line strategy helps to address the timeless need to work faster, cheaper and better. For example:
A Product Line is a group of closely related products that are variants of each other. A product is formed from a specific configuration of component parts, often produced from a common base, or architecture, of components. Each component used in a product has associated requirements specifications, designs, software, test plans, and more. These artifacts are linked Requirements are linked to the design artifacts at the system and subsystem level that model the requirements. The design is linked to the implementing code. Tests are linked to the requirements and code they validate. The links declare dependencies and enable traceability and impact analysis..
However, the requirements specifications of each product in a product line are slightly varying. For example, a Compact car has different product requirements as compared to a Premium car. As the requirements specifications are different all downstream artifacts like designs, software, test plans are also impacted.
A common approach to manage the variability is to use a ‘Clone and Own’ practice. When stating developing a new product variant a copy is made of all requirements specifications, designs, software, test plans, and other associated artifacts. Requirements specifications for the new product variant are modified or added in the copy. Requirements specifications that do not apply to the new variant are removed. All downstream artifacts and traced and updated similarly. While this approach is simple and pragmatic it is ineffective. It is challenging to share components across products and leverage improvements made in one product variant with other variants. Defects have to be coordinated and fixed in every variant individually by each product team. The use of development resources is also ineffective. A system engineer, a system developer, or a tester can not easily switch tasks between project variants. Recreating a development environment with a complete and accurate set of requirements, designs, code, and tests is highly manual and can easily take several hours. Making sure that the environment is correct and consistent with the latest state of all versions is challenging and tedious.
A more effective way of working would be to offload the challenge of variants and configurations to the development tools. Imagine a tool that would manage all requirements, designs, code files, and tests and a structure representing each reusable component in a product, including the system, subsystem, SW, and HW levels. Then, imagine that each of the components has been branched into variants. The tool would manage the changes made to artifacts in each component variant. And then finally, imagine a way to select what variant of each component that would be used by each product variant in a product line. That would be so cool! And as a practitioner, I would be able to just ‘ask the tool’ to present me with the right artifacts for each component by choosing the product variant I wanted to work with. And, then, when ‘asking the tool’ to switch to another product variant the tool would transparently just present the right artifacts of the new variant. Just like that, switch configuration in seconds. That simplicity of operation and assurance of correct artifact version is the value proposition to enterprise-sized systems delivery organizations that are challenged by the market demands of delivering product variants and inefficiency of managing the development of the product lines.
Artifacts, like the products they describe, have versions. A version of an artifact is identified by a specific set of characteristics and can exist at the same time as other versions of the artifact in other configurations. Artifacts are contained by components to make them easily tracked and reused. Product line engineering adds configuration management to enable System Engineering teams to effectively work on changes for a given product variant.
Our objectives are to design PLE by adding capabilities to our existing Application Lifecycle Management tools and articulating best practices, rather than creating a new PLE tool
PLE aspects concern the entire development process. This strategy focuses on the supporting infrastructure for artifact management and reuses needed to support PLE practices.
This strategy enables
My research and analysis led our design to two key System Engineering personas and two PLE hills
Hill 1. Teams enjoy configuration management in and across their ALM tools
Subhill 1.1 Fine-grained components in RDNG and RQM
Subhill 1.2 Impact analysis using validity assertions
Subhill 1.3 Report from the lifecycle index with versioned data from GCM, RQM, RDM, RTC, including using data currently missing and data related to plans and project areas
Hill 2 – Technical foundation
Provide and adopt service additions for multi-stream configuration management in Foundation, DNG, RQM, RTC, and DM
Product Line Engineering capabilities should enable development organizations to
The Product Line Engineering hills call out two major use-cases
“We have 30 products in our product line with 5 variants of each product. We release every product variant 2 times every 18 months with about 30-45 new features in each release. A product contains 300 modules with 500 reusable objects per module. The release roadmap and mapping it to the requirements is a pain point.” “Our current pain points are; Traceability analysis and baselining Feature change management, and Product change management. We need to view requirement states across all releases.” “Your PLE 2014 Design Hills and direction resonate well with our needs. We have been waiting for this solution for years” “Very glad you are being intentional about minimizing impact to existing users and enabling users to adapt better reuse patterns for reuse incrementally — that’s critical. We can’t expect to start from scratch. This has to be accessible to our teams without heroic changes to how they are working now.” After seeing the playback and our discussions at the Sponsor User call today, here are some quotes from my team: “big leap forward”, “great progress”, “these demos can impress some of our executive people”Read more about Strategic reuse and product line engineering in an article by Eran Gary, Distinguished Engineer, Rational Continuous Engineering.
