Manual de Asignatura Ing-Sw II

Ingeniera de software II
TIC-Sistemas Informticos
Presenta: Gloria del C. Crdoba Hernndez
ndice
Contenido Ingeniera de Software II .................................................................................... 5 Unidad I. Diseo de interfaz de Usuario ............................................................. 5 PRINCIPIOS DE USABILIDAD. ...................................................................... 6 Atributos de Usabilidad ................................................................................ 6 Los 10 principios de la usabilidad: ............................................................... 7 Relacin entre la Usabilidad y la Interfaz Grfica de Usuario ...................... 8 1. Practica 1. ............................................................................................. 9
ESTANDARES ................................................................................................ 9 Estndares de la interfaz ........................................................................... 10 Beneficios de utilizar Estndares ............................................................... 10 Tipos de estndares .................................................................................. 10 Estndares de iure ..................................................................................... 10 Estandares de facto ................................................................................... 12 GUIAS DE ESTILO ....................................................................................... 12 Guas de estilo comerciales: ...................................................................... 13 Guas de estilo CUA .................................................................................. 16 Guas de estilo para la WEB ...................................................................... 20 Conclusiones ................................................................................................ 23
Diseo de interfaz de usuario
Practica II ................................................................................................... 23 Unidad II. Documentacin en la etapa de codificacin ..................................... 24 ELEMENTOS DE LOS DIAGRAMAS DE: .................................................... 24 Elementos del diagrama de Componentes ................................................ 25 Diagrama de despliegue: ........................................................................... 29 Elementos del diagrama de Actividades: ................................................... 31 Documentacin en la codificacin ................................................................. 35 Estilo de programacin .............................................................................. 35 Nombrado de clases, mtodos, variables y constantes ............................. 36 Unidad III. Pruebas de software ....................................................................... 40 FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE. ............................ 40
2
Objetivos de las pruebas: .......................................................................... 40 PRINCIPIOS DE LAS PRUEBAS.................................................................. 41 DISEO DE CASOS DE PRUEBA ............................................................... 42 1. Prueba de caja blanca ........................................................................... 42 2. Prueba del camino bsico...................................................................... 42 3. Prueba de la estructura de control ......................................................... 43 4. Prueba de condicin .............................................................................. 43 5. Prueba del flujo de datos ....................................................................... 44 6. Prueba de bucles ................................................................................... 44 7. Prueba de caja negra............................................................................. 46 8. Prueba de interfaces grficas de usuario (igus) ..................................... 47 9. Prueba de arquitectura cliente/servidor ................................................. 47 10. Prueba de la documentacin y facilidades de ayuda ........................... 47 11. Prueba de sistemas de tiempo-real .................................................... 48 HERRAMIENTAS O ESTRATEGIAS DE PRUEBA DEL SOFTWARE ......... 48 Un enfoque estratgico para las pruebas del software .............................. 49 12. Prueba de unidad................................................................................. 50 13. Prueba de integracin .......................................................................... 51 14. Prueba de regresin ............................................................................ 52 15. Prueba de humo .................................................................................. 53 16. Prueba de validacin ........................................................................... 53 17. Revisin de la configuracin ................................................................ 53 18. Pruebas alfa y beta .............................................................................. 54 19. Prueba del sistema .............................................................................. 54 20. Prueba de recuperacin....................................................................... 54 21. Prueba de seguridad............................................................................ 55 22. Prueba de resistencia (STRESS)......................................................... 55 23. Prueba de rendimiento......................................................................... 55 EL ARTE DE LA DEPURACIN ................................................................... 56 PLAN DE PRUEBAS..................................................................................... 57 Propsito ....................................................................................................... 57 Alcance ......................................................................................................... 57 Tcnicas y Tipos de Testing ...................................................................... 57
Test de integridad de base de datos y datos ................................................ 57 Test de funcionalidad ................................................................................. 58 Test de Interfaz de Usuario........................................................................ 59 Test de Seguridad y de Control de Acceso................................................ 60 Test de Falla y Recuperacin .................................................................... 61 Test de Performance ................................................................................. 62 PRACTICA 3 ................................................................................................. 64 Plan de Pruebas............................................................................................ 64 Se deber entregar el archivo Plan de Pruebas.xls, con toda la informacin de los casos de prueba, respecto a cuatro de los seis tipos de testing mencionados anteriormente especificando como casos de prueba al menos 6 casos de prueba por cada tipo de pruebas. .................................................. 64 Entorno Necesario ..................................................................................... 64 Software Base para el Entorno de Prueba .................................................... 64 La siguiente tabla indica como ejemplo el software base que se requiere para ejecutar el Plan de Prueba. ........................................................................... 64 Roles.......................................................................................................... 64 1. Investigar herramientas (3) para ejecutar o simular casos de prueba ....................................................................................................... 65 Unidad IV. Liberacin del software ................................................................... 66 Manual tcnico: .................................................................................... 66 Manual de usuario: ............................................................................... 66 Manual de instalacin: ......................................................................... 67
Ingeniera de Software II
Competencia: Implementar sistemas de informacin de calidad, a travs de tcnicas avanzadas de desarrollo de software para eficientar los procesos de las organizaciones Unidades Temticas I. II. III. IV. Diseo de interfaz de usuario Documentacin en la etapa de codificacin Pruebas de software Liberacin de software
Objetivo de la asignatura: El alumno desarrollar un sistema de informacin empleando las tcnicas, metodologas y herramientas de diseo, pruebas y liberacin necesarias para garantizar la implementacin, de acuerdo a los requerimientos del cliente.
Unidad I. Diseo de interfaz de Usuario

