1. Aplikasi perangkat lunak yang diusulkan : beberapa proyek mirip biasanya dikembangkan berdasarkan pengalaman sebelumnya. Padahal proyek perangkat lunak memiliki sifat yang unik sehingga sering ada hal-hal yang tidak terduga dan penuh ketidakpastian.
2. Perubahan teknologi : perubahan bahasa pemrograman yang digunakan bisa menghambat waktu selesainya proyek.
3. Kurang homoginnya pengalaman proyek : estimasi akan efektif bila dibuat berdasarkan proyek-proyek sebelumnya, hanya saja banyak perusahaan yang menyembunyikan data proyek-proyek sebelumnya dari para staf.
4. Subyektifitas estimasi : orang cenderung berlaku under-estimate terhadap kesulitan dari pekerjaan-pekerjaan kecil dan  ber bertindak over-estime pada proyek-proyek besar yang dianggap lebih komplek dan sulit.
5. Implikasi Politik : kelompok berbeda dalam sebuah organisasi bisa memiliki tujuan berbeda. Manajer pengembang sistem informasi mungkin akan menekan pada bagian ‘estimator’ untuk mengurangi estimasi harga berdasarkan anjuran atasannya. Sedangkan pada bagian pemeliharaan berharap tidak terjadi pembengkaan biaya dan keterlambatan waktu penyerahan agar citranya tidak jelek. Sebagai jalan tengahnya, estimasi sebaiknya dibuat oleh tim khusus yang bersifat independen dari penngguna maupun tim proyek.

 A.  Dimana Estimasi Dilakukan ?

Estimasi bisa dilakukan pada tahapan yang berbeda dalam proyek perangkat lunak. Namun setiap tahap memiliki alasan dan metode estimasi yang berbeda-beda. Adapun tahapan dimana estimasi bisa dilakukan, antara lain :

1. Perencanaan Strategis (strategic planning)
2. Studi kelayakan (feasibility study)
3. Spesifikasi Sistem (system specification)
4. Evaluasi proposal supplier (evaluation of supplier’ proposals)
5. Perencanaan Poyek (project planning)        

 Dua hal yang perlu diperhatikan :

•  Karena proyek sedang berjalan, akurasi estimasi harus bisa memperbaiki pengetahuan tentang peningkatan proyek aslinya.
• Pada awal proyek, kebutuhan user merupakan hal yang sangat penting, sehingga pertimbangan yang tergesa-gesa pada implementasi fisik harus dihindari.  

B.  Problema ‘Over-Estimate’ Dan ‘Under-Estimate’

Estimasi yang berlebihan bisa menyebabkan waktu penyelesaian proyek molor dari biasanya. Hal ini bisa dijelaskan menggunakan hukum :

• Parkinson’s Law : ‘work expands to fill the time available’. Bila staf diberi target yang mudah akan bekerja kurang keras.
• Hukum Brooks’ Law : ‘ Putting more people on a late job makes it later’. Biaya yang diperlukan untuk mewujudkan sebuah proyek akan meningkat secara tidak proporsional terhadap jumlah staf yang dipekerjakan.  Bila estimasi biaya yang diperlukan berlebihan menyebabkan  jumlah staf yang dialokasikan lebih banyak dari yang diperlukan dan overhead manajemen akan meningkat.

 C.  Dasar Estimasi Perangkat Lunak

1. Kebutuhan data historis : memerlukan informasi bagaimana proyek yang telah diimplementasikan sebelumnya, terutama bahasa pemrograman dan tool yang digunakan, standar yang dipakai dan pengalaman staf.
2. Metrik pekerjaan: biasanya tidak mungkin menghitung langsung harga aktual atau waktu yang diperlukan untuk merealisasikan proyek. Waktu yang dipakai untuk menulis program bisa berbeda sesuai kompetensidan pengalaman software developer. Secara praktis, untuk mengukur volume pekerjaan didasarkan pada jumlah source lines of code (SLOC) atau function points.    
3. Kompleksitas : Telah banyak usaha yang dilakukan untuk mengukur kompleksitas secara obyektif, namun seringkali akan tergantung penilaian subyektif estimatornya.

 D.  Teknik-Teknik Estimasi Biaya Perangkat Lunak 

• Algorithmic models : menggunakann ‘effort driver’ yang menggambarkan karakteristik dari sistem target dan lingkungan implementasi untuk memprediksi biaya.
• Expert  judgement : dimana nasehat staf yang memiliki kemampuan  sangat diharapkan 
• Analogy : kemiripan, kelengkapan, proyek diidentifikasi dan biaya aktualnya digunakan sebagai dasar estimasi proyek baru.
• Parkinson : mengidentifikasi kelayakan biaya staf untuk mengerjakan proyek dan menggunakannya sebagai estimasi   (bukan merupakan metode prediksi biaya yang sebenarnya).
• Price to win : estimasi harus kelihatan cukup rendah untuk memenangkan kontrak.  
• Top-down: keseluruhan estimasi diformulasikan untuk keseluruhan proyek yang kemudian dipecah ke dalam usaha yang  diperlukan untuk komponen-komponen tugas.
• Bottom-up : komponen-komponen tugas diidentifikasi, diukur dan dilakukan estimasi sendiri-sendiri untuk kemudian dijumlahkan  

  Estimasi Bottom-Up

Pendekatan bottom-up memecah proyek ke dalam komponen-komponen tugasnya dan kemudian menghitung berapa banyak biaya yang diperlukan untuk menyelesaikan  setiap tugas tersebut.  Untuk proyek besar, proses pemecahan akan berulang hingga mendapatkan komponen yang bisa dieksekusi oleh  satu orang selama 1 hingga 2 minggu.  Setiap komponen tugas dianalisa hingga komponen sub tugasnya, yang menghasilkan Work Breakdown Schedule (WBS). Bagian bottom-up muncul ketika terjadi penjumlahan biaya yang dihitung dari setiap aktifitas untuk memperoleh estimasi keseluruhan. Pendekatan ini lebih cocok digunakan di bagian akhir tahap perencanaan proyek. Jika digunakan pada awal siklus proyek, beberapa karakteristik sistem final harus diasumsikan. 

Pendekatan Top-Down dan Model Parametrik

Pendekatan top-down normalnya dihubungkan dengan dengan model parametric (algoritma). Biaya yang diperlukan untuk implementasi proyek akan dikaitkan terutama dengan variabel yang berhubungan karakteristik sistem final. Bentuk dari model parametrik biasanya berupa satu atau lebih formula dalam bentuk : 

Effort  =  (system size) x (productivity rate)                       …….(1) 

Suatu model untuk memperkirakan biaya pengembangan perangkat lunak memiliki 2 komponen utama. Pertama, metode untuk menaksir ukuran pekerjaan pengembangan perangkat lunak (software) dan menaksir laju pekerjaan yang berhasil dikerjakan. Beberapa model parametrik (seperti Function Point ) berfokus pada sistem maupun ukuran pekerjaan, sementara metode lain (seperti COCOMO) lebih berkonsentrasi pada faktor produktifitas. 

E.  Experd Judgement

Metode ini digunakan ketika melakukan estimasi biaya yang diperlukan untuk mengubah sebagian software yang masih eksis. Estimator akan memberikan beberapa analisis dampak berdasarkan pendapat yang proporsional dengan kode yang ditambahkan. Seseorang yang telah terbiasa dengan software tersebut yang lebih tepat untuk mengerjakannya.  

F. Estimasi Dengan Analogi

Penggunaan analogi disebut juga case-based reasoning. Estimator mencari proyek-proyek yang telah selesai dikerjakan (sumber) yang memiliki karakteristik hampir sama untuk referensi proyek baru (target). Biaya yang telah dilaporkan yang sesuai dengan kasus sumber dapat dijadikan pijakan estimasi proyek target. Estimator kemudian melakukan identifikasi perbedaan sistem target dengan sumber, selanjutnya menetapkan estmasi dasar untuk menghasilakan estimasi biaya proyek baru.  Masalahnya adalah bagaimana mengidentifikasi kemiripan dan perbedaan yang sesungguhnya pada aplikasi yang berbeda, khususnya bila ada banyak proyek masa lampau sebagai gambaran. Untuk mengidentifikasi sumber yang paling dekat dengan target  biasanya menggunakan ukuran jarak Euclidian  : 

Distance = square-root of ((target_parameter₁ – source_parameter₁)² + …. + (target _parameter_n – source_parameter_n)²)                                                   …….(2) 

