Software

Engineering
CHAPTER – 1:
INTRODUCTION

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 1
Outline
▪ Two Orthogonal view of software

▪ The Software Engineering Evolution

▪ Shifting the Paradigm

▪ Software Engineering Problems

▪ Software Engineering Vs Other Engineering

▪ Software Engineering Definition

▪ Software Engineering Activities

▪ Software development process models

▪ Object oriented system development methodology

▪ Why an object oriented

▪ Overview of the unified approach.

▪ An object-oriented philosophy

▪ Basic concepts of an object

▪ Attributes of an object, its state and properties

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 2
Two Orthogonal View of
Software Development
Traditional Technique –focuses on functions, what it is doing
▪ Software as a collection of programs(functions) and isolated data

▪ Program = Algorithms + Data Structures

▪ A software system is a set of mechanisms for preforming certain action on

certain data

▪Object Oriented methodologies –focuses on objects that combines

data and functionality
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 3
Two Orthogonal View of
Software Development

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 4
Software Engineering Evolution
▪The term software engineering was coined in 1968 as a response to the desolate state of the
art of developing quality software on time and within budget.
▪Software developers were NOT ABLE TO set concrete objectives, NOT ABLE TO predict
the resources necessary to attain those objectives, and NOT ABLE TO manage the
customers’ expectations
▪Software engineering as a concept was created at the end of the 1960s. The term was first
used by Margaret Hamilton -- director of the Software Engineering Division of the MIT
Instrumentation Lab. Margaret was leading the effort to develop the flight-control software
for the Apollo space program.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 5
 Software Engineering Evolution
▪During the same period, the NATO convened a conference in Garmisch Partenkirchen, Germany, to try
to define the term. This was the first software engineering conference.

▪A conclusion of the conferees was that software engineering should use the philosophies and
paradigms of established engineering disciplines to solve what they termed the software crisis ,
namely, that the quality of software generally was unacceptably low and that deadlines and
budgets were not being met.

▪The earliest computers had been programmed by flipping switches, or even hard-coded as part of
their design. This was slow and inflexible, and the idea of the “stored program” was born. This is the
idea that, for the first time, made a clear distinction between software and hardware.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 6
Software Engineering Evolution
Shifting the Paradigm
▪The idea of paradigm shift was created by physicist Thomas Kuhn.
▪Most learning is a kind of accretion. We build up layers of understanding, with
each layer foundationally under-pinned by the previous one.
▪However, not all learning is like that. Sometimes we fundamentally change our
perspective on something, and that allows us to learn new things, but that also
means we must discard what went before.
▪In the 18th century, reputable biologists believed that some animals
spontaneously generated themselves. Darwin came along in the middle of the
19th century and described the process of natural selection, and this overturned
the idea of spontaneous generation completely.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 7
Software Engineering Evolution
Shifting the Paradigm
▪This change in thinking ultimately led to our modern understanding of genetics and our ability
to understand life at a more fundamental level, create technologies that allow us to manipulate
these genes, and create COVID-19 vaccines and genetic therapies.
▪Similarly, Kepler, Copernicus, and Galileo challenged the then conventional wisdom that Earth
was at the center of the universe. They instead proposed a heliocentric model for the solar
system. This ultimately led to Newton creating laws of gravitation and Einstein creating general
relativity, and it allowed us to travel in space and create technologies like GPS.
▪The idea of paradigm shift implicitly includes the idea that when we make such a shift, we will, as
part of that process, discard some other ideas that we now know are no longer correct.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 8
Software Engineering Evolution
Shifting the Paradigm
▪The implications of treating software development as a genuine engineering
discipline, rooted in the philosophy of the scientific method and scientific
rationalism, are profound.
▪It is profound not only in its, impact and effectiveness, but also in the essential need
to discard the ideas that this approach supersedes. This gives us an approach to
learning more effectively and discarding bad ideas more efficiently.
▪The paradigm shift (engineering thinking to software development) in thinking
differently about what it is that we do, and how we do it, when we create software
should help us make SW development simpler, more reliable, and more efficient.
▪This is not about more bureaucracy; it is about enhancing our ability to create
high-quality software more sustainably and more reliably.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 9
Software Engineering: Problems
▪The problem of building and delivering complex software systems on time has been
actively investigated and researched.
▪Everything has been blamed, from the customer (“What do you mean I can’t get the
moon for $50?”) to the “soft” in software (“If I could add that one last feature ...”).
What is the problem?
▪Complexity and change: Useful software systems are complex. To remain useful
they need to evolve with the end users’ need and the target environment.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 10
Software Engineering: Problems
▪Software systems are complex creations: They perform many functions; they are built to achieve
many different, and often conflicting, objectives;
▪ they comprise many complex and custom made components;

