Mitos Perangkat Lunak (Software Myths) Menurut Roger S. Pressman

Mitos seputar perangkat lunak telah ada sejak era awal komputasi dan hal ini salah kaprah dalam memahami perangkat lunak dan proses pembuatannya. Mitos ini berbahaya karena cenderung terlihat seperti fakta yang masuk akal, seringkali terdapat kebenaran di dalamnya, memiliki kecenderungan intuitif, dan sering kali dipopulerkan oleh para praktisi yang memiliki pengalaman dan dianggap tahu benar.

Saat ini, kebanyakan ahli rekayasa perangkat lunak yang berpengetahuan mengenali mitos sebagai suatu kenyataan, yaitu sikap yang dapat menyesatkan dan telah menimbulkan masalah serius bagi manajer dan praktisi. Namun, sikap dan kebiasaan yang sudah terbentuk sulit untuk diubah, dan masih tersisa beberapa mitos perangkat lunak yang bertahan.

Management myths. Para manajer yang bertanggung jawab atas pengembangan perangkat lunak selalu merasa tertekan untuk mempertahankan anggaran, menyelesaikan proyek sesuai jadwal, dan meningkatkan kualitasnya. Seperti seorang orang yang tenggelam yang berusaha bertahan dengan menggenggam sebuah sedotan, manajer perangkat lunak terkadang berpegang teguh pada kepercayaan mitos perangkat lunak, jika hal tersebut dapat mengurangi tekanan (meskipun hanya sementara).

Myth:        Saya sudah memiliki buku yang berisi berbagai standar dan prosedur dalam membangun perangkat lunak. Apakah buku tersebut sudah cukup memberikan informasi yang dibutuhkan oleh tim saya?

Reality:    Meskipun ada buku standar untuk membangun perangkat lunak, namun masih menjadi pertanyaan apakah buku tersebut digunakan dan apakah praktisi perangkat lunak menyadarinya. Apakah standar tersebut mencerminkan praktik rekayasa perangkat lunak modern dan sudah lengkap serta dapat beradaptasi. Selain itu, apakah prosedur yang disederhanakan untuk mempercepat waktu pengiriman tetapi tetap menjaga kualitas. Dalam banyak kasus, jawaban atas pertanyaan-pertanyaan tersebut adalah "tidak".

Myth:        Jika jadwal terlambat, kadang-kadang kita dapat menggunakan konsep "Mongolian horde" dengan menambahkan lebih banyak programmer untuk mengejar ketinggalan.

Reality:     Proses pengembangan perangkat lunak tidak dapat dianggap sebagai proses mekanistik seperti manufaktur. Seperti yang dikatakan oleh Brooks, "menambahkan orang ke dalam proyek perangkat lunak yang terlambat hanya akan membuatnya semakin terlambat." Pada awalnya, pernyataan ini mungkin kelihatan bertentangan dengan intuisi. Namun, menambahkan sumber daya manusia baru ke dalam proyek dapat mengakibatkan waktu yang terbuang karena harus melatih dan mengenalkan mereka pada proyek tersebut, sehingga mengurangi waktu yang seharusnya dihabiskan untuk aktivitas pengembangan yang produktif. Meskipun demikian, penambahan sumber daya manusia dapat dilakukan dengan cara yang terencana dan terkoordinasi dengan baik.

 Myth:        Dengan mengalihkan proyek perangkat lunak ke pihak ketiga, saya bisa membebaskan waktu dan sumber daya internal perusahaan dan mempercayakan tugas tersebut pada ahlinya.

Reality:    Jika sebuah perusahaan tidak mengerti bagaimana cara mengatur dan mengontrol proyek perangkat lunak mereka secara internal, mereka akan selalu mengalami kesulitan dalam menyelesaikan proyek tersebut.

Customer myths. Berbagai pelanggan yang memerlukan perangkat lunak dapat terdiri dari orang-orang yang duduk di sebelah, kelompok teknis yang berada di luar, departemen penjualan/pemasaran, atau bahkan perusahaan luar yang telah menandatangani kontrak untuk meminta perangkat lunak. Kebanyakan pelanggan tidak menyadari bahwa mitos tentang perangkat lunak sering diperparah oleh manajer dan praktisi perangkat lunak yang kurang melakukan upaya untuk mengoreksi kesalahpahaman tersebut. Hal ini dapat menghasilkan harapan yang tidak realistis dari pelanggan dan pada akhirnya dapat menimbulkan ketidakpuasan terhadap pengembang perangkat lunak. 

