algunas trasparencias de I. Sommerville

Procesos del software(selección de alguna de las trasparencias de Sommerville)©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Modelos de proceso del softwaregenéricos●●●●El modelo de cascada• Se trata de fases de especificación de desarrollo distintas yseparadas.Desarrollo evolutivo• Las actividades de especificación, desarrollo y validación sellevan a cabo concurrentemente.Ingeniería de software basada en los componentes• El sistema se articula a partir de componentes ya existentesHay muchas variantes de estos modelos, por ejemplo, undesarrollo formal en el que el proceso de cascada se usapero la especificación es una especificación formal que serefina a través de varias fases hasta conseguir un diseñoimplementable.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 2

Modelo de cascadadefiniciónDe requerimientosDiseño de sistemasde sistemas y softwareImplementacióny prueba deunidadesIntegración yprueba delsistemaOperación ymantenimiento©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 3

Fases del modelo de cascada●●●●●●Definición y análisis de los requerimientosDiseño de sistemas y softwareImplementación y prueba de unidadesIntegración y prueba del sistemaOperación y mantenimientoEl principal inconveniente del modelo de cascada es ladificultad de acomodar el cambio después de que elproceso está en proceso. Una fase tiene que estarcompleta antes de pasar a la siguiente fase.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 4

Problemas del modelo de cascada●●●●La Inflexibilidad al dividir el proyecto en distintasetapas hace difícil responder al cambio en losrequerimientos del cliente.Entonces, este modelo sólo e apropiado cuando losrequerimientos se han entendido bien y los cambiosestán bastante limitados durante el proceso de diseño.Muy pocos sistemas de negocios tienenrequerimientos establesEl modelo de cascada se usa principalmente paragrandes proyectos de ingeniería de sistemas en losque un sistema se desarrolla en varios sitios.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 5

Desarrollo evolutivo●●Desarrollo exploratorio• El objetivo es trabajar con el cliente y evolucionar haciaun sistema final desde un esbozo inicial deespecificación. Se debe empezar con unosrequerimientos bien comprendidos y añadir nuevosatributos acordes con las propuestas del cliente.Prototipos desechables• El objetivo es entender los requerimientos del sistema.Se debe empezar con requerimientos que no secomprenden del todo hasta clarificar lo que realmentese necesita.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 6

Desarrollo evolutivoActividadesconcurrentesEspecificaciónVersión inicialEsbozo de ladescripciónDesarrolloVersionesintermediasValidaciónVersión final©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 7

Desarrollo evolutivo●●Problemas• Falta de visibilidad del proceso;• A menudo los sistemas tienen una estructura deficiente;• Pueden ser necesarias técnicas especiales especiales (P.Ej.:en lenguajes para la rápida creación de prototipos).Aplicabilidad• Para sistemas interactivos pequeños o de tamaño medio;• Para partes de grandes sistemas (P.Ej.: la interfaz delusuario);• Para sistemas de corta vida©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 8

Iteración de procesos●●●Los requerimientos del sistema SIEMPREevolucionan en el transcurso de un proyecto,así que la iteración del proceso en el que lasprimeras etapas son revisadas siempre esparte del proceso para grandes sistemasLa iteración puede aplicarse a cualquiermodelo de proceso genéricoDos aproximaciones (relacionadas)• Desarrollo incremental;• Desarrollo en espiral.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 9

Desarrollo incremental●●●En lugar de desarrollar el sistema como una solaunidad, el desarrollo y entrega se dividen enincrementos con cada parte de incremento dedesarrollo de la funcionalidad requeridaLos requerimientos del usuario se priorizan y losrequerimientos de mayor prioridad se incluyen en losprimeros incrementos.Una vez el desarrollo de un incremento hacomenzado, los requerimientos se congelan aunquelos requerimientos para sucesivos incrementospueden continuar evolucionando.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 10

Desarrollo incrementalDefinir esbozoderequerimientosAsignar requerimientosa los incrementosDiseñararquitectura delsistemaDesarrollarincrementos delsistemaValidar incrementosSistema incompletoIntegrarincrementosValidar sistemaSistema final©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 11

Ventajas del desarrollo incremental●●●●Los clientes no tienen que esperar hasta que elsistema completo se entregue para sacar provecho deél. El primer incremento satisface los requerimientosmás críticos de tal forma que el software estádisponible para su uso inmediato.Los primeros incrementos actúan como prototipo paraayudar a obtener los requerimientos para incrementosposteriores.Bajo riesgo de fallar en el proyecto totalLos servicios de alta prioridad del sistema tienden aser más probados.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 12

Programación extrema●●Una aproximación al desarrollo basado en eldesarrollo y entrega de una pequeñísima partede los incrementos de funcionalidad.Depende de la constante mejora del código, laimplicación del usuario en el equipo dedesarrollo y la programación por parejas.● Tratado en el tema 17©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 13

Desarrollo en espiral●●●●el proceso se representa como una espiral enlugar de como una secuencia de actividadescon retroceso.Cada vuelta en la espiral representa una faseen el procesoNo hay fases fijas tales como la especificacióno el diseño – las vueltas en la espiral seescogen dependiendo de lo que se refiere.Los riesgos se valoran explícitamente y seresuelven durante el proceso.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 14

Modelo en espiral para el proceso deSoftwareDeterminar objetivos,alternativas yrestriccionesEvaluar alternativas eidentificar y resolver riesgosAnálisisde riesgosAnálisis deriesgosPlanear la siguiente faseRREVISIÓNPlan de requerimientosPlan de ciclo de vidaPlan de desarrolloIntegración yplan depruebaAnálisis deriesgosAnálisisde riesgosConcepto deoperaciónPrototipo 1Validación derequerimientosDiseño de V&VservicioPrototipo 2Requerimientos del softwarePrueba deaceptaciónPrototipo 3PrototipooperacionalSimulaciones, modelos, pruebas comparativasDiseño del productoDiseñosdetalladoPrueba deunidadesprueba deintegracióncódigoDesarrollo, verificar productodel siguiente nivel©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 15

Sectores del modelo en espiral●●●●Definición de objetivos• Se definen los objetivos específicos para cada fase.Evaluación y reducción de riesgos• Los riesgos se valoran y colocan en un sitio quereduzca los riesgos claveDesarrollo y validación• Se escoge un modelo de desarrollo para el sistemaque puede ser cualquiera de los modelos genéricos.Planeación• El proyecto se revisa y la siguiente fase de la espiral esplaneada.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 16

El Proceso Unificado Racional●●Es un modelo de proceso moderno que deriva deltrabajo sobre el UML y procesos asociados.Normalmente se describe desde 3 perspectivas• Una perspectiva dinámica que muestra las fases en eltiempo;• Una perspectiva estática que muestra las actividadesde proceso.• Una perspectiva práctica que sugiere buenas prácticaspara usar durante el proceso.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 17

Modelo de fase RUPFase de iteración o evoluciónOrigen Elaboración construcción Transición©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 18

Fases RUP●●●●Origen• Establecer el caso del negocio para el sistemaElaboración• Desarrollo y comprensión del ámbito del problemay de la arquitectura del sistema.Construcción• Diseño, programación y prueba del sistema.Transición• Despliegue del sistema en su entorno deexplotación.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 19

Buena práctica del RUP●●●●●●Desarrollo del software de forma evolutivaRequerimientos de direcciónUsar arquitecturas basadas en componentes.Modelos de software visualesVerificar la calidad del softwareControlar los cambios para el software©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 20

Puntos clave●●●●●Los procesos de software son las actividades implicadas enla producción y evolución de un sistema de softwareLos modelos de proceso de software son representacionesabstractas de esos procesosLas actividades generales son la especificación, diseño eimplementación, validación y evolución.Los ejemplos incluyen el modelo de cascada, el desarrolloevolutivo y la ingeniería de software basada en loscomponentes.Los modelos de proceso evolutivos describen los procesosde software como un ciclo de actividades.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 21