Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Software adalah sekumpulan data elektronik berupa program (instruksi untuk menjalankan perintah) yang disimpan dan diatur oleh komputer. Software quality adalah kesesuaian yang diharapkan dari semua software yang akan dibangun dalam hal fungsional yang diutamakan, standar pembangunan software yang terdokumentasi dan karakteristik software itu sendiri.

Kualitas perangkat lunak dapat dinilai melalui ukuran-ukuran dan metode-metode tertentu, serta melalui pengujian-pengujian software. Salah satu tolak ukur kualitas perangkat lunak adalah ISO 9126, yang dibuat oleh International Organization for Standardization (ISO) dan International Electrotechnical Commission (IEC).

ISO 9126 adalah standar terhadap kualitas perangkat lunak yang diakui secara internasional. ISO 9126 mendefinisikan kualitas produk perangkat lunak, model, karakteristik mutu, dan metrik terkait yang digunakan untuk mengevaluasi dan menetapkan kualitas sebuah produk software. Selain itu, standar ISO juga harus dipenuhi dari sisi manajemen. Jika manajemennya tidak memenuhi standar ISO maka hasil kerjanya pun tidak dapat diberikan sertifikat standar ISO.

Faktor kualitas menurut ISO 9126 meliputi enam karakteristik kualitas sebagai berikut:

  1. Functionality (Fungsionalitas). Kemampuan perangkat lunak untuk menyediakan fungsi sesuai kebutuhan user dan memuaskan user.
  2. Reliability (Kehandalan). Kemampuan perangkat lunak untuk mempertahankan tingkat kinerja tertentu/ performance dari software (ex: akurasi, konsistensi, kesederhanaan, toleransi kesalahan).
  3. Usability (Kebergunaan). Kemampuan perangkat lunak untuk dipahami, dipelajari, digunakan, dan menarik bagi pengguna.
  4. Efficiency (Efisiensi). Kemampuan perangkat lunak untuk memberikan kinerja yang sesuai dan relatif terhadap jumlah sumber daya yang digunakan pada saat keadaan tersebut (ex: efisiensi penyimpanan).
  5. Maintainability (Pemeliharaan). Kemampuan perangkat lunak untuk dimodifikasi. Modifikasi meliputi koreksi, perbaikan atau adaptasi terhadap perubahan lingkungan, persyaratan, dan spesifikasi fungsional (ex: konsistensi).
  6. Portability (Portabilitas). Kemampuan perangkat lunak untuk ditransfer dari satu lingkungan ke lingkungan lain atau kemampuan software beradaptasi saat digunakan di area tertentu (ex: self documentation, teratur).

Masing-masing karakteristik kualitas perangkat lunak model ISO 9126 dibagi menjadi beberapa sub-karakteristik kualitas, yaitu:

ISO 9126-Functionality

SUB-KARAKTERISTIK

DESKRIPSI

Suitability Kemampuan perangkat lunak untuk menyediakan serangkaian fungsi yang sesuai untuk tugas-tugas tertentu dan tujuan pengguna.
Accuracy Kemampuan perangkat lunak dalam memberikan hasil yang presisi dan benar sesuai dengan kebutuhan.
Security Kemampuan perangkat lunak untuk mencegah akses yang tidak diinginkan, menghadapi penyusup (hacker) maupun otorisasi dalam modifikasi data.
Interoperability Kemampuan perangkat lunak untuk berinteraksi dengan satu atau lebih sistem tertentu.
Compliance Kemampuan perangkat lunak dalam memenuhi standar dan kebutuhan sesuai peraturan yang berlaku.

ISO 9126-Reliability

SUB-KARAKTERISTIK

DESKRIPSI

Maturity Kemampuan perangkat lunak untuk menghindari kegagalan sebagai akibat dari kesalahan dalam perangkat lunak.
Fault tolerance Kemampuan perangkat lunak untuk mempertahankan kinerjanya jika terjadi kesalahan perangkat lunak.
Recoverability Kemampuan perangkat lunak untuk membangun kembali tingkat kinerja ketika terjadi kegagalan sistem, termasuk data dan koneksi jaringan.

ISO 9126-Usability

SUB-KARAKTERISTIK

DESKRIPSI

Understandibility Kemampuan perangkat lunak dalam kemudahan untuk dipahami.
Learnability Kemampuan perangkat lunak dalam kemudahan untuk dipelajari.
Operability Kemampuan perangkat lunak dalam kemudahan untuk dioperasikan.
Attractiveness Kemampuan perangkat lunak dalam menarik pengguna.

ISO 9126-Efficiency

SUB-KARAKTERISTIK

DESKRIPSI

Time behavior Kemampuan perangkat lunak dalam memberikan respon dan waktu pengolahan yang sesuai saat melakukan fungsinya.
Resource behavior Kemampuan perangkat lunak dalam menggunakan sumber daya yang dimilikinya ketika melakukan fungsi yang ditentukan.

ISO 9126-Maintainability

SUB-KARAKTERISTIK

DESKRIPSI

Analyzability Kemampuan perangkat lunak dalam mendiagnosis kekurangan atau penyebab kegagalan.
Changeability Kemampuan perangkat lunak untuk dimodifikasi tertentu.
Stability Kemampuan perangkat lunak untuk meminimalkan efek tak terduga dari modifikasi perangkat lunak.
Testability Kemampuan perangkat lunak untuk dimodifikasi dan divalidasi perangkat lunak lain.

ISO 9126-Portability

SUB-KARAKTERISTIK

DESKRIPSI

Adaptability Kemampuan perangkat lunak untuk diadaptasikan pada lingkungan yang berbeda-beda.
Instalability Kemampuan perangkat lunak untuk diinstal dalam lingkungan yang berbeda-beda.
Coexistence Kemampuan perangkat lunak untuk berdampingan dengan perangkat lunak lainnya dalam satu lingkungan dengan berbagi sumber daya.
Replaceability Kemampuan perangkat lunak untuk digunakan sebagai sebagai pengganti perangkat lunak lainnya.

Referensi:

http://fxekobudi.net/ilmu-komputer/kualitas-perangkat-lunak-model-iso-9126/

https://sqaindonesia.wordpress.com/2010/03/04/faktor-faktor-standart-perangkat-lunak-menurut-iso-9126/

http://nurdwirahmawati.weblog.esaunggul.ac.id/2014/10/21/kualitas-software-atau-perangkat-lunak/

Junyati

KUALITAS PERANGKAT LUNAK:

Definisi, Pengukuran dan Implementasi

Definisi

Berbagai macam definisi kualitas perangkat lunak (software quality) tergantung dari mana pemakai (user) memandang dan melihat sesuai dengan kebutuhannya. Menurut Crosby (1979:34) mendefinisikan kualitas atau mutu sebagai “conformance to requirements”. Selama seseorang dapat berdebat tentang perbedaan antara kebutuhan, keinginan dan kemauannya, definisi kualitas harus mempertimbangkan perspektif pemakai tersebut. Kunci utama pertanyaan untuk sebuah definisi kualitas adalah siapa pemakainya, apa yang penting bagi merekadan bagaimana prioritasnya tentang metode apa yang dibangun, dibungkus untuk mendukung sebuah produk?

 Untuk menjawab pertanyaan tersebut, kita harus mengenali herarki dari kualitas perangkat lunak. Pertama, suatu produk perangkat lunak harus menyediakan fungsi suatu jenis dan waktu yang sama ketika pemakai memerlukannya. Kedua, produk harus berjalan. Jika produk memiliki kecacatan maka produk tersebut tentunya tidak ada konsistensi kelayakan. Para pemakai tidak akan menggunakannya dengan mengabaikan atribut-atribut yang menyertainya. Hal tersebut tidak berarti bahwa kecacatan selalu menjadi prioritas yang paling utama dalam menolak suatu produk tetapi akan menjadi sangat penting dalam melihat layak atau tidaknya. Jika tingkatan cacat minimum belum dicapai maka berbagai hal tidak ada yang perlu dipertimbangkan. Di luar ambang kualitas tersebut, bagaimanapun juga sesuatu yang berhubungan dengan pertimbangan dan penilaian cacat suatu produk perangkat lunak seperti halnya kegunaan, kecocokan, kemampuan, dan lainnya tergantung pada pemakai tersebut memandang dan menilainya termasuk didalamnya aplikasinya dan lingkungan software yang menyertainya (Humphrey, 1994).

