ASI BARU

Anlisa/Solusi menurut saya:

*Pada Bagian Administrasi dan Keuangan memproses Formulir Registrasi & Slip/Kwitansi Pembayaran dilakukan secara Komputerisasi kemudian menyimpan datanya ke dalam sebuah Database ( Data Siswa).

*Di Asi Lama terdapat bagian hasil berupa output berupa 3 buah laporan , sedangkan pada ASI Baru Untuk Laporan Pembayaran Pendaftaran dan Laporan Pembayaran Bimbingan Digabung , Sehingga pada ASI Baru cukup hanya dengan menggunakan 2 buah Laporan saja yaitu :
1.Laporan Data Siswa.
2. Laporan Pembayaran Pendaftaran & Bimbingan Siswa .

*Pada Proses Pengolahan Data yang dilakukan secara proses Komputerisasi , sehingga pada Proses pembuatan Rapor Siswa terasa lebih cepat dibandingkan dengan proses manual di ASI Lama.

MATERI KONSEP DAN PRINSIP ANALISIS

KONSEP DAN PRINSIP ANALISIS PERANGKAT LUNAK


Tugas analisis persyaratan merupakan sebuah proses penemuan, perbaikan, pemodelan, dan spesifikasi. Ruang lingkup perangkat lunak, yang secara mendasar dikembangkan oleh perekayasa sistem dan diperbaiki selama perancanaan proyek perangkat lunak, diperbaki secara detail. Model-model data yang dibutuhkan, aliran kontrol dan informasi,
dan tingkah laku operasional diciptakan. Pemecahan alternatif dianalisis dan dialokasikan
ke berbagai elemen perangkat lunak. Baik pengembang maupun pelanggan melakukan peran aktif dalam analisis persyaratan dan spesifikasi. Pelangga berusaha memformulasikan kembali konsep yang tidak jelas dari fungsi perangkat lunak dan kinerja ke dalam detail yang konkrit. Pengembang bertindak sebagai interogator, konsultan, dan pemecah masalah.

ANALISIS PERSYARATAN

Merupakan sebuah tugas sebuah rekayasa perangkat lunak (RPL) yang menjembatani antara alokasi perangkat lunak dan perancangan perangkat lunak. Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface dan elemen-elemen di dalamnya, dan membangun batasan yang harus dipenuhi oleh perangkat lunak. Analisis persyaratan memberikan model-model yang akan diterjemahkan ke dalam data, arsitektur, interface, dan desain prosedural kepada perancang perangkat lunak. Akhirnya, spesifikasi persyaratan memberikan cara kepada pengembang dan pelanggan untuk menilai kualitas perangkat lunak yang telah dibangun. Pada awalnya, analis mempelajari spesifikasi sistem (bila ada) dan rencana proyek perangkat lunak. Penting untuk memahami perangkat lunak dalam suatu konteks sistem dan mengkaji ruang lingkup perangkat lunak yang telah digunakan untuk memunculkan estimasi perencanaan. Selanjutnya adalah membangun komunikasi untuk analisis untuk menjamin pengenalan masalah. Tujuannya adalah mengenali elemen masalah dasar seperti dirasakan oleh pelanggan.

1. TEKNIK KOMUNIKASI

Mengawali Proses
Menurut Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan.
Contoh:
• Siapa di balik permintaan untuk pekerjaan ini?
• Apa keuntungan ekonomi dari pemecahan yang berhasil?
• Rangkaian pertanyaan berikutnya memungkinakan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.


Contoh:
• Masalah apakah yang akan diselesaikan oleh pemecahan ini?
• Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan?
Rangkaian pertanyaan berikutnya berfokus pada efektifitas pertemuan. [GAU89] memberikan contohnya sebagai berikut:
• Apakah ada orang lain yang dapat memberikan informasi tambahan?
• Apakah ada hal lain yang harus saya tanyakan kepada anda?
Pertanayan-pertanyaan tersebut akan membantu anda mengawali komunikasi yang perlu untuk berhasilnya analisis. Pada dasarnya sesi tanya jawab seharusnya digunakan pada pertemuan pertama dan kemudian diganti dengan format yang mengkombinasikan lemen-elemen pemecahan masalah, negosiasi, dan spesifikasi.

Teknik Spesifikasi Aplikasi yang Terfasilitasi
Adanya teknik pendekatan spesifikasi aplikasi yang teratasi / facilitated aplication spesification techniques (FAST) dapat mendorong munculnya tim gabungan antara pengembang dan pelanggan yang bekerjasama untuk mengidentifikasimasalah, mengusulkan elemen pemecahan, menegosiasi pendekatan yang berbeda, dan mengkhususkan rangkaian pemecahan awal [ZAH90].Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing-masing pendekatan menggunakan skenario yang sangat berbeda, tetapi semuanya menerapkan beberapa variasi tuntutan dasar seperti: Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan. Aturan main untuk persiapan dan partisipasi dibuat.
Sebuah mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju konkrit ke arah pengembangan spesifikasi.

