Quelle norme a remplacé la 830-1998?


17

J'ai cherché à documenter les projets logiciels de manière plus formelle et j'ai découvert IEEE 830-1998: Pratique recommandée pour les spécifications des exigences logicielles . Cependant, comme vous pouvez le voir sur ce lien, il a été remplacé.

Je sais que 830-1998, et probablement même 830-1993, sont probablement très bien à utiliser. Cependant, si rien d'autre, je voudrais savoir quelle norme l'a remplacée. Dans ce cas, cela peut ne pas avoir d'importance, mais si d'autres normes sont remplacées pour des choses plus techniques, je pense que ce serait une bonne idée de lier quelque part quelle norme en remplace une autre (si ce n'est pas une autre de la même ligne (830, dans ce Cas)).

Il est important de mentionner que:

  1. La norme la plus récente lors de la recherche de «Software Requirements Specifications» ou «Software Requirements» sur le site Web de l'IEEE Standards Association est 830-1993,
  2. La version 2004 (actuelle) de SWEBOK fait référence à 830-1993 ( paragraphe 2.5 ),
  3. L' article Wikipedia du document ne mentionne pas que la norme a été remplacée.

TLDR: Comment trouvez-vous quelle norme a remplacé une autre et laquelle a pris la place du 830-1998?

Réponses:


23

Réponse courte : 830-1998 n'est pas une norme, c'est une meilleure pratique recommandée sur la façon d'écrire SRS dans le style de 1998.

Je ne trouve pas comment il a été super-semé (même avec la recherche avancée de l'IEEE :()

Mais je suppose que c'est parce que toute la méthode sur la façon dont nous spécifions les exigences a radicalement changé ces dernières années.

Donc, à partir de maintenant, j'essaie de répondre à une question modifiée:

Quelles sont les meilleures pratiques industrielles / Quelles sont les meilleures pratiques recommandées pour la rédaction de SRS dans le style de 2012?

Sur les méthodes classiques:

Habituellement, j'utilise les recommandations IEEE 1471 pour la documentation du logiciel, bien que cela ait également été récemment remplacé par ISO / IEC 42010. Il s'agit d'un type de documentation très complexe, il est principalement utilisé pour les transferts, bien qu'il contienne principalement les exigences (c'est le chapitre 7 dans le nouveau document de style ISO)

Un livre moyennement bon sur la documentation formelle est Documenting Software Architectures , un livre étonnamment bon est l' ancien livre iconix , et un vieux classique est les cas d'utilisation efficace de l'écriture de Cockburn .

Comment cela se fait actuellement dans l'industrie:

À vrai dire, la documentation formelle du projet, en particulier la documentation des exigences, a été détruite principalement à l'ère de l'Agile , car le Manifeste Agile décourage la documentation formelle. Il n'y a pas de spécification formelle unique, large, mais à la place, il y a ce qu'on appelle des user stories , des backlogs de produits et autres. Cela est dû au développement itératif, seules quelques fonctionnalités sont spécifiées de manière informelle pour chaque cycle de 2 à 4 semaines. Un livre de renom est User Stories Applied .

Il existe des spécifications dites «exécutables», qui sont formelles , car ce sont essentiellement des langages spécifiques au domaine (DSL) pour les tests. Ils ne sont ni meilleurs ni pires que OCL d'UML , mais ils sont peut-être plus faciles à saisir mais aussi moins scientifiques. La plupart d'entre eux sont appelés frameworks BDD, et des exemples incluent FitNesse , Cucumber , Jasmine - vous en trouverez un grand nombre. Il existe également des livres renommés sur le BDD et le TDD en général.

De plus, les spécifications des ingénieurs logiciels ont été remplacées par la conception UX , y compris l'architecture de l'information et la conception d'interaction, de sorte que cela n'est pas fait par des personnes qui peuvent réellement coder de nos jours, ce qui peut parfois entraîner des conflits. Ceci n'est pas un si mauvais exemple sur la façon dont on ressemble (ce n'est pas un standard!), Mais vous en trouverez beaucoup plus au sein de la communauté UX / interaction, mais il y a même un site d' échange de piles distinct pour eux. Ils ont leurs propres normes, meilleures pratiques recommandées, etc.

Mais que faire si vous voulez vous en tenir aux anciennes méthodes, par exemple. pour un travail universitaire?

En général, essayez d'adhérer à l'IEEE 830 (vous ne pouvez pas trouver sur leur page Web de quoi il a été remplacé, bien que l'IEEE n'ait jamais été bon avec cela, je suppose que c'est parce que cela n'a plus d'importance malheureusement), et assurez-vous d'essayer pour enregistrer des informations utiles (par exemple, je ne pense pas qu'une seule figure de bâton d'acteur -> seule bulle avec un verbe-sujet soit considérée comme utile) à partir de laquelle les objectifs globaux des utilisateurs, la gamme globale des utilisateurs et les méthodes globales de l'utilisation peut être reconstruite à tout moment.

Pourquoi recommandez-vous des livres? Pourquoi ne me montrez-vous pas des normes à la place?

Encore une fois, je suppose que ce document a été "dépassé" parce qu'aujourd'hui, nous avons un peu de chaos autour de la spécification des exigences: il existe de nombreux points de vue sur la façon de le faire.

Aucune autorité n'est en mesure de vous dire: "c'est ainsi que les spécifications doivent être établies" . Il existe des pratiques exemplaires et j'ai essayé de vous fournir une liste représentative de documents et de directives , bien que nullement complète, et peut-être personnelle.

À la fin de la journée, ce qui importe, c'est de savoir si le document que vous créez est capable d'atteindre tous les objectifs que toutes les personnes qui l'ont lu ont avec lui : ce que les gens veulent voir, ce que les gens doivent savoir pour comprendre les exigences. sont assez bien décrits dans ces livres, et ce sont les meilleures pratiques à part entière, bien que dans des communautés beaucoup plus petites qu'une communauté informatique unique, ce que nous avions peut-être en 1998.


Certains liens sont rompus ...
Tanmay Patil

9

J'ai trouvé cela sur le site IEEE: http://standards.ieee.org/findstds/standard/29148-2011.html

La norme 29148: 2011 semble remplacer l'IEEE 830: 1998.

Cette norme remplace IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

L'ISO / CEI / IEEE 29148: 2011 contient des dispositions pour les processus et les produits liés à l'ingénierie des exigences pour les systèmes et les produits et services logiciels tout au long du cycle de vie.

Il définit la construction d'une bonne exigence, fournit les attributs et les caractéristiques des exigences et discute de l'application itérative et récursive des processus d'exigences tout au long du cycle de vie.


2
Essayez d'étendre votre réponse avec quelques détails sur ce qui est contenu à l'intérieur de votre lien.

Il convient de noter que les normes IEEE ne sont PAS GRATUITES, comme dans le discours OU comme dans la bière. Je ne peux pas vous dire combien ils facturent, car le nouveau pare-feu d'entreprise ne permet pas à leur page d'achat de fonctionner.
John R. Strohm

Selon votre niveau d'abonnement, cela pourrait coûter de 175 $ à 205 $. J'en ai trouvé une copie sur le site interne de notre université. Il est temps de perdre un peu de sommeil ...
Gerrie
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.