G. Albrecht Function Point Analysis

Albrecht telah melakukan investigasi terhadap produktifitas pemrograman dan diperlukan beberapa cara menghitung ukuran fungsional program  yang independen  terhadap bahasa pemroghraman yang telah dikodekan.  Ide yang dikembangkan disebut function pont (FP).  Dasar analisa function point adalah lima komponen utama  (external user type) :

• External input type : transaksi input untuk meng-update file komputer internal.
• External output type : transaksi data yang di-outputkan ke user, khususnya print-out laporan dan tidak termasuk yang di-displaykan ke layar monitor (termasuk external inquiry type)
• Logical internal file type : file yang dipakai oleh sistem, berupa grup data yang biasanya dipakai bersama-sama.
• External interface file type : mengikuti input dan output yang melewatkan aplikasi dari dan ke komputer lain.
• External inquire type : transaksi yang diajukan oleh user yang memberikan informasi tetapi tidak meng-update file internal.   

 Analis harus mengidentifikasi setiap external user type dalam sistem yang diproyekkan. Setiap komponen kemudian diklasifikasi  kompleksitasnya dalam  high, average ataupun low. Setiap external user type kemudian dikalikan dengan bobot tertentu (tabel 1) untuk mendapatkan skor  function point (FP) yang dijumlahkan dengan keseluruhan FP yang mengindikasikan ukuran pemrosesan informasi. Problema FP versi Albrecht bahwa pengelompokan external user type bersifat subyektif sehingga The International FP User Group (IFPUG) perlu merumuskan aturan penilaian seperti dalam tabel 2, 3 dan 4.  

 Tabel 1.  Bobot  Kompleksitas Albrecht 

 Tabel 2  Kompleksitas Tipe File IFPUG 

Eksternal IFPUG 

  Tabel 3  Kompleksitas Input

Tabel 4  Kompleksitas Output Eksternal IFPUG 

H.   Function point Mark II

Metode Mark II  mengadakan perbaikan dan  penggantian  metode Albrect (IFPUG). Sama seperti Albrecht, ukuran pemrosesan informasi pertama-tama diukur dalam Unadjusted Function Point (UFP) yang mana Technical Complexity Adjusment  (TCA) dapat diaplikasikan.  Diasumsikan bahwa, sebuah sistem informasi terdiri dari transaksi yang mempunyai struktur dasar sbb:        

Gambar 1. Model Suatu Transaksi  

Jika  sebuah sistem informasi terdiri dari  transaksi-transaksi yang memiliki struktur dasar seperti gambar 1, maka setiap transaksi UFP dihitung sbb : W_i x (number of input data element types) + W_e x (number of entity types referenced) +W_o x (number of output data element types)                                …….(3)  Dimana W_i, W_e dan W_o adalah bobot yang diperoleh dari permintaan developer yang proporsional dengan biaya yang telah dikeluarkan proyek pengembangan software sebelumnya pada bagian tersebut yang sepakat dengan  pemrosesan input, akses, modifikasi penyimpanan data dan pemrosesan output.  Jika metode FP ‘Original Albrecht’ mengidentifikasi 14 faktor pengaturan kompleksitas secara teknis, Mark II  menambah 5 faktor lagi, yaitu :

• Interface to other applications
• Special security features
• Direct acces for third parties
• User training features
• Documentation requirements 

 Jika ada gambaran besarnya  biaya yang dikeluarkan pada proyek sebelumnya dan juga ukuran sistemnya (FP), maka besarnya laju produktifitas bisa dipecahkan dengan menggunakan rumus : 

Productivity =          size/ effort                                                     …….(4) 

Untuk proyek baru , besarnya FP dapat dihitung dan kemudian biaya dapat diproyeksikan menggunakan laju produktifitas sbb : 

Effort =          size / productivity                                                   …….(5) 

Lebih bagus lagi, jika digunakan metode statistik yang disebut least squares regression dengan menggunakan persamaan :

Effort  =         constant₁ + (size x constant₂)                             …….(6) 

I . COSMIC Full Function Points

Penggunaan pendekatan FP efektif digunakan pada organisasi yang mempunyai akses informasi historis tentang proyek-proyek masa lampau, khusus perihal FP untuk setiap proyek dan biaya aktual yang diperlukan. Metode pendekatan seperti IFPUG cocok untuk sistem informasi, tetapi kurang membantu untuk aplikasi ukuran real-time atau aplikasi yang telah canggih, maka  the Common Software Measurement Consorsium (COSMIC)  memasukkan tidak hanya versi originalnya tetapi juga versi lain menjadi the COSMIC FFP method.   COSMIC sepakat dengan kebutuhan analis untuk memecah arsitektur sistem ke dalam hirarki lapisan software. Komponen software diukur dan menerima permintaan layanan dari lapisan diatasnya dan bisa meminta layanan di bawahnya. Di saat yang sama, ada juga komponen software terpisah yang berada dalam level sama  yang dihubungkan dalam peer-to-peer communication. Hal ini membantu identifikasi batas komponen software yang diakses, jumlah input yang diterima dan transmisi output. Input dan output dikumpulkan dalam data-group, dimana setiap group membawa item data bersama  yang berkaitan dengan obyek yang sama.  Grup data  dapat dipindahkan lewat 4 cara ;

1. Entri (E) : dipengaruhi oleh sub-proses yang memindahkan grup data ke dalam komponen software atas permintaan user di luar lingkupnya, bisa dari lapisan lain atau komponen software terpisah yang lain dalam lapisan yang sama lewat peer-to-peer communication.
2. Exit (X) : dipengaruhi oleh subproses yang memindahkan grup data dari komponen software ke user yang berada di luar batasan.
3. Read (R) : gerakan data yang memindahkan group data dari  storage tetap ke dalam komponen software.
4. Write (W) : Perpindahan data yang mentransfer group data dari komponen software ke dalam storage tetap.   

 Jumlah keseluruhan FFP diperoleh dari penjumlahan sederhana keempat tipe perpindahan data. Unit yang dihasilkan disebut Cfsu (COSMIC functional size units). Metode ini tidak menghitung lagi pemrosesan data yang pernah dipindahkan sekali ke komponen software.    

J.  Procedural Code-Oriented Approach

Pendekatan yang dibahas sebelumnya berguna pada tahap desain proyek dimana bahasa pemrograman prosedural tidak merupakan sarana utama untuk pengembangan. Bagaimanapun biaya pengembangan modul software individual bisa diestimasi menggunakan pendekatan bahasa prosedural, dengan step-step sebagai berikut :

1. Pertimbangkan jumlah dan tipe modul software dalam sistem final.

Yang paling mudah, dimana merupakan sistem konvensional yang telah dipahami secara baik. Semua sistem informasi dibangun dari satu set operasi kecil seperti Insert, Amend, Update, Display, Delete, Print. Prinsip yang sama bisa diterapkan pada sistem terintegrasi (embedded), walaupun fungsi primitifnya berbeda.  

2. Estimasikan jumlah SLOC setiap program teridentifikasi.

Estimator harus memilih bahasa implementasi tertentu. Untuk menaksir  jumlah instruksi menggunakan bahasa tersebut, dengan cara menggambar diagram struktur program dan memvisualisasikan berapa banyak instruksi yang diperlukan untuk implementasi setiap prosedur teridentifikasi. Estimator mungkin harus melihat program eksisting yang mempunyai kemiripan deskripsi fungsional untuk membantu proses ini.    

3. Estimasikan isi pekerjaan yang dimasukkan dalam perhitungan kompleksitas dan kesulitan modul.

Prakteknya dengan mengalikan estimasi SLOC dengan faktor kompleksitas dan kesulitan teknik. Faktor ini sangat tergantung pada penilaian subyektif estimator. Pembobotan diperlukan ketika ada hal-hal yang tak bisa dipastikan, namun jangan berlebihan.  

4. Hitung biaya hari kerja

Data historis dapat digunakan untuk memberi rasio bobot  biaya SLOC. Faktor konversi sering didasarkan produktifitas ‘standard programmer’  (kira berpengalaman 15 – 18 bulan)   

K. COCOMO (Sebuah Model Parametrik)

COnstructive  COst  MOdel (COCOMO) diperkenalkan oleh Boehm di akhir tahun 70-an hasil kajian dari 63 proyek. Model yang diusulkan bisa digunakan untuk aplikasi lain (selain sistem informasi). Model dasar yang digunakan mendekati persamaan berikut :           

