Análisis de sistemas Resumen Parcial ll

TEMA 1: Requerimientos, clasificación de requerimientos, proceso de ingeniería de

requerimientos, proceso de validación, técnicas de validación y prototipo.

Requerimientos: Los requerimientos para un sistema son la descripción de los servicios

proporcionados por el sistema y sus restricciones operativas. Reflejan las necesidades de los
clientes de un sistema que ayude a resolver algún problema.

TIPOS DE REQUERIMIENTOS:

1) Requerimientos del usuario: Son declaraciones de los servicios que se espera que el
sistema proporcione y de las restricciones bajo las cuales debe funcionar. Estas
declaraciones pueden ser en lenguaje natural y en diagramas.

2) Requerimientos del sistema: Establecen con detalle las funciones, servicios y

restricciones operativas del sistema.
 Requerimientos funcionales: Se declara los servicios que debe y no debe hacer
el sistema, se debe declarar como se debe comportar para entradas particulares.
 Requerimientos no funcionales: Son restricciones de los servicios o funciones
ofrecidos por el sistema (como rendimiento, protección, disponibilidad, etc.).

Dentro de los requerimientos no funcionales se encuentran:

 Requerimientos del producto: Usabilidad, eficiencia (rendimiento, espacio),
confiabilidad y seguridad.

1. Usabilidad: Esta categoría define aspectos relacionados con las dificultades que pueden
encontrar los usuarios al enfrentarse al uso del nuevo sistema. Facilidad de Aprendizaje:
Tiempo de Formación, Número de cuadros de ayuda. EJ: La
Interfaces del Usuarios deberá ser simple.

2. Eficiencia: Esta categoría define aspectos que indican la proporción entre el nivel de
cumplimiento del sistema y la cantidad de recursos necesitados bajo condiciones
establecidas.

3. Confiabilidad: Es la probabilidad de que durante un determinado período de tiempo el

sistema funcione correctamente tal como espera el usuario. Tiempo medio entre fallos.
Probabilidad de no disponibilidad.

4. Seguridad: Restringe el comportamiento del sistema en cuanto a su seguridad.

  Requerimientos organizacionales: Ambientales, operacionales y desarrollo

1. Ambientales: Definen el entorno de operación del sistema. En función del

hardware y el software.
2. Procesos operacionales: Definen cómo se usará el sistema. En función de los
usuarios o RRHH respecto del sistema, seguridad.
3. Proceso de Desarrollo: Especifican el lenguaje de programación, estándares del
entorno o el proceso de desarrollo a utilizar

 Requerimientos externos: Regulatorios, ético y legislativo (contable,

protección/seguridad).

1. Regulatorios: Establecen lo que debe hacer el sistema para ser aprobado en su uso
por un regulador, como sería un banco central.
2. Ético: Se definen para poder asegurar que será aceptado por los usuarios y por el
público en general.
3. Legislativo: Deben seguirse para asegurar que el sistema funcione dentro de la ley.

PROCESOS DE INGENIERIA DE REQUERIMIENTOS :

La ingeniería de requerimientos es el proceso de descubrir, analizar, documentar y verificar estos
servicios y restricciones.

El proceso general contiene cuatro subprocesos:

 Estudio de factibilidad: Se realiza una estimación sobre si las necesidades identificadas del
usuario cubren con las actuales tecnologías. El estudio considera si el sistema propuesto
tendrá un costo beneficio desde el punto de vista empresarial, y si este puede
desarrollarse dentro de las restricciones del presupuesto existente. Debe ser rápido y
relativamente barato. El resultado debe informar si continúa o no continúa con un análisis
más detallado.
 Adquisición y análisis de requerimientos: Este es el proceso de derivar los requerimientos
del sistema mediante observación de los sistemas existentes, discusiones con los usuarios
y proveedores potenciales. Esto debe incluir el desarrollo de uno o más modelos de
sistema y prototipos, lo que ayuda a entender el sistema.
 Especificación de requerimientos: Consiste en la actividad de transcribir la información
