lunes, 13 de abril de 2009

Diagrama de procesos (Ejemplo 2)

Diagrama de procesos (Ejemplo 1)

Diagrama de flujo de datos (Ejemplo 2)

Diagrama de flujo de datos (Ejemplo 1)

BPM "Business Process Management"

Como ejemplo muy claro de los procesos y de sus diagramas podemos nombrar una herramienta nueva y muy ágil llamada BPM “Business Process Management”, quien trabaja eficientemente mediante la efectividad de los procesos. A continuación explicaremos lo que significa implementar el BPM en la gestión de negocios y sus ventajas, desventajas y diagramación basada en los procesos.
BPM (Business Process Management): es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar representar, analizar y controlar procesos de negocios operacionales. BPM es un enfoque centrado en los procesos para mejorar el rendimiento que combinan las tecnologías de la información con metodologías de proceso y gobierno. BPM es una colaboración entre personas de negocios y tecnólogos para fomentar procesos de negocio efectivos, ágiles y trasparentes.
Mucha gente puede preguntarse ¿qué son “procesos de negocios operacionales”? o ¿qué es un enfoque “centrado en los procesos”? ¿Y desde cuando “colaboran” las personas de negocios con la de tecnología?, daremos respuesta a esto.
BPM combina métodos ya probados y establecidos de gestión de procesos con una nueva clase de herramientas de software empresarial. Ha Posibilitado adelantos muy importantes en cuanto a la velocidad y agilidad con que las organizaciones mejoran el rendimiento de los negocios. Con BPM:
-. Los directores de negocios pueden, de forma más directa, medir, controlar y responder a todos los aspectos y elementos de sus procesos operacionales.
-. Los directores de tecnologías de la información pueden aplicar sus habilidades y recursos de forma más directa en las operaciones de negocios.
-. La dirección y los empleados de la organización pueden alinear mejor sus esfuerzos y mejorar la productividad y rendimiento personal.
-. La empresa, como un todo, puede responder deforma más rápida a cambios y desafíos a la hora de cumplir sus fines y objetivos.
Las tres dimensiones de BPM:
1-. El negocio: la dimensión de valor.
La dimensión de negocio es la dimensión de valor y de la creación de valor tanto para los clientes como para los “stakeholders” (personas interesadas en la buena marcha de la empresa como empleados, accionistas, proveedores, etc.)
BPM facilita directamente los fines y objetivos de negocio de la compañía: crecimiento sostenido de los ingresos brutos y mejora del rendimiento mínimo; aumento de la innovación; mejora d la productividad; incremento de la fidelidad y satisfacción del cliente y niveles elevados de eficiencia del personal.
2-. El Proceso: la dimensión de transformación
La dimensión de procesos crea valor a través de actividades estructuradas llamadas procesos. Los procesos operacionales transforman los recursos y materiales en productos o servicios para clientes y consumidores finales. Esta transformación, es el modo en que funciona un negocio; el elixir mágico de la empresa.
La ciencia aplicada de procesos y trasformación abarca la historia de la gestión industrial moderna.
Mediante BPM, los procesos de negocios son más efectivos, más trasparentes y más agiles. Los procesos producen menos errores y estos se detectan más rápidos y se resuelven antes.
Efectividad de los procesos.
Los procesos efectivos son más coherentes, generan menos pérdidas y crean un valor neto mayor para clientes y “Stakeholders”. BPM fomenta de forma directa un aumento en la efectividad de los procesos mediante la automatización adaptativa y la coordinación de persona, información, y sistemas.
Un proceso de negocio es el conjunto de todas las tareas y actividades coordinadas formalmente, dirigidas tanto como por personas como por equipos, que lleva a conseguir un objetivo organizativo específico. Un ejemplo, es cumplimentar un pedido. El acto del cliente solicitando un producto inicia un proceso para registrar el pedido, aprobar su crédito y desencadenar la producción y entrega. BPM se esfuerza en maximizar la efectividad de los procesos de negocios de las siguientes maneras:
-. Determina el proceso óptimo para las condiciones actuales.
-. Hace funcionar el proceso tan efectivamente como sea posible.
-. Posibilita decisiones y controles en busca de la eficiencia continua.
Transparencia de los procesos
La transparencia es la propiedad de apertura y visualización, y es crítica para la efectividad de las operaciones. Con BPM, puede visualizar de forma directa todos los elementos del diseño de los procesos como el modelo, flujo de trabajo, reglas, sistema y participantes, así como su rendimiento en tiempo real.
Agilidad en los procesos
De todas las demandas de las operaciones empresariales, quizás la más acuciante sea la necesidad de cambio, es decir, la capacidad de adaptación a eventos y circunstancias cambiantes manteniendo al mismo tiempo la productividad y rendimiento globales. BPM permite a las personas de negocios definir procesos de forma rápida y precisa a través de los modelos de procesos. Directamente convierte diseños de procesos en ejecución, integrando sistemas y construyendo aplicaciones sin necesidad de códigos y sin fisuras ya que cada plataforma BPM viene equipada con componentes tecnológicos.
3-. La gestión: la dimensión de capacitación
La gestión es la dimensión de capacitación. La gestión pone a las personas y a los sistemas en movimiento y empuja a los procesos a la acción en pos de los fines y objetivos del negocio. Con BPM, puede aunar todos los sistemas, métodos, herramientas y técnicas de desarrollo de procesos y la gestión de procesos en un sistema estructurado, completo, con la visibilidad y los controles necesarios para dirigirlos y afinarlos.

