jueves, 7 de junio de 2007

CAPÍTULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE

Una Estrategias 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 cobo como parte de la prueba, cuándo se deben de planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir.

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.

Se le llama prueba a un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente.

Plantilla para las pruebas del software: Es un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba.

Verificación.- Se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica.

Validación.- Se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requerimientos del cliente.

La ingeniería de sistemas define el papel del software, donde se establece el dominio de la información, la función el comportamiento, el rendimiento, las restricciones y los criterios de validación del software.

La estrategia para la prueba del software se puede ver en el contexto de espiral de la siguiente manera:

a) La prueba de unidad: Comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada en código fuente. Esta avanza, al movernos hacia fuera de la espiral, hasta llegar a la prueba de integración.
b) Prueba de integración: Aquí nos centramos en el diseño y la construcción de las arquitecturas del software.
c) Prueba de validación: Aquí se validan los requisitos establecidos como parte del análisis de requisitos del software, comparándolos con el sistema que ha sido construido.
d) Prueba del sistema: Aquí se prueba como un todo el software y otros elementos del sistema. Para probar el software de computadora nos movemos hacia fuera por una espiral que, a cada vuelta, aumenta el alcance de la prueba.

Pasos para definir una estrategia de prueba correcta

1) Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas.
2) Establecer los objetivos de la prueba de manera explícita.
3) Comprender qué usuarios van a manejar el software y desarrollar un perfil para cada categoría de usuario.
4) Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido
5) Construir un software robusto diseñado para probarse así mismo
6) Usar revisiones técnicas formales efectivas como filtro antes de la prueba
7) Usar revisiones técnicas formales par evaluar la estrategia de prueba y los propios casos de prueba
8) Desarrollar un enfoque de mejora continua al proceso de prueba

PRUEBA DE UNIDAD

Esta prueba centra el proceso de verificación en la mejor unidad de diseño del software, que es el componente software o módulo.

Antes de esta prueba, la comprobación selectiva de los caminos de ejecución es una tarea esencial. Se deben diseñar casos de prueba para detectar errores, debido a cálculos incorrectos, comparaciones incorrectas o flujo de control inapropiados.

Las pruebas del camino básico y de bucles son técnicas muy efectivas para descubrir una gran cantidad de errores en los caminos.

Los errores más comunes que ocurren durante la prueba de unidad son:

1) Precedencia aritmética incorrecta o mal interpretada
2) Operaciones de modo mezcladas
3) Inicializaciones incorrectas
4) Falta de precisión
5) Incorrecta representación simbólica de una expresión

Se llama controlador a un programa principal que acepta los datos del caso de prueba, pasa estos datos al módulo e imprime los resultados importantes.

PRUEBA DE INTEGRACIÓN

Está prueba es una técnica sistemática para construir la estructura del programa, mientras que al mismos tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.

El objetivo de esta prueba es tomar los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.

Prueba de integración descendente.- Es un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal; después los módulos subordinados al módulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura.
Prueba de integración ascendente.- Empieza la construcción y la prueba con los módulos atómicos. Aquí los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de resguardos.

Prueba de regresión.- Es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados.

Prueba de humo.- Es un método de prueba de integración que es comúnmente utilizada cuando se han desarrollado un producto software empaquetado.

PRUEBA DE VALIDACIÓN

La validación se consigue cuando el software funciona de acuerdo a las expectativas razonables del cliente. La validación permite descubrir errores, pero su enfoque esta en el nivel de requisitos, sobre cosas que son necesarias para el usuario final.

Criterios de la prueba de validación.

La validación se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Un plan de prueba traza la clase de pruebas que se han de llevar a cabo, y un procedimiento de prueba define los casos de prueba específicos en un intento por descubrir errores de acuerdo con los requisitos. Tanto el plan como el procedimiento estarán diseñados para asegurar que se satisfacen todos los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentación es correcta e inteligible y que se alcanzaros otros requisitos como la portabilidad, la compatibilidad, recuperación de errores, facilidad de mantenimiento, etc.

Una vez procedido cada caso de prueba pueden darse una de dos condiciones

