11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

teach me all the concept in the ppt and do give me reference of it from
Textbook Reference: Software Engineering: A Practitioner's Approach, 9th
Edition (Indian Edition) by Roger S. Pressman & Bruce R. Maxim.

PDF
Unit-I Introduction of Software Engine…

Unit I: Introduction to Software

Engineering
This unit is part of the course "Software Engineering and Project Management" for S.Y.
(SEM-I) at MIT School of Computing, Pune. The professors are Prof. Kanchan Wankhede,
Prof. Komal Munde, and Prof. Rupali. The academic year is 2025-2026 SEM-I.

Course Objectives
The main objectives of the course are to:

Learn and understand the principles of Software Engineering and understand the
Software Development Life Cycle.

Apply Project Management and Requirement analysis principles to software project

development.

Apply concepts of software engineering to develop UML diagrams in design.

Understand the testing strategies and tools.

Understand the different risk factors and techniques of Software Project planning and
management.

(Reference: Pressman, Chapter 1, Section 1.1 - The Nature of Software)

Course Outcomes
On completion of the course, the learner will be able to:

1. Compare and choose a process model for a software project development.

2. Analyze and model software requirements of a software system.

3. Design and model a software system with tools.

4. Design test cases of a software system.

[Link] 1/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

5. Prepare the SRS, Design document, Project plan, and overall management of a given
software system.

(Reference: Pressman, Chapter 1, Section 1.4 - Software Engineering Practice)

Unit I Syllabus
Unit I – Introduction to Software Engineering (09 hours)

Nature of Software, Software Engineering, The Software Process, Software Myths, A

Generic Process Model, Prescriptive Process Models: The Waterfall Model, Incremental
Process Models, Evolutionary Process Models, Concurrent Models, Specialized Process
Models, The Formal Methods Model, The Unified Process Personal, Agility Principles,
Extreme Programming (XP), Scrum.

(Reference: Pressman, Chapter 2, Process Models)

Nature of Software
Software is a set of computer programs that provides functionality and performs desired
tasks.

Technical Definition

Software is:

1. Instructions: A computer program which provides desired functions and performance

while executed.

2. Data Structures: Enables the program to adequately (effectively) manipulate (handle)

information.

3. Documents: That describes the operation and use of the program.

Examples: Operating Systems, Internet browser, Movie Player, Antivirus, Games, etc.

Software Processes

Software development often involves a series of steps that can go wrong if not managed
properly, as illustrated in humorous cartoons showing common pitfalls like poor
communication or misunderstood requirements.

The Evolving Role of Software

Dual Role of Software:

[Link] 2/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

1. A product as an information transformer — producing, managing, acquiring, modifying,

displaying, and/or transmitting information.

2. The vehicle for delivering a product as the control of the computer (Ex. operating
systems), the communication of information (Ex. Networking software), and the creation
of other programs (Ex. software tools).

Software Applications

Software categorization based on their application areas:

1. System Software

2. Business Software

3. Engineering and Scientific Software

4. Personal Computer Software

5. Web-based Software

6. Artificial Intelligence Software

7. Real-time System

8. Embedded System

System Software

Interacts with hardware and provides interface to other applications.

Examples: Operating System, Device Driver, Compiler, File Management Utilities, etc.

Business Software

Software applications that are used by business users to perform various business
functions.
Examples: Accounting System, Enterprise resource planning (ERP), etc.

Engineering and Scientific Software

Number crunching algorithms used to solve scientific problems.

Examples: Matlab, Autocad, etc.

(Reference: Pressman, Chapter 1, Section 1.1 - The Nature of Software)

Software Engineering
Software engineering is the process of designing, developing, testing, and maintaining
software. It is a systematic and disciplined, quantifiable approach to the development,

[Link] 3/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

operation, and maintenance of software.

Software Engineering: A Layered Technology

Software engineering in practice is built on 3 main layers:

1. Process: It is management control of software project. Establishes context with

technical methods. Examples: milestone established, Quality is ensured, and change is
properly managed.

2. Methods: Practices with proven techniques to perform certain activities. Examples:

Encompass a broad array of tasks that include communication, requirements analysis,
design, construction, testing, and support.

3. Tools: Software Engineering Tools allow automation of activities which helps to perform
systematic activities. A system for the support of software development, called
computer-aided software engineering (CASE). Examples: Testing Tools, Bug/Issue
Tracking Tools, etc.

With a "Quality" focus at the base, defining continuous process improvement principles.

Layered Technology in Software Engineering - GeeksforGeeks

(Reference: Pressman, Chapter 1, Section 1.3 - A Layered Technology)

Software Myths
Beliefs about software and the process used to build it. "Misleading Attitudes that cause
serious problems" are myths.

Types:

1. Management Myths

2. Customer Myths
[Link] 4/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

3. Practitioner's (Developer) Myths

Management Myths

Myth 1: We have standards and procedures to build a system, which is enough.

Reality: Practitioners may not be aware; it may not reflect modern software engineering
practices; Is it complete? Is it streamlined to improve time to delivery while still maintaining
a focus on quality?

Myth 2: We have the newest computers and development tools.

Reality: It takes much more than the latest model computers to do high-quality software
development. Computer-aided software engineering (CASE) tools are more important than
hardware.

(Reference: Pressman, Chapter 1, Section 1.2 - Software Myths)

Customer Myths

From the PPT, customer myths are mentioned but not detailed in browsed pages. From the
textbook, examples include:
Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in
the details later.
Reality: A poor up-front definition is the major cause of failed software efforts. A formal and
detailed description of the information domain, function, behavior, performance, interfaces,
design constraints, and validation criteria is essential. These characteristics can be
determined only after thorough communication between customer and developer.

(Reference: Pressman, Chapter 1, Section 1.2 - Software Myths)

Practitioner's (Developer) Myths

Myth 3: Working program is the only deliverable work product.

Reality: A working program is only one part of a software configuration. A variety of work
products (e.g., models, documents, plans) provide a foundation for successful engineering
and, more important, guidance for software support.

Myth 4: Software engineering is about unnecessary documentation.

Reality: Software engineering is not about creating documents. It is about creating a quality
product. Better quality leads to reduced rework. And reduced rework results in faster
delivery times.

(Reference: Pressman, Chapter 1, Section 1.2 - Software Myths)

[Link] 5/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

The Software Process

A software process consists of:

1. Communication

2. Planning

3. Modelling

4. Construction

5. Deployment

The process model is the abstract representation of the process. Also known as Software
Development Life Cycle (SDLC) or Application Development Life Cycle Models.

Process models prescribe a distinct set of activities, actions, tasks, and milestones
(deliverables) required to engineer high-quality software.

Process models are not perfect, but provide a roadmap for software engineering work.
Software models provide stability, control, and organization to a process that if not
managed can easily get out of control.

Software process models are adapted (adjusted) to meet the needs of software engineers
and managers for a specific project.

(Reference: Pressman, Chapter 2, Section 2.3 - The Software Process)

A Generic Process Model

Software process means to develop quality products by using technical and management
rules.

The generic process model is a description of the software development process.

1. Process Framework Activities: Communication, Planning, Modeling, Construction,

Deployment.

2. Umbrella activities: S/W Project tracking, Risk Management, SQA, Technical Review,
SCM, Reusability.

[Link] 6/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Generic process model | Learn How does Generic Process Model work?

(Reference: Pressman, Chapter 2, Section 2.5 - A Generic Process Model)

Prescriptive Process Models

The Waterfall Model

This Model also called as the Classic life cycle or the Waterfall model. Winston Royce
introduced the Waterfall Model in 1970. Also called as Linear Sequential Development
Model. Waterfall approach was first SDLC Model, used widely in Software Engineering to
ensure success of project. Each phase must be completed before the next phase can
begin. Output of one phase will be input of next phase. This model is named "Waterfall
Model", because its diagrammatic representation resembles cascading waterfalls.

Phases

1. Requirement Analysis: The aim of this phase is to understand the exact requirements of
the customer and to document them properly. They discuss functions, performance,
and interfacing requirements of the software. In this phase, Software Requirement
Specification (SRS) document is created. A project is short & simple. Where the tools
and technology used is consistent and is not changing. SRS document serves as a
contract between the development team and customers.

[Link] 7/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

2. Design Phase: All gathered requirements are converted into suitable design. It defines
the overall software architecture together with high level and detailed design. High level
design include Algorithm, Flow charts, Decision tree, Database design, etc. Low level
design include Rough paper design, User interface components, etc. Also finalized
Programming languages, Database or other Hardware & Software requirements. All this
work is documented as a Software Design Document (SDD).

3. Development Phase: In this phase software design is translated into source code using
any suitable programming language. The developer first developed in small programs
called units after that integrated it. Unit testing is done in this phase to check whether
each module is working properly or not.

4. Testing Phase: In this phase, Tester perform all the testing activities to make sure that
the system meets the client requirements or not. After combining all the unit modules,
Integration testing is done for any faults and failures. It generates Test cases & Test
reports.

5. Deployment & Maintenance Phase: The product is deployed in the customer

environment or released into the market. In maintenance phase, There are some issues
which come up in the client environment. To fix those issues, patches are released. Also
to enhance the product some better versions are released. Maintenance is done to
deliver these changes in the customer environment.

Waterfall Model - Software Engineering - GeeksforGeeks

[Link] 8/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Advantages

Simple and easy to understand and use.

