SOFTWARE ENGINEERING NOTES

1.1 Software Characteristics and Types of Software

Software Characteristics

1. Software is engineered, not manufactured:

Unlike hardware, software is developed through logical design steps, not physical production. Once
created, copies can be made without extra cost.

2. Software doesn’t wear out:

Software doesn’t degrade with use like machines. However, it deteriorates when changes (updates or
patches) introduce new errors over time.

3. Most software is custom-built:

Although reusable components exist, most software systems are still tailored to specific client needs.

4. Software is intangible:
It can’t be touched or seen physically. Its quality depends on logical structure, documentation, and
performance.

5. Software is complex and hard to visualize:

A small error in logic can cause large failures. Understanding and maintaining software needs detailed
documentation.

6. Software is easy to modify:

Compared to hardware, software can be changed easily to meet new user requirements or correct
bugs.

Types of Software Description

Provides a platform for other software.
System Software:
Example: Operating systems, compilers, drivers.
Performs specific user-oriented tasks.
Application Software:
Example: MS Word, Tally, Photoshop.
Responds immediately to external events.
Real-Time Software:
Example: Tra ic light control, air-tra ic monitoring.
Used for calculations, simulations, or scientific research.
Scientific and Engineering Software:
Example: MATLAB, AutoCAD.
Built into hardware devices for specific functions.
Embedded Software:
Example: Software in microwaves, washing machines.
Used in o ices or enterprises for data processing and decision-
Business Software: making.
Example: Payroll, accounting systems
Web Applications: Run on web browsers via internet.
Example: Gmail, YouTube.
 Artificial Intelligence Software: Simulates human intelligence and learning.
Example: Chatbots, voice assistants.

1.2 Software Engineering: A Layered Approach

Software Engineering uses a layered technology approach where each layer supports the next, ensuring
systematic and quality-oriented development.

Layers of Software Engineering

1. Quality Focus (Top Layer):

Every engineering activity aims at
producing high-quality software that
satisfies user needs and performance
standards.

2. Process Layer:
This defines how software is
developed — the overall framework
including planning, analysis, design,
coding, testing, and maintenance.
It acts as the “glue” that binds methods and tools together.

3. Methods Layer:
These are technical procedures and techniques used in analysis, design, and coding.
Example: DFDs, ER diagrams, flowcharts, UML, algorithms.

4. Tools Layer:
These are software applications that automate or support software development.
Example: IDEs like Eclipse, CASE tools, debuggers.

Together, these layers make software engineering a disciplined, structured, and repeatable process.

1.3 Software Development Framework

A software development framework defines a standard structure or model that guides the software
development life cycle (SDLC).

It provides guidelines, processes, and best practices for planning, building, testing, and maintaining
software.

Main Components of the Framework

1. Process Framework

A process framework gives the basic structure for developing software.

It defines a few main steps (framework activities) that are common for all software projects.
It also includes some umbrella activities that support the whole process.

Framework Activities:
  Communication:
Developers interact with customers and stakeholders to understand their needs and collect
requirements clearly.
 Planning:
A proper plan is made for the project — tasks, schedule, resources, risks, and deadlines are
decided.
 Modeling:
Models and diagrams (like DFDs or ER diagrams) are made to understand and design the system
before coding.
 Construction:
Actual coding and testing are done here. Errors are found and fixed to make sure the software
works properly.
 Deployment:
The final product is delivered to the customer. Feedback is taken, and small improvements are
made if needed.

2. Umbrella Activities

Umbrella activities are supporting activities that are done throughout the software development
process.
They ensure that the main process runs smoothly and the software maintains quality.

Main Umbrella Activities:

 Quality Assurance: Makes sure the software meets quality standards and works correctly.
 Configuration Management: Controls and tracks changes made to the software.
 Documentation: Keeps proper records of all project details for easy understanding and
maintenance.
 Risk Management: Identifies and prepares for possible risks in the project.
 Project Tracking: Monitors progress and ensures work is on time and within budget.
 Measurement & Metrics: Collects data to measure performance and improve future projects.

1.4 Software Process Model: Waterfall Model

The Waterfall Model is the oldest and most traditional software development model.
It follows a step-by-step (sequential) process where each phase must be completed fully before moving to
the next.
It is called “waterfall” because the development flows downward like a waterfall, from one stage to the
next.

Phases of Waterfall Model:

1. Requirement Analysis:
In this phase, all the requirements of the customer are collected and written in detail.
It helps the developer to clearly understand what needs to be built.
 2. System Design:
Based on the gathered requirements, the system’s structure and design are planned.
The database, user interface, and data flow are decided here.

3. Implementation (Coding):
The system design is converted into actual code using a programming language.
Each module is coded and tested individually.

4. Testing:
The complete software is tested carefully to find and fix any errors.
The goal is to ensure the software works exactly as required.

5. Deployment:
The software is delivered to the customer for actual use.
Installation and user training may also take place.

6. Maintenance:
After delivery, any problems found are corrected.
Updates or improvements may be added based on user feedback.

Advantages:

 Simple and easy to understand.

 Each phase has clear goals and documentation.

 Best for small projects where requirements are fixed.

 Easy to manage because of its step-by-step nature.

Disadvantages:

 Not flexible — once a phase is finished, going back is di icult.

 Customer feedback comes very late.

 Testing happens only after coding, so errors may be found late.

 Not suitable for projects with changing requirements.

Example:

Payroll systems, calculator software, or other small projects with fixed needs.

1.5 Incremental Process Model (RAD Model)

RAD (Rapid Application Development) is an incremental software process model that focuses on fast
development and early delivery of software components.

In this model, the entire software is divided into small parts (increments).
Each part is developed, tested, and delivered to the user quickly.
After all parts are completed, they are combined into the final product.

Phases of RAD Model:

 1. Business Modeling:
The flow of business information is studied — what data is required, how it moves, and who uses it.

2. Data Modeling:
Data objects and relationships between them are identified and designed.

3. Process Modeling:
Defines how data is processed to achieve business goals.

4. Application Generation:
The actual software is built using powerful tools, reusable components, and automatic code
generators.

5. Testing and Turnover:

Each module is tested independently, and finally all modules are integrated to form the full system.

Advantages:

 Faster development and delivery.

 Easy to make changes based on user feedback.

 Encourages frequent customer involvement.

 Reduces overall development time.

Disadvantages:

 Requires skilled developers and designers.

 Needs strong user participation throughout.

 Not suitable for large or complex projects.

 Depends heavily on powerful RAD tools.

Example:

Online booking systems, educational software, small business management systems.

1.6 Evolutionary Process Models

The Evolutionary Process Models focus on developing software step by step, improving it with each
version (iteration).
The system evolves over time as feedback is received from users.

These models are suitable when requirements are not clear in the beginning or may change during
development.

(a) Prototyping Model

The Prototyping Model builds a sample working version (prototype) of the system to understand user
requirements more clearly.
The prototype helps both the customer and developer to visualize how the system will look and work.

Steps in Prototyping Model:

1. Requirement Gathering:
Initial requirements are collected from the customer.

2. Quick Design:
A rough design (basic screens and layout) is created.

3. Build Prototype:
A simple working model is developed to demonstrate the main functions.

4. Customer Evaluation:
The customer tries the prototype and gives feedback.

5. Refinement:
Changes and improvements are made based on feedback.

6. Final Product:
Once the customer is satisfied, the final software is developed using the refined requirements.

Advantages:

 User gets to see the product early.

 Helps find missing or misunderstood requirements.

 Encourages active user participation.

 Reduces risk of project failure.

Disadvantages:

 Users may think the prototype is the final product.

 Frequent changes can delay final development.

 Poorly designed prototypes may lead to bad final systems.

Example:

Websites, user interface design, or mobile apps where user feedback is important.

(b) Spiral Model

The Spiral Model, developed by Barry Boehm, combines features of the waterfall model and prototyping
model with strong risk management.

The process is represented as a spiral with many loops (iterations).

Each loop represents one phase of development — planning, risk analysis, engineering, and evaluation.

Phases in Spiral Model:

 1. Planning:
Objectives, alternatives, and constraints of the project are identified.

2. Risk Analysis:
All possible risks are identified (cost, time, technical risks) and ways to minimize them are planned.

3. Engineering:
The next version of the product is developed and tested.

4. Evaluation:
The customer reviews the product and provides feedback for the next iteration.

This cycle repeats until the software is complete.

Advantages:

 Very e ective for large and high-risk projects.

 Risk is controlled at every stage.

 Allows customer feedback throughout the process.

 Flexible — changes can be made at any stage.

Disadvantages:

 Complex to manage.

 Expensive due to repeated risk analysis.

 Not suitable for small projects.

 Requires experienced developers and managers.

Example:

Banking systems, defense projects, large government systems.

1.7 Agile Process Models

The Agile Model is a modern approach that focuses on flexibility, teamwork, and continuous customer
feedback.
Work is divided into short time periods called iterations or sprints (1–4 weeks).
After every sprint, a working part of the software is delivered and reviewed.

The goal of Agile is to deliver working software quickly, accept changes easily, and keep the customer
closely involved.

(a) Extreme Programming (XP)

Extreme Programming (XP) improves software quality by combining strong teamwork, coding standards,
and customer involvement.

Main Practices:
  Pair Programming: Two developers work together at one computer.

 Test-Driven Development: Write tests before writing actual code.

 Continuous Integration: Merge and test code frequently.

 Simple Design: Keep the design simple and clear.

 Customer On-site: Customer stays involved throughout development.

Advantages:

 Produces high-quality software.

 Responds quickly to changing requirements.

 Continuous testing ensures fewer bugs.

