Software Development life cycle

models

[Link]
 SDLC
• A framework that describes the activities performed at each stage of a
software development project.
• The development process defines what to do and when to complete and the
order of tasks.
• A software lifecycle model is a standardised format for planning ,
organising, and running a new development project.
• It defines the Project specific parameters which includes size, (person-
years),Budget,Duration.
project plan =
lifecycle model + project parameters
• Within the product lifecycle, software will undergo maintenance to correct
errors and to comply with changes to requirements.

[Link]
 Typical Phases in Software
Development

Feasibility study
Feasibility Implementation
Strategy planning
Component
Elicitation Integration
Requirements Testing
Statement Installation

System Operations
Analysis Maintenance
Detailed Support

System
Design Retirement
Detailed

[Link]
 Activities During Phases
• Requirements: establish the customer’s needs

• System Design: develop the system’s structure

• Detailed Design: develop module structures

• Implementation: code or otherwise

• Testing: check what’s been developed

• Installation: bring the system into production

• Maintenance: correct, adapt, improve

[Link]
Classifications of SDLC Model

SDLC Model

Sequential Progressive Iterative

V Model Waterfall

[Link]
b. Waterfall Model
Requirements
Specification
Architectural
Design
Detailed
Design
Code and Unit
Testing
Software
Integration
System
Integration
Acceptance
Testing

[Link]
 Different Phases of Sequential
Model :
• Requirements phase - in which the requirements for the software are
gathered and analyzed, to produce a complete and unambiguous
specification of what the software is required to do
• Detailed Design phase - where the detailed implementation of each
component is specified.
• Code and Unit Test phase - in which each component of the software is
coded and tested to verify that it faithfully implements the detailed
design.
• Software Integration phase - in which progressively larger groups of
tested software components are integrated and tested until the software
works as a whole.
• System Integration phase - in which the software is integrated to the
overall product and tested.
• Acceptance Testing phase, where tests are applied and witnessed to
validate that the software faithfully implements the specified
requirements.
• Software specifications will be products of the first three phases of this
lifecycle model. The remaining four phases all involve testing the
software at various levels, requiring test specifications against which the
testing will be conducted as an input to each of these phases.

[Link]
 Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff,
track)
• Works well when quality is more important
than cost or schedule

[Link]
 disadvantages
• Idealised, doesn’t match reality well.
• Doesn’t reflect iterative nature of exploratory development.
• Unrealistic to expect accurate requirements so early in project
• Software is delivered late in project, delays discovery of serious errors.
• Difficult to integrate risk management
• Difficult and expensive to make changes too documents.
• Significant administrative overhead,
• costly for small teams and projects

[Link]
 When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.

[Link]
 3. Iterative Model
Requirements Design

Implementation
Review
and Test

• An iterative lifecycle model does not attempt to start with a full

specification of requirements.
• Instead, development begins by specifying and implementing just part of
the software, which can then be reviewed in order to identify further
requirements.
• This process is then repeated, producing a new version of the software for
each cycle of the model.

[Link]
 3. Iterative Model - Phases
• Requirements phase, in which the requirements for the
software are gathered and analyzed. Iteration should
eventually result in a requirements phase which produces a
complete and final specification of requirements.
• Design phase, in which a software solution to meet the
requirements is designed. This may be a new design, or an
extension of an earlier design.
• Implementation and Test phase, when the software is
coded, integrated and tested.
• Review phase - in which the software is evaluated, the
current requirements are reviewed, and changes and
additions to requirements proposed

[Link]
Rapid Application Model (RAD)
• Requirements planning phase (a workshop utilizing
structured discussion of business problems)
• User description phase – automated tools capture
information from users
• Construction phase – productivity tools, such as code
generators, screen generators, etc. inside a time-box.
(“Do until done”)
• Cutover phase -- installation of the system, user
acceptance testing and user training.

[Link]
 RAD Strengths
• Reduced cycle time and improved productivity with fewer
people means lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle minimizes
risk of not achieving customer satisfaction and business needs
• Focus moves from documentation to code.
• Uses modeling concepts to capture information about business,
data, and processes.

[Link]
 RAD Weaknesses
• Accelerated development process must give quick responses to
the user

• Risk of never achieving closure

• Hard to use with legacy systems

• Requires a system that can be modularized

• Developers and customers must be committed to rapid-fire

activities in an abbreviated time frame.

[Link]
 When to use RAD
• Reasonably well-known requirements
• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized

[Link]
 The Unified Process
• Booch, Jacobson, and Rumbaugh later developed the unified
process, which is a framework for object-oriented software
engineering using UML
– Draws on the best features and characteristics of conventional
software process models
– Emphasizes the important role of software architecture
– Consists of a process flow that is iterative and incremental,
thereby providing an evolutionary feel

• Consists of five phases: inception, elaboration, construction,

transition, and production

[Link]
Phases of the Unified Process
Inception Elaboration

planning

modeling
communication

construction
Construction

deployment

Production Transition

[Link]
 Inception Phase
• Encompasses both customer communication and planning activities of
the generic process

• Business requirements for the software are identified

• A rough architecture for the system is proposed

• A plan is created for an incremental, iterative development

• Fundamental business requirements are described through preliminary

use cases

– A use case describes a sequence of actions that are performed by a

user

[Link]
 Elaboration Phase
• Encompasses both the planning and modelling activities of the generic process

• Refines and expands the preliminary use cases

• Expands the architectural representation to include five views

– Use-case model

– Analysis model

– Design model

– Implementation model

– Deployment model

• Often results in an executable architectural baseline that represents a first cut

executable system

• The baseline demonstrates the viability of the architecture but does not provide
all features and functions required to use the system

[Link]
 Construction Phase

• Encompasses the construction activity of the generic process

• Uses the architectural model from the elaboration phase as input

• Develops or acquires the software components that make each use-

case operational

• Analysis and design models from the previous phase are completed
to reflect the final version of the increment

• Use cases are used to derive a set of acceptance tests that are
executed prior to the next phase

[Link]
 Transition Phase
• Encompasses the last part of the construction activity and the first
part of the deployment activity of the generic process

• Software is given to end users for beta testing and user feedback
reports on defects and necessary changes

• The software teams create necessary support documentation (user

manuals, trouble-shooting guides, installation procedures)

• At the conclusion of this phase, the software increment becomes a

usable software release

[Link]
 Production Phase

• Encompasses the last part of the deployment activity of the generic

process

• On-going use of the software is monitored

• Support for the operating environment (infrastructure) is provided

• Defect reports and requests for changes are submitted and evaluated

