INGENIERÍA DEL SOFTWARE

CÓDIGO: 301404_6

Evaluación Final: Consolidación de la propuesta de software

Presentado a:
Pilar Alexandra Moreno
Tutor

Entregado por:

Sandra Paola Molina

Cód.: 52.913.263
Marco Tulio Palomo Avila
Cód.: 79405397

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA - UNAD

DICIEMBRE DE 2018
 Tabla de contenido

Introducción .................................................................................................................................................. 3
Desarrollo de la actividad. ............................................................................................................................ 5
Capítulo 1 ...................................................................................................................................................... 5
1. La gestión del alcance ........................................................................................................................... 5
1.1.1 Recopilación de Requisitos .......................................................................................................... 5
1.1.2 Definición del alcance .................................................................................................................. 5
1.1.3 Creación EDT (WBS) Estructura desagregada del trabajo-Work Break Down .......................... 9
1.1.4 Control del Alcance ..................................................................................................................... 9
1.1.5 Verificación del alcance ............................................................................................................. 10
Capítulo 2 .................................................................................................................................................... 11
2. Gestión del tiempo............................................................................................................................ 11
2.2.1 Identificación de actividades ...................................................................................................... 11
2.2.2 Secuenciamiento de actividades ............................................................................................... 12
2.2.3 Estimación de recursos de las actividades ................................................................................ 13
2.2.4 Estimación duración de tiempo .................................................................................................. 13
2.2.5 Desarrollo cronograma (Project Schedule) ................................................................................ 13
2.2.6 Control del cronograma .......................................................................................................... 13
Capitulo3 ..................................................................................................................................................... 14
3. La gestión de costes ............................................................................................................................ 14
Capítulo 4. Gestión de riesgos .................................................................................................................... 15
4.2 Planificar la gestión de riesgos.......................................................................................................... 15
4.3 Identificar los riesgos del proyecto ................................................................................................... 16
4.3.1 Lista de riesgos identificados ..................................................................................................... 17
4.4 Análisis Cualitativo ........................................................................................................................... 19
Tablas de riesgos ................................................................................................................................. 21
Planificación respuesta:....................................................................................................................... 25
Conclusiones ............................................................................................................................................... 30
Referencias bibliográficas ........................................................................................................................... 31
 Introducción

El grupo colaborativo 301404_6 de ingeniería de software, está conformado por los estudiantes,

Miguel Ángel García, Sandra Paola Molina, Marco Tulio Palomo Avila, quienes ejercerán para el

desarrollo de la actividad dentro del grupo colaborativo de la siguiente manera:

 La estudiante1 Sandra Paola Molina ejercerá el rol Líder Comunicador que tendrá las

siguientes actividades o funciones, será el Responsable de la comunicación entre el tutor y

el equipo, como también de presentar a su equipo la información que recoge de la

observación - al desarrollo de las actividades - hecha a los otros equipos de grupo.

Responsable de entregar el producto final.

Se tuvo en cuenta para el desarrollo de la gestión del Tiempo las actividades a desarrollar,

el secuenciamiento de las mismas, la estimación de recursos con el objetivo de dar una

fecha de entrega del proyecto.

 El estudiante3 Marco Tulio Palomo Avila ejercerá el rol Vigía del Tiempo y será el que

controla el cronograma de tiempo establecido, y es responsable porque el equipo desarrolle

las diferentes actividades dentro del tiempo pactado.

Se tuvo en cuenta Para la gestión de riesgo, los procesos que existen en planificación e

identificación de riesgos, con lo cual se obtuvo una lista de riesgo, para realizar el análisis

cuantitativo de riesgos, para poder planificar las respuestas, y monitorear y controlar los

riesgos. Para este proceso se toma como entrada la lista de riesgos identificados y se analiza

en cada una de las fases. Entonces se procedió a utilizar, una tabla de probabilidad con

cinco niveles, esta ubica el riesgo en un nivel de ocurrencia, los cuales son raro,
 improbable, posible, probable, casi seguro. Los procesos mencionados anteriormente

involucran el uso de técnicas y herramientas que permiten priorizar dichos riesgos.

 El estudiante 5. Miguel Ángel García Ferro ejercerá el rol Utilero. Será el responsable

de conseguir el material y/o las herramientas de acuerdo a las necesidades del equipo para

el desarrollo de las actividades y/o procesos.

Se tuvo encuenta para el desarrollo de la gestión del Riesgo.

 Desarrollo de la actividad.

Capítulo 1
1. La gestión del alcance

1.1.1 Recopilación de Requisitos

Link formato IEEE 830

https://drive.google.com/open?id=1E-8Cdxg_kPo4kIj44UrcWeh69ZyIqu9p

1.1.2 Definición del alcance

Objetivo General:

Desarrollar el software de inteligencia artificial para la toma de decisiones del diagnóstico

preoperatorio del paciente de la Clínica Colombiana de obesidad y metabolismo S.A.S.

Descripción alcance del producto

 Características

 Combina lo real y lo virtual

 Funciona en tiempo real

 Se registra en tres dimensiones

 Autoenfoque para evitar distorsión en la imagen mientras el escáner se encuentra

en movimiento

 Alta precisión en sus resultados

 Requisitos funcionales

 Antes de poder usar la aplicación el usuario debe autenticarse en la aplicación con un

nombre de usuario y contraseña

 Al autenticarse, los usuarios estarán organizados desde enfermeras (con el menor

nivel de privilegios), hasta jefe de sistemas (con el máximo nivel de privilegios),

pasando por Mantenimiento que será el nivel intermedio.

 Enfermeras: Proceso completo de detección de errores, no pueden añadir usuarios, no

pueden crear formatos y no pueden acceder al menú de opciones.

 Mantenimiento: Mantienen privilegios de enfermeras, pero también pueden crear

formatos y acceder a opciones. No pueden añadir usuarios nuevos.

 Jefe de sistemas: Mantienen privilegios de Mantenimiento, pero también pueden

añadir y borrar usuarios de la aplicación.

 Los usuarios jefes de sistemas pueden añadir otros usuarios y establecer su nivel y

contraseña.

 Abrir en un menú independiente las distintas opciones que se han pedido para que el

menú principal no esté recargado y para que solo los usuarios de nivel Mantenimiento

y jefe de sistemas puedan cambiar las opciones.

 La clínica escaneará mujeres y hombres con una velocidad de escaneo baja para que

el sistema revise detenidamente el paciente

 Desde el menú principal se podrá previsualizar el escaneo y escoger el área a escanear

 Desde el menú principal se podrá escanear los pacientes de manera fácil

 Todas las opciones seleccionadas en el programa para el escaneo podrán ser

guardadas en un documento de formato

 El algoritmo de comparación que se use tiene una serie de características

configurables, que es Umbral de similitud que funcionan juntos para saber cómo de

diferente debe ser lo encontrado respecto a lo esperado

  La imagen recién escaneada debe estar mostradas siempre para asegurarse que sea el

paciente al que le están realizando el estudio.

 En el menú de visualización de zonas debemos añadir un zoom en forma de imagen

dinámica al lateral para poder ver mejor al paciente.

 Requisitos no funcionales

 Carga de Internet

 Idioma

 Lenguaje de desarrollo

 Versión de S.O.

 El escáner deber poder escanear tejidos blandos

 Se autenticará al usuario mediante usuario y contraseña a indicar por el cliente.

Especificaciones:

 Se recomienda utilizar el software sobre sistemas operativos Windows

Fronteras del proyecto

Con este Software de inteligencia artificial, la clínica de estética corporal tendrá beneficios como

integración de la información del paciente a intervenir, dándole agilidad en el proceso de estudio

científico corporal de cada paciente, permitiendo estandarizar y agilizar los procesos y tener una

mejora en la administración de las cirugías.

Este tipo de software, permite integrar todas las áreas de la clínica que intervienen en las cirugías

estéticas de sus pacientes. Como: anestesiólogo, enfermeras, gestión de las relaciones con los

pacientes, banco e inventarios de sangre; para que así toda la clínica trabaje mejor como una sola

unidad.
Entregables del proyecto

 Dos discos con el software para la instalación.

 Guía de instalación.

 Guía de manejo del software

Criterios de aceptación de entregables

El software se considera entregado si:

 Se puede instalar el software en los equipos

 Se puede ingresar a la información del paciente

 La apariencia de la información del paciente es la definida por el administrador.

La guía de Instalación será aceptada si:

 Si explica cómo realizar la instalación del software

Guía de manejo de software será aceptada si:

 Si explica el manejo y las diferentes opciones del software

 Si explica cómo dar inicio al proceso de escaneo.

