Oct 242016

ladybirdI recently came across a project working Agile with Rational Team Concert (RTC). This is great, they have all the tracking tools they need to monitor project velocity, and to manage which stories will go into which sprint. Job done. Short blog entry here…

Oh, just one thing. Who is ever in a project that couldn’t be working just a little better. Best practice, whatever that may mean, is too often an unachievable leap away for many reasons. Better practice is very often within  the grasp of the project.

Agile stories were well documented, some better than others, but in general they fairly good, clear, understandable. The only problem is that they are in the description field of an RTC work item. This means that requirements cannot be referenced individually, and finding a single requirement can be a challenge. RTC, after all, is not a requirements management tool. I have proposed a step forward, towards best practice. Mid way through a project is not the time to leap to a different tool solution, but better practice can be achieved with little disruption. This step is one to a state of better practice. It is also a viable option for a new project starting out. Best practice, state of the art, is not what is required on all projects, and for many Agile IT projects, the rigor demanded of large defence project best practice is not only unnecessary, it can be positively harmful.

There is value to be gained from moving towards DOORS Next Generation (DNG), with a lightweight approach, the value gained should far outweigh the investment. Value comes in the forms of searchability, traceability and analysability.

My proposal is as follows:

Continue reading »

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 »