1. Software Engineering

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

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

4. Failure curve for hardware

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

6. Failure curve for software

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

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

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

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

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

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

13. 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?

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

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

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

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

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

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

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

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

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

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

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

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

26. 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
Large number of users
Team of developers
Well-designed interface
Well documented & user-manual prepared
Systematic development

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

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

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

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

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

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

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

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

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

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

37. 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.'’

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

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

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

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

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

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

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

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

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

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

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

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

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

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

52. Evolution of Design Techniques
Object-Oriented
Data flow-based
Data structure- based
Control flow- based
Ad hoc

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

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