Konsep Dan Prinsip Analisis

PRINSIP DAN KONSEP ANALISA
(ANALYSIS CONCEPT AND PRINCIPLES)


Dalam konteks perangkat lunak, analisis merupakan sebuah :
Penemuan
Perbaikan
Pemodelan
Spesifikasi (baru)
SIAPA YANG BERPERAN DALAM ANALISIS ?
Pengembang maupun pelanggan harus berperan aktif
Pelanggan berusaha memformulasikan kembali konsep yang tidak jelas dari fungsi perangkat lunak dan kinerja kedalam detail yang konkret.
Pengembang bertindak sebagai integrator, konsultan dan pemecah masalah
Ruang lingkup perangkat lunak secara mendasar dikembangkan oleh perekayasa system dan diperbaiki selama perencanaan proyek perangkat lunak dan diperbaiki secara detail (rinci).




APA YANG MENJADI MASALAH SEBENARNYA ?
Pelanggan hanya memiliki ide yang samar-samar apa yang dibutuhkan
Pengembang akan menghasilkan sesuatu dengan mengacu kepada “ide yang samar-samar”, dengan asumsi bahwa “kita akan mengerjakan rincian pekerjaan sesuai tahapan (langkah)”
Pelanggan akan terus mengikuti perubahan
Pengembang akan “dirugikan” oleh perubahan-perubahan ini, membuat kesalahan-kesalahan dalam spesifikasi dan pengembangan


ANALISIS PERSYARATAN
Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi perangkat lunak tingkat system dan perancangan perangkat lunak seperti terlihat pada gambar



Analisis persyaratan perangkat lunak dapat dibagi menjadi 5 (lima) area kerja yaitu :
Pengenalan masalah
Mempelajari spesifikasi system (bila ada) dan rencana proyek perangkat lunak dalam suatu konteks system dan mengkaji ruang lingkup perangkat lunak dalam suatu konteks system dan mengkaji ruang lingkup perangkat lunak yang telah digunakan untuk memunculkan estimasi perencanaan
Evaluasi dan sintesis
· Membatasi semua objek data yang dapat diobservasi secara eksternal
· Mengevaluasi aliran dan muatan informasi
· Mendefinisikan dan menguraikan semua fungsi perangkat lunak
· Memahami tingkah laku perangkat lunak dalam konteks kejadian yang mempengaruhi system
· Membangun karakteristik interface system
· Menemukan batasan desain tambahan
Pemodelan
Menyiapkan system dalam ukuran yang kecil-kecil sebelum penerapan dengan system yang sebenarnya
Spesifikasi
Menetapkan system dalam kondisi yang sebenarnya
Kajian
Melakukan evaluasi dan pengujian formal terhadap penerapan yang telah dilakukan apakah sasaran yang yang ditetapkan tercapai atau tidak.


FAST (Facilitated Application Specification Techniques)
FAST
Memacu kreasi kerjasama dari tim (pelanggan dan pengembang) yang bekerja sama untuk :
· Mengidentifikasi masalah
· Menyiapkan elemen-elemen solusi
· Menegosiasikan pendekatan yang berbeda
· Menetapkan sebelumnya kebutuhan solusi yang diperlukan


PANDUAN FAST
J. Wood dan D. Silver menyarankan beberapa panduan umum FAST yang dapat digunakan yaitu :
Peserta harus menghadiri semua rapat
Semua peserta adalah sama
Persiapan harus sama pentingnya dengan rapat yang sebenarnya
Semua dokumen sebelum rapat harus dikaji ulang
Lokasi rapat diluar ruangan terkadang diperlukan
Tentukan agenda dan jangan sampai mengalami perubahan
Jangan sampai terbawa dalam hal-hal teknis yang terlalu rinci


(QUALITY FUNCTION DEPLOYMENT = QFD)
Teknik manajemen kualitas yang menterjemahkan kebutuhan pelanggan kedalam kebutuhan teknis untuk perangkat lunak
Pertama kali diperkenalkan di Jepang untuk memaksimalkan kepuasan pelanggan
Menekankan pemahaman tentang apa yang berguna kepada pelanggan dan kemudian menyebarkan nilai-nilai tersebut melalui proses rekayasa


