2. Course Outline
• Software cost factors
• Software Cost Estimation Techniques
• Staffing-level Estimation
• Estimating Software Maintenance Costs
• The Software Requirement Specification
• Formal Specification Techniques
• Language and Processors for Requirement Specification
3. SOFTWARE COST ESTIMATION
One of the important and difficult task is estimating a software
product
Preliminary estimate is prepared during planning
•Improved estimate is presented at the software
requirements review
•
Final estimate is prepared at the preliminary design view
2
4. MAJOR FACTOR THAT INFLUENCE SOFTWARE COST
4
⚫ Programmer ability
⚫ Product complexity
⚫ Product size
⚫ Available time
⚫ Required reliability
⚫ Level of technology
5. PROGRAMMER ABILITY
5
Maintaining and production of a software is based on
programmer
Programmer must be expert in computer programming
If not an expert project may become failure
Programming is a individual and private activity
6. Communication path among programmers increases
according to the number of programmers in a project
By Brook’s observation
Communication path=n(n+1)/2
n= number of programmers
6
7. PRODUCT COMPLEXITY
7
Three main categories of software
product are
⚫ Application software
⚫ Utility software
⚫ System software
.
8. Application software
⚫ Developed using high level programming language
like C++,java etc,.
Utility software
⚫ Utility programs are system software like loader ,
linker , compiler
System software
⚫ Which directly interacts with hardware
⚫ Ex: operating System 8
9. By Brook’s observation
⚫ 1:3:9
⚫ 1(App)-3(utility)-9(System)
⚫ i.e. utility program are 3 times difficult than
application program.
⚫ System programs are 9 times difficult than
utility program.
9
10. By Boehm's observation
Three levels are
⚫ Organic- application program
⚫ Semi-detached- utility program
⚫ Embedded-system program
10
11. Boehm derived an equation by analyzing the
historical data of many projects
⚫ Application program= PM*(KDSI)**1.05
⚫ Utility program = PM*(KDSI)**1.12
⚫ System program = PM*(KDSI)**1.20
*KDSI=thousand of delivered source
line or instructions
*PM=Programmer months
11
12. 12
Above graph shows that
Developing a application program
using 60,000 lines
The ratio is 1 to 1.7 to 2.8 for
application program , utility program
and system program.
13. The development time for a product
⚫ Application program TDEV=2.5*(PM)**0.38
⚫ Utility programs TDEV=2.5*(PM)**0.35
⚫ System programs TDEV=2.5*(PM)**0.32
*TDEV – development time
13
14. Graph shows that the duration
for developing all the three
types of system are same
14
15. Total programmer for a project
⚫ Application program:176.6PM / 17.85mo =9.9programmers
⚫ Utility program:294PM / 18.3mo =16programmers
⚫ System programm:489.6PM / 18.1mo =27programmers
*mo=month
15
16. Failures in estimating the number of source
instructions in a software product is to under estimate the
amount of house keeping code
Housekeeping code
⚫ portion of source code
⚫ Handles input , output , interactive user communication
,error checking and error handling
16
17. PRODUCT SIZE
17
A large software product is more expensive to develop
than a small one.
Boehm equation indicate that
⚫ “the rate of increase in required effort grows with
number of source instruction at an exponential
slightly greater than one”
19. AVAILABLE TIME
19
Project must complete within the given time and cost
Putnam’s
⚫ “project effort is inversely proportional to the fourth
power of the development time”
⚫ E=k/(TD**4)
Putnam states that , development schedule
cannot be compressed below about 86%
20. Boehm states that
⚫ “there is a limit beyond which a software project
cannot reduce its schedule by buying more personnel
and equipment”
20
21. REQUIRED RELIABILITY
21
Four main terms that express the reliability are
⚫ Accuracy
⚫ Robustness
⚫ Completeness
⚫ Consistency
22. A product which is built by these all characteristics but
there is a cost associated with different phases to ensure
high reliability
Product failure may cause slightly inconvenience high
financial loss or risk to human life
22
23. LEVEL OF TECHNOLOGY
23
A software Project is mainly reflected by
⚫ programming language
⚫ abstract machine
⚫ programming practices
⚫ software tools used
24. •
In Modern programming languages to
productivity and software reliability ,additional
24
increase
features like
⚫ strong type checking
⚫ data abstraction
⚫ separate computation
⚫ exception handling
25. •Programming practices include
⚫ systematic analysis and design technique
⚫ structure designed notations
⚫ inspection
⚫ structured coding
⚫ systematic testing
⚫ program development library
25
26. Software tools are
⚫ Assemblers
⚫ Loaders
⚫ Compilers
⚫ Other interactive tool
26
28. 🞭 Software cost estimation based on past
performance
🞭 Historical data used to identify cost factor
Methods
1. Top-down
2. Bottom-up
Top-Down:
🞭 Focuses on system level costs
🞭 Computing resources & personnel to develop the
system
🞭 Costs of Configuration management
🞭 Quality assurance
🞭 System Integration
🞭 Testing
🞭 Publications
29. Bottom –Up:
🞭 Estimates the cost to develop each module or
subsystem.
🞭 Combine overall cost.
Techniques:
1. Expert Judgment
2. Delphi Cost Estimation
3. Work Breakdown Structure
4. COCOMO Model
30. EXPERT JUDGMENT
🞭 Most widely used estimation technique
🞭 Top-down estimation technique
Ex:
Process Control System 10 months & $ 1
million cost
New System 25% more activities increase
our time and cost
🞭 Same computer and external sensing/controlling
devices & same people available to develop the
new system
🞭 Reduce our estimate by 20%
31. Advantages:
🞭 Experience
🞭 Expert confident that the project is similar to
previous one.
🞭 Group of experts prepare a consensus
estimate.
🞭 Minimize individual oversights.
32. Disadvantages:
🞭 Interpersonal group dynamics may have on
individuals in the group.
🞭 Political consideration
🞭 Dominance of an overly assertive group
member.
33. DELPHI COST ESTIMATION
🞭 Developed by Rand Corporation in 1948
🞭 Without introducing the adverse side effects
of group meetings
1. A coordinator provides each estimator with
the System Definition document
2. Estimators study the definition and complete
their estimate anonymously. Ask questions
of the coordinator.
3. Coordinator prepares and distributes a
summary of the estimators response
34. 4. Estimators complete another estimate, again
anonymously using the results from the
previous estimate.
5. The process is iterated for as many rounds
as required. No group discussion is allowed
during the entire process
35. VARIATION OF DELPHI COST ESTIMATION
1. Coordinator provides each estimator with a
system Definition and an estimation form
2. Coordinator calls a group meeting and discuss
the estimation issues with each other.
3. Estimators complete their estimates
anonymously
4. The coordinator prepares a summary of
estimates, but does not record any rationale.
5. The coordinator calls a group meeting to focus
on issues where the estimation vary widely
6. Estimators complete another estimate, again
anonymously. The process repeated so many
round
36. WORK BREAKDOWN STRUCTURE
🞭 Bottom-up estimation
🞭 Hierarchical chart individual parts of the system
🞭 WBS product hierarchy / process hierarchy
Product Hierarchy
🞭 Identifies the product components and how its interconnec
Process Hierarchy
🞭 Identifies the work activities and the relationship among tho
activities.
46. ▣ Software maintenance typically requires 40 to 60 percent, and in
some cases as much as 90 percent, of the total lifecycle effort
devoted to a software product.
The major concerns about maintenance during the
planning phase of a software projects are estimating the
number of maintenance programmers that will be
needed and specifying the facilities required for
maintenance.
A widely used rule of thumb for the distribution of
maintenance activities is
60% -Enhancement
20% -Adaptation
20% -Corrections
47. ▣ In survey 487 business data processing installations, Lientz and
Swanson determined that typical level of effort devoted to
software maintenance was around
FOR EXAMPLE:
▣ If a maintenance programmer can maintain 32KDSI, then two a
maintenance programmers are required to main 64 KDSI:
FSPm=(64KDSI)/(32 KDSI/FSP)=2 FSPm
50% of total lifecycle effort,
The distribution of maintenance activities was
51.3% for enhancement ,
23.6% for adaptation,
21.7% for repair and
3.4% for others(LIE80).
48. ▣ Boehm suggests that maintenance effort can be activity ratio ,
which is the number of source instruction to be added and
modified in any given time period divided by the total number of
instructions:
Number of programmer –months required for maintenance in the
corresponding time period:
In enhancement is provided by an effort adjustment factor EAF,
which recognizes that the effort multipliers for maintenance may
be different from the effort multipliers used for development:
ACT=(DSIadded+DSImodified)/DSItotal
PMm=ACT *MMdev
PMm=ACT *EAF*MMdev
49.
50.
51. ▣ Heavy emphasis on reliability and the use of modern programming pr
during development may reduce the amount of effort required for maintenance
low emphasis on reliability and modern practices during development
increase the difficulty of maintenance.
FSP - Fulltime Software Personnel
KSDI -Kilo delivered Source Instruction
ACT -Activity ratio
DSI -Delivered Source Instruction
PM -Programmer Months
EAF -Effort Adjustment Factor
54. 2.Formal Specifications Techniques
This techniques used for mathematical equation. In this techniques we
have two notations.
2.1. Relational Notations
It is based on the concerts of entities and attributes.
Entities are named elements and attributes are relations of entities.
In this we have
2.1.1 Implicit Equation
2.1.2 Recurrence Equation
2.1.3 Algebraic Axioms
2.1.4 Regular Expressions
55. 2.1.1 Implicit Equation
Implicit equations specify the properties of a solution without stating a solution
method. Matrix inversion is specified as follows
M x M ' = I + E
Matrix inversion has the property that the original matrix (M) multiplied by its inverse
(M1 ) yield an identify matrix, I denotes the identify matrix and E specifies allowable computational
errors
2.1.2 Recurrence Relations
Its consists of an initial part called basis and one or more recursive parts
Example: Fibonacci Series
F(0) = 0
F(l)=l
F(N) = F(N-1) + F(N-2) for N>1
56. 2.1.3 Algebraic Axioms
It is used to specify the properties of abstract data types
Example: Stack
( Stk is of type STACK, itm is of type ITEM)
l. EMPTY(NEW) = true
2. EMPTY(PUSH(Stk,itm)) = false .
3. POP(NEW) = error
4. TOP(NEW) = error
5. POP(PUSH(stk,itm)) = stk
6. TOP(PUSH(stk,itm)) = item
57. 2.1.4 Regular Expressions
The rules for forming regular expressions are as follows.
Axioms: The basis symbols in the alphabet of interest form regular expressions.
Alternation: If Rl and R2 are regular expressions, then (R1/R2) is a regular expression.
Composition: If Rl and R2 are regular expressions, then (R1.R2) is a RE
Closure: If Rl is a regular expressions, then (Rl)* is a regular expression.
Completeness: Nothing else is a regular expression.
Example: (a(b/c)) denotes {ab,ac}
58. 2.2 STATE ORIENTED NOTATION
2.2.1 Decision Table
2.2.2 Events Tables
2.2.3 Transition Tables
2.2.4 Finite State Mechanisms
2.2.5 Petri Nets
2.2.1 Decision tables
Decision tables are widely used in data processing application. A decision table is
segmented into four quadrants, condition state, condition entry, action states and action entry
Example:
59. 2.2.2 Event tables
specify actions to be taken when events occur under different set of conditions.
Event tables are viewed as two- dimensional tables or of higher dimension.
Example:
2.2.3 Transition Table
Transition Tables are used to specify changes in the state of a system as a function of next state
Current State Current Input
INPUT A B
S0 S0 S1
S1 S1 S0
(next state)
60. 2 .2.4 Finite State Mechanisms:
utilize data flow diagrams in which the data streams are specified
using regular expressions and the actions in the processing nodes are specified
using transition labels.
61. 2.2.5 Petri Net
It represent the technique and systematic methods have been
developed for synthesizing and analysing petri nets. Petri nets were invented to
overcome the limitations of finite state mechanisms in specifying parallelism.
62. Formal methods
• Formal specification is part of a more general
collection of techniques that are known as ‘formal
methods’ COMP313 “Formal Methods”
These are all based on mathematical
representation and analysis of software
• Formal methods include
• Formal specification
• Specification analysis and proof
• Transformational development
• Program verification
63. Acceptance of formal methods
• Formal methods have not become mainstream
software development techniques as was once
predicted
• Other software engineering techniques have been successful
at increasing system quality. Hence the need for formal
methods has been reduced
• Market changes have made time-to-market rather than
software with a low error count the key factor. Formal
methods do not reduce time to market
• The scope of formal methods is limited. They are not well-
suited to specifying and analysing user interfaces and user
interaction
• Formal methods are hard to scale up to large systems
64. Use of formal methods
• Their principal benefits are in reducing the number of errors in systems so their
main area of applicability is critical systems:
• Air traffic control information systems,
• Railway signalling systems
• Spacecraft systems
• Medical control systems
• In this area, the use of formal methods is most likely to be cost-effective
• Formal methods have limited practical applicability
65. Specification in the software process
• Specification and design are inextricably
mixed.
• Architectural design is essential to structure a
specification.
• Formal specifications are expressed in a
mathematical notation with precisely defined
vocabulary, syntax and semantics.
67. Specification in the software process
Requirements
specification
Formal
specification
System
modelling
Architectural
design
Requirements
definition
High-level
design
68. Specification techniques
• Algebraic approach
• The system is specified in terms of its operations and their
relationships
• Model-based approach
• The system is specified in terms of a state model that is
constructed using mathematical constructs such as sets and
sequences.
• Operations are defined by modifications to the system’s
state
69. Formal specification languages
Sequential Concurrent
Algebraic Larch (Guttag, Horning et
al., 1985; Guttag,
Horning et al., 1993),
OBJ (Futatsugi, Goguen
et al., 1985)
Lotos (Bolognesi and
Brinksma, 1987),
Model-based Z (Spivey, 1992)
VDM (Jones, 1980)
B (Wordsworth, 1996)
CSP (Hoare, 1985)
Petri Nets (Peterson,
1981)
ASML - Abstract State Machine Language
Yuri. Gurevich, Microsoft Research, 2001
70. Use of formal specification
• Formal specification involves investing more effort in
the early phases of software development
This reduces requirements errors as it forces a
detailed analysis of the requirements
• Incompleteness and inconsistencies can be discovered
and resolved !!!
Hence, savings as made as the amount of rework
due to requirements problems is reduced
71. Development costs with formal specification
Specification
Design and
Implementation
Validation
Specification
Design and
Implementation
Validation
Cost
Without formal
specification
With formal
specification
72. 1. Interface specification
• Large systems are decomposed into subsystems with
well-defined interfaces between these subsystems
• Specification of subsystem interfaces allows
independent development of the different subsystems
• Interfaces may be defined as abstract data types or
object classes
The algebraic approach to formal specification is
particularly well-suited to interface specification
74. The structure of an algebraic specification
sort < name >
imports < LIST OF SPECIFICATION NAMES >
Informal description of the sort and its operations
Operation signatures setting out the names and the types of
the parameters to the operations defined over the sort
Axioms defining the operations over the sort
< SPECIFICATION NAME > (Gener ic Parameter)
introduction
description
signature
axioms
75. Behavioural specification
• Algebraic specification can be cumbersome when the object
operations are not independent of the object state
• Model-based specification exposes the system state and
defines the operations in terms of changes to that state
77. Abstract State Machine Language (AsmL)
• AsmL is a language for modelling the structure and
behaviour of digital systems
• AsmL can be used to faithfully capture the abstract
structure and step-wise behaviour of any discrete
systems, including very complex ones such as:
Integrated circuits, software components, and devices that combine both
hardware and software
78. Abstract State
• An AsmL model is said to be abstract because it encodes only
those aspects of the system’s structure that affect the
behaviour being modelled
The goal is to use the minimum amount of detail that
accurately reproduces (or predicts) the behaviour of the
system
• Abstraction helps us reduce complex problems into
manageable units and prevents us from getting lost in a sea
of details
AsmL provides a variety of features that allow you to
describe the relevant state of a system in a very
economical, high-level way
79. Abstract State Machine and Turing
Machine
• An abstract state machine is a particular kind of
mathematical machine, like the Turing machine
(TM)
• But unlike a TM, ASMs may be defined a very high
level of abstraction
• An easy way to understand ASMs is to see them
as defining a succession of states that may follow
an initial state
80. State transitions
• The behaviour of a machine (its run) can always be
depicted as a sequence of states linked by state
transitions
• Moving from state A to state B is a state
transition
paint in green
paint in red
A B
81. Configurations
• Each state is a particular “configuration” of the
machine
• The state may be simple or it may be very large,
with complex structure
• But no matter how complex the state might be,
each step of the machine’s operation can be seen
as a well-defined transition from one particular
state to another
82. Evolution of state variables
paint in green
paint in red
A B
We can view any machine’s state as a dictionary of
(Name, Value)
pairs, called state variables
(Colour, Red) is a variable, where “Colour” is
the name of variable, “Red” is the value
83. Evolution of state variables
• Names are given by the machine’s symbolic
vocabulary
• Values are fixed elements, like numbers and strings
of characters
The run of a machine is a series of
states and state transitions that
results form applying operations
to each state in succession
84. Example
Diagram shows the run of a machine that models how orders might be
processed
S1
Mode = “Initial”
Orders = 0
Balance = £0
Initialise Process All Orders
S3
Mode = “Final”
Orders = 0
Balance = £500
S2
Mode = “Active”
Orders = 2
Balance = £200
Each transition operation:
• can be seen as the result of invoking the machine’s
control logic on the current state
• calculates the subsequence state as output
85. Control Logic
The machine’s control logic
behaves like a fix set of transition
rules that say how state may evolve
We can think of the control logic as a text that
precisely specifies, for any given state, what the
values of the machine’s variables will be in the
following step
Typical form of the operational text is:
“ if condition then update ”
86. Control Logic as a Black Box
• The two dictionaries S1 and S2 have the same set of keys,
but the values associated with each variable name may
differ between S1 and S2
The Machine’s Control
Logic
…
if mode = “Initial”
then mode := “Active”
mode “Initial”
orders 0
balance £0
Mode “Active”
orders 2
balance £200
input
output
• The machine control logic is a black box that takes as input a
state dictionary S1 and gives as output a new dictionary S2
87. Run of the Machine
• The run of the machine can be seen as what happens when the control logic is
applied to each state in turn
• The run starts form initial state
S1 S2 S3 …
S1 is given to the black box yielding S2, processing S2 results in S3,
and so on …
• When no more changes to state are possible, the run is complete
88. Update operations
• We use the symbol
“: =” (reads as “gets”)
to indicate the value that a name will have in the
resulting state
For example: mode:=“Active”
• Update can be seen only during the following step (this
is in contrast to Java, C, Pascal, …)
• All changes happen simultaneously, when you moving
from one step to another. Then, all updates happen at
once.(atomic transaction)
89. Programs
Example 1. Hello, world
Main()
step WriteLine(“hello, world!”)
ASML uses indentations to denote block structure, and blocks can
be places inside other blocks
Statement block affect the scope of variables
Whitespace includes blanks and new-line character, ASML does not
recognize tab character for indentation !!!!!!!
An operation names run() gives the top-level operational definition
of the model (Main() is like main() in Java and C )
90. Example 2. Reading a file
var F as File? = undef
var Fcontents as String = “”
var Mode as String = “Initial”
Main()
step until fixpoint
if Mode = “Initial” then
F :=open(“mfile.txt”)
Mode :=“Reading”
if Mode = “Reading” and length(FContents) =0 then FContents :=fread (F,1)
if Mode = “Reading” and length(FContents) =1 then FContents := FContents + fread (F,1)
if Mode = “Reading” and length(FContents) >1 then
WriteLine (FContents)
Mode :=“Finished”
92. Key points
• Formal system specification complements informal specification
techniques
• Formal specifications are precise and unambiguous. They remove
areas of doubt in a specification
• Formal specification forces an analysis of the system requirements at
an early stage. Correcting errors at this stage is cheaper than
modifying a delivered system
93. Key points
• Formal specification techniques are most applicable in the
development of critical systems and standards.
• Algebraic techniques are suited to interface specification where the
interface is defined as a set of object classes
• Model-based techniques model the system using sets and functions.
This simplifies some types of behavioural specification
95. 3. LANGUAGES AND PROCESSORS FOR REQUIREMENT SPECIFICATION
3.1 PSL/PSA(Problem Statement Language/Analyzer)
Originally developed for data processing applications. Widely used in other applications.
In PSL, system descriptions can be divided into eight major aspects:
System input/output flow.
System structure
Data structure
Data derivation
System size and volume
System dynamics
System properties
Project management
96. 3.2 RSL/REVS(Requirement Statement Language/Requirement Engineer
Validation System)
Real time process control systems
Major Components are
1.A translator for RSL.
2.A centralized database, the abstract semantic model(ASSM)
3.A set of automated tools for processing information in ASSM.
3.3 SADT(Structured Analysis and Design Technique)
Interconnection structure of any large, complex system.
Not restricted to software systems.
97. 3.4 SSA(Structured System Analysis)
Two similar versions of SSA are
Gane and Sarson version used in data processing
applications that have data base requirements.
DeMarco version suited to data flow analysis of software
systems.
3.5 Gist
Object-oriented specification and design.
Refinement of specifications into source code.
98.
99. LANGUAGES AND PROCESSORS FOR
REQUIREMENTS SPECIFICATION
A number of special purpose languages and processors
have been developed to permit concise statement and
automated analysis of requirements specification for
software.
our purpose is to provide a brief introduction to
requirements specification languages and processors.
100. PSL/PSA
problem statement language(PSL) was developed by professor
Daniel teich row at the university on Michigan
The problem statement analyzer is the PSL processor
PSL and PSA system is sometimes referred to as components
of the ISDOS project
PSL/PSA system is sometimes referred to as the ISDOS
system
101. PSL system descriptions can be divided into eight major
aspects:
system input/output flow
System structure
Data structure
Data derivation
System size and volume
System dynamics
System properties
project management
System input/output flow
The system I/o flow aspect deals with the interaction
between a system and its environment.
102. System structure
system structure is concerned with the hierarchies among objects in
a system.
Data structure
data structure aspect includes all the relationships that exist among
data used and/or manipulated by a system as seen by the users of
the system.
Data derivation
The data derivation aspect of the system description specifies
which data object are involved in particular processes in the system.
103. System size and volume
The system size and volume aspect is concerned with the size of the system
and those factors the volume of processing required.
System dynamic
Aspect of a system description presents the manner in which the system”
behaves” over time.
project management requires that project related information.
104. PSA (PROBLEM STATEMENT ANALYZER)
PSA is an automated analyzer for processing requirements
stated in PSL.
PSA system can provide reports in four categories
Data base modification reports , reference reports , summary
reports and analysis reports
106. RSL/REVS
The requirements statement language(RSL) was developed by the
TRW defense and space Systems group to permit concise .
The Requirements engineering validation system(REVS)processes
and analyzes RSL statements.
The fundamental characteristic of RSL is the flow oriented approach
used to describe real-time systems.
The requirements engineering and validation system (REVS)
operates on RSL statements.
107. REVS CONSISTS OF THREE MAJOR
COMPONENTS
A translator for RSL
A centeralized data base the Abstract System Semantic
Model(ASSM).
A set of automated tools for processing information in ASSM.
108. STRUCTURED ANALYSIS AND DESIGN TECHNIQUE
(SADT)
SADT was developed by D.T Ross and colleagues at
softtech, inc.
The SADT language is called the language of Structured Analysis(SA).
Data diagram specify data object in the nodes and activities on the arcs.
Activity diagram the inputs and output are data flows and the mechanisms are
processors control is data that is used, but not modified
109. ACTIVITY DIAGRAM COMPONENTS
ACTIVITY Source
program
interpreter
Interpreter
data Source
program
Computed
result
output
Source
Input
data
Control data
processor
data
110. DATA DIAGRAM COMPONENTS
DATA OUTPUT
DATA
Operating
system
Generating
activity
Control activity
Storage device
Using
activity
Disk
Printer
spool
Interpreter
