Mengapa Rekayasa Perangkat Lunak Tidak Seperti Disiplin Teknik Lainnya dan Bagaimana Mengubah Game


Selamat datang di ngepost.com, ada artikel baru tentang Mengapa Rekayasa Perangkat Lunak Tidak Seperti Disiplin Teknik Lainnya dan Bagaimana Mengubah Game

Diperkirakan ada lebih dari 11 juta pengembang perangkat lunak profesional di seluruh dunia pada 2014. Ketika saya mulai sebagai seorang programmer pada tahun 1973, salah satu greybeards 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 dan jadi saya melakukan pekerjaan sarjana dan pascasarjana di bidang Matematika mengambil beberapa program pemrograman komputer di sepanjang jalan. Ini adalah cara banyak dari kita memulai sebagai pengembang perangkat lunak di tahun 70-an.

Istilah Rekayasa Perangkat Lunak baru pada saat itu, diciptakan pada Konferensi Rekayasa Perangkat Lunak NATO 1968. Pemikiran saat itu adalah bahwa kita perlu menerapkan metode teknik yang ada untuk pengembangan perangkat lunak untuk mengatasi masalah anggaran, jadwal dan kualitas yang disebut pada saat itu sebagai "krisis perangkat lunak." Akibatnya, apa yang kebanyakan orang pikirkan sebagai Rekayasa Perangkat Lunak melibatkan kegiatan yang sangat mirip dengan disiplin teknik lainnya termasuk teknik sipil, mekanik, dan listrik.

Di permukaan, ide ini tampaknya masuk akal. Saat Anda membangun sesuatu menggunakan disiplin ilmu teknik lainnya (mis. Jembatan, bangunan, perangkat keras khusus, papan sirkuit listrik) Anda perlu mengetahui persyaratan, merancang solusi, mengimplementasikannya, dan mengujinya. Semua langkah ini juga masuk akal untuk perangkat lunak. Jadi orang tentu bisa berdebat dari perspektif ini bahwa rekayasa perangkat lunak harus menyerupai disiplin ilmu teknik lainnya. Namun, ketika Anda melihat lebih dekat pada 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, karena pemrograman komputer telah menjadi bagian besar dari apa yang disebut Ilmu Komputer, banyak Universitas telah menambahkan kursus dengan judul "Rekayasa Perangkat Lunak" ke dalam kurikulum Ilmu Komputer mereka. Buku teks populer yang digunakan pada waktu itu untuk mengajarkan kursus ini termasuk buku teks Ian Sommerville berjudul: "Rekayasa Perangkat Lunak". Dari 1992 hingga 1994 saya menggunakan Edisi Keempat buku teks ini untuk mengajar Rekayasa Perangkat Lunak di Universitas Binghamton. Saat ini, buku pelajaran 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 konon mengajar siswa-siswa kita dasar-dasar Rekayasa Perangkat Lunak?

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 hal ini terjadi, kita perlu melihat lebih dekat 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 mengajar generasi berikutnya dari para profesional perangkat lunak apa pun yang saat ini populer dalam hal praktik perangkat lunak, dan metode. Praktik dan metode peranti lunak populer saat ini dikenal oleh buzzwords seperti Agile, Use Case, User Stories, RUP, XP, Scrum Lean, PSP, TSP dan daftarnya terus bertambah …

Masalah dengan pendekatan ini untuk mengajar Rekayasa Perangkat Lunak adalah bahwa praktik dan metode perangkat lunak sering datang dan pergi dan akan terus datang dan pergi itulah sebabnya Sommerville harus terus memperbarui buku pelajarannya. Ini mengarah ke pertanyaan lain:

Bagaimana dengan greybeard di perusahaan pertama tempat saya bekerja pada tahun 1973 yang menyuruh saya mempelajari hal-hal yang tidak pernah berubah? Apakah dia memberi saya nasihat 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, mari kita mundur dan mengajukan beberapa pertanyaan berbeda:

Apakah sekumpulan hal yang tidak pernah berubah dalam Rekayasa Perangkat Lunak benar-benar ada?

Jika mereka 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 sehingga ketika mereka keluar dari Universitas mereka siap untuk berperilaku sebagai profesional perangkat lunak?

Satu set penting dari rekayasa perangkat lunak memang ada. Keyakinan ini telah memotivasi kelompok sukarelawan internasional untuk melakukan tugas kodifikasi hal-hal penting tersebut. Tujuannya adalah agar hal-hal yang penting ini diajarkan kepada generasi pengembang perangkat lunak kami berikutnya yang membantu mempersiapkan mereka sebagai profesional perangkat lunak sejati.

Para sukarelawan yang terlibat dalam inisiatif ini (dikenal sebagai SEMAT – Metode dan Teori Rekayasa Perangkat Lunak) telah mengerjakan tugas ini sejak 2010. Tahun lalu ini SEMAT mencapai tonggak utama 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:

