• Author / Uploaded
• AnthonySuarez

Citation preview

INGENIERIA DEL SOFTWARE Parte Tercer: Métodos Convencionales Para La Ingeniería del Software

(CAPITULO – 10 a 19) I.S.P: Ciro Alegría Bazán Anthony Rafael Suárez Puelles Computación e Informático [email protected]

RESUMEN: La Ingeniería del Software es una disciplina o área de la Informática o Ciencias de la Computación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Hoy en día es cada vez más frecuente la consideración del Software como una nueva área de la ingeniería, y el ingeniero del software comienza a ser una profesión implantada en el mundo laboral internacional, con derechos, deberes y responsabilidades que cumplir, junto a una, ya, reconocida consideración social en el mundo empresarial y, por suerte, para esas personas con brillante futuro. Sistemas operativos o desarrollos en Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a una infinidad de áreas tales como: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.

INTRODUCCIÓN Conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la utilización de la materia y de las fuentes de energía. Profesión y ejercicio del ingeniero y el término ingeniero se define como. Persona que profesa o ejerce la ingeniería. Conjunto de conocimientos y técnicas cuya aplicación permite la utilización racional de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras realizaciones provechosas para el hombre. Evidentemente, si la Ingeniería del Software es una nueva ingeniería, parece lógico que reúna las propiedades citadas en las definiciones anteriores. Ingeniería de Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software. Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar, operar (funcionar) y mantenerlos. Ingeniería del Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales. La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de ingeniería al software.

Capítulo 10: INGENIERIA DE SISTEMAS 10.1.SISTEMAS BASADOS EN COMPUTADORAS: El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema: Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido. Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real. Personas. Usuarios y operadores del hardware y software. Documentación. Manuales, formularios y otra información descriptiva que plasma el empleo y funcionamiento del sistema. Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema. 10.2.- LA JERARQUIA DE LA INGENIERIA DE SISTEMA: Independientemente del dominio de enfoque, la ingeniería de sistemas comprende una colección de métodos para navegar de arriba abajo en la jerarquía Ilustrada. El proceso de la ingeniería de sistemas empieza normalmente con una visión global. Es decir, se examina el dominio entero del negocio o del producto para asegurarse de que se puede

establecer el contexto de negocio o tecnológico apropiado. La visión global se refina para enfocarse totalmente en un dominio de interés específico. Dentro de un dominio específico, se analiza la necesidad de elementos del sistema (por ejemplo, información, software, hardware, personas). Finalmente, se inicia el análisis, diseño y construcción del elemento del sistema deseado. En la parte alta de la jerarquía se establece un contexto muy amplio y en la parte baja se llevan a cabo actividades técnicas detalladas hardware software.

10.2.1.- Modelado del Sistema La ingeniería de sistemas de computadora es un proceso de modelado. Tanto si el punto de mira está en la visión global o en la visión detallada, el ingeniero crea modelos que: 

Definan los procesos que satisfagan las necesidades de la visión en consideración;



Representen el comportamiento de los procesos y los supuestos en los que se basa el comportamiento;



Definan explícitamente las entradas exógenas3 y endógenas de información al modelo;



Representen todos las uniones (incluyendo las salidas) que permitan al ingeniero entender mejor la visión.

Simplificaciones que permiten crear el modelo a tiempo. El ingeniero del sistema está modelando las necesidades de la organización suministradora y está trabajando para entender el flujo de información que engendra una orden de suministro. Demanda interna o petición externa. Esto Permite una partición simplificada

