Metodolog - PowerPoint PPT Presentation

1 / 107
About This Presentation
Title:

Metodolog

Description:

Title: Abstract View of System Components Author: Marilyn Turnamian Last modified by: USM Created Date: 6/25/1999 6:38:26 PM Document presentation format – PowerPoint PPT presentation

Number of Views:88
Avg rating:3.0/5.0
Slides: 108
Provided by: Marily386
Category:

less

Transcript and Presenter's Notes

Title: Metodolog


1
Metodologías de Análisis
  • Pedro Francisco Godoy Barrera
  • Ingeniero Civil Informático

2
Calendarización
Nº Día Clases
1 06-Aug Presentación - Introducción
2 13-Aug Introducción
3 20-Aug Proceso
4 27-Aug Modelos
5 03-Sep Prototipos
6 10-Sep Procesos 2
7 17-Sep  
8 24-Sep Certamen 1
9 01-Oct Modelo OO
10 08-Oct UML
11 15-Oct Resumen ADOO
12 22-Oct Captura de Requisitos
13 29-Oct Modelo Conceptual
14 05-Nov Modelo de Casos de Usos
15 12-Nov Control de avance Diagrama de estados
16 19-Nov Patrones
17 26-Nov Certamen 2
18 03-Dec Caso Práctico
3
Evaluación
  • Certamen 1 24 de Sept 40
  • Certamen 2 26 de Nov 40
  • Trabajo Práctico 20
  • Presentación de avance 12 de Nov 6
  • Presentación Final 03 de Dic 6
  • Informe 01 de Dic 8

4
Presentación
  • Dos personas desconocidas
  • Tiempo máximo de 10 minutos, interactuar y
    conocerse.
  • Objetivo Presentar a su compañero.

5
Expectativas
  • Qué esperan recibir de este curso
  • Intereses personales

6
Metodologías de Análisis
  • Capítulo 1 Introducción

7
Contexto
  • La Ingeniería de Software designa un conjunto de
    técnicas destinadas a la producción de un
    programa de computador, más allá de la sola
    actividad de programación.
  • Forman parte de esta disciplina las ciencias
    computacionales y el manejo de proyectos, entre
    otros campos, propios de la rama más genérica
    denominada Ingeniería informática.

8
Contexto
  • La ingeniería de Software requiere llevar a cabo
    muchas tareas, sobre todo las siguientes
  • Análisis de Requisitos
  • Análisis y Especificación
  • Diseño y Arquitectura
  • Programación
  • Prueba
  • Documentación
  • Mantenimiento

9
Contexto
Análisis de Requisitos
  • Extraer los requisitos de un producto de SW es la
    primera etapa para crearlo.
  • Se requiere habilidad y experiencia en la
    Ingeniería de SW para reconocer los
    requerimientos incompletos, ambiguos o
    contradictorios.
  • El resultado de los análisis de requerimientos
    con el cliente se plasma en el documento de
    Especificación de Requerimientos del Sistema
    (ERS).

10
Contexto
Análisis de Requisitos
  • La estructura del ERS, puede venir definida por
    varios estándares, tales como CMM-I, Asimismo, se
    define un diagrama de Entidad/Relación, en el que
    se plasman las principales entidades que
    participarán en el desarrollo del SW.

11
Contexto
Análisis
  • El objetivo del modelado del análisis es crear
    una variedad de representaciones que muestran los
    requisitos del SW para la Información, la función
    y el comportamiento.

12
Contexto
Análisis
  • Para lograr lo anterior se deben aplicar dos
    filosofías diferentes
  • El análisis estructurado considera al SW como un
    transformador de información. Ayuda al ingeniero
    de SW a identificar los objetos de datos, sus
    relaciones y la manera en la cual estos objetos
    de datos se transforman mientras fluyen a través
    de las funciones de procesamiento del SW

13
Contexto
Análisis
  • El análisis orientado a objetos examina un
    dominio de problemas definidos como un conjunto
    de casos de uso en un esfuerzo por extraer clases
    que definen el problema.
  • Cada clase tiene un conjunto de atributos y
    operaciones. Las clases están relacionadas entre
    si en una variedad de formas diferentes y se
    moldean mediante la aplicación de diagramas de
    UML.

14
Contexto
Análisis
  • El modelo de análisis lo componen 4 elementos de
    modelado
  1. Modelos basados en Escenarios
  2. Modelos de Flujo
  3. Modelos basado en clases
  4. Modelos de comportamiento

15
Contexto
Análisis
  • 1.- Modelos basados en Escenarios
  • Estos muestran los requisitos del SW desde el
    punto de vista del Usuario
  • El Caso de Uso (CU), una descripción Narrativa o
    basada en una plantilla de una interacción entre
    el actor y el SW. Es el elemento primario del
    modelado.
  • El CU, derivado durante la obtención de
    requisitos define los casos clave para una
    función clave para una función o interacción
    específica.

