Download
1 / 54
E N D
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
Software Characteristics • 1. Software is developed or engineered, it is not manufactured in the classical sense. • 2. Software doesn't "wear out."
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.
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!
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.
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.
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. System software is a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities)
Software Applications • Real-time software. Software that monitors/analyzes/controls real-world 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.
Software Applications • Engineering and scientific software • Embedded software • Personal computer software • Web-based software
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 and 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?
What is Software Engineering? • Engineering approach to develop software. • Building Construction Analogy. • Systematic collection of past experience: • techniques, • methodologies, • guidelines.
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
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.
A Layered Technology tools methods process model a “quality” focus Software Engineering
Technology Development Pattern Engineering Technology Craft Esoteric Past Experience Systematic Use of Past Experience and Scientific Basis Unorganized Use of Past Experience Art Time
Technology Development Pattern • every technology initially starts as art. Overtime it graduates to a craft and finally emerges as an engineering discipline.
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.
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.
Why Study Software Engineering? (3) • To acquire skills to be a better programmer: • Higher Productivity • Better Quality Programs
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.
Software Crisis (cont.) Hw cost Sw cost Year 1960 1999 Relative Cost of Hardware and Software
Factors contributing to the software crisis • Larger problems, • Lack of adequate training in software engineering, • Increasing skill shortage, • Low productivity improvements.
Large Large number of users Team of developers Well-designed interface Well documented & user-manual prepared Systematic development 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.
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.
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.
Computer Systems Engineering • The high-level problem: • deciding which tasks are to be solved by software • which ones by hardware.
Computer Systems Engineering (CONT.) • Often, hardware and software are developed together: • Hardware simulator is used during software development. • Integration of hardware and software. • Final system testing
Computer Systems Engineering (CONT.) Feasibility Study Requirements Analysis and Specification Hardware Development Hardware Software Partitioning Software Development Integration and Testing Project Management
Emergence of Software Engineering • Early Computer Programming (1950s): • Programs were being written in assembly language. • Programs were limited to about a few hundreds of lines of assembly code.
Early Computer Programming (50s) • Every programmer developed his own style of writing programs: • according to his intuition (exploratory programming).
High-Level Language Programming (Early 60s) • High-level languages such as FORTRAN, and COBOL were introduced: • This reduced software development efforts greatly.
High-Level Language Programming (Early 60s) • Software development style was still exploratory. • Typical program sizes were limited to a few thousands of lines of source code.
Control Flow-Based Design (late 60s) • 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.
Control Flow-Based Design (late 60s) • Programmers found: • programs written by others very difficult to understand and maintain. • To cope up with this problem, experienced programmers advised: ``Pay particular attention to the design of the program's control structure.'’
Control Flow-Based Design (late 60s) • 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.
Control Flow-Based Design (late 60s) • 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.
Control Flow-Based Design (Late 60s) • A program having a messy flow chart representation: • difficult to understand and debug. 111
Control Flow-Based Design (Late 60s) • 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.
Control-flow Based Design (Late 60s) • Everyone accepted: • it is possible to solve any programming problem without using GO TO statements. • This formed the basis of Structured Programming methodology.
Structured Programming • A program is called structured • when it uses only the following types of constructs: • sequence, • selection, • iteration
Structured programs • Unstructured control flows are avoided. • Consist of a neat set of modules. • Use single-entry, single-exit program constructs.
Structured programs • Structured programs are: • Easier to read and understand, • easier to maintain, • require less effort and time for development.
Structured Programming • Research experience shows: • programmers commit less number of errors • while using structured if-then-else and do-while statements • compared to test-and-branch constructs.
Data Structure-Oriented Design (Early 70s) • 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.
Data Structure-Oriented Design (Early 70s) • Techniques which emphasize designing the data structure: • derive program structure from it: • are called data structure-oriented design techniques.
Object-Oriented Design (80s) • Object-oriented technique: • an intuitively appealing design approach: • natural objects (such as employees, pay-roll-register, etc.) occurring in a problem are first identified.
Object-Oriented Design (80s) • Relationships among objects: • such as composition, reference, and inheritance are determined. • Each object essentially acts as • a data hiding (or data abstraction) entity.