recopilada durante la actividad de análisis, en un documento que define un conjunto de
requerimientos. En este documento se incluyen dos tipos de requerimientos: Los
requerimientos del usuario (informes abstractos de requerimientos del sistema para el
cliente y el usuario final) y los requerimientos de sistema (descripción detallada de la
funcionalidad a ofrecer).
 Validación de requerimientos: Verifica que los requerimientos sean realistas, coherentes
y completos. Durante este proceso es inevitable descubrir errores en el documento de
requerimientos.
 ADQUISICION Y ANALISIS DE REQUERIMIENTOS:
I) Descubrimiento de los requerimientos: Se interactúa con los stakeholders para recopilar los
requerimientos

II) Clasificación y organización de los requerimientos: Se deben organizar en forma

coherente.

III) Priorización y negociación de los requerimientos: Se debe priorizar los requerimientos.

Resolver los requerimientos en conflictos.

IV) Especificación de los requerimientos: Se documenta y entra en una vuelta el espiral. Esa
Documentación puede ser formal o informal.

DESCUBRIMIENTO DE LOS REQUERIMIENTOS

Es el proceso de recoger información sobre el sistema propuesto y existente. Extraer los
requerimientos del usuario y del sistema de esta información. Las fuentes de información
durante esta fase son documentación, los stakeholders y la especificación de sistemas
similares. Se emplean técnicas de descubrimiento de los requerimientos como entrevistas,
escenarios y etnografía y podemos construís prototipos de sistema entre otras.

ESPECIFICACION DE REQUERIMIENTOS
Pautas a seguir:

1) Emplear formatos estándares para asegurar que todos los requerimientos se encuentren y
evitar omitir algunos de ellos.
2) Utilizar el lenguaje de forma consistente. Siempre debe distinguir entre los requerimientos
deseables y los obligatorios.

LOS REQUERIMIENTOS OBLIGATORIOS SON LOS REQUERIMIENTOS A LOS QUE EL SISTEMA

DEBE DAR SOPORTE Y NORMALMENTE SE REDACTAN EN FUTURO SIMPLE.

LOS REQUERIMIENTOS DESEABLES NO SON FUNDAMENTALES Y SE REDACTAN EN FUTURO

CONDICIONAL.

3) Resaltar el texto para distinguir las partes clave del requerimiento.

4) Evitar el uso de jerga informática.

CARACTERISTICAS A TENER EN CUENTA AL ESPECIFICAR LOS REQUERIMIENTOS

Que los requerimientos sean:

-Necesarios: Si su omisión provoca una deficiencia en el sistema a construir, y además su

capacidad, características física o factor de calidad no puede ser reemplazados por otras
capacidades del producto o del proceso.

-Concisos: Requerimiento fácil de leer y entender.

-Completos: Se debe proporcionar la información suficiente para su compresión.

 -Consistentes: No es contradictorio con otro requerimiento.

-No ambiguos: Tiene una sola interpretación.

-Verificables: Un requerimiento es verificable cuando puede ser cuantificado de manera que

permita hacer uso de métodos como: inspección, análisis, demostración o pruebas.

VALIDACIÓN DE LOS REQUERIMIENTOS

1) Trata de mostrar que estos realmente definen el sistema que el cliente desea.
2) Es importante debido a que los errores en el documento de requerimiento pueden
conducir a grandes costos
3) Durante el proceso tienen que realizarse diferentes tipos de comprobaciones sobre los
requerimientos contenidos en el documento de requerimientos.

TECNICAS PARA LA VALIDACION DE REQUERIMIENTOS: (Se usan individualmente o en

conjunto).

1) Revisiones de los requerimientos: Se analizan sistemáticamente usando un equipo de

revisiones que verifican errores e inconsistencias.
2) Creación de prototipos: Se muestra un modelo ejecutable del sistema en cuestión a los
usuarios finales y clientes. Así, ellos podrán experimentar con este modelo para constatar
si cubre sus necesidades reales.
3) Generación de cosas de prueba: Los requerimientos deben ser comprobables. Si las
pruebas para los requerimientos se diseñan como parte del proceso de validación, esto
revela con frecuencia problemas. Si una prueba es difícil o imposible de diseñar, hace que
los requerimientos serán difíciles de implementar.