16
Contexto
Análisis
1.- Modelos basados en Escenarios
  • Los escenarios también pueden describirse por
    medio de un diagrama de actividad Una
    representación gráfica del tipo de diagrama de
    flujo que muestra el flujo del procesamiento
    dentro de un escenario específico.
  • Los diagramas de carril Ilustran la forma en que
    el flujo de procesamiento incumbe a varios
    actores o clases.

17
Contexto
Análisis
2.- Los modelos de flujo
  • Estos se enfocan en el flujo de objetos de datos
    conforme las funciones de procesamiento los
    transforman.
  • Los modelos de flujo, que se derivan del análisis
    estructurado, utilizan el diagrama de flujo de
    datos (DFD).

18
Contexto
Análisis
2.- Los modelos de flujo
  • Esta es una notación de modelado que muestra la
    manera en que una entrada se transforma en una
    salida conforme los objetos de datos se mueven a
    través del sistema..
  • Cada función del SW que transforma datos se
    describe mediante una especificación del proceso
    o el flujo de control

19
Contexto
Análisis
3.- Modelos basados en clases
  • Estos utilizan información derivada de elementos
    de modelado orientado al flujo y basado en
    escenarios para extraer clases candidatas,
    atributos y operaciones de las narrativas basadas
    en texto.
  • Se usan una variedad de notaciones de modelado en
    UML para definir jerarquías, relaciones,
    asociaciones, agregaciones y dependencias entre
    las clases.

20
Contexto
Análisis
4.- Los modelos de comportamiento
  • Los 3 primeros modelos proporcionan una visión
    estática del SW. Los modelos de comportamiento
    muestran un desempeño dinámico.
  • El modelo de comportamiento utiliza la entrada de
    elementos basados en escenarios, orientados al
    flujo y basados en clases para representar los
    estados de las clases de análisis y sistema como
    un todo.

21
Contexto
Análisis
4.- Los modelos de comportamiento
  • Esto se logra identificando los estados,
    definiendo los eventos que ocasionan que una
    clase (o sistema) tenga una transición de un
    estado a otro, identificando las acciones que
    suceden cuando se realiza una transición.

22
Metodologías de Análisis
  • Requisitos del Software

23
Requisitos del Software
Índice del Tema
  • Introducir los conceptos de requisitos del
    usuario y del sistema.
  • Describir los requisitos funcionales y no
    funcionales.
  • Explicar dos técnicas para describir requisitos
    del sistema.
  • Explicar cómo los requisitos de software pueden
    ser organizados en un documento de requisitos.

24
Requisitos del Software
Tópicos a Cubrir
  • Requisitos Funcionales y no Funcionales.
  • Requisitos de Usuario.
  • Requisitos del Sistema.
  • Documento de Requisitos de Software.

25
Requisitos del Software
Introducción
Ingeniería de Requisitos
  • El proceso de establecer los servicios que el
    cliente necesita de un sistema y las
    restricciones bajo las cuales opera y se
    desarrolla.
  • Los requerimientos son las descripciones de los
    servicios del sistema y las restricciones que son
    generadas durante el proceso de ingeniería de
    requisitos.

26
Requisitos del Software
Introducción
Definición de Requisitos
  • Declaración abstracta de alto nivel de un
    servicio que debe proveer un sistema, o de una
    restricción de éste.
  • Definición matemática, detallada y formal, de una
    función del sistema.

27
Requisitos del Software
Introducción
Documento de Requisitos del Sistema
  • Si una compañía desea establecer un contrato para
    el desarrollo de un proyecto de software, debe
    definir sus necesidades de una forma
    suficientemente abstracta como para establecer a
    partir de ella una solución.
  • Los requisitos deben redactarse de tal forma que
    varios contratistas puedan licitar el contrato,
    ofreciendo, quizás, diferentes formas de cumplir
    las necesidades de los clientes de la
    organización.

28
Requisitos del Software
Introducción
Documento de Requisitos del Sistema
  • Una vez que el contrato se asigna, el contratista
    debe redactar una definición del sistema para el
    cliente de forma que éste comprenda y pueda
    validar lo que hará el softwareambos documentos
    se denominan el documento de requisitos para el
    sistema.

29
Requisitos del Software
Introducción
Tipos de Requisitos
  • Requisitos del Usuario descripciones, en
    lenguaje natural y en diagramas, de los servicios
    que se espera que el sistema provea y de las
    restricciones bajo las cuales debe operar.
    Escritos por el usuario.

30
Requisitos del Software
Introducción
Tipos de Requisitos
  • Requisitos del Sistema establecen con detalle
    los servicios y restricciones del sistema. El
    documento de requerimientos del sistema, algunas
    veces denominada especificación funcional, debe
    ser preciso. Éste sirve como un contrato entre el
    comprador del sistema y el desarrollador de
    software.

