Software Engineering 1 Software Software is 1 instructions

Software Engineering 1

Software · Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs 2

Software Characteristics · 1. Software is developed or engineered, it is not manufactured in the classical sense. · 2. Software doesn't "wear out. " 3

Failure curve for hardware 4

Failure curve for hardware · Figure 1. 1 depicts failure rate as a function of time for hardware. The relationship, often called the "bathtub curve, " indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some period of time. · As time passes, however, the failure rate rises again as hardware components suffer from the cumulative affects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out. 5

Failure curve for software 6

Failure curve for software · Software is not susceptible to the environmental problems that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the “idealized curve” shown in Figure 1. 2. Undiscovered defects will cause high failure rates early in the life of a program. · However, these are corrected (ideally, without introducing other errors) and the curve flattens as shown. · software doesn't wear out. But it does deteriorate! 7

Failure curve for software · This seeming contradiction can best be explained by considering the “actual curve” shown in Figure 1. 2. During its life, software will undergo change (maintenance). · As changes are made, it is likely that some new defects will be introduced, causing the failure rate curve to spike as shown in Figure 1. 2. · Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. · Slowly, the minimum failure rate level begins to rise— the software is deteriorating due to change. 8

Failure curve for software · Another aspect of wear illustrates the difference between hardware and software. · When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. · Therefore, software maintenance involves considerably more complexity than hardware maintenance. 9

Software Applications · Software may be applied in any situation for which a pre specified set of procedural steps (i. e. , an algorithm) has been defined. · System software is a collection of programs written to service other programs. Some system software (e. g. , compilers, editors, and file management utilities) 10

Software Applications · Real-time software. Software that monitors/analyzes/controls realworld events as they occur is called real time. · Business software. Business information processing is the largest single software application area. e. g: payroll, accounts receivable/payable, inventory. 11

Software Applications · · Engineering and scientific software Embedded software Personal computer software Web-based software 12

Software Engineering · Engineering is the analysis, design, construction, verification, and management of technical (or social) entities. · Regardless of the entity to be engineered, the following questions must be asked answered: · • What is the problem to be solved? · · • What characteristics of the entity are used to solve the problem? How will the entity (and the solution) be realized? • How will the entity be constructed? • What approach will be used to uncover errors that were made in the design and construction of the entity? 13

What is Software Engineering? · Engineering approach to develop software. - Building Construction Analogy. · Systematic collection of past experience: - techniques, - methodologies, - guidelines. 14

Engineering Practice · Heavy use of past experience: - Past experience is systematically arranged. · Theoretical justification and quantitative techniques provided. · Past experiences are thumb rules. · Tradeoff (selection) between alternatives based on cost, Maintainability and usability · approach to cost-effectiveness and economic concerns are addresed 15

Software Engineering · The IEEE definition: - Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. 16

A Layered Technology tools methods process model a “quality” focus Software Engineering 17

Technology Development Pattern Engineering Technology Esoteric Past Experience Art Craft Systematic Use of Past Experience and Scientific Basis Unorganized Use of Past Experience Time 18

Technology Development Pattern · every technology initially starts as art. Overtime it graduates to a craft and finally emerges as an engineering discipline. 19

Why Study Software Engineering? (1) · To acquire skills to develop large programs. - Exponential growth in complexity and difficulty level with size. - The ad hoc approach breaks down when size of software increases. 20

Why Study Software Engineering? (2) · Ability to solve complex programming problems: - How to break large projects into smaller and manageable parts? · Learn techniques of: - specification, design, interface development, testing, project management, etc. 21

Why Study Software Engineering? (3) · To acquire skills to be a better programmer: *Higher Productivity *Better Quality Programs 22

Software Crisis · Software products: - fail to meet user requirements. - frequently crash. - expensive. - difficult to alter, debug, and enhance. - often delivered late. - use resources non-optimally. 23

Software Crisis (cont. ) Hw cost Sw cost Year 1960 1999 Relative Cost of Hardware and Software 24

Factors contributing to the software crisis · Larger problems, · Lack of adequate training in software engineering, · Increasing skill shortage, · Low productivity improvements. 25

Programs versus Software Products · Usually small in size · Author himself is sole user · Single developer · Lacks proper user interface · Lacks proper documentation · Ad hoc development. · Large number of users · Team of developers · Well-designed interface · Well documented & user-manual prepared · Systematic development 26

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. · In case of a program, the programmer himself is the sole user but on the other hand, in case of a software product, most users are not involved with the development. · In case of a program, a single developer is involved but in case of a software product, a large number of developers are involved. 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. 27

