Software Engineering

[ECEG4201]
Introduction
YAFET PHILIPOS
[email protected]

INTRODUCTION 1
Software
◼If you have to write a 10,000 line program in C to
solve a problem, ~ it will take 2-4 months long
◼Let us analyze the productivity
◼Productivity = output/input resources
◼In SW output is considered as line of code (LOC)
◼Input resources is effort - person months; overhead cost
modeled in rate for person month
◼Though not perfect, some productivity measure is needed,
as a project has to keep productivity high

INTRODUCTION 2
 Software …
◼The productivity is 2.5-5 KLOC/PM
◼Q: What is the productivity in a typical commercial SW organization ?
◼A: Between 100 to 1000 LOC/PM
◼Q: Why is it low, when your productivity is so high? (people like you work in the
industry)
◼A: What the student is building and what the industry builds are two different
things

INTRODUCTION 3
Software…
◼In a univ a student system is built while the
commercial org builds industrial strength sw
◼What is the difference between a student
program and industrial strength sw for the same
problem?
◼Lets define Software
◼Software (IEEE): collection of programs, procedures,
rules, and associated documentation and data

INTRODUCTION 4
Software…

Student Industrial Strength

◼Developer is the user ◼Others are the users
◼bugs are tolerable ◼bugs not tolerated
◼UI not important ◼UI very imp. issue
◼No documentation ◼Documents needed for the
user as well as for the
organization and the project

INTRODUCTION 5
 Software…
Student Industrial Strength
▪SW not in critical use ◼Supports important functions /
business
▪Reliability, robustness not
important ◼Reliability , robustness are very
important
▪No investment
◼Heavy investment
▪Don’t care about portability
◼Portability is a key issue here

INTRODUCTION 6
 Industrial strength software
◼Student programs for a problem & industrial
strength software are two different things
◼Key difference is in quality (including usability,
reliability, portability, etc.)
◼High quality requires heavy testing, which consumes 30-50%
of total development effort
◼Requires development be broken in stages such that bugs
can be detected in each
◼Good UI, backup, fault-tolerance, following of stds etc
increase the size for the same functionality

INTRODUCTION 7
Industrial strength software
◼Domain of SE: Industrial strength SW
◼In SE. and in this course, software means
industrial strength software

INTRODUCTION 8
Software is Expensive
◼Let us look at costs involved
◼Productivity = 500 LOC/PM
◼Cost to the company = $10K/PM
◼Cost per LOC = $20
◼I.e, each line of delivered code costs about $20.
◼A simple application for a business may have 20KLOC
to 50KLOC
◼Cost = $100K to $1Million
◼Can easily run on $10K-$20K hardware
◼So HW costs in an IT solution are small as compared to SW
costs.
INTRODUCTION 9
Software is Expensive…

◼The HW/SW ratio for a computer system has shown

a reversal from the early years.
◼In 50s , HW:SW :: 80:20
◼In 80s , HW:SW :: 20:80
◼So , SW is very expensive
◼Importance of optimizing HW is not much
◼More important to optimize SW

INTRODUCTION 10
Late & Unreliable
◼20-25% of SW projects never complete
◼Because after some time they realize that the final cost will
be much higher
◼Many companies report runaways
◼budget & cost out of control
◼consulting companies to help control them
◼One defence (in India) survey found that 70% of the
equipment problems are due to SW

INTRODUCTION 11
Unreliable…
◼SW failures are different from failures of mechanical or
electrical systems

◼In software, failures are not due to aging related problems

◼Failures occur due to bugs or errors that get introduced

during development

◼I.e. the bug that causes a failure exists from start, only
manifests later
INTRODUCTION 12
Maintenance
▪Once sw is delivered, it enters maintenance phase
▪Why is maintenance needed for sw when it does
not wear with age?
▪ Residual errors requiring corrective maintenance
▪ Upgrades and environment changes – adaptive
maintenance
▪Over sw life, maintenance can cost more than the
development cost of sw

