REPASO 2DO PARCIAL ANALISIS

UNIT 6-------------------

Modelado de requerimientos del sistema con los casos de uso

1. Hay dos elementos primarios que participan al realizar la modelación de los casos de uso. El
primero es el diagrama de caso de uso, que ilustra gráficamente al sistema como una colección
de casos de uso, actores (usuarios) y sus relaciones. Los detalles de cada evento de negocios y
de cómo interactúan los usuarios con el sistema se describen en el segundo elemento, llamado
la narración del caso de uso, que es la descripción textual del evento de negocios y cómo va a
interactuar el usuario con el sistema para lograr la tarea.

2. La modelación de casos de uso utiliza dos construcciones: los actores y los casos de uso. Un
actor representa cualquier cosa que necesite interaccionar con el sistema para intercambiar
información. Un actor es un usuario, un papel, que podría ser un sistema externo así como una
persona. Un caso de uso es una secuencia de pasos relacionados (un escenario) tanto
automatizada como manual, con el propósito de completar una tarea individual del negocio.

3. Hay principalmente cuatro tipos de actores:

a) Actor primario de negocios: El involucrado que se beneficia en primer lugar de la ejecución del caso
de uso al recibir algo de valor medible u observable.

b) Actor primario del sistema: El involucrado que sostiene una interfaz directa con el sistema para iniciar
u originar el evento de negocios o del sistema.

c) Actor externo proveedor: El involucrado que responde a una solicitud proveniente del caso de uso.

d) Actor externo receptor: El involucrado que no es el actor primario pero que recibe algo de valor
medible u observable (salida) proveniente del caso de uso.

4. Los eventos temporales son eventos de negocios que se realizan (o se originan) en forma
automática; cuando se cumple cierta fecha o lapso. Debido a eso, decimos que el actor de un
evento temporal es el tiempo.

5. Una relación se ilustra como una línea entre dos símbolos en el diagrama de casos de uso.
a) Una asociación es una relación entre un actor y un caso de uso.
b) La relación entre el caso de uso de extensión y el caso de uso que se está extendiendo se llama una
relación de extensión.
c) La relación entre el caso de uso resumen y el caso de uso que los usa se llama una relación de usos.
d) La relación de herencia ocurre cuando un actor hereda la capacidad para iniciar un caso de uso de
otro.
e) La relación de dependencia indica una dependencia entre los casos de uso. En otras palabras, la
precondición de un caso de uso depende de la postcondición de otro caso de uso.
 6. Los pasos requeridos para producir un modelo de casos de uso de requerimientos son los
siguientes:
a) Identificar a los actores de negocios
b) Identificar los casos de uso de requerimientos de negocios.
c) Construir el diagrama del modelo de casos de uso
d) Documentar las narraciones de los casos de uso para los requerimientos de negocios.

7. La matriz de prioridad y la jerarquización del caso de uso son las herramientas que usan los
administradores de proyecto para priorizar y programar el desarrollo del caso de uso.

UNIT 7---------------------

Modelado y análisis de datos

1. El modelado de datos es una técnica para organizar y documentar los DATOS de un sistema.
Algunas veces se llama al modelado de datos “modelado de bases de datos”, porque un modelo
de datos generalmente se implementa como una base de datos.
2. Hay varias notaciones para el modelado de datos. Frecuentemente, al modelo real se le llama
ERD (Entity Relationship Diagram, Diagrama de Entidad Relación) porque bosqueja los datos en
términos de las entidades y relaciones descritas por los datos.
3. Una entidad es algo acerca de lo cual el negocio necesita almacenar datos. Las clases de
entidades incluyen las personas, los lugares, los objetos, los eventos y los conceptos.
4. Una instancia de entidad es una ocurrencia individual de una clase de entidad.
5. Las piezas de datos que queremos almacenar sobre cada instancia de una entidad dada se
llaman atributos. Un atributo es una característica o propiedad descriptiva de la entidad.
Algunos atributos pueden agruparse lógicamente en superatributos llamados atributos
compuestos.
6. Al analizar un sistema, debemos definir los valores de un atributo que sean legítimos o que
tengan La mayoría de ustedes irán directamente al capítulo 8, “Modelado de procesos”.
Mientras que el modelado de datos se ocupa de los datos independientemente de cómo se
capturan y se usan esos datos (datos estáticos), el modelado de procesos muestra cómo se
capturarán y se usarán los datos (datos dinámicos). Si usted quiere aprender inmediatamente
cómo implementar los modelos de datos como bases de datos, deberá revisar o leer el capítulo
12, “Diseño de bases de datos”. En ese capítulo los modelos lógicos de datos se transforman en
esquemas físicos de bases de datos. Con las herramientas CASE, el código para crear la base de
datos puede generarse automáticamente. Mapa de aprendizaje sentido en los negocios. Los
valores de cada atributo se definen en términos de tres propiedades: tipo de dato, dominio del
dato y datos por omisión:
a. Los tipos de datos determinan qué clase de datos pueden almacenarse en el atributo.
b. El dominio de un atributo define qué valores puede adoptar legítimamente un atributo.
c. El valor por omisión de un atributo es el valor que será registrado si no es especificado
por el usuario.
7. Cada entidad debe tener un identificador o clave. Una clave es un atributo, o un grupo de
atributos, que asume un valor único para cada instancia de entidad.
 a. Un grupo de atributos que identifica en forma única a una instancia de una entidad se