▪ many participants, from different disciplines, take part in the development of these components;

▪ the development process and the software life cycle often spans many years;

▪ finally, complex systems are difficult to understand completely by any single person.

▪ Many systems are so hard to understand, even during their development phase, that they are never

finished: These are called vaporware.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 11
Software Engineering:
Problems: Constant Change
▪Software development projects are subject to constant change.
▪Because requirements are complex, they need to be updated when errors are
discovered and when the developers have a better understanding of the
application.
▪If the project lasts many years, the staff turn-out is high, requiring constant training.
The time between technological changes is often shorter than the duration of
the project.
▪The widespread assumption of a software project manager that all changes have
been dealt with and that the requirements can be frozen lead to an irrelevant
system being deployed.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 12
Software Engineering Vs Other
Engineering
“In other disciplines, engineering simply means the “stuff that works.” It is the
process and practice that you apply to increase your chances of doing a good
job.”
▪Engineering—The Practical Application of Science
▪Engineering is the application of an empirical, scientific approach to finding
efficient, economic solutions to practical problems.
▪Engineering solutions are not abstract ivory-tower things; they are practical and
applicable to the problem and the context.
▪They are efficient, and they are created with an understanding of, and constrained by,
the economics of the situation.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 13
Software Engineering Vs Other
Engineering
▪Engineering is about applying scientific rationalism to solving problems.. It is the
processes, tools, and techniques. It is the ideas, philosophy, and approach that
together make up an engineering discipline.

▪An engineer is able to build a high-quality product using off-the-shelf components

and integrating them under time and budget constraints.

▪Engineering is more pragmatic: dealing with things sensibly and realistically in a

way that is based on practical rather than theoretical considerations.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 14
Software Engineering Vs Other
Engineering
▪Software development is a process of discovery and exploration;
therefore, to succeed at it, software engineers need to become experts at
learning.

▪Humanity’s best approach to learning is science, so we need to adopt the

techniques and strategies of science and apply them to our problems. This is often
misunderstood to mean that we need to become physicists measuring things to
unreasonable, in the context of software, levels of precision.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 15
Software Engineering:
Definitions
▪Software engineering is about production of fault-free software, delivered on time and within budget,
that satisfies the client’s needs.
▪Software Engineering is the construction of quality software with in the context of constant change.
▪Software engineering is a detailed study of engineering to the design, development and maintenance
of software.
▪Software engineering is To organize and control software development process and produce a well-
structured, accurate and useful software solution.
▪Software is built to meet a certain functional goal and satisfy certain qualities. The fundamental
assumptions of software engineering are: Good processes lead to good software and Good processes
reduce risk
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 16
 Software Engineering Activity:
Modeling
▪The purpose of sciences is to describe and understand complex systems such as: system of atoms, solar
systems or society of human beings. Traditionally, we have:
▪ Natural science: physics, biology, chemistry, …
▪ Social science: Sociology , psychology, …
▪ We have another system: Artificial system: space shuttle, airline reservation systems, and stock trading
systems
▪Herbert Simon coined the term sciences of the artificial to describe the sciences that deal with artificial
systems
▪ Computer science, for example, the science dealing with understanding computer systems, is a child of this
century.

