Lompat ke isi

Rekayasa perangkat lunak

Dari Wikipedia bahasa Indonesia, ensiklopedia bebas
(Dialihkan dari Teknik perangkat lunak)

Rekayasa perangkat lunak (bahasa Inggris: software engineering) adalah cabang dari ilmu komputer dan teknik yang berfokus pada perancangan, pengembangan, pengujian, dan pemeliharaan aplikasi perangkat lunak.[1] Bidang ini melibatkan penerapan prinsip-prinsip teknik dan keahlian pemrograman komputer untuk mengembangkan sistem perangkat lunak yang memenuhi kebutuhan pengguna.[2][3][4][5]

Ilustrasi diagram alir untuk pengembangan iteratif perangkat lunak

Seorang insinyur atau perekayasa perangkat lunak menerapkan proses pengembangan perangkat lunak[2][6] untuk mendefinisikan, mengimplementasikan, menguji, mengelola, dan memelihara sistem perangkat lunak.

Sejarah

[sunting | sunting sumber]

Dimulai pada tahun 1960-an, rekayasa perangkat lunak diakui sebagai bidang teknik yang terpisah.[7]

Perkembangan rekayasa perangkat lunak pada awalnya dipandang sebagai sebuah perjuangan. Masalah-masalah yang dihadapi meliputi perangkat lunak yang melebihi anggaran, melewati batas waktu, membutuhkan pengawakutuan (debugging) dan pemeliharaan yang ekstensif, serta tidak berhasil memenuhi kebutuhan konsumen atau bahkan tidak pernah selesai.

Pada tahun 1968, NATO menyelenggarakan konferensi pertama tentang rekayasa perangkat lunak, yang membahas tantangan-tantangan baru dalam pengembangan perangkat lunak dan memainkan peran penting dalam merumuskan pedoman serta praktik terbaik untuk menciptakan perangkat lunak yang andal dan mudah dipelihara.[8]

Asal-usul istilah software engineering dikaitkan dengan berbagai sumber. Istilah ini muncul dalam daftar layanan yang ditawarkan oleh perusahaan-perusahaan dalam majalah "Computers and Automation" edisi Juni 1965[9] dan digunakan secara lebih formal dalam majalah Communications of the ACM edisi Agustus 1966 (Volume 9, nomor 8) dalam tulisan "President's Letter to the ACM Membership" oleh Anthony A. Oettinger.[10][11][12] Istilah ini juga dikaitkan dengan judul konferensi NATO pada tahun 1968 oleh Profesor Friedrich L. Bauer.[13] Margaret Hamilton mendeskripsikan disiplin "rekayasa perangkat lunak" selama misi Apollo untuk memberikan legitimasi pada apa yang sedang mereka kerjakan.[14] Pada saat itu, dirasakan sedang terjadi "krisis perangkat lunak".[15][16][17] Konferensi Internasional Rekayasa Perangkat Lunak ke-40 (ICSE 2018) merayakan 50 tahun "Rekayasa Perangkat Lunak" dengan pidato utama Sidang Pleno oleh Frederick Brooks[18] dan Margaret Hamilton.[19]

Pada tahun 1984, Software Engineering Institute (SEI) didirikan sebagai pusat penelitian dan pengembangan yang didanai secara federal, yang berkantor pusat di kampus Universitas Carnegie Mellon di Pittsburgh, Pennsylvania, Amerika Serikat.[20] Watts Humphrey mendirikan Program Proses Perangkat Lunak SEI, yang bertujuan untuk memahami dan mengelola proses rekayasa perangkat lunak.[20] Tingkat Kematangan Proses yang diperkenalkan kemudian menjadi Capability Maturity Model Integration for Development (CMMI-DEV), yang menetapkan bagaimana Pemerintah AS mengevaluasi kemampuan tim pengembangan perangkat lunak.

Praktik terbaik rekayasa perangkat lunak modern yang diterima secara umum telah dikumpulkan oleh subkomite ISO/IEC JTC 1/SC 7 dan diterbitkan sebagai Software Engineering Body of Knowledge (SWEBOK).[6] Rekayasa perangkat lunak dianggap sebagai salah satu disiplin komputasi utama.[21]

Dalam sistem modern, di mana konsep seperti Komputasi Tepi (Edge Computing), Internet untuk Segala (Internet of Things), dan Sistem siber-fisik sangat umum, perangkat lunak menjadi faktor yang krusial. Oleh karena itu, rekayasa perangkat lunak terkait erat dengan disiplin rekayasa sistem. Menurut Systems Engineering Body of Knowledge:

Perangkat lunak menonjol dalam sebagian besar arsitektur sistem modern dan sering kali menjadi sarana utama untuk mengintegrasikan komponen sistem yang kompleks. Rekayasa perangkat lunak dan rekayasa sistem bukan sekadar disiplin ilmu yang saling terkait; keduanya sangat jalin-menjalin... Rekayasa sistem yang baik adalah faktor kunci dalam mewujudkan rekayasa perangkat lunak yang baik.

Terminologi

[sunting | sunting sumber]

Definisi

[sunting | sunting sumber]

Beberapa definisi penting mengenai rekayasa perangkat lunak meliputi:

  • "Penerapan pengetahuan ilmiah dan teknologi, metode, serta pengalaman secara sistematis untuk perancangan, implementasi, pengujian, dan dokumentasi perangkat lunak."—Biro Statistik Tenaga Kerja—IEEE Systems and software engineering – Vocabulary[22]
  • "Penerapan pendekatan yang sistematis, disiplin, dan terukur dalam pengembangan, pengoperasian, dan pemeliharaan perangkat lunak."—IEEE Standard Glossary of Software Engineering Terminology[23]
  • "Sebuah disiplin teknik yang berkaitan dengan semua aspek produksi perangkat lunak." — Ian Sommerville[24]
  • "Pembentukan dan penggunaan prinsip-prinsip teknik yang kuat untuk memperoleh perangkat lunak yang andal dan bekerja secara efisien pada mesin nyata secara ekonomis."—Fritz Bauer[25]
  • "Cabang ilmu komputer yang berkaitan dengan perancangan, implementasi, dan pemeliharaan program komputer yang kompleks."—Merriam-Webster[26]
  • "Rekayasa perangkat lunak mencakup bukan hanya tindakan menulis kode, melainkan semua alat dan proses yang digunakan organisasi untuk membangun dan memelihara kode tersebut dari waktu ke waktu. [...] Rekayasa perangkat lunak dapat dianggap sebagai 'pemrograman yang terintegrasi dari waktu ke waktu'."—Software Engineering di Google[27]

Istilah ini juga digunakan secara kurang formal:

  • Sebagai istilah kontemporer informal untuk berbagai aktivitas yang dulunya disebut pemrograman komputer dan analisis sistem[28]
  • Sebagai istilah luas untuk semua aspek praktik pemrograman komputer, berbeda dengan teori pemrograman komputer, yang dipelajari secara formal sebagai subdisiplin dari ilmu komputer[29]
  • Sebagai istilah yang mewujudkan advokasi pendekatan spesifik terhadap pemrograman komputer, yang mendesak agar pemrograman diperlakukan sebagai disiplin rekayasa dan bukan sebagai seni atau kerajinan, serta mengadvokasi kodifikasi praktik-praktik yang direkomendasikan[30]

Kesesuaian

[sunting | sunting sumber]

Para komentator memiliki perbedaan pendapat yang tajam mengenai cara mendefinisikan rekayasa perangkat lunak atau legitimasinya sebagai disiplin teknik. David Parnas menyatakan bahwa rekayasa perangkat lunak, pada kenyataannya, adalah suatu bentuk teknik.[31][32] Steve McConnell berpendapat bahwa bidang ini saat ini belum menjadi disiplin teknik, tetapi seharusnya menjadi seperti itu.[33] Donald Knuth menyatakan bahwa pemrograman adalah sebuah seni sekaligus sains.[34] Edsger W. Dijkstra mengklaim bahwa istilah rekayasa perangkat lunak dan insinyur perangkat lunak telah disalahgunakan di Amerika Serikat.[35]

Beban Kerja

[sunting | sunting sumber]

Analisis kebutuhan

[sunting | sunting sumber]

Rekayasa kebutuhan (requirements engineering) berkaitan dengan elisitasi, analisis, spesifikasi, dan validasi kebutuhan untuk perangkat lunak. Kebutuhan perangkat lunak dapat berupa kebutuhan fungsional, kebutuhan non-fungsional, atau kebutuhan domain.

Kebutuhan fungsional mendeskripsikan perilaku yang diharapkan (misalnya keluaran sistem). Kebutuhan non-fungsional menentukan aspek-aspek seperti portabilitas, keamanan, kemudahan pemeliharaan, keandalan, skalabilitas, kinerja, penggunaan kembali, dan fleksibilitas. Kebutuhan ini diklasifikasikan menjadi beberapa jenis: batasan antarmuka, batasan kinerja (seperti waktu respons, keamanan, ruang penyimpanan, dll.), batasan operasi, batasan siklus hidup (kemudahan pemeliharaan, portabilitas, dll.), dan batasan ekonomi. Pengetahuan tentang cara kerja sistem atau perangkat lunak sangat diperlukan saat menentukan kebutuhan non-fungsional. Kebutuhan domain berkaitan dengan karakteristik kategori atau domain proyek tertentu.[36]

Perancangan

[sunting | sunting sumber]

Perancangan perangkat lunak adalah proses membuat rencana tingkat tinggi untuk perangkat lunak. Perancangan terkadang dibagi menjadi beberapa tingkatan:

Konstruksi

[sunting | sunting sumber]

Konstruksi perangkat lunak biasanya melibatkan pemrograman (atau pengodean), pengujian unit, pengujian integrasi, dan pengawakutuan untuk mengimplementasikan hasil perancangan.[2][6] "Pengujian perangkat lunak terkait dengan, tetapi berbeda dari, ... pengawakutuan".[6]

Pengujian

[sunting | sunting sumber]

Pengujian perangkat lunak adalah penyelidikan empiris dan teknis yang dilakukan untuk memberikan informasi kepada pemangku kepentingan tentang kualitas perangkat lunak yang diuji.[2][6] Pengujian perangkat lunak dapat dipandang sebagai aktivitas berbasis risiko.

Ketika dijelaskan secara terpisah dari konstruksi, pengujian biasanya dilakukan oleh insinyur pengujian atau penjaminan kualitas (Quality Assurance) dan bukan oleh pemrogram yang menulis kodenya. Pengujian ini dilakukan pada tingkat sistem dan dianggap sebagai aspek dari kualitas perangkat lunak. Tujuan penguji selama proses pengujian adalah untuk meminimalkan jumlah total pengujian menjadi rangkaian yang dapat dikelola dan membuat keputusan yang tepat mengenai risiko mana yang harus diprioritaskan untuk diuji dan mana yang dapat ditunda.[38]

Analisis program

[sunting | sunting sumber]

Analisis program adalah proses menganalisis program komputer sehubungan dengan aspek-aspek seperti kinerja, ketahanan, dan keamanan.

Pemeliharaan

[sunting | sunting sumber]

Pemeliharaan perangkat lunak mengacu pada dukungan terhadap perangkat lunak setelah dirilis. Hal ini dapat mencakup tetapi tidak terbatas pada: perbaikan kesalahan, optimalisasi, penghapusan fitur yang tidak digunakan atau dibuang, dan peningkatan fitur yang sudah ada.[2][6]

Biasanya, pemeliharaan memakan biaya 40% hingga 80% dari total biaya proyek.[39]

Pendidikan

[sunting | sunting sumber]
Perguruan tinggi ilmu komputer terbaik di Amerika Utara

Pengetahuan tentang pemrograman komputer merupakan prasyarat untuk menjadi seorang insinyur perangkat lunak. Pada tahun 2004, IEEE Computer Society menyusun SWEBOK, yang telah diterbitkan sebagai Laporan Teknis ISO/IEC 1979:2005, yang mendeskripsikan kumpulan pengetahuan yang direkomendasikan untuk dikuasai oleh seorang lulusan rekayasa perangkat lunak dengan pengalaman empat tahun.[40] Banyak insinyur perangkat lunak memasuki profesi ini dengan memperoleh gelar universitas atau pelatihan di sekolah vokasi. Salah satu kurikulum internasional standar untuk gelar sarjana rekayasa perangkat lunak ditetapkan oleh Joint Task Force on Computing Curricula dari IEEE Computer Society dan Association for Computing Machinery, dan diperbarui pada tahun 2014.[21] Sejumlah universitas memiliki program studi Rekayasa Perangkat Lunak; per tahun 2010, terdapat 244 program Sarjana Rekayasa Perangkat Lunak di kampus, 70 program daring, 230 program tingkat Magister, 41 program tingkat Doktor, dan 69 program tingkat Sertifikat di Amerika Serikat.

Selain pendidikan universitas, banyak perusahaan mensponsori program magang bagi mahasiswa yang ingin mengejar karier di bidang teknologi informasi. Magang ini dapat mengenalkan mahasiswa pada tugas-tugas dunia nyata yang dihadapi oleh insinyur perangkat lunak setiap hari. Pengalaman serupa juga dapat diperoleh melalui dinas militer di bidang rekayasa perangkat lunak.

