Ingeniería de Requerimiento

Presentación del tema: "Ingeniería de Requerimiento"— Transcripción de la presentación:

1 Ingeniería de Requerimiento
Reconoce los tipos de requerimientos, considerando su rol en las organizaciones actuales En esta experiencia aprenderemos que es un requerimiento, esta será nuestra experiencia inicial, vamos a observar diferentes situaciones e identificar una forma ordenada de representarlas, cuando hablamos del requerimiento entenderemos como las características y funcionalidades que se desea que posea un sistema o software.

2 Requerimiento Las definiciones de requerimientos del sistema especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. (Ian Sommerville)

3 Tipos de Requerimiento
Requerimientos funcionales abstractos Propiedades del sistema Características que no debe mostrar el sistema Requerimientos funcionales abstractos: Las funciones básicas que el sistema debe proporcionar se definen en un nivel abstracto. Una especificación más detallada de requerimientos funcionales tiene lugar en el nivel de subsistemas. Por ejemplo, en un sistema de control del tráfico aéreo, un requerimiento funcional abstracto especificaría que una base de datos del plan de vuelo debe usarse para almacenar los planes de vuelo de todos los aviones que entran al espacio aéreo controlado. Sin embargo, normalmente no se especificaría los detalles de la base de datos a menos que afecten a los requerimientos de otros subsistemas. Propiedades del sistema: Como se señaló anteriormente, éstas son propiedades emergentes no funcionales del sistema, tales como la disponibilidad, el rendimiento y la seguridad. Estas propiedades no funcionales del sistema afectan a los requerimientos de todos los subsistemas. Características que no debe mostrar el sistema. Algunas veces es tan importante especificar lo que el sistema no debe hacer como especificar lo que debe hacer. Por ejemplo, si está especificando un sistema de control del tráfico aéreo, puede especificar que el sistema no debe presentar demasiada información al controlador.

4 Proceso de obtención de requerimientos
Entrevistas Leer los antecedentes Establecer los objetivos de la entrevista Decidir a quien entrevistar Preparar al entrevistado Decidir el tipo de preguntas y la estructura Preguntas abiertas Preguntas cerradas Requerimientos funcionales abstractos: Las funciones básicas que el sistema debe proporcionar se definen en un nivel abstracto. Una especificación más detallada de requerimientos funcionales tiene lugar en el nivel de subsistemas. Por ejemplo, en un sistema de control del tráfico aéreo, un requerimiento funcional abstracto especificaría que una base de datos del plan de vuelo debe usarse para almacenar los planes de vuelo de todos los aviones que entran al espacio aéreo controlado. Sin embargo, normalmente no se especificaría los detalles de la base de datos a menos que afecten a los requerimientos de otros subsistemas. Propiedades del sistema: Como se señaló anteriormente, éstas son propiedades emergentes no funcionales del sistema, tales como la disponibilidad, el rendimiento y la seguridad. Estas propiedades no funcionales del sistema afectan a los requerimientos de todos los subsistemas. Características que no debe mostrar el sistema. Algunas veces es tan importante especificar lo que el sistema no debe hacer como especificar lo que debe hacer. Por ejemplo, si está especificando un sistema de control del tráfico aéreo, puede especificar que el sistema no debe presentar demasiada información al controlador.

5 Mitos del Software Mitos de Gestión:
Cumplimiento con los presupuestos establecidos. Hacer que no se retrase el proyecto Mejorar la calidad de los proyectos. ¿Mito o Realidad? MITO ¡Tenemos ya un libro lleno de estándares y procedimientos para construir software! ¡Nuestra gente dispone de las herramientas de software mas avanzadas, después de todo cuentan con los computadores mas nuevos! MITO

6 Mitos del Cliente: Los mitos conducen a que el cliente se genere una falsa expectativa. El cliente que solicita el software puede ser un Gerente de Área, un Grupo Técnico de la Empresa, el Departamento de Venta o una empresa Externa. ¿Mito o Realidad? MITO ¡Una declaración general de los objetivos es suficiente para empezar a escribir los programas! MITO ¡Si los requisitos del proyecto cambian, se pueden acomodar fácilmente ya que el software es flexible!

