Posted
by
timothy
on Friday November 26, 2010 @06:59PM
from the who-asked-who-when dept.

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?"

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.

I work at an FDA regulated company and we use a hard copy document approach that was put together in the '90's, lots of paper, lots of signatures...

A few years ago we had an RFP for a requirements management system and ended up reviewing Requisite Pro (part of Rational suite) and Doors (now owned by IBM, maker of Rational, go figure}.I liked the Rational product because it allowed you to link the database to existing word docs and enter and update info either through the database app or original doc.As thin

my advice would be to avoid the integrated suite - they tend to be of even worse quality themselves than the 'hodgepodge' of tools. Also most of these suites are actually a hodgepodge of tools themselves, that you can buy piecemeal as they are too expensive to buy the 'enterprise' package.

At least the hodgepodge tools tend to be a lot better at what they do individually, a lot cheaper, faster and more reliable.

I've had the misfortune to use Serena Dimensions recently, and its a prime example of how not to w

Nothing replaces a team of guys dedicated to requirements. And a methodology. I run a critical in house application with almost 4 million lines of code (language and infrastructure are irrelevant), which has been built in multiple parallel phases over the last 10 years. We've been able to represent the solution to business' problems in code without having significant defects, or rework for that matter.

Here's all you need: (and good luck, becasue doing it right isn't easy by any means).. this does not take i

Traceability can also mean being able to hold someone's feet to the fire for doing a shitty job... or not doing it at all. e.g. "How did we leave this out?" "Let's see, programmer/analyst/dba/business analyst number one was supposed to do this." When people know they will be accountable for what they do or don't do, the task is more likely to be done, and done with better effort. Granted we need to assume people will try to do a good and conscientious job (why is generalizing about good things about people'

Isn't finding some specific person to hold responsible after a failure an example of butt covering? You aren't giving an example of how tracability actually prevented a failure, or improved quality or efficiency, just how we could use it to blame a specific low-level person instead of the team as a whole or the managers responsible for the project.

Tracing errors is useful because you can improve your process next time around, but it will do nothing to improve the current project, and it can be easily abused

Traceability requires making people responsible at the BEGINNING; so that you have something to trace. How can you trace something unless you make it traceable from the beginning?? When people are made responsible in writing, they are more apt to do the job properly since they know they have their name beside a particular action item. It seems to me that by your logic you (and I do believe many others besides you) get this strange view of traceability. That is, you have a warped reasoning that by not making

In the agile world blaming is largely seen as counter productive - in Scrum you make the fact that you "forget" to do something visible as soon as possible by interaction with the "culprit" on a very frequent basis.

In the more classical way of working you do a lot of book keeping so that after months or even years you will be able to blame somebody for doing something wrong. That is butt covering, isn't it? It doesn't help preventing or solving the problem in t

Yes, I know it's almost impossible to avoid. But if you get enough like minded individuals focusing on the problems rather than the people -- keeping standards high for both the process and the people themselves, you'll eventually turn the tide and find a workable balance.

Maybe in some places that's true. In other places traceability gets used to ensure coverage (hey, we didn't derive any design from this requirement! why not?) and to analyze change impacts (if we change this requirement, what code and tests are affected?). Recording traceability to that level is a serious amount of work, though.

I would echo Dolphinzilla's suggestions. Every proprietary vendor out there will talk about how easy it is to build a bridge to import data from other sources. Half of them make

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

That would be Level 1 of the CMMI model. That's arguable the model where most development actually occurs. My guess is that the GP is in an industry like medical devices, aerospace, or defense where the contracts require all the documentation and "process management" of Level 5.

I think onionman was driving at the distinction that Agile development tends to produce a different class of software than high-formality development. (Also that most software is the kind that Agile is good at developing, so applying too much process can stifle productivity for those.)

When the software absolutely must meet a large set of standard rules and requirements -- which is true of the three industries mentioned before, plus other fields like business accounting (due to Sarbanes-Oxley) and medical r

In other fields, "engineering" implies a degree of rigor and assurance through design approaches that is less often found in software development. Unfortunately, only a tiny fraction of programmers can deliver high-quality software when they are pushed to deliver as fast as possible; doing so requires a combination of good design and development practices with pushing back against some of the schedule pressure. Other fields emphasize those habits more often than software programmers do. I would guess tha

Of course I was rude and trolling, but for fucks sake. Their meta-meta-process makes me glad I can't find a job in that career field. It sounds a little like six sigma MBA's crossed with scientologists.

Wow. Well, thanks for proving me wrong. I can see now that you are nothing but a troll. How does that link in any way address the discussion here?

