Course Introduction: Software Engineering
Software Engineering is the disciplined application of engineering principles to the development, operation, and maintenance of software. Unlike "just programming," software engineering treats software as an engineered product — built to specifications, tested to standards, delivered on a schedule, and maintained over a lifetime.
This course (IPU BCA) covers the complete software lifecycle across four units: process models and requirements (Unit I), planning, metrics and risk (Unit II), design, quality and implementation (Unit III), and testing and maintenance (Unit IV). By the end you will be able to model a real software project end-to-end — from gathering a client's requirements to estimating its cost, designing its modules, choosing test strategies, and planning its ongoing maintenance.
---
Why Software Engineering Exists — The Software Crisis
In the late 1960s the term software crisis was coined at the NATO Software Engineering Conference (1968, Garmisch). Hardware was advancing exponentially, but software projects kept failing: delivered late, over-budget, riddled with defects, or scrapped entirely. The IBM OS/360 project — 5,000 staff-years, repeatedly missed deadlines — became the textbook example.
| Symptom of the Crisis | Cause | Software Engineering Response |
|---|---|---|
| Projects deliver late | No realistic estimation | Function Point, COCOMO models |
| Cost overruns | Unmanaged scope | Change-control boards, configuration management |
| Bugs in production | Ad-hoc testing | Levels of testing, formal verification |
| Maintenance dominates cost | No documentation, no design | SRS, design documents, traceability |
| User dissatisfaction | Requirements never validated | Prototyping, requirements review |
The famous Standish CHAOS report has tracked IT project outcomes since 1994. Even in modern years, only ~30% of projects succeed; the rest are challenged (late/over-budget) or fail outright. Software engineering is the body of techniques developed to push that success rate up.
---
Software vs Program — The Critical Distinction
A program is a piece of code that solves one problem for its author. Software is an engineered product that solves problems for many users over a long period. The differences are substantial and define what software engineering must address:
| Aspect | Program | Software |
|---|---|---|
| Author = User? | Yes | No — many users, separate from author |
| Lifetime | Short, throwaway | Years to decades |
| Documentation | Optional | Mandatory (SRS, design, user manual) |
| Testing | Author's intuition | Systematic, multi-level |
| Maintenance | Rare | 60–80% of total cost |
| Team size | One developer | Many developers, multiple roles |
| Failure cost | Low | Can be catastrophic (e.g. Therac-25, Ariane-5) |
Exam tip: When asked "Why is software engineering needed?" — the textbook answer is the software crisis plus the program-vs-software distinction. Quote at least three differences from the table above.
---
The Four Units At a Glance
| Unit | Theme | Key Topics | Hours (IPU) |
|---|---|---|---|
| I | Introduction, SDLC, Requirements | Process models, SRS, Agile, system modeling | 12 |
| II | Project Planning | Metrics, LOC, FP, COCOMO, risk management | 10 |
| III | Design, Quality, Implementation | Cohesion, coupling, SQA, TQM, reverse engineering | 10 |
| IV | Testing & Maintenance | Black/white-box, unit/integration/system testing, maintenance types | 12 |
---
Textbooks (IPU Prescribed)
- TB1. K.K. Aggarwal & Yogesh Singh, Software Engineering, 2nd Ed., New Age International — the IPU primary textbook
- TB2. Ian Sommerville, Software Engineering, 9th Edition, Pearson — the global standard
- RB1. R.S. Pressman, Software Engineering — A Practitioner's Approach, McGraw Hill — best for design
- RB2. Jibitesh Mishra & Ashok Mohanty, Software Engineering, Pearson
- RB3. James Peter & W. Pedrycz, Software Engineering: An Engineering Approach, Wiley
---
How to Get the Most From This Course
- Read in order — Unit I lays the foundation; Units II–IV all reference SDLC stages.
- Memorise the diagrams — Waterfall, Spiral, V-Model, COCOMO formula, cohesion/coupling hierarchies all show up directly in question papers.
- Match topics to PYQ patterns — every IPU paper since 2010 includes at least one question on COCOMO, one on cohesion/coupling, and one on black/white-box testing.
- Practice short numericals — LOC estimation, COCOMO calculation, cyclomatic complexity. They are 12.5-mark question favourites.
Let's begin.