Universidad Privada Telesup

Escuela Profesional de Ingeniería de Sistemas

Curso de Modelamiento de Datos

Sesión 1: Sistemas de Base de Datos

Requerimientos del Sistema

Ing. Ivan Crispin Sanchez

1
 AGENDA
PRIMERA PARTE
 Sistema.- Sistema de Información, conceptos.
 Introducción a los Sistemas de Gestión de Base de Datos
- Evolución, Ciclo de Vida
- Modelo de Datos,
- Usuarios de BD, Lenguaje SQL, Características,
- Arquitectura, Diseño de una BD

SEGUNDA PARTE
 Requerimientos.- Características, tipos de requerimientos.
 Proceso de determinación de requerimientos.- Fases.
 Metodología para la determinación de Requerimientos
 PARTE I
TEMAS
PRELIMINARES
 ..
Es un conjunto de elementos interrelacionados
formando un todo, que buscan alcanzar un
conjunto de objetivos.

Sistemas naturales
Sistema planetario solar
Sistema circulatorio humano
Clasificación
de Sistemas Sistemas hechos por el hombre
Sistema eléctrico interconectado del sur
Sistema de Contabilidad
Conjunto de componentes interrelacionados que permiten capturar, almacenar, procesar y distribuir
la información para apoyar la toma de decisiones y el control en una organización.

MEDIO AMBIENTE

CLIENTES PROVEEDORES
ORGANIZACION

COMPETIDORES
SISTEMA DE INFORMACION
ENTES DEL ESTADO

Procesamiento
Entrada de Salida de la
clasificación
datos ordenamiento
información
cálculos

Retroalimentación

ACCIONISTAS
 No es lo mismo el cálculo de notas de un
PRECISA alumno que las transacciones bancarias a nivel
de empresas multinacionales

La información resulta oportuna si esta

OPORTUNA disponible en el momento requerido.

Ha de ser comprensible e importante. El

SIGNIFICATIVA volúmen mostrado debe ser lo justo.

Los resultados obtenidos deben parecerse a lo esperado

COHERENTE y la relación entre ellos debe ser lógica

SEGURA Debe estar protegida contra daños físicos, errores lógicos

o de accesos no autorizados.
SI
MENOR MAYOR

MAYOR Cantidad de Cantidad de MENOR

información información utilizada
procesada y en la toma de
generada decisiones

Procesamiento de la Uso de la
información información
1. Aplicaciones con manejo de datos independiente
( Sistema de Archivos )

Cada aplicación recurre a archivos separados.

2. Gestión centralizada
( Sistema de Bases de Datos )

Datos centralizados y compartidos por todas las

aplicaciones
 Aplicaciones con Manejo de Datos Independiente

Archivo de cuentas corrientes Aplicación 1 Sistema

Num. Cliente nombre cliente DatosCuentaCorriente
de
2056 juan pérez ........ ........ ....... .......
Archivos
Archivo de Ahorros
Num. Cliente nombre cliente Datos de Ahorros redundancia
2056 juan pérez ........ ........ ....... .......

Aplicación 2 Aplicación 3

inconsistencia Archivo de prestamos

Num. Cliente nombre cliente Datos de Prestamos
2056 juan pérez ........ ........ ....... .......

 Cada aplicación recurre a archivos separados.

¿Cómo funcionaría un Banco bajo este criterio?
Archivos separados según tipo de operaciones bancarias y áreas funcionales: cuentas corrientes, ahorros y prestamos,..
Ejemplo: Si Juan Pérez es un cliente del Banco y tiene cuenta corriente, cuenta de ahorros y un préstamo que
actualmente esta pagando, los datos concernientes a Juan, estarían repetidos en los tres archivos, cada uno de los
cuales se actualiza con programas diferentes.
 Gestión Centralizada de Datos
Aplicación 1

Archivo de Clientes
Num. Cliente nombre cliente Datos de Datos de
Cuentas Cuentas de Datos de
Corrientes Ahorros Prestamos
Aplicación 3

2056 juan pérez

Aplicación 3
Archivo de
Datos de
cuentas Archivo de Datos de
Cuentas préstamos
corrientes Préstamos
Corrientes