The Institute of Electrical and Electronic Engineers (IEEE) mendefinisikan

kualitas sebagai “the degree to which a system, component or process meets customer or user needs or expectations” (IEEE90). Definisi dari IEEE digunakan dalam konteks suatu sistem perangkat lunak secara rinci. kualitas adalah suatu atribut dari sistem yang berjalan yang sangat erat kaitannya dengan resiko. Semakin tinggi resiko yang didapatkan dan kemudian dikuranginya maka akan tinggi kualitas yang dihasilkannya. Dengan cara yang sama, lebih cepat resiko dikenali dan dikurangi, akan lebih tinggi pula kualitasnya. Hasil dari sebuah aktivitas yang terencana, bukan kejadian yang spontan berbanding terbalik dengan delivery date 85% kesalahan ada pada proses,15% pada pada SDM.

Menurut definisi dalam Steve McConnell’s Code Complete membagi perangkat lunak ke dalam dua hal yaitu: : internal dan external quality characteristics. Karakteristik kualitas eksternal merupakan bagian-bagian dari suatu produk yang berhubungan dengan para pemakainya, sedangkan karakteristik kualitas internal tidak secara langsung berhubungan dengan pemakai. Software Quality didefinisikan sebagai: kesesuaian yang diharapkan pada semua software yang dibangun dalam hal fungsi software yang diutamakan dan unjuk kerja software, standar pembangunan software yang terdokumentasi dan karakteristik yang ditunjukkan oleh software. Definisi ini menekankan pada 3 hal yaitu:

1. kebutuhan software adalah fondasi ukuran kualitas software, jika software

    Tidak sesuai dengan kebutuhan yang ditentukan maka kualitaspun kurang

2. jika menggunakan suatu standar untuk pembangunan software maka jika

    software tidak memenuhi standar tersebut maka dianggap kurang berkualitas

3. seringkali ada kualitas yang secara langsung diutarakan (tersirat) seperti

    kemudahan penggunaan dan pemeliharaan yang baik. Kualitas software

    dipertanyakan jika tidak memenuhi kebutuhan ini.

Sedangkan definisi kualitas menurut The International Standards Organization (ISO) mendefinisikannya sebagai: “the totality of features and characteristics of a product or service that bear on its ability to satisfy specified or implied needs [11].” ISO menyoroti pada fitur-fitur dan karakteristik dari produk atau layanan dalam kemampuannya memenuhi kebutuhan yang ditentukan. menyediakan model yang berbasikan obyek dalam 3 konteks dasar yaitu: quality, requirements dan characteristics. Standar dapat membantu mendefinisikan suatu terminologi, seperti halnya kata “kualitas” (quality). Meskipun demikian, rata-rata suatu kata tertentu tidak menggunakan standar adalah sering sesuai dengan arti yang dimaksud. Hal ini juga benar untuk definisi ISO 8204 untuk mutu: “Keseluruhan karakteristik dari suatu kesatuan dalam kemampuannya untuk memenuhi dan memuaskan pemakai yang dinyatakan dan disiratkan dalam suatu kebutuhan.“ Makna tersebut artinya, diperlukan suatu kualitas produk perangkat lunak yang mempunyai karakteristik tertentu yang dihubungkan dengan kebutuhan pemakai dan membuat puas penggunanya. Kualitas perangkat lunak adalah keberadaan karakteristik dari suatu produk ang dijabarkan dalam kebutuhannya, artinya kita harus melihat terlebih dahulu karakteristik-karakteristik apa yang berhubungan atau tidak dengan kebutuhankebutuhan yang diiinginkan oleh pemakai. Karakteristik yang dimaksud yaitu contra-productive characteristics dan neutral characteristic. Mengetahui

karakteristik tersebut diperlukan untuk mengurangi kontra produktif dari kualitas perangkat lunak yang dimaksud dan relevan atau tidak perangkat lunak tersebut untuk kebutuhan suatu organisasi. Tidak hanya adanya keberadaan karakteristik tersebut tetapi juga tidak adanya kontra produktif dari suatu karakteristik dari suatu perangkat lunak yang diinginkan (Petrasch, 1999: 2).

Kebutuhan dan karakteristik berperan penting dalam mendefinisikan suatu kualitas. Oleh karena itu, suatu model yang berbasiskan obyek bermanfaat dalam pemahaman yang lebih baik untuk masalah ini. Gambar di bawah menunjukkan suatu produk perangkat lunak, dimana untuk memenuhi suatu kebutuhan diperlukan karakteristik yang sesuai. Keberadaan hubungan antara kebutuhan dan karakteristik menjadikan dimungkinkannnta statemen yang jelas tentang kualitas suatu produk. 

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Hal lain yang perlu diperhatikan dalam kualitas perangkat lunak adalah quality assurarance (QA) yang merupakan cctivity of providing evidence needed to establish confidence mong ll concerned,that quality-related activities are being performed effectively (J.M.Juran). Selain itu harus adanya software quality management (SQM). Tujuan dari SQM adalah untuk mengembangkan suatu pemahaman kuantitatif dari kualitas proyek produk perangkat lunak dan mencapai tujuan spesifik kualitasnya yang digambarkan dalam table sederhana berikut:

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Pengukuran Kualitas Perangkat Lunak

Sistem dari kualitas perangkat lunak terintegrasi dalam tiga disiplin aplikasi yaitu: pemodelan proses pengembangan (process), pemodelan pengukuran produk (product), dan pemodelan manajemen dan interaksi manusia (human). Pemahaman suatu disiplin melibatkan pembangunan model, pengujian model dan pelajaran untuk dipahami dalam aplikasi yang nyatal. Pengembang kualitas prima perangkat lunak harus berhadapan dengan unsur-unsur matriks berikut:

Model [M] [M*PROCESS] [M*PRODUCT] [M*HUMAN]

Testing [T] Process Product Human = [T*PROCESS] [T*PRODUCT]   [T*HUMAN]

Data [D] [D*PROCESS] [D*PRODUCT] [D*HUMAN]

