Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What Software Specification Tools Do You Use?

timothy posted more than 3 years ago | from the who-asked-who-when dept.

Programming 200

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

Sorry! There are no comments related to the filter you selected.

Notepad++ (-1)

Anonymous Coward | more than 3 years ago | (#34354258)

Works for me.

W

My sympathy for you (5, Insightful)

Dolphinzilla (199489) | more than 3 years ago | (#34354264)

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 (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34354428)

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Re:My sympathy for you (4, Insightful)

Nerdfest (867930) | more than 3 years ago | (#34354458)

Traceability=Butt covering over efficiency.

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

Re:My sympathy for you (2)

theshowmecanuck (703852) | more than 3 years ago | (#34355640)

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's behaviour OK, while generalizing things perceived as bad, is bad? I digress...) but we all know this isn't always true.

Re:My sympathy for you (1)

onionman (975962) | more than 3 years ago | (#34354524)

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding 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.

Re:My sympathy for you (1)

davecb (6526) | more than 3 years ago | (#34355084)

Oddly enough, that's also a way to achieve the same ends as CMMU level 5, optimizing.

Both aim at aligning the process with the business ends, and increasing the value of the process to the business.

Mind you, except for that homomorphism, they're orthogonal (;-))

--dave (who's customers are in both worlds) c-b

Re:My sympathy for you (3, Informative)

JamesP (688957) | more than 3 years ago | (#34354544)

rational tools are anything but rational

I absolutely will think twice before taking a job that requires them.

However, one tool that I found to be extremely useful amd totally worth its price is Enterprise Architect. I don't remember if it does requirements

Re:My sympathy for you (0)

Anonymous Coward | more than 3 years ago | (#34354582)

boy do I agree with that ! (we call them Irrational products) EA is however an excellent tool we use that as well - in fact as I am thinking about the sheer number of tools we have to do this it occurs to me that the community benefiting most from ISO/CMMI is the vendors that are making these software tools - looks like a classic case of a self licking ice cream cone...

Re:My sympathy for you (1)

wmac (1107843) | more than 3 years ago | (#34355362)

It does requirements and I agree with you. It is dirt cheap but if IBM wanted to specify a price for it, it would be a 4 digit.

I am using it for almost 8 years and I would never use rational over it at least for small to medium size projects.

BTW it does reverse engineering, bug etc. But I am not sure how effective is the collaboration possibilities. I am aware that the corporate version can be deployed in a database server (MySQL, MS-SQL etc) and that should be enough.

Re:My sympathy for you (1)

JonySuede (1908576) | more than 3 years ago | (#34355540)

Enterprise Architect is quite good, here at work we use that and yes it does requirement

Re:My sympathy for you (1)

jgrahn (181062) | more than 3 years ago | (#34356042)

rational tools are anything but rational

I absolutely will think twice before taking a job that requires them.

Specifically, Requisite Pro is a joke and ClearQuest is only semi-usable.

However, one tool that I found to be extremely useful amd totally worth its price is Enterprise Architect. I don't remember if it does requirements

And I'm one of the few who like ClearCase. Rational bought and rebranded (added phrases like "Clear" or "Rose" to the name) various software over the years, so some may still be decent.

Re:My sympathy for you (1)

garyisabusyguy (732330) | more than 3 years ago | (#34354742)

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 things go, we got Doors and were unable to successfully integrate it with our systems

In the mean time we have settled on MS team foundation server for a code repository and HP quick test pro and load runner for testing.

The newest version of HP quality center now has a requirement management piece and does good traceability to the tests, and we are looking at using it, which might have a chance since we are already using other HP tools.

fwiw, I enjoy working in a well regulated environment since it provides a lot of coverage to avoid crap code in production and makes maintenance a hell of a lot easier

Re:My sympathy for you (1)

adin (60273) | more than 3 years ago | (#34356196)

Rational used to have some real problems if word munged the docs at all; I've seen the database get out of sync with the word files many times. After quite a bit of rework getting stuff back in sync or reverting to backups, we gave up. We were far enough into the process that I just rolled my own database. The cost of a week or two's work was significantly less than something like Doors and gave us all the basics we needed for managing requirements and bugs all the way through the program's lifecycle. Last I heard it was still in active use over several projects.

Sometimes rolling your own isn't a complete nightmare, especially if someone on the team really understands the needs and processes (which is the *point* of CMMI).

Re:My sympathy for you (1)

lsdi (1585395) | more than 3 years ago | (#34355726)

Last June I became CIO at a company that was CMMI level 2. I took a great risk and I quit that crap, fired every single selfish unproductive butt-covered developer and built a new team with 1/3 of developer we had before. Developers that couldn't do anything besides software got fired also (not one SJCP/OCP/MSC kept his job). Results? Productivity skyrocketed, happiness too, developers are also stakeholders now. Problems? Developers take at least 3 months to learn their business. I work for a credit card company. CMMI == bureaucratizing the chaos. BTW, they are not even called developers anymore, some of them even found new careers. I feel great when I know a competitor is using CMMI. We deliver, they just brag.

CMMI = Engineering gone mad! (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34355756)

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

Re:My sympathy for you (1)

B4D BE4T (879239) | more than 3 years ago | (#34355778)

I work in a similar environment: CMMI level 5 using DOORS (requirements management), ClearQuest (bug/change tracking), and ClearCase (code versioning). Personally, I don't like any of these tools. They're slow, expensive, and generally a pain to use but they get the job done. There are open source alternatives and, although I have not used these myself, I hear they are faster, easier to use, and cheaper (free). For code version control there is Git, CVS, SVN, etc. For change tracking: bugzilla. For requirements management, any database software should do. Our process documentation is written in Word documents and posted to an internal website.

Re:My sympathy for you (0, Flamebait)

gandhi_2 (1108023) | more than 3 years ago | (#34356036)

All you motherfuckers sound like scientologists.

Re:My sympathy for you (0)

Anonymous Coward | more than 3 years ago | (#34356158)

My company is CMMI level 5 and we use Doors, Rational ClearQuest and ClearCase, Teamcenter and others.

I'd say that Doors is the end of software specification, my friend.

Word to the wise (4, Insightful)

Rogerborg (306625) | more than 3 years ago | (#34354270)

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.

sounds like you work at a dilbert work place (1)

Joe The Dragon (967727) | more than 3 years ago | (#34354594)

sounds like you work at a Dilbert work place

Re:Word to the wise (2, Informative)

Anonymous Coward | more than 3 years ago | (#34354598)

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

Re:Word to the wise (0)

Anonymous Coward | more than 3 years ago | (#34354790)

You're telling the driver to wear seatbelts, but forget that it's the driving that gets the goods delivered, and it's the driver that's doing it. Really, processes aren't that important.

Re:Word to the wise (0)

Anonymous Coward | more than 3 years ago | (#34354986)

Yep. Most process people are truly only concerned with process. Well, process does not mean quality. Process is process. You can have a good process, but the resulting software is wrong.

The only reason for process is to automate the mundane. If I don't need to think about it, that's where process shows it's colors. However, most auditors lack context when they evaluate process. It's frustrating.

Re:Word to the wise (5, Insightful)

UnderCoverPenguin (1001627) | more than 3 years ago | (#34355322)

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.

Re:Word to the wise (1)

jgrahn (181062) | more than 3 years ago | (#34356096)

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.

Re:Word to the wise (3, Insightful)

Anonymous Coward | more than 3 years ago | (#34354672)

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 BS your way through the documentation and testing.

If, on the other hand, you are writing large-scale software that will be used by thousands or millions of users on a variety of platforms, with a variety of hardware, and a variety of user expertise you would likely be complaining about all these "new requirements" that keep creeping up late in the game. These are the very same requirements that should have been caught in the spec sheet by those people who are a "cost to your business". 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.

The next time you recommend someone just "do the minimum amount ... to fake your way through your audits" think of how comfortable you would be with the guy who developed your cruise control system thinking that way, or maybe the guy designing the chemical processing plant a few blocks away, or maybe designing your neighborhood water treatment facility.

Re:Word to the wise (3, Insightful)

BlackSabbath (118110) | more than 3 years ago | (#34354732)

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

Re:Word to the wise (2, Insightful)

plover (150551) | more than 3 years ago | (#34355420)

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.

In any modestly sized organization (or larger), you will find a number of people are going to behave this way regardless of the process. Adding more processes (such as checklists, tollgates, audits, etc.) in an attempt to make the system game-proof takes the system in the wrong direction. The best approach I've found is to involve the dissenters in changing the process -- give them the opportunity to improve it. The hope is that they'll see that other people recognize they play a valuable part in the process (removing fear), they'll see the amount of compromise that goes into making some of the weird decisions (getting the bigger picture), and maybe recognize that they can never get 100% of what they want. But if they feel they are a part of it, and are able to address the most egregious violations of sanity they have to deal with, they usually accept the new situation.

Re:Word to the wise (0)

Anonymous Coward | more than 3 years ago | (#34355686)

In any modestly sized organization (or larger), you will find a number of people are going to behave this way regardless of the process. Adding more processes (such as checklists, tollgates, audits, etc.) in an attempt to make the system game-proof takes the system in the wrong direction. The best approach I've found is to involve the dissenters in changing the process -- give them the opportunity to improve it. The hope is that they'll see that other people recognize they play a valuable part in the process (removing fear), they'll see the amount of compromise that goes into making some of the weird decisions (getting the bigger picture), and maybe recognize that they can never get 100% of what they want. But if they feel they are a part of it, and are able to address the most egregious violations of sanity they have to deal with, they usually accept the new situation.

Very well said!

Re:Word to the wise (5, Insightful)

wrook (134116) | more than 3 years ago | (#34354736)

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 (3, Insightful)

B4D BE4T (879239) | more than 3 years ago | (#34355868)

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.

Re:Word to the wise (2, Insightful)

garyisabusyguy (732330) | more than 3 years ago | (#34354796)

Oddly enough, quality is something that people will pay for, if they are aware of how much it affects their enjoyment of the product

It becomes more apparent when a failure in your product has the ability to kill a lot of people

It is also apparent (maybe to a lesser degree) if the low quality product cannot interface with other systems or fails in a short amount of time

How much loss of revenue due to turning out poor products does it take before the bean counters understand the value of change management?

Re:Word to the wise (1)

nurb432 (527695) | more than 3 years ago | (#34354968)

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.

It works both ways ya know, everyone is a part of the larger puzzle.

Fred Brooks (2, Insightful)

Beryllium Sphere(tm) (193358) | more than 3 years ago | (#34355110)

As usual, The Mythical Man-Month cuts to the heart of the matter.

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 where you can map items to their corresponding tests helps with getting all the bases covered without wasted effort.

If you're free to do so, call the revision control system that holds your tests the "specification tool".

Re:Fred Brooks (0)

Anonymous Coward | more than 3 years ago | (#34356234)

Good point, but....

unless the project is so inchoate that it's doomed

I don't think that word means what you think it means (from the New Oxford American Dictionary as presented by the Mac Dictionary.app):

just begun and so not fully formed or developed; rudimentary : a still inchoate democracy.

USAGE Because inchoate means 'just begun and so not fully formed or developed,' a sense of 'disorder' may be implied. But to extend the usage of inchoate to mean 'chaotic, confused, incoherent' (: he speaks in an inchoate manner) is incorrect, although not uncommon.

This completes our pedantic English digression, we now return you to our regular digression about what requirements actually are

The preceding almost certainly contains a minimum of one error in English grammar, spelling, or usage.

Re:Word to the wise (0)

Anonymous Coward | more than 3 years ago | (#34355942)

Speaking of which.. I thought that companies never used CMMI, since it made management types have to participate in the exercise rather than simply punishing the programmers.

It depends on the platform (5, Funny)

BadAnalogyGuy (945258) | more than 3 years ago | (#34354274)

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 (0)

Anonymous Coward | more than 3 years ago | (#34354306)

Are you fucking kidding?

Re:It depends on the platform (2, Informative)

Anonymous Coward | more than 3 years ago | (#34354350)

Yes. Of course real programmers use Notepad++.

Re:It depends on the platform (1)

VTI9600 (1143169) | more than 3 years ago | (#34354362)

Are you fucking kidding?

Yes, I think it's quite clear that he is. Good day and a fine "woosh" to you, sir!

Re:It depends on the platform (4, Funny)

onionman (975962) | more than 3 years ago | (#34354556)

Are you fucking kidding?

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

Re:It depends on the platform (1)

Mitchell314 (1576581) | more than 3 years ago | (#34354604)

If he was kidding, he would have said ed, not vi/emacs.

Re:It depends on the platform (0)

Anonymous Coward | more than 3 years ago | (#34354622)

Sorry but I didn't laugh.

We use Microsoft Excel to do all of the tasks the OP mentions.

Fortunately, we are allowed to use version control software, instead of copy-pasting into Excel sheets. Unfortunately, it is Microsoft VSS which means Excel would be far more reliable.

Hacking embedded system code for a living is too fun to quit, though.

Re:It depends on the platform (2, Informative)

BadAnalogyGuy (945258) | more than 3 years ago | (#34354906)

I'm laughing.

at you.

Re:It depends on the platform (1)

Thing I am (761900) | more than 3 years ago | (#34355048)

I use Pine to check the system email on a few servers. Very efficient and easy to use.

Re:It depends on the platform (1)

NicknamesAreStupid (1040118) | more than 3 years ago | (#34355804)

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.

Re:It depends on the platform (1)

DynamiteNeon (623949) | more than 3 years ago | (#34355978)

tl;dr: Try to fit your process to reality and not force reality into a process.

Unfortunately, it's all too common to have processes that just get in the way of getting useful work done in larger companies.

Yay process (5, Insightful)

The End Of Days (1243248) | more than 3 years ago | (#34354276)

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 (2, Insightful)

hguorbray (967940) | more than 3 years ago | (#34354416)

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

No matter how good a thinker or programmer you are, there will probably come a time when you are not there or not available and without process (and it's partner, documentation) the ordered development of the code you were working on will be very difficult for those who follow.

I've been dealing with that mindset at my current company -they have a 20-year history of seat-of-the-pants programming with little documentation and most of the important details of the various server products in people's heads -some of whom are not that far off from retirement....

and it has been one of my tasks to try to get all of the processes and products documented so that we can pass off the work when it is time -not to mention satisfying SoX compliance and pending ITIL process implementation.

But I still can't get some of the developers to help me document their products/processes because they are constantly running around duct taping some of our ancient, barely understood core products -because at the time no one cared about process and/or documentation. Most of them still don't today, sadly.

-I'm just sayin'

Re:Yay process (1)

geezer nerd (1041858) | more than 3 years ago | (#34355284)

I had to live with this kind of environment for most of my career. Frustrating in the extreme.

I recall a big meeting held in the development department of the company I worked for in the mid-90's, the meeting being a post-mortem review of a recent product release. In the midst of a somewhat heated discussion about process, one of the senior development directors said: "But we don't have TIME to do it right!". Yessir, 'nuff said.

Re:Yay process (1)

JonySuede (1908576) | more than 3 years ago | (#34355490)

1. Initial (chaotic, ad hoc, individual heroics)

being a hero is fun

Re:Yay process (0)

Anonymous Coward | more than 3 years ago | (#34355580)

They don't document because it's not a deliverable and they are not judged on it.
At the end of the day, if the system works, but there is no document, they are seen as doing their job.
If the document is perfect, but the system fails, they are seen as failing.
So, they're just behaving rationally.
You won't be able to change it until you can change the deliverables.

Re:Yay process (5, Interesting)

Roland Piquepaille (780675) | more than 3 years ago | (#34354434)

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

Re:Yay process (1)

VTI9600 (1143169) | more than 3 years ago | (#34354538)

[...] and generally waste everybody's time and money. I should know, that's what I do for a living...

Right, right, but what *software* do you use for this? And how may we contact you to inquire about obtaining a cost estimate for your services?

Re:Yay process (1)

Roland Piquepaille (780675) | more than 3 years ago | (#34354638)

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.

Re:Yay process (1)

AlbertinaJane (978419) | more than 3 years ago | (#34355064)

Smells like Siemens....

Re:Yay process (2, Insightful)

CosmeticLobotamy (155360) | more than 3 years ago | (#34354438)

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.

Re:Yay process (1)

russotto (537200) | more than 3 years ago | (#34355456)

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

Re:Yay process (0, Troll)

davecb (6526) | more than 3 years ago | (#34355172)

A dedication to process is a substitute for thinking.

It is, and when I'm too scared and exhausted to think, it's a lifesaver. That's why soldiers practice a LOT.

Good practices that have become habit are genuinely beneficial. Bad practices imposed from without get you killed.

Chose your practices well.

--dave

My Test Suite (1)

jwthompson2 (749521) | more than 3 years ago | (#34354304)

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 human readable results. Since I work in Ruby predominantly those tools would be mini-test, test-unit, rspec and cucumber.

Re:My Test Suite (0)

Anonymous Coward | more than 3 years ago | (#34354936)

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

Re:My Test Suite (1)

plover (150551) | more than 3 years ago | (#34355558)

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.

But if someone runs the tests your mythical lone cowboy wrote, and says "look this test failed, you'd kill someone with this code, go back and fix it," I'd believe that a lot. I'd feel better about someone with "white box knowledge" writing a strong testing package than adding someone with only "black box knowledge". The white box author will understand the edge cases better.

Of course it doesn't prove a negative, and the single author writing their own tests won't catch all the missing cases, which is your point. I get it. But enough test cases and proper management of them can ensure that mistakes made before aren't repeated. Test cases can be engineered to thoroughly cover expected situations. Writing those test cases can lead you down additional code paths, and lead you to recognize new unhandled cases. And different kinds of testing (such as fuzzing) can be automated to give you some confidence that your product will work even in the presence of unexpected inputs, errors, and even malicious attacks.

Re:My Test Suite (1)

jgrahn (181062) | more than 3 years ago | (#34356140)

[...]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?

How about... (0)

Anonymous Coward | more than 3 years ago | (#34354316)

...a word processing program and a person who knows how to write well? For extra credit, add a change log to the bottom of the document and an effective date up top. If you really need something more complex than that, then hire a grossly huge and expensive management team and let them tell you what to do.

Agile (3, Interesting)

delibes (303485) | more than 3 years ago | (#34354352)

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.

Re:Agile (1)

Nerdfest (867930) | more than 3 years ago | (#34354412)

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

FRAgile is about lazy requirements definition (1)

syousef (465911) | more than 3 years ago | (#34354778)

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.

Re:Agile (1)

davecb (6526) | more than 3 years ago | (#34355114)

Customer managers like owning the backlogs and having regular deliveries against them, instead of waiting loooong times and then getting something that's close, but not quite there.

--dave

Agile: Scale? (1)

handy_vandal (606174) | more than 3 years ago | (#34354782)

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

Re:Agile (2, Insightful)

WindowsTroll (243509) | more than 3 years ago | (#34355200)

Agile is not sufficient for regulated industries.

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 cause of the crash was due to the design of the aircraft - a lot of engineers are going to lose their license to practice engineering. Now, think about the "auto-pilot" software or other control software on the plane. If the plane crashes, do you think that the FAA will accept index cards as an acceptable substitute for documented design and specification?

How about the anti-lock breaks and traction control software in your car?

Or the software that is used to control medical equipment? I suppose you are not familiar with the programming mistake in the software of a nuclear medicine machine that exposed a patient to 20,000 times the expected dose of radiation and killed them.

Re:Agile (0)

Anonymous Coward | more than 3 years ago | (#34355692)

Agile is still possible, you just need to include the required documents as stories to be completed as part of the sprint. In most cases, they are better off documenting what was done, as opposed to what was envisioned. Agile done right has acceptance criteria for each story, (e.g. specs must meed FAA quality standards). Both the Airbus A380 and the Boeing 777 delays show that planning is not a substitute for doing. Agile seeks to give priority to the engineering first and process second as opposed to the other way around.

None (2, Informative)

defaria (741527) | more than 3 years ago | (#34354376)

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

and (1)

unity100 (970058) | more than 3 years ago | (#34355090)

the latter is called 'agile'.

C'mon lets hear from the BPM folks (1)

fishbowl (7759) | more than 3 years ago | (#34354378)

I'm surprised we aren't hearing from the BPM folks. There's a lot to be said for BPMN and XPDL, which are useful for (A.) communicating with people who understand the basic ideas of flowcharts and (B.) turning those charts into formal workflow definitions that can lead to some confidence that an offshore programming group can return something that resembles your specifications.

There's a school of thought that is firmly committed to the idea that the problems of Big Design Up Front are best solved with Even Bigger Design Up Front. My favorite laugh is when the same people also try to claim that they are doing some sort of "Agile."

My favorite tool for specifying code happens to be a combination of a programming language and the English language.

What I use at work (1)

File_Breaker (16834) | more than 3 years ago | (#34354388)

My project has a team of about 40 people including people who develop and write our requirements, developers, integration testers, quality assurance testers, and various managers.
We use DOORS for formal documentation including requirements, high level design documents, and manuals. We use Visio to make UML diagrams for detailed design. We use ProcessMax to track defects in code (found by the integration test team or the QA test team), problems requirements, problems with other formal documentation, and to track the results of code peer reviews.

I've been using these tools for about 8 years now and so far they seem to work well for our team. Other teams in our division also use these tools. The only negative is that if I had my way we would use a better tool to generate UML.Our management doesn't see the need for that since the UML usually never leaves the development team and is not included in the formal documentation package we give to QA.

Good luck in finding a solution for your needs!

Small company (1)

johnlcallaway (165670) | more than 3 years ago | (#34354474)

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.

Anything but (1)

kamochan (883582) | more than 3 years ago | (#34354536)

I'd go for anything as long as it's not Accept360.

The best (2, Interesting)

Anonymous Coward | more than 3 years ago | (#34354634)

We use Lifesuck Greymaker (tm), the best solution for introducing bureaucratic process into your unbridled creativity.

CMMI - religion masquerading as whatever it is (5, Insightful)

dread (3500) | more than 3 years ago | (#34354860)

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.

Re:CMMI - religion masquerading as whatever it is (1)

Yosho (135835) | more than 3 years ago | (#34355180)

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 completely derailed our development process"...

Re:CMMI - religion masquerading as whatever it is (0)

Anonymous Coward | more than 3 years ago | (#34356006)

If you take the long road and read 'Zen and the Art of Motorcycle Maintenance'
the general point is you should not endeavor to define Quality. You certainly can't legislate 'it'.
You know quality when you see it (this is best definition)
If you are not a motorcycle mechanic (or an ace programmer)
you won't be able to appreciate the nuances that made the project good through all the stages.

Once a project is made, it is tempting for paper-shuffling folks to take credit, or predict how well the next one will go if only everyone would follow the latest 'system'.

Unfortunately these CMMI, and in my case AS9100, initiatives are an attempt to define 'it' on a worldwide level.
And all the standardized testing of our kids in school is a similar attempt to create little corporate 'yes' people.

You should inoculate yourself again group-think from people who, if given a 1,000,000 years, would never actually create anything!

Re:CMMI - religion masquerading as whatever it is (0)

Anonymous Coward | more than 3 years ago | (#34356178)

The premise behind the Scrum framework is that teams are best left to self organize and choose their own processes and tools.

Re:CMMI - religion masquerading as whatever it is (1)

danparker276 (1604251) | more than 3 years ago | (#34356244)

Very good post. Many developer snobs care more about their process than the actual product. That's what a masters degree will get you. I think you'd like PMS Programming Methodology.

Atlassian Jira, Fisheye, Confluence (0)

Anonymous Coward | more than 3 years ago | (#34354920)

The dream team - Atlassian.com

Re:Atlassian Jira, Fisheye, Confluence (1)

nwoolls (520606) | more than 3 years ago | (#34355450)

We use JIRA and I like it quite a lot. We used DotProject previously and it just didn't cut it.

Doors (1)

MichaelSmith (789609) | more than 3 years ago | (#34354998)

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.

As a tech writer... (0)

Anonymous Coward | more than 3 years ago | (#34355270)

I am convinced that software spec tools are:
a) Prayer
b) Alcohol
c) Fantasy

(You want me to document what?)

Process (1)

Whomp-Ass (135351) | more than 3 years ago | (#34355358)

An 8 and 1/2 by 11 note-pad to collect my thoughts and good notes.

One single, very short, power-point presentation to satisfy management.

Thereafter, inspiration atop persperation, with the illumination of the congregation caused by instantiation of what was really asked for using the perpetuation of the prior derivation as a starting point...

A Revolver (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34355364)

A revolver is probably the most effective tool for dealing with CMMI.

Process Impact Goodies (1)

ferrisoxide.com (1935296) | more than 3 years ago | (#34355394)

The tools I *prefer* to use are just cards and good interactions with customers, rapid feedback through short iterations and such. And with my own clients that's exactly what happens.. happy me, happy client.

Where I work at the moment they need slightly more ceremony, so I've found the templates that Karl Wiegers has come up with are super useful:

http://www.processimpact.com/goodies.shtml [processimpact.com]

High-end, complex tools for managing and tracing requirements are awesome if you (a) build space ships or (b) are a bit potty.. IMHO. I've yet to see any concrete evidence that they add as much value as they suck out of a project. Keep it simple and straightforward.

Reqtify (0)

Anonymous Coward | more than 3 years ago | (#34355436)

For requirements traceability, there's also Reqtify. I use it at work for traceability between specs, code, and test scripts. For a smaller company, it might be more within your budget than something like DOORS. It supports parsing of all MS Office document formats, C code, Simulink, ASCII files, and other file formats.
The basic idea is that in your spec, you define a requirement with an ID tag and description, and then create a reference to this ID tag in all associated files that cover the requirement. And then you can generate all the traceability information you would ever need. The format for requirement ID definitions and references are specified by the user as Regular Expressions, so it's very flexible.

Who is using it? (1)

larwe (858929) | more than 3 years ago | (#34355526)

My kneejerk response is to tell you not to worry your pretty little head about these questions, since unless you're working on aerospace, medical or government contract code (written in Ada?), this obsession with CMMI will soon put your small company out of business and you'll be able to get a real job at a company that's focused on making products instead of "deliverables". Anyway - the answer to "what is the most important part" is - usability BY THE PEOPLE WHO HAVE TO USE IT. I am involved with some groups who are CMMI level [x], reluctantly and for absolutely no useful purpose (by the time they finish these paperwork deliverables, their product is obsolete). The first step is for requirements to be entered, and this requires cooperation from non-engineers who are used to drafting a free-form Word document, and who frequently work offsite and/or with no live Internet connection, e.g. while on a plane. Note the implication here - for usability by the target people, it should be possible to export, edit offline and reimport data with no loss of audit trail. Further, all of these systems that I've evaluated - I'm most familiar with Contour - impose a structure on the input, and it's usually configurable by means of templates. MAKE SURE your entry template is designed/approved by the [typically marketing] folks who are expected to kick the project off, otherwise you'll wind up with a spec containing everything in the first category box and everything else left blank. I've never seen a CMMI template that was properly structured for non-engineers, btw; they're all designed by CS majors or, worse, documentation control specialists. And without buy-in from those people at the start, you're immediately screwed (unless this is purely a for-show exercise, where auditors, if any, are only looking for some text in every field - in which case go ahead and paste in lorem ipsum and get on with your actual work). I also suggest you hire someone whose sole job is to create and update this paperwork, because it is a spiraling black hole of unproductivity for any project that operates on modern development cycles (it only works with the waterfall model; too bad if you're doing a large consumer electronics project that needs to be released before your chipset goes obsolete and the world moves on) and by having a specific person (persons) assigned to it, you can very easily put a numerical value on exactly how much it is costing you, which might help to kill it before it sinks you. May flights of angels sing thee to thy rest...

Doors (1)

daveh0 (1948302) | more than 3 years ago | (#34355560)

We have DOORS at work. Here's my opinion based on project size: Small: e.g. couple of web pages of forms input and produces one or two reports. Don't use DOORS because it's too heavyweight for a project that size. Medium: e.g. too big for someone to understand the whole system in their head. Use DOORS. Large: e.g. multiple teams working in parallel on multiple subsystems. Use DOORS. Very large: e.g. multiple requirements baselines which can all change in parallel. Do not use DOORS here, as it will give you hell managing the different requirements baselines. Also, consider what your customer needs and if they'll pay for additional process. If your customer needs you to deliver things like test procedures which trace to requirements, then a DOORS like tool is a good thing to use. If they just want working software, then you might want to make DOORS optional for the team.

Traceability (1)

UnderCoverPenguin (1001627) | more than 3 years ago | (#34355602)

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 identifying number, which makes it easy to reference in the source code.

Seapine (1)

andy4us (324798) | more than 3 years ago | (#34355638)

We use Seapine SCM revision control, TTPro bug tracking and TCM test case management. They also have RM which is Requirements management, and can make up a complete testing matrix. We are a small company, the software is pretty cheap and it rocks ! It is cheaper to pay a license fee for software to get the job done, than to fool yourself and have to keep screwing with an open source implementation and try and tie it all together.

Hi (0, Offtopic)

Eliza027 (1948318) | more than 3 years ago | (#34355648)

I would like to thank you for the efforts you have made in writing this post. I am hoping the same best work from you in the future as well. Great information put together well http://www.optionpoppers.com/ [optionpoppers.com]

JIRA (1)

Prosthetic_Lips (971097) | more than 3 years ago | (#34355748)

We are not CMMI anything. However, we moved from an internally-developed package to JIRA a few years ago, and it definitely helped. Instead of always needing to add new features (attachments, etc.), JIRA holds a lot of that stuff. I tracks what changes were made to each project, and you can even tag each project (and move it later) to a specific delivery / version.

I know some people that really hate JIRA, but it is great at keeping track of changes and such. It even has ways to integrate with your version management system (including code reviews, via an add-on). Yes, I like it. Yes, I've used quite a few different internally-developed or external packages; JIRA has a bigger footprint than some others, but once you get used to how to move from one step to another, it really makes a lot of sense. And the notifications are great; whenever someone ELSE makes a change, you get an email if you are attached to the project (developer, analyst, etc.) or if you have marked it as "I want to watch this project."

PMD (1)

O('_')O_Bush (1162487) | more than 3 years ago | (#34356066)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?