Desarrollo de aplicaciones informáticas

Objetivo de la Unidad de Trabajo: Realizar el diseño de aplicaciones informáticas.

(Tiempo estimado: 15 períodos)

Hechos/conceptos (contenidos soporte)

ü  Ciclo de vida de un sistema. Concepto y procesos principales. Tipos de ciclos de vida. Modelos de desarrollo (lineal, evolutivo, espiral, prototipos). Fases y etapas. Integración de modelos - Metodología de desarrollo. Crisis del software e ingeniería del software. Concepto, evolución y características de las metodologías de desarrollo.

ü  Clasificación de las metodologías de desarrollo.Estructuradas: orientadas a procesos; orientadas a datos, mixtas y orientadas a objetos.

ü  Principales metodologías de desarrollo europeas. MERISE (Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise). SSADM (Structured System Analysis and Design Method). METRICA

Ingeniería de software

Ingeniería de software es la disciplina o área de la Ingenieria que ofrece métodos y técnicas para desarrollar y mantener software. La creación del software es un proceso intrínsecamente creativo y la Ingeniería del Software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo creativo por medio de diversas técnicas que se han demostrado adecuadas en base a la experiencia previa. Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.

Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

• Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
• Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976).
• Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
• Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U. S. Bureau of Labor Statistics) contó 760.840 ingenieros de software de computadora.¹ El término "ingeniero de software", sin embargo, se utiliza en forma genérica en el ambiente empresarial, y no todos los ingenieros de software poseen realmente títulos de Ingeniería de universidades reconocidas.

Algunos autores consideran que Desarrollo de Software es un término más apropiado que Ingeniería de Software (IS) para el proceso de crear software. Personas como Pete McBreen(autor de "Software Craftmanship") cree que el término IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos Ingeniería de Software o Ingeniería del Software. En hispanoamérica el término usado normalmente es el primero de ellos.

Modelos de desarrollo de software

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:

• Modelo en cascada o Clásico (modelo tradicional)
• Modelo de prototipos
• Modelo en espiral (modelo evolutivo)
• Desarrollo por etapas
• Desarrollo iterativo y creciente o Iterativo e Incremental
• RAD (Rapid Application Development)
• Desarrollo concurrente
• Proceso Unificado
• RUP (Proceso Unificado de Rational)

[editar]

Ciclo de Vida del Software

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.

El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos.

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

• Describe las fases principales de desarrollo de software.
• Define las fases primarias esperadas de ser ejecutadas durante esas fases.
• Ayuda a administrar el progreso del desarrollo, y
• Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

Desarrollo en 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 ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

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

Fases del modelo. 

Análisis de requisitos 

Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se deben consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Sistema 

Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras..

Diseño del Programa 

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación 

Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación.

Implantación 

El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto

Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios.

Variantes 

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.

Desventajas 

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.

Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.

Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado, lo cual provoca una gran inseguridad por parte del cliente que anda ansioso de ver avances en el producto. Esto también implica toparse con requerimientos que no se habian tomado en cuenta, y que surgieron al momento de la implementación, lo cual provocara que se regrese nuevamente a la fase de requerimientos.

Ventajas 

Se tiene todo bien organizado y no se mezclan las fases.

Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar

Desarrollo en espiral

El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo son una espiral, cada bucle es una actividad. Las actividades no están fijadas a prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Tareas 

Para cada actividad habrá cuatro tareas:

Determinar o fijar objetivos 

• Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.
• Fijar las restricciones.
• Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
• Hay una cosa que solo se hace una vez: planificación inicial o previa.

Análisis del riesgo 

• Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.

Desarrollar, verificar y validar (probar) 

• Tareas de la actividad propia y de prueba.
• Análisis de alternativas e identificación resolución de riesgos.
• Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

Planificar 

• Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Mecanismos de control

• La dimensión radial mide el coste.
• La dimensión angular mide el grado de avance del proyecto.

Variaciones del Modelo En Espiral 

• Modelo en Espiral Tiipico de seis regiones.
• Modelo en espiral WIN WIN.

Ventajas 

El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.

• Reduce riesgos del proyecto
• Incorpora objetivos de calidad
• Integra el desarrollo con el mantenimiento, etc.

Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas

• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos

Inconvenientes 

Genera mucho trabajo adicional, y eso causa muchos problemas sobre todo si la compañía que esta produciendo el software es floja y holgazan. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil). El IEEE lo pone como modelo no operativo en sus clasificaciones de MCV.

Modelo de prototipos

En Ingeniería de software el desarrollo con prototipación, también llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Ventajas 

• 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.
• También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente que los

Inconvenientes 

• El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.
• En aras 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). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Conclusiones 

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

• Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.
• Que el prototipo se descarte, al menos en parte.
• Que después se desarrolle el software real con un enfoque hacia la calidad.

Metodologías EUROPEAS

