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