Modelos de Desarrollo Metodologias_Jacrek

Universidad Nacional De La Amazonia Peruana

Modelos de Desarrollo Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final. Un modelo de desarrollo establece el orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades. Es nece necesa sari rio o dest destac acar ar el cicl ciclo o de vida vida del del proy proyec ecto to y el mo mode delo lo de desarrollo. El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo. El modelo de desarrollo nos ayuda a la forma en la que vamos a construir el producto. Ambos se complementan para generar el producto desde el punto de vista técnico y administrativo. La ingeniería de software tiene varios modelos, paradigmas o filosofías de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos: I. Modelo en cascada o Clásico (modelo tradicional) II. Modelo en espiral (modelo evolutivo) III. Modelo de prototipos IV. Desarrollo por etapas V. Desarrollo iterativo y creciente o Iterativo e Incremental VI. RAD (Rapid Application Development)

I.

EL MODELO DE CASCADA

El modelo de cascada es también conocido como Modelo en cascada o Modelo lineal secuencial o Ciclo de vida básico o Ciclo de vida clásico. Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentación entre etapas, y una guía para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del retrabajo involucrado en retroalimentaciones a través de muchas etapas. Es uno de los método más usados usados en desarrollo desarrollo de software software y que ha sido exitoso durante décadas tanto en el desarrollo de grandes sistemas como en el de pequeños. Existen Existen ocasiones en que los requisitos requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comu co muni nica caci ción ón a trav través és del del despl desplieg iegue ue de una una ma maner nera a ca casi si line lineal al.. Esta Esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, una adaptación a un soft softwa ware re co cont ntab able le debi debido do a los ca camb mbio ioss en las las regu regula laci cion ones es del del gobierno). Esto puede ocurrir también en un número limitado de proyectos de nuevos nuevos desarr desarrollo ollos, s, pero pero sólo sólo cuando cuando los requerim requerimient ientos os están están bien bien definidos y son estables en forma razonable,

ALUMNO: JACK JAREK SILVANO TAMANI


El modelo algunass veces veces llamado llamado el ciclo modelo en cascada cascada,, alguna ciclo de vida vida clásic clásico, o, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las las déca década dass pasa pasada das, s, las las crit critic icas as a este este mo mode delo lo de proc proces eso o han han ocasionado ocasionado que aun sus más fervientes practicantes practicantes hayan cuestionado cuestionado su eficacia. eficacia. Entre los problemas problemas que algunas algunas veces se encuentran encuentran al aplicar aplicar el modelo en cascada están: 1. Es muy muy raro raro que que los proyec proyecto toss rea reale less siga sigan n el flujo flujo secu secuenc encia iall que que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa. 2. Con frecuencia es difícil para el cliente establecer todos los requisitos de mane ma nera ra expl explíc ícit ita. a. El mo mode delo lo en ca casc scad ada a lo requ requie iere re y se enfr enfren enta tan n dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 3. El clie client nte e debe debe tene tenerr paci pacien enci cia. a. Una Una vers versió ión n que que func funcio ione ne de los los programas estará disponible cuando el proyecto esté muy avanzado. Un error error grav grave e será será desa desast stros roso o si no se detec detecta ta ante antess de la revis revisió ión n del del programa. En un análisis interesante de proyectos reales, Bradac concluyó que la naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser más común al principio y al final del proceso secuencial. En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de cambios (de características, funciones y contenido de la información). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en situac situacion iones es donde donde los requer requerimie imiento ntoss están están fijos fijos y donde donde el trabaj trabajo o se realiza, hasta su conclusión, de una manera lineal.

VENTA VENTAJAS JAS ...


Universidad Nacional De La Amazonia Peruana ✔

✔

✔ ✔ ✔

Excelente cuando se tiene un producto estable y se conoce la tecnología. Es un método muy estructurado que funciona bien con gente de poca experiencia. Provee estabilidad en los requerimientos. La planeación se puede hacer anticipadamente. Para proyectos grandes.