BPMS. La “S” de BPMS significa “suite”.
BPMS es la suite de tecnologías BPM, lo que incluye todos los módulos funcionales, las capacidades técnicas y la infraestructura de apoyo, integradas en un único entorno que realiza todas las funciones de la tecnología BPM de manera perfecta, sin fisuras. BPMS es el paquete completo.
Arquitectura de Negocios de BPM
Organizaciones centradas en los procesos
Redefinición de roles
Modificar alineaciones y estructuras funcionales no es fácil, pero BPM le demanda la creación de nuevos roles que van más allá de los conductos funcionales para respaldar los negocios centrados en procesos. Estos son:
- Director de procesos: El ejecutivo responsable de definir y habilitar la arquitectura de procesos empresariales, que fomenta la cultura empresarial basada en procesos.
- Arquitecto de procesos: El individuo que diseña y construye modelos y entornos para los procesos de negocios claves, como los flujos de trabajo, indicadores claves de desempeño y planes de control.
- Propietarios de procesos de negocios: Individuos responsables del rendimiento integral de los procesos.
- Ingenieros de procesos: Individuos que construyen procesos de negocios ejecutables, incluyendo la creación de servicios a partir de la orquestación de otras y la creación de aplicaciones compuestas y de sistemas de medidas, notificación y control.
- Analista de procesos: El experto que define qué eventos se deben supervisar, diagnóstica problemas de los procesos y prescribe soluciones del rendimiento.
- Actor del proceso: Alguien que no solo trabaja dentro de un proceso, sino que comprende cómo encaja dentro de un flujo de valor extendido.

Workflow. “Flujo de Trabajo”
Gestión electrónica de procesos de negocios. Busca capturar una definición clara de un proceso de negocio. Gestión modelada de las tareas a ejecutar y de los responsables de su ejecución. Representan interacciones entre los protagonistas intercambiando información
BPMN “Business process modeling notation”
Objetivo:
- Proveer una notación entendible para cualquiera desde el analista de negocio, el desarrollador técnico hasta la gente propia del negocio.
Actividades:
- Trabajo ejecutado dentro de un proceso de negocio.
- Hay tres tipos: proceso, subproceso y tareas.
- Su representación gráfica es un rectángulo con los bordes redondeados.


Proceso: Actividad ejecutada dentro de una compañía.
Cada proceso puede tener sus propios subprocesos.
Subprocesos: Actividad compuesta, contiene en detalle un flujo de otras actividades.
Tareas: Actividad atómica incluida en un proceso.

