Quality Manajemen

DEFINISI
Quality manajemen adalah suatu usaha untuk meningkatkan kualitas dari sebuah produk yang sedang dikerjakan dengan melalui beberapa tahapan proses, prosedur, dan pengukuran. Quality manejemen bertujuan untuk menciptakan sebuah produk yang berkualitas dan teruji hal ini berlaku pada sebuah pembentukan software maupun sebuah organisasi.

IMPLEMENTASI
Salah satu implementasi yang ada mengenai quality manajemen adalah pada studi kasus di Universitas Pretoria, Afrika Selatan. Universitas tersebut menjalankan quality manajemen yang mendukung e-learning.
1. Latar belakang studi kasus
Pada universitas tersebut terdapat lembaga Education Inovation (EI) yang bertanggung jawab mendukung belajar dan mengajar, pengembangan staff akademi, dan inovasi pendidikan. Pada lembaga ini juga terdapat unit e-education yang menyediakan support untuk pengembangan dan pelatihan mengarah ke project e-learning.
2. Statement permasalahan
Sesuai permintaan pada instruksi tim desain pada lembaga tersebut pendekatan secara sistematis dibutuhkan dalam terminologi pada pengaturan project e-learning pada tiap tahapnya. Mereka menginialisasi untuk menggunakan proposal standar project untuk mendorong e-learning project. Pada kasus ini usaha untuk menormalisasi e-learning quality manajement dalam sebuah institusi pendidikan tingkat tinggi di beri nama:
• Formalisasi instruksional design model yang digunakan
• Dokumentasi siklus project dari e-learning
• Pendekatan ISO 9000-cognisant oleh sebual formal implementasi, proses secara langsung berdasarkan Quality Manajemen System (QMS)
3. Roles and responsibilities
Aturan main pada e-;earning dibagi dalam 3 kelompok: stakeholders, client, dan practicioners. Mereka sebagai kunci individu yang mendukung, mengkntribusi, atau menggunakan produk e-learning dan mempe;ajarinya.



Hubungan langsung clients pada e-learning adalah staff akademis atau pengajar yang berharap dapat mengadopsi EI dalam meningkatkan material e-learning.sedangkan client students merupakan pemakai.
4. Budget
Pengaturan keuangan juga dibutuhkan dalam manajemn proyek ini karena pada poject tersebut juga memberikan dukungan servis sepert gambar, photografi, dan video yang dapat digunakan seperti pemakaian CD, kaset video, dan DVD. Tentunya hal tersebut membutuhkan dana. Oleh karena itu diperlukam estimasi biaya yang dikeluarkan dalam projek tersebut.


5. Instructional design model
Anggota e-learning telah melakukan konsultasi untuk mengikuti instruksional design model. Setelah melakukan konsultasi mengenai literature yangf ada maka Analysis, design, development, implementation, dan evaluation akan digunakan dalam project e-learning. Hal tersebut sesuai dengan tipikal siklus hidup dari project manajement model dan model dari proses dasar quality manajement system dari ISO 9000
Analysis, design, development, implementation, dan evaluation digunakan dalam project tersebut. Hal tersebut merupakan bagiandari model, di mana model tersebut diadaptasi untuk membentuk timeline project yang terdapat pada gambar di bawah ini, di mana terdapat procedural yang terdiri dari beberapa langkah.



6. Deliverables
Merupakan pengiriman materi dimana sebagai hasil dari pendekatan formal quality Management untuk project e-learning. Antara lain:
• Design toolkit instruksi yang terdiri dari:
o Project timeline
o Servis web support dan multimedia support.
o Aturan dan pertanggungjawaban dokumen
o Permintaan minimum untuk pelatihan web pendukung dan produk multimedia
• Pendokumentasian procedur yang lengkap berdasarkan apa yang ada.
• Online QMS yang digabungkan dengan prosedur, model, dan siagram, dan dokumentasi pendukung seperti kebijakan, form dan ceklist.

