SOFTWARE ENGINEERING

Complete Study Guide

BCA Semester 5 | B23-CAP-501 | Kurukshetra University
All 4 Units | Deep Explanations | Diagrams | Code Examples | Niche Questions

Prepared for: Gurbachan | Roll No: 2430043

UNIT I — Introduction to Software Engineering
This unit covers the foundational concepts of software engineering — what software is, the
crisis that led to formal engineering practices, the phases involved in developing software,
and the major development process models used in industry.

1.1 Program vs Software

A program is a set of instructions written to perform a specific task. Software is much
broader — it includes programs, documentation, and operating procedures that together
form a complete system.

Aspect Program Software

Definition Set of instructions for a task Complete system: code + docs +
data
Scope Small, single purpose Large, multi-component
Documentation Usually none Essential and required
Development One person, informal Team-based, formal process
Maintenance Rarely maintained Regularly updated and
maintained
Example A single Python script Microsoft Word, Android OS

💡 Exam Tip: A very common 2-mark question. Remember: Software = Program +

Documentation + Data + Operating procedures.
🎯 Niche Q: Is all software a program? Is all program software?
→ All software contains programs but not all programs are software. A standalone script with no
documentation or system design is a program, not software in the engineering sense.

1.2 Software Engineering

Software Engineering is the systematic application of engineering principles, methods, and
tools to develop and maintain high-quality software systems. It emerged as a discipline in the
late 1960s to address the software crisis.
• It applies engineering principles to software development
• It ensures software is reliable, efficient, maintainable and scalable
• IEEE defines it as: the application of a systematic, disciplined, quantifiable approach
to development, operation, and maintenance of software

📝 The word 'systematic' is key in any definition — software engineering is not random coding.
1.3 Programming Paradigms
A programming paradigm is a fundamental style or approach to programming. Different
paradigms solve problems in different ways.

Paradigm Description Example Languages

Procedural Step-by-step instructions, top-down C, Pascal, Fortran
approach
Object-Oriented Data and behavior bundled in objects Java, C++, Python
Functional Functions as first-class citizens, no side Haskell, Lisp, Erlang
effects
Declarative Describe what to do, not how SQL, HTML, Prolog
Event-Driven Program flow driven by user events JavaScript, Visual Basic

💡 Exam Tip: OOP paradigm is most commonly asked. Know the 4 pillars: Encapsulation,
Inheritance, Polymorphism, Abstraction.
🎯 Niche Q: Can a language support multiple paradigms?
→ Yes — Python supports procedural, OOP and functional paradigms. These are called multi-
paradigm languages.

1.4 Software Crisis

The Software Crisis refers to the period in the late 1960s when software projects were
consistently failing — running over budget, delivered late, full of bugs, or simply not working.
It led to the birth of software engineering as a formal discipline.

Problems (What caused the crisis):

• Projects ran massively over time and over budget
• Software was unreliable — full of bugs that were hard to find and fix
• Software was difficult to maintain as requirements changed
• No formal methods existed — coding was informal and undisciplined
• Communication gap between developers and clients
• Hardware became cheaper but software costs kept rising

Causes (Why it happened):

• Rapidly increasing hardware capability demanded more complex software
• No structured design methodologies existed
• Teams had no formal project management training
• Requirements were poorly understood and kept changing
• No quality assurance or testing processes
 💡 Exam Tip: Always remember: the software crisis had both problems AND causes —
exams often ask both separately.
🎯 Niche Q: Is the software crisis over?
→ No — the term 'software crisis' is ongoing. The Standish Group CHAOS Report still shows a
significant percentage of software projects failing or being challenged every year. The crisis simply
evolved, not resolved.

1.5 Phases in Software Development (SDLC)

The Software Development Life Cycle (SDLC) is a structured process that defines the
phases involved in creating a software system from inception to retirement.

Phase 1: Requirement Analysis

The most critical phase. Developers and clients work together to understand what the
software must do. Output is a Software Requirements Specification (SRS) document.
• Functional requirements: what the system does (login, search, calculate)
• Non-functional requirements: how the system performs (speed, security, scalability)
• Tools used: interviews, questionnaires, observation, prototyping

Phase 2: System Design

The SRS is translated into a blueprint for the software. This includes architecture, database
design, UI design, and module structure.
• High-level design (HLD): overall system architecture
• Low-level design (LLD): detailed design of each module

Phase 3: Implementation (Coding)

Developers write actual code based on the design documents. The chosen programming
language, tools and standards are applied here.

Phase 4: Testing
The software is tested to find and fix defects before delivery. Different types of testing verify
different aspects of the system.

Phase 5: Deployment
The tested software is delivered to the customer and installed in the production environment.

Phase 6: Maintenance
Post-delivery support. Bugs are fixed, new features added, and performance improved. This
phase consumes 60-70% of total software cost over the product lifetime.
 💡 Exam Tip: Exam often asks: which phase is most expensive? Maintenance. Which phase
is most critical? Requirement Analysis — a mistake here multiplies in cost as development
progresses.
🎯 Niche Q: Why does a mistake in requirement analysis cost more to fix than a mistake in
coding?
→ Because requirements drive every subsequent phase. If requirements are wrong, design is
wrong, code is wrong, tests are wrong. By the time the mistake is discovered, rework spans multiple
phases. This is called the Cost of Defect Amplification — IBM research showed a requirements defect
costs 100x more to fix in maintenance than if caught during requirements phase.

1.6 Software Development Process Models

A process model defines the sequence and organization of SDLC phases. Different models
suit different types of projects.

Waterfall Model
The oldest and simplest model. Phases flow sequentially like a waterfall — each phase must
be completed before the next begins.

DIAGRAM — Waterfall Flow:

Requirements → System Design → Implementation → Testing → Deployment →
Maintenance
↓ ↓ ↓ ↓ ↓
↓
[SRS Doc] [Design Doc] [Code] [Test Report] [Release]
[Updates]

