.MATERI Pengelolaan Proyek Sis - Informasi

Pengelolaan Proyek Sistem Informasi
BAB 1
TERMINOLOGI
° Project Management : Aplikasi pengetahuan, keahlian, alat

bantu dan teknik untuk mengelola aktivitas proyek dalam
menghadapi kebutuhan dasar stakeholders - client dan
memprediksi berbagai hal yang berkaitan dengan proyek.
° Project Manager : Individu yang menjaga jalannya
manajemen proyek dan semua sumber dayanya (biaya, staff,
waktu, kualitas)
° Project :
° kumpulan aktifitas yang jika dikerjakan secara
berkesinambungan akan dapat mencapai sukses secara
keseluruhan.
° Sesuatu hal yang biasa diminta oleh client
° Dibuat untuk memperbaiki suatu masalah dan atau
sesuatu yang baru yang berbeda
° Harus unik dari proyek-proyek yang lain.
Yang menentukan keberhasilan atau kegagalan Proyek, meliputi

dua hal :
1. Keterbatasan lingkup proyek
2. Fase proyek
BAB 1 1
1. Keterbatasan Lingkup Proyek (Project Contraint) : Sesuatu

yang secara potensial membatasi proses-proses dalam proyek, yang
meliputi 3 hal :
¾ Time : waktu yang dibutuhkan dalam menyelesaikan proyek.
Ada beberapa even yang ‘memaksa’ dalam Timeline proyek,
yaitu opportunity (kesempatan), limitations (Keterbatasan),
competition (kompetensi).
¾ Cost : Semua biaya yang dibutuhkan dalam proyek. Semua
sumber daya yang dibutuhkan untuk menyelesaikan proyek
tergantung pada biaya, pentingnya manajer proyek disini
adalah melakukan estimasi. Setelah itu adalah memonitor
semua limitasi ini, supaya proyek ’aman’
¾ Quality : Semua hal yang dikerjakan dalam proyek harus
menghasilkan sistem pada waktu dan dalam budget yang
ditentukan namun tetap dalam kualitas terbaik yang dapat
dicapai.
2. Fase Proyek (Project Phase) :

1. Persiapan (Initiating) – mengenali kebutuhan yang
berhubungan dengan proyek untuk menangani masalah-
masalah.
2. Perencanaan (Planning) – ketika mendefinisikan rencana yang
akan digunakan untuk menyelesaikan tujuan akhir
(requirements gathering).
BAB 1 2
3. Pelaksanaan (Executing) – Mengkoordinasi staff dan

sumberdaya penting lainnya, seperti yang sudah ditetapkan
dalam perencanaan.
4. Pengawasan (Controlling) – Monitoring secara konstan
terhadap overall progress dalam proyek dan menjaga integritas
tujuannya.
5. Sosialiasasi (Close Out) – Formalisasi penerimaan kesuksesan
suatu proyek dari stakeholders (client).
Keberhasilan Dokumentasi
Suatu = fase proyek
proyek yang baik
Dokumentasi
° Dokumen Konsep proyek (Project Concept Document) –
ikhtisar dari apa yang diucapkan client pada meeting
pendahuluan (preliminary meetings)
° Dokumen Kebutuhan Proyek (Project Requirement Document)
– hasil dari analisa kebutuhan.
° Dokumen Persetujuan / Validasi (Project Charter) – dokumen
yang berisi pengesahan manajemen dari client (acknowledges),
bahwa proyek diizinkan untuk mengalokasikan sumberdaya.
° Dokumen lingkup proyek (Project Scope Document ) –
kandungan proyek (yang berhubungan dengan proyek seperti :
project members, project sponsor, dsb).
BAB 1 3
° Dokumen Perencanaan Proyek (Project Plan) – detil yang

menunjukkan strategi untuk dapat menyelesaikan proyek.
Outline-nya bisa berupa tahapan-tahapan fase dan langkah
demi langkah kerja.
° Dokumen sosialisasi (Closing Document) – metode sosialisasi,
training, serah terima dengan stakeholders dan komitmen akhir
seperti garansi dsb.
TUJUH FASE PROYEK SOFTWARE

Ada 7 fase dari proyek software, yaitu :
1. DEFINITION
2. ANALYSIS
3. DESIGN
4. PROGRAMMING
5. SYSTEM TEST
6. ACCEPTANCE
7. OPERATION
Proyek software sama dengan membangun sebuah rumah

DEFINITION DEFINISIKAN RUMAH YANG AKAN DIBANGUN
ANALYISIS SPESIFIKASI RUMAH
DESIGN ARSITEK
PROGRAMMING KONSTRUKSI RUMAH
SYSTEM TEST BASEMENT, LANTAI 1, 2, ….
ACCEPTANCE RUMAH SUDAH SELESAI
OPERATION RUMAH SUDAH DAPAT DITEMPATI
BAB 1 4
BAB 2
FASE DEFINISI
Memahami Masalah User
2.1. PENDAHULUAN
Tujuan dari fase definisi adalah untuk memahami dengan baik

masalah-masalah yang dihadapi oleh user dalam memperkirakan
biaya dan waktu penyelesaian proyek.
Ada 3 aktifitas utama yang harus dilakukan dalam Fase Definisi :

Pertama
Anda harus memahami dengan baik masalah-masalah yang
dihadapi oleh user dan apa saja yang dibutuhkan untuk
menyelesaikan masalah tersebut (KEBUTUHAN).
Kedua
Anda harus memutuskan proyek akan dilaksanakan atau tidak.
Jika keputusannnya adalah melaksanakan proyek tersebut, Anda

harus dapat menganalisis semua risiko-risiko yang mungkin terjadi
yang dapat menggagalkan proyek tersebut. Analisis ini sangat
membantu dalam penulisan PROPOSAL yang berisi rincian
menganai proyek apa yang akan ditawarkan, kapan, dan berapa
biayanya (termasuk biaya untuk risiko-risiko yang mungkin terjadi).
Tulislah beberapa dokumen dan temukan beberapa kejadian

penting pada akhir fase ini.
Pertama, menulis Requirement Document (RD), yaitu dokumen

yang berisi rincian kebutuhan user. Dokumen RD harus jelas dan
lengkap, sehingga Tim Proyek (Project Tem (PT)) dapat
memahami seluruh masalah-masalah yang dihadapi oleh user dan
dapat memperkirakan biaya penyelesaian proyek tersebut..
Kejadian penting pertama yang akan Anda hadapi berupa
persetujuan atau penandatanganan dokumen RD oleh User dan
Tim Proyek.
BAB 2 Halaman 1 dari 8

Selanjutnya, menulis Pendahuluan Perencanaan Proyek

(Preliminary Project Plan (PPP)). PPP merupakan langkah
pertama dalam merencanakan langkah-langkah berikutnya yang
harus diambil untuk mengembangkan produk dan sumber-sumber
apa saja yang dibutuhkan untuk setiap langkahnya. Rencana
tersebut menggambarkan berapa lama sumber-sumber tersebut
akan diperlukan dan berapa banyak biaya yang akan dikeluarkan.
Ketiga
Anda harus memberikan perkiraan-perkiraan ini kepada user
dalam bentuk PROPOSAL.
Seberapa jauh perkiraan-perkiraan tersebut dapat dipertanggung

jawabkan ? Ada dua alasan dalam hal ini. Pertama, kita tidak
begitu ahli dalam memperkirakan sesuatu. Kedua, perkiraan-
perkiraan tersebut dibuat pada saat masih dalam tahap
pendefinisian masalah, dimana pada saat itu baru sebagian kecil
informasi yang kita peroleh dari masalah yang sedemikian luas.
Jika anda tidak yakin dengan kebutuhan-kebutuhan yang telah

digambarkan secara akurat dalam dokumen RD, disarankan untuk
membagi proyek tersebut menjadi 2 tahap : Fase Analisis sebagai
proyek pertama diikuti dengan fase sebelumnya sebagai proyek
kedua.
Pada saat pendefinisian, proposal anda hanya akan menjadi

analisis saja, dan ini disebut PROPOSAL ANALISIS. Setelah
analisis akan ada PROPOSAL PENGEMBANGAN (Lihat bab 3).
Kedua hal ini disebut dengan dua fase proposal. Kejadian penting
yang terdapat disini adalah pembelian proposal oleh user.
2.2. DOKUMEN KEBUTUHAN (REQUIREMENT DOCUMENT / RD)
RD menyatakan masalah-masalah yang dihadapi user dan solusi

umum yang dibutuhkan. Bahasanya berorientasi pada bahasa yang
digunakan oleh user sehari-hari, dan jauh dari bahasa komputer.
Kadangkala dokumen RD digunakan sebagai permohonan untuk
sebuah proposal (Request for a proposal (RFP)) ketika user
menawarkan proyeknya kepada kontraktor luar.

Tanya jawab dengan User

Proses tanya jawab dilakukan untuk mendapatkan informasi yang
tepat dari user untuk memperoleh RD yang baik. User akan
memberikan semua informasi yang anda butuhkan dan tidak lebih.
Tim proyek interviewer berkewajiban untuk mempelajari semua bisnis
user, memahami teknologi user, dan mengajukan pertanyaan-
pertanyaan.
Masalah terbesar berkaitan dengan pemakai akhir (end-user) yang

sesungguhnya petugas pemasukan data atau petugas pengirim
barang yang berada di gudang. Seringkali manajer atau supervisor
mengatakan bahwa pemakai akhir sangat sibuk dan tidak mampu
untuk memberikan informasi yang dapat dipercaya. Terkadang
manajer merasa dilangkahi atau diremehkan jika anda berhubungan
langsung dengan pemakai akhir yang berada di departemen mereka.
Solusi dari masalah ini adalah mendidik para wakil tim proyek
tersebut bagaimana pentingnya komunikasi dengan para pemakai
akhir yang sebenarnya. Jika masukkan yang mereka kemukakan
tidak mendapat tanggapan pada awal pendefinisian, akan sangat
mungkin terjadi perubahan-perubahan di kemudian hari dan hal ini
berarti akan membutuhkan biaya yang cukup mahal untuk
memperbaikinya. Mintalah izin dari manajer yang berwenang pada
saat akan mewawancarai orang-orang mereka.
Siapkan rencana untuk melakukan wawancara. Pelajari tentang

bisnis yang mereka lakukan, dan tulislah pertanyaan-pertanyaan
yang akan diajukan. Berikut ini pertanyaan yang berhubungan
dengan wawancara yang akan dilakukan :
Pertama, cari tahu tentang aliran informasi yang ada dalam

perusahaan tersebut. Mulailah dengan pertanyaan-pertanyaan
seperti : informasi apa saja yang dibutuhkan untuk menjalankan
kegiatan bisnis perusahaan ? Seberapa penting aliran data, baik
antara departemen maupun antar individual ? Tentukan frekuensi,
waktu dan keakuratannya.

Kedua, masukkan-masukkan yang diterima diikuti dengan

pertanyaan-pertanyaan sebagai berikut : Informasi apa saja yang
dibutuhkan untuk menghasilkan masing-masing barang? Informasi
apa yang tersedia, kapan, dimana ? Informasi-informasi baru apa
saja yang harus dikumpulkan ? Ingat tentang 5 W (Who, What,
Where, When, Why). Sediakan waktu untuk pertanyaan-
pertanyaan di atas selama membuat.
Hal-hal yang terdapat dalam RD
Berikut ini adalah bagian-bagian dari RD :

1. Pendahuluan. Identifikasi perusahaan (user) dan juga penjual
dimana RD tersebut ditujukan. Tentukan masalah yang perlu
diselesaikan, latar belakang, contoh situasi yang sedang dihadapi,
motivasi-motivasi untuk menanggulanginya, dll. Bagian ini
digunakan untuk memperkenalkan potensi penjual kepada
perusahaan user atau departemen jika diperlukan, jelaskan kultur,
lingkungungan, dan bagaimana jalannya bisnis yang dilakukan.
Berikan pengertian kepada Tim Proyek tentang masalah yang
dihadapi user.
2. Tujuan Proyek. Sebuah pernyataan singkat mengapa kita

mengajukan proposal untuk pengembangan proyek. Batasan-
batasan utama dalam penggunaan waktu dan keuangan dapat
juga disebutkan.
3. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana

sistem berfungsi berdasarkan tujuan proyek yang telah ditetapkan.
4. Keluaran Umum. Penjelasan secara singkat tentang informasi

yang dibutuhkan dari sistem.
5. Informasi Input secara Umum. Input data apa yang diperlukan

untuk menghasilkan output. Ini adalah waktu yang tepat untuk
memastikan bahwa seluruh data yang dibutuhkan dapat tersedia
pada waktu yang tepat pula.

6. Kinerja (Performance). Berapa banyak transaksi yang akan

diproses, berapa banyak data yang akan disimpan, kapan laporan
harus dihasilkan, dsb. Jelaskan waktu rata-rata dan waktu
maksimal proses (dalam hari atau jam).
7. Perkembangan (Growth). Hal ini mungkin sulit untuk diramalkan,

tetapi cobalah untuk menghitung kemajuan bisnis dan
menetapkan berapa tahun lagi sistem masih dapat diharapkan
untuk berfungsi. Kemukakan dalam bentuk persentase atau angka
sebenarnya.
8. Pengoperasian dan Lingkungan. Dimana komputer akan

ditempatkan, dimana terminal-terminal yang interaktif ditempatkan,
dan siapa yang akan menggunakannya.
9. Kompatibilitas, Pengantarmukaan. Jelaskan jika fasilitas antar

komputer dibutuhkan, adakah alat-alat yang harus disatukan, atau
jika pengiriman akses dibutuhkan. Jika sistem hanya dapat
berjalan dengan komputer yang ada, atau harus dapat diprogram
dengan bahasa yang spesifik, semua dokumen dinyatakan di
dalam bagian ini.
10. Reliabilitas, Ketersediaan. Tulis penggambaran waktu

diantara kegagalan-kegagalan (Meantime between Failures /
MTBF), waktu untuk perbaikan (Meantime to Repair / MTTR) dan
persentase tambahan yang diperlukan. Semua manufaktur
menyatakan penggambaran ini untuk hardware mereka.
11. Pengantarmukaan dengan Pemakai. Rincikan pengalaman-

pengalaman yang dibutuhkan user dalam menggunakan
komputer, jelaskan bagaimana menangani sistem kapada user
yang baru.
12. Pengaruh Organisasi. Departemen-departemen apa yang

akan sangat berpengaruh dan seberapa jauh cara kerja mereka
harus berubah. Bagaimana sistem yang baru dapat berkomunikasi
dengan sistem manual yang ada.
13. Pemeliharaan dan Dukungan. Jaminan-jaminan yang

dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman.

14. Dokumentasi dan Pelatihan. Rincikan semua dokumen-

dokumen umum dan / atau pelatihan yang dibutuhkan.
15. Keuntungan (hanya RFP). Jika RD adalah RFP dalam situasi

yang kompetitif, mintalah data dari penjual yang menjelaskan
mengapa dokumen tersebut harus dipilih. Minta data yang relevan
dari penjual yang berpengalaman, komitmen, metodologi proyek,
contoh-contoh proyek yang sukses, dan referensi dimana anda
dapat menghubungi penjual tersebut.
16. Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi,

kapan dan bagaimana akan dilakukan.
2.3. TANGGUNG JAWAB USER
Meskipun user tidak menulis RD, dia bertanggung jawab untuk

menyediakan pewawancara tim proyek yang dapat dipercaya, dan
informasi tepat pada waktunya. User harus dapat mengajukan orang
yang mengetahui tentang semua sistem yang ada dan apa saja yang
dibutuhkan untuk sistem baru.
2.4. KEPUTUSAN MELAKSANAKAN / TIDAK MELAKSANAKAN

PROYEK
Setelah kebutuhan-kebutuhan ditetapkan, langkah berikutnya adalah

memutuskan apakah proyek bernilai untuk dikerjakan atau tidak.
Untuk membantu membuat keputusan itu, suatu studi kelayakan
dilakukan untuk menjawab pertanyaan : “Dapatkah sistem ini
dibangun secara teknik ? Sayangnya, tidak semuanya mungkin
secara teknik, sehingga pertanyaan-pertanyaan untuk dijawab diubah
menjadi, “Dengan biaya berapa sistem dapat dibangun, dan apa
keuntungannya ?

Dalam suatu studi kelayakan kita mempertimbangkan semua

penyelesaian masalah teknis yang mungkin, dan coba untuk
memperkirakan biaya dari masing-masing penyelesaian masalah.
Untuk suatu proyek yang berukuran besar, kita mempertimbangkan
keputusan utama mengenai hardware apa yang digunakan, dan
apakah akan membuat atau membeli software. Untuk proyek
berukuran kecil sampai menengah studi kelayakan yang formal tidak
perlu ditulis. Biasanya cukup dengan mengangkat seseorang untuk
mempelajari penyelesaian masalah yang mungkin dan menilai
keuntungan-keuntungan.
Perkiraan keuntungan ini mungkin saja mudah, tetapi seharusnya

tidak dipergunakan. Manajer proyek tidak hanya harus menjawab
“Apakah proyek ini secara teknik dapat dikerjakan ?” tetapi juga
menjawab pertanyaan yang lebih penting : “Apakah proyek ini
dapat dikerjakan oleh saya sekarang ?”
Manajer proyek harus bertanya pada diri sendiri apakah proyek yang
ada memiliki peluang untuk sukses, atau proyek tersebut akan
mengalami kegagalan disebabkan oleh terbatasnya sumber-sumber,
pengetahuan, atau risiko di luar kekuasaannya. Tidak terkira proyek-
proyek telah gagal secara keseluruhan maupun sebagian, karena
orang mengabaikan tanda-tanda penting dan nyata yang menunjukan
kegagalan. Setiap rencana dipengaruhi oleh risiko.
2.5. MANAJEMEN RISIKO
Menurut sejarah, industri pemrosesan data telah membuat reputasi

yang buruk sekali karena meremehkan proyek-proyek yang ada.
Ketika ditanya tentang alasannya, para ahli pemrosesan data
membela diri dengan meberikan pernyataan seperti : “Saya menilai
dengan benar berdasarkan fakta-fakta yang diberikan kepada saya.
Alasan yang menumpuk adalah bahwa :

(Pilih satu atau lebih : Si pemakai mengubah pikirannya …..
tidak pernah memberitahukan saya tentang… dan departemen-
departemen yang lain menjanjikan ….. dan manajemen tingkat
atas mendikte penilaian ….. dengan kata lain, itu bukan
kesalahan saya !)

Solusi standar industri untuk semua masalah-masalah ini adalah :
SOLUSI 1. Selidiki masalah-masalah yang ada

SOLUSI 2. Hukum yang tidak bersalah
SOLUSI 3. Promosikan yang tidak terlibat
SOLUSI 4. Kembali ke solusi 1 dan berputar sampai membosankan
2.6. EMPAT LANGKAH MANAJEMEN RISIKO
Setiap proyek akan tepat waktu dan sesuai anggaran jika tidak ada
yang salah. Penting sekali untuk berkosentrasi pada hal-hal yang
akan menyebabkan salah dan coba untuk menghindari kesalahan-
kesalahan tersebut. Hal ini disebut Manajemen Risiko.
Manajemen risiko terdiri dari empat langkah :

Langkah 1. Antisipasi risiko
Langkah 2. Singkirkan risiko yang mungkin terjadi
Langkah 3. Kurangi dampak risiko
Langkah 4. Tetap tenang ketika terjadi kesalahan

BAB 3
PERENCANAAN PROYEK
3.1. PENDAHULUAN
Sekarang anda sudah mengevaluasi proyek dan memutuskan untuk

melanjutkannya. Pertama, anda harus meyakinkan rekan-rekan lain
bahwa proyek sebaiknya dilaksanakan. Hal ini dilakukan dengan
membuat proposal. Untuk sebuah proyek eksternal, proposal ditulis
untuk meyakinkan klien agar membeli proyek dari tim proyek anda.
Untuk proyek internal, manajemen sebaiknya meminta untuk
membuat sebuah proposal. Hal ini untuk mendukung tim proyek
untuk membuat rencana yang sederhana.
Sebuah proposal adalah dokumen yang merinci biaya dan jadwal

proyek, serta menjelaskan langkah-langkah yang akan diambil
oleh tim proyek untuk menghasilkan produk yang diinginkan.
Perencanaan adalah sebuah proses yang berulang-ulang : rencana

akan ditinjau secara terus menerus sesuai dengan perkembangan
proyek dan sesuai dengan bertambahnya pengetahuan dan
pemahaman yang lebih baik dari anggota tim. Perencanaan
memang merupakan pekerjaan yang sangat sulit, tetapi harus
dilaksanakan sebagaimana mestinya. Banyak proyek menjadi kacau
dikarenakan tidak adanya perencanaan.
3.2. PENDAHULUAN PERENCANAAN PROYEK

(THE PRELIMINARY PROJECT PLAN / PPP)
Pendahuluan Perencanaan Proyek adalah langkah awal, sumber

daya, biaya dan jadwal yang dibutuhkan untuk menyelesaikan
proyek. PPP adalah dokumen internal, tidak perlu ditunjukkan ke
user, terutama user luar.

3.3. RINCIAN STRUKTUR KERJA

(WORK BREAKDOWN STRUCTURES / WBS)
Kunci berbagai rencana adalah memecah kegiatan yang diperlukan

ke dalam sebuah bagian yang lebih kecil lagi. Rincian struktur kerja
(WBS) diawali dengan menyusun komponen-komponen utama
proyek. Hal ini merupakan Level 1 dari WBS (Level 0 adalah judul
proyek).
Untuk proyek software, metode terbaik untuk pemecahan proyek

menjadi bagian-bagian utama adalah diawali dengan 7 fase
pengembangan software.
Lihat Gambar 3.1. Rincian Struktur Kerja / WBS

Lihat Gambar 3.2. WBS untuk analisis
Sistem Penomoran WBS
Sistem penomoran dalam WBS seperti pada gambar 3.2 :

- Untuk Level 0 atau judul proyek adalah 0.0.
- Pada Level 1 masing-masing item diberi nomor N.0.
Contoh : 1.0, 2.0, dst.
- Kemudian masing-masing item pada Level 2 dibawah item N.0
pada Level 1 diberi nomor N.1, N.2, dst.
Contoh : di bawah Level 1 item Analysis yang bernomor 2.0, kita
mempunyai item 2.1, 2.2, dst.
- Sedangkan untuk Level 3, kita tambahkan titik dan digit dari nomor
di Level 2. Sebagai contoh, dibawah 2.1 kita harus menuliskan
2.1.1, 2.1.2, dst.
Kapan Anda Berhenti ?
Pemasukkan nomor pada level terendah menunjukkan tugas atau

kegiatan dalam proyek. Anda dapat berhenti merinci sebuah kegiatan
jika mengikuti langkah-langkah berikut dengan benar :
1. Beberapa orang (atau grup dari sebuah proyek besar) dapat
diberikan tanggung jawab untuk melakukan tugas atau
menyelesaikan kegiatan-kegiatan yang dilibatkan.

2. Anda dapat memperoleh perkiraan (berupa orang atau hari)

secara garis besar sebagai upaya yang dibutuhkan untuk
melaksanakan kegiatan-kegiatan yang terlibat. Hal ini dapat
dilakukan dengan memberi tanggung jawab pada setiap orang.
3. Anda dapat menjadwalkan tugas.
4. Tugas-tugas tersebut harus singkat dan dapat diselesaikan.
Sebagai seorang ahli kita dapat menetapkan sebuah tugas kepada

