Có khác biệt giữa kĩ năng máy tính được dạy ở đại học và kĩ năng được công nghiệp phần mềm cần tới.

Khác biệt này dường như là do quan điểm hàn lâm nhìn về các lí thuyết máy tính phải được dạy thế nào cho sinh viên và kinh nghiệm của các giáo sư. Quan điểm hàn lâm về dạy tập trung vào chuỗi bài giảng về lí thuyết tính toán và thực hành thì dùng các bài tập về lập trình. Trong khi cách tiếp cận này hợp lí, các bài giảng và bài tập trên lớp thường thiếu “tri thức chiều sâu” của điều đã xảy ra trong các dự án phần mềm thực. Đó là lí do tại sao nhiều sinh viên rất giỏi ở trường lại khó áp dụng lí thuyết của họ vào thực tế khi làm việc trong công nghiệp phần mềm. Sau đây là một số khác biệt:

Cách tiếp cận hàn lâm nhấn mạnh:

1. Xây dựng các chương trình nhỏ, cỡ vài trăm dòng mã.
2. Dùng các ngôn ngữ lập trình như Pascal hay C.
3. Mọi thứ bao giờ cũng “bắt đầu mới” cho từng bài tập lớn.
4. Trường học hiếm khi dạy việc dùng các công cụ phần mềm hay sản phẩm bán sẵn Commercial-off-the-shelves (COTS).
5. Lập trình trong cô lập hay trong nhóm nhỏ.
6. Niềm tin rằng nếu một chương trình “làm việc”, nó là tốt.
7. Cách tiếp cận phát triển không hình thức (chủ yếu viết mã) thay vì cách tiếp cận chặt chẽ yêu cầu nhiều kĩ năng hơn.

Người phát triển phần mềm thực hành trong công nghiệp phải giải quyết:

1. Hệ thống phần mềm lớn, thường hàng trăm nghìn hay hàng triệu dòng mã.
2. Nhiều ngôn ngữ lập trình, Pascal và C KHÔNG được dùng nữa, bị thay thế bằng Java, C++, C # và Ajax;
3. Hệ thống hiện tại vẫn còn quan trọng và phải được bảo trì và liên tục được cập nhật. Hiếm khi bạn bắt đầu cái gì đó mới;
4. Phần lớn các công ti có hàng trăm công cụ phần mềm và dùng nhiều sản phẩm thương mại làm sẵn COTS.
5. Phần lớn nỗ lực phát triển đều được thực hiện bởi các tổ lớn, không ai làm việc một mình.
6. Có nhiều bù trừ chi phí hiệu năng trong hoàn cảnh kinh doanh. Một chương trình “làm việc” có thể không đủ tốt.
7. Mọi phát triển phải tuân theo các qui trình và chuẩn được xác định rõ.

Rõ ràng, hai cách tiếp cận này KHÔNG ngang hàng với nhau, đó là lí do tại sao nhiều sinh viên khoa học máy tính chịu thua thiệt trong công nghiệp phần mềm và phải được đào tạo lại trước khi họ có thể có năng suất.

Một vấn đề chính khác là việc nhận diện tri thức và kĩ năng. Tri thức nói tới điều sinh viên “biết” nhưng kĩ năng chỉ ra những điều sinh viên phải có khả năng “làm.” Hơn nữa kĩ năng có thể được xác địng bằng “chiều sâu” (Quen thuộc, Thực hành và Làm chủ) dựa trên kinh nghiệm và chiều dài của thực hành. Không may, phần lớn các giáo sư đại học chưa bao giờ làm việc trong công nghiệp phần mềm hay chưa từng được đưa vào những thực hành này cho nên họ chỉ tập trung vào dạy lí thuyết mà không thực hành, vì vậy sinh viên không bao giờ có cơ hội để phát triển tri thức chiều sâu về một số chủ đề.

Ngày nay, phần lớn các đại học hàng đầu trên thế giới đang thay thế các bài tập truyền thống bằng “kịch bản tái tạo” nơi sinh viên phải áp dụng điều họ học vào giải quyết “vấn đề thực.” Với cách tiếp cận này, sinh viên có thể phát triển các kĩ năng của họ bằng việc áp dụng tri thức họ học trong lớp và nhận được phản hồi từ các giáo sư. Đây là lí do chính tại sao phần lớn các chương trình kĩ nghệ phần mềm đều hội tụ vào “qui trình” hay dãy các hoạt động mà kĩ nghệ phần mềm phải tuân theo thay vì học các lí thuyết trừu tượng. Theo phương pháp bài giảng truyền thống, qui trình phần mềm là khó dạy bởi vì chừng nào giáo sư còn chưa có kinh nghiệm công nghiệp thực tế, sẽ khó giải thích khái niệm về qui trình cho sinh viên, người đơn giản ngồi và nghe hướng dẫn. Học “qui trình” họ phải “làm nó.”  (Phương pháp học qua hành).

