Resolución caso de estudio

Objetivo General

Diseñar sistema un automatizado de gestión en Fesamericacentral, utilizando modelo de espiral. para mejoras en el control de la gestión de fondos de la misma.

Objetivos Específicos

Recolectar datos acerca de la forma en que funciona la empresa.

Mejorar el funcionamiento de la empresa Fesamericacentral.

Elaborar documento con diseño de sistema automatizado de Gestión.

Recopilación de requerimientos

Datos del Expositor: Nombre, Apellido, Dirección, Teléfono, Profesión, Asociación, Cargo, Idioma, Nacionalidad, Edad.

Datos de Eventos: Nombre del seminario, enfoque metodológico, duración de eventos, temas, programas, mesas de Trabajo.

Datos de Documentos: Programa, mesa de trabajo, encargado de mesa, medios dinámicos, numero de copias de proyecto.

Datos de servicios y Lugar de eventos: Nombre (Hotel o restaurante), dirección, teléfono, menú(Desayuno, Almuerzo, Cena. costos).

Análisis de riesgo

—

    En el análisis de riesgo tomamos en cuenta muchos factores desde el punto de vista técnico como el punto de vista operativo de las invitaciones.

—

Análisis de riesgo técnico.

     Desde el punto de vista técnico nos hemos dado cuenta de que la  Fundación  FES América utiliza para sus actividades equipos  no muy óptimos para un excelente  desarrollo lo cual es un riesgo para la fundación  debido a que con equipos en esos estados no brindarían una mejor presentación a las personas participantes de dichas actividades, la mejor decisión en ese caso seria invertir en equipos óptimos para garantizar un evento de calidad, ya que en las oficinas tienen equipos muy optimizados. Actualmente constan con 7 computadoras. Lo cual lo hace mas eficiente en la atención al cliente y en sus trabajos operativos dentro de la organización.

Análisis de riesgo operativo de las invitaciones.

     Analizando desde el punto de vista operativo de la fundación, hemos logrado            identificar algunos factores de posibles riesgos, dentro de ellos tenemos los siguientes:

     Invitaciones incorrectas a personas no invitadas para cierta actividad, esto ocasionaría una gran problemática en la organización de los invitados y no invitados, en este caso seria tomar medidas urgentemente para evitar pequeños incidentes como este, una de las medidas podría ser invertir en un sistema con mucha robustez el cual no permita errores de este tipo.

Formulario de datos del Expositor

Formulario de Temas

Formulario de Documentos

Formulario del Bufet

El software como producto

Muchas compañias de software exitosas adoptan este modelo:
Microsoft.
Adobe.
Muchas otras!
Recordemos que el software en sus inicios venía gratis con el hardware. Recién a fines de los 70' principios de los  80' se “inventó” esta nueva forma de concebir al software.

El software atraviesa las etapas propias de la fabricación de productos: Es diseñado (aplicando técnica de ingeniería de software). Luego es replicado.
Ej: Plantas de estampado de CDs o DVDs. Es eventualmente distribuído. Y finalmente vendido (Wal-Marts, Electronic  Boutiques, CompuWorlds, etc.). Se genera una “cosa” tangible: la cajita.




Esta concepción brinda varias ventajas: El costo de diseñar el software se paga una 
vez y se cobra miles o millones de veces. Podemos elegir la licencia que nos venga en 
gana, o bien diseñar nuestra propia licencia. Ej: Prohibir que se pueda hablar mal del producto.
Se puede negociar con los vendedores de  otros productos para que incorporen el  nuestro a cambio de alguna prestación.
Ej: Firefox integrando a Google en el search box.
Ej: Dell instalando Windows en sus computadoras.


Software como producto


En síntesis: Este enfoque permite recaudar cuantiosas  cantidades de dinero a las empresas ya establecidas (especialmente, las que controlan monopólicamente al mercado). Es complicado que una empresa recien  formada pueda tener éxito siguiendo este  enfoque por diversas razones:
Alta inversión inicial.
Peligro de litigación.
Riesgo de dumping.