Programmer, Analis, atau bahkan Manajer Proyek. Tergantung pada
pengalaman dan keahlian dalam membuat perkiraan, analis mungkin
hanya memerlukan level 1 dari WBS. Beberapa analis dapat dengan
mudah membaca RD untuk proyek ABC (Appendix A) secara
keseluruhan. Analis lain untuk merinci membutuhkan sampai Level 2.
Seperti pada gambar 3.2, analis lainnya memerlukan sampai Level 3
sebelum mereka dapat memperkirakan secara keseluruhan.
Sebagai contoh Level 3 WBS untuk kotak INTERVIEW dan

ANALYZE EXISTING SYSTEMS dapat dilihat pada gambar 3.3.
Lihat Gambar 3.3. WBS Level 3
Para ahli merinci setiap kotak pada level terendah sampai ia dapat
memperkirakan berapa upaya yang diperlukan. Perkiraan-perkiraan
ini dapat dipakai pada WBS seperti pada gambar 3.4. Sebagai
catatan bahwa perkiraan total adalah jumlah dari masing-masing
waktu. Hal ini disebut DIRECT time, yaitu jumlah hari yang
sesungguhnya dibutuhkan untuk melakukan kegiatan .
Lihat Gambar 3.4. Analysis Level 3
Para ahli tersebut dengan cara yang sama dapat merinci kotak yang
lain (DEFINE NEW SYSTEM FUNCTIONS, WRITE FUNCTIONAL
SPEC. dan NEGOTIATE FUNCTIONAL SPEC.) dan menambahkan
total waktu untuk semua analisis. Kemudian ahli tersebut
mengajukan perkiraan dan daftar kegiatan sebelumnya yang
dibutuhkan untuk seluruh analisis bagi Manajer Proyek. Orang
tersebut bertanggung jawab terhadap perencanaan (mungkin
Manajer Proyek untuk proyek berukuran kecil - menengah) kemudian
menggabungkan seluruh perkiraan dan daftar kegiatan terdahulu. Ia
mungkin mengakhirnya dengan daftar seperti berikut ini :

ACTIFITY EFFORT PRECEDENTS
Definition 20 -----------------
Analysis 35 Definition
Design 25 Analysis
Program A (Control) 20 Design
Program B (Registration) 30 Design
Program C (Warehouse) 25 Design
System test 10 Program A, B, C
Documentation 20 Design
Acceptance 5 System Test,
Documentation
Training 10 Documentation
Operation 10 Acceptance
TOTAL 210 person-days
3.4. DIAGRAM JARINGAN (THE NETWORK DIAGRAM)
Langkah kedua dari perencaan adalah menggambarkan diagram

jaringan yang menunjukkan urutan kejadian. Tipe diagram yang
paling baik untuk masalah ini adalah bagan PERT. Gambar 3.5.
adalah sebuah bagan PERT untuk proyek di atas. Urutan kejadian
hanya didasarkan pada contoh setiap kegiatan.
Lihat Gambar 3.5. Bagan PERT
Bentuk dari bagan PERT ini disebut Precedence Network (jaringan

yang diutamakan). Setiap kotak menunjukkan sebuah kegiatan. Pada
setiap kotak ditulis nama kegiatan dan waktu yang diperlukan.
Jalur Kritis & Lamanya Proyek
Bagan PERT dan jalur kritis adalah jumlah jalur, atau serangkaian
kegiatan yang dapat ditelusuri pada PERT sederhana di atas, dengan
mengikuti petunjuk garis panah. Lamanya waktu yang dibutuhkan
untuk menelusuri setiap jalur dapat dijumlahkan dengan
menambahkan lamanya waktu dari jalur masing-masing kegiatan.

Jalur kritis (CP / Critical Path) adalah jalur terpanjang dan

didefinisikan waktu minimal yang dibutuhkan untuk mengerjakan
proyek.
PERT pada gambar 3.5. mempunyai jalur kritis yang terdiri dari
kegiatan : START, DEFINITION, ANALYSIS, DESIGN, PROGRAM
B, SYSTEM TEST, ACCEPTANCE, OPERATION, dan END. Proyek
tersebut membutuhkan total waktu : 135 hari.
3.5. MENGHITUNG BIAYA PROYEK

(CALCULATING PROJECT COST)
Jika kontrak proyek telah mempunyai harga tetap, Manajer Proyek

dapat menghitung biaya kasar untuk tenaga kerja, dengan cara
mengalikan jumlah tenaga kerja per-hari dengan rata-rata biaya per-
hari.
Biaya pekerja perhari disebut ‘biaya penuh’ : yang harus mencakup

biaya operasi, sewa, administrasi pekerja, dan keuntungan. Untuk itu
anda harus menambahkan biaya tetap, seperti computer time, sewa
peralatan khusus, biaya tak terduga, dan sebaginya. Biaya tetap
harus dirinci oleh setiap estimator untuk kegiatan utamanya.
Lihat Gambar 3.6. SUPERPROJECT
Rata-rata Pgr 75 pd @ $1000 per pd 75,000

Keuntungan 25% 18,750
Faktor risiko :
User berubah pikiran terhadap 10% format
Biaya = 10% tambahan waktu pemrograman 7,500
Total pemrograman $ 101,250

3.6. PENJADWALAN PROYEK (PROJECT SCHEDULE)
Langkah selanjutnya adalah menghitung jadwal proyek. Untuk

melakukan hal ini, perencana (mungkin Manajer Proyek) harus
mengaplikasikan jadwal yang sebenarnya dari perkiraan ke
CALENDAR DAYS (jadwal harian) atau lamanya pekerjaan.
Salah satu kesulitan tugas ini adalah mengalokasikan sumber daya
manusia yang akan bekerja pada kegiatan yang akan dilaksanakan,
terutama ketika pekerjaan berlangsung secara serentak. Kesulitan
lain adalah memutuskan bagaimana mempersingkat pekerjaan yang
dilakukan dengan menggunakan sumber daya yang ada.
Kemudian Manajer Proyek menjadwalkan semua proyek pada

kelender atau jadwal yang nyata. Metode terbaik untuk melakukan
hal ini adalah dengan menggambarkan ke dalam sebuah Gantt Chart
atau Bar Chart seperti pada gambar 3.7.
Lihat Gambar 3.7. SUPERPROJECT project schedule
3.7. OUTLINE PENDAHULUAN PERENCANAAN PROYEK

(PRELIMINARY PROJECT PLAN OUTLINE)
Dilengkapi dengan semua pengetahuan ini, Manajer Proyek dapat

menuliskan dokumen penting ini. Berikut ini adalah outline yang
disarankan untuk PPP.
1. Tim Proyek (The Project Team)

Menggambarkan struktur, siapa yang memberikan laporan, siapa
yang menerima laporan, kepada siapa berkomunikasi, dst.
Lihat Gambar 3.8. Typical Project Team Structure
Programmer (tidak lebih dari 5 orang). Bertanggung jawab

terhadap pemrograman.

Pimpinan Proyek (Project Leader)

Mengawasi programmer.
Bertanggung jawab terhadap kegiatan-kegiatan yang bersifat
teknis, seperti analisis, disain dan tugas-tugas pemrograman
keseluruhan.
Tujuan utama : kualitas produk yang dihasilkan secara teknik.
Manajer Proyek (Project Manager)

Manajer dalam tim (pimpinan, motivator, dll).
Bertanggung jawab terhadap semua komunikasi yang datangnya
dari luar (laporan, pertemuan-pertemuan, penghubung antara
manajemen tingkat atas dengan user).
Tujuan utama : keberhasilan proyek (perencanaan, pengontrolan,
komunikasi).
2. Biaya Proyek (Projects Cost)

Termasuk WBS, membuat perkiraan dan perhitungan yang
digunakan untuk menaksir biaya dalam pembuatan produk.
3. Penjadwal Proyek (Project Schedule)

Merupakan bagian terpenting dalam proyek, dan dapat
menggunakan metode Gantt.
4. Pemeriksaan Ulang (Reviews)

Pada bagian ini anda dapat menghubungkan antara pertemuan
dari manajemen utama dengan peninjau teknik (jadwal proyek
akan memberikan informasi ini), tujuan dari masing-masing
peninjau, dan siapa yang akan mengerjakannya. Buatlah daftar
tanggung jawab dari orang-orang yang terlibat.
5. Laporan (Reports)
Bentuk dan isi dari laporan keadaan, laporan milestone dan
dokumen proyek lain dapat dirinci di dalam laporan tersebut.
6. Dokumentasi (Documentation)
Ada 2 jenis dokumen di dalam proyek, yaitu user dan manajemen
proyek.

7. Asumsi (Assumptions)
Disini anda dapat menentapkan harga berdasarkan asumsi :
dimana sebagian besar adalah fakta yang diberikan oleh user.
3.8. KESIMPULAN UNTUK PERENCANAAN

Perencanaan itu seperti menunggang kuda : kelihatannya sulit
sebelum anda mencobanya. Tetapi begitu anda mencobanya, maka
segalanya akan menjadi mudah.

BAB 4
PROPOSAL
4.1. PENDAHULUAN
Sebuah proposal mempunyai 3 kegunaan, yaitu :

1. Berisi perkiraan tim proyek, mulai dari biaya proyek sampai
dengan tanggal pengiriman proyek.
2. Untuk proyek eksternal, dokumen hukum formal menunjukkan
outline tim proyek untuk memberikan pelayanan yang diperlukan.
3. Sebagai alat penjualan. Proposal yang berisi usulan proyek akan
dijual untuk mendapatkan keuntungan.
Kesalahan utama pada proposal dapat disebabkan 2 hal :

1. Tidak menawar, yang mana seharusnya bisa ditawar.
2. Ada tawaran, tetapi hilang dalam kompetisi.
4.2. DUA FASE PROPOSAL PROYEK SOFTWARE
Ada 2 fase proses proposal, yaitu :

1. Buat fase analisis sebagian kecil proyek, usulkan untuk dikerjakan
dalam Proposal Analisis (Analysis Porposal).
2. Setelah analisis dikerjakan, usulkan sisanya dibangun dalam
Proposal Pengembangan (Development Proposal).
4.3. MENULIS PROPOSAL
Menulis proposal itu sulit. Harus dilakukan dengan benar, selain

dapat merusak reputasi anda dan mengubah masa depan bisnis
anda dengan klien. Menulis proposal juga mahal, dibuat dengan
mengumpulkan banyak sumber dan banyak hal, serta terkadang
anda membayar orang untuk membuatnya.
Jika anda menulis proposal gunakan word processor dan gunakan

huruf-huruf unik untuk setiap proposal, tetapi pastikan penulisan
tersebut dibenarkan untuk setiap klien. Kerjakan dengan

Requirement Document (RD), khususnya Request For a Proposal

(RFP). Format proposal harus mengikuti RFP dan RD.
Garis besar Proposal (Proposal Outline) :
1. Cakupan Surat (Cover Letter)

Sebuah surat yang ditujukan kepada pengambil keputusan,
ditandatangani oleh Manajer Proyek (jika diwakili oleh seorang
Akuntan, maka Akuntan tersebut dapat menandatangani surat ini
bersama klien yang lain).
♦ Bentuk dimulai dengan teks pendahuluan, seperti : “Thank you

for giving XYZ Software Co. the opportunity to propose …….
For your computer system.”
♦ Paragraf berikutnya memberikan penjelasan yang mudah dari

sistem, seperti “ …….hardware anda software to handle ABC’S
registration, finance and management information needs for the
next three years.”
♦ Paragraf berikutnya, jelaskan yang merupakan proposal

analisis atau proposal pengembangan
♦ Penutup, akhiri surat dengan pernyataan yang menunjukkan

kecepatan anda membuat keputusan di surat. Bagian penutup
disertai batas akhir penentuan harga (biasanya 30 hari), atau
pernyataan seperti , “If we are given a go-ahead in 14 days we
can start January 1, otherwise we must do another project, and
we can only start yours on June 1.” Penutup surat ini dibuat
sebagus mungkin.
2. Halam Judul (Tittle Page)

Halaman ini berisi “Proposal”, judul dari sistem, pembuat, tanggal,
nomor revisi, logo perusahaan, dan sebagainya.
3. Daftar Isi (Table of Contens)

Bila klien anda tidak terbiasa dengan format proposal anda, beri
penjelasan dari kegunaan setiap bagian.

Berikut ini contoh formatnya :
Section 1 : TUJUAN Menggambarkan masalah bisnis yang

disertai penyelesaian XYZ, ukuran, tingkat dan
batasan yang disarankan untuk sistem
penyelesaiannya …………………………… halaman 3
Section 2 : Keuntungan ………………………………….. halaman 4
4. Ruang Lingkup (Scope)

Lihat paragraf yang menjelaskan hal tersebut pada bagian ini
langsung dari Requirement Documents.
5. Keuntungan (Advantages)
Jual proyek anda. Buktikan bagaimana perencanaan anda, kontrol
dan 7 fase metodologi.
6. Keuangan (Financial)
Buat harga total dan tanggal pengiriman. Bila termasuk hardware,
rinci harga hardware dan sistem operasinya.
Buat daftar non material, seperti job satisfaction, good will,
customer happiness, management happiness, etc.
7. Rencana (Plan)
Gambarkan langkah-langkah rencana anda untuk membangun
proyek. Jika proposal analisis, rinci alasan-alasan untuk
penggunaan metode 2 langkah. Jelaskan fase analisis yang
dihasilkan tidak terhingga nilainya, dokumen Functional
Specification yang akan digunakan oleh Klien dan Tim proyek
untuk spesifikasi yang tepat mengenai apa yang dilakukan sistem.
8. Kemampuan dalam penyampaian (Deliverablless)

Daftar user yang akan merinci :
♦ Hardware, sistem operasi, paket software: buat daftar secara
rinci.
Keadaan bagaimana yang anda pilih salah satu fungsi,
kapasitas dan tanggal pengiriman.
♦ Custom software : sama seperti di atas.

♦ Jaminan : berapa lama setelah pengiriman dan bagaimana

anda akan memberikan dukungan.
♦ Dokumen : daftar manual (user, operator, manajer,

maintenance) dengan penjelasan singkat dari pembaca.
♦ Pelatihan : daftar bagian (user, operator, manajer,

maintenance) dengan penjelasan laporan singkat dari peserta.
♦ Gambarkan metode pengiriman : kapan anda akan mengirim,

dimana akan dikirimnya dan bagaimana itu dilakukan.
9. Penerimaan (Acceptance)
Salah satu masalah yang sering terjadi dalam industri komputer
adalah sistem yang ditolak. User menolak untuk menerima sistem
(dan untuk membayarnya), karena dia merasa tidak seperti apa
yang disetujui Tim proyek pada awal pengiriman.
10. Alternatif (Alternatives)

Kadang-kadang kita menentukan RFP ditulis langsung oleh
penjual (hardware / software) dalam pikiran kita. Ini baik, jika anda
adalah penjual, tetapi apa yang anda lakukan bila anda bukan
penjual ?. Anda harus merinci solusi penjual-penjual lain, seperti
ALTERNATIVE SOLUTION dan buktikan mengapa solusinya
berbeda.
11. Istilah, Kondisi dan Pendapat

(Terms, Conditions and Assumptions)
Daftar yang ada disini adalah semua kondisi yang diinginkan
untuk bekerja di dalam proyek internal. Daftarkan semua asumsi,
jika asumsinya mempengaruhi biaya proyek, anda harus
memproteksinya.
Daftar semua asumsi selalu ada pertanyaan dimana user tidak

dapat menjawab dengan tepat, dan hanya dapat menjawab yang
bersifat sementara jika asumsi tersebut mempunyai pengaruh
yang bernilai pada proyek. User harus melaksanakan sendiri
pendapatnya.

12. Istilah khusus (Terminologi)

Setiap proposal harus ditulis dengan menggunakan bahasa user
yang mungkin, beberapa istilah komputer mungkin berbeda. Jika
anda merasa bahwa istilah khusus ini tidak lazim bagi user, buat
definisinya.
4.4. PROPOSAL INFORMAL
Proposal tidak harus dibuat di ruang rapat. Proposal tersebut dapat

dibuat menjadi informal melalui telepon, tempat latihan golf, bahkan
di bar.
Presentasi proposal secara formal yang dilakukan di ruang rapat

akan selalu membutuhkan tempat, tetapi user sudah siap mengetahui
hal-hal utama apa yang akan dikemukakan.
4.5. PERSETUJUAN PROPOSAL INTERNAL
Ada aturan di DEC Software Service yang menyatakan bahwa

proposal tidak dapat keluar sebelum mendapat persetujuan dari
manajemen tingkat tinggi. Persetujuan manajemen tingkat tinggi
berhubungan dengan sejumlah hal yang diusulkan. Peraturan ini
untuk menghindari hal-hal yang tidak diinginkan.
4.6. PRESENTASI PROPOSAL
Selalu siapkan presentasi. Siapkan dan buatlah jadwal semua

peralatan yang dibutuhkan, seperti transparansi, proyektor, layar,
sebuah terminal dan modem untuk berhubungan ke dalam sistem
yang mirip dengan yang anda usulkan.
Buatlah presentasi di dalam ruangan yang tepat menurut anda,

dimana menurut pandangan user akan lebih dapat diterima.

Langkah-langkah presentasi :
¾ Buatlah ucapan pembuka. Perkenalkan tiap peserta, dan nyatakan
tujuan pertemuan tersebut.
¾ Perkenalkan proposal anda secara garis besar.
¾ Bagikan proposal anda.
¾ Beri waktu pada tiap peserta untuk membaca proposal.
¾ Kemudian beri penekanan utama di setiap bagian yang penting.
¾ Terakhir, tutup – sarankan user untuk membeli dan membeli
secepatnya.
4.7. KESIMPULAN UNTUK PROPOSAL
Penulisan proposal dan mempresentasikannya merupakan

sebuah seni.
Anda mungkin beruntung dan tidak harus membuat proposal.
Jangan membuat proposal asal jadi. Utamakan kualitas bukan
kuantitas.
Jangan janjikan sesuatu yang tidak diminta oleh klien : Siapa yang
anda pikir akan membayar ini ?
Rencanakan memberi solusi untuk semua masalah.
Dan akhirnya, untuk sebuah proyek eksternal, sebuah proposal
adalah kumpulan dokumen yang sah. Hal ini seharusnya dibuat
sebaik mungkin seperti untuk proyek di dalam yang dengan resmi
dibuat seperti jika melakukan kontrak eksternal.

KASUS
Tidak menawar
Sebuah perusahaan minuman ringan mengundang seorang Analis
dari Famous Minicomputer Manufacturing Company (FMMC), untuk
mempelajari suatu kemungkinan pada suatu hal, jika ada sesuatu
yang bermanfaat dari sistem komputerisasi pada pabrik minuman
ringan tersebut. Si Analisis mempelajarinya, tetapi selama belajar dia
menemui sedikit kesulitan dengan masalah akuntansi di perusahaan
tersebut. Akuntan yang ada pada perusahaan tersebut takut
kehilangan pekerjaan dengan adanya komputer, sehingga ia
mempersulit Analis dengan menolak menjawab pertanyaan yang
diajukan kepadanya.
Hasil dari yang dipelajari : Analis menyarankan bahwa beberapa

penggunaan sistem komputerisasi akan membantu pekerjaan.
Sehingga Analis menyarankan agar sistem komputer yang ada dapat
digunakan untuk menjalankan pekerjaan bagian keuangan yang
meliputi : piutang, hutang, kontrol persediaan, dll. Analis juga
menyarankan untuk mengimplementasikan sistem tersebut untuk
menangani masalah gaji, pajak, dan sejenisnya, serta menangani
masalah produksi minuman yang meliputi proses produksi
pembuatan minuman dan pengawasan barang-barang di gudang
secara ototmatis. Ketika ditanya mengenai perincian harga untuk
sistem tersebut, berdasarkan konsentrasi waktu, Analis menjelaskan
bahwa hanya untuk sistem keuangan diperlukan biaya $150.000.
Reaksi dari user terlihat kasar. Singkatnya dia mengatakan bahwa

$150.000 terlalu mahal untuk sistem komputer yang terlihat begitu
sedikit kegunaannya. Dia mengatakan tidak akan membayar lebih
dari $50.000 untuk sistem keuangan.
Kesalahan fatal dilakukan oleh Manajer si Analis tersebut.

Berdasarkan reaksi user (dan mungkin untuk alasan pribadi), Analis
menyarankan kepada manajernya agar FMMC menarik kembali
penawarannya. Analis merasa bahwa user akan sulit untuk ditangani,
dan user tidak akan menjawab pertanyaan-pertanyaan dengan
benar. Dan bahwa FMMC dan perusahaan minuman ringan tersebut
tidak akan pernah mencapai kesepakatan. Sayangnya Manajer
tersebut menyetujuinya dan membatalkan penawaran.

Komentar : Semua user merasa bahwa harga sistem yang

ditawarkan terlalu mahal. Mungkin user dapat saja menang dengan
pendekatan lain yang berbeda. Analis dapat mengusulkan
pembuatan sistem tersebut secara bertahap yaitu dengan membuat
sistem dalam ukuran-ukuran yang lebih kecil, sehingga user tertarik.
Mungin user memiliki uang, dan dia perlu bernegosiasi. Jangan
pernah menyerah untuk menawar dalam pertemuan pertama.
Mungkin saja ada masalah pribadi antara Akuntan yang takut
kehilangan kedudukannya dengan Analis. Manajer harus mengetahui
hal ini dan datang untuk membantu bernegosiasi.
Situasi di atas dapat terjadi pada proyek internal dimana seorang

user dan klien berada pada dua departemen dalam satu perusahaan.
Usahakan reaksi pertama untuk mengurangi harga. Rencanakan
negosiasi. Kadang-kadang lawan anda hanya menguji untuk
mengetahui seberapa yakin anda pada proposal anda. Bila anda
menarik kembali penawaran haga dengan tergesa-gesa, dia akan
mengetahui bahwa anda tidak percaya diri.
Penutup : Perusahaan minuman ringan tersebut menggunakan

sistem komputerisasi dengan harga ditetapkan oleh Analis pertama,
tetapi tidak oleh perusahaan FMMC.
Kehilangan Penawaran
Seorang pengarang buku terkenal “Software Project Management”
(untuk proyek berukuran kecil) memulai karirnya memberi nasehat
sebagai guru mikrokomputer. Dia berjalan-jalan di sekitar toko-toko
mikrokomputer di kotanya dan memberi informasi pada pemilik toko
bahwa ia dapat mengajar apapun pada siapapun. Sungguh
meyakinkan, suatu hari ia mendapat panggilan dari departemen
pemerintahan bagian pemeliharaan pesawat terbang. Tugas mereka
adalah mengetahui siapa saja di negara tersebut yang sudah
mendapat pelatihan mengenai jenis-jenis pesawat terbang.
Enam bulan yang lalu seorang anggota departemen telah membeli

sebuah mikrokomputer kuno, lengkap dengan program data base
yang tidak terdokumentasikan (dengan harga yang luar biasa), tetapi
ia telah meninggalkan departemen tersebut sebelum data base

diimplementasikan. Tidak seorangpun dari pegawai di departemen itu

memiliki pengalaman komputer. Maka guru itu dipekerjakan untuk
melatih pegawai di departemen itu dengan cukup baik, untuk
menjalankan program data base pada komputer. Guru tersebut
memperoleh informasi yang tepat dan berhasil mengajak orang-
orang bagaimana menggunakan komputer dan program data base.
Sekitar satu bulan kemudian, guru itu menerima panggilan dari