Before the next phase of development, each phase must be completed.

Works well for smaller projects.

Requirements are very well understood & fixed.

Any changes in software is made during the process of the development.

Process and results are well documented.

Drawbacks

High amounts of risk and uncertainty.

Error can be fixed only during the phase.

Not suitable for the projects where requirements are changing.

It becomes very difficult to move back to the phase.

Not a good model for complex and object-oriented projects.

Clients valuable feedback cannot be included with ongoing development phase.

Where to Use


[Link]. Project Name Description

1 Library Management A desktop-based system to manage book inventory, borrowing,

System and returns.

2 Hospital Patient Record Software to manage patient records, appointments, and billing in
System hospitals.

3 Payroll Management Handles salary calculation, deductions, and employee data for
System HR departments.

4 Inventory Control System Software for stock management, reordering, and reporting in
retail/business.

5 Online Examination System for conducting exams online with question banks and
System result generation.

 

Why These Projects Suit the Waterfall Model:

Requirements are clearly defined from the start.

Minimal changes are expected during development.

[Link] 9/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Ideal for government, educational, or small business clients.

Easy to test each phase independently (e.g., Design, Implementation, Testing).

(Reference: Pressman, Chapter 2, Section 2.6.1 - The Waterfall Model)

Incremental Process Models

In Incremental Model, requirements divided into multiple standalone modules of the

software development cycle. Each module goes through the requirements, design,
implementation and testing phases. Every subsequent release of the module adds function
to the previous release. The process continues until the complete system achieved.

Phases

1. Requirement Gathering & Analysis: Business Analyst & Product Manager collect all the
Functional & Non-Functional requirements of customers. This phase performs a crucial
role in Incremental Model.

2. Design Phase: It design the overall software architecture together with high level and
detailed design. Designer design Algorithm, Data Flow diagram, Activity diagram, Class
diagram, State Transition diagram, Database design etc.

3. Implementation Phase: In this phase software design is translated into specific source
code. Programmers use suitable programming languages, frameworks & databases.

4. Testing Phase: In the testing phase, Tester checks the performance of each existing
function as well as additional functionality as per customer requirements or not. There
are many test methods, but the most common are white box, black box and grey box
test methods.

[Link] 10/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Incremental Process Model - Software Engineering - GeeksforGeeks

When to Use

Requirements are clearly specified, understood and are known up-front. When the
customer demands a quick release of the product.

You can develop prioritized requirements first.

A project has a long development schedule.

When Software team are not very well skilled or trained.

Lowers initial delivery cost.

Such methodology is more in use for web application and product based companies.

Advantages

The Client gets important functionality early.

Clients have a clear idea of the project.

Errors are easy to be recognized.

Easier to test and debug.

Simple to manage risk because it handled during its iteration.

Changes are easy to implement.

It is flexible and less expensive to change requirements and scope.

[Link] 11/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Partial systems are successively built to produce a final total system.

Disadvantages

Well defined module interfaces are needed.

A good team and proper planned execution are required because of its continuous
iterations.

Problems might cause due to system architecture as such not all requirements
collected up front for the entire software lifecycle.

Each iteration phase is rigid and does not overlap each other.

Where to Use


[Link]. Project Name Description

1 Online Banking System Starts with basic account features, then adds fund
transfer, bill payment, etc.

2 E-Commerce Website Begins with product listing and cart; adds payment,
reviews, and tracking later.

3 Student Information System Initial version manages registration; later increments

include grading, reports.

4 CRM (Customer Relationship Begins with lead tracking; adds contact history, analytics,
Management) and marketing tools.

5 Hotel Booking Application Starts with room booking; later adds customer feedback,
billing, and offers.

 

Why These Projects Fit the Incremental Model:

Requirements are partially known at the beginning.

Allows early delivery of core features.

Frequent client feedback helps improve next increments.

Useful in web and app development, where features evolve over time.

(Reference: Pressman, Chapter 2, Section 2.6.2 - Incremental Process Models)

Evolutionary Process Models

Evolutionary model is also referred to as the successive versions model. It is a combination

of Iterative & Incremental model. In Evolutionary model, the software requirement is first

[Link] 12/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

broken down into several modules that can be incrementally constructed means it take
customer feedback of each module. Delivered product module by module to the customer.

Evolutionary Model - Software Engineering - GeeksforGeeks

When to Use

1. Evolutionary model is commonly used when the customer wants to start using the core
features instead of waiting for the full software.

2. It is used in large projects because of step by step development.

3. Customer requirements are not fixed. But clear concept.

4. Small changes required in separate modules.

5. Useful in object-oriented software development because all the development is divided

into different units.

Advantages

1. It is useful for very large products.

2. User has checked every stage during the development and it is helpful in achieving
customer confidence.

3. User gets a chance to experiment with a partially developed software much before the
complete version of the system is released.

[Link] 13/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

4. It reduces the error because the core modules get tested thoroughly. Initial
Requirement.

5. It also reduces the cost of development.

Disadvantages

1. Constant and clear interaction between the development team members is required.

2. The delivery of full software can be late due to different changes by customers during
development.

3. It is difficult to divide the problem into several parts.

Prototyping Model (Part of Evolutionary)

Prototype is not a complete product it is just functional replica or toy implementation of any
idea, software or system. It is applied when customers do not know the exact project
requirements. It generate before actual development of software. It is an iterative, trial and
error method which takes place between developer and client.

Software Prototyping Model and Phases - GeeksforGeeks

When to Use:

Requirements Are Not Well Understood.

Frequent Changes Are Expected.

User Interaction Is a Priority.

The product involves new technology or approaches.

Short Timelines for Initial Demonstration.

Advantages:
[Link] 14/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

1. Prototype model need not know the detailed input, output, processes, adaptability of
operating system and full machine interaction.

2. Good where requirement are changing.

3. Customers are actively involved in development.

4. Prototypes can be changed and even discarded.

5. Errors can be detected much earlier as the system is made side by side.

6. Flexibility in design.

7. Helps team member to communicate effectively.

Disadvantages:

1. The client involvement is more and it is not always considered by the developer.

2. It is a slow process because it takes more time for development.

3. Many changes can disturb the rhythm of the development team.

4. Documentation is poor as the requirements change frequently.

5. Costly with respect to time & money.

6. Prototyping tools are expensive.



[Link]. Project Name Description

1 ATM User Interface System Prototype helps design the user flow for cash withdrawal,
balance check, etc.

2 E-Learning Portal for Schools Prototype used to finalize features like content access,
quizzes, and reports.

3 Online Movie Ticket Booking UI prototype clarifies seat selection, booking flow, and
System payment interface.

4 Healthcare Appointment Early prototype allows validation of appointment flow,

Scheduling System calendar integration.

5 Hotel Room Reservation Web Mock-up helps refine room selection, date picker, and
App payment options.

 

Why These Projects Fit the Prototyping Model:

User interfaces and usability are key concerns.

End-users can see and refine the system early on.

[Link] 15/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Requirements are not fully known at the beginning.

Helps avoid rework by getting early feedback on functionality and design.

Spiral Model (Part of Evolutionary)

Initially proposed by Boehm in 1986. Spiral Model is a risk-driven software development

process model. It is a combination of Waterfall model, Iterative model & Prototyping model.
Example: Microsoft, OS Versions, Gaming industry ex. Also called as Meta model. Spiral
Model divide into four parts: 1. Planning 2. Risk Analysis 3. Engineering and Risk
Execution. 4. Customer Evaluation.

Spiral Model: Definition, Phases, Advantages & Disadvantages (2025)

Phases

1. Planning: (Requirement Gathering & Analysis) Communication between customers &

project head. Collect all the requirements from customers. Analyses estimated cost,
schedule & required recourses.

2. Risk Analysis: Identification of all the potential risks. Risk mitigation strategy is planned
for solving risks. Design a prototype of model.

3. Engineering & Execution: Actual development start. Designer design the product as per
final prototype. Developer perform actual coding or implementation. Tester perform all
testing methods. Deploy or Release product to the customer environment.

4. Risk Analysis: Take a feedback from customers. If customer want any changes, goes to
next planning.

When to use Spiral Model?

[Link] 16/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

When the project is large & high budget.

When requirements are unclear and complex.

Where the software needs continuous risk evaluation.

When creation of a prototype is applicable.

When changes may require at any time.

When long term project commitment is not feasible due to changes in economic
priorities.

Advantages:

1. High amount of risk analysis.

2. Risky parts can be developed earlier which helps in better risk management.

3. Useful for large and mission-critical projects.

4. Allows extensive use of prototypes.

5. There is always a space for customer feedback.

6. Development is fast.

Disadvantages:

1. Risk analysis needed highly particular expertise.

2. Can be a costly model to use.

3. Doesn't work well for smaller projects.

4. Spiral Process is complex sometimes because Spiral may go infinitely.

5. Large number of spiral stages requires excessive documentation.



[Link]. Project Name Description

1 Defense Missile Control System High-risk project with complex requirements; needs
repeated risk analysis.

2 Banking Software for Loan Involves evolving regulations, security checks, and high-
Management risk transactions.

3 Air Traffic Control System Critical, safety-focused project; allows multiple

refinements per iteration.

4 Enterprise Resource Planning Large modules developed iteratively with ongoing risk
(ERP) System assessment.

[Link] 17/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok


[Link]. Project Name Description

5 Medical Diagnostic Software Involves regulatory risks, evolving user needs, and
System intensive validation.

Why These Projects Fit the Spiral Model:

Projects are large, high-risk, and complex.

Risk analysis is critical in each development phase.

Requirements are not well understood initially and evolve over time.

Involves multiple iterations, validations, and reviews before final release.

(Reference: Pressman, Chapter 2, Section 2.6.3 - Evolutionary Process Models)

Concurrent Models

It is types of Evolutionary Model. Concurrent means “done at same time”. Applicable in all


SDLC Activities: Communication, Design, Coding, testing and deployment.

 

States:

Inactive: No any activity / state performed.

Under Development: Any activity performed.

Awaiting Changes: If customer want any changes.

Under review: Testing activity start.

Under revision: Do all required changes.

Baselined: As per the SRS document

Done: Project completed & Deployed.

[Link] 18/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Concurrent Model in Engineering | Definition, Pros & Cons - Lesson ...

Advantages:

1. This model is applicable to all types of software development processes.

2. It is easy for understanding and use.

3. It gives immediate feedback from testing.

4. It provides an accurate picture of the current state of a project.

Disadvantages:

1. It needs better communication between the team members. This may not be achieved
all the time.

2. It requires to remember the status of the different activities.



[Link]. Project Name Description

1 Cloud-Based File Storage Development, testing, and documentation occur

System simultaneously across modules.

2 Smart Home Automation System Parallel development of lighting, security, and temperature
control modules.

3 Multi-Platform Chat Application UI design, backend APIs, and mobile apps developed
concurrently.

4 Online Learning Management Simultaneous development of course modules, user

System (LMS) management, and reporting.

5 Enterprise CRM with Analytics Analytics, user interface, and data handling modules
Dashboard progress in parallel.

 

Why These Projects Fit the Concurrent Development Model:

Multiple modules/components can be developed in parallel.

Teams handle design, coding, testing, and documentation simultaneously.

Ideal for large, modular projects with clear interfaces between parts.

Supports faster delivery and better resource utilization.

(Reference: Pressman, Chapter 2, Section 2.6.4 - The Concurrent Model)

Specialized Process Models

The Formal Methods Model

[Link] 19/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Types of Specialized process model. It apply mathematical models to the specification,

design, and verification of software systems. Instead of simulation developer use
mathematical model for checking correctness.

The Process of Software Development using Formal Methods ...

When to Use:

Where failure can cause loss of life, serious injury, or environmental damage such as
medical devices, nuclear power plant controls, railway signaling.

Systems that require high assurance against vulnerabilities or breaches such as

Examples: cryptographic protocols, financial transaction systems, secure
communication.

When the system’s logic and behavior are very complex and hard to test thoroughly.

When requirements are ambiguous or incomplete.

Advantages:

Mathematical Precision – Eliminates ambiguities found in natural language

specifications.

Early Error Detection – Issues can be found at the design phase before coding.

Increased Reliability – Suitable for mission-critical systems (e.g., aerospace, nuclear).

[Link] 20/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Automated Analysis – Tools like model checkers can rigorously analyze system
behavior.

Disadvantages:

Complexity – Requires strong mathematical background.

Cost and Time – Formal methods are often resource-intensive.

Tool Limitations – Limited scalability for large systems.



[Link]. Project Name Description

1 Aerospace Flight control systems

2 Medical Devices Infusion pumps, pacemaker firmware

3 Nuclear Systems Reactor safety control software

4 Automotive Autonomous driving systems, braking systems

5 Banking/Finance Transaction protocols, smart contracts


 

(Reference: Pressman, Chapter 2, Section 2.6.5 - Formal Methods Models)

Component-Based Development

Consists of the following process steps:

Available component-based products are researched and evaluated for the application
domain.

Component integration issues are considered.

A software architecture is designed to accommodate the components.

Comprehensive (complete) testing is conducted to ensure proper functionality.

Relies on a robust (healthy) component library. Capitalizes (take advantage) on software

reuse, which leads to savings in project cost and time.

(Reference: Pressman, Chapter 2, Section 2.6.5 - Specialized Process Models)

RAD Model

It is a type of incremental model in which; components or functions are developed in

parallel. It is achieved by component based construction. This can quickly give the
customer something to see and use and to provide feedback.

1. Communication to understand business problem.

[Link] 21/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

2. Planning multiple software teams work in parallel on different systems/modules.

3. Modeling

1. Business Modeling: Information flow among the business. Ex. What kind of
information? Who is going to generate information? From where information comes
and goes?

2. Data Modeling: Information refine into set of data objects that are needed to support
business.

3. Process Modeling: Data object transforms to information flow necessary to

implement business.

4. Construction It highlighting the use of pre-existing software component.

5. Deployment Deliver to customer basis for subsequent iteration.

Rapid Application Development Model (RAD) - Software Engineering ...

Advantages:

Reduced development time.

Increases reusability of components.

Quick initial reviews occur.

Encourages customer feedback.

[Link] 22/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Integration from very beginning solves a lot of integration issues.

Disadvantages:

For large but scalable projects, RAD requires sufficient human resources.

Projects fail if developers and customers are not committed in a much shortened time-
frame.

Problematic if system can not be modularized.

Not appropriate when technical risks are high (heavy use of new technology).


[Link]. Project Name Description

1 Employee Feedback Portal A web-based tool to collect and analyze employee feedback;
quick prototypes help.

2 Online Food Ordering App Allows fast delivery of MVP with core functions like menu,
order, and tracking.

3 College Event Registration Quick web app for students to register for events; UI and forms
System developed fast.

4 Customer Support Chatbot Prototype chatbot system with modular upgrades like analytics
Interface and AI later.

5 Internal Expense Tracker Business tool for tracking department expenses; built quickly
Tool with frequent user input.

 

Why These Projects Fit the RAD Model:

Projects require rapid development and iteration.

Users are actively involved and give feedback after each prototype.

Features can be delivered in modular, quickly developed components.

Ideal when the UI/UX and basic workflows are the priority.

(Reference: Pressman, Chapter 2, Section 2.6.5 - Specialized Process Models)

The Unified Process

The Unified Process (UP) is an iterative and incremental software development framework.
It is use-case driven, architecture-centric, and focuses on managing risk. It has phases:
Inception, Elaboration, Construction, Transition.

[Link] 23/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

The "Personal" might refer to Personal Software Process (PSP), which is a disciplined
process for individual engineers to improve their performance.

(Reference: Pressman, Chapter 2, Section 2.6.6 - The Unified Process)

Agility Principles
Principles of Agile Software Development Methodology:

Customer Satisfaction

Changing Requirements

Frequent Delivery

Communicate Regularly

Face-to-face communication

Measure work progress

Development process

Good Design

Measure progress

Support Team member

Continue Seeking Result

Reflect and adjust regularly

[Link] 24/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Agile Manifesto - 12 principles, values and benefits

(Reference: Pressman, Chapter 3, Section 3.2 - Agility and the Cost of Change)

Extreme Programming (XP)

Extreme Programming (XP) is an agile software development methodology that
emphasizes customer satisfaction, continuous feedback, and adaptive planning. To improve
software quality and responsiveness to changing customer requirements through frequent
releases in short development cycles.

[Link] 25/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

What is Extreme Programming (XP)? - GeeksforGeeks

Key Principles:

Simplicity: Keeping the design simple and straightforward.

Communication: Constant communication among team members and stakeholders.

Feedback: Frequent feedback loops with customers and within the development team.

Courage: Encouraging team members to take initiative and make necessary changes
without fear.

Respect: Promoting mutual respect among team members.

Core Practices:

Pair Programming: Two developers work together at one workstation, collaboratively

writing code.

Test-Driven Development (TDD): Writing tests before the actual code to ensure
functionality and catch issues early.

Continuous Integration: Frequently integrating code changes into the main branch to
detect and fix conflicts early.

Refactoring: Continuously improving and cleaning up the codebase without changing its
functionality.

[Link] 26/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Small Releases: Releasing small, incremental updates to the software frequently.

Advantages:

Higher Quality: Continuous testing and refactoring lead to robust and error-free
software.

Customer Satisfaction: Frequent releases and customer involvement ensure the

product meets user needs.

Flexibility: Adaptive planning and small iterations allow for easy incorporation of
changes.

Improved Communication: Collaboration among team members fosters better

understanding and teamwork.

Disadvantages:

Learning Curve: Teams may need time to adapt to XP practices.

Discipline Required: Consistent adherence to XP practices is necessary for success.

Customer Availability: Requires regular involvement and feedback from customers.

Pair Programming: May not be suitable for all team members or projects.

(Reference: Pressman, Chapter 3, Section 3.4 - Extreme Programming (XP))

Scrum
Scrum Process:

User Story

Epic

Product Backlog

Sprint

Sprint planning

Sprint Backlog

Scrum meeting

Sprint Retrospective meeting

Characteristics of Scrum:

Self-organize team

[Link] 27/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Product progress in a series of month-long “Sprint”

Requirement are captured as items in a list of “product backlog”

No specific engineering practices prescribed

One of agile process

Different Roles in Scrum:

In software development, three roles are defined in the scrum framework:

Scrum team

Scrum Master

Product owner

How Scrum Works:

Scrum is based on short iterations called Sprints, and emphasizes inspection and
adaptation, allowing teams to improve continuously the product and the development
process:

Product Owner

Product Backlog

plans items from the Product Backlog

Daily Standup

