Firewalls: Circuit Level Gateway Firewall

Circuit Relay firewall or Circuit Level Gateway is an approach to configure a firewall that validates connections before allowing data to be exchanged. A circuit relay firewall is a type of security firewall (proxy server) that provides a controlled network connection between internal and external systems (that is, there is no "air gap"). A virtual "circuit" exists between the internal client and the proxy server. Internet requests go through this circuit to the proxy server, and the proxy server delivers those requests to the Internet after changing the IP (Internet Protocol) address.

All traffic is disallowed unless a session is open and every session of data exchange is validated and monitored. Using Circuit level gateway, IP spoofing is particularly much more tedious in comparison to the firewall based only on packet filtering. The Circuit Level Gateway operates at the Transport Layer of OSI Model. Traffic is filtered based on specified session rules and may be restricted to recognized computers only. Circuit-level firewalls hide the network itself from the outside, which is useful for denying access to intruders. But they don't filter individual packets.
Whether a connection is valid may for examples be based upon:
- destination IP address and/or port
- source IP address and/or port
- time of day
- protocol
- user
- password

SOCKS is an example of this type of firewall. This type of proxy is not aware of applications but just cross links your connects to another outside connection.

Firewalls : Network and Application layer firewalls

A firewall is a software program or device that monitors, and sometimes controls, all transmissions between an organization's internal network and the Internet. However large the network, a firewall is typically deployed on the network's edge to prevent inappropriate access to data behind the firewall. The firewall ensures that all communication in both directions conforms to an organization's security policy.

Network layer Firewalls
These generally make their decisions based on the source, destination addresses and ports in individual IP packets. A simple router is the ``traditional'' network layer firewall, since it is not able to make particularly sophisticated decisions about what a packet is actually talking to or where it actually came from. Network-level firewalls are fast, and today you'll find them built into most network appliances, particularly routers. These firewalls, however, don't support sophisticated rule-based models. They don’t understand languages like HTML and XML, and they are capable of decoding SSL-encrypted packets to examine their content. One thing that's an important distinction about many network layer firewalls is that they route traffic directly though them, so to use one you either need to have a validly assigned IP address block or to use a ``private internet'' address block. Network layer firewalls tend to be very fast and tend to be very transparent to users.

Application layer Firewalls

These generally are hosts running proxy servers, which permit no traffic directly between networks, and which perform elaborate logging and auditing of traffic passing through them. They can log user activity too. Application-level filtering may include protection against spam and viruses as well, and be able to block undesirable Web sites based on content rather than just their IP address. The downside to deep packet inspection is that the more closely a firewall examines network data flow, the longer it takes, and the heavier hit your network performance will sustain.

ISO 9001 - The International Standard for Quality Management

The standard covers all aspects of an organization’s activities including: identifying its key processes, defining roles and responsibilities, its policies & objectives, and documentation requirements. It also covers the importance of understanding & meeting customer requirements, communication, resource requirements, training, product & process planning, design processes, purchasing, production & service, monitoring and
measurement of products & processes, customer satisfaction, internal audit, management review, and improvement processes. ISO 9001 is based on the following eight Quality Management Principles, which are incorporated within the requirements of the
standard, and can be applied to improve organizational performance:
- Customer focus,
- Leadership,
- Involvement of people,
- Process approach,
- System approach to management,
- Continual improvement,
- Factual approach to decision making, and
- Mutually beneficial supplier relationships.

Benefits of implementing ISO 9001

- Implementing a Quality Management System will motivate staff by defining their key roles and responsibilities.
- Cost savings can be made through improved efficiency and productivity, as product or service deficiencies will be highlighted.
- From this, improvements can be developed, resulting in less waste, inappropriate or rejected work and fewer complaints.
- Customers will notice that orders are met consistently, on time and to the correct specification. This can open up the market place to increased opportunities.

Differences between Capability Maturity Model(CMM) and Capability Maturity Model Integration(CMMI)

Capability Maturity Model (CMM)

The Capability Maturity Model for Software (CMM) is a framework that describes the key elements of an effective software process. There are CMMs for non software processes as well, such as Business Process Management (BPM).
- The CMM describes an evolutionary improvement path from an ad hoc, immature process to a mature, disciplined process.
- The CMM covers practices for planning, engineering, and managing software development and maintenance.
- When followed, these key practices improve the ability of organizations to meet goals for cost, schedule, functionality, and product quality.
- The CMM establishes a yardstick against which it is possible to judge, in a repeatable way, the maturity of an organization's software process and compare it to the state of the practice of the industry.
- The CMM can also be used by an organization to plan improvements to its software process.
- It also reflects the needs of individuals performing software process, improvement, software process assessments, or software capability evaluations; is documented; and is publicly available.

Capability Maturity Model Integration (CMMI)
- CMMI is a process improvement approach that provides organizations with the essential elements of effective processes.
- It can be used to guide process improvement across a project, a division, or an entire organization.
- CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.

Misconceptions of the Capability Maturity Model (CMM)

CMM is the most widely used Software Process Improvement model. It was developed by Carnegie Mellon University’s Software Engineering Institute (SEI). A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level provides a layer in the foundation for continuous process improvement.
In CMMI models with a staged representation, there are five maturity levels designated by the numbers 1 through 5.
- Initial
- Managed/Repeatable
- Defined
- Quantitatively Managed
- Optimizing

Misconceptions About Maturity Levels
- If you are at Level 1, you are pond scum.
Being Level 1 does not mean that the members of a software organization are barely breathing. It does mean that the organization's projects are likely to have less predictability, more rework, more defects, and more schedule slippage than those in a higher maturity organization.
- Level 2 is mostly about software engineering activities, such as requirements analysis, design, coding, and testing.
- You have to perform all of the activities and practices defined at some maturity level in order to achieve that level.
- Software measurement is not required until you are approaching Level 4.
- The SEI certifies an organization at a specific maturity level.
- The CMM requires that you use specific software development practices, tools, and methodologies.
- The CMM mandates a waterfall life cycle model.
- The Software Quality Assurance KPA is mostly about testing.
- The CMM requires that you perform software inspections to achieve Level 3.
- Having a "tailorable" process really means that you can do whatever you want.
- Requirements management is the same thing as requirements engineering.
- You cannot work on improving KPAs more than one maturity level higher than your current level.
- The CMM mandates bureaucracy and wasteful paperwork.
- The CMM is a quick fix for short-term problems.
- CMMI is proprietary for the US military use.
- CMMI is the next release of CMM.
- Everyone uses the Staged Representation.
- You cannot use CMMI if you already use some other improvement model.
- CMMI is not suitable for small organizations.
- CMMI is used only to get an appraisal rating.
- CMMI is not suitable for companies using Agile methods.
- CMMI implementation takes long and is expensive and does not pay off.
- CMMI is a process model.

Imperative Programming and differences between Imperative and Functional Programming

Imperative programming is characterized by programming with a state and commands which modify the state.
- Imperative: a command or order.
- Procedure: the act, method or manner of proceeding in some process or course of action a particular course of action or way of doing something.
When imperative programming is combined with subprograms it is called procedural programming.

