jueves, 12 de junio de 2014

Anteproyecto - Problema

La siguiente información hace parte del anteproyecto titulado:
APLICACIÓN DE LA METODOLOGIA KIMBALL Y LA EDT A LA INTELIGENCIA DE NEGOCIOS EN LA GERENCIA DE DUQUESA S.A.
  

Presentado por: LUIS ARTURO SANTOS TIBADUIZA, ANDRES ENRIQUE RODRIGUEZ RODRIGUEZ y FREDY YAIR SUAREZ DIAZ

Hoy en día las grandes empresas trabajan continuamente con miras a satisfacer y cumplir las necesidades específicas de todos sus clientes en la fabricación de sus productos o servicios, pero hay que tener en cuenta que se manejan políticas de calidad y en este caso nos enfocaremos en una de ellas como por ejemplo una adecuada comunicación interna y externa que tiene como efecto una mejora continua en todos sus procesos, para garantizar la permanencia y competitividad de las organizaciones.
Ahora hay que tener en cuenta que dentro de los procesos de apoyo de una organización se encuentra el de gestión TICs cuyo objetivo es incorporar las tecnologías de la información y comunicación a todos los procesos, manteniendo el sistema de información actualizado en hardware, software y en línea como herramienta importante para la toma de decisiones.
Actualmente, en Duquesa S.A. se requieren gran cantidad de reportes y no cuenta con un procesamiento analítico en línea (OLAP) o una aplicación para la extracción de información de las bases de datos que permita aislar e identificar patrones o tendencias del mismo en un alto volumen de datos; por lo tanto no hay un sistema inteligente de negocios que sirva de soporte para la toma de decisiones gerenciales que permitan examinar de manera interactiva grandes volúmenes de información desde varias perspectivas. El análisis de la información se realiza en Excel teniendo como limitantes el número de registros máximo y que no se pueden cruzar todas las variables o dimensiones (vendedor, línea, sublínea, grupo, costo, cliente, canal, margen, cajas, kilos, dinero) que está limitada por Excel. Esta operación la realizan ingenieros en procesos de gestión de tecnología informática, ya que para los usuarios es más complejo y se requiere un alto nivel de Excel.

De acuerdo con lo anterior, cual es la principal causa por la cual no se ha elaborado un sistema inteligente de negocios para la empresa.


CAUSAS
PORCENTAJE
a.
Las dimensiones no se conocían bien en la base de datos.
Analítico de Excel inicialmente cubría la necesidad por tabla dinámica, es decir inicialmente porque con el paso de 1 a 10 años el volumen de la información creció considerablemente y ya la ejecución de una consulta se empezaba a ralentizar con el paso del tiempo y por lo tanto causando una enorme pérdida de tiempo y limitación del analítico.
Analítico de 1 cliente (sale toda la empresa) 100%, es decir se visualiza una consulta general y no por una empresa específica.
Algunas dimensiones (costo, kilos, margen) no existían, se fueron creando.
Los clientes de la información (Gerente, jefe de ventas “que en el momento no lo hay”, asistente de ventas, secretaria de gerencia) tienen poco conocimiento de Excel y sus requerimientos es que siempre llegan a sistemas sin estructurar un informe o una planilla.
20%
b.
El analítico de Excel no tiene todas las dimensiones, como las que siguen a continuación: Kilos, costo, flete, margen, publicidad, bonos, tipo de cliente.
De acuerdo con lo anterior cabe destacar las que si se tienen actualmente las siguientes dimensiones: Tipo de inventario, clasifica 1, clasifica2, sublínea, grupo, vendedor, zona, cajas, subtotal, total con IVA, ciudad.
20%
c.
La dimensión comisión “era manual” y la dimensión flete “no estaba en el sistema”
20%
d.
Informes de ventas personalizados para la gerencia eran diferentes a la configuración de la base de datos, es decir no estaban alineadas las bases de datos con los informes porque en ese entonces un usuario del sistema manejaba ese proceso con una macro de Excel.
10%