Eventos
Es algo que pasa durante el curso de un proceso de negocio. Afectan el flujo del proceso y usualmente tienen una causa y un impacto. Hay tres tipos: comienzo, intermedio, final. Su representación gráfica es un círculo.

Comienzo: Indica donde un proceso comienza. No tiene flujo de secuencia entrantes. Si hay un evento de FIN debe haber uno de INICIO.

Intermedios: Ocurren entre los eventos de inicio y fin. Son usados para graficar donde se mostraran mensajes y retardos dentro del proceso. Interrumpir el flujo normal a través del manejo de excepciones. Su representación gráfica es un círculo dentro de otro círculo.

Fin: Indica el fin de un proceso. No tiene flujo de secuencia de salida. Puede haber muchos eventos de fin dentro de un mismo proceso. Su representación es igual que la anterior pero con el borde relleno de color negro del círculo.

Gateways:
Son elementos de modelado que sirven para controlar como interactúa el flujo de secuencia mientras converge y diverge dentro de un proceso. Consiste de una colección de puertas que controlan la salida y el Gateway determina como estarán dispuestas las mismas.
Hay tres tipos:
- Decisión exclusiva (XOR): Lugares dentro de un proceso de negocio donde el flujo de secuencia puede tomar dos o más alternativas. Hay dos tipos, basados en datos (condiciones booleanas), o basado en eventos (manejo de sistemas distribuidos, alternativas basadas en eventos que ocurren), usualmente el evento es la recepción de un mensaje.
- Decisión inclusiva (OR)
- Decisiones paralelas
- Decisiones complejas
- Su representación gráfica es un rombo.

Objetos conectores
Definen los objetos gráficos usados para conectar dos objetos juntos y como progresa el flujo dentro de un proceso.

Flujo de secuencia: Se usa para mostrar el orden en que las actividades se ejecutan. Tiene una sola fuente y un solo destino. Su representación gráfica es una flecha.

Flujo del mensaje: Se usa para mostrar el flujo de mensajes entre dos entidades que están preparadas para mandarlos/recibirlos. Su representación es igual que la anterior pero con la línea segmentada.

Flujo de asociación: Usada para asociar información y artefactos con objetos de flujo. Su representación gráfica es una línea segmentada.
-----------------------

Diagrama de Flujo de Datos y de Procesos

Diagramas de flujo de datos

DFD’s
• Muestran en forma visual sólo el flujo de datos entre los distintos procesos, entidades externas y almacenes que conforman un sistema.
• Cuando los analistas de sistemas indagan sobre los requerimientos de información de los usuarios, deben ser capaces de concebir la manera en que los datos fluyen a través del sistema u organización, los procesos que sufren estos datos y sus tipos de salidas.
Elementos de un Diagrama de Flujo Datos (DFD)
- Entidad Externa
- Flujo Datos
- Proceso

Almacén Datos
Persona, grupo de personas o unidad de negocio que entrega y/o recibe información.
Conjunto de actividades de negocio que explican que se hace y como se llevan a cabo.
Señala el flujo de datos de una entidad externa a un proceso y viceversa, de un proceso a otro, y de un proceso a un almacén de datos y viceversa.
Lugar físico donde se almacenan los datos procesados o desde donde se recuperan para apoyar un proceso.

Análisis y Diseño Sistemas
Entidad Externa
• Representa personas, organizaciones, o sistemas que no pertenecen al sistema.
• En el caso de que las entidades externas se comunicasen entre sí, esto no se contemplaría en el diagrama, por estar fuera del ámbito de nuestro sistema
• Puede aparecer en los distintos niveles de DFD para mejorar su comprensión, aunque normalmente sólo aparecerá en el diagrama de contexto.
• Pueden aparecer varias veces en un mismo diagrama, para evitar entrecruzamientos de líneas.
• Suministra información acerca de la conexión del sistema con el mundo exterior.

Procesos
• Cuando un flujo de datos entra en un proceso sufre una transformación. Un proceso no es origen ni final de los datos, sólo lugar de transformación de ellos.
• Un proceso puede trasformar un dato en varios.
• Es necesario un proceso entre una Entidad Externa y un Almacén de datos.
• Un proceso puede representarse señalando una localización. La localización expresa la unidad o área dentro de la organización donde se realiza el proceso.

