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.
