0% found this document useful (0 votes)
34 views39 pages

Chapter 1

The document discusses the challenges of software engineering including scale, productivity, quality, and change. It explains that software engineering must provide systematic approaches to developing industrial-strength software that can scale to large problems, deliver high productivity, achieve high quality, and manage changes.

Uploaded by

mekinjemal999
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
34 views39 pages

Chapter 1

The document discusses the challenges of software engineering including scale, productivity, quality, and change. It explains that software engineering must provide systematic approaches to developing industrial-strength software that can scale to large problems, deliver high productivity, achieve high quality, and manage changes.

Uploaded by

mekinjemal999
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 39

Introduction

[email protected]

SOFTWARE ENGINEERING 1
This Course
 SE is unlike other CS topics
 OS , DBMS , Compilers etc talk about
specific types of software product
 SW Engg. focuses on general software
 Software Engineering is the systematic
approach to development, operation,
maintenance, and retirement of sw.
 Basic Q? of SW Engg.: How to develop
industrial-strength software?
SOFTWARE ENGINEERING 2
What this course will give ?
 Main objective: Give an idea of how industrial-
strength software gets developed
 At the end you should have the ability to plan,
execute, and manage small software projects
 Lectures will discuss how to perform different
tasks in a project
 In the project , the techniques will be applied
 Lectures will be a phase ahead of the project

SOFTWARE ENGINEERING 3
Project
 A group project with many people(~40)
 Two big groups (~40 people each) with 4
subgroups of ~10 people
 Approximately 10 hours per week per
student
 Will start from 2nd week and last till the
semester end
 Extra lectures in the start to kick-start
the project
SOFTWARE ENGINEERING 4
Evaluation and Grading
 Project will have a weight of 50%
 a poor project cannot get a good grade
 One mid sem exam (20%) and a final
exam(30%).
 Project – grade based on individual
contribution

SOFTWARE ENGINEERING 5
Software
 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 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
SOFTWARE ENGINEERING 6
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
SOFTWARE ENGINEERING 7
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
SOFTWARE ENGINEERING 8
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

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

SOFTWARE ENGINEERING 10
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
SOFTWARE ENGINEERING 11
Industrial strength software
 If 1/5th productivity, and increase in size by a
factor of 2, industrial strength software will
take 10 times effort
 Brooks thumb-rule: Industrial strength sw
costs 10 time more than student sw
 Domain of SW Engg: Industrial strength sw
 In SW Engg. and in this course, software
means industrial strength software

SOFTWARE ENGINEERING 12
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.
SOFTWARE ENGINEERING 13
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

SOFTWARE ENGINEERING 14
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

SOFTWARE ENGINEERING 15
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

SOFTWARE ENGINEERING 16
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, maintenace can cost more than
the development cost of sw
SOFTWARE ENGINEERING 17
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

SOFTWARE ENGINEERING 18
Basic Problem

SOFTWARE ENGINEERING 19
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, …

SOFTWARE ENGINEERING 20
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
SOFTWARE ENGINEERING 21
formalized
Scale…

SOFTWARE ENGINEERING 22
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
SOFTWARE ENGINEERING 23
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 24
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
SOFTWARE ENGINEERING 25
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

SOFTWARE ENGINEERING 26
Quality – ISO standard

SOFTWARE ENGINEERING 27
Quality – ISO std…
 ISO std has six attributes
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability

SOFTWARE ENGINEERING 28
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

SOFTWARE ENGINEERING 29
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!
SOFTWARE ENGINEERING 30
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
 Frameworks like ISO and CMM focus on this
aspect a lot

SOFTWARE ENGINEERING 31
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

SOFTWARE ENGINEERING 32
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

SOFTWARE ENGINEERING 33
Iron Triangle

SOFTWARE ENGINEERING 34
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

SOFTWARE ENGINEERING 35
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

SOFTWARE ENGINEERING 36
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

SOFTWARE ENGINEERING 37
Summary
 The problem domain for SE is industrial
strength software
 Software comprises programs,
documentation, and data
 SE aims to provide methods for
systematically developing SW
 Main goal – achieve high quality and
productivity (Q&P)

SOFTWARE ENGINEERING 38
Summary…
 Must have high Q&P with consistency,
under large scale and changes
 Basic approach of SE is to separate
process from products and focus on
process and managing the process

SOFTWARE ENGINEERING 39

You might also like