Conception GOST du code du programme. Règles de préparation des cours et des diplômes. Brève description des normes DUME disponibles

		Règles d'inscription et exigences relatives au contenu des cours		Édition 2
		projets (travaux) et travaux finaux de qualification		page 39 sur 73
	Plan d'assemblage d'une unité d'assemblage
	sous le numéro 8, inclus dans le produit 1		PK.760108.000 SB
	Dessin d'assemblage d'un assemblage séparé
	unités 4		PK.760004.000 SB
	Vue générale d'un assemblage séparé
	unités 4		PK.760004.000 VO
	Dessin de la pièce numéro 16 inclus dans
	unité d'assemblage 8 produits 1
	Dessin de la pièce numéro 120 inclus dans
	unité d'assemblage séparée 4
	Schéma électrique du produit 1		PK.760100.000 E3
	Schéma cinématique séparé
	pas d'unité de montage 4		PK.760400.000 K3
	Spécification de l'unité d'assemblage 8 produit 1

10 Préparation des documents technologiques

10.1 Les documents technologiques des projets de cours (travaux) et des travaux finaux de qualification sont établis conformément aux exigences des normes ESTD.

10.2 Les documents technologiques doivent inclure :

– page de titre, conçue conformément à GOST 3.1105-84 « ESTD. Forme et règles d'exécution des documents à usage général » (Formulaire 2a).

– carte d'itinéraire publiée conformément à GOST 3.1118-82 « ESTD. Formulaires et règles d'établissement des cartes routières" ;

– usinage des cartes d'exploitation et opérationnelles

calcul et cartes technologiques pour les opérations technologiques sur les machines CNC - conformément à GOST 3.1404-86 « ESTD. Formulaires et règles de préparation des documents pour les processus technologiques et les opérations de découpe" ;

– cartes d'exploitation de serrurier, travaux de plomberie et d'assemblage conformément à GOST 3.1407-86 « ESTD. Formulaires et exigences pour le remplissage et le traitement des documents pour les processus technologiques (opérations) spécialisés dans les méthodes d'assemblage" ;

– croquis de cartes (si nécessaire) selon GOST 3.1105-84 et GOST 3.1128-93 « ESTD. Règles générales d'exécution des documents technologiques graphiques" ;

– cartes de contrôle de processus opérationnel selon GOST 3.1502-85 « ESTD. Formulaires et règles d'établissement des documents pour le contrôle technique" ;

– d'autres documents technologiques (si nécessaire ou comme décidé par le chef de projet).

10.3 Les dessins de réparation sont réalisés conformément aux règles prévues par GOST 2.604-88 « Dessins de réparation ».

10.4 Les documents technologiques doivent être reliés

directement dans la note explicative du travail de cours (projet) ou après les candidatures, cahiers des charges et listes d'éléments. Les documents technologiques ont leur propre numérotation.

11 Préparation des documents de programme

11.1 Les documents sur divers domaines problématiques développés dans les projets de cours (travaux) et les travaux finaux de qualification doivent être formatés comme suit :

– documents du programme - conformément aux exigences du DUME,

– documents pour un système de contrôle automatisé - selon les normes nationales des systèmes de documentation technologique pour les systèmes de contrôle automatisés. 11.2 Les documents du programme (listes des programmes) doivent inclure :

– texte du programme, conçu conformément à GOST 19.401 ;

– description du programme, réalisée conformément à GOST 19.402 ;

– description de la note donnée conformément à GOST 19.502 ;

– d'autres documents du programme (si nécessaire).

11.3 Les listes de programmes sont placées dans les applications avec des liens obligatoires vers eux dans le PP.

11.4 Le code du programme peut être accompagné de commentaires. Lors de la conception d’annonces, il est recommandé d’utiliser la police Courier New, taille – 12 pt, interligne – simple. Il est recommandé de séparer les blocs sémantiques par des lignes vides, ainsi que d'indiquer visuellement les structures imbriquées à l'aide de retraits.

11.5 Les mots clés et les commentaires dans les listes de programmes peuvent être en italique. Dans le texte principal du PP, les noms des bibliothèques, sous-programmes, constantes, variables, etc. doivent être en italique.

11.6 Les listes de programmes doivent être numérotées de manière séquentielle dans la candidature. Le numéro d'inscription doit être composé de la désignation de la demande et du numéro d'ordre de l'inscription, séparés par un point, par exemple : « Liste A.3 » est la troisième inscription de l'annexe A. Si le projet (travaux) ne contient qu'un listing, il est désigné « Listing 1 ». Lorsqu'il est fait référence à une inscription dans le texte du PP, le mot « inscription » doit être écrit en indiquant son numéro.

11.7 Le titre du listing du programme est dans la même police que le texte principal et est placé au-dessus du listing à gauche, sans retrait, séparé par un tiret, après le numéro du listing.

Un exemple de conception de listage de programme Listing A.3 – Programme « Sortie d'un tableau bidimensionnel »

mas: tableau d'entiers ; ( déclaration d'un tableau à deux dimensions) je,j:entier;

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

(Saisie des valeurs des éléments du tableau) pour i:=1 à 5 do

pour j:=1 à 5, faites readln(mas);

(Impression des valeurs des éléments du tableau) pour i:=1 à 5 commencez

pour j:=1 à 5 do write(" ",mas); écrire;

12 Contrôle standard

12.1 Le contrôle standard est l'étape finale de l'élaboration des documents pour le projet de cours (travail) et le projet.

12.2 Le contrôle standard doit être conforme aux exigences de GOST 2.111.

12.3 Les travaux finaux de qualification sont soumis à un contrôle normatif. Un contrôle standard des projets de cours (travaux) est effectué par l'enseignant lors de la soutenance du travail. Le contrôle réglementaire vise à la bonne exécution des documents textuels et graphiques des projets de cours (travaux) et des travaux techniques (ci-après dénommés documents) conformément aux exigences des normes GOST, ESKD, ESPD et ESTD.

12.4 Le contrôle normatif est effectué par un inspecteur des normes en tenant compte des exigences en vigueur, des normes et documents réglementaires et techniques.

12.5 Dans le processus de contrôle normatif des notes explicatives des projets de cours (travaux) et des travaux techniques, sont vérifiés :

– le respect des règles d'immatriculation conformément au présent Règlement ;

– apparition du PZ ;

– l'exhaustivité de la conception conformément à la mission de conception ;

– la page de titre est correctement remplie et les signatures requises sont présentes ;

– achèvement correct de l'énoncé du projet (travaux) ;

– présence et exactitude des cadres et des inscriptions principales sur toutes les pages ;

– la mise en évidence des titres, sections et sous-sections, de la présence de lignes rouges ;

– mise en forme correcte du contenu, correspondance des noms des sections et sous-sections du contenu avec les noms correspondants dans le texte de la note ;

– numérotation correcte des pages, sections, sous-sections, figures, tableaux, formules ;

– l'exactitude des dessins ;

– formatage correct des tableaux ;

– l'exactitude des dimensions des grandeurs physiques, leur conformité au SI ;

– le respect des normes de la langue russe moderne ;

– l'exactitude des abréviations de mots utilisées ;

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

– disponibilité et exactitude des références aux sources utilisées ;

– disponibilité et exactitude des références aux documents réglementaires ;

– exactitude de la liste des sources utilisées ;

– conception correcte de l'application.

12.6 Dans le processus de contrôle normatif des documents graphiques des projets de cours (travaux) et des travaux techniques, sont vérifiés :

– conformité des dessins aux exigences des normes en vigueur ;

– exécution des dessins conformément aux exigences des documents réglementaires ;

– respect des formats, exactitude de leur conception ;

– dessin et application corrects des lignes ;

– respect des barèmes, exactitude de leur désignation ;

– suffisance des images (types, coupes, coupes), exactitude de leur désignation et de leur emplacement ;

– le respect des symboles des éléments dans les schémas et des règles de leur mise en œuvre conformément aux exigences de l'ESKD.

12.7. Il est recommandé d'effectuer le contrôle standard des travaux finaux de qualification en deux étapes : après l'ébauche (ou en lignes fines) et l'élaboration finale des documents originaux. Les documents en cours d'élaboration doivent être soumis au contrôle réglementaire dans un ensemble complet, c'est-à-dire documentation textuelle (note explicative) et graphique (dessins, spécifications, etc.).

12.8 Une liste de commentaires de l'inspecteur des normes est établie dans le cas où le contrôle est effectué en l'absence d'un étudiant développeur et que l'essence des erreurs peut être mal interprétée par lui.

12.9 Les documents vérifiés par l'inspecteur normatif en présence de l'étudiant-développeur, accompagnés de la liste des commentaires (si elle est établie), sont restitués à l'étudiant pour corrections et révision. Si des commentaires existent, les notes de l’inspecteur des normes sont conservées jusqu’à ce qu’il signe le document. Si un document est retravaillé par un étudiant, alors les deux exemplaires sont soumis pour recontrôle : avec les notes de l'inspecteur normatif et celui révisé.

12.10 Les documents soumis à la signature du contrôleur normatif doivent avoir tous les visas d'approbation, à l'exception du visa du chef de service. Les originaux finaux des projets de cours et de diplôme (travaux) sont signés par l'inspecteur normatif

V colonne "N.cont." inscription principale.

12.11 Il est interdit d'introduire à l'insu de l'inspecteur normatif toute modification apportée au document après que ce document ait été signé et approuvé par l'inspecteur réglementaire.

12.12 L'inspecteur chargé de la réglementation a le droit, dans des cas justifiés, de ne pas signer le document fourni :

– en cas de non-respect des exigences des documents réglementaires ;

– en l’absence de signature obligatoire ;

- s'il est effectué avec négligence ;

– en cas de violation de l'exhaustivité établie.

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

12.13 Le contrôleur normatif est responsable du respect des exigences des normes en vigueur et autres documents réglementaires et techniques dans la documentation en cours d'élaboration, en collaboration avec les développeurs de la documentation.

13 Bilan du WRC

13.1 Pour obtenir une évaluation objective complémentaire du travail final de qualification soumis à la soutenance, un examen externe du travail final de qualification est effectué par des spécialistes du domaine concerné.

13.2 Les évaluateurs des travaux finaux de qualification sont des spécialistes hautement qualifiés, dont la liste personnelle est déterminée par le département diplômé. Les personnes suivantes peuvent être impliquées en tant qu’évaluateurs : praticiens et enseignants d’autres universités.

Une saisine en révision est émise par le département diplômé dont le formulaire est présenté à l'annexe T du présent règlement.

13.3 L'évaluateur doit être familier avec toutes les exigences relatives au travail final de qualification (GQR).

13.4 L'examen est établi par écrit et contient des appréciations motivées :

– pertinence du thème de la WRC ;

– la conformité du contenu des travaux de recherche et développement avec la tâche de leur développement ;

– exactitude de la structure logique du WRC ;

– efficacité et validité des décisions de conception ;

– les avantages et les inconvénients de l'école doctorale, sa conformité aux exigences de qualification d'un diplômé dans le domaine d'études ;

– enregistrement de VKR.

Dans la dernière partie de la revue, des conclusions sont données sur l'exhaustivité du développement du sujet, conformément aux tâches fixées, sur l'importance théorique ou pratique des travaux de recherche et développement, sur le domaine d'utilisation possible de les résultats des travaux de recherche. L'évaluateur évalue le travail sur une échelle de quatre points (« excellent », « bon », « satisfaisant », « insatisfaisant ») et indique la possibilité d'attribuer la qualification appropriée à l'étudiant.

13.5 Le volume d'une critique d'un travail final admissible doit être 2-3 pages de texte imprimé ou clairement manuscrit. Le compte rendu signé doit être remis au département au plus tard trois jours avant la soutenance de la thèse.