Limitaciones o restricciones del proyecto

 Se instalará el software en los equipos de la Clínica Colombiana de Obesidad y

Metabolismo.

 Este proyecto está pensado solo para los cirujanos plásticos de la Clínica.

 Este software solo será probado en los equipos de la Clínica.

 Este software será probado en equipos Windows 10

Asunciones del proyecto

 Este software se entregará en CD e instalado en los equipos que se destinen a este fin en el

momento de la entrega.

 El mantenimiento e instalaciones posteriores a la entrega del software estarán a cargo de la

Clínica Colombiana de Obesidad y Metabolismo.

1.1.3 Creación EDT (WBS) Estructura desagregada del trabajo-Work Break Down
Software para la
Clinica Colombiana
de Obesidad y
Metabolismo

1. REQUISITOS 4. PRRUEBAS 5.
2. DISEÑO 3. DESARROLLO IMPLEMENTACIÓN
Y ENTREGA

2.1 3.1 4.1

1.1 5.1
Diseño inicial Seleccion de Selección de
Análisis de Reporte de
programas de objetivos a
requisitos ejecución
desarrollo evaluar

1.2 5.2
Especificaciones 2.2 3.2 4.2 Pruebas
de generales Pruebas
Diseño tecnico Division modular
funcionamiento preliminares

1.3 3.3 5.3

2.3 4.3 Pruebas de
Requerimientos Creación de Formación al
Diseño final usuario
Funcionales prototipos personal

1.4
3.4
Requerimientos 4.4 Certificación 5.4
no Creación de técnica Acta de entrega
manuales
funcionales

1.1.4 Control del Alcance

Plan de control de cambios:

Si se necesita hacer algún cambio en el proyecto debe seguir el siguiente procedimiento.

Llenar un formato de cambios:

Solicitud de cambio
Solicitante: Fecha:
Cedula:
Cambio Justificación Procesos que afecta

Recibió:

Entregarlo al responsable del proyecto

Aprobación de cambio:

Para la aprobación de cualquier cambio se contará con el análisis por parte de.

 Directivos de la Clínica Colombiana de Obesidad y Metabolismo

 Los encargados del proyecto

 Los desarrolladores del proyecto

Si se considera pertinente el cambio se realizará los ajustes al proyecto para que estos cambios

sean adaptados a: EDT, Cronograma y presupuesto.

Una vez ajustado el cambio se comunicará para que puedan ser realizadas las modificaciones.

1.1.5 Verificación del alcance

Una vez realizado el proyecto se verificará que se ha cumplido con los objetivos propuestos así:

VERIFICACIÓN DEL ALCANCE

Criterios a verificar cumplió No cumplió A mejorar
Se puede ingresar a los datos del paciente
Se puede guardar los datos tomados
Se puede ajustar los datos
La apariencia de las imágenes tomadas son
claras
 Se cuenta con los manuales
Los manuales son claros para el usuario

Capítulo 2
2. Gestión del tiempo.

2.2.1 Identificación de actividades

 Análisis de requisitos.
 Especificaciones de funcionamiento

 Requerimientos funcionales

 Requerimientos no funcionales

 Diseño inicial

 Diseño técnico

 Diseño final

 Selección de programas de desarrollo

 División modular

 Creación de prototipos

 Creación de manuales

 Selección de objetivos a evaluar

 Pruebas generales

 Pruebas de usuario

 Certificación técnica

 Reporte de ejecución

 Pruebas preliminares

 Formación al personal

 Acta de entrega
2.2.2 Secuenciamiento de actividades
Con el método PDM

Especificaciones
Análisis de Requerimientos Requerimientos
de
requisitos funcionales no funcionales
funcionamiento

Diseño Inicial Diseño técnico Diseño final

Selección de División Creación Creación de

programas de modular de Manuales
desarrollo prototipos
INICIO FIN

Selección de Pruebas Pruebas de Certificación

objetivos a generales usuario técnica
evaluar Garantía

Reporte de
ejecución Pruebas Formación al Acta de
preliminares personal entrega
2.2.3 Estimación de recursos de las actividades

Nombre del Tipo Disponibilidad Necesidad

recurso
Director del Humano 1 1
proyecto
Diseñador Humano 1 1
Programador Humano 1 2
Analista Humano 1 1
Instalaciones Físico 1 1
Computadores Equipo 4 4
Licencias Físico 4 4
Sistema operativo Físico 4 4
Windows 10

2.2.4 Estimación duración de tiempo

2.2.5 Desarrollo cronograma (Project Schedule)

2.2.6 Control del cronograma

Para poder realizar el control del cronograma se hará seguimientos semanales con el fin de realizar
ajustes y mejoras en las actividades que lo requieran.
Se debe informar al responsable del calendario sobre el adelanto de actividades para reorganizarlo
en caso de retrasos en el proceso de desarrollo.
Actividad Duración Duración Comienzo Comienzo Fin Fin % Observ
programada real programado real progra real aciones
(días) (días) mado ejecuta
do

Capitulo3

3. La gestión de costes

Nombre de la Costo fijo Acumulació Costo total Previsto Variación Real Restante
tares n de costos
fijos
Problema $0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
propuesto
Levantamient $2.000.000 Prorrateo $2.000.000 $0,0 $2.000.000 $0,0 $2.000.000
o de
Información
Tipo de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
software
Modelo de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
desarrollo
Descripción $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
general del
proyecto
Elaboración $500.000 Prorrateo $500.000 $0,0 $500.000 $0,0 $500.000
de la gestión
de Alcance
Elaboración $500.000 Prorrateo $500.000 $0,0 $500.000 $0,0 $500.000
de la gestión
de tiempo
Elaboración $500.000 Prorrateo $500.000 $0,0 $500.000 $0,0 $500.000
de la gestión
de costos
Elección de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
herramientas
de diseño
Diseño de $8.000.000 Prorrateo $8.000.000 $0,0 $8.000.000 $0,0 $8.000.000
juegos
Construcción $20.000.00 Prorrateo $20.000.00 $0,0 $20.000.00 $0,0 $20.000.000
de juegos 0 0 0
Construcción $200.000 Prorrateo $200.000 $0,0 $200.000 $0,0 $200.000
de manuales
Prueba y $6.000.000 Prorrateo $6.000.000 $0,0 $6.000.000 $0,0 $6.000.000
ajustes
Entrega de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
software
Costo total 37.700.000
 Capítulo 4. Gestión de riesgos

La Gestión de los Riesgos del Proyecto de software de ingeniería artificial para la Clínica

Colombiana de Obesidad y Metabolismo S.A.S incluirá los procesos relacionados con la

planificación de la gestión de riesgos. Así como, la identificación, análisis y la planificación de

respuestas a los mismos. Estos procesos se actualizan durante el ciclo de vida del Proyecto.

Los objetivos de la Gestión de los Riesgos del Proyecto de software de ingeniería artificial son:

1. Disminuir la probabilidad y el impacto de los eventos negativos.

2. Aumentar la probabilidad y el impacto de los eventos positivos.

3. Realizar estrategias de respuesta ante las contingencias que se puedan presentar en la

ejecución del proyecto.

Para la gestión de riesgos del proyecto software de inteligencia artificial para la Clínica Colombiana

de Obesidad y Metabolismo S.A.S se implementará la siguiente metodología con los procesos de

identificación, análisis cualitativo, plan de respuesta y control y seguimiento de los riesgos,

sustentada en la guía del PMBOK. Ver en la ilustración 1.

4.2

Ilustración 1 Diagrama de planificación del riesgo

Planificar la gestión de riesgos

Según Project Management Institute (2013) La Gestión de los Riesgos del Proyecto incluye los

procesos para llevar a cabo la planificación de la gestión de riesgos, así como la identificación,

análisis, planificación de respuesta y control de los riesgos de un proyecto. Los objetivos de la

gestión de los riesgos del proyecto consisten en aumentar la probabilidad y el impacto de los eventos

positivos, y disminuir la probabilidad y el impacto de los eventos negativos en el proyecto (p.309)

Planificar la Gestión de Riesgos

Consiste en definir cómo realizar las actividades de gestión de los riesgos para un Proyecto.

Identificar los Riesgos

Consiste en determinar los riesgos que pueden afectar el Proyecto y documentar sus características

Realizar el Análisis Cualitativo de Riesgos

Consiste en priorizar los riesgos para realizar otros Evaluando y combinando la probabilidad de ocurrencia
análisis o acciones posteriores y el impacto de dichos riesgos

Realizar el Análisis Cuantitativo de Riesgos

Consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del Proyecto.

Planificar la Respuesta a los Riesgos

Consiste en desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del Proyecto.

Monitorear y Controlar los Riesgos

Esto permite identificar nuevos riesgos y evaluar la efectividad
Consiste en implementar planes de respuesta a los riesgos.
del proceso contra riesgos a través del Proyecto.

Ilustración 2 Procesos de la Gestión de los Riesgos del Proyecto

4.3 Identificar los riesgos del proyecto

Según Project Management Institute (2013) Identificar los Riesgos es el proceso de determinar los

riesgos que pueden afectar al proyecto y documentar sus características. El beneficio clave de este

proceso es la documentación de los riesgos existentes y el conocimiento y la capacidad que confiere

al equipo del proyecto para anticipar eventos (p.318)

4.3.1 Lista de riesgos identificados

ID Lista de riesgos
1 Desconocimiento del software a utilizar en la construcción de la aplicación.
2 Pérdidas de información por fallas de Hardware o Software.
3 Insatisfacción por parte del Cliente de la interfaz usuaria.
4 Necesidad de cambiar la herramienta de desarrollo durante el proyecto.
5 Mala estimación de costos de desarrollo de la aplicación.
6 Falta de recursos de hardware específicos (impresora, entre otros).
7 Número de usuarios del producto
8 Grado de seguridad en la estimación del tamaño
9 Tamaño de la base de datos creada o empleada por el producto
10 Tamaño estimado del producto en número de programas, archivos y
transacciones
11 Costos asociados por retraso en la entrega
12 Costos asociados con un producto
defectuoso
13 Limitaciones gubernamentales en la construcción del producto
14 Número de clientes que usarán este producto
15 Entiende el cliente el proceso del software
16 Problemas de comunicación entre los integrantes del equipo.
17 Falta de disponibilidad de un integrante del equipo de trabajo.
18 Inexperiencia en desarrollo de proyectos de software por parte de los
desarrolladores.
19 Falta de disponibilidad por parte del Cliente para participar en reuniones con los
desarrolladores.
20 Mal dimensionamiento del problema (el problema es más grande de lo
pensado).
21 Sobredimensionamiento de las capacidades de las herramientas a utilizar.
22 Cambio en los requerimientos.
23 Mala calendarización (estimación de plazos).
24 Falta de disponibilidad de la metodóloga en enseñanza y aprendizaje.
25 Escaso entendimiento del proceso del software por parte del Cliente.
26 Problemas de salud de algún integrante del equipo de trabajo.
27 Conflictos al interior del equipo de trabajo.
28 Abandono por parte del diseñador de apoyo en el desarrollo del proyecto.
29 Abandono definitivo por parte de algún integrante del equipo.
30 Plan de capacitación insuficiente
31 Cambio de requisitos
32 Escatimar en la calidad
33 Diseño inadecuado
34 Diferencias con los clientes
35 Cronogramas imposibles de cumplir
36 No hay una persona responsable de todo el proyecto
37 Pobre control de los cambios de diseño
38 Problemas con los miembros del equipo
39 Pobre control de los cambios de clientes
40 Prioridades del proyecto en conflicto
41 Planeamiento y control no integrados
42 Oficina de proyectos mal organizada
43 Cambios tecnológicos
44 Riesgos derivados de los procesos de diseño
ID Externos
45 Impredecibles
46 Requisitos regulatorios inesperados
47 Desastres naturales
48 Vandalismo, sabotaje o efectos secundarios impredecibles
ID Predecibles
49 Riesgos del mercado u operacionales
50 Riesgo social
51 Riesgo ambiental
52 Medios de comunicación
53 Inflación
54 Fluctuaciones en la divisa
ID Técnicos
55 Falta de recursos de Hardware específicos (impresora, entre otros).
56 Sobredimensionamiento de las capacidades de las herramientas a utilizar.
57 Plan de capacitación insuficiente
58 Cambios tecnológicos
59 Riesgos derivados de los procesos de diseño
ID Legal
60 Uso no autorizado de marcas y licencias
 61 Demandas por ruptura de contrato
62 Problemas con la fuerza laboral o el lugar de trabajo
63 Legislación

4.4 Análisis Cualitativo

Para este proceso se toma como entrada la lista de riesgos identificados y se analiza en cada una de

