Week 5 - PSP with TSP development methodology

http://www.sei.cmu.edu/tsp/psp.html

What is PSP?
PSP stands for the Personal Software Process. It provides the disciplined and structured way for programmer to develop the program under the scheduled period since the cost of the software development heavily depends on the timing costs. As the result, the quicker the development of the software, the more profit that the company can gain.

As the PSP is so flexible and productive, it applied to many aspects. For example, the small software development, the software requirement definition, document writing, system tests, system, maintenance, the enhancement of large software systems as well. It almost covers all the status in the software production process.

Compare with the PSP, TSP (Team Software Process) is more suitable for the large to enterprise on the software development companies.

What is TSP? It is the original of the PSP. It aims to help the team of HIGH PERFORMANCE engineers to:
1. Ensure the quality SW products,
2. Create secure SW products
3. Improve process management in an organization


TSP and PSP are so popular in the software in-house company because they focus on the quantity rather than the quality of the software products. This methodology focus and stress on the disciplines guided and structured software development. Listing out what when how why to do every day routine on the document and programmers exhausted. This method does not consider the resting time of the programmer; always consume the working hours on the software development. If such methodology applied to the organization, the productivity decreases but not increases. It is because the undetermined workloads tired the driving force, the programmers. There’s just no rest and it seems "assume" that the programmer need to work 24 hours a day, 7 days a week!

We can get started with PSP and TSP by the following URL as reference:
http://www.sei.cmu.edu/tsp/get-started.html

Remarks: PSP modeling software.
http://processdash.sourceforge.net/index.html

Week 4 - Test-Driven Development lets you eliminate bugs as you code

http://techrepublic.com.com/5100-22-5077388.html

The site has briefly descript what is Test-Driven Development (TDD) and how can it be conducted. The cycle of the TDD is as mentioned in the site, I would like to pick some as a reference for this article:
1. Add a little test
2. Run all tests and fall
3. Make a little change
4. Run the test and success.
5. Re-Factor to remove the duplicate codes

It also shows some of the example on how to use the Debugger software to test the program automatically.

Test-driven development does good job especially for the small to medium-size of software development. What if such methodology apply to the large software development, say the Operating System for Super-computer? Certainly not!
On the other hand, there is a stage mentioned that the development of the software may stop in one phase if the programmer like to modify the code until it run prefect. Every software has bugs. We can never debug it and make it prefect. What would be the consequences of the programmer continue to test-code-run again and again? The product could certainly delay release.

In order to improve the TDD methodology, I think programmer need to set the due date of the release of the Alpha, Beta and Final release version in order to complete the task on time.

Week 3 - Test Drive Development in XP

http://c2.com/cgi/wiki?TestDrivenDevelopment

Test Driven Development(TDD)
TDD is the inner core of the outer shell of the Extreme Programming(XP). In this web-page, the author write some basic rule that we should notice before undergo the TDD. WE should think what we want to do, should think about how to test and write a small test, write enough code that just pass the tests.

I would like to ask him if the TDD is a good way to design the project, can it be applied to develop the project that as big as developing an Operating System, or a huge database management system? Obviously this methodology cannot do that since it focus on dividing the big problems into small piece and just work it, solve it but test-code-debug process. In a small part of the system, it may not be testable before combining with other components that developed by developer in the same team or even in other teams. So what about if the program cannot be tested? The whole methodology crashed and not workable at all.