1. Utilizando el RUP, sírvase obtener y personalizar las plantillas para: documento de visión, plan de iteraciones, especificación de casos de uso.

2. Con la información obtenida en su proyecto en el primer bimestre, llene la plantilla del documento de visión.

<Judicial & Recursos >

Vision Versión <1.0>

Revisión del Historial

Date Version Description Author

04 – 01 13 ‐ 1.0 Programa para recibir denuncias y elaboración de la respectiva providencia

Efraín Lincango

Tabla de Contenidos 1.Introduction

1.1Purpose 1.2Scope

2.Positioning

2.1Business Opportunity 2.2Problem Statement 2.3Product Position Statement

3.Stakeholder and User Descriptions 3.1Market Demographics 3.2Stakeholder Summary 3.3User Summary 3.4User environment

4.Product Overview 4.1Product Perspective 4.2Summary of Capabilities 4.3Assumptions and Dependencies

5.Constraints

6.Quality Ranges 7.Precedence and Priority

8.Other Product Requirements 8.1Applicable Standards 8.2System Requirements 8.3Performance Requirements 8.4Environmental Requirements

9.Documentation Requirements 9.1User Manual 9.2Online Help 9.3Installation Guides, Configuration, and Read Me File 9.4Labeling and Packaging

A. Feature Attributes

Visión

1. INTRODUCCIÓN La aplicación desarrollada para PC en ordenadores de la Función Judicial, permitirá gestionar el registro de las denuncias al juzgado y llenar la providencia con todos los datos requeridos para procesar la denuncia.

1.1 Propósito

El motivo de realizar este sistema es facilitar el proceso de ingreso de denuncias al sistema judicial, para seguidamente darle seguimiento con la debida providencia, de manera que se pueda acceder enseguida a este servicio en cualquier juzgado, con registros confiables y en tiempo real.

1.2 Alcance

El alcance de este documento está definido para el sistema “Judicial & Recursos” y contiene aspectos descriptivos del mismo.

2. POSICIONAMIENTO

2.1 Oportunidad de negocio.

El proyecto pretende posicionar en toda la Función Judicial a nivel nacional un sistema de gestión de denuncias, útil para la ciudadanía en general.

2.2 Problema.

El problema Dificultad de gestión de denuncias por parte de los usuarios y manejo deficiente por parte de los funcionarios judiciales para este servicio.

Afecta Usuarios quienes buscan dar seguimiento a su denuncia y a funcionarios judiciales.

El impacto Mejora en la calidad de servicio, ahorro de tiempo por parte del usuario y optimización de la estrategia de atención a la ciudadanía.

La solución Un sistema que haga la providencia sobre la denuncia presentada en cualquier juzgado, dando mayor comodidad, ahorro de tiempo y mejor servicio.

2.3 Posicionamiento del producto. Enfoque del sistema.

Para Funcionarios Judiciales

Quienes Necesitan mejorar la calidad de servicio y ahorrar tiempo al usuario

Que Permite el ingreso ágil de los datos de la denuncia para la elaboración de la

providencia.

A diferencia de

El proceso actual de elaboración de una providencia escrita a mano, con riesgo de faltas de ortografía o ilegibilidad en la letra.

El servicio a ofrecer Le da al cliente final (denunciante) opciones de ingreso ágil de la denuncia al sistema judicial, y al funcionario judicial le da la capacidad de gestionar esas denuncias con mayor precisión.

3. STAKEHOLDERS Y DESCRIPCIÓN DE USUARIOS.

3.1 Mercado demográfico.

Nuestro servicio está orientado a toda la Función Judicial (treinta juzgados) relacionados a la localidad. (Quito Ecuador). ‐

3.2 Sumario de Interesados.

Nombre Descripción Responsabilidad

Funcionario Judicial Administradores denuncias.

de Gestionar las denuncias ingresadas en su sistema elaborando la providencia correspondiente.

3.3 Sumario de usuarios.

Nombre Descripción Responsabilidad

Usuario – Afectado ‐Denunciante

Quien realiza denuncia

