La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

PRESENTADO POR: KERLY PARRA

Presentaciones similares


Presentación del tema: "PRESENTADO POR: KERLY PARRA"— Transcripción de la presentación:

1 PRESENTADO POR: KERLY PARRA
REQUERIMIENTOS DEL SOFTWARE SWEBOK PRESENTADO POR: KERLY PARRA

2 INTRODUCCION El area del conocimiento de requisitos del software (KA) se refiere a la obtención, análisis, especificación, y validación de requisitos del software. Así como la gestión de requisitos durante todo el ciclo de vida del producto de software.

3 TEMAS PARA REQUISITOS DEL SOFTWARE
Fundamentos de los requisitos del software Proceso de los requisitos Elicitaciòn de los requisitos Analisìs de requisitos Especificaciòn de requisitos Validaciòn de los requisitos Consideraciones practicas Herramientas de los requisitos del software

4 Fundamentos de los requisitos del software
1. Definiciòn de un Requisito del Software Un requisito del software es una propiedad que se debe exhibir por algo para resolver algún problema en el mundo real. Una propiedad esencial de todos los requisitos de software es que sean verificables como un individuo funcióna como requisito funcional o en el nivel de sistema como un requisito no funcional.

5 2. Producto y Requisitos del Proceso Los requisitos de un producto es una necesidad o restricción en el software a ser desarrollado . Un requisito del proceso es esencialmente una restricción en el desarrollo del software .

6 Requisitos Funcionales y No Funcionales
Los requisitos funcionales describen las funciones que el software va a ejecutar, también se puede describir como uno de los que un conjunto finito de pasos de prueba puede ser escrito para validar su comportamiento. Los requisitos no funcionales son los que actuan para restringir la solución. Los requisitos no funcionales son a veces conocidos como restricciones o requisitos de calidad.

7 4. Propiedades Emergentes Algunos requisitos representan propiedades emergentes de los requisitos de software, es decir, que no puede ser abordados por un solo componente, pero que dependerá de cómo todos los componentes de software inter operan.

8 5. Requisitos Cuantificables
Los requisitos del software deben expresarse tan claramente y como sin ambigüedad como sea posible, y, en su apropiado, cuantitativamente. Es importante evitar los requisitos vagos y no verificables que dependen para su interpretación sobre subjetiva juicio. El software debe ser confiable. El software debe ser fácil de usar.

9 6. Requisitos del Sistema y Requisitos del Software Combinación de elementos que interactúan para lograr un objetivo determinado. Estos incluyen hardware, software,personas, información, técnicas, instalaciones, servicios, y otros elementos de apoyo, según lo definido por el Consejo Internacional de Software e Ingeniería de Sistemas.

10 Proceso de los requisitos
1. Modelos de Procesos No es una actividad anticipada discreta del ciclo de vida del software, sino más bien un proceso iniciado en el comienzo de un proyecto que sigue ser refinado a lo largo del ciclo de vida. Identifica los requisitos del software como la configuración de artículos y gestiona usando la gestión de la configuración misma de software como prácticas de otros productos o procesos del ciclo de vida del software Necesita ser adaptado a la organización y contexto del proyecto.

11 2. Actores del Proceso En este tema se presentan los roles de las personas que participan en el proceso de requisitos. Usuarios: Este grupo comprende a los que va a operar el software. Clientes: Este grupo comprende a los que han encargado el software o que representan el mercado objetivo de software. Los analistas de mercado: Un producto de mercado masivo no tendrá un cliente puesto en marcha. Reguladores: Muchos dominios de aplicación, tales como la banca y el transporte público, son regulados. Los ingenieros de software: Estos individuos tienen un interés legítimo en sacar provecho de desarrollo el por software.

12 3. Apoyo y Gestión de Procesos Se presenta los recursos de la gestión de proyectos necesarios y consumidos por el proceso de los requisitos. Su principal objetivo es hacer que el vínculo entre a las actividades del proceso identificadas.

13 4. Calidad y Mejora del Proceso
Se refiere a la evaluación de la calidad y la mejora del proceso de los requisitos. El proceso de calidad y mejora están estrechamente relacionados tanto a la Calidad del Software KA e Ingeniería del Proceso del Software KA, que comprende: Cobertura de proceso de los requisitos por normas y modelos de mejora Medidas de proceso de los requisitos de evaluación comparativa Planificación e implementación de mejora; Seguridad / mejora de la CIA / planificación y implementación.

