Nó áp dụng cho mọi pha của vòng đời phát triển phần mềm như xác định yêu cầu, thiết kế kiến trúc, phát triển mã, và làm tài liệu. Bằng việc tuân theo kỉ luật và cách đo nghiêm khắc, người kĩ sư có thể tạo ra sản phẩm phần mềm chất lượng rất cao. Cách tiếp cận PSP dựa trên từng kĩ sư phần mềm tuân theo một qui trình xác định, đo công việc riêng của mình và quan sát hiệu năng riêng của mình. Việc nhìn vào dữ liệu riêng của mình tạo động cơ cho người đó thay đổi cách người đó làm việc.

Qui trình phần mềm tổ – Team Software Process (TSP) là phương pháp tạo ra khả năng cho “tổ phần mềm PSP” để xây dựng sản phẩm phần mềm hiệu quả hơn. TSP bổ sung thêm các kỉ luật quản lí dự án để giúp cho tổ lập kế hoạch công việc và lịch biểu. Điều này yêu cầu tổ tuân theo kỉ luật chặt chẽ để cộng tác với những người khác trên các hoạt động dự án. Người kĩ sư vẫn quản lí công việc riêng của mình và nhận quyền làm chủ kế hoạch riêng của mình nhưng TSP giúp từng kĩ sư trở thành thành viên tổ hiệu quả.

TSP dùng các phiên lập kế hoạch dựa trên tổ có tên là “khai trương” để gắn các kế hoạch dự án chi tiết tại chỗ. Lập kế hoạch dựa trên tổ có ưu điểm là nhiều thành viên làm việc cùng nhau sẽ tạo ra bản kế hoạch chính xác hơn bản kế hoạch người quản lí dự án làm việc một mình. Hoạt động dựa trên tổ cũng sẽ nhận diện các nhiệm vụ chi tiết với nhiều sự phụ thuộc hơn là một người làm việc cô lập, và các nhiệm vụ toàn thể sẽ có ít lỗi hơn bởi vì lỗi từ nhiều hoạt động không liên hệ có xu hướng cắt bỏ lẫn nhau.

Khai trương ban đầu TSP đặt bản kế hoạc mức đỉnh tại chỗ cho toàn thể dự án và kế hoạch chi tiết bao quát ba tháng tiếp đó.  Việc khai trương lại được thực hiện cứ sau ba tháng để tạo ra bản kế hoạch chi tiết cho quí tiếp hay bất kì khi nào mọi sự thay đổi nhiều tới mức kế hoạch hiện tại không còn áp dụng được.  Phiên lập kế hoạch tăng dần ngăn ngừa vấn đề tạo ra bản kế hoạch dự án chi tiết sớm mà có thể thay đổi trong tiến trình của dự án. TSP yêu cầu cuộc họp hàng tuần để thảo luận về tiến độ trong các thành viên tổ. Từng thành viên theo dõi tình trạng riêng của mình trong tuần và báo cáo cho tổ. Qui trình này được thiết kế để cho sức ép ngang quyền trở thành lực mạnh trong việc động viên hiệu năng tốt hơn.

PSP và TSP nên được tổ hợp thành qui trình phát triển phần mềm để rút bớt chi phí phát triển, tăng năng suất và chất lượng. Yếu tố then chốt là cách tiếp cận “dưới lên” nơi người kĩ sư phần mềm chịu trách nhiệm cho nhiệm vụ và lịch biểu riêng của họ thay vì dựa vào người quản lí dự án phân công lịch biểu và nhiệm vụ cho các thành viên tổ. Về toàn thể, cả PSP và TSP đều có ưu điểm so với các kĩ thuật khác vì chúng cung cấp cơ chế cho thay đổi hành vi và văn hoá bên trong tổ chức phần mềm qua chương trình đào tạo nghiêm ngặt của nó.

Điều khó khăn nhất trong thực hiện PSP và TSP là thái độ và kỉ luật của  cả người kĩ sư phần mềm và người quản lí.  PSP và TSP KHÔNG phải là kĩ thuật khó học, chúng KHÔNG phức tạp như nhiều người tưởng nhưng chúng quả có yêu cầu thay đổi hành vi trong các kĩ sư phần mềm. Chừng nào cấp quản lí còn chưa rất nghiêm túc và hỗ trợ mạnh, PSP và TSP là khó thực hiện trong tổ chức phần mềm nơi nó đã có qui trình đang đó và mọi người ngần ngại thay đổi.

Theo ý kiến tôi, tôi tin PSP và TSP nên được dạy sớm trong chương trình kĩ nghệ phần mềm khi sinh viên bắt đầu học lập trình thay vì muộn hơn vì hành vi xấu và thói quen cũ khó thay đổi.

English version

PSP and TSP

The Personal Software Process (PSP) is a method for individual software engineer to improve their development skills in building quality products. It applies to all phases of software development lifecycles such as requirements definition, architecture design, code development, and documentation. By following a rigorous disciplines and measurements, engineer can producing very high quality software products. The PSP approach is based on each software engineer follows a defined process, measure his own works and observing his own performance. By looking at his own data motivates him to change the way he works.

The Team Software Process (TSP) is a method that enables “PSP software teams” to build software products more effectively. TSP adds a project management disciplines to help the team plan the works and schedules. This requires the team to follow a strict discipline to collaborate with each others on project activities. The Engineers still manage their own works and take ownership of their own plans but TSP helps each engineer to become an effective team members.

TSP uses team based planning sessions called “launches” to put the detailed project plans in place. Team based planning has advantages as several members working together will create a more accurate plan than one project manager working alone. Team based activities will also identify more detailed tasks with more dependencies than a single person working in isolation, and the overall tasks will have less errors because errors from multiple uncorrelated activities tend to cancel each others out.

The TSP initial launch puts a top-level plan in place for the entire project and a detailed plan covering the next three months.  Re-launches are performed every three months to create the detailed plan for the next quarter or whenever things change so much that the existing plan is no longer applicable.  The incremental planning session prevents the problem of creating a detailed project plan early that may change during the course of the project. TSP requires a weekly meeting to discuss progress among team members. Each member tracks his or her own status for the week and report to the team. The process is designed so that peer pressure becomes a powerful force in motivate better performance.

PSP and TSP should be combined in the software development process to reduce development cost, increase productivity and quality. The key factor is the “bottoms up” approach where software engineers are responsible for their own tasks and schedules instead of relying on the project manager to assign schedule and tasks to team members. Overall, both PSP and TSP have advantage over other techniques as they provides a mechanism for behavior and cultural change within software organization through its rigorous training program.

The most difficult in implement PSP and TSP is the attitude and disciplines of both software engineers and managers.  PSP and TSP are NOT difficult techniques to learn, they are NOT complex as many people thought but they do requires behavior change among software engineers. Unless management is very serious and strongly support, PSP and TSP are difficult to implement in an software organization where it already have an existing process and people are reluctant to change.

In my own opinion, I believe PSP and TSP should be taught early in the software engineering program when students begin to learn programming rather than later as bad behavior and old habit are difficult to change.