Objetivo de la Unidad El alumno disear un sistema de informacin aplicando los principios de usabilidad, estndares y guas de estilo para mejorar la facilidad de uso.
Temas de la Unidad: Identificar los principios de Usabilidad: Interaccin Consistencia Facilidad de Aprendizaje Retroalimentacin Ayuda Estandarizacin Accesibilidad Identificar los tipos de estndares: iure facto Identificar las guas de estilo.
PRINCIPIOS DE USABILIDAD.
La usabilidad es un tema que est cobrando una importancia cada vez mayor en el desarrollo de software. A pesar de ello, la Ingeniera del Software sigue centrndose casi exclusivamente en atributos del software ms relacionados con el interior del sistema, como el rendimiento o la fiabilidad. En el entorno actual, en el que los sistemas software estn dirigidos a un pblico cada vez ms amplio, a usuarios cada vez menos expertos en el manejo de sistemas informticos, la usabilidad est destacndose como atributo fundamental para el xito de un producto software. La usabilidad se debe considerar como un atributo ms de calidad del software, integrar la usabilidad en un proceso de desarrollo de software no es fcil, el costo de introducir conceptos de usabilidad se justifica cuando: Reduce tiempos de desarrollo Incrementa las ventas Mejora la productividad del usuario Reduce costos de soporte y mantencin
La Usabilidad se define en el estndar ISO 9241 como el grado en el que un producto puede ser utilizado por usuarios especficos para conseguir objetivos especficos con efectividad, eficiencia y satisfaccin en un determinado contexto de uso [ISO98b],
Atributos de Usabilidad La usabilidad es una cualidad demasiado abstracta como para ser medida directamente. Para poder estudiarla se descompone habitualmente en los siguientes cinco atributos bsicos [Nielsen93]: Facilidad de aprendizaje: Cun fcil es aprender la funcionalidad bsica del sistema, como para ser capaz de realizar correctamente la tarea que desea realizar el usuario. Se mide normalmente por el tiempo empleado con el sistema hasta ser capaz de realizar ciertas tareas en menos de un tiempo dado (el tiempo empleado habitualmente por los usuarios expertos). Este atributo es muy importante para usuarios noveles. Eficiencia: El nmero de transacciones por unidad de tiempo que el usuario puede realizar usando el sistema. Lo que se busca es la mxima velocidad de realizacin de tareas del usuario. Cuanto mayor es la usabilidad de un sistema, ms rpido es el usuario al utilizarlo, y el trabajo se realiza con mayor rapidez. Ntese que eficiencia del software en cuanto su velocidad de proceso no implica necesariamente eficiencia del usuario en el sentido en el que aqu se ha descrito.
Recuerdo en el tiempo: Para usuarios intermitentes (que no utilizan el sistema regularmente) es vital ser capaces de usar el sistema sin tener que aprender cmo funciona partiendo de cero cada vez. Este atributo refleja el recuerdo acerca de cmo funciona el sistema que mantiene el usuario, cuando vuelve a utilizarlo tras un periodo de no utilizacin. Tasa de errores: Este atributo contribuye de forma negativa a la usabilidad de un sistema. Se refiere al nmero de errores cometidos por el usuario mientras realiza una determinada tarea. Un buen nivel de usabilidad implica una tasa de errores baja. Los errores reducen la eficiencia y satisfaccin del usuario, y pueden verse como un fracaso en la transmisin al usuario del modo de hacer las cosas con el sistema. Satisfaccin: ste es el atributo ms subjetivo. Muestra la impresin subjetiva que el usuario obtiene del sistema.
Algunos de estos atributos no contribuyen a la usabilidad del sistema en la misma direccin, pudiendo ocurrir que el aumento de uno de ellos tenga como efecto la disminucin de otro. Por ejemplo, esto puede ocurrir con la facilidad de aprendizaje y la eficiencia. Es preciso realizar el diseo del sistema cuidadosamente si se desea tanto una alta facilidad de aprendizaje como una alta eficiencia; siendo el uso de aceleradores (combinaciones de teclas que ejecutan operaciones de uso habitual) la solucin ms comn para conjugar ambos atributos de usabilidad. La usabilidad del sistema no es una simple adicin del valor de estos atributos, sino que se define para cada sistema como un nivel a alcanzar para algunos de ellos. Estos cinco atributos pueden descomponerse a su vez para conseguir una mayor precisin en los aspectos de usabilidad en los que se quiere poner mayor nfasis. Por ejemplo, rendimiento en uso normal y uso de opciones avanzadas son ambos subatributos de eficiencia, mientras que primera impresin es un subatributo de satisfaccin.
Los 10 principios de la usabilidad: Los 10 principios de la usabilidad del maestro Jakob Nielsen, publicado por Eduardo Aguayo en Noviembre del 2006 para IntelPCS basado en anlisis heurstico de usabilidad. Visibilidad del estado del sistema: El sistema siempre debe mantener informado al usuario acerca de lo que est pasando, utilizando para ello un feedback adecuado y en un tiempo razonable. Concordancia entre el sistema y el mundo real: El sistema debe hablar el lenguaje del usuario, con palabras, frases y conceptos familiares a l, ms all de los trminos orientados al sistema. Se deben seguir las
convenciones del mundo real, logrando que la informacin aparezca en un orden lgico y natural. Control y libertad del usuario: Los usuarios escogen frecuentemente por error algunas funciones del sistema, y necesitan de una salida de emergencia claramente rotulada, de modo que puedan volver al estado anterior sin pasar por dilogos complejos o extensos. Mantenga y de soporte para Deshacer y Rehacer acciones. Consistencia y estndares: Lo usuarios no deben lidiar con diferentes palabras, situaciones o acciones que signifiquen lo mismo. Siga las convenciones de la plataforma. Prevencin de errores: Aunque un mensaje de error bien diseado es bueno, es mucho mejor cuidar el diseo y evitar los problemas. Intente eliminar las posibilidades de error, o bien determine cules seran y mustrelas a los usuarios con una opcin de confirmacin antes que realicen la accin. Reconocimiento antes que llamadas: Minimice la carga nemotcnica del usuario entregando visibilidad a objetos, acciones y opciones. El usuario no tiene porqu recordar la informacin de un dilogo anterior en presencia de otro. Las instrucciones para el uso del sistema deben ser visibles o fcilmente accesibles cuando es necesario. Flexibilidad y eficiencia de uso: Aceleradores, invisibles al usuario novato, deberan entregar rapidez en la interaccin de los usuarios expertos, de tal modo que el sistema satisfaga a ambos. Permita a los usuarios automatizar acciones frecuentes. Diseo esttico y minimalista: Los dilogos no deben contener informacin que sea irrelevante o raramente necesitada. Cada bit extra de informacin compite con aquella que es relevante, y disminuye su visibilidad relativa. Ayude a los usuarios a reconocer, diagnosticar y recuperarse de los errores: Los mensajes de error deben ser expresados en un lenguaje natural, sin cdigos especficos del sistema. Deben indicar con precisin el problema, e indicar en forma constructiva la posible solucin. Ayuda y documentacin: Aunque se piense que lo mejor es que el sistema sea utilizable sin manuales ni guas de uso, siempre es necesario incluir algn tipo de ayuda y documentacin. Al respecto, toda informacin proporcionada debe ser fcil de encontrar, enfocada en la tarea del usuario y listando los pasos concretos a realizar, y por sobre todo, no ser demasiado larga.
Relacin entre la Usabilidad y la Interfaz Grfica de Usuario En el desarrollo de software se identifica a menudo la usabilidad con las caractersticas de los elementos de una interfaz grfica de usuario basada en ventanas, como puede ser su color, su disposicin o el diseo grfico de los
8
iconos y animaciones. Sin embargo, la usabilidad no slo tiene que ver con la interfaz grfica de usuario. La usabilidad de un sistema est ligada principalmente a la interaccin del mismo, al modo en que se realizan las operaciones con el sistema. Esta interaccin no est definida en la interfaz grfica, sino que est ligada en el cdigo que implementa la funcionalidad del sistema. La interfaz grfica de usuario es la parte visible de tal interaccin. Es cierto que la interfaz grfica es una parte importante del sistema, y un buen diseo de la misma puede hacer que un sistema aumente su nivel de usabilidad, pero un sistema con un diseo de la interaccin pobre no puede mejorar su nivel de usabilidad tan solo cambiando la interfaz grfica.
1) 2)
3) 4)
1. Practica 1. Leer el contenido del tema de principios de usabilidad. Realizar una abstraccin del contenido utilizando cualquiera de los siguientes medios didcticos. Mapa conceptual Pagina web Diseo de diapositivas Video Incluir adems el material investigado, con la referencia bibliogrfica. Explicar ante el grupo y dar ejemplos significativos, para lograr la participacin de los receptores de informacin.
ESTANDARES
Un estndar es un requisito, regla o recomendacin basada en principios probados y en la prctica. Representa un acuerdo de un grupo de profesionales oficialmente autorizados a nivel local, nacional o internacional Los estndares pueden ser: Locales Nacionales Internacionales El objetivo de los estndares es hacer las cosas ms fciles, definiendo caractersticas de objetos y sistemas que se utilizan cotidianamente
Ejemplos: teclado de telfono, teclado QWERTY
Toda la industria funciona con estndares Ejemplo: Construccin
Tambin la industria informtica Estndares de pantallas, teclados, conectores, incluso mobiliario Ejemplo: la inclinacin del teclado debe estar entre 0 y 25 grados
Estndares de la interfaz Objetivo: conseguir un software ms fcil y seguro, estableciendo unos requisitos mnimos de fabricacin, eliminando inconsistencias y variaciones innecesarias en las interfaces.
Beneficios de utilizar Estndares Una terminologa comn: Permite a los diseadores discutir los mismos conceptos y hacer valoraciones comparativas El mantenimiento y la evolucin: Todos los programas tienen la misma estructura y el mismo estilo Una identidad comn: Lo que hace que todos los sistemas sean fciles de reconocer Reduccin en la formacin: Los conocimientos son ms fciles de transmitir de un sistema a otro Salud y seguridad: Si los sistemas han pasado controles de estndares es difcil que tengan comportamientos inesperados.
Tipos de estndares Estndares de iure Estndares de facto
Estndares de iure Son generados por comits con estatus legal y gozan del apoyo de un gobierno o institucin para producir estndares. Para hacer un estndar de iure se ha de seguir un proceso complejo: Documento preliminar pblico Enmiendas
10
Aprobacin (tras cierto tiempo, a veces ao) Ejemplo: Ansi C
En Informtica tienen estatus legal para definir estndares de iure: ISO IEC ANSI IEEE CEN W3C Asociacin Internacional para Estndares Comisin Electrotcnica Internacional Instituto Nacional Americano para Estndares Instituto de Ingenieros Elctricos y Electrnicos Americano Comit Europeo para la Estandarizacin Consorcio para la World Wide Web
Algunos estndares de iure de los ms importantes son: ISO/IEC 9126: Evaluacin de productos software: caractersticas de calidad y directrices para su uso ISO 9241: requisitos ergonmicos para trabajar con terminales de presentacin visual (VDT) ISO/IEC 10741: interaccin de dilogos ISO/IEC 11581: smbolos y funciones de los iconos ISO 11064: diseo ergonmico de centros de control ISO 13406: requisitos ergonmicos para trabajar con presentaciones visuales basadas en paneles planos ISO 13407: procesos de diseo centrados en la persona para sistemas interactivos Algunos aspectos cubiertos por la ISO 9241 (requisitos ergonmicos para trabajar con terminales de presentacin visual):
11
Requisitos de la presentacin visual Requisitos de teclado Diseo de estaciones de trabajo y requisitos de las posturas Requisitos para colores visualizados Requisitos para dispositivos de entrada no-teclado Presentacin de informacin Dilogos de mens Dilogos para completar formularios
Estandares de facto Son estndares que nacen a partir de productos de la industria que tienen un gran xito en el mercado o desarrollos hechos por grupos de investigacin en la Universidad que tienen una gran difusin Son aceptados como tales por su uso generalizado, su definicin se encuentra en manuales, libros o artculos, Ejemplos: Sistema X-Windows Lenguaje C Normas CUA
GUIAS DE ESTILO
Pueden ser de dos tipos: Guas de estilo comerciales Guas de estilo corporativas
La principal ventaja es que aseguran una mejor usabilidad mediante la consistencia que imponen. En el lenguaje industrial se hace referencia a las guas de estilo como el look and feel
12
Para asegurar la consistencia de las diferentes partes de un sistema o de una familia de sistemas es fundamental para los desarrolladores basar sus diseos en un conjunto de principios y directrices. Por este motivo es tan importante para las organizaciones que desarrollan software disponer de una gua que puedan seguir sus desarrolladores, Estas guas se denominan guas de estilo y varan mucho en sus objetivos.
Guas de estilo comerciales: Son producidas por fabricantes de software y hardware, y son en general estndares de facto Apple Motif OS/2 Windows Open Look CDE, Common Desktop Environment Java Swing
Ejemplo de Apple (1985)
13
14
Sistema de ventanas
Principios bsicos de diseo Los usuarios tienen el control del dilogo Los usuarios tienen que desarrollar un modelo conceptual de la interfaz Uso de metforas Metfora de la sobremesa: los usuarios ven carpetas y documentos, no programas y archivos. El sistema establece la asociacin datos-programas Sistema dirigido por el usuario Consistencia Hacer la interfaz transparente
15
Guas de estilo CUA
Modelo grfico Las aplicaciones comparten la pantalla Cada una tiene asignada una parte o ventana Ventana activa: aquella con la que el usuario interacciona Niveles del modelo grfico: Presentacin Representa el aspecto visual de la interfaz Las aplicaciones tienen dos tipos de elementos que hay que presentar: Objetos - Cualquier cosa que el usuario pueda manipular - Son el centro de atencin del usuario Acciones - Permiten al usuario crear o manipular objetos - Se realizan mediante combinaciones de mens y cajas de dilogo. Acciones Mens: - Mens desplegables - Mens en cascada (no ms de dos niveles)
Cajas de dilogos:
16
- Presentan/recogen informacin - Ventana mvil de tamao fijo Aparece durante el procesamiento de una accin del usuario, cuando se requiere informacin para completarla. - Se utiliza una elipsis (...) tras el nombre del botn o elemento de men que abre la caja. - No usan mens. Usan botones para llamar a las acciones - Botones: confirmar, cancelar, ayuda. Tipos de cajas dilogos: No modal Permite a los usuarios continuar con su trabajo sin completar el dilogo Modal Requiere que los usuarios completen la caja de dilogo antes de continuar. Cajas de mensajes: Es un tipo especial de caja de dilogo que se utiliza exclusivamente para mostrar mensajes a los usuarios
Es el nivel a travs del cual los usuarios interaccionan con los componentes de la interfaz. Consta de: Seleccin de objeto Los usuarios apuntan a un objeto que desean manipular y lo seleccionan de manera visible Ejecucin de la accin Se selecciona una opcin de men y si es preciso se completa con una caja de dilogo La ejecucin de la accin debe ser visualizada
17
Interaccin
Seleccin de objeto
Ejecucin de accin
18
Apuntar y seleccionar Los usuarios interaccionan con los componentes de la interfaz Apuntan a lo que desean manipular y lo seleccionan Se utiliza tanto el teclado como el ratn El teclado y el ratn tienen una indicacin visual para indicar al usuario dnde se encuentra. Indicacin visual Teclado Seleccin de campos (caja de lneas discontinuas) Entrada de campos (cursor de texto) Ratn Un puntero indica la posicin del ratn nfasis Trata de realzar la importancia de algunos elementos de interaccin para que el usuario cuando interacciona pueda saber: Foco de la entrada Opciones disponibles Opciones no disponibles Estado actual de las opciones Tipos de nfasis: nfasis de cursor nfasis de seleccin nfasis de no disponible nfasis del estado actual
Seleccin: Seleccin con el ratn Clic, Doble-clic, Mayus+clic, Ctrl+clic, Arrastrar y seleccionar Seleccin con el teclado Tabulacin, flechas, Mayus y Ctrl (seleccin), Alt (mens Acciones comunes: La consistencia en acciones comunes es importante para reforzar el modelo conceptual del usuario Existen acciones que son comunes a la mayora de las aplicaciones, y que CUA define: Abrir fichero Imprimir Tipo de letra
Componentes CUA define una serie de componentes y describe sus propiedades Botones de radio (radio button) Botones de comprobacin (check button) Botones pulsables (push button)
Caja de grupo (group box) Campo de texto (text box) Caja de lista (list box) Caja de combinacin (combo box)
Indicador de progreso - Cambio del puntero - Ventana de progreso de la accin Control de desplazamiento
19
Ayuda: Permite resolver las dudas de los usuarios Interaccin Tecla F1 Seleccionando el botn de ayuda Seleccionando el men de ayuda Tipos de ayuda Ayuda contextual Tutorial Glosario
Guas de estilo para la WEB

Disear para la Web es diferente de disear interfaces de usuario tradicionales. Algunos principios son aplicables pero la Web tiene sus particularidades. Una caracterstica importante de la Web es la falta de interfaces de usuario comunes. La prioridad es conseguir una interfaz atractiva, diferente de las otras. Para afrontar este problema varias empresas y organismos han publicado sus guas de estilo Web. Apple (www.geo.tu-freiberg.de/docs/apple/web_design/intro.htm) IBM (www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/572) Sun (sut1.sut.ac.th/StyleGuide/Printing_Version.html) W3C (www.w3.org/WAI/Resources/#gl) Yale Center for Advanced Instructional Media National Cancer Institute (NIC)
20
IBM
W3C El W3C alberga la Iniciativa de Accesibilidad Web (WAI), patrocinada por varias organizaciones Las guas juegan un papel importante para crear sitios web accesibles WAI ofrece tres guas diferentes: Web Content Accessibility Guidelines (WCAG) Authoring Tool Accessibility Guidelines (ATAG) User Agent Accessibility Guidelines (UAAG) Web Content Accessibility Guidelines (WCAG) Principios de diseo para hacer los sitios web accesibles. Estudian escenarios que pueden ocasionar problemas a usuarios discapacitados Authoring Tool Accessibility Guidelines (ATAG) Asisten a los desarrolladores de herramientas de creacin de contenidos web para que estos sean accesibles User Agent Accessibility Guidelines (UAAG) Explican las caractersticas de las interfaces que benefician a las personas con discapacidades (navegacin por teclado, opciones de configuracin, documentacin, comunicacin por voz)
21
YALE info.med.yale.edu/caim/manual Es una de las ms reconocidas Cubre todos los elementos bsicos implicados en la creacin de un sitio web Se centra en la interfaz y en los principios de diseo grfico subyacentes al diseo de un sitio web
NATIONAL CANCER INSTITUTE
22
Guas de estilo CUA
Ayudan a las empresas a dar un mismo estilo a todos sus productos Si una organizacin desea desarrollar su propio estilo corporativo, primero ha de escoger una gua de estilo comercial Esta gua se aumenta con unas caractersticas propias que produzcan una imagen coherente de la organizacin
Conclusiones
Los estndares y guas proporcionan una base sobre la cual realizar el diseo y desarrollo Sin embargo, el uso de guas no garantiza que la interfaz sea usable Es mejor seguir las guas que no hacerlo. Puede que podamos hacer un diseo mejor sin guas, pero son muchas ms las ventajas que aportan que las desventajas Es conveniente dar facilidades a los diseadores y programadores: Proporcionar ejemplos en la documentacin Incorporar las guas a las herramientas Dar formacin y entrenamiento Los estndares y las guas de estilo facilitan el diseo de interfaces Tambin facilitan el aprendizaje y reducen los errores al permitir al usuario aprovechar el conocimiento adquirido en otros productos.
Practica II Rbrica de evaluacin
23
Unidad II. Documentacin en la etapa de codificacin

Objetivo de la Unidad El alumno elaborar los diagramas UML y la documentacin para guiar la etapa de codificacin en el desarrollo de software. Temas de la Unidad: Elementos de los diagramas de: Componentes Implementacin despliegue actividad Documentacin en la codificacin: Convencin del lenguaje de programacin: Conjunto de normas y reglas para la escritura de cdigo en un lenguaje determinado en elementos tales como: Nombres de archivos, Nombres de clases, Mtodos, Variables, Constantes, Comentarios, Etc. Facilitan y hacen ms comprensible la lectura del cdigo.
ELEMENTOS DE LOS DIAGRAMAS DE:
Elementos de los diagramas de: Componentes Implementacin despliegue actividad
24
Elementos del diagrama de Componentes Componentes Interfaces Relaciones de dependencia, generalizacin, asociacin y realizacin Paquetes o subsistemas Componentes:
Es una parte fsica de un sistema (modulo, base de datos, programa ejecutable, etc.). Se puede decir que un componente es la materializacin de una o ms clases, porque una abstraccin con atributos y mtodos pueden ser implementados en los componentes. En un DC, un componente se representa con un rectngulo en el que se escribe su nombre y se muestran dos pequeos rectngulos al lado izquierdo. O tambin los siguientes: Representacin simple de un Componente:
Estereotipos de COMPONENTES:
UML define cinco estereotipos estndar que se aplican en los componentes o o o o Executable, componente que se puede ejecutar. Library, biblioteca de objetos esttica o dinmica. Table, Componentes que representa una tabla de base de datos File, componente que representa un documento que contiene cdigo fuente o datos. o Document, Comp. Que representa un documento.
25
Relaciones de dependencia, generalizacin, asociacin y realizacin:
Paquetes o subsistemas
Los componentes se pueden agrupar en paquetes as como los objetos en clases, adems pueden haber entre ellos relaciones de dependencia como: Generalizacin Asociacin Agregacin Realizacin
Interfaces
Es el lazo de unin entre varios componentes, donde C es el nombre de la Interfaz:
Las interfaces pueden representarse de varias formas, como vemos en la grfica:
26
Adems se pueden representar de dos maneras: forma icnica y expandida
En qu fase del ciclo de vida se encuentra? Se representa en el diseo que da paso a la implementacin. Se genera a partir de diagrama de clases.
Por qu utilizar un diagrama de componentes? Nos permite ver el modelado de un sistema o subsistema Permite especificar un componente con interfaces bien definidas. Si los componentes se disean de tal forma que puedan ser tratados tan independientemente podrn ser reutilizados.
Con Diagrama de Despliegue
27
Relacin con otros diagramas
Diagrama de componentes: Un nodo representa un proceso o un dispositivo sobre los cuales se pueden desplegar los componentes. Similitudes: tienen nombre pueden anidarse Diferencias: Los nodos son elementos donde se ejecutan los componentes, en cambio, los componentes son elementos que participan en la ejecucin del sistema. Los nodos representan el despliegue fsico de componentes, en cambio, los componentes representan el empaquetamiento fsico de los elementos lgicos.
Pasos para la elaboracin de un diagrama de componentes: Previamente al diagrama de componentes debemos de tener hecho el diagrama de clases. Se debe identificar a todos las clases que participaran en el sistema o subsistema a desarrollar. Una vez identificado las clases, se procede a identificar sus mtodos. Estos mtodos pasaran a ser mdulos con lneas de cdigo independientes. Estos mdulos sern los componentes de nuestro diagrama. Estos componentes se relacionan entre s por medio de sus interfaces.
Mtodo de la clase pesan a ser mdulos Mdulos pasan a ser componentes.
28
Relacin con diagrama de clases:
Ejemplo de diagrama de componentes
Diagrama de despliegue: Muestra la relacin entre los componentes de software y hardware en el sistema y la distribucin fsica de la tramitacin. Para cada componente de un diagrama en necesario que se deba documentar las caractersticas tcnicas requeridas; se preparan durante la fase de implementacin del desarrollo, muestran la disposicin fsica de los nodos en un sistema distribuido, los artefactos que se almacenan en cada nodo, y los componentes.
Caractersticas: Muestran los enlaces de comunicacin fsica entre elementos de hardware. Muestra las relaciones entre maquinas fsicas y procesos. Sistemas integrados que utilizan el hardware que est controlada por los estmulos externos. Sistemas distribuidos que tiene varios servidores y puede albergar mltiples versiones de artefactos de hardware. Se centran en la configuracin de los nodos de procesamiento en tiempo de ejecucin y sus componentes.
29
En qu casos utilizamos los diagramas de despliegue? Son utilizados principalmente por ingenieros de sistema. Estos diagramas se utilizan para describir los componentes fsicos (hardware) de su distribucin y asociacin. Para modelar la topologa del hardware de un sistema. El modelo de sistema integrado. Para detalles de hardware modelo de una aplicacin distribuida. Avance y retroceso de la ingeniera.
Usos Sistemas empotrados: es una coleccin de hardware con una gran cantidad de software que interacta con el mundo fsico. Sistemas cliente-servidor: son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores. Sistemas completamente distribuidos: sistemas que son ampliamente distribuidos y que normalmente incluyen varios niveles de servidores.
Ventajas: Muestra un conjunto de nodos y sus relaciones. Se utilizan para describir la vista de despliegue esttica de un sistema. Se relacionan con los diagramas de componentes, ya que un nodo normalmente incluye uno o ms componentes.
Esquema del diagrama de despliegue
30
Desventajas: La posible falla en la modelacin de un hardware. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologa del sistema.
UML define cinco estereotipos estndar que se aplican en los componentes o Executable, componente que se puede ejecutar. o Library, biblioteca de objetos esttica o dinmica. o File, componente que representa un documento que contiene cdigo fuente o datos. o Document, Comp. Que representa un documento.
Elementos del diagrama de Actividades: Particiones Nodos de accin Nodos de control Nodos de objeto Extremos Otros elementos Elementos principales del diagrama de Actividades: Nombre del diagrama Estado de Accin Transicin Barras de sincronizacin Nodo de decisin Inicio y Fin Clase::Operacin
Definicin del diagrama de actividades: Representa el comportamiento interno de una operacin o de un caso de uso, bajo la forma de un desarrollo por etapas, agrupadas secuencialmente. El propsito del diagrama de actividad es: Modelar el flujo de tareas Modelar las operaciones
31
Organizacin de los elementos:
Caractersticas: Muestra los aspectos dinmicos de un sistema Puede describir procesos o casos de uso. Permite elegir el orden en que pueden hacerse las cosas. Establece las reglas de secuencia a seguir.
Particiones: Carriles (swimlanes) o Calles Franja de divisin vertical Muestra las actividades responsabilidad de un determinado objeto Puede representar a un actor o trabajador del negocio que participa en el proceso modelado por un caso de uso.
32
Nodo de control Nodo inicial (initial state). Indica el comienzo del flujo de actividades. Representa el inicio del flujo de trabajo del caso de uso del negocio. Se representa a travs de un crculo de color negro. Se coloca dentro del swimlane correspondiente al rol que comienza el caso de uso. Es un estado nico para el flujo de actividades Nodo final (end state) Indica el final del flujo de actividades del caso de uso. Se representa a travs de un crculo de color negro dentro de un crculo transparente. Se coloca dentro del swimlane correspondiente al rol que termina el caso de uso. Puede haber ms de un estado final en dependencia de las diferentes maneras de acabar el caso de uso. Ejemplo del diagrama de clases: Se tiene un proceso de solicitud de servicio. El cliente realiza la solicitud de un servicio, el vendedor pregunta si es cliente nuevo, en caso de serlo le pide sus datos y los registra. Luego pide los datos del servicio, indica el plan de tarifas y los indica al cliente. En caso de ser aceptada por el cliente, el vendedor programa servicio. Realice un Diagrama de Actividad para el caso planteado.
33
Nodo de objeto: flujo de Objetos: muestra el cambio de estado de un objeto al realizarse una actividad elementos: nodo de Objeto flujo de objetos
Objetos salen de una actividad (cambia de estado)
Objetos entran de una actividad (lectura de estado)
Conclusiones del diagrama de actividades:

Los diagramas de actividad pueden visualizar, especificar y documentar la dinmica de un conjunto de objetos. Tambin se pueden usar para modelar el flujo de control de una operacin. Mientras que los diagramas de interaccin enfatizan el flujo de control de un objeto a otro, los diagramas de actividad subrayan el flujo de control de una actividad.
34
Documentacin en la codificacin
Estilo de programacin Hace referencia a como formateamos el cdigo que estamos desarrollando, tales como llaves, identacin, parntesis, el espaciado, etc. Esto puede diferir entre lenguajes de programacin. 1. Identacin: Existen varios estilos tales como: Allman, K&R, BSD KN, Whitesmiths, etc. Estilo Allman Usar los sangrados para identar cdigo, nunca espacios. Poner las llaves de control en la lnea subsiguiente.
3. Espacios y lneas en blanco

35
2. Saltos de lnea: Aadir un salto de lnea despus del cierre de los parntesis de los parmetros. Aadir un salto de lnea despus un punto y coma, cuando termina la sentencia.
Usar espacios en blanco para mejorar la legibilidad del cdigo. Usar espacios en blanco a ambos lados del operador de smbolos, despus de comas y despus de las declaraciones. Usar lneas en blanco para separar trozos de cdigo. Usar lneas en blanco antes de cada mtodo dentro de la clase.
4. Longitud de la lnea Evitar las lneas de ms de 80 caracteres, cuando se supera debe ser cortado bajo los siguientes principios: Salto de lnea despus de la coma. Salto de lnea despus de un operador. Alinear la nueva lnea con el principio de la expresin en el mismo nivel en la lnea anterior.
Nombrado de clases, mtodos, variables y constantes Hace referencia al a nomenclatura de los nombres.
36
1. Clases Las clases representan cosas y no acciones, por tal motivo evitar verbos como nombre de clase. El nombre de la clase debe estar en singular, salvo que la clase represente multiplicidad de cosas. Los nombres de las clases deberan ser sustantivos: ejemplo carro, hombre, tienda, pas, empleado, proveedor, etc. Cada clase debe tener un bloque de documentacin segn la norma del lenguaje. 2. Mtodos Los nombres de los Mtodos deberan ser un verbo, dado que describe una accin; ejemplo remover(), enviar(), cargar() Los Mtodos dentro de las clases siempre deben declarar su visibilidad tales como privada, protegida, pblica, etc 3. Variables Evitar nombres de variables de un solo caracter. Nombres comunes para las variables temporales: i, j, k, m, y n para los nmeros enteros. c, d, y e para los caracteres. Los nombres de variables slo pueden contener caracteres alfanumricos. Los nombres de variables deben ser camelCase 4. Constantes Ejemplos segn el tipo de lenguaje
MIN_WIDTH LOCAL_CONSTANT COLUMNS
LocalConstant MIN_WIDTH LOCAL_CONSTANT MinWidth Colums

COLUMNS
Convenciones del uso de maysculas y minsculas Muchas convenciones de nomenclatura hacen uso de las maysculas y minsculas en sus identificadores.
37
PHP
C#
Java
1. Estilo Pascal (PascalCase) La primera letra del identificador y la primera letra de las siguientes palabras concatenadas estn en maysculas. El estilo de maysculas y minsculas Pascal se puede utilizar en identificadores de tres o ms caracteres, por ejemplo: ImageSprite 2. Estilo CamelCase El uso de camelCase lleg a ser extenso solamente en los aos 70 y los aos 80, cuando fue adoptado como estndar o la convencin de nombramiento alternativa para los identificadores de varias palabras en varios lenguajes de programacin, el origen de esta convencin todava no se ha colocado. El camelCase o los capitales intermedios es la prctica de las palabras compuestas de la escritura o de las frases en las cuales las palabras se ensamblan sin los espacios y son capitalizados dentro del compuesto. El nombre viene del maysculo: bump" en el medio de la palabra compuesta, sugestiva de las chepas de un camello. La primera letra del identificador est en minscula y la primera letra de las siguientes palabras concatenadas en mayscula, por ejemplo: imageSprite 3. Estilo Maysculas (ALL_CAPS) Es una convencin de identificador de nomenclatura en muchos lenguajes de programacin que simboliza que el identificador dado representa una constante. Todas las letras del identificador se encuentran en maysculas (posiblemente con guiones bajos para reemplazar espacios) ejemplo: IO Adems, puede que sea necesario utilizar maysculas en los identificadores para mantener la compatibilidad con esquemas existentes de smbolos no administrados, donde los caracteres en maysculas se utilizan con frecuencia en valores de constantes y enumeraciones. En general, estos smbolos no deben ser visibles fuera del ensamblado en el que se utilizan. 4. Estilo minsculas (small_caps) Todas las letras del identificador se encuentran en minsculas. Ejemplo: system 5. Estilo hngaro El estilo hngaro es un sistema usado normalmente para crear los nombres de variables. Tambin se utiliza para nombrar las instancias de objetos en lenguajes de programacin visuales, como por ejemplo Delphi. El nombre de la notacin proviene del hecho de que su inventor, Charles Simonyi, naci en Hungra.
38
Esta convencin es muy poco utilizada en las viejas versiones de Delphi pero es muy utilizada por los programadores de Microsoft y, en particular, en la programacin del sistema operativo Windows. Consiste en prefijos en minsculas que se aaden a los nombres de las variables y que indican su tipo. El resto del nombre indica, lo ms claramente posible, la funcin que realiza la variable. Ejemplos: intCosto bolSexo strNombre dblResultado
Estilo de programacin Rbrica
39
Unidad III. Pruebas de software
Objetivo de la Unidad El alumno realizar pruebas de software empleando metodologas y herramientas para detectar e interpretar errores.
Temas de la Unidad: Tipos de pruebas de Software: Conceptos Objetivos de pruebas Casos de prueba Documentar casos de prueba Disear casos de prueba de software Herramientas para pruebas de software Herramientas para ejecutar o simular casos de pruebas Interpretacin de resultados obtenidos de la ejecucin de casos de prueba.
FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE.
Objetivos de las pruebas:

1. La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un 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. Si la prueba se lleva a cabo con xito (de acuerdo con el objetivo anteriormente establecido), descubrir errores en el software. Como ventaja secundaria, la prueba demuestra hasta qu punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento.
40
PRINCIPIOS DE LAS PRUEBAS
A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente. Se entiende que los defectos ms graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos. Las pruebas deberan planificarse mucho antes de que empiecen . La planificacin de las pruebas pueden empezar tan pronto como est completo el modelo de requisitos. La definicin detallada de los casos de prueba puede empezar tan pronto como el modelo de diseo se ha consolidado. El principio de Pareto es aplicable a la prueba del software . El principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los mdulos del programa. El problema, por supuesto, es aislar estos mdulos sospechosos y probarlos concienzudamente. Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande. Las primeras pruebas planeadas y ejecutadas se centran generalmente en mdulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de mdulos y finalmente en el sistema entero. No son posibles las pruebas exhaustivas. El nmero de permutaciones de caminos para incluso un programa de tamao moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lgica del programa y asegurarse de que se han aplicado todas las condiciones en el diseo a nivel de componente. Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo independiente. Por ms eficaces queremos referirnos a pruebas con la ms alta probabilidad de encontrar errores (el objetivo principal de las pruebas). El ingeniero del software que cre el sistema no es el ms adecuado para llevar a cabo las pruebas para el software.
41
DISEO DE CASOS DE PRUEBA
El diseo de pruebas para el software o para otros productos de ingeniera puede requerir tanto esfuerzo como el propio diseo inicial del producto. Sin embargo, los ingenieros del software, a menudo tratan las pruebas como algo sin importancia, desarrollando casos de prueba que parezcan adecuados, pero que tienen poca garanta de ser completos. Recordando el objetivo de las pruebas, debemos disear pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo posible.
1. Prueba de caja blanca La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lgicos del software proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado o mencionado. La prueba de caja blanca, denominada a veces prueba de caja de cristal es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba. Mediante los mtodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que: 1) garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo; 2) ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa; 3) ejecuten todos los bucles en sus lmites y con sus lmites operacionales; y 4) ejerciten las estructuras internas de datos para asegurar su validez.
2. Prueba del camino bsico La prueba del camino bsico es una tcnica de prueba de caja blanca propuesta inicialmente por Tom McCabe. El mtodo del camino bsico permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba obtenidos del conjunto bsico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.
42
3. Prueba de la estructura de control La tcnica de prueba del camino bsico es una de las muchas tcnicas para la prueba de la estructura de control. Aunque la prueba del camino bsico es sencilla y altamente efectiva, no es suficiente por s sola.
4. Prueba de condicin La prueba de condicin es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. Una condicin simple es una variable lgica o una expresin relacional, posiblemente precedida con un operador NOT (c-D). Una expresin relacional toma la siguiente forma: E, < operador-relacional> E, Donde E, y E, son expresiones aritmticas y <operador-relacional> puede ser alguno de los siguientes: <, <=, =, # (a= desigualdad), K>D, o >=. Una condicin compuesta est formada por dos o ms condiciones simples, operadores lgicos y parntesis. Suponemos que los operadores lgicos permitidos en una condicin compuesta incluyen OR (I), AND (&) y NOT (c-B). A una condicin sin expresiones relacionales se la denomina Expresin lgica. Por tanto, los tipos posibles de componentes en una condicin pueden ser: un operador lgico, una variable lgica, un par de parntesis lgicos (que rodean a una condicin simple o compuesta), un operador relacional o una expresin aritmtica.
Si una condicin es incorrecta, entonces es incorrecto al menos un componente de la condicin. As, los tipos de errores de una condicin pueden ser los siguientes: error en operador lgico (existencia de operadores lgicos incorrectos / desaparecidos / sobrantes) error en variable lgica error en parntesis lgico error en operador relacional error en expresin aritmtica.
43
La prueba de ramificaciones es, posiblemente, la estrategia de prueba de condiciones ms sencilla. Para una condicin compuesta C, es necesario ejecutar al menos una vez las ramas verdadera y falsa de C y cada condicin simple de C. La prueba del dominio requiere la realizacin de tres o cuatro pruebas para una expresin relacional. Para una expresin relacional de la forma E, <operador-relacional> E, Se requieren tres pruebas, para comprobar que el valor de E, es mayor, igual o menor que el valor de E, respectivamente.
5. Prueba del flujo de datos El mtodo de prueba de flujo de datos selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa.
6. Prueba de bucles La prueba de bucles es una tcnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles: Bucles simples. A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el nmero mximo de pasos permitidos por el bucle: 1. 2. 3. 4. 5. pasar por alto totalmente el bucle pasar una sola vez por el bucle pasar dos veces por el bucle hacer m pasos por el bucle con m < n hacer n - 1, n y n+1 pasos por el bucle
44
Bucles anidados. Si extendiramos el enfoque de prueba de los bucles simples a los bucles anidados, el nmero de posibles pruebas aumentara geomtricamente a medida que aumenta el nivel de anidamiento. Esto llevara a un nmero impracticable de pruebas. Beizer sugiere un enfoque que ayuda a reducir el nmero de pruebas: 1. Comenzar por el bucle ms interior. Establecer o configurar los dems bucles con sus valores mnimos. 2. Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los parmetros de iteracin (por ejemplo, contador del bucle) de los bucles externos en sus valores mnimos. Aadir otras pruebas para valores fuera de rango o excluidos. 3. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores tpicos. 4. Continuar hasta que se hayan probado todos los bucles.
Bucles concatenados. Los bucles concatenados se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto. Sin embargo, si hay dos bucles concatenados y se usa el controlador del bucle 1 como valor inicial del bucle 2, entonces los bucles no son independientes. Cuando los bucles no son independientes, se recomienda usar el enfoque aplicado para los bucles anidados. Bucles no estructurados. Siempre que sea posible, esta clase de bucles se deben redisear para que se ajusten a las construcciones de programacin estructurada.
45
7. Prueba de caja negra 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. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, as como que la integridad de la informacin externa (por ejemplo, archivos de datos) se mantiene. Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lgica interna del software. Las pruebas de caja negra, tambin denominada prueba de comportamiento, se centran en los requisitos funcionales del software. O sea, la prueba de caja negra permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. La prueba de caja negra no es una alternativa a las tcnicas de prueba de caja blanca. Ms bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los mtodos de caja blanca. La prueba de caja negra intenta encontrar errores de las siguientes categoras: 1) 2) 3) 4) 5) funciones incorrectas o ausentes, errores de interfaz, errores en estructuras de datos o en accesos a bases de datos externas, errores de rendimiento y errores de inicializacin y de terminacin.
Mediante las tcnicas de prueba de caja negra se obtiene un conjunto de casos de prueba que satisfacen los siguientes criterios: 1) casos de prueba que reducen, en un coeficiente que es mayor que uno, el nmero de casos de prueba adicionales que se deben disear para alcanzar una prueba razonable y 2) casos de prueba que nos dicen algo sobre la presencia o ausencia de clases de errores en lugar de errores asociados solamente con la prueba que estamos realizando.
46
A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de caja negra tiende a aplicarse durante fases posteriores de la prueba. Ya que la prueba de caja negra ignora intencionadamente la estructura de control, centra su atencin en el campo de la informacin.
Prueba de entornos especializados, arquitecturas y aplicaciones
8. Prueba de interfaces grficas de usuario (igus) Debido a los componentes reutilizables provistos como parte de los entornos de desarrollo de las GUI, la creacin de la interfaz de usuario se ha convertido en menos costosa en tiempo y ms exacta. Al mismo tiempo, la complejidad de las IGUs ha aumentado, originando ms dificultad en el diseo y ejecucin de los casos de prueba. Dado que las IGUs modernas tienen la misma apariencia y filosofa, se pueden obtener una serie de pruebas estndar. Los grafos de modelado de estado finito pueden ser utilizados para realizar pruebas que vayan dirigidas sobre datos especficos y programas objeto que sean relevantes para las IGUs.
9. Prueba de arquitectura cliente/servidor La naturaleza distribuida de los entornos cliente/servidor, los aspectos de rendimiento asociados con el proceso de transacciones, la presencia potencial de diferentes plataformas hardware, las complejidades de las comunicaciones de red, la necesidad de servir a mltiples clientes desde una base de datos centralizada (o en algunos casos, distribuida) y los requisitos de coordinacin impuestos al servidor se combinan todos para hacer las pruebas de la arquitectura C/S y el software residente en ellas, considerablemente ms difciles que la prueba de aplicaciones individuales. De hecho, estudios recientes sobre la industria indican un significativo aumento en el tiempo invertido y los costos de las pruebas cuando se desarrollan entornos C/S.
La prueba de la documentacin se puede enfocar en dos fases. La primera fase, la revisin e inspeccin, examina el documento para comprobar la claridad editorial. La segunda fase, la prueba en vivo, utiliza la documentacin junto al uso del programa real.
47
10. Prueba de la documentacin y facilidades de ayuda Los errores en la documentacin pueden ser tan destructivos para la aceptacin del programa, como los errores en los datos o en el cdigo fuente. Nada es ms frustrante que seguir fielmente el manual de usuario y obtener resultados o comportamientos que no coinciden con los anticipados por el documento.
11. Prueba de sistemas de tiempo-real El responsable del diseo de casos de prueba no slo tiene que considerar los casos de prueba de caja blanca y de caja negra, sino tambin el tratamiento de sucesos (por ejemplo, procesamiento de interrupciones), la temporizacin de los datos y el paralelismo de las tareas (procesos) que manejan los datos. En muchas situaciones, los datos de prueba proporcionados al sistema de tiempo real cuando se encuentra en un determinado estado darn un proceso correcto, mientras que al proporcionrselos en otro estado llevarn a un error. Estrategia de prueba de sistemas de tiempo real en cuatro pasos: Prueba de tareas. El primer paso de la prueba de sistemas de tiempo real consiste en probar cada tarea independientemente. Es decir, se disean pruebas de caja blanca y de caja negra y se ejecutan para cada tarea. Prueba de comportamiento. Utilizando modelos del sistema creados con herramientas CASE, es posible simular el comportamiento del sistema en tiempo real y examinar su comportamiento como consecuencia de sucesos externos. Prueba intertareas. Una vez que se han aislado los errores en las tareas individuales y en el comportamiento del sistema, la prueba se dirige hacia los errores relativos al tiempo. Se prueban las tareas asncronas que se sabe que comunican con otras, con diferentes tasas de datos y cargas de proceso para determinar si se producen errores de sincronismo entre las tareas. Adems, se prueban las tareas que se comunican mediante colas de mensajes o almacenes de datos, para detectar errores en el tamao de esas reas de almacenamiento de datos. Prueba del sistema. El software y el hardware estn integrados, por lo que se lleva a cabo una serie de pruebas completas del sistema para intentar descubrir errores en la interfaz software hardware.
HERRAMIENTAS O ESTRATEGIAS DE PRUEBA DEL SOFTWARE
Una estrategia de prueba del software integra las tcnicas de diseo de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construccin del software. La estrategia proporciona un mapa que describe los pasos que hay que llevar a cabo como parte de la prueba, cundo se deben planificar y realizar esos pasos, y cunto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier estrategia de prueba debe incorporar la planificacin de la prueba, el diseo
48
de casos de prueba, la ejecucin de las pruebas y la agrupacin y evaluacin de los datos resultantes. Una estrategia de prueba del software debe ser suficientemente flexible para promover la creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes sistemas basados en software. Al mismo tiempo, la estrategia debe ser suficientemente rgida para promover un seguimiento razonable de la planificacin y la gestin a medida que progresa el proyecto. Estas filosofas y enfoques constituyen lo que nosotros llamaremos estrategia.
Un enfoque estratgico para las pruebas del software Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemticamente. Por esta razn, se debe definir en el proceso de la ingeniera del software una plantilla para las pruebas del software: un conjunto de pasos en los que podamos situar los mtodos especficos de diseo de casos de prueba.
A). Verificacin y validacin La prueba del software es un elemento de un tema ms amplio que, a menudo, es conocido como verificacin y validacin (VSrV). La verificacin se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. La validacin se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.
Verificacin: Estamos construyendo el producto correcto? Validacin: Estamos construyendo el producto correcto?
B). Organizacin para las pruebas del software Desde un punto de vista psicolgico, el anlisis y el diseo del software (junto con la codificacin) son tareas constructivas. El ingeniero del software crea un programa de computadora, su documentacin y sus estructuras de datos asociadas. Cuando comienza la prueba, aparece una sutil, aunque firme intencin de <<romper>> lo que el ingeniero del software ha construido. Desde el punto de vista del constructor, la prueba se puede considerar (psicolgicamente)
49
destructiva. Por tanto, el constructor anda con cuidado, diseando y ejecutando pruebas que demuestren que el programa funciona, en lugar de detectar errores. Desgraciadamente, los errores seguirn estando. Y si el ingeniero del software no los encuentra, el cliente si lo har.
C). Criterios para completar la prueba La prueba nunca termina, ya que el responsable del desarrollo del software carga o pasa el problema al cliente. Cada vez que el cliente/usuario ejecuta un programa de computadora, dicho programa se est probando con un nuevo conjunto de datos.
12. Prueba de unidad La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del software: el componente software o mdulo.
A). Consideraciones sobre la prueba de unidad Se prueba la interfaz del mdulo para asegurar que la informacin fluye de forma adecuada hacia y desde la unidad de programa que est siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante todos los pasos de ejecucin del algoritmo. Se prueban las condiciones lmite para asegurar que el mdulo funciona correctamente en los lmites establecidos como restricciones de procesamiento. Se ejercitan todos los caminos independientes (caminos bsicos) de la estructura de control con el fin de asegurar que todas las sentencias del mdulo se ejecutan por lo menos una vez. 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 mdulo. Si los datos no entran correctamente, todas las dems pruebas no tienen sentido. Adems de las estructuras de datos locales, durante la prueba de unidad se debe comprobar (en la medida de lo posible) el impacto de los datos globales sobre el mdulo. Entre los errores ms comunes en los clculos estn: 1) precedencia aritmtica incorrecta o mal interpretada; 2) operaciones de modo mezcladas; 3) inicializaciones incorrectas;
50
4) falta de precisin; 5) incorrecta representacin simblica de una expresin. Las comparaciones y el flujo de control estn fuertemente emparejadas (por ejemplo, el flujo de control cambia frecuentemente tras una comparacin). Los casos de prueba deben descubrir errores como: 1) 2) 3) 4) 5) 6) 7) comparaciones ente tipos de datos distintos; operadores lgicos o de precedencia incorrectos; igualdad esperada cuando los errores de precisin la hacen poco probable; variables o comparaciones incorrectas; terminacin de bucles inapropiada o inexistente; fallo de salida cuando se encuentra una iteracin divergente, y variables de bucles modificadas de forma inapropiada.
13. Prueba de integracin La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es coger los mdulos probados mediante la prueba de unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. A menudo hay una tendencia a intentar una integracin no incremental; decir, a construir el programa mediante un enfoque de (Cbig bang. combinan todos los mdulos por anticipado. Se prueba todo el programa conjunto. Normalmente se llega al caos! Se encuentran un gran conjunto errores. es Se en de
A). Integracin descendente La prueba de integracin descendente es un planteamiento incremental a la construccin de la estructura de programas. Se integran los mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal (programa principal). Los mdulos subordinados (subordinados de cualquier modo) al mdulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura.
51
La integracin incremental es la anttesis del enfoque del big bang. El programa se construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar y de corregir, es ms probable que se puedan probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemtica.
El proceso de integracin se realiza en una serie de cinco pasos: 1) Se usa el mdulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los mdulos directamente subordinados al mdulo de control principal. 2) Dependiendo del enfoque de integracin elegido (es decir, primero-enprofundidad o primero-en-anchura) se van sustituyendo uno a uno los resguardos subordinados por los mdulos reales. 3) Se llevan a cabo pruebas cada vez que se integra un nuevo mdulo. 4) Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el mdulo real. 5) Se hace la prueba de regresin para asegurarse de que no se han introducido errores nuevos. El proceso contina desde el paso 2 hasta que se haya construido la estructura del programa entero.
B). Integracin ascendente La prueba de la integracin ascendente, como su nombre indica, empieza la construccin y la prueba con los mdulos atmicos (es decir, mdulos de los niveles ms bajos de la estructura del programa). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados siempre est disponible y se elimina la necesidad de resguardos. Se puede implementar una estrategia de integracin ascendente mediante los siguientes pasos: 1. Se combinan los mdulos de bajo nivel en grupos (a veces denominados construcciones) que realicen una subfunsin especfica del software. 2. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba. 3. Se prueba el grupo. 4. Se eliminan los controladores y se combinan los grupos movindose hacia arriba por la estructura del programa.
14. Prueba de regresin La prueba de regresin 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.
52
15. Prueba de humo La prueba de humo es un mtodo de prueba de integracin que es comnmente utilizada cuando se ha desarrollado un producto software empaquetado. Es diseado como un mecanismo para proyectos crticos por tiempo, permitiendo que el equipo de software valore su proyecto sobre una base slida. En esencia, la prueba de humo comprende las siguientes actividades: 1) Los componentes software que han sido traducidos a cdigo se integran en una construccin. Una construccin incluye ficheros de datos, libreras, mdulos reutilizables y componentes de ingeniera que se requieren para implementar una o ms funciones del producto. 2) Se disea una serie de pruebas para descubrir errores que impiden a la construccin realizar su funcin adecuadamente. El objetivo ser descubrir errores bloqueantes que tengan la mayor probabilidad de impedir al proyecto de software el cumplimiento de su planificacin. 3) Es habitual en la prueba de humo que la construccin se integre con otras construcciones y que se aplica una prueba de humo al producto completo (en su forma actual). La integracin puede hacerse bien de forma descendente (top-down) o ascendente (bottom-up).
16. Prueba de validacin Tras la culminacin de la prueba de integracin, el software est completamente ensamblado como un paquete, se han encontrado y corregido los errores de interfaz y puede comenzar una serie final de pruebas del software: La prueba de validacin. La validacin puede definirse de muchas formas, pero una simple (aunque vulgar) definicin es que la validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente.
17. Revisin de la configuracin Un elemento importante del proceso de validacin es la revisin de la configuracin. La intencin de la revisin es asegurarse de que todos los elementos de la configuracin del software se han desarrollado apropiadamente, se han catalogado y estn suficientemente detallados para soportar la fase de mantenimiento durante el ciclo de vida del software. La revisin de la configuracin, a veces denominada auditora.
53
18. 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 y registrando los errores y los problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador. Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y as prepara una versin del producto de software para toda la clase de clientes.
19. Prueba del sistema La prueba del sistema, realmente, est constituida por una serie de pruebas diferentes cuyo propsito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propsito diferente, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
La prueba de recuperacin es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la recuperacin es automtica (llevada a cabo por el propio sistema) hay que evaluar la correccin de la inicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de datos y del proceso de arranque. Si la recuperacin requiere la intervencin humana, hay que evaluar los tiempos medios de reparacin (TMR) para determinar si estn dentro de unos lmites aceptables.
54
20. Prueba de recuperacin Muchos sistemas basados en computadora deben recuperarse de los fallos y continuar el proceso en un tiempo previamente especificado. En algunos casos, un sistema debe ser tolerante con los fallos; es decir, los fallos del proceso no deben hacer que cese el funcionamiento de todo el sistema.
21. Prueba de seguridad La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern, de hecho, de accesos impropios. Durante la prueba de seguridad, el responsable de la prueba desempea el papel de un individuo que desea entrar en el sistema. Todo vale! Debe intentar conseguir las claves de acceso por cualquier medio, puede atacar al sistema con software a medida, diseado para romper cualquier defensa que se haya construido, debe bloquear el sistema, negando as el servicio a otras personas, debe producir a propsito errores del sistema, intentando acceder durante la recuperacin o debe curiosear en los datos sin proteccin, intentando encontrar la clave de acceso al sistema, etc.
22. Prueba de resistencia (STRESS) Las pruebas de resistencia estn diseadas para enfrentar a los programas con situaciones anormales. La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo: 1) disear pruebas especiales que generen diez interrupciones por segundo, cuando las normales son una o dos; 2) incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo responden las funciones de entrada; 3) ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos; 4) disear casos de prueba que puedan dar problemas en un sistema operativo virtual o 5) disear casos de prueba que produzcan excesivas bsquedas de datos residentes en disco. Esencialmente, el responsable de la prueba intenta romper el programa. Una variante de la prueba de resistencia es una tcnica denominada prueba de sensibilidad. La prueba de sensibilidad intenta descubrir combinaciones de datos dentro de una clase de entrada vlida que pueda producir inestabilidad o un proceso incorrecto.
23. Prueba de rendimiento La prueba de rendimiento est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proceso de la prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los mdulos individuales a medida que se llevan a cabo las pruebas de caja
55
blanca. Sin embargo, hasta que no estn completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema. Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de resistencia y, frecuentemente, requieren instrumentacin tanto de software como de hardware. Es decir, muchas veces es necesario medir la utilizacin de recursos (por ejemplo, ciclos de procesador), de un modo exacto. La instrumentacin externa puede monitorizar los intervalos de ejecucin, los sucesos ocurridos (por ejemplo, interrupciones) y muestras de los estados de la mquina en un funcionamiento normal. Instrumentando un sistema, el encargado de la prueba puede descubrir situaciones que lleven a degradaciones y posibles fallos del sistema.
EL ARTE DE LA DEPURACIN
La depuracin ocurre como consecuencia de una prueba efectiva. Es decir, cuando un caso de prueba descubre un error, la depuracin es el proceso que provoca la eliminacin del error. Aunque la depuracin puede y debe ser un proceso ordenado, sigue teniendo mucho de arte. Un ingeniero del software, al evaluar los resultados de una prueba, se encuentra frecuentemente con una indicacin sintomtica de un problema en el software. Es decir, la manifestacin externa de un error, y la causa interna del error pueden no estar relacionadas de una forma obvia. El proceso mental, apenas comprendido, que conecta un sntoma con una causa es la depuracin.
56
PLAN DE PRUEBAS
Propsito El propsito del plan de Pruebas es recopilar la informacin necesaria para planificar y controlar el esfuerzo de pruebas para el proyecto. Describe cmo se probar el software. Alcance Los niveles de testing sern por pruebas unitarias y por pruebas de integracin. Los tipos de test incluidos en el plan son de integridad de datos, funcionalidad, interfaz de usuario, performance, seguridad y control de acceso, falla y recuperacin. No se incluye testing de configuracin ni instalacin, ni de ciclos de negocio.
Tcnicas y Tipos de Testing
Test de integridad de base de datos y datos La base de datos y los procesos de base de datos se prueban como un subsistema dentro del proyecto. Objetivo: Asegurar que los mtodos de acceso y los procesos de la base de datos, funcionen correctamente y que no generen corrupcin de informacin. Alimentar y consultar la base de datos con datos vlidos e invlidos. Inspeccionar la base de datos para asegurar que los datos han sido cargados como se pretenda, todos los eventos ocurrieron correctamente, o que la informacin fue recabada correctamente Scripts de carga de informacin Herramientas para backup y restore de la base de datos Utilidades para ejecutar scripts SQL Herramientas de generacin de informacin Todos los mtodos de acceso a datos y los procesos funcionan como fueron diseados y sin corrupcin de informacin
Tcnica:
Herramientas:
Criterio de xito:
57
Consideraciones especiales: Puede requerirse un entorno de desarrollo que permita el acceso directo a la base de datos para poder modificar los datos directamente. Debe utilizarse una cantidad mnima o pequea de datos para incrementar la visibilidad de cualquier evento no aceptable. El ambiente de testing debe ser lo ms parecido posible al de produccin.
Test de funcionalidad El test de funcionalidad verifica la correcta aceptacin de los datos por la aplicacin, su procesamiento, acceso, bsqueda y la apropiada implementacin de los requerimientos, utilizando datos vlidos e invlidos para la aplicacin que se est testeando. El testeo funcional se har nicamente para los Casos de Uso identificados como de alta criticidad para el flujo de negocio y de alto riesgo para el xito del desarrollo.
Objetivo:
Tcnica:
Asegurar la correcta funcionalidad de la aplicacin, incluyendo la navegacin, la entrada de datos, el procesamiento, la consulta de informacin, la actualizacin y la bsqueda. Ejecutar cada escenario de los casos de uso que incluyan una funcin crtica y de alto riesgo en el flujo de negocio, utilizando datos vlidos y no vlidos, verificando lo siguiente: Se obtienen los datos esperados cuando se ingresan datos vlidos Se muestran los mensajes de error adecuados cuando se ingresa datos no vlidos. Cada regla de negocio se aplica adecuadamente.
Herramientas: Criterio de xito:
Casos de uso, Reglas de negocio, Requerimientos funcionales. Todos los test han corrido con xito. Todos los defectos detectados fueron resueltos o fueron suspendidos de acuerdo a lo especificado por el cliente. Se cuenta con los datos necesarios para testear
Consideraciones especiales:
58
Test de Interfaz de Usuario
El Test de Interfaz de Usuario (UI) verifica la interaccin del usuario con el software. El objetivo de este test es asegurar que la UI provee el acceso y navegacin apropiados a travs de las funciones del objetivo del test. Adems, el Test de UI asegura que los objetos grficos funcionan como se esperaba y se ajusten a la conformidad del PMP o los estndares de la industria.
Objetivo:
Verificar que: La navegacin a travs de las aplicaciones reflejen las funciones pedidas por el usuario en la captura de los requerimientos, incluyendo la navegacin de ventana a ventana, de campo a campo, y la utilizacin de mtodos de acceso (teclas de tabulacin, movimientos del mouse, hoy keys). Los objetos de las ventanas y sus caractersticas puedan ser utilizados y funcionen con su correcto modo. La ortografa y la gramtica sea correcta (por lo menos en lo que respecta a la aplicacin en castellano).
Tcnica:
Crear o modificar las pruebas de cada ventana para verificar la correcta navegacin y el estado de los objetos grficos para cada aplicacin. Especificaciones Suplementarias GUI Imagen Conceptual: Prototipo Ejecutable
Herramientas:
Criterios de xito:
Las pruebas con la interfaz han salido satisfactorias y el usuario est satisfecho con las ventanas y la funcionalidad de los objetos de las mismas de ambas aplicaciones. No todas las propiedades de la GUI grfica utilizada pueden ser accedidas con facilidad y por cuestin de tiempo se dedicar mucha mayor importancia a la interfaz de la aplicacin Front, que la de la aplicacin Back.
59
Test de Seguridad y de Control de Acceso
Este test se enfoca en dos reas claves de la seguridad: Seguridad a nivel de aplicacin, como por ejemplo: el acceso a los datos o a las funciones del negocio Seguridad a nivel de sistema, como por ejemplo: el acceso restringido a los usuarios por medio de la ventana de login o no permitir que el aspirante, en caso de haber desaprobado el examen, pueda rendir nuevamente sino hasta transcurridos 3 meses desde aquella fecha de evaluacin.
Objetivo:
A nivel de Aplicacin: verificar que el usuario slo puede acceder a las funciones del Front para rendir el examen, que no tenga la posibilidad de acceder a las respuestas del examen que est rindiendo o va a rendir, de que no pueda acceder a los datos de usuario y que no tenga los permisos del administrador. A nivel de Sistema: Verificar que si el usuario o el administrador ingresaron mal el usuario y/o la clave, no puedan ingresar al sistema. Verificar que el aspirante que desaprob un examen no pueda rendir sino hasta transcurridos los 3 meses desde la fecha de evaluacin. A nivel de Aplicacin: Identificar y listar cada tipo de usuario y el tipo de funciones y datos a los que tiene permiso consultar, modificar o borrar. Se crearn casos de prueba para cada tipo de usuario y se probar que el usuario no puede acceder a ninguna funcionalidad o dato a los que no tenga permiso. A nivel de Sistema: Se probar ingresar con claves errneas, con usuarios errneos. Se probar ingresar con caracteres raros y con dems set de pruebas errneos e intencionalmente dainos. Tambin se reprobar un examen y se controlar que no se pueda rendir de nuevo si la diferencia de fechas es mayor a tres meses. Especificacin de los Casos de uso, donde se especifica qu puede y qu no puede hacer cada uno de los actores. La funcionalidad y permisos de cada usuario est correctamente implementada. Las pruebas fueron exitosas. Las pruebas de login fueron todas aceptadas. Diseo de interfaz de usuario
Tcnica:
Herramientas: Criterio de xito:
Special Considerations:
60
Test de Falla y Recuperacin
El test de Falla y Recuperacin asegura que los datos puedan recuperarse exitosamente tras alguna fallas de hardware o de software. Que los datos sean recuperados exitosamente significa que se pueden volver a consultar y modificar sin prdida de datos ni inconsistencias.
Objetivo:
Simular fallas y efectuar procesos de recuperacin para restaurar la base de datos, las aplicaciones y el sistema a un estado conocido y deseable. Se incluirn las siguientes pruebas: Interrupcin de energa en la aplicacin Front, mientras se estn llenando los datos o mientras se est rindiendo el examen Interrupcin de energa en la aplicacin Back, mientras se estn cargando las preguntas o se est publicando un examen Interrupcin, incomunicacin o apagado del servicio del SGBD, la base de datos Interrupcin de procesos: cierre de la aplicacin Front durante la rendicin de un examen, corte de la aplicacin Back mientras se estn cargando datos
Tcnica:
Para cada uno de los casos de prueba explicados en el Objetivo: Interrupcin de energa en la aplicacin Front y Back: se apagar la PC en la que la aplicacin se est ejecutando Interrupcin del servicio del SGBD: se simular o se eliminar fsicamente la comunicacin con el controlador de la base de datos Interrupcin de procesos: se probar de cerrar la aplicacin Front durante un examen, matando el proceso o con la cruz de cierre de la ventana de la GUI
Herramientas:
Backups Herramientas de monitoreo de registro, disco, CPU, memoria Herramientas de configuracin y/o de recuperacin de datos
61
Criterios de xito: Se considerarn aprobadas las pruebas de Falla y Recuperacin cuando se efecten los casos de prueba y se demuestre que no hubo corrupcin de datos, ni prdida. Con esto se asegurar que, tras una transaccin interrumpida, siempre se puede regresar al previo estado consistente. Las pruebas de fallas y recuperacin son altamente intrusivas. Los procedimientos que implican desconectar el cable de energa o apagar la PC pueden ser no deseables, sobre todo en los sistemas operativos modernos de hoy en da. En cuyo caso, se pueden utilizar mtodos alternativos, como el uso de una herramienta de diagnstico de software o similar. Para llevar a cabo estas pruebas son necesarios permisos de administrador sobre las PC y la base de datos que se vayan a llevar a cabo.
Test de Performance
El test de performance es una prueba de funcionamiento en que los tiempos de respuesta, las tasas de transaccin, y otros requerimientos no funcionales de performance se miden y evalan. El objetivo es verificar que los requisitos de rendimiento se han logrado; por ejemplo, que el procesamiento de resultado del examen y clculo de respuestas correctas no sea mayor a cinco segundos (requerimiento no funcional). El test de performance es implementado y ejecutado en funcin de las condiciones de trabajo como por ejemplo la configuracin y velocidad del hardware.
Tcnica:
Se controlar que el tiempo de respuesta a cualquier accin no sea mayor de 2 segundos, con un rango de tolerancia de hasta 3 segundos. O sea, que cualquier accin no demorar ms de 2 a 5 segundos.
62
Objetivo:
El objetivo de las pruebas de performance es demostrar que las funciones del sistema estn alineadas con los requerimientos de performance pedidos por el cliente y cumpla con especificaciones estndares de tiempos de respuesta aceptables.
Herramientas: Especificacin de los Casos de Uso Script de carga de datos (para probar performance con una cantidad considerable) Alguna herramienta de monitoreo de registro, disco rgido, CPU, memoria Ninguna accin superar los cinco segundos de respuesta, siendo preferible, en caso de contar con el tiempo suficiente, optimizar aquellas que demoren ms de dos segundos. Por cuestiones de tiempo, no se harn pruebas masivas como de stress y de volumen, as que la idea es que este test se pruebe con una cantidad considerable, media, de datos cargados. El test de performance nos servir para conocer cul es el lmite de registros que puede soportar la base de datos y manejar bien la aplicacin.
Criterio de xito:
63
PRACTICA 3
Plan de Pruebas Se deber entregar el archivo Plan de Pruebas.xls, con toda la informacin de los casos de prueba, respecto a cuatro de los seis tipos de testing mencionados anteriormente especificando como casos de prueba al menos 6 casos de prueba por cada tipo de pruebas.
Entorno Necesario Software Base para el Entorno de Prueba La siguiente tabla indica como ejemplo el software base que se requiere para ejecutar el Plan de Prueba.
Software S.O. X Aplicacin 1 Aplicacin 2 Navegador (Internet Explorer, Firefox) Manejador de BD NetBeans y/o Eclipse
Versin Tipo de SW o Notas Adicionales XP SP2 o Sistema Operativo superior
Por si algn tester necesita tocar algn artefacto de cdigo, como un JUnit, y recompilar, o depurar, o ejecutar la aplicacin de un modo especial
Roles La siguiente tabla especifica como ejemplo los roles y las actividades que debern de realizar
Rol
Responsabilidad Especfica o Comentarios
64
Rol Responsabilidad Especfica o Comentarios Implementa y ejecuta las pruebas. Sus responsabilidades incluyen: Tester Aplicar las pruebas Ejecutar los casos de pruebas Registrar los resultados Analizar y recuperar pruebas fallidas Documentar incidentes
1. Investigar herramientas (3) para ejecutar o simular casos de prueba
Herramienta
Definicin/Concepto/Caractersticas
Plan de pruebas
65
Unidad IV. Liberacin del software