Unsur-unsur perangkat lunak utama dari sistem kualitas perangkat lunak ditunjukkan pada gambar di bawah. Pengintegrasian dari semua unsur-unsur system kualitas memerlukan suatu model. Permasalahannya untuk diperbaiki oleh dua model berikut (1) penanganan kompleksitas dalam disiplin dari sistem kualitas dantunsur-unsurnya dan (2) penunjukan beberapa kelemahan dari model existing process. Kompleksitas proses pengembangan dan dokumentasinya serta perubahan dokumentasi selama pemeliharaan adalah permasalahan penting dalam peningkatan kualitas. Dokumentasi yang dievaluasi sering sangat banyak dan kompleks. Oleh karena itu, hubungan kompleksitas antara produk data teknis, dokumentasi perencanaan, pengujian kebutuhan dan tahapan unsur-unsur life cycle pengembangan yang berbeda mengakibatkan dokumentasi ini sulit untuk dievaluasi dalam meyakinkan semua aktivitas telah cukup dikerjakan. Dokumentasi menyediakan komunikasi antar semua kelompok terkait dengan pengembangannya dan kendali proses proyek tersebut. Schweiggert mencatat beberapa pertimbangan untuk krisis dokumentasi:

“Software in the application process must be constantly adapted and altered. The

maintenance programmer usually does not have the time alteration to

documentation. Often suitable tools are not available either. This causes the

quality of documentation to suffer”

Metoda tradisional untuk verifikasi kualitas, seperti checklist bisa gagal dalam proses pengembangan software yang kompleks. Audit dan review tidak bisa dilakukan tanpa menggunakan bantuan dan alat yang membantu mengidentifikasi pemenuhan standar dan prosedur. Lebih dari itu, kompleksitas proses pengembangan dan perubahan yang tak terkontrol dari unsur-unsur proses secara negatif berdampak pada kualitas. Lifecycle pengembangan software yang berbeda dapat diusulkan. Hal ini dapat memungkinkan adanya perbedaan motivasi, kekuatan dan kelemahan. Tidak ada model lifecycle yang universal disesuaikan dengan lingkungan pengembangannya. Dalam model lifecycle tradisional, hubungan antara tahapan unsur-unsur lifecycle pengembangan software yang berbeda tidaklah cukup terwakili. Oleh karena itu, sulit untuk menguraikan efek segala perubahan dalam kebutuhannya yang ditetapkan atas kualitas, keselamatan dan sasaran hasil dari perangkat lunak. Lebih dari itu, keberadaan komputer dapat membantu untuk aplikasi model proses yang tidak fleksibel dan sulit untuk ditangani karena kekompleksitasnya. Dalam lifecycle pengembangan software, Identifikasi hubungan antara kelompok organisasi sangat penting untuk beberapa

pertimbangan berikut: (1) Pengembangan Proses harus berhadapan dengan kompleksitas dan perubahan kebutuhan, pengujian metoda, teknologi, ukuran dan lain lain; (2) Kesalahan perangkat lunak yang dihasilkan baik dalam suatu tahapan proses pengembangan software maupun sebagai alat penghubung antara dua tahapan; (3) Dukungan kuat dari manajemen puncak merupakan suatu faktor utama dalam mempengaruhi proses pengembangan tersebut. Menururut Wahono (2006), Deras masuknya produk perangkat lunak dari luarnegeri di satu sisi menguntungkan pengguna karena banyaknya pilihan produk dan harga. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat lunak yang masuk ke Indonesia. Demikian juga dengan produk-produk perangkat lunak lokal, tentu akan semakin meningkat daya saing internasionalnya apabila pengembang dan software house di Indonesia mulai memperhatikan masalah kualitas perangkat lunak ini. Kualitas perangkat lunak (software quality) adalah tema kajian dan penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak (software engineering). Kajian dimulai dari apa yang akan diukur (apakah proses atau produk), apakah memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter pengukuran kualitas perangkat lunak. Bagaimanapun juga mengukur kualitas perangkat lunak memang bukan pekerjaan mudah. Ketika seseorang memberi nilai sangat baik terhadap sebuah perangkat lunak, orang lain belum tentu mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin berorientasi ke satu sisi masalah (misalnya tentang reliabilitas dan efisiensi perangkat lunak), sedangkan orang lain yang menyatakan bahwa perangkat lunak itu buruk menggunakan sudut pandang yang lain lagi (usabilitas dan aspek desain).

Apa yang diukur?

Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan perangkat lunak ( process) dan hasil produk yang dihasilkan (product). Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang diharapkan oleh pengguna. Dari sudut pandang produk, pengukuran dapat dilakukan dengan cara sebagai berikut:

Parameter dan metode pengukuran menurut Kelvin dalam Wahono (2006), When you can measure what you are speaking about, and express it in numbers, you know something about it. But when you can not measure it, when you can not express it in numbers, your knowledge is of a meagre and unsatisfactory kind. Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall, atribut tersusun secara hirarkis, dimana level atas (high-level attribute) disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat (cause-effect). Tabel berikut menunjukkan daftar lengkap faktor dan kriteria dalam kualitas perangkat lunak menurut McCall

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria

dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan. Rumus

pengukuran yang digunakan adalah:

Fa = w1c1 + w2c2 + … + wncn

Dimana:

Fa adalah nilai total dari faktor a

wi adalah bobot untuk kriteria i

ci adalah nilai untuk kriteria i

Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai

berikut:

Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor

Tahap 2: Tentukan bobot

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak
dari setiap kriteria (biasanya 0 <= w <= 1)

Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <=10)

Tahap 4: Berikan nilai pada tiap kriteria

Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn

Contoh pengukuran perangkat lunak

Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran kualitas perangkat lunak dari faktor usabilitas (usability). Yang akan diukur adalah dua buah perangkat lunak yang memiliki fungsi untuk mengkontrol peralatan elektronik (electronic device). Perangkat lunak yang pertama bernama TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran dapat dilihat pada Table 3 dan 4.

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Dari penghitungan yang ada di Tabel 4, dapat kita simpulkan bahwa dari faktor usabilitas, kualitas dari perangkat lunak bernama TukangKontrol lebih baik daripada Caktrol. Nilai total TukangKontrol untuk faktor usabilitas adalah 16.8, sedangkan Caktrol adalah 10.2 (dari maksimum total nilai 20).

Mengapa Software Quality Engineering perlu dipikirkan?

Penerapan suatu rumusan pemrograman sederhana jawaban bisa diperkenalkan cara yang berikut:

RISK= F (1/quality)

Atau kualitas yang ditingkatkan untuk mengurangi resiko

Suatu metode di mana hasil dari resiko dari kualitas yang pudar dapat dimanifestasikan lebih banyak, bagaimanapun untuk seorang pemakai yang berpengalaman dikenali dalam contoh berikut:

– Kerugian Sosial atau profesional (nformasi/data, waktu, uang, pekerjaan dll.)

– Kerugian kesehatan atau kehidupan ( contoh: pasien over-X-rayed dalam suatu

   rumah sakit)

Jelaslah bahwa sebagai pemakai mungkin akan bermimpi untuk mengharapakan adanya bug-free yang merupakan tingkatan paling tinggi kualitasnya dengan harga yang serendah-rendahnya. Akan tetapi seberapa besar hal tersebut terjadi, tergantung dari SQE oleh perusahaan pengembangan software. Paling mungkin ada suatu kesempatan untuk tidak membeli perangkat lunak yang jelas ada cacat produksinya. Rendahnya kualitas perangkat lunak merupakan resiko yang didapat suatu organisasi yang membelinya dan terkadang suatu pengembang ataupun supplier tidak ambil pusing bahkan tidak mau disalahkan. Berdasarkan pengalaman, resiko yang paling besar sebagai hasil dari rendahnya kualitas perangkat lunak sering didapatkan oleh pemakai dan hanya sedikit yang didapatkan oleh penyalur perangkat lunak. Karena itu harus ada suatu kompromi antara developer atau supplier dan pemakai tentang perangkat lunak yang akan dibeli sehingga diharapkan tidak ada yang dirugikan dari transaksi yang terjadi. Menentukan Kualitas Perangkat Lunak Dipandang dari sudut hipotesis, para ahli dalam membuat dan menentukan kualitas perangkat lunak sebaiknya menerapkan, mengukur, mengevaluasi dan meningkatkan mutu perangkat lunak sepanjang lifecycle-nya. Pengetahuan yang luas tentang rekayasa perangkat lunak memerlukan suatu pendekatan yang terstruktur dan sistematis dengan mempertimbangkan pengalaman yang diperolehnya. Jika mungkin, disesuiakan dengan praktek industri sebenarnya. Suatu pendekatan terstruktur tidak terbatas pada tiga komponen utama yang terpusat pada inti pengetahuan perangkat lunak. Contohnya komponen Quality Requirements didapatkan dengan adanya prasyarat:

– Kualitas kebutuhan (Quality requirements)

– Pengukuran kualitas dan instrument evaluasi (Quality measurement and

   evaluation instruments)

– Implementasi kualitas dalam lifecycle (In-lifecycle quality implementation)

Pengetahuan dalam mendapatkan komponen Quality requirement (QR) sangat diperlukan terutama bagi kalangan ahli software dalam mempertimbangkan dan memperoleh kebutuhan yang berkualitas sehingga benar-benar didapatkan high-level stakeholder’s requirements. Karena itu untuk mendapatkan kemudian untuk QR digambarkan pengukuran kualitas dalam gambar di bawah ini:

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Model dekomposisi yang diusulkan didasarkan pada model kualitas dari ISO/IEC 9126 dalam konjungsi dengan standar TL 9000, dimana kontribusi dari penggunaan QR adalah untuk menetapkan kebutuhan mutu eksternal (External Quality requirements), yang mana pada gilirannya berperan untuk menetapkan kebutuhan mutu internal (Internal Quality requirements). Model tersebut didokumentasikan dengan baik sehingga relatif mudah untuk dipelajari dan digunakan akan tetapi sedikit statis dalam perubahannya. Karena itu, ahli SQ yang baik seharusnya mengetahuinya tidak hanya apa? tetapi juga bagaimana? Pendekatan ini ditujukan oleh model tersebut untuk proses praktis dalam melukiskan dan mengendalikan kualitas kebutuhan

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Pada gambar di atas, anak panah dengan garis yang tidak putus-putus menunjukkan alur tentang ” bagaimana”, yaitu menanyakan tentang eksekusi dekomposisi kebutuhan. Yang ada dalam kotak berisi tentang pertanyaan ” apa ” , yaitu menggambarkan kebutuhan apa yang diakibatkan oleh proses dekomposisi. Sedangkan anak panah dengan garis putus-putus menandai adanya alur pokok dari traceability kebutuhan. Pengetahuan teoritis dan praktis yang menjawab pertanyaan diatas membutuhkan ahli yang berkompeten tentang SQ untuk mengatur proses definisi dan analisis kebutuhan. Komponen dari The Quality measurement and evaluation instruments memiliki tujuan untuk mendidik para ahli SQ tentang keberadaan

model kebutuhan dan mengukur pemilihan perangkat lunak dalam proses mendukung aktivitasnya. Demikian juga, dua unsur tersebut sebaiknya didokumentasikan sehingga mudah untuk dipelajari walau sedikit statis. Rancang bangun merupakan bagian dari pengetahuan dimana pemetaan tentang suatu instrumen ke dalam tahapan lifecycle perangkat lunak trlihat pada gambar di bawah sangat sedikit didokumentasikan dan memerlukan riset lebih lanjut .

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Komponen terakhir dari hasil lifecycle quality implementation diakibatkan oleh dua Komponen yang sebelumnya di mana pengetahuan dasar telah didaptkan. Implementasi sekarang memerlukan aplikasi yang praktis tidak sekedar dengan

pengetahuan tersebut tetapi juga dalam proses pengembangan perangkat lunak.

IMPLEMENTASI KUALITAS SOFWARE UNTUK OPEN-SOURCE

Sepuluh tahun terakhir, proses pengembangan open-source telah muncul sebagai suatu pendekatan yang efektif dalam mengurangi waktu maupun menekan biaya desain, implementasi serta biaya penerapan quality assurance dalam pembuatan perangkat lunak, baik jenis perangkat lunak OS, compiler, bahasa pemrograman maupun software aplikasi lainnya. Sebagai contoh berikut ini merupakan jenis perangkat lunak yang paling banyak digunakan:

_ Sistem operasi, contohnya: Linux, FreeBSD dan NetBSD

_ Server web, contohnya:Apache dan JAWS

_ Basis Data (DBMS), contohnya: MySQL

_ Compiler, contohnya: GNU C/C++

_ Editors, contohnya: GNU emacs

_ Language processing tools, contohnya: Perl, GAWK, Flex dan Bison

_ System/network support tools, contohnya: Samba, Sendmail dan Bind.

Berbagai macam jenis open-source tersebut disebarluaskan dengan berbagai macam skema lisensi dan model bisnis yang beraneka ragam. Secara umum, Perangkat lunak tersebut didistribusikan kepada komunitas pemakai untuk berbagai macam pengembangan dan aktifitas software quality assurance yang diperformansi secara internal oleh provider software. Lebih dari itu, berikut ini merupakan kunci sukses dari beberapa contoh proyek dari open-source:

_ Dibuat dengan tujuan umum dan komoditas infrastruktur software yang

jelas dan mudah dengan kebutuhan dan API mudah diketahui. Contohnya:

requirements dan APIs for UNIX/POSIX operating systems, Web servers,

C/C++ compilers/linkers serta object request broker (ORB) mudah

dimengerti oleh para pengembang software. Demikian pula dibutuhkan

sedikit waktu dan usaha untuk aktifitas pengembangan software yang

mahal, seperti analisa kebutuhan atau spesifikasi desain antarmukanya.

Lebih dari itu, ada suatu kuntungan dari sisi pemrogramannya sehingga para

pamakai yang berbakat dalam pengembangan software lebih menikmati dari

tujuan umum dari infratruktut teknologi perangkat lunak ini.

_ Open-source melayani komunitas umum dimana kebutuhan akan software

tidak dijumpai dipasaran. Tentunya komunitas dengan teknologi tertentu,

seperti ilmuwan atau bahkan industri pertahanan, perangkat lunak yang

dibutuhkannya sering tidak dijumpai pasaran atau jika ada kemampuan

komunitas tersebut tidak sebanding dengan harga yang tawarkan, lebihlebih

untuk ukuran masyarakat Indonesia. Contohnya: Linux-based Beowulf

clusters yang dikembangkan untuk komunitas scientific computing yang

merupakan aplikasi komputasi mutakhir yang berjalan di atas perangkat

keras dengan konfigurasi infrastruktur perangkat lunak yang tidaklah secara

luas didukung via vendor IT di pasar umum.

_ Open-source dikerjakan oleh suatu komunitas pemakai yang trampil dan

terdidik. Anggotanya terdiri dari komunitas pemakai tertentu yang

mempunyai pengetahuan dan ketrampilan pengembangan software yang

pantas dipertimbangkan dari segi pengembangan umum, seperti compiler,

debuggers, configuration managers, online bug tracking systems, memory

leak/validation tools, dan performance profilers. Demikian juga, mereka

lancar mekanisme komunikasi terbukanya, seperti web/ftp-sites and

mailing lists, dan advanced Internet serta kemanisme kolaborasi seperti

Netmeeting atau instant messaging. Ketika anggota dari komunitas pemakai

yang secara teknis canggih dalam menghadapi bugs atau permasalahan

konfigurasi perangkat lunak, mereka tidaklah kurang baik menyelesaikan

permasalahan tersebut dan meluncurkan perubahan perangkat lunak

tersebut dengan segera.

Tantangan Perangkat Lunak Open-Source

Walaupun proyek open-source sudah banyak yang berhasil, pengalaman beberapa orang yang bekerja pada beberapa proyek open-source proyek lebih suatu decade telah menunjukkan perkembangan perangkat lunak open-source tersebut menghadapi tantangan-tantangan sebagai berikut berikut:

1. Berisi biaya-biaya evolusi dan pemeliharaan jangka panjang yang berhubungan dengan quality assurance ( QA). Secara umum, Tujuan perangkat lunak open-source adalah mirip dengan jenis perangkat lunak lainnya, yaitu., membatasi kesalahan regresi (limit regression errors), mendukung kepercayaan end-user dan goodwill serta memperkeci biayal pengembangan dan biaya QA. Bagaimanapun juga, untuk memastikan konsistensi kualitas perangkat lunak open-source maka perlu dikembangkan:

-Frekuensi pengeluaran beta (Frequent beta releases). Landasan opensource adalah pengulangan umpan balik yang singkat antar para pemakai dan pengembang utama sehingga mengakibatkan sering adanya pengeluaran versi ” beta” beberapa kali dalam satu bulan. Walaupun jadwal ini membuat puas end-users yang menerima patches yang cepat untuk bugs-nya dapat membuat frustasi end-users lainnya.

-Platforms-independence. Landasan perangkat lunak open-source adalah platform-independence-nya yang berasal dari open systems disbanding kepemilikan systems. Dukungan untuk platform-independence dapat menghasilkan Sisyphean task untuk memelihara suatu software opensource yang berdasarkan pada basis operasional di samping perubahan pada sistem operasi dan platform compiler.

-Dukungan untuk compile-time yang banyak dan konfigurasi run-time (Support for many compile-time and run-time configurations).Ketersediaan perangkat lunak dalam proyek open-source mendorong pengembang utama untuk meningkatkan banyaknya pilihan untuk konfigurasi dan subsetting perangkat lunak tersebut pada compile-time dan run-time. Meskipun fleksibel dalam peningkatan software aplikasi dengan penggunaanya yang luas akan memperbesar biaya QA dalam kaitannya dengan kombinasi jumlah alur kode yang harus diuji. Lebih dari itu, perancangan open-source memerlukan biaya yang besar, anggaran QA dalam kaitannya dengan minimnya anggaran yang dikeluarkan sehingga sebagian besar versi dan varian baru sering terlambat keluar.

2. Kepastian koheren system-wide properties. Secara alami, banyak opensource dirancang dan dibuat untuk komunitas yang umum dengan standardisasi common APIs dan kepastian semantik konsisten ketika komponen berlainan terintegrasi bersama-sama. Sejak proyek open-source tumbuh berkembang, kontribusi yang didasarkan pada pengembang dan para pemakai, usaha yang cukup harus dikeluarkan untuk memastikan penggunaan komponen yang sama dan integritas arsitektur diantara masyarakat pemakai.

SQA dalam Pengembangan Perangkat Lunak Open-Source

Software Quality Assurance (SQA) sendiri memiliki pengertian:

“..a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures. SQA includes the process of assuring that standards and procedures are established and are followed throughout the software acquisition life cycle. Compliance with agreedupon standards and procedures is evaluated through process monitoring, product evaluation, and audits. Software development and control processes should include quality assurance approval points, where an SQA evaluation of the product may be done in relation to the applicable standards (NASA, http://jira.atlassian.com/secure/attachment/17146/sqa+activities.txt)

Menurut Santoso (2007), Ide dasar dari OSS sebenarnya sederhana, yaitu “Ketika para programmer dapat membaca, mendistribusikan, dan memodifikasi source code dari perangkat lunak, makaperangkat lunak akan ber-‘evolusi’. Orangorang memperbaikinya, beradaptasi dengannya, dan memperbaiki atau membuang berbagai kesalahan (bugs). Dan bila hal ini diimplementasikan dalam slow pace pengembangan perangkat lunak konvensional, akan terlihat mengagumkan (OSI, 2006). Penerimaan yang luas dari masyarakat terhadap OSS terangkum dalam studi yang disebut GRAM(Generally Recognized as Mature) OSS/FS programs (Wheeler dalam Santoso: 2006). Dimana kriteria yang digunakan adalah penggunaannya yang signifikan (dalam market area), pengembangan atau dukungan yang signifikan, fungsionalitas yang matang, keamanan, kualitas, dan biaya. Di samping itu, studi terhadap OSS dalam perkembangan terakhir menunjukkan adanya pergeseran (transformasi) dari OSS menuju bentuk yang commercially viable (OSS 2.0). Studi tersebut mengidentifikasi bagaimana OSS 2.0 dapat mengakomodasi transformasi yang terjadi dengan jalan mendapatkan keseimbangan antara nilai keuntungan komersial (PS) dan nilai-nilai komunitas open source (OSS). Pada siklus pengembangan OSS, terdapat beberapa tahapan yang perlu dilalui, yaitu: Code: penulisan code dan dikirim pada komunitas OSS untuk direview. Review: merupakan salah satu kekuatan OSS, yaitu bersifat independent serta ada mekanisme peer review. Pre-commit test: jaminan bahawa semua kontribusi yang diberikan untuk membangun OSS telah melalui proses testing secara hati-hati sebelum mendapatkan status committed. Development release: kontribusi berupa kode dapat dimasukkan ke dalam rilis pengembangan dalam waktu yang relatif singkat sejak kode tersebut dikirimkan atau implementasi yang singkat ini menjadi motivasi tersendiri bagi developers. Parallel debugging: besarnya jumlah debuggers yang berpotensi dengan platform yang berbeda dan konfigurasi system menjamin bugs dapat ditemukan dan diperbaiki secara cepat. Production release: dalam kondisi yang relatif stabil, versi produksi dari sistem dirilis setelah melalui proses debugging.

Karakteristik SQA dalam Open-Source

Pengembangan OSS identik dengan proses versioning yang cepat, dikembangkan berbagai pihak yang berbeda di seluruh dunia, penggunaan log yang ketat, serta tim pengembang yang solid. Mekanisme pemeliharaan (maintainance) perangkat lunak berbasis open source dari berbagai belahan dunia dapat dijumpai pada SourceForge. SourceForge.net merupakan situs web pengembangan OSS terbesar di dunia, dimana dalamnya terdapat lebih dari 100,000 proyek dan lebih dari 1,000,000 pengguna yang teregister dengan sumber daya (resource) terpusat untuk mengatur proyek, issues, komunikasi, dan kode. SourceForge memiliki repository terbesar untuk kode dan aplikasi berbasis open source yang tersedia di Internet. SourceForge menyediakan hosting gratis bagi proyek-proyek pengembangan OSS. Esensi dari model pengembangan open source adalah rapid creation of solutions dalam lingkungan yang terbuka dan bersifat kolaboratif. Mekanisme kolaboratif dalam komunitas open source, yaitu tim pengembang dan pengguna menjanjikan standar kualitas yang tinggi, dan membantu penjaminan ‘keberlangsungan hidup’ jangka panjang (long-term viability) baik dalam hal data dan aplikasi. Sacha Labourey selaku JBoss General Manager EMEA memilikipandangan mengenai layanan open source (Big Market for Open Source Services) yaitu sebagai berikut:

_ Pertama, ada anggapan bahwa proses penjaminan kualitas perangkat lunak berbasis open source tidak terdefiniskan dengan baik. Proses penjaminan kualitas dalam open source berbeda dengan apa yang dilakukan pada pengembangan PS, namun tidak seburuk yang dibayangkan. Pada OSS, kita memiliki versi rilis yang begitu banyak dan banyak masukan berharga yang diperoleh dari pengguna. Bagaimanapun hal ini tidak cukup. Apa yang kita lakukan adalah mengkombinasikan keuntungan atau kelebihan dari open source dengan proses pengembangan perangkat lunak yang dilakukan secara profesional, yang kita sebut dengan Professional Open Source. Aktivitas ini meliputi testing, training, dan tahap-tahap pengembangan lainnya yang kita ketahui dari disain PS. Terdapat 4 (empat) cara bagaimana kita mendapatkan proyek; Pertama, kita mengambil proyek yang sudah atau sedang dikembangkan (existing project). Kita melakukannya dengan cara mempekerjakan tim pengembang (developers), sehingga kita dapat mengontrol kualitas dari proyek. Cara kedua adalah bagaimana memulai proyek dengan cara scratch in-house. Cara ketiga adalah terlibat dalam existing project. Cara keempat adalah mendapatkan PS dan menjadikannyaberbasis OSS.

_ Kedua, cara mengevaluasi atau melakukan assessment kualitas yang pada dasarnya merupakan kontribusi dari komunitas open source. Sistem assessment kualitas dapat didasarkan pada langkah-langkah melakukan assessment terhadap para kontributor untuk menjamin kualitas dari kontribusi yang diberikan. Untuk tiap-tiap proyek yang ditangani, perlu ada seorang pemimpin proyek, yang berwenang untuk menerima atau menolak kontribusi. Pada gambar berikut ini akan ditampilkan contoh mekanisme PMPL dalam pengembangan sebuah modul sebuah OSS.

Analisis Kualitas Source Code pada Pengembangan Software Open-source Linux

 Menurut Stamelos, dkk (2002) dalam jurnalnya yang berjudul Code quality analysis in open source software development menjelaskan sebagi berikut: pengembang software open-source mengklaim bahwa lebih baik perangkat lunak diproduksi menggunakan model open-source dari pada model tertutup tradisional. Bagaimanapun, ada keterangan empiris dalam mendukung klaim ini. Dalam paper ini, kami hadirkan hasil suatu studi kasus yang mengarahkan pada:

a. Pemahaman implikasi tentang kualitas struktural (structural quality)

b. Penggambaran keluar ttg keuntungan-keuntungan structural analisis kualita

    struktural kode yang ada pada pengembangan model open-source.

Studi kasus ini diimplementasikan pada open-source Linux dengan mengukur karakteristik kualitasnya (quality characteristics) dimana 100 aplikasi yang tertulis oleh Linux menggunakan alat pengukuran perangkat lunak dan membandingkan hasilnya dengan tools dari standard industri. Kasus lain pada studi ini adalah meneliti isu modular dari open-source sebagai karakteristik yang dipertimbangkan oleh pengembang software open-source yaitu dengan menganalisa hubungan antara ukuran komponen aplikasi dan kualitas yang dimiliki sampai pada kepuasan pemakai. Penentuan sampai taraf tertentu dan rata-rata ukuran komponen dari suatu aplikasi, secara negatif dihubungkan dengan kepuasan pemakai untuk aplikasi ini.

Pengembang open-source mendeskripsikan proses pengembangan software inovatif ini ( Bollinger et al., 1999) sebagai pilihan dari intensive spiral model (oehm, 1988). Bagaimanapun, tampaknya tidak ada resiko penilaian yang pernah dilakukan dan tidak ada tujuan terukur yang di-setting selama pengembangan software, sebagaimana diperlukan oleh model spiral oleh Boehm. Lebih dari itu, Bollinger dan para rekannya ( Bollinger et al., 1999) menunjukkan bahwa suatu kebutuhan penting untuk source program dari open-source adalah bahwa haruslah rigorously modular, self-contained dan self explanatory modular, untuk memungkinkan pengembangan pada web. Alasan lain untuk memperoleh kode kualitas (quality code) yang tinggi dari suatu proyek open-source bahwa langkah berikutnya adalah pemeliharaan produk terbuka dalam merujuk kebutuhan pasar. Dalam kasus ini, sistem kebutuhan harus lebih tepat, disain dan dokumentasi permintaan harus lebih bervariasi serta menuntut kode kualitas yang tinggi.Pada paper ini, kita memfokuskan pada isu yang terakhir yaitu tidak ada data yang telah diterbitkan dukungan berbagai klaim menyetujui atau menentang terhadap hadirnya open-source. Pengurangan koreksi yang cacat atas biaya-biaya yang dikeluarkan belum dicatat secara sistematis dan karakteristik kualitas yang diperlukan yaitu source program tidak ditunjukkan dalam analisa datanya. Akan tetapi beberapa studi kasus sudah mencoba untuk mengukur berbagai aspek source pada pengembangan open-source. Mockus rekannya ( Mockus et al., 2000) telah menguji developer participa-tion, core team size, productivity dan defect density. Godfrey& Tu ( 2000) sudah meneliti tingkat evolusi dari kernel Linux. Untuk studi kasus ini, digunakan Logiscope….(Telelogic, 2000), suatu perangkat menyeluruh yang mampu melakukan secara otomatis pada pengukuran kode dan perbandingan dengan standard programming yang telah didefinisikan  oleh pemakai. Lebih dari itu, Logiscope menyediakan pemrograman sendiri yang baku sebagai hasil dari kesimpulan empiris yang muncul setelah analisa terhadap berjuta-juta bentuk source program industri. Metodenya digunakan oleh beberapa organisasi besar untuk mengendalikan proses pemrogramannya. Melalui matrik struktural (structural metrics), lihat (Fenton& Pfleeger, 1997), Data dari program ini dikumpulkan untuk 10 metrik pengukuran kualitas komponen (component quality) sebagai berikut:

1. Jumlah statemen ( N_STMTS): untuk menghitung rata-rata jumlah executable statements tiap komponen [ 1-50].

2. Kompleksitas cyclomatic ( VG): sebagaimana digambarkan oleh McCabe ( 1976).

Hal tersebut merupakan suatu teori grafik yang didasarkan pada metrik yang menghadirkan banyaknya linier alur mandiri dalam suatu grafik yang dihubungkan, pada kasus ini, komponen pengendalian arus grafik. Dipertimbangkannya suatu indikator usaha yang diperlukan untuk memahami dan menguji komponen tersebut [ 1-15].

3. Tingkatan maksimum ( MAX_LVLS): untuk mengukur jumlah nesting dalam struktur kontrol dari suatu komponen. Nesting yang berlebihan mengurangi readability dan testability dari suatu komponen [ 1-5].

4. Jumlah alur ( N_PATHS): untuk menghitung rata-rata jumlah alur non-cyclic tiap komponen. Hal itu adalah indikator lain banyaknya test yang diperlukan untuk menguji suatu komponen [1- 80].

5. Lompatan tanpa syarat ( UNCOND_J): untuk menghitung banyaknya kejadian GOTO. Statemen jenis ini membantah prinsip [dari;ttg] programming structural untuk percontohan mengendalikan arus [ 0].

6. Frekuensi komentar (COM_R): hal ini digambarkan sebagai proporsi bentuk komentar ke executable statements [0.2-1].

7. Frekuensi kosa kata (VOC_F): digambarkan oleh Halstead ( 1975) sebagai pen;jumlahan banyaknya unique operands, n1, dan operator, n2, dimana penting bagi definisi program tersebut. Metriks ini disediakan pandangan komponen ukuran yang berbeda [1-4].

8. Panjangnya program (PR_LGTH): untuk mengukur panjang program sebagai penjumlahan banyaknya kejadian operator dan unique operands. Metrik ini menyediakan juga pandangan komponen ukuran lain [ 3-350].

9. Rata-rata ukuran ( AVG_S): untuk mengukur rata-rata ukuran statemen tiap komponen dan equal dengan PR_LGTH/N-STMTS [3-7].

10. Jumlah input/output ( N_IO): untuk menghitung banyaknya masukan (input) dan exit nodes suatu komponen. Kendali metrik ini sesuai dengan prinsip yang dikenal lainnya dari pemrograman terstruktur ( hanya satu input dan satu output yang diijinkan) [2].

Metode atau cara dalam kondisi default untuk mengukur masing-masing komponen dan mengevaluasinya terhadap empat kriteria utama, yakni Keterujian (testability) , kesederhanaan (simplicity), keterbacaan (readability) dan selfdescriptiveness pada penggunaan nilai-nilai yang terukur tersebut. Ukuran-Ukurantersebut diambil dari suatu standard internasional mengenai sub karakteristik dari

software quality ( Organisasi Standard Internasional ( ISO), 1991). Metode tersebut mengusulkan rekomendasi spesifik untuk masing-masing komponen perangkat lunak dan ukurannya. Tingkatan rekomendasi adalah sebagai berikut: ACCEPT, COMMENT, INSPECT, TEST, REWRITE.

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Bagaimanapun juga untuk analisis kualitas source program open-source, suatu penilaian global untuk masing-masing komponen, mengkombinasikan semua empat ukuran-ukuran dan bersifat lebih baik. Tujuannya menggunakan suatu mekanisme pengumpulan yang disatukan pada satu metode. Karena masing-masing ukuran, penilaian dihitung dengan memperhatikan metrik terkait, masing-masing dengan suatu bobot berbeda sesuai bahasa program yang digunakan. Sebagai contoh, rumus untuk testabilasnya adalah:

Testability = 40 * CVG + 40 * CMAX_LVLS + 20 * CN_IO

Yang mana CVG adalah suatu variabel biner yang mewakili pemenuhan (conformance) pada cakupan yang sudah dikenal oleh VG metrik. Dengan mengambil nilai ‘1’ pada pernyataan tersebut adalah benar dan ‘ 0’ sebagai cara lainnya. CMAX_LVLS dan CN_IO digambarkan dengan cara yang serupa. Pemenuhan untuk semua tiga metrik akan menghasilkan skor “100”. Nilai penjumlahan lain dengan mengkalkulasikan skor komponen akhir dari skor yang diperoleh untuk masing-masing ukuran.

Singkatnya, untuk masing-masing komponen hádala suatu skor akhir yang dihitung, berkisar antara 0 sampai 100, berdasar pada yang empat skor yang diperolehnya dari ukuran-ukuran tersebut di atas. Skor akhir antara 90 dan 100 merupakan suatu komponen yang bisa diterima. Sebaliknya, skor akhir 30 atau dibawahnya menandakan suatu komponen harus ditulis ulang sejak awal. Komponen yang melanggar beberapa cakupan metrik direkomendasikan sebagai REWRITE. Skor menengah (intermediate) dianjurkan menggunakan rekomendasi lainnya pada tabel di bawah:

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak
Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Hasil perbandingan dengan Standar Industri Logiscope‚ mungkin diinterpretasikan

sebagai berikut:

– Kualitas kode struktural (structural code quality) dari aplikasi Linux menyediakan hasil lebih tinggi dibanding apa yang diharapkan seseorang terhadap open-source tersebut. Dengan mempertimbangkan control terbatas atas proses pengembangan yang diikutinya yang telah diikuti.

– Kualitas kode struktural (structural code quality) dari aplikasi Linux menyediakan hasil lebih rendah dari mutu yang tersirat pada standard-nya.

– Pengembang tradisional mungkin kawatir atas open-source yang mempunyai suatu kemungkinan code yang tak terbaca dan kualitas yang rendah serta mustahil untuk memeliharanya

– Sebaliknya, temuan yang kedua adalah menentang filosofi pengembangan open-source. Dengan direct link antara karakteristik kualitas internal dan eksternal serta penemuan studi kasus ini, tampaknya komunitas opensource diperlukan keseriusan dalam mempertimbangkan kebutuhan untuk pengembangan kualitas code yang lebih tinggi. Hal Ini diusulkan atas fakta bahwa rata-rata hampir separuh komponen dari tiap aplikasi yang yang diuji tidak menerima rekomendasi “ACCEPT” dan harus dikerjakan lagi atau di revisi kem ali dengan berbagai cara yaitu. rewritten, tested, inspected atau commnted.

Kalau kita tengok ke belakang bahwa proses open-source dengan kualitas code strukturalnya dapat dibentuk sebagai salah satu tujuan proyek yang menggambarkan satu set ukuran struktural dan aturan pemrograman yang baik. Ada tiga hal berbeda yang dapat membantu dalam mencapai code kualitas tinggi (high quality code) yaitu:

1. Para programmer dapat diminta untuk mempertimbangkan kualitas kode struktural ketika membuat kode tesebut.

2. Koordinator proyek dapat menilai kualitas kode yang dikembalikan oleh para programmer menurut suatu standar yang sudah dikenal. Hal ini mengimplikasikan komponen tertentu tersebut tidak memenuhi standar atau mungkin ditolak sekalipun mereka menyediakan bugs yang benar ataupun fungsionalitas baru.

3. Koordinator proyek dapat mengambil keputusan code re-engineering kapan saja jika proyek mengalami permasalahan yang tak diinginkan.

Walaupun ada indikasi hanya suatu hubungan parsial antara ukuran komponen dan kepuasan pemakai, penemuan ini dapat digunakan ketika memutuskan isi dari suatu pengeluaran open-source. Bentuk release-nya adalah frekuensi aktifitas dalam pengembangan open-source biasanya (Raymond, 2000). Ketika akan ada versi baru dari suatu aplikasi, analisanya adalah dalam keadaan sama, versi yang ditandai oleh komponen yang lebih kecil ukurannya bisa terpilih untuk diikutsertaan dalam pengeluaran versi barunya. Lebih sedikit ukuran komponennya merupakan hasil dari desain yang lebih baik dan sebagai konsekuensi tingkat kecacatan lebih rendah serta lebih baik demi kepuasan pemakainya. Sebagai tambahan, komponen yang lebih kecil ukurannya dapat memudahkan pemeliharaan program dan evolusinya. Pada pendekatan otomatisasi, akan dengan mudah mengintegrasikan dalam proses open-source.

 

 

 

Pengukuran Perangkat Lunak Menggunakan Metrik Size-Oriented dan Metrik Function Oriented.

PENGANTAR: Pengukuran adalah suatu hal pokok bagi disiplin perekayasaan(engineering), tidak terkecuali pada perekayasaan perangkat lunak atau software. Jangkauan luas pengukuran pada perangkat lunak komputer disebut metrik perangkat lunak. Tujuan diterapkannya pengukuran pada proses perangkat lunak adalah untuk mengembangkan perangkat lunak itu sendiri dengan dasar yang kontinu.

Pengukuran software dalam konteks manajemen software difokuskan pada produktivitas dan metrik kualitas (pengukuran output perkembangan software sebagai fungsi usaha dan waktu yang diaplikasikan serta pengukuran “kesesuaian pemakaian” dari produk kerja yang dihasilkan).

1. PENGUKURAN, METRIK, DAN INDIKATOR

Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan kuantitatif dari ukuran atribut sebuah proses atau produk. Pengukuran (measurement) adalah kegiatan menentukan sebuah measure (pengukuran). Dan definisi metriks menurut IEEE adalah “ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu”.
Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah kesalahan yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak menghubungkan pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari jumlah kesalahan yang ditemukan pada setiap kajian.

Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri. Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat lunak untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik.

2. PENGUKURAN PERANGKAT LUNAK

Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi, ukuran memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan pengukuran tidak langsung dari produk adalah tentang fungsionalitas, kualitas, kompleksitas, efisiensi, realibilitas, kemampuan pemeliharaan, dsb.Dalam kenyataannya, pengukuran perangkat lunak secara objektif akan sulit dilakukan secara langsung karena ada pengaruh-pengaruh seperti individu dalam tim pengukuran, atau tingkat kompleksitas proyek.
Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik perangkat lunak yang memungkinkan perbandingan dengan rata-rata organisasional yang lebih besar.

2.1 METRIK SIZE ORIENTED

Parameternya adalah ”ukuran” dari software yang dihasilkan. Dapat dilakukan jika ada record atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang diperlukan adalah keseluruhan aktivitas rekayasa perangkat lunak. Misalnya tabel dibawah ini adalah pengumpulan dari data-data record yang ada dari sebuah organisasi:

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada masing-masing proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan 12100 baris kode dalam 365 halaman, dikembangakan dengan usaha 24 orang per bulan dengan biaya $168000. Lalu ditemukan kesalahan sebanyak 134 pada proyek sebelum direlease, 29 cacat setelah direlease pada pelanggan, dan ada 3 orang yang bekerja pada pengembangan proyek perangkat lunak alpha.

Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru yang sederhana untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan), cacat per baris kode (ribuan), dokumentasi per baris kode (ribuan), kesalahan per usaha, baris kode per usaha, biaya per halaman dokumentasi, dsb.

