Este documento presenta la primera parte de una sesión sobre sistemas de base de datos. La primera parte introduce conceptos básicos como sistemas de información, evolución de los sistemas de gestión de base de datos, modelos de datos, usuarios de BD, lenguaje SQL y arquitectura de una BD. La segunda parte cubrirá requerimientos, procesos para determinar requerimientos y metodologías.

1. 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

2. 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

3. PARTE I
TEMAS
PRELIMINARES

4. ..
Es un conjunto de elementos interrelacionados
formando un todo, que buscan alcanzar un
conjunto de objetivos.
Sistemas naturales
Clasificación
de Sistemas
Sistema planetario solar
Sistema circulatorio humano
Sistemas hechos por el hombre
Sistema eléctrico interconectado del sur
Sistema de Contabilidad

5. 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
PROVEEDORES
CLIENTES
ORGANIZACION
ENTES DEL ESTADO
Procesamiento
Entrada de
datos
clasificación
ordenamiento
cálculos
Retroalimentación
ACCIONISTAS
Salida de la
información
COMPETIDORES
SISTEMA DE INFORMACION

6. PRECISA
No es lo mismo el cálculo de notas de un
alumno que las transacciones bancarias a nivel
de empresas multinacionales
OPORTUNA
La información resulta oportuna si esta
disponible en el momento requerido.
SIGNIFICATIVA
Ha de ser comprensible e importante. El
volúmen mostrado debe ser lo justo.
COHERENTE
Los resultados obtenidos deben parecerse a lo esperado
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.

7. SI

8. MAYOR
MENOR
MAYOR
Cantidad de
información
procesada y
generada
Cantidad de
información utilizada
en la toma de
decisiones
Procesamiento de la
información
Uso de la
información
MENOR

9. 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
aplicaciones
y
compartidos
por
todas
las

10. Aplicaciones con Manejo de Datos Independiente
Num. Cliente nombre cliente
2056
juan pérez
Sistema
de
Archivos
Aplicación 1
Archivo de cuentas corrientes
DatosCuentaCorriente
........ ........ ....... .......
Archivo de Ahorros
Num. Cliente
2056
Datos de Ahorros
nombre cliente
juan pérez
redundancia
........ ........ ....... .......
Aplicación 2
Aplicación 3
Archivo de prestamos
inconsistencia
Num. Cliente
nombre cliente
2056
juan pérez
Datos de Prestamos
........ ........ ....... .......
 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.

11. Gestión Centralizada de Datos
Aplicación 1
Archivo de Clientes
nombre cliente
2056
Archivo de
Cuentas
Corrientes
juan pérez
Datos de
cuentas
corrientes
Archivo de
Cuentas de
Ahorros
Datos de
cuentas de
ahorros
Datos de
Cuentas
Corrientes
Datos de
Cuentas de
Ahorros
Archivo de
Préstamos
Datos de
Prestamos
Datos de
préstamos
Aplicación 3
Aplicación 3
Num. Cliente
Enfoque
de Bases
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.

12.  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.

13. … Datos Independientes
Dpto. Personal
Empleados
Dpto. Ventas
Clientes
Ventas
Dpto. Contabilidad
Cuentas
Inventario
… Centralizado
Personal
Ventas
Contabilidad
BASE DE DATOS
SGBD
Empleados
Clientes
Ventas
Inventario
Cuentas

14. INTRODUCCIÓN
A LOS SISTEMAS DE BASE DE
DATOS
CONCEPTOS INICIALES
Resultados
Internet
Requerimientos
BASE
DATOS

15. Esquema General de Uso de una Base de Datos
Internet
BASE
DATOS
ASP
PHP
JAVA
.NET
Applicación
Cliente
VisualBasic
PowerBuilder
VisualFox
Delphi
SQL
SQL Server
ORACLE
INFORMIX
DB2
Modelo Datos

16. ¿ 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.

17. 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

18. Evolución de las Bases de Datos
Ordenadores
digitales
Archivos
Secuenciales
Fortran
1950
SBD.estruct.
Jerárquica
NAA + IBM
S.O.
Acc.directo
y secuenc.
1960
SBD. Relacionales
CODASYL
-SQL
1971
- SGBD (DB2, ORACLE)
Prog. Relacional
M-ER
Ted Codd
Chen (1976)
SBD en Red
Charles
Bachmann
(G.Electric)
1970
SBD
relacionales,
modelos
orientados a
objetos
1980
SBD
orientados
a objetos
Plataformas
cliente/servidor
1990
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)
2000

