UNIT-5

SOFTWARE MAINTENANCE AND SOFTWARE PROJECT MANAGEMENT

Software as an Evolutionary Entity:

In software engineering, software evolution is referred to as the process of developing, maintaining, and
updating software for various reasons. Software changes are inevitable because there are many factors
that change during the life cycle of a piece of software.

It is a product and, at the same time, the vehicle for delivering a product. As a product, it delivers the
computing potential embodied by computer hardware or, more broadly, a network of computers that are
accessible by local hardware.

Some of the factors include:

Requirement changes

Environment changes

Errors or security breaches

New equipment added or removed, and finally

Improvements to the system

Need for Maintenance:

Need of maintenance occurs due to the following factors:

Correct faults.

Improve the design.

Implement enhancements.

Interface with other systems.

Accommodate programs so that different hardware, software, system features, and telecommunications
facilities can be used.

Migrate legacy software.

Retire software.

Purpose of Maintenance:

Failure Avoidance

Equipment Reliability

Least Operating Costs

Risk Reduction

Maximum Production

Defect Simulation

Software maintenance refers to the process of modifying and updating a software system after it has been
delivered to the customer. This can include fixing bugs, adding new features, improving performance, or
updating the software to work with new hardware or software systems. The goal of software maintenance
is to keep the software system working correctly, efficiently, and securely, and to ensure that it continues
to meet the needs of the users.

There are several key aspects of software maintenance, including:

Bug fixing: The process of finding and fixing errors and problems in the software.
Enhancements: The process of adding new features or improving existing features to meet the evolving
needs of the users.
Performance optimization: The process of improving the speed, efficiency, and reliability of the software.
Porting and migration: The process of adapting the software to run on new hardware or software platforms.
Re-engineering: The process of improving the design and architecture of the software to make it more
maintainable and scalable.
Documentation: The process of creating, updating, and maintaining the documentation for the software,
including user manuals, technical specifications, and design documents.
Software maintenance is a critical part of the software development life cycle and is necessary to ensure
that the software continues to meet the needs of the users over time. It is also important to consider the
cost and effort required for software maintenance when planning and developing a software system.
Software maintenance is the process of modifying a software system after it has been delivered to the
customer. The goal of maintenance is to improve the system’s functionality, performance, and reliability
and to adapt it to changing requirements and environments.

There are several types of software maintenance, including:

Corrective maintenance: This involves fixing errors and bugs in the software system.
Adaptive maintenance: This involves modifying the software system to adapt it to changes in the
environment, such as changes in hardware or software.
Perfective maintenance: This involves improving the functionality, performance, and reliability of the
software system.
Preventive maintenance: This involves taking measures to prevent future problems, such as updating
documentation, reviewing and testing the system, and implementing preventive measures such as backups.
Software maintenance is a continuous process that occurs throughout the entire life cycle of the software
system. It is important to have a well-defined maintenance process in place, which includes testing and
validation, version control, and communication with stakeholders.
It’s important to note that software maintenance can be costly and complex, especially for large and
complex systems. Therefore, the cost and effort of maintenance should be taken into account during the
planning and development phases of a software project. It’s also important to have a clear and well-defined
maintenance plan that includes regular maintenance activities, such as testing, backup, and bug fixing.
Software Maintenance is the process of modifying a software product after it has been delivered to the
customer. The main purpose of software maintenance is to modify and update software applications after
delivery to correct faults and to improve performance.
Maintenance can be categorized into proactive and reactive types. Proactive maintenance involves taking
preventive measures to avoid problems from occurring, while reactive maintenance involves addressing
problems that have already occurred.
Maintenance can be performed by different stakeholders, including the original development team, an in-
house maintenance team, or a third-party maintenance provider.
Maintenance activities can be planned or unplanned. Planned activities include regular maintenance tasks
that are scheduled in advance, such as updates and backups. Unplanned activities are reactive and are
triggered by unexpected events, such as system crashes or security breaches.
Software maintenance can involve modifying the software code, as well as its documentation, user
manuals, and training materials. This ensures that the software is up-to-date and continues to meet the
needs of its users.
Software maintenance can also involve upgrading the software to a new version or platform. This can be
necessary to keep up with changes in technology and to ensure that the software remains compatible with
other systems.
The success of software maintenance depends on effective communication with stakeholders, including
users, developers, and management. Regular updates and reports can help to keep stakeholders informed
and involved in the maintenance process.
Software maintenance is also an important part of the Software Development Life Cycle(SDLC). To update
the software application and do all modifications in software application so as to improve performance is
the main focus of software maintenance. Software is a model that run on the basis of real world. so,
whenever any change requires in the software that means the need of real world changes wherever
possible.
Need for Maintenance –
Software Maintenance must be performed in order to:
Correct faults.
Improve the design.
Implement enhancements.
Interface with other systems.
Accommodate programs so that different hardware, software, system features, and telecommunications
facilities can be used.
Migrate legacy software.
Retire software.
Requirement of user changes.
Run the code fast
Challenges in Software Maintenance:
The various challenges in software maintenance are given below:
The popular age of any software program is taken into consideration up to ten to fifteen years. As software
program renovation is open ended and might maintain for decades making it very expensive.
Older software program’s, which had been intended to paintings on sluggish machines with much less
reminiscence and garage ability can not maintain themselves tough in opposition to newly coming more
advantageous software program on contemporary-day hardware.
Changes are frequently left undocumented which can also additionally reason greater conflicts in future.
As era advances, it turns into high priced to preserve vintage software program.
Often adjustments made can without problems harm the authentic shape of the software program, making
it difficult for any next adjustments.
There is lack of Code Comments.
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.
To overcome these challenges, it is important to have a well-defined maintenance process in place, which
includes testing and validation, version control, and communication with stakeholders. It is also important
to have a clear and well-defined maintenance plan that includes regular maintenance activities, such as
testing, backup, and bug fixing. Additionally, it is important to have personnel with the necessary skills and
knowledge to maintain the system.
Categories of Software Maintenance –
Maintenance can be divided into the following:
Corrective maintenance: Corrective maintenance of a software product may be essential either to rectify
some bugs observed while the system is in use, or to enhance the performance of the system.

Adaptive maintenance: This includes modifications and updations when the customers need the product
to run on new platforms, on new operating systems, or when they need the product to interface with new
hardware and software.

Perfective maintenance: A software product needs maintenance to support the new features that the users
want or to change different types of functionalities of the system according to the customer demands.

Preventive maintenance: This type of maintenance includes modifications and updations to prevent future
problems of the software. It goals to attend problems, which are not significant at this moment but may
cause serious issues in future.

Reverse Engineering –
Reverse Engineering is processes of extracting knowledge or design information from anything man-made
and reproducing it based on extracted information. It is also called back Engineering. The main objective of
reverse-engineering is to check out how the system works. There are a many reasons to perform reverse
engineering. Reverse engineering is used to know how the thing works. Also, reverse engineering is to
recreate the object by adding some enhancements.
Software Reverse Engineering –
Software Reverse Engineering is the process of recovering the design and the requirements specification
of a product from an analysis of it’s code. Reverse Engineering is becoming important, since several
existing software products, lack proper documentation, are highly unstructured, or their structure has
degraded through a series of maintenance efforts.
Why Reverse Engineering?
Providing proper system documentation.
Recovery of lost information.
Assisting with maintenance.
Facility of software reuse.
Discovering unexpected flaws or faults.
Implements the innovative processes for specific use.
Easy to document the things how the 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.
Malware analysis: Reverse engineering is used to understand how malware works and to identify the
vulnerabilities it exploits, in order to develop countermeasures.
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.
Compliance: Reverse engineering is used to ensure that a system meets compliance standards, such as
those for accessibility, security, and privacy.
Reverse-engineering of proprietary software: To understand how a software works, to improve the
software or to create a new software with similar features.
Reverse-engineering of a 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.

Advantages Or Disadvantages:
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.
The cost of software maintenance can include:
Labor costs: This includes the cost of the personnel who perform the maintenance, such as software
developers, engineers, and technicians.
Hardware and software costs: This includes the cost of hardware and software tools used for
maintenance, such as servers, software licenses, and development tools.
Training costs: This includes the cost of training personnel to perform maintenance tasks, such as
software developers, engineers, and technicians.
The effort of software maintenance can include:
Time and resources: This includes the time and resources required to perform the maintenance, such as
the time required to identify and fix the problem, test the solution, and implement the solution.
Communication and coordination: This includes the effort required to communicate and coordinate with
stakeholders, such as customers and other teams.
Testing and validation: This includes the effort required to test and validate the solution to ensure that it
is working correctly and that it does not cause any new problems.
The cost and effort of software maintenance can be reduced by:
Adopting a proactive maintenance strategy that includes regular testing, monitoring, and updating of the
system to prevent problems from occurring
Automating repetitive and routine tasks
Using modern development methodologies such as Agile, DevOps and Continuous Integration and
Continuous Deployment (CI/CD)
Using tools and technologies that can help to improve the efficiency of maintenance tasks, such as
automated testing tools and configuration management tools
Having a clear and well-defined maintenance plan that includes regular maintenance activities, such as
testing, backup, and bug fixing.
It’s important to note that software maintenance is an ongoing process, and the cost and effort of
maintenance will vary over time as the system evolves and new requirements are added.
Categories of Software Maintenance:
Corrective Maintenance
Adaptive Maintenance
Perfective Maintenance
Preventive Maintenance
The cost of system maintenance represents a large proportion of the budget of most organizations that
use software system. More than 65% of software lifecycle cost is expanded in the maintenance activities.
Cost of software maintenance can be controlled by postponing the. development opportunity of software
maintenance but this will cause the following intangible cost:
Customer dissatisfaction when requests for repair or modification cannot be addressed in a timely
manner.
Reduction in overall software quality as a result of changes that introduce hidden errors in maintained
software.
Software maintenance cost factors:
The key factors that distinguish development and maintenance and which lead to higher maintenance
cost are divided into two subcategories:
Non-Technical factors
Technical factors
Complexity of the software system: The more complex the software system, the more effort and
resources will be required to maintain it.
Size of the software system: The larger the software system, the more effort and resources will be
required to maintain it.
Number of users: The more users a software system has, the more effort and resources will be required
to maintain it.
Change rate of the software system: The more frequently the software system changes, the more effort
and resources will be required to maintain it.
Availability of personnel: The availability of personnel with the necessary skills and experience to
maintain the software system can affect the cost of maintenance.
Tools and technologies: The cost of maintenance can be affected by the tools and technologies used to
maintain the software system, such as automated testing tools and configuration management tools.
Maintenance plan: Having a clear and well-defined maintenance plan can help to reduce the cost of
maintenance by allowing for more efficient use of resources.
Age of the software system: Older systems may require more effort to maintain as the technology may
be outdated.
Type of maintenance: The type of maintenance being performed can also affect the cost, for example,
corrective maintenance is typically less expensive than perfective maintenance.
Location: The cost of maintenance can be affected by the location of the system and the cost of labor in
that area.
Non-Technical factors:
The Non-Technical factors include:
Application Domain
Staff stability
Program lifetime
Dependence on External Environment
Hardware stability
Technical factors:
Technical factors include the following:
module independence
Programming language
Programming style
Program validation and testing
Documentation
Configuration management techniques
Efforts expanded on maintenance may be divided into productivity activities (for example analysis and
evaluation, design and modification, coding). The following expression provides a module of maintenance
efforts:
M = P + Ke(C - D)

