domingo, 29 de abril de 2012

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:



miércoles, 18 de abril de 2012

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.

miércoles, 28 de marzo de 2012

Preguntas texto: "MODELAMIENTO DE PROCESOS DE NEGOCIO V2.0"

Preguntas y Respuestas:


1.- ¿Cuál es la principal ventaja de bpmn frente a uml?
  a) es más fácil de usar
  b) uml está obsoleto al ser muy antiguo
*c) bpmn es una notación enfocada en procesos y no en objetos
  d) bpmn es orientado a servicios


2.- ¿Qué representa el modelado de negocio?
 *A) un tipo de flujo de trabajo (workflow)
   b) un caso de uso
   c) un tipo de diagrama uml
   d) una actividad presente en el negocio


3.- ¿El sistema puede ser un actor?
* A) Verdadero
    b) Falso

4.- ¿Cómo se describe un escenario?
   a) un conjunto de casos de uso
   b) una plantilla uml
 *c) una secuencia especifica de acciones e interacciones entre los actores
   d) una tarima en donde se presentan los actores del caso de uso

5.- ¿Es incompatible utilizar uml y bpmn al mismo tiempo para un proyecto?
  A) verdadero
*B) falso

6.- Una de las opciones para poder modelar seria ¿Cuando se desea empezar el negocio desde cero?

*A) verdadero
  B) falso

   




(*) Son las respuestas Correctas.-



martes, 13 de marzo de 2012

Tarea 1 – Investigación BPMN


¿Qué diferencias tiene con la versión anterior?


El futuro inmediato del BPMN ha dado  un punto de experiencia entre usuarios y vendedores que permitió, mediante feedback, afinar detalles de la especificación, en concreto.

En esta nueva versión de mantenimiento del BPMN existe un esfuerzo en estandarización de los artefactos para soportar modelado de negocios generales y dominios de negocios verticales (seguros, manufacturación, finanzas). Además, está intentando encajar en un mayor contexto de modelado de negocios de alto nivel (incluyendo reglas de negocio y estrategias de negocio).

En la nueva versión de BPMN 2.0 existen actualizaciones y nuevos elementos, de los cuales se pueden resaltar:

- Nuevos componentes:

Choreographies

ü  Diagrama de Coreografía
ü  Diagrama de Conversación

- Actualizaciones:

Gateway

ü  Exclusivo
ü  Paralelo
Semántica: Se pueden encontrar en el inicio de un proceso.

Tasks

ü  Event- Subprocess (Usado para manipular los eventos que ocurren en la delimitación subprocesos)
ü  Actividad secuencial de varias instancias
ü  Tareas de Reglas de Negocio

Artifacts

ü  Data Objects

Events

ü  Eventos interrumpidos y NO interrumpidos
ü  Escalada
Si una escalada sucede, el siguiente nivel de responsabilidad será involucrado

-   Nuevos conceptos:

2.3.1  Business Rule Task

El Business Rule Task Proporciona un mecanismo, en el que a partir de un motor de reglas de negocio se puede enviar (Input) y recibir (Output) data. Es decir, de acuerdo a las reglas del juego.

2.3.2  Service Task

El Service Task es una tarea que utiliza algún tipo de servicio. Como por ejemplo un Web Service  o una aplicación automatizada. Los Inputs del Service Task se asignan al mensaje de entrada, vale decir a los atributos dentro del mensaje. Por un WSDL (Web Services Description Language),  en donde sería expresado como parte del mensaje.


2.3.3  Callable Element

             Es  la clase abstracta de todas las “Super Actividades” que se han definido al margen de un                     
             proceso o coreografía, pero que se puede llamar (o reutilizar) desde dentro de un proceso o 
             coreografía. Además, hace referencia a las operaciones del servicio que realiza.

2.3.4  Call Activity

            Identifica un punto en el proceso donde un  Global Process o un Global Task  es utilizado.    
            Asimismo, éste actúa como un “envoltorio”  para la invocación de un Global Process o un 
            Global Task  dentro de la ejecución.

2.3.5  Global Task

Es una Definición de tarea atómica y reutilizable que puede ser llamada desde cualquier proceso por un Call Activity.


Software para desarrollar BPMN

1 visio(Office)

2 VizAgi

3 Gliffy

El mejor software para desallorar, seria Vizagi, por su gran potencial, es amigable con el usuario, tiene bastante remonbre al hablar de BPMN.

Ejemplo de diagrama:



Tarea en version Word (Para descargar)

Descarga: Descarga del word
Tarea version Power Point (Para descargar y visualizar)

Visualizacion:


Descarga: Power point trabajo








lunes, 12 de marzo de 2012

Clase 1 (12 de marzo 2012)

La gestión de datos es sumamente importante en las empresas, a la hora de hacer las consultas.
Metodología ágil, programación extrema, diagrama de clases de usos son muy importantes, se construirán casos de uso de manera escrita. Lo mas importante es saber desarrollar casos de uso. Otros tipos de diagrama muy usados son: diagrama de interacción y transición.
ws-bpel
-Flow objects
Evento
actividad
decision
-
Investiagar sobre bpmn en el Blog
cambios en la version 1.1 a la version 2.0
3 software para desarrollar bpmn y elejir 1 para describir un proceso.
1 documento word con la investigacion, 1 ejemplo y hacer power point.
publicar como tarea 1 - investigacion bpmn, un resumen de su trabajo y los links de los archivos WORD y POWER POINT.

martes, 6 de diciembre de 2011

¿Que es Oracle Forms?

Como bien se entiende en el título es una herramienta de Oracle y su principal cometido es el desarrollo rápido de aplicaciones, sobre todo de gestión. También se puede considerar como un lenguaje 4gl, es decir, de cuarta generación.

Llevo trabajando más de 10 años con Oracle Forms, desde la versión 4.5, 6i y ahora con la 10g, mé he saltado la 9.

Las versiones 4.5 y la 6.0 funcionan en el modelo Cliente/Servidor. La 6i funciona en web aparte de en Cliente/Servidor, y a partir de la versión 9 (se han saltado la 7 y 8) solo funciona en entorno web.

Para el funcionamiento en web usa un applet, por lo que es necesario tener instalado el plug-in de Java en el ordenador que abra la aplicación.

La versión 6i en web no tengo experiencia de como va, lo que he visto de 10g no tiene mala pinta.