CS724 — Midterm Summary (Lectures 1–22)

📘 Lecture 1 — Software Process Improvement

📖 Overview: This lecture introduces the foundational concepts of software process improvement, explaining what processes are and why they are essential for managing complexity and reusing knowledge. It explores the nature of software processes, their management through statistical control, process modeling, and the systematic steps required to improve software development practices.

🗂️ Topics Covered

The lecture covers the course objectives, defining processes and software processes with examples, explaining software problems as technical vs. systemic, detailing process management based on statistical process control and measurement, describing process models and their variations, and outlining process improvement objectives, planning, and the six-step improvement cycle.

📝 Lecture Summary

Objectives of This Course

The course aims to introduce students to the basics of software process and process improvement. It will teach activities and issues in software process engineering, different improvement approaches, the concept of measurements in processes, and advanced research topics. Students will also explore local industry to understand and suggest improvement strategies.

Processes

Processes are essential mechanisms for coping with complexity in all aspects of life. Descriptions of processes are very important because they allow knowledge to be reused.

What is a Process?

A process is a documented way to solve a problem, allowing others to reuse that solution. Once someone has worked out how to solve a problem, they can document the way in which that solution was derived as a process.

📌 Examples of Processes:

• An instruction manual for a kitchen dishwasher describes the process of using that machine to clean dishes.
• A cookery book describes processes to prepare and cook meals.
• A bank's procedures manual describes processes for agreeing to a personal loan or correcting errors.
• A quality manual for software development describes the processes to assure the quality of the software, including standards for quality checking.

Software Processes

Software Problems can be technical (needing a technical solution, easy to solve) or systemic (difficult to solve, needing a process/management solution).

Solution to Software Problems involves treating the software task as a process that can be controlled, measured, and improved. It requires relating tasks, tools, and methods with the skill, training, and motivation of the people involved.

Software Processes are the set of tools, methods, and practices that people use to produce software and associated products like project plans, design documents, code, test cases, and user manuals. 💡 Why this matters: Recognizing that people are the most important part of an organization is crucial for process success.

Characteristics of Software Processes include requiring creativity, interactions between a wide range of people, engineering judgment, background knowledge, and experience.

📌 Examples of Software Processes:

• Software engineering development process (SDLC)
• Requirements engineering process
• Quality assurance process
• Change management process
• Design process

Process Management

Basic Concepts: The objectives of software process management are to produce products according to plan while simultaneously improving the organization's capability to produce better products. The basic principles are those of statistical process control.

A process is stable or under statistical control if its future performance is predictable within established statistical limits. When a process is stable, repeating work in roughly the same way will produce roughly the same result. To obtain consistently better results, the process must be improved. If a process is not under control, sustained progress is impossible until it is.

The basic principle behind statistical control is measurement. Lord Kelvin stated that when you can measure and express things in numbers, you know something about it; without numbers, knowledge is meager.

However, numbers must properly represent the process and be well-defined. The mere act of measuring human processes changes them, so measurements must be limited to those with predefined use. Measurements are both expensive and disruptive, and overzealous measuring can degrade the process.

Process Models

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, and no single model gives a complete understanding of the process being modeled.

Variations in Process Models are produced based on anticipated need:

• To help explain how process information has been organized.
• To help understand and improve a process.
• To satisfy some quality management standard.

Types of Process Model:

• Coarse-grain activity models: Provide an overall picture of the process, describing the context of different activities but not how to enact the process.
• Fine-grain activity models: More detailed models of a specific process, used for understanding and improving existing processes.

Enactment of Processes: Different people usually enact the same process in different ways due to different backgrounds and experience. Experienced people may change the order of stages, while inexperienced people follow the stages as described.

Process Improvement

Process Improvement Objectives include quality improvement, schedule reduction, and resource reduction.

Process Improvements Planning requires asking:

• What are the improvement goals?
• How can we introduce process improvements to achieve these goals?
• How should improvements be controlled and managed?

Six Steps to Software Improvements:

1. Understand the current status of development processes.
2. Develop a vision for the desired process.
3. Establish a list of required process improvement actions in order of priority.
4. Produce a plan to accomplish the required actions.
5. Commit the resources to execute the plan.
6. Start over at step 1.

Process Maturity Levels are: Initial, Repeatable, Defined, Managed, and Optimizing.

⭐ Key Takeaways

The most critical concept is that treating software development as a measurable, controllable process is essential for systematic improvement. Statistical process control requires a stable process before improvement can occur, and measurement is the foundation for this control. Different stakeholders may need different process models (coarse-grain vs. fine-grain), and process enactment varies based on individual experience. Finally, the six-step improvement cycle emphasizes that process improvement is a continuous, iterative activity that must be planned and managed.

🧠 Quick Revision Questions

1. What is the fundamental difference between a technical software problem and a systemic software problem?
2. According to the lecture, why is measurement considered the basic principle behind statistical process control?
3. What is a process model, and why might multiple models of the same process be necessary?
4. What is the difference between a coarse-grain activity model and a fine-grain activity model?
5. List the six steps involved in the software process improvement cycle.

📘 Lecture 2 — Software Quality Assurance

📖 Overview: This lecture defines software quality and explains why it is critical for business success. It introduces the Software Quality Assurance (SQA) group, its goals, skills, responsibilities, and the formal technical review process used to ensure quality. The lecture concludes with guidance on proper reporting structures for SQA to maintain its independence and effectiveness.

🗂️ Topics Covered

The lecture begins by defining software quality and its business importance, including the escalating cost of finding defects late. It then introduces the SQA group, its goals, pictorial process, required skills, and role as an independent monitor. Key pitfalls for SQA are listed, followed by specific SQA responsibilities. The core of the lecture details the formal technical review (FTR) process: its objectives, what it is not, participant roles, and the five-step review lifecycle (planning, meeting, report, rework, follow-up). Finally, the correct SQA reporting structure is emphasized.

📝 Lecture Summary

Quality and its need

Software quality is defined by low levels of defects when deployed (ideally approaching zero) and high reliability (running without crashes or strange results). The need for quality is driven by several business benefits: it reduces time to market for new products, enhances market share, minimizes “scrap and rework” expenses, attracts and keeps top-gun personnel, and minimizes the risks of serious litigation, operating failures, delays, or even bankruptcy. 💡 Why this matters: The lecture graphically shows that the cost to find and fix a defect escalates dramatically as you move from requirements (cheapest) to operations (most expensive), making early quality efforts a critical economic decision.

🔑 Definition — Software Quality Assurance (SQA): An active and independent group within every organization devoted to assuring the quality of software products.

📐 Key Concept — Cost to Find and Fix a Defect: The earlier a defect is found in the software lifecycle, the cheaper it is to fix. Finding a defect during operations is exponentially more expensive than finding it during requirements.

SQA tasks

The goals of SQA are: (1) to improve software quality by appropriately monitoring both the software and the development process that produces it, (2) to ensure full compliance with established standards and procedures, and (3) to ensure any inadequacies in the product, process, or standards are brought to management’s attention so they can be fixed. The SQA process is depicted as taking inputs from standards and development, processing them with SQA, and producing outputs that feed back into management and development.

For SQA tasks, the group must review all development and quality plans for completeness, participate as inspection moderators in design and code inspections, review all test plans for adherence to standards, review a significant sample of all test results, periodically audit SCM (Software Configuration Management) performance, and participate in all project quarterly and phase reviews, registering non-concurrence if standards are not met.

SQA group skills and responsibilities

The skills of an SQA group member include knowledge of statistical methods, quality control principles, the software process, and an ability to deal effectively with people in contentious situations.

The role of SQA is not to make quality themselves, but to monitor how the software project groups perform their quality responsibilities. The people responsible for the software projects are the only ones who can be held responsible for software quality. The lecture warns of key pitfalls: (1) It is a mistake to assume SQA people themselves can do anything about quality; (2) an SQA group does not ensure standards are followed; (3) SQA will be ineffective unless management periodically demonstrates support; (4) SQA and development will not work together unless line management requires SQA to resolve issues with project management before escalation.

SQA Reviews

A review is defined by IEEE Std. 610.12-1990 as a process or meeting during which a work product is presented to project personnel, managers, users, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, and test readiness review.

The objectives of Formal Technical Reviews (FTRs) are: uncover errors in function, logic, or implementation; verify the software meets its requirements; ensure representation according to predefined standards; achieve uniform development; make projects more manageable; transfer ownership from individual to group; serve as a training ground for junior engineers; and serve as a means of corporate backup.

💡 Why this matters: Technical reviews are not a project budget summary, scheduling assessment, overall progress report, or a mechanism for reprisal or political intrigue. They are strictly focused on the technical quality of the work product.

Review Roles include the Facilitator, Author, Recorder, Reviewer, and Observer. The Facilitator provides background, encourages participation, keeps the meeting focused, and gains consensus on problems. The Author is responsible for the readiness and distribution of material, schedules the review, selects participants, determines entry criteria, and provides information to clarify issues. The Recorder collects and records each defect, develops an issues list, records meeting decisions, prepares and publishes minutes, and tracks action items. The Reviewer spends time prior to the meeting reviewing information, makes notes of defects, identifies strengths, and insists on clarifying issues. The Observer is a new member who learns the product and observes techniques.

The Review Activities follow a five-step process:

1. Review Planning: Distribute the review package one week in advance, including the document, agenda, roles, exit/entrance criteria, objective, names of attendees, location, date/time, classification list (defect type, origin, severity), and handling procedures.
2. Review Meeting: The facilitator begins with an introduction. The author explains materials while reviewers raise issues. Valid problems are classified and recorded with names of responsible individuals and timelines. Guidelines for reviewers include: be prepared, review the product not the producer, keep tone mild, stick to the agenda, raise issues don’t resolve them, and avoid style discussions. At the end, attendees decide to accept the product, reject it, accept it provisionally, or hold a follow-up review.
3. Review Report: Published by the recorder within a week, it includes the elements reviewed, participant names, specific inputs, unresolved items, escalation items, action items/ownership/status, and suggested recommendations.
4. Rework: The project manager ensures all defects identified are fixed and retested.
5. Follow-up: All discrepancies are confirmed resolved, exit criteria are met, and lessons learned are documented.

🔑 Definition — Review: A process or meeting during which a work product is presented for comment or approval (IEEE Std. 610.12-1990). 🔑 Definition — Formal Technical Review (FTR): A specific type of review focused on uncovering errors and ensuring quality.

SQA Reporting

The SQA group must have a clear and independent SQA reporting structure to be effective. SQA should not report to the project manager. It should report somewhere within the local office and division office, with typically no more than one management position between SQA and the senior location manager. SQA should always have a “dotted-line” relationship to a senior corporate quality executive. Whenever possible, SQA should report to someone with a vested interest in software quality, like the staff head responsible for field service.

⭐ Key Takeaways

The primary purpose of the SQA group is to monitor the development process and ensure compliance with standards, not to directly improve quality themselves. Formal Technical Reviews are a cornerstone of quality assurance, with a structured process of planning, meeting, reporting, rework, and follow-up, and distinct roles for facilitator, author, recorder, reviewer, and observer. The most critical skill for reviewers is to review the product, not the producer, focusing on technical correctness rather than style. Proper SQA independence is crucial; SQA must report outside the project management chain, ideally to a senior location or corporate quality executive. Finally, the cost of finding and fixing a defect increases exponentially as it moves through the lifecycle, making early quality activities economically vital.

🧠 Quick Revision Questions

1. What are the three main goals of the Software Quality Assurance (SQA) group?
2. List the five distinct participant roles in a Formal Technical Review (FTR) and name one primary responsibility of the Recorder.
3. Explain the difference between the role of SQA and the role of the software project teams in achieving software quality.
4. What should be the proper reporting structure for an SQA group to ensure its independence and effectiveness?
5. Name the five sequential activities of a Formal Technical Review (FTR).

📘 Lecture 3 — Configuration Management

📖 Overview: This lecture introduces software configuration management (SCM) as the art of coordinating software development to minimize confusion caused by inevitable changes. It explains why change happens, how it creates chaos if uncontrolled, and presents the five core SCM functions—identification, version control, change control, configuration audit, and status accounting—that together provide visibility, control, and traceability throughout the software process.

🗂️ Topics Covered

The lecture begins by discussing change as an inevitable part of software development and its sources, then defines confusion that arises from uncontrolled change. It introduces configuration management and software configuration management (SCM), explains the purpose of SCM activities, and defines the concept of a software configuration and baseline. The five SCM functions are then explained in detail: identification, version control, change control (including the formal change control process, change control authority/board, engineering change orders, access and synchronization control), configuration audit, and status accounting/reporting. The lecture concludes with an overview of SCM and the importance of management commitment.

📝 Lecture Summary

Change

Changes will happen in all work products and during all processes during software development and maintenance. Change increases the level of confusion among software engineers who are working on a software project.

Sources of Change:

• New business or market conditions dictate changes in product requirements or business rules
• New customer needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by computer-based system
• Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure
• Budgetary or scheduling constraints cause a redefinition of the system or product

Why All This Modification? As time passes, all constituencies know more about what they need, which approach would be best, and how to get it done and still make money. Most changes are justified.

Confusion

Confusion arises when changes are not:

• Analyzed before they are made
• Recorded before they are implemented
• Reported to those who need to know
• Controlled in a manner that will improve quality and reduce errors

We need to minimize this confusion, or else our projects will get out of control.

Configuration Management

The art of coordinating software development to minimize confusion is called configuration management. The goal is to maximize productivity by minimizing mistakes.

Software Configuration Management

SCM is a set of activities designed to control change by:

• Identifying the work products that are likely to change
• Establishing relationships among them
• Defining mechanisms for managing different versions of these work products
• Controlling the changes imposed
• Auditing and reporting on the changes

💡 Why this matters: SCM is an umbrella activity applied throughout the entire software process, not just at the end.

Purpose of SCM Activities:

• Identify change
• Control change
• Ensure that the change is being properly implemented
• Report changes to others who may be interested

SCM Provides Cover Against:

• Lack of visibility
• Lack of control
• Lack of traceability
• Lack of monitoring
• Uncontrolled change

Software Configuration: The items that comprise all information produced as part of the software process are collectively called a software configuration. These include:

• Computer programs (source and executable)
• Documents that describe the computer programs
• Data

Software configuration items will grow. You must baseline every software configuration item.

Baseline every Software Configuration Item

How to Manage Change? A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change.

🔑 Definition — Baseline (IEEE Std. No. 610.12-1990): A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

Before a software configuration item becomes a baseline, changes may be made quickly and informally. However, once a baseline is established, changes can be made, but a specific, formal procedure must be applied to evaluate and verify each change request. In the context of software engineering, a baseline is a milestone in the development of software that is marked by the delivery of one or more software configuration items and approval of these software configuration items is obtained through a formal technical review or inspection.

Typical work products that are base-lined are:

• System specification
• Software requirements
• Design specification
• Source code
• Test plans/procedures/data
• Operational system

SCM Questions

1. How does an organization identify and manage the many existing versions of a configuration item in a manner that will enable change to be accommodated efficiently?
2. How does an organization control changes before and after software is released to a customer?
3. Who has the responsibility for approving and ranking changes?
4. How can we ensure that changes have been made properly?
5. What mechanism is used to apprise others of changes that are made?

SCM Functions

The five SCM functions are:

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. 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.

Change Control Process: Proposed changes to software work-products are reviewed, then subjected to the agreement of project participants, and finally incorporated into the currently approved software configuration. This requires that a separate authority, which reviews and approves all change requests, be established for every project from among the project participants. This authority is known as Change Control Authority or Change Control Board (CCA/CCB). A CCA/CCB plays an active role in the project level change control and formal change control activities. Typically, a CCA consists of representatives from software, hardware, database engineering, support, and marketing, etc., depending on the size and nature of the project.

For every change request, the change control authority/board assesses the:

• Technical merit
• Potential side effects
• Overall impact on other configuration items and system functions
• Projected cost of the change

The CCA/CCB has the authority to approve or reject a change request. It can delay the request for consideration and inclusion in the next iteration also. For every approved change request, an Engineering Change Order (ECO) is generated, which describes:

• The change to be made
• The constraints that must be respected
• The criteria of review and audit

The formal change control process is very elaborate and comprehensive. The “check-in” and “check-out” activities implement two important elements of change control:

• Access control
• Synchronization control

The Change Control Process (Step-by-Step):

1. Need for change is recognized
2. Change request from user
3. Developer evaluates
4. Change report is generated
5. Change control authority decides
   • If approved: Request is queued for action → Assign people to SCIs → Check-out SCIs → Make the change → Review/audit the change → Establish a “baseline” for testing → Perform SQA and testing activities → Check-in the changed SCIs → Promote SCI for inclusion in next release → Rebuild appropriate version → Review/audit the change → Include all changes in release
   • If rejected: Change request is denied, user is informed

Access and Synchronization Control: Access control governs which software engineers have the authority to access and modify a particular configuration item. Synchronization control helps to ensure that parallel changes, performed by two different people, don’t overwrite one another. We need to implement both.

💡 Why this matters: The check-in/check-out mechanism is the practical implementation of change control, ensuring no work is lost when multiple developers work on the same files.

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.

Key questions addressed by the configuration audit:

• 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” in the SCI? Have the change date and 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. It answers:

• What happened?
• Who did it?
• When did it happen?
• What else will be affected?

Management Commitment for SCM

Successful SCM implementation requires management commitment. The lecture includes a visual showing that management commitment is needed for policies, process, and tools. The SCM process itself consists of establishing baselines, configuration status accounting, configuration identification, change control, and configuration auditing.

Summary

• Software configuration management is an umbrella activity that is applied throughout the software process
• SCM identifies, controls, audits, and reports modifications that invariably occur while software is being developed and after it has been released
• SCM saves a project from total chaos

⭐ Key Takeaways

Students must remember that change is inevitable in software development and uncontrolled change leads to confusion and project chaos. Configuration management is the systematic art of minimizing this confusion through five core functions: identification, version control, change control (including the formal process with CCA/CCB and ECOs), configuration audit, and status accounting. The baseline is a critical concept—a formally reviewed product that serves as a foundation for development and can only be changed through formal procedures. The check-in/check-out mechanism with access and synchronization control is the practical tool for implementing version and change control, preventing parallel edits from overwriting each other. Ultimately, SCM is an umbrella activity applied throughout the entire software life cycle that requires management commitment to succeed.

🧠 Quick Revision Questions

1. What are the five functions of software configuration management?
2. Define a baseline according to the IEEE standard, and explain how the change process differs before and after a baseline is established.
3. What is a Change Control Authority/Board (CCA/CCB) and what factors does it assess when evaluating a change request?
4. What is the difference between access control and synchronization control in the context of SCM?
5. What are the five sources of confusion that arise when changes are not properly managed?

📘 Lecture 4 — Introduction to Project Planning

📖 Overview: This lecture introduces the fundamental concepts of software project planning, explaining why planning is crucial for managing complexity and ensuring timely, quality delivery. It covers the logic, goals, and objectives of project planning, then details the key steps: defining software scope, estimation, risk management, scheduling, and control strategy. The lecture emphasizes that planning is an iterative process that refines estimates as requirements become clearer.

🗂️ Topics Covered

The lecture covers the logic of software project planning, its overarching goal and specific objectives, and the five core steps: software scope, estimation, risk, schedule, and control strategy. Within estimation, it details resource and cost estimation, including functional decomposition, estimation techniques, empirical models like COCOMO, and the importance of using multiple techniques. The lecture also addresses feasibility and provides guidance on understanding project scope.

📝 Lecture Summary

Logic of Software Project Planning

Software development is complex and requires careful planning to ensure resources are available at the right time. The plan starts by mapping a route from vague, initial requirements to accurate and precise ones. A conceptual design is developed as the basis for planning, defining the product’s breakdown into units, function allocation, and relationships. A poor conceptual design is almost impossible to recover from. As requirements are refined, resource projections, size estimates, and schedules are also refined. The plan provides the framework for negotiating time and resources throughout the project life-cycle.

💡 Why this matters: Planning is not a one-time event but a continuous cycle of refinement that adapts as understanding of the project grows.

Goal of Project Planning

The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. The ultimate purpose is to ensure the end result gets done on time, with quality.

Objectives of Project Planning

The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. These estimates are made within a limited time frame at the beginning of a project and must be updated regularly as the project progresses. Estimates should attempt to define best-case and worst-case scenarios so that project outcomes can be bounded.

Steps of Project Planning

The five core steps are: Software scope, Estimation, Risk, Schedule, and Control strategy.

Software Scope

Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability. It must be unambiguous and understandable at both management and technical levels. A statement of software scope must be bounded. Good and open communication between developers and the customer is required to define the scope. To understand scope, one must understand the customer’s needs, business context, project boundaries, customer motivation, and likely paths for change, while acknowledging that even with understanding, nothing is guaranteed.

🔑 Definition — Software Scope: The description of the data and control to be processed, function, performance, constraints, interfaces, and reliability that unambiguously defines the work to be done.

Feasibility

Once scope is identified and agreed upon with the customer, it is reasonable to ask: “Can we build software to meet this scope? Is the project feasible?” Often this question is overlooked, leading to serious problems.

Estimation

Estimation involves determining: How much effort? How much time? Resource and time estimation.

🔑 Definition — Estimation: The process of determining the effort and time required to complete a software project.

Cost Estimation

To perform cost estimation, project scope must be explicitly defined. Task and/or functional decomposition is necessary. Historical measures (metrics) are very helpful. At least two different techniques should be used. Uncertainty is inherent in all estimates.

🔑 Definition — Cost Estimation: The process of predicting the resources, effort, and cost associated with a software project.

Project Resources

Project resources include people, reusable software components, and hardware/software tools. Software cost and effort estimation will never be an exact science due to too many variables – human, technical, environmental, and political – that can affect the ultimate cost.

Options for Reliable Cost and Effort Estimates

Options include: delaying estimation until late in the project; basing estimates on similar completed projects; using simple decomposition techniques (like functional decomposition, or “divide and conquer”); or using one or more empirical models for estimation.