QFD mengidentifikasi tiga tipe persyaratan yaitu :
Persyaratan normal : Sasaran dan tujuan bagi sebuah produk atau system selama pertemuan dengan pelanggan. Bila persyaratan ini ada, maka pelanggan akan menjadi puas, misalnya tampilan grafis yang sempurna.
Persyaratan yang diharapkan : Persyaratan ini implicit terhadap produk atau system yang sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya akan menyebabkan ketidakpuasan yang sangat mendalam. Contohnya adalah mudahnya operasional interaksi manusia dan mesin, reliabilitas dan kebenaran operasional keseluruhan dan mudahnya instalasi perangkat lunak
Exciting requirement : Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada, misal kemampuan perangkat pengolah kata yang memiliki kemampuan layout halaman, dsb.
ANALISA PROSES SECARA UMUM


PRINSIP ANALISA KESATU
Data Domain Model :
Menetapkan objek data
Menggambarkan atribut data
Menetapkan hubungan data


PRINSIP ANALISA KEDUA
Fungsi Model :
Mengidentifikasi fungsi yang (dapat) merubah objek data
Mengindikasikan berapa data yang melalui system
Mewakili data produsen dan konsumen


PRINSIP ANALISA KETIGA
Model Kebiasaan :
· Mengindikasikan states yang berbeda dari system
· Menetapkan kejadian yang mungkin menyebabkan perubahan pada state




PRINSIP ANALISA KEEMPAT
Partisi Model :
· Menyaring setiap model untuk mewakili level yang lebih rendah dari abstraksi
o Menyaring objek data
o Membuat hirarki fungsi
o Mewakili kebiasaan pada tingkatan yang berbeda tiap detil
· Membuat partisi horizontal dan vertikal


PRINSIP ANALISA KELIMA :
Intisari :
Memulai focus intisari masalah tanpa memperhatikan rincian implementasi

Read More

Analisis Kebutuhan Perangkat Lunak

Analisis kebutuhan merupakan langkah awal untuk menentukan gambaran perangkat yang akan dihasilkan ketika pengembang melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat tergantung pada keberhasilan dalam melakukan analisis kebutuhan. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning.
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik, tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat yang tidak berguna. Mengetahui adanya kesalahan pada analisis kebutuhan pada tahap awal memang jauh lebih baik, tapi kesalahan analisis kebutuhan yang diketahui ketika sudah memasuki penulisan kode atau pengujian, bahkan hampir masuk dalam tahap penyelesaian merupakan malapetaka besar bagi pembuat perangkat lunak. Biaya dan waktu yang diperlukan akan menjadi sia sia.

Analisis kebutuhan
Analisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi dari klien yang akan menjadi acuan untuk melakukan desain perangkat lunak.
Analisis kebutuhan merupakan satu di antara banyak aktivitas kritis pada proses rekayasa kebutuhan perangkat lunak untuk memahami ranah permasalahan dari sistem yang berjalan dan ranah solusi dari sistem yang akan dibuat(Yen et.al, 1998).
Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis. Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci. Semua data dari analisis kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang dipikirkan oleh pihak analisis.
Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok:

1.Identifikasi Masalah
2.Evaluasi dan sintesis
3.Pemodelan
4.Spesifikasi
5.Review


Tujuan analisis kebutuhan
Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai beriukut :
1.Mengelola hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi kebutuhan yang isi keseluruhannya sesuai dengan apa yang diinginkan pengguna                                (Liu and Yen, 1996).
2.Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para manajer dapat membuat pekerjaan proyek yang realistis dan staf teknis dapat melanjutkan dengan perancangan, implementasi dan pengujian (Wiegers, 2003).
3.Membangun pemahaman tentang karakteristik ranah permasalahan dan sekumpulan kebutuhan untuk menemukan solusi.
Ketiga tujuan tersebut dapat dicapai oleh perekayasa kebutuhan dengan melalui serangkaian tahapan-tahapan aktivitas. Tahapan aktivitas tersebut dijelaskan sebagai berikut.
Tahap Analisis Kebutuhan
Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya (manusia , perangkat keras dan perangkat lunak yang dibutuhkan) dan taksiran biaya pengembangan perangkat lunak.

Diagram menunjukan tahapan-tahapan didalam analisis kebutuhan (Sommervilee, 2004). Pada dasarnya, aktivitas analisis dibutuhkan dalam setiap proses dalam daur hidup pengembangan perangkat lunak. Didalam proses rekayasa kebutuhan, analisis pun dilakukan dalam setiap aktivitas-aktivitasnya. Penjelasan dari masing-masing aktivitas tersebut.

