Software Engineering by Pankaj Jalote

Introduction to SE

1. Introduction The Problem Domain SE Challenges SE Approaches

2. Software IEEE defines Software as a collection of programs, procedures, rules, and associated documentation and data

3. SOFTWARE ENGINEERING IEEE defines Software Engineering as: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software ; that is the application of engineering to develop software. Proposed by Fritz Bauer Software Engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficient ly on real machines.

4. Software… Students build: Student software Industry builds: Industrial Strength Software System What is the difference between a student software and industrial strength software for the same problem?

5. S.NO. STUDENT SOFTWARE SYSTEM INDUSTRIAL STRENGTH SOFTWARE 1) Developed for demonstration purpose only Developed to solve real problem of any organization or client who pays for it 2) Used by the developer by himself or herself Used by clients organization for their business 3) No importance given to the functionalities of software. Main focus is on output only Much importance given to the correct function of the system 4) Software not designed with quality attributes like portability, robustness, reliability and usability in mind Software should be designed with quality attributes like reliability , user-friendliness, etc. 5) No importance given for testing. If error occurs, users fix them when they are found . Bugs are tolerable Software Testing is done to ensure the system is working properly. Because malfunction (bug or defect or failure) leads to financial or business loss, inconvenience to users, loss of property or life. Bugs are not tolerable

6. Software developed as single process (monolithic architecture). Hard to fix the errors in the early stage It uses modular approach. D evelopment be broken into stages. Each stage is evaluated and reviewed to remove bugs earlier No documentation since it is for personal use Documents needed for the user as well as for the organization and the project Only 5% of the total effort spent in testing Testing takes 30 to 50% of the total effort. Less Effort. Productivity is high Requires much effort that lowers the productivity No Investment Heavy Investment

7. Industrial Strength Software Student programs != industrial strength software 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 all increase the size for the same functionality

8. Industrial strength software If 1/5 th 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 In this course, software == industrial strength software

9. Software is Expensive Software development is labor-intensive Cost of producing software = Man power employed + cost of developing software measured in terms of person-month Productivity is measured in terms of LOC or KLOC Rough cost estimate… Productivity = 500 LOC/PM Cost to the company = $10K/PM Cost per LOC = $20 So 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 <<< SW costs.

10. Software is Expensive… The HW/SW ratio for a computer system has shown a reversal from the early years. In 50’s , HW:SW :: 80:20 In 80’s , HW:SW :: 20:80 So , SW is very expensive Importance of optimizing HW is not much More important to optimize SW

11. Late & Unreliable Software development remains a weak area: Problem 1: Software project delivered late or over budget  runaway Problem 2: Lack of reliability – Unreliability leads to failure Software does not do what it is supposed to do? Software does something not supposed to do. 70 % of the equipment failures are due to software problems Failure of Apollo flight Failure of missile Many banks lost millions of dollars due to inaccuracies

12. Problem 3: Hardware wears out due to age. Software never wears out due to age but deteriorate (weaken) Failures are not due to aging related problems Failures occur due to bugs or errors that get introduced during development The bug that causes a failure typically exists from start, only manifests later

13. Maintenance & Rework Once SW delivered or deployed, it enters Maintenance phase What is Maintenance? Changes done after development Modification done to the existing software Not a part of development Maintenance Activities: Correct residual errors requires corrective maintenance Environment changes – adaptive maintenance Upgrades & enhancing features requires enhanced maintenance

14. Corrective Maintenance Software system developed with residual errors (difference between observed & predicted value) Remove errors that leads to change Enhanced Maintenance Even without errors, software needs to be changed Must be upgraded or enhanced by adding more features and provide more services that leads to change Adaptive Maintenance Environment in which it operates changes. Change of environment  change in software Change in software -> changes the environment -> requires change ---  law of software evolution

15. What’s happen in Maintenance Phase? Based on the existing software, it creates new software system Understand the existing s/w before modification Modifier should understood the effects of change before modification Modification leads to undesirable side effects -> regression testing should be done to test the old test cases so that no new errors have been introduced Making the changes  code and document Testing the new parts & retest the old parts that were changed 80:20, 70”30, 60:40 ->suggested maintenance-to-development ratio

