Ingenieria requisitos

44 %
56 %
Information about Ingenieria requisitos

Published on March 9, 2014

Author: ramiroeddymamani

Source: slideshare.net

INGENIERIA DE REQUISITOS Lic. Roxana Laurel R.

INTRODUCCION  Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir... No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal... Ninguna otra tarea es tan difícil de rectificar a posteriori...  F. P. Brooks, 1987

LA EXPERIENCIA EMPIRICA DEMUESTRA…       Los requisitos contienen demasiados errores Muchos de estos errores no se detectan al principio Muchos de estos errores podrían ser detectados al principio No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial Además, los programadores obedecen los requisitos (cuando existen).

CONSECUENCIAS  El sistema resultante no satisfará a los usuarios  Se producirán desacuerdos entre usuarios y desarrolladores  Puede ser imposible demostrar si el software cumple, o no, los requisitos  Se gastará tiempo y dinero en construir el sistema equivocado

COMPLEJIDAD • OJO: No estamos hablando de sistemas de 15 o 30 requisitos. También hay      Sistemas de cientos de requisitos Sistemas de miles de requisitos Sistemas de 5.000 requisitos Sistemas de más de 10.000 Sistemas de incluso 60.000 requisitos

1995/200: THE CHAOS REPORT      Gasto anual en EEUU: $250 mil millones en unos 175.000 proyectos. 31,1% (23%) son cancelados 52,7% (49%) cuestan un 190% más de lo estimado Un 16,2% (28%) será finalizado a tiempo y dentro del presupuesto, pero el producto final poseerá (aprox.) la mitad de los requisitos iniciales

ACUMULACION DE ERRORES

¿QUÉ ES UN REQUISITO?  Un requisito es una ”condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado”.  También se aplica a las condiciones que debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificación.

INGENIERIA DE REQUISITOS o o La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible. Los requisitos pueden ser funcionales y no funcionales

REQUISITOS FUNCIONALES Definición de los servicios que el sistema debe proporcionar, cómo debe reaccionar a una entrada particular y cómo se debe comportar ante situaciones particulares.    Describen el funcionamiento del sistema Los RF del usuario pueden ser frases muy generales sobre lo que el sistema debería hacer. Se suelen expresar como objetivos del sistema. Los RF del sistema deben describir los servicios que hay que proporcionar con todo detalle: los casos de uso

REQUISITOS FUNCIONALES EJEMPLOS: 1. Se deben poder realizar búsquedas en base a diferentes criterios. 2. Se deben proporcionar diferentes visores para que el usuario lea los documentos recuperados. 3. Cada factura tendrá un número único y correlativo y la fecha.

REQUISITOS NO FUNCIONALES Restricciones que afectan a los servicios o funciones del sistema, tales como restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.    Definen propiedades emergentes del sistema, tales como el tiempo de respuesta, las necesidades de almacenamiento, la fiabilidad, … Pueden especificar también la utilización de una herramienta CASE en particular, un lenguaje de programación o un método del desarrollo. Pueden ser más críticos que los funcionales.   Si un RF no se cumple, el sistema se degrada Si un RNF no se cumple, el sistema puede inutilizarse

REQUISITOS NO FUNCIONALES EJEMPLOS:    “El máximo espacio de almacenamiento ocupado por el sistema debe ser de 8 MB porque el sistema debe alojarse completamente en una memoria de sólo lectura e instalarse en el coche” “El proceso software y los documentos a realizar deben conformar el proceso y los estándares de documentación recogidos en la norma TELMo-ES-2003” “El sistema no debe revelar ninguna información personal sobre los clientes excepto su nombre y su número de referencia"

¿COMO ESCRIBIR REQUISITOS?     La “mejor forma” de escribir requisitos no existe Lo más utilizado es el lenguaje natural. Cada requisito expresado en una frases corta (“el sistema hará X ...”, “se facilitará Y...”, etc) O lenguaje natural complementado con diagramas y/o notaciones formales La notación utilizada depende de quien lee o quien escribe los requisitos.

Procesos de la Ingeniería de Requerimientos  La Ingeniería de Requerimientos es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema

Procesos de la Ingeniería de Requerimientos  Las 4 actividades genéricas de alto nivel son:     estudio de factibilidad del sistema obtención y análisis de requerimientos especificación y documentación de los requerimientos la validación de los requerimientos

ESTUDIO DE FACTIBILIDAD  Un estudio de factibilidad es un estudio corto y orientado a resolver varias preguntas:    ¿ el sistema contribuye a los objetivos generales de la organización ? ¿ el sistema se puede implementar utilizando la tecnología actual y con las restricciones de costo y tiempo ? ¿ el sistema puede integrarse a otros que existe en la organización ?

Procesos de la Ingeniería de Requerimientos

OBTENCION Y ANALISIS DE REQUERIMIENTOS  El personal del desarrollo técnico del software trabajará con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicación, cuáles servicios debe proveer el sistema, el desempeño requerido del sistema, las restricciones del hardware, etc.

OBTENCION Y ANALISIS DE REQUERIMIENTOS  La obtención y análisis es un proceso difícil por varias razones:  los stakeholders (personas que tienen influencia directa o indirecta sobre los requerimientos del sistema) a menudo no conocen realmente lo que desean obtener, excepto en términos muy generales.  los stakeholders expresan los requerimientos con sus propios términos.

OBTENCION Y ANALISIS DE REQUERIMIENTOS  La obtención y análisis es un proceso difícil por varias razones (continuación):   diferentes stakeholders tienen requerimientos distintos y podrían expresarlos de varias formas. Se deben identificar todas las fuentes de requerimientos así como los conflictos. Los factores políticos influyen en los requerimientos. Las personas buscan aumentar sus influencias.

OBTENCION Y ANALISIS DE REQUERIMIENTOS  El método VORD (definición de requerimientos orientados al punto de vista) se ha diseñado como un marco de trabajo orientado a servicios para la obtención y análisis de requerimientos.

OBTENCION Y ANALISIS DE REQUERIMIENTOS  Las etapas principales de VORD son: 1. Identificación de puntos de vista, que implica descubrir los que reciben los servicios del sistema e identificar los servicios específicos que se suministran a cada punto de vista. 2. Estructuración de puntos de vista que comprende agrupar los relacionados en una jerarquía

OBTENCION Y ANALISIS DE REQUERIMIENTOS  Las etapas principales de VORD son: 3. Documentación de puntos de vista, que comprende refinar la descripción de éstos y los servicios identificados. 4. Trazado del punto de vista del sistema, que comprende identificar los objetivos en un diseño OO utilizando la información del servicio encapsulado en los puntos de vista.

VALIDACION DE REQUERIMENTOS  Esta validación muestra que éstos son los que definen el sistema que el cliente desea.  Tiene mucho en común con el análisis ya que implica encontrar problemas con los requerimientos.

VALIDACION DE REQUERIMENTOS  La validación de requerimientos es importante debido a que los errores en el documento de requerimientos pueden conducir a costos excesivos al repetir el trabajo cuando sean descubiertos.  El costo de hacer un cambio en el sistema es mucho mayor que reparar los errores de diseño o codificación

VALIDACION DE REQUERIMENTOS  Las verificaciones incluyen: 1. Verificación de validez: para incluir solo requerimientos realmente útiles. 2. Verificación de consistencia: para evitar las contradicciones entre los requerimientos. 3. Verificación de integridad: para incluir todas las restricciones pedidas.

VALIDACION DE REQUERIMENTOS  Las verificaciones incluyen: 4. Verificación de realismo: para asegurarse que los requerimientos se pueden implementar. 5. Verificabilidad: para reducir las discusiones entre el cliente y el contratista, los requerimientos deben redactarse de una manera verificable.

VALIDACION DE REQUISISTOS Algunas preguntas recomendadas para realizar la validación: o ¿ La fuente del requisito está identificada? o ¿ Cuáles otros requisitos están relacionados con éste? o ¿ El requisito viola alguna restricción del dominio del sistema? o ¿ El requisito se puede probar?

DOCUMENTACION DE LOS REQUISITOS  Los objetivos de negocios que se desean satisfacer con el sistema (esto viene del modelo del negocio del cliente)  La visión general del sistema ¿usted que cree?  El propósito del sistema ¿para que lo necesito?  Los objetivos del proyecto (y cómo mido si se cumplieron o no)  Los involucrados

DOCUMENTACION DE LOS REQUISITOS  Restricciones impuestas (por el cliente o el entorno)  Otros hechos relevantes  El alcance del proyecto  El alcance del producto  Los requisitos

DOCUMENTACION DE LOS REQUISITOS  Soluciones ya existentes  Riesgos  Costos iniciales (valoración inicial)  Ideas de posibles soluciones

¿COMO SE DEFINEN LOS REQUISITOS ?  Existen   diferentes técnicas: Descripción en lenguaje natural Lista de características (feature)