where,
M: Total effort expanded on the maintenance.
P: Productive effort.
K: An empirical constant.
C: A measure of complexity that can be attributed to a lack of good design and documentation.
D: A measure of the degree of familiarity with the software.

Software Re-engineering is a process of software development which is done to improve the

maintainability of a software system. Re-engineering is the examination and alteration of a system to
reconstitute it in a new form. This process encompasses a combination of sub-processes like reverse
engineering, forward engineering, reconstructing etc.
Re-engineering, also known as reverse engineering or software re-engineering, is the process of analyzing,
designing, and modifying existing software systems to improve their quality, performance, and
maintainability. This can include updating the software to work with new hardware or software platforms,
adding new features, or improving the software’s overall design and architecture.
Software re-engineering, also known as software restructuring or software renovation, refers to the process
of improving or upgrading existing software systems to improve their quality, maintainability, or
functionality. It involves reusing the existing software artifacts, such as code, design, and documentation,
and transforming them to meet new or updated requirements.
The primary goal of software re-engineering is to improve the quality and maintainability of the software
system, while minimizing the risks and costs associated with the redevelopment of the system from scratch.
Software re-engineering can be initiated for various reasons, such as:
Improving software quality: Re-engineering can help improve the quality of software by eliminating defects,
improving performance, and enhancing reliability and maintainability.
Updating technology: Re-engineering can help modernize the software system by updating the technology
used to develop, test, and deploy the system.
Enhancing functionality: Re-engineering can help enhance the functionality of the software system by
adding new features or improving existing ones.
Resolving issues: Re-engineering can help resolve issues related to scalability, security, or compatibility with
other systems.
The process of software re-engineering involves the following steps:
Planning: The first step is to plan the re-engineering process, which involves identifying the reasons for re-
engineering, defining the scope, and establishing the goals and objectives of the process.
Analysis: The next step is to analyze the existing system, including the code, documentation, and other
artifacts. This involves identifying the system’s strengths and weaknesses, as well as any issues that need
to be addressed.
Design: Based on the analysis, the next step is to design the new or updated software system. This involves
identifying the changes that need to be made and developing a plan to implement them.
Implementation: The next step is to implement the changes by modifying the existing code, adding new
features, and updating the documentation and other artifacts.
Testing: Once the changes have been implemented, the software system needs to be tested to ensure that
it meets the new requirements and specifications.
Deployment: The final step is to deploy the re-engineered software system and make it available to end-
users.
Overall, software re-engineering can be a cost-effective way to improve the quality and functionality of
existing software systems, while minimizing the risks and costs associated with starting from scratch.
Re-engineering can be done for a variety of reasons, such as:
To improve the software’s performance and scalability: By analyzing the existing code and identifying
bottlenecks, re-engineering can be used to improve the software’s performance and scalability.
To add new features: Re-engineering can be used to add new features or functionality to existing
software.
To support new platforms: Re-engineering can be used to update existing software to work with new
hardware or software platforms.
To improve maintainability: Re-engineering can be used to improve the software’s overall design and
architecture, making it easier to maintain and update over time.
To meet new regulations and compliance: Re-engineering can be done to ensure that the software is
compliant with new regulations and standards.
Re-engineering can be a complex and time-consuming process, and it requires a thorough understanding
of the existing software system. It also requires a structured and disciplined approach to software
development, similar to software engineering.
Re-engineering can be beneficial in many cases, it can help to improve the quality, performance, and
maintainability of existing software systems, but it also has its own drawbacks, such as:
High costs: Re-engineering can be a resource-intensive process and can require a significant investment in
tools and training.
Risk of introducing new bugs: Changing existing code can introduce new bugs and compatibility issues.
High learning curve: Re-engineering can be complex, and it requires a lot of learning and training, which
can be challenging for new developers.
Software re-engineering, also known as software system re-engineering or software renovation, is the
process of transforming an existing software system into a new system that meets the changing needs of
users or business requirements. Re-engineering involves analyzing the existing system, identifying its
strengths and weaknesses, and making changes to improve its overall quality, maintainability, and
functionality.
The goals of software re-engineering include improving the maintainability, reliability, and performance of
the software system, reducing the cost of maintenance and support, and extending the useful life of the
system. Re-engineering can also involve updating the technology stack or migrating the system to a new
platform or architecture.

The process of software re-engineering typically involves the following steps:

Assessment: The existing software system is analyzed to identify its strengths and weaknesses, and to
determine the extent of the required re-engineering effort.
Planning: A plan is developed to guide the re-engineering effort, including the identification of goals,
objectives, and performance metrics.
Requirements analysis: The requirements of the new system are defined based on user needs and
business requirements.
Architecture and design: The architecture and design of the new system are developed, taking into
account the requirements of the new system and the limitations of the existing system.
Implementation: The new system is developed and implemented, either by modifying the existing system
or by developing a new system from scratch.
Testing: The new system is tested to ensure that it meets the requirements of the new system and is free
from errors and defects.
Maintenance: The new system is maintained over time to ensure that it remains reliable, performant, and
secure.
Advantages of software re-engineering include:
Improved system performance and reliability: Re-engineering can improve the performance and reliability
of the software system, making it more efficient and less prone to errors or failures.
Reduced maintenance costs: Re-engineering can reduce the cost of maintaining and supporting the
software system over time, by improving its maintainability and reducing the frequency of required
maintenance activities.
Increased user satisfaction: Re-engineering can improve the usability and functionality of the software
system, enhancing user satisfaction and increasing adoption rates.

