Que devriez-vous mettre dans une spécification d'architecture?

Question

Je révise actuellement un certain nombre de modèles de documents pour mon entreprise. Une chose que nous n’ayons jamais eue est une spécification d’architecture formelle. Je commence donc à en élaborer une.

Quel genre de choses mettez-vous dans vos spécifications d'architecture? N'hésitez pas à copier et coller une table des matières - cela serait utile. Existe-t-il de bons modèles déjà disponibles sur le Web?

Answer 1

Je suis d'accord avec Asaphs sentiment; heureusement, il n'est pas impossible de produire de l'utile / pratique de documentation architecturale - il suffit de pas commun.

Pour moi, la clé, c'est de savoir de qui le document est: quand auraient-ils l'utiliser? Pourquoi auraient-ils l'utiliser? Trop de fois il devient tout simplement un formulaire de remplissage de l'exercice pour cocher des cases sur certains plan de projet.

Je suppose que vous voulez dire un document d'architecture logicielle solution ou d'un document d'architecture - et non pas une stratégie d'entreprise ou de quelque chose.

Rappelez-vous aussi qu'il s'agit de deux choses l'une architecture typique document fera l'affaire:

• Commenter les décisions prises ailleurs: "c'est notre mode de pensée actuel - ce que quelqu'un serait veuillez décider de passer le gros $$ pour le site ou pas, etc".
• Enregistrement des décisions prises, notamment en justifiant vos décisions.

En termes de structure et d'information clé pour la capture je vous recommande de regarder les différentes vues du système: logique, physique, de données, de la sécurité, et ainsi de suite. Un bon point de départ est le 4+1 modèle.

[Mise à jour:] l'Une des utilisations d'un tel artefact est la Traçabilité des exigences et des artéfacts de conception par le biais de code artefacts; et tout cela peut sembler Cascade orientées elle s'applique effectivement (et travaux) pour Agile en fonction des projets.

[Mise à jour:] Artefact ne veut pas dire "Document Word". La table des matières exemple ci-dessous est un document / document en fonction de la version du système modélisé dans un langage de modélisation UML de l'outil (SparxEA) qui comprend les exigences ainsi. Parfois, vous "devez" utilisation d'un document, mais j'essaie d'être comme épargnant que possible.

