Sunday, September 23, 2007

Technichal Solution : Specific Practices by Goal SG3

Implement the Product Design
Product components, and associated support documentation, are implemented from their designs.
Product components are implemented from the designs established by the specific practices in the Develop the Design specific goal. The implementation usually includes unit testing of the product components
before sending them to product integration and development of enduser documentation.


SP 3.1 Implement the Design
Implement the designs of the product components.
For Software Engineering
Software code is a typical software product component.
Once the design has been completed, it is implemented as a product component. The characteristics of that implementation depend on the type of product component.
Design implementation at the top level of the product hierarchy involves the specification of each of the product components at the next level of the product hierarchy. This activity includes the allocation, refinement, and verification of each product component. It also involves the coordination between the various product-component development efforts.

Example characteristics of this implementation are as follows:
· Software is coded.
· Data is documented.
· Services are documented.
· Electrical and mechanical parts are fabricated.
· Product-unique manufacturing processes are put into operation.
· Processes are documented.
· Facilities are constructed.
· Materials are produced (e.g., a product-unique material could be a petroleum, oil, or lubricant, or a new alloy).
Typical Work Products
1. Implemented design
Subpractices
1. Use effective methods to implement the product components.

For Software Engineering
Examples of software coding methods include the following:
· Structured programming
· Object-oriented programming
· Automatic code generation
· Software code reuse
· Use of applicable design patterns


For Systems Engineering
Examples of appropriate fabrication methods include the following:

· Casting
· Molding
· Forming
· Joining
· Machining
· Tooling
· Welding
· Extruding

2. Adhere to applicable standards and criteria.

For Software Engineering
Examples of software coding standards include the following:
· Language standards
· Naming conventions for variables
· Acceptable language structures
· Structure and hierarchy of software product components
· Format of code and comments

For Software Engineering
Examples of software coding criteria include the following:
· Modularity
· Clarity
· Simplicity
· Structured (e.g., no GOTOs, one entrance, and one exit)
· Maintainability

For Systems Engineering
Examples of standards include the following:
· Standard Parts Lists
· Standard drawing requirements
· International Organization for Standardization (ISO) T3303 standards for manufactured parts

For Systems Engineering
Examples of criteria include the following:
· Maintainability

· Reliability
· Safety
3. Conduct peer reviews of the selected product components.

4. Perform unit testing of the product component as appropriate.
Note that unit testing is not limited to software. Unit testing involves the testing of individual hardware or software units or groups of related items prior to integration of those items.
5. Revise the product component as necessary.
An example of when the product component may need to be revised is when problems surface during implementation that could not be foreseen during design.


SP 3.2 Develop Product Support Documentation
Develop and maintain the end-use documentation.
This specific practice develops and maintains the documentation that will be used to install, operate, and maintain the product.

Typical Work Products
1. End-user training materials

2. User's manual
3. Operator's manual
4. Maintenance manual
5. Online help


Subpractices
1. Review the requirements, design, product, and test results to ensure that issues affecting the installation, operation, and maintenance documentation are identified and resolved.
2. Use effective methods to develop the installation, operation, and maintenance documentation.
3. Adhere to the applicable documentation standards.
Examples of documentation standards include the following:
· Compatibility with designated word processors
· Acceptable fonts
· Numbering of pages, sections, and paragraphs
· Consistency with a designated style manual
· Use of abbreviations
· Security classification markings
· Internationalization requirements
4. Develop preliminary versions of the installation, operation, and maintenance documentation in early phases of the project life cycle for review by the relevant stakeholders.
5. Conduct peer reviews of the installation, operation, and maintenance documentation.
6. Revise the installation, operation, and maintenance documentation as necessary.
Examples of when documentation may need to be revised include when the following events occur:
· Requirements change
· Design changes are made
· Product changes are made
· Documentation errors are identified
· Workaround fixes are identified

Technichal Solution : Specific Practices by Goal SG2

Develop the Design
Product or product-component designs are developed.

Product or product-component designs must provide the appropriate content not only for implementation, but also for other phases of the product life cycle such as modification, reprocurement, maintenance,
sustainment, and installation. The design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during
development and in subsequent phases of the product life cycle. A complete design description is documented in a technical data package that includes a full range of features and parameters including form, fit, function, interface, manufacturing process characteristics, and other parameters. Established organizational or project design standards (e.g., checklists, templates, object frameworks) form the basis for
achieving a high degree of definition and completeness in design documentation.