13.6 L'évaluation peut être effectuée sur papier à en-tête de l'organisation (lieu de travail de l'évaluateur), ou sur le formulaire standard réglementé par le présent Règlement (Annexe U) et certifié par le sceau de l'organisation, ou le sceau du service du personnel (général service, bureau) avec la mention « la signature est correcte ».

13.7 Afin de soutenir la thèse, vous pouvez en outre soumettre un avis de l'organisme leader mandaté par la commission de certification d'État.

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

Un magnétoscope a été réalisé. L'examen devrait mettre en évidence la valeur pratique des résultats obtenus.

14 Retour sur le WRC

14.1 Les retours sur le travail final qualifiant sont compilés directement par son superviseur. La revue doit caractériser la thèse sous différents aspects : du contenu, de la structure, de l'exhaustivité du sujet sélectionné, etc.

14.2 Le superviseur doit exprimer dans l’évaluation son opinion objective sur le travail final qualifiant de l’étudiant. En particulier, l'avis doit contenir des informations :

– sur la pertinence du sujet de travail ;

– sur la conformité des travaux finaux de qualification aux exigences des normes ;

– sur la connaissance de l’étudiant des méthodes de collecte, de traitement et d’analyse de l’information utilisées dans le domaine de l’activité professionnelle ;

– sur la capacité de l’étudiant à travailler de manière indépendante avec des sources de manière claire et claire et cohérente ;

– sur les aspects positifs du travail ;

– sur les lacunes et les commentaires sur le contenu de l'ouvrage, etc.

14.3 L'examen par le superviseur du travail final admissible peut contenir des suggestions concernant l'évaluation globale du travail.

14.4 A l'issue de l'examen, le superviseur tire une conclusion sur la possibilité de soumettre le travail final qualifiant pour la soutenance à la Commission nationale d'attestation.

14.5 Le texte de l'évaluation de la thèse par le directeur de thèse est imprimé sur des feuilles A4 et signé par le directeur de thèse. Le formulaire de feedback pour le WRC est présenté en Annexe F.

15 Rapport et présentation

15.1 Un rapport (discours) est un travail de nature présentation, reflétant l'essence du WRC.

Le rapport doit aborder la pertinence du sujet choisi, les fondements théoriques et méthodologiques des travaux, ainsi que résumer et résumer les résultats obtenus au cours de l'étude.

A la fin de la présentation, il est nécessaire de réfléchir à la signification pratique des résultats, à la possibilité de leur mise en œuvre dans la pratique ou de leur utilisation dans l'enseignement.

15.2 Le rapport est conçu pour un temps de parole donné et limité et est inextricablement lié à la présentation (polycopiés).

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

15.3 La présentation (document) est un matériel visuel numérique, tabulaire et illustratif préparé à l'aide de programmes spéciaux (par exemple, Microsoft PowerPoint) directement lié au rapport.

15.4 Pour la présentation, le matériel illustratif nécessaire est sélectionné, qui peut être extrait à la fois du texte de l'ouvrage et des annexes. Il peut s'agir de tableaux, d'images, de diagrammes, de diagrammes, de formules, etc. Les tableaux ne doivent pas être volumineux, les images ne doivent pas être trop détaillées et les formules doivent être claires.

Le matériel doit illustrer tous les points soulevés dans le rapport.

15.5 La présentation peut être présentée de deux manières :

– à l'aide d'un projecteur et sur un support ;

– à l'aide de documents sous forme de copies papier pour chaque membre de la commission.

Le volume de la présentation peut aller de 8 à 12 diapositives.

15.6 Le rapport ne doit contenir que l'essence de la question examinée, un minimum de données numériques, des noms spéciaux et une énumération.

Le rapport est construit selon le même schéma logique que le projet (ouvrage), à ​​savoir : partie introductive, partie principale et conclusions. La partie introductive doit contenir la pertinence et le but du travail, la partie principale doit divulguer pleinement le sujet à l'étude. Les conclusions doivent être concises et sans ambiguïté ;

en 1 à 2 phrases, réfléchissez aux recommandations pour résoudre les problèmes posés.

15.7 La première doit être une diapositive avec le thème du projet (œuvre) et les coordonnées de l'interprète, à savoir : nom, prénom, patronyme, groupe, spécialité (direction). Il est conseillé d'indiquer un encadrant scientifique.

15.8 Le projet de cours (travail) et la thèse sont déposés aux archives accompagnés d'une présentation réalisée sous forme électronique et enregistrée sur un support numérique (par exemple, CD/DVD).

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

Annexe A

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

Appendice B

(nom de la faculté)

(nom du département)

____________ ________________

NOTE EXPLICATIVE

pour le projet de cours (travail) dans la discipline (module)__

(nom de la discipline académique (module))

sur le sujet _________________________________________________________________________

_____

	_______________________	______________________________

Direction/spécialité, profil/spécialisation :

___________ _________________________________________________________________

code de direction nom de la direction (spécialité)

________________________________________________________________________________

nom du profil (spécialisation)

Désignation du projet de cours (travail) _________________________ Groupe ________

Rostov-sur-le-Don

Appendice B

MINISTÈRE DE L'ÉDUCATION ET DES SCIENCES DE LA FÉDÉRATION DE RUSSIE

BUDGET DE L'ÉTAT FÉDÉRAL INSTITUTION D'ENSEIGNEMENT PROFESSIONNEL SUPÉRIEUR

"UNIVERSITÉ TECHNIQUE D'ÉTAT DU DON" (DSTU)

La faculté _______________________________________________________

(nom de la faculté)

Département ______________________________________________________________

(nom du département)

Tête département "______________"

____________ ________________

NOTE EXPLICATIVE

pour un projet (travail) de fin d'études sur le thème :

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

			__________________________
	(date de la signature)
Désignation du projet de fin d'études ______________________________				Groupe ______________
Direction (spécialité) ___________		___________________________________
				(Nom)
Chef de projet (travaux)			____________________________
	(date de la signature)			(poste, I.O.F.)
Consultants par sections :
_______________________________				_____________________
(Nom de la section)		(date de la signature)		(poste, I.O.F.)
_______________________________				_____________________
(Nom de la section)		(date de la signature)		(poste, I.O.F.)
Contrôle standard				_____________________
		(date de la signature)		(poste, I.O.F.)

Rostov-sur-le-Don

Règles d'inscription et exigences relatives au contenu des projets de cours (travaux) et des travaux finaux qualificatifs – 09.1

L'objectif principal de ce texte est d'expliquer ce qu'est le Système Unifié de Documentation de Programme (USPD) et comment appliquer ces normes dans la pratique. Je commencerai par une histoire sur les normes existantes et je terminerai par l’expérience de l’application de chacune des normes DUME séparément.

À une époque, alors que je commençais tout juste à travailler en tant que programmeur, j'entendais souvent « s'il vous plaît, écrivez la documentation de votre programme ». J'ai tout décrit honnêtement, je l'ai donné à mon patron, après quoi la séance de magie noire a commencé. Au bout d'un moment, le patron m'a appelé et a commencé à marmonner des sons inarticulés, à froisser l'imprimé de mon « meilleur » texte dans ses mains, en jetant ses yeux. Le sens général de ses meuglements était qu’il s’avérait « faux », « faux » et « regardez ce que font les autres ». Comme il était impossible de lui soutirer une autre réponse, je me suis tourné vers « les autres » pour obtenir des exemples de documents. En règle générale, c'étaient des gars joyeux, dont le sens des discours était que « voici des exemples », « en général, selon GOST » et « personne n'a besoin de tout cela ». C'est ainsi que j'ai appris pour la première fois qu'un programmeur peut entrer en contact avec de terribles normes GOST.
Il est étonnant que parmi plusieurs dizaines de mes collègues, des programmeurs très intelligents, personne ne traite les GOST différemment. Même les quelques personnes qui les connaissaient et, semblait-il, savaient même rédiger des documents, les traitaient avec mépris et formalité. Une situation dans laquelle même les personnes responsables de la gestion du développement ne comprennent pas pourquoi les GOST sont nécessaires et comment ils seront appliqués se produit constamment dans de nombreuses entreprises. Oui, certaines entreprises ont compris en quoi la « description du programme » diffère de la « description de l'application », mais elles étaient clairement une minorité. Sur Internet, le point de vue dominant est que les GOST pour les programmeurs sont un rudiment évident et ne sont nécessaires que s'ils s'y « plient ». Le projet de conception est considéré comme « un moyen relativement équitable de retirer au client les billets en trop ». J'ai dû l'approfondir et le comprendre relativement récemment - dans le processus de développement d'un système de gestion des exigences adapté aux spécificités nationales. Une documentation qui, bien entendu, doit être générée « selon GOST ».

Ici, je veux me concentrer sur un seul sujet auquel un programmeur dans les entreprises nationales, en particulier dans les instituts de recherche, doit traiter : l'ensemble des normes DUME. Je ne me considère pas comme un grand expert du DUME. Il y a des gens qui y travaillent depuis des décennies et qui me corrigeront certainement. L’article tente plutôt de tracer les grandes lignes d’une « feuille de route » pour ceux qui débutent.

Normes

Jetons un bref coup d'œil aux normes existantes (en nous concentrant sur le domaine informatique).

1. international. Une particularité est qu'il a été adopté par une organisation internationale. Un exemple d'une telle organisation est l'ISO (Organisation internationale de normalisation). Un exemple de sa norme : ISO 2382-12:1988 (Équipements périphériques). Les normes communes de l'ISO et de la Commission électrotechnique internationale (CEI, en russe - CEI) sont très répandues : par exemple, ISO/CEI 12207:2008 (cycle de vie des logiciels) ;
2. régional. Une particularité - adoptée par la commission régionale de normalisation. Par exemple, de nombreux GOST soviétiques sont désormais des normes régionales, car adopté par le Conseil interétatique, qui comprend certaines anciennes républiques soviétiques. Ce conseil adopte également de nouvelles normes - et celles-ci reçoivent également la désignation GOST. Exemple : GOST 12.4.240-2013 ;
3. normes des associations publiques; Par exemple, la même CEI : CEI 60255 ;
4. normes nationales. Pour la Russie, le début de ces normes est « GOST R ». Il peut y en avoir trois types :
   1. copies exactes des documents internationaux ou régionaux. Ils sont désignés de manière indiscernable des « auto-écrits » (nationaux, rédigés de manière indépendante) ;
   2. copies internationales ou régionales avec ajouts. Ils sont indiqués en ajoutant au chiffre de la norme nationale le chiffre international qui a servi de base. Par exemple : GOST R ISO/IEC 12207 ;
   3. en fait, des normes nationales. Par exemple, GOST R 34.11-94.

Les systèmes de notation à chaque niveau et dans chaque organisation sont différents ; chaque cas devra être analysé séparément. Pour comprendre rapidement « dont » la norme est sous vos yeux, vous pouvez utiliser un aide-mémoire.

GOST

Donc : les normes sont internationales, interétatiques (régionales) et nationales. GOST, comme nous l'avons découvert, est une norme régionale. Les GOST ont un système de notation plutôt déroutant, à mon avis. Il est entièrement exposé dans GOST R 1.5-2004, je donnerai le minimum pour s'y retrouver. Tout d'abord, il faut faire la distinction entre la désignation GOST et sa classification. Une désignation est, en gros, un identifiant unique pour une norme. Un code classificateur est un code auxiliaire qui permet de trouver une norme ou de déterminer à quel domaine de connaissances il appartient. Il peut y avoir de nombreux classificateurs, principalement deux sont utilisés : KGS (classificateur de normes d'État) et son successeur OKS (classificateur de normes panrusse). Par exemple : "GOST R 50628-2000" est la désignation de la norme. D'après la désignation, il ressort seulement qu'elle a été adoptée en 2000. Il possède un code OKS « 33.100;35.160 » : c'est-à-dire « 33 » - section « Télécommunications, audio, vidéo », « 100 » - sous-section « compatibilité électromagnétique ». Cependant, il est également inclus dans la branche du classificateur 35.160. "35" - "Technologies de l'information. Machines de bureau", "160" - "Systèmes à microprocesseurs...". Et selon le KGS, il porte le code « E02 », qui signifie « E » - « Technologie électronique, radioélectronique et communications », « 0 » - « Règles et réglementations générales pour la technologie électronique, la radioélectronique et les communications », etc.

Si vous connaissez la désignation de la norme, vous pouvez obtenir ses codes KGS et OKS, par exemple, sur ce site intelligent.
Revenons donc aux désignations GOST. Il peut y avoir deux options :

1. norme fait référence à une série de normes. Dans ce cas, après l'index de catégorie standard (par exemple, GOST, GOST R ou GOST RV), il y a un code de série, un point et la désignation de la norme au sein de la série. Les règles de désignation des normes au sein d'une série sont fixées par les règles de la série. Par exemple : GOST RV 15.201-2000, GOST R 22.8.0-99, GOST 19.101-77 ;
2. La norme n'appartient pas à une série de normes. Ensuite, après l'index des catégories, il y a simplement un numéro de série de la norme, un tiret et l'année d'adoption. Par exemple, GOST R 50628-2000.

Donc, pour le dire très simplement, la désignation GOST est soit simplement un numéro de série, un tiret, une année, soit un numéro de série, un point, etc., selon la série. En réalité, tout est plus compliqué (par exemple, vous pouvez trouver quelque chose comme GOST 11326.19-79, et ce ne sera pas du tout la série 11326 - mais les programmeurs en ont très rarement besoin. Pour plus de détails, voir GOST R 1.5-2004).

DUME

L'ESPD est l'une de ces séries GOST, le numéro 19. Autrement dit. toutes les normes liées à l'ESPD commencent par le préfixe « 19 » : par exemple, GOST 19.106-78. Signifie « Système unifié de documentation du programme ». Il existe d'autres séries :

• GOST ESKD (système unifié de documentation de conception, préfixe « 2. ») ;
• GOST ESTD (système unifié de documentation technologique, préfixe « 3. ») ;
• GOST R, Système de développement et de production de produits, préfixe « 15. » ;
• GOST RV, Armement et équipement militaire. Système de développement et de mise en production de produits, préfixe « 15. » ;
• GOST, Système de documentation technique pour les systèmes de contrôle automatisés, préfixe « 24. » ;
• GOST, Ensemble de normes pour les systèmes automatisés, préfixe « 34 ».

Ainsi, le DUME contient un ensemble de normes utilisées dans le développement de logiciels. Ensuite, pour chaque norme du DUME, une brève description et explication des cas non évidents sont données.

19.001-77. Dispositions générales

Décrit les règles d'attribution des désignations aux normes de la série DUME. Pas nécessaire dans la vie pratique.

19.102-80. Schémas d'algorithmes et de programmes. Règles d'exécution.

Décrit les règles de construction et de conception d'algorithmes. Utilise la notation de 19.103. Dans ma pratique, le seul cas où cela était nécessaire était lorsque le laboratoire de certification insistait formellement sur le fait que c'était le diagramme algorithmique qui était nécessaire. De mon point de vue, les organigrammes classiques appartiennent au passé, et le seul endroit où ils restent plus ou moins appropriés est si, lors de la présentation, l’auteur souhaite attirer l’attention du lecteur sur l’algorithme.

19.003-80. Schémas d'algorithmes et de programmes. Symboles graphiques conventionnels

Des désignations graphiques des types acceptables d'éléments de diagramme fonctionnel sont données. Obligatoire si des organigrammes sont utilisés.

19.004-80. Termes et définitions.

Maigre glossaire. Le plus intéressant est qu’il contient des définitions formelles des documents de programme et opérationnels.

19.005-85. Schémas P d'algorithmes et de programmes

Une langue presque oubliée. À une certaine époque, les schémas P étaient largement utilisés dans l’industrie des fusées et de l’espace, devenant ainsi la norme de facto pour l’écriture de programmes de contrôle de lancement et la simulation de lancements. Cependant, cette langue est désormais complètement oubliée. Dans mon travail, je n'ai jamais rencontré de schémas P. Cependant, par rapport aux schémas fonctionnels, ils présentent des avantages notables : ils sont compacts, adaptés à la visualisation d'algorithmes non linéaires (par exemple, des classes en C++) ou de structures de données. En même temps, il n'y a pratiquement aucune information à leur sujet sur Internet : j'ai trouvé ceci et ce site utiles. Dans tous les cas, si je devais maintenant insérer un diagramme d'algorithme dans la documentation du logiciel, je choisirais des diagrammes P plutôt que des organigrammes.

19.101-77. Types de programmes et documents de programme

Contient un tableau de correspondance entre un type de document et son code, ainsi qu'une division des types de documents en opérationnel et programme. La notion de complexe et de composant est introduite. Il n'y a rien d'autre d'utile.

19.102-77. Étapes de développement

Une norme importante et nécessaire qui décrit les types de documents et fournit des codes pour les types de documents de programme. Cette norme (avec 19.103-77) est l'une des clés pour « démêler » les désignations de documents comme ABVG.10473-01 32 01-1.
La norme introduit le concept de complexe et de composant (un certain nombre d'entreprises ajoutent un troisième type - un ensemble, lorsqu'il s'agit d'éléments logiciels non liés), et une division est donnée : quels documents sont opérationnels et lesquels ne le sont pas.
Vous devez être prudent avec le tableau 4, qui montre quel document est en cours d'exécution à quel stade de développement. Les étapes de développement sont généralement réglementées dans des normes pour la mise en œuvre des travaux de conception et de développement, et il y est également indiqué quels documents doivent être présentés au client à chaque étape.

19.102-77. Étapes de développement

Dans ma mémoire, cette norme n'a jamais été utilisée : qui fait quoi à quelle étape et ce dont ils rendent compte est écrit dans les spécifications techniques ou une référence est faite aux GOST, où cela est plus clairement indiqué (par exemple, GOST RV 15.203 ). En même temps, pour un débutant, il contient un aperçu assez succinct des travaux sur les principales étapes du TOC.

19.103-77. Désignations des programmes et documents de programme

Il est nécessaire principalement pour apprendre à lire les symboles de documents similaires à celui donné ci-dessus. Cependant, comprendre le schéma de notation est utile lorsqu'il faut aller au-delà du travail standard : par exemple, rappelez-vous que les documents avec des codes après 90 sont définis par l'utilisateur, c'est-à-dire n'importe lequel. Dans ma pratique, nous avons publié le document 93, que nous avons appelé « Déclaration de documentation du programme », document 96 - « Instructions d'assemblage ».
L’expression courante « option d’exécution » est absente du DUME et est remplacée par « numéro de révision ». D'une part, ce n'est pas tout à fait exact : le numéro de révision était destiné à suivre l'évolution du programme : d'abord la première édition sort, puis, par exemple, après révision, la seconde. Mais en pratique, lorsqu'il faut sortir une version logicielle pour plusieurs systèmes d'exploitation (logiciel multiplateforme), il n'y a pas d'autre choix. Plus précisément, il y en a, mais c'est incorrect : attribuer à la version pour chaque système d'exploitation sa propre désignation - et mettre dans l'archive plusieurs disques avec les codes sources (selon le nombre de systèmes d'exploitation), développer (en fait copier) le ensemble complet de documentation, etc.... Autrement dit. pure activité stupide et déroutante. La solution sous forme d'attribution d'un numéro de version à chaque système d'exploitation permet de rendre communs certains documents.
L'ESPD utilise la désignation du code source du programme et le résultat de l'assemblage comme « documents », ce qui confond de nombreux programmeurs. Le document « texte du programme », selon 19.101-77, porte la désignation 12. Il est en outre admis que le code source est désigné par 12 01 - c'est-à-dire 01 (le premier) document de type 12, et les binaires - comme 12 02 - c'est-à-dire le deuxième document de type 12. Dans certains cas, des outils supplémentaires sont nécessaires pour créer un programme - compilateurs, générateurs d'installateurs, etc. Ceux. programmes qui ne sont pas inclus dans la livraison, mais sont nécessaires au montage. Une solution pourrait être de les désigner comme 12 03 - c'est-à-dire troisième document de type 12.

19.104-78. Inscriptions de base

Décrit deux feuilles du document - la feuille d'approbation (AL) et la page de titre. La feuille d'approbation du DUME contient les signatures des autorités qui ont approuvé le document et des développeurs, des inspecteurs normatifs, des représentants d'acceptation, etc. Ceux. il contient de nombreuses informations sensibles pour l'entreprise. Par conséquent, la norme suppose que la LU reste dans l'entreprise de développement et n'est envoyée que sur instructions spéciales. Encore une fois, le LU ne fait pas partie du document, mais est, pour ainsi dire, un document distinct, et il est inclus dans la spécification sur une ligne distincte.
La bizarrerie initialement déroutante de la séparation de la LU du document lui-même a de très bonnes raisons :

