Rabu, 19 Juni 2013

Prinsip Dan Konsep Analisa (Analysis Concept And Principles)

PEMAHAMAN
Pemahaman lengkap mengenai persyaratan perangkat lunak sangat penting bagi keberhasilan usaha pengembangan perangkat lunak. Tidak peduli bagaimana perangkat lunak dirancang atau dikodekan, program yang dianalisis dan ditentukan secara tidak baik akan mengecewakan pemakainya dan akan membawa kegagalan bagi pengembangnya.
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.
Analisis Persyaratan Perangkat Lunak dibagi 5 area kerja, yaitu :
1. Pengenalan masalah
2. Evaluasi dan sintesis
3. Pemodelan
4. Spesifikasi
5. Kajian

TEKNIK KOMUNIKASI
  • Merupakan permulaan yang (selalu) perlu dilakukan agar seorang pelanggan memiliki masalah yang dapat dipertanggung jawabkan melalui pemecahan berbasis komputer
  • Agar pengembang dapat merespon permintaan bantuan (help) dari pelanggan
  • Biasanya jalan komunikasi ke pemahaman penuh dengan “lobang-lobang”
FAST (Facilitated Application Specification Techniques)
Memacu kreasi kerja sama 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
PENYEBARAN FUNGSI KUALITAS (QUALITY FUNCTION DEPLOYMENT = QFD)
QFD sebagai perkenalan :
  • 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 :
  1. 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.
  2. 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
  3. 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.
 GAMBARAN KONSEP QFD :
  • Penyebaran fungsi, menentukan nilai (seperti yang diharapkan pelanggan) dari setiap fungsi yang dibutuhkan oleh system.
  • Penyebaran informasi, mengidentifikasi objek data dan kejadian
  • Penyebaran tugas, yang melatih kebiasaan dari system
  • Analisa nilai, menetapkan prioritas relative kebutuhan
RANGKUMAN
  • Analisis persyaratan adalah langkah teknis pertama pada proses rekayasa perangkat lunak
  • Analisis harus berfokus pada domain informasi, fungsional dan tingkah laku dari masalah
  • Dalam beberapa kasus tidaklah mungkin untuk secara lengkap memspesifikasi suatu masalah pada tahap awal
  • Spesifikasi persyaratan perangkat lunak dikembangkan sebagai akibat dari analisis

Rekayasa Sistem (System Engineering)

Rekayasa Perangkat Lunak terjadi :

  • Sebagai konsekuensi dari suatu proses yang disebut rekayasa system.
Rekayasa sistem berfokus pada :

  • Variasi elemen-elemen, analisa, rancangan dan mengelola elemen-elemen tersebut kedalam sistem yang dapat berbentuk produk, layanan (service) atau teknologi untuk transformasi informasi atau control
Proses rekayasa system :

  • Disebut rekayasa informasi bila konteks kerja rekayasa berfokus pada perusahaan bisnis.
  • Pada saat produk akan dibuat, proses ini disebut rekayasa produk.
Baik rekayasa informasi maupun rekayasa produk :

  • Cenderung untuk membawa orde kepada pengembangan sistem berbasis komputer.



SISTEM BERBASIS KOMPUTER
Kata sistem banyak digunakan (misal sistem politik, sistem pendidikan, sistem penerbangan).
Menurut Webster, definisi system berbasis computer adalah sebagai :
“Serangkaian atau tatanan elemen-elemen yang diatur untuk mencapai tujuan yang ditentukan sebelumnya melalui pemrosesan informasi”


Elemen Sistem Yang Digunakan :
  • Perangkat lunak. Program computer, struktur data dan dokumen yang berhubungan yang berfungsi untuk mempengaruhi metode logis, prosedur dan control yang dibutuhkan.
  • Perangkat keras. Perangkat elektronik yang memberikan kemampuan perhitungan dan perangkat elektromekanik (misalnya sensor, rotor, pompa) yang memberikan fungsi dunia eksternal
  • Manusia. Pemakai dan operator perangkat keras dan perangkat lunak.
  • Database. Kumpulan informasi yang besar dan terorganisasi yang di akses melalui perangkat lunak.
  • Dokumentasi. Manual, formulir dan informasi deskriptif lainnya yang menggambarkan penggunaan atau pengoperasian system.
  • Prosedur. Langkah-langkah yang menentukan penggunaan khusus dari masing-masing elemen system atau konteks procedural dimana system berada.
