Norma IEEE 830

TECNOLOGICO NACIONAL DE MÉXICO INSTITUTO TECNOLOGICO DE OAXACA

Ingeniería De Software

wow

Norma IEEE 830

Alumno: Barbosa Santiago Mario Alberto

Profesor: Diaz Sarmiento Bibiana

23/02/2024

Introducción

En le desarrollo de software siempre existe una preocupación constante acerca del posible éxito de este, una de las tareas de la ingeniería de software es garantizar ese éxito. Así a través de la experiencia en ese campo se han identificado ramas que ayudan a una mejorar un aspecto muy importante que es la recaudación de requerimientos, la cual mejora drásticamente la funcionabilidad del sistema que se va a entregar al cliente debido a que incluyen todos los aspectos posibles que requiere el cliente y su factibilidad el proyecto.

Historia

Historia IEEE, una asociación dedicada a promover la innovación y la excelencia tecnológica en beneficio de la humanidad, es la sociedad profesional técnica más grande del mundo. Está diseñado para servir a los profesionales involucrados en todos los aspectos de los campos eléctrico, electrónico, y de computación y áreas relacionadas de la ciencia y la tecnología que subyacen a la civilización moderna. Las raíces de IEEE se remontan a 1884, cuando la electricidad comenzó a convertirse en una gran influencia en la sociedad. Había una importante industria eléctrica establecida, el telégrafo, que desde la década de 1840 había llegado a conectar el mundo con un sistema de comunicaciones de datos más rápido que la velocidad de transporte. Las industrias telefónica, eléctrica y ligera acababan de llegar a pie. (IEEE, 2010)

Estándar IEEE 830

El estándar 830-1998 fue generado por un equipo de trabajo del IEEE, su finalidad es la integración de los requerimientos del sistema desde la perspectiva del usuario, cliente y desarrollador. se encarga de poner las pautas para identificar y esquematizar los requerimientos de software. como parte integral del desarrollo de software, sino también como base fundamental de este, todo esto con el fin de no caer en cambios, errores o situaciones que pongan en peligro la creación de una solución, producto o software; incurriendo en gastos o cambios producto de un mal análisis de requerimientos. (GONZALEZ, 2008)

¿Quién la puede usar?  Cliente/Usuario que vaya a definir requerimientos(características) de un software que necesite.  Un desarrollador (interno/externo) que haga software “a la medida” mediante proyecto.  Un desarrollador que haga software “de paquete” que se venda masivamente. Funciones  Un cliente describe claramente lo que quiere.  Un proveedor entiende claramente lo que el cliente quiere.  Se establecen bases para un contrato de desarrollo (o de compra-venta).  Se reduce el esfuerzo de análisis, diseño, y programación.  Se evitan retrabajos.  Se tiene una base o referencia para validar o probar el software solicitado.  Se facilita el traspaso del software a otros clientes/usuarios.  Se pueden hacer mejoras (o innovaciones) a ese software.

Objetivos

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. Asimismo, el cliente se siente partícipe del propio desarrollo.  Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS 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, ya que se deben hacer cambios durante la creación de la aplicación.  Servir de base para desarrollos de estándares de ERS particulares para cada organización: Cada entidad puede desarrollar sus propios estándares para definir sus necesidades

Introducción

FASES

Esta sección debe contener una descripción breve de las principales características del software que se va a desarrollar, la situación actual que genera la necesidad del nuevo desarrollo, la problemática que se encuentra presente en el área, el objetivo principal que se quiere alcanzar, definiciones, referencias y cualquier otra consideración que permita a los involucrados comprender el documento y lograr construir una herramienta informática optima que solvente las necesidades del área solicitante.

Proposito

Como su nombre lo indica esta sección contendrá el propósito de la ERS, aquí describe a que publico va dirigido

Alcance

Mide resultadosy experimenta.

Como su nombre lo indica esta sección contendrá el propósito de la ERS, aquí describe a que publico va dirigido

Definiciones, siglas y abreviaturas

Definición de todos los términos, abreviaturas y acrónimos necesarios para interpretar apropiada mente este documento, logrando una mejor comprensión.

Referencias

Relación completa de todos los documentos relacionados en la especificación de requisitos de software, identificando de cada documento el título, referencia (si procede), fecha y organización o autor.