7. Process followed
Tugas tim terdiri atas manajer proyek dan desainer instruksi yang dibentuk menjadi pencetus ide dasar dan mendokumentasi setiap prosedur dalam timeline project. Tugas tersebut adalah sebuah metodologi yang diterima untuk membangun quality managemen dan monitoring system.



Daftar Pustaka
Fresen, Jill and Lesley Boyd.”Quality Manajement in e-learning support unit: A case study at the University of Protiria, South Africa”.Department of education innovation, University of Pretoria. South Africa

Sender : Mulyo Adhi Sudarsono
Sender ID : 22 04 3470

SOFTWARE MEASUREMENTS

Kegagalan dalam pengerjaan proyek software selalu terjadi. Hal ini bias disebabkan oleh beberapa hal seperti kerja sama team yang buruk, tidak ada perencanaan sebelumnya, dsb. Padahal kunci keberhasilan dari pengerjaan suatu proyek software adalah perencanaan yang matang.
Perencanaan yang matang bisa diperoleh dengan melakukan yang namanya pengukuran. Apa yang diukur? Antara lain function points (cost per code), number of fault, efforts, dsb. Hasil dari pengukuran inilah yang nantinya menjadi bahan unutk membuat banyak pertimbangan dalam mengerjakan sroyek software tersebut. Hasil dari pengukuran merupakan hasil yang kuantitatif yang bisa menuntun seseorang software engineer dalam mendesain arsitektur, interfaces, dan komponen-komponen yang penting dari software yang akan dibuatnya.
Pada dasarnya tujuan dari adanya pengukuran ini sendiri untuk menghasilkan suatu software yang berkualitas tinggi. Software yang berkualitas sangat berhubungan dengan karakteristik dari analisis dan desain model serta source code yang dibuat. Sebenarnya masih ada faktor-faktor lain yang menunjang terbentuknya software berkualitas yang terbagi menjadi 2 group besar :
1. Faktor-faktor yang dapat diukur secara langsung seperti defects yang terjadi selama testing
2. Faktor-faktor yang tidak dapat diukur secara langsung (perlu keterlibatan factor-faktor lain) seperti usability, maintainability, dsb.
Proses dari pengukuran sendir dikelompokan menjadi 3 bagian :
1. Data Collection
→ proses mengumpulkan informasi dari proses software engineering, software project dan software product.
2. Metrics Computation
→ proses menghitung metrics (mendapatkan hasil pengukuran secara kuantitatif).
3. Data Collection
→ proses mengumpulkan measures (hasil dari proses mengumpulkan data) dan mengembangkan metrics untuk menghasilkan indicator yang merupakan acuan dalam membuat keputusan, perencanaan jangka panjang, evaluasi, dan laporan perkembangan.

SOFTWARE METRICS
Definisi dari dari software metrics adalah proses mengukur beberapa property (atribut / method) dari software atau spesifikasi dari software itu sendiri. Ada beberapa jenis dari software metrics antara lain :
1. Metrics for the analysis model.
2. Metrics for the design model.
3. Metrics for source code.
4. Metrics for testing.
Dan yang paling umum digunakan adalah Metrics for the analysis model karena mengalamatkan banyak aspek. Metrics ini salah satunya terdiri dari function points.
Function points dapat digunakan untuk :
1. Estimasi cost atau effort yang dibutuhkan.
2. Memprediksi jumlah errors yang terjadi selama testing.
3. Memperkirakan jumlah LOC (Line Of Code).
Function points dapat dihitung dengan mengetahui nilai-nilai dari information domain :
1. External inputs → inputan yang berasal dari user dan diproses di internal logical files.
2. External outputs → output yang ditampilkan kepada user berupa informasi.
3. External inquiries → inputan secara on-line, tanpa melibatkan user secara langsung.
4. Internal Logical Files→ sekelompok data yang secara logikal berada di dalam lingkup aplikasi.
5. External inputs → sekelompok data yang secara logikal berada diluar lingkup aplikasi tapi memberikan data yang mungkin dibutuhkan aplikasi tersebut.



