NORME INTER-ÉTATS
La norme est entièrement conforme à ST SEV 2092-80.
2. La structure et le format du document sont établis conformément à GOST 19.105-78.
La rédaction de la partie informationnelle (annotations et contenu) est obligatoire.
3. La description du programme doit contenir les sections suivantes :
des données d'entrée;
sortir.
Selon les caractéristiques du programme, il est possible d'introduire des sections supplémentaires ou de combiner des sections individuelles.
4. Dans la section « Informations générales », les éléments suivants doivent être indiqués :
désignation et nom du programme;
méthodes utilisées;
structure du programme avec une description des fonctions de ses composants et des connexions entre eux ;
connexion du programme avec d'autres programmes.
La description de la structure logique du programme est réalisée en tenant compte du texte du programme dans la langue source.
3-6.(Édition modifiée, amendement n° 1).
7. La section « Moyens techniques utilisés » doit indiquer les types d'ordinateurs et d'appareils électroniques utilisés lors de l'exécution du programme.
nature, organisation et préparation préliminaire des données d'entrée ;
format, description et méthode de codage des données d'entrée.
10. Dans la section « Données de sortie », les éléments suivants doivent être indiqués :
nature et organisation des données de sortie ;
format, description et méthode de codage des données de sortie.
11. Il est permis d'illustrer le contenu des sections avec des exemples explicatifs, des tableaux, des diagrammes, des graphiques.
12. L'annexe à la description du programme peut contenir divers éléments qu'il est inapproprié d'inclure dans les sections de la description.
7-12.(Introduit en plus, amendement n° 1).
V.E. Karpov
Ce document contient une brève description des normes DUME, 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 de type jargon 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 ça.). 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 modèle. Mais cela doit être fait de manière très efficace. Tranquille. Très minutieux.
Vous devez d'abord vous armer des normes 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. n° 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. |
|
Travail de recherche |
Déterminer la structure des données d'entrée et de sortie. |
|
|
Élaboration et approbation des spécifications techniques |
Déterminer les exigences du programme. |
|
|
Conception preliminaire |
Élaboration d'un avant-projet |
Développement préliminaire de la structure des données d'entrée et de sortie. |
|
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. |
|
Approbation de la conception technique |
Élaboration d'un plan d'action pour l'élaboration et la mise en œuvre de programmes. |
|
|
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. |
|
|
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. |
Remarques:
- 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.
- 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:
- Le programme est lancé….
- Choisi...
- Pressé...
- 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é.
NORME D'ÉTAT DE L'UNION URSS
Système unifié de documentation du programme
Par décret du Comité d'État de l'URSS sur les normes du 18 décembre 1978 n° 3350, la date d'introduction a été fixée du 01.01. 1980
1. Cette norme établit la composition et les exigences relatives au contenu du document de programme « Description du programme », défini par GOST 19.101-77.
La norme est entièrement conforme à ST SEV 2092-80.
2. La structure et le format du document sont établis conformément à GOST 19.105-78.
La rédaction de la partie informationnelle (annotations et contenu) est obligatoire.
3. La description du programme doit contenir les sections suivantes :
- informations générales;
- objectif fonctionnel;
- description de la structure logique ;
- moyens techniques utilisés ;
- des données d'entrée;
- sortir.
Selon les caractéristiques du programme, il est possible d'introduire des sections supplémentaires ou de combiner des sections individuelles.
4. Dans la section « Informations générales », les éléments suivants doivent être indiqués :
- désignation et nom du programme;
- logiciel nécessaire au fonctionnement du programme ;
- langages de programmation dans lesquels le programme est écrit.
5. La section « Objectif fonctionnel » doit indiquer les classes de problèmes à résoudre et (ou) l'objectif du programme et des informations sur les restrictions fonctionnelles d'utilisation.
6. Dans la section « Description de la structure logique », les éléments suivants doivent être indiqués :
- algorithme de programme ;
- méthodes utilisées;
- structure du programme avec une description des fonctions de ses composants et des connexions entre eux ;
- connexion du programme avec d'autres programmes.
La description de la structure logique du programme est réalisée en tenant compte du texte du programme dans la langue source.
3-6.(Édition modifiée, amendement n° 1).
7. La section « Outils techniques utilisés » doit indiquer les types d'ordinateurs et d'appareils électroniques utilisés lors de l'exécution du programme.
- méthode d'appel du programme à partir du support de stockage correspondant ;
- points d’entrée dans le programme.
Vous pouvez spécifier des adresses de téléchargement, des informations sur l'utilisation de la RAM et la taille du programme.
9. Dans la section « Données d'entrée », les éléments suivants doivent être indiqués :
- nature, organisation et préparation préliminaire des données d'entrée ;
- format, description et méthode de codage des données d'entrée.
10. Dans la section « Données de sortie », les éléments suivants doivent être indiqués :
- nature et organisation des données de sortie ;
- format, description et méthode de codage des données de sortie.
11. Il est permis d'illustrer le contenu des sections avec des exemples explicatifs, des tableaux, des diagrammes, des graphiques.
12. L'annexe à la description du programme peut contenir divers éléments qu'il est inapproprié d'inclure dans les sections de la description.
7-12.(Introduit en plus, amendement n° 1).
*Réédition (novembre 1987) avec modification n° 1, approuvée en septembre 1981 (IUS 11-81)
GOST 19.402-78
Groupe T55
NORME INTER-ÉTATS
Système unifié de documentation du programme
DESCRIPTION DU PROGRAMME
Système unifié pour la documentation du programme. Description du programme.
MKS 35.080
Date d'introduction 1980-01-01
Par décret du Comité d'État de l'URSS sur les normes du 18 décembre 1978 N 3350, la date de mise en œuvre a été fixée au 01/01/80
ÉDITION (janvier 2010) avec amendement n° 1, approuvé en septembre 1981 (IUS 11-81).
1. Cette norme établit la composition et les exigences relatives au contenu du document de programme « Description du programme », défini par GOST 19.101-77.
La norme est entièrement conforme à ST SEV 2092-80*.
________________
* L'accès aux documents internationaux et étrangers mentionnés ici peut être obtenu en suivant le lien vers le site http://shop.cntd.ru. - Note du fabricant de la base de données.
(Édition modifiée, amendement n° 1).
2. La structure et la conception du document sont établies conformément à GOST 19.105-78.
La rédaction de la partie informationnelle (annotations et contenu) est obligatoire.
3. La description du programme doit contenir les sections suivantes :
informations générales;
objectif fonctionnel;
description de la structure logique ;
moyens techniques utilisés ;
des données d'entrée;
sortir.
Selon les caractéristiques du programme, il est possible d'introduire des sections supplémentaires ou de combiner des sections individuelles.
4. Dans la section « Informations générales », les éléments suivants doivent être indiqués :
désignation et nom du programme;
logiciel nécessaire au fonctionnement du programme ;
langages de programmation dans lesquels le programme est écrit.
5. La section « Objectif fonctionnel » doit indiquer les classes de problèmes à résoudre et (ou) l'objectif du programme et des informations sur les restrictions fonctionnelles d'utilisation.
6. Dans la section « Description de la structure logique », les éléments suivants doivent être indiqués :
algorithme de programme ;
méthodes utilisées;
structure du programme avec une description des fonctions de ses composants et des connexions entre eux ;
connexion du programme avec d'autres programmes.
La description de la structure logique du programme est réalisée en tenant compte du texte du programme dans la langue source.
3-6. (Édition modifiée, amendement n° 1).
7. La section « Moyens techniques utilisés » doit indiquer les types d'ordinateurs et d'appareils électroniques utilisés lors de l'exécution du programme.
méthode d'appel du programme à partir du support de stockage correspondant ;
points d’entrée dans le programme.
Vous pouvez spécifier des adresses de téléchargement, des informations sur l'utilisation de la RAM et la taille du programme.
9. Dans la section « Données d'entrée », les éléments suivants doivent être indiqués :
nature, organisation et préparation préliminaire des données d'entrée ;
format, description et méthode de codage des données d'entrée.
10. Dans la section « Données de sortie », les éléments suivants doivent être indiqués :
nature et organisation des données de sortie ;
format, description et méthode de codage des données de sortie.
11. Il est permis d'illustrer le contenu des sections avec des exemples explicatifs, des tableaux, des diagrammes, des graphiques.
12. L'annexe à la description du programme peut contenir divers éléments qu'il est inapproprié d'inclure dans les sections de la description.
7-12. (Introduit en plus, amendement n° 1).
Texte du document électronique
préparé par Kodeks JSC et vérifié par rapport à :
publication officielle
Système unifié de documentation du programme :
Collection de normes nationales. -
M. : Standartinform, 2010
Par décret du Comité d'État de l'URSS sur les normes du 18 décembre 1978 n° 3350, la date d'introduction a été fixée
du 01/01/1980
1. Cette norme établit la composition et les exigences relatives au contenu du document de programme « Description du programme », défini par GOST 19.101-77.
La norme est entièrement conforme à ST SEV 2092-80.
2. La structure et la conception du document sont établies conformément à GOST 19.105-78.
La rédaction de la partie informationnelle (annotations et contenu) est obligatoire.
3. La description du programme doit contenir les sections suivantes :
informations générales;
objectif fonctionnel;
description de la structure logique ;
des données d'entrée;
sortir.
Selon les caractéristiques du programme, il est possible d'introduire des sections supplémentaires ou de combiner des sections individuelles.
4. Dans la section « Informations générales », les éléments suivants doivent être indiqués :
désignation et nom du programme;
logiciel nécessaire au fonctionnement du programme ;
langages de programmation dans lesquels le programme est écrit.
5. La section « Objectif fonctionnel » doit indiquer les classes de problèmes à résoudre et (ou) l'objectif du programme et des informations sur les restrictions fonctionnelles d'application.
6. Dans la section « Description de la structure logique », les éléments suivants doivent être indiqués :
algorithme de programme ;
méthodes utilisées;
structure du programme en décrivant les fonctions de ses éléments constitutifs et les connexions entre eux ;
connexion du programme avec d'autres programmes.
La description de la structure logique du programme est réalisée en tenant compte du texte du programme dans la langue source.
3-6. (Édition modifiée, amendement n° 1).
7. La section « Outils techniques utilisés » doit indiquer les types d'appareils informatiques électroniques utilisés lors de l'exécution du programme.
méthode d'appel du programme à partir du support de stockage correspondant ;
points d’entrée dans le programme.
Vous pouvez spécifier des adresses de téléchargement, des informations sur l'utilisation de la RAM et la taille du programme.
9. Dans la section « Données d'entrée », les éléments suivants doivent être indiqués :
nature, organisation et préparation préliminaire des données d'entrée ;
format, description et méthode de codage des données d'entrée.
10. Dans la section « Données de sortie », les éléments suivants doivent être indiqués :
nature et organisation des données de sortie ;
format, description et méthode de codage des données de sortie.
11. Il est permis d'illustrer le contenu des sections avec des exemples explicatifs, des tableaux, des diagrammes, des graphiques.
12. Dans l'annexe à la description du programme, il est permis d'inclure divers matériaux qu'il est inapproprié d'inclure dans les sections de la description.
7-12. (Introduit en plus, amendement n° 1).