23
[Link]
 Evolutionary Development..
• Main characteristics:
– The phases of the software construction are interleaved

– Feedback from the user is used throughout the entire process

– The software product is refined through many versions

• Types of evolutionary development:

– Exploratory development

– Throw-away prototyping

[Link]
 Evolutionary Development..
• Advantages:
– Deals constantly with changes
– Provides quickly an initial version of the system
– Involves all development teams
• Disadvantages:
– Quick fixes may be involved

– “Invisible” process, not well-supported by documentation

– The system’s structure can be corrupted by continuous change

– Special tools and techniques may be necessary

– The client may have the impression the first version is very close to
the final product and thus be less patient

[Link]
Incremental model

[Link]
 Incremental model
• Construct a partial implementation of a total system

• Then slowly add increased functionality

• The incremental model prioritizes requirements of the system and

then implements them in groups.

• Each subsequent release of the system adds function to the

previous release, until all designed functionality has been
implemented.

[Link]
 Incremental Model Strengths

• Develop high-risk or major functions first

• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced
[Link]
 Incremental Model
Weaknesses
• Requires good planning and design

• Requires early definition of a complete and fully

functional system to allow for the definition of increments

• Well-defined module interfaces are required (some will be

developed long before others)

• Total cost of the complete system is not lower

[Link]
When to use the Incremental Model
• Risk, funding, schedule, program complexity, or need for
early realization of benefits.

• Most of the requirements are known up-front but are

expected to evolve over time

• A need to get basic functionality to the market early

• On projects which have lengthy development schedules

• On a project with new technology

[Link]
 Spiral Quadrant
Determine objectives, alternatives and constraints

• Objectives: functionality, performance, hardware/software

interface, critical success factors, etc.
• Alternatives: build, reuse, buy, sub-contract, etc.
• Constraints: cost, schedule, interface, etc.

[Link]
 Spiral Quadrant
Evaluate alternatives, identify and resolve risks

• Study alternatives relative to objectives and constraints

• Identify risks (lack of experience, new technology, tight
schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost by continuing
system development

[Link]
 Spiral Quadrant
Develop next-level product
• Typical activities:
– Create a design
– Review design
– Develop code
– Inspect code
– Test product

[Link]
 Spiral Quadrant
Plan next phase
• Typical activities
– Develop project plan
– Develop configuration management plan
– Develop a test plan
– Develop an installation plan

[Link]
 Spiral Model Strengths
• Provides early indication of insurmountable risks,
without much cost
• Users see the system early because of rapid
prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently

[Link]
 Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-risk projects
• Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development phase
activities
• May be hard to define objective, verifiable milestones that indicate
readiness to proceed through the next iteration

[Link]
 When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential
changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)

[Link]
 Agile Software Development
• Agile software development is a conceptual framework for
software engineering that promotes development iterations
throughout the life-cycle of the project.

• Software developed during one unit of time is referred to as an

iteration, which may last from one to four weeks.

• Agile methods also emphasize working software as the primary

measure of progress

[Link]
 Agile Software Development:
Intro
• Characteristics of Agile Software Development
-- Light Weighted methodology
-- Small to medium sized teams
-- vague and/or changing requirements
-- vague and/or changing techniques
-- Simple design
-- Minimal system into production

[Link]
 Characteristics
• Modularity
• Iterative
• Time-bound
• Incremental
• Convergent
• People-oriented
• Collaborative

[Link]
 Disadvantages
• Agile is difficult as It Requires more TESTING & active
CUSTOMERS involvement.
• Agile is More disciplined. The code may be integrated
continuously, sometime after every update in source code
repository. Needs teams and self-discipline
• More Planning is needed Since the planning is done frequently (for
each iteration), and the plan is updated as and when needed more
focused planning needs to be done.
• The plan has to be adaptive to meet the changing requirements.

[Link]
 Software
• What Is Software?
Computer software is the product that
software professionals design and build.
• It encompasses
– Programs
– Content
– Documents

[Link]
 Information

Software Operating System

Vehicle to deliver the
product Network Software
Case tools

[Link]
 What is Software Engineering
• Solving Problems
• Software products are large and complex
• Development requires analysis and synthesis
– Analysis: decompose a large problem into smaller,
understandable pieces
• abstraction is the key
– Synthesis: build (compose) a software from smaller
building blocks
• composition is challenging

[Link]
 Con..
• The analysis process

[Link]
 Con..
• The synthesis process

[Link]
 What is Software Engineering
Solving Problems (continued)

• Method: refers to a formal procedure; a formal “recipe” for

accomplishing a goal that is typically independent of the tools
used
• Tool: an instrument or automated system for accomplishing
something in a better way
• Procedure: a combination of tools and techniques to produce
a product
• Paradigm: philosophy or approach for building a product
(e.g., OO vs structured approaches)

[Link]
 What is Software Engineering
Where Does the SW Engineer Fit in? (continued)
• Relationship between computer science and software
engineering

[Link]
 Characteristics
• Software does not wear out
• It becomes reliable over time.
• It becomes obsolete based on new changes
• Software is not manufactured
• One time development efforts
• Continuous maintenance efforts.
• Reusability of components
• Not a single product as a whole
• Every component – Single process
• Component based Software Engineering
• Software is flexible
• Can be made flexible
• Leads to unpredictability

[Link]
 The Evolving Role of Software

• The Evolving Role of Software

• Software takes on a dual role:
• A product
– Delivers the computing potential embodied by
computer hardware
• The vehicle for delivering a product
– Acts as the basis for the control of the computer
(OS), the communication of information
(networks), and the creation and control of other
programs (software tools and environments)
– The most important product: Information
[Link]
 Changing Nature of Software
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software (e.g., inventory control, word processing,
multimedia)
• Web applications
• Artificial intelligence software
• Ubiquitous computing (small, wireless devices)
• Netsourcing (net-wide computing)
• Open source (operating systems, databases, development
environments)
• The ".com" marketing applications

[Link]
Types of Software
• System software
– it services other programs
– heavy interaction with hardware,
• Real-time software
– data gathering component
– analysis component
– monitoring component
• Business software
– largest single software area
– MIS important component
• Engineering and scientific software
– number crunching numerical algorithms
[Link]
Types of Software
• Embedded software
– resides in read-only memory of any appliances
– controls products and system for consumers
• PC software
– several hundreds of applications available as
software packages
• Web-based software
– unlimited software resource
• AI software
– makes use of non-numerical algorithms
– expert systems, pattern recognition, games

[Link]
 Software Myths -
