Curso - GestiónProyectos 2012

Programa
OBJETIVOS:
Conocer los fundamentos y conceptos de la Teora de Sistemas. Entender la importancia de los sistemas de informacin en las organizaciones. Conocer la metodologa tradicional de desarrollo de sistemas. Introducir en nuevos modelos de desarrollo.
Programa
CONTENIDOS:
Teora de Sistemas Control y Sistemas de Informacin Organizaciones modernas Formulacin de Proyectos y Su Ciclo de Vida Introduccin al uso de Modelos en el desarrollo de Sistemas
Formulacin de Proyectos y Su Ciclo de Vida

1.0 Introduccin 1.1 Roles, recursos y restricciones. 1.2 Ciclo de vida del subcontrato y de la etapa de soporte. 1.3 Identificacin de riesgos. 1.4 Formalizacin y validacin del plan de subcontrato. 1.5 Estimacin de costos y tiempo. 1.6 Actividades y criterios para evaluacin de propuestas. 1.7 Criterios de satisfaccin de requerimientos. 1.8 Verificacin de la comprensin de requerimientos.
Introduccin
Qu es un proyecto?
Un proyecto consiste en reunir varias ideas para llevarlas a cabo, es un emprendimiento que tiene lugar durante un tiempo limitado, presupuesto definido y que apunta a lograr un resultado nico.
Surge como respuesta a una necesidad

El proyecto finaliza cuando se obtiene el resultado deseado, y se puede decir que colapsa cuando desaparece la necesidad inicial o se agotan los recursos disponibles.
Introduccin
Qu es un proyecto?
Un proyecto es una planificacin que consiste en un conjunto de actividades que se encuentran interrelacionadas y coordinadas. La razn de un proyecto es alcanzar objetivos especficos dentro de los lmites que imponen un presupuesto, calidades establecidas previamente y un lapso de tiempo previamente definido. La gestin de proyectos es la aplicacin de conocimientos, habilidades , herramientas y tcnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto.
Introduccin
Qu es un proyecto informtico?
Es el enfrentamiento de un problema del negocio Con nfasis en el manejo de la informacin como un activo diferenciador Cualquier iniciativa orientada a fortalecer el manejo de informacin: Estructurada / consistente, Dimensionada (recursos, riesgo), Evaluable, Para un cliente
Introduccin
Ejemplos de proyectos
Desarrollo de un sistema Seleccin de una aplicacin Implantacin de un producto Establecimiento de una plataforma Migracin de una plataforma
Introduccin
Un proyecto informtico implica:

un problema que debe ser solucionado un contexto una forma de solucin
Programa
1.0 Introduccin 1.1 Roles, recursos y restricciones. 1.2 Ciclo de vida del proyecto. 1.3 Identificacin de riesgos. 1.4 Formalizacin y validacin del plan de subcontrato. 1.5 Estimacin de costos y tiempo. 1.6 Actividades y criterios para evaluacin de propuestas. 1.7 Criterios de satisfaccin de requerimientos. 1.8 Verificacin de la comprensin de requerimientos.
1.1 Roles, recursos y restricciones
1. Cada proyecto requiere contar con un jefe de proyecto experimentado, que sea responsable por:
las actividades de planificacin del proyecto, el seguimiento de contratos y de actividades, la puesta en marcha y transicin a soporte. Por experiencia se entiende el que haya participado en la planificacin de al menos un proyecto, tener al menos 5 aos de experiencia en subcontratos, tener experiencia en el dominio de aplicacin, tener conocimiento de tecnologas e ingeniera de procesos, etc.
2. Si el proyecto se va a subcontratar, es necesario contar con un encargado del proceso y de la seleccin de propuestas.
Tambin es necesario contar con soporte en la administracin de contratos, internos o de la empresa.
3. Para desarrollo interno o subcontratacin, es necesario un equipo o persona que desarrolle las actividades del proyecto.
4. Tambin hay un grupo que se ve afectado por el proyecto.

El jefe de proyecto debe identificar a todas las personas y roles que se ven afectados por el proyecto. Ejemplos: usuarios finales, ingenieros de sistemas, evaluadores de proyectos, soporte organizacional, SQA, administrador de configuracin, expertos en el dominio de la aplicacin, equipos de prueba, grupos de ingeniera de software.
5. Segn sea la complejidad del proyecto, puede requerirse un equipo especfico que desarrolla y administra los requerimientos, as como un revisor externo al equipo del proyecto.

6. El proveedor tambin debe ser considerado como parte integrante del equipo de trabajo. Adems, para evaluar los resultados puede constituirse otro grupo de trabajo:
Evaluadores independientes, Usuarios finales, Soporte, Ingeniera de software y sistemas, Miembros del grupo que desarroll los requerimientos y la gestin.
En la conformacin de los equipos de trabajo es importante tener claridad sobre:

su formacin la experiencia sus habilidades tcnicas las habilidades sociales sus expectativas sus debilidades y conflictos
Adems, se debe determinar una estrategia de administracin del equipo y la disponibilidad de recursos asociados, como capacitacin.
Para la ejecucin exitosa del proyecto se requiere contar con los recursos adecuados:
Fondos suficientes para la operacin interna, subcontratos, desarrollo, soporte. Equipo de profesionales con preparacin necesaria para abordar las responsabilidades del proyecto. Equipamiento adecuado para desarrollar las actividades del proyecto. Herramientas.
Las herramientas para apoyar el desarrollo de un proyecto pueden incluir:

Herramientas de productividad Herramientas para gestin de configuracin Herramientas para apoyar la trazabilidad Herramientas para anlisis lxico Herramientas para modelamiento de la especificacin Herramientas para gestin de la evaluacin Herramientas para prototipar ...
Programa
1.2 Ciclo de vida del proyecto.

F. Evaluacin y medicin de resultados. G. Diseo de la evolucin del proyecto. A. Identificacin de un problema y concepcin del proyecto. E. Puesta en marcha. D. Ejecucin y administracin.
Proyecto
C. Formulacin del proyecto. B. Evaluacin de alternativas.
1.2 Ciclo de vida del proyecto: Identificacin de un problema...
Caracterizacin del problema

El problema se caracteriza por los perjuicios o beneficios implcitos (oportunidades o amenazas). No interesa el cmo. No confundir con la caracterizacin o evaluacin del proyecto. Habr una transicin que ser necesario manejar en el proyecto. La caracterizacin del problema incluye: (1) Una situacin por modificar, (2) Objetivos, (3) Efectos, y (4) Participantes.
Caracterizacin del problema desde la situacin por modificar

Lo primero es determinar si es posible eliminarla, es decir, hacer que deje de ser un problema. Si no se puede eliminar, entonces:
Realizar una descripcin neutra de la situacin actual Dimensionarla en costo, complejidad, importancia, riesgos, etc.
La caracterizacin debe incluir:

mbito Nivel de criticidad Responsabilidades Participantes Localidades Entidades (datos) Procesos Transacciones Condiciones (de operacin) Lmites del problema
Caracterizacin del problema desde el objetivo

Caracterizado por un conjunto de requerimientos
con ciertos rangos de flexibilidad de diversa naturaleza
Que tendr efectos en el negocio, los procesos, la infraestructura, las personas, ...
Caracterizacin del problema desde los efectos

Positivos y negativos Esperados e inesperados En distintos mbitos:
Dinero, poder, seguridad, sobrevivencia, personas, ...
Cmo evaluar / cuantificar cada efecto ...a priori?
Caracterizacin del problema desde los participantes

Dueo Beneficiados Perjudicados Participantes que se incorporan o excluyen Otros afectados (organismo regulador, sindicato, ...)
Caracterizacin del contexto del problema y del proyecto