de entradas necesaria para generar una orden de trabajo. Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se está modelando un sistema de aviónica para un avión de próxima generación. Como el avión tendrá un diseño de dos motores, todos los dominios de supervisión de la propulsión se modelarán para albergar un máximo de dos motores y sus sistemas redundantes asociados. Restricciones que guían la manera de crear el modelo y el enfoque que se toma al implementar el modelo. Por ejemplo, la infraestructura tecnológica para el sistema de representación en tres dimensiones descrita anteriormente es un solo procesador basado en un Power-PC. La complejidad de cálculo de los problemas debe restringirse para encajar en los Límites de proceso impuestos por el procesador. Preferencias que indican la arquitectura preferida para todos los datos, funciones y tecnología. 10.2.- INGENIERIA DE PROCESO DE NEGOCIO: Esta configuración debe ser diseñada para cambios continuos, desigualmente localizadosen la empresa, debido a cambios en requisitos del negocio y en las propias tecnologías. Estos diversos e incrementales cambios deben ser coordinados a través del entorno distribuido, consistente en hardware y software suministrado por decenas, cuando no cientos, de vendedores. Por supuesto, esperamos que estos cambios los incorporemos sin ruptura con la operativa habitual permitiendo además ampliar la operativa. Se deben analizar y diseñar tres arquitecturas diferentes dentro del contexto de objetivos y metas de negocio:  Arquitectura de datos

 Arquitectura de aplicaciones  Infraestructura de la tecnología La arquitectura de datos proporciona una estructura para las necesidades de información de un negocio o de una función de negocio.

10.5 INGENIERIA DE REQUISITOS: La consecuencia del proceso de ingeniería de sistemas es la especificación de un sistema o producto basado en computadora que se describe genéricamente, en diferentes niveles problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema.

10.4.- INGENIERIA DE PRODUCTO: La meta de la ingeniería de producto es traducir el deseo de un cliente, de un conjunto de capacidades definidas, a un producto operativo. Para conseguir esta meta, la ingeniería de producto debe crear una arquitectura y una infraestructura. El modelado de la fase de análisis asigna requisitos a las representaciones de datos, funciones y comportamiento. El diseño convierte el modelo de análisis en diseños de datos, arquitectónicos, de interfaz y a nivel de componentes del software.

Problemas de comprensión Los clientes/usuarios no están completamente seguros de lo que necesitan, tienen una pobre compresión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del dominio del problema, existen dificultades para comunicar las necesidades al ingeniero del sistema, la omisión de información o por considerar especificación de requisitos que están en conflicto con las necesidades de otros clientes/usuarios, o especificar requisitos ambiguos o poco estables. Problemas de volatilidad. Los requisitos cambian con el tiempo. ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS Una

vez

recopilados los requisitos, el producto obtenido configura la base del análisis de

requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios. Una vez los requisitos han sido identificados, se desarrollarán un conjunto de matrices para su seguimiento. Las matrices de seguimiento se incorporan como parte de un requisito de base de datos y se utiliza para buscar rápidamente los diferentes aspectos del sistema a construir afectados por el cambio de requisito. La tarea de la ingeniería del sistema finaliza con la elaboración de una Especificación del Sistema un documento que sirve de base para las tareas de ingeniería que se realizarán posteriormente.

Capítulo 11: CONCEPTOS Y PRINCIPIOS DEL ANALISIS 11.1.- ANALISIS DE REQUISITOS: El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software. El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación.

Una vez evaluados los problemas actuales y la información deseada (entradas y salidas), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. 11.2.- IDENTIFICACION PARA EL REQUISITOS DEL SOFTWARE: Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. Despliegue de la función de calidad El despliegue de la función calidad (DFC) es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software. Requisitos normales. Se declaran objetivos y metas para un producto o sistema durante las

reuniones con el cliente. Si estos requisitos están presentes, el cliente quedará satisfecho. Ejemplos de requisitos normales podrían ser peticiones de tipos de presentación gráfica,

funciones específicas del sistema y niveles definidos de rendimiento. Requisitos esperados Estos requisitos son implícitos al producto o sistema y pueden ser tan fundamentales que el cliente no los declara explícitamente. Su ausencia sería motivo de una insatisfacción significativa. Requisitos innovadores. Estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias. Por ejemplo, se pide un software procesador de textos con las características estándar. El producto entregado contiene ciertas capacidades de diseño de página que resultan muy válidas y que no eran esperadas.

