BAB I PENGENALAN REKAYASA PERANGKAT LUNAK 1.informatikaunindra.org/file/RPL/Diktat/Diktat...

Rekayasa Perangkat Lunak

1

BAB I

PENGENALAN REKAYASA PERANGKAT LUNAK

1. Perangkat Lunak

1. Pengertian Perangkat Lunak

Gambaran perangkat lunak pada sebuah buku teks mungkin mengambil bentuk

berikut : (1) perintah (program komputer) yang bila dieksekusi memberikan fungsi dan

unjuk kerja seperti yang diinginkan. (2) Struktur data yang memungkinkan program

memanipulasi informasi secara proporsional, dan (3) dokumen yang menggambarkan

operasi kegunaan program.

2. Karakteristik Perangkat Lunak

Perangkat lunak lebih merupakan elemen logika dan bukan merupakan elemen

fisik. Dengan demikian, perangkat lunak memiliki ciri yang berbeda dari perangkat

keras. Ciri-ciri yang membedakan tersebut antara lain :

1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang

klasik.

Meskipun terdapat kesamaan antara pembuatan perangkat keras dan pengembangan

perangkat lunak, yaitu kualitas yang tinggi bisa dicapai melalui perancangan yang

baik, tetapi di dalam fase pembuatan perangkat keras selalu saja ditemukan masalah

kualitas yang tidak mudah disesuaikan dengan perangkat lunak.

2. Perangkat lunak tidak pernah usang

Gambar 1.1. Kurva Kegagalan Perangkat Keras

Gambar 1.1 menggambarkan laju kegagalan sebagai fungsi waktu untuk

perangkat keras, disebut ‘kurva bathtub”, menunjukkan bahwa perangkat keras

mengalami laju kegagalan yang sangat tinggi pada awal hidupnya, yang disebabkan

kematian

segera usang

Waktu

Tingkat

Kegagalan


2

oleh perancangan atau cacat pembuatannya. Setelah diperbaiki maka laju kegagalan

menurun, kemudian naik lagi pada saat komponen perangkat keras terkena

penumpukkan debu, getaran, suhu tinggi, serta pengaruh lingkungan yang lain.

Secara singkat dapat dikatakan bahwa perangkat keras sudah mulai usang.

Sedangkan perangkat lunak tidak rentan terhadap pengaruh lingkungan yang

merusak dan menyebakan perangkat keras menjadi usang.

Gambar 1.2 secara teoritis menggambarkan tingkat kegagalan perangkat lunak.

Kesalahan-kesalahan yang tidak ditemukan akan menyebabkan tingkat kegagalan

tinggi pada awal hidup program, tetapi itu dapat diperbaiki sehingga kurvanya

menjadi datar. Secara singkat perangkat lunak tidak usang, meskipun pada

kenyataannya semakin lama makin memburuk.

Gambar 1.2. Kurva Kegagalan Perangkat Lunak

Selama masa hidupnya, perangkat lunak mengalami perubahan (pemeliharaan).

Sewaktu perubahan dibuat, kesalahan lain akan muncul yang menyebabkan kurva

kegagalan naik secara cepat. Lihat Gamabr 1.3. Setelah semua kesalahan diperbaiki

maka kurva akan menjadi normal kembali. Kemudian secara perlahan tingkat laju

kesalahan minimum mulai naik – perangkat lunak mulai memburuk sehubungan

perubahan yang dilakukan.

Pada tingkat yang sama

sampai usang

Waktu

Tingkat

Kegagalan


3

Gambar 1.3. Kurva Kegagalan Aktual Perangkat Lunak

Aspek lain dari keusangan yang membedakan antara perangkat keras dan lunak

adalah bila perangkat keras telah usang maka bisa diganti dengan suku cadangnya,

tetapi tidak demikian dengan perangkat lunak.

3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat dirakit

dari komponen yang sudah ada.

Perhatikan bagaimana perangkat keras komputer dirancang dan dibuat. Pengembang

desain menggambar skema sederhana dari rangkaina digital, melakukan serangkaian

analisis dasar untuk memastikan bahwa fungsi yang tepat dapat dicapai serta

kemudian menyesuaikan ke katalog komponen digital. Setiap IC (chip) mempunyai

nomor tersendiri, sebuah fungsi yang telah tervalidasi, interface yang didefinisikan

dengan baik, serta rangkaian standar tuntunan integrasi. Setelah masing-masing

komponen diseleksi, perangkat keras bisa dipesan secara terpisah. Tidak demikian

dengan pengembangan perangkat lunak, katalog komponen perangkat lunak tidak

ada. Memang memungkinkan memesan perangkat lunak secara terpisah, tetapi tetap

merupakan satu kesatuan yang lengkap, bukan sebagai komponen yang dapat

dipasang ke dalam program-program yang baru.


4

3. Evolusi Perangkat Lunak.

Pada awal tahun 1990-an Toffler menggambarkan adanya pergeseran kekuatan

dimana struktur kekuatan lama (pemerintah, pendidikan, industri, dan militer)

mengalami disintegrasi ketika komputer membawa ke arah demikratisasi pengetahuan.

Sedangkan pada tahun 1992 Yourdon mengkawatirkan perusahaan-perusahaan Amerika

akan kehilangan sisi kompetitif mereka di dalam bisnis yang berhubungan dengan

perangkat lunak dan meramalkan penurunan serta jatuhnya para pemrogram Amerika.

Tahun 1993 Hammer dan Champy berpendapat bahwa teknologi informasi akan

memainkan peranan sentral dalam pengembangan kerjasama. Pada pertengahan tahun

1990 daya tembus komputer dan perangkat lunak menimbulkan banyak pendapat bahwa

komputer menekankan sisi legitimasi tetapi mengabaikan keuntungan besar yang

diperoleh.

Perkembangan perangkat lunak bisa digambarkan pada Gambar 1.4. Pada masa

awal era komputer, perangkat lunak dilihat hanya sebagai suatu permenungan.

Pemrogram komputer menjadi sebuah seni “seat-of-pants” dimana di situ terdapat

beberapa metode yang sistematis. Perkembangan perangkat lunak sebenarnya tidak bisa

diatur sampai terjadi jadwal yang bergeser, atau biaya yang mulai melonjak. Para

pemrogram kemudian berusaha untuk membuat semuanya benar kembali, dan dengan

cara yang heroik akhirnya mereka berhasil. Pada masa itu perangkat lunak dirancang

secara khusus untuk aplikasi tertentu saja dan hanya memiliki areal distribusi yang

terbatas. Produk perangkat lunak yang dijual kepada pelangan atau masyarakat masih

langka. Kebanyak dikembangkan dan digunakan oleh orang atau organisasi yang sama,

dibuat untuk dipakai sendiri.

Era kedua evolusi sistem komputer antar pertengahan tahun 1960 dan 1970-an.

Sistem multiprogram dan multiuser memperkenalkan konsep baru interaksi manusia dan

mesin. Teknik interaktif membuka sebuah dunia aplikasi yang baru serta tingkat

kecanggihan perangkat lunak dan perangkat keras yang baru pula. Sistem real-time

mampu melakukan pengontrolan dalam menghasilkan output tidak lagi dalam skala

menit, melainkan detik. Kemajuan dalam penyimpanan on-line membawa ke generasi

pertama sistem mamajemen database. Pada era kedua ini juga ditandai dengan

kehadiran software-house. Produk perangkat lunak didistribusikan ke pasar yang lebih

luas dan multidisiplin. Program mainframe dan minikomputer didistribusikan kepada


5

masyarakat luas. Pengusaha, pemerintah, industri, serta akademisi masing-masing

mengembang-kan paket perangkat lunak paling mewah dengan mengeruk banyak uang.

Tahun-tahun

awal

Era kedua Era Ketiga Era keempat

- Orientasi batch - Multi user - Sistem terdistribusi - Sistem desk-top

bertenaga kuat

- Distribusi

terbatas - Realtime

- embedded

intelegence

- Teknologi berorientasi

objek

- Perangkat

lunak

kustomasi

- Database - Perangkat keras

biaya rendah - Sistem pakar

- Perangkat

lunak produk - Jaringan saraf tiruan

- Komputasi paralel

- Komputer jaringan

Gambar 1.4. Evolusi Perangkat Lunak

Era ketiga evolusi sistem komputer dimulai pertengahan tahun 1970-an dan berlangsung

lebih dari satu dekade penuh. Sistem terdistribusi dan multikomputer menambah

kompleksitas sistem berbasis komputer. Jaringan area global dan lokal, jaringan

komunikasi digital dengan bandwidh yang tinggi serta pertambahan permintaan untuk

akses “sesaat” sangat mendongkrak perkembangan perangkat lunak. Era ketiga ini juga

ditandai dengan kehadiran dan penyebaran pemakaian mikroprosesor, sehingga produk-

produk pintar, seperti automobil, microwave, robot sampai peralatan kedokteran bisa

dihasilkan. Yang paling penting pada era ini adalah munculnya komputer personal (PC

= Personal Computer).

1950 1960 1970 1980 1990 2000


6

Evolusi sistem komputer era keempat menjauhkan kita dari komputer individual

dan program komputer untuk menuju pengaruh kolektif dari komputer dan perangkat

lunak. Mesin desktop yang kuat yang dikontrol oleh sistem operasi yang canggih,

jaringan lokal dan global, serta didukung dengan aplikasi perangkat lunak yang maju,

menjadi sebuah aturan. Arsitektur penghitungan berubah dari lingkungan mainframe

yang terpusat ke lingkungan klien/server yang terdesentralisasi. Dan yang paling

penting pada era ini adalah internet sudah dapat dilihat sebagai perangkat lunak yang

dapat diakses oleh para pemakai individual.

Tetapi selama era evolusi sistem berbasis komputer, serangkaian masalah yang

berhubungan ddengan perangkat lunak masih muncul dengan intensitas yang terus

bertambah, misalnya :

1. Kemajuan perangkat keras terus berlajut, melampaui perkembangan perangkat

lunak yang sesuai dengan perangkat keras yang ada.

2. Kemampuan pengembangan perangakt lunak tidak cukup sepat untuk memenuhi

kebutuhan bisnis dan pasar.

3. Pemakaian komputer yang semakin luas membuat masyarakat semakin

tergantung pada perangkat lunak yang reliabel.

4. Sistem desain dan sumberdaya untuk mengembangkan perangkat lunak kurang

memadai, sehingga masih sulit untuk dibagun perangkat lunak dengan

reliabilitas dan kualitas yang tinggi.

4. Aplikasi Perangkat Lunak

Perangkat lunak dapat diaplikasikan ke berbagai situasi dimana serangakaian

langkah prosedural (seperti algoritma) telah didefinisikan. Kandungan (content) dan

determinasi informasi merupakan faktor penting dalam menentukan sifat aplikasi

perangkat lunak. Content mengarah pada arti dan bentuk informasi yang masuk dan

keluar. Misalnya, banyak aplikasi bisnis memakai data input dengan struktur data lebih

tinggi (misal database) dan mengahasilkan laporan yang sudah terformat. Perangkat

lunak yang mengontrol mesin otomatis menerima bentuk data diskrit dengan struktur

yang terbatas dan menghasulkan perintah mesin individual dalam ekskusi yang cepat.

Sedangkan determinasi informasi merujuk pada predikbilitas urutan dan timing

informasi.


7

Berikut beberapa jenis aplikasi perangkat lunak :

a. Perangkat lunak sistem. Sekumpulan program untuk melayani program–program

lain, misalnya sistem operasi, kompiler, editor, utilitas pengatur file, driver, prosesor

telekomunikasi.

b. Perangkat lunak real-time. Program-program untuk mengontrol/menganalisis/

memonitor kejadian dunia nyata pada saat terjadinya. Misalnya program untuk

mengontrol mesin industri.

c. Perangkat lunak bisnis. Program untuk pemrosesan informasi di dunia bisnis, mulai

dari payroll, account payable, inventory, post system, sampai perangkat lunak

sistem informasi manajemen yang bisa mengakses satu atau lebih database.

d. Perangkat lunak teknik dan ilmu pengetahuan. Jangkauan aplikasinya meliputi,

asmronomi, vulkanologi, kedokteran, analisis otomotif, biologi, mesin-mesin pabrik,

sampai pada perangkat bantu dalam perancangan (computer aided design) untuk

konstuksi bangunan, komponen elektronik, rancangan mesin, simulasi sitem, dan

lain-lain.

e. Embeded Software. Program yang disertakan dalam suatu perangkat dan berfungsi

untuk mengontrol hasil serta sistem perangkat tersebut. Contoh : key pad control

untuk microwave, fungsi digital pada automobil (pengontrol bahan bakar,

penampilan dash board, sistem rem, dll).

f. Perangkat lunak komputer personal. Program–program yang bisa dijalankan pada

komputer personal. Contoh : pengolah kata, multimedia, hiburan, manajemen

database, aplikasi keuangan bisnis, dll.

g. Perangkat lunak kecerdasan buatan dan jaringan syaraf tiruan. Sistem pakar atau

disebut juga sistem berbasis pengetahuan. Program yang digunakan untuk

