Topic: Software development cycle (Games too) (Read 5978 times)

Kmelew · « **Reply #40 on:** February 11, 2004, 10:08:05 pm »

Sorry, just a little bitter. Looks like I'm going to be patching 150 servers till 5 AM with the latest hotfix. Again.

Toasty0 · « **Reply #41 on:** February 11, 2004, 10:15:13 pm »

hehehe...not sure but I assume it is better than a whole new kernal.

Kmelew · « **Reply #42 on:** February 11, 2004, 10:16:31 pm »

Never had this problem with Netware

Sethan · « **Reply #43 on:** February 11, 2004, 10:48:41 pm »

Quote:

Sorry, just a little bitter. Looks like I'm going to be patching 150 servers till 5 AM with the latest hotfix. Again.

Install a SUS server. Automation is wonderful.

Dash Jones · « **Reply #44 on:** February 11, 2004, 11:37:03 pm »

Software development cycle redux.

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
4. Repeat three times steps 3 and 4.
5. Publishers decide they must release the product, but before they do, and after they finish Q&A, they add in their "CDprotection" which does absolutely NOTHING to stop piracy and in fact, no one can actually figure out what the heck it does...until a later step...
6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
7. Users find 137 new bugs.
8. Original programmer, having cashed his royalty check, is nowhere to be found. New programming team is assembled, realize 134 of them are due to people trying to use the code on machines that are specifically identified as not being able to even run the program. Team scratches head trying to figure out how the heck these users even got the thing to run on the outdated piece of junks they used in the first place, not stopping to think that the outdated pieces of junks referred to are only 6 months old, and one needs something newer than that to meet the minimum specs.
8a. One bug is recognized to have been missed in Q&A. The other two bugs are realized to be caused by the CDprotection installed. Users leap to the conclusion that the CDprotection was put in at the last minute to either drive down sales...or rob the customers blind. Users lean towards the idea of robbing the customers blind.
9. Newly-assembled programming team fixes the one remaining bug, but introduce 456 new ones in the process. The are not allowed to do anything about the CDprotection nor the bugs it causes (unless they are named bioware...in which case there's a small chance).
10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
13. Programmer produces code he believes is bug-free...

TalonClaw · « **Reply #47 on:** February 12, 2004, 10:03:55 am »

Where I work it's like this:

Design - Get sign offs
Code
Unit Testing
Fix the bugs you found.
Shake out testing
Fix bugs
QA 1 Testing
Fix bugs
QA 1 Sign off
QA 2 Testing
Fix bugs
QA 2 Sign off
User acceptance testing - God help you if you have any bugs at this stage.
Fix bugs
User acceptance sign off

Roll out
Production - any bugs here and it goes on your review.

Scott Allen Abfalter · « **Reply #48 on:** February 12, 2004, 11:43:33 am »

Where I work is goes like this:

1. Business opportunity requires new software.
2. Date is set for delivery (development barely consulted at this point)
3. Feature content and date dictated.
4. Development tries not to have a coronary and cuts half of the feature content to meet the date.
5. Spec, Design, Code, Unit.
6. By now we've missed the original date since it was always wildly optimistic to begin with.
7. Integrate feature into system and hope for the best.
8. QA the feature until the real drop-dead date.
9. Hope we got most of the bugs shaken out, if not ship anyways and document what bugs exist, fixing them in a later patch.
10. Panic when your pager goes off at 2:00am to fix a field problem that should have been caught during test. Gnash teeth, complain about it, and watch as the cycle repeats ad infinitum.

I understand that time-to-market issues can make or break the success of a company, but it sure is hard not ever having the time to do a complete and professional job on a project.

Karnak · « **Reply #49 on:** February 12, 2004, 01:36:49 pm »

Spiral SDLC model and the resource-time-cost triangulation method is used heavily where I work. Also, the onus is front-loaded on the client to get the user requirements right. Then the Design specs. are built off the original User requirements. If the users claim there is a bug at deployement when it turns out to be a feature they neglected to put in User requirments then they have to wait for the next release. Documentation saves your butt everytime cuz you can say you built the release to the specs. that the user signed off on. If you don't document then you are hosed....

Scott Allen Abfalter · « **Reply #50 on:** February 12, 2004, 02:17:49 pm »

I did just manage a fairlt large project and we used a spiral/evolving prototype model with a lot of success.

The good thing about the spiral model is that you can continually refine development estimates with the hindsight of the prior iterations.

Karnak · « **Reply #51 on:** February 12, 2004, 02:26:54 pm »

Yes, Spiral SDLC is the mark of a minimum CAPM SEI Level 2 and above organization. I would say 50 to 75% of successful S/W development is about the process. No matter how good the talent is on your development team, if you have no process, but only choas, then you will have nothing but lotsa bugs and angry users that steadily lose confidence in your ability to produce quality products on-time and on-budget.

Scott Allen Abfalter · « **Reply #52 on:** February 12, 2004, 02:53:24 pm »

Process, clearly defined requirements and good tools are essential. But having really good coders helps.

I've heard it said that a good team has different personality types. You need a few good coders, you need some guys who are process sticklers, others who are good testers, others who have vision, etc. The more of a mix you have, the better the chance you have.

But, yes, a clearly defined process is important. And not just lip-service, you have to have the people using it BELIEVE in it.

Kmelew

Re: Software development cycle (Games too)

Scott Allen Abfalter

Re: Software development cycle (Games too)

NJAntman

Re: Software development cycle (Games too)

News: