Want to create interactive content? It’s easy in Genially!

Reuse this genially

Norma IEEE 830

pdfkks

Created on February 19, 2024

Start designing with a free template

Discover more than 1500 professional designs like these:

Transcript

Ingenieria de software

NORMA IEEE 830

El estandar IEEE 830 tambien conocida como ERS (Especificacion de requerimientos de Software), SRS (En inglés).

Diego Edgar Morales Marin Ing. de Software

introduccion al IEEE 830

  • Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software: El cliente debe participar activamente en la especificación de requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se llevan a cabo.
  • Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. Permite al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena especificación de requisitos, los costes de desarrollo pueden incrementarse considerablemente.

Historia El estandar 830 fue generado por el Software Engineering Standards Committee (Comite de normas de ingenieria de Software)

Secciones deL Documento

1.- INTRODUCCION

  • PROPOSITO: Esta sección establece el objetivo del documento. Aquí se explica por qué se está creando el software, qué problema o necesidad y cuáles son los objetivos y metas del sistema que se quiere hacer.
  • AMBITO DEL SISTEMA: Acá se describe qué funcionalidades incluirá el sistema y qué no. Es importante saber aspectos del problema que serán abordados por el software y cuáles no serán considerados dentro del alcance del proyecto.
  • DEFINICIONES, ACRONIMOS Y ABREVIATURAS: Se incluyen todas las definiciones de términos técnicos, acrónimos y abreviaturas que se usaran a lo largo del documento.
  • REFERENCIAS: En esta sección se pone una lista de todas las fuentes consultadas durante la elaboración del documento, como libros, artículos, etc.

SECCIONES DEL DOCUMENTO

3.- Especificacion de requerimientos:

2.- Descripcion

  • Perspectiva del producto: Aquí proporciona una visión general del producto, incluyendo su propósito.
  • Funciones del producto: Aquí se detallan las funciones específicas que el producto debe realizar como funciones principales como las secundarias, requisitos funcionales, como la velocidad, la precisión o la facilidad de uso.
  • Características de los usuarios: Aquí se describen las características de los usuarios del producto, como sus roles, habilidades, limitaciones.
  • Restricciones generales: Aquí se enumeran las restricciones que afectan al desarrollo o al funcionamiento del producto, como limitaciones de hardware o software, restricciones de tiempo o presupuesto.
  • Corrección: Las especificaciones deben ser precisas y libres de errores para evitar malentendidos y problemas durante el desarrollo.
  • Rastreable: Cada requerimiento debe poder ser rastreado hasta su origen, ya sea un usuario, una normativa, etc. Esto facilita la gestión de cambios y la verificación.
  • Verificable: Deben ser posibles de verificar mediante pruebas u otras técnicas para confirmar que el software cumple con ellos.
  • Priorizado: Los requerimientos deben estar ordenados por importancia o relevancia para encaminar el proceso de desarrollo y asegurar que los más críticos se hagan primero.

Secciones del documento

4.- Modelo de Analisis

  • Diagrama de secuencia: Puede ayudar a ilustrar cómo se espera que funcione el sistema en diferentes situaciones y cómo se desencadenan las diferentes acciones entre los componentes.
  • Diagrama de Flujo de datos: Muestra los procesos, las entradas, las salidas y el almacenamiento de datos, así como las conexiones entre ellos. Puede ser utilizado para describir cómo se manejan los datos dentro del sistema, cómo se transforman a medida que atraviesan los diferentes procesos y cómo se almacenan o se transmiten entre los componentes.
  • Diagrama de transicion de datos: El diagrama de transición de estados puede ayudar a especificar cómo se espera que se comporte el sistema en diferentes situaciones y cómo deben manejarse las transiciones entre estados.

referencias

https://zeus.inf.ucv.cl/~bcrawford/AULA_ICI_3242/ERS_IEEE830.pdf

Nhttps://es.slideshare.net/ssuserbf52e91/infografia-estandar-ieee830

https://dspace.ups.edu.ec/bitstream/123456789/5264/1/UPS-CT002757.pdf

http://virtual.umng.edu.co/distancia/ecosistema/odin/odin_desktop.php?path=Li4vb3Zhcy9pbmdlbmllcmlhX2luZm9ybWF0aWNhL2luZ2VuaWVyaWFfZGVfcmVxdWVyaW1pZW50b3MvdW5pZGFkXzMv#slide_4

Nombre asignatura

Captamos mejor el contenido visual. Este tipo de contenido está asociado a mecanismos cognitivos y psicológicos. Las cosas entran por los ojos, la primera imagen es la que cuenta. Asociamos el contenido visual con emociones.

Nombre asignatura

Plantea una pregunta o problema que haga pensar a la clase; es el ingrediente esencial para mantener su atención. Se suele plantear al inicio del tema para fomentar su pensamiento críticoy participación.

Nombre asignatura

No nos gusta aburrir en nuestras clases ni trabajar con contenidos planos. Es momento de apostar por experiencias de aprendizaje dinámicas e interactivas que estimulan el pensamiento y creatividad de cada estudiante.