Domain Understanding, dalam tahap ini perekayasa kebutuhan perangkat lunak harus mengetahui bagaimana organisasi perusahaan beroperasi dan apa yang menjadi permasalahan pada sistem yg sedang  berjalan pada saat ini. perekayasaan perlu memfokuskan kepada ‘Apa’ yg menjadi permasalahan. Perekaysaan hendaknya tidak berhenti pada menemukan “gejala” dari  permasalahn itu terjadi untuk menemukan akar dari pemasalahan dari sistem yg berjalan tersebut.

Requirements Collection, Tahapan ini merupakan tahapan pengumpulan kebutuhan akan sistem yang akan dibangun.Pada tahapan ini diperlukan adanya intekasi intensif dengan pemangku kepentingan terutama dengan pengguna akhir.

Classification, Pada tahapan sebelumnya kumpulan kebutuhan masih tidak terstruktur.Untuk itu kebutuhan yang saling berkaitan dikelompokan,baik menurut kelas penggunaanya maupun jenis kebutuhananya. Kebutuhan kebutuhan tersebut diorganisasi ke dalam kelompk-kelompok yang koheren.Perekayasaan perlu memisahkan antara kebutuhan dan keinginan dari pengguna.

Conflict resolution, Pada tahapan ini adalah menemukan dan menyelesaikan  kebutuhan yang di dalamnya terdapat konflik.

Prioritisation, Pada tahapan dilakukan interaksi dengan pemangku kepentingan untuk mengidentifikasikan kebutuhan-kebutuhan priopritas dari masing-masing kebutuhan agar sumber daya yang tersedia pada organisasi dialokasikan untuk mengimplementasikan kebutuhan yg terutama dari pemangku kepentingan.

Requirements Checking, Menganalisa sekumpulan kebutuhan dari hasil tahapan sebelumnya untuk memverifikasi dan memvalidasi berdasarkan aspek kelengkapan,konsistensi,dan kebutuhan nyata.

Dalam rekayasa kebutuhan, analisa kebutuhan yang baik hedaklah menitik beratkan pada ranah permasalahan dan bukan pada ranah solusi. Tujuan utamanya adalah untuk mencapai pemahaman tetang sifat dari ranah permasalahan dan permasalahan  yang ada didalamnya . Pada dasarnya, analisi kebutuhan diawali dengan spesifikasi (layanan, atribut, properti, kualitas, batasan) dari sistem solusi yang hendak dibangun.

Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting.

Prinsip-prinsip analisis

Masing-masing metode analisis memiliki titik pandang yang  unik. Tetapi, semua metode analisis dihubungkan oleh serangkaian prinsip operasional (Pressman, 2008) berikut :

1. Ranah informasi dari suatu masalah harus dipresentasikan dan dipahami.
2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3. Tingkah laku perangkat lunak (sebagai suatu uruatan kejadian eksternal) harus terwakilkan.
4. Model-model yang merepresentasikan informasi, fungsi dan tingkah laku sistem haurs dipecah-pecah ke dalam tingkat yang lebih rinci dalam bentuk lapisan (atau hierarki).
5. Proses analisis harus dimulai dari informasi dasar menuju implementasi rinci.

Definisi Analisis

Analisis adalah penguraian suatu pokok atas berbagai bagiannya dan proses bagian itu sendiri serta hubungan antar bagian untuk memperoleh pengertian yang tepat dan pemahaman arti keseluruhan.

Tujuan tahap analisis adalah :

1. Menjabarkan kebutuhan pemakai
2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak
3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna).

Definisi kebutuhan

Definisi kebutuhan menurut IEEE (The Institute of Electrical and Electronics Engineers) kebutuhan adalah :

1. Suatu kondisi atau kemampuan yang diperlukan pengguna untuk menyelesaikan masalah atau mencapai sesuatu.
2. Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh suatu sistem atau komponen sistem untuk memenuhi suatu kontrak, standar, spesifikasi atau dokumen formal lain yang diberlakukan.
3. Suatu representasi terdokumentasi dar suatu kondisi atau kemapuan seperti dalam 1 dan 2.

Tahap kebutuhan akan perangkat lunak dimulai dengan :

1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian. Identifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas (product improvement oriented). 
2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah  kemajuan).

Suatu kebutuhan adalah atribut yang diperlukan di dalam sebuah sistem, sedangkan satu pernyataan (statment) digunakan untuk mengidentifikasi sebuah kemampuan, karakteristik, atau faktor kualitas dari sebuah sistem untuk mempunyai nilai dan kegunaan bagi pelanggan atau pengguna.

