Dampak Tingkat Kematangan Proses CMMI Berbasis pada Usaha, Produktivitas dan diseconomy Skala Majed Alyahya, Rodina Ahmad, dan Sai Peck Lee Departemen Rekayasa Perangkat Lunak, University of Malaya, Malaysia Abstrak: Software Capability Maturity Model Integrasi (CMMI) telah menjadi populer Software Proses Perbaikan (SPI) model untuk proses pengembangan perangkat lunak meningkatkan dengan tujuan mengembangkan perangkat lunak berkualitas tinggi dalam anggaran dan jadwal. Sejak usaha pengembangan perangkat lunak dapat sangat dipengaruhi oleh tingkat kematangan proses organisasi, penelitian ini meneliti dampak tingkat kematangan proses yang berbeda CMMI berbasis pada usaha, tim pengembangan produktivitas dan diseconomy skala untuk ukuran proyek standar. Konstruktif model biaya (COCOMO) digunakan untuk menghitung software usaha pengembangan. Persentase perubahan (kenaikan atau penurunan) dalam pengembangan perangkat lunak usaha, produktivitas dan diseconomy skala digunakan sebagai ukuran efektivitas untuk penelitian ini. Hasil kerja ini menunjukkan bahwa setiap tingkat kematangan CMMI yang lebih tinggi memiliki dampak yang cukup besar dalam mengurangi upaya pembangunan, meningkatkan tingkat produktivitas dan mengurangi diseconomy skala. Hasil ini juga menunjukkan bahwa dampak dari tingkat kematangan CMMI berbasis signifikan meningkat dengan ukuran proyek. Kata kunci: CMMI, kematangan proses, COCOMO II, usaha pengganda, faktor skala, diseconomy skala, tingkat produktivitas. Diterima 19 Februari 2010, diterima 10 Agustus 2010 1. Pengantar Mengembangkan perangkat lunak untuk memenuhi kebutuhan fungsional dengan kualitas yang dapat diterima, sesuai jadwal yang direncanakan, dan dalam anggaran adalah target dikejar oleh setiap perangkat lunak pengembangan organisasi [26]. Ada luas keyakinan bahwa produk perangkat lunak yang baik adalah hasil dari matang dan proses perangkat lunak berulang, yang telah menyebabkan lebih fokus pada Software Process Improvement (SPI) ke membantu organisasi pengembangan perangkat lunak menyadari nya manfaat potensial. Dengan demikian, pencarian handal metodologi, ide dan inovasi untuk meningkatkan pengembangan perangkat lunak tetap menjadi penting fokus untuk penelitian baik akademik dan industri. Usaha dihabiskan di daerah ini telah menghasilkan beberapa model SPI dan standar seperti ISO 9001 [30], Six Sigma [33], dan Carnegie Mellon Rekayasa Perangkat Lunak Institute Capability Maturity Model untuk Software (SW-CMM) [31] serta versi terbaru nya, Integrasi Model Kematangan Kemampuan (CMMI) [7]. Makalah ini berfokus pada CMMI. Motivasi untuk

memilih CMMI sebagai dasar penelitian ini adalah bahwa hal itu berpengaruh, lama, dan sering dipelajari standar SPI [35]. Selain itu, CMMI berbasis SPI telah menyebabkan peningkatan kuantitas dalam bagaimana proses perangkat lunak rekayasa dilakukan [5]. Sebuah cording ke Jones dan Soule [24], di antara perbaikan proses software kerangka, CMMI menjadi model standar dengan tingginya tingkat penerimaan. Dalam studi ini, kami menyelidiki dampak CMMI- tingkat kematangan proses berbasis pada pengembangan perangkat lunak usaha, tingkat produktivitas dan diseconomy skala untuk set ukuran proyek standar. Model COCOMO II digunakan untuk memperkirakan upaya yang diperlukan di setiap tingkat kematangan. Ini memiliki input faktor skala, Proses Kematangan (PMAT), yang digunakan untuk menilai kematangan proses organisasi. Karena penyelidikan disajikan dalam karya ini terutama didasarkan pada CMMI, dan nilai-nilai yang ada PMAT COCOMO II yang pada dasarnya diturunkan untuk CMM, oleh karena itu, berdasarkan Hasil penelitian terbaru kami, satu set baru COCOMO PMAT peringkat nilai II di bawah CMMI telah berasal dan dievaluasi [1]. Dengan demikian, studi ini bergantung pada Peringkat nilai PMAT CMMI baru berbasis. Sisa penelitian ini disusun sebagai berikut: Bagian 2 menyajikan latar belakang singkat tentang CMMI tingkat kematangan di samping definisi COCOMO Model. Motivasi Penelitian dan hipotesis diperkenalkan pada bagian 3. Bagian 4 survei beberapa penelitian sebelumnya yang terkait dengan pekerjaan ini. Bagian 5 dan 6 menggambarkan metode kerja ini dan ukuran evaluasi masing-masing. Hasil dan diskusi terkait disajikan dalam bagian 7. Akhirnya, Bagian 8 menawarkan beberapa kesimpulan dari pekerjaan ini dan menyajikan dianjurkan karya masa depan. 2. Latar belakang 2.1. CMMI Tingkat Kematangan Proses Perangkat Lunak CMMI digunakan untuk menilai organisasi kematangan proses. CMMI menyediakan sejumlah persyaratan bahwa semua organisasi dapat digunakan dalam pengaturan up proses perangkat lunak yang digunakan untuk mengontrol perangkat lunak pengembangan produk. CMMI menentukan "apa" yang harus dalam proses perangkat lunak daripada "kapan" atau "untuk

Page 2Dampak Tingkat Kematangan Proses CMMI Berbasis pada Usaha, Produktivitas dan diseconomy Skala