Apreciación Global

Describe lo que contiene la Especificación y como se encuentra organizada.

Descripción Global Esta sección contendrá la descripción de los factores generales que afectan directamente a nuestro proyecto y sus requisitos. Perspectiva del Producto Indicar si el producto es independiente o parte de un sistema mayor. En el caso de tratarse de un producto que forma parte de un sistema mayor, puede incluirse un diagrama que situé al producto dentro del sistema e identifique sus conexiones esto facilitaría la comprensión. Funciones del Producto Análisis puntual, de las funcionalidades principales que el proyecto debe realizar. Las Funcionalidades deben redactarse de forma clara y consistente, en un lenguaje sencillo para su mejor comprensión, considerando que pueda ser entendido por cualquier involucrado en el proyecto; logrando una mejor interpretación y cumpliendo con los objetivos propuestos en el desarrollo de esta aplicación de software. Características del Usuario Describe las características primordiales de los usuarios que van a ser parte de este proyecto.

Restricciones Descripción de los puntos que podrían limitar el proceso de diseño y desarrollo del software, como son:  Las políticas reguladoras  Las limitaciones del Hardware  Las Interfaces a otras aplicaciones  El funcionamiento Paralelo  Las funciones de la Auditoría  Las funciones de Control  Los requisitos de lenguaje  Los protocolos Señalados (por ejemplo, XON-XOFF, ACK-NACK)  Los requisitos de Fiabilidad  Credibilidad de la aplicación  La Seguridad y consideraciones de seguridad Anotaciones y Dependencias Descripción de aquellos factores que, si cambian, pueden afectar a los requerimientos. Anotaciones y Dependencias Descripción de aquellos factores que, si cambian, pueden afectar a los requerimientos Los Requisitos Específicos Esta es la sección más extensa e importante del documento. Debe contener una lista detallada y completa de los requisitos que debe cumplir el sistema a desarrollar.

Apéndices Los apéndices no siempre son necesarios, pueden comprender estudios de usuarios descripción de tipos de dato o almacenamientos, es decir se trata de información adicional que puede ayudar a los lectores a realizar un mejor desarrollo de software. Índice Comprende la tabla de contenido de la Especificación de Requisitos de Software, lo que nos permitirá llevar una organización de elaboración. (Patricia, 2018) Conclusión La Norma IEEE-830 recomienda que una Especificación de Requerimientos de Software debe contener las partes expuestas en esta investigación, la norma recomienda que cada empresa o institución bebería elaborar una ERS siguiendo sus procesos, para mantener una mejor gestión de los mismos, sin embargo, consciente de que cada compañía administra y dirige sus propias políticas no establece que sea absolutamente necesario la aplicación total de la norma sino adaptarla a las exigencias de cada una. Tener bien en claro los requisitos del cliente es el aspecto mas importante del proceso de desarrollo de software y la ingeniería de requisitos con su norma IEEE nos ayudan a que todo resulte de muy buena manera.

REFERENCIAS

contributors, E. (23 de Mayo de 2017). IEEE. Obtenido de EcuRed: https://www.ecured.cu/IEEE GONZALEZ, M. (24 de Agosto de 2008). INGENIERIA DE SOFTWARE ESTÁNDAR IEEE 830-1993. Obtenido de IEEE RECOMMENDED PRACTICE FOR SOFTWARE REQUIREMENTS SPECIFICATIONS: https://ingsoftudb.blogspot.com/ IEEE. (2010). Historia de IEEE. Obtenido de IEEE: https://www.ieee.org/about/ieee-history.html Patricia, M. M. (9 de Enero de 2018). Sistema informático para la captación de requerimientos para el desarrollo de aplicaciones en Farmaenlace Cía. Ltda., basada en el estándar IEEE - 830 1998, Modelo RMM, modelo CMMI-DEV. Obtenido de repositorio utn: http://repositorio.utn.edu.ec/bitstream/123456789/7801/1/04%20ISC%20390%20TRABAJO%20GRADO.pdf Proal, E. S. (2014). Historia del IEEE en Jalisco. Obtenido de IEEE Seccion Guadalajara: https://www.ieeegdl.org/historia/