PENDEKATAN EMPIRIS DALAM REKAYASA PERANGKAT LUNAK

Jurnal INFORMASI Vol.4 No.1 (4), Juli 2011

31

PENDEKATAN EMPIRIS DALAM REKAYASA PERANGKAT LUNAK Tien fabrianti Kusumasari Sistem Informasi, STMIK IM, Jl.Jakarta No.79 Bandung [email protected]

Abstrak Proses pengembangan prangkat lunak merupakan proses engineering / rekayasa yang diturunkan dari ilmu computer dan praktek terbaik. Proses tersebut meliputi requirement, analisis, desain, implementasi dan testing, serta evolusi. Rekayasa perangkat lunak selama ini selalu didekati dari sudut pandang ilmu engineering yang sudah matang seperti teknik sipil dan mesin, padahal karakteristik perangkat lunak ini berbeda dengan manufaktur dan sipil. Dalam makalah ini diungkapkan paradigma baru dalam rekayasa perangkat lunak yaitu konsep disain dalam pembangunan perangkat lunak yang dihubungkan dengan pengukuran secara empiris. Disain dan blueprint untuk pengembangan perangkat lunak adalah kode program itu sendiri. Kode program tersebut dapat dibuat mudah dibaca, terstruktur, dan dapat diukur. Key words: rekayasa perangkat lunak, metode empiris perangkat lunak, disain perangkat lunak.

1. Pendahuluan Rekayasa perangkat lunak yang dikenal dengan istilah software engineering, merupakan cabang ilmu engineering yang tergolong muda. Software engineering menurut IEEE merupakan penerapan suatu pendekatan yang sistematis, disiplin, dan terkuantifikasi atas pengembangan, penggunaan, dan pemeliharaan perangkat lunak serta studi mengenai pendekatan-pendekatan engineering-cici untuk perangkat lunak. Software engineering merupakan aplikasi engineering untuk perangkat lunak yang terintegrasi secara signifikan dengna matematika, ilmu komputer, dan praktek-praktek engineering (ACM, 2006). Dengan demikian rekayasa perangkat lunak sangat erat kaitannya dengan pengembangan dan maintenance perangkat lunak agar menghasilkan produk perangkat lunak yang efiseien, murah, memenuhi kebutuhan dan kepuasan user serta mudah menangani perubahan-perubahan. Dalam disiplin rekayasa perangkat lunak ini terdapat berbagai macam pendekatan-pendekatan metodologi dalam pengembangan dan maintenance perangkat lunak. Metodologi-metodologi pengembangan perangkat lunak ini berkaitan dengan bagaimana melakukan proses-proses untuk membuat perangkat lunak baik secara personal maupun kelompuk. Proses dalam pengembangan perangkat lunak tidak hanya bagaimana membangun perangkat lunak tetapi lebih menekankan pada pemilihan metode bagaimana pekerjaan tersebut dilakukan dalam sebuah tim untuk memenuhi jadwal, biaya, dan kepuasan pengguna. Menurut Pressman (2010) terdapat suatu framwork proses dalam pengembangan perangkat lunak yang generic/umum, yaitu komunikasi, perencanaan, pemodelan, konstruksi, dan deployment. Framework proses tersebut dapat digunakan untuk pengembangan perangkat lunak dari skala kecil sampai besar maupun untuk pengembangan aplikasi perangkat lunak berbasis web. Sedangkan struktur dari proses-proses diatas disebut dengan software methodology, sedangkan Pressman (2010) menyebutnya sebagai software process model. Pressman (2010) juga menyatakan bahwa

ISSN 2085-8795

LPPM STMIK IM


32

semua software process model dapat mengakomodasi framework proses pengembangan perangkat lunak generic/umum, namun berbeda penekanan aktifitasnya dan aliran prosesnya. Hampir semua pengembangan perangkat lunak mengacu pada metodologi pengembangan perangkat lunak, namun menurut statistik kesuksesan proyek perangkat lunak kurang dari 40% (Galorath Incorporated, 2008). Keberhasilan masing-masing metodologi pengembangan perangkat lunak bervariasi. Berdasarkan hasil statistik tersebut maka perlu adanya evaluasi mengenai mangemen proyek pengembangan perangkat lunak dan metodologi yang digunakan. Pada makalah ini penulis mencoba menganalisis kegagalan proyek perangkat lunak tersebut dari sisi disain yang berkaitan dengan metodologi-metodologi dalam pengembangan perangkat lunak.

