Lecture 3 - Chapter 1

bluntmoaningΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

68 εμφανίσεις

Lecture 3

Scope and necessity of software engineering



Engineering is an engineering approach for software development.


We can alternatively view it as a systematic collection of past
experience. The experience is arranged in the form of
methodologies and guidelines.


A small program can be written without using software
engineering principles. But if one wants to develop a large
software product, then software engineering principles are
MUST

to achieve a good quality software cost effectively.


Without using software engineering principles it would be difficult to develop
large programs.


A program of size 1,000 lines of code has some complexity. But a program with
10,000 LOC is not just 10 times more difficult to develop, but may as well turn
out to be 100 times more difficult unless software engineering principles are
used.


In such situations software engineering techniques come to rescue.


Software engineering helps to reduce the programming complexity.


Software engineering principles use two important techniques to reduce
problem complexity.


Abstraction and Decomposition

Scope and necessity of software engineering


Abstraction


The

principle

of

abstraction

implies

that

a

problem

can

be

simplified

by

omitting

irrelevant

details
.



In

other

words,

the

main

purpose

of

abstraction

is

to

consider

only

those

aspects

of

the

problem

that

are

relevant

for

certain

purpose

and

suppress

other

aspects

that

are

not

relevant

for

the

given

purpose
.



Once

the

simpler

problem

is

solved,

then

the

omitted

details

can

be

taken

into

consideration

to

solve

the

next

lower

level

abstraction,

and

so

on
.



Abstraction

is

a

powerful

way

of

reducing

the

complexity

of

the

problem
.

Abstraction

Decomposition


In

this

technique,

a

complex

problem

is

divided

into

several

smaller

problems

and

then

the

smaller

problems

are

solved

one

by

one
.



However,

in

this

technique

any

random

decomposition

of

a

problem

into

smaller

parts

will

not

help
.



The

problem

has

to

be

decomposed

such

that

each

component

of

the

decomposed

problem

can

be

solved

independently

and

then

the

solution

of

the

different

components

can

be

combined

to

get

the

full

solution
.



A

good

decomposition

of

a

problem

should

minimize

interactions

among

various

components
.



If

the

different

subcomponents

are

interrelated,

then

the

different

components

cannot

be

solved

separately

and

the

desired

reduction

in

complexity

will

not

be

realized
.

Decomposition

Program vs. Software product


Programs are developed by individuals for their personal use. They are
therefore, small in size and have limited functionality but software products are
extremely large such as Windows 7.


In case of a program, the programmer himself may or may not be sole user but
on the other hand, in case of a software product, most users are not involved
with the development.


For a program, the user interface may not be very important, because the
programmer is the sole user. On the other hand, for a software product, user
interface must be carefully designed and implemented because developers of
that product and users of that product are totally different.


In case of a program, very little documentation is expected, but a software
product must be well documented.


A program can be developed according to the programmer’s individual style of
development, but a software product must be developed using the accepted
software engineering principles.

Future of Software Engineering


Microsoft, IBM


Any Commercial Software


App Development


Apple Store


Android


Two Tier

Software

Engineering


Software

SOFTWARE ENGINEERING

10


Q : If you have to write a 10,000 line program in C to
solve a problem, how long will it take?


Answers: generally range from 2
-
4 months


Let us analyze the productivity


Productivity = output/input resources


In SW output is considered as LOC


Input resources is effort
-

person months; overhead cost modeled
in rate for person month


Though not perfect, some productivity measure is needed, as
project has to keep it high

Software …

SOFTWARE ENGINEERING

11


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

Software…

SOFTWARE ENGINEERING

12


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?


Software (IEEE): collection of programs, procedures,
rules, and associated documentation and data


Software…

SOFTWARE ENGINEERING

13


Student


Developer is the user


bugs are tolerable


UI not important


No documentation


Industrial Strength


Others are the users


bugs not tolerated


UI v. imp. issue


Documents needed for the
user as well as for the
organization and the project

Software…

SOFTWARE ENGINEERING

14


Student


SW not in critical use


Reliability, robustness not
important


No investment


Don’t care about portability


Industrial Strength


Supports important functions
/ business


Reliability , robustness are
very important


Heavy investment


Portability is a key issue here


Industrial strength software

SOFTWARE ENGINEERING

15


Student programs for a problem & industrial strength
software are two different things


Key difference is in quality (including usability, reliability,
portability, etc.)