Almacén de Datos
• Representa la información en reposo
• No puede crear, destruir ni transformar datos
• No puede estar comunicado directamente con otro almacén o Entidad externa
• El flujo de datos (Entrada y Salida) no lleva nombre cuando incide sobre su contenido completo.
• No debe estar referido al entorno físico, y por tanto, no se diferencian los ficheros convencionales de las bases de datos
• No se representa la clave de acceso a este almacén sino sólo la operación que se realiza (lectura, escritura, actualización)

Flujo de Datos
• El concepto de flujo de datos es similar al concepto de tubería a través del cual fluye información de estructura conocida.
• Los datos no pueden ser creados ni destruidos por un flujo de datos.
• Sirve para conectar el resto de los componentes de un DFD.
• No es un activador de procesos.
• Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la dirección del almacén de datos y a la inversa si es el proceso el que lee datos en el almacén.

DFD: Descomposición por Niveles
• El sistema deberá contener:
- Un Diagrama de contexto (primer nivel)
- Varios DFD en niveles intermedios
- Varios DFD en el último nivel de detalle
• En cualquier momento nos puede aparecer un proceso que no necesite descomposición y es lo que denominaremos Proceso Primitivo (PP). En ellos, se detallará la entrada y salida que tenga, además de la descripción asociada que explique lo que realiza.

DFD: Construcción
• Representar el diagrama de contexto.
• Representar el DFD de primer nivel, indicando los distintos subsistemas funcionales en que se descompone nuestro sistema.
• Descomponer cada uno de los procesos que aparecen en el DFD de primer nivel, hasta llegar a un nivel suficiente de detalle.
• Se recomienda el utilizar cuatro niveles de descomposición de diagramas.
Nivel 0: Diagrama de contexto
Nivel 1: Subsistemas
Nivel 2: Funciones de cada subsistema
Nivel 3: Subfunciones asociadas
Nivel 4: Procesos necesarios para el tratamiento de cada subfunción

Diccionario de Datos (DD)
• Notación para representar la estructura de ítems de datos, necesaria para expresar:
– Composición– cómo un ítem está compuesto de unidades planas (sus atributos).
– Repetición – ítems que son repetidos en (e.g.) listas, arreglos (arrays), etc.
– Selección – valores para ítems a seleccionar desde alternativas.
– Opcionalidad - ítems que no siempre están presentes.

Símbolos usados en la notación del DD
Asigne un nombre significativo a cada ítem de datos básico o compuesto.
= significa ‘es definido como', o ‘esta hecho de'
+ significa ‘ y '
{ } Significa cero o mas de cualquier cosa que este dentro de las llaves, i.e. repetición
n{ }m significa entre n y m (inclusive)
[ ] Significa que uno de los atributos entre las barras está presente.
( ) Significa que el ítem entre paréntesis es opcional
" " incluye literales (valor a utilizar)
* * Incluye comentarios – define el significado de datos, informalmente.

Ejemplo: Lista Seminarios
• ListaSeminarios = Titulo + NumeroVersion
+ Fecha + {DetalleSeminario}
• DetalleSeminario = DiaSemana + Horario + Aula
+ {ListaEstudiantes}
• ListaEstudiantes = {Nombre + Apellido Paterno}
• o…..
• ListaSeminarios = Titulo + NumeroVersion + Fecha
+ { DiaSemana + Horario + Aula
+ {Nombre + ApellidoPaterno} }
• NumeroVersion = Digito + "." + Digito
Digito = ["1" "2" "3" "4" …..]
Horario = HoraInicio + "-" + HoraTermino
HoraInicio = ["9" "10" "11" "12"…..]


Diagramas de flujo de procesos

