Conceptos del Espectro de Gestión

EL ESPECTRO DE LA GESTION

La gestión eficaz de un proyecto de software se centra en las cuatro P's: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos.

El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.

Personal

El <<factor humano>> es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) <<para aumentar la preparación de organizaciones del software.

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equio..

Producto

El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).

Proceso

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.

Proyecto

Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.

PERSONAL

Los participantes.

El proceso del software (y todos los proyectos de software) lo componen participantes que pueden clasificarse en una de estas cinco categorías:

1.- Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
2.- Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
3.- Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
4.- Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado.
5.- Usuarios finales, que interaccionan con el software una vez que ha entregado para la producción.

Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo.

Los jefes de equipo.

Weinberg sugiere que el éxito de los gestores de proyecto se basa en aplicar un estilo de gestión en la resolución de problemas. Es decir, un gestor de proyectos de software debería concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo (mediante palabras y, mucho más importante, con hechos) que la calidad es importante y que no debe verse comprometida.

El equipo de software.

Existen casi tantas estructuras de organización de personal para el desarrollo de software como organizaciones que se dedican a ello.

Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas trabajando durante k años:

1. n individuos son asignados a m diferentes tareas funcionales, tiene lugar relativamente poco trabajo conjunto.
2. n individuos son asignados a m diferentes tareas funcionales (m<n) de manera que se establecen <<equipos>> informales.
3. n individuos se organizan en t equipos; a cada equipo se le asignan una o más tareas funcionales.

La <<mejor>> estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Mantei sugiere tres organigramas de equipo genéricos:

Descentralizado democrático (DD). Este equipo de ingeniería del software no tiene un jefe permanente. Más bien, <<se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas>>.

Descentralizado controlado (DC). Este equipo de ingeniería de software tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas.

Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo.

Mantei describe siete factores de un proyecto que deberían considerarse cuando se planifica el organigrama de equipos de ingeniería del software:

· La dificultad del problema que hay que resolver.
· El tamaño del programa(s) resultante(s) en líneas de código o puntos de función.
· El tiempo que el equipo estará junto (tiempo de vida del equipo).
· El grado en que el problema puede ser modularizado.
· La calidad requerida y fiabilidad del sistema que se va a construir.
· La rigidez de la fecha de entrega.
· El grado de sociabilidad (comunicación) requerido para el proyecto.

Los equipos CC y DC producen menos defectos que los equipos DD, pero estos datos tienen mucho que ver con las actividades específicas de garantía de calidad que aplica el equipo. Los equipos descentralizados requieren generalmente más tiempo para completar un proyecto que un organigrama centralizado y al mismo tiempo son mejores cuando se precisa una gran cantidad de comunicación.

Constantine sugiere cuatro <<paradigmas de organización>> para equipos de ingeniería del software:

1.- Un paradigma cerrado estructura a un equipo con una jerarquía tradicional de autoridad (similar al equipo CC).

2.- El paradigma aleatorio estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo.

3.- El paradigma abierto intenta estructurar a un equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado, pero también utiliza el paradigma aleatorio.

4.- El paradigma sincronizado se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Constantine propone una variación en el equipo descentralizado democrático defendiendo a los equipos con independencia creativa cuyo enfoque de trabajo podría ser mejor llamado <<anarquía innovadora>>. Para conseguir un equipo de alto rendimiento:

· Los miembros del equipo deben confiar unos en otros.
· La distribución de habilidades debe adecuarse al problema.
· Para mantener la unión del equipo, los inconformistas tienen que ser excluidos del mismo.

Aspectos sobre la coordinación y la comunicación.

Hay muchos motivos por los que los proyectos de software pueden tener problemas. La escala (tamaño) de muchos esfuerzos de desarrollo es grande, conduciendo a complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo. La incertidumbre es corriente, dando como resultado un continuo flujo de cambios que impactan al equipo del proyecto. La interoperatividad se ha convertido en una característica clave de muchos sistemas. El software nuevo debe comunicarse con el anterior y ajustarse a restricciones predefinidas impuestas por el sistema o el producto.

