RESUMEN DE ANÁLISIS DE SISTEMAS – 2do PARCIAL

PREGUNTAS DE REPASO – SEGUNDO PARCIAL

UNIDAD 3: Fases del Análisis de Sistemas

1. El análisis de sistemas es la fase más importante de un proyecto porque se centra en los problemas y
requerimientos de negocio que luego serán tomados en cuenta a la hora de diseñar un sistema para solucionar estos
problemas presentados y satisfacer los requisitos necesarios.

2. Fases FAST que forman parte del análisis de sistemas:

Definición de alcance:
 Evaluar si vale la pena solucionar el problema que origina el posible inicio de un proyecto de desarrollo de un
sistema de información.
 Evaluar cada problema, mejora o directriz que dispara el proyecto.
 Identificación de cualquier restricción o limitación que afecte el proyecto.
 Definición de una línea base para el proyecto: Información, Procesos, Interfaz.
 Definición del Presupuesto y el Programa para todos los participantes del proceso.

Análisis del problema:

Su objetivo es entender el dominio del problema a fin de poder analizar las causas que lo producen; esta etapa
incluye:
 Entender el dominio del problema, conocer el vocabulario del negocio.
 Analizar los problemas y necesidades, análisis de causas y efectos.
 Analizar los procesos de negocios tal como son.
 Establecer los objetivos de mejora, con los cuales se pueda medir la efectividad del proyecto una vez
acabado.
 Refinar el plan de proyecto.

Análisis de requerimientos:
 Se definen los requerimientos de negocios que satisfagan los objetivos de mejora del sistema identificados en
la fase anterior (análisis de sistemas). En ella se debe descubrir lo que necesitan, quieren y esperan los
usuarios del nuevo sistema.

- Identificar y expresar los requerimientos del sistema:

Funcionales y no Funcionales.

- Priorizar los requerimientos de sistema:

Obligatorios o Deseables

- Actualizar o refinar el plan de proyecto:

Modificación del Alcance inicial.

- Comunicar la definición de requerimientos:

Tarea continua a usuarios y Patrocinadores.

UNIDAD 4: Máquinas de estados

1. Una máquina de estados es un grafo donde los nodos constituyen estados y los arcos las transiciones, etiquetadas
con eventos ante los cuales puede reaccionar un objeto.

2. El objetivo de una máquina de estados es mostrar la historia del ciclo de vida de un objeto como una máquina de
estados finita. (existe en un numero finito de estados).
La máquina realiza transiciones entre los diferentes estados en respuesta a eventos de una
forma bien definida.
3. Elementos de una máquina de estados:
- Estado:
Es una condición o situación durante la vida de un objeto en la cual el satisface
alguna condición, está realizando alguna actividad, o está esperando algún evento.

- Evento:
Es la especificación de una ocurrencia que tiene ubicación en el tiempo y espacio.

- Transición:
Es el movimiento de un estado a otro en respuesta a un evento.

UNIDAD 5: Modelo de Dominio

1. El modelo conceptual es la organización del conocimiento del dominio del problema en un conjunto de
abstracciones ordenadas de forma que se obtiene un conocimiento más profundo del problema.
Su objetivo es identificar y explicar los conceptos significativos en un dominio del problema, identificando sus
componentes fundamentales.

2. Una clase conceptual es la representación de componentes contenedores o clasificadores de objetos reconocidos

del dominio del problema que se caracterizan por tener propiedades similares, para diferenciarlos de otros objetos.
(ATRIBUTOS).
Se identifican a partir de un mecanismo de abstracción de propiedades esenciales por sobre los objetos específicos
particulares.

3. Una asociación es una relación entre dos conceptos (clases) que indica alguna vinculación significativa entre ellos.
Toda asociación se representa mediante un conjunto de instancias, que representan a aquellos pares ordenados de
instancias de las clases conceptuales que relaciona.
Los tipos de asociaciones son:
- Roles: Dada una asociación entre dos clases, decimos que cada clase conceptual
representa un rol en dicha asociación respecto a la otra clase.

- Composición: Esta asociación expresa que toda instancia de la clase compuesta, se

compone de varias instancias de la clase componente.

- Agregación: Es similar a la composición, la diferencia de este tipo de asociación con

la composición es que las instancias de la clase agregada no son responsables de la
existencia de sus instancias constituyentes.

- Clase de asociación: Se utiliza cuando es necesario añadir atributos a la asociación.

- Herencia: Se utilizan para establecer subclasificaciones de una clase. Es la relación “es un” / “incluido en”. Toda clase
conceptual hereda las propiedades de las clases conceptuales que las incluyen.

4. Multiplicidad entre dos clases:

Dadas las clases conceptuales A y B:
 cuántas instancias de la clase B pueden asociarse a cada instancia de la clase A a través de esa asociación.
 Y para cada instancia de la clase B, con cuántas instancias de la clase A se relaciona a través de la misma
asociación.

- 1: Exactamente uno
- n: Exactamente n
- 0..1: Cero o uno
- 0..*: Cero o más
- 1..*: Uno o más (al menos uno)
- n..*: n o más (al menos n)
- n..m: De n a m (por ejemplo: 3..6)
5. Los atributos representan propiedades que dan información sobre la naturaleza de las
clases. También representan la lista de valores posibles de un atributo que se puede
asignar a las instancias de la clase.

UNIDAD 6: Patrones

1. Patrón en Ingeniería de Software: Un patrón es una idea que ha sido útil en un determinado contexto y
probablemente lo sea en otros. Se documenta con el fin de ser reutilizado en otros contextos y como un medio de
transmitir conocimientos.

2. Patrones de Análisis: Representan estructuras conceptuales de procesos de negocios (no

son implementaciones de software).
Son un conjunto de clases y relaciones entre ellas, que tienen algún sentido en el contexto de una aplicación.
Representan una estructura que puede ser válida para otras aplicaciones.

3. Patrones de Colaboración: Consisten en la colaboración entre dos objetos de alguno de los siguientes tipos de
objetos: Personas – Lugares – Cosas – Eventos.

4. Tipos de Patrones de Análisis:

- Actor – Rol: Permite modelar personas que interactúan en contextos múltiples.

- Lugar Exterior – Lugar: Permite modelar lugares donde ocurren las interacciones
entre las personas y las cosas

- Ítem – Ítem específico: El ítem describe la información que es común en todas sus
variantes, y el ítem específico describe la información que hace que cada variación
sea distinta.

- Ensamble – Parte: Permite modelar estructuras complejas. Modela una cosa

compuesta por otras cosas.

- Contenedor – Contenido: Se utiliza cuando una cosa es receptáculo o

almacenamiento de otras cosas.

- Grupo – Miembro: Se utiliza para modelar clasificaciones o colecciones de cosas.

También puede ser usado para personas y lugares.

- Transacción – Rol: La transacción es un evento que describe cómo interactúan las

personas con las cosas.

- Transacción – Lugar: Se utiliza para modelar en qué lugar ocurren las cosas.

- Transacción – Ítem Específico: Modela la participación de una cosa en una

transacción o evento.

- Ítem Específico – Línea de Ítem: Describe la interacción de una cosa en un evento

que involucra a varias cosas. Un ítem especifico involucra 0 o más líneas de ítems.

- Transacción Compuesta – Ítem Específico: Se utiliza este patrón para describir la

interacción de la gente con múltiples cosas.

- Transacción – Seguimiento de Transacción: Se utiliza para modelar una transacción

que interactúa con otras transacciones.

UNIDAD 7: Reglas de Negocio

1. Reglas de Negocio: Es una declaración que rige el funcionamiento de algún aspecto del negocio:
- Política a cumplirse
- Condición a satisfacer.
- Restricción a cumplir o evitar.

Se clasifican en:

- Reglas de restricción:
- Reglas de Operación:
- Reglas de Flujo
- Reglas de estímulo y respuesta

- Reglas de estructura:
- Reglas del dominio o modelos de datos
- Reglas de relación.

- Reglas de Derivación
- Reglas de inferencia
- Reglas de cálculo

2. Características de la especificación correcta de una regla de negocio: Una regla de negocio debe ser:

- Atómica: no puede contener otra regla.

- Única: No puede ser redundante.

- Consistente: No puede contradecir a otra.

- Clara: No puede ser ambigua.

- Relevante: Desde el punto de vista del manejo de la información (sirve para algo).

TRABAJO PRÁCTICO 14

