Ingenieria de Requerimientos - GEZZLER
43
Transcript of Ingenieria de Requerimientos - GEZZLER
*Post Longhorn Server
M.C.C. Luis Islas Hernández
Introducción
Ingeniería De Requerimientos:Un Acercamiento
Es aquel conjunto de técnicas que ayuda a los ingenieros de software a entender mejor el problema en el que trabajarán.
¿Cuál es el corazón de la Ingeniería de Requisitos?
Un conjunto de tareas guía.
¿A que conduce ese conjunto de tareas?
¿Qué es la Ingenieria de requisitos?¿Qué es la Ingenieria de requisitos?
•Cuál será el impacto del software sobre el negocio.
•Qué es lo que el cliente quiere.
•Cómo interactuarán los usuarios finales con el software.
Roger S. Pressman
Un requisito puede definirse como un atributo necesario dentro
de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales.
¿Qué es un requisito?¿Qué es un requisito?
La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar ymantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.
Otras definicionesOtras definiciones de Ingenieria de requisitos de Ingenieria de requisitos
Todas las actividades de la ingeniería desistemas/software relacionadas con:
• Identificación y documentación de necesidades de clientes y usuarios.• Creación de un documento que describe la conducta externa y las restricciones asociadas [de un sistema] que satisfará dichas necesidades.• Análisis y validación del documento de requisitos para asegurar consistencia, compleción y viabilidad.• Evolución de las necesidades.
¿Porque es ¿Porque es importanteimportante??
Programas elegantes resolviendo
Los problemas incorrectos.
Primero hay que entenderExactamente lo que el cliente
quiere antes de comenzar a diseñar.
¿Y cómo se aplica?¿Y cómo se aplica?
Siguiendo una serie de pasos,
tareas o fases.
Comenzando por una fase de inicio
y terminando con la coincidencia
entre la concepción del problema que
tiene el ingeniero de software y la
percepción del cliente.
Tu peorTu peor pesadilla pesadilla
Ralph Young
Un cliente entra en tu oficina, se sienta,
te mira directo a los ojos y dice:
“Yo sé que usted piensa que entiende lo que digo pero lo que usted no entiende es que lo que
digo no es realmente lo que quiero decir”
Y el problema es que…Y el problema es que…
El dinero esta en peligro, además no olvidemos que la reputación esta en juego.
El dinero es quizás lo más importante en el desarrollo de proyectos informáticos.
Otro detalle importante…Otro detalle importante…
¿Se pierde el tiempo con la Ingeniería de requisitos?
¡NO se pierde! Es realmente un punto importante que no debe omitirse.
InicioInicio
ObtenciónObtención
ElaboraciElaboraciónón
NegociacióNegociaciónn
EspecificacióEspecificaciónn ValidaciónValidación
Gestion de requisitosGestion de requisitos
InicioInicio
Una conversación informalUna conversación informal
Necesidad de negociosNecesidad de negocios
Se descubre un nuevo mercadoSe descubre un nuevo mercado
InicioInicio
Preguntas libres de contextoPreguntas libres de contexto
Comprensión básica del problema en cuestiónComprensión básica del problema en cuestión
Objetivo principalObjetivo principal
ObtencionObtencion
PreguntarPreguntar
•ClientesClientes•UsuariosUsuarios•Otros InteresadosOtros Interesados
•Qué es lo que se debe lograr.
•Forma en que el producto satisface las necesidades del negocio.
•Como se utilizara dia con dia.
NO es facil hacerlo.
ObtencionObtencion
Problemas de ámbito.Problemas de ámbito.
Problemas de comprensión.Problemas de comprensión.
Problemas de volatilidad.Problemas de volatilidad.
•Limite mal definido.•Detalles tecnicos innecesarios.
•Ellos no estan seguros.•No comprenden al 100% el dominio del problema.•Dificultad para comunicar necesidades.•Problemas cambian
•Conforme pasa el tiempo.
ElaboraciElaboracionon
• La información se expande y se refina.• Se enfoca en el desarrollo de un modelo técnico de:
1. Funciones.2. Caracteristicas.3. Restricciones.
• Es una acción del modelado de software.• Creación de escenarios de uso del sistema.
Principalmente se busca establecer una base firme para el diseño.
NegociacioNegociacionn
Piden más de lo que se puede lograr.Piden más de lo que se puede lograr.
Proponen requisitos que generan conflictosProponen requisitos que generan conflictos
•Se habla de la prioridad.Se habla de la prioridad.
•Riesgos asociados con cada requisito.Riesgos asociados con cada requisito.
•Impacto de cada requisito en el costo.Impacto de cada requisito en el costo.
•Impacto en el tiempo de entrega.Impacto en el tiempo de entrega.
NegociacioNegociacionn
Y al final...Y al final...
•Algunos requisitos se eliminan.Algunos requisitos se eliminan.
•Algunos requisitos se modifican.Algunos requisitos se modifican.
•Algunos requisitos de combinan.Algunos requisitos de combinan.
Ambas partes contentasAmbas partes contentas
EspecificacioEspecificacionn
•Un documento escrito.Un documento escrito.•Un conjunto de modelos gráficos.Un conjunto de modelos gráficos.•Un modelo matemático formal.Un modelo matemático formal.•Una colección de escenarios de uso.Una colección de escenarios de uso.•Un prototipo.Un prototipo.•Una combinacion de todos los anteriores.Una combinacion de todos los anteriores.
Una especificación podria ser…Una especificación podria ser…
EspecificacioEspecificacionn
Un documento escrito combinando:
•Lenguaje natural•Modelos gráficos.
Proyectos grandesProyectos grandes
•Escenarios de uso… siempre ycuando residan en ambientestecnicos que se comprendan bien.
Proyectos pequeñosProyectos pequeños•Es el producto final de laEs el producto final de laingenieria de requisitos.ingenieria de requisitos.
•Sirve como base para las Sirve como base para las siguientes actividades.siguientes actividades.
ValidacionValidacion
Mecanismo primario
Revisión tecnica formal.
•Se evalua la calidad.
•Sirve para asegurar que todos los requisitos se establezcan de manera precisa.
•Se buscan errores.•Areas que requieran clarificación.•Información faltante.•Inconsistencias.•Conflictos entre requisitos.
Examinan la especificación
ValidacionValidacion
Examinamos cada requisito frente a una serie de preguntas.
¿Los requisitos estan establecidos de manera clara?¿Pueden malinterpretarse?¿Cuales otros requisitos estan relacionados con este?
Buen metodo que se puede aplicar a muchas areas noSolo a ingenieria de requisitos.
Listas de verificación
Gestion de requisitosGestion de requisitos
“El deseo de cambios persiste durante la vida del sistema”.
Conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.
Se comienza identificando cada requerimiento.
Identificación
Se comienza identificando cada requerimiento.
Tablas de rastreabilidad
Gestion de requisitosGestion de requisitos
Tablas de rastreabilidad
Gestion de requisitosGestion de requisitos
Tablas de rastreabilidad
•De las caracteristicas.Relacion requisitos/caracteristicas observables.•De la fuente.Indica la fuente de cada requisito.•De dependencia.Relacion entre si de los requisitos.•Del subsistema.Categorias de requisitos.•De la interfaz.Relaciones con las interfases internas y externas.
Elementos del modelo de Analisis.Elementos del modelo de Analisis.
Basados en escenariosBasados en escenarios
Basados en ClasesBasados en Clases
De comportamientoDe comportamiento
Elementos
Orientados al flujoOrientados al flujo
Elementos orientados al flujo.Elementos orientados al flujo.
Entradas
Procesos
Salida
En efecto es posible crear un modelo de fluyo para cualquier sistema basado en computadoras, sin importar su tamaño o complejidad.
*Post Longhorn Server
Negociación de requisitos.
¿Qué es la negociación de requisitos?¿Qué es la negociación de requisitos?
Definiéndola, la negociación de requisitos es una función de la ingeniería de requisitos en la cual se llega a “negociar” con el cliente los requisitos que van a satisfacerse con el sistema, de modo que ambas partes salgan ganando, es decir, que obtengan lo que merecen.
Objetivos de la negociación de requisitosObjetivos de la negociación de requisitos
Hay determinadas cosas que se persiguen al negociar los requisitos, y son las siguientes:•Satisfacer a ambas partes (cliente y equipo de desarrollo).•Determinar requerimientos que puedan cumplirse (realistas).•Satisfacer los intereses de la otra parte (cliente en nuestro caso).•Realizar propuestas de posibles requerimientos necesarios pero que no habían sido detectados.•Establecer requerimientos que se encuentren dentro del rango limitado por las restricciones del proyecto tales como recursos, personal, tiempo.
Negociar es llegar a un acuerdoNegociar es llegar a un acuerdo
Porqué? Porque cuando se llega a un acuerdo, quiere decir que todos los que participamos del acuerdo estamos satisfechos con lo que hemos obtenido de él.
“Un acuerdo es el arte de dividir un pastel de tal forma que cadaUno piense que se quedó con la rebanada más grande.”
Ludwig Erhard
¿Porqué hay que negociar los requisitos?¿Porqué hay que negociar los requisitos?
Es de vital importancia negociar los requisitos con el cliente en vez de tener una simple charla de lo que ellos quieren porque de esa forma se evitan cosas como:•No hacer todo lo que el cliente requiere por incapacidad de hacerlo.•Quedar mal con el cliente.•Hacer las cosas pero utilizar más recursos de los disponibles y emplear mas tiempo del estipulado.
Actividades de la negociación de requisitosActividades de la negociación de requisitos
Bohem ha establecido que hay 3 actividades que componen la negociación de requisitos, y el cumplimiento de estas actividades asegurará un acuerdo exitoso en el que todas las partes salgan ganando. Dichas actividades son:•Identificación de l@s interesad@s clave en el sistema o subsistema.•Determinación de las condiciones ganadoras (requisitos) de los interesados.•Negociación de dichas conexiones para reconciliarlas(establecerlas) en un conjunto de requerimientosdel tipo ganar-ganar.
*Post Longhorn Server
Validacion de requisitos.
¿Porqué validar los requisitos?¿Porqué validar los requisitos?
Cuando estamos haciendo funciones como determinar, formular, negociar requisitos es necesario examinarlos detalladamente para conocer su consistencia, omisiones y ambigüedades (es decir, interpretado de varias formas, lo que da lugar a dudas). Estos requisitos son jerarquizados debido a que son puestos en paquetes de requisitos que son implementados como incrementos de software (prototipos) que son entregados al cliente (Esto en caso de trabajar con un modelo de desarrollo de software que en donde se entregan prototipos regularmente durante el ciclo de vida del software).
Preguntas clave en la revisión de los Preguntas clave en la revisión de los requisitos.requisitos.
¿El requisito es necesario en realidad o es una característica agregada irrelevantemente para el objetivo del sistema?¿Cada requisito es alcanzable en el ambiente técnico que recibirá al sistema o producto?¿El modelo de requisitos refleja de manera adecuadala información, la función y el comportamiento?¿Cada requisito está limitado y no es ambiguo?¿Algunos requisitos entran en conflicto con otros?
*Post Longhorn Server
Extras.
Muy importante: Muy importante: ¿Es lo mismo?¿Es lo mismo?
¿Son iguales?¿Son iguales?
Ingeniería de Requisitos
Análisis de Requisitos
Ingeniería de Requisitos
Es aquel conjunto de técnicas que ayuda a
los ingenieros de software a entender mejor
el problema en el que trabajarán.
Análisis de Requisitos
Es aquel que genera la especificación de características operacionales de software
; Indica la interfaz del software con otros elementos del sistema, y establece las
restricciones que debe tener el software.
El Ing. de Software se extiende sobre requisitos básicos establecidos en la Inge-
nieria de requisitos.
Caso de la vida real 1.
Consecuencias de no aplicar la Ingeniería de requisitos adecuadamente.
•Cliente con poco tiempo.
•Cliente mentiroso.
•Desarrolladores cómodos.
•Mala relación con el cliente.
El cliente ha amenazado con acciones legales.
El proyecto ha cambiado mucho.
El cliente se tomo las cosas personales.
El proyecto se ha vuelto un desafió.
Caso de la vida real 2.
Consecuencias de no aplicar la Ingeniería de requisitos adecuadamente.
•Cliente abusador.
•Cliente paranoico.
•Desarrolladores temperamentales.
•Mala relación con el cliente.
El cliente no nos dejo respirar.
Recibía de 7 a 15 emails diarios y de 5 a 6 llamadas diarias.
El cliente cambio de parecer muchas veces.
El cliente llamaba a las 10/11 de la noche al celular.
Preguntas y Preguntas y respuestasrespuestas