kepala departemen, yang menanyakan jika ia dapat mengajukan
harga yang sebenarnya untuk menjalankan data base mereka. Guru
tersebut mewawancarai pemakai data base yang berpotensi : ada 25
pemakai yang berpotensi dengan 50 pendapat yang berbeda tentang
bagaimana menggunakan data base tersebut. Dengan catatan
program data base tidak akan mengatasi semua kebutuhan mereka –
program-program yang lainnya akan ditulis. Guru memperkirakan ini
akan memakan waktu selama 3 bulan.
Kesempatan pertama si guru harus mengajukan proposal pada rapat

komisi tingkat manajer dari 8 manajer departemen. Semua berjalan
lancar sampai pada waktu ia mengemukakan harganya : 3 bulan
untuk membuat program dengan biaya $400 per-hari, totalnya
$20.000. Para manajer terkejut. Selama ini mereka hanya
menghabiskan $1000 untuk hardware dan paket software, dan
sekarang seorang yang dungu memberitahukan mereka bahwa ia
akan menghabiskan $20.000 lagi untuk menjalankannya.
Komentar : Terkadang para pemakai tidak sadar akan harga

software, khususnya pada mikrokomputer dimana harga hardware
hanya sebagian kecil dari harga keseluruhannya. Pada kasus ini
harapan para Manajer tidak ditetapkan dengan tepat untuk batasan
harga tersebut.
Penutup : Mikrokomputer ini tetap ada di sana bersama dengan

debu.

BAB 5
NEGOSIASI DAN KONTRAK
5.1. NEGOSIASI
Mengapa bila orang pergi ke tempat perdagangan di Mexico, mereka

akan melakukan negosiasi walaupun hanya untuk beberapa dolar
saja, tetapi bila mereka melakukan transasksi dengan sebuah produk
berharga ribuan dolar, mereka enggan untuk “tawar-menawar”. Tidak
ada kata malu untuk melakukan negosiasi. Belajar dari bagaimana
semua itu dilakukan dengan benar dan anda dapat menggunakan
keahlian pada saat situasi tawar-menawar dalam lingkungan proyek
software.
Ilmu Pengetahuan dan Seni Bernegosiasi

Kunci sukses dari negosiasi adalah mengetahui fakta yang
sebenarnya. Hal pertama dan yang terpenting, mengetahui produk
yang akan dijual atau dibeli.
Sebelum anda memulai negosiasi, tentukan dua hal :

1. Apa yang sepenuhnya anda inginkan untuk perjanjian
2. Apa yang akan anda berikan
Bila anda penjual software, hal yang akan dinegosiasikan adalah

harga, ketahui harga minimum yang akan diminta. Jika anda pembeli,
ketahui harga maksimum yang akan dibayarkan. Hal ini juga
membantu jika anda mengetahui kebutuhan lawan anda, ini
dikatakan dengan fleksibilitas.
Tiga hal yang dinegosiasikan dalam proyek software

Hal yang paling sering dinegosiasikan adalah harga, tetapi lamanya
proyek dan fungsi proyek dapat juga dinegosiasikan. Seperti kata
pepatah, “Anda akan mendapatkan yang murah, cepat atau bagus :
pilih dua hal”. Anda dapat menghemat uang dengan mengambil
waktu yang lebih lama. Atau apabila harga terlalu mahal,
perhitungkan menawar dengan kelengkapan yang lebih sedikit.

Anda memperoleh apa yang anda bayar

Jika anda membeli produk, berhati-hatilah dengan tawar-menawar
Tim proyek yang terlalu rendah, atau menerima tawaran murah yang
tidak biasanya.
Contoh kasus :
Perusahaan ABC menawarkan tender keluar untuk kebutuhan
software. Mereka menerima 2 tawaran :
Pertama dari Smart Software Co. (SSC). SSC mempunyai perkiraan
akurat dan menawarkan harga $200 untuk dilaksanakan dalam 12
bulan.
Kedua, tawaran dari Unscrupulous Software Co. (USC). Mereka
menawarkan $100 untuk jangka waktu 6 bulan.
Mencoba menghemat biaya, perusahaan ABC tentu saja menerima

USC. Enam bulan kemudian setelah pembayaran $100 kepada
USC, kejadian berikut ini terjadi :
ABC : Benarkah sistem akan diantar hari ini ?

USC : Kami mempunyai kabar buruk.
ABC : Kabar buruk apa ?
USC : Sayang sekali, kami telah menghabiskan $100, tetapi kami
baru menyelesaikan hanya setengah dari sistem yang tertulis.
Anda punya dua pilihan : berikan kami $100 lagi (atau
mungkin lebih), atau ambil saja setengah sistem anda.
ABC : Tetapi kita mempunyai kontrak !
USC : Saya harus menggaji programmer saya, jika tidak mereka
akan berhenti. Jika anda tidak membayar saya, saya akan
dinyatakan bangkrut. Silakan kirim surat ke Brazil.
5.2. KONTRAK
Kontrak untuk produk software mengharuskan tim proyek untuk
menyediakan pengirim khusus, seperti tanggal yang pasti, untuk
berbagai macam pemberian upah. Kecuali proyek ini dilaksanakan
pada dasar formal dalam organisasi eksternal, khususnya dalam
dokumen “kontrak” yang tidak ingin dituliskan.

Bagian-bagian Kontrak (Items To Be Contracted)

Dalam tambahan untuk harga, tanggal pengiriman dan pengiriman,
kontrak ini dapat termasuk dalam hal-hal dan kondisi lain seperti
reproduksi, harga bertahan (price holding), lisensi atau garansi. Bila
kerusakan dari software dapat menyebabkan tidak hidup atau situasi
kritis lain, pertanggung jawaban dari pemulis harus diklarifikasikan.
Jika perkiraan didasarkan pada input verbal dari user, “escape
clause” harus diikutsertakan. Anjuran tim proyek ini berguna untuk
keluar dari kesalahan informasi. Tanggung jawab user, seperti
menyediakan informasi yang akurat dan tepat waktu, atau melakukan
beberapa pekerjaan seperti dokumentasi, juga harus ditulis.
Kontrak Harga Tetap (The Fixed Price (FP) Contract)

Ini merupakan tipe umum dari kontrak. Di dalam kontrak FP, tim
proyek mengajukan harga total pada awal proyek. Bagaimanapun
juga tim proyek harus memperkirakan risiko di dalam kontrak FP.
Gunakan kontrak FP hanya jika anda dapat memperhitungkan risiko
dan harganya.
Kontrak FP sangat tepat bila :

1. Anda yakin bahwa tidak akan terjadi pergantian utama.
2. Anda akan bekerja dengan software dan produk hardware yang
anda ketahui.
3. Anda memiliki komunikasi yang baik dengan user.
Kontrak Harga Tambahan (The Cost Plus (CP) Contract)

Apabila risiko terlalu tinggi dalam menentukan harga tetap, tim
proyek harus memilih kontrak CP. Pada kontrak CP, tim proyek
menerima gaji dalam jumlah tetap per-hari atau per-jam ditambah
ongkos-ongkos. Biasanya perusahaan tidak membuat janji untuk
berapa lama mereka membuat kontrak.
Kontrak CP sangat tepat bila :

1. Anda merasa bahwa pergantian utama akan terjadi (RD tidak ada
atau kebutuhan lain tidak jelas).
2. Anda bekerja dengan tidak mengetahui sistem operasi, paket
software atau hardware, atau anda mempunyai peralatan
pengembangan khusus untuk menulis, seperti simulator, tes
dasar, dsb.

3. Komunikasi yang kurang baik antara anda dan user.

4. Aktifitas utamanya berorientasi pada manusia, contohnya
interview.
Kondisi dan Syarat (Terms and Conditions)

Jika anda menjalani kontrak CP, yakinkan bahwa kondisi dan
persyaratan jelas.
Masukkan semua syarat dan kondisi – aspek hukum dari cara yang
anda inginkan untuk bekerja dengan klien. Ini akan memeberikan
perlindungan bagi anda dan klien, dan menghindari kesulitan yang
akan datang. Hal-hal yang berkaitan dengan hukum harus
diklarifikasi seawal mungkin yang dapat meliputi isu-isu pembayaran,
hak cipta untuk sumber daya dan dokumentasi, hutang, jaminan, dan
masalah-masalah yang berhubungan dengan hardware dan software
yang disediakan oleh pabrik.
Kontrak Di luar Organisasi dan Di dalam Organisasi

Kontrak akan diterima secara luas jika organisasi eksternal atau
perusahaan menyediakan layanan proyek. Mengapa ini bukan bagian
dari proyek ? Walaupun hubungan antara tim proyek dan user sangat
dekat harus ada sesuatu yang bersifat resmi, pernyataan tertulis
menjelaskan layanan yang akan disediakan oleh tim proyek . Ini
dapat dijadikan surat perjanjian (letter of intent) atau proposal resmi.
Garis bawahi ini dan anda akan terhindar dari percekcokan yang
tidak pernah berakhir.
5.3. PENINJAUAN PROPOSAL YANG DIKEMBALIKAN
User dapat mengembalikan proposal yang telah diterima dengan

“sedikit” perubahan-perubahan. Waktu yang dijadwalkan untuk
anggota teknis dari tim proyek untuk meninjau sedikit perubahan
susunan kata dapat berarti upaya utama. Masalah harga dapat
dinegosiasikan kembali.

Berhati-hati untuk tidak setuju pada kondisi dan persyaratan. Biarkan

manajemen tingkat tinggi atau departemen yang sah menangani
masalah ini. Jangan memulai pekerjaan sampai seluruh persetujuan
selesai. Akan lebih menguntungkan anda untuk membiarkan user
mengetahui kondisi-kondisi dan persyaratan sebelum menulis
proposal.
5.4. KESIMPULAN UNTUK FASE DEFINISI
Ini akan membawa kita pada akhir fase definisi. Mari kita mengulang
kejadian penting yang pernah dicapai. Ingat kembali kejadian penting
yang digunakan untuk merencanakan proyek dan mengontrol
kemajuan proyek.
1. Dokumen Kebutuhan (RD) yang lengkap dan telah disetujui oleh
kedua belah pihak yaitu Tim proyek dan user.
2. Dokumen proposal dapat digunakan untuk analisis atau seluruh
pengembangan, yang dilengkapi dan dibeli oleh user. Tulis
persetujuan yang diinginkan.
3. Walaupun tidak mempertimbangkan kejadian penting, izin dari
PPP itu dengan menyediakan sumber daya yang diperlukan.

BAB 6
FASE ANALISIS
6.1. PENDAHULUAN
Tujuan dari fase analisis adalah mendefinisikan secara tepat apa

yang dapat dilakukan sistem untuk user, dan bagaimana sistem
tersebut menyesuaikan dengan lingkungan user.
Aktivitas utama (kejadian penting) dari fase ini adalah untuk

menghasilkan dokumen yang menjelaskan arti lingkungan sistem,
disebut Functional Specifications (FS) / Spesifikasi Fungsi.
Setelah mengerjakan FS, anda kini memiliki pengetahuan yang lebih

dibandingkan pada Fase Definisi, sehingga anda harus meninjau
ulang rencana permulaan proyek dan perkiraan awal.
Aktivitas ketiga, menuliskan development proposal / proposal

pengembangan, dan akan dikerjakan jika dua metode proposal akan
dilakukan. Hal tersebut akan ditulis setelah FS. Isi dan garis besar
proposal pengembangan sama dengan proposal analisis, kecuali
bahwa proposal pengembangan dikerjakan dengan menggunakan
lima tahap dari pengembangan.
Dalam fase analisis “Anda harus menghadapi apa yang akan

dilakukan, bukan mengenai bagaimana hal tersebut akan dilakukan,
karena fase disain akan membahasnya”.
6.2. ALIRAN DATA YOURDON / METODE ANALISIS BUBBLE

CHART (THE YOURDON DATA-FLOW/BUBBLE CHART
METHOD OF ANALYSIS)
Edward Yourdon menemukan sebuah metode grafik untuk

mendokumentasikan dan mengendalikan proses analisis yang
menjadi sangat populer (Referensi 11). Berikut ini (gambar 6.1)
adalah sebuah aplikasi dari metode tersebut untuk proyek ABC.

Gambar 6.1. Analisis Yourdon

Pendefinisian User
Analis bersama-sama dengan user mengembangkan diagram seperti

pada gambar 6.1. Mereka mulai dengan membuat daftar semua user
yang akan memiliki hubungan dengan sistem. Termasuk user tidak
langsung seperti STUDENT.
Kemudian mereka menggambar garis panah untuk semua input dari

dan output untuk masing-masing user, garis diberi nama dengan
informasi atau data yang melewatinya.
Garis panah tersebut mewakili aliran informasi (STUDENT →

REGISTRAR melalui telepon), aliran data (REGISTRAR →
COMPUTER lewat terminal) atau kejadian perpindahan secara fisik
dari bagian-bagian (WAREHOUSE → CLASSROOM ships material).
Inilah sebabnya mengapa diagram ini disebut diagaram ‘aliran data’.

Kemudian analis dan user mengidentifikasi informasi umum yang
disimpan oleh sistem (informasi kursus, informasi murid, informasi
material) dan menuliskannnya ke dalam lingkaran.
Pendefinisian Antarmuka User
User dan Analis menjelaskan setiap bagian yang diwakili oleh garis
panah, yang merupakan aliran data antara user dan sistem. Hal ini
akan mengontrol penjelasan mengenai semua menu, formulir,
laporan, perintah-perintah dan pesan-pesan – dengan kata lain
merupakan ‘tampilan antarmuka user’ pada sistem.
Tujuan dari proses ini adalah :
• Pertama untuk menjelaskan tampilan antarmuka pada komputer.
• Kedua untuk memperoleh pemahaman yang umum dari bisnis
user. Seringkali user belajar mengenai bisnisnya sendiri dari tipe
analisis ini.
Sebagai contoh, analisis dari aliran data STUDENT ke REGISTRAR

akan dihasilkan sebagai berikut :

STUDENT → REGISTRAR and REGISTRAR → STUDENT

Method : Verbal over phone, or mailed in
Inquiries
Location, dates of courses
Number enrolled/maximums
Cost
……….
Responses
Course locations, dates (next 6 months)
Number enrolled (next 6 months); maximum allowed
Cost
……….
Changes
Update name, address, payment information of student
Cancel a student from a course
Register a student
Obtain and enter name, address, course (by number)
Payment information
Performance
Must handle up to 3 calls per minute
Analisis terhadap REGISTRAR → ABC akan menghasilkan :
REGISTRAR → ABC
Method : Terminal input
Automatic registrar menu
When registrar logs in with specific account number, menu of
The format in the Functional Specification Figure 3.9. is presented.
To make a choice on this menu, the registrar can use either the UP
and DOWN arrows keys followed by RETURN, or move the mouse up
or down, followed by press on mouse button.
If student wishes information on course
Registrar chooses 1.
Menu of format FS Fig. 3.10 appears.
If student wishes to enroll…..

Langkah berikutnya adalah merinci seluruh menu, formulir, laporan

dan perintah yang tepat. Semua menu seperti REGISTRAR dan
pertanyaan mengenai kursus harus dijelaskan.
6.3. SPESIFIKASI FUNGSI (THE FUNCTIONAL SPECIFICATIONS / FS)
FS menjelaskan semua tingkah laku sistem dalam bentuk cerita dan

gambar. Definisikan antarmuka user seperti di atas, menu-menu,
perintah-perintah, respon, laporan dan pesan-pesan dijelaskan
sebanyak mungkin. Setiap perubahan di dalam lingkungan user
karena sistem baru akan dijelaskan. Semua pengiriman, termasuk
hardware, software, pelatihan, dokumentasi dan garansi dirinci.
Sebagai tambahan pada proposal, FS juga merupakan kontrak

antara User dengan Tim Proyek (PT). Sejumlah uang yang besar
mungkin dipertaruhkan, dan user membutuhkan lebih rinci tantang
apa yang dapat diberikan dibandingkan apa yang ada di proposal. FS
mungkin akan dinegosiasikan dan ditinjau kembali, dan ketika
persetujuan dicapai proposal harus ditanda tangani oleh kedua belah
pihak.
Garis Besar FS (Outline of the FS)

(Lihat Appendix A untuk contoh keseluruhan)
1. Judul Halaman (Title Page)

Judul fungsi spesifikasi, nama sistem, pembuat, dan tanggal
Jangan lupa nomor versi : dokumen ini akan direvisi !
2. Daftar Isi (Table of Contens)

Nama bagian, berikut nomor halaman
3. Gambaran Sistem / Ikhtisar Sistem (System Overview)

Menjelaskan sistem yang akan dibuat. Ingatlah bahwa FS adalah
dokumen teknik yang ditujukan untuk pembaca non teknis
(user). Cara terbaik untuk menjelaskannya dengan menggunakan
gambar.

Marilah kita ambil contoh sistem Amalgamated Basketweaving

Course (ABC) yang dijelaskan di awal. Sistem berdasarkan data
mengenai kursus (Course) dan murid (Student). User
membutuhkan keterangan yang pasti mengenai data pendaftaran,
kursus yang masih dibuka/tersedia, jadwal, rincian akuntansi, dsb.
User juga membutuhkan kemampuan untuk merubah data. User
membutuhkan laporan yang dihasilkan, seperti faktur, konfirmasi,
jumlah murid yang mendaftar. Semua bagian ini harus ada
antarmukanya dengan user, sehingga sebaiknya dibuatkan sistem
menu menggunakan mouse. Untuk menjelaskan semua ini, anda
sebaiknya mulai dengan diagram seperti pada gambar 6.2.
Gambar. 6.2. Major functions of the system.

4. Tujuan Utama (Major Objectives)

Buatlah daftar tujuan sistem, hubungkan masing-masing ke modul
utama. Contoh INQUIRY akan menjawab pertanyaan seperti
“Berapa banyak murid yang mendaftar kursus”.
Menjelaskan bagaimana sistem yang baru akan mempengaruhi

lingkungan user, yaitu dimana terminal akan ditempatkan, siapa
yang menggunakannya, laporan apa yang akan dibuat, kapan dan
bagaimana hal ini akan mengubah pekerjaan setiap orang. Anda
harus memperingatkan user apabila sistem ini akan
mempengaruhi berbagai aspek kehidupannya.
5. Kebutuhan Khusus Sistem (Special System Requirements)

Bagian ini menunjukkan kebutuhan-kebutuhan sistem seperti
jaringan, kesesuaian, keamanan, ketahanan, dan kemudahan
dalam menggunakan sistem.
Persoalan yang rumit seperti respon (jumlah waktu dalam detik

yang dibutuhkan komputer untuk menjawab), throughput (jumlah
total pekerjaan yang diselesaikan komputer dalam jangka waktu
tertentu) dan growth / perkembangan (kebutuhan sistem untuk
beberapa tahun ke depan) dapat ditunjukkan disini.
Sebagai contoh bagaimana jika RD berisi pertanyaan seperti :

“Sistem harus memberikan respon untuk setiap input dalam 5
detik”. Sebuah komputer tercepat yang pernah dibuat sekalipun
membutuhkan waktu lebih dari 5 detik untuk merespon berbagai
permintaan.
Demikian pula jangan menjanjikan dengan pasti mengenai

throughput atau growth. Janji-janji yang pasti dapat diberikan pada
sejumlah hal, seperti jumlah user, ukuran file, transaksi per-menit,
atau pengembangan hardware, akan tetapi hal-hal tersebut
mungkin sulit dipenuhi pada waktu penerimaan.
6. Deskripsi Komponen (Component Descriptions)

Bagian ini menjelaskan secara detail masing-masing isi kotak,
atau fungsi yang terdapat pada gambar 6.2.

Jangan menjelaskan file yang berorientasi informasi seperti

organisasi file, record dan field – semua itu sudah ada dalam
disain. Lakukan pernyataan yang menunjukkan batasan, seperti
jumlah maksimum kursus yang dapat ditangani oleh sistem.
7. Pengiriman yang lain (Other Deliverables)

Dokumentasi. Menyatakan jumlah dokumen yang dihasilkan,
pembaca yang diharapkan, dan kegunaannya.
User’s Guide sebaiknya menyediakan 2 tujuan :

• Pertama, sebagai alat pembelajaran
• Kedua, sebagai referensi dengan petunjuk seluruh perintah dan
pesan yang akan disajikan secara alphabet.
Pelatihan. Buatlah daftar modul-modul atau topik-topik yang

menjadi cover pada masing-masing kursus, dan materi pelatihan
yang digunakan.
8. Perubahan Spesifikasi (Specification Changes)

Perubahan FS mungkin menyebabkan perubahan ke seluruh item-
item yang lain, yang menyebabkan biaya menjadi mahal dan
penundaan waktu pengiriman. Perubahan harus diminimalkan.
9. Penerimaan (Acceptance)
Salah satu masalah terbesar dalam dunia software adalah user
kadang-kadang enggan untuk menerima dan membayar sistem
tersebut. Oleh karena itu dalam FS kita rinci metode penerimaan,
dan mengakhirinya dengan baik.
10.User dan Interface Tim Proyek

(User and Project Team Interface)
User dan Tim proyek harus saling berkomunikasi pada level teknik
maupun manajemen. Kebutuhan secara teknik dari User
diperlukan saat Tim proyek memerlukan jawaban yang cepat dan
akurat berbagai pertanyaan yang bersifat teknik. Berbagai
pertanyaan ini tidak selesai hanya pada fase analisis, tetapi akan
semakin kompleks saat proyek dilaksanakan. Sebaiknya user
menunjuk paling sedikit satu orang yang dapat menjawab
pertanyaan-pertanyaan tersebut.

User dan Tim proyek harus berkomunikasi pada level manajemen

dengan baik. Hal ini harus dilakukan paling tidak oleh Proyek
Koordinator User dan Manajer proyek. Mereka akan
mendiskusikan berbagai isu seperti pendanaan, jadwal,
perubahan-perubahan, dan masalah-masalah sumber daya
manusia.
11.Tanggung Jawab User (User’s Responsibilities)

Untuk menghemat uang dan waktu, atau jika user berharap
dilibatkan lebih banyak, Tim proyek mungkin meminta kepada user
untuk mengerjakan tugas-tugas proyek, seperti menyediakan data
test, menulis User’s Guide, atau bahkan merencanakan
acceptance test. Buatlah daftar seluruh kegiatan dan batas
waktunya. Ingatkan user untuk menandatangani dokumen ini.
12.Istilah, Kondisi dan Asumsi

(Terms, Condition anda Assumptions)
Buatlah daftar aturan baru dan kebijaksanaan yang harus dipatuhi
semua orang.
6.4. TEKNIK PENULISAN UNTUK PEMBACA NON TEKNIS

(TECHNICAL WRITING FOR THE NON-TECHNICAL READER)
Untuk menulis FS yang baik memang sulit sekali. Jika FS

menjelaskan sebuah sistem teknis, maka disebut dokumen teknis,
tetapi FS ini ditulis untuk pembaca non teknis. Tulislah dari sudut
pandang user – gunakan terminologinya. Untuk itu anda harus
mempelajari bisnis user dan bahasanya.
Alasan terbesar yang menyebabkan kesalah pengertian dokumen

adalah kata-kata yang memiliki dua arti. Hal yang sama, hindari janji-
janji yang sulit untuk dilakukan.

6.5. KEGUNAAN LAIN UNTUK SPESIFIKASI FUNGSI

(OTHER USES FOR THE FUNCTIONAL SPECIFICATION)
FS yang baik dapat digunakan untuk memperkenalkan proyek

