Pada PERTEMUAN 14 MATA KULIAH SISTEM KOMPUTER BAGIAN 6 akan dibahas materi SEJARAH PC
Hari: 9 Oktober 2019
Pada PERTEMUAN 15 MATA KULIAH SISTEM KOMPUTER BAGIAN 7 akan dibahas materi PROSESSOR
PadaPERTEMUAN 16 MATA KULIAH SISTEM KOMPUTER BAGIAN 8 akan dibahas materi ASSEMBLY
Pada PERTEMUAN 13 MATA KULIAH SISTEM KOMPUTER BAGIAN 5 akan dibahas materi FLOATING POINT
Pada PERTEMUAN 12 MATA KULIAH SISTEM KOMPUTER BAGIAN 4 akan dibahas materi ALU
Pada PERTEMUAN 11 MATA KULIAH SISTEM KOMPUTER BAGIAN 3 akan dibahas materi RANGKAIAN KOMBINASI SEQUENSIAL
Pada PERTEMUAN 10 MATA KULIAH SISTEM KOMPUTER BAGIAN 2 akan dibahas materi SISTEM BILANGAN SANDI BINER GERBANG
Pada PERTEMUAN 8 MATA KULIAH PERMODELAN PERANGKAT LUNAK BAGIAN 8 membahas tentang ” Component-based Development Model”
Component-based Development Model
Component-based development sangat berkaitan dengan teknologi berorientasi objek. Pada pemrograman berorientasi objek, banyak class yang dibangun dan menjadi komponen dalam suatu software. Class-class tersebut bersifat reusable artinya bisa digunakan kembali. Model ini bersifat iteratif atau berulang-ulang prosesnya.
Secara umum proses yang terjadi dalam model ini adalah:
Identifikasi class-class yang akan digunakan kembali dengan menguji class tersebut dengan data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang baru
Class yang dibuat pada proyek sebelumnya disimpan dalam class library, sehingga bisa langsung diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class baru, maka class baru dibuat dengan metode berorientasi objek.
Bangun software dengan class-class yang sudah ditentukan atau class baru yang dibuat, integrasikan.
Pembangunan software dengan menggunakan komponen yang sudah tersedia dapat menggunakan komponen COTS (Commercial off-the-shelf) – yang bisa didapatkan dengan membeli atau komponen yang sudah dibangun sebelumnya secara internal. Component-Based Software Engineering (CBSE) adalah proses yang menekankan perancangan dan pembangunan software dengan menggunakan komponen software yang sudah ada.
Pada PERTEMUAN 6 MATA KULIAH PERMODELAN PERANGKAT LUNAK BAGIAN 6 membahas tentang ” Berapa biaya Rekayasa Perangkat Lunak? ” dan “Apa saja metode-metode RPL? “
Berapa biaya Rekayasa Perangkat Lunak?
Biaya untuk rekayasa perangkat lunak bervariasi tergantung pada jenis sistem yang akan dibuat ,atribut perangkat serta kinerja dan kehandalan perangkat yang akan dibuat, contohnya saja sistem yang berskala internasional tentunya memerlukan biaya yang lebih mahal apabila dibandingkan dengan sistem yang berskala nasional. Tabel dibawah ini menjelaskan perkiraan pengeluaran rekayasa perangkat lunak

Apa saja metode-metode RPL?
Metode-metode dalam rekayasa perangkat lunak merupakan cara yang dilakukan untuk mengembangkan perangkat lunak yang meliputi deskripsi model sistem, aturan, rekomendasi, panduan proses, dan bimbingan. Deskripsi model sistem merupakan model sistem yang akan digunakan contohnya model waterfall. Aturan merupakan batasan yang diberikan kepada model sistem yang telah ditentukan, misalnya setiap entitas pada model sistem diharuskan memiliki nama entitas yang berbeda antara satu entitas dengan entitas lainnya. Rekomendasi berupa saran yang diberikan agar dapat membentuk perancangan yang baik dan sesuai fungsinya. Panduan proses merupakan aktifitas yang bisa diikuti untuk mengembangkan model sistem. Proses bimbingan yaitu serangkaian kegiatan yang akan diikutin untuk mengembangkan model sistem.
Pada PERTEMUAN 5 MATA KULIAH PERMODELAN PERANGKAT LUNAK BAGIAN 5 akan membahas sambungan materi ” Apakah model proses perangkat lunak?”
Model Prototype
Prototype merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem. Prototyping, dimulai dengan pengumpulan kebutuhan, mendefinisikan objektif keseluruhan dari software, mengidentifikasikan segala kebutuhan, kemudian dilakukan “perangcangan kilat” yang difokuskan pada penyajian aspek yang diperlukan.

Kelebihan :
- Prototype melibatkan user dalam analisa dan desain.
- Punya kemampuan menangkap requirement secara konkret daripada secara abstrak.
- Untuk digunakan secara standalone.
- Digunakan untuk memperluas SDLC.
- Mempersingkat waktu pengembangan Sistem Informasi
Kekurangan :
- Proses analisis dan perancangan terlalu singkat.
- Mengesampingkan alternatif pemecahan masalah.
- Bisanya kurang fleksible dalam mengahdapi perubahan.
- Prototype yang dihasilkan tidak selamanya mudah dirubah
Contoh Studi Kasus :
Dalam pelaksanaannya, system akademik yang berjalan di Sekolah Menengah Pertama Negeri 20 Bandung dirasa belum optimal, hal ini dikarenakan sistem yang digunakan masih bersifat manual. Dengan permasalahan tersebutmaka muncul berbagai permasalahan terutama pada proses pendaftaran,registrasi, pembagian kelas, pembagian wali kelas, proses penilaian serta informasimengenai perkembangan siswa kepada orang tua. Untuk itu, diperlukan suatu sistem informasi yang mampu mendukung pengambilan keputusan dalammemperoleh informasi kegiatan akademik. Pembuatan Sistem Informasi Akademik Sekolah Menengah Pertama Negeri 20 Bandung menggunakan pendekatan terstruktur, sedangkan metode pengembangan menggunakan prototype dengan teknik pengumpulan data observasidan wawancara, sedangkan alat yang digunakan dalam merancang sistem berupa Flow Map, Diagram Konteks, DFD dan pengembangan aplikasi berbasis desktop.Sistem yang dibangun disajikan secara client server sehingga dapat diaksesbeberapa komputer. Sistem yang dibangun diharapkan dapat mengatasi sebagianbesar permasalahan yang ada seperti melakukan validasi kerangkapan dataregistrasi dan nilai siswa, pembagian kelas dan penilaian.
Model V / V-Model.
Bisa dikatakan model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.
Kelebihan v model :
- V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dantool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.
- V Model dikembangkan dan di-maintain oleh publik. Userdari V Model berpartisipasi dalam change control boardyang memproses semua change request terhadap V Model.
Kekurangan v model :
- V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
- V Model terlalu fleksibel dalam arti ada beberapa activitydalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalamactivity tersebut dan apa yang tidak.
Model Rapid Application Development (RAD)
Rapid Aplication Development (RAD) adalah sebuah model proses perkembanganperangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek (kira-kira 60 sampai 90 hari). Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen.

Kelebihan Model RAD :
- Lebih efektif dari Pengembangan Model waterfall/sequential linear dalam menghasilkan sistem yang memenuhi kebutuhan langsung dari pelanggan.
- Cocok untuk proyek yang memerlukan waktu yang singkat.
- Model RAD mengikuti tahap pengembangan sistem seperti pada umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang ada sehingga pengembang tidak perlu membuatnya dari awal lagi sehingga waktu pengembangan menjadi lebih singkat dan efisien.
Kekurangan Model RAD :
- Model RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.
- Tidak semua aplikasi sesuai untuk RAD, bila system tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat bermasalah.
- RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang tinggi.
- Membutuhkan Tenaga kerja yang banyak untuk menyelesaikan sebuah proyek dalam skala besar.
- Jika ada perubahan di tengah-tengah pengerjaan maka harus membuat kontrak baru antara pengembang dan pelanggan.
