Interacción entre las fases de un proyecto

Iniciación, planificación, ejecución, control, cierre

Software > Consideraciones ¿comprar o desarrollar software?

–Filosofía empresarial –Se recomienda, adquirir aplicaciones que cubran al menos el 70% de sus requerimientos funcionales –Evitar tiempos de desarrollo superiores a 18 meses o dos años 

–Comprar generalmente se refiere a adquirir productos con funcionalidades genéricas pensando en las mejores prácticas comunes en las empresas del sector

Carácterísticas a considerar en la decisión de comprar o desarrollar software 

–Necesidades: identificar las necesidades, aquellas verdaderamente indispensables y determine los rasgos más importantes. –Recursos: examinar sus recursos es crítico; tiempo, personal, recursos financieros. 

–Unicidad–Soporte

CARACTARISTICAS DEL SW: –No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales –Su duplicación es poco costosa, lo caro es el desarrollo –Puede ser modificado fácilmente, tanto que es necesario un control de versiones

Ciclo de Vida del Software

Conjunto de fases por las que pasa un sistema desde que se inicia su desarrollo hasta que e s retirado o remplazado: •Consiste en determinar: –El orden de las fases del proceso de desarrollo –Criterios de transición para pasar de una fase a otra –Definir las entradas y salida de cada fase

DEVELOPMENT >> USE >> MODIFICATION

Fases de desarrollo del ciclo de vida del software

Planificación >> ANALYSIS >> DESIGN >> IMPLEMENTATION >> TESTING 

Método tradicionales de desarrollo

MODELO EN CASCADA. Modelo en cascada Carácterísticas –Es el más utilizado. –Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. –Para que el proyecto tenga éxito deben desarrollarse todas las fases. –Las fases continúan hasta que los objetivos se han cumplido. –Si se cambia el orden de las fases, el producto final será de inferior calidad,

Limitaciones –No se permiten las iteraciones. –Los requisitos se congelan al principio del proyecto. –No existe un entregable hasta el final del proyecto. – No refleja realmente el proceso de desarrollo del software –Se tarda mucho tiempo en pasar por todo el ciclo –Comunicación con el usuario final mínima –El mantenimiento se realiza en el código fuente –Las revisiones de proyectos de gran complejidad son muy difíciles

Modelo de Proceso de Espiral Introduce el análisis de riesgo como elemento fundamental para guiar la evolución del proceso de desarrollo. En la dimensión radial se representa el esfuerzo realizado en el desarrollo (siempre creciente) Cada iteración consta de 4 fases: PLANIFICACIÓN, determina que parte del desarrollo se abordará en ese ciclo. Análisis DE RIESGO, evaluar diferentes alternativas para esa parte del desarrollo seleccionando la más ventajosa y tomando precauciones para evitar los posibles inconvenientes. INGENIERÍA, se realizan las actividades de los modelos clásicos EVALUACIÓN, se analizan los resultados de la fase de ingeniería.

RUP Rational Unified Process, es un proceso de desarrollo de software en conjunto con UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos. RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Métodos Ágiles

Manifiesto ágil Estamos poniendo al descubierto formas mejores de desarrollo de software, haciéndolo y ayudando a otros a que lo hagan. A través de este trabajo hemos llegado a valorar: Los individuos y la interacción por encima de los procesos y herramientas. El software que funciona por encima de la documentación abarcadora. La colaboración con el cliente por encima de la negociación contractual. La respuesta al cambio por encima del seguimiento de un plan.

Desarrollo evolutivo •Problemas –Los sistemas a menudo resultan pobremente estructurados. –Puede ser necesario contar con habilidades especiales (por ejemplo, lenguajes para prototipos rápidos). •Aplicabilidad –Para sistemas interactivos pequeños o de mediano tamaño. –Para partes de sistemas grandes (por ejemplo, la interfaz del usuario). –Para sistemas de corta vida útil.

XP (programación Extrema) Método ágil basado en cuatro principios: –simplicidad, –comunicación, –retroalimentación, –valor

Practicas asociada en XP •Programación en pares –Todo el código es escrito por parejas de programadores, una sola máquina con un teclado y un mouse –No es un programador trabajando y el otro mirando –No es una sesíón de aprendizaje para un programador junior –El que no está escribiendo; piensa más estratégicamente y revisa el código en tiempo real –Los roles se pueden cambiar varias veces durante el día –Fundamentos: dos programadores trabajando juntos son más efectivos que por separado, el conocimiento grupal crece más rápido, trabajar es más divertido

