REKAYASA PERANGKAT LUNAK - ESTIMATE TASK DURATIONS

Perkiraan Pembuatan Project ( Estimate Task Durations)

untuk melakukan perencanaan sebuah program yang akan dirancang pada sebuah perusahaan harus terkoordinir agar tercapainya titik maksimal dalam pengaplikasian sebuah system, adapun tahapan-tahapan Teknik memperkirakan durasi tersebut dapat dilakukan dengan salah satu teknik Estimasi Perencanaan System sebagai berikut :

1.      Optimistic Duration (OD) : perkiraan lama minimum waktu yang diperlukan untuk melakukan tugas.

2.       Pessimistic Duration (PD) : perkiraan lama maksimum waktu yang diperlukan untuk melakukan tugas.

3.       Expected Duration (ED) : lama perkiraan waktu yang diperlukan untuk menyelesaikan sebuah tugas.

4.       Most Likely Duration (D) : lama perkiraan waktu yang diperlukan untuk menyelesaikan sebuah tugas, berdasarkan nilai rata-rata optimistic, pessimistic, dan expected duration (durasi optimistis, pesimistis, dan diharapkan)

1.      JUDUL : SISTEM INFORMASI ABSENSI ONLINE PT Persero Batam  

2.       Pelaksanaan pembuatan aplikasi ini kurang lebih membutuhkan waktu 3 bulan.

3.       B. Tahap Pelaksanaan

Penjelasan Estimasi :

1 bulan = 24 hari efektif

1.       Optimistic duration (OD) : 60 days

2.       Pessimistic duration (PD) : 96 days

3.       Expected duration (ED) : 72 days

4.       Most likely duration (D) : 86 days

Rekayasa Perangkat Lunak

Hari ini Kamis 28 April 2016

Saya melampirkan Tugas matakuliah "Rekayasa Perangkat Lunak"

Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering  dan  software project planning. 

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.

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.

Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya semua metode analisis memiliki prinsip analisis yang sama, yaitu : 

-       Menggambarkan domain informasi masalah

-       Mendefinisikan fungsi perangkat lunak

-       Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang  dibagi secara rinci pada sebuah model lapisan (hirarki)

-       Informasi pokok pada tahap analisis memudahkan tahap implementasi yang lebih rinci.

Tujuan tahap analisis adalah : 

-       Menjabarkan kebutuhan pemakai

-       Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak

-       Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna).

Konsep dan Prinsip Analisis

-       Analisis Kebutuhan Perangkat Analisis

-       Teknik Komunikasi

-       Prinsip-prinsip Analisis

-       Prototyping Perangkat Lunak

PRINSIP DAN KONSEP ANALISA

(ANALYSIS CONCEPT AND PRINCIPLES)

A.   PEMAHAMAN PRINSIP DAN KONSEP ANALISA

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)

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.

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.

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

Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis.

-       Detail

Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci.

-       Benar.

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 :

-       Identifikasi Masalah

-       Evaluasi dan sintesis

-       Pemodelan

-       Spesifikasi

-       Review

Tujuan Analisis Kebutuhan

Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai berikut :

-       Mengelola hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi kebutuhan yang isi keseluruhannya sesuai dengan apa yang diinginkan pengguna                                (Liu and Yen, 1996).

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

-       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 aktifitas. Tahapan aktivitas tersebut dijelaskan sebagai berikut ;

1.    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, aktifitas analisis dibutuhkan dalam setiap proses dalam daur hidup pengembangan perangkat lunak. Didalam proses rekayasa kebutuhan, analisis pun dilakukan dalam setiap aktifitas aktifitasnya. Penjelasan dari masing masing aktifitas tersebut.

-       Domain Understanding, dalam tahap ini perekayasa kebutuhan perangkat lunak harus mengetahui bagaimana organisasi perusahaan beroperasi dan apa yang menjadi permasalahan pada sistem yang sedang berajalan pada saat ini. Perekayasaan perlu memfokuskan kepada ‘Apa’ yang menjadi permasalahan. Perekayasaan hendaknya tidak berhenti pada menemukan “gejala” dari permasalahan itu terjadi untuk menemukan akar dari permasalahan dari sistem yang 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 daling berkaitan dikelompokan, baik menurut kelas penggunaannya maupun jenis kebutuhannya. Kebutuhan kebutuhan tersebut diorganisasikan kedalam kelompok kelompok yang koheren. Perekayasaan perlu memisahkan antara kebutuhan dan keinginan dari pengguna

-       Conflict Resolution, Pada tahapan ini adalah menemukan dan menyelesaikan kebutuhan yang didalamnya terdapat konflik.

-       Priritisation, Pada tahapan ini dilakukan interkasi dengan pemangku kepentingan untuk mengidentifikasikan kebutuhan kebutuhan prioritas dari masing masing kebutuhan agar sumber daya yang tersedia pada organisasi dialokasikan untuk mengimplementasikan kebutuhan yang terutama dari pemangku kepentingan.

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

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 dibawah ini