la Quien envía una denuncia al juzgado y hace una petición de providencia para seguir el caso.

3.4 Entorno de usuarios.

Para el proyecto se asume que la gestión del funcionario judicial comprenderá:

• El ingreso de la denuncia llegue a su sistema por medio de presentación física de la denuncia, y el funcionario será el encargado de notificar al abogado correspondiente sobre la disponibilidad de la petición hecha para seguir con el caso.

• Es posible que el funcionario necesite un ayudante que esté pendiente de las denuncias entrantes para que dé respuesta inmediata al solicitante.

4. SUMARIO DEL SERVICIO.

4.1 Perspectiva del servicio.

El servicio está orientado a los juzgados relacionados de la localidad. (Quito ‐ Ecuador). El sistema es una aplicación para PC, capaz de conectarse en tiempo real a una base de datos de denuncias y demás para brindar opciones de ingreso de forma personalizada.

4.2 Sumario de capacidades.

La aplicación está en la capacidad de:

Beneficio Características Soportadas

Ingreso en tiempo real. La aplicación opera sobre la base de datos de forma instantánea.

Notificación Instantánea. Al momento de ingresar la denuncia, la misma se notifica en tiempo real al abogado correspondiente, donde el funcionario se encargará de dar la respectiva confirmación.

4.3 Costos y precios.

La aplicación necesita un ancho de banda de al menos 500 kbps, por lo que se necesita tenerla siempre en línea. Aparte se necesita un hosting para el soporte de la aplicación y registrar un nombre de dominio (La función judicial ya tiene ya un sitio web por lo que se puede integrar al sistema) que conllevan su respectivo costo individual. 5. Restricciones.

• La aplicación depende del ancho de banda que posea la institución y esta velocidad determinará su rendimiento. Es decir, si existe una velocidad de conexión deficiente, la aplicación no mostrará su máximo rendimiento.

• El sistema no confirma al usuario la disponibilidad de ingreso de denuncia ya que depende de los usuarios que lo requieran

6. Rangos de Calidad

[Definición de los rangos de calidad para el rendimiento, robustez, tolerancia a fallos, facilidad de uso y características similares que no se capturan en el conjunto de funciones.]

7. La precedencia y prioridad

[Definir la prioridad de las características diferentes del sistema.]

8. Otros requisitos del producto

[En una serie de requisitos de alto nivel, la lista de las normas aplicables de hardware, o requisitos de plataforma, requisitos de desempeño y ambientales.]

8.1 Normas aplicables

[<odas las normas con las que el producto debe cumplir. Estos pueden incluir legal y regulatorio (FDA, UCC) comunicaciones estándares (TCP / IP, ISDN), estándares de la plataforma de cumplimiento (Windows, UNIX, y así sucesivamente), y las normas de calidad y seguridad (UL, ISO, CMM).]

8.2 Requisitos del sistema

[Definir los requisitos del sistema necesarios para apoyar la aplicación. Estos pueden incluir los sistemas host compatibles operativos y plataformas de red, configuraciones de memoria, periféricos y software complementario.]

8.3 Requisitos de Desempeño

[Utilice esta sección para los requisitos de desempeño de detalle. Los problemas de rendimiento pueden incluir elementos tales como los factores de carga de usuarios, ancho de banda o los tiempos de comunicación de la capacidad, el rendimiento, la precisión y la fiabilidad o la respuesta bajo una variedad de condiciones de carga.]

8.4 Condiciones ambientales

[Detalle requisitos ambientales, según sea necesario. Para los sistemas basados en hardware, las cuestiones ambientales pueden incluir la temperatura, golpes, humedad, radiación, y así sucesivamente. Para las aplicaciones de software, los factores ambientales pueden incluir las condiciones de uso, el entorno de usuario, disponibilidad de recursos, problemas de mantenimiento y de control de errores y la recuperación.]

9. Requisitos de documentación

[Esta sección describe la documentación que se debe desarrollar para apoyar la implementación de

aplicaciones exitosas.] 9.1 Manual del usuario

