The IBM solution for Continuous Engineering delivers rich capabilities for impact analysis. And we are seeking ways to make use of these capabilities easier by removing tool boundaries, enabling collaboration in the I/A process, simplifying the building and using tabular and diagram report views, and simplifying the building and using visual views. This session discusses the need for Impact Analysis.
k validity is a status on a link between artifacts to indicate whether the contents of two artifacts meet the intended meaning of their link. This session introduces the Validity concept and the user experience design.
The PLE solution is impacting the user experience in all participating CE tools. The PLE design is not just the look, but also the same behavior across the solution. This session discusses the consistent items and their ranking in the product plan.
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.
PLE Hills
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
System Engineers and Testers may be assigned work in a configuration. Such a user just wants to browse from the work item into the configuration selected for the work. The user experience for switching into a configuration should now require any action by the user.
Users with no permissions for Configuration Management should not see such actions on the Configuration Management menu
System Engineers with Configuration Management permissions should be presented with menu commands to choose a configuration context.
System Engineers with Configuration Management permissions should be presented links to browse into the definition of a global configuration in the Configuration Management Application
User Experience Low Fidelity Design – Configuration Management menu
Early playback of Configuration Management menu
User Experience High Fidelity Prototypes
Running code prototypes of Configuration Management Application
User Experience – IBM IoT Continuous Engineering 6.0 GA
Released version of Configuration Management Application
Global Configuration Management (GCM) is an application that assembles configurations for itself and other contributing applications so teams can gain an overall view of the physical and logical parts of their product offering.
A configuration 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.
Global Configuration Management integrates with the following CLM applications.
The Requirements Management application (RM) delivers requirements definition and requirements management capabilities.
The Quality Management (QM) application delivers testing and test management capabilities.
The Design Management (DM) application delivers design management capabilities.
The software configuration management part of the Rational Team Concert™ application delivers work item capabilities.
In 2014 I was leading the design concepts for Product Line Engineering in the IoT Continuous Engineering solution.
What is Product Line Engineering
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:
Increase revenue by reaching more market segments/niches. Product variants provide targeted sets of capabilities, price points, and compliance with specific regulatory regimes.
Improve time to market and lower development costs. Products are defined as sets of reusable components in a product line.
Improve quality and lower field service costs. (A) Reusing validated and verified components already in the field results in lower defect densities and field service costs. (B) Engineering tools that can automate the reconstruction of complex product configurations used by clients will reduce field service costs through increased productivity of the engineers, for example, when preparing their environment to find and fix a defect.
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.
“Product lines are a development paradigm allowing companies to realize order-of-magnitude improvements in time to market, cost, productivity, quality, and other business drivers. Software product line engineering can also enable rapid market entry and flexible response, and provide a capability for mass customization” – Software Product Line handbook by SEI
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.
PLE design strategy
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.
Specifying a multi-domain product structure – What is exactly the product?
Consistently manage asset versions and product configurations across all lifecycle disciplines – Create cross-product baselines
Effectively handling change propagation to the multitude of variants – Where does this change need to go
Effectively creating new product configuration based on functional parameters – What features define my new product variant
This strategy enables
Product development teams to
Achieve high levels of reuse and parallel development
Define and work in the context of the products and components they are developing
Engineer product lines
Work across engineering domains
Employ version and configuration management across these domains
Federated data that is created and managed by multiple tools from multiple vendors
Use open standards and specifications
Enterprise-scale with worldwide teams
Hills
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
With minimal impact on current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.
Configuration Leads can define configurations of a product under development consisting of requirements, tests, designs, and implementation.
Teams work in a scalable environment with 1000s of configurations consisting of artifacts managed in multiple tools and links within and across those 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
Provide and adopt a Global Configurations SDK
Provide and adopt Link service
Enable configuration-aware aware dashboards and product artifact views, including document generation and TRS data feeds in RQM
Enable configuration-aware TRS data feeds in RDNG, RTC, DM and fill the data gaps in RTC, Foundation
Provide and adopt validity service
Use-Cases
Product Line Engineering capabilities should enable development organizations to
Decompose products into (independent) reusable components, like requirements modules, test plans, and design packages or blocks
Develop new products by reusing and modifying components
Develop and release a platform of reusable components that can be combined into new variants of products
Develop and release components of related requirements, tests, designs, and implementation into a reusable global configuration component
Re-factor artifacts across components within the same project area, split and merge components within the same project area.
Work in parallel when developing, releasing, and using variants of reusable components
Compose products under development from both released immutable component baselines and mutable component streams
Overview of the product, its parts, and the component configurations
Select a product configuration context, and then work, either collaboratively or in isolation, on changes in and across multiple components
Deliver or merge changes made in one component configuration to other component configurations
Report on components and their metadata, configurations and their metadata, and the artifacts in a configuration
The Product Line Engineering hills call out two major use-cases
The Configuration Lead creates a new product configuration
The System Engineer switches into and starts working in the context of the new configuration
Use-Case – Create a new product configuration
Use-Case – Switch and work in a context
“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.
The Automated Meter Reader scenario, used in Product Line Engineering design, uses a fictitious company JK Meters Corp, aspiring leaders of Smarter Flow Products for Utilities.
About JK Meters Corp
The Metering Division at JK Meters Corp has a range of Automated Meter Reader products in its product line. The innovative flow detection solutions combine flow sensors, digital monitors integrated with network communication features that are installed both above and below ground, units for gas and water pipe and pump attached flow control, along with meter reader equipment to commission and extract metering information, increasingly using wireless technologies. The Metering division also develops applications that provide industry partners and consumers with analytics on consumption, diagnostic, and status and solutions for customer billing and service management.
The most successful product is the Automated Meter Reader for Water Flow (see figure below). The product consists of meter interface units mounted on water pipes. The meter interface unit measures flow and delivers data to handheld or car-mounted meter readers. The registered meter readings are uploaded from the handheld devices to the AMR server data management system manually. Uploading of data is performed continuously by the mobile meter readers using a mobile network connection, or manually when returning to the office at the end of the day when using the manual meter reader product.
The Automated Meter Reader products are delivered to utility customers worldwide and the products are developed with variants for each regional market. The variants are configured for regional requirements on power voltage, dimensions on pipe mounting, regional units of flow and volume, language configuration for the handheld meter readers, and regional city maps for GPS routing.
The Metering Division is currently investing in improved features in the product lines and new AMR products. An innovative new AMR Grid product reduces the operational cost of utility services by providing fixed grid meter readers that continuously read a wireless grid of residential or industrial meter interface units and uploads data over a fixed network connection.
About the Organization in the Metering Division
Under the direction of Product Management and Sales, the Metering Division organizes Development, Product quality, Operations with production and maintenance in North America, Europe, India, and China. Development is organized around Enterprise systems for IT, business, and analytics applications and products, and on Sensor systems with integration of sensor technologies and devices. 3rd party suppliers are used for some sub-system development and delivery (not emphasized within the current scenario). The Metering Division teams are distributed and rely on a common product and systems development lifecycle infrastructure for development collaboration and product delivery.
The Metering Division organizes its Development in a matrix of projects and disciplines. The disciplines, managed by discipline managers, are responsible for the definition and continuous improvements of practices and contributor skills. Team members from the discipline are assigned to the project organization and work in the product development team under the leadership of a project manager.
The success factors for the Metering Division Development is to achieve better use of development resources by improving the reuse of parts through product configurations, improvement in product quality, and productivity improvements through collaborative design of hardware and software sub-systems. JK Meters Corp has the initiative to improve the performance of its development and delivery activities for the Metering division. The AMR product development team has deployed IBM Rational’s Systems and Software Engineering solution are currently using change management (CM), requirements management (RM), model-driven systems engineering (MDSE), and quality management (QM) capabilities.
About the AMR Product Line
The Automated Meter Reader products are configured from reusable components. These component subsystems are developed and delivered by the Meter Reader, Meter Interface, and AMR Server platform teams. The AMR Manual product is configured from a Wired Meter Interface unit, a Manual Handheld Reader, and a generic AMR Server that is reused across the product line. The AMR Mobile and AMR Grid reuses the Wireless Meter Interface unit but differs in using a Mobile reader vs Grid Reader.
The Automated Meter Reader products have been delivered to utility customers in the US. JK Meters Corp is growing its market share by developing variants for other regional markets. The variants are configured with regional requirements on power voltage, dimensions on pipe mounting, regional units of flow and volume, language configuration for the handheld meter readers, and regional city maps for GPS routing. Meter Interfaces, Mobile Readers, and AMR Servers are adapted and regional variants are created for each market in the US, EU, and the UK.
The AMR Meter Interface is an electro-mechanical unit that connects to water pipes, gas pipes, or electrical cords and measures flow consumption and triggers alarms based on events and analytics. The unit is based on a standard microcontroller that connects to a sensor and runs the AMR Meter Interface embedded software and additional drivers for the sensor type. Backup power and communication components are attached to the controller.
The Handheld AMR Meter Reader is a rugged handheld Microsoft® Windows Mobile® tablet that connects over wire or RF to Meter Interface units for reading and uploading water, gas, or electrical flow consumption data and alarms. The unit provides GPS routing and Cellular GSM (EU) or CDMA (US) connectivity to AMR servers.
The unit is based on a standard tablet and runs the AMR Meter Interface Windows Mobile software. It integrates with Windows Mobile applications for messaging, map management, and routing. The unit may be ordered with a car mount kit that charges the unit and connects to the car audio system over Bluetooth.
Handheld AMR Meter Reader Parts
Windows Mobile tablet
Windows® Embedded Handheld 6.5 operating system
AMR RF expansion unit + AMR RF unit drivers
GPS expansion unit + GPS unit drivers
Cellular GSM and CDMA expansion units + Cellular unit drivers
The AMR Grid Reader is a fixed meter reader that connects over RF to Meter Interface units for uploading water, gas, or electrical and reads flow consumption data and alarms. The unit provides fixed internet or Cellular GSM (EU) or CDMA (US) connectivity to AMR servers. The unit is based on a standard ARM processor board and runs the AMR Grid Meter Reader Linux embedded software. The unit is equipped with an RF antenna, solar panel power, and a backup battery unit. GSM/CDMA or Ethernet cards are attached directly to the board.
The AMR Server is provided with our IBM partner using the PureData Systems solutions and runs the ARM Server data storage and services applications. JK Meters and IBM offers on-premise, hosted, or cloud configurations.
The AMR Server delivers the AMR data store, the AMR analytics engine, and system administration applications for a customer, infrastructure, operations, and system management. The system also delivers AMR services like billing, reporting, reading, alarms, forecasts and flow analysis, and infrastructure planning.
AMR Server Software Parts
AMR Administration
Server administration
Services administration
Customer administrations
Device administration
GRID administration
Handheld administration
Meter administration
Reusable Platform Components and Variant Product Line Configurations
The Automated Meter Reader products are configured from reusable components. These component subsystems are developed and delivered by the Meter Reader, Meter Interface, and AMR Server platform teams. The platform teams deliver the component subsystems with feature variability for the product line. For example, the Meter Interface team delivers wired and wireless variants of the component for the Manual and Mobile products. The Meter Reader team delivers variant components for Manual, Mobile, and Grid products.
The Product Line Engineering capabilities in the IBM IoT Continuous Engineering solution is providing support to manage variants of components.
What is a Component?
A component is a unit of organization consisting of a reusable set of artifacts such as requirements, tests, designs, and source code. The Automated Meter Reader (AMR) teams are using components to organize the lifecycle artifacts under development. The teams have defined components both at the system/product level and at each subsystem level. Separate components are used to manage requirements, tests, designs, and source code at each level.
A configuration is a set of specific artifacts versions of a component. A configuration evolves as changes are made to the artifacts in the configuration. At different times it might contain different sets of artifact versions. Such a configuration is also called a stream. A stream can contain changes and is mutable. Snapshots of configurations (streams) at a certain time are called a baseline. Their role is to record a configuration state for either a comparison or simply later reuse. Baselines, can’t be changed, they are immutable.
As a configuration is a set of specific artifacts versions of a component, the use of two configurations for AMR system requirements will greatly help in managing the variability of artifacts across the US and UK markets. In two such configurations, common requirements will have the same artifact version but a specific requirement for the UK configuration will have a different version as compared to the US configuration.
The AMR teams are using several streams to manage variability across the product line. Streams are branched for the Manual, Mobile, and Grid products. Streams are also used to manage variability across regional market US and UK products. The stream diagram below shows a conceptual view of the configuration dependencies.
The AMR teams create baselines consistently across all artifact types for each milestone and release. The baselines are used to branch new streams for changes going into the next product release.
The AMR teams are using global configurations to organize the components for the system level. This enables the system requirements, design models, tests and source code to be managed as a single global configuration. You will use the IBM Rational Configuration Management application to create an AMR Mobile UK global configuration that assembles the requirements and test streams for Mobile UK you created in the previous part. The Automated Meter Reader (AMR) platform teams are using individual global configurations to develop and deliver the Meter Reader, Meter Interface, and AMR Server subsystems.
Charles, Configuration Lead. Charles is in the engineering organization. He is supporting the team(s) by administrating and creating stream and baseline configurations. He has a good product line overview and makes decisions on the best options for component versions.
Susan, Systems Engineer. Performs requirements analysis, modeling, and simulation to manage complexity. She collaborates with lead engineers from various hardware and software disciplines to design the system to meet stakeholders’ needs.
Pete, Project manager. Pete is managing the schedule and scope of the Mobile AMR 2013 UK project. He creates and assigns tasks across the team. He makes sure reviews are made and approvals are given. He makes sure the state of artifacts is kept by initiating that baselines are taken. He tracks project measures and makes sure artifacts progress to completion.
Pam, Product Manager. Pam is in the marketing organization. She works closely with customers to understand market needs and opportunities, and defines and manages products and variants to meet customer needs
Dan, Embedded Software Developer. Creates the software design model and implements the System Engineering model. Designs, implements, and unit test the software model using Model-Driven Development.
Allison, Tools Administrator. Installs, Configures and Maintains tools in production. Maintains project templates and creates tool repositories using templates.
The personas appear in two types of development teams.
The AMR Product teams deliver product variants for multiple markets
The AMR Platform team delivers reusable components for the product teams the Platform team
The AMR Mobile Product team is responsible for delivering the mobile product variants to the US, EU, and UK markets. The team reuses and refines components delivered by the platform component teams. The AMR Meter Reader platform component team is responsible for delivering reusable components for the AMR project line. The teams share resources for stared tasks, e.g Configuration management, Build, and Tool Administration. Separating the responsibilities of Project and Platform teams is significant and captures patterns of organizing teams and practices around effectively developing product lines.
AMR Mobile Product team
The personas appear in two types of development teams.
The AMR Product teams deliver product variants for multiple markets
The AMR Platform team delivers reusable components for the product teams the Platform team
The AMR Mobile Product team is responsible for delivering the mobile product variants to the US, EU, and UK markets. The team reuses and refines components delivered by the platform component teams. The AMR Meter Reader platform component team is responsible for delivering reusable components for the AMR project line. The teams share resources for stared tasks, e.g Configuration management, Build, and Tool Administration.
Separating the responsibilities of Project and Platform teams is significant and captures patterns of organizing teams and practices around effectively developing product lines.
Susan Systems Engineer B.Sc., Mechanical Engineering M.Sc., Systems Engineering
“I see the big picture to manage the complexity of the system”
Susan has been with the current company for about 10 years and has over 20 years of systems engineering experience in the industry. Her current project is building a smarter hybrid car. She has a BSc. in Mechanical Engineering and a graduate degree in Systems Engineering.
As part of her daily job, Susan uses a host of tools that include modeling and simulation, requirements analysis to manage complexity. She collaborates with lead engineers from various hardware and software disciplines to design the system to meet stakeholders’ needs, but also interacts with stakeholders to manage their expectations and to complete the project on time and within budget. She constantly monitors and investigates how all the pieces in the system fit and work together, but currently, it is not always easy to get a big picture view of the entire system or up-to-date information on components in the system.
Responsibilities
Collaborate with domain leads to perform. requirements definition, modeling, top-level functional designs to organize and coordinate other engineering activities. Susan collaborates with product management, project management, test, and design. Lifecycle cost analysis is performed by IPT (Integrated Product Team) lead.
Act as the primary interface between management, customers, suppliers, and specialty engineers in the systems development process.
Susan works closely with marketing to understand customers’ needs and works with tools architects to ensure tools/processes match everyone’s needs.
Support change review board.
Ensure complete requirements traceability from business requirements to systems to subsystems.
Goals
Manage the complexity of the system.
Detailing the requirements of the system.
Defining, characterizing, and documenting. subsystems and the interactions among them.
Organize and coordinate systems development activities and processes.
Pain Points
Get a big picture view of the entire system or up-to-date information on components in the system- large dependency of tools knowing how to extract needed information.
Maintain awareness of changes throughout the systems development process, more importance on the solid process for change management (change records, review proposed changes). This includes both formal (reviews, propose changes) and informal (drafting, fewer reviews of each change, in preparation for peer reviews) change control. There are two main pain points here : (1) changes to requirements coming from different sources (2) communicating the change with the team.
Maintain and communicate to ensure all stakeholders are on the same page about the system requirements, design, and so on. This is part of the formal change control (stakeholder reviews as part of the change.
Identify where different members of the cross-function team are to be involved.
Oversees preparation of reports, such as statistical and data analysis reports, for all engineering processes.
Oversees policies, procedures, protocols, and controls that govern operations.
Balance across products and identify what is common across products and reuse.
Ensure architecture integrity in the system and make all architectural design decisions
Review and approve architectural changes
Goals
Organize and coordinate systems development activities and process
Work with Systems Integration Organization to ensure integration of components from various disciplines into a coherent and effective system.
Pain Points
Have appropriate tools to help with productivity and process guidance – heavily reliant on a requirements management tool (DOORS), users must be effectively trained.
Create a baseline of artifacts stored in all tools used in product development.
We are nearing the release of Collaborative Lifecycle Management (CLM) 6.0 that will include Configuration Management (CfgM) across lifecycle projects, which we developed using IBM Design principles. One of these principles in our design thinking is the use of release hills to express user value, objectives, and the scope of the release.
Our first hill for the 6.0 CfgM capabilities is to ensure 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’. To meet this objective we designed a simple, usable, and transparent user experience for practitioners to select, work and navigate in a configuration context.
Our second release hill is to ‘define configurations of a product under development consisting of requirements, tests, designs, and implementation’. For this objective, we designed configuration management administration in a new global configurations application.
Working with Artifacts and Links in a Configuration Context
User scenarios are a key part of our design process. In the scenarios for the first release hill, we focus on how personas, like Susan a system engineer, or Tony a tester, are using work item links to browse to artifacts in the right configuration context. For example, when following a link that Tony created in a defect, Susan would browse into the release baseline context to reproduce the defect. Or for change requests, Susan would browse into a development stream to update the linked artifacts. In both cases, we pursued a design that simply switches the practitioner into the right configuration context.
In the CLM 6.0 release, we designed a simple and transparent configuration selection and navigation mechanism for these scenarios. It’s based on the assumption that administrators or project leads will create ‘releases’ associated with project timeline iterations and global configurations in the work item system. Some ‘releases’ will represent immutable release baselines. Other releases will represent streams for new development.
As project leads, self-configuring teams or practitioners start assigning work to plans. The ‘Planned For’ and ‘Found In’ fields in the work items will be set and associated with such a ‘release’. When a practitioner follows a link to the target artifact, the right configuration and artifact version will be opened. The configuration is also used when hovering over a link to get a preview of the link target artifact. With this design, teams can easily adopt new configuration management practices with very low impact on users.
An alternate use-case for selecting a configuration is to use the Configuration Management menu on the application banner. By clicking the ‘Switch’ button a practitioner can browse and select a new configuration context. This simple design provides a consistent experience across the CLM 6.0 tools for requirements, tests, or design. The configuration context information on the application banner, found on the left side of the menu, gives practitioners a simple and accessible way to see and confirm the current configuration context. Also, the configuration management menu is designed to provide basic and advanced actions for managing configurations and change, including creating streams and baselines, managing changes by comparing configurations, and delivering changes across configurations.
Managing Global Configurations in the new Global Configurations Application
The scenarios and design for configuration leads and administrators have taken aim at a much richer configuration management user experience in the new Global Configurations application. Here administrators can create Global Configuration project areas that define global components with stream and baselines that provide consistent configuration management across requirements, tests, design, and implementation. Global configurations also provide key capabilities to manage products, product variants, and reuse. The design of the Global Configurations tool provides a hierarchal editor for global configurations with consistent new flat and clean icons and easy-to-find context actions which are also easy to use.
While the user experience is rich in configuration management administration capabilities, we also designed the tool to be easy to find and use for experienced practitioners that may need richer configuration management capabilities than provided by the tool configuration management menu. The design of the configuration management menu provides easy navigation directly to the Global Configuration editor for the current global configuration context by just clicking on the Global Configuration link in the menu. You can note this in the second image above this text.
The design of the Global Configurations tool provides great design consistency and usability. Project Area Configurations are picked and updated using consistent dialogs. The usability of the tool is improved through link navigation from the editor directly to the Project Area configuration in the context of the selected global configuration.
If you would like to see these new capabilities in action right away, you can give them a test run in the Jazz.net cloud trial area.
Mats Göthe Senior Designer and Scenario Design Lead
“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.”
Read more about Strategic reuse and product line engineering in an article by Eran Gary, Distinguished Engineer, Rational Continuous Engineering.
