Software Engineering and Project Management - A Beginner's Guide - Part 5

21CSC303J – SOFTWARE
ENGINEERING AND PROJECT
MANAGEMENT
UNIT V

PRODUCT RELEASE MANAGEMENT
Product release management in software engineering is the systematic process of planning, designing, scheduling,
testing, deploying, and controlling software releases to ensure efficient delivery and maintain production stability.
the primary goal of product release management is To ensure smooth deployment and delivery of software updates
testing phase in release management ensures that a software update does not negatively impact existing
functionality.
 A structured approach:
Release management provides a framework for managing the entire software release lifecycle, from initial planning to
post-release analysis.
 Ensuring smooth deployments:
It aims to minimize disruptions and downtime during software updates and deployments.
 Collaboration and communication:
It facilitates collaboration between development, testing, and operations teams to ensure a smooth and efficient release
process.
 Maintaining production stability:
• It focuses on maintaining the integrity of the existing production environment during and after software releases.

Key Activities in Release Management:
 Release Planning:
o Defining the scope and objectives of the release.
o Identifying features and functionalities to be included in the release.
o Determining the release schedule and timeline.
 Preparing the Release:
o Building and packaging the software release.
o Creating deployment scripts and procedures.
o Ensuring that all necessary resources are available for the release.
 Testing and Quality Assurance:
o Conducting thorough testing to identify and fix bugs and issues.
o Performing user acceptance testing (UAT) to ensure that the software
meets user requirements.
o

 Deployment:
o Deploying the software release to the production environment.
o Monitoring the deployment process to ensure that it is successful.
o Rolling back the release if necessary.
 Post-Release Analysis:
o Gathering user feedback and analyzing the performance of the release.
o Identifying areas for improvement and making changes to the release management
process.
 Change Control:
o Managing changes to the software release during development and after
deployment.
o Ensuring that all changes are properly documented and approved.

Importance of Release Management:
 Reduced risk:
It helps to minimize the risk of deploying faulty software into production.
 Improved efficiency:
It streamlines the release process, leading to faster and more efficient software
deployments.
 Enhanced quality:
It ensures that software releases are of high quality and meet user expectations.
 Increased customer satisfaction:
It helps to ensure that customers receive timely and reliable software updates.
 Better collaboration:
• It fosters better collaboration between different teams involved in the software
development process.

RELEASE MANAGEMENT PROCESS
A Release management process may likely mean different things to a product
management team and a development team.
• Both perspectives are strongly incorporated into a dependable release
management process.
• A release management process incorporates all of the following:
• 1)Planning
• An initial release plan takes into account the team's velocity on the previous
release (or general capacity to deliver) and the feature prioritization to create a
general scope, sequencing, and timeline for the release.
• During release planning, a general expectation on the number of sprints or
iterations to deliver the scope is achieved.
• The accuracy of this expectation and plan depends on whether the team's
capacity is well-known as well as the level of detail (or grooming) the scope
has been through during estimation.

• This general plan will also provide expectations of major
product changes (or dependencies) for products that may
depend on your roadmap or platform.
• Plans will be revisited after each iteration. For this reason, a
tracking of an external release target (with quarterly, monthly,
or other precision) can be helpful.
• It will still set the expectation and trust with your customers,
but can be refined by you as the plan progresses.

2) Phased communication and supporting team engagement
• Product managers know best how to deliver their product
successfully — and that includes a series of non-development
tasks of engagement with supporting teams to complete items
like documentation, sales training, or marketing campaigns.
• As a product manager, establishing a launch or release template
will enable you to create a "gold standard" for major delivery.
• Use this template to engage your greater team, who may be
supporting multiple products in the portfolio only when needed.
• A standard for launch also sets expectation for when these teams
will be needed internally

3) Repeatable stages to readiness
• Establish standardized status at both the release and feature level to indicate
overall health of the plan.
• Status provides an "Are we good?" pulse point that can be key to seeing around
corners and proactive risk mitigation.
• A release status will enable communication to your internal stakeholders, while
feature status workflows enable granular visibility into the readiness of the
feature and its current status with respect to development, staging, or QA
environments
4)Forward adjustment on plan
• Regardless of whether your release plan is executed in sprints or via more
waterfall methodologies, regular check-ins and adjustments to plan are
necessary.
• Use your sprint closure to adjust plans as needed, or schedule regular reviews to
ensure plans are on track

Product Release Management
• Project teams working for software product vendors struggle to keep pace with
release of the software product.
• There is pressure from the market to launch new versions by certain dates.
• New features are to be added, porting the product to new platforms, old features
are to be enhanced, existing bugs are to be removed, and yet it has to meet the
deadline.
• It is a constant struggle that calls for good product release strategies.
• Depending on the situation, the project manager may need to convince the
management to cut short some of the product features to meet the deadline as
well as meet quality standards.
• A half-baked product will never have any takers; instead the project manager
may be blamed for its poor quality issues.
• Bargaining also has to be done for other requirements of bug fixes, feature
enhancements, etc. If quality concerns are paramount, then moving some of the
tasks of new features to a future release may be the best solution for meeting
quality standards.
• If the software vendor is not too sure about product quality, then he may opt for
an alpha or beta release of the product.
• In that case, the product will be released only among a few selected groups and
not in the market as a whole. The controlled product release is the best option in

• Product release management is such a dynamic environment that if proper planning is not done at a minute
level and constant vigilance is not applied over project activities, then a huge mess can be created and there
will be no time to clear it.
• So the project manager must be vigilant all the time
• Walk around for known issues, estimated number of critical bugs still remaining in the product, training for
the support staff, etc., should be done.
• The cost of support, depending on the number of estimated users, walk around, and remaining bugs should be
figured out.
• These measures will ensure that the product is transitioned into market without facing major difficulties.

Product Implementation
• The product that has been developed and thoroughly tested now needs to be implemented at a
customer site.
• You need to prepare all master data and test transaction data for testing the implemented product.
• You need to get all required hardware and software that need to be there for installing your software
product.
• You need to make sure that you have developed and tested all the hardware and software interfaces for
integrating your product, with existing legacy systems and infrastructure.
• You also need to make sure that your product will run smoothly on customer premises without any
interference with their existing applications.
• Often project teams run into problems during implementation, due to unforeseen circumstances or
negligence on part of the production team or customer’s team.
• Therefore, prepare a list of your own requirements and hand it over to your customer’s support team so
that they are prepared when you arrive for implementation.