Disadvantages:

 Needs skilled developers.

 Not suitable for very large teams.

 Requires full-time customer involvement.

(b) Adaptive Software Development (ASD)

ASD is based on the idea that change is normal in software development.

It encourages learning, flexibility, and teamwork.

Phases:

1. Speculate: Plan roughly what needs to be done.

2. Collaborate: Work closely with users and team members.

3. Learn: Review what was done and improve in the next cycle.

Advantages:

 Handles frequent changes easily.

 Encourages innovation and teamwork.

 Reduces project risks.

Disadvantages:

 Hard to predict cost and schedule.

 Needs experienced and cooperative teams.

(c) Scrum

Scrum divides the project into short cycles (sprints) of 2–4 weeks.
Each sprint delivers a working part of the software.
Roles in Scrum:

 Product Owner: Represents the customer and defines what needs to be built.

 Scrum Master: Guides the team and removes any obstacles.

 Development Team: Builds and tests the product.

Activities in Scrum:

 Sprint Planning: Team plans what to do in the next sprint.

 Daily Scrum: A short daily meeting to track progress.

 Sprint Review: Demonstrate the completed work.

 Sprint Retrospective: Discuss what went well and what to improve next.

Advantages:

 Delivers usable software quickly.

 Encourages teamwork and self-organization.

 Adapts well to changing needs.

Disadvantages:

 Requires experienced and disciplined teams.

 May not work well for very large or complex projects.

(d) Dynamic System Development Method (DSDM)

DSDM is an Agile framework that focuses on timely delivery and active user involvement.
It uses a technique called timeboxing, where a fixed time is given for each task.

Advantages:

 Delivers high-quality systems on time.

 Involves users throughout development.

 Flexible and business-focused.

Disadvantages:

 Needs constant user participation.

 Complex to manage without proper control.

(e) CRYSTAL Method

The Crystal Method focuses on people, communication, and interaction rather than strict processes.
Di erent versions (like Crystal Clear, Crystal Orange) are used depending on project size and criticality.

Advantages:
  Lightweight and simple.

 Encourages teamwork and communication.

 Flexible to project needs.

Disadvantages:

 Less documentation can cause confusion in large projects.

 Not suitable for big, complex systems.

(f) Agile Unified Process (AUP)

The Agile Unified Process combines the structure of Rational Unified Process (RUP) with Agile flexibility.
It divides development into four main phases and emphasizes iterative progress.

Phases:

1. Inception: Define goals and scope.

2. Elaboration: Design architecture and analyze risks.

3. Construction: Build and test the software in iterations.

4. Transition: Deliver and deploy the final system.

Advantages:

 Balanced between agility and structure.

 Suitable for medium and large projects.

 Allows continuous improvement and flexibility.

Disadvantages:

 Requires skilled and organized team.

 Needs proper management and documentation.

Model Approach Type Main Focus Best For

Waterfall Linear Step-by-step, no change Small, fixed projects

RAD Incremental Fast delivery using modules Medium projects

Prototyping Evolutionary Build prototype and refine Unclear requirements

Spiral Evolutionary Add risk management Large, high-risk projects

XP Agile Teamwork & code quality Small Agile teams

ASD Agile Learn and adapt quickly Dynamic projects

Scrum Agile Sprints and teamwork Medium projects

 DSDM Agile Time-boxed delivery Business applications

Crystal Agile Focus on people Small teams

AUP Agile Mix of Agile & RUP Medium–large projects

2.1 Software Engineering Core Principles

Software engineering core principles are basic rules or guidelines that help software engineers develop
good-quality software.
They ensure that every project is organized, easy to maintain, and meets the user’s needs.

1. Reason it all exists:

The main purpose of any software is to satisfy the customer’s needs.
Every activity in the project should focus on delivering what the user wants.

2. KISS (Keep It Simple):

Always keep software design and code simple.
Simpler systems are easier to build, test, and maintain.

3. Maintain the vision:

The entire team should understand and work towards one clear goal.
Everyone must follow the same vision of the final product.

4. What you produce, others will consume:

Whatever a developer creates will be used or maintained by others later, so the work should be clear,
well-structured, and easy to understand.

5. Be open to the future:

Software should be flexible so that it can be modified or improved later when requirements change.

6. Plan ahead for reuse:

Try to develop reusable code components or modules so they can be used in future projects to save
time and cost.

7. Think about quality:

Quality should be built into every stage — from requirements to coding and testing — to ensure
reliability and user satisfaction.

2.2 Software Practices and Principles

Software Practices are set of activities that guide how software is built and maintained.
Each practice has its own principles that help ensure success.

The five major software practices are:

1. Communication Practice

2. Planning Practice

3. Modeling Practice
 4. Construction Practice

5. Deployment Practice

1. Communication Practice

Communication ensures a clear understanding between developers, clients, and stakeholders before and
during development.

Principles:

Principle Explanation

1. Listen actively Developers must listen carefully to customers to understand their real needs
and expectations.

2. Use simple, clear Avoid technical jargon when communicating with clients; ensure everyone
language understands.

3. Record everything All discussions, decisions, and requirements should be documented for
reference.

4. Encourage feedback Regular feedback ensures corrections happen early, avoiding later confusion.

2. Planning Practice

Planning defines how the project will be carried out, who will do what, and by when.

Principles:

Principle Explanation

1. Understand the scope Know exactly what the project must achieve — this gives direction.

2. Involve stakeholders Clients and users should be part of the planning to set realistic goals.

3. Consider risks early Include risk analysis and mitigation in planning.

4. Be realistic and flexible Don’t overpromise — adjust plans as new information comes in.

3. Modelling Practice

Modelling means representing the software system visually or conceptually to understand requirements
and design.

Principles:

Principle Explanation

1. Model what is important Focus on critical system aspects, not unnecessary details.

2. Keep models simple Diagrams should be easy to understand and modify.

 3. Use di erent views Create models for data, control, and behavior (like DFD,
UML).

4. Validate models Ensure all models match real requirements before coding
starts.

4. Construction Practice

Construction covers coding and testing activities.

Principles:

Principle Explanation

1. Follow coding standards Maintain consistent code style for clarity and maintainability.

2. Keep it simple and modular Write small, understandable modules that can be reused.

3. Test as you build Perform unit testing after each code segment to catch errors early.

4. Review and refactor Regularly review code and improve it for performance and readability.

5. Deployment Practice

Deployment means delivering the software to the end users and ensuring it runs correctly in their
environment.

Principles:

Principle Explanation

1. Plan deployment early Prepare deployment strategy and environment in advance.

2. Document everything Provide user manuals and installation guides clearly.

3. Train users Ensure users know how to operate the software e ectively.

4. Gather post-deployment feedback Monitor usage and gather user feedback for improvement.

2.3 Requirement Engineering

Definition:
Requirement Engineering is the process of understanding, analyzing, documenting, and validating what
the customer needs from the software system. It starts during communication and continues through
modeling. It ensures that the final product meets user expectations and business goals.

Main Activities of Requirement Engineering

1. Inception

o It answers “Why do we need this software?”

o At this stage, the business need, target users, and basic project goals are identified.
 o Helps understand the scope of the project and the nature of the required solution.

2. Elicitation

o It answers “What does the customer want?”

o Information is collected by talking to customers, end-users, and stakeholders.

o Techniques: Interviews, questionnaires, workshops, brainstorming sessions, etc.

o The goal is to identify objectives, usage scenarios, and user expectations.

3. Elaboration

o Information gathered during elicitation is expanded and refined.

o A requirements model is developed to represent functional, behavioral, and information

requirements.

o Defines:

 How users will interact with the system.

 Entities and relationships visible to users.

 Attributes and services required for each class.

4. Negotiation

o It answers “What is actually required?”

o Di erent stakeholders may have conflicting or unrealistic requirements.

o Negotiation helps in resolving conflicts and setting priorities.

o Both sides (customer and developer) reach a “win-win” agreement using cost, time, and risk
as reference points.

5. Specification

o The agreed requirements are documented clearly.

o The specification can include:

 Written documents

 Graphical models

 Use-case descriptions

 Prototypes or mathematical models

o The format may vary depending on project size and complexity.

6. Validation

o Ensures that the documented requirements are correct, complete, and consistent.

o Conducted through technical reviews with engineers, customers, and stakeholders.

o Detects:
  Missing information

 Ambiguities

 Conflicting or unrealistic requirements

7. Requirements Management

o Involves tracking and controlling changes in requirements throughout the project life cycle.

o Helps maintain traceability (link between requirements and other project documents).

Types of Software Requirements

1. Functional Requirements:

o Define what the system must do — the specific functions or features.

o Example: “The system should generate a sales report at the end of each month.”

2. Non-Functional Requirements:

o Define how the system should behave or perform.

o These are quality attributes like speed, security, reliability, usability, and scalability.

o Example: “The response time of the system must be less than 2 seconds.”

3. Product Requirements:

o Describe both functional and non-functional behavior of the software product.

o Include performance, reliability, portability, and design constraints.

o Example: “The software must run on Windows, Linux, and macOS.”

4. Organizational Requirements:

o Come from the company’s internal policies or business rules.

o Example: “The software must use the company’s existing Oracle database.”

5. External Requirements:

o Arise from factors outside the organization such as laws, regulations, or hardware
interfaces.

o Example: “The system must comply with government data privacy laws.”

2.4 Software Requirement Specification (SRS)

Definition:

