Menjembatani kesenjangan antara penelitian ilmu komputer dan rekayasa perangkat lunak [ditutup]

8

Apakah Anda percaya ada kesenjangan antara penelitian ilmu komputer dan masalah rekayasa perangkat lunak? Sebagai contoh, apakah insinyur perangkat lunak harus khawatir tentang "anjakfakta dan grafik isomorfisme" atau beberapa masalah ilmu komputer yang rumit jika mereka harus .... katakanlah membangun situs kereta belanja? Mungkin tidak.

Dan jika ada keterputusan antara ilmu komputer dan para insinyur yang membangun aplikasi? Apakah itu cara rekayasa dan sains seharusnya ada? Akankah insinyur menyelami bertahun-tahun makalah penelitian untuk memecahkan masalah tertentu yang mereka miliki?

Sunting-1: Setelah memikirkannya, sains umum mungkin memiliki masalah yang sama. Saya yakin ada ahli kimia terkemuka yang bekerja di perusahaan seperti McDonald's dan Taco Bell yang bertugas membuat burger yang lebih baik dan lebih mudah dibuat.

computer-science berlinbrown2
sumber
Gap apa? Jika Anda menginginkan tenurial dan hibah maka Anda khawatir tentang "isomorfisme anjak piutang dan grafi" seperti yang Anda katakan dan jika Anda ingin membangun situs kereta belanja maka Anda khawatir tentang cookie dan data sesi. Kesenjangan apa yang ada untuk dijembatani?
davidk01
Anda tentu harus khawatir tentang grafik dan semacamnya jika Anda sedang membangun alur kerja apa pun (termasuk keranjang belanja atau hal-hal biasa lainnya). Kalau tidak, alur kerja Anda mungkin menjadi tidak dapat digunakan dan tidak bisa dipahami oleh pengelola dan pengguna akhir Anda.
SK-logic

Jawaban:

10

Dalam sebagian besar posisi rekayasa perangkat lunak, masalah ilmu komputer mendasar jarang muncul, karena satu dari dua alasan:

  • Mereka telah dipecahkan oleh alat yang Anda gunakan. Contohnya adalah algoritma penguraian untuk bahasa pemrograman yang Anda gunakan oleh kompiler Anda, penjadwalan algoritma untuk aplikasi yang Anda jalankan oleh sistem operasi, resolusi kueri dalam database yang Anda gunakan, dll.
  • Mereka sama sekali tidak penting untuk apa pun yang Anda coba capai. Bukan karena mereka tidak akan membantu, tetapi lebih karena tugas otomatisasi biasa jauh lebih penting daripada versi optimal yang dioptimalkan.

Alasan mengapa begitu banyak insinyur perangkat lunak membangun sistem informasi yang sepele dari sudut pandang teoretis, hanya karena mereka diperlukan. Cara dunia kita saat ini otomatis mungkin kurang dari 0,01% dari apa yang bisa dicapai. Jadi untuk beberapa dekade mendatang kita mungkin hanya akan membangun sebagian besar sistem informasi dan antarmuka. Begitu kita memilikinya, beberapa masalah mendasar akan mulai bermunculan.

Masalah-masalah ini saat ini ada, misalnya berkenaan dengan skalabilitas, threading, dll. Tetapi mereka hanyalah bagian yang sangat kecil dari semua yang perlu dilakukan. Jadi alasan mengapa perusahaan membangun sistem informasi yang relatif sepele berulang-ulang adalah karena (1) orang membutuhkannya dan (2) itu jauh lebih mudah (dan lebih menguntungkan) daripada menyelesaikan masalah mendasar.

