Title: Metodolog
1 Metodologías de Análisis
- Pedro Francisco Godoy Barrera
- Ingeniero Civil Informático
2Calendarizació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
3Evaluació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
4Presentación
- Dos personas desconocidas
- Tiempo máximo de 10 minutos, interactuar y
conocerse. - Objetivo Presentar a su compañero.
5Expectativas
- Qué esperan recibir de este curso
- Intereses personales
6Metodologías de Análisis
7Contexto
- 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.
8Contexto
- 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
9Contexto
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).
10Contexto
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.
11Contexto
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.
12Contexto
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
13Contexto
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.
14Contexto
Análisis
- El modelo de análisis lo componen 4 elementos de
modelado
- Modelos basados en Escenarios
- Modelos de Flujo
- Modelos basado en clases
- Modelos de comportamiento
15Contexto
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.
16Contexto
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.
17Contexto
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).
18Contexto
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
19Contexto
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.
20Contexto
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.
21Contexto
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.
22Metodologías de Análisis
23Requisitos 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.
24Requisitos del Software
Tópicos a Cubrir
- Requisitos Funcionales y no Funcionales.
- Documento de Requisitos de Software.
25Requisitos 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.
26Requisitos 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.
27Requisitos 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.
28Requisitos 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.
29Requisitos 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.
30Requisitos 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.
31Requisitos 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.
32Requisitos 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.
33Requisitos 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.
34Requisitos 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.
35Requisitos 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.
36Requisitos 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.
37Requisitos 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.
38Requisitos 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.
39Requisitos 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.
40Requisitos 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.
41Requisitos 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.
42Requisitos 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.
43Requisitos 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á.
44Requisitos 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.
45Requisitos 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.
46Requisitos 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.
47Requisitos 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.
48Requisitos 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.
49Requisitos 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.
50Requisitos 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
51Requisitos del Software
Requisitos Funcionales y No Funcionales
Requisitos No Funcionales métricas
- Facilidad de Uso
- Tiempo de Capacitación
- Número de cuadros de ayuda
52Requisitos 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
53Requisitos 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.
54Requisitos 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.
55Requisitos 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.
56Requisitos 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.
57Requisitos 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.
58Requisitos 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.
59Requisitos 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.
60Requisitos 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.
61Requisitos 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.
62Requisitos 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.
63Requisitos 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.
64Requisitos 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!!
65Requisitos 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
66Requisitos 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.
67Requisitos 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.
68Requisitos 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.
69Requisitos 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).
70Requisitos 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...
71Requisitos 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.
72Requisitos 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.
73Requisitos 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.
74Requisitos 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.
75Requisitos 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.
76Requisitos 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.
77Requisitos 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).
78Requisitos 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.
79Requisitos 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.
80Requisitos 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.
81Requisitos 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.
82Requisitos 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)
83Requisitos 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.
84Requisitos 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.
85Requisitos 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.
86Requisitos 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.
87Requisitos 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.
- Servir como herramienta de referencia para los
mantenedores del sistema.
88Requisitos 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.
89Requisitos 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
90Requisitos 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
91Requisitos 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.
92Requisitos del Software
Documento de Requisitos del Sistema
Estructura del Documento más completa
- Definición de requisitos del usuario
93Requisitos del Software
Documento de Requisitos del Sistema
Estructura del Documento más completa
- Especificación de Requisitos del sistema
94 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?
96Ejemplo 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
97Ejemplo 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
98Ejemplo 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.
99Ejemplo 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
100Ejemplo Doméstico
Voy a entrar a Picar
Marlon está Implementando la Solución
101Ejemplo 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
102Actividades 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
103Actividades 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
104Proceso 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
105Requisitos 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.
106Resumen
- 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
107Requisitos 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.