menggerakkan/mengontrol robot, permainan game, pengolah gambar dan pola

(image dan voice).


8

2. Rekayasa Perangkat Lunak

1. Pengertian Rekayasa Perangkat Lunak

Pada tahun 1969 Fritz Bauer memberikan definisi rekayasa perangkat lunak

adalah sebagai berikut :

“The establishment and use of sound engineering principles in order to

obtain economically software that is reliable and work efficiently on

real machines.”

Hampir setiap pembaca tergoda untuk menambah sendiri definisi tersebut,

karena definisi tersebut hanya menyinggung sedikit saja tentang aspek teknis dan

kualitas perangkat lunak, dan tidak secara langsung menyinggung kebutuhan dan

kepuasan pelanggan, pengabaikan pencamtuman pentingnya pengukuran dan matriks,

tidak menyinggung pentingnya sebuah proses. Apakah sound enginnering aplication

yang dapat diaplikasikan kepada pengembangan komputer? Bagaimana kita secara

ekonomis membangun perangkat lunak sehingga menjadi dapat diandalkan dan

reliable? Apakah yang dibutuhkan untuk menciptakan program komputer yang bekerja

secara efisien pada lebih dari satu mesin riril yang berbeda? Pertanyaan-pertanyaan ini

masih terus menjadi tantangan bagi pengembangan perangkat lunak.

Pada tahun 1985 Richard Fairly mendefinisikan rekayasa perangkat lunak

sebagai berikut :

“The technological and managerial dicipline concernment with

systematic production and maintenance of software products that are

developed and modified on time and within cost estimates.”

Definisi ini sudah menyinggung aspek teknis pengembangan perangkat lunak,

pengelolaan tim yang terlibat dalam pengembangan tersebut, pemeliharaan perangkat

lunak yang telah dikembangkan, serta waktu serta biaya pengem-bangan.

Kemudian pada tahun 1993, IEEE mengembangkan definisi yang lebih

komprehensif yaitu sebagai berikut :

Rekayasa perangkat lunak adalah : (1) Aplikasi dari sebuah pendekatan

kuantifiabel, disiplin, dan sistematis terhadap pengembangan, operasi,

dan pemeliharaan perangkat lunak; yaitu aplikasi dan rekayasa

perangkat lunak; (2) Studi tentang pendekatan-pendekatan tentang (1).


9

2. Lingkup Rekayasa Perangkat Lunak

Lingkup rekayasa perangkat lunak bisa digambarkan seperti Gambar 1.5.

Rekayasa perangkat lunak merupakan suatu kegiatan untuk menghasilkan suatu produk,

sehingga harus berada pada satu komitmen dasar menuju kualitas. Untuk itu fokus

kualitas menjadi batu landasanya. Lingkup kedua adalah proses. Proses-proses rekayasa

perangkat lunak adalah perekat yang menjaga bentangan teknologi secara bersama-sama

dan memungkinkan perkembangan perangkat lunak yang tepat waktu dan rasional.

Proses-proses tersebut membatasi kerangka kerja untuk serangkaian area proses kunci

yang harus dibangun demi keefektifan penyampaian teknologi pengembangan perangkat

lunak. Area proses kunci ini membentuk dasar bagi kontrol manajemen proyek

pengembangan perangkat lunak serta membangun kontek dimana metode teknis

diaplikasikan sehingga sebuah produk yang berkualitas bisa dihasilkan.

Gambar 1.5. Lingkup Rekayasa Perangkat Lunak.

Lingkup berikutnya adalah metodologi, yaitu sekumpulan metode untuk

melaksanakan setiap tahap pengembangan perangkat lunak, yang meliputi : perencanaan

dan estimasi proyek, analisa kebutuhan, prosedur algoritma dan arsitektur program,

menulis program (coding), pengujian (testing), dan pemeli-haraan (maintenance).

Terakhir adalah perangkat bantu (tools). Perangkat bantu yang dimaksus adalah suatu

perangkat, baik lunak atau keras, otomatis maupun semi-otomatis yang bisa digunakan

untuk proses pengembangan perangkat lunak. Tools untuk rekayasa perangkat lunak

disebut computer-aided sofware engineering (CASE). CASE ini terus dikembangkan

untuk menciptakan lingkungan rekayasa perangkat lunak sehingga analog dengan

CAD/CAE (computer-aided design/engineering) pada pengembangan perangkat keras.

Fokus kualitas

proses

metodologi

perangkat bantu


10

3. Paradigma Rekayasa Perangkat Lunak

Untuk menyelesaikan masalah aktual didalam sebuah seting industri, rekayasa

perangkat lunak atau tim perekaysa harus menggabungkan strategi pengembangan yang

mencakup semua lingkup rekayasa perangkat lunak seperti yang digambarkan pada

Gambar 1.5 tersebut . Strategi ini sering disebut paradigma atau model proses rekayasa

perangkat lunak.

Perkembangan perangkat lunak bisa dianggap sebagai lingkaran pemecahan

masalah dimana terdapat empat keadaan berbeda, yaitu status quo, definisi masalah,

perkembangan teknis pemecahan masalah, dan integrasi pemecahan menyampaikan

hasil (dokumen, program, data, fungsi bisnis baru, produk baru) kepada yang

membutuhkan hasil/produk tersebut. Lihat Gambar 1.6.

Lingkaran pemecahan masalah tersebut digunakan pada tingkat makro ketika

bagian dalam aplikasi dipakai; pada tingkat tengah ketika komponen program

direkayasa; dan pada tingkat mikro ketika baris-baris kode ditulis. Masing-masing

keadaan di dalam pemecahan masalah tersebut berisi lingkaran yang identik. Lihat

Gambar 1.7. Tanpa memperdulikan model proses yang dipilih untuk suatu proyek

rekayasa perangkat lunak, semua keadaan tersebut -- status quo, definisi masalah,

perkembangan teknis pemecahan masalah, dan integrasi pemecahan – secara simultan

hidup berdampingan pada beberapa tingkatan / tahapan detail.

Dalam subbab ini akan dibahas beberapa model proses yang berbeda pada

rekaya perangkat lunak.

Gambar 1.6. Fase lingkaran pemecahan masalah

Definisi masalah

Penyatuan Solusi

Pengembangan Teknis Status

Quo


11

Gambar 1.7. Fase-fase di dalam lingkaran pemecahan masalah

a. Siklus Hidup Klasik

Paradigma siklus hidup klasik untuk rekayasa perangkat lunak diilustrasikan

seperti pada Gambar 1.8. Disebut juga sebagai “model air terjun”.

Beberapa kelebihan model ini adalah :

1) Titik awal dan titik akhir yang eksplisit

2) Setiap tahapan didefinisikan dengan jelas

3) Setiap akhir suatu tahap, disesuikan kembali dengan tahap sebelumnya, sehingga

kesalahan yang mungkin terjadi bisa ditemukan dan diselesaikan lebih dini.

Definisi masalah

Penyatuan Solusi

Pengembangan Teknis

Status Quo

Definisi masalah

Penyatuan Solusi

Pengembangan Teknis

Status Quo

Definisi masalah

Penyatuan Solusi

Pengembangan Teknis

Status Quo Status

Quo


12

4) Incremental release, lingkup kerja untuk tahapan-tahapan berikutnya menjadi lebih

kecil, dan tugas yang lebih mudah. Jika tahap awal dilakukan dengan benar maka

akan mempermudah tahap berikutnya.

Gambar 1.8. Paradigma Siklus Hidup Klasik : “Model Air Terjun”

Aktivitas setiap tahapannya adalah :

1) System Engineering : Pengumpulan kebutuhan seluruh elemen sistem

2) Sofware Requirements Analysis : Pengumpulan kebutuhan dengan berfokus pada

perangkat lunak, meliputi : domain informasi, fungsi, unjuk kerja, antar muka

3) Design, meliputi : Perancang struktur data, arsitektur perangkat lunak, rincian

prosedural, karakteristik antar muka

4) Coding : penerjemah perancang ke bentuk yang dapat dimengerti oleh mesin

5) Testing, mencakup kegiatan : penguji lojikal, penguji fungsional, menemukan

kesalahan dan memastikan suatu masukan diproses menjadi keluaran yang sesuai

dengan yang diinginkan

6) Maintenance, bagian terujung dari siklus pengembangan dan dilakukan setelah

perangkat lunak dipergunakan. Kegiatan adalah corrective maintenance, yaitu

mengkoreksi kesalahan pada perangkat lunak, yang baru terdeteksi pada saat

perangkat lunak dipergunakan

Software

Enginering

Analysis

Design

Coding

Testing

Maintenance


13

Model air terjun adalah paradigma rekayasa perangkat lunak yang paling luas

dipakai dan paling tua. Tetapi kritik terhadap paradigma tersebut menyebabkan banyak

pihak yang mempertanyakan kehandalannya. Masalah-masalah yang timbul ketika

model tersebut diterapkan adalah :

1. Meskipun dalam prosesnya model ini bisa mengakomodasi iterasi, tetapi tidak

dilakukan secara langsung, akibatnya perubahan-perubahan dapat menyebabkan

keraguan pada saat tim proyek berjalan.

2. Kadang-kadang pelanggan sulit untuk menyatakan semua kebutuhannya secara

eksplisit, sehingga sulit untuk mengakomodasi ketidakpastian tersebut.

3. Pelanggan harus bersikap sabar, karena masa pakai dari program tidak akan

diperoleh sampai akhir waktu proyek berakhir. Akibatnya bisa saja terdapat

kesalahan yang tidak tedeteksi sampai program tersebut tiba masanya untuk dikaji

ulang.

4. Pengembang sering melakukan penundaan yang tidak perlu, karena seringnya

beberapa anggota tim proyek harus menunggu anggota lain untuk melengkapi tugas

yang saling ketergantungan.

b. Model Prototype

Sering kali seorang pelanggan mendefinisikan serangkaian umum bagi

perangkat lunak yang dibutuhkan, tetapi tidak mengidentifikasi kebutuhan output,

pemrosesan, maupun input secara detail. Pada kasus lain, pengembang tidak memiliki

kepastian terhadap efisiensi algoritma, kemampuan penyesuaian dari sebuah sistem

operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin.

Dalam hal ini, paradigma prototipe menawarkan pendekatan yang terbak.

Paradigma ini dimulai dengan mengumpulkan kebutuhan. Pengembang dan

pelanggan bertemu untuk mendefinisikan obyektif keseluruhan dari perangkat lunak.

Kemudian dilakukan perancangan kilat yang berfokus pada penyajian dari aspek-aspek

perangakt lunak yang akan nampak oleh pelanggan/pemakai (misal format input dan

outputnya). Perancangan kilat tersebut membawa kepada konstruksi prototipe. Prototipe

ini dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan

pengembangan perangkat lunak yang dibutuhkan. Iterasi terjadi pada saat prototipe


14

disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan

pengembang untuk secara lebih baik memahami apa yang harus dilakukan.

Prototipe bisa berfungsi sebagai “sistem awal”. Tetapi pada beberapa proyek

yang dibangun dengan prototipe, saat penggunaan pertama sistem awal yang baru

dibangun tersebut, mungkin akan terasa terlalu pelan, terlalu besar, janggal dalam

pemakaian, atau bahkan tiga hal tersebut semua terjadi. Jika terjadi demikian maka tidak

ada pilihan lain kecuali memulai lagi untuk membangun versi yang baru dimana

masalah yang muncul bisa diselesaikan.

c. Model RAD (Rapid Aplication Development).

RAD adalah merupakan model proses pengembangan perangkat lunak adaptasi

kecepatan tinggi dari model sekuensial linier yang menekankan siklus perkembangan

yang sangat pendek. Perjalanan pengembangannya sangat cepat dengan menggunakan

pendekatan konstruksi berbasis komponen, yang memungkinkan tim pengembang bisa

menciptakan sistem fungsional secara utuh dalam waktu 60 s.d. 90 hari. Pada umumnya

digunakan pada aplikasi sistem konstruksi.

Pendekatan RAD melingkupi fase-fase sebagai berikut :

1) Businnes modelling. Pemodelan dari aliran informasi diantara fungsi-fungsi bisnis.

2) Data modelling. Mengidentifikasi serangkaian objek data yang dibutuhkan dan

karakteristik masing-masing objek tersebut, serta mendefinisikan hubungan antara

objek-objek tersebut.

3) Proses modelling. Mentransformasikan hasil data modelling untuk mencapai aliran

informasi yang perlu bagi implementasi fungsi-fungsi prosesnya. Gambaran proses

dibuat untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali

sebuah objek data.

4) Aplication generation. RAD mengasumsikan pemakaian teknik generasi keempat

(4GL), lebih banyak memakai komponen program yang sudah ada, juga

menciptakan komponen yang bisa dipakai lagi.

5) Testing and turnover. Karena proses RAD menekankan pada pemakaian kembali,

maka setiap komponen baru harus diuji untuk mengurangi keseluruhan waktu

pengujian


15

Kelemahan model RAD :

1) Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusi

yang memadai untuk menciptakan jumlah tim RAD yang baik.

2) RAD menuntut pengembang dan pelanggan memiliki komitmen tinggi di dalam

