Apakah pengembangan perangkat lunak disiplin teknik?

Bisakah pengembangan perangkat lunak dianggap rekayasa? Jika tidak, apa saja hal-hal yang kurang untuk dikualifikasikan sebagai disiplin teknik? Terkait dengan ini adalah pertanyaan tentang Stack Overflow tentang perbedaan antara programmer dan insinyur perangkat lunak .

Ada Institut Rekayasa Perangkat Lunak di Universitas Carnigie Mellon yang mengatur dan mempertahankan standar CMMI. Apakah ini sesuatu yang akan mengubah pembangunan menjadi rekayasa?

Apakah rekayasa pengembangan perangkat lunak? Jika tidak, apa saja hal-hal yang kurang sehingga harus memenuhi syarat?

Ya, rekayasa perangkat lunak adalah disiplin teknik.

Wikipedia mendefinisikan teknik sebagai "aplikasi matematika, serta pengetahuan ilmiah, ekonomi, sosial, dan praktis untuk menciptakan, berinovasi, merancang, membangun, memelihara, meneliti, dan meningkatkan struktur, mesin, peralatan, sistem, komponen, bahan , proses, solusi, dan organisasi. " Hasil rekayasa perangkat lunak adalah sistem perangkat lunak yang dapat meningkatkan kehidupan masyarakat, dan dapat melibatkan beberapa kombinasi pengetahuan ilmiah, matematika, ekonomi, sosial, atau praktis.

Dalam hal bagaimana dilihat, secara akademis dan profesional, itu bervariasi. Program rekayasa perangkat lunak dapat diakreditasi oleh ABET sebagai program rekayasa. Insinyur perangkat lunak dapat menjadi anggota IEEE. Beberapa perusahaan menganggap rekayasa perangkat lunak sebagai disiplin teknik, sementara yang lain tidak - itu benar-benar sulit.

Buku terbaik tentang hal ini adalah Pengembangan Perangkat Lunak Profesional Steve McConnell: Jadwal Lebih Pendek, Produk Berkualitas Tinggi, Proyek Lebih Sukses, Peningkatan Karir . Ini terlihat pada rekayasa perangkat lunak sebagai profesi, evolusi dari kerajinan untuk profesi, ilmu pengembangan perangkat lunak, perbedaan antara software engineering dan software engineering (menerapkan praktek-praktek rekayasa perangkat lunak dibandingkan insinyur yang terjadi pada software membangun, dengan studi kasus yang termasuk almamater saya ), sertifikasi dan lisensi, dan etika.

Glenn Vanderburg memiliki serangkaian pembicaraan yang disebut "Rekayasa Perangkat Lunak Nyata" yang telah diberikan antara 2010 dan 2015 di sejumlah konferensi, bersama dengan dua pembicaraan terkait, "Kerajinan, Rekayasa, dan Esensi Pemrograman" (diberikan pada tahun 2011 sebagai keynote di RailsConf) dan "Craft and Software Engineering" (diberikan pada 2011 di QCon London). Saya pikir pembicaraan ini adalah argumen yang cukup komprehensif untuk mengapa rekayasa perangkat lunak adalah disiplin teknik.

Satu argumen, yang diajukan Vanderburg secara singkat dalam pembicaraannya, adalah argumen yang dibuat oleh Jack W. Reeves pada tahun 1992 (dan ditinjau kembali pada tahun 2005) tentang apa desain perangkat lunak dan bagaimana kode adalah output dari kegiatan desain rekayasa perangkat lunak ( ini juga dibahas pada wiki C2). Begitu Anda keluar dari aliran pemikiran lama di mana spesifikasi dan pemodelan adalah desain perangkat lunak dan menjadi desain kode perangkat lunak, beberapa hubungan antara rekayasa perangkat lunak dan disiplin teknik lainnya menjadi lebih mudah terlihat. Beberapa perbedaan dan alasan untuk perbedaan itu menjadi lebih jelas setelah Anda melihat bahwa ekonomi pengembangan perangkat lunak sangat berbeda dari banyak disiplin ilmu lainnya - konstruksi murah (hampir gratis, dalam banyak kasus), sementara desain adalah bagian yang mahal.