e.
Los datos eran livianos, ejemplo: Cooratiendas era 1 NIT, luego con el tiempo Cooratiendas paso a 300 NIT y fue así cuando se comenzó a manejar sucursales.

10%
g.
Falta conocimiento de los clientes, es decir de los usuarios del sistema, ya que en tiempo pasado se hizo un prototipo y no lo usaron en ese entonces, según porque también no les pareció fácil de usar.
10%
h.
Falta conocimiento para hacer algo que cubriera todas las necesidades.
10%

De acuerdo con la anterior tabla que contiene 7 causas, miremos el análisis del problema a nivel de diagrama de Pareto con una frecuencia mensual dentro de un periodo de tiempo de 132 meses comprendidos entre los años [2003 - 2013]:

Tabla 1.
CAUSAS
FRECUENCIA
% Relativo
% Acum
a
26,4
20%
20%
b
26,4
20%
40%
c
26,4
20%
60%
d
13,2
10%
70%
e
13,2
10%
80%
f
13,2
10%
90%
g
13,2
10%
100%
Total
132
100%



Anteproyecto - Objetivos

La siguiente información hace parte del anteproyecto titulado:
APLICACIÓN DE LA METODOLOGÍA KIMBALL Y LA EDT A LA INTELIGENCIA DE NEGOCIOS EN LA GERENCIA DE DUQUESA S.A.
  

Presentado por: LUIS ARTURO SANTOS TIBADUIZA, ANDRES ENRIQUE RODRIGUEZ RODRIGUEZ y FREDY YAIR SUAREZ DIAZ

Objetivo General

Elaborar un sistema inteligente de negocios, mediante la Estructura de Descomposición del Trabajo (EDT) y aplicando la metodología Kimball, para la toma de decisiones asertivas de la gerencia de Duquesa S.A.

Objetivo Especificos

  •  Elaborar el primer componente de la Estructura de Descomposición del Trabajo (EDT), mediante la realización de las siguientes actividades: (Plan del proyecto y levantamiento de requisitos), para la entrega del planeamiento de datos.
  •  Elaborar el segundo componente de la EDT, mediante la realización de las siguientes actividades: (Análisis dimensional, Diseño dimensional y el Datamar), para la entrega del análisis y estructura de datos.
  •  Elaborar el tercer componente de la EDT, mediante la realización de las siguientes actividades: (ETL, Cubo de datos), para la entrega de la integración de datos. 

Anteproyecto-Introduccion

La siguiente información hace parte del anteproyecto titulado:
APLICACIÓN DE LA METODOLOGIA KIMBALL Y LA EDT A LA INTELIGENCIA DE NEGOCIOS EN LA GERENCIA DE DUQUESA S.A.
  

Presentado por: LUIS ARTURO SANTOS TIBADUIZA, ANDRES ENRIQUE RODRIGUEZ RODRIGUEZ y FREDY YAIR SUAREZ DIAZ

La inteligencia de negocios es un detonador de la innovación porque da importancia a las empresas u organizaciones dándoles el poder de apoyarse en herramientas de trabajo que le permita a la gerencia tomar decisiones, la clasificación o predicción de las ventas, encontrar nuevos clientes, con el objetivo de anticiparse al futuro, de forma que con base en la información obtenida de un análisis de datos la gerencia pueda planear estratégicamente y mejorar todos sus procesos internos con el fin de lograr la satisfacción total del cliente y así generar un valor basado en conocimiento, es decir que lo que se vende en realidad no es la materia prima sino la tecnología y el conocimiento para fabricar productos que le permitan estar un paso adelante de la competencia. Hay que tener en cuenta que para el uso de estas herramientas es necesario contar con un software de aplicaciones que asista el análisis y la presentación de los datos. Una empresa que quiera ser competitiva a nivel mundial debe enfocar su trabajo en la dirección de generar valor basado en el conocimiento como un intangible que representa muchas ventajas que se han convertido en los pilares de las economías más desarrolladas del mundo; teniendo en cuenta que la inteligencia de negocios vista desde el modelo de inteligencia externa de negocios de 360 se compone de tres procesos dentro de la organización: Percepción del entorno, procesamiento de la información y actuación en consecuencia. El objetivo es que la gerencia de la organización pueda tener una percepción más completa de la realidad y pueda utilizar su creatividad con miras en la búsqueda de soluciones a los problemas que tenga que enfrentar. Si no se escatima tiempo y se empieza lo más pronto posible en la sistematización de la innovación así como lo sostiene en sus obras Peter Drucker, para no ignorar la ventaja que nos llevan los asiáticos, europeos y norteamericanos en la generación de valor basado en conocimiento.