2. Kajian Teori Hal pertama yang ditinjau dalam makalah ini adalah mengenai engineering dan software engineering. Kajian ini membahas mengenai apa itu engineering dan software engineering. Pembahasan yang kedua adalah mengenai software design dan kaitannya dengan metodologimetodologi dalam mengembangkan perangkat lunak. Teori lain yang berkaitan dengan kajian ini adalah pengukuran-pengukuran dalam perangkat lunak yang telah ada. Teori-teori yang melandasi analisis kegagalan proyek perangkat lunak yang ditinjau dari sisi disain perangkat lunak dalam pengembangan perangkat lunak adalah software engineering, software development methodology, dan pengukuran perangkat lunak.

2.1. Software Engineering Menurut American Engineers’ Council for Professional Development (ECPD) mendefinisikan engineering sebagai berikut (wikipedia, 2010):

• aplikasi kreatif dari prinsif-prinsip ilmu pengetahuan untuk mendisain atau mengembangkan struktur, mesin, peralatan, atau proses manufaktur atau memanfaatkan ilmu pengetahuan secara tunggal atau kombinasi;

• membangun atau mengoperasikan disain tersebut diatas dengan ilmu pengetahuan • memperkirakan kelakuan disain pada kondisi operasi tertentu • dan semua hal mengenai fungsional, keekonomian, dan keamanannya Sedangkan menurut ensiklopedia britanika (2010), engineering merupakan aplikasi dari ilmu pengetahuan untuk mendapatkan konversi optimum dari sumber daya alam menjadi produk yang berguna bagi manusia.

Gambar 1 Software Engineering Layers Pengertian software engineering dari berbagai sumber telah disebutkan pada bagian 1 (satu). Menurut Pressman (2010) software engineering merupakan lapisan-lapisan teknologi seperti pada Error! Reference source not found. yaitu peralatan, meetode, proses, dan kualitas. Lapisan dasar pada software engineering merupakan kualitas, karena semua pendekatan-pendekatan yang diambil dalam software engineering harus menitik beratkan pad kualitas perangkat lunak pada khususnya dan kualitas organisasi pada umumnya. Sedangkan lapisan dasar software engineering adalah proses, yang mana proses tersebut harus efisien dan efektif karena akan menyatukan antara

ISSN 2085-8795

LPPM STMIK IM


33

lapisan teknologi dengan rasio serta batas waktu untuk mengembangkan perangkat lunak. Lapisan berikutnya adalah metode, yaitu tentang bagaimana membangun sebuah perangkat lunak komputer yang berkaitan dengan serangkaian aktifitas. Lapisan terakhir adalah peralatan, yang membantu dalam otomatisasi atau semi-otomatisasi dalam melakukan proses dan metode pada lapisan sebelumnya.

2.2. Software Development Methodology Metodologi pengembangan perangkat lunak dalam konsep software engineering adalah merupakan sebuah framework yang digunkan untuk membuat struktur, perencanaan, dan pengendalian proses pengembangan suatu sistem informasi (CMS, 2008). Dengan kata lain metodologi ini merupakan pendekatan dasar dalam pengembangan dan maintenance perangkat lunak. Terdapat beberapa pendekatan dalam pengembangan dan maintenance perangkat lunak, antara lain (CMS, 2008) :

• • • • • • •

Waterfall Approach : linear framework type. Prototyping Approach : iterative framework type Incremental Approach: combination of linear and iterative framework type Spiral Approach : combination of linear and iterative framework type Rapid Application Development (RAD) Approach: Iterative Framework Type Extreme Programming Approach

Project Manaement Institute Menurut Pressman (2010) berbagai pendekatan tersebut mempunyai proses umum yang sama, hanya penekanan dan aliran prosesnya saja yang membedakan dari masing-masing pendekatan pengembangan perangkat lunak tersebut. 2.2.1. Pendekatan Waterfall Model waterfall dikemukakan pertama kali oleh Wiston W. Royce pada tahun 1979 (wikipedia, 2010) namun tidak dengan istilah waerfall. Model waterfall merupakan pendekatan pengembangan perangkat lunak secara sekuensial yang terlihat seperti aliran air terjun, dengan fase-fase system requirement, software requrement, analiis, desain program, coding, testing, dan operasi seperti pada .