Sprint Review.

What is Scrum? | The Agile Journey: A Scrum overview

Advantages:

[Link] 28/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Project deliverables quickly and efficiently.

Ensures effective use of time and money.

Large projects are divided into easily manageable sprints.

Team gets clear visibility through Scrum meeting.

Adopts feedback from customers and stakeholders.

Individual effort of each team member is visible.

Fast-moving development projects.

Disadvantages:

Leads to scope creep, due to the lack of a definite end-date.

Chances of project failure are high if individuals aren't very committed.

Adopting the Scrum framework in large teams is challenging.

Successful only with experienced team members.

Daily meetings sometimes frustrate.

Team member leaves in the middle of a project, it can have a huge negative impact on
the project.

(Reference: Pressman, Chapter 3, Section 3.5 - Scrum)

Product and Process

If the process is weak, the end product will suffer. But an overreliance (more confidence) on
process is also dangerous.

People derive (gain) as much (or more) satisfaction from the creative process as they do
from the end product.

Like an artist enjoys the brush strokes as much as the framed result.

A writer enjoys the search for the proper metaphor (comparison) as much as the
finished book.

As creative software professional, you should also derive as much satisfaction from the
process as the end product.

The duality (contrast) of product and process is one important element in keeping creative
people engaged as software engineering continues to evolve.

(Reference: Pressman, Chapter 1, Section 1.5 - The Product and the Process)

[Link] 29/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

teach me all the concept in the ppt and do give me reference of it from
Textbook Reference: Software Engineering: A Practitioner's Approach, 9th
Edition (Indian Edition) by Roger S. Pressman & Bruce R. Maxim.

PDF
Unit-II Requirements [Link]…

Unit II: Requirements Engineering

This unit is part of the course "Software Engineering" for Second Year Engineering, Class
S.Y. (SEM-I) at MIT School of Computing, Department of Computer Science & Engineering,
AY 2024-2025.

Syllabus
Main Topic-1: Requirements Engineering, Requirements Gathering, Quality Function
Deployment, Usage Scenarios, Elicitation Work Products, Developing Use Cases,
Building the Requirements Model, Negotiating Requirements, Validating Requirements

Main Topic-2: Analysis: Scenario-Based Modeling, UML Models, Requirements

Modeling Strategies: Flow-Oriented Modeling

Main Topic-3: Creating a Behavioral Patterns for Requirements Modeling,

Requirements Modeling for Web Apps, SRS

(Reference: Pressman, Chapter 5 - Requirements Engineering)

Requirements Engineering
Definition: A disciplined process of gathering, documenting, and managing the
requirements of a system.

Objectives:

Identify what the customer needs.

Create a model that guides design and validation.

Ensure traceability and clarity.

(Reference: Pressman, Chapter 5, Section 5.1 - Requirements Engineering)

What is Software Requirement?

[Link] 30/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Definition:

According to IEEE Standard, Software Requirement is a condition needed by a user

to solve a problem or achieve an objective.

Requirement should be clear, correct and well-defined.

Types of Requirements:
There are two types of requirements:

1. Functional Requirements

2. Non Functional Requirements

(Reference: Pressman, Chapter 5, Section 5.2 - Establishing the Groundwork)

Difference between Functional & Non Functional

Requirements


No. Functional Requirements Non-Functional Requirements

1 Help to understand the functions of the Help to understand the system's performance.
system.

2 Mandatory requirements. Not mandatory requirements.

3 They are easy to define. They are hard to define.

4 It concentrates on the user's requirement. It concentrates on the expectation of the user.

5 These requirements are specified by the user. These requirements are specified by the
software developers, architects and technical
persons.

6 Describe what the product does Describes how the product works

7 There is functional testing such as API testing, There is non-functional testing such as
system, integration, etc. usability, performance, stress, security, etc.

8 First Completion of Functional requirements While system will not work only with non-
allows the system to perform non-functional functional requirements.
requirements.

 

(Reference: Pressman, Chapter 5, Section 5.3 - Identifying Stakeholders and Scenarios)

Examples
[Link] 31/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Examples of Functional Requirements:

1. In hospital management system, a doctor should be able to retrieve the information

of his patients.

2. Search option given to user to search from various invoices.

3. User should be able to mail any report to management.

4. Only Managerial level employees have the right to view banking revenue data.

Examples of Non-Functional Requirements:

1. Security, Logging, Storage, Configuration, Performance, Cost, Interoperability,

Flexibility, Disaster recovery, Accessibility

2. Employees never allowed to update their salary information. Reported to the

administrator.

3. A website should be capable enough to handle 20 million users with affecting its
performance.

4. The software should be portable. Moving from one OS to other OS does not create
any issue.

(Reference: Pressman, Chapter 5, Section 5.4 - Eliciting Requirements)

Requirements Gathering: Quality Function Deployment

QFD is a quality management technique that translates the needs of the customer into
technical requirements for software. QFD “concentrates on maximizing customer
satisfaction from the software engineering process”.

To accomplish this, QFD emphasizes an understanding of what is valuable to the

customer and then deploys these values throughout the engineering process. QFD
identifies three types of requirements.

Normal Requirement: Anyone asking for X is expressing a Normal/Performance

requirement.

Expected requirement: Don’t let Expected requirements slip by—they’re silently

assumed

Exciting requirement: Exciters are your differentiators—features your competitors may

lack

[Link] 32/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Requirement What it means (how it affects
Type customer: 😊 / 😡) Real-life example

Normal These are explicitly stated by the You ask for the ability to book a seat
Requirements customer during discussion. reservation (you tell the app you want that).
Satisfaction increases in proportion to If booking is slow or error-prone, you get
how well they’re delivered—and annoyed. If it's smooth, you're satisfied.
decreases if they’re missing or poor.

Expected These are implied or assumed— You assume the app will send a valid E-
Requirements customers don’t usually mention ticket PDF via email. You don’t ask for it; if
them—but their absence causes it's missing or email arrives blank, you’re
major dissatisfaction, even though frustrated—even though its presence
their presence won't boost doesn’t excite you.
satisfaction.

Exciting These are unspoken, pleasant You don’t ask for real-time seat availability
Requirements surprises—delighters that customers indicator or app-showing available seats in
never ask for. Their presence creates bus layout as you tap. But when it shows
delight—but their absence causes no you exactly where the seats are in real time,
harm. you feel pleasantly surprised and
impressed.

 

Quality Function Deployment

(Reference: Pressman, Chapter 5, Section 5.5 - Collaborative Requirements Gathering)

[Link] 33/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Requirement Gathering: Usage Scenarios

As requirements solidify, we still lack usage context—we need to know how functions
get used in the real world.

We create scenarios—concrete stories that define how each type of user will work
through the feature.

We then convert to use cases: each use case is a structured set of steps describing
actor and system behavior.

This method captures both functional needs and user context, allowing us to design
accurate, testable requirements before writing detailed specs.

(Reference: Pressman, Chapter 5, Section 5.6 - Usage Scenarios)

Elicitation Work Products

The PPT mentions elicitation in the context of requirements engineering tasks like
inception, elicitation, and elaboration.

From the case study: Requirements Elicitation Techniques Used

Stakeholder Interviews with investors and brokers

Questionnaire to identify key trading features

Prototyping interface for live market feeds

Brainstorming sessions for advanced features like algo-trading

(Reference: Pressman, Chapter 5, Section 5.4 - Eliciting Requirements)

Developing Use Cases

Definition of Use Case: A use case is a list of actions or event steps defining
interactions between an actor and a system to achieve a goal. The actor can be a
human, an external system, or time.

Usage in Systems Engineering: In systems engineering, use cases represent

missions or stakeholder goals at a higher level than in software engineering.

Actor-System Interaction: A use case describes how a real-world actor interacts with
the system.

System Use Cases: Include high-level implementation decisions. Can be written both
informally and formally.
[Link] 34/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Developing Use Cases: Use cases are developed after identifying actors and address
several key questions, such as:

Who are the primary and secondary actors?

What are the actors' goals?

What preconditions exist before the story begins?

What tasks or functions do actors perform?

What exceptions and variations in interaction might occur?

What system information do actors interact with?

Do actors need to inform the system about external changes?

What information do actors seek from the system?

Do actors need updates about unexpected changes?

UML Use Case Diagram Template | Moqups

(Reference: Pressman, Chapter 6, Section 6.3 - Scenario-Based Modeling)

Building the Requirements Model

Elements of The Requirement Modelling

Class-based Elements:

Usage scenarios imply a set of objects that interact with the system, which are
categorized into classes.

[Link] 35/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Classes are collections of objects with similar attributes and behaviors.

UML class diagrams depict these classes, their attributes (e.g., name, type),
and operations (e.g., identify, enable).

Additional elements depict how classes collaborate and interact, which is

elaborated on in further chapters.

Behavioral Elements:

The system’s behavior significantly impacts design and implementation.

The requirements model includes elements that depict this behavior to guide
these later stages effectively.

Behavioral modeling ensures the system's dynamics are understood,

influencing the overall architecture and user experience.

(Reference: Pressman, Chapter 6, Section 6.2 - Requirements Modeling Approaches)

Negotiating Requirements
In an ideal scenario, requirements engineering tasks like inception, elicitation, and
elaboration should sufficiently determine customer requirements for proceeding with
software engineering activities. However, this is rarely the case, and negotiation with
stakeholders becomes necessary. The goal is to balance functionality, performance,
cost, and time-to-market, developing a project plan that meets stakeholder needs within
real-world constraints.

