Embed Size (px)
Citation preview
INSTITUTO TECNOLÓGICO
SUPERIOR DE TEPEACA
INGENIERIA EN SISTEMAS COMPUTACIONALES
DESARROLLO DE PROYECTOS DE
SOFTWARE
ALUMNA:
FUENTES SALOME ROSALBA LIZBETH
ING. INES LEON FLORES
25 ABRIL 2012
"Creatividad tecnológica y calidad educativa, pilares para la excelencia humana”
INDICE
UNIDAD 1 CONCEPTOS INTRODUCTORIOS...................................................................41.1 LA ARQUITECTURA DE 4+1 VISTAS.........................................................................4 1.1.1 La vista lógica..........................................................................................................5
1.1.2 La vista de procesos................................................................................................6 1.1.3 Vista de Desarrollo...................................................................................................7 1.1.4 Arquitectura Física...................................................................................................81.2 DESARROLLO ORIENTADO A OBJETOS..................................................................91.2.2 Ejemplos de objetos................................................................................................111.3 DIAGRAMACIÓN.........................................................................................................11
UNIDAD 2 DISEÑO ORIENTADO A OBJETOS................................................................142.1 DISEÑO DEL SISTEMA EN BASE A PROCESOS.....................................................142.1.1 Actividades y casos de uso....................................................................................142.1.2 Interfaces de usuario...............................................................................................162.2 DISEÑO DE LA LÓGICA..............................................................................................17 2.2.1 Clases y Objetos....................................................................................................17 2.2.1 Representación visual de un objeto....................................................................18 2.2.2 Definición de la clase “bicicleta”.........................................................................18 2.2.2 Interacción..............................................................................................................19 2.2.3 Estados y transiciones..........................................................................................19
UNIDAD 3 CONSTRUCCIÓN...........................................................................................203.1 DESPLIEGUE DE COMPONENTES Y ARQUITECTÓNICO......................................203.2 TÉCNICAS DE DESARROLLO DE LAS ARQUITECTURAS DE REFERENCIA EN
DIFERENTES DOMINIOS...............................................................................................21 3.2.1 Diagrama de componentes...................................................................................22 3.2.1 Modelos de componentes.....................................................................................21 3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de
alimentación...................................................................................................................23 3.2.3 Arquitectura de Referencia para Sistemas Móviles con Conexión a Internet..............23 3.2.4 Arquitectura de referencia para sistemas de información................................24 3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje...............25 3.2.6 Arquitectura de referencia para líneas de productos.........................................26
UNIDAD 4 PRUEBAS DE SOFTWARE.............................................................................284.1 DEFINICIONES.............................................................................................................284.1.1.- Pruebas, Caso de Prueba de Defecto, Falla , Error, Verificación y Validación.
.........................................................................................................................................28 4.1.2 Relación entre defecto-falla y error......................................................................29 4.1.3 Pruebas estructurales, funcionales y aleatorias................................................30 4.1.4 Documentación del diseño de las pruebas.........................................................324.2 PROCESO DE PRUEBAS............................................................................................34 4.2.1 Generar un plan de pruebas.................................................................................35 4.2.1 Proceso de pruebas...............................................................................................35 4.2.2 Diseñar pruebas específicas................................................................................37 4.2.3 Tomar Configuración del Software a Probar.......................................................39 4.2.4 Configurar las Pruebas.........................................................................................40 4.2.5 Evaluar resultados.................................................................................................41 4.2.5.1 Depuración.......................................................................................................41 4.2.5.2 Análisis de errores...........................................................................................434.3 TECNICAS DE DISEÑO DE CASOS DE PRUEBAS..................................................45
2
4.4 ENFOQUE PRACTICO RECOMENDADO PARA EL DISEÑO DE CASOS...............464.5 ESTRATEGIAS DE APLICACIÓN DE APLICACIÓN DE LAS PRUEBAS.................47 4.5.1 De unidad................................................................................................................47 4.5.3 DE SISTEMA...........................................................................................................48 4.5.4 PRUEBA DE ACEPTACIÓN...................................................................................49
UNIDAD 5 IMPLANTACION E IMPLEMENTACION.........................................................495.1 Implantación e integración de casos de uso y componentes de software...........495.2 Mantenimiento del software.......................................................................................50
GLOSARIO.........................................................................................................................52FUENTES DE INFORMACIÓN...........................................................................................54
ÍNDICE DE IMÁGENES
Figura 1.1 “Modelo de 4+1 vistas”..................................................................................................5Figura 1.1.1 Notación para la vista lógica......................................................................................6Figura 1.1.2 Notación para el diagrama de procesos....................................................................7Figura 1.1.3 Diagrama parcial de procesos....................................................................................8Figura 1.1.4 Notación para el diagrama de desarrollo..................................................................9Figura 1.1.5 Notación para el diagrama físico.........................................................................9, 10Figura 1.2.1 Notación para clases a distintos niveles de detalle...............................................11Figura 1.3.1 Formato...................................................................................................................... 13Figura 1.3.2 Márgenes.................................................................................................................... 13Figura 1.3.3 Caja............................................................................................................................. 13
Figura 2.1.1 Casos de uso.............................................................................................................15Figura 2.1.2 Ventajas de casos de uso.........................................................................................16Figura 2.2.3 Transiciones..............................................................................................................20
Figura 3.1.1 Representación gráfica.............................................................................................20Figura 3.1.2 Relación de componentes........................................................................................21Figura 3.1.3 Direcciones................................................................................................................21Figura 3.2.5.1 Modelo básico de una línea de productos de software.......................................27
Figura 4.1.2 Relacion entre error defecto y falla..........................................................................30Figura 4.1.3.1 Caja blaca................................................................................................................30Figura 4.1.3.1 Caja negra...............................................................................................................31Figura 4.2 pruebas de aceptacion.................................................................................................49Figura 4.2.5.1 Corrige el error de la manera más obvia..............................................................43Figura 4.3.1 Clases de prueba.......................................................................................................46
UNIDAD 1 CONCEPTOS INTRODUCTORIOS
3
1.1 LA ARQUITECTURA DE 4+1 VISTAS
La arquitectura del software se trata de abstracciones, de descomposición y composición,
de estilos y estética.
También tiene relación con el diseño y la implementación de la estructura de alto nivel del software.
Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos
apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y
performance del sistema, así como también otros requisitos no funcionales tales como
confiabilidad, escalabilidad, portabilidad y disponibilidad del sistema. A continuación en la figura 1.1
se presentan las 4 + 1 vistas que se usan para el diseño y la implementación de la estructura de
alto nivel de software
Figura 1.1 “Modelo de 4+1 vistas”
1.1.1 La vista lógica
4
Es aquella que trata de clases y subsistemas, tiene las siguientes particularidades: soporta los
requerimientos funcionales (estos son asignados por el usuario final), identifica mecanismos y
diseña elementos comunes atraves del sistema; utiliza los diagramas de clases y la notación de
Booch; además de utilizar el estilo arquitectónico orientado a objetos
Notación: La notación para la vista lógica se deriva de la notación de Booch. Esta se simplifica
considerablemente de tal modo de tener en cuenta solamente los items relevantes para la
arquitectura. En particular, los numerosos adornos disponibles son bastante inútiles a este nivel de
diseño. Usamos Rational Rose para apoyar el diseño lógico de la arquitectura. (Ver figura 1.2)
Figura 1.2 Notación para la vista lógica.
1.1.2 La vista de procesos
5
La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la
performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribución, integridad del
sistema, de tolerancia a fallas. La vista de procesos también especifica en cual hilo de control se
ejecuta efectivamente una operación de una clase identificada en la vista lógica.
La arquitectura de procesos se describe en varios niveles de abstracción, donde cada nivel se
refiere a distintos intereses. El nivel más alto la arquitectura de procesos puede verse como un
conjunto de redes lógicas de programas comunicantes (llamados “procesos”) ejecutándose en
forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados
mediante un bus, una LAN o WAN. Múltiples redes lógicas pueden usarse para apoyar la
separación de la operación del sistema en línea del sistema fuera de línea, así como también para
apoyar la coexistencia de versiones de software de simulación o de prueba.
Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos
representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente
(comenzar, recuperar, reconfigurar, y detener). Además, los procesos pueden replicarse para
aumentar la distribución de la carga de procesamiento, o para mejorar la disponibilidad.
Notación: La notación que usamos para la vista de procesos se expande de la notación
originalmente propuesta por Booch para las tareas de Ada y se centra solamente en los elementos
arquitectónicamente relevantes. En la Figura 1.3 se muestra la notación para la vista de procesos.
Figura 1.3 Notación para el diagrama de procesos.
1.1.3 Vista de Desarrollo
6
La vista de desarrollo se centra en la organización real de los módulos de software en el ambiente
de desarrollo del software. El software se empaqueta en partes pequeñas: bibliotecas de
programas o subsistemas, que pueden ser desarrollados por uno o un grupo pequeño de
desarrolladores. Los subsistemas se organizan en una jerarquía de capas, cada una de las cuales
brinda una interfaz estrecha y bien definida hacia las capas superiores. (ver figura 1.4)
Figura 1.4 Diagrama parcial de procesos
Notación. Tal como se muestra en la Figura 6, usamos una variante de la notación de Booch
limitándonos a aquellos items relevantes para la arquitectura. (Figura 1.5)
Figura 1.5 Notación para el diagrama de desarrollo.
1.1.4 Arquitectura Física
7
Mapeando el software al hardware
La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema tales
como la disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad.
El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos).
Los variados elementos identificados–redes, procesos, tareas y objetos– requieren ser mapeados
sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para
desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo
tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto
mínimo sobre el código fuente.
Notación: para la arquitectura física. Los diagramas físicos pueden tornarse muy confusos en
grandes sistemas, y por lo tanto toman diversas formas, con o sin el mapeo de la vista de
procesos. La figura 1.6 presenta la notación para el diagrama físico.
Figura 1.6 Notación para el diagrama físico.
1.2 DESARROLLO ORIENTADO A OBJETOS
8
Modelos
Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la
planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde
distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema.
Los modelos de UML que se tratan en esta parte son los siguientes:
· Diagrama de Estructura Estática.
· Diagrama de Casos de Uso.
· Diagrama de Secuencia.
· Diagrama de Colaboración.
· Diagrama de Estados.
Dependencias
La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el
elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento
destino habría que revisar el elemento origen).
Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos
elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el
elemento del que depende es el destino (junto a él está la flecha).
Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra
el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede
representarse de forma esquemática (plegada), con los detalles como atributos y
operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la
Figura 5 se ve cómo una misma clase puede representarse a distinto nivel de detalle según
interese, y según la fase en la que se esté. A continuación se presenta la figura 1.7 Notación para
clases a distintos niveles de detalle.
9
Figura 1.7 Notación para clases a distintos niveles de detalle.
Objetos
Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis:
nombre_del_objeto: nombre_de_la_clase
Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase. Ejemplo de objetos en la figura 1.8
1.8 Ejemplos de objetos
1.3 DIAGRAMACIÓN
10
Consiste en tratar de equilibrar elementos a través de las páginas; organizar las masas de texto,
las ilustraciones, los espacios en blanco, los títulos y las fotografías, procurando encontrar la
armonía de las partes con el todo. Podemos resumirlo esencialmente, en el orden y la dirección
que retoma la vista cuando apreciamos un documento impreso: Si los elementos aparecen ante
nosotros como un verdadero caos gráfico, sencilla-mente se obvia la lectura. Si por el contrario,
faltan elementos que unifiquen la armonía del impreso, nos quedará una vaga idea y poco concisa,
de lo que deseaba comunicar su emisor.
El formato
Es el tamaño o área de la hoja de papel, donde va a ser impreso nuestro diseño. Existen muchos
formatos de acuerdo a la necesidad del usuario como libros, revistas, periódicos, manuales,
afiches, broshures, etc. Por lo general, se denominan también en pulgadas: por ejemplo 8.5" x 11"
si es formato carta que se presenta en la figura 1.9
Figura 1.9 Formato
Los márgenes
Son los espacios circundantes que se respetan entre la caja y el borde de la hoja de papel. Pueden
variarse de acuerdo al diseño, pero siempre respetando la continuidad del impreso. Técnicamente
estos espacios reciben el nombre de: Cabeza, Lomo, Corte y Pie. Como ejemplo la figura 1.10
11
Figura 1.10 Márgenes
La caja
Es el espacio real y limitante, donde se diagrama y se acomodan los elementos de la página. En
Microsoft Publisher, aparece la caja del documento delineada por un cuadro azul dentro de la
página. Ejemplo figura 1.11
Figura 1.11 Caja
Las 7 reglas de la diagramación
La mejor forma de aprender a diagramar, es observando y emulando otros impresos tales como
revistas, diarios, plegables, etc. Pero existen 7 reglas de oro que se deben tomar en cuenta al
diseñar sus documentos:
1. Tenga presente el número de columnas a usar, para que planifique la cantidad de texto.
2. Una vez ubicados los textos, no olvide dejar espacio para los elementos gráficos.
3. NO recargue la página con textos, imágenes y/o blancos. Sea conciso para no distraer del
tema central.
4. Los espacios pequeños en blanco, ayudan a descansar la vista.
5. Cuando diagrame una doble página, deje un espacio prudente en el centro de ambas, para
evitar que las imágenes o el texto queden atrapados en el engrape o pegue del lomo.
6. Se recomienda no utilizar más de 2 o 3 familias tipográficas por documento diagramado.
Unifíquelas por títulos, subtítulos y párrafos.
7. Si trabaja en equipo con un ilustrador, indíquele siempre en sus borradores el espacio y los
detalles de la ilustración que necesita, con tinta roja o marcador destacable.
12
UNIDAD 2 DISEÑO ORIENTADO A OBJETOS
2.1 DISEÑO DEL SISTEMA EN BASE A PROCESOS
El diseño del sistema se representa a través de dos fases:
a) El diseño lógico
b) El diseño físico
Cuando los analistas formulan un diseño lógico escriben las especificaciones detalladas del nuevo
sistema, esto es, describen sus características como son: las salidas, entradas, archivos, bases de
datos y procedimientos; todas de manera que cubran los requerimientos del proyecto.
El diseño lógico de un sistema de información es como el plano de un ingeniero para armar un
automóvil: muestra las características principales (motor, transmisión y área para los pasajeros) y
cómo se relacionan unas características con otras (dónde se conectan entre sí los componentes
del sistema, o por ejemplo, cuán separadas están las puertas.
El diseño físico, actividad que sigue al diseño lógico, produce programas de software, archivos y un
sistema en marcha, las especificaciones del diseño indican a los programadores qué debe hacer el
sistema. Los programadores a su vez escriben los programas que aceptan entradas por parte de
los usuarios, procesan los datos, producen los informes y almacenan estos datos en los archivos.
A demás en el diseño físico se especifican las características de los componentes del sistema
requerido en prácticas del diseño lógico.
En el diseño físico deben delinearse las características de cada uno de los componentes que se enumeran a continuación:
Diseño de hardware
Diseño de software
Diseño de base de datos
2.1.1 Actividades y casos de uso
Los Casos de Uso son requerimientos funcionales que describen de una manera detallada el
comportamiento del sistema con los distintos Actores que interactúan con él. No definen todos los
requerimientos (por ej. los tipos de datos, interfaces externas, niveles de rendimiento esperado,
etc.), pero representan el hilo conductor que vincula a todos los requerimientos posibles (actuales y
futuros) de una aplicación. A continuación se presenta en la figura 2.1 los requerimientos de los
casos de uso.
13
Figura 2.1 Casos de uso
Ventajas:
1. Lenguaje de comunicación entre usuarios y desarrolladores.
2. Comprensión detallada de la funcionalidad del sistema.
3. Acotación precisa de las habilitaciones de los usuarios.
4. Gestión de riesgo más eficiente para gobernar la complejidad.
5. Estimación más exacta para determinar tiempo, recursos y prioridades en la dosificación de
esfuerzo de desarrollo.
6. Fiel trazabilidad para verificar la traducción de requerimientos en código ejecutable.
7. Mayor control para mantener las sucesivas revisiones de los programas.
8. Certificación contractual Cliente-Desarrollador.
9. Documentación orientada al usuario: Helps- Manual de Procedimientos - Reglas de Negocio.
10. Documentación orientada al administrador del sistema: Soporte de Mantenimiento.
14
Ventajas de casos de uso.
Figura 2.2 Ventajas de casos de uso
2.1.2 Interfaces de usuario
Son los dispositivos tecnológicos que transforman una herramienta no humana en una herramienta
convivencial.
Las tendencias son hacia interfaces más potentes considerando:
a) El aumento de la capacidad de los sistemas.
b) El aumento de la complejidad (según la ley de la tecnología, a mayor potencia, mayor
complejidad): surge la necesidad por parte del usuario de contar con algo que se la oculte.
Gracias a las interfaces, los usuarios no necesitan comprender la máquina física. Se crea la ilusión
de que el ordenador es muy sencillo. Este conjunto de mecanismos de dialogo hombre-máquina
que ocultan al usuario la complejidad de la máquina y del sistema ofimático se conoce como
”Ilusión de usuario”. De esta manera se da la paradoja de que los ordenadores, siendo cada vez
más complejos, parecen ser cada vez m´as simples. Es porque el usuario solo ”ve” una
máquina virtual hecha a medida de la complejidad que ´el comprende.
Características de una interfaz
Una interfaz debe cumplir las condiciones:
• Naturalidad. El nuevo sistema automatizado debe tender a ser lo más similar al antiguo.
• Facilidad de aprendizaje y uso, dos aspectos que no siempre van unidos.
• Consistencia. La interfaz debe mantener uniformidad en cuanto a estilo, vocabulario, etc.
15
Naturalidad
Una interfaz es natural, cuando provoca al usuario sentimientos de ”estar como en casa”. Todo
trabajador tiene:
• Una forma de actuar
• Una forma de organizarse
• Un vocabulario propio para las tareas habituales
• Un entorno que ya domina, al que está acostumbrado y del que, tal vez, le sea difícil de
salir.
Facilidad de aprendizaje y uso
Proporcionar al usuario un sistema de ayuda potente. Pero, ¡cuidado! El sistema de ayuda puede
ser un obstáculo una vez que se domine el producto (esta ayuda no debe ser automática). Para
disfrutar de esta característica, la interfaz debe incorporar:
• Administración de perfiles de usuario. Según el grado de perfil, la interfaz ejecutará unas
acciones u otras.
• Mecanismos de realimentación que proporcione al usuario información sobre la ejecución
actual del trabajo.
• Mecanismos de prevención de desastres.
2.2 DISEÑO DE LA LÓGICA
2.2.1 Clases y Objetos
¿QUÉ ES UN OBJETO?
Un objeto no es más que un conjunto de variables (o datos) y métodos (o funciones) relacionados
entre sí. Los objetos en programación se usan para modelar objetos o entidades del mundo real (el
objeto hijo, madre, o farmacéutica, por ejemplo). Un objeto es, por tanto, la representación en un
programa de un concepto, y contiene toda la información necesaria para abstraerlo: datos que
describen sus atributos y operaciones que pueden realizarse sobre los mismos. La siguiente figura
muestra una representación visual de un objeto. En la siguiente imagen (Figura 2.3) se observa
una presentación visual de un objeto
16
2.3 Representación visual de un objeto
¿QUÉ ES UNA CLASE?
Normalmente en el mundo real existen varios objetos de un mismo tipo, o como diremos
enseguida, de una misma clase. Por ejemplo, mi bicicleta es una de las muchas bicicletas que
existen en el mundo. Usando la terminología de la programación orientada a objetos, diremos que
mi bicicleta es una instancia de la clase de objetos conocida como bicicletas. Todas las bicicletas
tienen algunos estados o atributos (color, marcha actual, cadencia actual, dos ruedas) y algunos
métodos (cambiar de marcha, frenar) en común. Sin embargo, el estado particular de cada bicicleta
es independiente del estado de las demás bicicletas. La particularización de estos atributos puede
ser diferente. Es decir, una bicicleta podrá ser azul, y otra roja, pero ambas tienen en común el
hecho de tener una variable “color”. De este modo podemos definir una plantilla de variables y
métodos para todas las bicicletas. Las plantillas para crear objetos son denominadas clases.
Una clase es una plantilla que define las variables y los métodos que son comunes para todos los
objetos de un cierto tipo. (Figura 2.4)
2.4 Definición de la clase “bicicleta”
17
2.2.2 Interacción
En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay
dos tipos de diagrama de interacción, ambos basados en la misma información, pero
cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de
Colaboración.
En un diagrama de secuencia se indicarán los módulos o clases que forman parte del programa y
las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada.
El diagrama de colaboración
Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un
objetivo común.
Consiste especificar un contrato entre objetos
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un
objeto a otro. Dicha implementación es llamada "enlace".
2.2.3 Estados y transiciones.
Estado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre
los eventos.
Transiciones
Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción.
Esta transición se produce como resultado de la finalización del estado del que parte el arco
dirigido que marca la transición. Como todo flujo de control debe empezar y terminar en
algún momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como
queda reflejado en el ejemplo de la Figura 2.5
18
Figura 2.5 Transiciones
UNIDAD 3 CONSTRUCCIÓN
3.1 DESPLIEGUE DE COMPONENTES Y ARQUITECTÓNICO
Se utilizan para modelar los elementos físicos que pueden hallarse en un nodo.
• Ejecutables
• Bibliotecas
• Tablas
• Archivos
• Documentos
Deben definir abstracciones precisas con interfaces bien definidas y que permitan
la reemplazabilidad.
Representación gráfica:
Figura 3.1 Representación gráfica
En muchos sentidos los componentes son como las clases:
o Ambos tienen nombre
o Ambos pueden realizar un conjunto de interfaces
o Ambos pueden participar en relaciones de dependencia, generalización y asociación
o Ambos pueden anidarse
o Ambos pueden participar en interacciones
La relación entre un componente y las clases que representa puede especificarse explícitamente.
19
Figura 3.2 Relación de componentes
Los nodos al igual que los componentes son un elemento fundamental en el modelado físico de un
sistema
Es decir, un procesador o un dispositivo sobre el que se pueden desplegar los componentes
UML proporciona una representación gráfica de un nodo genérico que se puede particularizar
para representar procesadores y dispositivos específicos.
Un diagrama de despliegue muestra:
Los distintos dispositivos y su interconexión
La asignación de componentes (procesos, ficheros,...) a dispositivos
Debe existir un sólo diagrama de despliegue por modelo.
Con direcciones: in, out, inout
Figura 3.3 Direcciones
3.2 TÉCNICAS DE DESARROLLO DE LAS ARQUITECTURAS DE
REFERENCIA EN DIFERENTES DOMINIOS.
3.2.1 Modelos de componentes
El modelo de componentes ilustra los componentes de software que se usarán para construir el
sistema. Se pueden construir a partir del modelo de clases y escribir desde cero para el
nuevo sistema o se pueden importar de otros proyectos y de productos de terceros. Los
20
componentes son agregaciones de alto nivel de las piezas de software más pequeñas y
proveen un enfoque de construcción de bloques de “caja negra” para la elaboración de
software.
El Diagrama de Componentes
El diagrama de componentes muestra la relación entre componentes de software, sus
dependencias, su comunicación su ubicación y otras condiciones.
3.4 Diagrama de componentes
Los Componentes de Servidor
Estos componentes son una mezcla de los ítems construidos a medida y adquiridos que se
ensamblarán para proveer la funcionalidad requerida.
Los Componentes de Seguridad
El diagrama de componentes de la seguridad muestra cómo trabaja en conjunto el software de
seguridad, tal como la Autoridad Certificadora (Certificate Authority), el navegador (Browser),
el servidor WEB y otros elementos del modelo para asegurar la provisión de la seguridad en el
sistema propuesto.
21
3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de
alimentación
TAREAS
Los Sistemas de Tiempo Real (STR) ejecutan actividades o tareas en un intervalo de tiempo
predeterminado.
Tienen varios tipos de propiedades:
Funcionales: qué hacen.
Temporales: cuándo lo hacen.
El comportamiento temporal de las tareas se especifica mediante sus atributos temporales:
Cuándo se ejecutan: esquema de activación.
Qué plazo tienen para ejecutar cada acción.
El diseño de arquitecturas de tiempo real involucra 2 aspectos:
Nivel de Nodo Cada procesador debe proveer velocidad y predecibilidad en la ejecución
de tareas de tiempo real, manejo de interrupciones e interacción con el mundo externo.
Nivel de Sistema En este nivel las comunicaciones y la tolerancia a fallos son 2 aspectos
que hacen difícil la predecibilidad. De cualquier manera, estos aspectos son inevitables.
ELEMENTOS QUE COMPONEN UN STR
Aspectos de integración y de rendimiento.
Manejo de Interrupciones.
Bases de Datos de Tiempo Real.
Sistemas Operativos de Tiempo Real.
Lenguajes de Tiempo Real.
Sincronización y comunicación de tareas.
3.2.3 Arquitectura de Referencia para Sistemas Móviles con Conexión a
Internet
El concepto de Internet Móvil, o conexión móvil a Internet, surge apartir de la
evolución de los sistemas de telefonía móvil hacia la prestación de nuevos
servicios de datos. Dada la importancia de Internet como eje central sobre el que se desarrolla la
Sociedad de la Información, el éxito de los sistemas móviles de 2G y la llegada de la banda ancha
al mundo móvil con gracias a las redes de 3G y sucesivas,
22
Internet móvil es fruto de la convergencia del mundo Internet y la movilidad.
Convergencia Internet-móvil
El crecimiento espectacular de ambas tecnologías ha impulsado la convergencia entre Internet y
las comunicaciones móviles:
La tecnología WAP permite el desarrollo de contenidos y servicios en Internet con acceso desde
todo tipo de terminales móviles. GPRS/EDGE garantiza una transición suave y con garantías de la
segunda (GSM) a la tercera generación (UMTS) de comunicaciones móviles y permite acceso a
Internet con velocidades de hasta 170/384 Kbps. UMTS suponela fusión de las telecomunicaciones
móviles e Internet, proporcionando acceso ilimitado a contenidos y servicios multimedia con
velocidades de hasta 2 Mbps. HSDPA/HSUPA ofrecen altas prestaciones de voz y datos y
permitirán la creación de un gran mercado de IP multimedia móvil
Evolución de los sistemas móviles
Sistemas móviles de primera generación (1G)
Sistemas móviles de segunda generación (2G)
Sistemas móviles de generación 2,5 ( 2.5G)
Sistemas móviles de tercera generación (3G)
3.2.4 Arquitectura de referencia para sistemas de información
La decisión de abordar un estudio en profundidad para definir la Arquitectura de los Sistemas de
Información, parte de la necesidad de conseguir unos objetivos de carácter general, que pueden
resumirse en los siguientes puntos:
Alineamiento de la óptica de negocio con la estructura de los Sistemas de Información.
Disponer de un modelo integral que abarque todas las aplicaciones y sistemas
informáticos.
Determinar la estrategia general de los futuros desarrollos.
Adecuar los sistemas actuales,
Definir un horizonte hacia el que evolucionar a corto, medio y largo plazo.
Potenciar la eficacia de los Sistemas Informáticos
Posibilitar la incorporación de las tecnologías emergentes de forma eficaz.
Favorecer la mejora de la calidad profesional y de la gestión interna.
Reducir los costes y el plazo de disponibilidad de las aplicaciones.
Al término del estudio se dispondrá de los siguientes resultados:
23
Identificación de los Requerimientos Estratégicos de negocio, desde la óptica de los
Sistemas de Información.
Modelos estructurados y documentados sobre las Arquitecturas:
Funcional
Datos
Sistemas
Áreas complementarias seleccionadas
Identificación de los diferentes Sistemas de Información utilizados,
Reglas de diseño para implantar nuevas tendencias tecnológicas.
Reglas de diseño para la estructuración de las aplicaciones.
Las fronteras de cada uno de los Subsistemas en que se divide el Sistema (interfaces).
Un equipo formado y conocedor de los modelos diseñados para enfocar la implantación de
la Arquitectura.
Un soporte informático conteniendo los modelos, cara al enlace con el desarrollo de los
proyectos.
Un diseño previo, no detallado, de cada Sistema,
Modelo organizativo para la función de Administración de la Arquitectura
Un Plan Director, especificando la estrategia recomendada para la evolución de los
Sistemas.
3.2.5 Arquitectura de referencia para ambientes virtuales de
aprendizaje.
Un Ambiente Virtual de Aprendizaje es el conjunto de entornos de interacción, sincrónica y
asincrónica, donde, con base en un programa curricular, se lleva a cabo el proceso enseñanza
aprendizaje, a través de un sistema de administración de aprendizaje.
La propuesta metodológica para operar los modelos educativos innovadores es la de Ambientes
Virtuales de Aprendizaje (AVA), ya que crear un ambiente de este tipo no es trasladar la docencia
de un aula física a una virtual, ni cambiar el gis y el pizarrón por un medio electrónico, o concentrar
el contenido de una asignatura, en un texto que se lee en el monitor de la computadora.
Se requiere que quienes participan en el diseño de estos ambientes deben conocer todos los
recursos tecnológicos disponibles (infraestructura, medios, recursos de información, etc.), así como
las ventajas y limitaciones de éstos para poder relacionar los con los objetivos, los contenidos, las
estrategias y actividades de aprendizaje y la evaluación.
24
Los entornos en los cuales opera un AVA son:
Conocimiento Colaboración Asesoría
Experimentación Gestión
Elementos de un ambiente virtual de aprendizaje
Usuarios
. Se refiere a QUIÉN va a aprender, a desarrollar competencias, a generar habilidades, es decir
principalmente estudiantes y facilitadores.
Currícula
. Es el QUÉ se va a aprender. Son los contenidos, el sustento, los programas de estudio
curriculares y cursos de formación.
Especialistas
. Aquí está el CÓMO se va a aprender. Son los encargados de diseñar, desarrollar y materializar
todos los contenidos educativos que se utilizarán en el AVA. Se integra por un grupo
multidisciplinario que consta de:
Pedagogo.
Administrador
Diseñador grafico.
Programador.
Especialista en tecnología educativa.
Corrector de estilo.
Fases de creación de un ambiente virtual de aprendizaje.
Fase I. Planeación.
Fase II. Diseño, desarrollo de los entornos y la producción de los contenidos digitales.‡
Fase III. Operación.
3.2.6 Arquitectura de referencia para líneas de productos.
Definiciones de Líneas de Productos de Software
Consiste de una familia de sistemas de software que tienen una funcionalidad común y alguna
funcionalidad variable.
La funcionalidad común descansa en el uso recurrente de un conjunto común de activos
reutilizables (requisitos, diseños, componentes, servicios web, etc.).
Los activos son reutilizados por todos los miembros de la familia.
25
Figura 3.2.5.1 Modelo básico de una línea de productos de software
La entrada: Activos de Software
. Una colección de partes de software (requisitos, diseños, componentes, casos de prueba, etc.)
que se configuran y componen de una manera prescrita para producir los productos de la línea.
El control:
Modelos de Decisión y Decisiones de Productos
. Los Modelos de Decisiones describen los aspectos variables y opcionales de los productos de la
línea. Cada producto de la línea es definido por un conjunto de decisiones (decisiones del
producto).
El proceso de producción
. Establece los mecanismos o pasos para componer y configurar productos a partir de los activos
de entrada. Las decisiones del producto se usan para determinar que activos de entrada utilizar y
como configurar los puntos de variación de esos activos.
La salida: Productos de software
. Conjunto de todos los productos que pueden o son producidos por la línea de Productos.
Líneas de productos de software
La entrega de productos de software busca una manera:
Más rápida.
Económica.
Con una mejor calidad.
‡
Las líneas de producción producen mejoras en:
Tiempo de entrega del producto (time to market).
Costos de ingeniería.
Tamaño del portafolio de productos.
Reducción de las tasas de defectos.
Calidad de los productos.
26
El objetivo principal de una LPS es:
Reducir el tiempo, esfuerzo, costo y complejidad de crear y mantener los productos de la línea mediante:
La capitalización de los aspectos comunes de la línea de Productos, a través de la consolidación y
reutilización de los activos de entrada a la línea.
El manejo de los aspectos variables de los productos de la línea a través de los puntos de variación
de los activos y los modelos de decisión
UNIDAD 4 PRUEBAS DE SOFTWARE
4.1 DEFINICIONES
4.1.1.- Pruebas, Caso de Prueba de Defecto, Falla , Error, Verificación y
Validación.
Pruebas (test):
Es una actividad en la cual un sistema o uno de sus componentes se ejecutan para verificar el
funcionamiento de un proceso, los resultados se observan y registran para realizar una evolución
de dicho proceso.
Referente a la programación una prueba de software, en inglés testing son los procesos que
permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar
posibles fallos de implementación.
Caso de prueba (test case):
Un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un
objetivo particular, un caso de prueba es utilizado por el analista para determinar si el requisito de
una aplicación es parcial o completamente satisfactorio.
Defecto (defect, fault, bug):
Un defecto de software, es el resultado de un fallo o deficiencia durante el proceso de creación de
programas de ordenador o computadora u otro dispositivo. Por ejemplo, un proceso, una definición
de datos o un paso de procesamiento incorrectos en un programa.
Error (error):
Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de
tipeo, una malinterpretación de un requerimiento o de la funcionalidad de un método, una acción
humana que conduce a un resultado incorrecto. Por ejemplo: Divisiones entre cero. Es una tipo de
manifestación del defecto en el sistema que se ejecuta.
27
Falla (failure):
Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más
evidentes se dan en la etapa de desarrollo y programación. Es la incapacidad de un sistema o de
alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de
rendimiento especificados.
Verificación:
La verificación del software es el proceso a través del cual se analiza y revisa que el software
satisfaga los objetivos propuestos al inicio del desarrollo.
Validación:
El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del
proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.
4.1.2 Relación entre defecto-falla y error.
Figura 4.1 Relación entre error defecto y falla
Un error puede conducir a uno o más defectos. Un defecto se encuentra en un artefacto y puede
definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. Un
defecto es haber utilizado el operador “<” en vez de “<=“. En este caso una falla es la discrepancia
visible que se produce al ejecutar un programa con un defecto, respecto a la ejecución del
programa correcto. Es decir, una falla es el síntoma de un defecto. Por ejemplo: una consulta que
no arroje ningún resultado.
28
4.1.3 Pruebas estructurales, funcionales y aleatorias.
El objetivo de las pruebas es la detección de defectos en el software (descubrir un error es el éxito
de una prueba)
Existen tres enfoques principales para el diseño de casos o pruebas
A. El enfoque estructural o de caja blanca.
Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones
internas de un módulo. Las pruebas de caja blanca están dirigidas a las funciones internas. Entre
las técnicas usadas se encuentran:
· La cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos
de ejecución).
· Pruebas sobre las expresiones lógico-aritméticas.
· Pruebas de camino de datos (definición-uso de variables).
· Comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las
iteraciones máximas, máximas menos uno y más uno).
Figura 4.2 Caja blaca
B. El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas.
Se centra en las funciones, entradas y salidas. Intenta encontrar errores de las siguientes
categorías:
· Funciones Incorrecta o ausente.
· Errores de Interfaz.
· Errores en estructuras de datos o acceso a base de datos externas.
· Errores de rendimiento.
· Errores de inicialización y de terminación
29
Figura 4.3 Caja negra
C. PRUEBAS ALEATORIAS
En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en
la secuencia y con la frecuencia con las que podrían aparecer en la Práctica (de manera repetitiva).
Para ello habitualmente se utilizan generadores automáticos de casos de prueba.
Consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles
entradas al programa para crear a partir de ellos los casos de prueba
CRITERIOS DE COBERTURA LÓGICA
Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada
sentencia o instrucción del programa se ejecute al menos una vez.
Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisión tenga, por
lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura
de sentencias)
Cobertura de condiciones. Se trata de diseñar tantos casos como sea necesario para que cada
condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una
vez. (No incluye cobertura de condiciones)
Criterio de decisión/condición. Consiste en exigir el criterio de cobertura de condiciones obligando a
que se cumpla también el criterio de decisiones.
Criterio de condición múltiple. En el caso de que se considere que la evaluación de las condiciones
de cada decisión no se realiza de forma simultánea, se puede considerar que cada decisión
multicondicional se descompone en varias condiciones unicondicionales. Ejemplo en la siguiente
diapositiva. Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable).
30
4.1.4 Documentación del diseño de las pruebas.
Se compone de los siguientes pasos:
Plan De Pruebas
Señala el enfoque, los recursos y el esquema de actividades de prueba, así como los
elementos a probar, las características, las actividades de prueba, el personal responsable
y los riesgos asociados.
Especificación Del Diseño De Pruebas
Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e
identificar las características que se deben probar con este diseño de pruebas.
Especificación De Caso De Prueba
Define uno de los casos de prueba identificando por una especificación del diseño de las
pruebas.
Especificación De Procedimiento De Prueba
Especificar los pasos para la ejecución de un conjunto de casos de prueba o, más
generalmente, los pasos utilizados para analizar un elemento software con el propósito de
evaluar un conjunto de características del mismo.
Estructura de los pasos fijada en el estándar
Plan de Pruebas
1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
31
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
Especificación del diseño de pruebas
· Identificador único para la especificación. Proporcionar también una referencia del plan
asociado (si existe)
· Características a probar de los elementos software (y combinaciones de características)
· Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de
prueba específica y los métodos de análisis de resultados
Especificación de caso de prueba
· Elementos software (por ejemplo, módulos) que se van a probar: definir dichos elementos y
las características que ejercitará este caso
· Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las
relaciones entre las diversas entradas; por ejemplo, la sincronización de las mismas)
· Especificaciones de todas las salidas y las características requeridas (por ejemplo, el
tiempo respuesta) para los elementos que se van a probar
· Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal)
Especificación De Procedimiento De Prueba
Identificador único de la especificación y referencia a la correspondiente especificación de
diseño de prueba
· Objetivo del procedimiento y lista de casos que se ejecutan con él
· Requisitos especiales para la ejecución (por ejemplo, entorno especial o personal especial)
· Pasos en el procedimiento. Además de la manera de registrar los resultados y los
incidentes de la ejecución, se debe especificar:
· La secuencia necesaria de acciones para preparar la ejecución
· Acciones necesarias para empezar la ejecución
· Acciones necesarias durante la ejecución
· Cómo se realizarán las medidas ( por ejemplo, el tiempo de respuesta)
· Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo
obliguen)
· Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en estos puntos
· Acciones necesarias para detener ordenadamente la ejecución
32
· Acciones necesarias para restaurar el entorno y dejarlo en la situación existente antes de
las pruebas
· Acciones necesarias para tratar los acontecimientos anómalos.
4.4 Especificación
4.2 PROCESO DE PRUEBAS
33
4.2.1 Proceso de pruebas
4.2.1 Generar un plan de pruebas
El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario,
responsables y manejo de riesgos de un proceso de pruebas.
Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos tipos de
pruebas (verificación, integración e integración).
Un plan de pruebas incluye:
1. Identificador del plan.
Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance, por ej. TP-
Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de verificación del
requerimiento 1 de seguridad), TP-Contr-X (plan de verificación del contrato asociado al evento de
sistema X), TP-Unit-Despachador.iniciar (plan de prueba unitario para el método iniciar de la clase
Despachador). Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo
que debe distinguirse adicionalmente la versión y fecha del plan.
2. Alcance
Indica el tipo de prueba y las propiedades/elementos del software a ser probado.
3. Items a probar
Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a
aplicarle el plan. Por un lado, es difícil y riesgoso probar una configuración que aún reporta fallas;
por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas
graves demasiado tarde.
4. Estrategia
Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba. Por
ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se
aplicará la estrategia caja-negra de fronteras de la precondición" o "Ejercicio de los caminos
ciclomáticos válidos". En lo posible la estrategia debe precisar el número mínimo de casos de
prueba a diseñar, por ej. 100% de las fronteras, 60% de los caminos ciclomáticos... La estrategia
también explicita el grado de automatización que se exigirá, tanto para la generación de casos de
prueba como para su ejecución.
5. Categorización de la configuración
Explicita las condiciones bajo las cuales, el plan debe ser:
34
o Suspendido,
o Repetido;
o Culminado.
En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe
suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el
proceso de prueba previsto por el plan puede continuar, pero debe explicitarse a partir de qué
punto, ya que puede ser necesario repetir algunas pruebas. Los criterios de culminación pueden
ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejos
como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas
y la tasa de detección de fallas.
6. Tangibles
Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes,
especificación de pruebas, casos de prueba, resumen gerencial del proceso y bitácora de pruebas.
7. Procedimientos especiales
Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier
habilidad especial que se requiere.
8. Recursos
Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las
características del hardware, el software de sistemas (p. ej. el sistema de operación), cualquier otro
software necesario para llevar a cabo las pruebas, así como la colocación específica del software a
probar (p. ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del
software de apoyo.
La sección incluye un estimado de los recursos humanos necesarios para el proceso. También se
indican cualquier requerimiento especial del proceso: actualización de licencias, espacio de oficina,
tiempo en la máquina de producción, seguridad.
9. Calendario
Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de
las tareas a realizar.
10. Manejo de riesgos
Explicita los riesgos del plan, las acciones mitigantes y de contigencia.
11. Responsables
Especifica quién es el responsable de cada una de las tareas previstas en el plan.
35
El diseño de casos de prueba está
4.2.2 Diseñar pruebas específicas.
El diseño de caos de prueba está totalmente mediatizado por la imposibilidad de probar
exhaustivamente el software. Pensemos en un programa muy sencillo que sólo suma dos números
enteros de dos cifras (del 0 al 99). Si quisiéramos probar, simplemente, todos los valores válidos
que se pueden sumar, deberíamos probar 10.000 combinaciones distintas de cien posibles
números del primer sumando y cien del segundo. Pensemos que aún quedarían por probar todas
las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un
número). La conclusión es que, si para un programa tan elemental debemos realizar tantas
pruebas, pensemos en lo que supondría un programa medio.
En consecuencia, las técnicas de diseño de casos de prueba tienen como objetivo conseguir una
confianza aceptable en que se detectarán los defectos existentes (ya que la seguridad total sólo
puede obtenerse de la prueba exhaustiva, que no es practicable) sin necesidad de consumir una
cantidad excesiva de recursos (por ejemplo, tiempo para probar o tiempo de ejecución). Toda la
disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de
recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este equilibrio
no es sencillo, lo que convierte a las pruebas en una disciplina difícil que está lejos de parecerse a
la imagen de actividad rutinaria que suele sugerir.
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea
fundamental para el diseño de casos de prueba consiste en elegir algunas de ellas que, por sus
características, se consideren representativas del resto. Así, se asume que, si no se detectan
defectos en el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que
depende de la elección de los casos) en que el programa no tiene defectos. La dificultad de esta
idea es saber elegir los casos que se deben ejecutar. De hecho, una elección puramente aleatoria
no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. Por
ejemplo, en el caso del programa de suma de dos números, elegir cuatro pares de sumandos al
azar no aporta mucha seguridad a la prueba (una probabilidad de 4/10.000 de cobertura de
posibilidades). Por eso es necesario recurrir a ciertos criterios de elección que veremos a
continuación.
Existen tres enfoques principales para el diseño de casos:
El enfoque estructural o de caja blanca
El enfoque funcional o de caja negra
El enfoque aleatorio.
36
Estos enfoques no son excluyentes entre sí, ya que se pueden combinar para conseguir una
detección de defectos más eficaz. Veremos a continuación una presentación de cada uno de ellos.
Pruebas de caja blanca
Este método de casos de prueba usa los detalles procedimentales del programa. Se busca obtener
casos de prueba que:
Garanticen que se ejecuta por lo menos una vez todos los caminos independientes de
cada módulo.
Verificar las decisiones lógicas (V/F).
Ejecutar las condiciones en sus límites.
Ejecutar las estructuras internas de datos para asegurar su validez.
Prueba de camino básico
o Notación de grafo de flujo
o Complejidad ciclomática
o Obtención de casos de prueba
o Matrices de grafos
Prueba de la estructura de control
o Prueba de condición
o Prueba de flujo de datos
o Prueba de bucles
PRUEBA DEL CAMINO BÁSICO
Es una técnica de prueba de caja blanca que nos permite obtener una medida de complejidad
lógica.
Con la medida de complejidad se genera un conjunto básico de caminos que se ejecutan por lo
menos una vez durante la ejecución del programa.
Obtención de casos de prueba
1) Dibujar el grafo correspondiente
2) Determinar la complejidad.
3) Determinar un conjunto básico de caminos linealmente independientes
4) Preparar casos de prueba que forzarán a la ejecución de cada camino básico.
PRUEBAS DE CAJA NEGRA
Métodos de prueba basados en grafos
Partición equivalente
37
Análisis de valores límites
Prueba de comparación
Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas
que prueben todos los requisitos funcionales del programa. Con este tipo de pruebas se intenta
encontrar:
1) Funciones incorrectas o ausentes.
2) Errores de interfaz
3) Errores en estructuras de datos o en accesos a bases de datos externas.
4) Errores de rendimiento.
5) Errores de inicialización y terminación
Con la aplicación de esta técnica se obtiene un conjunto de pruebas que:
a. Reduce el número de casos de pruebas
b. Nos dicen algo sobre la presencia o ausencia de errores.
PRUEBA DE COMPARACIÓN
Esta técnica consiste en la comparación de salidas de un mismo software pero de sus diferentes
versiones. Cuando se han producido múltiples implementaciones de la misma especificación, a
cada versión del software se le proporciona como entrada los casos de prueba diseñados para la
otra. Si las salidas de distintas versiones son idénticas entonces todas las implementaciones son
correctas. Si la salida es diferente, se revisan las aplicaciones para determinar el defecto. Esta
prueba no es infalible
4.2.3 Tomar Configuración del Software a Probar
Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo tanto
debemos estar preparados, las actividades de CGS sirven para:
Identificar el cambio de nuestro software.
Controlar ese cambio.
Garantizar que el cambio quede bien implantado.
Informar el cambio.
La gestión de configuración del software no es un mantenimiento del software, el mantenimiento es
la etapa final de la ingeniería hasta que se retire el producto del equipo, la CGS es un conjunto de
actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del
software y termina sólo una vez que el software queda fuera de circulación.
38
Desgraciadamente, en el proceso de ingeniería del software existe una variable importantísima que
entra en juego, el cambio.
La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento del ciclo de
vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo
de todo el ciclo de vida”.
Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema? ¿Que produce los en
el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos
fundamentales y a menudo muy tradicionales dentro del desarrollo del software:
Nuevos requisitos del negocio o condiciones que dictan los cambios en las condiciones del
producto o en las normas comerciales.
Nuevas necesidades del los clientes que demandan la modificación de los datos
producidos por un sistema basado en computadora.
Reorganización y/o reducción del volumen comercial que provoca cambios en las
prioridades del proyecto o en la estructura del equipo de ingeniería del software.
Restricciones presupuestarias o de planificaciones que provocan una redefinición del
sistema o del producto.
La gestión de configuración del software realiza un conjunto de actividades desarrolladas para
gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora.
La GCS es una actividad de garantía de calidad del software que se aplica en todas las fases del
proceso de ingeniería del software.
4.2.4 Configurar las Pruebas
Pruebas de carga
Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se realiza
generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones
esperada. Esta carga puede ser el número esperado de usuarios concurrentes utilizando la
aplicación y que realizan un número específico de transacciones durante el tiempo que dura la
carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes
de la aplicación. Si la base de datos, el servidor de aplicaciones, etc también se monitorizan,
entonces esta prueba puede mostrar el cuello de botella en la aplicación.
39
Prueba de estrés
Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el número de
usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe.
Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de
carga extrema y ayuda a los administradores para determinar si la aplicación rendirá lo suficiente
en caso de que la carga real supere a la carga esperada.
Prueba de estabilidad (soak testing)
Esta prueba normalmente se hace para determinar si la aplicación puede aguantar una carga
esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de
memoria en la aplicación.
Pruebas de picos (spike testing)
La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema
variando el número de usuarios, tanto cuando bajan, como cuando tiene cambios drásticos en su
carga. Esta prueba se recomienda que sea realizada con un software automatizado que permita
realizar cambios en el número de usuarios mientras que los administradores llevan un registro de
los valores a ser monitorizados.
Pre-requisitos para las pruebas de carga
Un desarrollo estable de la aplicación instalado en un entorno lo más parecido al de producción.
El entorno de pruebas de rendimiento no debe cruzarse con pruebas de aceptación de usuarios ni
con el entorno de desarrollo. Esto es tan peligroso que si las pruebas de aceptación de usuarios, o
las pruebas de integración o cualquier otra prueba se ejecutan en el mismo entorno, entonces los
resultados no son fiables. Como buena práctica, siempre es aconsejable disponer de un entorno de
pruebas de rendimiento lo más parecido como se pueda al entorno de producción.
4.2.5 Evaluar resultados
Mediante esta evaluación se miden los resultados del programa para ver si tuvo éxito.
¿Usan ahora el casco más personas que antes?? La medición de un cambio en los resultados es
probablemente la forma más común de evaluación, ya que permite conocer si el programa hace lo
que tiene que hacer.
4.2.5.1 Depuración.
La depuración es el proceso de identificar la raíz de un error y corregirlo. Difiere de la
prueba, la cual es el proceso mediante el cual se detecta inicialmente el error.
40
La depuración puede representar hasta el 50% del tiempo de desarrollo de un programa. Para
muchos programadores -especialmente para los principiantes - es la parte más difícil de la
programación. Pero la depuración no tiene que ser la parte más difícil. Si sigues las guías y
consejos de este documento, tendrás menos errores que depurar. La mayoría de los que tendrás
serán olvidos o fallas mecanográficas, fácilmente detectables mediante la observación del código o
su seguimiento con un depurador. Para el resto que queden, los más serios, los tips y técnicas que
se describen en este documento serán suficientes para que su depuración resulte más fácil.
El Rol de la Depuración en la Calidad del Software
Como la prueba, la depuración no es en sí una forma de mejorar la calidad de tu software;
es una manera de diagnosticar errores. La calidad del software debe integrarse desde el inicio del
proceso de programación. La mejor manera de construir software de calidad es desarrollar
cuidadosamente los requerimientos, diseñar bien, y usar prácticas de codificación de alta calidad.
La depuración es el último recurso.
¿Por Qué es Importante la Depuración?
Desafortunadamente la depuración es un área a la que se da poca importancia en los
cursos y libros de programación. Se nos enseña teoría y técnicas para a crear cosas, pero no a
asegurar su calidad.
El problema principal del software actual en el mundo entero es que los programas no son 100%
confiables por contener demasiados bugs, lo que habla de su mala calidad. Esta calidad no se
garantiza en parte por el stress del mundo competitivo de hoy, pero principalmente por el poco
énfasis que se pone en la enseñanza, donde no se presta la suficiente atención o no se cubren
tópicos como el diseño, el estilo de codificación, la documentación, y en particular técnicas y
herramientas para la realización eficiente y efectiva de la depuración.
Guía de Cómo *NO* Debes Depurar
En los siguientes párrafos se mencionan las cosas que nunca deben hacer al depurar. A
partir de ellas construiremos la lista de tips y técnicas para realizar eficazmente el proceso de la
depuración
Encuentra los errores adivinando
Para encontrar el error, disemina sentencias de impresión aleatoriamente por todo el programa.
Examina la salida para ver dónde está el error. Si no puedes encontrarlos de este modo, intenta
cambiar cosas hasta que algo parezca funcionar. No respaldes la versión original del programa, y
41
no guardes registro de los cambios que hagas. La programación es más excitante si no estás muy
seguro de lo que el programa está haciendo.
No pierdas tiempo intentando comprender el problema
Es probable que el problema sea trivial, y no necesites comprenderlo. Simplemente encontrarlo
bastará. Además, es probable que desaparezca por si solo.
Corrige el error de la manera más obvia
Usualmente es bueno solo corregir el problema específico que observas en vez de perder tiempo
haciendo una modificación grande y ambiciosa que vaya a afectar a todo el programa.
Figura 4.1 Corrige el error de la manera más obvia
La depuración consta de dos fases: encontrar el error y corregirlo. Encontrar el error (y
comprenderlo) es usualmente el 90 porciento del trabajo.
4.2.5.2 Análisis de errores.
Sirve para realizar predicciones de la fiabilidad del software y para detectar las causas más
habituales de error y por tanto mejorar los procesos de desarrollo.
El objetivo del análisis causal es proporcionar información sobre la naturaleza de los defectos. Para
ello es fundamental recoger para cada defecto detectado esta información:
42
Figura 4.2.5.2 Los Errores Son Oportunidades de Mejorar Como Programador
Asumiendo que no deseas que tus programas tengan errores, tenerlos significa que no
comprendes por completo el problema que intentas resolver o lo que hace tu programa. Y esto es
desconcertante (unsettling). Después de todo, si tú creaste el programa, él debería hacer lo que
deseas que haga. Si no sabes exactamente qué problema estás solucionando o qué le estás
diciendo a la computadora que haga, resta poco para que pruebes diferentes cosas hasta que algo
funcione. Esto es programar por prueba y error y ello garantiza más errores. No necesitas aprender
cómo corregir errores; necesitas aprender cómo evitarlos en primera instancia.
En cualquier caso, un error en tu programa representa una excelente oportunidad para:
Aprender sobre el problema o programa en que estás trabajando
Si comprendieras por completo el problema o programa no tendrías ese error. Ya lo hubieras
corregido.
Aprender sobre los tipos de errores que cometes
Si tú escribiste el programa, tú insertaste el error. Una vez que lo encuentras pregúntate ¿por qué
lo cometiste? ¿Cómo lo hubieras encontrado más rápido? ¿Cómo lo hubieras prevenido? ¿Existen
en el código otros errores como ése? ¿Puedes corregirlos antes de que causen problemas?
Aprender sobre la calidad de tu código desde el punto de vista de quien tiene que leerlo
Tendrás que leer el código para encontrar el error. Esta es una oportunidad de oro para ver con
sentido crítico si tiene calidad. ¿Es fácil leerlo? ¿Cómo puedes mejorarlo? Usa tus descubrimientos
para refactorizar el código o para mejorar el que escribas en el futuro.
Aprender sobre cómo resolver problemas
¿Tu técnica de depuración te da confianza? ¿Funciona? ¿Encuentras el error rápidamente? ¿O es
una debilidad tuya como programador? ¿Sientes angustia y frustración? ¿Adivinas al azar dónde
pueden estar los errores? ¿Necesitas mejorar? Considerando la gran cantidad de tiempo que
inviertes en la depuración, definitivamente no desperdiciarás tiempo si observas cómo depuras.
43
Tomarte el tiempo para analizar y cambiar la forma en que depuras puede ser la forma más rápida
de reducir la cantidad total de tiempo que te toma desarrollar un programa.
Aprender sobre cómo corriges los errores
Además de aprender cómo encuentras los errores, puedes aprender cómo corregirlos. ¿Realizas
las correcciones más rápidas parchando el código con sentencias goto y código para casos
especiales que cambian los síntomas pero no el problema? ¿O haces correcciones sistemáticas,
que demandan un diagnóstico exacto y un tratamiento que va directo al núcleo del problema?
4.3 TECNICAS DE DISEÑO DE CASOS DE PRUEBAS
Un producto puede probarse siguiendo dos criterios:
Conocimiento del funcionamiento del producto (Caja blanca).
El conocimiento de la función específica para la que fue diseñado el producto (Caja negra).
CRITERIOS DE REALIZACIÓN DE PRUEBAS
Para llevar a cabo la verificación del comportamiento de un sistema pueden servirse 2 criterios:
Descendente
Ascendente
Prueba Descendente empieza a nivel de sistema, prueba los módulos y por ultimo las
funciones que conforman. Utiliza un programa esclavo.
Prueba Ascendente da inicio la verificación de funciones hasta llegar al nivel superior del
sistema. Utiliza un programa conductor para cada modulo a probar.
Datos de prueba:
Representativos (datos comunes)
Incorrectos, incompletos e incongruentes
44
CLASES DE PRUEBA
Consideraciones Tipos de prueba
Costo de preparación Nivel de confi abilidad
lógico-simulado muy baja Bajo Estocásticos bajo bajo
Real medio medio Controlada alto medio-alto
Figura 4.2 Clases de prueba
4.4 ENFOQUE PRACTICO RECOMENDADO PARA EL DISEÑO DE
CASOS
Se propone un uso más apropiado de cada técnica (caja blanca y negra) para obtener un conjunto
de casos útiles:
Si la especificación contiene combinaciones de condiciones de entrada, comenzar
formando sus grafos de causa-efecto(ayudan a la comprensión de dichas
combinaciones)
En todos los casos, usar el análisis de valores límites para añadir casos de prueba:
elegir límites para dar valores a las causas en los casos generados asumiendo que
cada causa es una clase de equivalencia.
Identificar las clases válidas y no válidas de equivalencia para la entrada y la
salida, y añadir los casos no incluidos anteriormente
Utilizar la técnica de conjetura de errores para añadir nuevos casos, referidos a
valores especiales
Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida
Examinar la lógica del programa para añadir los casos precisos (de caja blanca)
para cumplir el criterio de cobertura elegido si los resultados de la ejecución del
punto anterior indican que no se ha satisfecho el criterio de cobertura elegido.
45
4.5 ESTRATEGIAS DE APLICACIÓN DE APLICACIÓN DE LAS
PRUEBAS
Proporcionan un plano o guía para el desarrollador del software, para la organización de control de
calidad y para el cliente.
Es una guía que describe los pasos a 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 lo tanto, cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño
de los casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos
resultantes.
Estrategias de prueba del software:
Prueba de unidad,
Prueba de integración,
Prueba de validación,
Prueba del sistema
4.5.1 De unidad
Centra el proceso de verificación en la menor unidad del diseño del software - el módulo.
Usando la descripción del diseño detallado como guía, se prueban caminos de control
importantes, con el fin de descubrir errores dentro del ámbito del módulo.
Está orientada a la caja blanca
Puede llevarse a cabo en paralelo para múltiples módulos.
CONSIDERACIONES SOBRE LA PRUEBA DE UNIDAD
Las pruebas que se dan como parte de la prueba de unidad son:
Se prueba la interfaz del módulo .
Se examinan las estructuras de datos locales.
46
Se prueban las condiciones límites .
Se ejercitan todos los caminos independientes de la estructura de control.
Y finalmente, se prueban todos los caminos de manejo de errores.
Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del módulo.
4.5.2 De integración
Es una técnica sistemática para construir la estructura del programa mientras que, al mismo
tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.
El objetivo es tomar los módulos probados en unidad y construir una estructura de programa que
esté de acuerdo con lo que dicta el diseño.
La integración incremental, El programa se construye y se prueba en pequeños segmentos en los
que los errores son más fáciles de aislar y de corregir, de esta forma es más probable que se
puedan probar completamente los interfaces y se puede aplicar un enfoque de prueba sistemática.
Hay estrategias de integración incremental denominadas:
Integración descendente,
Integración ascendente.
A continuación se deben ensamblar o integrar los módulos para formar el paquete del software
completo.
La prueba de integración se dirige a todos los aspectos asociados con el doble problema de
verificación y de construcción del programa.
Las técnicas que más prevalecen son las de diseño de casos de prueba de caja negra
La especificación de prueba incluye un plan general para la integración del software y una
descripción de las pruebas específicas. Es un resultado del proceso de ingeniería del software y
forma parte de la configuración del software.
El alcance de la prueba resume las características funcionales, de rendimiento y de diseño interno
específicas que van a a ser probadas. Se limita el esfuerzo de prueba, se describen los criterios de
terminación de cada fase de prueba y se documentan las limitaciones del plan.
4.5.3 De sistema
La prueba del sistema, realmente está constituida por una serie de pruebas diferentes cuyo
propósito principal es ejercitar profundamente el sistema basado en computadora.
Aunque cada prueba tiene un propósito distinto, todas trabajan para verificar que se han integrado
adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas
47
4.5.4 Prueba de aceptación
se refiere principalmente a las fallas que puedan generarse en la
implementación del sistema
Figura 4.2 pruebas de aceptación
UNIDAD 5 IMPLANTACION E IMPLEMENTACION
5.1 Implantación e integración de casos de uso y componentes de
software
Modelos de calidad
Según el estándar ISO 8402 (1986), un modelo de calidad puede definirse como el conjunto de
factores de calidad, y de relaciones entre ellos, que proporciona una base para la especificación de
requisitos de calidad y para la evaluación de la calidad de los componentes software. Los modelos
de calidad se estructuran generalmente como una jerarquía (ya sea un árbol, ya sea un grafo
dirigido), donde factores de calidad más genéricos, como eficiencia o usabilidad, se descomponen
en otros más particulares, como tiempo de respuesta o facilidad de aprendizaje, probablemente en
diversos niveles de descomposición.
Los modelos de calidad pueden aplicarse en diversas actividades propias del DBSC: establecer los
requisitos de calidad para la selección de un componente en base a los factores de calidad del
modelo; evaluar la calidad de un componente para cada uno de los factores de calidad del modelo;
comparar la calidad de distintos componentes respecto a los requisitos establecidos para un
proceso de selección; y redactar contratos formales, donde aparezcan explícitamente las
evaluaciones de calidad de los componentes que el proveedor certifica.
48
Normalmente, los factores de calidad que aparecen en el modelo pueden utilizarse como checklist
para todas aquellas cuestiones relacionadas con la calidad de los componentes.
Desde que se formuló el concepto de modelo de calidad, se han presentado múltiples propuestas.
Dichas propuestas intentan resolver entre otros los interrogantes siguientes: ¿Cuáles son los
factores de calidad que deberían formar parte de un modelo de calidad de componentes software?;
¿Cuáles son los tipos de factores de calidad en los que tiene sentido estructurar los modelos?;
¿Cómo se estructuran los modelos?; ¿Qué tipo de relaciones pueden existir entre los factores de
calidad?; ¿Cómo se evalúan los factores de calidad?
A continuación se presenta una clasificación de los tipos de modelos de calidad, las propuestas de
estándares de modelos de calidad más usadas, y una descripción y comparación de las
propiedades de las distintas propuestas
Propiedades de los modelos de calidad
Del estudio de las diferentes propuestas de modelos de calidad existentes, se desprenden algunas
propiedades estructurales importantes
Número de capas
En general, el número de capas de un modelo de calidad puede ser utilizado como una medida
para determinar el nivel de detalle con el que el dominio de software para el cual ha sido
construido: a más niveles, mayor descomposición y por tanto, una descripción más detallada del
tipo de componente a evaluar. Los modelos a la medida tienden a estructurarse en jerarquías con
más niveles de descomposición que los modelos fijos.
5.2 Mantenimiento del software
El Servicio de mantenimiento de software es una de las actividades en la Ingeniería de Software y
es el proceso de mejorar y optimizar el software desplegado (revisión del programa), así como
también remediar los defectos.
El mantenimiento de software es también una de las fases en el Ciclo de Vida de Desarrollo de
Sistemas (SDLC ó System Development Life Cycle), que se aplica al desarrollo de software. La
fase de mantenimiento es la fase que viene después del despliegue (implementación) del software
en el campo.
49
La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos
y dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para
mejorar la usabilidad y aplicabilidad del software
Tipos de mantenimiento
A continuación se señalan los tipos servicio de mantenimientos existentes, y entre paréntesis el
porcentaje aproximado respecto al total de operaciones de mantenimiento:
Perfectivo (60%): Mejora del software ( rendimiento , flexibilidad , reusabilidad ..) o implementación
de nuevos requisitos. También se conoce como mantenimiento evolutivo .
Adaptativo (18%): Adaptación del software a cambios en su entorno tecnológico (nuevo hardware,
otro sistema de gestión de bases de datos , otro sistema operativo ...)
Correctivo (17%): Corrección de fallos detectados durante la explotación.
Preventivo (5%): Facilitar el mantenimiento futuro del sistema (verificar precondiciones, mejorar
legibilidad...).
50
GLOSARIO
Unidad 1
1.- Fiabilidad: probabilidad de buen funcionamiento de algo". Por tanto, extendiendo el significado
a sistemas, se dice que la fiabilidad de un sistema es la probabilidad de que ese sistema funcione o
desarrolle una cierta función, bajo condiciones fijadas y durante un período determinado.
2.- Escalabilidad: es la propiedad deseable de un sistema, una red o un proceso, que indica su
habilidad para extender el margen de operaciones sin perder calidad, o bien manejar el crecimiento
continuo de trabajo de manera fluida, o bien para estar preparado para hacerse más grande sin
perder calidad en los servicios ofrecidos.
3.- Portabilidad: Se define como la característica que posee un software para ejecutarse en
diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez de crearse un
nuevo código cuando el software pasa de una plataforma a otra.
4.- Disponibilidad: El concepto de disponibilidad se utiliza en diversos ámbitos y esferas para hacer
referencia a la posibilidad de que algo, un producto o un fenómeno, esté disponible de ser
realizado, encontrado o utilizado.
5.- Requisito no funcional: Un requisito no funcional o atributo de calidad es, un requisito que
especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus
comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se
refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.
6.- Proceso: Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que
se realizan o suceden (alternativa o simultáneamente) bajo ciertas circunstancias con un fin
determinado.
Interfaz En software, parte de un programa que permite el flujo de información entre un usuario y
la aplicación, o entre la aplicación y otros programas o periféricos. Esa parte de un programa está
constituida por un conjunto de comandos y métodos que permiten estas intercomunicaciones
Mapeo
es una técnica de programación para convertir datos entre el sistema de tipos utilizado en un
lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional,
utilizando un motor de persistencia.
51
Emular
Imitar las acciones de otro procurando igualarlo o superarlo
Unidad 2
Abstracciones: En programación, el término se refiere al énfasis en el "¿qué hace?" más que en el
"¿cómo lo hace?" (característica decana).
Taxonomía: ordenamiento
Trazabilidad: Se entiende trazabilidad como el conjunto de aquellos procedimientos
preestablecidos y autosuficientes que permiten conocer el histórico,
Implementación: Una implementación o implantación es la realización de una aplicación.
Iterativos: trata de resolver un problema (como una ecuación o un sistema de ecuaciones)
mediante aproximaciones sucesivas a la solución, empezando desde una estimación inicial.
Estado: es la condición de un objeto en un momento determinado: el tiempo que transcurre entre
eventos. (Un teléfono se encuentra en estado “ocioso“ una vez que el auricular es puesto en su
sitio y mientras no lo levantemos.)
OFIMATICA
Se llama ofimática el conjunto de técnicas, aplicaciones y herramientas informáticas que se utilizan
en funciones de oficina para optimizar, automatizar y mejorar los procedimientos o tareas
relacionados.
INSTANCIA
Una instancia de un programa es una copia de una versión ejecutable del programa que ha sido
escrito en la memoria del computador.
interaccion
La interacción es una acción recíproca entre dos o más objetos, sustancias, personas o agentes.
diagramas de interacción
52
Los diagramas de interacción explican gráficamente cómo losobjetos interactúan a través de
mensajes para realizar las tareas.
Transiciones
Las transiciones reflejan el paso de un estado a otro,
Unidad 3
Transición: es una relación entre dos estados, indica que, cuando ocurre un evento el objeto pasa
del estado anterior al siguiente. (Cuando ocurre el evento “levantar el auricular“, el teléfono realiza
la transición el estado “ocioso“ al estado “activo“.)
Interacción: Podríamos decir que es la disciplina que estudia el intercambio de información
mediante software entre las personas y las computadoras.
Componente: es una parte física y reemplazable de un sistema que implementa un conjunto de interfaces.
Nodo: es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional
Sistemas de tiempo real: Es un sistema informático que interacciona rápidamente con su entorno físico y realiza funciones de supervisión y control.
Diagrama Una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.
Requisitos Los componentes pueden tener requisitos adjuntos para indicar sus obligaciones contractuales; esto es, qué servicios proveen en el modelo los requisitos ayudan a documentar el comportamiento Funcional de los elementos de software.
Restricciones: Los componentes pueden restricciones asignadas que indican el entorno en el que operan.
nodoun nodo es un punto de intersección , conexión o unión de varios elementos que confluyen en el mismo lugar.
SincronizacionSincronización (del griego συν (sýn), "unido" y χρόνος (chrónos), "tiempo", describe el ajuste temporal de eventos. Se habla de sincronización cuando determinados fenómenos ocurran en un orden predefinido o a la vez.
53
WAPWireless Application Protocol o WAP (protocolo de aplicaciones inalámbricas) es un estándar abierto internacional para aplicaciones que utilizan las comunicaciones inalámbricas, p.ej. acceso a servicios de Internet desde un teléfono móvil.GSMLa localización GSM es un servicio ofrecido por las empresas operadoras de telefonía móvil que permite determinar, con una cierta precisión, donde se encuentra físicamente un terminal móvil determinado.
UMTSSistema universal de telecomunicaciones móviles (Universal Mobile Telecommunications System o UMTS) es una de las tecnologías usadas por los móviles de tercera generación, sucesora de GSM, debido a que la tecnología GSM propiamente dicha no podía seguir un camino evolutivo para llegar a brindar servicios considerados de tercera generación.
Unidad 4Solapamiento: un factor de calidad participa en la descomposición jerárquica de varios otros de niveles superiores. Cabe citar que dicho factor puede evaluarse con métricas diferentes para cada uno los factores que descompone.
Transversalidad: es una relación de solapamiento donde no sólo cambia la métrica, sino también la definición. Este es el caso de las seis subcaracterísticas de Cumplimiento asociadas a cada una de las características incluidas en el modelo de calidad del estándar ISO/IEC 9126-1 (2001).
Dependencia: un factor de calidad se relaciona con otros factores, generalmente del mismo nivel. Por ejemplo, Chung et al. (2000) identifican diversos tipos de dependencia (makes, breaks, etc.) dependiendo del tipo de relación (favorecer vs. perjudicar) y del grado de intensidad de la misma (total o parcial). El número de dependencias puede llegar a ser muy elevado, aunque como señalan Egyed y Grünbacher (2004), muchas de ellas pueden no ser relevantes.
Funcionalidad: Capacidad del producto software para proporcionar las funcionalidades que
satisfacen las necesidades explicitas e implícitas cuando el software se usa bajo unas ciertas
condiciones
Adecuación: Capacidad del producto software para proporcionar un conjunto de funciones
apropiado para unas ciertas tareas y objetivos de usuario
Exactitud: Capacidad del producto software para proporcionar los resultados o efectos correctos o
acordados, con el grado necesario de precisión
Interoperabilidad: Capacidad del producto software para interactuar con uno o más sistemas
54
Seguridad: Capacidad del producto software para proteger información y datos de manera que las
personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega
el acceso a las personas o sistemas autorizados
Cumplimiento funcional: Capacidad del producto software para adherirse a normas, convenciones
o regulaciones en leyes y prescripciones similares relacionadas con la funcionalidad
Fiabilidad: Capacidad del producto software para mantener un nivel especificado de prestaciones
cuando se usa bajo unas cierta condiciones
Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software
FUENTES DE INFORMACIÓN
http://adimen.si.ehu.es/~rigau/teaching/EHU/ISHAS/Curs2007-2008/Apunts/IS.14.pdf
http://lsi.ugr.es/~ig1/docis/pruso.pdf
www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r67850.PPT
http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/8.3%20prb-cal-mant.pdf
Análisis y diseño de sistemas de información (James A. Senn)
Análisis y diseño de sistemas (Kendall&Kendall)
Ingeniería de Software (Roger S. Pressman)
Diseño de sistemas de información Teoría y Practica (John G. Burch)
55
