Software Maintenance

Unit-5
Compiled By
Dr. Vandana Agarwal
 Software Maintenance

• Software maintenance is a part of the Software

Development Life Cycle. Its primary goal is to modify
and update software application after delivery to
correct errors and to improve performance.
• Software is a model of the real world. When the real
world changes, the software require alteration
wherever possible.
• Software Maintenance is an inclusive activity that
includes error corrections, enhancement of
capabilities, deletion of obsolete capabilities, and
optimization.
 Need for Maintenance

• Correct errors
• Change in user requirement with time
• Changing hardware/software requirements
• To improve system efficiency
• To optimize the code to run faster
• To modify the components
• To reduce any unwanted side effects.
Thus the maintenance is required to ensure that the
system continues to satisfy user requirements.
 Advantages of Software Maintenance

• Improved Software Quality: Regular software maintenance helps to ensure that the software
is functioning correctly and efficiently and that it continues to meet the needs of the users.
• Enhanced Security: Maintenance can include security updates and patches, helping to ensure
that the software is protected against potential threats and attacks.
• Increased User Satisfaction: Regular software maintenance helps to keep the software up-to-
date and relevant, leading to increased user satisfaction and adoption.
• Extended Software Life: Proper software maintenance can extend the life of the software,
allowing it to be used for longer periods of time and reducing the need for costly
replacements.
• Cost Savings: Regular software maintenance can help to prevent larger, more expensive
problems from occurring, reducing the overall cost of software ownership.
• Better Alignment with business goals: Regular software maintenance can help to ensure that
the software remains aligned with the changing needs of the business. This can help to
improve overall business efficiency and productivity.
• Competitive Advantage: Regular software maintenance can help to keep the
software ahead of the competition by improving functionality, performance, and
user experience.
• Compliance with Regulations: Software maintenance can help to ensure that the
software complies with relevant regulations and standards. This is particularly
important in industries such as healthcare, finance, and government, where
compliance is critical.
• Improved Collaboration: Regular software maintenance can help to improve
collaboration between different teams, such as developers, testers, and users. This
can lead to better communication and more effective problem-solving.
• Reduced Downtime: Software maintenance can help to reduce downtime caused
by system failures or errors. This can have a positive impact on business operations
and reduce the risk of lost revenue or customers.
• Improved Scalability: Regular software maintenance can help to ensure that the
software is scalable and can handle increased user demand. This can be
particularly important for growing businesses or for software that is used by a
large number of users.
 Disadvantages of Software
Maintenance
Cost: Software maintenance can be time-consuming and expensive, and may
require significant resources and expertise.
Schedule disruptions: Maintenance can cause disruptions to the normal
schedule and operations of the software, leading to potential downtime
and inconvenience.
Complexity: Maintaining and updating complex software systems can be
challenging, requiring specialized knowledge and expertise.
Risk of introducing new bugs: The process of fixing bugs or adding new
features can introduce new bugs or problems, making it important to
thoroughly test the software after maintenance.
User resistance: Users may resist changes or updates to the software, leading
to decreased satisfaction and adoption.
Compatibility issues: Maintenance can sometimes cause compatibility issues
with other software or hardware, leading to potential integration
problems.
Lack of documentation: Poor documentation or lack of documentation can
make software maintenance more difficult and time-consuming, leading
to potential errors or delays.
Technical debt: Over time, software maintenance can lead to technical debt,
where the cost of maintaining and updating the software becomes
increasingly higher than the cost of developing a new system.
Skill gaps: Maintaining software systems may require specialized skills or
expertise that may not be available within the organization, leading to
potential outsourcing or increased costs.
Inadequate testing: Inadequate testing or incomplete testing after
maintenance can lead to errors, bugs, and potential security
vulnerabilities.
End-of-life: Eventually, software systems may reach their end-of-life, making
maintenance and updates no longer feasible or cost-effective. This can
lead to the need for a complete system replacement, which can be costly
and time-consuming.
 Types of Software Maintenance
