Tema 2. Procesos de desarrollo de software complejos.

Transcripción

1 Ingeniería del Sftware II 2011 Tema 2. Prcess de desarrll de sftware cmplejs. Definición de mdel de prces. Un mdel de prces es un cnjunt de actividades que cnducen a la creación de un prduct sftware, n existe un prces ideal y su cmpsición depende del sistema sftware a desarrllar, pr l tant existen diferentes mdels enfques para el desarrll de sftware y distintas representacines abstractas. Ls mdels n se excluyen mutuamente y a menud se usan cnjuntamente en el desarrll de sistemas grandes. Aunque tds ls mdels de prces sn cmplejs se suelen clasificar en: Mdels de prcess pesads: Gran esfuerz de planificación, diseñ y dcumentación. Grandes equips, nrmalmente disperss espacialmente. Pryect de larga duración de gran tamañ. Mdels de prcess ligers ágiles: Si se busca la entrega de un sftware funcinal en un tiemp crt. Cm respuesta a uns requerimients cambiantes. Para el desarrll de aplicacines pequeñas específicas (pequeñs negcis, sftware cn muy pcas funcinalidades de pca cmplejidad). Tip de mdels de prces. Desarrll evlutiv Bases: Requerimients que cambian en el tiemp y expsición cntinúa a la crítica del usuari. Plazs estricts de finalización (cmpetencia). Buena cmprensión del prduct básic, per pca definición de ls detalles. Dirigid pr prttips (mdels): desarrll iterativ y gran refinamient a través de las diferentes versines del sistema. 1

2 Prblemas: Cnvertir un prttip en prduct final (mala calidad). El cliente ve l que parece ser una versión funcinal, cuand se le dice que hay que rehacerl n l entienden y piden uns pequeñs arregls. El desarrlladr cede. Pbre interacción entre las partes. Elements n adecuads (S.O., Interfaces, Algritms, ) que permanecen y pasan a frmar parte del prduct final cuand sól l eran del prttip. La evlución del prces es dificil de gestinar y cuantificar. Requiere herramientas y técnicas especiales para llevarse a cab. Pc adecuad para grandes sistemas sistemas muy cmplejs. Cuánd terminams? Se parará el desarrll cuand el prduct sea de calidad y cumpla cn ls requisits del cliente. Ventajas: Satisface las necesidades inmediatas del cliente. La especificación de requisits se puede realizar de md creciente. Este mdel de prces facilita la cmprensión del nivel de cmplejidad de la actividad de desarrllar sftware pr parte del usuari/cliente. Gran especificación de ls requisits. N es necesari cncerls tds para cmenzar el desarrll. Ls prttips sn versines funcinales n funcinales del sistema que sirven para valrar y crregir el desarrll del sftware. Prttip evlutiv: Trabaj cn el cliente para explrar sus requerimients y pder plasmarls en el sistema final. Sirve cm evaluación cntinua y punt de cntrl del cliente sbre las funcinalidades que se vayan implementand y la validación de las ya implementadas. Prttip desechable: Fmenta la cmprensión de las necesidades del cliente. Permite desarrllar una definición mejrada de ls requerimients del sistema. Se pueden centrar para definir analizar requisits pc clars cmplejs. Desarrll Incremental Bases: Es un enfque intermedi entre el mdel en cascada y el desarrll evlutiv. Se identifican y pririzan las funcines y servicis del sistema. 2

3 Se definen ls requerimients que prprcinan una varias funcinalidades cncretas y se pririzan pr imprtancia. Se realiza una definición detallada de ls requerimients a incluir en cada increment y el sistema de desarrll más adecuad para dich increment. Se integran ls nuevs requerimients implementads y se validan hasta que el sistema está cmplet. Prblemas: Ls increments deben ser relativamente pequeñs. Adaptar ls requerimients dentr de un increment de un tamañ cncret es difícil (estimar la carga de trabaj y el tiemp). La identificación de ls recurss cmunes a tds ls increments es difícil de identificar. Es necesari cncer bien el sistema para pder rdenar crrectamente las funcinalidades. Ventajas: Temprana implementación. Ls increments iniciales permiten refinar ls increments psterires ya que ayudan a cncer el sistema y sus necesidades. El cliente bserva el avance del pryect l que reduce el riesg de cancelación del mism. Se cnsigue un sistema final muy testead y pr l tant cn pcs falls. Al cntrari que en el evlutiv, intentams identificar la mayría de ls requisits. Al tener la perspectiva glbal del sistema, repartims ls requisits en trzs que vams a ir desarrlland en vueltas bteniend cada vez un prduct más cmplej. Prirización de requisits: se implementan primer las partes cn mayr priridad, las más imprtantes. El sistema final está muy prbad y cn pcs falls; al desarrllarse las partes más imprtantes al principi y realizar pruebas a cada vuelta, estas funcinalidades están muy prbadas y tienen una baja prpensión a fallar. Prces Unificad del Desarrll del sftware. Prpuest pr ls autres de UML (lenguaje unificad de desarrll). Principales aspects definitris: Dirigid pr cass de us. 3