12.1 LOS ELEMENTOS DEL MODELADO DEL ANALISIS: El modelo de análisis debe lograr tres objetivos primarios: 

Describir lo que requiere el cliente,



Establecer una base para la creación de un diseño de software



Definir un conjunto de requisitos que se pueda validar una vez que se construye el software.

11.3.- PRINCIPIOS DEL ANALISIS: Cada método de análisis tiene su punto de vista. Sin embargo, todos los métodos de análisis se relacionan por un conjunto de principios operativos: 1. Debe representarse y entenderse el dominio de información de un problema. 2. Deben definirse las funciones que debe realizar el software. 3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos). 4. Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente). 5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.

Capítulo 12: MODELADO DEL ANALISIS

12.2.MODELADO DE DATOS: Responde a una serie de preguntas específicas importantes para cualquier aplicación de procesamiento de datos. ¿Cuáles son los objetos de datos primarios que va a procesar el sistema? ¿Cuál es la composición de cada objeto de datos y qué atributos describe el objeto? ¿Dónde residen actualmente los objetos? ¿Cuál es la relación entre los objetos y los procesos que los transforman? Objetos de datos, atributos y relaciones El modelo de datos se compone de tres piezas de información interrelacionadas: el objeto de datos, los atributos que describen el objeto de datos y la relación que conecta objetos de datos entre sí. Cardinalidad y modalidad

Cardinalidad. El modelo de datos debe ser capaz de representar el número de ocurrencias de objetos que se dan en una relación. Modalidad. La modalidad de una relación es cero si no hay una necesidad explícita de que ocurra una relación, o que sea opcional. 12.3.- MODELO DE FLUJO DE INFORMACION

CONCEPTOS Y PRINCIPIOS DE DISEÑO El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas -diseño, generación de código y pruebas- que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar por último a un software de computadora validado. La importancia del diseño del software se puede describir con una sola palabra –CALIDADEl diseño proporciona las representaciones del software que se pueden evaluar en cuanto a calidad. El diseño es la única forma de convertir exactamente los requisitos de un cliente en un producto o sistema de software finalizado.

Después, un modelo de comportamiento usando el diagrama de transición de estados y un modelo de contenido de los datos con un diccionario de datos. Las especificaciones de los procesos y del control proporcionan una elaboración adicional de los detalles. La notación original para el análisis estructurado fue desarrollada para aplicaciones de procesamiento de datos convencionales, pero ahora hay ampliaciones que permiten aplicar el método a los sistemas de tiempo real. El análisis estructurado está soportado por una larga lista de herramientas CASE que ayudan en la creación de cada elemento del modelo y también en el mantenimiento de la consistencia y de la corrección.

Capítulo 13:

13.1.- PRINCIPOS DE DISEÑO: El diseño de software es tanto un proceso como un modelo. El proceso de diseño es una secuencia de pasos que hacen posible que el diseñador describa todos los aspectos del software que se va construir. Sin embargo, es importante destacar que el proceso de diseño simplemente no es un recetario. 13.2.- ARQUITECTURA DEL SOFTWARE: En su forma más simple, la arquitectura es la estructura jerárquica de los componentes del programa (Módulos), la manera en que los componentes interactúan y la estructura de datos que van a utilizar los componentes. Sin embargo, en un sentido más amplio, los «componentes» se pueden generalizar para representar los elementos principales del sistema y sus interacciones. 13.3.- JERARQUÍA DE CONTROL: La jerarquía de control, denominada también estructura de programa, representa la organización de los componentes de programa (módulos) e implica

