algoritmos y programación iii 5. metodologías, pruebas, documentación interna carlos fontela,...
TRANSCRIPT
Algoritmos y Programación III
5. Metodologías, Pruebas,
Documentación interna
Carlos Fontela, 2004
Página 2Algoritmos y Programación IIICarlos Fontela, 2004
Temario
Orientación a objetos: recapitulación UML: recapitulación Desarrollo en cascada y desarrollos
incrementales Proceso Unificado Métodos ágiles Extreme Programming
Página 3Algoritmos y Programación IIICarlos Fontela, 2004
OO: objetivos
Conceptos comunes de modelado a lo largo del ciclo de vida
Reducción de brecha entre problemas y modelos Reutilización y extensión del código Uso de prototipos Programación en ambientes de interfaz de usuario
gráfica. Programación por eventos. Programación para la World Wide Web. Desarrollo de
aplicaciones distribuidas. Uso de patrones.
¡¡¡Manejo de la complejidad!!!
Página 4Algoritmos y Programación IIICarlos Fontela, 2004
Conceptos Método o proceso
Define quién debe hacer qué, cuándo y cómo se deben realizar las distintas tareas.
Proceso Unificado, Extreme Programming, Scrum, Yourdon, etc.
Notación Lenguaje de especificación de modelos. Para diagramar los conceptos principales del software a
construir. UML, Yourdon, OMT, etc.
Herramienta Aplicación que facilita el desarrollo. Suele generar parte del código. Rational Rose, Borland ModelMaker, XDE (Extended
Development Environment, de Microsoft), Cool:Plex, etc.
Página 5Algoritmos y Programación IIICarlos Fontela, 2004
UML
Notación de modelado Creada por Booch-Rumbaugh-Jacobson Usa diagramas Diferentes diagramas para distintos
modelos Importante: mantener flexibilidad y
sencillez Muy buena fama y estandarizado por OMG No confundir con RUP o PUDS: no es un
proceso o método
Página 6Algoritmos y Programación IIICarlos Fontela, 2004
Desarrollo en cascada
Requisitos
Análisis
Diseño
Implementación
Pruebas
Producción/Mantenimiento
Página 7Algoritmos y Programación IIICarlos Fontela, 2004
Inconvenientes de la cascada
Impide comenzar una etapa hasta que la anterior no está concluida => retraso.
Cambios sobre una etapa ya terminada, a costa de burocracia y documentación.
Soluciones locales: remediar en diseño errores de análisis o en
implementación errores de diseño. El usuario final recién ve el sistema una
vez que está terminado: poco consustanciado con el desarrollo no advierte errores de concepción a tiempo.
Página 8Algoritmos y Programación IIICarlos Fontela, 2004
Métodos incrementales
Cascadas parciales. Facilidad para atender cambios de
requerimientos. Errores aparecen antes. Mayor continuidad entre fases. Competencias más amplias:
Analista se confunde con diseñador Diseñador con programador
Página 9Algoritmos y Programación IIICarlos Fontela, 2004
Categorías de métodos
Grandes metodologías Se utilizan en grandes proyectos. Suelen ser inaceptablemente pesadas para sistemas pequeños
o medianos. Destaca el Proceso Unificado de Desarrollo de Software
(PUDS).
Métodos ágiles O evolutivos o adaptables. Permiten organizar desarrollos medianos sin caer en
burocracias paralizantes. Alternativa a carecer de metodología. Destaca Extreme Programming (XP).
Página 10Algoritmos y Programación IIICarlos Fontela, 2004
Proceso Unificado (flujos)
Requisitos Análisis Diseño Implementación Prueba
¡No se refieren al tiempo! Asociados a tareas
Página 11Algoritmos y Programación IIICarlos Fontela, 2004
Proceso Unificado (fases)
Inicio o Concepción Elaboración Construcción Transición
Se refieren al tiempo Asociadas a hitos y objetivos
Página 12Algoritmos y Programación IIICarlos Fontela, 2004
PUDS – Fases – Inicio
Objetivos del hito de finalización: Haber definido los objetivos del sistema. Tener una idea aproximada del costo. Establecer la factibilidad del proyecto (si
conviene proseguir). Qué hacer:
Planificar el proyecto. Estudiar factibilidad. Delimitar alcance.
No suele ser una fase iterativa.
Página 13Algoritmos y Programación IIICarlos Fontela, 2004
PUDS – Fases – Elaboración
Objetivos del hito de finalización: Haber acotado los riesgos. Tener definida la arquitectura básica. Tener definido el plan de iteraciones de
construcción.• indicando qué casos de uso se realizan en qué
iteraciones,• empezar por los prioritarios para el cliente y los de
mayor riesgo.
Qué hacer: Establecer las “arquitecturas”. Analizar los riesgos mayores.
Puede ser una fase iterativa.
Página 14Algoritmos y Programación IIICarlos Fontela, 2004
PUDS – Fases – Construcción
Objetivos del hito de finalización: Tener la capacidad operativa inicial (versión
beta). Es la fase iterativa por excelencia. Qué hacer en cada iteración:
Miniproyecto que debe terminar con una entrega al usuario y pruebas de sistema.
Involucra análisis, diseño e implementación. Se pueden hacer cambios de arquitectura. E ir ajustando la planificación de las
iteraciones.
Página 15Algoritmos y Programación IIICarlos Fontela, 2004
PUDS – Fases – Transición
Objetivos del hito de finalización: Lanzamiento del producto.
Qué hacer: Desplegar el producto para ser utilizado. Puesta a punto. Adaptación a necesidades no previstas de los
usuarios que surjan de las pruebas beta. Añadir optimizaciones:
• no se añaden funciones nuevas,
• pero se desarrolla para optimizar y depurar.
Página 16Algoritmos y Programación IIICarlos Fontela, 2004
PUDS (fases y flujos)
Flujos – Fases Inicio Elaboración Construcción Transición
Requisitos 50% > 80% 100% 100%
Análisis y Diseño 5% 20% 100% 100%
Implementación, pruebas unitarias y de integración
0% < 10% 80% - 90% 100%
Despliegue, pruebas finales, puesta a punto
0% 0% 0% 100%
Página 17Algoritmos y Programación IIICarlos Fontela, 2004
PUDS (casos de uso)
Dirigen todo el proceso
Casos de uso > Identificados Descriptos AnalizadosDiseñados, implemen-
tados y probados
Inicio 50% 10% 5% Sólo algún prototipo
Elaboración > 80% 40% - 80% 20% - 40% < 10%
Construcción 100% 100% 100% 100%
Transición
Página 18Algoritmos y Programación IIICarlos Fontela, 2004
PUDS – Control del riesgo
Inicio: se estudian los casos de uso con los usuarios y construyen prototipos para validar conceptos.
Elaboración: se exploran escenarios y arquitecturas con los usuarios.
Construcción: se van ensamblando partes ya probadas sobre un código también probado.
Transición: se hacen despliegues graduales en las etapas anteriores.
Página 19Algoritmos y Programación IIICarlos Fontela, 2004
PUDS - Conclusiones
Metodología muy desarrollada.
Analizar en otro lado. Libros y cursos.
Muy amplio: Se puede combinar con otros métodos. ¡Sin trampas!
Página 20Algoritmos y Programación IIICarlos Fontela, 2004
Métodos ágiles (I)
Adaptables o adaptativos. Se adaptan a cada desarrollo.
Para desarrollos menos predecibles. Bastante comunes en el software.
Para facilitar cambios de requisitos sobre la marcha.
No para cualquier cliente. No para cualquier informático. Diseño y programación muy acoplados.
Página 21Algoritmos y Programación IIICarlos Fontela, 2004
Métodos ágiles (II)
Ojo con: Tiempos fijos. Alcances fijos. Presupuestos fijos.
Variables manejables Calidad Costo Tiempo de desarrollo Alcance
Ajustar el alcance y no la calidad.
Página 22Algoritmos y Programación IIICarlos Fontela, 2004
Métodos ágiles (III)
Extreme programming (XP) ASD Cristal Código abierto
un nombre engañoso
Scrum Desarrollo manejado por rasgos (FDD) DSDM (Método de desarrollo de sistema
dinámico)
Página 23Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (I)
Kent Beck y la comunidad Smalltalk. Lleva al extremo las buenas prácticas. Objetivos
Bajar el riesgo. Permitir cambios de especificaciones durante
el desarrollo. Favorecer la comunicación con el cliente. Que la inversión crezca gradualmente.
Página 24Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (II)
¿Probar programas es bueno? Hacer pruebas unitarias y funcionales todo el
tiempo. El desarrollo es dirigido por las pruebas: Test-
Driven Development (TDD). Se diseñan antes de codificar.
¿Los diseños de software son cambiantes? El diseño evoluciona junto con la
programación. Lo hacen los propios programadores.
Página 25Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (III)
¿Hacer pruebas de integración es importante? Integración sigue inmediatamente a las
pruebas unitarias. Permite que no sea cada vez más complicado
integrar código de varias fuentes. ¿Revisar la calidad del código es
recomendable? Revisar código todo el tiempo. Refactorizaciones (cambio de diseño para
hacerlo simple, sin cambiar funcionalidad).
Página 26Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (IV)
¿Estándares de codificación permiten una mejor comunicación y reducen errores? Fijar estándares precisos y estrictos.
¿Es bueno que el sistema sea simple? Buscar siempre la simplicidad. Diseñar sólo lo que se necesita en el momento. Principio más controvertido de XP.
¿Los requerimientos de arquitectura son cambiantes? Refinar la arquitectura constantemente.
Página 27Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (V)
¿El desarrollo incremental es positivo? Hacer iteraciones muy cortas. Diseñar una pequeña porción, codificarla y
probarla. Preocuparse sólo por lo que se está haciendo. Nada por adelantado.
¿Es importante tener una comunicación frecuente con el cliente? Un cliente acompañando el desarrollo. Fundamental para escribir pruebas funcionales
y priorizar tareas.
Página 28Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (VI)
¿Es frecuente que los proyectos se suspendan por falta de presupuesto? Usar el alcance como variable de ajuste. Implementar primero lo que tiene mayor valor
para el cliente. La primera iteración debe implementar un
esqueleto, con funcionalidades básicas. En la mayoría de los sistemas, el 20% del
desarrollo genera el 80% del beneficio.
Página 29Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (VII)
¿Dos cabezas piensan más que una? Los programadores trabajan de a dos. Cada pareja es responsable de una tarea. Aspecto más mencionado de XP. Y a la vez el menos conocido. Como refuerzo de las prácticas anteriores.
¿Es difícil mantener la documentación de desarrollo? “Burn it” (Beck). Aspecto muy cuestionado. Mucha comunicación interna.
Página 30Algoritmos y Programación IIICarlos Fontela, 2004
Extreme Programming (VIII)
Simplicidad “The simplest thing that could possibly work”. Complejidad dificulta refactorizaciones,
comunicación y depuraciones. No implementar lo que no se sabe si servirá,
• y en el 80% de los casos no sirve. Se mantiene baja la inversión inicial en el
proyecto. El código ejecutable permanece más chico.
La simplicidad cuesta trabajo y es fruto de un buen diseño.
Página 31Algoritmos y Programación IIICarlos Fontela, 2004
No aplicar XP en...
Proyectos que necesiten especificaciones precisas desde el comienzo.
Equipos de trabajo con más de 20 programadores (el número ideal es 10).
Equipos de trabajo que deben trabajar separados. Cuando la tecnología es un impedimento,
por tiempos de prueba o integración. Precio y plazo fijos. Bibliotecas genéricas,
sobre todo si no se puede llevar la biblioteca a producción hasta terminarla.
Página 32Algoritmos y Programación IIICarlos Fontela, 2004
Pruebas
Ver www.fi.uba.ar/materias/7507F Centrarse en pruebas unitarias y de
integración.
Página 33Algoritmos y Programación IIICarlos Fontela, 2004
Documentación
Ver www.fi.uba.ar/materias/7507F Documentación interna: en el código,
para los programadores Claridad Comentarios Documentación en línea
Página 34Algoritmos y Programación IIICarlos Fontela, 2004
javadoc - HTML
/** documentación para javadoc */
@see nombre-de-clase
@ version información-de-versión
@author información-del-autor
@param nombre-de-parámetro descripción
@return descripción
@throws clase-de-excepción-con-sus-calificadores
descripción
Página 35Algoritmos y Programación IIICarlos Fontela, 2004
Resumen
No confundir notaciones, procesos y herramientas.
Los métodos formales van bien con organizaciones formales.
Y con presupuestos, tiempos y alcances fijos.
Los métodos ágiles se adaptan a requisitos cambiantes.
Página 36Algoritmos y Programación IIICarlos Fontela, 2004
Qué sigue
Volver a POO: Excepciones Modelos de datos
Página 37Algoritmos y Programación IIICarlos Fontela, 2004
Bibliografía y otras fuentes
Una explicación de la programación
extrema, Kent Beck.
El Proceso Unificado de Desarrollo de
Software, Rumbaugh-Booch-Jacobson.
La Web.
Muchas Gracias.
Carlos Fontela, 2004