Modelos De Desarrollo Metodologias_jacrek 5r674y

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 necesario destacar el ciclo de vida del proyecto y el modelo 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 istrativo. 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 en desarrollo de software y que ha sido exitoso durante décadas tanto en el desarrollo de grandes sistemas como en el de pequeños. Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal. 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 software contable debido a los cambios en las regulaciones del gobierno). Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos, pero sólo cuando los requerimientos están bien definidos y son estables en forma razonable,

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

El modelo en cascada, algunas veces llamado el ciclo de vida clásico, 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 décadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están: 1. Es muy raro que los proyectos reales sigan el flujo secuencial 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 manera explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 3. El cliente debe tener paciencia. Una versión que funcione de los programas estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión 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 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 situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal. VENTAJAS...

ALUMNO: JACK JAREK SILVANO TAMANI

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. DESVENTAJAS... ✔ 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 s tienen una participación limitada.

I.

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 también agrega nuevas funciones que no están incluidas en los otros modelos, como el análisis de riesgo. El modelo espiral define cuatro 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 uno describe las actividades mencionadas anteriormente. El modelo espiral utiliza un esquema de desarrollo iterativo donde la primera iteración comienza en el centro del círculo e, incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones sucesivas son versiones más completas del software que está siendo construido. 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 iteración. Así, se puede contrarrestar cualquier riesgo observado mediante las acciones adecuadas en el tiempo preciso.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

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 sistematización y el 'desarrollo en etapas' del ciclo de vida clásico, pero, con la diferencia que todos están incorporados dentro del esquema iterativo planteado por el modelo espiral. VENTAJAS... ✔ El producto avanza a pasos firmes solucionado riesgos en cada 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. DESVENTAJAS... ✔ Es complicado. ✔ Requiere de mucha istración. ✔ Difícil de definir los objetivos, metas que indiquen que podemos 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 preliminar

ALUMNO: JACK JAREK SILVANO TAMANI

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 estudio de factibilidad que determine la factibilidad de una solución software. · Definición de los requerimientos del sistema El objetivo de esta etapa es registrar todos los requerimientos y deseos que los s 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 determina los requisitos mediante la construcción, demostració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 técnico tiene dos etapas: por un lado, la producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de 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 s han trabajado con el sistema al hacer las pruebas de prototipos. Además, la mantención también debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el proceso 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 y del desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo: · Análisis grueso y especificación El propósito de esta subfase es desarrollar un diseño básico 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 .

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

· Evaluación Esta etapa tiene dos propósitos: extraer a los s la especificación de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de requerimientos del sistema. Si los s identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: 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 s. · Término Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación a aspectos de calidad y de representación del sistema. En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificación de requerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que permite entregar al lo que sería una visión la solución final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones erróneas.

VENTAJAS... ✔ ✔ ✔ ✔ ✔

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

DESVENTAJAS... ✔ ✔ ✔ ✔

I.

No se conoce cuando se tendrá un producto aceptable. No se sabe cuantas iteraciones serán necesarias. Da una falsa ilusión al 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 enfrentarse 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 inherentes a la codificación y esto llevó al 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 Permite entregar una visión de alto nivel sobre el proyecto, poniendo énfasis en la descripción del problema desde el punto de vista de los clientes y desarrolladores. También se considera la posibilidad 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, la programación puede ser distribuida entre 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 juntan. Cada sección es enlazada con otra y, entonces, probada. 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 consiste en una serie de actividades que aseguran que el software 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 modelo de etapas consideraba que cada una de ellas debería ir a continuación de la anterior, poniendo énfasis en la documentació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 , 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 software nuevamente en la cadena de montaje para su revisión y reconstrucción.

II.

EL MODELO DESARROLLO ITERATIVO Y CRECIENTE O ITERATIVO E INCREMENTAL

Combina elementos del modelo en cascada aplicado en forma iterativa. 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 istración de archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. Se debe tener en cuenta que el 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 para el incremento siguiente. El plan afronta la modificación del producto esencial con el fin de satisfacer de mejor manera las 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 que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones “incompletas del producto final, pero proporcionan al la funcionalidad que necesita y una plataforma para evaluarlo.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