FP = count total x [0.65 + 0.01 x ∑ (Fi)]
∑ (Fi) = merupakan value adjustment factors (nilai kompleksitas).


Kasus

External inputs → password, panic, button, activate/deactivate
External outputs → messages, sensor status
External inquiries → zone inquiry, sensor inquiry
Internal logical files → sstem configuration data
External interface files → test sensor, zone testing, alarm alert, activate/deactivate




Dengan asumsi ∑ (Fi) = 46 (moderately complex)
FP = 50 x [0.65 + 0.01 x 46] = 56
Analysis :
1. Asumsi  1 FP = 60 LOC
12 FP per person-month of effort
2. Berapa lama jangka waktu pengerjaan jika dikerjakan oleh satu orang?
3. Bagaimana jika dikerjakan oelh sebuah team (missal terdiri dari 4 orang)
4. Berapa jumlah LOC total?


Referensi
Sofware Engineering – A Practitioner Approach (Roger S. Pressman – Mcgraw - Hill)
Modul Rekayasa Perangkat Lunak 2 – Software Measurements – Software Metrics (Wlliy SR)

Sender : Albertus Joseph Adrian
Sender ID : 22064094

SOFTWARE MEASUREMENT

Pengukuran
Adalah suatu aktivitas yang dilakukan untuk mendapat suatu nilai. Nilai-nilai itu nantinya dapat digunkan untuk memperkirakan secara lebih akurat dan meningkatkan kualitas dari apa yang ingin kita lakukan (dalam kasus kita adalah software). “We can’t control what we can’t measure ”.
Software Measurement
Berarti kita mengukur suatu project yang kita rancang agar bisa mendapat suatu nilai(metric) yang bisa digunakan. Menurut IEEE metric adalah “ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu”.
Keuntungan dari SM :
● Keakuratan dalam memperkirakan
● Deteksi resiko dini
● Perencanaan yang lebih baik
● Penggunaan nilai untuk masa depan
● Evaluasi
Yang diukur :
● biaya per code (Function points)
● jumlah kesalahan (KLOC)
● Waktu perbaikan
● Ukuran Software
● Tenaga kerja
● Kompleksitas Software
● Biaya Software

Tetapi bagaimana kita tahu kalau pengukuran kita sudah benar ?
Kita bisa menerapkan GQM :
- Goal : Hasil akhir project yang sesuai dengan yang diinginkan client.
- Question : Seberapa beasar project melenceng dari keinginan client.
- Metric : Jumlah yang melenceng.

Kapan kita mulai mengukur :
- Lebih cepat lebih baik.
- Semakin lama semakin besar resiko dan biayanya.

CONTOH KASUS


Paper ini merupakan laporan penerapan pengukuran menggunakan ISO/IEC15939 [5] dan memeriksa bagaimana pengukur menyediakan pandangan baru kedalam organisasi pengembang program. Tujuan utamanya dari pengukuran adalah untuk membantu teknisi TI departemen mendemokan biaya kefektifan dan keuntungan yang diterima dengan membangun ulang aplikasi raksasa (~14.000 fps) dalam jangka waktu 4 tahun. Bagaimanapun juga proses dari kerja dasar, mengumpulkan dan menganalisa dari mengukur telah menambah hal berharga kepad departemen pengmbang, sehingga penigkatan produksi dan kualitas yang signifikan menjadi disadari. Pandangan ini telah merubah cara manjer proyek dalam merencanakan dan memperkirakan perubahan permintaan, laporan, dan arah focus pengembangan. Hasil pengukuran menyediakan jalur utama untuk proses kemajuan yang dibutuhkan.
Paper ini mengamati kuci sukses dari program pengukuran ini yang telah efektif da berkembang selama 2 tahun dan bagaimana manager senior memutuskan berdasarkan pada hasil.
Total Metrics adalah sebuah konsultan metric yang telah membantu banyak pelanggan untuk menerapkan program pengukur selama lebih dari 13 tahun. Walaupun kami telah mengalami banyak kegagalan juga paper ini merupakansalah satu keberhasilan dan pembelajaran untuk mengetahui mengapa banyak pengukuran gagal dan banyak juga yang berhasil.
Paper ini berdasarkan kepada keberhasilan di departemen pemerintahan australia dengan mempekerjakan 60 orang untuk meningkatkan, merawat, dan mendukung aplikasi raksasa mereka “Asset Licensing and Registration System” (ALRS) ~14.000fps. Sistem ARLS menyediakan system pendapatan yang signifikan pada department dan dibutuhkan oleh bisnis agar tetap menguntungkan dan mempunyai daya saing.

