Implikasi Perawatan Perangkat Lunak pada Biaya dan Jadwal

Abstrak Kamus mendefinisikan pemeliharaan sebagai, "Pekerjaan menjaga sesuatu dalam urutan yang benar." Namun, definisi ini tidak selalu sesuai untuk perangkat lunak. Pemeliharaan perangkat lunak berbeda dari perawatan perangkat keras karena perangkat lunak tidak habis secara fisik, tetapi sering kurang berguna seiring bertambahnya usia. Perangkat lunak biasanya dikirimkan dengan kekurangan yang belum ditemukan. Oleh karena itu, pemeliharaan perangkat lunak adalah: "Proses memodifikasi perangkat lunak operasional yang ada saat meninggalkan fungsi utamanya tetap utuh." Perawatan biasanya melebihi lima puluh persen dari biaya siklus hidup sistem. Sementara pemeliharaan perangkat lunak dapat diperlakukan sebagai tingkat aktivitas usaha, ada konsekuensi pada kualitas, fungsionalitas, keandalan, biaya dan jadwal yang dapat dikurangi melalui penggunaan teknik estimasi parametrik.

1. PERKENALAN Salah satu tantangan terbesar yang dihadapi insinyur perangkat lunak adalah manajemen pengendalian perubahan. Diperkirakan biaya pengendalian perubahan bisa antara 40% hingga 70% dari biaya siklus hidup. Insinyur perangkat lunak berharap bahwa bahasa baru dan proses baru akan sangat mengurangi angka-angka ini; Namun ini belum terjadi. Pada dasarnya ini karena perangkat lunak masih dikirim dengan sejumlah besar cacat. Capers Jones memperkirakan bahwa ada sekitar 5 bug per Titik Fungsi yang dibuat selama Pengembangan. Watts Humphrey menemukan "… bahkan insinyur perangkat lunak yang berpengalaman biasanya menyuntikkan 100 atau lebih cacat per KSLOC. Capers Jones mengatakan," Serangkaian penelitian kerapatan cacat perangkat lunak berkisar 49,5 hingga 94,5 kesalahan per seribu baris kode. "Tujuan dari artikel ini adalah untuk pertama meninjau dasar-dasar pemeliharaan perangkat lunak dan untuk menyajikan pendekatan alternatif untuk memperkirakan pemeliharaan perangkat lunak.sebuah elemen kunci yang perlu diperhatikan adalah bahwa pengembangan dan keputusan manajemen yang dibuat selama proses pengembangan dapat secara signifikan mempengaruhi biaya pengembangan dan biaya pemeliharaan yang dihasilkan.

2. PEMELIHARAAN PERANGKAT LUNAK Kegiatan pemeliharaan mencakup semua pekerjaan yang dilakukan pasca pengiriman dan harus dibedakan dari modifikasi blok yang mewakili desain dan upaya pengembangan yang signifikan dan menggantikan paket perangkat lunak yang dirilis sebelumnya. Kegiatan pemeliharaan ini bisa sangat beragam, dan membantu untuk mengidentifikasi dengan tepat aktivitas pasca-pengiriman apa yang akan dimasukkan dalam perkiraan upaya pemeliharaan. Aktivitas pemeliharaan, sekali didefinisikan, dapat dievaluasi dalam cahaya yang sangat berbeda dari ketika hanya disebut "pemeliharaan". Pemeliharaan perangkat lunak berbeda dari pemeliharaan perangkat keras karena perangkat lunak tidak habis secara fisik, tetapi perangkat lunak sering kurang berguna dengan usia dan dapat dikirimkan dengan kekurangan yang belum ditemukan. Selain kekurangan yang belum ditemukan, adalah umum bahwa sejumlah cacat yang diketahui berpindah dari organisasi pengembangan ke kelompok pemeliharaan. Estimasi akurat dari upaya yang diperlukan untuk memelihara perangkat lunak yang disampaikan dibantu oleh dekomposisi dari upaya keseluruhan ke dalam berbagai kegiatan yang membentuk keseluruhan proses.

3. MEMPEROLEH MASALAH PEMELIHARAAN Perawatan adalah proses yang rumit dan terstruktur. Dalam bukunya, Estimating Software Intensive Systems, Richard Stuzke menjabarkan proses pemeliharaan perangkat lunak yang khas. Jelas bahwa prosesnya lebih dari sekadar menulis kode baru.

Daftar periksa berikut dapat digunakan untuk mengeksplorasi realisme dan akurasi persyaratan perawatan.

o Perangkat lunak apa yang akan dipertahankan?

o Berapa lama sistem perlu dipertahankan?

o Apakah Anda memperkirakan seluruh masalah perawatan, atau hanya perawatan tambahan?

