RISK MANAGEMENT IN SOFTWARE PROJECT TO BE DEVELOPED IN

PRIVATE COMPANY

SUMMARY

Currently, software development companies face an element

critical in the software product development process, what are the risks that
they are presented at each phase of development, these must be the subject
of proper management which must be initiated by the management, supervised and
controlled by each of the heads of the important areas involved in the
software development. Risk management in software projects is an activity
expressed in multiple methodologies, but in practice, they are applied in a particular way
depending on the business logic of each organization.

This article highlights risk management for software development.

for a private entity based on the PMBOK guide, where a
identification of the most important risks in each phase of development,
Similarly, a qualitative analysis is conducted, through which one finds the
probability of occurrence and the impact of each of the identified risks,
subsequently, a classification is made by the level of risk, for later
propose a response plan for the most critical risks. This management must comply
with adequate control and monitoring, which will allow for a
identification of new risks or updating of existing response plans,
in order to anticipate the possible negative risks that may arise
materialize during software development.

Palabras clave:Requerimiento, Riesgo, Gestión de Riesgos, PMBOK, Impacto,

Probability, software development, phase.
 ABSTRACT

Currently, software development companies are facing a critical element in their development.
process of software products, which are the risks that arise at the level of each of the
stages of development, they should be subject to appropriate management which must
be initiative by manager, supervised and controlled by each of the heads of the major
areas involved in software development. Risk management in software projects is an
activity expressed in multiple methodologies, but in practice are applied in a particular
way depending on the business logic of each organization.

In this article, risk management for the development of software for a private entity
based on the PMBOK Guide, where the identification of the most important risks is
done is evident in each of the phases of development, just as it is done a qualitative
analysis, through which the likelihood and impact of each risk has been identified, then
a classification by risk level, later to propose a plan to respond to the most critical risks.
This management should comply with adequate control and monitoring, which will allow
to carry out an identification of new risks or update existing mitigation plans, in order to
anticipate possible negative risks that may materialize during development
software.

Keywords:Requirement, Risk, risk management, PMBOK, Impact, Probability,

software development, phase.

INTRODUCTION

The financial entity of the case study [1] has an accreditation of more than
45 years, during which he has been characterized by his loyalty, compliance with his
clients and the effectiveness of their operations. Initially local operations, and in the
current affairs with its 24/7 service, with the help of the technological platform that
it allows the execution of operations at the electronic level, supported by a great team
of human and technological talent makes the entity one of the best at the level
national.

All the technological structures that support the entity with its operations
banking services not only provide greater effectiveness and coverage, but also bring
I achieve different risks that can significantly affect the processes, due to
this reason shows the need to carry out an appropriate management of risks in the
phases of analysis, design, coding, testing, and delivery of the software and power
propose mitigation strategies for them in order to ensure each one of
these stages.

According to the PMBOK, the risk of a project is an uncertain event or condition that, if
to occur, has a positive or negative effect on one or more of the objectives of
project, such as the scope, the schedule, the cost, and the quality. A risk can
to have one or more causes and, if materialized, one or more impacts. A cause can
be a specified or potential requirement, an assumption, a restriction, or a condition
which creates the possibility of both negative and positive consequences. Therefore
It is of vital importance to carry out an adequate risk management process where it begins in
the first phase of the project, to carry out proper monitoring and controls of these
in each of the phases of software development, up to the acceptance of the product
of the project.

For risk management, the PMBOK guide has been used as a reference.
defining a risk management methodology which establishes the Identification,
evaluation, risk response plan, monitoring and control, sequential and
iterative. Which will ensure the effectiveness of the risk management plan on the
project in question, for this reason for the software development project
seeks to identify the possible risks that may arise, similarly
categorize them highlighting their likelihood of occurrence and impact on the project
finally propose some risk mitigation strategies in case of reaching
materialize. [2] With the above, it is ensured that the project development meets
with adequate planning, in which the possible risks can be anticipated
they can cause alterations in the normal course of this.

The development of software today is of great importance in the part

the country's financial system, due to the growth of electronic transactions, generated by
the evolution of technology and systems, this generates a series of developments of
software that meets these needs, but it is worrisome that in the
Software development projects currently do not have the culture of being
prevented from carrying out an adequate risk management despite knowing that a risk
It is a big problem wherever it happened. The company specifically for this
the project does not have a risk management system, hence a
necessity in this topic, which is of great importance in the development of the project for
help the software team understand and manage uncertainty.

Considering that for this project the absence of management is evident

of risks, the following general objective called 'Risk Management' was established
software project to be developed in a private company, thus making it
the project reduces vulnerability to events or conditions that affect the outcome
of the same.

With the existing risks today in each of the developed projects at

At the software level, the need to develop methods that allow us to
identify the probability of occurrence and impact of an atypical event, facilitating the
control of them in the event that they occur at different stages of
development. With the use of a risk matrix, the impacts can be observed.
that these cause at the moment of materializing, at the level of the phases of
software development, allowing the results obtained to make decisions and
implement the necessary mitigation measures to counteract negative impacts
that these can generate.
 3. MATERIALS AND METHODS

The research conducted is exploratory in nature considering that although the