aktivitas pengembangan.

Gambar 1.9. Model RAD

Disamping tiga model di atas, masih banyak lagi model proses rekayasa

perangkat lunak yang lain, yaitu :

1) Model Proses Rekayasa Perangkat Lunak Evolusioner, antara lain :

a) Model Pertambahan

b) Model Spiral

c) Model Rakitan Komponen

d) Model Perkembangan Konkuren

Pemodelan

bisnis

Pemodelan

data

Pemodelan

Proses

Pembentukan

aplikasi

Pengujian

& turnover

Pemodelan

bisnis

Pemodelan

data

Pemodelan

Proses

Pembentukan

aplikasi

Pengujian

&

turnover

Pemodelan

bisnis

Pemodelan

data

Pemodelan

Proses

Pembentukan

aplikasi

Pengujian

& turnover

Tim #1

Tim #2

Tim #3


16

2) Model Formal

3) Teknik Generasi Keempat (4GL)

Model-model itu bisa anda baca di buku “Software Engineering” yang ditulis oleh

Rogers. Pressman, PhD.

3. Rekayasa Sistem Komputer

Dengan melihat definisi dari Webster’s, kita mendefinisikan sistem berbasis

komputer sebagai:

“serangkaian atau tatanan elemen-elemen yang diatur untuk mencapai tujuan yang

ditentukan sebelumnya melalui pemrosesan informasi”

Tujuannya adalah untuk mendukung berbagai fungsi bisnis atau untuk mengembangkan

suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis. Untuk mencapai

tujuan tersebut, sistem berbasis komputer menggunakan berbagai elemen sistem:

a) Perangkat lunak, program komputer, struktur data, dan dokumen yang

berhubungan yang berfungsi untuk mempengaruhi metode logis, prosedur, dan

kontrolyang dibutuhkan.

b) Perangkat keras, perangkat elektronik yang memberikan kemampuan

penghitungan, dan perangkat elektromekanik (misalnya: sensor, rotor,

pompa)yang memberikan fungsi dunia eksternal.

c) Manusia, pemakai dan operator perangkat lunak dan perangkat keras.

d) Database, kumpulan informasi yang besar dan terorganisasi yang diakses

melalui perangkat lunak.

e) Dokumentasi, manual, formulir, dan informasi deskriptif lainnya yang

menggambarkan penggunaan dan pengoprasian sistem.

f) Prosedur, langkah-langkah yang menentukan penggunaan khusus dari masing

elemen sistem atau konteks prosedural dimana sistem berada.

Satu karakteristik sistem berbasis komputer yang rumit adalah bahwa elemen yang

berisi satu sistem juga dapat mewakili satu elemen makro dari suatu sistem yang

sangat besar. Elemen makro adalah suatu sistem berbasis komputer yang merupakan

bagian dari sistem berbasis komputer yang lebih besar lagi. Peran rekayasa sistem

adalah membatasi elemen-elemenuntuk sistem berbasis komputer tertentu dalam

konteks keseluruhan hirarki sistem (elemen makro). Berikut adalah tugas-tugas yang

merupakan rekayasa sistem komputer:


17

Sistem Otomasi Pabrik

Sistem Pemanufakturan Sistem Inventori Sistem Informasi

Sistem Aliran Material Sel pemenufakturan

RobotMesin NC Perangkat Entry Data

Gambar 1.10. Sistem dari banyak sistem


18

BAB II

DASAR ANALISIS KEBUTUHAN

2.1. Lingkup Analisis

a) Pengenalan Permasalahan

b) Evalusi dan Sintesis

c) Pemodelan

d) Spesifikasi

e) Peninjauan Ulang

Gambar 2.1 Hubungan Antara Analisis dan Perancangan

Dalam menemukan area permasalahan, perlu adanya komunikasi yang intensif

dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari

salah interpretasi.

Pertanyaan pertama memfokuskan pada pengertian dasar permasalahan :

1. Menemukan yang membutuhkan software tersebut :

a. Siapa yang membutuhkan sistem (serta personal di belakangnya?)

b. Siapa yang akan menggunakan solusi

c. Apa yang akan menjadi keuntungan ekonomis dari solusi yang baik

d. Adakah sumber lain dari solusi yang dibutuhkan

2. Bentuk solusi yang diinginkan

a. Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan

dihasilkan oleh solusi yang benar

b. Masalah-masalah apa yang akan dicarikan solusinya?

c. Lingkungan solusi yang akan digunakan

d. Adakah isukah isu atau kendala khusus yang berdampak kepada solusi 3. Efektifitas

a. Mendapatkan person yang benar/berhak atas jawaban pertanyaan,

b. Apakah pertanyaan yang diajukan relevan dengan permasalahan

c. Adakah personal lain yang dapat menambah informasi

Analisis

Peran- cangan

Apa ? Bagaimana ?


19

d. Adakah hal lain yang perlu ditambahkan?

Jenis Kebutuhan: 1) Kebutuhan Fungsional

Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap

input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem

dilihat dari kacamata pengguna)

2) Kebutuhan Non-Fungsional

Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses

pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan

storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O,

representasi sistem dll.

2.2. Sistem Analis

a) Dituntut untuk dapat memiliki Kemampuan :

a. Pemimpin Proyek

b. Mediator

c. Inovator

d. Arkeolog

b) Nama Lain : System Engineer, Chief System Designer, Programmer/Analyst

dsb

Gambar 2.2 Cara Kerja Sistem Analis

c) Prinsip-Prinsip Analisis :

a. Domain Informasi dari masalah harus dapat direpresentasikan dan

mudah dimengerti

b. Harus ada model yg dpt mengambarkan fungsi dan perilaku sistem

c. Model dan masalah harus dapat dibuat bertingkat (dipartisi) perinciannya

Clien

t Pengem

bang

Konsultan/Specifi

er

(Perancang

Senior)


20

d. Proses Analisis harus berpindah dari informasi dasar ke perincian

implementasi

2.3. Domain Information

Tirdiri dari 3 pandangan : Information Flow, Information Content, dan Information

Sructure

a) Information Flow mempresentasikan bagaimana data dan kontrol berubah

dalam perjalananannya melalui sistem

b) Information Content merepresentasikan item-item individual dari data dan

kontrol yang lebih besar

c) Information Structure merepresentasikan organisasi internal dari item-item data

kontrol

Gambar 2.3 Struktur Informasi

2.4. Pemodelan

Harus dapat memodelkan informasi yang diolah oleh perangkat lunak, fungsi dan

sub fungsi yang memungkinkan pengolahan dan perilaku sistem ketika pengolahan

dilakukan. Dapat berupa notasi grafis atau tekstual.

1. Peranan Model :

a) Membantu analisis dalam pemahaman informasi fungsi dan dan prilaku sistem

sehingga aktivtas analisis kebutuhan menjadi lebih mudah dan lebih sistematis

Transform 1 Transfrom 2

Input

information

Output

information

Intermediate

information

Data Store


21

b) Merupakan poin kritis untuk peninjauan ulang yang penting untuk kelengkapan,

konsistensi dan ketetapan dari spesifikasi

c) Merupakan dasar untuk tahap perancangan dengan menyediakan kepada

perancang representasi dasar perangkat yang dapat dipetakan ke dalam konteks

implementasi.

2. Pembagian

a) Berguna untuk penyederhanan

b) Proses pembagian

a. pembagian vertikal untuk memperinci fungsi

b. pembagian horisontal untuk dekomposisi fungsi

2.5. Informasi Dasar dan Implementasi

Informasi Dasar merepresentasikan fungsi yang ingin dicapai dan informasi yang

akan diproses dengan mengabaikan perincian implementasi. Perincian implementasi

merepresentasikan manifestasi dunia nyata dari fungsi pemrosesan dan struktur

informasi

1. Kebutuhan Perangkat Lunak

Dapat dinyatakan dalam berbagai bentuk :

a) Gambar di atas kertas

b) Gambar di komputer ( dengan CASE Tool)

c) Prototype

d) Bahasa spesifikasi formal

2. Spesifikasi

a) Merupakan proses representasi dari kebutuhan sistem untuk suksesnya

implementasi perangkat lunak

b) Balzer dan Goldman memberikan 8 prinsip spesifikasi yang bagus, yaitu :

a. pisahkan fungsionalitas dari implementasi. Pusatkan pada ‘apa’ bukan

‘bagaimana’

b. dibutuhkan bhs spesifikasi sistem yang berorientasi pada proses

c. spesifikasi harus mencakup sistem dimana perangkat lunak adalah salah satu

komponen


22

d. spesifikasi harus meliputi lingkungan dimana sistem beroperasi

e. spesifikasi sistem merupakan model kognitif

f. spesifikasi harus dapat dioperasionalkan

g. spesifikasi sistem harus toleran terhadap ketidaklengkapan dan penambahan

h. spesifikasi harus terlokalisasi dan loosely coupled.


23

BAB III

ANALISA TERSTRUKTUR

3.1. Sejarah Analisa Terstruktur

1 Dipopularkan oleh DeMarco (1979)

2 Dikembangkan lebih lanjut oleh Page-Jones (1980), Gane dan Sarson (1982)

3 Dikembangkan untuk sistem waktu nyata (Real Time) oleh Ward dan Mellor

(1985) kemudian Hatley dan Pirbhai (1987)

4 Merupakan teknik pemodelan information flow dan information content

3.2. Data Flow Diagram (DFD)

DFD atau yang sering disebut juga Bubble Chart, Bubble Diagram, model proses,

diagram alur kerja, atau model fungsi, merupakan suatu diagram yang menggambarkan

aliran data dalam sebuah sistem.

Komponen DFD terbagi menjadi 4:

1) Terminator atau External Entity

External Entity adalah lingkungan luar dari sistem tetapi dia memiliki

pengaruh terhadap sistem. External Entity bisa digambarkan sebagai individu,

kelompok, atau sistem lain (bukan orang).

Notasi :

2) Proses

Proses berfungsi untuk mentransformasikan data secara umum. Karena proses

melakukan pekerjaan, maka dalam menamai sebuah proses dimulai dengan

kata kerja dan diikuti objek.

Suatu proses harus memiliki input dan output. Suatu proses juga dapat

dihubungkan dengan komponen External Entity, Data Store, atau Proses lain

melalui Aliran Data.

Konsumen


24

Notasi :

Model DeMarco/Yourdon Model Gane & Sarson

3) Data Store

Data Store berfungsi menyimpan data/ file. Data store biasanya berkaitan

dengan penyimpanan-penyimpanan secara komputasi, contoh: harddisk,

disket, dvd disc, namun bisa juga berupa seperti buku, alamat, agenda.

Data Store hanya dapat dihubungkan dengan komponen Proses melalui Alur

Data, tidak dengan komponen DFD lain.

Notasi :

Model DeMarco/Yourdon Model Gane & Sarson

4) Alur Data

Alur Data menggambarkan aliran data dari suatu proses ke proses lainnya.

Alur Data dapat merepresentasikan data/informasi yang berkaitan dengan

komputer seperti bit, bilangan real, karakter, maupun yang tidak seperti nama,

nim, alamat.

Notasi :

Diagram aliran data (DFD) memungkinkan perekayasa perangkat lunak untuk

mengembangkan model domain informasi dan domain fungsional pada saat yang sama.

Pada saat DFD disaring kedalam tingkah detail yang lebih tinggi, analis melakukan

suatu dekomposisi fungsional implisit dari sistem, sehingga memenuhi prinsip analisis

1

Periksa

Pesanan

1

Periksa

Pesanan

Pesanan Pesanan

Pesanan_barang


25

operasional keempat. Pada saat yang sama, penyaringan DFD menghasilkan suatu

penyaringan yang sesuai dari data pada saat dia bergerak melalui proses yang

membentuk aplikasi. Beberapa tuntunan sederhana dengan tak terukur dapat membantu

selama derivasi sebuah diagram alir data:

1) Diagram aliran data tingkat 0 (Nol) harus menggambarkan perangkat

lunak/sistem sebagai gelembung tunggal.

2) Input dan output utama harus dicatat secara hati-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) Satu gelembung pada suatu saat harus disaring.

Diagram Aliran Data Bertingkat

1. Dasar Pemikiran

a) ROSS

Pikiran manusia dapat menerima segala bentuk kerumitan, asalkan disajikan

dalam susunan yang terdiri bagian-bagian kecil yang mudah dimengerti

b) GEORGE MILLER

Pikiran manusia paling banyak dapat mengerti sesuatu yang terbagi menjadi 7 +

2 bagian dan tetap masih dapat mengerti konsep dari sesuatu tadi secara

keseluruhan .

2. Jenis DAD dalam DAD Bertingkat

a) Diagram konteks ( Context Diagram ): Diagram paling atas, terdiri dari satu

proses dan mengambarkan ruang lingkup sisrtem.

b) Diagram Prinsif Fungsional ( Functional Primitive ): Diagram-diagram paling

bawah, yang tidak dapat dibagi lagi atau memiliki masukan tunggal dan

keluaran tunggal atau telah sangat sederhana ( narasi untuk deskripsi dapat

dituliskan secara singkat ).