Gambar 2 Model Waterfall (Royce, 1970) Prinsip dasar pendekatan waterfall adalah :

ISSN 2085-8795

LPPM STMIK IM


34

• Proyek dibagi menjadi fase-fase sekuensial, dengan beberapa fase overlaping dan berbalik arah

• Menekankan pada perencanaan, penjadwalan, target, budget, dan implementasi semua sistem pada satu waktu.

• Pengendalian yang ketat yang dimaintenace sepanjang proyek dengan menulis dokumentasi 2.2.2. Pendekatan Prototyping Prototyping merupakan pendekatan metodologi dengan membua prototype selama proses pengembangan. Menurut Pressman (2010) pendekatan ini termasuk evolutionary process model. Prinsip dasar prototyping process model ini adalah :

• Bukan merupakan stand alone metodologi, tetapi lebih kepada pendekatan untuk menangani bagian tertentu dari sistem yang besar

• Mencoba mengurangi resiko proyek inheren dengan memecah proyek menjadi bagianbagian yang lebih kecil selama proses pengembangan

• User dilibatkan selama proses pengembangan • Membuat mock-up sistem skala kecil dan dimodifikasi secara iteratif sampai memenuhi keinginan user

• Prototype tersebut tidak akan digunakan dalam sistem yang dibangun hanya merupakan mock up saja

• Pemahaman mengenai fundametal permasalahan bisnis merupakan hal yang utama untukmenghindari penyelesaian yang salah 2.2.3. Pendekatan Incremental Incremental process model merupakan metodologi yang mengkombinasi linier dan iteratif aliran proses dalam pengembangan perangkat lunak. Tujuan utama kombinasi dan iterativ ini adalah mengurangi resiko kegagalan proyek dengan cara memecah pekerjaan menjadi bagian-bagian yang lebih kecil selama pengembangan. Prinsip dasar dalam incremental process model antara lain adalah sebagai berikut :

• Serangkaian waterfall mini yang harus diselesaikan sebelum melakukan increment berikutnya

• Semua requirement dilakukan sebelum dilakukan evolusioner • Fase-fase dalam setiap increment dilakukan seperti waterfall sehingga diperoleh perangkat lunak yang diinginkan dengan mengikuti fase iteratif seperti pendekatan prototyping. 2.2.4. Agile Methodology Dalam bukunya Abrahamson (Abrahamson, 2007), dkk menyatakan bahwa McCauly (2001) berpendapat bahwa dubawah filosofi process-oriented method requirement dikunci dan dibekukan sebelum proses disain dalam pengembangan perangkat lunak. Dengan pendekatan metodologi agaile ini perubahan-perubahan selau mungkin dilakuan sehingga fleksibel dan adaptif. Adapun prinsip-prinsip dalam agile manifesto adalah sebagai berikut :

• Mencapai kepuasan pelanggan dengan memberikan delivery perangkat lunak yang berguna dan cepat

• Menerima perubahan requirement, meskipun di akhir pengembangan

ISSN 2085-8795

LPPM STMIK IM


• • • • • • • • • •

35

Produk software didelivery sesering mungkin (dalam hitungan minggu dari pada bulan) Produk perangkat lunak merupakan dasar pengukuran software Memungkinkan pengembangan, dapat dimaintain Hubungan antara orang bisnis dengan pengembang sangat dekat, bekerja sama dalam sehari-hari Tatap muka merupakan komunikasi yang paling baik Proyek dibangun dari dorongan individu yang seharusnya di percaya Perhatian yang terus berlanjut terhadap kualitas teknik dan disain yang baik Kesederhanaan Self-organizing team Beradaptasi terhadap perubahan lingkungan secara reguler

