2 METODOLOGÍA DE DESARROLLO DE SOFTWARE

Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información.

Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.

A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.

El framework para metodología de desarrollo de software consiste en:

·         Una filosofía de desarrollo de programas de computación con el enfoque del proceso de desarrollo de software

·         Herramientas, modelos y métodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algún tipo de organización, que además desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo documentada en algún tipo de documentación formal.

2.1 METODOLOGÍAS CLÁSICAS

Los modelos de proceso dependen de las opiniones o creencias de las personas involucradas en un proyecto. Por ejemplo, algunas de estas opiniones o creencias implican que es necesario comprender el problema antes de desarrollar una solución, el proceso para resolver un problema debe dar un resultado predecible (sin importar qué individuo hace el trabajo), es indispensable planear y calcular el proceso con gran precisión, para que  proceso tenga éxito es importante evaluar y administrar el riesgo y la entrega de etapas intermedias bien definidas aumenta la confianza que se tiene en el resultado final. A continuación se describen los modelos de procesos “clásicos”, analizando las creencias en las cuales se basan.

2.1.1 MODELO DE CASCADA

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.

Llamado también Lineal secuencial. Proporciona una simple visión del desarrollo del Software. A los procesos los representa como fases separadas y secuenciales en tiempo.

Antes de codificar debemos diseñar el software, además probarlo antes de construirlo y ponerlo en operación.

Un ejemplo de una metodología de desarrollo en cascada es:

1.     Análisis de requisitos.

2.     Diseño del Sistema.

3.     Diseño del Programa.

4.     Codificación.

5.     Pruebas.

6.     Implantación.

7.     Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

VENTAJAS DEL MODELO CASCADA

1.      Modelo y planificación fácil y sencilla.

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 MODELO INCREMENTAL

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.

De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

El Modelo Incremental se puede ver aquí en forma grafica:

- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.

- El usuario se involucra más.

- Difícil de evaluar el coste total.

- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.

- Requiere gestores experimentados.

- Los errores en los requisitos se detectan tarde.

- El resultado puede ser muy positivo.

Ventajas:

- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.

- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.

- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

Desventajas:

- El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

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

- Requiere de metas claras para conocer el estado del proyecto.

2.1.3 MODELO EVOLUTIVO

Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

2.1.4 ESPIRAL

Este modelo en espiral es una de las metodologías más recomendables para el desarrollo y creación de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en una manera continua y cíclica.

Cada ciclo de la espiral se divide en 4 etapas:

1.-Definición de objetivos

2.-Evaluación y reducción de riesgos

3.-Desarrollo y validación

4.-Planeación

2.1.5 PROTOTIPOS

El modelo de prototipos permite que todo el sistema, o algunas de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo.

1.-Etapas para la elaboración del prototipo

2.-Identificar requerimientos básicos del usuario

3.-Desarrollar prototipo inicial

4.-Usar el prototipo

5.-Revisión y mejora del prototipo

2.1.6 DESARROLLO BASADO EN COMPONENTES

El desarrollo de software basado en componentes permite reutilizar piezas de código pre -elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión.

BENEFICIOS DEL DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes.

El uso de este paradigma posee algunas ventajas:

1.-Reutilización del software.

2.-Simplifica las pruebas.

3.-Simplifica el mantenimiento del sistema.

4.-Mayor calidad.

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 utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Aunque 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.

En  el siguiente diagrama nos muestra ciclo de entrega en la programación extrema.

 Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

·         Gile unified process

El proceso unificado ágil de scott ambler o agile unified process (aup) en inglés es una versión simplificada del proceso unificado de rational (rup). este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en rup. el aup aplica técnicas ágiles incluyendo desarrollo dirigido por pruebas (test driven development - tdd), modelado agil, gestión de cambios agil, y refactorización de base de datos para mejorar la productividad.

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. Las cuatro actividades son: elaborar los objetivos, restricciones y alternativas del proceso y producto del sistema y subsistema; evaluar las alternativas con respecto a los objetivos y restricciones (identificando y resolviendo las fuentes principales de riesgo en el proceso y producto); elaborar la definición del producto y proceso; y planear el siguiente ciclo, actualizando el plan del ciclo de vida, incluyendo la partición del sistema en subsistemas para ser considerados en ciclos paralelos, lo cual puede incluir un plan para terminar el proyecto si es muy riesgoso o no es factible, asegurando el compromiso de la administración para continuar según lo planeado.

Una vez revisadas las actividades, los ciclos definen líneas específicas a seguir. 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.

Las creencias del modelo son: crear software basado en componentes para lograr mayor calidad en los sistemas de mayor tamaño, escribir software reutilizable para hacer eficiente el proceso de desarrollo, medir la calidad del sistema como aspecto clave del desarrollo del producto, lograr mayor calidad en el proceso de ensamblaje a partir de componentes menores, usar tecnologías basadas en objetos como aspecto básico para lograr la calidad, producir sistemas rápidamente (sencillos, confiables y de calidad) empleando procesos bien definidos, utilizar el modelo espiral como base del proceso, hacer flexible el proceso de creación del software para lograr los objetivos generales de eficiencia, involucrar al cliente mediante el manejo de prototipos y analizar los riesgos en el proceso del desarrollo del software para asegurar la calidad final del sistema.

En el sistema GA  se basa principalmente en resolver los problemas que puedan surgir en el software y así poder tener un mejor producto y uso del mismo, para lograr esto se usaran los manuales de contingencia y de mantenimiento.

Para justificar de una forma más exacta el uso de dicho modelo en el sistema GA  es porque este modelo se basa principalmente del modelo espiral el cual tiene una secuencias de actividades como son el análisis, diseño, pruebas, implementación; el sistema GA utilizo todas estas actividades para poder ser realizado con esto podemos destacar que se podrán obtener a su vez las diferentes versiones que pueden ser realizadas por medio de dichas actividades, ya que nuestro sistema GA  tendrá diferentes actualizaciones que se enfocan en las versiones de mismo. También podemos destacar que nuestro sistema se basa en la tecnología gratuita para el software y esto a su vez mejor la calidad del mismo, ya que el modelo Ganar-ganar se basa principalmente en la calidad y eficiencia de un sistema.

2.2.2 PROCESO UNIFICADO (UP)

El proceso unificado (en inglés, UP—unifi ed process) 13 es una extensión al proceso objectory (del inglés object factory),14 que tiene sus orígenes en la década de los años 80. Estos modelos de proceso se basan principalmente en la especificación de requerimientos de un sistema mediante casos de uso (maneras de utilizar un sistema).

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. De manera adicional, el proceso unificado considera las cuatro P del desarrollo de software: personas, proyecto, producto y proceso.

El proceso unificado tiene las siguientes creencias: para construir un sistema exitoso se debe conocer qué quieren y necesitan los usuarios potenciales; al igual que la arquitectura, en la construcción, permite diseñar edificios desde múltiples puntos de vista, estructura, electricidad, etc., las arquitecturas de los sistemas de software deben permitir visualizar un sistema desde múltiples perspectivas; y el desarrollo de un producto de software comercial puede significar un gran esfuerzo continuando por meses, años o incluso más, por lo que es práctico dividir el trabajo en pedazos, donde cada iteración resulta en un incremento del proyecto.

2.2.3 INGENIERÍA WEB

¿Qué es un navegador? “Un navegador, navegador red o navegador web (del inglés, web browser) es una aplicación de software que permite al usuario recuperar y visualizar documentos de hipertexto, comúnmente descritos en HTML.

Protocolos comunes soportados por un Web Browser:

·         HTTP / HTTPS

·         E-mail

·         FTP

·         NNTP (Usenet)

·         SSL

·         IRC

·         Gopher

·         EV

·         IDN

·         data:URL

·         BitTorrent

·         IPv6

Navegadores comunes;

·         Internet Explorer,

·         Mozilla Firefox,

·         Safari, Opera,

·         Avant Browser,

·         Konqueror,

·         Lynx,

·         Google Chrome,

·         Maxthon,

·         Flock,

·         Arachne,

·         Epiphany,

·         K-Meleon,

·         AOL Explorer.

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