bab 2 an baru1

BAB II

PERENCANAAN PROYEK

Ada beberapa alasan yang menentang perencanaan seperti berikut ini :

“Perencanaan membuang waktu yang banyak “

“Perencanaan sangat mahal “

“Mengapa harus direncanakan bila rencana selesai maka jadwal sudah lewat“

“Setiap proyek berbeda masing-masingnya tidak perlu rencana”

“Perencanaan tidak mendukung fleksibilitas “

“Perencanaan memadamkan kreatifitas “

Suatu perencanaan proyek adalah proses yang membuat bingkai kerja

(framework) untuk bagaimana proyek dijalankan. Termasuk defenisi dan tujuan

proyek, pemilihan pendekatan siklus hidup, pembuatan kebijakan, prosedur dan

proses-proses penting untuk mencapai sasaran, penetapan tanggung jawab dan

perhitungan biaya. Proses perencanaan adalah suatu pekerjaan yang sulit dan

merupakan fungsi utama dari manajemen. Perencanaan bukan hanya :

Memperkirakan / memprediksi sesuatu

Mengidentifikasi resiko, tetapi mencoba mengantisipasi resiko

Suatu proses membuat keputusan yang akan datang

Mengapa perlu rencana ? rencana diperlukan untuk :

Melengkapi pengertian secara umum tentang tujuan dan pekerjaan proyek

Meningkatkan komunikasi dengan baik di dalam proyek

Acuan jadwal yang realistis dan titik kontrol

Mengantisipasi lingkup resiko

Mendapat dukungan dari Manajemen atas

Mengelola keterbatasan sumber daya

II.1 BEBERAPA ISU DALAM PERENCANAAN

Isu penting dalam Perencanaan Perangkat Lunak :

Kebutuhan perangkat lunak adalah sangat sulit untuk dapat dituliskan dengan

tepat

Perencanaan adalah program kegiatan yang sering kali tidak lengkap dan /

atau kurang

14

Kriteria yang dihasilkan tidak dapat dipakai untuk pemilihan teknologi yang

baik

Isu dari suatu Rencana Umum :

Identifikasi dan misi

Tujuan

Maksud

Sumber daya

Rencana kegiatan

Rencana aksi

Hubungan Rencana Umum dengan Rencana Proyek ditunjukkan pada tabel 2.1.

Tabel 2.1. Hubungan antara rencana umum dan rencana proyek

Rencana Umum Rencana Proyek

Identifikasi dan misi Kegunaan dan lingkup proyek

Tujuan Obyektif proyek dan gol manajemen

Maksud Pengendalian, pemantapan proses proyek

Sumber daya Uang, orang, peralatan, waktu

Rencana kegiatan Jaringan kerja, jadwal, anggaran, rencana

pengujian, rencana konversi, penugasan kerja

Rencana- aksi Rencana kontigensi, pengumpulan data,

pelaporan, perencanaan ulang

II.2 PERENCANAAN KONTIGENSI

Kontigensi perlu direncanakan untuk 3 kendala berkaitan dengan proyek, yaitu :

Performansi

Jadwal

Biaya

Orang

Tugas Perencana Kontigensi

Penspesifikasian performansi

Estimasi kesalahan

Perubahan dalam upaya pengembangan

Pelatihan orang baru

Antar muka dengan lainnya

15

Dukungan dari grup lainnya

Perubahan dalam proses pengembangan perangkat lunak

Perubahan dalam prioritas proyek

Panduan untuk perencanaan kontigensi

Tambahkan 10 % diatas estimasi – untuk setiap aktifitas

Gunakan estimasi individual dan ketidak-tentuan

Tambahkan aktifitas yang tidak direncanakan dan dibutuhkan

Analisis performansi proyek yang lalu

Ada beberapa siklus perencanaan seperti yang yang ditunjukkan gambar 2.1 dan gambar 2.2.

Gambar 2.1. Siklus Perencanaan –Contoh 1

16

Inisialisasi kebutuhan

Pengestimasian ukuran produk

Pengestimasian sumber daya produk

Pengembangan jadwal

Penyesuaaian jadwal

Pengembangan PL

Negosiasi utk komitmen

Penilaian komitmen

Kebutuhan yang telah dinegosiasikan

WBS

SLOC

Bulan, orang, waktu & mesin

Proyeksi jadwal

sesuai

aktual

Pembandingan (basis data)

Estimasi

penyesuaian

tidak

Produk yg diserahkan

Keinginan,kebutuhan, kesempatan

Pengusulan proyek

Usulan Proyek

Pembangunan sistem

Sistem yang sudah terinstalasi

Perawatan & pengoperasian System

Gambar 2.2. Siklus Perencanaan – Contoh 2II.3 PENGELOLAAN PROSES PERENCANAAN

Unsur-unsur Perencanaan perangkat lunak adalah ;

17

Gol dan obyektif : yang menggambarkan apa yang dilakukan, untuk siapa,

dan kapan

Work Breakdown Structure (WBS) : WBS membagi tugas proyek dalam sub-

sub tugas yang masing-masing akan didefenisikan,

diestimasi dan di lacak

Mengestimasi besar produk : adalah perkiraan kode yang dibutuhkan secara

kuantitatif untuk masing-masing elemen produk

(subsistem, komponen atau modul). Estimasi ini

didasarkan pada pengalaman utama proyek-proyek yang

lalu

Mengestimasi sumber daya : didasarkan pada pengalaman yang sudah-

sudah, dapat diketahui faktor produktifitas yang

dimasukkan ke bagian perkiraan yang masuk akal bagi

kebutuhan sumber daya untuk tiap-tiap elemen WBS.

Penjadwalan proyek : berdasarkan pada ketersediaan staf proyek dan

perkiraan sumber daya, suatu penjadwalan tugas dan

penyetoran item dapat dihasilkan.

II.4 GOL DAN OBYEKTIF

Gol dan obyektif proyek ditentukan pada tahap kebutuhan dari siklus hidup

pengembangan perangkat lunak, juga pada saat periode negosiasi antara

pengembang perangkat lunak dan user yaitu apa yang akan dilakukan, bagaimana

ukuran kesuksesan, berapa lama waktu yang dibutuhkan dan berapa banyak sumber

daya yang diperlukan. Karena kebutuhan user umumnya berubah sejalan waktu.

Ketika mereka melihat masalah mereka secara sempit, maka perubahan kebutuhan

secara bertahap dikerjakan dalam progress pekerjaan. Perubahan kebutuhan adalah

suatu masalah klasik dalam rekayasa perangkat lunak. Ada beberapa cara untuk

mengelola masalah ini, yaitu tim perangkat lunak harus mengikuti beberapa aturan

sederhana berikut:

1. Implementasikan produk dalam tahapan-tahapan kecil

2. Untuk tiap kenaikan tahap pilih yang mendukung pada kenaikan

berikutnya dan atau tingkatkan pengetahuan terhadap kebutuhan.

3. Tinjau kebutuhan-kebutuhan untuk tiap-tiap kenaikan tapi lakukan

sebelum memulai desain

18

4. Jika kebutuhan berubah selama tahap implementasi, liput perubahan ke

kenaikan tahap berikutnya.

5. Jika perubahan tidak terliput, berhenti bekerja, ubah kebutuhan, ulangi

perencanaan, dan mulai lagi pada desain.

Beberapa pertimbangan utama dari fase kebutuhan adalah :

Kebutuhan fungsional : Fungsi-fungsi produk di daftar, bersama dengan

beberapa performansi atau konstrain lain, Jika

memungkin sebuah draft petunjuk manual user

dibuat atau sebuah prototype di bangun untuk

mentes beberapa item-item pertanyaan.

Kebutuhan sistem : Konfigurasi target sistem ditentukan, bersama

dengan beberapa standarnya, kompatibilitas, atau

konstrain lingkungan.

Identifikasi pelanggan : user diidentifikasi sesuai dukungan

kebutuhannya, termasuk ; mekanisme

penyetoran, pemaketan produk, dukungan

instalasi, kebutuhan dokumentasi, dan

pelatihan.

Mengukur kesuksesan : biaya, penjadwalan, performansi, kualitas,

ukuran, dan ukuran-ukuran kesuksesan lainnya

dikuantifikasi.