Negocio Condiciones del mercado o regulatorias Estrategia de la empresa Capacidades Infraestructura / arquitectura (organizacional, plataforma, ...) Restricciones de recursos Estado del arte Coyuntura (circunstancias actuales) Otras restricciones ...
Caracterizacin de la solucin
Forma de solucin Evaluacin de alternativas Formulacin del proyecto Ejecucin y administracin Evaluacin / medicin de resultados Formulacin de la evolucin Previamente debe contarse con:
Estrategia informtica Definicin y establecimiento de arquitectura Determinacin, priorizacin y planificacin de cartera de proyectos
Nota 1: Estrategia
Conjunto de principios que permiten alinear las decisiones, facilitar el proceso de toma de decisiones y aumentar el valor del conjunto de ellas.
Nota 2: Arquitectura
Elementos que constituyen la plataforma de procesamiento de informacin de la organizacin: Hw, Sw, Aplicaciones, Comunicaciones, Modelo de Datos, Servicios, Protocolos, Estructura de Transacciones, Reglas de Validacin.
Nota 3: Plan Informtico
Conjunto de proyectos (de distinta naturaleza) evaluados y estructurados, que permiten mover a la organizacin y el negocio desde un estado dado a otro de mayor valor.
2. Evaluacin de alternativas.
Desarrollo interno. Compra de solucin de mercado. Subcontrato del desarrollo.
3. Formulacin del proyecto.

Planificacin del proyecto. Formulacin de la solicitud para contrato y mecanismo de evaluacin de propuestas.
4. Ejecucin y administracin.
Segn la alternativa elegida, la ejecucin puede consistir en requerimientos, diseo, codificacin, pruebas; o tratarse del seguimiento y control de una compra o desarrollo subcontratado.
5. Puesta en marcha.
Debe considerar los efectos sociales de la introduccin de una nueva forma de trabajar. Se requiere planificar las actividades de capacitacin, marcha blanca y entrada en operacin.
6. Evaluacin y medicin de resultados.

El producto soluciona el problema como se esperaba? Es usado? El proyecto pudo ser administrado de mejor manera? Las estimaciones fueron certeras?, Cul es la variacin con respecto a lo esperado?
7. Diseo de la evolucin del proyecto.

Paso a soporte y mantencin. Nuevos proyectos asociados.
Consideraciones estratgicas en el ciclo de vida del proyecto
Objetivos del proyecto sinrgicos con la visin del negocio. Restricciones Consistencia con la estrategia de adquisicin de sistemas Identificacin de los riesgos Ciclo de vida para la instalacin y soporte Leyes, regulaciones y polticas aplicables Las actividades realizadas son proporcionales al costo o complejidad del proyecto
Programa
1.3 Identificacin de riesgos.
Antes de comenzar la ejecucin del proyecto es necesario identificar:

Posibles riesgos Causas y nivel de manejo Probabilidad de ocurrencia Costo del riesgo Medidas de precaucin
La evaluacin del riesgo tiene tres etapas, ellas son:

Identificacin del riesgo, anlisis del riesgo, y priorizacin del riesgo.
Una vez priorizados se deben definir medidas de control. Dicho control tiene tres etapas:
Planificacin de la administracin del riesgo, modelamiento del riesgo, y monitoreo del riesgo.
Cmo se administran los riesgos?
Primero, se hace una evaluacin del riesgo.
Qu problemas pueden empezar a dominar los esfuerzos del proyecto? Cules son los ms crticos? Qu acciones puedo tomar para eliminarlos o evitarlos?
Segundo, se efectan las acciones para controlarlos.

Cul es mi plan para eliminar los riesgos? Qu tan bien estoy eliminando los riesgos?

Por qu la administracin del riesgo es importante? La mayor parte de los desastres en software se deben a la falta de manejo del riesgo en forma objetiva.
Los retrasos en la entrega del producto Los presupuestos sobrepasados Proyectos descontinuados Productos que no satisfacen las necesidades del usuario
La taxonoma de riesgos de software definida por el SEI (Software Engineering Institute - Carnegie Mellon University) est organizada en tres grupos:
Ingeniera de productos: Aspectos tcnicos del trabajo a ser realizado. Ambiente de desarrollo: Los mtodos, procedimientos y herramientas a usar para desarrollar el producto. Restricciones de programa: Factores contractuales, organizacionales y operacionales en los cuales el software es desarrollado pero que estn fuera de control directo del proyecto.