Characteristics:
• Sequential — one phase at a time, no overlap
• Document-driven — each phase produces formal documentation
• Easy to understand and manage
• Progress is easily measurable

Advantages Disadvantages
Simple and easy to understand Not flexible — changes are costly
Well-documented at each stage Customer sees product only at the end
Works well for stable requirements Testing only after full development
Easy to manage due to rigidity Not suitable for complex or long projects
Clear milestones High risk — errors found late are expensive

Best suited for: Projects with very clear, stable, and well-understood requirements. Example:
government contracts, embedded systems.
💡 Exam Tip: Waterfall is criticized most in exams — know ALL disadvantages. Most
important: no customer feedback until end, inflexible to change.
🎯 Niche Q: Can you go backwards in the Waterfall model?
→ In pure Waterfall — no. However Modified Waterfall allows limited feedback loops between
adjacent phases. Pure Waterfall is strictly sequential with no iteration.

Prototype Model
A working model (prototype) of the software is built quickly to demonstrate functionality to
the client. Based on feedback, the prototype is refined until the client approves, then the
actual system is built.

Requirements → Quick Design → Build Prototype → Client Evaluation

↑ ↓
Refine Prototype ← Client Feedback
↓ (approved)
Engineer Final Product → Test → Deploy

Advantages Disadvantages
Client sees the product early Client may mistake prototype for final product
Reduces risk of requirement misunderstanding Developers may take shortcuts in prototype
Good for unclear requirements Prototype may become the final system (poor
quality)
Early user feedback Time spent on prototype can be wasted
Better user satisfaction Scope creep — client keeps asking for more
changes

💡 Exam Tip: Key exam point: Prototype is thrown away after approval (throwaway
prototype) vs evolutionary prototype where it becomes the final system. Know the
difference.
🎯 Niche Q: What is the difference between throwaway prototyping and evolutionary
prototyping?
→ In throwaway prototyping, the prototype is discarded after requirements are understood and the
actual system is built from scratch. In evolutionary prototyping, the prototype is continuously refined
and eventually becomes the final system. Throwaway prototyping is safer for quality; evolutionary
prototyping is faster.

Evolutionary Model
Software is developed in small increments. Each increment adds functionality. The system
evolves over time through multiple releases. Better suited to changing requirements than
Waterfall.

Initial Requirements → Version 1.0 (core features)

↓
User Feedback → Version 2.0 (more features added)
↓
User Feedback → Version 3.0 (enhanced)
↓ (continues until complete)
 • Incremental delivery — each release is a working system
• Client uses early versions while development continues
• Good for large, long-term projects
• Risk is reduced since problems are found early

Spiral Model
Developed by Barry Boehm in 1988. Combines elements of both Waterfall and Prototype
models. Each cycle (spiral) passes through 4 phases: Planning, Risk Analysis, Engineering,
and Evaluation.

↗ PLANNING ↘
EVALUATION RISK ANALYSIS
↖ ENGINEERING ↙

Each complete loop = one spiral = one version of software

Spirals grow outward → more features each iteration

4 Phases of each Spiral:

1. Planning: Define objectives, alternatives, and constraints for this spiral
2. Risk Analysis: Identify and resolve risks. Build prototype if needed
3. Engineering: Develop and test the product for this spiral
4. Evaluation: Customer evaluates the current version and gives feedback

Advantages Disadvantages
Best for risk management Complex — hard to manage
Works with changing requirements Expensive — each spiral has full 4 phases
Early customer involvement Requires risk assessment expertise
Each spiral delivers working software Not suitable for small projects
Flexible — accommodates changes Can spiral indefinitely without end criteria

💡 Exam Tip: Spiral model's key distinguishing feature is RISK ANALYSIS in every iteration.
If an exam asks 'which model focuses most on risk management' — always Spiral.
🎯 Niche Q: How does the Spiral model differ from Incremental model?
→ Incremental model focuses on delivering features in pieces but doesn't explicitly handle risk.
Spiral model explicitly performs risk analysis in every iteration and uses prototyping to resolve risks
before committing to development. Spiral is risk-driven; Incremental is feature-driven.

1.7 Role of Metrics in Software Engineering

Software metrics are quantitative measures used to assess the quality, productivity, and
progress of software development. They help managers make data-driven decisions.
 Type What it Measures Example
Product Metrics Quality of the software itself Lines of Code (LOC), defect
density
Process Metrics Quality of development process Time per phase, defect
removal efficiency
Project Metrics Project management data Cost, schedule variance, team
productivity

• LOC (Lines of Code) — simplest but controversial metric

• Function Points — measures functionality independent of language
• Cyclomatic Complexity — measures code complexity
• Defect Density — number of defects per KLOC (thousand lines of code)

🎯 Niche Q: Why is LOC considered a poor metric?

→ LOC rewards verbose coding — a developer who writes more lines gets 'higher productivity'
even if the code is inefficient. A skilled developer might solve a problem in 10 lines that another writes
in 50. LOC also varies by programming language — a Java program has more LOC than equivalent
Python.

Unit I — Quick Revision Box

Topic One-Line Summary
Program vs Software Program = instructions only. Software = program + docs +
data
Software Engineering Systematic application of engineering principles to software
Software Crisis Late 1960s — projects failing due to no formal methods
SDLC 6 phases: Requirements → Design → Code → Test →
Deploy → Maintain
Waterfall Sequential, rigid, document-driven, no iteration
Prototype Build quick model → get feedback → refine → build real
system
Evolutionary Build in increments, each release is working software
Spiral 4-phase cycles, risk-driven, combines Waterfall +
Prototype
Metrics Quantitative measures: LOC, function points, defect
density
UNIT II — SRS & Structured Analysis
This unit covers how to capture and document what a software system must do (SRS), and
the tools used to visually represent the system structure — DFDs, ER diagrams, data
dictionaries, and decision tables.

2.1 Feasibility Study

Before committing resources to a project, a feasibility study determines whether the project
is worth pursuing. It is the first step in the SDLC.

Type Question It Answers Example