1.Corrective Maintenance
– Corrective maintenance aims to correct any remaining errors
regardless of where they may cause specifications, design, coding,
testing, and documentation, etc.
2. Adaptive Maintenance
– It contains modifying the software to match changes in the ever-
changing environment.
3. Preventive Maintenance
It is the process by which we prevent our system from being obsolete. It
involves the concept of reengineering & reverse engineering in which
an old system with old technology is re-engineered using new
technology. This maintenance prevents the system from dying out.
4. Perfective Maintenance
– It defines improving processing efficiency or performance or
restricting the software to enhance changeability. This may contain
enhancement of existing system functionality, improvement in
computational efficiency, etc.
 Software Maintenance Process
Generating a Particular maintenance problem
– The second phase consists of creating a particular maintenance
proposal to accomplish the implementation of the maintenance
goals.
Ripple Effect
– The third step consists of accounting for all of the ripple effects
as a consequence of program modifications.
Modified Program Testing
– The fourth step consists of testing the modified program to
ensure that the revised application has at least the same
reliability level as prior.
Maintainability
– Each of these four steps and their associated software quality
attributes is critical to the maintenance process. All of these
methods must be combined to form maintainability.
 Software Maintenance Cost Factors

• There are two types of cost factors involved in

software maintenance.
These are
– Non-Technical Factors
– Technical Factors
 Non-Technical Factors
1.Application Domain
– If the application of the program is defined and well understood, the system
requirements may be definitive and maintenance due to changing needs
minimized.
– If the form is entirely new, it is likely that the initial conditions will be modified
frequently, as user gain experience with the system.
2. Staff Stability
– It is simple for the original writer of a program to understand and change an
application rather than some other person who must understand the program
by the study of the reports and code listing.
– If the implementation of a system also maintains that systems, maintenance
costs will reduce.
– In practice, the feature of the programming profession is such that persons
change jobs regularly. It is unusual for one user to develop and maintain an
application throughout its useful life.
3. Program Lifetime
– Programs become obsolete when the program becomes obsolete, or their
original hardware is replaced, and conversion costs exceed rewriting costs.
4.Dependence on External Environment
– If an application is dependent on its external environment, it must be
modified as the climate changes.
For example:
– Changes in a taxation system might need payroll, accounting, and
stock control programs to be modified.
– Taxation changes are nearly frequent, and maintenance costs for these
programs are associated with the frequency of these changes.
– A program used in mathematical applications does not typically
depend on humans changing the assumptions on which the program is
based.
5. Hardware Stability
– If an application is designed to operate on a specific hardware
configuration and that configuration does not changes during the
program's lifetime, no maintenance costs due to hardware changes
will be incurred.
– Hardware developments are so increased that this situation is rare.
– The application must be changed to use new hardware that replaces
obsolete equipment.
 Technical Factors
Module Independence
– It should be possible to change one program unit of a system without affecting any other unit.
Programming Language
– Programs written in a high-level programming language are generally easier to understand than
programs written in a low-level language.
Programming Style
– The method in which a program is written contributes to its understandability and hence, the ease
with which it can be modified.
Program Validation and Testing
– Generally, more the time and effort are spent on design validation and program testing, the fewer
bugs in the program and, consequently, maintenance costs resulting from bugs correction are lower.
– Maintenance costs due to bug's correction are governed by the type of fault to be repaired.
– Coding errors are generally relatively cheap to correct, design errors are more expensive as they may
include the rewriting of one or more program units.
– Bugs in the software requirements are usually the most expensive to correct because of the drastic
design which is generally involved.
Documentation
– If a program is supported by clear, complete yet concise documentation, the functions of
understanding the application can be associatively straight-forward.
– Program maintenance costs tends to be less for well-reported systems than for the system supplied
with inadequate or incomplete documentation.
Configuration Management Techniques
– One of the essential costs of maintenance is keeping track of all system documents and ensuring that
these are kept consistent.
– Effective configuration management can help control these costs.
•
 Challenges in Software Maintenance