Maybe your little web admin world doesn't require the same engineering discipline but I can guarantee that any software project with hundreds of developers and life-threatening security implications do require these processes.

I'm glad that you have never been hired to be a part of one of these projects.

I think you overstate the level of complexity of software where high-maturity processes pay off. In my experience, if there are more than five to seven engineers -- of any discipline -- working on a safety-critical project, they need the kind of processes that CMMI suggests. And good luck trying to convince third parties that your product meets safety requirements without proper documentation and traceability.

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.

I am an auditor and you are so wrong!Process Control is not about checking boxes as much as having control of you processes. Checklists are a tool to do the auditing of a process, not a goal to reach in themslves.If you really care so little about your processes, come tomorrow they will byte you in the ass.You know, it's like the unfastened seatbelt that you always wear in your car "because it's less bothersome" but still fools the cops.At accident time you will be the sore ass with broken ribs.Sorry, this

I am an auditor and you are so wrong!
Process Control is not about checking boxes as much as having control of you processes.[...]
Sorry, this downplay of yours of process control systems is simply unprofessional. I had enough of the "software developers are artists that have no rules" mantra.

I don't see that he says that... Perhaps (parts of) the processes that get controlled at his workplace serve no useful purpose? Surely that's not unheard of.

I am an auditor and you are so wrong!Process Control is not about checking boxes as much as having control of you processes. Checklists are a tool to do the auditing of a process, not a goal to reach in themslves.If you really care so little about your processes, come tomorrow they will byte you in the ass.You know, it's like the unfastened seatbelt that you always wear in your car "because it's less bothersome" but still fools the cops.At accident time you will be the sore ass with broken ribs.Sorry, this downplay of yours of process control systems is simply unprofessional. I had enough of the "software developers are artists that have no rules" mantra.

Get real

I completely agree. Processes (or better process definition and control; every work place has processes, even the most crap quality messy business) are important in keeping your quality on the right level. They should never though be an end to itself. If there are processes defined that are useless and only add to extra paper being generated, cut them away. It is a continuous process. In my business (which I own), we have a monthly meeting about quality. Processes are a part of that. We realise that the ISO

I agree, complying with a bad process is often worse than not having a defined process. And it's a trap that a lot of businesses fall into.

But you don't have to adjust your workflow to match the process -- you could adjust the process to match your workflow. The auditors couldn't care less which adjustment you make, so long as at the end the documentation and the actual workflow match.

Wow... That is a rather ignorant and dangerous piece of advice you just gave. While I understand that writing software requirements and specifications isn't exactly a sexy job, and "process people" tend to create more work than they appear to be worth, they are some of the most important people in the software development process. Sure, if you're creating a new web-app designed to be used by 10 customers internal to your company, you can probably bang out the code without writing a spec, then backfill and

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

This is FALSE. In fact, "institutional causes" are ALWAYS lack of communication, lack of REAL teamwork, lot of ass-cover, responsibility avoidance, bureaucracy and fear. This is exactly CAUSED by such processes.

you know, if you *really* believed that, you wouldn't have posted it as AC. People may disagree with you, but even here you'd get a fair reception if you could hold up your end of the argument.

As it is, everyone knows you would be unable to defend that seriously. I think you need to get out more and see how the biggest, most critical software gets developed using those techniques.. and fails atrociously. There's a reason all those government IT projects fail, and those techniques are the reason, despite sou

You are right... except that in pretty much all places I have worked (ranging from small outfits to large multinationals), the processes so prevalent in IT today have proven to do a piss-poor job of preventing mishaps. In some cases they make it worse, because many people have a tendency to replace thinking with process. In fact, in some cases managers think they can get by with lesser qualified or more junior staff, because they think their processes will cover for any shortcomings. Now there's an accid

I thought twice about replying to this but I can't help myself so hear goes nothing...

1. Your (presumably bad) experience with "process people" may not be everyone's experience.

2. Slavish adherence to anything (incl. processes) MAY be ill advised at times. Typically, standards and/or processes are instituted for a good reason. This does not remove the need to consider whether they are appropriate in all cases. Process does not remove the need to think.

3. Capturing requirements is pretty useful and having a repeatable, reproducible way of doing this is also useful. Need to take over some other person's 3 year old steaming pile of spaghetti? Requirements are a good start. Need to replace a home-grown system with a market solution? Requirements are pretty useful in negotiating a contract with the vendor (unless you don't mind the vendor nailing your balls to their invoice because you couldn't actually tell them what you needed their software to do).

4. Customers typically only care about the utility, quality and cost of the end product. They care about how the sausage tastes, not how its made. However, to achieve those things you will require some process. You cannot have worked on any large project and think otherwise.