Technical Feasibility Can we build this with current Is the required
technology? hardware/software
available?
Economic Feasibility Is it cost-effective to build? Will ROI justify the
investment?
Operational Feasibility Will users actually use and accept Is the system compatible
this system? with current workflows?
Legal Feasibility Does it comply with laws and GDPR, data privacy,
regulations? intellectual property
Schedule Feasibility Can we build it in the required Is the deadline realistic
timeframe? given team size?

💡 Exam Tip: Exams ask all 5 types. The acronym TELOS covers them: Technical,
Economic, Legal, Operational, Schedule.
🎯 Niche Q: What happens if a project fails the feasibility study?
→ The project is either cancelled, redesigned with reduced scope, or postponed. A feasibility study
prevents wasting resources on projects that cannot succeed — this is why it is done before any
development begins.

2.2 Software Requirements Analysis and Specification (SRS)

What is an SRS?
A Software Requirements Specification (SRS) is a formal document that precisely describes
what the software system must do, under what constraints, and how it should perform. It is
the contract between the client and the development team.

Need for SRS:

• Provides a baseline for project planning and cost estimation
• Eliminates ambiguity between client and developers
• Serves as a reference for testing — testers verify software against SRS
 • Legal document — binding agreement on what will be delivered
• Reduces rework — clear requirements prevent costly changes later

Characteristics of a Good SRS (IEEE Standard):

Characteristic Meaning
Correct Every requirement stated is actually what the system should do
Unambiguous Each requirement has only one possible interpretation
Complete All possible states, inputs and responses are covered
Consistent No two requirements contradict each other
Ranked by Importance Requirements prioritized as essential, conditional, optional
Verifiable Each requirement can be tested to confirm it is met
Modifiable Structure allows easy updates without affecting other
requirements
Traceable Each requirement can be traced to its source and to its
implementation

💡 Exam Tip: These 8 characteristics are a very common question. IEEE defines them —
memorize all 8 with a one-word meaning each.
🎯 Niche Q: What makes a requirement 'unambiguous' vs 'complete'?
→ Unambiguous means one requirement cannot be interpreted in two ways — 'the system should
be fast' is ambiguous; 'response time must be under 2 seconds' is unambiguous. Complete means all
scenarios are covered — if the SRS doesn't mention what happens on login failure, it is incomplete
even if the login success flow is perfect.

Components of SRS:
5. Introduction: purpose, scope, definitions, overview
6. Overall description: product perspective, functions, user characteristics, constraints
7. Specific requirements: functional requirements, non-functional requirements,
interface requirements
8. Appendices: data flow diagrams, ER diagrams, data dictionary

2.3 Problem Analysis & Information Gathering Tools

Before writing an SRS, analysts gather information about the problem domain and user
needs using various techniques:

Tool How it works Best for

Interviews Direct 1-on-1 conversation with Detailed qualitative
stakeholders information
Questionnaires Written set of questions distributed to Large groups, quantitative
users data
 Observation Watch users doing their current work Understanding actual
workflow
Document Review Analyze existing manuals, reports, Understanding current
forms system
Prototyping Build mockup to clarify requirements When requirements are
unclear
Brainstorming Group session to generate ideas Early stage, creative
requirements
JAD Sessions Joint Application Development — Complex systems, multiple
structured workshops stakeholders

2.4 Data Flow Diagrams (DFD)

A DFD is a graphical representation of how data flows through a system. It shows where
data comes from, where it goes, what transforms it, and where it is stored — without
showing how the processing happens.

DFD Components (4 symbols):

Symbol Name Meaning Notation
Rectangle / Square External Entity Source or destination of data Square box
(outside system) with name
Circle / Bubble Process Transformation of data Circle with
process name
& number
Arrow Data Flow Movement of data between Arrow with
components data name on
it
Open Rectangle Data Store Repository where data is Two parallel
stored lines with
name

DFD Levels:
DFDs are drawn at different levels of abstraction:

Level 0 — Context Diagram:

Shows the entire system as a single process. Only external entities and their data flows
to/from the system are shown. No internal detail.

[Student]
| Student Details
↓
[0. Student Management System]
| Report
 ↓
[Teacher]

Level 1 — Explodes the single process into major sub-processes:

[Student] ─── Student Data ──→ [1.0 Registration] ─── Student Record ──→
[Student DB]
|
Registered Student
↓
[2.0 Exam Process] ─── Marks ──→ [Marks DB]
|
Result
↓
[3.0 Report Generation] ──→ [Teacher]

Level 2 — Further explodes each Level 1 process:

Each process in Level 1 is broken down into sub-processes. This continues until processes
are atomic (cannot be broken further).

Level Also Called What It Shows

Level 0 Context Diagram Entire system as one process, all external entities
Level 1 System Diagram Major processes within the system
Level 2 Detailed DFD Sub-processes within each Level 1 process
Level 3+ Primitive DFD Atomic processes that cannot be broken further

💡 Exam Tip: DFDs are PRACTICAL exam questions. Practice drawing Level 0, 1, and 2 for:
Library Management, Hospital Management, Student Result System.
🎯 Niche Q: What is 'balancing' in DFDs?
→ A DFD is balanced if the data flows coming into and going out of a process at Level N exactly
match the flows at Level N+1 when that process is exploded. If Level 1 shows Student Data flowing
into Process 1.0, then Level 2 must also show Student Data entering the expanded process. Violating
this is called an unbalanced DFD and is a design error.

2.5 Data Dictionary

A Data Dictionary is a structured repository that defines all data elements in a system —
their names, types, descriptions, and relationships. It accompanies the DFD.

Example — Data Dictionary Entry for 'Student Record':

Name: Student_Record
Description: Complete data of a registered student
Composed of: Student_ID + Student_Name + Course + Semester + Marks_List
 Student_ID: Numeric, 7 digits, range 1000000 to 9999999
