Diagrama de colaboración & Mensajes

Un diagrama de colaboración' en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboracion, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

    Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
    Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".

Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

Utilidad

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas:

    De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
    Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Driagrama de Secuencias

Utilidad

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas:

    De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
    Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.

Definición de polimorfismo

En programación orientada a objetos el polimorfismo se refiere a la posibilidad de enviar un mensaje a un grupo de objetos cuya naturaleza puede ser heterogénea. El único requisito que deben cumplir los objetos que se utilizan de manera polimórfica es saber responder al mensaje que se les envía.

La apariencia del código puede ser muy diferente dependiendo del lenguaje que se utilice, más allá de las obvias diferencias sintácticas.

Por ejemplo, en un lenguaje de programación que cuenta con un sistema de tipos dinámico (en los que las variables pueden contener datos de cualquier tipo u objetos de cualquier clase) como Smalltalk no se requiere que los objetos que se utilizan de modo polimórfico sean parte de una jerarquía de clases.

En lenguajes basados en clases y con un sistema de tipos de datos fuerte (independientemente de si la verificación se realiza en tiempo de compilación o de ejecución), es posible que el único modo de poder utilizar objetos de manera polimórfica sea que compartan una raíz común, es decir, una jerarquía de clases, ya que esto proporciona la compatibilidad de tipos de datos necesaria para que sea posible utilizar una misma variable de referencia (que podrá apuntar a objetos de diversas subclases de dicha jerarquía) para enviar el mismo mensaje (o un grupo de mensajes) al grupo de objetos que se tratan de manera polimórfica.

En Java, es frecuente y profusamente aconsejada la utilización de interfaces (que es un mecanismo del lenguaje que se emplea por medio de la palabra clave Interface) para proveer la necesaria concordancia de tipos para hacer posible el polimorfismo, también como un contrato que debe cumplir cualquier clase que implemente una cierta interfaz y como una forma de documentación para los desarrolladores. A veces, en la literatura que refiere específicamente a Java se hace mención a "herencia y polimorfismo de interfaces", lo que no concuerda con los conceptos de la programación orientada a objetos porque una clase que implementa una interfaz sólo obtiene su tipo de datos y la obligación de implementar sus métodos, no obtiene comportamiento ni de atributos. Esto muchas veces resulta paradójico porque en Java frecuentemente se utiliza la mal llamada "herencia de interfaces" para dotar a una clase con un tipo adicional (o varios) para que su uso en combinación con la agregación (colaboración o composición) permita evitar la necesidad de la herencia múltiple y favorezca una utilización más amplia del polimorfismo.

No obstante, el uso de una jerarquía de clases como paso previo, es muy habitual incluso en aquellos lenguajes en los que es posible prescindir de tal jerarquía, ya que, desde una perspectiva conceptual, se puede decir que al pertenecer los "objetos polimórficos" a subclases de una misma jerarquía, se asegura la equivalencia semántica de los mensajes que se invocarán de modo polimórfico. Por esto, en programación orientada a objetos a veces se denomina al polimorfismo como "polimorfismo de subclase (o de subtipo)".

En resumen, en la programación orientada a objetos, la esencia del polimorfismo no atañe a la clase o prototipo de la que provienen los objetos. Aún así, en los lenguajes basados en clases, es habitual (y en algunos tal vez sea el único modo) que dichos objetos pertenezcan a subclases pertenecientes a una misma jerarquía. Entonces, el polimorfismo debe verse como una forma flexible de usar un grupo de objetos (como si fueran sólo uno). Podría decirse que el polimorfismo en esencia refiere al comportamiento de los objetos, no a su pertenencia a una jerarquía de clases (o a sus tipos de datos).

Lo anterior se hace aún más evidente en lenguajes de programación orientada a objetos basados en prototipos, como Self, en los que las clases no existen.

Además, es importante remarcar que si un cierto grupo de objetos pueden utilizarse de manera polimórfica es porque, en última instancia, todos ellos saben responder a un cierto mensaje (o a varios), pero dado que esos mismos objetos generalmente contendrán otros métodos (que otros objetos en dicho grupo no contienen), difícilmente se pueda decir lisa y llanamente que los objetos son polimórficos; lo correcto es decir que esos objetos se pueden utilizar de modo polimórfico para un cierto conjunto de mensajes.

Un ejemplo. Podemos crear dos clases distintas: Pez y Ave que heredan de la superclase Animal. La clase Animal tiene el método abstracto mover que se implementa de forma distinta en cada una de las subclases (peces y aves se mueven de forma distinta). Entonces, un tercer objeto puede enviar el mensaje mover a un grupo de objetos Pez y Ave por medio de una variable de referencia de clase Animal, haciendo así un uso polimórfico de dichos objetos respecto del mensaje mover.

El concepto de polimorfismo, desde una perspectiva más general, se puede aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellas funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un elemento cuyo tipo no está especificado.

Definicion Metaclases

En programación orientada a objetos, una metaclase es una clase cuyas instancias son clases. En otras palabras, como los objetos son instancias de una clase, las clases son instancias de una metaclase.

No todos los lenguajes orientados a objetos soportan metaclases. Además, los lenguajes que lo soportan tienen sus propias reglas que definen como los objetos, clases y metaclases interactúan.

Las metaclases permiten saber el tipo exacto de un objetocuando lo único que se tiene es un manejador a su clase base. suministra un conjunto de metaclases con este objetivo:
Class, Field, Method, Constructor,
etc. Asímismo, la clase
Object
posee el método
getClass(),
que permite obtener un objeto de tipo
Class
con toda la información sobre el verdadero objeto apuntado.* El objeto
.class
correspondiente a una clase cualquiera
Xxx
 puede obtenerse sencillamente mediante la expresión
Xxx.class
.* La verdad es que, durante la ejecución, por cada clase que haycargada, Java mantiene un objeto oculto de tipo
Class
quedescribe a dicha clase.* Ese objeto de tipo
Class
se utiliza en tiempo de ejecución parachequear las conversiones de tipo efectuadas por el programador.* El operador
instanceof
nos dice si un objeto es instancia deuna clase determinada o no.

Definicion de Abstraccion

hay ocasiones, cuando se desarrolla una jerarquía de clases en que algún comportamiento está presente en todas ellas pero se materializa de forma distinta para cada una. Por ejemplo, pensemos en una estructura de clases para manipular figuras geométricas. Podríamos pensar en tener una clase genérica, que podría llamarse Figura geométrica y una serie de clases que extienden a la anterior que podrían ser Círculo, Polígono, etc. Podría haber un método dibujar dado que sobre todas las figuras puede llevarse a cabo esta acción, pero las operaciones concretas para llevarla a cabo dependen del tipo de figura en concreto (de su clase). Por otra parte la acción dibujar no tiene sentido para la clase genérica Figura geométrica, porque esta clase representa una abstracción del conjunto de figuras posibles.

Concepto de mensajes

Veamos detenidamente qué es un mensaje:
Un único objeto de por sí no es demasiado útil. En general, un objeto es un componente más de un programa o una aplicación que contiene otros muchos objetos. Con esta interacción los programadores
conseguimos una funcionalidad de mayor orden y podemos modelar comportamientos mucho más
complejos.
La Ambulancia que teníamos aparcada no es más que chapa por sí sola, es incapaz de desarrollar ninguna actividad. Es útil cuando otro objeto (conductor, por ejemplo) la conduce.
Los objetos de un programa interactúan y se comunican entre ellos por medio de mensajes. Cuando un objeto A quiere que otro objeto B ejecute una de sus funciones miembro (métodos de B), el objeto A manda un mensaje al objeto B. (¿complejo? :-)
A veces el objeto que recibe el mensaje necesita más información, si le decimos que queremos subir la velocidad, deberíamos además, decirle la velocidad exacta, por ejemplo. Esta información se pasa junto con el mensaje en forma de parámetro.
Partes del mensaje si quisiéramos (Yo) decirle a MiAmbulancia que suba la velocidad en 10 km/h:

1. El objeto al cual se manda el mensaje (MiAmbulancia).
2. El método o función miembro que debe ejecutar (SubirVelocidad()).
3. Los parámetros que necesita ese método (10).

Estas tres partes del mensaje (objeto destinatario, método y parámetros) son suficiente información para que el objeto que recibe el mensaje ejecute el método o la función miembro solicitada.
Los mensajes proporcionan dos ventajas importantes:

• El comportamiento de un objeto está completamente determinado (a excepción del acceso directo a variables miembro públicas) por sus métodos, así que los mensajes representan todas las posibles interacciones que pueden realizarse entre objetos.
• Los objetos no necesitan formar parte del mismo proceso, ni siquiera residir en un mismo ordenador para mandarse mensajes entre ellos (y de esta forma interactuar).

Concepto de Clases

En la programación orientada a objetos, una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto, por ejemplo, una instancia del objeto de la clase "Persona" sería del tipo "Persona".

Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a través de marcadores de datos llamados atributos (o variables miembro o variables de instancia), y encapsula el comportamiento a través de secciones de código reutilizables llamados métodos.

Más técnicamente, una clase es un conjunto coherente que consiste en un tipo particular de metadatos. Una clase tiene tanto una interfaz y una estructura. La interfaz describe cómo interactuar con la clase y sus instancias con métodos, mientras que la estructura describe cómo los datos se dividen en atributos dentro de una instancia. Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase. En el diseño orientado a objetos, una clase es el tipo más específico de un objeto en relación con una capa específica.

Los lenguajes de programación que soportan clases difieren sutilmente en su soporte para diversas características relacionadas con clases. La mayoría soportan diversas formas de herencia. Muchos lenguajes también soportan características para proporcionar encapsulación, como especificadores de acceso.

Programación Orientada a Objetos

La programación orientada a objetos (POO), es una de las más grandes ideas
en el campo de la programación durante los años recientes. Todo se reduce a
organizar los programas en formas que van a plasmar el mundo real para
representarlo en un mundo de computadora.

La clave en ésta forma de programar son los objetos que nos rodean. Estos
objetos pueden ser cosas físicas como personas, casas, sillas, etc. o cosas lógicas
como el clima, la hora, la fecha, etc.
La POO nos permitirá resolver problemas de la vida real usando objetos de la
vida real.

Proceso de Negocios

MARCO TEORICO PROCESOS DE NEGOCIOS

BORRADOR

2001

MARCO TEORICO