1. Las características de funcionamiento o rendimiento están de acuerdo a las especificaciones y son aceptables.
2. Se descubre una desviación de las especificaciones y se crea una lista de deficiencias.

Las desviaciones o errores encontrados en esta fase del proyecto raramente se pueden corregir de la terminación planificada.

REVISION DE LA CONFIGURACIÓN

Un elemento importante del proceso de validación es la revisión de la configuración o también conocida como auditoria consiste en asegurarse de que todos los elementos de la configuración de software se han desarrollado apropiadamente, se han catalogado y están suficientemente detallados para soportar la fase de mantenimiento durante el ciclo de vida del software.

PRUEBAS ALFA Y BETA

La 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 registrando los errores y los problemas de uso. Las pruebas alfa se llevan en un entorno controlado.

La prueba Beta se lleva a cabo por los usuarios finales en los lugares de trabajo de los clientes. A diferencia de la prueba alfa el desarrollador no esta presente normalmente. La prueba beta es aplicación en vivo del software en un entorno no controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y así prepara una versión del producto de software para toda la clase de clientes.

PRUEBA DEL SISTEMA

La prueba del sistema esta constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se han integrado todos los elementos del sistema y que se realizan las funciones apropiadas.

PRUEBA DE RECUPERACION

Es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva acabo apropiadamente. Si la prueba es automática (llevada a cabo por el propio sistema) hay que evaluar la corrección de la inicialización, de los mecanismos de recuperación de los estados del sistema, de la recuperación de datos y del procesos de rearranque. Si la recuperación requiere la intervención humana, hay que evaluar los tiempos medios de recuperación TMR para determinar si están dentro de los limites aceptables.

PRUEBAS DE SEGURIDAD

Intenta verificar que los mecanismos de protección incorporados al sistema lo protegerán de accesos impropios. Durante esta prueba el responsable de la misma desempeña el papel de un individuo que desea entrar en el sistema. Debe de intentar conseguir las claves por cualquier medio, puede atacar el sistema con software a medida, diseñado para romper con cualquier defensa que se haya construido, debe bloquear el sistema , negando el servicio a otras personas, debe producir a puposito errores del sistema, intentando acceder durante la recuperación o debe de curiosear entre los datos sin protección, tratando de encontrar la clave de acceso al sistema.

PRUEBA DE RESISTENCIA (STREES)


Ejecuta un sistema de forma que demande recursos, frecuencia o volúmenes anormales. Esencialmente el programa.

Una variante de esta prueba es la prueba de Sensibilidad, esta intenta descubrir combinaciones de datos dentro de una clase de entrada valida que pueda producir inestabilidad o un proceso incorrecto.

PRUEBA DE RENDIMIENTO

Esta diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado

EL ARTE DE LA DEPURACIÓN

La depuración ocurre como consecuencia de una prueba efectiva , o sea que se ha descubierto un error, la depuración es el proceso que elimina el error.

EL PROCESO DE DEPURACIÓN

Este proceso siempre tiene uno de los dos resultados siguientes:

1. Se encuentra la causa, se corrige y elimina.
2. No se encuentra la causa.

Varias características de los errores nos dan una pista para detectarlos:

1. El síntoma y la causa pueden ser remotamente geográficos entre si.
2. El síntoma puede desaparecer temporalmente al corregir otro.
3. El síntoma puede realmente estar por algo que no es un error.
4. El síntoma puede estar causado por un error humano de no fácil detección.
5. El síntoma puede ser el resultado de problemas de temporizacion en vez de proceso.
6. Puede ser difícil reproducir exactamente lasa condiciones de entrada.
7. El síntoma puede aparecer de forma intermitente.
8. El síntoma puede ser debido a causas que distribuyen por una serie de tareas ejecutándose en diferentes procesadores.

CONSIDERACIONES PSICOLOGICAS

La depuración es uno de los procesos mas frustrantes de la programación. Contiene elementos de resolución de problemas o de rompecabezas, junto con el desagradable reconocimiento de que se ha cometido un error. La enorme ansiedad y la no inclinación a aceptar la posibilidad de cometer errores hace que la tarea sea extremadamente difícil. Afortunadamente también se da un gran alivio y disminuye la tensión cuando el error es finalmente corregido.

