We tend to separate our A&D documentation into the following categories: For this section, we’re going to share the documentation included in one of our more complex projects, since it provides a comprehensive overview. The architecture and design (A&D) documentation included in a project depends on the complexity of that project and the amount of design effort we applied to it. We’ll also share other ways we document our software projects. Given that both questions center around diagrams, we’ll focus our answer on that topic. What do you consider to be a valid architecture diagram? What are some that you have discovered you prefer over others? The author admonishes developers to create and record a software architecture for their project before they start coding, and then says “Beware: activity diagrams, flowcharts, and sequence diagrams describe operation, not architecture.” In “Better Embedded Systems Software”, Phillip Koopman says that “an architecture is some figure that had boxes and arrows representing components and connections” and provides examples like “call graph, class diagram, data flow diagram, hardware allocation diagram, control hierarchy diagram” as well as a few exceptions to the rule (“message dictionary, real time schedule, memory map”). The second question arose during a discussion on Timeless Laws of Software Development, by Jerry Fitzpatrick: What type of documentation do you create for your code? Do you use UML? Subset of UML? Something else? Can you provide samples? We received a pair of questions that prompted this Q&A article.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |