Sesión 1: Sistemas de Base de DatosRequerimientos del Sistema

Ing. Ivan Crispin Sanchez

1

Universidad Privada TelesupEscuela Profesional de Ingeniería de Sistemas

Curso de Modelamiento de Datos

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

AGENDA

PARTE I

TEMAS PRELIMINARES

..

Es un conjunto de elementos interrelacionados formando un todo, que buscan alcanzar un conjunto de objetivos.

Sistemas naturales

Sistemas hechos por el hombre

Clasificación de Sistemas

Sistema planetario solarSistema circulatorio humano

Sistema eléctrico interconectado del surSistema 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.

Entrada de datos

Procesamiento

clasificación ordenamiento

cálculos

Salida de la información

Retroalimentación

SISTEMA DE INFORMACION

ORGANIZACIONCLIENTES PROVEEDORES

COM

PETIDO

RES

ACCIONISTAS

ENTE

S D

EL E

STAD

O

MEDIO AMBIENTE

PRECISA

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

OPORTUNALa información resulta oportuna si esta disponible en el momento requerido.

SIGNIFICATIVAHa de ser comprensible e importante. El volúmen mostrado debe ser lo justo.

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

S I

MAYOR

MENOR

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

Cada aplicación recurre a archivos separados.

1. Aplicaciones con manejo de datos independiente

( Sistema de Archivos )

Datos centralizados y compartidos por todas las aplicaciones

2. Gestión centralizada

( Sistema de Bases de Datos )

Archivo de cuentas corrientes

Num. Cliente nombre cliente DatosCuentaCorriente

2056 juan pérez ........ ........ ....... .......

Archivo de Ahorros

Archivo de prestamos

Num. Cliente nombre cliente Datos de Ahorros

2056 juan pérez ........ ........ ....... .......

Num. Cliente nombre cliente Datos de Prestamos

2056 juan pérez ........ ........ ....... .......

redundancia

Aplicación 1

inconsistencia

Aplicación 2 Aplicación 3

Sistemade

Archivos

Aplicaciones con Manejo de Datos Independiente

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.

Archivo de ClientesNum. Cliente nombre cliente

2056 juan pérez

Datos deCuentas

Corrientes

Datos deCuentas de

AhorrosDatos de

Prestamos

Archivo de

CuentasCorrientes

Datos decuentas

corrientesArchivo de

PréstamosDatos de

préstamos

Archivo de

Cuentas deAhorros

Datos decuentas de

ahorros

Aplicación 1

Ap

lica

ció

n

3Ap

lica

ció

n

3

Gestión Centralizada de Datos

Enfoquede Basesde 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 redundanciaUn mismo dato puede estar repetido en diferentes archivos.

Riesgo de inconsistenciasLas diversas copias de los mismos datos pueden no coincidir (por ejemplo el cambio de dirección de un cliente)

Uso excesivo de recursos humanosUna alta proporción de recurso humano, se dedica a actividades de mantenimiento de software.

Las aplicaciones dependen de los archivosSi se hacen cambios en los formatos de archivos, también deben modificarse los programas( falta de independencia ).

Los archivos pueden ser incompatiblesUn archivo en Cobol no es igual que un archivo hecho en C++. Los archivos no pueden combinarse o compararse.

Datos separados y aisladosEn ocasiones es necesario obtener información de dos o más archivos.

Costos elevadosCambios 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 archivosProliferación constante de nuevos archivos y por tanto dificultad en su actualización.

… Datos Independientes

EmpleadosClientes

Inventario

Ventas Cuentas

SGBDEmpleados

ClientesVentas

InventarioCuentas

Dpto. Personal Dpto. VentasDpto. Contabilidad

BASE DE DATOS

… CentralizadoPersonal

Ventas

Contabilidad

BASE DATOS

ResultadosResultados

RequerimientosRequerimientosInternetInternet

INTRODUCCIÓN A LOS SISTEMAS DE BASE DE

DATOS

CONCEPTOS INICIALES

Esquema General de Uso de una Base de Datos

ASPPHPJAVA.NET

BASE DATOS

SQL ServerORACLEINFORMIXDB2

SQLSQLApplicaciónApplicación

Cliente

ResultadosResultados

InternetInternet

VisualBasicPowerBuilderVisualFoxDelphi

