¿Qué estándar reemplazó a 830-1998?

17

He estado investigando cómo documentar proyectos de software de manera más formal, y he aprendido sobre IEEE 830-1998: Práctica recomendada para especificaciones de requisitos de software . Sin embargo, como puede ver en ese enlace, se ha reemplazado.

Sé que 830-1998, y probablemente incluso 830-1993, probablemente estén bien para usar. Sin embargo, si nada más, me gustaría saber qué estándar lo ha reemplazado. En este caso, puede no importar, pero si se reemplazan otros estándares por cosas más técnicas, creo que sería una buena idea vincular en algún lugar qué estándar reemplazó a otro (si no es otro en la misma línea (830, en este caso)).

Vale la pena mencionar que:

  1. El estándar más reciente al buscar "Especificaciones de requisitos de software" o "Requisitos de software" en el sitio web de la Asociación de Estándares de IEEE es 830-1993,
  2. La versión 2004 (actual) de SWEBOK hace referencia a 830-1993 ( párrafo 2.5 ),
  3. El artículo de Wikipedia del documento no menciona que el estándar fue reemplazado.

TLDR: ¿Cómo encuentra qué estándar reemplazó a otro y cuál tomó el lugar de 830-1998?

usuario1564158
fuente

Respuestas:

23

Respuesta corta : 830-1998 no es un estándar, es una mejor práctica recomendada sobre cómo escribir SRS al estilo de 1998.

No puedo encontrar cómo se superó (incluso con la búsqueda avanzada de IEEE :()

Pero supongo que es porque todo el método sobre cómo especificamos los requisitos ha cambiado drásticamente en los últimos años.

Entonces, a partir de ahora, trato de responder un poco de pregunta modificada:

¿Cuál es la mejor práctica industrial / ¿Cuáles son las mejores prácticas recomendadas para escribir SRS al estilo de 2012?

En métodos clásicos:

Por lo general, uso las recomendaciones IEEE 1471 para la documentación del software, aunque eso también fue reemplazado recientemente por ISO / IEC 42010. Este es un tipo de documentación muy complejo, se usa principalmente para traspasos, aunque contiene principalmente los requisitos (es el capítulo 7 en el nuevo documento de estilo ISO)

Un libro moderadamente bueno sobre documentación formal es Documenting Software Architectures , un libro sorprendentemente bueno es el viejo libro iconix , y un viejo clásico es Escritura de casos de uso efectivo de Cockburn .

Sobre cómo se hace actualmente en la industria hoy:

A decir verdad, la documentación formal del proyecto, especialmente la documentación de requisitos, se eliminó principalmente en la era de Agile , ya que el Manifiesto Ágil desalienta la documentación formal. No existe una especificación formal única, grande, pero en su lugar, existen las llamadas historias de usuarios , los atrasos de productos y demás . Esto se debe al desarrollo iterativo, solo un puñado de características se especifican informalmente para cada ciclo de 2-4 semanas. Un libro de renombre es User Stories Applied .

Existen las denominadas especificaciones "ejecutables", que son formales , ya que son esencialmente lenguajes específicos de dominio (DSL) para pruebas. No son mejores ni peores que el OCL de UML , pero quizás son más fáciles de entender pero también menos científicos. La mayoría de ellos se denominan marcos BDD, y los ejemplos incluyen FitNesse , Cucumber , Jasmine ; encontrarás una gran cantidad de estos. También hay libros de renombre sobre BDD y TDD en general.

Además, la especificación de los ingenieros de software fue superada por el diseño de UX , incluida la arquitectura de la información y el diseño de interacción, por lo que no lo hacen personas que realmente pueden codificar en la actualidad, lo que a veces puede generar conflictos. Este es un ejemplo no tan malo de cómo se ve (¡no es un estándar!), Pero encontrará mucho más dentro de la comunidad UX / interacción, pero incluso hay un sitio de intercambio de pila completamente separado para ellos. Tienen sus propios estándares, mejores prácticas recomendadas, etc.

Pero, ¿qué pasa si quieres seguir con los viejos métodos, por ejemplo para el trabajo universitario?

En general, intente adherirse al IEEE 830 (no puedo encontrar en su página web con qué fue reemplazado, aunque IEEE nunca fue bueno con esto, supongo que es porque desafortunadamente ya no importa), y asegúrese de intentarlo para registrar información útil (por ejemplo, no creo que una sola figura de actor -> una sola burbuja con un tema verbal se considere útil) a partir de la cual los objetivos generales de los usuarios, el rango general de usuarios y los métodos generales de El uso puede ser reconstruido en cualquier momento.

¿Por qué me recomiendan libros? ¿Por qué no me muestras estándares?

Una vez más, supongo que este documento fue "superado" porque hoy en día, tenemos un poco de caos en torno a la especificación de requisitos: hay muchos puntos de vista sobre cómo debería hacerse.

No existe una autoridad única que pueda decirle: "así es como deben hacerse las especificaciones" . Hay mejores prácticas , y traté de proporcionarle una lista representativa de documentos e instrucciones , aunque de ninguna manera completa, y quizás sesgada personalmente.

Al final del día, lo que importa es si el documento que crea es capaz de cumplir con todos los objetivos que todas las personas que lo leyeron tienen : lo que la gente quiere ver, lo que la gente necesita saber para comprender los requisitos. están bastante bien descritos en estos libros, y estas son las mejores prácticas por derecho propio, aunque en comunidades mucho más pequeñas que una comunidad de TI única e indivisa, lo que quizás tuvimos en 1998.

Aadaam
fuente
Algunos enlaces están rotos ...
Tanmay Patil
9

Encontré esto en el sitio de IEEE: http://standards.ieee.org/findstds/standard/29148-2011.html

El estándar 29148: 2011 busca reemplazar el IEEE 830: 1998.

Este estándar reemplaza a IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

ISO / IEC / IEEE 29148: 2011 contiene disposiciones para los procesos y productos relacionados con la ingeniería de requisitos para sistemas y productos y servicios de software a lo largo del ciclo de vida.

Define la construcción de un buen requisito, proporciona atributos y características de los requisitos y analiza la aplicación iterativa y recursiva de los procesos de requisitos a lo largo del ciclo de vida.

Fabricio
fuente
2
Intente ampliar su respuesta con algunos detalles sobre lo que contiene su enlace.
Cabe señalar que los estándares IEEE NO SON GRATUITOS, como en el discurso O como en la cerveza. No puedo decir cuánto cobran, ya que el nuevo firewall corporativo no permite que su página Comprar funcione.
John R. Strohm
Dependiendo de su nivel de suscripción, podría costar entre $ 175 y $ 205. Sin embargo, encontré una copia en el sitio interno de nuestra unidad. Es hora de perder algo de sueño ...
Gerrie