The imperative programming paradigm is an abstraction of real computers which in turn are based on the Turing machine and the Von Neumann machine with its registers and store (memory). At the heart of these machines is the concept of a modifiable store. Variables and assignments are the programming language analog of the modifiable store. The store is the object that is manipulated by the program. Imperative programming languages provide a variety of commands to provide structure to code and to manipulate the store.
In imperative programming, a name may be assigned to a value and later reassigned to another value. The collection of names and the associated values and the location of control in the program constitute the state. The state is a logical model of storage which is an association between memory locations and values.

Characteristic : Programmer focus
- Imperative approach: How to perform tasks (algorithms) and how to track changes in state.
- Functional approach: What information is desired and what transformations are required.
Characteristic : State changes
- Imperative approach: Important.
- Functional approach: Non-existent.
Characteristic : Order of execution
- Imperative approach: Important.
- Functional approach: Low priority.
Characteristic : Primary flow control
- Imperative approach: Loops, conditionals, and function (method) calls.
- Functional approach: Function calls, including recursion.
Characteristic : Primary manipulation unit
- Imperative approach: Instances of structures or classes.
- Functional approach: Functions as first-class objects and data collections.

Test Automation Framework: What is the Hybrid Test Automation Framework

In previous articles, we learned about the following Automation frameworks:
- Data Driven Testing (link)
- Test Library Architecture Framework (link)
- Keyword-driven/table-driven testing (link)
- Test script modularity (link)
This post covers the 5th such test automation framework, called Hybrid Test Automation Framework. Just like the name suggests, this is what people would ask for, why can't you combine the benefits and strong points of the above test automation frameworks and try to remove their weaknesses, and that is what you get. This is called the Hybrid Test Automation Framework. It is one of the most successful automation frameworks, and is also one of the frameworks that other frameworks eventually mature into.
So, since the keyword driven architecture has some powerful benefits in the form of libraries and utilities, this framework allows the data driven scripts to take advantage of these libraries and utilities; and also make these data driven scripts smaller and reduce the risk of their failure. This framework has many utilities that allow the conversion of currently used scripts into the equivalent of keyword driven (when needed).
Some of the properties of the Hybrid Test Automation Framework are: Core Data Driven Engine, the Component Functions, the Support Libraries, and the Application Map (App Map).

Think aloud Protocol - popular technique used during usability testing

The Think Aloud Method consists of asking people to think aloud while solving a
problem and analyzing the resulting verbal protocols.
Think Aloud (TA) studies provide rich verbal data about reasoning during a problem solving task. Using TA and protocol analysis, investigators can identify the information that is concentrated on during problem solving and how that information is used to facilitate problem resolution. From this, inferences can be made about the reasoning processes that were used during the problem-solving task. In the past, the validity of data obtained from TA studies has been suspect because of inconsistencies in data collection and the inability to verify findings obtained from the slow, laborious process of protocol analysis.

Think-aloud protocols are of particular value because they focus on the problems a user has; when the user is working without difficulty, direct observation is of very limited use. Use this technique in any stage of development. Thinking aloud is a cheap way of getting a lot of good qualitative feedback during testing.
Main advantages of this method are :
- High degree of flexibility.
- Presence of two people allows meaningful, direct dialog.
- Rapid, high-quality, qualitative user feedback.

How do I do Thinking aloud Protocol?
Provide your participant with the product to be tested (or a prototype of its interface) and a scenario of tasks to perform. Ask participants to perform the tasks using the product, and explain what they're thinking about while working with the product's interface.
Thinking aloud allows you to understand how the user approaches the interface and what considerations the user keeps in mind when using the interface. If the user expresses that the sequence of steps dictated by the product to accomplish their task goal is different from what they expected, perhaps the interface is convoluted.

Although the main benefit of the thinking aloud protocol is a better understanding of the user's mental model and interaction with the product, you can gain other benefits as well. For example, the terminology the user uses to express an idea or function should be incorporated into the product design or at least its documentation.

Verification (VER) Process Area in Capability Maturity Model (CMMi)

An Engineering Process Area at Maturity Level 3. The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.
Verification includes verification of the product and intermediate work products against all selected requirements, including customer, product, and product component requirements. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.

Verification is inherently an incremental process because it occurs throughout the development of the product and work products, beginning with verification of the requirements, progressing through the verification of the evolving work products, and culminating in the verification of the completed product.

Specific Practices by Goal

SG 1 Prepare for Verification
Up-front preparation is necessary to ensure that verification provisions are embedded in product and product component requirements, designs, developmental plans, and schedules. Verification includes selection, inspection, testing, analysis, and demonstration of work products. Methods of verification include, but are not limited to, inspections, peer reviews, audits, walkthroughs, analyses, simulations, testing, and demonstrations.
- SP 1.1 Select Work Products for Verification.
The work products to be verified may include those associated with maintenance, training, and support services. The work product requirements for verification are included with the verification methods.
- SP 1.2 Establish the Verification Environment.
An environment must be established to enable verification to take place. The verification environment can be acquired, developed, reused, modified, or a combination of these, depending on the needs of the project. The type of environment required will depend on the work products selected for verification and the verification methods used.
- SP 1.3 Establish Verification Procedures and Criteria.
The verification procedures and criteria should be developed concurrently and iteratively with the product and product component designs. Verification criteria are defined to ensure that the work products meet their requirements.

SG 2 Perform Peer Reviews
Peer reviews involve a methodical examination of work products by the producers peers to identify defects for removal and to recommend other changes that are needed. The peer review is an important and effective verification method implemented via inspections, structured walkthroughs, or a number of other collegial review methods.
- SP 2.1 Prepare for Peer Reviews.
Preparation activities for peer reviews typically include identifying the staff who will be invited to participate in the peer review of each work product; identifying the key reviewers who must participate in the peer review; preparing and updating any materials that will be used during the peer reviews, such as checklists and review criteria, and scheduling peer reviews.
- SP 2.2 Conduct Peer Reviews.
One of the purposes of conducting a peer review is to find and remove defects early. Peer reviews are performed incrementally as work products are being developed. These reviews are structured and are not management reviews. Peer reviews may be performed on key work products of specification, design, test, and implementation activities and specific planning work products.
- SP 2.3 Analyze Peer Review Data.
Analyze data about preparation, conduct, and results of the peer reviews.

SG 3 Verify Selected Work Products
The verification methods, procedures, and criteria are used to verify the selected work products and any associated maintenance, training, and support services using the appropriate verification environment.
- SP 3.1 Perform Verification.
Verifying products and work products incrementally promotes early detection of problems and can result in the early removal of defects. The results of verification save considerable cost of fault isolation and rework associated with troubleshooting problems.
- SP 3.2 Analyze Verification Results.
Analyze the results of all verification activities. Actual results must be compared to established verification criteria to determine acceptability. The results of the analysis are recorded as evidence that verification was conducted.

Validation (VAL) Process Area in Capability Maturity Model (CMMi)

