Use SyncPoint To Migrate DOORS Data To Cockpit

Introduction

Cognition Cockpit users often have the need to move data between an existing DOORS database and the Cockpit tool.  This White Paper describes services that Cockpit provides to facilitate this information transfer. Cognition Corporation developed SyncPoint™ software to enhance the flow of information between DOORS and Cognition Cockpit.

The most basic transfer is a one-time migration from DOORS to Cockpit.  Even this basic transfer often will turn out to require multiple iterations and/or need to be done in stages.  In other situations there may be a need to sustain continued use of both the DOORS and the Cockpit databases.  An example of the latter can be where the Cockpit tool is being used for development of new requirements coupled to a larger requirements system still maintained in DOORS.  However, this White Paper will focus on one-way migration from DOORS to Cockpit.  We use the general term ‘Mapping’ to refer to either a one-time migration or to a future two-way synchronization arrangement.

The Cockpit tool provides facilities for establishing and synchronizing information transfer for all of these scenarios. These facilities are collectively called “SyncPoint™” in Cockpit.  SyncPoint™ provides the following services:

·        Examination of both DOORS and Cockpit databases for determining the relevant portions of each tool needing information alignment.

·        Setup for specifying how information transfers (migration, synchronization) are to be accomplished.

·        Automation of the information transfer processes.

·        Status reporting of what information is being transferred, synchronization status, error reporting, etc.  These status reports may be generated as Excel files.

·        Presentation in Cockpit formats of all the mapped DOORS data.

·        Export from Cockpit of any of the mapped DOORS data.   Exports may be done in number of formats, including Excel, Word, RIF, and specialized Cockpit XML, for example to another Cockpit Project.

Formats for Connecting to DOORS

Connection to the DOORS databases may be based on several alternative interface standards.  These standards are:

·        RIF (Requirements Interchange Format).  RIF is a relatively new standard that DOORS and Cockpit support for comprehensive two-way information flow.  RIF is XML based, as are the native Cockpit interfaces.

·        CSV/TSV [Comma-Separated Variables/Tab-Separated Variables] (for Spreadsheets).

·        Word (Microsoft Word files).  Word files exported from DOORS provide for the capture of graphics embedded within a DOORS Requirement Object.

SyncPoint™ supports each of these formats.  The formats serve different purposes.  RIF is the most comprehensive, and is particularly useful for two-way communication with DOORS.  CSV is particularly useful for dealing with object linkages as well as object data.  Word allows for having graphical items in addition to text and document structure.

Key SyncPoint™ Elements

DOORS Reference Object (DRO)

A fundamental building block of SyncPoint™ is the "DOORS Reference Object". The DRO is a type of Requirement object in Cockpit that has the following two properties:  1) If you look at a DRO from the DOORS direction it will reflect all the data that is being transferred from or linked with its corresponding DOORS Requirement Object.  2) If you look at that same DRO from the Cockpit model direction you will see that same DOORS information, plus any additional information added into the Cockpit Project for that object.  (An example added piece of information might be approval status as conducted from within the Cockpit Project.)  If a total migration away from DOORS is wanted SyncPoint™ can migrate the DRO’s into another requirement type in conformance with the Project at hand.

DOORS Module Document (DMD)

A DOORS Module Document is a defined type of Cockpit document that corresponds to a particular DOORS Module.  A DMD will have metadata that properly identifies it, including its matching Module in DOORS.  A Project-specific document template may also be used to present the same data.

A DOORS Module Document will contain within it a number of DOORS Reference Objects as described above.  There will be one DRO for each mapped DOORS Requirement Object in the DOORS Module.  Typically all the DOORS Requirements in the Module will be mapped, but it could be just a selected subset of objects.  The Cockpit DMD structure reflects the object hierarchy present in the DOORS Module.

As with normal Cockpit Document Objects, the document and its contacts may be viewed and reported on within Cognition Cockpit in several ways:

·        Use of the Cockpit Table of Contents

·        Specialized Cockpit body pages, including Tables

·        Cockpit live connectivity diagrams (Visio, Excel, etc.)

·        Cockpit Document Presentations / Exports (to Word, Excel, Powerpoint, Visio, etc.)

Representation of DOORS Links in Cockpit

