1.1 Nombre del Proyecto: Administrador del Videoclub Nicole 1.2 Participantes en el Proyecto Jefe de Proyecto. Maritza G. Pech Cohuo Analista de Sistemas. Leny Gamboa Delgado Ingeniero de software y programador Sasha Uicab Varguez 1.2.1 Roles y Responsabilidades A continuacin se describen las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo durante las fases de Inicio y Elaboracin, de acuerdo con los roles que desempean en RUP.Puesto Jefe de proyecto Responsabilidad

El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios, y mantiene al equipo del proyecto enfocado en los objetivos. El jefe de proyecto tambin establece un conjunto de prcticas que aseguran la integridad y calidad de los artefactos del proyecto. Adems, el jefe de proyecto se encargar de supervisar el establecimiento de la arquitectura del sistema. Gestin de riesgos. Planificacin y control del proyecto.

Captura, especificacin y validacin de requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaboracin del Modelo de Anlisis y Diseo. Colaboracin en la elaboracin de las pruebas funcionales y el modelo de datos. Ingeniero en software Construccin de prototipos. Colaboracin en la elaboracin de las y programador pruebas funcionales, modelo de datos y en las validaciones con el usuario as como realiza la gestin de requisitos, gestin de configuracin y cambios, elaboracin del modelo de datos, preparacin de las pruebas funcionales, elaboracin de la documentacin. Elaborar modelos de implementacin y despliegue.Analista del sistema

1.3 Diagrama de Gantt

1.4 Mtricas Orientadas a la funcin Caracterstica Entradas de usuario Salidas de usuario Consultas de usuario Numero de archivos Cantidad 5 4 4 4 Simple 3 4 3 7 Cuenta total Cuenta 15 16 12 28 71

PF= 71x [0.65+0.01x50]=81.65 Productividad=81.65/2.4= 34.02 1.5 Modelo Orgnico. Proyectos de software relativamente pequeos y sencillos en los que trabajan pequeos equipos, con buena experiencia en la aplicacin, sobre el conjunto de requisitos poco rgidos (por ejemplo, un programa de anlisis termal desarrollado para un grupo calrico). Las ecuaciones del modelo COCOMO bsico tienen la siguiente forma: Donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de desarrollo en meses cronolgicos y KLDC es el nmero estimado de Lneas de Cdigo distribuidas (en miles) para el proyecto.

MODO Orgnico Semiacoplado

a 2.40 3.00 3.60

B 1.05 1.12 1.20

c 2.50 2.50 2.50

d 0.38 0.35 0.32

Empotrado

1.5.1 Costo del proyecto Modelo constructivo de costos COCOMO

Costo proyecto Sueldo de programador = $ 4,000 mensuales Subtotal = $ 4,000 * 3.4 meses = $13,600 Total= $13,600 * 2.4 TOTAL = $ 32,640

2 Modelado del Negocio2.1 Antecedentes El videoclub Nicole est ubicado en la ciudad de Mrida, actualmente realiza la renta de diversos artculos de entretenimiento: pelculas y series en DVD y pelculas en BlueRay, as como de videojuegos para 3 diferentes plataformas X-box, PS3 y Wii. En el videoclub actualmente laboran 2 empleados y un administrador el cual realiza las decisiones con respecto al funcionamiento del videoclub. Los empleados estn a cargo de la atencin a clientes, as como de realizar el mantenimiento del orden de los artculos del videoclub. 2.2 Planteamiento del Problema El videoclub realiza sus operaciones de registro de rentas, artculos y clientes en forma manual a travs de hojas de clculo y documentos de texto. El crecimiento del negocio, as como el aumento de artculos y clientes hacen que la forma que en que opera el videoclub actualmente se vuelva compleja, difcil de mantener en orden y susceptible cometer errores. El proceso de realizar la renta de un artculo comienza cuando el cliente selecciona el artculo que desea rentar, el empleado localiza la informacin del cliente en la hoja de clculo correspondiente y procede a realizar la nota de renta de forma manual. El proceso de registro de artculos y clientes es similar, se selecciona la hoja de clculo correspondiente y se procede a capturar la informacin nueva. Las dificultades en la forma de realizar actualmente las operaciones del videoclub han hecho que se busque una forma gil, eficiente y profesional de administrar estos procesos. 2.3 Propsito Debido a las diferentes formas de descarga de pelculas por internet y facilidad de renta por satlite, los clientes de los videoclubes pierden clientes que dejan de acudir a rentar a un local en especfico sus pelculas; por lo que este sistema aporta a la empresa una mejor forma de rentar las pelculas, ya que contamos que en la actualidad mucha gente tiene el servicio de internet y puede reservar desde all, as evitando as el cierre de estos negocios. 2.4 Objetivos 2.4.1 Objetivo General Analizar, Disear y Desarrollar un Sistema web para el proceso de administracin, control y rentas usando la Metodologa RUP en el videoclub. 2.4.2 Objetivos Especficos