INTRODUCTION 13
SE Challenges
▪Problem domain discussed before, now we discuss the area of SE
▪SE (IEEE): systematic approach to development,…., of software
▪Systematic approach: methodologies and practices that can be used to
solve a problem from problem domain

INTRODUCTION 14
Basic Problem

INTRODUCTION 15
SE Challenges
▪The problem of producing software to satisfy user
needs drives the approaches used in SE
▪ Software is Industrial strength sw
▪But there are other factors that drive the selection
of approaches
▪These factors include considerations of scale,
quality, productivity, consistency, change, …

INTRODUCTION 16
 Scale

◼SE must deal with problem of scale

◼methods for solving small problems do not scale up for
large problems
◼industrial strength SW problems tend to be large
◼SE methods must be scalable
◼Two clear dimensions in this
◼Engineering methods
◼Project management
◼For small projects, both can be informal or ad-hoc,
for large projects both have to be formalized

INTRODUCTION 17
Scale…

INTRODUCTION 18
Scale…
◼An illustration of issue of scale is counting the
number of people in a room vs taking a census
◼Both are counting problems
◼Methods used in first not useful for census
◼For large scale counting problem, must use different
techniques and models
◼Management will become critical

INTRODUCTION 19
Scale: Examples
Gcc 980KLOC C, C++, yacc

Perl 320 KLOC C, perl, sh

Appache 100 KLOC C, sh

Linux 30,000 KLOC C, c++

Windows XP 40,000 KLOC C, C++

INTRODUCTION 20
Productivity
▪An engg project is driven by cost and schedule
▪In sw cost is mainly manpower cost, hence measured
in person-months
▪Schedule is in months/weeks – very important in
business context
▪Productivity captures both of these
▪ If P is higher, cost is lower
▪ If P is higher, time taken can be lesser
▪Approaches used by SE must deliver high P

INTRODUCTION 21
Quality
◼Quality is the other major driving factor
◼Developing high Q sw is a basic goal
◼Quality of sw is harder to define
◼Approaches used should produce a high Q software

INTRODUCTION 22
Quality – ISO standard
◼ISO std has six attributes
◼Functionality
◼Reliability
◼Usability
◼Efficiency
◼Maintainability
◼Portability

INTRODUCTION 23
Quality…
◼Multiple dimensions mean that not easy to reduce Q to a
single number
◼Concept of Q is project specific
◼For some reliability is most important
◼For others usability may be more important

◼Reliability is generally considered the main Q criterion

INTRODUCTION 24
 Quality…
◼Reliability = Probability of failure
◼hard to measure
◼approximated by no. of defects in software

◼To normalize Quality = Defect density

◼Quality = No. of defects delivered / Size

◼Defects delivered - approximated with no. of defects found in

operation
◼Current practices: less than 1 def/KLOC
◼What is a defect? Project specific!

INTRODUCTION 25
Consistency and repeatability
◼Sometimes a group can deliver one good software
system
◼Key SE challenge: how to ensure that success can
be repeated
◼SE wants methods that can consistently produce
high Q sw with high P
◼A sw org, wants to deliver high Q&P consistently
across projects

INTRODUCTION 26
Change
◼Only constant in business is change!
◼Software must change to support the changing
business needs
◼SE practices must accommodate change
◼Methods that disallow change, even if high Q and P, are
of little use

INTRODUCTION 27
SE Approach
◼We understand the problem domain, the factors that drive SE
◼Consistently develop sw with high Q&P for large scale problems and under
changes

◼Q&P are the basic objectives to be achieved under large scale and
changes
◼Q&P governed by people, processes, and technology

◼Referred as: Iron Triangle

INTRODUCTION 28
SE Approach
◼SE focuses mostly on processes for achieving the
goals
◼Systematic approach is really about processes
being used
◼SE separates process for developing sw from the
developed product (i.e sw)
◼Premise: Process largely determines Q&P, hence
suitable processes will lead to high Q&P

