Formal Methods of

Software Engineering

Module 01: Introduction to

Software Engineering
Software?
 A textbook description of software might take
the following form: Software is (1) instructions
(computer programs) that when executed
provide desired function and performance, (2)
data structures that enable the programs to
adequately manipulate information, and (3)
documents that describe the operation and
use of the programs.
What is software?
 Software is a tool to improve work processes
and/or engineering artifacts.
 Basic structure of work processes
 Man/Woman
 Machine/Tool
 Software Policy
 Database Procedure Process Goal
 Hardware Standard
 Computing
 Non-Computing
 Communication network
Software characteristics:
 Software is developed or engineered, it is not
manufactured in the classical sense.
 Software does not “wear out.”
 Most software is custom built, rather than
being assembled from existing components.
Software applications:
 System Software
 Real-time Software
 Business Software
 Engineering and Scientific Software
 Embedded Software
 Personal Computer Software
 Artificial Intelligence Software
 Failure characteristics of software products:

Infant
Infant Wear out Failure mortality
Failure mortality
rate
rate
Continuous at
same rate until
obsolescence

Time Time
Failure curve for hardware Failure curve for software
Failure characteristics of software
products…
 Increased failure
rate due to side effect

Failure Actual
rate Change curve

Idealized
curve

Time
Software Development Process…
 The impact of change of software:

60 – 100x

Cost to
change

1.5 – 6x

1x

Definition Development Stage

After release
Why should people pay for software?
 It’s about the improvement what it makes to
work processes/engineering artifacts.
 How much should they pay?
Software Applications:

What do you think?
Are there software applications?
More Examples
Objective of software engineering:
 To capture right requirements with the optimum usage
of other components of the system.

 To implement requirement by ensuring predictability

and continuous improvement of
 Quality
 Time
 Cost

 Quality
 Conformance to requirement
Basic steps of software engineering:
 Technical steps:
 Work process/engineering artifacts
understanding.
 Determine the role of software with the
optimum roles played by other components of
the system.
 Design of software requirements
 Coding and testing
 Integration, system testing
 Implementation/deployment/commissioning
Basic steps of software engineering..
 Engineering management steps
 Project management
 Quality assurance
 Requirements/change management
 Configuration management
How to capture requirements?
 Functional capabilities/capacities
 Process modeling
 Performance parameter selection
 Determining existing roles of system
components
 Setting new targets of capabilities and
performance
 Determining new roles of components
 Determining optimum roles in meeting targets
 Capture the role of software: this is your
software requirements document.
Basic structure:

Purpose

Input Output Purpose

Step-1
Capability

Input Output
Step-2
Waiting time Waiting time
Performance

Performance
Time/throughput
Quality/wastage
Energy
Safety
Cost
Total value addition
 Practice Session:
 Develop requirements of a software for
improving the method of teaching alphabets to
playgroup students:
 Current system
 Envisioned system
 Role of software
 Submit a report in the next class:
 Sunday, June 03
 Any other system of your interest???
Business value of software
 Revenue of Apple?
 Revenue of Microsoft?
 Revenue of SAP?
 Revenue of InfoTech?
 Revenue of IBM global services?
 Revenue of Bangladesh’s software industry?
 Revenue of India’s software service industry?
 Is it a big business?
Every business is software business
 Why?
 Dilemma in software business:
 If you extend schedules to make realistic
customer commitment, you loose business.
 If you make competitive commitments, your
software is late and customers are unhappy.
 If you do this too often, you will be known as an
unreliable supplier.
 If this condition continues for long, you will lose
so many customers that you could well go out of
business.
Principles of Software Management
 Principle number one: Recognize that you are in
software business
 Customers
 Product managers
 Developers
 Principle number Two: The quality must be the
top priority
 Principle number Three: Quality software is
developed by disciplined and motivated people
Why project fails
 Unrealistic schedules
 Inappropriate staffing
 Changing requirements
 Poor quality work
 Believing in magic
Key lessons to deal with project failure
 The two key components of software
management are a dedication to quality and
consistently disciplined engineering work
 When software projects fails, it is usually
because a manager did not insist that the work
be done in the right way
 All of those causes could have been avoided