Practicas asociada en XP •Programación en pares. Practicas asociada en XP •40 horas semanales –El desarrollo de software es un ejercicio creativo, hay que estar fresco y descansado –Sin “héroes” –Se reduce la rotación de personal –Mejora la calidad del producto –Se permiten excepciones, con cuidado, más de una semana de horas extra: problema •Lugar de trabajo –Sala amplia (mejor, sin divisiones) –Al centro: pares de programadores –En la periferia: máquinas individuales –Ventajas del espacio abierto, mayor comunicación, agenda dinámica, etc.

Scrum •No es método independiente, sino complemento de otras metodologías (XP, MSF, RUP) •Enfatiza valores y prácticas de gestión, no cuestiones técnicas de desarrollo

•Equipos auto-dirigidos y auto-organizados. No hay mánager que decida, ni otros títulos que “miembros del equipo” o “cerdos”; la excepción es el Scrum Máster que debe ser 50% programador y que resuelve problemas, pero no manda. Los observadores externos se llaman “gallinas”; pueden observar, pero no interferir ni opinar. •Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa. •Encuentros diarios con las tres preguntas … Se realizan siempre en el mismo lugar, en círculo y de pie. •Iteraciones de treinta días; se admite que sean más frecuentes. •Demostración a participantes externos al fin de cada iteración. •Al principio de cada iteración, planeamiento adaptativo guiado por el cliente.

Prácticas de Scrum •Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Máster. •Las presentaciones en PowerPoint están prohibidas. En los encuentros diarios, las gallinas deben estar fuera del círculo. •Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinará a obras de caridad. •Es permitido usar artefactos de los métodos a los que Scrum acompañe, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el método es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestión de Proyectos de MSF. •No es legal el uso de instrumentos como diagramas PERT, porque parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar •El supuesto dominante es que el desarrollo es semi-caótico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.

Métodos Ágiles Feature Driven Development (FDD) El seguimiento del progreso se realiza mediante examen de pequeñas funcionalidades descompuestas y funciones valoradas por el cliente. •No cubre todo el ciclo de vida, sino diseño y construcción •Se considera apto para proyectos mayores o de misión crítica •Hay arquitectos en FDD •Numerosos artefactos para el control del proceso •FDD es un método de desarrollo de ciclos cortos que se concentra en la fase de diseño y construcción. •En la primera fase, el modelo global de dominio es elaborado por expertos del dominio y desarrolladores; •El modelo de dominio consiste en diagramas de clases con clases, relaciones, métodos y atributos. •Los métodos no reflejan conveniencias de programación sino rasgos funcionales.

Software Capability Maturity Model

CMMI es el acrónimo inglés de “Capability Maturity Model Integration / Integración de un modelo de madurez de la capacidad” y se define como un Modelo para la mejora de los procesos de desarrollo y mantenimiento de sistemas y productos de software.

Fue creado por el Instituto de Ingeniería del Software de la Universidad norteamericana Carnegie Mellón (SEI), y publicado en su primera versión en el año 2002.

Objetivos de CMMI –Producir servicios y Productos de alta calidad. –Crear valor para los accionistas. –Mejorar la satisfacción del cliente. –Incrementar la participación en el mercado. –Ganar reconocimiento en la industria.

Niveles de madurez. Utilizado en la representación escalonada para enfocar la mejora en la capacidad del proceso que la organización espera obtener

INICIAL No se tienen procesos estructurados en la organización, el desarrollo es caótico y ad hoc.

ADMINISTRADO La organización cuenta con procesos básicos de administración de proyectos y se utilizan

DEFINIDO La organización cuenta con un conjunto estándar de procesos que establecen la forma en que opera y que pueden ser ajustados bajo determinadas condiciones

ADMINISTRADO CUANTITATIVAMENTE La organización controla los procesos mediante estadísticas y otras técnicas cuantitativas

OPTIMIZADO La organización mejora continuamente sus procesos considerando las causas comunes de variación. Es el Nirvana

SCAMPI (Standard CMMI Appraisal Method for Process Improvement) Es un método desarrollado por SEI para evaluar el estado de los procesos de software de una organización basado en los modelos CMMI. Existen tres tipos de SCAMPI: A, B, C, en donde la profundidad de la evaluación, la duración, costo y uso varían. Estas evaluaciones son hechas por un Asesor Líder acreditado por el SEI. Los resultados de un SCAMPI permiten a la organización conocer la situación actual de sus procesos, establecer prioridades, enfocar las actividades de mejora, reforzar áreas de oportunidad, así como tener las bases sobre las cuales establecer el siguiente ciclo de mejora.