2.3. Pengukuran dalam Perangkat lunak Suatu perangkat lunak dapat diukur dari berbagai parameter. Ukuran pertama adalah ukuran program dari segi algoritma yaitu big O notation. Big O notation (Bell 2009) digunakan dalam ilmu komputer untuk mendiskripsikan performasi dan kekomplekan sebuah algoritma. Big O notation khususnya mendiskripsikan skenario terburuk dan dapat digunakan untuk mendiskripsikan waktu eksekusi yang diperlukan atau space yang diperlukan oleh suatu algoritma. Pada konsep pemrograman berorientasi objek, terdapat beberpa pengukuran yaitu kohesi dalam sebuah klas dan smel-smell pada refactoring. Kohesi merupakan ketertatikan objek-objek pada sebuah kelas yang sama. Apabila suatu objek lebih banyak berhubungan dengan kelas lain dari pada klas nya sendiri maka objek tersebut dikatakan kohesinya rendah. Sedangkan code refactoring (wikipedia 2010) merupakan proses perubahan program komputer tanpa memodifikasi fungsional dari program tersebut dengan tujuan untuk meningkatkan kualitas perangkat lunak. Keuntungan dari refactorign adalah mengurangi kekomplekan program (complexity) dan meningkatkan code readability. Dalam refactoring ini terdapat bed smell yang dapat mengurangi kualitas perangkat lunak. Kode program yang mengandung bed smell tersebut dapat diidentifikasikan dan kemudian dihitung. Complexity diikur dengan cyclomatic complexity. Cyclomatic complexity (Pressman, 2010) merupakan perangkat lunak metric yang menghasilkan ukuran kuantitaf logika kekomplekan suatu program. Cyclomatic complexity (V(G)) dihitung dengan control flow graph dalam program, dimana node (sekelompok peritah dalam program) dan edge (hubungan antar sekelompok perintah dalam program). V(G) = edge – node + 2. Adapun ukuran-ukuran dalam program yang lainnya adalah duplikasi source code, rule-rule tertentu yang ditambahkan secara opsional untuk mengatur kualitas program, komentar dalam API, technical debt, dan lain sebagainya.

3. Analisis Dalam analisis ini, penulis mencoba mengadopsi pemikiran induksi, yaitu penarikan kesimpulan berdasarkan fakta-fakta yang ada. Adapun thapan-tahapan penarikan kesimpulan induksi ini adalah sebagai berikut :

• Perumusan masalah : metode disain dalam software engineering yang tidak samaesuai dengan implementasinya

ISSN 2085-8795

LPPM STMIK IM


36

• Pengajuan hipotesis : model dalam disain perangkat lunak (UML, DFD, ERD, dll) bukan merupakan sebuah disain

• Pengambilan sampel dan Verivikasi : pengukuran kode program (sebagai disain) • Tesis : kode program (disain) dapat terukur dan dapat dilakukan penelitian lebih lanjut sehingga terdapat model yang menghubungkan kode program dengan software scalability

4. Perumusan Permasalahan Berdasarkan teori mengenai pendekatan metodologi yang digunakan dalam pengembangan perangkat lunak maka sebelum melakukan kode harus dilakukan proses disain. Disain perangkat lunak yang dimaksudkan adalah dalam teori-teori yang diajarkan di akademik adalah menghasilkan model artifak sistem perangkat lunak dengan aturan standar tertentu. Model-model artifak tersebut meliputi disain data, disain arsitektur, disain interface, disain komponen, dan disain deployment-level. Bahasa pemodelan yang digunakan bermacam-macam, bahasa pemodelan yang cukup lengkap terdapat pada pengembangan perangkat lunak dengan konsep object oriented yang dikenal sebagai Unified Modelling Language (UML). Pada metodologi tradisional pengembangan perangkat lunak (waterfall, increamental, prototyping, spiral, dll) menyatakan bahwa harus melakukan disain sebelum membuat kode (program). Namun pada kenyataannya disain-disain perangkat lunak yang telah dibuat tidak dapat meramalkan bagaimana perangkat lunak tersebut dibangun secara pasti sebelum dilakukan proses coding. Disain ini belum tentu sama dengan implementasi dalam bahasa pemrogramannya. Selain itu pembuatan artifak-artifak model disain suatu perangkat lunak tersebut merupakan usaha tersendiri dan belum tentu sesuai dengan implementasi programnya.

Gambar 3 Pemodelan Perangkat lunak Pada proses engineering yang lain disain merupakan blueprint dari produk yang dibangun. Dari disain yang ada dapat diperkirakan ketangguhan dari produknya. Pendekatan disain pada ilmu engineering yang lain adalah dengan melibatkan perhitungan matematis dan serangkaian peraturan yang telah teruji, kumudian baru menuangkan dalam gambar-gambar disain. Dari gambar-gambar

ISSN 2085-8795

