PARCIAL #1.
Análisis de sistemas
Presentado por:
Camilo Esteban Rodriguez Forero.
Andres Mauricio Clavijo.
Jhon Alexander Chacon Torres.
Brayan Andrés Valero Pinzón.
Presentado a:
Juan Carlos Guevara Bolaños.
Universidad Distrital Francisco José de Caldas.
Sistematización de datos.
Facultad Tecnológica.
Bogotá D.C. Colombia,viernes 1 de abril de 2016.
1. Describa los temas que abarca la ingeniería de software. Este punto
consiste en realizar los siguientes puntos:
1.1. Definición de la ingeniería de software
“La aplicación de un enfoque sistemático (ordenado), disciplinado y
cuantificable al desarrollo, operación y mantenimiento de software, esto es, la
aplicación de la ingeniería en el área del software.” Definición de IEEE.
Es aquella aplicación práctica del conocimiento científico en el diseño y
construcción de programas de computadora y la documentación asociada
requerida para desarrollar, su trabajo es promover la creatividad, el desarrollo
y la integración, compartir y aplicar los avances en las tecnologías de la
información, electrónica y ciencias en general para beneficio de la humanidad
y de los mismos profesionales.
1.2. Mapa conceptual de los temas que conforman el cuerpo de
conocimiento de la ingeniería de software
Imágen No.01 Mapa conceptual del cuerpo de conocimiento de la
ingeniería de Software. SWEBOK.
Imágen No.02 Mapa conceptual del cuerpo de conocimiento de la
ingeniería de software. SWEBOK.
Imágen No.03 Mapa conceptual del cuerpo del conocimiento de la
ingeniería de software. SWEBOK
1.3 Describir de manera general que abarca cada uno de los temas
Requisitos: Se refiere a la elicitación, análisis, especificación y
validación de los requisitos software.
Diseño: El proceso de diseño de software consiste en analizar los
requisitos con el fin de producir una descripción de la estructura
interna del software que sirva como base para su construcción.
Diseño: El proceso de diseño de software consiste en analizar los
requisitos con el fin de producir una descripción de la estructura
interna del software que sirva como base para su construcción.
Construcción: Se refiere a la creación detallada de software mediante
la combinación de codificación, verificación, pruebas unitarias, pruebas
de integración y depuración.
Pruebas: Sirve para evaluar la calidad de un producto software o para
mejorarlo, mediante la identificación de sus defectos y problemas.
Mantenimiento: Todo producto software, después de su despliegue o
entrega, “está destinado” a cambiar o evolucionar.
Gestión de la configuración: Es la disciplina de identificar la
configuración de un sistema en distintos momentos en el tiempo con el
fin de controlar sistemáticamente los cambios y mantener la integridad
y trazabilidad.
Gestión de la ingeniería: Consiste en aplicar actividades de gestión
(planificar, coordinar, medir, supervisar, controlar e informar) para
asegurar que el desarrollo y mantenimiento de software se realizan de
forma sistemática, disciplinada y cuantificable.
Procesos de ingeniería: Se refiere a la definición, implementación,
evaluación, medición, gestión, cambio y mejora de los propios
procesos del ciclo de vida del software.
Herramientas y métodos: Las herramientas (basadas en
computador) ayudan a realizar los procesos del ciclo de vida del
software. Los métodos imponen una manera o estructura para realizar
las actividades de ingeniería del software, de forma que el trabajo sea
más sistemático y más exitoso.
Calidad: En este área se abordan las técnicas estáticas para alcanzar
la calidad del software.
1.4 Describa de manera general en que se aplican cada uno de los
temas en el desarrollo de un proyecto de software.
Cada tema se aplica durante el proceso de la planificación de los proyectos
de software debido a que cada uno de los elementos conforma un
subconjunto de características que permiten seguir con la siguiente etapa en
la planeación, en este caso alguno de los que se encuentran en las
imágenes. Por otra parte cada elemento carece de información que es
obligatoria para poder continuar con otro, esto hace énfasis a que en un caso
hipotético de que no se haya realizado cierto punto de la planeación este
mismo generará problemas con el siguiente, tal es el caso de realizar un
proyecto sin hacer primero el estudio de requerimientos del software.
2. Describa el proceso de desarrollo de software para un proyecto de software.
Este punto consiste en realizar los siguientes puntos:
1) Definición de procesos de desarrollo de software
Requerimientos
Diseño
Implementación
Verificación
Mantenimiento
2) Descripción de las etapas de un proyecto de software
Análisis y requerimientos:Extraer los requisitos de un producto de software
es la primera etapa para crearlo. Mientras que los clientes piensan que ellos
saben lo que el software tiene que hacer, se requiere de habilidad y
experiencia en la ingeniería de software para reconocer requisitos
incompletos, ambiguos o contradictorios.
Diseño: Se refiere a determinar cómo funcionará de forma general sin entrar
en detalles. Consiste en incorporar consideraciones de la implementación
tecnológica, como el hardware, la red, etc. Se definen los Casos de Uso para
cubrir las funciones que realizará el sistema, y se transforman las entidades
definidas en el análisis de requisitos en clases de diseño, obteniendo un
modelo cercano a la programación orientada a objetos.
Desarrollo: Reducir un diseño a código puede ser la parte más obvia del
trabajo de ingeniería de software, pero no es necesariamente la porción más
larga. La complejidad y la duración de esta etapa está íntimamente ligada al o
a los lenguajes de programación utilizados.
Pruebas: Consiste en comprobar que el software realice correctamente las
tareas indicadas en la especificación. Una técnica de prueba es probar por
separado cada módulo del software, y luego probarlo de forma integral,para
así llegar al objetivo.
Documentación: Todo lo concerniente a la documentación del propio
desarrollo del software y de la gestión del proyecto, pasando por
modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales
técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad,
mantenimiento futuro y ampliaciones al sistema.
Mantenimiento: Mantener y mejorar el software para enfrentar errores
descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que
el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de
software tiene que ver con dar mantenimiento. Una pequeña parte de este
trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en
extender el sistema para hacer nuevas cosas.
3) Realizar un mapa conceptual sobre los diferentes artefactos que se
pueden realizar para cada etapa del proceso de software
3. Realizar un comparación entre dos metodologías de desarrollo de software
(Scrum, XP, RUP, Métrica 3, entre otras). Este punto comprende por cada
metodología: 1) Nombre de la metodología, 2) Descripción de actividades, 3)
Descripción de artefactos que apoyan el desarrollo de cada actividad y 4) Un
ejemplo de aplicación.
Nombre Metodologia RUP SCRUM
Descripción de
actividades
Modelado del negocio
Requisitos
Análisis/Diseño
Implementación
Pruebas
Despliegue
Gestión de Cambios y
configuración
Gestión del proyecto
El sprint
Reunión de planificación
de Sprint
Objetivo del sprint
Scrum diario
Revisión de sprint
Retrospectiva de sprint
Descripción de artefactos
de cada actividad
Modelo de casos de uso
del negocio.
Modelo de objetos del
negocio.
Modelo de casos de
uso.
Visión.
Especificaciones de
casos de uso.
Prototipos de interfaces
de usuario.
Modelo de análisis y
diseño.
Lista de producto
(Product Backlog)
Lista de Pendientes del
Sprint(Sprint Backlog)
Incremento
Modelo de datos.
Modelo de
implementación.
Modelo de despliegue.
Casos de prueba.
Descripción de Actividades RUP:
Ingeniería o modelado del negocio: Analizar y entender las
necesidades del negocio para el cual se está desarrollando el
software.
Requisitos: Proveer una base para estimar los costos y tiempo de
desarrollo del sistema.
Análisis y diseño: Trasladar los requisitos analizados anteriormente a
un sistema automatizado y desarrollar una arquitectura para el
sistema.
Implementación: Crear software que se ajuste a la arquitectura
diseñada y que tenga el comportamiento deseado.
Pruebas: Asegurarse de que el comportamiento requerido es correcto
y que todo lo solicitado está presente.
Despliegue: Producir distribuciones del producto y distribuirlo a los
usuarios.
Descripción de actividades Scrum:
El Sprint: es un bloque de tiempo (timebox) de un mes o menos
durante el cual se crea un incremento de producto “Terminado”,
utilizable y potencialmente desplegable. Es más conveniente si la
duración de los Sprints es consistente a lo largo del esfuerzo de
desarrollo. Cada nuevo Sprint comienza inmediatamente después de
la finalización del Sprint previo.
Reunión de Planificación de Sprint (Sprint Planning Meeting): El
trabajo a realizar durante el Sprint se planifica en la Reunión de
Planificación de Sprint. Este plan se crea mediante el trabajo
colaborativo del Equipo Scrum completo. La Reunión de Planificación
de Sprint tiene un máximo de duración de ocho horas para un Sprint
de un mes. Para Sprints más cortos, el evento es usualmente más
corto.
Objetivo del Sprint (Sprint Goal): El Objetivo del Sprint es una meta
establecida para el Sprint que puede ser alcanzada mediante la
implementación de la Lista de Producto. Proporciona una guía al
Equipo de Desarrollo acerca de por qué está construyendo el
incremento. Es creado durante la reunión de Planificación del Sprint. El
objetivo del Sprint ofrece al equipo de desarrollo cierta flexibilidad con
respecto a la funcionalidad implementada en el Sprint.
Scrum Diario (Daily Scrum):El Scrum Diario es una reunión con un
bloque de tiempo de 15 minutos para que el Equipo de Desarrollo
sincronice sus actividades y cree un plan para las siguientes 24 horas.
Esto se lleva a cabo inspeccionando el trabajo avanzado desde el
último Scrum Diario y haciendo una proyección acerca del trabajo que
podría completarse antes del siguiente.
Revisión de Sprint (Sprint Review): Al final del Sprint se lleva a cabo
una Revisión de Sprint para inspeccionar el Incremento y adaptar la
Lista de Producto si fuese necesario. Durante la Revisión de Sprint, el
Equipo Scrum y los interesados colaboran acerca de lo que se hizo
durante el Sprint. Basándose en esto, y en cualquier cambio a la Lista
de Producto durante el Sprint, los asistentes colaboran para
determinar las siguientes cosas que podrían hacerse para optimizar el
valor.
Retrospectiva de Sprint (Sprint Retrospective): La Retrospectiva de
Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí
mismo y crear un plan de mejoras que sean abordadas durante el
siguiente Sprint. La Retrospectiva de Sprint tiene lugar después de la
Revisión de Sprint y antes de la siguiente reunión de Planificación de
Sprint. Se trata de una reunión restringida a un bloque de tiempo de
tres horas para Sprints de un mes. Para Sprints más cortos se reserva
un tiempo proporcionalmente menor.
Descripción de artefactos RUP:
Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio
Es un modelo de las funciones de negocio vistas desde la perspectiva de los
actores externos (Agentes de registro, solicitantes finales, otros sistemas
etc.). permite situar al sistema en el contexto organizacional haciendo énfasis
en los objetivos en este ámbito.
Modelo de Casos de Uso
El modelo de Casos de Uso presenta las funciones del sistema y los actores
que hacen uso de ellas. Se representa mediante Diagramas de Casos de
Uso.
Visión
Este documento define la visión del producto desde la perspectiva del cliente,
especificando las necesidades y características del producto. Constituye una
base de acuerdo en cuanto a los requisitos del sistema.
Especificaciones de Casos de Uso
Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o
que no baste con una simple descripción narrativa) se realiza una descripción
detallada utilizando una plantilla de documento, donde se incluyen:
precondiciones, postcondiciones, flujo de eventos, requisitos nofuncionales
asociados.
Prototipos de Interfaces de Usuario
Se trata de prototipos que permiten al usuario hacerse una idea más o menos
precisa de las interfaces que proveerá el sistema y así, conseguir
retroalimentación de su parte respecto a los requisitos del sistema. Estos
prototipos se realizarán como: dibujos a mano en papel, dibujos con alguna
herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese orden
de acuerdo al avance del proyecto.
Modelo de Análisis y Diseño
Este modelo establece la realización de los casos de uso en clases y
pasando desde una representación en términos de análisis (sin incluir
aspectos de implementación) hacia una de diseño (incluyendo una
orientación hacia el entorno de implementación), de acuerdo al avance del
proyecto.
Modelo de Datos
Previendo que la persistencia de la información del sistema será soportada
por una base de datos relacional, este modelo describe la representación
lógica de los datos persistentes, de acuerdo con el enfoque para modelado
relacional de datos.
Modelo de Implementación
Este modelo es una colección de componentes y los subsistemas que los
contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de
código fuente, y todo otro tipo de ficheros necesarios para la implantación y
despliegue del sistema.
Modelo de Despliegue
Este modelo muestra el despliegue la configuración de tipos de nodos del
sistema, en los cuales se hará el despliegue de los componentes.
Casos de Prueba
Cada prueba es especificada mediante un documento que establece las
condiciones de ejecución, las entradas de la prueba, y los resultados
esperados. Estos casos de prueba son aplicados como pruebas de regresión
en cada iteración.
Descripción de artefactos Scrum:
Lista de Producto (Product Backlog)
La Lista de Producto es una lista ordenada de todo lo que podría ser
necesario en el producto, y es la única fuente de requisitos para cualquier
cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es
el responsable de la Lista de Producto, incluyendo su contenido,
disponibilidad y ordenación.
Lista de Pendientes del Sprint (Sprint Backlog)
La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de
Producto seleccionados para el Sprint, más un plan para entregar el
Incremento de producto y conseguir el Objetivo del Sprint.
La Lista de Pendientes del Sprint es una predicción hecha por el Equipo de
Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento
y del trabajo necesario para entregar esa funcionalidad en un Incremento
“Terminado”.
Incremento
El Incremento es la suma de todos los elementos de la Lista de Producto
completados durante un Sprint y el valor de los incrementos de todos los
Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe estar
“Terminado”, lo cual significa que está en condiciones de ser utilizado y que
cumple la Definición de “Terminado” del Equipo Scrum. El incremento debe
estar en condiciones de utilizarse sin importar si el Dueño de Producto decide
liberarlo o no.
Ejemplo de aplicación Rup:
El objetivo de esta página web es mostrar un ejemplo de desarrollo de
software basado en la metodología de Rational Unified Process (RUP). El
proyecto es el desarrollo de un sistema para la gestión de artículos deportivos
de una empresa del sector de ventas de deportes a clientes tanto a
mayoristas como a minoristas. Se incluye hasta la segunda iteración de la
fase de construcción, según la división establecida en el documento Plan de
Desarrollo Software. Por motivos de privacidad no se pueden publicar los
datos de la entidad para la que se diseñó el software.
Gracias a la metodología rup el desarrollo e implementación este problema
es realizable de manera mas comoda.
En el ejemplo planteado se analizan los requerimientos, se hace un análisis y
diseño del problema una vez hecho esto se procede a la etapa de
implementación luego prueba y desarrollo, todo esto mediante iteraciones
lineales concurrentes.
Ejemplo de aplicación Scrum:
Un cliente solicita software contable para su empresa.
El cliente se reúne con el Dueño de producto, quien toma nota de la idea del
cliente.
El Dueño del producto divide el proyecto en historias que son las que
componen la pila del producto.
El Scrum master es un miembro del equipo que tiene el papel de comunicar y
gestionar las necesidades del Dueño de Producto y la pila de sprint.
El Dueño de producto le entrega la pila de producto para que estimen el coste
de creación del producto.
El equipo se reúne para determinar el coste de cada historia de la pila del
producto, por medio por ejemplo del Planning Poker.
El cliente, una vez aprobado el presupuesto, reordena la pila de producto
para que el equipo vaya trabajando según la prioridad del cliente.
El equipo comienza su trabajo desglosando la primera historia de la pila de
producto, lo cual subdividen en tareas menores para crear la pila de sprint.
La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de 15
días en tareas más pequeñas, que tardan como mucho dos días.
Estas tareas se colocan en una pila, la cual prioriza el Dueño del producto,
que ha consultado con el cliente, antes de comenzar el sprint.
El equipo comienza el sprint tomando las tareas priorizadas.Una vez
concluida una se toma la siguiente de la lista. Se convoca todos los días una
reunión del equipo donde se cuenta las tareas realizadas el día anterior y
cuáles se van a realizar ese dia.
Una vez finalizado el sprint, el Dueño del producto le muestra al cliente el
resultado del trabajo realizado. El cliente ya tiene el primer contacto con su
encargo y además puede volver a priorizar la pila de producto antes de que
comience otro sprint.
El equipo de trabajo hace una reunión de retrospectiva, donde se analiza lo
ocurrido durante el sprint. Esta reunión se celebra fuera de la oficina,
normalmente con comida y bebidas de por medio.
4. Aplicación de un software que nos permita calcular métricas de software.
Este punto consiste en realizar los siguientes puntos:
4.1) Definición de métricas:
Las métricas son la maduración de una disciplina, que, según Pressman van
a ayudar a la (1) evaluación de los modelos de análisis y de diseño, (2) en
donde proporcionarán una indicación de la complejidad de diseños
procedimentales y de código fuente, y (3) ayudaran en el diseño de pruebas
más efectivas; Es por eso que propone un proceso de medición, el cual se
puede caracterizar por cinco actividades:
(1) Formulación: La obtención de medidas y métricas del software apropiadas
para la representación de software en cuestión.
(2) Colección: El mecanismo empleado para acumular datos necesarios para
obtener las métricas formuladas.
(3) Análisis: El cálculo de las métricas y la aplicación de herramientas
matemáticas.
(4) Interpretación: La evaluación de los resultados de las métricas en un
esfuerzo por conseguir una visión interna de la calidad de la representación.
(5) Realimentación: Recomendaciones obtenidas de la interpretación de
métricas técnicas transmitidas al equipo de software.
El objetivo de la ingeniería del software es desarrollar y producir software de
alta calidad.
Para lograr este objetivo, es fundamental aplicar métodos y herramientas
efectivos dentro del contexto de un proceso maduro de desarrollo de
software.
Las métricas del Software se refiere a un amplio elenco de medidas para el
Software de computadora.
La medición se puede aplicar al proceso de Software con el intento de
mejorarlo sobre una base continua.
Podemos definir las Métricas de Software o Medidas de Software como:
La aplicación continua de técnicas basadas en las medidas de los procesos
de desarrollo de Software y sus productos, para producir una información de
gestión significativa y a tiempo.
Esta información se utilizará para mejorar esos procesos y los productos que
se obtienen de ellos.
4.2) Mapa conceptual donde se visualice la manera de clasificar las
métricas:
4.3) Seleccionar un software que exista y aplicarle el software de
métricas:
se decidió mostrar con un breve ejemplo algunas de las aplicaciones de
ciertas métricas planteadas para un proyecto de software x.
Ejemplo:
El responsable del proyecto necesita saber si la productividad es
adecuada.
Conocer el nivel de productividad de los programadores del proyecto
en comparación con lo habitual en otros proyectos de la organización.
Ahora bien, con el ejemplo anterior no se puede captar con certeza la
aplicación de las métricas en un proyecto de software, se considera que hay
que usar un software ya existente al cual se le puedan aplicar las métricas y
tipos de métricas a utilizar.
Software existente: Modelos de Procesos de Negocio con BPMN
Antecedentes:
Este trabajo está basado en la propuesta FMESP, la cual consiste en un
marco para el modelado y medición del proceso software.
FMESP está basado en la idea de que es necesario llevar a cabo una buena
administración de los procesos software con el propósito de obtener
productos software con calidad, y tal gestión la considera de una manera
integrada abarcando dos importantes aspectos:
El modelado y la evaluación del proceso. Como resultado, proporciona el
soporte conceptual y tecnológico para el modelado y medición de procesos
software para promover su mejora.
Para la evaluación del proceso software, FMESP incluye un conjunto de
métricas las cuales miden la complejidad estructural de los modelos de
proceso software (MPS).
El objetivo es evaluar la influencia de la complejidad estructural de los MPS
en su mantenibilidad. Las métricas de FMESP han sido definidas en dos
niveles diferentes:
a) A nivel de modelo, para evaluar la complejidad estructural del
modelo en su totalidad.
b) A nivel de los elementos fundamentales del modelo, para evaluar la
complejidad concreta de elementos tales como las actividades, los
roles o los productos de trabajo.
Las métricas de FMESP fueron definidas analizando el metamodelo SPEM y
están clasificadas en métricas base, las cuales se obtienen contando el
número de constructores más significativos del metamodelo SPEM y sus
relaciones y métricas derivadas, las cuales son obtenidas como resultado de
aplicar funciones de medición en otras métricas base y/o derivadas.
Los modelos de procesos de negocio (MPN) tienen un amplio rango de usos
tales como el soporte a la reingeniería de procesos, la simulación ó servir
como base para el desarrollo de sistemas que automatizan dichos procesos.
Los MPN pueden ser creados o presentados usando diversos lenguajes, que
son bastante diferentes entre sí, dado que cada uno tiene una manera
diferente de ver los procesos dependiendo del propósito para el cual fueron
creados. De los lenguajes mencionados en la literatura, los siguientes
merecen especial atención para el modelado de procesos de negocio: IDEF0,
IDEF3 , UML, UML 2.0 y BPMN. Ésta última es la notación estándar del BPMI
en la cual está basado nuestro trabajo.
BPMN proporciona una notación gráfica para expresar procesos de negocio
mediante un Diagrama de Proceso de Negocio (DPN), que está basado en
una técnica de diagramas de flujo adaptada para la creación de modelos
gráficos de las operaciones de procesos de negocio. Un DPN está
compuesto de dos categorías básicas de elementos: la primera son los
elementos centrales con los cuales es posible desarrollar modelos de
procesos simples y; la segunda incluye los elementos que permiten la
creación de MPN complejos o de alto nivel.
Las cuatro clases que componen la lista de elementos centrales son los
Objetos de Flujo, Objetos de Conexión, Carriles y Artefactos. Los símbolos
correspondientes a los elementos centrales se muestran en la Tabla 1.
Además dentro de cada categoría de dichos elementos centrales hay una
lista más extensiva de constructores de procesos de negocio en la notación
BPMN que constituyen la lista completa de elementos, los cuales se
mostrarán en el siguiente apartado al definir las métricas para MPN.
Tabla 1. Elementos Centrales en un Diagrama de Procesos de Negocio
Aplicando FMESP a Modelos de Procesos de Negocio con BPMN:
El objetivo con la definición y la validación de las métricas en FMESP es el de
determinar un grupo de indicadores útiles para la mantenibilidad de los
modelos de proceso software evaluando su complejidad estructural. La
propuesta de FMESP está basada en el hecho de que la investigación en la
medición de procesos software ha estado centrada en el estudio de los
resultados de la ejecución y no en la repercusión que podría tener la
complejidad estructural de los modelos de procesos en su calidad.
Una situación similar sucede en el área del modelado de procesos de
negocio. Como resultado de la investigación por parte de la gente de
negocios, en la literatura se pueden encontrar diversas propuestas para la
evaluación de procesos, la mayoría desde el punto de vista de los resultados
obtenidos en su ejecución. Lo que significa que los aspectos evaluados en la
investigación sobre la medición de procesos de negocio corresponden
principalmente al nivel de ejecución del proceso, donde incluso se han
considerado dos categorías de métricas: operativas y estructurales. Por otro
lado, también existen propuestas o marcos de trabajo para evaluar la calidad
de las técnicas para el modelado de procesos de negocio.
Considerando nuestro interés en evaluar los procesos de negocio a partir del
modelo que lo representa en un nivel conceptual, nuestro trabajo recaptura la
propuesta de FMESP, adaptándola y extendiéndola a modelos de proceso de
negocio. Para lograr tal objetivo, hemos definido un conjunto de métricas para
evaluar la complejidad estructural de los MPN en un nivel conceptual.
La meta es tener evidencia empírica acerca de la influencia que la
complejidad estructural de los MPN puede tener en su mantenibilidad. Esto
puede proporcionar a las compañías de la base cuantitativa necesaria para
desarrollar MPN más mantenibles. El primer paso para lograr esta meta ha
sido definir un conjunto de métricas apropiadas para la evaluación de la
complejidad estructural de los modelos de proceso de negocio. La definición
de estas métricas está basada en los elementos que componen el
metamodelo de BPMN y han sido agrupadas en dos categorías principales:
Métricas Base y Métricas Derivadas.
Las métricas base han sido definidas contando los diferentes tipos de
elementos que componen un MPN representado con BPMN. En la Tabla 2 se
muestran las métricas base definidas para el constructor “Evento”
perteneciente a la categoría de Objetos de Flujo del metamodelo BPMN. Se
ha definido una métrica para cada uno de los disparadores de eventos (inicio,
intermedio y finales) con los cuáles es posible identificar la causa del inicio o
final del flujo dentro del modelo, así como los elementos que modifican el flujo
en un punto intermedio del mismo.
El constructor “Actividad” es otro de los elementos pertenecientes a la
categoría de Objetos de Flujo del metamodelo BPMN; y una actividad en el
diagrama de proceso de negocio puede ser de dos clases: actividades
atómicas (Tareas) ó actividades compuestas (SubProcesos Colapsados). A
su vez dentro de cada una de estas dos clases se pueden observar distintos
tipos de tareas o subprocesos. En la Tabla 3 se muestran las métricas base
definidas para cada uno de los cuatro tipos de tareas y los cinco tipos de
subprocesos colapsados existentes en el metamodelo BPMN.
Tabla 2. Métricas Base para el Elemento Evento de los Objetos de Flujo
del DPN.
Tabla 3. Métricas Base para el elemento Actividad de los Objetos de
Flujo del DPN
Dentro de la misma categoría de Objetos de Flujo, está el elemento “Decisión
ó Unión” que es el elemento usado para controlar la divergencia y
convergencia del flujo de secuencia. En el DPN hay cinco tipos de decisiones
o uniones, para los cuales se ha definido una métrica en función de cada uno
de ellos (ver Tabla 4).
Con las métricas mostradas en la Tabla 4, es posible conocer el número de
Decisiones/Uniones que generan bifurcaciones o uniones del flujo de
secuencia en punto específico del proceso. Otros elementos importantes a
considerar dentro de los elementoscentrales del DPN, correspondientes a las
categorías de Objetos de Conexión, Carriles y Artefactos, son mostrados en
la Tabla 5, con sus respectivas métricas base.
La propuesta de métricas para modelos de procesos de negocio incluye
algunas métricas derivadas significativas que establecen las proporciones
existentes entre los diferentes elementos del modelo y que son obtenidas en
función de las métricas base. Las métricas derivadas definidas para modelos
de proceso de negocio desarrollados con BPMN se muestran en la Tabla 6.
Tabla 4. Métricas Base para los tipos de control de Decisiones de los
Objetos de Flujo del DPN.
Tabla 5. Métricas Base para los Objetos de Conexión, Carriles y
Artefactos del DPN.
Tabla 6. Definición de Métricas Derivadas en función de las Métricas
Base.
Con las métricas base y derivadas propuestas, es posible evaluar la
complejidad estructural de los modelos de proceso de negocio expresados
con BPMN. Al analizar estructuralmente el modelo también puede ser
evaluada su calidad. En particular, esta evaluación puede hacerse en
referencia a los tres criterios de calidad para modelos conceptuales definidos
por Lindland : calidad semántica, calidad sintáctica y calidad pragmática.
Aplicación de las Métricas
Para ilustrar el cálculo de las métricas definidas para MPN, se proporciona un
ejemplo que ha sido tomado de. Este ejemplo (Figura 1) representa un
modelo de proceso concurrente de la ingeniería para diseñar un chip. Nuestro
objetivo es aplicar las métricas definidas en este trabajo para conocer sus
características estructurales.
Tabla 7. Nuevas Métricas Base definidas en función de la Notación
BPMN.
Tabla 8. Nuevas Métricas Derivadas en base a la Notación BPMN.
Los valores de las métricas de FMESP y de las específicas para BPMN que
han sido aplicadas al modelo de la figura anterior, son mostrados en las
tablas 9 y 10. Por razones de espacio, en el caso de las métricas para MPN,
sólo se muestran los valores de las métricas derivadas.
Como se puede observar, no existe diferencia significativa entre los valores
resultantes de aplicar las métricas para los dos tipos de procesos (software y
de negocio). Las principales diferencias resultan de las métricas para
Modelos de Proceso de Negocio basadas en elementos que no son
contemplados en SPEM, pero que resultan útiles a la hora de analizar
estructuralmente el modelo.
Tabla 9. Valor de las Métricas Definidas en FMESP
Tabla 10. Valor de las Métricas Derivadas con BPMN.
De esta manera, se comprueba que, aunque actualmente no se conocen en
la literatura propuestas de métricas para la evaluación de modelos de
proceso de negocio a nivel conceptual, es posible llevar a cabo su evaluación
aplicando métricas definidas para modelos de proceso software y definiendo
nuevas métricas específicas.
4.4) Describir los resultados generados:
Para concluir, se puede apreciar que en el ejemplo de los programadores del
proyecto se puede inferir no solo que un programador del proyecto sea
eficiente o rápido, sino que además de eso se puede concluir que tipo de
lógica usa el programador, además si es compatible con el resto de
programadores, si su tiempo de trabajo es menos efectivo que el del resto de
programadores, si es capaz de consolidar su trabajo con el del grupo y si se
pierde dinero y tiempo con los diferentes programadores del proyecto.
Resultados del software: Modelos de Procesos de Negocio con BPMN
Conclusiones y Trabajos Futuros:
En este trabajo se ha mostrado e ilustrado cómo el marco FMESP,
desarrollado inicialmente para el modelado y la medición de modelos de
procesos software, puede ser aplicado para evaluar los modelos de procesos
de negocio en un nivel conceptual. Considerando que en el campo de la
ingeniería de procesos no hay métricas aplicables a modelos de proceso de
negocio a nivel conceptual, se decidió hacer uso de las ideas de FMESP para
evaluar la complejidad estructural de los mismos.
Ha sido posible aplicar métricas para modelos de proceso software a
modelos de proceso de negocio representados en BPMN, dado que ambos
presentan ciertas similitudes en cuanto a los elementos centrales que los
componen. Sin embargo, ha sido necesario extender las métricas definidas
en FMESP para abarcar todos los aspectos considerados dentro de un MPN.
La adaptación ha sido relativamente fácil gracias a que en el marco FMESP
todas las métricas se representan a nivel del metamodelo SPEM, que se
caracteriza por su gran generalidad lo que permite utilizarlo como base para
otros tipos de procesos que no sean de ingeniería del software.
Integrando ambas propuestas, se ha proporcionado un marco más refinado
para la evaluación de modelos conceptuales de proceso de negocio. Esto da
soporte a la Gestión de Procesos de Negocio, al facilitar la evaluación
temprana de ciertas propiedades de calidad de los procesos de negocio. Las
métricas a nivel de modelo pueden ser muy útiles a la hora de seleccionar los
modelos con mayor facilidad de mantenimiento de entre diversas alternativas
en aquellas compañías que cambian sus modelos para mejorar sus procesos.
También puede ayudar a facilitar la evolución de los procesos de negocio en
estas compañías evaluando la mejora de los mismos en un nivel conceptual.
Las métricas de MPN proveen a las compañías de información objetiva
acerca de la mantenibilidad de dichos modelos. Modelos más mantenibles
pueden beneficiar la gestión de los procesos de negocio principalmente en
dos maneras: 1. Garantizando el entendimiento y la difusión de los procesos,
y su evolución, sin afectar su exitosa ejecución; 2. Reduciendo el esfuerzo
necesario para cambiar los modelos con la consecuente reducción del
mantenimiento.
Las métricas propuestas para MPN deben ser validadas experimentalmente
para saber si son útiles en casos reales. Por esta razón, actualmente se está
desarrollando una familia de experimentos con el propósito de evaluar
aspectos de calidad de modelos conceptuales de procesos de negocio. Estos
experimentos serán desarrollados con una población integrada por expertos
en análisis de negocios y en ingeniería del software para poder comparar los
resultados de ambos tipos de perfiles y determinar la influencia de estos
diferentes puntos de vista.
Los participantes recibirán material consistente en un conjunto de MPN
representados con BPMN. Los modelos tendrán diferentes características y
dimensiones pensadas a propósito. También se proporcionará un
cuestionario por cada uno de los modelos que incluirán preguntas
relacionadas con su entendibilidad y complejidad. Para evaluar cómo influye
la notación BPMN en la modificabilidad de los modelos, otra sección adicional
del cuestionario preguntará acerca de diversas modificaciones
(especialmente estudiadas) al modelo original.
5. Describa un modelo de trabajo colaborativo para su grupo de trabajo. Este
punto consiste en realizar los siguientes puntos:
1) Definición de Colaboración.
La colaboración es la ejecución grupal de un trabajo, actividad o proyecto
específico donde las personas tienen la misión de concretar un mismo
objetivo con el fin de obtener los mejores resultados, en el cual las personas
pueden tomar roles diferentes o tareas pero trabajandolas colaborativamente
entre sus gestores con responsabilidad y solidaridad siempre sobre el trabajo
a desarrollar, la colaboración implica la ayuda de cada individuo de un
proyecto con sus demás integrantes, además que para que a colaboración
hace referencia a un grupo de miembros con habilidades específicas ya sean
profesionales o técnicas que le permiten a un grupo colaborarse mutuamente
con un mismo fin.
2.1) Definición de Coordinación.
La coordinación en un trabajo, proyecto o actividad puede entenderse como
el proceso en el cual se puede poner a un grupo de trabajo o individuos a
trabajar en conjunto diferentes objetivos o propuestas en pos de obtener un
resultado específico para acciones conjuntas, coordinar tiene la tarea
fundamental de hacer una planificacion y ordenacion de las diferentes tareas
para quienes formaran parte del grupo, además tiene el fin de generar ciertos
resultados para triunfar con las metas establecidas.
2.2) Definición de Comunicación.
La comunicación es parte importante de cualquier actividad que se realice ya
sea individual o en grupo, la comunicación permite el intercambio de ideas e
información entre determinadas personas,se realiza con el fin de transmitir o
recibir información a través de ruidos o señales que permiten la captación de
ideas, en proyectos grupales la comunicación es parte fundamental durante
todo el proceso desde su inicio hasta el final, pues esta permite transmitir
información de un persona a otra (de un analista a un programador) para que
se realicen ciertos pasos o acciones determinadas de tal manera con el fin de
conseguir u obtener algo y no se cometan errores no deseados.
2.3) Definición de Negociación.
La negociación es una actividad o proceso que se da entre dos personas o
más partes, donde suelen existir dos distintos puntos de vista o posiciones
siempre en disputa sobre un mismo asunto, las negociaciones son una
actividad en las que hay intereses compartidos pero opuestos, en el cual
siempre se trata de alcanzar una acuerdo que satisfaga al máximo los
intereses de cada parte o persona que hace parte de la negociación, dentro
de trabajos y proyectos la negociación es una de las habilidades más
importantes que el project manager debe poseer para poder tratar
efectivamente con clientes, gerentes funcionales, miembros del equipo del
proyecto, etc.
3) Definición de trabajo colaborativo.
El trabajo colaborativo es una actividad que se realiza en grupos de trabajo
pero estos grupos de trabajo no siempre realizan trabajo colaborativo, este es
una herramienta para el desarrollo de procesos o actividades efectivas y
productivas dentro de un trabajo o proyecto, el trabajo colaborativo es una
estrategia de aprendizaje y enseñanza que se suele organizar en grupos de
trabajo, donde hay un objetivo común, donde cada integrante reconoce sus
habilidades y sus deficiencias para fortalecer la unión y colaboración de unos
con otros, el trabajo colaborativo exige a los participantes habilidades como la
comunicación, relaciones simétricas y deseos de compartir la resolución de
tareas.
4) Inventario de patrones de colaboración (esto se puede obtener desde
el área de la ingeniería de la colaboración o desde protocolos de
sistemas multiagente como FIPA)
Generación: permite acumular conceptos necesarios para el proceso que se
pueda compartir con todos los integrantes del grupo.
Reducción: permite seleccionar los conceptos de mayor importancia de
forma tal que la base conceptual que se tenía se hace más pequeña.
Clarificación: permite que cada integrante del equipo tenga un mayor
manejo y conocimiento de los conceptos manejados, las palabras claves y las
frases indicadas para el tema que se está tratando.
Organización: permite clasificar y estructurar los temas que se está tratando,
para generar un mayor conocimiento a cada integrante.
Evaluación: permite una consideración más detallada de los conceptos que
el grupo está tratando.
Construcción de consenso: permite consolidar el grupo que se va a
comprometer con el objetivo final.
Mesa redonda (Round table) o Lluvia de ideas (Brainstorming) La
estructura de mesa redonda es muy útil para generar una gran cantidad de
ideas en un corto periodo de tiempo. Las explicaciones, las evaluaciones y
las preguntas no están permitidas mientras dure el proceso de generación de
ideas. Para comenzar, el profesor debe plantear una o varias preguntas que
tengan un gran número de respuestas posibles. Los grupos disponen del
tiempo suficiente para revisar y clarificar sus ideas.
Piensa, discute y comparte (thinkpairshare) Ésta es una estructura
relativamente sencilla adecuada tanto para profesores como para estudiantes
que son nuevos en el aprendizaje colaborativo. El profesor propone una
cuestión abierta y da a los estudiantes un tiempo para que reflexionen
individualmente acerca de la misma. Seguidamente, los estudiantes se
emparejan para discutir sus ideas con un compañero durante el tiempo que
decida el profesor. De este modo, todos los estudiantes tienen la oportunidad
de discutir sus ideas. Esto es muy importante dado que les permite comenzar
a construir su conocimiento así como averiguar qué es lo que saben y qué es
lo que no. Las respuestas recibidas son habitualmente más concisas dado
que los estudiantes han podido reflexionar previamente sobre sus ideas.
Resolución de problemas en voz alta por parejas (Think Aloud Pair
Problem Solving) Esta estructura tiene como objetivo fomentar la habilidad
del estudiante para resolver problemas mediante la verbalización de sus
pensamientos durante el proceso de solución del mismo. Durante la
realización de esta actividad, los miembros de cada grupo deben turnarse a
la hora de encargarse de resolver un problema o de escuchar al que lo está
haciendo.
Rompecabezas (Jigsaw) divide la clase en varios grupos que deben
resolver un mismo problema. Se asigna a cada alumno dentro del grupo la
tarea de estudiar la información relativa a una porción de dicho problema.
Seguidamente, se forman “grupos de expertos” en los que los estudiantes
discuten y profundizan en el subproblema del que son especialistas.
Finalmente, los estudiantes vuelven a sus grupos originales para poner en
común sus conocimientos y encontrar una solución al problema global. Esta
técnica requiere una fuerte implicación por parte de los participantes pero, por
otro lado, fomenta el intercambio comunicativo y la interdependencia positiva.
Pirámide (Pyramid). plantea un problema común a toda la clase que los
estudiantes resuelven de manera individual. Cada estudiante se une con un
compañero para discutir las soluciones que propusieron individualmente
antes de plantear una solución común. Y así sucesivamente hasta que se
forman dos grandes grupos en la clase que se unen para discutir las
soluciones planteadas en cada uno de ellos con el objetivo de proponer una
solución final. La correcta realización de la estructura de pirámide facilita la
generación de múltiples ideas para la solución del problema que ha sido
planteado.
Simulación (Simulation) Este patrón es muy útil en un contexto en el que
miembros de uno o varios grupos interpretan un rol en la simulación de una
situación. Cada participante consulta información acerca del problema que va
a ser simulado y prepara su papel. A continuación, los miembros del mismo
grupo de simulación (generalmente grupos pequeños) interpretan una
simulación particular del problema. Posteriormente es posible realizar las
simulaciones delante del resto de la clase. Al final, toda la clase puede
discutir y compartir sus conclusiones acerca del problema.
5) Describir las actividades colaborativas de su grupo de trabajo,
Definir y aclarar puntos.
Asignación de roles por habilidad.
Interactividad.
Revisión del material.
Comparación y aclaración de ideas.
Evaluación de la actividad.
Discusión de la actividad y corrección.
6) Seleccionar los patrones colaborativos que más acercan a las
actividades de colaboración que realizan.
Mesa redonda (Round table) o Lluvia de ideas (Brainstorming)
Rompecabezas (Jigsaw)
Piensa, discute y comparte (thinkpairshare)
Clarificación
Construcción de consenso
7) Modelas las actividades colaborativas (en este punto se puede mirar
ejemplos de actividades colaborativas modeladas en AUML.
Diagrama de Secuencia.
Diagrama de colaboración.
Referencias :
http://es.slideshare.net/FlowersInSpace/introduccionascrumconcasoprctic
o1516220
http://www.scrumguides.org/docs/scrumguide/v1/ScrumGuideES.pdf
http://clases3gingsof.wikifoundry.com/page/Artefactos+Arquitectura+de+Softw
are
http://www.udistrital.edu.co:8080/documents/276352/356568/Cap3RolesArtef
actosProceso
http://es.slideshare.net/eccutpl/armandocabreraisummit2010
http://www.uv.mx/mis/files/2012/11/HernandezRodriguezFernandezPena.pdf
http://users.dcc.uchile.cl/~mmarin/revistasccc/scccweb/Vol6/Art09.pdf
http://es.slideshare.net/isisparada/metricasdecalidaddesoftware
http://4.bp.blogspot.com/4EHaxeAVMYU/UMi8Wi1svOI/AAAAAAAAARs/nRY
mcRxrMnE/s1600/Mapa%2BMental%2BM%C3%A9tricas%2Bde%2BCalidad
%2Bde%2BSoftware.jpg
https://prezi.com/xjirfskkr2ke/metricasdeevaluaciondesoftware/
http://eprints.ucm.es/11487/
http://www.desarrolloweb.com/articuloscopyleft/articulometricasdesoftware.
html
http://uptaprocesodepruebasycalidadymetricas.blogspot.com.co/2012/12/ejem
plosdemetricas.html
http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ANALISI
S_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20II/2.3.
HTM
http://www.bdigital.unal.edu.co/15377/1/9982180581PB.pdf
http://www.informaticahabana.cu/sites/default/files/ponencias/EDU054.pdf
http://www.learningreview.com/noticiastecnologias/3438modeloparaeldise
nodeactividadescolaborativasmediantelautilizaciondeherramientasweb
20
http://escritura.proyectolatin.org/inteligenciaartificial/sistemasmultiagentes/
http://www.csintranet.org/competenciaslaborales/index.php?option=com_cont
ent&view=article&id=173:negociacion&catid=55:competencias
http://biblioteca.itson.mx/oa/educacion/oa7/ventajas_del_trabajo_colaborativo
/t3.htm
http://definicion.de/comunicacion/
http://www.definicionabc.com/general/coordinacion.php
http://www.ctr.unican.es/asignaturas/is1/is1t01trans.pdf
http://bibliotecadigital.usbcali.edu.co/jspui/bitstream/10819/2432/1/Definicion_
Proceso_Trabajo_Colaborativo_Pol_Proyectos_Ortiz_2014.pdf
