Perancangan Sistem Informasi

5.1. Perencanaan proyek

Perencanaan Proyek (Project Planning) merupakan awal dari serangkaian aktivitas secara kolektif dari sebuah proses Manajemen Proyek Perangkat Lunak. Proses manajemen proyek perangkat lunak dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah estimation (perkiraan). Estimasi menjadi dasar bagi semua aktivitas perencanaan proyek yang lain dan perencanaan proyek memberikan sebuah peta jalan bagi suksesnya rekayasa perangkat lunak, maka tanpa estimasi kita tidak dapat berjalan dengan baik.

 1.Observasi pada Estimasi

Estimasi sumber daya, biaya dan jadwal untuk usaha pengembangan perangkat lunak membutuhkan pengalaman, mengakses informasi histories yang baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada.Estimasi membawa resiko yang inheren dan resiko inilah yang membawa kepada ketidakpastian.Dibawah ini merupakan faktor-faktor yang mempengaruhi estimasi.

Project Complexity (Kompleksitas Proyek)

Kompleksitas Proyek berpengaruh kuat terhadap ketidapastian yang inheren dalam perencanaan.Tetapi kompleksitas merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya.

Project Size (Ukuran Proyek)

Bila ukuran bertmbah maka ketergantungan diantara berbagai elemen perangkat lunak akan meningkat dengan cepat. Dekomposisi masalah sebagai suatu pendekatan yang sangat penting dalam proses estimasi menjadi lebih sulit karena lagi karena elemen-elemen yang akan didekomposisimasih sangat berat.

Structural Uncertainty (Ketidakpastian Struktural)

Bila metrik perangkat lunak yang komprehensif dapat diperoleh pada proyek yang telah lalu, maka estimasi dapat dilakukan dengan kepastian yang lebih tinggi.jadwal dapat dibuat untuk menhindari kesulitan-kesuliatan yang terjadi di masa lalu, dan resiko keseluruhan dapat dikurangi.

 2. Tujuan Perencanaan Proyek Perangkat Lunak

Tujuan umum dari perencanaan proyek perangkat lunak adalah:

1. Menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggung-jawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan seharusnya diperbaharui secara teratur selagi proyek sedang berjalan.
2. Untuk pengawasan, penelusuran, dan pemantauan sebuah proyek teknik yang kompleks.

 3. Ruang Lingkup Perangkat Lunak

Aktivitas pertama dalam perencanaan perangkat lunak adalah penentuan ruang lingkup perangkat lunak yang terdiri dari

1. Fungsi, Untuk memberikan awalan yang lebih detail pada saat dimulai estimasi.
2. Kinerja, Melingkupi pemrosesan dan kebutuhan waktu respon.
3. Batasan, Mengidentifikasi batas yang ditempatkan pada perangkat lunak oleh hardware eksternal, memori dan system lain.
4. Interface, Konsep sebuah Interface diinterpretasikan untuk menentukan:
5. Hardware yang mengeksekusi perangkat lunak dan device yang dikontrol secara langsung oleh perangkat lunak.
6. Software yang sudah ada dan harus dihubungkan dengan perangkat lunak baru.
7. Manusia yang menggunakan perangkat lunak melalui perangkat I/O
8. Prosedur
9. Realibilitas (Keandalan)

 Untuk mengerti Ruang Lingkup tersebut, maka perekayasa perangkat lunak harus:

1. Mengerti kebutuhan pelanggan
2. Mengerti konteks bisnis
3. Mengerti batasan-batasan proyek
4. Mengerti motivasi pelanggan
5. Mengerti alur kearah perubahan

 Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan dan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara pendahuluan.Gause & Weinberg mengusulkan bahwa analisis harus memulainya dengan mengajukan pertanyaan-pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan membawa kepada pemahaman yang mendasar terhadap masalah, orang yang menginginkan suatu solusi, sifat solusi yang diharapkan, dan efektivitas pertemuan itu sendiri.

Informasi yang dibutuhkan (awal pertemuan antara pelanggan dan pengembang) :

Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan.

Siapa di belakang permintaan kerja ini ?

Siapa yang akan memakai solusi ini?

Apakah keuntungan ekonomi dari solusi yang sukses?