Para garantizar la calidad de la información de cualquier empresa es necesario que el personal colabore de forma eficiente en la construcción de aplicaciones, y esto se consigue definiendo de antemano una serie de etapas intermedias que permitan aumentar la eficiencia del trabajo.

La Metodología es el conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a realizar nuevas aplicaciones informáticas.

Normalmente consistirá en un conjunto de fases descompuestas en subfases (módulos, etapas, pasos, etc.). Esta descomposición del proceso de desarrollo guía a los desarrolladores en la elección de las técnicas que debe elegir para cada estado del proyecto, y facilita la planificación, gestión, control y evaluación de los proyectos.

Una metodología, por tanto, representa el camino para desarrollar aplicaciones informáticas de una manera sistemática.

Evolución de las metodologías

En la siguiente tabla podemos ver cómo han surgido las metodologías más representativas en la historia de la Ingeniería del Software.

Años	Metodologías
1968	Concepción sobre la programación estructurada de DIJKDTRA
1974	Técnicas de programación estructurada de WARNIER y JACKSON
1975	Primeros conceptos sobre diseño estructurado de MYERS y YOURDON
1977	Primeros conceptos sobre el análisis estructurado GANE y SARSON
1978	Análisis estructurado : DEMARCO y WIINBERG. Nace MERISE
1981	SSADM. Information Engineering
1985	Análisis y Diseño estructurado para sistemas de tiempo real de WARD y MELLOR
1986	SSADM Versión 3
1987	Análisis y Diseño estructurado para sistemas de tiempo real de HATLEY Y PIRHBAY
1989	METRICA
1990	SSADM Versión 4
1993	METRICA Versión 2
1995	METRICA Versión 2.1

Estructura general de MERISE

Las bases de MERISE comenzaron en 1.972 por un equipo universitario de ingenieros de Aix-en-Provence. La primera versión salió a finales de 1.976.

El proyecto partió del Centre Technique Informatique del Ministerio de Industria Francés en Septiembre de 1.977, para cubrir las necesidades tanto de la administración como de las empresas. El proyecto finalizó en mayo de 1.978 dando lugar a MERISE como metodología de Análisis y Diseño de Sistemas de Información.

Esta metodología aporta un ciclo de vida más largo a los existentes hasta entonces que se materializa en un conjunto definido de etapas. Introducen dos ciclos complementarios : ciclo de abstracción y ciclo de decisión. El ciclo de abstracción se basa en la percepción de tres niveles de abstracción : conceptual, organizativo y físico. Además se definen dos niveles para cada nivel : un modelo de datos y otro de tratamientos.

Las fases de la metodología MERISE son :

1. Estudio preliminar.
2. Estudio detallado.
3. Implementación.
4. Realización y puesta en marcha.

Estructura general de SSADM

El gobierno británico plantea la necesidad de crear una metodología y se desarrolló entre el Central Computing and Telecommunications Agency (CCTA) y Learmonth and Burchett Management Systems (LBMS), dando como resultado la metodología SSADM (Structures Systems Analysis and Design Method).

Los aspectos claves de SSADM v 4 Son :

• Énfasis en los usuarios : sus requisitos y participación.
• Definición del proceso de producción : qué hacer, cuándo y cómo.
• Tres puntos de vista : datos, eventos, procesos.
• Máxima flexibilidad en herramientas y técnicas de implementación.

SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y diseño, pero no cubre aspectos como la planificación estratégica ni entra en la construcción del código.

Estructura general de Métrica v 2.0

Métrica v 2.0 es una metodología propuesta por el Ministerio de las Administraciones Públicas para que todas las organizaciones sigan el mismo modelo y unificar los criterios para mayor homogeneidad y eficiencia en las aplicaciones informáticas.

Para construir Métrica v 2.0 hay unas etapas intermedias en las que hay que asegurar la calidad en la construcción de las aplicaciones informáticas relacionadas con el campo del tratamiento de la información, elaborando un marco homogéneo de referencia para verificar que los productos que se generen tengan el nivel de calidad apropiado y que se cumplan las previsiones iniciales de plazo y coste.

Métrica está en versión 2 porque en 1.991 se decidió revisar el proyecto Métrica con el objetivo de obtener una nueva versión por los siguientes motivos :

1. Mejorar la anterior versión de 1.989
2. Responder a la demanda por parte de los centros informáticos de una referencia para el desarrollo de sistemas de información.
3. Contar con una metodología compatible con EuroMétodo
4. Aprovechar el mercado de herramientas CASE mucho mayor que cuando se realizó la primera versión de Métrica.

Las fases de Métrica v. 2.0

Las fases de Métrica v.2.0. son :

• Fase 0 : Plan de sistemas de información
• Fase 1 : Análisis de sistemas
• Fase 2 : Diseño de sistemas
• Fase 3 : Construcción de sistemas
• Fase 4 : Implementación de sistemas