Program studi rekayasa perangkat lunak

[sunting | sunting sumber]

Sebagian kecil praktisi yang terus berkembang memiliki gelar di bidang rekayasa perangkat lunak. Pada tahun 1987, Departemen Komputasi di Imperial College London memperkenalkan program sarjana rekayasa perangkat lunak tiga tahun pertama di dunia; pada tahun berikutnya, Universitas Sheffield mendirikan program serupa.[41] Pada tahun 1996, Institut Teknologi Rochester mendirikan program sarjana rekayasa perangkat lunak pertama di Amerika Serikat; namun, program tersebut baru mendapatkan akreditasi ABET pada tahun 2003, tahun yang sama dengan Universitas Rice, Universitas Clarkson, Sekolah Teknik Milwaukee, dan Universitas Negeri Mississippi.[42]

Sejak saat itu, gelar sarjana rekayasa perangkat lunak telah didirikan di banyak universitas. Kurikulum internasional standar untuk gelar sarjana rekayasa perangkat lunak, SE2004, ditetapkan oleh komite pengarah antara tahun 2001 dan 2004 dengan pendanaan dari Association for Computing Machinery dan IEEE Computer Society. Per tahun 2004, sekitar 50 universitas di AS menawarkan gelar rekayasa perangkat lunak, yang mengajarkan prinsip-prinsip serta praktik ilmu komputer dan teknik. Gelar magister rekayasa perangkat lunak pertama didirikan di Universitas Seattle pada tahun 1979. Sejak saat itu, gelar pascasarjana rekayasa perangkat lunak telah tersedia di lebih banyak universitas. Demikian pula di Kanada, Canadian Engineering Accreditation Board (CEAB) dari Canadian Council of Professional Engineers telah mengakui beberapa program rekayasa perangkat lunak.

Selain itu, banyak gelar lanjutan daring dalam Rekayasa Perangkat Lunak telah muncul seperti gelar Master of Science in Software Engineering (MSE) yang ditawarkan melalui Departemen Ilmu Komputer dan Rekayasa di Universitas Negeri California, Fullerton. Steve McConnell berpendapat bahwa karena sebagian besar universitas mengajarkan ilmu komputer daripada rekayasa perangkat lunak, terjadi kelangkaan insinyur perangkat lunak sejati.[43] Universitas ETS (École de technologie supérieure) dan UQAM (Université du Québec à Montréal) dimandatkan oleh IEEE untuk mengembangkan Software Engineering Body of Knowledge (SWEBOK), yang telah menjadi standar ISO yang mendeskripsikan kumpulan pengetahuan yang dicakup oleh seorang insinyur perangkat lunak.[6]

Profesi

[sunting | sunting sumber]

Persyaratan hukum untuk pemberian izin atau sertifikasi insinyur perangkat lunak profesional bervariasi di seluruh dunia. Di Inggris, tidak ada persyaratan izin atau hukum untuk menyandang atau menggunakan gelar pekerjaan Insinyur Perangkat Lunak. Di beberapa wilayah Kanada, seperti Alberta, British Columbia, Ontario,[44] dan Quebec, insinyur perangkat lunak dapat memegang gelar Professional Engineer (P.Eng) dan/atau gelar Information Systems Professional (I.S.P.). Di Eropa, Insinyur Perangkat Lunak dapat memperoleh gelar profesional European Engineer (EUR ING). Insinyur Perangkat Lunak juga dapat berkualifikasi secara profesional sebagai Chartered Engineer melalui British Computer Society.

Di Amerika Serikat, NCEES mulai menawarkan ujian Professional Engineer untuk Rekayasa Perangkat Lunak pada tahun 2013, sehingga memungkinkan Insinyur Perangkat Lunak untuk dilisensikan dan diakui.[45] NCEES menghentikan ujian tersebut setelah April 2019 karena kurangnya partisipasi.[46] Perizinan wajib saat ini masih banyak diperdebatkan dan dianggap kontroversial.[47][48]

IEEE Computer Society dan ACM, dua organisasi profesional utama rekayasa perangkat lunak yang berbasis di AS, menerbitkan panduan untuk profesi rekayasa perangkat lunak. Panduan IEEE untuk Guide to the Software Engineering Body of Knowledge – 2004 Version, atau SWEBOK, mendefinisikan bidang tersebut dan mendeskripsikan pengetahuan yang diharapkan dimiliki oleh seorang insinyur perangkat lunak praktisi oleh IEEE. Versi terbaru adalah SWEBOK v4.[6] IEEE juga menyebarluaskan "Kode Etik Rekayasa Perangkat Lunak".[49]

Ketenagakerjaan

[sunting | sunting sumber]

Diperkirakan terdapat 26,9 juta insinyur perangkat lunak profesional di dunia pada tahun 2022, naik dari 21 juta pada tahun 2016.[50][51]

Banyak insinyur perangkat lunak bekerja sebagai karyawan atau kontraktor. Insinyur perangkat lunak bekerja dengan bisnis, lembaga pemerintah (sipil atau militer), dan organisasi nirlaba. Beberapa insinyur perangkat lunak bekerja untuk diri mereka sendiri sebagai pekerja lepas (freelancer). Beberapa organisasi memiliki spesialis untuk melakukan setiap tugas dalam proses pengembangan perangkat lunak. Organisasi lain mengharuskan insinyur perangkat lunak untuk melakukan banyak atau semua tugas tersebut. Dalam proyek besar, orang mungkin berspesialisasi hanya dalam satu peran. Dalam proyek kecil, orang dapat mengisi beberapa atau semua peran secara bersamaan. Banyak perusahaan mempekerjakan pemagang, sering kali mahasiswa universitas atau perguruan tinggi selama liburan musim panas. Spesialisasi meliputi analis, arsitek, pengembang, penguji, dukungan teknis, analis middleware, manajer proyek, manajer produk perangkat lunak, pendidik, dan peneliti.

Sebagian besar insinyur perangkat lunak dan pemrogram bekerja 40 jam seminggu, tetapi sekitar 15 persen insinyur perangkat lunak dan 11 persen pemrogram bekerja lebih dari 50 jam seminggu pada tahun 2008.[52] Potensi cedera dalam pekerjaan ini dapat terjadi karena seperti pekerja lain yang menghabiskan waktu lama duduk di depan terminal komputer mengetik di keyboard, insinyur dan pemrogram rentan terhadap kelelahan mata, ketidaknyamanan punggung, Trombosis, Obesitas, serta masalah tangan dan pergelangan tangan seperti sindrom terowongan karpal.[53]

