4.
PEMODELAN ANALISIS
Topik meliputi :
1. Elemen Model Analisa 2. Pemodelan Data
3. Pemodelan Fungsional dan Aliran Informasi 4. Petunjuk Dalam pemakaian Penamaan 5. Kamus Data (Data Dictionary)
6. Normalisasi Data
7. Entity Relationship Diagram (ERD) 8. Diagram Warnier
9. Sistim Pengembangan Jackson (JSD – JACKSON SYSTEM DEVELOPMENT) 10. SADT (Structural Analysis and Design Technique)
Tujuan bab ini dapat memahami : Model Elemen analisa.
Konsep data flow diagram, konteks dan levelisasi.
Entity relational diagram (ERD), obyek data, atribut dan hubungan.
Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang komprehensif bagi perangkat lunak yang dibangun.
1. ELEMEN MODEL ANALISA Model analisa harus dapat mencapai tiga sasaran utama penting yakni : o Menggambarkan apa yang dibutuhkan untuk pelanggan. o Membangun dasar bagi pembuatan desain perangkat lunak.
o Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.
Untuk mencapai sasaran tersebut dibuatlah model analisa yang berisi :
Data Dictionary
Penyimpanan yang berisi diskripsi dari semua obyek data yang dikonsumsi atau diproduksi oleh perangkat lunak.
Entity Relationship Diagram (ERD)
Menggambarkan hubungan antara obyek data.
Data Flow Diagram (DFD)
Memberikan indikasi mengenai bagaimana data ditransformasi pada saat data bergerak melalui sistim.
Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.
State Transition Diagram
Menunjukkan bagaimana sistim bertingkah laku sebagai akibat dari kejadian eksternal.
Control Specification (CSPEC)
Informasi tambahan mengenai aspek kontrol dari perangkat lunak.
Design Data
Mentransformasikan model domain informasi yang dibuat selama analisa ke dalam struktur data yang akan diperlukan untuk mengimplementasikan perangkat lunak.
Design Arsitektur
Menentukan hubungan antara elemen-elemen struktural utama dari program.
Representasi desain tersebut, kerangka kerja modular dari sebuah program komputer, sehingga dapat diperoleh dari model-model analisa dan interaksi subsistim yang ditentukan dalam model analisa.
Design Interface
Menggambarkan bagaimana perangkat lunak dapat berkomunikasi dalam dirinya sendiri dan dengan manusia yang menggunakannya.
Interface mengimplikasi aliran informasi (misalnya data dan atau control) dengan demikian, data dan diagram aliran control memberikan informasi yang dibutuhkan bagi desain interface.
Desain Prosedural
2. PEMODELAN DATA
Untuk dapat menjawabnya pertanyaan sebagai berikut :
Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkan obyek tersebut ?
Dimana obyek saat ini berada ?
Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya ? Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya ?
Digunakan Entity Relational Diagram (ERD)
2.1. OBYEK DATA, ATRIBUT DAN HUBUNGAN
Pada model data ada 3 informasi yang saling berhubungan yaitu antara lain : 2.1.1. OBYEK DATA
2.1.2. ATRIBUT 2.1.3. HUBUNGAN
2.1.1. OBJEK DATA
Adalah representasi dari hampir semua informasi gabungan yang harus dipahami oleh perangkat lunak.
2.1.2. ATRIBUT
Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang berbeda.
Menamai sebuah contoh dari obyek data. Menggambarkan contoh.
Membuat referensi ke contoh yang lain pada tabel yang lain.
2.1.3. HUBUNGAN
Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara.
2.2. KARDINALITAS DAN MODALITAS
Merupakan spesifikasi dari sejumlah peristiwa dari suatu obyek yang dapat dihubungkan ke sejumlah peristiwa dari obyek yang lain.
Berikut penjelasan dan contoh masing-masing.
2.2.1. KARDINALITAS
seorang ibu dapat memiliki banyak anak tetapi seorang anak hanya dapat memiliki satu ibu.
Banyak ke banyak (M:N) Contoh:
seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan dapat memiliki banyak paman.
2.2.2. 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.
Gambar Hubungan antara Kardinalitas dan Modalitas.
Contoh :
Sebuah perangkat lunak yang digunakan oleh perusahaan telepon lokal untuk memproses permintaan pelayanan lapangan.
Seorang pelanggan menunjukkan bahwa salah satu dari pelanggan mengalami masalah.
Jika masalah tersebut didiagnosis sebagai masalah yang sederhana maka dilakukan aksi perbaikan tunggal dan jika masalahnya rumit maka dilakukan aksi perbaikan bertingkat.
Perhatikan gambar diatas, yang menggambarkan hubungan, kardinalitas dan modalitas antara obyek data pelanggan dan aksi perbaikan.
Pelanggan Tindakan Perbaikan
Kardinalitas
Mengimplikasikan bahwa
pelanggan tunggal menunggu tindakan perbaikan
Untuk mempunyai tindakan perbaikan, kita harus ada pelanggan.
Modalitas : Opsional
Mengimplikasikan bahwa
3. PEMODELAN FUNGSIONAL DAN ALIRAN INFORMASI
Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistim berbasis komputer.
Sistim tersebut menerima input dengan berbagai cara dan menghasilkan suatu output.
Akibatnya kita dapat menciptakan suatu model aliran bagi setiap sistim berbasis komputer tanpa melihat ukuran dan kompleksitasnya.
3.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 Bubble Chart.
Keuntungan menggunakan data flow diagram adalah memudahkan pemakai (user) yang kurang menguasai bidang computer untuk mengerti sistim yang akan dikerjakan atau dikembangkan.
Arus dari data tersebut nantinya dapat di jelaskan dengan menggunakan kamus data (Data Dictionary).
Gambar Contoh Diagram aliran data / data flow diagram.
Beberapa komponen yang disimbolkan dalam Data Flow Diagram antara lain sebagai berikut : 3.1.1. Proses
3.1.2. File atau Data Store
3.1.3. External entity / Sumber / Sink 3.1.4. Data Flow
3.1.1. PROSES
Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol. Simbol proses terdiri dari :
Gambar Simbol Proses.
3.1.2. FILE ATAU DATA STORE
File atau Data Store adalah tempat penyimpanan data.
Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store. Setiap data store rnempunyai nama yang unik.
Simbol File atau Data Store terdiri dari :
Gambar Simbol File atau Data Store.
3.1.3. EXTERNAL ENTITY / SUMBER / SINK
o External entity adalah diluar sistim, tetapi mereka merupakan salah satu bagian yang memberikan input data kedalam sistim atau digunakan oleh output sistim.
o Source adalah External entity yang memberikan input data kedalam sistim. o Sinks adalah External entity yang menggunakan data sistim.
o Simbol :
Gambar Simbol External entity.
3.1.4. DATA FLOW
Aliran data / data flow merupakan arus informasi yang mengalir dari atau ke proses, entity ataupun data store.
Aliran data / data flow pada sistim yang di perbolehkan adalah : Antara dua proses.
Dari sebuah data store ke sebuah proses. Dari sebuah proses ke sebuah data store. Dari sebuah source ke sebuah proses. Dari sebuah proses ke sebuah sink.
Gambar Simbol Data Flow.
Perhatikanlah bahwa apabila kita menggambarkan sebuah sistim maka simbol-simbol data flow diagram tersebut akan digunakan.
3.2. MENGGAMBARKAN SISTIM DENGAN DATA FLOW DIAGRAM
Langkah awal yang harus dibuat adalah membuat "DIAGRAM KONTEKS", yaitu DFD di mana sistim terdiri dari satu proses.
Pada tahap ini terlihat semua external entity yang berinteraksi dengan sistim dan data flow, antara external entity dan sistim, dan pada DFD tidak diperkenankan mempunyai data store.
Gambar Contoh diagram Konteks Budget monitoring sistim.
Jika anda perhatikan dari gambar diatas, diagram konteks, maka pada level konteks tidak ada simbol store dan sistim berinteraksi dengan 3 simbol external entity, antara lain :
1. DEPARTEMENTS 2. MANAGEMENTS 3. SUPPLIERS
Aliran data utama dari Departements adalah "Spending Request".
Sebagai tanggapan dari sistim, Departemen menerima "Rejected Request" atau aliran data "Delivery Advice".
Management juga mengirim data flow “Budget Allocation” ke sistim dan mendapatkan data
flow “Spending Summaries”.
Supplier menerima data flow “Part Order” dan mengembalikan data flow “Supplier Delivery
Advice”.
Setelah mendapatkan “Diagram Konteks”, langkah selanjutnya adalah membuat DFD yang
memperlihatkan proses dari sistim utama, yang dinamakan dengan DFD LEVEL TINGKAT 1.
Gambar Contoh diagram konteks level tingkat 1. Budget monitoring sistim.
Pada diagram konteks level 1 diatas memperlihatkan berbagai proses yang membentuk sistim dimana terdiri dari 5 simbol proses dan setiap proses mempunyai simbol dan nama yang unik serta nomor proses dari masing-masing simbol.
DFD diatas kita lihat bahwa data flow “Spending Request” dari Departements menuju ke proses “Check Funding”.
Proses “Check Funding” melihat “Allocated Budget” dan menetapkan apakah izin khusus
diperlukan dari management untuk diteruskan ke permintaan.
Data flow “Approved Request” menuju ke proses “Classify Expenditure”, dan kemudian dimasukkan pada data store “Departemental-Accounts” dan “Type-Accounts”.
Akhirnya, jika diperlukan, “Part Order” untuk menetapkan bagian ( part ) semula dalam
Dua proses lainnya : “Setup Budget” dan “Provide Spending Summaries”.
Kita dapat memperluas setiap proses pada Level DFD selanjutnya.
Sebagai contoh diambil proses “Classify Expenditure”.
Pada level ini simbol proses harus diisi nama yang unik serta nomor seperti yang terlihat pada proses Classify Expenditure dengan nomor 3.1 (gambar dibawah) demikian juga untuk proses selanjutnya sehingga akan mendapatkan aliran data yang menunjukkan hubungan satu proses ke proses yang lainnya.
Gambar Contoh diagram konteks level 1
yang di sertai dengan keterangan pada setiap proses dan aliran data.
Data Flow Diagram yang baik :
1. Ketiadaan dari struktur flowchart. 2. Penyimpanan data.
3. Penamaan yang baik.
Perbedaan antara Flowchart dan Data Flow Diagram : Flowchart terdiri dari box-box yang mendiskripsikan :
Komputasi.
Decision / Keputusan. Iterasi.
Loop.
3.3. FAKTOR YANG HARUS DIPERHATIKAN DALAM MEMBUAT DECISIONS DAN INTERACTIVE CONTROL
Hal yang terpenting adalah bagaimana anda dapat menempatkan proses yang akan berjalan pada sistim dengan penamaan yang unik serta aliran data yang jelas, diskripsi data store.
3.3.1. DECISION DALAM DFD
Gambar Contoh Decision dalam DFD.
3.3.2. PERULANGAN DALAM DFD
Gambar Contoh perulangan dalam DFD.
Contoh lain :
Studi kasus Prosedur Sistim Usulan.
Proses-proses dalam Sistim Usulan secara berurutan terbagi atas 3 proses antara lain : 1. Prosedur Pengolahan Penjualan.
Setelah itu pemesanan dicek limit kredit, jika pemesanan melebihi limit kredit maka diberikan konfirmasi kepada pelanggan, bila tidak dibuat faktur dan surat jalan untuk dikirimkan ke pelanggan.
2. Pembayaran dan Retur.
Setelah itu dibuat pengolahan penjualan terdapat beberapa prosedur yang berurutan seperti : Pembayaran pelanggan, terdapat proses pembayaran, proses pembuatan kuitansi dan pengelolaan piutang.
Retur pelanggan, proses pengembalian barang karena adanya ke tidak cocokan terhadap barang yang dipesan.
3. Pelaporan.
Pembuatan laporan penjualan, laporan barang, laporan piutang, laporan pelanggan, laporan ramalan penjualan, dan laporan retur.
Pemodelan diawali dengan diagram konteks, diagram nol dan terus dilanjutkan dengan diagram tingkat selanjutnya sampai dengan jelas tergambar keseluruhan proses secara rinci.
4.1. PENAMAAN “PROSES”
Dalam membuat penamaan, nama proses harus tunggal dan dapat mendeskripsikan suatu proses dalam sebuah kalimat yang jelas.
Dalam membuat penamaan, nama proses harus mendefinisikan kegiatan atau aksi yang spesifik.
Contoh : 1. Mengedit
2. Menghitung gaji mingguan 3. Menghitung diskon pada pesanan 4. Dan lainnnya
Dalam membuat penamaan, jika suatu proses menangani proses maka harus di pecah menjadi beberapa proses.
4.2. PENAMAAN “DATA STORE”
Penamaan data store harus khas atau spesifik.
Ingatlah bahwa setiap data store hanya berisi satu set struktur data.
4.3. PENAMAAN DATA FLOWS ANTARA PROSES o Gunakan satu kata, Contoh : “kuitansi”, “Cek” dan sebagainya. o Jangan menggunakan nama yang sama untuk setiap data flow.
o Perhatikan contoh pada gambar a berikut, yang menggunakan penamaan yang sama selanjutnya hasil setelah penamaan tersebut diperbaiki adalah gambar b.
Pada data flow “Invoice” yang masuk ke “Edit Invoice”, dan keluar sebagai “Invoice” lagi, hal ini tidak diizinkan dengan menggunakan nama yang sama atau dalam gambar diatas yang menggunakan simbol bintang tidak diperbolehkan.
Gambar b. Contoh DFD.
Penamaan yang benar dan telah diperbaiki.
5. KAMUS DATA (DATA DICTIONARY)
Merupakan kumpulan data yang bertujuan untuk memberikan informasi mengenai definisi, struktur, pemakai dari masing-masing elemen.
Notasi yang digunakan dalam kamus data adalah :
Penyusunan Data Notasi Arti
Sequence
Berikut diskripsi dan struktur data pada sistim penjualan adalah sebagai berikut :
Tabel KAMUS DATA.
No NAMA
ARUS DATA STRUKTUR DATA
1 DATA BARANG
2 DATA
Normalisasi merupakan suatu pendekatan formal yang menguji data dan elemen data secara bersamaan kedalam suatu bentuk yang dapat menampung perubahan dimasa yang akan datang.
Masing-masing atribut memiliki kesamaan kepentingan memudahkan memanggil ulang dalam perangkat lunak komputer mengunakan kunci atau key.
Tabel adalah suatu kesatuan yang terdiri dari baris dan kolom (field) yang berisi data untuk ditampilkan ke user sebagai informasi.
Sekelompok tabel untuk suatu keperluan dikelompokkan dalam sebuah database yang ditangani dan dihandle oleh database engine dan disimpan sebagai sebuah file.
Dalam pembentukan sebuah tabel yang baik dibutuhkan tahapan tahapan antara lain tahap unnormalized yakni tabel yang berisi seluruh data yang akan ditangani tanpa memperdulikan faktor relation dan ke tergantungannya.
Langkah selanjutnya adalah menormalisasi tabel menjadi bentuk 3NF dengan menghilangkan repetisi dan ketergantungan data antar kolom dalam sebuah tabel.
Meskipun bukan suatu yang mutlak dan pasti, sebuah tabel dalam bentuk 3NF biasanya terdiri dari 3 sampai 5 kolom dan satu sama lain saling terhubung melalui pola relation yang diatur dalam foreign key.
ATRIBUT KUNCI
Merupakan field kunci dari sebuah file tabel yang dapat mewakili suatu record.
Misalnya dalam contoh ini, kunci dari tabel barang adalah kode barang, field kunci ini harus bersifat unik dan dalam nomor induk pasti tidak boleh ada yang sama.
Beberapa atribut kunci yang digunakan antara lain : 1. KUNCI PRIMER (PRIMARY KEY)
2. KUNCI TAMU (FOREIGN KEY)
Adalah satu atribut yang melengkapi satu hubungan (relationship) yang menunjukkan ke induknya.
Kunci Tamu ditempatkan pada entity anak dan sama dengan Kunci Primary induk direlasikan.
Hubungan antara entity induk dengan anak adalah hubungan satu lawan banyak (one to many relationship).
3. KUNCI ALTERNATIF (ALTERNATIVE KEY)
Alternative Key adalah kunci kunci tertentu yang tidak dipakai sebagai Primary Key.
Sering kali kunci ini hanya dipakai sebagai kunci pada saat terjadi pengurutan (sorting) dalam laporan.
Ada beberapa bentuk Normalisasi, yaitu :
1. BENTUK TIDAK NORMAL (UNNORMALLIZED FORM / UNF).
Merupakan kumpulan data yang akan direkam, tidak ada keharusan mengikuti suatu format tertentu, bisa berupa data tidak lengkap atau terduplikasi, Data dikumpulkan apa adanya.
2. BENTUK NORMAL PERTAMA (FIRST NORMAL FORM / 1NF).
Merupakan suatu kumpulan data yang dibentuk menjadi bentuk normal ke satu dengan memisah misahkan data pada field field yang tepat dan bersifat atomic yaitu tidak ada set atribut yang berulang atau atribut bernilai ganda.
3. BENTUK NORMAL KE DUA (SECOND NORMAL FORM / 2NF). Setiap atribut dalam record adalah fungsional dependent dari record key. Dalam second normal form tidak terdapat data redudancy / berulang-ulang .
Pembentukan Normal Ke Dua mencari kunci field yang dipakai sebagai patokan dalam pencarian data dan memiliki sifat unik.
4. BENTUK NORMAL KE TIGA (THIRD NORMAL FORM / 3NF).
Bentuk Normal Ke Tiga mempunyai syarat setiap tabel tidak mempunyai field yang tergantung transitif, namun harus tergantung penuh pada Kunci Utama.
Dengan kata lain, setiap atribut bukan kunci haruslah bergantung hanya pada Primary Key dan pada pada Primary Key secara menyeluruh.
5. BOYCE-CODD NORMAL FORM (BCNF).
Boyce-Codd Normal Form mempunyai alasan paksaan yang lebih kuat dari Bentuk Normal Ke Tiga.
CONTOH NORMALISASI
1. PEMESANAN.
Normalisasi data untuk proses “pemesanan barang” pada bentuk 1, 2 dan 3 (1NF, 2NF dan 3NF serta UNF) pada gambar Diagram Level Dua (Proses 1.1), Proses Pemesanan Barang, terpusat pada proses P2.1.2. adalah :
UNF = No_Psn + Tgl_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos + {Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat} + Nilai_Psn
1NF = No_Psn + Tgl_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos + Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat + Nilai_Psn
2NF :
Header_Pesan = No_Psn* + Tgl_Psn + Kd_Plg + Nilai_Psn
Pelanggan = Kd_Plg* + Nm_Plg + Alamat + Kota + Kd_Pos
Detail_Pesan = No_Psn* + Kd_Brg* + Qty
Barang = Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Psn
Proses pemesanan barangnya lihat proses P2.1.2. pada “cek barang”, pada gambar Diagram Level Dua (Proses 1.1), Proses Pemesanan Barang.
2. FAKTUR.
Normalisasi data untuk proses “pemesanan barang” pada bentuk 1, 2 dan 3 (1NF, 2NF dan 3NF serta UNF) pada gambar Diagram Level Dua (Proses 1.1), Proses Pemesanan Barang, terpusat pada proses P2.1.5. adalah :
UNF = No_Fak + Tgl_Fak + No_Sj + No_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos + {Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat} + Nilai_Fak
1NF = No_Fak* + Tgl_Fak + No_Sj + No_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos
Detail_ faktur = No_Fak* + Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Sat
Pelanggan = Kd_Plg* + Nm_Plg + Alamat + Kota + Kd_Pos
Barang = Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Psn
Proses pemesanan barangnya lihat proses P2.1.5. pada “Buat faktur dan surat jalan”, pada gambar Diagram Level Dua (Proses 1.1), Proses Pemesanan Barang.
3. PEMBAYARAN.
Normalisasi data untuk proses “pembayaran pelanggan” pada bentuk 1, 2 dan 3 (1NF, 2NF
dan 3NF serta UNF) pada gambar Diagram Level Dua (Proses 2.1), Proses Pembayaran Pelanggan, terpusat pada proses P2.1.1. (proses terima pembayaran) adalah :
UNF = No_Byr + Tgl_Byr + Jml_Byr + Kd_Plg + {No_Fak} + Nm_Bank +
Detail_Bayar = No_Byr* + No_Fak*
4. RETUR.
Normalisasi data untuk proses “Retur pelanggan” pada bentuk 1, 2 dan 3 (1NF, 2NF dan
3NF, serta UNF) pada gambar Diagram Level Dua (Proses 2.2), Proses Retur Pelanggan, terpusat pada proses P2.2.1. (Cek retur) adalah :
UNF = No_Ret + Tgl_Ret + No_Fak + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos
Header_Retur = No_Ret* + Tgl_Ret + No_Fak + Kd_Plg + Nilai_Ret
Detail_Retur = No_Ret* + Kd_Ret* + Qty + Ket_Ret
Pelanggan = Kd_Plg* + Nm_Plg + Alamat + Kota + Kd_Pos
7. ENTITY RELATIONSHIP DIAGRAM (ERD)
Diagram hubungan entitas (Entity Relationship Diagram) adalah diagram yang menerangkan tentang:
Informasi apa saja yang terkandung didalam media penyimpanan (data storage). Hubungan apa yang ada diantara media penyimpanan (data storage).
Hubungan entitas adalah model jaringan kerja yang menguraikan susunan data yang disimpan dari sistim secara acak.
Abstraksi yang dipakai untuk mengurai data, lihat simbol dalam DFD,
7.1. ENTITAS
Entitas merupakan sebuah lingkungan elemen, sebuah sumber atau transaksi yang mana merupakan hal penting bagi perusahaan yang didokumentasikan dengan data.
Entitas ini digambarkan dengan empat persegi panjang.
7.2. RELASI (RELATIONSHIP)
Relationship merupakan hubungan antara entitas atau lebih. Digambarkan dengan diamond.
7.3. CARDINALITY
Cardinality merupakan hubungan antara entitas yang satu dengan yang lainnya, terdiri dari satu ke satu (one to one), satu ke banyak (one to many) dan banyak ke banyak (many to many).
8. DIAGRAM WARNIER
Diagram ini memungkinkan analis menggambarkan informasi dalam bentuk hirarki dengan baik dan dilengkapi dengan struktur program dan logika program serta struktur datanya.
Contoh : Pengulangan
9. SISTEM PENGEMBANGAN JACKSON (JSD – JACKSON SYSTEM DEVELOPMENT)
Menjelaskan analisis domain informasi dan hubungan dengan program dan perancangan sistim. Langkah-langkah JSD adalah :
9.1. ENTITY ACTION STEP 9.2. ENTITY STRUKTUR STEP 9.3. INITIAL MODEL STEP 9.4. FUCTION STEP
9.5. SYSTEM TIMING STEP 9.6. IMPLEMENTATION STEP
9.1. ENTITY ACTION STEP
Entity adalah orang, objek, organisasi yang menghasilkan atau memakai informasi. Sedangkan action (aksi) adalah tindakan yang terjadi dan mempengaruhi entity.
9.2. ENTITY STRUKTUR STEP
Tindakan yang mempengaruhi entity, dikerjakan dalam waktu dan digambarkan dengan diagram Jackson.
9.3. INITIAL MODEL STEP
Entity dan action yang digambarkan sebagai model proses, hubungan antar model dengan dunia nyata didefinisikan.
9.4. FUCTION STEP
Spesifikasi fungsi yang berhubungan dengan definisi aksi.
9.5. SYSTEM TIMING STEP
Karakteristik proses penjadwalan yang akan dinilai dan spesifikasinya.
9.6. IMPLEMENTATION STEP
10. SADT (STRUCTURAL ANALYSIS AND DESIGN TECHNIQUE)
Digunakan sebagai alat bantu otomatis untuk pendefinisian sistim, analisis keperluan perangkat lunak dan perancangan perangkat lunak.
Terdiri dari prosedur-prosedur yang mengizinkan analis sistim untuk memecah-mecah permasalahan yang ada, menggunakan notasi grafik dan juga menyediakan petunjuk pengawasan untuk penerapan metodologi pada proyek.
Simbol yang digunakan pada SADT :
AKTIGRAM
