Project Mangement - Go Go Go

Kesimpulan - Software Effort Estimation -

2008-01-12T00:34:00.001-08:00

kesimpulan yang bisa diambil dari bab 5 tentang Software effort estimation adalah membandingkan antara teori dan praktek dalam estimasi effort yang dibutuhkan. hasil yang diperoleh dari estimasi tersebut bisa sama(kurang lebih) bisa jauh berbeda. jika terdapat perbedaan yang begitu jauh maka dapat dilakukan perbaikan pada metode yang digunakan.

terimakasih
kami ucapkan pada bapak Fajar Baskoro yang telah mengajarkan kami pada mata kuliah Manajemen Proyek Perangkat Lunak(MPPL) serta Rekayasa Perangkat Lunak Lanjut (RPLL).
Kami menyadari bahwa Mahasiswa Beasiswa Unggulan banyak kekurangan yang mungkin menyakiti bapak fajar kami ucapkan minta maaf sebesar-besarnya. semoga ilmu yang diajarkan mendapatkan barokah serta amal jariyah yang senantiasa mengirimkan pahala kepada beliau.
kami keluarga besar Beasiswa Unggulan teknik Informatika 06 ucapkan terima kasih sebesar-besarnya.

wassalam

Contoh Effort Estimation pada SIstem Informasi Daerah

2008-01-11T22:26:00.000-08:00

Berdasarkan proposal penawaran oleh PT. ZAQINA PRIMA KARSA kepada pemerintah daerah tentang pengadaan Sistem Informasi Daerah – SIMDA Pemerintahan Daerah tingkat I/II (terlampir). Untuk menganalisa berapakah effort yang dibutuhkan untuk membangun aplikasi sistem informasi daerah dengan menggunakan COCOMO adalah sebagai berikut :

Menentukan UFP (Unadjusted Function Point)
Seperti yang dijabarkan diatas, UFP terdiri dari 5 komponen. Tabel dari 5 komponen tersebut dapat dilihat dibawah.

Pada SIMDA maka dapat diambil analisa sebagai berikut :
Jenis Komponen klasifikasi bobot jumlah

1.Eksternal Input Simple 3 x 5 = 15
2.Eksternal Output Simple 4 x 5 = 20
3.User Average 4 x 10 = 40
4.Files Complex 15 x 20 = 300
5. External Interface Complex 10 x 10 = 100
Total UFP 475

Menentukan kompleksitas
Pada kompeksitas didapatkan dari perhitungan technical complexity factor (TCF). Pada TCF terdapat 14 pertanyaan yang harus diberi nilai. Pertanyaan itu adalah dari E1 hingga 14. Dari tiap pertanyaan dibawah harus diberikat bobot antara 0 hingga 5. Untuk penjelasan penentuan bobot dapat dilihat pada gambar dibawah ini.

Untuk analisa pada SIMDA untuk TCF adalah sebagai berikut
Kode Keterangan Bobot
E1 Backup dan recovery dapat dipercaya 5
E2 Komunikasi data 4
E3 Fungsi distribusi 3
E4 Performansi 5
E5 Lingkungan operasional 3
E6 Data entry on-line 3
E7 Layar interaktif untuk input 4
E8 On-line update 2
E9 Kompleksitas interface 5
E10 Bisa digunakan kembali (reusability) 4
E11 Kompleksitas proses 5
E12 Kemudahan dalam install 5
E13 Memiliki banyak site 5
E14 Mudah digunakan 4
TOTAL = 57

Menentukan FP (Function Point)
Untuk mendapatkan nilai FP (function Point) dengan menggunakan rumus

FP = UFP x (0.65+0.01 x TCF )

Dari perhitungan diatas diketahui,
UFP = 475
TCF = 57

Maka FP adalah sebagai berikut :
FP = 475 x ( 0.65 + 0.01 x 57 )
FP = 475 x ( 0.65 + 0.57 )
FP = 475 x (1.22)
FP = 579,5

Konversi FP ke NCSS ( bahasa pemrograman yang digunakan )
Setelah FP diketahui, maka pada tahap implementasi harus ditentukan penggunaan bahasa pemrograman. Maka untuk mengkonversi dari FP ke NCSS adalah berdasarkan tabel dibawah ini :

Jika pada tahap implementasi SIMDA, bahasa pemrograman yang digunakan adalah C maka konversi ke NCSS adalah sebagai berikut :
Size = FP x NCSS
Size = 579,5 x 70
Size = 40565
atau
Size = 40,565 KDSI

Menentukan tipe proyek ( berdasarkan COCOMO)
Tipe proyek pada COCOMO ada 3 buah, yaitu organic, semi-detached, dan embeded. Pada SIMDA, tipe proyek yang dikerjakan adalah semi-detach, karena memiliki sistem yang komplek akan tetapi bukan sebuah proyek yang baru. Tim yang mengerjakan adalah bisa tenaga yang berpengalaman dan tenaga yang kurang pengalaman.

Dengan tipe proyek adalah semi-detached maka konstanta :
a = 3.0
b = 1.12
karena proyek SIMDA merupaka proyek yang besar, maka perumusan untuk effortnya adalah sebagai berikut :

EFFORT = EAF x a x (SIZE) ^ b

Menentukan EAF (Effort Adjusted Factor )
Jenis-jenis EAF dapat dilihat dari gambar dibawah ini :

Karakteristik dari proyek SIMDA adalah sebagai berikut :
1. Require software reliability : high 1.15
2. Database size : high 1.08
3. Product complexity : v.high 1.30
4. Main storage constraint : nominal 1.00
5. Computer turnaround time : low 0.87
6. Analyst capability : high 0.86
7. Application experience : Nominal 1.00
8. Programmer capability : high 0.86
9. Programming language experience : nominal 1.00
10. Use of software tools : high 0.91
11. Required development schedule : nominal 1.00

Dari analisa di atas, maka dapat dihitung EAF dengan mengalikan semuanya. Perhitungannya adalah sebagai berikut :

EAF = 1.15 x 1.08 x 1.30 x 1.00 x 0.87 x 0.86 x 1.00 x 0.86 x 1.00 x 0.91 x 1.00
EAF = 0.945

Didapatkan effort yang dihasilkan
Setelah EAF, a, b, size diketahui, maka effort yang diperlukan untuk membangun sebuah software dapat dihitung. Perhitungannya adalah sebagai berikut :
EFFORT = EAF x a x SIZE b
EFFORT = (0.945) x (3.00) (40,5)1,15
EFFORT = 200

Sehingga dapat diambil kesimpulan untuk membangun software SIMDA maka memerlukan effort sebesar 200 PM (Person Month)

Durasi
Durasi adalah waktu yang diperlukan untuk membangun sebuah software SIMDA adalah sebagai berikut :

Berdasarkan perumusan diatas, bahwa tipe proyek SIMDA adalah semi-detached maka, perhitungan durasinya adalah seabgai berikut :

DURASI = 1.5 x EFFORT 0.35
DURASI = 1.5 x (200)0.35
DURASI = 15,9

Maka dapat diambil kesimpulan dari perhitungan diatas maka waktu yang diperlukan untuk membangun software SIMDA adalah 16 bulan

Staffing
Staffing adalah jumlah orang yang dibutuhkan untuk memebangun software SIMDA. Perhitungan staffing adalah sebagai berikut :

STAFFING = EFFORT / DURASI
STAFFING = 200 / 15,9
STAFFING = 12,57

Berdasarkan perhitungan diatas, maka dapat diambil kesimpulan bahwa untuk menghasilkan sebuah software SIMDA membutuhkan 13 orang

Chapter 5

2007-10-16T22:37:00.000-07:00

Obyektif

Menghindari estimasi yang tidak realistis
Memahami range dari metode estimasi yang dapat digunakan
Estimasi proyek menggunakan pendekatan butoom-up
Menghitung function point untuk sebuah system
Estimasi usaha yang diperlukan untuk implementasi software menggunakan bahasa pemrograman prosedural
Memahami pendekatan COCOMO untuk membangun model usaha

5.1 Pendahuluan
Salah satu definisi proyek yang sukses adalah systemnya dikirim “tepat waktu, sesuai anggaran, sesuai dengan kualitas yang diharapkan”. Oleh karena itu, estimasi awal haruslah tepat, karena ini sangat penting dalam sebuah proyek. Untuk estimasi itu sendiri tidaklah mudah. Faktor-faktor yang mempengaruhi antara lain :

Complesity dan invisibility
Aplikasi baru dalam software
Perubahan teknologi
Ketidak samaan dari pengalaman proyek terdahulu
Subjective nature of estimating
Beberapa peneliti menunjukkan bahwa orang cenderung meremehkan proyek yang kecil dan over-estimasi untuk proyek yang besar. Pada dunia software development dapat dikatakan untuk proyek yang besar biasanya tidak sepadan kekomplekan dan kesulitannya dibandingkan dengan yang kecil
Political implication
IOE information system development manager, dengan melihat sebayak mungkin system yang diimplementasikan, sehingga akan memberikan tekanan pada estimator untuk mereduksi biaya, sehingga untuk managememnt yang lebih tinggi dapat menyetujui proyek tersebut. Salah satu solusi untuk menghindari faktor “politik” adalah dengan menggunakan group spesialis estimasi yang independen.

5.2 Dimana Estimasi telah dilakukan ?
Estimasi terdapat bayak tahap dari proyek software. Setiap tahap, alasan untuk estimasi dan metode yang digunakan bermacam-macam.

Perencanaan strategis
Pada tahap ini, biaya dari aplikasi potensial yang terkomputerisasi dan keuntungan akan membutuhkan estimasi untuk menentukan prioritas pada setiap proyek. Estimasi tersebut juga dipengaruhi jumlah staf development yang direkrut oleh sebuah organisasi
Feasibility study
Ini memastikan bahwa keuntungan dari sistem potensial akan menentukan cost
Spesifikasi sistem
Kebanyakan metodologi pembangunan sistem berguna untuk membedakan antara definisi dari user requirement dan desain dari dokumen yang mana requirement tersebut harus terpenuhi. Usaha untuk mengimplementasi proposal desain yang berbeda perlu diestimasi. Estimasi pada tahap desain akan mengkonfirmasikan bahwa feasibility study tetap valid.
Evaluasi dari proposal supplier
Perencanaan Proyek
Perencanaan dan implementasi dari perkembangan proyek ke level yang lebih detail, estimasi yang lebih detail dari komponen pekerjaan yang lebih kecil harus dilakukan. Semakin dini estimasi yang dilakukan, ini akan membantu memberi informasi seperti kapan staff dapat menyelesaikan perkerjaannya dan available untuk aktivitas yang baru.

2 point umum yang dapat ditangkap disini adalah :

Untuk memulai proyek, sehingga akurasi dari estimasi harus ditingkatkan sebagai pengetahuan tentang nature of project meningkat.
Kebijakan yang konvensional adalah pada saat permulaan dari proyek, user requirement adalah yang sangat penting dan pertimbangan yang premature dari implementasi fisik dapat dihindari. Urutan untuk menghasilkan estimasi, estimator akan berspekulasi tentang implementasi fisik ( jumlah komponen software yang ditulis)

5.3 Problem with over- and under-estimates
over estimates menyebabkan projek akan lebih lama. Ini dapat dijelaskan dengan aplikasi dua “Law” berikut :

“Parkinson Law” ‘works expands to fill the time available’ ini memberikan target yang mudah sehingga staff bekerja kurang keras.
“Brooks Law” ‘putting more people on a late work makes it later” jika terdapat over estimates dari usaha yang dibutuhkan maka dapat menambah staff yang diperlukan dan managerial overhead akan meningkat. Ini biasanya pada proyek yang besar