The importance of managing risks in software projects is well known.
In general form, it is not at a more specific level, oriented towards the phases of the life cycle.
for software development; for this reason, the sources of information worked are
'Secondary Sources' which are the searches on the Internet of virtual databases,
repository Military University Nueva Granada (UMNG), publications, reference of
books, articles in which risk management in development can be evidenced
of IT projects by detecting common traits, suggestions, and guides for their
management that can be considered as experience and best practices for
the adaptation to the project of the private company, 'SourceExperience and Knowledge'
which knowledge and experience are obtained from some processes of the phases of
software project development, this due to active participation in various
projects in both banking and telecommunications, supported in the phase of
analysis, functional testing, and technical testing. The methodology to be used for the
the development of this article is based on the description of the five phases of development
of software, in which an adequate management of risks will be carried out.

3.1DESCRIPCION DE LAS FASES DEL DESARROLLO DE SOFTWARE

3.1.1 ANALYSIS PHASE

This phase is the first and is of the utmost importance, as it is the foundation for continuing.
with the other phases of software development. The objective of this phase is the
description of the purpose of the system, where the client, requirements engineer and
users identify the problem and then define it through natural language
a system that solves the problem without generating ambiguities. In this phase
After the art study was conducted, the capture processes were defined.
requirements, analysis and negotiation of requirements, specification of
requirements, requirements validation and requirements documentation.

Figure 1. Processes of the Analysis Phase

[Link] Requirements Capture: It is the process through which the requirements are obtained or
they capture the functional and non-functional requirements where the former does
reference to the interactions between the user and the system, the latter deals with
the restrictions or attributes of the system such as response time and accuracy. It is given
I start with the extraction of data for the client and end users of the system using
of efficient and safe techniques such as introspection, questionnaire interviews,
open-ended interviews and discussions, etc.

[Link] Analysis and Negotiation of Requirements: In the requirements analysis

problems in the capture of requirements are discovered, the need for is evaluated
all requirements are analyzed for consistency and completeness, feasibility is ensured
regarding the technical aspect, costs, and planning. Next, we move on to the
negotiation of requirements where inconsistencies and limitations are discussed,
shortcomings found and finally reach a mutual agreement that satisfies everyone
the users in order to prioritize requirements.

[Link] Requirements Specification: It is the process by which

describe in draft form the requirements as they are subject to modifications.

[Link] Requirement Validation: The validation is carried out by a comprehensive team that
it can be made up of requirements engineer, developer, client, and
users in order to detect and correct errors, ambiguities, or omissions for
ensure the consistency and accuracy of the requirements. It is also evaluated that
the agreed requirements are the ones that truly define the system that the client
needs and wants to see as the final product.

[Link] Requirements Documentation: The official documentation is carried out

each of the agreed requirements, clearly, in detail, and verifiable.

3.1.2 DESIGN PHASE

The design of an information system produces the elements that establish how
the system will meet the requirements identified during the analysis phase. To this
This phase is also known as Logical Design.
The first step in system design is to identify the reports and outputs that the
system will produce; below are the specific data for each of these
they indicate, including their exact visualization on paper, the display screen
or any other means.

The design also describes the data calculated and/or stored in the database.
The data and the calculation procedures are described in detail. The... (incomplete sentence)
file structures and storage devices, such as disks or
magnetic tapes or paper. The procedures must show how they will be processed
the data and what the outputs will be. The documents that contain the
design specifications can be represented through diagrams, tables, and
special symbols. The last step of the design is to pass the design document to
development group to start the software coding phase. Therefore
After conducting the respective analysis of the phase, the design processes are proposed.
["data","Architectural Design","Procedural Design","User Interface Design"]
Preliminary Design Document, Detailed Design Document as it can be
observe in the following figure. [7].
 Figure 2. Design Phase Processes.

[Link] Data Design: The requirements document is taken and defined.

aspects, such as the types of data required to achieve functionality
correct for the entire application, likewise, these data can be records, files or
databases. Similarly, it is necessary to define those people or entities that
they will be involved, just like the relationships that can arise between
these depending on the type of processes or operations that the application must fulfill.
It is of utmost importance to define the rules that must be followed in order to establish the
criteria on how processes should be carried out to strictly execute them
what is desired.

Data design involves fully defining the processes and characteristics.

from the application data, this can be a process where it is refined from
the essential like the data required by the application up to the processes in which
they intervene, with a good data design it can be guaranteed that access to the
Application data will be handled efficiently, and it will be able to be maintained, just like
can accept improvements to the data that need to be made later. In this
the process identifies the data, the definition of the type of this data, and the mechanisms
of adequate storage, company rules and mechanisms are also defined
of requirements that guarantee the integrity of the data [8].

[Link] Architectural Design: This defines the relationship between the main
structural elements of software. Design patterns that may arise, and
that help meet the requirements that have been defined for the system. And the
different constraints that may affect the application of design patterns
architectural. It is the process that identifies all existing subsystems and
establishes a framework for the control and communication among all these subsystems,
the main components of the system and the communications that
there can be among these. There are advantages with the architectural design that can
facilitate this process, the communication with the users, this facilitates the discussion among
different users involved, another is the system analysis, which allows having
control over the critical system requirements, performance, reliability, and
maintainability and finally large-scale reuse, this given that the
The system architecture is often the same for systems with requirements
similar ones, and this allows for large-scale reuse to be carried out, to
Sometimes it is possible to develop architectures that can be used in multiple systems.
[8].

[Link] Procedural Design: This transforms the structural elements into a

procedural description of the software. It is the specification using tools
modeling (Star UML, Vsparading) such as algorithms, flowcharts, of the
internal functioning of each of the modules that make up the system, defined
in the Architectural subprocess and the relationships or operations that must be carried out
within the final application, this allows the developer to have a broader view
detailed description of the development procedure that must be carried out, these diagrams and
defined algorithms will become a functional part of the application as they contain
the primary and secondary components, the relationships and operations that must be
perform among them to meet each of the client's requirements [9].