A Software Requirement Specification (SRS) is a formal document that describes in detail what the
software will do and how it will perform.
It is prepared after all requirements are gathered and finalized.
Need for SRS:

 Provides a clear and detailed overview of the software product, its features, and goals.

 Describes the target audience and expected environment (hardware/software).

 Acts as a communication bridge between customers and developers.

 Serves as a reference document for design, coding, and testing.

 Avoids misunderstandings and scope creep.

 Helps in estimating project cost, time, and resources.

Format of SRS Document (IEEE Standard 830):

1. Introduction

o Purpose of the document

o Product overview and scope

o Definitions, acronyms, and references

2. Overall Description

o Product perspective

o User characteristics

o Constraints and assumptions

3. Specific Requirements

o Functional and non-functional requirements

o Interface requirements (hardware/software)

o Performance and safety requirements

4. External Interface Requirements

o Interaction with hardware, software, and users

5. Appendices

o Supporting information, diagrams, or additional notes

Characteristics of a Good SRS:

1. Correctness:
All requirements stated must be accurate and reflect user needs.

2. Completeness:
Every function and constraint must be clearly defined without missing details.
 3. Consistency:
No conflicting or contradictory requirements should exist.

4. Unambiguousness:
Requirements should have only one clear meaning.

5. Modifiability:
The document should be easy to change when requirements change.

6. Traceability:
Each requirement should be easily linked to its source or corresponding design element.

7. Testability:
Each requirement must be testable through inspection or testing methods.

8. Understandable by Stakeholders:
The document should be written in simple, clear language for both technical and non-technical users.

Unit III – Design and Analysis Modelling

3.1 Translating Requirement Model into Design Model (Data Modelling)

After collecting and analyzing all requirements, we move to the design phase.
This process is called translating the requirement model into a design model.
It means converting what the system should do (requirements) into how the system will do it (design).

Data Modelling

Data Modelling is the first and most important step in this translation.
It focuses on identifying, organizing, and structuring the data used in the system.

Steps in Data Modelling:

1. Identify Data Objects (Entities):

o Find all important data items from the requirement model.

o Example: In a college system, entities are Student, Course, Faculty.

2. Define Attributes:

o Each entity has its own properties or fields.

o Example: Student → Name, Roll No, Address.

3. Establish Relationships:

o Show how di erent entities are connected.

o Example: Student “enrolls in” Course.

o This can be one-to-one, one-to-many, or many-to-many.

4. Draw the Entity Relationship Diagram (ERD):

o ERD is a diagram that shows entities, their attributes, and relationships.

 o It helps to visualize how data flows between parts of the system.

5. Create Data Dictionary:

o A data dictionary gives details about every data item like name, type, size, and meaning.

6. Normalize the Data:

o Remove duplicate or unnecessary data to make storage e icient.

7. Convert to Physical Design:

o The logical data model is finally converted into database tables and keys for implementation.

Example:

For a Library Management System

Entities: Book, Member, Issue.
Relations: A Member can issue many Books.
ERD shows these links clearly.

3.2 Analysis Modelling (Elements of Analysis Model)

Analysis Modelling represents what the system must do —

it helps in understanding the problem clearly before designing the solution.

It acts as a bridge between requirement gathering and design.

Main Elements of the Analysis Model:

1. Scenario-Based Model (Use-Cases):

o Describes how the user interacts with the system.

o Example: “A student logs in, views timetable, and logs out.”

o It helps to understand user actions and system reactions.

2. Class-Based Model:

o Identifies the main objects (called classes) in the system.

o Each class has attributes (data) and operations (functions).

o Example: Class Student has attributes like name, roll number and functions like register() or
viewResult().

3. Behavioral Model:

o Shows how the system behaves in response to events.

o Example: When the user enters a password, the system verifies it and shows the homepage.

o Represented using state diagrams or activity diagrams.

4. Data Model:

o Defines how data is stored, connected, and processed.

 o It includes entities, attributes, and relationships shown in ER diagrams.

5. Flow-Oriented Model:

o Shows how data moves through the system and what operations are applied.

o It can be represented using Data Flow Diagrams (DFDs).

In short:

Analysis models show the functions, data, and behavior of the system before any code is written.
They help both the customer and the developer agree on what needs to be built.

3.3 Design Modelling (Fundamental Design Concepts)

Design Modelling tells how the system will work internally.

It converts analysis models into actual blueprints that developers can use to build the software.

To make good designs, software engineers follow some fundamental design concepts.

1. Abstraction

 Abstraction means showing only important details and hiding unnecessary ones.

 It helps to simplify complex systems.

 Example: When you use a “Print” option, you don’t see how printing happens internally — that is
abstraction.

2. Information Hiding

 Information hiding means keeping internal details of a module secret from other modules.

 Each part only shares what is necessary.

 Example: A “Database” module hides its connection details and only provides functions like
addData() or getData().

3. Structure

 Structure means arranging system components in a clear, organized way.

 It defines how modules are linked and how data flows between them.

 Example: Dividing a web system into layers — user interface, business logic, and database layer.

4. Modularity

 Modularity means dividing a big system into smaller parts called modules.
  Each module performs a specific task and can be developed or tested separately.

 Example: In an online shopping app — modules can be Login, Search Product, Payment, and Delivery.

5. Concurrency

 Concurrency means that di erent parts of the program can run at the same time.

 It helps improve performance.

 Example: While one user is shopping online, another can also browse products at the same time.

6. Verification

 Verification ensures that the design is correct and meets all requirements.

 It checks whether the design can be tested and implemented easily.

 Example: Review meetings are done to verify that all modules follow design rules.

7. Aesthetics

 Aesthetics means the design should be neat, consistent, and easy to understand.

 Good naming, clean layout, and readable diagrams make the system easier to maintain.

Concept Simple Meaning Example

Abstraction Show only important details Hide print logic behind “Print” button

Information Hiding Keep internal details private Database hides connection details

Structure Organized system layout UI → Logic → Database

Modularity Divide system into small parts Login, Payment, Delivery modules

Concurrency Run parts in parallel Many users using app at once

Verification Check correctness of design Design review meeting

Aesthetics Clean and readable design Clear naming & layout

Unit III – Design and Analysis Modelling (Part 2)

3.4 Design Notations

Design notations are the graphical or symbolic methods used to represent the structure, behavior, and
flow of a software system during the design phase.
They help in visualizing and communicating system logic before coding begins.
According to Pressman & Ri man, good design notations should be simple, understandable, and easy to
verify.

1. Data Flow Diagram (DFD)

Meaning:
A Data Flow Diagram shows how data moves through the system, what processes change it, and where it
is stored.
It focuses on the flow of information rather than the actual program logic.

Purpose:

 To represent functional aspects of a system.

 To show how input data is transformed into output data through various processes.

Main Components (Symbols):

Symbol Meaning
○ or Rounded Rectangle Process (transformation of data)
→ (Arrow) Data Flow (direction of movement)
▭ (Open rectangle) Data Store (where data is kept)
□ (Square) External Entity (source or destination of data)
Levels of DFD (as per Ri man):

1. Level 0 (Context Diagram):

Shows the overall system as a single process and its interaction with external entities.

2. Level 1:
Expands the main process into major sub-processes.

3. Level 2 and beyond:

Provides more detailed breakdowns of each process.

Example:
For an Online Banking System

 External Entities: Customer, Bank Server.

 Processes: Login, Transfer Funds, Generate Statement.

 Data Stores: Account Database, Transaction Log.

Advantages:

 Easy to understand for non-technical users.

 Clearly shows how information is processed.

 Helps in identifying missing functions or data.

2. Structured Flowcharts

Meaning:
A Flowchart is a graphical representation of program logic showing the sequence of steps, decisions, and
operations.
It is the oldest and most widely used design notation.

Purpose:

 To show the control flow of a process.

 To describe logic clearly before coding.

Basic Symbols (as per Ri man’s notation):

Symbol Meaning
⭘ (Oval) Start / End
(Rectangle) Process / Operation
⧫ (Diamond) Decision (Yes/No)
⧍ (Parallelogram) Input / Output
→ (Arrow) Flow line showing order of steps
Example:
A flowchart for a Login System:
Start → Input Username and Password →
If correct → “Login Successful” → Home Page → Stop.
Else → “Invalid Credentials” → Try Again.

Advantages:

 Shows control logic step-by-step.

 Easy to follow and debug.

 Helps programmers before actual coding.

3. Decision Tables

Meaning:
A Decision Table represents di erent possible conditions and the actions taken for each combination of
conditions.
It is useful when a process involves complex decision-making.

Structure:

Conditions Rule 1 Rule 2 Rule 3

Condition 1 T F F
Condition 2 T T F
Actions A1 A2 A3
Example:
ATM Withdrawal:
  Condition 1: Is Card Valid?

 Condition 2: Is PIN Correct?

 Action: Allow Withdrawal / Deny Access.

Advantages:

 Easy to handle multiple conditions.

 Avoids missing or duplicate logic.

 Makes decision-making clear.

3.5 UML Modelling

UML (Unified Modelling Language) is a standard visual language developed by Grady Booch, James
Rumbaugh, and Ivar Jacobson.
According to Ri man, UML is not just for design; it’s a common communication tool that bridges
understanding between users, analysts, and developers.

1. Use-Case Diagram

Meaning:
A Use-Case Diagram shows how users (actors) interact with the system and what functions (use-cases)
the system provides.

Purpose:

 To identify the main functionalities of the system.

 To show system boundaries and external interactions.

Elements:

 Actor: A user or external system interacting with the software.

 Use-Case: A function or service provided by the system.

 Association: Line showing interaction between actor and use-case.

 System Boundary: Rectangle showing system limits.