Brooks thumb
-
rule
: Industrial strength sw costs 10 time
more than student sw


In this course, software means industrial strength software


This software has some characteristics

Is Expensive

SOFTWARE ENGINEERING

16


Let us look at costs involved


Productivity = Appx 1000 LOC/PM


Cost = $3K to $10K/PM


Cost per LOC = $5 to $15


I.e, each line of delivered code costs many $s


A simple application for a business may have 20KLOC to
50KLOC


Cost = $100K to $2.25Million


Can easily run on $10K
-
$20K hardware


So
HW costs in an IT solution are small as compared to SW
costs
.

Requires tight Schedule

17


Business requirements today demand short delivery times
for software


In the past, software products have often failed to be
completed in time


Along with cost, cycle time is a fundamental driving
force

18



That

quality,

cost,

and

schedule

are

the

main

forces

that

drive

a

(industrial

strength)

software

project
.



How

cost

and

productivity

are

defined

and

measured

for

such

a

project,

and

how

quality

of

software

is

characterized

and

measured
.



That

large

scale

and

change

are

important

attributes

of

the

problem

domain

and

solution

approaches

have

to

handle

them
.

Cost, Schedule and Quality

Productivity


for cost and schedule

SOFTWARE ENGINEERING

19


An industrial strength software project is driven by
cost

and
schedule


Both can be modeled by productivity, measured in terms
of output per unit effort (e.g. LOC per person month)


Higher productivity leads to lower cost


Higher productivity leads to lower cycle time


Hence, for projects (to deliver software),
quality

and
productivity

are basic drivers

Quality

SOFTWARE ENGINEERING

20


Along with productivity, quality is the other major driving
factor


Developing high Q sw is a basic goal


Quality of sw is harder to define

Quality


ISO standard

SOFTWARE ENGINEERING

21

Quality


ISO std…

SOFTWARE ENGINEERING

22


ISO std has six attributes


Functionality



The capability to provide functions which meet stated
and implied needs when the software is used.


Reliability


The capability to provide failure
-
free service.


Usability


The capability to be understood, learned, and used.


Efficiency


The capability to provide appropriate performance
relative to the amount of resources used.

Quality


ISO std…

SOFTWARE ENGINEERING

23


ISO std has six attributes


Maintainability


The capability to be modified for purposes of making corrections,
improvements, or adaptation.


Portability


The capability to be adapted for different specified environments
without applying actions or means other than those provided for
this purpose in the product.

Quality…

SOFTWARE ENGINEERING

24


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

Quality…

SOFTWARE ENGINEERING

25


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!

Quality


Maintainability

SOFTWARE ENGINEERING

26


Once sw delivered, it enters the maintenance phase, in
which


Residual errors are fixed


this is
corrective maintenance


Upgrades and environment changes are done


this is
adaptive
maintenance


Maintenance can consume more effort than development

over the life of the software (can even be 20:80 ratio!)


Hence maintainability is another quality attribute of
great interest

Quality and Productivity

SOFTWARE ENGINEERING

27


Hence, quality and productivity (Q&P) are the basic drivers
in a sw project


The aim of most methodologies is to deliver software with a
high Q&P


Besides the need to achieve high Q&P there are some other
needs

Change

SOFTWARE ENGINEERING

28


Only constant in business is change!


Requirements change, even while the project is in progress


In a project, up to 40% of development effort may go in
implementing changes



Practices used for developing software
must accommodate
change

Scale

SOFTWARE ENGINEERING

29


Most industrial strength software tend to be large and
complex


Methods for solving small problems do not often scale up for
large problems


Two clear dimensions in a project


engineering


project management


For small, both can be done informally, for large both have to
be formalized

Scale…

SOFTWARE ENGINEERING

30

Scale…

SOFTWARE ENGINEERING

31


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

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++

SOFTWARE ENGINEERING

32

Scale…

SOFTWARE ENGINEERING

33


As industry strength software tends to be large, hence
methods used for building these must be able to scale up



For much of the discussion, we will high
Q&P

as the basic
objective

Summary

SOFTWARE ENGINEERING

34


The problem domain for SE is industrial strength
software


SE aims to provide methods for systematically
developing (industrial strength) software


Besides developing software the goal is to achieve high
quality and productivity (Q&P)


Methods used
must

accommodate changes, and
must

be
able to handle large problems