14 ELICITACIÒN DE LOS REQUISITOS
Se refiere a los orígenes de los requisitos de software y cómo el ingeniero de software puede recogerlos. Es la primera etapa en la construcción de una comprensión del problema que el software requiere para resolver. Un elemento crítico de la obtención de requisitos es informar el alcance del proyecto.

15 1. Fuentes de los Requisitos
Los requisitos tienen muchas fuentes en el software típico, y es esencial que todas las fuentes potenciales estés identificadas y evaluadas. Objetivos. Proporcionan la motivación para el software, pero son a menudo vagamente formulados. Conocimiento de Dominio. El ingeniero de software necesita adquirir o tener conocimiento disponible sobre el dominio de aplicación. El entorno operativo. Los requerimientos se derivan del ambiente en el que se ejecutará el software.

16 2. Técnicas de Obtención Se centra en las técnicas para conseguir actores humanos para articular requisitos pertinentes de la información. Entrevistas. Entrevistar a los interesados es un medios "tradicional" de los requisitos de obtención Escenarios. Valiosos medios de escenarios proporcionan una e licitación para proporcionar contexto a las necesidades del usuario Prototipos. Esta técnica es una herramienta valiosa para aclarar los requisitos ambiguos Facilitando reuniones. El propósito de estas reuniones es tratar de lograr un sumaria de efecto.

17 ANALISIS DE REQUISITOS
 Este tema tiene que ver con el proceso de análisis requisitos a: Detectar y resolver los conflictos entre requisitos Descubrir los límites del software y cómo debe interactuar con su organización y entorno operativo Elaborar requisitos del sistema para derivar requisitos del software

18 Clasificación de Requisitos
Los requisitos pueden clasificarse en un número de dimensiones. Algunos ejemplos son los siguientes: Si el requisito es sobre el producto o el proceso. Los requisitos en el proceso pueden limitar la elección del contratista, adaptar el proceso de ingeniería del software, o las normas que deben respetarse. La prioridad del requisito. Cuanto mayor sea la prioridad, más esencial el requisito es para cumplir con los objetivos generales del programa. A menudo clasificado en una escala fija tal como obligatorio, altamente deseable, deseable, u opcional, la prioridad a menudo tiene que ser equilibrado contra el costo de desarrollo e implementación.

19 2. El Modelado Conceptual
El desarrollo de modelos de un problema del mundo real es clave para el análisis de los requisitos de software. Su propósito es ayudar en la comprensión de la situación en la que se produce el problema, así como representa una solución. Varios tipos de modelos se pueden desarrollar. Estos incluyen diagramas de casos de uso, los modelos de flujo de datos, modelos de estado, los modelos basados ​​en objetivos, las interacciones del usuario, modelos de objetos, modelos de datos, y muchos otros.

20 3. Asignación Arquitectónica de Diseños y de los Requisitos En algún momento, la arquitectura de la solución debe ser derivada. El diseño arquitectónico es el punto en que el proceso se superpone con los requisitos del software o sistemas de diseño se ilustra cómo de imposible que es para desacoplar limpiamente las dos tareas. La asignación es importante para permitir un análisis detallado de requisitos

21 4. Negociación de los Requisitos
Se refiere a la resolución de problemas con los requisitos de los conflictos ocurren entre dos actores que requieren mutuamente características incompatibles, entre los requisitos y los recursos, o entre requisitos funcionales y no funcionales Los requisitos de prioridades son necesarios, no sólo como un medio para filtrar los requisitos importantes, sino también con el fin de resolver los conflictos.

22 5. Análisis Formal El mayor análisis formal se concentra en relativamente las últimas etapas de análisis de requisitos. Es generalmente contraproducente para aplicar formalización hasta que los objetivos de negocio y necesidades de los usuarios.

23 Especificacion de requisitos
Para la mayoría de las carreras de ingeniería, el término "especificación" se refiere a la asignación de numéricos valores o límites a los objetivos de diseño de un producto. Se refiere a la producción de un documento que puede ser revisado de forma sistemática, evaluado y aprobado

24 El Documento de la Definicion del Sistema
Este documento (a veces conocido como el usuario requisitos documento o concepto de las operaciones documento) registra los requisitos del sistema. El define los requisitos del sistema de alto nivel desde la perspectiva de dominio.

25 2. Requisitos del sistema de Especificaciones Los desarrolladores de sistemas con software sustancial y los componentes de software-un no avión moderno, por ejemplo, separa a menudo la descripción de los requisitos del sistema de la descripciónde los requisitos de software.

