lunes, 29 de octubre de 2007

Documento de Requerimientos

Este documento es una especificación de requisitos del sistema para un videoclub el cual llevara el control de la renta y devoluciones de películas y de la base de datos de los cliente que tiene el videoclub, en este sistema se almacenara los datos el estado en que se encuentra los clientes así como guardar nuevos clientes y dar de baja a los clientes que en cierto tiempo no han devuelto la película o no han rentado en un tiempo bastante amplio etc.

Propósito

El propósito es de qué manera clara y precisa todas las funcionalidades y restricciones del sistema a construir. Este documento va dirigido a las personas que van a llevar a cabo el control de renta de películas así el de dar de alta y modificación de perfiles de los clientes. Este documento será el medio por el cual se comunicara el personal encargado de lo mencionado anteriormente y será revisado y aprobado tanto como el equipo y el cliente, ya que este sea aprobado será base para la siguiente fase.

Restricciones

El sistema se diseñara para que el encargado del videoclub pueda tener acceso a dar altas y bajas de los clientes así como modificar su perfil de cada uno de ellos.

El sistema tendrá un diseño sencillo y debe ser de fácil uso

Suposiciones

1. Suposiciones.

Se asume que los requisitos descritos en este documento son estables, una vez que se hayan aprobados por los grupos de validación y verificación y control de cambios. Se pondrán en marcha para el funcionamiento del sistema.

Requisitos específicos

En este apartado los requisitos funcionales que deberán ser satisfechos por el sistema del videoclub. Todos los requisitos que se planteen serán esenciales, es decir, que no sería aceptable un sistema que no satisfaga alguno de estos requisitos. Estos requisitos se han especificado de acuerdo al criterio de estabilidad, dado un requisito, debería ser fácilmente demostrable si es satisfactorio o no por el sistema.

Requisitos funcionales

1. Encargado de Rentas

1.1 REQ01: Mantener un control sobre la renta de películas y juegos.

El sistema le permitirá al encargado de rentas, tener un control sobre las rentas realizadas en cualquier fecha específica, además de controlar a los clientes, sus restricciones o clasificación.

1.2 REQ02: Registro único y actualizable.

El sistema permitirá al encargado de rentas agregar datos del cliente, modificar o eliminar registros ya existentes, datos como nombre, Numero de membresía, dirección, tipo de cliente, teléfono y forma de pago. El sistema permitirá al administrador borrar, actualizar y consultar información relacionada con las rentas y datos del cliente.

2. Cliente

2.1 REQ03: Proporcionar la información necesaria para el registro de membresía.

El sistema permitirá tener un control sobre las rentas que realiza, actualizar sus datos en caso de ser necesario y le permitirá también tener un historial de todos los movimientos que ha realizado durante un periodo.

3. Sistema

3.2 REQ04: Registrar usuarios nuevos

El sistema permitirá al administrador dar de alta nuevos registros para mantener un control sobre los clientes que se vallan agregando.

3.2 REQ05: Registrar películas y juegos rentados.

Después de registrar a los clientes se registrara también las películas y juegos que ha rentado, nombre de la película o juego, número de control, clasificación y categoría.

Requisitos de interfaces externos

Requisitos no funcionales

1. Interfaces de usuario

1.1. REQ06: Ser consistente.

El sistema deberá presentar una interfaz de fácil manejo en la navegación dentro de nuestro sistema.

1.2. REQ07: Ofrecer respuestas significativas.

El sistema deberá presentar información importante y verdadera a las peticiones que el encargado de rentas desea realizar.

1.3. REQ08: Pedir confirmación antes de realizar cualquier acción que sea importante.

1.4. REQ09: Permitir deshacer acciones que se realizaron y ya no son necesarias.

1.5. REQ10: Clasificar los módulos por función y organizar la pantalla de acuerdo a esto.

1.6. REQ11: Proporcionar ayuda, si así lo necesita el usuario.

1.7. REQ212: Usar frases cortas para nombrar las órdenes y que se puedan entender mejor en una sola palabra lo que se desea realizar en dichos procesos.

2. Interfaces de hardware

2.1. REQ13: Sistema de cómputo.

Se deberá contar con un sistema de cómputo, para la integración de los

Servicios para el funcionamiento de sistema.

2.2 REQ14: Infraestructura de red.

Se deberá contar con una red de datos (LAN).


3. Interfaces de software

3.1. REQ15: Comunicación con otros módulos.

La comunicación de los módulos del sistema se realizará mediante

Servicios que utilizan protocolos basados en estándares aceptados por el Usuario y administrador del sistema

Requisitos de rendimiento

1. REQ17: Tiempo de respuesta.

Los tiempos de respuesta a las peticiones de los clientes deberán ser cortos, considerando una red de comunicaciones eficiente.

2. REQ18: Concurrencia.

El sistema deberá soportar concurrencia de acuerdo al número de consultas que se realicen.

Requisitos de desarrollo

1. REQ20: Ciclo de vida.

El ciclo de vida elegido para desarrollar el sistema será el Rational Unified Process (RUP), el cual consiste en que cada una de las etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes.

Atributos

1. REQ21: Portable.

El sistema deberá ser portable, es decir, que se pueda implantar en diversas plataformas.

2. REQ22: Escalable.

El sistema es susceptible de ser ampliado. Por lo tanto, deberá diseñarse fácilmente para ser escalable, aplicando en su desarrollo las metodologías que para ello sean precisas, como documentación de código y modularidad.

lunes, 1 de octubre de 2007

Conducir diseño con los casos del uso

Seguiremos el proceso detallado en nuestro libro objeto conducido caso del uso que modelaba con UML (Addison-Wesley, 1999), (también sabido como el proceso de ICONIX), que se sienta en alguna parte entre el proceso unificado racional muy grande (RUP) y el acercamiento de programación del extremo muy pequeño (XP).

El proceso de ICONIX es caso del uso conducido, como RUP, pero carece los muchos gastos indirectos que RUP trae a la tabla. Es también relativamente pequeño y apretado, como XP, pero no desecha análisis y el diseño como XP.


El diagrama retrata la esencia de un acercamiento aerodinámico al desarrollo del software que incluye un sistema mínimo de diagramas de UML y algunas técnicas valiosas que te llevan de casos del uso al código rápidamente y eficientemente.









El segundo artículo discutirá modelar del dominio. Ésta es la tarea de descubrir las clases que representan las cosas y los conceptos relacionados con el problema que un sistema se está diseñando para solucionar.

El modelar del dominio implica el trabajar hacia fuera de los requisitos de los datos para construir un modelo estático del dominio del problema relevante al sistema propuesto.

El tercer artículo discutirá cómo escribir los casos del uso que detallan los panoramas que los usuarios realizarán. Describiremos cómo escribir los casos completos e inequívocos del uso que describen aspectos individuales del uso del sistema sin presumir ningún diseño o puesta en práctica específico.


El cuarto artículo en la serie discutirá análisis de la robustez. Esto implica el analizar del texto narrativo de los casos del uso, el identificar primero-conjetura el sistema de los objetos que participarán en esos casos del uso

Demostraremos cómo el análisis de la robustez, que sirve como diseño preliminar dentro del proceso, proporciona el acoplamiento que falta entre el análisis y el diseño detallado.

El quinto y pasado artículo discutirá la interacción que modela, la fase en la cual puebla estructura los hilos de rosca que tejen sus objetos juntos y OS permiten comenzar a ver cómo el nuevo sistema realizará comportamiento útil.