Lack of documentation:
– Poorly documented systems can make it difficult to understand how the system works, making it difficult to
identify and fix problems.
Legacy code:
– Maintaining older systems with outdated technologies can be difficult, as it may require specialized
knowledge and skills.
Complexity:
– Large and complex systems can be difficult to understand and modify, making it difficult to identify and fix
problems.
Changing requirements:
– As user requirements change over time, the software system may need to be modified to meet these new
requirements, which can be difficult and time-consuming.
Interoperability issues:
– Systems that need to work with other systems or software can be difficult to maintain, as changes to one
system can affect the other systems.
Lack of test coverage:
– Systems that have not been thoroughly tested can be difficult to maintain as it can be hard to identify and
fix problems without knowing how the system behaves in different scenarios.
Lack of personnel:
– A lack of personnel with the necessary skills and knowledge to maintain the system can make it difficult to
keep the system up-to-date and running smoothly.
High-Cost:
– The cost of maintenance can be high, especially for large and complex systems, which can be difficult to
budget for and manage.
 Software Re-engineering

• When we need to update the software to keep it to the current

market, without impacting its functionality, it is called software re-
engineering. It is a thorough process where the design of software
is changed and programs are re-written.
• Legacy software cannot keep tuning with the latest technology
available in the market. As the hardware become obsolete,
updating of software becomes a headache. Even if software grows
old with time, its functionality does not.
• For example, initially Unix was developed in assembly language.
When language C came into existence, Unix was re-engineered in C,
because working in assembly language was difficult.
• Other than this, sometimes programmers notice that few parts of
software need more maintenance than others and they also need
re-engineering.
 Re-Engineering Process

• Decide what to re-engineer. Is it whole

software or a part of it?
• Perform Reverse Engineering, in order
to obtain specifications of existing
software.
• Restructure Program if required. For
example, changing function-oriented
programs into object-oriented
programs.
• Re-structure data as required.
• Apply Forward engineering concepts
in order to get re-engineered
software.
 Program Restructuring

• It is a process to re-structure and re-construct the existing

software. It is all about re-arranging the source code, either
in same programming language or from one programming
language to a different one. Restructuring can have either
source code-restructuring and data-restructuring or both.
• Re-structuring does not impact the functionality of the
software but enhance reliability and maintainability.
Program components, which cause errors very frequently
can be changed, or updated with re-structuring.
• The dependability of software on obsolete hardware
platform can be removed via re-structuring.
 Forward Engineering
• Forward engineering is a process of obtaining
desired software from the specifications in hand
which were brought down by means of reverse
engineering. It assumes that there was some
software engineering already done in the past.
• Forward engineering is same as software
engineering process with only one difference – it
is carried out always after reverse engineering.
•
 Reverse Engineering
• It is the process of extracting knowledge or design information from anything man-
made and reproducing it based on the extracted information. It is also called back
engineering. The main objective of reverse engineering is to check out how the
system works. Reverse engineering is used to know how the thing works. Also,
reverse engineering is to recreate the object by adding some enhancements.
• Why Reverse Engineering?
– Providing proper system documentation.
– Recovery of lost information.
– Assisting with maintenance.
– The facility of software reuse.
– Discovering unexpected flaws or faults.
– Implements innovative processes for specific use.
– Easy to document the things how efficiency and power can be improved.
• Uses of Software Reverse Engineering
– Software Reverse Engineering is used in software design
– Reverse engineering enables the developer or programmer to add new features to the existing
software with or without knowing the source code.
• Reverse engineering is also useful in software testing, it helps the testers to study or detect the
virus and other malware code.
• Software reverse engineering is the process of analyzing and understanding the internal structure
and design of a software system. It is often used to improve the understanding of a software
system, to recover lost or inaccessible source code, and to analyze the behavior of a system for
security or compliance purposes.
• Legacy systems: Reverse engineering can be used to understand and maintain legacy systems that
are no longer supported by the original developer.
• Intellectual property protection: Reverse engineering can be used to detect and prevent
intellectual property theft by identifying and preventing the unauthorized use of code or other
assets.
• Security: Reverse engineering is used to identify security vulnerabilities in a system, such as
backdoors, weak encryption, and other weaknesses.
• Reverse-engineering of software to create a competing product: To create a product that functions
similarly or to identify the features that are missing in a product and create a new product that
incorporates those features.
• It’s important to note that reverse engineering can be a complex and time-consuming process, and
it is important to have the necessary skills, tools, and knowledge to perform it effectively.
Additionally, it is important to consider the legal and ethical implications of reverse engineering, as
it may be illegal or restricted in some jurisdictions.
 Reuse Process

