Về truyền thống, dự án capstone là công việc cuối cùng trước khi sinh viên tốt nghiệp khỏi đại học.

Với sinh viên khoa học máy tính và kĩ nghệ phần mềm, nhiều dự án capstones là “dự án thực” được cho bởi các công ti trong công nghiệp phần mềm. Trong những dự án này, sinh viên phải áp dụng mọi tri thức họ đã học trong cả bốn năm đại học để giải quyết các vấn đề thực. Các dự án capstone thường là dồn dập, yêu cầu nỗ lực lớn trong cả lập kế hoạch và thực hiện. Trong vài năm qua, tôi đã tiến hành một khảo cứu về capstones ở Nhật Bản, Hàn Quốc, Trung Quốc và Ấn Độ. Sau đây là một số quan sát của tôi:

Nhiều tổ capstone nhận được tài liệu yêu cầu từ khách hàng nhưng thay vì kiểm nghiệm hay thẩm tra yêu cầu họ bắt đầu dự án ngay lập tức. (Về sau tôi thấy ra rằng kĩ nghệ yêu cầu không được dạy trong chương trình của họ.) Nhiều tổ không ước lượng và thương lượng về lịch biểu vì họ tin nó là cố định và không thể được thay đổi. Thường xuyên hơn, tổ bắt đầu dự án bằng việc họp nhiều lần trong tuần để thảo luận cách phân chia công việc nhưng ít người biết cách làm việc trong tổ và quản lí thời gian của họ. Có nhiều thảo luận và biện luận trong các thành viên tổ cho tới khi thời gian sắp hết rồi họ bỏ qua thiết kế và hội tụ vào viết mã. Vì thời gian sẵn có bị giới hạn, đa số công việc dự án được thực hiện bởi vài người làm việc cho tổ với thời gian dài. Tài liệu dự án được viết với ít chi tiết hơn vì nó thường được phân công cho thành viên yếu hơn của tổ như cách cung cấp cho họ cái gì đó để làm. Bởi vì họ không tham gia vào các hoạt động dự án, họ chỉ có thể làm tài liệu điều họ biết. Các chức năng phần mềm thường bị rút bớt lại so với những hứa hẹn ban đầu cho khách hàng bởi vì tổ không thể kết thúc mọi thứ vào lúc cuối.

Phần lớn các dự án capstone đều chuyển giao thấp hơn nhiều so với mong đợi và không qua được kiểm thử chấp nhận của khách hàng. Lí do là tổ gặp khó khăn khi cân bằng tải việc trong toàn dự án. Họ không biết cách ước lượng thời gian được yêu cầu. Họ không biết cách tổ chức nỗ lực của họ cho tốt nên họ dành nhiều thời gian lúc ban đầu vào thiết kế rồi khám phá ra họ không có đủ thời gian cho nên họ dừng lại và nhảy vào viết mã, khi thời gian là không đủ, họ bỏ qua kiểm thử vội vàng cho hoàn thành dự án để cho họ có thể kết thúc dự án capstone và tốt nghiệp.

Nhiều tổ đi theo vòng đời thác đổ nhưng họ thường bỏ qua điều họ làm việc trong yêu cầu và thiết kế khi lao vào viết mã vì mọi sự thay đổi. Không có gì dõi vết được giữa mã và thiết kế và giữa thiết kế và yêu cầu bởi vì nhiều thay đổi đã xảy ra. Ngay cả khi tổ dùng vòng đời lặp, họ có xu hướng tập trung vào chức năng mà họ biết cách mã nhưng để trễ làm việc trên những chức năng khó hơn. Do đó, dự án bao gồm số lượng lớn các chức năng nhỏ nhưng thiếu nhiều chức năng then chốt.

Nhiều thành viên tổ không biết cách làm việc trong tổ nhiều người. Phần lớn các kĩ năng họ học trong bốn năm là về công việc của một người và nó không đổi được qui mô tốt theo dự án với nhiều người. Quản lí cấu hình là vấn đề bị lẫn lộn trong tổ. Nhiều tổ đã không có cách thức đúng để kiểm soát mã nguồn của họ. Nhiều tổ đặt mã của họ ở kho trung tâm, sao chép các tệp cần thiết vào máy tính riêng của họ, làm thay đổi, và rồi thay thế các tệp mà không kiểm tra để xem liệu nội dung gốc có thay đổi trong thời gian đó không. Có các vấn đề về thiếu tệp, thiếu mã trong toàn dự án capstone.

Khi thành viên tổ bận rộn, họ dừng trao đổi lẫn nhau và hội tụ vào công việc riêng của họ. Đây là chỗ nhiều sai lầm được thực hiện. Nhiều tổ không theo dõi khiếm khuyết, đặc biệt trong những tuần cuối cùng trước khi chuyển giao cho khách hàng. Phần lớn các tổ thường không biết liệu khiếm khuyết có được chữa hay không.