DOORS Links are directional associations between Requirement objects.  These links may be between objects within a Module or between objects in different Modules.  Intra-Module Links in DOORS are strictly hierarchical; inter-Module links may be many-to-many. Cockpit’s SyncPoint™ may be used to create corresponding associations between DRO’s.  In Cockpit these links are represented as unidirectional Parent/Child Assogiations. 

The native Cockpit tool provides many facilities for viewing and navigating both hierarchical and non-hierarchical (many-to-one or many-to many) parent-child associations.  SyncPoint™ groups these associations in the same manner as the mapped DOORS file.  SyncPoint™ allows the user to navigate live graphical presentations of the linkage structure.  SyncPoint™ also provides reporting of this linkage structure in both tabular and spreadsheet form.

Summary of DOORS/Cockpit Terminology

	DOORS Term	Cockpit Term	Notes
	Requirement Object	DOORS Reference Object (DRO)	One Cockpit DRO will correspond to a given DOORS Requirement Object.  In the Cockpit Project this DRO will not only capture information from the DOORS object (ID, Text, Attributes, etc.), but may augmented and elaborated within Cockpit while still retaining the identity and data from the DOORS object.
	Requirement Object ID	DOORS Object ID (DID)	Fundamental basis for identifying corresponding requirement objects in each tool.
	Object Number	DOORS Object Number (DON)	DOORS Text Field conveying a Module’s object hierarchy.
	Object Name	DOORS Object Name [Title] (DOT)	DOORS-defined Requirement Object name
	Object Text	DOORS Object Text (DTx)	DOORS-defined Requirement Object body text
	Module	Cockpit Document: DOORS Module Document (DMD)	Typically a DOORS Module will be represented as a Cockpit Document.  The Cockpit Document will contain Requirement objects that correspond to objects in the DOORS module.
	Intra-Module Link	Cockpit Associations	DOORS Intra-module Links are One-to-Many (An object may have only a single parent).  Cockpit associations reflect these Links.
	Module-to-Module Link	Cockpit Associations	DOORS Module-to-Module Links may be Many-to-Many (An object in one Module may have multiple parents in other Modules).  Cockpit associations reflect these Links.
	N/A	Requirement Parameter	Mathematically-oriented Cockpit parameters do not have a counterpart in DOORS.  However such a Cockpit parameter may be part of an overall Requirement object, this hosting Cockpit Requirement object having a textual counterpart in DOORS.  The parameter value may be processed mathematically in Cockpit, but only represented as text in DOORS.
	Module ID [??]	DOORS Module ID	Unique identifier of a DOORS Module that is/ is to be synced to a Cockpit DOORS Module Document (DMD)
	Object Attribute	A Cockpit Custom Attribute called DOORS-Defined Attribute (DDA)	Upon import from DOORS to Cockpit, the Cockpit Project will acquire a customized attribute corresponding to each relevant or requested DOORS Object Attribute.
	Link	Association	In DOORS, Requirement Objects are Linked.  Links are maintained in dedicated ‘Link Modules’.  In a Cockpit Project this corresponding linkage information is maintained in the form of object associations.

Cockpit’s Dynamic Excel Spreadsheets

An important feature of the Cognition Cockpit tool is dynamically-linked Excel spreadsheets.  These spreadsheet files are maintained and configuration-managed from within the Cockpit Project.  They contain information that is dynamically linked (two-way) with Cockpit model data.  In the context of this White Paper these dynamic Excel spreadsheets mean that data may be moved between Cockpit DRO’s (DOORS Reference Objects) and Excel spreadsheets-- data that not only includes the DRO data, but also may include data from other objects throughout the Cockpit Project, and even additional Excel user data that is not directly synchronized with any particular Cockpit data.  (Constraints may be applied to ensure that the Excel sheets cannot improperly modify DRO data.)  These dynamic Excel spreadsheets are very valuable for collaborating between other organizations or other tools.

SyncPoint™ Actions

Actions: Specify DOORS Scope for Cockpit Project

Identify DOORS Files

Allows user to specify in a given Cockpit Project the DOORS Database for which data transfer is to be done.  The result will be the identification of a set of DOORS modules in a given DOORS Database for which data transfer with the Cockpit Project is to be accomplished. 

Typically these DOORS Modules will contain Requirement objects that have both intra-Module linkages as well as inter-Module linkages.  These links may also be exported in addition to the objects themselves.

