Unidad 2.
METODOLOGÍAS DE DESARROLLO
Una metodología es una colección de procedimientos, técnicas, herramientas, formada por fases, cada una de las cuales se puede dividir en sub-fases, que guiarán a los desarrolladores de sistemas a elegir las técnicas más apropiadas en cada momento del proyecto y también a planificarlo, gestionarlo, controlarlo y evaluarlo. 2.1 METODOLOGÍAS CLÁSICAS 2.1.1 CASCADA El modelo de cascada original se desarrolló entre las décadas de los años 60 y 70, y se define como una secuencia de actividades, donde la estrategia principal es seguir el progreso del desarrollo de software hacia puntos de revisión bien definidos Fases del modelo cascada:
Ingeniería y análisis del sistema: análisis y de diseño de todos los componentes del sistema computacional. · Análisis de requisitos software: se debe conocer que necesita el usuario para saber que necesidades debemos cubrir. · Diseño: en esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de codificación, se dividen en: 1. Diseño de alto nivel o arquitectónico
2. Diseño detallado Codificación: es la fase de programación propiamente dicha Pruebas: las componentes una vez programadas, se ensamblan para formar el sistema y se demuestra que trabaja correctamente antes de ser puesto en práctica por el usuario. Existen varios tipos de pruebas: · Pruebas de unidad · Pruebas de integración · Pruebas de sistema. Mantenimiento: el software necesitará cambios después de la entrega, los tipos de mantenimiento son: ·
Mantenimiento preventivo y perfectivo
Ventajas del modelo cascada: 1. modelo y planificación fácil y sencillos. 2. sus fases son conocidas por los desarrolladores. 3. los usuarios lo pueden comprender fácilmente. Desventajas del modelo cascada: 1. alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño. 2. bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida. 2.1.2 INCREMENTAL El modelo incremental consiste de un desarrollo inicial de la arquitectura completa del sistema, seguida de incrementos y versiones parciales. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa, se verifica e integra la última versión con las demás versiones ya completadas del sistema. Durante cada incremento, el sistema se evalúa con respecto al desarrollo de versiones futuras. Las actividades se dividen en procesos y subprocesos, dando lugar al término fábrica de software (en inglés, software Factory). Para que la secuencia de desarrollo sea exitosa, es esencial definir etapas que no requieran cambiar los resultados anteriores al agregar nuevas. Por lo tanto, es importante comprender al inicio los requisitos completos del sistema, algo que normalmente es muy difícil de lograr.
2.1.3 EVOLUTIVO Este modelo considera que el desarrollo de sistemas es un proceso de cambios progresivos mediante deltas (cambios) de especificación de requerimientos. El modelo evolutivo es también conocido como desarrollo rápido de aplicaciones (en inglés, RAD—rápida aplicación development), que se basa tradicionalmente en el uso de prototipos (en inglés, rápida prototyping). Un prototipo de software se considera como un medio para especificar los requisitos y un enlace de comunicación entre el usuario final y el diseñador, ayudando a reducir el riesgo de carecer de requerimientos iniciales completos y estables. VENTAJA La ventaja es que es ideal para sistemas que no tienen bien definidos los requerimientos, es decir, para la mayoría de los sistemas que se desarrollan. DESVENTAJA Es difícil distinguirlo del proceso "codifica y corrige", pues en cierta medida son parecidos, la diferencia está que en la práctica se requiere que al construir el prototipo se aplique el análisis y el diseño pero sólo a una parte de los requerimientos ya entendidos, que se documente y se codifique.
2.1.4 ESPIRAL El modelo espiral, desarrollado durante la década de los años 80, es una extensión del modelo de cascada. Cada ciclo del modelo espiral termina con una revisión que discute los logros actuales y los planes para el siguiente ciclo. Al igual que el modelo evolutivo, el modelo espiral incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Cada ciclo de la espiral se divide en 4 etapas: 1.- DEFINICIÓN DE OBJETIVOS: Para esta fase del proyecto se definen los objetivos específicos. Se identifican las restricciones de procesos y el producto, y se estipula un plan detallado de administración. 2.-EVALUACION Y REDUCCIÓN DE RIESGOS: Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto. Se definen los pasos para reducir dichos riesgos. 3.- DESARROLLO Y VALIDACIÓN: Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema. 4.- PLANEACIÓN: El proyecto se revisa y se toma la decisión de si se debe continuar con posterior de la espiral.
CARACTERÍSTICAS
VENTAJAS
DESVENTAJAS
Es cíclico y no lineal como el modelo de la cascada.
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
Cada ciclo del espiral consiste en cuatro etapas, y cada etapa es representada por un cuadrante del plano cartesiano.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
El radio del espiral representa el coste acumulado hasta ahora en el proceso; la dimensión angular representa el progreso en el proceso.
Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
Genera mucho tiempo en el desarrollo de sistemas.
2.1.5 PROTOTIPOS Un prototipo es una versión preliminar, intencionalmente incompleta o reducida de un sistema. El uso de prototipos es una estrategia que puede aplicarse en casi todas las actividades del proceso de software. El propósito de los prototipos es obtener de manera rápida la información necesaria como ayuda en la toma de decisiones.
ETAPAS PARA LA ELABORACIÓN DEL PROTOTIPO
Los prototipos de diseño permiten explorar y comprender la arquitectura particular de un sistema para poder evaluar aspectos como cuellos de botella (rendimiento y uso de memoria) o incoherencias en el diseño. VENTAJAS
DESVENTAJAS
Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. Se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo.
También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo.
En consecuencia de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido).
Los prototipos tienen éxito cuando se comprende su propósito y se usan de manera adecuada, se comprende la tecnología que va a utilizarse y su relación con el proceso de prototipos, se integra un grupo técnico apropiado para hacer el prototipo (líder de proyecto, documentador, elaborador de prototipos de requisitos y análisis, y elaborador de prototipos de diseño), se evalúa al grupo y las entregas finales, se involucra temprano en el proceso de software a los usuarios finales, se está dispuesto a repetir el proceso de prototipos para comprender mejor la arquitectura básica, se establecen criterios de evaluación apropiados al comienzo de cada etapa de prototipos y se basa uno firmemente en estos criterios para su terminación y/o se construyen prototipos basados en una biblioteca de código reutilizable, controlada por el bibliotecario asignado. 2.1.6 DESARROLLO BASADO EN COMPONENTES Ingeniería de Software Basada en Componentes (ISBC). La ISBC parte de la idea de la integración de componentes software ya existente (Desarrollo ascendente o bottom-up). Las tecnologías de objetos proporcionan el marco de trabajo técnico, para la ingeniería de software, para un modelo de proceso basado en componentes. El paradigma orientado a objetos enfatiza la creación de clases que encapsulan tanto los datos como los algoritmos para manejar esos datos. Si se diseñan y se implementan adecuadamente, las clases Orientadas a objetos son reutilizables por diferentes aplicaciones. Fases de Ingeniería y Construcción y Acción de éste modelo por una sola fase de Construcción y adaptación de la Ingeniería: Comunicación con el cliente- las tareas comunicación entre el desarrollador y el cliente.
requeridas
para
establecer
Planificación- las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto. Análisis de riesgos- las tareas requeridas para evaluar riesgos técnicos y de gestión. Construcción y adaptación de la Ingeniería Evaluación del cliente- las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.
BENEFICIOS Un componente es una pieza de código preelaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar (1). Los componentes son los "ingredientes de las aplicaciones", que se juntan y combinan para llevar a cabo una tarea (2). Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. DESVENTAJAS La producción este tipo de software es una empresa muy costosa (mantenimiento). La mayoría de los proyectos grandes fallan parcialmente o totalmente, conduciendo a un riesgo sustancial (interoperabilidad con otros sistemas locales). En un mundo de rápidos y continuos cambios en los requerimientos de los negocios, este tipo de software es usualmente muy lento para ser productivo antes de convertirse en obsoleto.
2.2 OTRAS METODOLOGÍAS
Metodología SCRUM: Es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental, Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums. Programación extrema La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. 2.2.1 GANAR-GANAR
El modelo ganar-ganar (en inglés, win-win) extiende el modelo espiral, haciendo énfasis en la identificación de las condiciones de ganancia para todas las partes, creando un plan para alcanzar las condiciones ganadoras y evitar los riesgos correspondientes. Se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas. El modelo no necesita mucho tiempo de gestión. Esto permite utilizarlo tanto en proyectos pequeños como grandes. Se consideran cuatro los ciclos, cada uno compuesto de cuatro actividades. En el Ciclo 0 (grupos de aplicación) se determina la viabilidad de un grupo apropiado de aplicaciones. En el Ciclo 1 (objetivos del ciclo de vida de la aplicación) se desarrollan los objetivos del ciclo de vida, incluyendo prototipos, planes y especificaciones de aplicaciones individuales, y se verifica la existencia de al menos una arquitectura viable para cada aplicación. En el Ciclo 2 (arquitectura del ciclo de vida de la aplicación) se establece una arquitectura del ciclo de vida detallado, se verifica su viabilidad, y se determina que no existen riesgos mayores en satisfacer los planes y especificaciones. En el Ciclo 3 (capacidad de operación inicial) se alcanza una capacidad operacional inicial para cada etapa crítica del proyecto en el ciclo de vida del software. 2.2.2 PROCESO UNIFICADO (UP) El proceso unificado considera como aspecto esencial del desarrollo de software una visión que parte de la arquitectura del sistema, siguiendo un proceso iterativo e incremental. El proceso considera e integra diferentes aspectos, como son los
ciclos, fases, flujos de trabajo, mitigación de riesgo, control de calidad, administración de proyecto y control de configuración. Se caracteriza por estar dirigido por Iterativo e incremental, Dirigido por casos de uso Y Centrado en la arquitectura
Iterativo e incremental
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del sistema.
Cada una de estas iteraciones se divide a su vez en el ciclo de vida clásico o en cascada:
BENEFICIOS DEL ENFOQUE ITERATIVO La iteración controlada reduce el riesgo a los costes de un solo incremento. Reduce el riesgo de retrasos en el calendario atacando los riesgos más importantes primero. Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo. Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse completamente al principio. Dirigido por casos de uso Se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones.
CAPTURA DE REQUISITOS:
cuál es el problema? ANÁLISIS: qué debe hacerse? qué sistema debemos construir? DISEÑO: cómo podemos solucionar el problema? CODIFICACIÓN: trasladar el diseño a programas... PRUEBAS: ... que funcionen... IMPLANTACIÓN: ... en un entorno productivo ... MANTENIMIENTO: ... y que pueden estar sujetos a posibles modificaciones o mejoras posteriores.
Centrado en la arquitectura Permite al constructor ver la imagen completa antes de que comience la construcción, este proceso ayuda al arquitecto a centrarse en los objetivos adecuados, como la: Comprensibilidad La capacidad de adaptación al cambio La reutilización
2.2.3 INGENIERÍA WEB Es una aplicación de software que permite al usuario recuperar y visualizar documentos de hipertexto, comúnmente descritos en HTML. Los sitios web pueden ser categorizados de la siguiente forma: Sólo
estático que se enfoca en la organización de la estructura y el contenido, en la forma como se va a presentar la información y que sea fácil de manejar para cualquier usuario, pero debe tener en cuenta la eficiencia y la confiabilidad. Sitio estático con formularios de entrada este sitio tiene las mismas características que el anterior, adicionándole que el le permite a los usuarios la interacción por medio de cuestionarios, comentario y sugerencias. Sitio con acceso de datos dinámicos aquí, además de las características antes mencionadas, cuenta con bases de datos en las cuales el usuario puede realizar consultas y búsquedas. Sitio creado dinámicamente en este sitio los requerimientos son parecidos pero deben suplir con las necesidades de cada usuario; creando sitios dinámicos que sean compatibles con el entorno de navegación de cada usuario. Aplicación de software basada en la Web este sitio puede tener todas las características antes mencionadas, pero logrando un parecido con una implementación cliente/servidor comúnmente conocido que a un sitio web estático.
En general, las aplicaciones web, necesitan ser funcionales, mantenibles, escalables y seguras. Como podemos ver, la actual demanda de las aplicaciones web es totalmente diferente de las aplicaciones convencionales y por lo tanto hay una gran necesidad de la ingeniería web.
2.2.4 METODOLOGÍAS ÁGILES Esta metodología nace en febrero del 2001 en una reunión celebrada en Utah EEUU. Principales ideas de la metodología ágil: · Se encarga de valorar al individuo y las iteraciones del equipo más que a las herramientas o los procesos utilizados. · Se hace mucho más importante crear un producto software que funcione que escribir mucha documentación. · El cliente está en todo momento colaborando en el proyecto. · Es más importante la capacidad de respuesta ante un cambio realizado que el seguimiento estricto de un plan 2.2.5 METODOLOGÍAS EMERGENTES 2.2.6 REINGENIERIA
Es el rediseño radical y la reconcepción fundamental de los procesos de negocios para lograr mejoras dramáticas en medidas de desempeño tales como en costes, calidad, servicio y rapidez. Es la actividad destinada a incrementar las capacidades de gestión del nivel operativo y complementario de las apuestas estratégicas y políticas de una organización. Es un modo planificado de establecer secuencias nuevas e interacciones novedosas en los procesos administrativos, regulativos y sustantivos con la pretensión de elevar la eficiencia, la eficacia, la productividad y la efectividad de la red de producción institucional y alcanzar un balance global positivo. Por consiguiente la solución a estos problemas cae en las siguientes categorías: •
(1) Mantenimiento. Que consiste en un proceso incremental e iterativo en el cual se hacen pequeñas modificaciones al sistema.
•
(2) Modernización. Implica cambios más extensos que el mantenimiento pero conserva partes considerables del sistema existente.
•
(3) Remplazo. Que consiste en reconstruir el sistema desde sus inicios. Esta última solución consiste en aplicarle al sistema actividades de reingeniería.
Los procesos fundamentales en la reingeniería son: •
(1) Análisis de inventario. Este proceso consiste en el estudio de la antigüedad, importancia de la aplicación en el negocio y el proceso de mantenimiento actual, entre otros criterios, para estudiar la posible conveniencia de la reingeniería.
•
(2) Reestructuración de documentos. En este proceso se puede optar por una de tres opciones: Evitar la documentación de los módulo estáticos que no van a sufrir cambios, documentar sólo lo que se va a modificar y documentar toda la información del sistema, si es que este es fundamental para el negocio.
•
(3) Ingeniería inversa. En este proceso se extraen modelos de alto nivel de abstracción que ayuden a la comprensión de la aplicación para poder modificarla y que sirvan como punto de partida para el siguiente proceso. Estos datos se deben almacenar en un repositorio que permita que las personas o herramientas que lleven a cabo los siguientes pasos lo encuentren disponible. De esta manera se conforma también la documentación de análisis y diseño de la aplicación que facilitará su posterior mantenimiento.
•
(4) Reestructuración del código y de los datos o aplicación de técnicas de ingeniería directa. A la luz de los resultados de la ingeniería inversa, se reestructuran el código y los datos o se aplican técnicas de ingeniería directa para rehacer la aplicación.
BENEFICIOS DE LA REINGENIERÍA
Procesos sencillos, fáciles de administrar y controlar Menores costos por reducción o eliminación de duplicidad de funciones, trabajos que no agregan valor, retrabajos y errores, reducción del ciclo de los procesos Mayor satisfacción de los clientes, como resultado de un mejor desempeño en las áreas críticas y estratégicas del negocio Mejor imagen de la empresa ante el mercado Oportunidades de aumentar ventas Mejor clima organizacional, como resultado de la mayor responsabilidad y autoridad de los empleados, del desarrollo de su potencial y habilidades, y del mayor involucramiento entre la administración y la fuerza de trabajo
GABRIEL FLORES HDEZ. MODULO 1