kepada anggota Tim proyek yang baru. User dapat menggunakannya
untuk memperkenalkan sistem yang baru ke pihak manajemen, atau
ke bagian-bagian lain. Tetapi yang paling penting adalah bagian-
bagian yang menjelaskan menu, form, query, dan report dapat
digunakan dalam User’s Guide.
6.6. CASE SOFTWARE TOOLS UNTUK ANALISIS

(CASE SOFTWARE TOOLS FOR ANALYSIS)
Computer Aided Software Engineering (CASE) digunakan sebagai

suatu paket software tools pada masing-masing fase dari daur hidup
sistem. Terdapat beberapa produk software yang mutunya bagus
yang membantu anda untuk melakukan analisis. Contohnya
Excelarator. Excelarator dapat digunakan untuk menggambarkan
Data Flow Diagram (DFD) tingkat tinggi, seperti pada gambar 6.2.,
kemudian memecah DFD ke level-level berikutnya yang lebih rendah.
Peralatan analis menyediakan menu, layar, dan fasilitas laporan dari

gambar untuk membantu menjelaskan kepada user. Input dan output
pada layar dapat digambarkan dengan menggunakan mouse input.
Laporan query dapat secara cepat ditampilkan.
Lihat Gambar 6.3. Excelarator report mock-up
Pada mini komputer, alat seperti DECDESIGN mendukung fase

analisis dengan menggambarkan DFD atau Entity Relationship
Diagram (ERD), seperti pada saat menggambar Structure Chart dan
Diagram State Transition.
Lihat Gambar 6.4. DECDESIGN Entity Relationship Diagram



6.7. MENINJAU KEMBALI PERENCANAAN (REVISING THE PLAN)
Perencanaan adalah proses pengulangan. Lakukan perbaikan PPP

segera setelah analisis dilakukan. Apakah tugas-tugas masih dapat
diperkirakan, ditentukan, dijadwalkan, dan diselesaikan ? Yang paling
penting adalah tanyakan apakah sumber daya yang diperlukan untuk
masing-masing tugas masih tersedia ketika dibutuhkan ?
Berikut ini adalah daftar pendek dari masalah-masalah yang dapat

terjadi dalam tiga fase berikutnya (Design, Programming, System
Test), selama pelaksanaan rencana berikutnya :
• Programmer kunci atau perancang mengundurkan diri.
• Komputer pengembangan tidak tersedia.
• Peralatan hardware yang khusus tidak ada / terwujud tepat pada
waktu dibutuhkan.
• Paket software dengan release terbaru (atau hardware) tidak
bekerja.
• Sumber daya yang disediakan oleh pihak ketiga tidak terwujud.
Rencana Pelatihan Untuk Anggota Proyek

(Training Plans For The Project Members)
Ketika akhirnya staf telah diputuskan, lakukan pemeriksaan untuk

melihat siapa-siapa saja yang membutuhkan pelatihan. Programmer
anda merupakan calon yang paling memungkinkan. Jadwalkan
semua pelatihan yang akan dilakukan pada akhir disain.
6.8. KESIMPULAN DARI FASE ANALISIS
Diharapkan FS dinegosiasikan atau ditinjau kembali; jadwalkan waktu

untuk persetujuan dan perbaikan. Atur batas akhir penyelesaian. Jika
tidak disetujui diantara individu-individu atau departemen-departemen
menyebabkan ‘analysis paralysis’, ambil satu orang dari tiap
departemen dan kumpulkan dalam satu ruang dan tekankan untuk
tidak menunda pertemuan sampai masalah terpecahkan.

Dan yang terakhir, kita tinjau kembali kejadian-kejadian utama dalam

fase analisis :
1. Spesifikasi Fungsi (FS) yang disetujui dan ditandatangani oleh

kedua belah pihak.
2. Jika kedua langkah proposal digunakan, Development Proposal

telah ditulis dan dibeli oleh user.
3. PPP diperbaiki untuk memasukkan perhitungan-perhitungan baru

dan jadwal-jadwal; sumber-sumber masih dijalankan untuk seluruh
kegiatan.
4. Disain tingkat atas (The Top Level design / TLD) telah dilakukan.
Hal ini mungkin tidak jelas, tetapi anda harus mengerjakan TLD
ketika anda menemukan gagasan dan menggambarkan gambar
6.1. Ini mungkin bukan TLD terbaik, meskipun pada akhirnya akan
digunakan juga, tetapi itu merupakan terobosan pertama
bagaimana sistem akan bekerja dan bagian utama yang akan
diproduksi.

BAB 7
FASE DISAIN
7.1. PENDAHULUAN
Aktivitas utama dalam Fase Disain adalah membuat top dan medium
level dari disain sistem dan mendokumentasikannya dalam
Spesifikasi Disain. Aktivitas kedua dimulai dengan melakukan
Rencana Test Penerimaan (Acceptance Test Plan / ATP).
ATP adalah sebuah dokumen tes yang akan digunakan untuk

mendemonstrasikan seluruh fungsi sistem kepada user pada fase
penerimaan.
Terdapat dua langkah dalam mendisain sistem software, yaitu :

• Pertama, bagilah sistem menjadi beberapa komponen secara
fungsional.
• Kedua, hubungkanlah komponen-komponen tersebut.
7.2. DISAIN YANG TERSTRUKTUR (STRUCTURED DESIGN)
Tujuan utama dari disain yang terstruktur adalah memecah sistem

menjadi bagian yang lebih kecil, teratur dan mudah untuk dibangun.
Disain Top Down (Top Down Design)
Disain Top Down dimulai dengan Top Level Design (TLD).
Lihat Gambar 7.1. Top Level Design
Masing-masing komponen utama atau kotak dalam TLD dipecah

menjadi sub-bagian dimulai dengan level teratas, kemudian turun ke
level berikutnya, dst.
Dalam kasus ini, dimulai dengan MENU dan mendisainnya sebelum

turun ke INQUIRY, UPDATE, dan REPORT GENERATION, yang
akan diikuti dengan tingkat selanjutnya, jika ada.

Disain Bottom Up (Bottom Up Design)
Pada kasus tertentu mungkin akan lebih mudah mendisain dengan

menggunakan pendekatan dari level bawah / rendah ke level atas.
Hal ini sering ditemui pada kasus sistem pengontrolan proses dimana
perlatan pengontrolan hardware pada level terbawah menentukan
bagaimana sistem tersebut disatukan (integrasi sistem).
Contoh :
Kita akan mendisain sebuah sistem pengujian mesin kendaraan. Kita
harus mulai dengan menentukan hardware dasar atau komponen
dasar yang terlibat – sensor mesin.
Lihat Gambar 7.2A. Bottom Up Design
Sensor umumnya dipasang pada alat digital atau analog, yang

terpasang pada modul software pengendali (drivers) alat yang unik.
Lihat Gambar 7.2B. Bottom Up Design (lanjutan)
Software yang digunakan untuk mengontrol alat pengendali / drivers

kemudian didisain di atas pengendali-pengendali tersebut.
Lihat Gambar 7.2C. Bottom Up Design (lanjutan)
Demikianlah sistem software didisain dari level bawah ke atas. Disain

Bottom Up juga sangat cocok digunakan pada kasus dimana
komponen software yang ada digabungkan dan disatukan dengan
modul baru untuk membangun sebuah sistem.
7.3. PERTUKARAN DISAIN TINGKAT ATAS

(TOP LEVEL DESIGN TRADE – OFFS)
Umumnya banyak disain tingkat atas yang dapat mencapai atau

memperoleh hasil yang sama dalam sebuah sistem software.

Contohnya, disain tingkat atas (top level) pada gambar 7.1. hanya
salah satu cara untuk memecahkan sistem ABC kedalam komponen-
komponen utama.
Keputusan untuk membangun sendiri atau membeli merupakan

keputusan yang khusus. Ada keuntungan dan kerugian pada setiap
kombinasi dari item yang dibangun maupun yang dibeli.
Semakin banyak paket program yang anda beli, semakin berkurang

pemrograman yang harus anda lakukan. Keputusan untuk membeli
paket program lebih mudah dibandingkan harus membuat sendiri,
akan tetapi lebih mahal, dan umumnya kurang efisien dibandingkan
dengan program tertulis biasa yang sama.
Disain tingkat atas yang lain ada juga yang cocok. Salah satu
masukkan mungkin adalah menghilangkan INQUIRY, UPDATE dan
REPORT GENERATION dan menggunakan rutin FILE HANDLER
yang umum untuk melakukan semua kegiatan akses file. TLD akses
tersebut seperti pada gambar 7.3.
Lihat Gambar 7.3. (Another) Top Level Design
Disini ada lima program yang harus dibuat dan sedikit penurunan
kinerja akan terlihat oleh karena pemanggilan yang sering pada FILE
HANDLER, tetapi sistem akan menjadi lebih kecil. Setiap pilihan TLD
memilki keuntungan dan kerugian dan melibatkan pertukaran dan
kompromi.
Prioritas Disain (Design Priorites)

Pilihan TLD anda akan mempengaruhi hal-hal berikut ini :
• Biaya Sistem (System Cost)
• Waktu yang diperlukan untuk membangun sistem (Time to Build
The System)
• Sifat mudah dipakai (User Friendliness)
• Kinerja (Performance)
• Ukuran Sistem (System Size)
• Kehandalan (Reliability)
• Kemampuan modifikasi (Modifiability)

Item-item ini harus menjadi prioritas, bersama dengan user pada

waktu perencanaan sistem, pada saat pendefinisian dan analisis. Ini
akan membuat pilihan TLD jauh lebih mudah.
7.5. DISAIN TINGKAT MENENGAH (MEDIUM LEVEL DESIGN)
Setelah TLD terpilih, kita harus membagi masing-masing fungsi atau

komponen utama menjadi beberapa sub fungsi atau komponen. Kita
akan lihat bagaimana hal tersebut dilakukan untuk menggabungkan
sistem perusahaan Basketweaving. Diawali dengan memberi nomor
setiap komponen utama pada TLD.
Lihat Gambar 7.4. Numbering System for the TLD
Disain top down ini dimulai dengan kotak menu. Diasumsikan bahwa
komponen ini dipanggil ketika seluruh sistem dimulai dan
menampilkan menu utama ke bagian register.
Lihat Tampilan Menu Utama
Kemudian program menunggu user untuk memindahkan mouse.
Sub fungsi utama komponen MENU adalah :

1. Memulai sistem dan menampilkan main menu
2. Menangani perpindahan mouse
3. Menangani tombol pada mouse
4. Pindah ke Menu INQUIRY, UPDATE, WAREHOUSE atau
REPORT ketika dipilih
5. Menangani kesalahan-kesalahan seperti pada on line help
messages untuk seluruh sistem
6. Mematikan sistem jika QUIT dipilih
Struktur diagram tingkat selanjutnya atau diagram rinci untuk

komponen MENU akan tampak seperti berikut ini.
Lihat Gambar 7.5. Rincian Level Kedua

Level terendah dari suatu menu menggambarkan modul. Sebuah

modul adalah bagian terkecil yang dapat ditest dan dicompile.
Aturan Penamaan (Naming Conventions)

Modul diberi nama untuk menunjukkan sistem, fungsi atau subfungsi
yang diperlukan.
Aturan Penomoran (Numbering Conventions)

Nomor pada setiap kotak disusun dengan aturan sebagai berikut :
Pada tiap-tiap tingkat terendah tambahkan sebuah titik dan angka
bulat untuk nomor yang terletak di atas kotak. Angka bulat tersebut
diurutkan dari kiri ke kanan.
7.6. KAMUS DISAIN (DESIGN DICTIONARIES)
Modul Kamus (Module Dictionaries)
Dictionary 1
Berdasarkan urutan angka sesuai dengan nomor komponen, berikan
nama yang tetap, dan penjelasan singkat untuk setiap modul.
Contoh :
0.0 A0000000 Amalgamated Basketweaving System
1.0 AM000000 Menu System
1.1 AMST0000 Startup, disp first menu, shutdown, etc.
Dictionary 2
Berdasarkan urutan alphabet dengan nama komponen, berikan
nomor yang tetap, dan penjelasan singkat untuk setiap modul.
Contoh :
A0000000 0.0 Amalgamated Basketweaving System
AM000000 1.0 Menu System
AMST0000 1.1 Startup, disp first menu, shutdown
Dictionary 3
Berdasarakan urutan alphabet dengan penjelasan singkat, berikan
nomor komponen dan nama yang tetap.

Contoh :
Amalgamated Basketweaving System 0.0 A0000000
Menu System 1.0 AM000000
Startup, disp first menu, shutdown 1.1 AMST0000
Kamus Data Umum (The Common Data Dictionary / CDD)
Daftar alphabet menyusun semua parameter yang ditunjukkan pada

tanda panah aliran data. Untuk setiap item menjelaskan tipe,
panjang, batasan, dan modul yang digunakan. CDD ini kemudian
akan berisi semua parameter lainnya yang didefinisikan pada level
terendah dari pemrograman dan disain, sebagaimana field
didefinisikan dalam sebuah file. CDD menjamin bahwa parameter
akan konsisten berlaku dlam seluruh sistem.
7.7. MODUL TERSTRUKTUR, ATAU SEJAUH MANA ANDA

DAPAT MERINCINYA ?
(Structured Modules, Or How Far Do You Break It Up ?)
Sebuah modul terstruktur memiliki ciri-ciri sebagai berikut :

1. Berfungsi sepenuhnya sebagai fungsi tunggal.
Misalnya dapat diterima, diedit, diformat ulang dan melewati
parameter tunggal.
2. Ukurannya kecil.
Ukuran yang ditetapkan berkisar antara 50 – 100 baris yang dapat
dieksekusi atau paling banyak 2 halaman.
3. Dapat diprediksi.
Semua ciri dapat terlihat dengan membaca kode program. Hal ini
tidak dipengaruhi oleh kode tersembunyi dalam modul lain atau
dalam sistem operasi.
4. Tidak tergantung (Independent)

Perubahan dalam modul atau parameter tidak mempengaruhi
sistem.

5. Meskipun hal ini tidak didefinisikan secara jelas dalam modul

terstruktur, lihatlah kegunaannya kembali – suatu modul yang
cukup lengkap dan umum mengakibatkan anda dapat
menggunakannya pada aplikasi lain dengan memodifikasi sedikit
mungkin.
7.8. DISAIN FILE (FILE DESIGN)
Dapatkan kinerja yang sesungguhnya (Getting Real Performance)
Anda mulai mendisain file dengan melihat hasil dari fase analisis,
kebutuhan-kebutuhan dan disain level atas yang sejauh ini
dihasilkan. Hasilnya akan tampak seperti item-item kotak pada
gambar 7.6.
Lihat Gambar 7.6. Data Types
Sebagai contoh, persyaratan “Pendaftaran seorang siswa pada

kursus tertentu” akan menghasilkan penambahan dalam daftar field
disamping masing-masing kotak pada gambar 7.6.
Jika STUDENT INFO dan COURSE INFO adalah file yang terpisah,
mereka akan dihubungkan dengan sebuah key. Tambahkan key
STUD_NO dan CRS_NO dan logika akses dapat digambarkan
dengan tanda panah, seperti pada gambar 7.7.
Lihat Gambar 7.7. Data types, keys dan access
Sekarang kita dapat menangani pendaftaran siswa sebaik-baiknya,

seperti : “Memberikan nama siswa, mencari kursus apa saja yang ia
ikuti” (akses file STUDENT FILE dengan nama, kemudian CRS_NO,
lihat COURSE FILE dengan CRS_NO tersebut). Diagram dilanjutkan
sampai semua pernyataan terpenuhi. Hasilnya dapat digambarkan
pada gambar 7.8.
Lihat Gambar 7.8. Data types, key and access

Mengoptimalkan File (Optimizing Files)
Langkah selanjutnya adalah mengoptimalkan penyimpanan disk

dengan mengurangi kerangkapan field-field dan file-file.
Pada STUDENT FILE, jika banyak siswa mempunyai alamat yang

sama, seperti perusahaan yang sama, field alamat akan terulang.
File ADDRESS dengan satu record setiap perusahaannya dan
COMPANY_NO di record siswa menunjukkan hal itu. File ini juga
dapat berisi alamat faktur yang dibutuhkan oleh FINANCE FILE.
Pada COURSE FILE item seperti DESCRIPTION, INSTRUCTOR,
dan MATERIAL NO akan selalu terulang setiap mereka kursus di
tempat yang sama. Kemudian file ini dipecah menjadi file baru yang
bernama SCHEDULE FILE yang mempunyai item unik untuk setiap
kursus yang dimulai, dan membiarkan COURSE FILE hanya sebagi
informasi.
FINANCE FILE hanya dapat ditandai dengan STUD_NO atau

COURSE_NO. Sudah ada beberapa file yang menggunakan key
tersebut, yang biasanya menunjukkan field tersebut dalam file ini
dapat digabungkan ke dalam file lain, jika informasi pembayaran dan
tagihan akan digabungkan dengan siswa. FINANCE FILE tidak
diperlukan. Hasil disain file dapat dilihat pada gambar 7.9.
Lihat Gambar 7.9. Data types, key and access
Mengoptimalkan Sejumlah Variabel Item-item

(Optimizing a Variable Number of Items)
Dalam STUDENT FILE terdapat 2 field, informasi CRS_NO dan

PYMNT, yang diulang untuk masing-masing kursus dari siswa yang
mendaftar. Dengan cara yang sama akan diulang field-field dalam file
SCHEDULE dan COURSE. Hal ini dapat diatasi dengan membuat
program yang menggunakan file yang mempunyai ukuran yang
berubah-ubah. Panjang dari sebuah record berubah sesuai dengan
penambahan maupun penghapusan sebuah item. Metode ini dapat
menghemat ruang penyimpanan.

Dalam hal lain, jika jumlah maksimum dari suatu variabel diketahui,
maka dapat digunakan record yang memiliki panjang yang tetap.
Sebagai contoh, jika suatu bidang kursus tidak akan pernah diambil
oleh lebih dari 30 siswa, maka jumlah record di file SCHEDULE
disediakan untuk 30 siswa. Metode ini menggunakan ruang
penyimpanan yang lebih besar dari metode pertama, namun metode
ini membutuhkan waktu proses yang lebih singkat. Selain itu record
dengan ukuran tetap lebih mudah untuk didisain, dimengerti, dan
dalam hal pemeliharaannya dibandingkan dengan record yang
memiliki panjang yang berubah-ubah. Karena harga media
penyimpanan yang semakin murah saat ini, maka disarankan untuk
menggunakan record yang memiliki ukuran tetap jika memungkinkan.
Sebuah masalah dapat muncul jika batasan tidak dapat ditentukan.

Sebagai contoh, Mengapa jumlah siswa di setiap bidang kursus tidak
dapat dibatasi dengan jumlah yang sama ? Untuk mengatasi hal ini
dapat dibuat suatu file lain yang hanya digunakan untuk menyimpan
informasi yang tidak tetap. File ENROLLMENT dapat dibuat untuk
setiap bidang kursus, dan setiap file akan berisi satu record per satu
siswa yang mendaftar per kursus, seperti pada gambar 7.10. Hal ini
mungkin membutuhkan biaya yang besar, baik dalam hal media
penyimpanan maupun pemeliharaan file.
Lihat Gambar 7.10. Handling variable information
Cara sederhana untuk menangani masalah tersebut adalah dengan

membuat sebuah file yang disebut ENROLLMENT yang akan berisi
record untuk setiap siswa yang mendaftar per kursus. Field-field yang
digunakan hanya STUDENT_NO dan COURSE_NO.
File Histori (History Files)
Apa yang kita lakukan tentang data pada siswa-siswa yang telah
mengambil sebuah kursus ? Pemecahan masalah ini dengan
mendefinisikan sebuah file STUDENT_HISTORY dan setelah
seorang siswa mengambil sebuah kursus, recordnya dipindahkan
dari file STUDENT ke File Histori.

Pengujian Disain File (Testing The File Design)

Pada disain ini, setiap permintaan kebutuhan yang melibatkan
pengaksesan data harus “diproses” dengan disain file. Hal ini
menandai perkembangan selanjutnya.
Contoh :
“Tampilkan semua peristiwa pada tempat pelatihan XYZ, lokasi dan
biayanya”. Mari kita mengikuti logika pengaksesannya. Register
mengubah nama bidang kursus menjadi CRS_NO. Record-record
pada file SCHEDULE diakses oleh CRS_NO untuk mendapatkan
biaya. Dalam permintaan yang umum seperti ini, mungkin nama
bidang kursus dapat dijadikan “key” pada file SCHEDULE. Mungkin
harga dapat ditambahkan ke file SCHEDULE untuk mengurangi
pengaksesan file COURSE setiap waktu. Untuk menghemat ruang
penyimpanan, kode biaya dapat digunakan.
7.9. SISTEM MANAJEMEN DATA BASE RELATIONAL

(RELATIONAL DATA BASE MANAGEMENT SYSTEM / RDBMS)
Pada bagian 7.8. kita mengasumsikan bahwa anda mendapatkan

sebuah record dari sebuah file yang mengandung sebuah kunci.
Dalam kenyataannya, harus terdapat DBMS untuk memenuhi hal ini.
Gambar 7.11 adalah contoh dari suatu relasi (tabel) yang dapat
didefinisikan pada sistem ABC.
Student Relations :
Stud-No Stud-Name Company-No
1 John Blake 999
2 Jane Smith 999
Run of a Course Relations :

Course-No Course-Date Location Instructor Cost
123 1/1/90 Ottawa Rakos 1000
123 1/2/90 New York Rakos 1500

Enrollment Relations :
Course-No Stud-No Pymnt
123 1 0
Course Relations :
Course-No Crs-Name Desc Mat-No
123 Weaving Intro 001
Company Relations :
Comp-No Addr Ship-To Bill-To Tot-Owing
999 First ST. X Y AB 10000
Material Relations :
Mat-No Desc Whse Source Cost
001 Straw 1-1 X Co 1.00
Gambar 7.11 Relasi pada Data Base Relational ABC
Bentuk untuk jenis database query khusus ini sudah distandarisasi,

dan ini disebut Structured Query Language (SQL). Sebagai contoh,
berikut ini adalah instruksi SQL untuk menampilkan kursus apa saja
yang diikuti oleh “Smith”.
SELECT CRS-NAME FROM COURSE

WHERE COURSE-NO IN
SELECT COURSE-NO FROM ENROLLMENT
WHERE STUD-NO IN
SELECT STUD-NO FROM STUDENT
WHERE STUD-NAME = ‘Smith”
Sayangnya SQL yang dibuat oleh IBM memiliki banyak kekurangan

sehingga produk-produk baru mempunyai perluasan bahasa untuk
menyediakan keistimewaan tambahan. Anda dapat melihat banyak
bahasa 4GL yang baru (yang mendukung Query By Example [QBE])
untuk mengisi formulir di bawah ini :

STUD_NAME = Smith
CRS_NAME = ---------------
---------------
---------------
---------------
“
“
Kelebihan utama dari RDBMS adalah fleksibilitasnya.

Sebagai contoh : jika kita ingin mengakses data yang sejenis secara
berlainan dari berbagai aplikasi, maka sistem ini akan dapat
menampungnya.
Kekurangan RDBMS hanya pada performance. Membutuhkan

banyak memori dan waktu untuk menyimpan, menjalankan dan
merinci seluruh bagian tabel.
Penghematan waktu yang diakibatkan oleh pemakaian yang mudah

dan fleksibilitas dari sistem, membuat RDBMS yang terdapat pada
sebuah komputer (CPU) yang baik sebagai investasi yang berharga.
7.10. KEUNTUNGAN DARI ANALISIS & DISAIN YANG TERSTRUKTUR