353 berapa lama ". Ada lima tingkat kematangan proses, Tingkat 1 (terendah) ke level 5 (tertinggi), di mana setiap tingkat menandakan tingkat kinerja yang dapat diharapkan dari sebuah organisasi. Sebagai contoh, tingkat kematangan 1 organisasi memiliki proses ad hoc, sedangkan jatuh tempo level 2 organisasi memiliki manajemen proyek dasar sistem di tempat, dan sebagainya. Lima CMMI jatuh tempo tingkatan tersebut adalah: awal (tingkat kematangan 1), berhasil (jatuh tempo level 2), ditetapkan tingkat kematangan 3), secara kuantitatif dikelola (tingkat kematangan 4), dan mengoptimalkan (jatuh tempo level 5) [7]. 2.2. COCOMO II Model The Constructive Cost Model (COCOMO) adalah awalnya diterbitkan pada tahun 1981 (COCOMO 81) [4], dan menjadi salah satu estimasi biaya parametrik paling populer model tahun 1980-an. Tapi di tahun 90-an, COCOMO 81 menghadapi banyak kesulitan dan komplikasi memperkirakan biaya perangkat lunak yang dikembangkan untuk baru proses siklus hidup seperti non-sekuensial dan perkembangan pesat proses model, reuse-didorong pendekatan, dan pendekatan berorientasi obyek [2]. Dengan demikian, COCOMO II diterbitkan awalnya dalam sejarah rekayasa perangkat lunak pada tahun 1995 dengan tiga sub model, sebuah aplikasi model-komposisi, model desain awal dan model pasca-arsitektur [2]. COCOMO II memiliki sebagai input, satu set tujuh belas Pengganda Usaha (EM) atau driver biaya yang digunakan untuk mengatur upaya nominal Orang-Bulan (PM) untuk mencerminkan produk perangkat lunak sedang dikembangkan. 2.2.1. Upaya Estimasi Dalam COCOMO II, usaha dinyatakan sebagai PM. Boehm di [3] mendefinisikan PM sebagai "jumlah waktu satu orang menghabiskan bekerja pada proyek pengembangan perangkat lunak selama satu bulan ". The COCOMO estimasi usaha II persamaan ditunjukkan dalam 1. PM nominal = A × UKURAN E × EM i N i = 1 Dimana

• Sebuah adalah perkalian dasar konstan = 2.94. Sekarang diturunkan oleh tim COCOMO dengan kalibrasi dengan nilai usaha sebenarnya untuk 161 proyek yang sedang Database COCOMO II. • eksponensial Faktor E dibahas dalam berikutnya bagian. • EM digunakan untuk mengatur usaha. • N adalah jumlah usaha pengganda atau driver biaya. 2.2.2. Faktor Skala (SF) Selain itu 17 pengganda usaha yang digunakan sebagai input ke model COCOMO II, ada satu set lima Faktor skala yang menjelaskan ekonomi dan diseconomies of scale dalam pengembangan perangkat lunak proyek. Bila ada skala ekonomi, dua kali lipat ukuran perangkat lunak akan menghasilkan usaha yang kurang dari dua kali lipat aslinya. Sedangkan bila disekonomis Skala hadir untuk sebuah proyek software, menggandakan ukuran proyek akan menghasilkan lebih dari dua kali lipat dari Upaya proyek awal yang dibutuhkan untuk menyelesaikan proyek [3]. COCOMO II menggunakan persamaan 2 untuk menghitung jika proyek memiliki ekonomi atau diseconomies of scale: E = B +0.01 × SF j N j = 1 Dimana B adalah konstanta = 0,91. Hal ini diperoleh oleh Tim COCOMO dengan kalibrasi dengan upaya yang sebenarnya nilai untuk 161 proyek saat ini dalam COCOMO II Database. Eksponen E dalam persamaan 2 adalah agregasi dari lima Faktor Skala (SF). Semua skala faktor memiliki tingkat rating. Tingkat-tingkat yang Sangat Luar Low (VL), Low (L), Nominal (N), tinggi (H), Sangat Tinggi (VH) dan Extra Tinggi (XH). Setiap tingkat rating memiliki berat, W, yang merupakan nilai kuantitatif yang digunakan dalam Model COCOMO II. Seperti terlihat pada Tabel 1, lima Faktor skala COCOMO II Precedentedness, Development Flexibility, Resolusi Risiko, Tim Kohesi, dan PMAT [3]. Prosedur untuk menentukan PMAT-faktor yang menarik dalam penelitian ini diselenggarakan sekitar Rekayasa Perangkat Lunak Institute Capability Maturity Model (SEI-CMM). Tabel 1. Penilaian tingkat dan nilai-nilai untuk faktor skala COCOMO II [3]. Faktor Skala C M

M L e v e l 1 ( L o w e r ) C M M L e v e l 1 ( U p p e r ) C M M L e v e l 2 C M M L e v e

l 3 C M M L e v e l 4 C M M L e v e l 5 VL L N H VH EH Precedentedness (Prec) 6.2 4.96 3.72 2.48 1.24 0.00 Pembangunan Fleksibilitas (FLEX) 5.07 4.05 3.04 2.03 1.01 0.00 Resolusi Risiko (RESL) 7.07 5.65

4.24 2.83 1.41 0.00 Tim Kohesi (TIM) 5.48 4.38 3.29 2.19 1.10 0.00 Proses Jatuh Tempo (PMAT) 7.80 6.24 4.68 3.12 1.56 0.00 Seperti dapat dilihat pada baris pertama dari Tabel 1, COCOMO II menggunakan enam peringkat tingkat kematangan. Itu satunya perbedaan antara CMM dan COCOMO II peringkat tingkatan pada tingkat kematangan pertama yang memiliki telah dibagi dalam COCOMO II menjadi dua bagian, lebih rendah setengah dan setengah bagian atas. Menurut [8], tingkat CMM 1 (Bagian bawah) adalah untuk organisasi yang mengandalkan "pahlawan" untuk melakukan pekerjaan itu. Mereka tidak fokus pada proses atau mendokumentasikan pelajaran. Tingkat CMM 1 (upper setengah) adalah untuk organisasi yang telah menerapkan sebagian besar persyaratan yang akan memuaskan CMM tingkat 2. Di (1) (2)

Page 3354 Journal Arab Internasional Teknologi Informasi, Vol. 9, No 4, Juli 2012 Diterbitkan definisi CMM, tingkat 1 (bagian bawah) dan (Bagian atas) dikelompokkan menjadi level 1. 3. Motivasi Penelitian dan Hipotesis 3.1. Motivasi penelitian Peningkatan jumlah pengembangan perangkat lunak organisasi di seluruh dunia telah mengadopsi CMMI untuk meningkatkan proses pengembangan perangkat lunak mereka [37]. Di literatur, ada banyak penelitian tentang arti dan manfaat meningkatkan berbasis CMM

tingkat kematangan organisasi. Namun, teramati bahwa ada penelitian yang sangat terbatas tentang dampak dan manfaat dari proses kematangan CMMI berbasis. Rasanya CMM masih menerima banyak perhatian dari CMMI meskipun ada terus-menerus dan meluas tuntutan pada bukti tentang dampak dan manfaat kematangan proses CMMI berbasis dari organisasi yang mengadopsinya [10]. Selain itu, sebagian besar studi yang tersedia dan penelitian yang berfokus pada CMMI adalah studi kasus berdasarkan data kuantitatif. Untuk yang terbaik dari pengetahuan kami, studi kualitatif pada efek meningkatkan tingkat kematangan CMMI adalah kekurangan dalam literatur. Hal ini diyakini bahwa CMMI, dengan tingkat penerimaan yang tinggi sebagai kerangka SPI, membutuhkan penyelidikan khusus tentang dampak dan manfaat meningkatkan tingkat jatuh tempo. 3.2. Hipotesis penelitian Hipotesis kerja yang disajikan di sini adalah bahwa meningkatkan tingkat kematangan proses CMMI berbasis akan menghasilkan berikut ini: 1. Penurunan dalam upaya pengembangan perangkat lunak. 2. Kenaikan tingkat produktivitas. 3. Sebuah mengurangi diseconomy di skala. Seperti yang dinyatakan sebelumnya, studi ini bergantung pada baru CMMI- nilai peringkat PMAT berbasis yang ditunjukkan pada Tabel 2. Tabel 2. Nilai Peringkat PMAT baru. PMAT Deskripsi CMMI Level 1 (Lower) CMMI Level 1 (Atas) CMMI Level 2 CMMI Level 3 CMMI Level 4 CMMI Level 5 Penilaian Tingkat Sangat

Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi New PMAT Nilai 7.55 5.71 3.81 2.08 1.03 0.00 Sejak COCOMO II menganggap tingkat CMM 2 sebagai Peringkat nominal untuk PMAT, pertimbangan yang sama adalah untuk tingkat CMMI 2. Dengan demikian, persentase kenaikan atau penurunan usaha, produktivitas dan diseconomy dari skala, akan dibandingkan terhadap nominal CMMI- peringkat PMAT berbasis. 4. Sastra Terkait Banyak penelitian dan studi kasus telah menunjukkan banyak manfaat dari proses organisasi meningkatkan jatuh tempo dengan menggunakan pendekatan penilaian yang berbeda [6, 22, 23, 27, 36]. Girish et al [18] melakukan. studi empiris untuk menyelidiki efek dari CMM pada dua faktor penting dalam Sistem Informasi (IS) implementasi strategi, yang adalah proyek kinerja dan kualitas perangkat lunak. Mereka menyatakan bahwa Tingkat CMM berhubungan dengan IS pelaksanaan strategi dan tingkat CMM yang lebih tinggi berhubungan dengan tinggi kinerja proyek dan kualitas perangkat lunak yang menyebabkan pengurangan yang nyata dalam upaya pengembangan perangkat lunak dan jadwal. Dari review tujuh belas diterbitkan artikel, Galin dan Avrahami [15] dieksplorasi CMM- imbalan berbasis seperti cacat, pengerjaan ulang, jadwal, produktivitas, efektivitas kesalahan pembelotan, dan Return on Investment (ROI), menyimpulkan bahwa baik investasi dalam program CMM menyebabkan peningkatan pengembangan perangkat lunak dan pemeliharaan. Diaz dan Raja [11] menyatakan bahwa peningkatan proses CMM kematangan

hasil dalam peningkatan kualitas, fase penahanan, produktivitas dan pengerjaan ulang. Agar mengeksplorasi dampak kematangan proses pada perangkat lunak upaya pengembangan, dan berdasarkan CMM dengan bantuan Sampel 161-proyek, Clark dalam [8] mengisolasi efek pada upaya kematangan proses dibandingkan efek lainnya faktor, dan menemukan bahwa peningkatan satu tingkat kematangan proses organisasi dapat menghasilkan pengurangan dalam upaya pengembangan perangkat lunak sebesar 4% menjadi 11%. Tapi pengurangan ini tampak seperti generalisasi di semua lima tingkat kematangan proses CMM, yaitu, persentase pengurangan upaya tidak sama di antara semua tingkat. Memon di [29] telah melaporkan bahwa Tingkat kematangan CMM jauh mempengaruhi Upaya pengembangan perangkat lunak dan produktivitas. El- Emam dan Goldenson [13] dalam komprehensif Tinjauan studi dan publikasi pada implementasi metodologi SPI, termasuk CMM, melaporkan peningkatan kinerja kualitatif dalam hal, kualitas yang lebih tinggi, produktivitas yang lebih tinggi, meningkatkan kemampuan untuk memenuhi jadwal pembangunan. Donald et al. [12] melakukan penelitian empiris untuk mengetahui hubungan antara kualitas produk, kematangan proses, pengembangan organisasi jadwal usaha, dan proyek. Temuan mereka menunjukkan proses yang jatuh tempo memiliki efek dalam mengurangi software jadwal pengembangan dan usaha. Survei-lain studi berbasis individu dari SW-CMM-dinilai organisasi perangkat lunak mengungkapkan bahwa kedewasaan yang lebih tinggi organisasi yang berhubungan dengan kinerja yang lebih baik, termasuk kemampuan untuk memenuhi anggaran dan jadwal sebagai serta meningkatkan produktivitas staf, kualitas produk, dan kepuasan pelanggan [20]. Herbsleb dan Goldenson di [21] menunjukkan bukti kuat, dalam sampel perangkat lunak 61 organisasi, proses software CMM tinggi berbasis jatuh tempo dikaitkan dengan kinerja tinggi.

Page 4Dampak Tingkat Kematangan Proses CMMI Berbasis pada Usaha, Produktivitas dan diseconomy Skala 355 Meskipun banyak penelitian yang telah meneliti hasil penilaian kinerja CMM berbasis perangkat lunak kematangan proses dan dampaknya terhadap software upaya pengembangan, masih ada karya-karya yang sangat terbatas tentang manfaat keseluruhan perangkat lunak CMMI berbasis