DESVEN DES VENTAJ TAJAS AS ... .. . ✔ ✔ ✔

✔ ✔ ✔ ✔

I.

Tiene poca flexibilidad. Los proyectos en la práctica raramente siguen un flujo secuencial. Siempre es difícil para el cliente mostrar todos los requerimientos explícitamente y con mucha anticipación. El cliente debe tener paciencia. Es inflexible y no motiva al cambio. Poco apropiado para aplicaciones para la toma de decisiones. Los usuarios tienen una participación limitada.

EL MODELO DE ESPIRAL

El modelo Espiral de Boehm para Ingeniería de Software agrupa las mejores características del modelo del ciclo de vida clásico y de prototipos. Pero tamb tambié ién n agreg agrega a nueva nuevass func funcion iones es que que no está están n incl inclui uida dass en los los otro otross mode mo delo los, s, co como mo el anál anális isis is de rie riesg sgo. o. El mo model delo o espir espiral al defi define ne cuat cuatro ro actividades principales para el ciclo de vida: · Planificación La determinación de los objetivos del proyecto, alternativas y restricciones. · Análisis de Riesgo El análisis de alternativas y la identificación y solución de riesgos. · Ingeniería Desarrollo del producto. · Evaluación del cliente El asentimiento de los resultados de la ingeniería. El modelo es representado por una espiral dividida en cuatro cuadrantes, en que cada cada uno descri describe be las activid actividades ades mencion mencionada adass anterio anteriormen rmente. te. El modelo espiral utiliza un esquema de desarrollo iterativo donde la primera iterac iteración ión comienz comienza a en el centro centro del círcul círculo o e, increme incrementa ntalmen lmente, te, se va desp desplaz lazan ando do haci hacia a afuer afuera. a. La Lass sigu siguien iente tess itera iteraci cion ones es suce sucesi siva vass son son versi version ones es má máss co comp mplet letas as del del soft softwa ware re que que está está sien siendo do co cons nstr trui uido do.. Al principio de cada iteración del ciclo de vida se hace un análisis de riesgo, mientras, por el otro extremo, la revisión del proyecto se realiza al final de la itera iteraci ción ón.. Así, Así, se pued puede e co cont ntra rarr rres esta tarr cual cualqu quier ier rie riesg sgo o obse observa rvado do mediante las acciones adecuadas en el tiempo preciso.



El modelo espiral es visto como un enfoque más realista para el desarrollo de grandes sistemas de software. Usa un método evolucionario para desarrollo y prototipos como una técnica de reducción de riesgo (pese a que los prototipos pueden ser usados en cualquier etapa dentro del ciclo de vida). También utiliza el enfoque de desarrollo en etapas' del ciclo de vida clásico, pero, con sistematización y el 'desarrollo la diferencia que todos están incorporados dentro del esquema iterativo planteado por el modelo espiral.

VENTA VENTAJAS JAS ... ✔

✔ ✔ ✔ ✔

El prod produc ucto to avan avanza za a paso pasoss firm firmes es solu soluci cion onad ado o rie riesg sgos os en ca cada da iteración. El producto termina con todos los riesgos resueltos. Se pueden incluir otros métodos de desarrollo en las iteraciones. A medida que el costo aumenta, los riesgos se reducen. Se tienen puntos de control en cada interacción.

DESVEN DES VENTAJ TAJAS AS ... .. . ✔ ✔ ✔

✔

Es complicado. Requiere de mucha administración. Difícil Difícil de definir definir los objeti objetivos vos,, metas metas que indique indiquen n que podemo podemoss avanzar al siguiente ciclo. Se puede caer en un desarrollo de nunca acabar.

