ir10 refinando definicion sistema
DESCRIPTION
Ingeniería de REQTRANSCRIPT
Propósito de la sesión• Describe como se realiza el
proceso de refinamiento del sistema.
Contenido de la sesión• Refinamiento del sistema.
Propósito y contenido de la sesión
Puntos claves
• Un sistema completo de requisitos puede ser determinadodefiniendo las entradas, las salidas, las funciones, los atributosy los atributos del entorno del sistema
• Los requisitos deben excluir la información relacionada con elproyecto, tal como horario, planes del proyecto, presupuestosy test de pruebas, así como la información del diseño
• Los requisitos y el proceso del diseño son iterativos; losrequisitos conducen a la selección de ciertas opciones deldiseño, que alternadamente pueden iniciar nuevos requisitos.
• Las restricciones del diseño son restricciones en el diseño delsistema o del proceso
Definición de requerimientos de software
• Una Capacidad del software necesaria para el usuario para resolver el problema y alcanzar un objetivo
• Una capacidad del software que se debe satisfacer o poseer un sistema o un componente del sistema para satisfacer el contrato, el estándar, la especificación, o la otra documentación formalmente impuesta.
Elementos del sistema
Entradas al Sistema
Salidas del Sistema
Funciones del Sistema
Características del Sistema
Atributos del entorno del Sistema
Relación entre las características y los requerimientos del software
• Las características son simples descripciones de un deseo y comportamiento beneficioso– El documento de visión cita las características en el lenguaje del usuario
• Los requerimientos de software expresan las características con más detalles, usando uno o mas especificaciones de requerimientos de software que deben ser cumplidos por los desarrolladores para suministrar las características al usuario
• Las características ayudan a comprender y comunicar a un alto nivel de abstracción, pero no podemos describir el sistema y escribir código de esas descripciones
• Los requisitos de software son específicos.– Podemos codificar de ellos y deben ser lo suficientemente específico para ser
"Sometidos a pruebas"; es decir, podemos validar el sistema (se implementa un requisito real)
Relación entre las características y los requerimientos del software
Documento Visión Requerimientos del sw
Característica 63: El sistema deseguimientos de defectosproporcionará la informaciónpara ayudar al usuario adeterminar estado del proyecto.
SR63.1 La información será proporcionadaen un histograma que demuestra tiempoen el eje “x” y el número de los defectosencontrados en el eje “y”.
SR63.2 El usuario puede ingresar elperíodo en días, semanas, o meses.
SR63.3 Un informe ejemplo se demuestraen la ilustración 1.
El dilema de los requerimientos: “que” versus “como”
Excluir la Información del proyecto• Calendarios, plan de la administración de la
configuración, planes de verificación y validación, presupuestos, …
Excluir la Información del diseño• Diseño del sistema, arquitectura
Requerimientos de Software (1)
• Requerimientos Funcionales• Requerimientos no Funcionales
– Usabilidad– Confiabilidad
• Disponibilidad• Promedio entre fallas• Promedio de reparación• Exactitud• Máximo número de defectos o ratio de defectos• Defectos por tipo
– Funcionamiento• Tiempo de respuesta• Rendimiento, transacciones por segundo• Capacidad, número de clientes o transacciones• Modos de degradación
– Adaptabilidad
Requerimientos de Software (2)
• Restricciones del diseño– Son limitaciones en el diseño del sistema o proceso
• Use Oracle BDMS• Programar en Visual Basic• Use la librería de clases XYZ• Compatibilidad con los sistemas existentes• Estándares
• ¿Las Restricciones de Diseño son requisitos verdaderos?– No, porque no representan a ninguno de los 5 elementos
del sistema– Si, cuando es elevada a nivel de negocio, política o asunto
técnico.
Requerimientos de Software (3)
• Restricciones del diseño– Son limitaciones en el diseño del sistema o proceso
• Use Oracle BDMS• Programar en Visual Basic• Use la librería de clases XYZ• Compatibilidad con los sistemas existentes• Estándares
• ¿Las Restricciones de Diseño son requisitos verdaderos?– No, porque no representan a ninguno de los 5 elementos
del sistema– Si, cuando es elevada a nivel de negocio, política o asunto
técnico.
Puntos claves
• Para soportar las actividades del diseño y la codificación, los casos de uso desarrollados en las actividades de recopilación de requerimientos deben estar completos
• Los casos de uso son apropiados cuando el sistema es rico en funcionalidad y debe soportar diferentes tipos de usuarios
• Los casos de uso no son tan efectivos cuando aplicamos a sistemas sin usuarios o con pocos usuarios y pocas interfaces, aquellos con principalmente requisitos no funcionales y restricciones de diseño
Redundancia del problema
• Los casos de uso esta dirigido a la redundancia significativa, aumentando el tamaño de la documentación de los requisitos– Muchos casos de uso son muy similares, sin embargo no son
lo suficientemente distintos para descomponerlo– El mantenimiento puede ser un desafío cuando el
comportamiento común es expresado en muchos casos de uso
• Requiere el uso adicional relaciones de caso, como la generalización, include, extend; que añaden complejidad.
Refinando las especificaciones de caso de uso
Ítem ValorNombre caso de uso Control de luzBreve descripción Este caso de uso describe la forma como las luces son
encendidas o apagadas o su intensidad es disminuida cuando los usuarios presionan los interruptores de luz de varias maneras.
Flujo de eventos El flujo básico del caso de uso comienza cuando el Residente presiona el botón del Control de Interruptores(CI). Si el Residente deja de presionar el CI dentro del periodo de tiempo, el sistema “conmuta” el estado de la luz. Esto significa:• Si la luz estaba encendida, la luz se apaga, no hay
iluminación.• Si la luz estaba apagada, la luz se enciende con el ultimo
nivel de iluminación conocido.
Refinando las especificaciones de caso de uso
Ítem ValorFlujo alternativo de eventos
Si el Residente mantiene pulsado el CI por mas de un segundo, el sistema inicia la disminución de la iluminación para el nivel indicado de luz. La siguiente acción ocurre mientras el residente continua presionando el botón CI:1. La iluminación se incrementa lentamente hasta el valor máximo a un
ratio de 10% en un segundo.
2. Cuando el nivel máximo de iluminación es alcanzado, la iluminación disminuye lentamente hasta el valor mínimo a un ratio de 10% en un segundo
3. Cuando el valor mínimo es alcanzado, la secuencia del caso de uso regresa al paso 1.
Cuando el residente libera la presión del botón CI.
4. El sistema cesa el cambio de iluminación.
Refinando las especificaciones de caso de uso
Ítem ValorPre condiciones • El botón seleccionado CI debe estar “Graduación
de iluminación activada” • El botón seleccionado CI debería estar pre
programado para el control de banco de luces.Post condiciones Al salir de este caso de uso, la intensidad de la luz
es recordado por el sistema.Requerimientos especiales
El nivel mínimo de luz no puede ser 0. Debe ser un valor mínimo aceptable tal que las luces sean adecuadas para la noche.
Puntos Claves
• Un paquete moderno de ERS (ERS, Software Requirements Specification) es una colección de artefactos que describen el comportamiento externo del sistema (modelo conceptual).
• El documento de Visión es la entrada del moderno ERS. Es una declaración ampliada de las necesidades del usuario, metas y objetivos, mercados objetivos y características del sistema; lo último se enfoca en los detalles a implementar.
• El “correcto balance” de la técnica esta en el mix del modelo de casos de uso y la especificación tradicional de requerimientos.
El moderno paquete ERS
• Históricamente, la técnica de documentación de requerimientos fue usar el lenguaje natural
• El mejoramiento de la técnica derivo en el varios estándares, tal como IEEE (Institute of Electrical and Electronics Engineers) 830: Standard for Software Requirements Specification (1994).
• Con las herramientas y técnicas hoy, el ERS es una estructura lógica en vez de un documento físico.
El moderno paquete ERS
• Es un paquete activo y viviente.• Tiene varios papeles cuando se comienza con el desarrollo.
– Es la base para la comunicación entre desarrolladores y los grupos externos, usuarios y stakeholders.
– Formalmente e informalmente representa una acuerdo entre las partes. Se desarrolla lo que esta en ello.
– El administrador del proyecto lo usa como estándar en las discusiones con el equipo de proyecto
– Sirve de entrada al diseño e implementación– Sirve de entrada al testeo y aseguramiento de la calidad– Controla la evolución del sistema durante toda la fase de
desarrollo
¿Quién es el propietario del paquete ERS?
• ¿Quién es responsable de crear y mantener los componentes del ERS?– Usualmente, los miembros del equipo– El análisis del sistema refinara el documento de visión– Recuerde, es un artefacto vivo y necesita ser actualizado
Sobre la ambigüedad y especificidad
• El requerimiento “sweet spot” es punto de balance de la gran cantidad de comprensibilidad y la mínima cantidad de ambigüedad
• Encontrar el “sweet spot” dependerá de las habilidades de los miembros del equipo, el contexto de la aplicación y el nivel de seguridad
• Si el riesgo de malinterpretar es inaceptable, más técnicas de requerimientos formales es necesario ser aplicado.
Encontrando el “sweet spot”
• ¿Realmente, tenemos que especificar Pantone 287 como el fondo de nuestras GUI? ¿No? ¿Le gusto el color la ultima vez?
• ¿A que nivel de detalle de especificar los requisitos para evitar cualquier cambio?• Eso depende.
El principal reto es detallar
suficientemente los
requerimientos
Caja de luz
• Características– Controlado por un
microprocesador– Almacena el estado del botón
Count si ha sido pulsado un numero par o impar de veces
– El detector de bombilla quemada destella la bombilla restante
Objetivo del ejercicio
• Escribir de manera clara y simple los requerimientos– Usando el lenguaje natural o los casos de uso– Para el ejercicio, el usuario esta disponible para entrevistarlo, así se
puede refinar los requerimientos
Especificación de requerimientos (Davis,1993)
• Después de pulsar on (antes pulso off) el sistema esta encendido.
• Después de pulsar off (antes pulso on) el sistema esta apagado.
• Si esta en ON, si “Count” ha sido presionado un numero impar de veces, brilla “Odd”.
• Si esta en ON, si “Count” ha sido presionado un numero par de veces, brilla “Even”.
• Si uno de las luces esta quemada el otro debe parpadear a intervalos de 1 segundo
¿Es suficiente?
• La especificación es suficiente para la mayoría de casos.• Refleja la forma como el dispositivo debe trabajar• Para el programador, quien debe escribir el código, descubre
por lo menos la siguiente ambigüedad: – ¿Qué significa parpadear a intervalos de 1 segundo?– ¿Todavía parece obvio?
¿Ciclo A o B?
• ¿Cuál escoge? ¿Ciclo de servicio A o B?– Aunque la mayoría escoge B, esta claro que el requerimiento es
ambiguo. – El programador preguntara al cliente ¿Qué ciclo debe ser usado?
• Si el programador no es perspicaz o no reconoce la ambigüedad o piensa “Sé que significa porque se como debe trabajar”– El proyecto podría estar en riesgo– Para la mayoría de aplicaciones, no es importante si se enciende
durante un segundo o 0.25 segundos.– Si el equipo es electro quirúrgico si importa .
¿Cuál es nivel de especificidad?
• Depende del contexto de la aplicación• ¿Cuán capaces para tomar las decisiones correctas son los
desarrolladores?• Mínimo nivel de seguridad para hacer preguntas donde hay
ambigüedad– Para el equipo electro quirúrgico se debería ahondar en la
especificación• Tiempo de elevación• Precisión del tiempo• Voltaje, etc.
Mary tiene un pequeño cordero
• Tiene 1ª: mantiene en posición como propiedad ….. 4ª: Adquiere o toma posesión de: obtiene (como en “lo mejor”) 4c: ACEPTA; Tiene matrimonio … 5ª: Marcado o caracterizado por (tiene el cabello rojo)… 10ª: Mantener una posición de ventaja… 10b: TRAMPA, ENGAÑO… 12b: DAR A LUZ (tener un bebe)… 13: Compartir (tener una cena)… 14: SOBORNO, (se puede tener a un precio)
• Cordero 1ª: Una joven oveja de menos de un año de edad o sin dientes permanentes … 1b: El joven de los animales (ej. Pequeños antílopes)… 2ª: Una persona caballerosa o débil como un cordero… 2b: MASCOTA… 2c: Una persona fácil de engañar o engañada, especialmente en falsificación de pagares… 3ª: Carne de cordero usado como comida.
Técnicas de desambiguación
• Memorización heurística– Preguntar al grupo de desarrollo, usuarios o stakeholder
• Técnica de la palabra clave– El codero de Mary
• Técnica énfasis– Lea el requisito en voz alta y enfatice las palabras individuales hasta tener
muchas interpretaciones como sea posible• Si sólo una interpretación es correcta, declare de nuevo el requerimiento• Si múltiples interpretaciones son correctas, generar requerimientos
adicionales• Otras técnicas
– Use figuras, gráficos u otros métodos formales
¿Qué hacer?
• Para encontrar “sweet spot”– Use el lenguaje natural si fuera posible– Use figuras y diagramas– Cuando este en duda, pregunte– Argumente sus especificaciones con mas métodos formales
• Entrene a su equipo a reconocer problemas de ambigüedad y como solucionarlos
Puntos claves
• Los métodos técnicos son apropiados cuando la descripción de los requerimientos son demasiados complejos para decirlo en lenguaje natural o si no puede permitirse malas interpretaciones
• Los métodos técnicos son seudocódigo, diagrama de estados finitos, arboles de decisión, diagrama de actividades, modelo entidad relación, análisis orientado a objetos y análisis estructurado
Puntos clave
• Tener un conjunto de requerimientos de calidad es objetivo principal, estos requisitos deben cubrir nueve medidas de calidad
• Las lista de chequeo pueden ser usadas para asegurar la calidad de los requerimientos, modelo de casos de uso, especificación de casos de uso y actores
• Una alta calidad en ERS tiene un buen TOC, a buen índice, historial de revisiones y glosario
Nueve medidas de la calidad
• Correcto• Inequívoco (no ambiguo)• Completo• Consistente• Clasificado por importancia y estabilidad• Verificable• Modificable• Trazable• Entendible
Completitud del conjunto de requerimientos
Si y solo si describen todo los requisitos significativos concernientes al usuario, relacionados con al funcionalidad, el rendimiento, las restricciones de diseño, atributos o las interfaces externas
• IEEE 830-1993, §4.3.3, 1994
Asegurando la completitud
• Asegurarse que las figuras, etiquetas y diagramas tienen las etiquetas y referencias apropiadas
• Algunos aspectos pueden ser evaluados por un desarrollador sin conocimiento especial de la aplicación– La raíz cuadrada de un numero – ¿Si es negativo?
• Revisar las entradas de las clases realizables para asegurarnos que el comportamiento de sistema este descrito para entradas válidas e invalidas
Completitud en los requerimientos no funcionales
• A menudo se descuida aspectos de rendimiento y restricciones de diseño o suposiciones sobre las interfaces externas con otros sistemas
• Se debería crear una lista de chequeo siguiendo las guías en el área de usabilidad, confiabilidad, rendimiento y suportabilidad. Asimismo, para la restricciones de diseño.
Completitud de los requerimientos funcionales
• Omitir la funcionalidad es difícil• Los desarrolladores técnicos no saben si se ha omitido alguna
funcionalidad– La funcionalidad es nueva
• A veces, la funcionalidad es profundamente arraigada y obvia para el usuario– En un sistema de nómina, el pago del día feriado
• El uso de técnicas de caso de uso ayudan
Completitud a través del prototipo
• Los storyborads, la revisión de requerimientos y los prototipos nos acercaran mejor a los verdaderos requerimientos.
• El equipo de desarrollo debe dar un paso adicional con preguntas “que pasa-si” (what-if) para las condiciones limites del sistemas, excepciones y eventos inusuales.
Consistencia en el conjunto de requerimientos
• Si solo si ningún conjunto individual de requerimientos esta en conflicto con otro– IEEE 830-1993, §4.3.4.1, 1994
• Los conflictos toman varias formas y son visibles en varios niveles de detalle– Si esta formalizada y automatizada, se identifican mecánicamente– Sino es necesaria una evaluación manual
• Algunas veces, son obvios– Cuando ocurre X se da la acción P– Cuando ocurre X se da la acción Q
• Los prototipos ayudan en la consistencia de los requerimientos• Los profesionales de testeo y aseguramiento de calidad lo hacen a través de
una evaluación manual
Ranqueo de requirimientos por importancia y estabilidad
• En un conjunto de alta calidad, los desarrolladores, clientes y otros stakeholders tienen ranqueado los requerimientos por importancia para el cliente y en términos de estabilidad– IEEE 830-1993, §4.3.5, 1994– Importante en el alcance del proyecto
• Los recursos son insuficientes para implementar todos los requerimientos
• Por eso, se planifica y presupuesta• Es útil saber que requerimientos son volátiles y que requerimientos el
usuario considera críticos– Los requerimientos tienen atributos como: costo, riesgo, dificultad y otros.
(Documento visión)• Basados principalmente en la estrategia de implementación
– Los atributos importancia y estabilidad son asociados con la percepción del usuario del mundo
Ranqueo de requerimientos
• Dada esta información y otros factores, se debe determinar el porcentaje para determinar la importancia y relativa volatilidad.– El administrador del proyecto debería estar preparado para dedicar
una proporcionalidad alta de recursos en SR103 y SR172– Igualmente en SR071
Requerimientos verificables
• Es verificable en conjunto si y solo si cada uno de los componentes contenidos en los requerimientos es verificable
• Los requerimientos pueden ser considerados verificables si y solo si allí existe un finito, costo efectivo del proceso con el cual una persona o máquina puede determinar que el desarrollo del sistema de software satisface verdaderamente los requerimientos– IEEE 830-1993, §4.3.6, 1994
Pruebas para verificar los requerimientos
• No es posible proveer una prueba científica rigurosa de verificación para cada requisito, pero eso no es generalmente necesario.
• La responsabilidad del personal de pruebas (testing) y de aseguramiento de la calidad (quality assurance) es crear los apropiados casos de prueba y los procedimientos de prueba para llevar la comprobación en cuanto el software ha sido desarrollado.– Ellos necesitan requerimiento bien definidos y sin ambigüedad– Es común tener una reunión con los especialistas de las pruebas y
preguntarles• ¿Esta Ud. Seguro que puede crear un “test script” para verificar que el
requerimiento ha sido satisfecho?
Típicas reacciones de los desarrolladores y/o profesionales de las pruebas en relación a la verificación
• El sistema debe soportar 1000 usuarios simultáneamente– Eso depende de que son capaces de a hacer cuando ellos están conectados
(logged in).– Si el usuario tiene abierta las posibilidades podrían entrar a una transacción
que la aplicación explore secuencialmente a través de cada registro de la base de datos• Podría ser difícil de verificar que el sistema tiene mil usuarios cargados• Hay una probabilidad mínima pero diferente de cero que los 1000
usuarios decidan realizar tal transacción al mismo tiempo• Si los usuarios están limitados a cierta clase de transacciones y si
podemos determinar una típica, la transacción costosa, podemos verificar que el requerimiento ha sido satisfecho con un razonable grado de certeza, aunque tendremos que usar una herramienta de carga para simular 1000 terminales activos
Típicas reacciones de los desarrolladores y/o profesionales de las pruebas en relación a la verificación
• El sistema responderá a una consulta arbitraria en 500 milésimas de segundo– Eso depende de lo que signifique arbitrario. Si el rango de las posibles consultas es finita y si
podemos identificar la consulta más compleja, nosotros podemos verificar el comportamiento del sistema.
• El tiempo de visualización será de “forma placentera” – No se preocupe por eso. La belleza esta en el ojo del espectador
• El sistema será amigable con el usuario– Esto es igual de incorrecto que “forma placentera”– Pero sin definir cuidadosamente los términos y detalles, “amigable al usuario” es una invitación a
la discusión• El sistema exporta vista de datos en el formato separado por comas
– Me gustaría aclarar los detalles; por ejemplo, ¿Qué sucede si la vista de datos es nula?– Pero en principio, si, podemos verificar que el sistema produce el comportamiento deseado en
esta área.• La verificación y validación son aspectos importantes para desarrollar software de alta calidad.
Conjunto de requerimientos modificables
• Si sólo si su estructura y estilo son tal que cualquier cambio de los requerimientos pueden ser hechos fácilmente, completamente y consistentemente, mientras se conserva la estructura y estilo existente. – IEEE 830-1993, §4.3.7, 1994– Estos requerimientos tienen mínima redundancia y están
bien organizados, con una tabla de contenido, índice y referencia cruzada.
– Podría o no mantenerse el paquete de requerimientos con una herramienta automatizada. Aunque es una necesidad en sistemas grandes, que pueden tener miles de requisitos.
Trazabilidad de requerimientos
• Si sólo si cada uno de los requerimientos esta claro y existe un mecanismo que hace factible referirlo en el futuro desarrollo– IEEE 830-1993, §4.3.8, 1994– Los requerimientos tienen identificadores como etiquetas o números– Algunos componentes necesitaran “trazar” a otros componentes del mismo proyecto
y posiblemente del mismo paquete.• El cambio de un requerimiento podría afectar a otro requerimiento• Algunos requerimientos pueden ser descritos como sub o hijo, por lo que la
trazabilidad es obvia.– La trazabilidad permite contestar “Que pasa-si”
• ¿Qué pasa si cambiamos este requisito?• ¿Interactúa con el desarrollo de software y, si es así, con qué elementos?• ¿Fuerza a revisar el plan de pruebas, si es así, cuales?
– Para el mismo proyecto se puede usar la matriz de trazabilidad
Requerimientos entendidos
• Un conjunto de requerimientos es entendible si el usuario y el desarrollador comprenden los requerimientos individuales y la funcionalidad completa.