Example (Online Shopping System):

Actors – Customer, Admin.
Use-Cases – Login, Search Product, Add to Cart, Make Payment.
Customer interacts with all these functions; Admin handles product updates.

2. Class Diagram

Meaning:
A Class Diagram represents the structure of the system by showing its classes, attributes, methods, and
relationships.
It gives a static view of the software.

Elements:

 Class: Represents an entity (e.g., Student, Account).

 Attributes: Data members (e.g., name, balance).

 Operations: Functions or methods (e.g., deposit(), withdraw()).

 Relationships:

o Association (uses)

o Inheritance (is-a)

o Aggregation (has-a)

Example:
Class: Student

 Attributes: RollNo, Name, Email

 Methods: register(), display()

Class: Course

 Attributes: CourseID, CourseName

 Methods: addStudent(), assignFaculty()

Relationship: Student “enrolls in” Course.

Purpose:

 Helps visualize object relationships.

 Supports Object-Oriented Design.

 Forms the base for database and code structure.

3. Sequence Diagram

Meaning:
A Sequence Diagram shows how objects communicate with each other through messages over time.
It represents the order of interaction in a particular use-case.

Elements:

 Actors / Objects: Placed at the top.

 Lifelines: Vertical dashed lines showing object existence.

 Messages: Arrows showing communication.

 Activation boxes: Periods when the object performs an action.

Example (Login Process):
User → Login Page → Server → Database → Server → User (Response Message “Login Success”).

Purpose:

 Describes message order clearly.

 Useful for understanding dynamic behavior.

 Helps during coding and integration.

3.6 Testing

Meaning:

Software Testing is the process of executing a software program with the intention of finding errors and
ensuring that the developed software meets the specified requirements.

In simple words, testing ensures that the software is working correctly, reliably, e iciently, and satisfies
user needs before it is delivered.

Purpose of Testing:

The main purpose of testing is not only to find errors but also to ensure that the software product:

1. Works according to customer requirements.

2. Produces expected results with valid inputs.

3. Handles invalid inputs properly.

4. Meets both functional and performance expectations.

5. Is reliable, secure, and user-friendly.

6. Is free from major defects and ready for real use.

Testing is also used to verify that the software product performs as per its design, and to validate that it
meets user needs and expectations.

Objectives of Software Testing (as per Ri man):

1. Verification: Ensures that software is built correctly (according to design).

2. Validation: Ensures that the right product is built (according to requirements).

3. Defect Detection: To identify errors or bugs before the product is released.

4. Quality Assurance: To improve software reliability and performance.

5. Confidence Building: To ensure the product behaves as expected in real conditions.

Types of Testing Methods

There are mainly two approaches to software testing:

Points of
Black Box Testing White Box Testing
Di erence

It is a way of testing the software in which

It is a way of software testing in which
the tester has knowledge about the
Definition the internal structure, program, or code
internal structure or the code or the
is hidden and nothing is known about it.
program of the software.

Also known as data-driven testing, and Also called structural testing or glass box
Other Names
functional testing. testing.

Ideal for higher levels of testing like

Best suited for lower levels of testing like
Level of Testing System Testing and Acceptance
Unit Testing and Integration Testing.
Testing.

Performed By Mostly done by software testers. Mostly done by software developers.

Knowledge No knowledge of implementation or Knowledge of implementation and

Required code is needed. programming is required.

Type of Test It is a functional test of the software. It is a structural test of the software.

Testing can start after preparing the Testing can start after preparing the
When to Start
Requirement Specification Document. Detailed Design Document.

1. Statement Coverage: Ensures

1. Equivalence Partitioning:
every line of code is executed at
Divides input values into valid
least once.
and invalid partitions and selects
Techniques Used 2. Branch Coverage: Ensures every
values from each.
branch (decision) is executed at
2. Boundary Value Analysis:
least once.
Checks boundary conditions for
3. Path Coverage: Tests all possible
input values.
paths of the program.
1. E icient for large systems.
2. Independent tester and
developer → balanced testing. 1. Helps in code optimization by
3. Tester can be non-technical. finding hidden errors.
4. No need for detailed system 2. Test cases can be easily
Advantages knowledge. automated.
5. Tests done from end user’s point 3. More thorough since all code
of view. paths are covered.
6. Helps identify vagueness in 4. Testing can start early even if GUI
functional specs. is not available.
est cases can be designed once
specifications are complete.
 Points of
Black Box Testing White Box Testing
Di erence

1. Test cases are di icult to design

without clear specifications. 1. Can be complex and expensive.
2. Hard to identify tricky inputs if 2. Developers dislike doing detailed
test data is not well defined. white-box tests.
Disadvantages 3. Impossible to test all inputs due 3. Requires professional resources
to limited time. with strong programming
4. Some program paths may knowledge.
remain untested. 4. Time-consuming, especially for
5. May repeat tests already done by large applications.
programmers.

Static and Dynamic Testing

Software testing is mainly divided into two broad categories based on whether the code is executed or not
—
Static Testing and Dynamic Testing.

1. Static Testing

Meaning:

Static testing means testing without executing the actual code of the program.
It focuses on reviewing documents, code, and design to find errors early — even before the program runs.

Purpose:

 To detect errors in requirements, design, and code before implementation.

 To ensure that documentation and logic are correct and complete.

 To reduce cost by fixing mistakes early in the development process.

Activities Involved:

 Requirement document review

 Design document review

 Code inspection

 Walkthroughs

 Static analysis using automated tools

Who performs it:

Usually performed by developers, analysts, or reviewers before handing the code to testers.

Advantages:
  Errors are found early, before execution.

 Saves time and cost in later stages.

 Ensures quality in design and documentation.

 Helps maintain coding standards.

Example:

Checking the requirement document for missing functions or reviewing code manually for syntax errors
before running the program.

2. Dynamic Testing

Meaning:

Dynamic testing means testing by executing the software to check its behavior, logic, and output.
It focuses on how the software performs when it runs.

Purpose:

 To verify that the software produces correct outputs for given inputs.

 To find logical, functional, and runtime errors.

 To check the software’s performance, reliability, and usability.

Activities Involved:

 Running test cases on actual software.

 Observing outputs and comparing them with expected results.

 Recording and fixing defects found during execution.

Who performs it:

Usually performed by testers or QA engineers during di erent testing levels like unit, integration, and system
testing.

Advantages:

 Helps ensure the system works as intended.

 Detects logical and runtime errors.

 Can validate both functional and non-functional requirements.

Example:

Executing a login program with valid and invalid usernames to check if it allows correct users and rejects
wrong ones.

The V-Model of Software Testing

Meaning:

The V-Model (also called the Verification and Validation Model) is an improved version of the Waterfall
Model.
It shows how development phases (on the left side) are linked with testing phases (on the right side) —
forming the shape of the letter “V”.

It means that for every development activity, there is a matching testing activity.
This ensures that testing starts early and runs in parallel with development.

Explanation of the V-Model :

1. Requirement Analysis → Acceptance Testing

 In this phase, the customer’s requirements are

collected and analyzed.

 A Requirement Specification Document is

prepared.

 Based on these requirements, Acceptance Test

Design is also prepared to verify the final product later.

Verification: Understanding what the user wants.

Validation: Checking if the final system satisfies all user
requirements during Acceptance Testing.

2. System Design → System Testing

 The overall system architecture and high-level design are created in this phase.

 All major modules and their interactions are defined.

 Corresponding System Test Cases are designed to test the system as a whole.

Verification: Designing the complete system structure.

Validation: System Testing ensures all integrated parts work together correctly.

3. Architecture Design → Integration Testing

 The software is divided into smaller modules, and their communication (interfaces) is designed.

 Integration Test Cases are planned to ensure all modules communicate properly.

Verification: Checking design and module connectivity.

Validation: Integration Testing confirms modules interact as expected.

4. Module Design → Unit Testing

  Each module or component is designed in detail (inputs, outputs, algorithms).

 Unit Test Cases are created to check each module separately.

Verification: Confirming the logic of individual modules.

Validation: Unit Testing ensures each module works correctly.

5. Coding (Bottom of the V)

 Coding is the actual implementation phase.

 Developers write and compile the code according to the design documents.

 Once coding is done, the testing phases on the right side of the V begin.

How V-Model Works Step-by-Step:

1. Left Side (Verification):

o Activities: Requirement Analysis → System Design → Architecture Design → Module Design

o Purpose: To make sure the software is being built correctly.

2. Right Side (Validation):

o Activities: Unit Testing → Integration Testing → System Testing → Acceptance Testing

o Purpose: To ensure the correct software is built as per customer needs.

3. Bottom Point (Coding):

o The stage where verified designs are turned into executable code, which is then validated
through various tests.

Advantages of the V-Model:

 Testing starts early — reduces late-stage defects.

 Each phase has a clear corresponding test plan.

 Ensures complete verification and validation of the product.

 Provides a clear and systematic development process.

 Easy to manage and track progress.

Disadvantages of the V-Model:

 Rigid — di icult to adjust if requirements change.

 Not suitable for projects where requirements are not clearly defined.

 Costly for large or evolving systems because of its strict structure.

Unit IV – Software Project Cost Estimation

4.1 The Management Spectrum – The 4 P’s

The success of a software project depends on four key elements collectively called the 4 P’s of Project
Management:

People, Product, Process, and Project.

Each “P” plays an important role in managing software development e ectively.

1. People

Meaning:
People are the most important resource in any software project.
Without skilled and motivated people, even the best tools and plans will fail.