Ingeniera de productos: Requerimientos Objetivo Identificar y evaluar los riesgos relacionados con requerimientos sobre el producto final, en relacin tanto a la calidad de la especificacin como a la dificultad de implementar un sistema que los satisfaga, tanto desde el punto de vista de un desarrollo interno como subcontratado.

Ingeniera de productos: Requerimientos
Discutir la definicin, anlisis y gestin de requerimientos (explcita e implcita) Detectar requerimientos que son tcnicamente difciles o imposibles de implementar Evaluar la habilidad para negociar requerimientos, revisar presupuestos y programacin tras un anlisis inadecuado de requerimientos

Ingeniera de productos: Diseo y produccin Objetivo Identificar y evaluar riesgos relativos al desarrollo de software en s, desde los requerimientos, pasando por diseo, codificacin y pruebas unitarias, hasta integracin y pruebas de aceptacin.

Ingeniera de productos: Diseo y produccin
Evaluar la factibilidad de diseo de los algoritmos, requerimientos funcionales o de desempeo, e interfaces internas y externas Evaluar la dificultad de trabajar con requerimientos no comprobables, o sin considerar las caractersticas de las pruebas durante el diseo Evaluar la calidad y estabilidad de las especificaciones del software e interfaces, y limitaciones que puedan acarrear dificultades en la implementacin Evaluar si la integracin y pruebas consideran planificacin, ejecucin e instalacin para la integracin del producto en el ambiente de explotacin

Ambiente de desarrollo Objetivo Identificar y evaluar los riesgos relativos al ambiente de desarrollo usado para el proyecto.

Ambiente de desarrollo
Evaluar las herramientas de hardware y software usadas en desarrollo de productos Evaluar el equipamiento de soporte usado en desarrollo de productos Evaluar el uso de herramientas CASE, simuladores, compiladores, equipamiento de prueba y servidores

Ambiente de desarrollo: Proceso de desarrollo Objetivo Identificar y evaluar riesgos relativos al proceso de desarrollo adoptado para realizar el proyecto y, por otro lado, satisfacer los requerimientos del cliente. Entenderemos por proceso a la secuencia de pasos - entradas, salidas, acciones, criterios de validacin y actividades de monitoreo - desde la especificacin inicial de requerimientos hasta la entrega final del producto.

Ambiente de desarrollo: Proceso de desarrollo
Identificar el uso de fases, tales como anlisis de requerimientos, definicin de productos, desarrollo del producto o funcionalidad, pruebas y entrega Identificar tanto los procesos de gestin (ej. costeo, planificacin, seguimiento y asignacin de personal) como los procesos especficos del proyecto (estudios de factibilidad, revisiones de diseo y pruebas de regresin) Identificar y evaluar riesgos derivados de una mala definicin, planificacin y documentacin de actividades relativas al proceso, o de un proceso inadecuado para las caractersticas del proyecto, o pobremente comunicado y carente de apoyo

Ambiente de desarrollo: Administracin Objetivo Identificar y evaluar riesgos relativos a la forma de administrar proyectos y, a un nivel ms general, la forma de administrar de la organizacin donde el proyecto se realizar, y hasta dnde el proyecto puede afectarse por ella.

Ambiente de desarrollo: Administracin
Identificar y evaluar los riesgos asociados con la administracin del personal del proyecto Evaluar aspectos relativos al ambiente de trabajo Evaluar aspectos subjetivos del ambiente tales como:
Preocupacin por asegurar que el personal est bien informado El modo en que la gente trabaja junta Sensibilidad a las opiniones del personal

Ambiente de desarrollo: Personal Objetivo Identificar y evaluar los riesgos relativos al personal de la organizacin, directa o indirectamente involucrado en la realizacin del proyecto.

Ambiente de desarrollo: Personal
Identificar el ambiente de trabajo y restricciones del programa en trminos de personal Identificar y evaluar aspectos subjetivos del ambiente tales como:
Preocupacin por asegurar que el personal est bien informado El modo en que la gente trabaja junta Sensibilidad a las opiniones del personal La actitud y motivacin del personal
Identificar y evaluar dependencias y experiencia, habilidades y estabilidad del personal

