Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 3.

Similar presentations


Presentation on theme: "Lecture 3."— Presentation transcript:

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… Industrial Strength Student 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 Student Developer is the user bugs are tolerable UI not important No documentation 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 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

32 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++ The computer program Yacc is a parser generator developed by Stephen C. Johnson at AT&T for the Unix operating system in The name is an acronym for "Yet Another Compiler Compiler." It generates a parser (the part of a compiler that tries to make syntactic sense of the source code) based on an analytic grammar written in a notation similar to BNF The GNU Compiler Collection includes front ends forC,C++, Objective-C, Fortran,Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...). GCC was originally written as the compiler for the GNU operating system. Perl is a high-level, general-purpose, interpreted, dynamic programming language. Linux is a Unix-like computer operating system assembled under the model of free and open source software development and distribution. The defining component of Linux is the Linux kernel, an operating system kernel first released 5 October 1991 by Linus Torvalds.[11][12] 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


Download ppt "Lecture 3."

Similar presentations


Ads by Google