El software también presenta ciertas características que lo hacen un servicio: El software no se fabrica, se desarrolla.En vez de llevar el producto a los  clientes, éstos vienen a pedirlo.

Generan una “cosa” no tangible: el servicio que es brindado por el software.

Ej: Gmail, Amazon, eBay, etc.

Ej: Salesforce.

Aplicaciones de Software

Software de sistemas. El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas.

Software de tiempo real. El software que coordina/analiza/controla sucesos del mundo real conforme ocurren, se denomina de tiempo real.

Software de gestión. El proceso de la información comercial constituye la mayor de las áreas de aplicación del software.

Software de ingeniería y científico. El software de ingeniería y científico está caracterizado por los algoritmos de «manejo de números». Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática.

Software empotrado. Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo.

Software de computadoras personales. El mercado del software de computadoras personales ha germinado en las pasadas dos décadas. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

Software basado en Web. Las páginas Web buscadas por un explorador son software que incorpora instrucciones ejecutables (por ejemplo, CGI, HTML, Perl, o Java), y datos (por ejemplo, hipertexto y una variedad de formatos de audio y visuales). En esencia, la red viene a ser una gran computadora que proporciona un recurso software casi ilimitado que puede ser accedido por cualquiera con un modem.

Software de inteligencia artificial. El software de inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. Los sistemas expertos, también llamados sistemas basados en el conocimiento, reconocimiento de patrones (imágenes y voz), redes neuronales artificiales, prueba de teoremas, y los juegos son representativos de las aplicaciones de esta categoría.

Características del software

1. El software se desarrolla, no se fabrica en un sentido clásico.

Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software

2. El software no se «estropea».

El software no es susceptible a los males del entorno que hacen que el hardware se estropee. . Los defectos no detectados harán que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corrigen(suponiendo que no se introducen nuevos errores) la curva se aplana.

3. Aunque la industria tiende a ensamblar componentes, la mayoría del software se construye a medida.

Consideremos la forma en la que se diseña y se construye el hardware de control para un producto basado en computadora. El ingeniero de diseño construye un sencillo esquema de la circuitería digital, hace algún análisis fundamental para asegurar que se consigue la función adecuada y va al armario donde se encuentran los catálogos de componentes digitales. Después de seleccionar cada componente, puede solicitarse la compra.

El Proceso del software

Capas de Ingeniería del software

La ingeniería de software es una tecnología multicapa, cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de organización de calidad.

El fundamento de la ingeniería de software es la capa del proceso. El proceso de la ingeniería de software es la unión que mantiene juntas las capas de tecnología y que permiten un desarrollo racional y oportuno de la ingeniería de software. El proceso define un marco de trabajo para un conjunto de

áreas clave de proceso que se deben establecer para la entrega de la tecnología de la ingeniería de software.

Los métodos de la ingeniería de software indican como construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento.

Las herramientas de la ingeniería de software proporcionan un enfoque automático o semiautomático para el proceso y para los métodos.

Enfoque en capas

Herramientas

Metodos

Procesos

Un enfoque de Calidad

Fases Genéricas 

La fase de definición se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación

se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software.

La fase de desarrollo se centra en el cómo. Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos,

cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba.

La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:

Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

Actividades Protectoras

1. Seguimiento y control del proyecto de software

2. Revisiones técnicas formales

3. Garantía de calidad del software

4. Gestión de configuración del software

5.Preparación y producción de documentos

6. Gestión de reutilización

7. Mediciones

8. Gestión de riesgos

ETAPAS EN EL DESARROLLO DEL SOFTWARE

Captura, análisis y especificación de requisitos

Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se realiza, y, según el modelo de proceso adoptado, puede casi terminar para pasar a la próxima etapa (caso de Modelo Cascada Realimentado) o puede hacerse parcialmente para luego retomarla (caso Modelo Iterativo Incremental u otros de carácter evolutivo).

En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y especifican las características funcionales y no funcionales que deberá cumplir el futuro programa o sistema a desarrollar.

