RSS
Write some words about you and your blog here

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

Los diez mandamientos de los metodos formales

La decisión de hacer uso de los métodos formales en el mundo real no debe de adoptarse a la ligera. Bowen y Hinchley han acuñado los diez mandamientos de los métodos formales, como guía para aquellos que estén a punto de embarcarse en este importante enfoque de la Ingenieria del Software.

1.Seleccionarás la notación adecuada. Con objeto de seleccionar eficientemente dentro de la amplia gama de lenguajes de especificación formal existente, el ingeniero del software deberá considerar el vocabulario del lenguaje, el tipo de aplicación que haya que especificar y el grado de utilización del lenguaje.

2.Formalizarás, pero no de más. En general, resulta necesario aplicar los métodos formales a todos los aspectos de los sistemas de cierta envergadura. Aquellos componentes que sean críticos para la seguridad serán nuestras primeras opciones, e irán seguidos por aquellos componentes cuyo fallo no se pueda admitir (por razones de negocios).

3.Estimarás los costes. Los métodos formales tienen unos costes de arranque considerables. El entrenamiento del personal, la adquisición de herramientas de apoyo y la utilización de asesores bajo contrato dan lugar a unos costes elevados en la primera ocasión. Estos costes deben tenerse en cuenta cuando se esté considerando el beneficio obtenido frente a esa inversión asociada a los métodos formales.

4.Poseerás un experto en métodos formales a tu disposición. El entrenamiento de expertos y la asesoría continua son esenciales para el éxito cuando se utilizan los métodos formales por primera vez.

5.No abandonarás tus métodos formales de desarrollo. Es posible, y en muchos casos resulta deseable, integrar los métodos formales con los métodos convencionales y/o con métodos orientados a objetos. Cada uno de estos métodos posee sus ventajas y sus inconvenientes. Una combinación de ambos, aplicada de forma adecuada, puede producir excelentes resultados.

6.Documentarás suficientemente. Los métodos formales proporcionan un método conciso, sin ambigüedades y consistente para documentar los requisitos del sistema. Sin embargo, se recomienda que se adjunte un comentario en lenguaje natural a la especificación formal, para que sirva como mecanismo para reforzar la comprensión del sistema por parte de los lectores.

7.No comprometerás los estándares de calidad. Los métodos formales no tienen nada de mágico, y por esta razón, las demás actividades de SQA deben de seguir aplicándose cuando se desarrollen sistemas.

8.No serás dogmático. El ingeniero de software debe reconocer que los métodos formales no son una garantía de corrección. Es posible (o como algunos probablemente dirían) que el sistema final, aun cuando se haya desarrollado empleando métodos formales, siga conteniendo pequeñas omisiones, errores de menor importancia y otros atributos que no satisfagan nuestras expectativas.

9.Comprobarás, comprobarás y volverás a comprobar. Los métodos formales no absuelven al ingeniero del software de la necesidad de llevar a cabo unas comprobaciones exhaustivas y bien planeadas.

10.Reutilizarás cuanto puedas. A la larga, la única forma racional de reducir los costes del software y de incrementar la calidad del software pasa por la reutilización. Los métodos formales no modifican esta realidad. De hecho, quizás suceda que los métodos formales sean un enfoque adecuado cuando es preciso crear componentes para bibliotecas reutilizables.

Los siete mitos sobre los métodos formales

1.Los métodos formales garantizan que el software esta perfecto. El mito más importante es que los métodos formales serian todopoderosos, si nosotros humildes mortales pudiésemos aplicarlos. Este mito es pernicioso porque nos lleva a expectativas irreales y a la idea de que los métodos formales son de alguna forma todo o nada.

2.Los métodos formales se centran en demostrar corrección. En los Estados Unidos, gran parte del trabajo desarrollado en métodos formales se ha concentrado en la verificación de programas. Esto ha hecho que los métodos formales parezcan muy difíciles y no muy relevantes para la vida real.

3.Los métodos formales son útiles solo para sistemas críticos. Esta creencia se basa en la percepción de la dificultad que implica la aplicación de métodos formales. La verdad es que los sistemas críticos requieren un uso más acucioso de métodos formales, pero cualquier sistema puede beneficiarse con el uso de algunas técnicas de especificación formal.

4.Los métodos formales requieren matemáticos entrenados. Los métodos formales se basan en notaciones matemáticas, y muchas personas creen que esto los hace difíciles para la práctica de los ingenieros de software. Este mito, a su vez, se basa en la percepción de que las matemáticas son intrínsecamente difíciles.

5.Los métodos formales aumentan el costo del desarrollo. Se acostumbraba decir que a pesar que el costo que significaba usar métodos formales era muy alto, de todas formas era conveniente porque resultaba en menores costos de mantenimiento del software.

6.Los métodos formales son incomprensibles para los usuarios. Una especificación formal está llena de símbolos matemáticos que resultan incomprensibles para cualquiera que no esté familiarizado con la notación. De ahí que se suponga que son inútiles para clientes no matemáticos.

7.Los métodos formales no se usan en grandes proyectos reales. Los métodos formales se asocian comúnmente con departamentos académicos y organizaciones de investigación. Se piensa que solo estas organizaciones tienen la capacidad necesaria para usar métodos formales y que estos solo son apropiados para las aplicaciones idealizadas que estos grupos desarrollan.

Ventajas y Desventajas del RAD

Ventajas

*Comprar puede ahorrar dinero en comparación con construir.
*Los entregables pueden ser fácilmente trasladados a otra plataforma.
*El desarrollo se realiza a un nivel de abstracción mayor.
*Visibilidad temprana.
*Mayor flexibilidad.
*Menor codificación manual.
*Mayor involucramiento de los usuarios.
*Posiblemente menos fallas.
*Posiblemente menor costo.
*Ciclos de desarrollo más pequeños.
*Interfaz gráfica estándar.

Desventajas

*Comprar puede ser más caro que construir.
*Costo de herramientas integradas y equipo necesario.
*Progreso más difícil de medir.
*Menos eficiente.
*Menor precisión científica.
*Riesgo de revertirse a las prácticas sin control de antaño.
*Más fallas (por síndrome de "codificar a lo bestia").
*Prototipos pueden no escalar, un problema mayúsculo.
*Funciones reducidas (por "timeboxing").
*Dependencia en componentes de terceros: funcionalidad de más o de
menos, problemas legales.

Caracteristicas del RAD

Entre las principales características del RAD tenemos:

1.Equipos Híbridos

•Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos.
•Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

2. Herramientas Especializadas

*Desarrollo "visual"
*Creación de prototipos falsos (simulación pura)
*Creación de prototipos funcionales
*Múltiples lenguajes
*Calendario grupal
*Herramientas colaborativas y de trabajo en equipo
*Componentes reusables
*Interfaces estándares (API)
*Control de versiones

3. "Timeboxing"

•Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

4. Prototipos Iterativos y Evolucionarios

•Reunión JAD (Joint Application Development):
*Se reúnen los usuarios finales y los desarrolladores.
*Lluvia de ideas para obtener un borrador inicial de los requisitos.

•Iterar hasta acabar:
*Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
*Los diseñadores revisan el prototipo.
*Los clientes prueban el prototipo, depuran los requisitos.
*Los clientes y desarrolladores se reúnen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios.
*Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.

•Notas:

*Cada iteración dura entre un día y tres semanas.
*Reuniones de 2 horas con facilitador que mantiene enfocado al grupo

Modelo de Desarrollo Rapido 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.

Fases de Análisis y Diseño de Sistemas Estructurado

El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:

1)Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2)Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

3)Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4)Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5)Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

6)Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

*Opinión de los administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.