[Link] Interface Design: This defines each of the interfaces that will be
use to allow the interaction of the application itself, there are various aspects
aspects such as navigation, usability,
colors, help, access control, texts, among others. Taking into account the
From previous aspects, we can guarantee that the interface design will meet the
need for which it is created, since this will ultimately be the one used by the
client as a mechanism to interact and operate the different components that
they come immersed in the final application [10].

[Link] Preliminary Design Document: It focuses on the transformation of the

requirements of the analysis phase, in data and the architecture specific to development
of the software.

[Link] Detailed Design Documents: It deals with the refinement and of the
architectural representation that leads to a refined data structure and to the
representations through flow diagrams of the software.

3.1.3 CODING PHASE

After completing the design phase, the coding phase begins, which in the
engineering language is known as programming, algorithms are taken and are
they lead to a specific programming language, this language is chosen
depending on its usefulness and the need for the application whether it is adaptable or not to it
required by the programmer. After conducting an analysis of the theoretical basis of this
This phase proceeds to propose the subprocesses of coding, debugging the code,
unit tests, component tests, integration tests, document
technical as seen in the following figure.
 Figure 3. Processes of the Coding Phase

[Link] Encoding: This process consists of the subprocesses of 'Source Code'

the first step in coding and consists of lines of text, which are instructions
that must be followed to execute the program, 'Object Code' is the result of
carrying out the compilation of the source code, "Executable Code" is what we
it allows knowing that the compilation was successful, and checks that there are no issues in the program
management errors, in this way if no errors are found it is said that the
the program works correctly, as it is free of variable, sign and errors
Others, 'Compiler Code' is the software program that allows translating the code.
source code of a high-level programming language (Language close to how one thinks)
human), to a low-level language (Machine language), in this way the
The compiler reports possible errors found in the source code.
"Machine" is that which comes from the compilation task carried out directly on
the source code, with which the (Bytecode) is later obtained, which is the
integration of different files that are part of executables so that the
computer can make use of the previously programmed code [11].

[Link] Debugging the Code: It is the process of identifying the root of an error and
correct it, debugging represents 50% of the development time of a program,
Most errors and failures are typographical, which can be detected.
easily, with the help of code observation or with the help of the debugger.

[Link] Unit Tests: These are also called white box tests, or
modular tests since they allow us to determine if a module of the program
it is ready and properly finished, for these tests one must take into account the
size of the modules and preferably separate them according to their functionality. The
the goal of unit tests is the isolation of parts of code and to demonstrate that
these do not contain errors. The benefits of these tests are simplification of the
integración, Refactorización del código, Documentación, y Diseño.

[Link] Component Testing: This involves testing components.

individually, this helps to find internal defects within it.
Through a test case, the functionality of that component must be tested.
this way the good execution of the component is confirmed, in the same way with
these tests determine the resistance that it has to invalid data inputs.
[Link] Integration Tests: Also called interface tests check
the integration between the different components after the integration of all the
modules or components that make up the system.

[Link] Technical Document: The document generally describes the

execution of each process that has been coded, likewise it should describe the
functionality and operability of each component. The packages are also specified.
that intervene if any deployment, specification, and interaction must be carried out
database, specify how each of the data should be entered for the
execution of the components or of the application, specify and demonstrate the correct
use of each of the interfaces used, and the correct navigation and execution
of each of the processes that are executed within the application by the
user [11].

[Link] PHASE

In this phase, a dynamic verification of the encoding behavior is carried out.

of the software against the expected behavior according to the defined requirements
in the analysis phase document, using a set of cases of
tests, selected appropriately according to the different scenarios that are
They can present for each specific validation of the software that they want to test.

The tests are mainly focused on the evaluation or assessment of the

Quality of software products, allowing to find and document defects
existing, Suggest improvements based on perceived quality, Validate that the requirements are met
correctly and completely implemented [5,6]. Based on the study conducted in the phase
The subprocesses were deduced, which contribute to the efficient execution of tests.
of the software, to subsequently certify the development of the software, which
they observe in the following figure.

Figure 4. Testing Phase Processes

[Link] Planning: It is defined as a preparation and planning in which

contextualizes the testing group about the application or software to be tested, it is established
el entorno de pruebas, se disponen de los procedimientos y los criterios a aplicar en
the tests, the appropriate testing strategy is also selected. The planning
testing is of utmost importance in the testing phase as it is the foundation for the
subsequent processes of the same phase, therefore it must be clear the Types
Pruebas, Numero de Ciclos de pruebas, Recursos Físicos, Recursos humanos,
Calendario de pruebas, Restricciones/Limitaciones, Dependencias.

[Link] Design: Identify and describe the identified test cases and scenarios
in the requirements received from the client, which will be executed later
in the execution phase. Additionally, it allows for the identification of the dataset that will be used.
to run the tests, create new necessary test cases that are
detected during the course of the project and control the coverage of the requirements
data.

[Link] Execution: Carry out the execution of all the test cases that were
designed in the Design phase and achieve the proposed objectives in the phase of
Planning, through the proper management of identified incidents, the
maintenance of traceability of executed test cases and tracking
and control of the status of the tests.

[Link] Evaluation: Determine if the completeness criteria defined for a

requirements have been satisfactorily completed and evaluate the results generated. There
It also aims to establish the quality of the developed product and the process.
same. To this end, a final report is prepared with a balance of the project,
providing an assessment of compliance with the planned activities and of the
overall quality of the project and the product obtained. Generating deliverables
the summary of tests, certification letter, and the lessons learned document.