Modelo Datos

Resultados

Resultados

¿ 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

Ordenadoresdigitales Archivos Secuenciales

Fortran

S.O.Acc.directoy secuenc.

SBD.estruct.JerárquicaNAA + IBM

SBD en RedCharles Bachmann(G.Electric)

SBD relacionales, modelos orientados a objetos

Plataformascliente/servidor

SBD orientados a objetos

1960

1970

1980 1990 2000

1950

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)

Prog. RelacionalTed Codd

CODASYL1971

M-ERChen (1976)

SBD. Relacionales-SQL- SGBD (DB2, ORACLE)

Evolución de las Bases 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 :

Modelo de Datos

1. Modelo Jerárquico

2. Modelo de Redes

3. Modelo Entidad Relación

4. Modelo Relacional

5. Modelo de Objetos

6. Modelo Objeto-RelacionalAl

to N

ivelN

ivel

Impl

emen

taci

ón SGBD de PrimeraGeneración

SGBD de SegundaGeneración

SGBD de TerceraGeneraciónBD. DISTRIBUIDAS, ACTIVAS, ESPACIALESORIENTADAS A OBJETOS, ...

Evolución

RENDIMIENTO

BD

FUNCIONALIDAD/INTELIGENCIA

DISTRIBUCIÓN/INTEGRACIÓN

Líneas de Evolución de las Bases de Datos

BD PARALELAS

BD EN TIEMPO REAL

BD EN MEMORIA PRINCIPAL

RENDIMIENTO

Líneas de Evolución de las BD

DISTRIBUCIÓN

BD DISTRIBUIDAS

BD FEDERADAS

MULTIBASES DE DATOS

BD MÓVILES

BD “WEB”

INTELIGENCIA

BD ACTIVAS

BD DEDUCTIVAS

BD ORIENTADAS A OBJETOS

BD MULTIMEDIA

BD TEMPORALES

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 los SGBDDiccionario 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 datosAbstracció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 datosCada usuario puede tener una vista ó perspectiva diferente.

Control de ConcunrrenciaEl 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 RedundanciaQueda 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 autorizadosNiveles de acceso: Manejo de roles y privilegios por cuentas y/o grupo de cuentas.

Restricciones de IntegridadEjemplos: 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ónSe 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.

NIVEL EXTERNO

NIVEL CONCEPTUAL

NIVEL INTERNO o FISICO

(Niveles de abstracción)

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.

A este nivel se tiene el esquema de la basede 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

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

de un nivel a otro.Correspondencia : proceso de transformar pedidos y respuestas

Correspondencia conceptual/ interna

Correspondencia externa/conceptual

La BD presenta una arquitectura de tres niveles:

Vista Externa 1

Vista Externa 2

Vista Externa n. . .

Usuarios finales

ESQUEMA CONCEPTUAL

ESQUEMA INTERNO

NIVEL EXTERNO

NIVEL CONCEPTUAL

NIVEL INTERNO

BD ALMACENADA

detalle

Arquitectura de una BD

Programadores

Usuarios normales

Administrador de la Base de Datos

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

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

Usuarios sofisticadosInteractú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.

Crea BD, define métodos de acceso, concede autorizaciones, etc

Tipos de Usuarios de Base de Datos

Usuarios normales

Programadores de aplicaciones

Usuarios sofisticados

Administrador de Base de Datos

Interfaces de aplicaciones

Programas de aplicacion Consulta

Esquema de base de datos

Precompilador del DML

compilador del DML

Interprete del DDL

Código objeto de las aplicaciones Motor de evaluación de

consultas

Gestor de transacciones

Gestor de memoria intermedia

Gestor de archivos

indices

Archivos de datos estadística

Diccionario de datos

Procesador de Consultas

Gestor de almacenamiento

Sistema de gestión de base de

datos

Usuarios

Vista de los Componentes de un SGBD

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

Interacción con el sistema

Usuarios

Requerimientos

Sistema

BASEDATOS

Etapas para el Diseño de una Base de Datos

(I)

DISEÑO CONCEPTUAL

(I)

DISEÑO CONCEPTUAL

(II)

DISEÑO LOGICO

(II)

DISEÑO LOGICO

DISEÑO FISICO DE LA BASE DE DATOS

(III)