For Integrated Product and Process Development
The integrated teams develop the designs of the appropriate product-related life-cycle processes concurrently with the design of the product. These processes may be selected without modification from the organization’s set of standard processes, if appropriate.

SP 2.1 Design the Product or Product Component
Develop a design for the product or product component.
Product design consists of two broad phases that may overlap in execution: preliminary and detailed design. Preliminary design establishes product capabilities and the product architecture, including product partitions, product-component identifications, system states and modes, major intercomponent interfaces, and external product interfaces. Detailed design fully defines the structure and capabilities of the product components.

Architecture definition is driven from a set of architectural requirements developed during the requirements development processes. These requirements express the qualities and performance points that are critical to the success of the product. The architecture defines structural elements and coordination mechanisms that either directly satisfy requirements or support the achievement of the requirements as the details of the product design are established. Architectures may include standards and design rules governing development of product components and their interfaces as well as guidance to aid product developers. Specific practices in the Select Product-Component Solutions specific goal contain more information about using product architectures as a basis for alternative solutions.
Architects postulate and develop a model of the product, making judgments about allocation of requirements to product components including hardware and software. Multiple architectures, supporting alternative solutions, may be developed and analyzed to determine the advantages and disadvantages in the context of the architectural requirements.
Operational concepts and scenarios are used to generate use cases and quality scenarios that are used to refine the architecture. They are also used as a means to evaluate the suitability of the architecture for
its intended purpose during architecture evaluations, which are conducted periodically throughout product design. The Evolve Operational Concepts and Scenarios specific practice gives more information about elaborating operational concepts and scenarios used in architecture evaluation.


For Software Engineering
In addition to tasks identified above, software architecture definition may include:
· Establishing the structural relations of partitions and rules regarding interfaces between elements within partitions, and between partitions
· Identifying major internal interfaces and all external interfaces of software
· Identifying software product components
· Defining software coordination mechanisms
· Establishing infrastructure capabilities and services
· Developing product-component templates or classes and frameworks
· Establishing design rules and authority for making decisions
· Defining a process/thread model
· Defining physical deployment of software to hardware
· Identifying major reuse approaches and sources
During detailed design, the product architecture details are finalized, product components are completely defined, and interfaces are fully characterized. Product-component designs may be optimized for certain
qualities or performance characteristics. Designers may evaluate the use of legacy or COTS products for the product components. As the design matures, the requirements assigned to lower level product components are tracked to ensure those requirements are satisfied.


For Software Engineering
Detailed design is focused on software product-component development.The internal structure of product components is defined, data schema are generated, algorithms are developed, and heuristics are established to provide product-component capabilities that satisfy allocated requirements.


Typical Work Products
1. Product architecture
2. Product-component designs
Subpractices
1. Establish and maintain criteria against which the design can be evaluated.

Examples of attributes, in addition to expected performance, for which design criteria can be established, include the following:
· Modular
· Clear
· Simple
· Maintainable
· Verifiable
· Portable
· Reliable
· Accurate
· Secure
· Scalable
· Usable
2. Identify, develop, or acquire the design methods appropriate for the product.
Effective design methods can embody a wide range of activities, tools, and descriptive techniques. Whether a given method is effective or not depends on the situation. Two companies may have very effective design methods for products in which they specialize, but these methods may not be effective in cooperative
ventures. Highly sophisticated methods are not necessarily effective in the hands of designers that have not been trained in the use of the methods.
Whether or not a method is effective also depends on how much assistance it provides the designer, and the cost effectiveness of that assistance. For example, a multiyear prototyping effort may not be appropriate for a simple product component but might be the right thing to do for an unprecedented, expensive, and complex product development. Rapid prototyping techniques, however, may be highly effective for many product components. Methods that use tools to ensure that a design will encompass all the necessary attributes needed to implement the product-component design can be very effective. For example, a design tool that “knows” the capabilities of the manufacturing processes can allow the variability of the manufacturing process to be accounted for in the design tolerances.

Examples of techniques and methods that facilitate effective design include the following:
· Prototypes
· Structural models
· Object-oriented design
· Essential systems analysis
· Entity relationship models
· Design reuse
· Design patterns
3. Ensure that the design adheres to applicable design standards and criteria.

