Manajemen Kontrol Programming

Post Test Vclass Mata Kuliah Analisis Kinerja Sistem

Struktur Team untuk Mengorganisasikan para Programmer 

Cara seorang programmer dalam menangani pekerjaan mereka sangat berpengaruh pada kualitas software yang mereka buat. Alternatifmya, para programmer bisa diorganisasikan sebagai kesatuan team. Mereka bekerja untuk periode waktu tertentu untuk menyelesaikan suatu proyek, dimana keputusannya dibicarakan diantara anggotanya. Hal ini sangat bermanfaat bila proyek yang ditangani sangat komplek dan tidak jelas.

Proses pengembangan, penerapan,dan implementasi dari software, untuk saat ini banyak dilakukan secara team. Dari segi audit, perhatian atau tujuan utamanya adalah bahwa manajemen telah memilih struktur team dengan hati-hati dilihat dari segi proyek, tingkat kompleksitasnya, dan tingkat keterlambatan dari jadwal proyek agar kemampuan dan kualitas mereka bisa diorganisasikan dalam bentuk team dimana mereka harus bekerja.

Berikut adalah struktur team yang digunakan untuk mengorganisasikan para programmer beserta dengan tugas dari masing – masing anggota team.

Untuk itu ada 3 struktur team yang digunakan untuk mengorganisasikan para programmer:

1. Chief Programmer Teams

2. Adaptives Teams dan

3. Controlled-Decentralized Teams

1.      Ketua Tim Programmer (Chief Programmer Team).

Struktur Chief Programmer Team dapat dilihat pada gambar 6.

Fungsi dan Cirinya : 

a.      Chief Programmer :

• Bertanggung jawab secara total/penuh untuk sistem dimana team bekerja
• Harus seorang ahli
• Seorang programmer yang sangat produktif
• Bertanggung jawab  dalam  mendesain,  coding,  dan  mengintegrasikan  bagian  yang  kritis dalam sistem
• Memberikan perintah kerja pada bagian back-up dan support programmers.

b.      Back-up Programmers :

• Seorang programmer  senior  yang bertanggung jawab  dalam  memberikan  dukungan  penuh pada chief programmer
• Harus bisa mengambil alih tugas chief programmer setiap saat

c.       Support Programmers:

• Diperlukan pada saat proyek besar yang tidak bisa dikerjakan oleh chief programmer dan back-up programmer saja.
• Menyediakan dukungan
• Bekerja dalam pembuatan coding dan uji coba modul tingkat rendah ( testing lowerlevel)

d.      Librarian (penyedia data) :

• Bertanggung jawab dalam perawatan program production library.
• Menyediakan  input  dan  mengumpulkan  keluaran  untuk  para  programmer,  file  output  dari hasil  kompilasi  dan  ujicoba,  mempertahankan  agar  source  code  dan  object-code  library tetap up to date.

Sruktur  “  The  Chief  Programmer  team  “  ini  di  desain  untuk  mengurangi  kebutuhan  proses informasi antara anggota team dan untuk meningkatkan kapasitas dari proses informasi.

2.      Penyesuaian Tim (Adaptives Teams)

Struktur Adaptives Teams dapat dilihat pada gambar  7.

Struktur ini diperuntukan untuk melayani 2 kebutuhan, yaitu:

1.  Keinginan organisasi untuk meningkatkan kualitas program

2.  Memenuhi kebutuhan sosial/ psikologi dari setiap anggota programmer dalam team.

Perbedaan dari struktur ini dengan struktur sebelumnya adalah:

• Adaptive  team  tidak  punya  tigkat  otoritas,  dimana  kepemimpinan  dalam  team  ada  di tangan para anggota.
• Dalam Adaptive team, tugas diberikan pada anggota dari team daripada ditentukan lewat posisi.
• Adaptive   team   tidak   mempunyai   aturan   formal   librarian   (penyedia   data)   dalam mengkoordinasikan  fungsi team.

3.      Desentraliasi Pengendalian Tim (Controlled-Decentralized Teams)

Struktur  ini  mempunyai  junior  programmer  yang  akan  melaporkan  hasil   program  pada  senior programmer, kemudian oleh senior programmer dilaporkan juga pada ketua proyek. Dengan struktur  ini, manfaat/keuntungan  dari  struktur  sebelumnya    akan    didapatkan.

Keuntungan : 

Dapat  memecahkan  masalah  yang  kompleks,  dimana  struktur  dari  grup  ini akan memfasillitasi pemecahan masalah.

Kerugian : 

Strukur  ini  tidak  bisa  bekerja  dengan  baik  apabila  tugas  dari  programmer  tersebut tidak bisa di bagi-bagi, dan dengan waktu deadline yang sangat ketat. Struktur Controlled-Decentralized Teams dapat dilihat pada gambar 8.  

Pengelolaan Kelompok Sistem Programming

Para programmer sering diklasifikasikan menurut aplikasi programmer atau sistem programmer. Dahulu,  programmer  membangun  dan  merawat  program  untuk  system aplikasinya.  Tetapi  kini, membangun dan merawat sistem software. Seperti sistem operasi, sistem manajemen database, dan komunikasi software.

Mengontrol Masalah

Mengontrol  sistem  programmer adalah tugas yang berat, mereka biasanya memiliki keahlian yang tinggi dan sering bekerja sendiri atau ada di dalam grup yang kecil. Dengan menerapkan kontrol  secara  tradisional  pada  aktivitas  merekaseperti pemisahan  tugas,  sangatlah  sulit. Mereka biasanya bekerja pada situasi yang kritis.

Mengukur Sistem Kontrol

Meskipun sulit unuk mengontrol sistem programmer, beberapa hal ini dapat di implementasikan untuk mengontrolnya:

1. Pekerjakan staf sistem programming yang mempunyai kualitas yang tinggi.
2. Pisahkan tugas seluas mungkin, contohnya tanggung jawab untuk desain dan coding sistem program dipisah dari tanggung jawab untuk uji coba program.
3. Buat metode dokumen standar.
4. Batasi  wewenang  sistem  programmer,  jadi  seorang  programmer  hanya  bekerja sesuai dengan aplikasi yang dikuasainya.
5. Jauhkan prosedur petunjuk manual dan kunci mesin dari aktivitas sistem programmer. Hal ini dimaksudkan agar aktivitas yang tidak diinginkan / sesuai dengan tugasnya tidak terjadi.
6. Pekerjakan konsulan dari luar untuk mengevaluasi pekerjaan programming.
7. Perintahkan programmer aplikasi untuk mengevaluasi pekerjaan sistem programmer secara berkala agar dapat dihasilkan program yang berkualitas.

Sumber :

http://liapsa.staff.gunadarma.ac.id/Downloads/files/16415/Bab+5+-+Mnj+Kontrol+Progamming.pdf

Manajemen Kontrol Programming

Pretest Vclass Mata Kuliah Analisis Kinerja Sistem

Tahapan Pengembangan Program

Pembuatan dan pengembangan program merupakan tahap penting dalam siklus hidup pengembangan sistem. Tujuan utama tahap ini adalah untuk menghasilkan dan menenerapkan program yang berkualitas. Terdapat 5 tahapan pengembangan program yaitu :

1. Perencanaan (Planning)

Tugas utama dari manajemen dalam tahap ini adalah 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 :

1. 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)).
2. 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.
3. Analogy (analogi) : jika proyek software yang sama pernah dibuat, penentuan sumber daya yang dibutuhkan dapat di dasarkan pada pengalaman sebelumnya.
4. 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.
5. 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 :

Pengendalian (Control)

Pada tahap kontrol ini, ada dua tujuan utama yaitu :

1. Untuk memonitor kemajuan dan beberapa tahap pada siklus hidup s/w agar tidak bertentangan dengan rencana awal.
2. 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 :

• Work Breakdown Structures (WBS), dengan teknik ini kita dapat mengidentifikasi tugas tugas yang spesifik untuk pengembangan, pengadaan, dan implementasi s/w yang dibutuhkan. (Mc.Leod and Smith 1996).
  

• Gantt Chart, dapat digunakan untuk membantu mengatur tugas (schedule) (lihat gbr.3). 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.
  

• Program Evaluation and review technique (PERT), menunjukan tugas-tugas yang harus diselesaikan, bagaimana hubungannya, kebutuhan sumber daya apa untuk setiap tugastugasnya. (lihat 4)

