Introduccion
Benchmarking.- Un proceso sistemático y continuo para evaluar los productos, servicios y procesos de trabajo de las organizaciones que son reconocidas como representantes de las mejores prácticas, con el propósito de realizar mejoras organizacionales.
Michael J. Spendolini
- Benchmarking no es un mecanismo para determinar reducciones de recursos. Los recursos de resignarán a la forma más efectiva de apoyar las necesidades de los clientes y obtener la satisfacción de los mismos.
- Benchmarking no es una panacea o un programa. Tiene que ser un proceso continuo de la administración que requiere una actualización constante - la recopilación y selección constante de las mejores prácticas y desempeño externos para incorporarlos a la toma de decisiones y las funciones de comunicaciones en todos los niveles del negocio. Tiene que tener una metodología estructurada para la obtención de información, sin embargo debe ser flexible para incorporar formas nuevas e innovadoras.
- Benchmarking no es un proceso de recetas de libros de cocina que sólo requieran buscar los ingredientes y utilizarlos para tener éxito.
- Benchmarking es un proceso de descubrimiento y una experiencia de aprendizaje.
- Benchmarking no sólo es una moda pasajera, sino que es una estrategia de negocios
- Benchmarking es una nueva forma de hacer negocios. Obliga a utilizar un punto de vista externo que asegure la corrección de la fijación de objetivos.
- Es un nuevo enfoque administrativo. Obliga a la prueba constante de las acciones internas contra estándares externos de las prácticas de la industria.
- Es una estrategia que fomenta el trabajo de equipo al enfocar la atención sobre las prácticas de negocios para permanecer competitivos más bien que en el interés personal, individual. Elimina la subjetividad de la toma de decisiones.
LAS CINCO ETAPAS PARA UN BENCHMARKING DE ÉXITO PROPUESTAS POR SPENDOLINI.
- Definir quienes son los clientes para la información del benchmarking.
- Determinar las necesidades de información de benchmarking de los clientes.
- Identificación de factores críticos de éxito.
- Diagnóstico del proceso de benchmarking.
- Consideración de benchmarking como actividad de equipo.
- Tipos de equipos de benchmarking.
- Grupos funcionales de trabajo.
- Equipos interfuncionales, interdepartamentales y equipos interorganizacionales.
- Equipos ad hoc.
- Quienes son los involucrados en el proceso de benchmarking.
- Especialistas internos.
- Especialistas externos.
- Empleados.
- Definir funciones y responsabilidades del equipo de benchmarking.
- Definición de habilidades y atributos de un practicante eficiente de benchmarking.
- Capacitación.
- Calendarización.
- Establecimiento de red de información propia.
- Identificar recursos de información.
- Buscar las mejores prácticas.
- Redes de Benchmarking.
- Otras fuentes de información.
- Conocerse.
- Recopilar la información.
- Organizar información.
- Análisis de la información.
- Producir un informe de benchmarking.
- Presentación de resultados a los clientes de benchmarking.
- Identificar posibles mejoras de productos y procesos.
- Visión del proyecto en su totalidad.
Diagramas de Componentes
domingo, 23 de agosto de 20091.- Componentes
Un componente de software es una parte física de un sistema, como puede ser un módulo, una base de datos, un programa ejecutable, una biblioteca de programas, etc. Puede considerarse que un componente es la materialización de una o más clases. En efecto, las clases son conceptos –constituyen una abstracción de un conjunto de atributos y operaciones- que se implementan o materializan en los componentes.
Existen tres grandes grupos o tipos de componentes:
a.- Componentes de distribución
Son los componentes que conforman un sistema, como los programas ejecutables, los DLL, controles ActiveX, Java Beans, etc.
b.- Componentes de trabajo
Son los componentes con los que se crean los componentes de distribución, como los programas fuente, las bases de datos, etc.
c.- Componentes de ejecución
Son los componentes que, en el transcurso de la ejecución de un sistema, se crean en forma dinámica, como los índices que crean los motores de búsqueda, como resultado de alguna consulta.
En un diagrama de componentes, un componente se representa con un rectángulo en el que se inscribe su nombre y en el que se muestran dos pequeños rectángulos en su lado izquierdo. También pueden utilizarse los símbolos que se muestran en la figura.
Las clases que implementa un componente pueden indicarse inscribiendo sus nombres en el rectángulo que representa al componente o mostrando las relaciones de dependencia con dichas clases.
En el capítulo IX, en el que revisamos los diagramas de clase, se introdujo el concepto de interfaz, señalando que es “una clase que sólo contiene operaciones”, en la que se incluyen operaciones que son comunes a varias clases.
En el caso de los componentes, el concepto es similar, añadiendo que la ejecución de un componente sólo puede ser hecha a través de su interfaz. Esto es, un componente presenta su interfaz para que otros componentes puedan utilizar sus operaciones y, sólo a través de su interfaz, podrá hacerse uso de sus operaciones.
Para un componente dado, existen dos tipos de interfaces: los interfaces provistos o requeridos y los interfaces utilizados.
Con el fin de tener una comprensión más clara de lo que es una interfaz, consideremos un ejemplo muy sencillo. Supongamos que hemos abierto la aplicación excel en nuestro microcomputador; en nuestra pantalla aparece el formato de filas y columnas que utiliza excel. Sabemos que “detrás de la pantalla”, en la memoria de nuestro microcomputador está alojado un componente que hace los cálculos –llamémoslo excel/programa-, de acuerdo a los datos y comandos que recibe del formato que aparece en pantalla –llamémoslo excel/ pantalla -. Este último componente sólo realizará sus operaciones si se le indican los datos y las funciones establecidas por su sintaxis a través de excel/pantalla.
El concepto de interfaz es una de las bases fundamentales para la reutilización de objetos, pues un objeto puede ser reemplazado por otro si ambos tienen la misma interfaz.
Expresando lo anterior en palabras mucho más simples, a Cantidad-de-días-hábiles le da lo mismo trabajar para Vacación que para Interés-Devengado, siempre y cuando se dirijan a ella con las mismas “palabras”. Es decir, la operación de Cantidad-de-días-hábiles puede ser reutilizada por cualquier sistema, siempre y cuando se invoque en la misma forma.
Así pues, podemos entender que, dado que cada componente tiene una interfaz, que constituye su “puerta de entrada” frente al mundo de los componentes, cualquier sistema puede utilizar un componente determinado, accediendo a él a través de su interfaz. Dicho en los términos de la OMG, “un componente es una unidad sustituible que puede ser reemplazado en tiempo de diseño o en tiempo de ejecución por un componente que ofrezca una funcionalidad equivalente, basada en la compatibilidad de sus interfaces”.
Las interfaces pueden representarse de varias formas, como vemos en la gráfica
Los diagramas de componentes pueden ser utilizados para modelar sistemas de software de cualquier tamaño y complejidad. La herramienta nos permite especificar un componente como unidad modular con interfaces bien definidos, reemplazable dentro de su ambiente.
El concepto de componente encaja dentro de las ideas de desarrollo basado en componentes y estructuración de sistemas basada en componentes, en las cuales un componente se va modelando a través de todo el ciclo de desarrollo y sucesivamente se va refinando hasta llegar a su implantación y creación de su “run time” –módulo ejecutable-. Un componente puede ser considerado como una unidad autónoma, dentro de un sistema o subsistema, tiene uno o más interfaces -proporcionados o requeridos- y sus “interioridades” permanecen ocultas e inaccesibles, con excepción de la forma que está prevista en sus interfaces.
Diagramas de UML