• A product software implementation method is a blueprint to get users and/or organizations running
with a specific software product.
• The method is a set of rules and views to cope with the most common issues that occur when
implementing a software product: business alignment from the organizational view and acceptance
from human view.
• The implementation of product software, as the final link in the deployment chain of software
production, is in a financial perspective of a major issue.
• It is stated that the implementation of (product) software consumes up to 1/3 of the budget of a
software purchase (more than hardware and software requirements together).

Simple Release Management Template

RISK MANAGEMENT
Risk management in software engineering is defined as the process of
identifying, analysing, ranking, and treating risks that may threaten the
success of a software engineering project.
It is a set of actions and strategies that are taken to reduce the possibility
of risks and their impacts by the achievement of the laid down project
goals and objectives.
The main aim of risk management is to contain the amount of risk and
improve the quality of decision-making because it considers threats and
turns them into strategic concerns before they become critical problems.

RISK MANAGEMENT
the first step in risk management is Risk identification.
Importance of Risk Management
 Project Success: Risk management helps recognise risks and deal with them before they
become serious, which may help keep projects on schedule, on budget, and to the desired
standard.
 Resource Optimization: Managing risks enables the successful use of some resources, scrap
avoidance, and direction of attention to critical project aspects.
 Stakeholder Confidence: Advance risk management can be effective. It can increase the
stakeholders' confidence, as it emphasises delivering a reliable product.
 Adaptability: Risk management helps teams better prepare for any changes in scenarios and
inconvenient situations that may arise, keeping the project on track and steady ground.
 Cost Control: Identification and management of risks to avoid negative consequences that could
lead to overtime and thus cost more than what the project was designed to spend.

OVERVIEW OF RISK MANAGEMENT PROCESS
The risk management process in software engineering typically involves the following
steps.
1. Risk Identification: The first is identifying risks that might harm the project. This
involves using brainstorming, checklists, historical data analysis, and SWOT analysis
to identify risks.
2. Risk Analysis and Evaluation: After identifying risks, they are assessed to
understand their potential consequences and the chances of their occurrence. This
step can be either qualitative, where assessment tools such as the Probability and
Impact Matrix are applied or quantitative, where Monte Carlo Simulation and
Decision Tree Analysis are used.
3. Risk Prioritization: The results from the risk evaluation are then ranked against the
likelihood of occurrence and their impact on the business. To summarise, high-
probability risks represent crucial risks likely to occur and deserve prompt attention.

OVERVIEW OF RISK MANAGEMENT PROCESS
4.Risk Response Planning: In this step, the management strategy entails taking measures to
contain the above risks.
Avoidance: Changing the project schedule in such a way that it will minimise the risk.
Mitigation: Measures that can be taken to minimise the prospect or magnitude of the
threat.
Transfer: This creates a twofold risk division between risk avoidance and risk shifting, typical
of insurance and outsourcing.
Acceptance: Recognising that an adverse event may happen and drawing up a plan to
mitigate if it does occur.
5.Risk Monitoring and Control: Risk management must be monitored across the project life
cycle since risk is never far from the picture. This means carrying out risk analysis
periodically, risk review, and risk audits to achieve an updated risk management plan to
cover all emerging risks.
6.Risk Communication: To manage risks in an organisation, there must be good
communication between the different departments. It maintains openness in handling risks,
the planned measures to prevent them from materialising, and the changes in their status.

PROACTIVE VS REACTIVE RISKS
Difference Between Proactive and Reactive Risk Management
Assigning roles is not the only job that managers do, even if it sometimes seems
like it. In an ideal world, all possible negative outcomes for a company could
be predicted and anticipated. Unfortunately, most businesses operate in risky
situations where there are financial, strategic, geopolitical, and security risks.
Handling such risks and maintaining market competitiveness are the focus of
Strategic Risk Management. The ability to handle problems both Proactively
and Reactively should be a must for any corporate leader.
• Proactive Risk Management is essential to the company but is frequently
disregarded. Business executives frequently respond to issues after harm has
already been done. You need to know the difference between reactive and
proactive risk management if you want to stay at the top of your game for a
long time. In light of the underlying risk, this helps you determine the optimal
course of action.

PROACTIVE RISK MANAGEMENT
Proactive Risk Management:
Every corporate entity prioritizes identifying and proactively managing
risks. The focus of proactive risk management is on using an
innovative strategy to mitigate risks and mitigate harm.
• Entrepreneurs need to be prepared for the difficulties posed by
technological advancements; therefore, management practices that
rely on past dangers are not the best for making informed
decisions. Proactive risk management, notably, may prevent financial
loss and data loss by taking into account current business trends.

REACTIVE RISK MANAGEMENT
Reactive Risk Management:
The reactive method of risk management is a reaction-driven plan that
centers on previous risk events and solutions to issues. When an event
is discovered by an audit, this method helps respond to the danger
accordingly. Following assessment, the risk is addressed, and
preventative actions are implemented.
How does Proactive and Reactive Risk Management differ from one
another?
• Today's corporate environment is full of risks, but cybersecurity is one
of the main concerns. It might thus be difficult to choose the optimal
kind of risk management strategy.

Proactive risk management is defined as "a closed-loop feedback control
strategy that is adaptive and observes the current safety level while utilizing
creative intellectualism to plan and observe the explicit target safety level“
Preventing risks before they happen is a characteristic of proactive risk management.
Reactive risk management is defined as "a response-based approach that is
dependent on accident evaluation and audit-based findings".
The Goal
The goal of proactive risk management is to identify the main risks associated
with your industry, activities, and surroundings in order to lower the
likelihood that your company may encounter further risks.
• Reactive risk management aims to lessen the likelihood that incidents that
occurred in the past will recur in the future.

