SOFTWARE ENGINEERING

By
SATYANANDARAM N

CSE Dept Software Engineering: Introduction 1

Objectives
 What is Software Engineering?

 Why Software Engineering?

 How to do Software Engineering?

CSE Dept Software Engineering: Introduction 2

What is Software Engineering?

A historical definition:

“A systematic approach to the analysis, design, implementation and

maintenance of software”

“ Software is a set of instructions to acquire inputs and to

manipulate them to produce the desired output. It also include a set
of documents, such as the software manual , meant for users to
understand the software system.”

CSE Dept Software Engineering: Introduction 3

Software Engineering Definition
 The application of engineering to make it as
software
 Involves the field of computer science dealing with
software systems
– large and complex
– built by teams
– exist in many versions
– last many years
– undergo changes
Software Engineer
 Must know what to do, when to do it, and how to do
it efficiently

CSE Dept Software Engineering: Introduction 4

What is software?
 Computer programs and associated documentation such as
requirements, design models and user manuals.
 Software products may be developed for a particular
customer or may be developed for a general market.
 Software products may be
 Generic - developed to be sold to a range of different customers e.g.
PC software such as Excel or Word.
 Bespoke (custom) - developed for a single customer according to
their specification.
 New software can be created by developing new programs,
configuring generic software systems or reusing existing
software.

CSE Dept Software Engineering: Introduction 5

What is the difference between software
engineering and computer science?
 Computer science is concerned with theory and
fundamentals; Software engineering is concerned with
the practicalities of developing and delivering useful
software.

CSE Dept Software Engineering: Introduction 6

Role of a Software Engineer

• Programming skills are not enough

• Software engineering involves "programming-in-the-
large"
– understand requirements and write specifications
• derive models and reasons about them
– operate at various abstraction levels
– member of a team
• communication skills
• management skills

CSE Dept Software Engineering: Introduction 7

Software Crisis
Large Software Systems Often
• Do not provide the desired functionality
• Take too long to build
• Cost too much to build
• Require too much time, space, or other resources to run
• Cannot evolve to meet changing needs

CSE Dept Software Engineering: Introduction 8

Why Software Engineering?

9 software projects totaling $96.7 million: Where The Money Went

[Report to Congress, Comptroller General, 1979]

Delivered, but never

successfully used
45%

Used as delivered
2%
Usable w. rework
Paid for, but
3% not delivered
30% Why?
Used w. extensive rework, Software hurts
but later abandoned
Requirements
20%
design

CSE Dept Software Engineering: Introduction 9

What Factors Contribute to Project Success?

Project Success Factors

28% The CHAOS Ten

1. User Involvement 15.9%

completed on time overran original estimates:
-Time overrun averaged 63% 2. Executive Management Support 13.9%
and on budget - Cost overrun averaged 45%
3. Clear Statement of Requirements 13.0%
4. Proper Planning 9.6%
canceled before
completion
49% 5. Realistic Expectations 8.2%
23% 6. Smaller Project Milestones 7.7%
7. Competent Staff 7.2%
8. Ownership 5.3%
9. Clear Vision & Objectives 2.9%
10. Hard-Working, Focused Staff 2.4%
11. Other 13.9%
CSE Dept Software Engineering: Introduction 10
 What Factors Contribute to Project Failure?

The CHAOS Ten The CHAOS Ten

CSE Dept Software Engineering: Introduction 11

Why Software Engineering?
What do software engineers do?

Non-productive
Activities
30%

Interaction
Work alone 50%
20%

programming ≠ software engineering

personal activity team activity
small, clear problem large, nebulous problem
CSE Dept Software Engineering: Introduction 12
Attributes of good software

The software should deliver the required functionality and performance to

the user and should be maintainable, dependable and usable.
• Maintainability
 Software must evolve to meet changing needs
 Dependability
 Software must be trustworthy
 Efficiency
 Software should not make wasteful use of system resources
 Usability
 Software must be usable by the users for which it was designed

CSE Dept Software Engineering: Introduction 13

Why Software Engineering?

Major symptoms of the “software crises”:

 Over budget
 Schedule slippage
 Poor quality

Major causes of the “software crises”:

The "software crises" came about when people realized the major problems in
software development were … caused by communication difficulties and the
management of complexity” [Budd]

CSE Dept Software Engineering: Introduction 14

What is a software process?
 A set of activities whose goal is the development or
evolution of software.
 Generic activities in all software processes are:
 Specification - what the system should do and its
development constraints
 Design – Diagrammatical representation of system
 Development - production of the software system
 Validation - checking that the software is what the
customer wants
 Evolution - changing the software in response to
changing demands.

CSE Dept Software Engineering: Introduction 15

What is a software process model?
 A simplified representation of a software process,
presented from a specific perspective.
 Examples of process perspectives are
 Workflow perspective - sequence of activities;
 Data-flow perspective - information flow;
 Role/action perspective - who does what.
 Generic process models
 Waterfall;
 Iterative development

CSE Dept Software Engineering: Introduction 16

How to Do Software Engineering?

Software Lifecycle Review

Systems Engineering

Quality Assurance
Requirements Analysis

Project Planning
Maintenance
Architectural Design

Detailed Design

Implementation

Release

CSE Dept Software Engineering: Introduction 17

Why SE?

CSE Dept Software Engineering: Introduction 18

CSE Dept Software Engineering: Introduction 19
CSE Dept Software Engineering: Introduction 20
CSE Dept Software Engineering: Introduction 21
CSE Dept Software Engineering: Introduction 22
CSE Dept Software Engineering: Introduction 23
CSE Dept Software Engineering: Introduction 24
CSE Dept Software Engineering: Introduction 25
CSE Dept Software Engineering: Introduction 26
 Structured Programming