Adakah sumber daya lain bagi solusi ini?

 

Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan pelanggan menyuarakan persepsi tentang sebuah solusi.

Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan oleh sebuah solusi yg baik?

Masalah apa yang dituju solusi ini?

Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai?

Adakah batasan atau isu kinerja khusus yg akan mempengaruhi

 

4. Sumber Daya

Tugas kedua perencanaan perangkat lunak adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut.Gambar berikut memperlihatkan sumber daya pengembangan sebagai sebuah piramid.Piramida diatas memperlihatkan sumber daya pengembangan sebagai sebuah piramis.Piranti perangkat keras dan perangkat lunak berada pada fondasi dan menyediakan infrastruktur untuk mendukung usaha pengembangan (lingkungan pengembang). Dalam tingkat yang lebih tinggi terdapat komponen perangkat lunak reusable, blok bangunan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat pencapaian. Pada puncak piramida terdapat sumber daya utama yaitu manusia.

Dibawah ini merupakan penjelasan lebih spesifik mengenai sumber daya.

Sumber Daya Manusia

Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk mnyelesaikan pengembangan.Baik posisi organisasi maupun specialty.Jumlah orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan setelah estimasi usaha pengembangan dibuat.

Komponen Perangkat lunak (reusable)

Kreasi dan penggunaan kembali blok bangunan perangkat lunak yang seharusnya dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan pada saat perencanaan berlangsung, yaitu :

Komponen Off-the self

Perangkat lunak yang ada dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal untuk proyek sebelumnya.

Komponen Full-Experience

Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat ini.

Komponen Partial-Experience

Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi substansial.

Komponen Baru

Komponen perangkat lunak yang harus dibangun oleh tim perangkat lunak khususnya adalah untuk kebutuhan proyek sekarang .Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi secara berkala dapat terjadi.

Lingkungan

Lingkungan yang mendukung proyek perangkat lunak, yang disebut juga software engineering environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Karena sebagian besar organisasi perangkat lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat diperoleh.

Pada saat sebuah sistem berbasis komputer akan direkayasa, tim perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang lain.

 

5. Estimasi Proyek Perangkat Lunak

Estimasi biaya dan usaha perangkat lunak tidak akan pernah menjadi ilmu pasti. Variabel yang terlalu banyak, manusia, teknik, lingkungan, politik dapat mempengaruhi biaya dan usaha akhir yang diaplikasikan untuk mengembangkannya.Ada sejumlah pilihan untuk mencapai estimasi biaya dan usaha yang dapat dipertanggungjawabkan :

1. Menunda estimasi sampai akhir proyek (estimasi akurat 100% bila proyek sudah selesai)
2. mendasarkan estimasi pada proyek-proyek yang mirip yang sudah dilakukan sebelumnya.
3. menggunkana “teknik dekomposisi” yang relatif sederhana untuk melakukan estimasi biaya dan usaha proyek.
4. menggunakan satu atau lebih model empiis bagi estimasi usaha dan biaya Perangkat lunak

 Perkiraan Biaya

1. Ruang Lingkup proyek harus didefinisikan secara eksplisit
2. Tugas dan atau dekomposisi fungsional diperlukan
3. Pengukuran historis sangat membantu
4. Paling sedikit harus digunakan dua teknik berbeda
5. Harus diingat bahwa ketidakpastian adalah hal yang tidak dapat dipidahkan (dari proyek Perangkat lunak).

Akurasi Estimasi perangkat lunak ditentukan oleh:

1. Ukuran yang diperkirakan dari produk.
2. Kemampuan untuk menterjemahkan ukuran ke satuan usaha, waktu dan anggaran.
3. Kemampuan tim menyesuaikan dengan rencana proyek.
4. Stabilitas kebutuhan dan lingkungan.

Secara ideal, teknik yang ditulis untuk masing-masing pilihan harus diaplikasi secara berpasangan, masing-masing digunakan sebagai cross check bagi yang lain. Pada estimasi proyek Perangkat lunak, teknik dekomposisi mengambil cara “membagi dan mengalahkan.”Model estimasi empiris dapat digunakan untuk melengkapi teknik dekomposisi serta menawarkan pendekatan estimasi yang secara potensial berharga. Model berbasis pengalaman dan berbentuk :

 D = f(vi)

 Dimana d adalah satu dari sejumlah harga estimasi (contoh usaha, biaya, durasi proyek) dan vi adalah parameter independen yang dipilih (seperti LOC dan FP yang diestimasi). Peranti estimasi otomatis mengimplementasi satu atau lebih teknik dekomposisi atau model empiris.