las fases. Se utiliza la tabla de probabilidad con cinco niveles, esta ubica el riesgo en un nivel de

ocurrencia, los cuales son raro, improbable, posible, probable, casi seguro, como se muestra en la

siguiente tabla:

Tabla 1. Niveles de Probabilidad

NIVEL DESCRIPTOR DESCRIPCION

1 Raro El evento puede ocurrir sólo en circunstancias excepcionales.

2 Improbable El evento puede ocurrir en algún momento.

3 Posible El evento podría ocurrir en algún momento

4 Probable El evento probablemente ocurrirá en la mayoría de las

circunstancias.
5 Casi seguro Se espera que en evento ocurra en la mayoría de las
circunstancias.
Fuente. Basado en la guía del PMBOK

Para medir el nivel de impacto causado por los riesgos en el momento de llegarse a realizarse, los

cuales pueden afectar directamente los objetivos del proyecto, como alcance, tiempo, costo y

calidad. Para esta establecer esta medida se utiliza la tabla de impactos donde se especifican cuatro

niveles Despreciable, Marginal, Crítico, Catastrófico, estos se muestran en la siguiente tabla.

Tabla 2. Niveles de impacto

NIVEL DESCRIPTOR DESCRIPCION

1 Despreciable Si el hecho llegara a presentarse, tendría consecuencias o

efectos mínimos.
 2 Marginal Si el hecho llegara a presentarse, tendría bajo impacto.

3 Critico Si el hecho llegara a presentarse, tendría alto impacto.

4 Catastrófico Si el hecho llegara a presentarse, tendría desastrosas

consecuencias.
Fuente. Basado en la guía del PMBOK

Para calificar cada uno de los riesgos identificados se realiza la matriz de probabilidad e impacto,

en esta se refleja la multiplicación del valor numérico del nivel de probabilidad de ocurrencia del

riesgo por el nivel numérico del impacto del riesgo sobre los objetivos, este resultado es el que

determina el nivel del riesgo.

Tabla 3. Probabilidad e Impacto.

IMPACTO
PROBABILIDAD Catastrófico
Despreciable 1 Marginal 2 Crítico 3
4
Raro 1
Improbable 2
Posible 3
Probable 4
Casi seguro 5
Fuente. Basado en la guía del PMBOK

Con base en el resultado de la matriz de probabilidad e impacto, se propone una escala numérica la

cual permite clasificar el riesgo según su nivel, estos pueden ser muy bajo, bajo, medio, alto, y muy

alto.

Tabla 4. Nivel de Riesgo

NIVEL DE RIESGO PROBABILIDAD X IMPACTO

Muy Alto >80

Alto 51- 80
 Medio 31-50

Bajo 11- 30
Muy Bajo <10
Fuente. Basado en la guía del PMBOK

Categorías
Tamaño del producto (TP)
Impacto en la organización (IO)
Tipo de cliente (TC)
Proceso de producción (PP)
Entorno de desarrollo (ED)
Tecnología (T)
Experiencia técnica (ET)

Tablas de riesgos

RIESGOS CATEGORIA PROBABILIDAD IMPACTO