una jerarquía de control. No representa los aspectos procedimentales del software, ni se puede aplicar necesariamente a todos los estilos arquitectónicos. 13.4.- ESTRUCTURA DE DATOS: La estructura de datos es una representación de la relación lógica entre elementos individuales de datos. Como la estructura de la información afectará invariablemente al diseño procedimental final, la estructura de datos es tan importante como la estructura de programa para la representación de la arquitectura del software. PROCEDIMIENTO DE SOFTWARE La estructura de programa define la jerarquía de control sin tener en consideración la secuencia de proceso y de decisiones. El procedimiento de software se centra en el procesamiento de cada módulo individualmente. El procedimiento debe proporcionar una especificación precisa de procesamiento, incluyendo la secuencia de sucesos, los puntos de decisión exactos, las operaciones repetitivas e incluso la estructura/organización de datos. La modularidad (tanto en el programa como en los datos) y el concepto de abstracción permiten que el diseñador simplifique y reutilice los componentes del software. El refinamiento proporciona un mecanismo para representar sucesivas capas de datos funcionales. El programa y la estructura de datos contribuyen a tener una visión global de la arquitectura del software, mientras que el procedimiento proporciona el detalle necesario para la implementación de los algoritmos. La ocultación de información y la independencia funcional proporciona.

atributos. A nivel más básico, pensamos en la forma global de la estructura física. Pero, en realidad, la arquitectura es mucho más. Es la forma en la que los diferentes componentes del edificio se integran para formar un todo unido. Es la forma en la que el edificio encaja en su entorno y con los otros edificios de su vecindad. Es el grado en el que el edificio consigue su propósito fijado y satisface las necesidades de sus propietarios El ingeniero del software cuenta con diferentes estilos y patrones arquitectónicos. Cada estilo describe una categoría de sistema que abarca un conjunto de componentes que realizan una función requerida por el sistema, un conjunto de conectores que posibilitan la comunicación, la coordinación y cooperación entre los componentes, las restricciones que definen cómo se integran los componentes para conformar el sistema, y los modelos semánticos que facilitan al diseñador el entendimiento de todas las partes del sistema. Han sido propuestos uno o varios estilos arquitectónicos por sistema, y el método de análisis de compromisos para la arquitectura podría utilizarse para evaluar la eficacia de cada

Capítulo 14: DISEÑO ARQUITECTONITO ¿Qué es arquitectura? Cuando hablamos de la «arquitectura» de un edificio, nos vienen a la cabeza diferentes

arquitectura propuesta. Esto se consigue determinando la sensibilidad de los atributos de calidad seleccionados (también llamados dimensiones del diseño) con diferentes

mecanismos de realización que reflejan las propiedades de la arquitectura.

El método de diseño arquitectónico presentado en este capítulo utiliza las características del flujo de datos descritas en el modelo de análisis que derivan de un estilo arquitectónico utilizado comúnmente. El diagrama de flujo de datos se descompone dentro de la estructura del sistema a través de dos enfoques de análisis –el análisis de las transformaciones y/o el análisis de las transacciones-. Se aplica el análisis de las transformaciones a un flujo de información que presenta diferentes límites entre los datos de entrada y de salida. El DFD se organiza en una estructura que asigna los controles de entrada, procesamiento y salida a través de tres jerarquías separadas de módulos de descomposición en factores. El análisis de las transformaciones se aplica cuando un Único ítem de información bifurca su flujo a través de diferentes caminos. El DFD se organiza en una estructura que asigna el control a una subestructura que adquiere y evalúa la transacción. Otra subestructura controla todas las acciones potenciales de procesamiento basadas en la transacción. Una vez que la arquitectura ha sido perfilada se elabora y se analiza contrastándola con los criterios de calidad. El diseño arquitectónico agrupa un grupo inicial de actividades de diseño que conducen a un modelo completo del diseño del software. En los siguientes capítulos, se estudiará el diseño de las interfaces y de los componentes.

Capítulo 15: DISEÑO DE LA INTERFAZ DE USUARIO