19. 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 :
2. Modelo de Redes
3. Modelo Entidad Relación
4. Modelo Relacional
5. Modelo de Objetos
6. Modelo Objeto-Relacional
SGBD de Primera
Generación
SGBD de Segunda
Generación
Alto Nivel
Nivel Implementación
1. Modelo Jerárquico
SGBD de Tercera
Generación
BD. DISTRIBUIDAS, ACTIVAS, ESPACIALES
ORIENTADAS A OBJETOS, ...

20. Evolución

21. Líneas de Evolución de las Bases de
Datos
FUNCIONALIDAD/
INTELIGENCIA
RENDIMIENTO
BD
DISTRIBUCIÓN/
INTEGRACIÓN

22. Líneas de Evolución de las BD
RENDIMIENTO
DISTRIBUCIÓN
INTELIGENCIA
 BD PARALELAS
 BD DISTRIBUIDAS
 BD ACTIVAS
 BD EN TIEMPO
REAL
 BD FEDERADAS
 BD DEDUCTIVAS
 MULTIBASES DE DATOS
 BD ORIENTADAS A
OBJETOS
 BD MÓVILES
 BD MULTIMEDIA
 BD EN MEMORIA
PRINCIPAL
 BD “WEB”
 BD TEMPORALES
 BD SEGURAS
 BD DIFUSAS

23. Algunos Ejemplos de Aplicaciones con BD

24. 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)

25. Características de los SGBD
Naturaleza autodescriptiva de
los SGBD
Diccionario de Datos o Catalogo (Metadatos ).
Aquí va la información de la estructura de cada
archivo, el tipo y formato de los datos elementales
y las diversas restricciones que se aplican a nivel
de columna o de archivo.
Independencia respecto a
programas y datos
Abstracción: Las estructuras de los archivos se
almacenan en el diccionario de datos del SGBD y
no en los programas.
Manejo de múltiples vistas de
los datos
Cada usuario puede tener una vista ó perspectiva
diferente.
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.
Control de Redundancia
Queda minimizada o controlada la repetición del
mismo dato en diferentes archivos. De esta forma
ya no se desperdicia espacio de almacenamiento
ni se producen inconsistencias.
Restricción de accesos no
autorizados
Niveles de acceso: Manejo de roles y privilegios
por cuentas y/o grupo de cuentas.
Restricciones de Integridad
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
Respaldo y Recuperación
Se recuperan ante fallas de hardware o de
software. La idea es que después de una caída,
se restaure la BD al estado en el que estaba.

26. 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.

27. Arquitectura de una BD
La BD presenta una arquitectura de tres niveles:
Usuarios finales
NIVEL
EXTERNO
NIVEL
CONCEPTUAL
Vista
Externa 1
...
Vista
Externa 2
Vista
Externa n
Correspondencia
externa/conceptual
ESQUEMA CONCEPTUAL
Correspondencia
conceptual/ interna
NIVEL
INTERNO
ESQUEMA INTERNO
BD ALMACENADA
Correspondencia : proceso de transformar pedidos y respuestas
de un nivel a otro.
detalle

28. 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

29. Vista de los Componentes de un SGBD
Usuarios
normales
Programadores de
aplicaciones
Interfaces de
aplicaciones
Programas de
aplicacion
Precompilador
del DML
Código objeto de
las aplicaciones
Gestor de
transacciones
Usuarios
sofisticados
Consulta
compilador
del DML
Administrador de
Base de Datos
Usuarios
Esquema de
base de datos
Interprete
del DDL
Procesador
de
Consultas
Motor de evaluación de
consultas
Gestor de memoria intermedia
Gestor de
almacenamiento
Gestor de archivos
Archivos de datos
estadística
indices
Diccionario de datos
Sistema
de gestión
de base de
datos

30. ¿Cómo Diseño la Base de Datos ?
Interacción con el sistema
Usuarios
Sistema
Requerimientos
BASE
DATOS

31. 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
DATOS
(III)

32. Etapas para el Diseño de una Base de Datos
Requerimientos de Información
Usuarios y
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

33. Los Protagonistas
Diseñador
Desarrollador
Profesional de
Base de Datos
Arquitecto
Analista de
Negocio
Probador
Proyecto
Sistema de
Información
Jefe de
Proyectos

34. Ciclo de Vida del Desarrollo de
Sistemas
FASES
Planeamiento
ACCIONES
Requerimientos Iniciales
Estudio de Factibilidad
Análisis
Requerimientos de usuario
Evaluación del sistema actual
Diseño Lógico del Sistema
Diseño
Detalle de las especificaciones
del Sistema
Desarrollo
Codificación, testing, ajustes.
Instalación, Tunning
Mantenimiento
Evaluación
Mantenimiento: evolutivo y
correctivo