Amerika Serikat

[sunting | sunting sumber]

U.S. Bureau of Labor Statistics (BLS) mencatat 1.365.500 pengembang perangkat lunak yang memegang pekerjaan di AS pada tahun 2018.[54] Karena relatif barunya bidang studi ini, pendidikan formal dalam rekayasa perangkat lunak sering kali diajarkan sebagai bagian dari kurikulum ilmu komputer, dan banyak insinyur perangkat lunak memegang gelar ilmu komputer.[55] BLS memperkirakan pertumbuhan untuk insinyur perangkat lunak dari tahun 2024 hingga 2034 adalah 15%, yang lebih rendah dari prediksi mereka dari tahun 2023 hingga 2033 bahwa rekayasa perangkat lunak komputer akan meningkat sebesar 17%.[56] Angka ini turun dari perkiraan BLS tahun 2022 hingga 2032 sebesar 25% untuk rekayasa perangkat lunak.[56][57] Dan, turun lebih jauh dari perkiraan BLS tahun 2010 hingga 2020 sebesar 30%.[58] Karena tren ini, pertumbuhan pekerjaan mungkin tidak secepat dekade lalu, karena pekerjaan yang seharusnya diberikan kepada insinyur perangkat lunak komputer di Amerika Serikat dialihdayakan ke insinyur perangkat lunak komputer di negara-negara seperti India dan negara asing lainnya.[59][52] Selain itu, Prospek Pekerjaan BLS untuk Pemrogram Komputer memprediksi penurunan sebesar -7 persen dari tahun 2016 hingga 2026, penurunan lebih lanjut sebesar -9 persen dari tahun 2019 hingga 2029, penurunan sebesar -10 persen dari tahun 2021 hingga 2031,[59] dan kemudian penurunan sebesar -11 persen dari tahun 2022 hingga 2032.[59] Saat ini prediksi mereka untuk tahun 2024 hingga 2034 adalah penurunan sebesar -6 persen. Karena pemrograman komputer dapat dilakukan dari mana saja di dunia, perusahaan terkadang mempekerjakan pemrogram di negara-negara dengan upah yang lebih rendah.[59][60][61] Lebih jauh lagi, rasio perempuan di banyak bidang perangkat lunak juga mengalami penurunan selama bertahun-tahun dibandingkan dengan bidang teknik lainnya.[62][63] Kemudian ada kekhawatiran tambahan bahwa kemajuan terkini dalam Kecerdasan Buatan mungkin berdampak pada permintaan generasi Insinyur Perangkat Lunak di masa depan.[64][65][66][67][68][69][70] Namun, tren ini mungkin berubah atau melambat di masa depan karena banyak insinyur perangkat lunak saat ini di pasar AS meninggalkan profesi tersebut atau keluar dari pasar karena usia dalam beberapa dekade mendatang.[59][71]

Sertifikasi

[sunting | sunting sumber]

Software Engineering Institute menawarkan sertifikasi pada topik-topik khusus seperti keamanan, peningkatan proses, dan arsitektur perangkat lunak.[72] IBM, Microsoft, dan perusahaan lain juga mensponsori ujian sertifikasi mereka sendiri. Banyak program sertifikasi TI berorientasi pada teknologi tertentu, dan dikelola oleh vendor teknologi tersebut.[73] Program sertifikasi ini disesuaikan dengan institusi yang akan mempekerjakan orang-orang yang menggunakan teknologi tersebut.

Sertifikasi yang lebih luas untuk keterampilan rekayasa perangkat lunak umum tersedia melalui berbagai asosiasi profesional. Per tahun 2006, IEEE telah menyertifikasi lebih dari 575 profesional perangkat lunak sebagai Certified Software Development Professional (CSDP).[74] Pada tahun 2008 mereka menambahkan sertifikasi tingkat pemula yang dikenal sebagai Certified Software Development Associate (CSDA).[75] ACM dan IEEE Computer Society bersama-sama mengkaji kemungkinan pemberian izin bagi insinyur perangkat lunak sebagai Professional Engineer pada tahun 1990-an, tetapi akhirnya memutuskan bahwa pemberian izin tersebut tidak sesuai untuk praktik industri profesional rekayasa perangkat lunak.[47] John C. Knight dan Nancy G. Leveson menyajikan analisis yang lebih berimbang mengenai masalah perizinan ini pada tahun 2002.[48]

Di Inggris, British Computer Society telah mengembangkan sertifikasi profesional yang diakui secara hukum yang disebut Chartered IT Professional (CITP), yang tersedia bagi anggota yang berkualifikasi penuh (MBCS). Insinyur perangkat lunak mungkin memenuhi syarat untuk menjadi anggota British Computer Society atau Institution of Engineering and Technology sehingga memenuhi syarat untuk dipertimbangkan mendapatkan status Chartered Engineer melalui salah satu dari institusi tersebut. Di Kanada, Canadian Information Processing Society telah mengembangkan sertifikasi profesional yang diakui secara hukum yang disebut Information Systems Professional (ISP).[76] Di Ontario, Kanada, Insinyur Perangkat Lunak yang lulus dari program terakreditasi Canadian Engineering Accreditation Board (CEAB), berhasil menyelesaikan Professional Practice Examination (PPE) dari PEO (Professional Engineers Ontario), dan memiliki setidaknya 48 bulan pengalaman teknik yang dapat diterima, memenuhi syarat untuk dilisensikan melalui Professional Engineers Ontario dan dapat menjadi Professional Engineers P.Eng.[77] PEO tidak mengakui pendidikan daring atau jarak jauh apa pun; dan tidak menganggap program Ilmu Komputer setara dengan program rekayasa perangkat lunak meskipun ada tumpang tindih yang sangat besar antara keduanya. Hal ini memicu kontroversi dan perang sertifikasi. Hal ini juga menyebabkan jumlah pemegang gelar P.Eng untuk profesi ini sangat rendah. Sebagian besar profesional yang bekerja di bidang ini memegang gelar dalam CS (Ilmu Komputer), bukan SE (Rekayasa Perangkat Lunak). Mengingat jalur sertifikasi yang sulit bagi pemegang gelar non-SE, sebagian besar dari mereka tidak pernah repot-repot mengejar lisensi tersebut.

Dampak globalisasi

[sunting | sunting sumber]