Student_Name: Alpha, max 50 chars, format: First_Name + Last_Name
Course: Alpha, values: BCA | BBA | BSc
Semester: Numeric, range 1-6
Marks_List: List of {Subject_Code + Marks_Obtained}

Data Dictionary Notations:

Symbol Meaning Example
= is composed of Student = Name + ID + Course
+ and (sequence) Name = First + Last
[|] either/or (selection) Grade = [A|B|C|D|F]
{} iteration (repetition) {Subject_Mark} means repeated
() optional Middle_Name = (Name)
** comment * this field is mandatory *

2.6 Decision Tables

A Decision Table is a tabular representation of complex business logic that involves multiple
conditions and actions. It ensures all combinations of conditions are handled.

Structure of a Decision Table:

| Rule 1 | Rule 2 | Rule 3 | Rule 4 |
CONDITIONS: | | | | |
Age >= 18 | Y | Y | N | N |
Has Valid ID | Y | N | Y | N |
| | | | |
ACTIONS: | | | | |
Allow Entry | X | | | |
Request More Proof | | X | | |
Deny Entry | | | X | X |

• Y = condition is true, N = condition is false, X = action to perform

• Every possible combination of conditions gets a rule column
• For n conditions, maximum 2^n rules (2^2 = 4 rules for 2 conditions above)

💡 Exam Tip: Decision Table questions often ask you to build one from a scenario. Always
count conditions first, calculate max rules (2^n), then fill.
🎯 Niche Q: What is a limited entry vs extended entry decision table?
→ In a limited entry table, conditions are only Y/N and actions are only marked/blank (like the
example above). In an extended entry table, conditions can have values (Age > 18, Age 13-18, Age <
13) and actions can have values (50% discount, 25% discount). Extended entry is more compact but
limited entry is easier to verify for completeness.
2.7 Decision Trees
A Decision Tree represents the same logic as a decision table but in a hierarchical tree
structure. Each branch represents a condition and each leaf represents an action.

START
|
Age >= 18?
/ \
YES NO
| |
Has Valid ID? DENY ENTRY
/ \
YES NO
| |
ALLOW ENTRY REQUEST PROOF

Decision Table Decision Tree

Tabular format Tree/hierarchical format
All conditions shown at once Conditions shown sequentially
Easy to check completeness Easy to follow logic flow
Better for complex condition combinations Better for sequential decision making
Harder to read for non-technical users Easier to understand visually

2.8 Structured English

Structured English (also called pseudo-code) is a semi-formal language used to describe
process logic in a way that is unambiguous yet readable by non-programmers. It uses a
limited subset of English with programming constructs.

Example — Library Book Issue Process in Structured English:

BEGIN Issue_Book
INPUT Member_ID, Book_ID
IF Member_ID is valid THEN
IF Book_ID is available THEN
Record issue with current date
Update book status to 'Issued'
PRINT 'Book issued successfully'
ELSE
PRINT 'Book not available'
END IF
ELSE
PRINT 'Invalid member'
END IF
END Issue_Book
 📝 Structured English uses: SEQUENCE (step by step), SELECTION (IF/ELSE), ITERATION
(WHILE/FOR). These 3 constructs cover all logic.

2.9 Entity-Relationship (ER) Diagrams

An ER Diagram is a graphical representation of the data and relationships in a database. It is
a key design tool for database planning.

ER Diagram Components:
Component Symbol Description
Entity Rectangle A real-world object or thing (Student, Book,
Doctor)
Attribute Oval/Ellipse Property of an entity (Name, Age, ID)
Primary Key Underlined Oval Unique identifier attribute
Relationship Diamond Association between entities (Enrolls, Borrows,
Treats)
Weak Entity Double Rectangle Entity that depends on another for identification
Derived Attribute Dashed Oval Attribute computed from other attributes (Age
from DOB)
Multivalued Attribute Double Oval Attribute with multiple values (Phone Numbers)

Cardinality (Relationship Types):

Type Symbol Meaning Example
One-to-One (1:1) 1 ─── 1 One instance relates to exactly Person has one
one other Passport
One-to-Many (1:N) 1 ─── M One instance relates to many Teacher teaches
others many Students
Many-to-Many (M:N) M ─── N Many instances relate to many Student enrolls in
others many Courses

Example — Student-Teacher ER Diagram:

[Student]─────────────<Enrolls>─────────────[Course]
| |
Attributes: Attributes:
- Student_ID (PK, underlined) - Course_ID (PK)
- Name - Course_Name
- Roll_No - Credits
- DOB - Department
|
[Student] M ─── Taught_By ─── 1 [Teacher]
|
- Teacher_ID (PK)
- Name
 - Department
- Phone (multivalued: ==Oval==)

💡 Exam Tip: ER diagrams are PRACTICAL marks. Practice drawing for: Library, Hospital,
Bank ATM, Hotel Management, Railway Reservation. Know all symbols perfectly.
🎯 Niche Q: What is a weak entity and how is it identified in an ER diagram?
→ A weak entity cannot be uniquely identified by its own attributes alone — it depends on a strong
(owner) entity. Example: Room in a Hotel — Room 101 isn't unique globally, but Hotel A Room 101 is
unique. In an ER diagram, weak entities use double rectangles, their identifying relationship uses a
double diamond, and their partial key (discriminator) is underlined with a dashed line.

Unit II — Quick Revision Box

Topic One-Line Summary
Feasibility Study TELOS: Technical, Economic, Legal, Operational, Schedule
SRS Contract between client & developer — 8 characteristics (IEEE)
DFD Level 0 Context diagram — entire system as one bubble
DFD Level 1 Major processes exposed — balanced with Level 0
DFD Level 2 Sub-processes of Level 1 — balanced with Level 1
Data Dictionary Defines every data element: name, type, composition
Decision Table Conditions vs Rules matrix — 2^n rules for n conditions
Decision Tree Same logic as decision table but in tree format
Structured English Pseudo-code: SEQUENCE + SELECTION + ITERATION
ER Diagram Entity(rect) + Attribute(oval) + Relationship(diamond)
UNIT III — Project Planning, Design & Risk
Management
This unit covers how software projects are estimated, planned, scheduled, and designed —
including cost models, team structures, risk management, and core design principles like
cohesion and coupling.