3.1.5 DELIVERY PHASE

In this phase, the different activities are carried out to make available to the
users the developed application, the preparation of the infrastructure is carried out
necessary to configure the environment, the installation of the components, the activation
of the manual and automatic associated procedures, and when necessary the
migration or initial data loading. In addition to this, training must be fulfilled.
to the end users, it must ensure the correct implementation, and the
correction of the errors that occur at the time of integration with
the client environment. Where the signature of the delivery record must finally be obtained
por parte del cliente. [12] En esta fase se entrega la última versión del proyecto probada
and approved; with the analysis carried out on the documentary base, it is proposed to suggest the
most important subprocesses as reflected in the following figure.
 Figure 5. Processes of the Implementation Phase

[Link] Hardware Installation and Software Deployment: In this section, we proceed to

carry out the installation of all the technological elements that will allow for installation and
run the project application, which must meet minimum requirements that are
they determined in the project testing phase, with this it is guaranteed that one possesses
the hardware structure on which the software will be well segmented
it will be required to ensure the functionality of the software product.

3.1.5.2Customization: The application must be adapted to the requirements.

of the end user, in this the parameters set in the software are adjusted to the
particularities that the client needs.

3.1.5.3Capacitación a Usuarios Finales:En esta fase se realiza un plan de

training for end users, where both knowledge of the
información que controlara la aplicación, como la forma de operación de la misma, con
this is fulfilled with an essential requirement. Training is provided to the
application administrators, as well as end users, the goal is not to create
difficulties or erroneous results with the execution of the application.

[Link] Pilot Test: It is one that is carried out in a live environment of the client.
where its operation is observed and the errors that become evident are removed
correcting on the go of this test this is essential since it is the prelude
to the final delivery of the project to the client.

[Link] Stabilization: In this process, each of the

features contained in the project, where tests called are conducted
beta tests, with these you can observe their operation as they are executed
correcting the errors, this is done until all have been incorporated
features, with this the aim is to have a stable product
operationally.
[Link] Startup of the Complete Application: In this, the application is
in operation directly in the client's environment, in this it is finally
where the customer acceptance is obtained and the product delivery report is signed
of the software [13].

3.2 RISK MANAGEMENT IN THE PHASES OF SOFTWARE DEVELOPMENT

IN THE PRIVATE COMPANY

Risks according to PMBOOK are defined as the probability of an event occurring.

whether positive or negative, if it is positive it is considered an opportunity
and if it is negative it represents a threat, which may affect the execution of the project
whether in the scope, time, cost, and quality of the product or service.

The Types of Risks are 'Known Risks' that refer to those that have
have been identified and analyzed, which allows for planning the response plan to these.
and they should be assigned a reserve for contingencies, the 'Unknown Risks'
they refer to the risks that are unknown and a reserve can be assigned to them
management. It is also important to keep in mind that there is a 'Probability of
Occurrence that refers to the measure to estimate the possibility of it happening
an incident or event.

3.2.1 Relationship of Risk with the phases of software development

The risks are reflected from the beginning of the project, for this reason it is necessary to carry out the
management in the project planning process group. Likewise this
management must be applied to each phase of software development, which
will ensure the reduction of risks present in them, avoiding over
Costs and delays in the project. The above is represented in the following figure.

Figure 6. Relationship of Risk with the phases of Software Development

3.2.2 Risk Management

Risk management can be defined as the systematic process of identification,

analysis, response to risks, and control and monitoring, this applied to each of
the phases of software development in the private company case study [1]. Its
The main objective is to minimize the probability and consequences of events.
negatives.

For the risk management of the private company software development project
The following methodology will be used with the processes of identification and analysis.
qualitative, response plan and control and monitoring of risks, which
established based on the PMBOK guide.

Figure 7. Risk Management.

[Link] Identification

The project's documentation and information about projects was used as a basis.
similar ones in which participation has taken place, as well as the sources of information
secondary school. A list of possible risks that can materialize was made.
Each of the phases of software development involved a root cause analysis.
associated with each of the risks identified in each of the phases.

[Link] Qualitative Analysis

In this process, the list of identified and analyzed risks is taken as input.
in each of the phases. The probability table with five levels is used, this gives us
locate the risk at a level of occurrence, which are rare, unlikely, possible,
probable, almost certain, as shown in the following figure.
 Table 1. Levels of Probability
LEVEL DESCRIPTOR DESCRIPTION

1 Rare The event can only occur in

exceptional circumstances.
The event can occur in
2 Improbable at some point.
The event could occur at some
3 Possible moment.
The event probably
4 Probable it will happen in most of the
circumstances.
It is expected that at the event

5 Almost sure it happens in most of the

circumstances.
Source. Based on the PMBOK guide

To measure the level of impact caused by the risks at the time of occurrence
materialize, which can directly affect the project's objectives, such as
scope, time, cost, and quality. To establish this measure, the table is used.
of impacts where five levels are specified: insignificant, minor, moderate,
major, catastrophic. These are shown in the following figure.

Table 2. Levels of Impact.

LEVEL DESCRIPTOR DESCRIPCION
If the fact were to reach
introducing oneself, I would have
1 Insignificant consequences or effects
minimums.
If the fact were to
to introduce oneself, I would have low
2 Minor
impact.
If the fact were to happen
3 Moderate introducing oneself, would have medium
impact.
If the fact were to
4 Mayor introducing oneself, would be high
impact
If the fact were to
5 Catastrophic to introduce oneself, I would have

disastrous consequences.
Source. Based on the PMBOK guide

