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.

Sources

  • Blogs of Prof. John Vu, Carnegie Mellon University