PEMODELAN ANALISIS

Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang komprehensip bagi perangkat lunak yang dibangun.

1. Elemen Model Analisis
    Model analisis harus dapat mencapai tiga sasaran utama yakni untuk :
•  Menggambarkan apa yang dibutuhkan untuk pelanggan
•  Membangun dasar bagi pembuatan desain perangkat lunak
•  Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.

Untuk mencapai sasaran tersebut dibuatlah model analisis yang berisi:
•  Data Dictionary

   Penyimpanan yang berisi deskripsi dari semua obyek data yang dikonsumsi atau diproduksi oleh perangkat lunak.

•  Entity Relationship Diagram (ERD)
   Menggambarkan hubungan antara obyek data.
•  Data Flow Diagram (DFD)
   o Memberikan indikasi mengenai bagaiman data ditransformasi pada saat data bergerak melalui sistem
   o Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.
•  State Transition Diagram
   Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.
•  Control Specification (CSPEC)
   Informasi tambahan mengenai aspek kontrol dari perangkat lunak

- Pemodelan Data

    Pemodelan data merupakan sebuah tahapan dalam merancang sebuah sistem informasi. Pemodelan data berfokus pada data apa yang akan disimpan yang menggambarkan hubungan entara entiti set yang dibutuhkan oleh sebuah organisasi dalam pengelolaan data.
Untuk dapat menjawab tentang pemodelan data sebagai berikut : 

1. Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkab obyek tersebut?
2. Dimana obyek saat ini berada? 
3. Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya? 
4. Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya? Digunakan Entity Relational Diagram (ERD)  

1. Obyek Data, Atribut dan Hubungan 
Obyek Data Adalah representasi dari hamper semua informasi gabungan yang harus dipahami oleh perangkat lunak. Atribut Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang berbeda.
o Menamai sebuah contoh dari obyek data
o Menggambarkan contoh
o Membujat referensi ke contoh yang lain pada tabel yang lain.
Hubungan  Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara.
 

2. Kardinalitas dan Modalitas Kardinalitas
Model data harus dapat merepresentasikan jumlah peristiwa dari obyek di dalam hubungan yang diberikan

• Satu ke satu (1:1)  Misalnya: seorang suami hanya dapat memiliki satu istri, dan seorang istri hanya mempunyai satu suami
• Satu ke banyak (1:N) Misalnya: seorang ibu dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki satu ibu
• Banyak ke banyak (M:N) Misalnya: seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan dapat memiliki banyak paman

Modalitas  Modalitas dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan yang  terjadi atau hubungan itu bersifat opsional. Modalitas bernilai satu jika suatu kejadian dari hubungan merupakan perintah.

Entity Relational Diagram
Pada mulanya digunakan untuk desain sistem database relational dan telah dikembangkan oleh yang lainnya. Serangkaian komponen utama diidentifikasikan untuk ERD: obyek data, atribut, hubungan dan berbagai tipe indicator. Tujuan utama dari ERD adalah untuk mewakili obyek data dan hubungan mereka.

- Pemodelan Fungsional dan Aliran Informasi
  Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis komputer. Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output. Akibatnya kita dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan kompleksitasnya.

1. Diagram Aliran Data/ Data Flow Diagram (DFD)
Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang diaplikasikan pada saat data bergerak dari input menjadi output.   Dikenal juga dengan sebutan grafik aliran data atau buble chart.

Komponen-komponen DFD :

• Proses : menunjukkan apa yang dikerjakan oleh sistem. Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.  
• External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan input data ke dalam sistem atau digunakan oleh output sistem 
• Data Flow  adalah tempat penyimpanan data 
• Data Store  : Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store. Setiap data store mempunyai nama yang unik  External Entity  

Pemodelan Tingkah Laku :
Model prilaku menggambarkan bagaimana PL merespon event atau stimulan eksternal. Untuk model tersebut, anlisis harus melakukan langkah-langkah sebagai berikut :

• Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem.
• Mengenali event yang mengendalikan urutan interaksi dan memahami bagaimana event mempunyai relasi terhadap objek spesifik.
• Membuat urutan untuk setiap use-case.
• Membangun state diagram untuk sistem.
• Review model behavioral untuk memverifikasi akurasi dan konsistensi

4. Mekanik Dari Analisis Terstruktur
    Dalam konteks pemodelan perilaku, dua karakter keadaan harus diperhatikan:

• Keadaan setiap class ketika sistem menjalankan fungsinya, dan
• Keadaan sistem ketika diobservasi dari luarsebagaimana sistem menjalankan fungsinya.

Keadaan class mengambil baik karakter aktif maupun pasif [CHA93].

• Sebuah keadaan pasif adalah status saat ini dari semua atribut objek.
• Keadaan aktif dari sebuah objek menggambarkan status saat ini pada objek tersebut ketika menjalankan transformasi atau proses. 

5. Kamus Data

    Kamus data adalah suatu daftar data elemen yang terorganisir dengan definisi yang tetap dan sesuai dengan sistem, sehingga user dan analis sistem mempunyai pengertian yang sama tentang input, output, dan komponen data strore.    Kamus data ini sangat membantu analis sistem dalam mendefinisikan data yang mengalir di dalam sistem, sehingga pendefinisian data itu dapat dilakukan dengan lengkap dan terstruktur. Pembentukan kamus data dilaksanakan dalam tahap analisis dan perancangan suatu sistem.    Pada tahap analisis, kamus data merupakan alat komunikasi antara user dan analis sistem tentang data yang mengalir di dalam sistem, yaitu tentang data yang masuk ke sistem dan tentang informasi yang dibutuhkan oleh user. Sementara itu, pada tahap perancangan sistem kamus data digunakan untuk merancang input, laporan dan database.    Pembentukan kamus data didasarkan atas alur data yang terdapat pada DFD. Alur data pada DFD ini bersifat global, dalam arti hanya menunjukan nama alur datanya tanpa menunjukan struktur dari Metode Analisis Klasik.

-Model Proses Perangkat Lunak  Evolusioner

 Model evolusioner adalah model iteratif. Model itu ditandai dengan tingkah laku yang memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang lebih lengkap sedikit demi sedikit.
 

-Model Pertambahan

 Model inkremental menggabungkan elemen-elemen model sekuensial linier dengan filosofi prototipe iteratif. Pada saat model pertambahan dipergunakan, pertambahan pertama sering merupakan produk inti (core product), yaitu sebuah model pertambahan yang dipergunakan, tetapi beberapa muka tambahan tetap tidak disampaikan. Produk inti tersebut dipergunakan oleh pelanggan (atau mengalami pengkajian lebih detail). Sebagai hasil dari pemakaian dan/atau evaluasi, maka dikembangkan rencana bagi pertambahan selanjutnya. Rencana tersebut menekankan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsionalitas tambahan. Proses ini diulang mengikuti penyampaian setiap pertambahan sampai bisa menghasilkan produk yang lengkap.
Model proses pertambahan tersebut, seperti model prototipe dan pendekatan-pendekatan evolusioner yang lain, bersifat iteratif. Tetapi tidak seperti model prototipe, model pertambahan berfokus pada penyampaian produk operasional dalam setiap pertambahannya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.
 

- Model Spiral
  Model spiral yang pada awalnya diusulkan oleh Boehm adalah model proses perangkat lunak yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model itu berpotensi untuk pengambangan versi pertambahan perangkat lunak secara cepat.

• Model spiral dibagi menjadi sejumlah aktivitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas. Gambar 2.8. menggambarkan model spiral yang berisi enam wilayah tugas : Komunikasi pelanggan – tugas-tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antara pengembang dan pelanggan
• Perencanaan – tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
• Analisis risiko – tugas-tugas yang dibutuhkan untuk menaksir risiko-risiko, baik manajemen maupun teknis.
• Perekayasa – tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut
• Konstruksi dan peluncuran – tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (install) dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).
• Evaluasi pelanggan – tugas-tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama masa perekayasaan, dan diimplementasikan selama masa pemasangan.

