GUIA PASO A PASO PARA EL USUARIO

MAPA CONCEPTUAL PRUEBA DEL SOFTWARE

LOGO PROYECTO (PAGINA WEB MATEMATICAS SEGUNDO DE PRIMARIA)

DIAGRAMA DE OBJETOS (PROYECTO)

DISEÑO DE INTERFAZ DE ENTRADA Y DE SALIDA

ENTRADA

SALIDA

DIAGRAMA DE CLASES (PROYECTO)

MANTENIMIENTO DE SOFTWARE

El mantenimiento de software o manutención de software es una de las actividades más comunes en la ingenieria de software, es el proceso de mejora y optimización del software después de su entrega al usuario final (es decir; revisión del programa), así como también correccion y prevención de los defectos.
El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas (SDLC, sigla en inglés de system development life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.

El mantenimiento del software es la totalidad de las actividades necesarias para proporcionar soporte económico (cost-effective) al sistema software. Estas actividades se desarrollan tanto antes como después de la entrega. Las actividades previas a la entrega incluyen la planificación de las operaciones posteriores a la entrega, planificación del soporte y determinación de la logística. Las actividades posteriores a la entrega incluyen la modificación del software, la formación de usuarios, y la operación de un help desk.

Como se ve, hay una diferenciación en las diferentes definiciones entre actividades pre- y post- entrega del software. Para clarificar los conceptos, en esta obra diferenciaremos entre:

1. actividades de mantenimiento propiamente dichas (posteriores a la entrega) y
2. actividades de preparación para el mantenimiento.

El criterio para diferenciarlo de otras actividades es el hecho de la entrega del producto software. Se debe tener en cuenta que en ocasiones esa entrega es un acto formal dentro de un contrato, pero en muchas otras es una simple decisión de disponibilidad pública de un grupo de desarrollo. Por ejemplo, en los proyectos de fuente abierto, desarrollados de manera voluntaria, el qué es una entrega lo determinan los propios desarrolladores cuando piensan que la funcionalidad implementada ha llegado a un determinado nivel.

La guía SWEBOK2 considera que el mantenimiento ocurre durante todo el ciclo de vida, y coincide en su definición con la de Pigoski antes mencionada.

Es importante resaltar que el concepto de mantenimiento del software difiere de la concepción de mantenimiento en otras disciplinas de ingeniería. Esto es debido a que el software no se “deteriora” con el uso. En la ingeniería mecánica, el mantenimiento consiste en las acciones de reparación necesarias para que la máquina o sistema mecánico siga funcionando. En la Ingeniería del Software, el mantenimiento tiene un significado más amplio, cubriendo su adaptación a necesidades

EVALUACION DEL SISTEMA

Se lleva a cabo para identificar puntos debiles y fuertes del sistema implantado.La evaluacion ocurre a lo largo de cualquiera de las siguiente cuatro dimenciones:

1.EVALUACION OPERACIONAL:
    Es el momento en que se evalua la manera en que funciona el sistema, si esto incluye su facilidad de uso, tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que se presenta la informacion, contabilidad global y su nivel de utilidad.
2. IMPACTO ORGANIZACIONAL:
Identifica y mide los beneficios operacionales para la empresa en areastales como finanzas (costos, ingresos y ganancias), eficiencia en el desempeño laboral e impacto competitivo, impacto, rapidez y organizacion en el flujo de informacion interna y externa.
3. DESEMPEÑO DEL DESARROLLO:
Es la evaluacion delproceso de desarrollo adecuado tomando en cuenta ciertos criterios como, tiempo y esfuerzo en el desarrollo concuerden con presupuestos y estandares y otros criterios de administracion de proyectos. Ademas se incluye la valoracion de los metodos y herramientas utilizados durante el desarrollo del sistema.

CAPACITACION DE USUARIOS DEL SISTEMA

Es enseñar a los usuarios que se relacionan u operan en un proceso de implantación.
La Responsabilidad de esta capacitación de los Usuarios primarios y secundarios es del Analista, desde el personal de captura de datos hasta aquellos que toman las decisiones sin usar una Computadora. No se debe incluir a personas de diferentes niveles de habilidad e intereses de trabajo; debido a que si en una Empresa existen trabajadores inexpertos no se pueden incluir en la misma sección de los expertos ya que ambos grupos quedaran perdidos.

Aun y cuando la Empresa puede contratar los Servicios de Instructores externos, el analista es la persona que puede ofrecer la mejor capacitación debido a que conoce el personal y al Sistema mejor que cualquier otro. A la falta o imposibilidad del analista la organización puede contratar otros servicios de capacitación como son:

• Vendedores: Son aquellos que proporcionan capacitación gratuita fuera de la Empresa de uno o dos días.

• Instructor pagado externamente: Son aquellos que pueden enseñar todo acerca de las  computadoras pero para algunos usuarios esta no es una capacitación necesaria.

• Instructores en casa: Están familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero le faltaría experiencia en Sistemas de Información que es realmente la necesidad del usuario. 

DEFINICION DE IMPLANTACION, ENFOQUES DE IMPLEMENTACION

IMPLANTACION: Es la ultima fase del desarrollo del sistema. Es el proceso instalar equipos o software nuevo, como resultado de un analisis y deseño previo como resultado de la sustitucion o mejoramiento de la forma de llevar a cavo un proceso automatizado.
Al implantar un sistema de informacion lo primero que debemos hacer es asegurarnos que el sistema sea operacional o sea que funcione de acuerdo a los requeriminetos del analisis y permitir que los usuarios puedan operarlo.

Existen varios enfoques de IMPLEMENTACION:
1. Es darle responsabilidad a los grupos.
2. Uso de diferentes estrategias para el entrenamiento de los usuarios.
3. El analisis de sistema necesita pondear la situacion y propone un plan de convercion que sea adecuado para la organizacion.
4. El analista necesita formular medidas de desempeño con las cuales evaluar a los usuarios.
5. Debe convertir fisicamente el sistema de informacion antiguo, al nuevo modificado.

¿CUÁLES SON LOS PASOS PARA LA EVALUACIÓN DEL DISEÑO?

El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación. Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un buen diseño como son:

• Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software.

• El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en elementos que realicen funciones y subfunciones especificas.

• Un diseño debe contener abstracciones de datos y procedimientos.

• Debe producir módulos que presenten características de funcionamiento independiente.

• Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior.

• Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software.

Estos criterios no se consiguen por casualidad. El proceso de Diseño del Software exige buena calidad a través de la aplicación de principios fundamentales de Diseño, Metodología sistemática y una revisión exhaustiva.

¿QUE DEBE REALIZAR UN ANALISTA PARA EL DISEÑO DE SALIDA?

Como analistas se debe realizar lo siguiente:
1. Determine que informacion presentar: decidir si la informacion sera presentada en forma visual, verbal o impresora y seleccionar elmedio de salida.
2. Disponga la presentacion de la informacion en un formato aceptable.
3. Decida como distribuir la salida entre los posibles destinatarios.

COHESION

La cohesion es una medida de la fuerza funcional relativa de un modulo, es decir, su interes es determinar que tan cercanamente relacionados estan los elementos de un modulo unos con otros, un modulo cohesivo realiza una sola tarea.
La cohesion determina si los diferentes elementos de un modulo deben estar juntos, la cohesion y  el acoplamiento estan relacionados, a mayor cohesion en los modulos habra menor acoplamiento entre modulos.

Niveles de cohesion:

• Coicidental.
• Logica.
• Temporal.
• Comunicacional.
• Secuencial.
• Funcional.

ATRIBUTOS DE CALIDAD A EVALUAR EN UN SISTEMA

Los principales atributos de calidad a evaluar en un sistema es que este sea:

1. CORRECTO.
2. EFICIENTE.
3.MANTENIBLE.
4.EFICIENTE EN COSTOS.

DISEÑO CLASICO (ACTIVIDADES)

El diseño clasico consta de 3 actividades:

1. El diseño de la arquitectura (diseño logico o diseño de alto nivel): El resultado de diseñar los modulos de un sistemas de software se le conoce como diseño de la arquitectura del sistema. El diseño de la arquitectura es el primer paso en el diseño, va seguido del diseño detallado y la fase de pruebas del diseño.
2. Diseño detallado(diseño logico o diseño de bajo nivel): Durantes esta fase, cada un de los modulos identificados durante el diseño de la arquitectura es especificado a detalle, incluyendo pseudocodigo representando los algoritmos, las estructuras de datos y los datos miembros.
3. Diseño de las pruebas: Sirve para verificar que los requerimientos se esten incluyendo conforme a las especificaciones. Las estructuras creadas durante el diseño de la arquitectura son un vehiculo importante para las pruebas del diseño, en las que se siguen los escenarios de los casos de uso en una simulacion del uso del sistema. Dichas pruebas son imposibles sin la representacion de los modulos y sus interrelaciones (acoplamiento).

DEFINICION DISEÑO DE SOFTWARE

El diseño es la fase del proceso de desarrollo de software "donde se crea una representacion o modelo del software. A diferencia del analisis donde se describen los datos y funciones requeridos, el modelo del diseño proporciona los detalles acerca de las estructuras de los datos, las arquitecturas, las interfaces y los componentes del software necesarios para implementar el sistema".
lenguaje intermedio entre los requerimientos y el  codigo.
pasa de representacion abstracta amas concreta.
actividad que inicia con un conjunto de requerimientos.
El diseño determina las principales caracteristicas de un sistema.
los documentos del diseño son la referencia para las siguientes fases

DIAGRAMA DE COMUNICACIÓN

DIAGRAMA DE COMUNICACIÓN

Un diagrama de Comunicaciones muestra las interacciones entre los elementos en tiempo de ejecución en forma semejante a un diagrama de Secuencia. No obstante, los diagramas de Comunicación se usan para visualizar relaciones inter-objetos, mientras que los diagramas de Secuencia son más efectivos para visualizar procesamiento a lo largo del tiempo.

Los diagramas de Comunicaciones emplean asociaciones ordenadas y etiquetadas para ilustrar el procesamiento. Es importante la numeración para indicar el orden y el anidamiento del procesamiento. Un esquema de numeración podría ser 1, 1.1, 1.1.1, 1.1.2, 1.2, etc. Comienza un nuevo segmento de números para una nueva capa de procesamiento, y sería equivalente a la invocación de un método.

DIAGRAMA GLOBAL DE INTERACCION

DIAGRAMA GLOBAL DE INTERACCION

Interacciones muestran la cooperación entre otros diagramas de interacción para reflejar el flujo de control que responde a un propósito abarcativo. Como los Diagramas de Descripción de las Interacciones son una variante de los diagramas de actividades, la mayor parte de la notación es similar, al igual que el proceso de construcción del diagrama. Los puntos de decisión, bifurcación, unión, puntos de inicio y final son los mismos. En lugar de actividades se usan elementos rectangulares. Hay dos tipos de estos elementos:

Los elementos de interacción muestran un diagrama de interacción en línea , el cual puede ser un diagrama de Secuencias, Comunicaciones, de Tiempos, o de Descripción de las Interacciones.

Los elementos de ocurrencia de interacción son referenciados a un diagrama de interacción existente. Ellos son visualmente representados por un marco, con ref en el espacio del título del marco. El nombre del diagrama está indicado en el contenido del marco .

Para crear una ocurrencia de interacción, simplemente arrastre un diagrama de interacción desde el Explorador del proyecto sobre su Diagrama de Revisión de las Interacciones. Aparecerá el marco ref, encapsulando una instancia del diagrama de interacción.

DIAGRAMA DE SECUENCIA

DIAGRAMA DE SECUENCIA

Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.

En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. Existen distintos tipos de mensajes según cómo se producen en el tiempo: simples, síncronos, y asíncronos.

Los diagrama de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición, que se especifica en el diagrama.

DIAGRAMA DE INTERACCION

Los diagramas de interacción

son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento. Habitualmente, un diagrama de interacción capta el comportamiento de un solo caso de uso. El diagrama muestra cierto número de ejem. plcs de objetos y los mensajes que se pasan entre estos objetos dentro

del caso de uso. ilustraré este enfoque mediante un caso de uso simple que exhibe el

comportamiento siguiente:

La ventana Entrada de pedido envía un mensaje "prepara" a Pedido.

El Pedido envía entonces un mensaje "prepara" a cada Línea de pedido dentro del Pedido.

Cada Línea de pedido revisa el Artículo de inventario correspondiente.

- Si esta revisión devuelve "verdadero", la Línea de pedido descuenta

la cantidad apropiada de Artículo de inventario del

almacén.

- Si no sucede así, quiere decir que la cantidad del Artículo de inventario ha caído más abajo del nivel de reorden y entonces dicho Artículo de inventario solicita una nueva entrega.

Hay dos tipos de d iagramas de interacción: diagramas de secuencia y

diagramas de colaboración.

El Diagrama de Interacción por Repaso es un diagrama variante de la actividad. En este diagrama las diferentes secuencias son incluidas en una actividad que fluyen en orden para mostrar el flujo de trabajo por las secuencias.

MAQUINA DE ESTADO

DIAGRAMA DE MAQUINA DE ESTADO

Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una interacción satisface una condición, desarrolla alguna acción o se encuentra esperando un evento.

Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transición. Como en todas las metodologías OO se envían mensajes, en este caso es la acción de la que puede enviar mensajes a uno o varios objetos destino.

DIAGRAMA DE CASOS DE USO

DIAGRAMA DE CASOS DE USO

Es una descripción de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, esta es una herramienta valiosa, ya que es una técnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que puede ser utilizado por la gente en general. En la siguiente grafica veremos un ejemplo de cuando usted utiliza una lavadora, obviamente para lavar ropa. Le muestra como representaría esto en un diagrama de casos de uso UML

Este tipode relación es uno de los mas utilizados, cumple una doble funsion dependiendo de su estereotipo, que puede ser de uso (<<user>>) o de herencia (<<extends>>). Este tpio de

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que
puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

DIAGRAMA DE ACTIVIDAD

DIAGRAMA DE COMPORTAMIENTO

Diagramas de Interacción o Comportamiento Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos:
Diagrama de secuencia.
Diagrama de colaboración.
Diagrama de estado.
Diagrama de actividad.

DIAGRAMA DE TIEMPOS

DIAGRAMA DE PAQUETES

DIAGRAMA DE OBJETOS

DIAGRAMA ESTRUCTURADA

DIAGRAMA DE ESTRUCTURA COMPUESTA

DIAGRAMA DE DESPLIEGE

DIAGRAMA DE COMPONENTES

DIAGRAMA DE CLASES

FORMATO ESPECIFICACION CASO DE USO (AUTOMATIZAR UN VIDEO CLUB)

ESPECIFICACIÓN DE CASO DE USO

NOMBRE DEL CASO DE USO	AUTOMATIZAR UN VIDEO CLUB
ACTOR	CLIENTE Y PROVEEDOR
FECHA	02-05-2011
PRECONDICIONES	El inventario debe estar actualizado a la fecha y hora antes de que se lleve a cabo el caso de uso.
OBJETIVO		Alquilar, devolver o reservar una película corroborando que este en el inventario

DESCRIPCION Permite adquirir, devolver o reservar alguna película.

  

FLUJO PRINCIPAL El cliente solicita el tipo de gestión que quiere realizar ya sea alquiler, reserva o devolución de una película. Si la opción es alquilar la película y existe no está alquilada por otro cliente se genera un comprobante y se aumentan las ventas. Si la opción es devolución  y el nombre del cliente y de la película son correctos se suma esta al stock. Cuando la opción es reserva el cliente proporciona su nombre y queda registrado. Si por lo contrario es proveedor se registra el catalogo y la generación de películas del proveedor.

FLUJO ALTERNO 1 Si el cliente elige la opción alquiler de película y la película no exite dentro del inventario o esta alquilada a otro cliente.

FLUJO ALTERNO 2 Si el cliente elige la opción devolución de una película y el nombre de la película o de cliente no coinciden.

POSCONDICIONES  El sistema ejecuta el tipo de gestión solicitada por el cliente desde el principio.

REGLAS DE NEGOCIO El proveedor lleva un control del inventario para de esta forma darse cuenta de faltas de películas solicitadas por el cliente. Los datos proporcionados por el cliente deben ser correctos.

COCLUSIONES Los casos de uso son de gran ayuda para entender y ejecutar una idea que en un principio parece compleja. Gracias a los casos de uso podremos ver un problema como el anterior mas ordenado y fácil de resolver y ejecutar

                       

PRACTICA CASOS DE USOS (AUTOMATIZAR UN VIDEOCLUB)

FORMATO ESPECIFICACIÓN CASO DE USO (Caja “Self checkout” de Wal-Mart)

ESPECIFICACIÓN DE CASO DE USO

NOMBRE DEL CASO DE USO	Caja “Self checkout” de Wal-Mart
ACTOR	Usuario, Caja, Supervisor.
PRECONDICIONES	La caja a nivel general debe estar funcionando, sin ella el caso de uso no se podría desarrollar.
OBJETIVO	Satisfacer las necesidades del usuario por medio de un buen servicio.

DESCRIPCION Permite que el usuario pueda comprar cualquier artículo de una tienda.

FLUJO PRINCIPAL El usuario debe elegir entre idiomas ingles y español. La caja debe escanear el producto. El producto debe ser pesado, si se bloquea el sistema debe pasar a un supervisor. El supervisor debe autorizar el escaneo de nuevo. El usuario elige entre 3 formas de pago, efectivo, tarjeta crédito, tarjeta debito. Si el usuario elige pagar en efectivo debe cancelar con monedas y luego con billetes. Si el usuario desea pagar con tarjetas debe deslizar la tarjeta. El usuario firma en el tablero electrónico y da clic en enviar. El banco da la autorización del pago. La caja devuelve el cambio. Imprime el recibo. La caja despide al usuario.

FLUJO ALTERNO 1 La caja comprueba la compatibilidad de el numero de cuenta de la tarjeta de crédito con la contraseña, si es errónea la caja avisara al usuario de digitar de nuevo numero de cuenta y contraseña.

FLUJO ALTERNO 2 Si el usuario desea pagar con billetes y después con monedas la caja deberá de informar al usuario de pagar primero con monedas y después con billetes.

POSCONDICIONES  El sistema autoriza el pago de algún producto.

REGLAS DE NEGOCIO En el bloqueo del sistema, el supervisor realizar la autorización para poder volver a escanear otros productos.

CONCLUSIONES Finalmente podemos concluir que con la utilización de los casos de uso, un problema se nos va a ser mucho mas fácil de resolver y de entender. Analizamos que podemos plasmar una idea o una solución en forma de diagrama para su mayor entendimiento no solo para nosotros si no para cualquier persona.