Enfoque
Archivo de
Cuentas de
Datos de
cuentas de
de Bases
ahorros
Ahorros de Datos

Usando el ejemplo anterior:

- En este caso se establece un solo archivo de clientes para las tres cuentas.
- Se crea un archivo para cada actividad bancaria: Cuenta corriente, Cuenta de ahorros y Prestamos.
- Ya no se registran los datos del cliente, solo se hace referencia a ellos.
- Los datos son compartidos por todas las aplicaciones.
Asi por ejemplo es posible transferir dinero entre una cuenta y las otras, o preparar un solo estado mensual para las tres
cuentas de un cliente o de todos los clientes.
 Alto nivel de redundancia
Un mismo dato puede estar repetido en diferentes archivos.
 Riesgo de inconsistencias
Las diversas copias de los mismos datos pueden no coincidir (por ejemplo el cambio
de dirección de un cliente)
 Uso excesivo de recursos humanos
Una alta proporción de recurso humano, se dedica a actividades de mantenimiento de
software.
 Las aplicaciones dependen de los archivos
Si se hacen cambios en los formatos de archivos, también deben modificarse los
programas( falta de independencia ).
 Los archivos pueden ser incompatibles
Un archivo en Cobol no es igual que un archivo hecho en C++. Los archivos no
pueden combinarse o compararse.
 Datos separados y aislados
En ocasiones es necesario obtener información de dos o más archivos.
 Costos elevados
Cambios a las aplicaciones muy costosos, un cambio trivial provoca una reacción en
cadena de otros cambios. Almacenamiento redundante incrementa los costos.
 Tendencia a crear más y más archivos
Proliferación constante de nuevos archivos y por tanto dificultad en su actualización.
 … Datos Independientes

Dpto. Personal Dpto. Contabilidad

Dpto. Ventas

Clientes Ventas Cuentas

Empleados

Inventario

… Centralizado
Personal
BASE DE DATOS

Empleados
Ventas SGBD Clientes
Ventas
Inventario
Contabilidad Cuentas
 INTRODUCCIÓN
A LOS SISTEMAS DE BASE DE
DATOS

CONCEPTOS INICIALES

Resultados
BASE
Internet Requerimientos
DATOS
 Esquema General de Uso de una Base de Datos

Internet

ASP
BASE PHP
DATOS JAVA
.NET
Applicación
Cliente SQL

VisualBasic SQL Server

PowerBuilder ORACLE
VisualFox INFORMIX
Delphi DB2
Modelo Datos
 ¿ Qué es una Base de Datos (BD) ?

 Un conjunto de información organizada para cumplir las necesidades

de información de los usuarios de una empresa.

 Almacena eventos individuales de las transacciones que se generan a

partir de un Proceso de Negocios determinado

 Colección compartida de datos sin redundancias innecesarias,

almacenados en un soporte informático no volátil, independiente de
los programas que los usen, interrelacionados y estructurados de
acuerdo a un modelo de datos con el objeto de atender todas las
necesidades de los diferentes usuarios.
 Sistema Gestor de Base de Datos (SGBD)
Un software ó conjunto de programas que permiten crear y mantener una base de datos, asegurando su
integridad, confidencialidad y seguridad.

Los SGBD permiten:

- Definir una BD: especificar tipos, estructuras y restricciones de datos
- Construir la base de datos: guardar los datos en algún medio controlado por el mismo SGBD
- Manipular la base de datos: realizar consultas, actualizarla, generar informes.
- Control de la Redundancia
- Control de accesos
- Manejo de restricciones de integridad

Características que hacen la Diferencia entre SGBD

- Rendimiento
- Funcionalidad/Inteligencia
- Distribución/Integración
 Evolución de las Bases de Datos
CODASYL SBD. Relacionales
1971 -SQL
Prog. Relacional - SGBD (DB2, ORACLE)
Ordenadores Ted Codd M-ER
digitales SBD.estruct. Chen (1976)
Jerárquica
Archivos NAA + IBM
Secuenciales SBD SBD
SBD en Red
S.O. Charles relacionales, orientados
Acc.directo modelos a objetos
y secuenc. Bachmann Plataformas
Fortran (G.Electric) orientados a
objetos cliente/servidor