Disadvantages of software re-engineering include:

Increased development time and cost: Re-engineering requires significant time and resources, which can
increase development costs and delay time-to-market.
Risk of introducing new errors or defects: Re-engineering can introduce new errors or defects into the
software system if not done carefully and thoroughly.
Overall, software re-engineering can be an effective way to improve the quality and functionality of an
existing software system. However, it is important to carefully assess the risks and benefits of re-
engineering and to plan and execute the re-engineering effort carefully to ensure a successful outcome.
It’s important to weigh the pros and cons of re-engineering and determine if it is the right approach for a
particular software system.
Re-engineering is the reorganizing and modifying existing software systems to make them more
maintainable.

Objectives of Re-engineering:

To describe a cost-effective option for system evolution.

To describe the activities involved in the software maintenance process.
To distinguish between software and data re-engineering and to explain the problems of data re-
engineering.
Steps involved in Re-engineering:

Inventory Analysis
Document Reconstruction
Reverse Engineering
Code Reconstruction
Data Reconstruction
Forward Engineering
Diagrammatic Representation:

Re-engineering Cost Factors:

The quality of the software to be re-engineered

The tool support available for re-engineering
The extent of the required data conversion
The availability of expert staff for re-engineering
Re-engineering can be a costly process, and there are several factors that can affect the cost of re-engineering
a software system:
Size and complexity of the software: The larger and more complex the software system, the more time and
resources will be required to analyze, design, and modify it.
Number of features to be added or modified: The more features that need to be added or modified, the
more time and resources will be required.
Tools and technologies used: The cost of re-engineering can be affected by the tools and technologies used,
such as the cost of software development tools and the cost of hardware and infrastructure.
Availability of documentation: If the documentation of the existing system is not available or is not accurate,
then it will take more time and resources to understand the system.
Team size and skill level: The size and skill level of the development team can also affect the cost of re-
engineering. A larger and more experienced team may be able to complete the project faster and with
fewer resources.
Location and rate of the team: The location and rate of the development team can also affect the cost of
re-engineering. Hiring a team in a lower-cost location or with lower rates can help to reduce the cost of re-
engineering.
Testing and quality assurance: Testing and quality assurance are important aspects of re-engineering, and
they can add significant costs to the project.
Post-deployment maintenance: The cost of post-deployment maintenance such as bug fixing, security
updates, and feature additions can also play a role in the cost of re-engineering.
In summary, the cost of re-engineering a software system can vary depending on a variety of factors,
including the size and complexity of the software, the number of features to be added or modified, the
tools and technologies used, and the availability of documentation and the skill level of the development
team. It’s important to carefully consider these factors when estimating the cost of re-engineering a
software system.
Advantages of Re-engineering:
Reduced Risk: As the software is already existing, the risk is less as compared to new software development.
Development problems, staffing problems and specification problems are the lots of problems that may
arise in new software development.
Reduced Cost: The cost of re-engineering is less than the costs of developing new software.
Revelation of Business Rules: As a system is re-engineered , business rules that are embedded in the
system are rediscovered.
Better use of Existing Staff: Existing staff expertise can be maintained and extended accommodate new
skills during re-engineering.
Improved efficiency: By analyzing and redesigning processes, re-engineering can lead to significant
improvements in productivity, speed, and cost-effectiveness.
Increased flexibility: Re-engineering can make systems more adaptable to changing business needs and
market conditions.
Better customer service: By redesigning processes to focus on customer needs, re-engineering can lead to
improved customer satisfaction and loyalty.
Increased competitiveness: Re-engineering can help organizations become more competitive by improving
efficiency, flexibility, and customer service.
Improved quality: Re-engineering can lead to better quality products and services by identifying and
eliminating defects and inefficiencies in processes.
Increased innovation: Re-engineering can lead to new and innovative ways of doing things, helping
organizations to stay ahead of their competitors.
Improved compliance: Re-engineering can help organizations to comply with industry standards and
regulations by identifying and addressing areas of non-compliance.
Disadvantages of Re-engineering:
Practical limits to the extent of re-engineering.
Major architectural changes or radical reorganizing of the systems data management has to be done
manually.
Re-engineered system is not likely to be as maintainable as a new system developed using modern software
Re-engineering methods.
High costs: Re-engineering can be a costly process, requiring significant investments in time, resources, and
technology.
Disruption to business operations: Re-engineering can disrupt normal business operations and cause
inconvenience to customers, employees and other stakeholders.
Resistance to change: Re-engineering can encounter resistance from employees who may be resistant to
change and uncomfortable with new processes and technologies.
Risk of failure: Re-engineering projects can fail if they are not planned and executed properly, resulting in
wasted resources and lost opportunities.
Lack of employee involvement: Re-engineering projects that are not properly communicated and involve
employees, may lead to lack of employee engagement and ownership resulting in failure of the project.
Difficulty in measuring success: Re-engineering can be difficult to measure in terms of success, making it
difficult to justify the cost and effort involved.
Difficulty in maintaining continuity: Re-engineering can lead to significant changes in processes and
systems, making it difficult to maintain continuity and consistency in the organization.