Beberapa saran mengatakan bahwa proyek under-estimates mungkin tidak selesai on time atau tidak sesuai dengan biayanya, itu mungkin masih bisa diimplementasi dalam waktu yang lebih pendek dibandingkan dengan estimasi yang baik.

Bahayanya dengan under-estimates adalah berefek pada kualitasnya. Manifestasi dari under-estimates adalah “Weinberg’s zeroth Law” ‘if system does not have to be reliable, it can meet any other objective.

5.4 The basis for software estimating
The need for historical data
Semua metode estimasi membutuhkan informasi bagaimana proyek diiplementasikan pada masa yang lalu. Bagaimanapun, perhatian diperlukan untuk menentukan data yang dapat dipakai dalam pertimabangan proyek karena kemungkinan perbedaan pada faktor lingkungan seperti bahasa pemrograman, software tool, menjalankan standart, dan pengalaman dari staff

Measure of Work
Waktu yang diperlukan untuk menulis program bermacam-macam, salah satunya tergantung dari kompentensi atau pengalaman dari software developer. Waktu implementasi juga bermacam-macam karena faktor lingkungan seperti software tool yang dapat digunakan. Biasanya untuk menyatakan work content dari aplikasi yang diimplementasi secara independen menggunakan Source Line of Code (SLOC).

Untuk SLOC merupakan pengukuran yang tidak teliti. Apakah komentar akan termasuk dihitung? Apakah deklarasi juga termasuk?para peneliti tdak konsisten pada poin ini. ini tergantung dari menurut penulis, kalau comment line tidak termasuk, kalau deklarasi maka akan termasuk yang dihitung.

Perhitungan SLOC adalah sulit dimana aplication-building tool berupa tabel, diagram untuk menyimpan processing rule. Pengukuran yang berbeda untuk ukuran diperlukan seperti function point.

Complexity
Dua buah software dengan KLOC yang sama akan memakan waktu yang tidak sama., walau dengan programmer yang sama dan lingkungan yang sama. Salah satu komponen mungkin lebih komplek. Usaha estimasi berdasarkan SLOC mungkin dimodifiaksi untuk disimpan pada account. Telah dilakukan percobaan untuk menemukan pengukuran dari kompleksitas, akan tetapi itu masih tergantung pada pendapat yang subyektif dari estimator

5.5 Software effort estimation techniques
Barry Boehm, pada pekerjaan klasiknya pada software effort model, identifikasi jalur utama untuk memperoleh estimasi dari software development effort adalah :

algorithm model, yang mana menggunakan “effort drive” untuk merepresentasikan karakteristik dari target sytem dan implementasi lingkungan untuk memprediksi usaha/effort
expert judgement, dimana mengumpulkan staff yang lebih banyak
analogy, dimana kesamaan, kelengkapan, proyek yang diidentifikasi, dan usaha yang sebenarnya adalah digunakan sebagai basis dari estimasi untuk proyek yang baru
parkinson, yang mana mengidentifikasi staff effort yang available untuk melakukan proyek dan menggunakannya untuk estimasi
price to win, dimana estimasi adalah harga yang muncul cukup rendah untuk memenangkan kontrak
top-down, dimana keseluruhan estimasi diformulasikan untuk keseluruhan proyek dimana kemudian dipecah menjadi usaha yang dibutuhkan untuk komponen task
bottom up, dimana komponen task diidentifikasi dan diukur kemudian estimasi individual ini digabungkan.

Bottom-up estimating
Pendekatan bottom-up estimator, memecah proyek menjadi komponen task dan kemudian mengestimasi berapa banyak usaha yang dibutuhkan untuk setiap tasknya. Untuk proyek yang besar, proses breaking down akan dilakukan repetisi, setiap task akan dianalisa pada tiap komponen subtask. Repetisi ini dilakukan hingga komponen dapat dieksekusi oleh satu orang dalam satu atau dua minggu. Bagian dari bottom-up ditambahkan untuk mendapatkan kalkulasi usaha setiap aktivitasnya untuk mendapatkan estimasi keseluruhan

The top-down approach and parametric models
Pendekatan top-down berasosiasi dengan model parametric ( atau algoritma ). Ini dapat dijelaskan dnegna mneggunakan analogi membangun sebuah rumah. Pada prakteknya pemilik rumah memerlukan jaminan yang cukup jika propertinya rusak. Kecuali pemilik rumah membeli rumah maka akan memperkirakan mempekerjakan berapa banyak tukang batu, tukan kayu, tukang listrik dan seterusnya.

Usaha yang diperlukan untuk mengimplementasi proyek akan berhubungan dengan variabel yang berasosiasi dengan karakteristik dari final system. Formulasinya :

Effort = (system size) * (productivity rate)

Sebagai contoh, ukuran sistem mungkin berbentuk “ribuan baris kode” (KLOC) dan memiliki 3 KLOC spesifik dan produktivitasnya 40 hari/KLOC. Nilai ini seringkali menjadi bahan pertimbangan.

Sebuah model untuk meramalkan software development effort memiliki 2 komponen utama. Pertama, sebuah metode menilai ukuran dari software development task dapat dilakukan. Kedua, menilai kecepatan kerja pada task yang dapat dilakukan.

Beberapa parameter model, seperti function point, fokusnya pada system atau ukuran task, sedangkan COCOMO pada faktor produkvifitas.

Aplikasi yang dibangun itdak menggunakan kode prosedura;, ukuran driver mungkin berbeda tipe komponen. Contoh, dimana microsoft access digunakan, estimator akan menghitung table, form, function, query, report dan seterusnya.

5.6 Expert judgment
ini dugunakan untuk estimasi task effort dari seseorang yang memeniliki banyak pengalaman tentang aplikasi atau development environment. Metode ini sering digunakan ketika estimasi effort diperlukan untuk merubah bagian software yang telah ada. Estimator akan membawa beberapa analisa pengaruh untuk menilai proporsi dari kode yang terpengaruh untuk memperoleh estimasi. Sesorang yang telah terbiasa dengan software adalah posisi yang terbaik untuk melakukan ini.

5.7 Estimating by analogy
Penggunaan analogi sering disebut “case-based reasoning”. Estimator akan mencari proyek yang telah sempuna (source access) dan memiliki kesamaan karakteristik pada proyek yang baru (target case). Usaha yang telah terekam pada source code yang kurang lebih sama, maka dapat dijadikan sebagai dasar estimasi target. Estimator akan mengidentfikasi setiap perbedaan antara target dan source dan membuat penyesuaian pada dasar estimasi untuk menghasilkan estimasi usaha pada proyek yang baru.

Ini dapat menjadi pendekatan yang baik dimana anda mempunyai informasi tentang proyek sebelumnya akan tetapi tidak cukup untuk menggambarkan kesimpulan umum.
Masalahnya adalah bagaiamana anda mengidentifikasi persamaan dan perbedaan antara aplikasi yang berbeda, terutama jika anda memiliki proyek yang besar pada masa lalu. Untuk mempermudah dapat menggunakan ANGEL software tool. Ini mengidentifikasi source case yang paling dekat dengan target dengan mengukur euclidean distancenya. Euclidean distance adalah sebagai berikut :

Distance = square-root((target_parameter1 – source_parameter1)^2 + .....(taget_parameter2 – source_parameter2)^2)

5.8 Albrecht function point analyis
model top-down ditemukan oleh Allan Albrecht ketika ia bekerja pada IBM. Untuk mengukur ukuran fungsional dari program independen maka menggunakan function point(FPs)

Dasar dari analisa sfunction point sistem informasi berbasis komputer terdiri dari 5 komponen utama :

external input types
input transaksi mengupdate file komputer internal
external output types
transaksi dimana data adalah output kepada user. Biasanya berupa printed report.
logical internal file types
file yang digunakan oleh sistem
external interface file types
mengijinkan input dan output yang mana meninggalkan ke atau dari aplikasi komputer yang lain.
external inquiry types
transaksi yang dimulai oleh user yang menyediakan informasi tetapi tidak mengupdate internal file.

Tabel 5.2 Albrecht complexity multipliers

Setiap komponen kemudian diklasifikasi terhadap kompleksitas yang tinggi, rata-rata atau rendah. Perhitungan setiap tipe user external pada setiap kompleksitas dikalikan dengan bobot yang spesifik ( table 5.2 )untuk mendapatkan score FP dengan dijumlahkan untuk mendapatkan keseluruhan perhitungan FP yang mengidentifikasi ukuran information processing.

Salah satu masalah menentukan tipe user eksternal adalah tinggi, rata-rata, rendah adalah lebih subjektif. International FP User Group (IFPUG) mengeluarkan aturan untuk penentuan ini. Contohnya, pada kasus logical internal file dan esternal interface file, batasnya ditunjukkan pada tabel 5.3 yang digunakan untuk menentukan kompleksitas level.

Table 5.3 IFPUG file type complexity

Tabel 5.4 IFPUG External input complexity

Table 5.5 IFPUG External output complexity

Tabel 5.4 dan 5.5 digunakan untuk skala eksternal input dan eksternal output. Setiap eksternal inquiry telah dihitung jika eksternal input dan eksternal output yang mana score yang digunakan lebih tinggi.

5.9 Function Point Mark II
Pendekatan Mark II metode yang bagus untuk structured system analyst and design methode (SSADM). Mark II menyatakan peningkatan dan penggantian dari metode Albrecht. Seperti pada Albrecht, informasi processing size diukur pada Unadjusted function point(UFP) yang mana technical complexity adjustment dapat (TCA) diaplikasikan. Asumsinya adalah sistem informasi terdiri dari transaksi, struktur dasarnya pada gambar 5.2

Gambar 5.2 Model of Transaction

Setiap transaksi UFP dihitung :

Wi * (jumlah dari input data element types) + We * (jumlah dari entity type referenced) + Wo*(jumlah dari output data element types)

Wi, We, Wo adalah bobot yang diperoleh dengan bertanya ke developer berapa proporsi effort yang telah dikeluarkan pada project yang lalu pada bagian tersebut. Dari sini dapat diambil average hour daro pekerjaan untuk tiap tipe elemen.

Average kemudian dinormalisasi ke rasio, atau bobot, yang ditambahkan hingga 2.5. Jika cara ini membutuhkan waktu yang lama, maka beberapa industri mengambil 0.58 untuk Wi ,1.66 untuk We ,0.26 untuk Wo.

Mark II FPs mengidentifikasi 5 faktor :

interface to other application
special security features
direct access for third parties
user training features
documentation requirement

Dengan metode Albrecht dan symons, FP dapat dihitung untuk project sebelumnya dimana effortnya diketahui. Jika anda mempunyai gambaran untuk effort yang dikembangkan dari proyek yang lalu dan juga system size pada FP, anda seharusnya dapat menghasilkan pruductivity rate :

productivity = size / effort

Untuk proyek yang baru, function point dapat dihitung dan kemudian effort dapat diproyekkan menggunakan productivity rate yang diperoleh dari :

effort = size / productivity

Dengan teknik statistik least squares regression untuk mendapatkan rumus pada form :

effort = constant1 + (size * constant2)

5.10 COSMIC Full Function Points
untuk menggunakan function point approach secara efektif, organisasi perlu mengkakses historical information pada proyek yang lalu, pada jumlah tertentu dari function point untuk setiap proyek dan actual effort yang dibutuhkan. Mungkin juga membutuhkan informasi yang lain tentang karakteristik dari proyek, seperti perbdaan tipe dari proyek akan menghasilkan produktivitas rate yang berbeda