An Engineering process area at Maturity Level 3. The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment. Validation activities can be applied to all aspects of the product in any of its intended environments, such as operation, training, manufacturing, maintenance, and support services. The methods employed to accomplish validation can be applied to work products as well as to the product and product components.
The validation environment should represent the intended environment for the product and product components as well as represent the intended environment suitable for validation activities with work products.
Validation demonstrates that the product, as provided, will fulfill its intended use; whereas, verification addresses whether the work product properly reflects the specified requirements. Whenever possible, validation should be accomplished using the product or product component operating in its intended environment. The entire environment can be used or only part of it.

Specific Practices by Goal

SG 1 Prepare for Validation
Preparation activities include selecting products and product components for validation and establishing and maintaining the validation environment, procedures, and criteria. The items selected for validation may include only the product or it may include appropriate levels of the product components that are used to build the product.
- SP 1.1 Select Products for Validation.
Products and product components are selected for validation on the basis of their relationship to user needs. For each product component, the scope of the validation (e.g., operational behavior, maintenance, training, and user interface) should be determined.
- SP 1.2 Establish the Validation Environment.
The requirements for the validation environment are driven by the product or product components selected, by the type of the work products (e.g., design, prototype, and final version), and by the methods of validation. These may yield requirements for the purchase or development of equipment, software, or other resources. These requirements are provided to the requirements development processes for development. The validation environment may include the reuse of existing resources.
- SP 1.3 Establish Validation Procedures and Criteria.
Validation procedures and criteria are defined to ensure that the product or product component will fulfill its intended use when placed in its intended environment. Acceptance test cases and procedures may meet the need for validation procedures.
The validation procedures and criteria include test and evaluation of maintenance, training, and support services.

SG 2 Validate Product or Product Components
The product or product components are validated to ensure that they are suitable for use in their intended operating environment. The validation methods, procedures, and criteria are used to validate the selected products and product components and any associated maintenance, training, and support services using the appropriate validation environment. Validation activities are performed throughout the product lifecycle.
- SP 2.1 Perform Validation.
Perform validation on the selected products and product components. To be acceptable to users, a product or product component must perform as expected in its intended operational environment. Validation activities are performed and the resulting data are collected according to the established methods, procedures, and criteria.
- SP 2.2 Analyze Validation Results.
The data resulting from validation tests, inspections, demonstrations, or evaluations are analyzed against the defined validation criteria. Analysis reports indicate whether the needs were met; in the case of deficiencies, these reports document the degree of success or failure and categorize probable cause of failure. The collected test, inspection, or review results are compared with established evaluation criteria to determine whether to proceed or to address requirements or design issues in the requirements development or technical solution processes.

Technical Solution (TS) Process Area in Capability Maturity Models (CMM)

The purpose of Technical Solution (TS) 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 combination as appropriate. It is an Engineering process area at Maturity Level 3.
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.

Technical Solution specific practices apply not only to the product and product components but also to product-related lifecycle processes. Processes associated with the Technical Solution process area receive the product and product component requirements from the requirements management processes.

Specific Practices by Goal

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.
- SP 1.1 Develop Alternative Solutions and Selection Criteria.
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 lifecycle processes (e.g., manufacturing, support, training, verification, and disposal).
- SP 1.2 Select Product Component Solutions.
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.

SG 2 Develop the Design
Product or product component designs must provide the appropriate content not only for implementation, but also for other phases of the product lifecycle such as modification, procurement, 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 lifecycle.
- SP 2.1 Design the Product or Product Component.
Product design consists of two broad phases that may overlap in execution: preliminary and detailed design.
- SP 2.2 Establish 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.
- SP 2.3 Design Interfaces Using Criteria.
Design product component interfaces using established criteria. The criteria for interfaces frequently reflect 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 service) and are often associated with safety, security, durability, and mission-critical characteristics.
- SP 2.4 Perform Make, Buy, or Reuse Analysis.
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.

SG 3 Implement the Product Design
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 end-user documentation.
- SP 3.1 Implement the Design.
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.
- 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.

Supplier Agreement Management (SAM) Process Area in CMMi

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers. It is a Project Management process area at Maturity Level 2.
The Supplier Agreement Management process area involves the following:
- Determining the type of acquisition that will be used for the products to be acquired.
- Selecting suppliers.
- Establishing and maintaining agreements with suppliers.
- Executing the supplier agreement.
- Monitoring selected supplier processes.
- Evaluating selected supplier work products.
- Accepting delivery of acquired products.
- Transitioning acquired products to the project.

Suppliers may take many forms depending on business needs, including in-house vendors (i.e., vendors that are in the same organization but are external to the project), fabrication capabilities and laboratories, and commercial vendors. A formal agreement is established to manage the relationship between the organization and the supplier. A formal agreement is any legal agreement between the organization (representing the project) and the supplier.

Specific Practices by Goal

SG 1 Establish Supplier Agreements
Agreements with the suppliers are established and maintained.
- SP 1.1 Determine Acquisition Type.
Determine the type of acquisition for each product or product component to be acquired. There are many different types of acquisition that can be used to acquire products and product components that will be used by the project.
- SP 1.2 Select Suppliers.
Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria. Criteria should be established to address factors that are important to the project.Examples of factors include geographical location of the supplier, supplier’s performance records on similar work, engineering capabilities, staff and facilities available to perform the work and prior experience in similar applications.
- SP 1.3 Establish Supplier Agreements.
When integrated teams are formed, team membership should be negotiated with suppliers and incorporated into the agreement. The agreement should identify any integrated decision making, reporting requirements (business and technical), and trade studies requiring supplier involvement.

SG 2 Satisfy Supplier Agreements
Agreements with the suppliers are satisfied by both the project and the supplier.
- SP 2.1 Execute the Supplier Agreement.
Perform activities with the supplier as specified in the supplier agreement. Typical work products are supplier progress reports and performance measures, supplier review materials and reports, action items tracked to closure and documentation of product and document deliveries.
- SP 2.2 Monitor Selected Supplier Processes.
Select, monitor, and analyze processes used by the supplier. The selection must consider the impact of the supplier's processes on the project. On larger projects with significant subcontracts for development of critical components, monitoring of key processes is expected. For most vendor agreements where a product is not being developed or for smaller, less critical components, the selection process may determine that monitoring is not appropriate. Between these extremes, the overall risk should be considered in selecting processes to be monitored.
- SP 2.3 Evaluate Selected Supplier Work Products.
The scope of this specific practice is limited to suppliers providing the project with custom-made products, particularly those that present some risk to the program due to complexity or criticality. The intent of this specific practice is to evaluate selected work products produced by the supplier to help detect issues as early as possible that may affect the supplier's ability to satisfy the requirements of the agreement.
- SP 2.4 Accept the Acquired Product.
Ensure that the supplier agreement is satisfied before accepting the acquired product. Acceptance reviews and tests and configuration audits should be completed before accepting the product as defined in the supplier agreement.
- SP 2.5 Transition Products.
Transition the acquired products from the supplier to the project. Before the acquired product is transferred to the project for integration, appropriate planning and evaluation should occur to ensure a smooth transition.

