Ciclo de vida del Software.

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren paravalidar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.

Pruebas Unitarias.

Probar código nunca tuvo tanta importancia en el ciclo de desarrollo de una aplicación hasta hace algunos años, donde se ha desatado una revolución en los procesos de desarrollo, apareciendo nuevas y ágiles forma de construcción, donde ejecutar pruebas (o al menos pruebas unitarias) pasó de ser un proceso tedioso (como las antiguas que se ejecutaban para cumplir estándares como el ISO 9001) a ser una forma de trabajo integrada y productiva en los nuevos procesos de desarrollo.

A pesar de existir diferentes tipos y técnicas de pruebas (unitarias, de integración, aceptación, carga y estress), en este articulo hablaremos del uso de Pruebas Unitarias (Unit Test), pues de todo el conjunto de pruebas, es considerada la más importante para garantizar un proyecto exitoso, por tanto debe ser introducida como una actividad más en el desarrollo.

Que son las pruebas unitarias

Son pruebas dirigidas a probar clases java aisladamente y están relacionadas con el código y la Responsabilidad de cada clase y sus fragmentos de código más críticos.

Pruebas de Integración.

El objetivo fundamental de este programa es diseñar y ejecutar las pruebas necesarias para comprobar que las interfaces entre los distintos módulos de una solución integrada en un solo producto son correctas.

La industria ha trabajado en tres estrategias de integración, las cuales han sido incorporadas por GreenSQA en su metodología de pruebas de integración y aplica en cada caso la que más se ajusta a las necesidades del proyecto de integración:

De arriba a abajo (top-down): Consiste en empezar la integración y la prueba por los módulos que están en los niveles superiores de abstracción, e integrar incrementalmente los niveles inferiores.

De abajo a arriba (bottom-up): Consiste en empezar la integración y la prueba por los módulos que están en los niveles inferiores de abstracción, e integrar incrementalmente los niveles superiores.

De big-bang: Consiste en integrar y probar todo al mismo tiempo. Para determinar que las interfaces entre los componentes del sistema funcionan adecuadamente, GreenSQA propone las Pruebas de Comunicaciones tanto a través de dispositivos remotos, como locales, dependiendo las condiciones del proyecto.

Pruebas Alfa y Beta.

Prueba Alfa: Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado.

Prueba Beta: Una prueba beta se utilice en el desarrollo de software para marcar la segunda fase de pruebas (siendo la primera la fase Alfa). En esta segunda fase se incorpora un grupo selecto de usuarios como probadores de las aplicaciones para obtener no solo corrección de errores de codificación sino también apreciaciones sobre la funcionalidad. Originalmente el termino Prueba Alfa indica la primera fase de pruebas, que incluye pruebas unitarias, pruebas de componentes y pruebas de sistemas. La prueba Beta se puede considerar como las pruebas anteriores a la liberación al público en general.

Aprovechando la Web, los probadores Beta, que antes eran un puñado de usuarios, ahora constituyen una gran y amplia población que permite darle al programa una prueba en «el mundo real» y para proveer una vista previa de las nuevas versiones.

Tipos de errores.

De Sintaxis:

Los errores de sintaxis son aquéllos que aparecen mientras escribe el código. Visual Basic comprueba su código cuando lo escribe en la ventana del Editor de código y le avisa si comete algún error, como escribir mal una palabra o utilizar un elemento del lenguaje incorrectamente. Los errores sintácticos son los errores más frecuentes. Se pueden corregir fácilmente en el entorno de codificación en cuanto se producen.

Nota

La instrucción Option Explicit es una medida para evitar los errores de sintaxis. Le obliga a declarar, por anticipado, todas las variables que se vayan a utilizar en la aplicación. De este modo, cuando se utilicen las variables en el código, cualquier error tipográfico que se produzca se capturará de forma inmediata, y podrá corregirse.

De ejecución:

Los errores en tiempo de ejecución son aquellos que aparecen solamente después de la compilación y la ejecución del código. Pueden darse errores de este tipo, por ejemplo, en fragmentos de código aparentemente correctos, por no presentar errores sintácticos, pero que no se ejecutan correctamente. Por ejemplo, podría escribir correctamente una línea de código que abre un archivo. Pero, si el archivo está dañado, la aplicación no podrá ejecutar la función Open y se detendrá su ejecución. La mayoría de los errores de este tipo pueden corregirse modificando el código que presenta errores, para después compilarlo y volver a ejecutarlo.

De lógica:

Los errores lógicos son aquellos que aparecen cuando la aplicación está en funcionamiento. Son a menudo resultados no deseados o inesperados en respuesta a acciones del usuario. Por ejemplo, una clave mal escrita u otra influencia externa podría hacer que la aplicación dejase de funcionar aún siendo correctos los parámetros, o que simplemente no funcionase. Por lo general, los errores lógicos son los más difíciles de corregir, puesto que no siempre está claro dónde se originan

Requerimientos mínimos (Hardware y Software).

Requisitos mínimos de hardware:

Escenario	CPU necesaria	RAM necesaria
Cliente	Pentium a 90 MHz*	32 MB**
Servidor	Pentium a 133 MHz*	128 MB**

*O la CPU mínima requerida para ejecutar el sistema operativo, lo que sea mayor.

**O la RAM mínima necesaria para ejecutar el sistema operativo, lo que sea mayor.

Hardware recomendado

Escenario	CPU recomendada	RAM recomendada
Cliente	Pentium a 90 MHz o más rápidoft	96 MB o más
Servidor	Pentium a 133 MHz o más rápido	256 MB o más