Estas características del software moderno, son aspectos de la vida. Para enfrentarse a ellos eficazmente, un equipo de ingeniería del software debe establecer métodos efectivos para coordinar a la gente que realiza el trabajo. Para lograr esto se deben establecer mecanismos de comunicación formales e informales entre los miembros del equipo y entre múltiples equipos.

PRODUCTO

El gestor de un proyecto de software se enfrenta a un dilema al inicio de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida.

Ámbito del software.

El ámbito se define respondiendo a las siguientes cuestiones:

Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultados del contexto?

Objetivos de información. ¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué objetos de datos son requeridos de entrada?

Función y rendimiento. ¿Qué función realiza el software para transformar la información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?

Descomposición del problema.

La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente. Más bien, la descomposición se aplica en dos áreas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se empleará para entregarlo.

PROCESO

El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para (1) los clientes que han solicitado el producto y la gente que realizará el trabajo; (2) las características del producto en sí, y (3) el entorno del proyecto en el que trabaja el equipo de software.

Maduración del producto y del proceso.

La planificación de un proyecto empieza con la maduración del producto y del proceso. Se asumen las siguientes actividades estructurales:

· Comunicación con el cliente- tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación- tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo- tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería- tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente- tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.

Descomposición del proceso

Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido.

Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.

PROYECTO

Para gestionar un proyecto de software con éxito, debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel define diez señales que indican que un proyecto de sistemas de información está en peligro:

1.- La gente del software no comprende las necesidades de los clientes.
2.- El ámbito del producto está definido pobremente.
3.- Los cambios están mal realizados.
4.- La tecnología elegida cambia.
5.- Las necesidades del negocio cambian (o están mal definidas)
6.- Las fechas de entrega no son realistas.
7.- Los usuarios se resisten.
8.- Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente)
9.- El equipo del proyecto carece del personal con las habilidades apropiadas.
10.- Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones.

Modelos de Desarrollo de Software

Introducción

v  Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final.

v  Un modelo de desarrollo establece el orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades.

v  Es necesario destacar el ciclo de vida del proyecto y el modelo de desarrollo.

v  El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo.

v  El modelo de desarrollo nos ayuda a la forma en la que vamos a construir el producto.

v  Ambos se complementan para generar el producto desde el punto de vista técnico y administrativo.

Modelo Lineal SecuencialTambién llamado "Ciclo de vida básico" o "Modelo de casca "Modelo de cascada" ingeniado por Winston Royce, sugiere un enfoque sistemático o más bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

El MLS tiene las siguientes actividades:

* Análisis de los requerimientos del software: es la fase en la cual se reúnen todos los requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos.

* Diseño: es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un esbozo de lo solicitado y se documenta haciéndose parte del software.

* Generación del código: es la etapa en la cual se traduce el diseño para que sea comprensible por la máquina. Esta etapa va a depender estrechamente de lo detallado del diseño.

* Pruebas: esta etapa se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en la detección de errores.

* Mantenimiento: debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos cambios.

El MLS es el paradigma de desarrollo de software más antiguo que existe, sin embargo esto no ha impedido que se haya creado una desconfianza alrededor de él basada en los siguientes errores reales:

* Los proyectos raramente siguen el paradigma secuencial que propone el proyecto.

* A menudo es difícil que el cliente exponga exactamente todos los requisitos.

* El cliente debe tener paciencia.

* Los responsables del desarrollo de software siempre se retrasan innecesariamente.

Modelo de Construcción de Prototipos

Este modelo arranca con el establecimiento de los requerimientos del sistema, se definen  los objetivos del sistema y los requisitos conocidos con base en las áreas de mayor prioridad e importancia para el sistema.

Luego se hace un diseño preliminar, sobre el cual se construye un prototipo o modelo del sistema, compuesto a menudo de ventanas, tablas de la Base de Datos, formatos de entrada y de salida básicos.

Un prototipo es una representación o modelo del producto de programación que, a diferencia de un modelo de simulación, incorpora componentes del producto real. Por lo regular, un prototipo tiene un funcionamiento limitado en cuanto a capacidades, confiabilidad o eficiencia.

