Assignment 1 Software Development Life Cycles (1631 Distinction)

ASSIGNMENT 01 FRONT SHEET
Qualification

BTEC Level 5 HND Diploma in Computing

Unit number and title

Unit 09: Software Development Life Cycle

Submission date

Date Received 1st submission

Re-submission Date

Date Received 2nd submission

Student Name

Bui Quang Minh

Student ID

GCD210325

Class

GCD1104

Assessor name

Tran Trong Minh

Student declaration
I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a
false declaration is a form of malpractice.
Student’s signature
Grading grid
P1

P2

P3

P4

M1

M2

D1

D2


❒ Summative Feedback:

Grade:
Internal Verifier’s Comments:

Signature & Date:

❒ Resubmission Feedback:

Assessor Signature:

Date:


TASK 1: SDLC MODEL ............................................................................................................................................... 2
I. Describing SDLC models (P1-M1-D1)................................................................................................................ 2
1. Describing 5 SDLC models and choosing suitable one for the project (P1)................................................. 2
1.1 Waterfall ................................................................................................................................................ 2
1.2 V-model ................................................................................................................................................. 4
1.3 Prototyping ............................................................................................................................................ 5
1.4 Agile ....................................................................................................................................................... 7
1.5 Spiral .................................................................................................................................................... 10
1.6 Responsibilities of a project manager ................................................................................................. 11
1.7 How to apply a methodology .............................................................................................................. 12
1.8 Suitable model for the project ............................................................................................................ 13
2. Discussing the suitability of each of SDLC models for The Tune Source project (M1) .............................. 14
3. Discussing the merits of applying waterfall model to a large software development project (D1) ......... 15
II. Identifying risks and discussing approach to manage them (P2) .................................................................. 15
1. How risk is managed in the Spiral Lifecycle Model ................................................................................... 15
2. Risk Management ...................................................................................................................................... 16
TASK 2: FEASIBILITY STUDY.................................................................................................................................... 21
I. Purpose of feasibility study and how can it help project manager (P3) ........................................................ 21
1. Discussing the purpose of conducting a feasibility study.......................................................................... 21
2. How can feasibility report help project manager in project selection, planning and design.................... 23
II. Feasibility criteria (P4) ................................................................................................................................... 23
1. Discussing how three feasibility criteria are applied to the project.......................................................... 23

2. Two technical solutions and comparing them about feasibility ............................................................... 26
III. Components of a feasibility report (M2) ...................................................................................................... 29
IV. Accessing the impact of each feasibility criterion on a software investigation (D2) ................................... 31


TASK 1: SDLC MODEL
I. Describing SDLC models (P1-M1-D1)
1. Describing 5 SDLC models and choosing suitable one for the project (P1)
1.1 Waterfall
Definition
The Waterfall approach was established in 1970 by Winston w. Royce. It contains five phases of
management, where each requires a deliverable from the previous phase to proceed. Waterfall is
ideal for projects like software development, where the end result is clearly established before
starting, and is best suited for projects that require a lot of predictability.
Phases
There are five phases of the Waterfall methodology: Requirements, Design, Implementation,
Verification and Maintenance.
Requirements.
The Waterfall methodology depends on the belief that all project requirements can be gathered and
understood upfront. The project manager does their best to get a detailed understanding of the
project sponsor’s requirements. Written requirements, usually contained in a single document, are
used to describe each stage of the project, including the costs, assumptions, risks, dependencies,
success metrics, and timelines for completion.
Design.
Here, software developers design a technical solution to the problems set out by the product
requirements, including scenarios, layouts, and data models. First, a higher-level or logical design is
created that describes the purpose and scope of the project, the general traffic flow of each
component, and the integration points. Once this is complete, it is transformed into a physical design
using specific hardware and software technologies.
Implementation.