Examples of design standards include the following (some or all of these standards may be design criteria, particularly in circumstances where the standards have not been established):
· Operator interface standards
· Safety standards
· Production constraints
· Design tolerances
· Parts standards (e.g., production scrap and waste)
4. Ensure that the design adheres to allocated requirements.
Identified COTS product components must be taken into account. For example, putting existing product components into the product architecture might modify the requirements and the requirements allocation.
5. Document the design.


SP 2.2 Establish a Technical Data Package
Establish and maintain a technical data package.A technical data package provides the developer with a comprehensive description of the product or product component as it is developed. Such a package also provides procurement flexibility in a variety of circumstances such as performance-based contracting or build to print.
The design is recorded in a technical data package that is created during preliminary design to document the architecture definition. Thistechnical data package is maintained throughout the life of the productto record essential details of the product design. The technical datapackage provides the description of a product or product component(including product-related life-cycle processes if not handled asseparate product components) that supports an acquisition strategy, or the implementation, production, engineering, and logistics support phases of the product life cycle. The description includes the definition of the required design configuration and procedures to ensure adequacy of product or product-component performance. It includes all applicable technical data such as drawings, associated lists,specifications, design descriptions, design databases, standards,performance requirements, quality assurance provisions, and packaging details. The technical data package includes a description ofthe selected alternative solution that was chosen for implementation.
A technical data package should include the following if such information is appropriate for the type of product and product component (for example, material and manufacturing requirements maynot be useful for product components associated with software servicesor processes):
· Product architecture description
· Allocated requirements
· Product-component descriptions
· Product-related life-cycle process descriptions, if not described asseparate product components
· Key product characteristics
· Required physical characteristics and constraints
· Interface requirements
· Materials requirements (bills of material and materialcharacteristics)
· Fabrication and manufacturing requirements (for both the originalequipment manufacturer and field support)
· The verification criteria used to ensure that requirements havebeen achieved
· Conditions of use (environments) and operating/usage scenarios,modes and states for operations, support, training, manufacturing,disposal, and verifications throughout the life of the product· Rationale for decisions and characteristics (requirements,requirement allocations, and design choices)
Because design descriptions can involve a very large amount of data and be crucial to successful product-component development, it is advisable to establish criteria for organizing the data and for selecting
the data content. It is particularly useful to use the product architecture as a means of organizing this data and abstracting views that are clear and relevant to an issue or feature of interest. These views include the
following:
· Customers
· Requirements
· The environment
· Functional
· Logical
· Security
· Data
· States/modes
· Construction
· Management
These views are documented in the technical data package.

Typical Work Products
1. Technical data package
Subpractices
1. Determine the number of levels of design and the appropriate level of documentation for each design level.
Determining the number of levels of product components (e.g., subsystem,hardware configuration item, circuit board, computer software configuration item [CSCI], computer software product component, computer software unit) that require documentation and requirements traceability is important to manage
documentation costs and to support integration and verification plans.
2. Base detailed design descriptions on the allocated product component requirements, architecture, and higher level designs.
3. Document the design in the technical data package.
4. Document the rationale for key (i.e., significant effect on cost, schedule, or technical performance) decisions made or defined.

5. Revise the technical data package as necessary.

SP 2.3 Design Interfaces Using Criteria
Design comprehensive product-component interfaces in terms of established and maintained criteria.
Interface designs include the following:
· Origination
· Destination
· Stimulus and data characteristics for software
· Electrical, mechanical, and functional characteristics for hardware
The criteria for interfaces frequently reflect a comprehensive list of critical parameters that must be defined, or at least investigated, to ascertain their applicability. These parameters are often peculiar to a given type of product (e.g., software, mechanical, electrical) and are often associated with safety, security, durability, and mission-critical characteristics.


Typical Work Products
1. Interface design specifications
2. Interface control documents
3. Interface specification criteria
4. Rationale for selected interface design
Subpractices
1. Define interface criteria.
These criteria can be a part of the organizational process assets.

2. Apply the criteria to the interface design alternatives.
3. Document the selected interface designs and the rationale for the
selection.


SP 2.4 Perform Make, Buy, or Reuse Analyses
Evaluate whether the product components should be developed, purchased, or reused based on established criteria.
The determination of what products or product components will be acquired is frequently referred to as a “make-or-buy analysis.” It is based on an analysis of the needs of the project. This make-or-buy analysis begins early in the project during the first iteration of design, continues during the design process, and is completed with the decision to develop, acquire, or reuse the product