Gambar  Analisis dan kesenjangan antara rekayasa system dan desain perangkat lunak

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

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

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

C.   Pemodelan

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

D.   Spesifikasi

Menetapkan system dalam kondisi yang sebenarnya

E.   Kajian

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

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

a.    Siapa dibalik permintaan untuk pekerjaan ini ?

b.    Siapa yang akan menggunakan pemecahan ini ?

c.    Apa keuntungan ekonomi dari pemecahan yang berhasil ?

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

a.    Bagaimana anda akan menandai output yang baik ?

b.    Masalah apa yang akan diselesaikan oleh pemecahan ini ?

c.    Dapatkah anda memperlihatkan kepada saya (atau menjelaskan) lingku ngan dimana pemecahan tersebut akan digunakan ?

d.    Apakah masalah atau batasan kinerja yang khusus yang akan mempenga ruhi cara pemecahan tersebut didekati ?

-       Diakhiri dengan pertanyaan yang berfokus pada efektivitas pertemuan

a.    Apakah anda adalah orang yang tepat untuk menjawab pertanyaan-pertanyaan ini ? dan apakah jawaban anda bersifat resmi ?

b.    Apakah pertanyaan saya ini relevan dengan masalah yang anda hadapi ?

c.    Apakah anda mengajukan terlalu banyak pertanyaan ?

d.    Apakah ada orang lain yang dapat memberikan informasi tambahan ?

e.    Apakah ada hal lain yang harus saya tanyakan kepada anda ?

FAST (Facilitated Application Specification Techniques)

TENTANG 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

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 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 :

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

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

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

3.    PRINSIP PRINSIP ANALISIS

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 harus dipecah pecahkan ke dalam tingkat yang lebih rinci dalam bentuk lapisan (atau hierarki).

5.    Proses analisis harus dimulai dari informasi dasar menuju implementasi rinci.

PRINSIP ANALISA 1

Data Domain Model :

-       Menetapkan objek data

-       Menggambarkan atribut data

-       Menetapkan hubungan data

PRINSIP ANALISA 2

Fungsi Model :

-       Mengidentifikasi fungsi yang (dapat) merubah objek data

-       Mengindikasikan berapa data yang melalui system

-       Mewakili data produsen dan konsumen

PRINSIP ANALISA 3

Model Kebiasaan :

-       Mengindikasikan states yang berbeda dari system

-       Menetapkan kejadian yang mungkin menyebabkan perubahan pada state

PRINSIP ANALISA 4

Partisi Model :

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

a.    Menyaring objek data

b.    Membuat hirarki fungsi

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

4.    PROTOTYPING PERANGKAT LUNAK

APA ITU PROTOTYPING MODEL? Prototyping Model adalah metode proses pembuatan sistem yang dibuat secara terstruktur dan memiliki beberapa tahap-tahap yang harus dilalui pada pembuatannya, namun jika tahap final dinyatakan bahwa sistem yang telah dibuat belum sempurna atau masih memiliki kekurangan, maka sistem akan dievaluasi kembali dan akan melalui proses dari awal. Prototyping Model juga dapat diartikan sebagai pembuatan sistem atau software dengan metode siklus. Dalam metode prototyping model sendiri memiliki 5 tahap, yaitu:

Tahap I                 : Deployment       Pada Tahap ini, customer atau user yang ingin membuat sebuah sistem datang kepada pengembang sistem untuk meminta dibuatkan sebuah sistem dengan menginformasikan beberapa kebutuhan sistem.

Tahap II           : Comunication Selanjutnya, pada tahap ini pengembang software mengkomunikasikan kepada pembuat spftware bahwa si user ingin membuat sebuah software yang memiliki kemampuan sesuai yang diinginkan user.

Tahap III           : Planning       Pada tahap planning, pembuat user merencanakan atau membuat perencanaan mengenai apa yang ingin dibuat dan apa saja kebutuhannya sistem yang diinginkan si user tersebut.

Tahap IV              : Modeling        Setelah melakukan planning, maka sang pembuat software/sistem melakukan perancangan model, contohnya model form awal atau log in usernya, maupun perancangan model form-form selanjutnya.

Tahap V                : Construction Tahap construction merupakan tahap akhir dalam prototyping model, disini pembuat software melakukan pengkodingan sesuai dengan perangcangan model dari suatu sistem yang ingin dibuat.

BAGAIMANA SIH METODE PROTOTYPING MODEL ??

Berikut ini merupakan tahapan-tahapan prototyping model:

-       Pengumpulan Kebutuhan     Pada tahappengumpulan kebutuhan, costumer memaparkan apa saja yang dibutuhkan dalam sistem yang       akan dibuat.

-       Membangun Prototyping     Pada tahap pembangunan prototyping, pengembang dan pembuat sistem bersama-sama membuat format       input maupun  output yang akan dihasilkan oleh sistem yang dibuat.