Modelo 4+1

A veces la arquitectura del sofware tiene secuelas de un diseño del sistema que fue muy lejos en particionar prematuramente el software, o de un enfasis excesivo de algunos de los aspectos del desarrollo del sofware: ingenieria de datos o en eficiencia de ejecucion. A menudo la arquitectura tampoco aborda los intereses de todos sus clientes.

El modelo de 4+1 vistas fue desarrollo para remediar esta problemática. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema.
  • La vista lógica describe el modelo de objetos del diseño cuando se usa un método de diseño orientado a objetos. Para diseñar una aplicación muy orientada a los datos, se puede usar un enfoque alternativo para desarrollar algún otro tipo de vista lógica, tal como diagramas de entidad-relación.
  • La vista de procesos describe los aspectos de concurrencia y sincronizan del diseño.
  •  La vista física describe el mapeo del software en el hardware y refleja los aspectos de distribución.
  • La vista de desarrollo describe la organización estática del software en su ambiente de desarrollo.

Los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas cuatro vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta vista. La arquitectura evoluciona parcialmente a partir de estos escenarios.

De donde se puede aplicar la formula de Dwayne Perry y Alexander Wolf:

Arquitectura del software = {Elementos, Formas, Motivación/Restricciones}

Para cada vista definimos un conjunto de elementos (componentes, contenedores y conectores), captamos la forma y los patrones con que trabajan, y captamos la justificación y las restricciones, relacionando la arquitectura con algunos de sus requisitos.

Los arquitectos también pueden usar estilos de arquitectura para cada vista, y por lo tanto hacer que coexistan distintos estilos en un mismo sistema.

El modelo de 4+1 vistas es bastante genérico: se puede usar otra notación y herramientas que las aquí descritas, así como también otros métodos de diseño, especialmente para las descomposiciones lógicas y de proceso.

La arquitectura del software se trata de abstracciones, de descomposición y composición, se estilos y estética. También tiene relación con el diseño y la implementacion de la estructura de alto nivel del software.


Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requerimientos de funcionalidad y performance del sistema, así como también otros requisitos no funcionales tales como: confiabilidad, escalabilidad,portabilidad y disponibilidad del sistema.



  • Vista de Casos de Uso: que contiene requisitos desarrollados en las restantes vistas.
  • Vista Lógica: La arquitectura lógica apoya principalmente los requisitos funcionales lo que el sistema debe brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie de abstracciones clave, tomadas (principalmente) del dominio del problema en la forma de objetos o clases de objetos. Aquí se aplican los principios de abstracción, encapsulamiento y herencia. Esta descomposición no solo se hace para potenciar el análisis funcional, sino también sirve para idéntica mecanismos y elementos de diseños comunes a diversas partes del sistema.
  • Vista Física: La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementos identificados redes, procesos, tareas y objetos requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios.
  • Vista de Procesos: La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribución, integridad del sistema, de tolerancia a fallas. La vista de procesos también especiada en cual hilo de control se ejecuta efectivamente una operación de una clase identificada en la vista lógica.
  • Vista de Desarrollo: La vista de desarrollo se centra en la organización real de los módulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeñas bibliotecas de programas o subsistemas que pueden ser desarrollados por uno o un grupo pequeños desarrolladores. Los subsistemas se organizan en una jerarquía de capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capas superiores.


