|
Xin chào
Guest
| Đăng ký
| Đăng nhập
|
|
|
| Trang chủ | Những mạch mới | Mạch chưa trả lời | Người dùng trực tuyến | Thành viên | Giúp đỡ |
Diễn đàn SEGVN
Software Engineering - Information System Management
Software Engineering
Mạch: Software engineering and computer science - two worlds
|
| Không có thành viên nào đang xem mạch |
|
Trạng thái mạch: Bình thường Tổng số bài viết trong mạch này: 2 |
|
| Tác giả |
|
Trung
Member Tham gia: 09-01-2009 Tổng số bài đã viết: 11 Trạng thái: Offline |
Hi everyone, This article gives a very good view on SE vs CS and also talk about IS so that we can have a clearer view. http://www.cs.auckland.ac.nz/~ewan/download/SE_essay20081219.pdf The purpose of SE is to build the good software while CS is about computation. IS is further attached to current business needs. This explains why CMU SE/IS practical program that SEGVN is running is on the right track to build better software engineers. Cheers Trung Nguyen |
||
|
|
ntviet
Guru Việt Nam Tham gia: 25-12-2008 Tổng số bài đã viết: 91 Trạng thái: Offline |
Bản dịch Suy nghĩ về Kĩ nghệ phần mềm là gì Ewan Tempero 19/12/2008 Giới thiệu Bài viết này trình bày các suy nghĩ đa dạng tôi thấy có liên quan tới bản chất của kĩ nghệ phần mềm, dựa trên kinh nghiệm của tôi khi dạy chương trình đại học về kĩ nghệ phần mềm và nghiên cứu trong miền này. Câu hỏi Điểm bắt đầu cho bài viết này là câu hỏi sau: Có khác biệt giữa khoa học máy tính và kĩ nghệ phần mềm không và nếu có thì nó là gì? Đây là câu hỏi tôi đã đi tới câu trả lời tốt, từ năm 2002, hồi tôi ở Đại học Auckland (UoA), nơi cho phép theo chuyên ngành cả trong khoa học máy tính (CS), đại học về khoa học (BSc), và chuyên môn trong Kĩ nghệ phần mềm (SE), đại học về kĩ nghệ (BE). Tôi ở khoa về Khoa học máy tính, nhưng vì hầu hết việc giảng dạy của tôi là ở chương trình SE nên tôi đã phải trả lời cho câu hỏi này cả từ góc độ sinh viên tiềm năng và góc độ người sử dụng lao động tiềm năng. Gần đây hơn, khi tôi chuẩn bị nghỉ để đi làm Nghiên cứu và Học tập (còn gọi tương đương là “nghỉ phép”), tôi bắt gặp thảo luận về câu hỏi này ở Bài ghi chép về kĩ nghệ phần mềm (SEN) nêu ra các quan điểm đối lập về chủ đề này. Điều thú vị về thảo luận này là, tôi đã thấy nó khi nó được xuất bản năm 2003 tôi đã đồng ý với một phe, nhưng bây giờ tôi kiên định theo phe bên kia. Từ khi đọc thảo luận này, và có nhiều thời gian nghỉ để suy nghĩ về những điều như vậy, tôi đã nghĩ về tại sao quan điểm của tôi đã thay đổi, cái dẫn tới bài viết bạn đang đọc trước mắt. Ngữ cảnh lịch sử và động cơ Đầu năm 2002, bằng về SE tại UoA là rất mới - những người đầu tiên đã bắt đầu năm học thứ ba (trong bốn năm) của họ. Mới thế, nên không mấy ai biết nhiều về nó. Các sinh viên mới tiềm năng (và cha mẹ họ) muốn biết liệu có việc làm cho sinh viên tốt nghiệp SE không, và tại sao họ phải học SE thay vì CS, môn học đã tiến hành trong nhiều năm rồi. Công nghiệp muốn biết sự khác biệt là gì, để quyết định liệu có muốn thuê sinh viên tốt nghiệp SE không thay vì thuê (hay thậm chí vẫn thuê) sinh viên CS. “Chả khác biệt gì” không chỉ là câu trả lời hữu dụng về chính trị (phải có khác biệt chứ không tại sao UoA lại đưa ra cả hai môn!), mà còn rõ ràng không hoàn toàn đúng. Trong khi số môn học trong chương trình SE bắt đầu tồn tại như việc nhái theo các môn tương ứng của CS, phần lớn trong chúng đi trệch sang các môn khác. Cũng có các môn SE khác không có tương đương trong CS, cộng thêm tất cả các môn kĩ nghệ khác tạo nên BE. Cho nên các chương trình này là khác nhau, nhưng điều đó có thể được coi như sự phân biệt nhân tạo bằng cách nào đó. Nhiều mối quan tâm hơn là liệu có sự khác biệt thực giữa hai môn này không. Câu hỏi này không mới. Đã có nhiều thảo luận ở các cuộc gặp gỡ đa dạng, kể cả trong các phòng trà nhân viên, về sự khác biệt là gì. Thảo luận SEN tôi đã nhắc tới ở trên xuất hiện trong vấn đề tháng 11/2003 và bao gồm cả bức thư của Bill Griswold và trả lời của Peter Henderson [3]. Tôi bắt gặp vấn đề này và tôi dọn sạch văn phòng mình để chuẩn bị cho việc đi nghỉ. Bằng cách nào đó tôi quên khuấy mất không đọc nó vào lúc nó mới ra, cho nên tôi ngấu nghiến đọc nó ngay (SEN là một trong vài tờ tạp chí tôi nhận được mà tôi cố gắng đọc). Trong bức thư của mình (lời đáp cho đề nghị về giáo trình SE), Griswold bầy tỏ quan điểm là CS là kĩ nghệ, dựa trên quan sát rằng nhiều điều được liên kết với CS có chứa kết cấu của các vật phẩm. Ông ấy cảm thấy rằng SE là bộ môn con của CS, và hỏi liệu việc tạo ra phân biệt có lợi gì cho việc phát triển các lĩnh vực tương ứng không, trong nghiên cứu và giảng dạy. Henderson (người vào thời đó đã viết bài báo cho SEN về giáo dục kĩ nghệ phần mềm) đã cảm thấy rằng quả có khác biệt giữa CS và SE như có khác biệt giữa khoa học và kĩ nghệ. Ông ấy cảm thấy rằng nhiều sinh viên tốt nghiệp chương trình CS không có "tâm tính kĩ nghệ”. Vào cuối năm 2003 (tức là, sau năm thứ hai của tôi dạy chương trình SE ở UoA), tôi có lẽ đã đồng ý với Griswold. Tôi gần như chắc chắn đã đồng ý ngay cả vài tháng trước đây. Bổ nhiệm trước đây của tôi trong 11 năm là ở khoa Khoa học máy tính tại đại học Victoria ở Wellington (VUW), nơi cung cấp chương trình CS khá truyền thống. Học vấn riêng của tôi mang tính năng các môn khoa học máy tính khá truyền thống, tuy nhiên môn học đại học chính của tôi là toán học và luận án tiến sĩ của tôi là về khoa học máy tính lí thuyết. Vào lúc tôi rời khỏi VUW nghiên cứu và giảng dạy của tôi đều vững chắc trong "kĩ nghệ phần mềm" nhưng tôi coi nó là bộ môn con của CS thay vì là cái gì đó tách biệt. Tại UoA, trong khi tôi ở khoa về Khoa học (FoS), vì phần lớn việc giảng dạy của tôi là trong chương trình SE, tôi có liên hệ nhiều hơn với Khoa Kĩ nghệ (FoE), nơi quản trị chương trình SE. Cấu trúc của chuyên môn SE bị ảnh hưởng mạnh bởi cấu trúc của BE, được quản trị bởi FoE, điều đã tồn tại trong gần 100 năm (vào thời đó). Đã có các môn “phát triển chuyên nghiệp” ở mọi mức cho mọi chuyên môn, và “mô hình hoá toán học” (mang tính năng nhiều tính toán) cho hầu hết các chuyên môn. Người thiết kế về chuyên môn SE đã gần như làm việc toàn bộ trong khoa Khoa học máy tính (FoS) và đã biện luận thành công rằng sinh viên SE không cần tất cả các môn toán học liên tục, và rằng nhiều môn thích hợp hơn sẽ thay thế cho các môn đó mà sinh viên kĩ nghệ cần học (toán học rời rạc và vân vân). Tuy nhiên không có việc né tránh các môn phát triển chuyên nghiệp, vì chúng là một phần của các môn được công nhận về kĩ nghệ, và không có né tránh năm chung đầu tiên mà tất cả sinh viên đều phải học. Năm thứ nhất mang tính chất gần như không có gì liên quan tới phần mềm (trừ nửa môn về lập trình trong MATLAB được tính tới). May mắn cho chương trình SE, có một chỗ "chọn lựa" ở năm đầu, và sinh viên SE được yêu cầu học nhập môn Khoa học máy tính vào lập trình trong chỗ đó . Tôi thấy hạn chế của chương trình BE bị áp đặt bởi cấu trúc BE chỉ không ích lợi chút ít. Tôi không thấy nhu cầu cho sinh viên SE học môn hoá học trong năm đầu tiên. Tôi không nói rằng hoá học (và tôi lấy hoá học chỉ bởi vì tôi không muốn liệt kê tất cả các môn) là không hữu dụng, hay rằng sinh viên SE sẽ có ích với việc học nó, nhưng bốn năm là gần như không đủ như nó vậy và chỗ để học hoá học có thể được dùng cho môn có chứa nhiều tài liệu liên quan trực tiếp hơn với sinh viên SE. Đường lối mà các nhân viên kĩ nghệ theo là họ muốn tất cả sinh viên đều có cùng nền tảng để cho sinh viên chọn được chuyên môn trên cơ sở được thông tin đầy đủ, và rằng những môn này tất cả đều được các kĩ sư dạy nên nó sẽ có ích cho sinh viên thu nhận “tâm tính kĩ nghệ”. Tôi đã không hiểu điều đó. Vào lúc đó tôi đã không thấy rằng bất kì tâm tính cơ giới hay hoá học nào mà người kĩ sư đã phát triển lại sẽ có giá trị gì cho sinh viên SE. Đến cuối năm 2003, nhóm đầu tiên hoàn thành chương trình. Điều này bao gồm một môn dự án “capstone” nơi sinh viên làm việc trong tổ của hai dự án được các cán bộ tài trợ (hầu hết). Môn này đã được “gắn thêm” với cuộc hội nghị 2 ngày nơi tất cả tổ dự án trình bày lại dự án và rồi tuần sau đó có cuộc triển lãm cả ngày mở cho công chúng là sinh viên xem. Đây là khi tôi tới xem, lần đầu tiên, một "sinh viên kĩ nghệ hoàn thành” (tôi cẩn thận không nói sinh viên là “kĩ sư hoàn thành”!) Tôi dứt khoát thấy cái gì đó trong toán sinh viên này mà tôi chưa từng thấy trong sinh viên tốt nghiệp khoa học máy tính. Khó mà nói ra. Vẫn có khía cạnh về “chúng tôi đã làm chất liệu hay và chúng tôi dùng công nghệ hay" nhưng cũng có chỉ báo rõ ràng về “chúng tôi đã chú ý tới điều khách hàng muốn" và "chúng tôi đã chú ý tới thực hành công nghiệp là gì.” Tôi tin điều này là dấu hiệu của "tâm tính kĩ nghệ" mà mọi người đều đã nói tới. Đây là điểm mà tôi bắt đầu trở nên ít nghiêng về việc gạt bỏ cách thức "kĩ nghệ" làm mọi sự, và bắt đầu chú ý nhiều hơn tới cách họ làm các thứ. Dầu vậy tôi vẫn ưa chuộng việc chương trình SE có hơi khác chút ít, nhưng bây giờ là một kĩ sư là đủ hiểu đó là thực tại tôi phải giải quyết. Vì tôi không biết đích xác điều gì dẫn tới tâm tính kĩ nghệ, tôi ít nghiêng về vứt bỏ các môn học chỉ bởi vì tôi không thấy chúng hữu dụng, vì có thể là những môn đó cung cấp nền tảng cần thiết (tức là, có thể người kĩ sư "truyền thống" là đúng sau rốt!) Bây giờ tôi cũng hiểu rằng có thể có giá trị nào đó để phân biệt giữa khoa học máy tính và kĩ nghệ phần mềm. Phân biệt về nguyên tắc Tất nhiên gắn nhãn cho mọi thứ có cái nguy hiểm của nó. Mọi người có xu hướng đánh giá dựa trên cơ sở cái mác thay vì điều thực, và mác thường quá đơn giản không làm được điều đúng. Mọi người dùng mác như cờ để tập hợp quanh, để tạo ra "chúng ta" và "họ", khi nghĩa khác của việc giải quyết vấn đề có thể có ích hơn. Nhưng chúng ta dùng mác để giải quyết vấn đề, và đó là kiểu giải pháp chúng ta dùng để giải nhiều vấn đề - chia để trị. Chúng ta thấy chúng ta có thể lập luận tốt hơn về mọi điều nếu chúng ta có thể cô lập các điều chúng ta chú ý tới. Nếu cái mác cung cấp sự phân biệt hữu dụng, thì chúng ta có thể có khả năng ra quyết định nhiều thông tin hơn. Chẳng hạn, với phân biệt rõ ràng giữa SE và CS, các khoa có thể, thay vì tranh cãi liệu họ nên dạy SE hay CS, họ có thể quyết định liệu họ muốn là khoa khoa học máy tính với sự tập trung lớn vào SE” hay “khoa kĩ nghệ phần mềm” hay chấp nhận rằng họ thực sự làm cả hai, hay bất kì cái gì. Thay vì tranh cãi rằng chủ đề nào đó là “rõ ràng quan trọng” và do đó “phải được dạy”, chúng ta có thể xem xét liệu chủ đề đó có liên quan nhiều tới CS hay SE không và đưa chúng vào (hay không đưa vào) dựa trên cơ sở là môn học này được dự định dành cho chương trình CS hay SE, thay vì cố gắng bảo vệ tiêu chí "rõ ràng quan trọng" mù mờ này. Vậy nên, nếu chúng ta định phân biệt giữa Khoa học máy tính và Kĩ nghệ phần mềm, thì nó phải là gì? ĐIểm bắt đầu có lí là xem xét sự khác biệt giữa Khoa học và Kĩ nghệ. Có nhiều bài học rút ra về điều này nhưng thay vì hâm lại chúng ở đây tôi sẽ bám lấy cái gì đó đơn giản: Người khoa học cố gắng hiểu thực tại. Người kĩ sư cố gắng giải quyết nó. Giống như mọi khẩu hiệu điều đó trình bày một cái nhìn đơn giản hoá về cái gì thực tế đang là hoàn cảnh, nhưng giống như mọi khẩu hiệu nó có yếu tố của chân lí về nó. Nó thâu tóm một nguyên lí có thể được dùng để quyết định khi nào cái gì có thể được coi là “khoa học” và khi nào nó có thể được coi là “kĩ nghệ.” Sự phân biệt là ở chỗ ý định chính của người khoa học là hiểu cách thế giới vận hành, trong khi ý định của người kĩ sư là xây dựng mọi thứ phải làm việc trong thế giới. Có nhiều điều mà người khoa học “biết” (theo nghĩa người khoa học có thể nói để biết bất kì cái gì) là đúng, nhưng việc biết những điều này không tác động vào cuộc sống thường ngày. Nhưng thế rồi người kĩ sư nào đó sẽ nhận ra rằng điều đó có thể được khai thác để cung cấp dịch vụ hay sản phẩm nào đó mà nếu không có nó thì không thể làm được, hay cung cấp dịch vụ và sản phẩm đã có một cách hiệu quả hơn. Trong nhiều thảo luận tôi đã thấy Kĩ nghệ là gì, đã có nhấn mạnh vào việc xây dựng cái gì đó. Tuy nhiên tôi không thấy rằng cần định nghĩa tính năng của Kĩ nghệ, đặc biệt theo nghĩa xây dựng cái gì đó thì nó không phải là khoa học. Nhiều việc xây dựng vẫn đi vào khoa học. Hai ví dụ là kính viễn vọng Hubble và Large Hadron Collider. Không có vấn đề là những thiết bị này có chứa kĩ nghệ nghiêm chỉnh nào đó, nhưng toàn bộ mục đích của chúng là để hỗ trợ cho khoa học nền tảng. Chỉ bởi vì cái gì đó được xây dựng, không có nghĩa khoa học không xuất hiện; vấn đề là việc xây dựng phục vụ cho mục đích gì. Một mục đích có thể của xây dựng là xác định mức độ hiểu biết nào mà khoa học đã đạt tới. Một cách kiểm thử một lí thuyết là nhìn vào vật phẩm nào nó dự đoán có thể được xây dựng, và cố gắng xây dựng chúng. Người khoa học thường gọi loại hoạt động này là "thực nghiệm," nhưng điều đó không làm thay đổi sự kiện là cái gì đó được xây dựng. Một ví dụ ở đây là con cừu Dolly, đại diện cho việc chứng minh mức độ hiểu biết về việc làm nhái (trong số những điều khác!) nhưng rõ ràng có bao gồm việc xây dựng ra vật phẩm (và cũng không phải là nhỏ trong công nghệ sinh học). Tôi chấp nhận rằng các cách diễn giải khác về những ví dụ này đã tồn tại, nhưng tôi sẽ biện minh rằng cách diễn giải của tôi không phải là không nhất quán với điều xảy ra, và do đó nó hỗ trợ cho luận đề của tôi rằng không phải việc xây dựng có xảy ra hay không mới xác định ra kĩ nghệ, mà vấn đề là mục đích của việc xây dựng đó là gì. Nếu nó giúp cho việc hiểu thực tại, nó dành cho khoa học; nếu nó làm nảy sinh vật phẩm được dự định cung cấp giá trị cho ai đó, nó là kĩ nghệ. Tất nhiên chúng ta có thể dùng các biện luận này cho đủ mọi loại cực đoan. Chẳng hạn, nếu tôi xây dựng cái gì đó mà người khoa học sẽ dùng cho một thực nghiệm, tức là, đó là một vật phẩm sẽ cung cấp giá trị cho người khoa học, đó có phải là kĩ nghệ không? Có chứ! Không có vấn đề gì. Large Hadron Collider và các ví dụ khác của tôi là những kì công của kĩ nghệ. Luận điểm của tôi là ở chỗ sự kiện xây dựng như vậy xảy ra không có nghĩa không có khoa học xảy ra - luận điểm tôi sẽ trở lại sau. Một luận điểm khác là ở chỗ, theo định nghĩa của tôi, những người làm nghiên cứu trong kĩ nghệ thực sự là các nhà khoa học, và điều đó là đúng. Người nghiên cứu kĩ nghệ hoạt động theo cùng các qui tắc như người khoa học đối với việc thu thập và cung cấp bằng chứng để hỗ trợ cho hiểu biết được công bố của họ về thực tại. Các loại bằng chứng họ thu thập rất có thể bao gồm việc xây dựng (“Tôi chứng minh tính hợp thức của ý tưởng của tôi về truyền năng lượng cảm ứng bằng việc xây dựng một thiết bị được tạo năng lượng bởi nó”), và các vấn đề họ xem xét sẽ rất có thể tới từ các vấn đề mà người kĩ sư thực hành đang đối diện (“Khoa học cho chúng ta biết rằng chúng ta phải có khả năng truyền điện qua không trung. Chúng ta hãy xem liệu chúng ta có thể làm điều đó thành thực hành cho việc sử dụng hàng ngày không.”) nhưng dầu vậy họ là những người khoa học (và nhiều nhất là kĩ sư nữa). Sự phân biệt này giữa hiểu thực tại so với giải quyết nó là có ích để ra quyết định. Một sinh viên tiềm năng thích thám hiểm các ý tưởng và hiểu cách mọi sự làm việc có thể lấy bằng khoa học tốt hơn, trong khi người thích xây dựng các thứ và tạo ra sản phẩm cuối cùng có thể làm kĩ nghệ tốt hơn. Trong việc quyết định đưa ra môn học nào (hay thay vì thế, môn học nào không nên đưa ra vì chẳng bao giờ có đủ thời gian để dạy mọi thứ có thể có ích trong bất kì chương trình bằng cấp nào), và khoa kĩ nghệ sẽ nghiêng nhiều hơn vào việc giữ các môn hội tụ vào thực tại thực hành làm cho mọi sự làm việc với trả giá là bỏ các môn "lí thuyết' (ngần ngại và than vãn cùng nghiến răng của một số cán bộ). Tách khoa học máy tính và kĩ nghệ phần mềm Nguyên tắc tôi mô tả trên đây là rất tốt cho việc phân biệt Khoa học và Kĩ nghệ, nhưng nó lại không giúp gì nhiều cho việc phân biệt khoa học máy tính và kĩ nghệ phần mềm (hay hoá học và kĩ nghệ hoá học cho chủ đề đó). Tôi cần nhận diện phần thực tại có liên quan; tôi dùng "tính toán." Cho nên, việc làm mịn thêm phát biểu trước đây của tôi sẽ cho: Người khoa học máy tính cố gắng hiểu tính toán, người kĩ sư phần mềm cố gắng cung cấp tính toán dưới dạng hữu dụng. Với tôi, CS là về hiểu bản chất của tính toán ở mọi mức, dù đó là hiểu tính toán được ngụ ý gì, xác định cách tính toán có thể được dùng, ít nhất là bắt chước, nếu không sao chép, thông minh của con người, tìm ra thuật toán tốt nhất để hỗ trợ cho các mạng không thể thức cho tính toán phổ cập, hay cách tổ chức dữ liệu để hỗ trợ cho giải pháp nhanh cho các truy vấn phức tạp. SE, mặt khác, là về áp dụng điều người khoa học máy tính đã biết để xây dựng sản phẩm thực hiện tính toán có giá trị cho mọi người. Có các khía cạnh của việc xây dựng mà thực sự không liên quan mấy tới tính toán nhưng dầu vậy không thể né tránh được khi xây dựng phần mềm. Chẳng hạn, kiểm soát phiên bản là cái gì đó mà việc xây dựng sản phẩm phần mềm đó cần biết tới nhưng có thể không thực sự được xem là vấn đề có liên quan tới bản chất của tính toán (mặc dầu tôi chắc có một số vấn đề toán học thú vị tiềm năng có áp dụng cho kiểm soát phiên bản). Có thể là đường phân ranh còn mờ mịt giữa CS và SE hơn các lĩnh vực khác (như, hoá học so với kĩ nghệ hoá học, tuy nhiên điều gây cho tôi ngạc nhiên là người trong các lĩnh vực này đã cãi nhau một cách khác biệt). Điều thông thường đối với ai đó là bắt đầu bằng câu đố tính toán (như, thuật toán nào dùng để hỗ trợ cho việc tìm kiếm một tập dữ liệu phân bố rất lớn không được tổ chức) và rằng cùng ai đó chế tạo ra một giải pháp đem lại cho họ và nhiều người khác số tiền lớn. Cái phần làm ra tiền này yêu cầu rất nhiều kĩ nghệ phức tạp, và tôi hoài nghi là Sergey và Larry sẽ nói khác, và tôi cũng ngờ rằng họ sẽ không tranh cãi với việc diễn giải nói rằng Google đại diện cho việc chứng minh thực nghiệm thành công (và còn đang tiếp diễn) về mức độ hiểu biết của họ với thuật toán tìm kiếm. Vậy làm sao làm phân biệt này trở thành hữu dụng? Nó có thể giúp xác định nội dung của môn học. Chẳng hạn, môn Cấu trúc dữ liệu dành cho bằng cấp CS sẽ chứa hợp lí nhiều chi tiết hơn về cách thực hiện phân tích tiệm cận thuật toán và đưa vào, chẳng hạn, các thảo luận chi tiết về các loại thuật toán sắp xếp khác nhau. Phiên bản SE sẽ tập trung hợp lí hơn vào các vấn đề thực tiễn bao quanh việc chọn lựa thuật toán và cấu trúc dữ liệu thay vì các chi tiết về bản thân thuật toán, cho nên cách thức thuật toán sắp xếp gộp làm việc là kém quan trọng hơn trong hoàn cảnh nào cần chọn sắp xếp nhanh là tốt hơn. Việc phân bổ hợp lí phiên bản CS về môn thuật toán có thể chứng minh tính đúng đắn của thuật toán Dijkstra, trong khi với phiên bản SE có thể yêu cầu thực hiện công việc đó bằng đồ thị với hơn 10,000 đỉnh. Và tôi phải nhấn mạnh, điều này không nói rằng sinh viên CS sẽ được lợi từ việc thực hiện thuật toán Dijstra và một sinh viên SE sẽ không được lợi từ việc làm chứng minh đó, nhưng với ngân sách-thời gian giới hạn không cho phép làm cả hai. Sự phân biệt tôi đưa ra cung cấp tiêu chí để dựa trên đó ra quyết định. Một loại luận cứ tương tự có thể được dùng khi quyết định dạy môn nào. Ít có khả năng là một môn về kiến trúc phần mềm sẽ xuất hiện trong chương trình CS hơn là trong chương trình SE, bởi vì kiến trúc phần mềm không nói gì nhiều về cách tính toán làm việc vì nó nói về cách tổ chức các điều khoản tính toán. Tức là, môn kiến trúc phần mềm chủ yếu bao quát khía cạnh hình thức của ngôn ngữ mô tả kiến trúc, hay mô hình hoá các khía cạnh của kiến trúc dẫn theo mô hình sẽ không ở ngoài vị trí trong (theo cách nhìn của tôi) chương trình CS. Nếu ai đó thực sự muốn dạy môn kiến trúc phần mềm mà hội tụ vào phát triển kiến trúc (như, theo mạch của Bass và cộng sự [1] trong chương trình CS, thì, theo quan điểm của tôi, đó là môn SE trong chương trình CS. Điều này cũng không tệ, nó đúng là cái nó đang là, và tốt hơn cả là thừa nhận điều đó còn hơn đưa ra định nghĩa của CS để cho phép nó được xem xét như môn CS, hay đưa ra luận cứ giải thích tại sao môn như vậy lại thực sự về việc hiểu tính toán (tôi có thể hình dung luận cứ như thế giống cái gì nhưng không thấy tại sao nêu những luận cứ đó lại có ích.) Để cho một ví dụ khác, không có gì cố hữu trong nọi dung của môn mạng chuẩn (như được dạy từ Tanenbaum [2]) mà trực tiếp hỗ trợ cho việc phát triển phần mềm. Việc học giao thức cửa sổ trượt sẽ chẳng có ích gì nhiều trong việc hình dung ra cách xây dựng hệ thống cung cấp phần mềm điều khiển cho thiết bị điều trị ngưng thở khi ngủ, và cũng chẳng giúp việc hiểu các nguyên lí của lan truyền sóng khi áp dụng vào mạng không dây. Tất nhiên biết thủ tục như vậy tồn tại, hay biết rằng có vấn đề liên quan tới việc truyền sóng phải được xét tới khi thiết lập hệ thống dùng truyền thông không dây, có thể giúp cho kĩ nghệ phần mềm tạo ra hệ thống tốt hơn, nhưng với thời gian-ngân sách giới hạn, nếu cái gì đó phải ra đi thì những chủ đề này sẽ là đầu tiên trong danh sách của tôi. Và tôi hi vọng rằng bất kì người học Kĩ nghệ phần mềm nào cũng là một Kĩ sư tốt, và do vậy biết đem vào tri thức chuyên gia có liên quan để bao phủ lỗ hổng trong tri thức của mình. Mặt khác, với mức độ mà phần mềm ngày nay dùng Internet theo cách nào đó, môn "mạng" tập trung nhiều vào đỉnh chồng giao thức mạng, và thảo luận việc chọn đường mạng từ quan điểm an ninh mạng, sẽ tạo ra ý nghĩa tốt cho chương trình SE. Tất nhiên có những sức ép khác ảnh hưởng tới nội dung môn học; chẳng hạn nếu mỗi một cán bộ dạy môn mạng thấy thoải mái ở đầu đáy của chồng giao thức thì tốt hơn cả cứ để họ dính lấy tri thức của mình. Tâm tính kĩ nghệ? Henderson tuyên bố rằng nhiều sinh viên tốt nghiệp CS đã không có tâm tính kĩ nghệ này. Bị thuyết phục có thể có cái gì đó cho điều này, và có ý tưởng tốt hơn về phải tìm cái gì, tôi bây giờ nghiêng về đồng ý với ông ấy. Tôi đã thấy các giải pháp do sinh viên tốt nghiệp CS tạo ra chỉ họ mới có thể dùng được, vì nó yêu cầu những hành động xoắn xuýt về phần người dùng để làm cho giải pháp chạy. Trong khi điều đó không còn đúng mấy bây giờ so với nó đã từng thế trong quá khứ, nó vẫn là trường hợp mà các sinh viên tốt nghiệp CS dường như không hiểu rằng chỉ bởi vì họ làm cho giải pháp của mình chạy, điều đó không có nghĩa nó hữu dụng cho khách hàng của họ, và họ sẽ cung cấp những biện minh thú vị về tại sao giải pháp của họ lại làm việc như nó đang làm việc. Điều này thậm chí còn đúng hơn khi nhìn vào tổ chức phần mềm. Sinh viên tốt nghiệp CS dường như nghĩ rằng theo một tập các qui tắc là tạo ra kết quả phần mềm tốt (“Nhưng tôi làm tất cả các trường thành tư cho nên thiết kế của tôi là tốt!”) mà không nghĩ về hậu quả của quyết định của họ dưới dạng tác động tới "người dùng" tương lai (như người kiểm thử hay bảo trì). SE có thể không cần tạo ra thiết kế tốt hơn, nhưng họ dường như có hiểu biết thực tế hơn về chúng tốt thế nào (“Vâng chúng tôi đã làm trường đó là công bởi vì chúng tôi đang vội đáp ứng hạn chót.” đi kèm với lui chân và cái nhìn xấu hổ). Bây giờ quan sát của tôi dựa trên mẫu khá nhỏ cho nên phải xem xét có hoài nghi nào đó! Tuy nhiên chúng là nhất quán với tâm tính kĩ nghệ này và ít nhất một người khác (Henderson) dường như cùng nghĩ vậy, tôi là người tin nhiều hơn. Tôi chắc chắn ít nghiêng về tái cấu trúc bằng cấp BE của chúng tôi mà không có những bằng chứng đáng xem xét rằng làm như vậy sẽ không phá huỷ bất kì cái gì đang có, cái đang tạo ra tâm tính kĩ nghệ. Tất nhiên không phải bị cắt bỏ và làm khô héo điều chương trình này làm và chương trình kia không tạo ra tâm tính đó, nhưng ít nhất tại UoA chương trình này cố gắng trong khi chương trình kia không cố gắng (và làm điều đó cũng không thích hợp). Bởi vì tôi đã thay đổi tâm tính, tôi thấy điều đó nhiều hơn. Và tôi phải nhắc lại để nhấn mạnh, tôi không nói rằng chương trình “khoa học máy tính” không thể tạo ra sinh viên tốt nghiệp với tâm tính kĩ nghệ này, điều tôi nói là ở chỗ đây thực sự chỉ là chương trình SE dưới cái tên khác. Tôi sẽ đi xa hơn và nói rằng việc gọi chương trình như vậy là “CS” là chẳng làm lợi cho ai cả. Chúng ta đi tới đây thế nào? Cũng đáng để một chút thời gian để cố hiểu tại sao một thảo luận như thế nào lại là cần thiết. Tôi không đi vòng khi (chẳng hạn) Kĩ nghệ hoá học đã phát triển như một lĩnh vực tách biệt, và sẽ không có gì làm cho tôi ngạc nhiên nếu loại thảo luận tương tự xảy ra, nhưng tốc độ của việc phát triển của cả CS và SE có lẽ đã giữ một phần. Trong khi nghiên cứu và giảng dạy về hoá học đã có thời gian rất lâu, việc dùng hoá chất trên qui mô lớn trong môi trường công nghiệp hay mọi ngày là mới gần đây. Trong khi nghiên cứu về tính toán đã có từ trước khi máy tính hữu dụng tồn tại, tổ chức của nó như một lĩnh vực, và đặc biệt việc giảng dạy của nó thực sự chỉ phát triển cùng với (hay thậm chí đi theo) nhu cầu về giảng dạy cách kết cấu phần mềm. Điều này đã có nghĩa là hiểu tính toán và cách làm cho nó hữu dụng chưa bao giờ thực sự được xem xét tách biệt. Xem như hậu quả, điều tôi đang gọi là SE thường là một phần của cùng khoa cung cấp điều tôi đang gọi là CS, và do vậy chẳng có gì ngạc nhiên là nhiều người ít thấy tách rời hai điều này, hay thấy rằng SE là một phần của CS. Tôi cũng phải đề cập tới một lĩnh vực khác, một lĩnh vực thường đi dưới cái tên Hệ thông tin (IS). Một thời gian trước đây người ta đã chỉ cho tôi (bởi ai đó trong khoa CS nhưng đã làm kĩ nghệ phần mềm) rằng khối lượng khá lớn công việc của SE thực tế được thực hiện trong IS, có lẽ (ít nhất là lần này) còn nhiều hơn trong khoa CS. Khoa CS có xu hướng có một trong ba hương vị — toán học (bởi vì những người thành lập ra khoa CS đều bắt nguồn từ nền tảng toán học), kĩ nghệ (bắt nguồn từ kĩ nghệ điện), hay doanh nghiệp (bắt nguồn từ trường doanh nghiệp). Trong một số trường hợp, sự tách biệt thực tế đã không xuất hiện (hay đã được hoàn tác), để cho chúng ta có các khoa Toán và Khoa học máy tính, Kĩ nghệ điện và Khoa học máy tính, Máy tính và hệ thông tin, và đại loại như vậy. Phỏng đoán của tôi là ở chỗ trong trường hợp khi sự tách rời đã xuất hiện theo hương vị doanh nghiệp, điều đã còn lại trong trường doanh nghiệp đã trở thành IS. Trong ba hương vị này của CS, có thể là chính hương vị doanh nghiệp đã được quan tâm nhiều về điều có thể được làm với kết quả, hơn là điều có thể, cho nên có lẽ không có gì ngạc nhiên là đã có nhiều quan tâm tới SE trong khoa IS. Tuy nhiên SE là một lĩnh vực đã phát triển nhiều hơn chỉ các ứng dụng doanh nghiệp và do vậy dường như đang trở thành một tính năng của CS hơn là nó có trong quá khứ. Ngẫu nhiên, tôi biết ít nhất một đại học trên thế giới có các khoa về khoa học máy tính và kĩ nghệ phần mềm tách rời (cả hai đều trong cùng một đại học, và với sự phân chia đại thể theo các tuyến tôi đang dùng, như tôi được biết), và một đại học với các khoa CS tách rời (Khoa về Khoa học) và khoa học thông tin (trong khoa thương mại), đều có sự phân chia tương tự. Nếu nó chưa hỏng, đừng sửa nó Như tôi đã lưu ý lúc ban đầu, tôi có lí do đặc biệt để nghĩ về sự khác biệt là gì giữa CS và SE, cho nên theo nghĩa đó có vấn đề. Tuy nhiên, có lẽ điều tôi đang đề nghị sẽ tạo ra nhiều vấn đề hơn nó giải quyết. Tôi đã lưu ý vấn đề về cái mác — bất kì ai dùng điều tôi viết ra ở đây để hỗ trợ cho chương trình nghị sự nào đó chỉ dựa trên cái mác “khoa học máy tính” và “kĩ sư phần mềm” mà không đưa ra triết lí nền tảng của tôi thì đều diễn tả sai luận điểm của tôi. Tôi chẳng thể làm gì được về những người như vậy cho nên tôi sẽ không thử. Nếu việc đi theo gợi ý của tôi dẫn tới những quyết định tồi, thì đó là vấn đề. Tuy nhiên tôi không thấy làm sao nó có thể dẫn tới những quyết định kém hơn tình huống hiện thời (tôi có thể bị thiên vị trong việc nghĩ điều này chứ!). Tình huống hiện thời là ở chỗ có những luận cứ về nội dung môn học phải là gì, môn nào nên có trong chương trình, và sinh viên tốt nghiệp nên có tập kĩ năng nào. Chẳng hạn, tôi đã thấy một số chương trình tuyên bố là thích hợp cho bất kì ai xem xét nghề nghiệp trong kĩ nghệ phần mềm. Cứ cho rằng họ cung cấp tất cả các tập kĩ năng hoàn toàn khác nhau đi thì dường như cũng khó mà tin được rằng họ có thể đúng tất cả, trừ phi "kĩ nghệ phần mềm" được diễn giải là "viết mã", bởi vì tính năng chung của các chương trình này là ở chỗ sinh viên tốt nghiệp của họ phải viết mã trong học tập của họ. Lấy một thí dụ khác, tôi đã thấy một số thảo luận về chủ đề nào nên được dạy trong một môn, với các luận cứ được trình bày rất hợp lí (và rất sôi nổi) nêu cả hai mặt của tranh luận. Không phải là các thành viên bao giờ cũng nhận biết rằng họ đang tranh cãi về diễn giải CS so với SE của môn học (mặc dầu đó đôi khi cũng là hoàn cảnh), mà là các diễn giải khác nhau đã được tuyên bố là tồn tại. Một ví dụ đặc biệt là phác hoạ chính xác tập kĩ năng của sinh viên tốt nghiệp. Người sử dụng lao động tiềm năng thường phàn nàn rằng họ không biết (hay ít nhất không hài lòng) với tập kĩ năng của những người họ đã thuê trong quá khứ. Ít nhất trong một số chương trình trên thế giới, sinh viên tốt nghiệp CS có thể biết nhiều về phát triển thuật toán, logic, toán học rời rạc, thiết kế mạng, cơ sở dữ liệu (lí thuyết, không thực hành), nhưng rất ít viết mã, và không xem xét về cái gì được cần để xác định hệ thống được giả định làm gì hay khách hàng quan tâm tới cái gì (hay thậm chí khách hàng có tồn tại không). Người sử dụng lao động mong đợi những sinh viên như vậy phải là các kĩ sư phần mềm mẫu đều bị thất vọng. Ngay cả sinh viên tốt nghiệp đã học các môn học đó mà về mặt truyền thống đã làm nhiều việc phát triển mã, như đồ hoạ, hệ điều hành, trí tuệ nhân tạo, vân vân, cũng đã không phải nghĩ về các vấn đề thực tế của việc sản xuất phần mềm mà ai đó khác sẽ dùng. Các môn họ học viết mã chả có liên quan gì tới các nguyên tắc đưa tới cách tạo ra phần mềm hiệu quả. Cho nên, trong khi các sinh viên như vậy có thể giỏi tạo ra mã làm điều họ muốn, họ không biết (hay thậm chí không quan tâm) cái gì được bao hàm trong việc tạo ra mã làm điều ai đó khác muốn. Có thể chính thái độ này mà phần lớn những người sử dụng lao động bực mình! Vấn đề này áp dụng cho các chương trình khác nữa. Tôi đã nghe một số người phàn nàn rằng chương trình của họ (không phải CS, SE, hay IS) tạo ra các sinh viên tốt nghiệp thích hợp cho vị trí SE. Những phàn nàn này có thể được đánh giá bằng cách xác định sinh viên đã được dạy tới có bằng cấp nào để cung cấp tính toán hữu dụng (như đối lập với việc chỉ viết mã là một phần bằng cấp của họ). Theo nguyên tắc tôi đang tán thành, bất kì chương trình nào tuyên bố cung cấp phẩm chất nào đó cho kĩ nghệ phần mềm đều phải chứa các môn mà các nguyên lí chính được dạy là về cách tạo ra phần mềm tốt một cách hiệu quả. Cái gì làm nên người kĩ sư Tôi đã cẩn thận không tuyên bố rằng sinh viên tốt nghiệp chương trình kĩ nghệ phần mềm là các kĩ sư. Điều này không đúng cho các chuyên môn khác. Bất kì ai muốn là một kĩ sư chuyên môn được xác nhận (hay bất kì danh xưng nào theo cách nói hợp pháp của bạn) đều phải không chỉ hoàn thành chương trình đại học được xác nhận bởi một cơ quan kĩ nghệ thích hợp, mà còn phải có một số kinh nghiệm kĩ nghệ thực tế. Các hãng kĩ nghệ đều biết họ không thuê “kĩ sư”, mà đơn thuần “sinh viên tốt nghiệp”, và việc của họ là biến sinh viên tốt nghiệp thành kĩ sư, và có các chương trình đa dạng chung bên trong công ti hoặc được cung cấp bởi các chuyên môn đặc thù để hỗ trợ cho điều này. Công nghiệp phần mềm gần như hoàn toàn không tính tới góc nhìn này. Công nghiệp mong đợi có được sinh viên tốt nghiệp "hữu dụng" một ngày nào đó, và phàn nàn về các chương trình vô dụng thế bởi vì đây không phải là hoàn cảnh. Đúng đó là cái gì đó nói ngoa lên. Có nhiều công ti có loại chương trình huấn luyện cho người mới tuyển. Tuy nhiên tôi có ấn tượng rằng những chương trình này được dự định để huấn luyện những người được thuê theo cách công ti làm mọi sự, thay vì biến người kĩ sư theo mẫu thành người kĩ sư thực. Chẳng hạn, trong một số trường hợp ngay cả những người có kinh nghiệm cũng phải làm chương trình, bởi vì họ phải học Cách thức của công ti. Xác nhận Điều này đưa tôi tới vấn đề về xác nhận cho kĩ sư phần mềm. Các chuyên môn kĩ nghệ khác có đa dạng xác nhận. Như được lưu ý ở trên, các chương trình đại học của họ phải được xác nhận và sinh viên tốt nghiệp phải hoàn thành các yêu cầu khác và trải qua việc xác nhận chính thức với cơ quan kĩ nghệ thích hợp. Luận cứ đã được trình bày là việc xác nhận như vậy là không thích hợp cho phát triển phần mềm bởi vì chúng ta không biết rằng người với xác nhận như vậy có thể được đảm bảo để tạo ra phần mềm làm việc. Luận cứ như vậy bỏ lỡ vấn đề xác nhận mang nghĩa gì. Đảm bảo duy nhất mà xác nhận có thể cung cấp là ở chỗ, người được xác nhận đã, tương ứng với bằng chứng được trình bày, được đưa vào thực hành tốt nhất hiện thời của chuyên môn kĩ nghệ nào đó. Do vậy, khi người đó ra quyết định kĩ nghệ, người đó có thể ra cùng quyết định như những người khác được xác nhận tương tự. Nếu quyết định đó bị sai, và người ta có thể chứng minh rằng đó không phải là điều người khác được xác nhận tương tự sẽ làm, thế thì người đó phải chịu trách nhiệm pháp lí. Tôi biết tôi đang đơn giản hoá rất nhiều một quan niệm rất phức tạp nhưng tôi tin rằng điều tôi đã mô tả trên đây là bản chất của xác nhận. Nếu tôi đúng thì việc xác nhận cho kĩ sư phần mềm là ý tưởng hợp lí (và thực tế chương trình UoA được xác nhận bởi cơ quan kí kết New Zealandtheo Thoả ước Washington). Chúng ta có chưa? Có thể là có kết năng được tạo ra trong việc giữ điều tôi đã gọi là CS và SE cùng nhau, điều sẽ mất đi (và bị bỏ lỡ) nếu việc phân tách tôi đã tranh luận xảy ra, tôi thực sự không biết. Nhưng đội chiếc mũ Kĩ sư của tôi lên, có vấn đề cần được giải quyết trong thế giới thực — làm sao quyết định dạy môn nào, làm sao quyết định nội dung các môn là gì, làm sao trình bày điều sinh viên đã học cho người sử dụng lao động tiềm năng, và nếu thực tế của bạn có chứa các chất lượng tách biệt trong SE và CS, lại có nhu cầu giải thích sự khác biệt. Những vấn đề này cần được giải quyết bây giờ, chúng ta không thể chờ giải pháp hoàn hảo được (điều mà bất kì kĩ sư nào cũng biết là không tồn tại). Điều tôi vừa trình bày có thể không phải là câu trả lời tốt nhất, nhưng nó là một câu trả lời tôi nghĩ là tốt theo nghĩa kĩ nghệ — nó cung cấp giải pháp đủ có giá trị cho người đúng bây giờ. Tôi hi vọng bạn cũng nghĩ như vậy. Cám ơn Bài viết này được viết trong năm 2008 khi tôi đang trong kì nghỉ Nghiên cứu và học tập. Thực tế nó đã bắt đầu khi tôi đang trên tàu hoả đi xuống miền nam Thuỵ Điển, khi tôi là nghiên cứu viên mời cho dự án BESQ tại Viện công nghệ Blekinge, Ronneby, Thuỵ Điển, tôi lấy làm biết ơn về sự hỗ trợ của họ. Tôi xin nhận toàn bộ chê trách về mọi điều được viết ra ở đây nhưng không coi là có công gì. Nhiều điều trong các ý tưởng tôi đã trình bày không phải là mới, và chắc chắn không từ tôi. Chúng tới từ nhiều cuộc thảo luận tôi đã đọc và tham gia, đặc biệt vì được tham dự vào chương trình UoA. Tôi không thể liệt kê hết (hay thậm chí nhớ hết) mọi người đã nói điều gì đó trong sự hiện diện của tôi mà tôi đã tổ hợp lại vào suy nghĩ của mình, nhưng tôi xin cám ơn tất cả các bạn. Một người tôi muốn nhắc tới là David Parnas, người đáp lại cho một câu hỏi tại ASWEC 2005 làm kết tinh suy nghĩ của tôi về chủ đề này, và thực sự là chỗ bắt đầu cho bài viết này. Ông ấy nói điều đó tốt hơn (và ngắn hơn!) tôi, nhưng những người không có đó sẽ phải làm điều này. Tài liệu tham khảo [1] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley, 2 edition, April 2003. [2] Andrew S. Tanenbaum. Computer Networks. Prentice Hall, 4 edition, 2003. [3] Will Tracz, editor. SIGSOFT Softw. Eng. Notes, 28(6). ACM, New York, NY, USA, November 2003. William Griswold’s letter to the editor, Peter Henderson’s reply. Reflections on What is Software Engineering Ewan Tempero December 19, 2008 Introduction This essay presents various thoughts I have had regarding the nature of software engineering, based on my experience due to teaching into a software engineering university programme and research in the area. The Question The starting point for this essay is the following question: Is there a difference between computer science and software engineering and if so what is it? This is a question I have had to come up with a good answer for as, since 2002, I have been at the University of Auckland (UoA), which allows a Major in both Computer Science (CS), in the Bachelor of Science (BSc), and a Specialisation in Software Engineering (SE), in the Bachelor of Engineering (BE). I am in the Computer Science department, but since most of my teaching was in the SE programme I have had to answer this question both from potential students and potential employers. More recently, as I was preparing to go away on Research and Study Leave (our equivalent of “sabbatical”), I came across a discussion on this question in Software Engineering Notes (SEN) giving opposing views on the subject. What was interesting about this discussion is, had I seen it when it when it was published in 2003 I would have agreed with one side, but I am now firmly on the other side. Since reading this discussion, and having the luxury of time on leave to think about such things, I’ve been thinking about why my views have changed, which has lead to what you see before you. Historical Context and Motivation At the beginning of 2002, the SE degree at UoA was quite new — the first cohort had just begun their third (of four) year. Being so new, there was not a lot known about it. Potential new students (and their parents) wanted to know if there were jobs for SE graduates, and why they should take SE instead of CS, which had been around for many years. Industry wanted to know what the difference was, in order to decide whether they wanted to hire SE graduates instead of (or even as well as) CS. “There is no difference” was not only not a politically useful answer (there must be a difference otherwise why is UoA offering both!), it also clearly wasn’t entirely correct. While a number of the courses in the SE programme began life as clones of their CS counterparts, most of them diverged to be different courses. There were also other SE courses that had no equivalent in CS, plus there were all the other engineering courses that made up the BE. So the programmes are different, but that could be considered a somewhat artificial distinction. Much more interesting is whether there is a true difference between the two. The question is not new. There have been many discussions in various venues, including many staff tea rooms, as to what the difference is. The SEN discussion I mentioned above appeared in the November 2003 issue and consisted of a letter by Bill Griswold and a response by Peter Henderson [3]. I came across this issue as I was cleaning up my office in preparation for going on leave. I had somehow neglected to read it at the time it came out and so I took a quick look at it (SEN being one of the few periodicals I receive that I make some effort to read). In his letter (which was a response to a proposal for an SE curriculum), Griswold expressed the view that CS is Engineering, based on the observation that much of what is associated with CS involves the construction of artefacts. He felt that SE was a sub-discipline of CS, and questioned whether making any distinction was of benefit for the development of the respective fields, in research and in teaching. Henderson (who at the time wrote a column for SEN on software engineering education) felt that there was a difference between CS and SE just as there is a difference between science and engineering. He felt that many graduates of CS programs don’t have an “engineering mindset”. At the end of 2003 (that is, after my second year of teaching in the SE programme at UoA), I probably would have agreed with Griswold. I almost certainly would have agreed even only months earlier. My previous appointment of 11 years had been in the Computer Science department at Victoria University of Wellington (VUW), which offered a fairly traditional CS programme. My own background featured fairly traditional computer science courses, however my undergraduate major was Mathematics and my PhD was in theoretical computer science. By the time I left VUW my research and teaching were firmly in “software engineering” but I considered it a sub-discipline of CS rather than something separate. At UoA, while I was in a department in the Faculty Of Science (FoS), as most of my teaching was in the SE programme, I had more contact with the Faculty of Engineering (FoE), which administered the SE programme. The structure of the SE specialisation was strongly influenced by the structure of the BE, administered by the FoE, which had existed for nearly (at that time) 100 years. There were “professional development” courses at every level for all specialities, and “mathematical modelling” (featuring lots of calculus) for most specialities. The designers of the SE speciality were almost entirely in the Computer Science department (FoS) and had argued successfully that SE students didn’t need all of the continuous mathematics, and that more appropriate courses would replace those courses the other engineering students took (discrete mathematics and so on). However there was no avoiding the professional development courses, as they were part of the engineering accreditation, and there was no avoiding the joint first year that all students took. The first year featured almost nothing relating to software (unless the half-course of programming in MATLAB counted). Fortunately for the SE programme, there was one “elective” slot at first year, and SE students were required to take the Computer Science introduction to programming course in that slot .1 I found the restrictions to the SE programme imposed by the BE structure just a little bit unhelpful. I did not see the need for an SE student to take a chemistry course in the first year. I’m not saying that the chemistry (and I pick on chemistry only because I don’t want to list all courses) is no use, or that SE students would benefit from seeing it, but four years is little enough as it is and that chemistry slot could be used for a course containing much more directly relevant material for SE students. The line by the engineering staff as that they wanted all students to have the same foundation so that the students made their choices of speciality on an informed basis, and that as these courses were all taught by engineers it would help the students to acquire the “engineering mindset”. I didn’t buy it. At the time I didn’t see that whatever mindset mechanical or chemical engineers had developed was going to be of any value to SE students. At the end 2 of 2003, the first cohort completed the programme. This included a “capstone” project course where students worked in teams of two on (mostly) staff-sponsored projects. This course was “capped off” with a 2-day conference where all project teams presented the projects and then the following week there was an exhibition day open to the public that students This is when I got to see, for the first time, a “finished engineering student” (I am carefully not saying said student was a “finished engineer”!) I definitely saw something in this cohort that I had not seen in computer science graduates. It’s hard to define. There was still the aspect of “we’ve done some cool stuff and we use cool technology” but there was also a clear indication of “we’ve paid attention to what the client wants” and “we’ve paid attention to what industry practise is.” I believe this was a sign of this “engineering mindset” that everyone had been talking about. This was the point at which I started to became less inclined to dismiss the “engineering” way of doing things, and began to pay more attention to how they did things. I still would prefer that the SE programme was a little different, but am now engineer enough to understand that’s the reality that I have to deal with. As I don’t know exactly what is leading to the engineering mindset, I’m less inclined to throw out courses just because I don’t see they are useful, as it may be that those courses that provide the necessary foundation (that is, maybe the “traditional” engineers are right afterall!) I now also understand that there may be some value to making a distinction between computer science and software engineering. Distinguishing on Principle Of course attaching labels to things has its dangers. People tend to evaluate on the basis of the label rather than the actual thing, and labels are usually far too simple for that to be the right thing to do. People use labels as flags to rally around, to create “us” and “them”, when other means of solving problems may be more helpful. But we use labels to solve a problem, and its a type of solution we use to solve many problems — divide and conquer. We find we can better reason about things if we can just isolate the things we care about. If the labels provide useful distinctions, then we may be able to make more informed decisions. For example, with a clear distinction between SE and CS, departments can, rather than debate whether or not they are doing SE or CS, can decide whether they want to be a “computer science department with a strong SE focus” or a “software engineering department” or accept that they really do do both, or whatever. Rather than argue that certain topics are “clearly important” and so “must be taught”, we can examine whether the topics are more relevant to CS or SE and include them (or not) on the basis that the course is intended for a CS or SE programme, rather than trying to defend this nebulous “clearly important” criteria. So, if we were to make a distinction between Computer Science and Software Engineering, what should it be? A reasonable starting point is to consider the difference between Science and Engineering. There are many learned discussions on this but rather than rehash them here I will stick to something simple: Scientists try to understand reality. Engineers try to deal with it. 3 Like all slogans it presents a simplistic view of what is actually the case, but like all slogans it has elements of truth about it. It captures a principle that can be used to decide when something could be considered “science” and when it could be considered “engineering.” The distinction is that a scientist’s primary intent is to understand how the world works, whereas the engineer’s intent is to build things that have to work in the world. There are many things that scientists “know” (in the sense that scientists can be said to know anything) to be true, but knowing these things doesn’t impact everyday life. But then some engineer will realise that that thing can be exploited to provide some service or product that otherwise could not be done, or to provide existing services and products more efficiently. In many discussions I’ve seen on what Engineering is, there has been an emphasis on building something. However I don’t see that as necessarily a defining feature of Engineering, especially in the sense that building something means it is not Science. Lots of building goes on in science. Two examples are the Hubble telescope and the Large Hadron Collider. There is no question that these involved some serious engineering, but their entire purpose is to support fundamental science. Just because something is being constructed, doesn’t mean no science is occurring; the question is what purpose the construction serves. One possible purpose of construction is to determine what level of understanding science has reached. One way to test a theory is to look at what artefacts it predicts can be built, and try to build them. Scientists often call this kind of activity an “experiment”, but that doesn’t alter the fact that something is being built. An example here is Dolly the sheep, which represented a demonstration of the level of understanding of cloning (among other things!) but clearly involved the construction of an artefact (and no small amount of biological engineering). I accept that other interpretations of these examples exist, but I would argue that my interpretation is not inconsistent with what happens, and so it supports my thesis that it is not whether or not construction takes place that defines engineering, but what the purpose of that construction is. If it is to help understand reality, then it is for science; if it results in an artefact that is intended to provide value to someone, then it is engineering. Of course we take take these arguments to all kinds of extremes. For example, if I’m building something that a scientist will use for an experiment, that is, it is an artefact that will provide value to the scientist, isn’t that engineering? Yes! No question. The Large Hadron Collider and my other examples are marvels of engineering. My point is that the fact that such construction took place does not mean no science was taking place — a point I will return to later. Another point is that, by my definitions, those who do research in engineering are really scientists, and that is true. Engineering researchers operate by the same rules as scientists with regards to gathering and provision of evidence to support their claimed understanding of reality. The kinds of evidence they gather are much more likely to involve construction (“I demonstrate the validity of my ideas about inductive power transfer by building a device that is powered by it”), and the problems they consider will be much more likely to come from problems faced by practising engineers (“Science tells us that we should be able to transmit electricity through the air. Let’s see if we can make that practical for everyday use.”) but nevertheless they are scientists (and, mostly, engineers too). This distinction between understanding reality versus dealing with it is useful for making decisions. A potential student who likes to explore ideas and understand how things work may be better off taking a science degree, whereas one who likes to build things and produce final products may be better off doing engineering. In deciding what courses to offer (or rather, which courses to not offer as there is never enough time to teach everything that might be useful in any degree programme), and engineering department will be more inclined to keep courses that focus on the practical realities of making things work at the expense of more “theoretical” courses (reluctantly and with great wailing and gnashing of teeth on the part of some staff). Separating Computer Science and Software Engineering The principle I described above is all very good for distinguishing Science and Engineering, but it is not much help distinguishing Computer Science and Software Engineering (or Chemistry and Chemical Engineering for that matter). I need to identify the part of reality that’s relevant; I use “computation”. So, refining my earlier statement gives: Computer Scientists try to understand computation, Software Engineers try to provide computation in a useful form. For me, CS is about understanding the nature of computation at all levels, whether it’s understanding what it means to be computable, determining how computation can be used to at least mimic, if not duplicate, human intelligence, finding the best algorithms to support ad-hoc networks for ubiquitous computing, or how to organise data to support fast solutions to complex queries. SE, on the other hand, is about applying what computer scientists have learned to construct products that do computation that are of value to people. There are aspects to such construction that really are not much to do with computation but nevertheless cannot be avoided when constructing software. For example, version control is something that those constructing software products need to know about but which could not really be considered a problem relating to the nature of computation (although I’m sure there are some potentially interesting mathematical problems that apply to version control). It is possible that the lines are more blurred for CS and SE than for other fields (e.g., Chemistry versus Chemical Engineering, although it would surprise me if people in those fields argued differently). It is not uncommon for someone to start with the computation puzzle (e.g., what algorithms to use to support searching a very large distributed unorganised dataset) and that same someone to engineer a solution that makes them and lots of other people are large amount of money. The bit that makes the money requires a great deal of sophisticated engineering, and I doubt that Sergey and Larry would claim otherwise, and I also suspect that they would not argue with an interpretation that says that Google represents a successful (and ongoing) experiment demonstrating the level of their understanding about algorithms for doing search. So how is making this distinction useful? It can help determine the contents of a course. For example, a Data Structures course for a CS degree would more reasonably contain details about how to perform asymptotic analysis of algorithms and include, for example, detailed discussions about the different kinds of algorithms for sorting. A SE version would more reasonably concentrate on practical issues surrounding choice of algorithms or data structures rather than details of the algorithms themselves, so how the mergesort algorithm works is less important than under what circumstances it is a better choice than quicksort. A reasonable assignment for the CS version of an Algorithms course would be to prove the correctness of Dijkstra’s algorithm, whereas for the SE version might require an implementation that works for graphs with more than 10,000 vertices. And I must emphasise, this is not to say that a CS student wouldn’t benefit from implementing Dijstra’s algorithm and an SE student wouldn’t benefit from doing the proof, but with a limited time-budget that doesn’t allow doing both, the distinction I make provides criteria on which to base a decision. A similar kind of argument can be used when deciding what courses to teach. It is less likely that a course on software architecture would appear in a CS programme than an SE one, because software architecture is not so much about how computation works as it is about how to organise provision of computation. That said, a software architecture course that mainly covered the formal aspects of architecture descriptions languages, or the modelling aspects of model-driven architecture would not be out of place in (my vision of) a CS programme. If someone really wanted to teach a software architecture cour |
||
|
|
|
Múi giờ hiện tại là GMT 22:54:39 05-02-2012 |