1950 1960 1970 1980 1990 2000

Proyecto APOLO (finales 60´s)

NAA (North America Aviation)  GUAM (General Update Access Method)
Modelo Jerárquico (ARBOL)
IBM ……..  Dispositivos de almacenamiento en serie
(cintas magnéticas)
CODASYL (Conference on Data System Language)
 Modelo de Datos
Conjunto de conceptos para describir la estructura de una base
de datos, es decir, a las entidades involucradas, sus relaciones,
semántica asociada a los datos y restricciones de consistencia.
Los modelos de datos se clasifican :

1. Modelo Jerárquico SGBD de Primera

Nivel Implementación

2. Modelo de Redes Generación

3. Modelo Entidad Relación SGBD de Segunda

Generación
4. Modelo Relacional

Alto Nivel
5. Modelo de Objetos
SGBD de Tercera
6. Modelo Objeto-Relacional Generación
BD. DISTRIBUIDAS, ACTIVAS, ESPACIALES
ORIENTADAS A OBJETOS, ...
Evolución
Líneas de Evolución de las Bases de
Datos

FUNCIONALIDAD/
INTELIGENCIA

RENDIMIENTO

BD

DISTRIBUCIÓN/
INTEGRACIÓN
Líneas de Evolución de las BD
RENDIMIENTO DISTRIBUCIÓN INTELIGENCIA

 BD PARALELAS  BD DISTRIBUIDAS  BD ACTIVAS

 BD EN TIEMPO  BD FEDERADAS  BD DEDUCTIVAS

REAL  BD ORIENTADAS A
 MULTIBASES DE DATOS OBJETOS
 BD EN MEMORIA
PRINCIPAL  BD MÓVILES  BD MULTIMEDIA
 BD TEMPORALES
 BD “WEB”
 BD SEGURAS
 BD DIFUSAS
Algunos Ejemplos de Aplicaciones con BD
 Lenguaje de las Base de Datos
Los SGBD emplean como lenguaje estándar el SQL.
El SQL es un lenguaje Declarativo que permite la
definición, construcción y la manipulación de datos.
Tipos de sentencias:
- DML (Data Manipulation Languaje)
- DDL (Data Definition Languaje)
 Características de los SGBD
Naturaleza autodescriptiva de Control de Redundancia
Queda minimizada o controlada la repetición del
los SGBD mismo dato en diferentes archivos. De esta forma
Diccionario de Datos o Catalogo (Metadatos ).
ya no se desperdicia espacio de almacenamiento
Aquí va la información de la estructura de cada
ni se producen inconsistencias.
archivo, el tipo y formato de los datos elementales
y las diversas restricciones que se aplican a nivel
de columna o de archivo. Restricción de accesos no
autorizados
Independencia respecto a Niveles de acceso: Manejo de roles y privilegios
por cuentas y/o grupo de cuentas.
programas y datos
Abstracción: Las estructuras de los archivos se
almacenan en el diccionario de datos del SGBD y Restricciones de Integridad
no en los programas. Ejemplos: definir un tipo de dato (entero o String),
las edades de colegiales (13 a 17), que un valor
sea único (código de trabajador ), etc
Manejo de múltiples vistas de
los datos Respaldo y Recuperación
Cada usuario puede tener una vista ó perspectiva
Se recuperan ante fallas de hardware o de
diferente.
software. La idea es que después de una caída,
se restaure la BD al estado en el que estaba.
Control de Concunrrencia
El SGBD incluye software de control de
concurrencia (gestor de transacciones) para
asegurar que cuando varios usuarios intenten
actualizar los mismos datos, lo hagan de manera
sincronizada.
 Arquitectura de una BD
(Niveles de abstracción)

NIVEL EXTERNO Es conocido como el nivel de vistas de usuario.

Cada vista de usuario se conoce como subesquema o esquema externo, donde

cada uno de ellos describe alguna parte de la base de datos. Oculta al usuario
toda la base de datos restante.

NIVEL CONCEPTUAL A este nivel se tiene el esquema de la base

