Antes de iniciar proyecto debe tomar en cuenta que tengas los recursos, la disponibilidad de ellos, que los puedas adquirir o usar antes de la etapa que se requieran Algunos Recursos: o Experiencia. o Material físico. o Material intangible (conocimientos, ideas, etc.). o Documentación (bibliografía, material disponible). o Recursos humanos. o Recursos financieros. o Tiempo.
1.Requisitos Carta de proyecto. I.Analizar el problema. II.Comprender las necesidades de los usuarios y stakeholders. III.Definir los requisitos del sistema. IV.Validar y verificar los requisitos. V.Organizar los requisitos. VI.Estudio de factibilidad. 2.Control de Calidad sobre los requisitos. 3.Gestión y control de cambios. 4.Trazabilidad de requisitos. 5.Interacción con otras disciplinas: Gestión de Proyectos, Verificación, Desarrollo, QA.
La investigación de factibilidad en un proyecto que consiste en descubrir cuales son los objetivos de la organización, luego determinar si el proyecto es útil para que la empresa logre sus objetivos. Aspectos básicos: ♦ Operativo. ♦ Técnico. ♦ Económico. Tiempo del analista. Costo de estudio. Costo del tiempo del personal. Costo del tiempo. Costo del desarrollo / adquisición.
o Reducción de errores y mayor precisión en los procesos. o Reducción de costos mediante la optimización o eliminación de recursos no necesarios. o Integración de todas las áreas y subsistemas de la empresa. o Actualización y mejoramiento de los servicios a clientes o usuarios. o Aceleración en la recopilación de datos. o Reducción en el tiempo de procesamiento y ejecución de tareas. o Automatización optima de procedimientos manuales.
o Requisitos óptimos: que el proyecto requiera, estos elementos deberán ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la máxima eficacia. o Requisitos mínimos: necesarios que el proyecto debe ocupar para obtener las metas y objetivos, este paso trata de hacer uso de los recursos disponibles de la empresa para minimizar cualquier gasto o adquisición adicional.
o Tiempo. o Espacio. o Recursos. o Disponibilidad de recursos. o Entre otro.
1.Identificar Casos de Uso del sistema. 2.Dar detalle a los casos de uso descritos. 3.Definir una interfaz inicial del sistema (si es aplicable). 4.Desarrollar el modelo del mundo. 5.Validar los modelos.
Se presenta en un diagrama de caso de uso donde se muestra las distintas operaciones que hace el usuario con la aplicación o sistema y cómo se relaciona con su entorno por lo que debemos: o Identificar los usuarios del sistema. o Identificar los roles que juegan esos usuarios desde el punto de vista del sistema. o Identificar otros sistemas con los cuales exista comunicación.
o Describa brevemente su objetivo. o Variantes para realizar este caso de uso. o Relacionar el caso de uso con la interfaz a usuario que lo representa. o Especificar el diálogo que da solución al caso de uso.
o Identificar Clases. o Elementos físicos y lógicos dentro del sistema a modelar. o Identificar atributos y asociaciones. o Identificar mensajes. o Punto de vista funcional. o Punto de vista de comportamiento. o Identificar relaciones de herencia. o Identificar restricciones del modelo. o Identificar valores posibles y no posibles de los atributos. Describirlos como restricciones de las clases. o Identificar valores permitidos para las asociaciones. Describirlos como restricciones de la asociación. o Identificar restricciones que relaciones dos o más atributos o relaciones. Describirlas dentro de la clase correspondiente Identificar paquetes. o Combinar clases fuertemente relacionadas en un paquete. o Combinar clases que tienen que ver con los mismos casos de uso en un paquete. o Consideraciones de re utilización. o Reutilizar modelos de dominio existentes. o Identificar posibles variantes en el futuro tenerlas en cuenta para diseño (patrones).
Desarrollar diagramas de interacción (diagramas de secuencia o de colaboración) para la variante por defecto de cada caso de uso, usando los objetos del modelo del mundo encontrados y sus mensajes.
o Se debe presentar y entender el dominio de la información de un problema. o Definir las funciones que debe realizar. o Representar el comportamiento del software a consecuencias de acontecimientos externos. o Divida en forma jerárquica los modelos que representan la información, funciones y comportamiento. o El proceso debe partir desde la información esencial hasta el detalle de la Implementación.
Un proyecto puede ser muy complejo pero al final es simplemente un conjunto de variables a controlar (recursos). Los recursos típicos son generalmente: o Tiempo.- Duración (el plazo que se tiene para terminar) no el esfuerzo (horas de trabajo). o Dinero.- Ingresos como gastos (en que lo gasto) como el flujo temporal (cuando lo gasto). o Planificación.- Lo que pienso que va a ocurrir. o Seguimiento.- Lo que en realidad ocurre. o Toma de decisiones.- En función de lo ocurrido. o Otros.- En este tipos de proyectos es que la interfaz del cliente con el sistema sea fácil de utilizar, el diseño tenga una presentación agradable para que el cliente quede satisfecho con el producto.
o Acciones correctivas Deben ocurrir cuando un problema surge. El proceso evalúa cómo la acción correctiva debe solucionar el problema, si los problemas surgirán o si la acción correctiva tendrá algún efecto en el proyecto. o Acciones preventivas El control de cambios integrados evalúa cuando ocurren cambios en el proyecto que no fueron previstos. La dirección del proyecto determina si ciertas acciones preventivas son requeridas para aligerar o evitar cualquier riesgo posible. Estas peticiones preventivas usualmente ocurren lo más lejos que el proyecto progresa pues la dirección del proyecto ha recibido una visión más clara y detallada de cómo el proyecto llegará a sus resultados.
Falta de comunicación. Planeación y administración inadecuada. Requerimientos inestables. Falta de entrenamiento. Cronograma no realista /no realizable. Alta rotación del personal. Uso inadecuado de recursos. Ambiente de trabajo inadecuado. Personal atado a tecnología obsoleta. Carencia de compromiso a largo plazo.
1.Optimismo desinformado: Período de tiempo al principio del proyecto cuando la preocupación y el estrés son bajo. 2.Preocupación vaga: Cuando la preocupación empieza a aumentar. 3.Pánico: Cuando el equipo debe realizar un enorme esfuerzo para cumplir con las actividades. 4.Asúmalo: El responsable tiene que aceptar los resultados generalmente malos.
Problemas del proyecto Indicadores de síntomas Fuentes del problema Mitigar riesgos Alerta Administrar para cambiar resultados Gerente de proyecto Lleva a Apunta a Distractores
Categoría 1.Equipo de proyecto. 2.Requerimiento. 3.Planeación. 4.Tecnología. 5.Expectativas. 6.Presupuesto. 7.Entrenamiento de usuarios. Problemas potenciales o Falta de entrenamiento. o Falta de claridad. o Detalles insuficientes. o Tecnología nueva. o Falta de asignación. o Falta de liderazgo. o Falta de comunicación.
o Negación de la realidad. o Miedo de ser culpado. o Miedo de parecer tonto. o Pereza. o Incentivos negativos. o Culpar a otros. o Síndrome de “eso no se hizo aquí”.
Reconocimiento del síntoma Evaluación Planeación de la recuperación Ejecución de la recuperación Revisión y pos- recuperación
o Reducir el alcance de modo que se pueda acabar en el plazo establecido y dentro de su presupuesto. o Aumentar la productividad implementando mejoras continuas de corto plazo. o Desplazar el cronograma, aumentar el presupuesto y terminar el alcance original. o Control de los problemas. o Cancelar el proyecto.
Stakeholder Productos Procesos y herramientas Personal
o Compromiso. o Habilidades. o Capacidades. o Entendimiento verdadero. o Revisión. o FODA. o Manejo de la política.