2do Resumen Sistemas IIRequisito: condicin necesaria para algo. Condicin o capacidad que debe poseer un sistema o un componente de un sistema para satisfacer un contrato, un estndar, una especificacin u otro documento formalmente impuesto. Clasificacin: Objetivo: requisitos de alto nivel, features o caractersticos, enuncian una condicin que debe cumplir el sistema, suelen ser el primer nivel de requisitos que se obtienen en el proceso de desarrollo, y se van refinando para obtener requisitos de nivel ms bajoRegla del Negocio: definen restricciones, regalas o polticas del negocio que deben ser respetadas por el sistema, suelen ser relativamente inestables, ya que pueden cambiar en un futuro.Interfaz: definen qu interfaz debe respetar el sistema debe respetar el sistema cuando se comunique con otros sistemas.Informacin: describen que informacin debe almacenar el sistema para cumplir los objetivos de nivel superior, deben indicar concepto relevante as como tambin que datos especficos son importantes para el cumplimiento de los objetivos.Funcional: definen los servicios que debe ofrecer el sistema a los usuarios para alcanzar los obj.No Funcional: condiciones que se le imponen al sistema a desarrollar relacionadas con aspectos de calidad: usabilidad, rendimiento, disponibilidad, fiabilidad, seguridad, compatibilidad con hardware o software

Requerimiento: peticin de una cosa que se considera necesaria, una solicitud. Necesidad de un usuario unidad funcional de la organizacinModelo Funcional de la Solucin: permite ver de una manera grfica y literal los requisitos o las funciones que debe exhibir la solucin propuesta utilizando TIC. (Modelado de Requisitos)

Casos de uso: son una tcnica para especificar el comportamiento de un sistema, es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un Diagrama de Casos de Uso muestra un conjunto de casos de uso, actores y sus relaciones, cubren la vista funcional de un sistema (funcionalidades visibles al usuario).Son historias que narran interacciones entre: Actores: personas u otras sistemas con algn objetivo que cumplir (actores primarios) o que ayudan a otros actores a cumplir sus objetivos (actores secundarios) Sistema bajo estudio: sistema actual o a desarrollar que proporciona ciertos servicios que necesitan los actores para cumplir los objetivos. Ejemplo: sacar dinero de un cajero automtico; Actores: usuario (primario) banco (secundario); Sistema bajo estudio: Cajero Automtico; Objetivo: Obtener dinero de su cta. Relaciones de Caso de uso: Asociacin: Herencia: Un actor es instancia de otro.Extend: Es una asociacin que especifica un comportamiento adicional de un caso de uso, describe un curso alterno y opcional (la extensin) de otro caso de uso (base). Usar: En partes opcionales de un caso de uso, En situaciones donde se puede seleccionar entre diferentes alternativas, sin perder el objetivo del caso de uso base, Cursos separados que son ejecutados bajo ciertas condicionesInclude: Es una asociacin que especifica una Relacin que define una instancia de un caso de uso como un curso obligatorio en otro caso de uso. Usar: Cuando se quiere separar una funcionalidad en un caso de uso, Para evitar la repeticin de casos de uso.

Los casos de usos deben tener:Precondicin: condiciones que describen en qu situacin se debe encontrar el sistema y su entorno para poder comenzar el caso de uso.Postcondicin: condiciones que describen en qu situacin se debe encontrar el sistema y su entorno una vez que se haya finalizado el caso de uso con xito.Secuencia Normal: secuencia de interaccione entre actores y sistema que lleva a la finalizacin con xito del caso de uso.Excepciones: situaciones anmalas y su tratamiento que pueden darse durante la secuencia normal.

Ingeniera de Requisitos: proceso de descubrir, analizar, documentar y verificar los servicios que debe proporcionar el sistema y sus restricciones. Comprende al conjunto de actividades que intentan entender las necesidades de los usuarios y traducirlas en afirmaciones precisas (no ambiguas), que se usarn en el desarrollo del sistema.Fortalezas de la Ingeniera de Requisitos1. Define un proceso.2. Facilita la comprensin de lo que quiere el cliente: Analizando sus necesidades. Confirmando su viabilidad. Negociando la solucin. Especificando la solucin sin ambigedad. Validando y Gestionando requisitos para que el sistema pueda ser operativo. Obtener requisitos:a travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus expectativas. Analizar requisitos:detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo. Documentar requisitos:igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos:consiste en comprobar el correcto funcionamiento de un requisito en la aplicacin. Validar los requisitos:comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretenda.

