LECTURE NOTES

SOFTWARE ENGINEERING
UNIT TWO
Lecturer: Engr George Essah Yaw Okai
Tel:0547452532
Email: [email protected]
SOFTWARE PROCESS
 OBJECTIVES
• The objective of this lecture is to introduce students to
the fundamentals of software development process – a
coherent set of activities for software production.

• At the end of this lecture, students are expected to:

• Understand the concept of software processes; and
• Understand the generic software process models and their
applications.
 INTRODUCTION TO SOFTWARE PROCESS

• Because software is embodied knowledge, and because that

knowledge is initially dispersed, tacit, latent, and incomplete in large
measure, software development is a social learning process.
• The process is a dialogue in which the knowledge that must become
the software is brought together and embodied in the software.
• The process facilitates interaction among users, designers, and
evolving tools, as well as between designers and evolving tools and
technology.
• It is an iterative process in which the evolving tool itself serves as the
medium for communication, with each new round of the dialogue
eliciting more useful knowledge from the people involved.
 INTRODUCTION TO SOFTWARE PROCESS
• A software process is a set of activities that leads to the production of a
software product.
• These activities may involve the development of software from scratch in a
standard programming language like C or Java.
• Software processes are complex and, like all intellectual and creative
processes, rely on people making decisions and judgments.
• In the context of software engineering, a process is not a rigid prescription for
how to build computer software. Rather, it is an adaptable approach that
enables the software team to pick and choose the appropriate set of work
actions and tasks.
• The intent is always to deliver software on time and with sufficient quality to
satisfy those who have sponsored its creation and those who will use it.
 PROCESS FRAMEWORK
• A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that apply to all software
projects, regardless of their size or complexity.
• A generic process framework for software engineering encompasses five activities:
• Communication
• Planning
• Modeling
• Construction
• Deployment

• These five generic framework activities can be used during the development of small,
simple programs, the creation of large Web applications, and for the engineering of large,
complex computer-based systems. The details of the software process will be quite
different in each case, but the framework activities remain the same.
 PROCESS FRAMEWORK
Before any technical work can commence, it is critically important to
Communication communicate and collaborate with all stakeholders. The intent is to
understand stakeholders’ objectives for the project and to gather
requirements that help define software features and functions.
A software project is a complicated journey, and the planning activity creates
a “map” that helps guide the team. The map, called a software project plan,
Planning defines the software engineering work by describing the technical tasks to be
conducted, the risks that are likely, the resources that will be required, the
work products to be produced, and a work schedule.
Experts in almost all fields work with models every day. They create a
“sketch” of the things they do to understand the big picture, what it will look
like architecturally, how the constituent parts fit together, and many other
Modeling characteristics. If required, they refine the sketch into greater and greater
detail in an effort to better understand the problem and how they are going
to solve it. A software engineer does the same thing by creating models to
better understand software requirements and the design that will achieve
those requirements.
 PROCESS FRAMEWORK
Construction This activity combines code generation (either manual
or automated) and the testing that is required to
uncover errors in the code

Deployment The software (as a complete entity or as a partially

completed increment) is delivered to the customer who
evaluates the delivered product and provides feedback
based on the evaluation.
 PROCESS FLOW
• Process flow—describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect to
sequence and time.

• Linear Process Flow

• Iterative Process Flow
• Evolutionary Process Flow
• A Parallel Process Flow
 LINEAR PROCESS FLOW

• A linear process flow

executes each of the five
framework activities in
sequence, beginning with
communication and
culminating with
deployment
 ITERATIVE PROCESS
• An iterative process
flow repeats one or
more of the activities
before proceeding to
the next
 EVOLUTIONARY PROCESS FLOW

• An evolutionary process flow

executes the activities in a
“circular” manner.
• Each circuit through the five
activities leads to a more
complete version of the
software
 A PARALLEL PROCESS FLOW
• A parallel process flow)
executes one or more
activities in parallel with
other activities (e.g.,
modeling for one aspect
of the software might be
executed in parallel with
construction of another
aspect of the software).
SOFTWARE PROCESS
MODEL
 SOFTWARE PROCESS MODEL
• A software process model is an abstract representation of a software process.
• Each process model represents a process from a particular perspective and thus
provides only partial information about the process.
• That is, we see the framework of the process but not the details of specific
activities.
• These general models are not definitive descriptions of software processes.
Rather, they are abstractions of the process that can be used to explain different
approaches to software development.
• Examples of software process models:

• The Waterfall Model