Hay varias razones para desarrollar un prototipo; una de ellas es ilustrar los formatos de datos de entrada, mensajes, informes y diálogos al cliente, este es un mecanismo adecuado para explicar opciones de procesamiento y tener un mejor entendimiento de las necesidades de él.

Al igual que el ciclo de vida clásico, la construcción de prototipos puede ser problemática por las siguientes razones:

1.- El cliente ve funcionando lo que parece ser una primera versión del software, ignorando que, por las prisas en hacer que funcione, no hemos considerado los aspectos de calidad o de mantenimiento del software a largo plazo. Cuando se le informa de que el producto debe ser reconstruido, el cliente se vuelve loco y solicita que se apliquen “cuantas mejoras” sean necesarias para hacer del prototipo un producto final que funcione.

2.- El técnico de desarrollo, frecuentemente, impone ciertos compromisos de implementación con el fin de obtener un prototipo que funciones rápidamente. Puede que utilice un sistema operativo inapropiado, o un lenguaje de programación equívoco o simplemente porque ya está disponible y es conocido, puede que implemente ineficientemente un algoritmo, sencillamente para demostrar su capacidad.

Modelo de Desarrollo Rápido de Aplicaciones

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 interfases a fondo.

Obviamente la limitación de tiempo impuestas en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.
• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.

No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.

DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.

Modelo Incremental

Perteneciente a la familia de los Modelos de Procesos Evolutivos, el Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.

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.

Al igual que los otros métodos, 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.

Modelo Espiral

El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. El modelo representado mediante la espiral define cuatro actividades principales:

1.      Planificación: determinación de objetivos, alternativas y restricciones.

2.      Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos.

3.      Ingeniería: desarrollo del producto del "siguiente nivel",

4.      Evaluación del cliente: Valorización de los resultados de la ingeniería.

Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente.

El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".

Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, al propio sistema operacional.

Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.

Modelo de Desarrollo Concurrente

ue escrito por Davis y Sitaram, algunas veces llamado  ingeniería concurrente. Se puede representar  en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software.

El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en 2 dimensiones: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante 3 actividades: diseño, ensamblaje y uso. La dimensión de componentes se afronta con 2 actividades: diseño y realización.

La concurrencia se logra de 2 formas: 1).- las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos; 2).- una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

El modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual del proyecto.

Modelo de Desarrollo basado en Componentes

Incorpora muchas de las características del Modelo Espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo ensamblador de componentes configura aplicaciones desde componentes separados del software (algunas veces llamados "clases").

Esto se debe gracias a que, si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadoras.

En primer lugar se identifica las clases candidatas examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a crear para conseguir el tratamiento. Si estas clases han sido creadas por programas anteriores se almacenan en un biblioteca de clases o depósito. Se determina cuáles de ellas ya existen a fin de reutilizarlas. En caso de que exista alguna que no esté diseñada, se aplican los métodos orientados a objetos. Este proceso se inicia en el estado de Análisis de Riesgos del Espiral y se inserta en el estado de Construcción de Ingeniería.

En resumen, este modelo se basa en ir construyendo con la construcción de cada sistema una biblioteca de Componentes (clases /objetos) , cuando se va a construir un nuevo sistema, se hace el proceso de definir los objetos del sistema, buscar en la librería de objetos, construir los que no existen, meterlos en la biblioteca, emsamblar los objetos, la metodología busca que sea evolutiva pasando por una fase de planificación, análisis de riesgos, ingeniería, construcción y adaptación, evaluación del cliente y repetir estas fases de tal forma que las primeras iteraciones desarrollan los conceptos, al avanzar se desarrollan los nuevos componentes, luego se busca mejorarlos y finalmente se les da mantenimiento.

Modelo de Métodos Formales

Su objetivo es aumentar la rigurosidad, consistencia y completitud en el desarrollo del software y evitar los problemas que son origen de errores en el software.

Una de las técnicas utilizadas para garantizar la calidad en un proyecto software es la verificación formal, que engloba una serie de técnicas matemáticas para demostrar que el software que se está desarrollando se ajusta a las especificaciones.

