Archived

This topic is now archived and is closed to further replies.

Project management software

This topic is 5088 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, At school I''ve been assigned as project manager for one of our software projects, and I was wondering what kind of software is available for managing such a project. Since I can''t buy anything, I''m bound to the licence ofcourse as I intend to use it at school to manage. We''re with eight people and are supposed to make a simple game in about fourteen weeks. This is not much an excersize for our programming skills, but our management and team-working skills. Anyway, I heard of Microsoft project and seen a few things of it, but because of it''s licence I''m not allowed to use it at school (school, student, tight budget ). But I believe it''s in the right direction of what I''m looking for. Basically I''m looking for a one-in-all package that allows me to do my planning, work breakdown, make my charts, perhaps even do some version management, etc etc. Everything that comes to a project really. So, does anyone know if there are any free projectmanagement tools out there? And what do you use? What package has your preference? Thank you for your time.

Share this post


Link to post
Share on other sites
NetOffice (http://netoffice.sourceforge.net/index.php) is free but you'll need a server running Apache2, PHP and MySQL. On the Windows machine, you will need to install PHP4 manually, but the installation 'receipe' is well-documented.

For version management, try CVS (http://www.cvshome.org/). It's free and works on all platforms.

For bug tracking (and task management to some degree), you could use BugZilla (http://www.bugzilla.org/). It runs on Linux only though.

-cb

[edited by - cbenoi1 on January 4, 2004 9:50:11 AM]

Share this post


Link to post
Share on other sites
Ah, a software engineering course. Or, as I subtitled the one at my university, "How to turn a game one person can make into a game sixteen people can''t."

I think the most valuable lesson I got out of mine was, dispense with that kind of formality as much as you can. The important thing is knowing what everyone needs to get done in the next N weeks, and don''t entertain delusions that you know anything about the cases where N>3 or so.

You don''t need the overhead.

In my university''s version of the course, you basically got 70% of your mark for writing reports, 25% for the final exam and 5% for actually having a working product at the end. When having that much documentation available to say "yes, we analysed the risks, designed everything out etc." becomes an acceptable way of failing, it''s no wonder that the end product sucks. My guess is that it happens all the time in the real world.

Be happy you get the experience now, when failure of the project won''t cost money (or much of your mark, if your school is anything like mine).

Share this post


Link to post
Share on other sites
quote:
Original post by Zahlman
Be happy you get the experience now, when failure of the project won''t cost money (or much of your mark, if your school is anything like mine).


Just some FYI, university courses in software engineering typically have you create projects that you are expected to fail to produce on time. The reasoning behind this is so you learn what may have caused the failure, so you can learn from mistakes and improve in the future. If you care about your work, rather than your grade, just having documentation that you analyzed risks and designed your software will not be an acceptable way of failing. That''s the experience you seem to have missed, based on what you say.

With that in mind, analyzing risks and using software design practices are important for any project. Never underestimate them. The types of practices use vary from project-to-project and from team-to-team, but the well-known fact in the software industry is that any software engineering practices is better than no software engineering practices.

Share this post


Link to post
Share on other sites
Mm. Thanks for the insight. I kinda figured that we weren''t really supposed to complete the actual project given how little weighting it had. It still is annoying to have to go through the process though. As you probably guessed I haven''t had much experience working for big companies; I only hope things are not quite as bad as I''ve been led to believe...

Formality and I tend not to mix very well in general, especially where work is involved It also still annoys me that there was no mention of XP in my SE course, and honestly very little description of anything other than Waterfall methods. And no pause to consider that Waterfall''s prediction that a $1 bug in initial design will cost $10^N later - is the result of trying to do things that way.

Of course my team has considered the risks out there, and we''re happy with the projects we''re working on. (Since we started from scratch, we may flop, but we have little to lose except our free time.) And certainly I have design practices - they don''t happen to involve making UML diagrams, but they are oriented towards developing a nice OO class structure.

I''m still trying to find that compromise between design-it-all and embrace-change - seems to be working pretty well for me now though. You may have heard the line "Teach Yourself Programming in Ten Years" - now that I think about it, I''m nearing that mark, if you count all my experience with Hypercard/Hypertalk back in the Olden Days(TM).

Eh... I''m losing focus. That''s enough for now, then, I guess.

Share this post


Link to post
Share on other sites