Desarrollo por capas

Cuando se construye software como producto empresarial o comercial, se llevan a cabo varias técnicas de manera que el desarrollo se haga en forma ordenada y así poder asegurar un avance continuo del proyecto, un producto final de calidad, y además realizar posteriores mejoras sea una tarea más fácil.  
Existen muchas prácticas de programación, dependiendo del tipo de software que se va a desarrollar y de la disciplina o disciplinas de programación que se utilicen en el desarrollo del producto. Una de las más utilizadas se llama la programación por capas, que consiste en dividir el código fuente según su funcionalidad principal.
La programación por capas es una técnica de ingeniería de software propia de la programación por
objetos, éstos se organizan principalmente en 3 capas: la capa de presentación o frontera, la capa de lógica
de negocio o control, y la capa de datos.
·         Capa de Presentación o Frontera:
La presentación del programa ante el usuario, debe manejar interfaces que cumplan con el objetivo principal de este componente, el cual es facilitar al usuario la interacción con la aplicación. Para esto se utilizan patrones predefinidos para cada tipo de aplicación y para cada necesidad del usuario. La interfaz debe ser amigable y fácil de utilizar, ya que el usuario final es el que se va a encargar de utilizar el sistema y de dar retroalimentación al equipo de desarrollo en caso de que haya algo que mejorar.
Las interfaces deben ser consistentes con la información que se requiere, no se deben utilizar más campos de los necesarios, así como la información requerida tiene que ser especificada de manera clara y concisa, no debe haber más que lo necesario en cada formulario y por último, las interfaces deben satisfacer los requerimientos del usuario, por lo cual no se debe excluir información solicitada por el usuario final y no se debe incluir información no solicitada por el mismo.
Dentro de la parte técnica, la capa de presentación contiene los objetos encargados de comunicar al usuario con el sistema mediante el intercambio de información, capturando y desplegando los datos necesarios para realizar alguna tarea. En esta capa los datos se procesan de manera superficial por ejemplo, para determinar la validez de su formato o para darles algún orden específico.
·         Capa de Lógica de Negocio o Control:
Es llamada capa de reglas de negocio porque en esta se definen todas las reglas que se deben cumplir para una correcta ejecución del programa.
Es aquí donde se encuentra toda la lógica del programa, así como las estructuras de datos y objetos encargados para la manipulación de los datos existentes, así como el procesamiento de la información ingresada o solicitada por el usuario en la capa de presentación.
Representa el corazón de la aplicación ya que se comunica con todas las demás capas para poder llevar a cabo las tareas. Por ejemplo, mediante la capa de presentación obtiene la información ingresada por el usuario, y despliega los resultados. Si la aplicación se comunica con otros sistemas que actúan en conjunto, lo hace mediante esta capa. También se comunica con la capa de datos para obtener información existente o ingresar nuevos datos.
Recibe los datos que ingresó el usuario del sistema mediante la capa de presentación, luego los procesa y crea objetos según lo que se necesite hacer con estos datos; esta acción se denomina encapsulamiento.
Al encapsular los datos, el programa asegura mantener la consistencia de los mismos, así como obtener información precisa de las bases de datos e ingresar en las mismas, solamente la información necesaria, asegurando así no tener datos duplicados ni en las bases de datos, ni en los reportes solicitados por el usuario.
·         Capa de Datos:
Es la encargada de realizar transacciones con bases de datos y con otros sistemas para obtener o ingresar información al sistema.
El manejo de los datos debe realizarse de forma tal que haya consistencia en los mismos, de tal forma los datos que se ingresan así como los que se extraen de las bases de datos, deben ser consistentes y precisos.
Es en esta capa donde se definen las consultas a realizar en la base de datos, tanto las consultas simples como las consultas complejas parla generación de reportes más específicos.
Esta capa envía la información directamente a la capa de reglas de negocio para que sea procesada e ingresada en objetos según se necesite, esta acción se denomina encapsulamiento