31
Requisitos del Software
Introducción
Tipos de Requisitos
  • Especificación del Diseño de Software
    descripción abstracta del diseño del software que
    es una base para un diseño e implementación
    detallados. Esta especificación agrega detalle a
    la especificación de requisitos del sistema.

32
Requisitos del Software
Introducción
Ejemplo de Requisito del Usuario
  • El software debe proveer un medio para
    representar y accesar archivos externos creados
    por otras herramientas.

33
Requisitos del Software
Introducción
Ejemplo de Requisito del Sistema
  • Al usuario se le proveerá con los recursos para
    definir el tipo de archivos externos.
  • Cada tipo de archivo externo tendrá una
    herramienta asociada que será aplicada al archivo.
  • Cada tipo de archivo externo se representará como
    un ícono específico sobre la pantalla del usuario.

34
Requisitos del Software
Introducción
Ejemplo de Requisito del Sistema
  • Se proveerán recursos para que el usuario defina
    el ícono que represente un tipo de archivo
    externo.
  • Cuando un usuario selecciona un ícono que
    representa un archivo externo, el efecto de esa
    selección es aplicar la herramienta asociada con
    este tipo de archivo representado por el ícono
    seleccionado.

35
Requisitos del Software
Introducción
Lectores de Requisitos
  • Requisitos del Usuario administradores, usuarios
    finales, ingenieros, contratistas, arquitectos
    del sistema.
  • Requisitos del Sistema usuarios finales,
    ingenieros, arquitectos del sistema,
    desarrolladores del software.
  • Especificación del Diseño del Software
    ingenieros, arquitectos del sistema,
    desarrolladores del software.

36
Requisitos del Software
Requisitos Funcionales y No Funcionales
  • Requisitos Funcionales descripciones de los
    servicios que el sistema debiera entregar, de
    cómo el sistema debiera reaccionar frente a
    entradas particulares, y de cómo se deberá
    comportar en situaciones específicas.
  • Requisitos No Funcionales restricciones sobre
    los servicios o funciones ofrecidos por el
    sistema. Incluyen restricciones de tiempo, sobre
    el proceso de desarrollo, estándares, etc.

37
Requisitos del Software
Requisitos Funcionales y No Funcionales
  • Requisitos del Dominio requisitos que provienen
    del dominio de aplicación del sistema y que
    reflejan las características de ese dominio.
    Éstos pueden ser funcionales o no funcionales.

38
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos Funcionales
  • Describen la funcionalidad o los servicios que se
    espera que el sistema proveerá.
  • Dependen del tipo de software y del sistema que
    se desarrolle, y de los posibles usuarios del
    software.
  • Cuando se expresan como requisitos del usuario,
    normalmente se describen de forma general,
    mientras que los requisitos del sistema describen
    con detalle de éste, sus entradas y salidas,
    excepciones, etc.

39
Requisitos del Software
Requisitos Funcionales y No Funcionales
Ejemplos de Requisitos Funcionales
  • El usuario deberá tener la posibilidad de buscar
    en el conjunto inicial de la base de datos o
    seleccionar un subconjunto de ella.
  • El sistema deberá proveer visores adecuados para
    que el usuario lea documentos en el repositorio
    de documentos.
  • A cada pedido se le deberá asignar un
    identificador único que el usuario podrá copiar
    al área de almacenamiento permanente de la cuenta.

40
Requisitos del Software
Requisitos Funcionales y No Funcionales
Imprecisión de Requisitos Funcionales
  • Problemas surgen cuando los requisitos no son
    precisamente establecidos.
  • Requisitos ambiguos pueden ser interpretados de
    diferentes maneras por los desarrolladores y
    usuarios.
  • Considerar el segundo requisito anterior, en
    relación a los visores
  • Intención del usuario visor de propósito
    específico para cada tipo de documento.
  • Intención del desarrollador visor de texto de
    propósito general.

41
Requisitos del Software
Requisitos Funcionales y No Funcionales
Imprecisión de Requisitos Funcionales
  • Por lo tanto, hay una necesidad de una
    especificación completa y consistente.
  • La completitud significa que todos los
    solicitados por el usuario están definidos.
  • La consistencia apunta a que los requisitos no
    tengan definiciones contradictorias.
  • En la práctica, para sistemas grandes y
    complejos, es imposible cumplir los requisitos de
    consistencia y completitud.

42
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales
  • Son requisitos que no se refieren directamente a
    las funciones específicas que entrega el sistema,
    sino a las propiedades emergentes de éste como la
    confiabilidad, la respuesta en el tiempo y la
    capacidad de almacenamiento.
  • De manera alternativa, definen las restricciones
    al sistema como la capacidad de los dispositivos
    de E/S, y la representación de datos a usar en
    las interfaces del sistema.