Betapa berbedanya standar Essence dari apa yang diajarkan kepada pengembang perangkat lunak kami saat ini, dan telah diajarkan selama 40 tahun terakhir dengan nama Rekayasa Perangkat Lunak?

Dan:

Akankah perbedaan benar-benar membantu dengan masalah yang banyak orang percaya masih mengganggu industri perangkat lunak berkenaan dengan anggaran bersama, dan penjadwalan yang berjalan serta kualitas perangkat lunak yang buruk?

Dari satu perspektif, apa yang ditangkap Essence bukanlah hal baru. Standar Essence mencakup kata-kata umum seperti, Stakeholder, Peluang, Persyaratan, Sistem Perangkat Lunak, Tim, Pekerjaan, dan Cara Kerja. Tetapi dari perspektif lain apa yang ditangkap Essence secara dramatis baru. Bahkan, beberapa menyebutnya sebagai "perubahan paradigma" yang banyak dari "penjaga lama" akan mengalami kesulitan besar bahkan memahaminya.

Untuk memberi Anda gambaran tentang perubahan yang terjadi saat menggunakan Essence saya kembali berpikir kembali ke hari-hari awal saya sebagai seorang programmer di akhir tahun 1970-an. Pada masa itu saya bekerja di domain simulasi penerbangan mengembangkan sistem perangkat lunak untuk melatih pilot untuk menerbangkan pesawat berkinerja tinggi. Salah satu bidang keahlian saya adalah menulis perangkat lunak untuk memberikan kemampuan merekam / pemutaran untuk membantu instruktur melatih pilot pesawat terbang muda dalam keterampilan terbang.

Saya ingat satu proyek spesifik tempat saya bekerja dan seorang instruktur pilot pelanggan yang bekerja sama dengan saya. Setelah menjelaskan kepadanya bagaimana ia dapat menggunakan perangkat lunak rekam / pemutaran saya untuk membantunya menunjukkan kepada pilot siswanya di mana mereka melakukan kesalahan, ia dengan bersemangat menulis sejumlah cacat yang meminta perubahan pada perangkat lunak saya.

Saya berdebat dengan manajer program saya bahwa tidak ada masalah yang benar-benar cacat. Karena saya telah meluangkan waktu untuk menjelaskan apa yang mungkin terjadi dengan perangkat lunak rekam / pemutaran saya, instruktur pilot mulai membayangkan fitur tambahan yang dapat membuat pekerjaannya lebih mudah. Dia menulis idenya di formulir cacat meskipun semuanya adalah peningkatan kemampuan yang kami tidak pernah rencanakan untuk disampaikan dan bukan bagian dari persyaratan.

Tetapi manajer proyek saya tidak ingin berdiskusi dengan pelanggan apakah permintaan ini berada di dalam ruang lingkup, atau di luar ruang lingkup. Pandangannya adalah – sebagai banyak perangkat lunak yang dilihat saat itu dan masih melihatnya hari ini – bahwa lebih mudah untuk mengubah perangkat lunak daripada melibatkan pelanggan dalam suatu diskusi.

Karena perangkat lunaknya lunak, kita cenderung melihatnya mudah diubah. Ini tidak seperti perangkat keras. Logam tidak mudah bengkok. Perspektif ini mengubah seluruh permainan ketika datang ke perangkat lunak.

Kemampuan ini untuk mengubah kode perangkat lunak dengan cepat dan tanpa akhir sepenuhnya mengubah dinamika yang ada antara pengembang perangkat lunak dan pemangku kepentingan mereka termasuk manajer program dan pelanggan. Salah satu cara perbedaan ini menunjukkan dirinya adalah ketika pengguna menjadi terbiasa dengan perangkat lunak mereka sering melihat cara-cara baru bahwa perubahan pada perangkat lunak dapat membuat pekerjaan mereka lebih mudah seperti pelanggan instruktur pilot saya lakukan kembali pada akhir 1970-an.

Kita sekarang tahu dari pengalaman bahwa ada dimensi lain pada Rekayasa Perangkat Lunak yang penting untuk praktik rekayasa perangkat lunak profesional yang efektif. Dimensi-dimensi lain ini membawa kita melampaui kemudahan dengan mana kode dapat diubah. Sampai saat ini, dimensi tambahan ini belum diterima mendekati perhatian yang layak mereka dapatkan.

Saat Anda mengubah kode, Anda mungkin juga memengaruhi persyaratan, dan Anda juga mungkin memengaruhi kemampuan lain dalam sistem perangkat lunak yang sebelumnya telah diuji. Mengubah kode berarti pekerjaan tambahan, pengujian tambahan, kemungkinan perubahan pada panduan pengguna pendukung dan sebagainya … Semua ini memengaruhi anggaran dan jadwal, dan memperkenalkan risiko tambahan pada kualitas perangkat lunak.