contoh, beberapa menyarankan bahwa pendekatan seperti IFPUG cocok untuk sistem informasi, tetapi tidak membantu ketika aplikasi yang realtime dan embeded. Sehingga dibangun versi yang lain dari function point – COSMIC FFP method. Full istiFunction Point (FFP)merupakan perluasan dari IFPUG yang dapat digunakan untuk real-time system dan hasilnya lebih akurat.

Pada metode function point yang ada membuat fair job dari menilai pekerjaan dengan konten business-oriented information system, karena di sistem tersebut ukuran dari prosedur internal merefleksikan sejumlah fitur eksternal dari berbagai tipe. Pada real time dan embeded system, fitur ini akan tersembunyi karena software user mungkin bukan manusia tetapi hardware device atau komponen software yang lain.

COSMIC membutuhkan analisis untuk memecah sistem arsitektur ke bentuk hirarki software layer. Komponen software dapat menerima request untuk service dari layer diatasnya dan dapat request service dari layer dibawahnya. Pada waktu yang sama, dapat memisahkan komponen software pada level yang sama yang menggunakan komunikasi peer-to-peer. Ini membantu untuk mengidentifikasi batas dari komponen software yang dinilai dan point tersebut menerima input dan mengirimkan output. Input dan output digabungkan dalam data group, dimana setiap grup membawa bersama data item yang berhubungan dengan object of interest yang sama.

Data group dapat dipindahkan dengan 4 cara :

entries(E)
yaitu berefek dengan sub proses yaitu memindahkan data group ke komponen software dari pertanyaan dari ‘user’ diluar boundariesnya
exits(X)
yaitu berefek dengan sub proses yaitu memindahan data group dari komponen software ke ‘user’ diluar boundariesnya.
reads(R)
pergerakan data yaitu memendahkan data group dari persistent storage(database) ke komponen software
writes(W)
pergerakan data yang mana mentransfer data group dari komponen software ke persistent storage

5.11 A Procedural code-oriented approach
Pendekatan sebelumnya berguna pada tahap desain dan dimana bahasa pemrograman prosedural bukan cara yang utama untuk development. Bagaimanapun, bagaimana nada dapat mengestimasi effort untuk membangun secara individu modul software menggunakan bahasa prosedural? Pendekatan adalah sebagai berikut :

mempertimbangkan jumlah dan tipe modul software pada final system
Yang paling adalah dimana sistem adalak konvensional dan mudah dipahami. Kebanyakan sistem informasi dibangun dari sistem operasi yang kecil, yaitu Insert, Amend, Update, Display, Delete, Print.
estimasi SLOC dari setiap program yang teridenfikasi
Estimator harus mempunyai bahasa imlementasi tertentu dalam pikirannya untuk tahap ini. Salah satu jalan untuk mempertimbangkan jumlah instruksi dalam program digambarkan dalam program structure diagram dan untuk visualisasi berapa banyak instruksi yang dibutuhkan untuk mengimplementasi setiap prosedur yang ada. Estimator akan melihat program yang ada yang memiliki dskripsi fungsional yang mirip untuk membantu proses ini
estimasi pekerjaan yang dilakukan pada account kompleksitas dan tingkat kesulitan teknis
Dalam praktisnya dengan mengalikan estimasi SLOC dengan faktor kompleksitas dan tingkat kesulitasn teknis. Faktor ini akan tergantung pada besarnya pertimbangan subyektif dari estimator. Contohnya, requirement yang memiliki banyak constraint akan membutuhkan programming effort yang lebih banyak
Pembobotan dapat diberikan ketika terdapat ketidakpastian, contohnya, teknik baru yang digunakan pada modul tertentu. Dimana terdapat ketidakpastian yang besar maka pengukuran yang spesifik harus dilakukan untuk mengurangi yaitu dengan menggunakan penyelidikan prototypes
mengkalkulasi work-day effort
historical data dapat digunakan untuk menyediakan rasio untuk mengkonversi bobot SLOC ke effort. Konversi faktor ini sering berdasarkan pada produktifitas dari standart programming yaitu pengalaman 15-18 bulan.

5.12 COCOMO : a parametric model
Boehm’s COCOMO ( COnstructive COst Model ) sering dirujuk pada literatur pada software project management, terutama berhunbungan dengan estimasi software.
Model dasar dibangun dengan rumus :

(effort) = c ( size)^k

dimana effort diukur dalam ppm atau jumlah dari “person-month” yang terdiri dari unit dari 152 working-hours, size diukur dalam kdsi ( thousands of delivered source code instruction ), c dan k adalah konstanta.

Langkah awal untuk mendapatkan estimasi dari ukuran sistem dalam kdsi. Konstanta c dan k ( tabel 5.6 )tergantung pada sistem dapat diklasifikasikan pada istilah Boehm’s, yaitu “organic”, “semi-detach”, “embeded”.

Organic mode
Ketika tim kecil development software sangan familiar dengan in-house environment dan sistem yang dibangun kecil dan interface requirement fleksibel
Embeded mode
Produk yang dibangun dioperasikan dengan batasan yang ketat dan perubahan pada sistem sangat mahal
Semi-detach mode
Kombinasi dari oraganic dan embeded atau memiliki karakteristik dari keduanya

Eksponen dari nilai k ketika lebih besar dari 1, berarti proyek yang lebih besar dapat dilihat sebagai ketidakseimbangan membutuhkan lebih banyak effort. Ini merefleksikan penemuan Boehm bahwa proyek yang lebih besar cenderung kurang produktif dibandingkan dengan yang lebih kecil karena membutuhkan effort yang lebih banyak untuk management dan koordinasi..

Tabel 5.6 COCOMO konstanta

Oleh karena itu nominal estimasi disesuaikan dengan membangun effort multiplier (dem) :

(pm_est) = (pm_nom) * (dem)

Multiplier ini memberi dampak pada pengurangan effort hingga 20% dengan tim yang mengenal bahasa pemrograman yang dibpakai jika dibandingkan dengan tim yang tidak familiar dengan bahasa yang digunakan. Pada faktanya, pengaruh yang paling besar terhadap produktivitas adalah kemampuan dari tim implementasi.

Contoh pendekatan, pengunaan multiplier untuk assessing the effect of analysis capability (ACAP) :
Very low 1.46
Low 1.19
Nominal 1.00
High 0.8
Very High 0.71

Tabel 5.7 COCOMO81 intermediate cost Driver

Keseluruhan dem dikalkulasi dengan mengalikan dengan multiplier yang dipilih untuk setiap cost driver pada table 5.7 untuk menghasilkan single combined multiplier

Pada COCOMO II, pendekatan ini menggunakan multiplier yang bervariasi dan nilai eksponen yang telah diset oleh expert pada inisial. Estimasi dibutuhkan pada tahap yang berbeda pada sistem life cycle dan COCOMO II yang telah didisain untuk mengakomodasi ini dengan model untuk 3 tahap yang berbeda :

Application composition
Ini adalah fitur eksternal dari sistem didisain yang mana user telah berpengalaman.
Early design
Ini adalah fundamental software structure yang didisain
Post achitecture
Ini adalah software structure yang dalam tahap final construction, modifikasi, tuning untuk menghasilkan sistem yang diinginkan

Untuk estimasi effort untuk application composition, perhitungan dari object point direkomendasikan oleh developer COCOMO II. Ini mengikuti function point approach untuk perhitungan external fitur yang terlihat dari software.

Pada tahap early design, FP direkomendasikan sebagai jalan untuk pengukuran basic system size. Perhitungan FP dapat dikonversi ke LOC yang equivalent dengan mengalikan FP dengan faktor untuk bahasa pemrograman yang digunakan.

Model berikut ini dapat digunakan untuk menghitung estimasi person-month :

pm=A(size)(sf)*(em1)* (em2)*..... (emn)

dimana pm adalah effort person-month, A adalah konstanta (pada 1998, 2.45), size diukur dalam kdsi, sf adalah exponent scale factor

scale factor diperoleh dari :

sf=1.01 + 0.01*Σ(exponent driver rating)

pada COCOMO II effort multiplier (em) mirip dengan development effort multiplier (dem) yang digunakan pada COCOMO. Terdapat 7 multiplier yang relevan ada early design dan 16 yang dapat digunakan pada tahap post architecture

Tabel 5.8 COCOMO II Early design effort Multiplier

Table 5.9 COCOMO II Post architecture effort multiplier

Linux vs. Windows - TCO Comparison

2007-10-07T21:38:00.000-07:00

SUMMARY
TOTAL COST COMPARISON

One compares the TCO difference between Standard Linux (namely the one that isn't acquired with a prepaid
support contract) and Microsoft's platform. The second compares Red Hat's managed Enterprise Linux and Microsoft's platform. Both models include costings for deployment on either a site's existing equipment or through a complete hardware refresh.

Windows Platform Solution
For our Windows platform solution, we have selected the following operating systems, backoffice technologies and office productivity tools.

Linux Platform Standard Solution
For our standard Linux platform solution, we have selected the following open source backoffice technologies and office productivity tools.

18 Price obtained from reseller (freesoftwarecdr.com).
19 Price obtained from reseller (freesoftwarecdr.com).
20 Figure obtained from netcraft.com.

NB: As Linux is generally taken to be immune from viruses in general, and from Windows viruses specifically, we have not added any virusscanning software to this list.

Linux Platform Enterprise Solution
For our enterprise level Linux solution, we have selected the following open source backoffice technologies and office productivity tools. The primary difference between the Enterprise Linux solution and the standard one is the incorporation of an ongoing support contract with the Linux vendor. The Red Hat Enterprise Linux solution is based on an annual subscription model and three (3) years' worth of annual subscriptions will need to be included in the cost.

NB: As Linux is generally taken to be immune from viruses in general, and from Windows viruses specifically, we have not added any virusscanning software to this list.

Perbedaan Linux Vs Windows (3)

2007-09-21T21:12:00.000-07:00

Partisi Harddisk
Linux tidak mengenal penamaan drive C: untuk suatu partisi. Semua drive disatukan dalam suatu sistem penyimpanan yang besar. Folder /mnt merupakan tempat untuk Anda mengakses semua media yang ada di komputer, baik partisi lain, CD-ROM, Floppy, ataupun FlashDisk.

Belakangan KDE telah memperudah akses ke media dengan menyediakan sistem Storage Media yang dapat diakses melalui My Computer ataupun file manager Konqueror.

Penamaan File
Linux menggunakan “/” untuk memisahkan folder dan bukannya “\” yang biasa digunakan DOS/Windows. Linux bersifat case-sensitive, ini berarti file “Hello.txt” berbeda dengan file “hello.txt”. Linux juga tidak terlalu memperhatikan ekstensi file. Jika Anda mengubah nama file “Hello.txt” menjadi “Hello”, Linux masih tetap mengetahui bahwa file ini adalah suatu teks. Dan ketika Anda mengklik file “Hello”, Linux secara otomatis tetap akan membuka program editor teks.

Kemudahan dan Keamanan
Anda mungkin sudah mengetahui, bahwa sebagai user biasa (bukan Root) Anda tidak bisa menulis file di sembarang folder. User biasa hanya memiliki akses tulis di folder home mereka. Sebagai user biasa, Anda tidak akan bisa mengubah bagian penting dari sistem Linux. Ini memang terkesan terlalu membatasi dan merepotkan, tetapi cara ini jauh lebih aman, karena hanya orang tertentu yang mempunyai akses Root saja yang bisa menyentuh sistem. Bahkan viruspun tidak bisa dengan mudah menyentuh sistem Linux. Itu sebabnya Anda tidak banyak mendengar adanya virus di Linux.