• Two kinds of method can be adopted: either by keeping

requirements same and adjusting components or by
keeping components same and modifying requirements.
• Requirement Specification - The functional and non-
functional requirements are specified, which a software
product must comply to, with the help of existing system,
user input or both.
• Design - This is also a standard SDLC process step, where
requirements are defined in terms of software parlance.
Basic architecture of system as a whole and its sub-systems
are created.
• Specify Components - By studying the software design, the
designers segregate the entire system into smaller
components or sub-systems. One complete software design
turns into a collection of a huge set of components working
together.
• Search Suitable Components - The software component
repository is referred by designers to search for the
matching component, on the basis of functionality and
intended software requirements..
• Incorporate Components - All matched components are
packed together to shape them as complete software.
 Software Configuration Management

• (SCM) is the task of tracking and controlling changes in

the software, part of the larger cross-discipline field of
configuration management. SCM practices include
revision control and the establishment of baselines. If
something goes wrong, SCM can determine what was
changed and who changed it. If a configuration is
working well, SCM can determine how to replicate it
across many hosts.
• SCM helps in identifying individual elements and
configurations, tracking changes, and version selection,
control, and base lining. SCM aims to control changes
introduced to large complex software systems through
reliable version selection and version control
Software configuration Management Activities
• Configuration identification – Identifying configurations, configuration items and baselines

• Configuration control – Implementing a controlled change process. This is usually achieved by

setting up a change control board whose primary function is to approve or reject all change
requests that are sent against any baseline.

• Configuration status accounting – Recording and reporting all the necessary information on the
status of the development process.

• Configuration auditing – Ensuring that configurations contain all their intended parts and are sound
with respect to their specifying documents, including requirements, architectural specifications and
user manuals.

• Build management – Managing the process and tools used for builds.

• Process management – Ensuring adherence to the organization’s development process.

• Environment management – Managing the software and hardware that host the system.

• Teamwork – Facilitate team interactions related to the process.

• Defect tracking – Making sure every defect has traceability back to the source.

• Reduced redundant work – This process also help us to reduce the redundant work.

• Avoids configuration-related problems – Software configuration management process make sure that the
configuration changes done in any environment which may include stage, UAT, Integration or products is
being tracked and controlled.

• Facilitates team coordination – Software configuration management also enables team to co-ordinate at
many scale to get done software development faster without compromising the quality of the software.
Need for co-ordination between Dev, QA and End User.

• Helps in building management – managing tools used in builds and release which include SCM Server,
Build Servers.

• More than one version of the software has to be supported – Software configuration management
enables us to support following…
— Multiple Releases
— Custom Configured systems
— Systems under Development
— Control the cost involved in making changes to a system
 Change Control
• Change control is a process used to manage change requests for projects and big initiatives. It’s part of a change
management plan, which defines the roles for managing change within a team or company. While there are many
parts to a change process, the easiest way to think about it is that it involves creating a change log where you’ll
track project change requests
• In most cases, any stakeholder will be able to request a change. A request could be as small as a slight edit to
the project schedule or as large as a new deliverable. It’s important to keep in mind that not all requests will be
approved, as it’s up to key stakeholders to approve or deny change requests.
Benefits
• Increased productivity
– A change control process will eliminate confusion around project deliverables and allow the focus to be on
executing rather than collecting information. This results in increased productivity and efficiency, especially
with the help of productivity software
• Effective communication
– Properly documenting change can help alleviate communication issues. When goals and objectives are
clearly defined, team communication can flourish.It may be helpful to also incorporate work management
software to keep communication about projects in one place. A change control process can then also be
shared with executive stakeholders in order to easily provide context for change requests.
• Better teamwork and collaboration
– With clear communication on project changes, it’s easier to collaborate and work together
 Software Version Control
• Software version control (SVC), also called revision control, source
control management, and versioning control, is a management
strategy to track and store changes to a software development
document or set of files that follow the development project from
beginning to end-of-life. Following the logical and recorded
development trail can aid in finding problem origins, bugs, or even
better versions of the build.
• In software development, many of the systems allow different
levels of collaboration and communication for a team of developers
while writing the code. At its core, SVC is a data repository (or
repositories) that tracks changes made to a file, who made the
change, and when the change occurred. This information tracks all
input to create a reliable historical record of the entire project.
• The SVC system is a complete view of changes and revisions, and
can move the project forward in a collaborative manner while also
preserving valuable work to revert to an older version if necessary.
 Benefits of Well-Managed Version
Control
• Software version control systems support an overall Agile development plan by
providing a “proof” mechanism for how the code was constructed, when it was
changed, and by whom. A well-managed system has version numbering
conventions that are easily identifiable by the entire team. The system manages
the directories, files, and individual changes made over time, which allows users to
find root causes for mistakes or bugs, or revert to an earlier version. The ability to
prevent overwriting is another important benefit of a strong VCS because it
preserves all versions for recall and analysis at any stage. Since the changed
information is kept over the life of the software solution, developers can “go back
in time” to a version that may be stronger or better suited.
• Additional business benefits include the following:
– Improve team productivity and enable collaboration.
– Enhance team communication with a reliable solution.
– Reduce development errors and conflicts.
– Improve customer satisfaction with reliable software versions.
 Risk Management
• A "risk" is a problem that could cause some loss or threaten the progress
of the project, but which has not happened yet.
• These potential issues might harm cost, schedule or technical success of
the project and the quality of our software device, or project team morale.
• Risk Management is the system of identifying addressing and eliminating
these problems before they can damage the project.
 Classifications of risks
• Project risks: Project risks concern differ forms of budgetary, schedule,
personnel, resource, and customer-related problems. A vital project risk is
schedule slippage. Since the software is intangible, it is very tough to
monitor and control a software project. It is very tough to control
something which cannot be identified. For any manufacturing program,
such as the manufacturing of cars, the plan executive can recognize the
product taking shape.
• Technical risks: Technical risks concern potential method, implementation,
interfacing, testing, and maintenance issue. It also consists of an
ambiguous specification, incomplete specification, changing specification,
technical uncertainty, and technical obsolescence. Most technical risks
appear due to the development team's insufficient knowledge about the
project.
• Business risks: This type of risks contain risks of building an excellent
product that no one need, losing budgetary or personnel commitments,
etc.
 Principle of Risk Management

• Global Perspective: In this, we review the bigger system

description, design, and implementation. We look at the
chance and the impact the risk is going to have.
• Take a forward-looking view: Consider the threat which
may appear in the future and create future plans for
directing the next events.
• Open Communication: This is to allow the free flow of
communications between the client and the team
members so that they have certainty about the risks.
• Integrated management: In this method risk management
is made an integral part of project management.
• Continuous process: In this phase, the risks are tracked
continuously throughout the risk management paradigm.
Risk Management Activities
 Risk Assessment

• The objective of risk assessment is to division the risks in the

