SOFTWARE ENGINEERING

Module 1 — Introduction
Introduction to Software Engineering • Software Process Models • Agile Development

(10 Hours | 9 Lectures + 1 Tutorial)

Table of Contents
TOC \h \o "1-3"
1. Introduction to Software Engineering

1.1 Software and Its Characteristics

Software is a collection of computer programs, associated data, and documentation that together perform a set
of specified functions. Unlike a physical product, software is a logical rather than a physical system element — it
is engineered, not manufactured in the traditional sense.

Key characteristics that distinguish software from hardware

• Software is developed or engineered — it is not manufactured on an assembly line. Its quality depends on
design and development discipline, not on a fixed production process.
• Software does not wear out in the physical sense, but it does deteriorate logically — bugs surface, and
repeated changes (maintenance) degrade its structure over time. This is often shown as an "idealized" vs
"actual" failure curve, unlike hardware's classic bathtub curve.
• Most software is custom-built rather than assembled from existing, standardized components, although
the growing use of reusable components and libraries is changing this.
• Software is flexible and easy to change, which is both a strength (adaptability) and a weakness
(uncontrolled change leads to poor design over time).
• Software is intangible — it cannot be seen or touched, which makes progress and quality harder to
measure than for physical products.

1.2 Role of a Software Engineer

A software engineer applies a systematic, disciplined, and quantifiable approach to the development, operation,
and maintenance of software — this is, in fact, the IEEE definition of software engineering itself. The software
engineer's role spans the entire life of the product, not just writing code.

• Eliciting, analyzing, and documenting requirements from stakeholders.

• Designing system architecture and detailed component design.
• Writing, reviewing, and testing code to agreed quality standards.
• Estimating cost, effort, and schedule, and managing project risk.
• Maintaining and evolving the software after it is delivered.
• Ensuring the product is reliable, efficient, usable, and maintainable — balancing technical excellence with
business constraints.

1.3 Software Components

A software product is rarely just "code". It is made up of several components that together make it usable,
maintainable, and deployable:

Component Description

The set of instructions that implement the required

Program / Source Code
functionality.
 Component Description

Structures and files the program operates on, including

Data
configuration and databases.

Requirement specifications, design documents, user

Documentation
manuals, and technical documentation.

Instructions for installation, operation, and use of the

Procedures
software.

The means by which the user interacts with the

User Interface
underlying logic and data.

1.4 The Software Crisis

In the late 1960s, as computer power grew and organizations attempted to build increasingly large and complex
software systems, the industry ran into serious, widespread difficulties: projects overran their budgets and
schedules, delivered software was unreliable, and maintenance was extremely costly. This set of problems came
to be called the "software crisis", a term popularized at the 1968 NATO Software Engineering Conference — the
same conference at which the term "software engineering" was coined.
 Figure 1.1 — Principal causes of the software crisis

Manifestations of the crisis

• Projects running over budget and behind schedule.
• Software that was inefficient, unreliable, and difficult to maintain.
• Software that did not meet user requirements, or was hard to change when requirements changed.
• Inconsistent quality and a lack of professional standards or measurable processes.

Root causes
• Rapidly growing hardware capability created demand for ever-larger and more ambitious software,
outpacing the ability of ad-hoc programming practices to deliver it.
• Increasing size and complexity of software systems, which individual programmers using informal methods
could no longer manage reliably.
• Absence of systematic methods for specifying, designing, and validating software (the "code-and-fix"
approach).
• Poor project management, estimation, and lack of quality assurance practices.

1.5 Emergence of Software Engineering

Software engineering emerged as a discipline in direct response to the software crisis. The central idea was to
apply the same rigor, planning, and process discipline used in traditional (civil, mechanical) engineering to the
production of software — treating software development as an engineering activity rather than an individual,
artistic "programming" activity.

• 1968 — NATO Software Engineering Conference: the term "software engineering" is formally proposed,
deliberately provocative, to suggest software development needed the rigor of established engineering
disciplines.
• 1970s–1980s — Structured programming, structured analysis and design, and formal process models (such
as the waterfall model) emerge.
• 1980s–1990s — Software quality standards (e.g., ISO 9001), Capability Maturity Model (CMM), and CASE
tools mature to bring predictability to software projects.
• 2000s onward — Agile methods emerge as a lighter-weight, iterative response to the rigidity of
heavyweight, plan-driven processes.

1.6 Similarity and Differences of Software Engineering from Conventional

Engineering
Software engineering borrows its philosophy — systematic process, engineering discipline, quality focus — from
conventional (civil/mechanical) engineering, but software has unique properties that mean the two disciplines
differ in important ways.