Dampak awal dari alih daya (outsourcing), dan biaya sumber daya manusia internasional yang relatif lebih rendah di negara-negara berkembang dunia ketiga menyebabkan migrasi besar-besaran aktivitas pengembangan perangkat lunak dari korporasi di Amerika Utara dan Eropa ke India, dan kemudian: Tiongkok, Rusia, serta negara berkembang lainnya. Pendekatan ini memiliki beberapa kelemahan, terutama perbedaan jarak / zona waktu yang menghalangi interaksi manusia antara klien dan pengembang serta transfer pekerjaan besar-besaran. Hal ini berdampak negatif pada banyak aspek profesi rekayasa perangkat lunak. Sebagai contoh, beberapa mahasiswa di negara maju menghindari pendidikan yang berkaitan dengan rekayasa perangkat lunak karena takut akan alih daya lepas pantai (offshore outsourcing—mengimpor produk atau layanan perangkat lunak dari negara lain) dan digantikan oleh pekerja visa asing.[78] Selain itu, kelebihan pekerja teknologi tinggi telah menyebabkan adopsi yang lebih luas dari sistem jam kerja 996 dan jadwal '007' sebagai beban kerja yang diharapkan.[79] Meskipun statistik saat ini tidak menunjukkan ancaman terhadap rekayasa perangkat lunak itu sendiri; karier terkait, yaitu pemrograman komputer, tampaknya telah terpengaruh.[80] Namun demikian, kemampuan untuk memanfaatkan sumber daya lepas pantai dan dekat pantai secara cerdas melalui alur kerja mengikuti matahari (follow-the-sun) telah meningkatkan kapabilitas operasional keseluruhan dari banyak organisasi.[81] Ketika orang Amerika Utara pulang kerja, orang Asia baru saja tiba untuk bekerja. Ketika orang Asia pulang kerja, orang Eropa tiba untuk bekerja. Ini memberikan kemampuan berkelanjutan untuk memiliki pengawasan manusia pada proses penting bisnis 24 jam per hari, tanpa membayar kompensasi lembur atau mengganggu sumber daya manusia yang penting, yaitu pola tidur.

Meskipun alih daya global memiliki beberapa keuntungan, pengembangan global—dan umumnya terdistribusi—dapat menghadapi kesulitan serius yang diakibatkan oleh jarak antar pengembang. Hal ini disebabkan oleh elemen-elemen kunci dari jenis jarak ini yang telah diidentifikasi sebagai geografis, temporal, kultural, dan komunikasi (yang mencakup penggunaan bahasa dan dialek bahasa Inggris yang berbeda di lokasi yang berbeda).[82] Penelitian telah dilakukan di bidang pengembangan perangkat lunak global selama 15 tahun terakhir dan kumpulan karya relevan yang ekstensif telah diterbitkan yang menyoroti manfaat dan masalah yang terkait dengan aktivitas kompleks tersebut. Seperti aspek rekayasa perangkat lunak lainnya, penelitian masih terus berlanjut di bidang ini dan bidang terkait.

Penghargaan

[sunting | sunting sumber]

Terdapat berbagai penghargaan di bidang rekayasa perangkat lunak:

  • ACM-AAAI Allen Newell Award- AS. Diberikan untuk kontribusi karier yang memiliki keluasan dalam ilmu komputer, atau yang menjembatani ilmu komputer dan disiplin ilmu lainnya.
  • BCS Lovelace Medal. Diberikan kepada individu yang telah memberikan kontribusi luar biasa dalam pemahaman atau kemajuan komputasi.
  • ACM SIGSOFT Outstanding Research Award, dipilih untuk individu yang telah memberikan "kontribusi signifikan dan langgeng dalam penelitian bagi teori atau praktik rekayasa perangkat lunak."[83]
  • Lebih banyak ACM SIGSOFT Awards.[84]
  • Codie award, penghargaan tahunan yang dikeluarkan oleh Software and Information Industry Association untuk keunggulan dalam pengembangan perangkat lunak di dalam industri perangkat lunak.
  • Harlan Mills Award untuk "kontribusi pada teori dan praktik ilmu informasi, yang berfokus pada rekayasa perangkat lunak".
  • ICSE Most Influential Paper Award.[85]
  • Jolt Award, juga untuk industri perangkat lunak.
  • Stevens Award diberikan untuk mengenang Wayne Stevens.

Kritik

[sunting | sunting sumber]

Beberapa pihak menyerukan perizinan, sertifikasi, dan kodifikasi kumpulan pengetahuan sebagai mekanisme untuk menyebarkan pengetahuan teknik dan mematangkan bidang ini.[86]

Beberapa pihak mengklaim bahwa konsep rekayasa perangkat lunak masih sangat baru sehingga jarang dipahami, dan banyak disalahtafsirkan, termasuk dalam buku teks rekayasa perangkat lunak, makalah, dan di antara komunitas pemrogram serta pengrajin kode.[87]

Beberapa pihak mengklaim bahwa masalah inti dalam rekayasa perangkat lunak adalah bahwa pendekatannya kurang empiris karena validasi dunia nyata dari pendekatan tersebut biasanya tidak ada, atau sangat terbatas, dan karenanya rekayasa perangkat lunak sering kali disalahtafsirkan sebagai hal yang layak hanya dalam "lingkungan teoretis."[87]

Edsger Dijkstra, penemu banyak konsep dalam pengembangan perangkat lunak saat ini, menolak gagasan "rekayasa perangkat lunak" hingga kematiannya pada tahun 2002, dengan argumen bahwa istilah-istilah tersebut merupakan analogi yang buruk untuk apa yang disebutnya sebagai "kebaruan radikal" dari ilmu komputer:

Sejumlah fenomena ini telah dibundel dengan nama "Rekayasa Perangkat Lunak". Sebagaimana ekonomi dikenal sebagai "Ilmu yang Sengsara", rekayasa perangkat lunak harus dikenal sebagai "Disiplin yang Ditakdirkan Gagal", ditakdirkan gagal karena bahkan tidak dapat mendekati tujuannya karena tujuannya itu sendiri kontradiktif. Rekayasa perangkat lunak, tentu saja, menampilkan dirinya sebagai tujuan mulia lainnya, tetapi itu adalah omong kosong: jika Anda membaca literaturnya dengan cermat dan menganalisis apa yang sebenarnya dilakukan oleh para penganutnya, Anda akan menemukan bahwa rekayasa perangkat lunak telah menerima piagamnya sebagai "Bagaimana cara memprogram jika Anda tidak bisa."[88]

Lihat pula

[sunting | sunting sumber]

Studi dan praktik

[sunting | sunting sumber]

Peran

[sunting | sunting sumber]

Aspek profesional

[sunting | sunting sumber]

Referensi

[sunting | sunting sumber]

Kutipan