El aporte que la tecnología de la información puede entregar a una organización puede ser visto en tres niveles: Procesos, Aplicaciones y Datos.
Este orden es el más adecuado para abordar un proyecto de diseño o rediseño de los procesos de una organización. Sin embargo, para explicarlos se analizarán en sentido inverso.
Los Datos
Los datos son el nivel básico de un sistema de información, existen diversas formas de almacenarlos como puede ser el papel ó un medio magnético en cuyo caso conforman lo que se denomina archivos. Un aspecto muy importante es la forma en que estos archivos se organizan y son vistos por las aplicaciones; en la actualidad existe una indiscutible superioridad del modelo cliente-servidor utilizando como lenguaje de acceso y grabación al SQL.
Un proyecto para una empresa debería tener como trasfondo la utilización del modelo cliente-servidor con SQL. Una vez declarado esto, se puede decir que, para trabajar las bases de datos del tipo relacional como son las que operan en este modelo, existen diversas tecnologías de representación de los datos. Pudiéndose utilizar, un modelo entidad-relación que permite describir muy bien los archivos (tablas en lenguaje SQL) y sus relaciones.
Para este tipo de tecnología, existen indicadores que permiten ver el potencial del modelamiento de una base de datos. El potencial del modelo de datos, está en la eficacia para responder con celeridad a las aplicaciones clientes en las consultas que éstas requieran.
Hay varias herramientas para manejar el modelo de datos entidad-relación. Pudiéndose utilizar el “System Architect”. Este software tiene la ventaja de apoyar también en la tarea de definición de las aplicaciones, y es uno de los paquetes con amplio uso en las empresas nacionales.
Las Aplicaciones
Este nivel también se denomina “las funciones” y considera todas la reglas que la empresa se dá para manejar el negocio en relación con sus datos. Dichas reglas pueden pertenecer a un manual de procedimientos o ser informales.
En el caso computacional, las funciones están muy relacionadas a un algoritmo. Por ejemplo, un banco para un cierto crédito aplica tasas de interés que devengan en el monto de un dividendo. Esta lógica se concreta a través de una función que permite ver los datos del cliente (como capacidad de crédito), los datos del crédito (como plazo y monto) y relacionarlos para entregar un resultado como el monto del dividendo a pagar.
Hoy día en el modelo cliente-servidor SQL se puede generar un archivo con las funciones y por lo tanto tener de esta manera no sólo un servidor de base de datos sino también tener un servidor de funciones. Esta tecnología es ampliamente conocida a través del concepto de “procedimientos almacenados”. Sin embargo, también existen otras formas de almacenar estas funciones que no necesariamente involucran al servidor de Base de datos.
Existe una parte muy significativa de las funciones, que aparece mucho más clara cuando a éste nivel se le denomina Aplicación; y se refiere a cómo la función se presenta al usuario final: la interfaz con el usuario. Es muy probable que en un futuro existan objetos computacionales que incluyan ambos elementos: algoritmo e interfaz y que éstos puedan ser almacenados en algún servidor.
Los Procesos
Los procesos han sido virtualmente marginados del mundo de la informática, de manera que el acercamiento que ha tenido el análisis de sistema se ha reducido a los dos niveles anteriores: Datos y Funciones. De esta manera, es común encontrar sistemas computacionales que manejan un excelente modelo de datos y una serie de funciones que los presentan y resuelven la manera en que la empresa ve estos datos, pero dichas funciones no tienen un proceso en que se inserten. Incluso éstos sistemas pueden llegar a tener una interfaz con el usuario hecha en Windows, la que deslumbra al usuario final y en una primera impresión dicho usuario tenga la impresión de estar frente un software de tecnología muy reciente.
Sin embargo, el asunto del proceso es central por lo que se ilustrará a través de un ejemplo. Supóngase una empresa de atención a cliente que recibe órdenes de compra telefónicas. El depto. de informática, construyó un software que permite ingresar esta orden de compra con todos sus antecedentes, entre los cuales esta el cliente. El cliente, en los sistemas más modernos es ubicado a través de su razón social o nombre, con lo cual es posible traer el Rut, dato necesario al definir la Orden de compra. Supongamos que el cliente no está, es decir es nuevo. En este caso un sistema en la tradición “datos-funciones” trae a pantalla la ficha del cliente con todos sus antecedentes. Estos antecedentes no son necesarios para la Orden de compra en cuestión, pero sí lo pueden ser en trámites posteriores. Como los datos requeridos son extensos el vendedor opta por no llenar todos los datos o por no utilizar el sistema porque le entorpece su trabajo. De esta manera, o la Orden de compra sigue una deriva en papeles externa al sistema computacional o los datos de la ficha del cliente quedan incompletos restando su potencial uso en otras instancias de la empresa.
Este ejemplo es el caso típico en que no se tuvo en cuenta que la creación de una ficha de un cliente es un proceso, y que ese proceso se inicia al ingresar una Orden de compra telefónica, que recoge los datos mínimos para no perturbar la venta, y que deja pendiente tareas para que otra persona de la organización complete esta tarea en otro momento.
La tecnología que se hace cargo de la completitud de los procesos en la informática se denomina “Workflow”. Es la opinión de muchos expertos que el rediseño de los procesos de una organización debe partir por ahí, por identificar los procesos relevantes y definir para ellos las funciones y datos necesarios.
Una consecuencia de esto apunta a lo siguiente: ha sido la visión limitada de ver sólo datos y funciones la que ha llevado a la gente de computación a escribir muchos más programas de los realmente son utilizados en la explotación de los sistemas. Esto porque se mira los datos y se busca luego cuales son todas la funciones de “consulta”, “mantención”, “ingreso” y “eliminación” que cada una de las tablas requiere. De esta manera, la matriz resultante “datos-funciones” es siempre mayor que la que se obtiene al preguntarse: ¿cuáles son los usuarios que existirán y bajo qué cirscunstancias podrán consultar, poblar, eliminar o actualizar datos?. Dicho de otra manera los procesos no son los triviales: “consulta”, “mantención”, “ingreso” y “eliminación”, sino que están insertos en una empresa que tiene definidos procesos más grandes en los cuales los de la información son parte. En el ejemplo de la Orden de compra telefónica, dado antes, se construyó la aplicación que permitía poblar la tabla de clientes, sin embargo, al no estar declarada esa función dentro de ningún proceso de la empresa, ésta función no tiene usuario y resulta inútil.
Otra consecuencia que también produce la miopía de no considerar los procesos, está ligada a la estructura que se da a la organización y que tiene repercusiones en la informática. Desde la revolución industrial hasta ahora se ha estructurado la empresa en una suerte de departamentos especializados. De esta manera en la empresa se distingue un departamento de contabilidad, de tesorería, de ventas, etc. El alto costo de esta especialización y división ha significado a juicio de muchos especialistas, que algunas empresas dejen de ser competitivas en el mercado; y hoy día se está haciendo un enorme esfuerzo por reestructurar la empresa en torno a sus procesos de negocios. La interpretación ofrecida aquí, coloca a la informática en un muy buen pié para colaborar dentro de esta nueva dirección. Si se hacen las funciones computacionales iluminadas por la lógica de los procesos de negocio, se avanzará en la dirección correcta. Para ilustrar este punto supongase una empresa en que se hacen Notas de venta y éstas deben ser aprobadas por un supervisor. El análisis de sistema tradicional resuelve este punto proveyendo al supervisor de: a) una consulta en el sistema de Cuentas corrientes que le permite ver el estado del cliente como: cupo máximo de crédito, morosidad, etc. b) una consulta en el sistema de inventario que le permite revisar los márgenes de los productos involucrados en la Nota de venta los cuales cotejará contra las políticas de márgenes y comisiones asociados al cliente/vendedor. Además, puede existir otro conjunto de consultas de apoyo. Lo que es importante de mostrar aquí es que probablemente el usuario supervisor de ventas deberá viajar a través de un conjunto de menús y pantallas en una deriva loca por encontrar la información necesaria para aprobar dicha nota de venta. Lo hará una vez o dos y después de fatigarse en esta gimnasia es altamente probable que no vuelva a hacerlo. En esta añeja lógica de análisis de sistema se va detrás de la organización en sus diferentes departamentos, pero con la ceguera para ver que la empresa cuando actúa no lo hace así. De nuevo el análisis matricial entre datos y funciones arrojó las consultas necesarias, pero no existe un proceso en el cuál dichas consultas sean necesarias; mientras que la consulta integral que si es necesaria para este supervisor nunca se hizo.
A continuación se va a revisar más en detalle el concepto proceso y lo que se quiere decir en la interpretación que se ofrece dentro de la metodología.
El concepto proceso ha sufrido una variación en su interpretación en los últimos años. Hace 40 años atrás cuando un ingeniero hablaba de procesos se refería a las modificaciones que alteraban los materiales o elementos físicos en una empresa. Durante las últimas décadas ha ocurrido que cuando se habla de procesos se considera también, toda la operación que se hace con datos y archivos, ambos tópicos relacionados a la informática.
Recientemente ha aparecido el tema de los procesos con una visión más global en la que se incluyen no sólo los conceptos anteriores, sino que se agregan elementos nuevos como son: comunicaciones, personas, teléfonos, etc. Hoy la idea de procesos se entiende mucho más por la forma en que toda la organización hace algo.
Uno de los instrumentos básicos que la ingeniería utiliza es el modelamiento de procesos . Ha sido una práctica recurrente la utilización de mapas y/o planos que representan gráficamente estos modelos. Asi por ejemplo se pueden encontrar en la tradición ingenieril: Cartas Gantt y Pert para estudio de proyectos, Planos de construcción de obras civiles, Diagramas de procesos industriales, Diagramas de Flujos, Flujos de datos, etc.
No siempre es de sentido común decir que un mapa es un instrumento de navegación, más usual es verlos como descriptores del mundo. Esto tiene que ver con la educación tradicional, que habla de la necesidad y capacidad que se tendría de describir el mundo real y deja de lado que el mapa es el mundo visto con una interpretación. Y que esta interpretación siempre tiene un propósito que se ajusta a una particular y única intención del observador que lo construye.
Los mapas de la ingeniería también son instrumentos de navegación, son una interpretación del fenómeno que describen con una cierta intencionalidad. Ellos han conseguido una aceptación general y universal, tienen asociados elementos cuantificadores y tienen una capacidad de diseño y de predicción de aquello que representan. Hasta hace poco habían sido mapas útiles para navegar en el mundo de los negocios.
Ya no son útiles, porque como la interpretación que son, omiten al principal actor de los discursos de hoy día: las personas, y aunque éstas son tomadas en cuenta por otras ciencias como la sicología, la sociología, éstas no nos proveen de un mapa ingenieril, es decir medible, repetible.
Los mapas tradicionales de la ingeniería no muestran cómo se producen las coordinaciones de las actividades en los procesos, o sea, las acciones y prácticas de las personas que realizan los procesos que se grafican.
Los mapas actuales interpretan los procesos enfocándolos principalmente en los movimientos de papeles o datos, o en las transformaciones de materiales y su movimiento, pero ocultan el proceso global donde se insertan.
Para mejor entender esta última observación se definirán tres tipos de procesos. Estos procesos son formas de interpretar las organizaciones y los negocios en general. Los dos primeros, los procesos materiales y los de información, han sido exitosos para entender situaciones estructuradas, pero hoy son ineficientes cuando se quiere considerar los aspectos humanos, como motivación, innovación, etc.
a) Procesos materiales.
Estos son el tema tradicional de la ingeniería y se refieren a aquel proceso en que la visión se centra en los materiales, en cómo éstos se transforman, se transportan, se construyen, se almacenan, etc. Observa las acciones físicas de los procesos.
Muchas de las ingenierías se definen asumiendo los nombres de los procesos con que esas prácticas se identifican (ingeniería mecánica, eléctrica, industrial etc.). Hace unos 40 años atrás no existía (no se veían) otro tipo de procesos.
b) Procesos de información.
Son aquellos procesos que miran el traspaso, transformación, almacenamiento, comunicación, etc. de elementos de información.
Estos procesos se han visto también como controles de los procesos materiales y utilizan una diagramación que les es propia: Diagramas de flujo, modelo de datos, diagrama de funciones, Flujo de datos, etc.
c) Procesos de negocios.
Lo central en este tipo de procesos es que se observan los negocios y las organizaciones como una red de compromisos y de coordinación de acciones entre la gente y que es al fin y al cabo, la que hace que los dos procesos anteriores ocurran.
Los elementos de trabajo aquí son propios de los seres humanos, tales como: roles, compromisos, solicitudes, satisfacción del cliente.
Esta interpretación nos permite observar y modelar cómo la coordinación y los compromisos se orientan hacia la satisfacción del cliente, cómo se innova, cuando se desmotivan los responsables de los diferentes roles. En suma entrega respuestas a las preguntas relevantes de hoy para los negocios.
Es más, los procesos de negocios entregan la posibilidad ingenieril de rediseñar las organizaciones orientándolas hacia el cliente, además de ir aprendiendo de la propia práctica, dejando un espacio a los miembros de la organización para innovar.