PENTING !!! PENTING !!! PENTING !!!
Itu sebabnya di Linux, Anda tidak disarankan menggunakan user Root untuk keperluan sehari-hari. Buatlah minimal 1 user untuk setiap komputer dan hanya pergunakan Root untuk keperluan administrasi sistem.

Hal ini berbeda jauh dengan Windows yang sangat rentan dengan virus. Ini terjadi karena user biasa di Windows juga sekaligus mempunyai hak sebagai administrator. Kebanyakan pemakai Windows tidak mengetahui hal ini, sehingga sistem mereka sangat rentan dengan serangan virus. Windows Vista sekarang telah mengadopsi sistem sekuriti Linux ini.

Defragment
Di Linux Anda tidak akan menemukan program untuk men-defrag harddisk. Anda tidak perlu melakukan defragment di harddisk Linux! Sistem file Linux yang menangani ini secara otomatis. Namun jika harddisk Anda sudah terisi sampai 99% Anda akan mendapatkan masalah kecepatan. Pastikan Anda memiliki cukup ruang supaya Linux menangani sistemnya dan Anda tidak akan pernah mendapatkan masalah deframentasi.

Sistem File
Windows mempunyai dua sistem file. FAT (dari DOS dan Windows 9x) dan NTFS (dari Windows NT/2000/XP). Anda bisa membaca dan bahkan menyimpan file di sistem FAT dan NTFS milik Windows. Hal ini tidak berlaku sebaliknya, Windows tidak akan bisa membaca atau menyimpan file di sistem Linux.

Seperti halnya Windows, Linux memiliki beberapa macam file sistem, diantaranya ReiserFS atau Ext3. Sistem ini dalam beberapa hal lebih bagus dari FAT atau NTFS milik Windows karena mengimplementasikan suatu tehnik yang disebut journaling. Jurnal ini menyimpan catatan tentang sistem file. Saat sistem Linux crash, kegiatan jurnal akan diselesaikan setelah proses reboot dan semua file di harddisk akan tetap berjalan lancar.

Perbedaan Linux Vs Windows (2)

2007-09-21T21:01:00.000-07:00

Instalasi dan Kelengkapan Program
Windows adalah sistem operasi, itu sebabnya Windows tidak menyediakan banyak program setelah diinstal. Kalaupun ada mungkin Anda hanya akan menemukan Internet Explorer, Media Player, Notepad, dan beberapa program kecil lainnya.

Ini sangat berbeda dengan Linux. Sekalipun Linux juga suatu sistem operasi, tetapi Linux disertai dengan banyak program didalamnya. Setelah diinstal, Anda akan menemui banyak program dari hampir semua kategori program. Sebut saja kategori Office Suite, Multimedia (Sound, Video, Graphics), Internet (Browser, Email, Chat, Downloader, Messenger, Torrent, News), 3D, Games, Utility, dll.

Dengan waktu instalasi yang hampir sama, Anda bukan hanya mendapatkan suatu sistem operasi tetapi juga semua program yang diperlukan untuk kegiatan sehari-hari di Linux.

Konfigurasi Sistem
Anda mungkin sering mendengar di Linux Anda perlu menyunting file secara manual melalui command line. Sebagian berita ini benar, tetapi dengan PCLINUX Control Center konfigurasi sistem bisa Anda lakukan semudah point n click. PCLINUX memiliki deteksi perangkat keras yang baik sehingga hampir semuanya berjalan secara otomatis. Dan hampir semua program di PCLINUX disertai dengan konfigurasi yang sudah siap pakai. Sebagai contoh, browser Internet telah disertai dengan sejumlah plug-ins. Tidak perlu men-download dan menginstal plug-ins flash ataupun yang lainnya.

Hardware Support
Anda sering mendengar suatu hardware tidak bekerja di Linux. Hal ini 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.

Menangani Crash
Linux secara umum terlihat sebagai sistem operasi yang stabil. Dan jika Anda membandingkan Linux dengan Windows 95/98/ME, Linux jauh lebih stabil. Windows XP – jika Anda mengikuti petunjuk sistemnya dengan baik – akan cukup stabil.

Dan seperti halnya dengan Windows, suatu saat Anda juga akan menemui masalah di Linux. Sekalipun jarang, tetapi program yang crash atau hang bisa saja terjadi. Ini adalah suatu fakta dari kehidupan di dunia komputer.

Sekalipun demikian ada beberapa perbedaan di Windows dan Linux. 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 Anda dapat memilih aplikasi (atau proses) mana yang bermasalah.

Dan jika sistem grafis yang terkunci, Anda bisa berpindah ke command-prompt (dengan menekan Ctrl+Alt+F1) dan membunuh proses software secara manual. Anda juga mempunyai pilihan untuk merestart desktop saja dengan menekan Ctrl+Alt+Backspace. Ini berarti Anda tidak harus melakukan reboot sekalipun sistem Linux sedang mengalami masalah.

Perbedaan Linux Vs Windows (1)

2007-09-21T20:48:00.000-07:00

Ada banyak persamaan dan ada pula banyak perbedaan antara Linux dan Windows. Mari kita lihat beberapa perbedaan yang ada di Linux dan Windows.

User Interface
Di Windows, Anda tidak banyak memiliki pilihan user interface. Sebagai misal, di Windows 95/98 Anda hanya mengenal user interface bawaan Windows 95/98. Anda sedikit lebih beruntung jika menggunakan Windows XP, karena Anda bisa berpindah dari interface milik Windows XP ke Windows 98 yang lebih ringan.

Di Linux, Anda bisa menemukan banyak macam user interface. Dan biasanya pilihan user interface ini dapat Anda sesuaikan dengan spesifikasi komputer atau lingkungan kerja Anda. Sebagai misal, pada komputer yang lambat Anda bisa menggunakan user interface yang ringan, seperti XFCE atau Fluxbox.

Atau jika Anda menyukai gaya Mac, Anda bisa memilih desktop model GNOME atau menggunakan utility Docker. Dan jika Anda terbiasa di Windows dan memiliki komputer yang cukup cepat, Anda bisa memilih desktop KDE.

Dengan KDE, Anda masih bisa memilih untuk menggunakan gaya Windows XP ataupun Windows Vista. Pilihan dan variasinya sangat banyak di Linux, Anda bisa mengatur sesuai dengan favorit Anda.

Sekuriti dan Virus
Salah satu masalah utama di Windows yang paling sering Anda temukan adalah virus dan spyware. Dari tahun ke tahun permasalahan ini bukan semakin mengecil tetapi malah semakin membesar. Ini semua terjadi karena banyak lubang keamanan di Windows yang bisa dieksploitasi oleh orang-orang yang tidak bertanggungjawab.

Linux diturunkan dari sistem operasi Unix yang memiliki tingkat sekuriti lebih kuat. Itu sebabnya tidak ada banyak virus di Linux dan kalaupun ada tidak bisa berkembang biak dengan pesat dan biasanya tidak mampu membawa kerusakan yang besar.

Sekalipun tidak sepenting di Windows, Anda tetap bisa menemukan program-program anti virus di Linux, seperti ClamAV dan F-Prot. PCLinux telah menyediakan anti virus ClamAV yang bisa ditemukan pada menu Start > Applications > FileTools > KlamAV.

Spyware
Spyware adalah suatu masalah yang cukup umum di dunia Windows. Biasanya program spyware mengamati, mengumpulkan dan mengirimkan data Anda ke suatu server. Untuk hal yang lebih positif, program ini biasanya dipergunakan untuk keperluan marketing.
Sayangnya, ada juga yang berniat buruk yaitu dengan mencuri identitas, kartu kredit, dan tindakan negatif lainnya.

Tidak banyak program spyware yang menginfeksi Linux mengingat cara kerja Linux yang lebih susah untuk ditembus. PCLinux telah menyediakan pre-instal Firewall untuk melindungi sistem Anda dan bisa diaktifkan melalui PCLinux Control Panel.

2007-09-17T20:00:00.000-07:00

MinuteMan Plus Management Software Version 7.1L
Website : www.minuteman-system.com
Trial : 21 hari

MinuteMan-Plus program yang mudah digunakan untuk melacak multiple proyek. Itu dikombinasikan dengan high-level cross-project overview capability secara detail pada jalur kristis manajemen proyek dari penjadwalan, staffing, dan pengeluaran. Jika hanya membutuhkan untuk menjaga track dari awal hingga akhir dan staffing, maka dapat menggunakan Project Summary view. Untuk proyek yang membutuhkan ketelitian, maka dapat di buka setiap proyek yang memiliki hingga 200 tugas individual dan milestone dengan PERT dan Gantt chart capabilities, task outline numbering, dan seterusnya. Walaupun dengan jadwal yang detail, akan dapat mencek kebelakang dan melihat keseluruhan proyek dari level yang tinggi. Kalender kerja multishift yang umum menetapkan hari kerja dan non-kerja dan hari libur. Sebagian besar laporan dan chart dapat dicostumize. File output berupa text dan grafik dapat digunakan pada pengolah kata, spreadsheet, dan e-mail.

View dari Minuteman adalah sebagai berikut :

Contoh Proyek :

Stafing for Project Management

2007-09-10T15:14:00.000-07:00

source : http://www.computereconomics.com/article.cfm?id=1174

Agar bisnis menjadi lebih bergantung (dependent) pada teknologi informasi, kemampuan dari organisasi ITuntuk mengirim system yang baru secara efektif dan kemampupuan menjadi sangat penting. Pada banyak organisasi, nerdasarkan catatan yang ada banyak proyek IT yang gagal. Anggaran dan Jadwal melebihi dari perkiraan, dan system yang baru sering terjadi kegagalan untuk memenuhi dari requirement yang ada. Pada kasus yang terburuk, project tidak dilanjutkan dan tanpa pembayaran. Oleh karena itu konsistensi pada proyek IT sesuai jadwal, anggaran yang sesuai, sesuai spesifikasi menjadi sangat penting sehingga akan menentukan sukses atau gagalnya proyek IT tersebut.

Pada lingkungan yang seperti itu, peran dari manager proyek sangat penting. Walaupun manager proyek secara umum tidak memiliki tanggung jawab secara langsung terhadap proyek, seperti desain system, kode program, ataupun dokumentasi, manager proyek secara individual bertanggung jawab untuk memastikan bahwa proyek berjalan secara sempurna berdasarkan rencana yang telah dibuat.

Seorang manager memiliki kemampuan dan pengatahuan yang unik dengan manager yang lain, maka banyak perusahaan telah membangun sebuah formal Project Management Office (PMO) yang menyediakan keahlian manajemen proyek yang dibutuhkan oleh organisasi IT. Dalam beberapa organisasi, PMO sebagai kelompok penasihat kepada manager proyek yang melaporkan secara langsung kepada unit-unit bisnis. Pada organisasi yang lain, manajer proyek melaporkan secara langsung pada PMO dan ditugaskan pada proyek yang berbasis kasus per kasus. Pada salah satu kasus, salah satu keuntungan mempunyai PMO sebagai suatu kelompok yang terpisah, adalah fokus. PMO menyediakan suatu lingkungan dimana profesional IT yang mana memberikan petunjuk seperti manager proyek dapat dilatih secara formal prinsip dan teknik dari manajemen proyek, seperti yang terdapat dalam program sertifikasi Project Mangement Institute. PMO juga menyediakan tempat, dimana tool manajemen proyek seperti product planning, dan scheduling system, dapat dipilih dan diimplementasi sehingga sehingga dapat untuk penyebaran yang cepat ketika proyek diluncurkan.

