What Software Specification Tools Do You Use?

IronWilliamCash writes "I currently work for a small software development company and for many years we have been using internally built tools for all our software specifications, bugs, change requests and the like. Traceability is a big issue as we are CMMI level 2, and thus our internal processes need to be clear and everything must be documented. We are currently looking into getting a unified solution for this, and after quite a bit of Googling, there are quite a few different options (Contour, Kovair, MKS, Doors, CaliberFM, Accept360, etc.). I was wondering: what do other Slashdotters use in their everyday life? Does it fulfill your needs? And what is the most important part in a specification management tool?"

Comments

My sympathy for you

[Dolphinzilla]

If there is one thing that can suck the fun out of software development and engineering its requirements traceability tools - My company is CMMI level 5 and we use Doors, Rational ClearQuest and ClearCase, Teamcenter and others. As much as I hate them they have their place and on rare occasions are even useful. My best advise would be to find an integrated suite and avoid having a big hodgepodge of different crap that has to be glued together with third party applications.

Re:My sympathy for you

[Nerdfest]

Traceability=Butt covering over efficiency.

Not always true of course, but there's a strong correlation.

Word to the wise

[Rogerborg]

Do the absolute minimum amount of work that it takes to fake your way through your audits. Process People are a cost to your business, not an asset. If you invest time in processes, then you are not producing anything that your customers want to pay for - all CMMI/ISO compliance is about their Process People ticking the boxes that say your Process People have ticked their boxes.

Re:Word to the wise

[wrook]

People, in general, are a cost and not necessarily an asset. Making sure all your activities are returning value is an important part of running a business. More warm bodies looking busy doesn't make you more efficient, that's for sure. And in many large organizations I've worked in the "Process People" have often been "warm bodies looking busy".

However, there is a difference between a bad idea and a bad implementation. Having been involved in CMMI/ISO audits I have seen what kind of joke it can be. Those warm bodies are doing exactly what you suggest -- the minimum to pass their audit (which is barely anything at all, if I am honest -- mostly running around hiding evidence that the process is not being followed). But ISO and CMMI is not to blame for this injustice. The problem is those warm bodies and attitudes like yours.

Most "Process People" sit around fantasizing about what process everyone should follow. Then they write it down and tell everyone to follow it. Never mind that they have never actually seen what people are actually doing now. This is precisely the opposite of what is recommended by these meta-processes. How many times have I heard, "Well, normally it takes 5 years to get to CMMI level 4, but I think we can do it in 2 months if everyone cooperates"? Having said that, they have demonstrated their ignorance for any point at all in CMMI.

Document what everyone is doing. Not what they say they are doing; not what they want to be doing; not what you wish they were doing; what they are actually doing. That's your process. Compliance? Dead easy. They are already doing it. Documentation? It's not exactly rocket science. Make sure people put version numbers on documents. Or better yet, put everything in an SCM and say that all paper versions are merely drafts. Done.

You are right that you should do the very minimum that you can do with ISO and CMMI. Not because it is a waste of time, but because sitting around concocting elaborate plans for a cool process doesn't align with reality. Neither ISO nor CMMI tells you what you should be doing in your process. It tells you what you should be observing and thinking about. For level 2 you can write down pretty much anything you want for each section.

But the point is, once you have everything written down you can look at it and say, "Hmmm... we have some inefficiencies here. Bob, if you were to do X before Y it would help out Sally. Would that be OK?" Also, having written everything down it makes it easy for new people to come in and get an idea of the existing culture without having to discover it through trial and error. It allows them to quickly identify areas that they may want to change -- "You know guys, in my last company we did X. What do you think".

As you may have guessed, I have had the misfortune of being one of those "Process Guys". I prefer coding, but sometimes you have to do what you have to do. In my time as a process guy I tried to spend 80% of my time documenting what people were doing, identifying things that had changed over time and asking why the changes were made. I spent 10% measuring various things and making pretty graphs for upper management. I spent 10% of my time giving advice for things that teams might want to try to improve their efficiency. I spent 0% of my time enforcing compliance. If people didn't follow the process, then the process was wrong. I think that the fact that my management preferred me to do this work than write code (despite my protests) says something about the value I returned to the company.

