1-Intro 3 - 2 - 2012

Introduction
SOFTWARE ENGINEERING
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?
2
What this course will give ?
Main objective: Give an idea of how industrial-strength software gets developed
This chapter includes

1.
2. 3.
Problem domain (industrial strength software) The software Engineering Challenges The software Engineering Approach
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 Expert students : 2 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
5
Software
For students :The productivity is 2.5-5 KLOC/PM (5000 LOC/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
6
Contd..
Software (IEEE): collection of programs, procedures, rules, and associated documentation and data Industrial strength software is a software which solves some problems of users where organizations or business depend on the software, and problems in software leads to significant direct or indirect loss. Industrial strength software are meant to solve some problems of clients or users
7
Software
In a university a student system is built while the commercial org builds industrial strength sw Domain of SW Engg: Industrial strength sw In SW Engg. and in this course, software means industrial strength software What is the difference between a student program and industrial strength sw for the same problem?
Software
Student Developer is the user

Industrial Strength Others are the users

bugs are tolerable UI not important No documentation
bugs not tolerated UI v. imp. issue Documents needed for the user as well as for the organization and the project
Software

Student SW not in critical use Reliability, robustness not important No investment Dont care about portability
Industrial Strength Supports important functions / business Reliability , robustness are very important Heavy investment Portability is a key issue here
10
Industrial strength software Characteristics:
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 3050% 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
11
Contd..
If 1/5th productivity, and increase in size by a factor of 2, industrial strength software will take 10 times more effort than student SW Brooks thumb-rule: Industrial strength sw costs 10 time more than student sw
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.
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 Importance of optimizing HW is not much More important to optimize SW Now a days, cost of software has become the dominant factor in the industry as compared to software
14
So , SW is very expensive

Late & Unreliable
20-25% of SW projects never complete
Because after some time they realize that the final cost will be much higher
budget & cost out of control There are consulting companies to help them to control
Many companies report runaways

15
Unreliable
Software become unreliable : the software does not do what it is supposed to do or does something it is not supposed to do One defense survey found that 70% of the equipment problems are due to SW Many examples of software failures : Failure of Apollo flight was due to software failure Many banks have lost millions of dollars due to inaccuracies and other problems in their software
16
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
17
Maintenance

Once sw delivered, it enters maintenance phase Why is maintenance needed for sw when it does not wear with age? There are often some residual errors remaining in the system that must be removed. Removing of errors causes changes in the software. Even without bugs, software frequently undergoes change due to upgradation and environment changes. So software need to be maintained Two types of maintenances 1. Corrective maintenance
2. Adaptive maintenance
18
Contd..
Removing of errors or bugs leads to changes in the software - requires corrective maintenance Upgrades and environment changes adaptive maintenance Over sw life, maintenance can cost more than the development cost of sw(30-40% of development cost)
19
Contd..
Rework: Clients frequently discover additional requirements which they had not specified earlier -> requirements get changed ->leads to rework -> design changes -> coding..etc
20
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
21
Basic Problem
22
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 1.Scale 2.Quality & Productivity (Q & P) 3.Consistency & Repeatability 4.Change
23
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 Engineering methods Project management
Two clear dimensions in this

For small projects, engineering capability and project management requirements are low For small, both can be informal or ad-hoc, for large both have to be formalized For large projects the methods that are followed should be able to control cost, schedule and quality
24
Scale
25
Scale(Example)
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
26
Contd..
There is no clear definition between small and large projects Small projects : size is less than 10 KLOC Medium projects :size is less than 100KLOC & more than 10KLOC Large projects : Size is many million LOC
27
Scale: Examples
software Gcc Perl size 980KLOC 320 KLOC language C, C++, yacc C, perl, sh
Appache Linux
Windows XP
100 KLOC 30,000 KLOC

40,000 KLOC
C, sh C, c++
C, C++
28
Productivity
An engg project driven by cost and schedule In sw, cost is mainly manpower cost, hence measured in person-months Person-month(total number of person months spent on the project Total cost = person-month x averge cost+ overhead costs
29
Contd..
Schedule is in months/weeks very important in business context Productivity capture both of these

If P is higher, cost is lower If P is higher, time taken can be lesser A team of higher productivity will finish the job fast A team of higher productivity requires fewer person-months
Approaches used by SE must deliver high Productivity

30
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
31
Quality
Two important things about quality are : Q has multiple dimensions. Multiple dimensions mean that it is 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 as the main Q criterion Unreliable projects have more defects Quality depends on No. of defects delivered / Size Current practice in SE is to reduce defects density less than 1 def / KLOC What is a defect? Project specific!
32
Quality ISO standard
33
Quality ISO std
ISO std has six attributes
Functionality Reliability Usability Efficiency Maintainability Portability
34
Quality
Functionality : The capability to provide functions which meet stated & implied needs when the software is used. Reliability : Capability to maintain a specified level of performance. Reliability depends on Probability of failure
hard to measure approximated by no. of defects in software
35
Contd..
Usability : Capability to be understood, learned and used (understandability, learnability, operability) Efficiency: Capability to provide appropriate performance relative to the amount of resources used. Maintainability: capability to be modified for purpose of making corrections, improvements or adaptation Portability : Capability to be adapted for different specified environments without changing the software
36
Consistency and repeatability

Key challenge is to have a consistency in quality and productivity how to ensure that success can be repeated ? Use methods that can consistently produce high Q sw with high Productivity to deliver high Q&P consistently across projects Frameworks like ISO and CMM(Capability Maturity Model) focus on this aspect a lot
37
Contd..
Why consistency required? Helps to predict the outcome of a project with reasonable accuracy To improve processes to produce higher quality products and to improve its productivity cost of projects can be estimated correctly
38
Change
Software must change to support the changing business needs Software need to be changed/modified due to the change in requirements of clients or to correct bugs from the software. SE practices must accommodate change. Approaches that can produce high quality software at high productivity but cannot accept and accommodate change are of little use.
39
Software Engg 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
40
Iron Triangle
41
SE Approach
SE focuses mostly on processes for achieving the goals Systematic approach is really about processes being used In SE process are different from product (i.e sw) Process largely determines Q&P, hence suitable processes will lead to high Q&P
42
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
43
SE Approach
The development process used in SE is typically phased approach. Each phase focuses 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.
44
Development Process
A set of phases and each phase being a sequence of steps Sequence of steps for a phase - methodologies for that phase. Why have phases ?

To employ divide and conquer each phase handles a different part of the problem helps in continuous validation
45
Development Process
Commonly has these activities: Requirements analysis, design, coding, testing, delivery Different models perform them in different manner
46
Requirement Analysis
To understand state the problem precisely Forms the basis of agreement between user and developer specifies what , not how . Not an easy task, as needs often understood. Requirement specifications of even medium systems can be many hundreds of pages Output is the sw req spec (SRS) document
47
Design
A major step in moving from problem domain to solution domain; three main tasks
Architecture design components and connectors that should be there in the system High level design modules and data structures needed to implement the architecture Detailed design logic of modules
Most methodologies focus on architecture or high level design Outputs are arch/des/logic design docs
48
Coding

Converts design into code in specific language Goal: Implement the design with simple and easy to understand code.
Code should be simple and readable.
The coding phase affects both testing and maintenance. Well written code can reduce the testing and maintenance effort. Output is code
49
Testing
Defects in each phase need to be discovered and removed to achieve high quality Testing plays this important role Goal: Identify most of defects Is a very expensive task; has to be properly planned and executed. Outputs are Test plans/results, and the final tested (hopefully reliable) code
50
Effort Distribution
Distribution of effort :

Req. Design Coding Testing
10-20% 10-20% 20-30% 30-50%
Coding is not the most expensive.
51
Distribution of effort
How programmers spend their time

Writing programs - 13% Reading programs and manuals - 16% Job communication - 32% Others - 39%
Programmers spend more time in reading programs than in writing them. Writing programs is a small part of their lives.
52
Defects
Distribution of error occurrences by phase is

Req. Design Coding
- 20% - 30% - 50%
Defects can be injected at any of the major phases. Cost of latency: Cost of defect removal increases exponentially with latency time.
53
Defects
Cost to fix Error ( log scale) Time
Cheapest way to detect and remove defects close to where it is injected. Hence must check for defects after every phase.
54
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)
55
Summary
SE challenge is to produce a product with 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
56
---------End--------
57

1-Intro 3 - 2 - 2012

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1-Intro 3 - 2 - 2012

Uploaded by

Copyright:

Available Formats

Introduction

SE is unlike other CS topics

What this course will give ?

Main objective: Give an idea of how industrial-strength software gets developed

This chapter includes

Industrial Strength Others are the users

bugs are tolerable UI not important No documentation

Industrial strength software Characteristics:

Let us look at costs involved

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

Late & Unreliable

20-25% of SW projects never complete

Many companies report runaways

Software is Industrial strength sw

SE must deal with problem of scale

Two clear dimensions in this

100 KLOC 30,000 KLOC

Approaches used by SE must deliver high Productivity

Quality ISO standard

Quality ISO std

ISO std has six attributes

Functionality Reliability Usability Efficiency Maintainability Portability

hard to measure approximated by no. of defects in software

Consistency and repeatability

Software Engg Approach

We understand the problem domain, the factors that drive SE

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.

Code should be simple and readable.

Req. Design Coding Testing

10-20% 10-20% 20-30% 30-50%

Coding is not the most expensive.

How programmers spend their time

Distribution of error occurrences by phase is

Req. Design Coding

- 20% - 30% - 50%

You might also like