Text Books:1.

Software Engineering, A practitioners approach

Roger s. Pressman 6th edition McGraw-Hill
2.Software Engineering Somerville 7th edition

Introduction to software Engineering

The Evolving role of software
Dual role of Software
A Product
- Information transformerproducing, 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

Introduction to software Engineering

Software is defined as
1. Instructions
- Programs that when executed provide
function
2. Data structures
-Enable the programs to adequately
manipulate information
3. Documents
-Describe the operation and use of the
programs.

desired

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

Characteristics of software compared with hardware

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

Failure rate

CHARACTERISTICS OF HARDWARE

Infant
mortality

Wear out

Time

Fig: FAILURE CURVE FOR HARDWARE

6

CHARACTERISTICS OF SOFTWARE

Fig: FAILURE CURVE FOR SOFTWARE

7

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

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

LEGACY SOFTWARE
Legacy software are older programs that are developed
decades ago
quality of legacy software is poor
inextensible design , convoluted code
poor and nonexistent documentation,
test cases and results that are not achieved.

10

Legacy systems evolve due to following reasons:

The software must be adapted to meet the needs of new
computing environment or technology.
The software must be enhanced to implement new
business requirements.
The software must be extended to make it interoperable
with more modern systems or database
The software must be rearchitected to make it viable
within a network environment.

11

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

12

13

 High rate of change of user requirements and environment on

which software is working
Large software
Cost
Scalability etc

14

15

17

 An activity
strives to achieve a broad objective and
applied regardless of the application domain
and size of the project

An action
encompasses a set of tasks that produce a
major work product
(e.g., architectural design)

