Jump to content
  • Advertisement
Sign in to follow this  
RyanZec

Your input about your programming process for my project

This topic is 4216 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

I am currrently in the process on design a project managment system for tracker progress on programming projects. Right now I am trying to think of what types of "Issues" programmers have to deal with and what information they need for each type of issues. right now my list consist of these three:
  • Tasks
  • Bugs
  • Enhancements
I am also thring to think how things link up. For me, i think Bugs and Enhancement will consist of one or more task to complete, and task will consist of one or more task to complete and issues will consist of 1 or more task to complete as well but there will never be 1 issue theat require another issue to be completed to fix the first issue. Another thing i am think about is what information a bug/task/enhacement needs. For instances these are thing all of those will need:
  • ID
  • Creator
  • Assigned to
  • Issue
  • Created On
  • Due Date
  • etc...
Any help of any of these thing would be greatful, i want ot build a very complete system when it comes to task/bugs/enhncement/etc.. so if you have any additions to "issue types" linking between "issue types" and information all and information only a certain "issue type" needs [Edited by - RyanZec on January 29, 2007 5:12:06 PM]

Share this post


Link to post
Share on other sites
Advertisement
Let me go into some detail about what I am talking about.

Issue Types



There are 3 major issues that I can think of that are somewhat different. The first type is a task which is basically the main issue, ever other type of issue will have atleast one task. The second type of issue it a bug. Now a bug. The last type of issue I can can of is an enhancement.


Link Between Issues



The top level of the linking structure is going ot be calles "Issue". Everything is going to be linked to one and only one issue. Now Issues can have have any issue type linked to it link the following:



  • Task issue type links to "Issue"
  • Bug issue type links to "Issue"
  • Enhancement issue type links to "Issue"
  • etc...


An Issue can have one or more tasks linked to it but an Issue can only have one bug issue type or one enhancement issue type linked to the one Issue link the following:



  • task1/task2/task3 l;ink to Issue1
  • bug1 links to Issue2(bug1/bug2 links to Issue2 - not possible)
  • enhancement1 links to Issue3(enhancement1/enhancement2 links to Issue3 - not possible)
  • etc...


The last linking I can think of is that bugs and enhancements can have mutliple tasks linked to them but can not link to each other as in the follow:



  • task1/task2/task3 link to bug1
  • task1/task2/task3 link to enhancement1
  • bug1 links to enhancement1(not possible)
  • enhancement1 links to bug1(not possible)
  • etc...


One thing to note about enhancement, they are basically the same exact thing as a task but they have not tasks assigned to them by default. this will allow someone to reveiw the request and if they fell it is not possible they can decline as and say why or if they fell it is a good enhancement they can then assign tasks to it.


Issue Type Information Needed


Task



  • id
  • linked issue id
  • created by
  • assigned to
  • created on
  • title
  • description
  • goal completetion date
  • actual completion date
  • priority

Bug



  • id
  • linked issue id
  • created by
  • assigned to
  • created on
  • title
  • description
  • goal completetion date
  • actual completion date
  • severity
  • tasks ids to complete bug
  • priority

Enhancement



  • id
  • linked issue id
  • created by
  • assigned to
  • created on
  • title
  • description
  • goal completetion date
  • actual completion date
  • priority

Any input you can give me on any section here would be greatly helpful

Share this post


Link to post
Share on other sites
Why bother? From what you've presented, your system offers nothing in addition to the features provided by existing issue tracking tools (BugZilla, FogBugz, CVSTrac, Trac, Scarab, Jira, et cetera, et cetera, et cetera).

Furthermore your method of giving task/bug/enhancements slightly different fields is going to be annoying, and you don't need to have a lot of fields because that just becomes a pain to manage and fill out, and you end up with most of the "extra" (or "apparent duplicates" like severity and priority) going unused.

What's wrong with an existing system?

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Furthermore your method of giving task/bug/enhancements slightly different fields is going to be annoying, and you don't need to have a lot of fields because that just becomes a pain to manage and fill out, and you end up with most of the "extra" (or "apparent duplicates" like severity and priority) going unused.
Actually severity and priority can be quite different, and I wish that the system we had at work distinguished between the two.

So what do you call a part of the system that has undesirably slow performance, but actually works correctly? I would say that it is neither a bug, nor an enhancement. We use the term 'Anomaly' rather than bug, and let this cover 'performance anomalies'.

Share this post


Link to post
Share on other sites
Why, I ask you why not? It not like right now I am under heavy pressure to get a Project management system up and running and it is also great experience to build one.
Now about the currently systems:

Bugzilla:
Not a bad system at all but what we need is going to be a little bit more in-depth with tracking other information beside what bugzilla tracks.

FogBugz:
After taking a look at it seem very nice (the interface at least) however I don't like that price on how they price per user and not one price for the software itself. That is my 1 single biggest problem with some of the big project management system pricing (FogBugz, GForge, SourceForgeEE) If I were to use this I would need right now about 10 users which would cost about 1000 dollars, and for that amount of money, I be better off written my own where I could have 1000000 user for the same price.

CVSTrac:
Again, this one is ok; don't like the interface that much but again there is more information I am going to need to store/track.

Trac:
Not bad but the biggest problem with this is it is written in Python. If I want to add or change something it is going to be a pain in the ass for me to do it because I have never touch a piece of python code in my life, I want to stick with PHP and MySQL.

Now of a few of them all I might want to do it to add some functionality and change some stuff but I don't want to have to learn how there database structure is setup and chances are some of the functionality I am going to want will require portions of the database to be rewritten and there is just a point where it would be faster to just scrap portions of the code an database and just rewrite it and for this reason is would be a lot better to just write my own application. Personally I don't want to work on open source code because generally I don't like dealing with other peoples code, I have to deal with poorly write undocumented code at work for 8 hours a day, I would like to not have to deal with it at home too. Some of the major benefits are:

I will know that code and database inside out because I created it.
Add and change things will be a lot easier because I will know the code and database structure a lot better and change the database/code with will easier because I will know if I need to change anything else so I don't break other things.


These are my reason for wanting to build a project management system form scratch and the main one is because I have the time to build one and not under pressure right now to get something up and running (for me the open reason to ever use code already written is A) The code is near perfect for what you need, nothing existing is "near prefect" for what I need, and B. You need something now and can't afford the time to build it yourself (I can afford the time to build this)

Oh about the severity and priority, they are quite different (I guess I would have worded better). Priority is basically a way to list what needs to get done first. Severity is only is bug because it describes how severe the bug is (like it crash program, make X portion or program to give incorrect result, etc...)

Share this post


Link to post
Share on other sites
I'm going to disagree. I think that priority and severity are very much related. If a bug is severe then it should be given higher priority. Bugs are just features that you want to remove from your program after all.

Share this post


Link to post
Share on other sites
Have you looked at the current source code for Bugzilla? Assuming you can build a system from scratch faster than you can adapt an existing one is only reasonable if the existing systems are all badly programmed (this is not the case). Other than that, it's an idiot's bet. Don't reinvent the wheel.

Share this post


Link to post
Share on other sites
For the most part, yes I would agree the higher the severity the higher the priority but I don't think this will always be the case. For instance, I am programming a game engine and there is a bug in the sound system when you enable something in the sound system and it crashes the game. For me that is a pretty severe bug in the sound system but right now I don't need that feature in the game to make the prototype of the game to show to clients so I would put that as a high severity but a low priorit because getting the fixed is no major, I can just disable the feature for the time being. This is one case where those 2 can be quite different.

Share this post


Link to post
Share on other sites
Okay, I haven't read everything totally, but I'll reply to the bits I skimmed over:

Severity and Priority are a little different, but not enough to warrant a distinction between them. Users will just get confused, use them interchangably, and eventually they will merge in meaning anyway. EDIT: in reply to RyanZec's last message, if you don't care about the bug then it's not very severe, right? Priority and severity are close enough in meaning to treat as one and the same. The very fact that people think this way should demonstrate that.

There are plenty of tools out there already, but there are some features I'd really like to see (all in one package), that could distinguish yours from theirs;
* Sub-tasks, i.e. tasks can be split up hierarchically.
* Proper distinction between bugs, tasks and enhancements - they're not equivalent but with a different tag (you don't "fix" a task).
* Proper linking between tickets and SCM revisions - Trac is nearly there, but it's a little flaky.
* Most importantly, some form of standard templating/abstraction system. Our current project is using Trac, but it's an absolute nightmare to integrate into the rest of the website's look & feel. A template engine would fix this nicely, and AFAIK there aren't any issue trackers that do this without defining their own new proprietary standard.

Aside from that, please share existing terminology with some existing tool, otherwise you'll alienate and confuse users.

Hope I've given you some food for thought :)

Share this post


Link to post
Share on other sites
Well, I'd also recomend using or modifying an existing solution. It really is a lot of work to create something thats stable and usefull.

I worked at a company who used a proprietary system which was built as a customization on top of Microsoft CRM (Customer Relationship Management.) Said company specialized in customizing CRM for other clients, so the development was in-house.

Honestly, it was a pretty solid system that fit exactly to our workflow, but even with the CRM software as the backbone of our customizations, and devs who knew every in and out of it, it was still many, many man-hours of work. Without the backbone already done, it surely would have been thousands of man-hours.


---

Whether you decide to roll your own or modify an existing system, I do have some advice however:

1) Make sure that your objects keep a complete history.
2) Don't just think of bugs and tasks coming down from the top, also think of bug reports and feature requests coming up from the bottom and how to easily turn such requests into bugs/features for the devs to take action on.
3) Support bulk editing operations: When a dev has to push several bugs back a week, you'll save a ton of time if he can do it on all at once.
4) While severity and priority are related they are not equal: don't treat them that way. Its entirely possible to have a show-stopper bug that's simply so rare that its priority will be low. Severity describes the impact of the error, while priority is more about (human) resource management and scheduling in relation to other bug fixes.
6) Choose labels carefully to limit ambiguity. As another poster said, a task is not "fixed" its "completed." When its possible and doesn't introduce an ambiguity use the same labels. Also be weary of overloading labels with more than one meaning in different contexts as this can also lead to ambiguity.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!