LPPM STMIK IM


37

disain tersebut dibangunlah suatu produk yang sama persis dengan disain tersebut. Namun dalam software engineering, tidak dapat dilakukan dengan cara yang sama. Untuk saat ini sebuah disain sebuah perangkat lunak tidak dapat dilakukan dengan menggunakan model matematis namun lebih cenderung berdasarkan dari best practice yang telah dilakukan.

4.1. Hipotesis Seorang perangkat lunak disain dapat mendisain sebuah perangkat lunak apabila mereka dapat membayangkan seperti model tersebut apabila dibuat kodenya dan di jalankan dalam mesin (komputer). Seperti yang diungkapkan Vanderberg (2010) yaitu bahwa disain pada perangkat lunak engineering bukanlah gambar-gambar UML, DFD, ERD maupun gambar-gambar yang lainnya. Vanderberk (2010) menyatakan bahwa disain pada perangkat lunak engineering merupakan kode (program) itu sendiri. Sebuah kode dapat dikatakan sebagai blueprint dari sebuah perangkat lunak yang apabila dijalankan oleh mesin akan menghasilkan outpun yang sesuai dengan keinginan user. Fnomena saat ini kode sudah mencapai titik dimana mudah untuk dibaca oleh bukan seorang programmer sekalipun yaitu dengan cara refactoring. Tool refactoring juga sudah tersedia sehingga tidak akan menjadi beban. Selain itu, saat ini code juga mudah untuk diubah sehingga akan lebih adaftif. Gambar-gambar disain seperti UML, ERD, dan lain sebgainya akan cenderung sebagai alat komunikasi dan tidak membebani pengembang. Untuk saat ini teknologi tool dalam perangkat lunak engineering, gambar-gambar disain tersebut sudah dapat digenerate dari kode (program) yang dibangun. Pembuatan kode bukan merupakan pekerjaan tenis dalam arti membangun seperti konsep engineering yang lain. Dalam perangkat lunak pembuatan kode merupakan proses mendisain perangkat lunak. Dalam hal ini penulis mencoba mengubah paradigma baru bahwa kode program merupakan disain dalam perangkat lunak engineering. Konsep disain ini merupakan rancangan dimana jika dieksekusi akan menghasilkan produk yang sesua dengan keunginan pelanggan. Disian juga harus dapat diperkirakan karakteristik dari produknya. Saar ini, untuk memperkirakan karakter-karakter dalam sebuah perangkat lunak harus dilakukan pengetesan. Metode ini digunakan pada konsep engineering sebelum ditemukannya model matematis.

4.2. Pengujian dengan Metode Empiris Berdasarkan perkembangan yang ada saat ini, disain perangkat lunak (program) sangat erat kaitannya dengan testing/ pengujian (empiris) dan belum cukup layak jika didekati dengan model matematis. Pendekatan suatu permasalahan secara empiris ini telah diungkapkan oleh para filosof dari jaman dulu yang terus berkembang sampai saat ini. Untuk saat ini, pendekatan empiris yang sesuai untuk rekayasa perangkat lunak. Pengukuran sebuah perangkat lunak dapat dilakukan dengan metode sebagai berikut :

• • • • • • • •

Big O notation, pengukuran waktu pada algoritma Kohesi, menunjukkan ketertarikan objek dalam satu klas. Complexity, kekomplekan suatu program. Duplikasi sourcencode Violations rule API (Aplication Programming Interface) yang belum dikomentari Smell pada refactoring Technical debt

ISSN 2085-8795

LPPM STMIK IM


38

Gambar 4 Hasil Pengukuran Program (LOC dan Comments) pada sonar Saat ini sudah terdapat peralatan untuk mengukur program dengan menggunakan metode tes-tes tersebut. Konsep pemrograman object oriented merupakan konsep pemrograman yang paling lengkap dengan ketersediaan metode dan tool untuk pengukurannya. Dalam hal ini, penulis mengambil contoh tool “sonar” untuk mengukur klas dan method pada object oriented programming. Sonar merupakan open source quality management platform untuk menganalisis dan mengukur kualitas teknik dari portofolioproyek sampai method pada klas-klas. Error! Reference source not found. dan Error! Reference source not found. merupakan hasil pengukuran dari Apache tomcat program dengan menggunakan sonar. Konsep empiris ini sesuai dengan agile methodology, dimana disain (gambar-gambar UML) merupakan sketsa yang sangat minim. Pada konsep agile, program yang berjalan dengan baik sesuai dengan keinginan pelanggan lebih berguna dari pada program dengan dokumntasi yang lengkap tetapi tidak memuaskan pelanggan.

