L'élaboration des spécifications techniques conformément à GOST 34 est simple et facile

Souvent, vous entendez l'opinion selon laquelle la préparation du mandat conformément à GOST 34 (TK) est non seulement laborieuse, mais aussi extrêmement ennuyeuse, car vous devez écrire beaucoup de toutes sortes de bêtises, de l'eau. Mais pensez-y: des instituts de recherche entiers ont été engagés dans le développement de ce GOST, c'était un projet au niveau de l'État, l'expérience de centaines de projets d'automatisation, des projets complexes ont été résumés. Pourraient-ils vraiment écrire des bêtises?

En effet, avec une approche compétente, GOST aide grandement non seulement à l'élaboration des spécifications techniques, mais aussi lors de la mise en œuvre du projet d'automatisation dans son ensemble (et pas seulement dans les contrats d'État, mais aussi pour le développement commercial). Des lettrés l'ont écrit. Mais pour profiter des fruits de leur travail, il faut comprendre un peu le concept non seulement des savoirs traditionnels, mais aussi de GOST 34 dans son ensemble.

Dans cet article, nous analyserons point par point toutes les exigences de GOST et essayerons de faire du développement des savoirs traditionnels selon GOST 34 non pas un fardeau, mais une grande aide dans le projet.

1. De quoi parle l'article?

Souvent, vous entendez l'opinion selon laquelle la préparation du mandat conformément à GOST 34 (TK) est non seulement laborieuse, mais aussi extrêmement ennuyeuse, car vous devez écrire beaucoup de bêtises de toutes sortes, de l'eau. Mais pensez-y: des instituts de recherche entiers ont été engagés dans le développement de ce GOST, c'était un projet au niveau de l'État, l'expérience de centaines de projets d'automatisation, des projets complexes ont été généralisés. Pourraient-ils vraiment écrire des bêtises?

En effet, avec une approche compétente, GOST aide grandement non seulement à l'élaboration des spécifications techniques, mais aussi lors de la mise en œuvre du projet d'automatisation dans son ensemble (et pas seulement dans les contrats d'État, mais aussi pour le développement commercial). Des lettrés l'ont écrit. Mais pour profiter des fruits de leur travail, il faut comprendre un peu le concept non seulement des savoirs traditionnels, mais aussi de GOST 34 dans son ensemble.

Soit dit en passant, les savoirs traditionnels ne sont pas le premier document en cours d'élaboration au cours du projet d'automatisation. Cela est expressément indiqué au paragraphe 1.5. GOST 34.602-89: “Les savoirs traditionnels à la centrale nucléaire sont élaborés sur la base des données initiales, y compris celles contenues dans la documentation finale de l'étape“ Recherche et justification de la création de la centrale nucléaire ”. Pour plus de détails, voir mon article Enquête de pré-conception lors du développement d'un système d'information .

ATTENTION: L'OBJET DE CET ARTICLE N'EST PAS DE REMPLACER GOST ET D'EXPLIQUER CERTAINES DISPOSITIONS.

2. Caractéristiques caractéristiques des spécifications techniques conformément à GOST 34

2.1. Selon quelle norme les TdR sont-ils compilés?

Le nom complet de la norme pour les savoirs traditionnels selon GOST 34 est le suivant: GOST 34.602-89 “Information Technology (IT). Un ensemble de normes pour les systèmes automatisés. Les termes de référence pour la création d'un système automatisé. "

La norme elle-même n'est imprimée que sur 15 pages (oui, pas mal). La langue est russe, vraiment russe et non étrangère à l'alphabet cyrillique. Autrement dit, si vous ne vous rendez pas compte à l'avance que ni les textes de GOST, ni les lois fédérales, ni les dissertations ne sont accessibles à un simple mortel, il est tout à fait possible de lire et de pénétrer, bien que ce ne soit souvent pas la première fois.

En effet, la norme utilise de nombreux termes obscurs. Qu'entend-on par exemple par soutien linguistique? Pour clarifier les concepts utilisés, il faut se tourner vers GOST 34.003-90 «Technologies de l'information (TI). Un ensemble de normes pour les systèmes automatisés. Systèmes automatisés. Termes et définitions. "

2.2. Pourquoi avez-vous besoin de GOST pour le mandat?

Probablement, lorsque vous devez composer un nouveau document pour vous, vous recherchez un modèle pour un tel document sur Internet ou le demandez à vos collègues. Donc, TOUTE norme pour les documents ou les processus est un modèle. De plus, le modèle simplifie grandement le développement du document: la structure et le contenu ont déjà été pensés pour vous, en plus, un tel modèle prend en compte des moments dont vous ne vous seriez pas souvenus.

2.3. Quel rôle joue le mandat dans le projet?

Selon le paragraphe 1.7 de la norme RD 50-682-89, "le cahier des charges est le document principal selon lequel s'effectue la création de l'UA et l'acceptation par le client". Et c'est vraiment le document principal. Il doit décrire tout ce qui est nécessaire pour le développement et la mise en œuvre du système.

Le mandat établit l'aspect général du système, la quantité de travail (cadre de développement), ainsi que la procédure de développement et d'acceptation. Tout commence par les savoirs traditionnels et tout se termine avec. Ce document est idéal pour que votre client comprenne l'importance et la complexité de la tâche et pourquoi il paie de l'argent.

De plus, les spécifications techniques sont compilées pour l'entrepreneur et le client, car le projet d'automatisation est réalisé par des équipes des deux côtés. Dans tout projet informatique, il existe un grand nombre d'activités organisationnelles, dont la mise en œuvre est impossible sans la participation active du client. Expliquez cela aux clients à chaque occasion, sinon ils ont l'impression qu'ils n'ont qu'à payer de l'argent et s'asseoir droit: les gars embauchés feront tout. Et puis le projet échoue et l'épreuve de force commence. En général, sans une vraie équipe, par contre, ça ne vaut pas la peine de démarrer un projet.

Ne formulez pas officiellement les savoirs traditionnels. Si vous ne savez pas quoi écrire, cela signifie qu'il est trop tôt pour développer des savoirs traditionnels, vous n'avez pas une compréhension du système, le processus automatisé lui-même, l'objet d'automatisation, ne sont pas encore compris. Vous devez élaborer un concept du système , nous en avons parlé au tout début de l'article.

2.4. Quel âge ont GOST 34.602-89 et existe-t-il des normes plus récentes?

Pas aussi obsolète. J'étais presque incapable de trouver des choses non essentielles. Et aucun de ceux qui prétendent que GOST 34 est obsolète ne peut pas donner un seul exemple (probablement juste qu'il n'avait pas les qualifications pour le lire?) Le fait est que GOST décrit une approche générale du projet d'automatisation, il ne parle pas de programmation, GOST 34 n'est pas à ce sujet.

Eh bien, si nous parlons de comparaison avec d'autres normes, il n'y a rien de spécial à comparer. GOST 34 offre une vue tellement large du projet d'automatisation que d'autres normes ne conviennent pas à la semelle extérieure (à mon avis). Oui, ils sont plus simples (donc plus populaires), mais la profondeur n'est pas la même. Voici une liste de normes avec lesquelles vous devez vous familiariser lorsque vous développez vos propres normes pour un projet d'automatisation:

• IEEE 830-1998. Méthodologie de compilation des spécifications des exigences logicielles.
• GOST R ISO / IEC 12207-2010. Technologie de l'information. Génie système et logiciel. Processus du cycle de vie du logiciel.
• ISO / CEI / IEEE 29148-2011. Ingénierie des systèmes et du logiciel - Processus du cycle de vie - Ingénierie des exigences.
• GOST R 54869-2011. Gestion de projet. Exigences de gestion de projet.
• Puits et spécifications standard de la série 34.

3. Principes généraux pour l'élaboration des spécifications techniques conformément à GOST 34

3.1. Quel spécialiste devrait établir le mandat conformément à GOST 34?

Souvent, les développeurs jurent beaucoup lors de la rédaction des savoirs traditionnels selon GOST 34. Pourquoi? Oui, car ce n'est pas l'affaire des programmeurs. Les termes de référence conformément à GOST 34 ne peuvent généralement pas être montrés aux programmeurs. Il existe des documents techniques de projet pour cela. Termes de référence - un document qui est convenu avec le client, qui est constamment sur la table du chef de projet. TK répond à deux questions: QUE doit faire le système et COMMENT doit-il être créé. Le projet technique répond à la question: COMMENT répondre aux exigences des TdR. Par exemple, dans TK vous prescrivez qu'il devrait y avoir une autorisation par identifiant et mot de passe, et dans TP donnez les dispositions de l'interface, les scripts, la structure de la base de données. Pourquoi il y a une division en différentes étapes et pourquoi vous ne devriez pas immédiatement faire la tâche pour les programmeurs, voir dans mes articles les secrets de la conception réussie de l'IP (système d'information) sur l'exemple de la construction d'un hôpital et la préconception lors de l'élaboration d'un système d'information .

Le mandat doit être confié à un analyste métier, car il est «traducteur» entre le client et l'équipe de développement. La tâche d'un analyste commercial est de comprendre ce dont le client a besoin et de l'exprimer d'une manière claire pour l'équipe. Et l'exprimer sous forme de spécifications techniques. De plus, un analyste d'entreprise est tenu non seulement d'écouter le client et ses employés, mais aussi de découvrir ce qu'ils n'ont pas dit (et cela représente généralement plus de 50%). Par conséquent, l'analyste doit avoir une bonne connaissance des processus en cours d'automatisation et, en raison de ses connaissances, combler les lacunes qui subsistent après l'enquête.

3.2. De quel côté devrait être le mandat?

Fondamentalement, le mandat est compilé par l'entrepreneur? Pourquoi?

Non seulement parce qu'il est ainsi recommandé à l'annexe 1 de GOST 34-602-89. En fait, le client n'a généralement pas les spécialistes appropriés. Mais les savoirs traditionnels sont nécessairement développés et acceptés par le client. Et ici, il faut s'assurer que l'accord n'est pas formel. J'essaie toujours d'insister pour que nous analysions chaque article en détail avec le client. Votre objectif est d'impliquer le client dans le projet. Sinon, il ne formera pas ses attentes vis-à-vis du système, ce qui signifie, d'une part, qu'il sera insatisfait du résultat et, d'autre part, il ne pourra pas prendre les mesures organisationnelles nécessaires.

3.3. Jusqu'où pouvez-vous aller depuis GOST 34?

Tout modèle présente également un inconvénient important - il s'agit d'un modèle. C'est-à-dire qu'un pas à droite et à gauche est la mesure de protection sociale la plus élevée (comme la peine de mort était appelée auparavant).

En fait, ce n'est pas le cas. Toute norme de processus (c'est-à-dire une norme non pas pour la saucisse, mais pour une certaine activité) ne donne que des indications générales, un aperçu. Il a été créé pour ne pas oublier quelque chose d'important, pour vous transmettre l'expérience des générations et non pour vous conduire derrière les drapeaux.

Ne croyez pas? Lisez ensuite la clause 2.2 de GOST 34.602-89 (soit dit en passant, les chiffres après le tiret sont l'année de publication de la norme ou de son édition): «Selon le type, le but, les caractéristiques spécifiques de l'objet d'automatisation et les conditions de fonctionnement du système, il est autorisé de rédiger des sections de savoirs traditionnels sous la forme d'applications, introduire des informations supplémentaires, exclure ou fusionner des sous-sections des savoirs traditionnels. ” Toujours au paragraphe 1.2. La RD 34.698-90 déclare: «Le contenu des documents est commun à tous les types d'AS et, si nécessaire, peut être complété par le développeur des documents en fonction des caractéristiques de l'AS créé. Il est permis d'inclure des sections et des informations supplémentaires dans les documents, de combiner et d'exclure des sections. »

En général, si vous ne pouvez citer que des phrases générales, pour tout bien, contre tout mal, n'écrivez rien. Sinon, le spécialiste qui lit le document, après avoir rencontré de tels passages, cessera de prendre le document au sérieux et des points importants seront manqués. Ne faites pas de la lecture d'un document une torture!

3.4. Pourquoi les savoirs traditionnels selon GOST 34 décrivent-ils tant d'exigences qui ne sont pas directement liées aux fonctions du système?

En effet, dans un mandat de 30 pages, seules 7 à 10 pages peuvent être consacrées aux fonctions. Cela a une explication. Le fait est que les développeurs de GOST 34 ont examiné le projet d'automatisation d'une manière complètement différente de la nôtre. Et ils ont regardé plus correctement, plus complètement.

Premièrement , dans la première moitié des savoirs traditionnels, les informations générales sur le système et les exigences générales ne sont pas uniquement présentées. Nous devons comprendre pourquoi le système est créé, quels processus il automatise, ce qui doit être fait pour que le système fonctionne, quel type de système le système possède. Cela semble être des choses banales, mais sans elles, les membres de l'équipe comprendront différemment le but du travail et les moyens d'atteindre le but. Il est très important pour nous de nous assurer que tous les participants sont à l'écoute de la même vague, et non comme un cygne, un cancer et un brochet.

Deuxièmement , les compilateurs de GOST 34 considéraient le système principalement comme des personnes, puis comme un complexe matériel-logiciel. C'est ainsi que GOST 34.003-90 définit un système automatisé: "Un système composé de personnel et d'un ensemble d'outils d'automatisation pour ses activités qui met en œuvre la technologie de l'information pour effectuer des fonctions établies." Ainsi, un système d'information est un ensemble formé de personnel, de logiciel et de matériel. En effet, retirer les ordinateurs des comptables, ils sont difficiles, mais pourront faire leur travail, bien qu'avec des registres papier. Mais 1C ne fonctionnera pas de manière indépendante sans un comptable. D'où les nombreuses sections des savoirs traditionnels sur les mesures organisationnelles. Comme on dit, un système informatique est à 20% informatique, tout le reste est constitué de mesures organisationnelles. Autrement dit, TK est un document qui énonce tout le nécessaire pour la mise en œuvre du système, de A à Z.

Troisièmement , faites attention au nom de GOST 34.602-89: "Termes de référence pour la création d'un système automatisé". Les savoirs traditionnels ne sont pas destinés au système, mais à la création du système. Quelle est la différence? La différence est que le mandat établit non seulement les exigences pour le système lui-même, mais réglemente également le processus de sa création, c'est-à-dire que le document contient des exigences pour toutes les mesures organisationnelles, dont la mise en œuvre est nécessaire pour atteindre le résultat. En effet, lors de la mise en œuvre d'un projet d'automatisation, il est souvent nécessaire de restructurer un certain nombre de processus, de former du personnel et de préparer le matériel.

Quatrièmement , le mandat est un document par lequel vous pouvez cocher: avons-nous pris en compte cette exigence ou non? Peut-être que vous mettez automatiquement 10 ticks proprement, car ce seront des solutions standard. Mais la coche numéro 11 révélera un très gros problème, et si vous sautez ce problème maintenant, il apparaîtra quelque part dans le processus de mise en œuvre, lorsque tous les délais et budgets sont déjà définis.

Cinquièmement , comme nous l'avons dit ci-dessus, des sous-sections inutiles peuvent être exclues, cela est autorisé. Par exemple, si vous savez avec certitude que rien ne peut être breveté dans vos conceptions, alors pourquoi imposer des exigences de pureté des brevets? Ce n'est pas le cas lorsqu'il n'y a pas d'eau et pas de syud sans eau.

3.5. Pourquoi les différentes sections disent-elles la même chose?

En effet, dans les savoirs traditionnels, il existe des sous-sections qui reprennent en grande partie le contenu des autres sous-sections. Par exemple, il y a des exigences pour le soutien organisationnel et pour le nombre et les qualifications du personnel. Dans les deux paragraphes, nous parlons du personnel.Mais dans le premier cas, nous fournissons des informations sur la structure organisationnelle: quels départements devraient être, comment l'interaction avec les autres départements devrait être établie. D'accord, ce n'est pas du tout la même chose que simplement les exigences concernant le nombre et les qualifications du personnel.

Mais pour les petits systèmes, seuls un ou deux administrateurs et quelques modérateurs sont nécessaires. Dans ce cas, nous n'avons tout simplement rien à décrire dans deux sections entières. Omettez ensuite certaines sections et, dans l'autre, donnez un énoncé complet des exigences.

3.6. Dois-je émettre des savoirs traditionnels de manière qualitative?

Bien que les exigences pour la conception des savoirs traditionnels soient données au paragraphe 3 de GOST 34.602-89, disons quelques mots sur cet aspect.

Bien sûr, le contenu principal. Mais, d'une part, ils sont accueillis par des vêtements, et d'autre part, il est difficile de lire un texte analphabète avec une police à sauter. Les lecteurs seront distraits par une conception de mauvaise qualité et il leur sera plus difficile de se plonger dans le contenu. Par conséquent, un contenu technique strict et une terminologie limitée sont acceptés dans les documents techniques, sans expressions colorées: le lecteur doit se concentrer sur l'essence et non sur les tournants artistiques.

Voici quelques suggestions pour l'exécution de gros documents, comme les savoirs traditionnels.

Tout d'abord, il est impératif d'utiliser des styles dans un document volumineux et, sauf pour souligner ou mettre en surbrillance à l'intérieur d'un paragraphe, ne modifiez pas les paramètres de police et de paragraphe pour un seul fragment. Si vous changez, alors le style.

Deuxièmement , nous ne devons pas oublier des éléments obligatoires tels qu'une table des matières à saisie semi-automatique, une liste de termes et d'abréviations (enfin, il n'y a pas de plaisir à deviner ce que l'on entend par telle ou telle abréviation), la page de titre. Il est également conseillé de fournir une liste des versions du document, une liste des modifications: il est très facile de suivre plus tard les dates d'envoi d'une version particulière.

Quatrième, chaque exigence individuelle doit être énoncée dans un paragraphe numéroté distinct. S'il y a 2-3 exigences dans un fragment, alors seul le premier est lu et notre cerveau saute le reste. TK est un document dans lequel, devant chaque paragraphe, vous pouvez vérifier si l'exigence est remplie ou non.

Cinquièmement , ne lésinez pas sur le placement des liens. Parfois, vous lisez un paragraphe où une fonction ou une exigence est mentionnée, et vous ne comprenez pas, il s'agit du même document ou d'un autre. Si à partir de cela, alors dans quelle section. Par conséquent, essayez de vous référer à d'autres sections si elles sont mentionnées dans le texte actuel. Naturellement, les liens doivent être automatiques.

Notez que, selon des règles strictes, l'énoncé des travaux est établi sans cadre (cela est indiqué au paragraphe 3), mais le reste des documents avec un cadre. Ceci est établi dans GOST 24.301-80 «Système de documentation technique pour ACS. Exigences générales pour la mise en œuvre des documents texte (tel que modifié n ° 1, 2). " Cette norme établit les règles d'exécution de tous les documents, à l'exception des savoirs traditionnels et des documents créés au stade de la préconception. Bien que personnellement, je n'aime pas le cadre dans les documents.

4. Section 1. «Informations générales» / p. 2.3 GOST 34.602-89 /

La plupart des informations présentées dans cette section n'ont pas besoin de commentaires, nous nous concentrerons donc uniquement sur certaines sous-sections.

Ainsi, par «liste des documents sur la base desquels le système est créé», nous entendons des lois, des ordonnances ou un accord. En outre, un tel document peut être un autre savoir traditionnel, si nous développons des savoirs traditionnels pour le sous-système. En général, il y a plusieurs sections dans les TdR qui contiennent une liste de documents, et il faut très clairement comprendre les différences entre le but de ces parties de la tâche technique.

Dans la sous-section "Procédure de traitement et de présentation au client les résultats des travaux sur la création du système (ses parties), sur la fabrication et la mise en service d'outils individuels (matériel, logiciel, information) et logiciels et matériel (logiciel et méthodologie) complexes système" fournit des informations générales sur l'acceptation du travail. Par exemple, le fait que nous transférons la documentation et effectuons une série de tests système. Ici, nous ne mentionnons que la procédure de transfert des résultats des travaux, et ci-dessous, dans d'autres sections, ce sujet est décrit en détail.

5. Section 2. «But et objectifs de la création (développement) du système» / p. 2.4 GOST 34.602-89 /

Ici, nous devons comprendre la différence entre le but et le but de la création d'un système. Très souvent, ces concepts sont confus. Par exemple, ils écrivent que le but du système est l'automatisation de votre compte personnel et le but est de créer un compte personnel. L'huile est l'huile. Dans certains cas, ces concepts coïncident vraiment, alors n'écrivez que le rendez-vous.

Dans le but, tout est clair: nous donnons exactement le (s) type (s) d'activité automatisée. Par exemple, si nous créons un système de comptabilité de production, il vaut la peine de citer les types de comptabilité automatisés, les opérations automatisées, ainsi que les objets dont l'automatisation est supposée.

Avec l'objectif, tout est différent. Le but est ce pour quoi nous planifions un projet. Vous pouvez appeler cela des objectifs commerciaux. Je souligne les objectifs possibles suivants pour les projets d'automatisation:

1. ( , ..)
2. (, -, , ).
3. ( , , ).
4. : , .
5. , . , , «», .

Le GOST indique également qu'il est nécessaire de fournir des critères pour évaluer la réalisation de l'objectif, c'est-à-dire des indicateurs spécifiques. Par exemple, nous avons 3 personnes qui collectent un total de 20 commandes par jour. Et après la mise en place du système, nous voulons que chacun recueille 20 commandes, soit trois fois plus. Si de tels indicateurs y sont connus, nous les présentons dans ce paragraphe.

6. Section 3. "Caractéristiques de l'objet d'automatisation" / p. 2.5 GOST 34.602-89 /

Une section très importante et souvent souvent formellement décrite. Bien que, à mon avis, il s'agit de la section la plus importante des savoirs traditionnels, sans elle, nous ne comprenons tout simplement pas sur quoi le système est créé.

Définissons d'abord ce qu'est un «objet d'automatisation». Si nous automatisons un entrepôt ou une usine, un service de comptabilité, alors tout est clair. Et si, par exemple, nous créons un nouveau réseau social, alors l'objet, pour ainsi dire, n'existe pas. Mais en fait, un objet est plus susceptible de signifier des processus automatisés. Et même dans le cas d'un entrepôt, nous n'automatisons pas l'entrepôt lui-même (comment automatiser le stockage des cartons?), Mais les processus d'entrepôt.

Si vous effectuez cette section de manière formelle, elle sera très similaire à la description de l'objectif du système, et un autre lac d'eau apparaîtra dans le mandat, mais il ne sera pas clair ce que le système devrait faire.

Cette section devrait comprendre:

1. Description du client: activités du client, nombre d'agences, employés. Bien sûr, vous devez caractériser le client dans la partie directement liée au système en cours de création.
2. Informations sur les utilisateurs du système: types d'utilisateurs, quel rôle le système joue pour différents utilisateurs.
3. Description des objets automatisés. Par exemple, si nous automatisons un entrepôt, nous devons décrire combien il est, combien de passerelles, quelle largeur de passerelles, quels rayonnages, s'il y a une zone de montage séparée, combien de personnes travaillent et quelles sont leurs responsabilités. Ensuite, nous comprendrons que nous automatisons spécifiquement à quoi devrait ressembler le processus d'entrepôt et quel équipement est utilisé.
4. Description des processus automatisés. Bien sûr, il n'est pas nécessaire de décrire les processus en détail dans les savoirs traditionnels. Mais des scénarios communs sont nécessaires. Ce n'est qu'à ce moment qu'il nous apparaît clairement quelles fonctions devraient être disponibles.
5. Une liste de documents qui fournissent une description détaillée de l'objet d'automatisation.

J'ai eu des cas où la description de cette section a pris plus de la moitié du développement des savoirs traditionnels, car il faut beaucoup de temps et méticuleusement pour collecter différentes informations, les analyser et les décrire soigneusement.

7. Section 4 «Configuration requise»

Dans les savoirs traditionnels selon GOST 34, il y a une section gigantesque: la section 4 «Configuration requise». Il comprend trois sous-sections:

• Exigences pour le système dans son ensemble.
• Conditions requises pour les fonctions (tâches) exécutées par le système.
• Exigences pour les types de garanties.

Nous examinerons ces sous-sections séparément.

7.1. Sous-section 4.1. "Configuration requise pour le système dans son ensemble" / p. 2.6.1 GOST 34.602-89 /

Dans la sous-section 4.1 «Exigences pour le système dans son ensemble», les exigences générales dites non fonctionnelles sont décrites et décrivent le système créé sous différents angles.

Soit dit en passant, comme nous l'avons déjà mentionné, des sous-sections peuvent être ajoutées et omises. Par conséquent, la numérotation donnée ici est approximative et sert d'orientation dans l'article.

7.1.1. Clause 4.1.1. "Exigences pour la structure et le fonctionnement du système" / p. 2.6.1.1 GOST 34.602-89 /

Cet élément est assez étendu, il devrait donner une idée générale de l'architecture du système. Nous analyserons ces exigences plus en détail.

1. La liste des sous-systèmes, leur objectif et leurs principales caractéristiques, les exigences concernant le nombre de niveaux de hiérarchie et le degré de centralisation du système.

Dans ce paragraphe, je cite généralement:

• ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
• .

Si vous prévoyez une architecture de microservice, il est logique de répertorier et de décrire la fonctionnalité des services.

Pour plus de clarté, il est souhaitable de joindre un schéma structurel du système avec la désignation de ses pièces et des systèmes associés, comme indiqué dans les exemples ci-dessous.



... ou plus:



2. Exigences concernant les méthodes de communication et les moyens d'échange d'informations entre les composants du système.

3. Exigences relatives aux caractéristiques de la relation du système créé avec les systèmes associés, exigences de sa compatibilité, y compris des instructions sur la façon d'échanger des informations (automatiquement, envoi de documents, par téléphone, etc.)

Dans les conditions modernes, la plupart des interactions sont effectuées à l'aide du protocole HTTP (S). Il semble, à part cela, qu'il n'y a rien à écrire. Cependant, ces éléments peuvent être si volumineux qu'ils sont soumis à la demande. Ils doivent fournir les informations suivantes:

• une liste des informations transmises, au moins une description générale, pour comprendre généralement pourquoi nous nous intégrons à un système spécifique;
• description du protocole (ou liens de description), en particulier dans le cas de la connexion d'un périphérique;
• structure du réseau local;
• débit de données requis;
• utilisation de l'Internet mobile ou du WiFi;
• Description des méthodes de transmission de données non automatisées.

4. Conditions requises pour les modes de fonctionnement du système.
Les modes de fonctionnement peuvent avoir plusieurs classifications:

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• Visibilité de l'application: boîte de dialogue ou arrière-plan
• sur l'impact possible sur le système: régulier, formation, modes de test.

5. Conditions requises pour diagnostiquer le système.

Des exigences de diagnostic continu ou périodique doivent être établies pour les systèmes basés sur une architecture à microservices (espacés), des systèmes comprenant des équipements: capteurs, systèmes de contrôle, terminaux, etc. Bien sûr, si seul un logiciel développé sur un seul serveur est développé, ces exigences sont superflues: vous saurez si quelque chose ne fonctionne plus.

6. Perspectives de développement, de modernisation du système.

Il semble, quelles sont les perspectives d'évolution du système vers la sous-section «Exigences pour la structure et le fonctionnement du système»? Mais imaginez, vous créez maintenant une version alpha pour 100 personnes, et dans un an, vous voulez obtenir plus d'un million d'utilisateurs travaillant simultanément dans différentes parties du monde. Ensuite, au stade de la création, vous devez immédiatement prévoir une architecture de cluster.

Ou maintenant, vous travaillez dans une seule organisation et dans six mois, il y en aura plusieurs, ce qui signifie qu'il est nécessaire de prévoir à l'avance la possibilité d'une expansion.

En d'autres termes, dans cette section, vous pouvez noter toutes les perspectives de modernisation, mais surtout noter celles qui affecteront définitivement l'architecture.

7.1.2. Clause 4.1.2. "Exigences relatives au nombre et aux qualifications du personnel" / p. 2.6.1.2 GOST 34.602-89 /

Comme nous l'avons mentionné précédemment, tout système automatisé se compose de «personnel et d'un ensemble d'outils d'automatisation pour ses activités». Par conséquent, les exigences concernant le personnel et ses qualifications sont indiquées dans le mandat.

Si vous automatisez une ligne de production spécifique, vous connaissez le nombre d'employés. Mais dans de nombreux cas, cela dépend de la quantité de travail effectuée. Par conséquent, indiquez les postes, l'horaire de travail, la description des activités (pour l'attribution des droits d'accès) et les qualifications approximatives. Au minimum, vous avez besoin d'un administrateur système et d'un opérateur, souvent un modérateur. Il est possible que vous deviez prévoir plusieurs types d'opérateurs avec différents niveaux d'accès.

Il est clair que les exigences en personnel sont souvent fixées par le client, pourquoi alors les amener? Mais, d'une part, nous avons déjà dit que les spécifications techniques sont établies pour les deux parties, et d'autre part, l'entrepreneur sera protégé: la condition de sélection du personnel n'est pas remplie, que veut donc le client si le système n'est pas mis en œuvre?

7.1.3. Clause 4.1.3. "Exigences relatives aux indicateurs de performance" / p. 2.6.1.3 GOST 34.602-89 /

Dans cette sous-section, il est souvent écrit ce que vous aimez, car la liste des indicateurs possibles est manquante dans le texte GOST, et il est presque impossible de les trouver dans des sources ouvertes. Veuillez noter que le «degré d'adaptabilité», les «limites de modernisation» et les «caractéristiques temps-probabilité» donnés dans GOST sont, d'une part, indiqués pour ACS (système de contrôle automatisé) et, d'autre part, ils sont assez difficiles à mesurer. Ainsi, ces caractéristiques ne conviennent pas toujours.

Néanmoins, dans le texte lui-même, les «indicateurs de nomination» sont définis comme des «paramètres caractérisant le degré de conformité du système à sa finalité». Dans les systèmes informatiques modernes, les valeurs quantitatives caractérisant ce système concernent principalement les performances et le volume de stockage des données.

Les indicateurs de destination comprennent:

• le nombre d'utilisateurs travaillant simultanément dans le système;
• le nombre de requêtes exécutées simultanément sur le serveur;
• le nombre de transactions (enregistrées) par unité de temps des transactions;
• temps de réponse pour un nombre différent de demandes ponctuelles et d'utilisateurs actifs, pour une quantité différente de données traitées (en particulier lors de la recherche et de l'agrégation de rapports);
• quantité de données stockées (en particulier, images et vidéos);
• temps de connexion pour une puissance de calcul supplémentaire lorsque la charge maximale est atteinte;
• temps de connexion des capacités supplémentaires avec une augmentation significative du volume de données stockées.