I. MODELO DE PROTOTIPOS Es un método menos formal de desarrollo. El prototipeo es una técnica para comprender las especificaciones. Un prototipo puede ser eliminado. Un prototipo puede llegar a ser parte del producto final. Una definición de un prototipo en software podría ser: Las fases que comprende el método de desarrollo orientado a prototipos serían: · Investigación Investigación preliminar


Universidad Nacional De La Amazonia Peruana Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estu estudi dio o de fact factibi ibilid lidad ad que que determ determin ine e la fact factibi ibilid lidad ad de una una soluc solució ión n software. · Definición de los requerimientos del sistema El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el desarrollador dete determ rmin ina a los los requ requis isit itos os me medi dian ante te la co cons nstr truc ucci ción ón,, demo demost stra raci ción ón y retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle luego de esta descripción. · Diseño técnico Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño diseño técnico tiene dos etapas: etapas: por un lado, la producción producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo requerido para promover cualquier mantención futura del software.

· Programación y prueba Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos. · Operación y mantención La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sist sistema ema al hace hacerr las prue prueba bass de prot protot otip ipos os.. Adem Además ás,, la ma mant ntenc ención ión también debería ser una fase menos importante, ya que se supone que el refin finamien iento del prototipo permitir itiría ía una mejor jor clar laridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si event eventua ualme lment nte e se requi requiri ries ese e una una ma mant ntenc ención ión ento entonc nces es el proce proceso so de prototipado es repetido y se definirá un nuevo conjunto de requerimientos. La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definición de requ requer erim imie ient ntos os co cons nsis iste te de cinc cinco o etap etapas as entr entre e dos dos de las las cual cuales es se establece un ciclo iterativo: · Análisis grueso y especificación especificación El prop propós ósit ito o de esta esta subf subfas ase e es desa desarr rrol olla larr un dise diseño ño bási básico co para para el prototipo inicial. · Diseño y construcción El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario.



· Evaluación Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los requer requerimie imiento ntoss adicion adicionales ales del sistema sistema y verific verificar ar que el protot prototipo ipo desarrolla llado lo haya sido en concordan dancia con la defi efinició ición n de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonc entonces es el desarr desarrolla ollador dor simplem simplement ente e corrige corrige el protot prototipo ipo antes antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proc proces eso o de eval evalua uaci ción ón pued puede e ser ser dividi dividido do en cuat cuatro ro paso pasoss sepa separa rado dos: s: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado. · Modificación Esto ocurre cuando la definición de requerimientos del sistema es alterada en la subfase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios. · Término Una Una vez vez que que se ha desa desarr rrol olla lado do un prot protot otip ipo o esta establ ble e y co comp mple leto to,, es nece necesa sario rio poner ponerse se de ac acuer uerdo do en rela relaci ción ón a aspec aspecto toss de ca calid lidad ad y de representación del sistema. En la siguiente figura se puede ver un esquema en que estas etapas se realizan realizan,, note note que la especi especific ficaci ación ón de requer requerimie imiento ntoss está está claram clarament ente e diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sería una visión la solución final en etapas tempranas tempranas del desarrollo, desarrollo, reduciendo tempranamente tempranamente los costos de especificaciones erróneas.

VENTA VENTAJAS JAS ... ✔ ✔ ✔ ✔ ✔

Útiles cuando los requerimientos son cambiantes. Cuando no se conoce bien la aplicación. Cuando el usuario no se quiere comprometer con los requerimientos. Cuando se quiere probar una arquitectura o tecnología. Cuando se requiere rapidez en el desarrollo.

DES VENTAJ VEN TAJAS AS... ... ✔ ✔ ✔ ✔

I.

No se conoce cuando se tendrá un producto aceptable. No se sabe cuantas iteraciones serán necesarias. Da una falsa ilusión al usuario sobre la velocidad del desarrollo. Se puede volver el producto aún y cuando no este con los estándares.

EL MODELO DE ETAPAS

Gustavo Donoso:

En 1956, el enfr enfre entarse a un gran sistema de software como el Semi−Automated Ground Environment (SAGE) hizo que se reconocieran los ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana problemas problemas inherentes inherentes a la codificación codificación y esto llevó al desarrollo desarrollo del modelo de etapas, con el objetivo de poder mejorar estos nuevos problemas. Este modelo estipula que el software será desarrollado en sucesivas etapas: · Plan operativo Etapa donde se define el problema a resolver, las metas del proyecto, las metas de calidad y se identifica cualquier restricción aplicable al proyecto.

· Especificación de requerimientos Permit Permite e entr entreg egar ar una una visi visión ón de alto alto nivel nivel sobr sobre e el proy proyec ecto to,, poni ponien endo do énfa énfasi siss en la desc descri ripc pció ión n del del prob proble lema ma desde desde el punt punto o de vista vista de los client clientes es y desarr desarrolla ollador dores. es. También También se consid considera era la posibi posibilid lidad ad de una planificación de los recursos sobre una escala de tiempos. · Especificación funcional Especifica la información sobre la cual el software a desarrollar trabajará. · Diseño Permite describir como el sistema va a satisfacer los requerimientos. Esta etapa a menudo tiene diferentes niveles de detalle. Los niveles más altos de detalle generalmente describen los componentes o módulos que formarán el software a ser producido. Los niveles más bajos, describen, con mucho detalle, cada módulo que contendrá el sistema.

· Implementación Aquí es donde el software a ser desarrollado se codifica. Dependiendo del tamaño del proyecto, proyecto, la programación programación puede ser distribuida distribuida entre distintos distintos programadores o grupos de programadores. Cada uno se concentrará en la construcción y prueba de una parte del software, a menudo un subsistema. Las pruebas, en general, tiene por objetivo asegurar que todas las funciones están correctamente implementadas dentro del sistema. · Integración Es la fase donde todos los subsistemas codificados independientemente se jun junta tan. n. Ca Cada da secc secció ión n es enla enlaza zada da co con n otra otra y, enton entonce ces, s, prob probad ada. a. Este Este proceso se repite hasta que se han agregado todos los módulos y el sistema se prueba como un todo.

· Validación y verificación Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es probado para verificar que el sistema es consistente con la definición de requerimientos y la especificación funcional. Por otro lado, la verificación cons co nsis iste te en una una seri serie e de ac acti tivi vida dade dess que que aseg asegur uran an que que el soft softwa ware re implementa correctamente una función específica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente de explotación. · Mantención La mantención ocurre cuando existe algún problema dentro de un sistema existente, e involucraría la corrección de errores que no fueron descubiertos en las fases de prueba, mejoras en la implementación de las unidades del sistema y cambios para que responda a los nuevos requerimientos. Las mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva. ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana El mo mode delo lo de etap etapas as co cons nsid ider erab aba a que que ca cada da una una de ella ellass debe deberí ría a ir a contin continuac uación ión de la anterio anterior, r, ponien poniendo do énfasi énfasiss en la documen documentac tación ión que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificación y de control. Todo tendiente a conformar una cadena de producción de software, de manera similar a una cadena de montaje de automóviles. Pero ello no logra que las causas de fondo que hicieron que se replantease el modelo de codificar y fijar desapareciesen. Todavía existe la distancia entre el programador (ahora desarrollador) y el usuario, esta distancia está dada por dominios de acción distintos. La iteración de aproximación es ahora más factible, pero también resulta onerosa, es necesario instalar todo el soft softwa ware re nueva nuevamen mente te en la ca cade dena na de mo mont ntaj aje e para para su revis revisió ión n y reconstrucción. II.

EL MODELO DESARROLLO ITERATIVO Y CRECIENTE O ITERATIVO E INCREMENTAL