4 Centrad en la arquitectura. Iterativ e incremental. Describe un enfque para la cnstrucción, desarrll y mantenimient del sftware, está pensad principalmente sbre el paradigma de rientación a bjets y cnstituye un marc de trabaj genéric que puede adaptarse fácilmente y que es cmúnmente aceptad cm el adecuad. Basad en cmpnentes intercnectads a través de interfaces. Utiliza UML para desarrllar ls esquemas y diagramas de un sistema sftware. Abarca: cicls, fases, flujs de trabaj, gestión de riesgs, cntrl de la calidad, gestión y planificación del pryect, cntrl de la cnfiguración y autmatización de ls prcess. Prpne dividir el sistema en trzs fáciles de desarrllar, estas divisines se cmunican a través de interfaces. Prpne desarrllar vistas estáticas y dinámicas (vista del mdel de ejecución y de la estructura del sistema). Prces integrad de desarrll que abarca cicls, fases, flujs, cntrles de calidad, etc. Dirigid pr Cass de Us. Para cnstruir un sistema cn éxit hay que cncer las necesidades y deses de ls futurs usuaris. Usuari: Persnas que trabajan y necesitan el sistema Otrs sistemas que interactúan cn el que estams desarrlland Interacción: Usuari inserta tarjeta en cajer autmátic. Usuari respnde sbre la pantalla a las preguntas que realiza el cajer. El usuari recibe una cantidad de diner y su tarjeta. 4

5 Una interacción así es un cas de us: Fragment de funcinalidad del sistema que prprcina al usuari un resultad imprtante. Utilidad cass de us: - Herramienta para especificar ls requisits de un sistema: representan ls requisits funcinales y junts cnstituyen el mdel de cass de us, que describe la funcinalidad ttal del sistema. - Guían el prces de desarrll (diseñ, implementación y prueba). Basándse en el mdel de cass de us, se crean mdels de diseñ e implementación. Se revisa cada mdel para que sean cnfrmes al mdel de cass de us. Se prueba la implementación para garantizar que ls cmpnentes del mdel de implementación implementan crrectamente ls cass de us. - N sól inician el prces de desarrll sin que éste sigue un hil de trabaj que parte de ls cass de us. Ls cass de us cnstituyen una técnica para recpilar requisits de usuari, histrias del manej de un sistema, etc. Otrs sistemas externs también pueden interactuar cn el nuestr. Ls cass de us guían el prces. Sn indispensables para desarrllar el rest de actividades; tant trs diagramas cm td tip de actividades. Se usan para td en td el sistema. Inician el prces y sn el fluj cnductr del mism. Interacción: secuencia de accines. Una sla acción n cnstituye un cas de us. Centrad en la arquitectura. La arquitectura de un sistema sftware se describe mediante diferentes vistas del sistema en cnstrucción: Influida pr diverss factres: Necesidades de la empresa, tal y cm las perciben ls usuaris y clientes. Otrs factres, cm platafrma de expltación (arquitectura hardware, sistema perativ, gestr de bases de dats, prtcls de cmunicación,...), cmpnentes reutilizables, sistemas heredads, requisits n funcinales... Es una vista del diseñ cmplet cn las características más imprtantes resaltadas, dejand ls detalles de lad. Hay una cnstante interacción entre ls cass de us y la arquitectura, que evlucinan en paralel: 5

6 Ls cass de us deben encajar en la arquitectura cuand se realizan. La arquitectura debe permitir el desarrll de tds ls cass de us requerids. El arquitect Realiza un esquema en brradr de la arquitectura que n es específica de ls cass de us (pr ejempl, la platafrma). Trabaja cn un subcnjunt de ls cass de us principales del sistema, especificándl en detalle y realizándl en términs de subsistemas, clases y cmpnentes. A medida que ls cass de us se especifican y maduran, se descubre más de la arquitectura, l que a su vez lleva a la maduración de más cass de us Este prces cntinúa hasta que se cnsidera que se dispne de una arquitectura estable. El Prces Unificad del Desarrll del sftware permite: Ganar y retener el cntrl intelectual sbre el pryect para así administrar la cmplejidad del sistema. Facilita el desarrll basad en cmpnentes. Prvee una base efectiva para la reutilización códig. 6

7 Prvee de una base para la gestión del pryect. Arquitectura: manera de describir un sistema mediante diferentes vistas. Está influida pr diverss factres: necesidades de la empresa, hardware, requisits n funcinales, sistemas heredads, etc. La elección de arquitectura tiene que ver cn varis factres cm la seguridad. El prces unificad es centrad en la arquitectura prque se enfatiza el us de esas vistas y la arquitectura se desarrlla en paralel al sistema. Facilidad para cntrlar el pryect, administración de cmplejidad. Facilita el entendimient del sistema, cn mayr menr cmplejidad. Iterativ e incremental. El trabaj se divide en partes más pequeñas minipryects: Minipryect: una iteración que resulta en un increment: Iteración: pass en el fluj de trabaj. Increment: crecimient del prduct. Las iteracines están cntrladas y planificadas. Factres para seleccinar l que se implementará en una iteración: La iteración se centra en un grup de cass de us que junts amplían la utilidad del prduct desarrllad hasta ahra. La iteración trata ls riesgs más imprtantes. Las iteracines sucesivas se cnstruyen sbre ls artefacts de desarrll tal cm quedarn al final de la última iteración: En las primeras fases del cicl de vida ls increments implican mdificacines. En las últimas fases ls increments implican mens mdificacines y más añadids a ls mdels. Cada iteración se cmpne de ls siguientes pass: Identificación y especificación de ls cass de us relevantes. Creación de un diseñ utilizand la arquitectura seleccinada cm guía. Implementación del diseñ mediante cmpnentes. Verificación de que ls cmpnentes satisfacen ls cass de us. Si una iteración cumple cn sus bjetivs, el desarrll cntinúa cn la siguiente iteración. Si n, se revisan las decisines previas y se adpta un nuev enfque. Ventajas: 7

8 Reducción del cste del riesg a ls cstes de un sl increment. Reducción del riesg de n sacar al mercad el prduct en el calendari previst. Se acelera el ritm del esfuerz de desarrll en su ttalidad, para btener resultads clars a crt plaz. Ls requerimients del usuari se van refinand en iteracines sucesivas, pr l que se pueden acmdar mejr ls cambis. Mantiene un equilibri entre definir un cnjunt cncret de requisits al inici del desarrll y la realidad dnde ls requisits varían a l larg del pryect. Ls riesgs se reducen a una iteración debid a las pruebas de cada increment. Mayr entendimient del sistema, se acelera el ritm. Refinamient de ls requisits en sucesivas iteracines. El Prces Unificad del Desarrll del sftware se repite a l larg de una serie de cicls. Cada cicl cncluye cn una nueva versión del prduct y cnsta de cuatr fases divididas a su vez en iteracines. Inici. Descripción del prduct a partir de una idea inicial y análisis del negci. Principales funcines del sistema y usuaris más imprtantes (mdels de cass de us). Es psible que se diseñe arquitectura del sistema. Plan del pryect, cste y gestión de riegs. Visión y especificación cmplementaria, glsari y trs artefacts. Elabración. Se diseñan tdas las partes y se cnstituye la arquitectura del sistema. Se especifican en detalle ls principales cass de us. Se diseña el núcle central de la arquitectura del sistema. Prsigue la gestión de riesgs. Se btiene el mdel de dmini y el mdel cnceptual del sistema a desarrllar. Se implementa y prueba la arquitectura. Se planifican las actividades y se estiman ls recurss necesaris para finalizar el pryect de un md realista. Se crean nuevas versines de tds ls artefacts y manuales preliminares para ls usuaris del sistema. Cnstrucción. En esta fase se cnstruye (cdifica) el sistema en sí. Se crea el prduct añadiend el sftware a la arquitectura. Se ejecuta el plan planificad y se cdifican tdas las partes del sistema. Transición. Se valida y verifica el prduct. Se prueba el prduct mediante un entrn real dnde ls usuaris analizan sus defects y deficiencias. Se crrigen ls prblemas y se incrpran las sugerencias de ls usuaris. Se terminan tds ls artefacts. Se adjuntan licencias, cntrats y referencias de sprte. Se maquetan manuales de usuari, peradr y administradr. 8

9 Puede impartirse frmación sbre el sistema. División en minipryects: una iteración que resulta en un increment. Cn cada iteración es muy psible que btengams alguna funcinalidad. Cada iteración se centra en un grup de cass de us empezand pr ls que tengan mayr riesg. Las iteracines se cnstruyen sbre ls artefacts tal y cm quedarn al final de la última iteración; entendiend cm artefact cualquier dcument archiv resultante de la anterir iteración. Es un prces iterativ cntrlad. 9