MS Computer Science Virtual University of Pakistan

CS724 Midterm Solved Past Papers (Mega File)

software process improvement


Software Process Improvement

CS724 Midterm Solved Past Papers (Mega File)

Q.NO.1: What are PSP measures?

There are three basic measures in the PSP:

  1. Development time
  2. Defects
  3. Size

Development Time Measure

  • Minutes are the unit of measure for development time
  • Engineers track the number of minutes they spend in each PSP phase, less time for any interruptions such as phone calls, coffee breaks, etc.
  • Using minutes is precise and simplifies calculations involving development time
  • Recording interruptions to work reduces the number of time log entries, provides a more accurate measure of the actual time spent, and a more accurate basis for estimating actual development time.
  • Tracking interruption time separately can help engineers deal objectively with issues that affect time management, such as a noisy work environment or inappropriate mix of responsibilities (e.g., software development and help desk support)
  • Time log entries take substantially less than a minute to record, but provide a wealth of detailed historical data for planning, tracking, and process improvement

Defect Measure

  • A defect is defined as any change that must be made to the design or code in order to get the program to compile or test correctly. Defects are recorded on the Defect Recording Log as they are found and fixed
  • The example Defect Recording Log shows the information that is recorded for each defect: the date, sequence number, defect type, phase in which the defect was injected, phase in which it was removed, fix time,3 and a description of the problem and fix
  • When an engineer injects a new defect while trying to fix an existing defect, proper accounting of fix time becomes more complicated
  • A common mistake is to include the fix time for the new defect twice
  • Each defect is classified according to a defect type standard
  • A standard and easy to use classification scheme should be used

Size Measure

  • The primary purpose of size measurement in the PSP is to provide a basis for estimating development time
  • Lines of code or function points can be used
  • Size is also used to normalize other data, such as productivity (LOC per hour) and defect density (defects per KLOC)

PSP Derived Measures

  • PSP introduces new measures to help engineers manage and improve their performance
  • These measures are derived from the three basic PSP measures: development time, defects, and size

Q.NO.2: What is the objective of Controlling the Process?

Controlling a process means keeping the process within its normal (inherent) performance boundaries – that is, making the process behave consistently. This involves:

  1. Measurement
  2. Detection

Measurement: Obtaining information about process performance

Detection: Analyzing the information to identify variations in the process that are due to assignable causes

Correction: Taking steps to remove variation due to assignable causes from the process and to remove the results of process drift from the product

Q.NO.3: Step of project planning? Explain Software scope?


The purpose is to establish reasonable plans for performing the software engineering and managing the project

It involves:

  • Developing estimates for the work
  • Establishing necessary commitments
  • Defining the plan to perform the work

Managing Based on Plan

Plan provides the basics for initiating the software effort and managing the work.

Other names for this plan include:

  • Software development plan
  • Software project management plan
  • Software project plan
  • Software engineering management plan

Software Scope

  • Understand the problem and the work that must be done – in a nutshell
  • Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability
  • Project scope must be unambiguous and understandable at the management and technical levels
  • A statement of software scope must be bounded – in other words
  • At the beginning of a project, things are very hazy and nothing is clear
  • Good and open communication is required between developers and customer to define the scope of the project
  • Who is behind the request for this work?
  • Who will use the solution?
  • What will be the economic benefit of a successful solution?
  • Is there another source for the solution?

Q.NO.4: Briefly explain KPA quantitative process management of CMM level 4?

KPAs – Level 4

  1. Software Quality Management
  2. Quantitative Process Management

Quantitative Process Management


Purpose is to control the process performance of software project quantitatively

It involves:

  • Establishing goals for the process performance
  • Measuring the performance of the project
  • Analyzing these measurements
  • Making adjustments to maintain process performance within acceptable limits.

Controlling Special Causes of Variation:

  • An important concern is identifying variations in performance that are not within the normal range of process performance
  • Extraordinary events outside the bounds of the process capability.

Taking Corrective Action at Level 4

  • Quantitative Process Management focuses on the process
  • Process capability is quantitatively known
  • When performance falls outside the limits:
    • Identify the reason
    • Take corrective action when appropriate

Basic Statistics

  • Quantitative, or statistical, techniques need to be sophisticated to be useful
  • Preto analysis for example is very simple
  • Quantitative techniques do require  Measurable data   Consistent data collection  Defined comparable measurements

Seven (Some) Basic Tools of Statistical Process Control

  • There are seven quantitative tools considered basic to statistical process or quality control.
  1. Histograms
  2. Cause and effect diagrams
  3. Check sheets
  4. Pareto diagrams
  5. Run charts
  6. Control charts
  7. Scatter diagrams

Software Quality Management


  • Purpose is to develop a quantitative understanding of the quality of the project’s softwareproducts and achieve specific quality goals
  • It involves
  • Defining quality goals for the software products,
  • Establishing plans to achieve these goals
  • Monitoring and adjusting software plans and work products

Building High-Quality Products

  • Software Quality Management Focuses on the product.
  • Measurable quality goals for the product are defined.
  • The product is ready when the goals are achieved.

Quality Evolves

  • At level 2 the focus of quality is conformance to requirement
  • By level 4 there is emphasis on understanding needs of the
  • Customer
  • End users
  • Organization (supplier)
  • Ultimately customer determines what quality is or is not
  • TQM revolves around customer satisfaction