Computer Systems Engineering · Computer systems engineering: - encompasses software engineering. · Many products require development of software as well as specific hardware to run it: - a coffee vending machine, -a mobile communication product, etc. 28

Computer Systems Engineering · The high-level problem: - deciding which tasks are to be solved by software - which ones by hardware. 29

Computer Systems Engineering (CONT. ) · Often, hardware and software developed together: - Hardware simulator is used during software development. · Integration of hardware and software. · Final system testing 30

Computer Systems Engineering (CONT. ) Feasibility Study Requirements Analysis and Specification Hardware Software Partitioning Hardware Development Software Development Integration and Testing Project Management 31

Emergence of Software Engineering · Early Computer Programming (1950 s): - Programs were being written in assembly language. - Programs were limited to about a few hundreds of lines of assembly code. 32

Early Computer Programming (50 s) · Every programmer developed his own style of writing programs: - according to his intuition (exploratory programming). 33

High-Level Language Programming (Early 60 s) · High-level languages such as FORTRAN, and COBOL were introduced: - This reduced software development efforts greatly. 34

High-Level Language Programming (Early 60 s) · Software development style was still exploratory. -Typical program sizes were limited to a few thousands of lines of source code. 35

Control Flow-Based Design (late 60 s) · Size and complexity of programs increased further: - exploratory programming style proved to be insufficient. · Programmers found: - very difficult to write cost-effective and correct programs. 36

Control Flow-Based Design (late 60 s) · Programmers found: - programs written by others very difficult to understand maintain. · To cope up with this problem, experienced programmers advised: ``Pay particular attention to the design of the program's control structure. '’ 37

Control Flow-Based Design (late 60 s) · A program's control structure indicates: - the sequence in which the program's instructions are executed. · To help design programs having good control structure: - flow charting technique was developed. 38

Control Flow-Based Design (late 60 s) · Using flow charting technique: -one can represent and design a program's control structure. -Usually one understands a program: *by mentally simulating the program's execution sequence. 39

Control Flow-Based Design (Late 60 s) · A program having a messy flow chart representation: -difficult to understand debug. 111 40

Control Flow-Based Design (Late 60 s) · It was found: - GO TO statements makes control structure of a program messy - GO TO statements alter the flow of control arbitrarily. - The need to restrict use of GO TO statements was recognized. 41

Control-flow Based Design (Late 60 s) · Everyone accepted: -it is possible to solve any programming problem without using GO TO statements. -This formed the basis of Structured Programming methodology. 42

Structured Programming · A program is called structured -when it uses only the following types of constructs: *sequence, *selection, *iteration 43

Structured programs · Unstructured control flows are avoided. · Consist of a neat set of modules. · Use single-entry, single-exit program constructs. 44

Structured programs · Structured programs are: -Easier to read and understand, -easier to maintain, -require less effort and time for development. 45

Structured Programming · Research experience shows: -programmers commit less number of errors *while using structured if-thenelse and do-while statements *compared to test-and-branch constructs. 46

Data Structure-Oriented Design (Early 70 s) · Soon it was discovered: -it is important to pay more attention to the design of data structures of a program *than to the design of its control structure. 47

Data Structure-Oriented Design (Early 70 s) · Techniques which emphasize designing the data structure: - derive program structure from it: *are called data structureoriented design techniques. 48

Object-Oriented Design (80 s) · Object-oriented technique: - an intuitively appealing design approach: - natural objects (such as employees, pay-roll-register, etc. ) occurring in a problem are first identified. 49

Object-Oriented Design (80 s) · Relationships among objects: - such as composition, reference, and inheritance are determined. · Each object essentially acts as - a data hiding (or data abstraction) entity. 50

Object-Oriented Design (80 s) · Object-Oriented Techniques have gained wide acceptance: - Simplicity - Reuse possibilities - Lower development time and cost - More robust code - Easy maintenance 51

Evolution of Design Techniques Object-Oriented Data flow-based Data structurebased Control flowbased Ad hoc 52

Exploratory style vs. modern style of software development · An important difference is that the exploratory software development style is based on error correction while the software engineering principles are primarily based on error prevention. · In the exploratory style, errors are detected only during the final product testing. In contrast, the modern practice of software development is to develop the software through several well-defined stages such as requirements specification, design, coding, testing, etc. , and attempts are made to detect and fix as many errors as possible in the same phase in which they occur. 53

Exploratory style vs. modern style of software development · In the exploratory style, coding was considered synonymous with software development. For instance, exploratory programming style believed in developing a working system as quickly as possible and then successively modifying it until it performed satisfactorily. · In the modern software development style, coding is regarded as only a small part of the overall software development activities. There are several development activities such as design and testing which typically require much more effort than coding. 54