Definición
Es una representación gráfica de la secuencia de todas las operaciones, los transportes, las inspecciones, las esperas y los almacenamientos que ocurren durante un proceso. Incluye, además, la información que se considera deseable para el análisis, por ejemplo el tiempo necesario y la distancia recorrida. Sirve para las secuencias de un producto, un operario, una pieza, etcétera.
Objetivos
Proporcionar una imagen clara de toda secuencia de acontecimientos del proceso. Mejorar la distribución de los locales y el manejo de los materiales. También sirve para disminuir las esperas, estudiar las operaciones y otras actividades en su relación recíproca. Igualmente para comparar métodos, eliminar el tiempo improductivo y escoger operaciones para su estudio detallado.
Recomendaciones previas a la construcción del diagrama de flujo
Obténgase un plano del lugar en donde se efectúe el proceso seleccionado. En el plano deben estar representados todos los objetos permanentes como muros, columnas, escaleras, etc., y también los semipermanentes como hacinamientos de material, bancos de servicio, etc. En el mismo plano debe estar localizado, de acuerdo con su posición actual, todo el equipo de manufactura, así como lugares de almacén, bancos de inspección y, si se requiere, las instalaciones de energía. Igualmente, debe decidirse a quién se va a seguir: al hombre o al material, pero sólo a uno, éste debe ser el mismo que se haya seguido en el diagrama del proceso.