Myth:        Dengan menyediakan pernyataan umum tentang tujuan, kita dapat memulai penulisan program dan memperincinya nanti dengan detail yang lebih lengkap.

Reality:        Dalam situasi di mana pernyataan persyaratan yang komprehensif dan stabil sulit dicapai, penggunaan "statement of objectives" yang tidak jelas dapat berujung pada bencana. Oleh karena itu, persyaratan yang jelas dan tidak ambigu harus dikembangkan melalui komunikasi terus-menerus dan efektif antara pelanggan dan pengembang secara iteratif.

Myth:        Meskipun persyaratan perangkat lunak dapat berubah-ubah, perubahan tersebut dapat dengan mudah ditangani karena perangkat lunak dirancang untuk fleksibel.

Reality:    Dalam pengembangan perangkat lunak, wajar jika persyaratan berubah seiring waktu. Namun, dampak dari perubahan tersebut bervariasi tergantung pada waktu diperkenalkannya. Jika perubahan dilakukan pada tahap awal (sebelum desain atau kode dimulai), maka dampak biayanya relatif kecil. Namun, jika perubahan dilakukan di kemudian hari, dampak biaya akan semakin besar karena sumber daya telah dikerahkan, kerangka desain telah ditetapkan, dan perubahan dapat menyebabkan masalah yang memerlukan sumber daya dan modifikasi desain yang besar. 

Practitioner’s myths. Praktisi perangkat lunak masih mempercayai beberapa mitos yang telah terbentuk selama lebih dari 50 tahun. Budaya pemrograman di masa awal dianggap sebagai sebuah seni yang sulit dilakukan dengan cara dan sikap lama. 

Myth:        Setelah program yang ditulis berhasil dijalankan, berarti tugas kita sudah selesai.

Reality:    Sebuah pernyataan mengatakan bahwa semakin cepat seseorang mulai menulis kode, maka semakin lama waktu yang dibutuhkan untuk menyelesaikannya. Data industri menunjukkan bahwa sekitar 60 hingga 80 persen dari seluruh usaha yang dikeluarkan untuk perangkat lunak akan dikeluarkan setelah produk tersebut pertama kali dikirimkan ke pelanggan.

Myth:        Saya tidak dapat mengevaluasi kualitas program hingga program itu dapat dijalankan dengan baik.

Reality:    Untuk menjamin kualitas perangkat lunak, tinjauan teknis dapat menjadi mekanisme yang sangat efektif. Tinjauan perangkat lunak, jika dilakukan sejak awal proyek, dianggap lebih efektif dalam mengidentifikasi cacat perangkat lunak dibandingkan dengan pengujian. 

Myth:        Untuk sebuah proyek yang berhasil, satu-satunya hasil yang dapat dihasilkan adalah program yang fungsional dan siap digunakan.

 Reality:    Perangkat lunak yang berhasil terdiri dari lebih dari sekedar program kerja, melainkan melibatkan banyak elemen lain dalam konfigurasinya. Produk kerja lainnya, seperti model, dokumen, dan rencana, memberikan fondasi bagi keberhasilan rekayasa perangkat lunak serta panduan untuk dukungan perangkat lunak.

Myth:        Dalam rekayasa perangkat lunak, kita akan memerlukan banyak dokumentasi yang terkadang tidak diperlukan dan hal ini dapat memperlambat proses.

Reality:    Rekayasa perangkat lunak tidaklah semata-mata tentang menghasilkan dokumen. Fokus utamanya adalah pada penciptaan produk yang memiliki kualitas yang baik. Kualitas yang lebih baik akan mengurangi kebutuhan untuk melakukan pekerjaan berulang-ulang. Dalam akhirnya, hal ini akan mengarah pada pengiriman produk yang lebih cepat. 

Banyak praktisi perangkat lunak menyadari kesalahan dalam pandangan mitos yang baru saja dijelaskan. Namun, kebiasaan dan metode manajemen yang buruk masih dipraktikkan, bahkan ketika situasi membutuhkan pendekatan yang lebih baik. Kesadaran terhadap realitas di industri perangkat lunak merupakan langkah awal dalam mengembangkan solusi praktis untuk rekayasa perangkat lunak. 

Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.