▪One of the basic methods of science is modeling

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 17
Software Engineering Activity:
Modeling
▪A Model is an abstract representation of a system that enables us to answer
questions about the system.
▪Models are useful when dealing with systems that are:
▪ too large, too small,
▪ too complicated, or
▪ too expensive to experience firsthand.
▪Models also allow to visualize and understand systems that either no longer
exist or that are only claimed to exist.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 18
Software Engineering Activity:
Modeling
▪ Dinosaur: From the bone fragments, Biologists reconstruct a model of the animal,
following rules of anatomy. The more bones they find, the clearer their idea of how
the pieces fit together and the higher the confidence that their model matches the
original dinosaur. If they find a sufficient number of bones, teeth, and claws, they can
almost be sure that their model reflects reality accurately, and they can guess the
missing parts. Legs, for example, usually come in pairs. If the left leg is found, but the
right leg is missing, the fossil biologists have a fairly good idea what the missing leg
should look like and where it fits in the model. This is an example of a model of a
system that no longer exists.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 19
Software Engineering Activity:
Modeling
▪ Today’s high-energy physicists are in a similar position to that of a fossil
biologist who has found most of the bones. Physicists are building a model of
matter and energy and how they fit together at the most basic subatomic
level. Their tool is the high-energy particle accelerator. Many years of
experiments with particle accelerators have given high-energy physicists
enough confidence that their models reflect reality and that the remaining
pieces that are not yet found will fit into the so-called standard model. This is
an example of a model for a system that is claimed to exist.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 20
Software Engineering Activity:
Modeling
▪Both system modelers, fossil biologists and high-energy physicists, deal with
two types of entities:
▪ The real-world system, observed in terms of a set of phenomena, and

▪ The problem domain model, represented as a set of interdependent concepts.

▪The system in the real world is a dinosaur or subatomic particles.
▪The problem domain model is a description of those aspects of the real-
world system that are relevant to the problem under consideration.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 21
Software Engineering Activity:
Modeling
▪Software engineers face similar challenges as fossil biologists and high-energy physicists.
▪First, software engineers need to understand the environment in which the system is to
operate.
▪For a train traffic control system, software engineers need to know train signaling procedures.
▪For a stock trading system, software engineers need to know trading rules.
▪ Software engineers do not need to become a fully certified train dispatcher or a stock
broker; they only need to learn the problem domain concepts that are relevant to the
system. In other terms, they need to build a model of the problem domain.
▪Second, software engineers need to understand the systems they could build, to evaluate
different solutions and trade-offs.
▪ Most systems are too complex to be understood by any one person and are expensive to
build.
▪ To address these challenges, software engineers describe important aspects of the alternative
systems they investigate. In other terms, they need to build a model of the solution domain.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 22
 Software Engineering Activity:
Problem Solving
▪Engineering is a problem-solving activity. Engineers search for an appropriate solution, often by
trial and error, evaluating alternatives empirically, with limited resources and incomplete knowledge. In
its simplest form, the engineering method includes five steps:

1. Formulate the problem

2. Analyze the problem

3. Search for solutions

4. Decide on the appropriate solution

5. Specify the solution

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 23
 Software Engineering Activity:
Problem Solving
▪Software engineering is an engineering activity. It requires experimentation, the reuse of pattern solutions,
and the incremental evolution of the system toward a solution that is acceptable to the client.
▪Software development typically includes five development activities: requirements elicitation, analysis, system
design, object design, and implementation.
▪During requirements elicitation and analysis, software engineers formulate the problem with the client and
build the problem domain model. Requirements elicitation and analysis correspond to steps 1 and 2 of the
engineering method.
▪During system design, software engineers analyze the problem, break it down into smaller pieces, and select
general strategies for designing the system. During object design, they select detail solutions for each piece and
decide on the most appropriate solution. System design and object design result in the solution domain
model. System and object design correspond to steps 3 and 4 of the engineering method.
▪During implementation, software engineers realize the system by translating the solution domain model into
an executable representation. Implementation corresponds to step 5 of the engineering method.
▪What makes software engineering different from problem solving in other
sciences is that change occurs while the problem is being solved.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 24
 Software Engineering Activity:
Knowledge Acquisition
▪Linear acquisition model for knowledge or also called “the bucket theory of the mind”
is a problem
▪Knowledge acquisition is a nonlinear process. The addition of a new piece of
information may invalidate all the knowledge we have acquired for the
understanding of a system.
▪Even if we had already documented this understanding in documents and code (“The
system is 90% coded, we will be done next week”), we must be mentally prepared to
start from scratch. This had important implications on the set of activities and their
interactions we define to develop the software system.
▪The equivalent of the bucket theory of the mind is the linear waterfall model for
software development, in which all steps of the engineering method are accomplished
sequentially.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 25
 Software Engineering Activity:
Knowledge Acquisition
▪There are several software processes that deal with this problem by avoiding the linear
dependencies inherent in the waterfall model.
▪Risk-based development attempts to anticipate surprises late in a project by identifying the high-
risk components.
▪Issue-based development attempts to remove the linearity altogether. Any development activity,
be it analysis, system design, object design, implementation, testing, or delivery, can influence any
other activity.
▪In issue-based development, all these activities are executed in parallel. The difficulty with
nonlinear development models, however, is that they are hard to manage.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 26
 Software Engineering Activity:
Rationale Management
▪When describing the acquisition or evolution of knowledge, we are even less well equipped than
when describing the knowledge of an existing system.
▪In the field of mathematics and many other once deduction have been stated, for change to
happen is very rare. “Once the axioms and the rules of deduction have been stated, the proof is
timeless”
▪For software engineers, the situation is very different. Assumptions that developers make about
a system change constantly.
▪ Even though the application domain models eventually stabilize once developers acquire an
adequate understanding of the problem, the solution domain models are in constant flux.
▪ Design and implementation faults discovered during testing and usability problems
discovered during user evaluation trigger changes to the solution models.
▪ Changes can also be caused by new technology. The availability of a long-life battery and of
high-bandwidth wireless communication, for example, can trigger revisions to the concept of a
portable data terminal.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 27
Software Engineering Activity:
Rationale Management
▪Change introduced by new technology often allows the formulation of new
functional or nonfunctional requirements.
▪A typical task to be done by software engineers is to change a currently
operational software system to incorporate this new enabling technology.
▪To change the system, it is not enough to understand its current components
and behavior. It is also necessary to capture and understand the context in which
each design decision was made. This additional knowledge is called the rationale
of the system.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 28
 Software Engineering Activity:
Rationale Management
▪Capturing and accessing the rationale of a system is nontrivial.
▪First, for every decision made, several alternatives may have been considered, evaluated, and
argued. Consequently, rationale represents a much larger amount of information than the
solution models do.
▪Second, rationale information is often not explicit. Developers make many decisions based on
their experience and their intuition, without explicitly evaluating different alternatives. When
asked to explain a decision, developers may have to spend a substantial amount of time
recovering its rationale.
▪In order to deal with changing systems, however, software engineers must address the
challenges of capturing and accessing rationale.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 29
Software Engineering: Concepts
▪Project–set of activities to develop a software system
▪Activity –a phase in which related tasks are carried out (Requirements
Elicitation, Analysis, Object Design, System Design, Implementation and
Validation/testing)

▪Task –effort that uses resources AND produces Work Product

▪Resources–time, equipment, people (participants)

▪Work Product–a model, system, or artifact

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 30
Software Engineering: Concepts
Project

*
Activity

Is produced by consumes
*
WorkProduct * Task * Resources

System Participant

Model Time
Document Equipment

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 31
Software Engineering:
Concepts: System and Roles
▪System
▪ A collection of interconnected parts

▪Roles
▪ Client – high level requirements, scope, deadline, budget, quality criteria

▪ User – domain knowledge

▪ Manager – progress evaluation, resource managing

▪ Developers – construction (analyzing, designing, implementing, and testing)