El desarrollo incremental es útil sobre todo cuando el personal necesario para una implementación completa no está disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto 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ía requerir la disponibilidad de un hardware nuevo que 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 permitiría la entrega de funcionalidad parcial a los s finales sin retrasos desordenados. VENTAJAS... ✔ 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. DESVENTAJAS... ✔ Requiere de mucha planeación, tanto istrativa como técnica. ✔ Requiere de metas claras para conocer el estado del proyecto.

I.

EL MODELO RAD (RAPID APPLICATION DEVELOPMENT).

El desarrollo rápido de aplicaciones (RAD) es un modelo de proceso de 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). Como otros modelos de proceso, el 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 planeación es esencial porque varios equipos de software trabajan en 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 empleo de componentes de software existente y la aplicació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 DRA se ilustra en la siguiente figura. Es obvio que las restricciones de tiempo impuestas sobre un proyecto DRA exigen 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 rendimiento es un aspecto importante, y se alcanzará 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ías de desarrollo de software 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. En si pasos naturales o lógicos para la construcción de software. 2. se definen como un con junto de pasos como análisis diseño desarrollo implementación pruebas y implantación 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 problema u obtención de un producto osea el software, son 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 metodología de desarrollo de software es un conjunto de pasos y procedimientos que deben seguirse para desarrollar software. 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.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

Clasificación de las metodologías Las metodologías se clasifican de la siguiente forma: a. Estructuradas.

○ Orientadas a procesos ○ Orientadas a datos ○

Mixta

b. No estructuradas.

○ Orientadas a objetos ○ Sistemas de tiempo real a.

Metodologías estructuradas

Se basan en la forma top-down Metodologías orientadas a procesos La ingeniería del software se basa entrada/proceso/salida de un sistema. Está compuesta por: •

Diagrama de flujo de datos (DFD).

•

Diccionario de datos.

•

Especificaciones de proceso.

en

el

modelo

básico

de

Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon.

Metodologías orientadas a datos

Son metodologías basadas en la información. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los componentes procedimentales.

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

Metodologías no 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: • Revolucionario, puro u ortodoxo. Rompen con las metodologías 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 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 prácticas para lograr los objetivos antes mencionados 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 istración de proyectos son las siguientes: Metodologías 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 Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, 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, 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. Originalmente se diseñó un proceso genérico y de dominio público, el Proceso 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

ALUMNO: JACK JAREK SILVANO TAMANI

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 requerimientos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse 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 iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados Colaboración entre equipos El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc. Elevar el nivel de abstracción Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros 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 pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje 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

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

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 la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos 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 baseline de la arquitectura, abarcan más los flujos de trabajo 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 construcción, se lleva a cabo la construcción del 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 s. 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 •

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

•

Pretende implementar las mejores prácticas en Ingeniería de Software

•

Desarrollo iterativo

•

istración de requisitos

•

Uso de arquitectura basada en componentes

ALUMNO: JACK JAREK SILVANO TAMANI

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, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, 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:

ALUMNO: JACK JAREK SILVANO TAMANI

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 (EssUP) Fusebox Lifecycle Process (FLiP) Software Process Improvement and Capability dEtermination (SPICE) Métrica Jackson System Development (JSD) t Application Development (JAD) Open Unified Process (OpenUP)

Metodologías ágiles

•

Extreme Programming (XP)

PROGRAMACIÓN EXTREMA XP Metodología ágil basada en cuatro principios: simplicidad, comunicación, retroalimentación y 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 Cinningham. El objetivo de Xp son grupos pequeños y medianos de construcción de software en donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el 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.

•

Scrum

•

Agile Modeling Adaptive Software Development (ASD)

•

Crystal Clear

•

Dynamic Systems Development Method (DSDM)

ALUMNO: JACK JAREK SILVANO TAMANI

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

ALUMNO: JACK JAREK SILVANO TAMANI