c) Diagran tengah: Diagram-diagram yang terletak antara Diagram Konteks dan

Primitif Fungsional.


26

3. Penyusunan DAD

a. Penomoran

a) Diagram konteks biasanya diberi nomor 0

b) Proses-proses pada DAD paling atas diberi nomor mulai dari 1 dan seterusnya

sampai semua proses bernomor

c) Pada saat setiap proses dipecah menjadi DAD dengan tingkat yang lebih

rendah, maka proses pada DAD tersebut diberi nomor sesuai dengan nomor

proses tadi

d) Setiap proses diberi nomor yang merupakan kombinasi dari nomor diagram

diikuti dengan nomor urut dalam tingkay yang bersangkutan.

b. Bentuk Umum Diagram Konteks :

R

S

Gambar 2.5 Bentuk umum diagram konteks

a) Nomor Diagram “ ANAK” harus diawali dengan nomor proses pada diagram

‘ ORANG TUA “ yang terkait,

Diagram 0 Diagram 3

Gambar 2.6 Penomoran diagram konteks

TI

T2

O

SISTEM T3

1

2

3

3.1

3.2 3.3

AAA

Z

Z

Y

X

B

A X

Y

R

S

A


27

b) Dengan menyebutkan nomor diagram “ANAK “ yang sesuai dengan nomor

proses diagram pada diagram “ ORANG TUA ‘ yang terkait . Nomor proses

pada diagram ‘ ANAK “ boleh tidak diawali dengan nomor proses diagram ‘

ORANG TUA ‘

c) Aturan Keseimbangan ( Balancing )

Semua aliran data yang masuk dan keluar diagram “ ORANG TUA’ harus

ada/sama pada diagram ‘ ANAK’

Diagram 0 Diagram 3

Gambar 2.7 Balancing DFD

4. Kamus Data

Sebuah daftar terorganisasi dari komposisi setiap elemen data, aliran data, dan

penyimpanan data yang digunakan dalam sebuah DAD, serta spesifikasi lojik dari

proses juga modul dan dekripsi modul dari Bagan Susunan dari daftar dari Entitas dan

Relasi yang digunakan didalam Diagram E-R

Nama lain : Requirements Dictionary, Data Dictionary, Encylopedia.

Mengapa diperlukan ?

Karena adanya kebutuhan untuk mendifinisikan isi dari :

a) Aliran Data ( DAD )

b) Penyimpanan Data

c) Proses ( DAD )

d) Entitas ( ERD )

e) Relasi (ERD)

1

2

3

.1

.2 .3

AAA

Z

Z

Y

X

B

A X

Y

R

S

A


28

5. Notasi Kamus Data

Tabel 2.1 Simbol notasi kamus data

SIMBOL ARTI

=

+

{}

[ ]

( )

* *

Terdiri dari

Dan

Iterasi

Pilihan salah Satu

Boleh ada, boleh tidak

Komentar

Contoh Kamus Data

a) Data : Nomor Telepon

Name : telephon number

aliases : none

where used/low used : access against set-up (output) dial phone

(input)

description :

Telephone number = [ lokal extension | outside number ]

Lokal extension = [ 2001 | 2002 | …..| 2999 ]

Outside number = 9 + [ local number | long distance number ]

Local number = prefix + access number

Long distance number = ( 1 ) + area code + local number

Prefix = [ 795 | 799 | 874 | 877 ]

Access number = *any four number strings “


29

b) Arus Data : Surat Pengeluaran Barang

Nama Arus : Sales Order

Alias : SO

Bentuk Data : Cetakan komputer

Arus Data : Pelanggan – Proses pemesanan barang

Proses pemesanan – Data Store

Penjelasan : Untuk mencatat pemesanan barang

Periode : Setiap ada pesanan

Volume : Rata – rata tiap hari adalah 35

Struktur Data <Surat Pesanan Barang> = HEADER + ISI + FOOTER

HEADER = No_SO + Tanggal + Tgl-PO + No PO Costumer + Nama_Pelanggan +

Alamat + Telp

- No_SO : * Terdiri dari lima belas digit *

- Tanggal : Tanggal + Bulan + Tahun

- Nama_Plangan : (Titel) + Nama_depan + Nama_belakang

- Alamat : Jalan + Nomor + Kota

- Telepon : * Maksimal 14 digit *

ISI = 1 {KD_Item + Item + Nama_Barang + Satuan + Quantity + Harga/Unit +

Disc (%) + Jumlah} 20

- item : * Nomor urut *

- Nama Barang : * Jenis barang yang dipesan *

- Satuan : * Maximal tiga digit *

- Harga/unit : * Dalam Rupiah *

-Quantity : * Dihitung dari unit dikali harga satuan dikurangi

discount *

FOOTER = Total

- Total : * Total semua penjualan *

3.3. Entity Relationship Diagram (ERD)

Komponen dari ERD ada 6 yaitu

1) Entitas (Entity)


30

Entitas adalah suatu objek yang dapat dibedakan dari objek lain. Suatu entitas

haruslah bersifat fakta. Entitas dapat berupa fisik, contoh: Mobil, Rumah,

Gedung, dan dapat berupa konsep, contoh: Pekerjaan, Perusahaan.

2) Atribut (Attribute)

Atribut merupakan properti yang dimiliki setiap entitas yang datanya akan

disimpan. Contoh : atribut MAHASISWA -> NIM, Nama, Alamat.

3) Relasi(Relationship)

Asosiasi antara satu atau lebih entitas. Berupa kata kerja.

4) Kardinalitas (Cardinality)

Gambar 3.1 Kardinalitas

5) Kardinalitas menunjukkan banyaknya objek yang terlibat dengan objek lain pada

suatu relasi. Ada 3 kombinasi yang mungkin terjadi, diantaranya : 1:1 (One to

One), 1:N (One to Many), dan N:M (Many to Many).

6) Modalitas (Modality)

Partisipasi sebuah entitas pada suatu relasi. 0 berarti partisipasi parsial. 1 berarti

partisipasi total.

Diagram hubungan entitas memungkinkan seorang perekayasa perangkat lunak untuk

secara penuh menspesifikasikan objek data yang merupakan input dan output dari

sistem, atribut yang mendefinisikan sifat dari objek tersebut, dan hubungan antar objek.

Seperti kebanyakan model analisis elemen, ERD dikonstruksi didalam cara yang

iteratif. Pendekatan berikut ini diambil:

1) Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar “hal-hal”

yang akan ditujuoleh proses bisnis dan aplikasi. “hal-hal” ini dimasukan

kedalam sebuah daftar objek data input dan output dan entitas eksternal yang

menghasilkan atau mengkonsumsi informasi.


31

2) Dengan mengambil objek satu pada satu saat, analis dan pelanggan

mendefinisikan apakiah ada sambungan (tidak diberi nama pada tahap ini) ada

diantara objek data dan objek lain.

3) Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan

hubungan objek atau lebih.

4) Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan

modalitas.

5) Langkah 2 sampai 4 dilanjutkan secara iteratif sampai semua pasangan

hubungan objek sudah dudefinisikan. Sudah menjadi kebiasaan untuk

menemukan penghilangan pada saat proses ini berlanjut. Objek dan hubungan

baru akan ditambahkan pada saat jumlah iterasi bertambah.

6) Atribut dari masing-masing entitas didefinisikan.

7) Diagram hubungan entitas diformulasikan dan dikaji.

8) Langkah 1 sampai 7 diulang sampai pemodelan data terlengkapi.

3.4. State Transition Diagram (STD)

STD merupakan diagram yang memodelkan tingkah laku (behaviour) sistem

berdasarkan pada definisi satu bagian dari keadaan sistem. STD sering dipakai untuk

menggambarkan kinerja sistem. Komponen STD dibagi menjadi 4 :

a. State

State merupakan kondisi dari suatu sistem. State dapat dikategorikan

menjadi 2 macam, yaitu : State Awal dan State Akhir. State Awal hanya

boleh berjumlah 1 state, dan State Akhir boleh memiliki jumlah lebih dari

satu state.

b. State Change (Tanda Panah)

Menyatakan perubahan state dari sistem.

c. Kondisi

Kondisi menyatakan suatu kejadian pada lingkungan eksternal yang dapat

dideteksi oleh sistem, contoh: sinyal.


32

d. Aksi

sistem melakukan sesuatu sehingga terjadi perubahan state atau merupakan

suatu reaksi terhadap kondisi.


33

BAB IV

ANALISA DAN PERANCANGAN BERORIENTASI OBJEK

4.1. Konsep Umum Metodologi Berorientasi Objek

Ada beberapa tema yang mendasari teknologi berorientasi objek. Meski tema-tema ini

tidak unik pada sistem berorientasi objek, mereka sangat didukung pada metoda

analisis, perancangan serta implementasi dengan metodologi berorientasi objek. Tema-

tema object oriented:

1. Kelas

Kelas membungkus (encapsulating) objek-objek. Suatu kelas tunggal dapat

digunakan untuk menciptakansejumlah objek-objek. Selain itu, suatu kelas juga

dapat digunakan untuk menciptakan kelas-kelas lain yang mewarisi (inheritance)

sebagian atau seluruh data serta fungsi yang dimiliki oleh kelas yang disebutkan

terdahulu.

2. Abstraksi

Abstraksi adalah menemukan hal-hal yang esensial pada suatu objek dan

mengabaikan hal-hal yang sifatnya insidental. Maksudnya adalah menangkap

sesuatu yang berarti untuk dituangkan sistem/perangkat lunak alih-alih menangkap

seluruh fakta yang ada. Penggunaan konsep abstraksi selama analisis berarti

“jangan pernah melakukan perancangan dan implementasi sebelum persoalan

benar-benar dipahami”.

3. Pembungkusan (Encapsulation) dan Pengiriman Pesan (Message Passing)

Pembungkusan berarti meninggalkan aspek eksternal dari objek yang dapat

dimasuk (diakses) oleh objek lain dan memfokuskan diri pada implementasi

internal suatu objek. Keuntungan pembungkusan adalah kita dapat mengharapkan

suatu objek melakukan metoda apa yang kita inginkan tanpa harus tahu bagaimana

objek itu melakukannya. Kita ibaratkan suatu objek dengan televisi. Kita tidak

perlu tahu bagaimana televisi melakukan suatu tugas tertentu, misalnya

menayangkan gambar tertentu, yang perlu kita ketahui adalahtombol mana pada

remote control yang harus ditekan, kemudian televisi akan berfungs. Penekanan

tombol pada remote control mengirim pesan tertentu ( baca Message) pada televisi,


34

memberitahu metode apa yang akan dilakukan (pindah saluran,mengeraskan suara,

meningkatkan intensitas warna tertentu dan sebagainya).

4. Generalisasi dan Polimorfisme

Generalisasi memungkinkan kelas-kelas berbagi data serta perilaku yang sama.

Pada konteks pemrograman ini memungkinkan penguranganukuran kode dan

menyediakan kemungkinan pengembangan sistem/perangkat lunak yang lebih

mudah dipelihara. Polimorfisme mengijinkan penyesuaian berbagai kode untuk

memenuhi keadaan tertentu.

5. Penggabungan Data (Atribut) dan Perilaku (Fungsi)

6. Sharing

7. Penekanan pada struktur objek, bukan pada struktur prosedur

Teknologi berorientasi objek menekankan pada apa itu objek, bukan pada

bagaimana objek itu digunakan.

8. Sinergis

Identitas, klasifikasi, polimorfisme serta pewarisan adalah karakteristik utama dari

bahasa pemrograman berorientasi objek.

4.2. Konsep Dasar Analisis Berorientasi Objek

Gambar 4.1 Konsep dasar analisis berorientasi objek

Obyek inheritan pada

semua atributnya kelas Kelas : Mebel

Harga Dimensi Berat Lokasi Warna

Obyek : Kursi Harga Dimensi Berat

Lokasi

Warna


35

Konsep Dasar:

Object merupakan Entitas yang memiliki data yang menyatakan kondisi pada suatu

saat, dan sekumpulan operasi yang dapat mengakses dan mengubah kondisi tersebut.

Object, dapat berupa:

a. External Entities: sistem lain, alat atau orang yang memberi atau memakai

informasi yang digunakan oleh sistem

b. Things: laporan tampilan, sinyal yang merupakan bagian dan domain informasi

dari masalah.

c. Events or occurences: selesainya gerak robot.

d. Roles: manajer, staf teknik, staf pemasaran yang berperan sebagai orang

berinteraksi dengan sistem.

e. Unit organisasi: divisi, kelompok. Tim yang berhubungan dengan sistem.

4.3. Analisis Berorientasi Objek

Analisis berorientasi objek (OOA- Object Oriented Analysis) adalah tahapan perangkat

lunak dengan menentukan spesifikasi sistem dan mengidentifikasi kelas-kelas serta

hubungannya satu terhadap yang lain. Ivar Jaobson (dikutif dari buku Object Oriented

System Development tulisan Ali Bahrawi, 1999) memperkenalkan konsep use case

sebagai skenario untuk mrnjelaskan interaksi pengguna dengan sistem

Analisis berorientasi objek memiliki 5 (lima) aktivitas:

1. Finding Class & Objects

2. Identifying Structures

3. Identifying Subjects

4. Defining Attributes

5. Defining Service

Ada 5 (lima) lapisan dalam analisis berorintasi objek:

1. Subject layer

2. Class & Onject layer

3. Structure layer


36

4. Attribute layer

5. Service layer

Identifikasi struktur dalam analisis berorientasi objek

1. Generalization Specialialization. (Gen-Spec) Structure dapat dianggap sebagai

‘is a’ atau ‘is a kind of’.

2. Whole Part Struktur dapat dianggap sebagai ‘has a’

Whole Part

a) Sebuah pesawat merupakan assembly dari 0-4 mesin. Dan sebuah mesin

merupakan bagian dari 0-1 pesawat

b) Sebuah organisasi merupakan kumpulan dari 0-n staf. Dan seorang staf

merupakan bagian dari tepat 1 organisasi

Pesawat

Mesin

0-

4 0-1

Organisasi

Staf

0-n 1


37

4.3.1. Subject

a. Masalah yang besar sebaiknya dibagi-bagi dalam lingkup masalah yang lebih kecil

lagi.

b. Begitu pula dalam OO, kelas-kelas yang ada dapat di kumpulkan dalam satu

domain masalah tertentu.

c. Notasi :

4.3.2. Hubungan antar Kelas

2 jenis hubungan antar kelas

a) Intance Connection

merupakan suatu hubungan antar objek, dimana suatu objek membutuhkan objek

lain untuk memenuhi tanggung jawabnya.

b) Message Connection

memodelkan suatu ketergantungan objek. Dimana suatu objek membutuhkan

suatu service darri objek lain (biasanya dari class yang beda) untuk memenuhi

tanggung jawabnya.

4.4. Perancangan Berorientasi Objek

Ada 4 aktivitas dalam perancangan berorientasi objek yaitu

1. Designing the Problem Domain Component

2. Designing the Human Interaction Component

3. Designing the Task Management Component

4. Designing the Data MC

Ada 4 komponen dalam perancangan berorientasi objek yaitu

1. Problem Domain Component (PDC)

2. Human Interaction Component (HIC)

3. Task Management Component (TMC)

4. Data Management Component (DMC)

1. Subject 1 1

1 1

1 1


38

Managemant Component terdiri dari:

Gambar 4.2 Management component

Bahasa Pemprograman Berorientasi Objek (C++)

1. Dikembangkan oleh AT&T Bell Lab.

2. Merupakan evolusi dari bahasa C.

3. Merupakan superset dari bahasa C.

4. Dikembangkan untuk :

a) mempertahankan efisiensi dan portabilitas bahasa C

b) mempertahankan kompatibilitas dengan bahasa C.

c) menutupi kekurangan pada bahasa C.

d) mempertajam penerapan konsep information hidding.

5. DEKLARASI “CLASS”

a) Makna pernyataan STRUCT diubah menjadi CLASS

Contoh : class ostream {

public:

FILE ‘file:

int nextchar:

char buf[128]:

}

b) Kata public menyebabkan ‘file, nextchar, buf’ dapat diakses oleh semua

object dalam kelas yang sama.

c) Bila kata public tidak dinyatakan maka data ‘file, nextchar, buf’ bersifat

private.

6. MEMBER FUNCTION

7. DEKLARASI FUNGSI

8. BASE CLASS

9. DRIVED CLASSES

Subject

Class & Object

Structure

Attribute

Service


39

BAB V

PEMODELAN DATA

Metode pemodelan data menggunakan ERD (Entity Relationship Diagram). Dengan

ERD memungkinkan perekayasa perangkat lunak mengidentifikasi objek data dan

hubungannya dengan menggunakan notasi grafis. ERD hanya berfokus pada data,

dengan menunjukan “jaringan data” yang ada untuk suatu sistem yang diberikan. ERD

sangat berguna bagi aplikasi dimana data dan hubungan yang mengatur data sangatlah

kompleks.tidak seperti diagram alir data, pemodelan data melihat secara independen

dari pemprosesan yang memtransformasikan data tersebut.

1. ERD merupakan model jaringan yang menggunakan susunan data yang disimpan

dalam sistem secara abstrak

2. Diagram E-R berupa model data konseptual, yang merepresentasikan data dalam

suatu organisasi.

3. ERD menekankan pada struktur dan relationship data, berbeda dengan DFD(Data

Flow Diagram) yang merupakan model jaringan fungsi yang akan dilaksanakan

sistem

4. Biasanya digunakan oleh profesional sistem untuk berkomunikasi dengan pemakai

eksekutif tingkat tinggi dalam perusahaan yang tidak tertarik pada pelaksanaan

operasi sistem sehari-hari, namun lebih kepada :

a. Data apa saja yang diperlukan untuk bisnis mereka?

b. Bagaimana data tersebut berelasi dengan data lainnya?

c. Siapa saja yang diperbolehkan mengakses data tsb?


40

Notasi Yang digunakan pada perancangan E-R diagram

Gambar 5.1 Simbol-simbol ERD

Contoh ER diagram terlampir.

Gambar 5.2 Contoh ERD

latihan

Rancanglah diagram E-R dari kasus aplikasi database sederhanauntuk sistem informasi

akademis suatu universitas.

Dengan ketentuan sebagai berikut :

Entities yang dimuat adalah :

1. mahasiswa: menyimpan semua informasi pribadi mengenai semua mahasiswa

2. dosen: menyimpan semua informasi pribadi mengenai semua dosen

Memasok

BARANG

Mengirim

KIRIMAN Memasok

PEMASOK

Digunakan_

pada

PRODUK

Beris

i

PESANAN

Mengirim

PELANGGA

N

ENTITAS

Hubungan

Kardinalitas:

Selalu hanya satu

Satu atau banyak

Nol atau satu

Nol, satu, atau banyak

Atribut


41

3. mata_kuliah: menyimpan semua informasi mengenai semua mata kuliah yang

ditawarkan

4. ruang: menyimpan semua informasi mengenai ruang kelas yang digunakan


42

BAB VI

DASAR-DASAR PERANCANGAN PIRANTI LUNAK

6.1. Prinsip Dasar Perancangan Perangkat Lunak

Perancangan Perangkat Lunak merupakan proses penerjemahan dari kebutuhan menjadi

perangkat lunak. Hasil dari perancangan adalah :

1. Rancangan data yang memetakan model domain informasi pada saat analisis

menjadi struktur data yang dibutuhkan untuk implementasi perangkat lunak.

2. Rancangan arsitektural yang mendefinisikan hubungan dari komponen-komponen

struktural utama dari program.

3. Rancangan prosedural yang memetakan komponen-komponen struktural ke

deskripsi prosedur perangkat lunak

ABSTRACTION ( Wasserman )

1. Pada rancangan secara modular, beberapa tingkatan abstraksi dapat diperoleh,

sehingga perancang dapat mengkonsen- trasikan pada setiap tingkatan abstraksi

yang lebih terinci.

2. Pada level paling tinggi, solusi dinyatakan secara global dengan bahasa pada

lingkungan masalah. Dan pada abstraksi paling bawah, solusi dinyatakan dalam

bahasa yang dapat langsung diimplementasikan.

Contoh Abstraksi Program dan Abstraksi Data :

PROGRAM ABSTRACTION

Abstraksi tingkat pertama :

CAD Software Task

User interface Task

2-D Drawing Creation Task

………

end.

Abstraksi tingkat kedua :

PROCEDURE User interface

………

……

End

DATA ABSTACTION

TYPE drawing IS STRUCTURE

DEFINED

Number IS INTEGER

Icon IS ICON_STRUCTURE

Notes IS STRING LENGTH (225)

Versi IS STRING LENGTH ( 10 )

……………

end


43

MODULARITY & SOFTWARE ARCHITECTURE

1. Perangkat lunak dibagi atas beberapa modul.

2. Sebuah modul dapat dibagi lagi atas beberapa sub-modul

3. Modul memiliki nama yang unik.

4. Sebuah modul dapat memanggil modul lainya.

Gambar 6.1 Struktur Evolusi

Gambar 6.2 Struktur Berbeda

S1 S2

S4

S3

S5

Software “solution” “Problem” to be solved via software

P S

5S

4S

1

S3

S2

S4

S1

S3

S5

S2

S4

S2

S3

S5

S1

“Problem”

Structure 1 Structure 2 Structure 3


44

Gambar 6.3 Struktur Terminologi

HIRARKI KONTROL ( STRUKTUR PROGRAM )

1. Menunjukkan organisasi dari modul-modul program dan menunjukan hirarki

kontrolnya. Tidak merepresentasikan aspek prosedural dari perangkat lunak seperti

urutan proses, keputusan, atau perulangan.

2. Kedalaman dan lebar menunjukkan jumlah tingkatan kontrol dan seluruh cakupan

kontrol

3. Fan-out menunjukkan jumlah modul yang secara langsung dikontrol oleh modul

lain

4. Fan-in menunjukkan jumlah modul yang mengontrol modul yang bersangkutan

5. Modul yang mengontrol modul yang lain disebut superordinate

6. Modul yang dikontrol modul yang lain disebut subordinate

FAN-OUT

1. Fan-out dari sebuah modul adalah banyaknya subordinate langsung dari modul

tersebut

2. Perluasan kontrol dari sebuah modul sebaiknya tidak melebihi 7 + 2 ( kecuali pada

pusat-pusat transaksi )

3. Hindarkan Fan-out yang bersifat main-line (satu boss, dengan modul-modul lain

sebagai subordinate )

Depth

Width

Fan-out

Fan-in

M

b c a

k d e l m

g f h o n p q

i j r


45

4. Sebuah modul dengan Fan-out yang banyak biasanya sukar dipelihara.

5. Untuk memecahkan fan-out yang banyak gunakan modul-modul antara

FAN-IN

1. Fan-in dari modul adalah banyaknya modul lain yang ( boss )

menggunakan/memanggil modul tersebut.

2. Jika mungkin Fan-in harus dilakukan sebanyak-banyaknya.

3. Fan-in yang banyak menghindari pengulangan pembuatan modul yang sama atau

serupa

4. Fan-in yang banyak mempermudah pemeliharaan karena menempatkan suatu fungsi

yang sama dalam satu modul

STRUKTUR DATA

Refresentasi lojikal dari hubungan antara elemen-elemen data.

Gambar 6.4 Struktur Data Klasik

A linked list

A scalar item

A scalar item

…

An N-dimensional space

…

…

A hierarchical tree


46

PROSEDUR PERANGKAT LUNAK

Struktur program hanya mendefinisikan hirarki kontrol tanpa memperhatikan urutan

proses. Prosedur perangkat lunak berfokus pada rincian proses dari setiap modul.

INFORMATION HIDING ( by Pamas )

Prinsip dasar dalam pembentukan modul dimana hanya data yang benar-benar perlu,

yang dikenalkan dan dapat diakses oleh sebuah modul.

Gambar 6.5 Prosedur Berlapis

Module

A

Module

A

Prosedur di dalam

suatu modul


47

6.2. PERANCANGAN YANG MODULAR

1. Keuntungan :

a) menurunkan kompleksitas

b) mempermudah pengubahan

c) implementasi yang lebih mudah karena bagian-bagian yang berbeda dapat dibuat

dengan paralel

2. Evaluasi dari hubungan antar modul dapat dinilai dengan melihat kohesi dan

koplingnya ( Steven, Myers, dan Constantine )

KOPLING

1. Kopling adalah tingkat saling ketergantungan antara dua modul.

2. Kita menghendaki modul dengan kopling rendah yaitu modul-modul yang sedapat

mungkin tidak saling bergantungan.

3. Kopling yang rendah adalah tanda dari pembagian sistem yang baik, dimana

sesuatu yang tidak berhubungan dipisahkan.

4. Jika sedikit atau tidak ada interaksi dua modul disebut loosely coupled (kopling

rendah) dan jika sebaliknya disebut tighty coupled (kopling tinggi)

5. Makin tinggi kopling yang ada makin sulit sebuah program untuk dimengerti.

6. Jika dua modul memiliki kopling yang rendah, maka sebuah modul dapat diubah

tanpa perlu mengubah modul yang lain.

7. Mengapa kopling yang rendah diperlukan ?

Untuk menghilangkan ripple effect (perubahan pada sebuah modul dapat

berpengaruh pada modul lain). Sehingga dapat memelihara atau mengubah suatu

modul dengan resiko yang minimal untuk mengubah modul lainnya. Jika mungkin

kita ingin dapat bekerja dengan modul A tanpa perlu mengetahui tentang apapun

dalam modul B.

8. Faktor-faktor yang berpengaruh pada kopling antara dua modul adalah :

a) Jumlah item data yang disalurkan diantara dua modul (makin banyak data yg

disalurkan makin tinggi kopling yang terjadi).

b) Jumlah data kontrol yang disalurkan diantara dua modul (makin banyak data

kontrol yang disalurkan makin tinggi kopling yang terjadi)


48

X

X

Y

Y

Lalu lintas jalan

Kopling rendah Kohesi tinggi

Y

X

X

Y

Lalu lintas jalan