▪ Technical writer - documentation

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 32
Software Process Model
▪The earlier approach (build and Fix approach)
▪Product is constructed without specification or any attempt at design.
▪Developers simply build a product that is reworked as many times as
necessary to satisfy the client.
▪This model may work for small projects but is totally unsatisfactory for
products of any reasonable size.
▪Maintenance is high.
▪Source of difficulties and deficiencies
▪impossible to predict
▪impossible to manage
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 33
Software Process Model: Why
Models are needed?
▪Symptoms of inadequacy: the software crisis
▪scheduled time and cost exceeded
▪user expectations not met
▪poor quality

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 34
Software Process Model
▪Software development life cycle (SDLC) or Software process model show the ways
to navigate through the complex and demanding process of software building.
▪Process models prescribe a distinct and structured set of activities, actions, tasks,
milestones, and work products required to design and build high quality software.
▪Software models provide stability, control, and organization to a process that if not
managed can easily get out of control
▪A project’s quality, timeframes, budget, and ability to meet the stakeholders’
expectations largely depend on the chosen model.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 35
Software Process Model
▪All models follow a Series of steps unique to its type to ensure success in the
process of software development
▪Today, there are more than 50 recognized SDLC models in use. None of
them are perfect, and each of them advantages and disadvantages
▪The models can be structured into several groups depending on how they
approach workflow organization – linearly or iteratively – and what kind of
relationships are established between the development team and the
customer.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 36
Software Process Model

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 37
Software Process Model
▪The types in the lower quadrants of the chart take the sequential flow. They are
easy to implement, use and manage.
▪As you move higher, the process becomes less rigid and offers more flexibility
when it comes to changes in the requirements for future software.
▪The models on the left side of the chart imply low customer involvement; as you
move toward the right side, the models grow more ‘cooperative’ and include
customers into different stages of software development life cycle more
intensively.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 38
Software Process Model:
Waterfall Model

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 39
Software Process Model:
Waterfall Model
▪Through all development stages (analysis, design, coding, testing, deployment), the
process moves in a cascade mode.
▪Each stage has concrete deliverables and is strictly documented.
▪OUTPUT of one phase becomes the INPUT of the next phase.
▪The next stage cannot start before the previous one is fully completed (no going
back to previously completed phases, no skip or on overlap of phases).
▪No ability to see and try software until the last development stage is finished (all or
nothing delivery), which results in high project risks and unpredictable project results.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 40
Software Process Model:
Waterfall Model: Applicability
▪Stable Requirements: for projects which are small or mid-sized with clearly defined and
unchanging requirements (small company website development).
▪Projects with the need for stricter control, predictable budget and timelines (e.g.,
governmental projects).
▪Compliance: It ensured strict adherence to regulations/rules and standards, especially
in safety-critical and financial systems or healthcare projects.
▪Thorough Documentation: Waterfall emphasized detailed documentation, which was
crucial for industries like defense, healthcare, and banking.
▪Projects where a well-known technology stack and tools are used
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 41
Software Process Model:
Waterfall Model
▪Common outputs of a waterfall: SRS, project plan, design docs, test plan and reports,
final code, supporting docs
▪Advantages:
▪ Natural approach for problem solving
▪ Conceptually simple and understandable, cleanly divides the problem into distinct
independent phases
▪ Easy to administer in a contractual setup – each phase is a milestone
▪Problems:
1. Real projects are rarely to follow the sequential model.
2. Difficult for the customer to state all the requirement explicitly.
3. Assumes patience from customer - working version of program will not be
available until programs not getting change fully.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 42
 Software Process Model:
Waterfall Model: Examples
1. Embedded Systems:
1. NASA Projects: Early space programs, such as the software for Apollo spacecraft and space probes, were
developed using the Waterfall Model because of the strict requirement specifications and zero
tolerance for errors.
2. Avionics Systems: Flight control software for aircraft often used Waterfall to ensure reliability and
compliance with safety standards.
2. Banking Software:
1. ATM Software: Many early banking systems and ATM software were developed using Waterfall due to the
need for thorough documentation and structured phases.
2. Payment Processing Systems: Systems like SWIFT or VISA's early transaction systems followed Waterfall to
ensure clear requirements and compliance with financial regulations.
3. Government and Defense Projects:
1. Military Systems: Projects like radar systems, missile control systems, and defense communication
systems often used Waterfall because of rigid requirements and extensive documentation needs.
2. Healthcare Software: Early hospital management systems and medical imaging software were
developed under Waterfall due to critical safety and regulatory standards
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 43
 Software Process Model:
Waterfall Model: Examples
4. Enterprise Resource Planning (ERP):
1. Early versions of ERP software, like SAP R/3, were developed using Waterfall because it required detailed

specifications and planning for organizational needs.

5. Telecommunications Systems: Software for early telephone switching systems, like Alcatel-Lucent's
switching systems, followed the Waterfall to ensure smooth operation and reliability.

