Ingeniería de software II

Edison Barrero

Christian Gahona

Ronald Antonio Zea Duarte

Septiembre 2019

Presentado a:

Angel Alberto Varón Quimbayo

Programa:

Ingeniería en sistemas – virtual

Fundación universitaria del Areandina.

2019
 Introducción

En este documento abarcamos algunos objetivos de la gestión de riesgos que a su vez nos

permiten identificar, controlar y eliminar la fuente de riesgo antes de que empiecen a afectar el

cumplimento de los objetivos del proyecto. Todo esto enfocado e un análisis en la gestión de

riesgos, que por medio de unos pasos ayuda al equipo a comprender y manejar la incertidumbre

de posibles fallos que pueden ocurrir en el proceso del proyecto.

Un riesgo es un problema potencial que puede ocurrir o no.

1. Análisis.

1.1. Que el contenido de la planeación y propuesta no sea realmente definido por el equipo, sino

Que solo escriba lo que el cliente les dicta.

Un proyecto consta de múltiples fases las cuales intervienen directa o indirectamente

obligándonos desde el principio a identificar la manera correcta en que debemos organizar cada

una de las actividades involucradas y su nivel de importancia.

La correcta planificación nos ayuda a establecer la prioridad de cada una de las actividades y a

tener un mejor control del tiempo para ejecutar un proyecto con la calidad deseada y con éxito.

Entonces, cuando hablamos de planificar podemos decir que se trata del conjunto de acciones

para establecer cada una de las actividades a realizar con el fin de lograr los objetivos planteados,
para mitigar el riesgo de que la planeación del proyecto no lo logré ser efectuado por fallas en la

estrategia planteada se deben dialogar las ideas con él equipo de profesionales, cliente y usuario

final manejando de manera conjunta las ideas principales para no comprometer al equipo a

realizar cambios improvisados que podrían perjudicar el desarrollo del software implicando

sobrecostos.

1.1. Hacer cronogramas muy optimistas.

En algunos casos la definición del alcance (no cumple con lo solicitado por el usuario), no

cumple con el tiempo establecido (esto a su vez impacta sobre el costo del desarrollo el cual se

eleva), en el aplicativo existen incongruencias que luego pasa a un estado de mantenimiento

constante, el equipo de desarrollo no trabaja como debe de ser, se realizan modificaciones que no

son informadas a todos los interesados y provoco molestias, existen factores internos y/o

externos que provocan demora y no son tomados en cuenta, y la adquisición de productos y/o

servicios adicionales debe de seguir un seguimiento.

Este es uno de los mayores inconveniente o riesgos al desarrollar un software, la estimación de

los tiempos por cada fase, se deben definir los cronogramas de acuerdo a las definiciones de

alcance del mismo, mayor disponibilidad de tiempo para que en ello se logre la revisión y

mantenimiento de fallas, logrando obtener la calidad que se le promete al cliente. Se debe llegar

a un mutuo acuerdo con el cliente sobre los tiempos de desarrollo y entrega, dando claridad sobre

cada fase del mismo.

1.3. Poca retroalimentación del usuario final.

Para mitigar este riesgo es necesario que se logre tener una comunicación clara y fluida con el

usuario final a fin de que se le pueda dar a conocer su evaluación el software y se logre conocer

interfaces y mecánicas.
Para ello recomienda realizar conclusiones específicas cuya finalidad sea la realización de

acciones que permitan darnos una perspectiva del usuario.

Refiriéndose a las características de una retroalimentación eficaz, se recomienda que sea

oportuna, esto es proporcionada tan pronto como sea posible; equilibrada, es decir, que incluya

refuerzos positivos y sugerencias de cómo mejorar específica y dando ejemplos objetivos.

1.4. Usuarios finales que insisten en nuevos requerimientos a lo largo de todo el proyecto.

Cabe la posibilidad de que el usuario solicite cambios con nuevos requerimientos a lo largo del

proyecto identificando falencias o simplemente hechos que se olvidaron al momento de recopilar

la información de funcionalidad y alcance del desarrollo, se debe mitigar este riesgo definiendo

los requerimientos con claridad de la mano del usuario final ya que si hay cambios en medio del

desarrollo conllevarían un sobrecosto elevado.

Riesgos en implementación:

Virus Troyano.

Un caballo de Troya o troyano es un tipo de malware que a menudo se camufla como software

legítimo. Los ciber ladrones y los hackers pueden emplear los troyanos para intentar acceder a

los sistemas de los usuarios. Normalmente, algún tipo de ingeniería social engaña a los usuarios

para que carguen y ejecuten los troyanos en sus sistemas. Una vez activados, los troyanos

pueden permitir a los cibercriminales espiarte, robar tus datos confidenciales y obtener acceso

por una puerta trasera a tu sistema. Estas acciones pueden incluir las siguientes:

 Eliminación de datos

 Bloqueo de datos
  Modificación de datos

 Copia de datos

Interrupción del rendimiento de ordenadores o redes de ordenadores

Posibles ataques:

Trojan-DDoS.

Estos programas realizan ataques DoS (denegación de servicio) contra una dirección web

específica. Mediante el envío de una gran cantidad de solicitudes (desde tu ordenador y otros

ordenadores infectados), el ataque puede saturar la dirección de destino y originar una

denegación de servicio.

Puerta trasera (Backdoor)

Un troyano backdoor (de puerta trasera) proporciona el control remoto del ordenador infectado a

los ciberdelincuentes. Estos troyanos permiten al ciberdelincuente hacer todo lo que desee en el

ordenador infectado, como enviar, recibir, iniciar y eliminar archivos, mostrar datos y reiniciar el

ordenador. Los troyanos backdoor (de puerta trasera) a menudo se utilizan para unir un conjunto

de ordenadores infectados para formar un botnet o una red zombi que se puede utilizar con

objetivos delictivos.

Exploit.

Los exploits son programas que contienen datos o código que se aprovechan de una

vulnerabilidad del software de aplicaciones que se ejecuta en el ordenador.

Phishing .

El phishing es un método usado por los atacantes para suplantar la identidad de un usuario o de

una empresa mediante una comunicación electrónica (correo, mensajería instantánea, etc.), con

la finalidad de obtener datos personales y bancarios.

Si bien el phishing no es un ataque directo contra una web o sus servidores, este método busca

desviar el flujo de clientes, ingresos o búsquedas hacia un portal falso. Aunque focaliza sus

ataques a tiendas o portales de venta online, el phishing es también frecuente en sitios que

ofrecen servicios financieros o en aquellas webs que mantienen un flujo de crédito constante.

Una forma persistente de forzar la confusión del usuario es que se anuncia la aparición del sitio

falso en la red e, incluso, se paga por aparecer primero en los buscadores.

Para evitar caer en este tipo de ataques, es importante verificar que el remitente de cualquier

correo electrónico se corresponda con la entidad a la cual dice pertenecer y que no contenga

letras o caracteres extraños. Otra forma de identificar estos sitios falsos es observar que en la

barra de direcciones aparezca la etiqueta de “sitio seguro” y desconfiar de enlaces insertos

en nuestros e-mails.

1.5 Riesgos en Desarrollo.

1.5.1 Que el contenido de la planeación y propuesta no sea realmente definido por el equipo, sino

que solo escriban lo que el cliente les dicta.

Un proyecto consta de múltiples fases las cuales intervienen directa o indirectamente

obligándonos desde el principio a identificar la manera correcta en que debemos organizar cada

una de las actividades involucradas y su nivel de importancia.

La correcta planificación nos ayuda a establecer la prioridad de cada una de las actividades y a

tener un mejor control del tiempo para ejecutar un proyecto con la calidad deseada y con éxito.

Entonces, cuando hablamos de planificar podemos decir que se trata del conjunto de acciones

para establecer cada una de las actividades a realizar con el fin de lograr los objetivos planteados,

para mitigar el riesgo de que la planeación del proyecto no lo logré ser efectuado por fallas en la

estrategia planteada se deben dialogar las ideas con él equipo de profesionales, cliente y usuario
final manejando de manera conjunta las ideas principales para no comprometer al equipo a

realizar cambios improvisados que podrían perjudicar el desarrollo del software implicando

sobrecostos.