Estimation Techniques

Estimation techniques include: past similar projects experience; conventional estimation techniques (e.g., task breakdown and effort estimates, size estimates like Function Points (FP), and tools like Checkpoint); and creating a Task Matrix.

Estimation based on Empirical Models

The general formula for empirical models is: d = f(vᵢ), where d is one of a number of estimated values (e.g., effort, cost, project duration) and vᵢ are selected independent parameters (e.g., estimated Lines of Code (LOC) or Function Points (FP)).

📐 Formula: d = f(vᵢ) → Estimated value is a function of independent parameters like LOC or FP.

COCOMO model

The COCOMO model (Constructive Cost Model) is a specific empirical model used for estimation.

Risk

Risk analysis asks: What can go wrong? How can we avoid it? What can we do about it?

🔑 Definition — Risk: An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.

Schedule

Scheduling asks: How do we allocate resources along the time line? What are the milestones?

🔑 Definition — Schedule: A timeline that allocates resources and defines milestones for project completion.

Control Strategy

Control strategy asks: How do we control quality? How do we control change?

📌 Example: A project team initially estimates a project will take 12 months and require 5 developers. After defining the software scope and using functional decomposition, they refine their estimate to 10 months and 4 developers. This new estimate is incorporated into the schedule, and a control strategy is put in place to track progress against milestones and manage any change requests.

⭐ Key Takeaways

The core of project planning is creating a dynamic, iterative framework to manage complexity and uncertainty, not a static document. The five essential steps are scope, estimation, risk, schedule, and control strategy, which must be executed and refined continuously. Estimation is inherently uncertain, so it’s critical to use multiple techniques (e.g., decomposition and an empirical model like COCOMO), and to always define best-case and worst-case scenarios. A clear, bounded, and mutually understood software scope with the customer is the foundation for all subsequent planning, and feasibility must be explicitly assessed. Finally, the plan’s ultimate goal is to provide a strategy for controlling, tracking, and monitoring the project to ensure on-time, quality delivery.

🧠 Quick Revision Questions

1. What is the overarching goal of software project planning, and why is it described as a continuous cycle rather than a single event?
2. List the five core steps of project planning as presented in the lecture.
3. What does it mean for a statement of software scope to be “bounded,” and why is this necessary at the beginning of a project?
4. According to the lecture, what are the four options for generating reliable cost and effort estimates?
5. In the context of empirical estimation models, what does the formula d = f(vᵢ) represent, and what are examples of d and vᵢ?

📘 Lecture 5 — Process Models

📖 Overview: This lecture explores the fundamental concepts of software processes, process models, and the balance between standardization and customization. It explains why defined processes are crucial for managing complex software development and introduces three distinct levels of process models—Universal, Worldly, and Atomic—along with their relationships to policies, procedures, and standards.

🗂️ Topics Covered

The lecture begins by establishing why a software process is needed, then defines what a software process is and acknowledges software engineering as an intellectual, non-routine activity. It discusses process trade-off factors and the conflicting needs for process standardization and customization, introducing the concept of a process architecture. Key definitions for software engineering process, process architecture, and process model are provided. The lecture categorizes software process models into three levels: Universal (U), Worldly (W), and Atomic (A), explaining each level’s characteristics and problems. It details the relationships between these levels, mapping U models to policies, W models to procedures, and A models to standards/tools. Finally, it covers critical software process issues like quality, product technology, requirements instability, and complexity.

📝 Lecture Summary

Why Software Process?

Software development can be exceedingly complex, with many alternative ways to perform tasks. There is a need for an organized set of activities, which when performed accurately, will result in an orderly development effort.

Software Process

A defined process can help guide software professionals through tasks in an orderly way. This results in the establishment of a process definition they can understand. This enables professionals to better understand what they should do, what they expect from co-workers, and what they are expected to provide in return. This allows them to focus on their jobs and acts as a contract between co-workers. Operational definitions are "something everyone can communicate about and work to" – Deming. They provide organizations with a consistent working framework while permitting individual adjustments to unique needs.

Software Engineering

Software engineering is not a routine activity that can be structured like repetitive manufacturing. It is an intellectual process that must dynamically adjust to the creative needs of the professionals and their tasks; a trade-off is needed.

Process Trade-off Factors

Since software projects have differences, their software engineering processes must have differences as well. In the absence of a universal software engineering process, organizations and projects must define processes that meet their own unique needs. The process used for a given project must consider the experience level of the members, current product status, and the available tools and facilities.

Process Standardization

There is a need to balance standardization with individual creativity, as seen in examples like music and artistic painting. Process standardization helps to reduce the problems of training, review, and tool support. With standard methods, each project's experiences can contribute to overall process improvement. Process standards provide the basis for process and quality measurements. Since process definitions take time and effort to produce, it is impractical to produce new ones for each project.

Customization and Standardization

The conflicting needs for customization and standardization can be resolved by establishing a process architecture, which consists of a standard set of unit or "kernel" process steps with rules for describing and relating them. Customization is achieved through appropriate interconnections of these standard elements into tailored process models.

Software

The term software refers to a program and all the associated information and materials needed to support its installation, operation, repair, and enhancement.

Definitions

🔑 Software Engineering Process: The total set of software engineering activities needed to transform a user's requirements into software. 🔑 Software Process Architecture: A framework within which project-specific software processes are defined. 🔑 Software Process Model: One specific embodiment of a software process architecture.

Software Processes

Software processes can be categorized according to the level of details organized in these processes. Some can be high-level (with little detail), while others can be low-level processes with lots of details. This analysis results in three levels of software process models: Universal or U Process Models, Atomic or A Process Models, and Worldly or W Process Models.

Universal or U Process Models

U process models provide high-level overviews. Traditional Waterfall, Spiral, and other later process models fall in this category and are typically task-oriented. The fundamental problem with simplistic U-level models is that they do not accurately represent what is really done. Traditional process models are extremely sensitive to task sequence, so simple adjustments can destroy the entire framework. For example, the waterfall model provides a very simplified view of activities, which can lead to inaccurate model development. 📌 Example: The lecture includes a diagram of a "Version of Waterfall Model" which shows a linear sequence of steps. 📌 Example: The lecture includes a diagram of a "Spiral model of the software process" which shows an iterative process with risk analysis at each cycle.

Problems with Universal Model

Problems arise from an over-emphasis on modeling tasks. It limits human flexibility and tends to arbitrarily impose rigidity. It becomes progressively less helpful as the number of possible task sequences increases. The model becomes very difficult to understand. Such process rigidity can cause serious problems for process automation, project management, or contract administration. The question is not "what is the right way to model the process?" but "what is the most appropriate way to model this process for this purpose?"

Worldly or W Process Models

W process models are most useful to practicing software engineers. They guide the sequence of their working tasks and define task prerequisites and results. They look like procedures and 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 detailed. 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 detail must be determined by their use. For example, an experienced developer repeating known tasks will not need as detailed a standard as a new trainee. When a task is to be automated, 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 abstractions in the higher level "W" or "U" process models.

Relations of Software Process Models

U process models embody policies; W process models embody procedures; and A process models embody standards and/or tools.

Policies

Policies establish a high-level framework and set of principles that guide the overall behavior of organizations. They are particularly helpful in unanticipated circumstances where no precedents have been established.

Policy-level Statements

Some policy-level statements include:

• All work will be subjected to an inspection before it is incorporated in a baseline.
• The quality of each product, at the time of new shipment, shall be better than its predecessor or leading competitor.
• All commitments for software cost or delivery will be supported by a documented and approved software engineering plan.
• Quality Assurance (QA) will review the software development process to assure senior management that the work is done according to established standards and procedures and in conformance with the intent of the stated policies.

“W”-level, Procedures

At the "W"-level, procedures are established to implement the policies. This W-level process model refers to any available Atomic-level standards that define precisely how tasks are to be performed. At the W-level, a procedure might define the points at which Quality Assurance reviews are to be conducted and how resulting issues are to be handled. This might specify what percent of work is to be reviewed, how statistical samples are to be selected, and whether, when, and how SQA independently tests or monitors the software engineering work.

Atomic level standards

Atomic level standards serve as the basis for directing the work and for the SQA review. For example, a code inspection standard would specify what code is to be reviewed, when, the methods to be used, the reports to be produced, and the acceptable performance limits. The developers would use this standard to guide their actions, and the SQA people would review their actions and work products against this standard.

Critical Software Process Issues

The key issues include Quality, Product technology, Requirements instability (including unknown, unstable, or misunderstood requirements), and Complexity.

⭐ Key Takeaways

The most critical concept from this lecture is the three-tiered structure of software process models: Universal (U) models for high-level policies, Worldly (W) models for detailed procedures guiding practitioners, and Atomic (A) models for precise standards and tool definitions. You must understand that a single universal model is inadequate because software development is an intellectual, non-routine activity that requires a balance between standardization and customization, achieved through a process architecture. Remember that policies provide guiding principles, procedures implement those policies by defining who does what when, and standards provide the precise, repeatable instructions for executing tasks. Finally, be aware that critical issues like requirements instability and complexity directly impact which process model level is most appropriate for a given project.

🧠 Quick Revision Questions

1. What are the three levels of software process models, and what is the primary concern of each level?
2. Why are Universal (U) process models considered problematic for accurately representing real software development work?
3. Explain the relationship between policies, procedures, and Atomic-level standards in the context of the three process model levels.
4. How does a process architecture help resolve the conflicting needs for process standardization and customization?
5. List the four critical software process issues mentioned in the lecture and explain one challenge associated with requirements instability.

📘 Lecture 6 — ETVX: Process Modeling Technique

📖 Overview: This lecture introduces the ETVX (Entry-Task-Verification-Exit) process modeling technique, which provides a structured way to define and represent software process activities. It explains how ETVX can be used to model processes at different levels of abstraction (Universal, Worldly, Atomic) to address critical software process issues like quality and requirements instability.

🗂️ Topics Covered

The lecture begins by identifying critical software process issues including quality, product technology, requirements instability and complexity. It then introduces the process framework with Universal, Worldly, and Atomic levels, defines the unit cell as the basic element of process architecture, explains entry and exit conditions for unit cells, details the ETVX modeling technique with its four attributes (Entry, Task, Verification, Exit), discusses characteristics of ETVX as a task-based model, and provides an example using design, implementation, and test activities with unit cell definitions.

📝 Lecture Summary

Critical Software Process Issues

Organizations face several critical software process issues that need to be addressed. These include quality, product technology, requirements instability (which encompasses unknown requirements, unstable requirements, and misunderstood requirements), and complexity.

💡 Why this matters: These issues directly impact project success and product quality, making it essential to have defined processes to manage them.

Process Framework

Organizations that face the issues of quality, product technology, requirements stability, and/or complexity need to define ways to address them. A process architecture permits these organizations to represent and manipulate the process at the U level (Universal) and then selectively to refine it to the W level (Worldly) and A level (Atomic). The Universal, Worldly, and Atomic levels of process models can be presented in the process framework, which gives established policies, procedures and standards. The architectural framework of a process helps in providing a definition for basic elements, how they interact, and how they are decomposed into increasing level of detail.

📐 Formula: Process Architecture → U level → W level → A level (decreasing abstraction, increasing detail)

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.

🔑 Definition — Unit Cell: The basic element of process architecture that accomplishes a specified task and is uniquely identified.

Entry Conditions of a Unit Cell

Each cell has required entry conditions specified for task initiation that include the inputs (one or more with their sources). Task standards, procedures, methods, responsibilities, and required measures are also defined.

Exit Conditions of a Unit Cell

Exit conditions define the results produced, their level of validation, and any post-task conditions. Cell feedback refers to any data provided to or received from other stages in the process.

Basic Unit Cell Specification

The basic unit cell specification includes:

• Specification Activities
• Entry Conditions: To be met before task initiation
• Exit: Results produced
• Feedback In: Feedback from other stages
• Feedback Out: Feedback to other stages
• Task: What is to be done (by whom, how, and when, including standards, procedures, and responsibilities)
• Measurements: Task (activities, resources, time), output (number, size, quality), and feedback (number, size, quality) measures

ETVX

ETVX is a modeling language introduced by IBM in 1980. ETVX stands for Entry, Task, Verification, and Exit.

🔑 Definition — ETVX: A process modeling technique introduced by IBM in 1980 used to illustrate effective process performance, expressed as a set of interconnected activities each with four sets of attributes.

Objectives of ETVX

The objective of ETVX is to illustrate the effective process performance. It can be applied to as low a level as required to control process. A model developed in ETVX is expressed as a set of interconnected activities each of which has four sets of attributes.

ETVX Representation

• Entry (E): The Entry section defines the entry criteria that must be satisfied for the process to be initiated, and lists the work products that must be available as inputs to the process.
• Task (T): The Task section defines what must be done to accomplish the process objectives. It indicates who is responsible for performing the process, the actions to be performed, and the procedures to be followed.
• Verification (V): The Verification section defines steps for verifying that the process has been properly executed, and that the associated work products meet project objectives.
• Exit (X): The Exit section defines the exit criteria that must be satisfied for the process to be terminated. The exit criteria usually define completion and verification work products, in terms of qualitative aspects of the products.

📐 Formula: ETVX = Entry + Task + Verification + Exit → Complete process activity definition

ETVX Model

An ETVX model indicates the relationship and flow among the four aspects of an activity and between activities. The notion of formal entry, exit, and criteria go back to the evolution of the waterfall development process. The idea is that every process step, inspection, function test, or software design has a precise entry and exit criteria.

💡 Why this matters: This formal structure ensures that no activity begins without proper preparation and no activity ends without proper validation.

Characteristics of ETVX

• ETVX is a task-based model
• Each task must be explicitly defined
• The basic cells can be combined to create process
• Uses a "bottom-up" approach (A level to W and U levels)

📌 Example: The generic activities of different process models from the U-level's perspective can be listed as "design", "implementation", and "test". When these activities are broken into more detail, however, significant differences show up. Even with all these variations at the W level, however, many software activities can be relatively standardized across different projects. It is thus possible to establish some basic process cells that can be interconnected in different ways to meet project-unique needs. The detailed structures of these standard cells are then further defined by A-level models as needed.

Unit Cell Definitions for Process Model

The following unit cell definitions show how the ETVX technique applies to a developmental process:

Cell 001 (Design)

• Entry: Approved requirements, changes and development plan
• Exit: Inspected and approved design changes
• Feedback In: Design Issues
• Feedback Out: Requirements Issues
• Task: Design
• Measures: Resources, Product; Changes, Errors, Design, Document Pages

Cell 002 (Implementation)

• Entry: Inspected and approved design and changes
• Exit: Inspected and approved code and changes
• Feedback In: Implementation Issues
• Feedback Out: Requirements and Design Issues
• Task: Implementation, Inspection and Unit test
• Measures: Resources, Product: Changes, Errors, Code, Document Pages

Cell 003 (Testing)

• Entry: Inspected and approved code and changes
• Exit: Inspected, tested and approved software
• Feedback In:
• Feedback Out: Requirements, Design Issues, and Implementation Issues
• Task: Testing: Integration, Function, System, and Acceptance
• Measures: Resources, Product: Changes, Errors, Code, Document Pages, Test Suite

⭐ Key Takeaways

The ETVX technique provides a formal and structured way to model software processes by defining four essential attributes for every activity: Entry criteria, Task procedures, Verification steps, and Exit criteria. The unit cell is the fundamental building block of process architecture, with each cell having clearly defined entry and exit conditions, feedback mechanisms, and measurement criteria. The three levels of process abstraction (Universal, Worldly, Atomic) allow organizations to represent processes at a high level and then refine them into increasing detail as needed. ETVX models use a bottom-up approach, meaning basic cells at the Atomic level can be combined to create higher-level Worldly and Universal process models. Finally, the example of design, implementation, and test cells shows how ETVX can be practically applied to standardize software development activities while allowing flexibility for project-specific variations.

🧠 Quick Revision Questions

1. What are the four attributes of an ETVX model, and what does each attribute define?
2. What is a unit cell, and what are its basic specification components?
3. How does the "bottom-up" approach work in ETVX modeling from Atomic to Universal levels?
4. What are the differences between the entry conditions and exit conditions of a unit cell?
5. In the U-Level developmental process example, what are the entry criteria for Cell 002 (Implementation) and what feedback does it provide to other cells?

📘 Lecture 7 — Application of ETVX

📖 Overview: This lecture demonstrates how the ETVX (Entry Criteria, Tasks, Validation/Verification, Exit Criteria) model is applied to a real software engineering process — specifically, the software inspection process. It breaks down each main activity of an inspection (Preparation, Meeting, Rework, Follow-up, and Data Recording) to show the formal structure required for a defined, measurable, and process-capable activity.

🗂️ Topics Covered

The lecture applies the ETVX model to a selected set of activities within the detailed software inspection process. It covers five main phases of inspection: Preparation, Inspection Meeting, Rework, Follow-up, and Data Recording and Reports. For each phase, the lecture explicitly lists the mandatory entry criteria, tasks to be performed, validation/verification steps, and exit criteria required to complete the activity. It also highlights the data gathered at each stage for process measurement.

📝 Lecture Summary

Preparation

Preparation is the first major activity in the inspection process. The moderator and producer must ensure that the work product is ready and that inspectors have the time and materials necessary to study it. Every inspector must individually identify defects before the meeting.

🔑 Definition — Inspector: A team member who examines the work product to find defects. 🔑 Definition — Producer: The author of the work product being inspected. 🔑 Definition — Moderator: The individual who leads and manages the inspection process.

The entry criteria for preparation are extensive. The overview must be complete, and any open issues must be closed. The producer must confirm the work product is ready, ensures it complies with standards (style guides, templates). All necessary ancillary material (related documents, plans) must be available well in advance. The preparation time must be confirmed and available. Predecessor work products that have already been inspected must be available. The moderator and producer must define the coverage, and the work product must allow easy location of defects. Finally, the moderator must agree the product is inspectable.

The tasks for each inspector are to use their scheduled time to study the material and mark it with questions, concerns, and possible defects (major and minor). Minor defects are recorded on a separate list or clearly noted in the marked material, which is given to the moderator at the start or end of the meeting. Each minor defect must be noted by its location.

🔑 Definition — Major Defect: A defect that could cause a failure in the operation of the software. 🔑 Definition — Minor Defect: A deviation from standards or a cosmetic issue that does not affect operation.

The validation/verification activities ensure the process is followed correctly. The moderator checks the preparation entry criteria and uses the minor defect information to confirm all inspectors prepared. The SQA group audits process records or samples inspections to ensure the procedure was followed. Specific data is gathered during this activity: time spent in preparation, the time period between notification and preparation, the number of rescheduled meetings due to lack of preparation, and the number of major and minor defects found.

💡 Why this matters: The preparation phase is crucial. If inspectors do not prepare properly, the inspection meeting will be inefficient and fail to find defects effectively. The entry criteria ensure the time is not wasted.

The exit criteria state that each inspector must have completed sufficient preparation, the minor defect inputs must be complete, and preparation notes must be recorded.

Inspection Meeting

The inspection meeting is the formal session where the team reviews the work product together, led by the reader.

The entry criteria require that inspection team members are sufficiently present in number and role assignments. Materials must have been available for study, inspectors must have prepared adequately, and they must have submitted their minor defect lists. The meeting scope must be defined, and a recorder, a data recording system, and other roles like the role of the reader must be assigned. The producer must have identified any new potential problem areas.

The tasks follow a defined sequence led by the moderator: a brief introduction, a preparedness check, reading of the work product by the reader, identification of defects by the inspectors, recording of defects by the recorder, and finally, a determination of the disposition of the material by the inspection team. The possible dispositions are:

• Accept the material.
• Accept the material after verification with a follow-up inspector.
• Request the work product to be re-inspected after rework.
• Recommend re-engineering of the work product followed by a new inspection.

Validation/Verification by the moderator and SQA group ensures the meeting was performed correctly. Data gathered includes time spent, time between preparation and meeting, rescheduling information, number of re-inspections, number of defects found, meeting duration, and number of attendees.

🔑 Definition — Disposition: The decision made by the inspection team on the fate of the inspected work product (e.g., accept, re-inspect).

The exit criteria mandate that coverage is complete. Inspection results must fall within expected tolerances for preparation time, meeting time, and defect density. Defects and conduct must be recorded, and the team must concur. Open issues are recorded for follow-up. The moderator appoints someone to do the follow-up. Decisions on re-inspection or re-engineering are reviewed, and process defects are recorded. A timeframe for resolving repairs is set, and the inspection satisfies the criteria to be indicated as "performed".

🔑 Definition — Defect Density: The number of defects found per unit of size (e.g., per page or per KLOC – thousand lines of code).

Rework

After the inspection meeting, the producer fixes the defects. This is the rework phase.

The entry criteria require that the list of defects and open issues is provided to the producer, and that the moderator has met with the producer to review them. The inspection report must be completed and on file.

The tasks for the producer are to repair all accepted defects and resolve open issues. The moderator meets with the producer to discuss resolutions. Change requests are written for any unresolved defects or open issues. The minor defect list or marked work products are used to repair the minor defects.

🔑 Definition — Change Request: A formal proposal for a modification to a baseline work product.

Validation/Verification involves scheduling the follow-up activity where the rework will be verified. The SQA group reviews sample results. Data gathered includes time spent on rework, number of open issues resolved and accepted as defects, and number of open issues that became change requests.

The exit criteria are that the producer resolves all defects and open issues, and that the inspected work product materials are updated to account for repairs.

Follow-Up

The follow-up activity verifies that the rework was done correctly and closes the inspection.

The entry criteria require that rework of defects is complete (fixed or identified with a decision not to fix). The producer must have completed rework for defects and open issues. Change requests are written for unresolved issues, and the moderator concurs with the producer’s decisions.

The tasks involve the moderator and producer discussing and agreeing on compliance. If there is disagreement, the project lead resolves the issue. The producer updates the work product. The moderator completes the inspection report and marks the inspection as closed.