Whenever a software is build, there is always scope for improvement and those improvements brings
changes in picture. Changes may be required to modify or update any existing solution or to create a new
solution for a problem. Requirements keeps on changing on daily basis and so we need to keep on
upgrading our systems based on the current requirements and needs to meet desired outputs. Changes
should be analyzed before they are made to the existing system, recorded before they are implemented,
reported to have details of before and after, and controlled in a manner that will improve quality and
reduce error. This is where the need of System Configuration Management comes. System Configuration
Management (SCM) is an arrangement of exercises which controls change by recognizing the items for
change, setting up connections between those things, making/characterizing instruments for overseeing
diverse variants, controlling the changes being executed in the current framework, inspecting and
revealing/reporting on the changes made. It is essential to control the changes in light of the fact that if
the changes are not checked legitimately then they may wind up undermining a well-run programming. In
this way, SCM is a fundamental piece of all project management activities. Processes involved in SCM –
Configuration management provides a disciplined environment for smooth control of work products. It
involves the following activities:
Identification and Establishment – Identifying the configuration items from products that compose
baselines at given points in time (a baseline is a set of mutually consistent Configuration Items, which has
been formally reviewed and agreed upon, and serves as the basis of further development). Establishing
relationship among items, creating a mechanism to manage multiple level of control and procedure for
change management system.
Version control – Creating versions/specifications of the existing product to build new products from the
help of SCM system. A description of version is given below:

Suppose after some changes, the

version of configuration object changes from 1.0 to 1.1. Minor corrections and changes result in versions
1.1.1 and 1.1.2, which is followed by a major update that is object 1.2. The development of object 1.0
continues through 1.3 and 1.4, but finally, a noteworthy change to the object results in a new
evolutionary path, version 2.0. Both versions are currently supported.
Change control – Controlling changes to Configuration items (CI). The change control process is explained

in Figure below: A change request

(CR) is submitted and evaluated to assess technical merit, potential side effects, overall impact on other
configuration objects and system functions, and the projected cost of the change. The results of the
evaluation are presented as a change report, which is used by a change control board (CCB) —a person or
group who makes a final decision on the status and priority of the change. An engineering change Request
(ECR) is generated for each approved change. Also CCB notifies the developer in case the change is
rejected with proper reason. The ECR describes the change to be made, the constraints that must be
respected, and the criteria for review and audit. The object to be changed is “checked out” of the project
database, the change is made, and then the object is tested again. The object is then “checked in” to the
database and appropriate version control mechanisms are used to create the next version of the
software.
Configuration auditing – A software configuration audit complements the formal technical review of the
process and product. It focuses on the technical correctness of the configuration object that has been
modified. The audit confirms the completeness, correctness and consistency of items in the SCM system
and track action items from the audit to closure.
Reporting – Providing accurate status and current configuration data to developers, tester, end users,
customers and stakeholders through admin guides, user guides, FAQs, Release notes, Memos, Installation
Guide, Configuration guide etc .
System Configuration Management (SCM) is a software engineering practice that focuses on managing
the configuration of software systems and ensuring that software components are properly controlled,
tracked, and stored. It is a critical aspect of software development, as it helps to ensure that changes
made to a software system are properly coordinated and that the system is always in a known and stable
state.
SCM involves a set of processes and tools that help to manage the different components of a software
system, including source code, documentation, and other assets. It enables teams to track changes made
to the software system, identify when and why changes were made, and manage the integration of these
changes into the final product.

The key objectives of SCM are to:

Control the evolution of software systems: SCM helps to ensure that changes to a software system are
properly planned, tested, and integrated into the final product.
Enable collaboration and coordination: SCM helps teams to collaborate and coordinate their work,
ensuring that changes are properly integrated and that everyone is working from the same version of the
software system.
Provide version control: SCM provides version control for software systems, enabling teams to manage
and track different versions of the system and to revert to earlier versions if necessary.
Facilitate replication and distribution: SCM helps to ensure that software systems can be easily replicated
and distributed to other environments, such as test, production, and customer sites.
SCM is a critical component of software development, and effective SCM practices can help to improve
the quality and reliability of software systems, as well as increase efficiency and reduce the risk of errors.
The main advantages of SCM are:
Improved productivity and efficiency by reducing the time and effort required to manage software
changes.
Reduced risk of errors and defects by ensuring that all changes are properly tested and validated.
Increased collaboration and communication among team members by providing a central repository for
software artifacts.
Improved quality and stability of software systems by ensuring that all changes are properly controlled
and managed.

The main disadvantages of SCM are:

Increased complexity and overhead, particularly in large software systems.
Difficulty in managing dependencies and ensuring that all changes are properly integrated.
Potential for conflicts and delays, particularly in large development teams with multiple contributors.

Control changes is a process used to ensure that the changes to a system or product are introduced in a well-
coordinated and controlled manner.

In an Information Technology based company, control changes systems are used to identify, document, and implement
changes. The process involved in change control is mainly formal and it includes aspects like policies, resources needed
to meet the required specifications, time, and project schedule.

To ultimately achieve a long-term goal, it may become necessary to make use of a new set of strategies because of the
external considerations used regularly. Examples of these considerations include potential high costs of input, a rise of
different technologies, changes in customer demand as a result of changes in market structure, and so on.

The change control process gives the customer the ability to effect changes in the work scope. The process involved in
change control is usually carried out as a sequence of steps starting from the submission of a change request.

In software engineering industries, change control is a major aspect of change management (a broader section of
change control). It is mostly used in modifying characteristics of systems or applications to suit various requirements,
bringing new features to the application software, patch network, or installation changes.

The purpose of using change control systems is to ensure that all changes are implemented, there are no unnecessary
changes, the resources are properly utilized and there is no unnecessary disruption in the service rendered.

Why is change control important in software engineering?

When a stakeholder requests a different or new change for a particular system. It cannot be ignored neither is it
optional. It must be implemented in such a way that other components of the system are not affected. Change control is
used in these scenarios because it helps the project teams to modify the project scope. This is done by using specific
policies and controls.

Change control comes in handy when a project is going as planned. A formal document used for the change request
must be properly completed and reviewed to keep control of change requests.

What is a “version control system”?

