Slashdot Mirror
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?"
7" x 5" index cards, a marker pen, and lots of conversations between the people who'll really create the software and the people who'll really use it. Everyone in between can be ignored. All that other stuff you think is important... it's ceremony and job creation. Also, read the end of The Dilbert Principle - if you're one level removed from your company's core business (creating a policy and writing code rather that writing code, talking about customers rather than talking to customers, quality teams, process teams etc etc), then it's not worth doing.
This is not a sig
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
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...
We use Lifesuck Greymaker (tm), the best solution for introducing bureaucratic process into your unbridled creativity.
First I hope that your companys contracts have CMMI as a requirement, otherwise, it's far more trouble than it's worth...
There is a shed load of evidence that engineering certification will cause more problems that they solve. I.E. People don't even looking for real issues because the process will save them...
Even heard the comment, "We don't need good programmers because our engineering is so good.", that's the real problem.
I once worked at a CMMI obsessed company, the ratio of engineers to programmers was about 5-1, that's one in six people doing the work(And to get the engineers to admit that changes where needed to designs, almost more trouble than its worth; few where ever programmers, and from my perspective, if ya can't code, ya never going to be a good engineer/architect)...
Having said that, I still use many of the practices, unit testing, a variety of UML tools, SCM, there is tons of grate tools to help programmers, and if your using eclipse, all the good tools are available as plugins.
At the end of the day, CMMI also means, extremely low productivity, but if the contract requires it...
But with good programmers you can negate the need for such extreme engineering...
Nonsense. If you're *really* following Agile methods, changes mid-Sprint (or whatever you're calling your N-week unit of work) are forbidden for exactly this reason. Product backlog can be churned as much as release management would like, but the current unit of work should be immutable.
Mind you, many shops are cherry picking the wrong combination of agile concepts and making a mess of things. Sorry to hear that you've had this experience -- done right, this can be a very enjoyable approach to software development.
Worse yet, let's say instead of writing a PC app, you are writing software that directly impacts the safety of operators or other people (nuclear reactor, thermostat, aerospace, automotive, medical equipment, etc, etc, etc). It is unlikely that while "faking your way through your audits" you are going to catch those little bugs that cost people their lives. If you don't want to believe me, look up Therac-25, the USS Thresher, Black Monday, various Airbus crashes, and any of the dozens of other incidents that are a direct result of the sort of mentality you are promoting here.
Are you saying that these projects didn't have the necessary processes in place? I thought these kinds of incidents happened despite all the required processes that were in place. In fact, I believe that these accidents happened (and will continue to occur) _because_ people were _relying_ on the processes that were in place. Processes dictated from high above that were not suitable for the task.
In the given examples, it is easy to think up additional processes that could've been used in retrospect. Everyone has something to say about that, but how many people got to read the code to verify that the additional process would've prevented any given problem? How do these processes prevent integer overflow and race conditions?
Let's examine the examples:
Therac-25 - http://en.wikipedia.org/wiki/Therac-25
No mention is made of any of the processes that were in place. The list of "institutional causes" can be addresses through process, but how would that solve the specific software-related "engineering causes", like arithmetic overflow, not like "open-loop controller"?
USS Thresher - http://en.wikipedia.org/wiki/USS_Thresher_(SSN-593)
Disaster occurred _despite_ the processes in place. It seems to me disaster could have been prevented by an experienced officer, rather than the inadequate process of the time: "Jim Henry, fresh from nuclear power school, probably followed standard operating procedures and gave the order to isolate the steam system after the scram, even though Thresher was at or slightly below her maximum depth and was taking on water. Once closed, the large steam system isolation valves could not be reopened quickly. Reflecting on the situation in later life, McCoole was sure he would have delayed shutting the valves, thus allowing the ship to "answer bells" and drive herself to the surface, despite the flooding in the engineering spaces. Admiral Rickover later changed the procedure, allowing steam to be withdrawn from the secondary system in limited quantities for several minutes following a scram."
Black Monday - http://en.wikipedia.org/wiki/Black_Monday_(1987)
I don't see how this is related to software engineering. The business requirement of "portfolio insurance" implemented in software that will always cause this kind of crash - see May 6, 2010 flash crash.
Perhaps the GP could've expressed his sentiment differently: Take responsibility. Concentrate on building the piece that you are responsible for as well as you can. Understand how it affects other parts of the system as best as you can. Let the people who care about processes and CYA techniques worry about processes and CYA techniques, but limit their involvement as much as you can.
My point?
1. The more regulated the environment, the more people will focus on CYA and avoiding responsibility.
2. Your process will never prevent all possible disasters, but it will create a sense of comfort that prevents people from worrying about it.
Enterprise Architect is very nice, since you can do forward and reverse software engineering with it.
However, if you do not have the budget allocated for it, a good compromise is StarUML,
which became very nice and usable lately and has the same "feeling" and menu-driven approach
like the old Rational Rose and Enterprise Architect:
http://staruml.sourceforge.net/
http://sourceforge.net/projects/staruml/files/staruml/5.0/staruml-5.0-with-cm.exe/download
As for Rational Rose, the first original version was very good with some known quirks until it
became IBM Rational Rose and was converted into a "super Eclipse" plug-in.
So, if you enjoyed drawing UML diagrams in the old Rational Rose,
then Enterprise Architect and StarUML are the tools that you are looking for.
And if you do not like to draw with a mouse then Graphviz Dot and a good text editor is for you:
http://www.graphviz.org/Download.php
For tracking issues / documents and schedule,
I can recommend either BugZilla, Mantis or BaseCamp:
http://www.bugzilla.org/download/
http://www.mantisbt.org/
http://basecamphq.com/
As for the actual writing part, your company should already have a good set of Word Templates,
to document the actual Sofware Requirement and Specification (SRS), Sofware Design Document (SDD),
Change Request Document (CRD).
Once, you got those set up, then we mostly use MantisBT or BaseCamp to share, comment and track them.
As for producing code documentation, the choice are: Doxygen, JavaDoc, NDoc, JsDoc:
http://www.doxygen.org/
http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html
http://ndoc.sourceforge.net/