kematangan proses [37]. Studi kasus juga menunjukkan manfaat dari proses perangkat lunak CMMI berbasis jatuh tempo dalam [14, 16, 17, 19, 25, 28, 32, 34, 37]. Goldenson dan Gibson [19] melaporkan beberapa besar dan kredibel bukti kuantitatif bahwa perangkat lunak CMMI berbasis kematangan proses dapat membantu organisasi mencapai kinerja proyek produk-produk berkualitas tinggi dan lebih baik dengan biaya yang lebih rendah dan usaha proyek mengalami penurunan. Karena pembatasan hasil kinerja yang diberikan dalam [19], Gibson et al. [17] terus penilaian kinerja proses perangkat lunak CMMI berbasis perbaikan dan memberikan bukti nyata empiris tentang hasil kinerja yang dapat mencapai sebagai hasil dari perbaikan proses CMMI berbasis. Mereka melaporkan, "Ada sekarang adalah bukti bahwa proses perbaikan menggunakan CMMI Produk Suite dapat mengakibatkan dalam kemajuan dalam jadwal dan biaya kinerja, kualitas produk, pengembalian investasi dan langkah-langkah lain dari hasil kinerja ". 5. Metode Penelitian Dalam rangka untuk menyelidiki dampak CMMI berbasis Proses tingkat kematangan pada berbagai produk perangkat lunak ukuran, itu lebih disarankan untuk mengklasifikasikan perangkat lunak ukuran dengan cara yang tepat karena ukuran dianggap faktor yang paling berpengaruh dalam memprediksi upaya yang produk perangkat lunak [9]. Boehm di [4] telah diklasifikasikan ukuran produk perangkat lunak kecil, menengah, menengah, besar dan sangat besar ditunjukkan pada Tabel 3. Tabel 3. Klasifikasi ukuran perangkat lunak sesuai dengan [4]. Klasifikasi Ukuran (KLOC) Small (S) 2 Intermediate (I) 8 Medium (M) 32 Large (L) 128 Very Large (VL) 512 Faktor skala PMAT digunakan di sini untuk menangkap dampak tingkat kematangan proses yang berbeda pada perangkat lunak pengembangan usaha untuk proyek-proyek ukuran standar diklasifikasikan atas. 5.1. Upaya Estimasi

Ide dasar dalam metode penelitian kami mengukur dampak PMAT dibandingkan faktor lain yang mempengaruhi upaya pengembangan perangkat lunak. Untuk melakukannya, kita memisahkan dampak PMAT dari faktor-faktor lain karena ketika berbagai jenis perbaikan yang dilakukan bersamaan dalam organisasi, manajer proyek akan tidak tahu tentang bagaimana untuk menentukan jumlah perbaikan yang diperoleh dari proses kematangan dengan adanya faktor-faktor lain [8]. Dalam konteks ini, Model COCOMO II digunakan untuk memperkirakan upaya pengembangan perangkat lunak. Selanjutnya, semua Upaya pengganda ditetapkan menjadi nominal, yaitu nilai 1. Selanjutnya, seperti yang dijelaskan dalam Tabel 4, semua skala faktor kecuali PMAT (yang berhubungan dengan proses jatuh tempo) juga diasumsikan nominal. Upaya pengganda dan faktor skala (kecuali PMAT) ditetapkan untuk nilai nominal untuk mengisolasi potensi mereka efek pada upaya pengembangan perangkat lunak. Sebagai contoh, untuk PMAT Peringkat nominal dan ukuran besar standar proyek, dengan menggantikan nilai-nilai dalam persamaan 1 dan 2, kami mendapatkan: PM nominal = 2.94 × 128 0.91 +0.01 × 18,10 = 585,21 Tabel 4. Nilai nominal untuk semua faktor skala di semua tingkatan Peringkat (Kecuali CMMI berbasis PAMT). Skala Faktor (SF) CMMI Level 1 (Lower) CMMI Level 1 (Atas) CMMI Level 2 CMMI Level 3 CMMI Level 4 CMM Aku Level 5 Sangat

Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi Precedentedness (Prec) 3.72 3.72 3.72 3.72 3.72 3.72 Pembangunan Fleksibilitas (FLEX) 3.04 3.04 3.04 3.04 3.04 3.04 Risiko Resolusi (RESL) 4.24 4.24 4.24 4.24 4.24 4.24 Tim Kohesi (TIM) 3.29 3.29 3.29 3.29 3.29 3.29 Baru Proses Kematangan (PMAT) 7.55 5.71 3.81

2.08 1.03 0.00 Penyajian terakhir Segala SF 21,84 20.00 18.10 16.37 15.32 14.29 5.2. Produktivitas Tingkat Dalam rangka untuk menguji hipotesis kami yang meningkatkan tingkat kematangan proses CMMI berbasis meningkatkan Tingkat produktivitas, persamaan 3 diterapkan untuk masing-masing Diperkirakan usaha. Produktivitas = Ukuran Usaha Dimana Ukuran adalah ukuran standar yang digunakan, dan diukur dalam formula ini oleh ribuan baris kode (KLOC), dan Usaha adalah usaha diperkirakan dalam setiap tingkat PMAT untuk semua ukuran standar. Sebagai contoh untuk produktivitas, untuk nominal Peringkat PMAT dan proyek ukuran besar standar, persamaan 3 akan diterapkan dengan upaya diproduksi di sebelumnya bagian. Produktivitas = 128 585,21 = 218,72 (3)

Halaman 5356 Journal Arab Internasional Teknologi Informasi, Vol. 9, No 4, Juli 2012 5.3. Diseconomy Skala Diseconomy skala mengacu relatif lebih meningkat dalam upaya dibandingkan dengan peningkatan ukuran produk perangkat lunak. Artinya, dua kali lipat ukuran proyek akan menghasilkan lebih dari dua kali lipat dari upaya awal proyek yang dibutuhkan untuk menyelesaikan proyek. Untuk membuat ini konsep yang lebih jelas, Memon [29] menyarankan membagi ukuran proyek standar dibahas sebelumnya oleh kecil ukuran (2 KLOC) dan kemudian dipanggil dari kecil ke menengah (dari S ke I), dari kecil ke menengah (dari S to M), dari kecil ke besar (dari S ke L), dan dari

kecil yang sangat besar (dari S ke VL). Demikian pula, mereka Upaya yang sesuai juga dibagi dengan upaya ukuran kecil dalam rangka untuk memvisualisasikan efek diseconomy skala ditunjukkan pada Tabel 5. Tabel 5. Software ukuran rasio. Klasifikasi Ukuran Jatah Dari S ke saya 4 Dari S ke M 16 Dari S ke L 64 Dari S ke VL 256 6. Evaluasi Ukur Dalam rangka untuk mengevaluasi dan membandingkan hasil yang kami ajukan, ukuran efektivitas diperlukan. Dalam studi ini, persentase perubahan dalam upaya pengembangan perangkat lunak, Tingkat produktivitas dan diseconomy skala digunakan sebagai Tindakan utama Efektivitas (MOE). Itu perubahan persen berarti baik kenaikan atau penurunan usaha, tingkat produktivitas dan diseconomy skala. Ini mengukur kriteria akan menentukan besarnya pengaruh tingkat kematangan proses yang berbeda pada upaya pengembangan untuk semua ukuran standar perangkat lunak proyek. Untuk menghitung persentase ini, kita akan mengasumsikan rating nominal PMAT sebagai kasus dasar. Oleh karena itu, persentase perubahan usaha, produktivitas, dan diseconomy skala diukur dengan menggunakan persamaan 4. Persen Perubahan = Parameter-Parameter nomi = al Parameter nominal Dimana Parameter mengacu pada nilai yang dihitung usaha, produktivitas, atau diseconomy skala pada khususnya PMAT rating. Sedangkan Parameter nominal lihat dengan nilai nominal parameter yang sama. A kombinasi perubahan positif dan negatif akan terlihat pada nilai-nilai yang dihasilkan. Sebuah nilai negatif menunjukkan persentase penurunan nilai parameter dan satu pertunjukan persentase peningkatan positif dalam

nilai parameter. 7. Hasil dan Diskusi 7.1. Usaha Setelah menerapkan metode kami, COCOMO II telah memperkirakan upaya untuk semua ukuran proyek standar di setiap PAMT rating, Tabel 6 menunjukkan hasil usaha, Tabel 7 menunjukkan persentase perubahan usaha dalam setiap proses tingkat kematangan untuk semua proyek ukuran standar, dan Gambar 1 adalah representasi visual dari Tabel 7. Tabel 6. Upaya diperkirakan dalam semua peringkat PMAT CMMI berbasis untuk semua ukuran standar. Proyek Upaya (PM) Berdasarkan Penilaian PMAT dan Ukuran Proyek Ukuran Klasifikasi Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi Kecil 2 6.43 6.35 6.26 6.19 6.14 6.10 Menengah 8 30.72 29.56 28.42 27.42 26.82 26.25 Medium 32 146,81 137,74 128,96 121,46 117,12 113,01 Besar 128 701,65 641,73 585,21 538,09 511,37 486,44 Sangat Besar 512 3353,42 2989,76 2655,59 2383,91 2232,77 2093,81 Tabel 7. Perubahan persen usaha di semua peringkat CMMI berbasis PMAT untuk semua ukuran standar. Proyek Rata-rata% Perubahan Usaha

Ukuran Klasifikasi Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi Kecil 2 2.63 1.33 0.00 -1.19 -1.91 -2.61 Menengah 8 8.09 4.03 0.00 -3,53 -5,62 -7,62 Medium 32 13.84 6.81 0.00 -5,82 -9,19 -12,37 Besar 128 19.90 9.66 0.00 -8,05 -12,62 -16,88 Sangat Besar 512 26.28 12.58 0.00 -10,23 -15,92 -21,15 Persentase perubahan usaha untuk proyek-proyek ukuran standar Peringkat PMAT Gambar 1. Perubahan persen usaha di semua peringkat PMAT untuk semua ukuran standar. Seperti terlihat pada Tabel 6, hasil menunjukkan bahwa untuk setiap peningkatan rating PMAT, ada penurunan dalam upaya pengembangan perangkat lunak yang diperlukan. Itu dapat melihat bahwa perbaikan ini dalam upaya lebih besar untuk ukuran proyek yang lebih besar daripada ukuran yang lebih kecil. Juga perubahan persentase yang ditunjukkan dalam Tabel 7 dan grafis pada Gambar 1 jelas memberikan

indikasi yang sama. Perubahan persen dalam upaya yang diperlukan bervariasi dari kenaikan 2,63% untuk rating yang sangat rendah PMAT pada penurunan dari 2,61% untuk peringkat ekstra tinggi (Perubahan total 5,24%) untuk proyek-proyek ukuran kecil, -30.00 -20.00 -10.00 0.00 10.00 20.00 30.00 VeryLow Rendah Nominal Tinggi VeryHigh Ekstra Tinggi PMATRatings Kecil Menengah Medium Besar VeryLarge E f f o r t (4)

Page 6Dampak Tingkat Kematangan Proses CMMI Berbasis pada Usaha, Produktivitas dan diseconomy Skala 357 sedangkan untuk proyek yang sangat besar, perubahan persen upaya yang diperlukan bervariasi dari kenaikan 26.28% untuk Peringkat sangat rendah PMAT terhadap penurunan 21,15% untuk rating ekstra tinggi (perubahan total 47.43%). 7.2. Produktivitas Tingkat Tabel 8 dan Gambar 2 menunjukkan produktivitas yang dihasilkan. Sedangkan perubahan persen dalam produktivitas di setiap Proses tingkat kematangan untuk semua proyek ukuran standar adalah ditunjukkan pada Tabel 9 dan Gambar 3. Tabel 8. Tingkat produktivitas di semua peringkat PMAT CMMI berbasis untuk semua ukuran standar. Proyek

Produktivitas (KLOC / PM) Berdasarkan ISF-PMAT Penilaian dan Ukuran Proyek Ukuran Klasifikasi Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi Kecil 2 311 315 319,34 323 326 328 Menengah 8 260 271 281,50 292 298 305 Medium 32 218 232 248,13 263 273 283 Besar 128 182 199 218,72 238 250 263 Sangat Besar 512 153 171

