Tips for developing good quality software

[Itronix]

Here some of the tips for developing good quality software.

1. Your project team to use source code management tool begin?
Should be used. VSS, CVS, PVCS, ClearCase, CCC / Harvest, FireFly can be. My choice is VSS.

2. Your project team using the defect management system begin?
Should be used. ClearQuest is too complex, my recommendation is BugZilla.

3. Your test team is using Word to write test cases Mody?
Do not use Word to write test cases (Test Case). Should be a dedicated system, which can be Test Manager, you can develop an ASP.NET their own small Web site. The main purpose is to Track and Browse.

4. Your project team has not established a portal website?
To have a portal to let Contact Info, Baselined Schedule, News and so on. Recommended Sharepoint Portal Server 2003 to achieve 15 minutes Gaoding. SPS 2003 can not afford to buy WSS (Windows Sharepoint Service).

5. Your project team with the best you can buy the tools?
Should be used as a good tool to work. For example, should be used VS.NET instead of Notepad to write C #. Use Notepad to write programs are usually just a show off. But we must take into account the funding and so he said yes, "You can buy the best."

6. Your programmers work in a quiet environment Mody?
Needs a quiet environment. This is extremely important, but also to ensure that each person's space is larger than a certain area.

7. Your staff everyone has a phone Mody?
Need to call each one. And the phone is best with a message function. Of course, such a set with a message on the phone system overhead is not small. But at least everyone should have a telephone, please do not Gaode often someone would stand up and say: "such and such a phone." "Human parts" which would strongly condemn the practice.

8. Have you ever had someone say, "I thought ..." manner?
To eliminate the "I thought." Never assume anything.


9. Your schedule, whether it reflects the latest development progress to date?
Should reflect. However, the method should be used to manage the Baseline schedule: Maintaining a stable Schedule, and then to maintain an updated change. Baseline approach should also apply to other Spec. Baseline is a change management inside an important means.

10. That your workload is to leave each person their own estimates?
Should allow each person their own estimates. From the bottom-up estimates of the workload, rather than down from the previous assignment. Unless there are other reasons, such as the duration of the fixed and other political task.

[Itronix]

11. Your developers from the outset of the project work overtime Mody?
Cut that out. Do not start engaging in a battle fatigue. From the outset of the project to work overtime, it only indicates the progress of the project unreasonable. Of course, some software outsourcing to Japan to work overtime every day, it belongs to exploitation.

12. Your project plan in Buffer Time is added to the back of each small task Mody?
Do not. Buffer Time added to the back of each small task, it is easy to be consumed easily. Buffer Time should be added to the entire paragraph or a checkpoint in front of a Milestone.


13. Worth to spend more time, from 95% to achieve 100% good
Worth it, well worth it. Especially when the project later became exhausted, when to press on. This will bring about a qualitative difference between products.

14. Registration of new defects?
To. This is a matter of communication between the Dev and Test tool. Face to face communication needs, fill out a Repro Steps also needed.

15. To write new code would of known defects before the settlement Mody?
To. Each person's flaws can not exceed 10 or 15, or the old bug must be resolved in order to continue to write new code.