Typically the DOORS Requirement Objects will have attributes associated with them. This attribute information may also be brought into the Cockpit Project.

A dedicated DOORS Scope Panel in Cockpit support the user in establishing the scope.

Actions: Setup DOORS Export to Cockpit

Set Up Module Export

Allows user to Specify the DOORS Module or Modules on the basis of which a new Cockpit DOORS Module Document (DMD) will be created.  The DMDs created will contain Cockpit Requirement objects that correspond to the DOORS Requirement Objects.

Set Up Object Export

Allows user to specify various options for importing data for a given object. 

Actions: Report on DOORS Database Import Status

Cockpit Reporting of DOORS Mapping Status

Cockpit SyncPoint™ provides many views and reports to show the status of mapping and synchronization between the Cockpit Project and mapped DOORS files.  (‘Mapping’ refers to DOORS-Cockpit associations that are scheduled for transfer/migration, have been transferred, or are in an ongoing synchronization status.)

Without going into detail in this White Paper, the following are general characteristics of the different DOORS Mapping status reporting available in SyncPoint™:

·        Identification of items in DOORS that are mapped (migrated or synchronized) in the Cockpit Project

·        Status of Actions like transfers or synchronization that have been taken or are planned to take place.  Status includes history, successes, errors/exceptions, statistics, etc.

·        Navigable graphical presentation of the relationship between linked items.

·        Exportable status reports, e.g. into Excel

File-level Status

·        DOORS File Identification

·        DOORS Module Identification

Inter-Module DOORS Links

·        File-level mapping status information

Module-level Status

·        Identification of Objects in Module

·        Module-level status information

Object-level Status

·        Object-level status information

·        Object Attribute Data

Actions: Export DOORS-linked Data

Cockpit provides a number of ways to export data that has been exported from or linked to a DOORS Database.  These include:

·        Word Document

·        Excel Spreadsheet

·        Cockpit Project data

Summary

Cockpit’s SyncPoint™ feature provides for easy migration of ALL information from DOORS files to a Cockpit Project.  Additional capabilities support ongoing two-way synchronization if one’s project has that need.

DOORS Elements Mappable with Cockpit include the following:

·        Identification of all DOORS Files, Modules, and Objects/Attributes that are mapped.

·        Data captured into Cockpit.

·        Selected (or all) DOORS Requirement Attributes.

·        DOORS Links, both within a Module, and between Modules.

·        DOORS Requirement content, including body text and embedded graphics.

SyncPoint™ provides specialized Cockpit Documents called DOORS Module Documents (DMD’s).  There is one DMD per mapped DOORS module.  DMD’s present data for objects in a DOORS Module as a collection specialized Cockpit requirements objects called DRO’s.  There is one DRO for each mapped DOORS Requirement Object.  The DOORS Module Document presents an object’s Identification, Body Text, Embedded Graphics, and Attributes.

SyncPoint™ utilizes ‘DOORS Reference Objects (DRO’s) that both reflect data that is mapped to DOORS, as well as holding additional associated data that is linked with the rest of the Cockpit Project.

The SyncPoint™ interface supports user for identifying and specifying how DOORS Data will map to a Cockpit Project; Viewing the status of migration or synchronization between the two tools; Viewing the mapped data from within Cockpit; and Exporting the DOORS-mapped data from Cockpit to several useful file formats.

Cognition Corporation Joins with SC&C Partner in Czech Republic to Deliver Cognition Cockpit Requirements Management and PLM Software to Eastern Europe

Cognition Corporation and SC&C Partner in Czech Republic team up to deliver advanced product development and lean solutions including six sigma, requirements management, PLM, and cost management throughout Eastern Europe. 

Bedford, MA December 08, 2010 

Cognition Corporation and SC&C Partner announce their partnership to provide companies in Eastern and Central Europe with services and software for advanced product development.

Martin O'Malley, Business Development Director and Six Sigma Master Black Belt at SC&C Partner, said "SC&C Partner is proud to join with Cognition Corporation to support advanced product development initiatives throughout Eastern Europe and Russia. There is strong interest in Cognition Cockpit software for requirements management and PLM in all of our industries and we at SC&C Partner are well qualified to support the implementation of systems engineering, requirements and risk management, PLM, and lean six sigma processes."