Toutes ces caractéristiques affectent le choix du matériel serveur, du serveur d'applications et de l'architecture SGBD, des SGBD relationnels ou non relationnels, des microservices, etc.

7.1.4. Clause 4.1.4. "Exigences de fiabilité" / p. 2.6.1.4 GOST 34.602-89 /

Le texte de GOST décrit suffisamment en détail ce qui doit être indiqué dans les exigences de fiabilité. Néanmoins, pour comprendre l'approche visant à garantir la fiabilité inhérente à cette norme, vous devez étudier les GOST de la série 27. Pour commencer, vous devez vous familiariser avec la terminologie: cela suffira pour comprendre le concept même de fiabilité, comment il est mesuré et comment il est fourni. Par conséquent, reportez-vous à GOST 27.002-89. «Fiabilité technologique. Concepts de base. Termes et définitions. "

Le concept de base qui peut être appliqué aux systèmes automatisés est le facteur de disponibilité: 99%, 99,9%, 99,99%. Chaque nombre de «neuf» est fourni par certaines mesures.

Quelles solutions techniques ces exigences peuvent-elles affecter? Il s'agit du nombre de capacités de réserve (elles varient), de la disponibilité du personnel technique sur le terrain, et de l'utilisation non seulement d'alimentations sans coupure, mais aussi de générateurs diesel, ainsi que du raccordement à partir de deux sources indépendantes (raccordement aux réseaux électriques selon la catégorie de fiabilité I ou II).