Un poco de historia

En 1967, fue Robert Floyd quien propuso utilizar lo que se denominó método de aserciones intermedias como una manera de estudiar las propiedades de los programas. Destacó la posibilidad de definir la semántica de las operaciones mediante reglas lógicas afirmando que estas aserciones son válidas después de ejecutarse las operaciones basándose en la información de las aserciones que son válidas antes de ejecutarse dichas operaciones.

Estas ideas fueron perfeccionadas por Hoare dando lugar al método axiomático (precondiciones E/S) donde introdujo la idea de "invariante".

En 1976, Edsger Dijkstra, presentó un método formal llamado precondición más débil, basado en la transformación de predicados wp (weakest precondition). De esta manera rompía con las ideas de verificación a posteriori de Floyd y Dijkstra. La idea principal era invertir los métodos de ambos de tal manera que se pudiera derivar la precondición a partir de la postcondición.

Métodos de verificación

Entre los métodos de verificación más utilizados, se encuentran:

• Aserciones E/S
• Precondición más débil
• Inducción estructural.

Aserciones E/S

Basado en la lógica de Hoare. El programa, en lógica de Hoare, se especifica mediante aserciones que relacionan las entradas y salidas del programa. Se garantiza que si la entrada actual satisface las restricciones de entrada (precondiciones) la salida satisface las restricciones de salida (poscondiciones).

Se utiliza una expresión del tipo P{programa}Q, siendo P y Q aserciones de la lógica, para indicar que si P es cierto antes de la ejecución del programa y dicho programa termina, entonces Q es cierto tras la ejecución de dicho programa. Este método permite tanto la corrección parcial como total de los programas.

Un caso especial son los bucles, donde los predicados deben mostrar una relación invariante, es decir, deben ser ciertos independientemente del número de vueltas del bucle, por lo tanto el predicado debe cumplir lo siguiente:

• Es cierto a la entrada del bucle
• Es cierto en cualquier paso del bucle
• Junto con la negación de la condición del bucle, implica que el predicado se cumple a la salida del bucle.

Precondición más débil

Básicamente, consiste en dada una poscondición POST, encontrar, operando hacia atrás, un programa S tal que wp(S, POST) (la precondición) se satisfaga en un amplio conjunto de situaciones

Dada una proposición (P) S (Q) donde S es un conjunto de sentencias de un módulo de un programa, y donde P y Q son los predicados que se cumplen antes y después de S respectivamente, se dice que P es la precondición más débil (wp) de S, si es la condición mínima que garantiza que R es cierto tras la ejecución de S.

Inducción estructural

La inducción estructural es una técnica de verificación formal que se basa en el principio de inducción matemática.

Dado un conjunto S con una serie de propiedades y una proposición P que se desea probar, la inducción matemática:

• Demuestra que P es cierto para el mínimo número de elementos (o casos triviales) de S.
• Asume que P es cierto para un número de elementos (o casos posibles) de S menores o iguales a N.

Demuestra que entonces P es cierto para el elemento N+1 de S.

Técnicas de 4ta Generación

Todas facilitan al ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico.

-Herramientas

Actualmente, un entorno para el desarrollo de el software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas:

·         Lenguajes no procedí mentales de consulta a bases de datos.

·         Generación de informes.

·         Manejo de datos.

·         Interacción y definición de pantallas.

·         Generación de códigos.

·         Capacidades gráficas de alto nivel.

Capacidades de hoja de cálculo.

Inicial mente estas herramientas eran utilizadas pero solo para aplicaciones muy especificas, y ahora la T4G se ha extendido a todas las categorías de aplicaciones de el software.

Las herramientas T4G generan automáticamente el código fuente basándose en el análisis  y  el diseño.

T4G comienza con el paso de reunión de requisitos; el dialogo cliente-desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G. 

Ventajas y Desventajas

Ventajas:

Reducción en tiempo de desarrollo. 

Desventajas:

Código ineficiente.

No más fáciles de usar que L3G.

Mantenimiento cuestionable.