llama clave concatenada.
b. Una clave candidato es un “candidato para convertirse en el identificador primario” de
las instancias de una entidad.
c. Una clave primaria es la clave candidata que más comúnmente se usará para identificar
en forma única una instancia de entidad individual.
d. Cualquier clave candidata que no se seleccione para convertirse en clave primaria se
designa clave alterna.
e. Algunas veces también es necesario identificar un subconjunto de instancias en
contraposición con una instancia individual. Un criterio de subconjuntos es un atributo
(o atributo concatenado) cuyos valores finitos dividen a todas las instancias de entidad
en subconjuntos útiles.
8. Una relación es una asociación natural de negocios que existe entre uno o más entidades. La
relación puede representar un evento que enlaza a las entidades o meramente una afinidad
lógica que existe entre las entidades. Todas las relaciones son implícitamente bidireccionales, es
decir, pueden interpretarse en ambas direcciones.
9. La cardinalidad define los números mínimo y máximo de las ocurrencias de una entidad para
una ocurrencia individual de la entidad relacionada. Y como todas las relaciones son
bidireccionales, la cardinalidad debe definirse en ambas direcciones para cada relación.
10. El grado de una relación es el número de clases de entidad que participan en la relación. No
todas las relaciones son binarias. Algunas relaciones pueden ser relaciones recursivas, en donde
existe una relación entre las diferentes instancias de la misma entidad. Las relaciones también
pueden existir entre más de dos entidades diferentes, como en el caso de una relación de tercer
orden o ternaria.
11. Una entidad asociativa es una entidad que hereda su clave primaria de más que alguna otra
entidad (los padres). Cada parte de esa clave concatenada apunta a una instancia y solamente
una de cada una de las entidades de conexión.
12. Una clave foránea es una clave primaria de una entidad que aporta (se duplica) a otra entidad
para identificar las instancias de una relación. Una clave foránea (siempre en una entidad hijo)
siempre corresponde a la clave primaria (en una entidad padre).
13. Las relaciones sin identificación son aquéllas en las que cada una de las entidades participantes
tiene su propia clave primaria independiente, de las cuales ninguno de los atributos de la clave
primaria es compartido. Las entidades en una relación sin identificación se denominan
entidades fuertes o independientes porque ninguna de ellas depende de ninguna otra entidad
para su identificación. Las relaciones de identificación son aquéllas en las cuales la entidad padre
aporta su clave primaria para formar parte de la clave primaria de la entidad hijo. La entidad hijo
de cualquier relación de identificación se llama entidad débil porque su identificación depende
de la existencia de la entidad padre.
14. Una relación no específica (o relación de muchos a muchos) es una en la cual se asocian muchas
instancias de una entidad con muchas instancias de otra entidad. Tales relaciones son
adecuadas sólo para los modelos preliminares de datos y deberán resolverse tan rápido como
sea posible.
 15. La generalización es un enfoque que trata de descubrir y sacar provecho de las comunalidades
entre entidades. Es una técnica en donde los atributos se agrupan para formar supertipos y
subtipos de entidades.
a. Un supertipo de entidad es una entidad cuyas instancias almacenan atributos que son
comunes para uno o más subtipos de entidad.

b. Un subtipo de entidad es una entidad cuyas instancias heredan algunos atributos

comunes de un supertipo de entidad y luego añade otros atributos que son únicos para
una instancia del subtipo.

