|
«La documentation est une partie inhérente du processus de conception." - Loi de Bryce INTRODUCTION J'ai récemment entendu un analyste d'affaires disent qu'il n'y avait plus d'une architecture de systèmes que de tirer des boîtes et des flèches sur une feuille de papier. Cette mai-être vrai dans une certaine mesure, mais la pratique architecturale livrable ultime de toute l'ingénierie / est un ensemble de dessins qui guidera l'élaboration d'un produit. Les architectes et les ingénieurs ne passent pas tout leur temps à la conception de diagrammes, par exemple, ils doivent préciser les exigences et analyser les choses telles que le stress de composants afin de déterminer l'aptitude des matériaux à utiliser dans la conception. Mais à part cela, le résultat final de l'ingénierie ou d'architecture, de leur livrer, est un ensemble de dessins, qu'il s'agisse d'un schéma directeur, un plan, schéma de câblage, la plomberie, ou un ensemble d'organigrammes. Ces dessins se composent essentiellement de boîtes et de flèches. Boxes (que ce soit carrés, rectangles, polygones, cercles, etc) représentent des objets tangibles et lignes représentent les relations entre ces objets. Organigrammes sont semblables, ici, les boîtes représentent des types spécifiques de processus ou des décisions ou des objets tels que les entrées / sorties / fichiers, et les lignes représentent les dépendances entre eux (vient de / va faire). Même si les dessins sont généralement constitués de formes géométriques, il n'est pas rare d'y inclure des tableaux ou d'indices pour représenter des décisions ou pour fournir une référence croisée. Néanmoins, les boîtes et lignes représentent le principal moyen de visualiser et communiquer une conception indépendamment de la structure à construire, et ont été utilisés depuis des temps immémoriaux. En plus de création de diagrammes techniques, des ingénieurs et des architectes ont jugé utile de développer des modèles et des prototypes pour évaluer l'ensemble des aspects physiques de leur conception. Elles sont utiles mais n'oublions pas qu'ils sont tous en fin de compte fondée sur une conception de certains types (boîtes et lignes). Des modèles et des prototypes, des modèles peuvent être ajustés selon les besoins. Je suppose que ce que je veux en venir, c'est que malgré toute cette activité périphérique, et de réfuter mon ami Business Analyst, l'idée directrice de l'ingénieur ou l'architecte est de produire et de maintenir un ensemble fiable de dessins. Le tout se résume à des boîtes et des lignes. Fait intéressant, les analystes et les programmeurs d'aujourd'hui pensent les dessins sont "vieux chapeau» ou passé. Je ne me soucie pas de savoir si vous le dessiner avec le crayon et le papier ou par ordinateur, la documentation est une partie inhérente du processus de conception. Ne pas reconnaître cela est de nier la réalité. En termes de l'industrie des systèmes d'information, des organigrammes ont été utilisés pendant des années, bien avant l'introduction de l'informatique commerciale dans les affaires. A l'origine ils ont inclus des diagrammes de processus; plus tard, ils ont été utilisés par les programmeurs comme un moyen commode de document logique du programme. Ces diagrammes de flux généralement fait usage de symboles d'organigrammes norme ANSI. Mais comme le mouvement de programmation structurée a prospéré à la fin des années 1970, symboles ANSI étaient considérés comme archaïques, et de nombreux nouveaux types de diagrammes techniques apparus, y compris Bubble diagrammes, structure des données diagrammes, des E / R Diagrams, HIPO, VTOC, etc (quelqu'un se souvient Nassi -Schneiderman Charts?). Je pourrais discuter des avantages et inconvénients des différentes techniques, mais ce n'est pas la question. Ce qui est important est que toutes ces techniques de diagrammes reconnu documentation, comme partie inhérente du processus de conception. Aujourd'hui, la documentation de toute nature est considérée comme un tabou (en particulier chez les personnes méthodologie agile). Pas étonnant l'industrie des TI rencontre le même type de problèmes aujourd'hui que nous avons connu il ya 35 ans en termes de gestion de la complexité de conception. BluePrinting C'est un mythe que d'un type de diagramme technique peut être utilisée pour tous les travaux de développement. Ce serait comme suggérant d'utiliser un schéma de câblage pour représenter un plan d'étage. Des besoins différents, des graphismes différents, objectifs différents. Il ya en fait quatre types de graphiques à utiliser pour les différents niveaux de conception du système. Cela suppose une approche Blueprinting avec différents niveaux d'abstraction, du général au spécifique. Comme nous l'avons discuté dans le passé, la «fierté», Information Systems Engineering Methodology (ISEM) se penche sur un système comme un produit qui peut être conçu et fabriqué un produit comme un autre et, comme tel, définit quatre niveaux de détail dans un système hiérarchie: NIVEAU 1 SYSTEM NIVEAU 2 sous-systèmes (Business Processes) PROCÉDURES DE NIVEAU 3 (administrative et informatique) NIVEAU 4 programmes (pour Computer Procedures) opérations (Procédures administratives) Quatre niveaux différents, quatre différents graphiques utilisés: NIVEAU 1 Schéma du système CONCEPT - représente un rendu d'architecture de forme libre de l'ensemble du système. NIVEAU 2 Organigramme du système - définit les sous-systèmes du système. NIVEAU 3 SOUS-SYSTÈME DE DIAGRAMME - définit les procédures dans un sous-ensemble (aka "Process Diagram"). NIVEAU 4 Chaque niveau fournit les spécifications pour la prochaine (c'est aussi connu sous le nom de «raffinement progressif"). À l'exception de l'arbre des concepts du système, tous les organigrammes de faire usage de symboles standard ANSI. Quant à la logique interne de traitement d'un programme, car il existe de nombreuses façons de la peau d'un chat, le diagramme de structure logicielle du jour est utilisé, nous l'espérons un programme type. Toutefois, un graphique mai-être pas nécessaire d'exprimer la logique du traitement d'un programme. Au lieu de cela, les spécifications mai être interprété par un générateur de programme quelconque. Son choix un joueur de champ "de". CONCLUSION Jusqu'à ce que nous pouvons maîtriser le mental "Vulcan meld", par lequel nous pouvons le transfert des connaissances par télépathie, il y aura toujours un besoin pour la documentation. Sa partie intégrante du processus de conception et de la principale prestation effectuée par des ingénieurs et architectes. Ne niez pas, acceptez-le. Je ne suis définitivement pas un pour la documentation excessive devient ainsi une tâche lourde. Au lieu de cela, la documentation doit être un sous-produit naturel du processus de conception. Tout comme les Bleus est une partie inhérente du processus de conception aux architectes et ingénieurs, ainsi doit être d'un organigramme pour les développeurs de systèmes. Et vous ne devriez pas être un génie pour dessiner un diagramme de flux, rester simple et essayez d'utiliser des techniques standard de la cohérence au lieu de réinventer graphiques toutes les cinq minutes. Quant à moi, je n'ai aucun problème avec les normes ANSI; cela fonctionne. |