Version control systems are a category of software tools that helps in recording changes made to files by
keeping a track of modifications done in the code.
Why Version Control system is so Important?
As we know that a software product is developed in collaboration by a group of developers they might be
located at different locations and each one of them contributes to some specific kind of
functionality/features. So in order to contribute to the product, they made modifications to the source
code(either by adding or removing). A version control system is a kind of software that helps the
developer team to efficiently communicate and manage(track) all the changes that have been made to
the source code along with the information like who made and what changes have been made. A separate
branch is created for every contributor who made the changes and the changes aren’t merged into the
original source code unless all are analyzed as soon as the changes are green signaled they merged to the
main source code. It not only keeps source code organized but also improves productivity by making the
development process smooth.

Basically Version control system keeps track on changes made on a particular software and take a
snapshot of every modification. Let’s suppose if a team of developer add some new functionalities in an
application and the updated version is not working properly so as the version control system keeps track
of our work so with the help of version control system we can omit the new changes and continue with
the previous version.
Benefits of the version control system:
Enhances the project development speed by providing efficient collaboration,
Leverages the productivity, expedites product delivery, and skills of the employees through better
communication and assistance,
Reduce possibilities of errors and conflicts meanwhile project development through traceability to every
small change,
Employees or contributors of the project can contribute from anywhere irrespective of the different
geographical locations through this VCS,
For each different contributor to the project, a different working copy is maintained and not merged to
the main file unless the working copy is validated. The most popular example is Git, Helix core, Microsoft
TFS,
Helps in recovery in case of any disaster or contingent situation,
Informs us about Who, What, When, Why changes have been made.
Use of Version Control System:
A repository: It can be thought of as a database of changes. It contains all the edits and historical versions
(snapshots) of the project.
Copy of Work (sometimes called as checkout): It is the personal copy of all the files in a project. You can
edit to this copy, without affecting the work of others and you can finally commit your changes to a
repository when you are done making your changes.
Working in a group: Consider yourself working in a company where you are asked to work on some live
project. You can’t change the main code as it is in production, and any change may cause inconvenience
to the user, also you are working in a team so you need to collaborate with your team to and adapt their
changes. Version control helps you with the, merging different requests to main repository without
making any undesirable changes. You may test the functionalities without putting it live, and you don’t
need to download and set up each time, just pull the changes and do the changes, test it and merge it
back. It may be visualized as.

Types of Version Control Systems:

Local Version Control Systems
Centralized Version Control Systems
Distributed Version Control Systems
Local Version Control Systems: It is one of the simplest forms and has a database that kept all the
changes to files under revision control. RCS is one of the most common VCS tools. It keeps patch sets
(differences between files) in a special format on disk. By adding up all the patches it can then re-create
what any file looked like at any point in time.
Centralized Version Control Systems: Centralized version control systems contain just one repository
globally and every user need to commit for reflecting one’s changes in the repository. It is possible for
others to see your changes by updating.
Two things are required to make your changes visible to others which are:
You commit
They update

The benefit of CVCS (Centralized Version Control Systems) makes collaboration amongst developers along
with providing an insight to a certain extent on what everyone else is doing on the project. It allows
administrators to fine-grained control over who can do what.
It has some downsides as well which led to the development of DVS. The most obvious is the single point
of failure that the centralized repository represents if it goes down during that period collaboration and
saving versioned changes is not possible. What if the hard disk of the central database becomes
corrupted, and proper backups haven’t been kept? You lose absolutely everything.
Distributed Version Control Systems: Distributed version control systems contain multiple repositories.
Each user has their own repository and working copy. Just committing your changes will not give others
access to your changes. This is because commit will reflect those changes in your local repository and you
need to push them in order to make them visible on the central repository. Similarly, When you update,
you do not get others’ changes unless you have first pulled those changes into your repository.
To make your changes visible to others, 4 things are required:
You commit
You push
They pull
They update
The most popular distributed version control systems are Git, and Mercurial. They help us overcome the
problem of single point of failure.
Purpose of Version Control:
Multiple people can work simultaneously on a single project. Everyone works on and edits their own copy
of the files and it is up to them when they wish to share the changes made by them with the rest of the
team.
It also enables one person to use multiple computers to work on a project, so it is valuable even if you are
working by yourself.
It integrates the work that is done simultaneously by different members of the team. In some rare cases,
when conflicting edits are made by two people to the same line of a file, then human assistance is
requested by the version control system in deciding what should be done.
Version control provides access to the historical versions of a project. This is insurance against computer
crashes or data loss. If any mistake is made, you can easily roll back to a previous version. It is also
possible to undo specific edits that too without losing the work done in the meanwhile. It can be easily
known when, why, and by whom any part of a file was edited.

It has some downsides as well which led to the development of DVS. The most obvious is the single point
of failure that the centralized repository represents if it goes down during that period collaboration and
saving versioned changes is not possible. What if the hard disk of the central database becomes
corrupted, and proper backups haven’t been kept? You lose absolutely everything.
Distributed Version Control Systems: Distributed version control systems contain multiple repositories.
Each user has their own repository and working copy. Just committing your changes will not give others
access to your changes. This is because commit will reflect those changes in your local repository and you
need to push them in order to make them visible on the central repository. Similarly, When you update,
you do not get others’ changes unless you have first pulled those changes into your repository.
To make your changes visible to others, 4 things are required:
You commit
You push
They pull
They update
The most popular distributed version control systems are Git, and Mercurial. They help us overcome the
problem of single point of failure.

Purpose of Version Control:

Multiple people can work simultaneously on a single project. Everyone works on and edits their own copy
of the files and it is up to them when they wish to share the changes made by them with the rest of the
team.
It also enables one person to use multiple computers to work on a project, so it is valuable even if you are
working by yourself.
It integrates the work that is done simultaneously by different members of the team. In some rare cases,
when conflicting edits are made by two people to the same line of a file, then human assistance is
requested by the version control system in deciding what should be done.
Version control provides access to the historical versions of a project. This is insurance against computer
crashes or data loss. If any mistake is made, you can easily roll back to a previous version. It is also
possible to undo specific edits that too without losing the work done in the meanwhile. It can be easily
known when, why, and by whom any part of a file was edited.
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

Now we briefly go through various CASE tools

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.

Estimation of Various Parameters such as Cost:

The cost estimation is a tool to estimate the planning, budgeting and resource utilization for the software
projects.

Effort: The amount of effort required to complete the development of software projects in terms of Man-
Months (MM).
Development Duration: The time duration required to complete the development of a software project
i.e. total development time.

Resources: The number of Manpower required for a software project in terms of time to complete.

There are multiple SCE methods/models in terms of size or type of project or in a

static nature with dependent factors (single parameter or multi parameters). Such as:

COCOMO or Algorithmic Model

It is called the Constructive Cost Model, which is mainly used for software cost estimation i.e. it
estimates/predicts the effort required for the project, total project cost and scheduled time for the
project. This model depends on the number of lines of code for software product development. It also
estimates the required number of Man-Months (MM) for the full development of software products.

Wideband Delphi or expert Judgment Model

Expert Judgment is a technique in which judgment is provided based upon a specific set of criteria and/or
expertise that has been acquired in a specific knowledge area, application area, or product area, a
particular discipline, an industry, etc. Such expertise may be provided by any group or person with
specialized education, knowledge, skill, experience, or training

Static Single Variable Model

A single variable is taken as a key element for calculating cost and time. In a dynamic model, all variables
are interdependent, and there is no basic variable. The Software Engineering Laboratory established a
model called SEL model, for estimating its software production.

Static Multivariable Model

These models are also known as multivariable models. This model is often based on the first equation and
actually depends on several variables representing different aspects of the software development
environment.

Estimation by Past Project Model

The software cost estimation is done for the new project by comparing the previous completed project
estimation. Here the estimation cost should be reconsidered. Sometimes we manipulate estimation to
win the Contract of project.
COCOMO Model
Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines of Code. It is a
procedural cost estimate model for software projects and is often used as a process of reliably predicting
the various parameters associated with making a project such as size, effort, cost, time, and quality. It was
proposed by Barry Boehm in 1981 and is based on the study of 63 projects, which makes it one of the
best-documented models. The key parameters which define the quality of any software products, which
are also an outcome of the Cocomo are primarily Effort & Schedule:
Effort: Amount of labor that will be required to complete a task. It is measured in person-months units.
Schedule: Simply means the amount of time required for the completion of the job, which is, of course,
proportional to the effort put in. It is measured in the units of time such as weeks, and months.
Different models of Cocomo have been proposed to predict the cost estimation at different levels, based
on the amount of accuracy and correctness required. All of these models can be applied to a variety of
projects, whose characteristics determine the value of the constant to be used in subsequent calculations.
These characteristics pertaining to different system types are mentioned below. Boehm’s definition of
organic, semidetached, and embedded systems:
Organic – A software project is said to be an organic type if the team size required is adequately small, the
problem is well understood and has been solved in the past and also the team members have a nominal
experience regarding the problem.
Semi-detached – A software project is said to be a Semi-detached type if the vital characteristics such as
team size, experience, and knowledge of the various programming environment lie in between that of
organic and Embedded. The projects classified as Semi-Detached are comparatively less familiar and
difficult to develop compared to the organic ones and require more experience and better guidance and
creativity. Eg: Compilers or different Embedded Systems can be considered Semi-Detached types.
Embedded – A software project requiring the highest level of complexity, creativity, and experience
requirement fall under this category. Such software requires a larger team size than the other two models
and also the developers need to be sufficiently experienced and creative to develop such complex
models.
Basic COCOMO Model
Intermediate COCOMO Model
Detailed COCOMO Model
Basic Model –

The above formula is used for the cost estimation of for the basic COCOMO model, and also is used in the
subsequent models. The constant values a,b,c, and d for the Basic Model for the different categories of
the system:
 Software a b c d
Projects

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

The effort is measured in Person-Months and as evident from the formula is dependent on Kilo-Lines of
code. The development time is measured in months. These formulas are used as such in the Basic Model
calculations, as not much consideration of different factors such as reliability, and expertise is taken into
account, henceforth the estimate is rough. Below is the C++ program for Basic COCOMO.
CPP
Java
Python3
Javascript
C#

// C++ program to implement basic COCOMO

#include <bits/stdc++.h>

using namespace std;

// Function
// For rounding off float to int
int fround(float x)
{
int a;
x = x + 0.5;
a = x;
return (a);
}

// Function to calculate parameters of Basic COCOMO

void calculate(float table[][4], int n, char mode[][15],
int size)
{
float effort, time, staff;

int model;

// Check the mode according to size

 if (size >= 2 && size <= 50)
model = 0; // organic

else if (size > 50 && size <= 300)

model = 1; // semi-detached

else if (size > 300)

model = 2; // embedded

cout << "The mode is " << mode[model];

// Calculate Effort
effort = table[model][0] * pow(size, table[model][1]);

// Calculate Time
time = table[model][2] * pow(effort, table[model][3]);

// Calculate Persons Required

staff = effort / time;

// Output the values calculated

cout << "\nEffort = " << effort << " Person-Month";

cout << "\nDevelopment Time = " << time << " Months";

cout << "\nAverage Staff Required = " << fround(staff)

<< " Persons";
}