1 Desconocimiento del software a
utilizar en la construcción de la ET 45% 3
aplicación.
2 Pérdidas de información por
IO 30% 3
fallas de Hardware o Software.
3 Insatisfacción por parte del
TC 25% 2
Cliente de la interfaz usuaria.
4 Necesidad de cambiar la
herramienta de desarrollo durante ED 55% 3
el proyecto.
5 Mala estimación de costos de
PP 65% 4
desarrollo de la aplicación.
6 Falta de recursos de hardware
específicos (impresora, entre T 20% 2
otros).
7 Número de usuarios del producto TP 45% 3
8 Grado de seguridad en la
TP 46% 3
estimación del tamaño
9 Tamaño de la base de datos
creada o empleada por el TP 60% 4
producto
10 Tamaño estimado del producto en
número de programas, archivos y TP 40% 3
transacciones
11 Costos asociados por retraso en la
IO 65% 4
entrega
12 Costos asociados con un producto
IO 65% 4
defectuoso
13 Limitaciones gubernamentales en
IO 50% 3
la construcción del producto
14 Número de clientes que usarán
IO 45% 3
este producto
15 Entiende el cliente el proceso del
TC 25% 2
software
16 Problemas de comunicación
ED 25% 2
entre los integrantes del equipo.
17 Falta de disponibilidad de un
ED 25% 2
integrante del equipo de trabajo.
18 Inexperiencia en desarrollo de
proyectos de software por parte ET 25% 2
de los desarrolladores.
19 Falta de disponibilidad por parte
del Cliente para participar en TC 35% 3
reuniones con los desarrolladores.
20 Mal dimensionamiento del
problema (el problema es más TP 55% 4
grande de lo pensado).
21 Sobredimensionamiento de las
capacidades de las herramientas a T 48% 3
utilizar.
22 Cambio en los requerimientos. PP 70% 4
23 Mala calendarización
PP 50% 3
(estimación de plazos).
24 Falta de disponibilidad de la
metodóloga en enseñanza y ED 45% 3
aprendizaje.
25 Escaso entendimiento del proceso
IO 45% 3
del software por parte del Cliente.
26 Problemas de salud de algún
ED 25% 2
integrante del equipo de trabajo.
27 Conflictos al interior del equipo
ED 25% 2
de trabajo.
28 Abandono por parte del diseñador
de apoyo en el desarrollo del ED 25% 2
proyecto.
29 Abandono definitivo por parte de
ED 50% 3
algún integrante del equipo.
30 Plan de capacitación insuficiente ED 25% 2
31 Cambio de requisitos PP 70% 4
32 Escatimar en la calidad PP 60% 4
33 Diseño inadecuado ET 70% 4
34 Diferencias con los clientes PP 60% 4
35 Cronogramas imposibles de
ED 70% 4
cumplir
36 No hay una persona responsable
IO 75% 4
de todo el proyecto
37 Pobre control de los cambios de
ET 55% 4
diseño
38 Problemas con los miembros del
ED 25% 2
equipo
39 Pobre control de los cambios de
ET 35% 3
clientes
40 Prioridades del proyecto en
IO 50% 3
conflicto
41 Planeamiento y control no
PP 70% 4
integrados
42 Oficina de proyectos mal
ED 35% 3
organizada
43 Cambios tecnológicos T 60% 4
44 Riesgos derivados de los
ET 50% 3
procesos de diseño
ID Externos
45 Impredecibles IO 70% 4
46 Requisitos regulatorios
IO 70% 4
inesperados
47 Desastres naturales IO 70% 4
48 Vandalismo, sabotaje o efectos
IO 70% 4
secundarios impredecibles
ID Predecibles
49 Riesgos del mercado u
IO 50% 3
operacionales
50 Riesgo social IO 50% 3
51 Riesgo ambiental IO 50% 3
52 Medios de comunicación IO 35% 3
53 Inflación IO 40% 3
54 Fluctuaciones en la divisa IO 40% 3
ID Técnicos
55 Falta de recursos de Hardware
específicos (impresora, entre T 35% 3
otros).
56 Sobredimensionamiento de las
capacidades de las herramientas T 45% 3
a utilizar.
57 Plan de capacitación insuficiente T 45% 3
58 Cambios tecnológicos T 60% 4
59 Riesgos derivados de los
T 70% 4
procesos de diseño
ID Legal
60 Uso no autorizado de marcas y
IO 50% 3
licencias
61 Demandas por ruptura de
IO 70% 4
contrato
62 Problemas con la fuerza laboral o
IO 25% 2
el lugar de trabajo
63 Legislación IO 30% 2
Planificación respuesta:

Eliminación, transferencia, mitigación, aceptación

RIESGOS Eliminaci Transferenci Mitigació Aceptación OBSERVACIONES

ón a n
1 Desconocimiento del software a
utilizar en la construcción de la
aplicación.
2 Pérdidas de información por fallas de
Hardware o Software.
3 Insatisfacción por parte del Cliente de
la interfaz usuaria.
4 Necesidad de cambiar la herramienta
de desarrollo durante el proyecto.
5 Mala estimación de costos de
desarrollo de la aplicación.
6 Falta de recursos de hardware
específicos (impresora, entre otros).
7 Número de usuarios del producto

8 Grado de seguridad en la estimación

