Apr 062017

As a unit of measure, a headful is not consistent. Not consistent between individuals, not consistent in any one individual from day to day. I will explain what I mean by the term, how it varies, and how to stretch it.

Firstly the definition. The Collins English Dictionary defines it as ‘the amount a head or brain will hold’. I use it specifically with reference to the understanding of a problem.

So how does it vary? When presented with a new project, I try to understand the big picture, the whole project. There is a level of abstraction at which that is possible. As time goes on, and I become familiar with the problem and the previous headful of information becomes compacted, making space for more detail. This is closely aligned to the process of turning data into knowledge and understanding. The initial headful for any given problem also depends on the other things already in my head; if I can closely align the new data with previously compacted data, then I can take in more at the first go. Each individual has a different capacity for a given problem space.

Note: my mental model of my mental model has diggers and dumper trucks and rollers and rotavators. While digging for the wanted information, there will often be surprising additional facts uncovered leading to interesting juxtapositions. I think a beautifully clean warehouse of a mind, while more efficient at retrieving things, might be rather dull and predictable.

If this is such a loosely defined quantity, then how is it helpful? First there is the appreciation that someone new to a project cannot understand all the detail across all the project areas on day one. We need to abstract the whole to a level that is comprehensible, and add detail once that framework is in place. Second, by understanding that this headful is not fixed through time, we can look at ways to supplement it, aid the compaction, and improve the ability to manipulate the data.

Tools. Pause for a moment and note what comes into your mind when I say tools. Tools come in many shapes and forms. The relevant ones here are:

  • Thinking tools – techniques and shortcuts
  • Data capture tools – databases, data storage
  • Data manipulation tools – modelling tools, more sophisticated search tools on the captured data

Data storage can actually be a bad thing for building mental models. Once something is written down and documented, there is a tendency to forget it. Many people use lists in some form to clear the clutter from their heads and make space for creative thought. Data storage is, however, essential for the sharing of information across teams. We have to ensure we write and remember, not write and forget.

Thinking tools allow us to fit the data to a pattern and gain understanding. This might be by asking certain questions, or by making certain associations. They involve manipulating the data in the headful, shaking it up, and allowing it to settle back into less space.

Data manipulation tools are where the real increase in the unit of the headful can be seen. This allows us to use the thinking tools across a wider data set, to find the next piece of the puzzle that will make sense. These tools also allow us to share and merge our headful of data with the other team members’ headfuls.

Feb 142017

Many industries rely heavily on a large number of standards, a selection of which are used on each project. There is a perennial problem of managing these so that they are visible within the engineering data environment along with other design artifacts. I wrote previously about some approaches to creating and maintaining traceability to the standards. Here I want to look at the issues around storage, and a possible data architecture.

DOORS Next Generation has moved on again, with real progress being made on useability. The latest release includes a feature that we call ‘components’, and I will be making use of this in my suggested architecture, I will explain what it means as I go along. Continue reading »

Jan 192017

How big is a project… or more specifically, how big should a DOORS Next Generation project be. Where do we draw the project boundaries in DNG. The answer, of course, is ‘it depends’, the trick is to know on what it depends.

At one extreme, you run a single project and have everything in there. At the other extreme, each ‘document’ sits in its own project. Neither of these extremes is ever likely to be useful, but there are reasons for leaning in one direction or another.

As a starting point, I would suggest considering a real world project, the scope that has a project manager, to be suitable for consideration for a DNG project. This is the same starting point that I always set for DOORS Classic, and, just as with DOORS Classic, there will be very good reasons for sometimes extending the scope, and sometimes reducing it. We start with this position because it makes sense from a language point of view, and an organizational point of view. Continue reading »

Jan 042017

p1020220It was a foggy day. Not so foggy that you needed to stay home, but one of those days where visibility was kind of OK. It was quite bright, but traveling at speed you really needed lights on. Ten years ago this would not have been a problem. Most people see the need for lights in foggy conditions, some even put fog lights on way before it is actually necessary. Last week it was a problem.

Many newer model cars now have automatic lights. The car turns the lights on as it gets dark, and off again in daylight. This is great, it catches the rare occasion where you leave a fuel station in a town at night and forget to put your lights back on, it also makes sure that you have lights on as the daylight light fades. The sensor detects ambient light and takes away one more responsibility from the person behind the wheel. The problem comes when you encounter daytime fog. The sensors detect sufficient ambient light to settle on ‘day’ and don’t trigger the headlights. Continue reading »

Dec 152016

2012-09-11-18-20-27I am going to take a look at two aspects of user access controls in DOORS Next Generation that frequently come up.

The first is how to restrict read access for some team members to some parts of the project area.

The second is how to limit who can make changes to individual attribute values.

Both of these require a little creativity in workarounds, but, in my opinion, the business needs can be met with the tool. Continue reading »

Apr 052016
Streams of Truth

One argument put forward for the use of databases, models and other data storage solutions is that we need a single source of the truth. The question that is not raised at this point is ‘What is the truth?’. We often want multiple versions of the truth. When I give data to a supplier, I […]