PROYECTOS EN INGENIERÍA

DE SISTEMAS

Mg. Ing. Leo Martín Chumbe Rodriguez.

 CICLO DE VIDA DE UN PROYECTO

La gestión de proyectos se puede clasificar en 5 grupos de procesos que ayudan

a guiarlo con éxito de principio a fin, según el Project Management Institute –
PMI (Instituto de Gestión de Proyectos, organización enfocada a la gerencia de
proyectos) estos son los 5 procesos:

Iniciación Planificación Ejecución Supervisión y Cierre

•Define el proyecto •¿Qué vamos a hacer? •Lanzamiento del Control •Confirma la
•Desarrolla el alcance •¿Cómo vamos a proyecto •Supervisa el aceptación del
inicial hacerlo? •Forma el equipo desempeño proyecto
•Estima los costos •¿Cómo sabremos que •Desarrolla y gestiona •Controla el programa •Documenta el
•Planifica los recursos hemos acabado? al equipo desempeño
•Identifica las personas •Explica las directrices •Recopila lo aprendido
involucradas del proyecto •Cierra contrato
•Ejecuta el plan •Libera recursos
 ENFOQUES DE LA GESTIÓN DE PROYECTOS

En la Gestión de Proyectos existen dos metodologías comunes:

1) Gestión de proyectos tradicional (en cascada)

Modelo en cascada:
• Meta y solución definida Iniciación
• Alcance y resultados claros
Planificación
Nota: Como sabes bien que hay que hacer, puedes
pasar por cada proceso una sola vez. Cuanto mas
sepas sobre el proyecto, mejor funcionará el modelo Ejecución
en cascada.
Seguimiento y Control
Proyectos candidatos para este modelo:
• Sencillo con poca incertidumbre
• Poco riesgo Cierre
• Tecnología familiar
• Recursos con experiencia
 ENFOQUES DE LA GESTIÓN DE PROYECTOS

Sin embargo, en muchos proyectos no sabes cómo va a ser la solución, y tienes

que definirla sobre la marcha, para ese tipo de proyectos se necesita un modelo
distinto.

2) Gestión de proyectos iterativa y ágil

Se utilizan iteraciones para ofrecer soluciones
parciales, pero de calidad de producción, en
intervalos regulares.
Con este modelo, el cliente obtiene antes
un valor del proyecto, además, el cliente
puede dar un “feedback” para cada parte
entregada , y eso mejora la solución
definitiva.
• Mayor intervención del cliente (que en los
proyectos tradicionales).
• Equipos pequeños e independientes (con mas
experiencia)
 ENFOQUES DE LA GESTIÓN DE PROYECTOS
2) Gestión de proyectos iterativa y ágil

Iniciación y planificación
• Define el objetivo general
• Desarrolla el plan general (luego
un plan detallado para cada iteración)

Ejecución
• Lleva a cabo cada iteración de forma
individual.
• Mas igualdad de opiniones (por los equipos
pequeños y capacitados)

Seguimiento y Control
• Supervisa y controla más de cerca
• Comunica rápidamente y con mas frecuencia

Cierre
• Cada iteración tiene su propio proceso de cierre y aceptación del producto
final.
• Si la iteración final se acepta, hacer lo necesario para final el proyecto global.
 DOCUMENTO DE VISIÓN DE UN PROYECTO DE
SOFTWARE

Como bien se menciono en la Fase de Inicio de todo

proyecto, uno de los factores bases del éxito futuro del
mismo es el dejar bien claro cual es la Visión y el Alcance
del proyecto donde quede bien enmarcado que vamos hacer
y hasta donde vamos a llegar.

Un documento de visión define el alcance y el objetivo de

alto nivel de un programa, producto o proyecto. Una
declaración clara del problema, una propuesta de solución y
las características de alto nivel de un producto ayudan a
establecer expectativas y reducir riesgos.
 DOCUMENTO DE VISIÓN DE UN PROYECTO DE
SOFTWARE

Sin un documento de visión, hay muchas posibilidades de