Management
• "We already have a book that is full of standards and procedures for
building software. Won't that provide my people with everything
they need to know?"
– Not used, not up to date, not complete, not focused on quality, time, and
money
• "If we get behind, we can add more programmers and catch up"
– Adding people to a late software project makes it later
– Training time, increased communication lines
• "If I decide to outsource the software project to a third party, I can
just relax and let that firm build it"
– Software projects need to be controlled and managed

[Link]
 Software Myths - Customer

• "A general statement of objectives is sufficient to begin writing

programs – we can fill in the details later"
– Ambiguous statement of objectives spells disaster
• "Project requirements continually change, but change can be
easily accommodated because software is flexible"
– Impact of change depends on where and when it occurs in the
software life cycle (requirements analysis, design, code, test)

[Link]
 Software Myths - Practitioner
• "Once we write the program and get it to work, our job is done"
– 60% to 80% of all effort expended on software occurs after it is
delivered
• "Until I get the program running, I have no way of assessing its
quality
– Formal technical reviews of requirements analysis documents,
design documents, and source code (more effective than actual
testing)
• "The only deliverable work product for a successful project is the
working program"
– Software, documentation, test drivers, test results
• "Software engineering will make us create voluminous and
unnecessary documentation and will invariably slow us down"
– Creates quality, not documents; quality reduces rework and
provides software on time and within the budget


[Link]
Software Planning

[Link]
 Problem
• Projects: Needs quantitative estimates and
organized plan.
• Requirement changes as the project
proceeds
• Important to define
1. Definition of problem
2. Scope of problem
3. Decomposition of problem

[Link]
 Software Scope
• First activity in Project Management
• It can be the answers of
1. Context:
How to make the system fit for all levels?
What are the constraints for the same?
2. Information Objectives:
What visible objects are projected as output.
What input is required for the same.
3. Function and Performance:
Regular functions (Input to Output)
Special functions
[Link]
 Problem Decomposition
• Defined as Partitioning
• Sits at the core of Requirement analysis.
• Two major areas:
1. Functionality – needs to be delivered.
2. The process – to deliver the same.
• Software functions – evaluated in the beginning
• Cost, Schedule estimation – based on
decomposition
• Some degree of decomposition – always good.

[Link]
 Software Metrics

Measurement can be applied

• to the software process with the intent of
improving
• to assist in estimation, quality control,
productivity assessment, and project
control
• to help assess the quality of technical work
products and to assist in tactical decision
making as a project proceeds
[Link]
 MEASURES , METRICS , AND
INDICATORS
a measure provides a quantitative indication of the extent,
amount, dimensions, capacity, or size of some attribute of a
product or process.

a metric as " a quantitative measure of the degree to which a

system, component, or process possesses a given attribute”.

an indicator is a metric or combination of metrics that provide

insight into the software process, a software project, or the
product itself .

A software engineer collects measures and develops metrics

so that indicators will be obtained .

[Link]
 Project indicators

enable a software project manager to assess the

• status of an ongoing project

• track potential risks
• uncover problem areas before they "go critical“
• adjust work flow or tasks
• evaluate the project team's ability to control
quality of software engineering work products.

[Link]
Cont…

[Link]
 Project Metrics
Used for strategic purposes
– by a project manager and a software team to
adapt project work
– flow and technical activities .
Project metrics on estimation
effort and time duration estimates
Production rates
–pages of documentation,
–review hours,
–function points,
–delivered source lines

[Link]
 Con..
The intent of project metrics is twofold :
–to minimize the development schedule,
–to assess product quality on an ongoing basis and when
necessary, modify the technical approach to improve
quality.
Every project should measure:
Inputs - measures of the resources (e.g., people,
environment) required to do the work
Outputs - measures of the deliverables or work products
created during the software engineering process
Results - measures that indicate the effectiveness of the
deliverables

[Link]
 SOFTWARE MEASUREMENT
Direct measures (e.g., the length of a bolt)
Indirect measures (e.g., the "quality" )
Direct measures
–lines of code (LOC)
–execution speed
–memory size
–defects reported over some set period of time
Indirect measures
·functionality, quality, complexity, efficiency,
reliability,
·maintainability and many other "abilities"

[Link]
 Size-Oriented Metrics
Derived by normalizing quality and or productivity measures by considering the "size" of
the software

[Link]
 Con..
A set of simple size -oriented metrics can be
developed for each project:
• errors per KLOC (thousand lines of code)
• defects per KLOC
• $ per LOC
• pages of documentation per LOC
other interesting metrics:
• errors/person-month
• LOC per person-month
• $/page of documentation

[Link]
Function-Oriented Metrics
Use a measure of the functionality delivered by the application as a
normalization value. Function-oriented metrics were first proposed
by Albrecht.

[Link]
 Con..
Number of user inputs. Each user input that provides distinct application
oriented data to the software is counted. Inputs should be distinguished from
inquiries, which are counted separately.

Number of user outputs. Each user output that provides application-

oriented information to the user is counted. In this context output refers to
reports, screens, error messages, and so on. Individual data items within a
report are not counted separately.

Number of user inquiries. An inquiry is defined as an on-line input that

results in the generation of some immediate software response in the form of
an on-line output. Each distinct inquiry is counted.

Number of files. Each logical master file (i.e., a logical grouping of data that
may be one part of a large database or a separate file), is counted.

Number of external interfaces. All machine readable interfaces (e.g., data

files on tape or disk) that are used to transmit information to another system
are counted.

[Link]
COMPUTING FUNCTION POINTS

Once the above data have been collected, a

complexity value is associated with each
count.
For determining whether a particular entry,
–simple,
–average,
–complex.
To compute function points (FP),
FP = count-total x [0.65 + 0.01 x SFi]
The Fi ( i = 1 to 14) are "complexity
adjustment values"
[Link]
Con…

[Link]
 Con..
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10.. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease o f use by the user?

[Link]
 Feature point metrics
• FP doesn’t solve algorithmic complexity of a
software.
• It implies that developing efforts of two functionally
same programs are same.
• To resolve the same, feature point is proposed.
• It includes additional parameter – algorithmic
complexity.
• More complexity of the function – greater efforts to
develop it.
• These are language independent and easily
computed from SRS document.

[Link]
 Software Estimation
Determine size of the product.
From the size estimate,
determine the effort needed.
From the effort estimate,
determine project duration, and cost.

[Link]
Software Cost Estimation

[Link]
 Three approaches
• Empirical
• Heuristic
• Analytical

[Link]
 Cost Estimation Techniques