Combina Combina element elementos os del modelo modelo en cascad cascada a aplica aplicado do en forma forma iterat iterativa. iva. Como se muestra en la figura, el modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podría realizar funciones básicas de administración de arc archivo hivoss, edic dición ión y prod produc uccción ión de docu docume ment ntos os;; en el segun egundo do incremento, incremento, ediciones más sofisticad sofisticadas, as, y tendría tendría funciones funciones más complejas complejas de prod produc ucci ción ón de docu documen mento tos; s; en el terc tercer er incr increm emen ento to,, func funcio ione ness de corrección corrección ortográfica ortográfica y gramatical; gramatical; y en el cuarto, cuarto, capacidades capacidades avanzadas avanzadas de co confi nfigu gura raci ción ón de pági página na.. Se debe debe tener tener en cuen cuenta ta que que el flujo flujo del proceso de cualquier Modelos de desarrollo de software incremento puede incorporar el paradigma de construcción de prototipos que se expone más adelante. A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos básicos, pero muchas características suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se desarrolla un plan plan para para el incr increme ement nto o sigu siguien iente te.. El plan plan afron afronta ta la mo modi dific ficac ació ión n del del producto producto esencial con el fin de satisfacer satisfacer de mejor manera las necesidades necesidades del cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual igual que la constr construcc ucción ión de protot prototipo iposs y otros otros enfoque enfoquess evolut evolutivos ivos,, es iterativo iterativo por naturaleza. naturaleza. Pero a diferencia diferencia de la construcción construcción de prototipos prototipos,, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones “incompletas del produc producto to final, final, pero pero propor proporcio cionan nan al usuario usuario la funcion funcionali alidad dad que necesita y una plataforma para evaluarlo.



El desarrollo incremental es útil sobre todo cuando el personal necesario para para una una impl impleme ement ntac ación ión co comp mplet leta a no está está dispo disponi nibl ble. e. Lo Loss prime primero ross incr increm ement entos os se puede pueden n implem implemen enta tarr co con n me meno noss gent gente. e. Si el produ product cto o esencial es bien recibido se agrega (si se requiere) más personal para implementar el incremento siguiente. Además, los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podr podría ía requ requer erir ir la disp dispon onib ibil ilid idad ad de un hard hardwa ware re nuev nuevo o que que está está en desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permit permitiría iría la entreg entrega a de funcio funcionali nalidad dad parcia parciall a los usuario usuarioss finales finales sin retrasos desordenados.

VENTA VENTAJAS JAS ... ✔

✔

La solución se va mejorando en forma progresiva a través de las múltiples iteraciones. Incrementa el entendimiento del problema y de la solución por medio de los refinamientos sucesivos.

DES VENTAJ VEN TAJAS AS... ... ✔

Requiere de mucha planeación, tanto administrativa como técnica.

✔

Requiere de metas claras para conocer el estado del proyecto.

I.

EL MODELO RAD (RAPID APPLICATION DEVELOPMENT).

desarrollo rápido de aplicaciones aplicaciones (RAD) es un modelo de proceso de El desarrollo software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción

basado en componentes. Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 días). días). Como otros modelos modelos de proceso, proceso, el enfoque enfoque DRA cumple con las actividades genéricas del marco de trabajo que ya se ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana han presentado. La comunicación trabaja para entender el problema de negocios y las características de información que debe incluir el software. La esenci cial al porq porque ue vari varios os equipo equiposs de soft softwa ware re trab trabaj ajan an en planeación es esen paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases: modelado de negocios, modelado de datos y modelado del proceso y establece representaciones del diseño que sirven como base para la actividad de construcción del modelo DRA. La construcción resalta el empl em pleo eo de co comp mpon onen ente tess de soft softwa ware re exis existe tent nte e y la apli aplica caci ción ón de la generación automática de código. Por último, el despliegue establece una base para las iteraciones subsecuentes, si éstas son necesarias. El modelo de proceso proceso DRA se ilustra en la siguiente siguiente figura. Es obvio que las restr restric icci cion ones es de tiemp tiempo o impues impuesta tass sobr sobre e un proyec proyecto to DRA DRA exige exigen n un "ámbito de escalas". Si una aplicación de negocios se puede modular de forma que cada gran función pueda completarse en menos de tres meses (mediante la aplicación del enfoque ya descrito), ésta es una candidata para el DRA. Cada gran función se puede abordar mediante un equipo de DRA por separado, para después integrarlas y formar un todo.

Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes: 1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear en número correcto de equipos DRA. 2) Si los desarrolladores y clientes no se comprometen con las actividades rápidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA fallarán. 3) Si un sistema no se puede modular en forma apropiada, la construcción de los componentes necesarios para el DRA será problemática. ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana 4) Si el alto alto rendim rendimie ient nto o es un aspec aspecto to impor importa tant nte, e, y se alca alcanz nzar ará á al convertir interfaces en componentes del sistema, el enfoque DRA podría no funcionar. 5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías).