Kopling tinggi Kohesi rendah

c) Jumlah elemen data global yang digunakan bersama-sama oleh beberapa modul

(makin banyak data global yang digunakan, makin tinggi kopling yang terjadi)

KOHESI

1. Melekatkan hal-hal yang berkaitan didalam modul yang sama, akan mengurangi

lalu-lintas diantara modul-modul .

2. Apa yang terjadi diantara modul-modul (kopling) dipengaruhi oleh apa yang terjadi

dalam modul-modul tersebut secara individual (kohesi)

3. Kohesi adalah ukuran kekuatan asosiasi antar elemen didalam suatu modul.

4. Elemen yang dimaksud adalah : sebuah instruksi, sekumpulan intruksi, atau

pemanggilan ke modul lain.

5. Kohesi tinggi jika sebuah modul hanya bertanggung jawab terhadap satu pekerjaan

saja.

Gambar 6.6 Kohesi

6.3. RANCANGAN DATA

1. Rancangan data yang bagus dapat membuat struktur program lebih baik,

modularitas efektif dan menurunkan kompleksitas prosedural

2. Beberapa petunjuk :

a) Semua struktur data dan operasi yang mengolahnya harus didefinisikasi

b) Selalu gunakan kamus data


49

c) Rancanagan data yang bersifat low-level harus ditunda sampai akhir dari

proses perancangan

d) Bentuk keputusan dan struktur data dan operasi-operasi yang mengolahnya

e) Bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe data

abstrak.

6.4. PERANCANGAN ARSITEKTURAL

Tujuan dari perancangan arsitektural adalah untuk membangun struktur program yang

modular dan membentuk hubungan kontrol antar modul. Rancangan arsitektural

menggabungkan struktur program dan struktur data serta mendefinisikan interface yang

membuat data melalui program. Dan dinyatakan dalam bentuk Bagan Susunan atau

diagram Wamier/Orr.

BAGAN SUSUNAN (Structured Chart)

1. Bagan susunan merupakan susunan hirarki dari modul-modul

2. Bagan susunan menunjukkan

a) pembagian sistem menjadi modul-modul

b) hirarki dan organisasi modul-modul

c) komunikasi antar modul ( masukan dan keluaran )

d) nama modul, yang berarti juga fungsi modul.

3. Bagan Susunan tidak menunjukkan :

a) Mekanik didalam modul ( seperti ukuran pemanggilan modul lain, loops dsb )

b) Data internal dari modul

Simbol-simbol yang digunakan :

Gambar 6.7 Simbol-simbol bagan terstruktur

: hubungan 2

: pengulangan 3

: Seleksi / pemilihan 4

: Kopel Kontrol 5

: Kopel Data 6

: Nama Modul / Proses 1


50

Contoh :

Menunjukkan suatu model dengan nama “Hitung Potongan”.

Modul A memanggil modul B. Setelah proses dari modul B selesai, maka proses

kembali ke modul A yang memanggilnya.

Modul A memanggil modul B dan elemen data P dikirimkan dari modul A ke modul B.

Hasil proses dari modul B mengirimkan elemen data Q dan elemen kontrol Flag ke

modul A.


51

Modul A memanggil modul B bila kondisi yang diseleksi di modul terpenuhi. Modul A

juga memanggil modul C berulang kali yang ditunjukkan oleh simbol perulangan.

Model Bagan Terstruktur

Terdapat dua model dari bagan terstruktur, yaitu transformed-centered dan transaction

centered. Bagan terstruktur dapat berbentuk model transformed-centered saja atau

transaction centered saja atau kombinasi dari keduanya. Model yang digunakan ini

tergantung dari diagram arus data yang telah dibuat, karena bagan terstruktur

digambarkan berdasarkan diagram arus data (DAD).

a. Transformed-centered

Bagan terstruktur dengan model transformed-centered menggambarkan sistem

dalam 3 cabang utama, yaitu sebagai berikut :

1. Cabang input (input branch) atau disebut juga dengan affrerent branch,

merupakan cabang yang menerima input dan membentuk input kedalam suatu

status yang siap untuk diproses.

2. Cabang proses (process branch) atau disebut juga dengan cabang transformasi

(transform branch) atau disebut juga dengan central transform, merupakan

cabang yang akan melakukan fungsi utama dari sistem, yaitu memperoses

input yang dikirim dari cabang input.

3. Cabang output (output branch) atau disebut juga dengan efferent branch,

merupakan cabang yang akan memformat data menjadi output.


52

Gambar 6.8 Model dasar bagan terstruktur transformed-centered

b. Transaction-centered

Seringkali diagram arus data menggambarkan suatu sistem yang menangani

beberapa tipe transaksi yang mempunyai jalur yang berbeda. Diagram tersebut

mungkin akan sulit dipilah-pilah berdasarkan transformasinya. Untuk diagram alur

data tersebut, dapat dibuat bagan terstruktur model transaction-centered.


53

Gambar 6.9 Model bagan terstruktur jenjang dari transaction-centered

Contoh :


54

TABEL KEPUTUSAN

Tabel keputusan (decision table) adalah tabel yang digunakan sebagai alat bantu untuk

menyelesaikan logika dalam program

Condition Stub

◦ Bagian ini berisi kondisi yang akan diseleksi.

Condition Entry

◦ Bagian ini berisi kemungkinan dari kondisi yang diseleksi, yaitu

terpenuhi (diberi simbol ‘Y’) dan tidak terpenuhi (diberi simbol ‘N’).

◦ Bila ada kondisi X diseleksi, terdapat N Kemungkinan terjadi N = 2X

Action Stub

◦ Action stub berisi pernyataan-pernyataan yang akan dikerjakan baik

kondisi yang diselesi terpenuhi maupun tidak terpenuhi.

Action Entry

◦ Action entry digunakan untuk memberi tanda tindakan mana yang akan

dilakukan dan mana yang tidak akan dilakukan


55

DIAGRAM KEPUTUSAN

Merupakan model dari sebuah fungsi diskrit dimana nilai dari sebuah variabel

ditentukan; berdasarkan nilai ini beberapa tindakan dilakukan


56

BAHASA TERSUSUN

Konteks Logik :

BIT/SE merupakan jembatan antara analisis perancangan dan pengkodean

BIT/SE adalah bahasa spesifikasi yang menggunakan perbendaraan kata dan

sintaks yang terbatas

Perbendaharaan katanya hanya terdiri dari :

◦ Kata kerja perintah/Imperative language verb.

◦ Istilah yang didefinisikan dalam Kamus Data.

◦ Reserved Word tertentu untuk formulasi logik.

Contoh :

JIKA MASA-KERJA LEBIH DARI 15 TAHUN

MAKA

BONUS = 100.000

SELAIN ITU

BONUS = 50.000

AKHIR JIKA


57

DIAGRAM ALIR/FLOWCHART

BOX DIAGRAM/N-S CHART


58

Contoh :


59

6.5. RANCANGAN PROSEDURAL

Rancangan prosedural dilakukan setelah struktur program dan data telah dibentuk.

Beberapa bentuk pernyataan :

1. pemrograman terstruktur

2. notasi grafis : flowchart, box diagram/N-S charts

3. bentuk tabel

4. PDL

KARAKTERISTIK NOTASI PERANCANGAN

1. Mendukung modularistas

2. Sederhana

3. Mudah diubah

4. Dapat dibaca oleh mesin

5. Dapat dipelihara

6. Structured enforcerment

7. Code-to-ability

8. Dapat diverifikasi

Beberapa Pedoman

1. Pemakai sistem harus selalu mengetahui apa yang mesti dilakukan berikutnya

a) beritahu pemakai apa yang diharapkan oleh sistem sekarang Contoh : SIAP,

MASUKKAN PERINTAH, MASUKKAN PILIHAN atau MASUKKAN

DATA.

b) Beritahu pemakai bahwa data telah dimasukkan dengan benar, Bisa berupa

perpindahan kursor ke data berikutnya atau pesan : MASUKKAN VALID

c) Beritahu pemakai bahwa pemasukkan data salah. Pemberitahuan format yang

benar lebih baik.

2. Bentuk pemakaian alasan adanya delay dalam pemrosesan.

Contoh : SORTING, PLEASE STAND BY, INDEXING, PLEASE WAIT, THIS

MAY TAKE A FEW MINUTES, TUNGGU SEBENTAR, Adanya pesan membuat

pemakai mengetahui bahwa sistem tidak gagal.


60

3. Beritahu pemakai sebuah pekerjaan selesai atau tidak selesai dilakukan Contoh :

PRINTING, COMPLETE, PRINTER NOT READY – PLEASE CHECK AND

TRY AGAIN.

Rancangan Layar :

1. Layar sebaiknya diatur agar beberapa tipe informasi, intruksi dan pesan selalu

muncul di area yang konsisten. Ini akan membantu pemakai mencari informasi

yang spesifik

2. Perancangan layar yang terlalu “ norak “

3. Berikan kesempatan pemakai menghemat pengetikan dengan function keys

4. Jika memungkinkan, berikan harga baku

5. Antisipasi kesalahan yang mungkin dibuat oleh pemakai.

a. Contoh : YAKIN DIHAPUS ?

6. Selalu Konsisten

7. Kurang jumlah informasi yang harus diingat diantaranya aksi

Penulisan Program

1. Cobalah untuk langsung menggunakan keistimewaan yang ada pada bahasa

pemrograman

2. Cobalah untuk menggunakan library dan fungsi-fungsi yang telah ada pada bahasa

pemrograman

3. Jangan mengabaikan pesan-pesan peringatan ( warning message )

Beberapa pedoman Bahasa

1. Sederhana, dan benar secara aturan bahasa.

o Bahasa percakapan lebih baik daripada bahasa tulisan

2. Jangan berusaha melucu atau “ sok imut “.

o jika penggunaan harus memakainya 25x seharai. Akan tidak lucu lagi.

3. Jangan menyinggung intelegensia pemakai


61

Penulisan Pemrograman

1. Jumlah perintah dalam suatu subprogram sebaiknya 5 – 100 perintah

2. Jumlah paremeter yang di-pass sebaiknya <= 5

3. Hindari penggunaan GO TO

4. Gunakan identitasi

5. Kedalaman pernyataan bersarang sebaiknya < 5. Pengecualian untuk penggunaan

fungsi rekursif.

6. Kemampuan program untuk dibaca lebih penting dari pada efesiensi program

7. Gunakan nama-nama yang punya arti

Komentar

1. Berilah komentar pada program anda.

2. Hindari komentar yang terlalu panjang

3. Komentar merupakan jawaban dari pertanyaan pembaca program

4. Berilah komentar setiap variabel

5. Komentar bukan terjemahan dari program anda.

Perbaikan Program

1. Lupakan semua tentang efisiensi sampai program anda dapat bekerja dengan benar.

2. Jangan mencoba untuk memperbaiki sampai anda mengerti benar programnya

3. Jangan mengorbankan kemampuan untuk dibaca demi efisiensi

Pemilihan Bahasa

1. Jika dibutuhkan struktur data yang kompleks : PASCAL, C

2. Jika kinerja, kemampuan real-time : ADA

3. Jika perlu efisiensi memori :C

4. Banyak report & banyak manipulasi berkas : COBOL, 4GL, RPG

5. Akan lebih mudah jika hanya satu bahasa tersedia atau sudah ditemukan oleh

pemakai. Pada banyak kasus mengikuti sistem yang sudah ada

6. Beberapa de-facto :

a) C untuk sistem software

b) Ada, C, Modula-2 untuk aplikasi real-time


62

c) COBOL, 4GL untuk aplikasi bisnis

d) FORTRAN untuk aplikasi sains dan teknik

e) PASCAL, C untuk program-program aplikasi di PC

f) LISP, PROLOG untuk kecerdasan buatan


63

BAB VII

PENGANTAR UML (Unified Modeling Language)

7.1. Definisi UML

Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar

dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti

lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi

piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi

dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena

UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih

cocok untuk penulisan piranti lunak dalam bahasa berorientasi objek seperti C++, Java,

C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling

aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML

mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan

bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk

memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk

tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang

telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh

OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented

Software Engineering). Sejarah UML sendiri cukup panjang. Sampai era tahun 1990

seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah

bermunculan di dunia. Diantaranya adalah: metodologi booch [1], metodologi coad [2],

metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi

wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi (method war)

dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi

sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama

dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan

tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha

untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease

draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut


64

dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org).

Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang

dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial

tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma

menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

7.2. Konsep Dasar UML

Gambar 7.1 Konsep Dasar UML

Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic

behavior, dan model management, bisa kita pahami dengan mudah apabila kita melihat

gambar diatas dari Diagrams. Main concepts bisa kita pandang sebagai term yang akan

muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram

tersebut. Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal

yang harus kita perhatikan:

1. Menguasai pembuatan diagram UML

2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML

Tulisan ini pada intinya akan mengupas kedua hal tersebut. Seperti juga tercantum pada

gambar diatas UML mendefinisikan diagram-diagram sebagai berikut:

a) use case diagram

b) class diagram


65

c) statechart diagram

d) activity diagram

e) sequence diagram

