Modelado de procesos de negocio
Definición de la visión del negocio
En esta etapa se describe “hacia dónde va “del negocio, sus objetivos, misión, etc. También se establecen los objetivos de negocio, la estrategia general del negocio, además sirve como herramienta de motivación entre los involucrados.
La visión del negocio cuenta con unos elementos vasitos, estos son:
- Misión/ Visión de la empresa
- Objetivos
- Fortalezas/ Debilidades
- Oportunidades
- Factores críticos
- Estrategias
- Roles
- Procesos clave
Esto nos permite posicionar el negocio en el “hoy y mañana”, dándole un contexto y determinando los objetivos de la organización. Además de la planificación y definición general de procesos y recursos clave.
Modelado de objetivos
El objetivo de alto nivel del negocio, se descompone en estrategias, objetivos y metas concretas para alcanzarlos.
Modelado de Casos de Uso
La esencia de los Casos de Uso es descubrir y almacenar requerimientos funcionales, escribiendo historias de uso de un sistema y así ayudar a lograr diferentes objetivos de los participantes de un proyecto. Para lograr entender el alcance y utilidades de los Casos de Uso, es necesario hacer una serie de definiciones formales.
- Actores: Un actor especifica un rol que adopta una entidad externa al negocio que interacciona directamente con el sistema. Estos actores significan roles y no entidades concretas.
- Trabajador de negocio: Es un rol dentro de la organización, estos son roles mas no posiciones, una persona puede tener varios roles, pero una sola posición.
- Entidad de negocio:
- Caso de Uso: Es una colección de escenarios con un objetivo común, estos escenarios especifican un comportamiento que proporciona un resultado observable valioso para uno o más actores. El caso de uso representa una tarea que el sistema está obligado a proporcionar a los actores en beneficio de los interesados.
- Actividades:
Diagrama de actividades del negocio y los flujos de objetos
Representa la relación entre una actividad y el objecto que esta crea. No necesita una transición si su diagrama tiene dos actividades conectadas a través de un objeto y dos flujos de objetos correspondientes.
Documentación o especificación textual de Casos de Uso
Identificación de procesos de negocio
Para identificar los procesos de negocio es muy importante tener en cuenta que deben generar un valor para el negocio o mitigar los costos del negocio. Se proponen 3 vías para identificar procesos de negocio. Ellas son:
- Clasificación de los procesos de negocio.
- Identificación de funciones.
- A partir de los objetivos estratégicos.
El tener los procesos definidos nos permiten:
- Comunicación efectiva acerca del proceso entre los usuarios, desarrolladores, gerentes, clientes e investigadores.
- Mejora de la comprensión de la gerencia, entregando una base precisa para la automatización del proceso y facilitando la movilidad del personal.
- Facilita la reutilización del proceso, disminuyendo los costos asociados a la definición de procesos.
- Soporta la evolución del proceso proveyendo de medios efectivos para el aprendizaje del proceso y un sólido fundamento para la mejora de procesos.
- Ayuda en la administración del proceso. La administración efectiva requiere planes claros y una manera precisa y cuantificada de medir el estado contra ellos. Los procesos definidos hacen posibles tales herramientas.
Modelado de diseño del negocio
Se denomina ventana de contexto porque es la interfaz que soporta el contexto de uso relacionado con un grupo de actividades y que posee la información necesaria para ejecutar dichas actividades.
Para diseñar la interfaz de usuario de negocio y promover la reutilización se aconseja identificar, con ayuda de los usuarios, las tareas más importantes y frecuentes del sistema y los datos que necesitarían para realizar dichas tareas. Los usuarios interactúan con las aplicaciones de proceso a través de interfaces de usuario.
Puntos de automatización
Automatización de los procesos de negocio: ventajas y tendencias. La automatización de procesos de negocio abarca varias técnicas y actividades que tienen como objetivo sistematizar y facilitar los procesos de las empresas, mediante la eliminación de residuos y obstáculos (entre otros procedimientos) para hacerlos más eficientes, además de recopilar información para que podamos optimizar estos procesos de forma continua y también tomar decisiones más asertivas.
En este post, vamos a contextualizar rápidamente cuatro puntos importantes de automatización de procesos de negocio:
- Estrategias
- Soluciones
- Tendencias
- Beneficios
A continuación, vamos a ver algunos casos de automatización de procesos de negocio que fueron muy exitosos.
Estrategias para la automatización de procesos de negocio
Existen varias metodologías y estrategias para la automatización de procesos de negocio, tales como el cambio de paradigma, el rediseño de procesos y la mejora continua.
En todas, el objetivo es definir una nueva forma de llevar a cabo los procesos de la empresa, alineando su aplicación tanto con los objetivos y metas estratégicas de la organización, como con la entrega de más valor para el cliente final, lo que garantiza la total satisfacción de sus necesidades.
Las soluciones para la automatización de procesos de negocio
El control de las tareas humanas por medio de la automatización generalmente ocurre con las tareas repetitivas, pero esa no es la única forma en que la automatización es útil.
Otros factores importantes son; permitir un flujo de información más transparente y ágil, con alertas y disparos de correos electrónicos automatizados – especialmente cuando los trabajos cambian de manos (las denominadas transferencias), además de proporcionar las condiciones necesarias para la captura y medición de indicadores clave de rendimiento (KPI) en diversas etapas del proceso.
Así que si en el primer caso, el de la automatización de tareas repetitivas, el uso de la integración entre los sistemas a través de la API puede ser una solución rápida y sencilla, para la automatización más compleja y estructurada se necesita algo más robusto.
Por lo tanto, la solución más recomendada son los software de automatización de procesos de negocio que también hacen el modelado y la documentación de los procesos.
Modelo de Dominio
Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea construcción del modelo del dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física.
Los modelos de dominio pueden utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir.
El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.
Crear un modelo de dominio (conceptual) para los Casos de Uso, no puede hacerse si no se cuenta con los Casos y con documentos que permitan identificar los conceptos, también conocidos como objetos. La creación no siempre es lineal, puede formularse en paralelo con el desarrollo de los Casos de Uso.
Porque fallan los proyectos de software?
Proyecto exitoso: Es un proyecto completado a tiempo y dentro del presupuesto.
Proyecto Desviado: Es un proyecto terminado y operable, pero sobre el presupuesto, fuera del plazo y con pocas características y funcionalidades.
Proyecto cancelado: Es un proyecto cancelado antes de completarse o un proyecto que nunca se implemento.
Algunos de los motivos por los que fallan los proyectos de software son:
- Falta de soporte
- Falta de recursos
- Requisitos/ especificaciones incompletas o cambiantes.
- Usuario no involucrado
- Expectativas no realistas
- No se necesito al final del desarrollo
Costo de ajustar defectos en proyectos
- Errores en los requerimientos
- Errores en el diseño
- Errores en el código
Requisitos
Los requerimientos, el espacio problema y el espacio solución
- Los medios tradicionales de desarrollo de software empresarial subestiman la importancia del problema y su análisis.
- Se centra en la solución
- La solución no esta alineada al negocio
Las necesidades tienen lugar en el espacio de la solución, pero surgen de las necesidades.
Que es un requerimiento?
El primer reto del trabajo de los requisitos es encontrar, comunicar y recordar (registrar), lo que se necesita realmente, de manera que se tenga un significado claro para el cliente y los miembros del equipo de desarrollo.
Los requisitos mal definidos
- Ambigüedad
- Definición incompleta
- Definición con contradicciones
- Confusión entre requisitos
- Conjunción entre los requisitos
Calidad de los requisitos
- Completos: todo lo que se supone que el software debe hacer está incluido
- Consistentes: No existen subconjuntos de requisitos contradictorios
- No ambiguos: todo requisito posee una sola interpretación
- Entendibles: Todo tipo de actores los entienden
- Factibles: Con los actuales recursos, es implementable
- Modificables: Los cambios son fáciles de introducir
- Rastreables: Cada requisito se puede referenciar de forma unívoca
- Verificables: Si cada requisito tiene un indicador que demuestra que el
sistema lo satisface
Tipos de requisitos
- Requisitos del negocio
- Requisitos del usuario
- Requisitos del sistema
Clasificación de los requisitos
- Requisitos generales.
- Requisitos funcionales: Requisitos de Actores, requisitos de interfaz, Requisitos de procesamiento, requisitos de persistencia, requisitos de gestión y administración.
- Requisitos no funcionales: Fiabilidad, usabilidad, eficiencia, mantenibilidad, potabilidad, seguridad.
Atributos de los requerimientos
- Prioridad
- Estado
- Costo
- Propietario
- Nivel de test/ presedencia
- Iteracion
- Riesgo
- Categoria
- Dificultad
Dependencia entre los requisitos
7 técnicas de levantamiento de requerimientos
En la ingeniería de requisitos, el levantamiento de requerimientos se refiere a la indentificación y documentación de los requerimientos de un sistema, a partir de los usuarios, clientes o interesados (Stakeholder). También se le conoce como recopilación de requerimientos.
- Análisis de documentación: Obtiene información de los requerimientos funcionales y no funcionales, a partir de documentos ya elaborados.
- Observación: Consiste en estudiar el entorno de trabajo de los usuarios, clientes o interesados del proyecto. Existe dos clases de observadores, el activo que puede tener una conversación con el usuario y el pasivo que solo observa y toma nota.
- Entrevistas
- Encuestas o cuestionarios
- Mesas de trabajo
- Tormenta de ideas: Consiste en obtener la mayor cantidad de ideas, las cuales después podrían evaluarsen.
- Historia de usuario
Después del levantamiento de requerimientos, la información capturada puede ser incluida en una matriz de trazabilidad y una de especificaciones. Del levantamiento de requerimientos le sigue el análisis de los mismos, por medio de técnicas como descomposición, modelado de procesos, casos de uso, inspecciones y prototipos.
Porque es importante recoger bien los requerimientos?
- Ayudar al cliente a definir sus ideas: Ya que quizás el cliente no puede expresarla claramente.
- Acotar el alcance del proyecto: El presupuesto y el calendario, se establecen en base a los requerimientos iniciales, esto por si el cliente desea agregar nuevas ideas a medio camino, esto obligara de inmediato a replantear los requerimientos iniciales y re evaluar todo el proyecto.
- Definir la hoja de ruta del equipo: SI los requerimientos no se han recogido a detalle, el equipo de proyecto no tendrá clara la ruta de sus tareas y responsabilidades.
- Establecer indicadores: Conocer los requerimientos del cliente es la única forma de poder establecer KPIS para medirlos y valorar durante etapas de seguimiento los logros obtenidos.
Esta metodología esta apoyada por una herramienta computacional desarrollada por el Instituto de Carnegie Mellon, que genera una serie de registros con información valiosa para llevar a cabo la siguiente planeación y para actualizar el plan al terminar cada programa de software.
Apuntes de ingeniería de software 