• comme déjà mentionné, une entreprise ne souhaite souvent pas divulguer d'informations sur le développeur. Séparer l'UL et le « presser » permet de le faire (contrairement à l'ESKD, il n'y a pas de cachet sur les fiches documentaires dans le DUME ; toutes les informations sont localisées uniquement dans l'UL) ;
• Un certain nombre d'entreprises utilisent un flux de documents mixte : les documents originaux sont stockés électroniquement dans les archives de l'entreprise et les documents qu'ils contiennent (avec les signatures originales) sont stockés sous forme papier ;

Quant à l'enregistrement des LU, les entreprises utilisent assez souvent un mélange - certaines des inscriptions LU sont établies selon le DUME, certaines - selon l'ESKD, et d'autres - à leur manière. Par conséquent, il est préférable, avant de créer vous-même LU, de rechercher une norme d'entreprise (STO) ou de prendre un exemple du contrôle réglementaire local.
Il faut également rappeler que le LU n'est pas numéroté, que la première page est la page de titre et que la première page sur laquelle le numéro est placé est à côté de la page de titre. Mais s'il y a plus d'une UL (cela se produit si toutes les signatures ne tiennent pas sur la feuille), alors les UL sont numérotées séparément.

19.105-78. Exigences générales pour les documents du programme

La structure générale du document est introduite, quelle que soit la méthode de son exécution. Ceux. En 1978 déjà, il était stipulé dans la norme qu'un document ne devait pas nécessairement être papier. En particulier, la notion de contenu est introduite pour les documents entièrement électroniques. Pour l'exécution papier, courante à l'époque, GOST 19.106-78 a été adopté.
Actuellement, il est rarement nécessaire de se référer à cette norme : à moins d’oublier l’ordre des principales parties du document.

19.106-78. Exigences générales pour les documents de programme imprimés

La norme la plus complète de l'ESPD, juste derrière la description des régimes R. Il s'agit de la principale norme de travail lors de la préparation de la documentation. Introduit des règles de formatage du texte, des éléments de structure du document, des images, des formules, etc. Cependant, contrairement au 2.106 correspondant de l’ESKD, le 19.106 est nettement moins détaillé, ce qui entraîne de nombreuses incertitudes.
Premièrement, la norme ne définit pas réellement l’espacement des lignes ni l’espace vertical entre les titres. Il introduit trois règles pour déterminer l'espacement : pour le texte dactylographié, machine et typographique.
Typescript est un texte tapé sur une machine à écrire. Le décalage de la ligne suivante par rapport à la précédente s'effectuait automatiquement lors du "retour chariot" - la transition vers l'impression de la ligne suivante, réalisée en déplaçant un levier spécial. En règle générale, l'espacement pouvait être ajusté manuellement en tournant l'arbre d'alimentation du papier et disposait d'un « réglage » qui vous permettait de définir la taille de l'espacement - simple ou double.
Le type de machine est très probablement le texte imprimé. Mais pour lui, il n’y a qu’une indication que le résultat doit être microfilmable. Il s'agit d'une référence implicite au 13.1.002-2003, qui, malheureusement, ne fixe l'espacement des lignes (et, soit dit en passant, la hauteur minimale de la police) que pour les documents manuscrits (clause 4.2.5).
Typographique - texte tapé dans une imprimerie. Compte tenu de l’année d’adoption de la norme, il s’agit très probablement de
[impression typographique, où l'espacement des lignes était déterminé par le type utilisé. Je ne suis pas un expert en typographie et il existe actuellement très peu d’informations sur les méthodes de composition.
L'intervalle à utiliser en fin de compte est souvent déterminé par les réglementations locales ou les stations-service. Les valeurs typiques sont un espacement d'un an et demi et une taille de police de 14.
La manière dont un document est structuré soulève souvent de nombreuses questions. 19.106 considère que l'ensemble du document est divisé en sections, sous-sections, paragraphes et sous-paragraphes. Tous (à l'exception des sections et sous-sections) peuvent avoir ou non un titre. Où:

• « le contenu du document comprend le nombre de sections, sous-sections, clauses et paragraphes qui ont un titre » (clause 2.1.4). Il s'agit d'une indication directe que le paragraphe peut avoir un titre et être inclus dans la table des matières ;
• "il est permis de placer du texte entre les titres de section et de sous-section, entre les titres de sous-section et de paragraphe." Il est important de noter que le texte non numéroté ne peut se trouver qu'entre les titres et uniquement aux 2 niveaux supérieurs.

Contrairement à l’ESKD, l’ESPD adopte une manière étrange de concevoir les dessins : vient d’abord le nom du dessin, puis le dessin lui-même, puis le « texte sous la figure » facultatif, puis, sur une nouvelle ligne, « Fig. N".
Cette norme présente un certain nombre de « trous » et d’incohérences. Par exemple, il est dit : « les illustrations, s’il y en a plusieurs dans un document donné, sont numérotées en chiffres arabes sur l’ensemble du document. « Mais s’il n’y a qu’une seule illustration, alors elle n’est pas numérotée, et alors comment peut-on s’y référer ? Il en va de même pour les tableaux. Pour les notes de bas de page, GOST n'indique pas la méthode de leur numérotation - dans l'ensemble du document ou dans la page.
Les tables. Le document lui-même contient une référence à GOST 1.5.68. À en juger par le premier épisode, il est facile de conclure qu'il s'agit d'une norme pour l'élaboration de normes. Ce qu’il a à voir avec cela n’est pas clair. En termes de sens, il correspond aux règles de conception des tableaux de l'ESKD, à quelques exceptions près. Cette norme a été annulée et remplacée, à travers plusieurs itérations, par la version 1.5-2012, dans laquelle les règles de conception des tables... ont tout simplement disparu. En 1.5-2002, ils étaient là, mais déjà en 1.5-2004, ils ont disparu. Dans la vraie vie, nous établissons des tableaux selon l'ESKD.
Applications. La norme n'indique pas si les chiffres, formules et tableaux des annexes sont inclus dans la liste générale. De même, il n'est pas précisé si la table des matières doit divulguer la structure de la demande si elle contient ses propres sections, paragraphes, etc. Dans notre pratique, nous ne divulguons pas l’intérieur des applications.
Enfin, il convient de dire quelque chose à propos de l'indentation. Un retrait de paragraphe de 5 caractères est courant pour :

• ligne rouge;
• indentation d'un élément de structure de document après une section (sous-section, clause, sous-clause) ;
• élément d’énumération.

Dans ce cas, le texte situé sur la ligne suivante après la ligne en retrait est aligné sur la marge de gauche. Il y a souvent des erreurs lorsque l'indentation saute - la ligne rouge - une valeur, le numéro d'article - nous avec un intervalle différent, dans des indentations imbriquées dans des listes - cela est généralement nécessaire.

Dans les parties suivantes, je prévois d'arriver à la fin de la liste des normes DUME.

V.E. Karpov

Ce document contient une brève description des normes ESPD, dont la connaissance est nécessaire pour que les étudiants puissent suivre des cours et des projets liés à la création de systèmes logiciels. De plus, cela peut être utile du point de vue de l’amélioration de la qualité de la documentation logicielle en général.

SPÉCIFICATIONS TECHNIQUES (GOST 19.201-78)

1. Dispositions générales

ÉTAPES DE DÉVELOPPEMENT (GOST 19.102-77)

DESCRIPTION DU PROGRAMME (GOST 19.402-78)

TEXTE DU PROGRAMME (GOST 19.401-78)

PROGRAMME ET MÉTHODOLOGIE DE TEST (GOST 19.301-79)

EXIGENCES RELATIVES AUX DOCUMENTS LOGICIELS IMPRIMÉS (GOST 19.106-78)

Normalisation dans le domaine de la documentation logicielle

Comment avancer

Préparation de la documentation pour le logiciel (PS) conformément aux GOST existants

2. Caractéristiques générales de la condition

2.3. Normes d'État de la Fédération de Russie (GOST R)

2.4. Norme internationale ISO/IEC 12207 : 1995-08-01

L'étape la plus désagréable et la plus difficile du travail de programmation est peut-être la création de la documentation du programme. Malheureusement, soit cela n'est généralement pas enseigné du tout, soit, dans le meilleur des cas, ils ne prêtent pas l'attention voulue à la qualité des documents reçus. Cependant, la maîtrise de cet art est souvent l’un des facteurs les plus importants déterminant la qualité d’un programmeur.

Premièrement, la capacité de créer une documentation sur un programme détermine le niveau professionnel du programmeur. Le client ne se plongera pas dans les subtilités et les caractéristiques du programme, même le plus merveilleux. Le client lira d'abord la documentation. Le facteur psychologique joue également un rôle important à cet égard. En particulier, l’ancienne école de programmation soviétique était (et est toujours) appréciée dans le monde entier. Les programmeurs nationaux modernes ont cessé d'être cités. La classe n'est pas la même. De nos jours, les programmes ne sont plus écrits, mais compilés (et ce sont « deux grandes différences »). Ainsi, un progiciel de documentation (ci-après dénommé PD) créé dans le style « classique » créera l'impression la plus favorable sur votre client ou employeur. De plus, si l’auteur du PD évite les expressions comme « cliquez sur la barre de défilement… », « vissez », etc. Malheureusement, de tels bavardages cachent généralement soit un manque de pensées, soit un vide complet (l'auteur a été indélébile impressionné par l'histoire d'une de ses connaissances à propos d'un certain « joueur » qui « discutait » avec quelqu'un ou était engagé dans une « modération » Ou quelque chose comme ca.). Le langage du PD est une sorte de langage bureaucratique et très conservateur. Il a son propre charme particulier. Convenez que les termes disque dur, lecteur de disque plat, manipulateur portatif tel que « souris » (ou « chignon », comme il était écrit dans l'un des anciens packages PD) sonnent complètement différemment de la « vis » correspondante. flop » et simplement « souris ». À propos, les choses ont déjà atteint le point où, disent-ils, même une spécialité spéciale est apparue - le rédacteur technique, c'est-à-dire une personne qui sait créer de la documentation sur un logiciel.

Deuxièmement, un package PD bien conçu (plus précisément créé) vous évitera de nombreux problèmes. En particulier, vous pouvez vous débarrasser des questions ennuyeuses et des réclamations infondées en renvoyant simplement l'utilisateur à la documentation. Cela concerne tout d'abord le document le plus important - les termes de référence. Nous en parlerons ci-dessous, mais nous pouvons maintenant vous rappeler le procès de plusieurs millions de dollars contre IBM. Ce procès a été intenté par une grande maison d'édition, insatisfaite de la qualité du VT et du logiciel. IBM a gagné le procès. Et elle n'a gagné que parce qu'elle a présenté les termes de référence signés par les deux parties. Cela s'est produit il y a longtemps, dans les années 70, mais cela ne change rien au fond du problème.

Encore une chose. Il est important de créer le premier package PD. Cela suffira pour construire tous les suivants sur cette base, en l'utilisant comme modèle ou gabarit. Mais cela doit être fait de manière très efficace. Tranquille. Très minutieux.

Vous devez d’abord vous armer de GOST. GOST définit tout. Il inclut notamment le Système unifié de documentation des programmes (USPD) qui nous intéresse. Le plus difficile est peut-être d'obtenir le GOST lui-même. GOST ne doit être présenté que sous sa forme originale imprimée. Ils sont vendus (du moins c'était le cas avant) dans des magasins spécialisés. Notamment, pour acquérir des normes dans le domaine de la documentation, vous pouvez vous adresser aux organismes suivants :

• IPK "Normes d'édition", Département territorial de distribution de NTD (magasin "Normes"), 17961, Moscou, st. Donskaya, 8, tél. 236-50-34, 237-00-02, fax/tél. 236-34-48 (concernant GOST et GOST R).
• VNIIKI Gosstandart de Russie (salle de lecture), 103001, Moscou, Granatny per. 4, tél. 290-50-94 (concernant les normes internationales, étrangères et autres documentations scientifiques et techniques).

Et pas de citations ni de sources secondaires. GOST est la loi. Et plus encore, pas d'Internet (imaginez un tribunal prononçant une sentence à l'aide d'un imprimé du Code criminel téléchargé à partir d'un site Web). Ne faites confiance à personne d'autre qu'à l'original. Cependant, l’auteur devra alors recourir à la citation du DUME, renonçant ainsi à toute responsabilité.

Commençons par les dispositions générales concernant le système unifié de documentation du programme (qui sont également définies dans la norme correspondante GOST 19.001-77).

Le système unifié de documentation des programmes est un ensemble de normes nationales qui établissent des règles interconnectées pour le développement, l'exécution et la circulation des programmes et de la documentation des programmes.

Les normes DUME définissent les dispositions générales et les normes fondamentales, les règles d'exécution de la documentation de développement, les règles d'exécution de la documentation de fabrication, les règles d'exécution de la documentation de support, les règles d'exécution de la documentation opérationnelle, les règles de circulation de la documentation de programme et d'autres normes. . Le DUME comprend :

• normes fondamentales, organisationnelles et méthodologiques ;
• des normes définissant les formes et le contenu des documents de programme utilisés dans le traitement des données ;
• des normes qui assurent l'automatisation de l'élaboration des documents de programme.

En général, la liste des documents DUME est très longue. Il comprend notamment les GOST suivants :

• GOST 19.001-77 DUME. Dispositions générales.
• GOST 19.101-77 DUME. Types de programmes et documents de programme (réédité en novembre 1987 avec des modifications).
• GOST 19.102-77 DUME. Étapes de développement.
• GOST 19.103-77 DUME. Désignation des programmes et documents de programme.
• GOST 19.104-78 DUME. Inscriptions de base.
• GOST 19.105-78 DUME. Exigences générales pour les documents du programme.
• GOST 19.106-78 DUME. Exigences relatives aux documents imprimés du programme.
• GOST 19.201-78 DUME. Tâche technique. Exigences en matière de contenu et de conception.
• GOST 19.202-78 DUME. Spécification. Exigences en matière de contenu et de conception.
• GOST 19.301-79 DUME. Programme et méthodologie de tests.
• GOST 19.401-78 DUME. Texte du programme. Exigences en matière de contenu et de conception.
• GOST 19.402-78 DUME. Description du programme.
• GOST 19.404-79 DUME. Note explicative. Exigences en matière de contenu et de conception.
• GOST 19.501-78 DUME. Formulaire. Exigences en matière de contenu et de conception.
• GOST 19.502-78 DUME. Description de la demande. Exigences en matière de contenu et de conception.
• GOST 19.503-79 DUME. Guide du programmeur système. Exigences en matière de contenu et de conception.
• GOST 19.504-79 DUME. Guide du programmeur.
• GOST 19.505-79 DUME. Manuel de l'opérateur.
• GOST 19.506-79 DUME. Description de la langue.
• GOST 19.508-79 DUME. Manuel de maintenance. Exigences en matière de contenu et de conception.
• GOST 19.604-78 DUME. Règles pour apporter des modifications aux documents du programme exécutés sous forme imprimée.
• GOST 19.701-90 DUME. Schémas d'algorithmes, de programmes, de données et de systèmes. Conventions et règles d'exécution.
• GOST 19.781-90. Logiciels pour systèmes de traitement de l'information.

Comme vous pouvez le constater, l’essentiel du complexe ESPD a été développé dans les années 70 et 80. Certaines de ces normes sont dépassées et ne sont pas sans inconvénients. Premièrement, elles ne reflètent pas certaines tendances modernes dans la conception de programmes et de documentation de programme, et deuxièmement, ces normes contiennent de multiples duplications de fragments de documentation de programme. Néanmoins, faute de mieux, il faut se concentrer sur eux.

