miércoles, 9 de mayo de 2012


ENTRADA 1
INGENIERÍA DE SISTEMAS
Definiciones
La ingeniería en sistemas computacionales es la aplicación de las ciencias matemáticas, físicas e informáticas en conjunto con la electrónica para desarrollar sistemas que utilicen económicamente materiales tecnológicos para el beneficio de la humanidad.
Una definición especialmente completa -y que data de 1974- nos la ofrece un estándar militar de las fuerzas aéreas estadounidenses sobre gestión de la ingeniería.
La ingeniería en sistemas computacionales es la aplicación de esfuerzos científicos y de ingeniería para:
  • Transformar una necesidad de operación en una descripción de parámetros de rendimiento del sistema y una configuración del sistema a través del uso de un proceso interactivo de definición, síntesis, análisis, diseño, prueba y evaluación;
  • Integrar parámetros técnicos relacionados para asegurar la compatibilidad de todos las interfaces de programa y funcionales de manera que optimice la definición y diseño del sistema total;
  • Integrar factores de fiabilidad, mantenibilidad, seguridad, supervivencia, humanos y otros en el esfuerzo de ingeniería total a fin de cumplir los objetivos de coste, planificación y rendimiento técnico.
CAMPOS RELACIONADOS
Muchos de los campos relacionados podrían ser considerados con estrechas vinculaciones a la Ingeniería en Sistemas Computacionales. Muchas de estas áreas han contribuido al desarrollo de la Ingeniería en Sistemas Computacionales como área independiente.
SISTEMAS DE INFORMACIÓN
Un sistema de información o (SI) es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. No siempre un Sistema de Información debe estar automatizado (en cuyo caso se trataría de un sistema informático), y es válido hablar de Sistemas de Información Manuales. Normalmente se desarrollan siguiendo Metodologías de Desarrollo de Sistemas de Información.
INVESTIGACIÓN DE OPERACIONES
La investigación de operaciones o (IO) se enseña a veces en los departamentos de ingeniería industrial o de matemática aplicada, pero las herramientas de la IO son enseñadas en un curso de estudio en Ingeniería de Sistemas. La IO trata de la optimización de un proceso arbitrario bajo múltiples restricciones. (Para artículos de discusión (en inglés) ver:
INGENIERÍA DE SISTEMAS COGNITIVOS
La ingeniería de sistemas cognitivos es una rama de la ingeniería de sistemas que trata los entes cognitivos, sean humanos o no, como un tipo de sistemas capaces de tratar información y de utilizar recursos cognitivos como la percepción, la memoria o el procesamiento de información. Depende de la aplicación directa de la experiencia y la investigación tanto en psicología cognitiva como en ingeniería de sistemas. La ingeniería de sistemas cognitivos se enfoca en cómo los entes cognitivos interactúan con el entorno. La ingeniería de sistemas trabaja en la intersección de:
  1. El desarrollo de la sociedad en esta nueva era
  2. Los problemas impuestos por el mundo
  3. Las necesidades de los agentes (humano, hardware, software)
  4. La interacción entre los varios sistemas y tecnologías que afectan (y/o son afectados por) la situación.
Algunas veces designados como ingeniería humana o ingeniería de factores humanos, esta rama además estudia la ergonomía en diseño de sistemas. Sin embargo, la ingeniería humana suele tratarse como otra especialidad de la ingeniería que el ingeniero de sistemas debe integrar.
Habitualmente, los avances en ingeniería de sistemas cognitivos se desarrollan en los departamentos y áreas de Informática, donde se estudian profundamente e integran la inteligencia artificial, la ingeniería del conocimiento y el desarrollo de interfaces hombre-máquina (diseños de usabilidad).
ENTRADA 2
CICLO DE VIDA DE UN SISTEMA DE INFORMACIÓN
Son los pasos a seguir desde que se comienza con la necesidad de un sistema hasta que el mismo es sustituido.

fases

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 prácticas 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 área 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 área 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 de acuerdo 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 él. 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

ENTRADA 3:
MODELOS DE CICLO DE VIDA

Modelo en cascada
 Modelo V

ENTRADA 4:
UML (LENGUAJE UNIFICADO DE MODELADO UML)

Definición
Historia e Inicios
Características
Objetivos Principales

El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementa la capacidad de lo q
se puede hacer con otros métodos de análisis y diseño orientados a objetos. Los
autores de UML apuntaron también al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.
El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.
Los principales beneficios de UML son:
  • Mejores tiempos totales de desarrollo (de 50 % o más).
  • Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
  • Establecer conceptos y artefactos ejecutables.
  • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
  • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
  • Mejor soporte a la planeación y al control de proyectos.
  • Alta reutilización y minimización de costos.

ENTRADA 5:
TIPOS DE DIAGRAMAS UML
4         Diagrama de clases.
Forma parte de la vista estática del sistema. En el diagrama de clases como ya hemos comentado será donde definiremos las características de cada una de las clases, interfaces, colaboraciones y relaciones de dependencia y generalización. Es decir, es donde daremos rienda suelta a nuestros conocimientos de diseño orientado a objetos, definiendo las clases e implementando las ya típicas relaciones de herencia y agregación.
En el diagrama de clases debemos definir a estas y a sus relaciones.
4.1        La Clase.
Una clase esta representada por un rectángulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los métodos.
Cada clase debe tener un nombre único, que las diferencie de las otras.
Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto.
Un método o operación es la implementación de un servicio de la clase, que muestra un comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de la clase que hagan algo.
Para separar las grandes listas de atributos y de métodos se pueden utilizar estereotipos.

http://usuarios.multimania.es/oopere/uml_files/image008.gif

Aquí vemos un ejemplo. La clase usuario contiene tres atributos. Nombre que es public, dirección que es protected y situación que es private. Situación empieza con el valor 3. También dispone de tres métodos Entrar, Salir y Trabajar.
4.2        Relaciones entre clases.

Existen tres relaciones diferentes entre clases, Dependencias, Generalización y Asociación. En las relaciones se habla de una clase destino y de una clase origen. La origen es desde la que se realiza la acción de relacionar. Es decir desde la que parte la flecha, la destino es la que recibe la flecha. Las relaciones se pueden modificar con estereotipos o con restricciones.
4.2.1       Dependencias.
Es una relación de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua va desde la clase utilizadora a la clase utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede afectar al funcionamiento de la clase utilizadora, pero no al contrario. Aunque las dependencias se pueden crear tal cual, es decir sin ningún estereotipo (palabreja que aparece al lado de la línea que representa la dependencia) UML permite dar mas significado a las dependencias, es decir concretar mas, mediante el uso de estereotipos.
q       Estereotipos de relación Clase-objeto.
q       Bind: La clase utilizada es una plantilla, y necesita de parámetros para ser utilizada, con Bind se indica que la clase se instancia con los parámetros pasándole datos reales para sus parámetros.
q       Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento.
q       Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir podrá ver las interioridades de la clase destino.
q       InstanceOF: Indica que el objeto origen es una instancia del destino.
q       Instantiate: indica que el origen crea instancias del destino.
q       Powertype: indica que el destino es un contenedor de objetos del origen, o de sus hijos.
q       Refine: se utiliza para indicar que una clase es la misma que otra, pero mas refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
4.2.2       Generalización.
Pues es la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. UML soporta tanto herencia simple como herencia múltiple. Aunque la representación común es suficiente en el 99.73% de los casos UML nos permite modificar la relación de Generalización con un estereotipo y dos restricciones.
q       Estereotipo de generalización.
q       Implementation: El hijo hereda la implementación del padre, sin publicar ni soportar sus interfaces.
q       Restricciones de generalización.
q       Complete: La generalización ya no permite mas hijos.
q       Incomplete: Podemos incorporar mas hijos a la generalización.
q       Disjoint: solo puede tener un tipo en tiempo de ejecución, una instancia del padre solo podrá ser de un tipo de hijo.
q       Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.
4.2.3       Asociación.
Especifica que los objetos de una clase están relacionados con los elementos de otra clase. Se representa mediante una línea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregación.
4.3       
http://usuarios.multimania.es/oopere/uml_files/image010.gif

Ejemplo.




En este diagrama se han creado cuatro clases. La clase principal es Usuario, que tiene dos clases hijas UsuarioADM y UsuarioINF. El usuario mantiene una relación de asociación con la clase Clave, se indica que es propietario de una clave, o de un número indeterminado de ellas. Se le crea también una relación de dependencia con la clase Perfil, es decir las instancias de usuario contendrán como miembro una instancia de Perfil.
5         Diagrama de objetos.
Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de las clases del diagrama de clases. Muestra a los objetos y sus relaciones, pero en un momento concreto del sistema. Estos diagramas contienen objetos y enlaces. En los diagramas de objetos también se pueden incorporar clases, para mostrar la clase de la que es un objeto representado.
En este diagrama se muestra un estado del diagrama de eventos. Para realizar el diagrama de objetos primero se debe decidir que situación queremos representar del sistema. Es decir si disponemos de un sistema de mensajería, deberemos decidir que representaremos el sistema con dos mensajes entrantes, los dos para diferentes departamentos, dejando un departamento inactivo. Para el siguiente diagrama de clases:
http://usuarios.multimania.es/oopere/uml_files/image012.gif
 

Tendríamos un diagrama de objetos con dos instancias de Mensaje, mas concretamente con una instancia de MensajeDIR y otra de MensajeADM, con todos sus atributos valorados. También tendríamos una instancia de cada una de las otras clases que deban tener instancia. Como CanalEnt, INS, Distr, y el Buzon correspondiente a la instancia de mensaje que se este instanciando. En la instancia de la clase INS se deberá mostrar en su miembro Estado, que esta ocupado realizando una inserción.
En un diseño no podemos encontrar con multitud de diagramas de objetos, cada uno de ellos representando diferentes estados del sistema.
6         Diagrama de componentes.
Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
En el situaremos librerías, tablas archivos, ejecutables y documentos que formen parte del sistema.
Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.
http://usuarios.multimania.es/oopere/uml_files/image014.gif

Aquí tenemos un componente del sistema de Windows. En el diagrama de componentes de Windows debe salir este componente, ya que sin el  sistema no funcionaría.
http://usuarios.multimania.es/oopere/uml_files/image016.gif
En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representación anterior es incorrecta, pero no es así solo corresponde a un nivel diferente de detalle.
Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, los standard que define UML son:
  • Executable
  • Library
  • Table
  • File
  • Document.

Aunque por suerte no estamos limitados a estas especificaciones. Que pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existe ya unos definidos WAE (Web Applications Extensión).

Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas.

  • Ejecutables y bibliotecas.
  • Tablas.
  • API
  • Código fuente.
  • Hojas HTML.
6.1        Ejecutables.
Nos facilita la distribución de ejecutables a los clientes. Documenta sus necesidades y dependencias. Si disponemos de un ejecutable que solo se necesita a el mismo para funcionar no necesitaremos el diagrama de componentes.
Los pasos a seguir para modelar, a priori no a posteriori, son:
  • Identificar los componentes, las particiones del sistema, cuales son factibles de ser reutilizadas.  Agruparlos por nodos y realizar un diagrama por cada nodo que se quiera modelar.
  • Identificar cada componente con su estereotipo correspondiente.
  • Considerar las relaciones entre componentes.

http://usuarios.multimania.es/oopere/uml_files/image018.gif

En este grafico se muestra un ejecutable que utiliza dos librerías, estas dos librerías disponen de su interface con el que ofrecen el acceso a sus servicios. Se puede ver que estas librerías son componentes que pueden ser reutilizados en otras partes del sistema.
HGGF HJ HJ


6.2        Codigo fuente.
Se utiliza para documentar las dependencias de los diferentes ficheros de código fuente. Un ejecutable, o librería es una combinación de estos ficheros, y al mostrar la dependencia entre ellos obtenemos una visión de las partes necesarias para la creación del ejecutable o librería.
Al tener documentadas las relaciones se pueden realizar cambios en el código de un archivo teniendo en cuenta donde se utiliza, y que otros ficheros pueden verse afectados por su modificación.

http://usuarios.multimania.es/oopere/uml_files/image020.gif

Aquí tenemos la relación entre los diferentes ficheros de un sistema. Cada fichero Cpp utiliza su fichero .h correspondiente, y MiServicio.h utiliza NTService.h u Stdio.h.

7         Diagramas de despliegue.
En el diagrama de despliegue se indica la situación física de los componentes lógicos desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada Hardware se representa como un nodo.
http://usuarios.multimania.es/oopere/uml_files/image022.gif

Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los componentes, representan el despliegue físico de estos componentes.


Aquí tenemos dos nodos, el cliente y el servidor, cada uno de ellos contiene componentes. El componente del cliente utiliza un interface de uno de los componentes del servidor. Se muestra la relación existente entre los dos Nodos. Esta relación podríamos asociarle un estereotipo para indicar que tipo de conexión disponemos entre el cliente y el servidor, así como modificar su cardinalidad, para indicar que soportamos diversos clientes.

Como los componentes pueden residir en mas de un nodo podemos situar el componente de forma independiente, sin que pertenezca a ningún nodo, y relacionarlo con los nodos en los que se sitúa.

http://usuarios.multimania.es/oopere/uml_files/image024.gif





8         Diagrama Secuencia.
El diagrama de secuencia forma parte del modelado dinámico del sistema. Se modelan las llamadas entre clases desde un punto concreto del sistema. Es útil para observar la vida de los objetos en sistema, identificar llamadas a realizar o posibles errores del modelado estático, que imposibiliten el flujo de información o de llamadas entre los componentes del sistema.

En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un punto de partida. El diagrama se forma con los objetos que forman parte de la secuencia, estos se sitúan en la parte superior de la pantalla, normalmente en la izquierda se sitúa al que inicia la acción. De estos objetos sale una línea que indica su vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando el esta activo.

http://usuarios.multimania.es/oopere/uml_files/image026.jpg
 

En esta pantalla tenemos tres objetos, y un actor, situado a la izquierda que es el que inicia la acción. Como podemos ver el objeto de mas a la derecha aparece mas abajo que los otros existentes. Esto se debe a que recibe una llamada de creación. Es decir el objeto no existe en el sistema hasta que recibe la primera petición.








 Los Casos de Uso


Los Casos de uso son una herramienta para la captura de los requerimientos, la planificación y para el control de proyectos, siendo la tarea principal en la fase elaboración.
Jacobson  fue el que convirtió el caso de uso como el principal elemento para la planificación y desarrollo de proyectos, ya que este  permite captar la función visible para el usuario, la información se obtiene directamente de los usuarios que utilizan el sistema y con esto tener una visión  más  clara de todo el proceso. Asimismo Jacobson

Diagramas de Clase


Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema y a su vez describe los tipos de objetos que lo componen, asimismo muestra los atributos y operaciones de la clase y sus restricciones. Hay dos tipos principales de relaciones estáticas como son: asociaciones y subtipos.

Diagramas de interacción


Este diagrama se utiliza para describir la manera en que un grupo de objetos colaborar para cierto comportamiento y asimismo mensajes  que muestra que se va a realizar entre estos objetos.  Este diagrama se utiliza cuando se quiere observar el comportamiento de varios objetos en un caso de uso. Asimismo se puede mostrar la colaboración entre los objetos en el sistema.
El diagrama de interacción se divide en dos tipos: Diagrama de secuencia y diagrama de colaboración. Explicado cada uno a continuación.

Diagramas de estados


En este diagrama describe  los diferentes estados por los que puede pasar un objeto, modificado su comportamiento por los distintos eventos que suceden dentro de un sistema. OMT fue quien por primera vez que fue utilizo este método orientado a objeto, OMT significa (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991 y luego fue adoptado por Grady Booch en 1994.

Diagrama de Actividades


Este tipo de diagrama  son muy funcionales  ya que se puede describir el flujo de trabajo y procesos que ocurren en un sistema. Su símbolo clave es la actividad, donde esta actividad es la tarea que se debe cumplir dentro del proceso.






ENTRADA 5:
 DIAGRAMAS DE CASOS DE USO

Definición de Actores
 Definición de Casos de uso
Asociaciones de casos de usos
 Ejemplos
Casos de Uso (Use Case)

Introducción
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Elementos
  • Actor:
http://www.dcc.uchile.cl/~psalinas/uml/img/usecase/actor1.jpg
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
  • Caso de Uso:
http://www.dcc.uchile.cl/~psalinas/uml/img/usecase/caso1.jpg
Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
  • Relaciones:
    • Asociación http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/asociacion1.jpg
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.
    • Dependencia o Instanciación http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/dependencia1.jpg
Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
    • Generalización http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/herencia1.jpg
Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.
Ejemplo:
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
  • Registrar el número de ítemes ingresados.
  • Imprimir un recibo cuando el usuario lo solicita:
a.     Describe lo depositado
b.     El valor de cada item
c.      Total
  • El usuario/cliente presiona el botón de comienzo
  • Existe un operador que desea saber lo siguiente:
a.     Cuantos ítemes han sido retornados en el día.
b.     Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
  • El operador debe además poder cambiar:
a.     Información asociada a ítemes.
b.     Dar una alarma en el caso de que:
                                                        i.            Item se atora.
                                                      ii.            No hay más papel.
Como una primera aproximación identificamos a los actores que interactuan con el sistema:
http://www.dcc.uchile.cl/~psalinas/uml/img/usecase/ejemplo1.jpg
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:
http://www.dcc.uchile.cl/~psalinas/uml/img/usecase/ejemplo2.jpg
Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
http://www.dcc.uchile.cl/~psalinas/uml/img/usecase/ejemplo3.jpg
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.
http://www.dcc.uchile.cl/~psalinas/uml/img/usecase/ejemplo4.jpg
Entonces, el diseño completo del diagrama Use Case es:




 
ENTRADA 6:
TALLER DE SISTEMAS
 TÉCNICAS DE RECOLECCIÓN DE DATOS 
Definición·
 Técnicas·
 Entrevistas·
 Cuestionario·
 Encuestas·
 Observación·
 Diccionario de datos.·
 Otros ·
    DEFINICIÓN

RECOLECTAR LOS DATOS
·          Definir la forma idónea de recolectar los datos de acuerdo al contexto de la investigación.
·          Elaborar el instrumento de medición.
·          Aplicar el instrumento de medición.
·          Obtener los datos.
·          Codificar los datos.
·          Archivar los datos y prepararlos para el análisis.
 
OBJETIVOS
 Que el alumno:

1)         Comprenda el significado de “medir” en ciencias sociales.
2)         Comprenda los requisitos que toda medición debe cumplir: confiabilidad y validez.
3)         Conozca los métodos para determinar la confiabilidad y validez de un instrumen­to de                   medición.
4)         Comprenda los niveles de medición en que pueden ubicarse las variables.
5)         Conozca los principales instrumentos de medición disponibles en ciencias sociales.
6)         Esté capacitado para elaborar y aplicar diferentes instrumentos de medición.
7)         Se encuentre habilitado en la preparación de datos para su análisis.