Key Roles:

 Senior Managers: Define business goals, budgets, and policies.

 Project Managers: Plan, track, and control project activities.

 Software Engineers / Developers: Design, code, and test the product.

 Testers and QA Team: Ensure quality and reliability of software.

 Stakeholders: Users or clients who provide feedback and requirements.

In short:
Good teamwork, clear communication, and proper responsibility distribution among people ensure project
success.

2. Product

Meaning:
The product defines what needs to be built — i.e., the software itself and all associated deliverables (like
documents, user manuals, and reports).

Key Points:

 Understanding the scope of the product is essential.

 Define functional and non-functional requirements clearly.

 Determine constraints, like performance, security, or hardware requirements.

In short:
A well-defined product ensures that everyone knows exactly what the final software should do.
3. Process

Meaning:
The process is the framework or methodology used to plan, design, develop, test, and maintain the
software.

Key Points:

 A proper process provides structure and discipline to the work.

 Common processes: Waterfall, Agile, Spiral, Incremental.

 The process should be chosen based on project size, time, and risk level.

In short:
A good process guides the team from start to finish in an organized way, ensuring quality and timely delivery.

4. Project

Meaning:
The project refers to the actual planning, scheduling, and tracking of software development activities.

Key Activities:

 Define milestones, deadlines, and responsibilities.

 Estimate cost, time, and resources.

 Manage risks and monitor progress.

 Control deviations through reporting and re-planning.

In short:
Project management ensures that people, product, and process all work together e ectively to meet goals.

4.2 Metrics for Size Estimation

Meaning:
Before estimating time and cost, the size of the software must be measured.
“Size” refers to how much software needs to be built — the amount of code, functionality, or user features.

Software size estimation is the process through which we estimate the size of the software to be developed.
We use it to determine software costs. Hence, tight size estimates are critical for correct cost estimates. Our
project can run behind schedule or exceed its budget if they are way o .

The two most commonly used metrics are:

1. Lines of Code (LoC)

2. Function Points (FP)
1. Line of Code (LoC) Metric

Meaning:
This method estimates the size of the software by counting the number of lines of source code written for
the program.

Formula:
Kilo Lines of Code (KLOC)
Productivity =
E ort (Person-Months)

Types:

 Physical LoC: Actual count of lines typed in the source file.

 Logical LoC: Only executable statements (excluding comments and blanks).

Advantages:

 Simple and easy to measure after coding.

 Useful for comparing productivity across similar projects.

 Helps in estimating e ort, time, and cost for maintenance.

Disadvantages:

 Cannot be used early in development (before coding).

 Di erent languages have di erent line lengths — results vary.

 Encourages writing longer code instead of e icient code.

 Ignores complexity and quality of logic.

Example:
If a project has 20,000 lines of code (20 KLOC) and past records show 500 LOC per person-month,
then estimated e ort = 20,000 / 500 = 40 person-months.

Function Point (FP) Metric

Definition:
In this method, the number and type of functions supported by the software are used to calculate the
Function Point Count (FPC).
It measures the functionality of the software from the user’s point of view, not the code size.

Steps in Function Point Analysis

1. Count the Number of Functions of Each Proposed Type

Functions belong to the following five types:

 Type Description

External Input (EI) Functions related to data entering the system.

External Output (EO) Functions related to data exiting the system.

External Enquiries (EQ) Functions that perform data retrieval from the system.

Internal Logical Files (ILF) Logical files maintained within the system.

External Interface Files (EIF) Logical files of other applications used by our system.

2. Compute the Unadjusted Function Point (UFP)

 Each function type is categorized as low, avg, or high based on its complexity.

Function Type Low Avg High

EI (Inputs) 3 4 6

EO (Outputs) 4 5 7

EQ (Inquiries) 3 4 6

ILF (Internal files) 7 10 15

EIF (External files) 5 7 10

Example — count and classify

Suppose for a small online system you count:

 EI: 10 total → 5 Low, 4 Avg, 1 High

 EO: 6 total → 3 Low, 3 Avg, 0 High

 EQ: 4 total → 0 Low, 4 Avg, 0 High

 ILF: 3 total → 0 Low, 2 Avg, 1 High

 EIF: 2 total → 2 Low, 0 Avg, 0 High

 Multiply the count of each function type with its weighting factor.

Compute Unadjusted Function Points (UFP)

EI contribution:
5 × 3 (Low) + 4 × 4 (Avg) + 1 × 6 (High) = 15 + 16 + 6 = 37

EO contribution:
3 × 4 + 3 × 5 = 12 + 15 = 27

EQ contribution:
0 × 3 + 4 × 4 + 0 × 6 = 16

ILF contribution:
0 × 7 + 2 × 10 + 1 × 15 = 0 + 20 + 15 = 35
 EIF contribution:
2 × 5 = 10

 Add all weighted values to get the UFP (Unadjusted Function Points).

UFP = 37 + 27 + 16 + 35 + 10 = 125

3. Find the Total Degree of Influence (TDI)

 Use the 14 General System Characteristics (GSCs) such as data communication, performance,
transaction rate, end-user e iciency, etc.

 Assign each characteristic a rating between 0 to 5, depending on its influence.

 Add all ratings to get TDI (Total Degree of Influence).

 The range of TDI is 0 to 70.

4. Compute the Value Adjustment Factor (VAF)

VAF = (𝑇𝐷𝐼 × 0.01) + 0.65

 The VAF adjusts the UFP value according to the complexity of the system.

 Its value typically lies between 0.65 and 1.35.

5. Find the Function Point Count (FPC)

FPC = UFP × VAF

 This gives the final Function Point Count of the system.

 It represents the total functionality delivered to the user.

4.5 Risk Analysis and Management

Introduction

A Risk Management Plan (also called Plan Risk Management) is a document that helps to foresee risks,
estimate their impact, and define responses before they occur.
It is part of project planning and helps ensure that the software project does not fail unexpectedly.

A risk is an uncertain event or condition that, if it occurs, can have a positive or negative e ect on a project’s
objectives.

Every project involves risks.

Hence, project managers should identify, analyze, monitor, and plan for these risks throughout the project
life cycle.
Characteristics of Risk

1. Uncertainty – We do not know whether the event will happen or not.

2. Loss – If it happens, it can cause loss (in cost, time, or quality).

Purpose of Risk Management

 To identify potential problems early.

 To minimize their negative impact on the project.

 To plan actions in advance so that the project stays on track.

 To build confidence and stability in project execution.

Main Steps in Risk Management

Step Name Purpose

1 Risk Identification Find possible risks before they occur

2 Risk Assessment / Analysis Estimate their probability and impact

3 Risk Management and Monitoring Track and handle risks during the project

4 Risk Refinement and Mitigation Reduce or remove risks

5 RMMM Plan (Risk Mitigation, Document and implement the overall

Monitoring, and Management) strategy

1) Risk Identification

Meaning:
This step lists all possible risks that may a ect the project.
Risks can come from technical, human, organizational, or environmental sources.

Types of Common Risks:

Category Example Risks

Project Risks Schedule delay, cost overrun, unclear requirements

Technical Risks New or untested technology, integration failure

Business Risks Market changes, client’s financial problems

Resource Risks Sta shortage, employee turnover, lack of skill

Environmental Risks Hardware crash, natural disaster, power failure

Example:
If key developer leaves mid-project, progress will slow down — this is a sta turnover risk.

2) Risk Assessment (or Risk Analysis)

Meaning:
After identifying risks, the next step is to analyze how likely each risk is and how severe its e ect could be.

Main Factors:

 Probability (P): How likely the risk will occur (High, Medium, Low).

 Impact (I): The e ect on project goals if it happens (High, Medium, Low).

Risk Exposure (RE):

𝑅𝐸 = 𝑃𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦 × 𝐼𝑚𝑝𝑎𝑐𝑡

This helps in ranking risks and deciding which ones need immediate attention.

Example Risk Matrix:

Risk Probability Impact Risk Exposure Priority

Sta turnover 0.6 8 (on 10) 4.8 High

Hardware crash 0.3 7 2.1 Medium

Client delay 0.2 5 1.0 Low

3) Risk Management and Monitoring

Meaning:
Once the project starts, risks must be tracked and reviewed regularly.
Monitoring checks whether a risk is becoming more or less likely, and ensures that mitigation steps are being
applied.

Objectives of Monitoring:

1. Check if predicted risks occur.

2. Verify that planned preventive actions are followed.

3. Collect data for future projects.

4. Detect new risks early.

Example (Sta Turnover Risk Monitoring):

 Watch team morale and stress level.

 Monitor job market conditions and resignations.

 Track compensation issues and workload.

4) Risk Refinement and Mitigation

Meaning:
Risk mitigation means taking steps to reduce the chance of the risk happening or minimize its e ect if it
does happen.

Risk Refinement:
Breaking down large or general risks into smaller, manageable parts and defining specific actions for each.

Example:
If “hardware crash” is a risk:

 Mitigation: take multiple data backups, use UPS, maintain systems.

 If “sta turnover” is a risk:

o Conduct meetings to understand job issues.

o Maintain documentation so others can continue work.

o Assign backup sta for critical tasks.

RMMM – Risk Mitigation, Monitoring and Management Plan

Introduction

The RMMM Plan (Risk Mitigation, Monitoring, and Management) is a formal part of the software project
plan.
It defines how risks will be handled throughout the life cycle of the project — from identifying them to
tracking and controlling them.

In simple words:

“RMMM is a plan that helps a software team avoid problems (mitigation), watch for warning signs
(monitoring), and handle issues if they actually occur (management).”

Purpose of RMMM Plan

1. To avoid or reduce possible risks before they occur.

2. To monitor known risks during project execution.

