Introduction to Software Engineering

Prepared By:
Pooja Thakar (Assistant Professor)
1

Understanding Software Software Crisis Software Myths Need and Objective of S/W Engineering Define S/W Engineering S/W Process Characteristics of S/W

S/W Applications
SDLC Models
2

Software = Program(s) + Documentation + Operating Procedures

PROGRAMS

DOCUMENTATION

OPERATING PROCEDURES

Components of Software

Formal Specifications Analysis / Specifications Context Diagram DFD Flowchart Design Documentation Manuals E R Diagrams

Source Code Listings Implementation Cross Reference Listings Test Data Testing Test Results
4

List of documentation manuals

System Overview User Manuals Operating Procedures Beginners Guide Tutorial Reference Guide

Installation Guide Operational Manuals System Administration Guide

List of operating procedure manuals

Software Crisis -1970

Computer Revolution Network Revolution Continuous decrease in price (Hardware)

Problems with Software

Still come Late Exceed Budget Full of residual faults

IBM Report says

31% projects cancelled 53% over run cost estimation (approx. 189% more) 94/100 projects restarts

Examples of Failures
Y2K Problem Patriot Missiles vs Scud Missiles Ariane- 5 space rocket
6

Managers and Technical persons are asked

Why does it take a long to get the program finished? Why are costs so high? Why cant we find errors before release? Why do we have difficulty in measuring progress of s/w development?

CASE Computer Aided S/W Engineering Tools may help a bit, no guarantee

Software Myths Practitioners

Myth Once we write the program and get it to work, our job is done Reality Objective is Good Quality Maintainable Program, no check on this, may cause problems later

Management
Myth We have books for s/w development Reality is it used?

Consumer
Myth A general statement of objective is sufficient. Details can be filled later. Reality more chances of s/w failure Myth Changes can be easily accommodated because s/w is flexible. Reality may increase cost and time needed many folds with no assurance of success

Myth If we get behind schedule, we can add more developer and catch up
Reality may increase time indeed, as time needed for educating newcomers

Other Myths
Computer provide greater reliability than the devices they replace. only if s/w is working as per expectation of the customer and is maintainable Testing s/w or provings/w correct can remove all errors testing shows presence of errors not the absence Reusing s/w increases safety not necessary S/w can work right the first time S/w can be designed thoroughly enough to avoid most integration problems S/w with more features is better s/w

List is ENDLESS
9

Need for S/W Engineering

Myths over Reality
Poor Quality of Software Increase cost and delay in delivery of software Change in ratio of h/w to s/w costs Increase in importance of maintenance Increase demand for s/w Demand for larger and more complex s/w systems

Objective of S/W Engineering

Produce good quality maintainable s/w, on time, within budget

Definition of S/W Engineering

A discipline whose aim is the production of quality software, software that is delivered on time, within budget and that satisfies its requirements Stephen Schach
10

Software Process
the way in which we produce software To compete in this competitive world need effective S/W development processes

Difficulties to improve s/w processes

1. 2. 3. Not Enough Time - unrealistic schedules, more demand Lack of Knowledge - developers are not familiar with industry best practices Wrong Motivations - forced implementation for quality standards

4.

Insufficient Commitment - dont want to work on long-term goals

Process improvement Initial State begins Productivity Do not quit here Learning Curve Improved Future State

Process improvement Learning Curve

11

Time

Comparison
S. No. 1 2 3 4 5 6 7 Constructing a bridge Problem Well understood Many samples (existing bridges ) Requirements do not change much Strength and stability can be calculated If collapse, detailed investigation Constructing experience 1000 of yrs. Materials and techniques change slowly Writing a program

12

Some Characteristics of Software

1. Software does not wear out
Hardware failure rate failure curve for software

actual failure rate for software

13

2. 3. 4.

Software is not manufactured its developed/ engineered Reusability of Components Software is Flexible

Software Applications

System s/w Engineering and Scientific s/w Web Based s/w AI s/w