A task
focuses on a small, but well-defined objective
that produces a tangible outcome
(e.g., conducting a unit test
18

SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY

19

SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY

Quality focus
- Bedrock that supports software Engineering
eg :Total quality management, Six Sigma
Process
Foundation for software Engineering
The software process forms the basis for management control
of software projects and
establishes the context in which technical methods are applied,
work products are produced,
milestones are established,
quality is ensured, and
change is properly managed.
20

 Methods
-

Provide technical How-tos for building

software

Methods encompass a broad array of tasks that include

communication,
requirements analysis,
design modeling,
program construction,
testing, and
support.

Tools
- Provide semi-automatic and automatic support for
process and methods

21

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.

22

23

24

25

 Communication
Heavy Communication and collaboration with customer
Encompasses requirement gathering and other related
activity
Planning
Establishes plan for software engineering work
It describe the technical task to be conducted
Risk that are likely to occur and the resource requirement
The work product to be produce and work schedule

26

 Modeling
encompasses the creation of model that allow the developer
and customer to better understand software requirement
The deign that will achieve those requirement
Construction
code generation
Testing required to un cover error in a code
Deployment
The software is delivered to customer
Customers evaluate and give feedback based on evaluation

27

process flow
Describes how the framework activities and the actions and
tasks that occur within each framework activity are organized
with respect to sequence and time
A linear process flow executes each of the five framework
activities in sequence, beginning with communication and
culminating with deployment

28

 An iterative process flow repeats one or more of the activities

before proceeding to the next

29

An evolutionary process flow executes the activities in a

circularmanner.
Each circuit through the five activities leads to a more
complete version of the software

30

A parallel process flow executes one or more activities in

parallel with other activities (e.g., modeling for one aspect of
the software might be executed in parallel with construction of
another aspect of the software).

31

32

 Software project tracking and control

allows the software team to assess progress against the project plan
take any necessary action to maintain the schedule.

33

 Risk management
assesses risks that may affect the outcome of the
project or the quality of the product.

Steps
Risk identification
Risk prioritization
Risk treatment

34

 Software quality assurancedefines and conducts the

activities required to ensure software quality.
Technical reviewsassesses software engineering work
products in an effort to uncover and remove errors before they
are propagated to the next activity.

35

 Measurement
defines and collects process, project, and product
measures that assist the team in delivering
software that meets stakeholders needs; can be
used in conjunction with all other framework and
umbrella activities.
Software configuration management
manages the effects of change throughout the
software process.

36

 Reusability management
defines criteria for work product reuse (including
software components) and establishes mechanisms
to achieve reusable components.
Work product preparation and production
encompasses the activities required to create work
products such as models, documents, logs,
forms,and lists.

37

CAPABILITY MATURITY MODEL INTEGRATION

(CMMI)
Developed by SEI(Software Engineering institute)
CMMI process meta model that defines the process
characteristics that should exist if an organization wants to
establish a software process that is complete
CMMI can be represented in different ways
1.A continuous model
2.A staged model

39

Focus of CMMI

CMMI is applied here

SW-CMM is applied here

40

Bridging the Divide

CMMI:
Integrates systems and
software disciplines into
one process
improvement
framework.
Provides a framework
for introducing new
disciplines as needs
arise.

41

Staged Representation
Provides a proven sequence of improvements, each serving
as a foundation for the next
Permits comparisons across and among organizations by the
use of maturity levels

Indicates maturity of an organizations

standard process -- to answer
What is a good order for approaching
improvement across the organization?
42

43

Maturity Levels
A maturity level is a well-defined evolutionary
plateau of process improvement.
There are five maturity levels.
Each level is a layer in the foundation for continuous
process improvement using a proven sequence of
improvements, beginning with basic management
practices and progressing through a predefined and
proven path of successive levels.
44

The Maturity Levels

Optimizing
5

Focus on continuous
process improvement

Quantitatively
Managed

Process measured
and controlled

Defined
3

Process characterized
for the organization and
is proactive

Managed
2

1
45

Process characterized for

projects and is often
reactive
Process unpredictable,
poorly controlled, and
reactive

Initial

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.

46

Continuous Representation
Allows you to select the order of improvement that best meets
your organizations business objectives and mitigates your
organizations areas of risk
Enables comparisons across and among organizations on a
process-area-by-process-area basis
Provides an easy migration from other models with a
continuous representation to CMMI
Indicates improvement within a single
process area -- to answer,
What is a good order for approaching
improvement of this process area?
47

48

Capability Levels
A capability level is a well-defined evolutionary plateau
describing the organizations capability relative to a
process area.
There are six capability levels.
For capability levels 1-5, there is an associated generic
goal.
Each level is a layer in the foundation for continuous
process improvement.
Thus, capability levels are cumulative, i.e., a higher
capability level includes the attributes of the lower
levels.
49

The Capability Levels

5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
1 Performed
0 Incomplete
50

Model Components
Process Areas (PA)
Specific Goals (SG)
Specific Practices (SP)

Typical Work Products

Sub-practices
Notes
Discipline Amplifications
References

Generic Goals (GG)

Generic Practices (GP)
Generic Practice Elaborations
51

Required
Expected
Informative
Informative
Informative
Informative
Informative

Required
Expected
Informative

PP - Capability Level 1
Project Planning
Specific Practices (CL1 - Base
Practices)

Generic Practices (CL1))

GP1.1: Perform Base Practices

SP1.1-1:Estimate the Scope of the

IfIfall
allof
ofthe
thebase
basepractices
practicesare
are
Project
performed,
SP1.2-1:Establish Estimates of Work
performed,
Product and Task Attributes
Then,
SP1.3-1:Define Project Life Cycle
Then,the
theassociated
associatedSpecific
Specific
Goals
SP1.4-1:Determine Estimates of
Goalsand
andGeneric
GenericGoal
Goal11are
are
satisfied,
Effort and Cost
satisfied,
SP2.1-1:Establish Budget and
Schedule
So,
So,the
theProcess
ProcessArea
Areaisisrated
ratedatat
SP2.2-1:Identify Project Risks
Capability
CapabilityLevel
Level11(CL1)
(CL1)-SP2.3-1:Plan for Data Management
Performed.
Performed.
SP2.4-1:Plan for Project Resources
SP2.5-1:Plan for Needed Knowledge
and Skills
SP2.7-1:Establish the Project Plan
SP2.6-1:Plan Stakeholder
SP3.1-1:Review Plans that Affect the
Involvement
Project
SP3.2-1:Reconcile Work and Resource
Levels
SP3.3-1:Obtain Plan Commitment

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

53

 Quantitatively Managed
-Metrics and indicators are available to measure the process
and quality
- Defect Prevention
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.

54

Maturity levels
LEVEL

FOCUS

PROCESS AREA

Optimizing

Continuous process
Improvement

-Organizational Innovation and

Deployment
-Causal Analysis and Resolution

Quantitatively
managed

Quantitative
management

-Organizational process 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
55

Integrated Teaming
Integrated Supplier
Management
Decision Analysis and
Resolution
Organizational
Environment for Integration
Managed

Basic project management

Requirements Management
Project Planning
Project Monitoring and
Control
Supplier Agreement
Measurement and Analysis
Process and Product
Quality Assurance
Configuration Management

Performed

56

SW-CMM V1.1 vs. CMMI V1.1

Key Process Areas (KPAs)
LEVEL 5
OPTIMIZING
LEVEL 4
MANAGED

Defect Prevention
Technology Change Mgmt
Process Change Management

Causal Analysis and Resolution

Organizational Innovation & Deployment

Quantitative Process Mgmt

Software Quality Mgmt

Organizational Process Performance

Quantitative Project Management

Organization Process Focus

Organization Process Definition
Training Program
Integrated Software Mgmt

Organization Process Focus

Organization Process Definition
Organizational Training
Integrated Project Management
Risk Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Decision Analysis and Resolution

Software Product Engr

LEVEL 3
DEFINED

LEVEL 2
REPEATABLE

Process Areas (PAs)

Intergroup Coordination
Peer Reviews
Requirements Management
Software Project Planning
Software Project Tracking & Oversight
Software Subcontract Mgmt
Software Quality Assurance
Software Configuration Mgmt

Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Product & Process Quality Assurance
Configuration Management
Measurement and Analysis

57

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.

58

PROCESS ASSESSMENT
Software Process

to

tio

Software Process
Assessment

ca

M
od
i fi

Ca
pa
bi
lit

ds
a
Le

Le
a

to

Software Process
improvement

Motivates

Id
e
n
ti
f
i
e
s

es
i
f
ti
n
e
Id

Ex
by am
in
ed

ds
t

ie
s

&

Ri
sk

Capability determination

APPROACHES TO SOFTWRE ASSESSMENT

Standard CMMI assessment (SCAMPI)

CMM based appraisal for internal process improvement
SPICE(ISO/IEC 15504)
ISO 9001:2000 for software

Refer PROCESS ASSESSMENT.ppt

ProcessAssessmentMethod.ppt
process_assmnt.docx

60

Personal and Team Software Process

Personal software process

PLANNING
HIGH LEVEL DESIGN
HIGH LEVEL DESIGN REVIEW
DEVELOPMENT
POSTMORTEM

61

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
- Refer psp.doc
- psp.docx

62

CLASSICAL WATERFALL
MODEL
By Royce:

Communication
project initiation
requirement gathering

Planning
estimating
scheduling
tracking

Modeling
analysis
design

Construction
code
test

Deployment
delivery
support
feedback

63

Sl
no

advantages

disadvantages

When to use

It
allows
departmentalization
managerial control.

for
and

it assumes that no development error is ever

committed by the engineers during any of the life
cycle phases. However, in practical development
environments, the engineers do commit a large
number of errors in almost every phase of the life
cycle

Requirements are
well understood

Simple
and
easy
understand and use

to

It is difficult for customer to state all requirements

explicitly(without any change)

Automation
of
existing
manual
system

Phases are processed and

completed one at a time.

Working version of software will not be available

until late in project span

Short
project

Works well for smaller

projects where requirements
are very well understood.

User feedback not encouraged

Not a good model for complex and object-oriented
projects.

A schedule can be set with

deadlines for each stage of
development and a product
can proceed through the
development process like a
car in a car-wash, and
theoretically, be delivered
on time.

. Once a defect is detected, the engineers need to

go back to the phase where the defect had occurred
and redo some of the work done during that phase
and the subsequent phases to correct the defect and
its effect on the later phases

duration

64

 Incremental Process Models

The Incremental Model
The RAD Model

65

66

advantages

disadvantages

When to use

Generates working
software quickly and
early during the software
life cycle.

Needs good planning and

design.

when the requirements of the

complete system are clearly
defined and understood.

Lowers initial delivery

cost.

Total cost is higher than

waterfall.

A new technology is being used

Easier to manage risk

because risky pieces are
identified and handled
during individual
iteration.

Needs a clear and complete

definition of the whole system
before it can be broken down
and built incrementally.

Staffing is not available for

complete implementation of
project

It is easier to test and