had management insisted on planned and
disciplined work.
Rational management
 Four elements to rational management:
 Set aggressive long-term goals, but break these
goals into realistic and measurable short-term
goals.
 Require detailed and complete plans, review
these plans, and then negotiate the commitments
with the people who will do the work.
 Insist on facts and data, and use these facts and
data to run these businesses
 Monitor the work, and use current data to
anticipate and resolve future problems.
Why should quality be managed?
 There are three reasons to insist that software
quality be measured and managed:
 Poor-quality software can cause major property
damage and even kill people
 Quality works saves time and money
 If management do not manage software quality,
nobody else will do.
Why quality pays
 Defective software is expensive and can even be life
threatening.
 Software engineers inject defects because they are
human.
 The cost to find and fix a defect increases exponentially
as development progresses.
 The engineer who developed a program is best able to
find and fix defects.
 Effective defect-removal methods require special
training.
 If you do not manage software quality, nobody else will.
Leadership goals:
 In setting goals, make them clear and measurable, assign them to
specific people, and track performance against them.
 Goals that are measured get managed, and goals that are managed
are often met.
 Goals that are not measured and managed won’t be met, and
performance may actually deteriorate.
 To improve engineering performance, you must change what people
do.
 To change their behavior, the engineers must know how to make
detailed plans, manage quality, and use efficient working methods.
 To actually improve the organization, the engineers must
consistently use the methods they know and the managers must
guide, support, and coach them in doing so.
Changing engineering behavior:
 For engineers to use disciplined methods, their
managers must agree with the methods and
support their use.
 To actually change engineering and
management behavior, the managers must be
responsible for implementing the changes.
 If software engineers are to change their
behavior, they must believe that the new
methods will work for them.
Software industry analysis
 Value chain
 Domestic market
 Export market
 Outsourcing
 Business Software Industry Analysis
Domestic Market Small Clients in Large Clients in
Production (e.g. RMG, the International the International $ 600 b
Banks etc.) Market Market
Value Chain

Determine IT Value No Value Proposition

Proposition for Local Software Big Consulting Companies
Clients’ business Service Provider (e.g. Accenture, EDS etc.)
$ 1000/day $ 200 b
System No System
Requirements’ Local Software Requirements’
Capturing Service Provider Capturing
Developed
Countries
Derivation of No Derivation of
Software Local Software Software
Requirements Service Provider Requirements
$ 500-
Most 600/day $ 50 b
Software design: Few Software design:
Architectural & Local Local Software Architectural &
Detailed Software Service Provider Detailed

Service
Many Unit Coding &
Unit Coding & $ 10-
Testing
Providers Local Software $ 80/day Testing
Unit Coding &
Testing 25/day
$ 100 b
Service Providers
80% in
(150 firms) Developed Developing
Few System
System Integration Countries Countries
& Testing Local Software Integration
Service Provider & Testing
$ 50 b
Production of Users’ Production of
No Users’ Manual &
Manual & Training $ 500-
Local Software Training Material
Material Service Provider 600/day
Developed
Software No Countries Software
Implementation Local Software Implementation $ 200 b
Guide Preparation Service Provider Guide Preparation
Software Life Cycle Models
 Basics
 The Waterfall
 The Prototype
 Rapid Application Development (RAD)
 Iterative or Evolutionary Model
 Incremental
 The Spiral
 Life Cycle Models in Object Oriented Development
Methodology
 Methodologies to deal with defects
 SEI Process Frameworks and Life cycle Models
Basics of Life Cycle
 Basic Technical Steps (i.e. Value Chain) of
Software Engineering
1. Requirements
2. Specifications
3. Design: Architectural and detailed
4. Test design: unit, system, acceptance
5. Coding and unit testing
6. Integration and system testing
7. Implementation and acceptance testing
8. Maintenance: bug fixing, enhancement
Basics of Life Cycle…
 Basic Management Steps
 Project planning
 Project monitoring and control
 Quality assurance
 Project financing
 HR management
 Technology management
 Process management
 Product positioning management
Basics of Life Cycle…
 Products produced
 Project plan
 Requirements document
 Specification document
 Design document
 Test design and plan
 Code
 Test results: unit, integration, acceptance
 Users’ manual
 Training materials
