2.7.12
29.6.12
Proyecto
Modelamiento Procesos de negocios
Distribuidora “El 9”
Santiago Domínguez
Iván Pino
Marco Cabello
Fecha Versión Descripción Autor
21-06-2012 2.0 Aproximación al sistema Marco Cabello
Santiago Domínguez
Iván Pino
Introducción
Nuestro trabajo consta de programar un software de inventario para la empresa distribuidora de licores “El 9” con el objetivo de controlar los productos que se tienen y facilitar la compra y venta de estos. El dueño, Saúl Martínez, nos conto que la visión de su empresa es crecer en grande para dar la mayor cantidad de empleos a las personas que lo necesiten y expandirse a regiones. La ubicación de su actual empresa es Santa Rosa.
1.1 Propósito
El propósito de este informe es detallar los requisitos y necesidades que necesita la distribuidora de licores para digitalizar y controlar el negocio.
1.2 Ámbito
El documento de visión se aplica a un sistema de gestión de inventario que desarrolla las tareas habituales de una distribuidora. Su objetivo principal es controlar los productos evitando perdidas y tener un orden y un detalle de cada uno de ellos.
1.3 Definiciones, acrónimos y abreviaturas
Cliente: Persona que ocasionalmente va a la distribuidora a comprar productos (licores) que estén en venta. El pago lo hace al contado y no se almacenan sus datos en el sistema.
Dueño: Persona propietaria del negocio y responsable del manejo de este.
Empleado: Persona que desempeña un cargo o trabajo y que a cambio de ello recibe un sueldo.
Sistema: Un sistema informático como todo sistema, es el conjunto de partes interrelacionadas, hardware, software y de Recurso Humanos. Un sistema informático típico emplea una computadora que usa dispositivos programables para capturar, almacenar y procesar datos.
Software: El software son las instrucciones electrónicas que van a indicar al ordenador qué es lo que tiene que hacer. También se puede decir que son los programas usados para dirigir las funciones de un sistema de computación.
Situación
2.1 Oportunidad de negocio
El propósito de este proyecto es realizar un sistema en el cual la distribuidora tenga un control total de sus productos, así como también gestionar sus ventas e ingresos de sus productos. Con esto esperamos que el sistema automatice lo que hoy se realiza manualmente, ya que esto ahorrara tiempo y dinero.
La aplicación deberá ser instalada en los computadores que posea la distribuidora y esta constara con módulos para distintos niveles de usuarios.
2.2 Informe de problema
El problema de Automatización de los procesos necesarios para la compra y venta de licores.
Afecta a Clientes, empleados y dueño de la distribuidora.
El efecto del problema es Falta de orden, organización y digitalización de la documentación existente.
Una solución con éxito debería Automatizar los procesos necesarios para la realización de venta y control de licores.
2.3 Informe del producto
3.1 Entorno de usuario:
El sistema constara con distintos módulos, los cuales serán realizados acorde a la necesidad de los tipos de usuario, así como los privilegios que se otorgaran a los distintos niveles de usuarios. Los usuarios del sistema son dos, el empleado y el dueño. Su nivel en la computación es medio y ambos tienen experiencia en el negocio. El dueño será capaz de modificar el stock y el precio de los productos, a diferencia de los vendedores, que solo tendrán acceso a los módulos de venta del sistema.
3.2 Resumen de implicados:
Nombre Descripción Tipo Responsabilidad
Cliente Representa al comprador Usuario de productos Comprar los productos
Encargado de bodega Representa a un empleado Usuario de sistema Realiza actividades de venta y recibe los productos obtenidos
Vendedor Representa a un empleado Usuario de sistema Realizar actividades de venta
Dueño Representa al dueño Usuario de sistema Realizar actividades de venta, modificar e ingresar inventario y precios
Distribuidora “El 9”
Santiago Domínguez
Iván Pino
Marco Cabello
Fecha Versión Descripción Autor
21-06-2012 2.0 Aproximación al sistema Marco Cabello
Santiago Domínguez
Iván Pino
Introducción
Nuestro trabajo consta de programar un software de inventario para la empresa distribuidora de licores “El 9” con el objetivo de controlar los productos que se tienen y facilitar la compra y venta de estos. El dueño, Saúl Martínez, nos conto que la visión de su empresa es crecer en grande para dar la mayor cantidad de empleos a las personas que lo necesiten y expandirse a regiones. La ubicación de su actual empresa es Santa Rosa.
1.1 Propósito
El propósito de este informe es detallar los requisitos y necesidades que necesita la distribuidora de licores para digitalizar y controlar el negocio.
1.2 Ámbito
El documento de visión se aplica a un sistema de gestión de inventario que desarrolla las tareas habituales de una distribuidora. Su objetivo principal es controlar los productos evitando perdidas y tener un orden y un detalle de cada uno de ellos.
1.3 Definiciones, acrónimos y abreviaturas
Cliente: Persona que ocasionalmente va a la distribuidora a comprar productos (licores) que estén en venta. El pago lo hace al contado y no se almacenan sus datos en el sistema.
Dueño: Persona propietaria del negocio y responsable del manejo de este.
Empleado: Persona que desempeña un cargo o trabajo y que a cambio de ello recibe un sueldo.
Sistema: Un sistema informático como todo sistema, es el conjunto de partes interrelacionadas, hardware, software y de Recurso Humanos. Un sistema informático típico emplea una computadora que usa dispositivos programables para capturar, almacenar y procesar datos.
Software: El software son las instrucciones electrónicas que van a indicar al ordenador qué es lo que tiene que hacer. También se puede decir que son los programas usados para dirigir las funciones de un sistema de computación.
Situación
2.1 Oportunidad de negocio
El propósito de este proyecto es realizar un sistema en el cual la distribuidora tenga un control total de sus productos, así como también gestionar sus ventas e ingresos de sus productos. Con esto esperamos que el sistema automatice lo que hoy se realiza manualmente, ya que esto ahorrara tiempo y dinero.
La aplicación deberá ser instalada en los computadores que posea la distribuidora y esta constara con módulos para distintos niveles de usuarios.
2.2 Informe de problema
El problema de Automatización de los procesos necesarios para la compra y venta de licores.
Afecta a Clientes, empleados y dueño de la distribuidora.
El efecto del problema es Falta de orden, organización y digitalización de la documentación existente.
Una solución con éxito debería Automatizar los procesos necesarios para la realización de venta y control de licores.
2.3 Informe del producto
3.1 Entorno de usuario:
El sistema constara con distintos módulos, los cuales serán realizados acorde a la necesidad de los tipos de usuario, así como los privilegios que se otorgaran a los distintos niveles de usuarios. Los usuarios del sistema son dos, el empleado y el dueño. Su nivel en la computación es medio y ambos tienen experiencia en el negocio. El dueño será capaz de modificar el stock y el precio de los productos, a diferencia de los vendedores, que solo tendrán acceso a los módulos de venta del sistema.
3.2 Resumen de implicados:
Nombre Descripción Tipo Responsabilidad
Cliente Representa al comprador Usuario de productos Comprar los productos
Encargado de bodega Representa a un empleado Usuario de sistema Realiza actividades de venta y recibe los productos obtenidos
Vendedor Representa a un empleado Usuario de sistema Realizar actividades de venta
Dueño Representa al dueño Usuario de sistema Realizar actividades de venta, modificar e ingresar inventario y precios
25.6.12
Patrones de Negocio, Reglas de Negocio
Patrones
- Muchos problemas recurrentes que se encuentran al modelar sistemas de negocio ya han sido resueltos.
- Los patrones permiten capturar y describir estos problemas de modelado de negocio y sus correspondientes soluciones de modo que las soluciones se puedan reutilizar
- Un patrón es una solución generalizada que puede ser implementada y aplicada en un problema (un contexto), y así eliminar uno o más problemas inherentes con el fin de satisfacer uno o más objetivos.
- “Cada patrón es una regla de 3 partes, la cual expresa una relación entre cierto contexto, un problema, y una solución.
- Son soluciones generalizadas establecidas que resuelven los problemas que son comunes a situaciones diferentes de negocio.
- Pueden ser reutilizados repetidamente y pueden ser combinados y adaptados de muchos modos diferentes.
- Se encuentran en todas las fases de desarrollo, desde el modelado de negocio hasta la codificación real y las etapas de pruebas.
o patrón de negocio
o patrones arquitectónicos
o patrones de diseño
Patrón de Negocio
- Tratan con problemas dentro del dominio del negocio, ejemplo como cómo modelar y estructurar los recursos del negocio que incluyen facturas, organización, información, etcétera.
- También se orientan a cómo organizar y relacionar procesos de negocio, reglas de gestión, visiones corporativas, y objetivos.
- El entendimiento de una situación de problema depende del conocimiento y la experiencia del modelador, los modelos y frameworks existentes, el proceso perceptual y los patrones aprendidos.
- Los patrones son un complemento al método de análisis y son útiles en el análisis de situaciones de negocio
- No son transferibles directamente a código. Se usan para crear modelos de negocio comprensibles y flexibles, que describan la estructura y conducta de un negocio;
- Estos modelos se pueden usar posteriormente para crear sistemas de información que apoyen el negocio.
Patrones en UML
• UML es el primer lenguaje de modelado que proporciona un símbolo específico y visual que representa un patrón.
• Este símbolo UML es la llamada colaboración.
- Muchos problemas recurrentes que se encuentran al modelar sistemas de negocio ya han sido resueltos.
- Los patrones permiten capturar y describir estos problemas de modelado de negocio y sus correspondientes soluciones de modo que las soluciones se puedan reutilizar
- Un patrón es una solución generalizada que puede ser implementada y aplicada en un problema (un contexto), y así eliminar uno o más problemas inherentes con el fin de satisfacer uno o más objetivos.
- “Cada patrón es una regla de 3 partes, la cual expresa una relación entre cierto contexto, un problema, y una solución.
- Son soluciones generalizadas establecidas que resuelven los problemas que son comunes a situaciones diferentes de negocio.
- Pueden ser reutilizados repetidamente y pueden ser combinados y adaptados de muchos modos diferentes.
- Se encuentran en todas las fases de desarrollo, desde el modelado de negocio hasta la codificación real y las etapas de pruebas.
o patrón de negocio
o patrones arquitectónicos
o patrones de diseño
Patrón de Negocio
- Tratan con problemas dentro del dominio del negocio, ejemplo como cómo modelar y estructurar los recursos del negocio que incluyen facturas, organización, información, etcétera.
- También se orientan a cómo organizar y relacionar procesos de negocio, reglas de gestión, visiones corporativas, y objetivos.
- El entendimiento de una situación de problema depende del conocimiento y la experiencia del modelador, los modelos y frameworks existentes, el proceso perceptual y los patrones aprendidos.
- Los patrones son un complemento al método de análisis y son útiles en el análisis de situaciones de negocio
- No son transferibles directamente a código. Se usan para crear modelos de negocio comprensibles y flexibles, que describan la estructura y conducta de un negocio;
- Estos modelos se pueden usar posteriormente para crear sistemas de información que apoyen el negocio.
Patrones en UML
• UML es el primer lenguaje de modelado que proporciona un símbolo específico y visual que representa un patrón.
• Este símbolo UML es la llamada colaboración.
21.6.12
Consejos para Escribir casos de Uso
Consejos Para Escribir Casos de Uso
Introducción
Escribir buenos casos de usos es más un arte que una ciencia. Y comoen cualquier arte, no existen reglas absolutas para crear obras maestras.
Finalmente, los casos de uso consisten en comunicar de forma clara
información detallada a diversas audiencias, y alcanzar el objetivo de crear
desarrollos de proyectos exitosos.
Ivar Jacobson inventó los Casos de Usos. María Ericsson trabajó junto a
Jacobson y fue la coautora de uno de sus libros. Kurt Bittner junto a Ian Spence
también escribieron un popular libro sobre Casos de Uso. Estos pioneros y
mucha gente de IBM, que tienen años de experiencia trabajando con clientes
para desarrollar buenos casos de uso, han contribuido a las tecnologías
descritas en este documento.
Escribir un buen caso de uso no es fácil, pero, afortunadamente, nuestra
experiencia puede ser su guía.
Los conceptos y principios aquí reunidos representan el trabajo de
muchas personas en IBM, los cuales forman un fundamento de mejores
prácticas probadas. Muchos de los consejos a los que hace alusión este
documento son parte de la metodología RUP de IBM, otros son nuevos y no
han sido incluidos dentro de RUP.
12.6.12
Diagrama de clases
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
5.6.12
Software de modelamiento - Freeware
StarUML genera todo tipo de diagramas compatibles con la plataforma de programas Microsoft Office.
StarUML se maneja con facilidad. En un vistazo a la interfaz se ven las funciones principales del programa. Otra característica importante del programa es que su código es compatible con C++ y Java.
Puedes comenzar a dibujar los gráficos manualmente o seleccionar las plantillas que contiene el archivo de instalación para modificarlas. Esta última opción es muy recomendable para quien no ha trabajado con archivos UML / MDA. Para este caso quizá te convenga buscar en la página del autor los módulos y plantillas más adecuados para tu proyecto.
Link Descarga: https://sourceforge.net/project/showfiles.php?group_id=152825&package_id=169190&release_id=437438
BizAgi Process Modeler edita croquis destinados a representar de forma gráfica conceptos, problemas o procesos de diversa índole.
El módulo de dibujo proporciona varios tipos de conectores y cajas de distintos colores para que se identifiquen con modelos de relación entre los conceptos.
Una vez dibujados, los mapas conceptuales pueden exportase fácilmente en un archivo de imagen PNG, JPG y BMP, en un fichero de Word o en un PDF.
3.5.12
Diagrama de Flujo, Ejemplo
Calcular los promedios de un numero X de alumnos, cada uno con 3 notas, se debe mostrar por pantalla si esta aprobado o reprobado utilizaremos la escala del 1 al 7, de un 4 para arriba esta aprobado)
1.- vemos que proceso debemos vamos a ocupar para la creacion del diagrama
a) Declarar las variables al utilizar: Nota1,Nota2,Nota3,Suma,Promedio
b) Ingresar notas
c) Sumar las notas
d) El resultado de la suma, dividirlo por 3
e) Ver si este nuevo resultado es mayor o igual a 4
f) Si es mayor, mostrar aprobado, de lo contrario mostrar reprobado
e) Pregunta si se quieren ingresar las notas de otro alumno
g) Si la respuesta es si, volver al paso “b” (no es necesario volver al a, ya que las variables estan declaradas)
b) Ingresar notas
c) Sumar las notas
d) El resultado de la suma, dividirlo por 3
e) Ver si este nuevo resultado es mayor o igual a 4
f) Si es mayor, mostrar aprobado, de lo contrario mostrar reprobado
e) Pregunta si se quieren ingresar las notas de otro alumno
g) Si la respuesta es si, volver al paso “b” (no es necesario volver al a, ya que las variables estan declaradas)
2.- Entonces, primero que todo, iniciamos el diagrama y declaramos variables:
3.- Ahora ingresamos las notas:
4.- Realizamos el proceso de sumar las 3 notas:
5.- Dividimos la suma en 3 (Cantidad de notas, en este caso es un numero fijo):
6.- Vemos si es igual o mayor a 4:
7.- Preguntamos si quieren calcular otro promedio:
Y el Diagrama completo se ve así (no se puede agrandar):
14.4.12
Introducción a los Artefactos UML para BPMN
Diagramas de casos de uso (Modelo conceptual)
- UML se especializa en representar fenómenos del “mundo real”
- Condujo al desarrollo de UML Business Modeling Profile
- Los perfiles UML adaptan el lenguaje a las áreas específicas - tal como, modelado de negocio, o para tecnologías particulares
Preguntas prácticas
• ¿Realmente, cuándo necesitamos un modelo de negocio?
• ¿Cuándo solamente los modelos de casos de uso son suficientes?
• ¿Cuál diagrama UML se debería usar para modelar un caso en particular de procesos de negocio?
• ¿Cómo sé si hay que usar un diagrama de secuencia o un diagrama de colaboración, por ejemplo?
• ¿Cómo se relacionan los modelos de negocio UML con otros modelos de UML (el modelo de dominio, el modelo de caso de uso, etc.)?
La descripción de un Caso de Uso debería incluir
• Comentarios generales y anotaciones que describan el caso.
• Requerimientos: cosas que el caso de uso debe permitir hacer al usuario.
• Restricciones: reglas acerca de qué se puede hacer y qué no se puede hacer.
– Pre-condiciones que deben ser verdaderas antes que el caso de uso “esté corriendo”, por ejemplo, <crear pedido> debe preceder a <modificar pedido>
– Post-condiciones que deben ser verdaderas una vez que el caso de uso “esté corriendo”, por ejemplo, <pedido es modificado y es consistente>
– Invariantes: estas deben ser siempre verdaderas, por ejemplo, un pedido siempre debe tener un número de cliente.
• Escenarios: descripción secuencial de los pasos necesarios para llevar adelante el caso de uso. Puede incluir múltiples escenarios.
• Diagramas de escenario: diagramas de secuencia similares a los workflow, pero representados gráficamente.
• Atributos adicionales: tales como fases de implementación, número de versión, grado de complejidad, estereotipo y estatus.
Especificación de un Caso de Uso
• Límites: Cuándo empieza y cómo termina el Caso de Uso.
• Interacciones: Comportamiento de Actores y Sistema. Acción-Reacción dentro del Caso de Uso.
• Masa: Conjunto de Objetos e Interfaces que requiere el Caso de Uso.
• índice de escenarios: Flujo principal de eventos y secuencia de variaciones posibles dentro de un Caso de Uso.
• Excepciones: Contingencias probables que pueden afectar al flujo de los eventos y son excepciones del Caso de Uso.
- UML se especializa en representar fenómenos del “mundo real”
- Condujo al desarrollo de UML Business Modeling Profile
- Los perfiles UML adaptan el lenguaje a las áreas específicas - tal como, modelado de negocio, o para tecnologías particulares
Preguntas prácticas
• ¿Realmente, cuándo necesitamos un modelo de negocio?
• ¿Cuándo solamente los modelos de casos de uso son suficientes?
• ¿Cuál diagrama UML se debería usar para modelar un caso en particular de procesos de negocio?
• ¿Cómo sé si hay que usar un diagrama de secuencia o un diagrama de colaboración, por ejemplo?
• ¿Cómo se relacionan los modelos de negocio UML con otros modelos de UML (el modelo de dominio, el modelo de caso de uso, etc.)?
La descripción de un Caso de Uso debería incluir
• Comentarios generales y anotaciones que describan el caso.
• Requerimientos: cosas que el caso de uso debe permitir hacer al usuario.
• Restricciones: reglas acerca de qué se puede hacer y qué no se puede hacer.
– Pre-condiciones que deben ser verdaderas antes que el caso de uso “esté corriendo”, por ejemplo, <crear pedido> debe preceder a <modificar pedido>
– Post-condiciones que deben ser verdaderas una vez que el caso de uso “esté corriendo”, por ejemplo, <pedido es modificado y es consistente>
– Invariantes: estas deben ser siempre verdaderas, por ejemplo, un pedido siempre debe tener un número de cliente.
• Escenarios: descripción secuencial de los pasos necesarios para llevar adelante el caso de uso. Puede incluir múltiples escenarios.
• Diagramas de escenario: diagramas de secuencia similares a los workflow, pero representados gráficamente.
• Atributos adicionales: tales como fases de implementación, número de versión, grado de complejidad, estereotipo y estatus.
Especificación de un Caso de Uso
• Límites: Cuándo empieza y cómo termina el Caso de Uso.
• Interacciones: Comportamiento de Actores y Sistema. Acción-Reacción dentro del Caso de Uso.
• Masa: Conjunto de Objetos e Interfaces que requiere el Caso de Uso.
• índice de escenarios: Flujo principal de eventos y secuencia de variaciones posibles dentro de un Caso de Uso.
• Excepciones: Contingencias probables que pueden afectar al flujo de los eventos y son excepciones del Caso de Uso.
Suscribirse a:
Entradas (Atom)