To qualify each of the identified risks, the probability matrix is created.

the impact, in this it reflects the multiplication of the numerical value of the level of
probability of occurrence of the risk by the numerical level of the impact of the risk on
the objectives, this outcome is what determines the level of risk.
 Table 3. Probability and Impact.
IMPACT
PROBABILITY
{"1":"Insignificant","2":"Minor","3":"Moderate","4":"Major","5":"Catastrophic"}

Rare (1)
Improbable (2)

Possible (3)

Probable (4)
Almost certain (5)

Source. Based on the PMBOK guide

Based on the results of the probability and impact matrix, a scale is proposed.
numeric which allows classifying the risk according to its level, these can be very low,
low, medium, high, and very high.

Table 4. Risk Level.

LEVEL OF PROBABILITY X
RISK IMPACT
Very High >80
High 51-80
Half 31-50
Under 11 - 30
Very Low <10
Source. Based on the PMBOK guide

[Link] Response Plan

The risks are prioritized according to their risk level Very High and High for
propose the contingency plan for each of the prioritized risks, making
use of strategies for threats which are to avoid, transfer, mitigate and
accept.

[Link] Control and Monitoring

For each of the risks that are addressed, a ...

responsible for supervising the correct execution of the contingency plan of
risks, just as this must assess whether there is a need to reconsider the risks.
existing ones or if new risks should be identified, an assessment must also be carried out.
periodic review (every two months) to validate the status and/or impact on each
one of the phases of software development.

4. RESULTS AND DISCUSSIONS

A detailed analysis was carried out for each of the phases of software development.
how each phase works in order to later draw on experience and support
from secondary information sources, the most significant risks were listed
significant and that in reality can occur, taking into account various factors
such as the business logic, the commitment from the client, the
requirements, quality in designing, coding, and testing, knowledge and
experience on the part of the staff, management of tools and methodologies among
others, which provided the basis to propose the list of risks for each phase and
subsequently apply step by step the respective proposed risk management and
explained in numeral 3.2.2, the above results in the matrix of
risk assessment for each of the phases of software development, with a
list of 43 risks that were identified for each of the phases of development
of software, where the risk levels that were reported were Very High, High, Medium
and with greater relevance for the first three respectively.

For the analysis phase, seven risks were identified with a very high risk level one,
High one and Medium five, in the design phase six risks were identified with level of
very high risk one, high two and medium three, in the coding phase were identified
once risks with a risk level Very high one, High three, Medium six, and low one, in the
In the testing phase, ten risks were identified with a risk level of Very High two, High
two, halfway five and low one, in the product delivery phase nine were identified
riesgos con nivel de riesgo Muy Alto uno, Medio seis y bajo dos, ver tabla 5.

After having the risk assessment matrix, thirteen risks were prioritized in total.
for all phases with a Very High and High level to carry out the respective plan of
Response. For the Analysis phase, risks with a Very High level R- were selected.
001 and High R-002, in the design phase, risks with a Very high level were selected.
011, Alto R-012 and R-013, in the Coding phase the risks were selected with
level Very High R-020, High R-017, R-018 and R-019, in the testing phase it was selected
the risks with Very High level R-025, R-026, High R-027 and R-028, in the Delivery phase
The product risk R-019 was selected with a Very High level.

It is clear that in reality, a response plan must be created for all risks.
identified and evaluated regardless of their level of risk, in this work due to effects
the plan for responding to previously identified risks will only be carried out by academics
mentioned. For each of the risks, an analysis was carried out to deduce which of
response plan strategies such as avoiding, transferring, mitigating, and accepting for
threat-type risks proposed by the PMBOK guide applied to them, where as
the result gave for each of the risks the type of response plan is Mitigate already
this allows for the implementation of early actions to reduce the likelihood of
occurrence of a risk and/or its impact on the project. To propose strategies
The mitigation for each risk was based on knowledge and experience.
acquired by participating in most phases of software development and equally
way with the support of the study conducted for each of the phases, see table 6.
 Table 5. RISK EVALUATION MATRIX FOR EACH PHASE OF SOFTWARE DEVELOPMENT

ANALYSIS
CODE OBJECTIVE ESTIMATION PROBABILITY LEVEL ESTIMATION
DESCRIPTION OF PHASE CAUSE DELIVERABLES
DEL PROBABILITY O IMPACT AD DE
RISK RISK AFFECTED ROOT AFFECTED AD AFFECTED X IMPACT RISK
O
Incomplete requirements or Analysis The requirements were not defined Requirements document. Scope 4 20
ambiguous. clear and complete manner. Time 5 25
R-001 5 Cost 5 25 Very High
Quality 4 20
Total Probability x 90
Impact
Lack of support for Analysis Users who do not collaborate or do not Requirements document. Scope 5 20
the users in the they are understood with the definition
Time 4 16
raising of of the requirements
R-002 4 Cost 5 20 High
requirements.
Quality 4 16
Total Probability x 72
Impact
Delays in the specification Analysis The meetings with the client for the Requirements document. Scope 3 9
of requirements. requirements gathering is Time 4 12
they postpone.
R-003 3 Cost 4 12 Medium
The specifications of the interfaces
essentials are not on time. Quality 3 9
Total Probability x 42
Impact
Continuous incorporation of Analysis The client does not have clarity about what Requirements document. Scope 4 12
new requirements. wish. New need on the part of the Time 4 12
market, of the government or of the business.
R-004 3 Cost 4 12 Medium
Quality 3 9
Total Probability x 45
Impact
Continuous modification of Analysis Update necessary due to a Requirements document. Scope 3 12
requirements. inadequate definition of requirements Time 3 12
initially.
R-005 4 Cost 3 12 Medium
Quality 3 12
Total Probability x 48
Impact
Incorrect modifications Analysis Incorrect update of the Documento de requerimientos. Scope 4 12
of the specifications requirements due to the absence of a Time 4 12
detailed preliminary study.
R-006 3 Cost 4 12 Half
Quality 4 12
Total Probability x 48
Impact
Misunderstanding of Analysis The requirements engineer Requirements document. Scope 4 12
the requirements understand and document in a way Time 4 12
wrong the needs
R-007 3 Cost 4 12 Medium
exposed by the client.
Quality 4 12
Total Probability x 48
Impact