El diseño de la interfaz de usuario crea un medio eficaz de comunicación entre los seres humanos y la computadora. Siguiendo un conjunto de principios de diseño de la interfaz, el diseño identifica los objetos y acciones de ésta y luego crea una plantilla de pantalla que constituye la base del prototipo de la interfaz de usuario. 15.1.- EL PROCESO DE DISEÑO DE LA INTERFAZ El proceso de diseño de las interfaces de usuario es iterativo y se puede representar mediante un modelo espiral similar al abordado en él se puede observar que el proceso de diseño de la interfaz de usuario acompaña cuatro actividades distintas de marco de trabajo: 1. Análisis y modelado de usuarios, tareas y entornos. 2. Diseño de la interfaz 3. Implementación de la interfaz 4.

Validación de la interfaz

El diseño de la interfaz de usuario comienza con la identificación de los requisitos del usuario, de las tareas y del entorno. El análisis de tareas es una actividad de diseño que define las tareas y acciones del usuario empleando un enfoque elabora TiVo u orientado a objetos.

EVALUACION DEL DISEÑO

o se quiebra, el usuario puede rechazar un sistema potente basado en computadora.

Capítulo 16: DISEÑO A NIVEL DE COMPONENTES Este diseño consiste en convertir el diseño de datos, interfaces y arquitectura en un software operacional. Para poderlo llevar a cabo, el diseño se deberá representar a un nivel de abstracción cercano a un código. El diseño a nivel de componentes establece los datos algorítmicos que se requieren para manipular las estructuras de datos, efectuar la comunicación entre los componentes del software por medio de las interfaces. E implementar los algoritmos asignados a cada componente. Una vez que se han definido las tareas, los escenarios del usuario se crean y analizan para definir un conjunto de objetos y acciones de la interfaz. Esto es lo que proporciona la base para la creación del formato de la pantalla, el cual representa el diseño gráfico y la colocación de iconos, la definición de un texto descriptivo en pantalla, la especificación y titulación de ventanas y la especificación de los elementos importantes y secundarios del menú. Cuando se va a refinar un modelo de diseño para el sistema se tienen en consideración temas de diseño tales como tiempo de respuesta, estructura de Órdenes y acciones, manipulación de errores y funciones de ayuda. Para construir un prototipo que el usuario pueda evaluar se utilizan diversas herramientas de implementación.

Mediante la utilización de un lenguaje de programación es posible representar el diseño a nivel de componentes. En esencia, el programa se crea empleando como guía el modelo de diseño.

La interfaz de usuario es la ventana del software. En muchos casos, la interfaz modela la percepción que tiene un usuario de la calidad del sistema. Si la ventana se difumina, se ondula

En este capítulo, examinaremos estas líneas generales de diseño.

Un enfoque alternativo es representar el diseño procedimental mediante la utilización de alguna representación intermedia (por ejemplo, gráfica, tabular o basada en texto) que se pueda transformar fácilmente en código fuente. Independientemente del mecanismo que se utilice para representar el diseño a nivel de componentes, la definición de las estructuras de datos, interfaces y algoritmos deberá ajustarse a la diversidad de líneas generales del diseño procedimental establecido como ayuda para evitar errores durante la evolución del mismo diseño.

A un nivel de componentes, el ingeniero del software

De representar estructuras de datos, interfaces y algoritmos con suficiente detalle como para servir de guía en la generación de códigos fuente de lenguajes de programación. Para conseguirlo, el ingeniero utiliza una de las notaciones de diseño que representa los detalles a nivel de componentes o bien en formatos gráficos, tabulares o basados en texto. La programación estructurada es una filosofía de diseño procedimental que restringe el número y tipo de construcciones lógicas que se utilizan para representar el dato algorítmico. El objetivo de la programación estructurada es ayudar a que el diseñador defina algoritmos menos complejos y por tanto más fáciles de leer, comprobar y mantener.

Capítulo 17: TÉCNICAS DE PRUEBA DEL SOFTWARE Para obtener un software con calidad se requiere de la utilización de metodologías y procedimientos estándares para el desarrollo de los requerimientos, el análisis, el diseño, la implementación y, finalmente, las pruebas del software, que son el elemento fundamental para el logro de la calidad de cualquier sistema o parte integrante de éste. Las pruebas permiten nivelar la estrategia de trabajo en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de las soluciones.

Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores.