1.5.2. Hacer cronogramas muy optimistas.

En algunos casos la definición del alcance (no cumple con lo solicitado por el usuario), no

cumple con el tiempo establecido (esto a su vez impacta sobre el costo del desarrollo el cual se

eleva), en el aplicativo existen incongruencias que luego pasa a un estado de mantenimiento

constante, el equipo de desarrollo no trabaja como debe de ser, se realizan modificaciones que

no son informadas a todos los interesados y provoco molestias, existen factores internos y/o

externos que provocan demora y no son tomados en cuenta, y la adquisición de productos y/o

servicios adicionales debe de seguir un seguimiento.

Este es uno de los mayores inconveniente o riesgos al desarrollar un software, la estimación de

los tiempos por cada fase, se deben definir los cronogramas de acuerdo a las definiciones de

alcance del mismo, mayor disponibilidad de tiempo para que en ello se logre la revisión y

mantenimiento de fallas, logrando obtener la calidad que se le promete al cliente. Se debe llegar

a un mutuo acuerdo con el cliente sobre los tiempos de desarrollo y entrega, dando claridad sobre

cada fase del mismo.

1.5.3. Poca retroalimentación del usuario final.

Para mitigar este riesgo es necesario que se logre tener una comunicación clara y fluida con el

usuario final a fin de que se le pueda dar a conocer su evaluación el software y se logre conocer

interfaces y mecánicas.
Para ello recomienda realizar conclusiones específicas cuya finalidad sea la realización de

acciones que permitan darnos una perspectiva del usuario.

2. Técnicas apropiadas para la gestión de riesgos.

2.1. Brainstorming o tormenta de ideas:

Consiste en dejar que miembros del equipo de proyectos o expertos externos al proyecto

generen una lista de posibles riesgos bajo la supervisión del moderador de la reunión.

una herramienta de trabajo grupal que facilita el surgimiento de nuevas ideas sobre un tema o

problema determinado. La lluvia de ideas, es una técnica de grupo para generar ideas originales

en un ambiente relajado.

Esta herramienta fue creada en el año 1941, por Alex Osborne, cuando su búsqueda de ideas

creativas resulto en un proceso interactivo de grupo no estructurado que generaba mas y mejores

ideas que las que los individuos podían producir trabajando de forma independiente; dando

oportunidad de sugerir sobre un determinado asunto y aprovechando la capacidad creativa de los

participantes.

¿Cuándo se utiliza?

Se deberá utilizar la lluvia de ideas cuando exista la necesidad de:

 Liberar la creatividad de los equipos

 Generar un numero extensos de ideas

 Involucrar oportunidades para mejorar

 Nos permite

 Plantear y resolver los problemas existentes

  Plantear posibles causas

 Plantear soluciones alternativas

 Desarrollar la creatividad

 Discutir conceptos nuevos

 Superar el conformismo y la monotonía

¿Cómo se utiliza?

 Se define el tema o el problema.

 Se nombra a un conductor del ejercicio

 Antes de comenzar la “tormenta de ideas”, explicara las reglas.

 Se emiten ideas libremente sin extraer conclusiones en esta etapa.

 Se listan las ideas

 No se deben repetir

 No se critican

El ejercicio termina cuando ya no existen nuevas ideas. Se analizan, evalúan y organizan las

mismas, para valorar su utilidad en función del objetivo que pretendía lograr con el empleo de

esta técnica.

Modo de uso.

La técnica, “Brainstorming”, puede ser empleada a través de 3 diferentes maneras:

 No estructurado (flujo libre)

 Escoger a alguien para que sea el facilitador y apunte las ideas

 Escribir en un rotafolio o en un tablero una frase que represente el problema y el

asunto de discusión.
 Escribir cada idea en el menor número de palabras posible.

 Verificar con la persona que hizo la contribución cuando se esté repitiendo la idea.

 No interpretar o cambiar las ideas.

 Establecer un tiempo límite (aproximadamente 25 minutos).

 Fomentar la creatividad.

 Construir sobre las ideas de otros.

 Los miembros del grupo de “lluvia de ideas” y el facilitador nunca deben criticar

