NPM : 11115193
Nama : Ayunda Maudiatama
Kelas : 4KA08
Matkul : Analisis Kerja Sistem
Pretest Manajemen Kontrol Programming
Nama : Ayunda Maudiatama
Kelas : 4KA08
Matkul : Analisis Kerja Sistem
Pretest Manajemen Kontrol Programming
TAHAPAN
PENGEMBANGAN PROGRAM
Terdapat
5 tahapan pengembangan program antara lain : Perencanaan (Planning), Perancangan
(Design), Pengkodean (Coding) , Pengetesan (Testing), dan Pengoperasian dan
Pemeliharaan (Operation and Maintenance).
1. Perencanaan
(Planning)
·
Tugas utama : untuk memperkirakan
kebutuhan besarnya sumber daya (khususnya jam kerja) yang dibutuhkan dalam
pengembangan, pengadaan, dan penerapan software
·
Jika, sebagai contoh, s/w di buat di rumah
(in house), manajemen harus berusaha untuk memperkirakan berapa jumlah baris
kode (program) yang di ketik atau banyaknya fungsi yang di buat.
·
Jika suatu software akan dikembangkan dan
diimplementasikan secara in-house, manajemen harus memanfaatkan lima teknik
perencanaan biaya yang di buat oleh Boehm (1984) sbb :
a. Algorithmic
Models (model algoritma) : model ini akan memperkirakan jumlah sumber daya yang
dibutuhkan berdasar pada faktor biaya, sebagai contoh memperkirakan jumlah
instruksi yang harus di ketik (di tulis), bahasa pemrograman yang digunakan,
dan perubahan pada permintaan kebutuhan. Dengan menggunakan model COCOMO
(Boehm’s (1981)).
b. Expert
Judgment (penilaian seorang ahli), seorang ahli dapat memperkirakan kebutuhan
sumber daya yang diperlukan dalam proyek / pembuatan program. Menurut
penelitian Vicinanza et el’s (1991), seorang ahli dapat menjadi pembuat
perkiraan yang lebih baik untuk menentukan sumber daya jika dibanding dengan
model algoritma.
c. Analogy
(analogi) : jika proyek software yang sama pernah dibuat, penentuan sumber daya
yang dibutuhkan dapat di dasarkan pada pengalaman sebelumnya.
d. Top-Down
Estimation (Perkiraan atas-bawah) : proyek di pecah kedalam beberapa tugas
(pekerjaan), dan penentuan sumber daya yang dibutuhkan oleh setiap tugas
tersebut baru dibuat.
e. Bottom-Up
Estimation (Perkiraan bawah-atas) : jika tugas-tugas sudah di buat terlebih
dahulu, kebutuhan sumber daya untuk masing-masing dapat diperkirakan dan di
satukan / dikumpulkan untuk keperluan seluruh kebutuhan proyek.
·
Selain memperkirakan kebutuhan sumber
daya, manajemen juga harus memutuskan tujuan dari keputusan penting yang dibuat
selama fase perencanaan seperti :
a. Pendekatan
desain (design approach) : jika program akan dikembangkan dirumah, manajemen
harus memilih pendekatan desain yang akan digunakan seperti prototyping atau
tipe top-down atau bottom-up.
b. Pendekatan
implementasi (implementation approach) : software dapat dikembangkan dirumah,
pengembang dapat membangun atau mengemas software untuk dijual. Jika software
akan dibuat koding, harus dibuat keputusan tentang bahasa pemrograman yang akan
dipakai.
c. Pendekatan
testing dan integrasi (Integration and testing approach) : pada saat pengetesan
akan dibutuhkan sumber daya yang khusus, seperti simulator atau hardware
tertentu untuk memonitor jalannya program.
d. Pengorganisasian
tim proyek (project team organization) : saat tim proyek harus dibentuk untuk
pengembangan atau pengadaan software, maka anggota dan struktur tim harus
ditentukan.
Pengendalian
(Control)
Pada tahap kontrol ini,
ada dua tujuan utama yaitu :
a. Untuk
memonitor kemajuan dan beberapa tahap pada siklus hidup s/w agar tidak
bertentangan dengan rencana awal.
b. Mengontrol
tugas pengembangan, pengadaan dan implementasi s/w, agar s/w dapat di produksi
secara autentik, akurat dan lengkap.
Untuk memonitor agar
kontrol tidak bertentangan dengan rencana awal, beberapa teknik dapat digunakan
seperti :
a. Work
Breakdown Structures (WBS), dengan teknik ini kita dapat mengidentifikasi
tugastugas yang spesifik untuk pengembangan, pengadaan, dan implementasi s/w
yang dibutuhkan (lihat gambar 1). (Mc.Leod and Smith 1996).
Gambar 1 Pemecahan
struktur untuk order-entry system
b. Gantt
Chart, dapat digunakan untuk membantu mengatur tugas (schedule) (lihat gambar
2). Teknik ini akan menunjukan kapan tugas harus dimulai dan diselesaikan,
tugas apa yang harus dibuat bersama-sama, dan tugas apa yang harus dihasilkan
secara serial.
Gambar 2 Gantt
Chart untuk order-entry system
c. Program
Evaluation and review technique (PERT), menunjukan tugas-tugas yang harus
diselesaikan, bagaimana hubungannya, kebutuhan sumber daya apa untuk setiap
tugastugasnya. (lihat gambar 3).
Gambar 3 PERT
Chart untuk order-entry system
·
Seorang auditor harus mempunyai dua
perhatian khusus pada kendali, pada tahap kontrol ini yaitu :
a. Auditor
harus dapat mengevaluasi apakah fungsi dari aktivitas kontrol dapat diterapkan
juga pada software yang berbeda.
b. Seorang
auditor harus dapat mengumpulkan bukti apakah prosedur dari suatu kontrol sudah
dijalankan dengan benar dan dapat dipercaya.
2. Perancangan
(Design)
·
Tugas programmer :
Dalam tahap desain,
seorang programmer bertugas untuk menspesifikasikan struktur dan operasi dari
program untuk menemukan artikulasi yang dibutuhkan selama tahap proses
informasi sistem desain dari pengembangan sistem.
·
Tugas utama auditor :
a. Selama
tahap ini, perhatian utama seorang auditor adalah untuk menentukan apakah
programmer menggunakan suatu tipe khusus dari pendekatan sistematik untuk
desain.
b. Auditor
harus mengubah keinginannya berdasarkan beberapa faktor seperti ukuran dan
bahan dari suatu program.
c. Seorang
auditor juga dapat memperoleh bukti dari proses desain dengan melakukan
interview, observasi, dan review dari dokumentasi.
d. Mereka
dapat berkomunikasi dengan programmer, apakah mereka dapat memahami tentang
kebutuhan dengan menggunakan pendekatan yang sistematik untuk desain, jika ya,
bagaimana menggunakannya.
e. Auditor
juga dapat mengamati apakah programmer menggunakan pendekatan sistematik untuk
mendesain program.
f.
Mereka juga dapat meninjau dokumentasi
program, apakah memiliki struktur chart sebagai bukti programmer menggunakan
pendekatan yang sistematik untuk mendesain.
3. Pengkodean
(Coding)
·
Tahap koding (pengetikan / penulisan
program) dilakukan pada saat s/w akan dibuat atau dimodifikasi.
·
Tugas programmer :
Selama tahap ini,
programmer akan menulis dan mendokumentasikan source code (program sumber)
dalam bahasa pemrograman untuk mengimplementasikan desain program.
·
Tiga strategi utama dari implementasi
modul dan integrasi :
a. Top-Down,
strategi ini digunakan jika, modul level atas (high-level modules) dibuat
(coding), di test, dan diintegrasikan sebelum modul level bawah (low-level
modules). Keuntungannya adalah kesalahan pada modul level atas dapat
teridentifikasi lebih dini, kerugiannya adalah pada saat uji coba program akan
menemui kesulitan ketika modul level bawah menemukan kesalahan fungsi
input-output yang sangat sulit.
b. Bottom
up, strategi ini digunakan jika, modul level bawah di buat (coding), di test,
dan diintegrasikan sebelum modul level atas di buat. Keuntungannya adalah modul
level rendah yang merupakan operasi yang paling sulit di implementasikan dan
diuji terlebih dahulu. Kerugiannya adalah pendekatan ini sangat sulit untuk di
teliti seluruh operasinya, sebelum programnya selesai dibuat.
c. Threads
(rangkaian / untaian), strategi ini digunakan jika, keputusan dibuat terlebih
dahulu untuk fungsi program yang akan dibuat, kemudian modul yang akan
mendukungnya baru dibuat dan kemudian diimplementasikan untuk menghasilkan
fungsi yang penting. Keuntungannya adalah fungsi yang paling penting di
implementasikan terlebih dahulu. Kerugiannya adalah integrasi dari modul yang
berikutnya mungkin akan lebih sulit, jika dibandingkan dengan pendekatan
top-down atau bottom-up.
·
Tugas auditor :
a. Auditor
perlu mencari bukti yang benar dengan cara uji coba oleh manajemen program
dalam memilih strategi implementasi modul dan integrasi. Khususnya pada program
yang besar, penggunaan strategi yang salah (jelek) dapat mengakibatkan program
yang dihasilkan menjadi kurang berkualitas.
b. Auditor
dapat melakukan wawancara untuk menguji apakah manajemen menggunakan pendekatan
sistematik untuk memilih strategi implementasi modul dan integrasi.
c. Mereka
juga dapat menguji dokumentasi program untuk memperoleh bukti tipe strategi
yang telah di adopsi (di pilih).
Strategi
Coding
Menurut konvensi
(kesepakatan) program terstruktur, terdapat tiga dasar struktur utama dalam struktur
kontrol yaitu :
a. Urutan
sederhana (simple sequence - SEQUENCE)
b. Pemilihan
dengan seleksi (selection based on a test – IF-THEN-ELSE)
c. Pengulangan
kondisi (conditional repetition-DO WHILE)
Jika
konvensi pemrograman terstruktur di penuhi, dapat dipastikan bahwa para
programmer akan membuat source-code yang tingkat kesalahannya kecil, mudah
untuk dimengerti dan mudah untuk dirawat.
Auditor
dapat mencari bukti untuk memastikan apakah manajemen programming di jamin di
buat oleh programmer mengikuti struktur programming yang telah di sepakati.
Mereka dapat melakukan wawancara dengan manager atau programmer tentang tugas
dan cara yang dilakukannya dalam membuat program.
Gambar 5 (a) Simple Sequence (b) Selection (c)
Repitition
Auditor
juga dapat mengecek apakah programmer dalam membuat programnya menyediakan
fasilitas otomatis sebagai alat bantu untuk mereka. Beberapa tipe penggunaan
fasilitas koding otomatis anatara lain :
a. Shorthand
preprocessor, memungkinkan programmer untuk menulis kode secara singkat,
jugadapat menerjemahkan kode singkat ini dalam sintak yang lebih lengkap,
contoh COBOL.
b. Decision-table
preprocessor, memindahkan bentuk teks program ke dalam bentuk
sourcecodemenggunakan bahasa pengolahan compiler.
c. Copy
facility, memungkinkan penggunaan kode secara berulang
d. Editor,
yang memungkinkan kode di ciptakan, di format, dan dimodifikasi secara mudah.
e. User-interface
management system, memungkinkan desain dari implementasi yang cepat,seperti
windows, icons, menus, dan dialog boxes.
f.
CASE tools, berisi bermacam-macam
fasilitas yang dapat membantu proses koding.
Strategi Dokumentasi
Pedoman
untuk menghasilkan dokumentasi yang berkualiatas adalah :
a. Sediakan
petunjuk yang menunjukan proes pembuatan program ke dalam beberapa tahap
dankomponen secara keseluruhan dan hubungan antara komponen-komponen tersebut.
b. Gunakan
baris komentar dalam program secara bebas untuk menerangkan jalannya
(logika)program.
c. Beri
nama untuk variabel, konstanta tipe, paragraf, modul, dan seksi yang berarti
kepada parapembaca source-code program.
d. Buat
lay-out dari source-program sehingga mudah untuk dibaca.
e. Kelompokan
tipe kode yang saling berhubungan.
4. Pengetesan
(Testing)
a. Static
analysis test (kel.1)
-
Desk-checking
1) Dilakukan
melalui pemeriksaan detail dari source code yang mengakibatkan pengeksekusian
logika dalam pikiran pemeriksa.
2) Seorang
programer yang berpengalaman dapat menelusuri logika dan perosesan data dengan
me-review source code-nya.
3) Informal
4) Tidak efektif dibandingkan dengan walkthrough atau inspeksi
-
Structured walk-throughs
1)
Programmer walk-throughs/executes
(mengeksekusi) kode ketika peserta yang diundang mengajukan pertanyaan dan membuat
komentar.
2)
Relatif informal
-
Design and code inspections
Biasanya daftar periksa
kesalahan umum digunakan untuk membandingkan kode melawan.
b. Dynamic
analysis test
-
Black-box test
Pengujian black-box berfokus pada persyaratan
fungsional perangkat lunak. Dengan demikian,
pengujian black-box memungkinkan perekayasa perangkat lunak mendapatkan serangkaian
kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional untuk
suatu program
Pengujian black-box berusaha menemukan kesalahan dalam
kategori sebagai berikut:
1)
Fungsi-fungsi yang tidak benar atau hilang
2)
Kesalahan dalam struktur data atau akses database
eksternal
3)
Kesalahan interface
4)
Kesalahan kinerja
5)
Inisialisasi dan kesalahan terminasi
-
White-box test
Pengujian white-box adalah metode desain test caseyang
menggunakan struktur kontrol desain prosedural untuk memperoleh test case.
Klasifikasi White box testing mencakup
beberapa pengujian, yaitu :
1)
Analisis statis dan dinamis (static and dynamic
analysis)
Analisis statis dilibatkan melalui kode untuk
mengetahui segala kemungkinan cacat dalam kode, sedangkan analisis dinamis akan
melibatkan pelaksanaan kode dan penganalisisan hasilnya.
2)
Cakupan Pernyataan (statement coverage)
Dalam hal ini, jenis pengujian kode dijalankan dengan
setiap pernyataaan dari aplikasi yang
dijalankan minimal sekali
3)
Pada pengujian mutasi (mutation testing)
Pada pengujian ini, aplikasi diuji untuk kode yang
telah dimodifikasi setelah pemasangan
bug/cacat tertentu.
4)
Cakupan cabang (branch coverage)
Pengujian cakupan cabang membantu pemvalidasi semua
cabang di dalam kode dan memastikan bahwa tidak ada yang mengarah ke
percabangan perilaku abnormal dari aplikasi.
5)
Pengujian unit (unit testing)
Pengembang melaksanakan pengujian unit untuk memeriksa
apakah modul tertentu atau kode unit
bekerja dengan baik. Pengujian unit berada pada tingkat yang sangat dasar
seperti ketika unit code dikembangkan atau fungsi tertentu dibangun
c. Integration
Testing
-
Top-down test
Top-Down
Test
adalah pengujian terpadu dimana modul terintegrasi paling atas diuji sampai
modul paling bawah dan cabang modul diuji langkah demi langkah sampai akhirnya
modul terkait. Jika suatu modul modul atas memanggil modul modul bawah, maka
modul atas diimplementasikan dan diintegrasikan lebih dahulu.
-
Bottom-up test
Bottom-Up
test
adalah sebuah pendekatan untuk pengujian terpadu dimana komponen tingkat
terendah diuji terlebih dahulu, kemudian digunakan untuk memfasilitasi
pengujian komponen tingkat yang lebih tinggi. Proses ini diulang sampai
komponen di bagian atas hierarki diuji.
-
Regression test
Regression test adalah pengulangan
uji coba untuk mencari kesalahan-kesalahan lain yang mungkin timbul. Regression
test dilakukan pengujian setiap kali ada
modul baru yang diintegrasikan atau ada modul yang berubah.
d. Validation
Test
Validation Test merupakan sekumpulan
aktivitas yang memastikan bahwa software yang dibangun dapat dilacak terhadap kebutuhan/permintaan
pelanggan.
e. Basis
path test
Pengujian basis path
adalah teknik pengujian whitebox pertama yang diusulkan Tom McCabe (1976). Basis
path memungkinkan desainer test case mengukur kompleksitas logis dari desain
prosedural dan pengukuran ini dijadikan pedoman dalam pendefinisian sekumpulan
basis dari jalur eksekusi. Yang termasuk basis path test :
1) Notasi
Diagram Alir (Path Graph Notation)
2) Kompleksitas
Siklomatik
3) Test
Case
4) Matriks
Grafik (Graph Matrices)
f.
Control structure test
Control structure testing
meliputi:
1) Testing
kondisi (Condition Testing)
Suatu metode disain test
case yang memeriksa kondisi logika yang terdapat pada modul program.
2) Testing
alur data (Data Flow Testing)
Metode data flow testing
memilih jalur program berdasarkan pada lokasi dari definisi dan penggunaan
variabel-variabel pada program. Sebagai ilustrasi pendekatan data flow testing,
diasumsikan bahwa tiap pernyataan dalam suatu program ditandai dengan suatu
penomoran pernyataan yang unik sifatnya, sebagai identitas dari tiap pernyataan
tersebut, dimana tiap fungsi tidak memodifikasi parameter atau variabel
globalnya.
3) Testing
loop (Loop Testing)
Loop testing adalah suatu
teknik white box testing yang berfokus pada validitas konstruksi loop secara
eksklusif.
g. System
test
1) Untuk memverifikasi bahwa komponen sistem melakukan fungsi kontrol
2) Untuk melakukan pengujian antar sistem
3) Untuk menunjukkan bahwa sistem melakukan baik secara fungsional dan operasional sebagaimana ditentukan
4) Untuk melakukan jenis pengujian yang tepat terkait dengan Aliran Transaksi, Pemasangan, Keandalan, Regresi, dll.
5. Pengoperasian
dan Pemeliharaan (Operation and Maintenance)
·
Dalam
sudut pandang Sistem
Audit, perhatian utama
pada operasional program
adalah bagaimana performance
program tersebut dapat dimonitor setiap saat.
·
Seseorang harus bertanggung jawab untuk
mengidentifikasi apabila program perlu perawatan, kemungkinan lain adalah
identifikasi dari kebutuhan perawatan
mungkin tidak terjadi. Akibatnya,
bisa
terjadi kekeliruan pada
database program, kegagalan dalam pencapaian keinginan user,
atau operasi program tidak efisien.
·
Mekanisme
formal dalam monitoring
status operasional program
sangat diperlukan, ketika
pengguna dari program adalah seluruh anggota organisasi yang terdiri
dari berbagai macam latar belakang.
·
Ada 3 macam tipe dari perawatan
(maintenance) yang diperlukan agar program tetap beroperasi:
a. Repair-maintenance-errors,
perawatan dengan cara memperbaiki kesalahan.
b. Adaptive
maintenance-users needs, perawatan dengan mengadaptasi pada keinginan user.
c. Perfective
maintenance, perawatan dengan maksud agar diperoleh program yang sempurna.
·
Tugas auditor :
a. Untuk
memastikan bahwa fase ini berjalan dengan efektif dan pelaporan secara berkala
dapat dilakukan, serta proses perawatan bisa di kontrol dengan baik.
b. Auditor harus
bisa mencari bukti
bawa manajemen telah
meninjau sistem dengan
baik dan bertanggungjawab
didalam monitoring status
dari operasional program. Caranya dengan
melakukan interview
(wawancara), observasi, tinjauan
pada dokumen yang
menunjukkan bahwa sistem
telah beroperasi dengan baik.
c. Selanjutnya
mereka harus fokus pada kualitas dari kontrol proses maintenance.
DAFTAR
PUSTAKA
Komentar
Posting Komentar