Lecture 01: Software
Processes
SE302: Principles of Software Engineering
Lecturer: Dr. İlker Korkmaz
(Slides were prepared by Dr. Kaya Oğuz)
Previously…
● Introduction to the course and software engineering…
● Did you sign up for a Git account?
This Week
● Software Process Models
● Process Activities
The Software Process
● Sommerville defines software process as “a structured set of activities
required to develop a software system.”
● Pressman defines it as “a framework for the activities, actions, and tasks that
are required to build high-quality software.”
● The activities are,
○ Specification: defining what the system should do,
○ Design & Implementation: defining the organization of the system and implementing it,
○ Validation: checking that software does what the customer wants,
○ Evolution: changing the system in response to changing customer needs.
● These are surrounded by other activities, such as project tracking and control,
risk management, quality assurance, etc.
The Software Process
● A software process model is an abstract representation of a process.
● When we describe and discuss processes, we usually talk about the activities
in them (1), such as specifying a data model, designing a user interface, etc.
and the ordering (2) of these activities.
● Process descriptions also include,
○ Products: the outcomes of a process activity,
○ Roles: which reflect the responsibilities of the people involved in the process,
○ Pre and post conditions: statements that are true before and after a process activity has been
enacted or a product produced.
IEEE Process Groups
● The IEEE Standard for
Software Life Cycle
Processes describes the
set of activities and
processes that are
mandatory for the
development and
maintenance of
software.
Software, Entropy, Chaos and Order
● How shall we approach the process of software building?
● There are many problems;
○ Software does not have a physical representation, therefore it is very hard to measure its
properties.
○ When we cannot measure, how can we tell how much we are done?
○ If we give the process structure and order, are they inappropriate for a software world that
thrives on change?
● What is the ideal state of nature? Chaos or order?
Software, Entropy, Chaos and Order
● Research supports the theory that operation away from equilibrium generates
creativity, self-organized process, and increasing returns.
● Absolute order means the absence of variability, which could be an
advantage under unpredictable environments.
● Change occurs when there is some structure so that the change can be
organized, but not so rigid that it cannot occur.
● So, let’s start with some “prescriptive process approaches.”
Prescriptive Process Models
● In prescriptive process models, order and project consistency are dominant
issues.
● They prescribe a set of process elements: framework activities, software
engineering actions, tasks, work products, quality assurance, and change
control mechanisms.
● The most famous of them all is the waterfall model.
The Waterfall Model
● There are times when the requirements for a problem are well understood:
the work flows from specification to deployment in a reasonably linear
fashion.
● The waterfall model, also called the classic life cycle, suggests a systematic,
sequential approach to software development with the following separately
identified phases:
○ Requirements analysis and definition,
○ System and software design,
○ Implementation and unit testing,
○ Integration and system testing,
○ Operation and maintenance.
The Waterfall Model
Requirements
Analysis and Definition
System and Software
Design
Implementation and
Unit Testing
Integration and
System Testing
Operation and
Maintenance
The Waterfall Model
● The main drawback of the waterfall model is the difficulty of accommodating
change after the process is underway.
● In principle, a phase has to be complete before moving on to the next one.
● Inflexible partitioning makes it difficult to respond to changing customer
requirements.
● This model is only appropriate when the requirements are well-understood
and changes will be fairly limited during the design process.
● It is mostly used for large system engineering projects where a system is
developed at several sites in which the nature of the waterfall model helps
coordinate the work.
The V-model
● The V-model is a variation in the representation of the waterfall model.
● It stresses the necessity for validation activities that match the activities that
create the products of the project.
The V-model
Feasibility study Corrections Review
User requirements Corrections User acceptance
System design Corrections System Testing
Program design Corrections Program Testing
Coding
The V-model
● The V-model is a variation in the representation of the waterfall model.
● It stresses the necessity for validation activities that match the activities that
create the products of the project.
● The V-process model can be seen as expanding the activity testing in the
waterfall model.
● Each step has a matching validation process which can, where defects are
found, cause a loop back to the corresponding development stage and a
reworking of the following steps.
The V-model
● Ideally this feeding back should only occur where a discrepancy has been
found between what was specified by a particular activity and what was
actually implemented in the next lower activity on the descent of the V loop.
○ For example, the system designer might have written that a calculation be carried out in a
certain way. A developer building code to meet this design might have misunderstood what
was required.
○ At system testing stage, the original designer would be responsible for checking that the
software is doing what was specified and this would discover the coder’s misreading of that
document.
More on Waterfall and V-model
● The waterfall model is the oldest paradigm for software engineering.
● However, there are many criticisms of this process:
○ Real projects rarely follow the sequential flow proposed by the model.
○ It is difficult for the customer to state all requirements explicitly. This creates an unnatural
uncertainty right at the beginning of many projects.
○ The customer must have patience. A working version of the program will not be available until
late in the project time span.
○ Blocking states: since one phase must be complete before moving on to the next, some team
members have to wait for others, which reduces efficiency.
More on Waterfall and V-model
● Today’s software is fast-paced and subject to never-ending stream of
changes.
● The waterfall model is often inappropriate for such work. However, it can
serve as a useful process model in situations where requirements are fixed
and work is to proceed to completion in a linear manner.
● Consider systems where human life is in risk: health systems, space
missions, vehicle software, etc.
● In such cases, the requirements are thoroughly analysed and waterfall can be
useful.
Incremental Process Models
● The incremental model delivers a series of releases, called increments, that
provide progressively more functionality for the customer as each increment
is delivered.
● The incremental model combines elements of linear and parallel process
flows.
● The model applies linear sequences in a staggered fashion as calendar time
progresses.
● Each linear sequence produces deliverable “increments” of the software.
Incremental Process Models
Image reference: Pressman, Software Engineering: A Practitioner’s Approach, page 42
Incremental Process Models
● For example, a word processing software that is developed incrementally
might deliver basic file management, editing and document production
functions in the first increment; more sophisticated editing and document
production capabilities in the second; spelling and grammar checking in third;
etc.
Incremental Process Models
● When an incremental model is used, the first increment is often a core
product. That is, basic requirements are addressed but many supplementary
features remain undelivered.
● The product is used by the customer (evaluated), and the next increment is
planned according to the feedback.
● The model focuses on the delivery of an operational product with each
increment.
Incremental Process Models: Benefits
● The cost of accommodating changing customer requirements is reduced.
● It is easier to get customer feedback on the development work that has been
done.
● More rapid delivery and deployment of useful software to the customer is
possible.
Incremental Process Models: Problems
● The process is not visible. Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
● System structure tends to degrade as new increments are added. Unless time
and money is spent on refactoring to improve the software, regular change
tends to corrupt its structure. Incorporating further software changes becomes
increasingly difficult and costly.
Prototyping
● “Plan to throw one away. You will do that, anyway. Your only choice is
whether to try to sell the throwaway to the customers,” Frederick P. Brooks.
● Often, the customer defines a set of general objectives for software, but does
not identify detailed requirements for functions and features.
● In such cases, prototyping may offer the best approach.
● Although prototyping can be used as a stand-alone process, it is more
commonly used as a technique that can be implemented within the context of
other processes.
● It assists you and other stakeholders to better understand what is to be built
when requirements are not clear.
Prototyping
● A quick design focuses on a representation
of the aspects of the software that will be
visible to the end users.
● Quick design leads to a prototype, which is
evaluated by stakeholders who provide
feedback.
● 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.
Image reference: Pressman, Software Engineering: A Practitioner’s Approach, page 43
Prototyping
● The prototype serves as the “first system” - the one that Brooks recommends
you to throw away.
● Although some prototypes are built as throwaways, others are evolutionary
in the sense that the prototype slowly evolves into the actual system.
● Both stakeholders and the software engineers like the prototyping paradigm.
● Users get a feel for the actual system, and developers get to build something
immediately.
Prototyping: Disadvantages
● Stakeholders see what appears to be a working version of the software,
unaware that the prototype is held together haphazardly, unaware that in the
rush to get it working you haven’t considered overall software quality or long-
term maintainability.
● When informed, stakeholders demand that “a few fixes” be applied to make
the prototype a working product.
Prototyping: Disadvantages
● From the software engineer’s point of view, in order to get the prototype
working, an inappropriate operating system or programming language may be
used simply because it is available and known, an inefficient algorithm may
be implemented simply to demonstrate capability.
● After a time, you may become comfortable with these choices and forget all
the reasons why they are inappropriate. The less-than-ideal choice has now
become an integral part of the system.
The Spiral Model
● 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 Spiral Model
● Boehm describes it as follows:
“The spiral development model is a risk-driven process model generator that
is used to guide multi-stakeholder concurrent engineering of software
intensive systems. It has two main distinguishing features: (1) a cyclic
approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk, (2) a set of anchor point
milestones for ensuring stakeholder commitment to feasible and mutually
satisfactory system solutions.
The Spiral Model
By Connyderivative work: Spiral_model_(Boehm,_1988).png: Marctroyderivative work: Conan (talk) - File:Spiralmodel_nach_Boehm.png, Spiral_model_(Boehm,_1988).png, Public Domain,
[Link]
The Spiral Model
● Using the spiral model, software is developed in a series of evolutionary
releases.
● During early iterations, the release might be a model or prototype.
● During later iterations, increasingly more complete versions of the engineered
system are produced.
● A spiral model is divided into a set of framework activities defined by the
software engineering team.
● Anchor point milestones, which are a combination of work products and
conditions that are attained along the path of the spiral, are noted for each
evolutionary pass.
The Spiral Model
● Unlike other process models that end when software is delivered, the spiral
model can be adapted to apply throughout the life of the software.
● The spiral model is a realistic approach to the development of large-scale
systems and software.
● Because the software evolves as the process progresses, the developer and
customer better understand and react to risks at each level.
● It demands a direct consideration of technical risks at all stages of the project
and, if properly applied, should reduce risks before they become problematic.
The Spiral Model
● But like other models, the spiral model is not the silver bullet.
● It may be difficult to convince customers that the evolutionary approach is
controllable.
● It demands considerable risk assessment expertise and relies on it for
success.
● If a major risk is not uncovered and managed, problems will undoubtedly
occur.
Component Based Development
● Commercial off-the-shelf (COTS) software components, developed by
vendors who offer them as products, provide targeted functionality with well-
defined interfaces that enable the component to be integrated into the
software that is to be built.
● The component based development model incorporates many of the
characteristics of the spiral model. It is evolutionary and demands an iterative
approach.
● However, this model constructs applications from prepackaged software
components.
Component Based Development
● The component based development model incorporates the following steps,
implemented using an evolutionary approach:
○ Available component-based products are researched and evaluated for the application
domain,
○ Component integration issues are considered,
○ A software architecture is designed to accommodate the components,
○ Components are integrated into the architecture,
○ Comprehensive testing is conducted to ensure proper functionality.
Component Based Development
Component Based Development
● This model leads to software reuse, and reusability provides software
engineers with a number of measurable benefits.
● Your software engineering team can achieve a reduction in development
cycle time, as well as a reduction in project cost if component reuse becomes
part of your culture.
Aspect-Oriented Software Development
● As modern computer-based systems become more complex, certain
concerns span the entire architecture.
● Some concerns are high-level properties of the system: such as security and
fault tolerance.
● Other concerns affect functions, such as the application of business rules,
while others are systemic, such as task synchronization or memory
management.
● When concerns cut across multiple system functions, features and
information, they are often referred to as crosscutting concerns.
Aspect-Oriented Software Development
● Aspectual requirements define those crosscutting concerns that have an
impact across the software architecture.
● Aspect-oriented software development (AOSD), also called aspect-oriented
programming (AOP), provides a process and methodological approach for
defining, specifying, designing and constructing aspects; mechanisms beyond
subroutines and inheritance for localizing the expression of a crosscutting
concern.
● A distinct aspect-oriented process has not yet matured.
The Unified Process
● Ivar Jacobson, Grady Booch and James Rumbaugh discuss the need for a
“use case driven, architecture-centric, iterative and incremental” software
process in an attempt to draw on the best features and characteristics of
traditional software process models, but characterize them in a way that
implements many of the best principles of agile software development.
The Unified Process: Phases
● Inception
● Elaboration
● Construction
● Transition
● Production
The Unified Process
● It is likely that at the same time the
construction, transition, and production
phases are being conducted, work may
have already begun on the next software
increment.
● This means that the five UP phases do
not occur in a sequence but rather with
staggered concurrency.
Image reference: Pressman, Software Engineering: A Practitioner’s Approach, page 55
Personal Software Process (PSP)
● Every developer uses some process to build computer software.
● The process maybe haphazard or ad hoc; may change on a daily basis; may
not be efficient, effective or even successful: but a process exists.
● Humphrey suggests that in order to change an ineffective personal process,
an individual must move through four phases, each requiring training and
careful instrumentation.
● The Personal Software Process (PSP) emphasizes personal measurement of
both the work product is produced and the resultant quality of the work
product.
Image reference: Spencer Rugabear, PSP presentation: [Link]
Personal Software Process (PSP)
● PSP represents a disciplined, metrics-based approach to software
engineering.
● When properly introduced, the resulting improvement in software engineering
productivity and software quality are significant.
● However, it is not been widely adopted, mostly because of human nature and
organizational inertia.
● PSP is intellectually challenging and demands a level of commitment that is
not always possible to obtain.
● Training is lengthy and training costs are high.
Team Software Process (TSP)
● Because many industry-grade software projects are addressed by a team of
practitioners, Humphrey extended PSP to Team Software Process (TSP).
● The goal of TSP is to build a self-directed project team that organizes itself to
produce high-quality software.
Team Software Process (TSP)
● A self-directed team
○ has a consistent understanding of its overall goals and objectives;
○ defines roles and responsibilities for each team member;
○ tracts quantitative project data; identifies a team process that is appropriate for the project and
a strategy for implementing the process;
○ defines local standards that are applicable to the team’s software engineering work;
○ continually assesses risk and reacts to it;
○ tracks, manages, and reports project status.
Agile Processes
● We will be covering agile software development next week.
● “Agile Software Development” is an umbrella term for a set of methods and
practices based on the values and principles expressed in the Agile
Manifesto.
● There are many methods; XP, Scrum, Kanban, etc…
● Agile processes are incremental & iterative; which begs the question, what is
the difference?
Incremental Development Strategy
● Each successive version of the product is usable, and each builds upon the
previous version by adding user-visible functionality.
● These are called “vertical” increments; as opposed to the opposite strategy
which successively delivers complete technical components: for instance,
creating a database schema, then building business rules on top of that, and
only then implementing a UI.
Iterative Development
● Agile projects are iterative insofar as they intentionally allow for repeating
software development activities, and for potentially revisiting the same work
products (the phrase planned rework is sometimes used; refactoring is a good
example).
● Nearly all Agile projects are incremental as well as iterative.
● However, it is possible to use iterative strategies which are not also
incremental; Prototyping is necessarily an iterative strategy, and may have
been a precursor to the development of iterative software development ideas.
Incremental Development Strategy
● The percentages represent the business value.
%20 %30 %60 %90 %100
User User User User User
User interface %100 Iteration 4 interface interface interface interface interface
Business Business Business Business Business
Logic Logic Logic Logic Logic
Business Logic %0 Iteration 3
Data Data Data Data Data
Access Access Access Access Access
Data Access %0 Iteration 2 Database Database Database Database Database
Database %0 Iteration 1 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
Image redrawn using the figure at: [Link]
There is no silver bullet
● There is no one strategy, paradigm, method, process that is fit for all projects.
● In that case you need to consider your options depending on
○ The project you are about to develop: this requires understanding the problem. Requirements
analysis is very, very important; the better you understand it, the better you solve it.
○ Budget and time: two important factors; given unlimited time and money, any problem can be
solved (how?). For your project in this course you have limited time; there is a due date, and
there are other courses you are attending.
○ Developers: This is why being a good software engineer is important; you need to have soft
and hard skills. Your process must also be compatible with your team.
Sample projects
● Let’s try to decide how to develop the following projects:
○ OASIS mobile
○ University course scheduler
○ Automated diabetics injection tool
○ Mars Rover Curiosity
Image reference: [Link]
Process Activities
● The four basic process activities of specification, development, validation and
evolution are organized differently in different development processes.
● Specification: The process of establishing what services are required and
the constraints on the system’s operation and development.
● This is done with requirements engineering process.
Process Activities
● Design and implementation: The process of converting the system
specification into an executable system.
● Software design: Design a software structure that realises the specification
● Implementation: Translate this structure into an executable program
● The activities of design and implementation are closely related and may be
interleaved.
Design Activities
● Architectural design, where you identify the overall structure of the system,
the principal components (subsystems or modules), their relationships and
how they are distributed.
● Database design, where you design the system data structures and how
these are to be represented in a database.
● Interface design, where you define the interfaces between system
components.
● Component selection and design, where you search for reusable
components. If unavailable, you design how it will operate.
System Implementation
● The software is implemented either by developing a program or programs or
by configuring an application system.
● Design and implementation are interleaved activities for most types of
software system.
● Programming is an individual activity with no standard process.
● Debugging is the activity of finding program faults and correcting these faults.
Software Validation
● Verification and validation (V & V) is intended to show that a system conforms
to its specification and meets the requirements of the system customer.
● Involves checking and review processes and system testing.
● System testing involves executing the system with test cases that are derived
from the specification of the real data to be processed by the system.
● Testing is the most commonly used V & V activity.
Testing Stages
● Component testing
○ Individual components are tested independently;
○ Components may be functions or objects or coherent groupings of these entities.
● System testing
○ Testing of the system as a whole. Testing of emergent properties is particularly important.
● Customer testing
○ Testing with customer data to check that the system meets the customer’s needs.
Software Evolution
● Software is inherently flexible and can change.
● As requirements change through changing business circumstances, the
software that supports the business must also evolve and change.
● Although there has been a demarcation between development and evolution
(maintenance) this is increasingly irrelevant as fewer and fewer systems are
completely new.
References
● Sommerville, Software Engineering 10
● Pressman, Software Engineering: A Practitioner’s Approach
● Bernd Bruegge, Allen H. Dutoit, Object Oriented Software Engineering Using
UML, Patterns, and Java, Prentice Hall, 2010
● Bob Hughes, Mike Cotterell, Software Project Management, McGraw Hill,
2006
● [Link]