Este diagrama contiene, en general, muchos más detalles que el de operaciones. Por lo tanto, no se adapta al caso de considerar en conjunto ensambles complicados. Se aplica sobre todo a un componente de un ensamble o sistema para lograr la mayor economía en la fabricación, o en los procedimientos aplicables a un componente o una sucesión de trabajos en particular. Este diagrama de flujo es especialmente útil para poner de manifiesto costos ocultos como distancias recorridas, retrasos y almacenamientos temporales. Una vez expuestos estos periodos no productivos, el analista puede proceder a su mejoramiento.
Además de registrar las operaciones y las inspecciones, el diagrama de flujo de proceso muestra todos los traslados y retrasos de almacenamiento con los que tropieza un artículo en su recorrido por la planta. En él se utilizan otros símbolos además de los de operación e inspección empleados en el diagrama de operaciones. Una pequeña flecha indica transporte, que se define como el movimiento de un lugar a otro, o traslado, de un objeto, cuando no forma parte del curso normal de una operación o una inspección. Un símbolo como la letra D mayúscula indica demora o retraso, el cual ocurre cuando no se permite a una pieza ser procesada inmediatamente en la siguiente estación de trabajo. Un triángulo equilátero puesto sobre su vértice indica almacenamiento, o sea, cuando una pieza se retira y protege contra un traslado no autorizado. Cuando es necesario mostrar una actividad combinada, por ejemplo, cuando un operario efectúa una operación y una inspección en una estación de trabajo, se utiliza como símbolo un cuadro de 10 mm (o 3/8 plg) por lado con un círculo inscrito de este diámetro.
Generalmente se usan dos tipos de diagrama de flujo: de producto y operativo. Mientras el diagrama de producto muestra todos los detalles de los hechos que tienen lugar para un producto o a un material, el diagrama de flujo operativo muestra los detalles de cómo una persona ejecuta una secuencia de operaciones.
También puede suceder que al mismo tiempo que ocurre una operación se ejecute una inspección, en cuyo caso se usan los dos símbolos combinados. Por ejemplo, retirar la pieza de una máquina e inspeccionarla al mismo tiempo o al producir una pieza, verificar simultáneamente algunas de sus características.
Cómo construir el diagrama de flujo
Como el diagrama de operaciones, el de flujo de un proceso debe ser identificado correctamente con un título. Es usual encabezar la información identificadora con el de "Diagrama de curso de proceso". La información mencionada comprende, por lo general, número de la pieza, número del plano, descripción del proceso, método actual o propuesto, fecha y nombre de la persona que elabora el diagrama.
Algunas veces hacen falta datos adicionales para identificar por completo el trabajo que se diagrama. Estos pueden ser los nombres de la planta, edificio o departamento, número de diagrama, cantidad de producción e información sobre costos.
Puesto que el diagrama de flujo de proceso corresponde sólo a una pieza o artículo y no a un ensamble o conjunto, puede elaborarse un diagrama más nítidamente empezando en el centro de la parte superior del papel. Primero se traza una línea horizontal de material, sobre la cual se escribe el número de la pieza y su descripción, así como el material con el que se procesa. Se traza luego una corta línea vertical de flujo, de unos 5 mm (o ¼ plg) de longitud al primer símbolo de evento, el cual puede ser una flecha que indica un transporte desde la bodega o almacén. Inmediatamente a la derecha del símbolo de transporte se anota una breve descripción del movimiento, tal como "llevado a la sierra recortadora por el manipulador del material". Inmediatamente abajo se anota el tipo de equipo para manejo de material empleado, si se utiliza. Por ejemplo: ''carro de mano de dos ruedas" o "carro montacargas con motor de gasolina" identificarán el equipo empleado. A la izquierda del símbolo se indica el tiempo requerido para desarrollar el evento, y a unos 25 mm más a la izquierda, se registra la distancia recorrida (en metros, por ejemplo).
Se continúa este procedimiento de diagramación registrando todas las operaciones, inspecciones, movimientos, demoras, almacenamientos permanentes y almacenamientos temporales que ocurran durante el procesado de la pieza o parte. Se numeran cronológicamente para futuras referencias todos los eventos utilizando una serie particular para cada clase de evento.
El símbolo de transporte se emplea para indicar el sentido de la circulación. Así, cuando hay flujo en línea recta se coloca el símbolo con la flecha apuntando a la derecha del papel. Cuando el proceso se invierte o retrocede, el cambio de sentido o dirección se señala dibujando la flecha de modo que apunte a la izquierda. Si el proceso se efectúa en un edificio de varios pisos, una flecha apuntando hacia arriba indica que el proceso se efectúa siguiendo esa dirección, y una flecha que apunte hacia abajo indicará que el flujo del trabajo es descendente.
No es necesario determinar con exactitud cada movimiento con una regla o cinta de medir para evaluar las distancias recorridas. Por lo general se obtiene un valor bastante correcto contando el número de columnas del edificio por las que ha pasado el material al ser trasladado, y multiplicado este número menos 1, por el claro entre columnas. Los trayectos de 1.50 mt o menos, no se registran comúnmente, aunque podría hacerse esto si el analista cree que influirán considerablemente en el costo total del método que se estudia.
Es importante indicar en el diagrama todas las demoras y tiempos de almacenamiento. No basta con indicar que tiene lugar un retraso o un almacenaje. Cuanto mayor sea el tiempo de almacenamiento o retraso de una pieza, tanto mayor será el incremento en el costo acumulado y, por tanto, es de importancia saber qué tiempo corresponde a la demora o al almacenamiento.
El método más económico para determinar la duración de los retrasos y los almacenamientos consiste en marcar varias piezas o partes indicando la hora exacta en que fueron almacenadas o demoradas. Después hay que inspeccionar periódicamente la sección para ver cuándo regresaron a la producción las partes marcadas. El analista obtendrá valores de tiempo suficientemente exactos, si considera un cierto número de casos, registra el tiempo transcurrido y promedia luego los resultados.
La construcción del diagrama de flujo es sumamente fácil e interesante. Se trata de unir con una línea todos los puntos en donde se efectúa una operación, un almacenaje, una inspección o alguna demora, de acuerdo con el orden natural del proceso.
Esta línea representa la trayectoria usual que siguen los materiales o el operario que los procesa, a través de la planta o taller en donde se lleva a cabo.
Una vez que se ha terminado el diagrama de flujo podemos darnos cuenta del transporte de un objeto, el camino de algún hombre, durante el proceso; este transporte, aún en lugares pequeños, llega a ser algunas veces de muchos kilómetros por día que calculados anualmente representan una pérdida considerable en tiempo, energía y dinero.
Cuando se sospecha que se tiene un número bastante grande de transportes, almacenamientos y demoras en un proceso, es necesario realizar un diagrama de proceso del recorrido con el fin de visualizar y reducir el número de ellos, y con esto disminuir los costos.
Este diagrama se realiza generalmente donde tenemos una parte o componente de ensamble general en fabricación.
Utilización del diagrama de curso de proceso
Este diagrama, como el diagrama de operaciones de proceso, no es un fin en si, sino sólo un medio para lograr una meta. Se utiliza como instrumento de análisis para eliminar los costos ocultos de un componente. Como el reograma muestra claramente todos los transportes, retrasos y almacenamientos, es conveniente para reducir la cantidad y la duración de estos elementos.
Una vez que el analista ha elaborado el diagrama de curso de proceso, debe empezar a formular las preguntas o cuestiones basadas en las consideraciones de mayor importancia para el análisis de operaciones. En el caso de este diagrama se debe dar especial consideración a:
1) Manejo de materiales.
2) Distribución de equipo en la planta.
3) Tiempo de retrasos.
4) Tiempo de almacenamientos.
Es probable que el analista ya haya elaborado y analizado un diagrama de operaciones de proceso del ensamble o conjunto del cual es componente la parte que se estudia en el reograrna. Este dispositivo se elaboró a partir de los componentes del ensamble particular donde se consideró que sería práctico hacer un estudio adicional de los costos ocultos. Al analizar el reograma el analista no deberá perder mucho tiempo volviendo a estudiar las operaciones o inspecciones efectuadas en el componente, cuando éstas ya hayan sido estudiadas. Debe importarle más el estudio de las distancias que las partes que deben recorrer de operación a operación, así como las demoras que ocurrirán. Desde luego que si el diagrama de curso de proceso fue elaborado inicialmente, entonces deberá emplearse todos los enfoques primarios en relación con el análisis de operaciones para estudiar los eventos que aparecen en él. Al analista le interesa principalmente mejorar lo siguiente: primero, el tiempo de cada operación, inspección, movimiento, retraso y almacenamiento; y segundo, la distancia de recorrido cada vez que se transporta el componente.