Empirical techniques:
An educated guess based on past
experience.
Heuristic techniques:
Assume that the characteristics to be
estimated can be expressed in terms of some
Mathematical expression.
Analytical techniques:
Derive the required results starting from
certain simple assumptions.

[Link]
 Empirical Estimation Techniques
Expert Judgement:
A guess made by an expert.
Suffers from individual bias.
Delphi Estimation:
Overcomes some of the problems of
expert judgement.

[Link]
 Expert Judgment Technique
• Experts divide a software product into
component units:
e.g. GUI, database module, data communication
module, billing module, etc.
• Add up the guesses for each of the
components.
• Subject to human errors and individual bias.
• Experts may overlook some factors.
• Understanding all the aspects would be
difficult.
[Link]
 Delphi Estimation
• Team of Experts and a coordinator.
• Experts carry out estimation independently.
• Mention the rationale behind their estimation.
• Coordinator notes down any extraordinary
rationale.
• Circulates among experts.
• Experts re-estimate.
• Experts never meet each other
• To discuss their viewpoints.

[Link]
 Heuristic – COCOMO Model
• COCOMO (COnstructive COst MOdel)
proposed by Boehm.
• Divides software product developments into 3
categories:
• Organic
• Semidetached
• Embedded

[Link]
 Con.. Elaboration of Product
classes
Organic:
Development of well understood appl. Program.
Size is very small.
Team members develop similar applications.
Semidetached:
If it contains the mix of experienced and inexperienced staff.
Embedded:
The software is strongly coupled to complex hardware, or
real-time systems.

[Link]
 Con..
• Software cost estimation is done through
three stages:
– Basic COCOMO,
– Intermediate COCOMO,
– Complete COCOMO.

[Link]
 Basic COCOMO Model
• Gives only an approximate estimation:
– Effort = a1*(KLOC)a2
– Tdev = b1*(Effort)b2
KLOC is the estimated kilo lines of source code,
a1,a2,b1,b2 are constants for different
categories of software products,
Tdev is the estimated time to develop the
software in months,
Effort estimation is obtained in terms of person
months (PMs).

[Link]
 Development Effort Estimation
• Organic :
Effort = 2.4*(KLOC)1.05 PM
• Semi-detached:
Effort = 3.0*(KLOC)1.12 PM
• Embedded:
Effort = 3.6*(KLOC)1.20 PM

[Link]
 Development Time Estimation
• Organic:
Tdev = 2.5*(Effort)0.38 Months
• Semi-detached:
Tdev = 2.5*(Effort)0.35 Months
• Embedded:
Tdev = 2.5*(Effort)0.32 Months

[Link]
 Con.
• Development time
sub linear function of product size.
• When product size increases two times,
development time does not double.
• Time taken:
almost same for all the three product
categories.

[Link]
 Con..
• Development time is roughly the same for
all the three categories of products:
• For example, a 60 KLOC program can be
developed in approximately 18 months
regardless of whether it is of
organic, semidetached, or embedded type.
• There is more scope for parallel activities for
system and application programs,
• than utility programs.

[Link]
 Intermediate COCOMO
Basic COCOMO model assumes
– effort and development time depend on
product size alone.
However, several parameters affect effort
and development time:
– Reliability requirements
– Availability of CASE tools and modern
facilities to the developers
– Size of data to be handled

[Link]
 Con..
For accurate estimation,
• the effect of all relevant parameters must
be considered:
Intermediate COCOMO model recognizes
this fact:
• refines the initial estimate obtained by the
basic COCOMO by using a set of 15 cost
drivers (multipliers).

[Link]
 Con..
If modern programming practices are used,
• initial estimates are scaled downwards.
If there are stringent reliability requirements on
the product :
• initial estimate is scaled upwards.
Rate different parameters on a scale of one to
three:
• Depending on these ratings, multiply cost
driver values with the estimate obtained using
the basic COCOMO

[Link]
Cost driver classes:
• Product: Inherent complexity of the
product, reliability requirements of the
product, etc.
• Computer: Execution time, storage
requirements, etc.
• Personnel: Experience of personnel, etc.
• Development Environment: Sophistication
of the tools used for software
development.

[Link]
 Shortcomings of two models
Both models:
consider a software product as a single
homogeneous entity:
However, most large systems are made up of
several smaller sub-systems.
– Some sub-systems may be considered as
organic type, some may be considered
embedded, etc.
– for some the reliability requirements may be
high, and so on.

[Link]
 Complete COCOMO
A Management Information System (MIS) for
an
organization having offices at several places
across the country:
– Database part (semi-detached)
– Graphical User Interface (GUI) part (organic)
– Communication part (embedded)
• Costs of the components are estimated
separately:
Summed up to give the overall cost of the system.

[Link]
 Con..
A Management Information System (MIS) for an
organization having offices at several places
across the country:
– Database part (semi-detached)
– Graphical User Interface (GUI) part (organic)
– Communication part (embedded)
Costs of the components are estimated
separately:
• summed up to give the overall cost of the system.

[Link]
The Activities of the Analysis Phase

[Link]
Activities of the Analysis Phase
and Their Key Questions

[Link]
 Techniques for Information
Gathering
• Analysis phase done to understand business
functions and develop system requirements
• Original structured approach
– Create model of existing system
– Derive requirements from existing system
model
• Current approach
– Identify logical requirements for new system
– Balance the review of current business
functions with new system requirements
[Link]
Information Gathering and Model
Building

[Link]
 Fact Finding Methods
• Review existing reports, forms, and procedure
descriptions
• Interview and discussion processes with users
• Observe and document business processes
• Build prototypes
• Distribute and collect questionnaires
• Conduct joint application design (JAD) sessions
• Research vendor solutions

[Link]
 Review Existing Reports, Forms,
and Procedure Descriptions
• Source: External industry wide professional organizations
and trade publications
• Source: Existing business documents and procedure
descriptions within organization
– Identify business rules, discrepancies, and redundancies
– Be cautious of outdated material
– Obtain preliminary understanding of processes
– Use as guidelines / visual clues to guide interviews

[Link]
 Analyzing Procedures and Other
Documents
• Types of information to be discovered:
– What problems exist with the existing system
– Are there opportunities to meet new needs
– What’s the organizational direction?
– Who are the “key stakeholders
– What are the values of the organization
– Are there any special information processing
circumstances
– What’s the history of the current system design
– Are there rules for processing data

[Link]
 Analyzing Procedures and Other
Documents (cont.)
• Four types of useful documents
– Written work procedures
• Describes how a job is performed
• Includes data and information used and created in the process of
performing the job or task
– Business forms
• Explicitly indicate data flow in or out of a system
– Reports
• Enables the analyst to work backwards from the report to the data
that generated it
– Descriptions of current information system