5. I agree that even where "best practice" processes are in place, there are still inordinately many failures. However in my experience (25 years), this is almost ALWAYS down to people/political issues. My own hypothesis is that there is no system, process, methodology or framework that can enforce appropriate behaviour and that cannot be "gamed". The best you can do is try and minimise the opportunities for gaming the system. Irrational agents (at any level) can (and will if given enough time) completely bugger up the best laid plans.

I agree that IT is still incredibly immature when compared to a discipline such as (say) civil engineering. However these things are all part and parcel of developing that maturity.

When I hear criticisms of IT processes like this I'm reminded of people criticising democratic forms of government and Churchill's response "democracy is the worst form of government...except for all those others that have been tried".

2. Slavish adherence to anything (incl. processes) MAY be ill advised at times. Typically, standards and/or processes are instituted for a good reason. This does not remove the need to consider whether they are appropriate in all cases. Process does not remove the need to think.

The problem is that slavish adherence to process is seen by many as a guarantee of ass-covering. If things go wrong BECAUSE of the process, the person who followed it blindly still believes that they did no wrong. I've seen important people go out of their way to defend a failing process, just because they play an important role in it, and would be uncomfortable (or perhaps fearful for their jobs or their teams' jobs) if it were to change in any way.

5. I agree that even where "best practice" processes are in place, there are still inordinately many failures. However in my experience (25 years), this is almost ALWAYS down to people/political issues. My own hypothesis is that there is no system, process, methodology or framework that can enforce appropriate behaviour and that cannot be "gamed". The best you can do is try and minimise the opportunities for gaming the system. Irrational agents (at any level) can (and will if given enough time) completely bugger up the best laid plans.

"Capturing requirements is pretty useful and having a repeatable, reproducible way of doing this is also useful. Need to take over some other person's 3 year old steaming pile of spaghetti? Requirements are a good start. Need to replace a home-grown system with a market solution? Requirements are pretty useful in negotiating a contract with the vendor (unless you don't mind the vendor nailing your balls to their invoice because you couldn't actually tell them what you needed their software to do)."

In my experience this *never* happens. Even for the little project with a 1-page document describing what the customer wants, I have scratched my head, phoned the business analyst at the customer, asked "wha?" and received a different requirement from that written down. Fortunately, in that case, we had an agile enough methodology that I could deliver what they actually wanted.

Now, for the 3,000 requirement document we receive for another project, there was no way in hell that every requirement would mesh p

upper cmmi levels are precisely for the case of a large organization composed of average contributors, who have median levels of motivation. in those cases it is a godsend, because, as is well-established by history, such organizations will fail without either (1) stellar leadership, or (2) rigorous process. and (1) is a crap shoot. now in environments with a small number of highly competent and motivated contributors, rigorous process can only lower the results to a level similar to those achieved in th

then there has to be a middle ground - perhaps a reduced functionality system with additional time & services contract afterwards for modifications, enhancements and bugfixes to bring it up to what the customer wanted, whilst still giving them reassurance that they will be delivered a reasonable system.

Alternatively, enter into a small contract for a system to gauge the competency of the supplier, then increase the size of system after they've shown they can deliver. Building trust with suppliers rather

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.

I agree with everything in the parent post but I think the last paragraph needs some clarification. You do not need to buy a tool for process development, but some tools will be required for the implementation of those processes. For example, almost all software projects will need tools for change tracking and version control processes.

Yes, you are correct. In fact there are a whole raft of tools that you probably would like to have once you know what you need. I find it interesting that the OP is asking/. about advice for tools having already built all the tools that they need. This tells me that they are likely trying to find a tool to fix process problems. That is backwards. You should fix your process and then notice that you are missing a tool (or a feature in one of your tools). Then it's pretty obvious what you need to get.

If his team is contracted to a larger organization, they may have people who can help. Some government organizations have independent support groups and research centers that can review your project and give advice. For instance, NASA has an IV&V group in West Virginia.

And if you have no processes you don't have an orgainzed business and your developers are a waste of resources doing random tasks, often time duplicating what is already there, or doing things that are not key to the business.

Brooks points out that there is always a specification, unless the project is so inchoate that it's doomed. It may be exclusively in the head of one person in the team, it may be in conflicting versions in the heads of multiple people, but it's there nonetheless.

Some specifications are better than others. A consistent specification is better than a self-contradictory one. A testable specification is better than a vague one. A specification whe

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.

Chiseling everything into stone, preferably granite, keeps this work to a minimum. I prefer to use steel, as bronze wears too quickly. Have change requests submitted in triplicate, and you will get very few.

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.