las ideas.

 Revisar la lista para verificar su comprensión.

 Eliminar las duplicaciones, problemas no importantes y aspectos no negociables.

 Llegar a un consenso sobre los problemas que parecen redundantes o no importantes.

 Estructurado (en círculo).

 Tiene las mismas metas que la lluvia de ideas no estructurada. La diferencia consiste en

que cada miembro del equipo presenta sus ideas en un formato ordenado (ej: de

izquierda a derecha). No hay problema si un miembro del equipo cede su turno si no

tiene una idea en ese instante.

 Silenciosa (lluvia de ideas escritas)

 Es similar a la lluvia de ideas, los participantes piensan las ideas, pero registran en papel

sus ideas en silencio. Cada participante pone su hoja en la mesa y la cambia por otra hoja

de papel. Cada participante puede entonces agregar otras ideas relacionadas o pensar en

nuevas ideas. Este proceso continuo por cerca de 30 minutos y permite a los participantes

construir sobre las ideas de otros y evitar conflictos o intimidaciones por parte de los

miembros dominantes.
2.2. Juicio Experto: Técnica Delphi.

Una técnica prospectiva que se usa para con el propósito

de realizar pronósticos y predicciones. La información obtenida es principalmente

de tipo cualitativa.

La técnica se basa en la consulta a un grupo de especialistas sobre su visión futura de un tema

determinado, de manera sistemática y anónima. Las diversas opiniones calificadas se analizan y

se replantean a los expertos en una segunda vuelta con información de lo aportado por los demás,

sin revelar los nombres de los autores. Esto permite orientar la creación de ideas hacia la

obtención de un consenso. Si es necesario se reitera el proceso varias veces.

En el siguiente diagrama de flujo se esquematiza el ciclo del proceso:

El resultado es un agregado consensual de las opiniones y juicios individuales en referencia al

futuro que se pretende visualizar...

Existen diferentes versiones de esta técnica; la forma más utilizada, organizada en cuatro pasos,

es la que se describe a continuación.

2.2.1. Formulación del problema.

Resultados esperados y horizonte temporal.

Es importante definir con precisión el campo de investigación. A partir de este paso se determina

el perfil de los expertos que deben ser consultados y se establecen las bases para la elaboración

del cuestionario inicial.

2.2.2. Elaboración del cuestionario.

Al igual que para las encuestas, el cuestionario se construye dentro del marco de criterios

específicos, a saber:

Las preguntas deben ser precisas, que generen respuestas concretas.

En la medida de lo posible y según el tema, se esperan datos cuantificables (por ejemplo,

probabilidades de ocurrencia de un evento o acontecimiento, tiempo estimado para el logro de

determinada meta, etc.).

Se debe especificar claramente el horizonte de tiempo previsto para el ejercicio y determinar el

objetivo del cuestionario.

En los cuestionarios subsiguientes al primero, el objetivo es disminuir la dispersión de las

opiniones.

2.2.3. Selección del panel de expertos.

Los expertos deben tener un amplio dominio del tema sobre el que se realiza el estudio y

capacidad para elucubrar sobre el futuro. No importan sus credenciales académicas o su jerarquía

en la organización a la que pertenezca; en cambio es relevante su amplitud ante la pluralidad de

planteamientos que se presentarán durante el proceso.

Los expertos deben ser independientes para evitar posibles sesgos en sus opiniones. Es bueno

conformar una selección de alrededor de 50 o más porque siempre hay bajas durante el tiempo de

duración del estudio. Es necesario aclararles que no se conocerán entre s y garantizar su

anonimato.

2.2.4. Desarrollo del proceso.

Una vez terminada la selección de expertos, se les envía el primer cuestionario con una

comunicación en la que se aclaran las características del método para que todos sepan que se

producirán otras opiniones, que habrá más de una vuelta y que lo que se busca es un consenso.

Transcurrido el tiempo establecido, se reciben las respuestas al cuestionario, se procesan

estadísticamente o de cualquier otra manera previamente establecida. La opinión media

consensuada generalmente no es posible en la primera consulta. Por otra parte, a veces los

planteamientos radicalmente divergentes de algunos participantes pueden ser de mayor interés

que los de la mayoría.