3.1 Software Project Planning

Project planning defines what needs to be done, who does it, when, and with what
resources. A project plan is created before development begins and updated throughout.

• Scope Definition: what the project will and will not deliver
• Resource Planning: team members, tools, hardware, budget
• Schedule Planning: timeline, milestones, deadlines
• Risk Planning: identify potential risks and mitigation strategies
• Quality Planning: define standards and testing criteria

3.2 Cost Estimation — COCOMO Model

COCOMO (Constructive Cost Model) was developed by Barry Boehm in 1981. It is a widely
used algorithmic cost estimation model that estimates software project effort, time, and cost
based on the size of the software (measured in KLOC — Kilo Lines of Code).

Three COCOMO Modes:

Mode Project Type Team Example
Organic Small, simple, well-understood Small, experienced, Simple payroll system,
requirements familiar with system inventory system
Semi-Detached Medium size, mixed Mixed experience levels Transaction processing,
experience, some novel database systems
aspects
Embedded Large, complex, tight Requires innovation and Air traffic control, banking
constraints (hardware/OS) experience systems, OS

Basic COCOMO Formula:

Effort (E) = a × (KLOC)^b [Person-Months]
Time (T) = c × (E)^d [Months]
People (P) = E / T [Person count]

Mode a b c d
 Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

Worked Example:
Project: A semi-detached software system of 32 KLOC

E = 3.0 × (32)^1.12
= 3.0 × 32^1.12
= 3.0 × 48.5 (approx)
= 145.6 Person-Months

T = 2.5 × (145.6)^0.35
= 2.5 × 6.6 (approx)
= 16.5 Months

P = 145.6 / 16.5
≈ 8.8 → 9 People required

💡 Exam Tip: COCOMO numerical problems appear every semester. Practice the formula.
Key values to memorize: Organic (2.4, 1.05), Semi-Detached (3.0, 1.12), Embedded (3.6,
1.20).
🎯 Niche Q: What is the difference between Basic COCOMO and Intermediate COCOMO?
→ Basic COCOMO estimates based on KLOC alone using simple formulas. Intermediate
COCOMO adds Cost Driver Attributes — 15 factors that adjust the effort based on product attributes
(reliability, complexity), computer attributes (execution time), personnel attributes (experience), and
project attributes (tools used). Intermediate COCOMO is more accurate because it accounts for
project-specific factors.

3.3 Project Scheduling

Project scheduling defines when tasks will be done. It uses techniques like Gantt Charts and
PERT/CPM networks to plan and track progress.

Milestones vs Deliverables:
• Milestone: a significant point in the project timeline (e.g., 'Requirements Complete',
'Code Review Done')
• Deliverable: a tangible output produced at a milestone (e.g., SRS document, tested
code)

Gantt Chart:
A Gantt Chart is a bar chart that shows tasks on the Y-axis and time on the X-axis. Each
task is shown as a horizontal bar spanning its start and end dates.
 Task | Week 1 | Week 2 | Week 3 | Week 4 | Week 5 |
──────────────────|────────|────────|────────|────────|────────|
Requirements |████████|████ | | | |
System Design | | ████|████████| | |
Coding | | | ████|████████|████ |
Testing | | | | ████|████████|

• Simple to understand and create

• Shows task duration and overlap clearly
• Does not show task dependencies explicitly

3.4 Team Structure

How a software development team is organized affects communication, accountability and
productivity. Three main structures:

Structure Description Best For

Chief Programmer Team One highly skilled chief programmer Small projects needing high
leads, others support. Hierarchical. expertise
Democratic Team All members equal, decisions by Research projects, creative
consensus. Egoless programming. work
Mixed Team Combines both — hierarchy at top, Medium to large commercial
democratic within sub-teams projects

🎯 Niche Q: What is 'egoless programming'?

→ Coined by Gerald Weinberg — the idea that programmers should not treat their code as personal
property. Code is opened for peer review without defensiveness. This improves code quality because
developers find bugs in each other's code more easily. Democratic teams practice egoless
programming.

3.5 Software Configuration Management (SCM)

SCM is the process of tracking and controlling changes to software. It ensures the team
always works with the correct version of files and can recover from errors.

• Version Control: tracking changes to files over time (Git, SVN)

• Change Control: formal process for approving changes
• Configuration Identification: naming and labeling software versions
• Configuration Auditing: verifying that the software matches its documentation
• Status Reporting: reporting the status of configuration items

📝 Git is the most common version control system today. SCM is why your internship list included
Git — directly relevant to this topic.
3.6 Risk Management
Risk management identifies potential problems before they occur so they can be avoided or
their impact reduced. A risk is any event that might jeopardize the project's success.

Types of Risks:
Type Description Example
Project Risk Threatens project schedule, Key developer leaves the team
resources or budget
Technical Risk Threatens quality or performance New technology doesn't work as
of software expected
Business Risk Threatens commercial viability Competitor releases similar product
first
Known Risks Risks that can be identified by Dependencies on third-party
analysis libraries
Unknown Risks Cannot be predicted in advance Natural disaster, global pandemic

Risk Management Process:

9. Risk Identification: list all possible risks using checklists, brainstorming, past
experience
10. Risk Analysis: assess likelihood (probability) and impact of each risk
11. Risk Prioritization: rank risks by exposure = probability × impact
12. Risk Planning: develop strategies to handle each risk
13. Risk Monitoring: track risks throughout the project

Risk Strategies:
Strategy Description
Risk Avoidance Change the project plan to eliminate the risk entirely
Risk Transfer Transfer the risk to a third party (insurance, outsourcing)
Risk Reduction Take steps to reduce probability or impact
Risk Acceptance Accept the risk and deal with it if it occurs (contingency plan)