Ketika proses evolusioner ini mulai, tim rekayasa perangkat lunak bergerak searah jarum mengelilingi spiral tersebut dengan dimulai intinya. Lintasan pertama putaran spiral menghasilkan perkembangan dari spesifikasi produk; putaran spiral selanjutnya mungkin dipakai untuk mengembangkan sebuah prototipe, dan secara progresif mengembangkan versi perangkat lunak yang lebih canggih.
Tidak seperti model proses klasik yang berakhir pada saat perangkat lunak sudah disampaikan, model spiral bisa disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
Model spiral menjadi sebuah pendekatan yang realistis bagi perkembangan sistem dan perangkat lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak, pengembang dan pemakai memahami dan bereaksi lebih baik terhadap risiko dari setiap tingkat evolusioner. Model spiral menggunakan prototipe sebagai mekanisme pengurangan risiko.

- Model Rakitan Komponen
  Model rakitan komponen menggabungkan beberapa karakteristik model spiral. Model ini bersifat evolusioner, sehingga membutuhkan pendekatan iteratif untuk menciptakan perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan (kadang-kadang disebut “kelas”).
Model rakitan komponen membawa kepada penggunaan kembali perangkat lunak, dan kegunaan kembali tersebut memberi sejumlah keuntungan yang bisa diukur pada perekayasa perangkat lunak.

- Model perkembangan Konkuren
  Model proses konkuren sering digunakan sebagai paradigma bagi pengembangan aplikasi klien/server. Sistem klien/server dirancang dari serangkaian komponen fungsional. Bila diaplikasikan kepada klien/server, model proses konkuren akan mendefinisikan aktivitas di dalam dua dimensi : dimensi sistem, dan dimensi komponen. Isu tingkat sistem ditujudengan menggunakan tiga aktivitas : desain, assembly, dan pemakaian. Dimensi komponen dituju dengan dua aktivitas : desain dan rea-lisasi. Konkuren dicapai dengan dua cara :

1. aktivitas sistem dan komponen yang berlangsung secara simultan dan dapat dimodelkan dengan menggunakan pendekatan orientasi keadaan yang digambarkan di atas;
2. aplikasi klien/server khusus diimplementasikan dengan banyak komponen di mana masing-masing bisa dirancang dan direalisasikan secara konkuren.

Kenyataannya model proses konkuren bisa diaplikasikan ke dalam semua tipe perkembangan perangkat lunak, dan memberikan gambaran akurat mengenai keadaan tertentu dari sebuah proyek.

 Overview Mengenai Metode Analisis Klasik

Data Structured Systems Development

Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data.

Jackson System Development

Jackson System Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang analisis domain informasi dan hubungannya dengan desain system dan program. 

SADT

Structured analysis and design technique (SADT) adalah sebuah teknik yang telah digunakan secara luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis persyaratan perangkat lunak dan desaign system /perangkat lunak.

- See more at: http://imaagusti.blogspot.co.id/2013/03/pemodelan-analisis_8.html#sthash.Bja7VZgu.dpuf

 Overview Mengenai Metode Analisis Klasik

Data Structured Systems Development

Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data.

Jackson System Development

Jackson System Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang analisis domain informasi dan hubungannya dengan desain system dan program. 

SADT

Structured analysis and design technique (SADT) adalah sebuah teknik yang telah digunakan secara luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis persyaratan perangkat lunak dan desaign system /perangkat lunak.

- See more at: http://imaagusti.blogspot.co.id/2013/03/pemodelan-analisis_8.html#sthash.Bja7VZgu.dpuf

6. Overview Mengenai Metode Analisis Klasik

- Data Structured Systems Development

  Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data.

- Jackson System Development

  Jackson System Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang analisis domain informasi dan hubungannya dengan desain system dan program. 

- SADT

  Structured analysis and design technique (SADT) adalah sebuah teknik yang telah digunakan secara luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis persyaratan perangkat lunak dan desaign system /perangkat lunak.

 Overview Mengenai Metode Analisis Klasik

 Overview Mengenai Metode Analisis Klasik

Data Structured Systems Development

Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data.

Jackson System Development

Jackson System Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang analisis domain informasi dan hubungannya dengan desain system dan program. 

SADT

Structured analysis and design technique (SADT) adalah sebuah teknik yang telah digunakan secara luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis persyaratan perangkat lunak dan desaign system /perangkat lunak.

- See more at: http://imaagusti.blogspot.co.id/2013/03/pemodelan-analisis_8.html#sthash.Bja7VZgu.dpuf

Sumber:

-http://putriptiwi.blogspot.co.id/2013/06/prinsip-dan-konsep-analisa.html

-http://imaagusti.blogspot.co.id/2013/03/pemodelan-analisis_8.html

-http://hendriipunj.blogspot.co.id/2012/06/pemodelan-analisis-pembahsan-pada.html

Read More

PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES)

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 PERSYARATANAnalisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi perangkat lunak tingkat system dan perancangan perangkat lunak seperti terlihat pada gambar 11.1







Gambar 11.1 Analisis dan kesenjangan antara rekayasa system dan desain perangkat lunak


Analisis persyaratan perangkat lunak dapat dibagi menjadi 5 (lima) area kerja yaitu :

1. 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

2. 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

3. Pemodelan

Menyiapkan system dalam ukuran yang kecil-kecil sebelum penerapan dengan system yang sebenarnya

4. Spesifikasi

Menetapkan system dalam kondisi yang sebenarnya

5. Kajian

Melakukan evaluasi dan pengujian formal terhadap penerapan yang telah dilakukan apakah sasaran yang yang ditetapkan tercapai atau tidak.


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”

MENGAWALI PROSES

• Untuk menjembatani jurang / lobang-lobang komunikasi antara pelanggan dan pengembang, sekaligus untuk memulai proses komunikasi, perlu dilakukan pertemuan pendahuluan atau wawancara

•  Harus dimulai dengan pertanyaan-pertanyaan yang bebas konteks :

o   Siapa dibalik permintaan untuk pekerjaan ini ?o   Siapa yang akan menggunakan pemecahan ini ?o   Apa keuntungan ekonomi dari pemecahan yang berhasil ?o   Apakah ada sumber lain untuk pemecahan yang anda inginkan ?

• Dilanjutkan dengan pertanyaan agar seorang analis mendapat pemahaman yang lebih baik akan mengenai masalah dari pelanggan

o   Bagaimana anda akan menandai output yang baik ?o   Masalah apa yang akan diselesaikan oleh pemecahan ini ?o   Dapatkah anda memperlihatkan kepada saya (atau menjelaskan) lingku ngan dimana pemecahan tersebut akan digunakan ?o   Apakah masalah atau batasan kinerja yang khusus yang akan mempenga ruhi cara pemecahan tersebut didekati ?

•  Diakhiri dengan pertanyaan yang berfokus pada efektivitas pertemuan

o   Apakah anda adalah orang yang tepat untuk menjawab pertanyaan-pertanyaan ini ? dan apakah jawaban anda bersifat resmi ?o   Apakah pertanyaan saya ini relevan dengan masalah yang anda hadapi ?o   Apakah anda mengajukan terlalu banyak pertanyaan ?o   Apakah ada orang lain yang dapat memberikan informasi tambahan ?o   Apakah ada hal lain yang harus saya tanyakan kepada anda ?
FAST (Facilitated Application Specification Techniques)TENTANG FASTMemacu 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

Banyak pendekatan yang digunakan dan masing-masing pendekatan menggunakan scenario yang berbeda, namun semuanya menerapkan variasi tuntunan dasar berikut ini:

•   Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan

•   Aturan main untuk persiapan dan partisipasi dibuat

•    Perlunya agenda

•   Perlunya seorang fasilitator

•  Harus adanya mekanisme definisi

PANDUAN FASTJ. 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.

1. 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

1. 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

ANALISA PROSES SECARA UMUM

Add caption

 

PRINSIP ANALISA 1Data Domain Model :

• Menetapkan objek data

• Menggambarkan atribut data

• Menetapkan hubungan data

PRINSIP ANALISA 2Fungsi Model :

•   Mengidentifikasi fungsi yang (dapat) merubah objek data

•   Mengindikasikan berapa data yang melalui system

•  Mewakili data produsen dan konsumen

PRINSIP ANALISA 3Model Kebiasaan :

•  Mengindikasikan states yang berbeda dari system

•    Menetapkan kejadian yang mungkin menyebabkan perubahan pada state

PRINSIP ANALISA 4Partisi Model :

•   Menyaring setiap model untuk mewakili level yang lebih rendah dari abstraksi

o   Menyaring objek datao   Membuat hirarki fungsio   Mewakili kebiasaan pada tingkatan yang berbeda tiap detil

•   Membuat partisi horizontal dan vertikal

PRINSIP ANALISA 5 :Intisari :

• Memulai focus intisari masalah tanpa memperhatikan rincian implementasi

BEBERAPA PRINSIP YANG DIKEMUKAKAN DAVIS :

• Mengerti masalah sebelum kita memulai menciptakan model analisa

• Membangun protipe yang memungkinkan pelanggan untuk mengerti bagaimana pelanggan mengerti interaksi manusia dan mesin dapat terjadi

• Mencatat hal-hal yang baru dan alasan untuk setiap kebutuhan

• Menggunakan gambaran bertingkat setiap kebutuhan

•  Memprioritaskan kebutuhan

• Bekerja untuk menghilangkan keragu-raguan

MODEL ANALISA :

BEHAVIORAL MODEL

KAJIAN SPESIFIKASI : Kajian dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh pelanggan maupun pengembang perangkat lunak dan harus dilakukan dengan sangat hati-hati.Kajian ini akan memastikan bahwa spesifikasi sudah lengkap, konsisten dan akurat. Untuk itu, pertanyaan-pertanyaan di bawah ini dapat diajukan :

•  Apakah tujuan dan sasaran yang dinyatakan bagi perangkat lunak tetap konsisten dengan tujuan dan sasaran system ?

• Apakah interface penting ke semua elemen system sudah digambarkan ?

•  Apakan aliran informasi dan struktur didefinisikan dengan tepat bagi domain masalah ?

• Apakah diagram jelas ? dapatkah masing-masing berdiri sendiri tanpa teks pendamping ?

•   Apakah fungsi mayor tetap ada dalam ruang lingkup, dan sudahkan digambarkan dengan tepat ?

• Apaka tingkah laku perangkat lunak konsisten dengan informasi yang harus diprosesnya dengan fungsi yang harus dilakukannya /

• Apakah batasan desain realistis ?

•  Apakah resiko teknologis pengembangan sudah dipertimbangkan ?

•  Apakah criteria validasi dinyatakan secara detail ? Apakah criteria itu tepat untuk menggambarkan sebuah system yang berhasil ?

•   Apakah ada inkonsistensi, penghilangan atau redundancy ?

• Apakah kontak dengan pelanggan sudah lengkap ?

• Apakah pemakai sudah mengkaji manual pemakai permulaan atau prototype ?

• Bagaimana estimasi perencanaan mempengaruhi ?

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

• Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.

• Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas

• Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE

• Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak

• Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.

• Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga

• Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan

• Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

Model

• Pendekatan Waterfall

• Pengembangan secara evolusioner

• Transformasi formal

• Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali.

Waterfall

• Penentuan dan analisis spesifikasi

• Desain sistem dan perangkat lunak

• Implementasi dan ujicoba unit

• Integrasi dan ujicoba sistem

• Operasi dan pemeliharaan

Pengembangan Evolusioner

• Proses tidak visibel.

• Sistem-sistem biasanya kurang terstruktur

• Ketrampilan khusus jarang dimiliki

Read More