Basics of Life Cycle…
 Fundamental approach
1. Plan
2. Perform
3. Measure
4. Control
5. Improve

 Essence of dealing with both micro and macro

complexities.
Software is about innovation
Basic Nature of Software engineering steps
Relevant Statistics
The Waterfall Model
Requirements
capturing and
analysis Waterfall Model
Architectural
and detailed
design
Coding and
component
testing
Classic life cycle System
integration
and testing Acceptance
testing and
release
The linear sequential model…
 Limitations:
 Real projects rarely follow the sequential flow

 It is often difficult for the customer to state all

requirements explicitly.

 The customer must have patience

 Developers are often delayed unnecessarily.

The linear sequential model…
 Strengths:
 Possible minimum cost can be achieved

 Project can be completed in possible minimum time

 If customers are knowledgeable, projects’

complexities are moderate, and the engineering
teams are competent, this model is the most
suitable.

 This is the ideal model

Prototyping Model:
 Deal with following uncertainties
 Requirements
 Technology
 HR and Skill
 Estimation
Prototyping Model…
• Prototyping paradigm may be the right approach to deal
with such managerial, requirement, skill and
technological uncertainties.

Listen to Build/revise
customer mock-up

Customer
test-drives
mock-up
Prototyping Model…
 Limitations:
 The customer sees what appears to be a working
version of the software.

 The developer often makes implementation

compromises in order to get a prototyping
working quickly.

 Question: What do we do with the prototype when it

has served the purpose?
Prototyping Model…
 The key is to define the rules of the game at the
beginning; that is
 The customer and developer must both agree
that the prototyping is built to serve as a
mechanism for defining requirements and to
reduce technological and managerial
uncertainties.

 It is them discarded (code, not the knowledge)

and the actual software is engineered with an eye
toward quality and maintainability.
The RAD Model:
 Rapid Application Development (RAD) is a linear
sequential software development process model that
emphasizes an extremely short development cycle.

 Each major function of the system to developed is

addressed by a separate RAD team and then integrated
to form a whole.

 If the requirements are well understood and project

scope is constrained, the RAD process enables a
development team to create a fully functional system
within very short time periods.
The RAD Model…
Business
Business
Team #3 process
modeling
Team #2 process
modeling Data
modeling
Data
Business Process
modeling
Team #1 process modeling

modeling Process Application

modeling generation
Data Application Testing
modeling generation &
turnover
Process Testing &
modeling turnover
Application
generation
Testing
&
turnover
The RAD Model…
 Limitations:
 For large, but scalable projects, RAD requires sufficient
human resources to create the right number of RAD
teams.

 RAD requires developers and customers who are

committed to the rapid-fire activities necessary to
complete a system in a much abbreviated time frame.

 If commitment is lacking from either side, RAD project

will fail.

 RAD is not appropriate when technical risks are high.

Evolutionary software process models:
 Constraints
 It appears that software, like all complex systems,
evolves over a period of time.

 Sometimes, the changes of business and product

requirements make a straight line path for product
development unrealistic.

 Sometimes, the tight market deadlines make

completion of a comprehensive software product
impossible.
Evolutionary software process
models…
 Solutions
 A limited version is introduced to meet
competitive or business pressure.

 A set of core product or system requirements,

which are well understood, are realized first.

 Along the way, the details of product or system

extensions are met; different versions come in
practice.

 Real-life software products evolve to met ever

increasing requirements
 The Incremental Model:
• The incremental model combines elements of the linear
sequential model with the iterative philosophy of
prototyping.
Increment 1

Requirements Design Integration

Coding and
capturing and (architectural and system
unit testing
analysis and detailed) testing

Requirements Design Integration

Coding and
Increment 2 capturing and (architectural unit testing
and system
analysis and detailed) testing

Requirements Design Integration

Increment 3 Coding and and system
capturing and (architectural unit testing
analysis and detailed) testing
The Incremental Model…
 Each linear sequence produces a deliverable “increment”
of the software.

 Word processing example? Windows example?

 When an increment model is used, the first increment is