o Tingkat perawatan apa yang diperlukan?

o Apakah itu yang disebut pemeliharaan sebenarnya merupakan proyek pengembangan baru?

o Siapa yang akan melakukan perawatan? Apakah ini akan dilakukan secara organik oleh pengembang asli? Apakah akan ada tim yang terpisah? Akankah ada organisasi terpisah?

o Akankah pengelola menggunakan alat yang sama yang digunakan selama pengembangan? Apakah ada alat kepemilikan yang diperlukan untuk pemeliharaan?

o Berapa banyak Komersial-Off-The-Shelf (COTS) yang ada? Seberapa erat hubungannya antarmuka?

o Beberapa pengembangan lanjutan dapat disamarkan sebagai pemeliharaan. Ini akan meningkatkan angka pemeliharaan, atau menyebabkan kekurangan jika perawatan dasar disisihkan. Pertanyaan-pertanyaan ini akan membantu Anda menanyakan apakah pemeliharaan direpresentasikan dengan jujur.

o Apakah kegiatan benar-benar merupakan peningkatan bertahap?

o Apakah potongan kode asli yang sehat ditulis ulang atau diubah?

o Apakah staf tambahan akan dibawa untuk melakukan pemutakhiran?

o Apakah jadwal upaya perawatan rutin dan cukup datar, atau apakah itu berisi staf yang gundukan yang terlihat seperti pengembangan baru?

4. PEMERIKSAAN SANITY Meskipun pemeriksaan kewarasan harus dilakukan setiap tahun, mereka tidak boleh berusaha untuk pengembangan secara keseluruhan. Alasannya adalah bahwa kegiatan pemeliharaan dapat dilakukan tanpa batas waktu, sehingga setiap aturan siklus kehidupan menjadi tidak berguna. Sebagai contoh, pertimbangkan Grady (p. 17):

Kami menghabiskan sekitar 2 hingga 3 kali lebih banyak upaya pemeliharaan dan peningkatan perangkat lunak saat kami menghabiskan membuat perangkat lunak baru.

Pengamatan ini dan yang serupa berlaku di tingkat organisasi dan lebih tinggi, tetapi tidak untuk proyek tertentu. Setiap kelompok pengembangan dengan sejarah akan terlibat dalam ujung ekor panjang dari banyak proyek yang dikirimkan, masih membutuhkan perhatian yang tidak terbatas. Berikut beberapa pemeriksaan cepat tentang kewarasan:

o Satu pengelola dapat menangani sekitar 10.000 baris per tahun.

o Upaya siklus hidup secara keseluruhan biasanya pengembangan 40% dan pemeliharaan 60%.

o Biaya pemeliharaan rata-rata adalah seperenam biaya pengembangan tahunan.

o Sistem yang berhasil biasanya dipertahankan selama 10 hingga 20 tahun.

Akhirnya, seperti dalam pengembangan, jumlah kode yang baru dibandingkan diubah membuat perbedaan. Ukuran efektif, yaitu, upaya setara jika semua pekerjaan itu kode baru, masih merupakan input kunci untuk kedua estimasi biaya pembangunan dan pemeliharaan.

5. FIVE ALTERNATIVE PENDEKATAN Semua estimasi perangkat lunak teknik harus dapat memodelkan teori dan kemungkinan hasil dunia nyata. Skenario dunia nyata adalah bahwa seiring waktu, hamparan perubahan pada perubahan membuat perangkat lunak semakin sulit untuk dipertahankan dan dengan demikian kurang bermanfaat. Teknik estimasi upaya pemeliharaan berkisar dari metode tingkat usaha yang sederhana, melalui analisis yang lebih bijaksana dan modifikasi praktik pembangunan, hingga penggunaan model parametrik untuk menggunakan data historis untuk memproyeksikan kebutuhan masa depan.

5.1 Tingkat Upaya Seperti yang kadang-kadang terjadi di lingkungan pengembangan, pemeliharaan perangkat lunak dapat dimodelkan sebagai tingkat aktivitas usaha. Mengingat kegiatan kategori perbaikan dan varians besar yang mereka tunjukkan, pendekatan ini jelas memiliki kekurangan. Dalam pendekatan ini, tingkat upaya untuk mempertahankan perangkat lunak didasarkan pada ukuran dan jenis.

