You are on page 1of 57




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?

What this course will give ?

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



This chapter includes

2. 3.

Problem domain (industrial strength software) The software Engineering Challenges The software Engineering Approach




 

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

Software …      For students :The productivity is 2. 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 6 .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.

Industrial strength software are meant to solve some problems of clients or users SOFTWARE ENGINEERING 7 .Contd. rules.    Software (IEEE): collection of programs.. 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. procedures. and problems in software leads to significant direct or indirect loss.

software means industrial strength software What is the difference between a student program and industrial strength sw for the same problem? SOFTWARE ENGINEERING 8 . and in this course.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.

issue Documents needed for the user as well as for the organization and the project SOFTWARE ENGINEERING 9 . imp.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.

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

fault-tolerance.)    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. portability. backup. reliability.Industrial strength software Characteristics:   Student programs for a problem & industrial strength software are two different things Key difference is in quality (including usability. etc. following of stds etc increase the size for the same functionality SOFTWARE ENGINEERING 11 .

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 SOFTWARE ENGINEERING 12 .Contd..   If 1/5th productivity.

e. each line of delivered code costs about $20. SOFTWARE ENGINEERING 13 .Software is Expensive  Let us look at costs involved     Productivity = 500 LOC/PM Cost to the company = $10K/PM Cost per LOC = $20 I.  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.

  In 50s . HW:SW :: 20:80 Importance of optimizing HW is not much More important to optimize SW Now a days. SW is very expensive    . cost of software has become the dominant factor in the industry as compared to software SOFTWARE ENGINEERING 14  So . HW:SW :: 80:20 In 80s .Software is Expensive…  The HW/SW ratio for a computer system has shown a reversal from the early years.

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   SOFTWARE ENGINEERING 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 SOFTWARE ENGINEERING 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 SOFTWARE ENGINEERING 17 .

Removing of errors causes changes in the software. Corrective maintenance 2.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. Adaptive maintenance SOFTWARE ENGINEERING 18 . Even without bugs. So software need to be maintained Two types of maintenances 1. software frequently undergoes change due to upgradation and environment changes.

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)   SOFTWARE ENGINEERING 19 .Contd. Removing of errors or bugs leads to changes in the software .

etc SOFTWARE ENGINEERING 20 ..Contd..  Rework: Clients frequently discover additional requirements which they had not specified earlier -> requirements get changed ->leads to rework -> design changes -> coding….

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 21 .


Scale 2.Consistency & Repeatability 4.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.Change SOFTWARE ENGINEERING 23 .Quality & Productivity (Q & P) 3.

schedule and quality SOFTWARE ENGINEERING 24 . for large both have to be formalized For large projects the methods that are followed should be able to control cost.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.


must use different techniques and models Management will become critical SOFTWARE ENGINEERING 26 .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.

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 SOFTWARE ENGINEERING 27 .

000 KLOC 40. C++ 28 . yacc C. c++ C. sh Appache Linux Windows XP 100 KLOC 30. sh C.Scale: Examples software Gcc Perl size 980KLOC 320 KLOC language C. C++. perl.000 KLOC SOFTWARE ENGINEERING C.

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 SOFTWARE ENGINEERING 29 .Productivity     An engg project driven by cost and schedule In sw. cost is mainly manpower cost.

cost is lower If P is higher.Contd.   Schedule is in months/weeks – very important in business context Productivity capture both of these     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 SOFTWARE ENGINEERING 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 SOFTWARE ENGINEERING 31 .

Quality… Two important things about quality are :  Q has multiple dimensions. usability may be more important  Reliability is generally considered as the main Q criterion  Unreliable projects have more defects  Quality depends on No. Multiple dimensions mean that it is not easy to reduce Q to a single number  Concept of Q is project specific  For some. of defects delivered / Size  Current practice in SE is to reduce defects density less than 1 def / KLOC  What is a defect? Project specific! SOFTWARE ENGINEERING 32 . reliability is most important  For others.

Quality – ISO standard SOFTWARE ENGINEERING 33 .

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

Quality…   Functionality : The capability to provide functions which meet stated & implied needs when the software is used. Reliability depends on Probability of failure   hard to measure approximated by no. Reliability : Capability to maintain a specified level of performance. of defects in software SOFTWARE ENGINEERING 35 .

Maintainability: capability to be modified for purpose of making corrections. learnability. operability) Efficiency: Capability to provide appropriate performance relative to the amount of resources used.Contd. improvements or adaptation Portability : Capability to be adapted for different specified environments without changing the software SOFTWARE ENGINEERING 36 . learned and used (understandability..     Usability : Capability to be understood.

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 SOFTWARE ENGINEERING 37 .

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 SOFTWARE ENGINEERING 38 .Contd..

Approaches that can produce high quality software at high productivity but cannot accept and accommodate change are of little use. SOFTWARE ENGINEERING 39 . SE practices must accommodate change.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.

processes. and technology SOFTWARE ENGINEERING 40 . 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.Software Engg Approach  We understand the problem domain.


hence suitable processes will lead to high Q&P SOFTWARE ENGINEERING 42 .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.

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 43 .

architecture. design.SE Approach…   The development process used in SE is typically phased approach.  Requirements. coding. testing are key phases  This phased process has to be properly managed to achieve the objectives  Metrics and measurement important for this. Each phase focuses on some aspect. SOFTWARE ENGINEERING 44 .

Why have phases ?    To employ divide and conquer each phase handles a different part of the problem helps in continuous validation SOFTWARE ENGINEERING 45 .methodologies for that phase.Development Process    A set of phases and each phase being a sequence of steps Sequence of steps for a phase .

testing.Development Process   Commonly has these activities: Requirements analysis. delivery Different models perform them in different manner SOFTWARE ENGINEERING 46 . design. coding.

not “ how “. as needs often understood.Requirement Analysis       To understand state the problem precisely Forms the basis of agreement between user and developer specifies “ what “ . Requirement specifications of even medium systems can be many hundreds of pages Output is the sw req spec (SRS) document SOFTWARE ENGINEERING 47 . Not an easy task.

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 SOFTWARE ENGINEERING 48 .

Output is code SOFTWARE ENGINEERING 49 . Well written code can reduce the testing and maintenance effort.   The coding phase affects both testing and maintenance.  Code should be simple and readable.Coding   Converts design into code in specific language Goal: Implement the design with simple and easy to understand code.

has to be properly planned and executed. and the final tested (hopefully reliable) code SOFTWARE ENGINEERING 50 . Outputs are Test plans/results.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.

Design Coding Testing - 10-20% 10-20% 20-30% 30-50%  Coding is not the most expensive. SOFTWARE ENGINEERING 51 .Effort Distribution  Distribution of effort :     Req.

16% Job communication . Writing programs is a small part of their lives.13% Reading programs and manuals . SOFTWARE ENGINEERING 52 .39%   Programmers spend more time in reading programs than in writing them.32% Others .Distribution of effort…  How programmers spend their time     Writing programs .

SOFTWARE ENGINEERING 53 .30% .Defects  Distribution of error occurrences by phase is    Req.20% .50%   Defects can be injected at any of the major phases. Design Coding . Cost of latency: Cost of defect removal increases exponentially with latency time.

Defects… Cost to fix Error ( log scale) Time   Cheapest way to detect and remove defects close to where it is injected. SOFTWARE ENGINEERING 54 . Hence must check for defects after every phase.

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

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 56 .Summary…   SE challenge is to produce a product with high Q&P with consistency.

---------End-------- SOFTWARE ENGINEERING 57 .