Occurs when:

Multiple stakeholders have conflicting needs.

Technical and business priorities clash.

Effective negotiations aim for a "win-win" outcome, satisfying stakeholders' needs while
enabling the software team to work within realistic budgets and deadlines. Boehm
outlines negotiation activities at the beginning of each software process iteration,
including identifying key stakeholders, determining their "win conditions," and
reconciling these into mutually agreeable conditions for all parties, including the
software team.

[Link] 36/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Win-Win negotiation model Four stages each consisting of >1 ...

(Reference: Pressman, Chapter 5, Section 5.8 - Negotiating Requirements)

Validating Requirements
In requirements modeling, the focus is on defining "what" the system must do, not
"how" it will do it. This includes specifying user interactions, system functions,
behaviors, interfaces, and constraints.

The requirements model has three main objectives: describing customer needs,
establishing a foundation for software design, and defining requirements for validation.

From the case study validation strategies:

Requirements review with stock market experts

Interface prototyping for high-frequency trade screens

Rule-based test scenarios for portfolio logic

Security audit for fund transfer and login modules

(Reference: Pressman, Chapter 5, Section 5.9 - Validating Requirements)

Analysis: Scenario-Based Modeling

Scenario-based modeling is implied through usage scenarios and use cases, which
form part of the analysis phase.

It involves creating scenarios and converting them to use cases to capture functional
needs and user context.

[Link] 37/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

(Reference: Pressman, Chapter 6, Section 6.3 - Scenario-Based Modeling)

UML Models
The Unified Modeling Language (UML) is a standardized modeling language used in
software engineering to visualize, specify, construct, and document the artifacts of a
software system. UML provides a set of diagrams and techniques to create abstract
models of a system, helping to simplify the complexity of software design and
development.

Key UML Models:

Structural Diagrams: These diagrams represent the static aspects of a system,

showing the structure and relationships between different components.

Class Diagram: Depicts the classes within a system and their relationships.

Object Diagram: Represents instances of classes at a particular moment.

Component Diagram: Illustrates the organization and dependencies among

software components.

Deployment Diagram: Shows the physical deployment of artifacts on nodes.

Behavioral Diagrams: These diagrams capture the dynamic aspects of a system,

describing how it behaves during execution.

Use Case Diagram: Visualizes the interactions between users (actors) and the
system, outlining system functionalities.

Sequence Diagram: Details the sequence of messages exchanged among

objects to accomplish a specific function.

Activity Diagram: Represents workflows of stepwise activities and actions.

State Diagram: Shows the states an object goes through and the transitions
between these states in response to events.

Interaction Diagrams: A subset of behavioral diagrams focusing on the flow of

control and data among system components.

Communication Diagram: Highlights the interactions between objects,

showing how messages are exchanged.

Timing Diagram: Represents the change in state or condition of a class over

time.

[Link] 38/65
11/29/25, 2:29 AM Software Engineering Fundamentals and Processes - Grok

Purpose and Benefits:

Visualization: Helps in understanding the structure and behavior of complex

systems.

Communication: Provides a common language for developers, stakeholders, and

project managers.

Design and Analysis: Aids in the design of new systems and the analysis of existing
ones, ensuring completeness and correctness.

Documentation: Serves as a reference throughout the software development

lifecycle, supporting maintenance and updates.

UML models are versatile tools that support various phases of software
development, from requirement analysis to design and implementation, enhancing
clarity and collaboration.

UML Class Diagrams Tutorial, Step by Step | by Salma | Medium

(Reference: Pressman, Chapter 7, Section 7.3 - UML Models That Supplement the Use
Case)

Requirements Modeling Strategies: Flow-Oriented Modeling

From the case study “TradeX” – Online Stock Trading Platform:

[Link] 39/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Flow-Oriented Modeling (DFD) Level 0 DFD: Place Order

Input: Stock selection, order details

Processes: Validate Order, Submit to Exchange, Record Transaction

Outputs: Order Confirmation, Updated Portfolio

How to create a Level-0 Data Flow Diagram (DFD)

(Reference: Pressman, Chapter 6, Section 6.4 - Data Modeling)

Creating a Behavioral Patterns for Requirements Modeling

Behavioral modeling ensures the system's dynamics are understood, influencing the
overall architecture and user experience.

From the case study:

Behavioral Modeling State Machine: Order Execution

Triggers: Market open, price conditions met

Actions: Notify user, update portfolio

[Link] 40/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

State Machine Diagram - UML 2 Tutorial | Sparx Systems

(Reference: Pressman, Chapter 6, Section 6.5 - Behavioral Modeling)

Requirements Modeling for Web Apps

The PPT refers to WebApp models as discussed in the textbook Chapter 7.

In the context of the case study "TradeX" which is an online platform, requirements
modeling includes aspects like interface prototyping for live market feeds, high-
frequency trade screens, and 24x7 availability except for planned maintenance.

(Reference: Pressman, Chapter 12 - Modeling WebApps)

SRS (Software Requirements Specification)

From the case study:

Software Requirements Specification (SRS)

Introduction: Overview, purpose, scope

Overall Description: System environment, dependencies (e.g., NSE APIs)

Functional Requirements:

FR1: User Login with 2FA

FR2: Place Limit and Market Orders

FR3: Withdraw Funds to Bank

Non-functional Requirements:

NFR1: System must respond within 500ms for market quotes

NFR2: System must be available 24x7 except for planned maintenance

[Link] 41/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

(Reference: Pressman, Chapter 5, Section 5.7 - Developing Use Cases)

teach me all the concept in the ppt and do give me reference of it from
Textbook Reference: Software Engineering: A Practitioner's Approach, 9th
Edition (Indian Edition) by Roger S. Pressman & Bruce R. Maxim.

PDF
Unit3_FINAL.[Link]

Unit III: DESIGN METHODS AND

INTRODUCTION TO UML
This unit is part of the course "Software Engineering" for Class S.Y. (SEM-I) at MIT Art
Design and Technology University, MIT School of Computing, Pune. The professors are
Prof. Sneha Singha and Prof. Anuja Chincholkar. The academic year is 2024-2025 SEM-I.

Syllabus
Duration: 09 hours

Topics:

The Design Process, Concepts of design, Design Quality, Design Principles,

Object-Oriented Design Concepts, Design Classes, The Design Model and
elements

Software Architecture, Importance, Architectural Styles, Architectural Design, UML

Diagrams, Component Design

Class-Based Components, Conducting Component Level Design, User Interface

Analysis and Design

(Reference: Pressman, Chapter 8 - Design Concepts)

The Design Process

Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. The design is represented at a high level of
abstraction—a level that can be directly traced to the specific system objective and more
detailed data, functional, and behavioral requirements.

The architectural design defines the relationship between major structural elements of the
software, the architectural styles and design patterns that can be used to achieve the
requirements defined for the system.
[Link] 42/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

The interface design describes how the software communicates with systems that
interoperate with it, and with humans who use it.

The component-level design transforms structural elements of the software architecture into
a procedural description of software components.

(Reference: Pressman, Chapter 8, Section 8.1 - Software Design Process)

Design within the Context of Software Engineering

Software design is the technical kernel of software engineering and is applied
regardless of the software process model that is used.

Software design is the last software engineering action within the modeling activity and
sets the stage for construction (code generation and testing).

Each of the elements of the requirements model provides information that is necessary
to create the four design models required for a complete specification of design.

The requirements model, manifested by scenario-based, class-based, flow-oriented,

and behavioral elements, feed the design task.

The data/class design transforms class models into design class realizations and the
requisite data structures required to implement the software.

(Reference: Pressman, Chapter 8, Section 8.2 - Design in the Context of Software

Engineering)

Concepts of Design
The concepts of design encompass the iterative translation of requirements into a blueprint,
focusing on abstraction levels, traceability to objectives, and detailed representations of
data, functions, and behaviors.

(Reference: Pressman, Chapter 8, Section 8.3 - Design Concepts)

Design Quality
Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. That is, the design is represented at a high level of
abstraction—a level that can be directly traced to the specific system objective and more
detailed data, functional, and behavioral requirements.

[Link] 43/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Quality is assessed based on traceability, modularity, reusability, and how well the design
serves as a foundation for implementation.

(Reference: Pressman, Chapter 8, Section 8.4 - Design Quality)

Design Principles
Design principles guide the creation of effective software designs. Key principles include:

Traceability: Ensure the design traces back to requirements.

Modularity: Divide the system into manageable modules.

Abstraction: Focus on essential features while hiding details.

Information Hiding: Limit access to internal details.

Functional Independence: Modules should have single responsibilities.

Refactoring: Continuously improve design without changing behavior.

Design for Change: Anticipate future modifications.

(Reference: Pressman, Chapter 8, Section 8.5 - Design Principles)

Object-Oriented Design Concepts

Object-oriented design focuses on defining classes, their relationships, and behaviors to
model real-world entities. Key concepts include:

Classes and Objects: Blueprints and instances.

Inheritance: Reusing code through hierarchies.

Polymorphism: Multiple forms for methods.

Encapsulation: Bundling data and methods.

Abstraction: Simplifying complex realities.

(Reference: Pressman, Chapter 9, Section 9.1 - Object-Oriented Design Concepts)

Design Classes
There are 5 different types of design classes that represent a different layer of design
architecture that can be developed:

[Link] 44/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

1. User Interface Classes: Define abstractions mandatory for human-computer

interaction (HCI). In cases, HCI occurs within the context of a metaphor, and design
classes for the interface may be visible representations of elements of the metaphor.

2. Business Domain Classes: Often refinements of analysis classes defined earlier. The
class identifies the attributes that are required to implement some elements of the
business domain.

3. Process Classes: Implement lower-level business abstractions needed to manage

business domain classes.

4. Persistent Classes: Represent data stores that will persist beyond the execution of the
software.

5. System Classes: Implement software management and control functions that permit
the system to operate and convey within its computing environment and with the
outside world.

(Reference: Pressman, Chapter 9, Section 9.3 - Design Classes)

The Design Model and Elements

The design model includes data/class design, architectural design, interface design, and
component-level design.

Architectural Design Elements: The architectural design for software is equivalent to

the floor plan of a house. The floor plan gives us an overall view of the house.
Architectural design elements give us an overall view of the software. The architectural
model is derived from three sources: (1) information about the application domain for
the software to be built; (2) specific requirements model elements such as data flow
diagrams or analysis classes, their relationships and collaborations for the problem at
hand; and (3) the availability of architectural styles and patterns.

Interface Design Elements: The interface design for software is analogous to a set of
detailed drawings for the doors, windows, and external utilities of a house. The interface
design elements for software depict information flows into and out of the system and
how it is communicated among the components defined as part of the architecture.
There are three important elements of interface design: (1) the user interface (UI); (2)
external interfaces to other systems, devices, networks, or other producers or
consumers of information; and (3) internal interfaces between various design
components. These interface design elements allow the software to communicate

[Link] 45/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

externally and enable internal communication and collaboration among the components
that populate the software architecture.

(Reference: Pressman, Chapter 8, Section 8.6 - The Design Model)

Software Architecture
Software architecture is the high-level design and organization of software in which we
make important decisions regarding its overall structure, such as the relationships between
components, data flow patterns, and the mechanism for communication between different
parts of the system.

A good software architecture helps define performance, quality, scalability, maintainability,

manageability, and usability. The goal is to ensure that your software is flexible, extensible,
and can evolve as new requirements emerge.

Software Architecture Principles: S.O.L.I.D.

(Reference: Pressman, Chapter 10, Section 10.1 - What Is Architecture?)

Importance of Software Architecture

Provides a blueprint for system structure.

Enables better decision-making on performance, scalability, and maintainability.

Reduces risks by addressing quality attributes early.

Facilitates communication among stakeholders.

Supports reusability and modularity.

Example: Comparing two products—one with messy code launched early vs. one with
structured architecture launched later—highlights how good architecture leads to long-term
success.

Good Software Architecture Characteristics:

Uninterrupted Functionality: Performs as intended without bugs.

Reliability: Optimal performance in various environments.

Maintainability: Easy to introduce changes without disruption.

Security: Protected from attacks.

Minimal Technical Debt: Clean, organized code.

[Link] 46/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Testability: Easy to test for quick bug fixes.

Modularity: Divisible into manageable modules.

(Reference: Pressman, Chapter 10, Section 10.1 - The Importance of Architecture)

Architectural Styles
Architectural styles define patterns for organizing software components. Common styles
include:

Data-Centered: Central repository with surrounding components.

Data-Flow: Sequential transformations on data.

Call and Return: Hierarchical control (e.g., main/subprogram).

Object-Oriented: Classes and objects.

Layered: Hierarchical layers (e.g., UI, business logic, data).

(Reference: Pressman, Chapter 10, Section 10.2 - Architectural Genres)

Architectural Design
Architectural design involves defining the relationship between major structural elements,
selecting styles and patterns to meet requirements.

(Reference: Pressman, Chapter 10, Section 10.3 - Architectural Design)

UML Diagrams
UML (Unified Modeling Language) diagrams are categorized into:

Structural Diagrams: Model the static structure (e.g., Class Diagram: Depicts classes,
attributes, methods, and relationships; used for object-oriented systems).

Behavioral Diagrams: Model dynamic behavior (e.g., state diagrams, activity

diagrams).

Structural diagrams depict a static view or structure of a system. It is widely used in the
documentation of software architecture. It embraces class diagrams, composite structure
diagrams, component diagrams, deployment diagrams, object diagrams, and package
diagrams. It presents an outline for the system.

[Link] 47/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Class Diagram: One of the most widely used diagrams. It is the backbone of all object-
oriented software systems. It depicts the static structure of the system. It displays the
system's class, attributes, and methods. It is helpful in recognizing the relation between
different objects as well as classes.

(Reference: Pressman, Chapter 7, Section 7.2 - UML Diagrams)

Component Design
Component design is all about taking complex software systems and making them into
small, reusable pieces or simply modules.

A component is a modular, portable, replicable, and reusable set of well-defined

functionalities.

Component-level design defines the data structures, algorithms, interface characteristics,

and communication mechanisms allocated to each software component.

Benefits of Component Design:

1. Makes every module reusable.

2. Reduces cost as modules are reusable.

3. Increases reliability through modular interactions.

4. Makes the system easy to maintain without full changes.

5. Describes each component's functionality clearly.

Component Design Views:

1. Object-Oriented View

2. Conventional View

3. Process-Related View

(Reference: Pressman, Chapter 11, Section 11.1 - What Is a Component?)

Class-Based Components
Class-based components are derived from object-oriented design, where components are
built around classes that encapsulate data and behavior.

(Reference: Pressman, Chapter 11, Section 11.2 - Class-Based Components)

[Link] 48/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Conducting Component Level Design

Component-level design involves:

Review Requirements: Understand functional/non-functional needs, constraints.

Identify Components: Decompose into modules using modularity, abstraction.

Define Interfaces: Public/private interfaces for interactions.

Allocate Responsibilities: Single, well-defined aspects per component.

Design Patterns: Apply patterns like Singleton, Factory for reusability.

Data Management: Structures, storage, integrity.

Error Handling: Robust mechanisms for stability.

Performance Considerations: Throughput, latency optimization.

Testing Strategy: Unit and integration testing.

Documentation: Decisions, interfaces, dependencies.

Review and Iteration: Feedback and refinement.

Example (from PPT on Library Management System):

Component Identification: Book Management, User Registration, etc.

Modular & Reusable: Each independent with defined functionality.

Activities: Define data structures, algorithms, interfaces, communications.

(Reference: Pressman, Chapter 11, Section 11.3 - Conducting Component-Level Design)

User Interface Analysis and Design

User interface analysis and design focus on understanding user needs, tasks, and creating
intuitive interfaces. It involves task analysis, interface prototyping, and usability evaluation.

(Reference: Pressman, Chapter 13, Section 13.1 - User Interface Analysis and Design)

teach me all the concept in the ppt and do give me reference of it from
Textbook Reference: Software Engineering: A Practitioner's Approach, 9th
Edition (Indian Edition) by Roger S. Pressman & Bruce R. Maxim.

PDF Unit - IV_ Updated - SE - PPT(1).pptx.…

Unit IV: Software Testing Principles

[Link] 49/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

This unit is part of the course "Software Engineering" for Class S.Y. (SEM-I) at MIT Art
Design and Technology University, MIT School of Computing, Pune. The academic year is
2025-2026 SEM-I.

Syllabus
Introduction to Software Testing, Principles of Testing, Testing Life Cycle, Phases of Testing,
Types of Testing, A Strategic Approach to Software Testing, Strategic Issues, Test
Strategies for Conventional Software, Test Strategies for Object-Oriented Software, Test
Strategies for WebApps, Verification & Validation, Software Testing Fundamentals, White-
Box Testing, Basis Path Testing, Control Structure Testing, Black-Box Testing, Model-Based
Testing, Testing for Specialized Environments, Architectures, Object-Oriented Testing
Strategies, Object-Oriented Testing Methods, Validation Testing.

(Reference: Pressman, Chapter 14 - Software Testing Strategies)

Introduction to Software Testing

Definition: Process of evaluating software to determine if it meets specified
requirements.

Purpose: Identify defects, ensure quality, verify functionality, performance, and security.

Importance: Saves cost and time, improves product quality and customer satisfaction.

(Reference: Pressman, Chapter 13, Section 13.1 - Software Testing Introduction)

Principles of Testing
The PPT syllabus lists "Principles of Testing," but specific details are not expanded in the
provided pages. From the textbook context, key principles include:

Testing shows the presence of defects, not their absence.

Exhaustive testing is impossible; focus on risk-based testing.

Early testing saves time and money.

Defects cluster together.

Pesticide paradox: Tests become ineffective over time; need to review and update.

Testing is context-dependent.

Absence-of-errors fallacy: Fixing bugs doesn't mean the software meets user needs.

[Link] 50/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

(Reference: Pressman, Chapter 13, Section 13.2 - Principles of Testing)

Testing Life Cycle (STLC)

Software Testing Life Cycle (STLC) includes:

Requirement Analysis

Test Planning

Test Case Development

Environment Setup

Test Execution

Test Cycle Closure

(Reference: Pressman, Chapter 14, Section 14.2 - The Testing Process)

Phases of Testing
The PPT has a dedicated slide for "Phases of Testing," but content is minimal in the
snippet. Typically, phases align with STLC above, including unit, integration, system, and
acceptance testing.

(Reference: Pressman, Chapter 14, Section 14.3 - Test Phases)