PROTOTIPO
-Un prototipo es una visión preliminar del sistema futuro que se implementara.
-Una técnica valiosa para la recopilación rápida de información específica acerca de los
requerimientos de información de los usuarios.

-Complementan el ciclo de vida de desarrollo de un sistema tradicional.

VENTAJAS: Posibilidad de cambiar el sistema en etapa tempranas de su desarrollo, detener el

desarrollo de un sistema que no funciona, posibilidad de desarrollar un sistema que satisfaga las
necesidades de los usuarios en función de los requerimientos del mismo.

TIPOS DE PROTOTIPOS:
 Parchados: Construcción de un sistema de información que tiene todas las características
propuestas, pero es realmente un modelo básico que eventualmente será mejorado. Son
modelos operables pero que no es eficiente
 No operacionales: Es un modelo a escala NO FUNCIONAL para probar determinados
aspectos de diseño. Se pueden realizar prototipos de entradas/salidas.
 Primeros de una serie: Es la realización de un prototipo completo del sistema, llamado
piloto pero que se pondrá posteriormente en otros lugares.
  Prototipos de características seleccionadas: Construir un modelo operacional que incluye
alguna, pero no todas, las características que tendrá el sistema total.

Pautas para la creación de un Prototipo

• Trabajar con módulos manejables, que es aquel que permite la interacción con sus
características principales, pero todavía puede ser construido por separado en otros módulos del
sistema.

• Construir el prototipo rápidamente.

• Modificar el prototipo, para que el sistema este lo mas rápido posible cerca de lo que los
usuarios pretenden de él.

• Enfatizar en la interfaz de usuario, con lo que se busca la interacción del usuario con un mínimo
de entrenamiento, que el mismo muestre cada vez mas los requerimientos de información del
sistema.

PROTOTIPOS PROCESO DE DESARROLLO:

 Los objetivos deben ser explícitos:
-Desarrollar un sistema para construir un PIU
-Desarrollar un sistema para validar los requerimientos funcionales
 Se debe decidir que incluir y que excluir del sistema de prototipo:
-Se debe excluir los requerimientos no funcionales
 Se debe prever la información de usuario, tener en claro el objetivo del prototipo:
-Se debe realizar un plan de evaluación ahora descubrir errores y omisiones de
requerimientos.

1) Prototipo evolutivo: Entrega a los usuarios finales un sistema en funcionamiento. Se

utiliza cuando los requerimientos se entienden claramente
2) Prototipo Desechable: Valida u obtiene los requerimientos del sistema. Se utiliza en
aquellos requerimientos que no se comprenden.
El problema general del prototipo desechable ejecutable es que el modo de utilizarlo no
corresponda con el modo de utilizar el sistema final entregado. El tiempo de formación del
prototipo no sea el usuario del sistema, el tiempo de formación del usuario haya sido
insuficiente. Si el prototipo es lento, se evitará usar las características de tiempo de
respuesta lento.

Documento Visión
El documento Visión es un informe que recopila y analiza las ideas que han surgido para el
futuro sistema. Este documento podría utilizarse como un contrato formal o informal
entre los desarrolladores del sistema y la empresa.
Objetivos del Documento:
• Asegurar que los interesados en el Sistema de Información tengan una visión clara y
compartida de los objetivos y alcances del sistema.
• Describir los objetivos y restricciones de alto nivel.
• Analizar los problemas / oportunidades del negocio.
• Servir de apoyo a la toma de decisiones.
• Presentar un presupuesto que permita planificar el Proyecto de Sistemas.

Que contiene el Documento Visión

Contiene la Información esencial acerca del Sistema de Información que se desarrollará. El
Documento puede contener varias secciones:
• Descripción del Personal - (Stakeholders): Identificación del grupo de personas
interesadas en el sistema.
• Descripción del Problema: Se debe definir de forma clara con el objetivo de reducir la
posibilidad de que el personal involucrado este intentando solucionar problemas
diferentes.
• Objetivos del Proceso:
• Resumen de las Características del Sistema:
• Visión general del Producto (Sistema de Información):