Project Management Staffing dengan Ukuran dan Struktur yang Bervariasi

Karena manajemen proyek adalah suatu fungsi kunci dai dalam organisasi IT, pengorganisasian yang baikadalah penting. Untuk memahami tren yang ada didalam project managment staffing studi terhadap IT Spending, Staffing, dan Tren Teknologi, menyelidiki peran dari manager proyek dan PMO kurang lebih 200 Organisasi.

Keseluruhan, 90% dari CIO dan Manager IT senior mensurvei penggunaan laporan penggunaan dari manager proyek sebagai suatu posisi staff IT yang terpisah. Bagaimanapun, seperti yang ditampilkan pada gambar 1, ada suatu korelasi positif antara rasio antara manager proyek dan staf IT dan ukuran dari organisasi. (perusahaan kecil mempunyai pendapatan tahunan kurang dari $250juta, perusahaan medium antara $250juta sampai $750juta, dan perusahaan besar lebih dari $750juta).

Secara keseluruhan, ratio rata-rata manager proyek terhadap staf IT adalah 2.4%. Pada perusahaan kecil hanya 1.6% dari staff adalah manager proyek. Pada perusahaan menengah, ratio meningkat 2.5%, ketika perusahaan besar memiliki manager proyek ratio terhadap staf adalah 2.8%. kecenderungan ini menunjukkan bahwa ukuran organisasional meningkat, kebutuhan terhadap manager proyek IT juga meningkat.

Versi lengkap dari report ini juga menyediakan suatu uraian pemakaian PMO oleh ukuran organisasi, metriks untuk pengukuran performa dari project management office. Itu juga mengidentifikasikan sebagian dari praktek-praktek terbaik dari manager proyek yang paling efektif.

Sementara manajemen proyek adalah salah satu dari kebanyakan tantangan pada organisasi IT modern, potensial untuk payback adalah salah satu fungsi yang paling penting. Fungsi manajemen proyek, oraganisirnya harus cukup baik, dan setiap pelaksanaan fungsinya harus cukup terlatih. Untungnya, tubuh dari manajemen proyek dari pengetahuan adalah dirumuskan dengan baik. Meskipun demikian, terlalu sedikit oraganisasi-organisasi IT secara konsisten menerapkan pengetahuan itu pada usaha proyek nyata mereka.

Project management office adalah sebuah bagian penting dari pentransferan teori manajemen proyek ke dalam praktek. PMO menyediakan suatu lingkungan yang profesional dimana manager proyek dapat belajar dari pengalaman satu sama lain dan mengembangkan praktek manajemen proyek yang terbaik demi kepentingan seluruh organisasi.

Staffing

2007-09-10T15:08:00.000-07:00

Source : http://en.wikipedia.org/wiki/Staffing

“Menemukan orang yang tepat, dengan skill yang tepat, kemampuan yang tepat, yang mana untuk direkrut atau yang telah bekerja untuk perusahaan”.

Pada Ilmu ekonomi, dimana talenta menjadi modal baru, sehingga dapat membantu perusahaan untuk mencapai gol ( keuntungan )yang akan dicapai pada setiap marketplace mereka.

Staffing juga merujuk pada industri atau tipe dari perusahaan yang menyediakan fungsi untuk mencapai keuntungan. Staffing Company menawarkan banyak macam service, termasuk bantuan temporal, penempatan permanen, penempatan temporal ke permanen, kontrak jangka panjang dan kontrak, outsourcing, training, kunsultan SDM, dan susunan PEO (Professional Employer Organization) yang mana firma staffing beraumsi bertanggung jawab untuk payroll, keuntungan, dan fungsi SDM.

Mengenal Organisasi dan Manajemen

2007-09-10T14:50:00.000-07:00

Dilema seorang Manager : situasi kerja dalam kantor yang harus dilakukan dan merupakan rutinitas, akan berdampak pada kejenuhan dalam mengerjakannya. Masalah tersebut telah diuraikan oleh Steven P. Siegel yang menjadikan sebuah pekerjaan rutinitas dan terstandarisasi menjadi pekerjaan yang amat dicintai para karyawannya dengan semangat baru tiap harinya.

Hal yang dilakukan siegel :

Setiap karyawan tidak memiliki kantor atau meja sendiri

Bersifat nomaden karena mempunyai barang bergerak ( berkas, hp, laptop ) yang selalu dibawa ke tempat yang baru.

Lapangan golf diletakkan di pusat segala aktifitas (desain kantor terbuka)

Menciptakan peluang para professional untuk berkumpul tanpa dinding atau ruang yang menghalangi

Menempatkan layar lebar sehingga pengunjung dapat melihat tentang bisnis, kehidupan dan inovasi.

Yang dihasilkan adalah suasana kantor yang PANDAI, NYAMAN, UNIK.

Question !!???

Siapa manajer itu ?

Apakah manajemen itu ?

Apa yang dilakukan manajer ?

Apakah organisasi itu ?

Mengapa perlu mempelajari manajemen ?

Siapakah Manajer Itu ?

Manajer : Seseorang yang bekerja dengan dan melalui orang lain dengan mengkoordinasikan kegiatan pekerjaan mereka guna mencapai sasaran organisasi

Oraganisasi berstruktur tradisional : oraganisasi yang jumlah karyawannya lebih besar di bagian bawah dari pada di puncak.

Pengklasifikasian manajer berdasarkan organisasi tradisional :

Manajer Puncak :

Manajer di dekat tingkatan puncak organisasi yang bertanggung jawab membuat keputusan yang meliputi keseluruhan oraganisasi dan menyusun sasaran serta rencana yang mempengaruhi oraganisasi secara keseluruhan.

Ex: wakil presiden pelaksana (executive vice president), presiden, direktur pelaksana, kepala operasi , CEO ( Chief Executive Officer), pimpinan dewan direktur ( Chairman of the Board).

Manajer Menengah :

Manajer di antara tingkatan lini pertama dan tingkatan pucak oraganisasi yang mengelola pekerjaan para manajer lini.

Ex: Kepala bagian atau biro, pimpinan proyek, manajer pabrik, atau manajer divisi.

Manajer Lini Pertama :

