/
DesignDocumentGuides.html
338 lines (295 loc) · 20.6 KB
/
DesignDocumentGuides.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Design Document Guidelines</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="_static/bootstrap-sphinx.css?v=fadd4351" />
<link rel="stylesheet" type="text/css" href="_static/custom.css?v=77160d70" />
<script src="_static/documentation_options.js?v=30d551ce"></script>
<script src="_static/doctools.js?v=9a2dae69"></script>
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Generating Code Coverage" href="CodeCoverage.html" />
<link rel="prev" title="Technical Steering Committee" href="TSC.html" />
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-59110517-1', 'auto');
ga('send', 'pageview');
</script>
</head><body>
<div id="navbar" class="navbar navbar-default ">
<div class="container">
<div class="navbar-header">
<!-- .btn-navbar is used as the toggle for collapsed navbar content -->
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="http://www.mantidproject.org">
</a>
<span class="navbar-text navbar-version pull-left"><b>master</b></span>
</div>
<div class="collapse navbar-collapse nav-collapse">
<ul class="nav navbar-nav">
<li class="divider-vertical"></li>
<li><a href="index.html">Home</a></li>
<li><a href="https://download.mantidproject.org">Download</a></li>
<li><a href="https://docs.mantidproject.org">User Documentation</a></li>
<li><a href="http://www.mantidproject.org/contact">Contact Us</a></li>
</ul>
<form class="navbar-form navbar-right" action="search.html" method="get">
<div class="form-group">
<input type="text" name="q" class="form-control" placeholder="Search" />
</div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<p>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="nav-item nav-item-0"><a href="index.html">Documentation</a> »</li>
<li class="nav-item nav-item-this"><a href="">Design Document Guidelines</a></li>
</ul>
</div> </p>
</div>
<div class="container">
<div class="row">
<div class="body col-md-12 content" role="main">
<section id="design-document-guidelines">
<span id="designdocumentguidelines"></span><h1>Design Document Guidelines<a class="headerlink" href="#design-document-guidelines" title="Link to this heading">¶</a></h1>
<nav class="contents local" id="contents">
<ul class="simple">
<li><p><a class="reference internal" href="#when-to-write-a-design-document" id="id1">When to write a design document</a></p>
<ul>
<li><p><a class="reference internal" href="#amount-of-classes" id="id2">Amount of classes</a></p></li>
<li><p><a class="reference internal" href="#amount-of-files" id="id3">Amount of files</a></p></li>
<li><p><a class="reference internal" href="#abstractness-fraction" id="id4">Abstractness fraction</a></p></li>
<li><p><a class="reference internal" href="#the-layer-of-intent" id="id5">The layer of intent</a></p></li>
<li><p><a class="reference internal" href="#number-of-developers" id="id6">Number of developers</a></p></li>
<li><p><a class="reference internal" href="#number-of-users" id="id7">Number of users</a></p></li>
<li><p><a class="reference internal" href="#number-of-person-months" id="id8">Number of person-months</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#design-document-process" id="id9">Design document process</a></p></li>
<li><p><a class="reference internal" href="#design-document-content" id="id10">Design document content</a></p>
<ul>
<li><p><a class="reference internal" href="#motivation" id="id11">Motivation</a></p></li>
<li><p><a class="reference internal" href="#dictionary-of-terms" id="id12">Dictionary of Terms</a></p></li>
<li><p><a class="reference internal" href="#potential-solutions" id="id13">Potential Solutions</a></p></li>
<li><p><a class="reference internal" href="#chosen-solution" id="id14">Chosen Solution</a></p></li>
<li><p><a class="reference internal" href="#implementation-detail" id="id15">Implementation Detail</a></p></li>
<li><p><a class="reference internal" href="#cheat-sheet-and-checklist" id="id16">Cheat Sheet and Checklist</a></p></li>
</ul>
</li>
</ul>
</nav>
<p>A good design document minimises unexpected complications by addressing
them before the code is written. A document will provide you, your
manager and your team with a common vocabulary for talking about the
project. Writing an effective design document can be tricky in itself, as
they often add unnecessary complexity if not done with care. These
guidelines are to help with when and how to generate effective and simple design
documents.</p>
<section id="when-to-write-a-design-document">
<h2><a class="toc-backref" href="#id1" role="doc-backlink">When to write a design document</a><a class="headerlink" href="#when-to-write-a-design-document" title="Link to this heading">¶</a></h2>
<p>This section provides some guidelines on when to produce a design document.
Note that, it is not about when to do a design and when not.
Except for trivial changes, one should always perform design work before coding, no matter the scope or the nature of the feature.
These guidelines set out in which cases the design must be a <em>public</em>, <em>written</em> and <em>persistent</em> document, rather than a sketch on a white-board in a stand-up meeting.
Just like coding, design is an iterative and collaborative process.
Having a written document allows for discussion and iterations with peers, including across facilities, before the first line of code is typed.
Besides, the written document facilitates the pull request review process.
Having the design already approved, the reviewer will not need to do a design review with the code review, but will just need to make sure that the implementation matches the previously agreed design.
Finally, once written, the document can also serve as (or easily be turned into) a developer documentation for future reference.</p>
<p>Not every feature requires a design document. The benefit it adds must be gauged with the time and effort that goes into it.
Below are the main scenarios when a design document is necessary or not.</p>
<table class="docutils align-default">
<thead>
<tr class="row-odd"><th class="head"><p>Design Document Needed</p></th>
<th class="head"><p>Design Document Not Needed</p></th>
</tr>
</thead>
<tbody>
<tr class="row-even"><td><ul class="simple">
<li><p>Large-scope feature - e.g. slice viewer, instrument viewer</p></li>
<li><p>Brand-new feature - e.g. crash reporter, plot manager</p></li>
<li><p>Core refactors - e.g. HistogramData, DetectorInfo</p></li>
<li><p>Abstractions, APIs - e.g. simpleapi, a new workspace type</p></li>
<li><p>Fully fledged libraries - e.g. Crystal library in the framework</p></li>
</ul>
</td>
<td><ul class="simple">
<li><p>Bug fixes of any kind</p></li>
<li><p>Minor extensions to the current tools - e.g. adding another button in a GUI widget</p></li>
<li><p>New functionalities to an extant algorithm – e.g. another target of unit conversion</p></li>
<li><p>Concrete, single-class plugins - e.g. a new algorithm or a new fit function</p></li>
</ul>
</td>
</tr>
</tbody>
</table>
<p>Below are a handful of measurable quantities that could help a developer decide which category the feature belongs to.</p>
<section id="amount-of-classes">
<h3><a class="toc-backref" href="#id2" role="doc-backlink">Amount of classes</a><a class="headerlink" href="#amount-of-classes" title="Link to this heading">¶</a></h3>
<p>Single-class plugins, such as algorithms, do not require design documents.
In the contrary, if the number of classes is more than a dozen, the document could be relevant in order to describe the relations between them.</p>
</section>
<section id="amount-of-files">
<h3><a class="toc-backref" href="#id3" role="doc-backlink">Amount of files</a><a class="headerlink" href="#amount-of-files" title="Link to this heading">¶</a></h3>
<p>If the feature intends to touch (add or edit) a single file, design document is not needed.
If it is more than a hundred, opposite is likely the case.</p>
</section>
<section id="abstractness-fraction">
<h3><a class="toc-backref" href="#id4" role="doc-backlink">Abstractness fraction</a><a class="headerlink" href="#abstractness-fraction" title="Link to this heading">¶</a></h3>
<p>Stability of a piece of code must be proportional to its abstractness; abstractions and APIs are hard to change, once in.
So whenever the feature concerns creations of new abstraction layers and APIs, a wider discussion on the design is needed, hence the necessity of the document.
A good measure for this is the intended fraction of the abstract classes (virtual or pure virtual) in the design.</p>
</section>
<section id="the-layer-of-intent">
<h3><a class="toc-backref" href="#id5" role="doc-backlink">The layer of intent</a><a class="headerlink" href="#the-layer-of-intent" title="Link to this heading">¶</a></h3>
<p>If the feature is deep in the framework or workbench, it is more critical to have a document.
Features in the core layer must be carefully thought out, as many other things will depend on them.
In the contrary, if the feature is just a plugin in the periphery (algorithm, function, GUI, script), with low risk of side effects, a design document is less important.</p>
</section>
<section id="number-of-developers">
<h3><a class="toc-backref" href="#id6" role="doc-backlink">Number of developers</a><a class="headerlink" href="#number-of-developers" title="Link to this heading">¶</a></h3>
<p>If the feature is large enough that the implementation will be done in a distributed way (i.e. more than one developer), the document will ensure that the whole team has a common vision, discussed and agreed upfront.</p>
</section>
<section id="number-of-users">
<h3><a class="toc-backref" href="#id7" role="doc-backlink">Number of users</a><a class="headerlink" href="#number-of-users" title="Link to this heading">¶</a></h3>
<p>If the feature is generic, it will be facing a wider audience of users, hence a document and design review will make sure that the right feature is being built in the right way.
In the contrary, if the feature is specific to one instrument or technique at one facility, producing a document is less important.</p>
</section>
<section id="number-of-person-months">
<h3><a class="toc-backref" href="#id8" role="doc-backlink">Number of person-months</a><a class="headerlink" href="#number-of-person-months" title="Link to this heading">¶</a></h3>
<p>Another metric could be the estimated effort in person-months. If the feature is estimated to take a year to develop, it is worth spending a few weeks to iterate and improve on the design.
If the feature is less than one month of work, it’s probably an overkill.</p>
<p>These are just guidelines and not strict rules.
It is hard to define exact thresholds on these quantities, and often your feature is going to be in a grey zone anyway.
Therefore, it is advised to combine all these metrics and make a professional judgement on a case-by-case basis.
Nevertheless, a good intuition on when a document is useful, and when not, comes with experience.
That’s why, whenever in doubt, get in touch with the senior members of the team - the gatekeepers.
A good first contact could be the local team lead at your facility, or the <em>tech-qa</em> channel on slack.</p>
</section>
</section>
<section id="design-document-process">
<h2><a class="toc-backref" href="#id9" role="doc-backlink">Design document process</a><a class="headerlink" href="#design-document-process" title="Link to this heading">¶</a></h2>
<p>Once identified that for a given feature a design document is needed, the process goes as follows:</p>
<ol class="arabic simple">
<li><p>Create an item in the technical working group roadmap <a class="reference external" href="https://github.com/mantidproject/roadmap/projects/1">here</a> under the intended release.</p></li>
<li><p>Produce the document in <a class="reference external" href="http://en.wikipedia.org/wiki/Markdown">markdown</a> format with the md extension. Once ready for review, open a PR in <a class="reference external" href="https://github.com/mantidproject/documents/tree/main/Design">here</a> or a subdirectory therein. The pull request should also include the sources (and not just the images) of any diagrams you put in the document. The diagrams can be drawn with <a class="reference external" href="https://staruml.io/">staruml</a> or similar cross-platform or WEB solution.</p></li>
<li><p>Once the PR is ready for review, put a message with a link in <em>tech-qa</em> channel, inviting the gatekeepers or other interested parties take a look and provide comments within one calendar week. Unlike the PR for code, the design reviews can and should have more than one assigned reviewer. The period can be extended if the scope is very large.</p></li>
<li><p>Answer the comments under the PR and iterate as long as needed.</p></li>
<li><p>Once the comments are incorporated, in absence of outstanding conflicts, the gatekeepers will approve and merge the PR of the design, which gives a green light to start the implementation.</p></li>
<li><p>If there is still a debate between gatekeepers, the <a class="reference internal" href="TSC.html#tsc"><span class="std std-ref">Technical Steering Committee</span></a> will set up a dedicated meeting, where the author will be invited to present and defend the design, and all the conflicts must be settled ideally via consensus, or in the absence thereof, via majority vote.</p></li>
<li><p>Once the implementation PR is opened, the design document must be referenced in the PR message. If the feature required a design document, high is the chance that the implementation PR will require also a developer documentation.</p></li>
</ol>
</section>
<section id="design-document-content">
<h2><a class="toc-backref" href="#id10" role="doc-backlink">Design document content</a><a class="headerlink" href="#design-document-content" title="Link to this heading">¶</a></h2>
<p>We want to avoid a prescriptive approach to design document layout.
Design documents are about communicating design ideas, not a box ticking
exercise, so developers are expected to use their own professional
judgement about what goes into them. We are not providing templates for
this reason. The following are suggestions for sections that one should normally have in a design
document:</p>
<section id="motivation">
<h3><a class="toc-backref" href="#id11" role="doc-backlink">Motivation</a><a class="headerlink" href="#motivation" title="Link to this heading">¶</a></h3>
<ul class="simple">
<li><p>Why does this design document exist?</p></li>
<li><p>What is the overview of the problem?</p></li>
<li><p>What use cases exist showing the present issue?</p></li>
<li><p>How does this solve the requirements?</p></li>
<li><p>Note that, <em>this section should be readable to non-developers</em>.</p></li>
</ul>
</section>
<section id="dictionary-of-terms">
<h3><a class="toc-backref" href="#id12" role="doc-backlink">Dictionary of Terms</a><a class="headerlink" href="#dictionary-of-terms" title="Link to this heading">¶</a></h3>
<p>Your opportunity to pair abbreviations to longer explanations. This is
not always necessary in documents where there are no special terms to
explain. If you need one, a two column table would be sufficient.</p>
</section>
<section id="potential-solutions">
<h3><a class="toc-backref" href="#id13" role="doc-backlink">Potential Solutions</a><a class="headerlink" href="#potential-solutions" title="Link to this heading">¶</a></h3>
<p>It is important that you consider a wide range of possible solutions,
and don’t just put forward your favourite. Remember that the design
document is a way of avoiding mistakes before coding, so spend some time
considering how several possibilities could be made to work.</p>
<p>For each potential solution, you should probably consider:</p>
<ul class="simple">
<li><p>Keep it brief and high-level at this stage</p></li>
<li><p>What would the scope of the changes be?</p></li>
<li><p>What are the pros/cons of this solution?</p></li>
</ul>
</section>
<section id="chosen-solution">
<h3><a class="toc-backref" href="#id14" role="doc-backlink">Chosen Solution</a><a class="headerlink" href="#chosen-solution" title="Link to this heading">¶</a></h3>
<p>You should provide logical reasons why you are choosing to adopt
solution A over solution B, C, D … As the project grows in size, we
may need to be able to understand in the future the reasons why certain
designs have been adopted. If you are unsure which solution would be
best, you may submit the partially complete design document to the <a class="reference internal" href="TSC.html#tsc"><span class="std std-ref">Technical Steering Committee</span></a> for help. Design
is itself an iterative process and documents are frequently not accepted
first time around, so be prepared to make amendments, and don’t take it
personally if corrections are required.</p>
<p>Another thing to include is how can one verify the design? What are the use cases that could be used to prove the viability of the solution?</p>
</section>
<section id="implementation-detail">
<h3><a class="toc-backref" href="#id15" role="doc-backlink">Implementation Detail</a><a class="headerlink" href="#implementation-detail" title="Link to this heading">¶</a></h3>
<p>You could merge this section here with the one above if you wish.</p>
<ul class="simple">
<li><p>Use feedback to correct and clarify.</p></li>
<li><p>Add more implementation detail. Diagrams are great, but you don’t
have to use strict UML, and use the appropriate UML diagrams
depending upon the solution. Diagrams should help you and readers to
understand the solution in a simple way, not make it more
complicated.</p></li>
<li><p>Could someone else follow the design and implement it based on the document without talking to you?
You may not be the one implementing this, and it’s even more likely that you will not be the only one maintaining it.</p></li>
</ul>
</section>
<section id="cheat-sheet-and-checklist">
<h3><a class="toc-backref" href="#id16" role="doc-backlink">Cheat Sheet and Checklist</a><a class="headerlink" href="#cheat-sheet-and-checklist" title="Link to this heading">¶</a></h3>
<p>The guidelines above do not need to be strictly followed, but the following are necessary:</p>
<ol class="arabic simple">
<li><p>Can non-experts understand the motivation for these changes?</p></li>
<li><p>Does your design document link from requirements through the implementation details in a traceable manner?</p></li>
<li><p>Can someone else implement this?</p></li>
<li><p>What use cases verify that this design works?</p></li>
<li><p>Has the <a class="reference internal" href="TSC.html#tsc"><span class="std std-ref">Technical Steering Committee</span></a> approved it?</p></li>
</ol>
</section>
</section>
</section>
</div>
</div>
</div>
<footer class="footer">
<div class="container">
<ul class="nav navbar-nav" style=" float: right;">
<li>
<a href="TSC.html" title="Previous Chapter: Technical Steering Committee"><span class="glyphicon glyphicon-chevron-left visible-sm"></span><span class="hidden-sm hidden-tablet">« Technical Ste...</span>
</a>
</li>
<li>
<a href="CodeCoverage.html" title="Next Chapter: Generating Code Coverage"><span class="glyphicon glyphicon-chevron-right visible-sm"></span><span class="hidden-sm hidden-tablet">Generating Co... »</span>
</a>
</li>
<li><a href="#">Back to top</a></li>
</ul>
<p>
</p>
</div>
</footer>
</body>
</html>