Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Organización y procesos de Negocios Organización Conjunto de personas reguladas por un conjunto de normas en función de determinados fines (DRAE). Es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma con arreglo a ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o servicios. Las actividades se pueden organizar de dos formas: Estructura funcional (vertical) estructura por procesos (horizontal). Para poder establecer una estructura de procesos es necesario conocer las actividades de la organización. Enfoque funcional Cada función busca optimizar sus propias actividades, incluso a costa del rendimiento global de la organización. Su foco de análisis es la tarea o función, su objetivo es la optimización de las tareas Se orienta al interior de la organización Tiene una visión fragmentada. Básicamente se centran en su área y se separan de los demás. Enfoque de procesos Se rompen las barreras funcionales por medio de las cuales se producen los productos y/o servicios. Se busca satisfacer al cliente Su foco de análisis es el proceso, su objetivo es la mejora de los procesos. Se orienta esencialmente al cliente Tiene una visión global. La idea es mejorar los procesos de negocio de la empresa como ingenieros de sistemas. Generalmente se establecen, en los libros, los niveles en una organización como una pirámide. Los niveles de mayor a menor serían: nivel estratégico (director); administrativo (gerentes de nivel medio); conocimiento (trabajadores del conocimiento); operativo (gerentes operativos). El nivel operativo se encarga de hacer que la organización funcione. Los trabajadores del conocimiento son los que tienen que tomar decisiones en ya si ocurren problemas en el área operativa. Los administradores son los que tienen que tomar decisiones a mediano plazo de cómo se trabaja en su área/proceso. Los directores son los que toman las decisiones a largo plazo de toda la compañía. ¿Que es un proceso de Negocio? Tenemos dos definiciones básicas: ● Un proceso es un orden específico a actividades a través del tiempo y lugar, con un comienzo y fin, estradas y salidas: una estructura para la acción. ● Un proceso de negocio es un conjunto de actividades que toman uno o más tipos de inputs y crean un output que es un valor para un cliente. Ejemplo: UN proceso de atención de un pedido: Ventas recibe el pedido e inicia el trámite, contabilidad verifica el crédito y se factura el pedido, manufactura produce el pedido y lo envía. Podemos concluir que un proceso de negocios es un conjunto de acciones/actividades que se rigen bajo unas reglas para transformar una entrada para crear una salida de valor para el cliente. Es conveniente conocer los tipos de procesos de negocio. Los libros indican que generalmente en una organización hay 3 procesos de negocio. ● Procesos principales: generan las salidas de valor para el cliente. ● Procesos de soporte: Ayudan a optimizar los procesos principales. Nunca hay clientes. ● Procesos de gestión: Se hacen actividades gerenciales que mantienen la empresa. Procesos Principales Los procesos principales o sustantivos son aquellos que están ligados directamente con la realización del producto y/o la prestación del servicio al cliente. Son los procesos de la línea, hacen realidad la misión de la organización. Proceso de Soporte Los procesos de soporte son aquellos que proporcionan apoyo a los procesos principales o sustantivos. Usualmente están relacionados con la gestión de recursos. Procesos de Gestión Los procesos de gestión son aquellos que están vinculados al ámbito de las responsabilidades de la dirección. Se relacionan con actividades de planificación y control. ¿Cómo se describen los procesos de negocio? Es más fácil establecer estos procesos de manera visible con un diagrama de actividades que con todas las reglas escritas. Algunas actividades se pueden hacer en paralelo a otras actividades. Gracias a los nuevos paradigmas que se presentan en las empresas gracias al paso del tiempo es lo que provoca que el esquema funcional deje de ser completamente útil y es necesario cambiar el enfoque. Por lo que se considera el uso del enfoque por procesos que permite una comunicación con todos los departamentos para poder llevar a cabo los objetivos, lo que nos permite una orientación hacia los resultados. Los clientes son importantes para las organizaciones, no se puede sobrevivir sin clientes, por lo que si lo tratamos de colocar en el enfoque funcional no es muy fácil saber donde colocarlo. Por lo que con el enfoque de procesos nos permite colocarlo al inicio de la comunicación horizontal de los departamentos, logrando una orientación hacia los clientes. Apuntes de video El desarrollo en una organización si o si será hecha por personas que sepan tomar decisiones. Y estas personas pueden ir aprendiendo, innovando y mejorando continuamente el proceso. Por lo que si tratamos de tener estos puntos en el enfoque funcional, esto sera mas dificil puesto que se tienen que seguir las directivas de los puestos más altos en la jerarquía y no permite la innovación por parte de los puestos más bajos que son los que estan al dia a dia con el área operativa y el cliente, aprendiendo sobre ella y puede que incluso innovando soluciones. Esto permite una autonomía por parte de las personas. Las actividades que realiza cada departamento deben de apuntar a agregar valor al producto final. Entonces podemos incluso agrupar actividades y llamarlas un proceso de negocio principal, incluso podríamos tener varios procesos en paralelo. Existen varios procesos que no agregan valor al producto pero son importantes para la empresa, como lo vimos en apuntes anteriores. Ahora, un proceso está constituido por entradas, salidas, objetivos, un encargado de que se cumplan los objetivos, y un procedimiento que puede incluir subprocesos. La gestión de procesos se define en 4 puntos: 1. Definir el mapa de procesos existentes y relaciones entre ellos, esto tiene que ser de manera general. 2. Establecer el proceso piloto, es preferible ser un proceso operativo, que afecta directamente al producto. El encargado de gestionar el proceso debe ser uno de los administrativos que tenga más interacción con el proceso. 3. Identificar misión y objetivos, entradas (proveedores) y salidas (clientes), procedimientos y actividades; y definir la sistemática de gestión seguimiento y mejora (personas, reuniones, indicadores, etc). Esto tiene que ser de manera general. 4. Aplicar la gestión del proceso y revisar que lo que establecimos en el paso tres se vaya cumpliendo. Modelado de Negocio Es una técnica para representar procesos del negocio. Permite asegurar que se construirá el sistema en el contexto de las necesidades de la empresa. El contexto está dado por: ● El ambiente en el que el sistema trabajara. ● Los roles y responsabilidades de los empleados que usarán el sistema. ● Las cosas que son manejadas en el negocio. Este modelo tiene dos perspectivas, el modelo de los casos de Uso del Negocio (perspectiva externa) y el modelo de análisis del negocio (perspectiva interna). En los casos de uso del negocio se establecen cuáles serán esos procesos que se realizarán en la organización, pero su descripción se hace en el modelo de análisis del negocio. Por lo que podemos indicar que primero se hacen los casos de uso y después el análisis. Modelos de casos de uso del negocio (CUN) Es una representación de la forma en que la empresa interactúa con su entorno, provee una visión general. Provee una visión general de lo que la empresa hace con sus clientes y participantes, este proceso solo los usaremos de manera muy superficial para poder diseñar el sistema. Incluye metas del negocio además de actores (generalmente clientes) y casos de uso del negocio (generalmente procesos). Los elementos del CUN son: ● Actores del negocio: Representa un rol que desempeña alguien o algo en la relación del negocio.● Caso de uso del negocio: Conjunto de secuencias de acciones que un negocio realiza para producir un resultado observable para un actor del negocio (pueden considerarse como los procesos de negocio (recordar que hay varios)). ● Meta del negocio: Describe el valor deseado en una medida particular que puede ser usada para planificar y administrar las actividades del negocio. ● Diagrama CUN: Muestra la relación de los elementos anteriores. Actor de negocio Para establecerlo es necesario revisar que el individuo, grupo, organización, empresa o máquina sea externo al negocio que interactúa con ella. Generalmente son: clientes, socios, proveedores o autoridades; entidades legales y reguladoras; sucursales; Dueños o inversionistas; sistemas informáticos fuera del negocio con los que se interactúa; o incluso si el negocio que se va a modelar es parte de una gran empresa, estas categorías también pueden contener actores de negocios, tales como: otras parte de la empresa y papeles individuales en el marco de otros departamentos. Caso de Uso del Negocio Los casos de uso del negocio son los procesos del negocio. Pueden ser de tres categorías: Principales, Soporte, Gestión. Las metas del negocio pueden ser minimizar tiempo, mejorar el servicio y confiabilidad y seguridad. Después solo se hace el modelo dibujado y listo. Modelo de Análisis de Negocio Describe la realización de los casos de uso del Negocio mediante la interacción de los trabajadores del negocio y las entidades del negocio. Los elementos del análisis del negocio son: ● Trabajador del negocio: Es una abstracción de una persona o sistema de software que representa un rol que se ejecuta dentro de la realización de un CUN ● Realización de caso de uso del negocio: Describe cómo los trabajadores, entidades y eventos del negocio colaboran para desarrollar un caso de uso del negocio. Se usan los diagramas de clases y de actividades para describirlos. ● Entidad del negocio: Representa una pieza de información significativa y persistente que es manipulada por los actores y trabajadores del negocio. Pueden estar dentro y fuera del negocio. ● Reglas de Negocio: Es una declaración de políticas o condiciones que deben de ser satisfechas. Introducción a los sistemas de información Datos: Los datos son registros de hechos/eventos no procesados. Los datos no tienen ningún significado en particular. Información: es un conjunto de datos para algún propósito en particular. Como ya están procesados ya tienen significado (Generalmente guardada en un Data Warehouse en una DB). Conocimiento: Es la información conectada a decisiones y acciones capaces de aplicar esa información. La información debe de tener los siguientes atributos: ● Correcta (Sin errores) ● Oportuna (Debe de estar siempre a tiempo) ● Disponible (se accede a ella siempre) ● Concisa (Tamaño y longitud delimitado) ● Relevante (Destacar siempre lo esencial) ● Completa (posibilidad de complementar, ampliar o hacer trazabilidad) Un sistema de información es un conjunto de componentes (Usuarios y Especialistas, hardware, software, datos/info, procedimientos) interrelacionados que permiten recopilar, procesar, almacenar y distribuir la información necesaria para apoyar la toma de decisiones, la coordinación y el control de una organización. Funciones de un sistema de información: ● Capturar ● Procesar ● Generar ● Almacenar ● Recuperar ● Transmitir Beneficios: ● Reducir y/o remplazar trabajo humano ● Procesar modelos complejos de análisis ● Comunicación a larga distancia ● Interconectar las partes de un proceso Todo Sistema de información va a cumplir objetivos. Para ello se necesitan los procedimientos y prácticas de trabajo que usarán información, personal y equipo (no solo de TI). Existen diferentes sistemas de información y estos están basados en la pirámide administrativa de la jerarquía en una organización: ● Operativo ● Conocimiento ● Administrativo ● Estratégico La función de estos sistemas es apoyar a las actividades de las jerarquías. hay otra forma de clasificar los sistemas de información y es según la función que desempeñan: ● Sistemas de procesamiento de transacciones ● Sistemas de información general ● Sistemas de soporte de decisiones ● Sistemas de información ejecutiva ● Sistemas de automatización de oficinas ● Sistemas Expertos ● ERP Estos sistemas fueron apareciendo de manera cronológica en las empresas. Proceso y Ciclo de vida del software Proceso de software Es un marco de trabajo que define las tareas a realizar para desarrollar software. Una visión genérica de estas fases de un proceso de software son: Definición, desarrollo y evolución. Definición: ● Análisis de sistema: Define el papel de cada elemento del sistema de información, asignando finalmente al software el papel que va a desempeñar. ● Requerimientos: Es lo que el usuario necesita que el proyecto realice. ● Planificación: cuánto, cómo y cuándo va a estar el proyecto software. Se deben de identificar la información que se debe proporcionar, funcionalidad y rendimiento deseado, interfaces a establecerse, restricciones de diseño y criterios de validación necesarios para definir que el sistema sea correcto. Desarrollo: ● Diseño: Definición de estructuras, pantallas, funciones, etc.; respecto a los requerimientos. ● Codificación: Traducción del diseño a un producto/prototipo ● Pruebas: Realizar Pruebas Se deben decidir cómo se van a diseñar las estructuras de datos y la arquitectura del software, la traducción del diseño a un lenguaje de programación y a un producto/ prototipo y las pruebas que se le realizarán. Evolución ● Corrección ● Adaptación ● Mejora Se debe de centrar en los cambios asociados a: corrección de errores, adaptaciones por evolución del entorno de software, modificaciones por parte de requisitos nuevos del usuario, y se repiten las primeras fases del proceso de software pero con lo que ya se tiene. Requerimientos De Acuerdo al Standish Group, los proyectos de software fallan un 18%, se desvían un 53% y se completan exitosamente un 29% en el año 2004. Un proyecto es exitoso cuando se cumple con tiempo, costo y con todas las características y funcionalidades especificadas. Los porcentajes de proyectos cancelados se deben a varios factores. De Acuerdo a CHAOS, A Standish Group Report (1998), se tiene que son por: ● Falta de soporte (9.3%) ● Falta de recursos (10.6%) ● Requisitos/especificaciones incompletas o cambiantes (21.8%) ● Usuarios no involucrados (12.4%) ● Expectativas no realistas (9.9%) ● No se necesito al final del desarrollo (7.5%) ● Problemas tecnológicos/técnicos varios (porcentaje restante) Generalmente se tienen errores en la especificación de requerimientos por problemas de comunicación entre los desarrolladores, clientes y usuarios. Si los errores se descubren tarde, terminan siendo caros de corregir a posteriori. Es importante separar el problema de la solución cuando se está analizando el sistema. Un error es pensar la solución cuando no se ha analizado el problema. En el espacio del problema se tiene el problema y las necesidades generadas por el problema. Estas necesidades serán definidas por el modelado del negocio. En el espacio de la solución, se aplicará ingeniería de requerimientos para obtener aspectos/características, requisitos de software y al último se realizan los procedimientos de pruebas, el diseño y la documentación del usuario para generar una solución que en nuestro caso será software. Para las necesidades se tendrán los stakeholders (usuarios) que serán los que tengan esas necesidades, las necesidades (que será una descripción del problema del stakeholder) y la característica que será una descripción de la función que haga el sistema para darle solución a la necesidad. Ahora, pasamos a los requerimientos pero es importante definirlos primero. Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se construye. De Acuerdo a la IEEE, un requisito es: ● Una condición o capacidad necesaria paraun usuario para resolver un problema o conseguir un objetivo ● Una condición o capacidad que debe reunir o poseer un sistema o componente de un sistema para satisfacer un contrato, estándar, especificación, u otro documento formalmente impuesto. ● Una representación documentada de una condición o capacidad como las definidas en los puntos anteriores. Hay varias maneras de clasificar los requerimientos pero la más común está descrita por el modelo FURPS+: ● Functionality (funcionalidad) Que debe de hacer el sistema respecto a su entorno Especifican comportamientos de Entradas y Salidas. Se captura con los casos de uso. ● Usability (capacidad de uso) Facilidad o nivel de uso del producto. Define factores Humanos Estética Consistencia de interfaz Ayudas en línea Agentes Wizards Documentación ● Reliability (fiabilidad) Capacidad para ejecutar sus funciones requeridas bajo condiciones normales en un periodo de tiempo específico. Subcategorías ■ Frecuencia/severidad de errores ■ Capacidad de recuperación ■ capacidad predictiva ■ Exactitud ■ Tiempo promedio entre fallas ● performance (Desempeño) ○ Velocidad ○ Eficiencia ○ Disponibilidad ○ Exactitud ○ Tiempo de respuesta ○ Tiempo de uso de recursos entre fallas ● Supportability (capacidad de Soporte) ○ Pruebas ○ Extensión ○ Adaptación ○ Mantenimiento ○ Compatibilidad ○ Configuración ○ Instalación y localización ● + ○ Restricciones de diseño ○ Implementación ○ Interfaz ○ Físicos ○ Etc. Los requerimientos no funcionales (también conocidos como adicionales) describen atributos del sistema o del ambiente en donde este se desarrolló (encapsulación de todos los que vimos que están en el +) Modelo de casos de uso El modelo de casos de uso es un modelo que describe los requerimientos funcionales del sistema en forma de Casos de Uso. Elementos del modelo: ● Actores Definir un conjunto coherente de roles que los usuarios del sistema pueden jugar cuando interactúan con el Una instancia de actor puede ser un individuo o un sistema externo Un actor puede interactuar con otro actor ● Casos de uso Un caso de uso define un conjunto de instancias de casos de uso Una instancia es una secuencia de acciones e interacciones entre el actor y el sistema que proporciona valor a un actor particular. ● Descripción del caso de uso Se usa una plantilla para hacer un registro de manera escrita de la información que conforma al caso de uso. Generalmente lleva: ○ Caso de uso: ■ Nombre del caso de uso ○ Actor: ■ Nombre del actor ○ Precondición: ■ Condición que debe ser verdadera para iniciar caso de uso. Estas se definen respecto al sistema y no al entorno. ○ Poscondición: ■ Condición que debe cumplirse para indicar que el caso de usa ha terminado con éxito. ○ Flujo de eventos básico: ■ Secuencia de eventos que describen qué hace el actor y el sistema en el caso de uso para cumplir un objetivo. También se conoce como flujo normal, pues no incluye variaciones o desviaciones. ○ Flujos de eventos alternativos: ■ Diversas secuencias que reflejan las diferentes situaciones que provocan una desviación del flujo básico de eventos. Son provocadas por condiciones: anormales, extremas, ocasionales, de error o violacion de las reglas del negocio para el caso de uso. Generalmente se usa con un formato a dos columnas donde se ve a la par las acciones del actor y del sistema en el flujo básico del caso de uso. ● Diagrama de casos de uso ○ Muestra la relación entre los casos de uso, actores y sistema de una manera gráfica. Los diagramas varían pero nosotros usaremos los de UML los cuales fueron aceptados por la OMG y se estandarizó en la ISO 19501. Por lo que nos basaremos en esos (generalmente en internet todos usan los mismos). Modelo de dominio Es un modelo conceptual que muestra clases conceptuales significativas en un dominio de problema. Las clases conceptuales no muestran componentes de software, ni clases de software, ni responsabilidades. La principal tarea del análisis orientado a objetos es identificar diferentes conceptos en el dominio del problema y documentar el resultado en un modelo de dominio El modelo de dominio se puede documentar con un diagrama de clases. 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, operaciones y las relaciones entre ellos. Los elementos del modelo de dominio son: ● Clases conceptuales ○ Es una idea, cosa u objeto. ○ Puede considerarse como ■ Símbolo ● palabras o imágenes que representan una clase conceptual. ■ Definición del concepto ■ Extensión: ● Conjunto de objetos que pertenecen a la clase. ● Asociaciones ○ Los objetos/cosas del mundo real se relacionan con otras cosas. Las relaciones entre objetos son enlaces y las relaciones entre clases se llaman asociaciones. ● Operaciones ○ Acciones que puede realizar la clase ● Atributos ○ Propiedad de una clase y describe un rango de valores que la propiedad podrá contener en los objetos de la clase. Especialización/Generalización Es una relación entre una subclase que hereda los métodos y atributos especificados de una superclase. Se llama generalización cuando varias subclases abstraen información más general de la superclase. Mientras que se llama especialización cuando la subclase tiene características más particulares. En prácticamente son los mismo y solo cambia el enfoque con lo que lo veas. Agregación Es cuando una superclase tiene como relación muchas subclases que la conforman. En una agregación la existencia de las partes es independiente de la existencia de la clase que la conforma (partes de una computadora - computadora). Mientras que una composición la existencia depende de la existencia de la clase que la conforma (municipios - estado). Para Construir un diagrama de clases es necesario: ● Identificar las clases, ● Identificar las Asociaciones ● Identificar los atributos ● Organizar usando herencias ● Verificar el modelo Matriz de trazabilidad Revisar PMBOK o artículos relacionados a él.
Compartir