Factors affecting the make-or-buy decision include the following:
· Functions the products or services will provide and how these functions will fit into the project
· Available project resources and skills
· Costs of acquiring versus developing internally
· Critical delivery and integration dates
· Strategic business alliances, including high-level business requirements
· Market research of available products, including COTS products
· Functionality and quality of available products
· Skills and capabilities of potential suppliers
· Impact on core competencies
· Licenses, warranties, responsibilities, and limitations associated with products being acquired
· Product availability
· Proprietary issues
· Risk reduction

Many of these factors are addressed by the project.
The make-or-buy decision can be conducted using a formal evaluation
approach.

As technology evolves, so does the rationale for choosing to develop or purchase a product component. While complex development efforts may favor purchasing an off-the-shelf product component, advances in
productivity and tools may provide an opposing rationale. Off-the-shelf products may have incomplete or inaccurate documentation and may or may not be supported in the future.
Once the decision is made to purchase an off-the-shelf product component, the requirements are used to establish a supplier agreement. There are times when “off the shelf” refers to an existing item that may not be readily available in the marketplace. For example, some types of aircraft and engines are not truly “off the shelf” but can be readily procured. In some cases the use of such non-developed items is in situations where the specifics of the performance and other product characteristics expected need to be within the limits specified.In these cases, the requirements and acceptance criteria may need to be included in the supplier agreement and managed. In other cases, the off-the-shelf product is literally off the shelf (word processing software, for example) and there is no agreement with the supplier that needs to be managed.


Typical Work Products
1. Criteria for design and product-component reuse
2. Make-or-buy analyses

3. Guidelines for choosing COTS product components

Subpractices
1. Develop criteria for the reuse of product-component designs.
2. Analyze designs to determine if product components should be developed, reused, or purchased.

3. When purchased or non-developmental (COTS, government off the shelf, and reuse) items are selected, plan for their maintenance.

For Software Engineering
Consider how the compatibility of future releases of an operating system and a database manager will be handled.

Monday, September 17, 2007

Technichal Solution : Specific Practices by Goal SG1

This article provides information about selecting product component solutions considering the major areas, limitations, issues etc. The article defines the Technichal Solutions for the product-component solutions based on CMMI standards.

SG 1 Select Product-Component Solutions
Product or product-component solutions are selected from alternative solutions.

Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis.
Architectural features that provide a foundation for product improvement and evolution are considered. Use of commercial off-the-shelf (COTS) product components are considered relative to cost, schedule,
performance, and risk. COTS alternatives may be used with or without modification. Sometimes such items may require modifications to aspects such as interfaces or a customization of some of the features to
better achieve product requirements.
One indicator of a good design process is that the design was chosen after comparing and evaluating it against alternative solutions. Decisions on architecture, custom development versus off the shelf, and product-component modularization are typical of the design choices that are addressed.
Sometimes the search for solutions examines alternative instances of the same requirements with no allocations needed to lower level product components. Such is the case at the bottom of the product architecture. There are also cases where one or more of the solutions are fixed (e.g., a specific solution is directed or available product components, such as COTS, are investigated for use).
In the general case, solutions are defined as a set. That is, when defining the next layer of product components, the solution for each of the product components in the set is established. The alternative
solutions are not only different ways of addressing the same requirements, but they also reflect a different allocation of requirements among the product components comprising the solution set. The objective is to optimize the set as a whole and not the individual pieces.There will be significant interaction with processes associated with the Requirements Development process area to support the provisional allocations to product components until a solution set is selected and final allocations established.
Product-related life-cycle processes are among the product-component solutions that are selected from alternative solutions. Examples of these product-related life-cycle processes are the manufacturing and the
support processes.


SP 1.1 Develop Detailed Alternative Solutions and Selection Criteria
Develop detailed alternative solutions and selection criteria.