[Mise à jour: une autre bonne chose à propos d'une belle claire document est qu'il est plus facile pour les nouveaux de sang à obtenir une certaine compréhension de ce qu'ils héritent d' - surtout si les employés ne sont pas disponibles.

Le Software Engineering Institute de l'université Carnegie Mellon a un tas d'informations, et sur la page ci-dessous il y a un lien vers un modèle: http://www.sei.cmu.edu/architecture/tools/viewsandbeyond/
Bewared que c'est très complète, pas pour les faibles de cœur (manque de temps).

[Mise à jour:] Enfin, voici un exemple de Table des Matières à partir d'un projet récent. Malgré les nombreuses sections du document n'est pas trop long (seulement environ 35 pages, et une bonne partie de l'est de diagrammes).

Table of Contents
1   Documentation Roadmap
1.1 Document & Version Information
1.1.1   Document Contributors
1.1.2   Referenced Documents
1.1.3   Reviewers   
1.1.4   Document Signoff    
1.2 Glossary of Terms   
1.3 Purpose and Scope of the SAD    
1.4 Stakeholder Representation  
2   Project Background  
2.1 Problem Background  
2.2 Solution Overview and Project Phases    
2.3 Solution Context    
2.3.1   Solution Usage  
2.4 Architectural Goals 
2.5 Constraints 
2.6 Considerations  
3   Register of Issues and Decisions    
3.1 Issues Register 
3.2 Decisions Register  
4   Overview of Key Views   
5   Functional View 
6   Logical Layers View 
7   Physical View   
7.1 Mapping of Logical and Physical Components  
7.2 Mapping of Logical Layers and Bespoke Packages  
7.3 Bespoke Physical Components 
7.4 Common  
7.5 Business Logic  
7.6 Data Provider Interfaces    
7.7 MS SQL Data Provider    
7.8 Data Repository 
7.9 External Data Services – Time Sheeting  
7.10    External Data Services - DLR    
7.11    UI - Flash  
7.12    FlourineFX  
7.13    UI - ASP.NET    
7.14    Model   
7.15    Login   
7.16    Mapping To Physical Components  
7.17    Solution Dependencies   
8   Solution Views  
8.1 Data View   23
8.1.1   Conceptual Data Model   
8.1.2   Physical Data Model 
8.2 Technology View 
8.2.1   Microsoft Windows Server    
8.2.2   Microsoft Internet Information Server   
8.2.3   Microsoft SQL Server    
8.2.4   Microsoft .Net Framework    
8.2.5   Microsoft ASP.NET   
8.2.6   Microsoft ASP.NET Role Membership Provider  
8.2.7   Dot Net Nuke (DNN)  
8.2.8   AntiXSS Library 
8.2.9   Microsoft Enterprise Libraries  
8.2.9.1 Application Logging Block   
8.2.10  Log4Net 
8.2.11  Fluorine    
8.2.12  Adobe Flash 
8.3 Security View   
8.3.1   Data Encryption – Data at Rest  
8.3.2   Data Encryption – Data in Flight    
8.3.3   Authentication  
8.3.4   Authorisation   
8.3.5   Non-Repudiation 
8.3.6   Cross-Site Scripting (XSS) and SQL Injection    
8.3.7   Other Security Concerns 
8.4 Infrastructure View 
8.5 Support View    
8.6 Enterprise Standards Compliance 
9   Design Patterns and Principles  
9.1 Dependency Inversion Principle  
9.2 Dependency Injection Pattern    
9.3 Factory Pattern 
9.4 Persistence Ignorance   
9.5 Dependency Injection    
Appendix – [legacy project name] Phase 1    
9.6 Bespoke Physical Components 

Answer 2

Dans mon opinion personnelle, je considère les rubriques suivantes pour être utile lors de la définition de la Documentation du Logiciel:

• Introduction (document d'objectifs)
• Contexte diagramme (application)
• Les Exigences matérielles (mémoire et processeur requise)
• Exigences de logiciels (systèmes d'exploitation, serveur de base de données, des cadres, des bibliothèques)
• Le Modèle d'opération (exploitation de l'entreprise, des fiches de processus)
• L'Architecture physique du Modèle (disposition physique, les serveurs de la DMZ, firewall)
• L'Architecture de l'Application du Modèle (plusieurs couches de l'application, des services, des composants, des diagrammes UML)
• Modèle de base de données (UML-PDM; tables, Sps, les Vues, les triggers)
• Modèle de sécurité (authentification, l'autorisation, la personnification, techniques de hachage)
• GUI Modèle (écrans, de cas d'utilisation, diagrammes de génériques)
• Dictionnaire de données (format Excel)

Jetez un oeil à ces Documents d'Orientation de l'Architecture de l'Application à partir de Microsoft:

• L'Architecture De L'Application Guide 2.0
• L'Architecture de l'Application pour .NET: la Conception d'Applications et de Services

Answer 3

Mes ingrédients typiques pour une spécification de l'architecture sont:

• Statique De La Structure Du Système De
  • Vue d'ensemble
  • Les composants (par composant: caractéristiques, technologie, persistance)
  • Interfaces (internes & externes, de machine à machine et de l'utilisateur interfaces)
• Comportement Dynamique
  • Processus d'affaires (c'est à dire des cas d'utilisation)
  • La cartographie des processus d'affaires à la structure du système (c'est à dire des diagrammes de séquence)
• Déploiement
  • HW Aperçu
  • Vue d'ensemble du réseau
  • La cartographie de composants logiciels pour le matériel

Aussi jeter un oeil sur les 4+1 Modèle.

Answer 4

L'IEEE ont de nombreuses normes en fonction de ces problème. Tels que l'IEEE 1016, il spécifie une structure organisationnelle pour la conception de logiciels description. http://en.wikipedia.org/wiki/Software_Design_Description

Le Document doit contenir au moins les chapitres suivants

1. INTRODUCTION
   • Présentation De La Conception
   • Matrice De Traçabilité Des Exigences
2. SYSTÈME DE CONCEPTION ARCHITECTURALE
   • Choisi L'Architecture Du Système
   • La Discussion d'autres Dessins
   • Système De Description De L'Interface
3. DÉTAIL DE LA DESCRIPTION DES COMPOSANTS
   • Composante n
   • Composante n+1
4. CONCEPTION DE L'INTERFACE UTILISATEUR
   • Description de l'Interface Utilisateur
     • L'Image De L'Écran
     • Les objets et les Actions
5. DU MATÉRIEL SUPPLÉMENTAIRE

Answer 5

L'Architecture devrait fournir des conseils aux développeurs un moyen d'éviter de l'intégration et des problèmes de maintenance. Plus précisément, l'architecture doit identifier les choses telles qu'approuvées systèmes d'exploitation, approuvé langages de développement, approuvé systèmes de stockage de données, a approuvé les protocoles de communication, des pratiques de codage, les tests de cadres, de contrôle de source, d'acceptation par l'utilisateur des procédures et de la production les procédures de mainlevée, la séparation des préoccupations, entretien des procédures et de la sécurité. Dans la plupart des cas, c'est un document vivant et sections sont ajoutées et raffinée que la technologie s'améliore. Étant donné que chaque entreprise est unique, d'une copie de la directive ne serait utile que pour des idées de ce qu'il faut inclure. Sur la base des réponses des autres, vous avez déjà un certain nombre de grandes idées que vous pouvez utiliser.