Deckard
sumber
1
"Cara dunia kita saat ini otomatis mungkin kurang dari 0,01% dari apa yang bisa dicapai." Itulah yang saya pikirkan. Sangat disayangkan bahwa semua sains, penelitian, dan jenius canggih itu bisa hilang karena kita sedang membangun aplikasi yang pada dasarnya mengambil data dari satu format dan memasukkannya ke dalam basis data.
berlinbrown2
3
@Berlin, saya pikir itu adalah kerangka kerja masalah yang berusaha diatasi. Apa pun itu, kami bergerak ke arah yang benar. Pikirkan tentang berapa banyak kejeniusan, dll., Yang digunakan untuk mendapatkan arsip yang terbuang sia-sia di lemari!
Ethel Evans
6

Apakah Anda percaya ada kesenjangan antara penelitian ilmu komputer dan masalah rekayasa perangkat lunak?

Pengalaman saya adalah bahwa pengembangan perangkat lunak komersial / praktis tertinggal dari penelitian akademis 5 hingga 30+ tahun. Salah satu kerangka waktu tercepat dari makalah akademik terobosan ke produk pengiriman komersial adalah SQL. Makalah ini diterbitkan pada tahun 1969, IBM dan yang lainnya menghabiskan banyak waktu dan upaya untuk membuat produk yang layak, dan produk nyata yang layak secara komersial adalah Relational Software - perusahaan yang sekarang bernama Oracle.

Bahasa fungsional dikembangkan oleh para peneliti pada tahun 1960-an. Berapa banyak yang umum digunakan saat ini? Beberapa. Mereka mendapatkan lebih banyak menggunakan hari ini daripada yang mereka lakukan di luar dinding universitas yang tertutup ivy. Tetapi butuh tiga dekade untuk melakukannya.

Akankah insinyur menyelami bertahun-tahun makalah penelitian untuk memecahkan masalah tertentu yang mereka miliki?

Iya. Saya selalu melakukannya. Ketika saya bekerja di perusahaan yang membuat jaringan area penyimpanan, banyak produk yang mulai dikirim dijelaskan dalam makalah penelitian yang diterbitkan 5-6 tahun sebelumnya.

Contoh lain melibatkan masalah yang disebut "pencocokan pasien." Manusia pandai melihat hal-hal seperti Chem. Dept.atauDepartment of Chemistrydan menentukan hal-hal seperti itu identik. Sebagian besar algoritma memiliki waktu yang sulit menentukan hal-hal seperti itu. Saya bekerja di perusahaan yang menangani resep obat elektronik, laporan laboratorium, dan klaim asuransi. Akan sangat membantu untuk dapat (secara anonim) dapat memiliki data jangka panjang yang mencakup kemanjuran dan efektivitas perawatan untuk pasien. Hal seperti itu perlu bergantung pada kemampuan untuk menentukan kedekatan string. Selama 1990-an, sebagian besar peneliti di bidang ini lenyap ke dalam proyek Genom Manusia, dan sebagian besar pekerjaan mereka menghilang dari web (dengan NDA dan kekayaan intelektual, semua yang ditemukan orang-orang ini menghilang dari web ketika mereka pergi bekerja untuk industri swasta). Setelah 911, nama yang cocok menjadi masalah "keamanan nasional" (ada sekitar 25 cara untuk mengeja Mohammed dalam bahasa Inggris, dan sekitar selusin cara untuk mengeja Osama) dan banyak dari sisanya lenyap juga. Jadi satupenemu / perusahaan memiliki produk yang memungkinkan Anda mencocokkan orang dan hubungan yang disebut " penganalisa hubungan tidak jelas " yang akhirnya menghilang menjadi add-on untuk DB2. Anda harus banyak menggali kertas. Mungkin tidak jika Anda membuat kereta belanja, tetapi cukup umum untuk melakukannya di proyek lain.

Tesis: Deteksi adaptif terhadap sekitar catatan duplikat basis data dan pendekatan integrasi basis data untuk penemuan informasi .
Perpustakaan yang mengimplementasikan beberapa fungsi dalam tesis .