Validation/Verification involves the moderator concurring, the producer reviewing the final report, and the SQA group reviewing it. Data gathered includes time spent on follow-up and number of disputed open issues.

The exit criteria require that any change requests from unresolved issues are submitted. The inspection report is completed and the producer agrees. If necessary, a re-inspection is scheduled, or issues are escalated. The inspection is noted as closed.

Data Recording and Reports

This activity runs concurrently with the others to capture all inspection data.

The entry criteria are that the overview meeting, inspection meeting, and optional analysis meeting have been held.

The tasks are to record data from the overview (if held), from the inspection meeting (including preparation data), from the optional analysis meeting, and during the follow-up activity (including sign-off to close the inspection).

Validation/Verification involves the inspection team verifying data at the end of the meeting, the SQA group reviewing sample reports, and the producer reviewing the moderator’s report. Data considered for this activity includes the effort used for recording and reporting.

The exit criteria require that data is complete and agreed to by the participants, and that data from follow-up is complete and agreed to by the producer and moderator.

⭐ Key Takeaways

The ETVX model transforms an informal activity like a "walkthrough" into a structured, measurable software process. A student must understand that every major inspection phase (Preparation, Meeting, Rework, Follow-up, Data Recording) has its own formal entry criteria, tasks, validation/verification steps, and exit criteria. The moderator is the key role responsible for enforcing these process steps. The goal of the inspection is not just to find defects but to gather data (e.g., time, defect density) to improve the process itself. Finally, the disposition decision – whether to accept, re-verify, re-inspect, or re-engineer – is the critical output of the inspection meeting.

🧠 Quick Revision Questions

1. What is the purpose of the validation/verification step in the ETVX model for each inspection activity?
2. List the four possible dispositions of a work product from an inspection meeting.
3. What specific data is gathered during the Preparation activity, and why is this data important for process improvement?
4. What are the required entry criteria for the Inspection Meeting regarding the inspectors?
5. Describe the difference between a "minor defect" and a "major defect" as defined in the context of the inspection process.

📘 Lecture 8 — IDEF0: Process Modeling Technique

📖 Overview: This lecture introduces IDEF0 (Integration Definition for Function Modeling), a structured methodology for modeling functions, decisions, and activities within systems. It is essential for software process improvement because it provides a rigorous, graphical language to analyze, document, and communicate business processes—both as they currently exist (AS-IS) and as they should be (TO-BE).

🗂️ Topics Covered

The lecture covers the definition and origins of IDEF0 (based on SADT), its purpose in analyzing and communicating system functions, and its core modeling components (functions as boxes, data/objects as arrows). It explains the ICOM (Inputs, Controls, Outputs, Mechanisms) framework, the hierarchical diagram structure starting with the A-0 context diagram, and the fundamental rules and benefits of using IDEF0 for process modeling and improvement.

📝 Lecture Summary

IDEF0

IDEF0 stands for Integration Definition for Function Modeling, a functional modeling methodology for describing manufacturing functions. This functional modeling language is used for the analysis, development, reengineering, and integration of information systems, business processes, or software engineering analysis. IDEF0 is part of the IDEF family of modeling languages in software engineering, built on the Structured Analysis and Design Technique (SADT) . The IDEF0 Functional Modeling method is designed to model the decisions, actions, and activities of an organization or system. In its original form, IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models.

SADT was designed by Douglas T. Ross and SofTech Inc in the 1970s. The purpose of SADT, as defined by the US Air Force, was "to develop a function model method for analyzing and communicating the functional perspective of a system." IDEF0 should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices.

IDEF0 is used to show data flow, system control, and the functional flow of life cycle processes. It is capable of graphically representing a wide variety of business, manufacturing, and other types of enterprise operations to any level of detail. It provides rigorous and precise description, promotes consistency of usage and interpretation, and is well-tested and proven through many years of use by government and private industry. It can be generated by a variety of computer graphics tools, and numerous commercial products specifically support the development and analysis of IDEF0 diagrams and models.

🔑 Definition — IDEF0: A function modeling methodology (part of the IDEF family) based on SADT, used to graphically represent the decisions, actions, and activities of a system, showing data flow, control, and functional flow.

Function Model

A function model is a structured representation of the functions, activities, or processes within the modeled system or subject area. The IDEF family covers different model types: IDEF0 describes function models, IDEF1 describes information models, and IDEF2 describes dynamic models.

IDEF0 Approach

IDEF0 may be used to model a wide variety of automated and non-automated systems. For new systems, it may be used first to define requirements and specify functions, then to design an implementation that meets those requirements. For existing systems, IDEF0 can be used to analyze the functions the system performs and to record the mechanisms (means) by which these are done. The result of applying IDEF0 to a system is a model that consists of a hierarchical series of diagrams, text, and glossary cross-referenced to each other. The two primary modeling components are functions (represented on a diagram by boxes) and the data and objects that inter-relate those functions (represented by arrows).

ICOM

ICOM stands for Inputs, Controls, Outputs, and Mechanisms. This is the core framework for describing the arrows that surround a function box in IDEF0.

IDEF0 Description

• Each activity is described by a verb-based label placed in a box.

• Inputs are shown as arrows entering the left side of the activity box.

• Outputs are shown as exiting arrows on the right side of the box.

• Controls are displayed as arrows entering the top of the box.

• Mechanisms are displayed as arrows entering from the bottom of the box.

• Inputs, Controls, Outputs, and Mechanisms are all referred to as concepts.

• Inputs: Entities which are transformed or consumed by the function to produce outputs.

• Outputs: The data or objects produced by the function.

• Controls: Specify the conditions required for the function to produce correct outputs.

• Mechanisms: Anything which is used to help perform the activity. Upward-pointing arrows identify some of the means that support the execution of the function. Call (downward) arrows enable the sharing of detail between models or between portions of the same model.

🔑 Definition — ICOM: The four arrow classes surrounding an IDEF0 function box: Inputs (left), Controls (top), Outputs (right), and Mechanisms (bottom).

IDEF0 Diagrammatic Notation

IDEF0 is a model that consists of a hierarchical series of diagrams, text, and glossary cross-referenced to each other. The two primary modeling components are: functions (represented on a diagram by boxes) and data and objects that interrelate those functions (represented by arrows).

IDEF0 Process

The IDEF0 process starts with the identification of the prime function to be decomposed. This function is identified on a "Top Level Context Diagram", which defines the scope of the particular IDEF0 analysis. This diagram is known as "A-0" (pronounced "A minus zero"). The A-0 diagram also sets the model scope or boundary and orientation. It shall present brief statements specifying the model's viewpoint and purpose. From this diagram, lower-level diagrams are generated, called a "child" in IDEF0 terminology.

🔑 Definition — A-0 Diagram: The top-level context diagram in IDEF0 that defines the scope, boundary, viewpoint, and purpose of the analysis (box number is always 0).

📐 Diagram: The lecture provides a diagram showing a single box labeled "Perform New Production Design and Process Plan" with inputs (finished design, new part specs), controls (design requirements, engineering constraints), outputs (design, design review, production information), and mechanisms (engineering system, design system). The viewpoint is "Production & Process Engineers" and the purpose is "Specify functions & processes of New Product Design."

📌 Example — Hierarchy: The A-0 diagram is the parent. From it, a "child" diagram is created that decomposes the prime function into its sub-functions (typically 3-6 boxes).

IDEF0 Fundamentals

• Diagrams are based on simple box and arrow graphics, where arrows convey data or objects.
• Text labels describe boxes and arrows, and a glossary and text define the precise meanings of diagram elements.
• Box name shall be a verb or verb phrase (e.g., "Perform Inspection"), while arrows are nouns.
• Gradual exposition of detail: major functions at the top, with successive levels of sub-functions revealing well-bounded detail breakout.
• The limitation of detail to no more than six sub-functions on each successive function (the "3-6 box rule").
• A "node chart" that provides a quick index for locating details within the hierarchic structure of diagrams.

IDEF0 - Rules

1. There is always an A-0 context diagram, and its box number is always 0. This is a strict part of the standard that identifies the overall description of the system.
2. A non-context diagram has from 3 to 6 boxes. This helps manage detail.
3. Each box is numbered in its lower right corner, generally going upper left to lower right on the diagram. This gives a consistent way to lay out the diagram.
4. Arrows have horizontal and/or vertical segments, never diagonal. This makes the diagrams more readable.
5. Each box has at least one control and one output. This keeps from using boxes with little purpose.
6. Only one call arrow is allowed. This is another way to manage detail.
7. Successive detail diagrams are numbered by "building up" diagram and box numbers. This leads to a collection of easy-to-understand diagrams rather than a single confusing one.
8. Unconnected ends of boundary arrows are identified by their ICOM codes. This helps identify arrows when moving from one diagram to another.
9. Use fork and/or join arrows, rather than parallel arrows for the same object. This reduces clutter and reduces the likelihood that an arrow could be overlooked.
10. 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 use. There are 4 arrow classes: Input Arrow, Output Arrow, Control Arrow, and Mechanism Arrow (includes Call Arrow).
11. Box: A rectangle, containing a name and number, used to represent a function.
12. Context: The immediate environment in which a function (or set of functions on a diagram) operates.
13. Decomposition: The partitioning of a modeled function into its component functions.
14. Fork: The junction at which an IDEF0 arrow segment divides into two or more arrow segments. May denote unbundling of meaning.
15. Function: An activity, process, or transformation (modeled by an IDEF0 box) identified by a verb or verb phrase that describes what must be accomplished.
16. Join: The junction at which an IDEF0 arrow segment merges with one or more other arrow segments to form a single arrow segment. May denote bundling of arrow segment meanings.
17. Node: A box from which child boxes originate; a parent box.
18. IDEF0 answers the question: "WHAT DO I DO?"

🔑 Definition — Decomposition: The process of partitioning a modeled function into its component (child) functions, creating a hierarchical diagram structure.

💡 Why this matters: The strict rules of IDEF0 are not arbitrary; they enforce clarity, manage complexity, and ensure that every function and every data flow is meaningful and well-defined, which is critical for process analysis and improvement.

IDEF0 Benefits

• IDEF0 reveals redundant and non-value-added processes.
• IDEF0 documents the AS-IS—the processes, relationships between them, and the logical breakdown of functions into sub-processes and properties for baseline evaluation and further analysis.
• IDEF0 begins the road map from the AS-IS to the TO-BE (future state).
• 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) .

💡 Why this matters: The "AS-IS to TO-BE" journey is central to process improvement. IDEF0 provides the structured documentation of current processes needed to plan and execute that transformation.

IDEF is not a substitute for...

IDEF is not a substitute for thinking, intelligence, or experience, but it can expose their absence.

Modeling Exercise

The lecture suggests building system models for Requirements gathering, analysis, specification, and review processes using IDEF0.

⭐ Key Takeaways

IDEF0 is a rigorous, graphical language for modeling system functions using boxes and arrows, where each box represents a function (labeled with a verb), and arrows represent data or objects arranged as ICOM (Inputs, Controls, Outputs, Mechanisms). The modeling process always starts with an A-0 context diagram that defines the system's scope and purpose, which is then decomposed into child diagrams with 3-6 boxes each, following strict rules like having at least one control and output per box. A key benefit of IDEF0 is its ability to document the current AS-IS process and provide a structured roadmap to the desired TO-BE state, revealing redundancies and opportunities for improvement. Students must remember the ICOM arrow placement (left, top, right, bottom), the naming conventions (boxes = verbs, arrows = nouns), and that IDEF0 answers "WHAT DO I DO?" as a functional modeling tool.

🧠 Quick Revision Questions

1. What does the acronym ICOM stand for in IDEF0, and where is each arrow placed around a function box?
2. What is the name and box number of the top-level context diagram in IDEF0, and what is its purpose?
3. List three distinct rules that govern the creation of IDEF0 diagrams (hint: consider box count, arrow segments, and minimum arrows per box).
4. In IDEF0 terminology, what is the difference between a "fork" and a "join" arrow?
5. What is the core question that IDEF0 (function modeling) is designed to answer about a system?

📘 Lecture 9 — Intro to Process Management

📖 Overview: This lecture introduces the fundamental concepts of process management in software engineering. It explains why understanding your current process is crucial for improvement, traces the evolution from viewing technology as a "silver bullet" to adopting Deming's process-thinking approach, and defines the core responsibilities of process management: define, measure, control, and improve. The lecture emphasizes that stable, predictable processes are the foundation for achieving quality, cost control, and business objectives.

🗂️ Topics Covered