[Link]
Written work procedure
is a business document
that formally describes
work processes,
provides useful
information regarding
system functionality and
logic.

[Link]
 Observe and Document Business
Processes
• Varies from office walkthroughs to performing
actual tasks

• Not necessary to observe all processes at

same level of detail

• May make users nervous, so use common

senseCan document workflows with UML
activity diagrams
[Link]
 On-site Observations
• Objective: To get as close as possible.
• Performed by the analyst for knowledge gain.
• Analyst should listen more than talk.
• Analyst should approach the things with genuine
interest.
• Should not enter into arguments.
Four alternative methods:
1. Natural or Contrived
2. Obtrusive or unobtrusive
3. Direct or indirect
4. Structured or unstructured
[Link]
Conduct Interviews and Discussions
with Users
• Effective way to understand business
functions and rules
• Time consuming and resource expensive
• May require multiple sessions to
– Meet all users
– Understand all processing requirements
• Can meet with individuals or groups of
users
• List of detailed questions prepared
[Link]
 What is Interviewing?
• Dialogue with user or manager to obtain
their requirements

• Two forms:
– Open-ended: conversational, questions with
no specific answers in mind
– Closed-ended: structured, questions with
limited range of possible answers

[Link]
 Guidelines for Effective
Interviewing
• Plan the interview.
– Prepare interviewee: appointment, priming questions.
– Prepare agenda, checklist, questions.
• Listen carefully and take notes (tape record if
permitted).
• Review notes within 48 hours.
• Be neutral.
• Seek diverse views.

[Link]
 Interview
• Step 1: Determine the People to Interview
– Informal structures
• Step 2: Establish Objectives for the
Interview
– Determine the general areas to be discussed
– List the facts you want to gather

[Link]
 Interviews
• Step 3: Develop Interview Questions
– Creating a standard list of interview questions
helps to keep you on track and avoid
unnecessary tangents
– Avoid leading questions
– Open-ended questions
– Closed-ended questions
– Range-of-response questions

[Link]
 Interviews
• Step 4: Prepare for the Interview
– Careful preparation is essential because
interview is an important meeting and not just
a casual chat
– Limit the interview to no more than one hour
– Send a list of topics
– Ask the interviewee to have samples available

[Link]
 Interviews
• Step 5: Conduct the Interview
– Develop a specific plan for the meeting
– Begin by introducing yourself, describing the
project, and explaining interview objectives
– Use engaged listening
– Allow the person enough time to think about
the question
– After interview, summarize the session and
seek a confirmation

[Link]
 Interviews
• Step 6: Document the Interview
– Note taking should be kept to a minimum
– After the interview, record the information
quickly
– After the interview, send memo expressing
appreciation, including the main points
discussed so the interviewee has a written
summary and can offer additions or
corrections

[Link]
 Interviews
• Step 7: Evaluate the Interview
– In addition to recording the facts obtained in
an interview, try to identify any possible
biases
• Unsuccessful Interviews
– No matter how well you prepare for
interviews, some are not successful

[Link]
Issue with Individual Interviews
• Advantages
– Easier to schedule than group
interviews
• Disadvantages
– Contradictions and inconsistencies
between interviewees
– Follow-up discussions are time
consuming
– Only one at a time

[Link]
 Group Interviews
• Interview several key people together
• Advantages
– More effective use of time
– Can hear agreements and disagreements at once
– Opportunity for synergies
• Disadvantages
– More difficult to schedule than individual interviews

[Link]
Sample Checklist to Prepare for User
Interviews

[Link]
 Questionnaire Steps
• Selecting participants
– Using samples of the population
• Designing the questionnaire
– Careful question selection
• Administering the questionnaire
– Working to get good response rate
• Questionnaire follow-up
– Send results to participants

[Link]
 Distribute and Collect
Questionnaires
• Limited and specific information from a large
number of stakeholders.

• Preliminary insight into business

• Not well suited for gathering detailed information

• Closed-ended questions direct person answering

question

• Open-ended questions encourage discussion

and elaboration
[Link]
 Good Questionnaire Design
Begin with non-threatening and interesting questions

Group items into logically coherent sections

Do not put important items at the very end of the questionnaire

Do not crowd a page with too many items

Avoid abbreviations

Avoid biased or suggestive items or terms

Number questions to avoid confusion

Pretest the questionnaire to identify confusing questions

Provide anonymity to respondents

[Link]
 Types
• Open ended Questions:
– No response direction or specific response.
– Only questions with space provided for the
answers.
• Closed Questions:
– Fill-in-blanks
– Dichotomous(Yes/No) type
– Ranking scales
– Multiple choice questions
– Multiple choice with rating

[Link]
 Advantages
• It is economical and requires less skill.
• It can be administered to large numbers
simultaneously.
• Standardized wording and order of the questions and
standardized instruction for reporting responses.
• The respondents feel greater confidence in the
anonymity of a questionnaire.
• Less pressure on subjects for immediate responses.
• Respondents have time to think the questions .

[Link]
 Build Prototypes
• Preliminary working model of a larger,
more complex system component
– Discovery, design, evolving prototypes
• Prototype should be
– Operative
• Working model to provide “look and feel”
– Focused to accomplish single objective
– Quick
• Built and modified rapidly with CASE tools

[Link]
 Prototyping
• Quickly converts requirements to working version of system
• Once the user sees requirements converted to system, he will ask
for modifications or will generate additional requests
• Most useful when:
– User requests are not clear
– Few users are involved in the system
– Designs are complex and require concrete form
– History of communication problems between analysts and users
– Tools are readily available to build prototype

[Link]
 Basic steps for prototyping
• Identify the user’s information and operating
requirements.

• Develop a working prototype that focuses on only the

most important functions, using a basic data base.

• Allow the user to use the prototype, discuss requested

changes, and implement the most important changes.

• Repeat the next version of the prototype with further

changes incorporated until the system fully meets user
requirements.
[Link]
 Prototyping (cont.)
• Drawbacks
– Tendency to avoid formal
documentation
– Difficult to adapt to more general user
audience
– Sharing data with other systems is
often not considered
– Systems Development Life Cycle
(SDLC) checks are often bypassed

[Link]
 Joint Application Design (JAD)
• Intensive group-oriented requirements
determination technique
• Team members meet in isolation for an
extended period of time
• Highly focused
• Resource intensive
• Started by IBM in 1970s

[Link]
[Link]
 JAD Participants
