Tarea 4 - Identificación de la Empresa para desarrollar proyecto Semestral

Gestión de un Administrador de un Condominio Privado

INDICE

1.         Introducción

1.1 Propósito

1.2 Ámbito

1.3 Definiciones, acrónimos y abreviaturas

1.4 Referencias

1.         Situación

2.1 Oportunidad de negocios

2.2 Informe del problema

2.3 Informe del producto

1.         Descripción de los implicados y usuarios finales

3.1. Entorno de los usuarios

3.2. Resumen de los implicados

3.3. Perfiles de los implicados

3.4. Necesidades principales de los implicados y usuarios

********************DESARROLLO***********************

Introducción

1.1.  Propósito

- El objetivo principal del Administrador, es facilitar el desarrollo del trabajo de un condominio y su comunidad; ya sea esto: Controlar y así facilitar el control de vehículos que entran y salen de la propiedad, Poder almacenar el estado de cuenta de cada parcelero y verificar si existen casos de estado de cuenta morosas de estos para solucionar el problema de atraso, Controlar los sueldos de los trabajadores que otorgan sus servicios para el condominio, cabe destacar el nochero, jardinero, etc.

1.2.  Ámbito

- El Ámbito, se automatizara con la gestión del Administrador en un sistema para el condominio. Esto es decir, la persona a cargo de administrar el condominio no tendrá mayor esfuerzo en realizar sus actividades de trabajo, más que saber usar la aplicación y desarrollar las funciones correctamente, será todo muy fácil y haciendo por ejemplo click en diferentes puntos de la aplicación ya estaría todo el trabajo resuelto y almacenado. Además se irá enviando la información de la aplicación víaDropbox para tener todo respaldado vía web.

1.3.  Definiciones, acrónimos, y abreviaturas

- Acá se hace un glosario de términos que solo el administrador a cargo podrá observar, esto es: En ves de escribir muchos comentarios, se le asignara una palabra a cada acción en particular para tener la información más precisa y simple, disminuyendo los riesgos de confusión y desorden.

1.4.  Referencias

- Las referencias son algo similar a las abreviaturas vistas anteriormente, acá se le asigna un número para identificar ( ID ) a una palabra que abarca muchas cosas, veamos un ejemplo: Entra un camión al condominio que lleva materiales. Se le asigna el ID 1, a todo camión que lleva materiales al condominio. Así de este modo se reduce la información innecesaria.

Situación

2.1.  Oportunidad de negocio

El objetivo de este proyecto es el propósito de desarrollar un software  para fortalecer  el trabajo administrativo de un condominio y finalmente reemplazar el sistema manual y actual de la gestión del condominio. El sistema deberá almacenar y gestionar la información relativa a los parceleros existentes en el condominio. Además, el sistema automatizará todas las actividades relacionadas con los trabajadores de la comunidad y se podrá llevar de una manera más fácil sus sueldos,  el control de vehículos y También se gestionara la relación de los parceleros con los gastos comunes.

Al desarrollar estas funciones, El sistema acelerará el proceso de boletas y deuda de cada parcelero lo cual repercutirá en los parceleros y trabajadores, que verán es esto una idea modesta surgida de la observación social, notando una mejora considerable respecto al actual sistema con excel, lo cual podrá incrementar los beneficios de la comunidad con el brillante invento técnico.

La aplicación resultante se instalará en las oficinas de la comunidad. Tras una prueba con tiempo de duración (acorde con las disponibilidades financieras), idealmente podrá exportarse y venderse a otras comunidades para su mayor beneficio.

2.2.  Informe del problema

El problema de	Automatización de las tareas habituales realizadas en un Administrador de un Condominio
Afecta a	Empleados, encargados, comunidad del condómino, administradores.
El efecto del problema es	Ineficiencia completa del hardware
Una solución con éxito debería	Mejorar la gestión de las actividades  del Administrador y su imagen para atraer más clientes

2.3.  Informe del producto En una nueva versión.

 Descripción de los implicados y  usuarios finales

3.1.  Entorno de usuario

Los usuarios del sistema de gestión del Administrador de un Condominio son dos, el desarrollador del software y el usuario encargado en la directiva del condominio. Su nivel cultural es medio y en un comienzo, solo el desarrollador del software tiene experiencia previa en el uso de aplicaciones informáticas, por ende hay una serie de pasos para que el desarrollador enseñe a ocupar el producto y el usuario encargado de la administración de la directiva aprenda el tipo software.  

3.2.  Resumen de implicados

3.3.  Perfiles de los implicados

En una nueva versión

Software de administración de un condominio. 

Realizar actividades de gestión del software.
Modificar usuarios de la comunidad de acuerdo a requerimientos del cliente.

Realizar actividades de gestión y económicas del software.

3.4.  Necesidades principales de los implicados y usuarios

Las necesidades principales en este software serian tener una clara, rápida y eficaz acción al desarrollar sus funciones, como el poder ingresar e editar las personas que pagan gastos comunes, tener un claro control de los trabajadores e ingreso de vehículos al condominio. La necesidad principal del administrador seria realizar de una rápida acción en estos puntos, ya que el software esta para mejorar el sistema ya actual. 

Documento en word:
Descargar Word

Presentación del Power Point:

Tarea 4: Versión Power Point

View more PowerPoint from Nataly Leon

TIPS IBM Casos de Uso - Tarea 3

1.- No olvide el Diagrama 
 Los casos de uso son representados gráficamente como óvalos en los diagramas de casos de uso, y estos son también expresados como especificaciones textuales. El texto es definitivamente la esencia del modelo de caso de uso, y ciertamente puede beneficiarse de escribir el texto sin dibujar el diagrama. Sin embargo, el diagrama puede ayudar a comunicar los requerimientos a un alto nivel. 
 2.- Los actores humanos son el elemento más importante 
 Las figuras de palo utilizadas en los diagramas de caso de uso son aludidos como los actores. Ellos indican cualquier persona (o rol), otro sistema o quizás inclusive un dispositivo fuera del sistema que se está construyendo y que interactúa con él. Es el actor humano el que representa las interacciones mas interesantes y difíciles para la mayoría de los sistemas, y las interacciones humano/sistema son donde el verdadero valor de los casos de uso viene a la perspectiva. 
 3.-Vaya con la corriente 
 Buenos casos de uso no son sólo párrafos de texto claro y conciso. Ellos poseen una estructura que definen como las partes de un caso de uso calzan juntas. Y ellos pueden ser estructurados en muchas formas- referidos como un estilo de casos de uso. 
 4.- Colocar referencias en los flujos alternativos, no en los flujos principales 
El flujo principal muestra que sucede cuando todo en el caso de uso sucede de la forma correcta, y el usuario alcanza su objetivo. Incluye una serie de pasos (eventos) ordenados en orden cronológico que explican los que el sistema hace y lo que el actor realiza para llevar a cabo el caso de uso. Las referencias son simples sentencias sobre donde inicia un flujo y como y donde termina. 
 5.- Los escenarios cuentan la historia completa 
 Los actores no pueden ejecutar flujos alternativos, pero pueden ejecutar escenarios. El concepto de escenario puede ser confuso porque las personas definen los escenarios de maneras muy distintas. En IBM, nosotros los definimos simplemente como los caminos a través de un caso de uso o como una serie de pasos y flujos que un actor podría tomar – de inicio a fin- a través de un caso de uso para proveer un resultado. Dados los muchos flujos alternativos posibles, habrá muchos escenarios, con muchos resultados – ambos, positivos y negativos-.
 6.- Sea cuidadoso con las sentencias “if” 
 Los profesionales de las Tecnologías de Información (TI), particularmente aquellos con experiencia en programación, están familiarizados con las sentencias “if”, y por lo general puede observar dichas sentencias usadas en casos de uso. Un “if” en lenguajes de programación especifican comportamientos condicionales, y eso usualmente es verdad en los casos de uso también. Los problemas surgen cuando existen uno o más “if” en un flujo, ya que usualmente significa que se están especificando múltiples requerimientos. 
 7.- Especificar elecciones (opciones) del actor 
 Los actores generalmente realizan elecciones en los casos de uso. Considere el ejemplo de un sistema de registro de una universidad siendo definido en caso de uso “Registro para cursos”. En este ejemplo, un flujo principal podría ser: 1) Crear un horario, 2) modificar un horario y 3) Eliminar un horario. A menudo los escritores de casos de uso tratarán de usar sentencias “if” para mostrar al actor tomar una elección, pero por razones indicadas anteriormente, está podría no ser la mejor idea. Una mejor alternativa es tener todas las elecciones (opciones) del actor listadas en el punto apropiado, y tener una opción seleccionada y asignada al flujo actual y las otras repartirlas en flujos alternativos. Esta técnica mantiene cada flujo simple y reduce las ramificaciones. 
 8.- Aleja el CRUD 
 A menudo vemos a escritores dirigir las opciones del actor creando casos de uso separados para cada opción. Es una solución tentadora pero a la vez peligrosa. El peligro es la necesidad de manejar la complejidad exponencial que a menudo se crea, resultando en comportamientos repetitivos innecesarios 
9.- La secuencia de los eventos puede ser opcional 
 Hemos dicho que los pasos en los casos de uso, usualmente están ordenado cronológicamente, pero se debe considerar si el orden de los pasos es un requerimiento. Por ejemplo, ¿El actor tiene que haber completado el paso cuatro antes de completar el paso cinco?, generalmente la respuesta sería SI, pero no siempre. Es una cosa muy simple, al desarrollar el texto de un caso de uso, para aclarar cualquier restricción temporal, agregue comentarios como este “Este paso pude ocurrir en cualquier orden” o “Este paso puede ocurrir en cualquier momento antes que este paso” a una línea. 
 10.- Póngase en los zapatos del actor 
 Los casos de uso son diferentes con respecto al uso de sentencia “deberá”. Dado que ellos especifican pasos ordenados cronológicamente, ellos crean más contexto que las autónomas sentencias “deberá”, las cuales no son temporales. Es por esto que ellos son más reflexivos para la experiencia de los usuarios planeados. Tenga esto en mente. Si los casos de uso son requerimientos (y lo son), los diseñadores y desarrolladores estarán restringidos por lo que ellos dicen. Recuerde esto, sienta pena por el actor y escriba sus casos de uso de una forma que haga que el sistema sea lo más simple posible para el usuario.

Clase 02 de Abril

Diagrama hecho en clases, con bizagi...