Real Time s/w Embedded s/w

Business s/w Personal Computer s/w

14

Software Life Cycle Models (SDLC)

Build and Fix Model

The Waterfall Model

Prototyping Model Iterative Enhancement Model Evolutionary Development Model Spiral Model The Rapid Application Development Model
15

RAD

Build and Fix Model

Build

Fix

Adhoc approach
Two-phase model Work well on small programs (100-200 lines) No room for structured design

16

The Waterfall Model

Requirement Analysis and Specification
SRS

System and Software design

SDD

Most familiar Easy to understand Must have proper specified requirement

Implementation and Unit Testing Integration and System Testing Operation and Maintenance
17

Reinforce define before design and design before code

Must complete each phase before proceeding for next phase

Limitations of Waterfall Model

Real Projects rarely follow that the model proposes (unrealistic)
Often difficult for user to state all requirements explicitly The customer must have patience. User participation is late after requirement gathering phase Delaying the discovery of serious errors Does not incorporate any kind of risk management Not suitable for accommodating any change

Working version of system is not seen until late in projects life

Does not scale up well to large projects Blocking states some team members have to wait for others to complete their job

Should be used where the requirements and their implementation are well understood

18

Prototyping Model
Requirements
Quick Design

Implement
Customer Evaluation Design Implementation and Unit Testing Integration and System Testing Operation and Maintenance

Refinement of Requirements as per suggestions

Not accepted by Customer Accepted by Customer

Developed as per current available requirements Use this to refine the requirements

Help to remove uncertainties in requirements

User can have good idea of final product
19

Limitations of Prototyping Model

Prototype may be useable program but it is not suitable as final s/w product The development of a prototype might involve extra cost

Require extensive participation and involvement of customer, which is not always possible
Sometimes the first system build is barely useable, it may be too slow, too big, awkward in use. User may demand this quick fix model. May not be able to produce good quality product and then problem of maintainability.

The code for prototype is thrown. Thus act as input to waterfall model

20

Iterative Enhancement Model

Requirements Design Implementation & Unit Testing Integration & System Testing Operation (Install) Release I Design Implementation & Unit Testing Integration & System Testing Operation (Install) Release II Implementation & Unit Testing Integration & System Testing Operation (Install) Release III

Design

same phases as waterfall, but few restrictions Conducted in several cycles, useable product released at every cycle with additional functionality Does not deliver operational quality product at each release. Customer is able to do some useful work from first release

21

Evolutionary Development Model

Resembles iterative enhancement model

Requirements are implemented by category rather than by priority

It does not require a useable product at the end of each cycle

Should be used when it is not necessary to provide a minimal version want to implement new technology not well known

22

Still all these models do not deal with uncertainty well

Project risks are neglected No body is prepared, if some unforeseen happens

23

Spiral Model
Determine objectives alternatives, constraints

Evaluate alternatives, identify, resolve risks, develop prototypes

Planning

Risk Analysis

Assessment

Development
Develop, verify next-level product

Plan next phases

Proposed by Boehm in 1986

24

Spiral Model

25

Focus is identification of problems and the classification of these in different level of risks, so as to eliminate high-risk problems first Each phase is completed with a review by the concerned people Wide range of options to accommodate the good features of other life cycle models.

Incorporates s/w quality objectives

Eliminates errors at early stage

Limitations of Spiral Model

Lack of explicit process guidance in determining objectives, constraints, alternatives. Relying on risk assessment expertise Providing more flexibility than required for many applications

26

The Rapid Application Development Model

With active participation of users

Requirements Planning

User Description

Construction

Cut Over

Proposed by IBM in 1980s User involvement necessary from requirement phase to delivery Start with building rapid prototype and given to user for assessment, so quick initial views possible

Limitation Highly specialized and skilled developers are expected

27

Selection of Suitable Model is based on

Characteristics of Requirements Status of Development Team Involvement of Users Project Type and Associated Risk

28