6. Legacy Software:
1. Operating Systems: Early versions of operating systems like UNIX and some versions of Windows (e.g., Windows
XP) used Waterfall during development due to the need for a clear design and implementation process.

2. Database Systems: Early versions of database systems like Oracle were developed with Waterfall to meet specific

business and performance requirements.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 44
Software Process Model:
Incremental Model

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 45
Software Process Model:
Incremental Model
▪The Incremental model is split into several iterations (“Lego-style”)
▪The Model consists of iterative and incremental development stages. The Model is
comprised of several mini waterfall cycles.
▪We collect the customer’s requirements, now instead of making the entire software at
once, we first take some requirements and based on them create a module or
function of the software and deliver it to the customer. Then we take some more
requirements and based on them add another module to that software with no or
little change in earlier to the previous modules, REPEAT till the system is complete.
▪The development process can go either sequentially or in parallel.
▪Parallel development adds to the speed of delivery
▪The Model allows software developers to take advantage of learnings and insights
gleaned from earlier development stages.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 46
Software Process Model:
Incremental Model
▪The Incremental Model is a great solution for projects that need accommodation for some
change requests between increments. (less expensive to change requirements and scope)
▪This model also yields the benefit of being able to detect problems earlier and Developers can
make alterations based on the learnings of the previous cycles.
▪Important modules/functions are developed first and then the rest are added in chunks.
▪This model is flexible and The customer can respond to each module and provide feedback if
any changes are needed. Project progress can be measured.
▪A potential disadvantage to the Model is the need for strategic planning and documentation.
▪This method also tends to require more resources, staff and monetary, behind the project.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 47
Software Process Model:
Incremental Model: Phases
▪Communication: we talk face to face with the customer and collect his/her
mandatory requirements. Like what functionalities does the customer want in his
software, etc.

▪Planning: the requirements are divided into multiple modules and planning is done on
their basis.

▪Modeling: the design of each module is prepared. After the design is ready, we take a
particular module among many modules and save it in DDS (Design Document
Specification). Diagrams like ERDs and DFDs are included in this document.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 48
Software Process Model:
Incremental Model: Phases
▪Construction: start construction based on the design of that particular module. That
is, the design of the module is implemented in coding. Once the code is written, it is
tested.

▪Deployment: After the testing of the code is completed, if the module is working
properly then it is given to the customer for use. After this, the next module is
developed through the same phases and is combined with the previous module. This
makes new functionality available to the customer. This will continue until complete
modules are developed
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 49
Software Process Model:
Incremental Model: Example
▪How Microsoft Office Suite Uses the Incremental Model: Microsoft Office (Word, Excel, PowerPoint, etc.) was not
built all at once but developed incrementally over multiple versions. Each version introduced new features while
improving existing ones.

▪Development Stages:

[Link] Release – The first version of Microsoft Word, for example, provided only basic text editing
features.
[Link] Increment – Later versions added spell-check, formatting options, and printing capabilities.
[Link] Increment – More features like grammar check, templates, and tables were introduced.
[Link] Increment – Cloud integration (OneDrive), real-time collaboration, and AI-powered
suggestions were added.
[Link] Development – Microsoft continues to release updates incrementally, improving security,
performance, and features based on user feedback.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 50
Software Process Model:
Iterative Model

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 51
 Software Process Model:
Iterative Model
▪Starts developing the software with some requirements and when it is developed, it is reviewed
and improved in the next iteration and so on.
▪Iteration means that we are repeating the development process again and again. We develop the
first version of the software following the SDLC process with some software requirements. We can
call this Iteration 1.
▪After the first version is developed, if there is a need to change the software , then a new version
is developed with the second iteration. Now again if the new version is not enough, then we will make
changes in it with the third iteration. The iteration will be repeated until the complete software is
ready.
▪As software is delivered in parts, there is no need for a full specification from the project’s start.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 52
Software Process Model:
Iterative Model: Phases
[Link] gathering & analysis: software requirements of the customer are
collected and it is analyzed whether those requirements can be meet or not. Besides, it is
also checked whether this project will not go beyond budget.
[Link]: the design of software is prepared. For this, various diagrams like Data Flow
diagram, class diagram, activity diagram, state transition diagram, etc. are used.
[Link]: Now the design of software is implemented in coding through various
programming languages.
[Link]: After the coding of the software is done, it is now tested so that the bugs and
errors present in it can be identified. Testing techniques like performance testing,
security testing, requirement testing, stress testing, etc. are done.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 53
Software Process Model:
Iterative Model: Phases
[Link]: Finally, the software is given to the customer. After this the customer
starts using that software in his work environment.