La información procesada constituye el material para la segunda consulta. En esta etapa los

expertos son informados de los resultados de la primera consulta de preguntas y deben dar una

nueva opinión. En el caso de que su respuesta sea fuertemente divergente con respecto al grupo

debe razonar su posición.

Si se hace necesaria, en la tercera consulta se pide a cada experto comentar los argumentos de los

que no coinciden con la mayoría. Una cuarta vuelta de preguntas, generalmente conduce al

resultado.

El papel del equipo conductor es fundamental en procesar la información que se genera en las

consultas y orientar el trabajo hacia el consenso.

2.2.5 Fortalezas y limitaciones del método.

La principal ventaja del Método Delphi es la alta probabilidad de obtener un consenso

convergente al final del desarrollo de las consultas sucesivas más algunos juicios divergentes a

los que hay que prestar atención. La técnica es simple y efectiva.

En el transcurso del proceso también se genera información útil para el estudio prospectivo.

Pueden, por ejemplo, identificarse tendencias, potenciales rupturas en la trayectoria de éstas o

aspectos nuevos no considerados anteriormente.

El método puede utilizarse en diversas áreas de la actividad humana: los pronósticos

tecnológicos, la evolución social y política y las perspectivas de desarrollo económico, entre

otras.

Las limitaciones del método son fundamentalmente dos: el proceso puede ser exageradamente

largo y eventualmente costoso. Por otra parte, en su transcurso es normal perder importantes

miembros del panel de expertos lo que le hace reducir solidez a los resultados.

2.3. DAFO:

Este método consiste en identificar las Debilidades, Amenazas, Fortalezas, y Oportunidades

existentes en nuestro proyecto, y en la organización que lo desarrolla. A partir de ellas será

posible identificar los riesgos, y oportunidades potenciales que pueden afectar a nuestro

proyecto. El análisis DAFO, también conocido como análisis FODA, es una herramienta de

estudio de la situación de una empresa, institución, proyecto o persona, analizando sus

características internas (Debilidades y Fortalezas) y su situación externa (Amenazas

y Oportunidades) en una matriz cuadrada.

Es una herramienta para conocer la situación real en que se encuentra una organización, empresa,

o proyecto, y planear una estrategia de futuro.

Se considera que esta técnica fue originalmente propuesta por Albert S. Humphrey durante los

años sesenta y setenta en los Estados Unidos durante una investigación del Instituto de

Investigaciones de Stanford que tenía como objetivo descubrir por qué fallaba la planificación
corporativa. Este recurso produjo una revolución en el campo de la estrategia empresarial. El

objetivo del análisis DAFO es determinar las ventajas competitivas de la empresa bajo análisis y

la estrategia genérica que más le convenga en función de sus características propias y de las del

mercado en que se mueve.

2.4. Entrevistas:

El director del proyecto se reúne los stakeholders, usuarios, o con diferentes personas con

experiencia y conocimientos relevantes para el proyecto en cuestión, para recabar información

sobre los riesgos potenciales que prevén para el proyecto.

2.5. Taxonomías de riesgos.

La Estructura de Desglose de Riesgo (RBS) especifica en forma

jerárquica las diferentes fuentes de donde podrían surgir riesgos para un determinado

proyecto. Cada proyecto tiene su propia RBS.

2.6. Técnica de diagramación causa y efecto.

El diagrama de causa-efecto (llamado también de espina de pescado debido a su forma o de

Ishikawa debido a su autor) es un método para crear y clasificar ideas o hipótesis sobre las

causas de un problema de manera gráfica. Además, organiza gran cantidad de datos mostrando

los nexos existentes entre los hechos y las posibles causas.

La representación gráfica va a permitir:

Estimular las ideas.

Ampliar las opiniones acerca de las causas probables o reales.

Facilitar un examen posterior de los motivos individuales.

Lo puedes encontrar también como: Diagrama de Ishikawa , Espina de pescado .

¿PARA QUÉ...?

El diagrama de causa-efecto presenta unas utilidades para determinar los factores involucrados

en un problema.

Ayuda a la objetividad, aunque no es un método cuantitativo.

Es aplicable a muchas y diversas áreas.

