Quale standard ha sostituito 830-1998?


17

Ho esaminato come documentare i progetti software in modo più formale e ho appreso IEEE 830-1998: pratica consigliata per le specifiche dei requisiti software . Tuttavia, come puoi vedere da quel link, è stato sostituito.

So che 830-1998, e probabilmente anche 830-1993, sono probabilmente adatti all'uso. Tuttavia, se non altro, vorrei sapere quale standard lo ha sostituito. In questo caso potrebbe non importare, ma se altri standard vengono sostituiti per cose più tecniche, penso che sarebbe una buona idea collegare da qualche parte quale standard ha sostituito un altro (se non è un altro nella stessa linea (830, in questo Astuccio)).

Vale la pena ricordare che:

  1. Lo standard più recente durante la ricerca di "Specifiche dei requisiti software" o "Requisiti software" sul sito Web IEEE Standards Association è 830-1993,
  2. La versione 2004 (corrente) dei SWEBOK riferimenti 830-1993 ( paragrafo 2.5 ),
  3. L' articolo di Wikipedia del documento non menziona che lo standard è stato sostituito.

TLDR: Come trovi quale standard ha sostituito un altro e quale ha preso il posto dell'830-1998?

Risposte:


23

Risposta breve : 830-1998 non è uno standard, è una best practice consigliata su come scrivere SRS nello stile del 1998.

Non riesco a trovare come è stato sostituito (anche con la ricerca avanzata dell'IEEE :()

Ma credo sia perché l'intero metodo su come specifichiamo i requisiti è cambiato drasticamente negli ultimi anni.

Quindi, da ora in poi, provo a rispondere a una domanda modificata:

Quali sono le migliori pratiche industriali / Quali sono le migliori pratiche consigliate per la scrittura di SRS nello stile del 2012?

Sui metodi classici:

Di solito utilizzo i consigli IEEE 1471 per la documentazione del software, anche se recentemente è stato superato da ISO / IEC 42010. Questo è un tipo di documentazione molto complesso, viene utilizzato principalmente per i passaggi di mano, sebbene contenga principalmente i requisiti (è il capitolo 7 della nuovo documento in stile ISO)

Un libro moderatamente buono sulla documentazione formale è Documenting Software Architectures , un libro sorprendentemente buono è il vecchio libro iconix , e un vecchio classico sono i casi di scrittura efficace di Cockburn .

Su come viene effettivamente fatto oggi nel settore:

A dire la verità, la documentazione formale del progetto, in particolare la documentazione sui requisiti, è stata eliminata principalmente nell'età di Agile , poiché il Manifesto Agile scoraggia la documentazione formale. Non esiste una specifica unica, singola e di grandi dimensioni, ma esistono invece cosiddette storie utente , arretrati di prodotti e simili. Ciò è dovuto allo sviluppo iterativo, solo una manciata di funzioni sono specificate in modo informale per ciascun ciclo di 2-4 settimane. Un libro rinomato è User Stories Applied .

Esistono specifiche cosiddette "eseguibili", che sono formali , poiché sono essenzialmente linguaggi specifici di dominio (DSL) per i test. Essi non sono meglio o peggio di quella di UML OCL , ma sono più facili da cogliere, forse, ma anche meno scientifica. Molti di questi sono chiamati framework BDD, e alcuni esempi includono FitNesse , Cucumber , Jasmine : ne troverai molti . Ci sono anche libri famosi su BDD e TDD in generale.

Inoltre, le specifiche degli ingegneri del software sono state sostituite dalla progettazione di UX , compresa l'architettura delle informazioni e la progettazione delle interazioni, quindi non sono fatte da persone che possono effettivamente codificare al giorno d'oggi, il che può portare a conflitti a volte. Questo è un esempio non male di come appare (non è uno standard!), Ma troverai molto di più all'interno della comunità UX / interazione, ma c'è anche un sito stackexchange completamente separato per loro. Hanno i loro standard, le migliori pratiche consigliate, ecc.

Ma cosa succede se si desidera attenersi ai vecchi metodi, ad es. per lavoro universitario?

In generale, prova ad aderire a IEEE 830 (non riesco a trovare sulla loro pagina web con cosa è stato superato, anche se IEEE non è mai stato bravo con questo, suppongo sia perché sfortunatamente non conta più) e assicurati di provare per registrare informazioni utili (ad esempio, non penso che una singola figura stilizzata dell'attore -> una singola bolla con un soggetto verbo sia considerata utile) da cui gli obiettivi generali degli utenti, la gamma complessiva degli utenti e i metodi generali di l'utilizzo può essere ricostruito in qualsiasi momento.

Perché consigli i libri? Perché invece non mi mostri standard?

Ancora una volta, immagino che questo documento sia stato "superato" perché oggi abbiamo un po 'di caos attorno alla specifica dei requisiti: ci sono molti punti di vista su come dovrebbe essere fatto.

Non esiste un'unica autorità in grado di dirti: "ecco come devono essere fatte le specifiche" . Esistono buone pratiche e ho cercato di fornirti un elenco rappresentativo di documenti e indicazioni , anche se non completo, e forse di parte.

Alla fine della giornata, ciò che conta è se il documento che crei è in grado di soddisfare tutti gli obiettivi che tutte le persone che lo leggono hanno con sé : ciò che le persone vogliono vedere, ciò che le persone devono sapere per comprendere i requisiti sono piuttosto ben descritti in questi libri, e queste sono le migliori pratiche a sé stanti, sebbene in comunità molto più piccole di una singola comunità IT indivisa, ciò che forse abbiamo avuto nel 1998.


Alcuni collegamenti sono interrotti ...
Tanmay Patil,

9

Ho trovato questo nel sito IEEE: http://standards.ieee.org/findstds/standard/29148-2011.html

La norma 29148: 2011 viene sostituita all'IEEE 830: 1998.

Questo standard sostituisce IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

ISO / IEC / IEEE 29148: 2011 contiene disposizioni per i processi e i prodotti relativi all'ingegneria dei requisiti per sistemi e prodotti e servizi software durante l'intero ciclo di vita.

Definisce la costruzione di un buon requisito, fornisce attributi e caratteristiche dei requisiti e discute l'applicazione iterativa e ricorsiva dei processi dei requisiti durante l'intero ciclo di vita.


2
Prova ad espandere la tua risposta con alcuni dettagli su ciò che è contenuto all'interno del tuo link.

Va notato che gli standard IEEE NON SONO GRATUITI, come nel discorso o come nella birra. Non posso dirti quanto addebitano, in quanto il nuovo firewall aziendale non consente alla loro pagina di acquisto di funzionare.
John R. Strohm,

A seconda del livello di abbonamento, potrebbe costare da $ 175 a $ 205. Ne ho trovato una copia sul sito interno della nostra uni. È ora di perdere un po 'di sonno ...
Gerrie,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.