Modelo del Dominio

Definición: Es una representación de las clases conceptuales del mundo real, no de

componentes del software, No se trata de un conjunto de diagramas que
describen clases de software, u objetos de software con responsabilidad. Es el
artefacto más importante que se crea durante el análisis orientado a objetos,
El modelo de dominio es una representación visual de las clases conceptuales u objetos
del mundo real en un dominio de interés, estos modelos pueden mostrar:
✓ Objetos del dominio o clases conceptuales.
✓ Asociaciones entre las clases conceptuales.
✓ Atributos de las clases conceptuales.
✓ Multiplicidad.
CLASES CONCEPTUALES

Una clase conceptual es una idea, cosa u objeto. También podría considerarse en términos de un
símbolo, intención y extensión.

 Símbolo: Palabras o imágenes que representan una clase conceptual

 Intención: Definición de una clase conceptual
 Extensión: El conjunto de ejemplos a los que se aplica la clase conceptual

IDENTIFICACION DE CLASES CONCEPTUALES

Estrategias o técnicas para identificar clases conceptuales:

1) Utilizar una lista de categorías clases conceptuales

2) Identificación de frases nominales
3) Uso de patrones de análisis, que son modelos de dominios parciales existentes creados
por expertos.

Lista de categorías:
Frases nominales (EJEMPLO):
Otra técnica recomendad es el análisis lingüístico: identificar los nombres y frases nominales
en las descripciones textuales de un dominio, y considerarlos como clases conceptuales o
atributos candidatos.

¿COMO HACER UN MODELO DE DOMINIO?

1) Liste las clases conceptuales candidatas, utilizando las técnicas de la lista de categorías de
clases conceptuales y la identificación de frases nominales, relacionadas con los requisitos
actuales en estudio.
2) Añadir atributos necesarios para satisfacer los requisitos de información.
3) Añada las asociaciones necesarias para registrar las relaciones que hay que mantener en
memoria.
4) Represéntalo en un modelo de dominio.

ERRORES TIPICOS EN LA IDENTIFICACIÓN

El error más típico al crear un modelo del dominio es representar algo como un atributo
cuando debería haber sido un concepto.

¿QUÉ SON LOS PATRONES DEL ANÁLISIS? Son un conjunto de clases y relaciones entre ellas,
que tienen algún sentido en el contexto de una aplicación y que sirven para entender en
detalle el negocio y sus reglas.
CLASES CONCEPTUALES DE ESPECIFICACIÓN O DESCRIPCIÓN

Son necesarias cuando:

 Se necesita la descripción de un artículo o servicio, independiente de la existencia actual.

 La eliminación de las instancias de las cosas que describen dan como resultado una
pérdida de información.
 Reduce información redundante y duplicada.

ASOCIACIONES: Es una relacion entre tipos que indica conexión significativa e interesante.

NOTACION DE LAS ASOCIACIONES EN UML: Se representa como una linea entre clases con un
nombre de asociacion.

ROLES: Los extremos de las asociaciones se denominan roles. Pueden tener opcionalmente
nombre, expresiones de multiplicidad, navegabilidad.

MULTIPLICIDAD: Define cuantas instancias de una clase A pueden asociarse con una instancia de
la clase B

 * cero o más “muchos”

 1.. * uno o más
 1..40 de uno a 40

ATRIBUTOS

Es el valor de datos lógicos de un objeto

 Atributos simples: La mayoría de los atributos simples son los que se conocen como los
tipos de datos primitivos, como los números. El tipo de un atributo, normalmente no
debería ser un concepto de dominio complejo. Se recomienda que se relaciones con las
clases conceptuales por asociaciones.
 1. Contrato en Análisis del Sistema
Esté describe el comportamiento detallado del sistema en función de los cambios de
estado de los objetos del Modelo del Dominio, después de la ejecución de una operación
del sistema.
Ejemplo de contrato (Introducir Articulo)