Validasi dan Penerimaan : menentukan kesuksesan yang dapat diterima,

termasuk tanggung jawab terhadap Acceptance

testing, kriteria yang dipakai dan beberapa

garansi atau konsekwensi-konsekwensi lain

jika kegagalan terjadi.

Dukungan : Kelanjutan kebutuhana dukungan di tetapkan, termasuk

pelaporan dan koreksi.

II.5 MEMBUAT WORK BREAKDOWN STRUCTURE (WBS)

WBS adalah teknik untuk :

Membagi keseluruhan proyek ke dalam komponen-komponen

19

Memecah komponen ke level-level berikutnya sampai dengan setiap tugas

merupakan unit-unit yang dapat dikelola (misalnya oleh manajer teknik)

seperti :

Direncanakan

Dianggarkan

Dijadwalkan

Dikendalikan

Menampilkan gambar / grafik tentang hirarki proyek

Tujuan WBS :

Melengkapi komunikasi antar personel proyek

Menjaga konsistensi dalam pengendalian dan pelaporan proyek

Cara efektif untuk melengkapi tugas manajemen

Manfaat WBS :

Mengurangi kompleksitas

Fasilitas penjadwalan dan pengendalian

Dimana posisi WBS dalam siklus hidup pengembangan produk ? sebagaimana

ditunjukkan dalam gambar 2.3 , adalah pada tahap-tahap awal, yaitu sebelum tahap

eksplorasi konsep.

Pertimbangan WBS :

Harapan

Hasil yang jelas

Tugas yang fleksibel

Antarmuka minimum

Berhubungan dengan ketrampilan

Level pengendalian

Berhubungan dengan sistem manajemen yang lain

Petugas tradisional

Kepuasan pekerja

20

Gambar 2.3 Siklus Hidup Pengembangan Produk menurut IEEE 1074

Panduan WBS :

1. Pecah setiap fungsi ke dalam 3 subfungsi yang

Menerima masukan dan memasukkannya kebentuk yang

berkaitan

Mentransformasikan masukan ke dalam keluaran yang

dibutuhkan

21

Laporan arsip

Dokumentasi pemeliharaan

Dokumentasi user

Laporan validasi / verifikasi perangkat lunak

Rencana validasi / verifikasi perangkat lunak

Spesifikasi kebutuhan perangkat lunak (SRS)

Biaya

SLC

Model SLC

. SLCs

Operasi dan support

pemeliharaan

Analisis kebutuhan

Desain

Spesifikasi antar muka sistem

Implementasi

Instalasi

Deskripsi desain perangkat lunak

Eksplorasi konsep

Eksplorasi sistem

Dokumen kebutuhan

Pengembalian

Identifikasi SLCs

Memilih model

Peta Task-task ke SLC menggunakan IEEE 1074

Alokasi sumber daya

Menyiapkan keluaran ke dalam bentuk akhir yang diminta

2. Lakukan dekomposisi secara iteratif

3. tidak seluruh cabang mempunyai level yang sama

4. buat struktur produk dengan perangkat lunak

5. WBS bukan hanya untuk proyek saja

6. Jika WBS sangat rumit untuk ditampilkan dalam satu peta maka

pecah setiap level subfungsi dalam peta terpisah

7. bangun inisial WBS oleh manajer proyek

8. kaji dan perbaiki WBS oleh semua kelompok yang berkaitan

9. WBS adalah merupakan / menyerupai struktur pohon

Struktur WBS ditunjukkan seperti gambar 2.3.

Gambar 2.3. Struktur WBS

WBS dapat dibuat dari pendekatan top-down atau bottom-up, seperti

ditunjukkan pada gambar 2.4. Pendekatan top-down meliputi proses dekomposisi

berturut-turut. Pendekatan bottom-up menggunakan brainstorming dan gabungan

diagram. Biasanya pada awal proyek ketika tahap kebutuhan, pendekatan top-down

digunakan. Pendekatan top-down sering digunakan ketika pekerjaan belum

dilaksanakan dan tim proyek memahami langkah-langkah dengan baik. Pendekatan

bottom-up adalah suatu pendekatan yang baik dan sesuai untuk suatu proyek, ketika

tim proyek belum begitu terbiasa dengan langkah-langkah yang akan dilakukan.

pendekatan ini pada umumnya yang dilaksanakan dengan pengungkapan pendapat

semua hal yang dapat dilakukan selama proyek dan kemudian menggolongkan

22

sistem

subsistemsubsistem subsistem

modul modulmodul modulmodulmodul modulmodul modul

aktivitas yang berada dalam tingkatan yang sama dan kemudian mengatur semua

aktivitas ke dalam pengelompokan yang lebih tinggi sampai item yang tertinggi

dicapai.

Gambar 2.4 Membangun WBS secara Tpo-Down atau Bottom-Up

Suatu milestone adalah suatu keadaaan signifikan dalam suatu proyek,

biasanya diasosiasikan dengan pekerjaan utama atau produk yang disetor. Milestone

mempunyai durasi waktu 0. Ia hanya menandai suatu titik dalam waktu ketika

sesuatu yag penting harus diselesaikan. Mereka dapat didefenisikan diakhir satu atau

lebih aktifitas, atau untuk suatu hasil kerja atau setoran. Sebaiknya menggunakan

bahasa yang menunjukkan penyelesaian seperti “ done” atau “completion”. Tahap

ataupun fase bukan milestone tapi adalah sekumpulan aktifitas produk yang saling

berhubungan, tetapi milestone dapat dipakai untuk menandai tahap atau fase

penyelesaian seperti ditunjukkan Gambar 2.4.

23

Tahap

Milestone Milestone

Task

Task

Task

Task

Task

Task

Task

Task

Task

Tahap

Milestone

Task

Task

Task

Task

Task

Task

Task

Tahap

Milestone Milestone

Task

Task

Task

Task

Task

Task

Task

Task

Task

Task

ProjectTop-Down

Bottom-up

Level terendah WBS adalah level di mana pekerjaan dapat diselesaikan.

Level ini seperti daun pada sebuah representasi pohon, dan dikenal sebagai paket

pekerjaan dan biasanya hasilnya dalam suatu produk pekerjaan yang disetor

(delivered). Paket pekerjaan menggambarkan produk pekerjaan sedemikian sehingga

masing-masing pekerjaan dengan jelas dibedakan dari semua paket pekerjaan yang

lain dalam proyek itu. Mereka pada umumnya dilukiskan sebagai semua informasi

penting bagi seorang yang berkualitas untuk menyelesaikan pekerjaan itu. Untuk

proyek-proyek pengembangan perangkat lunak, ini pada umumnya berhubungan

dengan modul atau object terkecil yang bisa diidentifikasi untuk dibuat dalam suatu

deliverable sistem.

Isi dari suatu paket pekerjaan meliputi:

uraian tentang produk pekerjaan yang diharapkan- elemen perangkat lunak

untuk diproduksi;

kebutuhan terhadap kepegawaian - siapa atau berapa banyak orang-orang

akan melakukan aktivitas ini;

nama dari individu yang bertanggung jawab - siapa yang bertanggung jawab

atas penyelesaiannya;

penjadwalan tanggal mulai dan tgl berakhir - ketika aktivitas diharapkan

untuk mulai dan berakhir;

biaya yang dianggarkan - usaha menaksir aktivitas;

kriteria-kriteria penerimaan pekerjaan – tingkat cacat atau ukuran kualitas

lain.

Jika staff proyek telah mengetahui berbagai hal tersebut, sudah umum

terjadi dalam organisasi di mana kelompok yang sama sama sebagai perekayasa

perangkat lunak bekerja bersama setiap hari, kemudian penulisan suatu paket

pekerjaan yang formal menjadi tidak perlu karena mereka telah mengetahui tugas

tugas yang diperlukan untuk menyelesaikan aktivitas itu. Bagaimanapun,

diperlukan kendali yang lebih untuk mengorganisir suatu kelompok yang belum

pernah sebelumnya bekerja bersama dan tidak memiliki kultur perangkat lunak yang

umumnya dapat menyediakan suatu kerangka, maka menurunkan penulisan

informasi paket pekerjaan menjadi sangat menolong sebab akan memperkecil

kerancuan mengenai tugas mereka. Mungkin juga terjadi bahwa suatu paket