16. Un modelo lógico de datos se desarrolla en las siguientes etapas:

a. Las entidades se descubren y se definen.
b. Se construye un modelo de datos de contexto. Un modelo de datos de contexto
contiene sólo entidades y relaciones de negocios identificadas por los dueños del
sistema y los usuarios.
c. Se construye un modelo de datos basado en claves. El modelo basado en claves elimina
las relaciones no específicas y añade las entidades asociativas. A todas las entidades en
el modelo se les dan claves.
d. Se construye un modelo totalmente atribuido. Este modelo muestra todos los atributos
que deben guardarse en el sistema.
e. Se construye un modelo totalmente descrito. Cada atributo se define en el diccionario y
se describe en términos de propiedades como el dominio y la seguridad.
f. Entonces se analiza el modelo de datos completados con respecto a la adaptabilidad y la
flexibilidad a través de un proceso llamado normalización. El modelo final analizado se
llama modelo de datos de la tercera forma normal.
17. Un modelo lógico de datos no comunica requerimientos de datos sobre una base operativa de
negocios de posición. Los analistas de sistemas lo han encontrado útil para definir estos
requerimientos en la forma de una matriz CLAB de datos de posición.

UNIT 8-----------------

Modelado de procesos

1. Construimos modelos lógicos para entender mejor los dominios y requisitos de los problemas de
negocios.
2. La modelación de procesos es una técnica para organizar y documentar los requisitos de
proceso y el diseño de un sistema. Este capítulo enfocó la atención en un modelo de proceso
llamado diagrama de flujo de datos, que esquematiza el flujo de datos a través de los procesos
de un Sistema.
3. Los agentes externos son entidades que están fuera del alcance de un sistema y del proyecto
pero que proveen entradas netas o salidas netas de un sistema. Como tal, forman las fronteras
del sistema.
4. Los almacenes de datos presentan los archivos de datos que el sistema va a usar y mantener. Un
almacén de datos en un modelo de proceso corresponde a todas las instancias de una entidad
dentro de un modelo de datos.
5. Un sistema es un proceso. Un proceso es un trabajo que se realiza, o una respuesta a entradas y
condiciones.
6. Tal como los sistemas pueden descomponerse recursivamente en subsistemas, los procesos
pueden descomponerse recursivamente en subprocesos. Un diagrama de descomposición
muestra la descomposición funcional de un sistema en procesos y subprocesos. Es una
herramienta de planificación para los siguientes diagramas de flujo de datos.
7. Los procesos lógicos muestran el trabajo esencial para ser realizado por un sistema sin mostrar
cómo serán implementados los procesos. Hay tres tipos de procesos lógicos: las funciones (el
nivel muy alto), los eventos (nivel intermedio de detalle) y los procesos elementales (muy
detallado).
8. Los procesos elementales se describen con más profundidad por la lógica procedural. El inglés
estructurado es una herramienta para expresar esta lógica procedural. Se deriva de las
construcciones de la lógica estructurada de programación unidas con el inglés natural.
9. Los procesos elementales complejos pueden estar descritos por políticas que se expresan en las
tablas de decisión, que demuestran combinaciones complejas de condiciones que dan como
resultado acciones específicas.
10. Los flujos de datos son las entradas y las salidas de los procesos. También ilustran accesos a los
almacenes de datos y actualizaciones.
11. Todos los flujos de datos constan ya sea de otros flujos o de estructuras discretas de datos que
incluyen atributos descriptivos. Un flujo de datos deberá contener sólo la cantidad de datos
necesarios para un proceso; a esto se le llama conservación de datos.
12. La modelación de procesos puede usarse en diferentes tipos de proyectos, incluyendo el
rediseño de los procesos de negocios y el desarrollo de aplicaciones. Para los proyectos de
desarrollo de aplicación, este capítulo enseñó una estrategia de diagramación de flujos de datos
impulsados por los eventos tal como sigue:
a. Dibuje un diagrama de flujo de datos de contexto que muestre cómo el sistema tiene
interfaces con otros sistemas, las organizaciones de negocios y las externas.
b. Dibuje un diagrama de descomposición funcional que muestre los subsistemas y/o
funciones claves que integran al sistema.
c. Cree una lista de eventos que identifique los eventos externos y temporales para los
cuales el sistema debe proveer una respuesta. Los eventos externos son
desencadenados por los agentes externos de un sistema. Los eventos temporales son
desencadenados por el transcurso del tiempo.
d. Actualice el diagrama de descomposición para incluir procesos para manejar los eventos
(un proceso por evento).
e. Para cada evento, dibuje un diagrama de eventos que muestre sus interacciones con
entidades externas, almacenes de datos y, en ocasiones, con otros disparadores de
otros acontecimientos.
f. Combine los diagramas de eventos en uno o más diagramas del sistema.
g. Para cada evento en el diagrama de sistemas, descríbalo como un proceso elemental
usando inglés estructurado o bien expándalo a un diagrama elemental de flujo de datos
que incluya los procesos elementales que deben describirse subsecuentemente, ya sea
por el inglés estructurado o por las tablas de decisión, o por ambos. Cuando los
procesos se expanden a diagramas de flujo de datos para revelar mayor detalle es
 importante mantener la consistencia entre los diferentes tipos de diagramas, a lo cual