192,80 215 229 245 Tingkat produktivitas untuk proyek-proyek ukuran standar Peringkat PMAT Gambar 2. Tingkat produktivitas di semua peringkat PMAT untuk semua standar ukuran. Seperti dapat dilihat pada Tabel 8 dan visual pada Gambar 2, ada pertumbuhan yang cukup besar dalam tingkat produktivitas di semua tingkat PMAT. Mereka juga memberikan indikasi yang jelas bahwa perubahan tingkat produktivitas (meningkat) lebih cepat untuk proyek-proyek yang lebih besar dibandingkan dengan yang lebih kecil proyek. Tabel 9. Persen perubahan produktivitas dalam semua CMMI berbasis PMAT peringkat untuk semua ukuran standar. Proyek Rata-rata% Perubahan Produktivitas Ukuran Klasifikasi Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi Kecil 2 -2.56 -1.31 0.00 1.21 1.95 2.68 Menengah 8 -7,48 -3,87 0.00 3.66 5.95 8.24 Medium 32 -12,16 -6,37 0.00 6.18 10.11 14.12

Besar 128 -16,60 -8,81 0.00 8.76 14.44 20.31 Sangat Besar 512 -20,81 -11,18 0.00 11.40 18.94 26.83 Seperti ditunjukkan pada Tabel 9 dan grafis dalam Gambar 3, perubahan persen dalam tingkat produktivitas bervariasi dari penurunan 2,56% untuk rating yang sangat rendah PMAT ke peningkatan 2,68% untuk peringkat ekstra tinggi (total perubahan 5,24%) untuk proyek-proyek ukuran kecil. Sedangkan untuk proyek yang sangat besar, perubahan persen diperlukan Upaya bervariasi dari penurunan (20,81%) untuk sangat rendah Peringkat dari PMAT peningkatan dari 26,83% untuk rating dari ekstra tinggi (perubahan total 47.64%). Persentase perubahan produktivitas untuk proyek-proyek ukuran standar Peringkat PMAT Gambar 3. Persen perubahan produktivitas di semua peringkat PMAT untuk semua ukuran standar. 7.3. Diseconomy Skala Ketika ukuran standar dibagi dengan ukuran kecil (2 KLOC), sama, upaya yang sesuai mereka juga dibagi dengan upaya ukuran kecil untuk memvisualisasikan pengaruh diseconomy skala seperti yang ditunjukkan pada Tabel 10 dan Gambar 4. Untuk memvisualisasikan efek dari diseconomy skala, rasio ukuran telah diplot pada Gambar 4. Itu perubahan persen diseconomy skala dalam setiap proses tingkat kematangan untuk semua proyek ukuran standar ditunjukkan pada Tabel 11 dan Gambar 5. Tabel 10. Diseconomy skala dalam semua peringkat CMMI berbasis PMAT untuk semua ukuran standar. Proyek Diseconomy Skala Berdasarkan CMMI Berbasis Penilaian PMAT dan Ukuran Proyek Klasifikasi Ukuran Perbandingan Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi

Dari S ke saya 4 4.78 4.66 4.54 4.43 4.37 4.30 Dari S ke M 16 22.84 21.71 20.59 19.63 19.06 18.53 Dari S ke L 64 109.17 101.13 93.44 86.96 83,24 79,75 Dari S ke VL 256 521,74 471,14 424,02 385,24 363,45 343,27 Diseconomy skala untuk proyek-proyek ukuran standar Gambar 4. Diseconomy skala dalam semua peringkat PMAT untuk semua standar ukuran. Tabel 10 dan Gambar 4 menunjukkan bahwa diseconomy dari skala meningkatkan diinginkan dengan perbaikan PMAT 0 100 200 300 400 VeryLow Rendah Nominal Tinggi VeryHigh Ekstra Tinggi Kecil Menengah Medium Besar VeryLarge -30.00 -20.00 -10.00 0.00 10.00 20.00 30.00 VeryLow

Rendah Nominal Tinggi VeryHigh ExtraHigh PMATRatings Smale Menengah Medium Besar VeryLarge 0 100 200 300 400 500 600 Ukuran Perbandingan Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi PMAT level rating / Ukuran (KLOC) Froms ke I Froms ke M Froms ke L Froms ke VL R sebuah t i o o f e f f o r t

/ s i z e P r o d u c t i v i t y ( K L O C / P M ) P r o d u c t i v i t y ( K L O C / P M

)

Page 7358 Journal Arab Internasional Teknologi Informasi, Vol. 9, No 4, Juli 2012 tingkat rating. Mereka juga memberikan jelas dan indikasi yang cukup bahwa tingkat produktivitas perubahan (kenaikan) lebih cepat untuk proyek-proyek besar seperti dibandingkan dengan proyek-proyek kecil. Tabel 11. Perubahan Persen diseconomy skala dalam semua CMMI- peringkat PMAT berbasis untuk semua ukuran standar. Proyek Rata-rata% Perubahan diseconomy Skala Ukuran Klasifikasi Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi Dari S ke saya 4 5.32 2.67 0.00 -2,37 -3,78 -5,14 Dari S ke M 16 10.93 5.41 0.00 -4,68 -7,42 -10,02 Dari S ke L 64 16.83 8.22 0.00 -6,94 -10,92 -14,65 Dari S ke VL 256 23.05 11.11 0.00 -9,15 -14,29 -19,04 Persentase perubahan diseconomy skala od untuk proyek-proyek ukuran standar Tingkat kematangan proses Gambar 5. Perubahan Persen diseconomy skala dalam semua PMAT peringkat untuk semua ukuran standar. Seperti ditunjukkan pada Tabel 11 dan grafis pada Gambar 5,