Penyebaran Fungsi Kualitas
Disebut juga Quality function deployment (QFD) adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak.
QFD mengidentifikasi 3 persyaratan [ZUL92] yaitu:
• Persyaratan normal:
• Sasaran dan
• tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan.
Bila persyaratan ini ada, maka pelanggan akan menjadi puas.
Conoth: tipe tampilan grafis yang diminta, dan tingkat kerja yang didefinisikan. Persyaratan yang diharapkan: Persyaratan ini implisit terhadap produk atau
sistem dan sangat fundamental sehingga pelanggan tidak menyatakannya
secara eksplisit. Ketidakhadirannya menyebabkan ketidakpuasan. Contoh:
Mudahnya instalasi perangkat lunak.
Exciting requirment: Persyaratan ini sangat diharapkan oleh pelanggan dan
terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata
diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah
kemampuan layout halaman yang sangat menyenangkan dan tidak terduga.
Dalam kenyataan, QFD mencakup seluruh proses rekayasa [AKA90]. Tetapi
banyak konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan
yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis
persyaratan.

2. PRINSIP-PRINSIP ANALISIS
Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:
1. Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
4. Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
5. Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
6. Berusaha mengurangi ambiguitas.
Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah secarasistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami secara lebih lengkap. Model-model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandangan esensial dan implementasi dari perangkat lunak diperlukan untuk
mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan
fisik yang dibebankan oleh elemen sistem yang lain. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.
- Domain Informasi
- Pemodelan
Model dalam perangkat lunak harus dapat memodelkan informasi yang ditransformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku sistem pada saat transformasi terjadi.
Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku sistem, dan karakteristik lain sebagai simbol yang berbeda dan dapat dikenali. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.
Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu:
Model fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan diri pada fungsi-fungsi masalah khusus. Model fungsi dimulai dengan sebuah model
tingkat konteks tunggal (yakni nama perangkat lunak yang akan dibuat).
Dengan serangkaian iterasi, maka lebih banyak lagi detail fungsional
diberikan, sampai seluruh rancangan dari semua fungsionalitas sistem
terwakili.
Model tingkah laku: Sebagian besar perangkat lunak merespon kejadiankejadian
dari dunia luar. Karakteristik stimulus-respon ini membentuk
dasar dari model tingkah laku. Model tingkah laku menciptakan
representasi pernyataan-pernyataan perangkat lunak dan event-event yang
menyebabkan perangkat lunak mengubah pernyataan.
Model yang diciptakan selama analisis persyaratan melayani sejumlah peran
penting:
- Model membantu analis dalam memahami informasi, fungsi, dan tingkah
laku suatu sistem, sehingga membuat tugas analisis persyaratan menjadi
lebih mudah dan lebih sistematis.
- Model menjadi titik fokus bagi kajian sehingga merupakan kunci bagi
penentuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.
- Model menjadi dasar bagi pengerjaan desain, memberi perancang suatu
representasi esensial dari perangkat lunak yang dapat diterjemahkan ke
dalam suatu konteks implementasi.
Meskipun metode pemodelan yang digunakan sering menjadi masalah preferensi
personal atau organisasional, aktivitas pemodelan adalah dasar bagi kerja analisis
yang baik.
- Pembagian
Masalah sering menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai satu
kesatuan. Karena itulah kita cenderung membagi masalah seperti itu ke dalam
bagian-bagian sehingga dapat dipahami dengan mudah dan kemudian
membangun interface antara bagian-bagian tersebut, sehingga keseluruhan fungsi
dapat dilakukan. Prinsip analisis operasi keempat menyatakan bahwa domain
informasi, fungsional, dan tingkah laku perangkat lunak dapat dibagi-bagi.
Secara mendasar pembagian mendekomposisi suatu masalah ke dalam bagian
konstituennya. Secara konseptual, kita membangun sebuah representasi hirarki
dari informasi atau fungsi dan kemudian membagi elemen bagian paling atas
dengan (1)mengekspos detail pertambahan dengan bergerak secara vertikal dalam
hirarki, (2)mendekomposisi masalah dengan bergerak secara horisontal dalam
hirarki.
Contoh: system keamanan safehome
- Pandangan esensial dan implementasi
Pandangan esensial persyaratan perangkat lunak menyajikan fungsi yang akan
dikerjakan dan dan di informasikan yg akan diproses tanpa melihat detail
implementasinya.
Contoh: Pandangan esensial dari fungsi safehome read sensor status
Tidak tergantung dari bentuk fisik dari data atau type sensor yang
Di gunakan.
Pandangan implementasi persyaratan perangkat lunak menyajikan manifestasi
dunia nyata dari pemrosessan fungsi-fungsi dan struktur informasi.
Contoh: Input safehome dimana perangkat/ element (sensor)
menggunakan pertimbangan pandangan implementasi.
3. Prototyping perangkat
Analisis harus dilakukan tanpa mengabaikan paradigma rekayasa PL yg di
aplikasikan ; tetapi bentuk yg diambil oleh analisis akan bermacam- macam.
Dalam banyak kasus sangat mungkin untuk mengaplikasikan prinsip operasional
dan menarik sebuah model PL yang melaluinya sebuah desain dapat
dikembangkan,pengaplikasian prinsip analisis dan penyusunan model perangkat
lunak yg akn dibangun yang disebut prototype untuk penilaian pelanggan dan
pengembang.
~ Pemilihan prototyping
Paradigma prototyping terbatas dan tidak terbatas. Pendekatan terbatas
sering disebut: throw away prototyping. Dengan menggunakn pendekatan
tersebut, prototyping sebagai sebuah demonstrasi kasar dari sebuah
persyaratan.Kemudian prototype dikesampingkan dan perangkat lunak
direkayasa dgn menggunakan suatu paradigma yang berbeda.Pendekatan
tidak terabatas sering disebut evolusionary prototyping,menggunakan
prototyping sebagai bagian utama dari aktivitas analisis yang akan
diteruskan ke dalam desain dan konstruksi.
Sebelum perangkat terbatas atau tidak terbatas dipilih, perlu ditentukan
apakah system yang akan dibangun dapat menerima prototyping atau
tidak.Sejumlah factor calon prototiyping[BOA84] dapat ditentukan: area
aplikasi, kompleksitas aplikasi, krakteristik pelanggan, dan karakteristik
proyek.
~ metode dan Peranti Prototyping
Agar prototyping perangkat lunak efektif,maka harus dikembangkan
suatu prototype dengan cepat sehingga pelanggan dengan dapat menilai
hasil dan perubahan yang di rekomendasikan. Untuk melakukan
prototyping dengan tepat ad tiga kelas metode dan peranti generik missal:
(AND 92,TAN 92): teknik generasi keempat komponen perangkat lunak
reusable,spesifikasi normal,dn lingkungan prototyping.