Q.NO.5: Briefly explain the KPA “Peer reviews” of software CMM level 3?

Peer Reviews

Purpose: Purpose is to remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding of the software work products and of defects that might be prevented.

It involves:

  • Methodical examination of work products by the producer’s pees to identify defects and areas where changes are needed.
  • Identifying products that will undergo a peer review in the project’s defined software process.

Performing Peer Reviews

  • Plan and schedule peer reviews
  • Train leaders and participants
  • Give material to the reviewers in advance
  • Assign each reviewer a specific role
  • Specify criteria to begin and end reviews
  • Use pre planned checklists
  • Identify action items and track to closure
  • Collect and analyze data for product and peer review process

Alternative Peer Review Methods

  • Possible alternative ways of implementing peer reviews include;
  • Fagan-style inspections
  • Structured walkthroughs
  • Active reviews
  • Phased inspections

Q.NO.6: Briefly explain the KPA “Software product engineering” of software CMM level 3?

Purpose: Purpose is to consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.


Performing the engineering tasks to build and maintain the software using the appropriate methods and tools.

Software Life cycles processes

Development and maintenance activities include

Software requirement analysis

  • Software design
  • Coding
  • Testing
  • Integration

Testing activities include 

  • Unit
  • Integration
  • System
  • Acceptance


  • Addresses needs that span life cycle
  • Customer and end-user documentation includes
  • User manuals
  • Training materials
  • Operator manuals
  • Developer / maintainer documentation includes
  • Software requirements documents
  • Design documents
  • Test documents
  • Maintenance manuals

Consistency and Traceability

  • Consistency and traceability among documents are critical to their usefulness
  • Inconsistent specifications are not useable
  • If the relationship between documents is not clearly traceable, their usefulness is minimized

Q.NO.7: Write the entry criteria of EVTX model of preparation activity in an inspection process?

Preparation: Entry Criteria

  • The overview, if needed, has been satisfactorily completed
  • Any open issues identified for the overview have been closed and addressed in the work product or are documented as open issues and provided as ancillary material for the preparation
  • Open issues not closed are documented for tracking within the change control system used by the project
  • The producer determines that the work product is ready for inspection
  • The work product has reached closure and the code complies with defined standards, style guides, and templates for format
  • All necessary ancillary material have been made available well in advance
  • The work product includes all base-lined function and approved changes for this planned work product completion date
  • The amount of time needed for preparation has been confirmed with the inspectors and is available to them
  • Predecessor and dependent work products are available, have been inspected, and meet exit criteria
  • The moderator and producer have defined the coverage of material to be inspected
  • The work products allow easy identification of defects by location in the material
  • The moderator agrees that the work product is inspectable

Q.NO.8: Write the KPA of CMMI level 2 of requirement management?

Requirements Management 

Purpose: The purpose is to establish a common understanding between the customer and organization.


  • Document and control of customer requirements
  • Keeping plans, products, and activities consistent with requirements

Software Requirements versus Allocated Requirements

  • The scope of Requirements management is control of requirements allocated to software
  • Requirements allocated to software come from systems engineering
  • Software requirements are derived from requirements allocated to software

Who is Customer?

  • Customers may be external or internal
  • Systems engineering
  • Marketing
  • User
  • The customer and / or end user identifies the problem that software will address

Documentation of requirements

  • The system requirements assigned to software Engineering must be documented
  • Documenting system requirements can be as simple as a memo or as elaborate as a multi volume specification
  • If requirements change, the changes must be documented and all resulting necessary changes in other documents must be tracked and verified

Review of Requirements

The software engineering group ensures that the system requirements allocated to software are documented and controlled. For which, the software engineering group reviews the initial and revised system requirements allocated to software to resolve issues

Q.NO.9: Write the KPA of CMMI level 2 of project planning?


  • The purpose is to establish reasonable plans for performing the software engineering and managing the project


  • Developing estimates for the work
  • Establishing necessary commitments  Defining the plan to perform the work

Managing Based on Plan

  • Plan provides the basics for initiating the software effort and managing the work.
  • Other names for this plan include:
  • Software development plan
  • Software project management plan
  • Software project plan
  • Software engineering management plan

What is a Software Development Plan?

  • A software development plan specifies many or all of the following:
  • Projects chosen software life cycle
  • List of products to be developed
  • Schedules
  • Estimates for level of effort (number of people), cost, etc.
  • Facilities, support tools, and hardware
  • Project risks

Packaging the Software Development Plan

  • There are many ways the software plan can be developed.
  • There may be separate documents entitled:
  • Software development plan
  • Software quality assurance plan
  • Software configuration management plan
  • Risk management plan
  • Software test plan
  • Project training plan

Plans are based on Estimates

  • In creating estimates for size, effort, cost, schedule, and/or computer resources
  • Use historical data, where available
  • Document assumptions and estimates
  • Good estimating depends on the skills and judgment of the estimator

Meeting Commitments

  • Commitment – a pact that is freely assumed, visible, and expected to be kept by all parties.
  • Commitment is necessary to achieve plans.
  • Feasible commitments are made when plans are realistic.
  • Commitment is a process.

 Q.NO.10: Define KPA as technical solution?

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 life-cycle processes either singly or in combination as appropriate