martes, 7 de abril de 2009

Ingeniería de Software

El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la obtención de un producto de software de calidad" (Jacobson 1998). El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo". Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo" (Jacobson 1998).
El proceso de desarrollo de software requiere por un lado, un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define el alcance del proyecto y desarrolla un caso de negocio. La elaboración define un plan del proyecto, especifica las características y fundamenta la arquitectura. La construcción crea el producto y la transición transfiere el producto a los usuarios.
Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de información. El Object Management Group (OMG)
es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO. El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnología OO. Una de las especificaciones más importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o UML (del inglés Unified Modeling Language) como un estándar, que junto con el Proceso Unificado están consolidando la tecnología OO.
La Ingeniería del Software tratas áreas muy diversas de la informática
y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos o desarrollos en Intranet/Internet, abordando las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de Información y aplicables a una infinidad de áreas tales como: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.
Tomando como base la referencia de estas definiciones seleccionadas, se produce de inmediato la pregunta: ¿Cuales son las Actividades que se encuadran hoy en día en el mundo de la ingeniería del software?
La respuesta a esta pregunta se manifiesta de muy diversas formas pero creo que tal vez las fuentes más objetivas sean las conferencias, congresos, eventos y acontecimientos más relevantes realizados en estos últimos años. Podemos nombrar algunas como lo son:
- Inspección de Software Crítico
- Software de Tecnologías de Procesos de Negocios
- Arquitecturas de Software Distribuido
- UML (Lenguaje Unificado de Modelado de Booch, Rumbaugch y Jacobson)
- Control Técnico de Proyectos de Software
- Marcos de Trabajo (FrameWorks) de empresa orienta a objetos
- CORBA (Estándar para objetos distribuidos)
- Estrategias de Ingeniería Inversa para migración de software
- Ingeniería de Objetos
- Modelado y Análisis de Arquitectura de Software
- Objetos Distribuidos
- Sistemas Cliente Servidor
- Reingeniería
- CASE
- Análisis y Diseño Orientado a Objetos
- Reutilización de Software
- Ingeniería de Bases de Datos
- Datawarehousing
- Datamining
- Ingeniería Web
- Metodología Ágiles
- Entre Otros
La ingeniería de software es la disciplina o área de la informática
que ofrece métodos y técnicas para desarrollar y mantener software de calidad.
Etapas del proceso
La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:
Análisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo. Se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I
(es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para procesos eficaces). Asimismo, se define un diagrama de entidad/relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.
La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de Requisitos
.
La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification).
Especificación
Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las interfaces externas, que deben permanecer estables.
Diseño y arquitectura
Se refiere a determinar como 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.
Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. 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. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas.
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, 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.