43
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales
  • Muchos de los requisitos no funcionales se
    refieren al sistema como un todo más que a
    características particulares del mismopor lo
    mismo, son más críticos que los requisitos
    funcionales específicos.
  • El incumplimiento de un requisito funcional
    degradará el sistema, una falla en un requisito
    no funcional del sistema lo inutilizará.

44
Requisitos del Software
Requisitos Funcionales y No Funcionales
Clasificación de los Requisitos No Funcionales
  • Requisitos del Producto especifican el
    comportamiento del producto.
  • Requisitos de Eficiencia, que agrupa los de
    Desempeño (tiempo de respuesta del sistema) y los
    de Espacio (disponibilidad de memoria).
  • Requisitos de Confiabilidad tasa de fallas para
    que el sistema sea aceptable.
  • Requisitos de Portabilidad.
  • Requisitos de Usabilidad.

45
Requisitos del Software
Requisitos Funcionales y No Funcionales
Clasificación de los Requisitos No Funcionales
  • Requisitos Organizacionales se derivan de las
    políticas y procedimientos existentes en la
    organización del cliente y en la del
    desarrollador.
  • Requisitos de Estándares de los procesos que
    deben usarse.
  • Requisitos de Implementación como los lenguajes
    de programación o el método de diseño a utilizar.
  • Requisitos de Entrega que especifican cuándo se
    entregará el producto y su documentación.

46
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales y Metas
  • Un problema común con estos requisitos es que
    pueden ser difíciles de verificar.
  • Se redactan para reflejar las metas generales del
    usuario, como la facilidad de uso, la capacidad
    del sistema para recuperarse de las fallas o la
    respuesta rápida al usuario.
  • Lo anterior causa problemas a los
    desarrolladores, pues deja abierta la posibilidad
    a la interpretación.

47
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales y Metas
  • Idealmente, los requisitos no funcionales
    debieran ser expresados de manera cuantitativa
    utilizando métricas que se puedan probar de modo
    objetivo.

48
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales Ejemplo de Meta
  • Deberá ser fácil para los controladores utilizar
    el sistema, y éste deberá estar organizado para
    minimizar los errores del usuario.

49
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales requisito verificable
  • Después de una capacitación de dos horas, a los
    controladores les deberá ser posible usar las
    funciones del sistema. Después de dicha
    capacitación, el número de errores cometidos por
    los usuarios experimentados no excederá de dos
    por día.

50
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales métricas
  • Velocidad de ejecución
  • Transacciones procesadas por segundo
  • Tiempo de respuesta al usuario y a eventos
  • Tiempo de actualización de la pantalla

51
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales métricas
  • Tamaño
  • KB, MB, GB
  • Facilidad de Uso
  • Tiempo de Capacitación
  • Número de cuadros de ayuda

52
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales métricas
  • Confiabilidad
  • Tiempo promedio entre fallas
  • Disponibilidad del sistema
  • Tasa de ocurrencia de las fallas
  • Portabilidad
  • Número de sistemas a considerar
  • Número de operaciones dependientes del sistema

53
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales métricas
  • Robustez
  • Tiempo de reinicio tras una falla
  • Porcentaje de eventos que provocan las fallas
  • Probabilidad de corrupción de los datos después
    de una falla

En general, las mediciones se hacen durante las
pruebas del sistema para determinar en qué
momento éste cumple dichos requerimientos.
54
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales consideraciones
  • La especificación cuantitativa de requisitos es
    difícil.
  • A veces los requerimientos no funcionales entran
    en conflicto e interactúan con otros
    requerimientos funcionales del sistema.
  • En principio, los requisitos funcionales y no
    funcionales debieran diferenciarse en el
    documento de requisitos.

55
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos del Dominio
  • Se derivan del dominio del sistema más que de las
    necesidades específicas de los usuarios.
  • Pueden ser nuevos requerimientos no funcionales,
    restringir los existentes o establecer cómo se
    deben ejecutar cálculos particulares.

56
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos del Dominio
  • Importantes, pues a menudo reflejan los
    fundamentos del dominio de aplicación.
  • Si no se satisfacen, es imposible que el sistema
    funcione adecuadamente.

57
Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos del Dominio problemas
  • Entendimiento - Conocimiento Implícito
  • Deben ser expresados en el lenguaje del dominio
    del problema.
  • No obstante, algo que es obvio para el experto en
    el dominio no tiene porque ser tal para el
    ingeniero de software.

58
Requisitos del Software
Requisitos del Usuario
  • Los requisitos del usuario para un sistema
    describen los requerimientos funcionales y no
    funcionales, de tal forma que sean comprensibles
    por los usuarios del sistema que no posean un
    conocimiento técnico detallado.
  • Deben redactarse utilizando el lenguaje natural,
    tablas y diagramas.