Chẳng hạn, theo cách tiếp cận kịch bản tái tạo, có nhiều biến cố xảy ra đồng thời; cho nên sinh viên phải thường xuyên ngắt hoạt động của mình để làm việc trên các hoạt động khác như trong dự án thực. Họ học cách ưu tiên hoá công việc của mình bởi vì làm theo cùng cách mọi lúc sẽ không dẫn tới cùng kết quả. Theo cách tiếp cận kịch bản, có vài nhân tố ngẫu nhiên như yêu cầu thay đổi, thành viên tổ thay đổi, khách hàng thay đổi và lịch biểu thay đổi cũng giống như trong dự án thực cho nên sinh viên học rằng có những mục đích xung đột mà đôi khi can nhiễu lẫn nhau mà họ phải giải quyết. Hành động của sinh viên để nhận diện những mục đích nào đó là quan trọng hơn các mục đích khác, và một số mục đích có thể được đạt tới khi các mục đích khác có thể bị trì hoãn hay được thực hiện một phần. Sinh viên sẽ học rằng với mọi dự án, có nhiều người dùng và khách hàng mà từng người đều cố thoả mãn nhu cầu riêng của họ cho nên sinh viên học cách thương lượng và thoả hiệp cũng như họ sẽ thực hiện trong dự án thực.

Tôi tin cách tiếp cận mới này là cao cấp hơn nhiều so với cách tiếp cận truyền thống, đặc biệt trong việc dạy kĩ nghệ phần mềm hay các lĩnh vực công nghệ khác.

—-English version—-

Learning Software Engineering

There is a difference between the computer skills taught at university and the skills that are needed by the software industry. The difference seems to be the way academic view of how computer theories must be taught to students and the experiences of the professors. The academia view of teaching is focusing in a series of lectures about computing theories and practice using programming assignments. While this is a reasonable approach, such lectures and class assignments often lack an “in-depth knowledge” of what happened in real software projects. That is why many students who are very good in school have difficulty to apply their theories into practices when working in software industry. Following are some differences:

The academic approach emphasizes:

1. The construction of small programs, about few hundred lines of code.
2. The use of few programming languages such as Pascal or C.
3. Everything always “start new” for each assignment.
4. School rarely teaches the use of software tools or Commercial-off-the-shelves (COTS) products.
5. Programming in isolation or in small groups.
6. The belief that if a program “works”, it is good.
7. An informal development approach (Mostly coding) rather than rigorous that requires more skills.

Practicing software developer in industry must have to deal with:

1. Software systems that are large, often hundred thousands or millions lines of code.
2. Several programming languages, Pascal and C are NOT used anymore, to be replaced by Java, C++, C # and Ajax;
3. Existing systems remain important and have to be maintained and continuously updated. Rarely you start something new;
4. Most companies have hundreds of software tools and extensive use of Commercial-Off-The Shelves Products
5. Most development efforts that are undertaken by large teams, no one works alone.
6. There are many cost performance trade-offs in business contexts. A program that “Work” may not be good enough;
7. Every development must follow a well-defined processes and standards.

Clearly, these two approaches are NOT in line with each other, that is why so many computer science students suffered in the software industry and have to be retrained before they can be productive.

Another major issue is the identification of knowledge and skills. Knowledge refers to what student “know” but skills indicate things that students should be able to “do”. Furthermore the skills can be specified with a “depth” (Familiarity, Practice, and Mastery) based on experiences and length of practice. Unfortunately, most university professors never work in software industry or have been exposed to these practices so they only focus on teaching theories but not practices so students never have a chance to develop an in-depth knowledge of some subjects.

Today, most top universities in the world are replacing traditional assignments with “simulated scenarios” where students must apply what they learn in solving “real problems”. With this approach, students can develop their skills by applying the knowledge they learned in class and receive feedbacks from professors. This is the main reason why most software engineering programs is focusing on “the process” or the sequence of activities that software engineering must follow rather than learning abstract theories. In traditional lectures method, software process is difficult to teach because unless the professor have actual industry experiences, it would be difficult to explain the concept of process to students who are simply sitting and listening to the instructions. To learn “process” they must “do it”.  (The Learning by Doing method).

For example, in the simulated scenario approach, there are multiple events happen at the same time; so students must frequently interrupt their activities to work on others just like in real project. They learn how to prioritize their works because doing the same way every time will not lead to the same results. In scenario approach, there are several random factors such as requirements changes, team member change, customers change and schedules change just like in real project so student learn that there are conflicting goals that sometimes interfere with each other that they must solve. Students’ actions are to identify certain goals as more important than others, and some goals that can be attained when others can be postponed or partially fulfilled. Students will learn that for every project, there are multiple users and customers that each try to satisfy their own needs so they learn how to negotiate and compromise just as they will do in real projects.

I believe this new approach is far superior than the traditional approach, especially in teaching software engineering or other technology fields.