Specific Goals for TS

SG1 Select Product Component Solutions

  1. SP 1.1 Develop Alternative Solutions and Selection Criteria
  2. SP 1.2 Select Product Component Solutions

SG2 Develop the Design

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

SG3 Implement the Product Design

  1. SP 3.1 Implement the Design
  2. SP 3.2 Develop Product Support Documentation
  • In this process area, when the model refers to processes, the model generally does not mean process improvement–type processes, but design processes. That is, the processes they are talking about in this PA focus on the technical steps necessary to produce the product
  • Peer reviews are mentioned in this process area
  • Things People Forget

Alternative solutions should be investigated

  • There are no generic practices that directly map to this process area
  • Technical Solution includes determining how to satisfy the requirements via analysis of different alternatives and methods; creating operational scenarios; selecting solutions and follow-on designs; generating a technical data package that may include development methodologies, bills of material, life-cycle processes, product descriptions, requirements, conditions of use, rationale for decisions made, and verification criteria; defining and documenting detailed interface information; determining whether to make, buy, or reuse; and implementing the design an generating supporting documentation

Q.NO.11: Explain W, A and U process model? Levels of Software Process Models?

Worldly or W Process Models

  • W process models are most useful to practicing software engineers
  • It guides the sequence of their working tasks and defines task prerequisites and results
  • They look like procedures
  • They specify who does what when
  • Where appropriate, they reference the A level that specifies standard task definitions or tool usage
  • For each task, W models define the anticipated results, the appropriate measures, and the key Checkpoints.

Atomic or A Process Models

  • “A” process models are enormously detail
  • They are used to automate specific process activity or use a standardized method or procedure to guide execution of a task
  • Precise data definitions, algorithmic specifications, information flows, and user procedures are essential at this level
  • The amount of details to be included in such models must be determined by their use
  • For example, an experienced developer who is repeating known manual tasks will not need as detailed a standard as a new trainee
  • When the task is to be automated, however, a great deal of detail is generally required
  • Atomic process definitions are often embodied in process standards and conventions, which can be treated as process abstraction in higher level “W” or “U” process models.

Universal or U Process Models

  • U process models provide high-level overview
  • Traditional Waterfall, Spiral, and other later process models fall in this category
  • Typically task-oriented
  • The fundamental problem with simplistic U –level software process models is that they do not accurately represent what is really done
  • The reason is that traditional process models are extremely sensitive to task sequence; consequently, simple adjustments can destroy the entire framework
  • Take the example of the waterfall model, which has been used in the software industry for a long time
  • Provides a very simplified view of activities, which can lead to inaccurate model development

Q.NO.12: Explain PSP process level “personal project management”?

Personal Project Management

  • Personal project management techniques are the focus at this level, introducing size and effort estimating, schedule planning, and schedule tracking methods
  • The estimated size of the newly developed code is the sum of all new objects, plus any modifications or additions to existing base code
  • Predicted program size and effort are estimated using the statistical method linear regression
  • Linear regression makes use of the historical relationship between prior estimates of size and actual size and effort to generate predicted values for program size and effort
  • Finally, a prediction interval is calculated that gives the likely range around the estimate, based on the variance found in the historical data
  • The prediction interval can be used to assess the quality of the estimate
  • PSP uses the earned value method for schedule planning and tracking
  • The earned value method is a standard management technique that assigns a planned value to each task in a project
  • A task’s planed value is based on the percentage of the total planned project effort that the task will take
  • As tasks are completed, the tasks planned value becomes earned value for the project
  • The project’s earned value the becomes an indicator of the percentage of completed work
  • When tracked week by week, the project’s earned value can be compared to its planned value to determine status, to estimate rate of progress, and to project the completion date for the project

Q.NO.13: Explain PSP process level “Personal Quality Management”?

Personal Quality Management

  • Quality management methods are added to the PSP at this level
  • These include: personal design and code reviews, a design notation, design templates, design verification techniques, and measures for managing process and product quality
  • The goal of quality management in the PSP is to find and remove all defects before the first compile. The measure associated with this goal is yield
  • Yield is defined as the percent of defects injected before compile that were removed before compile. A yield of 100% occurs when all the defects injected before compile are removed before compile
  • Design and code reviews help engineers achieve 100% yield. These are personal reviews conducted by an engineer on his/her own design or code
  • They are structured, data-driven review processes that are guided by personal review checklists derived from the engineer’s historical defect data
  • Engineers also begin using the historical data to plan for quality and control quality during development
  • Their goal is to remove all the defects they inject before the first compile
  • During planning, they estimate the number of defects that they will inject and remove in each phase. Then they use the historical correlation between review rates and yield to plan effective and efficient reviews
  • During development, they control quality by monitoring the actual defects injected and removed versus planned, and by comparing actual review rates to established limits
  • With sufficient data and practice, engineers are capable of eliminating 60% to 70% of the defects they inject before their first compile

Q.NO.14: Explain PSP process level “the baseline personal process”?