3. To manage risks e ectively if they become real problems.

4. To ensure continuity of the project without delay or failure.

5. To record all risk-related work for future learning.

When RMMM Plan is Prepared

 Usually created after risk identification and analysis.

 Prepared before the project starts or during the planning phase.

 Can be part of the main software project plan, or kept as a separate document.

Contents of an RMMM Plan

1. List of all identified risks (technical, human, environmental, etc.)

2. Risk probability and impact rating for each risk.

3. Risk priority (High, Medium, Low).

4. Mitigation plan – what steps will reduce or avoid the risk.

5. Monitoring plan – how the team will track risk indicators.

6. Management / Contingency plan – what actions to take if the risk happens.

7. Person responsible – who will monitor and respond to the risk.

8. Review schedule – how often risks will be reviewed or updated.

Three Main Components of RMMM

1. Risk Mitigation (Avoidance)

 The first and best step — try to prevent the risk from occurring.

 It includes planning, preventive measures, and early action.

Examples of Risk Mitigation:

 Risk: Sta turnover.

Mitigation: O er training, create good work conditions, assign backups, document every task.

 Risk: Hardware crash.

Mitigation: Take frequent backups, use stable systems, test hardware regularly.

 Risk: Requirement change.

Mitigation: Freeze requirements early, get written approvals.

Mitigation focuses on reducing either the probability or the impact of risks.

2. Risk Monitoring

 It is a continuous activity that tracks risk indicators to see whether the risk is becoming more or less
likely.

 The project manager observes and reports early warning signs.

Monitoring Objectives:

1. Check if the risk is occurring or increasing.

2. Ensure that mitigation steps are properly followed.

3. Collect information for future projects.

4. Detect new risks not identified earlier.

Example:
For a sta turnover risk:

 Monitor team morale, attendance, complaints, and outside job o ers.

 If many resignations occur in similar projects, risk probability increases.

3. Risk Management (Contingency or Control)

 This step assumes that the risk has occurred and mitigation has failed.

 The team must now minimize damage and recover quickly.

 Management is about contingency planning – “what to do if the worst happens.”

Example:
If system crashes and data is lost despite backups:

 Switch work to another stable system.

 Restore data from backup files.

 Inform client about the delay and new completion schedule.

Note: Risk management activities usually add cost, so project managers perform a cost-benefit analysis to
check if the cost of applying controls is worth the benefits gained.

Example of a Full RMMM Table

Risk Mitigation Monitoring Management (Contingency)

Keep multiple data Watch system Move work to another stable

Computer
backups in cloud and stability, temperature, system, restore data from latest
Crash
external drives. unusual behavior. backup.

Meet employees, Monitor morale,

Reassign tasks quickly, use
High Sta improve work workload,
documented work to train new
Turnover environment, assign attendance, HR
sta .
backups. trends.

Requirement Get written sign-o Watch for client Negotiate new schedule and
Change before development. change requests. budget with client.
Why RMMM Plan is Important

 Ensures project stability even in uncertain situations.

 Prevents last-minute “crisis mode.”

 Saves time and cost by avoiding large failures.

 Provides clear documentation of who handles what risk.

 Keeps the team and client confident in project success.

UNIT V — 5.1 Project Scheduling

Introduction

Project scheduling is a part of Software Project Management that deals with planning and organizing
project activities so they can be completed on time and within resources.
It defines what tasks are to be done, who will do them, and when they will be completed.

The goal of scheduling is to ensure smooth workflow, timely delivery, and balanced workload across all
team members.

Basic Principles of Project Scheduling

Software project scheduling is built on a few key principles that help the project manager organize the project
e ectively.

Principle Explanation (Easy Words)

1. Compartmentalization The project should be divided into small, manageable parts — tasks or
activities. This makes it easier to track and manage. Both the product
(software) and the process (development steps) are broken down into
parts.

2. Interdependency The relation between tasks should be identified — which tasks depend on
others, which can run parallel, and which must wait. Example: Testing can
start only after coding is done.

3. Time Allocation Each task should have a clear time limit — a start date, end date, and
e ort hours. This ensures all tasks fit within the overall project timeline.

4. E ort Validation Total work assigned should match the available sta strength. The
manager ensures no one is overbooked or underused.

5. Defined Responsibilities Every task must be assigned to a specific team member, so accountability
is clear.

6. Defined Outcomes Each task should have a clear output (e.g., a document, a tested module,
or a feature). This helps measure progress.
 7. Defined Milestones Important points or checkpoints in the project should be identified as
milestones — for example, “Design Completed” or “Testing Started.”
Each milestone ensures the project is on the right track.

A well-scheduled project is divided into small parts, linked correctly, timed properly, given to the right people,
and reviewed regularly through milestones.

Work Breakdown Structure (WBS)

Meaning:
Work Breakdown Structure is a hierarchical decomposition of the total project into smaller, more
manageable parts.

It helps the project manager understand the scope of work, assign resources e iciently, and track progress.

A good WBS is considered essential for the success of software project development. The primary purpose
of a WBS is to break down a large project into smaller, more manageable tasks. It serves as a foundation for
project planning and provides the basis for:

 Organizing and defining the project's scope.

 Planning and managing costs, schedules, and potential changes.
 Assigning responsibilities for specific tasks.
 Scheduling, budgeting, and tracking expenditures.

The process of creating a WBS involves a systematic breakdown of the project:

1. Identify Final Deliverables: First, the desired final results of the project are identified.
2. Define Major Steps: The project is then broken down into major steps, which form the main framework.
3. Decompose into Smaller Tasks: Each major step is further analyzed and broken into smaller tasks
required for its completion.
4. Continue Decomposition: This process of breaking down tasks into even smaller component tasks
continues until the work can be estimated and assigned to an individual

Advantages of WBS:

 Helps break down complex projects.

 Makes scheduling, cost estimation, and resource allocation easier.

 Improves monitoring and control.

 Ensures nothing is missed in planning.

Activity Network (PERT / CPM)

Meaning:
An Activity Network is a visual representation showing how project tasks are connected and the order in
which they must be completed.

Two common techniques are:

 1. PERT (Program Evaluation and Review Technique)

2. CPM (Critical Path Method)

These help identify critical paths, i.e., the longest path through the network which determines the minimum
completion time of the project.

Components of Activity Network

 Activity: A task or job to be completed.

 Event / Node: The start or end of an activity.

 Dependency: Relationship between two activities (one depends on another).

 Critical Path: The longest sequence of tasks which cannot be delayed without delaying the entire
project.

5.2 Project Tracking

Project tracking is the process of monitoring and controlling a software project to ensure it proceeds
according to the planned schedule, budget, and objectives.
It helps project managers measure progress, compare actual results with expected results, and make
corrections if delays or cost overruns occur.

Project tracking mainly uses three methods:

1. Timeline Charts

2. Earned Value Analysis (EVA)

3. Gantt Charts

Timeline Charts

Definition

A Timeline Chart is a graphical representation of the project schedule that shows the sequence of tasks or
activities over time.
Each activity is represented as a horizontal bar drawn according to its start and end dates.
It helps visualize how di erent phases of the project overlap and when each phase should start and end.

Characteristics

 Shows the overall flow of the project.

 Each bar indicates a specific activity’s duration.

  Milestones (important achievements) are marked using a diamond (♦) symbol.

 Concurrent tasks are shown by overlapping bars.

 It helps identify dependency between activities.

 Provides a macro view of project phases such as Communication, Planning, Design, Coding, and
Testing.

How to Make a Timeline Chart

1. List all activities to be performed (based on SDLC).

2. Decide the duration (number of working days) for each activity.

3. Set start and end dates of each task.

4. Identify dependencies (which task starts after another).

5. Draw horizontal bars along a time scale for each task.

6. Mark milestones (♦) for important checkpoints such as SRS completion or delivery.

7. Review and adjust if there are overlaps or delays.

Advantages

 Gives a clear visual overview of the entire project.

 Helps in understanding the sequence and timing of tasks.

 Makes communication easier among team members.

 Identifies overlaps and dependencies between tasks.

 Helps managers monitor progress quickly.

Disadvantages

 Not suitable for very large or complex projects.

 Does not show resource allocation or cost information.

 Cannot represent task delays dynamically unless updated frequently.

 Di icult to manage manually without software tools.

Tools Used to Create

 Microsoft Excel / Google Sheets

 Microsoft Project
  Smartsheet

 GanttProject

 Trello (with timeline view)

In short:

A Timeline Chart gives a simple visual of project activities along a time scale, showing when each task starts
and ends, helping managers ensure everything is on track.

Earned Value Analysis (EVA)

Definition

Earned Value Analysis (EVA) is a quantitative project tracking technique used to measure a project’s
performance and progress by comparing planned work, actual work done, and budgeted cost.
It helps to answer:

 Is the project ahead or behind schedule?

 Is it under or over budget?

Characteristics

 Combines cost, time, and progress in one performance measure.

 Uses three main parameters:

o BCWS (Budgeted Cost of Work Scheduled) – Planned cost.

o BCWP (Budgeted Cost of Work Performed) – Earned value of actual work done.

o ACWP (Actual Cost of Work Performed) – Actual money spent.

 Provides Schedule Variance (SV) and Cost Variance (CV).

 Indicates project e iciency and health using performance indexes (SPI, CPI).

 Used for forecasting project completion time and cost.

How to Perform EVA

1. Determine BCWS: Estimate total cost planned up to the given date.

2. Record ACWP: Calculate the actual cost incurred so far.

3. Compute BCWP: Multiply percentage of completed work with total planned cost.