f) collaboration diagram

g) component diagram

h) deployment diagram

7.2.1. Use Case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem.

Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah

use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case

merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah

daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia

atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan

tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun

requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan

merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat

meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.

Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali

use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include

oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari

dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat

meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan

generalisasi antar use case menunjukkan bahwa use case yang satu merupakan

spesialisasi dari yang lain. Contoh use case diagram:


66

Gambar 7.2 Contoh Use Case

7.2.2. Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek

dan merupakan inti dari pengembangan dan desain berorientasi objek. Class

menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan

untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan

struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti

containment, pewarisan, asosiasi, dan lain-lain. Contoh class diagram:

Gambar 7.3 Contoh Class Diagram


67

7.2.3. Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang

dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan

bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel

yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state

diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi

di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu

activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi

antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur

aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use

case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case

menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.

Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat

untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour

pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join)

digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan

objek mana yang bertanggung jawab untuk aktivitas tertentu. Contoh activity diagram

tanpa swimlane:

Gambar 7.3 Contoh Activity Diagram


68

7.2.4. Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem

(termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan

terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi

horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk

menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai

respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang

men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara

internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor,

memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek

ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi

operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah

proses, biasanya diawali dengan diterimanya sebuah message. Untuk objek-objek yang

memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary,

controller dan persistent entity. Contoh sequence diagram:

Gambar 7.4 Contoh Sequence Diagram


69

7.2.5. Tool Yang Mendukung UML

Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial

maupun opensource. Beberapa diantaranya adalah:

1) Rational Rose (www.rational.com)

2) Together (www.togethersoft.com)

3) Object Domain (www.objectdomain.com)

4) Jvision (www.object-insight.com)

5) Objecteering (www.objecteering.com)

6) MagicDraw (www.nomagic.com/magicdrawuml)

7) Visual Object Modeller (www.visualobject.com)

http://www.visualobject.com/


70

BAB VIII

PENGUJIAN PERANGKAT LUNAK

Saat ini sudah banyak berkembang berbagai metode untuk pengujian perangkat lunak.

Metode-metode tersebut memberikan pendekatan yang sistematik untuk pengujian

perangkat lunak kepada pengembang. Selain itu, metode-metode tersebut memberikan

mekanisme yang dapat membantu memastikan kelengkapan pengujian dan memberikan

kemungkinan tertinggi untuk mengungkap kesalahan pada perangkat lunak.

Semua produk yang direkayasa dapat diuji dengan satu atau dua cara, yaitu:

1) Dengan mengetahui fungsi yang ditentukan untuk dilakukan oleh suatu produk,

pengujian dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi

beroperasi sepenuhnya dan pada waktu yang sama mencari kesalahan pada setiap

fungsi

2) Dengan mengetahui kerja internal suatu produk, maka pengujian dapat dilakukan

untuk memastikan bahwa seluruh operasi internal bekerja sesuai spesifikasi dan

semua komponen internal telah diamati dengan memadai

Pendekatan pengujian pertama disebut sebagai pengujian black-box dan pengujian

kedua disebut sebagai pengujian white-box. Pengujian black-box berkaitan dengan

pengujian yang dilakukan pada antarmuka perangkat lunak. Meskipun dirancang untuk

mengungkap kesalahan, pengujian black-box digunakan untuk memperlihatkan bahwa

fungsi-fungsi perangkat lunak dapat beroperasi, bahwa input diterima dengan baik dan

output dihasilkan dengan tepat, dan integritas informasi eksternal (seperti file data)

dipelihara. Pengujian black-box menguji beberapa aspek dasar suatu sistem dengan

memperhatikan sedikit struktur logika internal perangkat lunak tersebut.

Pengujian white-box didasarkan pada pengamatan yang teliti terhadap detail prosedural.

Jalur-jalur logika yang melewati perangkat lunak diuji dengan memberikan kasus uji

yang menguji serangkaian kondisi dan atau loop tertentu. Status program tersebut dapat

diuji pada berbagai titik untuk menentukan apakah status yang diharapkan sesuai

dengan status yang sebenarnya.

Sekilas terlihat bahwa pengujian white-box yang sangat teliti akan membawa kepada

program yang benar 100%. Yang diperlukan adalah menentukan semua jalur logika,

mengembangkan kasus uji untuk mengujinya, dan mengevaluasi hasil, yaitu


71

memunculkan kasus uji untuk menguji logika program secara mendalam. Namun sesuai

dengan prinsip pengujian, pengujian secara mendalam akan menimbulkan masalah

logistik. Bahkan untuk program yang kecil, dapat dibangkitkan jumlah jalur logika yang

besar.

Tetapi pengujian white-box tidak boleh dianggap tidak praktis. Sejumlah jalur logika

yang penting dapat dipilih dan digunakan. Struktur-struktur data yang penting dapat

diperiksa validitasnya. Atribut pengujian black-box dan white-box dapat digabungkan

untuk memberikan pendekatan yang memvalidasi antarmuka perangkat lunak, dan

secara selektif menjamin bahwa kerja internal perangkat lunak itu benar.

8.1. White-Box Testing

White-box testing (kadang-kadang disebut sebagai glass-box testing) adalah metode

desain kasus uji yang menggunakan struktur kontrol desain prosedural untuk

memperoleh kasus uji. Dengan menggunakan metode pengujian white-box, perekayasa

sistem dapat melakukan kasus uji yang:

1) Memberikan jaminan bahwa semua jalur independen pada suatu modul telah

digunakan paling tidak satu kali

2) Menggunakan semua keputusan logis pada sisi true dan false

3) Mengeksekusi semua loop pada batasan mereka dan pada batas operasional

mereka

4) Menggunakan struktur data internal untuk menjamin validitasnya

Muncul pertanyaan tentang mengapa menghabiskan waktu dan sumber daya untuk

menguji logika jika dapat memastikan bahwa persyaratan program telah dapat dipenuhi

dengan lebih baik. Jawaban dari pertanyaan ini ada pada sifat cacat perangkat lunak

seperti:

a) Kesalahan logis dan asumsi yang tidak benar berbanding terbalik dengan

probabilitas jalur program yang akan dieksekusi. Kesalahan cenderung

muncul pada saat perancangan dan implementasi fungsi, kondisi, atau kontrol

yang berada di luar mainstream

b) Kepercayaan bahwa jalur logika mungkin tidak akan dieksekusi bila pada

kenyataannya mungkin dieksekusi pada basis reguler. Aliran logika dari

program kadang bersifat konterintuitif, artinya asumsi yang tidak disadari


72

mengenai aliran dan data kontrol dapat menyebabkan kesalahan perancangan

yang akan terungkap setelah pengujian jalur dimulai

c) Kesalahan tipografi sifatnya acak. Bila sebuah program diterjemahkan ke

dalam source code bahasa pemrograman, maka dimungkinkan akan terjadi

banyak kesalahan pengetikan. Beberapa kesalahan dapat ditemukan melalui

mekanisme pengecekan sintaks, namun yang lainnya tidak akan terdeteksi

sampai dilakukan pengujian

Sifat cacat tersebut sangat mungkin ditemukan dengan menggunakan pengujian white-

box sedangkan pengujian black-box tidak dapat menemukannya seberapa cermat pun

pengujian black-box dilakukan. Alasan inilah yang mendasari mengapa pengujian

white-box dilakukan.

Jenis pengujian White-Box testing antara lain:

1. Basis path testing

2. Control Structure Testing, yang terdiri dari:

- Condition Testing

- Data Flow Testing

- Loop Testing

UJI COBA BASIS PATH

Uji coba basis path adalah teknik uji coba white box yg diusulkan Tom McCabe.

Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan

logical dari perancangan prosedural dan menggunakan ukuran ini sbg petunjuk untuk

mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat digunakan untuk

mengerjakan basis set yang menjamin pengerjaan setiap perintah minimal satu kali

selama uji coba.

a) Notasi diagram alir

Gambar 8.1 Notasi diagram alir


73

Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan

prosedural dalam bentuk flowchart.

Gambar 8.2 Diagram alir flowchart

Selanjutnya diagram alir diatas dipetakan ke grafik alir

Gambar 8.3 Diagram grafik alir


74

Lingkaran/node :

Menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat

dipetakan dalam satu node.

Tanda panah/edge :

Menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan node

Region :

Adalah daerah yg dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.

Contoh menterjemahkan pseudocode ke grafik alir

1: do while record masih ada baca record

2: if record ke 1 = 0 3: then proses record

simpan di buffer naikan kounter

4: else if record ke 2 = 0 5 then reser kounter 6 proses record

simpan pada file 7a: endif

endif 7b: enddo 8 : end

Nomor pada pseudocode berhubungan dengan nomor node. Apabila diketemukan

kondisi majemuk (compound condition) pada pseudcode pembuatan grafik alir menjadi


75

rumit. Kondisi majemuk mungkin terjadi pada operator Boolean (AND, OR, NAND,

NOR) yg dipakai pada perintah if.

Contoh :

if A or B

then procedure x

else procedure y

endif

Node dibuat terpisah untuk masing-masing kondisi A dan B dari pernyataan IF A OR B.

Masing-masing node berisi kondisi yg disebut predicate node dan mempunyai

karakteristik dua atau lebih edge darinya.

b) Cyclomatic Complexity

Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari

kekompleksan logikal program. Apabila digunakan dalam kontek metode uji coba basis

path, nilai yang dihitung untuk cyclomatic complexity menentukan jumlah jalur

independen dalam basis set suatu program dan memberi batas atas untuk jumlah uji

coba yang harus dikerjakan untuk menjamin bahwa seluruh perintah sekurang-

kurangnya telah dikerjakan sekali.

Jalur independent adalah jalur yang melintasi atau melalui program dimana sekurang-

kurangnya terdapat proses perintah yang baru atau kondisi yang baru.

Dari gambar 8.3 :

Path 1 : 1 - 11

Path 2 : 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11

Path 3 : 1 - 2 - 3 - 6 - 8 - 9 ...: 10 - 1 - 11


76

Path 4 ': 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11

Path 1,2,3,4 yang telah didefinisikan di atas merupakan basis set untuk diagram alir.

Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu flowgraph.

Dapat dipergunakan rumusan sbb :

1. Jumlah region grafik alir sesuai dengan cyclomatic complexity.

2. Cyclomatix complexity V(G) untuk grafik alir dihitung dengan rumus:

V(G) = E - N + 2

dimana:

E = jumlah edge pada grafik alir

N = jumlah node pada grafik alir

3. Cyclomatix complexity V(G) juga dapat dihitung dengan rumus:

V(G) = P + 1

dimana P = jumlah predicate node pada grafik alir

Pada Gambar 8.3 dapat dihitung cyclomatic complexity:

1. Flowgraph mempunyai 4 region

2. V(G) = 11 edge - 9 node + 2 = 4

3. V(G) = 3 predicate node + 1 = 4

Jadi cyclomatic complexity untuk flowgraph Gambar 8.3 adalah 4

c) Melakukan Test Case

Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci

atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis

path. Prosedur rata-rata pada bagian berikut akan digunakan sebagai contoh dalam

pembuatan test case.

PROCEDURE RATA-RATA

INTERFACE RESULT rata, total, input, total.valid

INTERFACE RESULT nilai, minim, max

TYPE NILAl (1:100) IS SCALAR ARRAY;

TYPE rata, total. input, total.valid, max.minim, jumlah IS SCALAR;

TYPE I IS INTEGER;

I = 1;

total. input = total. valid = 0;


77

jumlah = 0;

DO WHILE nilai(i) <> -999 .and. total.input < 100

tambahkan total.input dengan 1;

IF nilai(i) >= minimum .and. nilai(i} <=max;

THEN tambahkan total.valid dengan I;

jumlah=jumlah + nilai(i);

ELSE skip;

END IF

tambahkan i dengan 1;

ENDDO

IF total. valid> 0

THEN rata =jumlah/total. valid;

ELSE rata = -999;

ENDIF

END

Langkah-Iangkah pembuatan test case:

1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai

dasar, digambarkan diagram alirnya.

Gambar 8.4 Diagram grafik alir prosedure rata-rata

2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat:

V (G) = 6 region .

V(G) = 17 edge - 13 node + 2 = 6


78

V(G) = 5 predicate node + 1 = 6

3. Tentukan independent path pada flowgraph

Dari hasil perhitungan cyclomatic complexity terdapat 6 independent path yaitu:

path 1 : 1-2-10-11-13

path 2 : 1-2-10-12-13

path 3 : 1-2-3-10-11-13

path 4 : 1-2-3-4-5-8-9-2-..

path 5 : 1-2-3-4-5-6-8-9-2-..

path 6 : 1-2-3-4-5-6-7-8-9-2-...

4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data

yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan

semua.

d) Graph Metrik

Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba basis

path atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai

ukuran (sejumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph.

Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah

ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge)

antarnode.

Contoh sederhana pemakaian graph matrik dapat digambarkan sbb :

Gambar 8.5 Graph Metrik


79

Pada gambar flowgraph masing-masing node ditandai dengan angka clan edge dengan