Similarities Differences

Both follow a structured process: requirements → Software is intangible; conventional engineering

design → build → test → maintain. products are physical and visible.
 Similarities Differences

Software does not wear out physically; it "decays"

Both aim to produce a reliable, high-quality product
logically through repeated changes, unlike physical
within cost and schedule.
wear-and-tear.

Software is far easier and cheaper to change after

Both rely on models/blueprints before construction
"construction" (deployment) begins — change is a core
(design documents vs. engineering drawings).
feature, not an exception.

Software components are rarely

Both use standards, reviews, and testing/inspection to standardized/interchangeable across projects the way
assure quality. physical parts (bolts, beams) are, though reusable
libraries are narrowing this gap.

Failure modes differ — software failures are typically

Both require skilled professionals, tools, and project
due to design/logic faults, not physical fatigue or
management.
material failure.

1.7 Quality Attributes

Software quality is judged not just by whether the program runs, but by a broader set of attributes. These are
commonly grouped into attributes visible to the user during operation and attributes that matter to developers
who must change or transport the software.

Operational quality attributes (visible to the user)

Attribute Meaning

The software performs exactly the functions specified

Correctness
in the requirements.

The software performs its intended functions

Reliability
consistently, without failure, over time.

Optimal use of system resources such as memory, CPU

Efficiency
time, and bandwidth.

Ease of learning and using the software; quality of the

Usability
user interface.

Protection of the program and data from unauthorized

Integrity (Security)
access or corruption.

Transitional and maintenance quality attributes (important to developers)

Attribute Meaning

Ease with which software can be transferred to a

Portability
different hardware/software environment.

Interoperability Ability of the software to work with other systems.

Reusability Ease with which parts of the software can be reused in

Attribute Meaning

other applications.

Ease with which faults can be corrected and the

Maintainability
software can be enhanced.

Ease with which the software can be modified to meet

Flexibility
new requirements.

Ease with which the software can be tested to

Testability
demonstrate faults.

Remember
McCall's Quality Model groups these into three categories — Product Operation, Product Revision, and Product
Transition — and is a common way this topic is examined.
2. Software Process Models
A software process model (or Software Development Life Cycle — SDLC — model) is an abstract representation
of the software development process. It defines the order of activities such as requirements, design, coding,
testing, and maintenance, and describes how these activities relate to one another. Choosing an appropriate
model is one of the most important decisions in software project planning, since it affects cost, schedule risk,
and how well the final product matches customer needs.

2.1 Classical Waterfall Model

The classical waterfall model is the earliest and simplest process model, adapted from the
manufacturing/construction industry. It organizes development into a strict sequence of phases, where each
phase must be completed before the next begins — like water flowing downhill through a series of steps, never
flowing back.
 Figure 2.1 — Classical Waterfall Model

Phases
1. Requirements Analysis & Specification — understand and document what the customer needs, producing a
Software Requirements Specification (SRS).
2. Design — translate requirements into a software architecture and detailed component design.
3. Coding & Unit Testing — implement the design in a programming language and test individual modules.
4. Integration & System Testing — combine modules and test the complete system against requirements.
5. Maintenance — fix defects, adapt to new environments, and enhance the system after delivery.

Advantages Limitations

• Simple to understand and use; each phase has clear • No feedback path between phases — a mistake
deliverables and a review process. found late (e.g., in testing) is expensive to fix.
• Works well for projects with clear, stable • Working software is only available very late in the
requirements. life cycle.
• Encourages discipline through documentation. • Unrealistic for most real projects, where
requirements evolve.

2.2 Iterative Waterfall Model

The iterative waterfall model is a practical refinement of the classical model. It adds feedback loops between
adjacent (and sometimes non-adjacent) phases, so that errors detected in a later phase can be corrected by
revisiting an earlier phase, rather than being carried forward uncorrected.
 Figure 2.2 — Iterative Waterfall Model with feedback paths

This is the model most often used in practice when a waterfall-style process is chosen, because pure "no
feedback" development is rarely realistic. The trade-off is that phases still occur largely in sequence, so large
course-corrections remain costly.

2.3 Prototyping Model

The prototyping model is used when requirements are not clearly understood at the outset. The developer
builds a quick, working prototype — often with reduced functionality and quality — so that the customer can
experiment with it, clarify their needs, and provide feedback before the actual system is built.
 Figure 2.3 — Prototyping Model

Steps
1. Gather and refine requirements at a high level.
2. Create a quick design focused on aspects visible to the user (e.g., input/output formats).
3. Build a working prototype.
4. Customer evaluates the prototype and refines requirements.
5. Iterate/refine the prototype until the customer is satisfied.
6. Engineer the final product, often discarding (throwaway prototyping) or evolving (evolutionary
prototyping) the prototype.

Advantages Limitations

• Reduces risk of building the wrong system; clarifies • Customer may mistake the prototype for the final
ambiguous requirements. system and expect it delivered as-is.
• Improves user involvement and satisfaction. • Can encourage "quick and dirty" design decisions
• Useful when the user interface is critical. that are hard to remove later.
• Additional cost and time if the prototype is
discarded.

2.4 Evolutionary Model

The evolutionary (incremental) model builds the system in a series of increments ("builds"). The first increment
typically delivers the core functionality; each subsequent increment adds features until the full system is
complete. Each increment itself is developed using a mini waterfall-style cycle (analyze → design → code →
test).
 Figure 2.4 — Evolutionary (Incremental) Model

Advantages Limitations

• Delivers a usable product early and gets real • Requires an open/modular architecture planned up-
feedback from users on each increment. front to accommodate later increments.
• Lowers risk since problems can be caught and • Total cost can be harder to estimate than in a single-
corrected in early increments. pass model.
• Customer sees steady, visible progress. • Needs disciplined planning so increments integrate
cleanly.

2.5 Spiral Model

Proposed by Barry Boehm, the spiral model combines the iterative nature of prototyping with the controlled,
systematic aspects of the waterfall model, adding an explicit emphasis on risk analysis. The process is
represented as a spiral, where each loop ("cycle") around the spiral represents one phase of the process, and
the radius of the spiral represents the cumulative cost of the project.
 Figure 2.5 — Spiral Model (Boehm)

Four quadrants repeated in every cycle

• Determine objectives, alternatives, and constraints for that cycle.
• Evaluate alternatives; identify and resolve risks (often using prototyping).
• Develop and verify the next-level product (the deliverable for that cycle).
• Plan the next phase / cycle.

Advantages Limitations

• Strong, explicit focus on risk analysis and • Complex to manage; requires risk-assessment
management — well suited to large, high-risk expertise.
projects. • Can be costly, and is not well suited to small, low-risk
• Combines benefits of both iterative development projects.
and structured waterfall control. • Project may continue indefinitely without a clear
• Flexible — can accommodate changes at each cycle. termination criterion if not managed carefully.

2.6 RAD (Rapid Application Development) Model

RAD is a process model that emphasizes a very short development cycle, achieved through component-based
construction, extensive reuse, and multiple teams working on different parts of the system in parallel. It is best
suited to systems that can be modularized and that have well-understood requirements and a scope that fits a
short (typically 60–90 day) time-box.
 Figure 2.6 — RAD Model

Phases
• Business Modeling — model the information flow among business functions.
• Data Modeling — refine business information into data objects needed to support the business.
• Process Modeling — define processing to implement business functions, i.e., add/modify/delete a data
object.
• Application Generation — use automated tools/4GLs and component reuse to construct software rapidly.
• Testing and Turnover — since components and reused parts are pre-tested, this phase focuses on new
components and overall interfaces.

Advantages Limitations

• Very fast development cycle for suitable projects. • Requires modularized requirements and a system
• Heavy reuse reduces cost and improves reliability of that decomposes cleanly.
components. • Needs a strong, well-staffed team and committed
• Encourages customer involvement through visible, customer availability.
rapid progress. • Not suitable for projects that cannot be time-boxed
or lack reusable components.
3. Agile Development Model

3.1 Essential Idea Behind Agile Models

Agile methods emerged in the late 1990s/early 2000s as a reaction to the rigidity and heavy documentation
burden of plan-driven models like the waterfall model. The Agile Manifesto (2001) crystallized this philosophy
around four core values:

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a rigid plan.
In practice, agile development delivers working software in small, frequent increments ("sprints" or "iterations"),
with continuous customer feedback, close team collaboration, and the expectation that requirements will
change — and that the process should welcome, not resist, that change.

3.2 Agile versus Other (Plan-Driven) Models

Agile Models Plan-Driven Models (e.g., Waterfall)

Requirements are expected to evolve throughout the Requirements are fixed early and changes are formally
project. controlled.

Working software is delivered every few weeks (each Working software is typically delivered only near the
sprint). end.

Documentation is kept minimal — "just enough" to Documentation is extensive and produced at each
support the team. phase.

Planning is adaptive and revisited every iteration. Planning is done comprehensively up-front.

Customer/product owner is closely and continuously Customer involvement is concentrated at the

involved. requirements and acceptance stages.

Best suited to large, well-understood projects with

Best suited to small-to-mid teams and projects with
stable requirements or regulatory/contractual
uncertain/evolving requirements.
constraints.

3.3 Extreme Programming (XP)

Extreme Programming, proposed by Kent Beck, is one of the most well-known agile methods. It takes
established good engineering practices — code review, testing, simplicity, design — to "extreme" levels: code is
reviewed continuously (via pair programming), testing is continuous (test-driven development), and design is
kept as simple as possible and improved constantly (refactoring).
 Figure 3.1 — Core practices of Extreme Programming

Core practices
• Pair Programming — two developers work together at one workstation, one writing code and the other
reviewing each line as it is typed.
• Test-Driven Development (TDD) — automated unit tests are written before the code that makes them pass.
• Continuous Integration — code changes are integrated and tested frequently (often multiple times a day)
to catch integration issues early.
• Refactoring — the internal structure of the code is continuously improved without changing its external
behavior.
• Small Releases — a simple version of the system is put into production early, with new versions released
frequently.
• Collective Code Ownership — any developer can change any part of the code at any time, and the whole
team is responsible for it.
• Simple Design — the system is kept as simple as possible for its current requirements — "do the simplest
thing that could possibly work."
• On-site Customer — a customer representative is available to the team full-time to answer questions and
set priorities.

3.4 Scrum
Scrum is the most widely used agile framework. It organizes work into fixed-length iterations called sprints
(commonly 2–4 weeks), during which a cross-functional team delivers a potentially shippable increment of the
product.
 Figure 3.2 — The Scrum Framework

Roles
• Product Owner — owns and prioritizes the Product Backlog, representing stakeholder/customer interests.
• Scrum Master — facilitates the process, removes impediments, and shields the team from outside
disruption.
• Development Team — a small, self-organizing, cross-functional group that builds the increment.

Artifacts
• Product Backlog — the ordered list of everything that might be needed in the product.
• Sprint Backlog — the subset of backlog items selected for the current sprint, plus a plan for delivering
them.
• Increment — the sum of all completed backlog items at the end of a sprint, meeting the team's "Definition
of Done".

Events / Ceremonies
• Sprint Planning — the team selects backlog items and plans the work for the upcoming sprint.
• Daily Scrum (Stand-up) — a short (~15 min) daily sync on progress and blockers.
• Sprint Review — the team demonstrates the increment to stakeholders and gathers feedback.
• Sprint Retrospective — the team reflects on the sprint just completed and identifies process
improvements.

Exam tip
A common point of confusion: Scrum is a management/process framework (roles, events, artifacts) — it does not
prescribe specific engineering practices. XP, by contrast, is largely a set of engineering practices (TDD, pair
programming, refactoring). Many real teams combine "Scrum for process" with "XP practices for engineering".

3.5 Summary Comparison of Process Models

Model Best Suited For Key Idea

Waterfall (Classical) Small, well-understood projects with stable Strict sequential phases, no feedback.
requirements.

Waterfall (Iterative) Similar, where limited rework across phases is Adds feedback loops between phases.
expected.

Prototyping Unclear or evolving user requirements, UI- Build-evaluate-refine a working mock-up

heavy systems. first.

Evolutionary / Systems that can be delivered in usable Deliver core system first, add features in
Incremental functional chunks. builds.

Spiral Large, complex, high-risk projects. Repeated cycles driven by explicit risk
analysis.

RAD Modular systems with a tight schedule and Parallel, component-based, time-boxed
available components. construction.
 Model Best Suited For Key Idea

Agile (XP / Scrum) Projects with evolving requirements and need Short iterations, continuous customer
for fast feedback. collaboration.

Tutorial I — Discussion of Module 1

The tutorial session (1 lecture) is used to consolidate Module 1 through discussion and problem-solving.
Suggested discussion questions:

1. Explain, with examples, why software is said to "deteriorate" rather than "wear out".
2. What were the main causes of the software crisis, and how did the emergence of software engineering
address them?
3. Compare the classical and iterative waterfall models. Why is the iterative version used more often in
practice?
4. For a given case study (e.g., a college ERP system, a food-delivery app), which process model would you
recommend, and why?
5. Differentiate Scrum and Extreme Programming — is it correct to say a team is either "doing Scrum" or
"doing XP", but never both?
6. Map each quality attribute (Section 1.7) to a real complaint a user or developer might make about poor-
quality software.