Làm việc tổ là cái gì đó không được dạy tốt ở Trung Quốc và Ấn Độ. (Nhật Bản và Hàn Quốc là tốt hơn nhiều.) Ở hai nước này, trách nhiệm của các thành viên tổ thường không rõ ràng. Mặc dầu mọi thành viên tổ đều có kĩ năng kĩ thuật tốt, vài người có đào tạo trong làm việc tổ. Lúc bắt đầu, các tổ được cấu trúc với người lãnh đạo chính thức và ít vai trò được xác định. Tuy nhiên, khi dự án tiến triển, các thành viên tổ nói chung cảm thấy không thoải mái với nhau khi bản ngã của họ bắt đầu nổi lên. Có nhiều xung đột xảy ra trong toàn dự án và thường kết thúc với từng người làm việc riêng của họ một cách độc lập chỉ để cho dự án chạy.

Các thành viên tổ với kĩ năng yếu thường né tránh làm việc hiệu quả bằng việc ẩn đằng sau vai trò mơ hồ như làm tài liệu hay giữ thời gian. Các thành viên với kĩ năng mạnh không muốn nhận điểm xấu, bù cho các thành viên yếu bằng việc nhận công việc phụ thêm. Phần lớn các tổ cảm thấy thoải mái viết mã nhưng họ bao giờ cũng vật lộn giải quyết với vấn đề tích hợp. Đây là chỗ họ cần giúp đỡ từ các thầy trong khoa. Về căn bản, họ không biết cách phát triển phần mềm, cách công nghiệp làm việc. Nói cách khác, họ cần học về qui trình phần mềm được xác định tốt.

—-English version—-

Capstone projects in Asia

Traditionally, a capstone project is a final work before students graduate from college. For computer science and software engineering students, many capstones are “real projects” given by companies in the software industry. In these project, students have to apply all the knowledge that they have learned throughout their four years in college to solve real problem. Capstone projects are often intensive, requiring significant effort in both planning and implementing. In the past few years, I have conducted a study of capstones in Japan, S. Korea, China and India. Following are some of my observations:

Many capstone teams receive requirements document from customers but instead of validate or verify requirements they start the project immediately. (Later I found out that requirements engineering is not taught in their programs). Many teams do not estimate and negotiate the schedule as they believe it is fixed and cannot be changed. More often, teams start project by meeting several times a week to discuss how to divide the work but few know how to work in team and managing their time. There are more discussions and arguments among team members until time is running out then they ignore designs and focus on code. Since there is limited time available, a majority of project work is done by a few people on the team working long hours. Project documentation is written with fewer detail as it is often assigned to the weaker members of the team as a way of providing them something to do. Because they do not involved with project activity, they can only document what they know. Software functions are often reduced from the initial promises to the customer because the team could not finish everything in the end.

Most capstone projects delivered well below expectation and did not pass customers’ acceptance tests. The reason is teams had difficulty balancing the workload throughout the project. They do not know how to estimate time required well. They do not know how to organize their efforts well so they spend more time in the beginning on designs then discover that they do not have enough time so they stop and jump to code, when time is not enough, they skip tests to hurry get the project complete so they could finish the capstone and graduate.

Many teams follow a waterfall lifecycle but they often ignore what they work in requirements and design when get to code because things are changing. There is no traceable between code and design and between design and requirements because so many changes already happened. Even when the teams use iterative lifecycles, they tend to concentrate on functions that they know how to code but delay working on more difficult functions. Therefore, projects consist of large amounts of small functions but miss several key functions.

Many team members do not know how to work in multiple person team. Most skills they learned in their four year is on a single person work and it does not scale well to project with several people. Configuration management is the most confusing issue among teams. Many teams did not have a proper way for controlling their source code. Many teams place their code in a central repository, copy needed files to their own computers, made changes, and then replace the files without checking to see whether the original contents had changed during that time. There are issues of missing files, missing code throughout the capstone projects.

When team members are busy, they stop communicate with each other and focus on their own work. This is where more mistakes are made. Many teams do not track defects, especially in the last few weeks before deliver to customers. Most teams often do not know if defects are fixes or not.

Teamwork is something not taught well in China and India. (Japan and S. Korea are much better). In these two countries, team members’ responsibilities are often not clear. Although all team members do have good technical skills, few have training in teamwork. In the beginning, teams are structured with a formal leader and few defined roles. However, as the project go on, team members generally feel uncomfortable with each others as their egos set in. There are a lot of conflicts happening throughout the project and often end up with each do their own work independently just to get the project working.

Team members with weak skills often avoid productive work by hiding behind ambiguous role such as documentation or time keeping. Members with strong skills do not want to receive bad grade, compensate for weaker members by taking on additional works. Most teams feel comfortable to write code but they always struggle to deal with integrated issues. This is where they need help from faculty. Basically, they do not know how to develop software the way the industry work. In other words, they needed to learn about well defined software process.