Seorang auditor harus mempunyai dua perhatian khusus pada kendali, pada tahap kontrol ini yaitu :

• Auditor harus dapat mengevaluasi apakah fungsi dari aktivitas kontrol dapat diterapkan juga pada software yang berbeda.
• Seorang auditor harus dapat mengumpulkan bukti apakah prosedur dari suatu kontrol sudah dijalankan dengan benar dan dapat dipercaya.

2. Perancangan (Desain)

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.

Selama tahap ini, perhatian utama seorang auditor adalah untuk menentukan apakah programmer menggunakan suatu tipe khusus dari pendekatan sistematik untuk desain. Auditor harus mengubah keinginannya berdasarkan beberapa faktor seperti ukuran dan bahan dari suatu program.

Seorang auditor juga dapat memperoleh bukti dari proses desain dengan melakukan interview, observasi, dan review dari dokumentasi. Mereka dapat berkomunikasi dengan programmer, apakah mereka dapat memahami tentang kebutuhan dengan menggunakan pendekatan yang sistematik untuk desain, jika ya, bagaimana menggunakannya.

Auditor juga dapat mengamati apakah programmer menggunakan pendekatan sistematik untuk mendesain program. 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. Selama tahap ini, programmer akan menulis dan mendokumentasikan source code (program sumber) dalam bahasa pemrograman untuk mengimplementasikan desain program.

Strategi Implementasi modul dan integrasi

Tiga strategi utama dari implementasi modul dan integrasi adalah sbb :

1. 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.
2. 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.
3. 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.

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. 

Auditor dapat melakukan wawancara untuk menguji apakah manajemen menggunakan pendekatan sistematik untuk memilih strategi implementasi modul dan integrasi. 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 (lihat gbr.5) :

1. Urutan sederhana (simple sequence - SEQUENCE)

2. Pemilihan dengan seleksi (selection based on a test – IF-THEN-ELSE) dan

3. 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.

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 :

• Shorthand preprocessor, memungkinkan programmer untuk menulis kode secara singkat, jugadapat menerjemahkan kode singkat ini dalam sintak yang lebih lengkap, contoh COBOL.

• Decision-table preprocessor, memindahkan bentuk teks program ke dalam bentuk sourcecodemenggunakan bahasa pengolahan compiler.

• Copy facility, memungkinkan penggunaan kode secara berulang

• Editor, yang memungkinkan kode di ciptakan, di format, dan dimodifikasi secara mudah.

• User-interface management system, memungkinkan desain dari implementasi yang cepat,seperti windows, icons, menus, dan dialog boxes.

• CASE tools, berisi bermacam-macam fasilitas yang dapat membantu proses koding.

Strategi Dokumentasi

Pedoman untuk menghasilkan dokumentasi yang berkualiatas adalah sbb :

1. Sediakan petunjuk yang menunjukan proes pembuatan program ke dalam beberapa tahap dan komponen secara keseluruhan dan hubungan antara komponen-komponen tersebut.
2. Gunakan baris komentar dalam program secara bebas untuk menerangkan jalannya (logika) program.
3. Beri nama untuk variabel, konstanta tipe, paragraf, modul, dan seksi yang berarti kepada para pembaca source-code program.
4. Buat lay-out dari source-program sehingga mudah untuk dibaca.
5. Kelompokan tipe kode yang saling berhubungan.

4. Pengetesan (Testing)

Testing merupakan Proses menganalisa suatu entitas software atau sistem untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang diinginkan (defect / error / bugs) dan mengevaluasi fitur-fitur atau data-data dari entitas software (standar IEEE1059). Testing dapat dikatakan sebagai proses menjalankan atau run dan mengevaluasi perangkat lunak (secara manual maupun otomatis) untuk menguji apakah perangkat lunak sudah memenuhi persyaratan atau belum, dalam artian testing ini menguji sebuah sistem apakah sistem tersebut sudah dapat di gunakan atau belum dan sudah sesuai dengan apa yang di rancang atau belumnya. Sebuah ujicoba kasus yang baik adalah yang memiliki probabilitas yang tinggi dalam menemukan kesalahan-kesalahan yang belum terungkap. Ujicoba yang berhasil adalah yang mengungkap kesalahan yang belum ditemukan.

