Mejoras en el Desarrollo de Software Y Documentación Y Pruebas de Software

Mejoras En El Desarrollo de Software:

En la actualidad, el ritmo de los negocios y de las actividades de cualquier organización tiende a 

intensificarse, a hacerse más acelerado, imponiendo exigencias de tiempo y calidad para poder mantener la operatividad y competitividad de las mismas. Por tanto, surge la necesidad de contar con ciclos de desarrollo más acelerados, pero que mantengan su confiabilidad. Comienzan a plantearse nuevos métodos que intentan incrementar la velocidad, reduciendo el tiempo requerido de desarrollo. Entre los elementos innovadores que se integran en estos métodos se encuentra: El uso de software o herramientas de desarrollo (como CASE; integración de grupos de personas bien capacitadas, enfocadas a la producción de aplicaciones en menor tiempo y de mayor calidad, la diestra utilización de nuevas y no tan nuevas técnicas de desarrollo

 Documentación Y Pruebas  de Software:

En general se habla mucho de la documentación, pero no se la hace, no se le asigna

Presupuesto, no se la mantiene y casi nunca está al día en los proyectos de desarrollo de software. Lo importante es la disponibilidad de la documentación que se necesita en el momento en que se la necesita.La documentación se suele clasificar en función de las personas o grupos a los cuales está dirigida:

La Documentación para Desarrolladores, es aquélla que se utiliza para el propio desarrollo del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas. Obviamente, cuanto más complejo es el sistema, más importante es la documentación. La documentación para desarrolladores a menudo es llamada modelo, pues es una simplificación de la realidad para comprender mejor el sistema como un todo.

La Documentación para Usuarios, es todo aquello que necesita el usuario para la

Instalación, aprendizaje y uso del producto. Puede consistir en guías de instalación, guías del usuario, manuales de referencia y guías de mensajes.

Los usuarios usan los  manuales solamente cuando se produce un error o se desconoce cómo lograr algo muy puntual, y recién cuando la ayuda en línea no satisface las necesidades del usuario. Por lo tanto, si bien es cierto que debemos realizar manuales, la existencia de un buen manual nunca nos libera de hacer un producto amigable para el usuario, que incluso contenga ayuda en línea. Es incluso deseable proveer un software tutorías que guíe al usuario en el uso del sistema, con apoyo multimedia, y que puede llegar a ser un curso online

La Documentación para Administradores o Soporte Técnico, a veces llamada manual de operaciones, contiene toda la información sobre el sistema terminado que no hace al uso por un usuario final. Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación. Como esto no es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad y demás nunca se puede descartar, en general el manual de operaciones es un documento que va engrosándose con el tiempo.

Pruebas En El Desarrollo de Software:

Calidad, Errores y Pruebas:

La calidad no es algo que se pueda agregar al software después de desarrollado si no se

hizo todo el desarrollo con la calidad en mente. Muchas veces parece que el software de calidad es aquél que brinda lo que se necesita con adecuada velocidad de procesamiento. En realidad, es mucho más que eso. Tiene que ver con la corrección, pero también con usabilidad, costo, consistencia, confiabilidad, compatibilidad, utilidad, eficiencia y apego a los estándares.

Como en todo proyecto de cualquier índole, siempre se debe tratar que las fallas sean

mínimas y poco costosas, durante todo el desarrollo. Y además, es sabido que cuanto más tarde se encuentra una falla, más caro resulta eliminarla. Es claro que si un error es descubierto en la mitaddel desarrollo de un sistema, el costo de su corrección será mucho menor al que se debería enfrentar en caso de descubrirlo con el sistema instalado y en funcionamiento.

Categorías de Pruebas:

Pruebas centradas en la verificación

Pruebas centradas en la validación

Las primeras sirven para determinar la consistencia entre los requerimientos y el programa

terminado. Soporta metodologías formales de testeo, de mucho componente matemático. De todas maneras, hay que ser cuidadoso, porque no suele ser fácil encontrar qué es lo que hay que demostrar. La verificación consiste en determinar si estamos construyendo el sistema correctamente, a partir de los requisitos. En general a los informáticos no les gustan las pruebas formales, en parte porque no las

entienden y en parte porque requieren un proceso matemático relativamente complejo.

La validación consiste en saber si estamos construyendo el sistema correcto. Las tareas de validación son más informales. Las pruebas suelen mostrar la presencia de errores, pero nunca demuestran su ausencia.

Las Pruebas y el Desarrollo de Software:

La importancia de esta fase será mayor o menor según las características del sistema

Desarrollado, llegando a ser vital en sistemas de tiempo real u otros en los que los errores sean irrecuperables.

Las pruebas no tienen el objeto de prevenir errores sino de detectarlos. Se efectúan sobre

el trabajo realizado y se deben encarar con la intención de descubrir la mayor cantidad de errores posible. Para realizar las pruebas se requiere gente que disfrute encontrando errores, por eso no es bueno que sea el mismo equipo de desarrollo el que lleve a cabo este trabajo.

En un sistema real, los casos de prueba se deben hacer sobre las partes del sistema en los cuales una buena prueba brinde un mayor retorno de la inversión o en las cuales un error represente un riesgo mayor.

Las pruebas cuestan mucho dinero. Pero para ello existe una máxima: “pague por la

prueba ahora o pague el doble por el mantenimiento después”.

Todo esto lleva a que se deban planificar bien las pruebas, con suficiente anticipación, y

determinar desde el comienzo los resultados que se deben obtener.

 Tipos de pruebas:

Revisiones de código:

Las revisiones de código son las únicas que se podrían omitir de todos los tipos de pruebas, pero tal vez sea buena idea por lo menos hacer alguna de ellas:

    La prueba de escritorio rinde muy poco, tal vez menos de lo que cuesta, pero es una

costumbre difícil de desterrar. Es bueno concentrarse en buscar anomalías típicas, como variables u objetos no inicializados o que no se usan, ciclos infinitos y demás.

   Los recorridos rinden mucho más. Son exposiciones del código escrito frente a pares. El

programador, exponiendo su código, encuentra muchos errores. Además da ideas avanzadas a programadores nuevos que se lleva a recorrer.

   Las llamadas inspecciones de código consisten en reuniones en conjunto entre los

responsables de la programación y los responsables de la revisión. Tienen como objetivo revisar elcódigo escrito por los programadores para chequear que cumpla con las normas que se hayan fijadoy para verificar la eficiencia del mismo.

Pruebas unitarias:

Las pruebas unitarias se realizan para controlar el funcionamiento de pequeñas porciones de código como ser subprogramas (en la programación estructurada) o métodos (en POO). Generalmente son realizadas por los mismos programadores puesto que al conocer con mayor detalle el código, se les simplifica la tarea de elaborar conjuntos de datos de prueba para testearlo.

Pruebas de integración:

Las pruebas de integración tienen como base las pruebas unitarias y consisten en una

progresión ordenada de testeos para los cuales los distintos módulos van siendo ensamblados y probados hasta haber integrado el sistema completo. Si bien se realizan sobre módulos ya probados en forma individual, no es necesario que se terminen todas las pruebas unitarias para comenzar con las de integración. Dependiendo de la forma en que se organicen, se pueden realizar en paralelo a las unitarias.

El orden de integración de los módulos influye en :

La forma de preparar los casos de prueba

Las herramientas a utilizar (módulos ficticios, muñones, impulsores o “stubs”)

El orden para codificar y probar los módulos

El costo de preparar los casos

El costo de la depuración

Tanto es así que se

Pruebas de sistema:

Las pruebas de sistema se realizan una vez integrados todos los componentes. Su objetivo es ver la respuesta del sistema en su conjunto, frente a distintas situaciones. Se simulan varias alternativas que podrían darse con el sistema implantado y en base a ellas se prueba la eficacia y eficiencia de la respuesta que se obtiene.

Pruebas de aceptación:

Las pruebas de aceptación, al igual que las de sistema, se realizan sobre el producto terminado e integrado; pero a diferencia de aquellas, están concebidas para que sea un usuario final quien detecte los posibles errores.

Se clasifican en dos tipos:

Las Pruebas Alfa se realizan por un cliente en un entorno controlado por el equipo de

desarrollo. Para que tengan validez, se debe primero crear un ambiente con las mismas condiciones que se encontrarán en las instalaciones del cliente. Una vez logrado esto, se procede a realizar las pruebas y a documentar los resultados.

Cuando el software sea la adaptación de una versión previa, deberán probarse también los

procesos de transformación de datos y actualización de archivos de todo tipo.

Las Pruebas Beta se realizan en las instalaciones propias de los clientes.

Para que tengan lugar, en primer término se deben distribuir copias del sistema para que cada cliente lo instale en sus oficinas, dependencias y/o sucursales, según sea el caso. Si se tratase de un número reducido de clientes, el tema de la distribución de las copias no representa grandes dificultades, pero en el caso de productos de venta masiva, la elección de los beta testers debe realizarse con sumo cuidado. En el caso de las pruebas Beta, cada usuario realizará sus propias pruebas y documentará los errores que encuentre, así como las sugerencias que crea conveniente realizar, para que el equipo de desarrollo tenga en cuenta al momento de analizar las posibles modificaciones.