del tamaño
9 Tamaño de la base de datos creada o
empleada por el producto
10 Tamaño estimado del producto en
número de programas, archivos y
transacciones
11 Costos asociados por retraso en la
entrega
12 Costos asociados con un producto
Defectuoso
13 Limitaciones gubernamentales en la
construcción del producto
14 Número de clientes que usarán este
producto
15 Entiende el cliente el proceso del
software
16 Problemas de comunicación entre los
integrantes del equipo.
17 Falta de disponibilidad de un
integrante del equipo de trabajo.
18 Inexperiencia en desarrollo de
proyectos de software por parte de los
desarrolladores.
19 Falta de disponibilidad por parte del
Cliente para participar en reuniones
con los desarrolladores.
20 Mal dimensionamiento del problema
(el problema es más grande de lo
pensado).
21 Sobredimensionamiento de las
capacidades de las herramientas a
utilizar.
22 Cambio en los requerimientos.
23 Mala calendarización (estimación de
plazos).
24 Falta de disponibilidad de la
metodóloga en enseñanza y
aprendizaje.
25 Escaso entendimiento del proceso del
software por parte del Cliente.
26 Problemas de salud de algún integrante
del equipo de trabajo.
27 Conflictos al interior del equipo de
trabajo.
28 Abandono por parte del diseñador de
apoyo en el desarrollo del proyecto.
29 Abandono definitivo por parte de
algún integrante del equipo.
30 Plan de capacitación insuficiente

31 Cambio de requisitos

32 Escatimar en la calidad

33 Diseño inadecuado

34 Diferencias con los clientes

35 Cronogramas imposibles de cumplir

36 No hay una persona responsable de

todo el proyecto
37 Pobre control de los cambios de
diseño
38 Problemas con los miembros del
equipo
39 Pobre control de los cambios de
clientes
40 Prioridades del proyecto en conflicto

41 Planeamiento y control no integrados

42 Oficina de proyectos mal organizada

43 Cambios tecnológicos
44 Riesgos derivados de los procesos de
diseño
ID Externos
45 Impredecibles
46 Requisitos regulatorios inesperados
47 Desastres naturales
48 Vandalismo, sabotaje o efectos
secundarios impredecibles
ID Predecibles

49 Riesgos del mercado u operacionales

50 Riesgo social
51 Riesgo ambiental

52 Medios de comunicación
53 Inflación

54 Fluctuaciones en la divisa
ID Técnicos

55 Falta de recursos de Hardware

específicos (impresora, entre otros).
56 Sobredimensionamiento de las
capacidades de las herramientas a
utilizar.
57 Plan de capacitación insuficiente
58 Cambios tecnológicos
59 Riesgos derivados de los procesos de
diseño
ID Legal
60 Uso no autorizado de marcas y
licencias
61 Demandas por ruptura de contrato
62 Problemas con la fuerza laboral o el
lugar de trabajo
63 legislación
 Conclusiones

¿Qué fue lo mejor del desarrollo de esta actividad?

Como grupo se logró ver la importancia que tiene la planificación en la implementación del

proyecto, ya que esta presenta dos fases fundamentales: Así La primera fase permitirá definir

lo que se quiere conseguir y la segunda fase planifica cómo se va a lograr.

En la primera fase del proyecto, se identifica su propósito y objetivos. Y en la segunda fase

se identifica las tareas a realizar usando estructuras de división del trabajo, estimar la

duración de dichas tareas, identificar los puntos claves en el desarrollo del proyecto.

¿Qué fue lo peor del desarrollo de esta actividad?

Lo más difícil del desarrollo de la actividad fue encontrar, el orden en que deben completarse

las tareas. Ya que se debe estar seguro de no estar abarcando demasiado, para poder contar

con el tiempo disponible, para su desarrollo.

 Referencias bibliográficas

Project Management Institute. (2013). GUÍA DE LOS FUNDAMENTOS PARA LA

DIRECCIÓN DE PROYECTOS (Guía del PMBOK). Newtown Square, Pensilvania:
Project Management Institute, Inc.
Canós, J., Penadés, M. C., y Letelier, P. (2003). Metodologías Ágiles en el Desarrollo
de Software. Presented at the VIII Jornadas de Ingeniería de Software y Bases de
Datos. [s.l.]. Recuperado el 16 de julio de 2011, de
http://201.249.238.203/portalopei/images/descargas/medesoft.pdf

Métricas de calidad y un modelo costo. beneficio ajustados a un caso real de la industria del
software [en línea] Argentina: Departamento de Informática Universidad
Nacional de San Luis. Recuperado el 16 de julio de 2011, de
http://www.costossoftware.com.