7 Mitos de los Desarrolladores:
Los mitos de los desarrolladores se ha ido fomentando década tras década. Los primeros días de desarrollo, la actividad se ve como un arte; después, sólo cumplir los plazos… ¿Mito o Realidad? MITO !Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo está terminado!. MITO ¡Hasta que no esté el SW “ejecutándose”, no hay forma de comprobar su calidad!. MITO ¡Lo único que se entrega al terminar el proyecto, es el software funcionando!.

8 Paradigmas de la Ingeniería de SW
Antecedentes: Los Paradigmas son metodologías de desarrollo de software que incluyen etapas desde el nacimiento de la necesidad hasta la entrega del último Hito del Proyecto. Uno de los fundamentos principales de los Paradigmas de la Ingeniería es reconocer los problemas y sus causas y demoler los mitos del software como primeros pasos para llegar a la solución. El objetivo principal es entregar soluciones que proporcionen asistencia práctica a las personas que desarrollan Software, mejorar su calidad e integrar el software con el hardware.

9 Especificación de Requisitos Especificación de la prueba
Paradigmas de la Ingeniería de SW Plan Especificación de Requisitos Diseño Listado Especificación de la prueba Estructura de Datos SW operativo La Configuración del Software:

10 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico:

11 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico: Es el paradigma más antiguo y quizás el mas utilizado en la Ingeniería de Software. Algunos desventajas que presenta: Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Normalmente, para el cliente es difícil establecer explícitamente al principio todos los requisitos. El cliente debe tener paciencia: hasta llegar a las etapas finales del proyecto, no habrá una versión operativa del programa.

12 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico: Ingeniería de Sistema Ingeniería y Análisis del Sistema: La Ingeniería y el Análisis de Sistema abarca los requisitos globales a nivel del sistema con una pequeña cantidad de análisis y de diseño a un nivel superior. Inicia con la premisa de que el SW es parte de un Sistema Mayor. Comienza estableciendo los requisitos de todos los elementos del sistema. Este planteamiento es esencial sobretodo cuando el software debe interrelacionarse con otros elementos, tales como Hardware, personas, Bases de Datos, etc.

13 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico: Análisis de los Requisitos del SW: Análisis El proceso de análisis y recopilación se intensifica para eñ software. Para un entendimiento cabal de lo que se va a construir, se debe comprender el ámbito de la información del software, las funciones, el rendimiento y las interfaces requeridas. Los requisitos del sistemas se documentan y se revisan con el cliente.

14 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico: Diseño: Diseño Se enfoca principalmente en: la estructura de datos, la arquitectura del software, el detalle procedimental y la Interfaz. Traduce los requisitos en una representación del software que pueda ser establecida de forma tal que obtenga la calidad requerida antes que comience la codificación. Al igual que la etapa anterior, el Diseño se documenta.

15 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico: Codificación: Codificación El diseño se traduce en forma legible para la máquina. Si el Diseño se realiza de una manera detallada, la Codificación se puede realizar prácticamente en forma mecánicamente..

16 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico: Prueba: Prueba Una vez que se generó el código, comienzan las pruebas del sistema. Se valida la lógica interna del código y se comprueba que los resultados entregados sean los esperados y los incluidos en las etapas anteriores.

17 Paradigmas de la Ingeniería de SW
Ciclo de Vida Clásico: Mantenimiento: Mantención El SW indudablemente podrá sufrir cambios una vez entregado al cliente. Estos cambios pueden ser: pequeños errores encontrados, adaptaciones del SW a entornos externos, nuevos requerimientos de ampliaciones funcionales o de rendimiento, otros. El Mantenimiento aplica cada uno de los pasos procedentes del Ciclo de Vida a un programa existente en vez de uno nuevo.

18

19 Requerimiento Consultas, Sugerencias.
Cierre: Nos damos cuenta que para reconocer los tipos de requerimientos es necesaria una practica en distintos niveles del desarrollo de software, En donde identificamos que el ciclo de desarrollo del software que y genera una forma de ordenar tanto el tipo de proceso para hacer software, como los roles que cumplen cada unos de los actores para crear el software.