Risk Management (RSKM) Process Area in CMMi

It is a Project Management process area at Maturity Level 3. The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.
Risk management is a continuous, forward-looking process that is an important part of management. Risk management should address issues that could endanger achievement of critical objectives. A continuous risk management approach is applied to effectively anticipate and mitigate the risks that may have a critical impact on the project.
Effective risk management includes early and aggressive risk identification through the collaboration and involvement of relevant stakeholders, as described in the stakeholder involvement plan addressed in the Project Planning process area. Risk management must consider both internal and external sources for cost, schedule, and performance risk as well as other risks.

Specific Practices by Goal

SG 1 Prepare for Risk Management
Preparation is conducted by establishing and maintaining a strategy for identifying, analyzing, and mitigating risks. This is typically documented in a risk management plan. The risk management strategy addresses the specific actions and management approach used to apply and control the risk management program.
- SP 1.1 Determine Risk Sources and Categories.
Identification of risk sources provides a basis for systematically examining changing situations over time to uncover circumstances that impact the ability of the project to meet its objectives. Risk sources are both internal and external to the project.
- SP 1.2 Define Risk Parameters.
Parameters for evaluating, categorizing, and prioritizing risks include risk likelihood (i.e., probability of risk occurrence), risk consequence (i.e., impact and severity of risk occurrence), thresholds to trigger management activities.
- SP 1.3 Establish a Risk Management Strategy.
A comprehensive risk management strategy addresses items such as the following:
. The scope of the risk management effort.
. Methods and tools to be used for risk identification, risk analysis, risk mitigation, risk monitoring, and communication.
. Project-specific sources of risks.
. How these risks are to be organized, categorized, compared, and consolidated.
. Parameters, including likelihood, consequence, and thresholds, for taking action on identified risks.
. Risk mitigation techniques to be used, such as prototyping, piloting, simulation, alternative designs, or evolutionary development.
. Definition of risk measures to monitor the status of the risks.
. Time intervals for risk monitoring or reassessment.

SG 2 Identify and Analyze Risks
The degree of risk impacts the resources assigned to handle an identified risk and the determination of when appropriate management attention is required.
- SP 2.1 Identify Risks.
The identification of potential issues, hazards, threats, and vulnerabilities that could negatively affect work efforts or plans is the basis for sound and successful risk management.
- SP 2.2 Evaluate, Categorize, and Prioritize Risks.
The evaluation of risks is needed to assign relative importance to each identified risk, and is used in determining when appropriate management attention is required.

SG 3 Mitigate Risks
The steps in handling risks include developing risk-handling options, monitoring risks, and performing risk-handling activities when defined thresholds are exceeded.
- SP 3.1 Develop Risk Mitigation Plans.
A critical component of a risk mitigation plan is to develop alternative courses of action, workarounds, and fallback positions, with a recommended course of action for each critical risk. The risk mitigation plan for a given risk includes techniques and methods used to avoid, reduce, and control the probability of occurrence of the risk, the extent of damage incurred should the risk occur (sometimes called a “contingency plan”), or both.
- SP 3.2 Implement Risk Mitigation Plans.
To effectively control and manage risks during the work effort, follow a proactive program to regularly monitor risks and the status and results of risk-handling actions. The risk management strategy defines the intervals at which the risk status should be revisited.

Requirements Management (REQM) Process Area in CMMi

The purpose of Requirements Management (REQM) is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products. It is an Engineering process area at Maturity Level 2.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.

REQM vs.RD

- REQM is about managing the set of requirements and keeping it consistent with the project’s plans whereas RD is about developing the requirements in a systematic way.
- REQM is a Maturity Level 2 process area whereas RD is a Maturity Level 3 process area.

Specific Practices by Goal

SG 1 Manage Requirements
The project maintains a current and approved set of requirements over the life of the project by managing all changes to the requirements, maintaining the relationships among the requirements, the project plans, and the work products, identifying inconsistencies among the requirements, the project plans, and the work products and taking corrective action.
- SP 1.1 Obtain an Understanding of Requirements.
The intent of this SP is to establish a criteria for the project to identify appropriate requirements providers, criteria for the evaluationand acceptance of requirements, and ensure through an analysis or reviewprocess that the established criteria are met.
- SP 1.2 Obtain Commitment to Requirements.
Once the understanding of the requirement is established through the SP1.1, this SP deals with agreements and commitmentsamong those who have to carry out the activities necessary to implement the requirements.
- SP 1.3 Manage Requirements Changes.
Once commitments to the requirements are established and plans have been made. The project will transform from planning mode to execution mode. During the project execution phase, changes to requirements may occur for a variety of reasons. As needs change and as work proceeds, additional requirements are derived and changes may have to be made to the existing requirements.
- SP 1.4 Maintain Bidirectional Traceability of Requirements.
he intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.
- SP 1.5 Identify Inconsistencies between Project Work and Requirements.
This SP focuses on maintaining consistency between requirements and project plans. I.e. the project plan should be revised, if changes to the requirements are identified to be impacting the schedule.

Requirements Development (RD) Process Area in CMMi

he purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements. An Engineering process area at Maturity Level 3.
This process area describes three types of requirements: customer requirements, product requirements, and product component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, and maintainability).
This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.
Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product component requirements are derived from the selected design solutions.

Specific Goals and Practices

SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders are the basis for determining customer requirements. The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
- SP 1.1 Elicit Needs.
Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product lifecycle activities and their impact on the product.
- SP 1.2 Develop the Customer Requirements.
Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. The various inputs from the relevant stakeholders must be consolidated, missing information must be obtained, and conflicts must be resolved in documenting the recognized set of customer requirements. The customer requirements may include needs, expectations, and constraints with regard to verification and validation.

SG 2 Develop Product Requirements
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “product and product component requirements.” Product and product component requirements address the needs associated with each product lifecycle phase.
- SP 2.1 Establish Product and Product-Component Requirements.
The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions.
- SP 2.2 Allocate Product-Component Requirements.
Allocate the requirements for each product component. The requirements for product components of the defined solution include allocation of product performance; design constraints; and fit, form, and function to meet requirements and facilitate production.
- SP 2.3 Identify Interface Requirements.
Interfaces between functions (or between objects) are identified. Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.

SG 3 Analyze and Validate Requirements
The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment.
- SP 3.1 Establish Operational Concepts and Scenarios.
A scenario is typically a sequence of events that might occur in the use of the product, which is used to make explicit some of the needs of the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario.
- SP 3.2 Establish a Definition of Required Functionality.
The definition of functionality, also referred to as “functional analysis,” is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
- SP 3.3 Analyze Requirements.
Analyze requirements to ensure that they are necessary and sufficient.
- SP 3.4 Analyze Requirements to Achieve Balance.
Analyze requirements to balance stakeholder needs and constraints. Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.
- SP 3.5 Validate Requirements.
Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

Quantitative Project Management (QPM) Process Area in CMMi

The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives. A Project Management process area at Maturity Level 4.
The Quantitative Project Management process area involves the following:
- Establishing and maintaining the project’s quality and process-performance objectives.
- Identifying suitable subprocesses that compose the project’s defined process based on historical stability and capability data found in process-performance baselines or models.
- Selecting the subprocesses of the project’s defined process to be statistically managed.
- Monitoring the project to determine whether the project’s objectives for quality and process performance are being satisfied, and identifying appropriate corrective action.
- Selecting the measures and analytic techniques to be used in statistically managing the selected subprocesses.
- Establishing and maintaining an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques.
- Monitoring the performance of the selected subprocesses to determine whether they are capable of satisfying their quality and process-performance objectives, and identifying corrective action.
- Recording statistical and quality management data in the organization’s measurement repository.

Specific Goals and Practices

SG 1 Quantitatively Manage the Project

The project is quantitatively managed using quality and process-performance objectives.
- SP 1.1 Establish the Project's Objectives.
When establishing the project’s quality and process-performance objectives, it is often useful to think ahead about which processes from the organization’s set of standard processes will be included in the project’s defined process, and what the historical data indicates regarding their process performance.
- SP 1.2 Compose the Defined Processes.
Select the subprocesses that compose the project’s defined process based on historical stability and capability data. Subprocesses are identified from the process elements in the organization’s set of standard processes and the process artifacts in the organization’s process asset library.
- SP 1.3 Select the Subprocesses that will be statistically managed.
Selecting the subprocesses to be statistically managed is often a concurrent and iterative process of identifying applicable project and organization quality and process-performance objectives, selecting the subprocesses, and identifying the process and product attributes to measure and control.
- SP 1.4 Manage Project Performance.
A prerequisite for such a comparison is that the selected subprocesses of the project’s defined process are being statistically managed and their process capability is understood. The specific practices of specific goal 2 provide detail on statistically managing the selected subprocesses.

SG 2 Statistically Manage Subprocess Performance
The performance of selected subprocesses within the project's defined process is statistically managed. This specific goal describes an activity critical to achieving the Quantitatively Manage the Project specific goal of this process area.
- SP 2.1 Select Measures and Analytic Techniques.
Select the measures and analytic techniques to be used in statistically managing the selected subprocesses.
- SP 2.2 Apply Statistical Methods to Understand Variation.
Establish and maintain an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques. Understanding variation is achieved, in part, by collecting and analyzing process and product measures so that special causes of variation can be identified and addressed to achieve predictable performance.
- SP 2.3 Monitor Performance of the Selected Subprocesses.
Monitor the performance of the selected subprocesses to determine their capability to satisfy their quality and process-performance objectives, and identify corrective action as necessary.
- SP 2.4 Record Statistical Management Data.
Record statistical and quality management data in the organization’s measurement repository.

Process and Product Quality Assurance (PPQA) Process Area in CMMi

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products. A Support Process Area at Maturity Level 2.
The Process and Product Quality Assurance process area involves the following activities :

- Objectively evaluating performed processes, work products, and services against applicable process descriptions, standards, and procedures.
- Identifying and documenting noncompliance issues.
- Providing feedback to project staff and managers on the results of quality assurance activities.
- Ensuring that noncompliance issues are addressed.
The Process and Product Quality Assurance process area supports the delivery of high-quality products and services by providing project staff and managers at all levels with appropriate visibility into, and feedback on, processes and associated work products throughout the life of the project.

Specific Goals and Practices

SG 1 Objectively Evaluate Processes and Work Products
Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.
- SP 1.1 Objectively Evaluate Processes.
Objectively evaluate the designated performed processes against the applicable process descriptions, standards, and procedures. Objectivity in quality assurance evaluations is critical to the success of the project. A description of the quality assurance reporting chain and how it ensures objectivity should be defined.
- SP 1.2 Objectively Evaluate Work Products and Services.
Objectively evaluate the designated work products and services against the applicable process descriptions, standards, and procedures. The intent of this subpractice is to provide criteria, based on business needs, such as the following:
. What will be evaluated during the evaluation of a work product?
. When or how often a work product will be evaluated?
. How the evaluation will be conducted?
. Who must be involved in the evaluation?

SG 2 Provide Objective Insight
Noncompliance issues are objectively tracked and communicated, and resolution is ensured.
- SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues.
Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers. Noncompliance issues are problems identified in evaluations that reflect a lack of adherence to applicable standards, process descriptions, or procedures. The status of noncompliance issues provides an indication of quality trends. Quality issues include noncompliance issues and results of trend analysis.
When local resolution of noncompliance issues cannot be obtained, use established escalation mechanisms to ensure that the appropriate level of management can resolve the issue. Track noncompliance issues to resolution.
- SP 2.2 Establish Records.
Establish and maintain records of the quality assurance activities. Typical Work Products are evaluation logs, quality assurance reports, status reports of corrective actions and reports of quality trends.

Project Planning (PP) Process area in CMMi

A Project Management Process Area at Maturity Level 2. The purpose of Project Planning (PP) is to establish and maintain plans that define project activities. Planning begins with requirements that define the product and project.
Planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks. Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling the project’s activities that address the commitments with the project’s customer.
The project plan will usually need to be revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and re-planning are contained in this process area.

Specific Goals and Practices

SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained. Estimates of planning parameters should have a sound basis to instill confidence that any plans based on these estimates are capable of supporting project objectives.
- SP 1.1 Estimate the Scope of the Project.
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. The WBS evolves with the project. Initially a top-level WBS can serve to structure the initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components. Typically, the WBS is a product oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called “work packages.”
- SP 1.2 Establish Estimates of Work Product and Task Attributes.
Establish and maintain estimates of the attributes of the work products and tasks.
Size is the primary input to many models used to estimate effort, cost, and schedule. The models can also be based on inputs such as connectivity, complexity, and structure.
- SP 1.3 Define Project Life Cycle.
The determination of a project’s lifecycle phases provides for planned periods of evaluation and decision making. These are normally defined to support logical decision points at which significant commitments are made concerning resources and technical approach. Such points provide planned events at which project course corrections and determinations of future scope and cost can be made.
- SP 1.4 Determine Estimates of Effort and Cost.
Estimates of effort and cost are generally based on the results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on the rationale for the selected model and the nature of the data. There may be occasions when the available historical data does not apply, such as where efforts are unprecedented or where the type of task does not fit available models.

