What is software?

• Computer programs and associated

documentation

1
 What is software?

Programs

Documentatio Operating
n Procedures

Software=Program+Documentation+Operating Procedures
Components of software

2
 Documentation consists of different types of manuals are
Formal Specification
Analysis Context-
/Specification Diagram
Data Flow
Diagrams
Flow Charts
Design
Entity-Relationship
Documentation Diagram
Manuals
Source Code Listings
Implementation Cross-Reference
Listing
Test Data
Testing
Test Results

List of documentation manuals

3
Documentation consists of different types of manuals are
System Overview
User Beginner’s Guide
Manuals Tutorial
Reference Guide

Operating
Procedures

Installation Guide
Operational
Manuals
System
Administration Guide

List of operating procedure manuals.

4
 Software Product

• 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
–Bespoke (custom) - developed for a single customer according
to their specification

5
 Software Product
Software product is a product designated for
delivery to the user
source documents
codes reports

manuals
object plans
codes
data

test suites test results

prototypes

6
 What is software engineering?

Software engineering is an engineering discipline which

is concerned with all aspects of software production
Software engineers should
– adopt a systematic and organised approach to their
work
– use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and
– use the resources available
7
 What is software engineering?
At the first conference on software engineering in 1968, Fritz Bauer
defined software engineering as “The establishment and use of
sound engineering principles in order to obtain economically
developed software that is reliable and works efficiently on real
machines”.

Stephen Schach defined the same as “A discipline whose aim is the

production of quality software, software that is delivered on time,
within budget, and that satisfies its requirements”.

Both the definitions are popular and acceptable to majority.

However, due to increase in cost of maintaining software, objective
is now shifting to produce quality software that is maintainable,
delivered on time, within budget, and also satisfies its requirements.
8
 Software Process

The software process is the way in which we produce

software.

Why is it difficult to improve software process ?

• Not enough time

• Lack of knowledge

9
 Software Process

• Wrong motivations
• Insufficient commitment
Improved future state
Process improvement
begins
Initial state
state

Productivity

Do not quit here!

Learning curve

Time

10
 Software Characteristics:

Software does not wear out.

Burn-in
phase Wear out
phase
Failure Intensity

Useful life
phase

Time
11
 Software Characteristics:
 Software is not manufactured
 Reusability of components
 Software is flexible

12
 Software Characteristics:
Comparison of constructing a bridge vis-à-vis writing a program.
Sr. Constructing a bridge Writing a program
No
1. Only some parts of the problem are
The problem is well understood
understood, others are not
2. Every program is different and designed for
There are many existing bridges
special applications.
3. The requirement for a bridge typically do Requirements typically change during all
not change much during construction phases of development.
4. The strength and stability of a bridge can be Not possible to calculate correctness of a
calculated with reasonable precision program with existing methods.
5. When a bridge collapses, there is a When a program fails, the reasons are often
detailed investigation and report unavailable or even deliberately concealed.
6. Engineers have been constructing bridges Developers have been writing programs
for thousands of years for 50 years or so.
7. Materials (wood, stone,iron, steel) and Hardware and software changes rapidly.
techniques (making joints in wood, carving
stone, casting iron) change slowly.

13
 Software Characteristics

• Software is developed or engineered, it is

not manufactured in the classical sense.
• Software doesn't "wear out."
• Although the industry is moving toward
component-based construction, most
software continues to be custom-built.
 Bath Tub Curve
Wear vs. Deterioration

increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time
The Changing Nature of Software

System Real
Software Time
Software

Engineering
and Scientific Embedded
Software Software

Web based Business

Software Software
Artificial
Intelligence Personal
Software Computer
Software

16
 Types of Software

• System Software- A collection of programs written to

service other programs at system level. For example,
compiler, operating systems.

• Real-time Software- Programs that

monitor/analyze/control real world events as they occur.

• Business Software- Programs that access, analyze and

process business information.

• Engineering and Scientific Software - Software using

“number crunching” algorithms for different science and
applications. System simulation, computer-aided design.
 Types of Software (Contd..)

• Embedded Software-:
Embedded software resides in read-only memory
and is used to control products and systems for the
consumer and industrial markets. It has very
limited and esoteric functions and control
capability.

• Artificial Intelligence (AI) Software:

Programs make use of AI techniques and methods
to solve complex problems. Active areas are
expert systems, pattern recognition, games
 The Changing Nature of Software

• Trend has emerged to provide source code

to the customer and organizations.
• Software where source codes are available
are known as open source software.
• Examples Open source software: LINUX,
MySQL, PHP, Open office, Apache web
server etc.
 Software—New Categories

• Open world computing—pervasive, distributed computing

• Ubiquitous computing—wireless networks
• Net sourcing—the Web as a computing engine
• Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
• Also …
– Data mining
– Grid computing
– Cognitive machines
– Software for nanotechnologies
Software Myths (Management Perspectives)

Management may be confident about good

standards and clear procedures of the company.

But the taste of any food item

is in the eating;
not in the Recipe !

21
Software Myths (Management Perspectives)

Company has latest computers and state-of-

the-art software tools, so we shouldn’t worry
about the quality of the product.

The infrastructure is
only one of the several factors
that determine the quality
of the product!

22
Software Myths (Management Perspectives)

Addition of more software specialists, those

with higher skills and longer experience may
bring the schedule back on the track!

Unfortunately,
that may further delay the schedule!

23
Software Myths (Management Perspectives)

Software is easy to change

The reality is totally different.

24
 Software Myths (Management Perspectives)

Computers provide greater reliability than

the devices they replace

This is not always true.

25
Software Myths (Customer Perspectives)

A general statement of objectives is sufficient to get started with

the development of software. Missing/vague requirements can
easily be incorporated/detailed out as they get concretized.

If we do so, we are heading

towards a disaster.

26
 Software Myths (Customer Perspectives)

Software with more features is better

software

Software can work right the first time

Both are only myths!

27
Software Myths (Developer Perspectives)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!

28
 Software Myths (Developer Perspectives)

Software quality can not be assessed before

testing.

However, quality assessment techniques

should be used through out the
software development life cycle.

29
 Software Myths (Developer Perspectives)

The only deliverable for a software

development project is the tested code.

Tested code is only one of the deliverable!

30
 Software Myths (Developer Perspectives)

Aim is to develop working programs

Those days are over. Now objective is to

develop good quality maintainable
programs!

31
A Layered Technology

tools

methods

process model

a “quality” focus
 Some Terminologies

 Deliverables and Milestones

Different deliverables are generated during software development.

The examples are source code, user manuals, operating procedure
manuals etc.

The milestones are the events that are used to ascertain the status of
the project. Finalization of specification is a milestone. Completion of
design documentation is another milestone. The milestones are
essential for project planning and management.

33
 Some Terminologies
 Product and Process
Product: What is delivered to the customer, is called a product. It may
include source code, specification document, manuals,
documentation etc. Basically, it is nothing but a set of deliverables
only.

Process: Process is the way in which we produce software. It is the

collection of activities that leads to (a part of) a product. An efficient
process is required to produce good quality products.

If the process is weak, the end product will undoubtedly suffer, but
an obsessive over reliance on process is also dangerous.

34
 Some Terminologies

 Measures, Metrics and Measurement

A measure provides a quantitative indication of the extent,

dimension, size, capacity, efficiency, productivity or reliability of
some attributes of a product or process.

Measurement is the act of evaluating a measure.

A metric is a quantitative measure of the degree to which a system,

component or process possesses a given attribute.

35
 Some Terminologies
 Software Process and Product Metrics

Process metrics quantify the attributes of software development

process and environment;
whereas product metrics are measures for the software product.
Examples
Process metrics: Productivity, Quality, Efficiency etc.
Product metrics: Size, Reliability, Complexity etc.

36
 Some Terminologies

 Productivity and Effort

Productivity is defined as the rate of output, or production per unit of

effort, i.e. the output achieved with regard to the time taken but
irrespective of the cost incurred.

Hence most appropriate unit of effort is Person Months (PMs),

meaning thereby number of persons involved for specified months.
So, productivity may be measured as LOC/PM (lines of code
produced/person month)

37
 Some Terminologies

 Module and Software Components

There are many definitions of the term module. They range from “a
module is a FORTRAN subroutine” to “a module is an Ada
Package”, to “Procedures and functions of PASCAL and C”, to
“C++ Java classes” to “Java packages” to “a module is a work
assignment for an individual developer”. All these definition are
correct. The term subprogram is also used sometimes in place of
module.

38
 Some Terminologies

“An independently deliverable piece of functionality providing

access to its services through interfaces”.

“A component represents a modular, deployable, and replaceable

part of a system that encapsulates implementation and exposes a set
of interfaces”.

39
 Some Terminologies

 Generic and Customized Software Products

Generic products are developed for anonymous customers. The target

is generally the entire world and many copies are expected to be sold.
Infrastructure software like operating system, compilers, analyzers,
word processors, CASE tools etc. are covered in this category.

The customized products are developed for particular customers.

The specific product is designed and developed as per customer
requirements. Most of the development projects (say about
80%)come under this category.

40
Role of Management in Software Development

Factors

People Project

Product Process

41
Role of Management in Software Development

People

Project Dependency Product

4 2
Order

Process

42
43
 Software Life Cycle Models

The goal of Software Engineering is to provide

models and processes that lead to the
production of well-documented maintainable
software in a manner that is predictable.

44
 Software Life Cycle Models