• Session Leader: facilitates group process
• Users: active, speaking participants
• Managers: active, speaking participants
• Sponsor: high-level champion, limited
participation
• Systems Analysts: should mostly listen
• Scribe: record session activities
• IS Staff: should mostly listen

[Link]
 Joint Application Design Facilities
• Conducted in special room
– Limit interruptions
– May be off-site
• Resources
– Overhead projector, white board, flip charts,
work material
– Electronic support (laptops)
– CASE tools
– Group support systems (GSS)

[Link]
 The JAD Session
• Tend to last 5 to 10 days over a three week period
• Prepare questions as with interviews
• Formal agenda and groundrules
• Facilitator activities
– Keep session on track
– Help with technical terms and jargon
– Record group input
– Help resolve issues
• Post-session follow-up

[Link]
 Managing Problems in JAD
Sessions
• Reducing domination
• Encouraging non-contributors
• Side discussions
• Agenda merry-go-round
• Violent agreement
• Unresolved conflict
• True conflict
• Use humor

[Link]
Joint Application Development
• JAD Advantages and Disadvantages
– Advantages
• Allows key users to participate effectively
• When properly used, JAD can result in a more accurate
statement of system requirements, a better understanding of
common goals, and a stronger commitment to the success of the
new system

– Disadvantages
• More expensive and can be cumbersome if the group is too
large relative to the size of the project

[Link]
 Validating the Requirements
• Two basic approaches to validating
requirements
– Predictive development
• Requirements assumed stable and feasible
• Requirements specified and validated beforehand
– Adaptive development
• Requirements are assumed difficult to document
• Requirements subject to change
• System prototypes used in validation process

[Link]
 Validating the Requirements
(continued)
• Structured walkthrough
– Reviews findings
– Reviews models based on findings
– Objective: find errors and problems
– Purpose: ensure that model is correct
• Conducting structured walkthrough
– Preparation
– Execution
– Follow-up

[Link]
 Scheduling walkthroughs
• Walkthroughs should be conducted frequently
– Focuses on a specific and small piece of work
– Increases the likelihood of uncovering errors
– Before author has too great an ego investment
• Scheduled only when the author is ready
• About 4 or 5 people
• Advanced preparation (no more than 2 hours)
should be required of and performed by each
reviewer.

[Link]
 Conducting Walkthroughs
• Coordinator chairs the meeting
• Walkthrough structure
– Author's overview?
• Reviewers should be able to understand the product
without assistance
• Author's overview may "brainwash" reviewers into making
the same logical errors as did the author
– Author's detailed walkthrough
• Based on logical arguments of what the design or code
will do at various stages
– Requested specific test cases
• Coordinator resolves disagreements when the
team can not reach a consensus
[Link]
 Walkthroughs: Guidelines
• Set an agenda and keep to it
• Limit debate and rebuttal
• Identify problem areas, but don't attempt to solve
every problem
• Limit the number of participants
• Insist upon advance preparation
• Train reviewers
• Develop a checklist for each reviewable product

[Link]
 Types of Walkthroughs
• Specification walkthroughs
– System specification
– Project planning
– Requirements analysis
• Design walkthroughs
– Preliminary design
– Design
• Code walkthroughs
• Test walkthroughs
– Test plan
– Test procedure
• Maintenance reviews

[Link]
 Specification Walkthroughs
• Objective - Check the system specification for:
– Problems
– Inaccuracies
– Ambiguities
– Omissions
• Participants
– User
– Senior analyst
– Project analysts
• Objects
– DFDs, Data Dictionary, ERDs, ...
[Link]
 Design Walkthroughs
• Objective - Check the architecture of the
design for:
– Flaws
– Weaknesses
– Errors
– Omissions
• Participants
– User
– Analyst
– Senior designer
– Project designers
• Objects
– Structure charts, detailed design documents, ...

[Link]
 Feasibility Analysis
Feasibility – the measure of how beneficial or practical
an information system will be to an organization.

Feasibility analysis – the process by which feasibility is

measured.

Creeping Commitment – an approach to feasibility that

proposes that feasibility should be measured throughout
the life cycle.

[Link]
 Six Tests For Feasibility
Operational feasibility – a measure of how well a solution meets the system
requirements.
Cultural (or political) feasibility - a measure of how well a solution will be
accepted in an organizational climate.
Technical feasibility – a measure of the practicality of a technical solution and
the availability of technical resources and expertise.
Schedule feasibility – a measure of how reasonable the project timetable is.
Economic feasibility - a measure of the cost-effectiveness of a project or
solution.
Legal feasibility - a measure of how well a solution can be implemented within
existing legal/contractual obligations.
[Link]
 Operational Feasibility:
The PIECES Framework
Performance -- Does current mode of operation provide
adequate throughput and response time?
Information -- Does current mode provide end users and
managers with timely, pertinent, accurate and usefully
formatted information?
Economy -- Does current mode of operation provide cost-
effective information services to the business? Could there be a
reduction in costs and/or an increase in benefits?
Control -- Does current mode of operation offer effective
controls to protect against fraud and to guarantee accuracy and
security of data and information?
Efficiency -- Does current mode of operation make maximum
use of available resources, including people, time, flow of
forms,...?
Services -- Does current mode of operation provide reliable
service? Is it flexible and expandable?
[Link]
 Con..
• How do end-users and managers feel about the problem
(solution)?
• It's not only important to evaluate whether a system can work
but
• also evaluate whether a system will work.
• A workable solution might fail because of end-user or
management resistance.
• Does management support the project?
• How do the end-users feel about their role in the new system?
• What end-users or managers may resist or not use the system?
• People tend to resist change. Can this problem be overcome? If
so, how?
• How will the working environment of the end-users change?
• Can or will end-users and management adapt to the change?

[Link]
 Cultural (or political) feasibility
• Does management support the system?
• How do end users feel about their role in the
system?
• What end users may resist or not use the
system? How can this be overcome?
• How will the working environment change?
Can users and management adapt to the
change?

[Link]
 Technical feasibility
• Is the proposed technology or solution practical?

• Do we currently possess the necessary technology?

• Do we possess the necessary technical expertise?

• Technical feasibility assesses whether the current

technical resources are sufficient for the new system.

• If they are not available, can they be upgraded to

provide the level of technology necessary for the new
system.
[Link]
 Project Risk Factors
• Project size
– Team size, organizational departments, project duration, programming effort

• Project structure
– New vs. renovated system, resulting organizational changes, management
commitment, user perceptions

• Development group
– Familiarity with platform, software, development method, application area,
development of similar systems