de datos, que describe la estructura de toda la base de datos. El esquema
conceptual oculta los detalles de las estructuras físicas de almacenamiento y
se concentra en describir entidades, tipos de datos, relaciones, operaciones y
restricciones

NIVEL INTERNO o FISICO tiene un esquema interno o físico.

Describe como se almacenan realmente los datos y los caminos de acceso a la
base de datos.
 Arquitectura de una BD
La BD presenta una arquitectura de tres niveles:

Usuarios finales

NIVEL
EXTERNO Vista
Externa 1
Vista
Externa 2 ... Vista
Externa n

Correspondencia
externa/conceptual
NIVEL
ESQUEMA CONCEPTUAL
CONCEPTUAL
Correspondencia
conceptual/ interna
detalle

NIVEL ESQUEMA INTERNO

INTERNO

BD ALMACENADA

Correspondencia : proceso de transformar pedidos y respuestas

de un nivel a otro.
 Tipos de Usuarios de Base de Datos

Programadores
Escriben aplicaciones, donde incrustan comandos DML para interactuar con el sistema

Usuarios normales
Interactúan con el sistema mediante el uso de aplicaciones que han sido escritos por informáticos.

Usuarios sofisticados
Interactúan con el sistema creando consultas con un lenguaje de consulta, las cuales entran al
procesador de consultas que transforma las instrucciones DML, para ser entendidas por el gestor de
almacenamiento.

Administrador de la Base de Datos

Crea BD, define métodos de acceso, concede autorizaciones, etc
 Vista de los Componentes de un SGBD
Usuarios Programadores de Usuarios Administrador de
normales aplicaciones sofisticados Base de Datos
Usuarios

Interfaces de Programas de Esquema de

Consulta
aplicaciones aplicacion base de datos

Precompilador compilador Interprete

del DML del DML del DDL
Procesador Sistema
de
Código objeto de Consultas
de gestión
las aplicaciones Motor de evaluación de de base de
consultas datos

Gestor de Gestor de memoria intermedia

transacciones Gestor de
almacenamiento
Gestor de archivos

Archivos de datos estadística

indices Diccionario de datos

 ¿Cómo Diseño la Base de Datos ?

Interacción con el sistema

Usuarios Sistema

BASE
Requerimientos DATOS
Etapas para el Diseño de una Base de Datos

Requerimientos de Información

(I)
DISEÑO CONCEPTUAL

(II)
DISEÑO LOGICO

DISEÑO FISICO DE LA BASE DE DATOS

BASE
(III)
DATOS
Etapas para el Diseño de una Base de Datos
Usuarios y
Requerimientos de Información
Clientes

DISEÑO CONCEPTUAL

Cliente Producto Documentos

DISEÑO LOGICO

RED RELACIONAL OO

DISEÑO FISICO DE LA BASE DE DATOS

ORACLE SQL Server ACCESS DB2 MYSQL INFORMIX

 Los Protagonistas

Diseñador Desarrollador Profesional de

Base de Datos
Arquitecto
Probador

Proyecto
Analista de Jefe de
Negocio Proyectos
Sistema de
Información
Ciclo de Vida del Desarrollo de
Sistemas
FASES ACCIONES

Planeamiento Requerimientos Iniciales

Estudio de Factibilidad

Requerimientos de usuario
Análisis Evaluación del sistema actual
Diseño Lógico del Sistema

Diseño Detalle de las especificaciones

del Sistema

Codificación, testing, ajustes.

Desarrollo Instalación, Tunning

Evaluación
Mantenimiento Mantenimiento: evolutivo y
correctivo
Ciclo de Vida de la Base de Datos
FASES ACCIONES
Análisis de la Situación de la Compañía
Definiciones Identificación de Problemas y Restricciones
Iniciales Definición de Objetivos
Determinación del Alcance
Diseño Conceptual
Diseño de la BD Selección del SGBD ó DBMS
Diseño Lógico y Físico
Instalación de la BD
Implementación Creación de la BD
Ingreso y Conversión de Datos

Testing de BD
Testing y Afinamiento de BD
Evaluación Evaluación de la BD y sus Aplicaciones

Operación Flujos de Información

Mantenimiento y Aplicación de Cambios