Ainsi, les normes DUME rationalisent le processus de documentation des systèmes logiciels. Cependant, d'une part, la composition des documents de programme prévue par les normes DUME n'est pas du tout aussi « rigide » qu'il y paraît : les normes permettent d'ajouter des types supplémentaires à l'ensemble de la documentation d'un système logiciel (PS), et , deuxièmement, en fonction des exigences des clients, certains changements dans la structure et le contenu des types de PD établis sont acceptables. Par ailleurs, on peut noter que les normes DUME (et cela s'applique à toutes les autres normes dans le domaine PS - GOST 34, la norme internationale ISO/IEC, etc.) ont un caractère consultatif. Le fait est que conformément à la loi de la Fédération de Russie « sur la normalisation », ces normes deviennent obligatoires sur une base contractuelle - c'est-à-dire en y faisant référence dans le contrat de développement (fourniture) du logiciel.

Avant de commencer à considérer les règles de compilation de la documentation logicielle, il est nécessaire de faire la remarque suivante. Il est conseillé de faire précéder chaque document d’une introduction. L'introduction parle de manière générale. Sur la pertinence, la nécessité, etc. Le but du Performer est ici de montrer l’importance et la nécessité de faire ce travail. Le début est généralement classique : « Les nombreux systèmes existants... ... ouvrent de réelles perspectives dans... », etc. Des citations des discours de diverses personnalités sont généralement insérées ici (il s'agit d'un aspect purement psychologique) : "... comme cela a été dit lors du dernier plénum, ​​congrès, conférence, etc.). Vous pouvez commencer par le fait que ".. " Aujourd'hui, à l'ère des transformations socio-économiques indigènes... etc. " En général, l'essentiel ici est de ne pas en faire trop.

Et plus loin. Lorsqu'il décrit son produit, le développeur confond souvent les notions de composant et de complexe. Ce sont différents types de programmes. Un composant est défini comme « un programme considéré comme un tout unique, remplissant une fonction complète et utilisé indépendamment ou dans le cadre d'un complexe », et un complexe est « un programme composé de deux ou plusieurs composants et (ou) complexes qui exécutent des tâches interdépendantes ». fonctions et est utilisé indépendamment ou dans le cadre d'un autre complexe.

Selon GOST, cette norme (rééditée en novembre 1987) établit la procédure de construction et de préparation de spécifications techniques pour le développement d'un programme ou d'un produit logiciel pour ordinateurs, complexes et systèmes, quels que soient leur objectif et leur portée.

Vous devez être extrêmement prudent et prudent lors de sa création, car... Souvent, une spécification technique rédigée avec habileté (et compétence) détermine le succès de l’ensemble du travail. Ce sont les spécifications techniques qui sont convenues avec le Client, qui s'efforce généralement d'introduire autant d'exigences contradictoires et exagérées que possible. La tâche de l'exécuteur testamentaire est, au contraire, de lui faciliter la vie. Mais une fois les signatures déposées des deux côtés, il est trop tard pour rejouer quoi que ce soit.

Les termes de référence sont rédigés sur des feuilles au format A4 et/ou A3, en règle générale, sans remplir les champs de la feuille. Les numéros de feuille (page) sont placés en haut de la feuille, au-dessus du texte.

Pour apporter des modifications et des ajouts au contexte technique lors des étapes ultérieures du développement d'un programme ou d'un produit logiciel, un ajout à celui-ci est publié. La coordination et l'approbation des ajouts aux spécifications techniques s'effectuent de la même manière que celle établie pour les spécifications techniques.

Les termes de référence doivent contenir les sections suivantes :

• nom et champ d'application ;
• base de développement;
• but du développement;
• les exigences techniques pour un programme ou un produit logiciel ;
• étapes et stades de développement;
• procédure de contrôle et de réception ;
• applications.

Selon les caractéristiques du programme ou du produit logiciel, il est possible de clarifier le contenu des sections, d'introduire de nouvelles sections ou d'en combiner des individuelles.

Au chapitre Nom et portée indiquer le nom, une brève description du champ d'application du programme ou du produit logiciel et l'objet dans lequel le programme ou le produit logiciel est utilisé.

Au chapitre Base de développement doit être indiqué :

• document(s) sur la base duquel le développement est réalisé ;
• l'organisme qui a approuvé ce document et la date de son approbation ;
• nom et (ou) symbole du sujet de développement.

En ce qui concerne les spécificités du processus éducatif, la base peut être une mission de conception de cours, une commande de l'institut en date du __.__. pour N ___., contrat __.__. pour N ___. , et ainsi de suite.

Au chapitre Objectif du développement L'objectif fonctionnel et opérationnel du programme ou du produit logiciel doit être indiqué. Vous pouvez vous limiter ici à une ou deux phrases. L'essentiel est de définir clairement à quoi sert ce programme.

Par exemple : Le programme est le cœur d'un poste de travail automatisé (AWS) pour le développeur de systèmes de contrôle automatique linéaire continu (ACS), permettant à l'utilisateur de résoudre des problèmes d'analyse de modèles simples.

Chapitre Exigences techniques pour un programme ou un produit logiciel doit contenir les sous-sections suivantes :

• exigences relatives aux caractéristiques fonctionnelles ;
• exigences de fiabilité ;
• conditions d'utilisation;
• exigences relatives à la composition et aux paramètres des moyens techniques ;
• exigences en matière d'informations et de compatibilité logicielle ;
• les exigences en matière d'étiquetage et d'emballage ;
• les exigences en matière de transport et de stockage ;
• besoins spéciaux.

En d’autres termes, c’est là que commencent les détails. Décrit ce que le programme doit faire et à quoi il doit ressembler.

Exigences relatives aux caractéristiques fonctionnelles. Ici, les exigences relatives à la composition des fonctions exercées, à l'organisation des données d'entrée et de sortie, aux caractéristiques temporelles, etc. doivent être indiquées.

Par exemple : Le programme doit permettre... de calculer... de construire... de créer...

Données d'entrée : fichier texte avec les données...

Données de sortie : informations graphiques et textuelles - résultats de l'analyse du système... ; fichiers texte - rapports sur ... les diagnostics de l'état du système et des messages sur toutes les erreurs survenues.

Exigences de fiabilité. Les exigences permettant d'assurer un fonctionnement fiable doivent être précisées (garantir un fonctionnement stable, surveiller les informations d'entrée et de sortie, temps de récupération après une panne, etc.).

Il est difficile de « deviner » quelque chose ici. Dans le meilleur des cas, votre programme ne fonctionne qu’avec des données absolument correctes. Habituellement, le client n'est pas d'accord avec cela, mais vous pouvez essayer.

Par exemple : Le programme doit fonctionner avec une matrice étendue donnée d'incidents du graphique étudié conformément à l'algorithme de fonctionnement, générer des messages d'erreur lorsque les données initiales sont incorrectement spécifiées et prendre en charge un mode interactif dans les limites des capacités fournies à l'utilisateur.

Conditions d'utilisation. Les conditions d'exploitation (température ambiante, humidité relative, etc. pour certains types de supports de stockage) dans lesquelles les caractéristiques spécifiées doivent être assurées, ainsi que le type de service, le nombre requis et les qualifications du personnel doivent être indiqués.

Il n'y a généralement aucune difficulté sur ce point. Malheureusement, la clause sur le professionnalisme de l'utilisateur par le Client est nécessairement implicite. Ceci, bien sûr, est une autre raison de critiquer votre programme. Cependant, nous pouvons ici nous limiter à des expressions telles que "Les conditions de fonctionnement du programme coïncident avec les conditions de fonctionnement du PC IBM et des PC compatibles", "Le programme doit être conçu pour un utilisateur non professionnel". et ainsi de suite.

Exigences relatives à la composition et aux paramètres des moyens techniques. Indiquer la composition requise des moyens techniques avec une indication de leurs caractéristiques techniques.

L'essentiel ici est de ne rien oublier et de tout prévoir, d'une part (sinon ils glisseront une sorte d'IBM PC/XT avec un écran monochrome et sans souris), et d'autre part, de ne pas faites-en trop avec des exigences accrues, sinon le client trouvera un entrepreneur plus flexible.

Par exemple : Vous devez disposer d'un PC compatible IBM PC avec un adaptateur graphique EGA (VGA). L'espace disque requis est d'au moins 600 Ko, la quantité de RAM libre est d'au moins 400 Ko. Il est souhaitable de disposer d'un pilote EMS et d'un manipulateur de type souris.

Exigences en matière d'informations et de compatibilité logicielle. Les fonctionnalités sont les mêmes que dans le paragraphe précédent. Ici, les exigences relatives aux structures d'information au niveau des entrées et des sorties, ainsi que les méthodes de solution, les codes sources et les langages de programmation doivent être spécifiées. Si nécessaire, la protection des informations et des programmes doit être assurée.

Par exemple : Le programme doit fonctionner de manière autonome sous la version du système d'exploitation MS DOS non inférieure à 3.3. Le langage de programmation de base est Turbo Pascal 6.0.

Les exigences en matière d’étiquetage et d’emballage ainsi que les exigences en matière de transport et de stockage sont assez exotiques. En général, cela indique les exigences relatives à l'étiquetage d'un produit logiciel, aux options et méthodes de packaging. Et les exigences en matière de transport et de stockage doivent indiquer pour le produit logiciel les conditions de transport, les emplacements de stockage, les conditions de stockage, les conditions de stockage, les périodes de stockage dans diverses conditions.

Les exigences particulières sont une chose très importante. Il vaut mieux les éviter si possible. Et déclarez-le tout de suite.

Par exemple : Il n'y a pas d'exigences particulières concernant les caractéristiques temporelles du programme. Il n'y a pas d'exigences particulières concernant les caractéristiques capacitives du programme.

Indicateurs techniques et économiques. Ce point le plus difficile pour un programmeur n’existe pas toujours. Cela est principalement nécessaire lorsque votre objectif est de justifier l'énorme efficacité et l'importance du travail effectué. Cet article fonctionne généralement très bien pour le client. C’est à tout le moins la meilleure justification du calendrier et des montants financiers du développement.

Cette section doit indiquer : l'efficacité économique estimée, les besoins annuels estimés (par exemple : le nombre prévu d'appels au complexe dans son ensemble par an - 365 séances de travail), les avantages économiques du développement par rapport aux meilleurs échantillons nationaux et étrangers ou analogues.

En outre, il est conseillé de fournir une définition à la fois du coût estimé du développement du programme et de la complexité de la programmation.

Étapes et étapes de développement(cela sera discuté plus en détail ci-dessous) établir les étapes de développement, les étapes et le contenu du travail nécessaires (une liste de documents de programme qui doivent être élaborés, convenus et approuvés), ainsi que, en règle générale, les délais de développement et déterminer les interprètes.

Les étapes standard sont décrites ici. L'essentiel est de déterminer correctement le timing. Si possible, essayez de répartir uniformément les étapes selon les délais (et les montants). N'oubliez pas que tous les projets n'atteignent pas la phase finale. Et il devrait y avoir des rapports pour chaque étape. N'oubliez pas non plus que le projet de travail prendra le plus de temps. Si vous ne complétez pas la documentation à temps, le client a le droit de ne pas accepter les travaux avec toutes les conséquences qui en découlent.

Les étapes et phases principales et indispensables sont les termes de référence eux-mêmes, la conception préliminaire, les conceptions techniques et de travail.

• Conception preliminaire. À ce stade, les structures des données d'entrée et de sortie sont développées en détail et la forme de leur présentation est déterminée. Une description générale de l'algorithme, de l'algorithme lui-même et de la structure du programme est en cours d'élaboration. Un plan d'action pour le développement et la mise en œuvre du programme est en cours d'élaboration.
• Projet technique. Contient un algorithme développé pour résoudre le problème ainsi que des méthodes de suivi des informations initiales. Ici, des outils de traitement des erreurs et d'émission de messages de diagnostic sont développés, des formulaires de présentation des données initiales et la configuration des équipements techniques sont déterminés.
• Document de travail. A ce stade, la programmation et le débogage du programme, le développement des documents de programme, des programmes et des méthodes de test sont effectués. Des exemples de tests et de débogage sont en cours de préparation. La documentation et le matériel graphique sont finalisés. Il est généralement précisé que lors du développement du programme, la documentation suivante doit être préparée :

• texte du programme ;
• Description du programme;
• programme et méthodologie de test ;
• description de la demande ;
• mode d'emploi.

Ce sont des exigences standard. Si le Client accepte que toute cette liste ne puisse pas être présentée, cela signifie que ses intentions envers vous et votre produit ne sont pas sérieuses.

Il ne peut y avoir aucun élément graphique. Surtout quand vous n'allez pas rendre compte des résultats de votre travail. Mais pour les projets sérieux, cet élément est obligatoire.

Par exemple : Lors du développement du programme, le matériel graphique suivant doit être préparé :

• indicateurs techniques et économiques;
• structure du programme ;
• format de présentation des données d'entrée du programme ;
• diagramme d'algorithme général (2 feuilles);
• algorithmes informatiques de base ;
• exemple du fonctionnement du programme.

Au chapitre Procédure de contrôle et de réception les types d'essais et les exigences générales pour la réception des travaux doivent être indiqués. Si possible, indiquez dans ce paragraphe que « le contrôle et la réception du développement s'effectuent à l'aide du matériel fourni par le Client », faute de quoi vous pourrez être amené à apporter le matériel avec vous.

Par exemple : Le contrôle et la réception du développement sont effectués sur la base d'exemples de tests et de débogage. Cela vérifie l'exécution de toutes les fonctions du programme.

DANS Applications Le cas échéant, les spécifications techniques sont fournies par :

• une liste des recherches et autres travaux justifiant le développement ;
• diagrammes d'algorithmes, tableaux, descriptions, justifications, calculs et autres documents pouvant être utilisés lors du développement ;

• d'autres sources de développement.

Cette norme établit les étapes de développement des programmes, la documentation des programmes, ainsi que les étapes et le contenu des travaux :

Étapes de développement	Étapes de travail
Tâche technique	Justification de la nécessité de développer le programme	Formulation du problème. Collection de matériaux sources. Sélection et justification des critères d'efficacité et de qualité du programme développé. Justification de la nécessité de travaux de recherche.
	Travail de recherche	Déterminer la structure des données d'entrée et de sortie. Sélection préliminaire de méthodes de résolution de problèmes. Justification de la faisabilité de l'utilisation de programmes développés précédemment. Détermination des besoins en moyens techniques. Justification de la possibilité fondamentale de résoudre le problème.
	Élaboration et approbation des spécifications techniques	Déterminer les exigences du programme. Élaboration d'une étude de faisabilité pour le développement du programme. Détermination des étapes, des étapes et du calendrier de développement du programme et de la documentation correspondante. Choix des langages de programmation. Déterminer la nécessité de travaux de recherche aux étapes ultérieures. Coordination et approbation des spécifications techniques.
Conception preliminaire	Élaboration d'un avant-projet	Développement préliminaire de la structure des données d'entrée et de sortie. Clarification des méthodes pour résoudre le problème. Développement d'une description générale de l'algorithme de résolution du problème. Élaboration d'une étude de faisabilité.
	Approbation de l’avant-projet	Coordination et approbation de l'avant-projet
Projet technique	Développement de projet technique	Clarification de la structure des données d'entrée et de sortie. Développement d'un algorithme pour résoudre le problème. Déterminer la forme de présentation des données d'entrée et de sortie. Définition de la sémantique et de la syntaxe du langage. Développement de la structure du programme. Détermination finale de la configuration matérielle.
	Approbation de la conception technique	Élaboration d'un plan d'action pour l'élaboration et la mise en œuvre de programmes. Élaboration d'une note explicative. Coordination et approbation de la conception technique.
Document de travail	Développement de programme	Programmation et débogage
	Développement de la documentation du logiciel	Élaboration de documents de programme conformément aux exigences de GOST 19.101-77.
	Test du programme	Développement, coordination et approbation du programme et de la méthodologie de tests. Réalisation de tests d'état préliminaires, interministériels, d'acceptation et autres types. Correction du programme et de la documentation du programme en fonction des résultats des tests.
Mise en œuvre	Préparation et transmission du programme	Préparation et transfert de programmes et de documentation logicielle pour la maintenance et (ou) la production. Enregistrement et approbation de l'acte de transfert du programme pour maintenance et (ou) production. Transfert du programme au fonds d'algorithmes et de programmes.

Remarques:

1. Il est permis d'exclure la deuxième étape du développement et, dans les cas techniquement justifiés, les deuxième et troisième étapes. La nécessité de ces étapes est indiquée dans les spécifications techniques.
2. Il est permis de combiner, d'exclure des étapes de travail et (ou) leur contenu, ainsi que d'introduire d'autres étapes de travail comme convenu avec le client.

Cette norme se concentre sur la documentation du produit de développement résultant.

À proprement parler, il existe deux documents différents, qui ont cependant de nombreux points communs. Il s'agit d'une DESCRIPTION GÉNÉRALE (GOST 19.502-78) et d'une DESCRIPTION DU PROGRAMME (GOST 19.402-78). Cependant, étant donné qu'il est très difficile de créer les deux avec une haute qualité, sans recourir à une duplication presque complète et à l'arrachage de morceaux, il suffirait de mettre en œuvre un document « hybride » plus général. Appelons-le « Description du programme ».

En effet, la « Description du programme » dans son contenu peut être complétée par des sections et paragraphes tirés des normes d'autres documents et manuels descriptifs : GOST 19.404-79 ESPD. Note explicative, GOST 19.503-79 ESPD. Guide du programmeur système, GOST 19.504-79 ESPD. Guide du programmeur, GOST 19.505-79 ESPD. Manuel de l'opérateur, etc. En particulier, à partir de la note explicative, vous pouvez tirer un schéma de l'algorithme, une description générale de l'algorithme et (ou) du fonctionnement du programme, ainsi que la justification des décisions techniques et technico-économiques adoptées.

La description du programme doit inclure une partie informative - annotation et contenu.

La partie principale du document doit comprendre une partie introductive et les sections suivantes :

• objectif fonctionnel;
• description de la logique.
• conditions d'utilisation;
• composition et fonctions.

Selon les spécificités du programme, des sections supplémentaires peuvent être introduites.

DANS Partie introductive Le document fournit des informations générales sur le programme - nom complet, désignation, ses applications possibles, etc.

Par exemple : Le programme « Poste de travail automatisé pour développeur de canons automoteurs » est destiné à... mis en œuvre sur.... Le programme prend en charge...