Requerimientos mínimos de software:

Para instalar Dotnetfx.exe, se debe tener uno de los siguientes sistemas operativos con Microsoft Internet Explorer 5.01 o posterior instalado en el equipo:

• Microsoft® Windows® 98
• Segunda edición de Microsoft® Windows® 98
• Microsoft® Windows® Millennium Edition (Windows Me)
• Microsoft® Windows NT® 4 (Workstation o Server) con Service Pack 6a
• Microsoft® Windows® 2000 (Professional, Server, o Advanced Server) con el último Service Pack de Windows y actualizaciones críticas que se pueden obtener en el sitio Web de Microsoft Seguridad (www.microsoft.com/spanish/seguridad).
• Microsoft® Windows® XP (Home o Professional)
• Familia de Microsoft® Windows® Server 2003

Precaución

Si instala Dotnefx.exe en Windows Server 2003 Beta 3, dañará la versión de .NET Framework instalada con el sistema operativo. Windows Server 2003 Beta 3 instala la versión 1.0.3215 de .NET Framework. Si se instala una versión posterior de .NET Framework, la versión 1.0.3215 resultará dañada. Si se instala una versión posterior, se puede ejecutar y utilizar la versión posterior. Sin embargo, no se podrá utilizar la versión 1.0.3215, ni siquiera tras desinstalar la versión posterior.

Software recomendado

Dependiendo de los requisitos de la aplicación, puede que también sea necesario instalar uno o varios de los siguientes componentes o aplicaciones:

• MDAC 2.6 o una versión posterior para el acceso a datos, que se puede obtener en el sitio Web Universal Data Access.
• WMI básico para instrumentación de Windows, que se puede obtener en el sitio Web de Microsoft MSDN Download Center en http://www.msdn.microsoft.com/downloads/?url=/downloads/sample.asp?url=/msdn-files/027/001/576/msdncompositedoc.xml&frame=true.

Nota

Si no se cumplen los requisitos mínimos de software recomendado, el programa de instalación no bloqueará la instalación ni avisará de la ausencia de los mismos.

Software de servidor recomendado

Dependiendo de los requisitos de la aplicación, puede que también sea necesario el software de servidor siguiente:

• MDAC 2.7 para los datos en el servidor, que se puede obtener en el sitio Web Universal Data Access.
• Servicios de Internet Information Server (IIS) en el servidor de Windows 2000, Windows XP (Professional) y Windows Server 2003. Se precisa para utilizar aplicaciones ASP.NET.

Evaluación del Software.

El desarrollo de cualquier software tiene como único objetivo satisfacer una necesidad planteada por un cliente. Pero ¿cómo puede ser un desarrollador si el producto construido corresponde exactamente con lo que el cliente pidió? ¿Cómo puede un desarrollador estar seguro, que el producto que ha construido va a funcionar correctamente? Para esto es recomendable, que el producto de software sea evaluado a medida que se va construyendo. Por lo tanto, se hace necesario llevar a cabo, en paralelo al proceso de desarrollo, un proceso de evaluación a comprobación de los distintos productos o modelos que se van generando, en el que participarán desarrolladores y clientes, lo que dará como resultado un mejor producto, aumentando de manera significativa la satisfacción del usuario final.

Criterios de calidad para evaluar Software.

Un enfoque actual sobre la calidad del software

Oscar M. Fernández Carrasco1, Delba García León2 y Alfa Beltrán Benavides3

1. Investigador Agregado. Centro de Desarrollo Informático. SOFTCAL, SIME.
2. Especialista en Sistemas de Computación.
3. Aspirante a Investigador.

Uno de los problemas que se afrontan actualmente en la esfera de la computación es la calidad del software. Desde la década del 70, este tema ha sido motivo de preocupación para especialistas, ingenieros, investigadores y comercializadores de softwares, los cuales han realizado gran cantidad de investigaciones al respecto con dos objetivos fundamentales:

1. ¿Cómo obtener un software con calidad?
2. ¿Cómo evaluar la calidad del software?

Ambas interrogantes conllevan amplias respuestas, pero están estrechamente ligadas con el concepto de la calidad del software, que es el resultado de la primera y la fuente de la segunda.

¿QUE ES LA CALIDAD DEL SOFTWARE?

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.

La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de «cero fallas»; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.

La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.

¿COMO OBTENER UN SOFTWARE DE CALIDAD?

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.

El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.

El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.

El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

¿COMO CONTROLAR LA CALIDAD DEL SOFTWARE?

Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, «usted no puede controlar lo que no se puede medir».

Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.

Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.

Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:

• Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
• Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.
• Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.
• Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.

Pruebas del Software.

La prueba de software involucra las operaciones del sistema bajo condiciones controladas y evaluando los resultados.  Las condiciones controladas pueden ser normales o anormales.  La prueba puede intencionalmente esforzar al programa y producir errores en las respuestas para determinar si los sucesos ocurren cuando no tendrían que ocurrir o cuando los hechos no suceden cuando deberían suceder.

La prueba de software esta detectada a la deteccion.

La mayoría de las grandes organizaciones asumen la responsabilidad del control de calidad y prueba de software a tal medida que en la producción se incluyen desarrolladores de sistemas (analistas, programadores) y un grupo dedicado a la prueba de software para que estos grupos antes mencionados trabajen en conjunto cumpliendo el control de calidad (prevención) y la prueba de software (detección) logrando una tarea exitosa.