Tecnicas de Recoleccion de datos

TÉCNICAS PARA HALLAR DATOS

 
Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.

LA ENTREVISTA

Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.
Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevistas es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.
Preparación de la Entrevista

1. Determinar la posición que ocupa de la organización el futuro entrevistado, sus responsabilidades básicas, actividades, etc. (Investigación).
2. Preparar las preguntas que van a plantearse, y los documentos necesarios (Organización).
3. Fijar un límite de tiempo y preparar la agenda para la entrevista. (Sicología).
4. Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad (Sicología).
5. Hacer la cita con la debida anticipación (Planeación).

Conducción de la Entrevista

1. Explicar con toda amplitud el propósito y alcance del estudio (Honestidad).
2. Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (Imparcialidad).
3. Hacer preguntas específicas para obtener respuestas cuantitativas (Hechos).
4. Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (habilidad).
5. Evitar el cuchicheo y las frases carentes de sentido (Claridad).
6. Ser cortés y comedio, absteniéndose de emitir juicios de valores. (Objetividad).
7. Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión.
8. Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas (Comunicación).

Secuela de la Entrevista

1. Escribir los resultados (Documentación).
2. Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. (Profesionalismo).
3. Archivar los resultados de la entrevista para referencia y análisis posteriores (Documentación).

Recabar datos mediante la Entrevista
La entrevista es una forma de conversación, no de interrogación, al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no están disponibles en ningún otra forma.
En las investigaciones de sistema, las formas cualitativas y cuantitativas de la información importantes. La información cualitativa está relacionada con opinión, política y descripciones narrativas de actividades o problemas, mientras que las descripciones cuantitativas tratan con números frecuencia, o cantidades. A menudo las entrevistas pueden ser la mejor fuente de información cualitativas, los otros métodos tiende a ser más útiles en la recabación de datos cuantitativos.
Son valiosas las opiniones, comentarios, ideas o sugerencia en relación a como se podría hacer el trabajo; las entrevistas a veces es la mejor forma para conocer las actividades de las empresas. La entrevista pueden descubrir rápidamente malos entendidos, falsa expectativa o incluso resistencia potencial para las aplicaciones de desarrollo; más aún, a menudo es más fácil calendarizar una entrevista con los gerentes de alto nivel, que pedirle que llenen cuestionario.


¿Qué es una encuesta?
Se ha dicho que Estados Unidos ya no es una "sociedad industrial", sino una "sociedad de información". Esto es, nuestros mayores problemas y tareas ya no giran principalmente en la producción de bienes y servicios necesarios para nuestra supervivencia y comodidad.
Nuestra "sociedad", requiere un rápido y preciso flujo de información sobre las preferencias, necesidades y comportamiento de sus miembros. Es en respuesta a esta necesidad crítica de información por el gobierno, el comercio y las instituciones sociales que tanta confianza se pone en las encuestas.
Hoy en día la palabra "encuesta" se usa más frecuentemente para describir un método de obtener información de una muestra de individuos. Esta "muestra" es usualmente sólo una fracción de la población bajo estudio.
Por ejemplo, antes de una elección, una muestra de electores es interrogada para determinar cómo los candidatos y los asuntos son percibidos por el público… un fabricante hace una encuesta al mercado potencial antes de introducir un nuevo producto… una entidad del gobierno comisiona una encuesta para obtener información para evaluar legislación existente o para preparar y proponer nueva legislación.
No tan sólo las encuestas tienen una gran variedad de propósitos, sino que también pueden conducirse de muchas maneras, incluyendo por teléfono, por correo o en persona.
Aún así, todas las encuestas tienen algunas características en común.
A diferencia de un censo, donde todos los miembros de la población son estudiados, las encuestas recogen información de una porción de la población de interés, dependiendo el tamaño de la muestra en el propósito del estudio. En una encuesta bona fide, la muestra no es seleccionada caprichosamente o sólo de personas que se ofrecen como voluntarios para participar. La muestra es seleccionada científicamente de manera que cada persona en la población tenga una oportunidad medible de ser seleccionada. De esta manera los resultados pueden ser proyectados con seguridad de la muestra a la población mayor. La información es recogida usando procedimientos estandarizados de manera que a cada individuo se le hacen las mismas preguntas en mas o menos la misma manera. La intención de la encuesta no es describir los individuos particulares quienes, por azar, son parte de la muestra sino obtener un perfil compuesto de la población.
Una "encuesta" recoge información de una "muestra." Una "muestra" es usualmente sólo una porción de la población bajo estudio.
El estándar de la industria para todas las organizaciones respetables que hacen encuestas es que los participantes individuales nunca puedan ser identificados al reportar los hallazgos. Todos los resultados de la encuesta deben presentarse en resúmenes completamente anónimos, tal como tablas y gráficas estadísticas.

Cuestionario

Los cuestionarios proporcionan una alternativa muy útil para la entrevista; si embargo, existen ciertas características que pueden ser apropiada en algunas situaciones e inapropiadas en otra. Al igual que la entrevistas, deben diseñarse cuidadosamente para una máxima efectividad.
Recabación de datos mediante cuestionarios
Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran número de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamento, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos en relación al sistema. En mayor parte de los casos, el analista no verá a los que responde; no obstante, también esto es una ventaja porque aplican muchas entrevista ayuda a asegurar que el interpelado cuenta con mayor anonimato y puedan darse respuestas mas honesta ( y menos respuestas prehechas o estereotipadas). También las preguntas estandarizadas pueden proporcionar datos más confiable.
Selección de formas para cuestionarios
El desarrollo y distribución de los cuestionarios; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. También es importante el formato y contenido de las preguntas en la recopilación de hechos significativos.
Existen dos formas de cuestionarios para recabar datos: cuestionarios abiertos y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlas. Con frecuencia se utilizan ambas formas en los estudios de sistemas.
Cuestionario Abierto
Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito, es un medio.
El formato abierto proporciona una amplia oportunidad para quienes respondan escriba las razones de sus ideas. Algunas personas sin embargo, encuentran más fácil escoger una de un conjunto de respuestas preparadas que pensar por sí mismas.
Cuestionario Cerrado
El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma su opinión sobre los aspectos importantes.

La OBSERVACIÓN

Otra técnica útil para el analista en su progreso de investigación, consiste en observar a las personas cuando efectúan su trabajo. Como técnica de investigación, la observación tiene amplia aceptación científica. Los sociólogos, sicólogos e ingenieros industriales utilizan extensamente ésta técnica con el fin de estudiar a las personas en sus actividades de grupo y como miembros de la organización. El propósito de la organización es múltiple: permite al analista determinar que se está haciendo, como se está haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, dónde se hace y por que se hace.
"¡Ver es creer! Observar las operaciones la proporciona el analista hechos que no podría obtener de otra forma.
Tipos de Observación
El analista de sistemas puede observar de tres maneras básicas. Primero, puede observar a una persona o actitud sin que el observado se dé cuenta y su interacción por aparte del propio analista. Quizá esta alternativa tenga poca importancia para el análisis de sistemas, puesto que resulta casi imposible reunir las condiciones necesarias. Segundo, el analista puede observar una operación sin intervenir para nada, pero estando la persona observada enteramente consciente de la observación. Por último, puede observar y a la vez estar en contacto con las personas observas. La interacción puede consistir simplemente en preguntar respecto a una tarea específica, pedir una explicación, etc.
Preparación para la observación