Las bondades de las características, tanto del sistema o programa a desarrollar, como de su entorno, parámetros no funcionales y arquitectura dependen enormemente de lo bien lograda que esté esta etapa. Esta es, probablemente, la de mayor importancia y una de las fases más difíciles de lograr certeramente, pues no es automatizable, no es muy técnica y depende en gran medida de la habilidad y experiencia del analista que la realice.

Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy subjetivos y es difícil de modelar con certeza o aplicar una técnica que sea "la más cercana a la adecuada" (de hecho no existe "la estrictamente adecuada"). Si bien se han ideado varias metodologías, incluso software de apoyo, para captura, elicitación y registro de requisitos, no existe una forma infalible o absolutamente confiable, y deben aplicarse conjuntamente buenos criterios y mucho sentido común por parte del o los analistas encargados de la tarea; es fundamental también lograr una fluida y adecuada comunicación y comprensión con el usuario final o cliente del sistema.

El artefacto más importante resultado de la culminación de esta etapa es lo que se conoce como especificación de requisitos software o simplemente documento ERS.

Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental; lo común es que el cliente tenga un objetivo general o problema a resolver, no conoce en absoluto el área (informática), ni su jerga, ni siquiera sabe con precisión qué debería hacer el producto software (qué y cuantas funciones) ni, mucho menos, cómo debe operar. En otros casos menos frecuentes, el cliente "piensa" que sabe precisamente lo que el software tiene que hacer, y generalmente acierta muy parcialmente, pero su empecinamiento entorpece la tarea de elicitación. El analista debe tener la capacidad para lidiar con este tipo de problemas, que incluyen relaciones humanas; tiene que saber ponerse al nivel del usuario para permitir una adecuada comunicación y comprensión.

Escasas son las situaciones en que el cliente sabe con certeza e incluso con completitud lo que requiere de su futuro sistema, este es el caso más sencillo para el analista.

Las tareas relativas a captura, elicitación, modelado y registro de requerimientos, además de ser sumamente importante, puede llegar a ser dificultosa de lograr acertadamente y llevar bastante tiempo relativo al proceso total del desarrollo; al proceso y metodologías para llevar a cabo este conjunto de actividades normalmente se las asume parte propia de la Ingeniería de Software, pero dada la antedicha complejidad, actualmente se habla de una Ingeniería en Requisitos¹¹ , aunque ella aún no existe formalmente.

Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente abocados a la idear modelos, técnicas y procesos para intentar lograr la correcta captura, análisis y registro de requerimientos. Estos grupos son los que normalmente hablan de la Ingeniería en Requisitos; es decir se plantea ésta como un área o disciplina pero no como una carrera universitaria en si misma.

Algunos requisitos no necesitan la presencia del cliente, para ser capturados o analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar unilateralmente decisiones que considera adecuadas (tanto en requerimientos funcionales como no funcionales). Por citar ejemplos probables: Algunos requisitos sobre la arquitectura del sistema, requisitos no funcionales tales como los relativos al rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo, relaciones internas o ligas entre la información (entre registros o tablas de datos) a almacenar en caso de bases o bancos de datos, etc. Algunos funcionales tales como opciones secundarias o de soporte necesarias para una mejor o más sencilla operatividad; etc.

La obtención de especificaciones a partir del cliente (u otros actores intervinientes) es un proceso humano muy interactivo e iterativo; normalmente a medida que se captura la información, se la analiza y realimenta con el cliente, refinándola, puliéndola y corrigiendo si es necesario; cualquiera sea el método de ERS utilizado. EL analista siempre debe llegar a conocer la temática y el problema a resolver, dominarlo, hasta cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad para comprender problemas de muy diversas áreas o disciplinas de trabajo (que no son específicamente suyas); así por ejemplo, si el sistema a desarrollar será para gestionar información de una aseguradora y sus sucursales remotas, el analista se debe compenetrar en cómo ella trabaja y maneja su información, desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada a gran diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas, es decir gente que conoce profundamente el área para la cual se desarrollará el software; evidentemente una única persona (el analista) no puede abarcar tan vasta cantidad de áreas del conocimiento. En empresas grandes de desarrollo de productos software, es común tener analistas especializados en ciertas áreas de trabajo.

Contrariamente, no es problema del cliente, es decir él no tiene por qué saber nada de software, ni de diseños, ni otras cosas relacionadas; sólo se debe limitar a aportar objetivos, datos e información (de mano propia o de sus registros, equipos, empleados, etc) al analista, y guiado por él, para que, en primera instancia, defina el "Universo de Discurso", y con posterior trabajo logre confeccionar el adecuado documento ERS.

Es bien conocida la presión que sufren los desarrolladores de sistemas informáticos para comprender y rescatar las necesidades de los clientes/usuarios. Cuanto más complejo es el contexto del problema más difícil es lograrlo, a veces se fuerza a los desarrolladores a tener que convertirse en casi expertos de los dominios que analizan.

Cuando esto no sucede es muy probable que se genere un conjunto de requisitos¹² erróneos o incompletos y por lo tanto un producto de software con alto grado de desaprobación por parte de los clientes/usuarios y un altísimo costo de reingeniería y mantenimiento. Todo aquello que no se detecte, o resulte mal entendido en la etapa inicial provocará un fuerte impacto negativo en los requisitos, propagando esta corriente degradante a lo largo de todo el proceso de desarrollo e incrementando su perjuicio cuanto más tardía sea su detección (Bell y Thayer 1976)(Davis 1993).

Procesos, modelado y formas de elicitación de requisito                                                           Siendo que la captura, elicitación y especificación de requisitos, es una parte crucial en el proceso de desarrollo de software, ya que de esta etapa depende el logro de los objetivos finales previstos, se han ideado modelos y diversas metodologías de trabajo para estos fines. También existen herramientas software que apoyan las tareas relativas realizadas por el ingeniero en requisitos.

El estándar IEEE 830-1998 brinda una normalización de las "Prácticas Recomendadas para la Especificación de Requisitos Software".¹³

A medida que se obtienen los requisitos, normalmente se los va analizando, el resultado de este análisis, con o sin el cliente, se plasma en un documento, conocido como ERS o Especificación de Requisitos Software, cuya estructura puede venir definida por varios estándares, tales como CMM-I.

Un primer paso para realizar el relevamiento de información es el conocimiento y definición acertada lo que se conoce como "Universo de Discurso" del problema, que se define y entiende por:

Universo de Discurso (UdeD): es el contexto general en el cual el software deberá ser desarrollado y deberá operar. El UdeD incluye todas las fuentes de información y todas las personas relacionadas con el software. Esas personas son conocidas también como actores de ese universo. El UdeD es la realidad circunstanciada por el conjunto de objetivos definidos por quienes demandaron el software.

A partir de la extracción y análisis de información en su ámbito se obtienen todas las especificaciones necesarias y tipos de requisitos para el futuro producto software.

El objetivo de la Ingeniería de Requisitos (IR) es sistematizar el proceso de definición de requisitos permitiendo elicitar, modelar y analizar el problema, generando un compromiso entre los Ingenieros de Requisitos y los clientes/usuarios, ya que ambos participan en la generación y definición de los requisitos del sistema. La IR aporta un conjunto de métodos, técnicas y herramientas que asisten a los ingenieros de requisitos (analistas) para obtener requerimientos lo más seguros, veraces, completos y oportunos posibles, permitiendo básicamente:

• Comprender el problema
• Facilitar la obtención de las necesidades del cliente/usuario
• Validar con el cliente/usuario
• Garantizar las especificaciones de requisitos

Si bien existen diversas formas, modelos y metodologías para elicitar, definir y documentar requerimientos, no se puede decir que alguna de ellas sea mejor o peor que la otra, suelen tener muchísimo en común, y todas cumplen el mismo objetivo. Sin embargo, lo que si se puede decir sin dudas es que es indispensable utilizar alguna de ellas para documentar las especificaciones del futuro producto software. Así por ejemplo, hay un grupo de investigación argentino que desde hace varios años ha propuesto y estudia el uso del LEL (Léxico Extendido del Lenguaje) y Escenarios como metodología, aquí¹⁴ se presenta una de las tantas referencias y bibliografía sobre ello. Otra forma, más ortodoxa, de capturar y documentar requisitos se puede obtener en detalle, por ejemplo, en el trabajo de la Universidad de Sevilla sobre "Metodología para el Análisis de Requisitos de Sistemas Software".¹⁵