ISSN 2085-8795

LPPM STMIK IM


39

Gambar 5 Hasil Complexity dan Rule Violations (Sonar)

5. Pengembangan Metode Empiris Dari kajian analisis diatas akan lebih meyakinkan lagi apabila dikaji lebih dalam lagi mengenai hubungan antara kode program dalam hal ini merupakan disain perangkat lunak dengan penggunaan memori dan hardware yang lain. Dengan adanya hubungan tersebut, dapat digunakan untuk memperkirakan kemampuan suatu perangkat lunak apabila dilakukan scale up. Hubungan antara kode program dengan hardware ini akan sangat bergantung pada bahasa dan platform yang digunakan. Menurut penulis jenis bahasa pemrograman dan platform bukannya tak terbatas tapi berbatas jumlahnya. Oleh karena itu visibel dari segi jumlah untuk dilakukan penelitian setiap jenis dan variasinya.

6. Kesimpulan Rekayasa perangkat lunak tidak akan sama dengan engineering dalam bidang keilmuan yang lain, karena perangkat lunak tersebut harus dapat beradaptasi sesuai dengan kebutuhan pelanggan. Perangkat lunak tidak akan mengalami aus tetapi akan selalau diperbaharui sampai deteriorate (memburuk). Oleh karena itu metodologi pengmebangannya berbeda pendekatan dari engineering yang lainnya. Disain sebuah perangkat lunak merupakan kode program itu sendiri tentungan dengan kulaitas yang tinggi sehingga kode dapat dibaca dengan mudah. Konsep disain dalam pengembangan

ISSN 2085-8795

LPPM STMIK IM


40

perangkat lunak yang diajarkan dalam akademik adalah identik dengan model-model yang berupa gambar-gambar disain perangkat lunak yang dilakukan diawal pengembangan tidak menggambarkan program yang dibuat pada akhirnya. Rekayasa perangkat lunak sebaiknya didekati dengan cara empiris. Metode empiris ini adalah dengan melakukan pengetesan pada sebuah kode program sehingga diperoleh parameter-parameter yang merepresentasikan kualitas dari tersebut.

7. References [1] P. Abrahamsson. ITEA homepage on Innovation Report modeling,. 2007. diunduh : ww.itea2.org/project/result/download/result/5583 [2] Beck, Kent; et al. Principles behind the Agile Manifesto. Agile Alliance. 2001. diunduh pada tanggal 13 Desember 2010. [3] Bell, Rob. A Beginer’s Guide to Big O Notation. http://rob-bell.net/2009/06/a-beginnersguide-to-big-o-notation/. 2009. didunduh pada tanggal 13 Desember 2010. [4] CMS, Selecting a Development Approach, Revalidated: 27 Maret 2008. Diunduh pada tanggal 13 Desember 2010. [5] Code refactoring, http://en.wikipedia.org/wiki/Code_refactoring, diunduh pada tanggal 15 Desember 2010. [6] Engineering, http://en.wikipedia.org/wiki/Engineering, diunduh pada tanggal 10 Desember 2010. [7] Engineering. http://www.britannica.com/EBchecked/topic/187549/engineering, diunduh pada tanggal 13 Desember 2010. [8] Pressman Roger, S .Software Engineering (a practitioner’s approach) edisi 7. Mc Graw Hill International. Singapore. 2010 [9] Royce, W.Winston. Managing the Development of Large Software Systems. Proceedings. IEEE Wescon. Agustus 1970. [10] Software Engineering. http://en.wikipedia.org/wiki/Software_engineering. dunduh pada tanggal 13 Desember 2010 [11] Software engineering. http://computingcareers.acm.org/?page_id=12. diunduh pada 13 Desember 2010. [12] Sonar. http://nemo.sonarsource.org/dashboard/index/50544. diunduh pada tanggal 13 Desember 2010.

ISSN 2085-8795

LPPM STMIK IM

PENDEKATAN EMPIRIS DALAM REKAYASA PERANGKAT LUNAK

Recommend Documents