huruf kecil, kemudian diterjemahkan ke graph matrik. Contoh hubungan node 3 dengan

node 4 pada graph ditandai dengan huruf b.

Hubungan bobot menyediakan tambahan informasi tentang aliran kontrol. Secara

simpel hubungan bobot dapat diberi nilai 1 jika ada hubungan antara node atau nilai 0

jika tidak ada hubungan. Dapat juga hubungan bobot diberi tanda dengan:

kemungkinan link (edge) dikerjakan

waktu yang digunakan untuk proses selama traversal dari link

memori yang diperlukan selama traversal link

sumber daya yang diperlukan selama traversal link

Gambar 8.6 Hubungan bobot

Koneksi :

1 – 1 = 0

2 – 1 = 1

2 – 1 = 1

2 – 1 = 1

3 + 1 = 4 cyclomatic complexity

PENGUJIAN LOOP

Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan

tepat. Uji coba loop merupakan teknik pengujian white box yg fokusnya pada validitas

dari loop. Kelas loop yaitu :


80

a. Loop Sederhana, pengujian loop sederhana dilakukan dgn mudah, dimana n

jumlah maksimum yg diijinkan melewati loop tsb.

1. Lewati loop secara keseluruhan

2. Hanya satu yg dapat melewati loop

3. m dapat melewati loop dimana m< n

b. Loop Tersarang, pengujian loop ini menggunakan pendekatan loop sederhana.

Petunjuk pengujian loop tersarang :

1. Dimulai dari loop paling dalam. Atur semua loop ke nilai minimum.

2. Kerjakan dgn prinsip loop sederhana untuk loop yg paling dalam sementara

tahan loop yang di luar pada parameter terkecil (nilai kounter terkecil)

3. Kemudian lanjutkan untuk loop yg diatasnya.

4. Teruskan sampai semua loop selesai di uji.

c. Loop Terangkai, pengujian loop ini menggunakan pendekatan loop sederhana bila

masing-masing loop independen, tetapi bila dua loop dirangkai dan pencacah loop 1

digunakan sebagai harga awal loop 2 maka loop tersebut jadi tidak independen,

maka pendekatan yg diaplikasikan ke loop tersarang direkomendasikan.

d. Loop Tidak Terstruktur, Kapan saja memungkinkan, loop ini didisain kembali

agar mencerminkan penggunaan komsepsi pemrograman terstruktur.

Gambar 8.7 Macam-macam loop


81

8.2. Black-Box Testing

Pengujian ini fokus kepada persyaratan fungsional perangkat lunak. Pengujian ini

memungkinkan pelaku RPL mendapatkan serangkaian kondisi input yang memenuhi

persyaratan fungsional suatu program.

Pengujian ini berusaha menemukan kesalahan dengan kategori sebagai berikut:

1. Fungsi-fungsi yang salah atau hilang

2. Kesalahan antarmuka

3. Kesalahan struktur data atau akses basisdata eksternal

4. Kesalahan kinerja

5. Kesalahan inisialisasi atau terminasi

Pengujian ini cenderung untuk dilakukan pada tahap akhir pengujian berbeda dengan

white-box testing. Penguji dituntut untuk menjawab pertanyaan-pertanyaan berikut:

a) Bagaimana validitas fungsional diuji?

b) Kelas input apa yang akan membuat kasus uji menjadi baik?

c) Apakah sistem sangat sensitif terhadap nilai input tertentu?

d) Bagaimana batasan suatu data diisolasi?

e) Berapa kecepatan dan volume data yang dapat ditolerir sistem?

f) Apa pengaruh kombinasi tertentu dari data terhadap operasi sistem?

Dengan mengaplikasikan teknik pengujian ini, penguji membuat serangkaian kasus uji

yang:

a) Mengurangi jumlah kasus uji tambahan yang harus dirancang untuk mencapai

pengujian yang benar

b) Memberi tahu mengenai ada atau tidaknya kesalahan

Contoh pengujian Black-Box testing antara lain:

a) Graph Based Testing Method

b) Equivalence Partitioning

c) Boundary Value Analysis

d) Comparison Testing

e) Orthogonal Array Testing


82

8.3. Strategi Pengujian Perangkat Lunak

Proses pengujian perangkat lunak dapat digambarkan sebagai berikut:

Gambar 8.8 Strategi Pengujian Perangkat Lunak

Spiral di atas menggambarkan bagaimana rekayasa sistem membangun sebuah

perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak, kemudian (spiral

bergerak ke dalam) proses dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke

pengkodean (di pusat spiral). Strategi pengujian serupa dengan hal tersebut, namun

bergerak dimulai dari pusat menuju keluar spiral. Dimulai dengan unit testing di pusat

spiral di mana masing-masing modul/unit dari perangkat lunak yang

diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian bergerak

keluar spiral, dilakukan integration testing dengan fokus pengujian adalah desain dan

konstruksi arsitektur perangkat lunak. Bergerak lagi keluar, dilakukan validation testing

dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang

telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada system

testing, di mana perangkat lunak dan keseluruhan elemen sistem diuji.

PENGUJIAN UNIT

Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain

PL, yakni modul. Uji coba unit selalu berorientasi pada white box testing dan dapat

dikerjakan paralel ayau beruntun dengan modul lainnya.

a. Pertimbangan Pengujian Unit

Interface diuji cobakan untuk menjamin informasi yg masuk atau yg ke luar dari

unit program telah tepat atau sesuai dgn yg diharapkan. Pertama diuji coba adalah

interface karena diperlukan untuk jalannya informasi atau data antar modul. Myers

mengusulkan checklist untuk pengujian interface:


83

Apakahjumlah parameter input sama dengan jumlah argumen?

Apakah antara atribut dan parameter argumen sudah cocok?

Apakah antara sistem satuan parameter dan argumen sudah cocok?

Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama

dengan jumlah parameter?

Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama

dengan atribut parameter?

Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil

sama dengan sistem satuan parameter?

Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in sudah

benar?

Adakah referensi ke parameter yang tidak sesuai dengan pain entri yang ada?

Apakah argumen input-only diubah?

Apakah definisi variabel global konsisten dengan modul?

Apakah batasan yang dilalui merupakan argumen?

Bila sebuah modul melakukan I/O ekstemal, maka pengujian interface tambahan

harus dilakukan.

Atribut file sudah benar?

Pemyataan OPEN/CLOSE sudah benar?

Spesifikasi format sudah cocok dengan pernyataan I/O?

Ukuran buffer sudah cocok dengan ukuran rekaman?

File dibuka sebelum penggunaan?

Apakah kondisi End-of-File ditangani?

Kesalahan I/O ditangani?

Adakah kesalahan tekstual di dalam informasi output?

Kesalahan yang umum di dalam komputasi adalah:

kesalah-pahaman atau prosedur aritmatik yang tidak benar

operasi mode yang tercampur

inisialisasi yang tidak benar


84

inakurasi ketelitian

representasi simbolis yang tidak benar dari sebuah persamaan.

Test case harus mengungkap kesalahan seperti

perbandingan tipe data yang berbeda

preseden atau operator logika yang tidak benar

pengharapan akan persamaan bila precision error membuat persamaan yang

tidak mungkin

perbandingan atau variabel yang tidak benar

penghentian loop yang tidak ada atau tidak teratur

kegagalan untuk keluar pada saat terjadi iterasi divergen

variabel loop yang dimodifikasi secara tidak teratur.

b. Prosedur Pengujian Unit

Program sumber telah dikembangkan, ditunjang kembali dan diverifikasi untuk

sintaksnya, maka perancangan test case dimulai. Peninjauan kembali perancangan

informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul

bukan program yang berdiri sendiri maka driver (pengendali) dan atau stub PL

harus dikembangkan untuk pengujian unit.

Driver adalah program yg menerima data untuk test case dan menyalurkan ke

modul yg diuji dan mencetak hasilnya.

Stub melayani pemindahan modul yg akan dipanggil untuk diuji.

PENGUJIAN INTEGRASI

Pengujian terintegrasi adalah teknik yg sistematis untuk penyusunan struktur program,

pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg nantinya

digabungkan dengan interface.

Metode pengujian

top down integration

buttom up integration

a. Top Down Integration

Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul

dipadukan dgn bergerak ke bawah melalui kontrol hirarki dimulai dari modul


85

utama. Modul subordinat ke modul kontrol utama digabungkan ke dalam struktur

baik menurut depth first atau breadth first.

Proses integrasi:

modul utama digunakan sebagai test driver dan stub yang menggantikan

seluruh modul yg secara langsung berada di bawah modul kontrol utama.

Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth)

Uji coba dilakukan selama masing-masing modul dipadukan

Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan dgn modul

sebenarnya.

Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain

yang mungkin muncul.

b. Bottom Up Integration

Pengujian buttom up dinyatakan dgn penyusunan yang dimulai dan diujicobakan

dengan atomic modul (modul tingkat paling bawah pada struktur program). Karena

modul dipadukan dari bawah ke atas, proses yang diperlukan untuk modul

subordinat yang selalu diberikan harus ada dan diperlukan untuk stub yang akan

dihilangkan.

Strategi pengujian :

Modul tingkat bawah digabungkan ke dalam cluster yang memperlihatkan

subfungsi PL

Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan

output

Cluster diuji

Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas pada struktur

program


86

Gambar 8.9 Bottom Up Integration

UJI COBA VALIDASI

Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi testing.

Pengujian validasi dikatakan berhasil bila fungsi yg ada pada PL sesuai dgn yg

diharapkan pemakai. Validasi PL merupakan kumpulan seri uji coba black box yg

menunjukkan sesuai dgn yg diperlukan.

Kemungkinan kondisi setelah pengujian:

1. Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat diterima.

2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.

Pengujian BETA dan ALPHA

Apabila PL dibuat untuk pelanggan maka dapat dilakukan acceptance test sehingga

memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Test ini dilakukan

karena memungkinkan pelanggan menemukan kesalahan yang lebih rinci dan

membiasakan pelanggan memahami PL yg telah dibuat.

a. Pengujian Alpha

Dilakukan pada sisi pengembang oleh seorang pelanggan. PL digunakan pada

setting yang natural dgn pengembang “yg memandang” melalui bahu pemakai dan

merekam semua kesalahan dan masalah pemakaian.

b. Pengujian Beta


87

Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam lingkungan

yang sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan

merekam semua masalah (real atau imajiner) yang ditemui selama pengujian dan

melaporkan pada pengembang pada interval waktu tertentu.

UJI COBA SISTEM

Pada akhirnya PL digabungkan dgn elemen sistem lainnya dan rentetan perpaduan

sistem dan validasi tes dilakukan. Jika uji coba gagal atau di luar skope dari proses daur

siklus pengembangan system, langkah yang diambil selama perancangan dan pengujian

dapat diperbaiki. Keberhasilan perpaduan PL dan system yg besar merupakan kuncinya.

Sistem testing merupakan rentetan pengujian yang berbeda-beda dengan tujuan utama

mengerjakan keseluruhan elemen sistem yang dikembangkan.

a. Recovery Testing

Adalah system testing yg memaksa PL mengalami kegagalan dalam bermacam-

macam cara dan memeriksa apakah perbaikan dilakukan dengan tepat.

b. Security Testing

Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg

akan dibuat oleh system, melindungi dari hal-hal yang mungkin terjadi.

c. Strees Testing

Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji.

Testing ini dilakukan oleh system untuk kondisi seperti volume data yang tidak

normal (melebihi atau kurang dari batasan) atau frekuensi.


88

DAFTAR PUSTAKA

Anonim, (2013). Analisis Terstruktur. http://soft-to-gine.blogspot.com/2011/09/analisis-

terstruktur.html. Diakses 30 Januari 2013.

Darwiyanti, Sri dan Wahono Satrio Romi. Pengantar Unified Modeling language.

http://setia.staff.gunadarma.ac.id /Downloads /files/6039/MateriSuplemenUml.pdf.

Diakses 5 Februari 2013.

Pressman, S, R. (2002). Rekayasa Perangkat Lunak. Andi. Yogyakarta.

Jogiyanto,H.(1990).Analisis dan Design Sistem Informasi: Pendekatan Terstruktur

Teori dan Praktek Aplikasi Bisnis. Yogyakarta : ANDI Publisher.

Nugroho P E, Ratnasar K, Ramadhani N K, dan Putro L B. (2013 ). Rekayasa Perangkat

Lunak http://courseware.politekniktelkom.ac.id/BUKU_MI/Semester%203/IS213%20

Rekayasa%20Perangkat%20Lunak/Rekayasa%20Perangkat%20Lunak.pdf. Diakses 5

Februari 2013.

Verdi Yasin, Rekayasa Perangkat Lunak Berorientasi Objek, Mitra Wacana Media, Jakarta

2012.

http://courseware.politekniktelkom.ac.id/BUKU_MI/Semester%203/IS213

BAB I PENGENALAN REKAYASA PERANGKAT LUNAK 1.informatikaunindra.org/file/RPL/Diktat/Diktat...

Documents

Transcript of BAB I PENGENALAN REKAYASA PERANGKAT LUNAK 1.informatikaunindra.org/file/RPL/Diktat/Diktat...