condition of their loss, causing potential. For risk assessment, first,
every risk should be rated in two methods:
• The possibility of a risk coming true (denoted as r).
• The consequence of the issues relates to that risk (denoted as s).
• Based on these two methods, the priority of each risk can be
estimated:
• p=r*s
• Where p is the priority with which the risk must be controlled, r is
the probability of the risk becoming true, and s is the severity of
loss caused due to the risk becoming true. If all identified risks are
set up, then the most likely and damaging risks can be controlled
first, and more comprehensive risk abatement methods can be
designed for these risks.
1. Risk Identification:
– The project organizer needs to anticipate the risk in the project as early as possible so that the impact of risk can be reduced
by making effective risk management planning.
– A project can be of use by a large variety of risk. To identify the significant risk, this might affect a project. It is necessary to
categories into the different risk of classes.
There are different types of risks which can affect a software project:
Technology risks: Risks that assume from the software or hardware technologies that are used to develop the system.
People risks: Risks that are connected with the person in the development team.
Organizational risks: Risks that assume from the organizational environment where the software is being developed.
Tools risks: Risks that assume from the software tools and other support software used to create the system.
Requirement risks: Risks that assume from the changes to the customer requirement and the process of managing the requirements
change.
Estimation risks: Risks that assume from the management estimates of the resources required to build the system

2. Risk Analysis:
– During the risk analysis process, you have to consider every identified risk and make a perception of the probability and
seriousness of that risk.
– There is no simple way to do this. You have to rely on your perception and experience of previous projects and the problems
that arise in them.
– It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk. Instead, you should
authorize the risk to one of several bands:
– The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%), high (50-75%) or very
high (+75%).
– The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious (would cause significant
delays), tolerable (delays are within allowed contingency), or insignificant.

3.Risk Control
– It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a plan are determined; the
project must be made to include the most harmful and the most likely risks. Different risks need different containment methods.
In fact, most risks need ingenuity on the part of the project manager in tackling the risk.
 Three main methods to plan for risk
management:
• Avoid the risk: This may take several ways such as
discussing with the client to change the requirements
to decrease the scope of the work, giving incentives to
the engineers to avoid the risk of human resources
turnover, etc.
• Transfer the risk: This method involves getting the
risky element developed by a third party, buying
insurance cover, etc.
• Risk reduction: This means planning method to include
the loss due to risk. For instance, if there is a risk that
some key personnel might leave, new recruitment can
be planned.
 Software Case Tools Overview

• CASE stands for Computer Aided Software Engineering. It means,

development and maintenance of software projects with help of
various automated software tools.
CASE Tools
• CASE tools are set of software application programs, which are used
to automate SDLC activities. CASE tools are used by software
project managers, analysts and engineers to develop software
system.
• There are number of CASE tools available to simplify various stages
of Software Development Life Cycle such as Analysis tools, Design
tools, Project management tools, Database Management tools,
Documentation tools are to name a few.
• Use of CASE tools accelerates the development of project to
produce desired result and helps to uncover flaws before moving
ahead with next stage in software development.
 Components of CASE Tools

• CASE tools can be broadly divided into the following parts based on their use at a
particular SDLC stage:
• Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information. Central repository is a
central place of storage where product specifications, requirement documents,
related reports and diagrams, other useful information regarding management is
stored. Central repository also serves as data dictionary.
• Upper Case Tools - Upper CASE tools are used in planning, analysis and design
stages of SDLC.
• Lower Case Tools - Lower CASE tools are used in implementation, testing and
maintenance.
• Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and documentation.
• CASE tools can be grouped together if they have similar functionality, process
activities and capability of getting integrated with other tools.
• Scope of Case Tools
• The scope of CASE tools goes throughout the SDLC.
 Case Tools Types
