11
DOC. DE ESPECIFICACIÓN DE REQUISITOS
El documento o la especificación de requisitos (SRD o SRS) recoge de forma integral los resultados del análisis.
Puede haber documentos previos al SRD, como estudios de viabilidad o de alternativas posibles.
El SRD debe ser revisado con cierta frecuencia durante el desarrollo y debe facilitar la varificación de las especificaciones (contrato).
Diversos organismos de estandarización hacen propuestas sobre la estructura del SRD: IEEE, DoD, etc. Vemos el modelo de SRD de la Agencia Espacial Europea. Dependiendo de las características y complejidad del proceso tal vez no sea necesario cubrir todos los apartados.
12
MODELO DE SRD
Introducción
Objetivo: objetivos, participantes, calendario,…
Ámbito, identificará y dará nombre al producto
Definiciones, siglas y abreviaturas
Referencias, la descripción bibliográfica de los documentos referenciados.
Panorámica del documento
Descripción general
Relación con otros proyectos, similares o complementarios
Relación con proyectos anteriores o posteriores
Objetivo y funciones
Consideraciones de entorno
Relaciones con otros sistemas, que utilicen entradas o salidas indirectas de información
Restricciones generales: metodologías, lenguajes, de hardware,…
Descripción del modelo, es el apartado más extenso y más importante. Se utilizan todas las notaciones y herramientas disponibles
13
MODELO DE SRD
Requisitos específicos, lista detallada y completa de los requisitos del sistema, indicando su grado de cumplimiento (obligatorio, recomendable, opcional. No incluir aspectos de diseño o desarrollo, ni tampoco soluciones particulares que no sean obligadas
Requisitos específicos, QUÉ debe hacer el sistema especificando el tratamiento de la información.
Requisitos de interfase, conexión con otros sistemas con los que interactúa (bases de datos, ficheros, SSOO,…).
Requisitos de operación, es decir, del interfaz de usuario
Requisitos de capacidad, volumen procesador, tiempo respuesta, tamaño ficheros. Se debe cuantificar para el peor, el mejor y el caso más habitual.
Requisitos de verificación, que debe cumplir el sistema para que se posible verificar su corrección
Requisitos de pruebas de aceptación
Requisitos de recursos, instalaciones y elementos necesarios para el funcionamiento del sistema
Requisitos de documentación
Requisitos de transportabilidad, para adaptalo a otras plataformas
Requisitos de calidad, que no hayan sido recogidos en otros apartados
Requisitos de fiabilidad, imponiendo un límite aceptable de fallos
Requisitos de mantenibilidad
Requisitos de seguridad, contra utilización indebida
Requisitos de salvaguarda, para evitar consecuencias graves en equipos o en personas
APENDICES, para complementar el contenido del documento
14
VIDEOJUEGO DE LAS MINAS
15
SISTEMA DE GESTIÓN DE BIBLIOTECA
16
SISTEMA DE GESTIÓN DE BIBLIOTECA
17
SISTEMA DE GESTIÓN DE BIBLIOTECA
18
SISTEMA DE GESTIÓN DE BIBLIOTECA
19
SISTEMA DE GESTIÓN DE BIBLIOTECA
20
CONCEPTO DE DISEÑO
Descripción o bosquejo de alguna cosa hecho por palabras.
En un sistema software la realización del diseño parte del SRD y no es nada trivial. Cuando no se tiene experiencia en el desarrollo concreto se hace de forma iterativa mediante ensayo y error, en caso contrario se aprovecha el “know-how” (saber hacer).
Las técnicas para realizar diseños nuevos son empíricas y no están suficientemente formalizadas, mientras que para proyectos ya conocidos, como los de gestión, existen herramientas tales como lenguajes de 4ª generación.
En el diseño se establece el CÓMO debe funcionar el sistema, determinando la organización y la estructura del software.
21
ACTIVIDADES DE UN DISEÑO SISTEMÁTICO
DISEÑO ARQUITECTÓNICO, se abordan los aspectos estructurales y de organización del sistema, y su posible división en subsistemas
DISEÑO DETALLADO, organización y estructura de los módulos
DISEÑO PROCEDIMENTAL, organización de las operaciones o servicios que ofrecerá cada módulo. Se suele realizar en pseudocódigo o PDL, pero desarrollando sólo los aspectos más relevantes del algoritmo
DISEÑO DE DATOS, organización de la base d edatos del sistema. Se parte de los diagramas E-R.
DISEÑO DE LA INTERFAZ DE USUARIO, organizar y facilitar la utilización del sistema por parte del usuario
El resultado de estas actividades debe plasmarse en el Documento d Diseño Software (SDD)
22
CONCEPTOS PARA EL DISEÑO
ABSTACCIÓN, identificar los elementos significativos del sistema y abstraer la utilidad específica de cada uno
ABSTRACCIONES FUNCIONALES, sirven para crear expresiones parametrizadas usando funciones o procedimientos
TIPOS ABSTRACTOS, junto con el tipo de datos se deben crear los métodos que manejan estos datos
MÁQUINAS ABSTRACTAS, definición formal del comportamiento de una máquina
MODULARIDAD, el diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Sus ventajas: claridad, reducción de costos y reutilización
REFINAMIENTO, a partir de una idea no muy concreta se va refinando mediante aproximaciones hasta el detalle
ESTRUCTURAS DE DATOS, para organizar la información que maneja el sistema: registros, conjuntos, listas, pilas, colas, árboles, grafos, tablas, ficheros, …
OCULTACIÓN, de la organización de los datos internos y de los detalles del algoritmo, se muestra en el interfaz sólo aquello que resultará invariable ante cambios. Ventajas: depuración, mantenimiento, …
GENERICIDAD, consiste en diseñar un elemento genérico, con las características comunes a todos los elementos agrupados
HERENCIA, los elementos hijos heredan del padre su estructura y operaciones para ampliarlos, mejorarlos o adaptarlos. Es conveniente utilizar un lenguaje de programación orientado a objetos
POLIMORFISMO, es la propiedad de los elementos que pueden variar su formar sin cambiar su naturaleza. Se emplea el concepto de genericidad. En los hijos se puede producir la anulación de una operación. A veces en el padre interesa declarar un método sin implementarlo, lo harán los hijos en diferido
CONCURRENCIA, se trata de aprovechar al máximo el procesador garantizando unos tiempos máximos de respuesta para tareas críticas. Problemas de los sistemas con restricciones:
Tareas concurrentes, asegurar que todas cumplen sus restricciones
Sincronización de tareas, determinando los puntos de sincronización entre ellas
Comunicación entre tareas, unas serán productoras de datos y otras consumidoras. Para evitar la corrupción de datos compartidos permitir sólo concurrencia en lectura con semáforos, monitores y regiones críticas
Interbloqueos (deadlock) cuando varias tareas esperan un evento que nunca se producirá
23
NOTACIONES PARA EL DISEÑO
Debe resultar precisa, clara y fácil de interpretar. Se emplean notaciones formales cuasimatemáticas
NOTACIONES ESTRUCTURALES, se desglosa y estructura el sistema en sus partes
DIAGRAMAS DE BLOQUES
CAJAS ADOSADAS
24
DIAGRAMAS DE ESTRUCTURA (Yourdon)
Describen la estructura de los sistemas software como una jerarquía de módulos, reflejando sólo su organización estática
RECTÁNGULO, módulo
LÍNEA, relación entre módulos, el superior utiliza el módulo inferior
ROMBO, opcional
ARCO, repetitiva
CIRCULO CON FLECHA, envio de datos o información de control (correcto, repetir, desconectar, etc)
25
DIAGRAMAS HIPO (Hierachy-Input-Process-Output)
Se muestra primero la jerarquía entre los módulos del sistema
Y en los diagramas HIPO de detalle hay 3 zonas: Entrada, Proceso y Salida
26
DIAGRAMAS DE JACKSON
El proceso de diseño es sistemático y se lleva a cabo en tres pasos:
Especificación de la estructura de datos de entrada y de salida
Obtención de la estructura del programa
Expansión de la estructura del programa para lograr el diseño detallado
27
NOTACIONES ESTÁTICAS
Describen las características estáticas del sistema, tales como la organización de la información, sin tener en cuenta su evolución durante el funcionamiento del sistema.
Las notaciones son las mismas que se emplean en la especificación:
DICCIONARIO DE DATOS, dónde se detalla la estructura interna de los datos que maneja el sistema. En el diseño se amplía y se completa el diccionario de la especificación hasta el nivel de detalle necesario para iniciar la codificación.
DIAGRAMAS ENTIDAD-RELACIÓN, definiendo las relaciones entre datos y la organización de la información. Se amplia y detalla el diagrama de la especificación con las nuevas entidades y relaciones.
28
NOTACIONES DINÁMICAS
Permiten describir el funcionamiento del sistema durante su funcionamiento.
Las notaciones son las misma utilizadas en la especificación:
DIAGRAMAS DE FLUJO DE DATOS, serán mucho más exhaustivos que los de la especificación.
DIAGRAMAS DE TRANSICIÓN DE ESTADOS, más detallados que reflejen las transiciones entre estados internos.
LENGUAJE DE DESCRIPCIÓN DE PROGRAMAS (PLD), permite realizar la especificación funcional del sistema.
29
NOTACIONES HIBRIDAS: DIAGRAMAS DE ABSTRACCIONES
Permiten un enfoque globalizado del diseño atendiendo a aspectos estáticos (datos), dinámicos (operaciones) y de estructura del sistema.
DIAGRAMAS DE ABSTRACCIONES, se contemplan dos tipos de abstracciones: las funciones y los tipos abstractos de datos.
En una abstracción se distinguen 3 partes:
NOMBRE, es su identificador
CONTENIDO, dónde se define la organización de los datos
OPERACIONES, para manejar el contenido de la abstracción
Las abstracciones funcionales (funciones o procedimientos), sólo tiene la parte de operación.
El dato encapsulado tiene como el tipo abstracto contenido y operaciones, pero no permite declarar otras variables de su mismo tipo.
En los diagramas se muestra la relación jerárquica entre abstracciones, de manera que la abstracción superior utiliza la inferior.
30
NOTACIONES HIBRIDAS: DIAGRAMAS DE OBJETOS
Se emplea una terminología distinta, pero las similitudes con los diagramas de abstracciones es muy grande, excepto que:
No existe nada equivalente a los datos encapsulados ni a las abstracciones funcionales en el modelo de objetos
En los diagramas de objetos hay relaciones de herencia
De acuerdo con las propiedades de los objetos podemos tener relaciones especiales entre ellos:
CLASIFICACIÓN, ESPECIALIZACIÓN O HERENCIA
COMPOSICIÓN, permite describir un objeto mediante los elementos que lo forman
 Página anterior | Volver al principio del trabajo | Página siguiente  |