For Integrated Product and Process Development
The activity of selecting alternative solutions and issues to be subject to decision analyses and trade studies is accomplished by the involvement of relevant stakeholders. These stakeholders represent both business and technical functions and the concurrent development of the product and the product-related life-cycle processes (e.g., manufacturing,support, training, verification, and disposal). In this way, important issues surface earlier in product development than with traditional serial development and can be addressed before they become costly mistakes.
Detailed alternative solutions are an essential concept of the Technical Solution process area. They provide more accurate and comprehensive information about the solution than nondetailed alternatives. For example, characterization of performance based on design content rather than on simple estimating enables effective assessment and understanding of environment and operating concept impacts. Alternative solutions need to be identified and analyzed to enable the selection of a balanced solution across the life of the product in terms of cost, schedule, and technical performance. These solutions are based on proposed product architectures that address critical product qualities. Specific practices associated with the Develop the Design specific goal provide more information on developing potential product architectures that can be incorporated into alternative solutions for the product.
Alternative solutions span the acceptable range of cost, schedule, and performance. The product-component requirements are received and used along with design issues, constraints, and criteria to develop the
alternative solutions. Selection criteria would typically address costs (e.g., time, people, money), benefits (e.g., performance, capability,effectiveness), and risks (e.g., technical, cost, schedule).Considerations for detailed alternative solutions and selection criteria include the following:
· Cost (development, procurement, support, product life cycle)
· Technical performance
· Complexity of the product component and product-related life-cycle processes
· Robustness to product operating and use conditions, operating modes, environments, and variations in product-related life-cycle processes
· Product expansion and growth
· Technology limitations
· Sensitivity to construction methods and materials
· Risk

· Evolution of requirements and technology
· Disposal
· Capabilities and limitations of end users and operators


The considerations listed above are a basic set; organizations should develop screening criteria to narrow down the list of alternatives that are consistent with their business objectives. Product life-cycle cost, while
being a desirable parameter to minimize, may be outside the control of development organizations. A customer may not be willing to pay for features that cost more in the short term but ultimately decrease cost
over the life of the product. In such cases, customers should at least be advised of any potential for reducing life-cycle costs. The criteria used in selections of final solutions should provide a balanced approach to
costs, benefits, and risks.

Typical Work Products
1. Alternative solution screening criteria
2. Evaluations of new technologies
3. Alternative solutions
4. Selection criteria for final selection
Subpractices
1. Identify screening criteria to select a set of alternative solutions for consideration.
2. Identify technologies currently in use and new product technologies for competitive advantage.


The project should identify technologies applied to current products and processes and monitor the progress of currently used technologies throughout the life of the project. The project should identify, select, evaluate, and invest in new technologies to achieve competitive advantage. Alternative solutions could include
newly developed technologies, but could also include applying mature technologies in different applications or to maintain current methods.
3. Generate alternative solutions.
4. Obtain a complete requirements allocation for each alternative.
5. Develop the criteria for selecting the best alternative solution.

Criteria should be included that address design issues for the life of the product, such as provisions for more easily inserting new technologies or the ability to better exploit commercial products. Examples include criteria related to open design or open architecture concepts for the alternatives being evaluated.
6. Develop timeline scenarios for product operation and user interaction for each alternative solution.


The following specific practice appears in the continuous representation as SP 1.1-1, but is subsumed in the staged representation by SP 1.1, Develop Detailed Alternative Solutions and Selection Criteria. The specific practice is presented here only as informative material.


SP 1.1-1 Develop Alternative Solutions and Selection Criteria
Develop alternative solutions and selection criteria.

Alternatives are based on potential product architectures and span a design space of feasible solutions. The Design Product or Product Component specific practice of the Develop the Design specific goal
contains more information about developing potential product architectures to incorporate into alternative solutions for the product.
As selections are made, the design space may be constricted and other alternatives examined until the most promising (i.e., optimal) solutions that meet requirements and criteria are identified. The selection criteria
identify the key factors that provide a basis for the selection of the solution. These criteria should provide clear discrimination and an indication of success in arriving at a balanced solution across the life of
the product. They typically include measures of cost, schedule, performance, and risk.

The alternative solutions evaluated frequently encompass alternative requirement allocations to different product components. These alternatives may also be structured to evaluate the use of COTS solutions in the product architecture. Processes associated with the Requirements Development process area would then be employed to provide a more complete and robust provisional allocation of requirements to the alternative solutions.
Selection of the best solution establishes the requirements provisionally allocated to that solution as the set of allocated requirements. The circumstances in which it would not be useful to examine alternative
solutions are infrequent in new developments. However, developments of precedented product components are candidates for not examining, or only minimally examining, alternative solutions.


