Ingeniería de requisitos
Upcoming SlideShare
Loading in...5
×
 

Ingeniería de requisitos

on

  • 789 views

resumen referente a la ingenieria de sistemas

resumen referente a la ingenieria de sistemas

Statistics

Views

Total Views
789
Views on SlideShare
789
Embed Views
0

Actions

Likes
0
Downloads
20
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ingeniería de requisitos Ingeniería de requisitos Document Transcript

  • Ingeniería de Requisitos La ingeniería de requisitos es una condición o necesidad de un usuariopara resolver un problema o alcanzar un objetivo. Comprende todas las tareas relacionadas con la determinación de lasnecesidades o de las condiciones a satisfacer para un software nuevo omodificado, tomando en cuenta los diversos requisitos de los inversores, quepueden entrar en conflicto entre ellos. El propósito de la ingeniería de requisitos es hacer que los mismosalcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Losbuenos requisitos deben ser medibles, comprobables, sin ambigüedades ocontradicciones. Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema serácapaz de realizar. Describen las transformaciones que el sistema realiza sobre lasentradas para producir salidas. Los requerimientos no funcionales tienen que ver con características quede una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. Definición de RequisitosEl objetivo de la fase de definición de requisitos (también se le suele denominarde «especificación» de requisitos) es obtener una clara comprensión del problemaa resolver, extraer las necesidades del usuario y derivar de ellas las funciones quedebe realizar el sistema.
  • Características de los Requerimientos Las características de un requerimiento son sus propiedades principales.Un conjunto de requerimientos en estado de madurez, deben presentar una seriede características tanto individualmente como en grupo. A continuación sepresentan las más importantes. Necesario: Un requerimiento es necesario si su omisión provoca unadeficiencia en el sistema a construir, y además su capacidad, características físicaso factor de calidad no pueden ser reemplazados por otras capacidades delproducto o del proceso. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Suredacción debe ser simple y clara para aquellos que vayan a consultarlo en unfuturo. Completo: Un requerimiento está completo si no necesita ampliar detallesen su redacción, es decir, si se proporciona la información suficiente para sucomprensión. Consistente: Un requerimiento es consistente si no es contradictorio conotro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una solainterpretación. El lenguaje usado en su definición, no debe causar confusiones allector. Verificable: Un requerimiento es verificable cuando puede ser cuantificadode manera que permita hacer uso de los siguientes métodos de verificación:inspección, análisis, demostración o pruebas.
  • Actividades de la Ingeniería de Requerimientos En el proceso de IR son esenciales diversas actividades. En estedocumento serán presentadas secuencialmente, sin embargo, en un proceso deingeniería de requerimientos efectivo, estas actividades son aplicadas de maneracontinua y en orden variado. Dependiendo del tamaño del proyecto y del modelo de proceso desoftware utilizado para el ciclo de desarrollo, las actividades de la IR varían tantoen número como en nombres. La tabla #1 muestra algunos ejemplos de lasactividades identificadas para cada proceso. A pesar de las diferentes interpretaciones que cada desarrollador tengasobre el conjunto de actividades mostradas en la tabla anterior, podemosidentificar y extraer cinco actividades principales que son: Análisis del Problema Evaluación y Negociación Especificación Validación Evolución
  • Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniería de SoftwareMODELO Oliver and Steiner EIA / IS-632 IEEE Std 1220- CMM nivel RUP 1996 1994 Repetitivo (2)Actividades Evaluar la Análisis de Análisis de Identificación de Análisis del información requerimientos Requerimientos requerimientos Problema disponible Definir métricas Análisis funcional Estudio de los Identificación de Comprender las efectivas requerimientos restricciones del necesidades de sistema a desarrollar los involucrados Crear un modelo del Síntesis Validación de Análisis de los Definir el sistema comportamiento del requerimientos requerimientos sistema Crear un modelo de Análisis y control Análisis funcional Representación de Analizar el los objetos del sistema los requerimientos alcance del proyecto Ejecutar el análisis Evaluación y Comunicación de Modificar la estudio de funciones los requerimientos definición del
  • sistemaCrear un plan Verificación de Validación de Administrar lossecuencial de funciones requerimientos cambios deconstrucción y requerimientospruebas Síntesis Estudio y evaluación del diseño Verificación física Control
  • A continuación se explicará cada una de ellas, presentándolas en el ordenen que deben ser aplicadas para un nuevo proyecto. Análisis del Problema El objetivo de esta actividad es entender las verdaderas necesidades delnegocio. Antes de describir qué pasos deben cumplirse en esta actividad, debemostener una definición clara del término "Problema". "Un problema puede ser definido como la diferencia entre las cosas comose perciben y las cosas como se desean”. Aquí vemos nuevamente la importanciaque tiene una buena comunicación entre desarrolladores y clientes; de estacomunicación con el cliente depende que entendamos sus necesidades. A través de la definición de problema, podemos ver entonces que laactividad de "Análisis del Problema" tiene por objetivo que se comprendan losproblemas del negocio, se evalúen las necesidades iniciales de todos losinvolucrados en el proyecto y que se proponga una solución de alto nivel pararesolverlo. Durante el análisis del problema, se realizan una serie de pasos paragarantizar un acuerdo entre los involucrados, basados en los problemas reales delnegocio.Estos pasos son los siguientes: Comprender el problema que se está resolviendo: Es importantedeterminar quién tiene el problema realmente, considerar dicho problema desdeuna variedad de perspectivas y explorar muchas soluciones desde diferentespuntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por laenorme fila que debe formar para realizar una transacción bancaria".
  • Perspectiva del cliente = Pérdida de tiempo Perspectiva del banco = Posibles pérdidas de clientes Posibles soluciones pueden ser, determinar por qué demoran los cajeros,colocar una nueva caja (implica contratación de nuevos cajeros), abrir una nuevasucursal (involucra personal nuevo y estudio de mercado), realizar transaccionespor otros medios (teléfono, internet, mediante cajeros automáticos, autobancos). Como puede verse, múltiples soluciones aplican para el mismo problema,sin embargo, sólo una de ellas será la más factible. Las soluciones iniciales, debenser definidas tomando en cuenta tanto la perspectiva técnica como la del negocio. Evaluación y negociación de los requerimientos La diversa gama de fuentes de las cuales provienen los requerimientos,hacen necesaria una evaluación de los mismos antes de definir si son adecuadospara el cliente. El término "adecuado" significa que ha sido percibido a un nivelaceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, ala vez que se buscan resultados completos, correctos y sin ambigüedades. En esta etapa se pretende limitar las expectativas del clienteapropiadamente, tomando como referencia los niveles de abstracción ydescomposición de cada problema presentado. Especificación de Requisitos de Software (SRS) La especificación de requisitos de software es la actividad en la cual segenera el documento, con el mismo nombre, que contiene una descripcióncompleta de las necesidades y funcionalidades del sistema que será desarrollado;describe el alcance del sistema y la forma en cómo hará sus funciones, definiendolos requerimientos funcionales y los no funcionales.
  • En la SRS se definen todos los requerimientos de hardware y software,diagramas, modelos de sistemas y cualquier otra información que sirva de soportey guía para fases posteriores. Es importante destacar que la especificación de requisitos es el resultadofinal de las actividades de análisis y evaluación de requerimientos; estedocumento resultante será utilizado como fuente básica de comunicación entre losclientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquelinvolucrado en la implementación del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se estáproponiendo, coincide con las necesidades de la empresa. Los analistas yprogramadores la utilizan para determinar el producto que debe desarrollarse. Elpersonal de pruebas elaborará las pruebas funcionales y de sistemas en base a estedocumento. Para el administrador del proyecto sirve como referencia y control dela evolución del sistema. La SRS posee las mismas características de los requerimientos: completa,consistente, verificable, no ambigua, factible, modificable, rastreable, precisa,entre otras. Para que cada característica de la SRS sea considerada, cada uno delos requerimientos debe cumplirlas; por ejemplo, para que una SRS se considereverificable, cada requerimiento definido en ella debe ser verificable; para que unaSRS se considere modificable, cada requerimiento debe ser modificable y asísucesivamente. Las características de la SRS son verificadas en la actividad deValidación. Validación de Requisitos La validación es la actividad de la IR que permite demostrar que losrequerimientos definidos en el sistema son los que realmente quiere el cliente;además revisa que no se haya omitido ninguno, que no sean ambiguos,inconsistentes o redundantes.
  • En este punto es necesario recordar que la SRS debe estar libre de errores,por lo tanto, la validación garantiza que todos los requerimientos presentes en eldocumento de especificación sigan los estándares de calidad. No debe confundirse la actividad de evaluación de requerimientos con lavalidación de requerimientos. La evaluación verifica las propiedades de cadarequerimiento, mientras que la validación revisa el cumplimiento de lascaracterísticas de la especificación de requisitos. Durante la actividad de validación pueden hacerse preguntas en base acada una de las características que se desean revisar. A continuación se presentanvarios ejemplos: ¿Están incluidas todas las funciones requeridas por el cliente? (completa) ¿Existen conflictos en los requerimientos? (consistencia) ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) ¿Está cada requerimiento claramente representado? (entendible) ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible) ¿Está la SRS escrita en un lenguaje apropiado? (clara) ¿Existe facilidad para hacer cambios en los requerimientos? (modificable) ¿Está claramente definido el origen de cada requisito? (rastreable) ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable) La validación de requerimientos es importante pues de ella depende que noexistan elevados costos de mantenimiento para el software desarrollado.
  • Evolución de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo delas necesidades de los usuarios y cómo los objetivos de la organización puedencambiar, por lo tanto, Es esencial planear posibles cambios a los requerimientos cuando elsistema sea desarrollado y utilizado. La actividad de evolución es un procesoexternoque ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las más frecuentesson: Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Porque cambió el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambió el ambiente de negocios. Porque cambió el mercado en el cual se desenvuelve el negocio. Cambios a los requisitos involucra modificar el tiempo en el que se va aimplementar una característica en particular, modificación que a la vez puedetener impacto en otros requerimientos. Por esto, la administración de cambiosinvolucra actividades como establecer políticas, guardar históricos de cadarequerimiento, identificar dependencias entre ellos y mantener un control deversiones. Tener versiones de los requerimientos es tan importante como tenerversiones del código, ya que evita tener requerimientos emparchados en unproyecto. Entre algunos de los beneficios que proporciona el control de versionesestán:
  • Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de "releases". Prevenir la modificación simultánea a los requisitos. En vista que las peticiones de cambios provienen de muchas fuentes, lasmismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad deevitar problemas y conseguir estabilidad en los requerimientos. Herramientas CASE Las herramientas CASE (Computer Aided Software Engineering,Ingeniería de Software Asistida por Computadora) son diversas aplicacionesinformáticas destinadas a aumentar la productividad en el desarrollo de softwarereduciendo el costo de las mismas en términos de tiempo y de dinero. Estasherramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollodel software en tareas como el proceso de realizar un diseño del proyecto, cálculode costos, implementación de parte del código automáticamente con el diseñodado, compilación automática, documentación o detección de errores entre otras. Objetivos 1. Mejorar la productividad en el desarrollo y mantenimiento del software. 2. Aumentar la calidad del software. 3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos. 4. Mejorar la planificación de un proyecto 5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos. 6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
  • 7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación 8. Gestión global en todas las fases de desarrollo de software con una misma herramienta. 9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software. Clasificación Aunque no es fácil y no existe una forma única de clasificarlas, lasherramientas CASE se pueden clasificar teniendo en cuenta los siguientesparámetros: 1. Las plataformas que soportan. 2. Las fases del ciclo de vida del desarrollo de sistemas que cubren. 3. La arquitectura de las aplicaciones que producen. 4. Su funcionalidad. La siguiente clasificación es la más habitual basada en las fases del ciclode desarrollo que cubren: Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación. Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.
  • Existen otros nombres que se le dan a este tipo de herramientas, y que noes una clasificación excluyente entre sí, ni con la anterior: Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación. MetaCASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración activa. Por funcionalidad podríamos diferenciar algunas como: Herramientas de generación semiautomática de código. Editores UML. Herramientas de Refactorización de código. Herramientas de mantenimiento como los sistemas de control de versiones·
  • INSTITUTO UNIVERSITARIO POLITECNICO “SANTIAGO MARIÑO” EXTENSION BARINAS SISTEMAS II INTEGRANTE:PROF. YESENIA DELGADO KRISMAR DURAN C.I 20.099.921SECCION: S6 CARLOS PAREDES C.I 19.350.099 ALDO GALLARDO C.I 19.881.947 BARINAS, NOVIEMBRE 2012