Ventajas
Al implementar este modelo de programación, se asegura un trabajo de forma ordenada y separada, debido a que sigue el principio de “divide y vencerás”.
Cada capa está dividida según su funcionalidad cuando se quiere modificar el sistema basta con cambiar un objeto o conjunto de objetos de una capa. Esto se llama modularidad.
Desventajas
Cuando se implementa un modelo de programación en capas, se debe llegar a un balance entre el número de capas y subcapas que componen el programa. Este debe ser el necesario y suficiente para realizar un trabajo específico con eficiencia y ser lo más modular posible.

De lo contrario se tiene una serie de desventajas como: pérdida de eficiencia, realización de trabajo innecesario o redundante entre capas, gasto de espacio de la aplicación debido a la expansión de las capas, o bien una alta dependencia entre los objetos y capas que contradice el objetivo principal del modelo.

SCRUM

Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80.
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
 Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto_ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.
Definición de proyecto
Según la definición que nos proporciona PMI en su guía PMBOOK, un proyecto se podría definir como “un servicio temporal que se lleva a cabo para crear un producto, servicio o resultado único”.
Se puede decir entonces que un proyecto tiene un inicio y un fin, este fin se tiene que alcanzar dentro de un tiempo fijado.
En un proyecto la consecución de los objetivos al final del mismo es la máxima deseada, pero la mayor parte de las veces, bien por una mala planificación, o bien por una mala gestión de los recursos, es importante finalizar el proyecto con éxito.
Teoría de Scrum
Scrum se fundamenta en la teoría empírica de control de procesos, o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea una aproximación iterativa e incremental para optimizar la predictibilidad y controlar el riesgo.
Tres pilares soportan toda implementación del control empírico de procesos: transparencia, inspección y adaptación.
Transparencia
Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. La transparencia requiere que dichos aspectos sean definidos por un estándar común, de modo que los observadores compartan un entendimiento común de lo que se está viendo.
Inspección
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones no deseables. Su inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las inspecciones son más beneficiosas cuando son realizadas de forma diligente por inspectores expertos, en el mismo lugar de trabajo.
Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe ser realizado cuanto antes para minimizar desviaciones mayores.