Once the design is complete, technical implementation starts. This might be the shortest phase of the
Waterfall process because painstaking research and design have already been done. In this phase,
programmers code applications based on project requirements and specifications, with some testing
and implementation taking place as well. If significant changes are required during this stage, this may
mean going back to the design phase.
Verification or testing.
Before a product can be released to customers, testing needs to be done to ensure the product has
no errors and all of the requirements have been completed, ensuring a good user experience with the
software. The testing team will turn to the design documents, personas, and user case scenarios
supplied by the product manager to create their test cases.


Deployment and maintenance.
Once the software has been deployed in the market or released to customers, the maintenance phase
begins. As defects are found and change requests come in from users, a team will be assigned to take
care of updates and release new versions of the software.

Figure 1. Waterfall method phases

Advantages and Disadvantages
Advantages

Dis-Advantages

Before the next phase of development, each
Error can be fixed only during the phase
phase must be completed
Suited for smaller projects where
requirements are well defined

It is not desirable for complex project where
requirement changes frequently

They should perform quality assurance test
(Verification and Validation) before
completing each stage

Testing period comes quite late in the
developmental process

Elaborate documentation is done at every
phase of the software’s development cycle

Documentation occupies a lot of time of
developers and testers

Project is completely dependent on project
team with minimum client intervention

Clients valuable feedback cannot be included
with ongoing development phase

Small changes or errors that arise in the
Any changes in software are made during the
completed software may cause a lot of
process of the development
problems


1.2 V-model

Definition
The V-model is a type of SDLC model where process executes in a sequential manner in V-shape. It is
also known as Verification and Validation model. It is based on the association of a testing phase for
each corresponding development stage. Development of each step directly associated with the
testing phase. The next phase starts only after completion of the previous phase i.e. for each
development activity, there is a testing activity corresponding to it.
The V-Model is a software development life cycle (SDLC) model that provides a systematic and visual
representation of the software development process. It is based on the idea of a “V” shape, with the
two legs of the “V” representing the progression of the software development process from
requirements gathering and analysis to design, implementation, testing, and maintenance.
Phases
Requirements Gathering and Analysis: The first phase of the V-Model is the requirements gathering
and analysis phase, where the customer’s requirements for the software are gathered and analyzed
to determine the scope of the project.
Design: In the design phase, the software architecture and design are developed, including the highlevel design and detailed design.
Implementation: In the implementation phase, the software is actually built based on the design.
Testing: In the testing phase, the software is tested to ensure that it meets the customer’s
requirements and is of high quality.
Deployment: In the deployment phase, the software is deployed and put into use.
Maintenance: In the maintenance phase, the software is maintained to ensure that it continues to
meet the customer’s needs and expectations.
The V-Model is often used in safety-critical systems, such as aerospace and defense systems, because
of its emphasis on thorough testing and its ability to clearly define the steps involved in the software
development process.

Figure 2. V-model method phases


Advantages and Disadvantages
Advantages:











This is a highly disciplined model and Phases are completed one at a time.
V-Model is used for small projects where project requirements are clear.
Simple and easy to understand and use.
This model focuses on verification and validation activities early in the life cycle thereby
enhancing the probability of building an error-free and good quality product.
It enables project management to track progress accurately.
Clear and Structured Process: The V-Model provides a clear and structured process for
software development, making it easier to understand and follow.
Emphasis on Testing: The V-Model places a strong emphasis on testing, which helps to ensure
the quality and reliability of the software.
Improved Traceability: The V-Model provides a clear link between the requirements and the
final product, making it easier to trace and manage changes to the software.
Better Communication: The clear structure of the V-Model helps to improve communication
between the customer and the development team.

Disadvantages:










High risk and uncertainty.
It is not a good for complex and object-oriented projects.
It is not suitable for projects where requirements are not clear and contains high risk of
changing.
This model does not support iteration of phases.
It does not easily handle concurrent events.
Inflexibility: The V-Model is a linear and sequential model, which can make it difficult to adapt
to changing requirements or unexpected events.
Time-Consuming: The V-Model can be time-consuming, as it requires a lot of documentation
and testing.
Overreliance on Documentation: The V-Model places a strong emphasis on documentation,
which can lead to an overreliance on documentation at the expense of actual development
work.