ENFOQUE DE DEPURACIÓN

El objetivo principal de la depuracion es encontrar y corregir el error en el software. El objetivo se consigue mediante una combinación de una evaluación sistemática, de intuición y de suerte.

Existen tres enfoques que se pueden proponer para la depuración:

1. Fuerza bruta.- Es la depuración mas común y menos eficiente a al hora de aislar la causa del error y se aplica cuando todo lo demás falla. Mediante una filosofía de dejar que la computadora encuentre el error se hacen volcados de memoria, trazas de ejecución y se cargan multitud de sentencias “mostrar” en el programa buscando así alguna pista que nos lleve al origen del error.

2. Vuelta atrás.- Es un enfoque mas normal para la depuración que se puede utilizar con éxito para pequeños programas. Partiendo del lugar donde se descubre el síntoma se recorre hacia atrás manualmente el código fuente hasta llagar a la posición del error.

3. Eliminación de Causas.- Se manifiesta mediante inducción o deducción e introduce el concepto de partición binaria. Los datos relacionados con la causa del error se organizan para aislar las posibles causas. Se llega una hipótesis de causa y se usan los datos anteriores para probar o revocar la hipótesis.

Se debe de hacerse tres preguntas antes de hacerse una corrección que elimine la causa del error.

1. ¿Se repite la causa del error en otra parte del programa?
2. ¿Cual es el siguiente error que se podrá presentar a raíz de la corrección que se va a realizar ?
3. ¿Qué podríamos haber hecho para corregir el error la primera vez?

lunes, 21 de mayo de 2007

CAPITULO 17: TECNICAS DE PRUEBA DEL SOFTWARE

FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Las técnicas facilitan una guía sistemática para diseñar pruebas que complementen la lógica interna de los componentes de software y verifiquen los dominios de entrada y salida del programa para descubrir errores en la funcionalidad, el comportamiento y el rendimiento.
Objetivos de las pruebas:
1. La prueba es el proceso de ejecución de un programa con la intención de descubrir u error.2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Principios de las pruebas:

• A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente.
• Las pruebas deberían de planificarse mucho antes de que empiecen.
• El principio de Pareto es aplicable a la prueba de software (el 80% de los errores se encuentra en un 20% del programa).
• Las pruebas deberían de comenzar con lo pequeño y progresar hacia lo grande.
• No son posibles las pruebas exhaustivas.
• Para ser más eficaces, las pruebas deberían de ser realizadas por un equipo independiente.

Facilidad de Prueba del software.- es simplemente la facilidad con la que se puede probar el programa de computadora. Se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto.

La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.

Operabilidad.- cuanto mejor funcione, mas eficientemente se puede probar.
Obserbabilidad.- lo que ves es lo que pruebas.
Controlabilidad.- cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.
Capacidad de descomposición.- Controlado el ámbito de las pruebas, podemos aislar mas rápido los problemas y llevara a cabo mejores pruebas de regresión.
Simplicidad.- Cuanto menos haya que probar, mas rápido podemos probarlo.Estabilidad.- Cuanto menos cambios, menos interrupciones a las pruebas.
Facilidad de comprensión.- Cuanta más información tengamos, mas inteligente serán las pruebas.

Una buena prueba debe de tener los siguientes atributos:

1. Debe de tener una alta probabilidad de encontrar un error.
2. No debe de ser redundante.
3. debería de ser de la mejor cosecha.
4. No debería de ser ni demasiado sencilla ni demasiado compleja.

DISEÑO DE CASOS DE PRUEBA

Debemos diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo posible.

Cualquier producto de ingeniería puede probarse de una de estas dos formas:
1. Conociendo la función especifica para la que fue diseñado el producto (Caja Negra)2. Conociendo el funcionamiento del producto. (Caja Blanca)

Cuando se considera el software de computadora la prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lógica interna del software.La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles.

PRUEBA DE CAJA BLANCA