Evaluación Cambios Asociados
 Evaluación del Aprendizaje
 ¿Cuál es la relación entre BD y SGBD?

 ¿Cuáles son las etapas del diseño de una BD?

 ¿A partir de que elaboramos una BD?

 ¿Los datos del negocio se almacenan en el Diccionario

de Datos?

 ¿Cuál es el mejor SGBD?

 ¿Quien es el especialista encargado de administrar la

BD? ¿será necesario?

 ¿Por qué es importante una BD?

 PARTE II
Definición de
Requerimientos del
Sistema
 ..
Condición, Característica o Restricción que
debe tener o cumplir un sistema o
componente de un sistema para satisfacer
un contrato, norma, especificación u otro
documento formalmente impuesto..

Ingeniería de Requerimientos. 1. Determinación de

Disciplina de la ISW que se encarga requerimientos.
de definir los requerimientos del
sistema. Fases: 2. Análisis de
requerimientos.
 Características de los Requerimientos

Características de los requisitos para ser de alta calidad:

 Correctos, sin errores.
 Consistentes.
 No ambiguos.
 Son completos*
 Son realistas. Puede el sistema hacer lo que el cliente desea.
 Los R. describen algo necesario para el cliente.
 Verificables.
 Son rastreables. Trazables, el origen de cada requisito está claro y se
posibilita la referencia de cada uno de estos requisitos en desarrollos futuros o
incrementos de la documentación.
 Tipos de Requerimientos
1. R. Funcionales. Una función es algo que hará el sistema.
Describen una interacción entre el sistema y su ambiente.

2. R. No Funcionales. Describen restricciones que limitan las

opciones de solucionar el problema. Restricciones cuantitativas o
precisión.

3. Seudorequerimientos. (de implementación).-

R. impuestos por el cliente que restringen la implementación del
sistema.
1. REQUERIMIENTOS FUNCIONALES
– describen las interacciones entre el sistema y su entorno (usuarios u otros sistemas),
sin tener en cuenta cuestiones de implementación.
– se estudian y representan en el Modelo de Casos de Uso

Requerimientos Funcionales de GeHoWeb.

GeHoWeb es un sistema para la gestión de horarios de la Escuela Superior de Ingeniería
Informática (ESEI). El administrador del sistema, que se tendrá que identificar al acceder al
mismo, es el encargado de introducir las asignaturas que se imparten en cada curso, así
como los datos del encargo de docencia anual (grupos de teoría y práctica de cada
asignatura).

Además, el sistema permite introducir los datos de las aulas de teoría (ubicación y aforo) y
de prácticas (ubicación, sistemas operativos, software,...).

La configuración del horario se lleva a cabo directamente sobre una plantilla horaria
semanal, en la que cada casilla representará una hora en un determinado día de la
semana. Cuando el administrador pulsa esa casilla se mostrarán las asignaturas del curso
que se esté configurando en ese momento. Una vez escogida las asignaturas se mostrarán
los grupos de teoría y práctica a los que todavía no se les ha asignado un horario. Al
escoger un grupo se muestran las aulas disponibles (si es un grupo de teoría) o los
laboratorios que cumplen las restricciones de sistemas operativos establecidas para esa
materia y que no están ocupados a esa hora.

El sistema podrá ser consultado por cualquier usuario, que podrá consultar el horario de
una asignatura, un curso, o de un aula o laboratorio concretos.
Diagrama de Casos de Uso

Gestionar asignaturas

Usuario externo
Gestionar profesores
Administrador

Consultar horarios
Introducir encargo de docencia

Modelo de Casos de Uso de

Gehoweb (gestión de horarios)
Gestionar aulas y laboratorios

Gestionar horarios
2. REQUERIMIENTOS NO FUNCIONALES
– describen aspectos del sistema visibles por el usuario que no se relacionan en forma
directa con el comportamiento funcional del sistema.
– se recogen en los casos de uso con los que están relacionados, o en la Especificación
Complementaria.
– en el Glosario se agrupan y clarifican los términos que se utilizan en los requisitos
– ejemplos: restricciones en el tiempo de respuesta, precisión de los resultados,...

Requerimientos No Funcionales de GeHoWeb.

La tasa de disponiblidad de Gehoweb debe ser de un 99%.