Apakah itu [CMMI] sesuatu yang akan mengubah pembangunan menjadi rekayasa?

Tidak. CMMI adalah kerangka kerja peningkatan proses yang memberikan panduan bagi organisasi tentang jenis kegiatan apa yang berguna saat membangun perangkat lunak. Disiplin teknik biasanya memiliki proses rekayasa. Memiliki proses seperti itu penting untuk keberhasilan penyelesaian proyek berkualitas tinggi. Yang mengatakan, CMMI (atau kerangka proses atau metodologi lainnya) hanya alat tunggal - menggunakannya tidak akan membuat Anda secara ajaib maju dari pengembang ke insinyur. Namun, tidak mengikuti semacam proses, menurut pendapat saya, merupakan tanda proyek yang bukan proyek rekayasa.

Juga, apa pendapat Anda tentang kursus / sertifikat rekayasa perangkat lunak?

Ini hanya nilai sebanyak orang lain dimasukkan ke dalamnya. Ada kursus yang bermanfaat dan ada kursus yang tidak berguna. Ada sertifikat yang berharga, dan sertifikat yang tidak sebanding dengan kertas yang dicetaknya. Ada banyak faktor, dari siapa yang mendukung atau mengakreditasi kursus atau siapa yang mengeluarkan sertifikat untuk industri pekerjaan Anda saat ini ke pekerjaan Anda saat ini dan ke mana Anda ingin pergi.

Berasal dari latar belakang teknik yang khas, tetapi membuat karir dalam pengembangan perangkat lunak, saya melihat kesamaan besar antara kedua dunia. Terlepas dari definisi teknik yang tepat, dalam praktiknya saya melihat pengembangan perangkat lunak tidak berbeda dengan pengembangan produk fisik. Setidaknya saya pikir seharusnya tidak jauh berbeda.

Baik Anda merancang pesawat terbang atau aplikasi perangkat lunak, untuk keduanya Anda perlu:

• membuat desain
• mendefinisikan subsistem dan komponen
• membuat prototipe
• tentukan dan jalankan tes
• dll.

Saya membaca di suatu tempat di jawaban lain bahwa merancang perangkat lunak berbeda karena Anda tidak merancang semuanya sebelum Anda memulai pemrograman. Yah sebenarnya pada tingkat lebih rendah itu juga terjadi ketika Anda merancang produk fisik. Merancang dan membuat prototipe dan menguji merupakan proses berulang.

Juga ketika proyek perangkat lunak bertambah besar, semakin penting untuk mendefinisikan subsistem yang jelas, komponen dan antarmuka yang juga mirip dengan merancang produk yang kompleks seperti pesawat terbang.

Itulah mengapa saya menganggap pengembangan perangkat lunak sebagai rekayasa.

Saya berpendapat bahwa memang ada yang namanya rekayasa perangkat lunak.

Rekayasa melibatkan aplikasi sistematis pengetahuan ilmiah untuk solusi masalah. Kompleksitas masalah yang ditangani saat ini tidak jauh berbeda dari yang ditangani oleh seorang insinyur listrik dalam menciptakan sirkuit atau insinyur kimia dalam merancang proses manufaktur atau insinyur mekanik dalam penciptaan perangkat.

Fakta bahwa ada juga pendekatan langsung dalam menerapkan rencana yang ada (pengembangan dalam kasus ini) sama saja dengan kenyataan bahwa di bidang lain seseorang melaksanakan rencana tersebut (misalnya, pekerja konstruksi).

Memang benar bahwa sebagian besar pengembang juga melakukan tugas rekayasa perangkat lunak, dan bahwa pendidikan kita sering tidak dalam pemrograman tetapi dalam rekayasa perangkat lunak. Jadi kami membuat tangan kami kotor sedangkan insinyur sipil tidak.