Effort = c (size)^k                                                                                           …(7)

Dimana :

Effort               : jumlah ‘person-month’ (pm)

Size                : thousands of  delivered source code instructions (kdsi)

 COCOMO mengelompokkan sistem dan lingkungan pengembangannya menjadi 3 :

• Organic mode: apabila software dikembangkan oleh tim yang relatif kecil dalam lingkungan yang sangat familier dan ketika sistem akan dikembangkan sedikit, kebutuhan interface yang diperlukan cukup fleksibel.
• Embedded-mode : produk yang dikembangkan harus beroperasi dengan spesifikasi yang tepat dan bila terjadi perubahan sistem sangat memakan biaya.
• Semi-detached mode: kombinasi elemen organik dan embedded-mode dan memiliki karakteristik antara keduanya.

          Tabel 5. Konstanta COCOMO 

  Karena versi pertama dianggap kurang bagus, Boehm mengembangkan COCOMO versi intermediate dengan memasukkan 15 cost driver seperti tabel 6.                          

Tabel 6. COCOMO81 Intermediate Cost Drivers Pada model intermediate, estimasi biaya nominal (pm_nom) diturunkan sama dengan pada model dasar (basic). Sedangkan estimasi nominal kemudian diatur dengan pengali biaya pengembangan (dem)  sehingga rumus pm_est  menjadi :                  

(pm_est)  =  (pm_est)  x  (dem)                                                                  ….(8)

dimana dem dihitung dari bobot pengali berdasarkan biaya effort driver  (tabel 6). Model COCOMO sendiri terus dikembangkan, yang terbaru disebut model COCOMO II. Mengingat estimasi diperlukan pada tahapan yang berbeda-beda dalam siklus hidup sistem, maka COCOMO II telah didesain untuk mengakomodasi hal tersebut dengan menyiapkan model untuk tiga tahapan yang berbeda :  

• Komposisi Aplikasi (application composition)  

Fitur eksternal dari sistem yang diperlukan oleh pengguna didesain. Prototipe yang khas akan digunakan untuk mengerjakannya. Dengan aplikasi kecil yang dapat dibangun menggunakan application building tool, pengembangan dapat berhenti pada poin ini.

• Desain awal (early design)

Struktur software dasar didesain. Dengan meluasnya permintaan, misalnya adanya peningkatan volume transaksi dan unjuk kerja menjadi penting, perhatian yang cermat perlu diberikan untuk arsitektur yang diadopsi.

• Arsitektur akhir (Post architecture)

      Struktur software mendekati struktur final, modifikasi dan pengaturan untuk memperbaiki sistem seperti yang diinginkan masih dimungkinkan.  

 Estimasi biaya untuk komposisi aplikasi, jumlah poin obyek direkomendasi oleh pengembang COCOMO II. Hal ini mengikuti pendekatan function point  dari perhitungan fitur nyata eksternal dari software.  Hal ini berbeda dengan fokus pada fitur aplikasi fisik, seperti layar dan laporan dari pada fitur logikal seperti tipe-tipe entitas.   Pada tahap desain awal, function point direkomendasi sebagai  cara pengukuran ukuran sistem dasar. Sebuah FP mungkin dikonversikan ke dalam ekuivalen LOC dengan mengalikan FP dengan sebuah faktor untuk bahasa pemrograman yang diogunakan.  Model berikut dapat digunakan untuk menghitung estimasi person-month :  

Pm = A (size) ^(sf) x (em₁) x (em₂) x … x (em_n)                               ……(9)

Dimana :

pm          : biaya dalam ‘person-month’

A            : konstanta

Size       : jumlah FP (kdsi)

sf            : eksponen faktor skala 

Sedangkan faktor skala diturunkan dari rumus berikut :                        

sf  =  1,01 + 0,01 x ∑ (exponent driver ratings)                       ……(10) 

Kenyataannya bahwa faktor-faktor yang digunakan untuk menghitung sebuah eksponen  menunjukkan rendahnya kualitas akan meningkatkan biaya yang diperlukan tidak proporsional lebih besar pada proyek yang lebih luas.

• Precedentedness : Menunjukkan derajat lebih diutamakan, mirip dengan kasus masa lalu, untuk proyek yang sedang direncanakan. Makin banyak hal-hal baru pada sistem baru, makin besar ketidakpastian dan semakin tinggi nilai yang diberikan exponent driver.
• Development flexibility : Menunjukkan derajat dimana kebutuhan dapat ditentukan dalam banyak cara yang berbeda. Hal ini kurang fleksibel dan semakin tinggi nilai exponent driver. 
• Architecture/risk resolution : Berkaitan dengan derajat ketidakpastian tentang kebutuhan. Jika ada yang tidak meyakinkan (tidak tepat) dan  dimungkinkan berubah maka besarnya exponent driver   bernilai tinggi.
•  Team cohesion : Memperlihatkan kondisi dimana semakin banyak tim yang dibubarkan karena bertentangan dengan tim yang yang kaitannya erat sekali.
• Process maturity : Makin terstruktur dan terorganisasi software yang dihasilkan, makin rendah ketidakpastian dan makin rendah pula rating untuk exponent driver.  Dalam model COCOMO II, pengali biaya (em) sama dengan pengali biaya pengembangan (dem)  yang digunakan  dalam original-COCOMO. Ada 7 pengali yang relevan dengan desain awal dan kemudian menjadi 16 yang dapat digunakan pada arsitektur akhirnya.

Tabel 7. COCOMO II Early Design Effort Multipliers                       

  Tabel 8. COCOMO II Post Architecture Effort Multipliers 

Sama seperti COCOMO Intermediate (COCOMO81), masing-masing sub katagori bisa digunakan untuk aplikasi tertentu pada kondisi very low, low, manual,  nominal, high maupun very high. Masing-masing kondisi memiliki nilai bobot tertentu. Nilai yang lebih besar dari 1 menunjukkan usaha pengembangan yang meningkat, sedangkan nilai di bawah 1 menyebabkan usaha yang menurun. Kondisi Laju nominal (1) berarti bobot pengali tidak berpengaruh pada estimasi. Maksud dari bobot yang digunakan dalam COCOMO II, harus dimasukkan dan direfisikan di kemudian hari sebagai detail dari proyek aktual yang ditambahkan dalam database.    

PT. Rahayu  Scaffoldings merupakan sebuah perusahaan yang bergerak dalam persewaan peralatan tangga-tangga besi (scaffolding) untuk mendukung pembangunan, perbaikan maupun renovasi rumah-rumah dan gedung-gedung. Setidaknya ada  18 jenis item barang yang direntalkan oleh PT. Rahayu  Scaffoldings, seperti pipe support (TS-70, TS-90), main frame (t-190, t-170), stair, cat walk, jack base (t-60, t-40), U-Head (t-60, t-40), cross brace (p-200, p-193), join pin, leader frame (90, 60), swimple clamp, horry beam dan pipe 6 meter. Mengingat banyaknya item yang harus dikelola oleh bagian gudang (inventory), berkaitan dengan keluar-masuknya barang akibat transaksi peminjaman, pengembalian, penambahan item baru, pengurangan barang akibat rusak maupun hilang, maka perlu kiranya dibuat sistem kontrol barang “on-line” sehingga kondisi terbaru (terakhir) mulai dari jumlah barang tersisa, jumlah barang tersewa, jumlah barang rusak  maupun tambahan barang baru bisa diketahui secara cepat dan akurat.  

B.   PERMASALAHAN  

PT. Rahayu Scaffolding sebenarnya telah memiliki sistem inventory yang belum on-line. Namun seiring dengan perkembangan bisnisnya yang kian maju, menyebabkan volume transaksi bisnisnya kian meningkat, sehingga pihak pemilik (owner) memandang perlu untuk mengubah sistem inventory yang ada menjadi sistem yang bersifat “on-line” dengan kemampuan sebagai berikut :

• Mendapatkan laporan (report) yang dikehendaki secara on-line
• Menampilkan inventaris barang-barang secara on-line
• Menampilkan deskripsi barang-barang secara on-line
• File maintenance secara on-line.                  

C.   TUJUAN            

Proyek perangkat lunak  “Sistem Gudang On-Line” ini dimaksudkan :