Typical Work Products
1. Alternative solutions
2. Selection criteria
Subpractices
1. Establish and maintain a process or processes for identifying solution alternatives, selection criteria, and design issues.
Selection criteria are influenced by a wide variety of factors driven by the requirements imposed on the project as well as the product life cycle. For example, criteria related to mitigating cost and schedule risks may influence a greater preference for COTS solutions provided such selections do not result in unacceptable risks for the remaining product components to be developed. When using existing items, such as COTS, either with or without modification, criteria dealing with diminishing sources of supply or technological obsolescence should be examined, as well as criteria capturing the benefits of standardization,
maintaining relationships with suppliers, and so forth. The criteria used in selections should provide a balanced approach to costs, benefits, and risks.

2. Identify alternative groupings of requirements that characterize sets of solution alternatives that span the feasible design space.

Effective employment of COTS alternatives can provide special challenges. Knowledgeable designers familiar with candidate COTS alternatives may explore architectural opportunities to exploit potential COTS payoffs.

3. Identify design issues for each solution alternative in each set of alternatives.


4. Characterize design issues and take appropriate action.

Appropriate action could be to characterize the issues as a risk for risk management, adjust the solution alternative to preclude the issues, or reject the solution alternative and replace it with a different alternative.

5. Obtain a complete requirements allocation for each alternative.

6. Document the rationale for each alternative set of solutions.

SP 1.2 Evolve Operational Concepts and Scenarios
Evolve the operational concept, scenarios, and environments to describe the conditions, operating modes, and operating states specific to each product component.

Operational concepts and scenarios are evolved to facilitate the selection of product-component solutions that, when implemented, will satisfy the intended use of the product. Operational concepts and
scenarios document the interaction of the product components with the environment, users, and other product components, regardless of engineering discipline. They should be documented for operations,
product deployment, delivery, support (including maintenance and sustainment), training, and disposal and for all modes and states.

The environments (operating, support, training, etc.) also need to be evolved. The environment of any given product component will be influenced by other product components as well as the external
environment.


Typical Work Products
1. Product-component operational concepts, scenarios, and environments for all product-related life-cycle processes (e.g., operations, support, training, manufacturing, deployment, fielding,delivery, and disposal)
2. Timeline analyses of product-component interactions
3. Use cases

Subpractices
1. Evolve the operational concepts and scenarios to a degree of detail appropriate for the product component.
2. Evolve the operational environments for the product components.

The environments may include thermal, stress, and electromagnetic and other elements that need to be documented.


SP 1.3 Select Product-Component Solutions
Select the product-component solutions that best satisfy the criteria established.


Selecting product components that best satisfy the criteria establishes the requirement allocations to product components. Lower level requirements are generated from the selected alternative and used to develop the product-component design. Interface requirements among product components are described, primarily functionally. Physical interface descriptions are included in the documentation for interfaces
to items and activities external to the product.
The description of the solutions and the rationale for selection are documented. The documentation evolves throughout development as solutions and detailed designs are developed and those designs are implemented. Maintaining a record of rationale is critical to downstream decision making. Such records keep downstream stakeholders from redoing work and provide insights to apply technology as it becomes available in applicable circumstances.


Typical Work Products
1. Product-component selection decisions and rationale
2. Documented relationships between requirements and product components
3. Documented solutions, evaluations, and rationale
Subpractices
1. Evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operating concepts, operating modes, and operating states.
2. Based on the evaluation of alternatives, assess the adequacy of the selection criteria and update these criteria as necessary.
3. Identify and resolve issues with the alternative solutions and requirements.
4. Select the best set of alternative solutions that satisfy the established selection criteria.
5. Establish the requirements associated with the selected set of alternatives as the set of allocated requirements to those product components.
6. Identify the product-component solutions that will be reused or acquired.

7. Establish and maintain the documentation of the solutions,evaluations, and rationale.

Thursday, September 6, 2007

Technichal Solution : CMMI Maturity Level 3

The purpose of Technical Solution is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle
processes either singly or in combinations as appropriate.


The Technical Solution process area is applicable at any level of the product architecture and to every product, product component, productrelated life-cycle process, and service. The process area focuses on the
following:
· Evaluating and selecting solutions (sometimes referred to as "design approaches," "design concepts," or "preliminary designs") that potentially satisfy an appropriate set of allocated requirements
· Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component)
· Implementing the designs as a product or product component Typically, these activities interactively support each other
. Some level of design, at times fairly detailed, may be needed to select solutions.
Product-component prototypes may be used as a means of gaining sufficient knowledge to develop a technical data package or a complete set of requirements.
Technical Solution specific practices apply not only to the product and product components but also to services and product-related life-cycle processes. The product-related life-cycle processes are developed in
concert with the product or product component. Such development may include selecting and adapting existing processes (including standard processes) for use as well as developing new processes.