• Incremental Process Models
• Evolutionary Process Models(The Spiral Model, Prototyping.)
• Concurrent Models
 THE WATERFALL MODEL

• The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins with
customer specification of requirements and progresses through planning,
modeling, construction, and deployment.
 THE PRINCIPAL STAGES OF THE
MODEL
Requirements analysis and The system’s services, constraints and goals are
definition established by consultation with system users. They are
1 then defined in detail and serve as a system
specification.

System and software design The systems design process partitions the requirements
2 to either hardware or software systems. It establishes
overall system architecture. Software design involves
identifying the fundamental software system
abstractions and their relationships.

Implementation and unit During this stage, the software design is realized as a
3 testing: set of program units. Unit testing involves verifying that
each unit meets its specification.
 THE PRINCIPAL STAGES OF THE
MODEL
Integration and testing The individual program units or programs are integrated
4 and tested as a complete system to ensure that the
software requirement has been met. After testing, the
software system is delivered to the customer.

Operation and Normally, (although not necessarily) this is the longest life
5 maintenance cycle phase. The system is installed and put into practical
use. Maintenance involves correcting errors which were not
discovered in earlier stages of the life cycle, improving the
implementation of system units and enhancing the system’s
services as new requirements are discovered.
 PROBLEMS THAT ARE ENCOUNTERED WITH
THE WATERFALL
• The classical waterfall model is an idealistic one since it assumes that no
development error is ever committed by the engineers during any of the life
cycle phases.
• However, in practical development environments, the engineers do commit a
large number of errors in almost every phase of the life cycle. The source of the
defects can be many: oversight, wrong assumptions, use of inappropriate
technology, communication gap among the project engineers, etc.
• These defects usually get detected much later in the life cycle. For example, a
design defect might go unnoticed till we reach the coding or testing phase.
• Once a defect is detected, the engineers need to go back to the phase where
the defect had occurred and redo some of the work done during that phase and
the subsequent phases to correct the defect and its effect on the later phases.
• Therefore, in any practical software development work, it is not possible to
strictly follow the classical waterfall model.
PROBLEMS THAT ARE ENCOUNTERED WITH THE WATERFALL
• The waterfall model should only be used when the requirements are well
understood and unlikely to change radically during system development.
 INCREMENTAL PROCESS MODELS

• The incremental model combines elements of linear and parallel process flows
• The incremental model applies linear sequences in a staggered fashion as
calendar time progresses. Each linear sequence produces deliverable
“increments” of the software
• There are many situations in which initial software requirements are
reasonably well defined, but the overall scope of the development effort
precludes a purely linear process.
• In addition, there may be a compelling need to provide a limited set of
software functionality to users quickly and then refine and expand on that
functionality in later software releases.
• In such cases, you can choose a process model that is designed to produce the
software in increments.
INCREMENTAL PROCESS MODELS
 INCREMENTAL PROCESS MODELS
• For example, word-processing software developed using the incremental paradigm
might deliver basic file management, editing, and document production functions
in the first increment;
• In the second increment more sophisticated editing and document production
capabilities are added;
• In the third increment, spelling and grammar checking is added;
• In the fourth increment an advanced page layout capability is added.
• It should be noted that the process flow for any increment can incorporate the
prototyping paradigm.
• When an incremental model is used, the first increment is often a core product.
• That is, basic requirements are addressed but many supplementary features (some
known, others unknown) remain undelivered.
• The core product is used by the customer for a detailed evaluation . The results of
the evaluation is used to plan the development of the next increment.
 EVOLUTIONARY PROCESS MODELS
• Evolutionary Process Model is based on the idea of developing an initial
implementation, exposing this to user comments and refining it through many
versions until an adequate system has been developed.
• Specifications, development and validation activities are interleaved rather than
separate, with rapid feedback across activities.
• Evolutionary models are iterative. They are characterised in a manner that
enables you to develop increasingly more complete versions of the software.
• There are two fundamental types of evolutionary development:
• Exploratory development, where the objective of the process is to work with the customer
to explore their requirements and deliver a final system. The development starts with the
parts of the system that are understood. The system evolves by adding new features
proposed by the customer.
• Throwaway prototyping, where the objective of the evolutionary development process is
to understand the customer’s requirements and hence develop a better requirements
definition for the system. The prototype concentrates on experimenting with the customer
requirements that are poorly understood.
COMMON EVOLUTIONARY
PROCESS MODELS
• Prototyping Model
• The Spiral Model
 PROTOTYPING

• A prototype is a toy implementation of the system.