Au chapitre But indiquer l'objectif du programme et fournir une description générale du fonctionnement du programme, ses principales caractéristiques, des informations sur les restrictions imposées sur la portée du programme, et indiquer également les types d'ordinateurs et d'appareils électroniques utilisés pendant le fonctionnement.

Par exemple : Le programme est conçu pour résoudre des problèmes... Le programme représente le cœur d'un poste de travail automatisé...

L'utilisateur a la possibilité de..., mettre en œuvre..., exécuter..., analyser..., obtenir des résultats d'analyse et de traitement..., construire..., etc.

Au chapitre " Description de la logique" indiquer:

• description de la structure du programme et de ses principales parties

(par exemple : Le programme comprend les éléments suivants :

• interface utilisateur,
• module de détermination de chemins dans un graphe,
• module de calcul de fonction de transfert,
• module de construction des caractéristiques d'amplitude et de fréquence de phase,
• module de construction d'une réponse à une influence polynomiale,
• éditeur de texte) .

• description des fonctions des composants et des connexions entre eux ;

Par exemple : Le programme se compose de six modules : module d'interface ; module de définition... ; module de calcul... ; module...etc..

Le module d'interface est construit sur deux types de dialogues : un dialogue question-réponse et un dialogue de type menu. Le module d'interface contrôle...

Module de définition... C'est...

Module de calcul...etc.

• des informations sur le langage de programmation ;

Par exemple : Le programme est écrit dans le langage... à l'aide d'un compilateur...

• description des données d'entrée et de sortie pour chacun des composants ;

Par exemple : SAISIR DES DONNÉES. Les données d'entrée du programme sont un fichier texte décrivant la matrice d'incidence étendue du graphique du système étudié.

SORTIR. Le résultat est :

• informations graphiques et textuelles affichées à l'écran (résultats de l'analyse du système) ;
• fichiers dans l'un des formats graphiques - copies de l'image des caractéristiques construites (réponse en fréquence, réponse en phase, etc.) ;
• fichiers texte - rapports sur les recherches menées ;
• diagnostics de l'état du système et messages sur toutes les erreurs qui se produisent.

• description de la logique des composants (si nécessaire, une description des schémas du programme doit être rédigée).

Lors de la description de la logique du programme, un lien vers le texte du programme est nécessaire.

Au chapitre Composition et fonctions indiquer une description de la composition et de la fonction des programmes ainsi que des méthodes utilisées pour résoudre les problèmes.

Au chapitre Conditions d'utilisation les conditions nécessaires à la mise en œuvre du programme sont indiquées (exigences relatives aux moyens techniques nécessaires à ce programme et à d'autres programmes, caractéristiques générales des informations d'entrée et de sortie, ainsi que exigences et conditions d'ordre organisationnel, technique et technologique, etc. ).

Par exemple : Le programme fonctionne sur un ordinateur personnel (PC) de type IBM PC/AT. Pour travailler en mode interactif, un écran d'affichage, un clavier et une souris sont utilisés. Pour prendre en charge le mode graphique, un adaptateur EGA (VGA) est requis. Les données d'entrée sont stockées sur des disquettes et/ou des disques durs. Le programme fonctionne sous le système d'exploitation...

L'annexe à la description peut comprendre des éléments de référence (illustrations, tableaux, graphiques, exemples, etc.)

Et n'oubliez pas d'indiquer le nom du module de chargement, ainsi qu'une description de l'ensemble de la procédure

Appeler et démarrer le système

Les exigences relatives à la conception du texte du programme sont assez simples et naturelles pour un programmeur compétent. La principale chose à prendre en compte lors de la création de ce document est que le texte du programme doit être lisible.

Il est toujours obligatoire de compiler la partie informationnelle – annotations et contenu.

La partie principale du document doit être constituée des textes d'une ou plusieurs sections, auxquelles sont attribués des noms.

Le texte de chaque fichier programme commence par un « en-tête » qui indique :

• nom du programme,
• auteur,
• date de création du programme,
• numéro de version,
• date de la dernière modification.

Des commentaires sont requis, ainsi qu'un strict respect des règles d'indentation. N'oubliez pas que même l'incapacité de créer une documentation logicielle peut être justifiée. Mais un texte de programme laid - jamais. Les références au fait que ce texte est compréhensible pour l'auteur lui-même ne sont pas prises au sérieux. Il ne devrait y avoir aucune honte à donner des textes de programmes à d’autres personnes pour qu’ils les lisent.

Vous trouverez ci-dessous un exemple d'un texte de programme aussi lisible (tiré du site Web de Nikolai Gekht, e-mail : [email protégé], http://users.omskreg.ru/~geht)

/* Sources Windows 98

Code source pour Windows 98 */ #inclut "win31.h" #inclut "win95.h" #inclut "evenmore.h" #inclut "oldstuff.h" #inclut "billrulz.h" #inclut "monopoly.h" # définir INSTALL = HARD char make_prog_look_big; void main() ( while(!CRASHED) ( display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) ( make_50_megabyte_swapfile(); do_nothing_loop();totalement_screw_up_HPFS_file_system(); search_and_destroy_the_rest_of_OS/2();disable_Netscape(); désactiver_RealPlayer(); désactiver_Corel_Products(); hang_system(); ) write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(still_not_crashed) ( display_copyright_message(); do_nothing_loop(); basic_run_windows_3.1(); do_nothing_loop (); do_nothing_loop(); ) ) if(detect_cache()) Disable_cache(); if(fast_cpu()) ( set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(réaction, parfois ); ) /* printf("Bienvenue dans Windows 3.11"); */ /* printf("Bienvenue dans Windows 95"); */ printf("Bienvenue dans Windows 98"); if(system_ok()) crash(to_dos_prompt ) else system_memory = open("a:\swp0001.swp", O_CREATE); while(quelque chose) ( sleep(5); get_user_input(); dormir(5); act_on_user_input(); dormir(5); ) create_general_protection_fault();

Ce document contient une description de ce qui doit être fait et comment pour s'assurer (et convaincre le client) que le programme fonctionne correctement. En effet, ce document est déterminant pour les tests de réception. Un programme et une méthodologie de test bien conçus sont la clé pour signer le certificat d'acceptation, c'est-à-dire la chose pour laquelle vous avez consacré tant d'efforts et de temps.

Formellement, ce GOST est utilisé pour élaborer des documents de planification et effectuer des travaux de test pour évaluer l'état de préparation et la qualité du système logiciel. Le document contient une description de l'objet et du but du test, des exigences relatives au programme et à la documentation du logiciel, des moyens et de la procédure de test, ainsi qu'une description des exemples de test.

Les composants de ce document sont plus simples et plus clairement décrits sous forme d'exemples.

Objet de test

Exemple : L'objet de test est le programme..., destiné à...

Objectif du test

Exemple : Vérification de la fiabilité du programme.

Exigences du programme

Exemple : Le fonctionnement du programme ne doit pas conduire à une panne (perturbation fatale du système). L'organisation du dialogue doit assurer une protection contre la saisie de données incorrectes. Le programme doit fournir des diagnostics de l'état du système et des messages sur les erreurs survenues... etc.

Conditions requises pour la documentation du logiciel

Exemple : Contenu de la documentation du logiciel présentée lors des tests :

• description du programme (GOST 19.402-78);
• programme et méthodologie de test (GOST 19.301-79);
• texte du programme (GOST 19.401-78).

Moyens et procédure de test

Exemple : Le programme fonctionne conformément aux conditions de fonctionnement du système d'exploitation MS DOS (version non inférieure à 3.0) sur un PC tel qu'IBM PC/AT, ainsi que sur des PC compatibles. Un adaptateur EGA (VGA) est également requis pour le fonctionnement.

Procédure de test:

1. Le programme est lancé….
2. Choisi...
3. Pressé...
4. Sélection séquentielle...

Cas de tests

Exemple : Pour les tests,... sont proposés dont les descriptions sont contenues dans les fichiers... Le contenu des fichiers de tests et les résultats du programme sont donnés en Annexe 1.

Et enfin, regardons la dernière norme DUME, appelée

Cette norme établit les règles d'exécution des documents de programme pour les ordinateurs, complexes et systèmes, quels que soient leur objet et leur champ d'application et prévus par les normes DUME.

Exigences générales. Il est nécessaire de saisir des mots individuels, des formules, des symboles (à la main dans une police de dessin), des lettres des alphabets latin et grec, ainsi que de dessiner des diagrammes et des dessins dans les documents de programme réalisés par dactylographie, machine et écriture manuscrite, à l'encre noire. ou de l'encre.

Les fautes de frappe et les inexactitudes graphiques découvertes lors du processus d'exécution peuvent être corrigées en effaçant une partie du texte mal exécutée (dessin) et en appliquant le texte corrigé (graphique) sur la même feuille à la machine ou à l'encre noire, selon la méthode d'exécution du document.

Les dommages aux feuilles de documents, les taches et les traces de texte (graphiques) incomplètement supprimés ne sont pas autorisés.

Les documents du programme sont rédigés sur des feuilles A4. En plus:

• Il est acceptable d'imprimer sur des feuilles A3 ;
• avec la méthode machine d'exécution des documents, des écarts de format des feuilles correspondant aux formats A4 et A3 sont autorisés, déterminés par les capacités des moyens techniques utilisés ; sur des feuilles aux formats A4 et A3, prévues par les caractéristiques de sortie des dispositifs de sortie de données, lors de la production d'un document par machine ;
• Lors de la réalisation d'un document par méthode typographique, il est possible d'utiliser des feuilles de formats typographiques.

Les éléments du document de programme sont classés dans l'ordre suivant :

• partie titre :

• feuille d'approbation (non incluse dans le nombre total de feuilles du document);
• page de titre (première page du document);

• partie information :

• annotation;
• table des matières;

• partie principale:

• texte du document (avec images, tableaux, etc.) ;
• liste de termes et leurs définitions ;
• Liste des abréviations;
• applications;
• index des sujets;
• liste des documents de référence ;

• modifier la partie de journalisation :

• modifier la fiche d'inscription.

Construction du document. Si nécessaire, il est permis de diviser le document en parties. La division en parties est effectuée à un niveau non inférieur à la section. Chaque partie est complétée séparément et à la fin du contenu de la première partie, les noms des parties restantes doivent être répertoriés.

Il est permis d'inclure dans le document des parties du texte du programme, formatées conformément aux règles de la langue dans laquelle le texte du programme est rédigé.

Le résumé est placé sur une ou plusieurs pages séparées, munies du titre « RÉSUMÉ », numérotées et incluses dans le contenu du document.

Le texte de chaque document, si nécessaire, est divisé en paragraphes et les paragraphes en sous-paragraphes, que le document soit divisé ou non en parties, sections et sous-sections.