7.1.5. Clause 4.1.5. "Exigences de sécurité" / p. 2.6.1.5 GOST 34.602-89 /

Cette sous-section décrit les exigences de sécurité pour la manipulation des équipements (installation, mise en service et fonctionnement). Maintenant, ces exigences sont appelées protection du travail et sont contenues dans les GOST de la 12e série (SSBT - le système de normes de sécurité du travail). En savoirs traditionnels, il suffit de donner une liste de ces sections, encore une fois, si quelqu'un va sérieusement s'engager dans la sécurité.

7.1.6. Clause 4.1.6. "Exigences d'ergonomie et d'esthétique technique" / p. 2.6.1.6 GOST 34.602-89 /

Nous donnons les exigences de GOST: «Les exigences d'ergonomie et d'esthétique technique incluent des indicateurs AC qui spécifient la qualité nécessaire de l'interaction humaine avec la machine et le confort des conditions de travail du personnel.

Habituellement, dans ce paragraphe, il est écrit que le système doit avoir une interface pratique et belle. Mais comment mesurer la commodité et la beauté? Par conséquent, soit nous omettons cette exigence, soit nous disons que l'interface correspondra à un projet de conception développé plus tard, soit nous fournirons des normes, par exemple, les soi-disant «lignes directrices» pour le développement d'applications mobiles: Material Design pour Android et Human Interface Guidelines pour iOS.

