1.1 Introduction to Software Engineering

Definition

IEEE 610.12-1990 definition (the IPU textbook answer): "Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software — that is, the application of engineering to software."

Fritz Bauer, NATO 1968 (the historical answer): "The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines."

Both definitions emphasise three things:

1. Engineering principles — not ad-hoc, not artistic; principled, repeatable.
2. Economy — software must be built within a budget.
3. The whole lifecycle — not just coding, but operation and maintenance.

---

Characteristics of Software

Software differs from physical products in several fundamental ways. Understanding these characteristics explains why "software engineering" exists as a separate discipline at all.

The Software Failure Curve

Hardware follows a classic bathtub curve: high failure rate at first (infant mortality), low failure rate in the middle, rising failure rate at end-of-life (wear-out). Software is different:

Failure rate
  ^
  |  *
  |   *
  |    *  ____________  bug fixes introduce new bugs
  |     *
  |      *_____________  ideal curve (no changes)
  |
  +---------------------> Time

After initial bug-fixing, the rate should decline and stay flat — but every "improvement" introduces side-effects, so real software shows a rising staircase. This is why maintenance dominates total cost (often 60–80%).

---

Software Components

A complete software product is more than source code. It is a deliverable bundle including:

---

Software Categories (Sommerville)

Sommerville classifies software into seven application domains. The category drives the engineering approach.

---

Software Crisis (Mandatory IPU topic)

The software crisis is the term coined at the NATO Software Engineering Conference (Garmisch, Germany, 1968) to describe the difficulty of writing useful and efficient computer programs in the required time. Key symptoms:

Exam tip: When asked about the software crisis, structure your answer as: (1) Year and venue of the term's coinage; (2) at least three symptoms with examples; (3) Connection to software engineering as the discipline that emerged in response.

---

Software Myths (Pressman)

Pressman documents three categories of myth that persistently mislead software projects. Each appears on IPU papers.

1. Management myths

Three managerial illusions consistently sabotage software projects. The first is that "having books of standards is enough." Standards documents on a shelf accomplish nothing — they must be followed, audited, and enforced, ideally via reviews and tooling. The second is that "state-of-the-art tools guarantee success." Tools are a force multiplier on a competent team; they cannot save an incompetent one. A great IDE in the wrong hands just lets you write bad code faster. The third — and most enduring — is that "if we're behind, we should add more programmers." This belief was demolished by Brooks's Law: adding manpower to a late software project makes it later, because new joiners need training, the communication graph grows as n(n−1)/2, and tasks have an irreducible sequential nature.

2. Customer myths

Customers carry two related illusions. The first is that "a general goal statement is enough to start — we'll fill in details later." In practice, ambiguous requirements are the single biggest cause of project failure, which is why an SRS is non-negotiable, not optional. The second is that "requirements change is easy because software is flexible." Software is flexible in theory, but Boehm's cost-of-change curve shows that fixing a requirement after coding has begun costs 5–10× more than fixing it during requirements; after release, 100–200× more. Flexibility is real but expensive.

3. Practitioner (developer) myths

Developers fall into three myths of their own. The first is "once the program works, our job is done." In reality, 60–80% of the total cost of a typical system is spent after first delivery — on bug-fixes, enhancements, environment changes, and adaptive maintenance. The second is "quality cannot be assessed until the program is running." Decades of data on Fagan inspections and modern code reviews show that formal review at the design or code stage finds defects earlier and far more cheaply than letting them survive into testing or production. The third is "the only deliverable is the working program." A working program with no SRS, no design document, no test plan, and no user manual is a future maintenance disaster — and an incomplete deliverable by any professional engineering standard.

---

The Engineering vs Art Continuum

Software is often described as part-art, part-science. Engineering pulls it toward science:

Art ←──────────────────────────→ Engineering
 |                                     |
 individual creativity         standardised process
 personal style                measurable outcomes
 talent-dependent              repeatable by trained teams

A senior developer working alone may build a clever 1,000-line tool relying on personal taste. A team building a 100,000-line product must lean toward the engineering end — using documented processes, peer review, version control, and structured testing — or the system collapses under its own complexity.

---

Key Terms — Lesson 1.1

These terms are the vocabulary every later lesson assumes. Memorise the definitions; they appear by name in nearly every Unit I PYQ.

Software — A set of computer programs, associated data, and documentation that together provide a service or solve a problem. The IEEE-754 textbook definition deliberately includes the data and the documentation: a working executable with no SRS, no user manual, and no test data is not a complete software product.

Software Engineering — The systematic, disciplined, quantifiable application of engineering principles to the development, operation, and maintenance of software (IEEE 610.12-1990). The word "engineering" is doing the heavy lifting — it implies repeatable processes, measurable quality, peer review, professional accountability, and a whole-lifecycle perspective rather than only coding.

Programming vs Software Engineering — Programming is the act of writing code that runs. Software Engineering is the broader discipline that surrounds programming with requirements analysis, design, project management, quality assurance, testing, configuration management, and maintenance. Every software engineer must be a programmer; not every programmer is a software engineer.

SDLC (Software Development Life Cycle) — The end-to-end sequence of phases through which software is conceived, built, deployed, operated, and eventually retired. Classic SDLC phases: feasibility → requirements → design → implementation → testing → deployment → maintenance. Different process models (Waterfall, Iterative, Agile, Spiral) order and repeat these phases differently.

Process Model / Software Process — A specific arrangement of SDLC activities — sequence, iterations, deliverables, decision gates. Waterfall, Prototyping, Spiral, RAD, V-Model, and Agile (Scrum, XP, Kanban) are all software process models. The choice depends on requirement clarity, risk tolerance, team experience, and project size.

Software Crisis — The term coined at the NATO Software Engineering Conference at Garmisch, Germany, in 1968 to describe the chronic difficulty of building large software systems on time, on budget, and to specification. Symptoms include schedule overruns, cost overruns, buggy releases, unmaintainable code, and projects that deliver the wrong product. Software engineering as a discipline was born to address this crisis.

Brooks's Law — "Adding manpower to a late software project makes it later." Frederick Brooks, manager of IBM OS/360, observed that new team members need training (consuming the time of existing experts), that the communication graph grows quadratically (n(n−1)/2 links), and that some tasks have an irreducible sequential nature. The implication: schedule recovery cannot be bought by hiring sprees.

Mythical Man-Month — Brooks's metaphor (from his 1975 book): "Nine women cannot produce a baby in one month." Effort (person-months) is not interchangeable with duration (months) when work has dependencies. The "man-month" is a useful accounting unit but a misleading planning unit.

Boehm's Cost-of-Change Curve — Barry Boehm's empirical finding that the cost of fixing a defect rises exponentially with how late in the lifecycle it is found: ~1× in requirements, ~5× in design, ~10× in coding, ~20–50× in testing, 100–200× in production. The single strongest economic argument for early reviews, prototyping, and rigorous requirements engineering.

Software Maintenance — All activity that takes place after first delivery: fixing defects (corrective maintenance), adapting to environment changes such as new OS or hardware (adaptive), adding new functionality (perfective), and improving non-functional qualities like performance and security (preventive). Maintenance accounts for 60–80% of the total lifecycle cost of a typical system.

Software Component / Deliverable — Anything that is part of the delivered package: source code, executables, SRS (Software Requirements Specification), design documents, user manuals, API documentation, test plans, test cases, test data, configuration files, deployment scripts, and operating procedures. A "deliverable" is anything a stakeholder can demand and inspect.

Software Quality Attributes — The non-functional properties by which a software product is judged: correctness (does what is specified), reliability (operates without failure for an expected period), efficiency (uses resources well), usability (easy for users), maintainability (easy to change safely), portability (runs in different environments), reusability (can be incorporated into new systems), and interoperability (works with other systems). Each can be measured by specific metrics.

Fagan Inspection / Formal Review — A structured, peer-led examination of a software artefact (SRS, design document, code) by trained reviewers using a checklist. Pioneered by Michael Fagan at IBM in the 1970s. Inspections find defects 4–10× more cheaply than the same defects would cost to fix if found in testing — one of the best-documented economic levers in software engineering.

Software Myth — A persistent false belief about software development held by managers, customers, or developers. Pressman classifies myths into three groups (management, customer, practitioner) — each of which leads to predictable project failures unless explicitly challenged.

System Software vs Application Software — Two broad categories of software. System software (operating systems, compilers, device drivers, utilities) serves other software and the hardware; performance, low-level access, and reliability dominate its engineering concerns. Application software (banking systems, ERP, browsers, mobile apps) serves end users to accomplish a business or personal task; domain rules, data integrity, and usability dominate its engineering concerns.

Embedded Software — Software that runs inside a hardware product — pacemakers, automotive ECUs, microwave ovens, satellites, industrial controllers. Embedded software typically operates under tight real-time, memory, power, and safety constraints, and a defect can cost lives.

IEEE 610.12 — The IEEE Standard Glossary of Software Engineering Terminology (1990). The source of the formal definitions of "software," "software engineering," "requirement," "design," and most other foundational terms. IPU exam answers that cite IEEE 610.12 carry a definitional weight that paraphrased answers do not.

---

Study deep: foundational ideas

1. Brooks's Mythical Man-Month (1975): Frederick Brooks, manager of OS/360, observed that women cannot produce a baby in one month by combining nine women. The same intuition applies to software: tasks have an irreducible sequential nature. Adding people to a late project costs more in onboarding and communication than the new bodies add. The communication overhead grows as n(n−1)/2 — for 10 people that's 45 communication links.

1. Boehm's Cost-of-Change curve (1981): Barry Boehm empirically showed that a defect found in requirements costs ~1× to fix; in design ~5×; in coding ~10×; in testing ~20–50×; in production 100–200×. This is the single most important argument for early reviews and prototyping.

1. The "engineering" word matters: Calling software development "engineering" implies it should be subject to the same rigour as civil or aeronautical engineering — peer review, sign-off, professional liability. The field has not fully reached that standard (no formal licensure in most countries), but the term sets the aspirational goal.

1. Software engineering is fundamentally a human activity. Tools, processes and models address symptoms of complexity. The root cause is that software systems are products of communication between humans (developers ↔ developers, developers ↔ users, developers ↔ future maintainers). Every technique in this course — SRS, design documents, code reviews, change control — is ultimately a communication tool.

PYQ pattern: "Define software engineering. What are the characteristics of a good software product?" — Answer using IEEE definition + at least 5 characteristics (correctness, reliability, efficiency, usability, maintainability, portability, reusability).