Tahun 2004, management memutusan untuk mengganti Cool:GEN applikasi tahun 1992 mereka, tetapi menyadari resiko tinggi dari kegagalan proyek, mereka memutuskan untuk membangun ulang aplikasi komponen demi komponen daripada merubah semua secara total. Karena ingin meraih keuntungan dari penedekatan ini, merkea memutuskan untuk tetap menggunakan dasar dari lingkungan mereka dan mengawasinya selama lebih dari 4 tahun periode.
Akhir 2004, department memakai jasa Total Metrics dalam membangun pengukuran yang dapat mendukung prduktivitas dan kualitas dari pengembangan ALRS merekap.

Dalam hal ini Total Metric mengikuti proses yang di anjurakan ISO standard ISO/IEC15939: [5]



2 Menerapkan Program Pengukuran

2.1. Membangun dan menjaga pengukuran dan perjanjian pengaturan
Tugas utama dari pengukuran adalah untuk menghitung jumlah produktifitas yang diharapan dan kualitas pertambahan dari kegiatan pembuatan ulang untuk mengevaluasi harga penerapan dibandingkan tawaran keuntungan pengembangan yang lebih cepat, kualitas yang lebih tinggi, harga perawatan yang lebih murah dan harga pendukung. Sudah diperkirakan bahwa produksi yang lebih tinggi dari proses pengembangan dan kualitas produk akan mempunyai efek positif langsung pada pendapatan yang didapat oleh ARLS untuk departemen.
Pelanggan menyadari bahwa keuntungan yang ditawarkan ini mungkin akan membutuhkan beberapa tahun untuk terpercaya di implementasikan kedalam “re-factoring project” yaitu program pengukuran dalam jangka 4 tahun. Mereka juga mengetahui untuk meyakinkan program pengukuran, mereka dibutuhkan untuk merespon hasil dari pengukuran dan meng-implementasikan anjuran yang ditawarkan. Semua ini adalah kunci sukses untuk jangka panjang.




2.2. Merencanakan proses pengukuran
Total Metrics bekerja sama dengan tim manager selama 4 minggu menggunakan workshop dan purwarupa untuk menganalia indicator kunci performa (KPIs) yang dibutuhkan untuk demonstrasi kemajuan jumlah keuntungan dan kelemahan dari proses pengembangan mereka. Setelah beberapa kali pengembangan, manajer setuju akan data kebutuhan , 27 metric dan 5 dasar untuk di ukur.