• User group
– Familiarity with IS development process, application area, use of similar
systems
[Link]
High technical familiarity mitigates risk due to project size and structure. Low familiarity
increases risk.
[Link]
Cultural (or political) feasibility
• Does management support the system?

• How do end users feel about their role in the system?

• What end users may resist or not use the system?

How can this be overcome?

• How will the working environment change? Can

users and management adapt to the change?

[Link]
 Legal feasibility
• Copyrights

• Union contracts

• Legal requirements for financial reporting

• Antitrust laws

• National data and work laws

[Link]
 Economic feasibility
• During Scope Definition
– Do the problems or opportunities warrant the cost of a detailed
study and analysis of the current system?

• During Problem Analysis

– After a detailed study of the current system
– Better estimates of development costs and benefits

• During Decision Analysis

– Requirements now defined
– Development costs can be better estimated

[Link]
 Economic Feasibility
• Cost-benefit analysis: identify all the
financial benefits and costs associated
with a project

• Tangible vs. intangible benefits

• Tangible vs. intangible costs
• One-time vs. recurring costs

[Link]
Tangible Benefits

Benefits that can be

measured in dollars and
with certainty

[Link]
Benefits that cannot easily be measured in dollars or with certainty
[Link]
 Types of Costs
• Tangible Costs: can be measured in dollars and with
certainty
• Intangible Costs: cannot easily be measured in dollars
or with certainty
• One-time Costs: often associated with project start-up
and development or systems start-up
• Recurring: a cost associated with ongoing evolution
and use of a system

[Link]
 Possible Project Costs
• Procurement
– Consulting, equipment, site preparation, capital, management
time

• Start-up
– Operating systems, communications installation, personnel
hiring, organizational disruption

• Project-related
– Application software, software modification, personnel overhead,
training, data analysis, documentation

• Operating
– System maintenance, rental, asset depreciation, operation and
planning
[Link]
One-time Costs

[Link]
Recurring Costs

[Link]
Three Popular Techniques to Assess
Economic Feasibility

• Payback Analysis
• Return On Investment
• Net Present Value

[Link]
 Payback Analysis
Payback analysis – a technique for determining
if and when an investment will pay for itself.

Payback period – the period of time that will

lapse before accrued benefits overtake accrued
and continuing costs.

[Link]
 Present Value Formula
Present value – the current value of a dollar at
any time in the future.

PVn = 1/(1 + i)n

Where n is the number of years and i is discount rate

Discount rate – a percentage similar to interest rates

that you earn on your savings.
– In most cases the discount rate for a business is the
opportunity cost of being able to invest money in other
projects or investments
[Link]
 Return-on-Investment Analysis (ROI)
Return-on-Investment (ROA) analysis – a technique that compares
the lifetime profitability of alternative solutions.

The ROI for a solution or project is a percentage rate that measures the relationship
between the amount the business gets back from an investment and the amount invested.

Lifetime ROI =
(estimated lifetime benefits – estimated lifetime costs) / estimated lifetime costs

Annual ROI = lifetime ROI / lifetime of the system

[Link]
 Software Reliability

Definition: The probability of failure-free

operation of the software for a specified
period of time in a specified environment.

[Link]
 Software Reliability
1. Trustworthiness or dependability.

2. Probability of the product working correctly over a

given period of time.

3. Not only depends on the number of errors but also on

the exact location of the error.

4. It is also depends on the execution profile.

5. Observer dependant

6. Cannot be determined absolutely.

[Link]
 What is Reliability?
• Reliability is a broad concept.
– It is applied whenever we expect something to behave in a certain way.
• Reliability is one of the metrics that are used to measure quality.
• It is a user-oriented quality factor relating to system operation.
– Intuitively, if the users of a system rarely experience failure, the system is
considered to be more reliable than one that fails more often.
• A system without faults is considered to be highly reliable.
– Constructing a correct system is a difficult task.
– Even an incorrect system may be considered to be reliable if the frequency of
failure is “acceptable.”
• Key concepts in discussing reliability:
– Fault, Failure, Time

[Link]
 What is Reliability?
• Failure
– A failure is said to occur if the observable outcome of a program execution is
different from the expected outcome.
• Fault
– The cause of failure is called a fault.
– Example: A failure may be cause by a defective block of code.
• Time
– Time is a key concept in the formulation of reliability. If the time gap between two
successive failures is short, we say that the system is less reliable.
– Two forms of time are considered.
• Execution time ()
• Calendar time (t)

[Link]
 Factors Influencing Software
Reliability
• A user’s perception of the reliability of a software depends upon two categories of
information.
– The number of faults present in the software.
– The ways users operate the system.
• This is known as the operational profile.

• The fault count in a system is influenced by the following.

– Size and complexity of code
– Characteristics of the development process used
– Education, experience, and training of development personnel
– Operational environment

[Link]
 Applications of Software
Reliability
• Comparison of software engineering technologies
– What is the cost of adopting a technology?
– What is the return from the technology -- in terms of cost and quality?
• Measuring the progress of system testing
– Key question: How of testing has been done?
– The failure intensity measure tells us about the present quality of the system: high
intensity means more tests are to be performed.
• Controlling the system in operation
– The amount of change to a software for maintenance affects its reliability. Thus the
amount of change to be effected in one go is determined by how much reliability
we are ready to potentially lose.
• Better insight into software development processes
– Quantification of quality gives us a better insight into the development processes.

[Link]
 Reliability metrics
• Probability of failure on demand (POFOD):
– This is a measure of the likelihood that the system will
fail when a service request is made

– POFOD = 0.001 means 1 out of 1000 service requests

result in failure

– Relevant for safety-critical or non-stop systems

[Link]
 Con..
• Rate of fault occurrence (ROCOF)
– Frequency of occurrence of unexpected behaviour

– ROCOF of 0.02 means 2 failures are likely in each

100 operational time units

– Relevant for operating systems, transaction processing

systems

[Link]
 Con..
• Mean time to failure
– Measure of the time between observed failures

– MTTF of 500 means that the time between

failures is 500 time units

– Relevant for systems with long transactions e.g.

CAD systems

[Link]
 Con..
• Availability
– Measure of how likely the system is available for use.
Takes repair/restart time into account
– Availability of 0.998 means software is available for 998
out of 1000 time units
– Relevant for continuously running systems e.g.
telephone switching systems

[Link]
 Con..
Mean Time Between Failures(MTBF):
• Can combine MTTF and MTTR.
• If MTBF indicates 300hours indicates that every
failure occurs after 300hrs.
Mean Time to Repair(MTTR):
• Once failure occurs, some time is required to fix the
error.
• MTTR measures the average time to track the errors
causing the failure and fix it.