debug during a smaller
iteration.
In this model customer
can respond to each built.

This model is more

flexible less costly to
change scope and
requirements.

There are some high risk features

and goals.

67

Team # n
Mo de lin g
business modeling
data modeling
process modeling

RAD

Co n st ru ct io n
component reuse
automatic code
generation
testing

Team # 2

Communication

Modeling
business modeling
data modeling
process modeling

Planning
Construction

Team # 1

component reuse
automatic code
generation
testing

Modeling

Deployment
integration
delivery
feedback

business modeling
dat a modeling
process modeling

Construction

component reuse
automatic code
generation
testing

68

60 - 90 days

Sl

advantages

disadvantages

When to use

Progress can be measured.

Iteration time can be short with use of powerful
RAD tools.

Dependency on technically strong team members for

identifying business requirements.

Suitable for
project requiring
shorter
development
times.

Sufficient human recourse is needed to create right no of

RAD team
2

Integration from very beginning solves a lot of

integration issues.

Only system that can be modularized can be built using

RAD.
Sufficient human recourse is needed to create right no of
RAD team

Encourages customer feedback, Changing

requirements can be accommodated.

Requires highly skilled developers/designers.

High dependency on modeling skills.
Performances issue

Reduced development time.

Increases reusability of components

Management complexity is more.

Suitable for systems that are component based and scalable

Productivity with fewer people in short time.

Requires user involvement throughout the life cycle.

Inapplicable to cheaper projects as cost of modeling and

automated code generation is very high

Requirements are
understood and
project scope is
constrained
Fully functional
system is to be
delivered in short
span of time

For large, but

scalable projects,
RAD requires
sufficient human
resources to create
the right number
of RAD teams.

69

 Evolutionary Process Model

Prototype
Spiral model

70

Prototype

71

Prototype
Quick plan

Communication

Modeling
Quick design

Deployment
Delivery
& Feedback

Construction
of
prototype

72

Sl

advantages

disadvantages

When to use

Provides a working model to the user

early in the process, enabling early
assessment and increasing user's
confidence.

If the user is not satisfied by the developed

prototype, then a new prototype is
developed. This process goes on until a
perfect prototype is developed. Thus, this
model is time consuming and expensive.

User
requirements
are not
complete

serves to clarify requirements, which

are not clear, hence reducing
ambiguity and improving
communication between the
developers and users.

The developer loses focus of the real

purpose of prototype and hence, may
compromise with the quality of the software.
For example, developers may use some
inefficient algorithms while developing the
prototype.

Technical
issues are not
clear

Helps in reducing risks associated

with the software.

Prototyping can lead to false expectations

customer sees what appears to be a working
version of the Software.

User feedback not encouraged

The primary goal of prototyping is speedy

development, thus, the system design can
suffer as it is developed in series without
considering integration of all other
components

The developer gains experience and

insight by developing a prototype
there by resulting in better
implementation of requirements.

73

Spiral model:Invented by Dr. Barry Boehm

planning
estimation
scheduling
risk analysis

communication
modeling
analysis
design
start

deployment
delivery
feedback

construction
code
test

74

Sl

advantages

disadvantages

When to use

Avoids the problems resulting in

risk-driven approach in the
software
Re-evaluation after each step
allows changes in user
perspectives, technology advances,
or financial perspectives.

Assessment of project risks and its

resolution is not an easy task.

suitable for
development of
technically
challenging
software products
that are prone to
several kinds of
risks

Specifies a mechanism for

software quality assurance
activities

Difficult to estimate budget and

schedule in the beginning as some
of the analysis is not done until the
design of the software is
developed.

Projects build on
untested
assumptions

Development can be divided into

smaller parts and more risky parts
can be developed earlier which
helps better risk management

It demands considerable risk

assessment expertise and relies on
this expertise for success

Is utilized by
complex and
dynamic projects

Allows for extensive use of

prototypes

If risks is not uncovered and

managed problems will surely
occur

Estimation of budget and schedule

gets realistic as the work
progresses.

Large number of intermediate

stages requires excessive
documentation.

Spiral may go indefinitely

End of project may not be
known early

75

76

none
Modeling activity

represents the state

of a software engineering
activity or task

Under
development

A waiting
changes

Under review
Under
revision
Baselined

Done

77

78