Les titres de section sont écrits en majuscules et placés symétriquement par rapport aux bordures droite et gauche du texte. Les titres de sous-sections sont écrits à partir du paragraphe en lettres minuscules (à l'exception de la première majuscule). La césure des mots dans les titres n'est pas autorisée. Il n'y a pas de point à la fin du titre. Il est recommandé de commencer chaque section sur une nouvelle feuille.

Les sections, sous-sections, paragraphes et sous-paragraphes doivent être numérotés en chiffres arabes avec un point. Les sections doivent avoir un numéro de série (1, 2, etc.)

Texte du document. Le texte du document doit être court, clair, excluant toute possibilité de mauvaise interprétation. Les termes et définitions doivent être uniformes et conformes aux normes établies, et en leur absence, généralement acceptés dans la littérature scientifique et technique, et être indiqués dans la liste des termes.

Les explications nécessaires au texte du document peuvent être fournies dans les notes de bas de page. Une note de bas de page est indiquée par un chiffre entouré d'une parenthèse placé au niveau du bord supérieur de la police.

Si une note de bas de page fait référence à un seul mot, le signe de note de bas de page est placé directement à côté de ce mot, mais s'il fait référence à une phrase dans son ensemble, alors à la fin de la phrase. Le texte de la note de bas de page est placé en fin de page et séparé du texte principal par une ligne de 3 cm de long tracée sur le côté gauche de la page.

Illustrations. Les illustrations peuvent être situées dans le texte du document et (ou) en annexes. Les illustrations, s'il y en a plusieurs dans un document donné, sont numérotées en chiffres arabes sur l'ensemble du document.

Dans les annexes, les illustrations sont numérotées au sein de chaque annexe dans l'ordre établi pour le texte principal du document. Les références aux illustrations sont données par type : « Fig. 12 » ou « (Fig. 12) ». Les illustrations peuvent avoir un titre thématique et un texte de légende expliquant le contenu de l’illustration.

Formules. Les formules d'un document, s'il y en a plusieurs, sont numérotées en chiffres arabes ; le numéro est placé sur le côté droit de la page, entre parenthèses au niveau de la formule. Dans l'ensemble du document ou dans ses parties, si le document est divisé en parties, les formules ont une numérotation continue.

Les références dans le texte au numéro d'ordre de la formule sont données entre parenthèses, par exemple : « dans la formule (3) ». Lors de la division d'un document en parties, le numéro de pièce est placé avant le numéro d'ordre de la formule et est séparé du dernier point, par exemple : « dans la formule (1.4) ».

La signification des symboles inclus dans la formule doit être indiquée directement sous la formule. La signification de chaque caractère est imprimée sur une nouvelle ligne dans l'ordre dans lequel ils sont donnés dans la formule. La première ligne de la transcription doit commencer par le mot « où », sans deux points après.

Liens. Les références aux normes et autres documents sont autorisées dans les documents de politique. Il convient de faire référence au document dans son ensemble ou à ses sections (en indiquant la désignation et le nom du document, le numéro et le nom de la section ou de l'annexe).

Il est permis d'indiquer uniquement la désignation du document et (ou) des sections sans indiquer leurs noms. Les références à des sous-sections, paragraphes et illustrations individuels d’un autre document ne sont pas autorisées. Les liens dans le document vers des paragraphes, des illustrations et des sous-sections individuelles sont autorisés.

Remarques Les notes du texte et des tableaux indiquent uniquement des données de référence et explicatives. Un billet n'est pas numéroté. Après le mot « Note », mettez un point. Plusieurs notes doivent être numérotées dans l'ordre en utilisant des chiffres arabes avec un point. Après le mot « Note », mettez deux points. Le texte des notes ne peut être imprimé qu'à un seul intervalle.

Abréviations. Les abréviations de mots dans le texte et les inscriptions sous les illustrations ne sont pas autorisées, à l'exception de :

• abréviations établies dans GOST 2.316-68 et généralement acceptées en langue russe ;
• abréviations utilisées pour désigner les programmes, leurs parties et modes de fonctionnement, dans les langages de contrôle de tâches, dans les outils de configuration de programmes, etc., désignées par des lettres de l'alphabet latin.

Applications. Du matériel illustré, des tableaux ou des textes justificatifs peuvent être présentés sous forme d’annexes. Des annexes sont établies dans la continuité de ce document sur les pages suivantes ou émises sous forme de document séparé.

Chaque candidature doit commencer sur une nouvelle page avec le mot « Candidature » dans le coin supérieur droit et avoir un en-tête thématique. S'il y a plus d'une pièce jointe dans un document, toutes les pièces jointes sont numérotées en chiffres arabes (sans le signe non), par exemple :

Annexe 1, Annexe 2, etc.

Lors de la délivrance d'une demande sous forme de document séparé, le mot « Annexe » doit être indiqué sur la page de titre sous le nom du document, et s'il y a plusieurs demandes, son numéro de série doit également être indiqué.

Lorsqu'un programmeur reçoit une tâche de développement d'un programme, lui, le chef de projet et toute l'équipe de projet sont confrontés aux questions suivantes :

• que faut-il faire à part le programme ?
• quelle documentation faut-il rédiger ?
• que transmettre aux utilisateurs, et quoi ? un service d'escorte ?
• comment gérer le processus de développement ?
• Que doit-on inclure dans les termes de référence ?

Outre les problèmes évoqués, il en existe bien d’autres.

Toutes ces questions ont déjà trouvé une réponse dans les normes de l'État pour la documentation du programme - un ensemble de normes de la 19e série de GOST ESPD. Mais même alors, les programmeurs avaient de nombreuses plaintes concernant ces normes. Certaines choses ont dû être dupliquées de manière injustifiée dans la documentation à plusieurs reprises, et de nombreuses choses n'ont pas été fournies, par exemple, reflétant les spécificités de la documentation des programmes qui fonctionnent avec une base de données.

À ce jour, la question de l'existence d'un système de normes régissant la documentation des programmes développés reste d'actualité.

2. Caractéristiques générales de la condition

La base du cadre réglementaire national dans le domaine de la documentation des programmes est un ensemble de normes du Système unifié de documentation des programmes (USPD). La majeure partie de ce complexe a été développée dans les années 70 et 80. À l'heure actuelle, ce complexe représente un système de normes interétatiques des pays de la CEI, opérant sur le territoire de la Fédération de Russie sur la base d'un accord interétatique de normalisation.

Les normes DUME couvrent la partie de la documentation créée au cours du processus de développement du programme et associée à la documentation des caractéristiques fonctionnelles. N'oubliez pas que les normes DUME (GOST 19) ont un caractère consultatif. Cependant, cela s'applique également à d'autres normes dans le domaine du développement de logiciels, telles que : GOST 34, la norme internationale ISO/IEC, etc. Conformément à la loi de la Fédération de Russie « sur la normalisation », ces normes ne deviennent obligatoires que sur une base contractuelle - c'est-à-dire sur référence à ceux-ci dans l'accord de développement du programme.

En ce qui concerne l’état du DUME dans son ensemble, on peut affirmer que la plupart des normes sont moralement dépassées.

Aux principaux inconvénients DUME peut être attribué:

• orientation vers un modèle unique, « en cascade », du cycle de vie du programme ;
• manque de recommandations claires pour documenter les caractéristiques de qualité ;
• manque de connexions avec d'autres systèmes de normes nationaux existants, par exemple ESKD ;
• approche mal exprimée pour documenter le programme en tant que produit commercial ;
• manque de recommandations pour la documentation interne, comme les menus à l'écran, l'aide pour travailler avec le programme, etc. ;
• manque de recommandations sur la composition, le contenu et l'exécution des documents du programme, conformes aux normes internationales et régionales.

Il s’ensuit que le DUME nécessite une révision complète basée sur la norme ISO/IEC 12207-95 (cette norme sera discutée plus en détail ci-dessous).

Il convient de noter qu'en plus du DUME, dans le cadre réglementaire officiel de la Fédération de Russie dans le domaine de la documentation des programmes et des domaines connexes, il existe un certain nombre de normes prometteuses, par exemple :

• standard international ISO/CEI 12207 : 1995-08-01 organiser le cycle de vie des produits logiciels.

• Des normes complexes GOST 34 pour la création et le développement de systèmes automatisés.

2.1. Brève description des normes DUME disponibles

Même malgré leurs lacunes, de nombreuses normes DUME peuvent être utilisées utilement pour documenter les programmes car :

• Les normes DUME introduisent un ordre caractéristique dans le processus de documentation des programmes ;
• La composition des documents du programme prévue par les normes DUME peut être modifiée en ajoutant des types de documents supplémentaires à l'ensemble documentaire.
• Les normes DUME vous permettent de modifier la structure et le contenu en fonction des exigences spécifiques du client et de l'utilisateur.

Dans le même temps, le client et le chef de projet sélectionnent le sous-ensemble approprié de normes et de documentation pour le projet, les complètent avec les sections nécessaires (excluent celles inutiles) et lient la création de ces documents au schéma utilisé dans le projet.

Les normes DUME sont divisées en groupes présentés dans le tableau :

La désignation de la norme DUME repose sur les critères de classification :

La désignation de la norme DUME doit être composée de :

• numéro 19 (attribué à la classe des normes DUME) ;
• un chiffre (après le point) indiquant le code du groupe de classification des normes spécifié dans le tableau ;
• un nombre à deux chiffres (après un tiret) indiquant l'année d'enregistrement de la norme.

Liste des documents DUME :

1. GOST 19.001-77 DUME. Dispositions générales.
2. GOST 19.101-77 DUME. Types de programmes et documents de programme.
3. GOST 19.102-77 DUME. Étapes de développement.
4. GOST 19.103-77 DUME. Désignation des programmes et documents de programme.
5. GOST 19.104-78 DUME. Inscriptions de base.
6. GOST 19.105-78 DUME. Exigences générales pour les documents du programme.
7. GOST 19.106-78 DUME. Exigences relatives aux documents imprimés du programme.
8. GOST 19.201-78 DUME. Tâche technique. Exigences en matière de contenu et de conception.
9. GOST 19.202-78 DUME. Spécification. Exigences en matière de contenu et de conception.
10. GOST 19.301-79 DUME. Procédure et méthodologie de test.
11. GOST 19.401-78 DUME. Texte du programme. Exigences en matière de contenu et de conception.
12. GOST 19.402-78 DUME. Description du programme.
13. GOST 19.404-79 DUME. Note explicative. Exigences en matière de contenu et de conception.
14. GOST 19.501-78 DUME. Formulaire. Exigences en matière de contenu et de conception.
15. GOST 19.502-78 DUME. Description de la demande. Exigences en matière de contenu et de conception.
16. GOST 19.503-79 DUME. Guide du programmeur système. Exigences en matière de contenu et de conception.
17. GOST 19.504-79 DUME. Guide du programmeur.
18. GOST 19.505-79 DUME. Manuel de l'opérateur.
19. GOST 19.506-79 DUME. Description de la langue.
20. GOST 19.508-79 DUME. Manuel de maintenance. Exigences en matière de contenu et de conception.
21. GOST 19.604-78 DUME. Règles pour apporter des modifications aux documents du programme exécutés sous forme imprimée.
22. GOST 19.701-90 DUME. Schémas d'algorithmes, de programmes, de données et de systèmes. Conventions et règles d'exécution.
23. GOST 19.781-90. Logiciels pour systèmes de traitement de l'information.

Termes et définitions

Parmi toutes les normes DUME, nous nous concentrerons sur celles qui peuvent être utilisées le plus souvent dans la pratique de l’élaboration de programmes.

La première norme pouvant être utilisée lors de la création de spécifications techniques pour la programmation est GOST (ST SEV) 19.201-78 (1626-79). DUME.
(Spécifications techniques. Exigences relatives au contenu et à la conception.).

Les termes de référence pour le développement d'un programme contiennent un ensemble d'exigences pour le programme et peuvent être utilisés comme un ensemble de critères nécessaires à la vérification et à l'acceptation du programme développé. Ainsi, une spécification technique assez complète constitue l'un des documents initiaux du projet.

Les termes de référence pour l’élaboration du programme doivent comprendre les sections suivantes :

• introduction;
• raisons du développement;
• but du développement;
• les exigences pour un programme ou un produit logiciel ;
• exigences en matière de documentation logicielle;
• indicateurs techniques et économiques;
• étapes et stades de développement;
• procédure de contrôle et de réception ;
• diverses applications (selon les besoins).

Selon les caractéristiques du programme, il est possible de clarifier le contenu des sections, d'introduire de nouvelles sections ou de combiner des sections existantes.

La deuxième norme est GOST (ST SEV) 19.101-77 (1626-79). DUME.
Types de programmes et documents de programme).
Cette norme établit les types de programmes et de documents de programmes pour les ordinateurs, complexes et systèmes, quels que soient leur objectif et leur portée.

Types de programmes :

Types de documents de programme :

Type de document de programme	Contenu du document de politique
spécification	Composition du programme et sa documentation
	Liste des entreprises qui stockent les documents originaux du programme
Texte du programme	Enregistrement du programme avec les commentaires nécessaires
Description du programme	Informations sur la structure logique et le fonctionnement du programme
	Exigences à vérifier lors du test du programme, ainsi que la procédure et les méthodes pour leur contrôle
Tâche technique	Objectif et portée du programme, techniques, faisabilité et exigences particulières du programme, étapes et conditions de développement nécessaires, types de tests
Note explicative	Schéma de l'algorithme, description générale de l'algorithme et (ou) du fonctionnement du programme, ainsi que justification des décisions techniques et technico-économiques adoptées
Documents opérationnels	Informations pour assurer le fonctionnement et le fonctionnement du programme

Types de documents opérationnels :

Type de document opérationnel	Contenu du document opérationnel
	Liste des documents opérationnels du programme
Formulaire	Principales caractéristiques du programme, exhaustivité et informations sur le fonctionnement du programme
Description de la demande	Informations sur l'objectif du programme, le champ d'application, les méthodes utilisées, la classe de problèmes à résoudre, les restrictions d'utilisation, la configuration minimale du matériel
	Informations permettant de vérifier, d'assurer le fonctionnement et de personnaliser le programme pour les conditions d'une application spécifique
Guide du programmeur	Informations pour l'utilisation du programme
Manuel de l'opérateur	Informations permettant d'assurer la procédure de communication entre l'opérateur et le système informatique lors de l'exécution du programme
Description de la langue	Description de la syntaxe et de la sémantique du langage
	Informations pour l'utilisation de programmes de test et de diagnostic lors de l'entretien des équipements techniques

Selon la méthode de mise en œuvre et la nature de la demande, les documents du programme sont divisés en originaux, duplicatas et copies (GOST 2.102-68), destinés au développement, à la maintenance et au fonctionnement du programme.

Types de documents de programme élaborés à différentes étapes et leurs codes :

Code du type de document	Type de document	Étapes de développement
		Conception preliminaire	Projet technique	Document de travail
				composant	complexe
-	spécification	-	-	!	+
05	Liste des titulaires originaux	-	-	-	?
12	Texte du programme	-	-	+	?
13	Description du programme	-	-	?	?
20	Liste des documents opérationnels	-	-	?	?
30	Formulaire	-	-	?	?
31	Description de la demande	-	-	?	?
32	Guide du programmeur système	-	-	?	?
33	Guide du programmeur	-	-	?	?
34	Manuel de l'opérateur	-	-	?	?
35	Description de la langue	-	-	?	?
46	Manuel de maintenance	-	-	?	?
51	Programme et méthodologie de test	-	-	?	?
81	Note explicative	?	?	-	-
90-99	Autres documents	?	?	?	?

Il est permis de regrouper certains types de documents (à l'exception de la liste des documents opérationnels et du formulaire), tandis que la nécessité de regrouper ces documents est indiquée dans les spécifications techniques. Le document fusionné se voit attribuer le nom et la désignation de l'un des documents fusionnés. Les documents fusionnés doivent décrire les informations qui doivent être incluses dans chaque document fusionné.

…………………………………………………………

GOST 19.102-77. DUME. Étapes de développement.

Établit les étapes de développement des programmes et la documentation des programmes pour les ordinateurs, les complexes et les systèmes, quels que soient leur objectif et leur champ d'application

Étapes de développement du programme, étapes et contenu du travail

Étapes de développement	Étapes de travail	Contenu du travail
Tâche technique	Justification de la nécessité de développer le programme	Formulation du problème. Collection de matériaux sources. Sélection et justification des critères d'efficacité et de qualité du programme développé. Justification de la nécessité de travaux de recherche.
	Travail de recherche	Déterminer la structure des données d'entrée et de sortie. Sélection préliminaire de méthodes de résolution de problèmes. Justification de la faisabilité de l'utilisation de programmes développés précédemment. Détermination des besoins en moyens techniques. Justification de la possibilité fondamentale de résoudre le problème.
	Élaboration et approbation des spécifications techniques	Déterminer les exigences du programme. Élaboration d'une étude de faisabilité pour le développement du programme. Détermination des étapes, des étapes et du calendrier de développement du programme et de la documentation correspondante. Choix des langages de programmation. Déterminer la nécessité de travaux de recherche aux étapes ultérieures. Coordination et approbation des spécifications techniques.
Conception preliminaire	Élaboration d'un avant-projet	Développement préliminaire de la structure des données d'entrée et de sortie. Clarification des méthodes pour résoudre le problème. Développement d'une description générale de l'algorithme de résolution du problème. Élaboration d'une étude de faisabilité.
	Approbation de l’avant-projet	Élaboration d'une note explicative. Coordination et approbation de l'avant-projet
Projet technique	Développement de projet technique	Clarification de la structure des données d'entrée et de sortie. Développement d'un algorithme pour résoudre le problème. Déterminer la forme de présentation des données d'entrée et de sortie. Définition de la sémantique et de la syntaxe du langage. Développement de la structure du programme. Détermination finale de la configuration matérielle.
	Approbation de la conception technique	Élaboration d'un plan d'action pour l'élaboration et la mise en œuvre de programmes. Élaboration d'une note explicative. Coordination et approbation de la conception technique.
Document de travail	Développement de programme	Programmation et débogage
	Développement de la documentation du logiciel	Élaboration de documents de programme conformément aux exigences de GOST 19.101-77.
	Test du programme	Développement, coordination et approbation du programme et de la méthodologie de tests. Réalisation de tests d'état préliminaires, interministériels, d'acceptation et autres types. Correction du programme et de la documentation du programme en fonction des résultats des tests.
Mise en œuvre	Préparation et transmission du programme	Préparation et transfert de programmes et de documentation logicielle pour la maintenance et (ou) la production. Enregistrement et approbation de l'acte de transfert du programme pour maintenance et (ou) production. Transfert du programme au fonds d'algorithmes et de programmes.

Remarques:

1. Il est permis d'exclure la deuxième étape du développement et, dans les cas techniquement justifiés, les deuxième et troisième étapes. La nécessité de ces étapes est indiquée dans les spécifications techniques.
2. Il est permis de combiner, d'exclure des étapes de travail et (ou) leur contenu, ainsi que d'introduire d'autres étapes de travail comme convenu avec le client.

GOST 19.103-77 DUME. Désignation des programmes et documents de programme

Le code du pays du développeur et le code de l'organisation du développeur sont attribués de la manière prescrite.

• Un numéro d'enregistrement est attribué par ordre croissant, de 00001 à 99999, pour chaque organisme de développement.
• Le numéro de publication ou le numéro de révision du programme. le numéro d'un document de ce type, le numéro de la partie du document sont attribués par ordre croissant de 01 à 99. (Si le document est constitué d'une partie, alors le trait d'union et le numéro de série de la partie ne sont pas indiqués).
• Le numéro de révision du cahier des charges et la liste des documents opérationnels du programme doivent correspondre au numéro de publication du même programme.

GOST 19.105-78 DUME. Exigences générales pour les documents du programme

Cette norme établit les exigences générales pour l'exécution de documents de programme pour les ordinateurs, complexes et systèmes, quels que soient leur objectif et leur champ d'application et prévues par les normes du Système unifié de documentation de programme (USPD) pour toute méthode d'exécution de documents sur divers supports de données.

Le document de programme peut être présenté sur différents types de supports de stockage et se compose des parties conventionnelles suivantes :
titre;
informatif;
basique.

Les règles d'exécution d'un document et de ses parties sur chaque support de données sont établies par les normes DUME pour les règles d'exécution des documents sur les supports de données correspondants.

GOST 19.106-78 DUME. Exigences relatives aux documents imprimés du programme

Les documents de programme sont rédigés par :

• sur des feuilles au format A4 (GOST 2.301-68) lors de la préparation d'un document par dactylographie ou écriture manuscrite ;
• Peut être imprimé sur des feuilles de format A3 ;
• avec la méthode machine d'exécution des documents, des écarts de format des feuilles correspondant aux formats A4 et A3 sont autorisés, déterminés par les capacités des moyens techniques utilisés ; sur des feuilles aux formats A4 et A3, prévues par les caractéristiques de sortie des dispositifs de sortie de données, lors de la production d'un document par machine ;
• sur des feuilles de formats typographiques lors de la réalisation d'un document par méthode typographique.

Les éléments du document de programme sont classés dans l'ordre suivant :

Partie titre :

• feuille d'approbation (non incluse dans le nombre total de feuilles du document);
• page de titre (première page du document);

partie information :

• annotation;
• table des matières;

partie principale:

• texte du document (avec images, tableaux, etc.)
• liste de termes et leurs définitions ;
• Liste des abréviations;
• applications;
• index des sujets;
• liste des documents de référence ;

modifier la partie de journalisation :

• modifier la fiche d'inscription.

Une liste de termes et leurs définitions, une liste d'abréviations, des annexes, un index thématique, une liste de documents de référence sont fournis si nécessaire.

La norme suivante se concentre sur la documentation du produit de développement résultant :

GOST 19.402-78 DUME. Description du programme

La composition du document « Description du programme » dans son contenu peut être complétée par des sections et paragraphes tirés des normes d'autres documents et manuels descriptifs : GOST 19.404-79 ESPD. Note explicative, GOST 19.502-78 ESPD. Description de l'application, GOST 19.503-79 ESPD. Guide du programmeur système, GOST 19.504-79 ESPD. Guide du programmeur, GOST 19.505-79 ESPD. Manuel de l'opérateur.

Il existe également un groupe de normes qui définissent les exigences d'enregistrement de l'ensemble des programmes et des PD élaborés pour le transfert de logiciels. Ils génèrent des documents comptables concis et peuvent être utiles pour rationaliser toute la gestion des programmes et des PD (après tout, il suffit très souvent de rétablir l'ordre de base !). Il existe également des normes qui définissent les règles de conservation des documents dans le « ménage » du PS.

Il faut également souligner

GOST 19.301-79 DUME. Programme et méthodologie de test qui (sous une forme adaptée) peuvent être utilisés pour élaborer des documents de planification et effectuer des travaux de test pour évaluer l'état de préparation et la qualité de la sous-station.

Enfin, la dernière norme selon l'année d'adoption.

GOST 19.701-90 DUME. Schémas d'algorithmes, de programmes, de données et de systèmes. Désignations graphiques conventionnelles et règles d'exécution.

Il établit des règles pour l'exécution des diagrammes utilisés pour représenter différents types de problèmes de traitement de données et les moyens de les résoudre et est entièrement conforme à la norme ISO 5807 : 1985.

Outre l'ESPD, deux autres normes sont en vigueur au niveau interétatique, également liées à la documentation du PS et adoptées il n'y a pas si longtemps que la plupart des DUME GOST.

GOST 19781-90 Logiciel pour les systèmes de traitement de l'information. Termes et définitions. Développé pour remplacer GOST 19.781-83 et GOST 19.004-80 et établit des termes et définitions dans le domaine des logiciels (logiciels) des systèmes de traitement de données (SOD), utilisés dans tous les types de documentation et de littérature inclus dans le cadre des travaux de normalisation ou utilisant les résultats de ce travail.

GOST 28388-89 Systèmes de traitement de l'information. Documents sur supports de stockage magnétiques. Ordre d'exécution et de traitement. S'applique non seulement aux logiciels, mais également aux documents de conception, technologiques et autres exécutés sur des supports magnétiques.

2.2. Normes du complexe GOST 34

GOST 34 a été conçu à la fin des années 80 comme un ensemble complet de documents intersectoriels interconnectés. Les motivations et les résultats qui en résultent sont décrits ci-dessous dans les « Caractéristiques » de GOST 34. Les objets de normalisation sont des locuteurs de divers (n'importe quels !) types et tous les types de leurs composants, et pas seulement des logiciels et des bases de données.

Le complexe est conçu pour l'interaction entre le client et le développeur. Semblable à la norme ISO12207, il est prévu que le client puisse développer lui-même des enceintes (s'il crée une unité spécialisée pour cela). Cependant, le libellé de GOST 34 n'est pas axé sur un reflet aussi explicite et, dans un certain sens, symétrique des actions des deux parties que l'ISO12207. Étant donné que GOST 34 prête principalement attention au contenu des documents de projet, la répartition des actions entre les parties se fait généralement sur la base de ce contenu.

Parmi tous les groupes de documents existants et non mis en œuvre, nous nous baserons uniquement sur le groupe 0 « Dispositions générales » et le groupe 6 « Création, fonctionnement et développement d'AS ». Les normes les plus populaires peuvent être considérées comme GOST 34.601-90 (étapes de création d'un AS), GOST 34.602-89 (TK pour la création d'un AS) et les lignes directrices RD 50-34.698-90 (Exigences relatives au contenu des documents). Les normes prévoient les étapes et étapes de travail pour créer un AS, mais ne prévoient pas explicitement des processus de bout en bout.

Pour le cas général du développement AS, les étapes et étapes de GOST 34 sont indiquées dans le tableau :

1. FT – Formation des exigences pour AS.	1.1. Inspection de l'installation et justification de la nécessité de créer une centrale nucléaire ; 1.2. Formation des exigences des utilisateurs pour les haut-parleurs ; 1.3. Préparation d'un rapport sur les travaux effectués et d'une demande d'élaboration d'un AS (spécifications tactiques et techniques) ;
2. RK – Développement du concept AS.	2.1. Etude de l'objet ; 2.2. Réaliser les travaux de recherche nécessaires ; 2.3. Développement d'options pour le concept d'enceinte répondant aux exigences des utilisateurs 2.4. Rédaction d'un rapport sur les travaux effectués
3. TK – Création technique de la centrale nucléaire.	3.1. Élaboration et approbation des spécifications techniques pour la tâche.
4. EP - Avant-projet.	4.1. Développement de solutions de conception préliminaires pour le système et ses pièces ; 4.2. Développement de la documentation pour l'UA et ses parties.
5. TP – Conception technique.	5.1. Développement de solutions de conception pour le système et ses pièces ; 5.2. Élaboration de la documentation pour la centrale nucléaire et ses parties ; 5.3. Élaboration et exécution de la documentation pour la fourniture de produits pour compléter la centrale nucléaire et/ou des exigences techniques (spécifications techniques) pour leur développement ; 5.4. Développement de tâches de conception dans les parties adjacentes du projet d'installation d'automatisation.
6. RD – Documentation de travail.	6.1. Développement de la documentation de travail pour le système et ses parties ; 6.2. Développement ou adaptation de programmes.
7. VD – Mise en service.	7.1. Préparation de l'installation d'automatisation pour la mise en service de l'usine ; 7.2. Formation du personnel ; 7.3. Ensemble complet d'enceintes avec les produits fournis (logiciels et matériels, systèmes logiciels et matériels, produits d'information) ; 7.4. Travaux de construction et d'installation ; 7.5. Travaux de mise en service ; 7.6. Réaliser des tests préliminaires ; 7.7. Réalisation d'opérations d'essai ; 7.8. Réalisation des tests de recette.
8. Sp – Prise en charge CA.	8.1. Effectuer les travaux conformément aux obligations de garantie ; 8.2. Service après garantie.

Le contenu des documents élaborés à chaque étape est décrit. Cela détermine la possibilité d'identifier au niveau substantiel les travaux de bout en bout effectués en parallèle ou séquentiellement (c'est-à-dire, essentiellement, les processus) et les tâches qui les constituent. Cette technique peut être utilisée lors de l'élaboration d'un profil de normes de cycle de vie de projet, y compris des sous-ensembles convenus des normes GOST 34 et ISO12207.

Le motif principal : résoudre le problème de la « Tour de Babel ».

Dans les années 80, une situation s'est produite dans laquelle diverses industries et domaines d'activité utilisaient des NTD - «documentation normative et technique» mal ou non coordonnées. Cela a rendu difficile l’intégration des systèmes et la garantie de leur fonctionnement commun efficace. Il existait divers complexes et systèmes de normes qui établissaient des exigences pour différents types d'AS.

La pratique d'application des normes a montré qu'elles appliquent essentiellement (mais pas selon des définitions strictes) un système unifié de concepts, il existe de nombreux objets communs de normalisation, mais les exigences des normes ne sont pas cohérentes les unes avec les autres, il existe des différences dans la composition et le contenu des travaux, les différences de désignation, de composition, de contenu et d'exécution des documents, etc.

Bien entendu, cette situation reflétait en partie la diversité naturelle des conditions de développement de l'AS, des objectifs des développeurs et des approches et techniques utilisées.

Dans ces conditions, il était possible d’analyser cette diversité et de procéder ensuite, par exemple, de deux manières largement opposées :

1. Développer un système conceptuel et terminologique généralisé, un schéma général de développement, un ensemble commun de documents avec leur contenu et les définir comme obligatoires pour tous les AS ;
2. Définir également un système conceptuel et terminologique général, un ensemble généralisé d'exigences système, un ensemble de critères de qualité, mais offrir une liberté maximale dans le choix d'un schéma de développement, la composition des documents et d'autres aspects, en imposant seulement un minimum d'exigences obligatoires qui permettraient :
   • déterminer le niveau de qualité du résultat ;
   • sélectionner les méthodes spécifiques (avec leurs modèles de cycle de vie, ensemble de documents, etc.) les plus adaptées aux conditions de développement et correspondant aux technologies de l'information utilisées ;
   • travaillez ainsi avec des restrictions minimales sur les actions efficaces du concepteur d’enceintes.

Les développeurs de l'ensemble de normes 34 ont choisi une méthode proche de la première de celles indiquées ci-dessus, c'est-à-dire qu'ils ont emprunté un chemin plus proche des schémas de méthodes spécifiques que des normes comme ISO12207. Toutefois, en raison de la généralité de la base conceptuelle, les normes restent applicables dans un très large éventail de cas.

Le degré d'adaptabilité est formellement déterminé par les capacités :

• omettre l'étape de conception préliminaire et combiner les étapes de « Conception technique » et de « Documentation détaillée » ;
• omettre des étapes, combiner et omettre la plupart des documents et leurs sections ;
• saisir des documents supplémentaires, des sections de documents et des travaux ;
• créant dynamiquement ce qu'on appelle. ChTZ - spécifications techniques privées - il est assez flexible pour former le cycle de vie d'une centrale nucléaire ; En règle générale, cette technique est utilisée au niveau de grandes unités (sous-systèmes, complexes), pour lesquelles il est considéré comme justifié de créer un CTZ, mais il n'y a aucune raison significative de limiter sévèrement cette méthode de gestion du cycle de vie.

Les étapes et jalons réalisés par les organismes participant à la création de centrales nucléaires sont fixés dans des contrats et des spécifications techniques, ce qui se rapproche de la démarche ISO.

L'introduction d'une terminologie unifiée, assez qualitativement définie, la présence d'une classification assez raisonnable des œuvres, des documents, des types de supports, etc. sont certainement utiles. GOST 34 contribue à une assemblage plus complet et de haute qualité de systèmes véritablement différents, ce qui est particulièrement important dans des conditions où des systèmes intégrés de plus en plus complexes sont développés, par exemple, tels que CAD-CAM, qui incluent un système de contrôle de processus, un système de contrôle, un concepteur CAO, un technologue CAO, ASNI et d'autres systèmes.

Plusieurs dispositions importantes ont été définies qui reflètent les caractéristiques de l'AS en tant qu'objet de normalisation, par exemple : « en général, l'AS se compose de complexes logiciels et matériels (PTK), logiciels et méthodologiques (PMK) et de composants individuels d'organisation, support technique, logiciel et informationnel.

La séparation des notions de PTC et d'AS consacre le principe selon lequel l'AS n'est pas un « SI avec base de données », mais :

• « un système organisationnel et technique qui assure le développement de solutions basées sur l'automatisation des processus d'information dans divers domaines d'activité (gestion, conception, production, etc.) ou leurs combinaisons » (selon RD 50-680-88), qui est particulièrement pertinent dans les aspects commerciaux - réingénierie ;
• « un système composé de personnel et d'un ensemble d'outils d'automatisation pour leurs activités, mettant en œuvre les technologies de l'information pour exécuter les fonctions établies » (selon GOST 34.003-90).

Ces définitions indiquent que l'AS est avant tout un personnel qui prend des décisions et effectue d'autres actions de gestion, soutenu par des moyens organisationnels et techniques.

Degré d'obligation :

L'exigence obligatoire complète précédente est absente : les matériaux GOST34 sont essentiellement devenus un support méthodologique, le plus souvent pour les clients qui ont dans la norme un ensemble d'exigences concernant le contenu des spécifications techniques et les tests de l'AS. Dans le même temps, l'utilité de GOST34 peut augmenter plusieurs fois s'ils sont utilisés de manière plus flexible dans la formation du profil de cycle de vie AS.

Le document clé pour l'interaction entre les parties est le cahier des charges technique pour la création de la centrale nucléaire. La spécification technique est le principal document source pour la création de l'AS et son acceptation ; la spécification technique détermine les points d'interaction les plus importants entre le client et le développeur. Dans ce cas, les spécifications techniques sont élaborées par l'organisation du développeur (selon GOST 34.602-89), mais le client délivre formellement les spécifications techniques au développeur (selon RD 50-680-88).

2.3. Normes d'État de la Fédération de Russie (GOST R)

Dans la Fédération de Russie, il existe un certain nombre de normes pour la documentation des logiciels, élaborées sur la base de l'application directe des normes internationales ISO. Ce? les normes les plus récentes au moment de leur adoption. Certaines d'entre elles s'adressent directement aux chefs de projets ou aux directeurs des services d'information. En même temps, ils sont déraisonnablement peu connus des professionnels. Voici leur prestation.

GOST R ISO/CEI 9294-93 Informatique. Guide de gestion de la documentation logicielle. La norme est entièrement conforme à la norme internationale ISO/IEC TO 9294:1990 et établit des recommandations pour une gestion efficace de la documentation des logiciels à l'intention des responsables responsables de leur création. L'objectif de la norme est d'aider à définir une stratégie de documentation des logiciels ; choisir les normes de documentation ; choisir les procédures de documentation ; déterminer les ressources nécessaires; établir des plans de documentation.

GOST R ISO/CEI 9126-93 Informatique. Évaluation de produits logiciels. Caractéristiques de qualité et directives pour leur utilisation. La norme est entièrement conforme à la norme internationale ISO/IEC 9126:1991. Dans son contexte, une caractéristique de qualité est comprise comme « un ensemble de propriétés (attributs) d'un produit logiciel par lequel sa qualité est décrite et évaluée ». La norme définit six caractéristiques complètes qui, avec un minimum de duplication, décrivent la qualité des logiciels (logiciels, produits logiciels) : fonctionnalité ; fiabilité; aspect pratique ; efficacité; accompagnement; mobilité. Ces caractéristiques constituent la base d'une clarification et d'une description plus approfondies de la qualité du logiciel.

GOST R ISO 9127-94 Systèmes de traitement de l'information. Documentation utilisateur et informations sur l'emballage des progiciels grand public. La norme est entièrement conforme à la norme internationale ISO 9127:1989. Aux fins de cette norme, un progiciel grand public (CSP) est défini comme « des produits logiciels conçus et commercialisés pour exécuter des fonctions spécifiques ; un programme et sa documentation associée conditionnés pour la vente comme une seule unité. La documentation utilisateur fait référence à la documentation qui fournit à l'utilisateur final des informations sur l'installation et le fonctionnement du logiciel. Les informations figurant sur l'emballage font référence aux informations reproduites sur l'emballage extérieur du PP. Son objectif est de fournir aux acheteurs potentiels des informations primaires sur le logiciel.

GOST R ISO/CEI 8631-94 Informatique. Constructions logicielles et symboles pour leur représentation. Décrit la présentation des algorithmes procéduraux.

2.4. Norme internationale ISO/IEC 12207 : 1995-08-01

La première édition de l'ISO12207 a été préparée en 1995 par le comité technique mixte ISO/IEC JTC1 « Technologies de l'information, sous-comité SC7, génie logiciel ».

Par définition, ISO12207 est la norme de base pour les processus du cycle de vie des logiciels, axée sur divers (n'importe quel !) types de logiciels et types de projets AS, dont le logiciel fait partie. La norme définit la stratégie et l'ordre général dans la création et l'exploitation des logiciels ; elle couvre le cycle de vie du logiciel depuis la conceptualisation des idées jusqu'à l'achèvement du cycle de vie.

NOTES Très Importantes DE LA NORME :

1. Les processus utilisés pendant le cycle de vie du logiciel doivent être compatibles avec les processus utilisés pendant le cycle de vie de l'AS. (L'opportunité d'une utilisation conjointe des normes AS et logicielles est donc évidente.)
2. L’ajout de processus, d’activités et de tâches uniques ou spécifiques doit être précisé dans le contrat entre les parties. Le contrat s’entend au sens large : du contrat légalement formalisé à l’accord informel, un accord peut être défini par une seule partie comme une tâche qui s’impose à elle-même.
3. La norme ne contient fondamentalement pas de méthodes d'action spécifiques, et encore moins de projets de solutions ou de documentation. Il décrit l'architecture des processus du cycle de vie des logiciels, mais ne précise pas en détail comment mettre en œuvre ou exécuter les services et tâches inclus dans les processus, et n'a pas pour but de prescrire le nom, le format ou le contenu exact de la documentation résultante. Les décisions de ce type sont prises par l'utilisateur de la norme.

DÉFINITIONS STANDARD :

1. Un système est une association d'un ou plusieurs processus, matériels, logiciels, équipements et personnes pour permettre la satisfaction de besoins ou d'objectifs spécifiés.
2. Modèle de cycle de vie– une structure contenant les processus, actions et tâches qui sont effectués lors du développement, de l'exploitation et de la maintenance d'un produit logiciel tout au long de la vie du système, depuis la détermination des exigences jusqu'à la fin de son utilisation.
   De nombreux processus et tâches sont conçus de manière à pouvoir être adaptés en fonction des projets logiciels. Le processus d'adaptation est le processus d'élimination des processus, activités et tâches qui ne sont pas applicables à un projet particulier. Degré d'adaptabilité : maximum
3. Exigence de qualification– un ensemble de critères ou de conditions (exigences de qualification) qui doivent être satisfaits afin de qualifier un produit logiciel comme étant conforme (satisfaisant aux conditions) à ses spécifications et prêt à être utilisé dans l'environnement cible.

La norme ne prescrit pas de modèle de cycle de vie ou de méthode de développement logiciel spécifique, mais précise que les parties à l'utilisation de la norme sont responsables de la sélection d'un modèle de cycle de vie pour un projet logiciel, d'adapter les processus et les tâches de la norme à ce modèle. , pour sélectionner et appliquer des méthodes de développement de logiciels, et pour effectuer des actions et des tâches appropriées au projet logiciel.

La norme ISO12207 s'attache également à organiser les actions de chacune des deux parties : le fournisseur (développeur) et l'acheteur (utilisateur) ; peut être appliqué de manière égale lorsque les deux parties appartiennent à la même organisation.

Chaque processus du cycle de vie est divisé en un ensemble d'actions, chaque action en un ensemble de tâches. Une différence très importante entre ISO : chaque processus, action ou tâche est initié et exécuté par un autre processus selon les besoins, et il n'y a pas de séquences prédéterminées (bien sûr, tout en conservant la logique des connexions en fonction des informations initiales des tâches, etc. ).

La norme ISO12207 décrit :

1. 5 principaux processus du cycle de vie des logiciels :
   • Processus d'acquisition. Détermine les actions de l'entreprise acheteuse qui achète l'AS, le produit logiciel ou le service logiciel.
   • Processus de livraison. Définit les actions de l'entreprise fournisseur qui fournit à l'acheteur un système, un produit logiciel ou un service logiciel.
   • Processus de développement. Détermine les actions de l'entreprise de développement, qui développe le principe de construction d'un produit logiciel et du produit logiciel.
   • Processus de fonctionnement. Définit les actions de l'entreprise exploitante, qui assure la maintenance du système (et pas seulement du logiciel) pendant son exploitation dans l'intérêt des utilisateurs. Contrairement aux actions qui sont déterminées par le développeur dans le mode d'emploi (cette activité du développeur est prévue dans les trois normes considérées), les actions de l'opérateur pour consulter les utilisateurs, recevoir des retours, etc. sont déterminées, qui il se planifie et assume les responsabilités correspondantes.
   • Processus d'entretien. Détermine les actions du personnel de maintenance qui assure la maintenance du produit logiciel, c'est-à-dire la gestion des modifications du produit logiciel, la prise en charge de son état actuel et de son adéquation fonctionnelle, y compris l'installation et la suppression du produit logiciel sur le système informatique.
2. 8 processus auxiliaires qui soutiennent la mise en œuvre d'un autre processus, faisant partie intégrante de l'ensemble du cycle de vie d'un produit logiciel, et assurent la bonne qualité du projet logiciel :
   • solution du problème;
   • Documentation;
   • gestion de la configuration;
   • l'assurance qualité, qui utilise les résultats des processus restants du groupe d'assurance qualité, qui comprend :
     • Processus de vérification;
     • Processus de certification ;
     • Processus d'évaluation participative ;
     • Processus de vérification.
3. 4 processus organisationnels :
   • Processus de gestion;
   • Processus de création d'infrastructures ;
   • Processus d'amélioration ;
   • Processus d'apprentissage.

Ils sont accompagnés d'un processus d'adaptation spécial, qui définit les principales actions nécessaires pour adapter la norme aux conditions d'un projet spécifique.

Le processus d'amélioration ne signifie pas ici l'amélioration de l'AS ou du logiciel, mais l'amélioration des processus d'acquisition, de développement, d'assurance qualité, etc., effectivement réalisés dans l'organisation.

Il n'y a pas d'étapes, de phases, d'étapes prévues, ce qui donne le degré d'adaptabilité décrit ci-dessous.

La nature « dynamique » de la norme est déterminée par la façon dont les processus et les tâches sont séquencés, dans lequel un processus en appelle un autre ou une partie de celui-ci lorsque cela est nécessaire.

• l'exécution du Processus d'Acquisition en termes d'analyse et d'enregistrement des exigences d'un système ou d'un logiciel peut déclencher l'exécution des tâches correspondantes du Processus de Développement ;
• dans le processus de livraison, le fournisseur doit gérer les sous-traitants conformément au processus d'acquisition et effectuer la vérification et la qualification par rapport aux processus pertinents ;
• La maintenance peut nécessiter le développement du système et du logiciel, qui est effectué conformément au processus de développement.

Cette nature permet de mettre en œuvre n’importe quel modèle de cycle de vie.

Lors de l'analyse des exigences logicielles, 11 classes de caractéristiques de qualité sont utilisées ultérieurement dans l'assurance qualité.

Dans ce cas, le développeur doit établir et documenter comme exigences logicielles :

1. Spécifications fonctionnelles et d'activation, y compris l'exécution, les caractéristiques physiques et les conditions d'environnement d'exploitation dans lesquelles l'élément logiciel doit être exécuté ;
2. Connexions externes (interfaces) avec l'unité logicielle ;
3. Les exigences de qualification;
4. Spécifications de fiabilité, y compris les spécifications liées aux méthodes d'exploitation et de maintenance, à l'exposition environnementale et à la probabilité de blessures ;
5. Spécifications de sécurité
6. Spécifications des facteurs humains pour la psychologie de l'ingénierie (ergonomie), y compris celles liées au contrôle manuel, à l'interaction homme-équipement, aux contraintes du personnel et aux domaines nécessitant une attention humaine concentrée et sensibles à l'erreur humaine et à l'apprentissage ;
7. Définir les exigences en matière de données et de bases de données ;
8. Exigences d'installation et d'acceptation du produit logiciel fourni sur les lieux d'exploitation et de maintenance (exploitation) ;
9. Documentation utilisateur ;
10. Exigences de travail et de performance des utilisateurs ;
11. Exigences du service utilisateur.

1. (Il est intéressant et important que ces caractéristiques et d'autres similaires correspondent bien aux caractéristiques de la centrale nucléaire prévues dans GOST 34 pour les types de support système.)

La norme contient très peu de descriptions destinées à la conception de bases de données. Cela peut être considéré comme justifié, puisque différents systèmes et différents progiciels d'application peuvent non seulement utiliser des types de bases de données très spécifiques, mais aussi ne pas utiliser

Ainsi, ISO12207 comporte un ensemble de processus, d'activités et de tâches qui couvrent le plus large éventail possible de situations possibles avec une adaptabilité maximale.

Il montre un exemple de la façon dont un standard bien organisé doit être construit, contenant un minimum de restrictions (le principe selon lequel « il n'y a pas deux projets identiques »). Parallèlement, il est conseillé d'inclure des définitions détaillées de processus, de formes de documents, etc. dans diverses normes fonctionnelles, documents réglementaires départementaux ou méthodes propriétaires pouvant ou non être utilisées dans un projet spécifique.

Pour cette raison, il est utile de considérer ISO12207 comme la norme centrale, dont les dispositions sont considérées comme l'ensemble initial de dispositions « de base » dans le processus de construction d'un profil de normes de cycle de vie pour un projet spécifique. Ce « noyau » peut définir un modèle de cycle de vie des logiciels et des AS, un concept d'assurance qualité et un modèle de gestion de projet.

Les praticiens utilisent une autre méthode : ils traduisent et utilisent eux-mêmes dans leurs projets des normes modernes pour organiser le cycle de vie des programmes et leur documentation. Mais cette voie souffre au moins de l'inconvénient que les différentes traductions et adaptations des normes réalisées par différents développeurs et clients différeront sur de nombreux détails. Ces différences concernent inévitablement non seulement les noms, mais aussi leurs définitions substantielles introduites et utilisées dans les normes. Ainsi, sur cette voie, l'émergence constante d'une confusion est inévitable, ce qui est directement opposé aux objectifs non seulement des normes, mais aussi de tout document méthodologique compétent.

Actuellement, l'Institut panrusse de recherche sur les normes a préparé des propositions visant à améliorer et à développer un ensemble de normes pour la documentation des logiciels.

Jusqu'au sommet

GOST 19.105-78* (Exigences générales pour les documents du programme)

De ce GOST nous obtenonsexigences générales pour la préparation des documents de programme.Vous trouverez ci-dessous les sections les plus importantes.

• Cette norme établit les exigences générales pour l'exécution de documents de programme pour les ordinateurs, complexes et systèmes, quels que soient leur objectif et leur champ d'application et prévues par les normes du Système unifié de documentation de programme (USPD) pour toute méthode d'exécution de documents sur divers supports de données.
• Le document de programme se compose des parties conventionnelles suivantes :
• titre;
• informatif;
• basique;
• enregistrement des modifications.
• La section de couverture se compose d'une feuille d'approbation et d'une page de titre. Les règles d'établissement de la fiche d'approbation et de la page de titre sont établies conformément à GOST 19.104-78.
• Partie informationnelle doit comprendre un résumé et un contenu.
• La nécessité d'inclure la partie informationnelle dans différents types de documents de programme est établie par les normes DUME pertinentes pour ces documents.
• L'annotation fournit des informations sur l'objet du document et un bref résumé de sa partie principale.
• Le contenu comprend une liste d'enregistrements sur les éléments structurels de la partie principale du document, dont chacun comprend :
• désignation d'un élément structurel (numéro de section, sous-section, etc.) ;
• nom de l'élément structurel ;
• adresse de l'élément structurel sur le support de stockage (par exemple, numéro de page, numéro de dossier, etc.).
• La composition et la structure de la partie principale du document de programme sont établies par les normes DUME pour les documents concernés.
• Modifier la partie journalisation(doit être présent dans chaque document de programme)
• Chaque modification dans le document du programme est enregistrée dans cette partie conformément aux exigences de GOST 19.603-78.

Jusqu'au sommet
==================================
GOST 19.106-78* (Exigences générales pour les documents de programme produits sous forme imprimée
chemin)
De ce GOST nous obtenons règles générales pour la méthode d'impressiondocuments du programme. Vous trouverez ci-dessous les sections les plus importantes.

• Cette norme établit les règles d'exécution des documents de programme pour les ordinateurs, complexes et systèmes, quels que soient leur objectif et leur champ d'application et prévues par les normes du Système unifié de documentation de programme (USPD) pour la méthode d'exécution imprimée.
• La norme ne s'applique pas au document de programme « Texte du programme ».
• La composition et la structure du document de programme sont établies conformément à GOST 19.105-78.
• Le document de programme est exécutésur une face de la feuille, à deux intervalles ; autorisé à un intervalle d'un ou un intervalle et demi.
• Les documents de programme sont rédigés par :
• sur des feuilles au format A4 (GOST 2.301-68) - lors de la préparation d'un document par dactylographie ou écriture manuscrite (formulaire 1). Dessiner sur des feuilles A3 est autorisé.

• Les éléments du document de programme sont classés dans l'ordre suivant :
• partie titre :
• feuille d'approbation (non incluse dans le nombre total de feuilles du document);
• page de titre (première page du document);
• partie information :
• annotation;
• table des matières;
• partie principale:
• texte du document (avec images, tableaux, etc.) ;
• applications;
• liste de termes, liste d'abréviations, liste de figures, liste de tableaux, index thématique, liste de documents de référence ;
• modifier la partie de journalisation :
• modifier la fiche d'inscription.

• Le résumé est placé sur une page séparée (numérotée) avec le titre « RÉSUMÉ » et n'est pas numéroté comme une section.
• L'annotation indique l'édition du programme et décrit brièvement le but et le contenu du document. Si le document est composé de plusieurs parties, le nombre total de parties est indiqué dans l'annotation.
• Le contenu du document est placé sur une ou plusieurs pages (numérotées) séparées après l'annotation, munies de l'en-tête « CONTENU », non numérotées en tant que section et incluses dans le nombre total de pages du document.
• Les titres de section sont écrits en majuscules et placés symétriquement par rapport aux bordures droite et gauche du texte.
• Les titres de sous-sections sont écrits à partir du paragraphe en lettres minuscules (à l'exception de la première majuscule).
• La césure des mots dans les titres n'est pas autorisée. Il n'y a pas de point à la fin du titre.

• La distance entre le titre et le texte suivant, ainsi qu'entre les titres de section et de sous-section, doit être égale à :
• lors de l'exécution d'un document par dactylographie - deux intervalles.
• Pour les sections et sous-sections dont le texte est écrit sur la même page que le texte de la section précédente, la distance entre la dernière ligne de texte et le titre suivant doit être égale à :
• lors de l'exécution d'un document à l'aide d'une méthode dactylographiée - trois intervalles dactylographiés.
• Les sections, sous-sections, paragraphes et sous-paragraphes doivent être numérotés en chiffres arabes avec un point.
• Dans une section, il doit y avoir une numérotation continue pour tous les sous-paragraphes, paragraphes et sous-paragraphes inclus dans cette section.
• La numérotation des sous-sections comprend le numéro de section et le numéro d'ordre de la sous-section incluse dans cette section, séparés par un point (2.1 ; 3.1, etc.).
• S'il y a des sections et des sous-sections, le numéro d'ordre de l'article et du sous-article (3.1.1, 3.1.1.1, etc.) est ajouté au numéro de sous-section après le point.

Un exemple de la structure du texte d'un document de programme et de la numérotation de ses sections, sous-sections, paragraphes et sous-paragraphes.

• Le texte du document doit être court, clair, excluant toute possibilité de mauvaise interprétation.
• Les termes et définitions doivent être uniformes et conformes aux normes établies, et en leur absence, généralement acceptés dans la littérature scientifique et technique, et être indiqués dans la liste des termes.
• Les explications nécessaires au texte du document peuvent être fournies dans les notes de bas de page.
• Une note de bas de page est indiquée par un chiffre avec parenthèse placé au niveau de la ligne du bord supérieur de la police, par exemple : « dispositif d'impression 2)… » ou « papier 5) ».
• Si une note de bas de page fait référence à un seul mot, le signe de note de bas de page est placé directement à côté de ce mot, mais s'il fait référence à une phrase dans son ensemble, alors à la fin de la phrase. Le texte de la note de bas de page est placé en fin de page et séparé du texte principal par une ligne de 3 cm de long tracée sur le côté gauche de la page.
• Les illustrations, s'il y en a plusieurs dans un document donné, sont numérotées en chiffres arabes sur l'ensemble du document.
• Les formules d'un document, s'il y en a plusieurs, sont numérotées en chiffres arabes ; le numéro est placé sur le côté droit de la page, entre parenthèses au niveau de la formule.
• La signification des symboles et des coefficients numériques inclus dans la formule doit être indiquée directement sous la formule. La signification de chaque caractère est imprimée sur une nouvelle ligne dans l'ordre dans lequel ils sont donnés dans la formule. La première ligne de la transcription doit commencer par le mot « où », sans deux points après.
• Dans les documents du programme, les références aux normes (à l'exception des normes d'entreprise), aux spécifications techniques et à d'autres documents (par exemple, les documents des organismes de surveillance de l'État, les règles et règlements du Comité national de la construction de l'URSS) sont autorisées. Lorsqu'on fait référence aux normes et spécifications techniques, leur désignation est indiquée.
• Il convient de faire référence au document dans son ensemble ou à ses sections (en indiquant la désignation et le nom du document, le numéro et le nom de la section ou de l'annexe). Lors de la répétition des références à une section ou à une application, seul le numéro est indiqué.
• Les notes du texte et des tableaux indiquent uniquement des données de référence et explicatives.
• Un billet n'est pas numéroté. Après le mot « Note », mettez un point.
• Plusieurs notes doivent être numérotées dans l'ordre en utilisant des chiffres arabes avec un point. Après le mot « Note », mettez deux points.
• Les abréviations de mots dans le texte et les inscriptions sous les illustrations ne sont pas autorisées.
• Du matériel illustré, des tableaux ou des textes justificatifs peuvent être présentés sous forme d’annexes.
• Chaque candidature doit commencer sur une nouvelle page avec le mot « ANNEXE » indiqué dans le coin supérieur droit et comporter un titre thématique, écrit symétriquement au texte en lettres majuscules.(au final, pour créer un projet, nous n'avons besoin que d'une fiche d'enregistrement de changement).
  
  • Cette norme établit les règles de modification des documents du programme prévues par les normes du Système unifié de documentation du programme (USPD) et imprimées.
  En raison de la quantité importante d'informations contenues dans ce GOST et pour économiser de l'espace sur cette page, je vous recommande de le consulter vous-même GOST 19.604-78* . Exemple de conception prête"changer la fiche d'inscription"Vous pouvez le consulter dans n'importe quel document de programme fourni dans la section TÉLÉCHARGEMENT
  
  Jusqu'au sommet
  ==================================