The lecture covers the importance of knowing your current process, the shift from technology-centric to process-centric improvement (Deming's approach), process-thinking principles, the definition of software process management, the four key responsibilities of process management (Defining, Measuring, Controlling, and Improving the process), and critical issues on the road to process improvement including process performance, stability, compliance, capability, and measurement.

📝 Lecture Summary

Why is Important to Know Your Current Process?

Understanding your current process is the first and essential step on the road to process improvement. Without knowing what a process is currently producing, you have no baseline or reference point for measuring the impact of any changes. This knowledge allows you to assess the repeatability of the process and whether it is meeting its needs, establishing a factual starting point for improvement.

Technology Innovations

Initially, software industry improvements were viewed as the "silver bullet" – new technologies like languages, compilers, and CASE tools. While these innovations helped, they did not provide the breakthrough in quality and productivity that was desired. This led the industry to look elsewhere for solutions.

Deming's approach

Other industries, particularly in Japan, adopted the approach of W. Edwards Deming, which was heavily influenced by the work of Walter A. Shewhart. Deming’s approach contends that to be competitive, improve quality, and increase productivity, the following actions are required:

• Focus on the processes that generate products and services.
• Ensure that 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 is an opportunity for improvement. Improvement comes from reducing variation.
• Take variation into account in the decision-making process.

💡 Why this matters: Deming’s approach shifts the focus from blaming individuals to understanding and improving the underlying systems and processes, a core principle of modern quality management.

Process-Thinking Principles

Adopting process-thinking requires a unique relationship within the organization, involving management philosophy, people, and the management of processes. This approach embodies a way of thinking, acting, and understanding data that collectively results in improved quality and productivity. The acceptance of this approach has required the software industry to measure process performance (effectiveness, efficiency, timeliness, predictability, improvements, and product quality) in quantitative terms.

A process is defined as 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. This concept 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 enables achievable plans, meeting cost estimates, and delivering required quality with consistency. If a controlled process is not capable of meeting requirements, it must be improved.

Process Management Responsibilities

The four key responsibilities of process management form a cycle:

1. Define the process
2. Measure the process
3. Control the process (Ensure variability is stable for predictable results)
4. Improve the process

Defining the Process

Defining a software process creates the disciplined and structured environment required for controlling and improving it. Management’s responsibility to define each process also includes responsibilities for implementing and sustaining it.

🔑 Definition — Process Definition: The act of creating a structured, documented sequence of steps and activities for a software process. 💡 Why this matters: A defined process provides a consistent, repeatable foundation. Without a definition, you cannot measure, control, or improve the work because you don't know what the work is supposed to be.

The objectives of process definition are to:

• Design processes that meet business and technical objectives.
• Identify issues, models, and measures that relate to process performance.
• Provide needed infrastructures (methods, people, practices).
• Ensure the organization has the ability to execute and sustain the processes (skills, training, tools, facilities, funds).

Measuring the Process

Measurements are the basis for detecting deviations from acceptable performance and for identifying opportunities for improvement.

The objectives of process measurements are to:

• Collect the data that measure the performance of each process.
• Analyze the performance of each process.
• Retain and use data to:
  • Assess process stability and capability.
  • Interpret observations and analyses.
  • Predict future costs and performance.
  • Provide baselines and benchmarks.
  • Plot trends.
  • Identify opportunities for improvements.

Controlling the Process

Controlling a process means keeping the process within its normal (inherent) performance boundaries – i.e., making the process behave consistently.

This involves a three-step cycle:

1. Measurement: Obtaining information about process performance.
2. Detection: Analyzing the information to identify variations due to assignable causes (special causes).
3. Correction: Taking steps to remove variation due to assignable causes and remove the results of process drift from the product.

The Actions for Process Control include:

• Determine if the process is under control (stable).
• Identify performance variations caused by process anomalies (assignable causes).
• Eliminate the sources of assignable causes.
• Once under control, sustain the process to counteract entropy, reinforcing the use of defined processes through continuing management oversight, measurement, benchmarking, and process assessments.

💡 Why this matters: "Entropy" means processes naturally degrade into ad-hoc, out-of-control states if not actively maintained. Sustaining activities are critical.

Improving the Process

A process may be defined and under control but may not be capable of producing products that meet customer needs. Processes must be technologically competitive, adaptable, and timely.

The objectives of process improvement are to:

• Understand characteristics of existing processes and factors affecting capacity.
• Plan, justify, and implement changes to better meet business needs.
• Assess the impacts and benefits gained compared to the costs of changes.

Issues on the Road to Process Improvement

This section frames the core issues addressed in the rest of the lecture. The first concern is to understand the existing performance. Knowing how a process is performing enables assessment of its repeatability and whether it is meeting its needs.

Process Performance

Process performance answers the question: "What is the process producing now?" with respect to measurable attributes of quality, quantity, cost, and time. Measures of performance quantify and make visible the ability of a process to deliver required qualities. When measurements vary erratically, the process is not in control. To attain control, we must ensure the process has stable variability, without which we cannot predict results.

Process Stability

Process stability answers the question: "Is the process behaving predictably?" We examine stability through the use of process behavior charts that allow us to determine if the process is within limits.

🔑 Definition — Process Stability: The state of a process where its performance is predictable and its variability is consistent due to only common causes of variation.

Three key questions for process managers:

1. Is the process supported such that it will be stable if operated according to the definition?
2. Is the process, as defined, being executed faithfully?
3. Is the organization fit to execute the process?

Process Compliance

Process compliance concerns whether the processes are sufficiently supported, faithfully executed, and if the organization is fit to execute them. Having a stable and compliant process does not mean performance is satisfactory. The process must be capable. Measures of process capability relate the performance of the process to the specifications that the product or process must satisfy.

Process Capability

Process capability answers: "Is the process capable of delivering products that meet requirements?" If a process is not capable, the organization faces the need to continually improve. Understanding the capability of sub-processes is the first step toward process improvement.

Process Improvement

This section asks the core improvement questions: "What can we do to improve performance? What would enable us to reduce variability? What would let us move the mean to a more profitable level?" Resolution of these issues revolves around measurement and analysis of process performance.

Process Measurement

Sequential measurements of quality attributes provide a foundation for process improvement. Measurement creates a corporate memory and aids in answering many questions. It helps evaluate current process and product quality, detect trends, anticipate problems, control costs, reduce risks, and ensure business objectives are met.

Key measurement questions include: What should be measured? How? What is the data telling us? How is our process behaving? What are the signals? How do we know something is a signal? What should we do when we recognize a signal?

⭐ Key Takeaways

For an exam on software process improvement, you must remember the shift from a technology-centric view to Deming's process-thinking approach, which emphasizes fixing the process, not blaming people, and recognizing variation as an opportunity. The four core responsibilities of process management are a cycle: Define, Measure, Control, and Improve. The critical distinction is that a process must be defined and stable (predictable) before it can be meaningfully measured or improved. Finally, a stable process is not necessarily a good one; it must also be capable of meeting its requirements, and understanding this distinction is central to process improvement.

🧠 Quick Revision Questions

1. According to Deming's approach, where should management focus its efforts when a process is performing poorly?
2. What are the four key responsibilities of software process management?
3. What is the relationship between process stability, predictability, and the ability to make achievable plans?
4. Why is it important to first "know your current process" before trying to improve it?
5. Explain the difference between a process that is "stable" and one that is "capable."

📘 Lecture 10 — Introduction to CMM

📖 Overview: This lecture introduces the Capability Maturity Model (CMM), its structure, and the five levels of software process maturity. It explains the state of the software industry in 1984, key process areas (KPAs), common features, and institutionalization, then dives deep into Level 2 (Repeatable) and its six KPAs. This matters because CMM provides a proven framework for improving software process capability, reducing project failures, and enhancing quality and predictability.

🗂️ Topics Covered

The lecture covers the software state-of-the-art in 1984, the Software Engineering Institute (SEI), the five levels of software process maturity, maturity levels and key process areas (KPAs), key process area goals, common features, institutionalization, key practices, CMM structure, and a detailed examination of CMM Level 2 (Repeatable) including its six KPAs: Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management.

📝 Lecture Summary

Software State-of-the-Art in 1984

The lecture begins by describing the chaotic state of software development in 1984. More than half of large software systems were late in excess of 12 months. The average costs of large software systems were more than twice the initial budget. The cancellation rate of large software systems exceeded 35%. The quality and reliability levels of delivered software of all sizes was poor. Software personnel were increasing by more than 10% per year. Software was the largest known business expense which could not be managed.

Software Engineering Institute

The Software Engineering Institute (SEI) is a research facility located in the University of Carnegie Mellon, Pennsylvania. It was primarily funded by the US DoD to explore software issues and topics associated with defense contracts. The US DoD is the largest producer and consumer of software in the world. The SEI developed a Capability Maturity Model (CMM) for software systems and an assessment mechanism.

The Five Levels of Software Process Maturity

The CMM defines five maturity levels: Level 1 Initial (ad hoc processes), Level 2 Repeatable, Level 3 Defined, Level 4 Managed, and Level 5 Optimizing.

Maturity Levels

Maturity levels are well-defined evolutionary plateaus, each a layer in the foundation for subsequent process improvement activities. Each level is a layer in the foundation for continuous process improvement. There are five maturity levels in the CMM. Achieving each level establishes a different component in the software process. Maturity levels are described in terms of 18 key process areas (KPAs).

Key Process Area Goals

Goals summarize the key practices of the key process areas. They are considered important for enhancing process capability for that level of maturity. They can be used to guide organizations and appraisal teams in assessing alternative ways to implement key process areas. Each Key Practice maps to one or more goals.

The CMM Key Process Areas

A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. KPAs are defined to reside at a single maturity level. They identify the issues that must be addressed to achieve a maturity level. There are 18 KPAs in the CMM.

The lecture provides a table mapping KPAs to maturity levels and process categories (Management, Organizational, Engineering). For example, at Level 2 (Repeatable), KPAs include Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management.

Common Features

Common features are used to organize the key practices in each key process area. They are attributes that ensure the processes are defined, documented, and understood. Common features are: commitment to perform, ability to perform, activities performed, measurement and analysis, and verifying implementation.

Institutionalization

Institutionalization means the organization outlives those who leave it. The organizational culture must convey the process. It is an indicator of whether the KPA is effective, repeatable, and lasting. The CMM has four common features that focus on institutionalizing the process: commitment to perform, ability to perform, measurement and analysis, and verifying implementation. Activities performed focus on implementing the process.

Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure. It typically includes policies and leadership.

Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently. It typically includes function/tools, resources, delegation, training, and orientation. It describes the roles and procedures necessary to implement a key process area, including establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary.

Measurement and Analysis describes the need to measure the process and analyze the measurements. It typically includes examples of the measurements that could be taken to determine the status and effectiveness of the activities performed.

Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established. It typically includes reviews and audits by senior management, project management, and SQA.

Key Practices

Key Practices state the fundamental policies, procedures, and activities for a key process area. Policies and procedures make up the infrastructure. They describe "what" is to be done but should not be interpreted as mandating "how". They are organized by common features. There are 316 key practices in the CMM.

CMM Structure

The lecture provides a visual of the CMM structure showing Maturity Levels, Process Capability, Key Process Areas, Goals, Common Features, Key Practices, and Institutionalization.

CMM Level 2: The Repeatable Level

Moving from Level 1 to Level 2: At level 2, a software project management system is in place. The organization sets expectations via policies. At level 2 projects have disciplined processes. Organizations have introduced at least some rigor into project management and technical development tasks. Approaches such as formal cost estimating are noted for project management, and formal requirements gathering are often noted during development. Compared to the initial level, a higher frequency of success and a lower incidence of overruns and cancelled projects can be observed.

KPA’s - Level 2: Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, Software Configuration Management.

Requirements Management

Purpose: The purpose is to establish a "common understanding" between the customer and organization. It involves documenting and controlling customer requirements, and 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, or 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 this, the software engineering group reviews the initial and revised system requirements allocated to software to resolve issues.

Software Project Planning

Purpose: 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, and defining the plan to perform the work.

Managing Based on Plan: The plan provides the basis 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, and software engineering management plan.

What is a Software Development Plan? A software development plan specifies many or all of the following: the project's 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, and 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, and 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: A commitment is 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.

Software Project Tracking and Oversight

Purpose: To provide adequate visibility into actual progress so that management can take effective actions when the software project's performance deviates significantly from the software plans. It involves tracking and reviewing software accomplishments and results against documented estimates, commitments, and plans, and adjusting plans based on actual accomplishments and results.

Manage to a Plan: Progress must be tracked against plans and specifications, including product size, project effort, cost and schedule, activities, and risks. Mechanisms to track progress against plans include both internal reviews and formal reviews with the customer.

Taking Corrective Action: If and when discrepancies between plans and actual progress occur, a judgment must be made about whether to change the work being done or adjust the plans. This judgment results in corrective action. Archives of original and adjusted plans should be kept.

Software Subcontract Management

Purpose: To select qualified software subcontractors and manage them effectively. It involves selecting a software subcontractor, establishing commitments with the subcontractor, and tracking and reviewing the subcontractor's performance and results.

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, the subcontractor. Performance of the prime contractor may critically depend on performance of the subcontractor.

Planning for the Subcontract: In selecting and managing a 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, and strategic business alliances.

Managing a Subcontract: The prime contractor must manage the subcontract. Ensure the subcontractor follows software development plans, standards, and procedures. Monitor software quality assurance by the subcontractor. Monitor software configuration management by the subcontractor.

Software Quality Assurance

Purpose: To provide management with appropriate visibility into the process being used by the software project and the products being built. It involves reviewing and auditing products and activities to ensure they comply with applicable procedures and standards, and providing the software project and other appropriate managers with the results of those reviews and audits.

Provides Visibility to Everyone: The value of SQA is that it provides an independent view of the project's activities, process, and product. SQA serves the "eyes and ears" of the management. Most key process areas contain SQA practices in Verifying Implementation.

Independent vs Objective: Commitment 1.2 (the SQA group has an "independent reporting channel" to senior management) indicates that an independent SQA group is normally expected. Goal 2 of SQA (verify adherence objectively) provides latitude in defining SQA. Without an independent SQA group, can the organization demonstrate objective means of adherence?

Resolving Noncompliance: There are three possible ways for resolving a noncompliance issue: make the product or process satisfy the standard, procedure, or requirement; change the standard or procedure to make it usable; or make an executive decision not to satisfy the standard, procedure, or requirement.

SQA Evolves: Proactive SQA functions as a value-adding member of the project team. SQA starts early in the project. SQA helps to prepare and review procedures, plans, and standards. At higher levels, the CMM provides flexibility for SQA to function proactively to drive improvements in the software process and product.

Software Configuration Management

Purpose: To establish and maintain the integrity of the products of the software projects throughout the project's software life cycle. It involves identifying configuration items/units, systematically controlling changes, and maintaining integrity and traceability of the configuration throughout the life cycle.

Using Baselines: SCM relies on baselining software work products. A baseline is a specification or product that has been formally reviewed and agreed on, serves as the basis for further work, and can be changed only through formal change control procedures.

Controlling Change: SCM provides a stable working environment. Uncontrolled change of work products is a chaotic process. SCM provides a memory of the status of software work products via baselines. When many individuals are working on the same product, SCM coordinates access to and change of the software work products.

Software Product and Software Work Product: A software product is the complete set, or any of the individual items of the set, of computer programs, procedures, associated documentation, and data designated for delivery to a customer or end user. A software work product is any artifact created as part of defining, maintaining, or using a software process, including process descriptions, plans, procedures, computer programs, and associated documents, which may or may not be intended for delivery to a customer or end user.

Baseline Vs Developmental Configuration Management: In baseline CM, baselines for identified software work products are established at predetermined points. In developmental CM, configuration control is exercised by the developers as they perform their work. The SCM KPA can be satisfied using at a minimum baseline configuration management.

Managed and Controlled: Some software work products do not need the formality of configuration management but do need to be placed under some form of version control and change control. This is referred to as "managed and controlled" in the key practices. Managed and controlled is a subset of developmental configuration management.

💡 Why this matters: Understanding the difference between a software product and a software work product is crucial for applying the correct level of configuration control. Knowing that SCM can be satisfied with baseline CM provides a practical starting point for organizations new to process discipline.

⭐ Key Takeaways

The CMM provides a structured five-level evolutionary path for improving software process maturity, from chaotic (Level 1 Initial) to continuously improving (Level 5 Optimizing). Each maturity level comprises Key Process Areas (KPAs) that must be institutionalized through common features: commitment to perform, ability to perform, activities performed, measurement and analysis, and verifying implementation. For the exam, you must know that Level 2 (Repeatable) focuses on project management discipline and has six KPAs: Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management. Institutionalization ensures processes endure beyond individuals, while key practices describe "what" to do, not "how" to do it. Finally, SQA provides an independent view of project activities, and SCM uses baselines to maintain integrity and control changes throughout the software life cycle.

🧠 Quick Revision Questions

1. What were the five key characteristics of the software state-of-the-art in 1984 that motivated the creation of CMM?
2. List the five maturity levels of the CMM in order, and state what the key focus of Level 2 (Repeatable) is.
3. What are the five common features used to organize key practices in each KPA, and which four focus on institutionalization?
4. Explain the difference between a software product and a software work product in the context of Software Configuration Management.
5. What are the three possible ways to resolve a noncompliance issue in Software Quality Assurance?

📘 Lecture 11 — CMM Level 3: The Defined Level

📖 Overview: This lecture details the transition from Level 2 (Repeatable) to Level 3 (Defined) of the Capability Maturity Model (CMM). It explains how the focus shifts from individual project management to organizational process standardization and improvement, introducing the seven Key Process Areas (KPAs) required for achieving this maturity level.

🗂️ Topics Covered

The lecture covers the transition from Level 2 to Level 3, the seven KPAs at this level including Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Reviews. It explains dedicated process groups like SEPGs, the creation and use of software process assets, tailoring guidelines, and the importance of institutionalized training and peer reviews for defect removal.

📝 Lecture Summary

CMM Level 3: The Defined Level

Moving from Level 2 to Level 3 represents a major shift in emphasis. At Level 2, the focus is on individual projects establishing reliable management processes. At Level 3 (The Defined Level), the emphasis shifts to the organization as a whole. Best practices are gathered across the organization, and processes are tailored as appropriate. The organization supports projects by establishing common processes, common measurements, and training. Organizations at this level have mastered a development process that can lead to successful large systems. Over and above the project management and technical approaches found in Level 2 organizations, Level 3 groups have a well-defined development process that can handle all sizes and kinds of projects.

Key Process Areas (KPAs) - Level 3

The seven KPAs at Level 3 are: Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Reviews.

Organization Process Focus

Purpose: To establish the organizational responsibility for software process activities that improve the organization’s overall process capability. It involves developing and maintaining an understanding of the organization’s and projects’ software processes, and coordinating activities to assess, develop, maintain, and improve these processes.

A dedicated group of people, such as a Software Engineering Process Group (SEPG) , is responsible for the organization’s software process activities, including appraisals and software process improvement plans. This group also maintains the organization’s software process database and provides training about the organization’s software process. Other ways of focusing on process include process review boards, quality circles, process steering committees, and software quality assurance. The key responsibilities of SEPGs are to establish process standards, maintain the process database, serve as the focal point for technology transition, provide process education and project consultation, and make periodic assessment and status reports. 💡 Why this matters: Without a dedicated group, process improvement initiatives are sporadic and lack organizational support.

Organization Process Definition

Purpose: To develop and maintain a useable set of software process assets that improve process performance and provide a basis for cumulative and long-term benefits. This involves developing and maintaining the organization’s standard software process and related process assets.

Software process assets are a collection of entities maintained by an organization for use by projects. They include:

• The organization’s standard software process
• Descriptions of approved software life cycles
• Guidelines and criteria for tailoring the standard process
• The organization’s software process database
• A library of software process-related documentation

The process building blocks of the standard software process include elements for activities such as estimating, design, coding, and peer review. These elements are described in terms of standards, procedures, templates, and abstractions. They have an order, interfaces, and interdependencies, sometimes referred to as a software process architecture. The organization may support several software life cycle models like Waterfall, Spiral, Incremental, or Agile processes.

Tailoring guidelines are available to individual projects, specifying what can be tailored out, what cannot, how much a process element can be modified, and what part should be considered for tailoring. The organization’s software process database is a central repository containing actual measurement data from projects and related information. The library of software process-related documentation holds best documents from past projects, including lessons learned and example documents. 🔑 Definition — Organization Process Focus vs. Organization Process Definition: Organization Process Focus focuses on the who (roles and people responsible for process activities), while Organization Process Definition focuses on the what (the actual process assets and standards). These two KPAs are tightly coupled.

Training Program

Purpose: To develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently. It involves identifying the training needs of the organization, projects, and individuals, and developing or procuring training to address those needs.

An organizational training group reviews each project’s training needs and plans, analyzes the skills needed by the organization, prepares and maintains training courses, and maintains training records. Organizational training needs are identified based on the organization’s standard software processes, project needs, organizational culture, and individual needs. A waiver procedure should exist to waive training for individuals who already possess the required skill. At Level 2, the phrase “receive training” is used, which may not be institutionalized. At Level 3 and above, the phrase “receive required training” is used, indicating that institutionalization of training is expected. Training may include formal and informal instruction, including mentors and on-the-job training, but these informal vehicles are frequently abused.

Integrated Software Management

Purpose: To integrate the project’s software engineering and management activities into a coherent, defined software process that is tailored from the organization’s standard software process and related process assets.

At Level 3, each project tailors the organization’s standard software process for its particular needs, including software life cycles, standards, and procedures. The project uses lessons learned and data from previous projects and feeds back appropriate measurement data and documents to the organization. The software development plan is now based on the project’s defined software process. Projects can use and share process data and lessons learned. Integrated Software Management is the evolution of Software Project Planning and Software Project Tracking and Oversight.

Software Product Engineering

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

Development and maintenance activities include software requirement analysis, software design, coding, testing, and integration. Testing activities include unit, integration, system, and acceptance testing. Documentation addresses needs that span the life cycle, including customer documentation (user manuals, training materials, operator manuals) and developer documentation (requirements documents, design documents, test documents, maintenance manuals). Consistency and traceability among documents are critical; inconsistent specifications are not usable.

Intergroup Coordination

Purpose: To establish a means for the software engineering group to participate actively with other engineering groups so that the project is better able to satisfy customer needs effectively and efficiently. It involves disciplined interaction and coordination of the project’s engineering groups with each other to address system-level requirements, objectives, and plans.

Commitments among groups are documented and agreed to by all groups. The software engineering group actively interfaces with groups such as systems engineering, marketing, training, and documentation. Intergroup coordination can be as minimal as a few meetings or as extensive as integrated product teams. It is a first step on the road to concurrent engineering.

Peer Reviews

Purpose: To remove defects from 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.

A peer review is a methodical examination of work products by the producer’s peers to identify defects and areas where changes are needed. It involves identifying products that will undergo a review in the project’s defined software process. Performing peer reviews requires planning and scheduling, training leaders and participants, providing material in advance, assigning specific roles, specifying start/end criteria, using pre-planned checklists, identifying action items to track to closure, and collecting data for process improvement. Alternative methods include Fagan-style inspections, structured walkthroughs, active reviews, and phased inspections. 💡 Why this matters: Catching defects early in the lifecycle is exponentially cheaper than finding them in later stages like testing or deployment.

⭐ Key Takeaways

The transition to CMM Level 3 represents a fundamental organizational shift from project-level management to organization-wide process standardization. The SEPG is the central driver for process improvement, while Organization Process Definition provides the standard assets like the process database and tailoring guidelines that all projects use. Institutionalized training is mandatory, moving from optional to required, and the project’s defined process is tailored from the organization’s standard. Peer reviews are a formal, planned activity for early defect removal, and intergroup coordination ensures all engineering groups work together to meet customer needs.

🧠 Quick Revision Questions

1. What is the key difference in focus between CMM Level 2 and Level 3?
2. Name the two KPAs that are tightly coupled, and explain what each one focuses on (the "who" vs. the "what").
3. What is the primary purpose of a training waiver in the Training Program KPA?
4. How does the "software development plan" change when a project reaches Integrated Software Management?
5. List three key activities required for performing a proper peer review.

📘 Lecture 12 — CMM Level 4 The Managed Level

📖 Overview: This lecture transitions from CMM Level 3 to Level 4, explaining how organizations move from defined processes to quantitatively managed ones. It covers the two Key Process Areas (KPAs) for Level 4—Quantitative Process Management and Software Quality Management—and introduces Level 5 (Optimizing) with its KPAs. The lecture concludes with a review of CMM themes, measurement progression, and an introduction to ISO 9001:2008 as a quality management system standard.

🗂️ Topics Covered

The lecture begins by explaining the transition from Level 3 to Level 4, where decisions are made based on collected data. It then details the two KPAs of Level 4: Quantitative Process Management (controlling process performance quantitatively) and Software Quality Management (developing quantitative understanding of product quality). The lecture proceeds to Level 5, the Optimizing Level, covering Defect Prevention, Technology Change Management, and Process Change Management. Finally, it ties together the CMM themes, discusses measurement by levels, and introduces ISO 9001:2008, its eight principles, and the process-based quality management system model.

📝 Lecture Summary

CMM Level 4 The Managed Level

At Level 3, measurements have been defined and collected systematically. At Level 4, decisions are made based on the data collected. This involves common measurement and data analysis. Organizations have established a firm quantitative basis for project management and utilize both effective measurements and also effective cost and quality estimates.

KPAs - Level 4

The Key Process Areas for Level 4 are Software Quality Management and Quantitative Process Management.

Quantitative Process Management

The purpose of Quantitative Process Management is to control the process performance of software projects quantitatively. It involves establishing goals for process performance, measuring the performance of the project, analyzing these measurements, and making adjustments to maintain process performance within acceptable limits.

🔑 Definition — Special Causes of Variation: Variations in performance that are not within the normal range of process performance. These are "extraordinary" events outside the bounds of process capability.

A key concern is identifying special causes of variation. Quantitative control in the CMM implies any quantitative or statistically based technique. The words "statistical" and "quantitative" imply data, which reflect facts. Fact-based management results in objective decisions.

Basic statistics show that quantitative techniques need not be sophisticated to be useful; a Pareto analysis for example is very simple. Quantitative techniques do require measurable data, consistent data collection, and defined comparable measurements.

📐 Formula/Concept: Seven Basic Tools of Statistical Process Control:

• Histograms
• Cause and effect diagrams
• Check sheets
• Pareto diagrams
• Run charts
• Control charts
• Scatter diagrams

Taking Corrective Action at Level 4

Quantitative Process Management focuses on the process. Process capability is quantitatively known. When performance falls outside the limits, the organization must identify the reason and take corrective action when appropriate.

Software Quality Management

The purpose is to develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals. It involves defining quality goals for the software products, establishing plans to achieve these goals, and monitoring and adjusting software plans and work products.

Building High-Quality Products

Software Quality Management focuses on the product, not the process. Measurable quality goals for the product are defined. The product is considered ready only when the goals are achieved.

Quality Evolves

At Level 2, the focus of quality is conformance to requirements. By Level 4, there is an emphasis on understanding the needs of the customer, end users, and organization (supplier). Ultimately, the customer determines what quality is or is not. TQM (Total Quality Management) revolves around customer satisfaction.

The CMM Level 5 The Optimizing Level

At Level 4, the process is quantitatively understood. At Level 5, continuous process improvement is a way of life. In immature organizations, no one may be responsible for process improvement. Mature organizations usually have 70 to 80% participation in improvement activities at any point in time—everyone is involved. Organizations are assumed to have mastered the current state-of-the-art of software project management and development.

KPAs - Level 5

The Key Process Areas for Level 5 are Defect Prevention, Technology Change Management, and Process Change Management.

Defect Prevention

The purpose is to identify the cause of defects and prevent them from reoccurring. It involves analyzing defects that were encountered in the past and taking specific actions to prevent the occurrence of these types of defects in the future.

Fixing Problems Before They Happen

The focus is on causal analysis: what in the process permitted the defect to occur and what in the process needs to be corrected to prevent the defect from occurring in the future.

Technology Change Management

The purpose is to identify new technologies (tools, methods, and processes) and track them into the organization in an orderly manner. It involves identifying, selecting, and evaluating new technologies, and incorporating effective technologies into the organization.

Reacting to Innovation

Technology changes occur at all maturity levels. At Level 5, innovation is introduced into the process in a disciplined way and is part of the culture (institutionalized).

Process Change Management

The purpose is to continually improve the software process used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development. It involves defining process improvement goals and systematically identifying, evaluating, and implementing improvements to the organization's standard software process and project-defined software processes.

Change Is a Process

Disciplined change is the key to success. Improvement includes planning, evaluating improvement proposals, planning actions, establishing process improvement teams, conducting pilot programs, and updating procedures and training. Improvements are transferred into everyday practice across the organization.

Level 5 is not the destination

Level 5 is the foundation for building an ever-improving capability. Level 5 organizations continuously improve both incrementally (Kaizen) and through revolutionary changes. Everyone in a Level 5 organization is involved in improvement.

Tying It All Together

Themes in the CMM include continuous improvement, defined/documented/used processes, commitment by senior management, stable, measured, controlled, and evolving processes, and team work.

Measurement by Levels:

1. Measurement is haphazard, but investigation may yield cost and effort data.
2. Projects collect management data (costs, effort, size, schedule, quality).
3. Consistent definitions exist across projects; management and quality data are collected organization-wide.
4. Data analysis is based on the principles of statistical process control; actual measurements are compared to expected values of mean and variance.
5. Continuous improvement is based on business objectives and cost-benefit analysis.

How is improvement achieved? Know where you are, know where you want to go, assign resources and responsibilities, and try progress.

Keys to Improvements: Senior management commitment, organizational consensus on important issues, belief that improvement is possible, and an action-oriented framework for improvement.

Key Adjectives: The CMM is not exhaustive; it focuses on the major leverage points: key process areas and key practices.

What does a good software organization look like? Processes are defined, documented, and used; management plans, monitors, and communicates; roles and responsibilities are clear; product and processes are measured; quality, cost, and schedule are predictable; technology is planned and used effectively; and continuous improvement is a way of life.

ISO 9001:2008

The lecture now discusses the efforts of ISO in improving quality, focusing on the quality management system. The adoption of a quality management system should be a strategic decision of an organization. The design and implementation of an organization's quality management system is influenced by its organizational environment, changes in that environment, risks, varying needs, objectives, products, processes, size, and structure.

🔑 Definition — Process Approach: The application of a system of processes within an organization, together with the identification and interactions of these processes, and their management to produce the desired outcome. An advantage is the ongoing control over the linkage between individual processes.

This International Standard promotes the adoption of a process approach to enhance customer satisfaction by meeting customer requirements.

Eight Principles of Management:

• Customer focus
• Leadership
• Involvement of people
• Process approach
• System approach
• Continual improvement
• Factual approach
• Mutually beneficial supplier relationship

Quality Management System Requirements, Categories:

• QMS - Requirements: General and Documentation (Quality manual, Control of documents and records)
• QMS: Management Responsibility: Management commitment, Customer focus, Quality policy, Planning, Responsibility/authority/communication, Management review
• QMS: Resource Management: Provision of resources, Human resources, Infrastructure, Work environment
• QMS: Product Realization: Planning, Customer-related processes, Design/development, Purchasing, Production/service provision, Control of monitoring/measuring equipment
• QMS: Measurement, Analysis and Improvement: Monitoring/measurement, Control of nonconforming product, Analysis of data, Improvement

The lecture presents a model of a process-based quality management system, which illustrates that customers play a significant role in defining requirements as inputs. Monitoring of customer satisfaction requires the evaluation of information relating to customer perception as to whether the organization has met the customer requirements.

💡 Why this matters: This lecture bridges the gap between having defined processes (Level 3) and using quantitative data to manage and improve them (Levels 4 and 5), which is the core of organizational maturity. The introduction of ISO 9001 shows a parallel, globally recognized framework for quality management.

⭐ Key Takeaways

A student must remember that Level 4 (Managed) is about using statistical and quantitative techniques to control both the process and the product, with KPAs being Quantitative Process Management and Software Quality Management. Level 5 (Optimizing) is about continuous, data-driven improvement through Defect Prevention, Technology Change Management, and Process Change Management. The measurement progression from Level 1 (haphazard) to Level 5 (business-objective-driven) is a critical framework. Finally, the ISO 9001:2008 standard provides a process-based quality management system with eight management principles and five major requirement categories (QMS, Management Responsibility, Resource Management, Product Realization, Measurement/Analysis/Improvement).

🧠 Quick Revision Questions

1. What is the fundamental difference in decision-making between CMM Level 3 and Level 4?
2. Name the two Key Process Areas (KPAs) for CMM Level 4 and state whether each one focuses primarily on the process or the product.
3. What does the concept of a "Special Cause of Variation" mean in the context of Quantitative Process Management?
4. List the three Key Process Areas (KPAs) for CMM Level 5 (the Optimizing Level) and briefly describe the goal of each.
5. Name three of the eight principles of management promoted by ISO 9001:2008.

📘 Lecture 13 — Introduction to CMMI

📖 Overview: This lecture introduces the Capability Maturity Model Integration (CMMI), explaining what it is and is not. It clarifies the distinctions between a process model, a process, a process description, a procedure, and an appraisal. The lecture covers the history of CMMI, its purpose in integrating systems and software disciplines, and its two key representations: staged and continuous.

🗂️ Topics Covered

The lecture begins by defining CMMI and distinguishing it from processes, procedures, and appraisals. It then covers the short history of CMMI, the problems with having many separate models, and how CMMI bridges the systems/software divide. The core of the lecture compares the staged and continuous representations of the model, their advantages, and the overall structure and benefits of using CMMI for process improvement.

📝 Lecture Summary

What is CMMI?

CMMI (Capability Maturity Model Integration) is a process model, not a process itself. It is a merger of process improvement models for systems engineering, software engineering, hardware engineering, and integrated teams. It provides a common vocabulary and clarifies how these areas interrelate. CMMI is a collection of best practices from highly functioning organizations, designed to help an organization improve its processes by describing what activities should be done, but not how to do them. It can be directly copied to serve as an organization's processes.

What is a Process?

A process is what you actually do in an organization. It is the documented set of activities or steps you perform to accomplish work. For a process to be real, performed consistently, and improved, it must be documented. Having undocumented processes and believing they are used consistently is unrealistic.

What is a Process Description?

A process description is a documented expression of a set of activities to achieve a given purpose. It documents the steps of the process (what you do when performing a task). Closely related are procedures, which provide step-by-step instructions on how to perform those steps.

What is an Appraisal?

An appraisal is a way to evaluate an organization’s processes and procedures. It assesses how they were implemented, to what extent they are followed, and how well they map to CMMI practices. The standard method for this is SCAMPI (Standard CMMI Appraisal Method for Process Improvement), which is a set of appraisal methods differing in intent and rigor. SCAMPI can be used for internal improvement, supplier selection, process monitoring, and contract awards.

Short History of CMMI

The CMM (Capability Maturity Model) was initially successful for improving software processes. This success led to the creation of similar models for other disciplines like systems engineering, software acquisition, and security. This proliferation of models (Software CMM, System Engineering CMM, etc.) caused confusion due to different structures, formats, and terminology. CMMI was created to rescue this situation by integrating systems and software disciplines into one process improvement framework, providing a structure for introducing new disciplines as they arise.

Comparing Model Representations: Staged vs. Continuous

CMMI provides two representations because of its heritage from different source models (Software CMM, SECM, IPD-CMM).

• Staged Representation: Uses predefined sets of process areas to define an improvement path. This path is described by maturity levels, which are well-defined evolutionary plateaus toward achieving improved organizational processes. It provides a roadmap for implementing groups of process areas in a specific sequence.
• Continuous Representation: Allows an organization to select a specific process area and improve it. It uses capability levels to characterize improvement relative to an individual process area. This offers maximum flexibility to focus on process areas that align with specific business goals.

Process Area Capability and Organizational Maturity

These are similar concepts. Process area capability deals with a set of processes relating to a single process area. Organizational maturity pertains to a set of process areas across the entire organization. A key rule to remember is that a model shows what to do, not how to do it or who does it.

🔑 Definition — CMMI: A process model that integrates multiple disciplines and provides a collection of best practices for process improvement. 🔑 Definition — Process: What an organization actually does, which must be documented to be real and consistent. 🔑 Definition — Appraisal: An evaluation of an organization's processes and their conformance to a reference model like CMMI.

CMMI Model Structure

The CMMI model has a specific structure. It includes:

• Maturity Levels (staged) or Capability Levels (continuous)
• Process Areas
• Goals (Generic and Specific)
• Practices (Generic and Specific)

💡 Why this matters: This structure provides a common, organized framework for improvement, allowing organizations to assess their current state and plan a path forward using a consistent set of components.

Benefits of CMMI

CMMI best practices enable organizations to:

• More explicitly link management and engineering activities to business objectives.
• Expand the scope of and visibility into the product lifecycle.
• Incorporate lessons learned from areas like measurement, risk management, and supplier management.
• Implement more robust high-maturity practices.
• Address additional critical organizational functions.

CMMI serves as a collection of best practices, a framework for organizing and prioritizing activities, and a means to align process improvement objectives with business objectives. It supports the coordination of multi-disciplined activities.

⭐ Key Takeaways

CMMI is a process model, not a process, and it integrates best practices from multiple disciplines. The two main representations are the staged approach, which provides a predefined roadmap via maturity levels, and the continuous approach, which offers flexibility to focus on specific process areas via capability levels. A process description documents the steps (what to do), while a procedure explains how to perform them. An appraisal like SCAMPI evaluates how well an organization’s actual processes align with the CMMI model. The primary benefits of CMMI include linking activities to business objectives and providing a framework to coordinate multi-disciplined activities.

🧠 Quick Revision Questions

1. What is the fundamental difference between a CMMI model and an organization's process?
2. Name the standard appraisal method used in the CMMI world and list one of its uses.
3. What is the primary advantage of the staged representation over the continuous representation?
4. In the CMMI model structure, what are the two types of Goals and the two types of Practices?
5. How does CMMI help to bridge the traditional "divide" between systems engineering and software engineering disciplines?

📘 Lecture 14 — Introduction to CMMI Staged Representation

📖 Overview: This lecture introduces the CMMI staged representation, an approach that uses predefined sets of process areas organized by maturity levels to define an improvement path for an organization. It explains the five maturity levels, the structure of the model including process areas, goals, and practices, and emphasizes that maturity levels cannot be skipped. This matters because it provides a systematic, step-by-step framework for organizations to progressively improve their processes.

🗂️ Topics Covered

This lecture covers the concept of staged representation and how it differs from continuous representation (not covered here). It details the five maturity levels (Performed, Managed, Defined, Quantitatively Managed, Optimizing), explaining the focus and characteristics of each level. The structure of CMMI staged representation is broken down into process areas, goals (specific and generic), practices (specific and generic), and common features (Commitment to Perform, Ability to Perform, Directing Implementation, Verification). It also discusses the rule that maturity levels cannot be skipped and provides examples of process areas for each level.

📝 Lecture Summary

Staged Representation

The staged representation 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, which is a well-defined evolutionary plateau toward achieving improved organizational processes. The staged representation offers a systematic, structured way to approach process improvement one step at a time. Achieving each stage ensures that an adequate foundation has been laid as a foundation for the next stage. Process areas are organized by maturity levels, prescribing the order for implementing each process area according to maturity levels, which define the improvement path for an organization from the initial level to the optimizing level.

Maturity Levels

Achieving each maturity level ensures that an adequate improvement foundation has been laid for the next maturity level and allows for lasting, incremental improvement. A maturity level signifies the level of performance that can be expected from an organization. There are five maturity levels, each a layer in the foundation for continuous process improvement: Performed, Managed, Defined, Quantitatively Managed, and Optimizing.

💡 Why this matters: Maturity levels provide a clear roadmap for improvement, ensuring that lower-level discipline is established before more advanced process innovations are attempted.

Structure of the CMMI Staged Representation

• Commitment to Perform: creates policies and secures sponsorship for process improvement efforts.
• Ability to Perform: ensures that the project and/or organization has the resources it needs to pursue process improvement.
• Directing Implementation: collects, measures, and analyzes data related to processes.
• Verification: verifies that the projects and/or organization's activities conform to requirements, processes, and procedures.
• All old common features got rolled into Level 2 generic practices. Both activities and common features are present in each Key Process Area (KPA), where the common features include Commitment to Perform, Ability to Perform, Measurement and Analysis, and Verifying Implementation.

Maturity Levels Cannot Be Skipped

A level provides a necessary foundation for effective implementation of processes at the next level.

• Higher level processes are easily sacrificed without the discipline provided by lower levels.
• The effect of innovation is obscured in a noisy process.
• Higher maturity level processes may be performed by organizations at lower maturity levels, with the risk of not being consistently applied in a crisis.

Process Areas

Process Areas (PAs) are clusters of related practices performed collectively to achieve a set of goals. They are the major building blocks in establishing the process capability of an organization. Each process area has been defined to reside at a given maturity level.

Process Areas by Maturity Level

Level 1: Performed

(No specific characteristics or process areas are detailed for this level in the lecture; it is the initial starting point.)

Level 2: Managed

Characteristics of a Level 2 organization include:

• Adhering to organizational policies
• Following a documented plan and process description
• Applying adequate funding and resources
• Maintaining appropriate assignment of responsibility and authority
• Training people in their appropriate processes
• Placing work products under appropriate configuration management
• Monitoring and controlling process performance, and taking corrective action
• Objectively reviewing the process, work products, and services, and addressing noncompliance
• Reviewing the activities, status, and results of the process with appropriate levels of management, and taking corrective action
• Identifying and interacting with relevant stakeholders

Level 3: Defined

At Level 3, the organization has achieved all of the goals of Level 2. There is an organizational way of doing business, with tailoring of this organizational method allowed under predefined conditions. The organization has an Organization's Set of Standard Processes (OSSP). The following characteristics of the process are clearly stated: Purpose, Inputs, Entry criteria, Activities, Roles, Measures, Verification steps, Outputs, Exit criteria. Level 3 continues with defining a strong, meaningful, organization-wide approach to developing products. An important distinction between Level 2 and Level 3 is that at Level 3, processes are described in more detail and more rigorously than at Level 2. Processes are managed more proactively, based on a more sophisticated understanding of the interrelationships and measurements of the processes and parts of the processes. Level 3 is more sophisticated, more organized, and establishes an organizational identity—a way of doing business particular to this organization.

Level 4: Quantitatively Managed

For Maturity Level 4, the organization has achieved all of the goals of Levels 2 and 3. The organization controls its processes by statistical and other quantitative techniques. Product quality, process performance, and service quality are understood in statistical terms and are managed throughout the life of the processes. Level 4 focuses on using metrics to make decisions and to truly measure whether progress is occurring and your product is improving. Distinctions between Level 3 and Level 4 are that at Level 3, processes are qualitatively predictable, while at Level 4, processes are quantitatively predictable. Level 4 addresses special causes of process variation and takes corrective action.

Level 5: Optimizing

At Level 5, the organization has achieved all of the goals of Levels 2, 3, and 4. Processes are continually improved based on an understanding of common causes of variation within the processes. Level 5 is described as "nirvana": everyone is a productive member of the team, defects are reduced, and your product is delivered on time and within the estimated budget.

🔑 Definition — Maturity Level: A well-defined evolutionary plateau on the path to becoming a mature organization, signifying the level of performance that can be expected from an organization.

Maturity Levels (Reiteration on Process Boundaries)

In the staged representation, the maturity levels serve as process boundaries—meaning that the efforts documented in that maturity level relate only to that maturity level. For example, Requirements Management is a Level 2 process area. To be considered a Maturity Level 2 organization, the projects undergoing process improvement need to satisfy the goals for all of the process areas for Maturity Level 2. An organization seeking to be Maturity Level 3 would need to structure their process improvement program to satisfy the goals for both Level 2 and Level 3. The process areas listed in Level 2 are not listed in Level 3, and vice versa. The same holds true for Maturity Level 4 and Maturity Level 5. You must satisfy all of the goals in the previous levels plus the goals for the current level in order to attain the maturity level rating. Each maturity level consists of process areas. Each process area contains goals that must be satisfied. Each goal has certain practices or actions associated with it.

Process Areas (Reiteration)

Each maturity level consists of several process areas. A process area is a group of practices or activities performed collectively in order to achieve a specific objective.

Goals

Each PA has several goals that need to be satisfied in order to satisfy the objectives of the PA. There are two types of goals:

• Specific Goals (SG): goals that relate only to the specific PA under study.
• Generic Goals (GG): goals that are common to multiple process areas throughout the model. These goals help determine whether the PA has been institutionalized.

🔑 Definition — Institutionalized: Embedded in the way the organization does its business, making it effective, repeatable, and lasting.

Practices

Practices are activities that must be performed to satisfy the goals for each PA. Each practice relates to only one goal. There are two types of practices:

• Specific Practices (SP): practices that relate to specific goals.
• Generic Practices (GP): practices associated with the generic goals for institutionalization.

Example: Specific Goal and Specific Practice

• Specific Goal (from Requirements Management PA): Requirements are maintained and accurately reflected in project plans, activities and products.
• Specific Practice (from Requirements Management PA): Maintain the traceability of requirements to their source requirements.
• Generic Goal (from Maturity Level 2): Institutionalize a Managed Process.
• Generic Practice (from Maturity Level 2): Establish an Organizational Policy.

Common Features

Common features are a means of categorizing Generic practices.

• Commitment to perform: establishment of management policies.
• Ability to perform: establishment and maintenance of plans, resources, assigned responsibility and authority, and training.
• Directing implementation: measurement, control, and performance practices.
• Verification: ensure implementation and compliance.

Another way to look at Common Features

Common feature categories are very similar across process areas. They are referred to as Institutionalization Common Features because they:

• Ensure the process areas are effective, repeatable and lasting.
• Provide needed infrastructure support.

Common Feature Examples

• Commitment to perform: Establish and maintain an organizational policy for planning and performing the requirements management process.
• Ability to perform: Train the people performing or supporting the requirements management process as needed.
• Directing implementation: Place designated work products of the requirements management process under appropriate levels of configuration management.
• Verification: Review the activities, status, and results of the requirements management process with higher level management and resolve issues.

Summary

• Staged: Structured for implementation based on proven grouping and ordering of processes.
• The CMMI model should be applied using intelligence, common sense, and professional judgment.

⭐ Key Takeaways

The staged representation provides a predefined, sequential improvement path using five maturity levels that cannot be skipped, ensuring a disciplined foundation is established before progressing. Each maturity level contains specific process areas with goals that must be fully satisfied to achieve that rating, with lower-level goals being a prerequisite for higher levels. The model's structure includes process areas, specific and generic goals, specific and generic practices, and common features that ensure institutionalization. The progression from Level 1 to Level 5 moves from chaotic processes to quantitatively managed and optimizing processes, with the key difference between Level 3 (qualitatively predictable) and Level 4 (quantitatively predictable) being particularly important.

🧠 Quick Revision Questions

1. What are the five maturity levels in the CMMI staged representation, and what is the key focus of each?
2. Why can maturity levels not be skipped in the staged representation, and what risks does skipping introduce?
3. What is the difference between a Specific Goal (SG) and a Generic Goal (GG), and what is the purpose of each?
4. What are the four common features in the staged representation, and give an example of a generic practice for each?
5. What is the key difference between a Level 3 (Defined) organization and a Level 4 (Quantitatively Managed) organization in terms of process predictability?

📘 Lecture 15 — CMMI Staged – Maturity Level 2

📖 Overview: This lecture examines CMMI Staged Representation, focusing on Maturity Level 2. It explains the evolutionary improvement path from ad-hoc Level 1 processes to managed Level 2 processes, detailing the seven process areas that establish fundamental project management discipline. Understanding this level is critical because it represents the biggest hurdle in process improvement—moving from chaotic individual practices to shared, repeatable project-level processes.

🗂️ Topics Covered

The lecture introduces the Staged Representation approach and the concept of maturity levels, then contrasts Level 1's ad-hoc processes with Level 2's disciplined management approach. It covers all seven Maturity Level 2 process areas in detail: Requirements Management, Project Planning, Project Monitoring and Control, Supplier Agreement Management, Measurement and Analysis, Process and Product Quality Assurance, and Configuration Management—including their specific goals, practices, generic practices, and common implementation pitfalls.

📝 Lecture Summary

Staged Representation

The staged representation 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, which is a well-defined evolutionary plateau toward achieving improved organizational processes. The biggest hurdle most organizations face is jumping from Level 1 to Level 2. Level 1 is characterized by ad hoc processes created by individuals, leading to redundant work, lack of sharing, opposing approaches, rework, delays, and frustration. The organization functions through heroics and suffers when people leave. Level 2 is characterized by individuals sharing lessons learned and best practices, devising preliminary processes that function at the project level and sometimes organization-wide.

💡 Why this matters: Level 1 organizations are fragile and dependent on individual heroics; Level 2 establishes the management discipline needed for predictable, repeatable project execution.

The Maturity Levels

Level 2 focuses on management issues that affect normal, day-to-day work routines and consists of seven process areas (PAs). Each PA has specific goals (specific to that PA) and generic goals applied to every PA at that maturity level. These generic goals lead to institutionalizing the process area—when an organization ensures consistent practice across the organization, the PA will continue to be applied appropriately even after those who created the procedures leave.

Generic Goal Level 2: Institutionalize a Managed Process consists of ten generic practices:

• 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

PA 1 – Requirements Management

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.

🔑 Definition — REQM: The process of understanding, obtaining commitment to, managing changes to, and maintaining traceability of requirements, while identifying inconsistencies between requirements and project work.

The specific goal (SG1) for REQM is Manage Requirements, with five specific practices:

• SP 1.1 Obtain an Understanding of Requirements
• SP 1.2 Obtain Commitment to Requirements
• SP 1.3 Manage Requirements Changes
• SP 1.4 Maintain Bidirectional Traceability of Requirements
• SP 1.5 Identify Inconsistencies between Project Work and Requirements

REQM at Level 2 focuses on managing already existing requirements—those elicited from the customer, documented, and ready to be worked. It exists at Level 2 because without setting scope, you cannot control how much work the project will need. The Requirements Development PA at Level 3 deals with eliciting and developing requirements, while REQM manages them. There are no generic practices that directly map to this PA. REQM includes understanding requirements for all parts of the system (not just software), obtaining commitment, managing changes, maintaining bidirectional traceability, and identifying inconsistencies. This PA forms the basis of project development and feeds into many other process areas.

PA 2 – Project Planning

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

Three specific goals for PP:

• SG1 Establish Estimates
• SG2 Develop a Project Plan
• SG3 Obtain Commitment to the Plan

SG1 Specific Practices:

• SP 1.1 Estimate the Scope of the Project
• SP 1.2 Establish Estimates of Work Product and Task Attributes
• SP 1.3 Define Project Life Cycle
• SP 1.4 Determine Estimates of Effort and Cost

SG2 Specific Practices:

• SP 2.1 Establish the Budget and Schedule
• SP 2.2 Identify Project Risks
• SP 2.3 Plan for Data Management
• SP 2.4 Plan for Project Resources
• SP 2.5 Plan for Needed Knowledge and Skills
• SP 2.6 Plan Stakeholder Involvement
• SP 2.7 Establish the Project Plan

SG3 Specific Practices:

• SP 3.1 Review Plans That Affect the Project
• SP 3.2 Reconcile Work and Resource Levels
• SP 3.3 Obtain Plan Commitment

The generic practice that most closely matches PP is GP 2.2 Plan the Process. Other GPs that can trace guidance back to this PA include GP 2.3 (Provide Resources), GP 2.4 (Assign Responsibility), GP 2.5 (Train People), and GP 2.7 (Identify and Involve Relevant Stakeholders).

PA 3 – Project Monitoring and Control

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.

Two specific goals:

• SG1 Monitor Project against Plan
• SG2 Manage Corrective Action to Closure

SG1 Specific Practices:

• SP 1.1 Monitor Project Planning Parameters
• SP 1.2 Monitor Commitments
• SP 1.3 Monitor Project Risks
• SP 1.4 Monitor Data Management
• SP 1.5 Monitor Stakeholder Involvement
• SP 1.6 Conduct Progress Reviews
• SP 1.7 Conduct Milestone Reviews

SG2 Specific Practices:

• SP 2.1 Analyze Issues
• SP 2.2 Take Corrective Action
• SP 2.3 Manage Corrective Action

Key point: PMC is tied to the PP PA—without a credible project plan, PMC cannot be satisfied. Document reviews with management and any other reviews that may impact schedules, planning, staffing, or strategies. The generic practice that most closely matches this PA is GP 2.8 Monitor and Control the Process. Other related GPs are GP 2.7 (Identify and Involve Relevant Stakeholders) and GP 2.10 (Review Status with Higher Level Management). Reviews should be both periodic (routinely scheduled) and event-driven (when something unexpected happens or a milestone is reached). PMC includes monitoring project attributes, staff availability, stakeholder involvement, project risks, information handling, conducting reviews, bringing potential problems to light, analyzing issues, and taking corrective action.

PA 4 – Supplier Agreement Management

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.

Two specific goals:

• SG1 Establish Supplier Agreements
• SG2 Satisfy Supplier Agreements

SG1 Specific Practices:

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

SG2 Specific Practices:

• 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

SAM does not apply to projects where the supplier is integrated into the project team using the same processes and reporting to the same management. If the organization has no external suppliers, this PA may be non-applicable, though given the model's expanded nature, this is increasingly unlikely. The PA covers formal agreements for delivery, development, or installation of hardware, tools, COTS products, simulators, etc.—not just subcontracting. It includes guidance for releasing supplier-built products, evaluating project risks, and acceptance testing. Even though wording specifies "products and product components," practices also include services provided. This is the only PA that may be tailored out—it does not have to be implemented if it doesn't pertain to the organization. This PA does not map to any generic practice.

PA 5 – Measurement and Analysis

The purpose of Measurement and Analysis (M&A) is to develop and sustain a measurement capability that is used to support management information needs.

Two specific goals:

• SG1 Align Measurement and Analysis Activities
• SG2 Provide Measurement Results

SG1 Specific Practices:

• SP 1.1 Establish Measurement Objectives
• SP 1.2 Specify Measures
• SP 1.3 Specify Data Collection and Storage Procedures
• SP 1.4 Specify Analysis Procedures

SG2 Specific Practices:

• SP 2.1 Collect Measurement Data
• SP 2.2 Analyze Measurement Data
• SP 2.3 Store Data and Results
• SP 2.4 Communicate Results

M&A describes what to do when instituting a measurement process, not just which measurements to collect. It should be considered global because all processes should be measured. M&A was made a separate PA because high-maturity organizations identified measurement as key to success in process improvement. While instituting a measurement approach and repository is difficult, it is so necessary that it should be initiated early. Key reminders: tie measurements back to meaningful business goals (not just collecting because it's always been done); measure your measures—track the time, effort, and effectiveness of the measurement effort itself. The generic practice that most closely matches this PA is GP 2.8 Monitor and Control the Process—both M&A and PMC must be implemented to satisfy GP 2.8.

Basic Step-by-Step Approach to Measurement:

1. Select the process to measure
2. Select the measures
3. Determine when to collect data
4. Determine how to collect data
5. Record and store the information
6. Analyze data for consistency and accuracy
7. Chart the results
8. Review the chart
9. Do something (corrective actions)

PA 6 – Process and Product Quality Assurance

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

Two specific goals:

• SG1 Objectively Evaluate Processes and Work Products
• SG2 Provide Objective Insight

SG1 Specific Practices:

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

SG2 Specific Practices:

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

Important: Someone needs to independently review QA activities and results—by another organization, outside the organization, or by companies specializing in IV&V or external audits. Some organizations use the SCAMPI appraisal itself as part of this external review. PPQA is the most often abused process area during appraisals—do not abuse or misuse it. If implementing PPQA as defined in CMMI is too much trouble, don't introduce CMMI. The generic practice that most closely matches this PA is GP 2.9 Objectively Evaluate Adherence. PPQA 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 verification reports.

PA 7 – Configuration Management

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Three specific goals:

• SG1 Establish Baselines
• SG2 Track and Control Changes
• SG3 Establish Integrity

SG1 Specific Practices:

• SP 1.1 Identify Configuration Items
• SP 1.2 Establish a Configuration Management System
• SP 1.3 Create or Release Baselines

SG2 Specific Practices:

• SP 2.1 Track Change Requests
• SP 2.2 Control Configuration Items

SG3 Specific Practices:

• SP 3.1 Establish Configuration Management Records
• SP 3.2 Perform Configuration Audits

The organization needs to define when each type of baseline (formal or developmental) should be used. The generic practice that most closely matches this PA is GP 2.6 Manage Configurations—the term "configuration control" is used instead of "configuration management" when describing appropriate levels of configuration activities. CM includes defining configuration items, developing or implementing support tools and procedures, generating and maintaining baselines, tracking change requests and controlling changes, documenting results, and performing configuration audits.

⭐ Key Takeaways

Maturity Level 2 in CMMI Staged Representation transforms an organization from ad-hoc, heroics-dependent Level 1 to a managed state through seven process areas that establish fundamental project management discipline. The hardest jump in the entire CMMI model is Level 1 to Level 2, and success requires institutionalizing processes through ten generic practices applied across all PAs. Requirements Management (REQM) establishes scope control by managing existing requirements, while Project Planning (PP) and Project Monitoring and Control (PMC) form an inseparable pair—a credible plan is essential for effective monitoring and corrective action. Supplier Agreement Management (SAM) is unique as the only PA that can be tailored out if irrelevant, and Measurement and Analysis (M&A) emphasizes tying measurements to business goals rather than collecting data for its own sake. Process and Product Quality Assurance (PPQA) is the most frequently abused PA and requires truly objective evaluation, while Configuration Management (CM) ensures work product integrity through baselines, change control, and auditing.

🧠 Quick Revision Questions

1. What is the fundamental difference between Maturity Level 1 and Maturity Level 2 processes?
2. What are the seven process areas that make up Maturity Level 2, and which one is the only PA that can be tailored out?
3. Why is Requirements Management (REQM) at Level 2 different from Requirements Development at Level 3?
4. Why can't Project Monitoring and Control (PMC) be satisfied without first having a credible Project Plan (PP)?
5. What is the basic nine-step approach to measurement, and why must you "measure your measures"?

📘 Lecture 16 — CMMI Staged – Maturity Level 3

📖 Overview: This lecture covers Maturity Level 3 of the CMMI staged representation, where an organization moves from project-level management to institutionalizing an organization-wide way of doing business. It details the attributes of a process, the distinction between managed and defined processes, and introduces the eleven process areas required at Level 3, including Requirements Development, Technical Solution, and Product Integration.

🗂️ Topics Covered

The lecture begins by explaining the fundamental shift from Level 2 to Level 3, where best practices from projects are aggregated into an Organizational Set of Standard Processes (OSSP) with a tailoring mechanism. It then defines the standard attributes of a process and distinguishes between a managed process and a defined process. The core of the lecture lists the eleven process areas for Level 3 and provides a detailed breakdown of three of them: Requirements Development (RD), Technical Solution (TS), and Product Integration (PI), including their specific goals, practices, and common pitfalls.

📝 Lecture Summary

Maturity Level

Maturity Level 3 differs from Level 2 because an organizational way of doing business has been developed. The best practices and lessons learned from projects have bubbled up to the organizational level to create an organizational identity. There are common, shared approaches for performing daily tasks on each project. For example, estimating the size of a project may be done using the Delphi Technique, a standard metric may have been institutionalized (such as using function points instead of lines of code), and a standard tool may be in use to calculate the size.

This organizational way of doing business is documented in the Organization’s Set of Standard Processes (OSSP). However, should a project need to tailor this OSSP to fit its needs more adequately, then that tailoring request is brought to a decision-making body (usually the Engineering Process Group [EPG] ), and if appropriate, the request is granted. An example may be a legacy system that calculates size by lines of code instead of by function point. Rather than reengineer the millions of lines of code, the project is simply allowed to continue calculating size by lines of code. To perform at Level 3, an organization must have satisfied all of the goals for all of the process areas (PAs) in both Level 2 and Level 3. Sometimes exceptions may be made, but caution should be exercised. Entire process areas are generally not allowed to be tailored out of consideration. Practices may be tailored out if replaced by sufficient alternative practices.

💡 Why this matters: The shift to Level 3 represents a cultural change where project-level successes become organization-wide standards, enabling more predictable and repeatable performance across the entire enterprise.

Attributes of a Process suggested by CMMI

A process must have clearly defined attributes:

• Purpose—The 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, stated as a verb.)
• Activities—Tasks that must be performed, often broken down into detailed procedures.
• 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.)
• 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.)

