lunes, 25 de junio de 2012


BMPN

1)   Investigar en Internet descripciones de procesos asociados a
Servicio de Atención a Clientes, (Recoger los textos que describen el
proceso, al menos dos textos)

Etapa 1: Recepción
Etapa 2: Resolución
Etapa 3: Notificación
Etapa 4: Apelación
Etapa que detalla los pasos a seguir para recibir la gestión o reclamo en las oficinas de la institución bancaria. 

El cliente presenta su gestión o reclamo con todos los requisitos establecidos.
Etapa en la cual el área o unidad responsable recibe el caso, lo procesa y brinda una respuesta oportuna a la gestión o reclamo del cliente. (Proceso Interno)
Etapa en la cual se notifica al cliente la respuesta a la gestión o reclamo que ha sido presentado en los diferentes puntos de servicio (call center, correo electrónico, cartas, otros).
Etapa mediante la cual el cliente expresa no estar de acuerdo con la resolución emitida a su gestión o reclamo y solicita que dicho resultado se someta a análisis nuevamente.




2)   Desarrollar Un diagrama BPD (BPMN) que describa dicho proceso
(eligiendo uno de las descripciones encontradas)



3)   Escribir el Diagrama de Clases resultante del BPD

4) Proponer mejoras el Proceso

Los trabajadores podrán tomar más decisiones, para que no  acudan a niveles superiores.
Los trabajadores podrán aplicar múltiples versiones de respuesta a las soluciones, para que sean aplicados en sus específicos casos y el cliente tenga menos posibilidades de estar disconforme con la resolución de su problema.
Se propone la reconstrucción de los procesos, para cambiar el proceso y usar los conocimientos para reducir las variaciones y las complejidades para mejorar la empresa.  Ósea una Reingeniería de proceso de negocios y mejora de procesos.

jueves, 14 de junio de 2012

Taller Mpn


Taller MPN5501

Desarrollo:

1.   Señale tres elementos que forman parte del sistema Biblioteca Duoc UC.

     - Administrador biblioteca DuocUC.
     - Encargado fotocopias y otros.
     - Encargados préstamo de computadores.


2. Defina dos elementos relevantes para el sistema de tarjeta BIP del Transantiago.

- Chip con id unico para cada tarjeta, en caso de estudiantes ocupan el rut de el para validar.
- Totem ubicado en costado de la micro, que cuenta con un torniquete. Si la persona tiene saldo suficiente se le descontará el saldo acorde al pago, y se podra girar el torniquete, si no, no se podra pasar por el torniquete y no podra usar la micro como medio de transporte.       

3. Señalar dos diferencias entre los modelos de desarrollo de software, explique brevemente cada uno

a)      Espiral y Prototipo:

Espiral se diferencia entre otros por realizar los procesos de manera circular es decir no en secuencia, se puede volver a mejorar un modulo si es que es necesario, por ende el resultado final es mucho mejor. El prototipado es una manera clara de explicarle al cliente con diseños (imágenes, pantallazos, etc...) de esta manera el cliente comprende y entiende con mucha mas facilidad lo que será el sistema a desarrollar.

b)       b) Espiral y XP :

En el Modelo Espiral las actividad es no se fijan como prioridades, sino que por el contrario estas son seleccionadas en función del Análisis de Riesgos, y siempre comenzando por el bucle anterior. En tanto XP(programación extrema), Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

c)       c) Cascada y Prototipo:

El desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior no como el Modelo de Prototipos que tiene un Modelo de Desarrollo Evolutivo, este Modelo comienza con la definición de los objetivos globales para el desarrollo del proyecto, posteriormente se identifican los requisitos conocidos y las áreas del esquema. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido)



4. Se le ha pedido a usted definir los requerimientos de información para mejorar el proceso más importante en la empresa en que está trabajando su proyecto semestral:

a) Identifique dicho Proceso:
Se trata de un condominio el cual cuenta con varias familias que habitan hay, lo particular es que en cada familia hay un parcelero, esta administracion contara con varios modulos, como la organización de gastos comunes de parceleros al día.

 b) Identifique los RRHH asociados al Proceso:
  Se entrevistara al Administrador del condominio y a algunos parceleros para determinar el funcionamiento de la administración del condominio entre ambos.


Cargo: Administración
 c) Explique a quien o quienes entrevistaría en primera instancia para hacer un levantamiento de procesos y por qué?

A los personajes principales, al que el sistema le soluciona el problema, ya que es muy importante tener la mirada del afectado y poder llegar a un acuerdo con todos los pro y contras resueltos. Luego de la primera instancia se hablara con todos los que conforman el sistema, para tener una mejor toma inicial de requerimientos.

5. Investigue y explique cuál es el documento que se utiliza para formalizar los acuerdos y compromisos que se establecen en una reunión, indicando la estructura de dicho producto.

La ingeniería de requerimientos y sus principales actividades son los que resuelven las necesidades y problemas del usuario, para alcanzar su objetivo. Así también estos requerimientos tienen la capacidad de  satisfacer un contrato, hasta una especificación de un documento formal.
Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

6. Investigue acerca del modelo de desarrollo MVC, detallando sus componentes. De un ejemplo de sistema e identifique los elementos y su correspondencia con el modelo MVC.
El patrón de desarrollo MVC (Modelo Vista Controlador) es un concepto de Ingeniería de Software ampliamente usado en el mundo de la programación, este concepto está implementado en casi todos los Frameworks de desarrollo y responde a 3 pasos o etapas en la elaboración de un script.
El orden real o más usado para aplicar este patrón a nuestros desarrollos realmente es CMV, así que vamos a explicar cada uno de estos en este mismo orden.
El Controlador (Controller):
El controlador es el componente principal del patrón, ya que es este quien se encarga de controlar (Controller)
el flujo de un evento o una petición al servidor. Por medio del controller sabemos a que modelo(s) llamar y a cual vista referirse.
El Modelo (Model):
El modelo es el componente donde se ejecuta toda la lógica de nuestra aplicación, es aquí donde nos referimos a la BD y hacemos todo el modelo de negocio de nuestra app.
La Vista (View):
La vista no es otra cosa que una representación grafica o lógica de nuestra aplicación, Grafica cuando mostramos en pantalla y lógica cuando lo que hacemos es usarla como medio de transmisión de datos.
Para no complicarnos tanto, la vista simplemente es una representación de datos en el formato que queramos, bien sea HTML, XML, PDF, XLS, etc.
Gracias a este patrón de desarrollo podemos desarrollar una aplicación tanto para dispositivos móviles como para PCs de escritorio, lo único que en teoría tendríamos que cambiar sería la vista ósea el View.



7. Para el siguiente esquema de diagrama de casos de Uso de dos ejemplos:

Ejemplo Publicar en Blog o similares:



Ejemplo viajar en metro


8) Crear un diagrama de caso de uso a partir del diagrama de secuencia adjunto.




Para descargar: Descargue el Documento

lunes, 14 de mayo de 2012

Diagrama de Actividades / mostrando elementos ...



Ejemplo del Diagrama de Actividades de UML.
Entrando a esta pagina y siguiendo los pasos correspondientes, podras hacer tu propio Diagrama.

Entra a la Pagina: Diagrama

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.