💡 Exam Tip: Risk Exposure = Probability × Impact. This formula appears in numerical
questions. Example: 40% chance of a bug causing 2-week delay → Exposure = 0.4 × 10
days = 4 person-days.
🎯 Niche Q: What is the difference between Risk Reduction and Risk Avoidance?
→ Risk Avoidance eliminates the risk entirely by changing the plan — e.g., avoiding a risky new
technology by using a proven one instead. Risk Reduction doesn't eliminate the risk but reduces its
likelihood or impact — e.g., creating daily backups reduces the impact of data loss but doesn't
eliminate the possibility. Avoidance is more drastic; Reduction is more practical.
3.7 Software Design Fundamentals
Software design transforms the requirements from the SRS into a blueprint for constructing
the software. Good design leads to maintainable, efficient, reliable software.

Design Principles:
• Abstraction: focus on essential features, hide implementation details
• Modularity: divide software into smaller, manageable modules
• Problem Partitioning: break a large problem into smaller sub-problems
• Separation of Concerns: different aspects of the system handled by different modules
• Information Hiding: internal module details hidden from other modules

Design Methodology — Top-Down vs Bottom-Up:

Approach Description Advantage
Top-Down Start with high-level design, refine into Better for understanding
details. Decomposition. overall system structure
Bottom-Up Start with low-level components, combine Better for reusing existing
into higher system. components

3.8 Cohesion & Coupling

Cohesion and Coupling are two of the most important design quality metrics. The goal of
good design is HIGH COHESION and LOW COUPLING.

Cohesion — How well a module's elements belong together:

Cohesion measures how closely related the functions within a single module are. High
cohesion means a module does ONE well-defined thing.

Type (Best→Worst) Description Example

Functional (Best) Module performs one specific, well- Calculate_Tax() — only
defined task calculates tax
Sequential Output of one function is input to Read_Data → Process_Data
next → Write_Data in one module
Communicational Functions use same input/output Module that reads and updates
data same customer record
Procedural Functions must execute in a specific Open file → Read → Process
order → Close in one module
Temporal Functions executed at the same Startup module: initialize all
time systems at startup
Logical Functions categorized as same type Module for all I/O operations
but unrelated — keyboard, disk, network
 Coincidental (Worst) Functions have no meaningful Utility module with random
relationship unrelated functions

Coupling — How dependent modules are on each other:

Coupling measures the degree of interdependence between modules. Low (loose) coupling
means modules are independent — a change in one doesn't require changes in others.

Type (Best→Worst) Description Example

No Coupling (Best) Modules completely independent Two separate utility libraries
Data Coupling Modules share data through function(name, age) — simple
parameters only data passed
Stamp Coupling Modules share composite data Passing entire Student object
structure when only name needed
Control Coupling One module controls execution of Passing a flag like isAdmin to
another via flags control behavior
External Coupling Modules share external data (global Both modules read same
variables) configuration file
Common Coupling Modules share global data Both modules modify same
structures global array
Content Coupling (Worst) One module directly accesses Module A directly modifies
internals of another Module B's local variables

💡 Exam Tip: The golden rule: MAXIMIZE COHESION, MINIMIZE COUPLING. Functional
cohesion is best. Content coupling is worst. These are guaranteed exam questions.
🎯 Niche Q: Why is high cohesion related to low coupling?
→ When a module has high cohesion (does one specific thing well), it naturally has fewer reasons
to depend on other modules, resulting in lower coupling. Conversely, when a module does many
unrelated things (low cohesion), it tends to need data and functions from many other modules (high
coupling). Good design principles reinforce each other.

Quality Assurance Plans:

A Software Quality Assurance (SQA) Plan defines the standards, procedures, and
responsibilities for ensuring software quality throughout the project.
• Defines quality standards (IEEE, ISO 9001)
• Specifies review and audit procedures
• Defines testing standards and entry/exit criteria
• Identifies tools to be used for quality checking

Unit III — Quick Revision Box

Topic One-Line Summary
COCOMO Cost model: E = a(KLOC)^b. Organic/Semi-Detached/Embedded
 modes
Organic Small projects: a=2.4, b=1.05
Semi-Detached Medium projects: a=3.0, b=1.12
Embedded Large/complex: a=3.6, b=1.20
Risk Exposure Probability × Impact = Risk Exposure
Risk Strategies Avoidance, Transfer, Reduction, Acceptance
High Cohesion Module does ONE thing well — Functional is best
Low Coupling Modules independent — Data coupling is best
SCM Version control + change control + configuration auditing
Team Structures Chief Programmer, Democratic, Mixed
UNIT IV — Testing & Maintenance
This unit covers how software is tested to verify it works correctly, and how it is maintained
after delivery. Testing is a critical quality activity — the goal is to find defects before the
software reaches users.

4.1 Software Testing Overview

Software testing is the process of executing a program with the intent of finding errors.
Testing cannot prove a program is error-free — it can only show that errors are present.

• Verification: Are we building the product right? (against specification)

• Validation: Are we building the right product? (against user needs)

📝 Verification checks documents and code against requirements. Validation checks the final
product against user needs. Both are necessary.

4.2 Unit Testing

Unit testing tests individual components (functions, modules, classes) in isolation. It is
typically done by developers during the coding phase.

What unit testing verifies:

• Individual function logic is correct
• Boundary conditions are handled properly
• Error handling works as expected
• Module interfaces are correct

Example — Unit Test for a function:

# Function to test
def calculate_grade(marks):
if marks >= 90: return 'A'
elif marks >= 80: return 'B'
elif marks >= 70: return 'C'
elif marks >= 60: return 'D'
else: return 'F'

# Unit Tests
assert calculate_grade(95) == 'A' # Normal A case
assert calculate_grade(90) == 'A' # Boundary — exactly 90
assert calculate_grade(89) == 'B' # Just below A
assert calculate_grade(0) == 'F' # Minimum case
assert calculate_grade(100) == 'A' # Maximum case
 💡 Exam Tip: Unit testing is FIRST level of testing. Done by DEVELOPERS. Tests individual