Objetivo de la Unidad El alumno elaborar la documentacin tcnica y el paquete de instalacin para la liberacin del software. Temas de la Unidad: Manual tcnico: Informacin del Sistema (Acerca del software) Ambiente de desarrollo Diagrama de despliegue de la aplicacin Requisitos Configuracin Sistema Mapa de navegacin del sistema Subsistema de seguridad del sistema Mantenimiento Diagrama de clases de la estructura del Sistema Diccionario de Datos Propuesta para agregar nuevos mdulos al Sistema (Futuro) Anexos Gua de estilos Normativa de desarrollo (estndares de codificacin y nombrado de variables y archivos) Documentacin tcnica (cdigo de la base de datos y de la aplicacin de escritorio) Manual de usuario: - Acerca de este manual - Documentacin adicional - Recursos adicionales - Soporte tcnico - Comentarios Captulo I. Bienvenido al sistema Informacin acerca del sistema Puntos destacados del sistema Requisitos del sistema Instalacin Captulo II. Captulo III. Captulo N. NOTA: se deber presentar informacin de acerca del funcionamiento detallado de todo el sistema, y los captulos se organizarn con base a la pantalla principal.
66
Manual de instalacin: Introduccin. Requerimientos tcnicos Proceso de instalacin Proceso de respaldos Proceso de desinstalacin Rbrica IV
67

