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:
- El
desarrollo de la sociedad en esta nueva era
- Los
problemas impuestos por el mundo
- Las
necesidades de los agentes (humano, hardware, software)
- 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
|
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:
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:
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
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
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
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:
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 instrumento
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.
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).
4. Elegir un lugar donde se puede conducir la entrevista con la
mayor comodidad (Sicología).
Conducción de la Entrevista
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).
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
2. Entregar una copia al entrevistado, solicitando su conformación,
correcciones o adiciones. (Profesionalismo).
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
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
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”
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
RECEPCIONISTAADMINISTRADOR
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>>.