Restricciones de programa: Externas Objetivo Identificar y evaluar los riesgos asociados a factores que afectan al proyecto, para los cuales el equipo del proyecto tiene poco o ningn control.

Restricciones de programa: Externas
Identificar y evaluar factores que puedan estar fuera del control del proyecto, pero que pueden tener un efecto importante en su xito Identificar fuentes externas importantes de riesgo, tales como:
Disponibilidad de personal Tipo de acuerdo o contrato Restricciones Dependencias Interfaces del proyecto con el cliente o
Programa
1.4 Formalizacin y validacin del plan de subcontrato.
El proceso de subcontrato conlleva las siguientes etapas:

Estimacin de costos y tiempo Solicitud Identificacin del riesgo y seguimiento Gestin del proyecto Desarrollo y administracin de requerimientos Seguimiento y control de contratos Evaluacin Transicin a soporte

Se debe establecer una instancia para resolucin de problemas, facilitar las decisiones de adquisicin, enfocarse en temas crticos, y manejar el riesgo. Las responsabilidades y cuentas deben estar claramente establecidas para el proyecto. Normalmente, a menor riesgo del proveedor, ms rgido es el contrato.
Cobertura del contrato:
Objetivos del proyecto y del contrato, espritu y participantes Restricciones del proyecto Disponibilidad de activos y tecnologas Mecanismos para subcontratos Tipos potenciales de contratos y trminos Consideraciones sobre los usuarios finales
Identificacin de riesgos Aproximacin al ciclo de vida del producto Medios, plazos Hitos, montos y flujos Formas de suspender, cerrar, ampliar, modificar, resolver conflictos Responsabilidades legales, garantas, evolucin
Recomendaciones sobre el documento:

claridad secciones nmeros de pgina cuerpo simple con anexos simplicidad en las referencias evitar redundancias
Programa
1.5 Estimacin de costos y tiempo.
Aun cuando el proyecto sea subcontratado, es conveniente realizar una estimacin de los recursos necesarios, para evaluar las ofertas y determinar el grado de cumplimiento de las actividades. Tcnicas:
Dimensionamiento con Puntos por Funcin (FPA), Albrecht, 1979. Dimensionamiento con COnstructive COst Model (COCOMO), Boehm 1981.
1.5 Estimacin ... Dimensionamiento con Puntos por Funcin (FPA).
Dimensionamiento del trabajo segn:

Entradas externas: Informacin que viene desde fuera de la aplicacin.

Salidas externas: Informacin que cruza los lmites internos y externos de la aplicacin, que contiene informacin derivada o actualizada por archivos lgicos internos.

Consultas externas: Informacin que cruza los lmites internos y externos de la aplicacin, que no contienen informacin derivada o actualizada en un archivo lgico interno.

Archivos lgicos internos: Un grupo identificable por el usuario de datos lgicamente relacionados, que residen enteramente en los lmites de la aplicacin y se mantienen a travs de entradas externas.

Archivos de interfaces externas: Un grupo identificable por el usuario de datos lgicamente relacionados, que es usado slo para propsitos de referencia.
1.5 Estimacin ... Dimensionamiento con Puntos por Funcin (FPA). Estos aspectos se evalan en magnitud
y complejidad. Se produce posteriormente un proceso de ajuste basado en 14 caractersticas generales. Cada punto de funcin tiene distinto costo (en horas) en cada lenguaje / ambiente. Tambin puede calcularse el costo en puntos por funcin para proyectos de mantencin o ampliacin.
1.5 Estimacin ... Dimensionamiento FPA.
Caractersticas generales de ajuste

