Unit I Syllabus

 Introduction to Software Engineering : The

evolving role of software, Changing Nature of
Software, Software myths.
 A Generic view of process : Software
engineering- A layered technology, a process
framework, The Capability Maturity Model
Integration (CMMI), Process patterns, process
assessment, personal and team process models.
 Process Models : Waterfall Model, Incremental
models, Evolutionary models,Specialized
models,Unified Process

1
 INDEX
Unit-1
S.N Topic Lecture PPTSlides
o No
Introduction to software L1 3
1 Engineering: Evolving role
software
2 The changing nature of L2 10
software & legacy software
3 Software myths L3 15
4 A generic view of process: L4 19
Software Engineering-A
layered technology
5 A Process Framework L5
22
5 The Capability maturity L6 25
model Integration(CMMI)
6 Process Patterns, Process L7
assessment 31

7 Personal and Team Process L8 35 2

models
Introduction to software
Engineering

The Evolving role of software

 Dual role of Software
A Product
- Information transformer-
producing, managing and displaying
 A Vehicle for delivering a product

- Control of computer(operating
system),the communication of
information(networks) and the creation of
other programs

3
Introduction to software
Engineering
 Software is defined as
1. Instructions
- Programs that when executed
provide desired function
2. Data structures
-Enable the programs to adequately
manipulate information
3. Documents
-Describe the operation and use of the
programs.
4
Introduction to software
Engineering
 Definition of Engineering
-Application of science, tools and
methods to find cost effective solution
to problems
Definition of SOFTWARE ENGINEERING
- SE is defined as systematic, disciplined and
quantifiable approach for the development,
operation and maintenance of software

5
 Introduction to software
Engineering
Characteristics of software
 Software is developed or engineered, it

is not manufactured in the classical sense.

 Software does not wear out. However it

deteriorates due to change.

 Software is custom built rather than

assembling existing components.

-Although the industry is moving towards
component based construction, most
software continues to be custom built
6
CHARACTERISTICS OF HARDWARE

“Infant
Failure rate

mortality” “Wear out”

Time

Fig: FAILURE CURVE FOR HARDWARE

7
CHARACTERISTICS OF SOFTWARE

Fig: FAILURE CURVE FOR SOFTWARE

8
 THE CHANGING NATURE OF
SOFTWARE
 Seven Broad Categories of software are
challenges for software engineers
 System software
 Application software
 Engineering and scientific software
 Embedded software
 Product-line software
 Web-applications
 Artificial intelligence software
9
 THE CHANGING NATURE OF
SOFTWARE
 System software. System software is a collection of
programs written to service other programs
 Embedded software
-- resides in read-only memory
--is used to control products and systems for the consumer
and industrial markets.
 Artificial intelligence software. Artificial intelligence (AI)
software makes use of nonnumeric algorithms to solve
complex problems that are not amenable to computation or
straightforward analysis
 Engineering and scientific software. Engineering and
scientific software have been characterized by "number
crunching" algorithms.

10
 LEGACY SOFTWARE
 Legacy software are older programs
that are developed decades ago.

 The quality of legacy software is poor

because it has inextensible design,
convoluted code, poor and
nonexistent documentation, test cases
and results that are not achieved.
11
 As time passes legacy systems evolve
due to following reasons:
 ADOPTABILITY: The software must be
adapted to meet the needs of new
computing environment or technology.
 ENHANCEMENT: The software must be
enhanced to implement new business
requirements.
 EXTENSIBILITY: The software must be
extended to make it interoperable with more
modern systems or database
 REARCHITECTURE: The software must be
rearchitected to make it viable within a
network environment.
12
 Software Evolution
 Software evolves due to changes
 Changes occur due to correction,adaption and
enhancement
 8 Laws of unified theory
 The Law of Continuing Change.

 The Law of Increasing Complexity.

 The Law of Self-Regulation

 The Law of Conservation of Organizational Stability.

 The Law of Conservation of Familiarity

 The Law of Continuing Growth

 The Law of Declining Quality

 The Feedback System Law

13
 SOFTWARE MYTHS
 Widely held but false view
 Propagate misinformation and
confusion
 Three types of mythS
- Management mythS
- Customer mythS
- Practitioner’s mythS
14
 MANAGEMENT MYTHS
 Myth(1): BOOK OF STANDARDS
-The available book standards and procedures

for software are

enough.
 Myth(2): STATE OF ART SOFTWARE
-Each organization feel that they have state-of-art
software development tools since they have latest
computer.
 Myth(3): SCHEDULE
-Adding more programmers when the work is behind
schedule can catch up.
 Myth(4): THIRD PARTY
-Outsourcing the software project to third party, we can
relax and let that party build it.
15
 CUSTOMER MYTHS
 Myth(1) : OBJECTIVE
- General statement of objective is
enough to begin writing programs,
the details can be filled in later.
 Myth(2) : EASY/FLEXIBILITY
-Software is easy to change because
software is flexible
16
 PRACTITIONER’S MYTHS
 Myth(1): PROGRAMMING IS ALL
-Once the program is written, the job has been
done.
 Myth(2) : LATE ASSESSMENT
-Until the program is running, there is no way of
assessing the quality.
 Myth(3):WORKING PROGRAM