Recabar informacin relacionada con las funciones y el proceso de administracin y venta del sistema de un videoclub.

Analizar los procesos y la informacin para presentar un diagnstico. (Anlisis del sistema). Hacer el anlisis de requerimientos del programa para definir las plataformas necesarias y las funciones especficas. Elaborar el diseo del sistema utilizando UML Desarrollar el sistema utilizando PHP5, MySQL y Apache. Realizar pruebas correspondientes Corregir errores Implementar el sistema en web y en el videoclub

2.5 3 4 5 6 7

Limitaciones El servicio de renta por internet permitir separar por 2 hrs. la pelcula elegida. El cliente deber presentarse a rentar personalmente los videos. Existe un limite de renta de hasta 2 das El cliente no podr rentar ni una pelcula mas en un da sin antes devolver las anteriores. Para poder acceder a la pgina web es necesario contar con una clave de cliente otorgada al registrarse

2.6 Alcances 1. El sistema reducir el trabajo realizado por el rea de cobro. 2. El sistema ser fcil e intuitivo de utilizar para el personal del rea. 3. Los requerimientos identificados sern debidamente cubiertos por el sistema. 4. Aportar un apoyo para sistemas nuevos de renta por internet.

2.7 Diagramas 2.7.1 Diagramas de caso de uso

Los diagramas de Casos de Uso del Negocio, identifican a los actores y describen los procesos en trminos de casos de uso desde la perspectiva actual del cliente. *diagrama general no creado Diagrama de caso de uso del cliente

Diagrama de caso de uso de del Empleado

Diagrama de casos de uso del administrador

2.7.1.1 Descripcin de Caso de Uso Caso de uso: Actores: Propsito: Tipo: Curso normal de los eventos Descripcin 1. El empleado es notificado cuando un cliente ha apartado una pelcula para separar las pelculas con el cdigo del cliente. 2. Cuando el cliente pasa a realizar la renta, el empleado corrobora el cumplimiento del horario de apartado y cobra. Cursos alternativos Validar renta Empleado El empleado podr realizar los cobros por las rentas de los clientes Primario

1.7.2. Diagrama de Actividades Representacin que muestra las actividades generadas por los actores y el orden en que se realizan estos. En la figura se representa el diagrama de actividades del proceso de Registrar cliente; en este proceso se involucran 2 actores, el Cliente y el Administrador.

El diagrama de actividades del proceso de Realizar reporte diario; en este proceso se involucran solo el actor Administrador.

Este diagrama de actividades es del proceso de Registrar artculo; en este proceso se pueden involucrar 2 actores, el Empleado o el Administrador.

Representa el diagrama de actividades del proceso de Rentar artculo; en este proceso se involucran 2 actores, el Empleado y el Cliente.

El diagrama de actividades del proceso de Cobrar recargo; en este proceso se involucran 2 actores, el Empleado y el Cliente.

Este representa el diagrama de actividades del proceso de Elegir artculo; en este proceso se involucran 2 actores, el Empleado y el Cliente

El diagrama de actividades del proceso de Devolver artculo; en este proceso se involucran 2 actores, el Empleado y el Cliente.

Diagrama de actividades del proceso de Hacer pedido; en este proceso se involucran 2 actores, el Administrador y el Proveedor.

Y el ltimo diagrama de actividades representa el proceso de Pagar proveedor; en este proceso se involucran 2 actores, el Administrador y el Proveedor.

2.8 Roles Se representa a los agentes o actores de la organizacin, quienes desempean un papel rol particular, llevando a cabo las actividades que conforman los procesos de la organizacin. En la Empresa, se identifican los siguientes actores y roles: Cliente: cualquier persona que renta de artculos del videoclub. Empleado: persona que atiende directamente al Cliente, cobra el precio de la renta de los artculos elija, adems de cobrar de los recargos que puedan tener los clientes, tambin puede registrar nuevos artculos. Administrador: es quien tiene a su cargo el videoclub, realiza el reporte de rentas del da, puede registrar nuevos clientes adems de poder registrar nuevos artculos, tiene a su cargo a los empleados del videoclub. Proveedor: persona a que se encarga de suministrar los artculos que se rentan en le videoclub.

2.9 Suposiciones y Restricciones Las siguientes restricciones sern aplicables al proyecto mencionado: El Administrador de videoclub se instalar en un servidor que soporte la plataforma PHP. As como que pueda visualizar de usuarios como empleado. El servidor tendr una base de datos, as como la capacidad de respaldar determinados tiempo todos aquellos datos que han sido registrados por los usuarios. La pgina web debe estar siempre en lnea para cualquier hora, pero la reservacin es solo para horario de local. El equipo de cmputo deber contar con conexin a Internet. La pgina tendr un peso aproximado de 10 Mb

2.10 Gestin de Riesgos 2.10.1 Identificacin de riesgos Es importante detectar desde antes los riesgos ya que estos podran afectar tanto como la programacin como la calidad del software que se planea desarrollar. Una vez detectados hay que emprender acciones para evitarlos.