1) ¿Qué es la captura de Requisitos? ¿Por qué la captura de requisitos en complicada?

La captura de requisitos es el acto del descubrimiento: es un proceso que consiste en averiguar (generalmente en
circunstancias difíciles) lo que se debe construir.

2) ¿Por qué la captura de requisitos en complicada?

La captura de datos es complicada, porque a la hora de abstraer los datos, los usuarios al ser generalmente de
varios tipos; no tienen una visión global del problema, en consecuencia, no saben cómo hacer de manera eficiente
una operación en conjunto, tampoco saben los requisitos ni como especificarlos de forma precisa.

3) ¿Cuál es el objetivo de las actividades realizadas durante la captura de requisitos?

El objetivo es guiar el desarrollo del sistema de manera correcta mediante una descripción de los requisitos del
sistema.

4) ¿Por qué la captura de requisitos puede ser diferente en cada proyecto?

Porque cada proyecto difiere en el tipo de sistema, en el cliente, en la organización de desarrollo, en la tecnología,
etc. También difiere, en donde se desea realizar la captura de datos (Modelado de Negocio, Modelo de Dominio,
etc.).
5) Defina los conceptos de Requisitos Funcionales y Requisitos No Funcionales
Requisitos Funcionales: Que comportamiento debería ofrecer el sistema.
 Requisitos No Funcionales: Especifican propiedades del sistema, como restricciones del entorno o de la
implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, expansibilidad y
fiabilidad. Algunos hacen referencia a fenómenos del mundo real, como las cuentas en un sistema bancario. Una
propiedad especifica o restricción del sistema.

6) Enumere los pasos a seguir en el proceso de captura de Requisitos.

 Enumerar los requisitos candidatos.
 Comprender el contexto del sistema.
 Capturar los requisitos funcionales.
 Capturar los requisitos no funcionales.

7) Enumerar los requisitos candidatos:

 Estado.
 Coste estimado de implementación.
 Prioridad.
 Nivel de riesgo asociado a la implementación de la característica.
a) ¿En qué consiste esta tarea?
Consiste en separar ideas obtenidas en el ciclo de vida del sistema por medio de los involucrados (clientes,
usuarios, analistas, desarrolladores) las cuales pueden convertirse en verdaderos requisitos.

b) ¿Qué finalidad tiene?

La finalidad es utilizar dicho conjunto de requisitos candidatos para el día de mañana implementarlo en una
versión futura del sistema.

8) ¿Qué dos modelos se utilizan para expresar el contexto del sistema? Explique qué aspectos abarca cada uno de
ellos:

Modelado Del Dominio: Describe los conceptos importantes del contexto como objetos del dominio, y enlaza estos
objetos unos con otros. Nos centramos solo en las “cosas”, es decir, las clases del dominio o entidades del negocio
que necesitan usar los trabajadores.

Modelado Del Negocio: Su objetivo es describir los procesos (Existentes y observados) comprenderlos y mejorar
su desempeño en la organización. También especifican que procesos de negocio soportara el sistema establecido
en los requerimientos del mismo (Los trabajadores, sus responsabilidades y las operaciones que llevan a cabo).

9) ¿De qué manera se capturan los requisitos funcionales? Defina qué es un caso de uso.
Los requisitos funcionales se capturan por medio de los casos de uso.

Caso de Uso: Escenario de negocios o evento respecto del cual el sistema debe proporcionar una respuesta
definida.

10) Confeccione una lista con tipos de requerimientos No Funcionales, incluya en ella también los requerimientos
adicionales mencionados por el autor:

 Rendimiento.
 Capacidad.
 Disponibilidad.
 Seguimiento de estándares.
 Seguridad.
 Interfaces.
 Diseño físico.

11) ¿De qué manera se puede pasar del Modelo de Negocio al Modelo de Casos de Uso?
Mediante la utilización de un modelo de negocio como entrada, un analista emplea una técnica sistemática para
crear un modelo de caso de uso tentativo.
12) ¿Qué es el modelo de Requisitos?
Un modelo de requisitos son las formas diferentes, aunque complementarias, de capturar requisitos del sistema
generalmente esas formas son los modelos de caso de uso y requisitos adicionales (funcionales y no funcionales).