METODOLOGÍA DE DESARROLLO DE SOFTWARE Las metodolog logías de desa esarrollo de softw ftware son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software. DEFINICIONES: 1. son un conjunto de procedimientos, técnicas y ayudas para el desarrollo de productos software. software. En si pasos naturales o lógicos lógicos para la construcción construcción de software. 2. se definen definen como un con con junto junto de pasos pasos como análisis análisis diseño diseño desarrollo desarrollo implementació implementación n pruebas pruebas y implantación implantación llamados llamados ciclo de vida como una definición general. 3. Es conjunto ordenado de pasos a seguir para llegar a la solución de un problem problema a u obtenc obtención ión de un produc producto to osea osea el softwa software, re, son también también los pasos generales que sigue el proceso de desarrollo de un producto software. Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software.

CARACTERISTICAS DESEABLES DE UNA METODOLOGIA Existencia de reglas predefinidas Cobertura total del ciclo de desarrollo Verificaciones intermedias Planificación y control Comunicación efectiva Utilización sobre un abanico amplio de proyectos Fácil formación Herramientas CASE Actividades que mejoren el proceso de desarrollo Soporte al mantenimiento Soporte de la reutilización de software Una Una me meto todo dolog logía ía de desar desarro rollo llo de soft softwa ware re es un co conju njunt nto o de paso pasoss y proc proced edim imie ient ntos os que que debe deben n segu seguir irse se para para desa desarr rrol olla larr soft softwa ware re.. Una Una metodología está compuesta por: Cómo dividir un proyecto en etapas. ✔ Qué tareas se llevan a cabo en cada etapa. ✔ Qué restricciones deben aplicarse. ✔ Qué técnicas y herramientas se emplean. ✔ Cómo se controla y gestiona un proyecto. ✔ • • • • • • • • • • •



Clasificación de las metodologías metodologías Las metodologías se clasifican de la siguiente forma: a. Estr Estruc uctu tura rada das. s. ○

Orientadas a procesos

○

Orientadas a datos

○

Mixta

b. No estr estruc uctu tura radas das.. ○

Orientadas a objetos

○

Sistemas de tiempo real

a.

Metodologías estructu cturadas

Se basan en la forma top-down Metodologías orientadas a procesos

La ingeniería del software se basa en el modelo básico entrada/proceso/salida de un sistema. Está compuesta por: Diagrama de flujo de datos (DFD). Diccionario de datos. Especificaciones de proceso. Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon.

de

•

•

•

Metodologías orientadas a datos Son Son metod metodol olog ogía íass basa basada dass en la info inform rmac ación ión.. Prime Primero ro se defin definen en las las estr estruc uctu tura rass de dato datoss y, a part partir ir de ésto éstos, s, se deriva derivan n los los co comp mpon onen ente tess procedimentales.

Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr.

a.

Metodologías no no es estructuradas

Metodologías orientadas a objeto La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos.

Tiene dos enfoques distintos: •

•

Romp mpen en co con n las las me meto todo dolo logí gías as Revolucion Revolucionario ario,, puro u ortodoxo . Ro