Sementara di satu sisi kemampuan untuk mengubah kode perangkat lunak dengan cepat membawa kekuatan besar bagi industri perangkat lunak, itu juga berarti bahwa para profesional perangkat lunak harus semakin selaras dengan cara kerja mereka yang disepakati, dampak dan waktu yang diperlukan untuk melakukan pekerjaan tambahan , dan risiko saat melakukan perubahan cepat yang tidak direncanakan. Gerakan lincah selama sepuluh tahun terakhir telah memberikan layanan hebat untuk membantu komunitas perangkat lunak memahami perbedaan utama terkait Rekayasa Perangkat Lunak ini termasuk pentingnya interaksi awal dan berkelanjutan dengan para pemangku kepentingan dan pentingnya pengembang perangkat lunak memperkirakan biaya pekerjaan mereka sendiri.

Sementara komunitas rekayasa perangkat lunak telah belajar banyak dari disiplin ilmu teknik lainnya, mereka juga telah mempelajari pentingnya dimensi-dimensi lain ini yang membawa perbedaan dari pengalaman teknik sebelumnya. Perbedaan-perbedaan ini berarti bahwa pengembang perangkat lunak perlu dilatih dalam cara-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 draft salinan buku yang sedang dia kerjakan untuk ditinjau. Watts Humphrey yang telah merencanakan untuk menjadi sangat aktif dalam pekerjaan SEMAT awal jatuh sakit hanya ketika pekerjaan SEMAT sedang bersiap-siap dan saya diminta untuk membantunya mendapatkan upaya yang direncanakan berjalan. Pada akhir Agustus tahun yang sama Watts mengirimi saya email berikut hanya beberapa bulan sebelum kematiannya. Dia setuju bahwa saya dapat membagikan email ini dengan orang lain:

Paul, Dari komentar Anda, sepertinya Anda benar-benar mengerti maksud buku saya, untuk itu saya bersyukur …. jawaban yang benar dan yang paling saya minati dengan SEMAT, menyangkut bagaimana kita dapat memastikan bahwa profesional perangkat lunak terlatih dengan baik dan memiliki serangkaian sikap dan keterampilan profesional yang sesuai sebelum mereka bahkan sampai ke industri. Ini adalah harapan saya bahwa upaya SEMAT pada akhirnya akan dapat menjadi ujung tombak dorongan untuk membuat komunitas akademis memfokuskan kembali program mereka pada pengajaran profesional perangkat lunak untuk bertindak seperti para profesional dan untuk mengatur diri mereka sendiri.

Ketika mereka melakukannya, lulusan mereka akan dapat bernegosiasi dengan manajemen mereka dan untuk melakukan pekerjaan yang unggul …. Itulah yang harus dilakukan para profesional … Awal yang baik dalam arah ini adalah meyakinkan mereka tentang perlunya memiliki orang-orang perangkat lunak ukur pekerjaan mereka sendiri. Karena pekerjaan perangkat lunak, seperti yang kami katakan, pekerjaan pengetahuan, segala tindakan yang benar-benar akurat harus diambil oleh para profesional perangkat lunak itu sendiri. … Watts Humphrey

Watts Humphrey telah disebut sebagai bapak kualitas perangkat lunak. Setelah menyelesaikan kariernya yang istimewa di IBM, ia kemudian menjadi anggota Institut Rekayasa Perangkat Lunak yang mendirikan Program Proses Perangkat Lunak. Pada tahun 2003 ia dianugerahi Medali Teknologi Nasional.

Hari ini Watts akan berbesar hati dengan pekerjaan SEMAT yang terjadi di komunitas akademik. Kursus penuh Universitas pertama berdasarkan standar Essence baru telah dikembangkan dan sedang dikirimkan kepada siswa tahun ini oleh Dr. Carlos Zapata di Universidad Nacional de Columbia di Medellin, Columbia, dan Essence digunakan pada 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 untuk menunjukkan bagaimana Essence dapat membantu dalam industri dengan menerbitkan studi kasus tentang penggunaan aktual dan hasil yang diukur pada proyek-proyek industri.



Source by Paul E McMahon

Leave a Reply

Your email address will not be published. Required fields are marked *

Releated

Energi dalam 30 Tahun Ke Depan

Selamat datang di ngepost.com, ada artikel baru tentang Energi dalam 30 Tahun Ke Depan Kita sekarang berada pada tahap awal dari revolusi energi yang mendalam dan cepat seperti yang mengantar era minyak di abad ke-21. Sistem energi baru ini – sangat terdesentralisasi, efisien, dan semakin berbasis pada sumber daya terbarukan dan bahan bakar hidrogen – […]

Pelatihan Energi Matahari – Saatnya Belajar Keterampilan Terbarukan?

Selamat datang di ngepost.com, ada artikel baru tentang Pelatihan Energi Matahari – Saatnya Belajar Keterampilan Terbarukan? Seperti kita ketahui bahwa energi hijau telah mendominasi masa kini dan sangat diharapkan bahwa energi hijau juga akan mendominasi masa depan. Dengan kelangkaan sumber daya alam dan pembatasan pada mereka, energi matahari adalah solusi lengkap untuk semua masalah. Banyak […]