Managed Process

Another distinction is made concerning processes. A managed process is a process that tackles project management efforts, is planned and executed according to a policy, is monitored, and reviewed to ensure adherence to its process description. This is the type of process expected at Maturity Level 2.

Defined Process

A defined process builds upon a managed process by creating an organizational process that is then tailored to fit the needs of a particular project and involves gathering information related to improvement efforts undertaken by the organization in order to improve both the organization-level process and the project-level process.

Process Areas for Maturity Level 3

The process areas for Maturity Level 3 are:

• Requirements Development
• Technical Solution
• Product Integration
• Verification
• Validation
• Organizational Process Focus
• Organizational Process Definition (with IPPD)
• Organizational Training
• Integrated Project Management (with IPPD)
• Risk Management
• Decision Analysis and Resolution

To satisfy the goals for Level 3, the goals for Level 2 must be satisfied as well. This mandate holds true for both the specific goals and the generic goals. There are two generic goals for levels 2 and 3:

• GG2 Institutionalize a Managed Process
• GG3 Institutionalize a Defined Process

GG2 Institutionalize a Managed Process – Generic Practices

The generic practices for GG2 are:

• 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

GG3 Institutionalize a Defined Process – Generic Practices

The generic practices for GG3 are:

• GP 3.1 Establish a Defined Process
• GP 3.2 Collect Improvement Information