[Describir la finalidad y el contenido del Manual de Usuario. Discuta la longitud deseada, nivel de detalle, la necesidad de índice, glosario de términos, frente a la estrategia tutorial manual de referencia, y así sucesivamente. Limitaciones de formato y la impresión debe ser también identificados.]

9.2 Ayuda en línea

[Muchas aplicaciones ofrecen un sistema de ayuda en línea para asistir al usuario. La naturaleza de estos sistemas es única para el desarrollo de aplicaciones, ya que combinan aspectos de la programación (hipervínculos, y así sucesivamente) con los aspectos de la escritura técnica, tales como la organización y presentación. Muchos han encontrado el desarrollo del sistema de ayuda en línea es

un proyecto dentro de un proyecto que se beneficia de la gestión del alcance por adelantado y la actividad de planificación.]

9.3 guías de instalación, configuración y archivo Léame

[Un documento que incluye instrucciones de instalación y las directrices de configuración es importante para una oferta de soluciones completa. Además, un archivo Léame se incluye típicamente como un componente estándar. El archivo Léame puede incluir un "¿Qué hay de nuevo en esta versión" sección, y una discusión de los problemas de compatibilidad con versiones anteriores. La mayoría de los usuarios también apreciarán la documentación, las posibles errores conocidos y soluciones alternativas en el archivo Léame.]

9.4 Etiquetado y Embalaje

[Hoy el estado de la técnica de aplicaciones proporcionan una apariencia coherente que se inicia con el embalaje del producto y se manifiesta a través de los menús, pantallas de inicio de instalación, sistemas de ayuda, diálogos GUI, y así sucesivamente. En esta sección se definen las necesidades y los tipos de etiquetado para ser incorporados en el código. Los ejemplos incluyen los avisos de copyright y de patentes, logotipos, iconos corporativos estandarizados y otros elementos gráficos, etc.]

Característica A. Atributos

Características [se dan atributos que se pueden utilizar para evaluar, dar seguimiento, priorizar y administrar los elementos del producto propuesto para su implementación. Todos los tipos de requisitos y atributos se describen en el Plan de Gestión de Requisitos, sin embargo es posible que desee enumerar y describir brevemente los atributos de características que han sido elegidos. En los apartados siguientes representan un conjunto de atributos de entidades sugeridas.]

A.1 Estado

[Ajuste después de la negociación y revisión por parte del equipo de gestión del proyecto. Seguimiento del progreso durante la definición de la línea de base del proyecto.]

Propuesto [Se utiliza para describir las características que son objeto de debate, pero aún no se han revisado y aceptado por el "canal oficial", tal como un grupo de trabajo integrado por representantes del equipo de proyecto, gestión de productos, y el usuario o comunidad de clientes.]

Aprobadas las capacidades [que se consideran útiles y factibles, y han sido aprobados para su ejecución por el canal oficial. ]

Incorporated [Funciones incorporadas en el producto de referencia en un punto específico en el

tiempo.] A.2 Beneficio

[Juego de Marketing, el gerente de producto o el analista de negocios. Todos los requisitos no son iguales. Ranking de los requisitos de su beneficio en relación con el usuario final abre un diálogo con los clientes, analistas y miembros del equipo de desarrollo. Se utiliza en la gestión de alcance y determinar la prioridad de desarrollo.]

Critical [características esenciales. La no aplicación significa que el sistema no va a satisfacer las necesidades de los clientes. Todas las funciones críticas deben ser implementadas en la liberación o el calendario de resbalar.]

[Importante Características importante para la eficacia y la eficiencia del sistema para la mayoría de aplicaciones. La funcionalidad no se puede proporcionar fácilmente en alguna otra forma. La falta de inclusión de un aspecto importante puede afectar al cliente o la satisfacción del usuario, o incluso ingresos, pero la autorización no se retrasará debido a la falta de alguna característica importante.]

Funciones útiles [que son útiles en aplicaciones menos habituales se utilizan con menos frecuencia o para los que razonablemente soluciones eficientes se puede lograr. Sin ingresos importantes o impacto satisfacción del cliente se puede esperar si ese elemento no se incluye en un comunicado.] A.3 Esfuerzo

