Aug 052016
 

2012-07-14 14.26.45IoT is almost everywhere, even where it has not reached, it is either assumed or talked about. It is in our homes, our wearables, our cars, it is in our public buildings, cities and transport. Surely designing for all these ‘Things’ must come with special challenges and need new techniques and tools?

If we look at the technology to solve a problem twenty years ago, and look at the technology to solve the same problem today, then yes, the two are vastly different. We typically have more software included, and there are some features now that were not considered then. This change has mostly happened slowly. This year’s car has been a small improvement over last year’s. I have a remote control for my TV – how about I put one with the central heating controller.

IoT does bring some interesting challenges, particularly in the areas of security and standards, but much of it is a small step on from what we had before. I worked on equipment in the mid 1980’s that had BIT, Built In Test, it put a code on the simple front panel display to show the result. Many things now have self-test, diagnostics, or predictive maintenance features, but they send the result over the internet and become part of the Internet of Things.

When we design for the IoT, we still have to have the core functionality, and all the challenges that gives us. Understand the need, understand the environment into which the system or equipment will fit, understand the operation and disposal parameters. Requirements, modelling, testing, and such things. We already have tools for this, we already have processes to support this.

So what is really different? Continue reading »

May 062016
 

2015-07-10 12.18.31In DOORS Classic we have a Module prefix; every requirement (Object) has a number that is unique within the module, and every requirement in a module has the same prefix. The prefix is user defined, and so not guaranteed unique in the database, or even the project, but that is what we are used to, and we like it, mostly.

DOORS Next Generation gives every requirement (artifact) a number that is unique within the database, but there is no prefix. Technically, we don’t need it, we have a better way to pinpoint the exact requirement of interest – using that unique-within-the-database number, but migrating people is nothing like as easy as migrating data.

Continue reading »

Apr 292016
 

2015-08-30 12.53.03I have been working in a small team this week on setting up a framework for a large project. We had all of our toys out of the box and it was important to make sure that everything was correct. We had DOORS Next Generation, Team Concert, Quality Manager, Design Manager, and RELM, sitting in the background were the Lifecycle Query Engine, Jazz Reporting Service, Global Configurations and Lifecycle projects. In total there were around 30 Project Areas created across the different applications and in four separate lifecycle projects.

I first created a picture showing the project areas and how they fitted into the lifecycle projects. Just a simple PowerPoint slide with some coloured boxes. The important part here was to get the finalised names written down. You can see in the image below the general layout, although I have anonymised the names here. Continue reading »

Apr 052016
 

pansiesOne 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 might choose to withhold some facets of that data; reasons for decisions, cost expectations, future plans. As a supplier, I have to give data back to the customer, and again, I might choose to withhold some facets. This is all normal practice, and is generally handled by having an external facing set of information, and a more detailed internal facing set.

In a little lightbulb moment, I connected this problem of multiple sets of the truth, with the DOORS Next Generation configuration management capability. Continue reading »

Dec 082015
 

TornadoThis is not a new question. We have been struggling with managing traceability to standards for as long as we have had the concept of traceability to standards.
In the DOORS Classic World we had a few options, and we still have those options with DOORS Next Generation, but we also have a couple of new options. I am going to look at this fresh and go over the pros and cons for the various methods in DOORS Next Generation.

I will look at the following methods:

  1. Attributes
  2. External link
  3. Separate module and link
  4. Separate module and reuse
  5. Separate module, reuse and link
  6. Glossary terms
  7. Glossary and link

Continue reading »