SG 2 Develop a Project Plan
A project plan is established and maintained as the basis for managing the project.
A project plan is a formal, approved document used to manage and control the execution of the project. It is based on the project requirements and the established estimates.
- SP 2.1 Establish the Budget and Schedule.
The project’s budget and schedule are based on the developed estimates and ensure that budget allocation, task complexity, and task dependencies are appropriately addressed.
- SP 2.2 Identify Project Risks.
Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all the plans that affect the project to ensure that the appropriate interfacing is taking place between all relevant stakeholders on identified risks. Project planning risk identification and analysis typically include identifying risks, analyzing the risks to determine the impact, probability of occurrence, and time frame in which problems are likely to occur
and prioritizing risks.
- SP 2.3 Plan for Data Management.
When integrated teams are formed, project data includes data developed and used solely within a particular team as well as data applicable across integrated team boundaries, if there are multiple integrated teams.
- SP 2.4 Plan for Project Resources.
Defining project resources (labor, machinery/equipment, materials, and methods) and quantities needed to perform project activities builds on the initial estimates and provides additional information that can be applied to expand the WBS used to manage the project.
- SP 2.5 Plan for Needed Knowledge and Skills.
Plan for knowledge and skills needed to perform the project. Knowledge delivery to projects involves both training of project personnel and acquisition of knowledge from outside sources. Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.
- SP 2.6 Plan Stakeholder Involvement.
Stakeholders are identified from all phases of the project lifecycle by identifying the type of people and functions needing representation in the project and describing their relevance and the degree of interaction for specific project activities.
- SP 2.7 Establish the Project Plan.
A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the plans. The plan generated for the project defines all aspects of the effort, tying together in a logical manner.

SG 3 Obtain Commitment to the Plan
Commitments to the project plan are established and maintained. To be effective, plans require commitment by those responsible for implementing and supporting the plan.
- SP 3.1 Review Plans that Affect the Project.
Plans developed within other process areas will typically contain information similar to that called for in the overall project plan. These plans may provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control.
- SP 3.2 Reconcile Work and Resource Levels.
When integrated teams are formed, special attention should be paid to resource commitments in circumstances of distributed integrated teams and when people are on multiple integrated teams in one or more projects.
- SP 3.3 Obtain Plan Commitment.
Obtaining commitment involves interaction among all relevant stakeholders both internal and external to the project. The individual or group making a commitment should have confidence that the work can be performed within cost, schedule, and performance constraints.

Project Monitoring and Control (PMC) Process Area in CMMi

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. A Project Management Process Area at Maturity Level 2.
A project’s documented plan is the basis for monitoring activities, communicating status, and taking corrective action. Progress is primarily determined by comparing actual work product and task attributes, effort, cost, and schedule to the plan at prescribed milestones or control levels in the project schedule or WBS. Appropriate visibility of progress enables timely corrective action to be taken when performance deviates significantly from the plan. A deviation is significant if, when left unresolved, it precludes the project from meeting its objectives.

Specific Goals and Practices

SG 1 Monitor Project Against Plan
- SP 1.1 Monitor Project Planning Parameters.
Monitor the actual values of the project planning parameters against the project plan. Monitoring typically involves measuring the actual values of project planning parameters, comparing actual values to the estimates in the plan, and identifying significant deviations. Recording actual values of the project planning parameters includes recording associated contextual information to help understand the measures.
- SP 1.2 Monitor Commitments.
Monitor commitments against those identified in the project plan.
- SP 1.3 Monitor Project Risks.
Monitor risks against those identified in the project plan.
- SP 1.4 Monitor Data Management.
Monitor the management of project data against the project plan. Once the plans for the management of project data are made, the management of that data must be monitored to ensure that those plans are accomplished.
- SP 1.5 Monitor Stakeholder Involvement.
Once the stakeholders are identified and the extent of their involvement within the project is specified in project planning, that involvement must be monitored to ensure that the appropriate interactions are occurring.
- SP 1.6 Conduct Progress Reviews.
Periodically review the project's progress, performance, and issues. Progress reviews are reviews on the project to keep stakeholders informed. These project reviews can be informal reviews and may not be specified explicitly in the project plans.
- SP 1.7 Conduct Milestone Reviews.
Review the accomplishments and results of the project at selected project milestones.
Milestone reviews are planned during project planning and are typically formal reviews.

SG 2 Manage Corrective Action to Closure
Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan. Many product integration problems arise from unknown or uncontrolled aspects of both internal and external interfaces. Effective management of product component interface requirements, specifications, and designs helps ensure that implemented interfaces will be complete and compatible.
- SP 2.1 Analyze Issues.
Collect and analyze the issues and determine the corrective actions necessary to address the issues.
- SP 2.2 Take Corrective Action.
Take corrective action on identified issues. Examples of potential actions include modifying the statement of work, modifying requirements, revising estimates and plans, renegotiating commitments, adding resources, changing processes, revising project risks .
- SP 2.3 Manage Corrective Action.
Manage corrective actions to closure. Lessons learned as a result of taking corrective action can be inputs to planning and risk management processes.

Product Integration (PI) Process Area in CMMi

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product. An Engineering process area at Maturity Level 3.

The scope of this process area is to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration sequence and procedures. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.

Specific Practices by Goal

SG 1 Prepare for Product Integration
Preparing for integration of product components involves establishing and maintaining an integration sequence, the environment for performing the integration, and integration procedures. The specific practices of the Prepare for Product Integration specific goal build on each other in the following way.
- SP 1.1 Determine Integration Sequence.
. The product components that are integrated may include those that are a part of the product to be delivered along with test equipment, test software, or other integration items such as fixtures. Once you have analyzed alternative test and assembly integration sequences, select the best integration sequence.

- SP 1.2 Establish the Product Integration Environment.
The environment for product integration can either be acquired or developed. To establish an environment, requirements for the purchase or development of equipment, software, or other resources will need to be developed.

- SP 1.3 Establish Product Integration Procedures and Criteria.
Procedures for the integration of the product components can include such things as the number of incremental iterations to be performed and details of the expected tests and other evaluations to be carried out at each stage.

SG 2 Ensure Interface Compatibility
Many product integration problems arise from unknown or uncontrolled aspects of both internal and external interfaces. Effective management of product component interface requirements, specifications, and designs helps ensure that implemented interfaces will be complete and compatible.

- SP 2.1 Review Interface Descriptions for Completeness.
The interfaces should include, in addition to product component interfaces, all the interfaces with the product integration environment.

- SP 2.2 Manage Interfaces.
Interface requirements drive the development of the interfaces necessary to integrate product components. Managing product and product component interfaces starts very early in the development of the product. The definitions and designs for interfaces affect not only the product components and external systems, but can also affect the verification and validation environments.

SG 3 Assemble Product Components and Deliver the Product
ntegration of product components proceeds according to the product integration sequence and available procedures. Before integration, each product component should be confirmed to be compliant with its interface requirements. This process continues until product integration is complete. If, during this process, problems are identified, the problem should be documented and a corrective action process initiated.

- SP 3.1 Confirm Readiness of Product Components for Integration.
Confirm, prior to assembly, that each product component required to assemble the product has been properly identified, functions according to its description, and that the product component interfaces comply with the interface descriptions.

- SP 3.2 Assemble Product Components.
The assembly activities of this specific practice and the evaluation activities of the next specific practice are conducted iteratively, from the initial product components, through the interim assemblies of product components, to the product as a whole.

- SP 3.3 Evaluate Assembled Product Components.
This evaluation involves examining and testing assembled product components for performance, suitability, or readiness using the available procedures and environment. It is performed as appropriate for different stages of assembly of product components as identified in the product integration sequence and available procedures. The product integration sequence and available procedures may define a more refined integration and evaluation sequence than might be envisioned just by examining the product architecture.