Duration
By recognizing the main risks associated with your industry, operations, and
environment, proactive risk management seeks to lower the likelihood that your
company may encounter a variety of dangers. Proactive risk management
integrates past, present, and future projections to develop a solution strategy.
On the other hand, reactive risk management aims to reduce the probability that an
event that has already occurred will occur again. Also, it depends on analysis of
previous accidents to prevent recurrence.
Adjustment
• By leveraging original and creative ideas to reduce risk sources, proactive risk
management adapts to changing conditions and times. Proactive risk
management also enhances the capacity of your company to handle current
concerns and avert new ones.

Reactive risk management, in contrast, is a set strategy that applies comparable tactics
to address disparate issues. It also assists you in having an efficient response when
previous problems re-occur.
Reactive risk management primarily focuses on Responding to risks after they
arise
Cost-Effective
Cost-effective proactive risk management is possible. The goal of the strategy is to
reduce the probability of the risk occurring. Anticipating a problem and addressing
it early on can help you avoid significant financial and legal consequences.
• Conversely, because the reactive strategy concentrates on fixing an issue that has
already occurred, it usually comes at a high cost. This suggests that when you use
reactive risk management, you'll experience monetary loss or a data breach.

Basis Proactive Risk
Management
Reactive Risk
Management
Methods Identifies and mitigates
problems before they arise.
Focuses on hazards after
they arise.
Duration Long-term outlook. Temporal viewpoint.
Concentrate Avoidance and reduction of
damage.
Reaction and recuperation.
Being proactive Reacts proactively to
dangers.
Actively detects and controls
hazards.
Efficiency Lessens the possibility and
effect of hazards.
Deals with hazards after
they have already
happened.
Price It may need an initial outlay
of funds, but it can ultimately
result in cost savings.
It may cost more because of
unforeseen circumstances.
Planning Places a focus on risk
assessment and planning.
Not enough thorough
planning or preparation.

SOFTWARE RISKS
SOFTWARE RISK:
The risks are the unknown incidents in the software that have a probability of occuring in the future. These
incidents are not guaranteed to take place. In case, these unknown incidents occur in the software it leads
to loss in the overall project. The detection and management of risks are very crucial steps at the time of
software project development as they determine the failure and success of the project.
Types of Software Risks
The different types of software risks are listed below −
1. Schedule Risks
They are related to the time related risks involved in the software. The incorrect schedules hamper the software
development, and delivery. They mainly denote slow progress which indicates that the project is running
behind a committed time frame and there may be a delayed software delivery. If these types of risks are
not handled properly, they lead to the project failure, and directly affect business. The schedule risks are
mainly due to the reasons listed below −
 Wrong time estimation
 Improper resource alignment
 Improper tracking of resources
 Changes in project scopes
Inappropriate requirement analysis

TYPES OF RISKS IN RISK MANAGEMENT
PROCESS
2. Technical Risks
Technological risks are related to the selection, use, and methodology of technology that shall be used in
software development. Such risks may be associated with the technology selection, the application's
intricacy, and performance issues.
Technology Changes
The software industry is highly volatile, and new solutions can often appear. Implementing modern technologies
can sometimes prove beneficial, but it is also risky. Integration problems can occur with new or developing
technology, compatibility problems with some developing technology, and training problems can occur to
accommodate some new or developing technology. When the programmer changes the current
programming language or framework mid-project, the programmer will most likely encounter new and
unfamiliar bugs and may take time to develop solutions.
Software Complexity
Software systems being used and functional means that systems become more extensive and complex, thus
increasing difficulty in designing and implementing the systems. High complexity may also render the
software tricky to comprehend, test, and alter, and defects may increase.
PERFORMANCE ISSUES IN RISK MANAGEMENT:
• Operational risks relate to the software's capacity to deliver the requisite performance characteristics,
including reaction time, quantity constitutive throughput, and scalability. Negativity impacts the users,
suboptimal and unstable system functioning, and the inability to provide necessary processing to high
loads.

TYPES OF RISKS
3. Project Management Risks
It is a circumstance within a project resulting from activities carried out about its planning, execution, and
control. When it comes to project risks, there is one thing that should be understood: these threats can
affect the schedule of the project, cause consumption of resources, and increase expenses.
Schedule Slippage
The following factors may result in extending project time horizons: new requirements, risks and problems,
and the ineffectiveness of one's management. There is always a danger that, due to such slippages, a
project may run out of time and cost more than planned, or worse, stakeholders may lose their
confidence in project managers.
Resource Shortages
Resource scarcity can be defined as the unavailability of human, financial, or other resources needed for a
given project. A lack of resources can slow down the processes within the project, combine its quality,
and put pressure on the project team members.
Budget Overruns
• Cost control issues can be summarised as a situation whereby the project's total cost is beyond the
planned or expected budget because of wrong estimation, changes in the project scope, or the
discovery of new activities that require funding. Going over the cost can put the project's financial
sustainability at risk and result in clients' or users' discontent.

TYPES OF RISKS
4. Organizational Risks
Project risks relate to the operational and organisational aspects of the venture that implements the
software project. These risks can occur because of activities such as conflicts, changes in
management, and restructurings.
Stakeholder Conflicts
Criticisms can also emanate from conflicts or differences of opinion from the various stakeholders on
goals, objectives, or specifications. These disputes may result in time extension for the specific
project, high costs, and the absence of a supposed single vision.
Management Changes
Fluctuation at the leadership or core management levels can interfere with the project's continuity and
disturb various decision-making propositions. When management changes, there is always a shift in
organisational focus and direction, objective changes, and sometimes a lack of project experience.
Organisational Restructuring
• Transforming refers to significant modifications that may occur in the formal structure, business
practices, or strategies within the company and may affect the project. A common consequence of
restructuring is resource redistribution, a shift in the scale of projects, and the possible deterioration
of working relations.