Vous pouvez également indiquer le nombre maximum de transitions (clics) lors de l'implémentation de certaines fonctions qui nous tiennent particulièrement à cœur, la vitesse moyenne de recherche des données, etc.

7.1.7. Clause 4.1.7. "Exigences de transportabilité pour les haut-parleurs mobiles" / p. 2.6.1.7 GOST 34.602-89 /

Dites une exigence obsolète. Désormais, les serveurs sur camions, comme les gros ordinateurs auparavant, ne transportent plus. Néanmoins, imaginez que vous ayez une sorte de superprotection, un circuit interne derrière la DMZ et ... la nécessité d'un travail à distance via un ordinateur portable. Oui, un VPN est configuré à tout moment, mais il vaut mieux qu'il soit reflété dans le Guide d'administration, et la possibilité elle-même est prévue par la configuration du réseau.

7.1.8. Clause 4.1.8. "Conditions de fonctionnement, d'entretien, de réparation et de stockage" / p. 2.6.1.8 GOST 34.602-89 /

Ces exigences concernent la maintenance d'un ensemble de moyens techniques (serveurs, pare-feu, commutateurs, postes de travail, etc.) Si l'équipement nécessite une maintenance particulière, il est nécessaire de le décrire dans cette section. Par exemple, vous disposez d'un appareil spécial qui doit être étalonné une fois par mois.

7.1.9. Clause 4.1.9. "Exigences pour la protection des informations contre les accès non autorisés" / p. 2.6.1.9 GOST 34.602-89 /

Le sujet de la protection des informations contre les accès non autorisés est assez vaste, tout comme les mesures visant à les garantir. Bien sûr, si nous parlons de l'accès au compte personnel du site Web et au panneau d'administration de ce site Web, il y a suffisamment d'exigences pour l'autorisation, la complexité du mot de passe, le modèle d'accès au rôle. Mais si un système financier ou un système est créé pour les besoins de l'État, des exigences spéciales apparaissent.

Il est important de noter que dans cette sous-section sont données non seulement les mesures qui doivent être appliquées pendant le développement du système, mais aussi son fonctionnement.

Ainsi, pour les systèmes financiers, vous devez utiliser la «norme de sécurité des données de l'industrie des cartes de paiement» (PCI DSS). Pour les systèmes dans lesquels des données personnelles sont stockées, - Décret du gouvernement de la Fédération de Russie du 01.11.2012 n ° 1119 «sur l'approbation des exigences de protection des données personnelles lors de leur traitement dans les systèmes d'information sur les données personnelles». Il peut y avoir d'autres normes dans votre domaine.

En général, les équipements de protection peuvent être divisés selon les types suivants:

1. Moyens fournis par le produit logiciel créé.
2. Mesures fournies par l'administrateur système.
3. Mesures de protection physique.
4. Mesures organisationnelles générales.
5. Mesures prises pendant le processus de développement logiciel.

1. Mesures de sécurité fournies par le produit logiciel créé:

• Mot de passe requis pour les utilisateurs, en particulier pour les utilisateurs ayant le rôle d'administrateur.
• Implémentation d'un modèle d'accès basé sur les rôles.
• L'obligation d'utiliser des clés de signature électronique pour effectuer des opérations critiques.
• Suppression des composants logiciels chargés d'interagir avec des systèmes externes dans la DMZ.
• Fournir l'enregistrement des événements et des actions des utilisateurs.

2. Mesures fournies par l'administrateur système:

• L'utilisation de pare-feu (pare-feu).
• Documenter et surveiller les services et protocoles utilisés.
• Configuration de la zone démilitarisée (DMZ).
• Suivi de la mise en œuvre des règles d'utilisation des ordinateurs portables: connexion à un réseau interne, utilisation de pare-feu.
• Désactiver les comptes par défaut avant de connecter l'équipement et les systèmes au réseau.
• Configurer les périphériques d'accès sans fil: définissez des mots de passe et modifiez les paramètres d'accès par défaut.
• Installez des mises à jour qui résolvent les vulnérabilités matérielles et logicielles identifiées.
• Assurer la sécurité de l'accès à distance au système (par exemple, en utilisant un VPN).
• Installation, mise à jour et surveillance de logiciels antivirus.
• Effectuez des analyses de réseau périodiques et des analyses après avoir apporté des modifications importantes.
• Attribution d'un compte unique à chaque employé, contrôles périodiques de la présence de comptes supprimés d'employés licenciés, changement de mots de passe. Emission et comptabilisation des jetons de signature électronique.
• Configurez les restrictions d'accès à la base de données.
• Contrôle de la synchronisation de l'heure sur tous les serveurs et postes de travail (afin d'assurer l'exactitude de l'heure enregistrée dans les journaux d'événements).
• Configurez les journaux des événements.
• Inventaire périodique des points d'accès sans fil et autres logiciels installés.

3. Mesures de protection physique:

• Accès restreint aux salles critiques.
• Débranchez les connecteurs réseau dans les lieux publics.
• Installation de caméras de vidéosurveillance pour les locaux critiques.

4. Mesures organisationnelles générales:

• Adoption d'une politique de sécurité et formation périodique du personnel aux règles de sécurité de l'information.
• Mettre en œuvre des procédures de réponse aux incidents de sécurité.
• Vérification d'écran ou rapports de données confidentielles.
• Délivrance de badges à tous les visiteurs, accompagnant les visiteurs dans les zones critiques.
• Examen complet des employés embauchés.
• Assurer la sécurité des organisations-fournisseurs de services liés aux logiciels et au matériel.

5. Mesures prises pendant le processus de développement logiciel:

• Contrôle des personnes responsables pour apporter des modifications au code du programme, vérifier la conformité du code avec les règles de sécurité de l'information (contrôle du débordement de la mémoire tampon, traitement correct des erreurs, vérification des scripts crossite, erreurs du mécanisme d'accès, etc.)
• L'utilisation d'une cryptographie forte.
• Application des règles de sécurité pour les applications Web publiques.
• Élaborez une procédure d'annulation pour chaque changement.
• Documentation des changements.

7.1.10. Clause 4.1.10. "Exigences de sécurité des informations en cas d'accident" / p. 2.6.1.10 GOST 34.602-89 /

Cette section fournit une liste des accidents et défaillances possibles dans lesquels la sécurité des informations doit être assurée. Ces événements peuvent inclure:

• perte de nutrition;
• panne du serveur;
• panne du périphérique de stockage (disque dur).

7.1.11. Clause 4.1.11. "Exigences de protection contre l'influence des influences extérieures" / p. 2.6.1.11 GOST 34.602-89 /

Cette section sera utile dans le cas de serveurs, postes de travail et autres équipements dans un entrepôt froid ou, à l'inverse, dans des locaux industriels à températures élevées, dans des endroits poussiéreux ou à forte humidité. Il vaut également parfois la peine d’envisager les vibrations, les radiations ou d’autres influences.

7.1.12. Sous-section 4.1.12. "Exigences de pureté du brevet" / p. 2.6.1.12 GOST 34.602-89 /

Si vous pensez que vous utiliserez une technologie brevetée dans d'autres pays (ou dans notre pays) et que le titulaire du brevet peut intenter une action contre le propriétaire du système, ce paragraphe indique la liste des pays dans lesquels vous souhaitez vérifier pour la pureté du brevet.

7.1.13. Clause 4.1.13. "Exigences de normalisation et d'unification" / p. 2.6.1.13 GOST 34.602-89 /

Cet élément est également rarement contenu dans les termes de référence en ce qui concerne spécifiquement les logiciels. Il indique à la fois les exigences pour l'utilisation de technologies spécifiques et les formes normalisées de documents et de classificateurs.

Cette description est particulièrement importante si vous avez des exigences spécifiques pour les frameworks, plugins, protocoles, appareils, algorithmes mathématiques, logiciels tiers, etc. utilisés. N'oubliez pas d'indiquer dans quelle partie et dans quel but ces outils doivent être utilisés.

De plus, parfois dans les systèmes de certaines classes, il est d'usage d'utiliser certains protocoles d'échange de données. Par exemple, les normes OCG sont utilisées pour échanger des données entre les systèmes d'information géographique, et l'OCPP est utilisé pour contrôler les bornes de recharge pour les véhicules électriques.

7.1.14. Clause 4.1.14. «Exigences supplémentaires» / p. 2.6.1.14 GOST 34.602-89 /

Ce paragraphe devrait se trouver dans le texte de GOST. Il n'a pas besoin de commentaires.

7.2. Sous-section 4.2. «Conditions requises pour les fonctions (tâches) exécutées par le système» / p. 2.6.2 GOST 34.602-89 /