En la Fig. 7 se muestra un esquema, más o menos riguroso, aunque no detallado, de los pasos y tareas a seguir para realizar la captura, análisis y especificación de requerimientos software. También allí se observa qué artefacto o documento se obtiene en cada etapa del proceso. En el diagrama no se explicita metodología o modelo a utilizar, sencillamente se pautan las tareas que deben cumplirse, de alguna manera.

Fig. 7 - Diagrama de tareas para captura y análisis de requisitos.

Una posible lista, general y ordenada, de tareas recomendadas para obtener la definición de lo que se debe realizar, los productos a obtener y las técnicas a emplear durante la actividad de elicitación de requisitos, en fase de Especificación de Requisitos Software es:

1. Obtener información sobre el dominio del problema y el sistema actual (UdeD).
2. Preparar y realizar las reuniones para elicitación/negociación.
3. Identificar/revisar los objetivos del usuario.
4. Identificar/revisar los objetivos del sistema.
5. Identificar/revisar los requisitos de información.
6. Identificar/revisar los requisitos funcionales.
7. Identificar/revisar los requisitos no funcionales.
8. Priorizar objetivos y requisitos.

Algunos principios básicos a tener en cuenta:

• Presentar y entender cabalmente el dominio de la información del problema.
• Definir correctamente las funciones que debe realizar el Software.
• Representar el comportamiento del software a consecuencias de acontecimientos externos, particulares, incluso inesperados.
• Reconocer requisitos incompletos, ambiguos o contradictorios.
• Dividir claramente los modelos que representan la información, las funciones y comportamiento y características no funcionales.

Clasificación e identificación de requerimientos

Se pueden identificar dos formas de requisitos:

• Requisitos de usuario: Los requisitos de usuario son frases en lenguaje natural junto a diagramas con los servicios que el sistema debe proporcionar, así como las restricciones bajo las que debe operar.
• Requisitos de sistema: Los requisitos de sistema determinan los servicios del sistema y pero con las restricciones en detalle. Sirven como contrato.

Es decir, ambos son lo mismo, pero con distinto nivel de detalle.

Ejemplo de requisito de usuario: El sistema debe hacer préstamos Ejemplo de requisito de sistema: Función préstamo: entrada código socio, código ejemplar; salida: fecha devolución; etc.

Se clasifican en tres los tipos de requisitos de sistema:

• Requisitos funcionales

Los requisitos funcionales describen:

• Los servicios que proporciona el sistema (funciones).
• La respuesta del sistema ante determinadas entradas.
• El comportamiento del sistema en situaciones particulares.

• Requisitos no funcionales

Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema (ej. cotas de tiempo, proceso de desarrollo, rendimiento, etc.)

Ejemplo 1. La biblioteca Central debe ser capaz de atender simultáneamente a todas las bibliotecas de la Universidad

Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2 s

A su vez, hay tres tipos de requisitos no funcionales:

• Requisitos del producto. Especifican el comportamiento del producto (Ej. prestaciones, memoria, tasa de fallos, etc.)
• Requisitos organizativos. Se derivan de las políticas y procedimientos de las organizaciones de los clientes y desarrolladores (Ej. estándares de proceso, lenguajes de programación, etc.)
• Requisitos externos. Se derivan de factores externos al sistema y al proceso de desarrollo (Ej. requisitos legislativos, éticos, etc.)

• Requisitos del dominio.

Los requisitos del dominio se derivan del dominio de la aplicación y reflejan características de dicho dominio.

Pueden ser funcionales o no funcionales.

Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos mediante el Lenguaje de Intercomunicación de Bibliotecas de España (LIBE). Ej. El sistema de biblioteca no podrá acceder a bibliotecas con material censurado.

Modelo de desarrollo rápido de aplicaciones

El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE.

Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar

También la usabilidad, utilidad y la rapidez de ejecución. El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos

y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos

cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

•Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

•Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

•Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

•Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

•Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Métodos

 Formales

¿Qué es un Método Formal?

Definición: "Método formal es cualquier técnica que trate la construcción y/o el análisis de modelos matemáticos que contribuyen a la automatización del desarrollo de sistemas informáticos"

El papel de los métodos formales en la Ingeniería del Software

Los métodos formales se basan en el empleo de técnicas, lenguajes y herramientas definidos matemáticamente para cumplir objetivos tales como facilitar el análisis y construcción de sistemas confiables independientemente de su complejidad, delatando posibles inconsistencias o ambigüedades que de otra forma podrían pasar inadvertidas.

En los últimos años, la idea de que la formalización matemática del SW es el enfoque más apropiado para conseguir mejorar su calidad va adquiriendo cada vez más fuerza. Los partidarios de los métodos formales defienden que su empleo, a lo largo de todo el ciclo de vida, facilita el desarrollo de especificaciones claras, concisas y no ambiguas, permite el análisis funcional de la especificación y posibilita el desarrollo de implementaciones correctas respecto a su especificación. Sin embargo los detractores aseguran que el empleo de métodos formales supone un volumen de trabajo considerable, aumento en los costes y tiempo de desarrollo y que debe quedar supeditado a herramientas que lo automaticen.

Ventajas de los métodos formales

•Se comprende mejor el sistema.

•La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.

•El sistema se describe de manera más precisa.

•El sistema se asegura matemáticamente que es correcto según las especificaciones.

•Mayor calidad software respecto al cumplimiento de las especificaciones.

•Mayor productividad

Problemática actual de los métodos formales

La falta de madurez en la práctica de los métodos formales es la causa de la imposibilidad de utilizarlos a nivel industrial tal y como se utilizan otros métodos de la Ingeniería del Software. Algunas de estas causas son las siguientes:

•El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.

•Los investigadores por lo general no conocen la realidad industrial.

•Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.

•Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

Clasificación de los métodos formales

Se pueden encontrar multitud de métodos y técnicas formales con lo que los criterios de clasificación son bastante variados. La clasificación más común se realiza en base al modelo matemático subyacente en cada método, de esta manera podrían clasificarse en:

•Especificaciones basadas en lógica de primer orden y teoría de conjuntos: permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Los métodos de este tipo más conocidos son: Z, VDM y B.

•Especificaciones algebraicas: proponen una descripción de estructuras de datos estableciendo tipos y operaciones sobre esos tipos.

Técnicas de  4ta Generación

Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, mas tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.

Los tipos más comunes de generadores de código curen uno o varios de los siguientes aspectos:

•Acceso a base de datos: utilizando lenguajes de consulta de alto nivel.

•Generadores de códigos: a partir de una especificación de los requisitos se genera automáticamente toda la aplicación

•Generación de pantallas: permitiendo diseñar la pantalla dibujándola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada.

•Gestión de entornos gráficos.

•Generación de informes.

Los pasos de los paradigmas son: Recolección de requerimientos, Estrategia de Diseño, Implementación usando T4G y Producto.

Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. Idealmente el cliente debe describir los requerimientos y estos debe traducirse directamente en un prototipo operacional pero este no funciona. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo en este momento el dialogo cliente técnico descrito por los otros paradigmas permanecen como una pequeña parte esencial del enfoque T4G. Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, usando un lenguaje de cuarta generación no procedimental (L4G) sin embargo es necesario un mayor esfuerzo para desarrollar una estrategia del diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para grandes proyectos causará las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales. La implementación usando L4G facilita el que desarrolla al software la descripción de los resultados deseados, los cuales se traducen automáticamente en código fuente para producir dichos resultados. Obviamente debe existir una estructura de datos con información relevante y debe estar rápidamente accesible al L4G. El último paso de la figura anterior contiene la palabra producto para transformar una implementación T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar todas las otras actividades de transición requeridas en los otros paradigmas de la ingeniería de software. Además del software desarrollado con T4g, debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma expeditiva. Los defensores aducen reducciones dramáticas en el tiempo de desarrollo en el software y una mejora significativa en la productividad de la gente que construye el software. Los retractores de este paradigma aducen que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g está abierto a discusión.