TYPES OF RISKS
5. External Risks
External risks affect the projects external to the organisation and are not easily influenced by the
project team. It may be around changes in regulations that govern the company's operations,
fluctuations in the market, and disasters such as floods, among others.
Regulatory Changes
New policies, either in Government, standards, codes of practice, or any other, may impact the
requirements or the constraints placed on the project. That requires changes in the software,
new compliance activities, and costs.
Market Fluctuations
Fluctuations in the market indices, for instance, depression or changes in the market about the
project feasibility and success rate. That is why many factors can influence the project process,
including, for example, changes in the market that can cause fluctuations in funding for a
particular project, as well as changes in its priority or the scope of work to be done.
Natural Disasters
• Project activities may be affected by Earthquakes, floods, or hurricanes. Catastrophes may
occur and affect schedules and assets, and more money may be required to restore and
maintain the business.

SOFTWARE RISKS
6. Budget Risks
They are related to the budget related risks involved whenever the budget has
surpassed. They mainly denote that the financial resources of the project
are not distributed, and managed properly. If these types of risks are not
handled properly, they lead to the project failure. The budget risks are
mainly due to the reasons listed below:
 Wrong budget estimation
 Unplanned expansion of project
 Bad management of budget
 Additional unplanned expenses
 Improper tracking of budget

SOFTWARE RISKS
7. Operational Risks
They are related to the risks involved with the methods taken up while carrying out the normal
daily activities for the development of the project. They mainly denote the incorrect
implementation of the processes. The operational risks are mainly due to the reasons listed
below −
 Inadequate count of resources
 Problems in the tasks allocation to the resources
 Mismanagement in tasks
 Inadequate planning
 Insufficient experienced and skilled resources
 Miscommunications
 Lack of cooperation and coordination
 Roles and responsibilities not properly defined
 Lack of training and guidances

SOFTWARE RISKS
8. Technical Risks
They are related to the risks involved with the functional or performance
aspects of the software. The technical risks are mainly due to the
reasons listed below −
 Changes in the requirements
 Not taking help of latest technologies
 Insufficient experienced and skilled resources
 Complex implementation
 Incorrect integration of various modules

SOFTWARE RISKS
9. Programmatic Risks
They are related to the risks involved with the external factors or unavoidable
situations. They originate from outside and out of control of the interior program
source code. The programmatic risks are mainly due to the reasons listed below −
 Changing nature of the market
 Limited available funds
 Updates in the government rules and regulations
 Contract discontinuation in middle
10. Communication Risks
• They are related to the risks originated due to lack of understanding, misses, and
confusions. They lead to insufficient or no communication during the project
development.

SOFTWARE RISKS
11. Security Risks
They are related to the risks originated due to vulnerabilities such as compromise in the reliability,
privacy, accessibility etc.
12. Quality Risks
They are related to the risks originated when the developed software is not working properly, and is
unable to satisfy the customer needs.
13. Risks Around Law and Compliances
They are related to the risks originated because of not adhering to the laws and compliances during
the project development. They lead to penalties, legal hassles, and other problems.
14. Costs Risks
They are related to the risks originated due to unanticipated expenses, updates in the scope of the
project, lack or excess of funds etc. They hamper the financial plans taken up from the start of
the project.
15. Market Risks
• They are related to the risks originated due to changes in market conditions, new technology
trends, addition of competitors, changes in customer needs etc.

RISK IDENTIFICATION
RISK IDENTIFICATION:
• Risk identification is the process of identifying and defining potential
risks that could impact the successful completion of a project, program,
or any other endeavor. This is the first step in risk management, the
purpose is systematic process of anticipating, assessing, and controlling
potential harm to an organization.

RISK IDENTIFICATION
RISK IDENTIFICATION PROCESS

RISK IDENTIFICATION
Risks can come from various sources, including internal processes, external events, human
factors, technology, and natural disasters. By identifying risks early in the project lifecycle,
organizations can take proactive steps to mitigate or avoid these risks and ensure the
project's success.
 Risk identification is identifying and defining potential risks that could impact the success of
a project.
 There are several techniques organizations can use to identify risks, including
brainstorming, root cause analysis, SWOT analysis, and expert judgment.
 The risk identification process includes defining the project scope, identifying potential
risks, assessing the likelihood and impact of each risk, and developing mitigation plans for
the most critical risks.
 The risk assessment process evaluates the impact of identified risks, whereas risk
identification focuses on the likelihood of risks occurring

The risk identification process defines the scope of a project or program. It consists of
various steps outlining the project's boundaries and requirements. Also, this
ensures that it considers and accounts for all potential risks. These stages include:
1. Identifying potential risks: In this step, the project team and stakeholders identify
potential risks that could impact the project. This includes internal factors, such as
resource shortages, and external factors, such as changes in regulations or market
conditions.
2. Assessing the likelihood and impact: Once potential risks have been identified, the
next step is to assess the likelihood and impact of each risk. The likelihood refers to
the probability of the risk occurring, while the impact refers to the potential
consequences if the risk does occur.
3. Prioritizing risks: Based on the likelihood and impact of each risk, the risks should be
prioritized so that the most critical risks can be addressed first. This ensures that the
project's limited resources go toward the most important risks.

4.Developing risk mitigation plans: For the most critical risks, the project
team should develop risk mitigation plans to minimize the potential impact
of the risks. Hence, this may include purchasing insurance, making changes
to the project schedule, or developing contingency plans.
5.Continuously monitoring and updating: Finally, the risk management plan
should be continuously monitored and updated as the project progresses.
New risks may emerge, and the likelihood and impact of existing risks may
change, so it is important to keep the risk management plan up-to-date. This
ensures the project gets protection against potential risks throughout its
lifecycle.

Techniques
There are several techniques that organizations can use to identify risks. They are the following -
#1 - Brainstorming
A group of stakeholders from different departments or disciplines identifies potential risks. It can
be an effective tool for generating creative and innovative ideas, and it can help to foster
collaboration and teamwork among project team members.
#2 - Root Cause Analysis
A systematic approach to identifying the underlying causes of risks. It involves investigating the
factors contributing to a particular risk event to identify the root cause and develop
effective risk mitigation strategies.
#3 - SWOT Analysis
SWOT Analysis represents the organization's strengths, weaknesses, opportunities, and threats.
It is a structured approach that can help to identify internal and external factors that can
affect the success of an initiative.
#4 - Expert Judgment
• Consulting with experts who have experience with similar projects or in relevant fields. The
experts can provide insights and recommendations on the technical feasibility, cost-
effectiveness, and other factors related to the project.