[sunting | sunting sumber]
  1. ↑ "What is Software Engineering?". Michigan Technological University (dalam bahasa Inggris). Diakses tanggal 2025-06-29.
  2. 1 2 3 4 5 Abran et al. 2004
  3. ↑ ACM (2007). "Computing Degrees & Careers". ACM. Diarsipkan dari asli tanggal 2011-06-17. Diakses tanggal 2010-11-23.
  4. ↑ Laplante, Phillip (2007). What Every Engineer Should Know about Software Engineering. Boca Raton: CRC. ISBN 978-0-8493-7228-5. Diakses tanggal 2011-01-21.
  5. ↑ "What Does a Software Engineer Do?". coursera. Oct 31, 2022.
  6. 1 2 3 4 5 6 7 8 Bourque, Pierre; Fairley, Richard E. (Dick), ed. (2014). Guide to the Software Engineering Body of Knowledge Version 3.0 (SWEBOK). IEEE Computer Society.
  7. ↑ Farone, Alison (2020-08-04). "The history of coding and software engineering". Hack Reactor (dalam bahasa American English). Diakses tanggal 2025-06-29.
  8. ↑ "The history of coding and software engineering". Hack Reactor. Diarsipkan dari asli tanggal 2022-03-24. Diakses tanggal 2021-05-06.
  9. ↑ "Computers and Automation: The Computer Directory and Buyers' Guide, 1965" (PDF). bitsavers.org. Diakses tanggal 15 July 2023.
  10. ↑ "President's Letter to the ACM Membership" (PDF). Diakses tanggal 27 February 2025. We must recognize ourselves -- not necessarily all of us, and not necessarily any one of us all the time -- as members of an engineering profession, be it hardware engineering or software engineering, a profession without artificial and irrelevant boundaries like that between "scientific" and "business" applications.
  11. ↑ Oettinger, A. G. (1966). "President's Letter to the ACM Membership". Commun. ACM. 9 (8). Association for Computing Machinery: 545–546. doi:10.1145/365758.3291288. ISSN 0001-0782. S2CID 53432801.
  12. ↑ "The origin of "software engineering"". 4 April 2013. Diakses tanggal 17 November 2017.
  13. ↑ Randall, Brian. "The 1968/69 NATO Software Engineering Reports". Diakses tanggal 17 November 2017.
  14. ↑ Lori Cameron (October 5, 2008). "Margaret Hamilton: First Software Engineer". Tech News. IEEE Computer Society.
  15. ↑ Ian Sommerville (March 24, 2015). Software Engineering (Edisi 10th). Pearson Education Limited. ISBN 978-0-13-394303-0.
  16. ↑ Peter, Naur; Randell, Brian (7–11 October 1968). Software Engineering: Report of a conference sponsored by the NATO Science Committee (PDF). Garmisch, Germany: Scientific Affairs Division, NATO. Diakses tanggal 2008-12-26.
  17. ↑ Randell, Brian (10 August 2001). "The 1968/69 NATO Software Engineering Reports". Brian Randell's University Homepage. The School of the Computer Sciences, Newcastle University. Diakses tanggal 2008-10-11. The idea for the first NATO Software Engineering Conference, and in particular that of adopting the then practically unknown term "software engineering" as its (deliberately provocative) title, I believe came originally from Professor Fritz Bauer.
  18. ↑ 2018 International Conference on Software Engineering celebrating its 40th anniversary, and 50 years of Software engineering (31 May 2018). "ICSE 2018 – Plenary Sessions – Fred Brooks". YouTube. Diakses tanggal 9 August 2018. Pemeliharaan CS1: Nama numerik: authors list (link)
  19. ↑ 2018 International Conference on Software Engineering celebrating its 40th anniversary, and 50 years of Software engineering (31 May 2018). "ICSE 2018 – Plenary Sessions – Margaret Hamilton". YouTube. Diakses tanggal 9 August 2018. Pemeliharaan CS1: Nama numerik: authors list (link)
  20. 1 2 Linda Hutz Pesante (January 1, 2003). Anthony Ralston; Edwin D. Reilly (ed.). "Software engineering institute (SEI)". Encyclopedia of Computer Science. Chichester, West Sussex, UK: John Wiley and Sons Ltd.: 1611–1613. ISBN 978-0-470-86412-8. (1) The institute was competitively awarded to Carnegie Mellon in December 1984 by the US Department of Defense (DoD) to improve the state of the practice of software engineering. ... (2) the SEI moves mature solutions of proven value into widespread use; examples include the Capability Maturity Model (CMM) ... Ikon gembok hijau terbuka
  21. 1 2 Joint Task Force on Computing Curricula, IEEE Computer Society, Association for Computing Machinery (23 February 2015). Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (PDF). A Volume of the Computing Curricula Series. IEEE Computer Society and Association for Computing Machinery. Pemeliharaan CS1: Banyak nama: authors list (link)
  22. ↑ Systems and software engineering – Vocabulary, ISO/IEC/IEEE std 24765:2010(E), 2010.
  23. ↑ IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
  24. ↑ Sommerville, Ian (2007) [1982]. "1.1.2 What is software engineering?". Software Engineering (Edisi 8th). Harlow, England: Pearson Education. hlm. 7. ISBN 978-0-321-31379-9. Software engineering is an engineering discipline that is concerned with all aspects of software production, from the early stages of system specification to maintaining the system after it has gone into use. The definition highlights two key ideas: (1) engineering discipline—the application of theories, methods, and tools within organizational and financial constraints; and (2) all aspects of software production—including technical development processes, project management, and the creation of supporting tools, methods, and theories.
  25. ↑ "Software Engineering". Information Processing. 71: 530–538.
  26. ↑ "Definition of SOFTWARE ENGINEERING". www.merriam-webster.com (dalam bahasa Inggris). Diakses tanggal 2019-11-25.
  27. ↑ Winters, Titus; Manshrec, Tom; Wright, Hyrum (2020). "Preface, Programming Over Time". Software Engineering at Google. O'Reilly Media, Inc. hlm. xix–xx, 6–7. ISBN 978-1-492-08279-8. We propose that "software engineering" encompasses not just the act of writing code, but all of the tools and processes an organization uses to build and maintain that code over time. What practices can a software organization introduce that will best keep its code valuable over the long term? How can engineers make a codebase more sustainable and the software engineering discipline itself more rigorous?
  28. ↑ Akram I. Salah (2002-04-05). "Engineering an Academic Program in Software Engineering" (PDF). 35th Annual Midwest Instruction and Computing Symposium. Diakses tanggal 2006-09-13.: "For some, software engineering is just a glorified name for programming. If you are a programmer, you might put 'software engineer' on your business card—never 'programmer' though."
  29. ↑ Mills, Harlan D., J. R. Newman, and C. B. Engle, Jr., "An Undergraduate Curriculum in Software Engineering," in Deimel, Lionel E. (1990). Software Engineering Education: SEI Conference 1990, Pittsburgh, Pennsylvania, USA, April 2–3,... Springer. ISBN 978-0-387-97274-9.,p. 26: "As a practical matter, we regard software engineering as the necessary preparation for the practicing, software development and maintenance professional. The Computer Scientist is preparing for further theoretical studies..."
  30. ↑ Barbara Kitchevnham; David Budgen; Pearl Brereton; Stephen Linkman (2005). "Realising evidence-based software engineering". ACM SIGSOFT Software Engineering Notes. 30 (4): 1–3. doi:10.1145/1082983.1083175. We believe that software engineering can only advance as an engineering discipline by moving away from its current dependence upon advocacy and analysis, ...
  31. ↑ Parnas, David L. (1998). "Software Engineering Programmes are not Computer Science Programmes". Annals of Software Engineering. 6 (1–4): 19–37. doi:10.1023/A:1018949113292. S2CID 35786237., p. 19: "Rather than treat software engineering as a subfield of computer science, I treat it as an element of the set, {Civil Engineering, Mechanical Engineering, Chemical Engineering, Electrical Engineering,....}."
  32. ↑ Parnas, David L. (1998). "Software Engineering Programmes are not Computer Science Programmes". Annals of Software Engineering. 6 (1–4): 19–37. doi:10.1023/A:1018949113292. S2CID 35786237., p. 20: "This paper argues that the introduction of accredited professional programs in software engineering, programmes that are modelled on programmes in traditional engineering disciplines will help to increase both the quality and quantity of graduates who are well prepared, by their education, to develop trustworthy software products."
  33. ↑ McConnell, Steve (August 2003). Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers. Boston, MA: Addison-Wesley. ISBN 0-321-19367-9., p. 39: "In my opinion, the answer to that question is clear: Professional software development should be engineering. Is it? No. But should it be? Unquestionably, yes. "
  34. ↑ Knuth, Donald (1974). "Computer Programming as an Art" (PDF). Communications of the ACM. 17 (12): 667–673. doi:10.1145/361604.361612. S2CID 207685720.
  35. ↑ Dijkstra, Edsger W; transcribed by Mario Béland (November 23, 2004) [First published December 3, 1993]. "There is still a war going on (manuscript Austin, 3 December 1993)". E. W. Dijkstra Archive. The University of Texas at Austin, Department of Computer Sciences. Diakses tanggal February 17, 2007. When the term was coined in 1968 by F.L. Bauer of the Technological University of Munich, I welcomed it. [. . .] I interpreted the introduction of the term "software engineering" as an apt reflection of the fact that the design of software systems was an activity par excellence for the mathematical engineer. [. . .]. As soon the term arrived in the USA, it was relieved of all its technical content. It had to be so for in its original meaning it was totally unacceptable [. . .] In the meantime, software engineering has become an almost empty term, as was nicely demonstrated by Data General who overnight promoted all its programmers to the exalted rank of "software engineer"!
  36. ↑ "Software Engineering | Classification of Software Requirements". GeeksforGeeks (dalam bahasa American English). 2018-06-19. Diakses tanggal 2021-05-06.
  37. ↑ "Software Engineering | Software Design Process". GeeksforGeeks (dalam bahasa American English). 2019-05-24. Diakses tanggal 2021-05-06.
  38. ↑ Jamil, Muhammad Abid; Arif, Muhammad; Abubakar, Normi Sham Awang; Ahmad, Akhlaq (November 2016). "Software Testing Techniques: A Literature Review". 2016 6th International Conference on Information and Communication Technology for the Muslim World (ICT4M). hlm. 177–182. doi:10.1109/ICT4M.2016.045. ISBN 978-1-5090-4521-1.
  39. ↑ "What is Software Maintenance? Definition of Software Maintenance, Software Maintenance Meaning". The Economic Times. Diakses tanggal 2021-05-06.
  40. ↑ Alain Abran; James W. Moore; Pierre Bourque; Robert Dupuis; Leonard L. Tripp, ed. (2005) [2004]. "Chapter 1: Introduction to the Guide". Guide to the Software Engineering Body of Knowledge. IEEE Computer Society. Diarsipkan dari asli tanggal 2016-05-09. Diakses tanggal 2010-09-13. The total volume of cited literature is intended to be suitable for mastery through the completion of an undergraduate education plus four years of experience.
  41. ↑ Cowling, A. J. 1999. The first decade of an undergraduate degree program in software engineering. Ann. Softw. Eng. 6, 1–4 (Apr. 1999), 61–90.
  42. ↑ "ABET Accredited Engineering Programs". April 3, 2007. Diarsipkan dari asli tanggal June 19, 2010. Diakses tanggal April 3, 2007.
  43. ↑ McConnell, Steve (July 10, 2003). Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers. ISBN 978-0-321-19367-4.
  44. ↑ Williams, N.S.W. (19–21 February 2001). "Professional Engineers Ontario's approach to licensing software engineering practitioners". Software Engineering Education and Training, 2001 Proceedings. 14th Conference on. Charlotte, NC: IEEE. hlm. 77–78.
  45. ↑ "NCEES Software Engineering Exam Specifications" (PDF). Diarsipkan dari asli (PDF) tanggal 2013-08-27. Diakses tanggal 2012-04-01.
  46. ↑ "NCEES discontinuing PE Software Engineering exam". National Council of Examiners for Engineering and Surveying. 13 March 2018. Diakses tanggal 6 August 2018.
  47. 1 2 Barbara Simons. "Past ACM Presidents Reflect on Their Service to ACM". Celebrating 75 Years of Advancing Computing as a Science & Profession. Association for Computing Machinery. Diakses tanggal May 18, 2024. After the panels' recommendations were submitted, ACM Council concluded that the framework of a licensed professional engineer, originally developed for civil engineers, does not match the professional industrial practice of software engineering and would preclude many of the most qualified software engineers from becoming licensed.
  48. 1 2 John C. Knight; Nancy G. Leveson (November 1, 2002). "Should software engineers be licensed?". Communications of the ACM. 45 (11): 87–90. doi:10.1145/581571.581601.
  49. ↑ "Software Engineering Code of Ethics" (PDF). Diarsipkan dari asli (PDF) tanggal 2015-01-23. Diakses tanggal 2012-03-25.
  50. ↑ Labs, Qubit (29 November 2022). "How Many Programmers are there in the World and in the US? [2023]". Qubit Labs. Diakses tanggal 7 February 2023.
  51. ↑ "Global Developer Population and Demographic Study 2016 V2". Evans Data Corporation. Diakses tanggal 19 January 2017.
  52. 1 2 Rosenthal, Rachel (August 4, 2020). "Tech Companies Want You to Believe America Has a Skills Gap". Bloomberg. Diakses tanggal October 8, 2021.
  53. ↑ "Computer Software Engineers and Computer Programmers". Diakses tanggal 2009-12-17.
  54. ↑ "Software Developers". Occupational Outlook Handbook. U. S. Bureau of labor Statistics. 4 September 2019. Diakses tanggal 11 December 2019.
  55. ↑ "Computing Disciplines and Majors" (PDF). Association for Computing Machinery. Diakses tanggal 6 September 2019.
  56. 1 2 Kesalahan pengutipan: Tanda <ref> tidak sah; tidak ditemukan teks untuk ref bernama softdev
  57. ↑ "Computer Software Engineer". Bureau of Labor Statistics. March 19, 2010. Diarsipkan dari asli tanggal July 26, 2013. Diakses tanggal July 20, 2012.
  58. ↑ "Software Developers". Bureau of Labor Statistics. January 8, 2014. Diakses tanggal July 21, 2012.
  59. 1 2 3 4 5 "Computer Programmers : Occupational Outlook Handbook: : U.S. Bureau of Labor Statistics". Diarsipkan dari versi aslinya tanggal 3 May 2019. Diakses tanggal 17 January 2017.
  60. ↑ "Archive By Publication : Beyond the Numbers: U.S. Bureau of Labor Statistics". www.bls.gov.
  61. ↑ "The Soon-to-Be-Extinct Embedded Software Engineer". designnews.com. May 10, 2018.
  62. ↑ "hp's Developer Portal | HP International Women's Week: Women in Computer Science dropping since 1980s". developers.hp.com.
  63. ↑ Generative AI and Jobs https://webapps.ilo.org/static/english/intserv/working-papers/wp140/index.html
  64. ↑ "Software engineer jobs in danger due to ChatGPT-like tools? Here's what Google CEO Sundar Pichai has to say". Business Today (dalam bahasa Inggris). 2023-04-06. Diakses tanggal 2023-05-12.
  65. ↑ "ChatGPT could make these jobs obsolete" (dalam bahasa American English). 2023-01-25. Diakses tanggal 2023-05-12.
  66. ↑ Kay, Grace. "Software engineers are panicking about being replaced by AI". Business Insider (dalam bahasa American English). Diakses tanggal 2023-05-12.
  67. ↑ Fowler, Gary. "Council Post: How Will ChatGPT Affect Jobs?". Forbes (dalam bahasa Inggris). Diakses tanggal 2023-05-12.
  68. ↑ Ito, Aki. "ChatGPT spells the end of coding as we know it". Business Insider (dalam bahasa American English). Diakses tanggal 2023-05-12.
  69. ↑ Zinkula, Aaron Mok, Jacob. "ChatGPT may be coming for our jobs. Here are the 10 roles that AI is most likely to replace". Business Insider (dalam bahasa American English). Diakses tanggal 2023-05-12. Pemeliharaan CS1: Banyak nama: authors list (link)
  70. ↑ Cohen, Mikaela (15 April 2023). "These are the tech jobs most threatened by ChatGPT and A.I." CNBC (dalam bahasa Inggris). Diakses tanggal 2023-05-12.
  71. ↑ ""Learn to Code" Backfires Spectacularly as Comp-Sci Majors Suddenly Have Sky-High Unemployment". 31 May 2025.
  72. ↑ "SEI certification page". Sei.cmu.edu. Diakses tanggal 2012-03-25.
  73. ↑ Wyrostek, Warren (March 14, 2008). "The Top 10 Problems with IT Certification in 2008". InformIT. Diakses tanggal 2009-03-03.
  74. ↑ IEEE Computer Society. "2006 IEEE computer society report to the IFIP General Assembly" (PDF). Diakses tanggal 2007-04-10.
  75. ↑ IEEE (12 November 2008). "CSDA". Diakses tanggal 2010-04-20.
  76. ↑ Canadian Information Processing Society. "I.S.P. Designation". Diakses tanggal 2007-03-15.
  77. ↑ "Professional Engineers Ontario: Welcome to PEO's website". Peo.on.ca. Diakses tanggal 2012-03-25.
  78. ↑ Thibodaux, Patrick (2006-05-05). "As outsourcing gathers steam, computer science interest wanes". Computerworld.com. Diakses tanggal 2016-12-06.
  79. ↑ "Work weeks are getting more intense for AI startups".
  80. ↑ Robert Mullins (March 13, 2007). "Software developer growth slows in North America: Study shows Asia will lead in software developer jobs by 2010". InfoWorld. Software Development.
  81. ↑ "Gartner Magic Quadrant" (PDF). Cognizant.com. Diarsipkan dari asli (PDF) tanggal 2008-09-20. Diakses tanggal 2012-03-25.
  82. ↑ Casey, Valentine (2010-08-20). "Virtual software team project management". Journal of the Brazilian Computer Society. 16 (2): 83–96. doi:10.1007/s13173-010-0013-3. S2CID 14383734.
  83. ↑ "Outstanding Research Award". SIGSOFT. Diakses tanggal 1 April 2024.
  84. ↑ David Lo (SIGSOFT Awards Chair); Thomas Zimmermann (SIGSOFT Chair) (17 January 2024). "SIGSOFT Awards 2024". ACM SIGSOFT Blog. Diakses tanggal 1 April 2024.
  85. ↑ "ICSE Most Influential Paper Award". ACM SIGSOFT.
  86. ↑ Donald J. Bagert (April 1999). "Viewpoint: taking the lead in licensing software engineers". Communications of the ACM. 42 (4): 27–29. doi:10.1145/299157.299163. publikasi akses terbuka - bebas untuk dibuka
  87. 1 2 Barry Boehm (September–October 2002). "Software engineering is a value-based contact sport". IEEE Software. 19 (5): 95–96. doi:10.1109/MS.2002.1032863.
  88. ↑ Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science". Diakses tanggal 2014-01-10.

Sumber

[sunting | sunting sumber]

Bacaan lanjutan

[sunting | sunting sumber]

Pranala luar

[sunting | sunting sumber]

Templat:Software engineering Templat:Systems engineering Templat:Engineering fields Templat:Computer science

Diperoleh dari "https://id.wikipedia.org/w/index.php?title=Rekayasa_perangkat_lunak&oldid=29294856"