5.2 Teknik Dekomposisi

Akurasi estimasi proyek Perangkat lunak didasarkan pada sejumlah hal :

1. tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yang akan dibuat
2. kemampuan untuk menerjemahkan estimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar
3. Tingkat di mana rencana proyek mencerminkan kemampuan tim Perangkat lunak
4. stabilitas syarat produk serta lingkungan yang mendukung usaha pengembangan Perangkat lunak.

Dalam konteks perencanaan proyek, ukuran berarti keluaran yang dapat dikuantitatifkan dari proyek Perangkat lunak. Bila dilakukan pendekatan langsung, ukuran dapat diukur dalam LOC. Tetapi bila dipilih pendekatan tidak langsung, ukuran dihadirkan sebagai FP.

Selama estimasi proyek Perangkat lunak, data LOC dan FP digunakan dalam dua cara :

1. sebagai variabel estimasi yang dipakai untuk “mengukur” masing-masing elemen Perangkat lunak,
2. Sebagai metrik baseline yang dikumpulkan dari proyek yang lalu dan dipakai dalam hubungannya dengan variabel estimasi untuk mengembangkan proyeksi kerja dan biaya.

 Teknik estimasi LOC dan FP berbeda di dalam tingkat detail yang dibutuhkan untuk dekomposisi dan target pembagian. Bila LOC digunakan sebagai variabel estimasi, dekomposisi menjadi sangat penting dan sering dipakai pada tingkat yang dapat dipertanggungjawabkan.Semakin besar tingkat pemisahannya, semakin akurat estimasi LOC dan FP yang dikembangkan.

Kemudian three-point atau expected value dihitung. Expected value untuk variabel estimasi (ukuran), EV, dapat dihitung sebagai rata-rata terbobot dari estimasi optimistik (S_opt), paling sering (S_m) dan pesimistik(S_pess). Contohnya :

           EV = (S_opt + S_m + S_pess)/6

 5.3. Model Perkiraan Empiris

Model perkiraan untuk Perangkat lunak komputer menggunakan rumusan yang ditarik secara empiris untuk memprediksi usaha sebagai sebuah fungsi LOC dan FP. Data empiris yang mendukung sebagian besar model perkiraan ditarik dari sebuah sampel proyek yang terbatas.Karena itulah maka tidak ada model perkiraan yang sesuai untuk semua kelas Perangkat lunak dan dalam semua lingkungan pengembangan.

 1. Struktur Model Perkiraan

 Di antara berbagai model perkiraan yang berorientasi pada LOC yang diusulkan dalam literatur ini adalah :

          E = 5,2 x (KLOC)^0,91                     Walston-felix Model

          E = 5,5 + 0,73 x (KLOC)^1,16            Baily-Basili Model

          E = 3,2 x (KLOC)^1,05                     Model sederhana Boehm

          E = 5,288 x (KLOC)^1,047                 Dotu Model untuk KLOC > 9

 Model-model orientasi FP juga telah diusulkan, yaitu :

          E = -13,39 + 0,0545 FP                Albercht dan Gaffney Model

          E = 60,62 x 7,728 x 10^-8FP³          Kemerer Model

          E = 585,7 + 15,12 FP                    Matson, Barnett, dan Mellichamp Model

 2. Model COCOMO

Barry Boehm memperkenalkan hirarki model estimasi Perangkat lunak dengan nama COCOMO, kependekatan dari COnstructive COst Model (Model Biaya Konstruktif). Hirarki model Boehm berbentuk sbb :

Model 1 :       Model COCOMO Dasar menghitung usaha pengembangan Perangkat lunak (dan biaya) sebagai fungsi dari ukuran prgram yang diekspresikan dalam baris kode yang diestimasi.