[Definido por el equipo de desarrollo. Dado que algunas funciones requieren más tiempo y recursos que otros, la estimación del número de equipo o persona semana-, las líneas de código requerido o puntos de función, por ejemplo, es la mejor forma de medir las expectativas de la complejidad y el conjunto de lo que se puede y no se puede lograr en un marco de tiempo dado. Se utiliza en la gestión de alcance y determinar la prioridad de desarrollo.]

A.4 Riesgo

[Juego por el equipo de desarrollo basado en la probabilidad de que el proyecto va a experimentar reacciones adversas, tales como excesos de costos, retrasos de horario o cancelación incluso. La mayoría de los gerentes de proyecto encontrar calificar los riesgos de alta, media y baja es suficiente, aunque gradaciones más finas posibles. Riesgo a menudo se puede evaluar midiendo indirectamente la incertidumbre (intervalo) de la estimación de la programación del equipo de proyectos.] A.5 Estabilidad

[Definido por el analista y el equipo de desarrollo basado en la probabilidad de que la función va a cambiar o la comprensión del equipo de la característica cambiará. Se utiliza para ayudar a establecer las prioridades de desarrollo y determinar aquellos elementos para los que la elicitación adicional es la siguiente acción apropiada.]

A.6 Target Release

[Graba la versión del producto deseado en el que la primera característica aparecerá. Este campo se puede utilizar para asignar funciones de una Visiondocument en un comunicado de línea de base en particular. Cuando se combina con el campo de estado, su equipo puede proponer, registrar y analizar las diversas características de la liberación sin comprometerlos con el desarrollo. Sólo las funciones de estado se establece Incorporated y cuyo destino se define lanzamiento se llevará a cabo. Cuando se produce la gestión del alcance, la distribución objetivo número de versión se puede aumentar por lo que el tema se mantendrá en el documento de Visión, pero se prevé su estreno para más adelante.] A.7 Asignado a

[En muchos proyectos, las características serán asignados a los "equipos de características" responsables de elicitación más allá, escribiendo los requisitos de software y la implementación. Esta sencilla lista desplegable ayudará a todos en el equipo de proyecto para entender mejor las responsabilidades.]

A.8 Razón

[Este campo de texto se utiliza para rastrear la fuente de la característica solicitada. Requisitos de existir por razones específicas. Este campo registra una explicación o una referencia a una explicación. Por ejemplo, la referencia podría ser a una página y el número de línea de una especificación de requisitos del producto o a un marcador minutos en un vídeo de una revisión importante de clientes.]

3. Documente de forma general los requerimientos.

LISTA DE REQUERIMIENTOS.

Funcionales

Identificar al usuario afectado (denunciado) para habilitar herramientas.

El programa debe elaborar reportes del proceso y la conclusión a la que se llegó de la causa procesada.

El programa debe registrar además de los datos personales del denunciante y denunciado, la fecha del delito, y las notificaciones a los casilleros judiciales, si es que los hay.

El programa debe registrar el número de pruebas e investigaciones realizadas.

El programa permite realizar y registrar remisiones de las denuncias al Fiscal superior.

El programa permite realizar un boletín donde consten las notificaciones realizadas cada día.

No funcionales.

El programa debe presentar todo en mayúsculas indiferentemente si se ingresa información en minúsculas.

El programa debe estar en plataforma grafica con uso de mouse.

4. Refine la lista de casos de uso y elabore un diagrama de casos de uso para el sistema si es posible utilice Rational Rose, caso contrario un graficador.

<Judicial & Recursos >

5. En función de las características del RUP descargue la plantilla y elabore un plan de iteraciones.

Revisión del Historial

Confirmación

Ingresa

Funcionario

Judicial Ayudante

Usuario

Notifica

rovidenciap Elabora

Registra

Despacha

<<extends>>

Date Version Description Author

04 – 01 13 ‐ 1.0 Programa para recibir denuncias y elaboración de la respectiva providencia

Efraín Lincango

