Your SlideShare is downloading. ×
02 proceso ciclodevida
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

02 proceso ciclodevida

241
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
241
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Presentación de ISProyecto de ISIntroducción a la ISProceso y Ciclo de Vida Proceso Software y Ciclo de Vida Curso 2008-2009 Gonzalo Méndez Dpto. de Ingeniería de Software e Inteligencia Artificial Facultad de Informática Universidad Complutense de Madrid
  • 2. Conceptos importantesPersonas• los que trabajanProducto• lo que se obtieneProyecto• la pauta a seguir para desarrollar un productoProceso• la pauta a seguir para desarrollar un proyecto
  • 3. Un trajePersonas• El sastreProducto• El trajeProyecto:• el sastre, el traje, el presupuesto del traje, el traje en sí, los pasos a dar para hacer el traje...Proceso• La secuencia de acciones para hacer un traje concreto
  • 4. Una cenaPersonas• Empleados de una empresa de cateringProducto• La cena que se sirveProyecto• El menú, el presupuesto, lo que hay que hacer para conseguir el menú, ...Proceso• La secuencia de acciones de servir una cena
  • 5. Una gama de automóvilesPersonas• Empleados de la marcaProducto• Los automóvilesProyecto• Desarrollo de un modelo nuevoProceso• Las instrucciones de la empresa sobre cómo desarrollar un modelo nuevo
  • 6. Para vosotrosPersonas• vuestro grupoProducto• la aplicación elegidaProyecto• parte práctica ISProceso• entregas mensuales + cómo vosotros decidáis organizaros
  • 7. Capas de la ISCapa de enfoque de calidadCapa de procesoCapa de métodosCapa de herramientas
  • 8. Capas de la ISCapa de calidad• Base de cualquier proceso de ingeniería• La IS se basa en calidad • Mejores técnicas de construcción de softwareCapa de proceso• Capa que une calidad y métodos • Desarrollo racional de la IS• Conjunto de actividades y resultados asociados que sirven para construir un producto software
  • 9. Capas de la ISCapa de métodos• Un método incluye: • Análisis de requisitos • Diseño • Construcción de programas • Prueba • Mantenimiento• Suelen estar bastante ligados al procesoCapa de herramientas• Soporte automático o semiautomático para el proceso y los métodos• Herramientas CASE
  • 10. Visión general de la ISCon independencia del modelo de proceso haytres fases genéricas:• Fase de definición• Fase de desarrollo• Fase de mantenimientoCada una de estas fases se descompone en unconjunto de tareas
  • 11. Fase de definición/especificaciónSe identifican requisitos de sistema y software:• Información a procesar• Función y rendimiento deseados• Comportamiento del sistema• Interfaces establecidas• Restricciones de diseño• Tareas principales: • Planificación del proyecto software • Ingeniería de sistemas o de información • Análisis de requisitos
  • 12. Fase de desarrolloSe define:• Cómo diseñar las estructuras de datos• Cómo implementar las funciones• Cómo caracterizar las interfaces• Cómo traducir el diseño a programación• Cómo validar el producto (pruebas, verificación)• Tareas principales: • Diseño del software • Generación del código • Pruebas del software
  • 13. Fase de mantenimientoCentrada en cambios que se pueda necesitar realizarsobre un productoSe vuelven a aplicar las fases de definición ydesarrollo, pero sobre software ya existentePueden producirse cuatro tipos de cambio:• Corrección: Corregir los defectos• Adaptación: Modificaciones por cambio externo• Mejora: Ampliar los requisitos funcionales originales, a petición del cliente• Prevención: Cambio para facilitar el cambio
  • 14. Visión general de la ISEstas fases se complementan con lasactividades de soporte• No crean software• Mejoran su calidad• Facilitan su desarrolloSe aplican a lo largo de todo el proceso delsoftware
  • 15. Visión general de la ISEjemplos de actividades de soporte• Documentación• Gestión de configuración• Seguimiento y control del proyecto de software• Revisiones técnicas formales• Garantía de la calidad del software• Gestión de reutilización• Mediciones• Gestión de riesgos
  • 16. Proceso softwareConjunto estructurado de actividades y resultadosasociados requeridos para desarrollar un sistema desoftware• Especificación: establecer requisitos y restricciones• Diseño: Producir un modelo en papel del sistema• Implementación: construcción del sistema de software• Validación: verificar (por ejemplo mediante pruebas) que el sistema cumple con las especificaciones requeridas• Instalación: entregar el sistema al usuario• Evolución y mantenimiento: cambiar/adaptar el software según las demandas; reparar fallos en el sistema
  • 17. Modelos de procesoUn modelo de proceso, o paradigma de IS, esuna plantilla, patrón o marco que define elproceso a través del cual se crea softwareDicho de otra forma, los procesos soninstancias de un modelo de procesoEn esta asignatura los términos proceso ymodelo de proceso se utilizan indistintamente
  • 18. Modelos de procesoUna organización podría variar su modelo deproceso para cada proyecto, según:• La naturaleza del proyecto• La naturaleza de la aplicación• Los métodos y herramientas a utilizar• Los controles y entregas requeridas
  • 19. Características del procesoEntendibleVisibilidad: Grado en que las actividades del procesoproporcionan resultadosSoportable por herramientas CASEAceptabilidad: Grado en que los desarrolladores aceptan yusan el procesoFiabilidad: Capacidad de evitar o detectar errores antes de quesean defectosRobustez: Continuidad del proceso a pesar de los problemasMantenible: Capacidad de evolución para adaptarseRapidez: Velocidad en que el proceso puede proporcionar unsistema a partir de una especificación
  • 20. Modelos Genéricos de Desarrollo de SoftwareModelo de CascadaPrototipadoDesarrollo EvolutivoEn espiralDesarrollo basado en componentesMétodos Formales
  • 21. Modelo en cascada (waterfall)Modelo de proceso clásico (desde los 70)Basado en la mentalidad de línea deensamblaje (cartesiano)Es sencillo y fácil de entenderEl proyecto pasa a través de una serie de fases• Al final de cada fase se revisan las tareas de trabajo y productos • Para poder pasar a la siguiente fase se tiene que haber conseguido todos los objetivos de la fase anterior• No hay apenas comunicación entre las fases
  • 22. Modelo en cascada (waterfall)Definición de Requisitos Diseño del Software y del Sistema Implementación y Pruebas Unitarias Integración y Prueba del Sistema Operación y Mantenimiento
  • 23. Modelo en cascada (waterfall)Fases:• Conceptualización: Se determina la arquitectura de la solución (división del sistema en subsistemas)• Análisis de requisitos: Básicamente se definen los requisitos funcionales y de rendimiento• Diseño: Representación de la aplicación que sirve de guía a la implementación• Implementación: Transforma el diseño en código• Prueba: Validación e integración de software y sistemas• Instalación y comprobación: Se instala el software al cliente, el cual comprueba la corrección de la aplicaciónSe supone que sólo se baja en la cascada... perotambién se puede subir (aunque difícilmente)
  • 24. Modelo en cascada (waterfall)Posibles ventajas:• Sencillo: Sirve cuando el personal está poco cualificado• Aplicable cuando el problema es estable y cuando se trabaja con técnicas conocidasCríticas:• No se ve un producto hasta muy tarde en el proceso • Un error grave detectado en las últimas fases puede ser letal• Especificación de requisitos estable• Impone una estructura de gestión de proyectos • Fases muy rígidas• Las revisiones de proyectos de gran complejidad son muy difíciles
  • 25. PrototipadoSe usa un prototipo para dar al usuario una ideaconcreta de lo que va a hacer el sistemaSe aplica cada vez más cuando la rapidez dedesarrollo es esencialPrototipado evolutivo: el prototipo inicial se refinaprogresivamente hasta convertirse en versión finalPrototipado desechable: de cada prototipo se extraenideas buenas que se usan para hacer el siguiente, perocada prototipo se tira entero
  • 26. PrototipadoEscucharal cliente Construir/ revisar prototipo El cliente evalúa el prototipo
  • 27. PrototipadoComienza con la recolección de requisitos• Cliente y desarrolladores definen los objetivos globales del software.• Además, identifican los requisitos conocidos y aquellos que deben ser más definidos.Aparece un diseño rápido centrado en los aspectosvisibles para el cliente (e.g. información de E/S)• El diseño rápido lleva a la construcción de un prototipoEl prototipo lo evalúa el cliente y lo utiliza pararefinar los requisitosEl proceso se itera... ¿desechando el prototipo?
  • 28. PrototipadoVentajas• Permite identificar los requisitos incrementalmente• Permite probar alternativas a los desarrolladores• Tiene una alta visibilidad tanto clientes como desarrolladores ven resultados rápidamenteInconvenientes• El cliente no entiende por qué hay que desechar el prototipo • Si simplemente ha pedido unos ajustes...(¿?)• Riesgo de software de baja calidad • Compromisos de implementación para que el prototipo funcione rápidamente y que al final son parte integral del sistema – Utilizar un SO o lenguaje de programación inadecuado pero conocido
  • 29. Modelos evolutivosCaracterísticas:• Gestionan bien la naturaleza evolutiva del software• Son iterativos: construyen versiones de software cada vez más completasSe adaptan bien:• Los cambios de requisitos del producto• Fechas de entrega estrictas poco realistas• Especificaciones parciales del producto
  • 30. Modelos evolutivos Actividades Concurrentes Versión Especificación InicialDescripción Versionesdel sistema Desarrollo Versiones Intermedias Intermedias Validación Versión Final
  • 31. Modelos evolutivos. IncrementalFusiona el modelo lineal secuencial con el deconstrucción de prototipos A D C P 1er incremento A D C P 2º incremento ..................... N-ésimo incremento
  • 32. Modelos evolutivos. IncrementalCada secuencia lineal secuencial produce unincremento del software• Incremento: producto operacional de una parte del sistemaEl primer incremento suele ser el núcleo• Requisitos básicos• Muchas funciones suplementarias se dejan para despuésSe evalúa (p.ej., por el cliente) el producto entregado• Como resultado se desarrolla un plan para el siguienteSe itera• Hasta elaborar el producto completo
  • 33. Modelos evolutivos. IncrementalVentajas• Es interactivo • Con cada incremento se entrega al cliente un producto operacional al cliente, que puede evaluarlo• Personal • Permite variar el personal asignado a cada iteración• Gestión riesgos técnicos • Por ejemplo, disponibilidad de hardware específicoInconvenientes• La primera iteración puede plantear los mismos problemas que en un modelo lineal secuencial
  • 34. Modelo de Proceso en EspiralOriginal: Boehm, 1988IEEE Std. 1490-1998Tratar primero las áreas de mayor riesgoMúltiples iteraciones sobre varias regiones de tareas• Vuelta a la espiral: ciclo• Número de iteraciones predeterminadas o calculadas dinámicamenteSe pueden variar las actividades de desarrollo: familiade modelos de procesos
  • 35. Modelo de Proceso de Espiral Evalúe alternativas,Determine objetivos identifique y resuelva alternativas y riesgos restricciones Análisis de Riesgos Análisis de Riesgos Análisis de Riesgos Prototipo Prototipo Operacional Análisis Prototipo 3 de Proto 2 REVISIÓN Riesgos tipo1 Simulaciones, modelos y benchmarks Plan de requerimientos Concepto de Plan del ciclo de vida Operación Requeri mientos de Diseño Diseño SW del Detallado Plan de Validación de Producto Codificación Desarrollo Requerimientos Prueba de Plan de Integración Diseño Unidades Prueba de y Prueba V &V Planea la Prueba de Integración Aceptación Desarrolla y verifica siguiente fase Servicio el siguiente nivel del producto
  • 36. Modelo de Proceso en EspiralEl modelo en espiral es bastante adecuado parala gestión de riesgosSe puede añadir una actividad de gestión deriesgosDe hecho, el modelo original de Boehm:• Fijar objetivos• Gestionar y reducir riesgos• Desarrollo y validación• Planificar siguiente ciclo
  • 37. Modelos Evolutivos. Espiral BoehmFijar objetivos• Definir objetivos del ciclo• Identificar restricciones del proceso y producto• Desarrollar plan de gestión• Identificar riesgos• Identificar estrategias alternativasGestionar y reducir el riesgo• RSGR para cada riesgo identificado
  • 38. Modelos Evolutivos. Espiral BoehmDesarrollo y validación• Elegir modelo de desarrollo• Algunos autores lo denominan metamodelo• Yo prefiero llamarlo modelo paramétricoPlanificación• Revisión del proyecto• Decisión de una nueva vuelta
  • 39. Modelos de Proceso en EspiralVentajas• Enfoque realista• Gestión explícita de riesgos• Centra su atención en la reutilización de componentes y eliminación de errores en información descubierta en fases iniciales• Los objetivos de calidad son el primer objetivo• Integra desarrollo con mantenimiento
  • 40. Modelos de Proceso en EspiralInconvenientes• Convencer cliente enfoque controlable• Requiere de experiencia en la identificación de riesgos• Requiere refinamiento para uso generalizado
  • 41. Desarrollo Basado en Componentes Desarrollo de sistemas en poco tiempo Adaptación a “alta velocidad” de la cascada • Equipos trabajando en paralelo • Aplicando tecnología de componentes Equipo 1 Equipo 2 Equipo n A A A D D ............ D C C C P P P 60-90 días
  • 42. Desarrollo Basado en Componentes Ventajas • Rapidez • Válido para aplicaciones modularizables Inconvenientes • Exige conocer bien los requisitos y delimitar el ámbito del proyecto • Número de personas • Clientes y desarrolladores comprometidos • Gestión riesgos técnicos altos • Uso de nueva tecnología • Alto grado de interoperabilidad con sistemas existentes
  • 43. Desarrollo Basado en Componentes Identificar componentes candidatos Construir Buscar iteración N componentes del sistema en biblioteca Añadir Extraer componentes componentes a biblioteca disponibles Construir componentes que falten
  • 44. Desarrollo con métodos formalesSe basa en la transformación de unaespecificación formal a lo largo de variasrepresentaciones hasta llegar a un programaejecutableLas transformaciones preservan la corrección• Permiten comprobar fácilmente que el programa es conforme a la especificación
  • 45. Desarrollo con métodos formalesRequirements Formal Formal Integration and definition specification transformation system testing
  • 46. Transformaciones formales Formal transformations T1 T2 T3 T4 Formal R1 Executable R2 R3specification program P1 P2 P3 P4 Proofs of transformation correctness
  • 47. Desarrollo formal de sistemasProblemas• Hace falta una formación especializada para aplicar la técnica• Muchos aspectos de los sistemas reales son difíciles de especificar formalmente • Interfaz de usuario • Requisitos no funcionalesAplicabilidad• Sistemas críticos en los que la seguridad y fiabilidad debe poder asegurarse antes de poner el sistema en operación
  • 48. Visibilidad de ProcesosLos sistemas de software son intangibles por lo quelos administradores necesitan documentación paraidentificar el progreso en el desarrolloEsto puede causar problemas• El tiempo planeado para entregar resultados puede no coincidir con el necesario para completar una actividad• La necesidad de producir documentos restringe la iteración entre procesos• Tiempo para revisar y aprobar documentos significativoEl modelo de cascada es aún el modelo basado enresultados mas utilizado
  • 49. Visibilidad de ProcesosModelo de Proceso Visibilidad del ProcesoModelo de Cascada Buena visibilidad, cada actividad produce un documento o resultadoDesarrollo Evolutivo Visibilidad pobre, muy caro al producir documentos en cada iteraciónModelos Formales Buena visibilidad, en cada fase deben producirse documentosDesarrollo orientado a la Visibilidad moderada. Importantereutilización contar con documentación de componentes reutilizablesModelo de Espiral Buena visibilidad, cada segmento y cada anillo del espiral debe producir un documento
  • 50. ¿Qué modelo utilizar?Para sistemas bien conocidos se puede utilizar elModelo de Cascada. La fase de análisis de riesgos esrelativamente fácilCon requisitos estables y sistemas de seguridadcríticos, se recomienda utilizar modelos formalesCon especificaciones incompletas, el modelo deprototipado ayuda a identificarlos y va produciendoun sistema funcionalPueden utilizarse modelos híbridos en distintas partesdel desarrollo
  • 51. EjemplosDos modelos de proceso concretos:• Proceso Unificado de Rational (pesado)• Extreme Programming (ágil)
  • 52. Proceso UnificadoLos autores de UML• Booch: método Booch• Rumbaugh: OMT• Jacobson: proceso ObjectoryTambién conocido como RUP: RationalUnified Process
  • 53. Proceso UnificadoEs un proceso de desarrollo de software• Dirigido por casos de uso• Centrado en la arquitectura• Iterativo e incrementalUtiliza UML para definir los modelos del sistema softwareEl sistema software en construcción está formado por• componentes software• interconectados a través de interfaces Proceso de Requisitos desarrollo de Sistema de usuario software software Los requisitos cambian y el sistema software evoluciona
  • 54. Proceso Unificado Organization along time Phases Process Components Inception Elaboration Construction Transition Requirements Capture Analysis & Design ImplementationOrganization Testalong content Supporting Components Management Environment Deployment preliminary iter. iter. iter. iter. iter. iter. iter. iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterations
  • 55. Extreme Programming (XP)Modelo de proceso de Kent Beck Un modo ligero, eficiente, de bajo riesgo, flexible, predecible, científico y divertido de producir softwareCaracterísticas• Alta visibilidad debido a ciclos muy cortos• Planificación incremental• Se adapta a cambios de negocio
  • 56. Extreme Programming (XP)Basado en pruebas automatizadas escritas pordesarrolladores y clientes (test-driven)Alta comunicaciónDiseño evolutivoColaboración entre programadoresBusca equilibrio entre las necesidades a cortoplazo de los programadores y las de largoplazo del proyecto
  • 57. Extreme Programming (XP) La estructura del proceso, si la hay, es un poco atípicaCodificación Prueba Evaluación Diseño Actividades en XP
  • 58. Extreme Programming (XP)Las cuatro actividades están soportadas por doce prácticas:• El juego de planificación• Pequeñas entregas• Metáfora• Diseño simple• Prueba• Refactoring• Programación en pareja• Propiedad colectiva• Integración continua• Semana de cuarenta horas• Cliente en el lugar de desarrollo• Codificación estándar
  • 59. Extreme Programming (XP)Ventajas:• Bueno para especificaciones cambiantes• Fundamentación prácticaInconvenientes:• Poco probado• Poco compatible con especificaciones/diseños totales• Sólo funciona con equipos pequeños (hasta diez personas)
  • 60. Extreme Programming (XP)Diferencias fundamentales (hay más que ya severán)• No hay requisitos explícitos sino que el cliente participa en el desarrollo• Se empieza por automatizar las pruebas• Se desarrolla siempre la versión más simple posible que resuelva el problema• Se ejecutan todas las pruebas todos los días• Se cambia el diseño (aunque sea radicalmente) siempre que haga falta
  • 61. Calidad del proceso de software ¿ Cómo medir la calidad del proceso de software de una empresa ?
  • 62. La empresa idealEl Dpto. de la Defensa de los US fundó el SoftwareEngineering Institute (SEI) asociado con laUniversidad de Carnegie Mellon (CMU).Desarrollan el Software Capability Maturity Model(SW CMM) a mediados de 1980s, refinado en losinicios de l990s.Este modelo define una serie de áreas clave deproceso (ACP)• Un área clave de proceso es, básicamente, una actividad de IS
  • 63. Software Capability Maturity Model Level 5 Optimizing Level 4 Managed Level 3 Defined Level 2 RepeatableLevel 1 Initial
  • 64. Áreas clave del proceso O p t i m i zi n g P r o ce s s c h a n g e m a n a g em e n t T e c h n o l o g y c h a n g e m a n a g em e n t D e f e c t p r e v e n t io n M a n a g ed S o f tw a re q u a l it y m a n a g e m e n t Q u a nt it a t iv e p r o c e s s m a n a g e m e n t D e fin e d P e e r r e v ie w s I n t e r g ro u p c o o r d in a t io n S o f tw a r e p r o d u c t e n g i n e e r i n g I n t e g r a t e d s o f tw a r e m a n a g e m e n t T ra ining p rog ra m m e O r g a n i z a ti o n p r oc e s s d e f in it io n O r g a n i z a ti o n p r oc e s s f o c u s R e p e atab le S o f tw a r e c o n f i g u ra t io n m a n a g e m e n t S o f tw a r e q u a l it y a s s u r a n c e S o f tw a r e s u b c o n tr a c t m a n a g e m e n t S o f tw a r e p ro je c t tr a c k i n g a n d o v e r s ig h t S o f tw a r e p ro je c t p l a n n in g R e q u ir e m e n ts m a n a g e m e n tI n it i a l ©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31.
  • 65. CMMLos niveles son acumulativosNivel 1: Inicial• El proceso de software se caracteriza según el caso• Se definen poco procesos• El éxito depende del esfuerzo individual
  • 66. CMMNivel 2: Repetible• Se incluye seguimiento del coste, la planificación y la funcionalidad• Se repiten técnicas de proyectos anteriores con buenos resultados• Las ACP son: • Planificación del proyecto de software • Seguimiento y supervisión del proyecto de software • Gestión de requisitos • Gestión de la configuración software (GCS) • Garantía de calidad del software (SQA) • Gestión de la subcontratación
  • 67. CMMNivel 3: Definido• Nivel 2• Las actividades se documentan, estandarizan e integran en un proceso a nivel organización• Existe un proceso documentado• Las ACP son: • Definición y enfoque del proceso de la organización • Programa de formación • Revisiones periódicas • Coordinación entre grupos • Ingeniería de productos software • Gestión de integración del software
  • 68. CMMNivel 4: Gestionado• Nivel 3• Se recopilan medidas del proceso del software y de la calidad del producto• Estas medidas sirven para gestionar el proceso• Las ACP son: • Gestión de la calidad del software • Gestión cuantitativa del software
  • 69. CMMNivel 5: Optimización• Nivel 4• En base a la experiencia y métricas se optimiza el proceso• Las ACP son: • Gestión de cambios del proceso • Gestión de cambios de tecnología • Prevención de defectos
  • 70. CMMUn nivel razonable es el definido (nivel 3)Un nivel deseable es optimización (nivel 5)Con independencia del CMM, ACPs mínimas:• Planificación del proyecto• Seguimiento y supervisión del proyecto• Gestión de requisitos• GCS• SQA• Definición del proceso• Revisiones periódicas• Coordinación entre grupos
  • 71. Datos Agosto 2000Inicial 34,9%Repetible 38,2%Definido 18,5%Gestionado 5,5%Optimizado 2,9%Resultados de 901 empresas desde 1996.
  • 72. Referencias• Modelos de proceso • Pressman 17-46, Sommerville 42-67• Proceso Unificado • Jacobson, Krutchen• SW CMM • Pressman Cap. 2, Sommerville Cap. 25 • http://www.sei.cmu.edu/cmm/obtain.cmm.html• Material • Pablo Gervás • Juan Pavón y Jorge Gómez • Natalia Juristo