RISK PROJECTION
Risk projection or risk estimation is a concept that tries to determine the probability of a risk being real
and the problems that might arise if that risk occurs. Risk a dynamic entity in software engineering
often determines the success of projects and gets influenced by how skillfully it is managed.
Risk projection involves: in Estimating the probability and consequences of identified risks
Risk projection, also called risk estimation, attempts to rate each risk in two ways—the likelihood or
probability that the risk is real and the consequences of the problems associated with the risk,
should it occur.
The project planner, along with other managers and technical staff, performs four risk projection
activities:
(1) Establish a scale that reflects the perceived likelihood of a risk.
(2) Delineate the consequences of the risk.
(3) Estimate the impact of the risk on the project and the product.
• (4) Note the overall accuracy of the risk projection so that there will be no misunderstandings.

RISK PROJECTION
Developing a Risk Table
Risk table provides a project manager with a simple technique for risk projection.
Steps in Setting up Risk Table
(1) Project team begins by listing all risks in the first column of the table.
Accomplished with the help of the risk item checklists.
(2) Each risk is categorized in the second column.
(e.g. PS implies a project size risk, BU implies a business risk).
(3) The probability of occurrence of each risk is entered in the next column of the table.
The probability value for each risk can be estimated by team members individually.
• (4) Individual team members are polled in round-robin fashion until their
assessment of risk probability begins to converge.

RISK PROJECTION – RISK IMPACT
CALCULATION
Assessing Risk Impact
Nature of the risk - the problems that are likely if it occurs.
e.g. a poorly defined external interface to customer hardware (a technical risk) will
preclude early design and testing and will likely lead to system integration problems
late in a project.
Scope of a risk - combines the severity with its overall distribution (how much of the
project will be affected or how many customers are harmed?).
Timing of a risk - when and how long the impact will be felt.
Overall risk exposure, RE, determined using:
RE = P x C
P is the probability of occurrence for a risk.
• C is the the cost to the project should the risk occur.

RISK PROJECTION – RISK IMPACT CALCULATION
For example, assume that the software team defines a project risk in the following
manner:
Risk identification. Only 70 percent of the software components scheduled for reuse
will, in fact, be integrated into the application. The remaining functionality will
have to be custom developed.
Risk probability. 80% (likely).
Risk impact. 60 reusable software components were planned. If only 70 percent can
be used, 18 components would have to be developed from scratch (in addition to
other custom software that has been scheduled for development). Since the
average component is 100 LOC and local data indicate that the software
engineering cost for each LOC is $14.00, the overall cost (impact) to develop the
components would be 18 x 100 x 14 = $25,200.
•
Risk exposure. RE = 0.80 x 25,200 ~ $20,200.

RISK PROJECTION
Risk exposure can be computed for each risk in the risk table, once an estimate
of the cost of the risk is made. The total risk exposure for all risks (above
the cutoff in the risk table) can provide a means for adjusting the final cost
estimate for a project. It can also be used to predict the probable increase
in staff resources required at various points during the project schedule.
•
The risk projection and analysis techniques are applied iteratively as the
software project proceeds. The project team should revisit the risk table at
regular intervals, re-evaluating each risk to determine when new
circumstances cause its probability and impact to change. As a
consequence of this activity, it may be necessary to add new risks to the
table, remove some risks that are no longer relevant, and change the
relative positions of still others.

RISK REFINEMENT
Risk refinement is the process of taking initially broad or general risks identified during
early project planning and making them more specific and detailed as the project
progresses and more information becomes available, leading to better risk
management and mitigation.
the purpose of risk refinement is To break down complex risks into manageable
components
· A risk may be stated generally during early stages of project planning.
· With time, more is learned about the project and the risk
o may be possible to refine the risk into a set of more detailed risks
· Represent risk in condition-transition-consequence (CTC) format.
• o Stated in the following form:

RISK REFINEMENT
Given that <condition> then there is concern that (possibly) <consequence>
· Using CTC format for the reuse we can write:
Given that all reusable software components must conform to specific design standards
and that some do not conform, then there is concern that (possibly) only 70 percent of
the planned reusable modules may actually be integrated into the as-built system,
resulting in the need to custom engineer the remaining 30 percent of components.
· This general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has not been solidified and
may not conform to certain existing reusable components.
Subcondition 3. Certain reusable components have been implemented in a language that
is not supported on the target environment.

RMMM PLAN
In software engineering, "RMMM" refers to Risk Mitigation, Monitoring, and Management, a plan or process
used to identify, assess, and manage potential risks throughout a software project's lifecycle.
Here's a more detailed breakdown:
 Risk Mitigation:
This involves developing strategies and actions to reduce the impact or likelihood of identified risks.
purpose of a Risk Mitigation Plan is o develop strategies to reduce the impact of risks
 Risk Monitoring:
This involves tracking the progress of risk mitigation efforts and assessing whether the predicted risks actually
materialize.
 Risk Management:
This encompasses the overall process of identifying, analyzing, and managing risks, including developing
contingency plans and addressing issues as they arise.
 Benefits of RMMM:
Using a RMMM plan can lead to better decision-making, improved software quality, and reduced project
failures by proactively addressing potential problems.
 RMMM as a Plan:
• The RMMM plan may be a separate document or integrated into the overall software development plan.

RMMM PLAN
SEVEN PRINCIPLES OF RISK MANAGEMENT

RMMM PLAN - RIS
 Risk Information Sheet (RIS):
Some teams use Risk Information Sheets to document individual risks, their impact, likelihood,
mitigation strategies, and contingency plans, which can supplement or replace a formal
RMMM plan.

RMMM PLAN - RIS
Some teams use Risk Information Sheets to document individual risks, their impact, likelihood,
mitigation strategies, and contingency plans, which can supplement or replace a formal
RMMM plan.
1. Risk monitoring is a project tracking activity
2. Three primary objectives:
1. assess whether predicted risks do, in fact, occur
2. ensure that risk aversion steps defined for the risk are being properly applied
3. collect information that can be used for future risk analysis.
 Problems that occur during a project can be traced to more than one risk.