Testing ini juga memiliki sebuah tujuan di antara lain untuk :

• Menguji sehingga dapat menemukan kesalahn yang sebelumnya belum bisa di temukan.

• Pengujian yang baik bukan untuk memastikan tidak ada kesalahan tetapi untuk memcari sebanyak mungkin kesalahan yang ada pada program, agar program yang ada dapat berjalan sesuai dengan apa yang telah di harapkan/di rencanakan.

Dynamic analysis test

Black-box test 

Black-box test berfokus pada kebutuhan fungsional software dan memungkinkan perancang untuk memperoleh kondisi input yang secara penuh menguji semua kebutuhan fungsional suatu program.

Pengujian Blackbox :

1. Berkaitan dengan pengujian pada interface PL.
2. Blackbox testing menyinggung ujicoba yang dilakukan pada interface software.
3. Blackbox testing didesain untuk menemukan kesalahan.
4. Blackbox testing digunakan untuk mendemonstrasikan fungsi software yang dioperasikan. 
5. Blackbox testing sedikit memeriksa struktur logika internal software

White-box test

White-box test berfokus pada struktur kontrol program. Semua independen path dijalankan satu kali, melakukan semua loop, melakukan struktur data internal untuk validitas.

PengujianWhitebox :

1. Didasarkan pada pemeriksaan detail prosedural.
2. Whitebox testing akan menghasilkan program yang 100% benar.
3. Whitebox testing dilakukan pada alur logika yang penting.
4. Alur logika software diujicoba dengan menyediakan kasus ujicoba dengan melakukan sekumpulan kondisi atau perulangan.

Integration Testing

Sub System Testing (Integration Testing) Integrasi program meliputi prosedur-prosedur yang disertakan untuk menghubungkan modul-modul menjadi subsistem maupun sistem lengkap. Ujicoba integrasi dibangun dari spesifikasi sistem, meliputi ujicoba terhadap hubungan antar program-program untuk menentukan kemungkinan pelaksanaan dan kekuatannya. Ujicoba diaplikasikan dan diutamakan pada ujicoba interface antar modul dalam program aplikasi. Terdapat dua pendekatan yang dapat dilaksanakan :

1. Incremental testing, modul dapat ditambahkan pada modul lainnya untuk ujicoba individual, biasanya berupa penulisan modul baru. Terdapat dua metode untuk mengaplikasikan Incremental testing, yaitu :  Top-down test  dan Bottom-up test
2. Nonincremental testing, seluruh modul dalam program dapat dibangun terlebih dahulu, kemudian digabungkan dan diujicobakan sebagai satu entitas, sehingga seluruh interface dalam modul diujicoba dalam satu waktu untuk keseluruhan program.

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)

Control Structure Test

Condition Testing bertujuan untuk mengeksekusi semua kondisi logik dari sebuah modul program. Pengujian kondisi (Condition Testing) adalah sebuah metode desain test case yang menggunakan kondisi logis yang ada pada suatu modul program. Metode pengujian kondisi berfokus pada pengujian setiap kondisi yang ada pada program.  

Keuntungan Condition Testing adalah sbb :

1. Memperkirakan pengujian berdasarkan kondisi adalah hal yang simpel.
2. Cakupan pengujian dapat mengarahkan pada penambahan kasus uji untuk semua program.

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:

1. Repair-maintenance-errors, perawatan dengan cara memperbaiki kesalahan.
2. Adaptive maintenance-users needs, perawatan dengan mengadaptasi pada keinginan user.
3. Perfective maintenance, perawatan dengan maksud agar diperoleh program yang sempurna.

Perhatian utama seorang auditor pada fase operation & maintenance adalah untuk memastikan bahwa fase ini berjalan dengan efektif dan pelaporan secara berkala dapat dilakukan, serta proses perawatan bisa di kontrol dengan baik. 

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. Selanjutnya mereka harus fokus pada kualitas dari kontrol proses maintenance.

Sumber :

http://liapsa.staff.gunadarma.ac.id/Downloads/files/16415/Bab+5+-+Mnj+Kontrol+Progamming.pdf

http://ayu_ws.staff.gunadarma.ac.id/Downloads/files/48185/Dasar-Dasar+Pengujian+Perangkat+Lunak.pdf