Your SlideShare is downloading. ×

BASE DE DATOS SISTEMA MODELO DE GESTION DE DATOS

4,385

Published on

ARQUITECTURA DE BASES DE DATOS

ARQUITECTURA DE BASES DE DATOS

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,385
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
178
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×