35. Ciclo de Vida de la Base de Datos
FASES
Definiciones
Iniciales
ACCIONES
Análisis de la Situación de la Compañía
Identificación de Problemas y Restricciones
Definición de Objetivos
Determinación del Alcance
Diseño de la BD
Diseño Conceptual
Selección del SGBD ó DBMS
Diseño Lógico y Físico
Implementación
Instalación de la BD
Creación de la BD
Ingreso y Conversión de Datos
Testing y
Evaluación
Testing de BD
Afinamiento de BD
Evaluación de la BD y sus Aplicaciones
Operación
Flujos de Información
Mantenimiento y
Evaluación
Aplicación de Cambios
Cambios Asociados

36. 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?

37. PARTE II
Definición de
Requerimientos del
Sistema

38. ..
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.
Disciplina de la ISW que se encarga
de definir los requerimientos del
sistema. Fases:
1. Determinación de
requerimientos.
2. Análisis de
requerimientos.

39. 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.

40. 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.

41. 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.

42. Diagrama de Casos de Uso
Gestionar asignaturas
Usuario externo
Gestionar profesores
Administrador
Consultar horarios
Introducir encargo de docencia
Gestionar aulas y laboratorios
Gestionar horarios
Modelo de Casos de Uso de
Gehoweb (gestión de horarios)

43. 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.

44. Requerimientos No Funcionales
requerimientos
no funcionales
requerimientos
del producto
usabilidad
eficiencia
rendimiento
fiabilidad
espacio
requerimientos
organizacionales
portabilidad
entrega
requerimientos
externos
interoperabilidad
implementación
estándares
éticos
privacidad
legislativos
seguridad
fuente: Ingeniería de Software, I. Sommerville, p. 102

45. 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.

46. Determinación de
Requerimientos
Especificación
Sistema
Determinación
Requerimientos
Obtención
Documentación
Validación
Fases
Cliente/Usuario
Desarrolladores
1.Obtención de
requerimientos. Captura de
requerimientos con el objetivo
de definir que es el sistema.
1.Documentación de requerimientos. Los requisitos
han de reflejarse en un documento como registro del
proceso de captura con el objetivo de fijar una base
para clientes y desarrolladores.
1.Validación. Es el
proceso por el cual
se determina si la
especificación es

47. 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.

48. Captura de Requerimientos.- Técnicas
Aplicadas
1. Primera tarea
2. Fase critica. Colaboración de grupos heterogéneos.
Desarrollador
Cliente/Usuario
Identifc.
Actores
Actividades
Obtención
Requer.
Captura de
Requer.
Identifc.
Funcionalidad

49. 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
–
–
–
–
Cuestionarios
Entrevistas
Talleres
Prototipos
1.Dirección general
2.Usuarios finales y dirección
3.Clientes
4.Proveedores
5.El equipo operativo
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.

50. 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.
¿Importancia de estos
Velocidad
factores para adquirir
Usabilidad
un OS?
 Mediante preguntas
Flexibilidad
para recoger información abierta
•
Baja
Alta
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
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

51. 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.

52. 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.

53. 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.

54. 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
Actividades
Actividades
Funciones
Funciones
Actividades
Actividades
Actividades

55. 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.

56. 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.

57. 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.

58. 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
Introducción
1. Alcance. Área de aplicación de los requisitos.
1. Alcance. Relación con otros sistemas
2. Definiciones.
2. Definiciones.
3. Historial.
3. Historial. Infraestructura existente
4. Descripción de alto nivel. Esquema del
problema.
4. Descripción de alto nivel. Esquema del
problema.
5. RF (Forma atómica y con identificador)
5. RF (Forma atómica y con identificador)
6. RNF (Forma atómica y con identificador y
vinculados a los funcionales que soportan)
6. RNF (Forma atómica y con identificador y
vinculados a los funcionales que soportan)
7. Restricciones específicas
7. Restricciones específicas

59. 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

60. 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.

61. Ejemplo de un Modelo de Negocio.

62. 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

63. 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

64. El Proceso de Negocios Atender Pedidos
• Acerca de Atender Pedidos
– Captar pedido del cliente
– Generar Documento de Venta
Registrar Pedido
Entregar producto
Pedido
Item
Fact-BV
Reparto
Mercadería

65. 65

66. 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 ?

67. 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

68. 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.