PEMODELAN SISTEM
  1. Asumsi : yang mengurangi jumlah permutasi dan variasi yang mungkin sehingga memungkinkan sebuah model mencerminkan masalah dengan cara yang dapat dipertanggung jawabkan.
  2. Penyederhanaan : yang memungkinkan model diciptakan dengan waktu yang tepat
  3. Pembatasan : yang membantu membatasi system
  4. Batasan : yang menunjukkan cara dimana model diciptakan dan pendekatan dilakukan pada saat model diimplementasikan.
  5. Preferensi : yang menunjukkan arsitektur yang dipilih untuk semua data, fungsi dan teknologi.
REKAYASA PROSES BISNIS / INFORMASI

Tujuan dari rekayasa proses bisnis / informasi (information engineering) adalah untuk mendefinisikan / menentukan arsitektur yang memungkinkan suatu bisnis dapat memanfaatkan informasi secara efektif. Rekayasa informasi juga bekerja untuk membuat suatu rencana menyeluruh guna mengimplementasikan arsitektur-arsitektur tersebut. Ada tiga arsitektur berbeda yang harus dianalisis dan dirancang dalam konteks sasaran dan tujuan bisnis yaitu :
  1. Arsitektur Data
  2. Arsitektur Aplikasi
  3. Arsitektur Teknologi
REKAYASA PROSES BISNIS (BUSINESS PROCESS ENGINEERING = BPE)
  • Menggunakan sekumpulan prosedur yang terpadu, metode dan alat bantu untuk mengidentifikasi bagaimana system informasi dapat sesuai dengan tujuan strategis perusahaan.
  • Perhatian utama adalah kepada tujuan perusahaan dan setelah itu ke area bisnis
  • Menciptakan model perusahaan, model data dan model proses
  • Membuat suatu kerangka kerja yang lebih baik untuk distribusi dan pengawasan manajemen informasi.
HIRARKI BPE
Ada 4 hirarki dalam BPE yaitu :

  1. Perencanaan Strategi Informasi (Information Strategy Planning = ISP)
  2. Analisis Area Bisnis (Business Area Analysis = BAA)
  3. Rekayasa Aplikasi
  4. Konstruksi dan Pengiriman (delivery)
PERENCANAAN STRATEGI INFORMASI
Langkah pertama rekayasa informasi adalah perencanaan strategi informasi (ISP) dan sasaran keseluruhan  dari ISP adalah :
  • Menentukan sasaran dan tujuan bisnis strategis
  • Mengisolasi faktor sukses kritis yang memungkinkan bisnis mencapai tujuan-tujuan dan sasaran tersebut
  • Menganalisis pengaruh teknologi dan otomatisasi terhadap tujuan dan sasaran
  • Menganalisis informasi yang ada untuk menentukan perannya dalam pencapaian sasaran dan tujuan

KONSTRUKSI DAN INTEGRASI
Fokus terhadap rincian implementasi
Contoh kasusnya seperti : membangun database yang tepat, membangun aplikasi yang menggunakan komponen perangkat lunak, memilih elemen yang tepat dari infrastruktur teknologi untuk mendukung rancangan selama proses rancangan system bisnis (BSD)


REKAYASA PRODUK
Tujuan Rekayasa Produk adalah untuk menerjemahkan keinginan pelanggan dengan serang kaian kemampuan yang terbatas kedalam produk yang sedang bekerja.


ANALISIS SISTEM
Analisis system dilakukan dengan sasaran sebagai berikut :
  1. Mengidentifikasi kebutuhan pelanggan
  2. Mengevaluasi konsep system untuk feasibilitas
  3. Melakukan analisis teknis dan ekonomis
  4. Mengalokasikan fungsi-fungsi untuk perangkat keras, perangkat lunak, manusia, database dan elemen system yang lain
  5. Membuat batasan biaya dan jadual
  6. Menciptakan definisi system yang membentuk fondasi bagi semua kerja rekayasa tingkat berikut, baik keahlian perangakt keras maupun perangkat lunak

STUDI KELAYAKAN
  1. Kelayakan ekonomis
  2. Kelayakan teknis
  3. Kelayakan legal
  4. Alternatif

KEUNTUNGAN YANG MUNGKIN DARI (REKAYASA) SISTEM INFORMASI :
1.    Keuntungan dari konstribusi tugas kalkulasi dan pencetakan
2.    Keuntungan dari konstribusi pada tugas-tugas pemeliharaan record
3.    Keuntungan dari konstribusi tugas pencarian record
4.    Keuntungan dari konstribusi kapabilitas menstruktur ulang system
5.    Keuntungan dari konstribusi analisis dan simulasi kapabilitas
6.    Keuntungan dari konstribusi pada control proses dan sumber daya
  
      BIAYA-BIAYA YANG MUNGKIN DARI (REKAYASA) SISTEM INFORMASI
1.    Biaya-biaya usaha, seperti biaya konsultasi, beli peralatan, instalasi, modifikasi tempat
2.    Biaya awal seperti software system operasi, instalasi peralatan komunikasi, biaya sewa
3.  Biaya (yang berhubungan dengan) proyek, seperti pembelian software aplikasi, modifikasi software, pelatihan, dokumentasi
4.  Biaya rutin, seperti biaya pemeliharaan, biaya listrik, telepon, biaya depresiasi




Kamis, 06 Juni 2013

Prinsip Tugas Pareto Dalam Implementasi RPL

PENGUJIAN PERANGKAT LUNAK

Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.
Sasaran pengujian perangkat lunak :

  1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan.
  2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum ditemukan pernah sebelumnya.
  3. Pengujian yang sukses adalah yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya.
Prinsip Pengujian :

  1. Semua pengujian harus dapat ditelusuri hingga ke persyaratan pelanggan.Sebagai tujuan utama pengujian perangkat lunak yaitu untuk mengungkap kesalahan. Yang mana berarti kesalahan paling fatal apabila perangkat lunak tidak dapat memenuhi syarat yang ditentukan oleh pelanggan.
  2. Pengujian harus direncanakan lama sebelum pengujian itu di mulai.Perencanaan pengujian dapat dimulai setelah model persyratan telah dilengkapi. Definisi detail tentang test case dapat di mulai segera setelah model desain di teguhkan. Dengan demikian pengujian dapat direncanakn dan dirancang sebelum pengkodean dilakukan.
  3. Prinsip Pareto berlaku untuk pengujian perangkat lunak.Prinsip Pareto mengimplikasikan bahwa 80% dari semua kesalahan yang ditemukan selama pengujian, hanya dapat ditelusuri 20% dari semua modul program. Hanya saja kita sulit untuk mengetahui modul yang mengalami kesalahan dan mengujinya dengan teliti
  4. Pengujian harus mulai “dari yang terkecil” dan berkembang ke pengengujian “yang besar”.Pengujian biasanya dilakukan terhadapmodul program individual. Selagi pengujian berlangsung, maka seluruh modul yang terintegrasi lebih mudah di uji.
  5. Pengujian yang mendalam tidak mungkin.Jumlah jalur permutasi pada perangkat lunak sangat besar, oleh karena itu sulit untuk melakukan pengujian terhadap semua jalur skema pengujian. Akan tetapi setidaknya kita dapat mengetahui bahwa logika yang tertuang dalam perancangan perangkat lunak itu telah tepat dan memastikan semua kondisi telah teruji.
  6. Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent.Arti dari “Paling Efektif”  adalah pengujian yang memiliki peluang tertinggi untuk menemukan kesalahan. Perekayasa perangkat lunak yang membuat system bukanlah orang yang paling tepat untuk melakukan semua pengujian bagi perangkat lunak.
PRINSIP PARETO

Prinsip pareto (The Pareto principle) juga dikenal sebagai aturan 80-20 menyatakan bahwa untuk banyak kejadian, sekitar 80% daripada efeknya disebabkan oleh 20% dari penyebabnya. Prinsip ini diajukkan oleh pemikir manajemen bisnis Joseph M. Juran, yang menamakannya berdasarkan ekonom Italia Vilfredo Pareto (15 July 1848 – 19 August 1923), yang pada 1906 mengamati bahwa 80% dari pendapatan di Italia dimiliki oleh 20% dari jumlah populasi.

Dalam implementasinya, prisip 80/20 ini dapat diterapkan untuk hampir semua hal :

  • 80% dari keluhan pelanggan muncul dari 20% dari produk atau jasa.
  • 80% dari keterlambatan jadwal timbul dari 20% dari kemungkinan penyebab penundaan.
  • 20% dari produk atau jasa mencapai 80% dari keuntungan.
  • 20% dari tenaga penjualan memproduksi 80% dari pendapatan perusahaan.
  • 20% dari cacat sistem menyebabkan 80% masalah.

Prinsip Tugas Pareto Dalam Implementasi RPL

Dalam ilmu komputer dan teori kontrol rekayasa seperti untuk konverter energi elektromekanis, prinsip Pareto dapat diterapkan untuk upaya optimasi. Sebagai contoh, Microsoft mencatat bahwa dengan menetapkan atas 20% paling melaporkan bug, 80% dari kesalahan dan crash akan dihilangkan. Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program.

Dalam pengembangan perangkat lunak proses yang khas adalah bahwa pengumpulan persyaratan, persyaratan review, desain, desain review, coding, kode review, pengujian komponen, pengujian integrasi, rilis, dan pemeliharaan. Singkatnya, proyek mulai dengan satu set persyaratan, dan kemudian pergi melalui serangkaian perbaikan dimana spesifikasi asli dibandingkan dengan produk akhir untuk kelengkapan dan kebenaran dan terhadap penggunaan dunia nyata untuk perbaikan tambahan. Selama revisi, jika persyaratan dari proses pembangunan mengikuti distribusi Pareto, maka beberapa isu kunci akan menampakkan diri dan perlu ditangani pada setiap revisi baru. Persyaratan lama akan memudar, dan yang baru akan muncul dengan konteks mereka sendiri.

Praktis pengalaman memberitahu kita bahwa pada awal proyek perangkat lunak masalah tersebut mencakup isu-isu tersebut pada platform pilihan, bahasa implementasi, database model data, modus akses dan fungsi utama dari aplikasi. Seiring waktu, penyempurnaan lanjutan dapat memperkenalkan persyaratan yang membahas bagaimana aplikasi bekerja untuk kelompok tertentu pengguna, atau dalam konsep dengan aplikasi eksternal lainnya.

Pertambahan manfaat dalam open source :

Perancang sering menggunakan prinsip pareto dalam pengelolaan teknik desain dan pengembangan bahwa 80 % dari proyek mudah dibandingkan dengan yang 20 % terakhir. Lebih khusus lagi dalam proses formal prioritas persayaratan menggunakan analisis pareto, setiap persyaratan yang unik diberi peringkat sebagai persentase dari seluruh proyek. Kebutuhan individu tersebut kemudian disajikan dalam grafik batang dari yang paling signifikan. Perusahaan perangkat lunak seperti Microsoft memahami hal ini, dan desain untuk produk yang membahas 80 persen dari persyaratan, meninggalkan 20% terakhir sebagai kustomisasi oleh pengguna akhir. Sebagian besar aplikasi saat ini telah dirancang untuk mencakup beberapa bentuk penyesuaian atau diperpanjang termasuk pengaturan preferensi pengguna, bahasa scripting atau API untuk ekstensi kustom menggunakan bahasa yang lebih tradisional.

Manajemen Konfigurasi Perangkat Lunak

PENGERTIAN

Manajemen Konfigurasi Perangkat Lunak atau biasa disebut Software Configuration Management adalah serangkaian aktifitas penelusuran dan pengendalian yang dimulai ketika proyek berjalan sampai tidak dioperasikan lagi. Sebuah aktifitas untuk mengidentifikasi konfigurasi dari sebuah sistem dengan tujuan untuk mengontrol perubahan secara sistematik terhadap konfigurasi, pemeliharaan integritas dan pengulangan dari konfigurasi seluruhnya selama daur hidup sistem.
Konsep dari manajemen konfigurasi menggunakan semua item untuk di kontrol meskipun ada beberapa perbedaan antara manajemen konfigurasi perangkat keras dan perangkat lunak. Pada bagian ini kita akan menjelaskan sebuah perincian dari konsep-konsep manajemen konfigurasi perangkat lunak, dengan deskripsi yang jelas dari setiap konsep.
Aktifitas SCM antara lain :
  • Mengidentifikasi produk pekerjaan yang cenderung berubah
  • Membangun hubungan di antara mereka
  • Mendefinisikan mekanisme untuk mengelola versi yang berbeda dari produk kerja
  • Mengontrol perubahan
  • Audit & melaporkan perubahan yang dibuat
Baselines adalah sebuah konsep manajemen konfigurasi perangkat lunak yang membantu kita mengontrol perubahan tanpa harus secara serius mengganggu perubahan yang dapat dibenarkan.
Langkah-langkah perubahan dalam SCM, antara lain :
  • Kebutuhan akan perubahan diperbaiki
  • Permintaan perubahan dari pemakai
  • Pengembang mengevaluasi
  • Laporan perubahan dihasilkan
  • Otoritas kontrol perubahan membuat keputusan
AUDIT
Audit konfigurasi perangkat lunak melengkapi kajian teknis formal dengan menilai suatu objek konfigurasi untuk karakteristik yang secara umum tidak dipertimbangkan selama kajian.

RANGKUMAN
  • Manajemen konfigurasi perangkat lunak adalah aktivitas pelindung yang diterapkan pada seluruh proses perangkat lunak
  • SCM mengidentifikasi control, audit, dan modifikasi laporan, yang selalu terjadi pada saat perangkat lunak sedang dikembangkan dan setelah dilepas ke pelanggan
  • Semua informasi yang diproduksi sebagai bagian dari proses perangkat lunak menjadi bagian dari suatu konfigurasi perangkat lunak
  • Konfigurasi tersebut harus diorganisir dengan cara memungkinkan control perubahan secara teratur