- SP 3.4 Package and Deliver the Product or Product Component.
The packaging requirements for some products can be addressed in their specifications and verification criteria. This is especially important when items are stored and transported by the customer. In such cases, there may be a spectrum of environmental and stress conditions specified for the package.

Organizational Training (OT) Process Area in CMMi

The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently. Organizational Training includes training to support the organization’s strategic business objectives and to meet the tactical training needs that are common across projects and support groups. Specific training needs identified by individual projects and support groups are handled at the project and support group level and are outside the scope of Organizational Training.

Specific Practices by Goal

SG 1 Establish an Organizational Training Capability
- SP 1.1 Establish the Strategic Training Needs.
Strategic training needs address long-term objectives to build a capability by filling significant knowledge gaps, introducing new technologies, or implementing major changes in behavior. Strategic planning typically looks two to five years into the future. Examples of sources of strategic training needs include the following:
. Organization’s standard processes.
. Organization’s strategic business plan.
. Organization’s process improvement plan.
. Enterprise-level initiatives.
. Skill assessments.
. Risk analyses.

- SP 1.2 Determine Which Training Needs Are the Responsibility of the Organization.
In addition to strategic training needs, organizational training addresses training requirements that are common across projects and support groups. Projects and support groups have the primary responsibility for identifying and addressing their specific training needs. The organization’s training staff is only responsible for addressing common cross-project and support group training needs.

- SP 1.3 Establish an Organizational Training Tactical Plan.
The organizational training tactical plan is the plan to deliver the training that is the responsibility of the organization and is necessary for individuals to perform their roles effectively. This plan addresses the near-term execution of training and is adjusted periodically in response to changes (e.g., in needs or resources) and to evaluations of effectiveness.

- SP 1.4 Establish Training Capability.
Establish and maintain training capability to address organizational training needs.
Refer to the Decision Analysis and Resolution process area for how to apply decision-making criteria when selecting training approaches and developing training materials.
Examples of training approaches include the following:
. Classroom training.
. Computer-aided instruction.
. Guided self-study.
. Formal apprenticeship and mentoring programs.
. Facilitated videos.
. Chalk talks.
. Brown-bag lunch seminars.
. Structured on-the-job training.

SG 2 Provide Necessary Training
- SP 2.1 Deliver Training.
Training is intended to impart knowledge and skills to people performing various roles within the organization. Some people already possess the knowledge and skills required to perform well in their designated roles. Training can be waived for these people, but care should be taken that training waivers are not abused.

- SP 2.2 Establish Training Records.
Establish and maintain records of the organizational training. The scope of this practice is for the training performed at the organizational level. Establishment and maintenance of training records for project- or support-group-sponsored training is the responsibility of each individual project or support group.

- SP 2.3 Assess Training Effectiveness.
A process should exist to determine the effectiveness of training (i.e., how well the training is meeting the organization’s needs). Measures may be taken to assess the benefit of the training against both the project’s and organization’s objectives. Particular attention should be paid to the need for various training methods, such as training teams as integral work units. When used, performance objectives should be shared with course participants, and should be unambiguous, observable, and verifiable.

Organizational Process Performance (OPP) Process Area in CMMi

A Process Management Process Area at Maturity Level 4. The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of the organization's set of standard processes in support of quality and process-performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization's projects.

Specific Goals and Practices

SG 1 Establish Performance Baselines and Models

- SP 1.1 Select Processes
Select the processes or subprocesses in the organization's set of standard processes that are to be included in the organization's process-performance analyses. Examples of criteria which may be used for the selection of a process or subprocess for organizational analysis include the following:
. The relationship of the subprocess to key business objectives.
. Current availability of valid historical data relevant to the subprocess.
. The current degree of variability of this data.
. Subprocess stability (e.g. stable performance in comparable instances).
. The availability of corporate or commercial information that can be used to build predictive models.

- SP 1.2 Establish Process Performance Measures
Establish and maintain definitions of the measures that are to be included in the organization’s process-performance analyses. Examples of criteria used to select measures include the following:
. Relationship of the measures to the organization’s business objectives.
. Coverage that the measures provide over the entire life of the product or service.
. Visibility that the measures provide into the process performance.
. Availability of the measures.
. Extent to which the measures are objective.
. Frequency at which the observations of the measure can be collected.
. Extent to which the measures are controllable by changes to the process or subprocess.
. Extent to which the measures represent the users’ view of effective process performance.

- SP 1.3 Establish Quality and Process Performance Objectives
Establish and maintain quantitative objectives for quality and process performance for the organization. Examples of business objectives include the following:
. Achieve a development cycle of a specified duration for a specified release of a product.
. Achieve an average response time less than a specified duration for a specified version of a service.
. Deliver functionality of the product to a target percentage of estimated cost.
. Decrease the cost of maintenance of the products by a specified percent.

- SP 1.4 Establish Process Performance Baselines
Establish and maintain the organization's process-performance baselines. Examples of criteria used to categorize subgroups include the following:
. Product line.
. Line of business.
. Application domain.
. Complexity.
. Team size.
. Work product size.
. Process elements from the organization’s set of standard processes.

- SP 1.5 Establish Process Performance Models
Establish and maintain the process-performance models for the organization’s set of standard processes. Process-performance models are used to estimate or predict the value of a process-performance measure from the values of other process, product, and service measurements. Examples of areas of concern to projects in which models may be useful include the following:

. Schedule and cost.
. Reliability.
. Defect identification and removal rates.
. Defect removal effectiveness.
. Latent defect estimation.
. Response time.
. Project progress.
. Combinations of these areas.

Organizational Process Focus (OPF) Process Area in CMMi

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

The organization’s processes include all processes used by the organization and its projects. Candidate improvements to the organization’s processes and process assets are obtained from various sources, including the measurement of processes, lessons learned in implementing processes, results of process appraisals, results of product evaluation activities, results of benchmarking against other organizations’ processes, and recommendations from other improvement initiatives in the organization.
Process improvement occurs in the context of the organization’s needs and is used to address the organization’s objectives.

Specific Practices by Goal

SG 1: Determine Process Improvement Opportunities
Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed.
- SP 1.1 Establish Organizational Process Needs
Establish and maintain the description of the process needs and objectives for the organization.
- SP 1.2 Appraise the Organization's Processes
Appraise the organization's processes periodically and as needed to maintain an understanding of their strengths and weaknesses. Process appraisals may be performed for the following reasons :
To identify processes that should be improved

To confirm progress and make the benefits of process improvement visible.

To satisfy the needs of a customer-supplier relationship.
To motivate and facilitate buy-in.
- SP 1.3 Identify the Organization's Process Improvements
Identify improvements to the organization's processes and process assets. Typical Work Products :
Analysis of candidate process improvements.
Identification of improvements for the organization's processes.

SG 2 Plan and Implement Process Improvement Activities
- SP 2.1 Establish Process Action Plans
Establishing and maintaining process action plans typically involves the following roles:
Management steering committees to set strategies and oversee process improvement activities.