ADMINISTRACION DE REQUERIMIENTOS  Los requerimientos para sistemas grandes son siempre cambiantes.  Una razón es porque no siempre el problema puede definirse totalmente.  Es difícil anticipar que efectos tendrá el sistema nuevo en la organización, y siempre se lo comparará con el sistema anterior (manual o automatizado).

ADMINISTRACION DE REQUERIMIENTOS  Una vez que los usuarios finales experimenten el nuevo sistema surgirán nuevos requerimientos porque:  1. Por lo general un sistema grande tiene una comunidad de usuarios diversa, los que tienen diferentes tipos de requerimientos, algunos contradictorios. Esto obliga a aceptar algunos y desechar otros.

ADMINISTRACION DE REQUERIMIENTOS  Una vez que los usuarios finales experimenten el nuevo sistema surgirán nuevos requerimientos porque:  2. Las personas que pagan por los sistemas (clientes) raras veces son las mismas que los usan. Los primeros imponen requerimientos organizacionales o presupuestarios, los segundos funcionales.

ADMINISTRACION DE REQUERIMIENTOS  Una vez que los usuarios finales experimenten el nuevo sistema surgirán nuevos requerimientos porque:  3. El entorno de negocios y técnico del sistema cambia y esto debe reflejarse en el sistema mismo. Se puede introducir nuevo hardware, puede ser necesario que el sistema interactúe con otros sistemas, etc.

¿POR QUE FRACASAN LOS PROYECTOS?

¿QUIENES PARTICIPAN EN LA IR?  Entre las personas implicadas hay que considerar:     Organizaciones que integran la organización del analista que está diseñando el sistema Organizaciones o sistemas de respaldo Dirección Usuarios

¿QUIENES PARTICIPAN EN LA IR?

PROBLEMAS RELACIONADAS CON LAS PERSONAS INVOLUCRADAS  Las vías que pueden dificultar la determinación de los requisitos son:        Los usuarios no tienen claro lo que desean Los usuarios no se involucran en la elaboración de requisitos escritos Los usuarios insisten en nuevos requisitos después de que el coste y la programación se hayan fijado. La comunicación con los usuarios es lenta Los usuarios no participan en revisiones o son incapaces de hacerlo. Los usuarios no comprenden los problemas técnicos Los usuarios no entienden el proceso del desarrollo

PROBLEMAS RELACIONADOS CON LOS ANALISTAS  La correcta redacción de las Especificaciones de requisitos del Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redacción hay que evitar:      Uso de terminología ambigua en la redacción de los documentos de requisitos Sobre especificación de los requisitos Escritura poco legible, voz pasiva, abuso de negaciones Uso de verbos en condicional, expresiones subjetivas Ausencia de términos y verbos del dominio de la aplicación

PROBLEMAS RELACIONADOS CON LOS DESARROLLADORES  El personal técnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que se provee el producto final.  Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente.

TRABAJO DE INVESTIGACION  Herramientas CASE para la IR.  Requisitos de usuario y sistema  Técnicas para la especificación de requisitos.

Add a comment

Related presentations

Related pages

Ingeniería de requisitos - Wikipedia, la enciclopedia libre

Implicaciones. La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a: La educción (a veces llamada "elicitación ...
Read more

Análisis de requisitos del software - Pagina del servidor ...

Análisis de requisitos del software [PRESSMAN, 2002] La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y ...
Read more

Requisito (sistemas) - Wikipedia, la enciclopedia libre

Requisitos en ingeniería de software y sistemas. En ingeniería de sistemas existen tres tipos de requisitos. Un requisito funcional puede ser una ...
Read more

Ingeniería de Requisitos

requisitos que no son obvios para los usuarios, o puede deducir mejor las consecuencias de los requisitos propuestos por los usuarios. Por ejemplo, un
Read more

Ingeniería de requisitos - EcuRed

Ingeniería de Requisitos, es el proceso de desarrollar una especificación de Software. Las especificaciones pretenden comunicar las necesidades del ...
Read more

2.2. Técnicas de la Ingeniería de Requisitos by John ...

INSTITUTO TECNOLÓGICO SUPERIOR DE JEREZ MATERIA: Fundamentos de Ingeniería de software MAESTRO: Hailer de Rene de la Cruz Castañeda .
Read more

Ingenieria de Requisitos - YouTube

NOTA: SELECCIONAR CALIDAD 240p o SUPERIOR ( RECOMENDADO 360p) YA QUE EN 144p EL VIDEO NO SE LEE CORRECTAMENTE Video realizado por estudiantes de ...
Read more