Types of Testing
Functional Testing: Smoke, Sanity, Regression – Checks if the software performs as
expected.

Non-functional Testing: Performance, Usability, Compatibility – Checks quality

attributes.

Manual Testing: Human-executed tests.

Automated Testing: Scripted tests for efficiency.

(Reference: Pressman, Chapter 13, Section 13.3 - Types of Tests)

A Strategic Approach to Software Testing

Testing as a process, not a phase.

[Link] 51/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Includes planning, test case design, execution, and result analysis.

Continuous testing through development.

(Reference: Pressman, Chapter 14, Section 14.1 - A Strategic Approach to Software

Testing)

Strategic Issues
Issues to address for a successful software testing strategy:

Specify product requirements in a quantifiable manner long before testing commences

(e.g., portability, maintainability, usability).

State testing objectives explicitly (e.g., mean time to failure, test coverage).

Understand the users of the software and develop a profile for each user category (use
cases).

Develop a testing plan that emphasizes “rapid cycle testing” for quick feedback.

Build robust software that is designed to test itself (exception handling, automated
testing).

Use effective formal technical reviews as a filter prior to testing.

Conduct formal technical reviews to assess the test strategy and test cases
themselves.

Develop a continuous improvement approach to the testing process.

Additional issues from PPT: Who performs testing? When to start testing? How much
testing is enough? Balancing budget, time, and quality. Use of tools and automation.

(Reference: Pressman, Chapter 14, Section 14.4 - Strategic Issues)

Test Strategies for Conventional Software

Top-down Testing: Start with high-level modules, using stubs for lower ones.

Bottom-up Testing: Start with low-level modules, using drivers for higher ones.

Big-bang Testing: Integrate all modules at once and test.

Sandwich Testing: Combination of top-down and bottom-up.

Example: Banking Application - test login, account summary, fund transfer separately
and then integrate.

[Link] 52/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

(Reference: Pressman, Chapter 14, Section 14.5 - Integration Testing for Conventional
Software)

Test Strategies for Object-Oriented Software

Testing Classes and Objects.

State-based Testing.

Cluster Testing.

Integration through collaboration patterns.

Example: Library Management System - test class behaviors (Book, Member,

Transaction) individually and in collaboration.

Initially, traditional testing focused on procedures operating on data, but OO testing

focuses on objects as instances of classes.

Advantages of OO: reliability, interoperability, reusability, extendibility.

(Reference: Pressman, Chapter 14, Section 14.6 - Test Strategies for Object-Oriented
Software)

Test Strategies for WebApps

The PPT syllabus includes this, but no specific content in browsed pages. From textbook:

Content testing for errors in content.

Interface testing for usability.

Navigation testing for links.

Performance testing for load.

Security testing for vulnerabilities.

Configuration testing for compatibility.

(Reference: Pressman, Chapter 17, Section 17.3 - Testing WebApps)

Verification & Validation

Verification: The process of checking that software achieves its goal without any bugs.
Ensures the product is developed right. Static testing (reviews, walkthroughs,

[Link] 53/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

inspections, desk-checking). Ensures software correctly implements the specific

function.

Validation: The process of checking whether the software product meets high-level
requirements. Ensures the right product is built. Dynamic testing (Black Box, White Box,
Non-Functional). Validates the actual and expected products. Ensures the software built
is traceable to customer requirements.

Verification and Validation investigate if the system satisfies specifications, standards,

and fulfills its purpose.

Verification does not include code execution; Validation does.

(Reference: Pressman, Chapter 14, Section 14.7 - Verification and Validation)

Software Testing Fundamentals

Fundamental Testing Processes:

Test Planning: Defining the scope, objectives, resources, and schedule for testing.

Test Design: Creating test cases and test scenarios based on requirements and
specifications.

Test Execution: Running the tests and recording the results.

Defect Reporting: Documenting any defects found and tracking their resolution.

Test Automation: Utilizing tools to automate repetitive testing tasks for efficiency.

Continuous Integration: Integrating testing into the development process to identify

issues early.

Review and Feedback: Analyzing test results and using them to improve the testing
process.

(Reference: Pressman, Chapter 13, Section 13.4 - Testing Fundamentals)

White-Box Testing
White-Box Testing (also known as structural or glass-box testing) examines the internal
structure of the code. It includes techniques like Basis Path Testing and Control Structure
Testing to ensure all paths and logic are covered.

(Reference: Pressman, Chapter 15, Section 15.1 - White-Box Testing)

[Link] 54/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Basis Path Testing

Path Testing is a white-box testing technique based on the control structure of a
program or a module.

Using the control flow graph, various possible paths in the graph are executed.

Process:

Construct the Control Flow Graph.

Compute the Cyclomatic Complexity of the Graph.

Identify the Independent Paths.

Design Test cases from Independent Paths.

Requires complete knowledge of the program's structure.

(Reference: Pressman, Chapter 15, Section 15.2 - Basis Path Testing)

Control Structure Testing

Control structure testing increases coverage by testing various control structures in the
program. Types include:

Condition Testing:

Focuses on testing individual components of complex conditions.

Tests true and false branches of each simple condition in a compound condition
(e.g., if (a > b && c < d)).

Example: For (x > 5 && y < 10), test cases where conditions hold or not to uncover
errors in Boolean or relational expressions.

Data Flow Testing:

Focuses on variable use, where defined and used, including in loops and if
statements.

Example: Variable defined in a loop should be verified for correct use after the loop.

Loop Testing:

Tests aspects of loops (for, while, do-while).

Example: For a while loop, test skipping, executing once, twice, and near boundary
conditions (n-1, n, n+1).

[Link] 55/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Benefits:

Improved Code Coverage: Tests more logic.

Early Error Detection: Identifies control flow errors early.

Reduced Bugs: Minimizes unexpected behavior.

Targeted Testing: Focus on complex control areas.

(Reference: Pressman, Chapter 15, Section 15.3 - Control Structure Testing)

Black-Box Testing
Black-Box Testing focuses on inputs and outputs without internal knowledge. Mentioned in
Validation as a method. Applies use-case scenarios, creates deficiency lists.

(Reference: Pressman, Chapter 16, Section 16.1 - Black-Box Testing)

Model-Based Testing
Models represent the system under test at a certain abstraction level.

Why it works: Models can test complex systems efficiently; less than 10% of code is
application-specific.

Benefits:

Easy test case maintenance (reuse generation and execution).

Reduced costs with more tests.

Early bug detection and increased bug count.

Time savings.

Start automated testing from version 0.1.

Obstacles:

Skill set: Need testers who can build/use models.

Comfort factor: Technical to create and understand traversal.

Expectations: Upfront investment contradicts Agile; won't catch all bugs.

Metrics: Avoid bug counts/number of tests; use spec/code coverage.

(Reference: Pressman, Chapter 16, Section 16.4 - Model-Based Testing)

[Link] 56/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Testing for Specialized Environments, Architectures

The PPT syllabus includes this, but no specific content in browsed pages. From textbook:
Testing for real-time systems, client-server architectures, embedded systems, etc., focusing
on performance, concurrency, security.

(Reference: Pressman, Chapter 18 - Testing for Specialized Environments)

Object-Oriented Testing Strategies

The PPT syllabus lists this; from OO strategies section: Testing classes, state-based,
cluster, integration via collaboration.

(Reference: Pressman, Chapter 19, Section 19.1 - Object-Oriented Testing Strategies)

Object-Oriented Testing Methods

Focus on objects as class instances. Change from traditional to OO requires reconsidering
strategies. Advantages: reliability, interoperability, reusability, extendibility.

(Reference: Pressman, Chapter 19, Section 19.2 - OO Testing Methods)

Validation Testing
Are we building the right product? Succeeds when software functions as reasonably
expected by the customer.

Focus on user-visible actions and outputs.

Details of class connections disappear.

Apply:

Use-case scenarios from requirements spec.

Black-box testing for deficiency list.

Acceptance tests: Alpha (developer's site), Beta (customer's site) with actual
customers.

(Reference: Pressman, Chapter 14, Section 14.8 - Validation Testing)

teach me all the concept in the ppt and do give me reference of it from
Textbook Reference: Software Engineering: A Practitioner's Approach, 9th
Edition (Indian Edition) by Roger S. Pressman & Bruce R. Maxim.

[Link] 57/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

PDF Unit 5 updated .[Link]

Unit V: Introduction to Project

Management
This unit is part of the course "Software Engineering" for Class S.Y. (SEM-I) at MIT Art
Design and Technology University, MIT School of Computing, Pune. The professors are
Prof. Namrata Naikwade, Prof. Amol Dande, and Prof. Himanshi Agrawal. The academic
year is 2025-2026 SEM-I.

Syllabus
Duration: 09 hours

Topics:

Overview of Project Management: Project Management – Definitions; Stakeholders

in detail, The Management Spectrum, Software Scope, Problem Decomposition,
Process Decomposition, Process and project metrics, Size-Oriented Metrics,
Function-Oriented Metrics, Reconciling LOC and FP Metrics, Object-Oriented
Metrics, Factors Influencing Project Management

Risk: Risk Management: Risk Analysis & Management: Reactive versus Proactive
Risk Strategies, Risks monitoring and Management

(Reference: Pressman, Chapter 21 - Project Management Concepts)

Project Management
Project management has existed as long as humans have worked together to achieve
goals.