[Link]: After the software is deployed in its work environment, it is reviewed. If

any error/bug is found or any new requirements come in front of developer, then
again, these phases are repeated with new iteration and a new version is developed.

[Link]: we look at customer feedback, solve problems, fix errors, update

software, etc.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 54
 Software Process Model:
Iterative Model: Example
▪How Google Chrome Uses the Iterative Model: Google Chrome was not built in a
single step; instead, it evolved through multiple iterations, improving its
performance, security, and features over time.
▪Development Stages (Iterations)
1. First Iteration – Initial release with basic browsing capabilities.
2. Second Iteration – Performance improvements, tabbed browsing, and better
UI.
3. Third Iteration – Security updates, incognito mode, and extension support.
4. Ongoing Iterations – Regular updates introduce new features (like AI
suggestions), bug fixes, and enhanced security.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 55
Software Process Model:
Prototype Model

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 56
Software Process Model:
Prototype Model
▪Prototype model is an activity in which instead of freezing the requirements before a
design or coding can proceed, a throwaway prototypes of software applications are
created (prototype of what is believed the customer wants) which helps to better to
understand the requirements. Based on that, final product is manufactured.
▪This prototype is developed based on the currently known requirements and is created
when we do not know the requirements well.
▪If the end users are not satisfied with the prototype, then a new prototype is
created again, consuming more money and time.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 57
Software Process Model:
Prototype Model: Phases
▪Requirement gathering: The first step of prototype model is to collect the requirements, although
the customer does not know much about the requirements but the major requirements are
defined in detail.
▪Build the initial prototype: the initial prototype is built. In this some basic requirements are
displayed and user interface is made available.
▪Review the prototype: the prototype is completed is presented to the end users or customer and
feedback is taken from them about this prototype.
▪Revise and improve the prototype: When feedback is taken from end users and customers, the
prototype is improved on the basis of feedback. This process continues until the customer gets
the prototype as per his desire.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 58
Software Process Model:
Prototype Model: Example
Microsoft Windows GUI Development : When Microsoft was developing the first versions of
Windows (Windows 1.0 and Windows 2.0), they followed the Prototype Model to create and refine
the Graphical User Interface (GUI) before finalizing the product.
1. Why Microsoft Used the Prototype Model?
▪ User Feedback Was Critical – Since GUIs were a new concept, Microsoft needed user feedback
before finalizing the design.
▪ Iterative Improvements Were Required – A static design wouldn’t work; continuous
refinements were needed.
▪ Reducing Development Risks – A prototype helped Microsoft identify usability issues early on.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 59
Software Process Model:
Prototype Model: Example
2. How the Prototype Model Was Applied?
Phase 1: Initial Requirements Gathering
Microsoft identified key user needs for a GUI-based OS.
They analyzed features from existing systems like Apple Macintosh and Xerox PARC.
Phase 2: Prototype Development
Engineers built multiple prototypes of the Windows GUI.
Early prototypes had basic windowing, icons, and a file manager.
These prototypes were tested internally and with selected users.
SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 60
Software Process Model:
Prototype Model: Example
2. How the Prototype Model Was Applied?
Phase 3: User Evaluation and Feedback
▪Users tested the prototypes and provided feedback on usability, navigation, and design.
▪Microsoft modified layouts, improved responsiveness, and added new features like
overlapping windows.
Phase 4: Refinement and Further Iterations
▪New prototypes incorporated user suggestions (e.g., better menu structures).
▪The interface became more intuitive and visually appealing.
Phase 5: Final Implementation and Deployment
▪After multiple iterations, a stable Windows 1.0 version was released in 1985.
▪Future versions (Windows 2.0, Windows 3.0) built on the prototype foundation.

SOFTWARE ENGINEERING --- CHAPTER --- 1--- INTRODUCTION BY: KIBRU G. 10/17/2025 61