Manajer [ada tingkat yang paling rendah dalam organisasi yang mengelola pekerjaan karyawan non-majenarial yang terlibat dalam produksi dan penciptaan produk organisasi.

Ex: Penyelia(supervisor), manajer lini, manager kantor, mandor/foremen.

Apakah Manajemen Itu ?

Manajemen : Proses pengkoordinasian kegiatan-kegiatan pekerjaan sehingga pekerjaan tersebut terselesaikan secara efisien dan efektif dengan dan melalui orang lain.

Dalam manajemen terdapat proses yaitu menggambarkan fungsi-fungsi yang sedang berjalan atau kegiatan utama yang dilakukan manager. Fungsi-sungsi tersebut lazimnya disebut dengan merancang, mengorganisasi, memimpin, dan mengendalikan.

faktor yang sangat diperhatikan dalam manajemen adalah efisiensi dan efektifitas.

Efisiensi : memperoleh output yang terbesar dengan input yang terkecil

Efektivitas : menyelesaikan kegiatan-kegiatan sehingga sasaran organisasi dapat tercapai

Apa yang akan dikerjakan Manajer?

to be continued............

Project Planning : Undertanding the work

2007-09-03T21:19:00.000-07:00

Disini akan dijelaskan systematic model untuk membangun sebuah project, dengan membandingkan dua buah pendekatan untuk memecah sebuah project menjadi bagian-bagian yang dapat dikontrol :

The work breakdown structure
The project breakdown structure

Kenapa kita membutuhkan sebuah perencanaan (plan)?beberapa alasannya adalah sebagai berikut :

Membangun information system merupakan pekerjaan yang kompleks, biasanya melibatkan gabungan dari beberapa elemen ( hardware, software, capture, user training dan sebagainya).
Orang-orang yang terlibat dalam sebuah project harus mengetahui aturan yang ada, apa yang mereka harapkan untuk menghasilkan dan kapan itu diinginkan. Project plan mengkomunikasikan informasi ini ke semua yang terlibat.
Customer menginginkan developer mengetahui siapa mereka sebenarnya. Perencanaan adalah demonstrasi yang nyata yang mengingatkan pekerjaan yang terlewatkan dan developer benar-benar memiliki ide kemana mereka akan pergi.

Tanpa perencanaan, bagaimana seorang manager mengetahui project sesuai dengan jadwal, lebih cepat atau lebih lambat, dan aksi perbaikan apa yang diperlukan?

Understanding the requirement

Starting poinnya adalah apa sebenarnya yang dibutuhkan sebuah project untuk mencapainya ? yang seharusnya adalah project akan diawali dengan requirement specification. Yang mencover dan detail dari level, akan bergantung pada dimana kita pada project lifecycle.

Contoh :

Jika kita memulai IS strategi study, maka requirement mungkin akan sangat tersebar – contoh : study mungkin akan memasukkan semua aktifitas yang berkontribusi pada business’s market strategy.
Feasibility study memiliki focus yang menyempit – contoh : menguji kepraktisan dari automating stockchecking pada gudang.
Keseluruhan project IS meliputi analysis, design, specification, development and implementasi dari information system membutuhkan lebih banyak definisi yang tepat dari requirement untuk memulainya.

Seringkali pada pengumpulan sebuah requirement, justru yang didapatkan adalah sebuah spesifikasi yang sangat tidak mencukupi. Oleh karena itu seorang project manager mampu melakukan analisa resiko yang teliti dari sebuah project dan mengidentifikasi lubang pada specification. Lubang ini harus didiskusikan dengan customer dan setiap asumsi harus terdokumentasi dan diterima oleh kedua pihak.

Analysis merupakan aktifitas yang pertama dari sebuah pekerjaan, dan mungkin tahap yang paling penting pada proses perencanaan. Pada akhirnya, project manager harus memiliki idea apa yang dibutuhkan dari sebuah project untuk mencapainya.

Breaking down the work

1. Work breakdown structure

Work breakdown adalah merupakan pendekatan yang tradisional dan telah digunakan banyak industry untuk waktu yang lama. Ide dasarnya adalah mengamambil secara keseluruhan pekerjaan ( project ) dan membaginya menjadi lebih kecil dan lebih kecil sampai menjadi individual task, atau work package, sehingga kita dapat mengestimasi dengan pantas dan memilih anggota tim.

Contoh sebuah IS project, feasibility study untuk pemilik merchant untuk melihat apakah terdapat scope untuk pengenalan komputerisasi stock control system. Berdasarkan project tersebut, maka pekerjaan dapat dipecah menjadi 2 bagian yaitu sebagai berikut :

Gambar 1.1 : work breakdown structure : top level

Gambar 1.2 : work breakdown structure : second level

Gambar 1.3 : work breakdown structure : third level

Gambar 1.4 : work breakdown structure : bottom level

Dari gambar di atas, maka work break down akan berjalan hingga :

Cukup atomic, hingga tidak dapat dibagi lagi atau pemilihan lebih dari 1 orang
Cukup kecil untuk mengestimasi dengan akurasi tertentu

Beberapa departemen IT dan system perusahaan memiliki standart work breakdown structures(WBSs) berdasarkan mengalaman mereka terhadap proyek yang pernah dikerjakan. Kekurangan dalam menggunakan WBS ( atau standart yang lain ) adalah setiap project memiliki beberapa fitur yang berbeda dan menjadi sebuah perhatian untuk tidak mencocokkan atau menyesuaikan sebuah project dengan pendekatan standarisasi. Jika tetap menggunakan standarisasi yang telah ada, maka standarisasi tersebut harus di ubah dan disesuaikan dengan setiap project.

2. Product breakdown structure

Keuntungan dari product breakdown adalah :

Dapat memastikan bahwa project focus pada apa yang akan dicapai
Ketika pendekatan pada area kerja yang baru, terkadang sulit untuk mempertimbangkan

to be continued.........................................

2007-06-19T21:11:00.000-07:00

UAS RPLL - PERMASALAHAN & STUDI KASUS 2

2007-06-19T20:38:00.000-07:00

Dalam suatu proyek yang berhubungan dengan sistem informasi, pasti melibatkan suatu proses pengambilan keputusan, dimana ada seorang manajer yang harus membuat keputusan yang paling sesuai dengan kondisi proyeknya saat itu. Studi kasus ini mengangkat topik mengenai lima proses pengambilan keputusan beserta dengan permodelan yang dapat digunakan untuk proses pengambilan keputusan mana yang terbaik untuk kasus yang sedang dialami oleh seorang manajer. Untuk lebih memperjelas mengenai permodelan proses pengambilan keputusan ini, studi kasus ini memberikan suatu contoh kasus :

” Mr.X selaku manajer sebuah software project yang mengalami masalah dengan deadline project-nya, dan masalah-masalah lain, untuk itu manajer tersebut harus mengambil suatu keputusan agar dapat menyelesaikan software projectnya dengan baik dan sesuai jadwal.

Mr.X sedang mengalami berbagai permasalahan, yaitu project’s budget dipotong 10%, top programmer dalam project akan dipindahkan dan diganti dengan orang lain, dan permasalahan yang terakhir adalah laporan tahap pertama tidak sesuai dengan keinginan user (manajer marketing). ”

Jika dianalisa, permasalahan pertama dan kedua merupakan masalah yang berhubungan dengan orang (people problem), yang menyebabkan pembagian tugas dalam project tersebut harus ditata ulang dan seluruh pekerja dalam tim harus ekstra kerja keras agar project dapat selesai tepat waktu dengan anggaran kecil. Sedangkan untuk menyelesaikan permasalahan yang ketiga, Mr.X harus lebih melibatkan manajer marketing dalam proses pembuatan software.

Proses Pengambilan Keputusan
Menurut Vroom & Yetton ada lima cara proses pengambilan keputusan:

1. Authorian-I (A I)
menyelesaikan masalah yang terjadi dengan sendiri tanpa melakukan diskusi dengan anggota kelompok lain.

2. Authorian-II (A II)
mencari informasi untuk menyelesaikan masalah.

3. Consultative-I (C I)
konsultasi dengan orang lain untuk menyelesaikan masalah

4. Consultative-II (C II)
konsultasi dengan kelompok, hal ini lebih ditekankan pada diskusi dengan kelompok.

5. Group Participation (GP)
diselesaikan dengan melibatkan seluruh anggota proyek dan ditekankan pada diskusi besar dengan seluruh anggota proyek.

Dalam tahap pengambilan keputusan dengan menggunakan model Vroom-Yetton ini, langkah pertama yang harus dilakukan seorang manajer proyek adalah menjawab sejumlah pertanyaan sebagai berikut:
1. Apakah terdapat requirement khusus
2. Apakah informasi yang saya miliki sudah cukup untuk membuat keputusan
3. Apakah problem yang ada sudah terstruktur
4. Apakah keputusan tersebut akan diterima secara kritis oleh tim proyek
5. Apakah keputusan saya akan diterima oleh tim proyek
6. Apakah anggota tim proyek saling berbagi tujuan organisasi
7. Apakah konflik yang ada dapat diselesikan dengan keputusan tsb
8. Apakah anggota tim proyek memiliki cukup informasi untuk membuat keputusan
9. Proses keputusan yang memungkinkan
10. Pilihan (kriteria untuk pilihan)

Semua pertanyaan-pertanyaan diatas kemudian dipetakan pada sebuah tree sebagai berikut:

Keterangan huruf abjad A sampai dengan H menunjukkan pertanyaan-pertanyaan yang sebelumnya telah dijelaskan. Ketika seorang manajer proyek menjawab pertanyaan-pertanyaan tersebut, pada akhirnya ia akan bertemu dengan node akhir (pada gambar diatas node terakhir ditandai dengan angka 1 sampai dengan 17). Node akhir ini menunjukkan kandidat keputusan yang dapat diambil seorang manajer proyek. Penjelasan dari tiap node tersebut adalah sebagai berikut:

1. A I, A II, C I, C II
2. GP

3. A I, A II, C I, C II, GP

4. A I, A II, C I, C II, GP

5. A I, A II, C I, C II

6. GP

7. GP

8. C II
9. C I, C II

10. A II, C I, C II

11. A II, C I, C II, GP

12. A II, C I, CII, GP

13. C II
14. C II, GP
15. C II, GP
16. GP
17. GP
18. C II

Pada kasus Mr. X untuk menanggulangi penyusunan ulang pembagian tugas kerja, Mr.X memperoleh alternatif nomor 15 yaitu model pengambilan keputusan CII atau GP, dimana Mr.X harus memilih keputusan mana yang lebih cocok untuk diterapkan dalam menaggulangi masalah yang ada. Pada akhirnya Mr. X memilih pengambilan keputusan dengan cara CII dimana pengambilan keputusan dilakukan dengan cara mengkonsultasikan masalah yang ada dengan kelompok. Alasan mengapa CII dipilih adalah karena penerapan CII membutuhkan waktu yang lebih singkat daripada GP.

Kesimpulan dari studi kasus ini menyatakan bahwa seorang manajer harus memiliki kemampuan untuk memilah isu yang ada dalam proyeknya dan membuat keputusan yang sesuai dengan keadaan serta efektiv untuk diimplementasikan pada isu yang bersesuaian. Model Vroom-Yetton menyediakan sistematik yang cocok digunakan oleh manajer untuk memperkirakan masalah yang dihadapi serta keputusan apa yang paling efektif untuk mengatasinya. Model ini juga lebih menekankan manajer untuk lebih konsentrasi pada masalah yang ada dan membatu manajer untuk memilih keputusan yang terbaik.

UAS RPLL - PERMASALAHAN & STUDI KASUS 1

2007-06-19T20:25:00.000-07:00

PERMASALAHAN & STUDI KASUS 1 - TESTING

Permasalahan yang sering timbul dalam suatu proses pengembangan adalah :
* perilaku dari programmer yang bisa jadi cukup menjengkelkan manajemen, yaitu programmer tidak melakukan pengujian dengan baik dan benar. Terkadang programmer hanya memperbaiki program, kemudian melakukan kompilasi. Jika kompilasi sudah tanpa kesalahan, programmer menganggap bahwa program telah benar.

* spesifikasi program dari perancang aplikasi tidak selalu disertai dengan kasus uji, sehingga sering kali pengujian dilakukan oleh programmer tidak seperti yang diharapkan. Jadi ala kadarnya.

SOLUSI

Persiapan Pengujian Software
Pengujian software (software testing) membutuhkan persiapan, sebelum pengujian dilakukan. Mengapa? Karena proses testing harus dilakukan secara sistematis, tidak bisa secara sembarang, karena software yang dihasilkan harus bebas dari error, untuk mengurangi resiko kerugian yang akan diderita oleh penggunanya. Produk software harus menguntungkan penggunanya pada saat digunakan.

Berikut persiapan yang dapat dilakukan untuk dapat melakukan proses testing:
1. membuat checklist
a. list yang akan ditest
b. list requirement
c. list rancangan
d. list spesifikasi
e. list manual, jika sudah ada - biasanya diperlukan untuk pengujian oleh user

2. pembuatan test case
a. merupakan elemen dasar yang harus ditesting
b. merupakan list yang independent

3. pembuatan grup test case
a. kumpulan dari beberapa test case
b. merupakan list yang akan memiliki status hasil test

4. pembuatan modul test
a. pembuatan skenario testing
b. terdiri atas beberapa grup test case
c. diasosiasikan dengan fungsionalitas modul
d. mengacu kepada dokumen requirement dan desain/spec program
5. pembuatan package testing
6. pembuatan produk test

Dengan dimilikinya checklist, kita akan dapat mengetahui progress dari kegiatan testing itu sendiri. Mana yang sudah selesai dilakukan test, mana yang belum. Mana yang sudah dilakukan test pun, bisa diketahui mana yang benar modulnya sudah selesai, dan mana yang belum selesai. Jadi tidak sekedar mengetahui mana yang sudah dan mana yang belum.
Pekerjaan persiapan juga membutuhkan software yang dapat membantu proses persiapan testing ini. Yang paling sederhana adalah dengan menggunakan Excel, jika memungkin menggunakan aplikasi yang dirancang khusus. Produk yang open source adalah TestLink.

Software Tester
Profesi software tester (penguji software ) merupakan kelompok profesi yang dapat dikatakan masih baru di dalam dunia software; walaupun sebenarnya dalam dunia nyata pengembangan software, pekerjaannya ada dan sudah dilakukan, tetapi masih belum dipisahkan secara khusus. Umumnya melekat kepada pemrogram untuk melakukan pengujian software.

Software tester dalam pengertian umum adalah orang yang melakukan proses pengujian software. Software yang diuji, bisa software yang sedang dikembangkan, bisa juga software yang sudah jadi, yang dijual di toko (pasar).

Profesi ini dulu masih dipandang sebelah mata, sering diabaikan, bahkan tidak pernah dilakukan oleh pengembang software.

Tetapi dengan semakin meningkatnya kompleksitas sistem yang dikembangkan, dan tuntutan akan mutu dan layanan, maka profesi ini menjadi sangat penting dan harus ada. Software tester dapat dipandang sebagai pengguna software; yang akan melakukan pengujian software secara menyeluruh, dari proses instalasi sampai dengan penggunaannya, dengan semua menu/fasilitas software dicoba semua.

Sangatlah ironi, saat ini, jika suatu perusahaan pengembang software belum memiliki orang atau tim khusus untuk menjadi software tester. Perusahaan pengembang software tidak boleh mengandalkan pemrogramnya untuk melakukan pengujian software yang dikembangkan oleh pemrogram itu sendiri. Mengapa? Karena hasil pengujian oleh pemrogram itu sendiri, bisa jadi tidak akan objektif. Sudut pandang pengujian pemrogram dalam menguji software akan berbeda dengan sudut pandang penguji sebagai pengguna.

Software tester, jika memungkinkan, per orangan atau tim yang berposisi sebagai pihak ketiga. Mengapa? Pihak ketiga diharapkan lebih netral, tidak memiliki konflik of interest, sehingga bisa lebih objektif.

Siapa saja yang bisa software tester?
Tidak ada ketentuan baku, tentang siapa yang bisa menjadi software tester, karena berhubungan dengan tahap pengembangan dari software yang sedang dikembangkan. Jika software masih dalam tahap pengembangan, maka tester haruslah orang yang memahami proses bisnis yang akan dibantu proses kerjanya dan orang yang memiliki penguasaan terhadap teknologinya. Jika sudah selesai dan akan dioperasionalkan, maka tester bisa penggunanya.

Pelatihan formal tentang proses pengujian sebaiknya harus dibekalkan kepada setiap software tester. Mengapa? Tentu saja agar tester memiliki pengetahuan dasar tentang bagaimana melakukan proses pengujian software yang benar.

Proses pengujian haruslah sistematis, dan jika mungkin dibantu dengan menggunakan software, yang bisa membantu dalam proses pengujian. Proses pengujian tidak harus dilakukan secara manual, tetapi juga harus bisa dilakukan dengan diotomatisasi.
Proses pengujian software dapat dibedakan menjadi:
1. pengujian manual (manual testing)
2. pengujian diotomatisasi (automated testing)
3. gabungan manual dan otomatis

Pengujian manual merupakan pengujian yang umum dilakukan oleh banyak tester. Proses pengujian manual membutuhkan suatu prosedur baku, ketekunan, dan ketelitian dari orang yang berperan sebagai penguji (tester). Mengapa? Karena proses pengujian merupakan proses yang berulang, dan bisa jadi sangat menjemukan.

Pengujian yang diotomatisasi merupakan proses pengujian yang menggunakan alat bantu, dalam hal ini software untuk pengujian (testing software). Proses pengujian dirancang agar dapat dilakukan oleh software. Kita bisa membuat program dengan software untuk pengujian, agar proses pengujian dapat dilakukan secara otomatis. Software pengujian sangat diperlukan untuk membantu proses pengujian yang sifatnya berulang dan banyak sekali.

Gabungan antara manual dan otomatis, merupakan proses pengujian yang ideal, karena tetap saja bahwa proses pengujian membutuhkan keputusan manusia sebagai penguji. Banyak pertimbangan dalam proses pengujian tidak bisa dimasukkan ke dalam software untuk pengujian yang diotomatisasi.

Perekaman Proses Pengujian Software
Suatu proses pengujian software (software testing process) memerlukan software yang bisa membantu proses pengujian.

Proses pengujian yang umum dilakukan adalah dengan menjalankan software aplikasi yang telah selesai dibuat oleh pemrogram. Kemudian aplikasi dicoba dari awal sampai dengan akhir dengan menggunakan langkah (skenario) dan data yang telah disiapkan.

Secara mudah dan sederhana, suatu aplikasi akan dianggap telah lulus pengujian, apabila setelah dicoba, aplikasi dapat merekam dan memproses data yang dimasukkan, kemudian menghasilakan keluaran sesuai dengan yang diharapkan, tanpa ada kesalahan sedikitpun.

Pengujian software tidak dilakukan oleh pemrogram saja, tetapi juga harus melibatkan pihak ketiga, pihak yang independent, yang akan memberikan justifikasi bahwa software aplikasi yang dibuat telah lulus dari pengujian.

Permasalahan yang sering timbul apabila hasil dari proses pengujian yang masih bermasalah, dalam artian bahwa software aplikasi belum lulus uji, adalah bagaimana menunjukkan di mana letak kesalahan yang menyebabkan software belum lulus uji.

Pada proses pengujian yang masih konvensional, manual, tanpa ada bantuan software pendukung untuk pengujian, penguji melaporkan hasil pengujiannya dengan menggunakan laporan secara lisan. Akibatnya adalah bahwa seringkali laporan kesalahan tersebut tidak dapat tersampaikan dengan baik, atau bahkan sering kali terlewatkan atau terlupakan sebagai bagian pekerjaan programmer yang harus memperbaikinya.

Pada tingkatan berikutnya, tester telah melakukan pengujian dengan memberikan laporan secara tertulis deskriptif. Pemrogram dapat menggunakan laporan ini untuk bekerja memperbaiki program, sehingga pemrogram bisa memiliki daftar modul yang harus diperbaiki. Pemrogram bisa memeriksa mana saja yang sudah dan mana yang belum diperbaiki. Masalh masih timbul, karena secara deskriptif, kesalahan yang ada tidak dapat dibayangkan di mana letaknya.

Pada tingkatan berikutnya, penguji harus menggunakan software yang dapat merekam gambar dari kesalahan yang terjadi. Penguji dapat melakukan capture (menangkap dan menyimpan) screen yang menunjukkan program yang diuji pada saat ‘error’. Dengan adanya gambar yang menunjukkan kesalahan, pemrogram dapat langsung mengetahui di mana letak kesalahannya. Proses capture screen dapat menggunakan fasilitas dari sistem operasi, jika pengguna menggunakan Windows, maka pengguna dapat dengan mudah melakukan penekanan tombol keyboard PrtSc (PrintScreen).

Akan tetapi seringkali terjadi, timbulnya kesalahan sewaktu-waktu. Pada kasus seperti ini, maka penguji harus dapat melakukan pengujian dengan melakukan proses pengujian secara lengkap terekam. Setiap langkah dari skenario diikuti dan direkam. Penguji dapat melaporkan kesalahan yang terjadi secara lebih lengkap. Pemrogram dapat mempelajari kejadian kesalahan dengan lebih teliti.
Jika kita lihat permasalahan di atas, maka kita membutuhkan suatu software yang bisa merekam proses pengujian dari awal sampai dengan akhir. Software untuk pengujian harus dapat membantu dari proses pembuatan skenario, pelaksanaan skenario, dan proses pelaporan hasil pengujian.
Untuk membantu mengelola skenario sampai dengan merekam proses dan hasil pengujian, maka kita dapat menggunakan software:

1. Testlink (http://testlink.org/)Software berbasis web yang digunakan untuk membuat membuat suatu daftar kasus uji yang akan didaftarkan pada setiap skenario dari komponen/modul dari suatu produk. Daftar kasus uji untuk setiap skenario untuk pengujian. Dari data inilah tester akan melakukan pengujian, dan menuliskan setiap pengujian yang dilakukan ke dalam daftar.

2. Bugzilla (http://www.bugzilla.org/) (Mantis - http://www.mantisbt.org/)Software ini harus dihubungkan dengan Testlink, digunakan untuk melakukan perekaman data modul yang belum lulus uji, yang harus diperiksa dan diperbaiki oleh pemrogram. Pemrogram harus bekerja memperbaiki dan melaporkan hasil uji ini. Tester akan melihat data hasil uji dan perbaikan dari programmer, jika masih belum benar, tester akan menuliskan bahwa program masih tetap harus diperbaiki.

3. screen capture atau yang lebih baik adalah video capture - avi recorder (http://www.bobyte.com/AviScreen/index.asp)Software ini sangat dibutuhkan untuk menyimpan bukti proses pengujian dilakukan. Apabila terjadi kesalahan, maka bagaimana terjadinya kesalahan untuk rekonstruksi akan dapat dilihat oleh pemrogram. Penggunaan video capture akan sangat bermanfaat, karena pemrogram dapat dengan mudah menjalankan video ini untuk melakukan rekonstruksi bagaimana kesalahan bisa terjadi, di mana dan kapan terjadi errornya.

Konsekuensi dari proses pengujian ini adalah kita harus memiliki space harddisk yang cukup memadai, untuk dapat merekam semua proses yang dilakukan selama proses pengujian. Jika pengujian telah selesai, maka rekaman hasil pengujian dapat dihapus, tetapi sebaiknya, sebelumnya dihapus terlebih dahulu

UAS RPLL - INTRO

2007-06-19T19:29:00.000-07:00

FASE PENGEMBANGAN DAN DESAIN PERANGKAT LUNAK

Fase pengembangan terdiri dari 3 langkah :
1. Design
2. Code Generation (manual or automatic)
3. Testing
Setiap langkah melakukan transformasi informasi dalam suatu cara yang akhirnya menghasilkan software komputer yang valid.

Gambar 1. Development Phase

Software requirements
Dijelaskan dengan “Information Domain”, “Functional and performance requirements”, “Feed the design step”

Menggunakan metodelogi :
1. Data Design : difokuskan pada definisi dari struktur data
2.Architectural Design : mendefinisikan hubungan antara elemen struktur utama dari program
3. Procedural Design : mengubah struktur elemen ke dalam prosedur software

Gambar 2. Pentingnya Desain

PROSES DESAIN
Software design adalah suatu proses yang melawati serangkaian kebutuhan yang membentuk sebuah perangkat lunak

Software design dibagi dalam 2 tahap :
1. Preliminary Design
Pada tahap ini difokuskan dengan transformasi dari keperluan / kebutuhan ke dalam data dan arsitektur software
2. Detail Design
Difokuskan pada penghalusan representasi arsitektur yang berisi struktur data detail dan algoritma untuk software

Gambar 3. Hubungan antara aspek teknik dan management pada desain

KUALITAS DESAIN DAN SOFTWARE
Beberapa tuntunan dalam melakukan agar dihasilkan desain dengan kriteria yang baik, yaitu suatu desain haruslah :
1. Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen software
2. Berkenaan dengan modul. Software secara logika terbagi dalam elemenelemen yang membentuk fungsi dan sub fungsi
3. Berisi representasi yang berbeda dan terpisah dari data dan prosedur
4. Membentuk modul ( contoh subroutine dan procedure ) yang memperlihatkan karakteristik fungsi yang tidak saling bergantung
5. Diturunkan dengan menggunakan metode perulangan yang didukung oleh informasi yang ada selama analisa kebutuhan software

EVOLUSI DESAIN SOFTWARE
Evolusi dari desain software merupakan proses yang berkelanjutan terus selama 3 dekade. Beberapa metodologi telah tumbuh, dan secara umum memiliki karakteristik sebagai berikut :
1. Sebuah mekanisme untuk menterjemahkan representasi domain informasi ke dalam representasi desain
2. Notasi untuk merepresentasikan fungsi komponen-komponen dan interfaces-nya
3. Heuristics bagi penyaringan dan partisi
4. Petunjuk untuk penaksiran kualitas

DASAR-DASAR DESAIN
Membantu software engineer untuk menjawab pertanyaan-pertanyaan berikut :
* Apakah kriteria yang dapat dipakai untuk mempartisi software menjadi sejumlah komponen ?
* Bagaimana fungsi atau struktur data dipisahkan dari suatu representasi konseptual software ?
* Apakah ada kriteria yang seragam yang menetapkan kualitas tehnik dari suatu software desain ?

ARSITEKTUR SOFTWARE
Arsitektur perangkat lunak menyinggung 2 karakteristik penting dari sebuah program komputer :
1. Hirarki struktur dari komponen-komponen prosedural ( modul )
2. Struktur data

Gambar 4. Evolution of structure

Gambar 5. Different strucuture

PROGRAM STRUCTURE
* Program structure menampilkan / menyajikan organisasi ( seringkali organisasi hirarki ) dari komponen-komponen program ( modul-modul ) dan mengandung arti hirarki dari kontrol program.
* Notasi yang digunakan adalah diagram tree. Biasanya dinamakan structure chart

Gambar 6. Terminologi structure

DATA STRUCTURE
Menggambarkan relasi logikal antara sejumlah elemen dari . Contoh :
type G = array [1..100] of integer;
...
...
Procedure S ( var T : G ; n : integer ; sum : integer );
Var
I : integer;
begin
sum := 0;
for I:=1 to n do
sum := sum + t[i];
end;

SOFTWARE PROCEDURE
Difokuskan pada detail pemrosesan dari setiap modul secara individu. Prosedur harus mengandung spesifikasi yang benar / tepat dari pemrosesan, termasuk : sequence of events, decision points, repetitive operations, dan struktur data.

Gambar 7. Procedure dengan sebuah modul

MODULARITAS
Software dibagi kedalam nama-nama yang terpisah dan elemen-elemen yang dapat dipanggil, yang disebut dengan modul, yang termasuk kedalam memenuhi syarat-syarat permasalahan

Misalkan :
C(x) = fungsi kompleksitas dari suatu masalah
E(x) = fungsi usaha/waktu yang diperlukan untuk memecahkan suatu masalah
P1 ,P2 = masalah 1, masalah 2
Jika : C(P1) > C(P2) maka : E(P1) > E(P2)

Berdasarkan penelitian :
C ( P1 + P2 ) > C ( P1 ) + C ( P2 )
E ( P1 + P2 ) > E ( P1 ) + E ( P2 )

Konklusi :
Kompleksitas suatu masalah gabungan P1 dan P2 akan berkurang jika masalah tersebut dipisahkan
Akan lebih mudah menyelesaikan suatu masalah jika dipecah / dipartisi

ABSTRAKSI
Jika kita menggunakan suatu solusi modular untuk beberapa masalah, maka beberapa level / tingkat abstrasi dapat ditampilakn / diperlihatkan.
Pada level tertinggi, suatu solusi berada pada term yang umum dengan menggunakan bahasa natural
Level yang lebih rendah lebih berorientasi pada prosedur-prosedur

Contoh :
Abstraksi 1
The software will incorporate a computer graphics interface
that will enable visual communication with the drafts person
and a digitizer interface that replace the drafting board and
square. All line and curve drawing, all geometric computation,
and all sectioning and auxiliary views will be performed by
the CAD Comp.

Abstraksi 2
CAD Software tasks :
user interaction task ;
2-D drawing creation task ;
graphics display task ;
drawing file management task ;
end.

Abstraksi 3
procedure : 2-D drawing creation ;
repeat until (drawing creation task terminates)
do while (digitizer interaction occurs)
digitizer interface task ;
determine drawing request case ;
line : line drawing task ;
circle : circle drawing task ;
...
...
end ;
do while (keyboard interaction occurs)
keyboard interaction task ;
process analysis / computation case ;
view : auxiliary view task ;
section : cross sectioning task ;
...
...
end
...
...
end repetition ;
end procedure.

PENYEMBUNYIAN INFORMASI
Contoh :

Gambar 8. Penyembunyian Informasi

* Black Box : input, output, & proses dike-tahui tetapi proses detail tidak diketahui.
* Bagi Modul B, Modul C adalah Black Box

Keuntungan :
* Jika diperlukan modifikasi selama testing dan maintenance 􀃖 data & prosedur disembunyikan dari bagian lain, dari program / software secara keseluruhan.
* Kesalahan-kesalahan yang terjadi selama modifikasi tidak merambat pada bagian lain.

DESAIN MODULAR EFEKTIF
Modular design :: mereduksi komplesitas masalah, menyediakan fasilitas untuk melakukan perubahan ( dalam hal pemeliharaan ), dan memudahkan implementasi dengan pengembangan paralel dari bagian-bagian yang berbeda dalam suatu sistem

MODULE TYPES
Abstraksi dan penyembunyian informasi dipakai untuk mendefinisikan modul-modul di dalam lingkungan software architecture. Di dalam structure software, suatu modul mungkin dikategorikan sebagai berikut :
1. Sequential module :: dieksekusi tanpa interupsi yang dilakukan software aplikasi
2. Incremental module :: dapat diinterupsi oleh program aplikasi dan kemudian kembali ke titik semula setelah interupsi selesai
3. Parallel module :: dieksekusi secara simultan dengan modul lain dalam lingkungan Concurrent multiprocessor

INDEPENDENSI FUNGSIONAL
Konsep functional independence berkembang dari modularitas dan konsep bstraksi serta information hiding. Independence diukur dengan menggunakan 2 kriteria kualitatif, yaitu
1. Cohesion
2. Coupling

Cohesion ( keterpautan )
* Perluasan / kelanjutan dari information hiding
* Suatu modul kohesif membentuk sebuah tugas tunggal di dalam suatu software prosedur dan memerlukan sedikit interaksi dengan prosedur yang dibuat dalam bagian lain dari suatu program

Gambar 9. Cohesion

Coincidental cohesion :
sebuah modul yang membentuk sejumlah tugas yang berhubungan satu sama lain dengan longgar

Logically cohesion :
sebuah modul yang membentuk tugas-tugas yang dihubungkan secara logical

Temporal cohesion :
jika sebuah modul berisi sejumlah tugas yang dihubungkan dengan segala yang harus dieksekusi di dalam waktu yang bersamaan.

Procedural cohesion :
jika pemrosesan elemen-elemen dari suatu modul dihubungkan dan harus dieksekusi dalam urutan spesifik

Communication cohesion :
jika pemrosesan elemen-elemen dikonsentrasikan pada satu area dari suatu struktur data

Coupling ( bergandengan )
Merupakan suatu pengukuran dari keterkaitan / keterhubungan antara sejumlah modul dalam struktur program. Coupling tergantung pada kompleksitas interface antar modul

Gambar 10. Coupling

Gambar 11. Low Coupling dan High Coupling

MODEL DESAIN
Prinsip dan konsep desain yang dibicarakan pada bab ini membangun sebuah fondasi untuk pembuatan model desain yang mencakup representasi data, arsitektur, interface dan prosedur.

DOKUMENTASI DESAIN
Outline spesifikasi desain :
I. Ruang Lingkup
A. Sasaran Sistem
B. Persyaratan utama software
C. Batasan-batasan dan pembatasan desain
II. Desain Data
A. Obyek data dan struktur data resultan
B. Struktur file dan database
1. Struktur file eksternal
a. struktur logis
b. deskripsi record logis
c. metode akses
2. data global
3. file dan referensi lintas data
III. Desain Arsitektural
A. Kajian data dan aliran control
B. Struktur program yang diperoleh
IV. Desain Interface
A. Spesifikasi interface manusia-mesin
B. Aturan desain interface manusia-mesin
C. Desain interface eksternal
1. Interface untuk data eksternal
2. Interface untuk sistem atau peralatan eksternal
V. Desain Prosedural
Untuk masing-masing modul :
A. Naratif pemrosesan
B. Deskripsi Interface
C. Deskripsi bahasa (atau lainnya) desain
D. Modul-modul yang digunakan
E. Struktur data internal
F. Keterangan/larangan/pembatasan
VI. Persyaratan Lintas-Referensi
VII. Ketetentuan pengujian
1. Panduan pengujian
2. Strategi integrasi
3. Pertimbangan Khusus
VIII. Catatan Khusus
IX. Lampiran

PENGUJIAN
Pengujian program harus dilakukan pertama kali oleh pemrogram itu sendiri, setelah itu baru diserahkan dan dilakukan pengujian oleh penguji (tester) program.

Bahan untuk pengujian harus disiapkan oleh perancang aplikasi atau pengguna. Bahan untuk pengujian suatu modul program akan terdiri atas banyak data dan prosedur. Setiap data dan prosedur disebut sebagai kasus uji (test case).Satu modul akan memiliki banyak kasus uji. Mengapa? Karena di dalam suatu program atau modul, pada umumnya, di dalamnya akan terdapat lebih dari satu prosedur atau fungsi. Setiap prosedur dan fungsi akan memiliki kegunaan sendiri, maka sudah seharusnya setiap fungsi atau prosedur harus diuji. Pengujian pada level prosedur atau fungsi disebut sebagai pengujian pada level unit.

ICT untuk Pendidikan Beragama

2007-06-04T20:59:00.000-07:00

Pada dasarnya Indonesia sangat kompleks, baik dari segi agama, suku, dan lain sebagainya. Dari banyaknya kompleksitas yang ada di indoensia, maka akan memiliki resiko terjadinya konflik dalam masyarakat sangat memungkinkan. Ini terlihat pada beberapa saat yang lalu terjadi konflik antara 2 kubu agama yang terjadi di POSO. Ini adalah sekelumit cerita dari konflik yang ada pada indonesia. Sebenarnya apakah yang mendasari terjadinya konflik? Mungkin salah satu faktornya adalah komunikasi. Jangankan kehidupan beragama, terkadang antara saudara jika tidak terjadi komunikasi yang baik maka akan timbul konflik. Bagaimana dengan orang indonesia yang beraneka ragam serta berjumlah lebih dari 200 juta jiwa? Tentulah ini akan menjadi persoalan yang penting untuk ditindak lanjuti.

Dengan kemajuan teknologi sekarang dan akan datang, maka faktor miskomunikasi dapat direduksi. Di internet telah banyak situs-situs yang mengenalkan ataupun menjelaskan kegiatan yang dilakukan dalam agama tersebut. Sehingga orang yang beragama lainnya dapat mengetahui apa yang dilakukan orang lain. Dengan adanya komunikasi antar agama dapat mereduksi konflik yang ada indonesia. Indonesia memang majemuk, dan itu patut disyukuri.

ICT ( Information Communication Technology) dapat menjadi salah satu pemecahan kebuntuan komunikasi. Faktor jarak, waktu, dan lain sebagainya yang menyebabkan komunikasi tidak berjalan secara perlahan dapat dikikis. Seperti halnya ICT untuk pendidikan Formal, ICT dapat pula dimanfaatkan untuk pendidikan beragama. Pemanfaatannya dapat berupa makin memperdalam agama yang dianut seseorang atau terjadi sharing antar umat beragama.

Komponen utama untuk mengimplementasikan ICT dalam Pendidikan Agama :

Media komunikasi ( televisi, radio, internet )
Mesin Informasi ( Komputer, Handphone )
Teknologi dan Peralatan Komunikasi ( Fiber Optik, Satelit )
Pakar pada tiap bidang masing-masing agama ( Islam : Tafsir, Ekonomi Syariah, dll , Kristen, Katolik, Hindu, Budha, Aliran Kepercayaan )

Dengan adanya pakar, maka akan meminimalkan kesalahan pehaman sesorang kepada orang lain. Terkadang seseorang kurang mengetahui atau mendalami sebuah agama yang dianutnya. Sehingga ketika orang lain ingin mengetahui, maka akan terjadi konflik yang sangat fatal jika salah menjelaskan. Sehingga diharapan bahwa kehidupan berbangsa dan bernegara dapat berlandaskan Agama yang dianut.

Langkah yang perlu dibangun adalah :

Membangun jaringan di tingkat Institusi Pendidikan :

Negeri : SDN, SMPN, SMUN, Perguruan Tinggi
Swasta : TK, SD, SMP, SMU, Perguruan Tinggi

Membangun jaringan pendidikan informal di tingkat masyarakat

Tempat Peribadatan
Komunitas Beragama
Seminar, Training

Pada poin 1 dan 2 terintegrasi dalam setiap wilayah ( kota ) dan masing-masing kota memiliki Pusat Seagama, Pusat Komunikasi Antar Agama.
Dari masing-masing pusat diantar kota terintegrasi Pusat Tingkat Propinsi yang terdiri dari Pusat Seagama Tingkat Propinsi, dan Pusat Komunikasi Antar Negara Tingkat Propinsi.
Terdapat sebuah Pusat Keagamaan Seluruh Indonesia.

Setelah jaringan telah terbentuk, maka yang sangat penting di bangun andalah Moralitas dari bangsa itu sendiri. Untuk membangun Moralitas, maka manusianyalah yang perlu dibangun mentalitasnya. Untuk membangun mentalisatas tersebut perlu dibentuk baik di dalam Institusi Pendidikan ataupun Pendidikan informal.

Pembangunan mentalitas :

Pada Institusi Pendidikan

Kurikulum
E-Learning
Praktik
Klinik ICT

Pada Pendidikan informal

Seminar
Pelatihan/Training
Acara Keagamaan yang rutin, baik tiap hari, tiap minggu, tiap bulan, tiap tahun.
Ceramah Pemuka agama secara rutin

To be continue .........