SÍNTESIS
La sección presenta una definición de medición en el contexto de las ciencias sociales, así como los requisitos que todo instrumento de medición debe reunir: confiabilidad y validez. Diversos métodos para determinar la confiabilidad y validez son revisados.

Además se analiza y ejemplifica las principales maneras de medir en ciencias sociales: escalas de actitudes, cuestionarios, análisis de contenido, observación, pruebas estandarizadas, sesiones en profundidad y utilización de archivos.

Finalmente en el capítulo se presenta el procedimiento de codificación de los datos obtenidos y la forma de prepararlos para el análisis.

¿QUÉ IMPLICA LA ETAPA DE RECOLECCIÓN DE LOS DATOS?
Una vez que seleccionamos el diseño de investigación apropiado y la muestra adecuada de acuerdo con nuestro problema de estudio e hipótesis, la siguiente etapa consiste en recolectar los datos pertinentes sobre las variables involucradas en la investigación.

Recolectar los datos implica tres actividades estrechamente vinculadas entre sí:

a)         Seleccionar un instrumento de medición de los disponibles en el estudio del comportamiento o desarrollar uno (el instrumento de recolección de los datos). Este instrumento debe ser válido y confiable, -de lo contrario no podemos basamos en sus resultados.
b)         Aplicar ese instrumento de medición. Es decir, obtener las observaciones y mediciones de las variables que son de interés para nuestro estudio (medir variables).
c)         Preparar las mediciones obtenidas para que puedan analizarse correctamente (a esta actividad se le denomina codificación de los datos).

TÉCNICAS
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 trabajo de cada una y ayudar a asegurar una investigación completa.

ENTREVISTAS
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).


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 departamentos, 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 rehechas o estereotipadas). También las preguntas estandarizadas pueden proporcionar datos más confiables.
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.

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.

OBSERVACIÓN
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 suinteracció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.


DICCIONARIO DE DATOS

Los diccionarios de datos son el segundo componente del análisis del flujo de datos. En sí mismos los diagramas de flujo de datos no describen por completo el objeto de la investigación. El diccionario de datos proporciona información adicional sobre el sistema. Esta sección analiza que es un diccionario, por qué se necesita en el análisis de flujo de datos y como desarrollarlo. Se utilizará el ejemplo del sistema de contabilidad para describir los diccionarios de datos.
Un diccionario de datos es una lista de todos los elementos incluido en el conjunto de los diagramas de flujo de datos que describen un sistema. Los elementos principales en un sistema, estudiados en las secciones anteriores, son el flujo de datos, el almacenamiento de datos y los procesos. El diccionario de datos almacena detalles y descripciones de estos elementos.
Si los analistas desean conocer cuántos caracteres hay en un dato, con qué otros nombres se le conoce en el sistema, o en donde se utilizan dentro del sistema deben ser capaces de encontrar las respuesta en un diccionario de datos desarrollado apropiadamente.
El diccionario de dato se desarrolla durante el análisis de flujo de datos y ayuda el analista involucrado en la determinación de los requerimientos de sistemas. Sin embargo, como se verá más adelante, también el contenido del diccionario de datos se utiliza durante el diseño del sistema.
En informática, base de datos acerca de la terminología que se utilizará en un sistema de información. Para comprender mejor el significado de un diccionario de datos, puede considerarse su contenido como "datos acerca de los datos"; es decir, descripciones de todos los demás objetos (archivos, programas, informes, sinónimos...) existentes en el sistema. Un diccionario de datos almacena la totalidad de los diversos esquemas y especificaciones de archivos, así como sus ubicaciones. Si es completo incluye también información acerca de qué programas utilizan qué datos, y qué usuarios están interesados en unos u otros informes. Por lo general, el diccionario de datos está integrado en el sistema de información que describe.
Descripción de los Datos en el Diccionario
Cada entrada en el diccionario de dato consiste en un conjunto de detalles que describen los datos utilizados o producidos en el sistema. Cada articulo se identifica por un nombre de dato, descripción, sinónimo y longitud de campo y tiene valores específicos que se permiten para éste en el sistema estudiado.
Nombre de los Datos
Para distinguir un dato de otro, los analista les asigna nombre significativos que se utilizan para tener una referencia de cada elemento a través del proceso total de desarrollo de sistemas. Por lo tanto, debe tenerse cuidado para seleccionar, en forma significativa y entendible, los nombres de los datos, por ejemplo la fecha de factura es más significativa si se llama FECHA FACTURA que si se le conoce como ABCXXX.
Descripción de los Datos
Establece brevemente lo que representa el dato en el sistema; por ejemplo, la descripción para FECHA-DE-FACTURA indica que es la fecha en la cual se está preparando la misma (para distinguirla de la fecha en la que se envió por correo o se recibió.
Las descripciones de datos se deben escribir suponiendo que a gente que los lea no conoce nada en relación del sistema. Deben evitarse termino especiales o argot, todas las palabras deben se entendible para el lector
Alias
Con frecuencia el mismo dato puede conocerse con diferentes nombres, dependiendo de quien lo utilice. El uso de los alias deben evitar confusión. Un diccionario de dato significativo incluirá todos los alias.
Longitud de campo
Cuando las característica del diseño del sistema se ejecuten más tarde en el proceso de desarrollo del sistemas, será importante conocer la cantidad de espacio que necesita para cada dato.
Valores de los datos
En algunos proceso solo se permiten valores de datos específicos. Por ejemplo, en muchas compañías con frecuencia los números de orden de compra se proporcionan con un prefijo de una letra para indicar el departamento del origen.
Registro de las descripciones de datos
Dadas que las descripciones se utilizarán en forma repetitiva a través de una información y después, durante el diseño, se sugiere un formato fácil para utilizar que simplifique el registro y los detalles de consulta cuando se necesiten.
ENTRADA 7:
Requerimientos

§ Determinación de requerimientos
§ Uso de los diagramas de caso de usos
§ Explicación de herramienta para análisis y diseño (STARUML)
§ Taller de Sistemas 

DETERMINACIÓN DE REQUERIMIENTOS
http://1.bp.blogspot.com/-FXNYMWFkV1s/T6W0sgjgxhI/AAAAAAAAATs/z__AKVhvZgY/s320/DTE.gif


La determinación de requerimientos es el conjunto de actividades encaminadas a obtener las características necesarias que deberá poseer el nuevo sistema, es el estudio de un sistema, actividad o proceso, para comprender cómo trabaja y dónde es necesario efectuar mejoras o cambios considerables.
Este es el primer paso en el análisis de sistemas y se puede decir que es el más importante.

USO DE LOS DIAGRAMAS DE CASO DE USOS

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto
de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del
sistema, es decir, representan las funciones que un sistema puede ejecutar.
Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente
útiles en la comunicación con el cliente.

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso.
 Los personajes o entidades que participarán en un caso de uso se denominan actores.En el contexto deingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.



EXPLICACIÓN DE HERRAMIENTAS PARA ANÁLISIS DISEÑO (STARUML)

Objetivo
Conocer una herramienta de modelado para la solución de problemas utilizando
programación orientada a objetos. 
• Conocer los diferentes tipos de diagramas para análisis y diseño básicos en UML 
• Utilizar una de las herramientas para elaborar diagramas UML
Introducción
¿Qué es UML? El Lenguaje de Modelado Unificado (UML - Unified Modeling Lenguaje)
Es un lenguaje gráfico de propósito general, estándar de la industria para visualizar,
especificar y documentar cada una de las partes que comprende el Desarrollo de
Sistemas a través del uso de diagramas y texto de soporte.
¿Para qué sirve?
• Visualizar como es un sistema o como queremos que sea.
• Especificar la estructura y/o comportamiento de un sistema.
• Hacer una plantilla que guíe la construcción de los sistemas
• Documentar las decisiones que hemos tomado
Para esta práctica usaremos los diagramas de casos de uso, diagramas de secuencia, y
los diagramas de clase.
Los diagramas de casos de uso y de secuencia, nos servirán para realizar el análisis
necesario para poder hacer un diseño basado en diagramas de clase.

Procedimiento

Iniciando StarUML.
Selecciona el icono de lanzamiento de la aplicación. Dado que un proyecto se puede
Realizar siguiendo distintos enfoques, StarUML nos  pregunta cuál queremos utilizar. En
esta práctica utilizaremos el “Default Approach”.
ENTRADA 8:
PROCESOS DE NEGOCIOS
§ Definición de proceso de negocios
§ Reglas de negocio 
DEFINICIÓN DE PROCESOS DE NEGOCIOS

http://2.bp.blogspot.com/-qJ8-Mq9QmRU/T6W6rw2CwhI/AAAAAAAAAT4/3rqbRkvWe38/s1600/MEMME.jpg
Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas resultantes.

Es una colección de actividades estructurales relacionadas que producen un valor para la organización, sus inversores o sus clientes. Es, por ejemplo, el proceso a través del que una organización ofrece sus servicios a sus clientes.
Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de trabajo que efectúan las tareas de una organización. Los procesos poseen las siguientes características:

1.    Pueden ser medidos y están orientados al rendimiento
2.    Tienen resultados específicos
3.    Entregan resultados a clientes o stakeholders
http://1.bp.blogspot.com/-EZ09Gh1v9kU/T6W63TzyUMI/AAAAAAAAAUA/2mNVp2APevU/s320/MAMA.png4.    Responden a alguna acción o evento específico
5.    Las actividades deben agregar valor a las entradas del proceso.


Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Las dos formas principales de visualizar una organización, son la vista funcional y la vista de procesos.


REGLAS DE NEGOCIO
Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las políticas, normas, operaciones, definiciones y restricciones presentes en una organización y que son de vital importancia para alcanzar los objetivos misionales.
Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000".
Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos.
En los últimos años se viene observando una tendencia a gestionar de forma sistemática y centralizada las reglas de negocio, de modo que sea fácil y sencillo consultarlas, entenderlas, utilizarlas, cambiarlas, etc. Para ello se puede utilizar un motor de reglas de negocio. El motor de reglas de negocio es un sistema que se configura para dar servicio a las necesidades de negocio a través de la definición de objetos y reglas de negocio, el software se rige por flujos que derivan responsabilidades a los distintos cargos de la empresa repartiendo así el trabajo equitativamente y cuantitativamente, cuando, quien y donde tiene que desempeñar la tarea asignada.

Las reglas de negocio son un medio por el cual la estrategia es implementada. Las reglas especifican - en un nivel adecuado de detalle - lo que una organización debe hacer.


ENTRADA 9:
 TALLER DE SISTEMAS DE CASO DE USOS DE EMPRESA
§ Requerimientos
§ Actores
§ Casos de uso
§ Dependencias 


EJERCICIO Nª 3
ONG CONCORDIA
La ONG Concordia nos ha encargado el desarrollo de una aplicación Web para la gestión de su hospital en el poblado de Rukara en Rwanda.
En el hospital trabajan médicos, enfermeros y personal de administración.
La Aplicación ofrecerá algunas funcionalidades comunes y otras específicas dependiendo del usuario.
El personal de administración deberá poder hacer el mantenimiento de la base de datos de pacientes (alta, baja, modificación y consulta). Para dar de alta un paciente será necesario recoger sus datos personales, dirección donde vive y asignarle un médico y un turno de visita (mañana o tarde).
Además, cuando el paciente lo solicite, deberán darle cita (especificando día y hora) para la visita a su médico. También, dado un médico, una fecha y un turno (mañana o tarde) tienen que poder consultar el listado de pacientes con cita ordenado por hora, y se les tiene que dar la posibilidad de imprimir este listado.
Los médicos tienen que poder dar de alta un historial. Una vez creado deben de poder modificarlo y consultarlo, pero nunca borrarlo. Un historial contiene los datos personales del paciente y toda esa información que el médico ha ido apuntando encada una de las visitas (análisis, revisiones, medicamentos tomados, alergias sufridas, enfermedades padecidas). Tienen que poder expedir recetas. Una receta refleja los datos del paciente y los medicamentos especificados por el médico. Obligatoriamente, para terminar con esta funcionalidad, el médico tiene que imprimirla. Los enfermeros deben de poder consultar los datos y el historial de un paciente, pero nunca modificarlos ni borrarlos. Son los que mantienen la base de datos de medicamentos de la farmacia propia del hospital.
Por cada tipo de medicamento, se tiene cierta información (componentes, ¿cómo tomar?, efectos secundarios, precauciones, y número de unidades existentes en el almacén). Cuando les llega una remesa de este tipo de medicamento o realizan alguna venta deben actualizar su número de unidades. El sistema les tiene que permitir realizar un inventario de todos los medicamentos que tienen en la farmacia. De forma opcional, tienen que poder imprimirlo.





DESARROLLO



REQUERIMIENTOS


ACTORES
http://3.bp.blogspot.com/-2csHxBUg32Y/T6W9JmmdA2I/AAAAAAAAAUI/PrHiOvEcARI/s1600/actor.jpgRECEPCIONISTAhttp://3.bp.blogspot.com/-2csHxBUg32Y/T6W9JmmdA2I/AAAAAAAAAUI/PrHiOvEcARI/s1600/actor.jpgADMINISTRADOR


CASOS DE USO


DEPENDENCIAS


  DEPENDENCIAS/RELACIONES DE CASOS DE USOS 


 Inclusiones·
 Extensiones·
§ Taller de Sistemas (Especificaciones de casos de uso) 


INCLUSIONES 


Modelo de Casos de Uso - Relación Include


Esta es la tercera entrega de la serie modelo de casos de uso. Una vez más buscamos una unificación de conceptos que rodean a los casos de uso, en este caso queremos adentrar un poco en el concepto de relaciones de casos de uso, específicamente en este artículo trataremos la relación de inclusión (Include).
Una relación de inclusión es aquella que conecta un caso de uso base a un caso de uso de inclusión. El caso de uso de inclusión siempre es abstracto. Describe un segmento del comportamiento que se inserta en una instancia de caso de uso que ejecuta el caso de uso base. El caso de uso base tiene control de la relación para la inclusión y puede depender del resultado de que se lleve a cabo la inclusión, pero ni la base ni la inclusión pueden acceder a los atributos entre sí. En este sentido, la inclusión está encapsulada y representa el comportamiento que se puede reutilizar en casos de uso base diferentes.
EXTENSIONES


En muchas ocasiones el uso de características avanzadas de los casos de uso generan dudas en los equipos de desarrollo. La razón básica es que estos modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el uso de las relaciones de inclusión y extensión, entre otras características.
Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad y sencillez, existen situaciones en que hacer uso de una relación avanzada entre casos de uso mejora en lugar de reducir, la claridad del modelo de requisitos. De ahí por tanto que todo analista de requisitos debe comprender perfectamente el significado de estas relaciones. En el presente post abordamos la relación de extensión <<extend>>.






No hay comentarios:

Publicar un comentario en la entrada