The Baseline Personal Process

  • The baseline personal process provides an introduction to the PSP and establishes an initial base of historical size, time, and defect data.
  • Basic process measurement and planning are introduced here.
  • Development time, defects, and program size are measured and recorded on forms. A simple plan summary form is used to document planned and actual results.
  • A form for recording process improvement proposals (PIPs) is also introduced. This form provides engineers with a convenient way to record process problems and proposed solutions.

Steps in Baseline PSP:

Step Phase Description
1PlanPlan the work and document the plan
2DesignDesign the program
3CodeImplement the design
4CompileCompile the program and fix and log all defects found
5TestTest the program and fix and log all defects found
6PostmortemRecord actual time, defect, and size data on the plan


Q.NO.15: Describes the basic element of process architecture of unit cell?

A Unit Cell

  • The basic element of the process architecture is the unit cell
  • Each cell is defined to accomplish a specified task and is uniquely identified

Unit Cell Definitions for Process Model/architecture:

CellImplementation 001Design 002Test 003
EntryApproved requirements, changes and development planInspected and approved design and changesInspected and approved code and changes
ExitInspected and approved design changesInspected and approved code and changesInspected tested and approved software
Feedback inDesign IssuesImplementation Issues
Feedback OutRequirements IssuesRequirements and Design IssuesRequirements, Design Issues, and Implementation Issues
TaskDesignImplementation, Inspection and Unit testTesting: Integration, Function, System, and Acceptance
MeasuresResources, Product; Changes, Errors, Design, Document PagesResources, Product: Changes, Errors, Code, Document PagesResources, Product: Changes, Errors, Code, Document Pages, Test Suite

Q.NO.16: Explain Deming’s approach?

Deming Approach

  • Other industries began to adopt the approach advocated by W. Edwards Deming and successfully implemented by many companies in Japan
  • Deming approach, greatly influenced by the work of Walter A. “helhalt, deals with the notions of process management and continual improvement
  • Deming approach contends that to be competitive, improve quality, and increase productivity, the following actions are required
  • Focus on the processes that generate the products and services to improve quality and productivity. Consider the task of building the product or providing the service as a series of integrated and interconnected processes
  • Ensure that the processes are properly supported
  • Manage poorly behaving processes by fixing the process, not blaming the people
  • Recognize that variation is present in all processes and that existence of variation is an opportunity for improvement. Improvement comes from reducing variation
  • Take variation into account in the decision-making process. Management action uses data from the process to guide decisions

Q.NO.17: What are objective of Technical Review and which terms are not measured by Technical Review?

Objectives of Formal Technical Reviews (FTRs)

  • Uncover errors in function, logic, or implementation for any representation of the software
  • To verify that the software under review meets its requirements
  • To ensure that the software has been represented according to predefined standards
  • To achieve software that is developed in a uniform manner
  • Make projects more manageable
  • Ownership transfers from individual to group
  • In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation
  • Also serves as a means of corporate backup

What Technical Reviews Are Not Measured!

  • A project budget summary
  • A scheduling assessment
  • An overall progress report
  • A mechanism for reprisal or political intrigue

Q.NO.18: Measurement and analysis of CMM level 3?

Software requirement analysis at CMM level 3

  • Software design
  • Coding
  • Testing
  • Integration


  • A central repository for organization measurement data.
  • Contains
  • Actual measurement data (the numbers) from individual projects
  • The related information needed to understand the measurement data and apply it to the new projects
  • This is where the planning and re-planning data for the organization as a whole are kept

Q.NO.19: Key Process Areas for PSP?

  • Software project planning
  • Software project tracking/oversight
  • Software process focus
  • Software process definition
  • Integrated software management
  • Software product engineering
  • Peer reviews
  • Quantitative process management
  • Quality management
  • Defect prevention
  • Technology change management
  • Process change management

Q.NO.20: Explain measurement and analysis of CMMI level 2?

Measurement and Analysis

  • While instituting a measurement approach and repository is not an easy task, it is so necessary for success of any process improvement initiative that it is important that this task should be initiated early in the process improvement effort
  • There is a difference between beginning and successfully implementing
  • Organizations were good at collecting measurements but not in actually using the measurements. While creating this process area as a separate entity has not really ended that problem, it has made organizations more aware of the importance of measurements and tracking against those measurements
  • Things People Forget
  • You have to tie your measurements back to meaningful business goals—not just collect something because it has always been collected or not just collect something because the book tells you to in the examples. So don’t measure everything listed as an example—but, also, dot just pay lip service to this area. Prove that you are collecting the right measurements that will truly help track progress and failure of your process improvement effort and of your business activities
  • This process area is about defining a measurement effort inyour organization. Don’t forget to measure your measures. That is, you also must track the time and effort and effectiveness of your measurement effort itself
  • The generic practice that most closely matches this PA is GP 2.8 Monitor and Control the Process
  • The M&A process area, plus the Project Monitoring and Control PA must both be implemented to satisfy GP 2.8
  • Measurements should focus on the process, its products, and its services

Basic Step-by-Step Approach to Measurement

  • Select the process to measure
  • Select the measures
  • Determine when to collect data
  • Determine how to collect data
  • Record and store the information
  • Analyze data for consistency and accuracy
  • Chart the results
  • Review the chart
  • Do something (corrective actions)

Q.NO.21: EVTX for data recording and reporting?

Data Recording and Reports

  • To record the data about the defects and conduct of the inspection
  • This activity is held concurrently with other activities, including at the end of the inspection process

Data Recording and Reports: Entry Criteria

  • The optional overview meeting was held
  • The inspection meeting was held
  • The optional analysis meeting was held

Data Recording and Reports: Tasks

  • Record data from overview, if held
  • Record data at the inspection meeting, including preparation data
  • Record data at the optional analysis meeting
  • Record data during the follow-up activity, including sign-off to close the inspection

Data Recording and Reports: Validation/Verification

  • The inspection verifies the data at the end of the inspection meeting and optional analysis meeting
  • SQA review sampled reports
  • The producer reviews the report completed by the moderator
  • Data should be considered for this activity; e.g., how much effort is used for recording and reporting

Data Recording and Reports: Exit Criteria

  • The data are complete and agreed to by the inspection meeting and analysis meeting participants
  • The data gathered during the follow-up activity are complete and agreed to by the producer and
  • Moderator

Q.NO.22: CMMI process area organizational innovation and deployment?

Organizational Innovation and Deployment

  • The purpose of Organizational Innovation and Deployment (OID) is to select and deploy incremental and innovative improvement that measurably improve the organization’sprocesses and theologies. The improvement  support the organization’squality and process– performanceobjectives as derived from the organization’sbusinessobjectives
  • In OID, the proposals are subjected to quantitative analysis of proposed improvements. Metrics residing in the historical database, as well as defects and where they were introduced, are reviewed as well in order to determine where, when, and how to make improvements. Costs and benefits of the proposed versus actual improvements are also stud
  • Organizational Innovation and Deployment involves coordinating process improvement proposals submitted from the  staff at various levels (improvement proposals may be related to innovative technology improvements); piloting selected improvements; planning and implementing the deployment of improvements throughout the organization; and measuring the effects of the improvements implemented

Steps in this PA

  • Submitting improvement proposals
  • Reviewing and analyzing the proposals (including a cost-benefit review)
  • Piloting the proposed improvement
  • Measuring the improvement to see whether it has been effective in the pilot
  • Planning the deployment of the improvement
  • Deploying the improvement
  • Measuring the effectiveness of the improvement across the organization or project

Q.NO.23: Explain CMMI level 5?

CMMI Level 5

  • At Level 5, an organization has achieved all of the goals of Levels 2, 3, and 4
  • The major difference between Level 4 and the next level, Level 5, is that Level 4 analyzes the data collected, determines special causes of variation from the norm, and supports quantitative management and control
  • Although innovative, radical approaches to introduce change into an organization are often undertaken, most organizations have found that an incremental approach works better and has longer-lasting results
  • Process Areas at Level 5
  • Organizational Innovation and Deployment
  • Causal Analysis and Resolution
  • There are no additions to the list of generic goals at Level 5 from Level 3. What makes this maturity level different is the two process areas
  • GG2 Institutionalize a Managed Process
  • GG3 Institutionalize a Defined Process
  • To satisfy the goals for Level 5, the goals for Levels 2, 3, and 4 must be satisfied as well. This rule holds true for both the specific goals and the generic goals

LEVEL 5 improve the overall quality of the organization’s processes by

  • identifying common causes of variation
  • determining root causes of the conditions identified
  • piloting process improvements

Q.NO.24: CMMI level 2 organizational training process area?

Process Area

  • This PA expects a Strategic Training Plan coming from the OSSP, as well as business plans, process improvement plans, defined skill sets of existing groups, missing skill sets of existing groups, skill sets needed for any nonexistent groups necessary to be formed, mission statements, and vision statements
  • And all of these things are tied into training plans. That’s a lot of documentation that many smaller organizations do not have and do not need. Small organizations tend to operate at the tactical planning level and not at the strategic level. This PA expects a Strategic Plan that leads to a Tactical Plan.
  • Organizational-level training plans bubble up from project-level training plans and needs. Organizations also need to evaluate the effectiveness of the training received
  • This process area is not about knowledge management. While you may define core competencies and certifications necessary, the concepts are not that similar. For that consult People CMM

Q.NO.25: Explain SCM (Software configuration Management) functions?

SCM Functions:

  1. Identification of software configuration items
  2. Version control
  3. Change control
  4. Configuration audit
  5. Status accounting/reporting

SCM Function 1: Identification

  • To control and manage software configuration items, each item must be separately named or numbered
  • The identification scheme is documented in the software configuration management plan
  • The unique identification of each SCI helps in organization and retrieval of configuration items

SCM Function 2: Version Control

  • Version control combines procedures and tools to manage different versions of configuration items that are created during the software process
  • The naming scheme for SCIs should incorporate the version number
  • Configuration management allows a user to specify alternative configurations of the software system through the selection of appropriate versions
  • This is supported by associating attributes with each software version, and then allowing a configuration to be specified [and constructed] by describing the set of attributes

SCM Function 3: Change Control

  • Change control is vital
  • Too much change control and we create problems. Too little, and we create other problems (elaborate this point more)
  • For large projects, uncontrolled change rapidly leads to chaos
  • For medium to large projects, change control combines human procedures and automated tools to provide a mechanism for the control of change