1.3 Prototyping
Definition
The prototyping model is a systems development method in which a prototype is built, tested and
then reworked as necessary until an acceptable outcome is achieved from which the complete system
or product can be developed. This model works best in scenarios where not all of the project
requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes
place between the developers and the users.


Phases
Step-1: Requirements gathering and analysis :

Requirement analysis is the first step in developing a prototyping model. During this phase, the
system’s desires are precisely defined. During the method, system users are interviewed to determine
what they expect from the system.
Step-2: Quick design :
The second phase could consist of a preliminary design or a quick design. During this stage, the
system’s basic design is formed. However, it is not a complete design. It provides the user with a quick
overview of the system. The rapid design aids in the development of the prototype.
Step-3: Build a Prototype :
During this stage, an actual prototype is intended to support the knowledge gained from quick design.
It is a small low-level working model of the desired system.
Step-4: Initial user evaluation :
The proposed system is presented to the client for preliminary testing at this stage. It is beneficial to
investigate the performance model’s strengths and weaknesses. Customer feedback and suggestions
are gathered and forwarded to the developer.
Step-5: Refining prototype :
If the user is dissatisfied with the current model, you may want to improve the type that responds to
user feedback and suggestions. When the user is satisfied with the upgraded model, a final system
based on the approved final type is created.
Step-6: Implement Product and Maintain :
The final system was fully tested and distributed to production after it was developed to support the
original version. To reduce downtime and prevent major failures, the programmer is run on a regular
basis.

Figure 3. Prototyping method phases


Advantages and Disadvantages
Advantages








Customers get a say in the product early on, increasing customer satisfaction.
Missing functionality and errors are detected easily.
Prototypes can be reused in future, more complicated projects.
It emphasizes team communication and flexible design practices.
Users have a better understanding of how the product works.
Quicker customer feedback provides a better idea of customer needs.

Disadvantages
The main disadvantage of this methodology is that it is more costly in terms of time and money when
compared to alternative development methods, such as the spiral or Waterfall model. Since in most
cases the prototype is discarded, some companies may not see the value in taking this approach.
Additionally, inviting customer feedback so early on in the development lifecycle may cause
problems. One problem is that there may be an excessive amount of change requests that may be
hard to accommodate. Another issue could arise if after seeing the prototype, the customer demands
a quicker final release or becomes uninterested in the product.
1.4 Agile
Definition
The Agile methodology is a way to manage a project by breaking it up into several phases. It involves
constant collaboration with stakeholders and continuous improvement at every stage. Once the work
begins, team cycle through a process of planning, executing, and evaluating. Continuous collaboration
is vital, both with team members and project stakeholders.
Phases
Concept
At the onset of the Agile development life cycle, stakeholders and product owners join forces to
outline the project’s scope and priorities. They scrutinize costs, projected completion time, desired

features, and requirements to determine the project’s feasibility.
Inception
The inception phase is the second of six Agile development life cycle stages. During this phase, the
founder selects the appropriate team members, assigns roles, and provides the necessary tools to
begin development.
Before beginning the development phase, it is essential to establish a plan and define the core set of
methods and templates for future development activities. This planning stage, known as the inception
phase, consists of two parts.


UI/UX design, where designers create a mock-up of the user interface and experience,
thoroughly analyzing their competitors’ strengths and weaknesses.




Product architecture, where the dedicated team discusses the most suitable tools to meet
business requirements, including frameworks, containers, programming languages, etc.

At the end of this phase, the team and software structure is established, allowing you to move to the
next stage.
Iteration
This phase typically lasts the longest and involves close cooperation between developers and UI/UX
designers to ensure that all business needs and feedback are incorporated into the code. During this
phase, the team works on the product backlog, completed through development sprints.
The iteration (or development) stage is fundamental to the agile approach, allowing the team to build
a product with minimal features, with additional functionality added later. Once the development
stage is complete, it’s time to conduct quality assurance activities, create technical documentation,
and end the iteration.
Testing

After testing the digital product at the end of every sprint, the final testing phase is conducted to
ensure the software operates flawlessly. The Agile life cycle incorporates various types of testing,
including:





Unit Testing: At this stage, the QA team separately evaluates each front-end and back-end
component’s performance and functionality.
Integration Testing: This phase merges different product parts to verify their compatibility.
Acceptance Testing: Upon completing this phase, quality assurance specialists assess the
digital solution’s adherence to end-user requirements.
System Testing: The entire system is evaluated to ensure all components function properly.
The QA team approves the next deployment phase if the tests are successful

The designated team conducts all these procedures to assess the code’s quality and the product’s
ability to fulfill business objectives. After successfully passing all testing stages, it is time to release the
product. By the way, if you’re seeking top-notch quality assurance services delivered by industry
experts, don’t hesitate to contact us!
Release
In this phase, the primary objective is to deliver a dependable and efficient product that meets
customers’ requirements. It is accomplished by conducting quality assurance testing to ensure the
product is error-free and functions flawlessly upon release.
Once all the final testing and verification are completed, the product is prepared for launch. To help
users become acquainted with the software, development teams frequently offer training on using it
efficiently. When the dedicated team ends all the activities, they pass to the final phase.
Review
Once an Agile software development project reaches this stage, the focus shifts from striving for a
triumphant launch to sustaining long-term triumph. The product has been released successfully, and

customers frequently provide feedback, request new features, or interact with recent updates.


The development and operations teams and stakeholders are now tasked with providing continuous
support for the application to ensure it operates effortlessly.

Figure 4. Agile method phases

Advantages and Disadvantages
Advantages









Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.


Disadvantages






Less predictable.
More time and commitment.
Greater demands on developers and clients.
Lack of necessary documentation.
Projects easily fall off track.

1.5 Spiral
Definition
Spiral Model is a risk-driven software development process model. It is a combination of waterfall
model and iterative model. Spiral Model helps to adopt software development elements of multiple
process models for the software project based on unique risk patterns ensuring efficient development
process.
Phases
Identification
This phase starts with gathering the business requirements in the baseline spiral. In the subsequent
spirals as the product matures, identification of system requirements, subsystem requirements and
unit requirements are all done in this phase.
This phase also includes understanding the system requirements by continuous communication