3. Spesifikasi
Metode spesifikasi sama dengan pemecahan masalah. Pereka PL yang dipaksa
bekerja dengan spesifikasiyang tidak lengkap,tidak konsisten,atau salah akan
mengalami frustasi atau keraguan.akibatnya, kualitas ,ketepatan waktu dan
kelengkapan perangkat lunak menjadi korban.
~ Prinsip spesifikasi
Spesifikasi, tanpa mempedulikan mode dimana kita melakukannya, dapat
dilihat sebagai sebuah proses representasi. Persyaratan diwakilkan dengan suatu
cara yg membawa ke arah implementasi yang berhasil. Berikut ini sejumlah
prinsip spesifikasi yang diadaptasi dari kerja Blazer dan Goldman[BLA 86].
1.Memisahkan fungsional dari implementasi
2. Mengembangkan suatu model dari system yang diperlukan yg meliputi
data dan respon fungsional dari suatu system terhadap berbagai stimulus
dari lingkungan.
3.Membangun konteks dimana PL beroperasi dengan menentukan cara
dimana komponen system yg lain berinteraksi dengan PL.
4.Menentukan lingkungan dimana system beroperasi dan menunjukan
bagaimana “ sekumpulan agen yang sangat terjalin bereaksi terhadap
stimulus dalam lingkungan.
5.Menciptakan sebuah model yg kognitif daripada model desain atau
implementasi.Model kognitif menggambarkan sebuah system
sebagaimana dirasakan oleh komunitas pemakainya.
6.mengenali spesifikasi harus toleran terhadap ketidak lengkapan dan
dapat di tambah.
7.Membangun muatan dan struktur spesifikasi dengan suatu cara yang
akan memungkinkan spesifikasi dapat ditambah agar dapat berubah.
~ Representasi
Kita mengetahui bahwa persyaratan PL dapat ditentukan dalam berbagai cara.
Akan tetapi, bila persyaratan itu dimasukan pada kertas atau media presentasi
electronic, maka diperoleh panduan sederhana:
-Format dan muatan representasi harus relevan dengan masalah.
-Informasi yang di isikan kedalm spesifikasi harus disarangkan.
~ Spesifikasi persyaratan PL
Spesifikasi persyaratan PL dibuat pada puncak tugas analisis. Fungsi dan kinerja
yang dialokasikan pada PL sebagai bagian dari rekayasa system, diperhalus
dengan membangun sebuah diskripsi informasi lengkap,diskripsi tingkah laku dan
fungsional lengkap,indikasi persyaaratan kinerja dan batasan desain, criteria
validasi yang sesuai, dan data lain yang berkenaan dengan persyaratan. The
Nation Bureau of Standards, IEE( standard no. 830- 1984) dan Departement
Pertahanan AS mengusulkan format calon untuk spesifikasi persyaratan
perangkatan perangkat lunak. Berikut merupakan kerangka kerj untuk spesifikasi.
a.Pendahuluan
-Refrensi system
-Deskripsi keseluruhan
-Batasan proyek PL
b.Deskripsi informsi
-Representasi isi informasi
-Representasi aliran informasi
- aliran data
- aliran kontrol
c.Deskripsi fungsional
-Pembagian fungsional
-deskripsi fungsional
- gambaran pemrosesan
- retriksi / keterbatasan
- persyaratan kinerja
- batasan desain
- diagram pendukung
- diskripsi control
- spesifikasi control
- batasan desain
d.Diskripsi prilaku
- peryataan system
- event dan tindakan
e.Validasi dan kreteria
-batas kinerja
- kelas- kelas pengujian
- respon PL
- pertimbangan khusus
f.Bibliografi
g.Lampiran
~ Kajian spesifikasi
Kajian dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh
pelanggan atau pengembang PL. Karena spesifikasi membentuk dasar bagi
desain dan aktivitas rekayasa selanjutnya, maka kajian harus dilakukan dengan
hati- hati.
Kajian dilakukan pertama kali pada tingkat makroskopik.pada tingkat ini pengkaji
akan memastikan bahwa spesifikasi sudah lengkap, konsisten, dan, akurat.
Pertanyaan - pertayan berikut dapat di ajukn:
Apakah tujun dan sasaran yang diyatakan bagi perangkat lunak
tetap konsisten dengan tujuan dan sasaran system?
Apakah interface penting kesemua element system sudah
digambarkan?
Apakah aliran informasi dan struktur didefinisikan dengan tepat
bagi domain masalah
Apakah diagram jelas?apakah masing masing dapat berdiri sendiri
tanpa teks pendamping
Apakah fungsi mayor tetap ada pada ruang lingkup, dan sudah
digambarkan dengan lengkap dn tepat?
Apakah tingkah laku PL konsisten dengan informasi yang harus
diproses dan fungsi harus dilakukannya?
Apakah batasan desain realistis?
Apakah resiko teknologis pengembang sudah dipertimbangkan?
Apakah criteria validasi dinyatakan secara detail?apakah criteria
tersebut kuat untuk menggambarkan sebuah system yang berhasil.
Apakah ada inkonsistensi,penghilangan?
Apakah kontak dengan pelanggan sudah lengkap?
Apakah pemakai sudah mengkaji manual pemakai pemulaan atau
prototype?
Bagaimana estimasi perencanaan mempengaruhi
Pengkaji dapat mengembangkan pertayaan diatas dengan :
Mencari konektor persuasive
Bila suatu daftar yang diberikan tidak lengkap,pastikan jenisnya
sudah dipahami.
Pastikan jangkauan yg dinyatakan tidak berisi asumsi yg tidak
dinyatakan.
Hti hatilah pada kata kerja yang kabur
Hati hati terhadap kata ganti yang ambiguitas
Cari pertanyaan yang mengimplimentasikan kepastian
Bila kajian lengkap spesifikasi persyaratan PL diakhiri oleh pelanggan atau
pengembang. Perubahan yang diminta setelah spesifikasi itu di akhiri tidak akan
dieleminasi, tetapi pelanggan harus mencata bahwa masing – masing perubahan setelah
pengakhiran spesifikasi merupakan ekstensi dari ruang lingkup PL yang demikian dapt
menambah biay dan atau dapat memperpanjang jadwal proyek.Bahkan dengan prosedur
kajian terbaikpun, tetap ada sejumlah masalah spesifikasi. Spesifikasi sulit di uji dalam
berbagai cara yang berarti sehingga inkonsistensi dn penghilangan dapat berlangsung
tanpa terlihat.Selama kajian , perubahan terhadap terhadap spesifikasi dapat
disetujui.Sangat sulit untuk menili pengaruh global dari suatu perubahan ; yaitu
bagaimana suatu perubahan dalam suatu fungsi mempengaruhi persyaratan bagi fungsi-
fungsi yang lain.
Rangkuman
Analisis persyaratan adalah langkah teknis pertama pada proses rekayasa perangkat
lunak. Di sini pernyataan umum mengenai ruang lingkup perangkat lunak disaring ke
dalam sebuah spesifikasi konkrit yang menjadi dasar bagi aktivitas rekayasa perangkat
lunak yang mengikutinya.
Analisis harus berfokus pada domain informasi, fungsional, dan tingkah laku dari
masalah. Untuk lebih memahami apa yang dibutuhkan, maka dibuatlah sebuah model;
masalah dibagi-bagi, dan representasi yang menggambarkan esensi persyaratan, dan
kemudian detail implementasi dikembangkan.
Dalam beberapa kasus tidaklah mungkin untuk secara lengkap menspesifikasi suatu
masalah pada tahap awal. Prototyping menawarkan sebuah pendekatan alternatif yang
menghasilkan sebuah model perangkat lunak yang dapat dieksekusi yang dari sana
persyaratan disaring. Dibutuhkan peranti dan teknik khusus untuk melakukan prototyping
secara tepat.
Spesifikasi persyaratan perangkat lunak dikembangkan sebagai akibat dari analisis.
Kajian penting untuk memastikan bahwa pengembang dan pelanggan memiliki persepsi
yang sama mengenai sistem. Sayangnya, bahkan dengan metode yang terbaik sekalipun,
masalahnya adalah bahwa masalah tersebut terus berubah.

Use Case

Use Case Diagram
Pengertian :
● Use case class digunakan untuk memodelkan dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (or bagian sistem: subsistem atau class) ke pemakai.
● Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem.
● Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.
Karakteristik :
 Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.
 Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor.
 Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan.
 Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal.
Komponen Pembentuk Use Case Diagram :
1. Actor
Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man . Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship

Gambar Actor
2. Use Case
Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.
Cara menentukan Use Case dalam suatu sistem:
a. Pola perilaku perangkat lunak aplikasi.
b. Gambaran tugas dari sebuah actor.
c. Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor.
d. Apa yang dikerjakan oleh suatu perangkat lunak (*bukan bagaimana cara mengerjakannya).

Gambar Use Case
Relasi dalam Use Case
Ada beberapa relasi yang terdapat pada use case diagram:
1. Association, menghubungkan link antar element.
2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.
3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.
4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.
Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram:
1. <> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.
2. <>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.
3. <>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.
3. Contoh Use Case Diagram

Contoh Use Case Diagram




Cara Penggambaran Diagram Use Case
Diagram Use Case adalah diagram yang menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar dan menjelaskan sistem secara fungsional yang terlihat user. Biasanya dibuat pada awal pengembangan. Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.
Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan system untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.
Use case diagram adalah gambaran graphical dari beberapa atau semua actor, use case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar.
Use case diagram dapat digunakan selama proses analisis untuk menangkap requirements sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use case diagram. Kebutuhan atau requirements sistem adalah fungsionalitas apa yang harus disediakan oleh sistem kemudian didokumentasikan pada model use case yang menggambarkan fungsi sistem yang diharapkan (use case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use case (use case diagram) itu sendiri.
Notasi Gambar Yang Diapakai Use Case
1. Actor
Seorang / sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

2. Case
Menggambarkan deskripsi yang melibatkan actor.

Contoh Case - Actor:

3. Extend
Relasi yang digunakan jika use case yang satu mirip dengan use case yang lain.
4. Include
Relasi jika terdapat perilaku yang mirip dengan beberapa use case.
Cara Menemukan Use Case
• Pola perilaku perangkat lunak aplikasi.
• Gambaran tugas dari sebuah actor.
• Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor.
• Apa yang dikerjakan oleh suatu perangkat lunak (bukan bagaimana cara mengerjakannya).
Komponen Pembentuk Use Case
Actor
Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man. Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship.
Contoh:
Ada beberapa kemungkinan yang menyebabkan actor tersebut terkait dengan sistem, antara lain:
• Yang berkepentingan terhadap sistem dimana adanya arus informasi, baik yang diterimanya maupun yang dia inputkan ke sistem.
• Orang ataupun pihak yang akan mengelola sistem tersebut.
• External resource yang digunakan oleh sistem.
• Sistem lain yang berinteraksi dengan sistem yang akan dibuat.
Use Case
Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.
Cara menentukan Use Case dalam suatu sistem:
• Pola perilaku peringkat lunak aplikasi
• Gambaran tugas dari sebuah actor
• Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor
• Apa yang dikerjakan oleh suatu perangkat lunak (bukan bagaimana cara mengerjakannya)
Relasi dalam Use Case
Ada beberapa relasi yang terdapat pada use case diagram:
1. Association, menghubungkan link antar element.
2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.
3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.
4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.
Tipe relasi / stereotype yang mungkin terjadi pada Use Case diagram:
1. <>, yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.
2. <>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.
3. <>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.
Contoh Use Case Diagram

Use Case Specification
• Nama
• Deskripsi Singkat
• Aliran event (flow of event)
• Relationship
• Activity Diagram
• Kebutuhan khusus (special requirement)
• Pre-Condition
• Post-Condition








Aliran Event Use Case
• Memiliki sebuah flow normal dan dasar
• Beberapa flow alternatif
o Regular variant
o Kasus-kasus ganjil
o Exceptional flows, penanganan error

• Scenario adalah sebuah instance dari sebuah use case

• Activity diagram didalam model use case dapat digunakan untuk meng-capture aktifitas-aktifitas dalam sebuah use case
• Sebenarnya merupakan flowchart, yang menunjukkan aliran kontrol activity ke activity
Deskripsi singkat tentang USE CASE
• Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Perilaku ini merupakan aktifitas sistem yang bisa dilihat dari luar dan bisa diuji.
• Perilaku sistem ini dicapture di dalam USE CASE. USE CASE sendiri mendeskripsikan sistem, lingkungan sistem, serta hubungan antara sistem dengan lingkungannya.
Defenisi Use Case
• Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan yang tampak dari nilai ke actor khusus. Use Case digunakan untuk menyusun behavioral things dalam sebuah model. Use case direalisasikan dengan sebuah collaboration. Secara gambar, sebuah use case digambarkan dengan sebuah ellips dengan garis penuh, biasanya termasuk hanya namanya, seperti gambar berikut :

• Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk menggambarkan fungsional requirement suatu sistem.
• Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem.
• Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan perangkat lunak dalam berbagai cara.
• Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan secara bersama-sama, memproduksi hasil yang dibutuhkan oleh pengguna sistem. Use Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana yang biasa dilakukan (secara manual).
Contoh sederhana:
Konsumen pesan tiket pesawat

Contoh lebih lengkap:
Use Case pada Sistem Rumah Sakit

Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem, menggambarkan kebutuhan sistem, memvalidasikan arsitektur sistem, menjalankan implementasi dan meng-generate test case.
Include
Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut.
Extend
Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu.
Manfaat Model Use Case
• Digunakan untuk berkomunikasi dengan end user dan domain expert
o Menyediakan buy-in pada tahap awal pengembangan sistem.
o Memastikan pemahaman yang tepat tentang requirement / kebutuhan sistem.
• Digunakan untuk mengidentifikasi
o Siapa yang berinteraksi dengan sistem dan apa yang harus dilakukan sistem.
o Interface yang harus dimiliki sistem.
• Digunakan untuk ferifikasi
o Semua requirement yang telah dicapture.
o Tim pengembang memahami requirement.
Macam-macam Use Case
• Narative Form
Bentuk teks bebas dalam format paragraph.
• Scenerio Form
Penjelasan penulisan use case dari sudut pandang actor.
• Conversation Form
Dialog antara actor dan sistem yang menunjukkan interaksi antar keduanya.
Perbandingan Bentuk Use Case
Format Penulisan Use Case
Tiap Use Case memiliki:
• Precoditions, yang harus dipertemukan agar use cases dapat bekerja dengan sukses.
• Postconditions, mendefinisikan kondisi-kondisi dimana use cases berakhir.
• Postconditions mengidentifikasi hasil yang dapat diobservasi dan status akhir dari sistem setelah use case telah komplit.
• Flow of events, yang mendefinisikan aksi pengguna dan respon sistem terhadap aksi yang dilakukan. Flow of events merupakan kompresi dari skenario normal, yang mendefinisikan tingkah laku umum dari sistem untuk use case, dan cabang-cabang alternatif, dimana bagian lain yang telah tersedia dapat digunakan oleh use case.
Use Case dan Test Cases akan bekerja dengan baik dalam dua cara, yaitu:
• Jika use case dari sistem komplit, akurat dan jelas, maka pembuatan test cases dapat dilakukan secara langsung.
• Jika use case tidak dalam kondisi yang baik, maka pembuata test cases akan membantu dalam melakukan debug terhadap test cases.
Modul Use Case
Mulai dengan kondisi atau kejadian normal biasa:
• Acuhkan pengecualian, alternatif, dll.
• Use case harus dinamai dan perspektif pengguna sebagai kata kerja aktif.
• Menunjukkan deskripsi tujuan dari use case dan defenisi fungsionalitas tingkat
tinggi.
Model Use Case
• Model untuk melengkapi system requirements
• Tahapan awal "system development":
o Requirement: sistem belum terinci
o Representasi: user perspektif
"What the system will/should do ?"
• Starting point: OO analysis & design activities
• Garis besar terdiri dari: "actors" dan "use cases"
________________________________________
Actors
• Types yang mewakili: users yang berinteraksi dengan sistem
• Users: di luar dari sistem, batasan apa yang akan diharapkan dari sistem
o Pengertian users => types of activities performed by external entity
o Sekumpulan individu dapat dianggap sebagai satu user (same role)
• Actors: manusia, external hardware, atau sistem yang lain
________________________________________
Use Case
• Types yang mewakili: behaviour, sifat / karakteristik dan fungsi sistem
• Dikembangkan sesuai dengan keinginan "actor"
• Dapat diterjemahkan sebagai bentuk eksekusi pemakaian sistem
o Interaksi dan fungsi yang diharapkan dari sistem
o Flow events response dari sistem

Contoh : ATM Cashier Application
• Actor: Klien Bank
• Bagaimana interaksi dengan aplikasi di ATM ?
Fasilitas apa saja yang dapat diberikan oleh Bank kepada Klien Bank

• User cases:
o Tarikan Uang
o Deposit Uang
o Transfer Antar Rekening

• Actor: apa saja yang berinteraksi (memberikan dan menerima data atau events) dengan sistem
o Actor dapat mewakili sekelompok klien bank (yang mempunyai karut ATM)
o Satu klien dapat menggunakan ATM tersebut untuk berbagai keperluan => berbagai actors yang berbeda
o Peranan actor ditentukan use case mana saja yang digunakan oleh actor tersebut
• Interaksi ? tidak lain mengirim dan menerima messages (data, events)
o Hubungan antara actor dan use case: <> associations
________________________________________
Use Case: Transactions
• Definisi: use case adalah urutan transaksi/proses yang dilakukan oleh sistem, dimana menghasilkan sesuatu yang dapat dilihat/diamati oleh actor tertentu

• Problem: bagaimana memilih use case yang tepat (terdapat banyak kejadian interaksi antar actor dan system) ?
o Definisi di atas => "instance" kejadian yang penting dan dapat dipilah sangat relevan dengan kegiatan actors
o Pilih use case type yang mewakili instance tersebut
o Dari definisi "menghasilkan sesuatu yang dapat dilihat oleh actor" => use case harus cukup besar karena berhubungan dengan kegiatan actor
o Transaksi: sekumpulan aksi, keputusan, dan messages yang diberikan kepada actors secara konsisten
o Actor tertentu: peranan utama, karena hasil use case harus berhubungan dengan actor tersebut, berhubungan dengan task tertentu

Contoh
Use case: Tarikan Uang
• Klien Bank memberikan identifikasi dirinya
• Klien Bank memilih atau memberikan input berapa banyak uang yang akan diambil dari rekening. Sistem memberikan persetujuan dan mengijinkan berapa banyak uang yang dapat diambil
• Sistem mengeluarkan uang tersebut dan mengurangi jumlah uang tersebut dari rekening
________________________________________
Reuse Use Case : <>
• Untuk sistem yang besar: terdapat use case yang sifatnya sama
• Kelompok use case ini dapat dibuat : "generalizations" yang mewakili kelompok tsb.
o Dapat dianggap sebagai "inheritance"
o Digunakan simbol: <>

• Contoh: <> use case A menggunakan use case B berarti instance A dapat melakukan semua sifat dari instance B
o Sebagai contoh: semua transaksi ATM berhubungan dengan pemindahan uang dari satu rekening ke rekening lain.
• Dapat menggunakan use case yang telah ada: Transfer Keuangan sebagai "abstract" use case.
Transfer Keuangan use case memberikan deskripsi cara debit dan kredit dari berbagai account yang berbeda.
Reuse Use Case : <>
• Sering use case dapat dikembangkan (ditambahkan) dari use case yang telah ada
• Penambahan ini untuk memberikan spesialisasi atau inheritance
• Jadi jika disebut use case A "extends" use case B : maka instance tersebut mengikuti use case A dan pada satu saat akan mengikuti use case B, setelah mengikuti B dapat kembali ke use case A.
• Contoh: Klien Bank dapat diberikan fasilitas untuk mengambil uang dalam bentuk overdraft.

Untuk kasus dimana Klien Bank mengambil overdraft maka terdapat sifat khusus use case yang harus ditangani oleh "Manajemen Overdraft"

Atau dapat disebut: use case Manajemen Overdarft merupakan "extends" dari use case Tarikan Uang.


Contoh Lain:

HUBUNGAN PENDIDIKAN dan KEMISKINAN

Pendidikan bagi bangsa yang maju sangat penting, bisa di sebut pula dengan kebutuhan. Sama kebutuhan perumahan, sandang dan pangan, bahkan ada bangsa yang terkecil adalah keluarga, pendidikan merupakan kebutuhan utama artinya, mereka mau mengurangi kualitas perumahan, pakaian bahkan makanan demi melaksanakan pendidik anak-anaknya. Seharusnya negara juga demikian, apabila suatu negara ingin cepat maju dan berhasil dalam pembangunan. Prioritas pembangunan negara itu adalah pendidikan, jika perlu sektor-sektor yang tidak penting ditunda dulu dan dana dipusatkan pada pembangunan pendidikan.

Sebagian besar keadaan sosial ekonomi masyarakat kita tergolong tidak mampu dengan kata lain mereka masih dililiti kemiskinan. Mulai inpres 10 tahun 1971 tentang pembangunan sekolah dasar seharusnya dipercepat pengangkatan guru SD dan beribu-ribu bangunan sekolah supaya mereka mendapatkan biaya murah yang terjangkau oleh masyarakat Indonesia. Disanalah orang tua menyekolahkan anak-anak mereka, dan tidak Nampak perbedaan antara anak-anak orang miskin dengan anak orang kaya, karena mereka diberi seragam yang bersamaaan yang tidak akan merubah penampilan mereka.

Antara orang miskin yang berpendidikan dan orang kaya yang berpendidikan sangat berbeda karena pendidikan ini sebenarnya tidak diharapkan dari guru saja karena itu tidak akan cukup. Dari situlah orang tua berperan untuk mencukupi pendidikan mereka.

Kalau orang kaya mereka kebanyakan mendapat pendidikan dari guru saja, karena mereka selalu ditinggal oleh orang tua yang disibukkan oleh karir mereka. Jadi mereka kurang kasih sayang dari kedua orang tua mereka. Jadi mereka kurang diperhatikan dan akhirnya terjaebak kedalam dunia anak zaman sekarang, misalnya memakai narkoba, pergaulan bebas, dll.

Kalau oaring miskin mereka tetap diberikan pendidikan dirumah oleh kedua orang tua mereka sehingga kebanyakan yang pintar-pintar adalah orang anak orang miskin.

Enaknya dikit Sakitnya Lama

Terlintas difikiran saya narkoba sangat fatal sekali akibatnya.bukankah orang orang yang menjadikan narkoba sebagai “PELARIAN”akan terkena prinsip ini.”nikmat sesaat yang mungkin hanya beberapa jam, tetapi sakitnya lama dan tak ketulungan.

Kemudian bagaimana dengan tindakan KORUPSI….??????????

YACH…….!!!!!! kalau saya rasa ini juga termasuk yang akan mendatangkan kenikmatan sesaat,short term sekali namun sakitnya seumur hidup dan bahkan sampai akhirat.Betapa tidak bukankah ketika mendapat hasil”jarahan”sikoruptor dapat dengan bebas berfoya-foya menikmati hasil korupsinya.namun kenikmatan semu itu ternyata tidak bertaan lama,karena keburu tercium oleh masyarakat luas lalu diadili selanjutnya dijebloskan kepenjara.

Setelah bertahun tahun menghitung hari dipenjara,kemudian keluarlah dari penjara fisik,tapi…..penjara batin tetap tidak bisa dibebaskan.dan lebih menyedihkan lagi si koruptor yang sudah jadi mayat tidak ada lagi rasa sedih masyarakat malahan mereka bersyukur! alama’………….enaknya Cuma sikit sakitnya lamaaaaaaaaaa.

Kenapa tidak kita balik aja prinsip ini YACH……..???????????

“SAKITNYA DIKIT ENAKNYA LAMAAAAAAAA”

Sebagai contoh:

Ibadah ritual sehari-hari yang kita lakukan sebagai mana tuntutan agama dengan susah payah siang-malam bahkan tengah malam (qiamullail/tahajud).kita lakukan semua itu dengan sakit,alias berat untuk dilakukan ! yach….!!! Itu ma Cuma sebentar sakitnya……

Begitu juga halnya dengan segala perjuangan dan kesulitan kita dimuka bumi ini dalam memperjuangkan kebenaran.sulit dan sakit memang tapi hanya sebentar,nanti enaknya kita rasakan sepanjang umur dunia dan akhirat.

Akhirnnya mari kita renungkannasehat penuh falsafah yang cukup mendalam dari pelawak terkenal dan sangat senior yang tidak asing lagi adalah “Tarzan” suatu ketika dilayar kaca bertutur ”lebih baik petheng sepisan padhang selawase dari pada padhang sepisan peteng selawase”(lebih baik gelap sebentar tapi akan terang selamanya,dari pada terang hanya sebentar lalu gelap selamanya).

Bravo om Tarzan,”lebih baik sakitnya sedikit enaknya lama dari pada enaknya sedikit sakitnya lama………”

HUBUNGAN PENDIDIKAN dan KEMISKINAN

Pendidikan bagi bangsa yang maju sangat penting, bisa di sebut pula dengan kebutuhan. Sama kebutuhan perumahan, sandang dan pangan, bahkan ada bangsa yang terkecil adalah keluarga, pendidikan merupakan kebutuhan utama artinya, mereka mau mengurangi kualitas perumahan, pakaian bahkan makanan demi melaksanakan pendidik anak-anaknya. Seharusnya negara juga demikian, apabila suatu negara ingin cepat maju dan berhasil dalam pembangunan. Prioritas pembangunan negara itu adalah pendidikan, jika perlu sektor-sektor yang tidak penting ditunda dulu dan dana dipusatkan pada pembangunan pendidikan.

Sebagian besar keadaan sosial ekonomi masyarakat kita tergolong tidak mampu dengan kata lain mereka masih dililiti kemiskinan. Mulai inpres 10 tahun 1971 tentang pembangunan sekolah dasar seharusnya dipercepat pengangkatan guru SD dan beribu-ribu bangunan sekolah supaya mereka mendapatkan biaya murah yang terjangkau oleh masyarakat Indonesia. Disanalah orang tua menyekolahkan anak-anak mereka, dan tidak Nampak perbedaan antara anak-anak orang miskin dengan anak orang kaya, karena mereka diberi seragam yang bersamaaan yang tidak akan merubah penampilan mereka.

Antara orang miskin yang berpendidikan dan orang kaya yang berpendidikan sangat berbeda karena pendidikan ini sebenarnya tidak diharapkan dari guru saja karena itu tidak akan cukup. Dari situlah orang tua berperan untuk mencukupi pendidikan mereka.

Kalau orang kaya mereka kebanyakan mendapat pendidikan dari guru saja, karena mereka selalu ditinggal oleh orang tua yang disibukkan oleh karir mereka. Jadi mereka kurang kasih sayang dari kedua orang tua mereka. Jadi mereka kurang diperhatikan dan akhirnya terjaebak kedalam dunia anak zaman sekarang, misalnya memakai narkoba, pergaulan bebas, dll.

Kalau oaring miskin mereka tetap diberikan pendidikan dirumah oleh kedua orang tua mereka sehingga kebanyakan yang pintar-pintar adalah orang anak orang miskin.

JANGAN HANYA “BELAJAR DARI HIDUP”

BELAJARLAH UNTUK HIDUP BEBAS

Cinta tidak mungkin bisa dipakskan, belajarpun tidak bisa dipaksakan. Cara belajar yang paling baik, salah satunya adalah suasana tanpa tekanan dan paksaan tentunya, cara belajar yang paling menyenangkan adalah sambil bermain. Ini terjadi jika pikiran kita bebas dan jernih.

Kita dapat melihat menerawang sesuatu, seolah-olah melihat kaca jendela yang bersih ketika pikiran sedang jernih. Misalnya alas an yang kita buat-buat kala sedang malas atau diperbudak prasangka. Kita dapat belajar melitah kebalik dusta yang kita katakana jika sedang terlalu takut untuk maju dan membela keyakinan kita.

Kita berfikir jernih, visi terbebaskan, kita menangkap apa yang kita lihat, kita melihat tanda-tanda zaman dan membaca apa yang tersirat, kita mengajak intelek untuk belajar, tetapi kita juga mengisi hati dan semangat. Belajar yang menyentuh pikiran, emosi dan semangat. Belajar yang menyentuh pikiran, emosi dan semangat yang seperti ini bersifat multidimensi dan berlapis-lapis.

Terapkan pada diri mu……..

Bawalah buku catatan kecil waktu bepergian untuk menampung coretan, lamunan dan renungan yang sekilas tidak berkaitan sama sekali dengan pelajaran, tetapi seolah-olah hanya untuk bermain, tidak apa-apa kalau catatan anda ini tidak langsung berguna atau tidak masuk akal, tapi percaya saja bahawa catatan ini mempersiapkan pikiran untuk membuat koneksi dan temuan buku catatan ini merangsang alam tak sadar dan imajinasi. Pada akhirnya, anda akan memanfaatkan buku ini untuk membangun ide-ide. Jika anda merasa kebun binatang tidak menarik, cobalah melihat akuarium, jika akuariumpun tidak terasa menarik, kunjungi tempat lain seperti mall, amati, amati dan amati, selesai mengamati orang dan lingkungan, buatlah ringkasannya, kaji catatan dan gambar yang telah dibuat, dan cari nama yang bisa anda pakai untuk memperkaya pekerjaan, bermainlah dengan gambar yang dibuat, bereksperimen dan bersenang-senanglah.