Tangurena
sumber
Respons yang baik dan Anda menghubungkan tesis yang sebenarnya ke aplikasi. Saya masih berpendapat bahwa itu bukan norma untuk sebagian besar rekayasa perangkat lunak, tugas pengembangan di luar sana. Seperti yang Anda katakan, saya pikir pengembangan perangkat lunak mungkin bertahun-tahun atau dekade di belakang penelitian yang ada. Dan itu untuk tugas-tugas menarik seperti 'pencarian google' atau aplikasi biometrik.
berlinbrown2
Itu tidak benar. Sebagai contoh, sistem rekomendasi, analisis keranjang pasar, dll. Semua keluar dari penelitian ilmu komputer mendasar menggunakan Bayes Theorem dan ini tidak memakan waktu 30+ tahun.
Mushy
4

Ilmuwan Komputer Akademik sangat baik dengan yang berikut:

  1. Analisis algoritma
  2. Pengetahuan tentang Struktur Data Standar.
  3. Teori automata

Semua hal di atas bermanfaat untuk rekayasa perangkat lunak. Bahkan akan sangat diperlukan untuk memiliki setidaknya satu ilmuwan komputer dalam tim rekayasa perangkat lunak.

Namun, cara ilmu komputer diajarkan, dan aturan akreditasi ABET memperburuk masalah (jika bisa disebut masalah). Para ilmuwan komputer tidak memiliki banyak pengetahuan tentang mengikuti bidang rekayasa perangkat lunak utama.

  1. Jejak kaki RAM suatu perangkat lunak dan dampaknya pada kinerja perangkat lunak.
  2. Rekayasa pemeliharaan perangkat lunak. Mereka tidak menghargai kenyataan bahwa 80% pekerjaan perangkat lunak dalam memelihara perangkat lunak, yang merupakan komponen terbesar dari biaya perangkat lunak.
  3. Cara bekerja dekat dengan perangkat keras. Ini diperlukan ketika Anda melihat seluruh sistem sebagai kombinasi perangkat keras dan perangkat lunak dan Anda mengoptimalkan sistem untuk melihat bagaimana mengoptimalkan keduanya untuk fungsionalitas terbaik.
  4. Menemukan prosedur pengujian, implementasi, dan pemeliharaan perangkat lunak yang baru, cepat, dan andal.
  5. Dokumentasi perangkat lunak, pelatihan klien dan dokumentasi terkait.
  6. Rekayasa keamanan sistem.

Saya bisa terus dan terus tetapi saya pikir saya telah membuat poin saya.

Rekayasa perangkat lunak saat ini adalah disiplin ilmu tersendiri yang meminjam dari ilmu komputer, tetapi mendorong teknologi dan kehidupan manusia saat ini. Anda benar-benar membutuhkan otak Insinyur untuk unggul di dalamnya. Semua ilmuwan komputer tidak cocok menjadi insinyur perangkat lunak yang hebat. Tentu saja sebaliknya juga tidak akan benar.

Satish Singhal
sumber
apa itu "ABET"?
nyamuk
Saya tidak setuju. Memperoleh pengetahuan tentang pengembangan perangkat lunak bukanlah hal yang tinggi, menyendiri saat Anda membuatnya. Saya memiliki Magister Ilmu Komputer dan saya tidak kekurangan pengetahuan om bidang rekayasa perangkat lunak utama. Sebagian besar insinyur perangkat lunak saat ini mengalami degreed dan mengambil pengetahuan baru itu mudah ... kami telah membuktikan bahwa kami dapat belajar!
Mushy
2

Saya benar-benar berpendapat bahwa untuk membangun situs kereta belanja yang baik , Anda benar-benar perlu menggunakan algoritma yang sulit.

Katakanlah Anda ingin memprediksi perilaku pengguna berdasarkan pembelian sebelumnya. Itu akan membutuhkan lebih banyak daripada a+b=cmelakukannya secara efektif. Bagaimana dengan kebiasaan pembelian berdasarkan sejumlah faktor yang berbeda, seperti usia, jenis kelamin, lokasi geografis, dll?

Dalam pekerjaan saya sendiri, ada penggunaan sehari-hari algoritma kompleks dalam rendering, AI, dll.