Uso de comunicacin Datos distribuidos Performance Alta utilizacin Nivel transaccional Ingreso de datos en lnea Eficiencia para el usuario
Actualizacin en lnea Complejidad de procesamiento Reusabilidad Facilidad de instalacin Facilidad de operacin Uso en mltiples localidades Facilidad de cambio
1.5 Estimacin ... Dimensionamiento con COnstructive COst Model.
Estimacin experimental del dimensionamiento para desarrollo. MM = 2.4 KDSI1.05

MM: Man-Months KDSI: K Delivered Source Instructions
TDEV = 2.5 MM 0.38

TDEV: Time of Development (meses)
1.5 Estimacin ... Dimensionamiento COCOMO.
Perfil tpico de proyecto
Tamao Esfuerzo Productiv. Schedule Staff [KDSI] [MM] [DSI/MM] [Meses] [FSP] Chico 2 5.0 400 4.6 1.1 Mediano 8 21.3 376 8.0 2.7 Medio 32 91.0 352 14.0 6.5 Grande 128 392.0 327 24.0 16.0
1.5 Estimacin ... Dimensionamiento COCOMO
Distribucin de fases del proyecto (proyecto medio) Esfuerzo
Fase Schedule Diseo de producto 19 Programacin Diseo detallado Codif. + prueba unit. Integracin y prueba
16
62 55
24 38
22 26
Programa
1.0 Introduccin 1.1 Roles, recursos y restricciones. 1.2 Ciclo de vida del proyecto. 1.3 Identificacin de riesgos. 1.4 Formalizacin y validacin del plan de subcontrato. 1.5 Estimacin de costos y tiempo. 1.6 Actividades y criterios para evaluacin de propuestas. 1.7 Criterios de satisfaccin de requerimientos. 1.8 Verificacin de la comprensin de
1.6 Actividades y criterios de evaluacin de propuestas.
Los requerimientos tcnicos, no tcnicos, de producto y de la evaluacin, son incorporados en la solicitud y en el contrato resultante. Es conveniente preparar una estimacin de los costos y plazos del proyecto que se va a subcontratar, y pedir una revisin independiente, comprensiva y realista, a un observador no involucrado en dicho proyecto. Las propuestas deben ser evaluadas segn el plan establecido.
1.6 Actividades y criterios de evaluacin de propuestas.
El responsable de la decisin toma en cuenta los resultados de las evaluaciones para elegir a un proveedor.
Programa
1.0 Introduccin 1.1 Roles, recursos y restricciones. 1.2 Ciclo de vida del proyecto. 1.3 Identificacin de riesgos. 1.4 Formalizacin y validacin del plan de subcontrato. 1.5 Estimacin de costos y tiempo. 1.6 Actividades y criterios de evaluacin de propuestas. 1.7 Criterios de satisfaccin para requerimientos. 1.8 Verificacin de la comprensin de requerimientos.
1.7 Criterios de satisfaccin de requerimientos.
En la definicin de los criterios de satisfaccin de requisitos es deseable:
Precisin, es decir, no tener requisitos ambiguos. Enunciado gramaticalmente correcto. Consistencia tcnica (consigo mismo y con otros requisitos). Consistencia en su terminologa. Comprobable, es decir, que se puede probar en un tiempo finito y a un costo factible. Ausencia de trminos indefinidos Con referencias explcitas Carente de referencias ulteriores
1.7 Criterios de satisfaccin de requerimientos.
En la definicin de los criterios de satisfaccin de requisitos es deseable:(cont.):