• A prototype usually exhibits limited functional capabilities, low reliability, and
inefficient performance compared to the actual software.
• A prototype is usually built using several shortcuts.
• The shortcuts might involve using inefficient, inaccurate, or dummy functions.
• A prototype usually turns out to be a very crude version of the actual system.
• Although prototyping can be used as a stand-alone process model, it is more
commonly used as a technique that can be implemented within the context of
any one of the process models.
• Regardless of the manner in which it is applied, the prototyping paradigm
assists you and other stakeholders to better understand what is to be built
when requirements are fuzzy.
PROTOTYPING
 PROTOTYPING

• The prototyping paradigm begins with communication.

• You meet with other stakeholders to define the overall objectives for the software,
identify whatever requirements are known, and outline areas where further
definition is mandatory.
• A prototyping iteration is planned quickly, and modeling (in the form of a “quick
design”) occurs.
• A quick design focuses on a representation of those aspects of the software that
will be visible to end users (e.g., human interface layout or output display
formats).
• The quick design leads to the construction of a prototype. The prototype is
deployed and evaluated by stakeholders, who provide feedback that is used to
further refine requirements.
• Iteration occurs as the prototype is tuned to satisfy the needs of various
stakeholders, while at the same time enabling you to better understand what
needs to be done.
 PROTOTYPING
• Although problems can occur, prototyping can be an effective paradigm for
software engineering.
• The key is to define the rules of the game at the beginning; that is, all
stakeholders should agree that the prototype is built to serve as a mechanism
for defining requirements.
• It is then discarded (at least in part), and the actual software is engineered with
an eye toward quality.
 THE SPIRAL MODEL

• The Spiral Model was Originally proposed by Barry Boehm

• The spiral model is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and systematic aspects of
the waterfall model.
• It provides the potential for rapid development of increasingly more complete
versions of the software.
• The diagrammatic representation of this model appears like a spiral with many
loops.
• The exact number of loops in the spiral is not fixed.
• Each loop of the spiral represents a phase of the software process.
THE SPIRAL MODEL
 THE SPIRAL MODEL
• A spiral model is divided into a set of framework activities defined by the
software engineering team.
• Each of the framework activities represents one segment of the spiral path
• As this evolutionary process begins, the software team performs activities
that are implied by a circuit around the spiral in a clockwise direction,
beginning at the centre.
• Risk is considered with each revolution made.
• Unlike other process models that end when software is delivered, the spiral
model can be adapted to apply throughout the life of the computer software.
• Therefore, the first circuit around the spiral might represent a “concept
development project” that starts at the core of the spiral and continues for
multiple iterations until concept development is complete.
 CIRCUMSTANCES TO USE SPIRAL MODEL
• The spiral model is called a meta model since it encompasses all
other life cycle models.
• Risk handling is inherently built into this model.
• The spiral model is suitable for development of technically
challenging software products that are prone to several kinds of
risks.
• However, this model is much more complex than the other
models – this is probably a factor deterring its use in ordinary
projects.
 CONCURRENT MODELS

• The concurrent development model also called concurrent engineering, allows

a software team to represent iterative and concurrent elements of any of the
process models already described.

• The concurrent development model can be represented schematically as a

series of framework activities, Software engineering actions of tasks, and their
associated states.

• The concurrent model is often more appropriate for system engineering

projects where different engineering teams are involved.
CONCURRENT MODEL
 CONCURRENT MODEL
• Figure above provides a schematic representation of one Software engineering
task within the modeling activity for the concurrent process model.
• The activity – modeling- may be in any one of the states noted at any given
time.
• All activities exist concurrently but reside in different states.
• For example, early in the project the communication activity has completed its
first iteration and exists in the awaiting changes state.
• The modeling activity which existed in the Inactive or none state while initial
communication was completed now makes a transition into underdevelopment
state.
• If, however, the customer indicates the changes in requirements must be made,
the modeling activity moves from the under development state into the
awaiting changes state.
 CONCURRENT MODEL
• Concurrent modeling defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, actions, or tasks.
• For example, during early stages of design (a major software engineering action that
occurs during the modeling activity), an inconsistency in the requirements model is
uncovered.
• This generates the event analysis model correction, which will trigger the
requirements analysis action from the done state into the awaiting changes state.
• Concurrent modeling is applicable to all types of software development and
provides an accurate picture of the current state of a project. Rather than confining
software engineering activities, actions, and tasks to a sequence of events, it
defines a process network.
• Each activity, action, or task on the network exists simultaneously with other
activities, actions, or tasks.
• Events generated at one point in the process network trigger transitions among the
states.
Thank You