PA 1 – Requirements Development (RD)

The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements. This process area is where requirements are created and documented, while Requirements Management at Level 2 is where changes are administered. RD gathers requirements and then refines them—stating them more clearly, determining redundancy or inconsistency, and breaking them down into more detailed and traceable requirements. Even maintenance shops have development since there are always new requirements or changes to existing ones. This process area introduces the Concept of Operations or, using the CMMI term, operations concept, which is a high-level statement of desired functionality and a preliminary plan to justify the project.

Specific goals for this process area are:

• SG1 Develop Customer Requirements
  • SP 1.1 Elicit Needs
  • SP 1.2 Develop the Customer Requirements
• SG2 Develop Product Requirements
  • SP 2.1 Establish Product and Product Component Requirements
  • SP 2.2 Allocate Product Component Requirements
  • SP 2.3 Identify Interface Requirements
• SG3 Analyze and Validate Requirements
  • SP 3.1 Establish Operational Concepts and Scenarios
  • SP 3.2 Establish a Definition of Required Functionality
  • SP 3.3 Analyze Requirements
  • SP 3.4 Analyze Requirements to Achieve Balance
  • SP 3.5 Validate Requirements

Things People Forget:

• Maintenance shops also do development.
• Even if you get your requirements directly from the customer, some refinement and analysis is always necessary.
• Developing and analyzing requirements never stops until the entire application is delivered or dead and buried.
• There are no generic practices that directly map to this process area.

PA 2 – Technical Solution (TS)

The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. In this process area, when the model refers to processes, it generally means design processes, not process improvement–type processes. Peer reviews are mentioned in this process area. A key thing people forget is that alternative solutions should be investigated.

Specific goals for Technical Solution are:

• SG1 Select Product Component Solutions
  • SP 1.1 Develop Alternative Solutions and Selection Criteria
  • SP 1.2 Select Product Component Solutions
• SG2 Develop the Design
  • SP 2.1 Design the Product or Product Component
  • SP 2.2 Establish a Technical Data Package
  • SP 2.3 Design Interfaces Using Criteria
  • SP 2.4 Perform Make, Buy, or Reuse Analyses
• SG3 Implement the Product Design
  • SP 3.1 Implement the Design
  • SP 3.2 Develop Product Support Documentation

PA 3 – Product Integration

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product functions properly, and deliver the product. This is where the product comes together and you get to see the results of your work. It is also where you deliver the product, which means you get paid. This process area expects the project to demonstrate each step to the user. This process area is not release management.

Specific goals for this process area are:

• SG1 Prepare for product integration
  • SP 1.1 Determine Integration Sequence
  • SP 1.2 Establish the Product Integration Environment
  • SP 1.3 Establish Product Integration Procedures and Criteria
• SG2 Ensure Interface Compatibility
  • SP 2.1 Review Interface Descriptions for Completeness
  • SP 2.2 Manage Interfaces
• SG3 Assemble Product Components and Deliver the Product
  • SP 3.1 Confirm Readiness of Product Components for Integration
  • SP 3.2 Assemble Product Components
  • SP 3.3 Evaluate Assembled Product Components
  • SP 3.4 Package and Deliver the Product or Product Component

Things People Forget:

• The nightly build does not satisfy all of the Product Integration process area practices.
• You must analyze the problems that occur and see if any of the integrated components conflict with remaining components.
• The emphasis is on being proactive and identifying problems early, rather than being reactive to problems that pop up during the nightly run.
• There are no generic practices that directly map to this process area.

🔑 Definition — Delphi Technique: A technique where subject matter experts discuss best-case and worst-case estimates to arrive at a project estimate.

🔑 Definition — OSSP (Organization’s Set of Standard Processes): The documented set of organizational standard processes that defines the organization-wide way of doing business.

🔑 Definition — EPG (Engineering Process Group): The decision-making body that reviews and approves tailoring requests to the OSSP.

🔑 Definition — Managed Process: A process that tackles project management efforts, is planned and executed according to a policy, is monitored, and reviewed to ensure adherence to its process description (expected at Level 2).

🔑 Definition — Defined Process: A process that builds upon a managed process by creating an organizational process that is tailored to fit the needs of a particular project (expected at Level 3).

🔑 Definition — Concept of Operations (Operations Concept): A high-level statement of the desired functionality, and a preliminary plan and schedule for development, to justify initiating a new project.

⭐ Key Takeaways

At Maturity Level 3, an organization establishes a standard way of doing business documented in the OSSP, which projects can tailor with approval from the EPG. The key distinction is between a managed process (Level 2, project-level planning and monitoring) and a defined process (Level 3, organizational standards that are tailored). The three process areas detailed—Requirements Development, Technical Solution, and Product Integration—cover creating and refining requirements, designing technical solutions with alternative analysis, and assembling and delivering the final product. A critical exam point is that even maintenance organizations perform development activities and must refine requirements, and that the nightly build does not satisfy the proactive analysis required by Product Integration.

🧠 Quick Revision Questions

1. What is the fundamental difference between a managed process (Level 2) and a defined process (Level 3)?
2. What is the role of the Engineering Process Group (EPG) in the context of the OSSP at Maturity Level 3?
3. What is the primary purpose of Requirements Development (RD), and how does it differ from Requirements Management?
4. In the Technical Solution (TS) process area, what is a common mistake organizations make regarding solution selection?
5. Why does a "nightly build" alone not satisfy all the practices of the Product Integration (PI) process area?

📘 Lecture 17 — CMMI Staged – Maturity Level 3 (Continue...)

📖 Overview: This lecture covers all eleven Process Areas (PAs) at CMMI Maturity Level 3, focusing on their purposes, specific goals, and specific practices. It explains how these PAs move beyond basic project management to establish organization-wide processes, proactive risk management, and formal decision-making, which are critical for predictable and mature software development.

🗂️ Topics Covered

This lecture details the eleven Process Areas for Maturity Level 3: Verification (VER) and Validation (VAL) for ensuring product quality; Organizational Process Focus (OPF), Organizational Process Definition (OPD), and Organizational Training (OT) for establishing and improving organization-wide capabilities; Integrated Project Management (IPM) for using defined, tailored processes; Risk Management (RSKM) for proactive risk handling; and Decision Analysis and Resolution (DAR) for formal decision-making. Each PA is broken down into specific goals and specific practices.

📝 Lecture Summary

PA 4 – Verification

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements. It allows the use of test setups and test simulators, which may also be used for Validation but for different purposes. Acceptance testing is mentioned here.

🔑 Definition — Verification (VER): A process area to ensure that selected work products meet their specified requirements. 📐 Formula: SG1 Prepare for Verification → SP 1.1 Select Work Products, SP 1.2 Establish Verification Environment, SP 1.3 Establish Procedures and Criteria. 📐 Formula: SG2 Perform Peer Reviews → SP 2.1 Prepare, SP 2.2 Conduct, SP 2.3 Analyze Data. 📐 Formula: SG3 Verify Selected Work Products → SP 3.1 Perform Verification, SP 3.2 Analyze Results. 📌 Example: A development team selects a specific module's code for verification. They set up a test environment with simulators, write test cases (procedures) defining expected outcomes (criteria). They then conduct a peer review with other coders to find errors, and after that, run the tests. Any failures are documented as verification results for analysis. 💡 Why this matters: Verification includes both peer reviews and testing to ensure total product coverage. Key reminders: you cannot test in quality, a peer review board is not one person, and errors found must be resolved. There are no generic practices that directly map to this process area.

PA 5 – Validation

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

🔑 Definition — Validation (VAL): A process area to demonstrate that a product fulfills its intended use in its intended environment. 📐 Formula: SG1 Prepare for Validation → SP 1.1 Select Products, SP 1.2 Establish Environment, SP 1.3 Establish Procedures and Criteria. 📐 Formula: SG2 Validate Product or Product Components → SP 2.1 Perform Validation, SP 2.2 Analyze Validation Results. 📌 Example: For a new air traffic control system, the team selects the final software build for validation. They establish a test environment that mimics a real control tower, with simulated flight data. They then run the software in this environment, observing if it correctly tracks aircraft and alerts controllers as intended. Any deviations are analyzed as validation results. 💡 Why this matters: Validation is not just an end-of-project activity; it can be performed throughout the development life cycle. If a web-based system is developed and tested using the same environment and procedures users will employ, this process area might be satisfied without extra effort. There are no general practices that directly map to this process area.

PA 6 – Organizational Process Focus

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of the organization’s current strengths and weaknesses and its process assets. The Engineering Process Group (EPG) is introduced here as the group responsible for this.

🔑 Definition — Organizational Process Focus (OPF): A process area to plan, implement, and deploy process improvements based on understanding current processes. 🔑 Definition — Engineering Process Group (EPG): The group responsible for planning and implementing process improvement. 📐 Formula: SG1 Determine Process Improvement Opportunities → SP 1.1 Establish Needs, SP 1.2 Appraise Processes, SP 1.3 Identify Improvements. 📐 Formula: SG2 Plan and Implement Process Improvements → SP 2.1 Establish Action Plans, SP 2.2 Implement Action Plans. 📐 Formula: SG3 Deploy Process Assets and Incorporate Lessons Learned → SP 3.1 Deploy Assets, SP 3.2 Deploy Standard Processes, SP 3.3 Monitor Implementation, SP 3.4 Incorporate Experiences. 💡 Why this matters: This process area describes a cycle like the IDEAL model (Initiating, Diagnosing, Establishing, Acting, Learning). A key tip is to not try to change everything at once and to rotate EPG members after one or two years to inject new thinking. The generic practice that most closely maps is GP 3.2 Collect Improvement Information.

PA 7 – Organizational Process Definition (with IPPD)

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards. For IPPD, it also covers rules and guidelines for integrated teams. IPPD is applicable to specific DOD projects and is considered optional.

🔑 Definition — Organizational Process Definition (OPD): A process area to establish and maintain a usable set of organizational process assets (e.g., the Organization’s Set of Standard Processes OSSP). 📐 Formula: SG1 Establish Organizational Process Assets → SP 1.1 Establish Standard Processes, SP 1.2 Establish Life Cycle Model Descriptions, SP 1.3 Establish Tailoring Criteria and Guidelines, SP 1.4 Establish Measurement Repository, SP 1.5 Establish Process Asset Library, SP 1.6 Establish Work Environment Standards. 💡 Why this matters: A common challenge is finding the right level of detail for documenting processes—they can be too complex or too high-level. The OPD creates the OSSP, describes approved life cycles, and creates tailoring guidelines and the measurement repository. The generic practice that most closely matches is GP 3.1 Establish a Defined Process.

PA 8 – Organizational Training

The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently. This process area expects a Strategic Training Plan derived from the OSSP, business plans, and defined skill sets.

🔑 Definition — Organizational Training (OT): A process area to develop skills and knowledge for people to perform their roles effectively. 📐 Formula: SG1 Establish an Organizational Training Capability → SP 1.1 Establish Strategic Training Needs, SP 1.2 Determine Organizational Responsibility, SP 1.3 Establish Tactical Plan, SP 1.4 Establish Capability. 📐 Formula: SG2 Provide Necessary Training → SP 2.1 Deliver Training, SP 2.2 Establish Records, SP 2.3 Assess Effectiveness. 📌 Example: An organization identifies a strategic need to move to cloud-based development. They determine that project teams need training on AWS. A tactical plan is created for the coming year, scheduling specific AWS courses and a budget. The project plans then use this as input to schedule their team members for the training. After training, effectiveness is assessed via a test or project performance. 💡 Why this matters: This PA is about organizational training, not knowledge management (for which you would consult People CMM). Organizations must evaluate the effectiveness of training received. The generic practices that most closely match are GP 2.5 Train People (organizational view) and GP 2.2 Plan the Process (project perspective).

PA 9 – Integrated Project Management (with IPPD)

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes (OSSP). This PA is seen as the evolution of Project Planning (PP) and Project Monitoring and Control (PMC) from Level 2.

🔑 Definition — Integrated Project Management (IPM): A process area to manage a project using an integrated, defined process tailored from the organization’s standard processes. 🔑 Definition — Project’s Defined Process (PDP): A documented, step-by-step description of how a project will function, tailored from the OSSP. 📐 Formula: SG1 Use the Project’s Defined Process → SP 1.1 Establish the PDP, SP 1.2 Use Process Assets, SP 1.3 Establish Work Environment, SP 1.4 Integrate Plans, SP 1.5 Manage Using Integrated Plans, SP 1.6 Contribute to Process Assets. 📐 Formula: SG2 Coordinate and Collaborate with Relevant Stakeholders → SP 2.1 Manage Stakeholder Involvement, SP 2.2 Manage Dependencies, SP 2.3 Resolve Coordination Issues. 💡 Why this matters: The key difference from Level 2 management is that Level 3 uses a set of organizational plans, processes, and assets (like templates and checklists) based on best practices and lessons learned. The PDP is created by tailoring the OSSP and is then used to build the project plan. In small, non-diverse organizations, the OSSP can be used directly as the PDP. The generic practice GP 3.1 Establish a Defined Process most closely matches this PA.

PA 10 – Risk Management

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. This is much more proactive than Level 2 risk management.

🔑 Definition — Risk Management (RSKM): A process area to identify potential problems proactively and plan risk-handling activities to mitigate adverse impacts. 📐 Formula: SG1 Prepare for Risk Management → SP 1.1 Determine Risk Sources and Categories, SP 1.2 Define Risk Parameters, SP 1.3 Establish a Risk Management Strategy. 📐 Formula: SG2 Identify and Analyze Risks → SP 2.1 Identify Risks, SP 2.2 Evaluate, Categorize, and Prioritize Risks. 📐 Formula: SG3 Mitigate Risks → SP 3.1 Develop Risk Mitigation Plans, SP 3.2 Implement Risk Mitigation Plans. 📌 Example: A project team defines categories like "Technical Risk" (e.g., new technology not working). They set parameters like "Probability" (1-5) and "Impact" (1-5). They identify a risk: "The new database may not handle the required load." They evaluate it with Probability=4, Impact=5, giving a priority score of 20. A mitigation plan is created: "Run a load test on a prototype within the first month." The plan is then implemented. 💡 Why this matters: This PA requires studying and measuring a risk's impact and probability. Periodic and event-driven reviews should summarize the most critical risks. Disaster recovery may be included as part of the organization's risk management culture. There are no generic practices that directly map to this process area.

PA 11 – Decision Analysis and Resolution

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

🔑 Definition — Decision Analysis and Resolution (DAR): A process area to analyze possible decisions using a formal evaluation process with established criteria. 📐 Formula: SG1 Evaluate Alternatives → SP 1.1 Establish Guidelines for Decision Analysis, SP 1.2 Establish Evaluation Criteria, SP 1.3 Identify Alternative Solutions, SP 1.4 Select Evaluation Methods, SP 1.5 Evaluate Alternatives, SP 1.6 Select Solutions. 📌 Example: A project must choose a new code editor. They establish guidelines that DAR must be used for purchases over $1000. They create evaluation criteria: cost, features, ease of use (weighted). They identify alternatives: Editor A, B, and C. They select a method (e.g., weighted scoring matrix). They evaluate each editor against the criteria, then select the highest-scoring solution. 💡 Why this matters: The organization must define when this PA should be used to avoid overuse or underuse. All changes to evaluation criteria must be documented, including the reason, who initiated it, and the impact. There are no generic practices that directly map to this process area.

⭐ Key Takeaways

This lecture covers the eleven Process Areas of CMMI Maturity Level 3, which moves an organization from project-specific management to organization-wide process standardization. The Engineering PAs (Verification & Validation) ensure product quality through both peer reviews and testing in simulated or actual environments. The Process Management PAs (OPF, OPD, OT) establish the infrastructure for continuous process improvement, including creating a standard process library and providing strategic training. The Project Management PAs (IPM, RSKM) evolve Level 2 concepts by requiring defined, tailored processes for each project and proactive, quantified risk management. Finally, the Support PA (DAR) ensures that critical decisions are made formally and objectively using established criteria and alternatives.

🧠 Quick Revision Questions

1. What is the main difference between Verification (VER) and Validation (VAL) according to this lecture?
2. What is the role of the Engineering Process Group (EPG) mentioned in the Organizational Process Focus (OPF) process area?
3. How does Integrated Project Management (IPM) differ from Level 2 Project Planning (PP)?
4. What is a key requirement for using the Decision Analysis and Resolution (DAR) process area effectively in an organization?
5. Why is it important to review risks periodically during a project, even if no new risks are identified?

📘 Lecture 18 — CMMI Staged – Maturity Level 4

📖 Overview: This lecture explores CMMI Maturity Level 4, where organizations manage processes "by the numbers" using quantitative data and statistical control. It details the two key process areas — Organizational Process Performance and Quantitative Project Management — and how they build upon Levels 2 and 3. The lecture also introduces Level 5 concepts, focusing on continuous process improvement through Organizational Innovation and Deployment and Causal Analysis and Resolution.

🗂️ Topics Covered

This lecture covers the concept of Level 4 maturity as a quantitatively managed plateau where organizational decisions are driven by numerical data. It explains the Organizational Process Performance (OPP) process area, which establishes performance baselines and models, and the Quantitative Project Management (QPM) process area, which manages projects against quantitative objectives. The lecture then moves to Level 5, covering Organizational Innovation and Deployment (OID) for selecting and deploying process improvements, and Causal Analysis and Resolution (CAR) for identifying and preventing root causes of defects.

📝 Lecture Summary

Staged Representation

The staged representation is the approach used in the Software CMM, using 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, which is a well-defined evolutionary plateau toward achieving improved organizational processes.

Level 4

Level 4 is all about numbers. Projects are managed "by the numbers," organizational decisions are made "by the numbers," and processes, services, and product quality are all measured "by the numbers." At Level 4, the organization has achieved all of the goals of Levels 2 and 3. Processes, although qualitatively stable and predictable at Level 3, can be proved to be quantitatively stable and predictable at Level 4. Level 4 analyzes the data collected, determines special causes of variation from the norm, and supports quantitative management and control. This is done to make your processes predictable.

To get "good" data, an organization usually has to collect data for several years, or at least through several projects and several life cycles of the projects. When you first begin collecting data, it will not be consistent. Measurements data are collected beginning with Level 2 in the staged representation, but the data are not clean and consistent because the processes used on the projects are not yet stable and consistent. An organization cannot go to Level 4 overnight.

At Level 3, measures are collected and preliminary thresholds are established, usually relating to size and effort. At Level 4, the control limits are based on years of historical data and trends analyses. More data are collected, and more limits are established, monitored, and refined. At Level 3, the data may be somewhat inconsistent and "dirty," whereas Level 4 expects stabilized, normalized, statistically accurate data.

Process Areas at Level 4

There are no additions to the list of generic goals at Level 4 from Level 3. What makes this maturity level different are the two process areas: Organizational Process Performance and Quantitative Project Management. To satisfy the goals for Level 4, the goals for Levels 2 and 3 must be satisfied as well, both for specific goals and generic goals (GG2 Institutionalize a Managed Process and GG3 Institutionalize a Defined Process).

PA 1 – Organizational Process Performance

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 (OSSP) 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 Goal for Level 4: SG1 Establish Performance Baselines and Models
• Specific Practices: SP 1.1 Select Processes; SP 1.2 Establish Process–performance Measures; SP 1.3 Establish Quality and Process–performance Objectives; SP 1.4 Establish Process–performance Baselines; SP 1.5 Establish Process–performance Models

This process area includes measurements for both process and product, and service has also been specifically presented as an area appropriate for measurement. A process performance baseline (PPB) documents the historical results achieved by following a process and is used as a benchmark for comparing actual process performance against expected process performance. A process performance model (PPM) describes the relationships among attributes (for example, defects) of a process and its work products. A PPM is used to estimate or predict a critical value that cannot be measured until later in the project’s life.

The most common measurements used are size, effort, cost, schedule, and product defect density. Performance-related measurements can include schedule variance (lateness), effort variance, and unplanned tasks. Quality-related measurements may include rework and defects collected during all life-cycle phases. Common process-related measures are related to productivity at different phases of life cycles.

🔑 Definition — Process Performance Baseline (PPB): Documents the historical results achieved by following a process. It is used as a benchmark for comparing actual process performance against expected process performance. 🔑 Definition — Process Performance Model (PPM): Describes the relationships among attributes of a process and its work products. It is used to estimate or predict a critical value that cannot be measured until later in the project’s life. 📌 Example: At Level 3, measures are collected in a database per project. In Level 2, measures bubble up to an organizational database. At Level 3, data are reviewed for consistency and accuracy. Then at Level 4, statistically-based controls are applied.

Things People Forget: The organization either builds too many models or not enough. Nobody really understands the models that are built (except maybe the person who built them). The models aren’t really used to make decisions.

PA 2 – Quantitative Project Management

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.

• Specific Goals: SG1 Quantitatively Manage the Project; SG2 Statistically Manage Sub-process Performance
• Specific Practices (SG1): SP 1.1 Establish the Project’s Objectives; SP 1.2 Compose the Defined Process; SP 1.3 Select the Sub-processes That Will Be Statistically Managed; SP 1.4 Manage Project Performance
• Specific Practices (SG2): SP 2.1 Select Measures and Analytic Techniques; SP 2.2 Apply Statistical Methods to Understand Variation; SP 2.3 Monitor Performance of the Selected Sub-processes; SP 2.4 Record Statistical Management Data

In this process area, usage of the organizational level measurement repository is refined. Experienced managers and measurement personnel identify measures, senior level project personnel collect the measures, and projects use the measures. Project managers should do at least a weekly review of the project measures. Repositories require years of historical data using the same, normalized data, with reviews and analyses of these data.

💡 Why this matters: Level 4 is where senior management commitment and participation really come to the fore. Business decisions are supposed to be made based on the numbers. Most small organizations will find this level very difficult to implement due to the number of people needed and the type of expertise required.

Things People Forget: Make sure the project manager (or whoever will use these data) is involved in determining which measures are needed. Train both the people collecting data and those who will use it. Show how the project’s defined process was changed, reviewed, or influenced by these data.

CMMI Staged – Maturity 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 Level 5 is that Level 4 analyzes data for special causes of variation, while Level 5 addresses common causes of variation. Level 5 concentrates on improving the overall quality of the organization’s processes by:

• Identifying common causes of variation
• Determining root causes of the conditions identified
• Piloting process improvements
• Incorporating improvements into the OSSP

Although innovative, radical approaches to introduce change 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
• No additions to generic goals at Level 5 from Level 3.

PA 1 – Organizational Innovation and Deployment

The purpose of Organizational Innovation and Deployment (OID) is to select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies. The improvements support the organization’s quality and process–performance objectives as derived from the organization’s business objectives.

• Specific Goals: SG1 Select Improvements; SG2 Deploy Improvements
• SG1 Specific Practices: SP 1.1 Collect and Analyze Improvement Proposals; SP 1.2 Identify and Analyze Innovations; SP 1.3 Pilot Improvements; SP 1.4 Select Improvements for Deployment
• SG2 Specific Practices: SP 2.1 Plan the Deployment; SP 2.2 Manage the Deployment; SP 2.3 Measure Improvement Effects

In OID, proposals are subjected to quantitative analysis. Metrics from the historical database, as well as defects and where they were introduced, are reviewed to determine where and how to make improvements. Steps include submitting proposals, analyzing them (including cost-benefit review), piloting the improvement, measuring effectiveness, planning deployment, deploying, and measuring effectiveness across the organization.

Things People Forget: You must pilot your improvement! Only piloting can accurately predict whether an improvement will work. Many organizations skip this step, which is a wrong approach.

PA 2 – Causal Analysis and Resolution

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of defects and other problems and take action to prevent them from occurring in the future.

• Specific Goals: SG1 Determine Causes of Defects; SG2 Address Causes of Defects
• SG1 Specific Practices: SP 1.1 Select Defect Data for Analysis; SP 1.2 Analyze Causes
• SG2 Specific Practices: SP 2.1 Implement the Action Proposals; SP 2.2 Evaluate the Effect of Changes; SP 2.3 Record Data

This process area looks at defects and determines their root cause — the most basic reason why the defect occurred, such that if that cause is removed, the defect vanishes. Steps include looking at defects and problems, selecting data to analyze, analyzing causes, preparing proposals to address problems, implementing proposals, and evaluating the effects of changes.

Things People Forget: You are analyzing defects of the process. The defects of the process may result in product defects. The processes under review should be quantitatively managed processes — those studied and implemented using Level 4 concepts.

🔑 Definition — Root Cause: The most basic reason why a defect occurred (or the source of the defect). If that cause is removed, the defect vanishes.

Summary of Level 5

The focus at Level 5 is on improving processes using the OSSP as the controlling document. Level 5 tries to find common causes and fix them, resulting in overall improvements. Measurements are used to select improvements, estimate costs and benefits, and prove actual results. There are two types of improvement strategies: innovative (introducing radical changes) and incremental (building on earlier improvements). Incremental approaches tend to have more long-lasting effects and lead to easier institutionalization.

⭐ Key Takeaways

Maturity Level 4 is about quantitative management "by the numbers," requiring years of stable, consistent historical data to establish control limits, baselines, and models. The two key process areas are Organizational Process Performance (establishing PPBs and PPMs) and Quantitative Project Management (statistically managing sub-processes). Level 5 extends this by addressing common causes of variation through Organizational Innovation and Deployment (piloting improvements before deployment) and Causal Analysis and Resolution (finding and eliminating root causes of defects). Organizations must progress sequentially through maturity levels, as Level 4 requires stable processes from Level 3, and Level 5 requires quantitative processes from Level 4. Most organizations find incremental, piloted improvements more effective than radical approaches.

🧠 Quick Revision Questions

1. What is the key difference between Level 3 and Level 4 regarding process stability?
2. What are the two process areas at CMMI Level 4, and what is the purpose of each?
3. What is a Process Performance Baseline (PPB) and a Process Performance Model (PPM)?
4. What distinguishes Level 5 from Level 4 in terms of variation analysis?
5. Why is piloting improvements considered essential in the Organizational Innovation and Deployment process area?

📘 Lecture 19 — Introduction to CMMI Continuous Representation

📖 Overview: This lecture introduces the CMMI Continuous Representation, a process improvement approach that allows organizations to focus on specific process areas. It covers the structure of the model, including process area categories, capability levels, and how goals and practices are organized. This is crucial for understanding how to tailor process improvement to an organization's specific needs.

🗂️ Topics Covered

The lecture covers the fundamental concepts of the CMMI Continuous Representation, including its model components, the Process Area Categories (Process Management, Project Management, Engineering, Support), the relationship between specific and generic goals and practices, the definition and description of six capability levels (0 to 5), process area capability profiles, target profiles, and the cumulative nature of capability levels.

📝 Lecture Summary

Continuous Representation

The continuous representation is an approach that allows an organization to select a specific process area and improve relative to it, rather than improving all process areas at once. This approach uses capability levels to characterize improvement relative to an individual process area.

🔑 Definition — Continuous Representation: An approach to process improvement that allows an organization to select a specific process area and improve it to a defined capability level.

CMMI Model Components in the Continuous Representation

The continuous representation has specific goals that organize specific practices and generic goals that organize generic practices. Each specific and generic practice corresponds to a capability level. Specific goals and specific practices apply to individual process areas. While using the same basic structure as the staged representation, each Process Area (PA) belongs to a Process Area Category, which is a simple way of arranging PAs by their related, primary functions.

Process Area Categories

There are four process area categories:

• Process Management: PAs consist of common functions related to defining, planning, implementing, and monitoring a process. They all reside at the organizational level and are listed in increasing order of sophistication.
• Project Management: PAs consist of functions related to planning, tracking, and controlling projects, and are listed in increasing order of sophistication.
• Engineering: PAs consist of technical functions related to building and delivering a product, and are listed in increasing order of sophistication.
• Support: PAs consist of related support functions related to managing changes, ensuring quality, measuring results, and structured decision-making.

💡 Why this matters: These categories help an organization group related processes and focus improvement efforts on specific business functions.

Goals and Practices

Specific goals and practices relate to specific process areas and to tasks that make sense for that process area only. Generic goals and practices relate to multiple process areas. For example, to achieve Capability Level 2 for Requirements Management, an organization must also establish an organizational policy, plan the process, and train people. Both specific and generic goals must be satisfied to achieve a capability level. Each capability level has one generic goal associated with it.

Generic Goals and Practices

Each Generic Goal (GG) and its associated Generic Practices (GPs) are defined:

• Generic Goal 1: Achieve Specific Goals of Each Process Area
• Generic Practice GP 1.1: Perform Specific Practices
• Generic Goal 2: Institutionalize a Managed Process
• Generic Practices GP 2.1 – 2.10: Cover activities like establishing policy (Project Planning), planning (Project Planning), training (Organizational Training), and monitoring (Project Monitoring and Control).
• Generic Goal 3: Institutionalize a Defined Process
• Generic Practices GP 3.1 & 3.2: Focus on establishing a defined process (Integrated Project Management) and collecting improvement information (Integrated Project Management, Organizational Process Focus).
• Generic Goal 4: Institutionalize a Quantitatively Managed Process
• Generic Practices GP 4.1 & 4.2: Involve establishing quantitative objectives (Quantitative Project Management, Organizational Process Performance) and stabilizing sub-process performance (Quantitative Project Management, Organizational Process Performance).
• Generic Goal 5: Institutionalize an Optimizing Process
• Generic Practices GP 5.1 & 5.2: Focus on continuous process improvement (Organizational Innovation and Deployment) and correcting root causes (Causal Analysis and Resolution).

Continuous Representation vs. Staged

The continuous representation has the same basic information as the staged representation, but arranged differently using capability levels and process area categories. It focuses process improvement on actions to be completed within process areas.

What is a Capability Level?

A Capability Level focuses on maturing an organization's ability to perform, control, and improve its performance in a specific process area. This allows the organization to focus improvement efforts where they are most needed.

🔑 Definition — Capability Level: A measure of how well an organization performs a specific process area, ranging from Incomplete (Level 0) to Optimizing (Level 5).

Capability Levels

There are six capability levels:

• Level 0: Incomplete: An incomplete process does not implement all of the Capability Level 1 specific practices. It’s similar to Maturity Level 1 in staged representation.
• Level 1: Performed: A Capability Level 1 process performs all of the Capability Level 1 specific practices. Performance may not be stable, but useful work can be done.
• Level 2: Managed: A managed process is planned, performed, monitored, and controlled for individual projects. It ensures the process achieves its objectives, including cost, schedule, and quality.
• Level 3: Defined: A defined process is a managed process that is tailored from the organization's set of standard processes. Deviations outside of tailoring guidelines are documented, justified, reviewed, and approved.
• Level 4: Quantitatively Managed: A quantitatively managed process is a defined process controlled using statistical and other quantitative techniques. Product quality and process performance are understood in statistical terms.
• Level 5: Optimizing: An optimizing process is a quantitatively managed process that is improved based on an understanding of the common causes of process variation. It focuses on continually improving through both incremental and innovative improvements.

💡 Why this matters: Capability levels allow an organization to precisely track its progress in mastering a specific process area.

Process Area Capability Profile

A process area capability profile can be represented by a set of points in two dimensions:

• The Process Dimension: Describes what you do (the process areas selected).
• The Capability Dimension: Describes how well you do it (the capability levels achieved).

Target Profile

A target profile is a list of process areas and their corresponding capability levels that an organization aims to achieve. Target staging is a sequence of target profiles that describes the path of process improvement an organization will take.

🔑 Definition — Target Profile: A list of process areas and the capability levels an organization aims to achieve for each.

Achievement Profile

An achievement profile is used in the continuous representation. It is a bar chart of each process area that shows how much of the PA has been achieved and how much has not.

🔑 Definition — Achievement Profile: A visual representation (bar chart) of each process area showing the capability level achieved.

Generic Practices Relating to Process Areas

Generic practices are used to determine if generic goals have been satisfied. An organization using the continuous representation must satisfy the basic concepts of Maturity Level 2 (i.e., planning, managing changes) for every process area they select. The continuous representation was designed to tailor the model and process improvement approaches focusing on specific categories that match areas where problems exist.

⭐ Key Takeaways

The key takeaway is that the continuous representation allows organizations to focus on improving specific process areas using capability levels, unlike the staged representation which requires an organization to improve all process areas to a certain maturity level. The model is organized into four process area categories—Process Management, Project Management, Engineering, and Support—which help group related functions. Both specific and generic goals must be met to achieve a capability level, and importantly, generic practices for lower levels (like planning and monitoring) must be addressed even if the corresponding process area wasn't selected. Target and achievement profiles are essential tools for planning and tracking progress in a continuous representation improvement path.

🧠 Quick Revision Questions

1. What is the main difference between the CMMI Continuous and Staged representations?
2. Name the four Process Area Categories in the Continuous Representation.
3. Explain the difference between a Specific Goal and a Generic Goal in CMMI.
4. List the six capability levels from 0 to 5.
5. What is a Target Profile, and how is it used in process improvement?

📘 Lecture 20 — Personal Software Process (PSP)

📖 Overview: This lecture introduces the Personal Software Process (PSP), a defined and measured software process designed for use by individual software engineers. Developed by Watts Humphrey at the SEI, PSP scales down CMM principles to the personal level, addressing critical business needs for better cost/schedule management, quality improvement, and reduced cycle time. The lecture explains how PSP empowers engineers to take ownership of their process through measurement, planning, and quantitative feedback.

🗂️ Topics Covered

The lecture covers the concept and definition of PSP, its role in cost and schedule management, quality management, cycle time reduction, and organizational process improvement. It provides background on why software businesses need PSP, explains how PSP works, lists the 12 CMM Key Process Areas adapted for PSP, summarizes PSP in a nutshell, and describes the personal improvement process cycle.

📝 Lecture Summary

Concept of PSP

Many viewed the CMM as designed for large organizations and did not see how it could be applied to individual work or small project teams. The SEI started a process research project to examine ways individual software engineers could apply level-5 process principles. After several years of research, means were devised to adapt 12 of the 18 CMM key process areas to the work of individual software engineers.

💡 Why this matters: This shows that high-maturity process principles are not just for large organizations; they can be scaled down for individual use.

What is PSP?

The PSP is a defined and measured software process designed to be used by an individual software engineer. It was developed by Watts Humphrey. Its intended use is to guide the planning and development of software modules or small programs, but it is adaptable to other personal tasks.

🔑 Definition — Personal Software Process (PSP): A defined and measured software process for individual software engineers, based on CMM principles, to guide planning and development.

PSP