Completitud. Todos los aspectos que tienen que ser descritos lo son y nada se ha dejado de colocar por obvio que sea. Trazabilidad.- Los requisitos pueden ser trazados desde los Requisitos del Sistema hacia la implementacin como en la direccin inversa. Organizacin lgica. Carencia de detalles de diseo e implementacin.
Programa
1.0 Introduccin 1.1 Roles, recursos y restricciones. 1.2 Ciclo de vida del proyecto. 1.3 Identificacin de riesgos. 1.4 Formalizacin y validacin del plan de subcontrato. 1.5 Estimacin de costos y tiempo. 1.6 Actividades y criterios de evaluacin de propuestas. 1.7 Criterios de satisfaccin para requerimientos. 1.8 Verificacin de la comprensin de requerimientos.
1.8 Verificacin de la comprensin de requerimientos.
El equipo del proyecto debe ejercer acciones para asegurar el mutuo entendimiento de los requisitos de contrato con el proveedor seleccionado, antes de firmar el contrato. Los problemas de comprensin se originan por tres motivos:
Diferencias de formacin/lenguaje Grado de formalidad inadecuado para algunos grupos Magnitud del sistema.
Caractersticas no deseables:
Existencia de ruido. Datos que sin aportar nueva informacin slo pueden causar confusin. Silencios. El no describir una faceta del problema que debe ser tratado. Especificaciones excesivas. El tener una descripcin de facetas de una posible solucin. Contradicciones. El tener dos o ms requisitos en conflicto entre ellos. Ambigedad. Presencia de texto que se presta para dos o ms interpretaciones.
Caractersticas no deseables (cont.):

Referencias ulteriores. Descripcin de elementos en base a una explicacin que se hace ms adelante en el documento. Creer que se puede hacer algo sin tener idea de la factibilidad. Requisitos no comprobables. Requisito que no se puede comprobar debe reescribirse de forma de poder tener una prueba objetiva o eliminarse por completo.
Se usan trminos como: generalmente, tpicamente, usualmente, detallado, apropiado, amigable, adecuado, como requerido, necesario, vlido, razonable, preciso, completo, ptimo? Si es as, hay una definicin cuantificada y comprobable de esos trminos?

Se debe usar la misma palabra o trmino en forma repetitiva para evitar confusiones. Existen trminos tcnicos o del entorno de la aplicacin que no han sido definidos? Han sido definidos todos los acrnimos y abreviaciones? El requisito no debe poder dividirse en dos o ms requisitos. Conviene usar tablas o cuadros para describir el comportamiento requerido.

Curso - GestiónProyectos 2012

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Curso - GestiónProyectos 2012

Transféré par

Droits d'auteur :

Formats disponibles

Programa

Formulacin de Proyectos y Su Ciclo de Vida

Surge como respuesta a una necesidad

Un proyecto informtico implica:

1.1 Roles, recursos y restricciones

1.1 Roles, recursos y restricciones

1.1 Roles, recursos y restricciones

4. Tambin hay un grupo que se ve afectado por el proyecto.

1.1 Roles, recursos y restricciones

1.1 Roles, recursos y restricciones

En la conformacin de los equipos de trabajo es importante tener claridad sobre:

1.1 Roles, recursos y restricciones

1.1 Roles, recursos y restricciones

Las herramientas para apoyar el desarrollo de un proyecto pueden incluir:

1.2 Ciclo de vida del proyecto.

C. Formulacin del proyecto. B. Evaluacin de alternativas.

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

Caracterizacin del problema

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

Caracterizacin del problema desde la situacin por modificar

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

La caracterizacin debe incluir:

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

Caracterizacin del problema desde el objetivo

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

Caracterizacin del problema desde los efectos

Cmo evaluar / cuantificar cada efecto ...a priori?

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

Caracterizacin del problema desde los participantes

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

Caracterizacin del contexto del problema y del proyecto

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

1.2 Ciclo de vida del proyecto: Identificacin de un problema...

1.2 Ciclo de vida del proyecto.

3. Formulacin del proyecto.

1.2 Ciclo de vida del proyecto.

1.2 Ciclo de vida del proyecto.

6. Evaluacin y medicin de resultados.

7. Diseo de la evolucin del proyecto.

1.2 Ciclo de vida del proyecto.

Consideraciones estratgicas en el ciclo de vida del proyecto

1.3 Identificacin de riesgos.

Antes de comenzar la ejecucin del proyecto es necesario identificar:

1.3 Identificacin de riesgos.

La evaluacin del riesgo tiene tres etapas, ellas son:

1.3 Identificacin de riesgos.

Cmo se administran los riesgos?

1.3 Identificacin de riesgos.

Primero, se hace una evaluacin del riesgo.

Segundo, se efectan las acciones para controlarlos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.

1.3 Identificacin de riesgos.