tradicionales. Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock. Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman elementos de uno y otro tipo. Ejemplos: metodología OMT de Rumbourgh.

Sistemas de tiempo real Procesan información orientada al control más que a los datos. Se caracterizan por concurrencia, priorización de procesos, comunicación entre tareas y acceso simultáneo a datos comunes. ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana En general las metodologías llevan a cabo una serie de procesos comunes que son buenas buenas prácti prácticas cas para para lograr lograr los objeti objetivos vos antes antes menciona mencionados dos independientemente de cómo hayan sido diseñadas. Las fases que agrupan estos procesos son las siguientes: •

Análisis

•

Especificación

•

Diseño

•

Programación

•

Prueba

•

Documentación

•

Mantenimiento

•

Reingeniería

Las metodologías desde el punto de vista de la arquitectura de software y la administración de proyectos son las siguientes:

Metodologías Metodologías tradicionales tradicionales •

Capability Maturity Model (SW-CMM)

•

Capability Maturity Model Integration for Development (CMMI-DEV)

•

Big Design Up Front (BDUF)

•

Cleanroom Software Engineering

•

Rational Unified Process (RUP)

El Proceso inglés és,, Proceso Unificad Unificado o Racional Racional (Ratio Rational nal Unifie Unified d Proc Process ess en ingl habitua habitualmen lmente te resumi resumido do como como RUP) es un proc proces eso o de des desarro arroll llo o de software y junto con el Lenguaje Unificado de Modelado UML, UML, constituye la metodolo metodología gía estánd estándar ar más utiliza utilizada da para para el anális análisis, is, implem implement entaci ación ón y documentación de sistemas orientados a objetos. El RUP RUP no es un sist sistem ema a co con n paso pasoss firmem firmement ente e esta establ blec ecido idos, s, sino sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades. Orig Origin inal almen mente te se dise diseñó ñó un proc proces eso o gené genéric rico o y de domin dominio io públ públic ico, o, el Proceso Unificado, Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

El RUP está basado en 6 principios clave que son: El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que


Universidad Nacional De La Amazonia Peruana lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un area subformal.

Equilibrar prioridades Los requerim requerimient ientos os de los diverso diversoss partic participa ipantes ntes pueden pueden ser diferen diferentes tes,, contra contradic dictor torios ios o disput disputars arse e recurs recursos os limita limitados dos.. Debe Debe encont encontra rarse rse un equilibrio que satisfaga los deseos de todos . Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente Los proyectos se entregan, aunque sea de un modo interno, en etapas cada da iter iterac ació ión n se anal analiz iza a la opin opinión ión de los los invers inversor ores es,, la iteradas. En ca estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados

Colaboración Colaboración entre equipos El desa desarr rroll ollo o de soft softwa ware re no lo hace hace una una únic única a perso persona na sino sino múlt múltip iples les equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción Este Este princi principio pio domina dominante nte motiva motiva el uso de concep conceptos tos reutil reutiliza izables bles tales tales como co mo patr patrón ón del del soft softwa ware re,, leng lengua uaje jess 4GL o ma marc rcos os de refe refere renc ncia ia (frameworks) frameworks) por por nomb nombra rarr algu alguno nos. s. Esto Esto evit evita a que que los los inge ingeni nier eros os de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requerimientos y sin comenzar desde un principio pens pensan ando do en la reut reutili iliza zaci ción ón del del có códi digo go.. Un alto alto nivel nivel de abst abstrac racci ción ón tamb tambié ién n permi ermitte disc iscusio usione ness sobre obre dive divers rso os nive nivele less y soluc olucio ione ness arquit arquitect ectóni ónicas cas.. Éstas Éstas se pueden pueden acompa acompañar ñar por las repres represent entaci aciones ones visuales de la arquitectura, por ejemplo con el lenguaje UML. UML.