perubahan persen diseconomy skala bervariasi dari meningkat 5,32% untuk rating yang sangat rendah PMAT ke penurunan 5,14% untuk peringkat ekstra tinggi (total perubahan 10,46%) untuk proyek-proyek ukuran kecil. Sedangkan untuk proyek yang sangat besar, perubahan persen diperlukan Upaya bervariasi dari peningkatan 23,05% untuk sangat rendah Peringkat dari PMAT terhadap penurunan 19,04% untuk rating ekstra tinggi (perubahan total 42.09%). 8. Kesimpulan dan Kerja Masa Depan Tulisan ini meneliti dampak CMMI berbasis tingkat kematangan proses pada pengembangan perangkat lunak usaha, tingkat produktivitas dan diseconomy skala untuk set ukuran proyek standar. Hasil ini Penyelidikan telah mendorong hipotesis dan mengungkapkan bahwa tingkat kematangan proses penilaian berdasarkan CMMI jauh mempengaruhi upaya pengembangan perangkat lunak di hal produktivitas dan diseconomy skala, yaitu, untuk setiap tingkat lebih tinggi PMAT, ada penurunan upaya yang diperlukan, meningkatkan tingkat produktivitas dan pengurangan diseconomy skala, meskipun persentase (kenaikan / penurunan) tidak seragam antara tingkat. Hasil juga menunjukkan bahwa efek ini lebih besar dan signifikan untuk proyek-proyek besar seperti dibandingkan dengan proyek-proyek kecil. Ini mengharuskan adopsi perbaikan proses CMMI-berbasis organisasi perangkat lunak yang mengembangkan proyek ukuran besar. Sebagai hasil dari investigasi dampak kematangan proses pada usaha, tampaknya masuk akal untuk mendukung saran bahwa PMAT adalah masukan yang signifikan untuk biaya estimasi model perangkat lunak. Masa Depan kerja di bidang proses CMMI berbasis jatuh tempo memerlukan pengumpulan data historis untuk masing-masing area proses 22 digunakan dalam CMMI dalam rangka untuk memeriksa daerah mana proses memiliki pengaruh paling besar pada usaha, produktivitas, dan diseconomy skala. Selain itu, seperti SW-CMM, CMMI memiliki dua berbeda representasi, Bertahap dan berkelanjutan. Penelitian ini difokuskan pada representasi bertahap, karena itu, lanjut Penelitian dianjurkan untuk dilakukan pada dampak CMMI berbasis kemampuan Proses dari perspektif representasi terus menerus. Referensi [1] A. Alyahya, Ahmad R., dan Lee S., "Dampak CMMI Based Software Proses Jatuh Tempo pada COCOMO II

Usaha Estimasi, " Itu International Arab Journal of Information Teknologi, vol. 7, no. 2, hlm 129-137, 2010. [2] B. Boehm, Clark B., Horowitz E., Westland C, Madachy R., dan R. Selby, "Model Biaya untuk Masa depan Perangkat lunak Hidup Sepeda Proses: COCOMO 2.0, "dalam Prosiding Khusus Volume pada Proses Perangkat Lunak dan Produk Pengukuran, Amsterdam, hlm 45-60, 1995. [3] Boehm B., Horowitz E., R. Madachy, Reifer D., Clark B., Steece B., Brown A., Chulani S., dan ABTS C., Software Estimasi Biaya dengan COCOMO II, Prentice Hall, 2000. [4] B. Boehm, Rekayasa Perangkat Lunak Ekonomi, Prentice Hall, 1981. [5] Bollinger T. dan McGowan C., "A Look Kritis pada Software Capability Evaluasi, "IEEE Software, vol. 26, no. 5, hlm 80-83, 2009. [6] Butler K., "Manfaat Ekonomi Software Proses Perbaikan, "dalam Prosiding Crosstalk, Bukit AFB, Amerika Serikat, hlm 14-17, 1995. [7] Chrissis M., Konrad M., dan S. Shrum, CMMI: Pedoman Proses Integrasi dan Produk Peningkatan, 3 ed , Addison-Wesley, 2003. [8] Clark B., "Mengukur Dampak Proses Peningkatan Usaha, "IEEE Software, vol. 17, no. 6, hlm 65-70, 2000. [9] Clark, B., "Pengaruh Proses Perangkat Lunak Tempo pada Software Development Effort, "PhD Disertasi, University of Southern California, 1997. [10] Damian D., D. Zowghi, Vaidyanathasamy L., dan Pal Y., "Pengalaman Industri dalam Proses Peningkatan: Sebuah Penilaian Awal di Australia Center for Unisys Software, "dalam Prosiding Simposium Internasional tentang Rekayasa Perangkat Lunak empiris, Amerika Serikat, hlm 111 - 123, 2002.

-30.00 -20.00 -10.00 0.00 10.00 20.00 30.00 Sangat Rendah Rendah Nominal Tinggi Sangat Tinggi Ekstra Tinggi Froms ke I Froms ke M Froms ke L Froms ke VL D i s e c o n o m y o d s c sebuah l e

Page 8Dampak Tingkat Kematangan Proses CMMI Berbasis pada Usaha, Produktivitas dan diseconomy Skala 359 [11] M. Diaz dan Raja J., "Bagaimana Dampak CMM Kualitas, Produktivitas, Mengolah, dan Bawah Line, "The Journal of Software Pertahanan Teknik, vol. 15, no. 3, hlm 9-14, 2003. [12] Donald H., M. Krishnan, dan Slaughter A., "Pengaruh Proses Kematangan pada Kualitas, Siklus Waktu, dan Upaya Produk Perangkat Lunak

Pembangunan, "Jurnal Ilmu Manajemen, vol. 46, no. 4, hlm 451-466, 2000. [13] El-Emam K. dan Goldenson D., "An Empiris Review Software Proses Penilaian, " Kemajuan dalam Komputer, vol. 53, hlm 319-423, 2000. [14] El-Emam K., "TrialStat Perusahaan: On Jadwal dengan Kualitas Tinggi dan Penghematan Biaya untuk Nasabah, "Journal of Technology Software, vol. 10, tidak ada. 1, hlm 24-29, 2007. [15] Galin D. dan M. Avrahami, "Apakah Program CMM Investasi Menguntungkan? Menganalisis Studi Past, " Software IEEE, vol. 23, no. 6, hlm 81-87, 2006. [16] Garmus D. dan S. Iwanicki, "Peningkatan Kinerja Harus Diharapkan dari Proses Perbaikan, "Journal of Technology Software, vol. 10, tidak ada. 1, hlm 14-17, 2007. [17] Gibson D., D. Goldenson, dan Kost K., "Kinerja Hasil Proses CMMI Berbasis Perbaikan, "Laporan Teknis, Software Engineering Institute CMU/SEI-2006-TR-004 ESC-TR-2006-004, 2006. [18] Girish H., James J., dan Klein G., "Software Kualitas dan IS Proyek Prestasi Perbaikan dari Pengembangan Perangkat Lunak Proses Kematangan dan IS Implementasi Strategi, "Jurnal Sistem dan Software, vol. 80, no. 4, hlm 616-627, 2007. [19] Goldenson D. Gibson dan D., "Mendemonstrasikan Dampak dan Manfaat CMMI: Sebuah Update dan Hasil Awal, "Laporan Teknis, CMU/SEI-2003-SR-009, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003. [20] Goldenson D. dan J. Herbsleb, "Setelah Appraisal: Sebuah Survei sistematis Proses Peningkatan, Manfaat, serta Faktor-faktor yang Sukses Pengaruh, "Laporan Teknis, CMU/SEI- 95-TR-009, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1995.