1. Menghasilkan perangkat lunak untuk aplikasi Sistem Gudang On-Line yang memiliki fitur-fitur standar seperti menambah barang, menghapus barang, menampilkan inventarisasi barang dan pembuatan laporan dan sebagainya.
2. Memudahkan pekerjaan administrator gudang, karena bisa mendapatkan informasi barang secara cepat dan akurat..
3. Memudahkan pekerjaan up-date barang, karena ada penambahan barang baru  dan pengurangan barang akibat rusak maupun hilang.  

D.   RUANG LINGKUP  

Mengingat kendala berbagai macam media penyimpanan (storage), kinerja (performance) dan waktu responnya (time response), master file barang yang sudah ada tidak akan digunakan dalam  sistem on-line yang baru. Namun sistem lama tersebut masih dipakai dalam batch system. Sebagai gantinya, beberapa bagian file tersebut disimpan dalam File Pilihan Barang. Barang-barang yang terdapat dalam file ini akan dipilih dari master file barang dan biasanya sering diakses.

Gambar 1. Diagram Alir Sistem Gudang On- Line                                                                       

Dalam sistem gudang on-line yang akan dibuat, pengguna dapat mengetahui informasi barang yang ada seperti persediaan barang tertentu, jumlah barang dipesan, tanggal dipesan dsb. Juga tersedia fasilitas untuk menambahkan barang baru maupun menghapus barang yang sudah tidak dikehendaki ke File Pilihan Barang. Kedua operasi terakhir dilakukan melalui Tabel Pilihan Barang yang menghubungkan item-item yang ada di File Pilihan Barang ke master dan mengontrol suatu perhitungan record terakhir. Suatu Laporan Inventory Barang bisa disajikan dalam sistem gudang on-line ini.  Laporan ini bisa diminta melalui terminal  operator. Laporan ini minimal terdiri dari header dan rincian yang. memuat daftar barang persediaan dan yang dipesan.  Laporan Kontrol Pilihan juga bisa diberikan untuk membuat daftar semua perubahan pada File Pilihan Barang akibat transaksi bisnis yang terjadi. Laporan ini terdiri dari bagian rincian dan ringkasan. Bagian rincian berisi penambahan barang, penghapusan barang dan jumlah permintaan yang salah. Sedangkan bagian ringkasan berisi rekapitulasi jumlah barang yang ditambahkan maupun dihapus,  laporan ukuran dan status terakhirnya.                  

 E.   METODOLOGI  

Metodologi merupakan elemen yang paling mendasar dari suatu proses bisnis. Berikut ini adalah suatu metodologi untuk merealisasikan proyek perangkat lunak “Sistem Gudang On-Line” pada PT. Rahayu Scaffoldings, akan ditempuh langkah-langkah sebagai berikut : 

1.      Studi Kelayakan (feasibility study)

Mempelajari proses bisnis yang berlangsung di PT. Rahayu Scaffoldings, mengidentifikasi  fungsi-fungsi bisnis yang diperlukan sehingga bisa disimpulkan kebutuhan aplikasi perangkat lunak secara pasti.

2.   Desain Fungsi (Design Function)

Melakukan desain sistem secara detail, mulai dari Context  Diagram, Data Flow Diagram (DFD),  desain file, desain tabel,  relasi tabel dsb sehingga membentuk sistem lengkap sesuai dengan fungsi-fungsi bisnis yang dikehendaki.

3.      Pemrograman (Programming)

Melakukan coding untuk merealisasikan desain fungsi yang telah dibuat. Jumlah baris coding ini turut menentukan besar-kecilnya harga perangkat lunak yang dibuat.

4.      Pengujian (Testing)

Dilakukan untuk mengetahui apakah pekerjaan pemrograman telah dilakukan secara benar sehingga bisa menghasilkan fungsi-fungsi yang dikehendaki. Pengujian juga dimaksudkan untuk mengetahui keterbatasan dan kelemahan program aplikasi yang dibuat untuk sebisa mungkin dilakukan penyempurnaan. 

5.      Pelatihan (Training)

Sebelum diserahterimakan ke user, pihak developer proyek perangkat lunak bertanggung jawab melatih  user atau operator PT. Rahayu Scaffoldings yang hendak mengoperasikan program aplikasi yang telah dibuat.  Pihak pengembang juga berkewajiban memberikan informasi yang benar dan terbuka sehingga tidak menyulitkan para pengguna di kemudian hari.   

6.      Pemeliharan (Maintenance)

Proyek perangkat lunak tidak bisa selesai begitu saja setelah diserahterimakan, tetapi masih berlanjut hingga tenggat waktu yang cukup untuk memastikan bahwa produk perangkat lunak yang telah diserahkan tersebut bisa beroperasi dengan baik dan tidak ada kendala yang berarti.

7.      Dokumentasi (Dokumentation)

Dalam sebuah proyek bisa terdiri dari beberapa dokumen. Dokumen dibuat untuk melihat  kemajuan proyek yang sedang dikembangkan, sebagai referensi untuk troubleshooting bila terjadi kendala, sebagai pedoman operasional dsb. 

 F.    JADWAL PROYEK

Untuk merealisasikan pekerjaan proyek perangkat lunak  “Sistem Gudang On-Line” kurang lebih memerlukan waktu 3 bulan dengan pengaturan wakturti berikut ini :

Catatan :

• Pada setiap awal kegiatan, jadwal yang lebih rinci akan didiskusikan di antara para anggota tim.
• Pada setiap akhir kegiatan, laporan kemajuan akan disiapkan oleh pimpinan tim untuk memberikan gambaran tentang status proyek kepada pihak-pihak yang berkepentingan

G. SUMBER DAYA MANUSIA

Untuk melaksanakan proyek perangkat lunak “Sistem Gudang On-Line” disiapkan SDM 4  orang dengan peran rangkap seperti dalam tabel di bawah ini.

Biaya untuk implementasi “Sistem Gudang On-Line” diperkirakan sebagai berikut:

PERMASALAHAN

Untuk meningkatkan mutu layanan mahasiswa pascasarjana, tersedianya sistem informasi akademik khususnya dalam manajemen thesis sangat diperlukan untuk menginformasikan segala sesuatu yang berkaitan dengan penyelenggaraan seminar proposal dan sidang thesis. Perangkat lunak untuk keperluan tersebut dinamakan “Sistem Informasi Thesis(SIT)”. SIT bertujuan memberikan informasi kepada mahasiswa pascasarjana yang memerlukannya dan juga memudahkan staf karyawan administrasi dalam memberikan layanan segala sesuatu yang menyangkut pengajuan dan pelaksanaan seminar proposal dan  sidang thesis mahasiswa pascasarjana yang mengusulkannya.  Dalam SIT ini, terdapat beberapa permasalahan yang biasanya muncul berkaitan dengan usulan dan penyelenggaraan seminar proposal dan sidang thesis, seperti terlihat dalam Tabel 1. 

Tabel 1. Masalah-Masalah Yang Dihadapi Pada Thesis 

No	Masalah
1	Jumlah SKS Prasyarat
2	Topik Thesis
3	Pembimbing
4	Pendaftaran Seminar Proposal
5	Jadwal Seminar Proposal
6	Jadwal Pertemuan Bimbingan
7	Konsultasi
8	Kemajuan Pengerjaan (progress-report)
9	Ijin Menggunakan Fasilitas Penelitian
10	Pendaftaran Sidang Thesis
11	Jadwal Sidang Thesis
12	Penyerahan buku
13	Penilaian

 PERTANYAAN 

Hitung estimasi besarnya Effort (PM = Person-Months), Project Duration (D) dan Staffing (P) menggunakan pendekatan Constructive Cost Model (COCOMO) yang digambarkan oleh Boehm.  

ANALISA

• Sebenarnya sulit untuk menentukan perkiraan biaya secara tepat ketika masih dalam tahap perencanaan pengembangan proyek perangkat lunak (PPL) dikarenakan terlalu banyaknya faktor yang tidak  pasti.
• Perkiraan awal bisa disiapkan selama fase perencanaan, kemudian bisa diperbaiki pada saat presentasi persyaratan PL, dan terakhir bisa direfisi kembali pada saat presentasi perancangan awal.

Banyak metode pendekatan yang bisa digunakan untuk menghitung biaya PL, namun faktor utama yang berpengaruh dalam biaya PL adalah : 

                    a. Kemampuan programmer 

                    b. Kompleksitas produk  

                   c.      Ukuran produk     

                  d.       Waktu yang tersedia untuk pengembangan

                  e.      Keandalan yang diperlukan

                  f.        Tingkat teknologi