Objetivos de la ingeniería de software
En la construcción
y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software.
- Mejorar la calidad de los productos
de software
- Aumentar la productividad
y trabajo de los ingenieros del software.
- Facilitar el control
del proceso de desarrollo de software.
- Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.
- Definir una disciplina
que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.
Objetivos de los proyectos de sistemas
Para que los objetivos se cumplan las empresas
emprenden proyectos por las siguientes razones: "Las cinco C. "
Capacidad
Las actividades de la organización
están influenciadas por la capacidad de ésta para procesar transacciones con rapidez y eficiencia.
Los sistemas de información
mejoran esta capacidad en tres formas.
- Aumentan la velocidad
de procesamiento.
- Aumento en el volumen.

- Recuperación más rápida de la información
.
Costo
- Vigilancia de los costos.
- Reducción de costos.
Control
- Mayor seguridad
de información.
- Menor margen de error: (mejora de la exactitud y la consistencia).
Comunicación
La falta de comunicación
es una fuente común de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de información bien desarrollados amplían la comunicación y facilitan la integración de funciones individuales.
- Interconexión: (aumento en la comunicación).
- Integración de áreas en las empresas.
Competitividad
- Asegurar clientes.
Como los clientes son los más importantes para una organización, los directivos buscan diferentes formas para conseguir nuevos clientes y mantener los que tienen. Para eso las empresas proporcionan:
1- Mejores precios
2- Servicios
exclusivos.
3- Productos diferentes.
Estrategias para su desarrollo
Los sistemas de información basados en computadoras sirven para diversas finalidades que van desde el procesamiento de las transacciones de una empresa
hasta proveer de la información necesaria para decidir sobre asuntos que se presentan con frecuencia.
En algunos casos los factores que deben considerarse en un proyecto de sistema de información
, como el aspecto más apropiado de la computadora o la tecnología de comunicaciones que se va a utilizar, el impacto del nuevo sistema sobre los empleados de la empresa y las características específicas que el sistema debe tener se pueden determinar de manera secuencial.
Método de desarrollo por análisis estructurado
Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de:
La división del sistema en componentes.
La construcción de un modelo
del sistema.
El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento
, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.
Componentes
Símbolos gráficos: Íconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.
Diccionario de datos: Descripción de todos los datos usados en el sistema. Puede ser manual o automatizado.
Descripciones de procesos y procedimientos: Declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.
Reglas: Estándares para describir y documentar el sistema en forma correcta y completa.
Diseño Estructurado.
El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional.
La herramienta fundamental del Diseño Estructurado es el diagrama
estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.
Análisis de flujo de datos.
Estudia el empleo
de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.
Herramientas
Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.

Diagrama de flujo de datos
Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes.
El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación.
Flujo de datos: Son movimientos de datos en una determinada dirección,
desde un origen hasta un destino. Es un paquete de datos.
Proceso: Son personas, procedimientos o dispositivos que utilizan o producen datos. No identifica el componente físico.
Fuente o destino de los datos: Pueden ser personas, programas, organizaciones u otras entidades que interactúan con el sistema pero que se encuentre fuera.
Almacenamiento de datos: Es un lugar donde se guardan los datos. El almacenamiento de datos puede representar dispositivos tanto computarizados como no computarizados.
Cada componente en un diagrama de flujo
de datos tiene una etiqueta con un nombre descriptivo. Los nombres de los procesos reciben un número para poder identificarlos, este número tiene un valor adicional cuando se estudian los componentes que integran un proceso específico.