pekerjaan untuk suatu proyek menjadi lingkup pekerjaan untuk suatu sub proyek

24

yang utuh, yang lebih lanjut dibagi menjadi beberapa aktivitas, dikelola sebagai

suatu proyek yang berada jauh di bawah usaha yang lebih besar.

Suatu cara untuk membedakan suatu sub proyek dengan proyek utuh

adalah dengan menjawab pertanyaan apakah sub proyek bisa mandiri pada dirinya

sendiri, tanpa adanya konteks proyek yang lebih besar. Setoran produk pekerjaan

sub proyek mungkin bisa berupa modul perangkat lunak yang mandiri dan

bermanfaat diluar konteks lingkup proyek yang sekarang. Membuat tradisi utilitas

perangkat lunak adalah suatu contoh yang baik dari suatu sub proyek perangkat

lunak. Kebanyakan alat bantu penjadwalan (tool schedulling) manajemen proyek,

seperti Microsoft Project, mengalokasikan suatu tempat untuk mencatat masing-

masing aktivitas dan cara untuk mencetak mereka sebagai lembaran tugas.

II.6 PENGUKURAN BESAR PERANGKAT LUNAK

Memprediksi "ukuran" dari suatu sistem perangkat lunak akan lebih

membantu dan menjadikan proyek lebih mudah. Pengukuran yang dilakukan dalam

mengestimasi ukuran program selayaknya mudah digunakan di awal proyek dan

mudah dibaca ketika pekerjaan sudah selesai. Selanjutnya perbandingan besar

produk estimasi awal dengan pengukuran aktual kemudian digunakan untuk

menyediakan umpan balik ke estimator agar dapat membuat estimasi yang lebih

akurat.

Beberapa unit pengukuran perangkat lunak yang paling banyak digunakan ,

meliputi :

Lines of Code (LOC)

Function point

Jumlah node pada diagram alir data (DAD)

Jumlah entitas pada diagram relasi entitas (ER diagram)

Jumlah kotak proses (PSPEC) atau Kontak kontrol (CSPEC) pada suatu

bagan struktur

Jumlah pernyataan “sebaiknya” versus pernyataan “harus” dalam spesifikasi

kebijakan pemerintah

Jumlah dokumentasi

Jumlah obyek, atribut, dan layanan pada diagram obyek

Ketika perdebatan berlanjut pada pertanyaan apakah model terbaik untuk

pengukuran besar perangkat lunak , maka tidak ada jawaban yang dapat memenuhi

25

semua tujuan. Disatu sisi menghitung jumlah baris dari kode sumber mudah untuk

didefenisikan, dan telah digunakan secara luas juga difasilitasi dengan perhitungan

otomatis. Sayangnya sangat sulit untuk menghubungkan antara baris-baris kode

dengan deskripsi awal kebutuhan fungsional. Untuk menyelesaikan masalah ini

Albrecht merancang suatu metode estimasi yang disebut Functoin point. Di dalam

istilah yang paling sederhana function point dimulai dari perspektif user dan

mengestimasi ukuran aplikasi. Baris-baris kode adalah suatu pengukur produk dan

berhubungan lebih dekat kepada apa yang pengembang perangkat lunak inginkan

untuk dibangun. Keduanya mempunyai keunggulan dan kelemahan, maka sebelum

menjelaskan proses estimasi, dua metode ini akan dijelaskan secara singkat.

II.6.1. Mengestimasi Line of Code (LOC)

LOC mengestimasi secara tipikal dengan menghitung semua instruksi-instruksi

sumber dan mengabaikan komentar dan blank. sebagai contoh sebuah tool otomatis

didesain untuk menghitung semicolon (misal pada pascal satu baris ditandai dengan

semicolon). Bagaimanapun juga sangat sulit untuk memperkirakan baris-baris kode

dari statemen-statemen kebutuhan level tinggi. Pengukuran ini memfasilitasi suatu

proses pembelajaran sehingga meningkatkan estimasi. LOC juga memfasilitasi

penyimpanan dan pengambilan data ukuran yang dibutuhkan untuk meningkatkan

akurasi estimasi. Keunggulan utama dari LOC adalah bahwa LOC berhubungan

secara langsung kepada produk yang dibangun. Dengan demikian pengukuran

dilakukan setelah adanya fakta yang dibandingkan dengan rencana awal.

Ketika dekomposisi WBS telah sampai pada tingkatan terendah, suatu ukuran "

statistik" dapat dibuat melalui suatu pengukuran proses. Ukuran dari tiap

komponen dapat diperoleh dengan menanyakan pada tenaga ahli yang sudah pernah

mengembangkan sistem yang sama, atau dengan meminta pada pengembang sistem

yang berpotensi untuk mengestimasi ukuran dari tiap task pada tingkat terendah dari

WBS itu. Ketika ukuran dijumlahkan, jumlah total disebut sebagai penaksiran

ukuran " bottom-up". Suatu penaksiran yang lebih baik biasanya diperoleh jika

masing-masing penaksir diminta untuk menyediakan dalam suatu bentuk taksiran

terhadap ukuran optimis, pesimistis, dan realistis. Kemudian dapat dibentuk sebuah

distribusi beta dengan mengalikan taksiran ukuran realistis dengan 4, ditambah

ukuran optimis dan pesimistis, dan totalnya dibagi 6. Hasil rata-rata ini adalah suatu

konversi yang tidak dapat dipisahkan dari ketidakpastian penaksiran. Sebagai

contoh, diberikan suatu obyek window yang didekati dengan WBS sistem, kode

26

pendukung yang dibutuhkan untuk proses mengedit window itu diperkirakan antara

200-400 baris kode, dengan nilai keyakinan mendekati 250. Dengan pendekatan

nilai optimis dan pesimistis akan menghasilkan perkiraan hasil akhir sebagai

berikut :

Jumlah baris = nilai optimis + (nilai realistis x 4) + nilai pesimis

6

266 = 200 + (250 x 4) + 400

6

Jumlah seribu baris kode disebut sebagai KLOC (Kilo Lines of Code ).

Menghitung baris kode secara manual akan memakan waktu dan membosankan,

maka kebanyakan organisasi membeli atau membangun suatu peranti penghitung

LOC otomatis. Peranti ini dapat menjawab beberapa masalah yang kompleks

mengenai pertanyaan tentang persisnya apa yang disebut satu baris kode. Lagipula,

tidak jadi soal seperti apa kita menggambarkan LOC, sepanjang definisi tersebut

digunakan secara konsisten. Petunjuk perhitungan berikut ini telah digunakan

selama bertahun-tahun, untuk merekam ukuran program ada dan untuk menaksir

ukuran program yang dikembangkan:

Pastikan bahwa tiap-tiap " baris kode program" yang terhitung berisi