Together, SC&C Partner and Cognition Corporation bring the most advanced Web 2.0 / Enterprise 2.0 technology and implementation services to companies seeking advanced systems engineering processes, web based PLM/PDM, unified requirements management, and lean/six sigma product development processes.
David Cronin, a Director at Cognition, said "We are very excited about this new partnership with SCACP. Cognition has been expanding in Europe and Eastern Europe and SCACP is an established corporation with advanced skills in lean product development, systems engineering, and six sigma - exactly what we look for in partners."

SC&C Partner has a strong staff to help mentor people and projects and implement new product development processes. Their Czech Republic based team is experienced in the unique needs of the Eastern Europe market and their cultural and language skills make them effective coaches and partners to product development companies throughout Europe.

As they say in Prague:

Věříme, že Cockpit je prvním řešením, které poskytuje Jednoduchý a Unifikovaný Model, který zaznamenává a sleduje všechna data v rámci vývoje nového produktu.

 

Cost and Performance Design Trades During Product Development

Balancing Cost and Performance During Product Development

Cost Management - The process of cost management is partly encompassed by such topics as Cost As an Independent Variable (CAIV), Design To Cost (DTC), and Total Ownership Cost (TOC) or Total Acquisition Cost (TAC). Each of these can help engineers work towards designing a system at lower cost. In order to manage and interact with costs, the engineer must have timely access to all appropriate cost related information for a system. Most often, engineers (and cost professionals, for that matter) do not have consistent, timely access to cost data and information. Cost information exists in many formats and locations throughout the corporation.  Examples of some common cost  sources are listed in Table 1.

Table 1: Typical Sources and Types of Cost Related Data