Metrik ini tidak dapat diterima secara universal karena adanya kontroversi pada penggunaan baris kode sebagai titik ukur. Sebagian yang setuju pada pengukuran LOC menganggap bahwa LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer – comment yang ada).

Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur kebanyakan disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri. Dalam masa-masa awal bahasa pemrograman Assembly, hal ini tidak menjadi suatu masalah karena dalam 1 baris aktual program merupakan 1 baris instruksi, tetapi dalam bahasa pemrograman tingkat tinggi, dimana pada masing-masing bahasa, untuk menyelesaikan suatu masalah dengan algoritma yang sama pun LOC nya sudah berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari algoritma yang digunakan. Hal ini yang membuat banyak sekali kontroversi mengenai LOC sebagai tolak ukur dari sebuah software.

2.2 METRIK FUNCTION ORIENTED

Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk melakukan hal ini, fungsionalitas harus diukur dengan pengukuran langsung yang lain karena fungsionalitas tidak dapat diukur secara langsung. Maka pengukuran dapat dilakukan dengan pengukuran function point. Function point didapat dari penarikan hubungan empiris berdasarkan pengukuran domain informasi software dan perkiraan kompleksitas software. Domain informasi yang biasa digunakan ada 5 karakteristik, yaitu: · jumlah input pemakai: setiap input pemakai yang memberikan data yang berorientasi pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari penelitian yang dihitung secara terpisah) misal: tipe transaksi. · jumlah output pemakai: setiap output pemakai yang memberikan informasi yang berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada laporan, layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung terpisah. misal: report type. · jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk output online. · jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file terpisah).

· jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informasi ke sistem yang lain

Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan masing-masing penghitungan dengan tabel perhitungan sebagai berikut:
Faktor pembobotan

Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak
Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubah-ubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada salah satu parameter pengukuran adalah sederhana, rata-rata atau kompleks ditentukan oleh organisasi atau perkeyasa perangkat lunak yang melakukan penghitungan itu sendiri. Tetapi meskipun begitu perkiraan kompleksitas tetap bersifat subyektif.

Untuk menghitung function point (FP) dapat digunakan hubungan sbb: FP = jumlah total x [0,65 + 0,01 x Fi]

dimana jumlah total adalah nilai yang kita dapatkan pada tabel perhitungan di atas.

Sedangkan Fi dapat dihitung dari perhitungan sebagai berikut: · Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut: 1. Data communications 2. Distributed functions 3. Performance 4. Heavily used configuration 5. Transaction rate 6. Online data entry 7. End-user efficiency 8. Online update 9. Complex processing 10. Reusability 11. Installation ease 12. Operational ease 13. Multiple sites 14. Facilitation of change Pada setiap karakteristik tersebut diberi bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai berikut: 0. Tidak berpengaruh 1. Insidental 2. Moderat 3. Rata-rata 4. Signifikan

5. Essential

Setelah setiap karakteristik diberi bobot masing-masing, lalu bobot-bobot dari setiap karakteristik ini dijumlahkan (jadi minimum 0 dan maksimal 70) dan kita akan mendapatkan nilai Fi. Setelah mendapatkan nilai Fi maka kita bisa menghitung nilai FP dengan rumus di yang sudah ada di atas.
Setelah kita mendapatkan nilai FP, maka kita dapat menggunakannya dengan cara analog dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat lunak, serta atribut-atribut yang lain seperti:

· kesalahan per FP · cacat per FP · $ per FP · halaman dokumentasi per FP · FP per person-month · dsb

(dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat diambil dari data-data pada tabel record pada metrik size-oriented).

Contoh:

Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa jumlah input pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah penyelidikan pemakai 22 buah, jumlah file 45 buah, jumlah interface eksternal 20 buah, dengan asumsi bahwa jumlah input pemakai rata-rata, jumlah output pemakai sederhana, jumlah penyelidikan pemakai rata-rata, jumlah file kompleks, jumlah interface eksternal sederhana. Semua karakteristik pada perangkat lunak ini moderat. Hitung $ per FP nya!

Jawab:

jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979 Fi = 14 x 2 = 28 FP = 979 x (0,65 + (0,01 x 28)) = 910,47 $ pada proyek alpha: 168000

$ per FP = 168000 / 910,47 = $184,52

Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat dilihat apakah angka ini termasuk baik atau tidak harus diperbandingkan dengan perhitungan lain, misalnya $ per FP dari proyek beta atau gamma, atau proyek dari organisasi lain.

Sebenarnya banyak sekali metrik-metrik yang digunakan untuk mengukur perangkat lunak, misalnya metrik FP yang diperluas (biasanya diaplikasikan dalam dunia bisnis) tetapi belum sempat dibahas disini.

REFERENSI :

http://rpl07.wordpress.com/2007/06/21/pengukuran-perangkat-lunak-menggunakan-metrik-size-oriented-dan-metrik-function-oriented-oleh-arif-m-5105-100-139/

http://www.geocities.com/iyuadi/rpluasImam.pdf

DISUSUN OLEH :

Tofan Teguh Perkasa

220641105