Untuk permasalah SIT yang terdapat dalam tabel 1 diatas, akan dibuat fungsi-fungsi  pendukung dengan perkiraan jumlah Line of Codes (LOC) seperti dalam tabel 2. 

Tabel 3.  Estimasi Fungsi-Fungsi Pendukung 

NO	FUNGSI	JUMLAH LOC
1	User interface and control facilities (UICF)	1500
2	Database management (DBM)	2000
3	Computer graphics display facilities (CGDF)	2500
4	Peripheral Control (PC)	1200
JUMLAH		7200

PERHITUNGAN

1. Menggunakan Basic COCOMO      

 Beberapa parameter yang digunakan dalam perhitungan model  Basic COCOMO   

Tabel 4.  Basic COCOMO Model 

 Perhitungan besarnya effort (PM) untuk versi Basic COCOMO (organic) :      

 PM      = a x  (KLOC) ^b                       

             = 2,4 x ( 7,2) ^1,05                       

             = 19,07262    

Perhitungan besarnya  duration (D):           

 D         = c x  (PM)^d                       

             = 2,5 x  (19,07262)^0,38                        

             = 7,6647   

Maka banyaknya orang (P) yang terlibat dalam pembuatan proyek dapat ditentukan :           

P         =  PM / D                       

            = 19,07262 / 7,6647                       

            = 2,488367

Tabel  5. Hasil Perhitungan Lengkap Basic COCOMO 

2. Menggunakan Intermediate COCOMO  

Beberapa parameter yang digunakan dalam perhitungan model Intermediate-COCOMO terdapat dalam tabel 6, dan besarnya bobot karakteristik proyek ditentukan seperti tabel  7.  

Tabel 6.  Intermediate COCOMO Model 

 Tabel 7. Besarnya Bobot Karakteristik Proyek  

* Hasil perkalian semua bobot 

Perhitungan besarnya effort (PM) untuk versi Intermediate COCOMO (organic) :      

PM      = EAF x a x  (KLOC) ^b                       

            = 1,6116399  x 3,2 x ( 7,2) ^1,05                       

            =  40,98426117    

Perhitungan besarnya  duration (D):           

D         = c x  (PM)^d                       

            = 2,5 x  (40,98426)^0,38                        

            = 10,25025125    

Maka banyaknya orang (P) yang terlibat dalam pembuatan proyek dapat ditentukan :           

P         =  PM / D                       

            =  40,98426/10,25025                       

            = 3,998366497 

 Tabel  8. Hasil Perhitungan Lengkap Intermediate COCOMO 

1. Model COCOMO Dasar  

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:

1. Proyek organik (organic mode) Adalah proyek dengan ukuran relatif kecil, dengan anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif fleksibel.
2. Proyek sedang (semi-detached mode)Merupakan proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda
3.  Proyek terintegrasi (embedded mode)Proyek yang dibangun dengan spesifikasi dan operasi yang ketat 

Model COCOMO dasar ditunjukkan dalam persamaan 1, 2, dan 3 berikut ini:     

                                                                                       (1, 2, 3)

Dimana :

• E          :  besarnya usaha (orang-bulan)
• D         :  lama waktu pengerjaan (bulan)
• KLOC  :  estimasi jumlah baris kode (ribuan)
• P           :  jumlah orang yang diperlukan.  

Sedangkan koefisien  ab, bb, cb, dan db diberikan pada Tabel 1  berikut: 

Tabel 1 .  Koefisien Model COCOMO Dasar  

2. Model COCOMO Lanjut (Intermediate COCOMO) 

Pengembangan model COCOMO adalah dengan menambahkan atribut yang dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak, yang dijabarkan dalam kategori dan subkatagori sebagai berikut: 

1. Atribut produk (product attributes)

1. Reliabilitas perangkat lunak yang diperlukan (RELY)
2. Ukuran basis data aplikasi (DATA)
3. Kompleksitas produk (CPLX)

2. Atribut perangkat keras (computer attributes)

1. Waktu eksekusi program ketika dijalankan (TIME)
2. Memori yang dipakai (STOR)
3. Kecepatan mesin virtual (VIRT)
4. Waktu yang diperlukan untuk mengeksekusi perintah (TURN)

3. Atribut sumber daya manusia  (personnel attributes)

1. Kemampuan analisis (ACAP)
2. Kemampuan ahli perangkat lunak (PCAP)
3. Pengalaman membuat aplikasi (AEXP)
4. Pengalaman penggunaan mesin virtual (VEXP)
5. Pengalaman dalam menggunakan bahasa pemrograman (LEXP)

4. Atribut proyek (project attributes)

1. Penggunaan sistem pemrograman modern(MODP)
2. Penggunaan perangkat lunak (TOOL)
3. Jadwal pengembangan yang diperlukan (SCED) 

Masing-masing subkatagori diberi bobot seperti dalam tabel 2 dan kemudian dikalikan.  

Dari pengembangan ini diperoleh persamaan:                                                           

                                                                                                                                       (4)

Dimana :

• E           :  besarnya usaha (orang-bulan)
• KLOC   :  estimasi jumlah baris kode (ribuan)
• EAF       :  faktor hasil penghitungan dari sub-katagori di atas.          

Koefisien ai dan eksponen bi diberikan pada tabel berikut. 

            Tabel 3.  Koefisien Model COCOMO Lanjut 

2.1 Persamaan Perangkat Lunak 

Persamaan perangkat lunak merupakan model variabel jamak yang menghitung suatu distribusi spesifik dari usaha pada jalannya pengembangan perangkat lunak. Persamaan berikut ini diperoleh dari hasil pengamatan terhadap lebih dari 4000 proyek perangkat lunak :   

                                                                                                                                                                                                                      (5)

Dimana :

•  E = usaha yang dilakukan (orang-bulan atau orang-tahun)
• t =  durasi proyek dalam (bulan atau tahun)
• B = faktor kemampuan khusus
• P = parameter produktivitas 

Nilai B diambil  berdasarkan perkiraan. Untuk program berukuran kecil  (0.5 < KLOC < 5), B = 0.16. Untuk program yang lebih besar dari 70 KLOC, B = 0.39. 

Sedangkan besarnya nilai P merefleksikan:

1. Kematangan proses dan praktek manajemen
2. Kualitas rekayasa perangkat lunak
3. Tingkat bahasa pemrograman yang digunakan
4. Keadaan lingkungan perangkat lunak
5. Kemampuan dan pengalaman tim pengembang
6. Kompleksitas aplikasi

Berdasarkan teori, diperoleh P = 2000 untuk sistem terapan, P = 10000 untuk perangkat lunak pada sistem informasi dan sistem telekomunikasi, dan P = 28000 untuk sistem aplikasi bisnis. 

2.2 Konversi Waktu Tenaga Kerja 

Konversi waktu tenaga kerja ini diperoleh dari angka pembanding yang digunakan pada perangkat lunak ConvertAll, dengan hubungan persamaan antara orang-bulan (OB), orang-jam (OJ), orang-minggu (OM), dan orang-tahun (OT) adalah sebagai berikut :  

                           OM = 40 OJ                                                                      (6) 

                           OT = 12 OB                                                                      (7) 

                           OT = 52 OM                                                                      (8) 

Dari persamaan di atas, diperoleh konversi orang-bulan ke orang-jam sebagai berikut : 

                           OB = (40 OJ x 52) / 12                                                    

                           OB = 173,33 OJ                                                                (9)  

3.         Model  COCOMO II 

Model COCOMO II, pada awal desainnya terdiri dari 7 bobot pengali yang relevan dan kemudian menjadi 16 yang dapat digunakan pada arsitektur terbarunya. 

Tabel 4. COCOMO II Early Design Effort Multipliers  

Tabel 5. COCOMO II Post Architecture Effort Multipliers 

Sama seperti COCOMO Intermediate (COCOMO81), masing-masing sub katagori bisa digunakan untuk aplikasi tertentu pada kondisi very low, low, manual,  nominal, high maupun very high. Masing-masing kondisi memiliki nilai bobot tertentu. Nilai yang lebih besar dari 1 menunjukkan usaha pengembangan yang meningkat, sedangkan nilai di bawah 1 menyebabkan usaha yang menurun. Kondisi Laju nominal (1) berarti bobot pengali tidak berpengaruh pada estimasi. Maksud dari bobot yang digunakan dalam COCOMO II, harus dimasukkan dan direfisikan di kemudian hari sebagai detail dari proyek aktual yang ditambahkan dalam database.  