The most important function of cost management is to bring together data and information from these various sources so the engineer can trade between  multiple estimates per part and keep a history of cost and design choices. This requires a knowledge management system built to handle cost related knowledge tied together with program structures. Structures are a way to organize cost (and later, performance) information. A structure is a collection of uniquely identifiable objects to which cost is attached. This implies a list of part numbers, a Bill Of Materials (BOM), Generation Breakdown (GB, or Work Breakdown Structure (WBS). See Figure 1 for an example of how a structure is “costed”.

Figure 1:  Creating a "costed" structure

Table 2: Dynamic attributes of an element in a costed structure

Cost information is associated with the appropriate part numbers; this provides a mechanism to switch between various cost estimates for each item. Each time a structure is “costed” can be thought of as a particular cost scenario for the structure. A history is developed whereby each part number has its collection of multiple estimates. These estimates will vary by source (ex. a vendor quote v. a guess based on “similar to” work), date, confidence, and creator. The structure will have multiple cost scenarios depending on which estimates are activated for each part during a roll up event. Scenarios can either be linked to a master WBS structure (updates to the master will update the scenario elements) or independent (no connection: updates to the structure are not passed to the scenario).
The costed structure is a dynamic entity with much information connected to each element. Table 2 shows some of the common attributes associated with each element. The structure is dynamic in that when a change occurs, say an update to a labor rate, the information percolates through the structure and updates appropriate elements.

This  behavior is important as it allows the costed structure to be driven, manually or automatically, to compare "what if" concepts and configurations. The structure is rolled up and compared under various algorithms; use the most current estimates per element, estimates made with a certain tool or method, from information entered by a particular user or group, etc. In this way users can rapidly explore various cost and configuration trades and see the immediate impact on the complete costed structure. Costs, and all the other attributes attached to the elements in a structure, are managed through a traceable history that follows a system from bid/propose through development to retirement/disposal.

Critical Parameter (Performance) Management (CPM) - The performance of a system is predicted and managed by various processes including Systems Engineering  (more specifically, through Technical Performance Management (TPM)) and Critical (or key) Parameter Management (CPM). Typically, Systems Engineering manages the higher-level requirements and parameters but does not tier down to the lowest level parameters that affect a system. The process of CPM best accomplishes this tiering, or flow down, of a system to its lowest parameters. Of course, the ultimate benefit of CPM is the ability to flow back up the path from low-level parameters to higher-level requirements.

CPM provides a series of techniques to enable engineers to track the interaction between requirements and the parameters that drive those requirements. Most companies are engaged in some form of CPM whether they use the phrase or not.  As  Figure 2 shows, CPM is a process that guides users through the steps of defining a system from high level “wants” and “shalls” to low-level critical specifications. In this way, CPM acts as an enabling backbone to the DFSS process by building the connections between Voice of the Customer, System Requirements, Sub Requirements, Parameters, and driving specifications. CPM becomes the tree to which all of the DFSS branches attach. The transfer functions bring the branches to life so the DFSS team can see immediate impacts of design changes.

Figure 2: Best practice "V" diagram showing CPM flow-down and flow-up of requirements

The higher-level parts of this “tree” are often defined through Systems Engineering.  CPM kicks in as the parameters are defined at lower and lower levels. Once this tree is complete, it defines a functional performance path through a system and helps identify which specifications and parameters are critical. By adding transfer functions to the tree, as shown in Figure 3 and Figure 4, the engineer creates a dynamic relationship between requirements and parameters that can be used to travel from the bottom of the tree back to the top. The result is a dynamic relationship between requirements and parameters. This is an extremely powerful process that provides feedback on the sensitivity of each critical parameter to the overall system. Table 3 gives some examples of the types of transfer functions used in CPM.

The relationship works two ways. By traveling down the tree, from the highest-level requirements (maybe even Voice Of the Customer) to the lowest level critical parameters, knowledge of the various system interactions can be traced. When the tree is studied from bottom up, the variations and sensitivities of critical parameters will result in specific, quantitative effects on the higher-level requirements. The CPM tree is “alive” with relationships between various parameters and requirements and helps build true knowledge of the performance and functional behavior of a system.

Figure 3: Transfer functions build quantitative relationships between requirements (and costs)

Figure 4: Transfer functions roll up  variation and sensitivities throughout the performance tree

Table 3: Transfer functions for typical Critical Parameter Management (CPM)

Balancing Cost and Performance

Defining the Process - As an engineer makes decisions regarding the performance of a system, the appropriate elements in the costed structure are flagged to indicate they need attention.  Someone (the engineer themselves, a cost professional, or other designated person) must update the cost on the affected element(s) or define a cost estimating relationship (CER) that will allow automatic updates to cost based on certain performance attributes. This change to cost will flow back to the CPM structure and update the parameter so the engineer can see the cost impact of their performance decision.

The process is bi-directional. When an element or cost in the costed structure changes (maybe a cost reduction initiative is realized and applied to the costed structure) that information flags the appropriate parameters and requirements in the CPM structure. The engineer will see the information and where/how it affects performance targets and estimates.  All of this is done either real time (if there are CER’s to calculate cost-performance trades) or near real time (a user must physically change a parameter or calculate a new estimate.)  Most companies do not yet have CER’s for all performance and cost interactions. This process of balancing cost and performance during design will help drive the need for these CER’s. Even the near real time method significantly shortens the trade study cycle time. 

Trade studies will take less time as the cost professional (or whoever is the user of the costed structure tree for the system) will now see immediately which elements are being altered by engineering throughout the design process. This allows them to work new cost estimates on effected elements with important input from the CPM tree. When the element flags itself as out of date, the cost user will see what caused the condition: a specification change to a critical parameter, tolerance information, functional alteration of the system or its behavior, or whatever caused the change. The cost user can now re-estimate elements while having vital input for the reason for the change. They make the new estimate and it flows back to the CPM tree and the engineer user sees the impact of their design decisions on cost.

Interact with the new Design Trade Space - This new process lets users manipulate the design trade space (shown in Figure 5) rapidly and with better fidelity. By providing rapid feedback between the cost and performance structures we make more time for trade studies and improve the overall fidelity of each estimate and prediction. A brief walkthrough of this interaction follows.

Figure 5: Balancing cost and performance during development enables near real time feedback within the trade space of the system

First, the relationship between performance parameters and cost (element) parameters is defined through team interactions, historical data, subject matter expert (SME) input, and best practices/tribal knowledge. This is where the connections are made that will later be followed when information changes. It is a one-time event. Figure 6 shows this in progress.

Figure 6: Defining the relationship between performance parameters and cost elements

Once these connections are established, there remains  a dynamic, bi-directional relationship between the various elements and parameters (Figure 7.) The two groups, design engineering and professional cost estimating/management, can now continue their once independent work. The difference now is that as each team enters or changes information, the other team will see the impact in their design space.

Figure 7: Specific part number elements are dynamically related to performance characteristics of the system

Figure 8 shows the heart of the process underway. Performance information is created/updated and then, through the dynamic link created at the beginning of the process, flowed to the cost elements for notification of the cost professional. If there are CER’s to define the relationship then automatic cost estimate updates will trigger. More likely, there is no complete set of CER’s today so the cost element flags the change and “asks” to be updated. The update (automatic with CER or manual by cost professional) is completed and flowed (again through the original dynamic link) back to the originating performance parameter. The engineer will see the cost impact of their design choice. Figure 9 shows information flowing back from the cost elements to the performance parameters.

Figure 8: Changes to the critical parameter (performance) tree will update the appropriate sections of the costed BOM/WBS structure.

Figure 9: A cost rollup is a type of transfer function within the critical parameter (performance) tree

At any point during the process, either side (performance or cost) can query for the change history of important performance and cost decision points. This allows users to explore the “why” behind a change. Figure 10 shows a cost professional’s view of an element. The user asked for the most recent change to an element and is alerted to a cost driver change from the performance tree: in this case, a change to the cutting rate specification requirements for a lawn mower system.

Figure 10: Query a part number element to learn of particular performance specification changes that will impact cost

Conclusion - Followers of this cost-performance balancing process will notice a reduction in the time to complete cost-performance-configuration changes. The automated interconnection between critical performance parameters and cost/structure elements means that users will see the information they need right away, and not need to wait for formal reviews or gates. Cost estimating results will improve in fidelity as key cost drivers are flowed through the system faster and more accurately. The cost professional will see the explicit performance characteristics that are being defined by engineering as they happen. Costing and cost management will gain respect as they will have more timely and accurate feedback to engineering. Development teams will not be able to avoid the costing process as they will have that near real time feedback right alongside their performance characteristics for each critical parameter of the system.

Critical parameter management

Check out this SlideShare Presentation:

Critical parameter management

View more documents from Cognition Corporation.

An Engineer Explains: Why Use Cockpit?

The following is from a recent conversation I had with Xiaobo Wang,  product development expert at Medtronic in Minnesota. We have been talking over the last year about how to improve product development without shocking the system with all new processes, tools, and mandates in a single, devastating blow? He summarized his thoughts and is gracious enough to let me publish them here. Let me know if you would like to talk to Xiaobo and I will arrange contact.

Q: What are advantages of using Cognition Cockpit in medical device development?

A: It is the methodological thinking and the potentials embedded in Cognition Cockpit that I am interested in the most. Following that methodology thinking, Cockpit has provided an environment that synchronizes design improvement / optimization activities from different functional areas in an organization. The environment provides the potential to help an organization reach operational optimization (of the PDP) or even business optimization. The synchronization of design improvement / optimization activities promotes concurrent data / information sharing / updating and, therefore, aligns “local” optimum solutions to “global” optimum solutions – the goals of a business. To me, there is no limitation for the potentials of the software, even though it can still be challenging to deploy the methodology thinking in a given environment. This difficulty to success could be due to lack of training, limitation from the culture of an organization, nature of human beings, or even the constraints from existing social structures.

Q:  Please explain more local v global optimization.

A: As an engineer, I have explored multiple levels of design optimization, from structure / shape optimization (such as using FEA or similar tools to reach a structure design with minimum weight and still satisfy stress / strain constraints, etc.) to process / operational optimization (such as developing concurrent engineering models to improve the efficiency of the product development process). Design optimization, to me, has always been a multiple discipline, multi level, constraint optimization problem. A “local optimum” solution (detailed optimum design) dose not always ensure the alignment to the “global optimum” solution (operation or business optimization). It has been a great experience to have Cockpit helping me to ensure this alignment. 

Q: What has your experience been like with Cognition Corporation as a vendor?

A: Cognition Corporation has the most dedicated engineers and supporting / service team to ensure the satisfaction of their customers. I can always get their help when I need. They are proactive in the way to pursuing a Win-Win solution with their customers.

Q: What are some of the tangible benefits of using Cockpit on medical device development projects?

A:  The benefits to the project and the company:

1. Improved efficiency
2. Shorter product development cycle
3. Better understanding to customer needs and the relationships between designed feathers to the needed
4. Ensure no critical issues / concerns ignored
5. The potential of building enterprise knowledge database that can be reused as starting point for similar designs
6. Traceability of development progresses
7. Confidence when a design is mature for release
8. Increased competition capability

Q: What has working with Cockpit meant for you as an individual?

A: The usage of Cockpit is aligned to the goal of my career and interest (design optimization has been my research interest for many years): it is a solution that I have been seeking for to close the gaps between optimization levels (from low level, detailed design optimizations to the overall objective of a business.)

1. Job satisfaction: meaningful tasks completed in more efficient way; real time feedback and linkages of requests and progress; perfectness of tasks completed (based on more / current available information and objective evaluation, instead of on subjective judgment)
2. Improved job security: when the competition capacity increased of a company, the job security of all the employees should be improved (based on certain assumptions.)

Using Social Media In Product Development

Social media use has lagged in product development. In many cases it is because people do not know how to use it effectively. A group at Xerox and Rochester Institute of Technology recently released a study of social media in product development with some valuable findings for engineering leaders. Their effort was part of a Capstone project for a Master of  Science in Product Development. Authors James Guentner, Matthew Hoffmann, and Seth Merritt have graciously allowed me to promote their work and give you access to their results. This is a wonderful paper to read if you are interested about how companies are meeting the challenge of including online collaboration and social media in day to day product development.

The Xerox-RIT Paper.

Numeric Requirements v Text Requirements

Most of us who are familiar with requirements management are used to the idea of a requirement being a textual "shall" description. For traditional requirements management, where a requirement is identified, written, and tested, the text based shall statement works fine. But what about when you have a requirement with a numeric target? Wouldn't it be nice to let the product development team make predictions about the requirement satisfaction instead of just a pass/fail statement? 

The Cognition Cockpit engine supports a new concept in requirements management: the idea of a numeric requirement type. This brings users the ability to define a requirement with a numeric target and calculate the predicted requirement value based on the values of sub requirements. This is sometimes referred to as Transfer Function Analysis (a phrase often used in the Design For Six Sigma (DFSS) world). Some requirements may be simple Pass Fail and are validated/verified through testing. Other requirements may have a specific physical target range and are more appropriately evaluated through transfer functions. Following is a (very simple) example of how Cockpit handles a numeric requirement:

Requirement:  Power (in an electric circuit)

Target:  "The Power shall be at least 10 Watts"

Subrequirements/Children of Power:

            Current

            Total Resistance

The engineer (or vendor/partner/whoever) enters possible design values for Current and Total Resistance.

            Current                       Design Value:  2 A +/- .1

            Total Resistance:        Design Value: 2.8 Ω +/-.05

Next, the engineer enters an equation in Cockpit (or uses a spreadsheet or uses Matlab: Cockpit can run transfers functions through various methods):

            Power = Current² * Total Resistance

Cockpit will now evaluate the equation using the inputs (with variation) from the subrequirements/children and calculate a predicted design value AND VARIATION for the target requirement:

Power                          Predicted Design Value:  11.2 +/-.1.138

Cockpit automatically evaluates this predicted design value for Power against the target statement for Power and does a Root Sum Squared (RSS) calculation and delivers the following information real time to the team:

Power             Process Capability/Cpk:  1.1  (or Z Score or PNC or DPMO)

Cockpit also automatically generates the following information real time (screen shot):

In this way, the engineer can see real time the likelihood that the Power requirement will meet its target. When a subrequirement of Power changes- for example if the owner of Current gets a new input from a vendor- Cockpit will recalculate the equation, notify the owners, and re-plot the results. In addition, Cockpit can run Monte Carlo analysis on Power using various distributions and distribution types (ex: normal, uniform, triangular, weibull) for the subrequirements Current and Total Resistance. In a real product development project there can be a series of tiered transfer functions at various levels of the requirements flowdown. Each equation will "roll up" as different values change on each subrequirement.

Here is a Cockpit screenshot showing the current engineering values for Power:

Note the user sees real time information for the Power requirement including predicted Design Value, predicted Process (long or short) Value, and statistical (not just Pass Fail) Test Data.

Cockpit will also automatically generate a real time Scorecard for Power:

Of course, if you are working with software requirements, Cockpit may simply use Pass Fail test results to "satisfy" the Power requirement (and flag defects where appropriate). However, in the case where you have a physical requirement the transfer function capability of Cockpit is a way for the design team to gain real time visibility into the predicted performance of a single requirement, group of requirements, or the entire system.