-       Evaluasi Prototyping     Selanjutnya, setelah tahap pembangunan prototyping, prototype yang telah dirancang akan dievaluasi             untuk dkerjakan pada tahap selanjutnya.

-       Mengkodekan System     Pada tahap ini, sistem yang ingin dibuat akan dibuatkan kedalam bahasa pemograman baik pascal, visual       basic, php, dan sebagainya.

-       Menguji System     Pada tahap prngujian system, koding yang telah dibuat sebelumnya akan diuji apakah dapat berjalan             dengan baik ataukan masih ada bagian-bagian yang perlu diperbaiki atau apakah masih ada bagian yang       belum sesuai dengan keinginan pelanggan.

-       Evaluasi System     Evaluasi system bukanlah evaluasi prototyping, evaluasi system adalah mengevaluasi system atau                   perangkat lunak yang sudah jadi apakah sudah sesuai dengan keinginan pelanggan atau belum. Jika belum,     maka system akan direvisi kembali dan kembali ketahap 4 dan 5. Jika system sudah dikatakan OK maka     system siap dilanjutkan pada tahap selanjutnya.

-       Menggunakan System     Tahap ini merupakan tahap akhir dari pembuatan system dengan metode Prototyping Model. Pada tahap       ini perangkat lunak yang sudah jadi dan sudah lulus uji, siap untuk  digunakan oleh pelanggan/user.

Dalam metode pembuatan sistem, pastinya memiliki tujuannya masing-masing. Nah, tujuan dari prototyping model ini adalah untuk membuat sistem lebih baik dan sistem akan lebih mudah dikembangkan jika menggunakan prototyping model.

Metode-metode proses pembuatan software, memiliki kekurangan dan kelebihannya masing-masing. Kekurangan dan kelebihan metode Prototyping Model adalah pembuatan software dapat dilakukan dengan lebih baik oleh pengembang sesuai dengan kebutuhan pelanggan/user dan juga dapat memudahkan dalam mengembangkan software yang sudah dibuat. Namun, Prototyping juga memilki kekurangan yaitu, jika pelanggan/user ingin agar waktu penyelesaian software cepat maka software yang dihasilkanpun akan jadi secara asal-asalan. Dengan kata lain, butuh waktu yang lama dalam pengerjaan software menggunakan metode prototyping model.

Untuk menyelesaikan permasalahan dalam menanggulangi kekurangan pembuatan software menggunakan prototyping model saya ingin berbagi solusinya. Solusinya adalah costumer harus lebih cermat dalam mengevaluasi sistem dan mencoba sistem agar tidak ada kesalahan yang dapat ditutupi oleh pengembang dan pembuat software.

Make Money Online : http://ow.ly/KNICZ

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.

Pemodelan analisys terbagi 6

1.    Elemen Model analisis

2.    Pemodelan Data

3.    Pemodelan Fungsional dan aliran informasi

4.    Mekanik dari analisys terstruktur

5.    Kamus Data

6.    Overview mengenai metode analisis

Pemodelan

Pemodelan Analisis
Pembahasan 

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)
a. Memberikan indikasi mengenai bagaiman data ditransformasi pada saat data bergerak melalui sistem

b. Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.

c. State Transition Diagram

   Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.
d. Control Specification (CSPEC)
   Informasi tambahan mengenai aspek kontrol dari perangkat lunak

2.    Pemodelan Data

            Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan. Model analisis sebenarnya merupakan serangkaian model  yang merupakan representasi teknis yang pertama dari system. Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan.

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini.

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

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

            Tetapi pada saat ini ada dua landskap pemodelan analisis. Yaitu yang pertama analisis terstrutur  adalah metode pemodelan klasik. Dimana analisis terstruktur ini merupakan aktifitas pembangunan model.  Dan yang kedua adalah analisis berorientasi Objek . Tetapi pada makalah ini yang dijelaskan adalah  Tinjauan singkat terhadap metode analisis yang umum digunakan. Untuk menciptakan model yang menggambarkan muatan dan aliran informasi (data dan kontrol).

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

• Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak, uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya.

• Pengembangan secara evolusioner

Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable.

• Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi.

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

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.

Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner, saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.

Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

• Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

• Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan.

• Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

• Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke kastamer

• Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.

Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini

1. Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2. Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti.

Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

• Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.

• Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

• Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.

Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk

Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan, tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya.

Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

PEMODELAN DATA

            Pemodelan data menjawab serangkaian pertanyaan spesifik yang relevan dengan aplikasi pemrosesan data. Apakah objek data utama yang akan diproses oleh system ? Bagaimana komposisi dari masing-masing objek data dan atribut apa yang menggambarkan objek tersebut? Dimana objek saat ini berada? Bagaimana hubungan antara masing-masing objek data dan objek yang lainnya? Bagaimana hubungan objek dengan proses yang mentransformasikannya?