Source. Template adapted based on the Source[Link]

DESIGN
Incorrect definition and Design Poor definition of data types and Detailed Design Document. Scope 3 9
data structuring integrity, and little understanding about the Time 3 9
established. relationship or dependence on them
R-008 3 Cost 3 9 Middle
Quality 3 9
Total Probability x Impact 36
Incomplete interface design Design Lack of knowledge of all the interfaces Detailed Design Document. Scope 4 12
what can affect the solution Time 4 12
R-009 3 Cost 4 12 Medium
Quality 3 9
Total Probability x Impact 45
Underestimation of the size of the Design When designing, it is underestimated Detailed Design Document. Scope 4 12
application. software regarding the needs Time 4 12
of the client.
R-010 3 Cost 5 15 Medium
Quality 3 9
Total Probability x Impact 48
Lack of Specification of the Design It is not properly defined the Detailed Design Document Scope 4 20
logical architecture interconnections and logical resources between
Time 5 25
system modules in such a way
R-011 5 Cost 5 25 Very High
suitable for its detailed design and
administration. Quality 4 20
Total Probability x Impact 90
Lack of Specification of the Design The Detailed Design Document set is not correctly defined. Scope 4 12
physical architecture of physical devices that will be used Time 4 12
for the logical architecture to work
R-012 3 Cost 5 15 High
correctly.
Quality 4 12
Total Probability x Impact 51
Ignorance of logic Design Bad interpretation and/or interpretation Detailed Design Document Scope 5 15
of business superficial of the requirements to do the Time 4 12
detailed system design
R-013 3 Cost 5 15 High
Quality 4 12
Total Probability x Impact 54

CODING
Low performance of the Coding The CASE tools that are used Software implementation. Scope 3 9
CASE tool as support they do not have the performance and the
Time 4 12
expected functionalities
R-014 3 Cost 3 9 Medium
Quality 4 12
Total Probability x Impact 42
Inadequate management in Coding Incomplete deployment of version of the Software implementation. Scope 3 9
release of versions application, The non-deployment of the last Time 4 12
the version of the application, Deployment of
Cost 4 12
version with incorrect addressing
R-015 3 Quality 3 9 Medium
to databases.

42
Total Probability x Impact
 Lack of documentation in Encoding Time limitation. Software implementation. Scope 2 6
source code Application of bad practices of Time 3 9
development and lack of reviews
R-016 3 Cost 2 6 Under
Quality 3 9
Total Probability x Impact 30
Schedule modification Encoding Activities not included. Software implementation. Scope 3 12
activities Addition of new activities. Time 4 16
Complexity of development
R-017 4 Cost 4 16 High
unestimated activities.
Delays in the execution of activities Quality 3 12
for indirect unforeseen events.
Total Probability x Impact 56
No hardware availability Encoding The essential hardware and/or software is not Software implementation. Scope 5 20
and/or software. delivered on time. Time 5 20
R-018 4 Cost 4 16 High
Quality 4 16
Total Probability x Impact 72
The software is complex to Encoding The development of the application has a Software implementation. Scope 4 16
implement high level of complexity. Time 4 16
The system modeling carried out in the
R-019 the design phase was not very clear and 4 Cost 4 16 High
specific. Quality 4 16
Total Probability x Impact 64
Complex integration of Encoding When coding and starting the integration Software implementation. Scope 4 20
software modules it becomes evident that the specification Time 5 25
is incomplete or contains requirements
R-020 contradictory or there are shortcomings in 5 Cost 5 25 Very High
the software design. Quality 4 20
Total Probability x Impact 90
Withdrawal of staff with Being the only people in charge Scope 3 12
knowledge and experience Encoding certain specific and/or complex topics Software implementation. Time 3 12
they cause delays in the course of
R-021 4 Cost 3 12 Average
the
tasks. Quality 3 12
Total Probability x Impact 48
There is no good communication The communication between the staff of Scope 4 12
and/or synergy in the team. Coding the development area is not the most optimal and Software implementation.
Time 4 12
Likewise, its synergy is not the best.
R-022 3 Cost 4 12 Medium
effective for achieving objectives
in common. Quality 4 12
Total Probability x Impact 48
Lack of knowledge and The staff is not suitable or does not have the Scope 4 12
Experience about the tasks Encoding necessary expertise for the assigned role. Software implementation. Time 4 12
assigned and the
R-023 3 Cost 4 12 Medium
tools to be used.
Quality 4 12
Total Probability x Impact 48
Loss of backups Loss of the backup of the Scope 3 9
Coding current software version caused by Software implementation. Time 4 12
virus or by version replacement without removal
R-024 3 Cost 4 12 Medium
the previous copy.
Quality 3 9
Total Probability x Impact 42
TESTS
Scope of tests No Tests The quality assurance was not defined from the beginning of the phase. Scope 4 20
completely defined. scope due to the fact that it was not available software. Time 5 25
the documentation or what existed was very
R-025 5 Cost 5 25 Very High
superficial or was outdated
Quality 5 25
Total Probability x 95
Impact
Documentation of Tests The test cases are not covered Quality assurance of Scope 5 25
requirements insufficient, in its entirety, due to the fact that they can software. Time 5 25
outdated, to exist
R-026 5 Cost 5 25 Very High
contradictory or ambiguous. changes and/or improvements that are not
they are updated as of the date. Quality 5 25
Total Probability x 100
Impact
Conduct tests in the Testing environment High instability of the environment Quality assurance of Scope 4 16
development Proven functionalities but software. Time 4 16
not 100% certified.
R-027 4 Cost 5 20 High
Quality 5 20
Total Probability x 72
Impact
Completeness is not achieved in Tests The set of tests performed are not Quality Assurance of the Scope 4 16
the tests. enough to guarantee the quality of the software. Time 4 16
this happens by default and/or
R-028 4 Cost 4 16 High
due to lack of time.
Quality 4 16
Total Probability x 64
Impact
No prioritization is carried out in Tests It is not prioritized to test the ... Quality assurance of Scope 4 12
the execution of the tests most important features and software. Time 4 12
complex software
Cost 4 12
R-029 In the end, defects are discovered. 3 Medium
blockers which need time Quality 4 12
to be
48
resolved. Total Probability x
Impact
Excessive delays in the Tests Defect solutions not prioritized by Quality assurance of Scope 3 9
repair of defects part of the developers which software. Time 4 12
found in the tests delay the tests.
R-030 3 Cost 4 12 Medium
Quality 3 9
Total Probability x 42
Impact
Availability issues Tests Problems with the preparation, Quality assurance of Scope 4 12
with the test environment. adaptation and stabilization of the environment software. Time 4 12
where is
R-031 3 Cost 4 12 Medium
they carry out the tests, affecting
schedules and delaying the start of Quality 4 12
each cycle. Total Probability x 48
Impact
Testing delay due to Tests Rework caused by deployments Quality assurance of the Scope 4 12
new errors after which damage functionalities already software. Time 4 12
deployments successful, thus generating new
R-032 3 Cost 4 12 Medium
defects.
Quality 4 12
Total Probability x 48
Impact
Poor Productivity Dead times in initial subphases of Scope 2 6
Tests the testing phase that cannot be Quality assurance of Time 3 9
recover for late software deliveries.
R-033 3 Cost 2 6 Under
development.
Quality 2 6
Total Probability x 27
Impact
There are not enough resources Late entry of personnel to the roles Scope 4 12
they enter too late Tests in need. Quality assurance of Time 4 12
Reduced staff where needed software.
R-034 3 Cost 4 12 Medium
more than those assigned.
Quality 4 12
Total Probabilidad x 48
Impact
DELIVERY OF THE PRODUCT
Superficial training to Entrega del Producto. Due to limitation or underestimation of Deployment of the software. Scope 4 12
end users training is carried out Time 4 12
incomplete
R-035 3 Cost 4 12 Medium
about the use of the application.
Quality 4 12
Total Probability x Impact 48
The application does not process Product Delivery. The capacity at the hardware level is not Software production deployment. Scope 4 12
transactions per second according to the number of transactions
Time 4 12
as expected. requested.
R-036 3 Cost 4 12 Medium
The coding of the procedure of the
transaction is inefficient in the Quality 4 12
response time. 48
Total Probability x Impact
Hardware failures limit the Product Delivery. Network instability and/or Software deployment. Scope 4 12
functionality of the software Internet. Outage or impact due to Time 4 12
server virus.
R-037 3 Cost 4 12 Medium
Quality 4 12
Total Probability x Impact 48
Inadequate architecture for Product Delivery. Especificacion superficial de los requisitos Puesta en produccion del software. Scope 4 12
client part basics for hardware architecture and Time 4 12
software.
R-038 3 Cost 4 12 Medium
Modification of the architecture
regarding the defined Quality 4 12
initially. Total Probability x Impact 48
Documentation on usage Product Delivery. Poor generation of Production deployment of the software. Scope 2 6
from the application. necessary documents for the Time 3 9
installation and effective use of the
R-039 3 Cost 2 6 Bajo
application.
Quality 3 9
Total Probability x Impact 30
Software vulnerabilities Product Delivery. Omission of validations in the phase of Production rollout of the software. Scope 3 9
presented in production. tests. Time 3 9
Production environment what is it like
Cost 5 15
R-040 real environment can present 3 Medium
defects that did not occur in the Quality 5 15
semireal testing environment.
48
Total Probability x Impact
Staff resistance for Product Delivery. The staff that will use the new Software production deployment. Scope 2 6
change the practices of software is afraid of change due to Time 3 9
past to the
R-041 3 Cost 2 6 Under
habit of using the previous software.
Quality 2 6
Total Probability x Impact 27
Software contains Product Delivery. The client, in the eagerness to leavea Software production deployment. Scope 3 9
numerous errors when production takes the risk of going out with Time 3 9
delivered to the customer. defects
R-042 3 Costo 5 15 Medium
existing in the application that not yet
they have been resolved by the Quality 5 15
development team. Total Probability x Impact 48
Presentation of defects in Product Delivery. Finding defects that are not Software deployment. Scope 4 20
production environment. they were previously detected or that they do not
Time 4 20
they presented in the environment of
R-043 5 Cost 5 25 Very High
tests.
Quality 5 25
Total Probability x Impact 90
Table 6. RISK MITIGATION MATRIX FOR EACH PHASE OF SOFTWARE DEVELOPMENT