A veces denominada prueba de caja de cristal es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para obtener los casos de prueba. Los casos de prueba que se obtienen:
1. Garantizan que se ejercita por lo menos una vez todos los caminos independientes de cada modulo.
2. Que se ejerciten todas las decisiones lógicas en sus vertientes verdaderas y falsa.
3. Que se ejecuten todos los bucles en sus límites y con sus limites operacionales.
4. Que se ejerciten las estructuras internas de datos para asegurar su validez.

PRUEBA DEL CAMINO BASICO

Es una técnica de prueba de caja blanca. Permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución y garantizan que se ejecute por lo menos una vez cada sentencia del programa.

Grafo de Flujo.- Representa el flujo de control lógico mediante el uso de un diagrama de flujo para representar la estructura de control del programa.

Cada circulo se denomina NODO y representa una o mas sentencias procedimentales. Las flechas se denominan ARISTAS o ENLACES que representan el flujo de control. Las áreas delimitadas por aristas o nodos se denominan REGIONES. Cada nodo que contiene una condición se denomina NODO PREDICADO y se caracteriza porque dos o mas aristas emergen de el.

Complejidad Ciclomatica.-Es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica del programa. Cuando se usa en el contexto del método de prueba del camino básico el valor calculado como complejidad ciclomatica define el numero de caminos independientes del conjunto básico de un programa y nos da un limite superior para el numero de pruebas que se deben de realizar para asegurar que se ejecuta cada sentencia por lo menos una vez.

Camino independiente.- Es cualquier camino que el programa produce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condición.

La complejidad se puede calcular de tres formas.
1. El numero de regiones del grafo de flujo coincide con la complejidad ciclomatica.
2. La complejidad ciclomatica, V(G), de un grafo de flujo se define como:V(G)=A-N+2Donde A es el numero de aristas del grafo y N es el numero de nodos.
3. La complejidad ciclomatica, V(G), de un grafo de flujo también se define como:V(G)=P+2Donde P es el numero de nodos predicado contenidos en grafo de flujo (G).
Matriz de grafos.- Matriz cuadrada cuyo tamaño (numero de filas y columnas) es igual al numero de nodos del grafo de flujo. Cada fila y cada columna corresponde a un nodo especifico y las entradas de la matriz corresponden alas aristas entre los nodos.

PRUEBA DE LA ESTRUCTURA DE CONTROL

Prueba de condición.- método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el modulo de un programa.

Una condición simple es una variable lógica o una expresión relacional precedida por un operador NOT.

La expresión condicional toma esta forma E1 E2 donde E1 y E2 son expresiones aritméticas y puede ser un signo de <, >, =>, <=, =.

Una condición compuesta esta formada por dos o mas condiciones simples, operadores lógicos y paréntesis.

Método de la prueba de condiciones.- Se centra en la prueba de cada una de las condiciones del programa.

Este método tiene dos ventajas: Que la cobertura de la prueba de una condición es sencilla; y que la cobertura de la prueba de las condiciones de un programa de una orientación para generar pruebas adicionales del programa.

Prueba de ramificaciones.- Es la estrategia de prueba de condiciones más sencilla.

Prueba del dominio [WHI80] requiere la realización de tres o cuatro pruebas para una expresión relacional.

Prueba de flujo de datos.- Selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.

PRUEBA DE BUCLES

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software.

La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles.

Se pueden definir los siguientes tipos de bucles:

1) Bucles simples: A estos se les debe de aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos por el bucle.

a) Pasar por alto totalmente el bucle
b) Pasar una sola vez por el bucle
c) Pasar dos veces por el bucled) Hacer m pasos por el bucle con m

2) Bucles anidados: Aquí el número de posibles pruebas aumentaría geométricamente a medida que aumenta el nivel de anidamiento. Con lo que se llevaría a un número impracticable de pruebas.
Beizer sugiere un enfoque que ayuda a reducir el número de pruebas.
a) Comenzar por el bucle más inferior
b) Llevar a cabo las pruebas de bucles simples para el bucle más interior, mientras se mantienen los parámetros de iteración de los bucles externos en sus valores mínimos.
c) Progresas hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mínimos y los demás bucles anidados en sus valores típicos.
d) Continuar hasta que se hayan probado todos los bucles

3) Bucles concatenados: Se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto.
4) Bucles no estructurados: Este tipo de bucles cuando es posible se deben de rediseñar para que se ajusten a las construcciones de programación estructurada.

PRUEBA DE CAJA NEGRA

Pruebas de caja negra: También denominadas pruebas de comportamiento, se centran en los requisitos funcionales del software. Esta prueba permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. Esta prueba no se considera como una alternativa a las técnicas de prueba de caja blanca.

La prueba de caja negra intenta encontrar errores de las siguientes categorías:

a) Funciones incorrectas o ausentes
b) Errores de interfaz
c) Errores en estructuras de datos o en accesos a base de datos externas
d) Errores de rendimiento
e) Errores de inicialización y de terminación

MÉTODOS DE PRUEBA BASADOS EN GRAFOS:

La prueba de caja negra se realiza inicialmente con entender los objetivos que se modelan en el software y las relaciones que conectan a estos objetos. Después se definen una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas.

La prueba del software empieza creando un grafo de objetos importantes y sus relaciones, y después diseñando una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para describir los errores.

Se le llama grafo a una colección de nodos que representan objetos, enlaces que representan lasa relaciones entre los objetos, pesos de nodos que describen las propiedades de un nodo y pesos de enlace que describen alguna característica de un enlace.

Un enlace dirigido.- Se representa por una flecha y es el que indica que una relación se mueve sólo en una dirección.

Un enlace bidireccional.- También se denomina enlace simétrico, indica que la relación se aplica en ambos sentidos.

Partición equivalente.- Es un método de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.

Clase de equivalencia.- Representa un conjunto de estados válidos o no válidos para condiciones de entrada.

Análisis de valores límites (AVL).- Es una técnica de prueba, que se utiliza cuñado los errores tienden a darse más en los límites del campo de entrada. Esta prueba complementa a la partición equivalente; en lugar de seleccionar cualquier elemento de una clase de equivalencia, esta técnica lleva a la elección de casos de prueba en los extremos de la clase.

Prueba de la tabla ortogonal.- Se aplica a problemas en que el dominio de entrada es relativamente pequeño pero demasiado grande para posibilitar pruebas exhaustas. Este método es particularmente útil al encontrar errores asociados con fallos localizados.

Los métodos de prueba de caja negra y de caja blanca son aplicables a todos los entornos, arquitecturas y aplicaciones pero a veces se necesitan unas directrices y enfoques únicos para las pruebas.

viernes, 18 de mayo de 2007

CAPITULO 10: INGENIERIA DE SISTEMAS

Sistemas basados en computadora

Sistema.- Conjunto o disposición de cosas relacionadas de manera que forman una unidad o un todo orgánico. Conjunto de hechos, principios, reglas, clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes.

Sistemas basados en computadora.- Conjunto o disposición de elementos que están organizados para realizar un objetivo predefinido procesando información.

Sistema basado en computadora hace uso de varios elementos del sistema:

Software.- Programas de computadora, estructuras de datos y su documentación.
Hardware.- Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión y dispositivos electromecánicos.
Personas.- Usuarios y operadores del hardware y el software.
Documentación.- Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema.
Procedimientos.- Pasos que definen el empleo especifico te cada elemento del sistema o el contexto procedimental en que reside el sistema.

Los elementos se combinan de diferentes maneras para transformar la información.

Los sistemas complejos son actualmente una jerarquía de macro elementos que son sistemas en si mismos.

El macro elemento es un sistema basado en computadora que es parte de un sistema mas grande basado en computadora.

La Gerarquia de la Ingenieria de Sistemas

El proceso de ingeniería de sistemas empieza normalmente con una visión global. Se examina el dominio entero del negocio o del producto para asegurarse que pueda establecerse un contexto de negocio o tecnológico apropiado. La visión global se refina para enfocarse totalmente en un dominio de interés específico, se analiza la necesidad de elementos del sistema. 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 realizadas por la disciplina de ingeniería correspondiente.

A) Modelado del sistema

La ingeniería de sistemas de computadora es un proceso de modelado. Un ingeniero crea modelos que:

Definan los procesos de la visión del sistema.
Representan el comportamiento de los procesos y supuestos en que se basa el comportamiento
Definan explícitamente las entradas exogenas y endogenas de información al modelo.
Representen todas las uniones que permitan conocer la visión.

Los buenos sistemas de ingeniería comienzan por clarificar el comportamiento del contexto (visión global) y progresivamente se van estrechando hasta el nivel de detalle necesario.

Para construir un modelo del sistema se deben de considerar las siguientes restricciones:

Supuestos que reducen el numero de permutaciones y variaciones posibles para reflejar el problema.
Simplificaciones que permiten crear el modelo a tiempo
Limitaciones que ayudan a delimitar el sistema
Restricciones que guían la manera de crear el modelo y el enfoque que se toma al implementar el modelo.
Preferencias que indican la arquitectura preferida para todos los datos, funciones y tecnología

B) Simulación del Sistema

Muchos sistemas basados en computadora interaccionan con el mundo real en forma reactiva. Los acontecimientos del mundo real son vigilados por el hardware y software que componen el sistema y basándose en esos sucesos, el sistema aplica su control sobre maquinas, procesos incluso las personas que motivan los acontecimientos.

Ingenieria de proceso de negocio: una vision general

El objetivo de la ingeniería de proceso de negocio (IPN) es definir arquitecturas que permitan a las empresas emplear la información eficazmente. La ingeniería de proceso de negocio es un acercamiento para crear un plan general para implementar la arquitectura de computación.

Se deben de analizar y diseñar tres arquitecturas diferentes dentro del contexto de objetivos y metas del 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 una función de negocio.

Un objeto de datos contiene un conjunto de atributos que definen aspectos, cualidades, o características o descriptor de los datos que han sido escritos.

Una relación indica como los objetos están conectados.

La Arquitectura de Aplicación comprende aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algún propósito del negocio.

La Infraestructura Tecnológica proporciona el fundamento de las arquitecturas de datos y aplicaciones y comprende el hardware y software empleados para dar soporte a las aplicaciones y datos.

Planificación de la Estrategia de Información (PEI) ve todo el negocio como una entidad y aísla los dominios del negocio importantes para la totalidad de la empresa. Define los objetos de datos visibles a nivel empresa, sus relaciones y como fluyen entre los dominios del negocio.

Análisis Áreas del Negocio (AAN) actividad que identifica en detalle la información y los requisitos de las funciones identificadas durante la PEI. Se obtiene como resultado el aislar las áreas de oportunidad en la que los sistemas información pueden prestar soporte al área de negocio.

Diseño de Sistema de Negocio (DSN) modela los requisitos básicos de un sistema de información especifico y estos requisitos se traducen en arquitectura de datos, arquitectura de aplicación e infraestructura tecnológica.

Construcción e Integración(C&I) se centra en los detalles de la implementación.

La arquitectura e infraestructura se implementan construyendo una base de datos apropiada y estructuras internas de datos, mediante la construcción de aplicaciones constituidas por programas y seleccionando los elementos apropiados de una infraestructura tecnológica para dar soporte al diseño creado durante la DSN.

La actividad de integración también coloca al nuevo sistema de información en el contexto del área de negocio, realizando todo el entrenamiento del usuario y soporte logístico para conseguir una suave transición.

Ingenieria de Producto: una vision general

La meta de la ingeniería de producto es traducir el deseo del cliente, de un conjunto de capacidades definidas a un producto operativo. Para conseguir esta meta se debe crear una arquitectura una infraestructura.

La arquitectura comprende cuatro componentes de sistemas distintos: software, hardware, datos y personas. Se establece una infraestructura de soporte e incluye la tecnología requerida para unir los componentes y la información que se emplea para dar soporte a los componentes.

La visión global se consigue a través de la ingeniería de requisitos, los requisitos se obtienen de los clientes, estos requisitos comprenden necesidades de información y control, funcionalidad del producto y comportamiento, rendimiento general del producto, diseño, restricciones de la interfaz y otras necesidades especiales.

Ingeniería de componentes del sistema conjunto de actividades concurrentes que se dirigen separadamente a cada uno de los componentes del sistema: ingeniería del Software, ingeniería de Hardware, ingeniería Humana e ingeniería de Bases de Datos.