Se ocupa de: Controlar el proceso de Ingeniera de Requisitos. Generar el documento base de requisitos. Gestionar las peticiones de cambio en los requisitos. Definir los atributos de los requisitos. Mantener la rastreabilidad.

Elicitacin: tcnica de interaccin para centrar las discusiones sobre los servicios que debe ofrecer el sistema que se va a desarrollar, pueden usarse en el modelado de negocio para entender y describir los procesos actuales, en cuyo caso suelen denominarse caso de uso de negocioDocumentacin: tcnica alternativa a las tradicionales listas de requisitos para la documentacin de casi todos los requisitos funcionales. Validacin: pueden usarse como unidad de validacin conjuntamente con prototipos de interfaz de usuario, de modo que los usuarios recorran los casos de uso por el prototipo y los validen.

Especificacin de Requisitos: El objetivo es obtener un documento de especificacin de requisitos (ERS). Documento que define, de forma completa, precisa y verificable los Requisitos que debe cumplir el sistema, tanto funcionales como no funcionales, as como las restricciones aplicables al diseo (software y hardware). Caractersticas fundamentales: Debe incluir informacin veraz, Debe comunicar dicha informacin de forma eficaz, Describir correctamente todos los requisitos necesarios del software, No describir ningn detalle del diseo del software, de su verificacin o de la direccin del proyecto que influyen en los requisitos. El QU y no el CMO

La gestin del cambio se debe aplicar a todos los cambios propuestos. Ventajas de utilizar un proceso formal de gestin de cambios: Todos los cambios propuestos son tratados de forma consistente. Todos los cambios en el documento de requisitos se hacen de forma controlada.

Modelo de Datos: es el segundo modelo ms importante del diseo de la solucin. Representa grficamente todos los conceptos que pertenecen al dominio de la solucin. Tambin se le denomina Capa de Datos o Vista de Datos del Diseo de la Solucin. Este Modelo tambin captura las reglas del negocio o de la solucin, que se modelan a travs de las relaciones entre los conceptos del Dominio. Se construye a travs del MER y del Diagrama de Clases.

Es necesario conocer el negocio para modelarlo

Modelo Entidad Relacin (MER): Grfico que permite Organizar, Verificar, Comprender y Conocer un Sistema en funcin de sus Datos, permite comprender el negocio y el significado de sus datos.Elementos:Entidad: Es todo aquello de lo cual se guarda informacin en un Sistema. Ejemplo: AlumnoAtributos: Caractersticas o propiedades bsicas de las Entidades o Asociaciones. Ejemplo: CedulaAsociacin o Reglas del Negocio: Expresa la vinculacin entre entidades y es adems una regla del negocio. Ejemplo: un ALUMNO cursa una o varias MATERIA

Reglas del Negocio: son restricciones en las actividades de los negocios que necesitan reflejarse en la base de datos (b.d.) y en sus aplicacionesCardinalidad en las asociaciones: Expresa las ocurrencias de las entidades que participan en la asociacin en trminos de Frecuencia Mxima (FM) y Frecuencia Mnima (Fm)

Notaciones utilizadas para representar grficamente el MER: Un alumno cursa una o varias materias. Una materia es cursada por uno o varios alumnos

Tipos de asociacin: - Una a una ( 1 : 1 ) - Una a Muchas ( 1 : n ) - Muchas a Muchas ( n : m ) Recursivas(Vincula a una Entidad consigo misma)Asociacin Mltiple: Se presenta cuando las asociaciones vinculan a ms de dos entidadesAsociacin Paralela: Se presenta cuando entre dos entidades existe ms de una AsociacinModelo Conceptual de Datos o MER: aparecen los puentes o entidades asociativasEntidad Asociativa: Es aquella Entidad que almacena informacin contenida en una Asociacin Muchas-a-Muchas, disuelve una Asociacin Muchas-a-Muchas y la convierte en dos relaciones Una-a-Muchas

Pasos para la construccin de un MER:a) Conocer la Gestin del Negociob) Identificar las Entidades del Negocioc) Analizar las asociaciones entre las Entidadesd) Representar el Modelo de Entidades del Negocio (MEN)e) Identificar Asociaciones Muchas-a-Muchasf) Construir el Modelo Conceptual de Datos (MCD)g) Identificar los Atributos de cada Entidad de Datos

Consideraciones: - Una entidad NO es un archivo, - No confundir con Entidades Externas del DFD, - Los reportes e Histricos no se consideran Entidades, - El Nombre de la Entidad es en Singular.