Untuk menjawab pertanyaan-pertanyaan tersebut, metode pemodelan data menggunakan ERD. ERD hanya berfokus pada data (sehingga memuaskan prinsip pertama analisis operasional).

2.1       Objek Data, Atribut Dan Hubungan

            Model data terdiri dari tiga informasi yang saling bergantungan :

1. Objek Data adalah representasi dari hampir semua informasi gabungan yang harus dipahami oleh perangkat lunak. Maksudnya dengan informasi gabungan kita mengartikan sesuatu yang memiliki sejumlah sifat atau atribut yang berbeda. Contohnya orang atau mobil dapat dipandang sebagai objek data bila salah satu dari mereka dapat didefinisikan dalam bentuk atribut.

Objek                                      Atribut                             Hubungan

                                                         Nama

                    Orang                          Alamat                                             Orang

                                                         Umur

                                                         Lisensi Pengemudi

                                                         Nomor

                  

           Mobil                              Membuat                                        Mobil  

                                                         Model

                                                         Nomor ID

                                                         Body Type

                                                         Warna        

Gambar : 1.0

2. Atribut  menentukan properti suatu objek data dan mengambil salah satu dari tiga karakter hyang berbeda. Atribut dapat digunakan untuk :
1. Menamai sebuah contoh dari objek data
2. Menggambar Contoh
3. Membuat referensi kecontoh ke contoh yang lain pada table yang lain.

Sebagai tambahan, satu atribut atau lebih harus didefinisikan sebagai sebuah pengidentifikasi dimana atribut pengidentifikasi akan menjadi sebuah “kunci”. Dalam banyak kasus harga untuk mengidentifikasi adalah unik, meskipun hal itu bukan merupakan persyaratan. Dengan mengacu pada objek data mobil, pengidentifikasi yang bertanggung jawab dapat menjadi ID #.

     Mobil

Mengikat satu objek data ke yang lain dalam kasus ini, pemilik

       Atribut Penamaan

                                                                            Atribut Diskriptif

                                            Mengidentifikasi                                Atribut Relevansi

Memuat	Model	ID#	Type Body	warna	Pemilik
Lexus Chavy	LS400 Corvette	AB123.. X456..	Sedan Sports	White Red	RSP CCD

Gambar 2.0 Representasi Tabular  dari objek data

3. Hubungan objek data disambungkan satu dengan yang lainnya dengan berbagai macam cara. Andaikan ada dua objek data BUKU dan TOKO BUKU, objek tersebut dapat diwakilkan dengan menggunakan notasi sederhana . misalnya :

·         Toko buku memesan buku

·         Toko buku menampilkan buku

·         Took buku menstok buku

·         Toko buku menjual buku

·         Toko buku mengembalikan buku

Dapat dilihat dengan gambar sebagai berikut  :

 Buku                                                                                    Buku

  a.   Koneksi dasar antar Objek

pesanan

di display

                     Buku                               Persediaan                           Toko Buku

Menjual

Mengembalikan

 Gambar : 3.0  b. Hubungan antar objek

Penting untuk dicatat bahwa objek relationship pairs mempunyai dua arah, dimana mereka dapat dibaca dari dua arah. Toko buku memesan buku atau buku dipesan oleh toko buku.

2.2       Kardinalitas dan Modalitas

           

            Kardinalitas  Model data harus dapat merepresentasikan jumlah peristiwa dari objek didalam hubungan yang diberikan. Tiilmann (TIL. 93)  mendefinisikan kardinalitas dari objek – relationship pair dengan cara sebagai berikut :

Kardinalitas merupakan spesifikasi dari sejumlah peristiwa dari suatu (objek) yang dapat dihubungkan kesejumlah peristiwa dari (objek) yang lain. Kardinalitas biasanya diexpresikan secara sederhana ‘satu’ atau ‘banyak’. Dengan mempertimbangkan semua kombinasi dari ‘satu’ dan ‘banyak’ dua objek dapat dihubungkan sebagai :

·         Satu ke satu (1:1)                suatu peristiwa dari objek A dapat berhubungan dengan satu dan hanya kejadian dari objek B, dan sebuah peristiwa dari B hanya dapat berhubungan dari satu kejadian A, misalnya : seorang suami hanay dapat memiliki satu orang istri dan seorang istri hanya dapat memiliki satu orang suami (di New Jersey).

·         Satu ke banyak (1:N)                     suatu kejadian A dapat berhubungan dengan satu  atau lebih kejadian dari objek B, tetapi sebuah kejadian B dapat berhubungan dengan satu kejadian A, misalnya : seorang ibu  dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki satu orang ibu saja.

·         Banyak ke banyak (N:N)               sebuah kejadian A dapat berhubungan dengan satu atau lebih kejadian dari B, sementara itu sebuah kejadian dari B dapat berhubungan dengan satu atau lebih kejadian dari A, misalnya : seorang paman dapat memiliki banyak keponakan sementara itu seorang keponakan dapat memiliki banyak paman.

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