Namun, kemampuan untuk menerapkan bahasa dan program pemrograman tidak mengubah seseorang menjadi seorang insinyur: Saya telah bertemu dengan para pengembang saya yang tidak memiliki pemahaman yang benar tentang kompleksitas dan masalah di luar potongan kode mereka saat ini.

Adapun pertanyaan Anda tentang CMU: Penerapan standar atau praktik (misalnya, CMMI) tidak secara otomatis mengubah pekerjaan seseorang menjadi rekayasa. Namun, fakta bahwa ada organisasi yang melakukan penelitian ilmiah untuk memberikan praktik baru lagi-lagi merupakan pertanda bahwa ada yang namanya rekayasa.

Tidak, ini bukan rekayasa. Kami bukan orang yang saintifik dan kami tidak harus melewati salah satu dari tes teknik negara tersebut. Bahkan, itu ilegal untuk menyebut diri Anda seorang "insinyur" perangkat lunak di beberapa tempat karena kurangnya pengujian.

IMHO istilah 'rekayasa perangkat lunak' diciptakan untuk mencoba menggambarkan dengan lebih baik berbagai hal yang dilakukan pengembang, daripada hanya menjadi 'programmer' (yang memiliki nuansa beberapa proses mekanistik dengan sedikit pemikiran atau kreativitas).

Secara pribadi saya lebih suka analogi yang muncul dari seorang pengembang sebagai 'pengrajin', yang diperjuangkan oleh programmer pragmatis, antara lain.

Secara historis, orang telah mencoba menganalogikan pembuatan perangkat lunak dengan manufaktur. Saya pikir Jack Reeves membuat argumen yang cukup bagus untuk mendiskreditkan ide ini dalam artikelnya What Is Software Design .

Dari Wiki:

Rekayasa:

Rekayasa perangkat lunak adalah penerapan pendekatan yang sistematis, disiplin, terkuantifikasi untuk pengembangan, operasi, dan pemeliharaan perangkat lunak, dan studi tentang pendekatan ini; yaitu, penerapan rekayasa ke perangkat lunak.

Pengembangan perangkat lunak

Pengembangan perangkat lunak adalah serangkaian kegiatan yang menghasilkan produk perangkat lunak. Pengembangan perangkat lunak dapat meliputi penelitian, pengembangan baru, modifikasi, penggunaan kembali, rekayasa ulang, pemeliharaan, atau kegiatan lain apa pun yang menghasilkan produk perangkat lunak. [1]

Terutama fase pertama dalam proses pengembangan perangkat lunak dapat melibatkan banyak departemen, termasuk pemasaran, teknik, penelitian dan pengembangan dan manajemen umum.

Jadi mereka sangat mirip dan bisa juga berarti hal yang sama.

Dari Dictionary.com: en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /

- kata benda 1. seni atau ilmu membuat aplikasi praktis dari pengetahuan ilmu murni, seperti fisika atau kimia, seperti dalam konstruksi mesin, jembatan, bangunan, tambang, kapal, dan pabrik kimia.

Saya akan mengatakan bahwa membuat perangkat lunak adalah aplikasi praktis matematika dan ilmu komputer, dan berpotensi dari sejumlah ilmu murni tergantung pada aplikasinya.

[EDIT] FWIW, saya tidak menyebut diri saya seorang insinyur perangkat lunak, tetapi seorang pengembang perangkat lunak jadi saya tidak memiliki kepentingan pribadi dalam hal ini.

Dalam pandangan saya seorang Insinyur Perangkat Lunak dan Pengembang Perangkat Lunak adalah dua hal yang berbeda.

Saya melihat seorang insinyur perangkat lunak sebagai orang yang melakukan perencanaan, seperti siklus hidup yang akan diambil, melakukan persyaratan / spesifikasi, dll ... Pada dasarnya, seorang insinyur perangkat lunak menangani banyak dokumentasi. Ini dapat dilakukan oleh pengembang perangkat lunak dan / atau manajer proyek.