Manual de Asignatura Ing-Sw II

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Manual de Asignatura Ing-Sw II

Transféré par

Droits d'auteur :

Formats disponibles

Ingeniera de software II

Presenta: Gloria del C. Crdoba Hernndez

Diseo de interfaz de usuario

Unidad I. Diseo de interfaz de Usuario

Diseo de interfaz de usuario

Toda la industria funciona con estndares Ejemplo: Construccin

Tipos de estndares Estndares de iure Estndares de facto

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Ejemplo de Apple (1985)

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Guas de estilo para la WEB

Diseo de interfaz de usuario

Diseo de interfaz de usuario

NATIONAL CANCER INSTITUTE

Diseo de interfaz de usuario

Practica II Rbrica de evaluacin

Diseo de interfaz de usuario

Unidad II. Documentacin en la etapa de codificacin

ELEMENTOS DE LOS DIAGRAMAS DE:

Elementos de los diagramas de: Componentes Implementacin despliegue actividad

Es el lazo de unin entre varios componentes, donde C es el nombre de la Interfaz:

Las interfaces pueden representarse de varias formas, como vemos en la grfica:

Adems se pueden representar de dos maneras: forma icnica y expandida

Con Diagrama de Despliegue

Diseo de interfaz de usuario

Relacin con otros diagramas

Mtodo de la clase pesan a ser mdulos Mdulos pasan a ser componentes.

Diseo de interfaz de usuario

Relacin con diagrama de clases:

Esquema del diagrama de despliegue

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Objetos salen de una actividad (cambia de estado)

Objetos entran de una actividad (lectura de estado)

Conclusiones del diagrama de actividades:

3. Espacios y lneas en blanco

Diseo de interfaz de usuario

Diseo de interfaz de usuario

MIN_WIDTH LOCAL_CONSTANT COLUMNS

LocalConstant MIN_WIDTH LOCAL_CONSTANT MinWidth Colums

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Estilo de programacin Rbrica

Diseo de interfaz de usuario

Unidad III. Pruebas de software

FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE.

Objetivos de las pruebas:

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

Diseo de interfaz de usuario

HERRAMIENTAS O ESTRATEGIAS DE PRUEBA DEL SOFTWARE

Diseo de interfaz de usuario