Lecture 3

1. Lecture 3

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

3. Scope and necessity of software engineering • 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

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

5. Abstraction

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

7. Decomposition

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

9. Future of Software Engineering • Microsoft, IBM • Any Commercial Software • App Development • Apple Store • Android • Two Tier Software Engineering

10. 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 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 ENGINEERING

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

12. 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? • Software (IEEE): collection of programs, procedures, rules, and associated documentation and data SOFTWARE ENGINEERING

13. Software… • 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 ENGINEERING

14. Software… • 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 SOFTWARE ENGINEERING

15. 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.) • 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 SOFTWARE ENGINEERING

16. Is Expensive • 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. SOFTWARE ENGINEERING

17. Requires tight Schedule • 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. Cost, Schedule and Quality • 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.

19. Productivity – for cost and schedule • 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 SOFTWARE ENGINEERING

20. Quality • 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 SOFTWARE ENGINEERING

21. Quality – ISO standard SOFTWARE ENGINEERING

22. Quality – ISO std… • 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. SOFTWARE ENGINEERING

23. Quality – ISO std… • 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. SOFTWARE ENGINEERING

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

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

26. Quality – Maintainability • 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 SOFTWARE ENGINEERING

27. Quality and Productivity • 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 SOFTWARE ENGINEERING

28. Change • 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 SOFTWARE ENGINEERING

29. Scale • 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 SOFTWARE ENGINEERING

30. Scale… SOFTWARE ENGINEERING

31. Scale… • An illustration of issue of scale is counting the number of people in a roomvstaking 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

32. Scale: Examples SOFTWARE ENGINEERING

33. Scale… • 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 SOFTWARE ENGINEERING

34. Summary • 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 SOFTWARE ENGINEERING