BAB 2 LANDASAN TEORI Sebelum kita membahas mengenai perancangan aplikasi, terlebih dahulu dijelaskan beberapa definisi yang diperlukan serta beberapa teori yang penting dan diperlukan untuk perancangan aplikasi. 2.1 Model Inventori 2.1.1. Model Inventori Umum Inti dari masalah inventori adalah tentang bagaimana meletakkan order dan menerimanya di dalam set interval waktu. Kebijakan inventori secara umum harus dapat menjawab 2 pertanyaan, yaitu berapa jumlah yang harus diorder dan kapan harus melakukan order. Jawaban dari kedua pertanyaan ini tertuju dalam bagaimana cara meminimalkan model biaya / cost : Total Cost = Purchasing Cost+Setup Cost+Holding Cost+Shortage Cost (2.1) Seluruh biaya ini harus dinyatakan dalam istilah economic order quantity (berapa jumlah yang harus diorder) dan waktu order (kapan melakukan order). Purchasing Cost merupakan harga beli per unit item. Setup Cost merepresentasikan biaya tetap yang diperlukan untuk order barang. Holding Cost merepresentasikan biaya pemeliharaan inventori di dalam stok. Biaya ini meliputi
7 bunga modal, biaya penyimpanan, pemeliharaan. Shortage Cost adalah penalti yang harus ditanggung saat kehabisan stok. Biaya ini meliputi kehilangan pendapatan dan biaya lain yang sifatnya subjektif dalam kaitannya dengan kehilangan nama baik di mata customer. Suatu sistem inventori bisa didasarkan pada review periodik (misalnya order tiap minggu) di mana order dilakukan pada awal periode. Alternatif lain dari hal ini adalah menggunakan review kontinu di mana order baru dilakukan ketika level inventory mencapai titik minimum tertentu, atau sering disebut reorder point. 2.1.2. Metode EOQ Klasik Metode EOQ (Economic Order Quantity) Klasik merupakan metode yang paling mudah dan paling umum digunakan dalam model pengendalian inventori / persediaan. Metode ini juga dikenal karena relatif mudah diaplikasikan. Metode EOQ Klasik ini pertama kali diperkenalkan oleh Harris pada tahun 1913, tetapi kemudian disempurnakan oleh Wilson pada tahun 1934. Metode EOQ Klasik didasarkan pada beberapa asumsi, yaitu : 1. Jumlah permintaan tetap dan kontinu. 2. Jumlah order dan holding cost tetap. 3. Kuantitas batch tidak harus selalu integer. 4. Seluruh kuantitas batch dikirimkan pada waktu yang sama.
8 Pada metode EOQ klasik digunakan beberapa notasi sebagai berikut : A = Ordering / Setup Cost h = holding cost per unit / waktu d = jumlah unit permintaan / waktu Q = jumlah kuantitas persediaan C = Biaya per unit waktu. Karena stok aman tidak diperlukan dan penyusutan tidak diperhitungkan, maka inventory level akan bervariasi sepanjang waktu, seperti formula di bawah ini. Q d C = h + A 2 Q (2.2) Bagian pertama dari formula ini (Qh/2) merepresentasikan holding costs, yang kita dapatkan sebagai stok rata-rata. Jumlah rata-rata dari order per unit waktu adalah direpresentasikan dalam d/q. Dengan mengalikan d/q dengan ordering cost A, kita dapatkan biaya order / ordering cost biaya order per satuan waktu. Gambar 2.1. Grafik Perkembangan Level Inventori Terhadap Waktu (Axsater 2002)
9 Fungsi biaya C terlihat jelas berbentuk cembung terhadap Q, dan kita bisa mendapatkan Q optimum dari syarat turunan pertama. dc dq h d = A 2 Q 2 = 0 (2.3) Dengan memecahkan Q kita dapat mencari economic order quantity optimal ( Q *). 2Ad Q* = (2.4) h Jika kita memasukkan (2.4) ke dalam (2.2), maka kita akan mendapatkan Adh Adh C* = + = 2Adh (2.5) 2 2 Pada optimal order quantity ini holding cost akan sama dengan ordering costs. Di persamaan (2.2) telah ditunjukkan biaya sebagai fungsi dari economic order quantity Q. Sebagai alternatifnya, kita juga bisa menyatakan biaya dalam fungsi siklus waktu T = Q/d, dan T* = Q*/d. 2.1.3. Reorder Point Dalam EOQ digunakan review kontinu kebijakan (R,Q) untuk menentukan penentuan reorder point. Jika lead time L = 0 kita dapat mengatakan bahwa R = 0. Ini menunjukkan bahwa kita melakukan order saat posisi inventori = 0 dan kita mendapatkan pengiriman segera. Saat L=0, posisi inventori selalu sama dengan level inventori. Kemudian kita menggunakan asumsi L>0. Sebagaimana telah ditunjukkan di atas, kita harus melakukan order lebih awal, maka dari itu perlu untuk mengganti reorder point ke R = Ld, dan dapat ditambahkan lead time permintaan yang deterministik. Order dilakukan ketika posisi inventori sama dengan R.
10 2.1.4. Quantity Discount Secara umum, relatif mudah untuk memasukkan biaya lain yang bervariasi dengan kuantitas order dalam lot sizing models. Jika kuantitas order cukup besar, kita bisa mendapat discount untuk seluruh unit terhadap harga beli unit. Kita dapat mendefinisikan variabel v dan v sebagai berikut : v = harga per unit untuk Q < Q 0, ini adalah harga normal v ' = harga per unit untuk Q Q 0, dimana v ' < v Syarat untuk harga yang lebih murah ini adalah jika Q Q 0, tetapi juga dimungkinkan hal lain, yaitu diskon hanya berlaku untuk jumlah unit di atas breakpoint Q 0. (Benton dan Park,1996). Holding cost akan bergantungan pada unit cost dan kita anggap hal ini mengikuti struktur berikut : h = h 0 + rv, untuk Q < Q 0 (2.6) h = h 0 + r v ', untuk Q Q 0 Dengan melihat asumsi bahwa holding cost terdiri dari 2 bagian, yaitu biaya modal yang didapat dengan memasukkan rate bunga r pada unit cost, dan holding cost lain h 0 yang didapat bersifat bebas terhadap harga per unit. Sebagaimana telah disebutkan sebelumnya, A adalah ordering cost dan d adalah permintaan tetap per satuan waktu. Mengingat biaya pembelian / purchasing cost bergantung pada jumlah order, maka hal ini harus dimasukkan ke dalam fungsi objektif yang digunakan untuk menentukan Q. Dari persamaan (2.2), kita bisa dapatkan persamaan sebagai berikut :
11 Q d C = dv + ( h0 + rv) + A, untuk Q < Q 0 (2.7) 2 Q Q d C = dv + ( h0 + rv' ) + A, untuk Q Q 0 (2.8) 2 Q Untuk mendapatkan solusi optimal kita dapat menggunakan 2 step berikut : 1. Pertama, masukkan persamaan (2.8) tanpa constrain Q Q 0. Maka akan didapatkan : 2Ad Q' = (2.9) h 0 + rv' C ' = 2Ad( h0 + rv') + dv' (2.10) Perhatikan bahwa karena v <v, (2.8) menghasilkan batas bawah / lower bound untuk (2.7) dengan Q < Q 0. Maka dari itu, jika Q Q 0, persamaan (2,9) dan (2,10) akan memberikan solusi optimal, dengan Q* = Q, dan C*= C. 2. Jika Q < Q 0 seperti yang ditunjukkan di gambar berikut, maka optimasi fungsi biaya (2.7) harus dilakukan, dan hasilnya akan menjadi sebagai berikut. 2Ad Q' ' = (2.11) h + rv 0 C' ' = 2Ad( ho + rv) + dv (2.12) Mengingat v > v, maka kita dapat mengetahui bahwa Q adalah lebih kecil dari Q, maka bisa ditarik kesimpulan bahwa Q < Q < Q 0. Secara jelas,
12 disini terlihat bahwa persamaan (2.11) dan (2.12) menyediakan biaya terendah yang mungkin tanpa memasukkan discount. Karena konveksitas dari persamaan (2.8) dan bahwa Q < Q 0, kita dapat mengetahui bahwa biaya terendah dengan discount adalah Q0 d C( Q0 ) = dv' + ( h0 + rv' ) + A (2.13) 2 Q 0 Solusi optimal pada kasus ini secara konsekuen dapat diperoleh sebagai nilai minimum dari persamaan (2.12) dan (2.13). Gambar 2.2. Fungsi biaya untuk berbagai nilai Q yang berbeda Pada gambar 2.2 diatas, karena v > v, maka persamaan (2.10) dengan Q akan menghasilkan biaya yang lebih tinggi dibanding persamaan (2.11) yang menggunakan variabel Q. Dengan melihat pasangan persamaan (2.9),(2.10), (2.11), dan (2.12), kita dapat mengetahui bahwa variabel v dan v berbanding terbalik dengan biaya yang diperlukan.
13 2.1.5. Time-Varying Demand Sampai bagian ini, hanya dibicarakan tentang permintaan yang sifatnya tetap. Tetapi di sisi lain, time-varying demand atau permintaan yang berubah sesuai waktu juga sering terjadi. Variasi ini dapat terjadi karena beberapa alasan yang berbeda. Sebagai contoh, sebuah item bisa digunakan sebagai komponen yang digunakan dalam memproduksi beberapa produk hanya dalam keadaan tertentu. Kemungkinan lain adalah produksi berbasis kontrak, yang mengharuskan sejumlah barang dikirimkan pada tanggal yang spesifik. Ada alasan lain juga, yaitu variasi musim dalam permintaan. Dalam hal ini dibicarakan permintaan yang deterministik, di mana semua variasi sudah dikenal, dan faktor lead time masih dapat diabaikan. Ketika berhubungan dengan lot sizing untuk permintaan yang berubah sesuai waktu, secara umum dapat diasumsikan bahwa ada sejumlah time step tertentu yang bersifat diskret, atau periode. Suatu periode bisa sebagai contoh satu hari atau satu minggu. Sebelumnya telah diketahui bahwa permintaan pada tiap periode, atau mudahnya, diasumsikan bahwa permintaan periodik terjadi pada awal periode, dan tidak ada stok awal. Ketika pengiriman barang, semua barang dikirimkan pada waktu yang sama. Holding cost dan ordering cost bersifat tetap sepanjang waktu. (Inventory Control, Axsater, 2002). Pada permintaan yang berubah sesuai waktu kita bisa menggunakan notasi berikut : A = Ordering Cost h = holding cost per unit / waktu d i = jumlah unit permintaan pada periode i, i = 1,2,, T. (diasumsikan bahwa d 1 > 0)
14 T = jumlah periode Pada bagian ini kita memilih kuantitas batch, sehingga jumlah order dan holding cost dapat diminimalkan. Problem ini biasanya disebut sebagai masalah classical dynamic lot size. Karena permintaan berubah terhadap waktu, kita tidak bisa mengharapkan lot size optimal untuk selalu konstan. Ada 2 property yang disampaikan oleh Taha (2003) terkait hal ini : 1. Replenishment / pengisian / pelengkapan harus selalu memenuhi permintaan dalam sebuah bilangan integer periode yang saling berkaitan. Hal ini sering disebut sebagai zero-inventory property, berarti bahwa pengiriman hanya dilakukan saat jumlah inventori berjumlah nol. 2. Holding cost untuk permintaan yang periodik tidak boleh melebihi ordering cost. 2.2 Dynamic Programming Dynamic Programming adalah suatu teknik untuk menentukan solusi optimum untuk n-variabel dengan cara melakukan proses dekomposisi ke dalam n stage dengan tiap stage, di mana tiap stage menghasilkan single variabel untuk tiap sub problem. (Taha, 2003). Ide dasar dari dynamic programming adalah melakukan dekomposisi / penguraian problem dan membagi ke dalam stage, lalu melakukan perhitungan solusi optimal tiap sub problem. Keuntungan menggunakan perhitungan dengan metode dynamic programming adalah dapat mengoptimalkan solusi single variabel untuk tiap sub problem. Perhitungan dalam dynamic programming
15 dilakukan secara rekursif, di mana solusi optimal untuk satu subproblem digunakan sebagai input untuk sub problem berikutnya. Ketika sub problem terakhir terpecahkan, solusi optimal dari keseluruhan problem akan didapatkan. Secara umum, tiap subproblem ini dihubungkan oleh constrain umum. Saat kita bergerak dari satu sub problem ke sub problem lain, feasibility dari constrain umum ini tetap dibawa / diturunkan. Secara umum, perhitungan rekursif dalam dynamic programming ini dapat diringkas ke dalam suatu model ekspresi matematika umum sebagai berikut : f ( x ) min/ max{ d( x, x ) + f ( 1)( x 1)}, i i i = i 1 i i i = 1,2,3,... Di mana pencarian nilai optimum minimum atau maksimum ini dilakukan pada interval yang mungkin / feasible. Perhitungan ini dimulai dari i=1, dan set rekursif f x ) = 0. Persamaan ini menunjukkan bahwa solusi optimum subproblem o ( o f x ) pada stage i harus dinyatakan dalam istilah node berikutnya, x i. Dalam i ( i terminologi dynamic programming, x i menunjuk state system pada stage i. Sebagai akibatnya, state sistem pada stage i dianggap sebagai informasi yang menghubungkan bersama seluruh stage yang ada, dan keputusan optimal pada sisa stage yang ada dapat dibuat tanpa mengecek ulang bagaimana keputusan untuk stage berikutnya dicapai. Definisi yang benar tentang state membuat kita untuk memisahkan setiap stage secara terpisah dan menjamin bahwa solusi yang dihasilkan feasible untuk semua stage. Definisi dari state ini mengantar kita kepada kerangka kerja terpadu dalam dynamic programming. Prinsip optimalitas menyebutkan bahwa
16 keputusan mendatang dari stage yang tersisa akan menghasilkan kebijakan optimal, tidak peduli terhadap kebijakan yang diadopsi dalam stage sebelumnya. (Taha, 2003). Salah satu aplikasi praktis dari dynamic programming ini adalah solusi rute terpendek. 2.3 Algorima Wagner-Whitin Pada dunia inventori, jumlah permintaan barang bisa tetap atau berubah sesuai berjalannya waktu, dan masalah ini sebelumnya telah dijelaskan pada bab sebelumnya tentang time-varying demand. Untuk menyelesaikan masalah inventory yang ditimbulkan karena berubahnya barang sesuai berjalannya waktu, pendekatan yang paling umum digunakan adalah menggunakan solusi Dynamic Programming. Penyelesaian dengan metode ini pertama kali diperkenalkan oleh Wagner dan Whitin pada tahun 1958 dan solusi mereka sering disebut sebagai algoritma Wagner-Whitin. (Axsater, 2002). Kita dapat menggunakan notasi sebagai berikut : f k = biaya minimum pada periode 1,2,, k, di mana kita mengabaikan periode k+1, k+2, T f k, t = biaya minimum pada periode 1,2,, di mana pengiriman terakhir berada dalam periode t. ( 1 t k) (3.1) Pertama-tama, mari kita perhatikan bahwa :
17 =, di mana ( 1 t k) (3.2) f k min f k, t Hal ini disebabkan karena pengiriman terakhir berada pada beberapa periode dalam solusi optimal. Disini cukup jelas bahwa f 0 = 0, dan f 1, 1 = A. Ini karena dengan hanya satu periode, kita hanya mendapatkan setup cost, bukan holding cost. Pemanggilan kembali permintaan periodik diasumsikan terjadi pada permulaan periode. Sekarang kita asumsikan bahwa kita mengetahui ft 1 untuk beberapa t > 0. Kita bisa dengan mudah mencari f, untuk k t sebagai berikut : k t f ft 1 + A + h( dt + 1 + 2dt 2 +... + ( k t) d ) (3.3) k, t = + k Karena kita memiliki pengiriman pada periode t, maka biaya minimum untuk periode 1,2,,t-1 haruslah f t 1. Biaya pada periode t adalah setup cost A. Permintaan diasumsikan terjadi pada permulaan periode. Ini berarti bahwa d t tidak akan menyebabkan terjadinya holding cost. Permintaan pada periode t+1 mendatangkan holding cost hd t + 1, karena kuantitas dt + 1 disimpan di dalam stok selama periode t. Permintaan pada periode t+2 juga serupa, disimpan dalam stok selama 2 periode, t dan t+1, dan menyebabkan holding cost sebesar 2 hd t + 2, dan seterusnya. Kita sekarang bisa mengasumsikan, bahwa kita mengetahui f 1, f2,..., f k 1, dan kita sudah memecahkan problem untuk periode 1,2,, k-1. Selanjutnya kita dapat
18 menentukan f, untuk interval k t 1 t k dari persamaan (3.3). Selanjutnya kita memasukkan persamaan (3.2) untuk mendapatkan f k dan problem untuk periode k ini juga terpecahkan. Setelah itu kita telah siap untuk menggunakan prosedur yang sama untuk periode k+1, dan seterusnya. Dari bab sebelumnya kita telah mengetahui bahwa jika h( j t) d j > A, kita tidak perlu menentukan f k, t untuk k j ketika memasukkan persamaan (3.3). Lebih jauh lagi, sangat jelas bahwa kita hanya perlu menganggap k T. Setelah melalui seluruh periode T, kita mendapatkan solusi optimal sebagai berikut. Pertama kita menganggap persamaan (3.2) untuk k=t. Nilai minimum adalah biaya minimum, dan t yang diminimumkan adalah periode dengan pengiriman terakhir. Perhatikan meminimumkan t dengan t '. Karena pengiriman terakhir berada dalam periode t, solusi untuk periode 1,2,, t-1 harus juga optimal. Maka sekali lagi kita memasukkan persamaan (3.2) untuk k = t' -1. Pengiriman terakhir yang optimal untuk masalah ini,dianggap t, adalah pengiriman yang kedua dari terakhir untuk keseluruhan masalah. Sekarang kita memasukkan persamaan (3.2) untuk k = t' ' -1, dan kita lanjutkan dengan cara ini sampai t minimum sama dengan satu, karena kita memiliki semua periode dengan pengiriman. Berikut ini diberikan contoh pemodelan aplikasi Wagner Whitin agar dapat mempermudah pemahaman tentang metode kalkulasi yang digunakan : Permintaan dalam T = 10 periode diberikan dalam 2 baris pertama tabel 3.1. Ordering cost A = $300 dan holding cost h=$1 per unit dan satuan waktu. Tabel 2.1. Contoh solusi untuk f k, t
19 Solusi : Dalam tabel 2.1 kita mulai dengan setting f $ 300. Selanjutnya kita 1,1 = menggunakan persamaan (3.3) untuk menentukan f 2, 1 = f 1, 1 +1*60 = 360, f 3,1 = 2, 1 f +2*90 = 540, dan seterusnya. Ketika kita sampai di f 6, 1 kita akan lihat bahwa holding cost yang berkaitan dengan permintaan di periode 6 = 500 > A=300 dan kolom sudah lengkap. Sangat jelas di sini bahwa f = f 300. Dengan 1 1,1 = mengguanakan persamaan (3.3) kita mendapatkan f 2,2, f3, 2, dan seterusnya. Setelah menyelesaikan kolom ini kita memasukkan persamaan (3.2) untuk mendapatkan f = min{ f2,1, f2, 2} = min{360,600} 2 = 360. Perhatikan bahwa kedua angka ini berada di garis bawah diagonal pada tabel 3.1. Setelah menyelesaikan kolom berikutnya kita harus mengoptimalkan dari diagonal selanjutnya ke arah kanan untuk mendapatkan f 3 = min{540,690,660} = 540. Kita lanjutkan dengan cara ini sampai tabel lengkap. Kemudian kita akan bisa mendapatkan biaya minimum, yaitu ada di f = min{1550,1630,1570,1550,1770} 1550 dengan menggunakan persamaan (3.2). 10 = Disini jelas bahwa biaya minimum didapat untuk t ' =9 dan t ' =6. Pertama kali kita mencari solusi dengan t =9. Karena pengiriman terakhir ada di periode 9, problem setelah berjalan 8 periode seharusnya sudah bisa dipecahkan secara optimal. Dengan
20 melihat ke diagonal yang berkaitan, kita mendapat t ' ' =6. Selanjutnya kita melihat masalah 5 periode dan mendapat t ' ' ' =3. Selanjutnya kita mendapatkan t ' ' ' ' =1 dan solusi ini lengkap. Kemudian dapat dilakukan verifikasi bahwa solusi optimal lain dengan t ' = 6, ini berarti bahwa 2 batch terakhir dikombinasikan menjadi single batch. 2 solusi optimal diberikan pada tabel 2.2 dibawah. Tabel 2.2. Batch Size Optimal 2.4 Interaksi Manusia dan Komputer 2.4.1 Definisi Interaksi Manusia dan Komputer (IMK) adalah disiplin ilmu yang berhubungan dengan perancangan, evaluasi, dan implementasi sistem komputer interaktif untuk digunakan oleh manusia, serta studi fenomena-fenomena besar yang berhubungan dengannya (Shneidermann, 2003). Interface / antarmuka pemakai adalah bagian sistem komputer yang memungkinkan manusia berinteraksi dengan komputer. 2.4.2 Aturan Emas Perancangan User Interface Untuk melakukan perancangan yang baik, terdapat beberapa aturan yang perlu diperhatikan dan berguna untuk membuat alternatif desain antarmuka, perancangan yang baik dan juga untuk melakukan evaluasi terhadap hasil
21 perancangan yang telah dilakukan. Aturan ini sering disebut 8 aturan emas perancangan User Interface (Shneidermann,2003), yang terdiri dari : 1. Menjaga konsistensi tampilan. 2. Memungkinkan frequent users untuk menggunakan shortcut, sehingga mempermudah user untuk melakukan tugas atau aksi yang sering dilakukan. 3. Memberikan umpan balik yang informatif. 4. Merancang dialog yang memberikan penutupan (keadaan akhir). 5. Memberikan pencegahan kesalahan dan penanganan kesalahan yang sederhana. 6. Memungkinkan pembalikan aksi yang mudah. 7. Mendukung pusat kendali internal ( internal locus of control). 8. Mengurangi beban ingatan jangka pendek. 2.5 Rekayasa Piranti Lunak Software adalah set dari item atau obyek yang membentuk konfigurasi yang termasuk program, dokumen, dan data (Pressman, 1992) Rekayasa Piranti Lunak / software adalah penetapan dan penggunaan prinsip-prinsip rekayasa dalam rangka mendapatkan software yang ekonomis yaitu software yang terpercaya dan bekerja efisien pada mesin / komputer. Ada 3 elemen kunci dalam proses rekayasa software, yaitu :
22 1. Metode : menyediakan cara bagaimana secara teknis membangun software. Metode ini terdiri dari : Perencanaan proyek dan estimasi. Analisis kebutuhan sistem dan software. Rancangan struktur data. Arsitektur program. Algoritma prosedur. Pengkodean Testing Pemeliharaan. 2. Alat bantu / tools : menyediakan dukungan otomatis / semi otomatis untuk metode. Salah satu tools yang sering dipakai dalam perancangan aplikasi adalah Computer Aided Software Engineering (CASE) yang mengkombinasikan software, hardware, dan software engineering database. 3. Prosedur : menggabungkan metode dan alat bantu, mendefinisikan urutan (seguence) metode, mendefinisikan keluaran seperti dokumen, laporan, dan formulir yang dibutuhkan. Selain itu prosedur juga mendefinisikan kontrol yang membantu keyakinan kualitas dan perubahan koordinasi. Dalam proses pengembangan software ada beberapa model yang dapat digunakan, yaitu :
23 1. Model Linear / Klasik. Pada model ini proses perancangan dilakukan secara linear dari awal sampai selesai, dan terdiri dari 6 proses / aktivitas utama yang membentuk siklus, yaitu : a. System engineering / rekayasa sistem. Pada tahap pertama ini, proses rekayasa sistem mulai dilakukan. b. Requirement analysis. Analisis terhadap kebutuhan sistem mulai dilakukan pada tahap ini. c. Design. Proses desain pada tahap ini mencakup perancangan struktur data, arsitektur software, dan prosedur detail. d. Coding Pada tahap ini proses untuk menghasilkan coding terjadi. e. Testing. Proses testing / pengujian software ini berfokus pada logical internal dari software. f. Pemeliharaan / maintenance. Tahapan ini bertujuan untuk menyempurnakan software yang telah dibuat dan juga untuk mengakomodasi terhadap perubahan lingkungan luar, misalnya karena dirilisnya sistem operasi baru, sehingga software perlu disempurnakan dengan patch agar dapat bekerja dengan baik di lingkungan sistem operasi yang baru.
24 System/information engineering analysis design code test Gambar 2.3 Metode Linear 2. Model Sekuensial / Waterfall. Metode ini mirip dengan metode linear, hanya pada tahapan yang ada dilakukan perincian lebih detail, pada metode ini terdiri dari beberapa tahapan / aktivitas, yaitu : a. Market analysis. Proses analisa pasar dilakukan untuk mengetahui jenis software apa yang diinginkan atau dibutuhkan pasar. b. Requirement specification. Fase ini menentukan spesifikasi teknis yang diperlukan oleh sistem / software. c. Cost estimation. Penentuan biaya yang diperlukan untuk pengembangan software.
25 d. Project planning. Perencanaan teknis pelaksanaan proyek pengembangan software diperlukan untuk kelancaran pelaksanaan proyek. e. Requirement review. Setelah perencanaan teknis pelaksanaan, estimasi biaya, dan spesifikasi teknis ditentukan, dilakukan review untuk meneliti secara keseluruhan, apakah ada kesalahan atau kekurangan, sehingga kesalahan fatal dapat dicegah secara dini sebelum proses desain dimulai. f. High level design. Proses desain global software dilakukan pada tahapan high level design ini. g. Low level design. Pada tahap low level design, dilakukan desain terhadap detail dari software. h. Design review. Proses design review dilakukan untuk melihat kembali secara keseluruhan hasil dari proses desain yang telah dilakukan. i. Unit testing. Kinerja dari unit dan modul yang ada diuji pada tahap unit testing ini. j. System testing. Tahap system testing dilakukan untuk menguji operasional sistem software yang telah didesain.
26 k. Acceptance test. Sebelum software hasil pengembangan dipasarkan, perlu dilakukan uji kemampuan penerimaan konsumen terhadap software yang telah dikembangkan. l. Implementasi. Setelah software melewati fase testing, maka dapat dilakukan implementasi pada konsumen. Model sekuensial memiliki beberapa kelebihan, yaitu resiko kegagalan sedikit jika proses awal matang dan berjalan maksimal jika requirement konsumen cenderung statis dan sistem scope kecil. Selain kelebihan, pada model ini terdapat juga kelemahan yaitu tiap tahapan proses memerlukan waktu yang relatif lama, akan tetapi hal ini dapat diatasi dengan menggunakan bantuan model prototyping. 3. Model Incremental. Model ini terdiri dari 4 tahapan utama yaitu analisis, desain, coding, dan test. Tetapi pada model incremental pengembangan dapat dilakukan secara paralel dan dapat dilakukan pipelining. System/information engineering increment 1 analysis design code test delivery of 1st increment increment 2analysis design code test delivery of 2nd increment increment 3analysis design code test delivery of 3rd increment increment 4analysis design code test delivery of 4th incremen calendar time Gambar 2.4. Model Incremental (Schneiderman, 2003)
27 4. Model Spiral. Pada model spiral, proses pengembangan terdiri dari 6 komponen atau aktivitas utama, yaitu planning (perencanaan), risk analysis (analisis resiko), engineering, construction & release (konstruksi dan rilis), customer evaluation dan customer communication. Tiap komponen ini saling bekerjasama seperti membentuk spiral. Planning Risk Analysis Customer Communication Engineering Customer Evaluation Construction & Release Gambar 2.5. Model Spiral 5. Model Prototyping. Prototyping adalah suatu proses yang memungkinkan pembangun software menciptakan sebuah model dari software yang akan dibangun. Pengembangan software dengan menggunakan model prototype juga seringkali disebut pengembangan aplikasi secara cepat atau Rapid Application Development (RAD). Pada model
28 prototyping, proses pengembangan dimulai dengan input dari customer, lalu developer membuat model software, lalu setelah selesai dilakukan test drive atau pengujian pada konsumen, dan selanjutnya developer akan mendengar masukan dari konsumen, lalu jika ada yang perlu diperbaiki developer akan melakukan revisi dan demikian seterusnya proses berulang, sampai proses pengembangan selesai dan didapatkan hasil yang diinginkan. listen to customer build/revise mock-up customer test-drives mock-up Gambar 2.6. Model Prototyping Selain model pengembangan software diatas, juga terdapat tool atau alat bantu perancangan dan modelling yang berupa : 1. State Transition Diagram (STD). State Transition Diagram (STD) merupakan tools modelling yang menggambarkan sifat ketergantungan pada waktu dari suatu sistem, dan menjelaskan perubahan state
29 pada sistem. Pada mulanya hanya digunakan untuk menggambarkan suatu sistem yang memiliki sifat real time, seperti telephone switching system. Notasi yang digunakan pada STD adalah : State Perubahan State Selain state dan perubahan state, untuk melengkapi STD diperlukan condition dan action. Condition adalah suatu event pada external environment yang dapat dideteksi oleh sistem. Sedangkan action adalah yang dilakukan oleh sistem bila terjadi perubahan state atau dapat dikatakan merupakan reaksi terhadap condition. Action akan menghasilkan output, message display pada screen, menghasilkan kalkulasi, dan lainnya. 2. Spesifikasi Proses. Setiap proses di DFD harus memiliki spesifikasi proses, karena tanpa spesifikasi proses kita tidak mengetahui apa yang terjadi di dalam proses tersebut. Spesifikasi proses menjadi pedoman bagi programmer dalam membuat program / coding. Untuk menjelaskan spesifikasi proses dapat berupa narasi / cerita, bahasa natural yang terstruktur seperti bahasa Inggris atau Indonesia, pohon keputusan dan tabel keputusan.