Se puede emplear tanto para la búsqueda de una causa como de una solución.

Para crear un consenso sobre las causas.

Para concentrar la atención en el proceso en el que se produce el problema.

Para permitir el uso constructivo de la información.

Para expresar hipótesis sobre las causas del problema.

3. Matriz de riegos a los que puede estar sometida su aplicación.

Tipo de riesgo Riesgo Probabilidad Impacto

Personal No es posible reclutar personal con el Baja Alto

perfil requerido.

Personal Se enferma la persona clave en el Media Baja

desarrollo.

Personal No hay capacitación correcta. Alto Alto

 Tecnológica La BD no soporta no soporta el Media Alto

número de transacciones requeridas.

Tecnológica Se cae la red. Baja Alto

Tecnológica Caída de servicios de producción. Baja Alto

Tecnológica Extracción, modificación y Media Alto

destrucción de información

confidencial.

Personal Uso inadecuado de las instalaciones. Baja Baja

Tecnológica Ataques de virus informáticos. Alta Alto

Tecnológica Fuga de información. Medi Alto

Requerimiento El cliente solicita nuevos Baja Media

requerimientos que impactan el

diseño.

Organizacional Reducción en el presupuesto del Baja Madia

proyecto por problemas financieros

Estimación El tiempo para el desarrollo del Media Aalta

proyecto es subestimada.

Cliente o El cliente no participa en los ciclos Media Alta

Usuario final de revisiones los planes y los

prototipos.

Tecnológica Inadecuados controles de accesos Media Baja

lógicos.
 Tecnológica Falta de disponibilidad de servicios Alta Alta

de terceros.

Personal Descontrol del personal Media alta

4. Cree un plan de acción que le permita brindar seguridad a su aplicación.

Los aspectos organizativos de la información se podrían decir que es un dominio de contrastes,

ya que hay controles que se encuentran muy bien implementados y otros en cambio están por

trabajar.

En este punto se ha analizado la empresa desde el punto de vista de sus activos, cómo está

organizada, las amenazas y un análisis de riesgos donde se puede ver cómo afectan estas y el

impacto que tienen sobre la organización. En este apartado se evaluará hasta que punta la

empresa cumple con las buenas prácticas en materia de seguridad. Esto se hará utilizando como

guía la ISO/IEC 27002:2005 basándonos en el marco de control del estado de la seguridad.

Metodología.

La ISO/IEC 27002:2005 servirá como marco de control del estado de la seguridad. En total, la

ISO/IEC 27002:2005 agrupa 133 controles o medidas preventivas sobre “buenas prácticas” para

la gestión de la seguridad de la información, organizados en 11 áreas y 39 objetivos de control.

Este estándar es internacionalmente reconocido y es perfectamente válido para la mayoría de las

organizaciones.

 Formalización de las prácticas mediante documentos escritos o aprobados.

  Política personal.

 Solicitudes técnicas (Software, hardware o comunicaciones).

 Seguridad física.

Lo que componen la ISO/IEC 27002:2005 son:

 Política de seguridad

 Organización de la seguridad de la información

 Gestión de activos

 Seguridad de los recursos humanos

 Gestión de comunicaciones y operaciones

 Control de acceso

 Adquisición, desarrollo y mantenimiento de sistemas de información

 Gestión de incidentes

 Gestión de continuidad de negocio

 Cumplimiento

Como principales puntos a destacar por parte de la política de seguridad, esta debería:

 establecer el compromiso de la gerencia y el enfoque de la organización para gestionar

la seguridad de la información. La gerencia debería aprobar, publicar y comunicar a

todos los empleados en la forma adecuada, un documento de política de seguridad de la

información.
  El otro objetivo principal de la política es llevar un control, revisándola a intervalos

previamente definidos y planificados o, en caso de cambios significantes, con el fin de

asegurar su uso continuo, adecuación y efectividad.

Gestión de activos:

La gestión de activos no obtiene buenos resultados a nivel general, por tanto, la organización ha

de intentar enfocar sus esfuerzos en realizar una gestión de los activos más importante de manera

que se intenten alcanzar niveles aceptables.

Seguridad ligada a los recursos humanos:

La seguridad de los recursos humanos está en líneas generales por encima del 50% del nivel

total, lo que es un nivel aceptable pero no suficiente como para no invertir esfuerzos en mejorar

este apartado.

Actualmente no se recibe ningún tipo de formación o entrenamiento en términos de

conocimiento y actuaciones regulares en políticas y procedimientos organizacionales relevantes

en su función. Esta formación debería empezar con una inducción formal del proceso designado

para introducir la política de seguridad de la compañía y las expectativas. Otro punto a definir

son los procesos disciplinarios para empleados que cometan aperturas en la seguridad,

asegurándose que se reciba un correcto y justo tratamiento de los empleados por los hechos

ocurridos y que han provocado dicha apertura.

Seguridad física y del entorno:

En cuanto a la seguridad de los equipos fuera de la universidad, no se contempla esta posibilidad

ya que no es posible extraer material fuera de ella y los ordenadores que se desechan se realiza a

través de la fundación universitaria del area andina tiene un servicio para ello, por lo tanto, en

este apartado haría falta formalizar el procedimiento y ponerlo en conocimiento de los

trabajadores de la organización informando que es un servicio que se puede realizar a través de

un tercero, aún y así debe reforzarse este control.

Controles de acceso:

La responsabilidad de los usuarios y compromiso de estos ante el buen mantenimiento y eficacia

de las medidas de control y donde no existe ningún procedimiento ni documentación formal,

actualizado y revisado periódicamente al respecto, por tanto es otro punto a implementar. Este

procedimiento debería documentar pautas de los empleados como mantener el escritorio limpio,

no permitir el acceso no autorizado a su zona de trabajo, una política de contraseñas robusta, no

acceder a redes o sitios maliciosos que puedan comprometer los activos o información sensible.

5. Recomendaciones pertinentes frente a la ciberseguridad del producto.

Es necesario la creación y formalización de un documento de seguridad donde se especifiquen y

detallen los requisitos que debe seguir la organización conjuntamente con la normativa de

seguridad vigente española para la gestión de los datos de carácter confidencial, para conseguir

preservar la confidencialidad, integridad y disponibilidad de los recursos de la organización

Es necesario la formalización de procesos y gestión de los usuarios sobre los recursos de la

organización, como:

 Controles de acceso adecuados al rol del usuario.

 Procedimientos de seguridad claramente definido.

 Roles especificados y detallados para la gestión de la información, etc.

 Responsabilidades de los trabajadores.

 Concienciación del usuario sobre temas de seguridad de la información.

 Reducción del riesgo por desconocimiento de los controles o respuesta a incidentes.

Buenas prácticas por parte de los usuarios.

 La implementación de un firewall de aplicación es un complemento más de seguridad, sin

substituir otros dispositivos o procedimientos de seguridad. Este firewall de aplicación

deberá tener asignado un responsable que se encargue de verificar las alertas que se

generan, así como de actualizarlo de forma periódica.

 Procedimiento de programación segura, Procedimiento de pruebas del software,

Auditorías de seguridad.
 Conclusión

La gestión del riesgo es crucial en el proyecto de software, el gestionar los riesgos implica

identificar todos los factores que pueden llevar el proyecto al fracaso. Si se tienen en cuenta o

se elabora los planes RSGR se podrá controlar de una forma adecuada los riesgos que pueden

afectar al proyecto.

Es necesario recordar que el plan RSGR debe revisarse conforme el proyecto avanza y a su

vez recordar que los riesgos de relacionan acontecimientos futuros.

Referencia.

https://www.aulafacil.com/cursos/estrategia/prospectiva-y-gestion-estrategica/juicio-de-expertos-

metodo-delphi-l37803

https://es.slideshare.net/malupahu/gestion-de-riesgos-4696054

https://www.linkedin.com/pulse/los-100-riesgos-en-la-gesti%C3%B3n-de-proyectos-luciano-

moreira-da-cruz

https://www2.deloitte.com/cr/es/pages/risk/articles/cuales-fueron-los-riesgos-tecnologicos-en-

2017-y-que-se-espera-para-este-2018.html

https://www.aec.es/web/guest/centro-conocimiento/diagrama-de-causa-efecto