Las pruebas de caja blanca se centran en la estructura de control del programa. Se obtienen casos de prueba que aseguren que durante la prueba se han ejecutado, por lo menos una vez, todas las sentencias del programa y que se ejercitan todas las condiciones lógicas. La prueba del camino básico, una técnica de caja blanca, hace uso de grafos de programa (o matrices de grafos) para obtener el conjunto de pruebas linealmente independientes que aseguren la total cobertura. La prueba de condiciones y del flujo de datos ejercita más aún la lógica del programa y la prueba de los bucles complementa a otras técnicas de caja blanca, proporcionando un procedimiento para ejercitar bucles de distintos grados de complejidad. Las pruebas de caja negra son diseñadas para validar los requisitos funcionales sin fijarse en el funcionamiento interno de un programa. Las técnicas de prueba de caja negra se centran en el ámbito de información de un programa, de forma que se proporcione una cobertura completa de prueba. Los métodos de prueba basados en grafos exploran las relaciones entre los objetos del programa y su comportamiento. La partición equivalente divide el campo de entrada en clases de datos que tienden a ejercitar determinadas funciones del software. El análisis de valores límite prueba la habilidad del programa para manejar datos que se encuentran en los límites aceptables. La prueba de la tabla ortogonal suministra un método sistemático y eficiente para probar sistemas con un número reducido de parámetros de entrada. Los métodos de prueba especializados comprenden una amplia gama de capacidades del software y áreas de aplicación. Las interfaces arquitecturas

gráficas de usuario, cliente/servidor,

las la

documentación y facilidades de ayuda, y los sistemas de tiempo real requieren directrices y técnicas especializadas para la prueba del software.

Capítulo 18: ESTRATEGIAS DE PRUEBA DE SOFTWARE Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construcción del software. La estrategia proporciona un mapa que describe los pasos que hay que llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos resultantes. Una estrategia de prueba del software debe ser suficientemente flexible para promover la creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes sistemas basados en software. Al mismo tiempo, la estrategia debe ser suficientemente rígida para promover un seguimiento razonable de la planificación y la gestión a medida que progresa el proyecto.

Según el momento, son apropiadas diferentes técnicas de prueba. La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas. La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba. El objetivo de la prueba de software es descubrir errores. Para conseguir este objetivo, se planifica y se ejecutan una serie de pasos; pruebas de unidad, de integración, de validación y del sistema. Las pruebas de unidad y de integración se centran en la verificación funcional de cada módulo y en la incorporación de los módulos en una estructura de programa. La prueba de validación demuestra el seguimiento de los requisitos del software y la prueba del sistema valida el software una vez que se ha incorporado en un sistema superior. Cada paso de prueba se lleva a cabo mediante una serie de técnicas sistemáticas de prueba que ayudan en el diseño de casos de prueba. Con cada paso de prueba se amplía el nivel de abstracción con el que se considera el software. A diferencia de la prueba (una actividad sistemática y planificada), la depuración se puede considerar un arte.

Se han propuesto varias estrategias de prueba del software en distintos libros. Todas proporcionan al ingeniero del software una plantilla para la prueba y todas tienen las siguientes características generales:

A partir de una indicación sintomática de un problema, la actividad de la depuración debe rastrear la causa del error. De entre los recursos disponibles durante la depuración, el más valioso puede ser el apoyo de otros ingenieros de software.

Las pruebas comienzan a nivel de módulo’ y trabajan «hacia fuera», hacia la integración de todo el sistema basado en computadora.

El requisito de que el software sea cada vez de mayor calidad exige un planteamiento más sistemático de la prueba.

Hemos examinado el espacio estratégico de la prueba, considerando los pasos que tienen la mayor probabilidad de conseguir el fin Último de la prueba: encontrar y subsanar los defectos de una manera ordenada y efectiva.