16. Rework Biggest problem in large and complex system development is: rework To avoid rework: State/ specify the requirements, functionalities, interfaces and constraints before development What leads to rework? Requirement is not understood completely and clearly before development leads to rework Clients needs additional requirements during development – rework Large and complex systems take long years to complete. During that time, clients needs change of requirements 30 – 40% of effort spent on rework 30-40% of development cost spent on rework

17. The Software Challenge

18. Basic Problem

19. SE Challenges The problem of producing software to satisfy user needs drives the approaches used in SE What other factors that drive the selection of a SE approach? Scale, Productivity, Quality, Consistency, Rate of change, …

20. 1) 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 Scales – small, medium, large, very large SE methods must be scalable Two clear dimensions in this Engineering methods Project management For small, both can be informal or ad-hoc, for large both have to be formalized

21. 1) Scale…

22. 1) 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

23. 1) Scale: Examples Size Software Languages 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++

24. 2) Productivity An engg project driven by cost and schedule Cost: In sw cost is mainly manpower cost, hence measured in person-months Schedule is in months/weeks – very important in business context In Biz context Cost and Schedule can not be separated SE must serve the Biz, NOT the other way around

25. 2) Productivity Productivity capture both Cost and Schedule If P is higher, cost is lower If P is higher, time taken can be lesser Approaches used by SE must deliver high Productivity

26. 3) Quality Quality is the other major driving factor Developing high Quality SW is a basic goal Quality of SW is harder to define Approaches used should produce a high Quality software SE driven by 3 major factors: Cost, Schedule and quality

27. 3) Quality – ISO standard ISO standard has six attributes Functionality Reliability Usability Efficiency Maintainability Portability

28. Functionality (suitability, accuracy, security,…) The capability to provide functions which meet stated and implied needs when the software is used Reliability (trust-worthy) The capability to maintain a specified level of performance Usability (understandability, learn ability, operatability) The capability to be understood, learned and used Efficiency (capability, competence,..) The capability to provide appropriate performance relative to the amount of resources used Maintainability (changeability, testability, stability,…) The capability to be modified for purposes of making corrections, improvements or adaptations Portability (independence, strong,…) The capability to be adapted for different specified environments

29. 3) 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

30. 3) 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!

31. 4) Consistency and repeatability Sometimes a group can deliver one good software system, but not a second Key SE challenge: how to ensure that success can be repeated ? SE wants methods that can consistently produce high Quality SW with high Productivity A SW org, wants to deliver high Q&P consistently across projects Frameworks like Inter. Org. for Standardization (ISO) and Capability Maturity Model (CMM) focus on this aspect

32. 5) Rate of 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 value

33. Goals of Industrial Strength SE Consistently develop SW with high Q&P for large scale problems, under change Q&P are the basic objectives to be achieved Q&P governed by people, processes, and technology

34. Iron Triangle

35. Iron Triangle What happens when you break the triangle? 1) The project gets canceled .    15% of projects are cancelled before they deliver a system.  A study of 1,027 IT projects  cited scope management related to serial practices as the single largest contributing factor to project failure in 82% of the projects and was given a overall weighted failure influence of 25%.   www.ambysoft.com/essays/brokenTriangle.htm

36. Iron Triangle What happens when you break the triangle? 2) The Project is deliver late, over budget, or both According to the  Chaos Report  51% of projects are challenged (severely over budget and/or late), with an average cost overrun of 43%.    www.ambysoft.com/essays/brokenTriangle.htm

37. Iron Triangle What happens when you break the triangle? 3) The Project delivers poor quality software .  When development teams are forced to deliver more functionality than they have time or resources for, they are often motivated to take short cuts which inevitably result in poor quality.   www.ambysoft.com/essays/brokenTriangle.htm

38. Iron Triangle What happens when you break the triangle? 4) The project under delivers .  The team fails to deliver all of the required functionality.     www.ambysoft.com/essays/brokenTriangle.htm

39. Iron Triangle… What to do about it? Recognize that the iron triangle must be respected.   So Vary the Scope Vary the Schedule Vary the Resources Vary two or more factors   www.ambysoft.com/essays/brokenTriangle.htm

40. SE Methodology SE focuses mostly on processes for achieving the goals Process must be systematic SE separates process for developing sw from the developed product (i.e the sw) Premise: Process largely determines Q&P, hence suitable processes will lead to high Q&P

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

42. SE Methodology… 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

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

44. Summary… Must have high Q&P with consistency in the context of large scale and frequent changes Basic approach of SE is to separate process from products and focus on process and managing the process