El sistema debe tener una interfaz de uso intuitiva y sencilla,

complementada con un buen sistema de ayuda (la administración puede
recaer en personal con poca experiencia en el uso de aplicaciones
informáticas).

El sistema debe disponer de una documentación fácilmente actualizable

que permita realizar operaciones de mantenimiento con el menor esfuerzo
posible.
 Requerimientos No Funcionales

requerimientos
no funcionales

requerimientos requerimientos requerimientos

del producto organizacionales externos

usabilidad eficiencia fiabilidad portabilidad interoperabilidad éticos legislativos

rendimiento espacio entrega implementación estándares privacidad seguridad

fuente: Ingeniería de Software, I. Sommerville, p. 102

 tipos de requerimientos
3. REQUERIMIENTOS DE IMPLEMENTACIÓN
– son necesidades del cliente que restringen la implementación (por
ejemplo, lenguaje de programación, plataforma hardware, servidor
de páginas web, libro de estilo,...)

Requerimientos de implementación de GeHoWeb.

Con el fin de ajustarse a la arquitectura de la intranet actual de la ESEI,
GeHoWeb debe desarrollarse como un servicio web, accesible desde cualquier
navegador Explorer 5.0, Netscape 5.0 o superior, y estará instalado en un
servidor Windows 2000, actuando como servidor de páginas web Internet
Information Server. La base de datos a utilizar será SQL Server 2008

La interfaz de usuario debe de ajustarse a las características de la web de la

ESEI, dentro de la cual estará integrado Gehoweb.

Además, en el desarrollo de GeHoWeb deberán tenerse en cuenta las

directrices de política de seguridad recomendadas por el Grupo de Seguridad
de la ESEI.
 Determinación de
Requerimientos
Especificación
Sistema
Determinación
Requerimientos

Validación Fases
Obtención Documentación

Cliente/Usuario
Desarrolladores

1.Obtención de 1.Documentación de requerimientos. Los requisitos 1.Validación. Es el

requerimientos. Captura de han de reflejarse en un documento como registro del proceso por el cual
requerimientos con el objetivo proceso de captura con el objetivo de fijar una base se determina si la
de definir que es el sistema. para clientes y desarrolladores. especificación es
 Participantes del Proceso
 Supervisores del contrato, sugieren hitos de control y
cronogramas que disciplinan el desarrollo del sistema.
 Clientes y usuarios, deben comprender y trasmitir
adecuadamente los requerimientos, para del sistema.

 Los gerentes de negocios, para calibrar el impacto de construir

y utilizar el sistema.
 Los diseñadores que usarán los requerimientos como base
del desarrollo.
 Los verificadores encargados de las sesiones de prueba
destinadas a asegurar que el sistema cumple los
requerimientos.
 Captura de Requerimientos.- Técnicas
Aplicadas

1. Primera tarea
2. Fase critica. Colaboración de grupos heterogéneos.

Desarrollador Identifc.
Cliente/Usuario Actores

Actividades
Obtención Captura de
Requer. Requer.
Identifc.
Funcionalidad
 Captura de Requerimientos.-
Objetivos de la captura de requerimientos (OO):
• Identificación de actores. Entidades externas que interactúan con el sistema.
Como abstracción de papeles.

• Identificar la funcionalidad a la que tiene acceso cada actor.

– Identificación de escenarios. Descripción concreta, enfocada e informal de una sola
característica del sistema desde el punto de vista de un solo actor.
– Descripción de casos de uso.
Administración de la Captura de Requerimientos
• Fuentes:
– Documentación.
– Personas con puntos de vista necesarios.
• Técnicas 1.Dirección general
– Cuestionarios 2.Usuarios finales y dirección
– Entrevistas 3.Clientes
4.Proveedores
– Talleres 5.El equipo operativo
– Prototipos 6.El equipo de mantenimiento
7.Asesoría jurídica u otros expertos.

Importante contar con más de una

persona por cada punto de vista.
 Captura de Requerimientos.- Técnicas
Aplicadas

1. Elaboración de cuestionarios. Se recopila datos estructurados

2 Modalidades:
 Mediante Lista de cuestiones concretas y de respuesta cerrada.