int main()
{
float table[3][4] = { 2.4, 1.05, 2.5, 0.38, 3.0, 1.12,
2.5, 0.35, 3.6, 1.20, 2.5, 0.32 };

char mode[][15]
= { "Organic", "Semi-Detached", "Embedded" };

int size = 4;

calculate(table, 3, mode, size);

return 0;
}

Output:The mode is Organic

Effort = 10.289 Person-Month
Development Time = 6.06237 Months
Average Staff Required = 2 Persons
1. Intermediate Model – The basic Cocomo model assumes that the effort is only a function of the number
of lines of code and some constants evaluated according to the different software systems. However, in
reality, no system’s effort and schedule can be solely calculated on the basis of Lines of Code. For that,
various other factors such as reliability, experience, and Capability. These factors are known as Cost Drivers
and the Intermediate Model utilizes 15 such drivers for cost estimation. Classification of Cost Drivers and
their Attributes:
(i) Product attributes –
Required software reliability extent
Size of the application database
The complexity of the product
Run-time performance constraints
Memory constraints
The volatility of the virtual machine environment
Required turnabout time
Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language experience
Use of software tools
Application of software engineering methods
Required development schedule
2. Detailed Model – Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering process. The detailed
model uses different effort multipliers for each cost driver attribute. In detailed cocomo, the whole
software is divided into different modules and then we apply COCOMO in different modules to estimate
effort and then sum the effort. The Six phases of detailed COCOMO are:
Planning and requirements
System design
Detailed design
Module code and test
Integration and test
Cost Constructive model
Advantages of the COCOMO model:
Provides a systematic way to estimate the cost and effort of a software project.
Can be used to estimate the cost and effort of a software project at different stages of the development
process.
Helps in identifying the factors that have the greatest impact on the cost and effort of a software project.
Can be used to evaluate the feasibility of a software project by estimating the cost and effort required to
complete it.
Disadvantages of the COCOMO model:
Assumes that the size of the software is the main factor that determines the cost and effort of a software
project, which may not always be the case.
Does not take into account the specific characteristics of the development team, which can have a
significant impact on the cost and effort of a software project.
Does not provide a precise estimate of the cost and effort of a software project, as it is based on
assumptions and averages.

Resource Allocation Model

To assign the available resources in an economic way is known as resource allocation. The planning of the
activities and the resource required by these activities while taking into consideration both resources
availability and project time is termed as resource allocation in project management.
There are 2 parts of resource allocation: Strategic Planning, and Resource Leveling. These are explained as
following below.
Strategic planning –
In strategic planning resource allocation is a plan for using available resources, for example human
resources, specially in the near term, to achieve goals for the future. It is the process of allocating
resources among various projects or business units. The strategic planning has 2 parts.
There is the basic allocation decision.
There is the contingency mechanism.
The basic allocation decision is the choice of which items to fund in the plan and what level of fund in it
should receive and which to leave unfunded; the resources are located to some items and not to others.

There may be contingency mechanism such as priority ranking of items excluded from the plan, showing
which items are to be sacrificed to reduce total funding.
Resource Leveling –
The main objective is to smooth resource requirement by shifting slack jobs beyond periods of peak
requirement. Some of the methods essentially replicate what a human scheduler do if he has enough
time, procedures design especially for the computer. They of course depend for their success on the
speed and capabilities of electronic compilers.
Approach for resource allocation :
There are number of approaches to solve resource allocation problems:
Manual Approach
Algorithmic Approach
Combination of both
In algorithmic approach resource is allocated by using some computer program which is defined for a
specific domain, this will automatically and dynamically distribute resources to the user. Electronic
devices dedicated to routing and communication is commonly use this method. For example: channel
allocation in wireless communication may be decided by base transceiver using an appropriate algorithm.

Risk Management:
A risk is a probable problem- it might happen or it might not. There are main two characteristics of risk
Uncertainty- the risk may or may not happen that means there are no 100% risks.
loss – If the risk occurs in reality , undesirable result or losses will occur.
Risk management is a sequence of steps that help a software team to understand , analyze and manage
uncertainty. Risk management consists of
Risk Identification
Risk analysis
Risk Planning
Risk
Monitoring
A computer code project may be laid low with an outsized sort of risk. so as to be ready to consistently
establish the necessary risks which could have an effect on a computer code project, it’s necessary to
reason risks into completely different categories. The project manager will then examine the risks from
every category square measure relevant to the project.
There square measure 3 main classes of risks that may have an effect on a computer code project:

Project Risks:
Project risks concern various sorts of monetary funds, schedules, personnel, resource, and customer-
related issues. a vital project risk is schedule slippage. Since computer code is intangible, it’s terribly tough
to observe and manage a computer code project. it’s terribly tough to manage one thing that can not be
seen. For any producing project, like producing cars, the project manager will see the merchandise taking
form.
For example, see that the engine is fitted, at the moment the area of the door unit fitted, the automotive
is obtaining painted, etc. so he will simply assess the progress of the work and manage it. The physical
property of the merchandise being developed is a vital reason why several computer codes come to suffer
from the danger of schedule slippage.

Technical Risks:
Technical risks concern potential style, implementation, interfacing, testing, and maintenance issues.
Technical risks conjointly embody ambiguous specifications, incomplete specification, dynamic
specification, technical uncertainty, and technical degeneration. Most technical risks occur thanks to the
event team’s lean information concerning the project.

Business Risks:
This type of risk embodies the risks of building a superb product that nobody needs, losing monetary
funds or personal commitments, etc.
Classification of Risk in a project:
Example: Let us consider a satellite based mobile communication project. The project manager can
identify several risks in this project. Let us classify them appropriately.
What if the project cost escalates and overshoots what was estimated? – Project Risk
What if the mobile phones that are developed become too bulky in size to conveniently carry? Business
Risk
What if call hand-off between satellites becomes too difficult to implement? Technical Risk