(BENEFITS OF STRUCTURED ANALYSIS AND DESIGN)
Mengurangi Jumlah Kesalahan

(Reducing the Number Of Initial Errors)
Tabel statistik berikut ini diambil dari hasil survei oleh TRW untuk
proyek besar, dan DEC’s Customer Services Systems Engineering
(yaitu departemen yang bertanggung jawab untuk memastikan
bahwa produk-produk DEC baik software maupun hardwarenya
benar-benar bebas dari virus).

Menggunakan metode tidak terstruktur :
Analysis and Remaining After

Design Phase Operation
Effort Spent : 10 % 23 % 67 %
Problem Introduced : 64 % 36 %
Problems Found : 19 % 27 % 54 %
Dollars Spent (AVG) 25 K 57.5K 167.5 K
(Total = 250 K)
Menggunakan metode terstruktur :
Analysis and Remaining After

Design Phase Operation
Effort Spent : 20 % 50 % 30 %
Problem Introduced : 32 % 68 %
Problems Found : 30 % 33 % 37 %
Dollars Spent (AVG) 40 K 50 K 100 K
(Total = 190 K)
(1) Bagan di atas adalah setengah dari biaya sebelumnya
Gambar 7.12. Causes and costs of problems
Gambar 7.12 menunjukkan bahwa meskipun biaya dimuka

mengalami kenaikan, metode terstruktur tetap mengurangi biaya
sistem secara keseluruhan.
7.11. PROSES DISAIN (THE DESIGN PROCESS)
Tim Disain (The Design Team)

Pilihlah orang-orang terbaik untuk tim disain. Tim disain yang baik
tidak perlu orang yang menguasai bahasa pemrograman. Mereka
haruslah orang yang dapat mengkonsep semuanya. Hindari orang-

orang yang selalu menginginkan kesempurnaan (perfectionis) dalam

tim disain.
Pertemuan Disain (The Design Meeting)
Merancang sesuatu mirip dengan urun remuk (brainstorming) :
beberapa orang berkumpul dalam suatu ruangan yang tenang dan
tidak terganggu. Setiap orang diharapkan untuk mengeluarkan
semua ide mereka agar semua elemen yang berfungsi dapat
digunakan dan juga memikirkan bagaimana cara menguasainya.
Tulis semua ide yang ada, dan kemudian akhirnya ide-ide yang ada
disusun ke dalam modul-modul yang unik.
7.12. DOKUMENTASI TEKNIK (TECHNICAL DOCUMENTATION)
Pertimbangkan hal-hal berikut ketika menulis dokumentasi teknik :

1. Gunakan bahasa yang formal dan tepat.
2. Gunakan gambar, diagram yang terstruktur dan yang sejenisnya.
3. Buatlah agar maksud dari disain menjadi jelas pada beberapa
halaman pertama. Kemudian uraikan.
4. Cobalah untuk konsisten pada grafik-grafik dan struktur kalimat.
7.13. STANDAR KETENTUAN PADA WAKTU DISAIN

(STANDARDS ‘DICTATED’ AT DESIGN TIME)
Buatlah aturan yang standar seperti berikut :

1. Beberapa ketentuan disain.
Format struktur diagram, modul dan kaidah penamaan variabel ini
digunakan untuk semua tingkatan yang rendah.
2. Parameter yang mendahului.

Rincian perintah, panjang, format / tipe.
3. Penanganan kesalahan.
Setiap modul melewati keadaan dimana kesalahan muncul dan
nomor kesalahan untuk ditangani.

4. Standar pemrograman.
Standar pemrograman terstruktur seperti pemunculan kode (white
space, memasukkan, komentar-komentar), konsep yang
diperbolehkan, organisasi, ukuran modul, dan ketergantungan
secara rinci. Membuat ‘template’ yang berisi komentar seperti :
- judul
- parameter-parameter (penerima, pengirim)
- masukkan (hanya satu)
- variabel yang digunakan
- memanggil subroutine
- penanganan kesalahan
- exit (hanya satu)
5. Programmer memulai dengan template ini dan mengisikan kode

proses. Lihat bagian 9.4 untuk alat pemrograman yang membantu
format program secara tetap.
7.14. GARIS BESAR SPESIFIKASI DISAIN

(OUTLINE OF THE DESIGN SPECIFICATION)
Spesifikasi disain terdiri atas :

1. Judul halaman dan daftar isi
2. Gambaran umum (Overview)
3. Daftar hardware / software yang akan dipakai
4. Daftar urutan prioritas disain
5. Diagram disain dan beberapa modul dictionary yang umum
6. Beberapa kebiasaan penamaan modul yang umum
7. Parameter yang dipakai dan Data Dictionaries
8. Penanganan kesalahan. Jelaskan bagaimana kesalahan akan
ditangani
9. Standar pemrograman terstruktur
10.Alat pemrograman terstruktur
11.Top Level Design. Termasuk struktur diagram TLD
12.Medium Level Design. Termasuk struktur diagram MLD
13.Modul dan kamus data
14. File dan Tabel

7.15. MENGUJI DISAIN (TESTING THE DESIGN)
Ketika disain telah diselesaikan, semuanya harus berjalan dengan

benar. Maksudnya adalah untuk menjamin hal-hal berikut ini :
1. Semua keperluan Spesifikasi Fungsi sudah ketemu.
2. Disain mudah diprogram dan dipelihara.
3. Dapat diimplementasikan sesuai dengan waktu dan anggaran.
7.16. MERUBAH PERMINTAAN SESUAI DENGAN DISAIN

(CHANGES TO REQUIREMENTS DUE TO DESIGN)
Beberapa disain yang rinci akan selalu membawa pada perubahan

permintaan. Anda harus kembali kepada user sekarang dan
meyakinkan user bahwa dia sebenarnya tidak menginginkan apa
yang dia minta sebelumnya.
7.17. PERENCANAAN PENERIMAAN

(PLANNING THE ACCEPTANCE)
Meskipun penerimaan adalah tahapan pada bab tersendiri nantinya,

perencanaan penerimaan dapat dimulai setelah disain level
menengah dikerjakan.

7.4. DISAIN SIAP PAKAI (DESIGN WALK-THROUGHS)

Ketika hendak mengambil keputusan diantara beberapa pendekatan
teknis terhadap suatu masalah, lebih mudah mengambil keputusan
dengan meminta pendapat orang lain.
Adakan pertemuan dengan beberapa ahli untuk melakukan TLD siap

pakai. Tujuan dari pertemuan itu adalah memilih TLD yang terbaik.













Kisah Tentang Perang Disain
Cerita ini melibatkan dua orang pemuda yang menjadi sahabat karib ketika
mereka mengikuti kuliah Ilmu Komputer pada sebuah universitas terkemuka di
Ontario, Kanada. Setelah lulus yang satu menjadi menjadi seorang Manajer
Pemrosesan Data pada sebuah perusahaan penerbitan terkenal, dan yang satu
menjadi seorang perancang sistem pada Famous Minicomputer Manufacturing
Company (FMMC). Beberapa tahun kemudian perusahaan penerbit memutuskan
untuk memasang komputer baru untuk sistem pengolahan. Manajer Pemrosesan
Data tidak mamapu menangani beban pekerjaan itu sendiri, maka ia menyewa
temannya dari FMMC untuk mengerjaka desain dan program.
Setelah mereka mengerjakan top level desain bersama-sama, mereka membagi

modul utama, yang masing-masing mengerjakan desain medium level dari
modul-modul yang spesifik. Perancang dari FMMC mendesain modul yang
pertama. Untuk menunjukkan kehebatan desainnya pada temannya, ia membuat
rancangan itu dengan sangat “bagus” untuk menghemat sedikit byte dari media
penyimpanan atau beberapa nanodetik dari waktu CPU. Ia bahkan
menambahkan sedikit “keistimewaan” tersendiri : sesuatu yang tidak seorangpun
meminta atau mengerti atau pernah menggunakannya.
Si Manajer Pemrosesan Data menanggapinya dengan mendesain modul yang

kedua. Ketika dia melihat rancangan hebat milik temanya, ia mengatakan “saya
dapat membuat yang lebih bagus dari itu”. Lalu ia membuat modulnya sedikit
lebih bagus dari modul temannya, dan menambahkan sedikit “suara bel dan
melodi-melodi” pada modulnya. Ia mengerjakan lebih lama dari jadwal yang
ditentukan dan modulnya menjadi lebih besar dari rencana. Si perancang
tertantang untuk membuat modul yang ketiga yang lebih “sempurna” dengan
menambah lebih banyak lagi suara bel-bel dan melodi sampai modul menjadi
dua kali lebih besar dari seharusnya. Dan perlombaan terus berlanjut sampai
mendesain sebagus mungkin tahap pemrograman.
Sistem tersebut dibuat untuk 16 orang user. Ketika sistem akhirnya berjalan
(50% terlambat) sistem bekerja baik sampai 4 orang user. Ketika 6 orang user
bekerja, sistem menjadi sangat lambat, dengan 8 orang user sistem crash –
program menjadi sangat besar untuk dapat ditangani oleh sistem.
Komentar : Orang teknis dapat terbawa dengan tantangan teknis. Selalu banyak
jalan yang baik untuk menyelesaikan masalah, tapi tantangan harus
menghasilkan tujuan, yaitu waktu dan biaya.
Penutup : FMMC memberikan CPU yang besar kepada perusahaan penerbit

tanpa biaya.

BAB 8
RENCANA TES PENERIMAAN
8.1. PENDAHULUAN
Tujuan dari penerimaan adalah mendapatkan pernyataan tertulis dari

user bahwa produk (dalam hal ini sistem) yang dikirim sesuai dengan
yang dijanjikan.
Mendapatkan persetujuan ini dan pembayaran jika itu adalah proyek

yang dikontrak mungkin akan sulit, kecuali user yakin bahwa sistem
bekerja dengan baik sesuai dengan yang dijanjikan. User mungkin
merasa takut pada penerimaan : dia mengambil ahli kepemilikan dan
tanggung jawab sistem. User mungkin enggan menyerahkan tanda
penerimaannya – apa yang terjadi jika sesuatu salah ?
8.2. PERIODE PERCOBAAN ATAU PARALLEL RUN

(THE TRIAL PERIOD OR PARALLEL RUN)
Periode percobaan atau parallel run adalah pendekatan yang paling

umum untuk penerimaan. Menggunakan pendekatan ‘Periode
Percobaan’ tim proyek mudah memasang sistem baru untuk dicoba
oleh user. Pendekatan ‘Parallel Run’ menambahkan dimensi untuk
peralihan sistem lama yang sudah berjalan dengan baik sebagai
perbandingan dan cadangan.
Dalam kedua kasus ini klien menggunakan sistem baru selama ‘X’
hari. Jika tidak ada masalah maka user menerimanya, jika ada
masalah maka tim proyek berusaha memperbaikinya dan melakukan
kembali percobaan selama ‘X’ hari.
Pendekatan ini cukup mudah, tetapi ada beberapa kekurangan :

1. Masalah kecil dapat membuat anda menjalankan kembali selama
‘X’ hari untuk jangka waktu yang tidak terbatas. Kadang-kadang
sistem software yang rumit tidak pernah 100% di-debug.

2. Mungkin sulit untuk mencari penyebab dari suatu masalah. Jika 10

user berada pada sistem yang interaktif dan sistem tersebut rusak,
ini merupakan tantangan untuk menemukan dengan tepat apa
yang menyebabkan sistem tersebut rusak.
3. Tidak ada jaminan bahwa semua kelebihan sistem akan dicoba

dalam ‘X’ hari. Penulis pernah melihat sebuah sistem akuntansi
yang diterapkan pada awal tahun fiskal baru. Sistem itu berjalan
baik selama masa percobaan (6 bulan) sampai mengalami
kegagalan pada akhir tahun fiskal ketika akuntan mencoba untuk
melakukan tutup buku. Sayangnya garansinya telah habis dan
penjual (vendor) tidak mau memperbaikinya.
4. Biarkan end user masuk ke sistem pada hari pertama yang

penerapannya tidak selalu bermanfaat. Karena dalam hal ini faktor
penampilan lebih berperan. Seperti dalam roman, kesan pertama
sangat penting.
8.3. SOLUSI : PENERIMAAN YANG LENGKAP SEDIKIT DEMI

SEDIKIT
(SOLUTION : A THOROUGH BUT PIECEMEAL ACCEPTANCE)
Pendekatan yang lebih baik adalah menemukan serangkaian tes

yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan
akan dilakukan secara resmi melalui seluruh tes ini kepada
pelanggan. Keberhasilan tes diakhiri satu per satu.
Jika sebuah tes gagal, Tim proyek dengan penuh harapan

memperbaiki masalah langsung di tempat pengujian. Jika itu masalah
utama maka tes ditunda sampai masalah dapat diperbaiki. Dalam
teori hanya tes yang gagal yang diulang, walaupun user memiliki hak
untuk menjalankan kembali tes yang diterimanya sesudah perbaikan.
Serangkaian tes dan perintah yang dijalankan sistem disebut

Rencana Tes Penerimaan (Acceptance Test Plan / ATP).

Pendekatan ini mempunyai manfaat sebagai berikut :

1. Anda dapat mendemonstrasikan semua fungsi yang dijanjikan.
2. Sebuah tindakan yang menyebabkan masalah selalu diketahui –
anda mengetahui dengan tepat siapa yang mengetik ketika
masalah terjadi.
3. User tidak merasa takut tentang semuanya.
Kerugian utama dari pendekatan ini adalah memerlukan banyak

pekerjaan untuk menulis ATP. Dan lagi user mungkin tidak lazim
dengan pendekatan ini. Tetapi anda dapat membiasakan mereka
dengan metode baru sebelumnya.
Cantumkan laporan singkat dalam proposal, yang merupakan sebuah

dokumen yang ditandatangani. Selengkapnya ada dalam Spesifikasi
Fungsi, dokumen lainnya yang ditandatangani. Dia akan selalu
melihat dan menyetujui ATP sebelum penerimaan. Seharusnya tidak
ada keengganan untuk menerima dan membayar jika metode ini
digunakan.
8.4. MEMASTIKAN BAHWA SEMUA YANG DIJANJIKAN AKAN

DIUJI
(ENSURING THAT ALL THE PROMISES ARE TESTED)
Untuk memastikan semua yang dijanjikan akan dites langsung

melalui Spesifikasi Fungsi halaman demi halaman, paragraf demi
paragraf, dan buat daftar semua fungsi yang dapat dites. Perhatikan
tabel seperti gambar 8.1 berikut ini :

FS FUNCTION TO BE TESTED TEST TEST

REF METHOD NUMBER
SEC/PAR
3.1 Main menu appears at start-up T 1.0

3.2 Registrar menu appears when… T 2.1
3.3 Manager menu appears when… T 2.2
7.7 Store 10.000 student records I 7.8
10.2 Students by course by city report T,A 4.5
T – test I – inspection A – Analysis (Hand calc,or use another pgm)

N/A – not applicable
Gambar 8.1. Functions vs tests table
Catatan : ada beberapa hal dalam daftar tersebut tidak dites (N/A).
8.5. MENGGUNAKAN DISAIN (USING THE DESIGN)
Anda mungkin berfikir mengapa saya menyarankan mengerjakan

ATP setelah disain dikerjakan. Sesungguhnya anda hanya
memerlukan Spesifikasi Fungsi untuk menghasilkan ATP. Tetapi,
disain membantu untuk menggelompokkan tes ke dalam serangkaian
tes yang mendemonstrasikan fungsi utama dari sistem.
Anda dapat menjalankan tes pada perintah atas bawah yang sama
seperti TLD, yang dapat dimengerti dengan baik oleh user anda.
Pendekatan sistem ABC seperti dalam TLD (gambar 7.1), anda dapat
mendemonstrasikan semua menu, kemudian seluruh keterangan
yang diminta, diikuti dengan semua update, dsb. Cara lain untuk
mengelompokkan kumpulan tes adalah dengan fungsi. Melalui
semua fungsi Registrasi, diikuti oleh fungsi Administrator, dsb.

8.6. MENULIS PERCOBAAN (WRITING TEST)
Anda sudah siap menentukan bagaimana anda akan menguji item

ketika pengisian pada METODE PERCOBAAN seperti pada gambar
8.1. di atas.
Berikut ini (gambar 8.2) adalah contoh percobaan nomor 4.5.,

laporan ‘Students by Course by City ‘. [Catatan dalam tanda
kurung siku-siku tidak ditampilkan – ini adalah keterangan].

TEST NO: 4.5

TEST PURPOSE: Demonstrate the production of the
Students by Course by City report.
F.S. REFERENCE (SEC/PAR): 10.2, 12.8, 11.3 [Note how one test
can demonstrate several functions.]
SETUP: Ensure files STUDENT.DAT and
COURSE.DAT contain data.Star
system.
INPUT: Choose Selection 1. From Main
Menu using mouse click and drag
method.
OUTPUT: “CHOOSE REPORT TYPE’ menu
(format per FS pg 17, Figure 8.15)
appears. [Refer to the Functional
Spec. whenever possible.]
INPUT: Choose Selection 5. (Students by
Course by CIty report) by UP/DOWN
arrow anda RETURN method.
OUTPUT: Message ‘Report being prepared.’
Appears. No longer than 60 seconds
later, message ‘Report being printed’
appears and printer starts printing.
The terminal can be used to enter
any other command. User will try up
to 3 commands of his choice. [There
is danger in stating, “User may type
any number of commands.”He just
may!] When the report is complete
(printer stops,) inspect it to ensure it
is of format FS pg.23,Figure 12.12.
Total columns will be checked by
hand calculated addition of the
attendance figures printed.
USER SIGNATURE
PROJECT TEAM SIGNATURE
DATE
COMMENTS
Gambar 8.2. Typical test

8.7. DAFTAR RENCANA TES PENERIMAAN

(THE ACCEPTANCE TEST PLAN CHECKLIST)
Gunakan hal berikut sebagai daftar pengecekkan untuk semua

kegiatan yang diperlukan untuk rencana penerimaan :
• Hasilkan Fungsi vs. Tabel Percobaan dan semua FS yang
dijanjikan telah dialamatkan.
• Definiskan percobaan dan kumpulan percobaan.
• Tetapkan tanggung jawab untuk menulis percobaan.
• Klien dan Tim proyek mengetahui bahwa ATP akan ditinjau
kembali, direvisi jika perlu, dan ditandatangani oleh user. Klien
mengetahui bahwa keberhasilan penyelesaian dari percobaan
akan mempengaruhi penerimaan sistem. Lihat bentuk contoh ATP
pada bagian 10 di Appendix A.
• Tanggung jawab untuk percobaan data telah ditetapkan. Data
untuk percobaan seharusnya disediakan oleh tim proyek dan juga
user. Jika user dapat menyediakan data yang sesuai dengan
keadaan yang sebenarnya, percobaan terhadap sistem akan
berjalan dengan baik, ditambah user akan merasa nyaman
dengan keakuratan percobaannya.
8.8. KESIMPULAN UNTUK RENCANA TES PENERIMAAN

(CONCLUSION TO THE ACCEPTANCE TEST PLAN)
Anjurkan user untuk menulis ATP jika dia mampu. Hal ini akan
memberikan dia perasaan mengawasi – tim proyek harus
membangun sistem melalui percobaan.
Anda dapat melakukan tes penerimaan secara berlebihan.

Membandingkan biaya tes dengan biaya risiko itu adalah suatu
masalah. Anda dapat tidak melakukan semua percobaan, khususnya
dalam sistem multi-user yang interaktif.

8.9. KESIMPULAN UNTUK TAHAP DISAIN

(CONCLUSION TO THE DESIGN PHASE)
Pada akhir tahap disain kita menempuh beberapa kejadian penting

sebagai berikut :
1. Dokumen Spesifikasi Disain memuat disain akhir tingkat atas

melalui disain tingkat menengah.
2. Tanggung jawab ATP disahkan dan dimulai. Ini tidak perlu

diselesaikan sampai tahap penerimaan.
3. Rencana proyek, khususnya perkiraan perlu ditinjau kembali.

Walaupun anda sedang memperkirakan hanya 4 tahap yang telah
disebutkan, tahap pemrograman mungkin akan menjadi tahap
yang sangat mahal dan membutuhkan waktu yang sangat banyak
dalam keseluruhan kerja proyek. Disain memberikan anda
perkiraan perhitungan jumlah modul-modul dan kerumitannya.
Sekarang anda mungkin tahu siapa programmer-programmer
yang dapat diandalkan, sehingga anda dapat mempertimbangkan
faktor produktivitas mereka. Dengan informasi ini waktu
pemrograman yang diperlukan dapat dengan mudah diperkirakan
(lihat BAB 13). Statistik menunjukkan bahwa pada akhir tahap
disain diperkirakan seharusnya tidak lebih dari 10%.

BAB 9
FASE PEMROGRAMAN
9.1. PENDAHULUAN
Pemrograman adalah merupakan bagian yang paling mudah – itulah

yang kita sangat kenal sebagai tipe-tipe teknik. Pada kenyataannya,
sebagai Manajer Proyek anda mungkin menemukan cara sendiri
untuk mengendalikan staf anda dari memulai program yang terlalu
cepat. Selalu ada tekanan untuk melakukan sesuatu dengan benar,
tidak hanya dari tim proyek, tetapi dari manajemen tingkat tinggi.
Aktifitas-aktifitas pada fase ini adalah menulis program. Kejadian

pentingnya adalah menguji program, Rencana Tes Sistem, dan paling
tidak mulai pada Dokumentasi User.
9.2. DAFTAR PEMERIKSAAN PEMROGRAMAN

(PRE-PROGRAMMING CHECKLIST)
Sebelum anda memulai pemrograman, jawablah pertanyaan berikut :
• Apakah pemeriksaan disain memerlukan pengerjaan kembali ? Jika

ya, jadwalkan waktu mulai dan penundaan pemrograman.
• Apakah sumber daya yang direncanakan dan programmer masih

tersedia ? Jangan terlalu optimis dengan proyek orang lain yang
selesai tepat waktu. Jika ada pergantian staf, apakah anda akan
menguji kembali produktifitas mereka ?
• Apakah orang-orang ini telah dilatih ? Programmer harus

mengetahui tentang sistem operasi, bahasa pemrograman,
program paket, dan alat-alat pemrograman yang akan digunakan.
Mereka juga harus mengenal dengan baik aplikasi user dan
masalah bisnis. Pastikan bahwa mereka telah membaca
Requirement Document dan Functional Specification.

• Apakah lingkungan pemrograman cukup baik ? Anda membutuh-

kan kemudahan untuk menggunakan software pengembangan
dan alat-alat pemrograman. (Lihat bagian 9.4). Komputer
pengembangan harus mempunyai respon yang cepat, harus
tersedia ketika diperlukan, dan harus dapat diandalkan.
9.3. LANGKAH-LANGKAH PEMROGRAMAN

(THE PROGRAMMING STEPS)
Langkah 1. Rencana Penggabungan (Plan The Integration)
Menurut akal sehat anda tidak akan dapat membuat semua program
sekaligus dan kemudian membuang semuanya – ini memerlukan
rangkaian langkah demi langkah. Rencanakan urutan dimana anda
akan menggabungkannya. Bab 9 ini merinci beberapa metode untuk
menggabungkan bagian-bagian tersebut, tetapi anda harus
merencanakan urutan penggabungan ini sekarang, karena anda
harus menulis program supaya dapat digabungkan. Ini disebut
Rencana Tes Sistem (System Test Plan).
Langkah 2. Mendisain Modul (Design The Module)
Programmer menerima beberapa tingkatan disain dari fase disain.

Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih
rendah sampi mencapai keadaan programmer siap untuk melakukan
pemrograman. Ini disebut disain modul. Level disain modul tingkat
menengah dapat dilihat pada gambar 9.1.
Lihat Gambar 9.1. Medium level desin (3rd level)