Enfocarse en la calidad El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

Ciclo de vida



RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia hacia la compren comprensió sión n del problem problema a y la tecnolo tecnología gía,, la delimit delimitaci ación ón del ámbito ito del proyec ectto, la elim liminación ión de los los riesg esgos críticos, y al establecimiento de una baseline (Linea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requerimientos. En la fase de elaboración, las iteraciones se orientan al desarrollo de la bas baselin eline e de la arqu rquitec itecttura ura, abar abarccan má máss los los fluj flujos os de tra trabajo bajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura. En la fase de construcc construcción, ión, se lleva a cabo la construcc construcción ión del producto producto por medio de una serie de iteraciones. Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto. En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía. Principales características características Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pret Preten ende de impl implem emen enta tarr las las me mejo jore ress prác prácti tica cass en Inge Ingeni nier ería ía de Software Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes •

•

•

•

•


Universidad Nacional De La Amazonia Peruana Control de cambios Modelado visual del software Verificación de la calidad del software El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, uso, el código fuente, etc.) y roles (papel (papel que desempeña desempeña una person persona a en un determi determinad nado o moment momento, o, una persona puede desempeñar distintos roles a lo largo del proceso).... Fases Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: Proceso: Las etapas de esta sección son: Modelado de negocio Requisitos Análisis y Diseño Implementación Pruebas Despliegue Soporte: En esta parte nos encontramos con las siguientes etapas: Gestión del cambio y configuraciones Gestión del proyecto Entorno La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente: Inicio(También llamado Incepción) Elaboración Desarrollo(También llamado Implementación,Construcción) Cierre (También llamado Transición) Artefactos RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes: Inicio: Documento Visión Especificación de Requerimientos Elaboración: •

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•


Universidad Nacional De La Amazonia Peruana Diagramas de caso de uso Construcción : Documento Arquitectura que trabaja con las siguientes vistas: Vista Lógica: Diagrama de clases Modelo E-R (Si el sistema así lo requiere) Vista de Implementación: Diagrama de Secuencia Diagrama de estados Diagrama de Colaboración Vista Conceptual: Modelo de dominio Vista física: Mapa de comportamiento a nivel de hardware. •

•

•

•

•

•

•

•

Essential Unified Process for Software Development Development (EssUP)

•

Fusebox Lifecycle Process (FLiP)

•

Software Process Improvement and Capability dEtermination (SPICE)

•

Métrica

•

Jackson System Development (JSD)

•

Joint Application Development (JAD)

•

Open Unified Process (OpenUP)

Metodologías ágiles •

Extreme Programming (XP)

PROGRAMACIÓN PROGRAMACIÓN EXTREMA XP Metodología ágil basada en cuatro principios: principios: simplicidad, comunicación, comunicación, retroalimentación y valor. valor. Además, orientada por pruebas y refactorización, se diseña e implementan las pruebas antes de programar la funcionalidad, el programador crea sus propios tests de unidad. Este método es típicamente atribuido a Kent Beck, Ron Jeffries y Ward Cinnin Cinningha gham. m. El objetivo de Xp son grupos peque pequeño ñoss y media mediano noss de construcción de software en donde donde los requisito requisitoss aún son muy ambiguos, ambiguos, cambian rápidamente o son de alto riesgo. riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el producto. producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto. proyecto. Scrum • •

Agile Modeling Adaptive Software Development (ASD)

•

Crystal Clear

•

Dynamic Systems Development Method (DSDM)


Universidad Nacional De La Amazonia Peruana •

Feature Driven Development (FDD)

•

Lean Software Development (LSD)

• • •

Agile Unified Process (AUP) Software Development Rhythms Agile Documentation

•

ICONIX Process

•

Microsoft Solutions Framework (MSF)

•

Agile Data Method

•

Database Refactoring

•

LeanCMMI


Modelos de Desarrollo Metodologias_Jacrek

Recommend Documents