o Another job of risk monitoring is to attempt to allocate origin (what risk(s) caused which problems throughout
the project).
•

RMMM PLAN - RIS
Some teams use Risk Information Sheets to document individual risks, their impact,
likelihood, mitigation strategies, and contingency plans, which can supplement or
replace a formal RMMM plan.
Risk Mitigation, Monitoring, and Management
Effective strategy must consider three issues:
 risk avoidance
 risk monitoring
 risk management and contingency planning
· Proactive approach to risk - avoidance strategy.
· Develop risk mitigation plan.
· e.g. assume high staff turnover is noted as a project risk, r1.
· Based on past history
o the likelihood, l1, of high turnover is estimated to be 0.70
o the impact, x1, is projected at level 2.
• o So… high turnover will have a critical impact on project cost and schedule.

RMMM PLAN - RIS
· Develop a strategy to mitigate this risk for reducing turnover.
· Possible steps to be taken
o Meet with current staff to determine causes for turnover (e.g., poor working conditions, low
pay, competitive job market).
o Mitigate those causes that are under our control before the project starts.
o Once the project commences, assume turnover will occur and develop techniques to ensure
continuity when people leave.
o Organize project teams so that information about each development activity is widely
dispersed.
o Define documentation standards and establish mechanisms to be sure that documents are
developed in a timely manner.
o Conduct peer reviews of all work (so that more than one person is "up to speed").
o Assign a backup staff member for every critical technologist.

RMMM PLAN - RIS
· Project manager monitors for likelihood of risk
· For high staff turnover, the following factors can be monitored:
o General attitude of team members based on project pressures.
o The degree to which the team has jelled.
o Interpersonal relationships among team members.
o Potential problems with compensation and benefits.
o The availability of jobs within the company and outside it.

RMMM PLAN - RIS
Project manager should monitor the effectiveness of risk mitigation steps.
· Risk management and contingency planning assumes that mitigation
efforts have failed and that the risk has become a reality.
e.g., the project is underway and a number of people announce that they
will be leaving.
· Mitigation strategy makes sure:
§ backup is available
§ information is documented
• § knowledge has been dispersed across the team.

RMMM PLAN - RIS
· RMMM steps incur additional project cost
e.g. spending time to "backup" every critical technologist costs money.
· Large project - 30 or 40 risks.
· 80 percent of the overall project risk (i.e., 80 percent of the potential for
project failure) can be accounted for by only 20 percent of the identified
risks.
· Work performed during earlier risk analysis steps will help the planner to
determine which of the risks reside in that 20 percent (e.g., risks that lead
to the highest risk exposure).
•

SOFTWARE MAINTENANCE AND REENGINEERING
Software maintenance is widely accepted part of SDLC now a days. It stands for all
the modifications and updations done after the delivery of software product.
software maintenance is the process of modifying software after
deployment
There are number of reasons, why modifications are required, some of them are
briefly mentioned below:
• Market Conditions - Policies, which changes over the time, such as taxation
and newly introduced constraints like, how to maintain bookkeeping, may
trigger need for modification.
• Client Requirements - Over the time, customer may ask for new features or
functions in the software.
• Host Modifications - If any of the hardware and/or platform (such as operating
system) of the target host changes, software changes are needed to keep
adaptability.
• Organization Changes - If there is any business level change at client end, such
as reduction of organization strength, acquiring another company, organization
venturing into new business, need to modify in the original software may arise.

SOFTWARE MAINTENANCE AND
REENGINEERING
Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be
just a routine maintenance tasks as some bug discovered by some user or it may
be a large event in itself based on maintenance size or nature. Following are some
types of maintenance based on their characteristics:
19. Corrective Maintenance - This includes modifications and updations done in order
to correct or fix problems, which are either discovered by user or concluded by user
error reports. Corrective maintenance deals with: Fixing software bugs and
errors
• Adaptive Maintenance - This includes modifications and updations applied to keep
the software product up-to date and tuned to the ever changing world of
technology and business environment.
• Perfective Maintenance - This includes modifications and updates done in order to
keep the software usable over long period of time. It includes new features, new
user requirements for refining the software and improve its reliability and
performance.
• Preventive Maintenance - This includes modifications and updations to prevent
future problems of the software. It aims to attend problems, which are not
significant at this moment but may cause serious issues in future.

REENGINEERING
Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating
software maintenance found that the cost of maintenance is as high as
67% of the cost of entire software process cycle.

Changing a Software System
• Software maintenance and evolution of system was
first introduced by Lehman.
• One of the key observations of the studies was that large
system are never complete and continue to evolve and
as these system evolve, they become more complex
unless some actions are taken to reduce the complexity.
• Lehman stated five laws for software maintenance and
evolution of large systems.

Law Description
Law of continuing
change
A program that is used in a real-world environment
necessarily must change or become progressively less
useful in that environment.
Law of increasing
complexity
As an evolving program changes, its structure tends to
become more complex. Extra resources must be devoted to
preserving and simplifying the structure.
Law of conservation
of familiarity
For E-Systems to efficiently continue to evolve a deep
understanding of how the system functions, and why it has
been developed to function in that manner, must be
preserved at all costs.
The incremental change in each release over the life time of
the system is approximately constant.
Law of conservation
of organizational
stability
Over a program’s lifetime, its rate of development is
approximately constant and independent of the resources
devoted to system development.
Lehman Laws for software maintenance and evolution
of large systems

Lehman Laws for software maintenance and evolution of
large systems
Law Description
Law of self regulation Global E-type system evolution processes are self-
regulating, and distribution of product and process
measures close to normal.
Law of continuing
growth
E-type system’s functional capability must be continually
enhanced to maintain user satisfaction over system lifetime,
BUT expansion of the system size can have negative affects
to the ability to be comprehended along with its ability to
evolve.
Law of declining
quality
Poorly modified systems lead to introduction of defects; &
The quality of E-type systems will appear to be declining as
newer products emerge.
Law of feedback
system
To sustain continuous change or evolution, & to minimize
threats of software decay & loss of familiarity, feedback to
monitor the performance is must.
Feedback helps to collect metrics on the systems and
maintenance efforts performance.

Legacy Systems
• Were developed before the introduction of structured
programming .
• Process models and basic principles such as modularity
coupling, cohesion, good programming practice
emerged too late for them.
• Legacy system are generally associated with high
maintenance costs.
• The root cause of this expense is the degraded structure
that results from prolonged maintenance.

Characteristics Description
High maintenance
cost
Results due to combination of other system
factors, such as complexity, poor
documentation and lack of inexperienced
personnel.
Complex software Results due to structural degradation, which
must have occurred over a legacy system’s
lifetime of change.
Obsolete support
software
Support software may not be available for a
particular platform, or no longer be supported
by its original vendor or any other
organization.
Obsolete hardware Legacy system’s hardware may have been
discontinued.
Legacy System Characteristics

Characteristics Description
Lack of technical
expertise
Original developers of a legacy system are
unlikely to involved with its maintenance
today.
Business critical Many legacy system are essential for the proper
working of the organizations which operate
them.
Poorly documented Documentation is often missing or
inconsistent.
Poorly understood As a consequence of system complexity and
poor documentation, software maintainers
often understand the legacy system poorly.
Legacy System Characteristics

Software Maintenance Prediction

Software Maintenance Prediction
The various predictions shown in the figure are closely
related and specify the following:
• The decision to accept a system change depends on the
maintainability of the system components affected by
that change up to a certain extent.
• Implementing change degrades the system structure
and hence reduces its maintainability.
• Costs involved in implementing change depend on the
maintainability of system components.

Components Features
User requirements • Request for additional functionality, error
correction, capability and improvement in
maintainability.
• Request for non-programming
related support.
Organizational
Environment
• Change in business policies.
• Competition in market.
Operational
Environment
• Hardware platform.
• Software specifications.
Components of Software Maintenance Framework

Components of Software Maintenance Framework
Components Features
Maintenance Process • Capturing requirements
• Variation in programming and working
practices.
• Paradigm shift.
• Error detection and correction.
Software Product • Quality of documentation.
• Complexity of programs.
• Program Structure.
Software Maintenance
team
• Staff turnover.
• Domain expertise.

Maintenance Cost
A software product is generally very valuable to an
organization if it is used for doing a large portion of their daily
business. If for some reason the software product has become unusable,
then the organization in fact will be making losses on their revenue.
Moreover, large enterprise software products are that much crucial.
When the organization faces such a case, it is left with no alternative
but to either get an entirely different software product that will replace
the existing one or do maintenance of an existing product to make it
usable.
Software Maintenance team

Maintenance Cost
Following are some financial reasons for which a maintenance may be needed:
1. Loss in business revenue: It may happen that business transactions are faulty and thus the
business may lose revenue.
2. Opportunity loss: Sometimes there could be some business opportunity in the marketplace, but
due to some software problems it could not be availed.
3. Productivity loss: If the software product becomes difficult to operate due to many walk around
or lengthy processing then productivity will become lower for business personnel Maintenance of
an existing software product has its own share of problems. The maintenance will incur costs. A
profit/loss analysis can be done, to see if it is more profitable to conduct a maintenance program
on the software or keep using it as it is.
The losses due to problems with the software can be compared to probable cost of maintenance
and an ROI (return on investment) can be done.
If we get a desirable ROI then it is better to go for maintenance.

Factors Affecting Software Maintenance
• Relationship of Software product and
Environment
• Relationship of Software product and User
• Relationship of Software product and Software
Maintenance team

• Software Maintenance Team:
 Various functions performed by the Software Maintenance team are:
 Locating information in system documentation
 Keeping system documentation up-to-date
 Extending existing functions to accommodate new or changing
requirements
 Adding new functions to the system
 Finding the source of system failures or problems
 Managing change to the system as they are made.
• The aspects of a maintenance team that lead to high maintenance costs are:
 Staff turnover
 Domain expertise

Software Engineering and Project Management - A Beginner's Guide - Part 5

SOFTWARE MAINTENANCE LIFE CYCLE MODEL
Process of Software Maintenance:
Software Maintenance is an important phase of Software Development
Life Cycle (SDLC), and it is implemented in the system through a proper
software maintenance process, known as Software Maintenance Life
Cycle (SMLC). This life cycle consists of seven different phases, each of
which can be used in iterative manner and can be extended so that
customized items and processes can be included. These seven phases of
Software Maintenance process are:
1. Identification Phase:
In this phase, the requests for modifications in the software are
identified and analysed. Each of the requested modification is then
assessed to determine and classify the type of maintenance activity it
requires. This is either generated by the system itself, via logs or error
messages, or by the user.
2.Analysis Phase:
The feasibility and scope of each validated modification request are
determined and a plan is prepared to incorporate the changes in the
software. The input attribute comprises validated modification request,
initial estimate of resources, project documentation, and repository
information. The cost of modification and maintenance is also estimated.

3.Design Phase:
The new modules that need to be replaced or modified are designed as per the
requirements specified in the earlier stages. Test cases are developed for the new
design including the safety and security issues. These test cases are created for the
validation and verification of the system.
4.Implementation Phase:
In the implementation phase, the actual modification in the software code are
made, new features that support the specifications of the present software are
added, and the modified software is installed. The new modules are coded with the
assistance of structured design created in the design phase.
5.System Testing Phase:
Regression testing is performed on the modified system to ensure that no defect,
error or bug is left undetected. Furthermore, it validates that no new faults are
introduced in the software as a result of maintenance activity. Integration testing
is also carried out between new modules and the system.

6Acceptance Testing Phase:
Acceptance testing is performed on the fully integrated system by the
user or by the third party specified by the end user. The main objective of
this testing is to verify that all the features of the software are according
to the requirements stated in the modification request.
7.Delivery Phase:
Once the acceptance testing is successfully accomplished, the modified
system is delivered to the users. In addition to this, the user is provided
proper consisting of manuals and help files that describe the operation
of the software along with its hardware specifications. The final testing of
the system is done by the client after the system is delivered.