se le llama sincronización.
13. La mayoría de las herramientas de ingeniería de software asistida por computadora soportan la
diagramación de descomposición y la diagramación de flujo de datos.

UNIT 9---------------

Análisis de Factibilidad y propuesta del sistema

1. La factibilidad es una medición del grado en que el desarrollo de un sistema de información sería
beneficioso para una organización. El análisis de factibilidad es el proceso de medirla. Se trata de una
evaluación continua en diversos controles del ciclo de vida. En cualquiera de esos puntos se podría
cancelar, modificar o continuar el proyecto. Esto se denomina estrategia de compromiso creciente con
la factibilidad.

2. Existen seis pruebas de factibilidad: operativas, culturales/políticas, técnicas, de calendario,

económicas y legales.

a) La factibilidad operativa es una medición de la urgencia del problema o la aceptabilidad de la

solución. Incluye la medición del sentir de los usuarios finales y administradores acerca de los
problemas o las soluciones.

b) La factibilidad cultural (o política) es una medición del sentir de una persona acerca de una
solución y el grado en que será aceptada.

c) La factibilidad técnica es una medición del grado en que son prácticas las soluciones y si se
cuenta o no con la tecnología necesaria en la organización. En caso de no contar con ella, la
factibilidad técnica también considera si es posible adquirirla.

d) La factibilidad de calendario corresponde a medir el grado en que los tiempos o fechas límite
de un proyecto son razonables.

e) La factibilidad económica mide si una solución permitirá recuperar la inversión

correspondiente o cuán rentable será. Es la más importante de las cuatro mediciones, para los
administradores.

f) La factibilidad legal cuantifica el grado en que es posible implantar una solución dentro de las
obligaciones legales y contractuales existentes.

3. El análisis de la factibilidad económica requiere pormenorizar los beneficios y los costos. Los
beneficios son tangibles (fáciles de medir) o intangibles (de difícil medición). A fin de analizar
correctamente la factibilidad económica, hay que tratar de estimar el valor de todos los beneficios. Los
costos son de dos categorías: de desarrollo y operativos.

a) Los costos de desarrollo se desembolsan una sola vez en relación con el análisis, diseño e
implantación del sistema.

b) Los costos de operación pueden ser fijos en el tiempo o variables conforme al uso del
sistema.
4. Dados los costos y beneficios, la factibilidad económica se valora con las técnicas de análisis de costo-
beneficio. Estas últimas determinan si un proyecto o solución será rentable, es decir, si los beneficios
serán mayores que los costos durante el ciclo de vida. Son tres las formas más usadas de medir la
relación costo-beneficio: análisis de la recuperación de la inversión, análisis del rendimiento sobre la
inversión y análisis del valor presente neto.

a) El análisis de la recuperación de la inversión determina el tiempo que tardará en pagarse la

inversión.

b) Los análisis del rendimiento sobre la inversión y del valor presente neto determinan la
rentabilidad de un sistema.

c) Se prefiere el análisis de valor presente neto porque permite comparar alternativas con ciclos
de vida distintos.

5. Una matriz de soluciones alternativas del sistema es una herramienta útil para documentar las
similitudes y diferencias entre diferentes soluciones del sistema que se consideran.

6. La matriz de análisis de factibilidad de soluciones sirve para evaluar y clasificar las soluciones
alternativas del sistema. Junto con la matriz de análisis de factibilidad de soluciones, resulta útil
presentar los resultados del análisis de factibilidad como parte de una propuesta del sistema.

