La ingeniería de software requiere llevar a cabo numerosas tareas para los cuales se lleva un control de cada etapa, donde cada una de ellas es indispensable para garantizar la verdadera prueba del software dentro de la empresa, las etapas son las siguientes:
Análisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.
La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de Requisitos.
La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification).
Especificación
Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las interfaces externas, que deben permanecer estables.
Diseño y arquitectura
Se refiere a determinar como funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.
Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.
Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas.
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 como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo.
- Opinión de los administradores
Evaluación de las actitudes de directivos y administradores dentro de la organización así como de los usuarios finales.
• Desempeño del desarrollo
La evaluación del 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.
Cuando la evaluación de sistema se conduce en forma adecuada proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos cuando la evaluación de sistemas se conduce en forma adecuada proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.
Flujo de información de la ingeniería de pruebas para poner lo en práctica dentro de la empresa
Se proporcionan dos clases de entrada al proceso de prueba:
1.) Configuración del software: * Especificación de requerimientos.
* Documento de Diseño.
* Código fuente.
2.) Configuración de prueba: * Plan y procedimiento de prueba.
* Casos de prueba.
* Resultados esperados.
Se lleva a cabo la prueba y se evalúan los resultados obtenidos frente a los resultados esperados. Si se descubren datos erróneos implica que hay un error y hay que corregirlo y empieza el proceso de depuración de errores.
A medida que se van obteniendo los resultados de la prueba se empieza a disponer de una medida cualitativa de la calidad y fiabilidad del software. Las situaciones posibles que pueden aparecer son:
1.) Se encuentran con regularidad serios errores que requieren modificación en el diseño. La calidad y fiabilidad no parecen ser idóneas.
2.) El funcionamiento del software parece ser correcto y los errores que se detectan son fácilmente corregibles. En ese caso puede suceder que:
La calidad y fiabilidad del software sean aceptables.
Las pruebas son inadecuadas para descubrir serios errores.
3.) La prueba no descubre errores. Puede darse el caso de que no se ha llevado a cabo una prueba correcta y los errores siguen presentes en el software.
Diseño de casos de prueba del Software
Se deben de diseñar métodos de prueba que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo. Existen gran cantidad de métodos de diseño de casos de prueba que pretenden garantizar la obtención de un producto correcto. Se clasifican en:
• MÉTODOS DE CAJA NEGRA: se llevan a cabo sobre la interfaz del software. Los casos de prueba pretenden demostrar que las funciones del software se verifican, que la entrada se acepta de forma adecuada y que se produce una salida correcta, así como que la integridad de la información externa se mantiene.
• MÉTODOS DE CAJA BLANCA: se basan en un examen minucioso de los detalles procedimentales para comprobar los diferentes caminos lógicos del software, través de casos de prueba que los recorren.
Puede parecer que con una prueba de caja blanca profunda se obtendrían programas totalmente correctos ya que se diseñan casos de prueba para recorrer todos los caminos lógicos. Pero hay un problema para poder realizar esta prueba exhaustiva, el número de caminos lógicos de un programa suele ser enorme.
La solución estriba en elegir y recorrer una serie de importantes caminos lógicos y probar las estructuras de datos más importantes.
Lo normal es combinar las pruebas de caja blanca con pruebas de caja negra para garantizar la corrección del software.
No hay comentarios:
Publicar un comentario