“The period of time that starts when a software product is conceived

and ends when the product is no longer available for use. The
software life cycle typically includes a requirement phase, design
phase, implementation phase, test phase, installation and check out
phase, operation and maintenance phase, and sometimes retirement
phase”.

45
 Build & Fix Model

 Product is constructed without

specifications or any attempt at
design
Build
 Adhoc approach and not well Code

defined

 Simple two phase model Fix

46
 Build & Fix Model

 Suitable for small programming exercises of 100 or 200 lines

 Unsatisfactory for software for any reasonable size

 Code soon becomes unfixable & unenhanceable

 No room for structured design

 Maintenance is practically not possible

47
 Waterfall Model

Requirement This model is named “waterfall

Analysis & Specification
model” because its diagrammatic
representation resembles a cascade of
Design waterfalls.

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance

48
 Waterfall Model

This model is easy to understand and reinforces

the notion of “define before design” and “design
before code”.

The model expects complete & accurate

requirements early in the process, which is
unrealistic

49
 Waterfall Model

Problems of waterfall model

i. It is difficult to define all requirements at the beginning of a
project

ii. This model is not suitable for accommodating any change

iii. A working version of the system is not seen until late in
the project’s life

iv. It does not scale up well to large projects.

v. Real projects are rarely sequential.

50
 Incremental Process Models

They are effective in the situations where requirements are

defined precisely and there is no confusion about the
functionality of the final product.

After every cycle a useable product is given to the customer.

Popular particularly when we have to quickly deliver a limited

functionality system.

51
 Iterative Enhancement Model

This model has the same phases as the waterfall model, but with
fewer restrictions. Generally the phases occur in the same order as
in the waterfall model, but they may be conducted in several cycles.
Useable product is released at the end of the each cycle, with each
release providing additional functionality.

 Customers and developers specify as many requirements as

possible and prepare a SRS document.

 Developers and customers then prioritize these requirements

 Developers implement the specified requirements in one or
more cycles of design, implementation and test based on the
defined priorities.

52
 Iterative Enhancement Model

Requirements
specification

Architectural
design

Detailed
design

Implementation
and unit testing

Integration
and testing

Operation and
Maintenance

53
 The Rapid Application Development (RAD) Model

o Developed by IBM in 1980

o User participation is essential

This is how the

The requirements The developers problem is
understood it in This is how the
specification was solved now
that way problem was
defined like this solved before.

This is how the program is This, in fact, is what the

That is the program after described by marketing customer wanted …
debugging department
54
The Rapid Application Development (RAD) Model

o Build a rapid prototype

o Give it to user for evaluation & obtain feedback
o Prototype is refined

With active participation of users

Requirements User Construction Cut over

Planning Description

55
 The Rapid Application Development (RAD) Model

Not an appropriate model in the absence of user

participation.

Reusable components are required to reduce development

time.

Highly specialized & skilled developers are required and

such developers are not easily available.

56
 Evolutionary Process Models

Evolutionary process model resembles iterative enhancement

model. The same phases as defined for the waterfall model occur
here in a cyclical fashion. This model differs from iterative
enhancement model in the sense that this does not require a
useable product at the end of each cycle. In evolutionary
development, requirements are implemented by category rather
than by priority.

This model is useful for projects using new technology that is not
well understood. This is also used for complex projects where all
functionality must be delivered at one time, but the requirements
are unstable or not well understood at the beginning.

57
 Evolutionary Process Model

Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

58
 Prototyping Model

 The prototype may be a usable program but is not suitable as

the final software product.

 The code for the prototype is thrown away. However

experience gathered helps in developing the actual system.

 The development of a prototype might involve extra cost, but

overall cost might turnout to be lower than that of an
equivalent system developed using the waterfall model.

59
 Prototyping Model

• Linear model
• “Rapid”

60
Spiral Model

61
 Spiral Model
The radial dimension of the model represents the cumulative costs.
Each path around the spiral is indicative of increased costs. The
angular dimension represents the progress made in completing each
cycle. Each loop of the spiral from X-axis clockwise through 360o
represents one phase. One phase is split roughly into four sectors of
major activities.
 Planning: Determination of objectives, alternatives &
constraints.
 Risk Analysis: Analyze alternatives and attempts to identify
and resolve the risks involved.
 Development: Product development and testing product.
 Assessment: Customer evaluation
62
 Spiral Model
 An important feature of the spiral model is that each phase is
completed with a review by the people concerned with the
project (designers and programmers)
 The advantage of this model is the wide range of options to
accommodate the good features of other life cycle models.
 It becomes equivalent to another life cycle model in
appropriate situations.
The spiral model has some difficulties that need to be resolved
before it can be a universally applied life cycle model. These
difficulties include lack of explicit process guidance in determining
objectives, constraints, alternatives; relying on risk assessment
expertise; and provides more flexibility than required for many
applications.
63
 The Unified Process