functions/modules in isolation.
🎯 Niche Q: What is a test stub and a test driver in unit testing?
→ When testing a module in isolation, it may depend on other modules not yet built. A Test Stub
replaces a called module (simulates the module being called by the unit under test). A Test Driver
replaces the calling module (simulates the module that calls the unit under test). Stubs and drivers
allow unit testing before the full system is built.

4.3 Integration Testing

Integration testing tests how multiple modules work together after individual unit testing. It
finds interface defects between modules.

Integration Strategies:
Strategy Description Advantage Disadvantage
Big Bang Combine all modules at Simple — just Hard to isolate faults
once and test together combine and test — which module
caused the error?
Top-Down Start with top-level module, Tests main control Stubs needed for all
add lower modules using flow early lower modules
stubs
Bottom-Up Start with lowest modules, Lower modules (often Top-level design
add higher modules using most complex) tested flaws found late
drivers first
Sandwich Combines top-down and Parallel testing, faster More complex to
bottom-up simultaneously manage

💡 Exam Tip: Big Bang is the worst strategy — always eliminated first in exam questions.
Top-Down is most commonly preferred for control-flow heavy systems.

4.4 Validation Testing

Validation testing verifies that the software meets user requirements as specified in the SRS.
It confirms that the right product was built.

• Tests against requirements in the SRS document

• Black-box testing — test what the system does, not how
• Configuration review — verify all documentation is correct
• Acceptance testing — done with customer present

📝 Validation testing = does the software do what the CLIENT asked for? Verification testing =
does the software match the SRS?
4.5 System Testing
System testing tests the complete, integrated software system against the overall system
requirements. It tests the system as a whole in a realistic environment.

Types of System Testing:

Type What It Tests
Functional Testing Does each function work as required?
Performance Testing Does the system meet speed and throughput requirements?
Load Testing How does system behave under expected load (normal users)?
Stress Testing How does system behave beyond normal load (extreme
conditions)?
Security Testing Can unauthorized users access the system?
Usability Testing Is the system easy to use?
Compatibility Testing Does it work on different OS, browsers, devices?
Recovery Testing Can the system recover from failures?

4.6 Alpha and Beta Testing

Alpha Testing:
Alpha testing is performed by internal teams (developers and QA) at the developer's site
before releasing to external users. The software is tested in a simulated or actual production
environment.
• Done by developer's own testing team
• Done in a controlled environment at developer's premises
• Can use both white-box and black-box techniques
• Goal: find bugs before real users see the software

Beta Testing:
Beta testing is performed by actual end-users in their own environment (real world). A limited
release of the software is given to selected users before the official launch.
• Done by actual end users (external, real customers)
• Done in user's own environment — real world conditions
• Developer not present — user reports bugs voluntarily
• Goal: get real-world feedback and find environment-specific issues

Aspect Alpha Testing Beta Testing

Who tests? Developer's internal team Actual end users
Where? Developer's premises User's own environment
 Control? Controlled, monitored Uncontrolled, real world
Phase? Before beta After alpha, before release
When found? Issues fixed immediately Issues reported to developer
Example? Microsoft internal testing Windows Insider Program

💡 Exam Tip: Alpha = internal + controlled. Beta = external + real world. Very common 2-
mark distinction question.
🎯 Niche Q: Can a product skip alpha testing and go directly to beta?
→ Technically yes, but it is extremely risky. Alpha testing catches critical bugs in a controlled
environment before real users encounter them. Skipping alpha means real users find the bugs —
damaging reputation and trust. Some startups skip formal alpha testing but this leads to poor-quality
beta releases. Best practice always includes both phases.

4.7 Software Maintenance

Software maintenance is the modification of a software product after delivery to correct
faults, improve performance, or adapt to a changed environment. It is the longest and most
expensive phase of the software lifecycle — consuming 60-80% of total lifecycle cost.

Types of Software Maintenance:

Type Description Triggered By Example
Corrective Fix bugs discovered after Bug reports from users Fixing a crash in payment
delivery module
Adaptive Modify software to work in Environment changes Updating app to work with
new environment new Android version
Perfective Improve performance or add User requests, business Adding dark mode,
new features growth improving search speed
Preventive Restructure code to prevent Proactive quality Refactoring messy code
future problems improvement before it causes bugs

💡 Exam Tip: CAPP acronym: Corrective, Adaptive, Perfective, Preventive. Most common is
Corrective in terms of frequency, but Perfective accounts for the largest percentage of
maintenance effort overall.
🎯 Niche Q: Why is preventive maintenance important even when the software is working fine?
→ Software that works today may become fragile over time due to accumulated technical debt —
messy code, outdated comments, poor structure. Preventive maintenance restructures and
documents this code before it causes failures. Without it, small future changes risk breaking the
system. The cost of preventive maintenance now is always lower than emergency corrective
maintenance later.

Management of Maintenance:
• Maintain a Change Request Log for all reported issues
• Prioritize changes: critical bugs first, enhancements later
 • Use Configuration Management to track all changes
• Regression test after every change — ensure existing functionality still works
• Maintain up-to-date documentation after every change

Maintenance Process:
14. Receive and record change request
15. Analyze impact of the change
16. Implement the change in a controlled manner
17. Test the change (unit + regression testing)
18. Document the change
19. Release the updated version

Maintenance Characteristics:
• Lehman's Laws: software must be continually adapted or it becomes progressively
less satisfactory
• Maintenance cost increases as the system ages and complexity grows
• Each change introduces risk of new bugs (regression risk)
• Maintenance is harder without good documentation
• Legacy systems — old systems that are expensive to maintain but critical to business

🎯 Niche Q: What is a 'legacy system' and what are the options for handling it?
→ A legacy system is an old software system that is outdated in terms of technology or design but
still critical to business operations. Options: (1) Maintain as-is — keep fixing bugs but no major
changes. (2) Reengineer — restructure the code while keeping functionality. (3) Replace — build a
completely new system. (4) Retire — phase out and replace with off-the-shelf software. The decision
depends on cost, risk, and business value.