1. Determinar y definir aquella que va a observarse.
2. Estimular el tiempo necesario de observación.
3. Obtener la autorización de la gerencia para llevar a cabo la observación.
4. Explicar a las personas que van a ser observadas lo que se va a hacer y las razones para ello.

Conducción de la observación

1. Familiarizarse con los componentes físicos del área inmediata de observación.
2. Mientras se observa, medir el tiempo en forma periódica.
3. Anotar lo que se observa lo más específicamente posible, evitando las generalidades y las descripciones vagas.
4. Si se está en contacto con las personas observadas, es necesario abstenerse de hacer comentarios cualitativos o que impliquen un juicio de valores.
5. Observar las reglas de cortesía y seguridad.

Secuela de la observación

1. Documentar y organizar formalmente las notas, impresionistas, etc.
2. Revisar los resultados y conclusiones junto con la persona observada, el supervisar inmediato y posiblemente otro de sistemas.

Diagrama de Flujo

Es una representación pictórica de los pasos en proceso. Útil para determinar cómo funciona realmente el proceso para producir un resultado. El resultado puede ser un producto, un servicio, información o una combinación de los tres. Al examinar cómo los diferentes pasos es un proceso se relacionan entre sí, se puede descubrir con frecuencia las fuentes de problemas potenciales. Los diagramas de flujo se pueden aplicar a cualquier aspecto del proceso desde el flujo de materiales hasta los pasos para hacer la venta u ofrecer un producto. Con frecuencia este nivel de detalle no es necesario, pero cuando se necesita, el equipo completo de trabajo más pequeños pueden agregar niveles según sea necesario durante el proyecto.
¿Cuándo se utiliza un Diagrama De Flujo?
Cuando un equipo necesita ver cómo funciona realmente un proceso completo. Este esfuerzo con frecuencia revela problemas potenciales tales como cuellos de botella en el sistema, pasos innecesarios y círculos de duplicación de trabajo.
Algunos aplicaciones comunes son:
Definición de Proyectos:

• Identificar oportunidades de cambios en el proceso.
• Desarrollar estimados de costos de mala calidad.
• Identificar organizaciones que deben estar representadas en el equipo.
• Desarrollar una base común de conocimiento para los nuevos miembros del equipo.
• Involucrar a trabajadores en los esfuerzos de resolución de problemas para reducir las resistencias futura al cambio.

Identificación de las causas principales:

• Desarrollar planes para reunir datos.
• Generar teorías sobre las causas principales.
• Discutir las formas de estratificar los datos para el análisis para identificar las causas principales.
• Examinar el tiempo requerido para las diferentes vías del proceso.

Diseño de soluciones

• Describir los cambios potenciales en el proceso y sus efectos potenciales.
• Identificar las organizaciones que será afectadas por los cambios propuesto.

Aplicaciones de soluciones:

• Explicar otros el proceso actual y la solución propuesta.
• Superar la resistencia al cambio demostrando cómo los cambios propuestos simplificarán el proceso.

Control (retener las Ganancias):

• Revisar y establecer controles y monotorías al proceso.
• Auditar el proceso periódicamente para asegurar que están siguiendo los nuevos procedimientos.
• Entrenar a nuevos empleados.

¿Cómo se Utiliza?
La metodología para prepara un Diagrama de Flujo es;

1. PROPÓSITO: analizar como se pretende utilizar el Diagrama de Flujo. Exhibir esta hoja en el pared y consultarla en cualquier momento para verificar que se Diagrama de Flujo es apropiado para las aplicaciones que se pretende.
2. DETERMINAR EL NIVEL DE DETALLE REQUERIDO.
3. DEFINIR LOS LIMITES: después de establecer los límites del proceso, enumerar los resultados y los clientes en el extremo derecho del diagrama.
4. UTILIZAR SÍMBOLOS APROPIADOS: utilizando los símbolos apropiados para el Diagrama de Flujo, presentar las respuestas como los primeros pasos en el diagrama.
5. HACER PREGUNTAS: para cada input, haga preguntas como:

• ¿Quién recibe el input?
• ¿Qué es lo primero que se hace con el input?

1. DOCUMENTAR: cada paso en la secuencia, empezando con el primer (ó último) paso. Para cada paso, hacer preguntas como:

• ¿Qué produce este paso?
• ¿Quién recibe este resultado?
• ¿Qué pasa después?
• ¿Alguno de los pasos requiere de inputs que actualmente no se muestran?

1. COMPLETAR: continuar la construcción del Diagrama de Flujo hasta que se conecte todos los resultados (outputs) definidos en el extremo derecho del diagrama. Si se encuentra un segmento del proceso que es extraña para todos en el salón, se deberá tomar nota y continuar haciendo el diagrama.
2. REVISIÓN: Preguntar:

• ¿Todos los flujos de información encajan en los inputs y outputs del proceso?
• ¿El Diagrama muestra la naturaleza serial y paralela de los pasos?
• ¿El Diagrama capta de forma exacta lo que realmente ocurrió, a diferencia de la forma cómo se piensa que las cosas deberías pasar o como fueron diseñadas originalmente?

1. DETERMINAR OPORTUNIDADES

Nota: El Diagrama de flujo final deberá actuar como un registro de cómo el proceso actual realmente opera. Indicar la fecha.
Aunque hay literalmente docenas de símbolos especializadas utilizados para hacer Diagrama de Flujos, se utiliza con más frecuencia los siguientes:
 Para ver el gráfico seleccione la opción "Descargar"
Las "líneas de flujos" son utilizadas para representar el progreso de los pasos en la secuencia. La punta de la fecha indica la dirección del flujo del proceso.
Otros dos símbolos que no son utilizados tan comúnmente y que pueden ser útiles son:
El "Símbolo del documento" representa la información escrita pertinente al proceso.
 El "Símbolo de la Base de Datos" representa información almacenada electrónicamente con respecto al proceso

Diagrama de caso de uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

Tipos de Diagrama UML

- Diagrama de Clases: sirve para mostrar la estructura estática de un sistema, ya sean estas las clases como los paquetes.
- Diagrama de Estructura Compuesta: nuevo en UML2, este diagrama muestra la estructura INTERNA de un elemento o clase.
- Diagrama de Componente: muestra el sistema como una colección de componentes tecnológicos, ejecutables, DLLs, páginas de HTML, etc.
- Diagrama de Despliegue: muestra como el los componentes de un sistema se distribuyen entre los computadores que los ejecutan. Útil en el caso de sistemas distribuidos.
- Diagrama de Objeto: muestra instancias de clases y sus nexos.
- Diagrama de Paquete: muestra paquetes y sus relaciones, suele ser útil para la gestión de un modelo grande en UML.
- Diagrama de actividad: suerte de diagrama de flujo, indican actividades, decisiones y bifurcaciones.
- Diagrama de Secuencia: muestra la interacción entre elementos indicando claramente el eje de tiempo (hay un ejemplo en “Analisis de Casos de Uso”)
- Diagrama de Comunicación: equivale a un diagrama de secuencia, pero colapsa el eje del tiempo.
- Diagrama de Resumen de Interacción: dado que no hay paquetes de actividades se muestran las partes de un diagrama de actividad agrupando estas a la manera de un paquete, pero con un símbolo distinto.
- Diagrama de Tiempo: muestra la evolución de uno o más componente como líneas de vidas que se cruzan en un eje de tiempo. Esto es útil en desarrollo de sistemas en tiempo real.
- Diagrama de Casos de Uso: sirve para ilustrar un modelo de casos de uso. En el blog hay muchos ejemplos de estos.