Las reuniones
·         Planificación de sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el trabajo y los objetivos que se deben cumplir en esa iteración.
·         Reunión diaria: Breve revisión del equipo del trabajo realizado hasta la fecha y la previsión para el día siguiente.
·         Revisión de sprint: Análisis y revisión del incremento generado.
Los elementos
·         Pila del producto: lista de requisitos de usuario que se origina con la visión inicial del producto y va creciendo y evolucionando durante el desarrollo.
·         Pila del sprint: Lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto.
·         Incremento: Resultado de cada sprint
Los roles
·         El Dueño de Producto (Product Owner)
El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo. El cómo se lleva esto a cabo puede variar ampliamente entre distintas organizaciones, Equipos Scrum, e individuos.
El Dueño de Producto es la única persona responsable de gestionar la Pila de Producto (Product Backlog). La gestión de la Pila de Producto incluye:
Ø  Expresar claramente los elementos de la Pila de Producto;
Ø  Ordenar los elementos en la Pila de Producto para alcanzar los objetivos y misiones de la mejor manera posible;
Ø  Asegurar el valor del trabajo desempeñado por el Equipo de Desarrollo;
Ø  Asegurar que la Pila de Producto es visible, transparente y clara para todos, y que muestra aquello en lo que el equipo trabajará a continuación; y,
Ø  Asegurar que el Equipo de Desarrollo entiende los elementos de la Pila de Producto al nivel necesario.
El Dueño de Producto puede hacer el trabajo anterior, o delegarlo en el Equipo de Desarrollo. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo.
·         El Equipo de Desarrollo (Development Team)
El Equipo de Desarrollo consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de producto “Hecho”, potencialmente utilizable, al final de cada Sprint. Sólo los miembros del Equipo de Desarrollo participan en la creación del Incremento.
Los Equipos de Desarrollo se estructuran y reciben poderes por parte de la organización para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad general del Equipo de Desarrollo. Los Equipos de Desarrollo tienen las siguientes características:
Ø  Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos de la Pila de Producto en Incrementos de funcionalidad potencialmente entregables;
Ø  Los Equipos de Desarrollo son multifuncionales, contando como equipo con todas las habilidades necesarias para crear un Incremento de producto;
Ø  Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores. Independientemente del trabajo que realice cada persona, no hay excepciones a esta regla;
Ø  Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas o áreas en las que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo; y,
Ø  Los Equipos de Desarrollo no contienen sub-equipos dedicados a dominios concretos como pruebas o análisis de negocio.
·         El Scrum Master
El Scrum Master es el responsable de asegurar que Scrum es entendido y llevado a cabo. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder servil, al servicio del Equipo Scrum.
El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones, para maximizar el valor creado por el Equipo Scrum.
El Servicio del Scrum Master al Dueño de Producto
El Scrum Master da servicio al Dueño de Producto de varias formas, incluyendo:
Ø  Encontrar técnicas para gestionar la Pila de Producto de manera efectiva;
Ø  Comunicar claramente la visión, los objetivos y los elementos de la Pila de Producto al Equipo de Desarrollo;
Ø  Enseñar al Equipo Scrum a crear elementos de la Pila de Producto claros y concisos;
Ø  Entender la planificación a largo plazo del producto en un entorno empírico;
Ø  Entender y practicar la agilidad; y,
Ø  Facilitar los eventos de Scrum según se requiera o necesite.
El Servicio del Scrum Master al Equipo de Desarrollo
El Scrum Master da servicio al Equipo de Desarrollo de varias formas, incluyendo:
Ø  Entrenar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
Ø  Formar y liderar al Equipo de Desarrollo en la creación de productos de alto valor;
Ø  Eliminar impedimentos al progreso del Equipo de Desarrollo;
Ø  Facilitar los eventos de Scrum según se requiera o necesite; y,
Ø  Entrenar al Equipo de Desarrollo en el entorno de organizaciones en las que Scrum aún no ha sido adoptado y entendido por completo.
El Servicio del Scrum Master a la Organización
El Scrum Master da servicio a la organización de varias formas, incluyendo:
Ø  Liderar y entrenar a la organización en su adopción de Scrum;
Ø  Planificar implementaciones de Scrum en la organización;
Ø  Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto;
Ø  Causar cambios que incrementen la productividad del Equipo Scrum; y,
Ø  Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.



miércoles, 11 de junio de 2014

Ingeniería de Requerimientos


La Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema.

El análisis de requerimientos establece el proceso de definición de requerimientos como una serie de tareas o actividades mediante las cuales se busca ganar conocimientos relevantes del problema, que se utilizarán para producir una especificación formal del software necesario para resolverlo. En este proceso se deben conciliar diferentes puntos de vista y utilizar una combinación de métodos, personas y herramientas. El resultado final constituye la documentación de los requerimientos. Éstos deben expresarse de forma clara y estructurada de manera que puedan ser entendidos tanto por expertos como por el usuario, quien deberá participar en la validación.

