Open Source Requirements Management Systems? 117
scphantm asks: "I have the wonderful (and rare) job of building a development department from scratch. One of the things im doing right now is looking for the software im going to use company wide to manage the department and the various projects we are going to have. I have some great ideas for OSS project management software, but the one piece of the puzzle that im missing is a good requirements management system. I have found a few that will do what i want but i have serious issues spending $1200 to $10,000 a seat! I sat down and put together a wish list for what I would want in a Requirements Management System, is there anything like this out there?" While SourceForge and it's free counterpart Alexandria
may have a few of the pieces to his wishlist, scphantm has some decent ideas that Project Managers might want to think about.
"I have used your basic Word docs and Excel spreadsheets in the past for this but it just simply wasn't up to snuff as far as I'm concerned. How have Slashdotters solved these problems?
My Wishlist
- Has to be web based. We are going to be spread all over the country and i see no other realistic way of doing it.
- Has to handle multiple projects
- I want it set up so I can take the tree of requirements, click on a button and have it take a snapshot of those requirements and mark them as the requirements for version 1. I can then still use the original requirements tree to create the requirements for version 2.0, in the future. I then want the ability to compare the two snapshots and generate a report that I can give to marketing which says: "these are the changes from version 1.0 to 2.0"
- I want the defect tracking integrated into it. Source code management I don't really care about, but bottom line, I want to be able to click on my snapshot of version 2.0 and run a report that itemizes everything in it, from requirements to bug fixes. I want to be able to look at a closed bug and see what release of the product it was integrated into. on this level, I really don't give a rats @$# about what version of data.h the fix was integrated in.
- If I have a bug reported in version 1 of a release, I want it to flag the developers of version 2 that this may be an issue for them as well. Basically have a little bit of AI as far as who needs to know about a bug, and make sure to incorporate the fix for that bug into future releases.
- I want security set up so there is a free communication during the process of requirements management. anyone who is anyone will be permitted to add input to new feature ideas using this system. the Development Director for the particular project would be the only one permitted to make a suggestion a requirement.
- I want an impact tree. I want to be able to run a report to show the CEO that if he wants to change the encryption from Blowfish to AES, its going to impact these requirements."
Apostrophe (Score:1)
Or... (Score:4, Funny)
Version control would get a little difficult though.
Do you already know who/what/why (Score:3, Insightful)
Re:Do you already know who/what/why (Score:3, Insightful)
I agree. This to me sounds like someone putting the technology ahead of the humans.
I'd start out with a decent version control system and that's about it. I'd make that work first, and also concentrate on proper coding standards (comments etc etc) before ever worrying about the rest of the infrastructure.
The build system would be a close second. For Java I like Ant...I've been using it for years, and the company I work for right now uses it big time.
Configuration and documentation management would come third, and not too late either.
OK, it sounds like I am discounting requirements management and high level design and traceability - definitely not. But I think you can do this without resorting to systems. Just make sure that the business analysts are hardnosed SOBs that know requirements analysis inside and out. All you need from them are decent System/Software requirements specs that could be in ASCII for all I care.
Do your spec review. Make sure the senior programmers are on board and understand the requirements. Give them their bits and let them loose. Let them use UML if they like but don't demand it, and curb excessive use of it. If they want to use something else that's fine. Require traceability.
Review again. Intensively. All docs at this point are still ASCII/Word/XML/LaTeX/images - no fancy expensive systems are in play. None required, as far as I am concerned. Your best bet is people, not technology.
I, or other commentators here, could follow the entire lifecycle through - what's the point? The thng is, you don't need the technology - you can do very well with email and simple document formats. It comes down to human skills and training and doctrine.
Re:Do you already know who/what/why (Score:3, Insightful)
"Configuration and documentation management would come third, and not too late either"
How can you mention requirements specs and design specs and say that coding standards, of all things, should be tackled before configuration control, document management and project infrastructure ?
Because ... (Score:2)
Which is the cart and which is the horse? (Score:4, Insightful)
If you are a software company, then you had better pay close attention to having the right process from the start. Once your into the project, you won't have time to go back and do planning and process. If your design and project methods aren't good, how can you even make a schedule or know how many programmers to hire? This is by definition more than a one or two person project or you wouldn't need a software company to do it.
That being said, don't go nuts on process either. Figure out what is most important to your project, and implement something that hits the important points. Use it and build good habits on your team, and you will be able to refine the process as you go. At the end of each product cycle you have to evaluate the performance of everything and make adjustments.
This is just like the extreme programming model where you prototype quickly and test constantly. Unlike writing programs, it's harder to automate the testing because your evaluating a human process, not a program. Performance metrics can help, but sometime they hide more than they reveal.
support oss (Score:2, Insightful)
Re:support oss (Score:1)
Yeah right.
Take and give (Score:2, Interesting)
I would be very interested in your decisions regarding all the other parts of your open source development environment. Could you give us a summary of the tools you plan to use?
I'd be happy to help you with the Requirements Management System. Unfortunetaly all I've ever used for this are plain text files...
Microsoft (Score:2, Interesting)
A platform for Web-based project management (Score:5, Interesting)
It was really developed as a way to allow us to keep in touch with multiple customers and partners for various projects, and includes incident management, a knowledge base, bulletin board, document repository with versioning and notification, and a handy e-mail archiving system too. It has a few plug-in options, including a GANTT tool, and an on-line update capability. It uses LAMP, but will also run under Windows if you're able to set up MySQL, Apahce and PHP correctly.
See: http://outreach.sourceforge.net [sourceforge.net].
Re:A platform for Web-based project management (Score:1)
Re:A platform for Web-based project management (Score:1)
Re:A platform for Web-based project management (Score:2)
Check out:
http://outreach.sourceforge.net/
http://source
The above links are both in English.
You just defined your new depts. first project. (Score:4, Interesting)
There's nothing that meets your requirements better than something you rolled yourself, so get to it!
Re:You just defined your new depts. first project. (Score:1)
2nd vote for "Roll your own" (Score:4, Insightful)
One place you won't find the terms "requirements analysis" or "requirements management" used outside of specific examples is in the Project Management Institute Body of Knowledge (PMBOK), which is (get this) an ANSI standard for project management.
The PMBOK dispenses with the concept of a project as a sequence of segmented phases and describes a project as the outcome of several "process groups" that wax and wane in importance during the project. When you talk about "requirements management" you are cutting a broad swath across these process groups and invoking activities such as risk management, scope management, resource management. time management, and so forth.
For example, the first process group is "initiating processes." What drives your organization to authorize a project? If your requirements don't relate directly to that, you're already on the wrong track.
My main exposure to SDLCs was in professional services; limiting the context to "outsourced project" already answers some of the questions I raised above. Some guys I worked with at PwC consulting had the best approach to requirements management (within this context) that I saw. (Yes, I realize that PwC Consulting changed its name to "Monday" and sold iteself to IBM, but despite outward signs of insanity, these guys had the SDLC methodologies down.) Anyway, at the commencement of each project, they would write a custom requirements manager in Microsoft Access. At the end of the project, they'd throw it away, because it was never quite the right one for the next project.
The cliché that comes up in every Java vs. Perl flame session is "use the right tool for the job." Unless your projects need to follow some kind of rigorous methodology (like DOD contracts), you should plan for variation. Put together a suite of tools (there are already some excellent suggestions) and include as part of the planning for a new project "tool selection" and let the project team deploy these tools as best suits each project.
The PMBOK definition of "project" specifies that a project be "unique." If it's not unique, then it's not a project, it's part of some ongoing process. Very insightful: all projects are unique.
"Roll your own"?? Why is this a good idea? (Score:1)
1) Outside the team's core competency. Presumably the development team was picked in order to compliment each other in terms of the products or services of the company. (e.g. just because I know JAVA, doesnt mean Im familiar with SWING or I like doing socket networking)
2) Time and more importantly Focus. The team wants to work on the real project, not get all muddled up in trying to write from scratch software just to get the project started
3) Resource management. Sorry all you technologist here on Slashdot, but buying vrs building your own is a business decision, not a technological one. Is it worth it to me to spend X amount of dollars or Y amount of time. I would make the assumption, since the poster here wants an open source project to start, that money is a concern. Time is more costly than cash! Having my team of developers spend their time working on a software solution means that as a manager I am a) paying their salary during that time and b) delaying when I can get the real project started, getting that product/service to market, or using whatever effeciency that product/service was intended to give me.
Make sure to make it Open Source (Score:2)
The company I work for has some deal with Rational, so we are tied into using their products. :(
We are using Aegis (Score:3, Interesting)
http://aegis.sourceforge.net/ [sourceforge.net]
It has some of the wanted features.
What about Wiki + Bugzilla (Score:5, Interesting)
Wiki (the interactive collaborative system, implementations I know of being TWiki and MoinMoin Wiki) can be used pretty effectivly for a lot of these things.
I have tried using it. It does take a little getting used to, but once people (developers I am assuming) are hooked to it, there's no turning back. And i'm speaking from experience
As T/MoinMoin are open source implementations, you may even be able to integrate it into bugzilla without too much difficulty.
Hrishikesh
Re:What about Wiki + Bugzilla (Score:2, Interesting)
The links are never UptoDate, there are LeafPages everywhere with NoContent. Or even worse there are LeafPages that say 'Note to self, put content here.' Half the pages should just be RetiredYesterday but no one ever seems to DoIt.
www.worldforge.org is a PrimeExample. I'd love to know where they are in their CurrentDevelopment, but I can't find a DamnThing on the site.
So what are wikis actually good for? Very short term collaboration and note taking with a very few number of pages. Everything else is just WikiMastrubation.
Everything2 might be a great wiki derivitive but only because they spent alot of time tweaking it for a more specific purpose and threw out alot of the Wikiness.
Re:What about Wiki + Bugzilla (Score:2)
The original Portland Patterns Repository wiki, by Ward Cunningham, is one example of a public Wiki that remains quite active.
Re:What about Wiki + Bugzilla (Score:3, Interesting)
I have used a Wiki happily for collaboration between a distributed team of eight (all working fractional amounts) over the course of the last ten months. We used it to track all requirements, to keep manuals, and as a general project intranet. Our project enough of a success that it was covered twice in the New York Times, so we must have done something right.
On another project, I successfully used it to keep a distributed team of architects in touch, building a common coding standard, a common design standard and as a repository for a lot of tools, tips, and tricks.
he links are never UptoDate, there are LeafPages everywhere with NoContent. Or even worse there are LeafPages that say 'Note to self, put content here.' Half the pages should just be RetiredYesterday but no one ever seems to DoIt.
Is the problem that nobody in the team gives a fuck about communicating or writing things down? Or is it that they put the information somewhere other than the Wiki?
www.worldforge.org is a PrimeExample. I'd love to know where they are in their CurrentDevelopment, but I can't find a DamnThing on the site.
Then maybe you could GetOffYourAss and write it. Content doesn't magically appear in Wikis. Somebody has to put it there, and the person who wants it is often the best person for the job.
Note also that you may be trying to use Wikis for the wrong thing. Wikis are topic-based; things like a StatusReport will only get updated if the people who have the knowledge find it useful to put the knowledge there.
If you want a Wiki to be adopted, you need to rig things so that the people with the knowledge find that the easiest thing to do is to put the knowledge in the Wiki.
restating his own requirements... (Score:2)
I think that guy might be well served by viewing his need as a bug tracking system that he can use for requirements management, rather than a requirements management system that he can use for bug tracking.
I was on a project a while back where the QA lead entered the requirements doc point-by-point into the defect tracking system with each functional requirement tracked as a missing feature.
Sounds awkward, and at first it even ticked a few of us off to have a bunch of bugs logged against us when we hadn't even begun coding yet... but it actually worked pretty well.
Not ideal for a few reasons, most notably because moving information between the requirements doc and the bug tracking system is a tedious manual process, and because the mapping between them can be ambiguous and the source of some contention. But, if you can't find just what you want, and can't justify investing the time to build just what you want, it's another option.
Re:What about Wiki + Bugzilla (Score:1)
Re:What about Wiki + Bugzilla (Score:2)
- Don't make blank pages. If you aren't ready to write content for a node, don't create the node.
- Refactor a Wiki's organization like you would source code.
- Use a Wiki like a FAQ. When someone asks a question, add a node to the Wiki.
As for requirements management? The only real way it falls short is, my boss wants to build "requirements documents" to archive and "sign off" on. I'm sort of working on my own version of wiki 2 docbook [tldp.org] but it's still alot of effort.tutos (Score:5, Informative)
Seems pretty complete. I'm looking at using it.
Jira... (Score:1)
Tigris? (Score:3, Informative)
Though no longer available as OpenSource (Free!) product, CollabNet provides this platform for Collaborative Development to interested parties as a Hosted Model for a fee. Check them out at http://www.collab.net/ and while you are at it, you might get a feel of the features provided by checking out http://www.tigris.org/
We tried SourceForge too when it was open source/free. But finally decided to go with Tigris as it was more flexible and suited us better. YMMV!!
-Sumit Dhar
Re:Tigris? (Score:4, Informative)
To the original poster: I don't know if it could be adapted for your purposes, but you may well want to check out Forrest, at xml.apache.org [apache.org]. I have been examining it for my own use, and it looks like it might make a very interesting part of a distributed development framework.
Good luck, and let us know how it turns out.
Re:Tigris? (Score:2, Interesting)
Scale? Objectives? Tracking? (Score:3, Insightful)
And what's your key objective? Do you need to show something by December 1, or can you project any date as long as it clears a well-defined quality test on that date?
What's your need for accurate tracking of progress? Do you need to tell people something believable every week about when they can expect the THING that they've ordered, or can you just say "we're working on it, and we're somewhere in the middle?"
All that said, the approach I've seen work the best is an email folder, a spreadsheet, and a brilliant dedicated experienced person who kept it all in her head and spoke the right language to everyone concerned. Get whatever tools you want - as long as the craftsmen are right, everthing else will be fine...
Or, y'know, not. Good luck, comrade.
why? (Score:4, Insightful)
Why not?
Seriously. I've worked on a few projects of some magnitude [infamous.net] and we never used any "requirements management system" more special than standard document files. (Of course, you shouldn't be putting any data at all in proprietary and virus-ridden Word or Excel formats, but there are safe and open alternatives.) Heck, they managed to put a man on the moon with a "requirements management system" that probably consisted of three-ring binders.
Ask yourself: is using an fancy-pants automated system going to simplify or complicate the process?
Re:why? (Score:1)
Re:why? (Score:1)
Although, perhaps a more elegant solution (I'm thinking about XML right now because it's easy to transform into other formats like HTML or WML) would be nice.
Re:why? (Score:1)
I'm mostly an emacs man, these days, though I know several outstanding coders who prefer vi. I've also worked with joe and nedit guys...so long as we're all editing good ol' ASCII text, who cares?
And just because someone creates a new tool that's got bells and whistles and shiny chrome attached doesn't mean it's better.
My preference is for simplicity - and thus robustness, and a certain beauty - of solutions, not age.
My question is a a sincere one: what did the questioner find deficient about the old-school method?
Re:why? (Score:2)
Yeah, I have yet to see a system that worked better than the following (find your own open source equivalents if that's truely a requirement):
Of course, don't forget to implement a good version control system, checkin procedures, daily builds, yadda yadda. Read Rapid Development [amazon.com] by Steve McConnell for some good info. This site [joelonsoftware.com] also has some practical articles and recommendations.
Oh, and above all, this needs to be as transparent and easy to use as possible, otherwise you put an unnecessary burden on your development team.
matrix (Score:2)
Because it's hard as hell to extract decient matrix out of spread sheets and word docs.
Configuration management of you well configuration management is also a nightmare with plain docs, why not have a system that self manages?
If I was building a project management system it would be !somthing! like this.
Bill comes to me with a 'project'
I put the project into the management tool, and setup who's going to do some requirements and feasablilty analysis on the project (to see if it's worth taking on and what were going to charge).
The project is now have a few nodes for various elements, and the node link up to the staff.
We decide to take on the project, by this time there are a few more nodes giveing some top down requirements and some time estimates.
A manager is assigned to the project, the manager assigned different teems to the various nodes (this could include businss analysts and managers depending on the node type).
Each team itterates through the process, reporting back to there parent nodes (there manager), tasks are assigned, completed and reviewed. Bugs are tracked against the various levels of the project (down to source level).
Re:why? (Score:2)
There are a lot of really neat tools knocking around, but the starting point should be a standard office system and most importantly standard templates. Open source is prefereable but O97 did it for us.
Technology v. Management (Score:3, Insightful)
I read your specification for your requirements system, and it left me with a distinct impression that you're trying to use technology as a substitute for your company's management. No system is going to make a mediocre team better - this is true for any organization regardless of size. If you're putting together a team, concentrate on the people first. A strong team will be able to credibly explain to management the impact of requirements changes better than some report from a system that most of your management can't even grasp.
Remember - build a great team! Good Luck
How about Bugzilla... (Score:2, Interesting)
Nice things about Bugzilla in this context:
* Use 'enchancement' for requirements, and have them all owned by the project manager until they are finalized and assigned to a developer.
* Lots of feedback possible from all parties
* Use Milestones in order to get the r1/r2 distinction for reporting purposes -- bugs included and sortable.
* It is truly free
Works like a charm -- I used this for the dev group I set up from scratch to build a complete router/gateway system... It's not perfect, but, hey, what is?
Cheers,
matt.
Re:How about Bugzilla... (Score:1)
Your Are Asking For A Lot From One Tool. (Score:4, Informative)
1) For requirements documents, Word is not a bad choice. You will need narrative, formatting and pictures - becuase the one of the target audiences for this is the sponsor of the project and the business people who are paying for it. They have Word on their desktop, they understand it and they can print from it. (Note: I don't like MS any more than the next person, if you have a company preferred alterntive, then use it). Without nice pictures explaining what is happening, the people who are paying for your project won't understand what is going on - and confused managers are dangerous managers in my experience!
2) The point at which we reduce the requirements document to something unreadable is the creation of the Test Model - linking requirements to test conditions. For this we use a home rolled Oracle DB that we use to populate test scripts via ODBC. The test scripts and model are all Word based. (Sorry
3) You are asking for a CMM 3/4 type of environment. That implies a very rigorous development approach - in order to do the impact analysis of changing your encryption algorithm, you need the developers and designers to be really thorough. If they are not, then all the tools in the world won't help.
4) If find it strange that you are not starting with version control. From my perspective, knowing that encrypt.c version 21 was changed by developer Fred and went into build 723 which became Release 3 is the most important thing. I have seen many projects fail becuase of a lack of version control, and I have seen projects fail becuse they did not write down the requirements. I have never seen a project fail becuase they did not use the right tool for their requirements.
5) We make sure that bugs fixed in one release get fixed in the next by raising multiple problem requests; one for every phase in flight. That way it doesn't matter if Phase 5 is in design or build - someone has to address the problem request and sign it off.
Re:Your Are Asking For A Lot From One Tool. (Score:3, Informative)
CMM Level 1 - the project is fairly shambolic, but you have version control and the basics are in place.
CMM Level 2 - you have tight version control, defects are linked to item changes, all docs are under version control.
CMM Level 3 - as per 2, but your process is the same on several projects - this is "repeatibility". The advantage is that good management is becoming a process, rather than just being lucky enough to have a good manager.
CMM 4/5 - Never really researched these, but it seems to be about having such a repeatable process that any project you do could be run by a zombie, and it would all come out OK.
Caveat: This is massively paraphrased. There are loads of books on this subject. Do a Google for more.
Most normal development shops are CMM 2 - 4. Many places that have 5 do it by treating a defect as a project in its own right - so after 2000 defects, you can be damned sure you are repeatable.
Re:Your Are Asking For A Lot From One Tool. (Score:1)
I have a new project, what can be re-used from the previous projects.
Not only must the process be repeatable but one of you targets must be reusablity through the project not just the management.
Re: requirements management (Score:2, Interesting)
Though it's not open source, it's only $150. Windows only. It does excellent web-based export of data too, and powerful database replication.
I dont suppose... (Score:1)
I dont think theres an all in one solution out there, but by combining a couple of tools, one could get all that desired functionality plus more.
Just an idea.
McDoobie
Why web based? (Score:4, Informative)
Why is it that every time somebody plans a new multi-tier application, it seems like a browser is the only "realistic" option for the client? Don't get me wrong, i think browser based clients (if designed correct) can be great. They offer ease of use to the user, and are basically platform agnostic. Also, web servers offer are a easy way for a developer to use server side program logic(as opposed to using component services of some sort in a custom build client app).
But just remember, web clients aren't always the way to go. In your case for example, I would think a custom created client might be a better solution. Since a custom MDI applications still offers far superior multitasking capabilities as opposed to a browser client solution, meaning you spend less time working with the application and more time working with the data in the application. The larger a application get, the less suited for a browser it becomes. Who for example would like to use a browser based C++ IDE? It would be possible (though stupid) to create, but 1000000:1 you would prefer to use a compiled gkt/kde/mfc/whatever based application.
Also, when using a custom client you can actually use that 500Mhz+ badasso processor that resides in most computers today. So instead of doing EVERYTHING on one maschine(the server), you can spead some of the application logic (like generating rapports ect) out on the client. And then just handle the most basic program logic(log in/out etc) on the server.
The geographical differences aren't a problem either, just use a database that's accessible from all the companies locations (simple networking task) in conjunction with the custom made client app.
Just my 2cents =)
Re:Why web based? (Score:1)
Most of the advantages you cite for clients can be gained through Java applets, w/out compromising any of the advantages of being web-based.
Sounds like... (Score:2)
Seriously, a project like this is a great way to see how the team is going to work together. And really, this is a better way of finding out who should be a tech lead, and who is just a developer. Remember, tech-lead shouldn't be a gift to the person with the most experience... It is a different skill set.
--T
SCM & Project mgmt via web (Score:1)
Project and group management:
http://www.phprojekt.com/
http://ph
For documentation, check out Doxygen:
http://www.stack.nl/~dimitri/doxygen/
HTH...
http://www.phprojekt.com (Score:2, Interesting)
Free, functional, I use it
Management of Requirements Management (Score:2, Funny)
slashdot - style web-based system where the process looks like this:
1). Anonymous coward proposes a system requirement
2). Discussions about the requirements abound...
3). A moderator mods it up because it might be insightful (or down...)
4). Requirements with a score of 5 get added to the real requirements.... Those with high karma
get raises and promotions....(or respect and admiration with OSS) etc...
Once requirements are in the system, it's just a database - blah. We really want to improve the product and the developement process, right?
Re:Management of Requirements Management (Score:1)
Wait, we could just use monkeys on typewriters.
Nevermind.
Build it yourself (Score:1)
Our SysDev team built a web-based work request tracker with issue and work history (management gets a pretty report from Crystal Reports that shows weekly work for team - no matter which work request they devoted time to), and it fit our requirements perfectly because we built it!
Some of the requests we get are simple "build me a report" type projects, which don't need the level of requirements and version history tracking that you outlined, but some of the large projects definately do - and in fact, I might borrow your requirements to run past management to see if this is something we might want to implement.
(not that this helps you in anyway, other than points out the fact that the best fit software is rolled in house - if you've got the resources to pull it off..)
Other Tools You've Selected, And Why? (Score:1)
Some of us might find your requirements and selections interesting and it would provide more detail re: what PM software would be appropriate for you.
And the rest of the readers will appreciate the opprtunity to flame and argue over your other choices. ~:-0.
Start simple (Score:1)
It will save you time and money because you won't end up buying/writing something you don't need. And you might be surprised how useful index cards can be...
Consider Debian-sourceforge version (Score:2)
I think sourceforge could help you out a lot. Stay away from the alexandria project, it was not a very good public project when it was active and has been in active for about a year now, use the debian-sourceforge packages hosted on savanna:
Sourceforge for Debian [nongnu.org]
This project is a _working_ easy to install sourceforge system based on the last known public sources before VA pulled it in and made it proprietary again.
The two main authors (lo-lan-do and cbayle) have done an outstanding job fixing bugs and hard coded stuff VA left in there (which I think they did on purpose to make it hard to install so you had to pay them their USD100k to install it for you basically) and getting a nearly fully functional system that is accessible to all.
I like sf as a development management system very much, even though the public version they left out there is far from perfect, with several features missing that I think are close to essential for a dev mgt system, but overall I am more than willing to live without them for the rest of the features of sf and its easy to use interface for end users.
If you don't know the nightmare of installing the old 2.0 or 2.5 version then you will not appreciate fully the work of these two folks to bring sf to the average user. My thanks to them and I encourage anyone who might make use of their packages to contribute back to them in some way to say thank you.
Requirements Management (Score:3, Interesting)
I used Xplanner (http://sourceforge.net/projects/xplanner/) for a small project last spring and found it useful for a small project.
You might also look at Jakarta Maven as a related useful tool
I would add to your wishlist:
* linkages to design specs, test cases, defects and source modules.
* Team-based time estimates, project management hooks and actual time effort measures. (how can you commit to a schedule without knowing you velocity, vicinity and vector?)
Got any openings? (Score:1)
So, here's the question I'm sure a lot of us who are currently not working were thinking when we read that opening sentence: When will you have openings for developers? Where are they?
--
brother can you spare an internet connection?
Re:Got any openings? (Score:1)
Take, and enhance from something else... (Score:1)
I took from an open source project (then in it's infancy), and enhanced it for our needs. We now have web based project management software that fits our needs very well.
Of course, we fed our improvements back into the source (and I have become one of the developers). Isn't that what open source is about?
So, use the force behind open source, develop your own from what you can get. Then return, what you've learnt to the community.
Oh, and if you're interested: Have a look at
http://sourceforge.net/projects/core-lan-org
Dollar costs (Score:2, Insightful)
Let me point out that your company is already planning on spending, fully-burdened with overhead, nominally $250,000 per seat on your developers. That is salary, benefits, cost of office space, cost of lights, cost of PCs, secretarial support, janitorial support, bathrooms, water fountains, time spent perusing the lastest zero-information-content puffery from the Board of Directors, everything. $1200-$10K per seat is pretty small potatoes by comparison.
Having said that, I suggest you take another look at your wish list and ask yourself how often you REALLY are going to *USE* all those bells and whistles. Do you NEED them, or do you just WANT them? Do you NEED one-button brass-band-Mozart, or do you just need to be able to pull the data out OCCASIONALLY for a right-now CEO presentation?
Your payoff occurs when you automate the things that happen every day. Spending a fortune to automate the things that never happen is wasting time and money.
CMM, Requirements and Processes (Score:1)
Anyone else been a part of a valley death march?
Anyone else gotten stuck in the middle of long-winded discussions of what a requirement _really_ meant in the last week of a year-long development project?
XP makes a good attempt at getting requirements defined and building incrementally towards a solution.
CMM represents all of the key software processes that might be important to your organization.
In my experience you have to tailor any development process to the skills and experience of the engineers; the scope and complexity of the project; and the clarity and understanding of the end goals.
Re:Suggestion (Score:2, Funny)