4. Calculate Variances:
 o Schedule Variance = BCWP − BCWS

o Cost Variance = BCWP − ACWP

5. Compute Indexes:

o Schedule Performance Index (SPI) = BCWP / BCWS

o Cost Performance Index (CPI) = BCWP / ACWP

6. Interpret Results:

o SPI or CPI > 1 → Ahead of schedule / under budget

o SPI or CPI < 1 → Behind schedule / over budget

Advantages

 Provides objective, numerical evaluation of progress.

 Allows early detection of cost or time overruns.

 Helps predict final project cost and completion date.

 Improves decision-making with measurable data.

 Can be used in any project scale (small or large).

Disadvantages

 Requires accurate cost and progress data.

 Complex calculations for beginners.

 Small estimation errors can lead to misleading results.

 Not very helpful when work progress is subjective (like design quality).

Tools Used to Create

 Microsoft Project (built-in EVA feature)

 Primavera P6

 Smartsheet

 Excel spreadsheets (manual calculations)

 ProjectLibre

In short:
EVA is a cost and schedule tracking method that uses planned value, earned value, and actual cost to
measure project performance and forecast completion.

Gantt Charts

Definition

A Gantt Chart is a detailed project scheduling tool that represents activities and their progress on a time
scale using horizontal bars.
It was developed by Henry L. Gantt and is one of the most popular project management tools.
It provides a visual summary of tasks, durations, dependencies, and milestones.

Characteristics

 Shows start and end dates of all activities.

 Each activity is represented by a horizontal bar; its length shows task duration.

 Vertical axis lists project activities; horizontal axis shows time (days, weeks, months).

 Dependencies between tasks are visible by connecting lines.

 Milestones are shown as diamonds (♦).

 Provides both planned and actual progress in one view.

 Used for both planning and tracking purposes.

How to Create a Gantt Chart

1. List all project activities in order.

2. Decide the duration and start/end date of each activity.

3. Identify dependencies (which tasks rely on others).

4. Draw a time scale on the horizontal axis.

5. Plot horizontal bars for each task to show its duration.

6. Add milestones (♦) for major deliverables (e.g., SRS, testing, delivery).

7. Regularly update with actual progress to track performance.

Advantages

 Provides a clear visual schedule of all tasks.

 Shows progress and delays easily.

  Helps identify task overlaps and dependencies.

 Improves team coordination and communication.

 Useful for tracking real-time progress of large projects.

Disadvantages

 Can become complex for large projects with many tasks.

 Needs regular updates to stay accurate.

 Does not directly show cost performance.

 Requires a good understanding of task dependencies to prepare accurately.

Tools Used to Create

 Microsoft Project

 GanttProject

 TeamGantt

 ClickUp / [Link]

 Smartsheet

 Excel (with bar chart feature)

5.3 Scheduling Techniques: CPM vs PERT

Program Evaluation Review

Point of Comparison Critical Path Method (CPM)
Technique (PERT)

CPM is a deterministic scheduling PERT is a probabilistic scheduling

technique that identifies the longest path technique used to deal with uncertainty
1. Meaning /
(critical path) through a project network in project durations, by estimating
Definition
and determines the minimum time expected completion time using three
required to complete the project. time estimates.

Developed by DuPont Company (1957) Developed by U.S. Navy (1958) for the
2. Developed By
for chemical plant maintenance. Polaris missile project.

Probabilistic — assumes time required

Deterministic — assumes time required
3. Nature / Type for each activity is uncertain and uses
for each activity is known and fixed.
probability.
 Program Evaluation Review
Point of Comparison Critical Path Method (CPM)
Technique (PERT)

Focuses mainly on time-cost Focuses mainly on time management

4. Focus optimization and e icient resource and uncertainty reduction in
utilization. scheduling.

Three time estimates for each activity:

• Optimistic time (To) – minimum
5. Time Estimates One-time estimate for each activity
possible time • Most likely time (Tm) –
Used (single deterministic duration).
most probable time • Pessimistic time
(Tp) – maximum possible time

6. Expected Time Expected time (Te) is calculated using:

Not required since times are fixed.
Calculation Te = (To + 4Tm + Tp) / 6

Calculated by identifying the longest

Calculated by identifying the path with
7. Critical Path path in the network (total duration of
the highest expected time and risk.
project).

Activities are shown in a network Activities are also shown in a network

8. Activity
diagram connected by arrows. Each diagram, but each activity has variable
Relationship
activity has a fixed duration. time estimates.

CPM helps to control both time and cost. PERT helps to control time and manage
9. Focus of Control It allows cost optimization by allocating risk. It focuses on ensuring timely
extra resources to critical activities. completion under uncertainty.

Used for research, development, and

Used for routine, well-defined projects
software projects where time
10. Application Type where time and cost are known (e.g.,
estimates are uncertain (e.g., new
construction, manufacturing).
product development, R&D).

Includes cost analysis — cost can be Does not include cost analysis —
11. Cost
adjusted by “crashing” activities to focuses mainly on time estimation and
Consideration
shorten project time. probability.

Suitable for repetitive and predictable Suitable for non-repetitive and

12. Type of Projects
projects. uncertain projects.

13. Estimation High accuracy since time values are Lower accuracy since time values are
Accuracy known. estimated.

14. Basis of Based on deterministic time estimates Based on statistical or probability

Calculation and fixed relationships between tasks. analysis of time estimates.

Usually represented as Activity on Node Usually represented as Activity on

15. Representation (AON) or Activity on Arrow (AOA) Arrow (AOA) diagram with events as
network diagram. nodes.
 Program Evaluation Review
Point of Comparison Critical Path Method (CPM)
Technique (PERT)

To reduce total project cost and duration To reduce project time uncertainty and
16. Main Objective
through proper time-cost trade-o . improve time estimation reliability.

May have multiple probable paths, with

17. Type of Path Only one critical path (longest path) is
the most critical one having the highest
Considered considered for project duration.
risk or variance.

18. Nature of Deterministic analysis (fixed, known Probabilistic analysis (uncertain, uses
Analysis values). expected time and variance).

19. Formula for

Not used (time fixed). Variance (σ²) = ((Tp − To) / 6)²
Variance

• Total project duration • Critical path • Expected project duration •

20. Output of the
activities • Slack (float) time for non- Probability of completion within time •
Technique
critical tasks. Risk level of each activity.

Less useful for risk analysis (no Very useful for risk and uncertainty
21. Risk Analysis
uncertainty). analysis.

22. Slack / Float Float time can be calculated: Float = Float is also calculated, but it includes
Calculation Latest Start – Earliest Start probabilistic time estimates.

Used for well-structured projects like Used for new development projects
23. Use in Software
maintenance, upgrades, or where task durations are not well-
Projects
enhancement. known.

Produces a probabilistic network

24. Output Produces a clear network diagram with
diagram with variable time
Representation fixed time bars and floats.
distributions.

Example: Developing a Website Example: Developing a New AI-based

25. Example Maintenance System with known task Application with uncertain research
durations and costs. time.

6.1 Software Quality Management vs. Software Quality Assurance

Software Quality Management

Point of Comparison Software Quality Assurance (SQA)
(SQM)

SQA is a set of systematic activities that

SQM is the overall process of ensures the software processes and
1. Definition managing quality throughout the products conform to specified
software development life cycle to requirements and standards.
 Software Quality Management
Point of Comparison Software Quality Assurance (SQA)
(SQM)

ensure that products meet required

standards.

The main goal is to plan, organize, The main goal is to verify and assure that
2. Purpose and control all quality-related the process used to develop software is
activities within a project. e ective and consistent.

Managerial activity — focuses on Technical and procedural activity —

3. Nature of Activity planning and controlling quality at focuses on checking and ensuring
the project level. quality during development.

Focuses on managing quality

Focuses on ensuring the software
4. Focus policies, standards, and objectives
process and product meet quality goals.
at an organizational or project level.

Covers entire organization or Covers specific project or process

5. Scope
multiple projects. quality activities.

To define quality standards and

To monitor and evaluate whether those
6. Main Objective ensure they are followed across the
quality standards are properly applied.
organization.

Handled by project managers and Handled by SQA team or quality

7. Responsibility
senior management. assurance engineers.

Proactive and managerial — Preventive and process-oriented —

involves planning and implementing ensures defects are prevented by
8. Approach
quality systems before development following proper methods and
starts. standards.

1. Developing quality policies

1. Conducting reviews, inspections,
and objectives.
and testing.
2. Planning quality processes.
9. Key Activities 2. Verifying compliance to
3. Assigning quality
standards.
responsibilities.
3. Measuring and improving quality
4. Conducting reviews and
processes.
audits.
10. Stage of Active throughout the project life Active during software development and
Involvement cycle, from planning to delivery. testing stages.

11. Focus on Prevention: focuses on setting up Assurance: focuses on verifying that the
Prevention or proper processes to prevent quality process works correctly to avoid
Detection issues. defects.

Ensures the quality system and

12. Verification / Ensures the software product meets
standards are in place — relates to
Validation requirements — relates to validation.
verification.
 Software Quality Management
Point of Comparison Software Quality Assurance (SQA)
(SQM)

Produces quality plans, audit

Produces test reports, process
13. Output reports, and quality improvement
checklists, and compliance records.
actions.

Defining ISO or CMMI quality

Performing code inspections, testing,
14. Example of Work frameworks and policies for a
and audits for a project.
company.

Quality management tools like ISO QA tools like Test Management Systems,
15. Tools Used 9001, Six Sigma, CMMI, and Quality Review Checklists, and Defect Tracking
Auditing tools. tools (e.g., JIRA, Bugzilla).

Measures overall project quality

16. Measurable performance, customer Measures defect density, test coverage,
Aspects satisfaction, and adherence to and compliance with quality processes.
standards.

Ensures long-term quality policy

Ensures individual project and product
17. Result / Outcome implementation across multiple
quality before release.
projects.

Strategic orientation — part of the Operational orientation — part of the

18. Orientation
organization’s management policy. project’s development and testing cycle.

SQA is a subprocess under SQM. SQA works within the SQM framework
19. Dependency SQM depends on SQA feedback for and ensures its processes are correctly
improvement. followed.

Implementing ISO 9001 standard

Conducting code reviews and audits for
20. Example across all departments of a
a specific project.
software company.

Definition of Software Quality

Software Quality means that the software product meets its specified requirements and also satisfies
user expectations in terms of performance, reliability, and usability.
In simple words, a high-quality software is one that works as intended, is easy to maintain, performs
e iciently, and fulfills customer needs.

However, achieving quality is challenging because:

 Customer requirements (like speed, reliability) often conflict with

 Developer requirements (like maintainability, reusability).

Hence, maintaining balance between both is the main goal of Software Quality Assurance.
Definition of Software Quality Assurance (SQA)

Software Quality Assurance (SQA) is a systematic process that ensures the software being developed
meets the required quality standards and follows the defined software process.

It includes:

 Auditing the processes used in software development.

 Reporting results to management to maintain control over quality.

 Ensuring conformance to defined procedures, methods, and standards.

6.2 Phases of Software Quality Assurance

SQA Planning Phase

Purpose:
This is the first phase where a complete SQA Plan is prepared before development begins.
It defines how quality will be managed, measured, and controlled throughout the project.

Main Objectives:

 Define quality goals, standards, and responsibilities.

 Prepare a Software Quality Assurance Plan (SQAP) as part of the project plan.

 Decide what evaluations, audits, and reviews will be performed.

 Specify error reporting, tracking procedures, and feedback mechanisms.

 Identify SQA indicators and metrics to assess quality.

Example:
In a payroll system project, the SQA plan may specify following ISO 9001 standards and require two design
reviews before coding begins.

SQA Activities Phase

Purpose:
This phase involves the execution of SQA tasks as defined in the SQA plan.
The SQA group performs various activities to ensure the software process complies with standards.

Key Activities (as per Pressman):

1. Participate in process definition: Review project’s software process for compliance with company
policy and standards.

2. Review software engineering activities: Ensure development tasks follow the defined process.
 3. Audit work products: Verify they meet specified standards.

4. Document and track deviations: Note any non-compliance and ensure corrections are made.

5. Provide feedback: Communicate quality findings and suggestions to the project team and
management.

Example:
During design phase, the SQA team verifies that UML diagrams follow company’s naming and documentation
rules.

SQA Audit Phase

Purpose:
To formally check and evaluate if the software project activities and products adhere to defined standards
and processes.

Description:

 Audits are independent examinations performed by the SQA group.

 They review selected work products, documents, and project activities.

 The goal is to ensure compliance and identify deviations early.

 Each deviation is recorded, tracked, corrected, and re-verified.

Example:
An audit may find that some test cases were not executed as per the SQA plan, leading to a corrective action
and re-audit.

SQA Review and Reporting Phase

Purpose:
To analyze results, measure quality performance, and ensure that deviations are resolved and overall
product quality improves.

Key Steps (as shown in Pressman’s SQA process diagram):

1. Identify Problem Area – Locate where process or product quality is weak.

2. Prepare Criteria – Define measurable standards for evaluation.

3. Identify Indicators – Set quality indicators (like defect density or code complexity).

4. Analyze and Compare Results – Compare actual results with expected outcomes.

5. Take Measures – Recommend corrective or preventive actions.

6. Record and Report Findings – Share results with project management and senior leadership.
Example:
If coding standards violations are detected frequently, the SQA team recommends extra peer reviews or
automated code quality tools.

Summary of SQA Phases

Phase Description / Objective Main Output

1. Planning Defines quality goals, standards, and prepares SQA plan SQA Plan Document
before development begins.

2. Activities Implements SQA tasks and monitors compliance with Compliance Reports
the defined process.

3. Audit Performs formal verification of work products and Audit Reports

documents.

4. Review & Analyzes results, identifies issues, and ensures Review & Management
Reporting continuous quality improvement. Reports

6.3 Quality Evaluation Standards

Six Sigma

Definition:
Six Sigma is a quality improvement strategy that focuses on reducing defects and errors in a process to
produce near-perfect results.
It aims to make every process e icient, predictable, and consistent by identifying the causes of problems
and eliminating them.

In simple words, Six Sigma means improving process performance by reducing variation and ensuring that
products or services meet customer expectations every single time.

Six Sigma follows two main methodologies based on the type of process — DMAIC and DMADV.

A) DMAIC Methodology

(Used for improving existing processes)

1. Define:
In this phase, the problem and project goals are clearly defined.
The team prepares project charters, process maps, and flowcharts to understand how the current system
works.

2. Measure:
The existing process performance is measured using data.
It involves identifying key performance indicators and collecting measurements related to process e iciency,
error rate, and customer satisfaction.

3. Analyze:
In this stage, the team studies the collected data to find the root cause of defects or variations.
Statistical tools like process capability analysis and control charts may be used to understand where
problems occur.

4. Improve:
Once the root cause is known, improvements are planned and implemented.
Techniques such as risk analysis, simulation, and design of experiments are used to find the best solutions
that reduce errors.

5. Control:
The final step ensures that the new and improved process remains consistent over time.
Process control systems, monitoring charts, and periodic reviews are used to maintain performance.

Use:
DMAIC is applied when a company already has an existing process that needs to be optimized or improved.

B) DMADV Methodology

(Used for creating new products or processes)

1. Define:
The team defines the project’s purpose, goals, and customer needs.

2. Measure:
It collects detailed information about customer requirements and expectations for the new product or
process.

3. Analyze:
Di erent design options are analyzed to determine how best to meet the customer’s needs and achieve
performance goals.

4. Design:
A new process or product is designed that meets the quality and performance expectations identified earlier.

5. Verify:
The new design is tested and verified to ensure it performs correctly and meets customer satisfaction.

Use:
DMADV is applied when a new product or process needs to be designed with built-in quality from the start.

Six Sigma Summary Table

Aspect DMAIC DMADV

Purpose Improve existing processes Design new products/processes

 Focus Identify and remove defects Build quality into the design

Define, Measure, Analyze, Improve,

Key Phases Define, Measure, Analyze, Design, Verify
Control

Goal Reduce variation and errors Create high-quality and predictable systems

Advantages of Six Sigma

 Reduces process defects and variations.

 Improves customer satisfaction and product quality.

 Increases company profits by minimizing rework and waste.

 Builds a culture of continuous improvement.

Capability Maturity Model Integration (CMMI)

Definition:
CMMI stands for Capability Maturity Model Integration.
It is a process improvement framework developed by the Software Engineering Institute (SEI) to help
organizations improve their software development and management processes.

CMMI describes how mature and capable an organization’s processes are in delivering quality software
consistently.
It provides a step-by-step improvement path, divided into five levels of maturity.

CMMI Maturity Levels (Staged Model)

Level Name Description

The process is unstructured and chaotic. Success depends on

Level 1 Initial
individual e ort rather than a defined process.

Basic project management practices are used. Projects can repeat past
Level 2 Repeatable
successes using documented plans and control.

All processes are documented, standardized, and integrated across the

Level 3 Defined
organization. A common set of standards is used.

The organization uses metrics and quantitative data to measure

Level 4 Managed
process performance and product quality.

Focus on continuous process improvement through innovation and

Level 5 Optimizing
feedback. Processes are refined and optimized over time.

CMMI in Two Models

 1. Staged Model:

o Represents overall organizational maturity through levels 1 to 5.

o Each level builds upon the previous one.

2. Continuous Model:

o Focuses on individual process areas (like project planning, risk management).

o Each process area is rated on capability levels (0–5) separately.

Advantages of CMMI

 Improves process predictability and e iciency.

 Enhances product quality and customer satisfaction.

 Reduces rework and project risks.

 Builds a culture of process discipline and continuous improvement.

Di erence Between CMMI and ISO

Although both CMMI and ISO (International Organization for Standardization) are used for improving
software quality, they di er in scope, approach, and implementation.

CMMI (Capability Maturity Model ISO (International Organization for

Aspect
Integration) Standardization)

CMMI focuses specifically on software and

ISO is broad and generic, applicable to
system engineering processes. It applies
Scope all types of industries including
mainly to companies involved in software-
manufacturing, IT, and services.
intensive projects.

CMMI integrates processes into the ISO focuses on ensuring conformance to

organization’s culture. It emphasizes documented procedures and
Approach
process improvement, project compliance with international quality
management, and risk handling. standards.

CMMI compares the organization’s existing ISO requires organizations to adjust and
Implementation processes to industry best practices and document their existing processes
helps improve them. according to ISO standards.

CMMI includes risk management as a ISO 31000:2009 added risk

Risk
structured discipline to track and reduce management later; earlier versions were
Management
project risks. neutral.

CMMI mainly links processes with business ISO gives high importance to customer
Customer
goals; customer satisfaction is not a major satisfaction and continuous
Focus
ranking factor. improvement.
 CMMI (Capability Maturity Model ISO (International Organization for
Aspect
Integration) Standardization)

CMMI is more rigid and technical, suitable ISO is flexible and generic, suitable for
Flexibility
for large software projects. all industries.