mon 1

Gestin de Proyectos
Informticos

Ing. Miguel Ortiz. Mba.

mon 2
Como Obtener el Mximo
Aprovechamiento de la Charla
Tomar parte activa desde el comienzo
Dialogar
Dar al grupo el beneficio de su
experiencia y sus puntos de vista
Respetar la opinin de los demas
Evitar conversaciones privadas
Pregunte si algo no esta claro
mon 3
Objetivo del Seminario
Al finalizar el seminario el asistente
estara en capacidad de:
Aplicar conceptos de proyectos que eviten
el fracaso en su desarrollo y mejoren la
calidad de sus productos
Desarrollar proyectos tecnolgicos
aplicando tcnicas, herramientas y
metodologias administrativas
mon 4
Contenido
1. La Direccin de proyectos
2. El desarrollo de proyectos
3. La seleccin del ciclo de vida
mon 5
3. Seleccin del ciclo de vida o
modelo
3.1. !mportancia del ciclo de vida o modelo
3.2. Nodelo en cascada
3.3. Nodelo codificar y corregir
3.+. Nodelo espiral
3.5. Nodelo prototipado evolutivo
3.6. Nodelo entrega por etapas
3.7. Cascada con sub proyectos
3.8. Cascada modificado (cascada con reduccin de riesgos
S!NERGY)
3.9. Seleccin del modelo del ciclo de vida
3.10. Etapas de cualquier modelo de ciclo de vida
3.11. xito de los Sistemas de !nformacin
3.12. !ngredientes para el xito de un Sistema de !nformacin
mon 6
3.1. Importancia del ciclo de vida o
modelo
Un modelo de ciclo de vida establece el orden en que
se llevan a cabo las diversas actividades relacionadas
con el desarrollo de software. Tambin establece los
criterios que se utilizan para determinar el paso de
una actividad a otra.
Existen muchos modelos de ciclo de vida. La
seleccin del modelo adecuado para un proyecto
influye de manera decisiva en el xito del proyecto.
Un modelo adecuado de ciclo de vida permite
orientar el proyecto y ayuda a asegurar que cada
paso se acerque mas a la consecucin del objetivo
mon 7
Modelos de ciclo de vida
Cascada pura
Codificar y corregir
Espiral
mon 8
Modelos de ciclo de vida
Prototipado evolutivo
Entrega por etapas
Entrega evolutiva
mon 9
Modelos de ciclo de vida
Con fases solapadas
Cascada con subproyectos
Cascada con reduccin de
riesgos
mon 10
Modelos de ciclo de vida
Diseno por planificacin
Diseno por herramientas
Cascadas modificadas
Anlisis
Diseo
Construccin Pruebas Documentacin
Implantacin
Produccin
Mantenimiento
mon 11
3.2. Modelo en cascada
mon 12
3.2. Modelo en cascada
Es el predecesor de todos los modelos de Cv
El mas conocido
Ofrece una velocidad de desarrollo aceptable
Exige revisiones al final de cada etapa
Esta dirigido por documentos
Se usa cundo se tiene una definicin estable del
producto
Se usa con metodologias o tcnicas conocidas
Recomendado para migraciones
Los resultados tangibles son al final del Cv
Aplicable cuando se dispone de personal poco
cualificado
mon 13
3.2. Modelo en cascada
ventajas
Ayuda a localizar errores en las primeras etapas del proyecto
a un bajo costo.
Proporciona desde el inicio los requerimientos que los
desarrolladores anhelan.
Ayuda a minimizar los gastos de planificacin, porque
permite realizarla sin problemas.
Elimina una fuente comun de errores importantes,
eliminando los cambios que se pueden producir a medio
camino.
No proporciona resultados tangibles en forma de software
hasta el final del ciclo de vida, pero la documentacin que
genera proporciona indicaciones significativas del progreso
del proyecto.
mon 14
3.2. Modelo en cascada
Desventajas
Se tienen que especificar claramente, al comienzo del proyecto,
todos los requerimientos.
- En la mayoria de proyectos de software, se tiene una enorme dificultad
de especificar claramente los requerimientos al comienzo del proyecto,
antes de realizar trabajos de diseno y codificacin.
- A menudo, las personas responsables de especificar el software no son
expertos en sistemas de informacin
No permite flexibilidad en los cambios. La vuelta atras es posible,
pero dificil (modelo del salmn: se puede nadar contra corriente,
pero el esfuerzo puede matarle).
El modelo supone una cantidad muy grande de documentacin.
Si se intenta darle flexibilidad, la actualizacin de las
especificaciones se puede convertir en un trabajo a tiempo
completo.
Produce poca visibilidad para los clientes
mon 15
3.2. Modelo en cascada
Cuando usar el modelo en cascada
Cuando se tiene desde el inicio una definicin estable del producto.
Cuando se esta trabajando con metodologias tcnicas conocidas.
Cuando se construye una nueva versin bien definida de un
producto existente.
Cuando se migra un producto existente a una nueva plataforma.
En proyectos complejos que se entienden correctamente (se puede
enfrentar la complejidad de forma ordenada).
Cuando los requerimientos de calidad (caracteristicas y
prestaciones del producto) dominan sobre los requerimientos de
tiempo y costo.
Cuando se dispone de personal poco cualificado e inexperto, ya
que presenta el proyecto con una estructura que ayuda a eliminar
el esfuerzo inutil.
mon 16
3.3. Modelo codificar y corregir
mon 17
3.3. Modelo codificar y corregir
Es un modelo poco util y muy comun
Cuando no se realiza mucha planificacin
El proyecto inicia con una idea general
Se puede o no tener una especificacin formal
Usa cualquier combinacin de analisis, diseno, codificacin y pruebas
Tiene dos ventajas
No conlleva ninguna gestin (planificacin, documentacin, QA,
cumplir estandares) muestra progreso inmediatamente
Requiere poca experiencia (persona con conocimientos de
programacin)
Util para proyectos que se liquidan poco despus de ser construidos
Peligroso para proyectos grandes
mon 18
3.3. Modelo codificar y corregir
ventajas
No connlleva ninguna gestin: no se pierde tiempo en:
- planificacin,
- documentacin,
- control de calidad,
- cumplimiento de estandares,
- cualquier otra actividad que no sea la codificacin pura, por lo
cual se puede mostrar inmediatamente indicios de progreso.
Requiere poca experiencia. Cualquiera puede usarlo.
Es util cuando se trata de proyectos pequenos con productos
de corta duracin. Ejemplo:
- Programas pequenos de demostracin de conceptos
- Prototipos desechables
mon 19
3.3. Modelo codificar y corregir
Desventajas
Es peligroso para proyectos que no sean
pequenos,
No ofrece medios de evaluacin del progreso,
No proporciona medios de evaluacin de calidad o
de identificacin de riesgos,
Si en etapas avanzadas del proyecto se descubre
errores en el diseno, no queda otra solucin que
desechar el trabajo y comenzar de nuevo.
Este modelo no tiene cabida en un desarrollo
formal que requiere controles de planificacin,
costo y prestaciones.
mon 20
3.4. Modelo espiral
mon 21
3.4. Modelo espiral
Orientado o basado a riesgos
Divide un proyecto de software en mini proyectos
Cada interaccin pasa al proyecto a una escala superior
Una ventaja es que mientras los costos suben los riesgos
disminuyen
Proporciona tanto control de gestin como el cascada
Proporciona con anterioridad informacin contra cualquier
riesgo insuperable
La desventaja es muy complicado, requiere de una gestin
concienzuda atenta y con conocimientos profundos
mon 22
3.4. Modelo espiral
R!ESGO:
Requerimientos poco comprensibles
Arquitectura poco comprensible
Problemas de ejecucin importantes
Problemas con la tecnologia subyacente
Etc.
CONCEPTO:
Primera iteracin: Concepto de funcionamiento
Segunda iteracin: Requerimientos del software + validacin de
requerimientos
Tercera iteracin: Diseno del producto + validacin del diseno
Cuarta iteracin: Diseno detallado + codificacin + pruebas + entrega
PLANES:
Primera iteracin: Plan de requerimientos + plan del ciclo de vida
Segunda iteracin: Plan de desarrollo
Tercera iteracin: Plan de integracin y prueba
mon 23
3.4. Modelo espiral
ventajas
Nientras los costos suben, los riesgos disminuyen.
Cuanto mas tiempo y dinero se emplee, menores
seran los riesgos.
Proporciona tanto o mas control que el modelo en
cascada.
Proporciona a tiempo indicaciones de cualquier
riesgo insuperable (razones tcnicas o de
cualquier otra clase).
mon 24
3.4. Modelo espiral
Desventajas
Es un modelo complicado.
Requiere de una gestin concienzuda, atenta y
que exige profundos conocimientos.
Puede ser dificil definir hitos de comprobacin que
indiquen si esta preparado para pasar a la
siguiente iteracin.
Cuando un proyecto no presenta mayores riesgos
y no necesita tanta flexibilidad ni tanta gestin de
riesgos, es mejor utilizar otro modelo.
mon 25
3.5. Modelo prototipado evolutivo
mon 26
3.5. Modelo prototipado evolutivo
Desarrolla el concepto del sistema a medida que avanza el
proyecto
Normalmente se inicia desarrollando los aspectos mas visibles y
continua de acuerdo a la retroalimentacin obtenida
El desarrollador y el cliente se pone de acuerdo en que
prototipo es el mas adecuado
Se utiliza cuando:
Los requerimientos cambian con rapidez,
Cuando el cliente es reacio a especificar los requerimientos,
Cuando ni Ud. ni el Cliente identifican apropiadamente el area de
aplicacin o los requerimientos
Cuando los desarrolladores no estan seguros de la arquitectura
Gran demanda en la velocidad de desarrollo
mon 27
3.5. Modelo prototipado evolutivo
Cuando utilizar este modelo:
Cuando los requerimientos cambian con rapidez,
Cuando el cliente es reacio a especificar el conjunto de
requerimientos,
Cuando ni el desarrollador ni el cliente logran identificar de
forma apropiada las caracteristicas finales del software,
Cuando existe una gran demanda de velocidad de desarrollo
y visibilidad,
Cuando los desarrolladores pueden tener interacciones
frecuentes e informales con los usuarios finales.
En sistemas pequenos. En sistemas grandes se justifica el
costo de creacin de prototipos desechables, que eliminan
muchos de los riesgos del prototipado evolutivo.
mon 28
3.5. Modelo prototipado evolutivo
Cuando utilizar este modelo:
A diferencia del modelo COD!F!CAR y CORREG!R, incluye
analisis de requerimientos, diseno real, y cdigo pensado
para el mantenimiento real, en niveles ligeramente inferiores
a los que se utilizan en otros modelos como CASCADA.
Es clave decidir al comienzo del proyecto si se va a
desarrollar el prototipo hasta convertirlo en producto final o
se lo va a desechar.
En este modelo se vuelve mas critica la labor de gestin de
los requerimientos (control de cambios), pues la
realimentacin de los usuarios y clientes puede dirigir el
proyecto a una direccin inesperada, tergiversando el diseno
y adaptandolo sin volver a hacer un diseno completo.
mon 29
3.5. Modelo prototipado evolutivo
ventajas
Los clientes pueden ver signos firmes de progreso y tienden
a ponerse menos nerviosos que con el uso de otros
modelos.
Puede modificarse de manera inmediata en respuesta a la
realimentacin del cliente y del usuario final.
Nejora la moral de usuarios finales, clientes y
desarrolladores porque el progreso es visible.
Realimentacin temprana sobre la aceptacin del producto.
Curvas de esfuerzo mas suaves, reduciendo la presin de la
fecha limite.
mon 30
3.5. Modelo prototipado evolutivo
Desventajas
!mposibilidad de conocer, al comienzo del
proyecto, lo que se tardara en crear un producto
aceptable.
No se sabe cuantas iteraciones se tendran que
realizar.
Este modelo puede convertirse facilmente en una
excusa para realizar el desarrollo con el modelo de
codificar y corregir.
Cuando el protototipo se desarrolla de forma
extremadamente rapida, a veces tambin se
desarrolla de forma extremadamente descuidada.
mon 31
3.6. Entrega por etapas
mon 32
3.6. Entrega por etapas
El software no se entrega cliente al final del proyecto y de una
sola vez, sino que se entrega por etapas sucesivas a lo largo del
proyecto.
A diferencia del modelo de prototipado evolutivo, en este
modelo se conoce exactamente qu es lo que se va a construir
cuando se procede a construirlo.
Si se planifica cuidadosamente las etapas, es posible entregar
las prestaciones mas importantes al principio, y los clientes ya
pueden comenzar a usar el software en ese punto.
Hay que asegurarse que las etapas que se planifican primero
son significativas para el cliente.
Hay que asegurarse de que se han tenido en cuenta todas las
dependencias tcnicas entre los diferentes componentes del
producto.
mon 33
3.6. Entrega por etapas
vENTAJAS:
Proporciona signos tangibles de progreso en el
proyecto, lo cual es valioso para mantener la
presin de tiempo a un nivel apropiado.
DESvENTAJAS:
No funciona sin una planificacin adecuada, tanto
para el nivel de gestin como para el nivel tcnico.
Un problema comun en este modelo es planificar
el desarrollo de un componente para una etapa
tardia, y luego descubrir que un componente
planificado para una etapa previa no puede
trabajar sin l.
mon 34
3.6. Entrega por etapas
Cuando usar este modelo
En proyectos largos, en los cuales se debe forzar la visibilidad.
Cuando se esta seguro de las prestaciones que debe tener el
producto. Si tiene dudas sobre algunos aspectos significativos, no
utilice este modelo.
Solo funciona bien en sistemas en los que se puede desarrollar
independientemente subconjuntos utiles del producto.
Cuando sea vital entregar algo util tan pronto como sea posible.
Cuando no haya una certeza de la continuidad de
financiamiento. Al final de cada etapa usted y sus clientes
pueden examinar el presupuesto y determinar si pueden
afrontar la siguiente etapa.
mon 35
3.7. Cascada con sub proyectos
mon 36
3.7. Cascada con sub proyectos
Nuchos sistemas de software presentan algunas areas
que hemos implementado muchas veces con anterioridad
y que no incluyen sorpresas.
cPor qu retrasar la implementacin areas que son faciles
de disenar por esperar a terminar el diseno de un area
dificil
Si la arquitectura ha dividido el sistema en subsistemas
lgicamente independientes, se puede tener proyectos
separados, cada uno avanzando a su propio ritmo.
El riesgo de este modelo es la presencia de
interdependencias imprevistas. En este caso ayuda
eliminar dependencias durante le diseno de la
arquitectura, o esperar hasta despus del diseno detallado
para dividir el proyecto en subproyectos
mon 37
3.8. Cascada modificado (cascada
con reduccin de riesgos SINERGY)
Anlisis
Diseo
Construccin Pruebas Documentacin
Implantacin
Produccin
Mantenimiento
mon 38
3.8. Cascada modificado (cascada
con reduccin de riesgos SINERGY)
Requiere la definicin completa de los
requerimientos antes de comenzar el diseno
Obliga a finalizar el diseno antes de iniciar la
construccin
Coloca el espiral en las etapas mas criticas
Permite realizar paralelamente a la
construccin las pruebas y documentacin
mon 39
3.9. Seleccin del modelo del ciclo
de vida
No existe un modelo mejor o peor. Depende del
contexto en el que se utilicen y depende de cmo se
los utilice.
Los factores mas importantes a analizar para
seleccionar el modelo de ciclo de vida son:
cEs posible obtener una descripcin completa de
requerimientos al inicio del proyecto?
cComprendo bien la arquitectura del producto o considero
que se debera modificar de manera importante durante el
proyecto?
cCuanta fiabilidad necesito en el sistema al momento de
entregarlo?
cCuanta facilidad necesito dar al sistema para ser modificado
en tamano y funcionalidad durante su tiempo de vida?
mon 40
3.9. Seleccin del modelo del ciclo
de vida
cTengo presiones de tiempo. Fecha de entrega
inamovible?
cNecesito realizar modificaciones a medio camino?
cCuanta visibilidad para los clientes necesito darle
al proyecto?
cCuanta visibilidad para los directivos necesito
darle al proyecto?
cCuanta sofisticacin (nivel de educacin y
formacin) se necesita para usar el modelo?
mon 41
3.10. Etapas de cualquier modelo
ciclo de vida
Analisis de Sistemas
Objetivos
Efectuar el analisis del sistema para modelar los
requeriminetos del negocio antes de proceder con
el desarrollo de la aplicacin
Desarrollar los modelos del analisis
Productos
Especificaciones del sistema
Nodelos del analisis
Diccionario de datos
mon 42
3.10. Etapas de cualquier modelo
ciclo de vida
Diseno de Sistemas
Objetivos
Trazar los planos de la aplicacin a construir
Crear y mantener los disenos de la base de datos
en base a los modelos de datos desarrollados en
el analisis
Crear y mantener los disenos de las aplicaciones
en base al diseno de la BD y a los modelos
funcionales
Crear y mantener los disenos arquitectnicos
mon 43
3.10. Etapas de cualquier modelo
ciclo de vida
Diseno de Sistemas (2)
Productos
Esquema de la base de datos
Lgica de los mdulos de la aplicacin
Ndulos de la aplicacin y los datos
Estructura de los mdulos de la aplicacin
Especificaciones visuales y otras
caracteristicas de la aplicacin
mon 44
3.10. Etapas de cualquier modelo
ciclo de vida
Construccin
Objetivos
Creacin de la base de datos
Creacin de los programas de la aplicacin
incluyendo la codificacin de la lgica y controles (
DB e interfase)
Productos
DB
!nterfase de usuario, reportes, consultas, menus
Librerias de cdigos (DB e interfase)
Librerias de instalacin
mon 45
3.10. Etapas de cualquier modelo
ciclo de vida
Documentacin
Objetivo
Desarrollo de la documentacin de
operacin, tcnica y de uso del sistema
Productos
Nanual de operacin del sistema
Nanual de uso de la aplicacin
Nanual tcnico del sistema
mon 46
3.10. Etapas de cualquier modelo
ciclo de vida
Pruebas
Objetivo
Efectuar pruebas a la aplicacin desarrollada
Entregar la aplicacin al usuario de acuerdo a las
especificaciones funcionales
Productos
Puebas de ingenieria unitarias e integrales
Pruebas de usuario de validacin alfa y beta
mon 47
3.10. Etapas de cualquier modelo
ciclo de vida
!mplantacin
Objetivo
!nstalacin de la aplicacin y puesta en marcha
Productos
!nstalacin de Hardware y Software nesesarios
Usuarios y tcnicos entrenados
Datos iniciales cargados yfo migrados
Asistencia al usuario
Nonitoreo del sistema
mon 48
3.10. Etapas de cualquier modelo
ciclo de vida
Produccin
Objetivo
Asegurar el funcionamiento con un minimo de
problemas y con un minimo de intervencin del
equpo de soporte y operacin
Productos
Servicio Operacional (Tiempo de operacin)
Soporte tcnico
Atender requisiciones de usuarios
Seguimiento y revisin del rendimiento
Futuro del sistema
mon 49
3.10. Etapas de cualquier modelo
ciclo de vida
Nantenimiento
Objetivo
Proveer servicios de mantenimiento a la
aplicacin
Productos
Nantenimineto correctivo
Nantenimiento adaptivo
mon 50
3.11. xito de los Sistemas de
Informacin
Neta de un S!
Contribuir al xito de sus usuarios xito
institucional
El xito del desarrollo f compra de un
S! se mide en base a:
Tenerlo en produccin en los tiempos
esperados
Exactitud con la que el sistema cumple con
los requerimientos del usuario.
mon 51
Un S! exitoso debe ser:
Orientado por el negocio
Desarrollado rapidamente
Flexible
Confiable
3.11. xito de los Sistemas de
Informacin (2)
mon 52
3.12. Ingredientes para el xito
de un Sistema de Informacin
Soporte y Compromiso Gerencial
Presupuesto
Netodologia (disciplina)
Administracin del proyecto
Equipos de desarrollo calificados
(tcnicos y usuarios)
Herramientas