Model 2 :       Model COCOMO Intermediate menghitung usaha pengembangan Perangkat lunak sebagai fungsi ukuran program dan serangkaian “pengendali biaya” yang menyangkut penilaian yang subyektif terhadap produk, perangkat keras personil, dan atribut proyek.

Model 3 :       Model COCOMO advanced menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dll) dari proses rekayasa Perangkat lunak.

Proyek Perangkat Lunak                a_b                b_b                c_b                 d_b

Organik                                      2,4               1,05             2,5               0,38

Semi-detached                             3,0               1,12             2,5               0,35

Embedded                                  3,6               1,20             2,5               0,32   

 Model COCOMO ditetapkan untuk tiga kelas proyek Perangkat lunak :

1. mode organik – proyek Perangkat lunak yang sederhana dan relatif kecil di mana tim kecil dengan pengalaman aplikasi yang baik.
2. mode semi-detached – proyek Perangkat lunak menengah 9dalam ukuran dan kompleksitas) di mana tim dengan pengalaman pada tingkat tingkat yang berbeda-beda harus memenuhi bauran yang kurang kuat dari syarat yang ketat (misalnya sistem pemrosesan transaksi dengan syarat tertentu untuk PK terminal dan Perangkat lunak database)
3. modeembedded – proyek Perangkat lunak yang harus dikembangkan ke dalam serangkaian PK, Pl dan batasan operasional yang ketat (seperti Perangkat lunak  kontrol penerbangan untuk pesawat udara).

Persamaan COCOMO dasar berbentuk :

          E = a_bKLOCb_b

          D = c_bEd_b

Dimana         E adalah usaha yang diaplikasikan dalam person-month,

                    D adalah waktu pengembangan dalam bulan kronologis

          KLOC adalah jumlah baris penyampaian kode yang diperkirakan untuk proyek tsb.

          Koefisien a_b dan c_b  dan eksponen b_b dan d_b ada pada tabel 5.1.

Model COCOMO menengah berbentuk :

          E = a_iKLOCb_i x EAF

Dimana         E adalah usaha yang diaplikasikan dalam person-month,

          KLOC adalah jumlah baris penyampaian kode yang diperkirakan untuk proyek tsb.

          Koefisien a_i dan eksponen b_i ada pada tabel 5.2.

Proyek Perangkat Lunak                a_i                 b_i                

Organik                                      3,2               1,05            

Semi-detached                             3,0               1,12            

Embedded                                  2,8               1,20                      

 3. Persamaan Perangkat Lunak

Persamaan perangkat lunak adalah model yang multivariasi yang mengasumsikan distribusi khusus usaha sepanjang hidup proyek pengembangan Perangkat lunak. Berdasarkan data-data tersebut, model estimasi berbentuk :

          E = [LOC x B^0,333/P]³ x (1/t4)

Dimana E = usaha dalam person-month atau person-year

             B = ‘faktor skill khusus” yang meningkat secara perlahan. Untuk program kecil (KLOC = 5 – 15) B = 0,16. Untuk program yang lebih besar dari 70 KLOC, B = 0,39

             t = durasi proyek dalam bulan atau tahun

             P = “parameter produktivitas”

                   P = 2000 untuk pengembangan Perangkat lunak real time

                   P = 10.000 untuk telekomunikasi dan Perangkat lunak sistem

                   P = 28.000 untuk aplikasi sistem bisnis

                   P = 12.000 untuk Perangkat lunak ilmu pengetahuan

 5.4. Keputusan MAKE-BUY

Langkah-langkah membuat keputusan MAKE-BUY dapat ditelusuri dengan membuat Analisis Pohon Keputusan. Di sini kita akan mencari expected cost dengan rumus sbb :

          Expected cost = S (jalur probabilitas)_i x (biaya jalur terestimasi)_i

Dimana i adalah garis edar pohon keputusan. Ini berarti bahwa  :

Expected cost_built = 0,30($380K) + 0,70 ($450K) = $429K

Expected cost_reuse = 0,40($275K) + 0,60[0,20($310K)+0,80($490K)] = $382K

Expected cost_buyt = 0,70($210K) + 0,30 ($400K) = $267K

Expected cost_contract = 0,60($350K) + 0,40 ($500K) = $410K