[21] J. Herbsleb dan Goldenson D., "A Systematic Survei Pengalaman CMM dan Hasil, "dalam Prosiding 18 th Konferensi Internasional Rekayasa Perangkat Lunak, Jerman, hlm 323-330, 1996. [22] Herbsleb J., A. Carleton, Rozum J., J. Siegel, dan Zubrow D., "Manfaat CMM-Based Software Proses Perbaikan: Hasil Awal, "Teknis Laporan, CMU/SEI-94-TR-13, Perangkat lunak Teknik Institute, Carnegie Mellon University, Pittsburgh, 1994. [23] Humphrey S., R. Snyder, dan Willis R., "Perbaikan Proses Perangkat Lunak di Hughes Pesawat, "IEEE Software, vol. 8, no. 4, hlm 11-23, 1991. [24] Jones L. dan A. Soule, "Proses Perangkat Lunak Perbaikan dan Product Line Praktek: CMMI dan Kerangka Software Product Line Praktek, "Laporan Teknis, CMU/SEI-2002- TN-012, Pittsburg, Pennsylvania: Carnegie Mellon University, Perangkat lunak Teknik Institute, 2002. [25] Liu A., "Motorola Software Group Cina Pusat: Nilai Ditambahkan oleh CMMI, "Jurnal Software Teknologi, vol. 10, tidak ada. 1, hlm 18-23, 2007. [26] Manish A. dan C. Kaushal, "Software Effort, Mutu dan Siklus Waktu: Sebuah Studi CMM Level 5 Proyek, "IEEE Transaksi pada Software Engineering, vol. 33, no. 3, hal 145 - 156, 2007. [27] McGibbon T., "Kasus Bisnis untuk Software Proses Perbaikan, "Laporan Akhir, Kontrak Nomor F30602-92-C-0158, dan Analisis Data Pusat untuk

Software, Kaman Ilmu Corporation, New York, 1996. [28] T. McGibbon, Grader M., dan Vienneau R., "The DACS ROI Dashboard-Meneliti Hasil CMMI ® Improvement, "Journal of Software Teknologi, vol. 10, tidak ada. 1, hlm 30-35, 2007. [29] G. Memon, "Pengaruh Proses Tingkat Kematangan Pengembangan Perangkat Lunak Upaya Standar Proyek ukuran, "Jurnal Informasi dan Teknologi Komunikasi, vol. 2, no. 1, hlm 10 - 18, 2008. [30] M. Paulk, "Bagaimana ISO 9001 Membandingkan dengan CMM, "IEEE Software, vol. 12, no. 1, hlm 74 - 83, 1995. [31] M. Paulk, Weber C., Curtis B., dan M. Chrissis, The Capability Maturity Model: Pedoman Meningkatkan Proses Perangkat Lunak, Addison- Wesley, 1995. [32] Peter J. dan Rohde L., "Kinerja Hasil dari CMMI Berbasis Proses Perbaikan, " Journal of Software Technology, vol. 10, tidak ada. 1, hlm 5-8, 2007. [33] Pyzdek T., The Six Sigma Handbook: The Panduan untuk greenbelt, Blackbelts, dan lengkap Manajer di Semua Tingkatan, McGraw-Hill, 2003. [34] M. Sapp, Stoddard R., dan Christian T., "Biaya, Jadwal dan Kualitas Perbaikan di Warner Udara Robins Logistik Pusat, "Jurnal Software Teknologi, vol. 10, tidak ada. 1, hlm 10-13, 2007. [35] Staple M. dan M. Niazi, "tinjauan sistematik: Sistematis Tinjau dari Organisatoris Motivasi untuk Mengadopsi CMM Berbasis SPI, " Jurnal Informasi dan Teknologi Perangkat Lunak, vol. 50, no. 7-8, hlm 605-620, 2008.

Page 9360

Journal Arab Internasional Teknologi Informasi, Vol. 9, No 4, Juli 2012 [36] Wohlwend H. dan Rosenbaum S., "Schlumberger Perangkat lunak Perbaikan Program, "Jurnal Transaksi IEEE pada Software Engineering, vol. 20, no. 11, hlm 833 - 839, 1994. [37] Yi T., Sheng T., Ching C, dan Huang S., "Menilai Kinerja Adopsi CMMI- Berbasis Peningkatan Proses Perangkat Lunak di 18 Taiwan Perusahaan, " Majalah dari Perangkat lunak Studi Rekayasa, vol. 1, no. 2, hlm 96-104, 2006. Majed Alyahya adalah seorang peneliti di bidang rekayasa perangkat lunak. Dia memegang gelar PhD dalam komputer sains dari University of Malaya, Malaysia pada 2010. Ia menerima gelar Gelar BSc dalam ilmu komputer dari Zarqa Perguruan Tinggi Swasta, Jordan pada tahun 2002 dan gelar MSc dalam ilmu komputer dari University of Jordan pada tahun 2004. Penelitiannya kepentingan termasuk manajemen proyek, proses perangkat lunak model, perangkat lunak proses penaksiran dan perbaikan, dan estimasi biaya perangkat lunak. Rodina Ahmad adalah dosen senior di rekayasa perangkat lunak dan penelitian anggota klaster TIK di University of Malaya, Malaysia. Dia memegang gelar PhD dalam informasi sistem dari National University Malaysia pada tahun 2006. Dia diperoleh nya BSc dan gelar MSc dalam ilmu komputer dari

Rensselaer Polytechnic Institute, Amerika Serikat. Dia memiliki lebih dari 19 tahun pengalaman dalam mengajar dan meneliti di bidang rekayasa perangkat lunak dan sistem informasi. Dia telah menerbitkan banyak konferensi dan jurnal makalah di tingkat nasional dan tingkat internasional. Saat ini, dia mengawasi tujuh Mahasiswa PhD dalam persyaratan pendidikan teknik, perencanaan rilis software, CMMI kerangka evaluasi, metrik dinamis perangkat lunak dan informasi sistem. Dia juga memimpin dan mengajar kursus di kedua BSc dan tingkat MSc dalam ilmu komputer dan perangkat lunak rekayasa