<quote><p>A dedication to process is a substitute for thinking....</p></quote>It sounds as though you have spent most of your time schlepping through cmmi process level 1 -albeit as a heroic individual (from cmmi link in tfa):

1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new process.

That's fine for lone developer projects or backscratch projects on sourceforge, but that's not the way to keep any organization with more than half a dozen programmers

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...

As a QA engineer, I only use Office 95% of the time really:) Remember, my work is to produce ISO-9001 documents, which doesn't require much more than a word processor.Now of course, we have a content management tool to organize all the junk we produce (we use Alfresco [alfresco.com]), and other services like QM, purchasing, marketing, R&D and production all have specialized software to carry out their work, but I can't tell you which because my employer forbids me to.

Good advice for capable people. For the 90% that are barely sentient drones that thank God when nobody notices that they just shit out some code that sort of works if you don't poke at it, those processes are critical. They take people that should be dunking french fries in oil and bring them to the "good enough for a Chevy" programming level required for customers that made you agree to do the work at 30% of what it should actually cost to do it right.

Good advice for capable people. For the 90% that are barely sentient drones that thank God when nobody notices that they just shit out some code that sort of works if you don't poke at it, those processes are critical.

Problem is, by having these processes and actually insisting on adherence to them, you ensure that the other 10% won't work for you for long, because there's so little no overlap between people who are competent and people who can stand dealing with "process".

Process isn't a substitute for thinking, process is a substitute for forgetting. A well designed process is simply the thing you'd do if you could keep every *actually* important detail in your head at all times.

You should certainly file bugs against a process (in the same way you would against any work product) if you perceive that a step or steps is useless or wrong.

You *are* following a process, it's just ad hoc, and maybe made up on the spot. Formalizing that process is a way to make it repeatable, and

I use the output of my test suite. Between the unit, functional and integration tests this provides a great specification of what my software is suppose to do and what the various internal APIs are. And the great thing about the test suite is that I can prove to a certain degree that the software conforms to the spec because the spec itself is executable and actually exercises the software. Specs that you can't prove are accurate are useless anyways, write a good test suite and use testing tools that output

[...]And the great thing about the test suite is that I can prove to a certain degree that the software conforms to the spec because the spec itself is executable and actually exercises the software. Specs that you can't prove are accurate are useless anyways, write a good test suite and use testing tools that output human readable results.

Tests cannot prove the absence of bugs. You should know that.

Are you saying non-functional requirements are useless just because they don't fit in your unit test framework?

No, you really can't prove anything. Code testing code is not a proper proof especially when they are both written by the same user.If I contract you to program a pacemarker, why should I trust you when you say, "look all my tests pass, therefore all requirements are met"?

Two things. First, a contract for a safety critical device (such as a pacemaker) is going to include all kinds of formal testing requirements that a one-man-shop will never be able to meet alone, so it's not a valid example. Building the test fixture for pacemakers is substantially more complex than building the devices, according to a co-worker who actually worked on building test fixtures for pacemakers.

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.

Managers hate being left out. Too bad too... Agile works quite well and generally creates good software and happy clients. Most of the process software only leaves happy sales-people. (process software sales-people specifically).

Managers hate being left out. Too bad too... Agile works quite well and generally creates good software and happy clients. Most of the process software only leaves happy sales-people. (process software sales-people specifically).

In my experience FRAgile is all about justifying business people being too lazy to come up with a spec and then when they finally do give you something (well into development) changing their mind and the spec every five minutes. They say jump. If you're "agile" you are suppose to say "how high" and they can then say "just start jumping and we'll tell you when you're up in the air". Agile only works at all if the developers have a better grasp in advance of the project starting of what the business wants.

I agree with all of this. Lots of conversations between developers and actual users, with notecards and pens. Very similar to my own experience: nothing beats discussion for the kind of small-scale projects I've worked on. "It takes a whole village to write an application."

However, I have to wonder how poorly it scales... I wouldn't trust space shuttle development if it lacked extreme process control.

When does "takes a whole village" (development team) become "takes a city planner with hundreds of subor

Scalability and process control are two different subjects, but I'll try to answer what I think your question is.

I'm mostly familiar with XP. There are a lot of other so-called "Agile" methodologies, but XP has the most well defined set of development practices. Other methodologies don't specify what you should be doing, so a lot is left up to the individuals (which can be good or bad). But just because it is "Agile" doesn't mean it isn't well controlled. For example, doing full XP you should be writin