between the customer and the system analyst. At the end of the spiral, the product is deployed in the
identified market.
Design
The Design phase starts with the conceptual design in the baseline spiral and involves architectural
design, logical design of modules, physical product design and the final design in the subsequent
spirals.
Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In the
baseline spiral, when the product is just thought of and the design is being developed a POC (Proof of
Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working
model of the software called build is produced with a version number. These builds are sent to the
customer for feedback.
Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management
risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration,
the customer evaluates the software and provides feedback.


Figure 5. Spiral method phases

Advantages and Disadvantage
The advantages






Changing requirements can be accommodated.

Allows extensive use of prototypes.
Requirements can be captured more accurately.
Users see the system early.
Development can be divided into smaller parts and the risky parts can be developed earlier
which helps in better risk management.

The disadvantages







Management is more complex.
End of the project may not be known early.
Not suitable for small or low risk projects and could be expensive for small projects.
Process is complex
Spiral may go on indefinitely.
Large number of intermediate stages requires excessive documentation.

1.6 Responsibilities of a project manager
Project managers have the responsibility of the planning, pitching, managing, executing, and
monitoring a project’s life cycle and quality.


Responsibilities of a project manager include:
Phase 1: Initiation



Identifying the stakeholders that work around the project. (such as the clients, himself, the
team that takes over the project, the managing director, etc.)
Formulating a project charter (that includes the objectives, the methodology, etc)

Phase 2: Planning











Developing a project management plan for the team lead.
Detailing the scope of the project, gathering the requirements of the project from the clients,
creating a work breakdown structure (WBS).
Scheduling every activity of the project.
Determining the budget and filing an estimated cost of the project.
Discussing the quality requirements with the client and team.
Identifying the suitable team for the project.
Choosing the mode of communication and hierarchical structure of the team for the project.
Conducting a risk analysis and informing the team & the clients.
Participating in the procurement process of the project.
Conducting an orientation session with the stakeholders and the project team.

Phase 3: Execution of the project






Communicating the changes from the clients to the team.
Assisting the team to communicate the technical difficulties with the management.
Assessing the performance of the team that handles the project.
Managing the stakeholders’ expectations.

Phase 4: Monitoring the functions of the project





Asking the team to make changes if necessary.
Communicating the project update to the clients.
Monitoring whether the steps of the project are moving chronologically and properly.
Managing the costs and budget of each task.

Phase 5: Closing the project




Last-minute updates and getting clients’ approval on the project.
Handing over the project to the clients.
Communicating the project’s success to the team.

1.7 How to apply a methodology
Applying a methodology in project management involves following a structured approach to planning,
executing, and controlling projects. Here are general steps to help you apply a methodology
effectively:


1. Select a Project Management Methodology: Research and choose a methodology that aligns
with your project's requirements, organization's culture, and industry best practices. Common
methodologies include Waterfall, Agile, Scrum, Kanban, PRINCE2, and PMBOK (Project
Management Body of Knowledge).
2. Understand the Methodology: Familiarize yourself with the chosen methodology's principles,
concepts, and processes. Read the methodology guide, attend training sessions, or seek
guidance from experienced project managers.
3. Tailor the Methodology: Adapt the methodology to fit your project's specific needs. Identify
the project's unique characteristics, stakeholders, constraints, and requirements, and modify
the methodology accordingly.
4. Define Project Objectives: Clearly define the project objectives, deliverables, scope, and
success criteria. This step provides a foundation for planning and ensures everyone involved
has a shared understanding of the project's goals.
5. Plan the Project: Develop a comprehensive project plan that outlines the tasks, resources,
timelines, and dependencies. Break the project into manageable phases or iterations,
depending on the methodology. Include risk management, quality assurance, and
communication plans.
6. Assign Roles and Responsibilities: Identify the project team members and assign roles and
responsibilities. Clearly communicate expectations and ensure everyone understands their
contributions to the project's success.
7. Execute the Project: Implement the project plan by executing the tasks, monitoring progress,
and managing resources. Follow the methodology's processes and guidelines for project
execution. Regularly track and document progress, making necessary adjustments along the
way.

8. Monitor and Control: Continuously monitor the project's progress, compare it against the
plan, and control any deviations. Use key performance indicators (KPIs) and metrics relevant
to the methodology to assess project performance. Conduct regular status meetings, manage
risks, and address issues promptly.
9. Communicate and Collaborate: Maintain open and effective communication with
stakeholders, team members, and project sponsors. Foster collaboration and provide regular
updates on project status, milestones, and any changes.
10. Evaluate and Learn: Once the project is complete, conduct a post-project evaluation. Assess
the project's outcomes, identify lessons learned, and document best practices. This knowledge
can be used to improve future projects and enhance the chosen methodology.
1.8 Suitable model for the project
After thinking throuhly about the project and discussing with employees in team so that I would
choose WATERFALL MODEL for my project "English Center" because the following criterias





The requirements are well understood and not likely to change.
The customer is not prone to demanding changes.
The customer prefers not to be involved in the development but wants to be consulted at the
beginning and receive a working package at the end of the project.
The project is small.


2. Discussing the suitability of each of SDLC models for The Tune Source project (M1)
The Tune Source project, led by entrepreneurs John Margolis, Megan Taylor, and Phil Cooper, aims to
leverage their expertise in the music industry to provide a wide range of hard-to-find and classic audio
recordings. With successful brick-and-mortar stores in southern California and an established website,
Tune Source has become a leading destination for music enthusiasts. To further enhance its online

platform and meet evolving customer demands, the company is embarking on a development project.
In this analysis, I will evaluate different Software Development Life Cycle (SDLC) models, including
Waterfall, V-Model, Agile, and Spiral, to determine the most suitable approach for the Tune Source
project, considering its characteristics and industry dynamics.
Waterfall model:
The Waterfall model follows a sequential approach with distinct stages, where each stage is
completed before moving on to the next. This model may not be the most suitable choice for the
Tune Source project because:


The music industry is dynamic and requirements can change or evolve as market trends and
customer preferences change. The waterfall model does not handle changes well after the
completion of a phase, which can hinder the project's ability to adapt to evolving needs.

V-Model:
The V-Model is an extension of the Waterfall Model that emphasizes testing at each phase of
development. However, similar to the Waterfall Model, it may not be the most suitable choice for the
Tune Source project due to the following reasons:



The need for flexibility and adaptability to accommodate changing requirements and market
trends may not be adequately addressed by the V-Model.
The V-Model's focus on testing may not align with the project's need for iterative customer
feedback and continuous improvement.

Agile Model:
The Agile Model, particularly Scrum, is an iterative and incremental approach that involves dividing
the project into small sprints and incorporating regular feedback from stakeholders. The Agile Model
could be a good fit for the Tune Source project due to the following reasons:




The dynamic nature of the music industry requires the project to be adaptable and responsive
to changing customer preferences and market trends.
Agile methodologies allow for flexibility, iterative development, and collaboration with
stakeholders, which can help Tune Source meet evolving customer needs.

Spiral Model:
The Spiral Model combines elements of the Waterfall Model and prototyping, focusing on risk analysis
and iterative development. The Spiral Model may be suitable for the Tune Source project due to the
following reasons:


The project involves a moderate level of complexity, and the Spiral Model allows for risk
analysis and gradual enhancements through iterative cycles.




The Spiral Model's iterative nature accommodates flexibility, feedback, and continuous
improvement, which align with the project's requirements.

Based on the provided information, both the Agile Model and Spiral
Model seem suitable for the Tune Source project.
3. Discussing the merits of applying waterfall model to a large software development
project (D1)
There are a number of potential advantages but it’s important to understand that a pure Waterfall
approach will only work if there is a relatively low level of uncertainty and the requirements for the
project can be defined with some level of confidence prior to the start of the project.

That being said, some of the potential advantages are:
 Architecture can be planned, defined, and stabilized in advance
 Work can be planned, structured, and organized more easily among a large team of people
 Regulatory requirements can be more easily met with requirements traceability
 The costs and schedule of the project might be more predictable
 There is a mechanism for providing control of the project at designated phase transition points
Despite these merits, it's important to note that the Waterfall model has limitations, especially in the
context of large and complex software development projects. It assumes that requirements are wellunderstood and unlikely to change significantly, which is not always the case in dynamic
environments. The model's sequential nature can make it difficult to accommodate changes, leading
to potential delays and cost overruns if requirements evolve during the project. Additionally, the lack
of early and continuous customer feedback may result in a product that does not fully meet user
needs and expectations.

II. Identifying risks and discussing approach to manage them (P2)
1. How risk is managed in the Spiral Lifecycle Model
 Risk management is at the heart of the spiral lifecycle software development model designed here,
which sets it apart from other software development methodologies. It is an integral part of every
iteration or phase of the project, making it a proactive approach rather than a reactive one.
 Risk Identification: This is the spiral model’s initial phase of risk management. In each iteration, the
first step is to identify potential risks. These could be operational, technical, or external.
 Operational risks could include potential team changes or miscommunications. Technical risks
could involve technology malfunctions or the use of untested technology. External risks could
arise from changes in market conditions or regulatory laws.
 Risk Analysis: After identifying potential risks, the next step is to analyze them. This analysis includes
determining the likelihood of each risk occurring and the potential impact on the project if it does
occur. Risks are typically categorized as high, medium, or low priority based on these factors. This
prioritization helps guide the team’s focus on the most significant risks.


 Risk Evaluation: Once the risks have been analyzed, they are evaluated to decide which risks to

address in the current iteration of the spiral. The risks are evaluated based on their priority and the
project’s current phase. Sometimes, addressing certain risks in later spirals may be more efficient.
 Risk Mitigation: After evaluation, the next step is to devise strategies to mitigate the identified risks.
This could involve taking preventive measures to reduce the likelihood of the risk occurring, creating
contingency plans to handle the risk if it does occur, or accepting the risk if it cannot be avoided or if
the cost of mitigation exceeds the potential impact.
 Risk Monitoring: Even after implementing a risk mitigation strategy, it is vital to monitor the risk
continuously. This is because the likelihood and impact of risks can change over time as the project
progresses. Monitoring involves keeping an eye on the risk factors and adjusting the mitigation
strategy if necessary.
 Risk Communication: Throughout all these steps, it is essential to maintain clear and consistent
communication about risks. All project stakeholders should be kept informed about the identified
risks of small projects, their potential impact, and the strategies for managing them.

Figure 6. Risk management illustration

2. Risk Management
Risk Management Process
The risk management process is a framework for the actions that need to be taken. There are five
basic steps that are taken to manage risk; these steps are referred to as the risk management
process. It begins with identifying risks, goes on to analyze risks, then the risk is prioritized, a
solution is implemented, and finally, the risk is monitored. In manual systems, each step involves a
lot of documentation and administration.


The Five Essential Steps of A Risk Management Process
1.
2.
3.
4.

5.

Identify the Risk
Analyze the Risk
Evaluate or Rank the Risk
Treat the Risk
Monitor and Review the Risk

Figure 7. Risk management process
Step 1: Identify the Risk
The initial step in the risk management process is to identify the risks that the business is exposed to in its
operating environment.
There are many different types of risks:





Legal risks
Environmental risks
Market risks
Regulatory risks etc.

It is important to identify as many of these risk factors as possible. In a manual environment, these risks are
noted down manually. If the organization has a risk management solution employed all this information is
inserted directly into the system.


Step 2: Analyze the Risk
Once a risk has been identified it needs to be analyzed. The scope of the risk must be determined. It is also

important to understand the link between the risk and different factors within the organization. To
determine the severity and seriousness of the risk it is necessary to see how many business functions the
risk affects. There are risks that can bring the whole business to a standstill if actualized, while there are
risks that will only be minor inconveniences in the analysis.
In a manual risk management environment, this analysis must be done manually.When a risk management
solution is implemented one of the most important basic steps is to map risks to different documents,
policies, procedures, and business processes. This means that the system will already have a mapped risk
management framework that will evaluate risks and let you know the far-reaching effects of each risk.
Step 3: Evaluate the Risk or Risk Assessment
Risks need to be ranked and prioritized. Most risk management solutions have different categories of risks,
depending on the severity of the risk. A risk that may cause some inconvenience is rated lowly, risks that
can result in catastrophic loss are rated the highest. It is important to rank risks because it allows the
organization to gain a holistic view of the risk exposure of the whole organization. The business may be
vulnerable to several low-level risks, but it may not require upper management intervention. On the other
hand, just one of the highest-rated risks is enough to require immediate intervention.
Step 4: Treat the Risk
Every risk needs to be eliminated or contained as much as possible. This is done by connecting with the
experts of the field to which the risk belongs. In a manual environment, this entails contacting each and
every stakeholder and then setting up meetings so everyone can talk and discuss the issues. The problem is
that the discussion is broken into many different email threads, across different documents and
spreadsheets, and many different phone calls. In a risk management solution, all the relevant stakeholders
can be sent notifications from within the system. The discussion regarding the risk and its possible solution
can take place from within the system. Upper management can also keep a close eye on the solutions
being suggested and the progress being made within the system. Instead of everyone contacting each
other to get updates, everyone can get updates directly from within the risk management solution.
Step 5: Monitor and Review the Risk
Not all risks can be eliminated – some risks are always present. Market risks and environmental risks are
just two examples of risks that always need to be monitored. Under manual systems monitoring happens
through diligent employees. These professionals must make sure that they keep a close watch on all risk
factors. Under a digital environment, the risk management system monitors the entire risk framework of

the organization. If any factor or risk changes, it is immediately visible to everyone. Computers are also
much better at continuously monitoring risks than people. Monitoring risks also allows your business to
ensure continuity.