hanya satu statemen program ( jika dua statemen yang executable berada

pada satu baris, yang dipisahkan oleh suatu titik koma, maka dihitung

menjadi dua; jika satu statemen yang executable ada atau tersebar ke dua

/ beberapa baris, maka dihitung satu. Bahasa pemrograman menyediakan

pilihan pengkodean untuk bermacam-maccam keperluan, tetapi biasanya

tetap mudah untuk menentukan satu statemen tunggal yang executable

karena compiler atau interpreter melakukan hal yang sama.

Hitung semua setoran , termasuk statemen statemen yang executable -

pemakai akhir tidak akan secara langsung menggunakan setiap statemen,

tapi suatu produk bisa memerlukannya sebagai pendukungnya (seperti

utilitas)

Menghitung definisi data sekali saja

Jangan menghitung baris yang mengandung komentar

jangan menghitung kode debug atau kode yang bersifat temporer lainnya

seperti perangkat lunak pengujian, kasus uji, peranti bantu

pengembangan, peranti bantu prototipe, dan seterusnya

27

Hitung tiap-tiap defenisi permintaaan, pemanggilan, atau pemasukan

( kadang-kadang disebut compiler directive) dari suatu makro sebagai

bagian dari program yang memakainya ( jangan menghitung statemen

program yang dipakai ulang)

Terjemahkan banyaknya baris dari kode program ke baris bahasa

asembler padanannya sedemikian sehingga mungkin dapat dibuat

perbandingannya terhadap proyek-proyek lain

Kolom pertama dan kedua tabel... memberikan suatu metoda yang digunakan

secara umum untuk menterjemahkan baris kode program / sistem ( SLOC) dalam

berbagai bahasa ke jumlah rata-rata LOC program asembler. (catat bahwa SLOC

dan LOC dapat saling dipertukarkan) Banyak manager proyek yang menginginkan

suatu konversi semua bahasa ke dalam dasar asembler sedemikian sehingga suatu

perbandingan satu sama lain bisa dibuat terhadap proyek-proyek. Fungsi lain dari

data ini adalah untuk suatu proyek dalam suatu bahasa tertentu akan dikonversi ke

bahasa lain. Sebagai contoh, diberikan sautu sistem dengan 50.000 LOC yang ditulis

dalam bahasa Cakan dikonversi ke bahasa C++. Dengan menggunakan tabel 2.2.,

dasar assembler SLOC untuk bahasa C adalah 2,5, maka 50.000 SLOC sistem yang

ditulis dalam bahasa C ekivalen dengan 50.000 x 2,5 = 125.000 SLOC jika ditulis

dalam Basic Assembler. Dari 125.000 SLOC ini jika ditulis dalam bahasa C++

menjadi 125.000/6 = 20.833 SLOC.

Tabel 2.2. Konversi Bahasa Pemrograman ke Baris Kode Program Basic

Assembler per function point

BahasaBasic Assembler SLOC

(Level)

Rerata SLOC per

Function Point

Basic Assembler 1 320

Autocoder 1 320

Macro Assembler 1.5 213

C 2.5 128 – 150

DOS Batch Files 2.5 128

Basic 3 107

LOTUS Macro 3 107

ALGOL 3 105 -106

COBOL 3 105 – 107

28

FORTRAN 3 105 – 106

JOVIAL 3 105 – 107

Mixed Languages(default) 3 105

Pascal 3.5 91

COBOL (ANSI 85) 3.5 91

RPG 4 80

MODULA-2 4.5 80

PL/ I 4.5 80

Concurrent PASCAL 4 80

FORTRAN 95 4.5 71

BASIC (ANSI) 5 64

FORTH 5 64

LISP 5 64

PROLOG 5 64

LOGO 5.5 58

Ext Common LISP 5.75 56

RPG III 5.75 56

C++ 6 53

JAVA 6 53

YACC 6 53

Ada 95 6.5 49

CICS 7 46

SIMULA 7 46

Database Language 8 40

CLIPPER DB dan Dbase III 8 40

INFORMIX 8 40

ORACLE dan SYBASE 8 40

Access 8.5 38

Dbase IV 9 36

FileMaker Pro 9 36

Decision Support Languages 9 35

FOXPRO 2.5 9.5 34

APL 10 32

29

SAS 10 32

DELPHI 11 29

Object-oriented default 11 29

OBJECTIVE-C 12 27

Oracle Developer / 2000 14 23

SMALLTALK 15 21

awk 15 21

EIFFEL 15 21

UNIX shell Script (PERL) 15 21

4th Generation Default 16 20

Aplication Builder 16 20

COBRA 16 20

Crystal Reports 16 20

Datatrieve 16 20

CLIPPER 17 19

SQL 25 13 – 16

HTML 3.0 22 15

IEF / IEW 23 14

EASYTRIEVE+ 25 13

SQL (ANSI) 25 13

EXCELL 50 6

QUATRO PRO 51 6

Graphic Icon Languages 75 4

Salah satu cara untuk menaksir ukuran dari suatu sistem perangkat lunak

yang akan dikembangkan adalah dengan membandingkan kemampuan atau

fungsionalitasnya dengan sistem-sistem yang telah ada. Misalkan kita telah

mempunyai suatu komponen perangkat lunak , katakan modul A, yang harus

dibangun kembali dengan sistem yang baru. A mempunyai besar 2.345 LOC dan

kita yakin modul A yang baru nanti akan lebih efisien ( mungkin karena telah

dipelajari mulai dari awal sampai pemeliharaan A sehingga dapat diketahui

bagaimana membuat kodenya lebih ramping), tetapi karena terdapat beberapa fitur

30

tambahan yang dapat ditambahkan pada modul A itu nanti, maka kemudian modul

A yang baru ini diperkirakan terdiri atas 3000 LOC.

Metode ini tentu saja juga bukan suatu metode yang sangat akurat

mengingat modul A yang baru mungkin saja ditulis dalam bahasa pemrograman

yang berbeda, domain aplikasi yang berbeda, menggunakan algoritma yang berbeda,

level kompleksitas yang berbeda, dengan fungsionalitas yang belum diuji coba, dan

level realitas yang berbeda.

Contoh dengan kasus lain adalah sebagai berikut : diberikan suatu perangkat

lunak yang akan dikonversi dari bahasa COBOL,yang sebelumnya tanpa

menggunakan teknik desain, akan ditulis ke dalam bahasa C++ dengan

menggunakan desain berorientasi obyek. Dari ukuran program akan menurun karena

pada waktu sekarang telah dirancang secara lebih baik, bahkan kemampuan dan

mutunya pun lebih baik, tetapi biaya per baris kode ini naik 10% lebih tinggi.

Apakah ini terlihat sebagai kebocoran produktifitas ? Tentu saja tidak. Ini adalah

suatu peningkatan dalam produktifitas seperti halnya kemampuan dan daya

pemeliharaannya yang juga menjadi lebih baik.

Kelebihan-kelebihan menggunakan baris kode (LOC) ini sebagai unit

pengukuran perangkat lunak meliputi :

LOC ini sudah umum digunakan dan dapat diterima secara universal

LOC ini mengijinkan adanya perbandingan matriks ukuran dan

produktifitas antara kelompok-kelompok pengembangan yang berbeda beda

LOC ini berhubungan secara langsung dengan produk akhir

LOC lebih mudah diukur terhadap penyelesaian proyek

LOC mengukur perangkat lunak dari sudut pandang pengembang - yaitu

apa yang ia kerjakan.

Teknik estimasi ini memungkinkan adanya aktifitas untuk kenaikan

berkelanjutan - ukuran perkiraan dapat dengan mudah dibandingkan

dengan ukuran riil ketika sesudahnya dilakukan analisa terhadap proyek

tadi (seperti bagaimana keakuratan perkiraan, mengapa ia bisa mengubah

sekian persen?, apa yang bisa dipelajari dari sini untuk menilai ukuran

proyek berikutnya?, .. dan seterusnya).

Kelemahan-kelemahan menggunakan baris kode (LOC) adalah sebagai

berikut :

31

LOC kesulitan untuk menaksir perangkat lunak baru diawal tahap siklus

hidup pengembangan

Instruksi program berbeda menurut jenis bahasa pemrograman, metoda-

metoda disain, dan dengan gaya dan kemampuan programmer

Tidak adanya organisasi standarisasi ( seperti ISO) untuk menghitung baris

kode

Perangkat lunak melibatkan banyak biaya-biaya yang mungkin tidak

dipertimbangkan ketika melakukan pengukuran kode untuk menaksir biaya

– terdapat " biaya-biaya tetap" seperti biaya kebutuhan spesifikasi dan

dokumen-dokumen pemakai yag tidak dimasukkan dalam pengkodean.

Pemrogram mungkin akan menerima bayaran lebih untuk jumlah baris

kode yang besar jika pihak manajemen salah tanggap terhadap

produktifitas mereka dan tidak sebaliknya untuk pihak desainer, padahal

kode program bukanlah yang paling esensi dari suatu produk melainkan

pencapaian fungsionalitas dan performansi.

Penghitungan LOC seharusnya membedakan antara kode yang dihasilkan

dengan kode berdasarkan fungsinya - karena ini lebih sulit yaitu

menghitung utilitas, bukan hanya sekedar "menghitung langsung" kode,

yang sebenarnya bisa diperoleh dari daftar kode compiler

LOC tidak dapat digunakan untuk normalisasi jika platform atau bahasa

dibedakan

Hanya ada dua cara untuk memperkirakan jumlah LOC untuk perangkat

lunak baru yang akan dibangun yaitu pertama dengan menganalogikan

kesamaan fungsional dengan produk perangkat lunak yang telah ada dan

kedua dengan opini pakar, keduanya adalah metode yang kurang akurat

Sayangnya, produktifitas sering diukur dengan baris kode yang dihasilkan.

Jika seorang pemrogram bisa meningkatkan dari rata-rata 200 baris kode per bulan

menjadi 250 baris kode perbulan, manajer mengira bahwa produktifitasnya telah

meningkat. Hal ini adalah persepsi yang berbahaya yang sering mengakibatkan

pemrogram tergoda untuk menghasilkan baris kode yang lebih banyak per

desainnya. Tidak hanya pengembang yang menilainya mempunyai produktivitas

yang lebih tinggi, tetapi ia juga dianggap menghasilkan kode yang bersih. Beberapa

organisasi menggunakan rumus ini untuk mengukur mutu:

32

Jumlah cacat / jumlah baris kode

Jika pembagi besar, maka kualitas kelihatannya dibuat tinggi. Pada umumnya tahap

pengkodean mengkonsumsi hanya 7 % dari total usaha dan maksimum sekitar 20 %.

tetapi tentu saja kualitas kode yang terpenting, bukan volume.

II.6.2. Function_Point Sebagai Unit Pengukuran

Metode Function Point ( FP) didasarkan pada gagasan di mana ukuran

perangkat lunak akan lebih baik diukur dalam kaitannya terhadap jumlah dan

kompleksitas fungsi yang dikerjakannya dibanding dengan banyaknya baris dari

kode yang merepresentasikannya. Function point pertama kali dikenalkan oleh A.J.

Albrecht dari IBM yang ditulis di akhir 1970, untuk sistem yang berorientasi

transaksi. Capers Jones suatu korporasi dibidang Riset produktifitas perangkat

lunak, mengembangkan gagasan Albrecht ke suatu badan pengetahuan nasional.

Pada tahun 1986, suatu kelompok non profit, yang disebut The International

Function Point User Group (IFPUG) dibentuk untuk mengelola informasi

matriksnya. Tahun 1987, pemerintah Inggris mengadopsi function point yang

dimodifikasi sebagai matriks baku untuk produktivitas perangkat lunak. Kemudian

tahun 1994, dikenalkan Latihan Manual Penghitungan Function Point versi 4.0

(Function Point Counting Practices Manual Release 4.0) Standar IFPUG dan dirilis

Petunjuk Pengukuran Perangkat lunak versi 1.0 (Guidelines to Software

Measurement Release 1.0 ) Standard IFPUG.

Prinsip Function point :

Melengkapi unit standar dari pengukuran

Berdasarkan pada pandangan eksternal pemakai terhadap sistem

Pengukuran kerja produktif bersama dengan pengukuran usaha kerja

akan menghasilkan pengukuran produktifitas

Model estimasi yang mendasarkan pengukuran function-point untuk

produktifitas

Tujuannya adalah membangun pengukuran relatif dari nilai fungsi

hasil yang akan diserahkan, terlepas dari teknologi atau pendekatan

yang digunakan

Secara umum pendekatan dilakukan berdasar perhitungan (bobot

yang merefleksikan nilai tipe fungsi ) dari :

33

External input (data screen, ligt-pen, switch, transaksi dari

aplikasi lain)

External output (screen report, terminal report, screen

message, transaksi untuk aplikasi lain)

Logical internal file (Data base, user table, message table,

logical internal table)

File atau struktur data

External interface file (share data base, logical internal file

yang dapat diakses dari / ke aplikasi lain)

External inquiry (user inquiry tanpa update file, help

message and screen, pemilihan menu screen)

Langkah-langkah :

Kumpulkan dokumen dari sudut pandang user

Klasifikasikan ke dalam 5 tipe fungsi

Siapkan lembar kerja untuk masing-masing fungsi

Gunakan faktor pembobotan untuk setiap fungsi

Jumlahkan ke dalam function Count (FC)

Gunakan nilai dari 0-5 untuk masing-masing dari 14 karakteristik (N)

Jumlahkan ke dalam Processing Complexity (CF)

Hitung AFP = FP x CF

Konversikan ke LOC

Petunjuk Menghitung Function Point

Gambar 2.5. menunjukkan langkah-langkah dasar dalam menghitung

function point (FP) yang akan dijelaskan lebih lanjut. Tabel 2.3 menunjukkan input,

transformasi, dan output untuk tiap-tiap langkah dalam menghitung FP

Langkah 1. Hitung Jumlah fungsi untuk tiap kategori

Petunjuk Umum untuk Menghitung:

Hitung fungsi kebutuhan perangkat lunak saja

Hitung representasi logika, dimana beberapa input, output dan seterusnya

yang memerlukan logika pemrosesan yang berbeda, masing-masng

direpresentasikan sebagai function point yang unik.

34

Hitung jumlah fungsi untuk tiap kategori

Terapkan faktor pembobotan kompleksitas

Terapkan faktior lingkungan

Kalkulasi faktor kompleksitas

Hitung function point

Konversi ke baris kode

Gambar 2.5. Langkah-langkah Dasar dalam Analisis Function Point

Menghitung Output

Daftar berikut meliputi "tanda" untuk diingat ketika menghitung keluaran:

keluaran yang eksternal adalah berbagai hal diproduksi oleh perangkat lunak

yang pergi [bagi/kepada] bagian luar dari sistem

Output adalah unit informasi yang dihasilkan oleh perangkat lunak untuk

pemakai.

Contohnya meliputi: data screen, data report, pesan kesalahan, dst.

Tabel 2.3 Lembar worksheet Analisis FP

Langkah 1. Menghitung Jumlah Fungsi dalam tiap-tiap kategori

Langkah 2. Menerapkan faktor pembobotan kompleksitas

Sederhana Menengah Kompleks Function Point

Jumlah Output ____ x 4 ____ x 5 ____ x 7

Jumlah Input ____ x 3 ____ x 4 ____ x 6

35

Jumlah Inquiry Output ____ x 4 ____ x 5 ____ x 7

Jumlah Inquiry Input ____ x 3 ____ x 4 ____ x 6

Jumlah File ____ x 7 ____ x 10 ____ x 15

Jumlah Interface ____ x 5 ____ x 7 ____ x 10

Total FP :

Langkah 3. Menerapkan Faktor Lingkungan

Faktor Lingkungan Rating (0,1,2,3,4,5)

Komunikasi Data

Pemrosesan terdistribusi

Kebutuhan Performansi

Batasan Konfigurasi

Rating Transaksi

Online Inquiry dan / atau Entry

Efisiensi pemakai akhir

Online update

Pemrosesan Kompleks

Reusability

Kemudahan konversi / Install

Kemudahan Operasi

Digunakan dibeberapa site

Potensial terhadap perubahan fungsi

Total(N) :

Langkah 4. Kalkulasi Faktor Kompleksitas (CF)

CF = 0.65 + (0.01 x N) =

Langkah 5. Menghitung Kesesuaian Function Point (AFP)

AFP = FP x CF

Langkah 6. Konversi ke LOC (Optional)

LOC = AFP x LOC/AFP

Hitung tiap-tiap unit output unik sebagai keluaran aplikasi, suatu unit output

unik adalah jika ia memiliki format berbeda atau logika pemrosesan yang

berbeda

36

Masing-masing output ditambahkan ke salah satu dari tiga kategori, tergantung pada

kompleksitasnya: suatu output kompleks akan membutuhkan usaha lebih untuk

membuatnya dibanding output menengah ataupun yang sederhana. Bilangan yang

diapit tanda “()” menunjukkan bobot pengali. Petunjuk untuk menentukan

kompleksitas ditemukan di tabel 2.4.

Tabel 2.4 Faktor Pembobotan Output pada analisis Function Point

Merujuk 1-5 Data Merujuk 6-19

Data

Merujuk lebih dari

20 data

Merujuk 0 – 1 File Sederhana (4) Sederhana (4) Menengah (5)

Merujuk 2 atau 3 File Sederhana (4) Menengah (5) Kompleks (7)

Merujuk 4 atau lebih

File

Menengah (5) Kompleks (7) Kompleks(7)

Menghitung Input

Ingat Berikut ini ketika menghitung input :

Input eksternal adalah sesuatu yang diterima oleh perangkat lunak dari luar

sistem

Input adalah unit informasi yang diberikan pemakai pada perangkat lunak

untuk diproses atau disimpan

Hitung masing–masing unit input yang unik.

Sebagaimana output, input dibagi dalam kategori sederhana, menengah dan

kompleks untuk pembobotan. Petunjuk untuk menentukan kompleksitas diberikan

pada tabel 2.5.

Tabel 2.5. Faktor Pembobotan Analisa Input pada Function Point


Data

Merujuk lebih dari

20 data


37



File


Menghitung Inquiry (Output/Input)

Ketika menghitung inquiries , ingat hal-hal berikut :

Eksternal inquiry adalah instruksi khusus atau permintaan agar perangkat

lunak merespon, membentuk, atau menurunkan sesuatu akibat masukan yang

diberikan.

Inquiry mengakses langsung ke database yang menerima data spesifik,

menggunakan kunci, dan membentuk fungsi-fungsi yang tidk mengubah

data.

Hitung tiap-tiap unit inquiry unik. Suatu inquiry dianggap unik jika

memenuhi salah satu berikut :

- Memiliki format yang berbeda dari yang lain baik input maupun

outputnya

- Memiliki format yang sama, baik input maupun output, dengan

inquiry lainnya tapi salah satu memiliki logika pemrosesan yang

berbeda

Inquiry dengan input dan output yang berbeda akan memiliki faktor bobot

kompleksitas yang berbeda

Query bukan suatu inquiry. Query biasanya diklasifikasikan sebagai salah

satu input atau otput karena ia sering menggunakan beberapa kunci dan

melibatkan operasi atau kalkulasi pada data

Inquiry dikelompokkan ke dalam kelompok : sederhana, menengah, dan

kompleks. Petunjuk untuk menentukan kompleksitasnya ditunjukkan oleh tabel

2.6.

Tabel 2.6. Faktor Pembobotan Analissi Inquiry Pada Function Point

Bagian Output (Catatan:

Pilih Nilai Tertinggi :


Data

Merujuk lebih dari

20 data

38

Output atau Input




File


Bagian Input (Catatan:

Pilih Nilai Tertinggi :

Output atau Input)


Data

Merujuk lebih dari

20 data




File


Meghitung Struktur Data (File)

Hal-hal yang harus diingat ketika menghitung struktur data / File meliputi :

File internal adalah File yang secara logik berada dalam program

Struktur data dikenal sebagai “file” adalah kelompok data user utama yang

secara permanen disimpan dalam lingkungan sisitem perangkat lunak

Struktur data dijangkau pemakai melalui input, output, inquiry, atau interface

Struktur data dibagi kedalam : sederhana, menengah, dan kompleks. Petunjuk untuk

menentukan kompleksitas ditunjukkan dalam tabel 2.7.

Menghitung Interface

Ketika menghitung interface, beberapa hal yang harus diingat adalah :

File eksternal adalah file turunan mesin yang digunakan program

Interface adalah data (dan kontrol) yang disimpan diluar lingkungan

perangkat lunak sistem yang dievaluasi

Struktur data bersama diantara sistem-sistem dihitung sebagai interface dan

juga struktur data

39

Hitung tiap-tiap data dan aliran kontrol menurut arahnya sebagai interface

unik

Tabel 2.7. Faktor Pembobotan Analisis File Pada Function Point

Catatan: Hitung Relasi

secara logik bukan tipe

record secara fisik

Merujuk 1-19

Item Data

Merujuk 20-50

Item Data

Merujuk lebih dari

50 Item Data

Relasi / Format 1 record

lojik

Sederhana (7) Sederhana (7) Menengah (10)

Relasi / Format 2-5 record

lojik

Sederhana (7) Menengah

(10)

Kompleks (15)

6 atau lebih record lojik Menengah (10) Kompleks (15) Kompleks(15)

Interface dibagi ke dalam sederhana, menengah dan kompleks. Petunjuk untuk

menentukan kompleksitas ditunjuk dalam tabel 2.8.

Tabel 2.8. Faktor Pembobotan Analisis Interface Pada Function Point

Catatan: Jumlah Relasi

secara logik bukan tipe

record secara fisik

Merujuk 1-19

Item Data

Merujuk 20-50

Item Data

Merujuk lebih dari

50 Item Data

Relasi / Format 1 record

lojik

Sederhana (5) Sederhana (5) Menengah (7)

Relasi / Format 2-5 record

lojik

Sederhana (5) Menengah (7) Kompleks (10)

6 atau lebih record lojik Menengah (7) Kompleks (10) Kompleks(10)

Langkah 2. Terapkan Faktor Pembobotan Kompleksitas

kalikan masing-masing jumlah masing-masing kategori (sederhana,

menengah, kompleks) dalam tiap kategori (output, input,

40

inquiry[output/input], struktur data[file], interface) dengan faktor penimbang

yang sesuai

Jumlahkan total dari tiap kategori. Ketika langkah 1 dan langkah 2

dilaksanakan maka hasilnya akan terlihat seperti tabel 2.11.

Ingat hasil total ini dalam jumlah function point murni.

Langkah 3. Terapkan Faktor Lingkungan

lakukan penyesuaian jumlah function point murni terhadap faktor lingkungan yang

mempengaruhi proses pengembangan perangkat lunak. Beberapa aspek lingkungan

mungkin akan mempengaruhi proses pengembangan perangkat lunak. Beberapa

aspek ini mempengaruhi proyek secara positif, dan disisi lain menimbulkan

pengaruh negatif.

Tabel 2.9 memuat suatu defenisi detil terhadap 14 faktor lingkungan.

Menggunakan tabel 2.9, setiap faktor diberi skala 0 sampai 5 (0 berarti tidak dapat

diaplikasikan). Untuk membantu menaksir batas spektrum, tabel 2.10. berisi contoh-

contoh sistem perangkat lunak yang akan dinilai tinggi - dengan skala 4 atau 5.

Jumlahkan rating factor (Fn) untuk mengkalkulasi total Faktor Pengaruh

Lingkungan (N) :

N = sum (Fn)

Gunakan Tabel Function point dalam Tabel 2.3. untuk merekam nilai. Rujuk tabel

2.11. untuk melihat bagaimana hasilnya setelah langkah 3 dilakukan.

Tabel 2.9. Deskripsi Analisis Faktor Lingkungan pada Function Point

Faktor lingkungan Rating (0,1,2,3,4,5)

Komunikasi data Informasi data atau kendali dikirim atai diterima

melalui fasilitas komunikasi data. Sistem online

dipengaruhi oleh komunikas data.

Pemrosesan Terdistribusi Aplikasi menggunakan data yang disimpan, diakses

atau diproses pada suatu storage lain atau memproses

sistem lain selain dari sistem yang digunakan pada

sistem utama tersebut.

Kebutuhan Performansi permintaan user yang telah disetujui dibuat dengan

throughput luar biasa tinggi atau memiliki respon

41

waktu yang cepat

Batasan Konfigurasi Aplikasi akan dijalankan pada konfigurasi yang

ketat,berat atau padat

Rating Transaksi Trafik jaringan tinggi, layar penuh dengan informasi

dan grafik, frekuensi transmisi layar tinggi

Online Inquiry dan/ atau

Entry

Terlalu Interaktif

Efisiensi pemakai akhir Pertimbangan faktor manusia perlu ditambahkan

Online Update Update database dinamis, database terdistribusi

Pemrosesan kompleks keamanan yang tinggi, proses transaksi yang berat,

algoritma yang kompleks, interupsi logika kendali

Reusability Kode yang didesain untuk dapat dipakai ulang harus

berkualitas tinggi

Kemudahan Konversi /

install

Konversi dan instalasi memerlukan dokumen

perencanaan yang telah diuji

Kemudahan operasi Efektif tetapi tetap mudah untuk melakukan prosedur

start, backup, error recovery dan shutdown. Aktifitas

manual dibuat minimal

Digunakan dibeberapa site Account meliputi fungsi bisnis yang berbeda-beda

Potensial terhadap

perubahan fungsi

Bersifat modular, table-driven, user-maintened,

kapabilitas query fleksibel, dan seterusnya

Langkah 4. Kalkulasi Faktor

II.7 ESTIMASI

Karakteristik Estimasi

Estimasi didasarkan pada model probabilitas, bukan deterministic

Estimasi pada suatu angka dalam suatu selang dari suatu kuantitas yang

diestimasi

Kepercayaan pada estimasi tergantung pada ukuran selang dari kuantitas

yang diestimasi

Kepercayaan pada estimasi tergantung pada ukuran selang dari kuantitas

yang diukur

Informasi yang cukup banyak (sebagai dasar estimasi) akan memperkecil

selang dan memperbesar kepercayaan

42

Informasi yang sangat relevan yang dipakai sebagai dasar estimasi adalah

dalam selang yang kecil

Beberapa kemungkinan penyebab lemahnya estimasi

Kita tidak mengembangkan kepakaran estimasi

Kita tidak membuat cukup syarat untuk menggantikan akibat dari bias

Kita tidak memiliki cukup pengertian dari apa yang seharusnya diestimasi

Kita tidak mendasarkan estimasi pada ukuran performansi waktu yang lalu

Pemodelan Estimasi Empiris dengan COCOMO (Constructive Cost Model)

Pada perencanaan pengembangan perangkat lunak diperlukan suatu model

perhitungan ( estimation model) dengan menggunakan rumusan-rumusan yang

diturunkan secara empiris untuk memprediksi data-data yang diperlukan pada setiap

tahapannya.

Model sumber terdiri dari paling sedikit satu persamaan empiris untuk

berusaha memprediksi berbagai hal misalnya :

Kemajuan proses pengembangan (dalam satuan orang – bulan)

Lamanya proyek

Ukuran staf

Jumlah baris kode program

Selanjutnya Basili membagi kelas-kelas model sumber ke dalam empat jenis

model yaitu :

Model static single-variable

Model static multivariable

Model dynamic multivariable

Model theoritical

Pada diktat ini hanya akan dibahas rumusan model Model static single-variable dan

model static multivariable.

Model static single-variable mengambil bentuk :

Resource = c1 . (karakteristik perhitungan)c2

43

Dimana :

Resource bisa berupa kemajuan yang dicapai, lamanya proyek, ukuran staf,

jumlah baris kode program

C1 dan c2 adalah konstanta yang diambil dari kumpulan data yang terkoleksi

dari proyek sebelumnya

Karakteristik perhitungan yang bisa berupa jumlah baris kode sumber,

kemajuan pengembangan dan karakteristik perangkat lunak lainnya

Model static multivariable seperti model sebelumnya mengambil bentuk data

historis ke dalam persamaan :

Resource = c11.e1 + c21.e2 + …

Dimana :

ei adalah karakteristik perangkat lunak yang ke i

ci1, ci2 adalah konstanta yang secara empiris diturunkan dari karakteristik ke i

resource bisa berupa kemajuan yang dicapai, lamanya proyek, ukuran staf,

jumlah baris kode program

Cocomo dikemukakan oleh Barry Boehm dan merupakan model perhitungan

perangkat lunak secara hirarkis yang mengambil bentuk antara lain :

Model 1 : BASIC COCOMO

Adalah model static single valued yang menghitung kemajuan dan biaya

pengembangan perangkat lunak sebagai fungsi dari ukuran program yang

dalam hal ini dinyatakan dalam perhitungan jumlah baris kode program

Model 2 : INTERMEDIATE COCOMO

Model ini menghitung kemajuan pengembangan perangkat lunak sebagai

fungsi dari ukuran program dan kumpulan komponen biaya lainnya yang

termasuk penilaian subyektif dari produk, perangkat keras, personil dan

komponen proyek lainnya.

Model 3 : ADVANCE COCOMO

Model ini menggabungkan semua karakteristik dari versi Intermediate

Cocomo dengan tambahan penilaian dari komponen biaya yang berpengaruh pada

tiap tahapan dari pengembangan perangkat lunak (analisis, desain, pengkodean,

implementasi dan pemeliharaan).

Cocomo dapat diaplikasikan ke dalam 3 kelas dari proyek pengembangan

perangkat lunak diantaranya :

44

Mode Organic

Mode ini diterapkan pada kelas proyek untuk pengembangan perangkat lunak

yang sederhana dan tidak terlalu besar. Tim pengembang bisa berupa tim kecil

yang biasa bekerja sama dan telah berpengalaman dalam pengembangan

aplikasi. Kebutuhan perangkat lunak yang dikembangkan biasanya bersifat

fleksibel.

Mode Semi-Detached

Mode ini diterapkan pada kelas proyek yang agak kompleks dan melibatkan

personil dalam tim yang agak besar. Personil bisa berasal dari berbagai

bidangn dan tingkatan pengalaman yang bervariasi. Dengan demikian tingkat

pemenuhan kebutuhan yang beragam pula.

Mode Embedded

Mode ini diterapkan pada kelas proyek yang rumit. Dalam mode ini terdapat

hubungan yang sangat kuat antara perangkat lunak, perangkat keras dan

batasan operasi yang harus dipenuhi sistem, seperti dalam pengembangan

perangkat lunak pengatur lalu lintas pesawat udara

Persamaan untuk model BASIC COCOMO adalah :

E = ab (KLOC)exp(bb)

D = cb (E) exp (db)

Dimana:

E merupakan satuan usaha dalam orang- bulan

D merupakan waktu pengembangan dalam bulan yang berurutan

KLOC perkiraan jumlah baris kode program (dalam ribuan)

ab, cb, bb, db adalah koefisien seperti yang diberikan pada table berikut :

Proyek PL ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Selanjutnya model ini dapat dikembangkan dengan mempertimbangkan

kumpulan sifat-sifat penggerak komponen biaya yang dapat dikelompokkan ke

dalam 4 kategori umum yaitu :

45

1. Sifat produk

Kehandalan dari perangkat lunak yang dibutuhkan

Ukuran dari aplikasi database

Kompleksitas dari produk

2. Sifat Perangkat lunak

Batasan performansi pada saat run-time

Batasan memori

Keseimbangan dari lingkungan virtual machine

Waktu perubahan yang diperlukan

3. Sifat personil

Kemampuan analisis

Kemampuan perekayasa perangkat lunak

pengalaman dalam pengembangan aplikasi

pengalaman terhadap virtual machine

pengalaman terhadap bahasa pemrograman

3. Sifat proyek

penggunaan perangkat lunak pembantu

penerapan dari metoda-metoda dalam rekayasa perangkat lunak

jadwal pengembangan yang diperlukan

Tiap sifat ini berharga dari yang paling kecil sampai paling besar pada skala 6.

Kemudian nilai ini dikalikan dengan factor pengali yang didapat dari table Boehm.

Hasil penjumlahan keseluruhan merupakan nilai effort adjusment factor (EAF) yang

biasanya berkisar dari 0,9 sampai 1,4

Persamaan untuk model Intermediate Cocomo adalah :

E = ai (LOC) exp (bi). EAF

Dimana :

E merupakan satuan usaha dalam orang-bulan

LOC perkiraan jumlah baris kode program

ai, bi adalah koefisien seperti yang diberikan pada table berikut ;

46

Proyek PERANGKAT

LUNAK

ai bi

Organic 3.2 1.05

Semidetached 3.0 1.12

Embedded 2.8 1.20

Contoh aplikasi BASIC COCOMO

Sebuah perusahaan perdagangan membuat aplikasi bisnis untuk mendukung

penyediaan informasi yang diperlukan. Pada tahap pengembangannya melibatkan

seluruh bagian yang terlibat dalam hal perumusan sistem yang tepat, seperti bagian

keuangan, penjualan, pembelian, gudang, pembukuan, akutansi dan bagian EDP.

Aplikasi dibagi ke dalam 7 modul besar yaitu :

modul pembelian

modul penjualan

modul general ledger

modul account receivable

modul account payable

modul pemeliharaan data stok

modul utilitas

pada akhir proses pengkodean didapatkan distribusi ukuran baris kode program

sesuai dengan modul-modul yang ada sebagai berikut :

Modul Jumlah baris kode program (LOC)

modul pembelian 31500

modul penjualan 32250

modul general ledger 17600

modul account receivable 18050

modul account payable 19600

modul pemeliharaan data stok 25000

modul utilitas 12000

TOTAL 156000

Dari table di atas diketahui jumlah baris program daro keseluruhan modul adalah

156.000 baris.

47

Penentuan penggunaan model estimasi dilakukan sebagai berikut :

Pemilihan model BASIC COCOMO dilakukan karena dasar perhitungan

hanya didasarkan pada ukuran program yang dalam hal ini jumlah baris kode

program

Pemilihan model semi-detached dari model BASIC COCOMO adalah karena

pengembangan aplikasi ini melibatkan personil yang agak besar dan dari

berbagai bidang dan keahlian yang berbeda

Selanjutnya perhitungan dilakukan terhadap komponen-komponen:

usaha pengembangan dalam satuan orang-bulan

E = ai (LOC) exp (bi). EAF

= 3.0 (156)1.12

858 orang-bulan

jangka waktu proyek yang diperlukan dalam satuan bulan ditentukan

dengan :

D = 2.5 (E) exp (0.35)

= 2.5 (858)

26 bulan

jumlah personil yang diperlukan dalam satuan orang ditentukan dengan :

N = E/D

= 858 / 26

= 33 orang

II.7 PENJADWALAN

Ada beberapa teknik penjadwalan yang dapat digunakan yaitu :

Gantt Chart

Diagram Milestone

Metoda Jaringan Kerja

Kurva S

Gantt Chart

Dikembangkan sekitar tahun 1900 oleh Henry Gantt

Saat ini digunakan secara luas

Berisi kumpulan garis / bar horizontal yang dibuat berskala waktu

48

Setiap bar merepresentasikan aktifitas

Awal dan akhir garis menunjukkan jadwal mulai dan selesai

Terdapat beberapa variasi saat ini, untuk membedakan digunakan warna

Kelebihan dan kekurangan Gantt Chart :

Kelebihan Kekurangan

Efektif untuk komunikasi Tidak menunjukkan interdependensi

Mudah dibuat Tidak menguji dampak perubahan suatu

aktifitas

Ringkas Sulit dimodifikasi

Grafikal Sulit untuk memelihara proyek yang besar /

compels

Dapat menjadi sangat rumit, sulit

diinterpretasi / dibaca

Contoh :

49

aktifitas

A

Waktu (minggu)

B

C

D

E

0 1 2 3 4 5 6

…

direncanakan

aktual

Diagram Milestone

Patok-patok kejadian (events) penting pada suatu proyek yang waktunya

sudah ditetapkan dari awal

Dibuat pada bar chart, sehingga diketahui hubungan antara aktifitas

Diperiksa dan disetujui oleh pelanggan

Menunjukkan interface kejadian antara langkah langkah pada SDLC

(software Development Life Circle)

Sangat berguna untuk awal menuju penggunaan metoda jaringan kerja

Kelebihan dan kekurangan :

Kelebihan Kekurangan

Mudah dibuat Tidak menunjukkan interdepedensi

Ringkas Tidak mencukupi untuk menelusuri

kemajauan kerja

Grafikal

Contoh :

50

waktu

Milestone

UR D I T UR - User RequirementD - DesignI - ImplementationT - Testing

Metoda Jaringan Kerja

Fokus pada interdependensi aktifitas

Menampilkan proyek sebagai jaringan kerja dari beberapa aktifitas

Bila ditinjau cara merepresentasikan kegiatannya, ada 2 jenis :

Activity on arrow (AOA)

Kegiatan dinyatakan dalam bentuk panah, yang berhubungan

satu dengan lainnya melalui titik simpul (node) event

Kegiatan sebagai elemen utama yang diberi perhatian

Activity on node (AON)

Kegiatan dinyatakan dalam titik simpul,keterkaitan antara

kegiatan dinyatakan dalam panah

Ada 3 fokus utama : aktiftas

Kejadian

Aktifitas semu (dummy)

Aktifitas :

Kumpulan gerakan atau rangkaian kerja proyek dari satu titik ke titik lainnya

dalam suatu waktu

Lambang

Kejadian :

Kondisi tertentu yang terjadi pada saat tertentu atau suatu penyelesaian dari

sutau kumpulan aktifitas. Awal dan akhir aktifitas dinyatakan oleh suatu

kejadian.

Lambang

Aktifitas semu (dummy) :

Aktifitas yang tidak ada kerja riil yang diwakilinya (zero time activity)

digunakan karena adanya ketergantungan logis dari suatu jaringan kerja

Bila ditinjau dari cara pendekatannya , ada 2 tipe :

CPM (Critical Path Method)

PERT (Program Evaluation and Review Technique )

Perbandingan antara CPM dan PERT :

CPM (Du Pont) PERT (Boez &Hamilton)

51

Beroroientasi ke depan untuk proyek

yang terdefenisi baik (biasanya industri

konstruksi)

Berorientasi ke depan tetapi dengan

pendefenisisan yang tidak pasti

(biasanya proyek (R&D))

Berkaitan dengan biaya dan waktu Berkaitan dengan 3 waktu estimasi : T0,

Tp, Tm

Mengutamakan biaya sebagai obyek

yang dianalisis (biaya percepatan

minimum)

Parameter utama waktu penyelesaian

pekerjaan

Istilah :

TE : Earliest Time of Occurrence (waktu paling awal peristiwa boleh terjadi)

TL : Latest time of occurrence (waktu paling akhir peristiwa boleh terjadi)

ES : Earliest start (waktu paling awal kegiatan)

EF : Earliest finish (waktu selesai paling awal suatu kegiatan)

LS : Latest start (waktu paling akhir kegiatan boleh diawali)

LF : Latest finish (waktu paling akhir kegiatan boleh selesai)

D : duration

Hitungan maju :

EFij = ESij + Dij

Hitungan mundur :

LSij = LFij - Dij

Sifat jalur kritis :

Pada pelaksanaan awal ES =LS=0

Pada pelaksanaan terakhir LF=EF

Total float TF = 0, TF = Lj – Ei - Dij

Contoh :

Suatu proyek dipecah ( memiliki WBS) menjadi aktifitas-aktifitas sebagai berikut :

Aktifitas Aktifitas pendahulu waktu

52

A - 10

B - 8

C - 12

D A 22

E B 27

F B 7

G B,C 15

H D,E 8

I F 20

J D,E,G 15

Maka kegiatan kegiatan ini dapat digambarkan dalam jaringan kerja sebagai berikut:

Latihan :

Diberikan kegiatan-kegiatan sebagai berikut :

Aktifitas Prasyarat waktu

A - 3

B A 4

C - 4

D B,C 8

E B,C 5

F E 3

G D 2

H G,F 2

I H 2

53

10

03

8

8

412

20

615

30

735

35

150

50

535

352

10

13

B

A

C

D

E

F

G

H

I

J

10

8

12

22

27

7

15

8

20

15

D1

D2

J I 3

Diitanya:

1. Buat diagram jaringan kerja (CPM)?

2. Hitung nilai EF, LS, dan Jalur kritis?

54

Kurva S

Grafik yang disusun untuk menunjukkan hubungan antara nilai kumulatif

biaya / jam- orang / prosentase penyelesaian pekerjaan terhadap waktu

Langkah pembuatan kurva S

1. buat bar chart (jadwal pelaksanaan)

2. alokasikan anggaran yang disediakan untuk setiap kegiatan pada

setiap periodenya

3. hitung prosentase penyerapan dana untuk setiap periode

4. hitung prosentase kumulatif penyerapan dana / periode

5. gambarkan dalam sumbu kartesian antara prosentasi kumulatif

dengan waktu (periodenya)

55

percepatan

keterlambatan

waktu

% kumulatif penyerapan dana

: rencana

: aktual

Contoh :

1. Bar Chart

Kegiatan Pendahulu waktu (bln) anggaran(Rp Juta)

A - 3 5

B - 6 5

C A,B 6 60

D C 3 10

E C 1,5 20

2. Alokasi anggaran

D1

D2

3. Prosentasi kumulatif penyerapan dana

Kegiatan Periode (3 bulan) anggaran (Rp. Juta)

1 2 3 4 5

A 5 5

B 3 2 5

C 30 30 60

D 10 10

E 20 20

Kebutuhan

Per periode 8 2 30 30 30 100

% penyerapan

perperiode 8(8/100) 2 30 30 30

% kumulatif

penyerapan 8 10 40 70 100

56

B(6)

A(3) C(6) D(3)

E(1,5)

bab 2 an baru1

Documents