Introduction To Software Engineering: Prepared by

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

Introduction To Software Engineering: Prepared by

Uploaded by

Copyright:

Available Formats

Introduction To Software Engineering: Prepared by

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Software Engineering: Prepared by

Uploaded by

Copyright:

Available Formats

Introduction to Software Engineering

Software = Program(s) + Documentation + Operating Procedures

List of documentation manuals

Installation Guide Operational Manuals System Administration Guide

List of operating procedure manuals

Software Crisis -1970

Problems with Software

Still come Late Exceed Budget Full of residual faults

IBM Report says

Managers and Technical persons are asked

Software Myths Practitioners

Need for S/W Engineering

Objective of S/W Engineering

Definition of S/W Engineering

Difficulties to improve s/w processes

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

Process improvement Learning Curve

Some Characteristics of Software

actual failure rate for software

Real Time s/w Embedded s/w

Business s/w Personal Computer s/w

Software Life Cycle Models (SDLC)

The Waterfall Model

Build and Fix Model

The Waterfall Model

System and Software design

Most familiar Easy to understand Must have proper specified requirement

Reinforce define before design and design before code

Limitations of Waterfall Model

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

Refinement of Requirements as per suggestions

Not accepted by Customer Accepted by Customer

Help to remove uncertainties in requirements

Limitations of Prototyping Model

Iterative Enhancement Model

Evolutionary Development Model

Requirements are implemented by category rather than by priority

Still all these models do not deal with uncertainty well

Evaluate alternatives, identify, resolve risks, develop prototypes

Plan next phases

Proposed by Boehm in 1986

Incorporates s/w quality objectives

Limitations of Spiral Model

The Rapid Application Development Model

Limitation Highly specialized and skilled developers are expected

Selection of Suitable Model is based on

You might also like