Unit IV — Quick Revision Box

Topic One-Line Summary
Unit Testing Tests individual module/function — done by developers
Integration Testing Tests modules working together — Big
Bang/Top-Down/Bottom-Up
Validation Testing Confirms software meets user requirements (SRS)
System Testing Tests complete system — functional, performance, security,
load
Alpha Testing Internal team, developer's site, controlled environment
Beta Testing Real users, their own environment, uncontrolled
Corrective Maintenance Fix bugs found after delivery
Adaptive Maintenance Modify for new environment (new OS, hardware)
Perfective Maintenance Add features or improve performance
Preventive Maintenance Restructure code to avoid future problems
Maintenance Cost 60-80% of total software lifecycle cost
Master Niche Questions — All Units
These are the counter-questions and unexpected questions your examiner might ask. Study
these carefully.

Unit I Niche Questions

🎯 Niche Q: Why was the software crisis worse in the 1960s than today?
→ Because no formal methods existed. Today we have structured SDLC, design patterns, version
control, automated testing, agile methodologies — all developed as a direct response to the crisis.
The crisis still exists but is better managed.

🎯 Niche Q: Can the Waterfall model ever be appropriate in modern development?

→ Yes — for projects with completely stable requirements, regulatory compliance needs
(aerospace, medical devices), or fixed-price contracts where scope must be locked. The model's
rigidity becomes an advantage when requirements truly won't change.

🎯 Niche Q: Why does the Spiral model work better for large projects but worse for small ones?
→ Each spiral requires full risk analysis, prototyping, and evaluation — this overhead is worth it for
large projects where risks are significant. For a small 3-person project with clear requirements, this
overhead costs more time than it saves. Small projects are better suited to Waterfall or Agile.

Unit II Niche Questions

🎯 Niche Q: What is the difference between functional and non-functional requirements?
→ Functional requirements describe WHAT the system does — login, search, calculate, generate
report. Non-functional requirements describe HOW WELL it does it — response time under 2
seconds, 99.9% uptime, support 10,000 concurrent users, GDPR compliance. Both are essential in
the SRS.

🎯 Niche Q: Can a DFD show timing, control flow, or error handling?

→ No — DFDs show only DATA flow and TRANSFORMATION. They don't show time sequence,
control flow (if/else), or error conditions. For control flow, flowcharts or structure charts are used. This
is a fundamental limitation of DFDs.

🎯 Niche Q: What makes an ER diagram different from a class diagram?

→ ER diagrams model DATABASE structure — entities, attributes, and relationships for data
storage. Class diagrams (UML) model OBJECT-ORIENTED software structure — classes, methods,
attributes, and inheritance. ER diagrams are used for database design; class diagrams for software
design.

Unit III Niche Questions

🎯 Niche Q: Why is COCOMO considered outdated by some practitioners?
→ COCOMO was designed when LOC was the primary size metric and waterfall was the dominant
model. Modern Agile projects are hard to measure in KLOC upfront. Also, COCOMO doesn't account
for reuse of existing code, open-source components, or modern development tools that significantly
change productivity. COCOMO II was developed to address some of these issues.

🎯 Niche Q: What is the difference between quality assurance and quality control?
→ Quality Assurance (QA) is process-oriented — it prevents defects by improving the development
process (reviews, standards, training). Quality Control (QC) is product-oriented — it finds defects in
the actual software through testing and inspection. QA is proactive; QC is reactive. Both are part of
SQA.

Unit IV Niche Questions

🎯 Niche Q: What is regression testing and when is it done?
→ Regression testing re-runs existing tests after a code change to ensure that the change didn't
break anything that was previously working. It is done after every maintenance change, bug fix, or
new feature addition. Without regression testing, a fix for one bug often introduces new bugs
elsewhere.

🎯 Niche Q: What is the difference between Black-Box and White-Box testing?

→ Black-Box testing tests the software from the user's perspective without knowledge of internal
code — inputs and outputs only. White-Box testing tests the internal logic, code paths, and structure.
Black-Box suits validation and system testing; White-Box suits unit testing. Most real projects use
both.

🎯 Niche Q: Why does maintenance cost increase over time for a software system?
→ Due to entropy — as software is patched and modified, its structure degrades. Workarounds
accumulate, documentation becomes outdated, original developers leave. Each new change
becomes harder because the codebase is less understood. This is called software aging. Without
preventive maintenance and refactoring, the system eventually becomes unmaintainable — a legacy
system.
Exam Strategy for Software Engineering

Paper Pattern Reminder

• 9 questions total — Q1 is compulsory (short answer, covers all units)
• Attempt 5 questions total — 1 from each unit + Q1
• Q1 has short answers covering entire syllabus
• Each question carries equal marks

High-Priority Topics (Most Frequently Asked)

Topic Why It's Important
Development Models comparison Asked almost every semester — know all 4 models
COCOMO numerical Always a numerical question — practice the formula
Cohesion & Coupling types Full 10-mark question potential — know all levels
DFD drawing (all levels) Practical marks — practice drawing for 5+ systems
ER diagram drawing Same as DFD — practice is the only preparation
Alpha vs Beta testing Classic 2-mark question — always appears
Maintenance types (CAPP) Always asked — know all 4 with examples
SRS characteristics (8 IEEE) Direct memory question — list and explain all 8
Software Crisis problems+causes Foundational topic — always in Q1

Writing Tips for SE Exam

• Always define the term FIRST before explaining — start every answer with a one-line
definition
• Use tables for comparisons — they look organized and score well
• For models (Waterfall, Spiral etc.) — always draw a simple diagram
• For DFD/ER questions — draw neatly with proper symbols, label everything
• For COCOMO problems — show ALL working steps, not just the final answer
• End longer answers with advantages/disadvantages if space allows

— End of Software Engineering Study Guide —

Prepared for Gurbachan | BCA Sem 5 | Roll No: 2430043 | KUK