Riesgos del Proyecto. y y y y Ausencia de los miembros del equipo (enfermedad, faltas no justificadas etc.) Falta de comunicacin entre los miembros del equipo Cambios constantes en los requerimientos Falta de conocimiento del lenguaje de programacin.

Riesgos Tcnicos y y y Definir requerimientos ambiguos Fallo de computadora Fallo del servidor

2.10.2 Anlisis de riesgos. y Ausencia de los miembros del equipo. Cada uno de los miembros del equipo tienen horarios diferentes u choques de la materia por lo tanto el ndice de ocurrencia es bastante alto. Con cada falta se retrasan las actividades y en consecuencia el calendario se ver afectado por las inasistencias de cada integrante. Falta de comunicacin entre los miembros del equipo. Los integrantes del equipo tengan ideas diferentes, o que no se digan a tiempo y varios integrantes del equipo podran estar trabajando en una solucin que no es acoplable con otra solucin desarrollada por otro integrante del equipo (problemas de las rieles del tren). Para este riesgo el ndice de ocurrencia es moderado. Cambios constantes en los requerimientos. Debidos a los cambios en sus necesidades por parte del cliente, algunos requerimientos podran no concretarse y extender el tiempo de esta actividad retrasando el calendario. Para ese riesgo la probabilidad de ocurrencia es alta.

y

y

y

Falta de conocimiento del lenguaje de programacin Las tres tenemos conocimiento bsico de la programacin web y php sin embargo una de las tres sabe mejor ese lenguaje y nos apoyara para el diseo del proyecto as que el ndice de ocurrencia es alto. Definir requerimientos ambiguos. Cuando no se hace un anlisis exhaustivo en la identificacin de los requerimientos caemos en interpretaciones diferentes del mismo problema, no llegando a satisfacer con un producto de calidad y cumpla con las expectativas del cliente. El ndice de ocurrencia es alto. Fallo en la computadora. Este riesgo es poco probable ya que las computadoras son bastante confiables, el efecto de perder la informacin de este proyecto sera catastrfico ya que se tendra que realizar todo de nuevo. El ndice de ocurrencia es bajo. Fallo del servidor La pagina web depende totalmente del servidor a tal grado que si se llega a caer o falla en el da, la renta se vera afectada totalmente, adems de que no contamos con problemas tcnicos y accidentes del mismo que ocasionaran grandes problemas por lo que el ndice de ocurrencia es bajo.

y

y

y

El anlisis y la priorizacin se presentan en la siguiente taba ordenados por probabilidad y luego por efecto los intervalos usados son los siguientes: Probabilidad 1. Muy bajo (10%) 2. Bajo (11-25%) 3. Moderado (26-50%) 4. Alto (51-75%) 5. Muy alto (>75%). Impacto 1. Insignificante 2. Tolerable 3. Serio 4. Catastrfico El ndice es calculado multiplicando el nmero asignado a la probabilidad por el asignado al impacto siendo 20 el mximo ndice y 1 el mnimo. ID RSGR 1 RSGR 2 Riesgo Ausencia de los miembros del equipo Falta de comunicacin Efecto Retraso con la construccin del proyecto Retraso parcial en el proyecto Probabilidad 4 3 Impacto 4 2 ndice 16 6

RSGR 3

RSGR 4

RSGR 5

entre los miembros del equipo Cambios constantes en los requerimientos Falta de conocimiento del lenguaje de programacin Definir requerimientos ambiguos Falla en la computadora Falla del servidor

Retrasan la actividad Ocasiona un atraso alto en el proyecto Puede ocasionar un atraso en el proyecto No es muy comn que suceda Puede suceder pero no es muy comn

4

4

16

5

4

20

4

2

8

RSGR 6 RSGR 7

2 2

2 2

4 4

2.11 Glosario1.1 Base de Datos (BD) Conjunto de datos pertenecientes a un mismo contexto y almacenados sistemticamente para su posterior uso. Pueden contener muchos tipos de datos. MySQL Es un sistema de gestin de bases de datos relacional, multihilo y multiusuario. Es muy utilizado en aplicaciones web, como Drupal o phpBB, en plataformas (Linux/WindowsApache-MySQL-PHP/Perl/Python) RUP Proceso Racional Unificado (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. Skateholder Es un trmino ingls utilizado para referirse a quienes pueden afectar o son afectados por las actividades de una empresa. 1.5 Tester Es la persona encargada de realizar los procesos que permiten verificar y revelar la calidad de un producto software.

1.2

1.3

1.4

1.6

PHP Es un lenguaje de programacin interpretado (lenguaje de alto rendimiento), diseado originalmente para la creacin de pginas web dinmicas. Se usa principalmente para la interpretacin del lado del servidor (server-side scripting). Apache Es un servidor web HTTP de cdigo abierto, para plataformas Unix (BSD, GNU/Linux, etc.) Microsoft, Windows, Macintosh y otras que implementa el protocolo HTTP/1.1

1.7