59
Requisitos del Software
Requisitos del Usuario
Problemas del Lenguaje Natural
  • Falta de claridad imprecisión, ambigüedad.
  • Confusión de requisitos mezcla de
    requerimientos, metas e información del diseño.
  • Conjunción de requisitos requisitos diferentes
    se expresan como uno solo.

60
Requisitos del Software
Requisitos del Usuario
Ejemplo de Requisito mal formulado
  • La base de datos deberá ayudar a la generación y
    control de la configuración de objetos es decir,
    objetos que a su vez son agrupaciones de otros
    objetos de la base de datos.
  • Los recursos para este control permitirán el
    acceso a los objetos en una versión de grupo
    utilizando un nombre incompleto.

61
Requisitos del Software
Requisitos del Usuario
Ejemplo de Requisito mal formulado
  • La descripción muestra información tanto
    conceptual como detallada.
  • Expresa la existencia de recursos de control de
    la configuraciónpero también el detalle de los
    recursos de control de la configuración, que
    debería estar ubicado en la especificación de
    requisitos del sistema.

62
Requisitos del Software
Requisitos del Usuario
Necesidad de Documento de Requisitos
  • Buena práctica para separar los requisitos del
    usuario de los requisitos detallados del sistema.
  • Por otro lado, los lectores no técnicos de los
    requisitos del usuario se confundirán con los
    detalles que sólo son relevantes a los lectores
    técnicos.

63
Requisitos del Software
Requisitos del Usuario
Ejemplo de otro Requisito mal formulado
  • Para ayudar a la ubicación de entidades en un
    diagrama, el usuario activará una grilla, en cms
    o pulgadas, mediante una opción en el panel de
    control. Inicialmente, dicha grilla estará
    desactivada, y se podrá activar (y desactivar) en
    cualquier momento durante una sesión de edición.
  • La opción de grilla se estará en la vista de
    reducción del ajuste, pero el número de líneas de
    la grilla se reducirá para evitar saturar el
    diagrama más pequeño con líneas de grilla.

64
Requisitos del Software
Requisitos del Usuario
Ejemplo de otro Requisito mal formulado
problemas...
  • Un requisito funcional conceptual que establece
    que el sistema de edición debe proveer una grilla.
  • Un requerimiento no funcional que provee
    información detallada de las unidades de la
    grilla (cms, pulgadas).
  • Un requerimiento de interfaz de usuario no
    funcional que define la manera en que la grilla
    es (des)activada por el usuario.

...en una misma oración!!
65
Requisitos del Software
Requisitos del Usuario
Ejemplo de otro Requisito mal formulado
problemas...
  • Define que la grilla está inicialmente
    desactivada sin embargo, no define sus unidades
    cuando se activa.
  • Provee alguna información detallada, como la de
    intercambiar las unidades, pero no el espaciado
    entre las líneas de la grilla.

muchas restricciones limitan la creatividad del
desarrollador luego, lo correcto sería
66
Requisitos del Software
Requisitos del Usuario
Ejemplo de Requisito bien formulado
  • El editor deberá proporcionar un recurso para la
    grilla, donde una matriz de líneas horizontales y
    verticales entregue un fondo para la ventana del
    editor. Esta grilla deberá ser pasiva, donde la
    alineación de entidades es responsabilidad del
    sistema.

67
Requisitos del Software
Requisitos del Usuario
Ejemplo de Requisito bien formulado (continuación)
  • Fundamento una grilla ayuda al usuario a crear
    un diagrama ordenado con objetos bien espaciados.
    Aunque en una grilla activa pueda ser de utilidad
    que los objetos se ajusten a las líneas de la
    grilla, la ubicación es imprecisa. El usuario es
    la mejor persona para decidir dónde se deberían
    ubicar los objetos.

68
Requisitos del Software
Requisitos del Usuario
Pautas para minimizar las malas interpretaciones
  • Inventar un formato estándar y asegurar que todos
    los requerimientos se ajusten a él.
  • Utilizar el lenguaje de forma consistente.
  • Resaltar el texto para ver las partes claves del
    requisito.
  • Evitar, en la medida de lo posible, usar el
    lenguaje técnico de computación. Esto será
    inevitable en los requerimientos del usuario.

69
Requisitos del Software
Requisitos del Sistema
  • Corresponden a descripciones de los requisitos
    del usuario.
  • Sirven como base para definir el contrato de la
    especificación del sistema y, por lo tanto, debe
    ser una especificación completa y consistente del
    sistema.
  • Son usados por los ingenieros de software como el
    punto de partida para el diseño del sistema.
  • Pueden ser escritos usando diferentes modelos del
    sistema (flujo de datos, objetos).