Cette section est au cœur des systèmes informatiques modernes. En fait, le système est créé pour l'exécution de certaines fonctions. Souvent, les savoirs traditionnels, créés sur la base de normes étrangères et généralement sans normes, ne contiennent que cette section.

7.2.1. Structure de description fonctionnelle

Tout d'abord, nous considérons la structure des exigences fonctionnelles du système: sous-système - ensemble de fonctions - fonction - tâche. Une tâche fait partie d'une fonction et la tâche peut être décrite comme une fonction distincte. Par exemple, pour la fonction de connexion, nous introduisons un mot de passe comme l'une des tâches. Et nous pouvons décrire la procédure de saisie du mot de passe comme une fonction distincte: vérification de l'exactitude, récupération du mot de passe, affichage des invites, etc. Un complexe est ce qui unit les fonctions. Par exemple, «Comptabilisation des informations de base», «Tenue d'une enchère», etc. Le complexe a deux fonctions ou plus.

Si votre système se compose de plusieurs sous-systèmes, alors TK devrait donner une liste de fonctions pour les sous-systèmes, et déjà décrire en détail les exigences fonctionnelles pour les sous-systèmes dans les savoirs traditionnels individuels pour les sous-systèmes (ils sont souvent appelés CTZ maintenant - une tâche technique privée).

7.2.2. Types de fonctions en termes de mise en œuvre

En fait, toutes les fonctions (ou leurs tâches; plusieurs tâches peuvent être présentes dans une fonction à la fois) peuvent être divisées en les types suivants:

• Saisie d'informations. Parfois appelé «informations comptables».
• Sortie d'informations.
• Traitement automatique des informations.

7.2.3. Types de fonctions en fonction de leur rôle

Les fonctions peuvent être générales et spéciales. Les fonctions courantes, par exemple, incluent l'utilisation de listes d'objets, l'utilisation d'une carte d'objet et l'utilisation d'une carte interactive. Ces fonctions peuvent s'appliquer à toutes les fonctions spéciales ou à certaines fonctions spéciales.

7.2.4. Exigence, pas script

N'oubliez pas que le mandat contient des exigences pour le système et le processus de sa création. Pas des scripts. TK répond à la question QUE doit faire le système. À la question de savoir comment la conception technique répond. Si vous commencez à décrire en détail la mise en œuvre technique, alors plongez dans les détails et ne donnez pas une liste complète des exigences: notre cerveau ne peut pas fonctionner simultanément dans des modes de large couverture et de considération des détails.

La structure des fonctions du mandat et du projet technique peut différer considérablement: dans un scénario, plusieurs fonctions peuvent être mises en œuvre, et vice versa.

7.2.5. Exigences fonctionnelles

Voici quelques recommandations pour rédiger une description des fonctions:

1. Les exigences relatives aux fonctions et aux tâches doivent généralement être apportées à l'application. Ainsi, le document est organiquement divisé en parties non fonctionnelles et fonctionnelles. De plus, l'application peut toujours être imprimée et consultée séparément.
2. Évitez les gros paragraphes. Il est préférable que les exigences soient divisées en paragraphes et sous-paragraphes: il est plus facile de les percevoir et de contrôler leur mise en œuvre (cochez les cases). Si une liste d'exigences ou d'informations est fournie, qu'elle soit donnée par une liste numérotée ou à puces.
3. Pour les fonctions dont le but n'est pas évident d'après leur nom, il est nécessaire d'indiquer le but et le problème à résoudre. Sinon, même le compilateur TK risque d'oublier pourquoi il a décrit telle ou telle fonctionnalité.

7.2.6. Exemple de description de fonction

5.6. Immatriculation d'un véhicule dans le système

Les exigences suivantes sont présentées:

1) Le système doit permettre de prendre en compte les informations générales suivantes:

• marque d'enregistrement d'État (GRNZ);
• Nom du propriétaire;
• adresse du propriétaire;
• les données du service d'acquisition des données du véhicule (voir la clause 3.3, annexe B);
• note.

2) Le système devrait permettre de prendre en compte les informations suivantes relatives au paiement du prix (les informations spécifiées sont de nature informative, la possibilité de les modifier directement dans la carte d'immatriculation du véhicule n'est pas requise):

• classe de véhicule actuelle (voir la clause 3.3, annexe A);
• tarif actuel (voir la clause 5.1, annexe A);
• contrat en cours (voir clause 5.5, annexe A);
• classe de véhicule selon les informations fournies par le Ministère des affaires intérieures de la République du Kazakhstan;
• des informations sur le compte personnel et son état (voir clause 3.6, annexe A);
• des informations sur l'inscription au registre des véhicules à tarif réduit (voir clause 3.5, annexe A).

3) Le système doit permettre d'enregistrer et de modifier les informations sur le véhicule de la manière suivante:

• manuellement par l'opérateur;
• dès réception des informations du système d'enregistrement des étiquettes RFID (voir la clause 1.1, annexe B);
• lors de l'identification du véhicule à l'aide de la caméra GRNZ.

4) Lors de l'enregistrement d'un nouveau véhicule dans le système, le système doit demander des données sur le véhicule au service pour recevoir des données sur le véhicule (voir paragraphe 3.3, Annexe B). Il devrait être possible de mettre à jour les informations spécifiées d'un véhicule individuel.

7.3. Sous-section 4.3. "Exigences relatives aux types de sécurité" / p. 2.6.3 GOST 34.602-89 /

La section des exigences relatives aux types de soutien est généralement souvent citée comme exemple du volume excessif de savoirs traditionnels selon GOST. Quand il s'agit de savoir si toutes les sections et sous-sections doivent être données, elles rappellent le logiciel, pour lequel dans la plupart des cas, il n'y a tout simplement rien à écrire.

En fait, il s'agit d'une sous-section très importante, bien que tout le monde ne comprenne pas son objectif. Il décrit les conditions sans lesquelles il est impossible de réaliser le développement ou la mise en service. Ces conditions sont décrites comme des «garanties».

A la lecture de cette sous-section, on se demande ce que les rédacteurs de la norme entendaient par «logiciel», «logiciel linguistique», «logiciel d'information», etc. Les réponses doivent être recherchées dans GOST 34.003-90, où tous ces termes sont déchiffrés.

7.3.1. Article 4.3.1 "Logiciel" / p. 2.6.3.1 GOST 34.602-89 /

Imaginez la situation dont vous avez besoin pour créer un système dans lequel vous souhaitez implémenter le calcul automatique de l'itinéraire optimal. Le bouton «Calculer l'itinéraire» peut sembler simple, mais des algorithmes et des calculs mathématiques très complexes peuvent être derrière lui. Il est clair qu'il ne vaut pas la peine d'entreprendre le développement de tels algorithmes, des mathématiciens professionnels s'y sont engagés. Si de tels algorithmes sont disponibles, les exigences de leur développement ou de leur utilisation sont également écrites.

7.3.2. Clause 4.3.2 «Aide à l'information» / p. 2.6.3.2 GOST 34.602-89 /

En lisant la description de cette exigence dans le texte GOST, il semble que ce soit une répétition de ce qui a été dit dans d'autres sections. Par exemple, pourquoi décrire à nouveau les exigences de «composition, structure et méthodes d'organisation des données dans le système» et «d'échange d'informations entre les composants du système»? Mais nous oublions encore une fois que les compilateurs de GOST sous le système avaient non seulement des logiciels, mais aussi l'ensemble des mesures organisationnelles.

Lorsque vous vous présentez, vous rencontrez une situation telle que le client, pour sa part, n'a pas fourni d'opérateur qui entrera des données dans le système, et en même temps, il déclare que le système ne fonctionne pas. Une situation familière? Mais si l'obligation de fournir cette entrée était énoncée dans l'énoncé des travaux, il serait alors possible de pousser le client directement à ce stade. Ou vous avez besoin d'accéder à un classificateur d'adresses spécifique pour le travail, mais le client ne vous le donne pas.

Ainsi, dans ce paragraphe, il est logique de spécifier les exigences pour les informations entrantes et les informations transmises d'un composant à l'autre du système d'une manière non automatisée. Le traitement automatisé des informations, l'utilisation du SGBD, l'échange d'informations au sein du système sont décrits en détail dans d'autres sections.

7.3.3. Clause 4.3.3 «Support linguistique» / p. 2.6.3.3 GOST 34.602-89 /

Ce paragraphe prévoit:

• exigences pour l'utilisation des langages de programmation (s'il existe des préférences spécifiques);
• langue d'interface (quelles langues, interface multilingue);
• langue de communication entre les équipes de projet, exigences de traduction;
• autres caractéristiques d'entrée et de sortie des données, si disponibles: cryptage, méthodes non standard d'interaction de l'utilisateur avec le système.

7.3.4. Article 4.3.4 «Logiciel» / p. 2.6.3.4 GOST 34.602-89 /

Ce paragraphe fournit une liste des logiciels achetés, s'ils sont identifiés au stade de développement des TdR.

7.3.5. Clause 4.3.5 «Support technique» / p. 2.6.3.5 GOST 34.602-89 /

Tout système d'information ne peut fonctionner sans matériel, serveurs, réseaux, etc. Il est généralement conseillé de déterminer les caractéristiques spécifiques des équipements dans une conception technique, mais une composition approximative peut être indiquée dans l'énoncé des travaux afin que le client ait une idée des coûts futurs.

7.3.6. Clause 4.3.6 "Support métrologique" / p. 2.6.3.6 GOST 34.602-89 /

S'il est prévu de recevoir des données de capteurs dans le système, il est nécessaire de comprendre quels instruments de mesure seront utilisés, quels instruments de mesure de précision devraient fournir, si ces outils doivent être certifiés et certifiés.

7.3.7. Clause 4.3.7 «Soutien organisationnel» / p. 2.6.3.7 GOST 34.602-89 /

Imaginez que vous créez un système à partir de zéro. Par exemple, il s'agit d'un système de gestion d'entrepôt pour un nouveau complexe logistique. En d'autres termes, il n'y a que des murs. Ou vous mettez à niveau le système et pour mettre en œuvre les changements dont vous avez besoin pour modifier la structure organisationnelle. Dans de tels cas, vous devez spécifier les conditions concernant l'organisation des processus dans lesquels le système fourni par vous fonctionnera réellement.

7.3.8. Clause 4.3.8 "Support méthodologique" / p. 2.6.3.8 GOST 34.602-89 /

Parfois, pour gérer le système, du personnel ayant des compétences particulières est requis. Dans ce cas, une liste de méthodes, de normes et de standards doit être fournie dans le mandat, avec laquelle les employés qui interagissent avec le système doivent être familiarisés.

7.3.9. Autres types de garanties

Lors du développement de chaque nouveau TK, vous devez considérer ce dont vous aurez besoin pour une mise en service réussie. Par exemple, j'écris souvent des exigences pour le soutien juridique, lorsque le cadre juridique utilisé n'est pas entièrement défini et que son développement peut affecter la mise en œuvre. Bien qu'il soit préférable de résoudre ces problèmes avant de rédiger les spécifications techniques .

8. Section 5 «Composition et contenu des travaux sur la création (développement) du système» / p. 2.7 GOST 34.602-89 /

Cette section est organisationnelle et est souvent insérée dans le contrat. Cependant, ces informations dans les TdR peuvent être spécifiées.

Il s'agit essentiellement d'un court plan de développement et de mise en œuvre. Lors de sa compilation, je donne généralement un tableau qui répertorie tout ou partie des colonnes suivantes:

• Le nom de l'étape (sous-étape).
• Contenu du travail (brève description, liste des tâches).
• Le résultat du travail (documents approuvés, solutions développées et soumises).
• Conception, documentation de travail ou de rapport.
• Responsable (qui exécute ce travail: client, entrepreneur ou autre personne). Si les deux parties doivent donner un résultat commun, les rôles sont indiqués.
• Durée (dates, dates, début du chronométrage).

Un exemple du contenu de cette section est donné dans le tableau ci-dessous.

9. Section 6 «Procédure de suivi et d'acceptation du système» / p. 2.8 GOST 34.602-89 /

Cette section décrit en détail le processus d'acceptation du système par le client: quels tests doivent être effectués, ce qui sera inclus dans ces tests, selon quels documents seront testés, comment les commentaires seront établis et éliminés.

9.1. Sous-section 6.1. «Types, composition, volume et méthodes d'essai du système et de ses composants» / p. 2.8.1 GOST 34.602-89 /

Habituellement, j'indique ici la liste des tests et mentionne que les méthodes de test seront données dans le document "Programme et méthodologie de test", qui est une description des principaux cas de test, les scripts de test.

Arrêtons-nous sur les types de tests. Les types de tests, leur composition, les exigences relatives aux documents sont établis par GOST 34.603-92 «Technologies de l'information. Types de tests de systèmes automatisés. " Par conséquent, lors du développement de cette section et de ce projet technique, assurez-vous de vous référer à cette norme, nous n'expliquerons ici que les principaux points.

Essayons de comprendre quels types de tests sont:

1. Les tests sont divisés en les types suivants:

• Préliminaire.
• Opération d'essai.
• Acceptation.

2. Les tests préliminaires (et partiellement acceptés) sont à leur tour divisés en:

• ( ).
• ( ).

Pourquoi les tests sont-ils divisés en différentes étapes? Premièrement, parce que GOST 34.603-92 ne fait pas de distinction entre l'acceptation interne et externe, une partie des tests peut être effectuée sans client. Deuxièmement, un processus de test séquentiel est décrit, partie par partie, puis tout est intégré.

Essayons de décrire le processus de test avec des mots simples:

1. Tests autonomes préliminaires de parties du système. Certaines parties du système sont testées individuellement s'il existe plusieurs sous-systèmes ou modules de grande taille dans la composition. En règle générale, ces tests sont effectués de manière autonome, c'est-à-dire sans intégration avec les systèmes adjacents. Si le système est simple, cette étape peut être ignorée en toute sécurité.