For example, each commercial aircraft in the US has their own set of engineering designs specifically for that aircraft. Every single nut, bolt, and rivet is documented and signed off my multiple engineers - materials, electrical, mechanical, stress, etc. In the event of a plane crash, the FAA swoops in, grabs up all the pieces and reconstructs everything to determine the cause of the crash and they review all engineering drawings and documents. If the cau

Index cards alone may not be. But each story should be accompanied by acceptance tests. I would hazard a guess that a short description of what you are building followed by a rigorous set of tests that show whether or not the functionality is acceptable would be exactly what they are looking for. If the tests are automated and you can show whether or not the production version of the software passes the acceptance tests, I think you would be much better off than a standard requirements document.

Try reading that book again. Adams includes the budget process in his list of one level removed activities, and says, "You couldn't run a company, for example, without a budget process. I'm not suggesting you try." He then goes on to provide further advice, essentially that fiddling and reorganising is usually bad, while re-engineering and streamlining can be good. The latter are one level removed.

Be careful of taking simplisitic advice out of context to reinforce your own sense of superiority.

There are two ways to work - one is to plan methodically each and every aspect of what you intend to do for months then spend the 2 weeks it takes to actually do it and the other is to just asking do in 2 weeks and move onward. You seem to be of the first camp...

We use whiteboards, email, MS Word, and Visio
Works fine for a company of 30 people with a development staff of two people. And after being in large shops with all the BS you have to do to get something done, I'll continue to forgo the 15% higher paychecks and enjoy the quality of my job instead. Hourly, I'm probably making the same. Per line of code completed, probably more.

I have to agree here. You say you are a small company, in my experience requirements for even modest size projects are generally easy to manage with human language documents, just label everything for traceability. If a word processor is too awkward switch to a spreadsheet, or use them in combo. But I do highly recommend using a defect tracking database. I like Jira.

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.

I think that's a common misconception -- that being certified for some process standard such as CMMI is supposed to magically make everything you do better.

Unfortunately, I've seen a number of organizations obsess over CMMI so much that it ruined their productivity.

What CMMI is good for is making it so that when you screw up, you can look back over what happened and figure out why it is that you screwed up and prevent it from happening again. Of course, sometimes the problem is, "Implementing CMMI complete

Agreed. Process is a tool. It can solve SOME problems. It is best applied in small doses in the place where it is most needed - kind of like medicine.

I actually am a big believer in Six Sigma - it works great! (Just ask the auto manufacturers.) I don't like corporate-level Six Sigma programs. These turn into exercises where EVERYTHING is a Sigma project. Usually they involve perverse incentives (rewards to individuals for creating projects - which is what you end up with lots of).

We use Doors and I wouldn't wish it on my worst enemy. Its a fairly high end tool and probably a bit too heavy for your needs. One problem we have is that while your version control system can be distributed, doors is centralised and uses huge binary database files.

Also if everybody in the organisation doesn't work towards your CMMI goals no tool will help you.

a colleague came to us saying how crap DOORS was. We were persuaded to use Serena Dimensions for a new project, after using it for 6 months, he was heard to say that he now realises DOORs wasn't that bad.

I guess being poked in the eye with something sharp doesn't seem so bad when the poky thing starts on your balls.

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.

Sounds more like you are at Level 3, "Defined", than 2, "Repeatable"

In my experience, it takes a lot of upper management support to get to Level 3 - either that or they care only about process

As for tools, the clients of mine that have most successfully deployed such tools are the ones using a general issue management tool. Admittedly, this means a PDF or printed document ends up with a page for each requirement/specification/etc, but it allows for easy traceability and each requirement or spec has its own

I worked for a large defense contractor that writes a lot of complex software on secure systems. The only quality control tools I ever saw used were PMD, audits/standards put forth by DISA, and in depth peer software reviews.

My understanding is that at some point they decided that products like Contour are 95% bullshit and 5% use, which can be replicated by more efficient processes.

I did software development and IA, so I had a fair bit of knowledge about the processes used.

Let me recommend a book : "Lean Software Strategies: Proven Techniques for Managers and Developers".
It containes throrough analysis of craft, mass and lean production strategies and their reflections in software (CMM being on the mass side = already obsolete approach).
If you can't abandon CMM because of market conditions, think about embracing CMM with as much lean as possible as Peter Middleton describes, and find auditors who would understand and allow you advance on CMM scale without sacrificing produc

I got my Masters degree in software engineering which was largely all about project management. We even took a course from CMU on a topic that was a theory about proving the "correctness" of code without testing it. Bottom line is that when all the mucky-muck non-programmer BS dust settles, you still have to write the code. Of course, once you get a few programmers together who are working on projects that overlap, you need some way of managing the effort. In terms of butt-covering, I've heard it said t