Kebutuhan menjadi hal penting sebab mereka menyediakan dasar untuk semua pengembangan pekerjaan selanjutnya, mengapa?

Mencari kesalahan diakhir siklus hidup pengembangan perangkat lunak ternyata akan banyak mengeluarkan uang. 

1. Jika dapat dideteksi, dilakukan perbaikan pada setiap tahap proses. 
2. Jika tidak dapat dideteksi, kesalahan baru kelihatan setelah produk selesai dibuat.

Suatu pendekatan yang lebih baik akan menginvestasikan waktu yang lebih di dalam pengempulan kebutuhan, analisis, dan aktivitas-aktivitas manajemen. Alasannya adalah bahwa pekerjaan pengodean biasanya dimulai lebih cepat daripada harus menambah waktu untuk mengidentifikasi kebutuhan “riil” (real) dan untuk merencanakan aktivitas terkait kebutuhan (requidment-realted). Ada satu perbedaan penting antara kebutuhan State dan kebutuhan riil, yaitu :

1. Kebutuhan State (ditetapkan) disajikan oleh pelanggan pada permulaan sistem atau usaha pengembangan perangkat lunak, contohnya di dalam permintaan untuk informasi, proposal, atau di dalam sebuah statment of Works (SOW).
2. Kebutuhan riil mencerminkan kebutuhan pengguna yang dibutuhkan untuk kemampuan atau sistem tertentu.

Sering muncul perbedaan yang sangat besar antara kebutuhan State dan kebutuhan riil. Analisis dalam kebutuhan State  diperlukan untuk menentukan dan menyaring pelanggan riil, kebutuhan pengguna dan harapan sistem yang dikirimkan. Kebutuhan perlu disaring dengan proses klarisifikasi dari identifikasi, artinya dari aspek yang lain yang membutuhkan pertimbangan. Contoh sederhana, requirement analysts (RA) menjadi lebih terbiasa dengan keperluan untuk menyatakan kebutuhan dengan jelas.

Untuk menghemat waktu, semua kebutuhan sebaiknya diperjelas melalui mekanisme pelanggan/pengguna gabungan (jin costomer/user) dan usaha RA. Pelanggan dan pengguna akan memerlukan dukungan secara teknis dan para profesional yang berpengalaman, dan sebaliknya memastikan komunikasi yang efektif. Pengembang juga harus mempunyai pemanahan yang sama sehingga solusi yang mereka gambarkan sesuai dengan harapan semua orang. Kesalahpahaman akan berujung pada kesia-siaan dan mengharuskan pekerjaan ulang.

Proses Rekayasa Kebutuhan

Apa yang menjadi kesuksesan dalam sebuah perangkat lunak? Apa sistem yang cukup mampu memenuhi semua kebutuhan penggunanya? Tinggat kepuasan penggunannya?

Rekayasa kebutuhan mencakup beberapa proses mengenai fakta ini, proses rekayasa kebutuhan adalah sekumpulan aktivitas-aktivitas yang terstruktur untuk diperoleh, memvalidasi, dan memelihara dokumen kebutuhan sistem (Thayer, 1997). Pada umumnya tugas rekayasa digambarkan sebagai penciptaan dari solusi keefektifan biaya untuk masalah kehidupan yang nyata dengan menerapkan pengetahuan keilmuan. Rekayasa kebutuhan juga dapat digambarkan sebagai tugas untuk memenuhi aktivitas-aktivitas pengembangan untuk masalah dunia nyata sehingga ketepatan dan keefektifan biaya dari solusi dapat dianalis (Nuseibeh, 2000).

Dari sudut pandang pengembangan sistem perangkat lunak, dua aktiviatas dapat dikenali sebagai rekayasa kebutuhan dan rekayasa perangkat lunak. Rekayasa perangkat lunak dapat digambarkan sebgai aktivitas yang terlibat dalam siklus hidup dari proses pengembangan perangkat lunak, dengan rekayasa kebutuhan yang menjadi pusat aktivias di dalam siklus hidup.

Latar belakang kenapa rakayasa kebutuhan diperlukan adalah kenyataan bahwa menemukan kebutuhan klien secara lengkap merupakan usaha yang tidak mudah dan mahal. Dikatakan tidak mudah karena,

1. Klien tidak selalu mengetahui dengan pasti dan jelas mengenai apa yang diperlukan,
2. Kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud, dan
3. Kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak.

Hal tersebut menyebabkan biaya pembangangunan perangkat lunak menjadi mahal karena ada tambahan biaya dan tambahan waktu untuk perubahan yang dilakukan.

Daur hidup suatu perangkat lunak (SLC) secara umum dapat diilustrasikan sebagai gambar diatas, dimana ada 2 buah siklus kehidupan utama dari suatu perangkat lunak, yaitu daur hidup pengembangan perangkat lunak (SDLC) dan daur hidup pengoperasian perangkat lunak (SOLC), keduanya dihubungkan oleh dua buah proses, yaitu proses studi kelayakan dan proses peluncuran.

Pengembangan perangkat lunak pada dasarnya muncul karena adanya suatu kebutuhan baru. Melalui studi kelayakan, kita dapat dibantu menentukan apakah kebutuhan tersebut masih dapat dipenuhi oleh sistem perangkat lunak yang ada atau tidak. Jika dipandang bahwa sistem yang sudah ada tidak dapat memenuhi kebutuhan baru tersebut, maka kita akan memutusakan apa mau mengembangkan sistem perangkat lunak (baik sistem lama atau baru). Studi kelayakan tetap dilakukan dalam pengembangan perangkat lunak berskala besar maupun kecil.

Sistem yang baru yang akan dikembangkan bisa dibangun dari sistem lama, atau dari sistem baru. Sering juga disebut lingkungan pengembangan (development enviornment). Proses pertama yang dilakukan dengan penspesifikasian kebutuhan, hasil dari proses ini adalah sebuah spesifikasi kebutuhan sistem yang dibutuhkan oleh pembuat. Spesifikasi ini sering disebut sebagai rancangan bersifat high-end. Berdasarkan spesifikasi tersebut, pihak pengembang akan membuat suatu rancangan yang bersifat low-end. Kemudian diimplementasikan menjadi produk perangkat lunak oleh programmer. Melalui proses pengujian produk ini diuji dan dipastikan kesesuaiannya dengan spesifikasi kebutuhan yang telah ditetapkan dan ketetapan implementasinya. Produk yang berhasil melewati proses pengujian kemudaian akan diluncurkan ke lingkungan operasioanl (operatioan environment).

Dalam daur pengoperasian , perangkat lunak yang telah selesai dibangun difungsikan untuk kebutuhan operasiional sistem. Seringkali, terdapat ketidaksesuaian antara perangkat lunak dengan kebutuhan di lapangan. Kesalahan ini terjadi pada beberapa kesalahan pada daur hidup pengembangan dan akan diperbaiki. Proses ini sering dipandang sebagai proses perawatan perangkat lunak. Tapi jika kesalahan itu terjadi karena kebutuhan baru dalam organisasi maka perangkat lunak tersebut dikaji ulang kelayakannya. Dan kembali pada daur hidup perangkat lunak tersebut.

Spesifikasi kebutuhan merupakan proses awal dari daur hidup pengembangan perangkat lunak. Keluaran dari proses ini menentukan arah pengembangan perangkat lunak selanjutnya.

Tahap pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas :

1. Menentukan kebutuhan (requirement)

Lebih banyak berhubungan dengan pemakai. Hasil belum terstruktur.

1. Data atau informasi apa yang akan diproses
2. Fungsi apa yang diinginkan
3. Kelakuan sistem apa yang diharapkan
4. Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software  interface, dan communications interfaces)

2. Sintesis

Mengubah kebutuhan yang belum terstruktur menjadi model atau gambar dengan memanfaatkan teknik dan metodeanalisis tertentu.

3. Membuat dokumen Software Requirements Spesification (SRS).

Sudah merupakan analisis yang lebih rinci, sebagai tahap awal perancangan.

Studi Kelayakan

Untuk semua sistem baru, proses rekayasa persyaratan harus dimulai studi kelayakan. Input dari studi kelayakan adalah deskripsi garis besar sistem dan bagaimana sistem akan digunakan di dalam organisasi. Hasil studi kelayakan berwujud laporan.

Studi Kelayakan memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek permasalahan. Melakukan studi kelayakan mencakup penilaian informasi, pengumpulan informasi,dan penulisan laporan.

Melakukan studi untuk menguji apakah sistem:

1. sudah sesuai dengan tujuan organisasi
2. dapat dikembangkan dengan teknologi terkini dan dana yang tersedia
3. dapat diintegrasikan dengan sistem lain yang sudah digunakan

Implementasi Studi Kelayakan

Implementasi menurut kamus besar indonesia, diartikan sebagai pelaksanaan atau penerapan, artinya yang dilaksanakan dan diterapkan adalah kurikulum yang telah dirancang atau didesain untuk kemudian dijalankan sepenuhnya.

Berbasikan pada penilaian informasi (apa yg dibutuhkan), pengumpulan informasi dan penulisan laporan

Pertanyaan ke personal di organisasi:

1. Apa yang akan terjadi apabila sistem tidak diimplementasikan?
2. Masalah proses apa yang ada ?
3. Apa yang dapat dibantu oleh sistem ?
4. Masalah apa yang akan muncul pada proses Integrasi ?
5. Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ?
6. Fasilitas apa yang harus didukung oleh sistem ?

Validasi Kebutuhan

Validasi adalah suatu tindakan pembuktian dengan cara yang sesuai dengan tiap bahan proses, prosedur, kegiatan, sistem, perlengkapan atau mekanisme yang digunakan dalam produksi dan pengawasan yang akan senantiasa mencapi hasil yang diinginkan.

Validasi Kebutuhan

Validasi dibutuhkan untuk memberikan kepastian bahwa rancangan dan dokumen dari sistem yang akan diimplementasiakn telah sesuai dengan keinginan dan kebutuhan pemangku kepentingan baik pemesan, pengguna maupun pihak pengembang.  Tujuan dari validasi kebutuhan adalah :

1. Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai dengan yang diinginkan pengguna
2. Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan penambahan biaya yang besar
3. Memperbaiki definisi kebutuhan setelah software dikirim akan menyebabkan peningkatan biaya hingga 100 kali

Read More

Teknik komunikasi

Teknik komunikasi

Teknik komunikasi yakni meliputi empat macam sebagai berikut;

1. Komunikasi informatif (informative communication)
Teknik komunikasi informatif, yakni suatu teknik komunikasi yang dilakukan agar orang lain (komunikan) mengerti dan tahu. Bisa kita temukan teknik ini pada semua bentuk komunikasi personal, bentuk komunikasi media, ataupun bentuk komunikasi massa.



2. Komunikasi persuasif (persuasive communication)
Teknik komunikasi persuasif merupakan suatu teknik komunikasi yang dilakukan agar orang lain bersedia menerima suatu paham atau keyakinan, melakukan suatu perbuatan atau kegiatan dan lain sebagainya. Teknik ini berlangsung dengan personal contact yang memungkinkan komunikator mengetahui, memahami, dan menguasai; (1) frame of reference komunikan selengkapnya, (2) kondisi fisik dan mental komunikan sepenuhnya, (3) suasana lingkungan padasaat terjadinya komunikasi, dan (4) tanggapan komunikan secara langsung.

3. Komunikasi instruktif/koersif (instructive/coersive communication)
Teknik komunikasi instruktif atau koersif merupakan teknik komunikasi agar orang mengikuti suatu prosedur dan aturan-aturan tertentu.

a. Komunikasi manusiawi (human relation)
Hubungan manusiawi, menurut Effendy (2000:138-140), dalam arti luas ialah interaksi antara seseorang dengan orang lain dalam segala situasi dan di dalam semua bidang kehidupan. Adapun hubungan manusiawi dalam arti sempit yakni interaksi antara seseorang dengan orang lain dalam situasi kerja dan dalam organisasi kekaryaan (work organization).
Ditinjau dari ilmu komunikasi, hubungan manusiawi termasuk ke dalam komunikasi antarpersona (interpersonal communication) sebab berlangsung pada umumnya antara dua orang secara dialogis. Oleh karena sifatnya action oriented, hubungan manusiawi disebut komunikasi.
Teknik komunikasi hubungan manusiawi ini yakni berupa counseling. Konseling ini bertujuan untuk membantu konseli (counselee), yakni seseorang yang menghadapi masalah atau menderita frustasi, untuk memecahkan masalahnya sendiri atau mengusahakan terciptanya suasana yang menimbulkan keberanian untuk memecahkan masalahnya.
Dalam hubungan manusiawi, ada dua jenis konseling, bergantung pada pendekatan (approach) yang dilakukan. Kedua jenis tersebut yakni direct counseling, yakni konseling yang langsung terarah, dannon-directive counseling, yakni konseling yang tidak langsung terarah.

Read More