Process group staff to facilitate and manage process improvement activities.
Process action teams to define and implement process actions.
Process owners to manage deployment.
Practitioners to perform the process.
- SP 2.2 Implement Process Action Plans

SG 3 Deploy Organizational Process Assets and Incorporate Lessons Learned
- SP 3.1 Deploy Organizational Process Assets.
Deploying organizational process assets or changes to organizational process assets should be performed in an orderly manner. Some organizational process assets or changes to organizational process assets may not be appropriate for use in some parts of the organization.
- SP 3.2 Deploy Standard Processes.
Deploy the organization’s set of standard processes to projects at their startup and deploy changes to them as appropriate throughout the life of each project. It is important that new projects use proven and effective processes to perform critical early activities.
- SP 3.3 Monitor Implementation.
By monitoring implementation, the organization ensures that the organization’s set of standard processes and other process assets are appropriately deployed to all projects. Monitoring implementation also helps the organization develop an understanding of the organizational process assets being used and where they are used within the organization.
- SP 3.4 Incorporate Process-Related Experiences into the Organizational Process Assets.

Organizational Process Definition + IPPD (OPD) Process Area

A Process Management process area at Maturity Level 3. The purpose of Organizational Process Definition + IPPD (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards. For IPPD, Organizational Process Definition + IPPD also covers the establishment of organizational rules and guidelines that enable conducting work using integrated teams.
Organizational process assets enable consistent process performance across the organization and provide a basis for cumulative, long-term benefits to the organization.
The organization’s process asset library is a collection of items maintained by the organization for use by the people and projects of the organization. This collection of items includes descriptions of processes and process elements, descriptions of lifecycle models, process tailoring guidelines, process-related documentation, and data. The organization’s process asset library supports organizational learning and process improvement by allowing the sharing of best practices and lessons learned across the organization.
The organization’s set of standard processes is tailored by projects to create their defined processes. The other organizational process assets are used to support tailoring as well as the implementation of the defined processes. The work environment standards are used to guide creation of project work environments.

Specific Practices by Goal

SG 1: Establish Organizational Process Assets
- SP 1.1 Establish Standard Processes.
- SP 1.2 Establish Lifecycle Model Descriptions.
- SP 1.3 Establish Tailoring Criteria and Guidelines.
- SP 1.4 Establish the Organization's Measurement Repository.
- SP 1.5 Establish the Organization's Process Asset Library.
- SP 1.6 Establish Work Environment Standards.

IPPD Addition:
SG 2: Enable IPPD Management
- SP 2.1 Establish Empowerment Mechanisms.
- SP 2.2 Establish Rules and Guidelines for Integrated Teams.
- SP 2.3 Balance Team and Home Organization Responsibilities.

CMMi - Process Area : Causal Analysis and Resolution (CAR)

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of defects and problems and take action to prevent them from occurring in the future. CAR is a Maturity Level 5 Process Area. CAR can be performed qualitatively at lower Maturity Levels, but the full benefits of CAR cannot be recognized until you have stable processes and statistically understand the process capabilities.

Causal analysis may also be performed on problems unrelated to defects. For example, causal analysis may be used to improve quality attributes such as cycle time. Improvement proposals, simulations, dynamic systems models, engineering analyses, new business directives, or other items may initiate such analysis.

When it is impractical to perform causal analysis on all defects, defect targets are selected by tradeoffs on estimated investments and estimated returns of quality, productivity and cycle time.

The Causal Analysis and Resolution process area involves the following:
- Identifying and analyzing causes of defects and other problems.
- Taking specific actions to remove the causes and prevent the occurrence of those types of defects and problems in the future.
Causal analysis and resolution improves quality and productivity by preventing the introduction of defects into a product.

Specific Practices by Goal

SG 1 Determine Causes of Defects
- SP 1.1 Select Defect Data for Analysis.
- SP 1.2 Analyze Causes.
SG 2 Address Causes of Defects
- SP 2.1 Implement the Action Proposals.
- SP 2.2 Evaluate the Effect of Changes.
- SP 2.3 Record Data.

General practices are same as discussed in Generic goals and practices article.

CMMI - Generic goals and practices in Process Areas

Each process area is defined by a set of goals and practices. There are two categories of goals and practices:
- Generic goals and practices (GG & GP): They are part of every process area.
- Specific goals and practices (SG & SP): They are specific to a given process area.

A process area is satisfied when company processes cover all of the generic and specific goals and practices for that process area.
Capability Maturity Model Integration (CMMI)--CMMI for Development, Version 1.2—contains 22 Process Areas that describe the aspects of product development that are to be covered by organizational processes.

Generic goals and practices

GG 1 Achieve Specific Goals
- GP 1.1 Perform Specific Practices.
GG 2 Institutionalize a Managed Process
- GP 2.1 Establish an Organizational Policy.
- GP 2.2 Plan the Process.
- GP 2.3 Provide Resources.
- GP 2.4 Assign Responsibility.
- GP 2.5 Train People.
- GP 2.6 Manage Configurations.
- GP 2.7 Identify and Involve Relevant Stakeholders.
- GP 2.8 Monitor and Control the Process.
- GP 2.9 Objectively Evaluate Adherence.
- GP 2.10 Review Status with Higher Level Management.
GG 3 Institutionalize a Defined Process
- GP 3.1 Establish a Defined Process.
- GP 3.2 Collect Improvement Information.
GG 4 Institutionalize a Quantitatively Managed Process
- GP 4.1 Establish Quantitative Objectives for the Process.
- GP 4.2 Stabilise Subprocess Performance.
GG 5 Institutionalize an Optimizing Process
- GP 5.1 Ensure Continuous Process Improvement.
- GP 5.2 Correct Root Causes of Problems.

Process Areas in Capability Maturity Model (CMM)

The Capability Maturity Model Integration (CMMI), based process improvement can result in better project performance and higher quality products.
A Process Area is a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making significant improvement in that area.
In CMMI, Process Areas (PAs) can be grouped into the following four categories to understand their interactions and links with one another regardless of their defined level:
Process Management : It contains the cross-project activities related to defining, planning, resourcing, deploying, implementing, monitoring, controlling, appraising, measuring, and improving processes. Process areas are :
- Organisational Process Focus.
- Organisational Process Definition.
- Organisational Training.
- Organisational Process Performance.
- Organisational Innovation and Deployment.

Project Management : The process areas cover the project management activities related to planning, monitoring, and controlling the project. Process areas are :
- Project Planning.
- Project Monitoring and Control.
- Supplier Agreement Management.
- Integrated Project Management for IPPD (or Integrated Project Management).
- Risk Management.
- Integrated Teaming.
- Integrated Supplier Management.
- Quantitative Project Management.

Engineering : Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines. Process areas are :
- Requirements Development.
- Requirements Management.
- Technical Solution.
- Product Integration.
- Verification.
- Validation.

Support : Support process areas cover the activities that support product development and maintenance. Process areas are :
- Process and Product Quality Assurance.
- Configuration Management.
- Measurement and Analysis.
- Organisational Environment for Integration.
- Decision Analysis and Resolution.
- Causal Analysis and Resolution.