Engineering Process Area
Process Improvement Frameworks
The major purpose of engineering process group (EPG) is to improve the process throughout the
organization. EPG first evaluate the existing process, define what a process should be and then
provide suggestion for improvement. EPG also manage multiple process action teams with the
purpose of improving different process areas simultaneously. PATs are individual teams created
to address specific process improvement and PAT teams are consisting of technical staff from
throughout the organizations. How EPG work is shown in the figure below followed by the details
about process action teams.
Executive Sponsorship &
Management Committee
Transition EPG
Partner Lead
Steering
Committee
Transition EPG
Partner Lead
Engineering Process
Group
(EPG)
EPG EPG EPG
Member Member Member
Process Action Process Action Process Action
Team Team Team
Technical
Staff
A. Different Process Areas and Goal
There are in total 22 process areas but in this course only engineering related process areas will
be discussed. As per CMMI definition, engineering process areas cover the development and
maintenance activities that are shared across engineering disciplines. These are as follows:
● Requirement Management Process Area
● Requirement Development Process Area
● Technical Solution Process Area
● Product Integration Process Area
● Software Validation Process Area
● Software Verification Process Area
Process Action Teams (PAT)
As mentioned above, PAT is responsible for implementation of improvement initiatives activities
in Specific Process Areas. In other words, each process area has associated process action team.
The PATs are also known as the "worker bees." with immediate focus on weakness fund in
process during the evaluation stage, their mandate is to write the procedures, pilot them, and
update them as needed. Members of PAT belong to different domains and department of the
organizations and they may include project managers. There tasks list is given below.
Task List of PAT
Process Action Teams (PAT) is mainly tasked to generate the process improvement
documentation, policies, processes, procedures, charters, and Action Plans. For the
improvement initiatives, PAT need to take care of different stakeholders for different process
areas. One important task of PAT is to bring consistency in the documents throughout the
organization in order to improve quality so they may need to work on drafting templates first.
This will help in bringing same document structure for all processes and avoid rewriting of
documents. This is also referred to standardization of artifacts.
A. Process Area: Requirement Management
This process area is concerned with the management of the entire requirement received or
generated by the project, either technical or non-technical. The major purpose behind this is to
ensure alignment between the requirements, project plans and the final output. One part of
requirement management is to document the entire requirement, any changes in requirement
along with their rationale. Change in requirements can take 2 forms, either change and/or
update in the existing requirement or new requirement added to the project. Motivations
behind requirement management process area are as follows:
● To manage inconsistencies between products and Requirements
● To manage different versions of Requirements
● To manage correlation between different project deliverable and requirements
● Traceability Matrix to be used to manage cross referencing
Action Item for Requirement Management
The goals of requirement management and practices to be followed are mentioned below:
Goal: Management Requirement
Practice: In order to achieve the goal, following practices are to be followed:
● Understanding Requirement: Develop an understanding with the requirements
providers on the meaning of the requirements.
● Obtain Commitment to Requirements: Obtain commitment to requirements from
project stakeholders. In other words, this specific practice deals with agreements and
commitments among those who carry out activities necessary to implement
requirements.
● Manage Requirements Changes: Manage changes to requirements as they evolve during
the project using Change Management Process by performing Impact Analysis.
● Maintain Bidirectional Traceability of Requirements: When requirements are managed
well, traceability can be established from a source requirement to its lower level
requirements and from those lower level requirements back to their source
requirements.
● Identify Inconsistencies: Ensure that project plans and work products remain aligned
with requirements.
Example of Requirement Management
Requirement Management
Consider a real-time scenario below:
● 13-Mar-2016: Client and Project Manager agree on Requirements and Client approves it
● 14-Mar-2017: Requirements are passed on to Technical Team by Project Manager so
they can work further
● 28-Mar-2017: Demo to be given to client and it was communicated to client
● 24-Mar-2017: Client and Project Manager agree on new set of requirements
● 28-Mar-2017: Client Reject the Demo by saying that Demo was not what was committed
and rejected the Demo
Root Cause Analysis
Client, Project Manager, Technical Team and QA were looking at different version of
Requirements.
B. Process Area: Requirement Development
The purpose of this process area is to analyze and establish customer, product and product
component requirements. Customer requirements are further divided into Product and Project
Requirements. Requirements are identified and refined throughout the phases of the product
lifecycle so all the requirements should be documented, analyzed and approved by the client
and the source trace should be maintained.
Major artifact for this process area is Development of Software Requirement Specification (SRS).
Action Item for Requirement Management
The goals of requirement development and practices to be followed are mentioned below:
● Develop Customer Requirements: Stakeholder needs, expectations, constraints, and
interfaces are collected and translated into customer requirements.
● Develop Product Requirements: Customer requirements are refined and elaborated to
develop product and product component requirements.
● Analyze and Validate Requirements: The requirements are analyzed and validated.
Example of Requirement Development
The most important thing is that SRS should explicitly be approved by Client otherwise it will
cause problem later in the Project.
The following images serve as good example of Requirement Development
C. Process Area: Technical Solutions
This process area is all about selection, design and implementation of solutions to the
requirement of the product/project. As a good practice, design and solution should be aligned
and traceable with the requirements. In other words, the selected solution should produce the
required output (requirement) and the solution must also tell that which requirement it is going
to fulfill. This process area focuses on evaluating different solution or design approaches that
satisfy functional and quality requirement. Wireframe are also considered, through partially, to
visualize the technical design. The main goals for these process areas are as follows:
● Select Product Component Solutions: Product or product component solutions are
selected from alternative solutions.
● Develop the Design: Product or product component designs are developed.
● Implement the Product Design: Product components, and associated support
documentation, are implemented from their designs.
Example of Technical Solutions
The main artifact is Technical Design Document. Its purpose is to streamline the requirements,
project plans and final output (product). All the details of adopted technical design are documented
in this artifact which ultimately gives a picture of product architecture along with the traceability with
the requirement.
D. Process Area: Product Integration
Software products are made of different components and this process area is all about
assembling the product from multiple product components and ensuring that the product (as a
whole) behaves properly and satisfy all the functional and quality requirements. Major failure
occurs when the product components are either failed to integrate with each other or partially
integrate which results in defects due to misaligned interfaces. So, heterogeneous Development
environment is a major risk in this area. Product integration is not one-time assembling of the
product components; in fact it can be done incrementally. In other words, instead of
simultaneous integration of all the components, only few components are integrated and tested
first and then more components are assembled. Usually Sanity is performed to ensure that
integration is successfully completed no further issues/defects are introduced due to it.
The main goals for this process area are:
● Prepare for Product Integration: Preparation for product integration is conducted.
Page | 5
● Ensure Interface Compatibility: The product component interfaces, both internal and
external, are compatible.
● Assemble Product Components and Deliver the Product: Verified product components
are assembled and the integrated, verified, and validated product is delivered.
Example of Product Integration
Team 1 Component 1
Integration
Point
Build Release Sanity Testing
Team 2 Component 2 (Software by SCM by Teams
Configuration
Team)
Team 3 Component 3
As per the example, there are three components developed by three different teams. These
components are integrated by software configuration team and the merged code based is
forwarded for sanity testing. Product integration also includes removal of issues on merged
codebase. Sanity testing on merged codebase will evaluate the integration and check that no
defects are introduced due to integration.
E. Process Area: Software Validation
This process area has the purpose of ensuring that the final product or its component(s) fulfill
the requirements and its intended use when deployed. The product or its components are
validated in the intended environment be it manufacturing, operations or any other. The major
goal is to capture client requirements correctly from client and then meeting that requirement
i.e. building the right thing. No code is required for software validation as it is just to check
whether the product is doing what it should be doing (as per requirements) in the intended
environment. Once again, Proof of Concept, Wireframes, and Requirement Modeling are key to
validation. The major goal for these process areas includes the following:
● Prepare for Validation: Preparation for validation is conducted by selecting the product,
validation environment and validation criteria
Page | 6
● Validate Product or Product Components: The product or product components are
validated to ensure they are suitable for use in their intended operating environment.
Example of Software Validation
Sample Requirements
● Admin (Employee) should be able to login
● Employee should be able to register another employee ¡n the organization
● Employee should be able to mark the attendance on daily basis
As per the requirement; employee is able to login, register another employee and mark
attendance i.e. developer build the right product. One good strategy for software validation is
that prototypes are shown to the customer and after approval the actual product is built and
delivered.
F. Process Area: Software Verification
Software Verification process area is more concerned with the engineering/programming
aspects of the project with the purpose to ensure that the final product is error free and selected
work products/components meet their specified requirements. Verification does not evaluate
usefulness of the system instead verification is concerned with whether the system is well-
engineered, error-free, and so on. So verification is more concerned with building the product
right way. Software verification includes testing, design analysis, inspections and code reviews.
The major goals for these process areas are as under:
● Prepare for Verification: Preparation for verification is conducted.
● Verify Selected Work Products: Selected work products are verified against their
Page | 7
specified requirements.
Example of Software Verification
Continuing with the same example, QA team will verify that all requirements are being fulfilled
and each part of the software is working properly. For example, in this case
Sample Requirements
● Admin (Employee) should be able to login
● Employee should be able to register another employee ¡n the organization
● Employee should be able to mark the attendance on daily basis
In verification QA team will execute each step after receiving the shipment from Development
team
Engineering Process Group
Engineering process group is organization’s focal point to implement software processes to
ensure compliance with quality standards. EPG also Act as oversight committee to monitor,
evaluate and improve processes and it is a major player in coordinating process activity
throughout the organization. Members of this group belongs to technical and management sides
of the organization and they are responsible to assess the existing process, provide and
implement suggestion for improvement and measure the effectiveness of the improved
processes.
What are Audits?
Audit is tool to measure the organizational compliance level with the established process.
Assessment and then improvements in any processes won't do any good for the organization if
the process is not being followed. Through audits, organizations not only check the level of
compliance but the reason behind the nonconformance. The reasons can come up in many
shapes like people are not provided with required resources or training to follow the process or
the process is misaligned with the working model and so on. Audits are conducted by
independent auditor who first study the process, evaluate the conformance level and then assign
ratings to the process after the audit.
Rationale for Audits
Audits are required to keep check and balance on organizational process and practices. Such
audits become more important in volatile working environments. Results of audits become a
starting point for process improvement and it gives valuable insights related to conformance. It
can also tell where improvement is needed; in process design, process implementation, working
conditions or the staff who are required to follow the process.
Page | 8
Audit Types
There are three (3) types of audits and these, along with brief explanation, are as follows:
● First Party Audits: These are often described as internal audits. Someone from the
organization itself audits a process to measure compliance and/or effectiveness.
● Second Party Audits: This is an external audit where the audit is being performed on
supplier by a customer or by a contracted organization on behalf of a customer with the
intention to ensure that the supplier is meeting contract specification.
● Third Party Audit: this is also an external audit and it’s performed by an audit
organization independent of supplier-customer relationship.
Audit Roles and Responsibilities
Audit team includes a certified lead auditor who leads the audit activities and a team of 2 to 3
members supporting the lead in performing audit. Each member is equipped with right attitude
and skills to measure the process results and performing the process audit to ensure compliance.
Further in tough scenarios, domain experts become a part of this team to deal with the
technicalities of such scenarios.
CMMI Appraisals
Appraisal is defined as a process to collect, review and analyzes data to measure performance
or compliance level. The collected data is then compared with the desired or standard data to
identify the gap between the actual and desired, if any with the main purpose of measuring the
effectiveness of the framework or process. CMMI appraisals provide ratings that accurately
reflect the capability level or maturity level of the processes in use.
Process Reviews
Process reviews are frequently carried out in the organizations to measure the effectiveness of
the process and to ensure that it is being completely followed. The frequency of process audit
depends upon many factors but usually it’s biannual or quarterly or on need basis. The process
reviews also helps in identifying the required actions to improve the process results. Those
required action may vary based on the results and it can be related to change/update in process
objectives or design, training of stakeholders, technological advancement and many others.
Review Policy
Every organization has its own review policy but the literature is full of best practices to be
followed while conducting review. The fact remains same, the process is useless without review
as no environment is static and no requirements are static. The current condition is best
described with the word dynamic or constantly changing and so must be the process to get
desired results. Through review policy, organizations define what to review and when to review.
Page | 9
Benchmarking for Process Review
There are many common issues the modern era organizations face today but the prospects of
those issues or the circumstances might vary based on multiple factors. Benchmarking is the
referencing to those common problems. For any issue, organization adopts the model of another
organization that went through, more or less, same condition and developed a successful
solution to it. Adopting the already developed solution after some amendments saves an
organization a lot of time and efforts. Besides this, organization can use the best practices, with
some modification, available in literature or research journals.
Page | 10