Ingenieria de Requisitos

La ingeniería de Requisitos se describe en 5 pasos.

Identificación de requisitos, investigar como los sistemas o productos se ajustan alas necesidades del negocio y como se va a utilizar cada día. Se encuentran ciertos problemas durante este paso:
a) Problemas de Alcance
b) Problemas de Comprensión
c) Problemas de Volatilidad

Análisis y negociación 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 las necesidades de los usuarios/clientes.

Especificación de Requisitos

Especificación.- Documento escrito, modelo grafico, modelo matemático formal, colección de escenarios de uso, prototipos o combinación de todo lo anterior.

Especificación del sistema.- es el producto final sobre los requisitos del sistema obtenido por el ingeniero y sirve de fundamento para las demás ingenierías. Describe la función y características del sistema de computación y las restricciones que gobiernan su desarrollo así mismo describe la información que entra y sale del sistema.

Modelado del Sistema

Validación de Requisitos, examina la especificación para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencia, sin omisiones, que los errores detectados ya han sido corregidos y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, proyecto y producto.

Gestión de Requisitos, conjunto de actividades que ayudan al equipó de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.

Una vez que los requisitos han sido identificados se desarrollaran un conjunto de matrices para su seguimiento.

a) Matriz de seguimiento de características, muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto.
b) Matriz de seguimiento de orígenes, identifica el origen de cada requisito.
c) Matriz de seguimiento de dependencias, indica como se relacionan los requisitos entre si.
d) Matriz de seguimiento de subsistemas, vincula los requisitos a los subsistemas que manejan.
e) Matriz de seguimiento de interfaces, muestra como los requisitos están vinculados a las interfaces externas o internas del sistema.



Modelado del Sistema

Todos los sistemas basados en computadora pueden modelarse como una transformación de la información empleando una arquitectura del tipo entrada-proceso-salida-tratamiento de la interfaz de usuario-tratamiento del mantenimiento y autocomprobación.

Esquema del modelado del sistema.- permite crear al analista crear una jerarquía detalle.

Diagrama de contexto del sistema.- Establece el limite de la información entre el sistema que se esta implantando y el entorno en el que va a operar.

jueves, 8 de marzo de 2007

Modelos Evolutivos

Se adaptan más fácilmente a los cambios introducidos a lo largo del desarrollo.

Iterativos

En cada iteración se obtienen versiones más completas del SW.

Modelos Evolutivos:
–Modelo Incremental
–Modelo en Espiral
–Modelo de Desarrollo Basado en Componentes
–Modelo WINWIN
–Modelo de Desarrollo Concurrente


Modelo Incremental

Iteración de Lineal Secuencial.
Cada iteración devuelve un “Incremento” o versión operativa.
Útil cuando no se está seguro de cumplir con plazos de tiempo o se tiene una fecha imposible de cambiar.


Desarrollo Basado en Componentes

Basado en modelo en Espiral (evolutivo e iterativo) + Tecnologías de Objetos.
Enfatiza la Reusabilidad.


Modelo de Métodos Formales

Usan notación rigurosa.
Especificaciones sin ambigüedades.
Utiles para sistemas críticos.
Demostraciones formales de propiedades.
Dificulta validación con cliente => combinación con otras técnicas semi-formales.
Buen nivel de manejo de Lógica y Algebra.


Técnicas de Cuarta Generación (T4G)

Herramientas que facilitan la realización de especificaciones a alto nivel -> código fuente.
Basadas en Lenguajes de 4ta Generación (L4G).
Ventajas: Reducción en tiempo de desarrollo.

Modelo de Desarrollo Rápido de Aplicaciones (DRA)



•Lineal secuencial con ciclo extremadamente corto.


•Candidatos: sistemas que se pueden modularizar => equipos de desarrollo paralelos.


•Basado en el uso de componentes y T4G

Niveles de Madurez del Proceso

Nivel 1: Inicial
Nivel 2: Repetible
Nivel 3: Definido
Nivel 4: Gestionado
Nivel 5: Optimizado

Modelo Construccion de Prototipos