Software Traceability

I know that there are a few guys out there in the development game, so the question is, do you use, or have you been forced to work with traceability?

I'm currently looking into setting up traceability in a large scale RUP based project, unfortunately the project is well under way and I can't justify the cost and delay of back implementing all the necessary checks.

I know what I'm doing with it but wondered if others here had any experience with it.

Thanks.

 

Don't use it, but nearly all the software we write is only used in-house anyway so not an issue. What's the objective? Piracy prevention?

Michael.

 

Traceability in that making sure all of the actual requirements have been developed, no new artifacts have been added along the way (developer gold plating) and what was promised has been delivered.

e.g. how do you know what you developed was what was asked for...

 

Is there another term of this? I have done quite a bit of this but the area I have done is more with regards to end user design rather than the actual software engineering side of it. It sounds like its very much a project management issue.

 

sounds like you want some way of controlling creeping featurism. simplest way i can think of is to pay the developer(s) by the feature. that way you definately won;t get anything extra and if they don;t impliment the feature to requirements they don;t get paid. this is only half tongue in cheek.
cheers


julian

 

Oops...looks like I got totally the wrong end of the stick :shame:

Never heard of that as a concept with a name and I'm not aware of any methodologies that guarantee it. Unless requirements have been extremely well defined there's usually some interpretation as to whether the requirement has been met or not.

Scope creep is endemic in projects I've worked on as the business can never make their mind up what they want!

Michael.

 

Scope creep can be stopped by various methods, although its easier to do this if you are an external company than working internally. Stopping developers gold platting is harder.

Traceability allows both forward and backward tracking of any artefact, so a test case can be traced back to a requirement, whilst a requirement can be traced to a GUI for example. This method allows people to see the impact on all project artefacts when a change in requirements is made.

Yes AT it is a PM responsibility to ensure traceability is used whilst its all the project teams role to ensure it is adhered to.

Paying developers by the feature really works well for bug fixing, not sure I'd use it for a mass developement though.

 

Philip,

traceability is a term I've seen used for this, or the wider umbrella term "Software Quality Assurance". Human medical devices software has been subjected to this for some time, and you may find some useful information at the US FDA (Food and Drugs Administration), who approve (or otherwise) any medical device used in the USA. They started crawling all over developers in the early 90s, when they finally twigged the effect that software had on overall performance! Another source of methodologies for traceablility was TickIT (slightly out of things now so not sure if there's a current successor to that). My experience of ISO9000/1/2/3 was that it was all written by and for project managers and was far more concerned with getting projects delivered on time and budget than making sure the resulting product (er...what's that?) actually worked.

The main strictures in the system I had experience of IIRC were that all material facts in a document should be in numbered paragraphs, with only one fact per paragraph, and there should be a cross reference for each such paragraph between documents (which sort of fitted within the good old-fashioned Waterfall model). This still rather begs the question though of verifying that the written code actually matches whats in the detailed design. The other perennial question, with such highly segmented statements is checking that the big picture functionality (at the detailed level - if that makes sense) isn't lost. Probably the best way of doing this is to keep referring back to the original use-case analysis (assuming you did this to gather the initial requirements - it may well be retrofitting if you didn't).

I also once had a guy working for me who was keen on "Z" as a design language, which results in a very formal algebraic design - which allows algebraic proof than the design works. We didn't use this though (I think he picked this up working as a contractor for a defence customer) as the design effort was so onerous that most commercial companies would have gone bust long before a line of code was written.

 

Nice reply Graham thanks, yes we are using Use Cases, and modelling in XDE, this allows us to create links from packages to use cases to realisations through to actual components, these can then be traced back via test scenarios.

Our issues come from not knowing at what point to stop within the design process.

Most of the thinking for traceability seems to have come out of either the medical, food or airplane industry.

Gonna have to look into Z, seems like it could really confuse a few people!