¿Cuánto lleva operando el actual sistema de facturación (en años)?.

 Mediante índices. Baja Alta

¿Importancia de estos
Velocidad 1 2 3 4 5
factores para adquirir
un OS? Usabilidad 1 2 3 4 5
 Mediante preguntas Flexibilidad 1 2 3 4 5
para recoger información abierta
• Se formula una pregunta abierta.
¿Cuál son para usted los factores principales en la selección de proveedor de servicios de
Internet”
• Útiles para obtener una información inicial sobre el área
 Técnicas Aplicadas
2. Entrevistas.
 Permiten obtener toda la información posible de la visión que el
entrevistado tiene de los requisitos

 Depende de la habilidad del entrevistador para crear un clima de confianza

 Es aconsejable 2 entrevistadores (una conduce la entrevista el otro supervisa la
interacción y toma notas):
• Mejora la gestión del tiempo.
• Beneficia la supervisión.

 Es aconsejable emplear tanto preguntas abiertas como cerradas:

• Abiertas: Suelen comenzar por “qué”, por qué” y “como” y exigen respuesta detallada por el
entrevistado.
• Cerradas: Aquellas con un Intervalo específico de respuesta.

 El entrevistador debe centrar la entrevista cuando esta se desvía.

 El entrevistador debe evitar emitir juicios de valor para no influir.
 Técnicas Aplicadas
2. Entrevistas.

• Análisis de resultados de la entrevista:

– Si se ha utilizado como marco un cuestionario, este se utilizará como context
e el análisis.

– Si la entrevista no es estructurada, el resultado se detallará como informe.

Esquema de resumen de entrevista

Nombre entrevistado.
Puesto de trabajo y breve descripción.
Punto de vista que representa.
Fecha, hora y lugar de la entrevista
Resumen de puntos principales
Doc´s. de referencia
Otros contactos.
 Técnicas Aplicadas
3. Talleres.
 Reunión de partes interesadas.
 Sesiones intensivas y estructuradas concentradas en uno o dos días.
 Es preciso una importante preparación previa:
– Definir con los participantes la finalidad del taller.
– Facilitarles información histórica.

 El taller ha de ser dirigido por un experto para:

– Garantizar que todo los participantes aportan sus puntos de vista.
– No se desvían del propósito del taller.
 Se genera un informe para documentar los resultados y base de la
especificación de requisitos.
 Tiene la ventaja de reunir a los participantes pudiendo debatirse las cuestiones
más controvertidas y resolver así requisitos aparentemente divergentes
satisfaciendo a las partes.
 Técnicas Aplicadas
4. Modelado de Proceso.
 Método de análisis vertical (up-dow) para establecer la composición
funcional del área para la cual se propone el sistema.

Proceso
Funciones Funciones Actividades

Actividades
Funciones Actividades
Actividades
Actividades
 Técnicas Aplicadas

4. Modelado de Proceso.
 Se descompone el sistema en procesos “atómicos” que no admitan mas
divisiones.

 La derivación de procesos se realizará mediante técnicas de captura de

requisitos.

 Los usuarios revisarán el modelo en cada desagregación.

– Permite correcciones antes de seguir con una mayor elaboración
– Permite identificar procesos de bajo nivel duplicados, permitiendo
una simplificación del modelo.
 Técnicas Aplicadas

5. Prototipado.
 Un prototipo es un modelo de sistema eventual que se puede utilizar para
demostrar las características de lo que el sistema puede ofrecer. 2 métodos: P.
desechable, P. evolutivo.

 Los prototipos pueden usarse para:

• Demostrar la viabilidad del sistema. Se implanta parte del sistema para:
– Comprobar el comportamiento funcional.
– Análisis de rendimiento.

• Aclarar los requisitos del usuario.

 Documentación de Requerimientos.-
Técnicas Aplicadas
• Sirve de base para la futura operativa del proyecto tanto para clientes
como para desarrolladores. (debe ser significativo para ambos)

• Así se generan dos documentos:

– Doc. de requisitos del usuario/Definición de requerimientos
– Doc. de requisitos del sistema/Especificación de requerimientos.
 Documentación de Requerimientos