DISEÑO FISICO DE LA BASE DE DATOS

(III)BASE

DATOS

Requerimientos de Información

Etapas para el Diseño de una Base de Datos

DISEÑO CONCEPTUAL DISEÑO CONCEPTUAL

Requerimientos de InformaciónRequerimientos de Información

Cliente Producto Documentos

DISEÑO LOGICODISEÑO LOGICO

RED RELACIONAL OO

DISEÑO FISICO DE LA BASE DE DATOSDISEÑO FISICO DE LA BASE DE DATOS

ORACLE DB2ACCESSSQL Server MYSQL INFORMIX

Usuarios y Clientes

Los Protagonistas

Probador

Desarrollador

Arquitecto

Jefe deProyectos

Analista deNegocio

Profesional de Base de Datos

Diseñador

ProyectoSistema de Información

Planeamiento

Análisis

Diseño

Desarrollo

Mantenimiento

Requerimientos InicialesEstudio de Factibilidad

Requerimientos de usuarioEvaluación del sistema actualDiseño Lógico del Sistema

Detalle de las especificaciones del Sistema

Codificación, testing, ajustes.Instalación, Tunning

EvaluaciónMantenimiento: evolutivo y correctivo

Ciclo de Vida del Desarrollo de Sistemas

FASES ACCIONES

Diseño de la BD

Implementación

Testing y Evaluación

Operación

Mantenimiento y Evaluación

Diseño ConceptualSelección del SGBD ó DBMSDiseño Lógico y Físico

Instalación de la BDCreación de la BDIngreso y Conversión de Datos

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

Flujos de Información

Aplicación de CambiosCambios Asociados

Ciclo de Vida de la Base de Datos

Definiciones Iniciales

Análisis de la Situación de la CompañíaIdentificación de Problemas y RestriccionesDefinición de ObjetivosDeterminación del Alcance

FASES ACCIONES

¿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?

Evaluación del Aprendizaje

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. Disciplina de la ISW que se encarga de definir los requerimientos del sistema. Fases:

1. Determinación de requerimientos.

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.

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

Gestionar profesores

Introducir encargo de docencia

Gestionar aulas y laboratorios

Administrador

Gestionar horarios

Usuario externo

Consultar horarios

Modelo de Casos de Uso de Gehoweb (gestión de 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 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.

requerimientosno funcionales

requerimientosno funcionales

requerimientosdel producto

requerimientosdel producto

requerimientosorganizacionales

requerimientosorganizacionales

requerimientosexternos

requerimientosexternos

eficienciaeficiencia fiabilidadfiabilidadusabilidadusabilidad portabilidadportabilidad

rendimientorendimiento espacioespacio entregaentrega implementaciónimplementación estándaresestándares

interoperabilidadinteroperabilidad éticoséticos legislativoslegislativos

privacidadprivacidad seguridadseguridad

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

Requerimientos No Funcionales

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.

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

Determinación Requerimientos

DocumentaciónObtención

Cliente/UsuarioDesarrolladores

EspecificaciónSistema

Validación Fases

1.Validación. Es el proceso por el cual se determina si la especificación es

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.

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.

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

Captura deRequer.

ActividadesObtención

Requer.

Identifc. Actores

DesarrolladorCliente/Usuario

Identifc. Funcionalidad

Captura de Requerimientos.- Técnicas Aplicadas

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

Captura de Requerimientos.-

1.Dirección general2.Usuarios finales y dirección3.Clientes4.Proveedores5.El equipo operativo6.El equipo de mantenimiento7.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. ¿Importancia de estos factores para adquirir un OS? Mediante preguntas 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

Baja Alta

Velocidad 1 2 3 4 5

Usabilidad 1 2 3 4 5

Flexibilidad 1 2 3 4 5

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 contexto

e el análisis.

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

Nombre entrevistado.Puesto de trabajo y breve descripción.Punto de vista que representa.Fecha, hora y lugar de la entrevistaResumen de puntos principalesDoc´s. de referenciaOtros contactos.

Esquema de resumen de entrevista

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.

ProcesoFunciones

Funciones

Funciones

Actividades

Actividades

ActividadesActividades

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.

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

E. Requisitos del Usuario

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

E. Requisitos del Sistema

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

Reparto

Fact-BV

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.