70
Requisitos del Software
Requisitos del Sistema
  • En principio, no debieran establecer lo que el
    sistema hará y no la forma en que se implementará.
  • Sin embargo, en el nivel de detalle requerido
    para especificar el sistema completamente, es
    casi imposible excluir toda la información de
    diseño.
  • Razones para lo anterior...

71
Requisitos del Software
Requisitos del Sistema
  • Una arquitectura inicial del sistema se define
    para ayudar a estructurar la especificación de
    requerimientos.
  • En muchos casos, los sistemas deben interactuar
    con otros ya existentes.
  • El uso de un diseño específico es un requisito
    externo del sistema.

72
Requisitos del Software
Requisitos del Sistema
  • Muchas veces se usa lenguaje natural para
    especificar requisitos del sistema pero esto
    puede causar los siguientes problemas
  • La comprensión del lenguaje natural radica en que
    los lectores y redactores de la especificación
    utilicen la misma palabra para el mismo concepto.
  • La especificación resultante es demasiado
    flexible.
  • No existe una forma fácil de modularizar los
    requisitos.

73
Requisitos del Software
Requisitos del Sistema
Notaciones para la Especificación de Requisitos
  • Lenguaje Natural Estructurado enfoque que
    depende de la definición de formas estándar o
    plantillas para expresar la especificación de
    requisitos.
  • Lenguajes de Descripción de Diseño se utiliza un
    lenguaje similar a uno de programación, pero con
    características más abstractas, para especificar
    los requisitos por medio de la definición de un
    modelo operacional del sistema.

74
Requisitos del Software
Requisitos del Sistema
Notaciones para la Especificación de Requisitos
  • Notaciones Gráficas usadas para los requisitos
    funcionales, complementadas con anotaciones de
    texto (ej. casos de uso).
  • Especificaciones Matemáticas notaciones basadas
    en conceptos matemáticos, como las máquinas de
    estado finito o los conjuntos.

75
Requisitos del Software
Requisitos del Sistema
Especificación en Lenguaje Estructurado
  • Forma restringida del lenguaje natural para
    redactar los requisitos del sistema.
  • Limitan la terminología usada, y se emplean para
    especificar los requisitos del sistema.
  • Incorpora construcciones de control derivadas de
    los lenguajes de programación y expresiones
    gráficas para dividir la especificación.

76
Requisitos del Software
Requisitos del Sistema
Especificación en Lenguaje Estructurado forma
estándar.
  • Descripción de la función o entidad a
    especificar.
  • Descripción de sus entradas y de dónde provienen.
  • Descripción de sus salidas y hacia dónde van.
  • Indicación de qué otras entidades se utilizan.
  • Si es un enfoque funcional, una precondición y
    una postcon-dición.
  • Descripción de los efectos colaterales.

77
Requisitos del Software
Requisitos del Sistema
Especificación basada en un PDL
  • Para contrarrestar las ambigüedades propias de la
    especificación en lenguaje natural, es posible
    describir los requisitos de forma operacional,
    usando un lenguaje de descripción de programas
    (PDL).

78
Requisitos del Software
Requisitos del Sistema
Especificación basada en un PDL
  • Se recomienda su uso en dos situaciones
  • Cuando una operación se especifica como una
    secuencia de acciones simples, y el orden de
    ejecución es importante.
  • Cuando se tienen que especificar las interfaces
    de hardware y software.

79
Requisitos del Software
Requisitos del Sistema
Especificación basada en un PDL
  • Desventajas
  • El lenguaje usado para redactar la especificación
    puede no ser suficientemente expresivo para
    expresar la funcionalidad del sistema.
  • La notación sólo es comprensible para la gente
    que tiene conocimientos de algún lenguaje de
    programación.
  • Los requisitos se consideran un diseño de la
    especificación del diseño más que un modelo para
    ayudar al usuario a comprender el sistema.

80
Requisitos del Software
Requisitos del Sistema
Especificación de Interfaces
  • Muchos sistemas de software deben operar con
    otros sistemas implementados e instalados de
    antemano.
  • Para la interacción es preciso especificar de
    forma precisa las interfaces a usar.
  • Las especificaciones se definen al inicio del
    proceso y se incluyen en el documento de
    requisitos.

81
Requisitos del Software
Requisitos del Sistema
Especificación de Interfaces tipos de interfaces.
  • Interfaces de procedimientos en las cuales los
    subsistemas existentes ofrecen una variedad de
    servicios que se obtienen al invocar a los
    procedimientos de la interfaz.
  • Las estructuras de datos que pasan de un
    subsistema a otro.
  • Las representaciones de datos (como el orden de
    los bits) establecidas para un subsistema
    existente.