2.3       Entity – Relationship Diagram

Objec-Relationship Pair merupakan batu pertama dari model data. Pasangan ini dapat diwakili secara grafis dengan menggunakan ERD. ERD pada mulanya diusulkan oleh Peter Chen (CHE77) untuk desain system database relasional dan telah dikembangkan. Tujuan utama dari ERD adalah untuk mewakili objek data dan hubungan mereka.

                                    Kardinalitas ; mengimplementasikan

                                    Bahwa ada banyak tindakan perbaikan

Kardinalitas : mengimplementasikan

Bahwa pelanggan tunggal menunggu

Tindakan perbaikan

                                           

   Pelanggan                    disediakan dengan    Tindakan perbaikan

         

Modalitas;  harus mengimpelmentasikan                                Modulasi ;Optional mengimplementasikan

Bahwa untuk mempunyai tindakan perbaikan                      bahwa ada situasi dimana tindakan per-

Kita harus mempunyai pelanggan                                baikan tidak perlu dilakukan

Gambar : 4.0  Kordanalitas dan Modalitas

Objek data diwakili oleh sebuah persegi panjang yang diberi label. Hubungan ditunjukkan dengan garis yang diberi label yang menghubungkan objek dalam variasi ERD, garis yang menghubungkan berisi sebuah label permata yang diberi label dengan hubungan tersebut. Sambungan antara data dan objek dan hubungan dibangun dengan menggunakan berbagai macam simbol khusus yang menunjukkan kardinalitas dan modalitas.

   Pemanufakturan                                  Membuat                              Mobil       

Tabel Objek Data

ID #	Model	Tipe body	Mesin	Transmisi