Project management skills are useful in all careers.

Project management takes place in all industries.

Project management tools and methodologies have evolved over the past century and
a half:

Scientific management

Gantt chart

Pert/CPM network diagrams

[Link] 58/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

(Reference: Pressman, Chapter 21, Section 21.1 - The Management Spectrum)

Project Management – Definitions

Project Management is the application of knowledge, skills, tools, and techniques to project
activities to meet project requirements. It involves planning, organizing, monitoring, and
controlling all aspects of a project to achieve specific goals on time and within budget.

(Reference: Pressman, Chapter 21, Section 21.1 - Basic Concepts)

Stakeholders in Detail
Stakeholders are individuals or groups with an interest in the project's outcome.

Senior Managers (Product Owners): Define the business issues that often have a
significant impact on the project.

Customers: Specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.

End Users: Interact with the software once it is released for production use.

Other Stakeholders: May include developers, testers, or external parties affected by

the project.

(Reference: Pressman, Chapter 21, Section 21.2 - People)

The Management Spectrum

The management of a software project starts from requirement analysis and finishes
based on the nature of the product.

It is about turning the project from plan to reality.

The management spectrum focuses on the four P's: people, product, process, and
project. The manager of the project has to control all these P's to have a smooth flow in
the progress of the project and to reach the goal.

1. People

2. Product

3. Process

4. Project

[Link] 59/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

(Reference: Pressman, Chapter 21, Section 21.1 - The Management Spectrum)

The Process
A software process provides the framework from which a comprehensive plan for
software development can be established.

Umbrella activities overlay the software process model.

Umbrella activities are independent of any one framework activity and occur throughout
the process.

(Reference: Pressman, Chapter 21, Section 21.4 - The Process)

The Project
The project manager of a project or sub-project is responsible for managing the people,
product, and process.

The responsibilities or activities of software project manager would be a long list but
that can be summarized under the main functions.

(Reference: Pressman, Chapter 21, Section 21.5 - The Project)

Software Scope
Software scope is the part of project planning that involves determining and
documenting a list of specific project goals, tasks, costs, and deadlines.

Software scope describes the data and control to be processed, function, performance,
constraints, interfaces, and reliability.

(Reference: Pressman, Chapter 24, Section 24.2 - Software Scope)

Problem Decomposition
To bridge the communication gap between the customer and developer and to get the
communication process started is to conduct a preliminary meeting or interview.

In the first meeting between the software engineer (the analyst) and the customer, a set
of questions are asked to establish a basic understanding of the problem, the nature of
the solution desired, and the people who will interact with the system.

[Link] 60/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

The next set of questions enables the analyst to gain a better understanding of the
problem and the customer to voice any perceptions about a solution.

How would the customer characterize "good" output that would be generated by a
successful solution?

What problem(s) will this solution address?

Can you show me (or describe) the environment in which the solution will be used?

Additional questions: Are you the right person to answer these questions? Are answers
"official"? Are my questions relevant to the problem that you have? Am I asking too
many questions? Can anyone else provide additional information?

(Reference: Pressman, Chapter 24, Section 24.3 - Problem Decomposition)

Process Decomposition
Process decomposition involves breaking down the software development process into
smaller, manageable activities or phases. It helps in organizing the work and ensuring that
each part of the process is handled effectively.

(Reference: Pressman, Chapter 22, Section 22.1 - Process Metrics and Software Process
Improvement)

Process and Project Metrics

A software metric is a measure of software characteristics which are measurable or
countable. Software metrics are valuable for many reasons, including measuring
software performance, planning work items, measuring productivity, and many other
uses.

Within the software development process, many metrics are connected. Software
metrics are similar to the four functions of management: Planning, Organizing,
Controlling, or Improving.

(Reference: Pressman, Chapter 22, Section 22.1 - Process Metrics and Software Process
Improvement)

Classification of Software Metrics

Software metrics can be classified into two types:

[Link] 61/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

1. Product Metrics: These are the measures of various characteristics of the software
product. The two important software characteristics are: Size and complexity of
software, Quality and reliability of software, Maintainability and testability of software.

2. Process Metrics: These are the measures of various characteristics of the software
development process. For example, the efficiency of fault detection. They are used to
measure the characteristics of methods, techniques, and tools that are used for
developing software.

(Reference: Pressman, Chapter 22, Section 22.3 - Project Metrics)

Types of Metrics
Internal Metrics: Internal metrics are the metrics used for measuring properties that
are viewed to be of greater importance to a software engineer. For example, Line of
Code (LOC), Cyclomatic Complexity, etc.

External Metrics: External metrics are the metrics used for measuring properties that
are viewed to be of greater importance to the user, e.g., portability, reliability,
functionality, usability, etc.

Hybrid Metrics: Hybrid metrics are the metrics that combine product, process, and
resource metrics. For example, cost per FP where FP stands for Function Point Metric.

(Reference: Pressman, Chapter 22, Section 22.2 - Metrics in the Process and Project
Domains)

Size-Oriented Metrics
Size-oriented metrics are derived by normalizing quality and/or productivity measures by
considering the "size" of the software produced. Thousand lines of code (KLOC) are often
chosen as the normalization value.

Example code for selection sort to illustrate LOC.

So, if LOC is simply a count of the number of lines then the function shown contains 13
lines of code (LOC). Assuming that the average salary of a software engineer is
approximately Rs. 2,00,000 per year, and that 1000 lines of code are developed per year,
the average cost to develop a single line of code is approximately Rs. 200. Based on this
cost data, the total cost for development of selection sort can be calculated as Cost = 13 *
200 = Rs. 2600.

(Reference: Pressman, Chapter 22, Section 22.4 - Size-Oriented Metrics)

[Link] 62/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Function-Oriented Metrics
Function-oriented software metrics use a measure of the functionality delivered by the
application as a normalization value. The most widely used function-oriented metric is the
function point (FP). Function points are derived using an empirical relationship based on
countable (direct) measures of software's information domain and assessments of software
complexity.

(Reference: Pressman, Chapter 22, Section 22.5 - Function-Oriented Metrics)

Reconciling LOC and FP Metrics

The relationship between lines of code and function points depends upon the programming
language that is used to implement the software and the quality of the design. Empirical
data that connects lines of code and function points can be developed, but the relationship
is dependent on the programming language that is used to implement the software and the
quality of the design.

(Reference: Pressman, Chapter 22, Section 22.6 - Reconciling LOC and FP Metrics)

Object-Oriented Metrics
Conventional software project estimation techniques require estimates of lines-of-code
(LOC) or function-points (FP), a potential problem since many OO projects use UML as
their normal notation. To address this, a number of extensions to the LOC and FP metrics
have been proposed for object-oriented systems. These are summarized in the table below.

Example: void selSort(int x[], int n) { //Below function sorts an array in ascending order int i,
j, min, temp; for (i = 0; i < n-1; i++) { min = i; for (j = i+1; j < n; j++) if (x[j] < x[min]) min = j; if (i
!= min) { temp = x[i]; x[i] = x[min]; x[min] = temp; } } }

(Reference: Pressman, Chapter 22, Section 22.7 - Metrics for Object-Oriented Projects)

Factors Influencing Project Management

Factors that influence project management include people, product, process, and project
specifics, as well as external factors like technology changes, market conditions, and
organizational constraints.

(Reference: Pressman, Chapter 21, Section 21.6 - Factors That Influence Software
Projects)

[Link] 63/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Risk Management
Risk management is concerned with identifying risks and drawing up plans to minimize
their effect on a project.

Risk management is the process of identifying, assessing, and controlling threats to an

organization's capital and earnings.

(Reference: Pressman, Chapter 25, Section 25.1 - Risk Management)

Reactive versus Proactive Risk Strategies

Reactive Risk Management: Project team reacts to risks when they occur. Mitigation
—plan for additional resources in anticipation of fire fighting. Fix on failure—fire fighting
is performed when risk becomes a reality.

Proactive Risk Management: Formal risk analysis is performed. Organization corrects

the root causes of risk. TQM concepts and statistical SQA. Examining risk sources that
lie beyond the bounds of the software. Developing the skill to manage change.

(Reference: Pressman, Chapter 25, Section 25.2 - Reactive versus Proactive Risk
Strategies)

Risks Monitoring and Management

An effective strategy must consider three issues: risk avoidance, risk monitoring, and
risk management and contingency planning.

Maintain a global perspective—view software risks within the context of system and the
business problem.

Take a forward-looking view—think about the risks that may arise in the future; establish
contingency plans so that future events are manageable.

Encourage adequate communication about risks among all stakeholders.

Establish a schedule for reviewing risks.

If these factors are considered, the project manager should monitor the effectiveness of
risk mitigation steps.

Risk management and contingency planning assume that mitigation efforts have failed
and that the risk has become a reality.

If you don’t actively attack the risks, they will actively attack you.

[Link] 64/65
11/29/25, 2:30 AM Software Engineering Fundamentals and Processes - Grok

Major projects should all have a risk management plan.

Integrate—a consideration of risk must be integrated into the software process.

Emphasize a continuous process—the team must be vigilant throughout the software

process, modifying identified risks as more information is known and adding new ones
as better insight is achieved.

Develop a shared product vision—if all stakeholders share the same vision of the
software, it is likely that better risk identification and assessment will occur.

(Reference: Pressman, Chapter 25, Section 25.5 - Risk Monitoring)

[Link] 65/65