5.2 Tingkat Upaya Plus Stuzke mengusulkan bahwa pemeliharaan perangkat lunak dimulai dengan usaha tingkat dasar (orang minimum yang diperlukan untuk memiliki kompetensi inti dan kemudian bahwa staf inti dasar harus dimodifikasi dengan menilai tiga faktor tambahan; manajemen konfigurasi, jaminan kualitas, dan manajemen proyek. Prosesnya membahas beberapa faktor tambahan yang mempengaruhi pemeliharaan perangkat lunak.

5.3 Faktor Perubahan Perawatan Estimasi Biaya Perangkat Lunak dengan COCOMO II (Boehm 2000) mengusulkan metodologi sederhana, tetapi juga cukup berguna untuk menentukan pemeliharaan tahunan. Perawatan adalah salah satu pilihan menu di bilah menu. Dalam COCOMO II Maintenance mencakup proses memodifikasi perangkat lunak operasional yang ada sementara fungsi utamanya tetap utuh. Proses ini tidak termasuk:

o Perancangan ulang dan pengembangan ulang (lebih dari 50% kode baru) dari produk perangkat lunak baru yang menjalankan fungsi yang sama secara substansial.

o Desain dan pengembangan dari sebuah paket perangkat lunak interfacing yang cukup besar (lebih dari 20% dari produk yang ada) yang memerlukan desain ulang yang relatif sedikit dari produk yang ada.

o Operasi sistem pengolahan data, entri data, dan modifikasi nilai dalam database.

Perhitungan pemeliharaan sangat didasarkan pada Faktor Perubahan Pemeliharaan (MCF) dan Faktor Penyesuaian Perawatan (MAF). MCF mirip dengan Trafik Perubahan Tahunan di COCOMO81, kecuali bahwa periode pemeliharaan selain satu tahun dapat digunakan. Rumus estimasi upaya pemeliharaan yang dihasilkan adalah sama dengan model pengembangan Pasca Arsitektur COCOMO II.

Sebagaimana dinyatakan sebelumnya, tiga driver biaya untuk pemeliharaan berbeda dari pengembangan. Driver biaya tersebut adalah keandalan perangkat lunak, praktik pemrograman modern, dan jadwal. COCOMO II mengasumsikan bahwa peningkatan investasi dalam keandalan perangkat lunak dan penggunaan praktik pemrograman modern selama pengembangan perangkat lunak memiliki efek positif yang kuat pada tahap pemeliharaan.

Upaya Pemeliharaan Tahunan = (Lalu Lintas Perubahan Tahunan) * (Pengembangan Perangkat Lunak Asli)

Kuantitas Upaya Pengembangan Perangkat Lunak Asli mengacu pada upaya total (orang-bulan atau unit ukuran lain) yang dikeluarkan selama pengembangan, bahkan jika proyek multi-tahun.

Multiplier Annual Change Traffic adalah proporsi dari keseluruhan perangkat lunak yang akan dimodifikasi sepanjang tahun. Ini relatif mudah diperoleh dari estimasi teknik. Pengembang sering mempertahankan daftar perubahan, atau memiliki rasa perubahan proporsional yang diperlukan bahkan sebelum pengembangan selesai.

5.4 Mengelola Biaya Pemeliharaan Perangkat Lunak dengan Teknik Pengembangan dan Keputusan Manajemen Selama Pengembangan

Ketika datang ke pemeliharaan, "satu sen yang dihabiskan adalah satu pon yang disimpan." Praktik pengembangan yang lebih baik (meskipun lebih mahal) dapat secara signifikan mengurangi upaya pemeliharaan, dan mengurangi biaya siklus hidup secara keseluruhan. Semakin banyak upaya yang dimasukkan ke dalam pengembangan, semakin sedikit yang dibutuhkan dalam pemeliharaan. Sebagai contoh, biaya dan jadwal pengembangan perangkat lunak dapat berdampak signifikan (dikurangi) dengan membiarkan jumlah cacat yang dikirimkan bertambah. Pengurangan biaya dan jadwal ini lebih dari diimbangi oleh peningkatan biaya pemeliharaan. Diskusi berikut adalah contoh bagaimana keputusan manajemen dapat secara signifikan mempengaruhi / mengurangi biaya pemeliharaan perangkat lunak.

Lloyd Huff dan George Novak dari Lockheed Martin Aeronautics dalam paper mereka "Lockheed Martin Aeronautics Performance Based Software Sustainment untuk F-35 Lightning II" mengusulkan serangkaian keputusan pengembangan dan manajemen yang dirancang untuk berdampak dan mengurangi biaya pemeliharaan perangkat lunak. Mereka mengusulkan proses delapan langkah untuk memperkirakan dan mengontrol pemeliharaan perangkat lunak. Langkah-langkah yang mereka usulkan adalah:

1. Berjuang untuk Kesamaan

2. Terapkan Praktik Teknik Industri ke Perangkat Lunak

3. Terlibat

4. Mengadopsi Pendekatan Holistik untuk Keberlanjutan

5. Kembangkan Sistem dan Perangkat Lunak Yang Sangat Dapat Dikelola

6. Kelola Perangkat Lunak Off-the-Shelf

7. Merencanakan yang Tak Terduga

8. Menganalisa dan Memperbaiki Kasus Bisnis Pelestarian Perangkat Lunak (gunakan perkiraan biaya pemeliharaan perangkat lunak Parametrik)

5.5 Penilaian Parametrik Pemeliharaan Perangkat Lunak

Model parametrik seperti SIER untuk Perangkat Lunak memungkinkan pemeliharaan dimodelkan dengan salah satu dari dua cara:

Memperkirakan pemeliharaan sebagai bagian dari total biaya siklus hidup. Memilih parameter kategori Pemeliharaan yang tepat akan mencakup perkiraan upaya pemeliharaan dengan estimasi pengembangan untuk masing-masing program perangkat lunak. Beberapa laporan dan bagan menunjukkan kerusakan pembangunan dibandingkan upaya pemeliharaan. Metode ini paling baik digunakan untuk mengevaluasi biaya siklus hidup untuk setiap program perangkat lunak individual.

Memperkirakan pemeliharaan sebagai aktivitas yang terpisah. Dengan menggunakan parameter pemeliharaan yang tepat untuk perangkat lunak yang harus dipelihara, Anda dapat memodelkan upaya pemeliharaan sebagai aktivitas terpisah. Metode ini akan memungkinkan Anda untuk menyesuaikan estimasi pemeliharaan Anda dengan menyesuaikan parameter. Ukuran pemeliharaan harus sama dengan ukuran pengembangan, tetapi harus dimasukkan sebagai semua kode yang sudah ada sebelumnya. Metode ini juga dapat berguna dalam membagi total biaya pemeliharaan proyek dari biaya pengembangan proyek.

Estimasi parametrik yang baik untuk pemeliharaan mencakup berbagai informasi. Informasi penting untuk menyelesaikan perkiraan pemeliharaan perangkat lunak adalah ukuran atau jumlah perangkat lunak yang akan dipertahankan, kualitas perangkat lunak itu, kualitas dan ketersediaan dokumentasi, dan jenis atau jumlah pemeliharaan yang akan dilakukan. Banyak organisasi tidak benar-benar memperkirakan biaya pemeliharaan; mereka hanya memiliki anggaran untuk pemeliharaan perangkat lunak. Dalam hal ini, model parametrik harus digunakan untuk menghitung seberapa banyak pemeliharaan sebenarnya dapat dilakukan dengan anggaran yang diberikan.

Memperkirakan dan merencanakan pemeliharaan adalah kegiatan penting jika perangkat lunak diperlukan untuk berfungsi dengan baik sepanjang kehidupan yang diharapkan. Bahkan dengan anggaran terbatas, rencana dapat dibuat untuk menggunakan sumber daya yang tersedia dengan cara yang paling efisien dan produktif. Melihat diagram di atas, Anda dapat melihat bahwa tidak hanya beberapa input yang berdampak pada pemeliharaan, tetapi ada beberapa output kunci yang menyediakan informasi yang diperlukan untuk merencanakan upaya pemeliharaan yang sukses.

6. Kesimpulan Kesimpulan dari artikel ini adalah:

Pemeliharaan perangkat lunak dapat dimodelkan menggunakan metode sederhana seperti Level of Effort Staffing, tetapi teknik ini memiliki kelemahan yang signifikan.

o Biaya pemeliharaan perangkat lunak dapat sangat dipengaruhi oleh keputusan manajemen selama proses pengembangan.

o Pemeliharaan perangkat lunak dapat diestimasi secara akurat menggunakan proses parametrik.

o Pemeliharaan perangkat lunak paling baik dimodelkan ketika pengembangan dan keputusan manajemen digabungkan dengan teknik estimasi biaya parametrik.

REFERENSI [1] Konsep dan Praktik Perawatan Perangkat Lunak (Edisi Kedua) oleh Penny Grubb dan Armstrong Takang, World Scientific, 2005.

[2] Memperkirakan Sistem Intensif Perangkat Lunak; Richard Stuzke, 2005, Addison-Wesley.

[3] Lloyd Huff, George Novak; Lockheed Martin Aeronautics; Lockheed Martin Aeronautics Performance Based Software Sustainment untuk F-35 Lightning II.

[4] G. Edward Bryan, "CP-6: Kualitas dan Ukuran Produktivitas dalam Siklus Hidup 15 Tahun dari Sistem Operasi," Kualitas Perangkat Lunak Jurnal 2, 129-144, Juni 1993.

[5] Ukuran Perangkat Lunak, Estimasi, dan Manajemen Risiko; Daniel D. Galorath, Michael W. Evans, 2006, Auerbach Publications.

Leave a Reply

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