• Sirve de base para la futura operativa del proyecto tanto para clientes
como para desarrolladores. (debe ser significativo para ambos)
• Así se generan dos documentos:
– Doc. de requisitos del usuario/Definición de requerimientos
– Doc. de requisitos del sistema/Especificación de requerimientos.

E. Requisitos del Usuario E. Requisitos del Sistema

Introducción
1. Alcance. Área de aplicación de los requisitos.
2. Definiciones.
3. Historial.
4. Descripción de alto nivel. Esquema del
problema.
5. RF (Forma atómica y con identificador)
6. RNF (Forma atómica y con identificador y
vinculados a los funcionales que soportan)
7. Restricciones específicas
Introducción
1. Alcance. Relación con otros sistemas
2. Definiciones.
3. Historial. Infraestructura existente
4. Descripción de alto nivel. Esquema del
problema.
5. RF (Forma atómica y con identificador)
6. RNF (Forma atómica y con identificador y
vinculados a los funcionales que soportan)
7. Restricciones específicas
 Validación de Requerimientos
• La determinación de requerimientos tiene 2 propósitos:
– El acuerdo entre clientes y desarrolladores sobre qué debe ser el sistema.
– Proporcionar a los diseñadores pautas para el desarrollo.
• Proceso por el cual se determina si la especificación del sistema es
consistente, es decir si los requerimientos satisfarán las necesidades del
cliente. 2 pasos (trazabilidad):
– Se asegura que cada especificación del sistema pueda ser rastreada hasta su
requerimiento en el documento de definición.
– Se chequea la definición comprobando que cada requerimiento es
rastreable hasta la especificación.
• La técnica más utilizada y simple son las reuniones de revisión.
• Se examinan los requerimientos por parte de:
– Representantes del cliente:
• Operadores del sistema.
• Operadores que preparan las entradas
• Operadores los que utilizan las salidas
• Gerentes de estos empleados.
– Representantes del desarrollador:
• Equipo de diseño
• Equipo de pruebas, y gestión de configuración
 Conociendo la Organización. Modelo
del Negocio

Qué es un modelo de Negocio ?

Sirve para comprender el conjunto de proceso de

negocios que tiene lugar dentro de una empresa,
como paso previo a establecer los requisitos del
sistema.
Ejemplo de un Modelo de Negocio.
Qué es un Proceso de Negocio

• Un proceso de Negocio es un conjunto de

actividades que desarrolla la empresa con
miras a cumplir sus objetivos.
• Los procesos de negocio están restringido por
la reglas de negocio
– Determinan políticas y estructura de información.
– Permiten o no realizar operaciones dentro del
proceso
Ejemplos de Proceso de Negocios

• La empresa se dedica a la
comercialización de productos
• Procesos de Negocio
– Atender Pedidos
– Realizar Cobranzas
– Controlar Almacenes
– Realizar compras
El Proceso de Negocios Atender Pedidos

• Acerca de Atender Pedidos

– Captar pedido del cliente Registrar Pedido
– Generar Documento de Venta Entregar producto

Pedido

Item

Fact-BV

Reparto
Mercadería
65
 Evalúe los requerimientos ….

• Forme Grupo de 3 ó 4 alumnos

• Identifique una empresa conocida e importante.
Identifique la línea de negocio, estime el nro.
aproximado de clientes y/o empleados que esta tiene.
• Identifique un aplicativo ó sistema principal (que requiera o
ya tenga esta empresa) y haga una lista de sus requerimientos
de información; así como sus restricciones.
<ANALISIS>
• Identifique a los actores del sistema.-
• Liste los requerimientos de Información y/o
restricciones (apóyese en un diagrama de casos de uso)
• ¿ Que características deberá tener el SGBD ?
Ejemplos:
• Telefónica Móviles.-
Sistema Comercial.- Módulo de Venta de Equipos

• Transportes Movil Tours.-

Sistema de Venta de Pasajes

• Universidad Particular César Vallejo.-

Sistema Académico.- Módulo de Matriculas
Si A es igual al éxito, entonces la formula es:

A=x+y+z

Donde:
 x es trabajo
 y es divertirse
 z es mantener la boca cerrada.

Autor: Albert Einstein.