INTRODUCTION 29
SE Approach…
◼Design of proper processes and their control is a key
challenge SE faces
◼This focus on process makes SE different from many CS
courses
◼Sw process is the equivalent of manufacturing process

INTRODUCTION 30
SE Approach…
◼The development process used in SE is typically
phased
◼Phases separate concerns with each phase
focusing on some aspect
◼Requirements, architecture, design, coding, testing are
key phases
◼This phased process has to be properly managed
to achieve the objectives
◼Metrics and measurement important for this

INTRODUCTION 31
Software Process
▪Process is distinct from product – products are
outcomes of executing a process on a project
▪SW Engg. focuses on process
▪Premise:
▪ Proper processes will help achieve project objectives of
high QP

INTRODUCTION 32
Software Process…
◼Process: A particular method, generally involving a
number of steps
◼Software Process: A set of steps, along with
ordering constraints on execution, to produce
software with desired outcome
◼Many types of activities performed by diff people
in a software project
◼Better to view software process as comprising of
many component processes

INTRODUCTION 33
Component Software
Processes
▪Two major processes
▪ Development – focuses on development and quality
steps needed to engineer the software
▪ Project management – focuses on planning and
controlling the development process
▪Development process is the heart of software
process; other processes revolve around it
▪These are executed by different people
▪ developers execute engineering process
▪ project manager executes the management process

INTRODUCTION 34
Component Processes…
Other processes
◼Configuration management process:
◼manages the evolution of artifacts
◼Change management process:
◼how changes are incorporated
◼Process management process:
◼management of processes themselves
◼Inspection process:
◼How inspections are conducted on artifacts

INTRODUCTION 35
Process Specification
▪Process is generally a set of phases
▪Each phase performs a well defined task and generally
produces an output
▪Intermediate outputs – work products
▪At top level, typically few phases in a process
▪How to perform a particular phase – methodologies
have been proposed

INTRODUCTION 36
ETVX Specification
◼ETVX approach to specify a step
◼Entry criteria: what conditions must be satisfied for
initiating this phase
◼Task: what is to be done in this phase
◼Verification: the checks done on the outputs of this
phase
◼eXit criteria: when can this phase be considered done
successfully
◼A phase also produces info for mgmt

INTRODUCTION 37
ETVX approach

INTRODUCTION 38
Desired Process Properties
◼Provide high Q&P
◼Support testability as testing is the most
expensive task; testing can consume 30 to 50% of
total development effort
◼Support maintainability as maintenance can be
more expensive than development; over life up
to 80% of total cost
◼Remove defects early, as cost of removing
defects increases with latency

INTRODUCTION 39
High Q&P: Early Defect
Removal…
◼Cost of a defect increases with latency
◼I.e. fixing a req defect in operation can cost a 100
times the cost of fixing it in requirements itself
◼Hence, for high Q&P, the process must support
early defect removal
◼That is why there is a V in ETVX, and quality
control tasks in the sw process

INTRODUCTION 40
Early Defect Removal…

INTRODUCTION 41
Desired Properties…
◼Predictability and repeatability
◼Process should repeat its performance when
used on different projects
◼I.e. outcome of using a process should be
predictable
◼Without predictability, cannot estimate, or say
anything about quality or productivity
◼With predictability, past performance can be
used to predict future performance

INTRODUCTION 42
Predictability…
▪Predictable process is said to be under
statistical control
▪Repeatedly using the process produces similar
results
▪Results – properties of interest like quality,
productivity, …
▪To consistently develop sw with high Q&P,
process must be in control

INTRODUCTION 43
Predictability…

INTRODUCTION 44
Support Change
▪Software changes for various reasons
▪Requirements change is a key reason
▪Requirement changes cannot be wished away or
treated as “bad”
▪They must be accommodated in the process for sw
development

INTRODUCTION 45