Diperkirakan ada lebih dari 11 juta pengembang perangkat lunak profesional di seluruh dunia pada tahun 2014. Ketika saya mulai sebagai programmer pada tahun 1973, salah satu orang yang tidak bertanggung jawab di perusahaan pertama tempat saya bekerja memberi saya beberapa saran. Dia berkata, “Pelajari hal-hal yang tidak pernah berubah.”
Ketika saya mulai kuliah enam tahun sebelumnya pada tahun 1967, sekolah yang saya hadiri tidak memiliki jurusan yang disebut Ilmu Komputer, jadi saya melakukan pekerjaan sarjana dan pascasarjana di bidang Matematika dengan mengambil beberapa kursus pemrograman komputer di sepanjang jalan. Ini adalah cara banyak dari kita memulai sebagai pengembang perangkat lunak di tahun 70-an.
Istilah Rekayasa Perangkat Lunak masih baru pada saat itu, diciptakan pada Konferensi Rekayasa Perangkat Lunak NATO tahun 1968. Pemikiran saat itu adalah bahwa kami perlu menerapkan metode rekayasa yang ada untuk pengembangan perangkat lunak untuk mengatasi masalah umum anggaran, jadwal, dan kualitas yang pada saat itu disebut sebagai “krisis perangkat lunak”. Akibatnya, apa yang kebanyakan orang anggap sebagai Rekayasa Perangkat Lunak melibatkan kegiatan yang sangat mirip dengan disiplin ilmu teknik lainnya termasuk teknik sipil, mekanik, dan listrik.
Di permukaan, ide ini tampaknya masuk akal. Saat Anda membangun sesuatu menggunakan disiplin teknik lainnya (misalnya jembatan, bangunan, perangkat keras khusus, papan sirkuit listrik), Anda perlu mengetahui persyaratannya, merancang solusi, mengimplementasikannya, dan mengujinya. Semua langkah ini juga masuk akal untuk perangkat lunak. Jadi orang pasti bisa berargumen dari perspektif ini bahwa rekayasa perangkat lunak harus menyerupai disiplin teknik lainnya. Namun, ketika Anda melihat lebih dekat apa yang telah kami pelajari tentang pengembangan perangkat lunak selama empat puluh tahun terakhir, serta bagaimana kami mengajarkannya kepada pengembang perangkat lunak saat ini, analogi ini dengan cepat rusak.
Pada saat tahun 1990-an bergulir, karena pemrograman komputer telah menjadi bagian besar dari apa yang disebut Ilmu Komputer, banyak Universitas menambahkan kursus dengan judul “Rekayasa Perangkat Lunak” ke dalam kurikulum Ilmu Komputer mereka. Buku teks populer yang digunakan pada saat itu untuk mengajar kursus ini termasuk buku teks Ian Sommerville berjudul: “Rekayasa Perangkat Lunak”. Dari tahun 1992 sampai 1994 saya menggunakan Buku Edisi Keempat ini untuk mengajar Rekayasa Perangkat Lunak di Universitas Binghamton. Saat ini, buku teks Ian Sommerville masih digunakan di banyak Universitas di seluruh dunia—sekarang dalam Edisi Kesembilan. Ini mengarah pada pertanyaan:
Mengapa kita perlu merevisi buku teks kira-kira setiap 3-4 tahun yang seharusnya mengajarkan dasar-dasar Rekayasa Perangkat Lunak kepada siswa kita?
Jika Anda melihat buku teks yang digunakan dalam Teknik Sipil, Teknik Mesin, dan Teknik Listrik, sebagian besar buku-buku ini hampir tidak memerlukan revisi. Untuk memahami mengapa demikian, kita perlu melihat lebih dekat pada apa yang diajarkan di sebagian besar Universitas di seluruh dunia dengan nama “Rekayasa Perangkat Lunak”.
Ketika Anda melihat lebih dekat, Anda akan menemukan bahwa kami sedang mengajarkan perangkat lunak profesional generasi berikutnya apa pun yang saat ini populer dalam hal praktik dan metode perangkat lunak. Praktik dan metode perangkat lunak populer saat ini dikenal dengan kata kunci seperti Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP dan daftarnya terus bertambah…
Masalah dengan pendekatan pengajaran Rekayasa Perangkat Lunak ini adalah bahwa praktik dan metode perangkat lunak sering datang dan pergi dan akan terus datang dan pergi, itulah sebabnya Sommerville harus terus memperbarui buku teksnya. Ini mengarah ke pertanyaan lain:
Bagaimana dengan pria berjanggut abu-abu di perusahaan pertama tempat saya bekerja pada tahun 1973 yang menyuruh saya mempelajari hal-hal yang tidak pernah berubah? Apakah dia memberi saya nasihat yang buruk? Jika tidak, apa yang kita ajarkan kepada generasi profesional perangkat lunak berikutnya sehubungan dengan hal-hal yang tidak pernah berubah tentang Rekayasa Perangkat Lunak?
Sebelum menjawab pertanyaan-pertanyaan ini, pertama-tama mari kita mundur dan mengajukan beberapa pertanyaan berbeda:
Apakah sekumpulan hal yang tidak pernah berubah dalam Rekayasa Perangkat Lunak benar-benar ada?
Jika mereka memang ada, apakah kita tahu apa itu?
Jika kita tahu apa itu, apakah kita mengajar mereka dengan cara yang konsisten kepada generasi profesional perangkat lunak kita berikutnya sehingga ketika mereka keluar dari Universitas mereka siap untuk bertindak sebagai profesional perangkat lunak?
Serangkaian esensi rekayasa perangkat lunak seperti itu sebenarnya ada. Keyakinan ini telah memotivasi kelompok sukarelawan internasional untuk mengkodifikasi hal-hal penting tersebut. Tujuannya adalah agar hal-hal penting ini diajarkan kepada pengembang perangkat lunak generasi berikutnya yang membantu mempersiapkan mereka sebagai profesional perangkat lunak sejati.
Relawan yang terlibat dalam inisiatif ini (dikenal sebagai SEMAT – Metode dan Teori Rekayasa Perangkat Lunak) telah mengerjakan tugas ini sejak 2010. Tahun lalu SEMAT mencapai tonggak penting dengan pengumuman oleh Object Management Group, sebuah konsorsium standar internasional, bahwa mereka telah mengadopsi “Essence” sebagai standar resmi OMG.
Jadi ini mengarah ke beberapa pertanyaan lagi:
Seberapa berbeda standar Essence dari apa yang diajarkan kepada pengembang perangkat lunak kita saat ini, dan telah diajarkan selama 40 tahun terakhir dengan nama Rekayasa Perangkat Lunak?
Dan:
Akankah perbedaan benar-benar membantu dengan masalah yang diyakini banyak orang masih mengganggu industri perangkat lunak sehubungan dengan anggaran bersama, dan jadwal over-run dan kualitas perangkat lunak yang buruk?
Dari satu perspektif, apa yang ditangkap Essence bukanlah hal baru. Standar Essence mencakup kata-kata umum seperti, Pemangku Kepentingan, Peluang, Persyaratan, Sistem Perangkat Lunak, Tim, Kerja, dan Cara Kerja. Namun dari perspektif lain, apa yang ditangkap oleh Essence benar-benar baru. Faktanya, beberapa orang menyebutnya sebagai “pergeseran paradigma” yang akan sulit dipahami oleh banyak “penjaga lama”.
Untuk memberi Anda gambaran tentang perubahan yang terjadi saat menggunakan Essence, saya mengingat kembali hari-hari awal saya sebagai programmer di akhir tahun 1970-an. Pada masa itu saya bekerja di domain simulasi penerbangan mengembangkan sistem perangkat lunak untuk melatih pilot menerbangkan pesawat berperforma tinggi. Salah satu bidang keahlian saya adalah menulis perangkat lunak untuk menyediakan kemampuan merekam/memutar untuk membantu instruktur melatih pilot pesawat terbang muda dalam keterampilan terbang.
Saya ingat satu proyek khusus yang saya kerjakan dan seorang instruktur percontohan pelanggan yang bekerja dengan saya. Setelah menjelaskan kepadanya bagaimana dia dapat menggunakan perangkat lunak rekaman/pemutaran saya untuk membantunya menunjukkan kepada siswa pilotnya di mana mereka telah membuat kesalahan, dia dengan bersemangat menulis sejumlah kekurangan yang meminta perubahan pada perangkat lunak saya.
Saya dengan keras berdebat dengan manajer program saya bahwa tidak satu pun dari masalah ini yang benar-benar cacat. Karena saya telah meluangkan waktu untuk menjelaskan apa yang mungkin dilakukan dengan perangkat lunak perekam/pemutaran saya, instruktur pilot mulai membayangkan fitur tambahan yang dapat mempermudah pekerjaannya. Dia menulis idenya pada formulir cacat meskipun itu semua adalah kemampuan yang ditingkatkan yang tidak pernah kami rencanakan untuk disampaikan dan bukan bagian dari persyaratan.
Tetapi manajer proyek saya tidak ingin berdiskusi dengan pelanggan apakah permintaan ini termasuk dalam cakupan atau tidak. Pandangannya adalah– seperti banyak perangkat lunak yang dilihat saat itu dan masih melihatnya hingga sekarang–bahwa lebih mudah mengubah perangkat lunak daripada melibatkan pelanggan dalam diskusi.
Karena perangkat lunak itu lunak, kita cenderung menganggapnya mudah untuk diubah. Ini tidak seperti perangkat keras. Logam tidak mudah bengkok. Perspektif ini mengubah keseluruhan permainan dalam hal perangkat lunak.
Kemampuan untuk mengubah kode perangkat lunak dengan cepat dan tanpa akhir ini benar-benar mengubah dinamika yang ada antara pengembang perangkat lunak dan pemangku kepentingan mereka termasuk manajer program dan pelanggan. Salah satu cara perbedaan ini mencontohkan dirinya adalah ketika pengguna menjadi terbiasa dengan perangkat lunak, mereka sering melihat cara baru bahwa perubahan pada perangkat lunak dapat membuat pekerjaan mereka lebih mudah seperti yang dilakukan pelanggan instruktur pilot saya di akhir tahun 1970-an.
Kami sekarang tahu dari pengalaman bahwa ada dimensi lain untuk Rekayasa Perangkat Lunak yang sangat penting untuk praktik rekayasa perangkat lunak profesional yang efektif. Dimensi lain ini membawa kita melampaui kemudahan mengubah kode. Sampai saat ini, dimensi tambahan ini belum mendapat perhatian yang layak.
Saat Anda mengubah kode, Anda mungkin juga memengaruhi persyaratan, dan Anda mungkin juga memengaruhi kapabilitas lain dalam sistem perangkat lunak yang telah diuji sebelumnya. Mengubah kode berarti pekerjaan tambahan, pengujian tambahan, kemungkinan perubahan untuk mendukung manual pengguna dan seterusnya… Semua ini memengaruhi anggaran dan jadwal, dan menimbulkan risiko tambahan pada kualitas perangkat lunak.
Sementara di satu sisi kemampuan untuk mengubah kode perangkat lunak dengan cepat memberikan kekuatan besar bagi industri perangkat lunak, ini juga berarti bahwa para profesional perangkat lunak harus semakin menyesuaikan diri dengan cara kerja yang disepakati, dampak dan waktu yang diperlukan untuk melakukan pekerjaan tambahan. , dan risiko saat melakukan perubahan cepat yang tidak direncanakan. Gerakan tangkas selama sepuluh tahun terakhir telah memberikan layanan hebat untuk membantu komunitas perangkat lunak memahami perbedaan utama yang terkait dengan Rekayasa Perangkat Lunak ini termasuk pentingnya interaksi awal dan berkelanjutan dengan pemangku kepentingan dan pentingnya pengembang perangkat lunak memperkirakan biaya pekerjaan mereka sendiri.
Sementara komunitas rekayasa perangkat lunak telah belajar banyak dari disiplin teknik lainnya, mereka juga telah mempelajari pentingnya dimensi lain yang membawa perbedaan dari pengalaman rekayasa sebelumnya. Perbedaan ini berarti bahwa pengembang perangkat lunak perlu dilatih dengan cara baru dan berbeda untuk menjadi profesional perangkat lunak yang efektif.
Tak lama setelah dimulainya inisiatif SEMAT pada bulan Maret 2010, salah satu penandatangan awal SEMAT mengirimi saya salinan draf buku yang sedang dikerjakannya untuk diulas. Watts Humphrey yang telah merencanakan untuk menjadi sangat aktif dalam pekerjaan SEMAT awal jatuh sakit tepat ketika pekerjaan SEMAT sedang bersiap dan saya diminta untuk membantunya menjalankan usahanya yang direncanakan. Pada akhir Agustus di tahun yang sama Watts mengirimi saya email berikut hanya beberapa bulan sebelum dia meninggal. Dia setuju bahwa saya dapat membagikan email ini kepada orang lain:
Paul, Dari komentar Anda, sepertinya Anda benar-benar memahami inti dari buku saya, yang saya syukuri …. jawaban yang benar dan yang paling saya minati dengan SEMAT, berkaitan dengan bagaimana kita dapat memastikannya profesional perangkat lunak terlatih dengan baik dan memiliki seperangkat sikap dan keterampilan profesional yang sesuai bahkan sebelum mereka masuk ke industri. Harapan saya bahwa upaya SEMAT pada akhirnya akan dapat menjadi ujung tombak untuk membuat komunitas akademis memfokuskan kembali program mereka untuk mengajar para profesional perangkat lunak untuk bertindak seperti profesional dan mengelola diri mereka sendiri.
Ketika mereka melakukannya, lulusan mereka akan dapat bernegosiasi dengan manajemen mereka dan melakukan pekerjaan yang unggul…. Itulah yang harus dilakukan oleh para profesional… Awal yang baik ke arah ini adalah meyakinkan mereka tentang perlunya memiliki orang perangkat lunak mengukur pekerjaan mereka sendiri. Karena pekerjaan perangkat lunak, seperti yang kami katakan, pekerjaan pengetahuan, tindakan apa pun yang benar-benar akurat harus diambil oleh para profesional perangkat lunak itu sendiri. … Watt Humphrey
Watts Humphrey telah disebut sebagai bapak kualitas perangkat lunak. Setelah menyelesaikan karir terkemuka di IBM, dia kemudian menjadi rekan dari Institut Rekayasa Perangkat Lunak yang mendirikan Program Proses Perangkat Lunak. Pada tahun 2003 ia dianugerahi National Medal of Technology.
Hari ini Watts akan berbesar hati dengan pekerjaan SEMAT yang sedang berlangsung di komunitas akademik. Kursus Universitas penuh pertama berdasarkan standar Essence baru telah dikembangkan dan disampaikan kepada siswa tahun ini oleh Dr. Carlos Zapata di Universidad Nacional de Columbia di Medellin, Columbia, dan Essence digunakan di tahun pertama dan kedua. kursus rekayasa perangkat lunak di KTH Royal Institute of Technology di Swedia di bawah bimbingan Dr. Mira Kajko-Mattson. Ada juga studi lapangan Essence yang dilakukan dengan siswa oleh Dr. Cecile Peraire di Carnegie-Mellon West di Amerika Serikat. Langkah selanjutnya untuk komunitas SEMAT adalah mendemonstrasikan bagaimana Essence dapat membantu industri dengan menerbitkan studi kasus penggunaan aktual dan hasil terukur pada proyek industri.