SCM Function 4: Configuration Audit

  • A software configuration audit complements the formal technical reviews/inspections by assessing a configuration item for characteristics that are generally not considered during review
  • The SCM audit is conducted by the quality assurance group
  • Has the change specified in the ECO been made? Have any additional modifications been incorporated?
  • Has a formal technical review been conducted to assess technical correctness?
  • Has the software process been followed and have software engineering standards been properly applied?
  • Has the change been “highlighted” i the “SCI? Have the change date ad author been specified? Do the attributes of the configuration object reflect the change?
  • Have SCM procedures for noting the change, recording it, and reporting it been followed?
  • Have all related SCIs been properly updated?

SCM Function 5: Status Accounting/Reporting

  • The status accounting function provides a corporate memory of project events that supports accomplishment of other configuration management items
  1. What happened?
  2. Who did it?
  3. When did it happen?
  4. What else will be affected?

Q.NO.26:Intergroup coordination at CMM level 3?

Purpose: Purpose is to establish a means for software engineering group to participate actively with the other engineering groups, so that the project is better able to satisfy the customer needs effectively and efficiently.

It involves: Disciplined interaction and coordination of the projects engineering groups with each other to address system-level requirements, objectives and plans

Ongoing working Relationship

  • Commitments among groups are documented and agreed to by all groups
  • Inter group coordination can be
  • As minimal as one or two meetings between project groups
  • As extensive as integrated product teams

Interdisciplinary Groups

  • The software engineering group actively interfaces with a variety of groups.
  • Examples of these groups, to whom the interface must be managed include;
  • Systems engineering
  • Marketing
  • Training
  • Sub contract management
  • Documentation
  • Intergroup coordination is a first step on the road to concurrent engineering

Q.NO.27: ETVX of rework of software inspection process?

Rework: Entry Criteria

  • The list of defects and open issues is provided to the producer for resolution
  • The moderator or someone assigned meets with the producer to review rework and open issues
  • The inspection report is completed, is on file, and available

Rework: Tasks

  • The producer repairs accepted defects identified during the inspection meeting
  • The producer resolves any open issues
  • The moderator meets with the producer to discuss resolutions of open issues
  • Change requests are written for any open issues or defects not resolved during the rework activity
  • Either the minor defect list or marked work products with minor defects noted are used to repair the minor defects

Rework: Validation/Verification

  • The follow-up activity is scheduled; where the rework will be verified by the moderator or assigned designee
  • SQA has reviewed sample results of this activity in the project
  • Data gathered during this activity
  1. How much time was spent in rework
  2. How many open issues were resolved and accepted as defects
  • How many open issues became submitted change requests

Rework: Exit Criteria

  • The producer resolves all defects and open issues
  • Inspected work product materials are updated to account for repairs

Q.NO.28: Define KPA of CMMI “verification”?

PA 4 – Verification

  • The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements
  • Specific goals for this process area are
  1. SG1 Prepare for Verification
  2. SG2 Perform Peer Reviews
  • SG3 Verify Selected Work Products
  • SG1 Prepare for Verification – Specific Practices
  1. SP 1.1 Select Work Products for Verification
  2. SP 1.2 Establish the Verification Environment
  • SP 1.3 Establish Verification Procedures and Criteria
  • SG2 Perform Peer Reviews – Specific Practices
  1. SP 2.1 Prepare for Peer Reviews
  2. SP 2.2 Conduct Peer Reviews
  • SP 2.3 Analyze Peer Review Data
  • SG3 Verify Selected Work Products – Specific Practices
  1. SP 3.1 Perform Verification
  2. SP 3.2 Analyze Verification Results
  • The Verification PA allows the usage of test setups and test simulators. Sometimes, the same test setups and simulators may be used for Validation as well—you just use them for different purposes, looking for different things
  • Acceptance testing is mentioned here
  • Things People Forget
  1. You don’t need to test everything
  2. You do need to test almost everything
  • You cannot test in quality

You must do both peer reviews and testing. You can peer review and test the same products or different products. Try to ensure total coverage of the product, by one means or the other, if possible.

Q.NO.29:What are attributes of process suggested by CMMI?

Attributes of a Process suggested by CMMI 

Attributes of a Process

Purpose: Purpose of the process.

Inputs: Work products, plans, approval memoranda (usually nouns).

Entry criteria: What must be triggered before this process can start? (Usually the exit criteria of the previous step or process. Usually stated as a verb.)

Activities: Tasks that must be performed. These tasks are usually later broken down into the detailed procedures for how to perform the tasks

 Roles: Who does what? (Usually by position.)

Measures: What measures does this process produce?

Verification steps: What reviews are performed to determine that this process is followed and is producing the correct results? (Usually management and quality assurance reviews, but sometimes can include customer, peer, and project team reviews.)

Outputs: Work products, plans, approved products (can be the completed inputs)

Exit criteria: How do we know when it is time to stop this process? (Usually expressed in verbs, and usually becomes the entry criteria for the next process step or next process.)

Q.NO.30:Shortly explain “KPA software subcontract management CMM level 2”?

Purpose: To select qualified software subcontractors and manage them effectively.

 It involves:

  • Selecting a software subcontractor
  • Establishing commitments with the subcontractor
  • Tracking and reviewing the subcontractor performance and results

Planning for the Subcontract

  • In selecting and managing subcontractor, prime contractors must perform activities additional to the ordinary project management effort.
  • Specify the work to be performed and the procedures to be followed by the subcontractor
  • Statements of work
  • Requirements
  • Products to be delivered
  • Standards
  • Procedures
  • Specify criteria for selecting and evaluating subcontractors

Selecting the Subcontractor

  • The qualifications of a subcontractor may depend on many factors
  • Process capability
  • Software engineering expertise
  • Application domain knowledge
  • Strategic business alliances

Managing a Subcontract

  • The prime contractor must manage subcontract
  • Ensures subcontractor follow software development plans, standards and procedures
  • Monitoring software quality assurance by subcontractor
  • Monitoring software configuration management by the subcontractor

Prime vs Subcontractor

  • The prime contractor is the organization responsible for building a system
  • The prime contractor may contract out part of the work to another contractor, thesubcontractor
  • Performance of the prime contractor may critically depend on performance of thesubcontractor

Q.NO.31:What is Process model? What are its variations and types of process model??

Process Model

  • A process model is a simplified description of a process presented from a particular perspective
  • There may be several different models of the same process
  • No single model gives a complete understanding of the process being modeled

Variations in Process Model

  • A process model is produced on the anticipated need for that model
  • A model to help explain how process information has been organized
  • A model to help understand and improve a process
  • A model to satisfy some quality management standard

Types of Process Model

  • Coarse-grain activity models
  • This type of model provides an overall picture of the process
  • Describes the context of different activities in the process
  • It doesn’t document ho to enact a process
  • Fine-grain activity models
  • These are more detailed models of a specific process, which are used for understanding and improving existing processes

Q.NO.32: Explain process area “validation” of CMMI 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
  • Specific goals for this process area are
  • SG1 Prepare for Validation
  • SG2 Validate Product or Product Components
  • SG1 Prepare for Validation – Specific Practices
  • SP 1.1 Select Products for Validation
  • SP 1.2 Establish the Validation Environment
  • SP 1.3 Establish Validation Procedures and Criteria
  • SG2 Validate Product or Product Components – Specific Practices
  • SP 2.1 Perform Validation
  • SP 2.2 Analyze Validation Results
  • Discussion on VAL
  • Validation involves creating an environment as close as possible to the environment in which the product will be used in order to perform final testing of the product.
  • Things People Forget
  • You dot need to test everything.
  • Validation is not performed at the end of the project.
  • Make sure you plan in detail any tests to be performed by the users or in the user environment
  • If you are simulating the user environment, make sure it truly replicates the actual environment.
  • If you are developing a Web-based system using the Web that your users will use, then you may have satisfied Validation without knowing about it.
  • General Practices
  • There are no general practices that directly map to this process are
  • Validation asks: are you building the right product?

Q.NO.33: What are benefits of IDEF0?

IDEF0 Benefits

  • IDEF0 reveals redundant and non-value-added processes.
  • IDEF0 documents the AS-IS– the processes, the relationships between them, and the logical breakdown of those functions into their sub-processes and properties for baseline evaluation and further analysis
  • IDEF0 begins the road map from the AS-IS to the TO-BE
  • IDEF0 provides a means for communicating and presenting results
  • IDEF0 establishes a forum and a structure for data gathering and knowledge acquisition
  • IDEF0 identifies opportunities for improvements
  • IDEF0 reveals data relationships and incongruities
  • IDEF0 identifies and categorizes information entities which form the foundation for information modeling (IDEF1x)

Q.NO.34: What are the rules of IDEF0?

  • There is always an A-0 context diagram, and its box number is always 0. This is a strict part of the standard that helps identify the overall description of the system.
  • A non-context diagram has from 3 to 6 boxes. This helps us manage detail.
  • Each box is numbered in its lower right corner, generally going upper left to lower right on the diagram. This gives us a consistent way to lay out the diagram.
  • Arrows have horizontal and/or vertical segments, never diagonal. This makes the diagrams more readable.
  • Each box has at least one control and output. This keeps us from using boxes with little purpose.
  • Only one call arrow is allowed. This is another way to manage detail.
  • Successive detail diagrams are numbered by “building up” diagram and box numbers. This is one of the most important concepts that leads to a collection of easy-to-understand diagrams rather than a single confusing one.
  • Unconnected ends of boundary arrows are identified by their ICOM codes. This helps identify arrows when moving from one diagram to another.
  • Rather than using parallel arrows for the same object. This reduces clutter, and reduces the likelihood that an arrow could be overlooked because it is in another part of the diagram.
  • Arrow: A directed line, composed of one or more arrow segments, that models an open channel or conduit conveying data or objects from source to
  • There are 4 arrow classes: Input Arrow, Output Arrow, Control Arrow, and Mechanism Arrow (includes Call Arrow). See Arrow Segment, Boundary Arrow, Internal Arrow
  • Box: A rectangle, containing a name and number, used to represent a function
  • Context: The immediate environment in which a function (or set of functions on a diagram) operates
  • Decomposition: The partitioning of a modeled function into its component functions
  • Fork: The junction at which an IDEF0 arrow segment (going from source to use) divides into two or more arrow segments. May denote unbundling of meaning
  • Function: An activity, process, or transformation (modeled by an IDEF0 box) identified by a verb or verb phrase that describes what must be accomplished
  • Join: The junction at which an IDEF0 arrow segment (going from source to use) merges with one or more other arrow segments to form a single arrow segment. May denote bundling of arrow segment meanings
  • Node: A box from which child boxes originate; a parent box. See Node Index, Node Tree, Node Number, Node Reference, Diagram Node Number
  • IDEF0 – Function and process modeling
  • Answers the question – WHAT DO I DO?