Programmer menerima penjelasan modul dari perancang seperti
berikut ini.
Lihat Gambar penjelasan modul

Programmer pertama-tama menggambarkan diagram struktur dari

modul. Terlihat seperti pada gambar 9.2.
Lihat Gambar 9.2. Fourth level module breakout
Disain modul adalah pendekatan top-down dimulai dengan kotak

paling atas, AMST000 dan dipecah ke dalam sub-komponen yang
tepat, seperti pada gambar 9.3.
Lihat Gambar 9.3. Fifth level module breakout
Kemudian setiap sub-komponen dapat dibagi lagi, seperti pada

gambar 9.4.
Lihat Gambar 9.4. Sixth level module breakout
Dan kemudian modul tersebut dipecah lagi sampai tercapai sebuah

tingkatan dimana mulai dapat diprogram.
Pertanyaan yang bisa diajukan adalah : “Pada tingkatan mana disain

sistem berhenti dan disain modul dimulai ?”. Jawabannya adalah
“Disain sistem dipecah sampai pada tingkat dimana programmer
dapat memulainya”. Tingkatan ini dapat bermacam-macam dari
proyek ke proyek dan bahkan dari satu bagian sistem ke bagian
lainnya – tergantung pada programmer yang menerima bagian
tersebut.
Adapun pertimbangan lainnya adalah :

• Jika pemecahan modul yang dihasilkan adalah sangat penting
yang memerlukan prioritas seperti adanya respon, user-friendly
atau konsistensi, perancang bisa melanjutkan ke tingkat yang
lebih rendah.
• Tingkat pemecahan dari disain dinyatakan dengan kontrak.

• Jika programmer tidak mengetahui pada waktu disain,

pengetahuan programmer tingkat menengah dapat diasumsikan,
dan disain dapat diambil alih oleh programmer tingkat menengah
yang dapat mengatasinya.
Tetapi perlu diingat bahwa programmer tidak senang menerima

disain yang terlalu rinci, yang programnya adalah menerjemahkan
bahasa Inggris yang sederhana, seperti pernyataan-pernyataan
secara harafiah ke dalam bahasa pemrograman.
Langkah 3. Telusuri Disain Modul

(Walk Through The Module Design)
Seperti pada tingkat atas dan menengah dari disain, pertukaran

harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri
disain dari masing-masing modul sebelum melakukan pengkodean.
Penelusuran ini sangat kecil : hanya programmer yang tepat,
supervisor dan mungkin programmer lainnya yang perlu diperhatikan.
Kegunaan dari penelusuran disain modul adalah untuk memastikan
bahwa disain yang terbaik yang telah dilakukan, semua fungsi telah
dialamatkan dan semua bagian telah ditangani.
Langkah 4. Rencana Bagaimana Menguji Modul

(Plan How To Test The Module)
Programmer harus menyiapkan rencana pengujian modul dan data

pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah
kode ditetapkan. Mereka cenderung hanya menguji bagian kode yang
paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada
penelusuran rencana pengujian sepanjang disain modul sedang
dilaksanakan. Kerjakan penelusuran ini bersama-sama.

Langkah 5. Kode Setiap Modul (Code Each Module)
Standar pengkodean akan ditetapkan pada saat disain sistem (lihat

bagian 7.12). Kita tidak membahas bagaimana membuat program –
lihat Referensi 12 (tulisan ini membahas disain sama baiknya dengan
pemrograman) dan Referensi 13 untuk lebih jelasnya.
Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :

• Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris
kode yang dapat dieksekusi dan listingnya tidak lebih dari 2
halaman.
• Satu entry, satu exit.
• Referensi secara keseluruhan sedikit.
• Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE,
CASE, WHILE, UNTIL, CALL (bukan GO TO).
Langkah 6. Menguji Modul (Test The Module)
Programmer menguji modul dengan menetapkan lingkungan yang

tepat, menyediakan beberapa input, membiarkan modul langsung
memproses secara logik dan mendapatkan hasilnya. Beberapa input
mungkin tidak sebenarnya, terutama jika modul tersebut tidak
menyediakan input yang sebenarnya.
Modul seharusnya diuji dalam dua tahap, yaitu :

• Tahap Pertama disebut pengujian “White Box”. Programmer
harus mengetahui isi di dalam modul dan menyediakan data
pengujian, sehingga masing-masing path logical dalam program
dapat dieksekusi.
• Tahap Kedua atau pengujian “Black Box” dapat dilakukan. Dalam

pengujian ini, programmer mengabaikan bagian dalam dari modul
– data disediakan secara berurut dan dianggap seperti pemakaian
sebenarnya.

Langkah 7. Menguji Level Terendah dari Integrasi

(Test The Lowest Levels Of Integration)
Jika modul utama memanggil sub-modul, programmer harus

menggabungkan dan menguji semua modul secara bersama-sama.
Bahkan jika programmer tidak bertanggung jawab untuk menulis
sub-modul, programmer harus menguji perintah CALL dan RETURN
dari seluruh modul.
Metode terbaik untuk melakukan hal ini adalah membuat sebuah

“program stub” (potongan program) sebagai pengganti sub-modul.
Potongan program ini dapat terdiri dari empat baris program yang
menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan
parameter penerima, jika perlu lakukan pengontrolan kembali dengan
beberapa parameter yang tidak sebenarnya.
Langkah 8. Menyimpan Semua Hasil Pengujian;

Penggabungan Modul-modul Yang Telah Diuji
(Save The Results Of All Tests; Submit Finished
Modules To Integration)
Hasil pengujian digunakan untuk menyusun statistik yang

menunjukkan penyebab, cara perbaikan serta biaya-biaya yang
dibutuhkan untuk memperbaiki kesalahan-kesalahan program.
Pimpinan proyek biasanya menguasai/mengepalai penggabungan ini
pada sistem berukuran kecil sampai sedang.
Software seperti CMS (Code Management System) sangat berguna

untuk menajemen konfigurasi – menjamin program tetap berjalan
sesuai versinya dan mengubah ke source code (lihat bagian 9.4).
Langkah 9. Memulai Dokumentasi User

(Get Started On The User Documentation)
Apakah programmer bertanggung jawab pada dokumentasi user atau

tidak, tahapan ini adalah waktu terbaik untuk menjawabnya.
Dokumen-dokumen berikut mungkin harus ditulis :
Tuntunan Pemakai (User’s Guide)
Dokumen ini dapat ditulis oleh programmer, penulis teknis atau

bahkan user sendiri. Tampilkan kembali FS yang mempunyai bagian
rinci mengenai menu, layar, form, dan user interface lainnya.
USER’S GUIDE yang baik adalah terbagi dalam bagian-bagian yang

menunjukkan tingkatan user yang berbeda-beda. Sebagai contoh,
dalam USER’S GUIDE sistem ABC, harus ada bagian yang disebut
“Registrar’s Functions” atau “Warehouse Functions” atau lainnya.
Materinya harus disesuaikan agar user dapat menggunakan secara
normal. Hal ini membuat USER’S GUIDE berguna untuk mempelajari
sistem.
Urutan popular lainnya untuk USER’S GUIDE adalah menelusuri

menu-menu perintah secara logika. Pada akhir dari USER’S GUIDE ini
disediakan referensi dari setiap perintah, menu, form dan pesan yang
ditampilkan secara alphabet.
Tuntunan Pemeliharaan (Maintenance Guide)
Bagaimana anda menemukan programmer untuk merinci dokumen

dari program mereka untuk pemeliharaan berikutnya ? Kebanyakan
Manajer proyek mengalami kesulitan dalam hal berikut : programmer
enggan untuk melakukan dokumentasi sebelum program ditulis; dan
beruntunglah menemukannya setelah semuanya selesai dikerjakan.
Programmer berpikir bahwa pemeliharaan memerlukan penjelasan
secara rinci dari logika pemrograman. Sangat membosankan untuk
menulisnya dan sebenarnya tidak perlu.
Berikut ini adalah solusi sederhana tentang hal tersebut : lebih baik
merinci spesifikasi disain tingkat modul secara struktur,
mendokumentasikan sendiri kode, dirasa cukup untuk pemeliharaan
sistem.

MAINTENANCE GUIDE akan berisi spesifikasi disain, listing program

dan penjelasan bagaimana semuanya disesuaikan, bagaimana
mengubah pendekatan, dan bagaimana menghubungkan dan
menguji semuanya.
Tuntunan Operator / Tuntunan Manajer Sistem

(Operator’s Guide / System Manager’s Guide)
Sama seperti USER’S GUIDE untuk orang-orang yang menghidupkan

sistem di pagi hari, mematikannya, melakukan backup, menangani
permasalahan utama, melakukan perhitungan, dsb. Dokumentasi
yang disediakan oleh perusahaan hardware dan sistem operasi
mungkin cukup – hanya prosedur untuk software tertentu yang harus
ditulis ulang.
Dokumentasi Pelatihan (Training Documentation)
Jika anda akan memberikan kursus bagaimana menggunakan sistem,

rencanakan apakah materi pelatihan akan diperlukan. USER’S GUIDE
yang baik harusnya menambahkan hal ini. Anda mungkin harus
membuat bantuan pelatihan, seperti transaparansi, buku latihan,
pengujian, dsb.
9.4. PERALATAN PROGRAM (PROGRAMMING CASE TOOLS)
Berikut ini adalah produk software yang membantu programmer

untuk melakukan pekerjaanya dengan lebih baik. Software ini disebut
CASE (Computer Aided Software Engineering), karena membantu
proses pemrograman secara otomatis. Lihar Referensi 2.1. untuk
produk tersebut.
Bahasa Pemrograman (The Programming Language)
Bahasa pemrograman dan compiler adalah alat yang sangat penting.

Jika bahasa pemrograman itu sederhana dan sesuai dengan
aplikasinya programmer akan dapat mempelajarinya dengan cepat,
gunakan jenis yang diperlukan secara tetap, dan lakukan
pemrograman tanpa canggung. Compiler harus cepat dan jelas dalam

menuliskan pesan kesalahan.
Language Sensitive Editor (LSE)
LSE menyediakan template untuk setiap pernyataan dalam bahasa

pemrograman. Sebagai contoh, dalam bahasa PASCAL, user dapat
mengetikkan ‘FOR’ dan LSE menghasilkan :
FOR % {ctrl-var}% := %{exp}% %{TO | DOWNTO}% %{exp}% DO

%{statemnets}%
END;
Programmer mengisikan variabelnya dan LSE memastikan sintaksnya

benar. LSE juga dapat memanggil compiler. Jika ada kesalahan yang
ditemukan oleh compiler, LSE dapat mengontrol kembali, dan
programmer dapat kembali ke posisi edit – pada pesan dan baris
kesalahan tersebut. LSE dapat membuat program header dari
template. LSE membantu dalam pemeriksaan sintaks, kompilasi
program dan memastikan source format yang konsisten pada sistem.
Pendeteksi (Debugger)
Debugger membantu memeriksa dan memperbaiki kesalahan

program. Debugger dapat memberhentikan program, menelusuri
kesalahan dan memeriksa kesalahan berikutnya. Debugger yang
baik dapat menyesuaikan dan menampilkan variabel pada semua
titik, seperti pada pengeksekusian bagian spesifik dari program.
Code Management System (CMS)
Seringkali disebut manajer konfigurasi, CMS tidak tersedia untuk

semua bahasa pemrograman. CMS adalah ‘perpustakaan’ yang
memiliki sendiri semua sumbernya. CMS menertibkan orang–orang
yang melakukan update dan memastikan tidak terjadi konflik, jika
dua orang meng-update modul yang sama pada saat yang
bersamaan. CMS menyimpan segala perubahan yang terjadi pada
modul, sehingga segala perubahan pada modul dapat mudah dilihat.

CMS menunjukkan adanya perbaikan atau penambahan yang mudah

dengan versi-versi sebelumnya.
CMS dapat menangani semua file ASCII. Oleh karena itu CMS
berguna tidak hanya untuk menelusuri file-file sumber, tapi juga
untuk menyimpan file dokumentasi, file pengujian, dan file-file untuk
membangun sistem.
Module Management System (MMS)
MMS digunakan untuk proses compile dan link secara otomatis atau
membangun sebuah sistem. MMS hanya dapat membangun kembali
semua komponen tersebut yang diubah sejak pembangunan yang
terakhir. MMS dapat digunakan untuk menjalankan secara otomatis
sekumpulan pengujian modul. MMS sangat berguna ketika anda
membangun sebuah ‘release’ sistem : menyatukan sumber-sumber
yang benar dan meng-eksekusi image, seperti seluruh dokumen yang
terdapat dalam satu paket. MMS bekerja hand-in-hand dengan CMS
dimana semua sumber, file-file dokumen dan file-file perintah yang
diproses MMS dapat disimpan.
Test Manager (TM)
TM digunakan untuk menguji sebuah modul secara otomatis. Untuk

menggunakan TM, anda harus mendefinisikan serangkaian pengujian
terhadap modul. TM akan menjalankan pengujian, dan
memberitahukan programmer jika hasilnya bebeda dengan yang
diharapkan.
9.5. HAK CIPTA (COPYRIGHTS)
Subyek dari hak cipta software adalah tetap pada pengadilan, tetapi
terdapat peraturan pemerintah yang tidak hanya merupakan bagian
dari software yang memiliki hak cipta, tetapi juga berkenaan dengan
hal-hal lain yang berhubungan dengan software (apapun tujuan dan
artinya). Jika anda ingin melindungi kode anda, tambahkan

pemberitahuan hak cipta pada masing-masing modul dan dokumen

asli. “Copyright © 20nn, Company Name” yang biasanya diperlukan.
9.6. KESIMPULAN DARI FASE PEMROGRAMAN
Berikut ini beberapa pemikiran tentang pemrograman :
Pemrograman telah menjadi sebuah karya seni. Programmer

diperbolehkan untuk “mengerjakan segala sesuatunya sendiri”. Hal
tersebut sangat cepat ditemukan dan sangat mahal untuk
melaksanakan proses tersebut. Pemrograman haruslah
dipertimbangkan sebagai sebuah ilmu pengetahuan.
Pemrograman adalah kesenangan tetapi debugging bukanlah

kesenangan. Perhatikan pernyataan seperti “Pengkodean telah
dilakukan, semua yang debug dihilangkan, sehingga 90% telah
dikerjakan”. Data statistik menunjukkan bahwa programmer hanya
50% berhasil setelah pengkodean.
Berikut ini beberapa pemikiran tentang programmer :
Programmer selalu meremehkan tugas. Mengajari mereka pesimis

merupakan hal yang salah.
Programmer akan menikmati pekerjaan mereka jika anda memotivasi

mereka dengan sebuah tantangan. Setiap tugas harusnya lebih sulit
atau berbeda dari sebelumnya. Jika anda ingin belajar bagaimana
memotivasi programmer, bacalah buku G.Weinberg, “The Psychology
of Computer Programming” (Referensi 14).
Programmer sangat mudah tertekan, mereka akan bekerja lembur

jika diperlukan. Tetapi hati-hati terhadap lembur yang tetap.
Sewaktu-waktu tidak ada lagi produktifitas ekstra yang diperoleh dan
programmer akan kehabisan tenaga.

Pada akhir fase pemrograman, lihatlah hal utama berikut ini :
1. Disain modul sudah dijalankan dan diselesaikan.
2. Program-program individual sudah selesai di-kodekan, diuji dan

diselesaikan oleh pimpinan proyek.
3. Susunan dari penggabungan telah ditentukan, ditulis dalam

Rencana Pengujian Sistem (dan pemrograman telah dijalankan
pada saat itu).
4. Tanggung jawab terhadap dokumentasi user telah diberikan, dan

jika anda beruntung hal tersebut telah dilakukan.






BAB 13
ESTIMASI (PERKIRAAN)
13.1. PENDAHULUAN
Estimasi merupakan sebuah proses pengulangan. Pemanggilan ulang

estimasi yang pertama dilakukan selama fase definisi, yaitu ketika
anda menulis rencana pendahuluan proyek. Hal ini perlu dilakukan,
karena anda membutuhkan estimasi untuk proposal. Setelah fase
analisis direncanakan ulang, anda harus memeriksa estimasi dan
merubah rencana pendahuluan proyek menjadi rencana akhir proyek.
13.2. TEKNIK–TEKNIK ESTIMASI
Ada tiga teknik yang digunakan untuk melakukan estimasi, yaitu :
1. Keputusan Profesional
Katakanlah bahwa anda merupakan orang yang memiliki

pengalaman yang luas dalam membuat program “report
generation modules”. Anda melakukannya dengan pendekatan
merancang report tersebut dan memperkirakan berapa lama
waktu yang dibutuhkan untuk membuat program tersebut. Setelah
mempelajari rancangan program selama 5 menit, programmer lalu
menutup matanya selama 5 menit (dia tidak tidur, tetapi
berhitung), dan kemudian mengatakan “15 hari”. Inilah yang
disebut Keputusan Profesional murni.
Keuntungan dari teknik ini adalah cepat , dan jika seseorang

sudah ahli dalam teknik ini, maka estimasinya pasti akan lebih
akurat. Sedangkan kerugian dari teknik ini adalah bahwa anda
membutuhkan seorang ahli yang berpengalaman dalam bidang ini,
dan beberapa ahli tersebut akan bekerja keras untuk
mendapatkan estimasi yang tepat.

2. Sejarah
Jalan keluar dari ketergantungan pada orang dan untuk membuat

estimasi lebih khusus, yaitu anda harus mengerti tentang
sejarahnya. Tulislah berapa lama masing-masing tugas dapat
diselesaikan dan siapa yang bertanggung jawab atas tugas
tersebut.
Anda dapat membandingkan tuagas yang akan diestimasik dengan

tugas yang sama yang dikerjakan lebih awal, setelah itu mulailah
dengan melakukan estimasi. Hal ini dimaksudkan agar anda
menjabarkan suatu proyek ke dalam beberapa tugas yang
biasanya diulang dan mudah untuk dibandingkan.
3. Rumus-rumus
Ada beberapa rumus yang digunakan dalam software estimasi.

Software yang baik untuk diketahui adalah COCOMO (Referensi
15). COCOMO dapat digunakan untuk memperkirakan biaya
proyek, usaha (person months), jadwal, dan jumlah staf untuk
masing-masing fase berikut ini :
Preliminary Design - our Analysis Phase

Detailed Design (DD) - our Design Phase
Code and Unit Tes (CUT) - same as ours
System Test - our System Test and Acceptance Phase
Ada 3 tipe penginputan dengan COCOMO

VERY CMPLX
13.5. ATURAN PERSETUJUAN ESTIMASI PADA DEC

(DAN PERUSAHAAN BESAR LAINNYA)
Apakah perusahaan besar seperti DEC menggunakan pendekatan-

pendekatan ini ? Ya, mereka menggunakan rumus-rumus, tetapi
mereka tetap mengikuti aturan berikut ini :
• Jangan pernah menanyakan pada seseorang yang tidak

berpengalaman untuk melakukan estimasi.
• Lakukan estimasi secara berkelompok, jika anda mampu

menyediakan sumber daya manusianya.
• Jangan memaksa melakukan estimasi pada seseorang profesional,

seperti programmer.
• Jangan pernah mengambil rata-rata dari estimasi yang berbeda.
• Membagi persoalan menjadi bagian kecil secara mendetail selama

satu minggu atau kurang.
• Selalu tambahkan (kalikan ?) untuk kejadian yang tidak pasti.

Lihat bagian 2.4. manajemen risiko.
• Selalu berikan jangka waktu ketika melakukan estimasi bagi

manajer atau klien.
• Gunakan naluri anda.

BAB 14
PENJADWALAN
14.1. PENDAHULUAN
Perkiraan yang sudah diperhitungkan di dalam Bab 13 adalah

banyaknya orang per-hari dari usaha yang akan diperlukan untuk
membuat proyek. Hal ini disebut waktu sebenarnya (direct time).
Dalam bab 13 kita lihat bahwa langkah-langkah sebenarnya dalam

perencanaan sebuah proyek adalah :
1. Perencana (biasanya PM dan PL dalam suatu proyek kecil dan
menengah) menjelaskan rincian struktur kerja (WBS). Seseorang
atau kelompok diberi tanggung jawab untuk setiap kegiatan pada
tingkat rendah.
2. Tanggung jawab kelompok memperkirakan kegiatan-kegiatan di
tingkat rendah pada seseorang atau penggunaan hari yang
berjalan.
3. Tanggung jawab kelompok juga menunjukkan kegiatan
sebelumnya yang diperlukan untuk setiap tugas, dan menyaran-
kan sumber yang diperlukan untuk tugas tersebut.
4. Perencana menggambarkan aktifitas jaringan kerja, biasanya
dalam bentuk diagram PERT.
5. PM mengoptimalkan jaringan kerja dengan menyediakan sumber
untuk setiap kegiatan.
6. PM menghasilkan jadwal kegiatan-kegiatan.
Bab ini merinci langkah 4, 5 dan 6, jaringan kerja dan jadwal.
14.2. DIAGRAM PERT (THE PERT CHART)
Pada awalnya PERT (Program Evaluation and Review Technique)

yang sederhana digunakan untuk menjelaskan kegiatan yang
berurutan dengan menggunakan serangkaian anak panah, seperti
gambar 14.1.
Lihat Gambar 14.1 A PERT chart

Masing-masing anak panah mewakili satu kegiatan dan diberi label

dengan nama kegiatan tersebut, contohnya A, B, dan seterusnya.
Jika suatu kegiatan tidak dapat dimulai sebelum aktifitas sebelumnya
selesai, buntut dari anak panah kegiatan kedua (pengganti) diletakan
pada kepala dari yang sebelumnya. Pada gambar 14.1, sebagai
contoh, E tidak dapat dimulai sebelum D selesai, G tidak dapat
dimulai sebelum C dan F keduanya selesai. Titik awal dan akhir
disebut node dan diberi angka. Diagram dalam gambar 14.1
kelihatan tidak punya arti, tetapi berguna untuk menggambarkan
suatu PERT untuk ukuran proyek apapun, karena hal itu memaksa
anda untuk menganalisis sederetan kegiatan.
PERT juga menunjukkan kegiatan yang berjalan secara serentak.

Sederetan kegiatan seperti A – B – C – G disebut suatu jalur (path).
Jika ada jalur atau bagian jalur yang berjalan secara paralel, seperti
jalur B – C dan jalur D – E – F, maka kegiatan B dan C dapat
dikerjakan secara serentak dengan kegiatan D, E dan F.
Jalur Kritis (The Critical Path)
Suatu pembuktian yang luas dari diagram PERT di atas dapat dicapai
dengan mencantumkan lamanya tugas masing–masing pada PERT,
seperti pada gambar 14.2.
Lihat Gambar 14.2. A Pert chart with duration in day
Jalur terpanjang dalam jaringan kerja, dihitung dengan

menambahkan lamanya waktu sepanjang jalur. Sebagai contoh, pada
gambar 14.2 jalur paling atas (A-B-C-G) adalah 26 hari, dan jalur
bawah (A-D-E-F-G) adalah 25 hari, menjadikan jalur paling atas itu
jalur kritis (CP).
Garis ganda menunjukkan CP lengkap. Mengetahui jalur kritis

merupakan hal penting bagi PM. Jika suatu kegiatan pada CP meleset
(membutuhkan waktu lebih lama dari yang direncanakan) maka
tanggal pengiriman proyek akan meleset.