often a core product. That is, basic requirements are
addressed.

 Many supplementary features remain undelivered.

 An additional set of requirements is defined after use of

the first delivery.
The Incremental Model…
 Additional components are added to core product to
better meet needs of the customer.

 The process is repeated following the delivery of each

increment, until the complete product is produced.

 Unlike prototyping, the incremental model focuses on the

delivery of an operational product with each increment.

 Early increments are “stripped down” versions of the final

product, but they do provide capability that serves the
user and also provide a platform for evaluation of the
user.
Usefulness of Incremental Model…
 Incremental development is particularly useful when
staffing is unavailable for a complete implementation by
the business deadline that has been established for the
project.

 Early increments can be implemented with fewer people.

 If the core product is well received, additional resources

can be added to implement the next increment.

 In addition, increments can be used to manage technical

and business risks.
The Spiral Model:
 Spiral model: proposed by Boehm (1988)

 This evolutionary approach couples the iterative nature

of prototyping with the controlled and systematic aspects
of linear sequential model.

 In this model, software is developed in a series of

incremental releases of intermediate products.

 During early iterations, the incremental release might be

a paper model or prototype.

 During later versions, increasingly more complete

versions of the engineered systems are produced.
 Spiral Model’s structure:

Planning
Customer
Communication
Risk
Project analysis
entry point
axis

Customer Evaluation
Engineering
Engineering
Construction &
Release
Spiral Model’s Activities:
 Customer communication – tasks required to establish effective
communication between developer and customer.

 Planning – tasks required to define resources, timelines, and other project

related information.

 Risk analysis– tasks required to assess both technical and management risks.

 Engineering– tasks required to build one or more representations of the

application.

 Construction and release– tasks required to construct, test, install and provide
user support.

 Customer evaluation– tasks required to obtain customer feedback based on

evaluation of the software representations created during the engineering stage
and implemented during the installation stage.
Scope of Use of Spiral Model:
 The spiral model can be adapted to apply throughout the life of
computer software.

 A concept development project starts at the core of the spiral and

will continue until the concept development is complete.

 It the concept is to be developed into an actual product, the process

proceeds through the next loop and a new development project is
initiated.

 The new product will evolve through a number of iterations around

the spiral following the path.

 In essence, the spiral, when characterized in this way, remains

operative until the software is retired.
Strengths of Spiral Model:
 The spiral model is a realistic approach to the development of large
scale systems and software.

 The evolving nature of this model enables the customer and the
developer better understand and react to risks at each evolutionary
level.

 The spiral model uses prototyping as a risk reduction mechanism.

 It maintains the systematic stepwise approach suggested by the

classic life cycle, but incorporates it into an iterative framework that
more realistically reflects the real world.

 The spiral model demands a direct consideration of technical risks

at all stages of the project, and if properly applied, should reduce
risks before they become problematic.
Cycle Models in Object Oriented
Development Methodology:
 OO approach works for each life cycle model
 Basic steps
 The analysis phase
 Model the essential system
 Derive candidate-essential classes
 The design phase
 Constrain the essential model
 Derive additional classes
 Synthesize classes
 Define interfaces
 The implementation phase
 Complete the design
 Implement the solution
Dealing with Defects: The Cleanroom
Methodology
 This is an engineering process with mathematical
foundations
 The bases of the process are proof of correctness (of
design and code) and formal quality certification via
statistical testing.
 Cleanroom operations are carried out by small,
independent development and certification (test) teams.
 Once the code is developed, it is subject to statistical
testing for quality assessment.
 The Cleanroom process proclaims that statistical testing
can replace coverage and testing path. In Cleanroom, all
testing is based on anticipated customer usage.
Dealing with Defects: The Defect
Prevention Process (DPP)
 The DPP was developed on techniques used in
Japan for decades and is in agreement with
Deming’s principles. It is based on three simple
steps:
 Analyze defects or errors to trace the root cause
 Suggest preventive actions to eliminate the defect
root causes.
 Implement the preventive actions
 Process Maturity Framework for
Quality, Schedule and Cost:
 SEI’s Capability Maturity
Model:
 Level 1: Initial
 Level 2: Repeatable
 Level 3: Defined
 Level 4: Managed
 Level 5: Optimizing