UML

EL DESARROLLO DE SISTEMAS DE INFORMACIÓN

EMPLEANDO EL LENGUAJE DE MODELADO UNIFICADO UML

Resumen.
El presente artículo describe la evolución de las notaciones que dieron lugar a UML (Lenguaje de Modelado Unificado), detalla ampliamente sobre el surgimiento de la Ingeniería del Software, expone los principios de modelado en que se fundamenta la notación de UML, asimismo muestra y explica como el UML adopta el RUP(Proceso Unificado de Desarrollo) para modelar las actividades de un proyecto. Finalmente se propone la organización de los diagramas a utilizar en las diferentes etapas del desarrollo de los sistemas de información.
1. Introducción.
A lo largo de los años, el desarrollo de los proyectos de software causan bastantes confusiones y malas interpretaciones en los requerimientos de los clientes y usuarios, en parte debido a la abundancia de notaciones, metodologías y conceptos que hace que los desarrolladores de sistemas no se pongan de acuerdo en que es lo que realmente están elaborando. En un esfuerzo para estándarizar las notaciones y procesos a utilizar, se conformó un consorcio liderado por la empresa Rational y por las principales empresas del mundo de la industria de la informática, entre ellas, Microsoft, Oracle, Sun Microsystems, Intellicorp, IBM, AMD y otras, quienes desarrollaron una notación llamada UML y el proceso de desarrollo RUP.
2. La Ingeniería de Software.
La ingeniería del Software nace como una disciplina para aplicar los principios técnicas y herramientas de desarrollo de software, surgió porque todos los desarrolladores en la década de los 80's, realizaban el software de forma artística, es decir utilizando métodos y técnicas adhoc donde la experiencia (el ensayo-error) era el camino a seguir. Este enfoque produjo grandes y exitosos productos de programación pero conforme los proyectos se volvieron más complejos debido al avance del hardware y software y la penetración cada vez mayor de la informática en todos los ámbitos de la sociedad, llevó a que se produjera software sin calidad, se incumplieran los presupuestos y se incrementara dramáticamente los costos de mantenimiento.
La solución propuesta fue aplicar métodos y principios que han sido utilizados y probados en la experiencia de desarrollo de software para producir de forma inequívoca productos que corran eficientemente y se ejecuten sobre máquinas reales. En la década de los 70 surgieron una gran variedad de metologistas y metodologías entre ellos se destacan Yourdon y Demarco cuyas investigaciones se basaban en los principios de la programación estructurada. En los 80's y 90's el paradigma estructurado evolucionó hacia el paradigma orientado a objetos, en el período de 1989 y 1994 se creó la llamada guerra de métodos dentro de la comunidad orientada a objetos existiendo un incremento de menos de diez a más de cincuenta metodologías, es así que los desarrolladores de software quedaron muy confundidos sin saber cual era la metodología más adecuada para elaborar sus proyectos.
Ante lo enunciado, el UML oficialmente se presentó cuando Rumbaugh, Booch y Jacobson unifican sus estudios con una semántica y notación, para lograr compatibilidad en el análisis y diseño orientado a objetos, permitiendo que los proyectos se asentaran en un lenguaje de modelado maduro, permitiendo a los constructores de herramientas enfocarse en producir características más útiles.
3. La complejidad del Software.
Al observar sistemas complejos sociales como una gran empresa, los naturales como el universo y los sistemas creados por el hombre como el computador, se observa que exhiben una jerarquía de clases (conceptos) y otra de objetos (instancias). En una empresa donde conjuntos de personas forman un departamento y un conjunto de departamentos forman divisiones se describe la forma canónica de un sistema complejo que exhibe dos jerarquías: Una jerarquía de clases y otra jerarquía de objetos, donde cada objeto es una instancia de la una clase. Este es el modelo del cual se apropia el análisis y diseño orientado a objetos para desarrollar sistemas donde hay gran cantidad de software.

Figura 1.

Forma Canónica de un Sistema Complejo

4. Principios de Modelado
En cualquier proyecto de ingeniería como la construcción de un gran edificio, un avión, una represa hidroeléctrica, la construcción de un procesador de textos o un software de comunicaciones para Internet, requieren de etapas de modelamiento que permitan experimentar y visualizar el sistema que se construirá. De la experiencia en ingeniería se extractan los siguientes principios de modelado:
a) La forma como vemos el problema tiene una profunda influencia en forma como acometemos el problema y le damos solución al mismo.
Si pensamos que el mundo esta compuesto de clases (Abstracciones de la realidad y de la solución del problema) y objetos (instancias de éstas abstracciones) que interactúan entre si para realizar una funcionalidad, así veremos el mundo. Este es precisamente al paradigma a que le apuesta UML: el modelo orientado a objetos. Si vemos la realidad como compuesta de procesos donde cada uno a su vez se puede descomponer en subprocesos entonces estamos concibiendo la realidad según el modelo estructurado y la arquitectura del sistema en desarrollo estará conformada de programas y subprogramas.
b) Para modelar un sistema complejo no es suficiente un único modelo se requieren múltiples modelos donde cada uno representa una vista (aspecto) del sistema; estos modelos se complementan entre si.
Esta es la razón de la existencia de varios diagramas en UML que modelan diferentes aspectos del sistema, desde las vistas lógicas y físicas del sistema hasta los aspectos dinámicos, estáticos y funcionales del mismo.
c) Cualquier modelo puede ser representado con diferentes grados de precisión.
La precisión se puede ver desde dos ópticas: La primera es el grado de detalle con que se representa un modelo; por ejemplo, si lo que se desea es razonar acerca de los requerimientos del sistema con un cliente o usuario final, se puede elaborar un diagrama de clases que muestra las clases, sus atributos y operaciones así como varios adornos(multiplicidad) en las relaciones; por otro lado, si lo que se desea es transmitir el diagrama de clases para que sea implementado en un DBMS (Data Base Management System, Sistema Administrador de Bases de Datos) por un programador, el diagrama con toda seguridad contendrá la visibilidad de las características (atributos y operaciones) de las clases, los tipos de datos de los atributos y las signaturas de las métodos de las clases.
La segunda forma de ver la precisión de un modelo se refiere al nivel de abstracción, ese decir, a los detalles y la vista (porción del sistema o realidad) que presenta un modelo al lector; por ejemplo, en un sistema Bancario que maneja los retiros que hacen los clientes ya sea en un cajero automático o humano, el diagrama de clases contiene decenas de éstas; sin embargo las personas encargadas de desarrollar la interfaz de un cajero electrónico estarían interesadas en las clases necesarias para realizar el comportamiento del cajero y omiten el resto de clases del sistema.
d) Los mejores Modelos están ligados a la realidad.
El símbolo de un actor en un diagrama de casos de uso representa, de hecho, un actor en el sistema real; así como un componente en un diagrama de componentes representa un componente físico del software. Cada elemento de UML como una clase, objeto, estado, componente o nodo tiene su correspondencia con algún elemento conceptual o físico del mundo real.
5. El Lenguaje de Modelado Unificado UML.
“El Lenguaje de Modelado Unificado UML es un lenguaje estándar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra gran cantidad de software”
El UML es el Lenguaje de Modelado Unificado Orientado a Objetos, UML no es un método porque no tiene noción de proceso el cual es una parte importante de un método. Ahora bien si UML no es método; entonces ¿Cuáles son las etapas a seguir en el desarrollo de sistemas con UML?, varios especialistas en desarrollo de sistemas de información arguyen de que existe la necesidad de adoptar un Proceso de Desarrollo de sistemas para enmarcar las fases importantes que sigue el UML, por ello los desarrolladores de proyectos de sistemas de información emplean el Procesos Unificado para dar soluciones adecuadas a las necesidades de los clientes.
El desarrollo de sistemas con UML siguiendo el proceso unificado incluye actividades específicas, cada una de ellas a su vez contienen otras subactividades las cuales sirven como una guía de cómo deben ser las actividades desarrolladas y secuenciadas con el fin de obtener sistemas exitosos; consecuentemente el desarrollo de los sistemas puede variar de desarrollador en desarrollador, de proyecto en proyecto, de empresa en empresa adoptando siempre un Proceso de Desarrollo.
6. El proceso Unificado de Modelado (RUP).
A través de la historia se han desarrollado varios modelos de proceso de software (paradigmas de desarrollo) cada uno con sus ventajas, desventajas y utilidad en algunos tipos de proyectos y problemas. Al igual que cualquier notación, el proceso unificado actúa como un modelo que puede adaptarse a cualquier tipo de proyecto y empresa (grandes y pequeñas). Las características del proceso unificado de modelado son:

• Centrado en los Modelos: Los diagramas son un vehículo de comunicación más expresivo que las descripciones en lenguaje natural. Se trata de minimizar el uso de descripciones y especificaciones textuales del sistema.
• Guiado por lo casos de uso: Los casos de uso son el instrumento para validar la arquitectura del software y extraer los casos de prueba.
• Centrado en la arquitectura: Los modelos son proyecciones del análisis y el diseño constituye la arquitectura del producto a desarrollar.
• Iterativo e incremental: Durante todo el proceso de desarrollo se producen versiones incrementales (que se acercan al producto terminado) del producto en desarrollo.

Figura 2.

El Proceso de Modelado Unificado

El gráfico que representa el RUP incluye las cuatro etapas importantes que son: la iniciación, elaboración, construcción y transición, las cuales muestran que para producir una versión del producto en desarrollo se aplican todas las actividades de ingeniería pero con diferente énfasis; en las versiones preliminares, como además indica la intuición, hay más énfasis en actividades de modelado del negocio, requisitos, análisis y diseño; conforme se producen versiones el énfasis pasa a las actividades de implementación, pruebas y despliegue.
8. Diagramas de UML.
Los elementos de UML se muestran mediante diagramas que presentan múltiples vistas del sistema, ese conjunto de vistas son conocidos como modelos.
UML presenta varios diagramas donde cada uno representa un aspecto del sistema. De ahí que varios investigadores según sus criterios y puntos de vista mencionan qué diagramas emplear en el desarrollo de los sistemas de información; sin mencionar cuáles son los diagramas más adecuados en las distintas etapas de desarrollo del Proceso Unificado, viendo esta necesidad, la autora del presente artículo propone un conjunto de diagramas necesarios para cada etapa según la complejidad del sistema de información a solucionar.

Ciclo de vida de un software

Ciclo de Vida del Software

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos.

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software:

• Describe las fases principales de desarrollo de software.
• Define las fases primarias esperadas de ser ejecutadas durante esas fases.
• Ayuda a administrar el progreso del desarrollo, y
• Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

Alternativas de Modelos de Ciclo de Vida

Modelo Cascada

Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada
 del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.
El modelo de ciclo de vida cascada, captura algunos principios básicos:

• Planear un proyecto antes de embarcarse en él.
• Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
• Documentar los resultados de cada actividad.
• Diseñar un sistema antes de codificarlo.
• Testear un sistema después de construirlo.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.
Modelo De Desarrollo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

• Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
• Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
• Si un error importante es realizado, sólo la última iteración necesita ser descartada.
• Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
• Si un error importante es realizado, el incremento previo puede ser usado.
• Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.
Modelo de Prototipado de Requerimientos.-
El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.
El Prototipado ha sido usado frecuentemente en los 90, porque la especificación de requerimientos para sistemas complejos tienden a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación convenientemente basado en la manipulación, desde un prototipo, en vez de leer una especificación de requerimientos potencialmente ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente.
En caso que ustedes construyan requerimientos bien entendidos, el cliente podría responder con "sí, así es", y nada podría ser aprendido de la experiencia.
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:

• Determinar qué quieres lograr.
• Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
• Seguir la alternativa seleccionada en el paso 2.
• Establecer qué tienes terminado.

 
La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios básicos:

• Decidir qué problema se quiere resolver antes de viajar a resolverlo.
• Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
• Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
• No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.
Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.
En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5.
En todos estos casos, diversas actividades están ocurriendo simultáneamente. Eligiendo seguir un proyecto usando técnicas de modelación concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.

Fase I - Requerimientos
Fase II - Análisis / Diseño
Fase III - Construcción
Fase IV - Pruebas
Fase V - Producción / Mantenimiento

Fase I – Requerimientos

Esta fase fundamental para que la estrategia informática encaje dentro de las metas de la empresa, ya que en ella se cumplen las funciones del modelaje del negocio y planificación de sistemas; esto con el fin de proyectar las estrategias del negocio y determinar de esta forma sus requerimientos de información.
Durante esta fase se desarrolla un modelo del área estudiada, donde se representa: Los procesos que se llevan a cabo, la información utilizada por ellos y las reglas políticas y practicas de la empresa relacionada con estos procesos.
Este modelo permite proyectar las estrategias, procesos y flujos de datos de la empresa al igual que las interrelaciones entre procesos y datos, con el fin de desarrollar un plan de sistema de información capaz de guiar el desarrollo de un sistema que permita dar soporte al area en estudio en el cumplimiento de sus objetivos.

El Plan de Sistemas debe contener:

• Los sistemas que requiere el área del negocio, así como sus bases de datos y la información que intercambiaran o compartieran.
• Descripción detallada de cada sistema y aplicación incluyendo sus objetivos funcionales y sus bases de diseño.
• Todo hardware y software que serán utilizados para el funcionamiento requeridos por el área de negocio (incluyendo las redes)
• Métodos de desarrollo para cada sistema como lo es adquisición de paquetes, nuevo desarrollo o actualizaciones
• Esquema de los problemas actuales del area de negocio y de las posibles mejoras que se puedan realizar en cada sistema
• Análisis de los beneficios que se espera derivar de los sistemas que conforman la arquitectura
El plan de sistemas de información es uno de los factores más importantes para el departamento de informática o sistemas ya que constituye la guía para emprender los proyectos que requiera el cliente, reclutar y adiestrar al personal necesario y la adquisición e instalación de hardware y software necesarios.

Fase II - Análisis / Diseño

El objetivo de esta fase es desarrollar el diseño arquitectónico de los sistemas, utilizando los requerimientos obtenidos en la primera fase. En el diseño arquitectónico se engloban dos componentes: los datos y los procesos, los cuales serán analizados y diseñados desde una perspectiva conceptual a una física, dentro de las cuatros actividades que se encuentran en esta fase.
• Actividades dentro de la fase de Análisis/Diseño.
• Analizar y Diseñar Proceso: Las operaciones del negocio y los requerimientos de funcionamiento definidos en la primera fase, se toman en cuenta con el propósito de determinar la forma en que debe funcionar el sistema.
• Analizar y Diseñar Los Datos: Con los requerimientos de información definidos en la fase I se debe organizar los distintos modelos de datos que nos ayuden a diseñar la base de datos que hagan falta para que el sistema funcione de acuerdo al modelo de funcionamiento.
• Diseñar y Organizar Los Componentes Físicos: Todo componente físico como (pantallas, base de datos) que hagan posible el funcionamiento del sistema de acuerdo al modelo de funcionamiento.
• Planificar El Desarrollo De Los Componentes Físicos: actividad en la cual planificamos la forma en que pueden ser construidos e implementados los componentes físicos de una forma rápida y productiva.
En esta fase de análisis / diseño puede incluirse una sub.-fase de evaluación de paquetes. Esta se pudiese realizar si en los requerimientos se estableció adquirir un paquete de aplicaciones en lugar de completar un diseño arquitectónico.

Fase III – Construcción

Dentro de esta fase de construcción existen actividades separadas en cinco sub.-fases:
• DESARROLLO DE INFRAESTRUCTURA
Durante esta fase se desarrollará y organizará la infraestructura que permita cumplir las tareas de construcción en la forma más productiva posible.
• ADAPTACIÓN DE PAQUETE
Uno de los objetivos centrales de esta subfase es conocer al máximo detalle posible el funcionamiento del paquete, este asegurará que el paquete será utilizado con el máximo provecho, tanto desde el punto de vista del negocio, como de la utilización de recursos. Cada componente del paquete será revisado en forma exhaustiva por el equipo Analista – Usuario, con el fin de conocer y comprender todos los aspectos del paquete.

• DESARROLLO DE UNIDADES DE DISEÑO INTERACTIVAS
Las unidades de diseño interactivas, son procedimientos que se cumple o se ejecutan a través de un dialogo usuario – sistema.
Las actividades de esta subfase tienen como objetivo central:
• Especificar en detalle las tareas que debe cumplir la unidad de diseño
• Desarrollar componentes
• Realizar las pruebas unitarias y las pruebas de integración a nivel de la unidad de diseño.
• DESARROLLO DE UNIDADES DE DISEÑO BATCH
En esta sub.-fase se preparan especificaciones hechas utilizando una combinación de técnicas como flujo gramas, diagramas de estructuras, tablas de decisiones etc. Cualquiera que se utilice será útil para que la especificación sea clara y se logre el propósito de que el programador comprenda y pueda programar y probar los programas correspondientes.
• DESARROLLO DE UNIDADES DE DISEÑO MANUALES
Las actividades de esta subfase tienen como objetivo central desarrollar todos los procedimientos administrativos que rodearán y gobernarán la utilización de los componentes computarizados desarrollados en la fase de diseño detallado y construcción.

Fase IV – Pruebas

Esta fase, da inicio luego de que las diferentes unidades de diseño han sido desarrolladas y probadas por separado. Durante su desarrollo, el sistema se emplea de forma experimental para asegurar que el software no falle, es decir que funcione deacuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga, y de esta forma poder detectar cualquier anomalía, antes de que el sistema sea puesto en marcha y se dependa de el. Para evaluar el desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de prueba:
• Funcional: Prueba desde el punto de vista de los requerimientos funcionales.
• De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeño.
• De Integración: Prueba de interfaces.
• De Aceptación Técnica: Prueba de manejo de condiciones extremas.
Si el Sistema cumple de forma satisfactoria con estos niveles mencionados anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptación final, durante el cual, el sistema comenzará a funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptación.
Finalizado el Periodo de Aceptación, se le dará al sistema la aprobación final, para que pase a ser el sistema oficial.

Fase V - Producción / Mantenimiento

“Una vez que un sistema pasa a formar parte de la vida diaria de la empresa, cada programa, cada procedimiento y cada estructura de datos se convierte en una pieza del negocio que, como tal, deberá funcionar en forma constante, exacta y confiable. L a operación del negocio ahora dependerá del funcionamiento del sistema, por lo que las tareas de mantenimiento cobran vital importancia.
Durante la fase de mantenimiento, se ponen en práctica todas las políticas y los procedimientos destinados a garantizar la operación continúa de los de los sistemas y a asegurar su uso efectivo, con el fin, de que éstos se constituyan en una verdadera herramienta de apoyo al logro de los objetivos estratégicos de la empresa

Ingeneria de Sistemas, Definicion; Sistemas de Información

Ingeniera de Software

Definición

Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software.1 Es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería.2

Se pueden citar otras definiciones enunciadas por prestigiosos autores:
Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976).
Ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).

En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U. S. Bureau of Labor Statistics) contó 760.840 ingenieros de software de computadora.3 El término "ingeniero de software", sin embargo, se utiliza en forma genérica en el ambiente empresarial, y no todos los ingenieros de software poseen realmente títulos de ingeniería de universidades reconocidas.

Algunos autores consideran que "desarrollo de software" es un término más apropiado que "ingeniería de software" para el proceso de crear software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el término IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos "ingeniería de software" o "ingeniería del software". En Hispanoamérica el término usado normalmente es el primero de ellos.

La creación del software es un proceso intrínsecamente creativo y la ingeniería del software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo creativo por medio de diversas técnicas que se han demostrado adecuadas en base a la experiencia previa.

La IS se puede considerar como la ingeniería aplicada al software, esto es, por medios sistematizados y con herramientas preestablecidas, la aplicación de ellos de la forma más eficiente para la obtención de resultados óptimos; objetivos que siempre busca la ingeniería. No es sólo de la resolución de problemas, sino más bien teniendo en cuenta las diferentes soluciones, elegir la más apropiada.

Económicamente

En los Estados Unidos, el software contribuyó a una octava parte de todo el incremento del PIB durante la década de 1990 (alrededor de 90,000 millones de dólares por año), y un noveno de todo el crecimiento de productividad durante los últimos años de la década (alrededor de 33.000 millones de dólares estadounidenses por año). La ingeniería de software contribuyó a US$ 1 billón de crecimiento económico y productividad en esa década. Alrededor del globo, el software contribuye al crecimiento económico en formas similares, aunque es difícil de encontrar estadísticas fiables. [cita requerida]

Además, con la industria del lenguaje está hallando cada vez más campos de aplicación a escala global.

Socialmente

La ingeniería de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrónico (E-mail), la WWW y la mensajería instantánea permiten a la gente interactuar en nuevas formas. El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los proyectos exitosos donde se han usado métodos de ingeniería de software incluyen a GNU/Linux, el software del transbordador espacial, los cajeros automáticos y muchos otros.

Metodología

Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.

Etapas del proceso

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:

Análisis de requerimientos

Extraer los requisitos y requerimientos 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 requerimientos incompletos, ambiguos o contradictorios. El resultado del análisis de requerimientos 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 CMMI. 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 requerimientos (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 requerimientos, por ejemplo en dos capítulos del libro de Sommerville "Ingeniería del software" titulados "Requerimientos del software" y "Procesos de la Ingeniería de Requerimientos".

La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requerimientos de software (Software Requirements Specification).

Especificación

La especificación de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:
Caso de uso,
Historias de usuario,

Siendo los primeros más rigurosas y formales, los segundas más ágiles e informales.

Arquitectura

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto.

El arquitecto de software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas.

La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de software.

La arquitectura de software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:
Diagramas de clases
Diagramas de base de datos
Diagrama de despliegue
Diagrama de secuencia

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar.

Las herramientas para el diseño y modelado de software se denominan CASE, (Computer Aided Software Engineering) entre las cuales se encuentran:
Enterprise Architect
Microsoft Visio for Enterprise Architects

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. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

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 de casos de uso, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto4 está dedicado a su mantenimiento. Una pequeña parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte recide en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.