Berdasarkan biaya probabilitas dan proyeksi yang telah ditulis pada gambar 5.6, expected cost yang paling rendah adalah pilihan buy.

Namun penting pula untuk dicatat bahwa banyak kriteria – bukan hanya biaya- harus dipertimbangkan selama proses pembuatan keputusan. Keberadaan, pengalaman pengembang/vendor/kontraktor, penyesuaian terhadap kebutuhan, dan kecenderungan perubahan, juga merupakan beberapa kriteria yang dapat mempengaruhi keputusan akhir untuk memilih garis built, reuse, buy atau contract.

			Sederhana(0,30)	$380,000
	Built		Sulit (0,70)	$450,000
			Perub. Kecil(0,40)	$275,000
	Reuse
Sistem x		perubahan besar(0,60)	Sederhana(0,20)	$310,000
	Buy		Kompleks(0,80)	$490,000
			Perub. Kecil(0,70)	$210,000
	contract		Perub. Besar(0,30)	$400,000
			Tanpa perub(0,60)	$350,000
			Dengan perub(0,40)	$500,000

Gambar 5.1.Pohon Keputusan untuk Mendukung keputusan MAKE-BUY

 

5.5. Komponen Sistem Informasi

Sistem informasi terdiri dari komponen-komponen yang disebut blok bangunan (building blok), yang terdiri dari komponen input, komponen model, komponen output, komponen teknologi, komponen hardware, komponen software, komponen basis data, dan komponen kontrol. Semua komponen tersebut saling berinteraksi satu dengan yang lain membentuk suatu kesatuan untuk mencapai sasaran.
 

1. Komponen input

Input mewakili data yang masuk kedalam sistem informasi. Input disini termasuk metode dan media untuk menangkap data yang akan dimasukkan, yang dapat berupa dokumendokumen dasar.

2. Komponen model

Komponen ini terdiri dari kombinasi prosedur, logika, dan model matematik yang akan memanipulasi data input dan data yang tersimpan di basis data dengan cara yag sudah ditentukan untuk menghasilkan keluaran yang diinginkan.

3. Komponen output

Hasil dari sistem informasi adalah keluaran yang merupakan informasi yang berkualitas dan dokumentasi yang berguna untuk semua pemakai sistem.

4. Komponen teknologi

Teknologi merupakan “tool box” dalam sistem informasi, Teknologi digunakan untuk menerima input, menjalankan model, menyimpan dan mengakses data, neghasilkan dan mengirimkan keluaran, dan membantu pengendalian dari sistem secara keseluruhan.

5. Komponen hardware

Hardware berperan penting sebagai suatu media penyimpanan vital bagi sistem informasi.Yang berfungsi sebagai tempat untuk menampung database atau lebih mudah dikatakan sebagai sumber data dan informasi untuk memperlancar dan mempermudah kerja dari sistem informasi.

6. Komponen software

Software berfungsi sebagai tempat untuk mengolah,menghitung dan memanipulasi data yang diambil dari hardware untuk menciptakan suatu informasi.

7. Komponen basis data

Basis data (database) merupakan kumpulan data yang saling berkaitan dan berhubungan satu dengan yang lain, tersimpan di pernagkat keras komputer dan menggunakan perangkat lunak untuk memanipulasinya. Data perlu disimpan dalam basis data untuk keperluan penyediaan informasi lebih lanjut.Data di dalam basis data perlu diorganisasikan sedemikian rupa supaya informasi yang dihasilkan berkualitas.Organisasi basis data yang baik juga berguna untuk efisiensi kapasitas penyimpanannya.Basis data diakses atau dimanipulasi menggunakan perangkat lunak paket yang disebut DBMS (Database Management System).

8. Komponen control

Banyak hal yang dapat merusak sistem informasi, seperti bencana alam, api, te,peratur, air, debu, kecurangan-kecurangan, kegagalan-kegagalan sistem itu sendiri, ketidak efisienan, sabotase dan lain sebagainya. Beberapa pengendalian perlu dirancang dan diterapkan untuk meyakinkan bahwa halhal yang dapat merusak sistem dapat dicegah ataupun bila terlanjur
terjadi kesalahan-kesalahan dapat langsung cepat diatasi.