Originally posted by Bryan Welch:
I noticed what looks like a typo on slide 6 with the " �-ilities"
That's not a typo. Look at the notes for the slide (below the side). When planning projects
you should take into account appropriate "-ilities." Does it need to be scalable? How scalable? Portable? To which platforms? Available? Can you stand to be down 1 hour per week? per month? per year?
Ilities are the intangible aspecs of a system. It doesn't define how a system works feature-wise, but it does define how the system behaves. Making a web server which support 10 hits per minute is very different from one which needs to support 10,000 hits per minute.
Originally posted by Bryan Welch:
In the QA slide, this comment surprised me:
"Developer:QA ratio should be 2:1 or better (even 1:2)"
Two QA people for each developer? I could see that as useful toward later stages of the project, possibly. In early stages when developers are doing small unit tests, wouldn't many QA people be bored?
There are many reasons.
Maybe you can stagger projects and rotate QA people across projects, achiving a ratio of 2:1 for, say, half the lifecycle of any particular project.
Many companies continue to test a product even after its been released. Certainly shortly after a release (which presumably is right around the start of the next project), you tend to get many bug reports, since you're on the start of the bathtub curve. The QA people are often the first line of defense in reproducing and tracking down where the reported bugs may lie.
Depending on the skill sets of the QA personel, they could even do profiling of the system, to suggest performence improvements. Yeah, in an ideal world the developers are profiling the code as they write. The reality is they don't have the time, and QA usually puts enhanced performance lower on the priority list than "checking for bugs" (rightly so in most cases).
Along these lines, it is rare to find a company that has a test harness which they feel is absolutely complete, having all the features they need, and all the test cases they want. QA engineers can always continue to extend the harness in terms of usability and test cases.
Finally, if you subscribe to XP, then even from the start of the project, there's a need for QA, since the code is good to go from the start.
I will certainly grant you, that the actual number can vary depending on the type of software, and these numbers are by no means hard guidelines. Since my talk was aimed at students, whose idea of QA is "it compiled!" I wanted to emphasize the importance of this part of the development process. :-)
Thanks for the feedback.
--Mark
[email protected] [This message has been edited by Mark Herschberg (edited February 16, 2001).]