13) Confeccione una lista de fuentes de requisitos:

 Usuarios directos del sistema.

 Otros grupos de decisión (directores, mantenimiento, instaladores, etc.)
 Otros sistemas con los que interactúa el sistema.
 Dispositivos de hardware con los que interactúa el sistema.
 Restricciones legales y regulatorias.
 Restricciones técnicas.
 Objetivos de negocio.

14) ¿Qué intentan explicar los autores (Jim Arlow– Ila Neustadt) con la frase: “el mapa no es el territorio”.
Siempre que se trabaje con personas para definir los requisitos para un sistema, se está tratando de obtener un
mapa de su modelo del mundo. Dicho mapa es creado por medio de la eliminación, distorsión, y generalización.
Separando de manera necesaria los detalles importantes de dicho mundo, esto es necesario pues no podemos
captar de manera cognitiva un mapa mental infinitamente detallado.

15) Enumere distintas maneras de recopilar información necesaria para identificar requerimientos:

 Entrevistas.
 Cuestionarios.
 Workshops.

UNIDAD 8: Ingeniería De Requerimientos Cuestionario Del TP N° 15

UNIDAD 9: Métodos De Recolección

Entrevista:
¿Qué es una entrevista? ¿En qué consiste? Ventajas y Desventajas.
Las entrevistas personales consisten en preguntar los requerimientos a través de una interacción directa cara a cara.
Las entrevistas pueden usarse para alcanzar alguno o todos los objetivos siguientes:

-indagar hechos.
-Verificar hechos y/o aclararlos.
-Generar entusiasmo.
-Hacer que se involucre el usuario final.
-Identificar los requerimientos.
-Solicitar ideas y opiniones.

VENTAJAS

 Las entrevistas dan al analista una oportunidad para motivar al entrevistado para que responda libre y
abiertamente a las preguntas. Al establecer una armonía, el analista de sistemas puede darle al entrevistado
una percepción de que está contribuyendo activamente al proyecto de sistemas.
 Las entrevistas permiten que el analista de sistemas intente obtener más retroalimentación del entrevistado.
 Las entrevistas permiten que el analista de sistemas adapte o parafrasee las preguntas para cada persona.
 Las entrevistas le dan al analista una oportunidad para observar la comunicación no oral del entrevistado. Un
buen analista de sistemas puede ser capaz de obtener información al observar los movimientos corporales y
las expresiones faciales del entrevistado, así como al escuchar las respuestas orales a las preguntas.

DESVENTAJAS

 La entrevista es un enfoque de exploración que consume mucho tiempo, y por tanto es muy costosa.
  El éxito de las entrevistas depende mucho de las habilidades en relaciones humanas del analista de sistemas.
 Una entrevista puede ser impráctica debido a la ubicación del entrevistado

Cuestionario:
¿Qué es un cuestionario? ¿En qué consiste? Ventajas y Desventajas. Reglas a seguir para lograr la efectividad de un
cuestionario.

El cuestionario puede producirse en gran cantidad y distribuirse a los encuestados, quienes entonces pueden llenar el
cuestionario cuando tengan tiempo. Los cuestionarios le permiten al analista recolectar hechos de un gran número de
personas al tiempo que se mantienen respuestas uniformes. Al enfrentarse a una audiencia grande, ninguna otra
técnica de exploración puede tabular los mismos hechos con la misma eficacia.

VENTAJAS

 La mayoría de los cuestionarios pueden responderse rápidamente. La gente puede completar y devolver los
cuestionarios con toda comodidad.
 Los cuestionarios son un medio relativamente barato de recopilar datos provenientes de un gran número de
personas.
 Los cuestionarios permiten que las personas mantengan el anonimato. Por lo tanto, es más probable que las
personas suministren los hechos reales en vez de decirle lo que piensan que su jefe querría que ellos hicieran.
 Las respuestas pueden tabularse y analizarse rápidamente

DESVENTAJAS

 Con frecuencia el número de encuestados es bajo.

 No existe garantía de que una persona responda o se explaye a todas las preguntas.
 Los cuestionarios tienden a ser inflexibles. No hay oportunidad de que el analista de sistemas obtenga
información voluntaria o parafrasee las preguntas que pudieron haber sido mal interpretadas.
 No es posible que el analista de sistemas observe y analice el lenguaje corporal del encuestado.
 No hay una oportunidad inmediata para aclarar una respuesta vaga o incompleta a cualquier pregunta.
 Los buenos cuestionarios son difíciles de preparar