5 Dasar
1. Functional size setiap peningkatan program dalam laporan 3 bulan, akan diukur saat penerapan menggunakan IFPU (CFPS
2. Effort biaya perjam yang di keluarkan perhari akan diberikan kepada tim pengembang, dan juga pembayaran jika ada perbaikan dan perawatan.
3. Defects found penganalisaan dan perbaikan untuk sebelum dan sesudah proyek selesai
4. Full Time Equivalents (FTE) – ukuran untuk pekerja yang bekerja selama 40 jam seminggu.


2.3. Pelaksanaan

2.3.1. membangun dasar
Aslinya dari ARLS, di dapat 10.455 UFPS. Maka digunakan SCOPE untuk mengembangakan ARLS menjadi 8 bagian dan 1600 proses dasar untuk memberikan ruang kerja yang bisa dengan mudah menghitung dan memetakan perubahan dalam system. Karena hal ini ukuran baseline menjadi 14,009 fps. Hal ini memakan waktu 33 hari kerja dan 8 minggu konsultasi
2.3.2. Pengukuran
setelah membangun garis dasar kemudian dilakukan pemngambilan laporan setiap ada peningkatan dan dilakukan perbandingan antara produksi dan kualitas.
Biaya, lama waktu, dan error di kumpulkan juga sebagai bagian dari pengukuran.
FP tiap project :
• ‘approximated untuk membantu menghitung ukuran dan biaya penerapan
• ‘measured untuk hal yang telah di hitung.
Hal ini otomatis di update seiring perubahan dalam system.
Mengukur perkiraan FP (846 fps) untuk dikerjakan setiap hari memakan waktu 5 hari kerja dan konsultasi selama 3 bulan.

2.3.3. Analisa

Terdapat 42 kemajuan yang di alami dari 8 laporan selama 2 tahun periode. Laporan lengkap keseulruhan dari data mentah menjadi utuh kami kerjakan menggunakan MS Exels. Proses pelaporan ini memakan waksu 5 hari kerja dan 6 bulan konsultasi.

2.3.4 Laporan
Setiap 3 bulan sekali di adakan pelaporan untuk emngetahui perkembangan dan seberapa jauh program tidak sesuai dengan keinginan. Laporan itu berisi hasil data dari system yang mengindikasikan kekuatan dan kelemahan dari system. Selain itu hasil laporan dapat figunakan untuk meningkatkan lagi kerja system. Menghasilkan laporan (110 halaman, 50 gambar dan tabel) memakan waktu 12-15 hari dan 6 bulan konsultasi tiap bab.

3. kesimpulan
Pengukuran membuat organisasi ini untuk focus kepada proses mereka untuk meningkatkan keuntungan ke maksimal dari produksi dalam pengembangan yang telah mereka lakukan. Hal ini terihat dari hasil mereka yang lebih cepat dan murah tapi tetap berkualitas.
Total Metrics bekerja dengan banyak organisasi yang menyadari bahwa dengan pengukuran yang berkualitas maka dapat memberikan hasil yang luar biasa tap tidak punya waktu, SDM, dan uang untuk melakukan hal pengukuran tersebut melaluai jalur yang formal. Kami mementingkan kepuasan pelanggan dengan memberikan hasil yang optimal dengan modal yang tidak terlalu besar. Dan program yang kami tawarkan berupa program jangka panjang.

Referensi :
Pam Morris (BSc.Grad Dip Comp.Dip Ed, CFPS, CSMS (Level 3))
CEO Total Metrics Australia.
WWW.totalmetrics.com
Pam.Morris@Totalmetrics.com


http://www.totalmetrics.com/

http://www.isbsg.org/html/terminol.html

http://www.isbsg.org

Sender : Rio Caesar
Sender ID : 22 06 4142

METRIK PENGUKURAN PERANGKAT LUNAK PADA PROYEK PERANGKAT LUNAK SISTEM INFORMASI BISNIS

PENDAHULUAN
Dalam IEEE Standart 610.12 Rekayasa Perangkat Lunak di definisikan sebagai :
“The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”.
Metrik digunakan oleh industri perangkat lunak untuk mengukur proses pembuatan, operasi, dan perawatan perangkat lunak. Melalui metrik, dapat diperoleh informasi-informasi berharga dan parameter-parameter sebagai bahan evaluasi yang obyektif mengenai atribut-atribut dan status dari suatu pengembangan perangkat lunak. Implementasi metrik perangkat lunak pada suatu proses pengembangan perangkat lunak dan pada suatu produk perangkat lunak melibatkan tahapan-tahapan kompleks yang memerlukan pembelajaran yang berkelanjutan, yang pada akhirnya dapat memberikan pengetahuan mengenai status dari suatu proses pembuatan perangkat lunak dan atau suatu produk dari perangkat lunak.

METRIK PERANGKAT LUNAK
Metrik perangkat lunak memiliki batasan-batasan yang luas. Metrik perangkat lunak tergantung pada atribut-atribut perangkat lunak yang ingin dinilai kuantitas dan kualitasnya. Hal-hal yang harus diukur dalam perangkat lunak adalah: masukan, keluaran, dan efektifitas hasil [Hetzel, 1993]. Secara umum, metrik perangkat lunak dibagi dalam dua kelas yang berbeda, yaitu metrik yang digunakan pada proyek
pengembangan perangkat lunak dan metrik yang digunakan pada produk perangkat lunak. Pada Metik terdapat penggunaan privat dan publik untuk data-data proses yang diperoleh. Beberapa metrik proses bisa bersifat privat untuk tim dalam proyek, namun bisa bersifat publik untuk seluruh anggota tim [Grady, 1992].

METRIK BERORIENTASI UKURAN JUMLAH DAN BARIS (SLOC)
SLOC = Source Line of Code
Secara virtual tidak mungkin untuk menghitung SLOC dari dokumen requirement awal. SLOC pengukurannya didasarkan pada bahasa pemrograman tertentu, oleh karena itu muncul banyak masalah dalam membuat standard pengukuran dengan teknik SLOC.
SLOC merupakan ukuran yang kurang akurat dan merupakan sebuah topik yang menimbulkan perdebatan selama bertahun- tahun, dipandang sebagai sebuah ukuran untuk mengestimasi biaya dan waktu, tidak dapat dipastikan bahwa dua program yang mempunyai SLOC sama akan membutuhkan waktu implementasi yang sama walaupun keduanya diimplemenatsikan dengan kondisi pemrograman
yang standard. Meskipun metode ini kurang akurat dan merupakan metodologi yang belum diterima secara luas, tetapi metrik dengan orientasi ukuran ini merupakan kunci pengukuran dan banyak estimasi software yang menggunakan model ini.

METRIK YANG BERORIENTASI PADA FUNGSI (FUNCTION POINT)
Pendekatan yang berorientasi fungsi mengukur fungsionalitas aplikasi untuk mengestimasi ukuran software dan selanjutnya digunakan untuk estimasi biaya dan usaha yang diperlukan untuk mengembangkan system.
Pendekatan ini diusulkan oleh Albrecht yang disebut sebagai metrik Function Points. Metrik ini diperoleh dari keterhubungan dasar antara domain informasi software dan kompleksitas software (Gambar 1). Function Points biasanya digunakan dalam mengukur system informasi manajemen (SIM).
Pada metodologi ini software dapat diklasifikasikan menjadi 5 domain yaitu:
• Jumlah data input pengguna
• Jumlah data output pengguna
• Jumlah data permintaan pengguna
• Jumlah file
• Jumlah file interface luar
Kemudian hitung nilai fungsi proyek yang mungkin pada setiap katagori dan kemudian setiap nilai perhitungan dikalikan dengan factor kompleksitas sebagai berikut:
• Sederhana (simple)
• Rata-rata (average)
• Komplek (complex)
Untuk menghitung Unadjusted Function Points digunakan tabel berikut berdasarkan kriteria dari setiap kategori.




Untuk menghitung function point digunakan persamaan berikut:

FP = count total * [0.65 * 0.01 * sum(Fj)]

Dimana count total adalah total yang diperoleh dari table function point analisis sum(Fj) adalah jumlah dari 14 faktor kompleksitas yang bernilai 0 s/d 5.



14 faktor kompleksitasnya adalah 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

PERNDEKATAN MODEL
Pendekatan model yang digunakan dalam menghitung besaran proyek adalah model function point (FP). Dibandingkan dengan pendekatan berbasis ukuran baris (LOC/Line Of Code). Pendekatan FP lebih independen terhadap bahasa pemrograman sehingga bisa diterapkan pada jenis aplikasi yang berbeda baik aplikasi database yang non-procedural, sistem informasi berbasis web, maupun aplikasi penghitungan, misalnya payroll. Pendekatan ini juga lebih mudah diprediksi daripada LOC karena parameternya dihitung berdasarkan data yang lebih diketahui, misalnya prediksi jumlah input dan ouput.
Meskipun FP dianggap memiliki kelemahan dalam subyektifitas data yang dimasukkan tetapi beberapa kriteria, misalnya untuk menentukan kategori sederhana atau kompleks, telah ditetapkan secara numerik untuk lebih memastikan obyektivitas data. Disamping itu, hasil perhitungan FP juga sering dianggap tidak memiliki arti yang mudah dipahami dibandingkan dengan LOC yang besarannya menunjukkan jumlah ukuran coding. Akan tetapi, hasil akhir FP dapat dikonversikan ke dalam LOC berdasarkan jenis bahasa pemrograman yang dipakai.
Jumlah usaha didapatkan dari waktu pengerjaan dikalikan dengan jumlah personel yang terlibat dalam pengerjaan proyek. Analisa regresi linear selanjutnya dilakukan terhadap beberapa sampel jumlah FP terhadap jumlah usaha/effort. Dari analisa tersebut akan didapatkan suatu persamaan, yakni:
Effort = a + b* FP
Konstanta a dan b yang didapat tersebut akan menjadi model bagi penentuan usaha (i.e jumlah biaya dan personel yang diperlukan) jika diketahui jumlah function point yang dapat dihitung dari kebutuhan pengguna (requirement definition).

VERIFIKASI MODEL
Verifikasi terhadap validitas model yang dihasilkan dapat diketahui dari sampel data yang masuk, tingkat kesalahan dalam regresi tingkat kesesuaian dengan model yang sudah ada. Perbedaan lingkungan pengembangan software, tentu akan menyebabkan persamaan yang berbeda. Kemungkinan perbedaan itu jugalah yang mendorong dilakukannya kajian ini sehingga diperoleh suatu model yang paling sesuai untuk daerah/lingkungan tertentu.
Verifikasi dengan berdasar pada jumlah sampel sering disebut sebagai exhaustive testing. Cara ini dilakukan dengan mengambil sampel atau kasus sebanyak mungkin untuk menguji disain dan implementasi sebuah sistem. Pendekatan ini diharapkan dapat mendeteksi kesalahan lebih akurat. Pendekatan ini membutuhkan semua kombinasi (exhaustive test) agar disain atau implementasi dapat dijamin benar. Untuk sistem yang besar dan kompleks, hal ini tentu saja tidak dapat dilakukan. Pendekatan formal method, yang menggunakan pembuktian secara matematis, biasanya digunakan untuk menguji sistem dengan tingkat kemungkinan yang tinggi. Akan tetapi untuk sample yang kecil (i.e tidak melebihi ribuan) seperti dalam kajian ini, exhaustive test ini dapat dilakukan.

CONTOH KASUS
Dalam Kasus ini kita akan mencoba implementasi Mertik Pengukuran Perangkat Lunak pada beberapa Sistem Informasi Bisnis
Data Pengembangan Proyek Perangkat Lunak Sistem Infomasi Bisnis


data yang diperoleh tidak dipublikasikan semuanya karena beberapa data merupakan rahasia perusahaan yang tidak boleh di ketahui oleh umum.

Pada proyek Sistem Informasi A diperoleh data sebagai berikut :
• jumlah input pemakainya = 22
• jumlah output pemakai = 8
• jumlah penyelidikan pemakai = 20
• jumlah file = 75
• jumlah interface eksternal = 25
• Diasumsikan 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.
count total
= (22 x 4) + (8 x 4) + (20 x 4) + (75 x 15) + (25 x 6)
= 88 + 32 +80+1125+ 150
=1475
sum Fj = 14 x 2 = 28
FP = 1475 x (0,65 + (0,01 x 28)) = 1371,75
Dana Proyek : Rp. 55.500.000
Dana per FP = Rp. 55.500.000 / 1371,75 =Rp. 40.459,26736

diatas merupakan contoh kasus metrik pengukuran perangkat lunak menggunakan Metrik Function Point.
Dengan menggunakan analisis LOC umum, Proyek Sistem Infomasi Bisnis A memiliki 194506 LOC

dan juga cara yang sama dapat diterapkan untuk Sistem Informasi Bisnis B dan C.

Referenced
B. Hetzel, 1993, Making Software Measurement Work: Building an Effective Measurement Program, QED Technical Publishing Group, Boston, Massachusetts, ISBN: 0471565687
Grady, Robert B., 1992, Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, Inc., ISBN: 0137203845
Lowell Jay Arthur, 1985, Measuring Programmer Productivity and Software Quality, John Wiley & Sons, Inc., New York, NY, ISBN: 0471887137
Pressman, 2000, R. S. Software Engineering A Practitioner’s Approach, 5th Edition, New York, McGraw Hill, ISBN: 0073655783
Albrecht, A. J., 1979, Measuring Application Development Productivity, IBM Applications Development Symposium, Monterey, CA , pp. 83-92
http://www.proyeksoftware.com

Sender : Matahari Bhakti Nendya
Sender ID : 22064091

Quality Management

Definisi Quality Management

Quality Management (QM) merupakan suatu karakteristik atau atribut dalam pemrograman maupun dalam suatu organisasi yang memiliki acuan pada suatu karakteristik yang bisa dilakukan suatu pengukuran, di dalamnya terlibat beberapa material seperti LOC dan kompleksitas.

Implementasi QM

Studi kasus pada IBM :

IBM melakukan pendekatan dalam sistem kerja yaitu dengan quality management yang dimulai dengan vision of continues, comprehensive, collaborative system, project metric dan juga track qulaity yang digunakan sebagai acuan dasar untuk memfasilitasi segala perubahan dalam perusahaan yang mana perubahan tersebut mengikuti perkembangan pasar, perkembangna teknologi dan kebutuhan dari pelanggan itu sendiri.

Untuk mengatasi hal tersebut diatas maka IBM menerapkan beberapa langkah, langkah- langkah tersebut antara lain adalah sebagai berikut :

1. IBM Rational RequisitePro di desain untuk requirements management.

2. IBM Rational ClearCase digunakan untuk perubahan dan konfigurasi management. Yang mana menyediakan berbagai kendali dan mendukung pengembangan secara parallel untuk meningkatkan produktivitas.

3. IBM Rational ClearQuest dugunakan untuk menguatkan tracking yang sejalan dengan test management, dimana dapat membantu customer untuk mengetahui perkembangan yang dilakukan oleh IBM dalam semua fase quality management lifecycle.

4. IBM Rational Functional Tester digunakan untuk testing fungsi – fungsi secara otomatis dan testing regresi.

5. IBM Rational Purify and PurifyPlus adalah solusi berbasis analisis yang membantu dalam debugging dan membantu para programmer dalam membuat coding yang lebih baik dan efisien.

6. IBM Rational Manual Tester adalah suatu tes yang digunakan untuk menguji suatu program atau produk secara manual yang sehingga produk tersebut lebih cepat, tepat dan reliable.

7. IBM Rational Performance Tester digunakan untuk mengetaui waktu respond an skalabilitas dibawah semua kondisi sehingga performa produk tersebut dapat berjalan dengan baik pada semua situasi dan kondisi.

8. IBM Rational Robot adalah suatu test otomatisasi produk untuk kebutuhan apliaksi client-server.

Selain langkah – langkah diatas makan IBM juga mengembangkan proses dan management tools dan metodelogi untuk memfasilitasi implementasi yang tadi telah dijalankan.IBM juga menerapakan RUP (Rational Unified Process) adalah suatu framework yang menyediakan pelatihan terbaik untuk pengembangan software dan management proyek.


Sender :

user : B.Kristianto Purwoko Adi

ID : 22.04.3523


References:

1. Adopting A Lifecycle Approach To Software Quality Management,Marcia Kaufman & Robert Dorin (Senior Analyst).

2. http://www.google.com

3.http://www.yahoo.com