82
Requisitos del Software
Requisitos del Sistema
Especificación de Interfaces ejemplo.
interface PrintServer // define un servidor de
impresión void initialize( Printer p
) void print( Printer p, PrintDoc d )
void displayPrintQueue( Printer p ) void
cancelPrintJob( Printer p, PrintDoc d)
void switchPrinter( Printer p1, Printer p2,
PrintDoc d)
83
Requisitos del Software
Requisitos del Sistema
Especificación de Interfaces ejemplo
(continuación).
  • La funcionalidad de las operaciones de la
    interfaz se definen utilizando el lenguaje
    natural estructurado, usando un PDL o alguna
    notación formal.
  • Las notaciones formales permiten definir
    interfaces de una forma no ambigua, pero por su
    naturaleza no son comprensibles sin capacitación
    especial.
  • Raramente se usan en la práctica, pero son
    ideales para la especificación de interfaces.

84
Requisitos del Software
Documento de Requisitos del Sistema
  • Denominado también Especificación de Requisitos
    del Software, es la declaración oficial de qué es
    lo que requieren los desarrolladores del sistema.
  • Debe incluir tanto los requisitos del usuario
    para el sistema como una especificación detallada
    de los requisitos del sistema.
  • No es un documento de diseñoal contrario, debe
    indicar lo qué el sistema debe hacer, no cómo
    hacerlo.

85
Requisitos del Software
Documento de Requisitos del Sistema
Usuarios del Documento de Requisitos.
  • Clientes del Sistema especifican los requisitos
    y los leen para verificar que cumplen sus
    necesidades. Especifican, también, los cambios en
    dichos requisitos.
  • Administradores Utilizan el documento para
    planear el proceso de desarrollo del sistema.
  • Ingenieros de Sistemas Usan los requisitos para
    comprender por qué se desarrollará el sistema.

86
Requisitos del Software
Documento de Requisitos del Sistema
Usuarios del Documento de Requisitos.
  • Ingenieros Testeadores del Sistema Utilizan los
    requisitos para desarrollar las pruebas de
    validación para el sistema.
  • Ingenieros Mantenedores del Sistema Usan los
    requisitos para ayudar a comprender el sistema y
    las relaciones entre las partes.

87
Requisitos del Software
Documento de Requisitos del Sistema
Documento de Requisitos seis propiedades a
cumplir.
  • Especificar de forma única el comportamiento
    externo del sistema.
  • Especificar las restricciones de la
    implementación.
  • Ser fácil de entender.
  • Servir como herramienta de referencia para los
    mantenedores del sistema.

88
Requisitos del Software
Documento de Requisitos del Sistema
Documento de Requisitos seis propiedades a
cumplir.
  • Registrar las previsiones del ciclo de vida del
    sistema.
  • Caracterizar las respuestas aceptables para los
    eventos no deseados.

89
Requisitos del Software
Documento de Requisitos del Sistema
Estructura del Documento sugerida por el IEEE
  • Introducción
  • Propósito del documento de requisitos
  • Alcance del producto
  • Definiciones, acrónimos y abreviaturas
  • Referencias
  • Resumen del resto del documento

90
Requisitos del Software
Documento de Requisitos del Sistema
Estructura del Documento sugerida por el IEEE
  • Descripción General
  • Perspectiva del producto
  • Funciones del producto
  • Características del usuario
  • Restricciones generales
  • Suposiciones y dependencias

91
Requisitos del Software
Documento de Requisitos del Sistema
Estructura del Documento sugerida por el IEEE
  • Requisitos Específicos que cubren los requisitos
    funcionales, no funcionales y de interfaz.
  • Apéndices
  • Índice

92
Requisitos del Software
Documento de Requisitos del Sistema
Estructura del Documento más completa
  • Prefacio
  • Introducción
  • Glosario
  • Definición de requisitos del usuario
  • Arquitectura del sistema

93
Requisitos del Software
Documento de Requisitos del Sistema
Estructura del Documento más completa
  • Especificación de Requisitos del sistema
  • Modelos del sistema
  • Evolución del sistema
  • Apéndices
  • Índice

94
  • Resumen

95
  • Una situación cotidiana
  • El software se desarrolla para satisfacer una
    necesidad
  • Veamos cómo un especialista en una materia
    satisface una necesidad

Juanita, Señora Estándar
Marlon, Gásfiter
Hola joven, sabe que el Yeison estaba jugando
con los monitos en el lavaplatos y ahora el agua
no se va
Hola Señora, cuénteme cuál es su problema?
96
Ejemplo Doméstico
Ahhlos Monitos son de papelde plástico?
De plástico joven, como el Max Steel ese
Comprendo Señora, entonces usted necesita
desbloquear la obstrucción del conducto evacuador
del lavaplatos, que es producido por un elemento
sólido
97
Ejemplo Doméstico
  • Qué ha hecho Marlon?
  • Marlon ha escuchado las necesidades de la Sra.
    Juanita
  • Marlon ha preguntado lo que necesita, para saber
    la gravedad del problema
  • Marlon ha abstraído elementos no importantes del
    problema (no le importan ni Yeison ni Max Steel)
  • Basado en lo anterior, Marlon ha descrito lo que
    necesita de la Sra. Juanita
  • Marlon ha Analizado el Requerimiento
  • Sigamos con Marlon y la Sra. Juanita

