Paul Clements (1)
Auteur de Documenting Software Architectures: Views and Beyond
Pour les autres auteurs qui s'appellent Paul Clements, voyez la page de désambigüisation.
Paul Clements (1) a été combiné avec Paul C. Clements.
Œuvres de Paul Clements
Les œuvres ont été combinées en Paul C. Clements.
Étiqueté
Partage des connaissances
- Sexe
- male
Membres
Critiques
Vous aimerez peut-être aussi
Auteurs associés
Statistiques
- Œuvres
- 3
- Membres
- 304
- Popularité
- #77,406
- Évaluation
- 3.2
- Critiques
- 2
- ISBN
- 51
- Langues
- 1
My recommendation is that most people will get the most value by skimming the prologue, especially sections P.2.2 and uses and audiences for architecture documentation, section P.4 on architecture styles, and P.5 on rules for sound documentation[1]. Flip through the chapters on the different view types and read the description of those that feel most relevant (skip the text about the examples and just look at the diagrams). Read chapter 7 on documenting software interfaces. Skim chapter 8 on documenting behavior. Read chapter 11 on reviewing an architecture document.
You won't find all of the gems this way, but you'll get a better value for your time investment than if you were to read the whole thing.
[1] In sum:
1. Write documentation from the reader's point of view
2. Avoid unnecessary repetition
3. Avoid ambiguity
4. Use a standard organization
5. Record rationale
6. Keep documentation current but not too current
7. Review documentation for fitness of purpose.… (plus d'informations)