Sebuah pengembang perangkat lunak akan lebih erat terkait dengan seorang programmer tetapi dengan keterampilan lebih banyak di daerah lain seperti manajemen database, dll ..

Satu hal yang menarik untuk diangkat adalah Arsitektur . Seseorang yang juga terlibat dalam mencari tahu hardware / software apa yang akan dibutuhkan untuk siklus hidup proyek.

Saya akan pergi dengan "Tidak" di sini. Adik saya adalah seorang insinyur mesin, dan ia menggambarkan teknik sebagai "The Art of Being Cheap":

"Para insinyur lebih peduli menyelesaikan pekerjaan secepat mungkin, dengan biaya serendah mungkin, dengan bahan sesedikit mungkin. "

Sebagai reaksi, saya datang untuk menggambarkan pengembangan perangkat lunak (bukan rekayasa perangkat lunak - mereka pada dasarnya adalah dua bidang yang berbeda) sebagai "Seni Menjadi Efisien":

"Pengembang lebih peduli dengan menyelesaikan sesuatu secepat mungkin, dengan biaya serendah mungkin, dengan jumlah pengulangan paling sedikit. "

Perbedaannya ada di bagian terakhir dari kalimat-kalimat itu.

Apakah rekayasa pengembangan perangkat lunak?

Tidak. Menjadi insinyur berarti proyek Anda mengikuti garis waktu sebab-akibat - Anda mengikuti kode bangunan, oleh karena itu bangunan Anda tidak jatuh (atau setidaknya Anda tidak dapat disalahkan jika melakukannya). Menulis perangkat lunak, Anda dapat mengikuti semua pedoman yang ada (dan ada begitu banyak yang berbeda untuk dipilih!) Dan itu masih menggantung / crash / memberikan jawaban yang salah (kecuali jika Anda terlibat dalam bidang penulisan program yang dapat dibuktikan yang sangat kecil di sampingnya) - bahasa fungsional yang tidak efektif).

Saya melihat seorang insinyur (mekanik, struktural, perangkat lunak) sebagai seseorang yang merancang produk sebelumnya berdasarkan pada kebutuhan yang dipahami dan pemahaman tentang apa dan bagaimana cara menerapkan bahan untuk mengakomodasi kebutuhan itu.

Misalnya, Anda mungkin sering melihat insinyur struktur mencari berbagai kekuatan baja dan menerapkan aturan fisika untuk menghitung bahan yang diperlukan dan bagaimana mereka harus diimplementasikan. Rekayasa struktural adalah contoh utama karena Anda selalu berakhir dengan cetak biru (spesifikasi) apa yang akan Anda bangun sebelum Anda membangun. Itu tidak selalu terjadi dengan perangkat lunak.

Bagi saya perbedaan antara seorang insinyur perangkat lunak dan seorang programmer adalah bahwa insinyur tersebut mampu membangun spesifikasi untuk apa yang akan diproduksi sebelum menulis kode apa pun, di mana seorang programmer hanya menulis kode berdasarkan spesifikasi seseorang, atau merupakan salah satu dari mereka programmer barat liar yang menulis kode tanpa spesifikasi. Selain itu, insinyur memiliki gelar sarjana.

Saya menyamakan perbedaan antara pekerja konstruksi dan insinyur struktural dengan perbedaan antara programmer dan insinyur perangkat lunak.

Untuk memperjelas, saya hanya memiliki ijazah perguruan tinggi, jadi saya tidak bisa menyebut diri saya seorang insinyur.

Saya tidak akan menganggap istilah "teknik" sebagai yang paling tepat untuk menggambarkan pengembangan perangkat lunak, karena 2 alasan utama:

• Ini menyampaikan banyak ide lama, konsep dan apa yang disebut "aturan emas" yang berasal dari disiplin teknik tradisional seperti industri, sipil, angkatan laut, atau teknik mesin. Saya berbicara tentang peraturan di divisi tenaga kerja, proses produksi, standar kualitas ... Ini paling sering hanya berlaku secara marginal untuk perangkat lunak.