Float atau Slack
Suatu periode waktu dimana kegiatan dapat meleset tetapi tidak

mempengaruhi CP dan tanggal pengiriman.
Sebagai contoh, pada gambar 14.2, kegiatan-kegiatan D, E, dan F

diantara mereka terdapat 1 hari float (Perhitungan : kegiatan-
kegiatan CP pada B dan C membutuhkan waktu 11 hari; secara
bersamaan kegiatan-kegiatan di luar CP pada D, E, dan F membutuh-
kan waktu 10 hari, 11 – 10 = 1 hari untuk float). Setiap kegiatan
pada D, E, atau F, atau ketiganya secara bersamaan akan memakan
waktu sehari lebih lama dan tetap tidak berpengaruh pada CP.
Float Bebas dan Float Total (Free Float & Total Float)
Diagram PERT pada gambar 14.3 menunjukkan kegiatan CP dari

modul program A dan modul tes A dikerjakan oleh Programmer 1.
Kegiatan pada jalur utama, modul program B dan modul tes B,
dikerjakan oleh Programmer 2 memakan waktu 5 hari float. Kegiatan
– kegiatan pada jalur bawah, modul program C, modul tes C dan
penggabungan dikerjakan oleh Programmer 3 dan Pimpinan Proyek.
Jalur bawah membutuhkan waktu 5 hari float.
Lihat Gambar 14.3. Free float and total float
Total Float adalah waktu total float dimana kegiatan sebelumnya

berpengaruh pada CP.
Free Float adalah waktu float dimana kegiatan sebelumnya tidak

berpengaruh pada kegiatan lainnya.
Project float (beberapa float pada beberapa kegiatan) adalah hal

yang dimiliki Manajer proyek untuk digunakan sebagai
kebijaksanaannya. Beberapa Manajer proyek kadang melangkah
terlalu jauh dengan tidak memberikan informasi tentang kegiatan-
kegiatan floatnya.

Kegiatan Dummy (Dummy Activities)
Sejauh ini diagram PERT digambarkan sebagai kegiatan dalam format

anak panah. Penarikan mundur yang utama pada bentuk PERT ini
adalah dibutuhkan untuk kegiatan dummy. Sebagai contoh, pada
gambar 14.4A kita mempunyai kegiatan B, C dan D – F yang
semuanya dimulai pada titik yang sama dan berakhir pada titik yang
sama.
Lihat Gambar 14.4A A PERT chart
Akan lebih baik untuk mempunyai titik awal dan/atau titik akhir yang
unik untuk masing-masing kegiatan. Sebagai contoh, jika seseorang
menunjuk kegiatan diantara titik 2 dan 3, hal ini tidak jelas kegiatan
mana yang dimaksud. Kegiatan ini akan membingungkan ketika
jaringan kerjanya adalah komputer. Gambar 14.4A biasanya
digambarkan kembali seperti gambar 14.4B. Disini semua kegiatan
digambarkan dengan pasangan titik awal – akhir yang unik. Kegiatan
diantara titik 3 dan 4 tidak ada atau dummy (kegiatan fiktif)
dengan waktunya nol dan digambarkan sebagai garis terputus.
Lihat Gambar 14.4B A PERT chart with dummy
Kegiatan pada Titik atau Jaringan kerja yang diutamakan

(Activity on Node or Precedence Network)
Aktivitas pada titik atau jaringan kerja yang diutamakan adalah

bentuk lain dari diagram PERT. Gambar 14.5 mempunyai proyeksi
yang sama dengan gambar 14.4, digambar seperti kegiatan pada titik
PERT.
Lihat Gambar 14.5. Activity on node PERT
Titik-titik diberi nama dengan nama tugas, dan bebas menentukan

lamanya tugas.

14.3. PENEMPATAN SUMBER (RESOURCE ALLOCATION)
Jika anda mengerjakan rencana secara manual, diagram PERT

merupakan diagram yang paling baik digunakan untuk
menggambarkan lokasi sumber. Diagram untuk sebuah proyek
software seperti pada gambar 14.6.
Lihat Gambar 14.6. PERT ignoring resources
Langkah selanjutnya adalah menggambar ulang diagram PERT

dengan mengambil sumber dan memasukkannya ke dalam
perhitungan.
Penempatan Sumber Daya Manusia

(Allocating Human Resources)
Jaringan pada gambar 14.6 mempunyai 10 kegiatan yang dikerjakan

serentak pada satu waktu, yang mungkin menjadi pilihan jika anda
mempunyai 10 programmer yang handal (atau satu programmer
yang dapat menyelesaikan 1/10 dari waktunya untuk setiap orang).
Penempatan sumber daya manusia sangat subyektif dan tergantung

pada kemampuan mereka, tetapi ada beberapa hal yang harus
dipertimbangkan :
• Penentuan tugas kepada seseorang disesuaikan dengan tingkat

kemampuan individualnya. Jangan memberikan tugas yang mudah
kepada para ahli, jangan memberikan tugas yang rumit kepada
para pemula.
• Berikan tugas yang hampir sama pada orang yang sama. Hal ini
akan mengurangi waktu untuk mempelajarinya.
• Berikan tugas penting pada orang yang anda percaya. Yang

disebut orang kepercayaan bukan hanya orang yang bisa
menyelesaikan suatu tugas dalam waktu 3 hari, namun pada
kenyataannya penyelesaiannya membutuhkan waktu sekitar 5

sampai 10 hari. Orang yang dapat dipercaya itu adalah orang yang
bila berkata dapat menyelesaikan suatu tugas selama 3 hari, maka
selama itu jugalah tugas tersebut selesai.
• Berikan tugas yang memerlukan komunikasi pada satu orang yang

sama untuk menekan interaksi antar manusia.
• Jangan lupa bahwa pimpinan proyek membutuhkan waktu untuk

mengawasi, khususnya pada saat awal proyek.
Tingkatkan sumber daya yang ada sebanyak mungkin. Lebih baik

tetap mempertahankan 3 programmer dalam kesibukan selama 5
minggu berjalan, daripada mempekerjakan 5 programmer selama
seminggu, tidak satupun orang untuk minggu berikutnya, 3 orang
untuk minggu berikutnya, dan 7 orang untuk minggu selanjutnya.
Diagram PERT pada gambar 14.7 adalah pengulangan gambar 14.6

dengan penentuan sumber daya. Waktu yang dicapai untuk setiap
tugas akan lebih singkat jika lebih dari satu sumber daya yang
ditugaskan.
Lihat Gambar 14.7. Resources allocated
Keputusan penempatan staf dapat ditetapkan berdasarkan hal

berikut : P1 (Programmer 1) mempunyai kemampuan menangani
proyek, tetapi P2 dan P3 hanya dapat menangani proyek dalam
waktu yang lebih pendek. Modul A, B dan C merupakan modul yang
paling sulit namun mempunyai kesamaan, sehingga Pimpinan Proyek
(PL) dapat membantu P2 untuk membuat semua kode. Dengan
adanya PL dalam CP akan mengurangi stres PM. P1 merupakan
seorang senior yang mampu bekerja sendiri dengan serius, P3 adalah
pemula yang diserahi menangani dokumentasi (sesuatu yang tidak
adil). Catatan bahwa setiap orang bekerja pada jangka waktu yang
berdekatan.

Mengurangi (?) Lamanya Tugas dengan Menambah Tenaga

Kerja (Reducing (?) Task Duration by Adding Manpower)
Menambah tenaga kerja dalam suatu tim tidak perlu mengurangi

lamanya tugas-tugas. Peraturan suatu industri yang sangat menonjol
yang pengarang temui sangat berguna, yaitu “Tambahkan
sekurang-kurangnya 10% dari perkiraan waktu sebenarnya
untuk setiap tambahan anggota dalam suatu tim yang
profesional” .
Hal ini menunjukkan bahwa jika satu orang membutuhkan 10 hari

untuk mengerjakan tugas, dengan 2 orang dibutuhkan waktu 11 hari,
atau paling baik 5½ dalam 24 jam. Tambahkan 10% untuk setiap
penambahan kumulatif anggota.
Lamanya tugas dapat diterjemahkan dari gambar 14.6 menjadi

gambar 14.7. dengan memasukkan peraturan di atas ke dalam
perhitungan, ditambahkan beberapa keputusan profesional berdasar-
kan seberapa baik tugas-tugas itu dapat dibagi, seberapa baik
komunikasi setiap individu, dll.
Penempatan Sumber Daya ‘Non Manusia’

(Allocating ‘Non-Human’ Resources)
Sumber daya non manusia diperlukan untuk proyek software seperti

hardware komputer, paket software, sistem operasi, informasi,
manual, pelatihan, jaminan komputer, layanan cetakan, dsb.
14.4. TIGA BATASAN (THE TRIPLE CONSTRAINT)
Seperti yang kita lihat yang lalu, “Anda bisa mendapatkan yang baik,
murah atau cepat : Pilih dua !”. Menambah beberapa sumber daya
akan mengurangi lamanya tugas, tetapi biaya meningkat.
Memindahkan orang yang dipercaya dari kegiatan yang rumit tetapi
kegiatannya pendek ke dalam kegiatan yang lama mungkin
mengurangi waktu secara keseluruhan, tetapi ini akan
membahayakan seluruh proyek jika kualitas pada tugas yang pendek
dikurangi.

Banyak pilihan yang mungkin dilakukan ketika anda menentukan

sumber daya. Selalu coba beberapa pendekatan, lihat efek dari
penggunaan sumber daya dan biaya, panjang CP dan kesederhanaan
dari PERT. PM harus dapat membuat tiga batasan dan memberikan
keseimbangan yang baik berdasarkan prioritas tempat pada tiga
batasan untuk user atau manajemen tingkat atas.
Kegagalan Proyek (Crashing a Project)
Salah satu situasi yang paling sulit adalah ketika waktu menjadi
prioritas utama diantara tiga batasan. Ambil contoh skenario ketika
manajer anda menanyakan kepada anda untuk memperkiraan proyek
dan hasil yang anda sajikan :
YOU : Jika semuanya berjalan lancar, kita dapat menyerahkan

proyek ini pada tanggal 15 April.
MGR : Tidak mungkin ! Bagian Marketing telah menjanjikan proyek
ini pada tanggal 1 April. Kita bisa dikenakan denda $1000
perhari setelah tanggal 1 April. Bisakah anda mengerjakannya
lebih cepat ?
YOU : Ya, tapi saya membutuhkan waktu lebih banyak di depan
komputer, menyewa beberapa orang dan mengerjakan
pekerjaan tersebut dengan cepat (lembur). Hal itu akan
membutuhkan tambahan biaya lagi.
MGR : Semuanya gagal ! Tak usah hiraukan biayanya !
YOU : (Untuk anda sendiri : terdengar disini seperti ada yang
memotivasi). OK.
Apakah anda sungguh gagal di setiap tugas? Jelas tidak, mengapa

tugas yang gagal tidak ditempatkan pada jalur kritis ? Gambar 14.8A
di bawah ini merupakan contoh perhitungan tugas itu diselesaikan
beserta hasilnya.
Lihat Gambar 14.8A PERT for a project
Lihat Gambar 14.8B Steps to crashing the project

Lihat Gambar 14.8C Cost vs crash graph

Pertama-tama kita harus menghitung tiga hal untuk setiap tugas :
Hal pertama : Lamanya waktu normal (hari). Ini adalah perkiraan

yang akan anda berikan kepada Manajer pertama kali.
Hal kedua : Lamanya waktu minimal (hari) dimana anda dapat
menekan perubahan tugas.
Hal ketiga : Biaya tambahan per-hari untuk setiap perubahan.
Sebagai contoh, tugas B (gambar 14.8A) secara normal akan

memakan waktu 5 hari. Jika programmer bekerja lembur, tugas B
dapat selesai dalam 3 hari (minimum), tapi hal itu akan memerlukan
tambahan biaya $200 per-hari.
Mari kita coba untuk menyelesaikan proyek ini. Algoritma yang

digunakan pada proyek tersebut adalah : Ubah tugas pada CP,
jika selama tidak ada jalur lain yang menjadi kritis. Jika jalur
lain menjadi kritis, ubah tugas tersebut dengan baik.
Langkah satu : (Lihat gambar 14.8B) Ubah tugas A dari 3 hari

menjadi 2 hari. Ada keuntungan 1 hari dengan
biaya $500. Jalur lain tidak padat karena tidak ada
kegiatan lain yang paralel. Tugas A tidak dapat
diselesaikan lebih lama (3 hari adalah waktu
minimum).
Langkah dua : Ubah tugas B dari 5 hari menjadi 4 hari,

dengan biaya $200. E adalah sebuah jalur paralel,
jadi periksa jalur tersebut, jika jalur ini menjadi
kritis. Tugas E dilakukan secara simultan dengan B
dan C. Dengan mengubah tugas B menjadi 4 hari,
maka B dan C bersama-sama membutuhkan waktu
11 hari. Tugas E dilakukan selama 11 hari dengan
demikian berubah menjadi kritis, tetapi belum perlu
diubah.
Langkah tiga : Ubah tugas B menjadi 3 hari dengan biaya $200.

Karena E adalah paralel dan kritis, maka E
memerlukan tambahan hari, E harus diubah

menjadi 10 hari dengan biaya $1500, dan biaya

totalnya adalah $1700.
Langkah empat : Langkah 4 dan 5 sama, jadi penjelasannya

tergantung kepada pembaca.
Lima hari adalah yang terlama dari proyek tersebut dapat

diselesaikan, sehingga perlu diubah. Perhatikan bahwa tidak semua
tugas perlu diubah, atau tidak semua tugas yang diubah ditekan
menjadi minimum.
Terakhir, gambar 14.8C adalah graph yang sangat berguna bagi

manajemen. Graph tersebut menunjukkan tanggal pengiriman proyek
(sumbu X), serta biaya tambahan yang diperlukan selama tanggal
tersebut (sumbu Y).
Kesimpulan untuk Penyelesaian Proyek

(Conclusions to Crashing a Project)
Beberapa asumsi dapat dibuat disini :

• Pertama : tugas dapat diselesaikan. Menambah tenaga kerja dan
waktu lembur belum tentu mempercepat penyelesaian proyek.
• Kedua : tugas dapat diselesaikan sesuai pesanan.
• Ketiga : tugas-tugas dapat diselesaikan secara terpisah.
Penyelesaian satu tugas akan mempengaruhi tugas lain. Paket
komputer terbaik akan membantu semua perhitungan anda.
14.5. JADWAL ATAU DIAGRAM GANTT

(THE SCHEDULE OR GANTT CHART)
Diagram GANTT adalah diagram batang yang menunjukkan waktu.

Disebut GANTT karena ditemukan oleh Henry Gantt. Diagram GANTT
pada gambar 14.9 merupakan jadwal proyek PERT pada gambar
14.8.
Lihat Gambar 14.9. Gantt chart of a project

Langkah-langkah untuk menggambar GANTT adalah :
Langkah 1 : Gambarlah satuan waktu di posisi atas. Pilih satuan

waktu sehingga anda memerlukan tidak lebih dari 2
diagram. Anda akan melihat bahwa Gantt adalah buku
penuntun bagi Manajer proyek. Semua kalender
bergantung pada informasi yang dapat dimasukkan ke
dalam Gantt, dan 99% kehidupan PM bergantung pada
kalender ini. Tanggal mulai pada setiap minggunya
harus diberi tanda jika tersedia ruangannya.
Langkah 2 : Beri tanda pada kalender semua kejadian di posisi

bawah. Kegiatan hari libur seperti liburan, hari raya,
rapat, pelatihan, janji penting, dll, semua kejadian harus
dijadwalkan di sekitarnya.
Langkah 3 : Dari PERT pada gambar 14.7, jadwalkan setiap

kegiatan. Mulailah dengan kegiatan pertama, fase
DEFINISI, gambarkan dalam bentuk batang sama
panjangnya dengan satu hari pada PERT. Beri tanda
orang yang bertanggung jawab di dalamnya, dan
presentasikan waktu yang anda harapkan untuk setiap
orang yang bekerja pada proyek tersebut, jika ini tidak
100%.
Langkah 4 : Jadwalkan kemungkinan tugas. Untuk setiap kegiatan

tanya pada diri Anda sendiri, “Apakah ada pekerjaan
yang akan diperpanjang waktunya untuk tugas khusus
ini ?“.
Langkah 5 : Ulangi kembali langkah 3 dan 4, jadwalkan semua

tugas-tugas dalam PERT, dari kiri ke kanan dan dari
atas ke bawah untuk tugas-tugas yang paralel. Sebuah
tugas dimulai bila kemungkinan tugas yang sebelumnya
telah diselesaikan. Tambahkan kemungkinan yang
banyak pada tugas khusus terakhir, System Test,
sebagai ukuran keamanan.

Langkah 6 : Beri tanda semua kejadian-kejadian penting. Beri tanda

kejadian penting utama yang menunjukkan
penyelesaian dari kejadian penting dan produk-produk.
Yakinkan bahwa kejadian penting tersebut cukup sering,
jadi waktu diantara satu kejadian cukup pendek,
sehingga tidak akan lepas kontrol. Lakukan setiap 2
atau 3 bulan selama 12 bulan proyek itu berjalan. Ini
menunjukkan bahwa kejadian penting ‘fake’ dapat
ditemukan, seperti Milestone 3, Mid-programming
review pada gambar 14.10.
14.6. KESIMPULAN UNTUK PENJADWALAN
Sampai pengarang menulis buku ini, biaya Personal Computer

dengan software manajemen proyek yang sangat sempurna sama
dengan gaji seorang manajer proyek selama 1 minggu. Biaya ini tidak
dapat dihindari dalam pemakaian sebuah produk komputer untuk
menggambarkan PERT dan GANTT, untuk menghitung CP, dsb.
Personal Computer juga berguna untuk mengambarkan kembali

proyek GANTT kedalam sumber daya GANTT tersendiri untuk setiap
orang, meliputi jadwal kegiatan orangnya. Jika anda tidak pernah
menggambar PERT atau GANTT secara manual, pertama-tama
kerjakan ini pada kertas untuk mempelajari konsepnya, kemudian
gunakan Personal Computer.
Tetaplah mempertimbangkan 3 bagian dari GANTT. Bagian pertama

adalah untuk diri anda sendiri dengan semua float dan kemungkinan
yang terlihat. Bagian kedua adalah untuk individu-individu yang
terlibat – ini merupakan sumber daya GANTT bagi mereka. Bagian
ketiga adalah untuk distribusi bagi manajemen tingkat atas.

Arti penting Total Float adalah menunjukkan jumlah waktu yang

diperkenankan suatu kegiatan boleh ditunda, tanpa mempengaruhi
jadwal penyelesaian proyek secara keseluruhan.
Jumlah waktu tersebut sama dengan waktu yang didapat bila semua
kegiatan terdahulu dimulai seawal mungkin, sedangkan semua
kegiatan berikutnya dimulai selambat mungkin.
Total Float ini dimiliki bersama oleh semua kegiatan yang ada pada
jalur yang bersangkutan. Hal ini berarti bila salah satu kegiatan telah
memakainya, maka total float yang tersedia untuk kegiatan-kegiatan
lain yang berada pada jalur tersebut adalah sama dengan total float
semua dikurangi bagian yang telah dipakai.
Free Float adalah bilamana semua kegiatan pada jalur yang

bersangkutan mulai seawal mungkin.
Besarnya Free Float suatu kegiatan adalah sama dengan sejumlah

waktu dimana penyelesaian kegiatan tersebut dapat ditunda, tanpa
mempengaruhi waktu mulai paling awal dari kegiatan berikutnya
ataupun semua peristiwa yang lain pada jaringan kerja. Dengan kata
lain free float dimiliki oleh suatu kegiatan tertentu, sedangkan total
float dimiliki kegiatan-kegiatan yang berada di jalur yang
bersangkutan.

BAB 15
PROTOTIPE
Bekerja dengan Model Pertama
15.1. PENDAHULUAN
Siapapun yang pernah menyelesaikan proyek software akan

sependapat, bahwa masalah pertama adalah memperoleh kebutuhan
dari user. Permasalahan kedua adalah berdasarkan persetujuan
Spesifikasi Fungsional (FS). FS mencoba untuk menggambarkan
sistem yang berbasis grafik dan narasi, tetapi gambar dan penjelasan
tidak dapat menerangkan cara sistem tersebut berjalan, berlaku, dan
mempengaruhi bisnis user. Sebagai tambahan, FS biasanya
menimbulkan kesalah pahaman (jika dibaca semuanya).
Kesalah pahaman antara user dan analis mengakibatkan perubahan

yang berarti atau sistem tidak akan pernah sempurna dalam
pelaksanaannya atau sekaligus ditolak. Prototipe dapat memecahkan
masalah ini untuk tipe-tipe tertentu dalam sistem.
15.2. TEORI DI BELAKANG PROTOTIPE

(THE THEORY BEHIND PROTOTYPING)
Apakah anda membeli mobil dari brosur penjualan ?
Seperti halnya anda tidak dapat menilai sebuah mobil tanpa

mencobanya, user juga tidak dapat menilai dari Spesifikasi
Fungsional, bagaimana sistem akan berlaku dan berjalan. Tetapi jika
user dapat melihat, menyentuh dan menggunakan ‘mode’l atau
prototipe dari tujuan sistem, ia dapat langsung menilai kegunaan
sistem. Jika perubahan diperlukan prototipe dapat dimodifikasi,
memungkinkan dimodifikasi beberapa kali sampai keadaaan yang
ditetapkan user.

Keuntungan dari prototipe
• Menghasilkan syarat yang lebih baik dari produksi yang dihasilkan

oleh metode ‘spesifikasi tulisan’.
• User dapat mempertimbangkan sedikit perubahan selama masih

bentuk prototipe.
• Memberikan hasil yang lebih akurat dari pada perkiraan

sebelumnya, karena fungsi yang diinginkan dan kerumitannya
sudah dapat diketahui dengan baik.
• User merasa puas. Pertama, user dapat mengenal melalui

komputer. Dengan melakukan prototipe (dengan analisis yang
sudah ada), user belajar mengenai komputer dan aplikasi yang
akan dibuatkan untuknya. Kedua, user terlibat langsung dari awal
dan memotivasi semangat untuk mendukung analisis selama
proyek berlangsung.
15.3. METODE PROTOTIPE (THE PROTOTYPING METHOD)
Langkah-langkah pembuatan prototipe :
Langkah Pertama
Permintaan bermula dari kebutuhan user.
Langkah Kedua
Bangunlah sistem prototipe untuk menemukan kebutuhan awal yang
diminta.
Langkah Ketiga
Biarkan user menggunakan prototipe. Analis harus memberikan
pelatihan, membantu dan duduk bersama-sama dengan user,
khususnya untuk pertama kali. Anjurkan perubahan. User harus
melihat fungsi-fungsi dan sifat dari prototipe, lihat bagaimana ia
memecahkan masalah bisnis dan mengusulkan perbaikan.

Langkah Keempat
Implementasikan saran-saran perubahan.
Langkah Kelima
Ulangi langkah ketiga sampai user merasa puas.
Langkah Keenam
Merancang dan membangun suatu sistem akhir seperti sebelumnya.
15.4. SISTEM YANG BERMANFAAT DARI PROTOTIPE

(SYSTEMS THAT BENEFIT FROM PROTOTYPING)
Sejak kebutuhan (baca Spesifikasi Fungsi) pada umumnya

