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.