Like the SEI Capability Maturity Model for Software (CMM-SW), the PSP is based on process improvement principles. While the CMM-SW focused on improving organizational capability, the focus of the PSP is the individual engineer. To foster improvement at the personal level, PSP extends process management and control to the software engineer. With PSP, engineers develop software using a disciplined, structured approach. Individual engineers follow a defined process, plan, measure, and track their work, manage product quality, and apply quantitative feedback to improve their personal work processes, leading to:

• better estimating
• better planning and tracking
• protection against over-commitment
• a personal commitment to quality
• the engineer's involvement in continuous process improvement

Thus, both the individual and the organization's capability are improved.

Cost and Schedule Management

A critical business need for all organizations that develop software is better cost and schedule management. Cost and schedule problems often begin when projects make commitments that are based on inadequate estimates of size and development resources. PSP addresses this problem by showing engineers how to make better size and resource estimates using statistical techniques and historical data. A more balanced estimation error means that the errors tend to cancel, rather than compound, when multiple estimates are combined.

Quality Management

A second critical business need is for improved software quality. Poor quality management now limits our ability to field many critical systems, increases software development costs, and makes development schedules even harder to predict. Many of these quality problems stem from the practice of relying on testing to manage software quality. But finding and fixing defects in test is costly, ineffective, and unpredictable. The most efficient and effective way to manage software quality is through a comprehensive program focused on removing defects early, at the source. The PSP helps engineers to find and remove defects where they are injected, before compile, inspection, unit test, integration test, or system test. With fewer defects to find and remove in integration and system test, test costs are reduced sharply, schedules are more predictable, fewer defects are released to the field, maintenance and repair costs are reduced, and customer satisfaction is increased.

🔑 Definition — Early Defect Removal: The practice of finding and fixing defects at the point they are injected, before later development phases like compile or test.

Cycle Time

A third critical business need is for reduced product cycle time. Cycle time can be reduced through better planning and the elimination of rework through improvements in product quality. Accurate plans allow for tighter scheduling and greater concurrency among planned activities. Better quality through early defect removal reduces waste and further increases planning accuracy by reducing a source of variation, the discovery and repair of defects in integration and system test. With PSP, engineers learn how to gather the process data needed to minimize cycle time. The data helps them to build accurate plans, eliminate rework, and reduce integration and system test by as much as four to five times.

Organizational Process Improvement

A fourth critical business need is process improvement. It is well understood that process improvement can increase competitive advantage, but it has been difficult to involve software engineers. They often view process improvement and product quality as a management or staff activity, not as their personal responsibility. With PSP, engineers gain personal experience with process improvement. They become process owners, directly involved in the measurement, management, and improvement of the software process.

Background and Introduction

All businesses are becoming software businesses. More and more businesses now develop and incorporate software in the products they produce, or develop software to support the design, manufacture, or delivery of the products and services they provide. Many are finding that as the software component of their business grows, schedule delays, cost overruns, and quality problems caused by software are becoming their number one business problem. Software development has become the high-risk element in their business plans. Moreover, despite their best management efforts, they find their risk of failure increasing with each increase in the size or complexity of the software they produce. Software businesses have at least one thing in common: the business is dependent on people. Software products are made of hundreds to millions of individual computer instructions, each one handcrafted by a software engineer. And so, the technical practices and experience of their engineers largely determine the outcome of the development process. Software businesses also share a common set of needs: better cost and schedule management, improved software quality, and reduced software development cycle time. PSP directly addresses these needs by improving the technical practices and individual abilities of software engineers, and by providing a quantitative basis for managing the development process. By improving individual performance, PSP can improve the performance of the organization, as individual improvements in aggregate are reflected at the organizational level.

How

Data from the PSP improve planning and tracking of software projects. Early defect removal results in higher quality products, as well as reductions in test costs and cycle time. PSP provides a classroom setting for learning and practicing process improvement. Short feedback cycles and personal data make it easier to gain understanding through experience. PSP helps engineers and their managers learn to practice quantitative process management. They learn to use defined processes and collect data to manage, control, and improve the work. Finally, PSP exposes engineers to 12 of the CMM Key Process Areas (KPAs). They are better prepared to participate in CMM-based improvement. The PSP provides a framework for teaching engineers about the software process, and a starting point from which they can evolve their own personal processes. The PSP is based on the same industrial practices that are found in the SEI CMM, but scaled-down for individual use. It is a defined and measured, individualized process for consistently and efficiently developing high quality software modules or small programs. It has been adapted to many other kinds of software engineering tasks, such as developing software requirements, software specifications, and test cases. The PSP can also be scaled up to support small projects by integrating individual personal processes with a project process that was based on the PSP architecture. In general, once learned, the principles and concepts in the PSP can be applied to any structured, repetitive task.

Key Process Areas for PSP

The 12 CMM Key Process Areas (KPAs) adapted for PSP are:

1. Software project planning
2. Software project tracking/oversight
3. Software process focus
4. Software process definition
5. Integrated software management
6. Software product engineering
7. Peer reviews
8. Quantitative process management
9. Quality management
10. Defect prevention
11. Technology change management
12. Process change management

PSP in a Nutshell

PSP in a nutshell involves:

• Baselining your existing personal software process
• Developing a planning process for your software development
• Measuring software size as part of the planning process
• Estimating software size in advance
• Estimating the required schedule and resources for software
• Conducting appropriate measures of one's process
• Conducting meaningful design and code reviews
• Performing software quality management
• Perform software design in a more formal fashion
• Verifying the design, using methods such as object state machines, program tracing, etc.
• Scaling up the PSP to larger problems

Personal Improvement Process

The personal improvement process cycle consists of:

1. Define the quality goals
2. Measure product quality
3. Understand the process
4. Adjust the process
5. Use the adjusted process
6. Measure the results
7. Compare the results with the goal

⭐ Key Takeaways

The PSP is a scaled-down, individualized application of CMM principles for software engineers to improve their personal performance. It addresses critical business needs by directly improving cost/schedule estimation through statistical techniques and historical data, and by promoting early defect removal to enhance quality and reduce cycle time. Engineers become process owners, not just followers, by using defined processes and collecting personal data for quantitative process management. The PSP framework exposes engineers to 12 CMM KPAs and follows a cyclic personal improvement process of defining goals, measuring, understanding, adjusting, and comparing results. Ultimately, improving individual performance through PSP aggregates to improve organizational capability.

🧠 Quick Revision Questions

1. What is the Personal Software Process (PSP) and who developed it?
2. List three critical business needs that PSP directly addresses.
3. How does PSP help improve cost and schedule management?
4. What is the key strategy for quality management in PSP, and why is it effective?
5. Name the steps in the personal improvement process cycle.

📘 Lecture 21 — Implementing PSP

📖 Overview: This lecture explores the Personal Software Process (PSP) as a disciplined framework for individual software engineers to plan, measure, and manage their work. It covers practical implementation strategies focusing on time management and commitment management, then details the four progressive PSP Process Levels that build from baseline measurement to cyclic development for larger projects.

🗂️ Topics Covered

The lecture introduces the PSP as a personal framework for software engineers, then focuses on the logic and strategies of time management including how time is spent and tracked using logs. It defines commitments and their responsible management, outlines the consequences of poor commitment handling, and describes the four PSP Process Levels: Baseline Personal Process, Personal Project Management, Personal Quality Management, and Cyclic Personal Process. Finally, it covers the three basic PSP measures (time, defects, size).

📝 Lecture Summary

PSP

The Personal Software Process (PSP) provides engineers with a disciplined personal framework for doing software work. The PSP process consists of a set of methods, forms, and scripts that show software engineers how to plan, measure, and manage their work. The PSP extends the improvement process to the people who actually do the work—the practicing engineers. The PSP concentrates on the work practices of the individual engineers. The principle behind the PSP is that to produce quality software systems, every engineer who works on the system must do quality work. The PSP is designed to help software professionals consistently use sound engineering practices. It shows them how to plan and track their work, use a defined and measured process, establish measurable goals, and track performance against these goals. The PSP shows engineers how to manage quality from the beginning of the job, how to analyze the results of each job, and how to use the results to improve the process for the next project.

Implementing Personal Software Process

Key parts of implementing personal software process include managing time and managing commitments. A key part of implementing personal software process is managing time accurately. The lecture discusses time management issues and ways to record and store time.

Logic of Time Management

• You will likely spend your time this week much the way you spent it last week
• To make realistic plans, you have to track the way you spend time
• To check the accuracy of your time estimates and plans, you must document them and later compare them with what you actually do
• To make more accurate plans, determine where your plans were in error and what you could have done better
• To manage your time, plan your time and then follow the plan

Product Planning

Product planning involves the size and important features of the product to be produced, an estimate of the time required to do the work, a projection of the schedule, and the relationship between product and period planning.

How Time is Spent?

To manage time effectively, engineers must categorize their major activities, record the time spent on each major activity, record time in a standard way, and keep the time data in a convenient place such as an Engineering Notebook or electronic hand-held devices.

Tracking Time in PSP

When tracking time in PSP, the following data must be recorded: Date, Start time, Stop time, Interruption time, Delta time, Activity, Comments, whether it is Completed (or not), and Units.

Hints on Logging Your Time

• Keep the engineering notebook/hand-held device with you at all times
• When you occasionally forget to record the start time, stop time, or interrupt duration, make an estimate as soon as you remember
• You may use a stopwatch to track interruptions
• Summarize your time promptly

Managing Your Time

Managing time involves deciding how you want to spend your time, making a time budget, tracking the way you spend time against this budget, and deciding what changes to make to bring your actions into agreement with the budget.

Time Stealers

Common time stealers include: Interruptions (Telephone, Personal visitors), Meetings, Tasks you should have delegated, Procrastination and indecision, Acting with incomplete information, Dealing with team members, Crisis management (fire fighting), Unclear communication, Inadequate technical knowledge, Unclear objectives and priorities, Lack of planning, Stress and fatigue, Inability to say 'No', and Desk management and personal disorganization.

Suggestion on Managing Variable Time

Engineers should ask: What are your highest priority items? Are there some tasks that should be done at specific times? Are there activities you want to do as soon as you have time?

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: Ask "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.

Defining Commitments

A commitment defines what will be done, the criteria for determining that it is done, who will do it, when it will be done, the compensation or other consideration to be given in return, and who will provide this compensation or consideration.

Responsibly Made Commitments

To make responsible commitments, engineers should analyze the job before agreeing to the commitment, support the commitment with a plan, document the agreement, and if unable to meet the commitment, promptly tell the other party and try to minimize the impact on that party.

Consequences of Not Managing Commitments

Not managing commitments leads to work required exceeding time available, failure to meet commitments, misplaced priorities, poor quality work, loss of trust, and loss of respect for your judgment.

PSP Process Levels

PSP has four process levels: The Baseline Personal Process, Personal Project Management, Personal Quality Management, and The Cyclic 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

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 planned value is based on the percentage of the total planned project effort that the task will take. As tasks are completed, the task's planned value becomes earned value for the project. The project's earned value then 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.

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.

🔑 Definition — Yield: The percent of defects injected before compile that were removed before compile.

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.

The Cyclic Personal Process

The cyclic personal process addresses the need to efficiently scale the PSP up to larger projects without sacrificing quality or productivity. Productivity is highest between some minimum and maximum size range. Below this range, productivity declines due to fixed overhead costs. Above this range, productivity declines because the process scalability limit has been reached. At this level, this scalability limit is addressed by introducing a cyclic development strategy where large programs are decomposed into parts for development and then integrated. This strategy ensures that engineers are working at their maximum productivity and product quality levels, with only incremental, not exponential, increases in overhead for larger projects. At this level high-level design, high-level design review, cycle planning, and development cycles are introduced based on the personal quality management processes.

💡 Why this matters: The cyclic process allows PSP principles to scale from small exercises to real-world industrial projects.

PSP Measures

There are three basic measures in the PSP: Development time, Defects, and Size. All other PSP measures are derived from these three basic measures.

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, 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.

🔑 Definition — Defect: Any change that must be made to the design or code in order to get the program to compile or test correctly.

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.

Why PSP?

As Watts Humphrey states: "When you trust your life to someone, you want them to behave professionally. Now consider your professional life. Should you entrust it to someone who is out of date? If you are looking for career guidance, would you ask someone who has not cracked a technical book since college? Probably not. The skill, knowledge, and ability you bring to your job will determine your future. Your future is in your hands."

⭐ Key Takeaways

The PSP is a disciplined personal framework emphasizing that quality software requires quality work from every individual engineer. Effective implementation requires mastering time management through logging, budgeting, and tracking time using a standard format, and commitment management through analysis, planning, and documentation. The four PSP process levels progressively build capability: from baseline measurement (Plan-Design-Code-Compile-Test-Postmortem) to project management (size/effort estimation via linear regression and earned value tracking), to quality management (achieving high yield through personal reviews before first compile), and finally to cyclic development for scaling to larger projects without sacrificing productivity. The three fundamental PSP measures—development time (in minutes), defects (logged with type and phase information), and size—serve as the foundation for all derived measures like yield, productivity, and defect density.

🧠 Quick Revision Questions

1. What are the three basic PSP measures, and from which measure is "yield" derived?
2. List the six steps in the Baseline PSP process in order.
3. What is the definition of "yield" in PSP quality management, and what is the goal value for yield?
4. How does the earned value method work for schedule planning and tracking in PSP?
5. What is the cyclic personal process, and why does it become necessary for larger projects?

📘 Lecture 22 — Review Up To Mid-Term

📖 Overview: This lecture provides a comprehensive review of all topics covered up to the midterm in the Software Process Improvement course. It covers the fundamental concepts of processes, software process models, capability maturity models (CMM and CMMI), and the Personal Software Process (PSP), emphasizing their importance in improving software development practices and organizational maturity.

🗂️ Topics Covered

The lecture reviews the definition and examples of processes, the distinction between technical and systemic software problems, software process characteristics and examples, process improvement objectives and planning, six steps to software improvement, levels of software process models (Universal, Worldly, Atomic), process modeling (ETVX, IDEF0), CMM-SW maturity levels (Initial through Optimizing), CMMI as an integrated framework, model representations (staged vs. continuous), CMMI model structure, benefits of CMMI, and an introduction to the Personal Software Process (PSP) and its key process areas.

📝 Lecture Summary

Process

A process is a documented solution to a problem that helps others facing similar challenges. Once someone figures out how to solve a problem, they can document that solution as a process. This process then helps other people get started on their own solutions for similar problems. Examples include an instruction manual for a dishwasher, a cookery book, a bank's procedures manual, and a software development quality manual.

Software Problems

Software problems are categorized into two types. Technical problems need a technical solution and are easy to understand and solve. Systemic problems need a process or management solution and are difficult to understand and solve. The solution to software problems involves treating the software task as a process that can be controlled, measured, and improved, and relating the required tasks, tools, and methods with the skill, training, and motivation of the people involved.

Software Processes

Software engineering has many processes that help perform different activities in an organized manner. A software process is the set of tools, methods, and practices that people use to produce software and associated products, such as project plans, design documents, code, test cases, and user manuals. People are the most important part of an organization.

Characteristics of Software Processes

Characteristics of software processes include requiring creativity, interactions between a wide range of different people, engineering judgment, background knowledge, and experience.

Examples of Software Processes

Examples include the Software Development Life Cycle (SDLC) , the requirements engineering process, the design process, the quality assurance process, and the change management process.

Process Improvement Objectives

The objectives of process improvement are quality improvement, schedule reduction, and resource reduction.

Process Improvements Planning

Process improvement planning involves asking: What are the improvement goals? How can we introduce process improvements to achieve these goals? How should improvements be controlled and managed?

Six Steps to Software Improvements

The six steps are:

1. Understand the current status of development processes.
2. Develop a vision for the desired process.
3. Establish a list of required process improvement actions in order of priority.
4. Produce a plan to accomplish the required actions.
5. Commit the resources to execute the plan.
6. Start over at step 1.

Levels of Software Process Models

There are three levels of software process models:

• Universal or U Process Models: Provide a high-level overview. Traditional Waterfall and Spiral models fall in this category. They are typically task-oriented.
• Worldly or W Process Models: Most useful to practicing software engineers. They guide the sequence of working tasks and define task prerequisites and results. They look like procedures.
• Atomic or A Process Models: Enormously detailed. They are used to automate a specific process activity or use a standardized method or procedure to guide execution of a task.

Process Modeling

Process modeling techniques include ETVX and IDEF0.

CMM-SW Levels

The five levels of the Capability Maturity Model for Software (CMM-SW) are:

1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing

CMMI

CMMI (Capability Maturity Model Integration) was developed because people were successfully using the Capability Maturity Model, which was designed for improving software processes. This success brought attention to model-based process improvement in other areas. Historically, the model to use depended on the discipline (e.g., Software Engineering, Systems Engineering, Software Acquisition, Systems Security).

What is CMM?

A Capability Maturity Model (CMM) is a reference model of mature practices in a specified discipline, used to assess a group's capability to perform that discipline. CMMs differ by discipline (software, systems, acquisition, etc.), structure (staged versus continuous), how maturity is defined (process improvement path), and how capability is defined (institutionalization). Common CMMs include the Software CMM, System Engineering CMM, System Engineering Capability Model, Software Acquisition CMM, System Security Engineering CMM, Personal Software Process, FAA-iCMM, IPD-CMM, People CMM, and SPICE Model.

System and Software Divide

Systems and software disciplines have traditionally not been well integrated. The importance of software in systems has increased dramatically, creating a need to make the systems/software interface more seamless. Having many models with different structures, formats, terms, and ways of measuring maturity causes confusion, especially when using more than one model, and makes it hard to integrate them in a combined improvement program or use multiple models in supplier selection. CMMI comes to rescue by integrating systems and software disciplines into one process improvement framework and providing a framework for introducing new disciplines as needs arise. Systems engineering and software engineering processes are integrated, bridging the divide.

Models directly influencing CMMI

CMMI models combine System Engineering and Software Engineering into one model. It can be applied to just the software engineering projects, just the system engineering projects, or both in an organization.

Comparing Model Representations

• Staged Representation: The approach used in the Software CMM. It uses predefined sets of process areas to define an improvement path for an organization, described by model components called maturity levels. A maturity level is a well-defined evolutionary plateau toward achieving improved organizational processes.
• Continuous Representation: The approach used in the SECM and the IPD-CMM. It allows an organization to select a specific process area and improve relative to it. It uses capability levels to characterize improvement relative to an individual process area.

Process Area Capability and Organizational Maturity

Process area capability deals with a set of processes relating to a single process area or specific practice. Organizational maturity pertains to a set of process areas across an organization. It is important to remember that a model is not a process; the model shows what to do, NOT how to do it or who does it.

Why Do we have Two Representations?

The two representations exist due to source model heritage (Software CMM—Staged, SECM—Continuous, IPD CMM—Hybrid). Proponents for each type were part of the CMMI product development team, and selecting a single representation approach became "too hard," so a compromise was made to initially support two representations with equivalent content.

Advantages of Staged Representation

The staged representation provides a roadmap for implementing groups of process areas and sequencing of implementation. It has a familiar structure for those transitioning from the SW-CMM.

Advantages of Continuous Representations

The continuous representation provides maximum flexibility for focusing on specific process areas according to business goals and objectives. It has a familiar structure for those transitioning from the systems engineering community.

CMMI in a Nutshell

A CMMI model provides a structured view of process improvement across an organization. It can help set process improvement goals and priorities, provide guidance for quality processes, and provide a yardstick for appraising current practices.

CMMI Model Structure

The CMMI model structure includes Maturity Levels (for staged representation) or Capability Levels (for continuous representation), Process Areas, Goals (Generic and Specific), and Practices (Generic and Specific). The CMMI product suite provides the latest best practices for product and service development and maintenance, improving on the best practices of previous models.

Benefits of CMMI

CMMI best practices enable organizations to:

• More explicitly link management and engineering activities to their business objectives.
• Expand the scope of and visibility into the product lifecycle and engineering activities to ensure the product or service meets customer expectations.
• Incorporate lessons learned from additional areas of best practices (e.g., measurement, risk management, and supplier management).
• Implement more robust high-maturity practices.
• Address additional organizational functions critical to their products and services.
• More fully comply with relevant ISO standards.

Use CMMI in process improvement activities as a collection of best practices, a framework for organizing and prioritizing activities, a support for the coordination of multi-disciplined activities, and a means to emphasize the alignment of process improvement objectives with organization business objectives.

What is PSP?

The Personal Software Process (PSP) is a defined and measured software process designed to be used by an individual software engineer. Developed by Watts Humphrey, its intended use is to guide the planning and development of software modules or small programs, but it is adaptable to other personal tasks. While the CMM-SW focuses on improving organizational capability, the focus of the PSP is the individual engineer.

Key Process Areas for PSP

Key process areas for PSP include 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, and Process Change Management.

PSP in a Nutshell

PSP involves baselining your existing personal software process, developing a planning process for your software development, measuring and estimating software size, estimating schedule and resources, conducting appropriate measures of one's process, conducting meaningful design and code reviews, performing software quality management, performing formal software design, verifying the design using methods such as object state machines and program tracing, and scaling up the PSP to larger problems.

⭐ Key Takeaways

This lecture reviewed the entire course up to the midterm. The core concepts are that a software process is a defined set of tools and methods used by people to produce software, and that systematic improvement is essential, often following a six-step cycle. The CMM-SW provides a staged path for organizational maturity from Initial to Optimizing, while CMMI integrates this with other disciplines using both staged and continuous representations for maximum flexibility. Finally, the PSP applies these same improvement principles to the individual engineer to improve personal productivity and quality.

🧠 Quick Revision Questions

1. What are the three objectives of process improvement?
2. Name the five levels of the Software CMM (CMM-SW) in order.
3. What is the key difference between Universal (U) Process Models and Worldly (W) Process Models?
4. What are the two representations of the CMMI model, and what is the primary advantage of each?
5. How does the scope of the Personal Software Process (PSP) differ from that of the CMM-SW?