• Developed by I.Jacobson, G.Booch and J.Rumbaugh.

• Software engineering process with the goal of producing good

quality maintainable software within specified time and budget.

• Developed through a series of fixed length mini projects called

iterations.

• Maintained and enhanced by Rational Software Corporation and

thus referred to as Rational Unified Process (RUP).

64
 Phases of the Unified Process

Inception Elaboration Construction Transition

Time

Definition of Planning & Initial Release of

objectives architecture operational the Software
of the project for the project capability product

65
 Phases of the Unified Process
• Inception: defines scope of the project.
• Elaboration
- How do we plan & design the project?
- What resources are required?
- What type of architecture may be suitable?
• Construction: the objectives are translated in design &
architecture documents.
• Transition : involves many activities like delivering, training,
supporting, and maintaining the product.

66
 Initial development & Evolution Cycles

V1
Inception Elaboration Construction Transition
Initial development Cycle
V2
Inception Elaboration Construction Transition
Evolution Cycle
V3
Inception Elaboration Construction Transition

Continue till the product is retired

V1=version1, V2 =version2, V3=version3

67
Iterations & Workflow of Unified Process

68
 Inception Phase

The inception phase has the following objectives:

 Gathering and analyzing the requirements.

 Planning and preparing a business case and evaluating
alternatives for risk management, scheduling resources etc.
 Estimating the overall cost and schedule for the project.
 Studying the feasibility and calculating profitability of the
project.

69
 Outcomes of Inception Phase

Prototypes Project plan

Business Initial risk

Inception
model assessment
Initial business
Vision
Initial use Initial case
document
case model project
Glossary

70
 Elaboration Phase

The elaboration phase has the following objectives:

 Establishing architectural foundations.

 Design of use case model.
 Elaborating the process, infrastructure & development
environment.
 Selecting component.
 Demonstrating that architecture support the vision at
reasonable cost & within specified time.

71
 Outcomes of Elaboration Phase

Development plan Revised risk

document
Preliminary An executable
Elaboration architectural
User manual
prototype
Architecture
Use case Description
model Supplementary
document
Requirements
with non functional
requirement

72
 Construction Phase

The construction phase has the following objectives:

 Implementing the project.

 Minimizing development cost.
 Management and optimizing resources.
 Testing the product
 Assessing the product releases against acceptance criteria

73
 Outcomes of Construction Phase

Test Operational
Outline manuals
Documentation
Construction Test Suite
manuals
A description
Software of the
product User manuals current release

74
 Transition Phase

The transition phase has the following objectives:

 Starting of beta testing

 Analysis of user’s views.
 Training of users.
 Tuning activities including bug fixing and enhancements for
performance & usability
 Assessing the customer satisfaction.

75
 Outcomes of Transition Phase

Transition

Product User feedback

release Beta test reports

76
 Selection of a Life Cycle Model

Selection of a model is based on:

a) Requirements

b) Development team
c) Users

d) Project type and associated risk

77
 Based On Characteristics Of Requirements

Requirements Waterfall Prototype Iterative Evolutionary Spiral RAD

enhancement development

Are requirements
easily understandable Yes No No No No Yes
and defined?

Do we change
requirements quite No Yes No No Yes No
often?

Can we define
requirements early Yes No Yes Yes No Yes
in the cycle?

Requirements are
indicating a complex No Yes Yes Yes Yes No
system to be built

78
 Based On Status Of Development Team

Development Waterfall Prototype Iterative Evolutionary Spiral RAD

team enhancement development

Less experience on
No Yes No No Yes No
similar projects?

Less domain
knowledge (new to Yes No Yes Yes Yes No
the technology)

Less experience on
tools to be used Yes No No No Yes No

Availability of
No No Yes Yes No Yes
training if required

79
 Based On User’s Participation
Involvement Waterfall Prototype Iterative Evolutionary Spiral RAD
of Users enhancement development

User involvement
in all phases No Yes No No No Yes

Limited user
participation Yes No Yes Yes Yes No

User have no
previous experience No Yes Yes Yes Yes No
of participation in
similar projects

Users are experts

of problem domain No Yes Yes Yes No Yes

80
Based On Type Of Project With Associated Risk
Project type Waterfall Prototype Iterative Evolutionary Spiral RAD
and risk enhancement development

Project is the
enhancement of the No No Yes Yes No Yes
existing system
Funding is stable
for the project Yes Yes No No No Yes

High reliability
requirements No No Yes Yes Yes No

Tight project
No Yes Yes Yes Yes Yes
schedule
Use of reusable
components No Yes No No Yes Yes
Are resources
(time, money, No Yes No No Yes No
people etc.) scare?
81