26 3. Especificacion de Requisitos del Software La especificacion de Requisitos del software establece la base para un acuerdo entre los clientes y contratistas o proveedores (en los proyectos impulsados por el mercado, estos roles pueden ser reproducidos por la comercialización y divisiones de desarrollo) en lo que el producto del software, así como lo que no se espera hacer.

27 Validacion de los requisitos
Los documentos de requerimientos pueden estar sujetos a validaciones y procedimientos de verificación. los requisitos pueden ser validados para asegurarse de que el ingeniero del software ha entendido los requisitos; También es importante verificar que un documento de requisitos se ajusta a las normas de la empresa y que es comprensible, coherente y completo.

28 Comentarios de los Requisitos
Tal vez los medios más comunes de la validación es por inspección o revisión de los documentos de requisitos. Se asigna un grupo de revisores en un breve buscador de errores, suposiciones erróneas, falta de claridad, y la desviación de la práctica estándar. Los comentarios pueden ser constituidos al término del documento de definición del sistema, la especificación de los documentos del sistema, los requisitos de especificaciones de los documentos del software, la especificación de la línea de base para un nuevo lanzamiento, o en cualquier otro paso en la proceso

29 2. Prototipos Prototipos es comúnmente un medio para validar la interpretación que el ingeniero del software de los requisitos del software, así como para la obtención de un nuevo requisito. La ventaja de prototipos es que pueden hacer que sea más fácil de interpretar los supuestos del ingeniero del software y, cuando sea necesario, dar información útil sobre por qué están equivocados

30 3. Valdaciòn del Modelo Es típicamente necesario validar la calidad de los modelos desarrollados durante el análisis. Por ejemplo, en modelos de objetos, es útil para realizar un análisis estático para verificar que las rutas de comunicación existen entre los objetos que, en los grupos de dominio de interés, el intercambio de datos.

31 4. Pruebas de Aceptaciòn Una propiedad esencial de un requisito del software es que debería ser posible para validar que el producto terminado satisface. Los requisitos que no pueden ser validados son en realidad "deseos“. En la mayoría de los casos, el diseño de pruebas de aceptación hace por cómo los usuarios finales normalmente realizan negocios utilizando el sistema.

32 Consideraciones practicas
El proceso de requisitos se extiende por la totalidad ciclo de vida del software. La gestión del cambio y del mantenimiento de los requisitos de un Estado querefleja con precisión el software a construir, o que se ha construido, son clave para el éxito del proceso de ingenieria del software.

33 Naturaleza Iteractiva del Proceso de los Requisitos
Hay una presión general en la industria del software para los ciclos de desarrollo cada vez más cortos, y esto es particularmente pronunciado en sectores de mercado altamente competitivo. Por otra parte, la mayoría de los proyectos están limitados de alguna manera por su entorno, y muchos son mejoras para, o las revisiones, existentes del software donde la arquitectura es un hecho.

34 2. Cambiar a Gestion La gestión del cambio es fundamental para la gestión de requisitos. En este tema se describe el papel de gestión del cambio, los procedimientos que deben estar en su lugar, y el análisis que se debe aplicar a los cambios propuestos.

35 3. Atributos de los Requisitos Los requisitos deben consistir no sólo de una especificación de lo que se requiere, sino también de la informacion de auxiliares, que ayudan a administrar e interpretar los requisitos. Los atributos de los requisitos deben definir la grabada y actualizada del software bajo el desarrollo o mantenimiento evolucionado.

36 4. Trazado de los Requisitos El rastreo de los requisitos tiene que ver con la fuente recuperación de los requisitos y la predicción de los efectos de los requisitos. El rastreo es fundamental a la realización de análisis de impacto cuando los requisitos cambian. Un requisito debe ser trazable hacia atrás a los requisitos y las partes interesadas que lo motivan (de un requisito de software de nuevo al requisito (s) del sistema que ayuda a satisfacer

37 5. Medicion de los Requisitos Como una cuestión práctica, es típicamente útil tener algún concepto del "volumen" de los requisitos para un producto de software en particular. Este número es útil para evaluar el "tamaño" de un cambio en los requisitos, en la estimación del costo de una tarea desarrollo o mantenimiento, o simplemente para utilizar como denominador en otras mediciones .

38 Herramientas de los requisitos del software
Las herramientas para hacer frente a los requisitos del software caen a rasgos grandes en dos categorías: herramientas para el modelado y herramientas para la gestión de requisitos.

39 Gracias


Descargar ppt "PRESENTADO POR: KERLY PARRA"

Presentaciones similares


Anuncios Google