Finally, to answer the question of the OP -- Don't buy a tool. A tool models someone else's vision of reality -- not what your people are actually doing. If you buy a tool off the shelf then you will spend most of your time chasing compliance rather than improving workflow. It really will be a waste of time and money.

Re:Word to the wise

[UnderCoverPenguin]

Yep. Most process people are truly only concerned with process. ... You can have a good process, but the resulting software is wrong. ... However, most auditors lack context when they evaluate process.

In my experience, the auditors are looking far more at compliance with the process then the process's compliance with business needs.

It depends on the platform

[BadAnalogyGuy]

You really need to nail down exactly which platform you're talking about because the choices will differ depending on the platform.

For example, on Windows, you have either Notepad or WordPad. Now, I like Notepad because of its simplicity, but other people like their proportional fonts and formatting crutches. I guess you could splurge and go for something like Microsoft Word, but that's really overkill for most specification purposes.

Now if you're on Linux, you have a ton of choices. The easiest is Pine. If you've used Notepad, you'll most likely be able to pick up Pine pretty quickly. On the other hand, if you like needless complexity, vi might be the specification tool for you. You can do stuff like search based on regexes and copy and paste whole lines of text at once. If you're looking for something more fully featured, a lot of Linux platforms come with Emacs. I think it is a lot like Microsoft Word in that it has too many features that are simply unnecessary, but a lot of people like it.

Of course you're not using a Mac since these are not really programmers' tools. But if you are, I know there is a way to dual boot your system into Windows and get the full power of Windows without having to buy a separate PC. That's a pretty good deal.

When it comes to specifications, completeness, detail, accuracy, and readability are the most important things. Notepad and Pine are excellent tools to help you pound out good specs.

Re:It depends on the platform

[onionman]

Are you fucking kidding?

Asking that of BadAnalogyGuy is like asking a car if it meant to be on asphalt.

Yay process

[The End Of Days]

A dedication to process is a substitute for thinking. When the processes become more important than the product, quit. That's the only advice I can give you. I'm aware that's not what you asked, and I'm almost certain you won't listen, but really, that's what I have to say.

Re:Yay process

[Roland Piquepaille]

A dedication to process is a substitute for thinking.

If I didn't work as a QA engineer for a huge ISO-9001 company that absolutely looooves paperwork and red tape, I would print your sentence in huge letters and tack it above my desk at work. This is so true.

The problem with processes is, you need them to interface with customers that require it. Otherwise you miss contracts and opportunities. Unfortunately, QA of the kind I do (and the kind the OP seems to want) is a surefire way of turning a nimble, reactive, cheap small company into a stuffed up, slow, expensive and impossibly non-competitive one.

I hope the OP has a good reason to want more of that shit for his small company, because otherwise he'll be well on his way to hiring a lot of overpaid people who spend their days writing QA documents, norms, purchase specs, acceptance specs, procedures, test reports, waste kajillion reams of paper every day printing all that shit, travel all over the country to attend meetings with others of their ilk to discuss more forms, and generally waste everybody's time and money. I should know, that's what I do for a living...

CMMI - religion masquerading as whatever it is

[dread]

Listen. I've spent far too many of my working years dealing with companies that have caught religion of some sort. It doesn't matter which one it is, be it ISO, CMMI, Six Sigma or some virulent form of agile (yes SCRUM people, I'm talking to you); its a religion. Instead of focusing on the business and developing sound processes that fit the business model and the company culture these companies put in place this huge infrastructure hoping that this will make them automatically successful.

It doesn't.

It does kill whatever passion there is though. Yes that goes for agile too but in other parts of the company than the one you might be sitting in.

These days I have a good rule that works - when a company tries to sell me services based on being CMMI level 5 I tell them to far, far away and preferably perform some acts that are illegal in several states. After having dealt with a couple of them I have realized that the only genuine thing generated is a huge paper trail and innovation is dead or dying.

As to your question - I don't know and I don't care. I can only make the friendly suggestion that you look for work in a place that doesn't focus on religious adherence to principles defined elsewhere. I promise you that it'll be more fun, challenging and ultimately interesting.