Ingeniería De Software I - Grial
INGENIERÍA DE SOFTWARE ITema 3: Modelos de proceso2º G.I.I.Fecha de última modificación: 20-2-2018Dr. Francisco José García Peñalvo / fgarcia@usal.esAlicia García Holgado / aliciagh@usal.esDepartamento de Informática y AutomáticaUniversidad de Salamanca
Ingeniería del Software IModelos de procesoResumenResumenDescriptoresBibliografíaSe presentan diferentes modelos de proceso clasificados por categorías.Se parte del modelo clásico o en cascada y diferentes variantes delmismo. Posteriormente, se abordan modelos más evolucionados comopueden ser los modelos evolutivos en los que se considera la naturalezacambiante del software, modelos específicos para sistemas orientados aobjetos o modelos basados en reutilización centrados en el uso ydesarrollo de componentes reutilizables. Asimismo, se abordan modelosmás recientes tales como los procesos ágiles que enfatizan laprogramación frente al análisis, diseño y documentación, y modelosenfocados al desarrollo de sistemas web.Modelos de proceso; ciclo de vida; fases; modelos evolutivos;reutilización; orientación a objetos; procesos ágiles; ingeniería web[Piattini et al., 2004] Capítulo 3[Pfleeger, 2002] Capítulo 2[Pressman, 2010] Capítulos 2 y 3[Sommerville, 2011] Capítulos 2 y 3Universidad de Salamanca – Dpto. de Informática y Automática2
Ingeniería del Software IModelos de procesoEsquemannnnnnnnnnnClasificación de los modelos de procesoModelos tradicionalesModelos evolutivosModelos para sistemas orientados a objetosModelos basados en reutilizaciónProcesos ágilesModelos para la Ingeniería WebAportaciones principales del temaEjerciciosLecturas complementariasReferenciasUniversidad de Salamanca – Dpto. de Informática y Automática3
Ingeniería del Software IModelos de proceso1. Clasificación de los modelos de procesoUniversidad de Salamanca – Dpto. de Informática y Automática4
Ingeniería del Software IModelos de procesoClasificación de los modelos de proceso (i)nExisten diferentes formas de clasificar los modelos de proceso en funciónde sus características y los tipos de sistemas a los que se aplicann Modelos tradicionalesnnModelos evolutivosnnTienen en cuenta la reutilización sistemática del softwareProcesos ágilesnnModelos con un alto grado de iteratividad y solapamiento entre fasesModelos basados en reutilizaciónnnSon modelos que se adaptan a la evolución que sufren los requisitos delsistema en función del tiempoModelos para sistemas orientados a objetosnnFormados por un conjunto de fases o actividades en las que no tienen encuenta la naturaleza evolutiva del softwareEnfatizan el desarrollo rápido, ponen el énfasis en la programaciónModelos para sistemas webnCreados específicamente para el desarrollo de aplicaciones webUniversidad de Salamanca – Dpto. de Informática y Automática5
Ingeniería del Software IModelos de procesoClasificación de los modelos de proceso (ii)nEjemplos de modelos de proceso de diferentes categoríasnnnModelos tradicionalesnModelos basados enreutilizaciónnClásico, lineal o en cascadanEstructuradonBasado en componentesnBasado en prototiposnProceso UnificadonDesarrollo rápido de aplicaciones (RAD)nModelos evolutivosProcesos ágilesnProgramación extrema (XP)nIncrementalnScrumnIterativonDesarrollo de software adaptativonEn espiralnCrystalModelos para sistemas orientadosa objetosnDe agrupamientonProceso UnificadoUniversidad de Salamanca – Dpto. de Informática y AutomáticanModelos para sistemas webnModelos de PressmannUML-based Web Engineering6
Ingeniería del Software IModelos de proceso2. Modelos tradicionalesUniversidad de Salamanca – Dpto. de Informática y Automática7
Ingeniería del Software IModelos de procesoModelo primitivo (i)nnnSe le conoce también con el nombre de Modelo Prueba yError o Modelo Codifica y MejoraProceso de desarrollo aplicado en las primeras experienciasde programaciónSupone una iteración de fases codificación-depuración sinninguna planificación ni diseños previosCodificaciónPruebaEmpezar acodificarComienzael proyectoUniversidad de Salamanca – Dpto. de Informática y AutomáticaContinuarcodificandoFinalTiempo8
Ingeniería del Software IModelos de procesoModelo primitivo (ii)nInconvenientesnCódigo pobremente estructurado tras varias iteracionesnCódigo espaguetinCaro de desarrollar por las numerosas recodificacionesnPosible rechazo del usuario al no existir análisis de requisitosnCaro de depurar por la falta de planificaciónnCaro de mantener por la falta de estructura y documentaciónUniversidad de Salamanca – Dpto. de Informática y Automática9
Ingeniería del Software IModelos de procesoModelos lineales o secuenciales (i)nHan sido ampliamente utilizadosnnOfrecen grandes facilidades a los gestores para controlar el progresode los proyectosProponen un enfoque sistemático, secuencial, para el desarrollo delsoftwarennnComienza en un nivel de sistemas y progresa con el análisis, diseño,codificación, pruebas y mantenimientoFases separadas en la especificación y el desarrolloLa filosofía de estos modelos de proceso no es realistannnNo se ajusta al proceso de desarrollo softwareRaramente sigue un flujo secuencial sino que exige diversasiteracionesNo ofrece un soporte adecuado a las técnicas de desarrollo basadasen objetos y componentesUniversidad de Salamanca – Dpto. de Informática y Automática10
Ingeniería del Software IModelos de procesoModelos lineales o secuenciales (ii)nModelo clásico (i)nnnConocido también como modelo lineal o “en cascada”Versión original se debe a W. Royce [Royce, 1970], pero aparecendespués numerosos refinamientosCaracterísticasnnnnnEstá compuesto por unaserie de fases que seejecutan secuencialmenteInvestigaciónpreliminarPaso de fase al conseguir los objetivosObtención de documentos como criteriode finalización de faseAnálisisDiseñoCodificaciónEl final de una fase puede suponer unpunto de revisiónSe encuentra definido en la normaestándar 2167-A del DoD de EEUUUniversidad de Salamanca – Dpto. de Informática y AutomáticaPruebaMantenimientoCiclo de vida clásico11
Ingeniería del Software IModelos de procesoModelos lineales o secuenciales (iii)nModelo clásico (ii)nnnnnApoyo a los gestoresDistintas configuracionesn Muchos modelos más complejos son variaciones del modelo en cascadaque incorporan lazos de realimentación y fases adicionalesModelo satisfactorio solo en desarrollos conocidos y establesEl desconocimiento y el riesgo suele ser alto en el desarrollo del softwaren Desconocimiento de las necesidades por parte del clienten Incomprensión de las necesidades por parte del proveedorn Inestabilidad de las necesidadesn Opciones tecnológicasn Movimientos de personalLa linealidad no se corresponde con la realidadn Los retornos de información entre las fases se hacen necesarios paraincorporar correcciones hacia arriba, en función de los descubrimientosrealizados hacia abajoUniversidad de Salamanca – Dpto. de Informática y Automática12
Ingeniería del Software IModelos de procesoModelos lineales o secuenciales (iv)nModelo clásico ón de requisitosDiseñoEspecificación de diseñoCodificaciónMódulos clo de vida clásico con realimentaciónUniversidad de Salamanca – Dpto. de Informática y AutomáticaSistema funcionandoy actualizado13
Ingeniería del Software IModelos de procesoModelos lineales o secuenciales (v)nModelo clásico (iv)nInconvenientesn Su progresión secuencial o lineal no refleja la manera en que realmentese desarrolla el software [Pfleeger, 2002; Pressman, 2006]n Es un modelo que adolece de rigidez [Pressman, 2010]nnnSe tarda mucho tiempo en pasar por todo el ciclo [Piattini et al., 2004]Es un modelo monolítico [Pressman, 2010]nnnExige al usuario que exponga explícitamente todos los requisitos al principio,presentando problemas para gestionar la incertidumbre natural propia delcomienzo de la mayoría de los proyectosHasta llegar a las etapas finales del desarrollo no habrá una versión operativadel programa, lo que influye negativamente en el descubrimiento a tiempo deerrores o incongruencias en los requisitosImpone una estructura de gestión de proyecto al desarrollo del sistema[McCracken y Jackson, 1981]No trata al software como un proceso de resolución de problemas [Curtiset al., 1987]Universidad de Salamanca – Dpto. de Informática y Automática14
Ingeniería del Software IModelos de procesoModelos lineales o secuenciales (vi)nModelo clásico (v)nConsideraciones finalesnnnnTiene un lugar destacado en la Ingeniería del SoftwareProporciona una plantilla para adecuar los métodosEs muy utilizadoTiene problemas pero es mejor que desarrollar sin guíasUniversidad de Salamanca – Dpto. de Informática y Automática15
Ingeniería del Software IModelos de procesoModelos lineales o secuenciales (vii)nModelo VnnnnEs una variación del modeloen cascada que demuestracómo se relacionan lasactividades de prueba conlas de análisis y desarrollo[GMD, 1992]Presenta una implantaciónascendenteDemuestra que el desarrollode las pruebas se efectúa demanera síncrona con eldesarrollo del programaMientras que el modeloclásico centra su atenciónen los documentos yartefactos producidos, elmodelo en V lo hace en laactividad y la exactitudOperación ymantenimientoValidar requisitosAnálisisDiseñoUniversidad de Salamanca – Dpto. de Informática y AutomáticaVerificar diseñoPruebasde aceptaciónPruebas deintegracióny de elo V16
Ingeniería del Software IModelos de procesoModelos basados en prototipos (i)nnUn prototipo es un modelo experimental de un sistema o de uncomponente de un sistema que tiene los suficientes elementos quepermiten su usoObjetivosnnnSon un medio eficaz para aclarar los requisitos de los usuarios e identificar lascaracterísticas de un sistema que deben cambiarse o añadirseMediante el prototipo se puede verificar la viabilidad del diseño de un sistemaCaracterísticasnnEs una aplicación que funcionaSu finalidad es probar varias suposiciones con respecto a las característicasrequeridas por el sistemanSe crean con rapideznEvolucionan a través de un proceso iterativonTienen un costo bajo de desarrolloUniversidad de Salamanca – Dpto. de Informática y Automática17
Ingeniería del Software IModelos de procesoModelos basados en prototipos (ii)nEnfoques de desarrollonnnDesechable: El prototipo es una versión rudimentaria del sistema queposteriormente es desechadaEvolutivo: El prototipo debe convertirse, eventualmente, en el sistema finalusado (alternativa al ciclo de vida) [Basili y Turner, 1975]Mixto (prototipado operativo) [Davis, 1992]nnSe aplican técnicas convencionales para los requisitos bien conocidosCombinación de prototipos desechables y evolutivos para los requisitos poco conocidosDESECHABLEEnfoque dedesarrolloEVOLUTIVORápido y sin rigorRigurosoQué construir problemáticasSólo las partesPrimero las partes bien entendidas.Sobre una base sólida.Directricesdel diseñoOptimizar el tiempo dedesarrolloOptimizar la modificabilidadObjetivoúltimoDesecharloIncluirlo en el sistemaDiferencias entre los prototipos desechables y evolutivosUniversidad de Salamanca – Dpto. de Informática y Automática18
Ingeniería del Software IModelos de procesoModelos basados en prototipos (iii)nPrototipos desechables (i)nCaracterísticasnnnnSe desarrolla código para explorar factores críticos para el éxito del sistemaLa implementación usa lenguajes y/o métodos de desarrollo más rápidosque los definitivosSe usa como herramienta auxiliar de la especificación de requisitos y eldiseñonDeterminar la viabilidad de los requisitosnValidar la funcionalidad del sistemanEncontrar requisitos ocultosnDeterminar la viabilidad de la interfaz de usuarionExaminar alternativas de diseñonValidar una arquitectura de diseño particularEste enfoque suele derivar en un modelo lineal una vez que el prototipo hacumplido su misiónUniversidad de Salamanca – Dpto. de Informática y Automática19
Ingeniería del Software IModelos de procesoModelos basados en prototipos (iv)nPrototipos desechables (ii)nCaracterísticasn Idea del software en líneasgenerales desde el punto de vistadel usuarionIdealmente sirve para identificar losrequisitos del softwarennIntroduce cierta flexibilidad en laintroducción de requisitosProceso iterativonLa iteración ocurre cuando elprototipo se pone a punto parasatisfacer las necesidades delcliente, permitiendo a la vez que eldesarrollador comprenda mejor loque necesita hacerUniversidad de Salamanca – Dpto. de Informática y AutomáticaObtención derequisitosDiseño rápidoConstruccióndel prototipoRefinamientodel prototipoEvaluacióndel prototipoProducto finalModelo de prototipos20
Ingeniería del Software IModelos de procesoModelos basados en prototipos (v)nPrototipos desechables (iii)nAplicacionesnInterfaz de usuarionFormatos de informesnFormatos de gráficosnOrganización de bases de datosnRendimiento de bases de datosnPrecisión e implementación de cálculos complejosnPartes con respuesta crítica en el tiempo en sistemas de tiempo realnRendimiento de sistemas interactivosnViabilidad de partes del sistema en las que no se tiene experienciaUniversidad de Salamanca – Dpto. de Informática y Automática21
Ingeniería del Software IModelos de procesoModelos basados en prototipos (vi)nPrototipado evolutivo (ciclo de vida iterativo)nCaracterísticasnnnnEnfoque de desarrollo que se utiliza cuando no se conoce con seguridad loque se quiere construirSe comienza diseñando e implementando las partes más destacadas delsistemaLa evaluación del prototipo proporciona la realimentación necesaria paraaumentar y refinar el prototipoEl prototipo evoluciona y se transforma en el sistema finalConceptoinicialDiseño eimplementacióndel prototipoinicialRefinar el prototipohasta que sea aceptableCompletar yentregar elprototipoModelo de prototipado evolutivoUniversidad de Salamanca – Dpto. de Informática y Automática22
Ingeniería del Software IModelos de procesoModelos basados en prototipos (vii)nVentajas del prototipadonnnnnPermite solventar objeciones delusuarioSirve para formalizar la aceptaciónpreviaIntroduce flexibilidad en la capturade requisitosEs útil cuando el área de aplicaciónno está definida, cuando el riesgo derechazo el alto, o como forma deevaluar el impacto de una aplicaciónEl prototipado es un subproceso quepuede incluirse como parte de otrosmodelos de procesonPor ejemplo puede combinarse conun ciclo en cascada para intentarsolventar ciertas carencias de esteUniversidad de Salamanca – Dpto. de Informática y AutomáticaModelo en cascada con prototipado [Pfleeger, 2002]23
Ingeniería del Software IModelos de procesoModelo basados en prototipos (viii)nInconvenientesn El sistema se puede llegar a deteriorar tendiendo hacia el modeloprimitivon Se suele refinar el prototipo hacia el sistema final en lugar dedesecharlo y empezar desde el principion El cliente puede encontrar atractivo el prototipo y quedarse con elprototipo como sistema finaln Relajación de los desarrolladoresn No disminuye el tiempo entre la definición de los requisitos y laentrega del producton Al usuario le desagrada que se deseche códigoUniversidad de Salamanca – Dpto. de Informática y Automática24
Ingeniería del Software IModelos de procesoDesarrollo rápido de aplicaciones (i)nnEl modelo de desarrollo rápido de aplicaciones, DRA (RAD – Rapid ApplicationDevelopment) o modelo de la caja de tiempo surgió como respuesta al modeloformal y al ciclo en espiralEnfatiza un ciclo de desarrollo extremadamente cortonnNo es un modelo bien definidonnnModelo funcional en 60 o 90 díasSecuencia de integraciones de un sistema evolutivo o de prototipos que se revisan con elcliente è descubrimiento de los requisitosCada integración se restringe a un período de tiempo bien definido (caja de tiempo)CaracterísticasnnnnnnModelo secuencial: Separación en fases de cada caja de tiempoIntegraciones constantesCentrado en el código más que en la documentaciónDesarrollo basado en componentesUso efectivo de herramientas y frameworksParticipación activa del usuarioUniversidad de Salamanca – Dpto. de Informática y Automática25
Ingeniería del Software IModelos de procesoDesarrollo rápido de aplicaciones (ii)Equipo nº 3Modeladode gestiónModeladoEquipo nº 2de datosModeladoModeladodeprocesosde gestiónGener. deModeladoaplicacionesde datosPruebas yModeladoModeladoentregade procesosde gestiónGener. deModeladoaplicacionesde datosPruebas yentregaEquipo nº 1Modeladode procesosnCuando se utiliza en S.I.Automatizados, comprendelas fases [Kerr y Hunter,1994]nnnnGener. denModelado de gestiónModelado de datosModelado del procesoGeneración de aplicacionesPruebas y entregaaplicacionesPruebas yentregaDe 60 a 90 díasModelo DRA [Kerr y Hunter, 1994]Universidad de Salamanca – Dpto. de Informática y Automática26
Ingeniería del Software IModelos de procesoDesarrollo rápido de aplicaciones (iii)nLas limitaciones de tiempo demandan un ámbito de escalasnSi una aplicación de gestión puede modularse de forma que puedacompletarse cada una de las funciones principales en menos de tresmeses, es un candidato del DRA. Cada una de estas funciones puedeser afrontadas por un equipo DRA diferente y ser integradas en unasola aplicaciónnInconvenientes [Butler, 1994]nLos proyectos grandes necesitan los recursos humanos suficientes paracrear el número correcto de equiposnSe requiere de un compromiso de las partes involucradasUniversidad de Salamanca – Dpto. de Informática y Automática27
Ingeniería del Software IModelos de proceso3. Modelos evolutivosUniversidad de Salamanca – Dpto. de Informática y Automática28
Ingeniería del Software IModelos de procesoModelos evolutivos (i)nnEl software, al igual que todos los sistemas complejos, evolucionan con eltiempo [Gilb, 1988]Se caracterizan porque permiten desarrollar versiones cada vez máscompletas del software, teniendo en cuenta la naturaleza evolutiva delsoftwarenPresentan la filosofía de poner un producto en explotación cuanto antesnnnEstán muy ligados a la idea de prototipado evolutivoExisten muchos modelos de proceso evolutivosLos modelos evolutivos son iterativos [Pressman, 2010]nSe caracterizan por la forma en que permiten a los ingenieros de softwaredesarrollar versiones cada vez más completas del producto software, quepuede ir entregándose al cliente en forma de incrementosUniversidad de Salamanca – Dpto. de Informática y Automática29
Ingeniería del Software IModelos de procesoModelos evolutivos (ii)nnnLos desarrollos orientados a objetos se ajustan a un modelo de procesoiterativo e incrementalSe puede argumentar lo mismo para los desarrollos basados encomponentesEsto es así porquennnLas tareas de cada fase se llevan a cabo de una forma iterativaA la vez que existe un ciclo de desarrollo análisis-diseño-implementaciónanálisis que permite hacer evolucionar al sistemaEn el desarrollo incremental el sistema se divide en un conjunto de particionesnnCada una se desarrolla de forma completa hasta que se finaliza el sistemaEsta idea de iteratividad máxima propia de la orientación a objetos hasido equiparada por autores como James Rumbaugh (1992) o L. B. S.Raccoon (1995) a las fractales o la teoría del caosUniversidad de Salamanca – Dpto. de Informática y Automática30
Ingeniería del Software IModelos de procesoModelo incremental (i)nnEn este modelo, el sistema, tal y como está especificado en laespecificación de requisitos del software, se divide ensubsistemas de acuerdo a su funcionalidadLas versiones se definen comenzando con un subsistemafuncional pequeño y agregando funcionalidad con cada nuevaversiónnnnCada nueva parte entregada se denomina incrementoCombina elementos del modelo en cascada con la filosofíainteractiva de construcción de prototiposAplica secuencias lineales de forma escalonada mientrasprogresa el calendario del proyectonCada secuencia lineal supone un incremento [McDermid y Rook, 1993]Universidad de Salamanca – Dpto. de Informática y Automática31
Ingeniería del Software IModelos de procesoModelo incremental (ii)Incremento 1AnálisisDiseñoCódigoEntrega delprimer incrementoPruebaIncremento 2AnálisisDiseñoCódigoPruebaEntrega delsegundo incrementoIncremento 3AnálisisDiseño.CódigoPruebaEntrega deltercer incremento.Tiempo de calendarioModelo incremental [Pressman, 2010]Universidad de Salamanca – Dpto. de Informática y Automática32
Ingeniería del Software IModelos de procesoModelo iterativo (i)nnEntrega un sistema completo desde el principio, para posteriormentecambiar la funcionalidad de cada subsistema con cada versiónCaracterísticas del ciclo iterativo [Muller, 1997]nnnnSe basa en la evolución de prototipos ejecutables, mensurables y evaluablesSe van incorporando cambios en cada iteraciónExige más atención e implicación de todos los actores del proyectoMinicascadannnnCada iteración reproduce el ciclo de vida en cascada, pero a una escala menorLos objetivos de cada iteración se establecen en función de la evaluación delas iteraciones precedentesLas fases tradicionales se cubre gradualmente en las diversas iteracionesLas actividades internas se solapan porque dentro de una iteración nonecesitan terminarse de golpe, siendo la transición entre dos actividadesprogresivaUniversidad de Salamanca – Dpto. de Informática y Automática33
Ingeniería del Software IModelos de procesoModelo iterativo (ii)PlanificaciónAnálisisAnálisisDiseñoN ntegraciónFasesUniversidad de Salamanca – Dpto. de Informática y AutomáticaEntregaTransiciónprogresiva34
Ingeniería del Software IModelos de procesoModelo iterativo (iii)nEvaluación de las iteracionesnnDeben definirse criterios de evaluación de las iteracionesUna iteración se marca por etapas intermedias que permitan medir losprogresos. Debe haber al menos dos etapasnnnRevisión inicial: fija los objetivos y criterios de la iteraciónRevisión de evaluación: valida los resultadosMitos sobre el ciclo de vida iterativo [Muller, 1997]nnnnnnEl ciclo de vida iterativo favorece los apañosEl ciclo de vida iterativo engendra problemasEl ciclo de vida iterativo e incremental exige recomenzar n veces hasta que elresultado sea el adecuadoEl ciclo de vida iterativo es una excusa para no planificar y gestionar unproyectoEl ciclo de vida iterativo sólo concierne a los desarrolladoresEl ciclo de vida iterativo favorece siempre añadir nuevas necesidades, sin finUniversidad de Salamanca – Dpto. de Informática y Automática35
Ingeniería del Software IModelos de procesoIncremental vs. iterativoDesarrollo incremental: sistema parcial, funcionalidad completaDesarrollo iterativo: sistema completo; funcionalidad parcialUniversidad de Salamanca – Dpto. de Informática y Automática36
Ingeniería del Software IModelos de procesoModelos en espiral (i)nModelo en espiralnnFue propuesto inicialmente por B. Boehm [Boehm, 1986, 1988]Es un modelo de proceso de software evolutivo, que proporciona elpotencial para el desarrollo rápido de versiones incrementales delsoftwarenCaracterísticasnPuede considerarse como un metamodelo de procesonnnReúne características del modelo clásico y de prototiposAparece el análisis de riesgoSe divide en un número de actividades estructurales, también denominadasregiones de tareas. En el modelo original de Boehm aparecen cuatroregiones de tareasnnPlanificación, Análisis de riesgos, Ingeniería, Evaluación del clienteEl avance se realiza desde el centro de la espiral hacia el exteriorUniversidad de Salamanca – Dpto. de Informática y Automática37
Ingeniería del Software IModelos de procesoModelos en espiral (ii)PlanificaciónAnálisis de riesgoDeterminar objetivos,alternativasy restriccionesEvaluar alternativas Identificar yresolver riesgosAnálisisde riesgoAnálisisde riesgoAnálisis Protode riesgo tipo 1Plan de requisitos ydel ciclo de vidaPlan de desarrolloPlan deintegración y pruebaPlan para la próxima faseOperaciónPrototipo 2Prototipo uisitosV&VdiseñoServicio.ipoot oot tivPr eraopAnálisisde uebasaceptación.Evaluación del clienteDesarrollo, verificación delsiguiente nivel del productoIngenieríaCiclo de vida en espiral [Boehm, 1988]Universidad de Salamanca – Dpto. de Informática y Automática38
Ingeniería del Software IModelos de procesoModelos en espiral (iii)nModelo en espiral de Pressman [Pressman, 2002]Variante del modelo de Boehm con 6 regiones de tareasnnSe define un eje con diferentes puntos de entrada para diferentes tipos deproyectosPlanificaciónAnálisis deriesgosComunicacióncon el clientePuntos de entrada al proyectoProyecto de mantenimiento de productosProyecto de mejora de productosingenieríaProyecto de desarrollo de productos nuevosProyecto de desarrollo de conceptosEvaluacióndel clienteConstrucción yadaptaciónModelo en espiral de PressmanUniversidad de Salamanca – Dpto. de Informática y Automática39
Ingeniería del Software IModelos de procesoModelos en espiral (iv)nModelo win-win [Boehm et al., 1998]nnExtiende el modelo en espiral haciendo énfasis en las condiciones de éxito(ganancia) de todas las partes involucradas en el proyectoConsta de cuatro ciclosnnnnCiclo 0. Grupos de aplicación: determinación de la viabilidad de un grupo deaplicacionesCiclo 1. Objetivos del ciclo de vida de la aplicación: objetivos, prototipos,planes, especificaciones de cada aplicación y arquitectura viableCiclo 2. Arquitectura del ciclo de vida de la aplicación: establecimiento de unaarquitectura detallada y verificación de su viabilidadCiclo 3. Capacidad de operación inicial: consecución de la capacidad para cadaetapa crítica del proyectoUniversidad de Salamanca – Dpto. de Informática y Automática40
Ingeniería del Software IModelos de procesoModelos en espiral (v)nModelo win-win [Boehm et al., 1998]Universidad de Salamanca – Dpto. de Informática y Automática41
Ingeniería del Software IModelos de procesoModelos en espiral (vi)nVentajasnnnnnnnnnnRefleja de forma más realista la idiosincrasia del desarrollo de softwareToma lo mejor y evita lo peor de los demás modelos, según la situación encada momentoLas opciones de reutilización se tienen en cuenta desde el primer momentoProporciona una preparación para la evolución, crecimiento y cambioProporciona un mecanismo para incorporar objetivos de calidad en eldesarrolloSe centra en la eliminación de errores y opciones no atractivas desde elprincipioDetermina el nivel de esfuerzo de cada fase en cada proyectoSe sigue el mismo procedimiento para el desarrollo que para elmantenimiento, con lo que se evitan los problemas de las “mejoras rutinarias”de alto riesgoPermite una gran flexibilidadSe adapta bien al diseño y programación orientado a objetosUniversidad de Salamanca – Dpto. de Informática y Automática42
Ingeniería del Software IModelos de procesoModelos en espiral (vii)nInconvenientesnNo ha sido desarrollado en el mundo de la contratación comercial sinoen el de desarrollo internonnnPuede resultar difícil convencer a grandes clientes de que el enfoqueevolutivo es controlableNecesita experiencia en la evaluación de riesgos, expertos, que nosiempre están disponiblesNecesita una elaboración adicional de los pasos del modeloUniversidad de Salamanca – Dpto. de Informática y Automática43
Ingeniería del Software IModelos de procesoModelos en espiral (viii)nDiferencias con otros modelos [Wolff, 1989]nnnnExiste un reconocimiento explícito de las diferentes alternativas paraalcanzar los objetivos del proyectoEl modelo se centra en identificar los riesgos de cada alternativa, asícomo las formas de solventarlosLa división de los proyectos en ciclos, cada uno con un acuerdo alfinal, implica que existe un acuerdo para los cambios a realizar o parala finalización del mismo, en función de lo aprendido a lo largo delproyectoEs un método que se adapta a cualquier tipo de actividad, alguna delas cuales no existen en otros paradigmas, como puede ser la consultaa asesores externosUniversidad de Salamanca – Dpto. de Informática y Automática44
Ingeniería del Software IModelos de proceso4. Modelos para sistemas orientados aobjetosUniversidad de Salamanca – Dpto. de Informática y Automática45
Ingeniería del Software IModelos de procesoModelos para sistemas orientados a objetos§ Surgieron por la dificultad de adaptar los modelos tradicionales aldesarrollo de sistemas orientados a objetos§ Características principales§ Eliminación de las fronteras entre fases§ En el desarrollo de software orientado a objetos están más difuminados loslímites entre fases§ Uso de componentes reutilizables§ Las características del software orientado a objetos (abstracción, herencia,encapsulamiento, ocultación de la información) favorecen la reutilización§ Alto grado de iteratividad y solapamiento§ Desarrollo incremental§ División del sistema en partes que se van desarrollando e integrandogradualmente por lo que el sistema puede ponerse en producción antes deestar totalmente terminadoUniversidad de Salamanca – Dpto. de Informática y Automática46
Ingeniería del Software IModelos de procesoModelo de agrupamiento (i)§ Propuesto por Bertrand Meyer [Meyer, 1990]§ Concepto clave: AGRUPAMIENTO (cluster) [Meyer, 1999]§ Unidad organizativa básica§ Grupo de clases relacionadas o, recursivamente, clusters relacionados§ Unidad natural para el desarrollo por parte de un único desarrolladornEvita el efecto todo-nada propio del modelo en cascada§ Tiene un componente secuencial y un componente concurrenten Existencia de diferentes subciclos de vida (uno para cada cluster) quepueden solaparse en el tiemponCada subciclo de vida que gobierna el desarrollo de un cluster está formadopornEspecificación, Diseño, Implementación, Verificación/Validación y GeneralizaciónUniversidad de Salamanca – Dpto. de Informática y Automática47
Ingeniería del Software IModelos de procesoModelo de agrupamiento (ii)§ Enfoque ascendente§ La ocultación de la información posibilita la forma del modelo de clustersTiempode
Universidad de Salamanca -Dpto. de Informática y Automática Ingeniería del Software I Modelos de proceso 3 Esquema n Clasificación de los modelos de proceso n Modelos tradicionales n Modelos evolutivos n Modelos para sistemas orientados a objetos n Modelos basados en reutilización n Procesos ágiles n Modelos para la Ingeniería Web n Aportaciones principales del tema
natura de algebra lineal de las titulaciones de Grado en Ingenier a de Materiales, Grado en Ingenier a en Tecnolog as Industriales y Grado en Ingenier a Qu mica, del Plan 2010, que se imparten en la ETSEIB y
Texts of Wow Rosh Hashana II 5780 - Congregation Shearith Israel, Atlanta Georgia Wow ׳ג ׳א:׳א תישארב (א) ׃ץרֶָֽאָּהָּ תאֵֵ֥וְּ םִימִַׁ֖שַָּה תאֵֵ֥ םיקִִ֑לֹאֱ ארָָּ֣ Îָּ תישִִׁ֖ארֵ Îְּ(ב) חַורְָּ֣ו ם
COMISIÓN DE INGENIER A MEC NICA PERFIL DEL PROFESIONAL EN INGENIER A MEC NICA COLEGIO CIEMI PROFESIÓN INGENIER A MEC NICA MANTENIMIENTO UNIDADES DE COMPETENCIA 2.1 Diseæar, dirigir, implementar y controlar el plan general de mantenimiento de los recursos (facilidades) y maquinaria pa
E.T.S. DE INGENIER IA INFORMATICA Apuntes de ALGEBRA LINEAL para la titulacion de INGENIER IA TECNICA EN INFORM ATICA DE GESTION Fco. Javier Cobos Gavala Amparo Osuna Lucena Rafael Robles Arias Beatriz Silva Gallardo
\Ingenier a Social el Arte del Hacking Personal" de ne a la Ingenier a Social como \El . utilizando herramientas integradas dentro del Kali Linux. Las pruebas de seguridad rea- . La investigaci on se realiz o en los laboratorios de inform atica de la Universidad T ecnica de Manab . Los
Conclusi n de la elaboraci n del Plan de Desarrollo de la licen-ciatura de Ingenier a Qu mica Actualizaci n a los lineamientos del plan curricular de la licenciatura de Ingenier a Qu mica, l neas 4 y 9 se logr la reacreditaci n de la licenciatura de Ing. Qu mica por parte del CACEI Implementaci n del
Grado en Ingenier a Inform atica G678 - Garant a y Seguridad en Sistemas y Redes Pr actica 3 Ingenier a inversa de malware 1. Introducci on 2. Objetivos
tres tipos principales de software: software de sistemas, software de aplicación y software de programación. 1.2 Tipos de software El software se clasifica en tres tipos: Software de sistema. Software de aplicación. Software de programación.