[Link] template based on the Source: h[Link]

 - Revise the development leader's part
infrastructure.
- Creating the physical architecture design considering
Tell us about the architecture that the client has.
- Use models, views, and diagrams for the design of the
physical architecture.
Training on the business logic
designers.
Threat Lack of understanding of the logic Leader in Design
- Facilitation of documentation on the Iâqicadel
R-013 Design High Mitigate business negotiations.
of systems
- Meetings for clarifying doubts on topics
punctual.
Assign staff for the anniversary event with experience.
Threat The module is relatively small for
minimize the impact of making a change, corruption of
error in redesign.
Modular independence, makes it easier to maneuver.
Complex integration of cooification VeryHigh
At the leader I want to work with them. AI to develop a new
R-D2O Mitigate
software modules Development It is essential to know the details without errors.
others
Perform programming in teams and develop modules
in parallel.
Perform component testing.
You will receive these design documents on time.
Threat Receive contextualization and support from the team
discussed.
Modification schedule Leader Have a clear understanding of the application development process.
R-017 i a i AltO Mitigate
activities Development Make a good planning of resources, tasks
times to avoid possible delays.
Include in the planning a reasonable time just in case
unexpected events happen directly.

Define in the software development plan the

requirements for both physical equipment and tools
They are necessary for the application coding.
No hardware availability Lfder de "Manage on behalf of the development team with
R-018 song High Mitigate
Threat I am on vacation. Development the resources HW and SW in order to be executed
the planned tasks.
Having an alternative plan prevents some from failing.
software resources v/o soRvrare.
Support for the development team from an expert
on the subject.
Software is complex. Leaders of the Use a software development model according to
R-019 Threat implement
action AltO Mitigate
Development
the size of the application, times, documentation, etc.
Support among the members of the group.
Perform software reuse.
Perform unit tests.
Evitar,Mitigar,Transfarir,Aceptar.
 CONCLUSIONS

It is important to clearly and specifically understand each of the phases of

software development, as the risks must be identified from these
important to them.

The identification of risks is of utmost importance as it will allow

focus on the risks that may materialize in each phase
of software development.

When defining the level of the probability of occurrence and the level of impact of the
risks, it will allow to determine the level of risk and thus focus with a greater degree of
attention to those at critical levels.

An adequate determination of the risk level must be made for each one.
of the risks to propose the response plan that best fits the risk.

The proposal for risk response plans is of vital importance that

ensure proper control and monitoring over these.

The risk matrix helps guide the risk manager in making and
apply the best mitigation plan to the risk in question.

It is necessary to have personnel who handle the topic of treatment, control and
monitoring of the risks presented in the different phases of development
of the software project.

Clear, updated, and effective response plans must be in place, which

allow control and proper management of risks to reduce the
probability and/or impact of occurrence.

The risk management system must be implemented to have control.

and monitoring of the risks found, analyzed and mitigated in each
one of the phases of software development.

Currently, there are no books specifically on risk management in the

phases of software development.
 BIBLIOGRAPHIC REFERENCES

For confidentiality reasons, the name of the company in question is reserved.

analysis and reference will be made to a Financial Entity.
Project Management Institute, I. (2013). GUIDE TO THE FUNDAMENTALS FOR
THE PROJECT MANAGEMENT (PMBOK Guide). United States of America.
Fifth Edition.
[3] Roger S. Pressman. Ingeniería del Software. Mc Graw Hill. 155-173p.
María del Carmen Gómez Fuentes. (2011). Requirements Analysis. Mexico
D.F. Metropolitan Autonomous University. 3-11p.
Ian Sommerville. (2005). Software Engineering. Madrid (Spain). Pearson
Education, Inc.
International Software Quality Institute. (2005). ISTQB Certified Tester Foundation
Level. Germany. CHOUCAIR.
[7] Alejandro Peña Ayala. (2006). Ingeniería de Software. México. Instituto Politécnico
National. 67-80p
Roger S. Pressman. Software Engineering. Mc Graw Hill 201-207p
9 Gustavo Marcelo Torossi. (2005). Design of Systems In:
[Link]
(12/10/2015)
[10] Willian J. Giraldo, Cesar A. Collazos, Faber D. Giraldo (2009). Development Based
in User Interface Models of Systems. In:
[Link] (12/10/2015
José M, Drake, Patricia López. (2009). Programming Engineering. In:
[Link]
[Link] (11/10/2015)
University Institution of Envigado. (2008). Project Management. In:
[Link] (10/10/2015)
Barrios Judith. (2010). Conceptualization of the Implementation Process
Software. En:
[Link]
(12/10/2015)
Software Testing Help (2015). How to Manage Risks During Test Planning Phase
Risk Based [Link]://[Link]/risk-management-during-
test-planning-risk-based-testing/
Sebastián Uchitel (2007). Requirements [Link]://www-
[Link]/materias/isoft1/teoricas_2009_1/01-Introduction_IR_BN.pdf
Identification of Software Project Risks Based On
Taxonomies. Master's Thesis in Software Engineering (2005). University of
ITBA Postgraduate. Page 460.
Del Rio J. L. Risk Management Assistance System in Projects
Software for Industrial Automation and Control Systems. Master's Thesis in
Software Engineering (2006). ITBA Graduate School. Page 361.
Ledo N, Palacios D. Expert System for Risk Identification in the
Software Development (2007). University of Buenos Aires, Faculty of Engineering.
Page 156.