Secciones de un Contrato:
 Operación: Nombre de la operación y parámetros.
 Referencias Cruzadas (Opcional): Casos de uso en los que pueden tener
lugar esta operación.
 Precondiciones: Suposiciones relevantes sobre el estado del sistema o de los
objetos del modelo de dominio.
 Postcondiciones: Estado de los objetos del modelo de dominio después de
que se complete la operación.

2. Modelo de casos de uso

El UP define el Modelo de Casos de Uso como el conjunto de todos los casos de uso; es un modelo
de la funcionalidad y entorno del sistema.

Objetivos

Los clientes y los usuarios finales tienen objetivos y quieren sistemas informáticos que ayuden a
conseguirlos. Los casos de uso son un mecanismo para ayudar a mantenerlo simple y entendible
para todo el personal involucrado. De manera informal, son historias del uso de un sistema para
alcanzar los objetivos.

Casos de uso y valor añadido

 Actores: es algo con comportamiento

 Escenario: Secuencia especificada de acciones e interacciones entre los actores y el
sistema objeto de estudio; también se denomina instancia de caso de uso.
 Caso de uso: Colección de escenarios con éxito y fallo relacionados, que describe a los
actores utilizando un sistema para satisfacer un objetivo.

Casos de uso y requisitos funcionales

 Los casos de uso son requisitos: ante todo son requisitos funcionales que indican qué hará
el sistema. Los casos de uso son documentos de texto, no diagramas, aunque, UML define
un diagrama de casos de uso para ilustrar los nombres de casos de uso y autores y sus
respectivas relaciones.

Tipos de casos de uso y formatos

Los casos de uso de caja negra son la clase más común y recomendada; no describen el
funcionamiento interno del sistema, sus componentes y diseño, sino que se describe el
sistema en base de las responsabilidades que tiene.

Tipos de formalidad

 Breve: resumen conciso de un párrafo, normalmente del escenario principal con éxito.
 Informal: formato de párrafo en un estilo informal. Múltiples párrafos que comprenden
varios escenarios.
 Completo: el más elaborado. Se escriben con detalle todos los pasos y variaciones y hay
secciones de apoyo como precondiciones y garantías de éxito.

Explicación de las Secciones de un caso de uso

Prólogo: Son posibles muchos elementos opcionales en el prólogo. Sitúe al principio solo los
elementos que son importantes que se lean antes del escenario principal de éxito.

Actor principal: el actor principal que recurre a los servicios del sistema para cumplir un objetivo.

Personal involucrado y lista de intereses: Sugiere y delimita qué es lo que debe hacer el sistema.

Precondiciones: Establecen lo que siempre debe cumplirse antes de comenzar un escenario en el

caso de uso. Las precondiciones NO se prueban en el caso de uso, sino que son condiciones que se
asumen que son verdad

Las garantías de éxito (postcondiciones): Establecen qué debe cumplirse cuando el caso de uso se
completa con éxito. La garantía debería satisfacer las necesidades de todo el personal involucrado.
Escenario principal de éxito y pasos (flujo básico) Describe el camino de éxito típico que satisface
los intereses del personal involucrado. El escenario recoge los pasos, que pueden ser de tres tipos:

1. Una interacción entre actores.

2. Una validación (normalmente a cargo del sistema)

3. Un cambio de estado realizado por el sistema (por ejemplo, registrando o modificando algo)

Extensiones (o flujos alternativos) Las extensiones son muy importantes. Indican todos los otros
escenarios o bifurcaciones, tanto de éxito como de fracaso.

Requisitos especiales: Son los requisitos no funcionales, atributos de calidad o restricciones que se
relacionan de manera específica con un caso de uso y se deben recoger en el caso de uso.

Lista de tecnologías y variaciones de datos: Se sitúan las variaciones de datos y las tecnologías
que se usan para llevarlas a cabo.

3. Diagramas de caso de uso

Es una representación del contexto de un sistema, conforma un buen diagrama de contexto,

porque muestra los límites de un sistema y lo que permanece fuera de él. Funciona como
herramienta de comunicación que resume el comportamiento de un sistema y sus actores

“Los casos de uso son requisitos funcionales que indican que hará el sistema. Estos se
representan en documentos de texto. El diagrama de casos de uso es una descripción de las
actividades que se deben realizar para llevar a cabo algún proceso. Estos se representan en
diagramas.”

ACTORES Es cualquier cosa con comportamiento, incluyendo el propio sistema que se está
estudiando cuando solicita los servicios de otros sistemas. Los actores no son solamente roles que
juegan personas, sino también organizaciones, software y máquinas. Existen 3 tipos de actores:

 Actor Principal: Tiene objetivos de usuario que se satisfacen mediante el uso de los
servicios del SuD (System Under Discussion). Por ejemplo, el cajero. Resulta
importante identificarlo ya que es de utilidad para encontrar los objetivos de
usuario, los cuales dirigen los casos de uso.
 Actor de Apoyo: Proporciona un servicio al SuD. El servicio de autorización de pago
es un ejemplo. Normalmente se trata de un sistema informático, pero podría ser
una organización o una persona. Se identifica para clarificar las interfaces externas y
los protocolos.
 Actor Pasivo: Está interesado en el comportamiento del caso de uso, pero no es principal ni
de apoyo. Por ejemplo, la agencia tributaria del gobierno. Se identifica para asegurar que
todos los intereses necesarios se han identificado y satisfecho. Los intereses de este tipo de
actores algunas veces son sutiles o es fácil no tenerlos en cuenta, a menos que sean
identificados explícitamente.
 4. Diagrama de Secuencia del Sistema
Un diagrama de secuencia es un artefacto creado de manera rápida y fácil., que muestra los
eventos de entrada y salida relacionados con el sistema que se está estudiando. Muestra, para un
escenario especifico de un caso de uso, los eventos que generan los actores externos, el orden y
los eventos entre los sistemas.

BENEFICIOS:

- Representa los detalles de un caso de uso UML

- Planifica y comprende la funcionalidad detallada de un escenario actual o futuro
- Ve como los objetos y componentes interactúan entre si hasta completar un proceso.

ELEMENTOS:

 Objetos: Se colocan en la parte superior del diagrama, de izquierda a derecha, la línea

punteada que se desprende del rectángulo se la denomina línea de vida y junto con
ella aparece un pequeño rectángulo llamado activación.

 Mensajes o estímulos: Línea continua que termina con una punta de flecha. Esta pasa
de una línea de vida de un objeto a otro.

 Mensaje simple: Representa la transferencia de un control a otro.

 Mensaje síncrono: Mensaje que necesita una respuesta antes que el remitente
continúe.

 Mensaje asíncrono: Mensaje que no necesita de una respuesta antes que el remitente
continúe.

 Tiempo: Representado por una progresión vertical. Se inicia en la parte superior hasta
la parte inferior del diagrama.
 Ejemplo de DSS (Diagrama de Secuencia del Sistema):
En este ejemplo se muestra el escenario principal de éxito del caso de uso Procesar Venta. Se
indica que el cajero genera los eventos del sistema crearNuevaVenta, introducirArticulo,
finalizarVenta y realizarPago.

ELEMENTOS Y LÍMITES DEL SISTEMA

Para identificar los eventos del sistema, es necesario tener en claros los límites del sistema. Por lo
que tiene que ver con el desarrollo del software, el límite del sistema normalmente se elige para
que el sistema de software sea propio.

GLOSARIO

Es una lista de términos relevantes y sus definiciones. Es habitual que un término, técnico o propio
del dominio, se utilice de forma distinta por diferentes personas.
El objetivo no es recoger todos los posibles términos, sino aquellos que no están claros, son
ambiguos o que requieren algún tipo de elaboración relevante.

DICCIONARIO DE DATOS

En el UP, el glosario también juega el rol de diccionario de datos, un documento que recoge los
datos sobre los datos, es decir, un metadato. Durante la fase de inicio, el glosario debe ser un
documento sencillo de términos y descripciones. Durante la elaboración, podría ampliarse a un
diccionario de datos.