Q.NO.35: Describe Process Management?

  • A process is a sequence of steps performed by people with the aid of tools and equipment to transform raw material into product
  • Software process management is about successfully managing the work processes associated with developing, maintaining, and supporting software products and software-intensive systems
  • This concept of process management is founded on the principles of statistical process control
  • These principles hold that, by establishing and sustaining stable levels of variability, processes will yield predictable results
  • Controlled processes are stable processes, and stable processes enable you to predict results
  • This, in turn, enables us to prepare achievable plans, meet cost estimates, and scheduling commitments, and deliver required product functionality and quality with acceptable and reasonable consistency
  • If a controlled process is not capable of meeting customer requirements or other business objectives, the process must be improved.

 Q.NO.36: What is continuous and staged representations and their advantages

Staged Representation

  • The staged representation is the approach used in the Software CMM. It is an approach that uses predefined sets of process areas to define an improvement path for an organization. This improvement path is described by a model component called a maturity level
  • A maturity level is a well-defined evolutionary plateau toward achieving improved organizational processes

Advantages of Staged Representation

  • Provides a roadmap for implementing
  • Groups of process areas
  • Sequencing of implementation
  • Familiar structure for those transitioning from the SW-CMM

Continuous Representation

  • The continuous representation is the approach used in the SECM and the IPD-CMM. This approach allows an organization to select a specific process area and improve relative to it
  • The continuous representation uses capability levels to characterize improvement relative to an individual process area

Advantages of Continuous Representations

  • Provides maximum flexibility for focusing on specific process areas according to business goals and objectives
  • Familiar structure for those transitioning from the systems engineering community

Q.NO.37: Explain process area “Supplier agreement management” of CMM level 2. [10 Marks] [Page 106]

The purpose of Supplier Agreement Management (SAM)

  • The purpose of Supplier Agreement Management (SAM) is to manage the acquisition ofproducts from suppliers
  • Specific goals for this process area
  • SG1 Establish Supplier Agreements
  • SG2 Satisfy Supplier Agreements

SG1 Establish Supplier Agreements – Specific Practices

  • SP 1.1 Determine Acquisition Type
  • SP 1.2 Select Suppliers
  • SP 1.3 Establish Supplier Agreements

SG2 Satisfy Supplier Agreements

  • SP 2.1 Execute the Supplier Agreement
  • SP 2.2 Monitor Selected Supplier Processes
  • SP 2.3 Evaluate Selected Supplier Work Products
  • SP 2.4 Accept the Acquired Product
  • SP 2.5 Transition Products

Supplier Agreement Management (SAM)

  • This process area does not apply to projects where the supplier or his employee is integrated into the project team, uses the same processes, and reports to the same management as the product developers/project members
  • If the supplier or his employees are directly incorporated into the project team, and the employee is treated just like any other member of the team (except that his paycheck is signed by the supplier organization), then this PA does not apply to you
  • If your organization does not have external suppliers (including contractors providing services) this process area may be not applicable for your organization
  • However, considering the expanded nature of the model, this N/A seems less and less likely

Q.NO.38: Explain Process Area “Process and Product Quality Assurance” [Page 109]

  • The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products
  • The specific goals for this process area are
  • SG1 Objectively Evaluate Processes and Work Products
  • SG2 Provide Objective Insight

SG1 Objectively Evaluate Processes and Work Products – Specific Practices

  • SP 1.1 Objectively Evaluate Processes
  • SP 1.2 Objectively Evaluate Work Products and Services

SG2 Provide Objective Insight – Specific Practices

  • SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues
  • SP 2.2 Establish Records

Things People Forget

  • You also need someone to independently review your QA activities and results. This review can be done by another organization in your company, outside your own organization, or by companies that specialize in performing IV&V or other formal external audits. Some organizations also use the SCAMPI appraisal itself as part of this external review

Process and Product Quality Assurance

  • The generic practice that most closely matches this PA is GP 2.9 Objectively Evaluate Adherence
  • Process and Product Quality Assurance includes providing a strategy and procedures for objectively evaluating processes and products; identifying personnel to fulfill this role objectively; reporting quality issues and noncompliance; and producing reports that provide verification that quality reviews were conducted and their results

Q.NO.39: Time management strategies in PSP

Time Management Strategies

  • Always define your objectives as clearly as possible
  • Written goals, which can be reviewed regularly
  • Long term goals should impact daily activities
  • Without a goal or object, people tend to just drift personally and professionally
  • Analyze your use of time
  • What is the most important use of my time, right now?
  • Have a plan
  • Successful people make lists constantly
  • Change priorities on a regular basis
  • Action plan analysis
  • Problems will occur
  • A good plan identifies them early and seek out solutions
  • Good time management enables you to measure the progress towards your goals
  • What you can measure, you can control
  • Keep discussion on commitments short and sweet and move to PSP process levels