INGENIERÍA DE SOFTWARE

Presentado a:

ANGEL ALBERTO VARON QUIMBAYO

Programa: Ingeniería en sistemas

Fundación universitaria del Areandina.

2020

1
Contenido
INGENIERÍA DE SOFTWARE............................................................................................................................. 1
Introducción......................................................................................................................................................... 3
1. Análisis......................................................................................................................................................... 3
1.1. Contenido.................................................................................................................................................. 3
1.2. Hacer cronogramas muy optimistas.......................................................................................................... 3
1.3. Poca retroalimentación del usuario final....................................................................................................3
1.4. Usuarios finales que insisten en nuevos requerimientos a lo largo de todo el proyecto............................4
1.5. Riesgos en Desarrollo............................................................................................................................... 5
2. Técnicas apropiadas para la gestión de riesgos...........................................................................................6
2.1. Brainstorming o tormenta de ideas:........................................................................................................... 6
2.2. Juicio Experto: Técnica Delphi.................................................................................................................. 7
2.3. DAFO:....................................................................................................................................................... 9
2.4. Entrevistas:............................................................................................................................................. 10
2.5. Taxonomías de riesgos........................................................................................................................... 10
2.6. Técnica de diagramación causa y efecto................................................................................................10
3. Matriz de riegos a los que puede estar sometida su aplicación..................................................................11
4. Cree un plan de acción que le permita brindar seguridad a su aplicación..................................................11
5. Recomendaciones pertinentes frente a la ciberseguridad del producto......................................................13
Conclusión......................................................................................................................................................... 14
Referencia......................................................................................................................................................... 15
Introducción

En este documento, cubrimos algunos de los objetivos de la gestión de riesgos, que a su vez nos
permiten identificar, controlar y eliminar las fuentes de riesgo antes de que los riesgos comiencen
a afectar la realización de los objetivos del proyecto. Todos estos se centran en el análisis de la
gestión de riesgos, que pueden ayudar al equipo a comprender y gestionar la incertidumbre de
las fallas que pueden ocurrir durante el proyecto a través de varios pasos. Los peligros son
problemas potenciales que pueden ocurrir o no.

1. Análisis.
1.1. Contenido.

El equipo no determinó realmente el contenido del plan y la propuesta, sino que solo escribió los
requisitos del cliente. Un proyecto consta de múltiples fases, las cuales intervienen directa o
indirectamente, obligándonos a determinar desde el principio la forma en que debemos organizar
correctamente todas las actividades involucradas y su nivel de importancia.
El plan correcto puede ayudarnos a determinar la prioridad de cada actividad y controlar mejor la
calidad y el tiempo esperados para ejecutar con éxito el proyecto. Por tanto, cuando hablamos de
planificación, se puede decir que se trata de un conjunto de acciones para establecer cada
actividad a realizar para lograr las metas marcadas para reducir el riesgo de no proceder con el
plan del proyecto. En la estrategia propuesta, debe estar en línea con el profesional. El equipo,
los clientes y los usuarios finales discuten ideas y gestionan conjuntamente las ideas principales
para no hacer que el equipo realice cambios improvisados que puedan dañar el desarrollo del
software, lo que significa sobrecostos.

1.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.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.
Los usuarios pueden requerir cambios en los nuevos requisitos a lo largo del proyecto,
identificando defectos o hechos que se han olvidado al recopilar información sobre las funciones y
el alcance del desarrollo. Este riesgo debe mitigarse definiendo claramente los requisitos del
producto. De la mano del usuario final, porque si se producen cambios durante el proceso de
desarrollo, traerá altos costos adicionales.

1.4.1. Riesgos en implementación:

Virus Troyano.
Un caballo de Troya o un caballo de Troya es un tipo de software malintencionado que suele
disfrazarse de software legítimo. Los ladrones cibernéticos y los piratas informáticos pueden
utilizar programas de caballo de Troya para intentar obtener acceso a los sistemas de los
usuarios. Generalmente, ciertos tipos de ingeniería social engañan a los usuarios para que
carguen y ejecuten troyanos en sus sistemas. Una vez activado, el programa caballo de Troya
puede permitir a los ciberdelincuentes espiarte, robar tus datos confidenciales y obtener acceso
por la puerta trasera al sistema. Estas operaciones pueden incluir lo siguiente:

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

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.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.5.2. 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 rota folio 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 (Amenazasy 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.

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 de riesgos es muy importante en un proyecto de software. La gestión de

riesgos implica determinar todos los factores que pueden hacer que el proyecto falle.
Si se considera o se prepara el plan RSGR, los riesgos que pueden afectar el proyecto
se pueden controlar completamente. Es necesario recordar que a medida que avanza
el proyecto, se debe revisar el plan RSGR, recordando también que los riesgos están
relacionados con eventos futuros.
 Referencia.

Barzanallana, R. (2004, 13 diciembre). Apuntes Gestión de riesgos en Informática.

Seguridad. Criptografia. Rafael Barzanallana. IAGP. Gestión de riesgos en ingeniería
del software. https://dis.um.es/%7Ebarzana/Informatica/IAGP/IAGP_riesgos.htmlf, R.
(2016, 5 mayo). Los 100 riesgos en la gestiÃ3n de proyectos. Los 100 riesgos en la
gestión de proyectos. https://www.linkedin.com/pulse/los-100-riesgos-en-la-gesti
%C3%B3n-de-proyectos-luciano-moreira-da-cruz