• Itu gagal menggambarkan dengan cara yang memuaskan apa pemrograman memiliki lebih dari disiplin ilmu lain (dan saya percaya itu memiliki lebih banyak dan jauh berbeda), dan apa tantangan baru yang harus dihadapi pengembang pada hari ke hari dibandingkan dengan rekan-rekan mereka dalam tradisional domain enineering. Sifat virtual dan tidak penting dari perangkat lunak memainkan peran besar dalam hal itu.

Pengembangan perangkat lunak telah lama dipandang sebagai "sekadar disiplin teknik". Mempertimbangkan tingkat kegagalan proyek perangkat lunak yang telah kita ketahui sejak diukur, sudah saatnya kita mengenali develoment sebagai binatang yang sama sekali baru, kode sebagai bahan yang sangat spesial dan siklus hidup aplikasi sebagai jenis siklus produksi yang sama sekali berbeda, dan berhenti dengan putus asa mencoba untuk menerapkan resep lama kepada mereka.

Ya, seseorang harus dapat menerapkan standar dan prinsip untuk sampai pada produk yang layak. Yang menyulitkan adalah pola pikir klien (itu hanya kode - tidak semestinya banyak biaya berubah), kesulitan ekstrim dalam mengkodifikasi apa yang harus dilakukan produk menjadi kode mesin (bahasa lisan / tulisan ke kode) dan menghitung " kualitas". Definisi kualitas Anda bukan milik saya.

Ini juga pengulangan. Ambil satu set persyaratan dan berikan ke dua tim. Ketika Anda bisa mengeluarkan hal yang sama (tanpa tim berbicara satu sama lain) Anda cukup dekat dengan teknik.

Bidang teknik lainnya juga memiliki penalti dan ulasan yang kaku serta ditandatangani. Akuntabilitas.

Tidak. Rekayasa Perangkat Lunak bukanlah rekayasa. Menurut saya, perbedaannya terletak pada jumlah kreativitas yang terlibat. Dalam Teknik Sipil, misalnya, mungkin ada sangat sedikit atau tidak ada kreativitas. Ini hal yang baik.

Untuk membangun jembatan, Anda memiliki seperangkat spesifikasi (saya perlu mendapatkan jumlah mobil ini dari sisi sungai ke sisi lainnya).

Dari sini, saya dapat menyimpulkan:

1. jumlah lajur jalan yang saya butuhkan (menggunakan perhitungan standar yang ditentukan oleh pemerintah);
2. beban yang saya perlukan untuk mendukung (menggunakan perhitungan yang ditentukan oleh pemerintah)
3. bahan-bahan yang perlu saya gunakan untuk mendukung muatan tersebut (menggunakan bahan standar, yang bisa saya dapatkan dari sejumlah pemasok yang berbeda, atau bahan-bahan non-standar, yang kemudian harus saya buktikan akan memiliki sifat yang benar).

Kemudian, saya harus mendapatkan desain disetujui dan diperiksa oleh pihak ketiga (perusahaan lain) untuk memastikan bahwa saya telah melakukan perhitungan saya dengan benar.

Kemudian, ketika jembatan benar-benar dibangun, pekerjaan akan dilakukan oleh orang-orang yang memenuhi syarat dengan cara standar. Mereka akan melakukan pekerjaan yang telah mereka lakukan ratusan, mungkin ribuan kali sebelumnya.

Jangan salah, setiap proyek teknik sipil berbeda, tetapi sepertinya setiap kali saya mengembangkan aplikasi / situs web baru, segala sesuatunya dilakukan secara berbeda.

Ya, saya rasa pengembangan itu adalah bagian dari rekayasa:

• Rekayasa perangkat lunak mencakup spesifikasi awal ("jenis perangkat lunak apa yang kita butuhkan di sini?"), Yang bisa dibilang mendahului pengembangan
• "Rekayasa" mungkin juga termasuk misalnya mendefinisikan Proses Jaminan Kualitas, yang tentunya terkait dengan pengembangan tetapi juga bisa dibilang di luar lingkup 'konstruksi' itu sendiri.