Software Maintenance Models:
To overcome internal as well as external problems of the
software, Software maintenance models are proposed.
These models use different approaches and techniques to
simplify the process of maintenance as well as to make is
cost effective. Software maintenance models that are of
most importance are:
1.Quikfix model
2.Iterative enhancement model
3.Reuse oriented model
4.Boehm’s model
5.Taute maintenance model

1.Quickfix model:
This is an ad hoc approach used for maintaining the
software system. The objective of this model is to identify
the problem and then fix it as quickly as possible. The
advantage is that it performs its work quickly and at a low
cost. This model is an approach to modify the software
code with little consideration for its impact on the overall
structure of the software system.
.

2.Iterative enhancement model:
Iterative enhancement model considers the changes made to the system
are iterative in nature. This model incorporates changes in the software
based on the analysis of the existing system. It assumes complete
documentation of the software is available in the beginning. Moreover, it
attempts to control complexity and tries to maintain good design.
Iterative Enhancement Model is divided into three stages:
1. Analysis of software system.
2. Classification of requested modifications.
3. Implementation of requested modifications.

3.Reuse Oriented Model:
The parts of the old/existing system that are appropriate for reuse are
identified and understood, in Reuse Oriented Model. These parts are
then go through modification and enhancement, which are done on the
basis of the specified new requirements. The final step of this model is
the integration of modified parts into the new system.

4.Boehm’s model:
This model performs maintenance process based on the economic
models and principles. It represents the maintenance process in a closed
loop cycle, wherein changes are suggested and approved first and then
are executed.

5.Taute Maintenance model:
Named after the person who proposed the model, Taute’s model is a
typical maintenance model that consists of eight phases in cycle fashion.
The process of maintenance begins by requesting the change and ends
with its operation. The phases of Taute’s Maintenance Model are:
1. Change request Phase.
2. Estimate Phase.
3. Schedule Phase.
4. Programming Phase.
5. Test Phase.
6. Documentation Phase.
7. Release Phase.
8. Operation Phase.

REENGINEERING
Real-world factors affecting Maintenance Cost
• The standard age of any software is considered up to 10 to 15 years.
• Older softwares, which were meant to work on slow machines with less
memory and storage capacity cannot keep themselves challenging
against newly coming enhanced softwares on modern hardware.
• As technology advances, it becomes costly to maintain old software.
• Most maintenance engineers are newbie and use trial and error method
to rectify problem.
• Often, changes made can easily hurt the original structure of the
software, making it hard for any subsequent changes.
• Changes are often left undocumented which may cause more conflicts in
future.

REENGINEERING
Software-end factors affecting Maintenance Cost
• Structure of Software Program
• Programming Language
• Dependence on external environment
• Staff reliability and availability

REENGINEERING
Maintenance Activities
• IEEE provides a framework for sequential maintenance process activities.
It can be used in iterative manner and can be extended so that
customized items and processes can be included.

REENGINEERING
PHASES OF MAINTENANCE ACTIVITIES:
• Identification & Tracing - It involves activities pertaining to identification of
requirement of modification or maintenance. It is generated by user or system may
itself report via logs or error messages.Here, the maintenance type is classified
also.
• Analysis - The modification is analyzed for its impact on the system including safety
and security implications. If probable impact is severe, alternative solution is looked
for. A set of required modifications is then materialized into requirement
specifications. The cost of modification/maintenance is analyzed and estimation is
concluded.
• Design - New modules, which need to be replaced or modified, are designed against
requirement specifications set in the previous stage. Test cases are created for
validation and verification.
• Implementation - The new modules are coded with the help of structured design
created in the design step.Every programmer is expected to do unit testing in
parallel.
• System Testing - Integration testing is done among newly created modules.
Integration testing is also carried out between new modules and the system. Finally
the system is tested as a whole, following regressive testing procedures.

REENGINEERING
PHASES OF MAINTENANCE ACTIVITIES CONTINUING:
• Acceptance Testing - After testing the system internally, it is tested for
acceptance with the help of users. If at this state, user complaints some
issues they are addressed or noted to address in next iteration.
• Delivery - After acceptance test, the system is deployed all over the
organization either by small update package or fresh installation of the
system. The final testing takes place at client end after the software is
delivered.
• Training facility is provided if required, in addition to the hard copy of
user manual.
• Maintenance management - Configuration management is an essential
part of system maintenance. It is aided with version control tools to
control versions, semi-version or patch management.

REENGINEERING
Software maintenance is done through three kinds of
activities.
1.Reengineering
2.Forward engineering
3.Reverse engineering

REENGINEERING
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.

REENGINEERING
RENGINEERING

REENGINEERING
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.

REENGINEERING
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing,
understanding the existing system. This process can be seen as reverse
SDLC model, i.e. we try to get higher abstraction level by analyzing lower
abstraction levels.
• An existing system is previously implemented design, about which we
know nothing. Designers then do reverse engineering by looking at the
code and try to get the design. With design in hand, they try to conclude
the specifications. Thus, going in reverse from code to system
specification.

REENGINEERING
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.

REENGINEERING
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.

REENGINEERING
Component reusability
A component is a part of software program code, which executes an independent
task in the system. It can be a small module or sub-system itself.
Example
The login procedures used on the web can be considered as components,
printing system in software can be seen as a component of the software.
Components have high cohesion of functionality and lower rate of coupling, i.e.
they work independently and can perform tasks without depending on other
modules.
In OOP, the objects are designed are very specific to their concern and have
fewer chances to be used in some other software.
In modular programming, the modules are coded to perform specific tasks which
can be used across number of other software programs.
• There is a whole new vertical, which is based on re-use of software
component, and is known as Component Based Software Engineering
(CBSE).

REENGINEERING
REUSABILITY
Re-use can be done at various levels
• Application level - Where an entire application is used as sub-system of
new software.
• Component level - Where sub-system of an application is used.
• Modules level - Where functional modules are re-used.
• Software components provide interfaces, which can be used to establish
communication among different components.

REENGINEERING
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.

REENGINEERING
• 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 Engineering and Project Management - A Beginner's Guide - Part 5

More Related Content

Similar to Software Engineering and Project Management - A Beginner's Guide - Part 5 (20)

Recently uploaded (20)

Software Engineering and Project Management - A Beginner's Guide - Part 5