2. Tests préliminaires autonomes du système dans son ensemble.L'ensemble du système est testé dans un complexe en mode autonome, c'est-à-dire sans intégration avec les systèmes adjacents. Les fonctions associées aux systèmes adjacents ne sont pas testées. Dans un cas extrême, des «stubs» sont mis (émulation de l'intégration) ou la base de données est pré-remplie avec des données qui doivent provenir de sources externes.

3. Tests préliminaires complets. Le système est testé de manière intégrée, c'est-à-dire en interaction avec les systèmes adjacents. Sous cette forme, le système est transféré au client pour un essai.

4. Opération pilote.MA peut avoir lieu dans différents modes. La meilleure chose est l'exploitation sur des données réelles, avec de vrais utilisateurs et avec de vraies tâches. Seul ce type de test garantira que le système est réellement opérationnel. Pendant l'opération d'essai, les inconvénients sont éliminés.

5. Tests d'acceptation. C'est le dernier type de chèque. Dites-moi, pourquoi l'opération d'essai après avoir éliminé toutes les lacunes ne se fera pas en douceur dans l'industrie? Cela arrive donc généralement. Mais les grands oncles ont besoin de voir que le système fonctionne vraiment, de le "sentir". Des tests d'acceptation leur sont destinés, pour une haute commission. Ainsi, les tests d'acceptation diffèrent des tests préliminaires principalement par le statut de la commission.

Dans ce paragraphe, les documents indiquent également les méthodes d'essai qui seront données:

• « () ». . — 34.603-92 (. 2.2.2 4.1) — 50-34.698-90 « . . . . ».
• « », . 3.1 34.003-90. « » (. . 3.2 34.603-92), .

9.2. Sous-section 6.2. "Conditions générales d'acceptation des travaux par étapes" / p. 2.8.2 GOST 34.602-89 /

Dans cette section, j'indique généralement:

1. Sur le territoire et sur l'équipement duquel les tests seront effectués: le client ou le contractant.
2. Une description générale de la façon dont les tests seront menés (par exemple, que les documents seront vérifiés, la présence d'éléments d'interface utilisateur, les scripts sont élaborés).
3. Liste des participants.
4. La liste des documents qui établissent le résultat du test:
   
   
   • Pour les tests préliminaires et d'acceptation, il s'agit d'un rapport de test qui fournit une liste des contrôles et de leurs résultats.
   • Pour une opération d'essai - un journal d'opération d'essai.

10. Section 7 «Exigences relatives à la composition et au contenu des travaux de préparation de l'objet d'automatisation pour la mise en service du système» / p. 2.9 GOST 34.602-89 /

Le processus décrit dans cette section est souvent appelé mise en œuvre. Veuillez noter que ces travaux sont également donnés dans la section 5 «Composition et contenu des travaux sur la création (développement) du système» . Mais, dans la section 5, ils ne sont que brièvement mentionnés, et une description détaillée est donnée ici.

Lors de la préparation d'un objet, en règle générale, les travaux suivants doivent être effectués:

1. Réorganisation, recrutement de nouveaux collaborateurs, si nécessaire.
2. Formation du personnel.
3. Pour les applications web: développement de sections communes du site et accord d'utilisation (consentement au traitement des données personnelles).
4. Remplissage des répertoires et autres informations générales.
5. Transférez les données de l'ancien système.
6. Déployer le système sur des serveurs industriels.
7. Configurez l'intégration avec les systèmes adjacents.
8. Mise en place d'un système d'accès et création de comptes.

Certains de ces points doivent être décrits en détail, notamment en ce qui concerne le transfert de données et le remplissage de répertoires.

11. Section 8 «Documents requis» / p. 2.10 GOST 34.602-89 /

Pas la peine se réfère formellement aux documents. Documents - c'est la gestion de projet, le flux de travail du projet. Vous ne tiendrez pas tout dans votre tête et le succès du projet dépend de la disponibilité et de la qualité des documents. Bien sûr, il existe des documents «pour le poids», et ils doivent être traités en conséquence, mais sans document de manière calme et ordonnée, le projet ne peut pas être mis en œuvre.

La documentation du projet d'automatisation conformément à GOST 34 est réglementée par les normes suivantes:

• GOST 34.201-89 Types, exhaustivité et désignation des documents lors de la création de systèmes automatisés.
• RD 50-34.698-90 Directives. Technologie de l'information. Un ensemble de normes et de directives pour les systèmes automatisés. Systèmes automatisés. Exigences relatives au contenu des documents.
• Pour le mandat - GOST 34.602-89, dont nous discutons maintenant.

La première norme (GOST 34.201-89) fournit une liste et une structure de documentation. Dans la seconde - RD 50-34.698-90 - le contenu des documents suivants est indiqué:

• Documents de l'avant-projet et des projets techniques.
• Documents élaborés aux étapes de la pré-conception.
• Documents organisationnels et administratifs (actes, protocoles, etc.)

11.1 Caractéristiques de la structure de documentation

Lors de la compilation d'une liste de documents nécessaires, ils regardent généralement le RD 50-34.698-90 et sélectionnent ceux requis. Dans le même temps, beaucoup d'erreurs sont commises, car la documentation a une structure assez compliquée, qui est décrite dans GOST 34.201-89.

Essayons d'identifier quelques règles qui aideront à compiler une liste de documents.

1. Chaque étape a sa propre documentation.

Chaque étape a son propre ensemble de documentation. C'est très important à comprendre. Il n'est pas nécessaire de prescrire l'élaboration de documents opérationnels aux stades de la conception et vice versa. Il s’agit d’un document purement formel, que vous passerez un temps considérable. Et si le «Guide de l'utilisateur» jusqu'à la fin du développement du système, généralement personne ne rédige (bien que j'aie également rencontré de tels chiffres), alors la «Description des fonctions automatisées», qui contient généralement des scripts pour les programmeurs, est constamment compilée après la fin du développement. De plus, en lisant RD 50-34.698-90, on peut avoir l'impression que certains documents ont un contenu qui se chevauchent: cela est également dû au fait que les documents sont destinés à différentes étapes.

Étant donné que certains documents peuvent être développés à un stade ou à un autre, GOST 34.201-89, pour éviter la répétition, fournit séparément, par exemple, une liste de documents pouvant être délivrés à la fois au stade de la conception technique et de la documentation de travail, et séparément, des listes de documents chacune de ces étapes séparément. Ainsi, lors de la compilation d'une liste de documents pour l'une des étapes, vous devez parcourir les listes de documents dans plusieurs sections de la norme.

Afin de ne pas être confus, j'ai compilé une feuille de calcul Excel dans laquelle, à l'aide de filtres, vous pouvez immédiatement afficher une liste complète des documents pour une étape particulière.

2. Les documents sont divisés en thèmes (parties du projet).

GOST 34 contient des documents décrivant les solutions à l'échelle du système, ainsi que le support organisationnel, technique, mathématique, logiciel et informationnel (nous avons parlé des types de support ci-dessus ). Dans le RD 50-34.698-90, ces documents sont fournis précisément avec une ventilation par parties du projet (thèmes). Vous devez toujours y prêter attention afin de déterminer l'objectif du document.

3. Les documents peuvent être combinés.

GOST 34.201-89 indique directement dans quels cas un document est inclus dans un autre. Ceci est fait de sorte qu'il ne reste aucun document dégénéré, avec une ou deux pages. Si quelque chose doit être décrit, mais que le volume est très petit, il est préférable d'inclure le texte dans un autre document. Dans la plupart des cas, il existe un document tel que «Note explicative sur la conception technique», dans lequel vous pouvez ajouter des sections.

4. Les estimations de fonctionnement et de conception sont mises en évidence séparément.

Les compilateurs de GOST 34.201-89 dans des colonnes séparées du tableau avec une liste des documents indiqués appartenant aux estimations opérationnelles et de conception.

Les devis de conception comprennent des documents régissant la construction et les travaux électriques: devis, plans d'approvisionnement, dessins et schémas électriques.

Les documents opérationnels comprennent les documents qui guident l'utilisation et la maintenance du système: manuels et instructions, listes de matériels et données, documents contenant des informations sur les violations en cours de fonctionnement.

11.2 Caractéristiques de la conception de la liste des documents

Comme vous l'avez noté précédemment, lorsque vous décrivez les étapes du travail dans la section 5, «Composition et contenu du travail pour créer (développer) un système» , une liste de documentation est également fournie. Une double liste de documents est fournie pour une raison simple: il ne suffit pas d'indiquer le nom du document, il faut tout de même en expliquer la finalité et en fournir un bref résumé (bien entendu, pour le «Guide de l'utilisateur» cela n'a pas de sens d'en indiquer le contenu). Sinon, il ne sera pas en mesure de déterminer l'importance d'un document particulier dans la gestion de projet. GOST est un invité, et sur chaque projet, le contenu et le rôle des documents peuvent différer. En outre, la liste peut contenir des documents qui ne sont pas réglementés par GOST 34, qui doivent être clarifiés sans faute.

Dans les règles de documentation, je donne généralement un tableau avec les colonnes suivantes:

• Stage.
• Le nom du document.
• Remarque: indique la norme de développement, le but, le résumé et les principales caractéristiques du document.

11.3 Exemple de liste de documentation

Pour qu'un grand projet implémente un système complexe, une liste assez importante de documentation peut être requise. Nous donnons un exemple d'une telle liste dans le tableau ci-dessous.

12. Section 9 "Sources de développement" / p. 2.11 GOST 34.602-89 /

Il semble que ce soit une section formelle, mais très utile. Imaginez une situation où vous vous souvenez qu'au cours du développement des savoirs traditionnels, vous lisez un article, et pour une raison quelconque, vous devez le trouver, par exemple, pour clarifier quelque chose ou justifier vos décisions. Mais vous ne vous souvenez absolument ni de son nom ni de l'endroit où il était contenu. Par conséquent, lorsque j'utilise des documents utiles, assurez-vous de les mettre sur la liste. Et dans le texte, j'ai mis une note de bas de page indiquant la source.

S'il existe de nombreuses sources, elles doivent être divisées en sous-sections, par exemple:

• Matériaux décrivant des analogues (prototypes) du système développé.
• Matériel décrivant l'idée générale du système. Souvent, ces documents sont compilés à des stades de préconception, et ceux-ci sont généralement référencés dans la section «Caractéristiques de l'objet d'automatisation».
• Matériel de développement de projet: liste des GOST utilisés de la série 34, normes utilisées pour la gestion de projet.
• Matériaux liés à la mise en œuvre du processus principal: une liste de lois, normes, règlements internes et arrêtés qui établissent les règles de mise en œuvre des processus automatisés.
• Matériaux et normes contenant des exigences pour la sécurité générale et de l'information.

Conclusion

Bien sûr, la préparation du mandat conformément à GOST 34 ne peut pas être qualifiée de facile et simple. Et pas parce que GOST est mauvais, mais GOST vous fait juste réfléchir à tout le projet, peindre toutes les petites choses. Mais un mandat bien rédigé représente la moitié du succès du projet.

Écrivez dans les commentaires si vous jugez nécessaire de clarifier ou de compléter quelque chose. Assurez-vous d'apporter des modifications à l'article.

Lisez d'autres articles de l'auteur:

• Enquête de pré-conception dans le développement d'un système d'information.
• Secrets d'une conception réussie de l'IP (système d'information) sur l'exemple de la construction d'un hôpital.
• Quelques notes sur la conception des systèmes d'information.