-The only deliverable work product is the working
program
 Myth(4): DOCUMENTATION
-Software Engineering creates voluminous and
unnecessary documentation and invariably slows
down software development.

17
 SOFTWARE ENGINEERING-A LAYERED
TECHNOLOGY
Basic
Forms Principle
basic SW s

Fig: Software Engineering-A layered technology

Increases more effective

apporach
18
 SOFTWARE ENGINEERING-A
LAYERED TECHNOLOGY
 Quality focus:
- Bedrock that supports software
Engineering.
 Process:
- Foundation for software Engineering
 Methods:
- Provide technical How-to’s for building
software
 Tools:
- Provide semi-automatic and automatic
support to methods-Automation
19
 A PROCESS FRAMEWORK

 Establishes the foundation for a

complete software process
 Identifies a number of framework
activities applicable to all software
projects
 Also include a set of umbrella
activities that are applicable across
the entire software process.
20
A PROCESS FRAMEWORK

Common process framework

Framework activities

TTTasks

Milestones,delierables

SQA points

Umbrella activities

21
 A PROCESS FRAMEWORK

 Used as a basis for the description of

process models
 Generic process activities
 Communication

 Planning

 Modeling

 Construction

 Deployment

22
 A PROCESS FRAMEWORK
 Generic view of engineering
complimented by a number of umbrella
activities

 Software project tracking and control

 Formal technical reviews
 Software quality assurance
 Software configuration management
 Document preparation and production
 Reusability management
 Measurement
 Risk management

23
 CAPABILITY MATURITY MODEL
INTEGRATION(CMMI)
 Developed by SEI(Software Engineering institute)
 Assess the process model followed by an organization and rate the
organization with different levels
 A set of software engineering capabilities should be present as
organizations reach different levels of process capability and
maturity.
 CMMI process meta model can be represented in different ways

1.A continuous model

2.A staged model
Continuous model:
-Lets organization select specific improvement that best meet its
business objectives and minimize risk
-Levels are called capability levels.
-Describes a process in 2 dimensions
-Each process area is assessed against specific goals and practices and
is rated according to the following capability
levels.
24
 CMMI
 Six levels of CMMI
 Level 0:Incomplete
 Level 1:Performed
 Level 2:Managed
 Level 3:Defined
 Level 4:Quantitatively managed
 Level 5:Optimized

25
 CMMI
 INCOMPLETE
-Process is adhoc.Objective and goal of process areas are not
known
 Performed
-Goal,objective,work tasks,work products and other activities of
software process are carried out
 Managed
-Activities are monitored, reviewed, evaluated and controlled
 Defined
-Activities are standardized, integrated and documented
 Quantitatively Managed
-Metrics and indicators are available to measure the process and
quality
 Optimized
- Continuous process improvement based on quantitative feed
back from the user
-Use of innovative ideas and techniques, statistical quality
control and other methods for process improvement.

26
 CMMI
Staged model
- This model is used if you have no clue of how to improve the
process for quality software.
- It gives a suggestion of what things other organizations have
found helpful to work first
- Levels are called maturity levels

27
LEVEL FOCUS PROCESS AREA
Optimizing Continuous process -Organizational Innovation and
Improvement
Deployment
-Causal Analysis and Resolution

Quantitatively Quantitative -Organizational process

managed management performance
-Quantitative project
management
Defined Process standardized Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Risk Management 28
 −Integrated Teaming
−Integrated Supplier

Management
−Decision Analysis and

Resolution
−Organizational

Environment for
Integration
Managed Basic project Requirements
management Management
Project Planning
Project Monitoring and
Control
Supplier Agreement
Measurement and
Analysis
Process and Product
Quality Assurance
Configuration
Management
Performed

29

PROCESS PATTERNS
Software Process is defined as collection of
Patterns
 Process pattern provides a template
 Process Template

-Pattern Name
-Intent
-Type
-Task pattern
- Stage pattern
-Phase Pattern
 Initial Context
 Problem
 Solution
 Resulting Context
 Related Patterns 30
 PROCESS ASSESSMENT
 Does not specify the quality of the
software or whether the software will
be delivered on time or will it stand
up to the user requirements.
 It attempts to keep a check on the
current state of the software process
with the intention of improving it.

31
 PROCESS ASSESSMENT
Software Process

Ex
by am Ca
in pa
ed
bi
liti
es
s
es
to

e
i
i
f
f
ti
ti
Software Process &
n

n
n
io

e Ri
e
at

Id Assessment Id
sk
ific

Le
od

to a ds
M

s t
ad o
Le

Software Process Motivates Capability determination

improvement
 APPROACHES TO SOFTWRE
ASSESSMENT
 Standard CMMI assessment (SCAMPI)
 CMM based appraisal for internal
process improvement
 SPICE(ISO/IEC 15504)
 ISO 9001:2000 for software

33
Personal and Team Software
Process

 Personal software process

 PLANNING
 HIGH LEVEL DESIGN
 HIGH LEVEL DESIGN REVIEW
 DEVELOPMENT
 POSTMORTEM

34
Personal and Team Software
Process
 Team software process
 Goal of TSP
- Build self-directed teams
- Motivate the teams
- Acceptance of CMM level 5 behavior as
normal to accelerate software process
improvement
- Provide improvement guidance to high
maturity organization
35