[Link]
 Failure Classification
• Transient - only occurs with certain inputs
• Permanent - occurs on all inputs
• Recoverable - system can recover without operator help
• Unrecoverable - operator has to help
• Non-corrupting - failure does not corrupt system state or
data
• Corrupting - system state or data are altered

[Link]
 Reliability growth modelling
• Growth model is a mathematical model of the
system reliability change as it is tested and faults are
removed
• Used as a means of reliability prediction by
extrapolating from current data
• Depends on the use of statistical testing to measure
the reliability of a system version

[Link]
 Equal-step reliability growth

Reliability
(RO COF)

t1 t2 t3 t4 t5
Time

[Link]
 Observed reliability growth
• Simple equal-step model but does not reflect reality
• Reliability does not necessarily increase with change as the
change can introduce new faults
• The rate of reliability growth tends to slow down with time as
frequently occurring faults are discovered and removed from the
software
• A random-growth model may be more accurate

[Link]
 Random-step reliability growth
Note different
reliability
Reliability improvements Fault repair adds new fault
(RO COF) and decreases reliability
(increases ROCOF)

t1 t2 t3 t4 t5
Time

[Link]
 Growth models choice
• Many different reliability growth models have been
proposed

• No universally applicable growth model

• Reliability should be measured and observed data should be

fitted to several models

• Best-fit model should be used for reliability prediction

[Link]
Software Maintenance

[Link]
 What is Reverse Engineering ?
• You have an unexpected case:
– You finished one course project using Java
– Your program runs OK
– But, by accident, you delete the java file
– How to hand in your project?

• Reverse Engineering

[Link]
 Reverse Engineering

• Analyzing software with a view to understanding its

design and specification
• May be part of the reengineering process
• May be used to specify a system for prior to
reimplementation
• Program understanding tools may be useful (browsers,
cross-reference generators, etc.)

[Link]
What is Reverse Engineering ?

Forward Engineering Reverse Engineering

Requirements

Design

Source Code

Behavior
[Link]
 What is Reverse Engineering ?

Abstraction System

Reverse Engineering Forward Engineering

Abstraction Re-Implementation

Old system New System

[Link]
 What is Reverse Engineering?

• RE encompasses any activity that is done to

determine how a product works, to learn the
ideas and technology that were used in
developing that product.
• RE can be done at many levels
• RE generally belongs to Software Maintenance

[Link]
 Why do we need RE ?

• Recovery of lost information

– providing proper system documentation
• Assisting with maintenance
– identification of side effects and anomalies
• Migration to another hw/sw platform
• Facilitating software reuse

[Link]
 Why do we need RE ?

• Benefits
– maintenance cost savings
– quality improvements
– competitive advantages
– software reuse facilitation

[Link]
 Reverse Engineering Concepts
part 1
• Abstraction level
– ideally want to be able to derive design information at the
highest level possible
• Completeness
– level of detail provided at a given abstraction level
• Interactivity
– degree to which humans are integrated with automated
reverse engineering tools

[Link]
 Reverse Engineering Concepts
part 2
• Directionality
– one-way means the software engineer doing the
maintenance activity is given all information extracted from
source code
– two-way means the information is fed to a reengineering
tool that attempts to regenerate the old program
• Extract abstractions
– meaningful specification of processing performed is derived
from old source code

[Link]
 Reverse Engineering Process

Programstucture
Automated diagrams
analysis
System
Systemtobe Document Datastucture
information
re-engineered generation diagrams
store
Manual
annotation Traceability
matrices

[Link]
 Reverse Engineering Activities
part 1
• Understanding process
– source code is analyzed to at varying levels of detail
• system

• program

• component

• pattern

• statement

– to understand procedural abstractions and overall functionality

[Link]
 Reverse Engineering Activities
part 2
• Understanding data
– internal data structures
– database structure
• User interfaces
– what are the basic actions (e.g. key strokes or mouse
operations) processed by the interface?
– what is a compact description of the system's behavioral
response to these actions?
– what concept of equivalence of interfaces is relevant?

[Link]
 Difficulties of Reverse
Engineering
• Gap between problem
/solution domain
• Gap between concrete
and abstract
• Gap between coherency/disintegration
• Gap between hierarchical/associational

[Link]
 Scope and Task of Reverse
Engineering
• program understanding
Problem/Application
domain

Mapping

Program/Implemen.
domain

[Link]
 Scope and Task of Reverse
Engineering
• Redocumentation and/or document
generation
• Recovery of design approach and design
details at any level of abstraction
• Identifying reusable components and
components that need restructuring
• Recovering business rules
• Understanding high-level system description.

[Link]
 Maintenance Costs
• Usually greater than development costs (2* to
100* depending on the application)
• Affected by both technical and non-technical
factors.
• Increases as software is maintained.
Maintenance corrupts the software structure
so
makes further maintenance more difficult.
• Ageing software can have high support costs
(e.g. old languages, compilers etc.)
[Link]
 Maintenance Costs (cont’d)
• Time and money (software that costs £ 10 a line to develop
costs £ 400 a line to maintain)
• Organizations become maintenance bound and cannot produce
new software
• Customer dissatisfaction when seemingly legitimate requests
for repair or modification cannot be addressed in a timely
manner
• Reduction in overall software quality as changes introduce
latent errors in the maintained software
• Upheaval caused during development efforts when staff must
be “pulled” to work on a maintenance task

[Link]
 Maintenance Cost Factors
• Team stability
– Maintenance costs are reduced if the same staff are involved with
them for some time
• Contractual responsibility
– The developers of a system may have no contractual responsibility
for maintenance so there is no incentive to design for future change
• Staff skills
– Maintenance staff are often inexperienced and have limited domain
knowledge
• Program age and structure
– As programs age, their structure is degraded and they become
harder to understand and change

[Link]
 Estimation of Maintenance Cost
• Maintenance efforts – 60% of the total life
cycle cost.
• It varies widely from one application domain
to another.
• 2 to 4 times of the development cost.
• Boehm – MC estimation as a part of
COCOMO.
• He defines it as a Annual Change Traffic
(ACT).
[Link]
 Con..
• ACT= KLOC(added) +KLOC(deleted) /KLOC(total).

• KLOC(added) : Total kilo lined of source code added during

maintenance.

• KLOC(deleted): Total KLOC deleted during maintenance.

• MC= ACT*Development cost.

• The results are approximate

[Link]
THANK YOU

[Link]