7. Los informes escritos son el medio de comunicación que más usan los analistas. Consisten en
elementos primarios y secundarios. Los primarios contienen información de hechos, mientras que los
secundarios, por así decirlo, articulan el informe para facilitar su uso. Los informes suelen organizarse en
formato factual o administrativo. El primero muestra los detalles antes de las conclusiones, mientras
que en el segundo se invierte el orden. Los administradores gustan del formato administrativo porque
se orienta a resultados y va directamente a la pregunta de fondo.

8. Las presentaciones formales son un tipo especial de junta en la que una persona presenta las
conclusiones, ideas o propuestas a un auditorio interesado. La preparación es la clave de las
presentaciones efectivas.

9. La propuesta del sistema puede ser un informe escrito formal o una presentación verbal.

UNIT 10----------

Diseño de sistemas

1.El diseño de sistemas de información se define formalmente como las tareas enfocadas en las
especificaciones de una solución computarizada detallada. Mientras que en el análisis de sistemas se
hace énfasis en el problema del negocio. En el diseño de sistemas se centra la atención en los aspectos
técnicos o de implantación del sistema.

2. El diseño de sistemas se basa en las preocupaciones técnicas de los diseñadores del sistema. Por lo
tanto, en lo referente a los componentes del sistema de información, tal diseño considera los
componentes de dicho sistema desde la perspectiva de su diseñador.
3. El diseño de sistemas de los proyectos de desarrollo al interior de la organización o de “construcción”
difiere de los de “compra”, en que en este último se adquiere un paquete de software de sistemas.

4. Son muchas las estrategias o técnicas para el diseño de sistemas. Se las puede utilizar combinadas.

a) Diseño estructurado moderno, técnica que se enfoca en los procesos.

b) Ingeniería de la información (IE, por sus siglas en inglés), que se centra en la planeación de
datos y en la estrategia para generar proyectos de aplicaciones.

c) Elaboración de prototipos, que es un proceso iterativo que implica una relación de trabajo
estrecho entre los diseñadores y usuarios para producir un modelo del nuevo sistema.

d) Desarrollo conjunto de aplicaciones (JAD, por sus siglas en inglés), que hace énfasis en el
desarrollo con la participación de los propietarios, usuarios, diseñadores y constructores del
sistema. Durante las sesiones de JAD para el diseño de sistemas, el diseñador del sistema asume
la función de facilitador.

e) El desarrollo rápido de aplicaciones (RAD, por sus siglas en inglés) es una técnica que
constituye una fusión de las diversas técnicas estructuradas con la elaboración de prototipos y el
JAD para acelerar el desarrollo de los sistemas.

f) El diseño orientado a objetos (OOD, por sus siglas en inglés), nueva estrategia de diseño que
da seguimiento al análisis orientado a objetos para refinar las definiciones de requerimientos de
objetos y definir nuevos objetos específicos del diseño en cuestión.

5. En el caso de los proyectos de desarrollo en la organización (construcción), el diseño de sistemas

incluye el desarrollo de especificaciones de diseño técnico que sirven de guía en la construcción y puesta
en marcha del nuevo sistema. A fin de completar la fase de diseño, el diseñador del sistema debe
realizar las tareas siguientes:

a) Diseñar la arquitectura de aplicaciones.

b) Diseñar la base o bases de datos del sistema.

c) Diseñar la interfaz del sistema.

d) Integrar (“conjuntar”) las especificaciones de diseño.

e) Actualizar el plan del proyecto.

6. El diseño de sistemas para soluciones que incluyen la adquisición de productos de software

comerciales listos para usarse (COTS, por sus siglas en inglés) abarca la fase de suministro análisis de
decisiones, relativa al software y a los servicios. La realización de estas fases comprende las siguientes
tareas:

a) Investigación de criterios técnicos y opciones.

b) Solicitud de propuestas o cotizaciones de los proveedores.

c) Validación de las afirmaciones y desempeño de los proveedores.

 d) Evaluación y jerarquización de las propuestas de los proveedores.

e) Otorgamiento del contrato y sesión informativa a los proveedores no elegidos.

7. No basta simplemente comprar o construir sistemas que satisfagan los requerimientos del sistema
deseado. El analista debe integrar o comunicar el nuevo sistema con los numerosos sistemas existentes
que son fundamentales para la empresa. Muchos de estos sistemas incluyen el uso de tecnologías,
técnicas y estructuras de archivos con diferencias impresionantes entre ellas.