Table of Contents 1.Introduction

1.1Purpose 1.2Scope 1.3Definitions, Acronyms and Abbreviations 1.4References 1.5Overview

2.Plan

3.Resources

4.Use Cases

5.Evaluation Criteria

Plan de Iteración

1. Introducción El Plan de iteraciones nos permite tener una visión general de todo el proyecto para realizar la Aplicación <Judicial & Recursos > donde todo el proceso está documentado, aquí se incluye los propósitos, alcances, definiciones, acrónimos, abreviaciones , referencias y una visión general del Plan de Iteración.

1.1 Propósito

El propósito de la Iteración es fijar un diseño definitivo que nos permita trabajar durante todo el proyecto hasta la culminación. Todos los componentes deben tener un comportamiento y dependencias bien definidas estén o no desarrolladas, para esto se elabora un documento de diseño que nos ayudará a realizar con éxito el proyecto

1.2 Alcance El Plan de Iteración comienza con una conversación por parte de la ciudadanía en general sobre el problema al momento de ingresar una denuncia al sistema judicial para que se elabore la respectiva providencia y continuar con las investigaciones, quienes comentan con las autoridades del consejo de la Judicatura, y contratan a un grupo de profesionales para comentarles la problemática, para comenzar el proyecto que consiste en desarrollar una

aplicación software que ayude a ingresar ágilmente los datos y almacenarlos en una base de datos, brindando mejor servicio a la ciudadanía en cuanto a agilidad, claridad y precisión.

1.3 Definitions, Acronyms and Abbreviations [This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Iteration Plan. This information may be provided by reference to the project Glossary.]

1.4 References [This subsection should provide a complete list of all documents referenced elsewhere in the Iteration Plan. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

1.5 Overview Primeramente se obtiene información de parte de los funcionarios para recopilar información de cómo se ha ido trabajando hasta ahora, cómo se podría informatizar el sistema actual de ingreso de denuncias, la elaboración de providencias y almacenamiento de información, se hace un diseño preliminar se lo pone en consideración con el director de la Judicatura y jefe de proyecto, si es aceptado comienza el desarrollo, luego las pruebas y por último entrega a los funcionarios judiciales. Además se contará siempre con ayuda para dar mantenimientos y capacitación a los ayudantes judiciales que laboran en los diferentes juzgados sobre el funcionamiento del programa en caso de que tengan que explicar a otros empleados.

2. Plan

Recolección de información sobre el problema, las necesidades y que es lo que se espera. Diagrama de entidad relación, diagrama de clases, diagrama de caso de uso, diagrama de‐ actividades.

3. Recursos Se necesitan un grupo de Ingenieros, Técnicos, desarrolladores de Programas, los funcionarios, el dueño de la Aplicación para recolectar información y aceptación esto en la parte humana ahora se debe contar con el presupuesto económico suficiente para llevar a cabo un proyecto de calidad.

4. Casos de Uso El escenario viene siendo varias máquinas instalada en el juzgado (dependiendo del número de empleados) , donde los funcionarios realizarán las transacciones guiándose de la denuncia presentada por el usuario, los actores son los usuarios, los funcionarios judiciales y los ayudantes judiciales, los casos de usos serían necesidad de una aplicación, registro, ingreso, elaboración de la providencia, notificación, confirmación, despacho, ayudar en el funcionamiento en caso de que algún alumno tenga problemas con el sistema.

5. Evaluation Criteria La Aplicación para los juzgados de pichincha según los requerimientos previos y si son realizados como se esperan va a tener un gran éxito en la Función Judicial ya que minimizará el tiempo de espera para hacer una transacción de parte de los usuarios afectados, evitará la molestia de permanecer de pie haciendo largas filas e interrumpiendo el paso en los pasillos, además ya no habría motivo de reclamos a cerca de la legibilidad de la letra ya que todo será computarizado. Contando con que la aplicación se va a desarrollar de forma eficiente con varios idiomas y facilidad para realizar cualquier transacción.

6. Especifique los casos de uso en base a una plantilla obtenida del RUP, la que deberá contener: código, descripción, actores, flujo básico, flujos alternos, precondiciones, poscondiciones, especificaciones suplementarias.

CASO DE USO

Obtener una Aplicación Software

Actores Primarios

Funcionarios Judiciales, Ayudantes, Usuarios

Intereses y objetivos

Consejo de la Judicatura: Desea acelerar el proceso de ingreso de denuncias al sistema judicial y expedir la elaboración de la respectiva providencia dando un mejor servicio a la ciudadanía.

Equipo de Profesionales: Desarrollar un Programa eficaz.

Usuarios: Evitar hacer filas para ingresar una denuncia, evitar aglomerarse en los pasillos, evitar malos entendidos por la legibilidad de la letra, recibir un mejor servicio.

Funcionarios: Llevar un mejor control en sus labores, evitar la sobrecarga de trabajo, atender mejor a la ciudadanía.

Precondiciones

El propietario del proyecto tiene que tener en cuenta que debe tener claro lo que desea, contar con la parte económica suficiente, el tiempo que esto llevará, contar con el personal apropiado, y el lugar donde se fijarían las máquinas.

Post condiciones ‐

El programa quedará instalado y funcionando correctamente.

Escenario Principal

‐ El funcionario presiona “start” para comenzar.

‐ Selecciona el idioma que el usuario solicite (ya que puede ser extranjero).

‐ Pone el número de denuncia, número de indagación.

‐ Selecciona fecha y hora actuales.

‐ Ingresa datos del denunciado

‐ Ingresa fecha de denuncia y de indagación previa

‐ Ingresa nombre del fiscal encargado

‐ Ingresa todos los casilleros judiciales

‐ Realiza la notificación al abogado correspondiente

‐ El programa pregunta si desea imprimir la providencia,

‐ Si desea realizar alguna corrección, vuelve nuevamente,

‐ El programa entrega copia de providencia al usuario.

‐ Imprime el boletín con los casilleros judiciales.

Escenario Alternativo

‐ Olvidar el número de denuncia El programa rechaza la operación.

Se pide introducir nuevamente el número correcto

Si no responde en 30 segundos el programa pregunta si necesita más tiempo. Si no hay

respuesta el programa pide llamar al abogado encargado para solicitar el número de

denuncia con los datos del usuario.

Requisitos especiales:

Pantalla táctil, panel grande y plano, con letras visibles.

Respuesta de la máquina en menos de 2 segundos en el 100% de los casos.

Recuperación robusta cuando el acceso mediante comunicaciones falla.

Contar con varios idiomas.

Comunicaciones cifradas.

Frecuencia de Ocurrencia

Tiene que ser continua.

Escenario principal

El Consejo de la Judicatura necesita una aplicación software para el proceso de denuncias. Contrata a un equipo de profesionales.

Mediante una entrevista los profesionales reciben toda la información sobre las

necesidades.

Los Ingenieros realizan un plan de visión.

Los interesados lo revisan y hacen algunos cambios.

Se realiza un diseño preliminar de lo que se desea.

Llegan al acuerdo de crear un prototipo.

El prototipo es aceptado por los interesados.

Se pone a prueba.

Se implementa.

Se entrega el programa a cada juzgado

Se da entrenamiento al personal de cada juzgado donde se instalará el sistema.

Los profesionales se comprometen en dar mantenimiento al programa.

El programa comienza su funcionamiento.

Escenario Alternativo:

Falta de información por parte de los interesados, o algún cambio durante el proceso, se

vuelve atrás y se rectifica no esperar llegar al final, ya que cada semana se hacen reuniones

entre las partes para ver el avance del proyecto y si hay que rectificar algo.

Frecuencia de Ocurrencia

Todo el equipo que están desarrollando la Aplicación tanto equipo de profesionales,

propietario, deben contar con el tiempo disponible para reunirse y avanzar con el desarrollo

del Programa.

Requisitos especiales.

Contar con una sala para reunirse.

Con el material necesario para hacer realizar el proyecto.

Tener toda la información necesaria.

El equipo de profesionales debe ser experimentado y no amateur.

7. A partir del modelo de casos de uso obtenga un modelo conceptual identificando las clases con las estrategias indicadas en la guía didáctica y luego en Rational Rose elabore diagramas de clases, diagramas de interacción y diagramas de actividades correspondientes a los casos de uso del sistema.

MODELO CONCEPTUAL PARA <Judicial & Recursos >

DEFINICION DEL PROBLEMA

Definición Largas filas al realizar un ingreso de denuncia, aglomeración en los pasillos, incomodidad, trabajo apurado y propenso a errores.

Afecta a Usuarios, personal que labora.

Impacto Los usuarios tienen que esperar demasiado. Los empleados no pueden agilitar el proceso por realizar muchos pasos y trabajo a mano.

Solución Sistema que automatice el proceso de ingreso de denuncias.

AFECTADOS POR EL PROBLEMA

Afectados Descripción Responsabilidades

Propietario Jefe de Sistemas de la función judicial

Supervisa, controla, informa los procedimientos que se ocurren en todos los juzgados.

Funcionarios y ayudantes Encargados de atender a los clientes y hacer trámites.

Realizan actividades relacionadas con la el proceso seguimiento de denuncia.

Usuarios Buscan una solución al delito que los ha afectado

Se relaciona con los funcionarios.

NECESIDADES DE LOS AFECTADOS

Director de la judicatura

‐ Llevar un estricto control de las transacciones económicas.

‐ Evitar contratar demasiado personal.

‐ Otorgar un buen servicio a la comunidad. Funcionarios

‐ Evitar errores al notificar a los abogados,

‐ Agilitar el proceso de elaboración de providencia.

Usuarios

‐ Atención eficiente.

‐ Evitar hacer filas.

‐ Evitar hacer aglomeraciones.

IDENTIFICAR LAS ENTIDADES

JUZGADO

APLICACION

EQUIPO DE PROFESIONALES

USUARIOS

FUNCIONARIOS

AYUDANTES

COPIA DE PROVIDENCIA

RECIBO

FUNCIONAMIENTO

IDENTIFICAR LAS RELACIONES

JUZGADO

‐ Adquisición de Programa

‐ Tiene funcionarios

‐ Tiene ayudantes

APLICACIÓN

‐ Ingresa datos de denuncia

‐ Genera una providencia

‐ Entrega recibo

EQUIPO DE PROFESIONALES

‐ Entrevistan con los interesados

‐ Recopilan información

‐ Desarrollan el programa

‐ Proporcionan entrenamiento a los usuarios

‐ Dan mantenimiento

USUARIOS

‐ Solicitan el ingreso de la denuncia

‐ Solicita la copia de la providencia

‐ Obtiene un recibo de la notificación al abogado competente.

AYUDANTES JUDICIALES

‐ Ayudar al funcionario en las operaciones llevadas a cabo

‐ Chequear la denuncia y todos las pruebas que existan

IDENTIFICAR LOS ATRIBUTOS

JUZGADO APLICACION FUNCIONARIOS AYUDANTE USUARIOS

JuzNombre Apl.Id FuncName AyudName UsuarioId

JuzDirección Juz.Name FuncApellido AyudApellido UsuarioName

JuzTelef Func.Telf AyudTelf UsuarioApellido

UsuarioTelf

DETERMINAR CLAVES CANDIDATAS Y CAVES PRIMARIAS

Juzgado (JuzName, JuzDiracción, JuzTelf) PK Aplicación (AplId, JuzName) FK Funcionarios (FunName, FunApellido, FunTelf, AyudName, AyudApellido, AyudTelf)

Usuarios (UsuarioId, UsuarioName, UsuarioApellido, UsuarioTelf)

DEBIDO A QUE NO HE LOGRADO INSTALAR EL SOFTWARE PROPUESTO POR UD, HE HECHO LA SIGUIENTE ACTIVIDAD EN NETBEANS

DIAGRAMA DE CLASES

DIAGRAMA DE INTERACCIÓN

DIAGRAMA DE ACTIVIDADES