Cheeky Quotes

RPLast

RPL akhirnya selesai juga... detik-detik menjelang akhir semester ini pun semakin terlihat...

RPL adalah salah satu mata pelajaran tetangga ( mirip dengan ASI ) yang sebelumnya saya post, dalam RPL ini ada beberapa ilmu yang saya peroleh, misalnya saja mempermantap erd, flowchart dan dfd. Walaupun diulang-ulang dan mirip dengan ASI, namun ini lumayan membantu untuk mempermantap apa yang kita ketahui. Namun, pada penjelasan materi yang terakhir state transition diagram, itu masihlah hal yang mengambang bagi saya. Membuat state transition diagram masih cukup membingungkan, kadang berpikir terlalu rumit ataupun bingung harus bagaimana menuliskannya dengan benar. Waktu yang sangat singkat juga merupakan kendala dalam membahas materi ini, materi ini belum dibahas secara lebih mendalam namun sangatlah sebentar saja. Selain itu, arsitektur sistem juga masih belum terlalu dipahami, namun ternyata yang kelompok kami buat sudah hampir mendekati benar, hanya salah satu tambahan yang sebenarnya tidak diperlukan (atau tidak ada dalam rancangan awal).

Hanya ini saja yang bisa saya tuliskan, terima kasih Bapak udah mengajar kami di ASI dan RPL, jangan lupa luluskan kami dengan nilai yang bagus ya Pak... ^^ 

Never say goodbye, cause goodbye means forgetting, so see ya...di mata kuliah yang lain...

The Lesson that We Got

Banyak orang yang berkata, setiap dari perpisahan selalu membawa sebuah makna. In every goodbye, there's always the good thing.

Tak terasa waktu bergulir dengan sangat cepat, tugas-tugas pun tak terasa telah dapat dilalui semuanya. Semester yang lumayan penuh dengan kegilaan ini pun tinggal sedikit lagi, lalu kembali akan dilanjutkan ke semester berikutnya yang mungkin juga akan penuh kegilaan lainnya.

Mata kuliah Analisis Sistem Informasi... Dilihat dari namanya, sejak awal saya sudah menduga bahwa pelajaran ini bermain dalam logika berpikir dan bukanlah sekedar hapalan. Tentu saja ini bagus, karena menghapal adalah hal yang berat... Dikarenakan saya lebih bisa membuat suatu pernyataan dalam waktu singkat atau saya sering menyebutnya dalam 3 detik, dibanding dengan harus menghapal titik koma dalam suatu teks. Itu hal yang berat... karena pada akhirnya saya suka mengubah kata-kata yang berada di dalamnya menjadi kata-kata yang lebih mudah untuk saya cerna sendiri.

Nah, kembali ke mata kuliah Analisis Sistem Informasi, selama satu semester ini, saya merasa pola pikir kami semakin dilatih agar dapat berpikir lebih kritis dan lebih luas, bukan hanya memandang hal dari satu sudut, namun juga dari sudut lainnya. Selain itu, kami pun dilatih untuk kembali rajin membaca dan menulis (*membaca dan menulis merupakan penyakit akut bagi sebagian besar pelajar), tentu saja ini merupakan hal yang baik, walaupun pada awalnya juga terasa berat dan agak malas. Namun, itu sudah berhasil dilewati.

Banyak rumor yang beredar bahwa dosen yang mengajar sangatlah ketat dan bahkan tidak boleh bernapas, lalu saya berpikir kalau tidak boleh bernapas, ada baiknya mata kuliah ini jangan diambil dulu, saya harus berlatih menahan napas lebih lama...haha... tapi ternyata kenyataannya berbeda, Pak Sofyan memang tipikal yang ketat namun tetap membiarkan kami bernapas, bila tidak saya tidak mungkin sanggup menulis blog pada akhir semester ini. Selama pelajaran, kami dapat bernapas lega dan saya merasa cara pengajarannya juga bagus, ketat tapi santai. Ketat agar sesuai tujuan, namun santai agar dapat berkreasi dan berkembang.

Pembelajaran kelompok merupakan cara yang bagus, karena memang sebagai manusia kita adalah makhluk sosial yang saling berhubungan dan tergantung satu sama lainnya. Namun walaupun demikian, metode kelompok bila dilakukan terus menerus juga akan menemukan titik jenuh. Selain sebagai makhluk sosial, manusia juga adalah individu, dan setiap individu ingin bebas dan berkembang sendiri. Dalam kelompok, pasti ada yang mayoritas dan minoritas, sadar atau tidak sadar, langsung atau tidak langsung, pembedaan demikian akan terjadi. Akan ada yang pendapatnya akan terasa selalu benar atau akan ada yang mengerjakan lebih dibanding dengan yang lainnya. Metode kelompok memang efektif untuk saling bertukar pikiran, namun ada kalanya titik jenuh itu terasa. Kesabaran dari setiap individu ada batasnya, walaupun harusnya kesabaran itu tidak ada batasnya, namun ya tetap saja ada. Mungkin saja ada yang sudah tidak sabar karena selalu merasa minoritas dan akhirnya mematikan potensi dirinya dan menyerahkannya kepada mayoritas, atau bila dibalik yang mayoritas bisa saja merasa tidak sabar karena yang minoritas selalu nampak seperti ogah-ogahan. 

Walaupun demikian, metode pembelajaran kelompok memang paling efektif, ada satu pembelajaran penting di dalamnya, yaitu kerendahan hati. Terkadang sebagai seorang individu, kita melupakan kerendahan hati, padahal seharusnya kita dapat saling berbagi dan membantu satu sama lain. Ini juga merupakan salah satu pembelajaran berharga yang saya terima.

Seperti kata Pak Sofyan yang berdoa agar bertemu lagi di semester berikutnya, semoga saja, tapi tentu saja di mata kuliah yang beda ya Pak... Luluskan kami dengan nilai yang bagus semua ya Pak... Amin.

People may change like the seasons, but the lesson that we got will never change...

Model Data 002

Model data... pembahasan ini memang telah pernah saya bicarakan sebelumnya... namun kali ini mari melihatnya sekali lagi dengan tambahan persepsi yang baru.

Sebelumnya, mari melihat arsitektur sistem basis data

  • View merupakan output, yaitu hasil-hasil yang diinginkan untuk diperoleh dari sistem basis data tersebut. Jumlah view bisa sebanyak dan semaksimal mungkin tergantung dari seberapa sukses logical level yang telah dibuat.
  • Logical level merupakan tahap pembuatan erd atau pemikiran logical dari sistem yang akan dibuat, meliputi berapa entitas yang dibutuhkan, relasi yang ada, kardinalitas, modalitas serta normalisasi datanya.
  • Physical level merupakan tahap memikirkan dari fisik dari sistemnya, seperti berapa besar memori yang mungkin dibutuhkan
Saat ini, pembelajaran fokus pada logical level yaitu pembuatan ERD nya. Nah, dalam ERD sendiri juga memiliki simbol-simbol tersendiri, ada kardinalitas, modalitas, relasi yang merupakan hubungan antar entitas. Dalam kasus yang diberikan kali ini tentang kasus artis figuran. Dalam kasus ini, artis figuran dibagi menjadi 3 kategori untuk masing-masing honor yang berbeda. Setiap artis figuran juga memiliki scene masing-masing dan bila berhalangan dapat digantikan dengan artis figuran yang lain dalam kategori yang sama.

Pada pembuatan ERD nya, kami terlalu banyak melibatkan entitas dan berpikir terlalu jauh dan rumit dari kasus yang diberikan, padahal yang diminta sangat sederhana yaitu hanya hubungan antara artis figuran, scene dan kategorinya. Hanya 3 entitas yang penting terlibat dalam kasus kali ini. Bila digambarkan :

Setelah sekian lama berjumpa dengan kata ERD, semoga kami semakin mengenal satu sama lain dan makin memahami membuat ERD dengan sebaik mungkin, walaupun kadang jalan berpikir saya suka berbeda, kadang terlalu rumit dan berbeda dari persoalan yang ada, ataupun kadang terlalu sederhana... semoga perlahan-lahan saya semakin bisa memahami model data dengan baik dan sukses dalam tahapan logical level ini (ini adalah dasar dalam pembuatan sistem) sehingga saya nantinya bisa membuat sistem yang bagus.

Wish me luck!




It's not just the sims, it's SIMSE

Game The Sims adalah salah satu game simulasi terlaris di dunia, kali ini yang akan saya bahas bukan mengenai The Sims yang seperti biasa saya post, tapi kali ini SIM SE. Apa itu SIM SE? Ini merupakan game simulator juga, tapi simulator sebagai Software Engineer. Dalam game ini, pemain diajarkan bagaimana metode-metode yang digunakan dalam pengembangan atau pembuatan suatu software. Dalam simulasinya, ada karakter-karakter sebagai pekerjanya, pemain bertugas sebagai manager untuk mengontrol alur permainan agar sesuai dengan metode yang digunakan dan menghasilkan final product untuk customer.

Salah satu metode yang paling menarik untuk saya adalah Prototyping. Mengapa Prototyping? Mungkin karena pada awalnya dikarenakan saya selalu memperoleh nilai 0, sehingga saya penasaran dalam game ini hingga saya terus mencoba dan mencari solusinya.

Contoh hasil yang saya peroleh
Dalam game SIM SE Rapid Prototyping, pemain akan berhadapan dengan customer yang cerewet dan selalu curious akan program yang dia inginkan. Pemain sebagai developer yang baik harus bisa mendengar suara atau permintaan customer. Seperti metode pengembangan prototyping yang saya bahas pada post saya yang sebelumnya, pada simulasi ini, developer akan membuat terlebih dahulu prototype nya dan akan terus mengevaluasi dengan customer hingga customer merasa puas, baru akan dilanjutkan ke tahapan berikutnya.

Nah, pada game SIM SE Rapid Prototyping ini, ada 2 poin yang terpenting yaitu :
Waktu, Customer Satisfaction dan Bahasa Pemograman

  • Waktu. Ketika melakukan simulasi Rapid Prototyping ini, pemain diharapkan dapat bekerja semaksimal mungkin dalam menghemat waktu yang digunakan, karena ketika waktu yang dipakai melebih batas waktu yang diberikan, maka pemain akan mendapatkan nilai 0.
  • Customer Satisfaction. Ketika dalam tahap pembuatan Prototype, yang perlu diperhatikan adalah poin di Customer Satisfaction nya harus mencapai 100, sedangkan di percent discovernya harus dipastikan di atas 80 dan tidak perlu mencapai angka 100.
  • Bahasa Pemograman. Dalam tahapan pembuatan prototype, bahasa pemograman yang dipilih adalah Visual Basic, dikarenakan memiliki waktu tercepat untuk membuat prototype yaitu 2. Sedangkan pada tahapan implementasi, bahasa pemograman yang dipilih adalah Java ataupun C++ yang memiliki kecepatan dan error yang ditimbulkan yang sama, yaitu 1. Jangan memilih Visual Basic untuk implementasi, karena akan berakibat menimbulkan error yang banyak dan akan mengurangi poin.
Dalam simulasi ini, setiap aksi yang dilakukan akan melibatkan semua karyawan, jadi pemilihan karyawan tidak diperlukan (langsung check all saja). Ketika dalam tahapan pembuatan prototype, customer akan banyak untuk curious akan produk yang dibuat dan ataupun memiliki permintaan yang lain, ketika itu terjadi maka pembuatan prototype akan dihentikan, lalu kembali mendengar dari customer 'have customer evaluate prototype'. Setelah prototype selesai dibuat, maka developer akan kembali meminta feed back dari customer dengan kembali 'have customer evaluate prototype' (ingat poin no 2 tentang poin customer satisfaction dan percent discovernya), ketika percent discovernya telah mencapai angka 80 dan customer satisfactionnya telah mencapai 100, maka pemain dapat stop waktunya, dan langsung melanjutkan ke tahapan requirement specification, design dan implement. Ketiga hal tersebut harus diproses hingga mencapai angka 100, baru dikirim final product nya ke customer.

Walaupun sudah mencapai angka demikian, saya masih penasaran untuk menembus angka 100, nampaknya saya harus lebih menghemat dan memperhatikan waktu lagi.

Nah, semoga tips and trick ini dapat membantu kalian supaya tidak dapat 0 terus ya... dan bisa mencapai nilai yang tinggi... Good Luck! Selamat mencoba...

Model Awal

Prototyping... nama yang keren dan mungkin saja pernah didengar oleh telinga kita ketika sedang menonton film tentang robot atau film yang menceritakan dengan latar belakang teknologi. Atau biasa juga kita mendengar istilah prototype di berita ataupun media cetak. Contohya saja mobil prototype. Selain mobil dan robot, ternyata maket rumah juga merupakan prototype loh.
Prototype mobil hemat energi
Sumber : Google
Prototype robot 2005
Sumber : Google














Nah, sebenernya apa itu prototype?

Prototype adalah model awal atau contoh dasar yang lebih sederhana.

Lalu apa itu prototyping? Seperti pada penggunaan bahasa Inggris pada umumnya ketika ditambahkan akhiran -ing maka akan menjadi sebuah pekerjaan, seperti cycle menjadi cycling dari sepeda menjadi bersepeda.

Prototyping adalah suatu metode pengembangan perangkat lunak dengan membuat prototype nya terlebih dahulu sesuai dengan permintaan atau kebutuhan awal dari customer, lalu dari prototype itulah akan dikembangkan lebih lanjut untuk menjadi sistemnya.

Metode ini sangat sesuai untuk mengembangkan perangkat lunak atau sistem yang customer nya belum tahu dengan jelas apa yang diinginkan, ataupun untuk customer yang cerewet. Untuk penjelasan tentang  tahapan dari model proses prototype, yang dari mendengar permintaan atau kebutuhan customer hingga akhirnya jadi sistem, telah saya bahas di artikel saya yang sebelumnya. Di sini hanya berpusat pada tahapan Prototyping nya saja.

Hal terpenting dari prototyping adalah 
visual dan reuse.

Prototype nya dibuat dengan atau hanya dengan memperlihatkan visual kepada customer, agar customer paling tidak dapat melihat seperti apa sistem atau perangkat lunak yang diinginkan. Biasanya untuk pengembangan visualnya, developer akan menggunakan bahasa pemograman visual. Salah satu bahasa pemograman visual yang paling dikenal adalan VB atau Visual Basic karena sangat mudah untuk mengatur tampilannya. Selain daripada tampilan atau visualnya, masalah reuse juga penting. Prototype yang dibuat, harus bisa direuse, baik untuk pengembangan sistem selanjutnya ataupun untuk digunakan kemudian untuk customer yang berbeda namun memiliki kasus yang hampir sama.

Prototype yang dibuat terbagi 2 jenis yaitu :
  • Close-ended atau throw-away prototype (Prototype yang terbuang) artinya prototype tersebut hanya digunakan untuk menghasilkan informasi dan spesifikasi apa yang dibutuhkan untuk pengembangan sistemnya.
  • Open-ended atau evolutionary prototype (Prototype tak terbuang atau Prototype yang berkembang) artinya prototype nya akan menjadi tahapan awal dalam pembuatan sistemnya.
Sebenarnya masih ada suatu kebingungan dalam otak saya, walupun prototyping sangat cocok untuk metode pembuatan perangkat lunak bagi customer yang cerewet, namun dulu saya pernah mendengar bahwa lebih baik menghindari menggunakan metode prototyping ketika sedang membuatkan sistem basis data untuk customer yang cerewet. Mengapa? Karena sistemnya tidak akan selesai-selesai dan memakan waktu yang lama. Bila menggunakan metode prototyping untuk membuat sistem basis data bagi suatu perusahaan, sebaiknya memiliki kesepakatan awal dalam hal jangka waktu dan biaya pembuatan sistem hingga tahapan mana untuk mengurangi kerugian dari developer. Lalu bagaimana? Tetap menggunakan prototyping? Contoh kasus seperti apakah yang sesuai?

Lebih lanjut saya akan mendalami dan mencari tahu lebih lanjut tentang prototyping dan sebenarnya kasus seperti apa yang sesuai untuk metode ini.



P.S. Ingat ya, prototype itu contoh dasar. Siapa tahu nanti dengar atau nonton film tentang teknologi atau robot lagi...

Model Data

Model data ialah sekumpulan konsep-konsep yang menggambarkan data, hubungan antar data, batasan-batasan data yang terintegrasi satu dengan yang lainnya.

Sumber : Google
Salah satu model data yang biasa digunakan adalah ERD atau Entity Relationship Diagram. Model ERD ini berpusat pada entitas dan relasi antar entitasnya. Entitas disimbolkan dengan persegi panjang, relasi disimbolkan dengan belah ketupat dan atribut disimbolkan dengan oval.

Dalam hubungan antar entitas, keduanya terkait dengan kardinalitas dan modalitasnya. Kardinalitas seperti hubungan antara entitas itu dengan entitas lainnya berkaitan dengan tiap data yang menyangkut di dalamnya. Kardinalitas seperti one to one, one to many dan many to many.

One to one yaitu hubungan satu ke satu, sedangkan one to many yaitu hubungan satu ke banyak. Many to many yaitu hubungan banyak ke banyak. Secara gampang, hal ini dapat dilihat dengan melihat himpunan yang berada pada pelajaran matematika SD atau SMP :
Sumber : Google
Nah, selain masalah kardinalitas, modalitasnya juga penting. Apakah data tersebut semuanya pasti berpasangan dengan data pada entitas lain pada relasi tersebut. Modalitas disimbolkan dengan | dan O. Penjelasan sederhananya, | menyatakan bahwa entitas yang didekatnya tiap datanya harus berpasangan dengan data pada entitas yang satunya. Sedangkan O menyatakan bahwa tidak semua data pada entitas di dekatnya harus berpasangan dengan entitas yang satunya. Contohnya :

Sumber : Google

Hal yang masih membingungkan adalah bagaimana dengan relasi satu ke banyak, pada relasinya bila terdapat atribut dan dijadikan tabel, atribut kunci dari entitas mana yang harus dilibatkan. Bagaimana menyatakan hubungan antara entitas bila terjadi kemungkinan, adakah simbol decision untuk kasus ERD, misalnya saja kasus rumah sakit, bila pasien rawat inap maka dia akan berhubungan dengan entitas kamar, namun bila dokter menyatakan pasien bisa rawat jalan, maka dia akan berhubungan dengan treatment saja. Apakah semuanya langsung dihubungkan atau memerlukan decision?

Lebih dalam lagi, saya ingin mengetahui bagaimana penerapan ERD dalam kasus sehari-hari secara jelas, dikarenakan selama ini kami mempelajari ERD dengan metode learn by mistake. Pola pikir mengenai model data masih harus ditingkatkan lagi.