Code Complete mendefinisikan "konstruksi" sebagai sinonim dengan pengkodean dan debugging (dan komentar), juga dengan desain terperinci sebelumnya dan dengan pengujian unit dan integrasi sesudahnya. Bab 1, Selamat Datang di Konstruksi Perangkat Lunak (PDF) dimulai dengan mendaftar banyak topik dalam Siklus Hidup Pengembangan Perangkat Lunak secara keseluruhan (termasuk Definisi Masalah, Arsitektur Perangkat Lunak, Pemeliharaan Korektif, dll.), Dan kemudian berkata,

Seperti yang ditunjukkan oleh gambar, konstruksi sebagian besar adalah pengkodean dan debugging tetapi juga melibatkan desain terperinci, perencanaan konstruksi, pengujian unit, integrasi, pengujian integrasi, dan kegiatan lainnya. Jika ini adalah buku tentang semua aspek pengembangan perangkat lunak, itu akan menampilkan diskusi yang seimbang dari semua kegiatan dalam proses pengembangan. Karena ini adalah buku pegangan teknik konstruksi, ia menempatkan penekanan miring pada konstruksi dan hanya menyentuh pada topik terkait. Jika buku ini adalah seekor anjing, buku itu akan mengarah ke konstruksi, mengibaskan ekornya pada desain dan pengujian, dan menggonggong pada kegiatan pengembangan lainnya.

Pengembangan perangkat lunak adalah rekayasa.

Beberapa argumen yang dibuat oleh orang lain mengapa rekayasa perangkat lunak tidak memenuhi standar insinyur:

Ada yang mengatakan insinyur dalam bisnis merancang "hal-hal" untuk kepentingan publik - apakah ICBM, Tank, dll dalam kepentingan publik? Beberapa orang akan mengatakan ya (pelanggaran yang baik adalah pertahanan yang baik) yang lain akan mengatakan tidak. Namun, saya tidak berpikir ada orang yang akan tidak setuju bahwa orang yang merancang sistem penargetan tangki generasi berikutnya adalah seorang insinyur. Barang publik bisa subjektif. Bagaimanapun banyak perangkat lunak yang ada di barang publik sehingga intinya adalah diperdebatkan baik.

Yang lain mengatakan insinyur merancang mereka tidak membangun. Saya telah melihat beberapa komentar tipe "insinyur mesin tidak mengelas". Saya berpendapat bahwa insinyur mesin menghasilkan cetak biru - desain terperinci yang diterapkan oleh sesuatu yang lain. Jika seorang insinyur mekanik menghasilkan cetak biru dan memasukkannya ke mesin CNC apakah itu membuat mereka tidak lagi menjadi insinyur mekanik - karena mesin melakukan implementasi alih-alih seseorang? Saya berpendapat bahwa kode sumber adalah cetak biru terperinci yang diumpankan ke mesin yang melakukan implementasi dan saya gagal melihat bagaimana itu berbeda dari kode pemberian makan MechE ke mesin CNC. Dan kami sekarang memiliki printer 3d, apakah itu menandakan akhir dari insinyur mekanik? Apakah mereka sekarang pengembang mekanis?

Lisensi adalah topik lain yang saya lihat muncul. Saat ini hanya beberapa insinyur yurisdiksi lisensi perangkat lunak. Tidak ada (sejauh ini) ada lisensi luas AS untuk insinyur perangkat lunak (saya pikir hanya Texas yang melakukannya). Beberapa telah menggunakan ini sebagai alasan untuk menyatakan bahwa rekayasa perangkat lunak tidak boleh disebut rekayasa. PE untuk insinyur perangkat lunak akan datang. Tetapi pada tingkat yang lebih filosofis hanya karena beberapa legislator negara memilih (atau tidak) untuk memanggil rekayasa pengembangan perangkat lunak tidak berpengaruh pada kenyataan.