By
Satyanandaram N

12/16/2019 CSE Dept. Software Engineering 1

Objectives
 Features

 Advantages of Structured Programming

 Evaluation of Software design techniques

 Exploratory style Vs. Modern style

12/16/2019 CSE Dept. Software Engineering 2

Structured programming
 Aimed on improving the clarity, quality, and
development time of a computer program
 By making extensive use of subroutines, block
structures and loops
 It uses selection, sequence and iteration
 It uses single entry, single-exit constructs
 Ex: If-then-else, do-while

12/16/2019 CSE Dept. Software Engineering 3

Advantages
 Easier to read and understand

 Easier to maintain

 Require less effort and time for development

 Easier to debugging

12/16/2019 CSE Dept. Software Engineering 4

Evolution of S/W design techs
 Low Level – Exploratory Programming:
 In 1950s programs were being written in assembly
language
 Programs were very small in size
 Individual style – based on developer choice
 High Level:
 During early 1960s
 Reduced the development efforts and time
 Ex: FORTRAN, ALGOL and COBOL

12/16/2019 CSE Dept. Software Engineering 5

Evolution of S/W design techs
 Exploratory programming style was insufficient
 Size and complexity of programs kept on increasing
 GOTO statement was the main culprit
 GOTO – assembly languages
 GOTO– High-level languages
 Sequence, selection, and iteration were sufficient to
express any programming logic

12/16/2019 CSE Dept. Software Engineering 6

Components of Software
Engineering
Software development engineering is carried out in two
ways
 Structured System Analysis and Design ( SSAD)
 The system and its requirements are decomposed in structured
manner
 s/w development is carried out using sub-system structure, tested
and integrated and implemented
 Object Oriented System Analysis and Design ( OOSAD)

12/16/2019 CSE Dept. Software Engineering 7

Components of Software
Engineering
 Object Oriented System Analysis and Design( OOSAD)
 Identification of objects occurring in a problem

 Relationships among the objects determined

 Each object essentially acts as a data hiding entity

12/16/2019 CSE Dept. Software Engineering 8

Exploratory style vs. Modern style
in S/W Development
 Exploratory style:
 Based on error correction
 Errors are detected only during the final product testing
 Every thing is coding
 Modern style:
 Develop the s/w through several well-defined stages

12/16/2019 CSE Dept. Software Engineering 9

 Life cycle model
 Need for Life cycle model
 Different life cycle models
 Classical waterfall model
 Prototype model
 Spiral model
 Life Cycle: A recognizable work phase pattern
that delivers well defined products
 Product Life Cycles: An activity pattern occurs
over the useful life of a product
 Versions: enhances functionality or quality
 Variations: different domains
 Project Life cycles: The collection of activities
that occurs over the life of a project to
produce a single release of a product
 is a descriptive and diagrammatic
representation of the software life cycle

 It maps the different activities perform on a

software product from its inception to
retirement
 Development team must identify a suitable
life cycle model
 Without any model, product would not be in
a systematic and disciplined manner
 Life cycle model defines entry and exit
criteria for every phase
 Without LCMs it would be very difficult to
monitor the progress of a project
 Waterfall Model
 Prototyping Model
 Evolutionary Model
 Spiral Model
 1970 ： Waterfall model (Royce)
 This model is considered as a theoretical way
of developing software
 This model is base for all other models
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than
cost or schedule
 Is an idealistic one – no development error
has ever committed by engineers
 All requirements must be known upfront
 Integration is one big task at the end
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Requirements are very well known
 Product definition is stable
 No significant risks
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
 1977 ： Prototyping model(Bally and others)
 Toy implementation of the system
 Customers are non-technical and usually
don’t know what they want/can have
 By implementing dummy functions
 If you want to develop a good product you
must plan for 1st version
 Better understanding of the customer needs
 How the screens might look like
 How the user interface would behave
 How the system would produce outputs
 If the technical solutions are unclear to the
development team
 When to choose prototype:
 User requirements are not complete
 Technical issues are not clear
 1988 ： Spiral model(Boehm)
 It includes the iterative nature of the
prototyping model and the linear nature of
the waterfall model
 Developing software that is revealed in
various versions
 At the end of 1st iteration, customer evaluates
the product and provide feedback
 Iteration continues throughout the life of the
software
 Requirements:
 Not well understood
 Unstable

 For medium to high-risk projects

 Functional and some non-function quality attributes are very important

 New product line

 Cost and time pressure is less important

Determine Evaluate
objectives, alternatives,
alternatives, identify and
constraints resolve risks

Plan next Develop verify

phases next level
product
 Objectives: functionality, performance,
hardware/software interface, critical success factors,
etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.
 Study alternatives related to objectives and
constraints
 Identify risks (lack of experience, new technology,
tight schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost by
continuing system development
 Typical activities:

 Create a design
 Review design
 Develop code
 Inspect code
 Test product
 Typical activities
 Develop configuration management plan
 Develop a test plan
 Develop an installation plan
 Develop project plan
 Provides early indication to overcome the risks without much cost

 User can see the system early because of rapid prototyping tools

 Critical high-risk functions are developed first

 The design does not have to be perfect

 Users can be closely tied to all lifecycle steps

 Early and frequent feedback from users

 Cumulative costs assessed frequently

 Time spent for evaluating risks too large for small or low-risk projects

 Time spent for planning, resetting objectives, doing risk analysis and
prototyping may be excessive

 The model is complex

 Risk assessment expertise is required

 Spiral may continue indefinitely

 Developers must be reassigned during non-development phase activities