Processes associated with the Technical Solution process area receive the product and product-component requirements from the requirements management processes. The requirements management processes place the requirements, which originate in requirements development processes, under appropriate configuration management and maintain their traceability to previous requirements.


For a maintenance or sustainment organization, the requirements in need of maintenance actions or redesign may be driven by user needs or latent defects in the product components. New requirements may arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where actual performance can be compared against the specified performance and unacceptable degradation can be identified. Processes associated with the Technical Solution process area should be used to perform the maintenance or sustainment design efforts.

Specific and Generic Goals
SG 1 Select Product-Component Solutions

Product or product-component solutions are selected from alternative solutions.
SG 2 Develop the Design
Product or product-component designs are developed.

SG 3 Implement the Product Design
Product components, and associated support documentation, are implemented from their designs.
GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Select Product-Component Solutions
SP 1.1 Develop Detailed Alternative Solutions and Selection Criteria
SP 1.2 Evolve Operational Concepts and Scenarios
SP 1.3 Select Product-Component Solutions

SG 2 Develop the Design
SP 2.1 Design the Product or Product Component
SP 2.2 Establish a Technical Data Package
SP 2.3 Design Interfaces Using Criteria
SP 2.4 Perform Make, Buy, or Reuse Analyses

SG 3 Implement the Product Design
SP 3.1 Implement the Design
SP 3.2 Develop Product Support Documentation

GG 3 Institutionalize a Defined Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 3.1 (AB 1) Establish a Defined Process
GP 2.2 (AB 2) Plan the Process
GP 2.3 (AB 3) Provide Resources
GP 2.4 (AB 4) Assign Responsibility
GP 2.5 (AB 5) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 3.2 (DI 4) Collect Improvement Information
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

Wednesday, September 5, 2007

Requirement Development: GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.
Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the requirements development process.
Elaboration:
This policy establishes organizational expectations for collecting stakeholder needs, formulating product and product-component requirements, and analyzing and validating those requirements.


Ability to Perform
GP 3.1 (AB 1) Establish a Defined Process
Establish and maintain the description of a defined requirements development process.

GP 2.2 (AB 2) Plan the Process
Establish and maintain the plan for performing the requirements development process.
Elaboration:
Typically, this plan for performing the requirements development process is a part of the project plan as described in the Project Planning process area.

GP 2.3 (AB 3) Provide Resources
Provide adequate resources for performing the requirements development process, developing the work products, and providing the services of the process.
Elaboration:
Special expertise in the application domain, methods for eliciting stakeholder needs, and methods and tools for specifying and analyzing customer, product, and product-component requirements may be
required.
Examples of other resources provided include the following tools:
· Requirements specification tools
· Simulators and modeling tools
· Prototyping tools
· Scenario definition and management tools
· Requirements tracking tools


GP 2.4 (AB 4) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements development process.

GP 2.5 (AB 5) Train People
Train the people performing or supporting the requirements development process as needed.
Elaboration:
Examples of training topics include the following: [PA157.EL105]
· Application domain
· Requirements definition and analysis
· Requirements elicitation
· Requirements specification and modeling
· Requirements tracking


Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the requirements development process under appropriate levels of configuration management.

Elaboration:
Examples of work products placed under configuration management include the following:

· Customer requirements
· Functional architecture
· Product and product-component requirements
· Interface requirements


GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the requirements development process as planned.

Elaboration:
Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process.
Examples of activities for stakeholder involvement include the following:
· Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces
· Establishing operational concepts and scenarios
· Assessing the adequacy of requirements
· Establishing product and product-component requirements
· Assessing product cost, schedule, and risk

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the requirements development process against the plan for performing the process and take appropriate corrective action.


Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Cost, schedule, and effort expended for rework
· Defect density of requirements specifications


GP 3.2 (DI 4) Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements development process to support the future use and improvement of the organization’s processes and process assets.

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the requirements development process against its process description, standards, and procedures, and address noncompliance.

Elaboration:
Examples of activities reviewed include the following:
· Collecting stakeholder needs
· Formulating product and product-component requirements
· Analyzing and validating product and product-component requirements
Examples of work products reviewed include the following:
· Product requirements
· Product-component requirements
· Interface requirements
· Functional architecture


GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the requirements development process with higher level management and resolve issues.