Gambar :  5.0 ERD sederhana dan tabel objek data (catatan dalam ERD ini, bangunan diindikasikan dengan diamon pada line koneksi antar objek data)

            Hubungan antara mobil dan pabrik akan dipresentasikan seperti diperlihatkan didalam Gambar : 5.0  satu pabrik membangun satu atau banyak mobil. Diberikan konteks yang diimplikasikan oleh ERD, spesifikasi dari objek data mobil  (lihat pada gambar table 5.0 akan menjadi sangat berbeda dengan spesifikasi sebelumnya  (gambar 2.0) . Dengan mengamati symbol pada akhir garis sambungan antara objek dapat dilihat bahwa modalitas dari kedua peristiwa merupakan keharusan (garis vertical).

            Dengan memperluas model, kita mewakili ERD yang sangat disederhanakan  (gambar 6.0) dari elemen distribusi  bisnis aotomotif.

Lisensi                                      Dealership                              Persediaan

   Pemanufaktur                                  Membuat                               Mobil

 

       Kontrak                                                                                          Transport

 

                                                                                                                Pengirim

                                              

Gambar : 6.0  ERD diperluas

         Notasi ERD juga memberikan suatu mekanisme yang mewakili asosiativitas antar objek, sebuah objek data asosiatif di representasikan seperti diperlihatkan didalam gambar 7.0. didalam gambar tersebut objek data yang memodelkan subsistem individual masing-masing  diasosiasikan dengan objek data mobil.

                                                      Elektronika

 

     Mesin                   Chasis                                    Interior                        drive train     

 

                                                            Mobil

Gambar 7.0 Objek Data Terkait

Pemodelan data dan ERD memberi notasi yang singkat untuk mengamati data didalam konteks aplikasi pemrosesan data kepada analis. Dalam sebbagian besar kasus, pendekatan pemodelan data digunakan untuk menciptakan satu potong analisis, tetapi dia juga dapat digunakan untuk perancangan database dan untuk mendukung metode analisis persyaratan yang lain.

3.   PEMODELAN FUNGSIONAL DAN ALIRAN INFORMASI

Analisis terstruktur dimulai sebagai sebuah teknik pemodelan aliran informasi. Sebuah sistem berbasis komputer direpresentasikan sebagai sebuah transformasi informasi. Sebagai contoh terlihat pada gambar 4.0 keseluruhan fungsi dari sistem tersebut diwakilkan sebagai transformasi informasi tunggal, yang ditulis sebagai gelembung didalam gambar. Satu input atau lebih diperlihatkan oleh anak panah yang diberi label , berasal dari entitas eksternal. Yang direpresentasikan sebagai sebuah kotak. Input mengendalikan transformasi tersebut untuk memproduksi informasi Output yang dilewatkan ke entitas eksternal.

3.1 Diagram Aliran Data

            Pada saat informasi mengalir melalui pernagkat lunak, dia dia dimodifikasi oleh suatu deretan transformasi. Diagram aliran data / data flow diagram (DFD) adalah sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang diaplikasikan pada saat data bergerak dari input menjadi output. Bentuk dasar  dari suatu aliran data diilustrasikan didalam gambar 4.0. DFD juga dikenali sebagai grafik aliran aliran data atau bubble chart.

                                                Informasi       Informasi                   Entiti External

   Entiti External                       input                        Output

                                                    Sistem Berbasis                           Entiti External

                                                         Komputer

  Entiti External

                                        G.8.0   Model Aliran Informasi          Entiti External

DFD tingkat 0 yang disebut juga dengan model system fundamentasi atau model konteks, merepresentasi seluruh elemen system sebagai sebuah bubble tunggal dengan data input dan output yang ditunjukkan oleh anak panah yang masuk dan keluar secara berurutan. Proses tambahan (bubble) dan jalur aliran informasi direpresentasikan pada saat DFD tingkat 0 dipartisi untuk megungkap detail yang lebih. Contohnya, sebuah DFD tingkat 1 dapat berisi lima atau enam bubble dengan anak panah yang saling menghubungkan.

Notasi dasar yang digunakan untuk menciptakan suatu DFD diilustrasikan didalam gambar 5.0

    Entiti External                               Prosedur atau konsumer  yang ada diluar bound Sistem untuk dimodelkan

         Proses                                       Tranfer informasi (fungsi ) yang ada di dalam bound sistem untuk dimodelkan

                                                            Objek data ; anak panah menunjukkan arah aliran data     

           Objek Data

Penyimpanan Data                         Repositori data yang disimpan untuk digunakan oleh satu atau lebih, proses dapat disederhanakan buffer atau queque, atau serumit database relasional .

G. 10.0

3.2       Ekstensi Sistem Real-Time

            Sistem real-time harus berinteraksi dengan dunia nyata didalam kerangka waktu yang ditentukan oleh dunia nyata. Penerbangan pesawat, proses pabrik, produk konsumen dan instrumentasi industri merupakan beberapa dari ratusan aplikasi perangkat lunak real-time.

            Aliran data tidak                      objek data yang berupa input atau output dari proses pada basis terus menerus

           Terus menerus

Proses                                                   transformer controlatau ‘event’ menerima           Kontrol                                       control dan input dan melakukan control

                                                   Sebagai output     

           

                                                              

            Item                                            item control ;mengambil nilai Boolean atau

            Control                                      diskrit; anak panah menunjuk arah aliran data

                                                               Penyimpan item control yang disimpan untuk

Penyimpanan Control                       digunakan oleh satu atau lebih proses

 

        Proses                                           banyak contoh ekivalen dari proses yang sama; digunakan jika banyak proses dibuat dalam system multitasting.

G.11.0 ; Notasi analisis terstruktur extended untuk system real – time yang dikembangkan oleh word dan Mellor (WARD85).

3.3       Ekstensi Ward dan Mellor

            Ward dan Mellor memperluas notasi analisis struktur dasar untuk mengakomodasi permintaan yang dikenakan oleh system real-time berikut ini :

• Aliran informasi dikumpulkan atau dihasilkan pada basis time-continious
• Informasi control yang dilewatkan melalui system dan pemrosesan control yang sesuai
• Contoh bertingkat dari transformasi yang sama, yang kadang-kadang terjadi didalam situasi multitasking
• Pernyataan system dan mekanisme yang menyebabkan transisi diantara keadaan.

Dalam presentasi yang berarti dari aplikasi real-time, system harus memonitor informasi time-cintinuous yang digenerasikan oleh proses dunia nyata. Notasi aliran data konvensional tidak membuat perbedaan diantara data diskrit dan data time-continuous ekstensi untuk analisis terstruktur diperlihatkan pada gambar 7.0

Suhu dimonitor        input ‘berkelanjutan’

 

                                                                                              Output ‘berkelanjutan’

 

                                                               memonitor

                                                         dan menyesuaikan                   Nilai dikoreksi

                                                              tingkat suhu           

 

Suhu ditetapkan      G.12.0 ; Aliran data time-continuous

3.4       Ekstensi Hatley dan Pirbhai

Ekstensi Hatlei dan Pirbhai kenotasi analisis terstruktur dasar kurang berfokus pada kreasi dari symbol grafis tambahan dan lebih berfokus pada representasi dan spesifikasi aspek perangkat lunak yang berorientasi pada control.

4          MEKANIK DARI ANALISIS TERSTRUKTUR

4.1 Membuat sebuah diagram hubungan Entitas

Diagram hubungan  entitas memungkinkan seorang perekayasa perangkat lunak untuk secara penuh menspesifikasikan objek data yang merupakan input dan output dari system. Pendekatan berikut ini perlu diketahui dalam membuat diagram Entitas :

ü  Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar ‘hal-hal’ yang akan dituju oleh proses bisnis dan aplikasi. ‘Hal-hal’ ini dimasukkan kedalam sebuah daftar objek data input dan output dan entitas eksternal yang menghasilkan atau mengkonsumsi informasi.

ü  Dengan mengambil objek satu pada satu saat , analis dan pelanggan mendefinisikan apakah ada sambungan (tidak diberi nama pada tahap ini ) ada diantara objek data  dan objek lain.

ü  Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan hubungan objek atau lebih .

ü  Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan modalitas.

ü  Langkah 2 sampai 4 dilanjutkan secara iterative sampai semua pasangan hubungan objek sudah didefinisikan. Sudah menjadi kebiasaan untuk menemukan penghilangan pada saat proses ini berlanjut. Objek dan hubungan baru akan ditambahkan pada saat jumlah iterasi bertambah.

ü  Atribut dari masing-masing entitas didefinisikan

ü  Diagram entitas diformalisasikan dan dikaji

ü  Langkah 1 sampai 7 diulangi sampai pemodelan data terlengkapi.

4.2       Membuat Sebuah Model Aliran Data

            Diagram aliran data (DFD) memungkinkan perekayasa perangkat lunak untuk mengembangkan model domain informasi dan domain fungsional pada saat yang sama. Beberapa tuntunan sederhana dengan terukur dapat membantu selama derivasi  sebuah diagram aliran data :

1. diagram aliran data tingkat 0 harus menggambarkan perangkat lunak/system sebagai gelembung tunggal.
2. input dan output utama harus dicatat secara berhati – hati
3. penyaringan harus dimulai dengan mengisolasi proses calon, objek data, dan penyimpanan yang akan direpresentasikan pada tingkat selanjutnya.
4. semua anak panah dan gelembung harus diberi label dengan nama yang berarti
5. kontinyuitas aliran informasi harus dijaga dari tingkat ke tingkat
6.  satu gelembung pada satu saat harus disaring.

Ada  kecenderungan natural untuk terlalu mengkomlikasikan diagram aliran data. Hal ini terjadi bila analisis ingin menunjukkan terlalu banyak  detail pada saat yang terlalu dini

4.3     Membuat Sebuah Model Aliran Kontrol

Untuk beberapa tipe aplikasi pemrosesan, model data dan diagram aliran data meruapakan hal yang diperlukan untuk memperoleh wawasan yang berarti kedalam persyaratan perangkat lunak. Tetapi, seperti yang telah dicatat, disana ada suatu kelas aplikasi yang besar yang lebih dikendalikan oleh kejadian dari pada data, yang lebih menghasilkan informasi control dari pada menghasilkan laporan dan tampilan. Dan yang memproses informasi dengan perhatian besar kepada waktu dan kinerja kerja. Aplikasi semacam itu mambutuhkan pemodelan aliran control sebagai tambahan kepemodelan aliran data.

Telah kita catat bahwa sebuah kejadian atau item control diimplementasikan sebagai harga Boolean (misalnya; benar atau salah, on atau off, 1 atau 0) atau sebuah daftar diskrit dari keadaan (kosong,penuh), untuk memilih calon kejadian yang potensial, diusulkan tuntutan berikut ini :

·               Daftarlah semua sensor yang dibaca oleh perangkat lunak

·               Daftarlah semua keadaan interupsi

·               Bacalah semua saklar yang diaktuasi oleh operator

·               Daftarlah semua keadaan data

·               Dengan menarik uraian data kerja dan data benda yang diaplikasikan ke narasi pemrosesan, kajilah semua item control sebagai input /output CSPEC yang mungkin

·               Gambarkanlah tingkah laku dari system dengan mengidentifikasi keadaannya ; identifikasikanlah bagaimana keadaan dicapai dan definisikanlah transisi antar keadaan.

·               Fokuskanlah penghilangan yang mungkin sebuah kesalahan yang paling umum didalam menspesifikasikan control (misalnya, tanyakanlah ; adakah suatu cara dimana saya dapat masuk ke keadaan itu atau keluar darinya).

4.4       Spesifikasi Kontrol

            CSPEC mempresentasikan tingkah laku system (pada tingkat dimana dia direferensikan) didalam dua cara yang berbeda. CSPEC berisi sebuah diagram transisi keadaan (STD) yang merupakan suatu spesifikasi sekuensial dari tingkah laku. Dia juga dapat berisi suatu table aktifitas proses (PAT) – sebuah spesifikasi  kombinaturial dari tingkah laku. 

4.5       Spesifikasi Proses

            Spesifikasi Proses (PSPEC) digunsksn untuk menggambarkan semua proses model aliran yang nampak pada tingkat akhir penyaringan.Kandungan dari spesifikasi proses dapat termasuk teks naratif, bahasa design program/Progamme Design Language (PDL) dari Algoritma proses, persamaan Matematika, table, diagram atau bagan, dengan memberikan sebuah PSPEC untuk mengiringi masing-masing gelembung didalam model aliran, berarti perekayasa perangkat lunak menciptakan sebuah “spesifikasi mini”yang dapat berfungsi sebagai sebuah langkah pertama didalam kreasi spesifikasi persyaratan perangkat lunak dan sebagai penuntun bagi desaign komponen program yang akan mengimplementasikan program.

Dimensi segitiga                                                      pesan error

 

                                                            Segi tiga

                                                            Analisis                                        tipe segitiga

PSPEC : Naratif Pemrosesan untuk segi tiga Analisis

Proses segitiga analisis menerima nilai A,B dan C yang menyajikan dimensi sisi sebuah segitiga. Proses memeriksa  nilai-nilai dimensi untuk menentukan apakah semua nilai positif, jika ditemukan nilai negative, akan muncul pesan error. Proses mengevaluasi keabsahandata input untuk menentukan apakah dimensi menentukan. Keabsahan segitiga, dan jika ya, apa tipe segitiga  sama sisi, sama kaki , atau tidak sama sisi yang diimplikasikan oleh dimensi tipe adalah output.

Gambar 13.0 Spesifikasi Proses untuk Proses PDF

Dimensi segitiga                                                      pesan error

 

                                                            Segi tiga

                                                            Analisis                                        tipe segitiga

PSPEC : Naratif Pemrosesan untuk segi tiga Analisis

Prosedur Analisa Segitiga : Membaca dimensi sisi-sisi segitiga; Jika semua dimensi negatif maka terjadi pesan error Jika dimensi terbesar kurang dari jumlah yang lain maka mulai Tentukan jumlah sama sisi Jika tiga sisi sama maka tipenya adalah sama sisi ; Jika dua sisi sama maka tipenya adalah sama kaki Jika tidak ada sisi yang sama maka tipenya adalah tidak sama output tipe segitiga End Tipe output lain = 0 indikasi bahwa tidak ada segitiga; Endif enproc

Gambar 14.0 Spesifikasi Proses Menggunakan PDL untuk proses DFD

5          KAMUS DATA

            Kamus data telah diusulkan sebagai sebuah tata bahasa quasi-formal untuk menggambarkan kandungan dari objek yang didefinisikan selama analisis terstruktur. Notasi pemodelan yang penting ini telah didefinisikan sebagai berikut : Kamus data merupakan sebuah daftar  yang teroganisasi  dari elemen data yang berhubungan dengan system, dengan definisi yang tegar dan teliti sehingga pemakai dan analisis system akan memiliki pemahaman yang umum mengenai input, output, komponen penyimpan , dan bahkan kalkulasi inter-mediate.

            Saat ini, kamus data hamper selalu diimplementasikan sebagai bagian dari sebuah “piranti desain dan analisis terstruktur “ CASE. Sebagian kamus data berisi informasi sebagai berikut :

-          Name = sebenarnya dari data atau item control, penyimpanan data, atau entitas eksternal.

-          Aliasi = nama lain yang digunakan untuk entri pertama

-          Where-used/how used = suatu daftar dari proses yang menggunakan data atau item control dan bagaimana dia digunakan (misalnya input ke progress, output dari progress, sebagai suatu penyimpanan, sebagai suatu entitas eksternal)

-          Content description = suatu notasi untuk mempresentasikan isi

-          Supplementary information = informasi lain mengenai tipe data, harga preset (bila diketahui).

Notasi yang digunakan untuk mengembangkan diskripsi isi, yang diilustrasikan didalam Gambar 9.0 memungkinkan analisis untuk mempresentasikan data komposit (misal objek data) didalam salah satu dari tiga fundamenta yang dapat dikonstruksi olehnya :

1. sebagai sebuah urutan item data
2. sebagai suatu pilihan dari antara serangkaian item data atau
3. sebagai sebuah kelompok pengulangan item data

Konstruksi data	Notasi	Arti
Berurutan Pilihan Pengulangan	= + [ | ] {  }n {  } .   .	Disusun atas Dan Baik ini ,atau Pengulangan ke-n dari Data opsional Komentar tidak dibatasi

Masing-masing entri item data direpresentasikan sebagai bagian dari urutan, seleksi dan pengulangan dapat menjadi objek data lain yang memerlukan penyaringan lebih jauh lagi didalam kamus.

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

Ken Orr memperluas kerja Warnier untuk mencakup pandangan yang lebih luas mengenai domain informasi yang telah dikembangkan kedalam DSSD

            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. Dalam kalimat Jackson , “Pengembang memulai dengan menciptakan sebuah model realistis dimana system diperhatikan, realitas yang memperlengkapi masalah subjek (system)nya..”

            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.

DAFTAR PUSTAKA

Roger S. Pressman, Ph.D,  “Rekayasa Perangkat Lunak”, Pendekatan Praktisi (Buku Satu ), ANDI Yogyakarta

Roger S. Pressman, "Software Engineering, a Practitioner's Approach" Fourth Edition, McGraw Hill, 1997.

Barbee Teasley Mynatt, "Software Engineering with Student Project Guidance", Prentice Hall Int. 1990.

Roger S. Pressman, "Software Engineering, A Beginner's Guide", McGraw Hill, 1998.