Hay dos formatos para los cuestionarios: El formato libre y el formato fijo.
 Los cuestionarios de formato libre se diseñan para permitir a los usuarios que ejerciten más libertad o
flexibilidad en sus respuestas a cada pregunta.
 Los cuestionarios de formato fijo son más rígidos ya que requieren que el usuario seleccione una respuesta
de un conjunto de respuestas posibles previamente definido.

Los buenos cuestionarios pueden ser difíciles de desarrollar. El siguiente procedimiento puede ser útil para el desarrollo
de una encuesta efectiva:

1. Determine qué hechos y opiniones deben recolectarse y de quién debe obtenerlas. Si el número de personas es
grande, considere el uso de un grupo de encuestados más pequeño seleccionado aleatoriamente.

2. Basándose en los hechos y en las opiniones buscadas, determine si las preguntas de formato libre o fijo darán las
mejores respuestas. Frecuentemente se usa un formato combinado que permite la aclaración opcional de formato
libre de las respuestas de formato fijo.

3. Escriba las preguntas. Examínelas en cuanto a errores de construcción y posibles malas interpretaciones. Asegúrese
de que las preguntas no revelen su sesgo personal o sus opiniones. Revise las preguntas.

4. Ensaye las preguntas en una pequeña muestra de encuestados. Si sus encuestados tuvieran problemas con éstas o
si las respuestas no fueran útiles, revise las preguntas.

5. Duplique y distribuya el cuestionario.

Observación: ¿Qué es la observación? ¿En qué consiste? Ventajas y Desventajas.
La observación consiste en que el analista de sistemas se convierte en un observador de las personas y de las
actividades con objeto de aprender acerca del sistema. Frecuentemente se usa esta técnica cuando se cuestiona la
validez de los datos recolectados mediante otros métodos o cuando la complejidad de ciertos aspectos del sistema
impide obtener una clara explicación por parte de los usuarios finales.

VENTAJAS
 Los datos recabados basándose en la observación pueden ser muy confiables. Algunas veces se realizan
observaciones para verificar la validez de los datos obtenidos directamente de las personas.
 El analista de sistemas puede ver exactamente lo que se está haciendo. Algunas veces es difícil explicar
claramente con palabras las tareas complejas. A través de la observación, el analista de sistemas puede
identificar las tareas que se han omitido o que se han descrito con inexactitud por otras técnicas de
exploración. También, el analista puede obtener datos que describan el ambiente físico de la tarea (por
ejemplo, la disposición física, el tránsito, la iluminación, el nivel de ruido).
 La observación es relativamente barata en comparación con otras técnicas de exploración. Generalmente
otras técnicas requieren mayor tiempo de liberación del empleado y más gastos de copiado
 La observación permite que el analista de sistemas haga mediciones del trabajo.

DESVENTAJAS

 Ya que la gente generalmente se siente incómoda cuando está siendo vigilada, inconscientemente puede
comportarse de una manera diferente que cuando está siendo observada.
 El trabajo que se esté observando tal vez no incluya el nivel de dificultad o de volumen normalmente
experimentado durante ese tiempo.
 Algunas actividades de sistemas pueden tener lugar en horas estrambóticas, causando una inconveniencia de
programación para el analista de sistemas.
 Las tareas que se observan están sujetas a diferentes tipos de interrupciones.
 Algunas tareas no siempre serán desempeñadas en la manera en que las observa el analista de sistemas. Por
ejemplo, el analista de sistemas pudo haber observado cómo una compañía llenaba varias solicitudes de los
clientes. Sin embargo, los procedimientos que el analista de sistemas observó pudieron haber sido los pasos
usados para llenar varias solicitudes regulares de los clientes. Si cualquiera de estas solicitudes hubiera sido
una solicitud especial (por ejemplo, de bienes que normalmente no se guardan en existencia), el analista de
sistemas habría observado un conjunto diferente de procedimientos que se ejecutan.
 Si las personas han estado realizando tareas de una manera que viole los procedimientos estándar de
operación, temporalmente pueden desempeñar su trabajo de manera correcta mientras que usted los
observa. En otras palabras, la gente puede permitirle ver lo que ellos quieren que usted vea.