que diferentes partes interesadas / departamentos intenten
dirigir el desarrollo en su propia dirección, ya que los
desarrolladores quedan atrapados en el medio con un
número importante de requisitos conflictivos. Si hay un
documento de visión, entonces es más fácil decir "este
documento de visión es la dirección que acordaron todas las
partes interesadas y sus nuevos requisitos se desvían de
eso. No podemos tomarlos en consideración hasta que se
acuerde una nueva visión".
 DOCUMENTO DE VISIÓN DE UN PROYECTO DE
SOFTWARE

• La visión del producto alinea a todos los stakeholders en una dirección

común.
• La visión describe cuál es el producto y en qué eventualmente se
convertirá.
• El alcance del proyecto identifica qué porción de la visión del producto
a largo plazo realizará el proyecto.
• El enunciado de alcance establece los límites de qué está dentro y qué
queda fuera.
• El alcance define las limitaciones del proyecto.
• La visión se aplica al producto como un todo.
• El alcance pertenece a un proyecto o iteración específica que
implementará el siguiente incremento de la funcionalidad del
producto.
• El alcance es más dinámico que la visión, puesto que el administrador
se apega al contenido de cada versión dentro de su calendario,
presupuesto, recursos y restricciones de calidad.
 DOCUMENTO DE VISIÓN DE UN PROYECTO DE
SOFTWARE

• El objetivo es administrar el alcance de un

desarrollo específico o proyecto de mejora como
un subconjunto definido de la gran visión
estratégica.
• El enunciado de alcance para cada proyecto
puede aparecer en el SRS (especificación de
requisitos de software) del proyecto, en lugar de
hacerlo en un documento de visión y alcance
separado separado.
• Los grandes proyectos deberán tener un
documento de visión y alcance completo y un
SRS.
 DOCUMENTO DE VISIÓN DE UN PROYECTO DE
SOFTWARE

• Recolecta los requerimientos de nivel superior en

un documento simple que establece la etapa para
trabajo de desarrollo subsecuente.
• Algunas organizaciones crean una Cédula del
Proyecto (Project Charter) o un documento de
Caso de Negocios (Business Case) que tiene un
propósito similar.
• El propietario del documento de Visión y Alcance
es el patrocinador ejecutivo del proyecto o alguien
en un papel similar.
 ESTRUCTURA DE UN DOCUMENTO DE VISIÓN
DE UN PROYECTO DE SOFTWARE

1. Introducción
1.1 Objetivo
1.2 Alcance
1.3 Definiciones, acrónimos y abreviaturas
1.4 Referencias
1.5 Visión general
2. Posicionamiento
2.1 Oportunidad de negocio
2.2 Declaración del problema
2.3 Declaración de posición de producto
 ESTRUCTURA DE UN DOCUMENTO DE VISIÓN
DE UN PROYECTO DE SOFTWARE

3. Descripciones de la parte interesada y del

usuario
3.1 Datos demográficos del mercado
3.2 Resumen de la parte interesada
3.3 Resumen de usuario
3.4 Entorno de usuario
3.5 Perfiles de parte interesada
3.6 Perfiles de usuario
3.7 Necesidades clave de la parte interesada o
del usuario
3.8 Alternativas y competencia
 ESTRUCTURA DE UN DOCUMENTO DE VISIÓN
DE UN PROYECTO DE SOFTWARE

4. Visión general del producto

4.1 Perspectiva del producto
4.2 Resumen de capacidades
4.3 Suposiciones y dependencias
4.4 Coste y precios
4.5 Concesión de licencia e instalación
 ESTRUCTURA DE UN DOCUMENTO DE VISIÓN
DE UN PROYECTO DE SOFTWARE

5. Características del producto

5.1 Característica 1
5.2 Característica 2
6. Restricciones
7. Rangos de calidad
8. Precedencia y prioridad
9. Otros requisitos del producto
9.1 Estándares aplicables
9.2 Requisitos del sistema
9.3 Requisitos de rendimiento
9.4 Requisitos del entorno
10. Requisitos de documentación
11. Apéndice
 ESTRUCTURA DE UN DOCUMENTO DE VISIÓN
DE UN PROYECTO DE SOFTWARE

10.Requisitos de documentación
10.1 Notas de release y archivo Léame
10.2 Ayuda en línea
10.3 Guías de instalación
10.4 Etiquetado y empaquetado
11.Apéndice