berhubungan dengan pandangan user terhadap sistem, hanya
dengan prototipe tampilan bagi user sudah cukup untuk memeriksa
yang dibutuhkan. Menu-menu, bentuk tampilan input, tampilan
keluaran, atau laporan yang dicetak, pertanyaan-pertanyaan, pesan-
pesan merupakan calon yang ideal untuk prototipe.
Di lain pihak, perhitungan yang rumit, kumpulan update data dan

realtime, dan sistem yang bersifat scientific sangat sulit untuk
dijadikan model.
Sistem yang paling sesuai untuk prototipe adalah satu dari banyak
hal yang bergantung pada sistem input/output dari user. Sistem
dengan transaksi on-line dikendalikan melalui menu, layar, formulir,
laporan, daftar dan perintah.

15.5. SOFTWARE UNTUK PROTOTIPE

(SOFTWARE FOR PROTOTYPING)
Apa yang harus disediakan dari paket software prototipe ?
Produk yang baik harus menyediakan 7 bagian, yaitu :
1. Pembuatan menu yang cepat dan mudah.

Pada menu harus terdapat sub menu, formulir, laporan, program
protipe, dan menyediakan bantuan secara on-line untuk pemilihan
menu dan prompt.
Lihat Gambar 15.1. Konstruksi Program Menu
2. Pembuatan tampilan input dan output.

Anda harus dapat mewarnai bentuk tampilan dengan menempat-
kan kursor pada lokasi yang dituju (mouse merupakan alat yang
terbaik untuk melakukannya), ketik nama field, spesifikasikan
ketentuan untuk mengedit berdasarkan panjang field,
menyertakan alfanumerik, jarak angka-angka yang diperbolehkan,
kesalahan dan pesan-pesan bantuan, dll.
Lihat Gambar 15.2. Cara kerja field program aplikasi
3. Penyelarasan.
Anda dapat menjelaskan bentuk sebuah laporan yang dicetak
dengan mudah. Bagian-bagian untuk merinci pembuatan laporan
adalah judul, catatan kaki, field mana yang diletakkan (yang
paling baik adalah jika program menampilkan semua field yang
dikenal), header kolom, pengelompokkan, pengurutan, serta sub
dan grand total. Pada umumnya seseorang harus dapat
melaporkan item yang dipilih saja.
Lihat Gambar 15.3. Penggunaan sebuah program pembuatan

laporan

4. Software harus menghasilkan sebuah Data Dictionary

secara otomatis.
Data Dictionary (DD) menyimpan informasi seperti layar, laporan
atau formulir, tetapi yang paling penting DD menyimpan setiap
informasi pada setiap field, termasuk panjang field, pengeditan
dalam setiap laporan, dan format field yang digunakan.
DD adalah inti dari setiap produk dan sudah seharusnya setiap

alat prototipe menggunakan DD untuk mengecek apakah fieldnya
digunakan secara konsisten pada setiap tampilan, dan apakah
dapat menyimpan pengetikan berulang jika field muncul lebih dari
1 kali.
5. Software harus dapat menyusun database sesuai harapan.

Ketentuan tampilan input seperti yang digunakan pada gambar
15.2 menjelaskan tentang peralatan daftar format. Software harus
menyusun database dan selanjutnya mengijinkan user memasuk-
kan data menggunakan formulir input. Produk-produk yang baik
mengijinkan user untuk mengoptimalkan database dengan
menentukan format dan kunci recordnya.
6. Mencari hasil dengan query on-line secara tepat ke data

yang didaftar pada database.
Anda harus mampu melakukan pencarian dengan mudah,
penyusunan, pemilihan dan menampilkan record.
7. Apakah yang dibutuhkan meliputi logika yang rumit atau

perhitungan yang diperlukan prototipe ?
Walaupun tidak penting, program yang baik mempunyai bentuk
struktur sederhana bahasa pemrograman untuk mengijinkan anda
melakukan pemrosesan khusus, waktu kejadian, prosedur-
prosedur otomatis, dsb.

Prototipe sebagai bagian dari CASE
Prototipe adalah metode untuk mengotomatisasi fase definisi dan

analisis, jadi merupakan bagian dari CASE (Computer Aided Software
Engineering). Tetapi prototipe memberikan masukan pada tingkat
pengotomatisasian selanjutnya dengan baik.
Jika langkah selanjutnya adalah membangun sistem nyata dalam

bahasa pemrograman generasi ketiga, produk prototipe harus dapat
menyediakan pada anda sarana untuk mencetak semua item yang
telah diketahui, semua menu, semua bentuk laporan dan perintah-
perintah.
Produk yang terbaik adalah yang mengijinkan user untuk mencetak

dokumen yang tersusun secara logika dengan bab dan bagian yang
dapat digunakan seperti dokumen Spesifikasi Fungsional (FS).
Bahkan beberapa diantaranya menyediakan pengolah kata untuk
memasukkan teks keterangan di antara item-item. Produk tersebut
harus pula dapat mencetak kamus data, yang dapat menghemat
banyak jam kerja.
Jika disain dan programnya menggunakan bahasa pemgrograman

generasi ke-empat atau peralatan CASE yang terintegrasi (lihat
Bab 6), anda harus dapat memasukkan hasil dari prototipe secara
langsung ke dalam peralatannya. Peralatan CASE yang paling baik
akan secara otomatis menyusun database dan bahkan kode untuk
aplikasi akhir.
Seberapa cepat anda melakukan prototipe ?
Software untuk melakukan prototipe harus dapat membuat anda

mampu menyusun model permulaan dari suatu sistem secara cepat.
Khususnya, anda dapat membangun prototipe pertama dari bentuk
terkecil hingga bentuk yang sedang hanya dalam waktu 2 s/d 3
minggu !. Anda juga harus dapat mengimplementasikan perubahan
dengan cepat.

Ini akan memakan waktu beberapa menit untuk membuat

perubahan, seperti memindahkan sebuah field pada sebuah form. Ini
akan memakan waktu kurang dari 1 jam untuk menentukan sebuah
menu atau form baru, dan hampir beberapa jam untuk membuat
sebuah file baru atau menyusun ulang sebuah file yang sudah ada
untuk sebuah field, key atau akses baru.
Untuk mencapai kecepatan ini perlu mempunyai sebuah user

interface yang sederhana dan logis. Sebenarnya jika pembuatan
prototipe software cukup sederhana, para pengembang dapat
melatih user untuk menggunakannya. User kemudian akan
membangun prototipe dan menghubungi pengembang ketika siap
untuk berubah menjadi sistem akhir.
15.6. DIMANAKAH PROTOTIPE DITEMPATKAN DALAM 7 FASE ?
Sekarang anda mungkin merasakan bahwa metode pembuatan

prototipe dapat menggantikan dengan sempurna 7 fase mendekati
pembangunan proyek (dan mungkin juga merasa diganggu bahwa
saya membuat anda membaca bagian I buku ini sebelum
menceritakan pada anda tentang pembuatan prototipe !) Jangan
takut pembuatan prototipe hanya menggantikan beberapa bagian
dari Fase Definisi dan Analisis.
Lihat Gambar 15.4. Urutan kejadian di dalam 7 fase antara metode

lama dengan metode baru (prototipe)
Fase definisi dan analisis akan memakan waktu yang lebih sedikit dari
cara baru, karena sebuah deadline akan ditentukan waktunya.

15.7. BEBERAPA PRODUK YANG HARUS DILIHAT

(SOME PRODUCTS TO LOOAK AT)
Excelerator sebagai alat prototipe
Dalam bab 6 kita telah melihat sebuah alat analisis yang baik disebut
Excelerator (referensi 2.2), tetapi alat ini mempunyai bentuk yang
membuat alat prototipe yang baik. Meliputi menu, form, dan fasilitas
untuk membuat laporan. Yang terpenting memelihara sebuah kamus
data, mengijinkan anda untuk mencetak sebuah organsasi logik yang
berfungsi sebagai dokumen yang khusus, yang terdiri dari semua
jenis yang didefinisikan dengan proses kata yang dimasukkan dalam
paragraf untuk ukuran yang baik.
Bahasa Generasi Ke-empat sebagai peralatan prototipe
Suatu saat kita memerlukan layar yang rumit, perhitungan khusus,

prosedur otomatis, dan bentuk laporan yang unik, yang kebanyakan
prototipe tidak mempunyai kemampuan untuk melakukan semua itu.
Ada sebuah jenis produk yang disebut Fourth Generation Language
(4GL) yang mempunyai kemampuan untuk melakukan hal tersebut.
Kita akan membicarakan hal ini di bab lain sebagai alat untuk
mengembangkan semua sistem, tetapi hampir semua 4GL dapat
digunakan sebagai peralatan prototipe yang baik.
15.8. KESIMPULAN (CONCLUSIONS)
Prototipe telah digunakan dengan sukses untuk diimplementasikan ke

beberapa sistem software, yang meliputi user interface melalui menu,
layar, laporan, dan transaksi on-line. Sistem yang berorientasi bisnis
sangat cocok untuk metode ini. Sistem real-time dan scientific akan
sedikit berkurang ketika menggunakan metode ini.


BAB 19
SUSUNAN STAF
Orang yang tepat untuk tugas yang tepat
19.1. PENDAHULUAN
Susunan staf adalah memilih orang yang tepat untuk pekerjaan yang
tepat. Bab ini akan sangat berguna bagi Anda yang harus memilih
individu-individu dari staf yang ada atau siapa yang harus ditugaskan
pada tim proyek.
19.2. MEMILIH ANGGOTA TIM PROYEK
Jika Anda mengorganisasikan tim proyek seperti digambarkan pada

gambar 18.1, jabatan yang harus diisi adalah Manajer Proyek,
Pimpinan Proyek, dan Programmer.
Manajer Proyek (Project Manager)
PM adalah posisi pertama yang harus diisi. Pekerjaan ini diisi ketika
proyek masih sekilas di mata orang, karena PM yang pertama
menentukan apakah sebuah proyek dapat dikerjakan atau tidak.
Manajer tingkat atas menugaskan PM. Mereka mencari seseorang

yang memiliki kemampuan berkomunikasi dengan baik. Keahlian-
keahlian lain yang mereka cari adalah pengetahuan tentang
manajemen proyek, kemampuan mengorganisasi, dan keahlian
teknik.
Kadang-kadang pekerjaan PM membutuhkan aksi yang tidak umum

seperti berkata “Tidak” untuk perubahan permintaan yang
menyimpang, mengumumkan kesalahan, atau mendisiplinkan orang-
orang. PM harus mengetahui orang-orang yang terlibat sama seperti
dalam politik, prosedur-prosedur pemakaian, dan proyek perusahaan.

Keahlian yang dibutuhkan untuk pekerjaan ini adalah kepemimpinan

yang luas, kemampuan bernegosiasi dan diplomasi.
Pimpinan Proyek (Project Leader)
Pimpinan Proyek adalah posisi kedua yang harus diisi. Sangatlah baik
jika PM memilih orang ini. Pertama, PM harus bernegosiasi dengan
Manajer Fungsional untuk tugas-tugas PL, kemudian yakinkan PL
untuk bergabung dalam tim. PL terdaftar pada proposal karena
banyak detail proposal dikerjakan oleh PL. Pekerjaan ini sangat
bersifat teknis, karenanya pilihlah ahli yang terbaik. Jangan mencari
orang yang tidak mempunyai pendirian. Lebih baik mencari orang
yang dapat mengingat pembuatan detail keseluruhan proyek
tersebut.
PL juga harus memiliki kemampuan berkomunikasi yang baik. PL

akan memimpin keseluruhan wawancara dengan user dan menjadi
pengawas harian bagi programmer.
Programmer
PM dan PL akan mulai berpikir tantang siapa yang dapat membentuk

tim pemrograman dan bertanya pada Manajemen Fungsional (jika
diperlukan) tentang kemampuan orang-orang ini (Programmer).
Kemudian, ketika kontrak ditandatangani, mulailah mengumpulkan
tim programmer Anda.
Pertama pilihlah Programmer dengan kemampuan pemrogramannya.

Sebagai tambahan carilah keterangan tentang pengalaman mereka,
tetapi bukan seseorang yang sudah melakukan hal yang sama
selama 5 kali berturut-turut – orang ini akan bosan. Jika kandidat
tersebut tidak memiliki pengalaman yang sesuai, hal lain yang dapat
dipertimbangkan adalah latar belakang tentang sistem operasi, atau
hal lainnya.

Programmer Ahli (The Guru Programmer)
Gaya hidup baru telah berevolusi sejak komputer ditemukan. Hal ini
adalah Programmer Ahli atau “Hacker”. Orang ini bekerja secara
misterius, pada jam-jam yang aneh; suka menentang dan tidak mau
diatur, hanya ingin mengerjakan tugas sesuai dengan keinginanya.
Tetapi ahli dalam bidangnya, dapat membuat program tugas-tugas
yang rumit 10 kali lebih cepat dari orang lain. Disarankan jika Anda
memiliki orang ini, organisasikan sebuah tim dan 1 ahli ini dikelilingi
oleh para pemula. Hal ini akan sukses jika ahli tersebut senang
menjelaskan sesuatu kepada orang lain (seperti yang biasa mereka
lakukan) – para pemula akan belajar dari ahli ini.
Programmer Pemula (The Junior Programmer)
Programmer pemula biasanya memiliki bakat dan mempunyai

keinginan untuk membuktikan diri mereka. Ada dua keahlian,
bagaimanapun itu tidak selalu diajarkan di sekolah : komunikasi
tim dan komunikasi manajemen. Selalu ada kompetisi di sekolah.
Bahkan pada sebuah tim proyek, para siswa tidak membantu
diantara sesama mereka. Mereka mungkin tidak diajarkan untuk
berbagi pekerjaan kepada anggota tim yang lain. Dalam sebuah
perusahaan seorang anggota tim hanya berhasil jika keseluruhan tim
berhasil.
Bersamaan dengan itu, para siswa mungkin tidak diajarkan bahwa

para manajer setiap saat harus selalu tahu apa yang sedang
dikerjakan setiap orang dan bagaimana kemajuan tugas mereka. Ini
mungkin tidak dibutuhkan untuk sebuah tugas sekolah. Tetapi jika
anda mengajarkan Programmer Pemula untuk berkomunisasi, Anda
akan memiliki anggota tim yang tidak terhingga nilainya.
19.3. KEPRIBADIAN
Kepribadian dapat berpengaruh kuat terhadap proyek. Berikut ini

sebuah daftar dari kepribadian yang diinginkan untuk staf proyek.
(Hati-hati, gunakan penilaian Anda).
1. Anda membutuhkan seseorang yang dapat berkomunikasi, yang

merupakan bagian dari sebuah tim, serta dapat berbagi
pengetahuan dan ide-ide dengan baik, tetapi juga harus mau
menjalankan ide-ide tersebut.
2. Anda membutuhkan seorang pendengar yang baik, seseorang

yang akan mendengarkan pendapat orang lain dan mau mengakui
jika pendapat-pendapat tersebut lebih baik.
3. Anda membutuhkan seorang yang terorganisir. Akan banyak tugas

yang harus dilakukan, setiap tugas pada waktu yang tepat.
4. Anda tidak membutuhkan seseorang yang perfeksionis. Pilihlah

seorang yang dapat bekerja pada saat deadline. Selalu ada cara
yang terbaik, tetapi jika hal ini berhasil sekarang, keluarkan sesuai
waktu, dan simpan kemajuan ini untuk versi berikutnya.
5. Anda membutuhkan seseorang yang mempunyai kemampuan

teknik terbaik, seorang analitis dan logis, dengan pengalaman
yang sesuai.
19.4. MEMBERIKAN TUGAS KEPADA INDIVIDU-INDIVIDU
Dalam bukunya “The Psychology of Computer Programming”,

G. Weinberg menyatakan bahwa motivator terbesar dari seorang
programmer adalah mempelajari hal baru. Selalu berikan tugas yang
lebih menantang dari tugas sebelumnya. Tetapi jangan memberikan
sebuah tugas yang rumit untuk Programmer Pemula – mungkin tidak
akan selesai, dan tugas yang rumit ini pun juga tidak akan
terselesaikan oleh para ahli.
Jika ada tugas-tugas yang berhubungan, berikan pada orang yang

sama. Jika ada program yang berhubungan dengan program lain,
berikan program ini kepada seseorang pada posisi yang sama (atau 2
orang yang sangat dekat).

Berikan tugas-tugas yang kritis dan tugas-tugas yang sulit kepada

orang yang paling diandalkan. Orang yang dapat diandalkan
bukanlah “Ahli” yang dapat menyelesaikan tugas dalam 2 hari, tetapi
orang tersebut menyelesaikan dalam 4 atau 10 hari tergantung pada
mood orang tersebut. Orang yang dapat diandalkan berkata “Tugas
ini akan selesai 5 hari”, dan selama waktu itulah yang diperlukan.
Jangan memberikan tugas yang membuat seseorang menjadi tidak

disiplin. IBM telah menemukan bahwa sebuah organisasi dimana
Kepala Tim Programmer / Chief Programmer Team (CPT) sangat
produktif. Dengan metode CPT, seorang kepala ahli programmer
melakukan semua pengkodean yang rumit (80%), dibantu oleh para
pemula untuk pengkodean yang lebih mudah (20%). Tetapi jika
ketua pergi, maka anak buah akan menghilang.
Untuk mencegah hal ini, IBM biasanya menggunakan sebuah sistem

bersahabat, dimana seorang programmer ditugaskan untuk bekerja
dengan sangat dekat dengan kepala programmer, membantu dan
berbagi muatan pekerjaan jika mungkin, dan mempelajari semua hal
yang diketahui oleh kepala programmer.
19.5. MEMOTIVASI ORANG
PM adalah pelatih dari sebuah tim; PL adalah kapten. PM memimpin,

memotivasi, mengajarkan dan menggunakan sedikit ancaman untuk
mendapatkan tugas tersebut diselesaikan. PL bermain dalam tim dan
memotivasi dengan memberi contoh. Kepemimpinan proyek (PM dan
PL) harus selalu ada dan dapat melakukan pendekatan. Gunakan
pendekatan MBWA (Management By Walking Around) seperti
dalam buku “In Search of Excellence”, bagian 4.
Ketika seseorang mendekati Anda dengan sebuah masalah pribadi

atau teknik, lakukanlah hal ini : Diam dan dengarkan. Biasanya orang
itu akan menjawab masalahnya, ketika menjelaskan masalah
tersebut.

angan lupakan 3 prinsip dasar dalam buku “The One Minute

Manager” (bagian 21) : Jika pantas, berilah pujian (satu menit),
Jika sangat perlu, berilah kritikan (satu menit), dan selalu
menyusun sasaran-sasaran (satu menit) untuk
berkomunikasi sesuai dengan apa yang diharapkan setiap
orang dan bagaimana mereka akan dinilai untuk sukses.
Libatkan orang-orang dalam setiap keputusan proyek yang penting

dan mereka akan mematuhinya. Sebagai contoh, selalu
memperhitungkan kembali setiap pekerjaan mereka dan capailah
kesepakatan jika anda mempunyai perhitungan dan mereka tidak
setuju.
Kirim orang-orang Anda ke kursus-kursus – sangatlah mengejutkan

apa yang dapat dipelajari, bahkan oleh orang-orang yang paling
berpengalaman.
19.6. KESIMPULAN
Dari semua hal tentang bagaimana memilih orang yang tepat,

ingatlah bahwa kemampuan dari orang tersebut akan menjadi faktor
pertama yang menentukan.

.MATERI Pengelolaan Proyek Sis - Informasi

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

.MATERI Pengelolaan Proyek Sis - Informasi

Diunggah oleh

Hak Cipta:

Format Tersedia

Pengelolaan Proyek Sistem Informasi

° Project Management : Aplikasi pengetahuan, keahlian, alat

Yang menentukan keberhasilan atau kegagalan Proyek, meliputi

1. Keterbatasan Lingkup Proyek (Project Contraint) : Sesuatu

2. Fase Proyek (Project Phase) :

3. Pelaksanaan (Executing) – Mengkoordinasi staff dan

° Dokumen Perencanaan Proyek (Project Plan) – detil yang

TUJUH FASE PROYEK SOFTWARE

Proyek software sama dengan membangun sebuah rumah

Tujuan dari fase definisi adalah untuk memahami dengan baik

Ada 3 aktifitas utama yang harus dilakukan dalam Fase Definisi :

Jika keputusannnya adalah melaksanakan proyek tersebut, Anda

Tulislah beberapa dokumen dan temukan beberapa kejadian

Pertama, menulis Requirement Document (RD), yaitu dokumen

BAB 2 Halaman 1 dari 8

Selanjutnya, menulis Pendahuluan Perencanaan Proyek

Seberapa jauh perkiraan-perkiraan tersebut dapat dipertanggung

Jika anda tidak yakin dengan kebutuhan-kebutuhan yang telah

Pada saat pendefinisian, proposal anda hanya akan menjadi

2.2. DOKUMEN KEBUTUHAN (REQUIREMENT DOCUMENT / RD)

RD menyatakan masalah-masalah yang dihadapi user dan solusi

BAB 2 Halaman 2 dari 8

Tanya jawab dengan User

Masalah terbesar berkaitan dengan pemakai akhir (end-user) yang

Siapkan rencana untuk melakukan wawancara. Pelajari tentang

Pertama, cari tahu tentang aliran informasi yang ada dalam

BAB 2 Halaman 3 dari 8

Kedua, masukkan-masukkan yang diterima diikuti dengan

Hal-hal yang terdapat dalam RD

Berikut ini adalah bagian-bagian dari RD :

2. Tujuan Proyek. Sebuah pernyataan singkat mengapa kita

3. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana

4. Keluaran Umum. Penjelasan secara singkat tentang informasi

5. Informasi Input secara Umum. Input data apa yang diperlukan

BAB 2 Halaman 4 dari 8

6. Kinerja (Performance). Berapa banyak transaksi yang akan

7. Perkembangan (Growth). Hal ini mungkin sulit untuk diramalkan,

8. Pengoperasian dan Lingkungan. Dimana komputer akan

9. Kompatibilitas, Pengantarmukaan. Jelaskan jika fasilitas antar

10. Reliabilitas, Ketersediaan. Tulis penggambaran waktu

11. Pengantarmukaan dengan Pemakai. Rincikan pengalaman-

12. Pengaruh Organisasi. Departemen-departemen apa yang

13. Pemeliharaan dan Dukungan. Jaminan-jaminan yang

BAB 2 Halaman 5 dari 8

14. Dokumentasi dan Pelatihan. Rincikan semua dokumen-

15. Keuntungan (hanya RFP). Jika RD adalah RFP dalam situasi

16. Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi,

2.3. TANGGUNG JAWAB USER

Meskipun user tidak menulis RD, dia bertanggung jawab untuk

2.4. KEPUTUSAN MELAKSANAKAN / TIDAK MELAKSANAKAN

Setelah kebutuhan-kebutuhan ditetapkan, langkah berikutnya adalah

BAB 2 Halaman 6 dari 8

Dalam suatu studi kelayakan kita mempertimbangkan semua

Perkiraan keuntungan ini mungkin saja mudah, tetapi seharusnya

2.5. MANAJEMEN RISIKO

Menurut sejarah, industri pemrosesan data telah membuat reputasi

Alasan yang menumpuk adalah bahwa :

BAB 2 Halaman 7 dari 8

Solusi standar industri untuk semua masalah-masalah ini adalah :

SOLUSI 1. Selidiki masalah-masalah yang ada

2.6. EMPAT LANGKAH MANAJEMEN RISIKO

Manajemen risiko terdiri dari empat langkah :

BAB 2 Halaman 8 dari 8