• Diagram tools
– These tools are used to represent system components, data and control flow among various
software components and system structure in a graphical form. For example, Flow Chart
Maker tool for creating state-of-the-art flowcharts.
• Process Modeling Tools
– Process modeling is method to create software process model, which is used to develop the
software. Process modeling tools help the managers to choose a process model or modify it as
per the requirement of software product. For example, EPF Composer
• Project Management Tools
– These tools are used for project planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project execution with every mentioned
step in software project management. Project management tools help in storing and sharing
project information in real-time throughout the organization. For example, Creative Pro Office,
Trac Project, Basecamp.
• Documentation Tools
– Documentation in a software project starts prior to the software process, goes throughout all
phases of SDLC and after the completion of the project.
– Documentation tools generate documents for technical users and end users. Technical users
are mostly in-house professionals of the development team who refer to system manual,
reference manual, training manual, installation manuals etc. The end user documents describe
the functioning and how-to of the system such as user manual. For example, Doxygen,
DrExplain, Adobe RoboHelp for documentation.
• Analysis Tools
• These tools help to gather requirements, automatically check for any
inconsistency, inaccuracy in the diagrams, data redundancies or erroneous
omissions. For example, Accept 360, Accompa, CaseComplete for
requirement analysis, Visible Analyst for total analysis.
• Design Tools
• These tools help software designers to design the block structure of the
software, which may further be broken down in smaller modules using
refinement techniques. These tools provides detailing of each module and
interconnections among modules. For example, Animated Software Design
• Configuration Management Tools
• An instance of software is released under one version. Configuration
Management tools deal with –
• Version and revision management
• Baseline configuration management
• Change control management
• CASE tools help in this by automatic tracking, version management and
release management. For example, Fossil, Git, Accu REV.
• Change Control Tools
• These tools are considered as a part of configuration management tools. They deal with changes made to the
software after its baseline is fixed or when the software is first released. CASE tools automate change tracking, file
management, code management and more. It also helps in enforcing change policy of the organization.
• Programming Tools
• These tools consist of programming environments like IDE (Integrated Development Environment), in-built
modules library and simulation tools. These tools provide comprehensive aid in building software product and
include features for simulation and testing. For example, Cscope to search code in C, Eclipse.
• Prototyping Tools
• Software prototype is simulated version of the intended software product. Prototype provides initial look and feel
of the product and simulates few aspect of actual product.
• Prototyping CASE tools essentially come with graphical libraries. They can create hardware independent user
interfaces and design. These tools help us to build rapid prototypes based on existing information. In addition,
they provide simulation of software prototype. For example, Serena prototype composer, Mockup Builder.
• Web Development Tools
• These tools assist in designing web pages with all allied elements like forms, text, script, graphic and so on. Web
tools also provide live preview of what is being developed and how will it look after completion. For example,
Fontello, Adobe Edge Inspect, Foundation 3, Brackets.
• Quality Assurance Tools
• Quality assurance in a software organization is monitoring the engineering process and methods adopted to
develop the software product in order to ensure conformance of quality as per organization standards. QA tools
consist of configuration and change control tools and software testing tools. For example, SoapTest, AppsWatch,
JMeter.
• Maintenance Tools
• Software maintenance includes modifications in the software product after it is delivered. Automatic logging and
error reporting techniques, automatic error ticket generation and root cause Analysis are few CASE tools, which
help software organization in maintenance phase of SDLC. For example, Bugzilla for defect tracking, HP Quality
Center.
• Print Page
 Software Cost Estimation

• For any new software project, it is necessary to know how much it

will cost to develop and how much development time will it take.
These estimates are needed before development is initiated
• Project scope must be established in advanced.
• Software metrics are used as a support from which evaluation is
made.
• The project is broken into small PCs which are estimated
individually.
To achieve true cost & schedule estimate, several option arise.
• Delay estimation
• Used symbol decomposition techniques to generate project cost
and schedule estimates.
• Acquire one or more automated estimation tools.
 Uses of Cost Estimation

• During the planning stage, one needs to

choose how many engineers are required for
the project and to develop a schedule.
• In monitoring the project's progress, one
needs to access whether the project is
progressing according to the procedure and
takes corrective action, if necessary
 Cost Estimation Models

Static, Single Variable Models: When a model makes use of single

variables to calculate desired values such as cost, time, efforts, etc. is
said to be a single variable model
Static, Multivariable Models: These models are based on method
(1), they depend on several variables describing various aspects of
the software development environment. In some model, several
variables are needed to describe the software development process,
and selected equation combined these variables to give the estimate
of time & cost. These models are called multivariable models.
 COCOMO Model

• The term COCOMO stands for Constructive Cost Model. Barry

Boehm's book Software Engineering Economics was initially
published in 1981. Due to the model's ease of transparency, it
provides the magnitude of the project's expense. It is designed for
small projects since it has a limited number of cost drivers. When
the team size is small, i.e. when the staff is tiny, it is helpful.
• It's useful for getting a quick, early, rough estimate of software
costs, but its accuracy is limited due to the lack of factors to account
for differences in hardware constraints, personnel quality and
experience, use of modern tools and techniques, and other project
attributes that are known to have a significant impact on s/w costs.
• EFFORT = a* (KDSI)b EFFORT = a* (KDSI)
• Constants a and b have different values depending on the project
type. The KLOC is the projected number of delivered lines of code
for the project.
 In COCOMO, projects are categorized into three types:
1. Organic:
– A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar methods of
projects. Examples of this type of projects are simple business systems, simple inventory
management systems, and data processing systems.
2. Semidetached:
– A development project can be treated with semidetached type if the development consists of
a mixture of experienced and inexperienced staff. Team members may have finite experience
in related systems but may be unfamiliar with some aspects of the order being
developed. Example of Semidetached system includes developing a new operating system
(OS), a Database Management System (DBMS), and complex inventory management system.
3. Embedded:
– A development project is treated to be of an embedded type, if the software being developed
is strongly coupled to complex hardware, or if the stringent regulations on the operational
method exist. For Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict
effort (in a unit of person month)and development time from the size of
estimation in KLOC(Kilo Line of code) efforts estimation takes into account the
productivity loss due to holidays, weekly off, coffee breaks, etc.
 kinds of modes available in COCOMO
Organic Mode − A modest, basic software project involving a small group of people with prior
application knowledge. Efforts, E, and Development, D are the following
E = 2.4*(KLOC)^1.05
D=2.5*(E)^0.38
Semi-detached Mode − An intermediate software project in which teams with varying levels of
expertise collaborate.
E= 3.0*(KLOC)^1.12
D=2.5*(E)^0.35
Embedded Mode − A software project that must be built under strict hardware, software, and
operational limitations.
E= 3.6*(KLOC)^1.20
D= 2.5*(E)^0.32
 Basic COCOMO Model
The basic COCOMO model provide an accurate size of the project parameters. The following expressions
give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
Estimation of development effort
For the three classes of software products, the formulas for estimating the effort based on the code size
are shown below:
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
Estimation of development time
For the three classes of software products, the formulas for estimating the development time based on
the effort are given below:
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
 Intermediate Model
• It assesses software development effort as a function of program size and a set of cost drivers, which
include a subjective assessment of goods, hardware, employees, and project characteristics.
• It's appropriate for medium-sized tasks. Intermediate to basic and advanced COCOMO are the cost drivers.
Cost factors influence product dependability, database size, execution, and storage. The team has a
modest size. The COCOMO intermediate model looks like this −
• EFFORT = a*(KLOC)b*EAF
• Here, effort is measured in person-months, and KLOC is the project's projected amount of delivered lines
of code.
• COCOMO in depth
• It's designed for large-scale undertakings. The cost drivers are determined by requirements, analysis,
design, testing, and maintenance. The team is rather big. The comprehensive COCOMO Model
incorporates all of the characteristics of the intermediate version, as well as an evaluation of the cost
driver's impact on each phase of the software engineering process (analysis, design, and so on).
• Intermediate COCOMO equation:
E=ai (KLOC) bi*EAF
D=ci (E)di
Coefficients for intermediate COCOMO
Project ai bi ci di
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32