software. Si no se siguen los criterios, habrá seguramente poca calidad. 3.- Existe un conjunto de requisitos implícitos que a menudo no se nombran (por ejemplo, facilidad de mantenimiento). Si el software cumple con sus requisitos explícitos pero falla en los implícitos, la calidad del software no será fiable.

Funcionalidad. El grado en que el software satisface las necesidades indicadas por los siguientes sub atributos: idoneidad, corrección, interoperabilidad, conformidad y seguridad.

CAPÍTULO 19: MÉTRICAS TÉCNICAS DEL SOFTWARE 19.1.- CALIDAD DEL SOFTWARE: Incluso los desarrolladores del software más hastiados estarán de acuerdo en que un software de alta calidad es una de las metas más importantes. Pero, ¿cómo definimos la calidad? 1.- Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad'. 2.- Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la manera en que se hace la ingeniería del

Confiabilidad. Cantidad de tiempo que el software está disponible para su uso. Está referido por la siguiente suba tributos: madurez, tolerancia a fallos y facilidad de recuperación. Usabilidad. Grado en que el software es fácil de usar. Viene reflejado por la siguiente suba tributos: facilidad de comprensión, facilidad de aprendizaje y operatividad. Eficiencia. Grado en que el software hace Óptimo el uso de los recursos del sistema. Está indicado por la siguiente suba tributos: tiempo de uso y recursos utilizados. Facilidad de Mantenimiento. La facilidad con que una modificación puede ser realizada. Está indicada por la siguiente suba tributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.

Portabilidad. La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes PRINCIPIOS DE MEDECION Formulación: la obtención de medidas y métricas del software apropiadas para la representación del software en cuestión. Colección: el mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. Análisis: el cálculo de las métricas y la aplicación de herramientas matemáticas. Interpretación: la evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación. Realimentación: recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo que construye el software.

CARACTERISTICAS FUNDAMENTALES DE LAS METRICAS DEL SOFTWARE Simples y fáciles de calcular. Debería ser relativamente fácil aprender a obtener la métrica y su cálculo no debería demandar un esfuerzo o cantidad de tiempo inusuales. Empírica e intuitivamente persuasivas. La métrica debería satisfacer las nociones intuitivas del ingeniero sobre el atributo del producto en cuestión. Consistentes y objetivas. La métrica debería siempre producir resultados sin ambigüedad. Un tercer equipo debería ser capaz de obtener el mismo valor de métrica usando la misma información del software.

Consistentes en el empleo de unidades y tamaños. El cálculo matemático de la métrica debería emplear medidas que no conduzcan a extrañas combinaciones de unidades. Por ejemplo, multiplicando el número de personas de un equipo por las variables del lenguaje de programación en el programa resulta una sospechosa mezcla de unidades que no son intuitivamente persuasivas. Independientes del lenguaje de programación. Las métricas deberían basarse en el modelo de análisis.

La ciencia del software proporciona un intrigante conjunto de métricas a nivel de código fuente. Usando el número de operadores y operando presentes en el código, la ciencia del software proporciona una variedad de métricas que pueden usarse para valorar la calidad del programa. Se han propuesto pocas métricas técnicas para un empleo directo en las pruebas y mantenimiento del software.

Sin embargo, se pueden emplear muchas otras métricas técnicas para guiar el proceso de las pruebas y como mecanismo para valorar la facilidad de mantenimiento de un programa de computadora.

Recomendaciones Implementacion de un sistema la cual no orienta paso por paso como un sistema puede funcionar complementa mente, con sus características, como vender al mundo

empresarial, hacerlo fiable para las personas que lo van a usar.

Conclusiones Los temas muestran la manera de utilizar los sistemas operativos de un modo seguro, los estudios realizado son completamente aplicables y científicos para la cual los sistemas operativos van evolucionando como el pasar del tiempo.

Referencias INGENIERIA DEL SOFTWARE (Un enfoque práctico) --- Quinta Edición --Autor: Roger S. Pressman