Sebuah proyek yang komplek agar mudah dikendalikan harus diuraikan dalam bentuk komponen-komponen individual dalam struktur hirarki, yang dikenal dengan Work Breakdown Structure (WBS).

Pada dasarnya WBS merupakan suatu daftar yang bersifat top down dan secara hirarkis menerangkan komponen-komponen yang harus dibangun dan pekerjaan yang berkaitan dengannya.

Struktur WBS

Struktur dalam WBS mendefinisikan tugas-tugas yang dapat diselesaikan secara terpisah dari tugas-tugas lain, memudahkan alokasi sumber daya, penyerahan tanggung jawab, pengukuran dan pengendalian proyek. Pembagian tugas menjadi sub tugas yang lebih kecil tersebut dengan harapan menjadi lebih mudah untuk dikerjakan dan diestimasi lama waktunya.Sebagai gambaran, Work breakdown structure (WBS) dapat diilustrasikan seperti diagram blok berikut:  

Model WBS memberikan beberapa keuntungan, antara lain :

• Memberikan daftar pekerjaan yang harus diselesaikan

• Memberikan dasar untuk mengestimasi, mengalokasikan sumber daya, menyusun jadwal, dan menghitung biaya

• Mendorong untuk mempertimbangkan secara lebih serius sebelum membangun suatu proyek . 

Dikarenakan WBS merupakan struktur yang bersifat hirarki, maka bisa juga disampikan dalam bentuk skema sebagai berikut :   

Sebagai gambaran praktis, berikut ini dicontohkan sebagian dari struktur WBS dalam sebuah proyek pembangunan Intranet.

Perbedaan Level Dan Tingkat Kedetailan WBS

Setiap organisasi menggunakan terminologinya sendiri untuk mengklasifikasi komponen WBS sesuai levelnya dalam hirarki. Sebagai contoh, beberapa organisasi memperlihatkan level-level yang berbeda sebagai tugas (task), sub-tugas (sub-task) dan paket pekerjaan (work package) sebagaimana yang ditunjukkan dalam bagan diatas. Sementara organisasi lain mungkin menggunakan istilah fase (phase), entri (entry) dan aktifitas (activity).           

WBS mungkin saja disusun  mengikuti pembagian atau pentahapan dalam siklus hidup proyek ( the project life cycle). Level-level yang lebih tinggi dari struktur umumnya dikerjakan oleh kelompok-kelompok. Level yang paling rendah dalam hirarki seringkali terdiri dari aktifitas-aktifitas dilakukan secara individual, kendati demikian sebuah WBS yang menitikberatkan pada “deliverable”  tidak memerlukan aktifitas-aktifitas yang spesifik.

Melakukan rincian sebuah proyek ke dalam bagian-bagian komponen yang lebih kecil akan memudahkan pembagian alokasi sumber daya dan pemberian tanggung jawab individual. Perlu kiranya memberi perhatian pada penggunaan detail level yang layak ketika hendak membuat WBS. Dalam kondisi ekstrim, detail level yang sangat tinggi akan menyerupai hasil dalam manajemen mikro. Sedangkan kondisi ekstrim kebalikannya,  tugas-tugas mungkin akan menjadi demikian lebar untuk bisa di-manage secara efektif. Kendati demikian, menetapkan tugas-tugas dalam pekerjaan yang berdurasi beberapa hari maupun beberapa bulan merupakan hal yang baik di hampir kebanyakan proyek.

Peran WBS Dalam Perencanaan Proyek

WBS merupakan pondasi untuk perencanaan proyek. WBS dibuat sebelum ketergantungan diidentifikasi dan lamanya aktifitas pekerjaan diestimasi. WBS juga dapat digunakan untuk mengidentifikasi tugas-tugas dalam model perencanaan proyek. Oleh karena itu, idealnya rancangan WBS sendiri harusnya telah diselesaikan sebelum pengerjaan perencanaan proyek (project plan) dan penjadwalan proyek (project schedule).

Dengan memanfaatkan daftar pekerjaan pada WBS, akan dapat diperkirakan lamanya waktu yang dibutuhkan untuk menyelesaikan setiap pekerjaan tersebut. Perkiraan bisa dilakukan dengan mempertimbangan beberapa hal, antara lain ketersediaan sumber daya dan kompleksitas.

Selanjutnya dilakukan penjabaran dalam kalender (flow time). Beberapa model pendekatan bisa digunakan untuk menghitung perkiraan waktu yang diperlukan :

• Most optimistic :  Merupakan waktu ideal untuk menyelesaikan pekerjaan, diasumsikan segala   sesuatunya berjalan lancar, dan sempurna.

• Most likely :  Merupakan waktu yang dibutuhkan pada kondisi kebanyakan, tipikal dan   normal.

• Most pessimistic :Merupakan waktu yang dibutuhkan ketika keadaan paling sulit terjadi.  

 Selanjutnya, estimasi waktu dilakukan dan dibagi dalam unit (misal 8 jam/hari). Estimasi waktu untuk suatu proyek Intranet (seperti contoh diatas) lebih sulit dari proyek pengembangan aplikasi lainnya. Hal ini karena masih sedikit proyek yang dapat digunakan sebagai patokan menghitung waktu pelaksanaan.

Dalam mengestimasi waktu ini juga harus dipertimbangkan beberapa hal, misal pengalaman teknologi server yang digunakan, keahlian Perl, CGI, Java, HTML, browser, dan juga bekerja dalam lingkungan TCP/IP.

 Setelah WBS berhasil disusun dan perkiraan lama waktu pelaksanaan telah dihitung, selanjutnya dilakukan penyusunan jadwal kerja. Pada dasarnya ada dua jenis model deskripsi penjadwalan, yaitu :

§         Bar Chart :          Yang hanya menerangkan flow time dari setiap pekerjaan dan tanpa keterkaitan antar pekerjaan. Deskripsi ini paling baik digunakan pada presentasi

§         Network diagram : Yang menunjukkan keterkaitan antar tugas dan mengidentifikasi saat kritis pada jadwal.

1. Awal perkembangannya.  

Windows berkembang dari dunia komputer mikro yang serba personal. Karena khusus untuk kebutuhan desktop, Windows sangat memfokuskan diri pada kesederhanaan penggunaan, pendekatan pada sisi end user dsb. 

Linux berkembang dari dunia Unix dengan segala persoalan multi-tasking dan multi-usernya. Dengan kata lain, Linux dirancang dengan karakteristik server atau workstation high-end. Linux juga dikembangkan dengan kemampuan jaringan cukup tinggi dan sejak awal hidupnya sudah berusaha untuk berjalan pada berbagai arsitektur komputer, sehingga Linux tidak menjadikan kebutuhan desktop sebagai tujuan besar 

2. Hak Atas Kekayaan Intelektual (HAKI) 

Jika dilihat dari sisi HAKI, SO Windows dan kebanyakan program-program aplikasinya, kepemilikan lisensi (rata-rata berharga $200 USD) merupakan sarat mutlak untuk penggunannya.                                           

Sementara Linux dan program-program aplikasinya dilain pihak berlisensi gratis dan justru mendorong para penggunanya untuk menyebarluaskan perangkat lunak tersebut.

3. Kelengkapan Program
Windows tidak menyediakan banyak program setelah diinstal. Kalaupun ada mungkin hanya Internet Explorer, Media Player, Notepad, dan beberapa program kecil lainnya.Sekalipun Linux juga sebagai SO, setelah diinstal, akan ditemui banyak program dari hampir semua kategori program seperti Office Suite, Multimedia (Sound, Video, Graphics), Internet (Browser, Email, Chat, Downloader, Messenger, Torrent, News), 3D, Games, Utility, dll.

4. Program Aplikasi

Windows unggul untuk aplikasi Office-nya. Diakui bahwa Microsoft Office termasuk tool yang sangat enak untuk bekerja di PC seperti menyiapkan presentasi, tulisan, laporan, agenda dll.  Linux unggul dalam aplikasi Webserver, proxy server, firewall, mail server, Samba dll. Pada aplikasi server umumnya X-Windows tidak lagi digunakan di Linux, oleh karena itu Linux biasanya lebih hemat resources (memory & harddisk) di bandingkan Windows. Sementara komunitas Linux juga berusaha keras untuk mengejar ketinggalannya dalam aplikasi Office-nya dengan mengembangkan StarOffice yang dimotori oleh Sun Microsystems agar dapat digunakan secara cuma-cuma di atas Linux.

5. Konfigurasi Sistem
Berbeda dengan program Windows yang sudah siap pakai, di Linux ada kalanya perlu  menyunting file secara manual melalui command line. Tetapi dengan adanya PCLINUX Control Center, konfigurasi sistem bisa dilakukan dengan mudah. PCLINUX memiliki deteksi perangkat keras yang baik sehingga hampir semuanya berjalan secara otomatis. Dan hampir semua program di PCLINUX disertai dengan konfigurasi yang juga sudah siap pakai

6. Dukungan Perangkat Keras
Tidak seperti kemudahan yang ditemui di Windows, terkadang suatu hardware tidak bisa bekerja di Linux. Hal ini bisa terjadi karena pembuat hardware tidak menyediakan driver versi Linux. Untungnya, belakangan ini cukup banyak vendor yang sudah memberikan dukungan driver Linux. Dan pengenalan Linux akan hardware semakin lama semakin meningkat sehingga mulai jarang terdengar permasalahan hardware di Linux.

7. Manajemen Proses

Apabila kita tekan tombol Crtl-Alt-Del pada saat sistem menjalankan Windows akan terlihat sejumlah proses yang sedang berjalan. Kalau dihitung dari 10 dan pengguna biasa bisa mengenali sebagian besar proses-proses ini. 

Bila kita kirim perintah ps ax pada sistem Linux akan terlihat keterangan bahwa ada lebih dari 20 proses sedang berjalan. Mereka yang tidak mendalami sistem operasi tidak akan bisa mengenali sebagian besar dari proses-proses tersebut.

8. Sistem File

Windows menggunakan FAT dan NTFS. Windows tidak membedakan penggunaan nama file dengan huruf besar dan huruf kecil (case insensitive). Windows mengenal juga istilah drive untuk device dan partisi. Windows memiliki MyComputer sebagai root, yang didalamnya terdapat berbagai drive dan device. Windows juga tidak bisa membaca file sistem Linux (tanpa memanfaatkan program terpisah). Di sistem file, ekstensi nama file di Windows memiliki peranan penting. 

Sementara Linux menggunakan ext2, ext3, reiserfs, xfs, jfs dan lain sebagainya. Linux dapat membaca dan menulis ke FAT32, dan dapat membaca dan  menulis NTFS (eksperimental dan memanfaatkan proyek terpisah). Linux membedakan penggunaan huruf besar dan kecil dalam berbagai aspek penggunaan sistem operasi. Di Linux, istilah drive tidak digunakan. Yang digunakan adalah direktori biasa. Apabila dibandingkan dengan Windows, Linux mengenal direktori root (disimbolkan dengan /), yang didalamnya terdapat berbagai direktori dan device. Di Linux, ekstensi nama file tidak memiliki peranan penting. 

9. Waktu Pengoperasian 

Sebagai SO personal workstation, Windows akan sering dimatikan apabila ditinggalkan pemiliknya untuk menghemat listrik karena tidak akan ada orang lain yang akan menggunakan komputer itu.

Sistem Linux dirancang untuk bisa digunakan bersama-sama oleh banyak orang. Karena itu perlindungan berkas dan proses-proses milik seseorang terhadap orang lain menjadi porsi besar dari perhatian perancangnya. Pada sistem Linux (dan Windows NT/2000/XP) identifikasi user sangat menentukan hak akses pengguna. Karena itu akan banyak ditemui pengguna Linux yang bekerja dengan user root (nama super user di dunia Unix).

10. Proteksi Sistem

Karena sistem Windows biasanya digunakan orang tertentu saja, maka sistem proteksi berkas-berkas di komputer tidak menjadi perhatian utama dalam perancangan Windows. Kapanpun pengguna Windows bisa menghapus, mengganti nama, memindah lokasi direktori file apapun yang ada di sistem. Login bukanlah keharusan bagi pengguna Windows 9x. Dengan cancel login prompt, bisa didapatkan hak akses segalanya.

Meskipun sama-sama sebagai sistem operasi (SO) komputer, Linux dan Windows memiliki perbedaan dalam banyak hal. Karena merupakan dua dunia yang berbeda, maka hampir semuanya bisa berbeda. Software yang didesain khusus untuk Windows tidak akan berjalan pada Linux, demikian juga sebaliknya.

11. Menangani Crash
Dibandingkan dengan Windows 95/98/ME, Linux jauh lebih stabil. Namun jika mengikuti petunjuk sistemnya dengan baik, Windows XP juga cukup stabil.Unix dan Linux mempunyai sifat multi-user. Linux menjalankan aplikasi secara berbeda dengan Windows. Ketika suatu aplikasi terkunci, Anda dapat mematikannya dengan mudah. Cukup menekan kombinasi tombol Ctrl + Esc, dan dapat memilih aplikasi (atau proses) mana yang bermasalah. Dan jika sistem grafis yang terkunci, bisa berpindah ke command-prompt (dengan menekan Ctrl+Alt+F1) dan membunuh proses software secara manual. Juga tersedia pilihan untuk merestart desktop saja dengan menekan Ctrl+Alt+Backspace. Ini berarti tidak harus melakukan reboot sekalipun sistem Linux sedang mengalami masalah.

12 Sistem Sistribusi

Windows hanya mengenal satu distribusi  yaitu Microsoft. Sementara, Linux mengenal banyak distribusi yang merupakan kumpulan kernel Linux, pustaka – pustaka sistem, dan software – software yang dibungkus dengan prosedur tertentu. Yang membedakan antar distribusi bisa saja pada semua bagian tersebut (kernel yang berbeda versi dan pengaturan, software dan pustaka yang berbeda), termasuk prosedur pemaketannya.  

Kemungkinan Migrasi

Di satu pihak, Windows dalam perkembangannya menyatu dengan garis produksi server NT menjadi Windows 2000 dan kemudian Windows XP. Di lain pihak, masyarakat opensource terus mengembangan user interface grafis untuk meningkatkan kenyamanan Linux untuk penggunaan sebagai workstation pribadi. Sejak kemunculan Windows 2000 dan perkembangan user interface grafis di Linux, mulai bisa dilihat kesetaraan Windows dan Linux yakni sistem operasi untuk server dan juga untuk workstation.

Migrasi pengguna dari Windows ke Linux dan sebaliknya tidak dapat terjadi secara spontan karena faktor kebiasaan yang sulit ditinggalkan. Selama penggunaan Windows dan program-program aplikasinya tidak terhalang oleh keharusan membayar lisensi, pengguna Windows tidak akan banyak beralih ke Linux. Kesuksesan Linux di Indonesia meraih perhatian dari pengguna komputer bergantung pada hak yang berwajib dalam mengkampanyekan penghormatan pada hak atas kekayaan intelektual. 

A. Unrealistic Schedules

Jangan dikira bahwa dengan menekan jadwal secara membabi buta akan mempercepat selesainya pekerjaan, tapi justru akan menundanya. Ketika menghadapi jadwal yang tidak realistis, anggota tim teknik sering berperilaku tidak rasional.  Mereka tergesa-gesa mengerjakan ‘requirement’, menghasilkan desain yang dangkal dan melakukan coding secara buru-buru. Perjuangan yang gila untuk membangun sesuatu dipastikan akan menghasilkan  produk PL berkualitas rendah dan berfungsi salah, sangat tidak sempurna dan mengalami keterlambatan waktu.

B. Inappropriate Staffing                            

Hanya ada cara untuk menyelesaikan proyek teknik dengan cepat dan efisien yaitu dengan menempatkan sejumlah orang yang tepat dan kemudian memproteksinya dari banyaknya interupsi dan gangguan. Hal ini bisa membangun motivasi dan teamwork yang efektif, yang diperlukan untuk mendapatkan hasil yang berkualitas. Karena bila manajer gagal memberikan  waktu yang tepat, sumberdaya yang layak dan cukup terlatih, proyek tersebut  biasanya akan gagal. 

C. Changing Requirements During Development

Ketika mulai mendesain dan membangun produk, tim teknik harus mengetahui produk apa yang mereka buat. Sayangnya pihak manajemen, pemasaran dan bahkan para pengguna sering tidak mengetahui apa yang mereka inginkan. Lebih parah lagi, mereka pikir mereka mengetahuinya dan kemudian mengubahnya sebagian lewat pekerjaannya. Padahal, ketika ada perubahan kebutuhan (atau tujuan) di tahap awal pekerjaan, biasanya akan ada sesuatu  yang pada akhirnya ikut berubah. Hal ini bisa dikatakan sebagai pemborosan waktu dan biaya dan bisa mengacaukan pekerjaan

D. Poor-QualityWork

Ketika eksekutif menerapkan jadwal yang tidak realistis, proyek PL bahkan tidak hanya mengalami keterlambatan dalam pengiriman hasil produk namun hasil produknya juga tidak bisa bekerja. Ada sebuah ungkapan tentang kualitas PL “ bila tidak ada hal yang harus dikerjakan, kita bisa membuatnya sangat cepat”. Tetapi sistem akan mengalami bencana, karena setiap saat tidak bisa dipastikan perubahan  apa yang dibuat dalam produk atau ketika penggabungan produk

E.  Believing in Magic

Commercial off-the-shelf software (COTS)  merupakan cara yang menarik untuk menghemat waktu dan biaya pengembangan proyek. Tetapi COTS bukanlah sebuah peluru perak. Jika ia tidak dikelola dengan baik, bisa menimbulkan bencana. Produk COTS bisa bekerja secara sempurna untuk keperluan “demo”, misalnya bila terjadi benturan ketika diterapkan pada konfigurasi perangkat keras yang berbeda, laju data yang lebih tinggi atau bahkan bila ada kesalahan memasukkan data. Harusnya dilakukan pengujian yang cukup untuk menyingkap kondisi yang tidak pernah dicoba sebelumnya. Jika ternyata program tersebut menyusahkan pada saat dilakukan uji coba, hampir bisa dipastikan akan menemui banyak kendala ketika digunakan dalam produksi.

    1.  Name Your Project

Nama proyek. Setiap proyek memiliki nama. Untuk memulai perencanaan proyek, berilah nama yang singkat namun mewakili deskripsi proyek.

2. Type each phase in your project

 4.  Select any similar projects

        5.  Type the name of the people working on your project

Ketik nama orang-orang yang bekerja dalam proyek. Buat daftar individual atau kelompok yang mungkin  bisa menyediakan sumber daya dalam proyek, termasuk diri kita sendiri. Daftar tersebut bisa disimpan dalam “People Library”. Harapannya, para pengguna bisa memanfaatkan kontak yang ada di “People Library “  tersebut.

           6.   List the obstacles in your project

Buat daftar hambatan-hambatan yang bisa terjadi dalam proyek.  Setiap proyek memiliki  hambatan-hambatan, namun hal tersebut bisa diatasi bila telah diantisipasi sebelumnya. Buatlah daftar hambatan-hambatan yang bisa muncul dalam proyek atau klik “Obstacles Library” dan tarik contoh-contoh hambatan ke dalam daftar yang dibuat.

           7.   Assign tasks to people

Menetapkan tugas masing-masing orang yang terlibat dalam proyek. Klik pada “phase or task” di sebelah kiri. Kemudian klik pada masing-masing orang yang diinginkan mengerjakan tugas tersebut. “Ctrl-click” pada  beberapa tugas untuk menetapkannya sebagai sebuah group. Beri tanda cek pada tugas-tugas sebagai tanda bahwa tugas telah diberikan.

           8.   Review and edit your Task List

Tinjau kembali dan edit daftar tugas tersebut bila perlu. Bisa menggunakan “icon” yang tersedia untuk mengurutkan tugas, membuat sub-tugas dan menambahkan catatan dan  lampiran.

            9.   Adjust your project schedule in the Gantt chart 

 

Create  a Gantt Chart Schedule

Rencana proyek secara otomatis akan terdisplay dalam Gantt chart dan siap dilakukan penjadwalan, dimana kita bisa menambahkan tanggal dalam jadwal. Juga bisa menambahkan besarnya biaya untuk suatu pekerjaan tertentu, catatan-catatan dan prosentase pekerjaan dalam Gantt chart.   Ada 3 pilihan model Gantt chart dan bentuk laporan yang tersedia. Laporan juga bisa dicetak bervariasi, misalnya untuk anggota team, manajemen ataupun vendor. Tampilan data proyek bisa dibuat dalam berbagai cara. Pada Project KickStart 4.0 dilakukan perbaikan pada antar muka pengguna (user interface), tampilan GANNT charts, menambah warna , menambah kolom biaya, prosentase pekerjaan, kolom catatan mengikuti  “attaching links” dari pekerjaan.

Export to Microsoft Office and Other Applications

 Jadwal proyek bisa dibuat dalam program Project KickStart  itu sendiri atau bisa juga mengambil datanya dari Microsoft Outlook, Word, Excel, PowerPoint, Microsoft Project, MindManager dan ACT!  Gunakan MindManager dan WBS Chart untuk mendapatkan detail laporan, lembar kerja dan slide presentasi. Sedangkan untuk track progress bisa dalam Outlook dan ACT. Jika proyek menghendaki fitur tracking yang lebih banyak lagi bisa menggunakan Microsoft Project.Features and benefits

• Easy-to-use project management program
• Work with any size project — up to 1000 tasks and 100 resources.
• Project planning wizard gets project details organized quickly.
• Drag and drop Libraries of typical phases, tasks, goals and obstacles.
• Multi-line cut and paste. 10 levels of subtasking
• Gantt chart scheduling and tracking.
• Print a variety of Task Reports and 3 styles of Gantt chart schedules.
• Save As HTML — post project plans on your Intranet.
• Interoperability– Hot link to Outlook, Word and Excel — include project plans in proposals and business plans.
• Hot link to Microsoft Project, SureTrak, P3, FastTrack Schedule, Project Scheduler, Milestones, WBS Chart, PowerPoint, MindManager, ACT! — great for novice users.
• Includes a variety of Sample projects.
• FREE technical support.

System Requirements

• Windows Me / NT / 2000 / XP / And Now Vista
• 128 MB RAM, 25 MB free disk space
• Can also be installed on a network. Check out Tech FAQs for more details.

Standish Group telah melakukan penelitian parameter keberhasilan proyek perangkat lunak dengan mengidentifikasi alasan-alasan yang menyebabkan kegagalan proyek perangkat lunak. Untuk keperluan tersebut, proyek PL diklasifikasikan ke dalam 3 tipe resolusi yaitu resolusi tipe 1 untuk proyek sukses, resolusi tipe 2 untuk proyek challenged dan resolusi tipe 3 untuk proyek yang rusak (gagal).

Proyek dikatakan sukses (success), bila proyek tersebut bisa diselesaikan tepat waktu, biaya tidak berubah dengan fitur dan fungsi seperti yang direncanakan semula. Sementara yang termasuk tipe proyek challenged bila proyek tersebut mampu diselesaikan, namun biaya operasionalnya melebihi perkiraan, waktu penyelesaiannya menjadi molor serta menawarkan fitur dan fungsi yang lebih sedikit dari yang direncanakan. Sedangkan proyek impaired, bila proyek tersebut dibatalkan karena ada beberapa hal yang terjadi selama masih dalam proses pengembangan.

Aspek yang paling penting dari penelitian yang dilakukan Standish Group adalah menemukan sebab-sebab mengapa proyek gagal. Untuk keperluan ini jajak pendapat dilakukan pada manajer eksekutif IT untuk ditanyai pendapatnya tentang mengapa proyek bisa sukses. Ada tiga alasan utama yang bisa menyebabkan proyek PL sukses, yaitu keterlibatan pengguna (user involvement), dukungan manajemen eksekutif (executive management support) dan pernyataan jelas dari kebutuhan (a clear statement of requirement). Memang ada beberapa kriteria yang lain, namun jika tiga elemen tersebut sudah pada tempatnya, maka kesempatan poyek akan sukses jauh lebih besar. Sebaliknya, bila hal tersebut tidak terpenuhi potensi gagal bisa meningkat tajam.

Tabel 1. Kriteria Proyek Sukses

Dalam jajak pendapat tersebut, responden juga diminta pendapatnya tentang faktor apa saja yang menyebabkan proyek challenged, hasilnya seperti terlihat dalam tabel 2.

                                  Tabel 2. Kriteria Proyek Challanged   

Hasil jajak pendapat tentang opini mengapa proyek menjadi rusak dan terancam dibatalkan, faktor terbesar dikarenakan daftar kebutuhan yang kurang lengkap serta terlalu sedikitnya keterlibatan pengguna.

                                      Tabel 3. Kriteria Proyek Impaired