98
Ejemplo Doméstico
Por supuesto, Señora
Y lo puede arreglar, joven?
Voy a tener que hacer un corte en el conducto a
10 cm del lavaplatos y otro a 20 cm del suelo
para sacar el elemento, y luego volveré a poner
el mismo tubo. Por último sellaré todo con
silicona.
99
Ejemplo Doméstico
  • Qué ha hecho Marlon?
  • Marlon ha pensado en cómo resolver el problema
  • Marlon ha pensado en qué puede reutilizar en su
    solución propuesta (podría haber usado otro tubo
    y cobrar más, pero el es sabe que con el mismo
    funciona, y Marlon es muy ético)
  • Marlon ha descrito su solución en términos de los
    elementos que intervienen en la solución
  • Marlon ha Diseñado una Solución para el
    requerimiento
  • Sigamos con Marlon y la Sra. Juanita

100
Ejemplo Doméstico
Voy a entrar a Picar
Marlon está Implementando la Solución
101
Ejemplo Doméstico
Listo Señora, pruebe nomás, yo lo probé y
funciona
Funciona perfecto, joven!
Muy bien Señora, esta es mi tarjeta, cualquier
problema con el arreglo me avisa
102
Actividades para Hacer Software
  • Qué ha hecho Marlon?
  • Marlon ha probado su solución
  • Marlon ha ofrecido sus servicios para una
    eventual mantención de la solución

103
Actividades para Hacer Software
  • En resumen
  • Marlon Analizó el Requerimiento
  • Marlon Diseñó la Solución
  • Marlon Implementó la Solución
  • Marlon Probó la Solución
  • (Eventualmente) Marlon realizó la mantención de
    la solución
  • El enfoque de usado por Marlon es adecuado
    también para resolver un problema de software
  • Alguna crítica hacia Marlon?
  • El uso de lenguaje excesivamente técnico puede
    hacer que la Sra. Juanita no se convenza de que
    él entendió el problema, o puede no entender cómo
    se va a resolver

104
Proceso de Desarrollo de SW
  • Problemas de Software
  • Un problema de software es usualmente más
    complejo
  • Problema es más difícil de entender y resolver
  • Requiere de plazos más extensos para ser resuelto
  • Requiere más participantes en el desarrollo
  • Se deben generar productos intermedios en el
    desarrollo
  • Más actividades para hacer Software
  • Formalizar las actividades en un Proceso de
    Desarrollo
  • Administrar cambios y versiones de los productos
    de trabajo (Gestión de la configuración)
  • Gestionar, planificar y medir la ejecución del
    desarrollo
  • Obtener, desarrollar o adaptar herramientas y
    métodos para el desarrollo
  • Asegurar la Calidad del Software

105
Requisitos del Software
Resumen
  • Los requisitos especifican lo que el sistema
    debiera hacer, y definen restricciones sobre su
    operación e implementación.
  • Requisitos funcionales establecen los servicios
    que el sistema debiera proveer.
  • Requisitos no funcionales restringen el sistema a
    ser desarrollado o el proceso de desarrollo.
  • Requisitos de usuario son declaraciones de alto
    nivel de lo que el sistema debiera hacer.

106
Resumen
  • Requerimientos Funcionales
  • Tareas que el sistema debe poder realizar
  • Requerimientos No Funcionales
  • Propiedades que el sistema debe mantener
  • Cómo distinguirlos?
  • Funcionales Verbos
  • Listar, Imprimir, Buscar, Ingresar, etc.
  • No Funcionales Adverbios
  • Eficientemente, establemente, integradamente
  • Ojo, siempre buscar el detalle (buscar, por
    cuáles filtros? qué tan eficiente?)
  • Cómo Resolverlos?
  • Funcionales Análisis y Diseño (OO)
  • No Funcionales Arquitectura de Software

107
Requisitos del Software
Resumen
  • Requisitos del usuario debieran ser escritos en
    lenguaje natural, tablas y diagramas.
  • Los requisitos del sistemas son expresados para
    comunicar las funciones que el sistema debiera
    entregar.
  • Los requisitos del sistema pueden ser escritos en
    lenguaje natural estructurado, un PDL o en
    lenguaje formal.
  • Un documento de requisitos del software es una
    declaración oficial de los requisitos del sistema.
Write a Comment
User Comments (0)
About PowerShow.com