Singkatnya, jika Anda memikirkan fitur tertentu (yaitu hanya keranjang belanja), maka kemungkinan besar Anda berpikir tentang implementasi yang buruk. Mulailah berpikir implementasi google atau amazon dan saya yakin Anda akan mulai melihat di mana itu akan berguna (atau diperlukan) untuk mengetahui atau setidaknya terbiasa dengan algoritma yang kompleks.

Demian Brecht
sumber
Ya, pencarian praktis dan algoritma penyortiran adalah bagian dari komputasi. Tapi saya tidak akan menyebut algoritma pengurutan dasar masalah menarik dalam penelitian ilmu komputer. Saya melihat AI termasuk visi komputer, algoritma genetika memiliki aplikasi yang lebih praktis tetapi ada aspek lain dari penelitian ilmu komputer yang tampaknya jauh dari rekayasa perangkat lunak.
berlinbrown2
@berlin: Saya akan membayangkan bahwa jika Anda mendapat pekerjaan di NASA atau NSA sebagai insinyur perangkat lunak, Anda akan dihadapkan dengan semua jenis algoritma tipe penelitian ilmiah. "Rekayasa Perangkat Lunak" adalah istilah yang cukup kabur dan dapat berarti berbagai hal tergantung pada konteks bidang pemberi kerja.
Demian Brecht
2

Insinyur perangkat lunak pemecahan masalah memiliki tumpang tindih yang sangat besar dengan penelitian ilmu komputer, dan juga penelitian matematika & statistik.

Mendesain situs web bukanlah rekayasa perangkat lunak, meskipun Anda mengintegrasikan beberapa kode keranjang belanja. Ini mendesain.

Bahkan 'coding' belum tentu rekayasa perangkat lunak - Saya tahu banyak coders yang tidak akan menganggap diri mereka sesuatu yang mendekati insinyur. Kode dapat sesederhana manipulasi string atau menulis rumus Excel.

Jelas tidak semua rekayasa perangkat lunak akan tumpang tindih dengan penelitian ilmiah (ada banyak tanggung jawab lain dalam pekerjaan), tetapi saya telah membaca banyak makalah yang diterbitkan untuk menentukan algoritma atau pendekatan optimal untuk masalah. Masalah-masalah ini dapat timbul hanya setahun sekali (sisa waktu saya menulis validasi UI atau apa pun) tetapi itulah sifat lingkungan kerja saya.

Kirk Broadhurst
sumber
1

Apakah Anda percaya ada kesenjangan antara penelitian ilmu komputer dan masalah rekayasa perangkat lunak?

Tidak.

Sebagai contoh, apakah insinyur perangkat lunak harus khawatir tentang "anjakfakta dan grafik isomorfisme" atau beberapa masalah ilmu komputer yang rumit jika mereka harus .... katakanlah membangun situs kereta belanja? Mungkin tidak.

Salah. Mereka menggunakan alat yang bergantung pada hal ini dilakukan dengan benar.

Memang, semua hubungan teman-teman Anda di Facebook adalah masalah teori grafik besar. Sangat rumit. Sangat besar. Sangat teoretis.

Dan jika ada keterputusan antara ilmu komputer dan para insinyur yang membangun aplikasi?

Iya. Beberapa orang membuat aplikasi yang jelas-jelas tidak memenuhi syarat. Saya telah melihat banyak barang jelek yang dibuat oleh "profesional" berbayar yang seharusnya melakukan hal lain, lebih berguna dengan waktu mereka.

Apakah itu cara rekayasa dan sains seharusnya ada?

"Seharusnya" tidak ada artinya. Ini cara itu tidak ada.

Akankah insinyur menyelami bertahun-tahun makalah penelitian untuk memecahkan masalah tertentu yang mereka miliki?

Iya. Sering. Itu sebabnya saya berlangganan ACM Digital Library. http://portal.acm.org/ Sangat penting untuk mengatasi masalah yang tidak sepele.

S.Lott
sumber