Entre las críticas más habituales están las siguientes:

•No son más fáciles de utilizar que que los lenguajes de tercera generación.

•El código fuente que produce es ineficiente, al estar generado automáticamente no pueden hacer uso de de los trucos habituales para aumentar el rendimiento, que se basan en el buen conocimiento de cada caso en particular.

•Sólo son aplicables al software de gestión, la mayoría de las herramientas de cuarta generación están orientadas a la generación a partir de grandes bases de datos, pero últimamente están surgiendo herramientas que generan esquemas de códigos para aplicaciones de ingeniería y de tiempo real.

Algunos lenguajes de cuarta generación:

Progress 4GL, o Progress Open Edge como se han llamado sus últimas versiones, es un lenguaje muy utilizado pues es portable y muy confiable. Es una plataforma diseñada para ayudar a los desarrolladores en la construcción de aplicaciones empresariales de forma rápida, esto ayuda a recuperar la inversión de manera más rápida. Tiene la facilidad de fácilmente conectarse e integrarse con clientes, con otras aplicaciones y con distintas bases de datos.

SQL (Structured Query Language): SQL (lenguaje de consultas estructurado) es un lenguaje de acceso a bases de datos relacionales con el cual se pueden crear y manipular las mismas.

WinDev: Permite el desarrollo de interfaz gráfica. Se pueden realizar muchos tipos de aplicaciones, entre ellas: Gestión, industriales, médicas. En WinDev la calidad de las aplicaciones dependen menos del equipo de desarrollo que con otras herramientas, esto debido a que trae un conjunto de funciones avanzadas sin la necesidad de que alguien las programe, por ejemplo, puede ser que el entorno detecte que mejoras para aumentar el rendimiento y la velocidad del sistema y este mismo las sugiere y las realiza automáticamente, además, posee una herramienta generadora de reportes automática.

PowerBuilder: Es un entorno gráfico de programación orientado a objetos para el desarrollo de aplicaciones cliente/servidor, distribuidas y web. Incluye herramientas para generar reportes, acceder bases de datos y para crear interfaz gráfica.

Mathematica: En Mathematica se contemplan muchos de los aspectos técnicos de la computación como el manejo numérico, la conversión de datos, la visualización y la creación de interfaces para el usuario. El avance intelectual que hizo posible el desarrollo de un paquete tan completo fue la invención de un lenguaje que fuera capaz de manipular la gran cantidad de objetos que alberga la computaron técnica. Por su completitud es un paquete que a pesar de inicialmente ser usado por técnicos ha pasado a ser un ambiente manejado por gran cantidad de personas que han aprendido desplegar todas las utilidades que el programa ofrece como por ejemplo los estudiantes a los que les permite aprender de manera interactiva.

Conclusión:

La evolución de los lenguajes tiende cada vez más a alejarnos de la maquina o hardware, creando una mayor abstracción de los problemas a resolver, esto es beneficioso pues genera un ahorro significativo de recursos como el tiempo que es tan valioso actualmente.

Los Lenguajes de Cuarta Generación tienden a ser muy compatibles entre sus mismas evoluciones lo que nos permite crear aplicaciones con la confianza de que el trabajo realizado no será desechado más adelante.

Paquetes tan poderosos como Mathematica hacen posible que las técnicas de computación mejoren constantemente pues brindan una mayor facilidad para el análisis y diseño de nuevas herramientas, mientas también ayudan a áreas tan importantes como la educación, todo esto empleando la misma herramienta.

Es importante resaltar que para utilizar un 4GL se debe tener claro que si se desea manipular para sacarle un mayor rendimiento, se debe de hacer cambiando la forma normal de hacer software. Para esto, los programadores deben de volverse analistas, deben dominar técnicas estructuradas, conceptos de diseño de interfaz grafica, conceptos de arquitectura, conceptos de orientación a objetos y de principios de diseño. Y todo esto para poder obtener una mayor productividad, una mayor facilidad al dar mantenimiento y además una mejor apariencia de la aplicación.