Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming

What Software Specification Tools Do You Use? 200

Posted by timothy 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?"
This discussion has been archived. No new comments can be posted.

What Software Specification Tools Do You Use? More

What Software Specification Tools Do You Use?

Comments Filter:

  • My sympathy for you (Score:5, Insightful)

    by Dolphinzilla ( 199489 ) on Friday November 26, 2010 @08:07PM (#34354264) Journal

    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 (Score:4, Informative)

      by JamesP ( 688957 ) on Friday November 26, 2010 @08:38PM (#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

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

      • Re: (Score:2)

        by jgrahn ( 181062 )

        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: (Score:2)

          by JamesP ( 688957 )

          In my opinion

          CQ CC RR

          I used Rational Rose for only a brief period of time though.

          Also, (legend says) ClearCase is not that bad with a decent administrator and configuration (tough luck on this one)

    • 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

    • Re: (Score:2)

      by bit01 ( 644603 )

      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.

      "Integrated" is just vendor code for "we own all the pieces, we own you".

      In addition it blocks you from using the best tools for the job and being agile and responsive to new requirements.

      That "hodgepodge" you are talking about is due to bad management and has nothing to do with using independent, well written, best of breed tools with good int

    • Re: (Score:2)

      by drewhk ( 1744562 )

      AAAAAH! Now I remember! Now I remember all the pain! These memories were suppressed, and buried deep down in my mind... This explains all the nightmares. Oh God. I need a therapist.

    • 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

  • Word to the wise (Score:5, Insightful)

    by Rogerborg ( 306625 ) on Friday November 26, 2010 @08:07PM (#34354270) Homepage
    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

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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

      • Re: (Score:2)

        by jgrahn ( 181062 )

        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

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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

      • Re: (Score:2, Interesting)

        by acooks ( 663747 )

        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

        • Re: (Score:2)

          by drewhk ( 1744562 )

          I agree with you except:

          The list of "institutional causes" can be addresses through process

          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

    • Re:Word to the wise (Score:4, Insightful)

      by BlackSabbath ( 118110 ) on Friday November 26, 2010 @09:03PM (#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: (Score:3, Insightful)

        by plover ( 150551 ) *

        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

      • Re: (Score:2)

        by drewhk ( 1744562 )

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

        Yes, IF y

        • Re: (Score:3, Insightful)

          by gbjbaanb ( 229885 )

          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

    • Re:Word to the wise (Score:5, Insightful)

      by wrook ( 134116 ) on Friday November 26, 2010 @09:03PM (#34354736) Homepage

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

        by B4D BE4T ( 879239 )

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

          by wrook ( 134116 )

          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.

          • Re: (Score:2, Insightful)

            by Alcanazar ( 879920 )
            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.

    • Re: (Score:3, Insightful)

      by garyisabusyguy ( 732330 )

      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: (Score:2)

      by nurb432 ( 527695 )

      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.

    • 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 whe

  • It depends on the platform (Score:5, Funny)

    by BadAnalogyGuy ( 945258 ) <BadAnalogyGuy@gmail.com> on Friday November 26, 2010 @08:08PM (#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.

  • Yay process (Score:5, Insightful)

    by The End Of Days ( 1243248 ) on Friday November 26, 2010 @08:08PM (#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: (Score:3, Insightful)

      by hguorbray ( 967940 )
      <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

    • Re:Yay process (Score:5, Interesting)

      by Roland Piquepaille ( 780675 ) on Friday November 26, 2010 @08:27PM (#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...

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

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

      by CosmeticLobotamy ( 155360 )

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

    • Re: (Score:2)

      by Hacksaw ( 3678 )

      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

    • Re: (Score:2)

      by jgrahn ( 181062 )

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

  • Agile (Score:4, Interesting)

    by delibes ( 303485 ) on Friday November 26, 2010 @08:18PM (#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.
    • 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.

      • Re: (Score:2)

        by davecb ( 6526 )

        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

    • 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

      • Re: (Score:2)

        by wrook ( 134116 )

        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

    • Re: (Score:3, Insightful)

      by WindowsTroll ( 243509 )

      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 cau

      • Re: (Score:3, Interesting)

        by wrook ( 134116 )

        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.

        Wouldn't

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

  • None (Score:2, Informative)

    by defaria ( 741527 )
    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.

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

  • The best (Score:2, Interesting)

    by Anonymous Coward

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

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

    by dread ( 3500 ) on Friday November 26, 2010 @09:17PM (#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.

    • Comment removed based on user account deletion

    • Re: (Score:2)

      by Rich0 ( 548339 )

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

      If you do something

  • 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.
  • OSRMT seems to work. Anybody actually using it?
  • 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

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close