El proceso del establecimiento de requerimientos de un sistema de software es el primer paso esencial en entregar lo que el cliente desea. Entre los métodos conocidos se puede citar a los siguientes:
1.       Reconocimiento del problema: Se deben de estudiar inicialmente las especificaciones del sistema y el plan del proyecto del software. Realmente se necesita llegar a comprender el software dentro del contexto del sistema. El analista debe establecer un canal adecuado de comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la función primordial del analista en todo momento es reconocer los elementos del problema tal y como los percibe el usuario.
2.       Evaluación y síntesis: En esta etapa el analista debe centrarse en el flujo y estructura de la información, definir las funciones del software, determinar los factores que afectan el desarrollo de nuestro sistema, establecer las características de la interfaz del sistema y descubrir las restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la determinación del problema de forma sintetizada.
3.       Modelización: Durante la evaluación y síntesis de la solución, se crean modelos del sistema que servirán al analista para comprender mejor el proceso funcional, operativo y de contenido de la información. El modelo servirá de pilar para el diseño del software y como base para la creación de una especificación del software.
4.       Especificación: Las tareas asociadas con la especificación intentan proporcionar una representación del software. Esto más adelante permitirá llegar a determinar si se ha llegado a comprender el software, en los casos que se lleguen a modelar se pueden dejar plasmados manuales.
5.       Revisión: Una vez que se han descrito la información básica, se especifican los criterios de validación que han de servir para demostrar que se ha llegado a un buen entendimiento de la forma de implementar con éxito el software. La documentación del análisis de requerimientos y manuales, permitirán una revisión por parte del cliente, la cual posiblemente traerá consigo modificaciones en las funciones del sistema por lo que deberán revisare el plan de desarrollo y las estimaciones previstas inicialmente.
5.
Técnicas
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio
·         Entrevistas: Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.
·         Talleres: Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Existen dos técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La diferencia que existe entre ambas técnicas es que durante la tormenta de ideas se tiene como objetivo generar una gran cantidad de ideas, es desestructurada y la información que se obtiene puede ser visual, textual o coloquial; mientras que en el JAD el taller es ordenado, la información que se obtiene es visual y su objetivo es generar requisitos y la interfaz del sistema.

Durante una sesión de Lluvia de ideas, todos los participantes pueden aportar distintas ideas en un ambiente libre de prejuicios. Ningún participante debe juzgar negativamente la propuesta de otros, sino que se anotan todas las ideas en una pizarra y serán evaluadas al final de la sesión. El principio básico es no descartar de manera apresurada ningún planteo, de modo que existe la posibilidad de que surjan otras ideas derivadas de la idea original y se generan varios puntos de vista del problema.
En el Joint application development se trabaja directamente sobre los documentos a generar, las temáticas que se tratan durante las reuniones siguen un esquema y se busca que la misma sea ordenada y racional. Se define una agenda con los puntos principales a tratar durante la jornada. Este tipo de taller tiene el inconveniente de que es muy difícil poder reunir a todos los participantes, es costoso y generalmente es necesaria más de una reunión para establecer los requisitos del sistema.
·         Forma de contrato: En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Objetivos medibles Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.
·         Prototipos u casos de uso: Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.
Ø  A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
Ø  Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
Ø  Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
Ø  Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

Actividades de la Ingeniería de requerimientos para diferentes modelos de ingeniería de software
Modelo
Oliver and Steiner 1996
EIA / IS-632
IEEE estándar 1220- 1994
CMM nivel Repetitivo
RUP
Actividades
Evaluar la información disponible
Análisis de requerimientos
Análisis de Requerimientos
Identificación de requerimientos
Análisis del Problema
Definir métricas efectivas
Análisis funcional
Estudio de los requerimientos
Identificación de restricciones del sistema a desarrollar
Comprender las necesidades de los involucrados
Crear un modelo del comportamiento del sistema
Síntesis
Validación de requerimientos
Análisis de los requerimientos
Definir el sistema
Crear un modelo de los objetos
Análisis funcional
Representación de los requerimientos
Analizar el alcance del proyecto
Ejecutar el análisis
Evaluación y estudio de funciones
Comunicación de los requerimientos
Modificar la definición del sistema
Verificación de funciones
Validación de requerimientos
Administrar los cambios de requerimientos
Síntesis
Verificación física
Control