Dyah Chantique’s Weblog

Asal Mula C

Bahasa C dikembangkan di Laboratorium Bell (USA) sekitar tahun 1972. Penciptanya adalah Dennis M. Ritchie, seorang pakar dalam berbagai bidang pemrograman. Pertama kali C diwujudkan pada komputer DEC PDP-11 yang memakai sistem operasi UNIX. Bahasa C sendiri merupakan pengembangan dari bahasa B. Bahasa pendahulu dari C ini diciptakan oleh Ken Thompson, pada Laboratorium Bell tahun 1970, yang digunakan untuk pengimplementasian dini dari UNIX.

Pada tahun 1978 Ritchie dan Brian W. Kernighan mengeluarkan buku berjudul “The Programming C Language”. Buku inilah yang selanjutnya digunakan sebagai acuan pembuatan berbagai versi C.

Beberapa versi C yang diciptakan oleh berbagai kalangan dirancang untuk diopersikan pada sistem operasi yang lain (selain UNIX), misalnya pada PC-DOS atau MS-DOS.

Untuk melaksanakan standardisasi terhadap bahasa C, ANSI (American National Standards Institute) membentuk tim kerja untuk membuat C standar ANSI yang dimulai pada tahun 1983. Standar ANSI inilah yang selanjutnya digunakan sebagai referensi dari berbagai versi C yang beredar dewasa ini, termasuk Turbo C.

Kelebihan C

Beberapa kelebihan dari C :

• C banyak memiliki operator untuk memanipulasi data.
• Berbagai struktur data dan pengendalian proses disediakan dalam C sehingga memungkinkan untuk membuat program yang terstruktur, yakni bentuk program yang mudah dipahami dan dikembangkan.
• Dibandingkan dengan bahasa mesin atau assembly, C jauh lebih mudah dipahami dan pemrogram tidak perlu tahu detail mesin komputer sehingga tidak menyita waktu yang terlampau banyak dalam menyelesaikan suatu masalah ke dalam bentuk program. Sebab C merupakan bahasa yang berorientasi pada permasalahan, bukan berorientasi pada mesin.
• C merupakan mid-level language, namun kecepatan eksekusi C mendekati kecepatan eksekusi program yang dibuat dengan low-level language.
• C memungkinkan memanipulasi data dalam bentuk bit maupun byte secara efisien. Di samping itu juga memungkinkan untuk memanipulasi alamat dari suatu data (pada C tipe yang berkaitan dengan hal ini dinamakan pointer).

Kelemahan C

Adapun kelemahan (lebih tepatnya adalah kesulitan) C yang dirasakan oleh para pemula C :

• Banyaknya operator serta fleksibilitas penulisan program kadang-kadang membingungkan pemakai.
• Para pemrogram C tingkat pemula umumnya belum pernah mengenal pointer dan tidak terbiasa menggunakannya (sebab bahasa BASIC yang biasanya merupakan bahasa dasar bagi para pemrogram memang tidak mengenal istilah pointer). Padahal keampuhan C justru terletak pada pointer.

One of the most useful concepts in computer science is that of the stack. A stack is an ordered collection of items into which new items may be inserted and from which items may be deleted at one end, called the top of the stack.

Unlike that of the array, the definition of stack provides for the insertion and deletion of items, so that a stack is a dynamic, constantly changing object. The definition specifies that a single end of the stack is designated as the stack top. New items may be put on top of the stack (in which case the top of the stack moves upward to correspond to the new highest element), or items which are at the top of the stack may be removed (in which case the top of the stack moves downward to correspond to the new highest element). A stack is sometimes called a Last-In, First Out (LIFO) list.

Stack containing stack items :

Primitive Operations

The two changes which can be made to a stack are given special names. When an item is added to a stack, it is pushed onto the stack. And when an item is removed, it popped from the stack.

Representing Stack in C
A stack in C may therefore be declared as a structure containing two objects : an array to hold the elements of the stack, and an integer to indicate the position of current stack top within the array.

#define STACKSIZE 100
struct stack
{
int top;
int items[STACKSIZE];
};

struct stack s;

The empty stack contains no elements and can therefore be indicated by top equalling to -1. To initialize a stack s to the empty state, we may initially execute : s.top = -1;

We may write a function that returns TRUE if the stack is empty and FALSE if it is not empty.

int empty(struct stack *ps)
{
if(ps->top == -1) return(TRUE);
else return(FALSE);
}

Implementing The Pop Operation

The possibility of underflow must be considered in implementing the pop operation, since the user may inadvertently attempt to pop an element from an empty stack. We therefore introduce a function pop that performs the following three actions :

• If the stack is empty, print a warning message and halt execution
• Remove the top element from the stack
• Return this element to the calling program

int pop(struct stack *ps)
{
if(empty(ps)){
printf(“Stack underflow”);
exit(1);
}
return(ps->items[ps->top–]);
}

The use of pop function, the programmer can declared int x and write :

x = pop(&s);

x then contained the value poped from the stack.

Implementing The Push Operation

The possibility of overflow must be considered in implementing the push operation, since the user may inadvertently attempt to push an element onto a full stack.

void push(struct stack *ps, int x)
{
if(ps->top == STACKSIZE - 1){
printf(“Stack overflow”);
exit(1);
}
else ps->items[++(ps->top)] = x;
}

The use of push function, the programmer can write :

push(&s,x);

Stemming adalah proses untuk menggabungkan atau memecahkan setiap varian-varian suatu kata menjadi kata dasar.

Stem (akar kata) adalah bagian dari kata yang tersisa setelah dihilangkan imbuhannya (awalan dan akhiran). Contoh : connect adalah stem dari connected, connecting, connection, dan connections.

Metode stemming memerlukan input berupa term yang terdapat dalam dokumen. Sedangkan outputnya berupa stem.

Ada tiga jenis metode stemming, antara lain :

• Successor Variety (SV) : llebih mengutamakan penyusunan huruf dalam kata dibandingkan dengan pertimbangan atas fonem. Contoh untuk kata-kata : corpus, able, axle, accident, ape, about menghasilkan SV untuk kata apple :
  • Karena huruf pertama dari kata “apple” adalah “a”, maka kumpulan kata yang ada substring “a” diikuti “b”, “x”, “c”, “p” disebut SV dari “a” sehingga “a” memiliki 4 SV.
  • Karena dua huruf pertama dari kata “apple” adalah “ap”, maka kumpulan kata yang ada substring “ap” hanya diikuti “e” disebut SV dari “ap” sehingga “ap” memiliki 1 SV.
• N-Gram Conflation : ide dasarnya adalah pengelompokan kata-kata secara bersama berdasarkan karakter-karakter (substring) yang teridentifikasi sepanjang N karakter.
• Affix Removal : membuang suffix dan prefix dari term menjadi suatu stem. Yang paling sering digunakan adalah algoritma Porter Stemmer karena modelnya sederhana dan effisien.
  • Jika suatu kata diakhiri dengan “ies” tetapi bukan “eies” atau “aies”, maka “ies” direplace dengan “y”
  • Jika suatu kata diakhiri dengan “es” tetapi bukan “aes” atau “ees” atau “oes”, maka “es” direplace dengan “e”
  • Jika suatu kata diakhiri dengan “s” tetapi bukan “us” atau “ss”, maka “s” direplace dengan “NULL”

Porter stemmer merupakan algoritma penghilangan akhiran morphological dan infleksional yang umum dari bahasa Inggris. Algoritma ini terdiri dari himpunan kondisi atau action rules.

Kondisi dikelompokkan menjadi tiga kelas, yakni :

• Kondisi pada stem
  • Ukuran (measure), dinotasikan dengan m, dari sebuah stem berdasarkan pada urutan vokal-konsonan.
    • m = 0, contoh : TR, EE, TREE, Y, BY
    • m = 1, contoh : TROUBLE, OATS, TREES, IVY
    • m = 2, contoh : TROUBLES, PRIVATE, OATEN

• • *<X> berarti stem berakhir dengan huruf X
  • *v* berarti stem mengandung sebuah vokal
  • *d berarti stem diakhiri dengan konsonan dobel
  • *o berarti stem diakhiri dengan konsonan – vokal – konsonan, berurutan, di mana konsonan akhir bukan w, x, atau y.
• Kondisi pada suffix : (current_suffix == pattern)
• Kondisi pada rule : rule-rule dibagi menjadi step-step. Rule-rule dalam sebuah step diuji secara berurutan, dan hanya 1 rule dari suatu step yang diterapkan.

{
step1a(word);
step1b(stem);
if (the second or third rule of step 1b was used) step1b1(stem);
step1c(stem);
step2(stem);
step3(stem);
step4(stem);
step5a(stem);
step5b(stem);
}

Control flow algoritma Porter Stemmer :

Step-step algoritma Porter Stemmer :

• Step 1a : remove plural suffixation

• Step 1b : remove verbal inflection

• Step 1b1 : continued for -ed and -ing rules

• Step 1c : y and i

• Step 2 : peel one suffix off for multiple suffixes

• Step 3
  

• Step 4 : delete last suffix

• Step 5a : remove e

• Step 5b : reduction

Temu kembali informasi (information retrieval) adalah ilmu pencarian informasi pada dokumen, pencarian untuk dokumen itu sendiri, pencarian untuk metadata yang menjelaskan dokumen, atau mencari di dalam database, baik relasi database yang stand-alone atau hipertext database yang terdapat pada network seperti internet atau World Wide Web atau intranet, untuk teks, suara, gambar, atau data. Information retrieval (IR) adalah ilmu yang lahir dari berbagai disiplin ilmu, baik ilmu komputer, matematika, ilmu kepustakaan, ilmu informasi, psikologi kognitif, linguistik, statistik, maupun fisika.

Secara prinsip, penyimpanan informasi dan penemuan kembali informasi adalah hal yang sederhana. Misalkan terdapat tempat penyimpanan dokumen-dokumen dan seseorang (user) merumuskan suatu pertanyaan (request atau query) yang jawabannya adalah himpunan dokumen yang mengandung informasi yang diperlukan yang diekspresikan melalui pertanyaan user. User bisa saja memperoleh dokumen-dokumen yang diperlukannya dengan membaca semua dokumen dalam tempat penyimpanan, menyimpan dokumen-dokumen yang relevan dan membuang dokumen lainnya. Hal ini merupakan perfect retrieval, tetapi solusi ini tidak praktis. Karena user tidak memiliki waktu atau tidak ingin menghabiskan waktunya untuk membaca seluruh koleksi dokumen, terlepas dari kenyataan bahwa secara fisik user tidak mungkin dapat melakukannya.

Oleh karena itu, diperlukan suatu sistem temu kembali informasi (information retrieval system) untuk membantu user menemukan dokumen yang diperlukannya.

Ilustrasi sistem temu kembali informasi :

Model IR ada tiga jenis, yaitu :

• Model Boolean : merupakan model IR sederhana yang berdasarkan atas teori himpunan dan aljabar boolean
• Model Vector Space : merupakan model IR yang merepresentasikan dokumen dan query dalam bentuk vektor dimensional
• Model Probabilistic : merupakan model IR yang menggunakan framework probabilistik

Taksonomi model IR :

Definisi pengujian perangkat lunak (PL) :

• Menurut Myers (1979)
  • Proses menjalankan program dengan maksud menemukan kesalahan
• Menurut IEEE (1990)
  • Proses sistem operasi atau komponen menurut kondisi tertentu, pengamatan atau pencatatan hasil dan mengevaluasi beberapa aspek sistem atau komponen
  • Proses analisis item PL untuk mendeteksi perbedaan antara kondisi yang ada dengan yang diinginkan dan mengevaluasi fitur item PL
• Definisi lanjut
  • Proses formal yang ditentukan oleh tim pengujian yang meliputi unit PL, beberapa unit PL terintegrasi atau seluruh package PL yang ditentukan oleh program yang berjalan di komputer. Seluruh tes saling terkait dan adanya prosedur pengujian dan kasus pengujian.

Tujuan pengujian PL :

• Tujuan langsung
  • Identifikasi dan menemukan beberapa kesalahan yang mungkin ada dalam PL yang diuji
  • Setelah PL dibetulkan, diidentifikasi lagi kesalahan dan dites ulang untuk menjamin kualitas level penerimaan
  • Membentuk tes yang efisien dan efektif dengan anggaran dan jadwal yang terbatas
• Tujuan tidak langsung
  • Mengumpulkan daftar kesalahan untuk digunakan dalam daftar pencegahan kesalahan (tindakan corrective dan preventive)

Strategi pengujian PL :

• Big bang testing : menguji PL keseluruhan, sekali untuk semua package yang ada
• Incremental testing : menguji PL per bagian dalam modul (unit testing), dilanjutkan dengan menguji integrasi tiap modul (integration test), selanjutnya seluruh package diuji (system testing)

Incremental testing :

• Dibentuk dari dua dasar strategi :
  • Top-down
    • Modul pertama yang diuji : modul utama (tertinggi)
    • Modul terakhir yang diuji : modul pada level paling rendah
    • Keuntungan : memperlihatkan keseluruhan fungsi program (semua modul lengkap)
    • Kerugian : sulit menyiapkan potongan program dan menganalisis hasil tes
  • Bottom-up : kebalikan top-down
    • Keuntungan : relatif mendorong performance
    • Kerugian : menghambat program sebagai suatu keseluruhan modul
• Keduanya menganggap package PL dibangun berdasarkan hirarki modul PL

Pengelompokan berdasarkan konsep pengujian :

• Black box (functionality) testing : mengidentifikasi kesalahan yang berhubungan dengan kesalahan fungsionalitas PL yang tampak dalam kesalahan output
• White box (structural) testing / glass box testing : memeriksa kalkulasi internal path untuk mengidentifikasi kesalahan

Definisi menurut IEEE :

• Black box testing
  • Pengujian yang mengabaikan mekanisme internal sistem atau komponen dan fokus semata-mata pada output yang dihasilkan yang merespon input yang dipilih dan kondisi eksekusi
  • Pengujian yang dilakukan untuk mengevaluasi pemenuhan sistem atau komponen dengan kebutuhan fungsional tertentu
• White box testing
  • Pengujian yang memegang perhitungan mekanisme internal sistem atau komponen

White box testing memiliki empat kategori :

• Data processing and calculations correctness test : melakukan pengecekan data processing untuk setiap kasus tes
  • Pendekatan yang digunakan :
    • Path coverage : rencana tes yang mencakup semua kemungkinan path, di mana coverage diukur dengan berapa % path dicover
    • Line coverage : rencana tes yang mencakup semua baris kode program, di mana coverage diukur dengan berapa % line dicover
  • Correctness test & path coverage
    • Path yang berbeda dalam modul PL akan dibentuk oleh pilihan kondisional statement seperti IF-THEN-ELSE / DO WHILE / DO UNTIL.
    • Untuk full line coverage, tiap line dieksekusi min 1 kali selama proses pengujian, contoh : Imperial Taxi Service (ITS) taximeter ada 24 test case
• Software qualification test
• Maintainability test
• Reusability test

Mc Cabe’s cyclomatic complexity metric (1976) :

• Tujuan : mengukur kompleksitas program atau modul pada waktu yang sama sebagai jumlah maksimum independent path yang dibutuhkan untuk mencapai full line coverage pada program
• Dasar ukuran : teori graph dan dihitung berdasarkan kesesuaian sifat program yang dicapture oleh program flow graph
• Independent path : setiap path pada program flow graph sedikitnya satu baris yang tidak dibentuk oleh independent path lain
• Rumus : V(G) = R = E – N + 2 = P + 1
• Keterangan :
  • V(G) = cyclometic complexity graph
  • R = jumlah region dalam program flow graph
  • E = jumlah edge
  • N = jumlah node
  • P = jumlah decision (percabangan)
• Contoh kasus : Imperial Taxi Services (ITS) :
  • V(G) = R = 6
  • V(G) = E – N + 2 = 21 – 17 + 2 = 6
  • V(G) = P + 1 = 5 + 1 = 6

Komponen Software Quality Assurance (SQA) :

• Pre-proyek
• Penilaian aktivitas daur hidup proyek
• Pencegahan dan perbaikan infrastruktur proyek
• Manajemen Kualitas Perangkat Lunak (MKPL)
• Standarisasi, sertifikasi, dan penilaian dalam sistem SQA
• Organisasi SQA -> komponen manusia

Pre-proyek menjamin atas :

• Komitmen bahwa proyek sesuai dengan sumber daya, jadwal, dan anggaran yang telah ditentukan
• Pembangunan dan rencana kualitas telah ditentukan dengan benar

Pre-proyek terdiri dari :

• Kontrak review
  • Klarifikasi kebutuhan pelanggan
  • Review jadwal proyek dan perkiraan kebutuhan sumber daya
  • Evaluasi kemampuan staf profesional untuk melaksanakan proyek
  • Evaluasi kemampuan pelanggan untuk memenuhi kewajibannya
• Pembangunan dan rencana kualitas
  • Jadwal
  • Kebutuhan manpower dan sumber daya hardware
  • Evaluasi risiko
  • Persoalan organisasi : anggota tim, sub kontraktor, dan rekanan
  • Metodologi proyek, tools pengembangan, dll
  • Rencana penggunaan ulang perangkat lunak (PL)

Penilaian aktivitas daur hidup proyek ada dua tahap, yaitu :

• Tahap siklus hidup pengembangan : mendeteksi kesalahan desain dan programming
  • Review
  • Pendapat ahli
  • Pengujian PL
  • Jaminan kualitas untuk pekerjaan sub kontraktor dan kesediaan pelanggan
• Tahap operasi maintenance
  • Corrective maintenance
  • Adaptive maintenance
  • Functionality improvement maintenance
• Komponen pre-maintenance :
  • Maintenance kontrak review
  • Rencana maintenance
• Komponen infrastruktur SQA :
  • Prosedur maintenance dan instruksi
  • Dukungan perlengkapan kualitas
  • Maintenance pelatihan staf, pelatihan ulang, dan sertifikasi
  • Tindakan preventive dan corrective maintenance
  • Manajemen konfigurasi
  • Kontrol dokumentasi maintenance dan laporan kualitas
• Kontrol manajerial komponen SQA :
  • Kontrol maintenance servis
  • Metriks maintenance kualitas
  • Biaya maintenance kualitas

Pencegahan dan perbaikan infrastruktur proyek :

• Tujuan utama : untuk melenyapkan atau mengurangi error yang didasarkan atas pengalaman SQA organisasi
• Mencakup :
  • Prosedur dan instruksi pekerjaan
  • Template dan checklist
  • Pelatihan staf, pelatihan ulang, dan sertifikasi
  • Tindakan pencegahan dan perbaikan
  • Kontrol dokumentasi

Manajemen Kualitas Perangkat Lunak (MKPL) :

• Merupakan pelengkap dari beberapa tujuan, salah satunya adalah mengontrol aktivitas pembangunan dan perawatan serta memperkenalkan lebih awal dukungan manajerial untuk mencegah atau meminimalisir kegagalan jadwal dan anggaran serta akibatnya
• Terdiri dari :
  • Kontrol progress proyek (mencakup kontrol kontrak maintenance)
    • Penggunaan sumber daya
    • Jadwal
    • Aktivitas manajemen risiko
    • Anggaran
  • Metriks kualitas PL
    • Kualitas pembangunan PL dan aktivitas maintenance
    • Pembentukan kelompok produktivitas
    • Help desk dan maintenance tim produktivitas
    • Tingkat kegagalan PL
    • Selisih jadwal
  • Biaya kualitas PL

Standarisasi, sertifikasi, dan penilaian sistem SQA :

• Tujuan :
  • Pengetahuan profesional internasional
  • Perbaikan koordinasi kualitas sistem organisasi dengan organisasi lain yang sejenis
  • Penilaian pencapaian kualitas sistem sesuai dengan skala umum
• Standar yang digunakan :
  • Standar manajemen kualitas : SEI CMM, ISO 9001, dan ISO 9000-3
  • Standar proses proyek : IEEE 1012, ISO / IEC 12207

Organisasi SQA -> komponen manusia :

• Memiliki aktor-aktor :
  • Manajer
  • Personal pengujian
  • Unit dan praktisi SQA yang tertarik pada kualitas PL
• Tujuan utama :
  • Memulai dan mendukung pelaksanaan komponen SQA
  • Mendeteksi deviasi dari prosedur SQA dan metodologi
  • Mengusulkan perbaikan komponen SQA

Peran manajemen dalam SQA :

• Mendefinisikan kebijakan dalam kualitas
• Secara efektif menindaklanjuti pelaksanaan kebijakan kualitas
• Alokasi kecukupan sumber daya untuk melaksanakan kebijakan kualitas
• Menugaskan staf yang mampu
• Menindaklanjuti pemenuhan prosedur jaminan kualitas
• Penyelesaian jadwal, anggaran, dan kesulitan hubungan dengan pelanggan

Unit SQA :

• Menyiapkan laporan program kualitas
• Konsultasi dengan staf dan ahli dari luar dalam permasalahan kualitas PL
• Memimpin internal audit jaminan kualitas
• Kepemimpinan dari panitia jaminan kualitas
• Mendukung komponen infrastruktur jaminan kualitas yang ada dan memperbaruinya serta membangun komponen baru

Pengawas, panitia, dan forum SQA :

• Penyelesaian tim atau unit lokal masalah kualitas
• Mendeteksi deviasi dari prosedur kualitas dan instruksi
• Menginisialisasi perbaikan komponen SQA
• Pelaporan ke unit SQA tentang permasalahan kualitas di dalam tim atau unit

Issue utama dalam panitia :

• Solusi masalah kualitas PL
• Analisis masalah dan laporan kegagalan sebaik laporan lain, diikuti inisialisasi tindakan perbaikan dan pencegahan yang tepat
• Inisialisasi dan pembangunan prosedur baru, pelaksanaan dan perbaharuan bahan yang ada
• Inisialisasi dan pembangunan komponen SQA yang baru serta perbaikan komponen yang ada

Tahapan dan proses kontrak review

• Tahap 1 : review draft proposal untuk pelanggan (proposal draft review)
• Tahap 2 : review draft proposal sebelum ditandatangani (contract draft review)

Tujuan review kontrak :

• Tujuan review draft proposal
  • Klarifikasi dan dokumentasi kebutuhan pengguna
  • Pendekatan alternatif untuk menyelesaikan proyek telah diuji
  • Aspek formal hubungan pelanggan dan perusahaan pengembang perangkat lunak (PL) ditentukan
  • Identifikasi pembangunan risiko
  • Penilaian sumber daya proyek dan jadwal telah cukup disiapkan
  • Pengujian kapasitas perusahaan berkenaan dengan proyek
  • Pengujian kapasitas pelanggan untuk memenuhi komitmennya
  • Definisi partner dan kondisi-kondisi keikutsertaan sub kontraktor
  • Definisi dan perlindungan hak kepemilikan
• Tujuan review draft kontrak
  • Tidak ada isu yang tidak diperjelas di draft kontrak
  • Semua pengertian yang disepakati di proposal didokumentasikan
  • Tidak ada perubahan baru, tambahan atau pengurangan yang dimasukkan ke draft kontrak

Pelaksanaan review kontrak :

• Faktor yang mempengaruhi tingkat tinjauan review kontrak
  • Proyek penting atau besar, selalu mengukur sumber daya man-month
  • Kompleksitas teknikal proyek
  • Derajat tingkat pengetahuan staf dan pengalaman lingkup proyek
  • Kompleksitas organisasi proyek
• Siapa yang melakukan kontrak review
  • Pimpinan atau anggota lain dalam tim proyek
  • Anggota tim proposal
  • Profesional luar atau staf perusahaan yang tidak menjadi anggota tim proposal
  • Anggota ahli dari luar
• Pelaksanaan kontrak review untuk proposal utama
  • Review kontrak seharusnya dijadwalkan
  • Tim seharusnya membawa review kontrak
  • Pimpinan tim kontrak review seharusnya ditetapkan

Review kontrak untuk proyek internal :

• Suatu proposal cukup untuk proyek internal
• Menggunakan proses review kontrak yang tepat untuk proyek internal
• Kesepakatan yang sesuai antara pelanggan internal dan supplier internal

Rencana kualitas dan pengembangannya :

• Tujuan rencana kualitas dan pengembangannya :
  • Jadwal aktivitas pengembangan akan mendorong ke arah penyelesaian yg tepat waktu, kesuksesan proyek, perkiraan anggaran, & sumber daya tenaga kerja yg diperlukan
  • Merekrut anggota dan mengalokasikan sumber daya pengembangan
  • Penyelesaian risiko pengembangan
  • Penerapan aktivitas SQA
  • Penyediaan manajemen dengan data yang diperlukan untuk kendali proyek
• Elemen rencana pengembangan
  • Produk proyek, mencakup produk-produk :
    • Dokumen perancangan, menetapkan waktu penyelesaian, mengindikasikan materi yang dikirim ke pelanggan
    • Training, menentukan tanggal, peserta, dan tempat
  • Interface proyek
    • Interface dengan package PL yang ada
    • Interface dengan PL lain atau tim pengembangan hardware yang bekerja pada sistem atau proyek yang sama
    • Interface dengan hardware yang ada
  • Metodologi proyek dan tools pengembangan yang dimasukkan ke setiap fase proyek
  • Standar dan prosedur pengembangan PL
  • Pemetaan proses pengembangan
    • Perkiraan lamanya aktivitas
    • Rangkaian logis pada setiap aktivitas yang dilakukan
    • Jenis sumber daya profesional yang dibutuhkan dan perkiraan berapa banyak sumber daya yang diperlukan untuk setiap aktivitas
  • Milestone proyek
  • Pengaturan staf proyek
    • Struktur organisasi : definisi anggota tim dan pekerjaan, terdiri dari sub kontraktor, pekerja sementara
    • Kebutuhan profesional : sertifikasi, pengalaman dalam bahasa pemrograman tertentu atau tools pengembangan
    • Jumlah orang yang dibutuhkan untuk setiap periode waktu
    • Nama pimpinan dan anggota tim
  • Fasilitas pengembangan
  • Risiko pengembangan
    • Gap teknologi
    • Kekurangan staf
    • Ketergantungan elemen organisasi
  • Metode pengendalian
  • Perkiraan biaya proyek
• Elemen rencana kualitas
  • Daftar tujuan kualitas
  • Aktivitas review :
    • Lingkup, jenis, dan jadwal aktivitas review
    • Prosedur khusus yang ditambahkan
    • Siapa yang bertanggung jawab melaksanakan aktivitas review
  • Rencana pengujian PL
    • Pengujian unit, integrasi, atau keseluruhan sistem
    • Jenis aktivitas pengujian yang dipakai, termasuk spesifikasi PL yang diuji
    • Jadwal rencana pengujian
    • Prosedur khusus yang ditambahkan
    • Siapa yang bertanggung jawab melaksanakan pengujian
  • Test penerimaan
  • Prosedur dan tools manajemen konfigurasi
• Rencana kualitas dan pengembangan untuk proyek kecil dan internal
  • Rencana pengembangan
  • Produk proyek (indikasi -> setoran)
  • Benchmark proyek
  • Pengembangan risiko
  • Perkiraan anggaran proyek
  • Tujuan kualitas

Penginapan merupakan salah satu sarana dan fasilitas yang diperlukan bagi masyarakat sebagai tempat tinggal sementara, khususnya bagi masyarakat yang sedang melaksanakan perjalanan wisata ke suatu tempat.

Fasilitas yang disediakan oleh penginapan ini terdiri dari bermacam-macam jenis pelayanan bagi customer, misalnya pelayanan Deluxe, VVIP, VIP, standard, ekonomi dimana setiap jenis pelayanan terdapat kategori single bed dan double bed. Fasilitas pelayanan penginapan yang disediakan berbanding lurus dengan harga yang ditawarkan kepada customer. Setiap penggunaan fasilitas penginapan (laundry, telepon, snack, minuman dll) akan ditagihkan pada saat check out.

Setiap kali customer melakukan check-in, maka data customer disimpan pada database penginapan. Pembayaran check-in customer bisa melalui pembayaran tunai, kartu kredit, dll. Selain itu, check-in penginapan / reservasi penginapan bisa dilakukan via internet (pembayaran melalui rekening bank). Jika customer melakukan reservasi penginapan dalam waktu kurang dari 10 hari dari hari-H maka customer bisa mendapatkan potongan harga penginapan. Sedangkan customer yang membatalkan reservasi, uang reservasi dikembalikan sebesar 20%.

Untuk pegawai penginapan, terdapat status dan jenis pegawai di mana status pegawai dibedakan menjadi pegawai tetap, tidak tetap, dan magang. Sedangkan jenis pegawai terdiri dari resepsionis, roomboy, security, koki, waitress, administrator, manajer. Setiap pegawai memiliki hak akses masing-masing sesuai dengan jabatannya, misalnya administrator memiliki hak akses penuh pada database penginapan. Selain itu, terdapat pembagian shift kerja pada pegawai. Penggajian pegawai dihitung berdasarkan status, jenis, absensi, dan lembur. Pegawai yang mengambil cuti, akan mendapat potongan gaji.

Beberapa model faktor kualitas perangkat lunak (PL) :

• Model klasik (Mc Call) : 11 faktor kualitas
• Model Deutsch dan Willis : 12 - 15 faktor kualitas
• Model Evans dan Marciniak

Model Mc Call, 11 faktor kualitas PL dikelompokkan menjadi tiga kategori :

• Faktor operasi produk
  • Correctness : daftar sistem PL yang memberikan output yang benar sesuai dengan spesifikasi kebutuhan PL
  • Reliability : maksimum terjadi failure yang dibolehkan
  • Efficiency : berhubungan dengan sumber daya hardware untuk
    melakukan semua fungsi sistem PL dalam melayani kebutuhan
  • Integrity : berhubungan dengan security sistem, pencegahan akses untuk orang-orang yang tidak berhak, pembedaan user yang dapat melakukan create, read, update, delete (CRUD)
  • Usability : berhubungan dengan sumber daya pegawai yang diperlukan untuk melatih pegawai baru dan mengoperasikan sistem PL
• Faktor revisi produk
  • Maintainability : mendefinisikan usaha yang diperlukan user dan personil perawatan untuk mengidentifikasi alasan software failure dan membuktikan keberhasilan perbaikan
  • Flexibility : kemampuan dan usaha yang diperlukan untuk mendukung aktivitas adaptive maintenance
  • Testability : berhubungan dengan testing
• Faktor transisi produk
  • Portability : adaptasi sistem PL dengan lingkungan lain yang mencakup perbedaan hardware, sistem operasi, dll
  • Reusability : berhubungan dengan penggunaan modul asli PL yang didesain untuk project baru yang dibangun
  • Interoperability : fokus pada pembuatan interface dengan sistem PL lain atau dengan peralatan perusahaan lain

Jenis-jenis maintenance PL :

• Corrective maintenance : koreksi error-error yang muncul pada saat PL mulai digunakan
• Adaptive maintenance : adaptasi terhadap perubahan-perubahan, new release, tidak merubah fungsi atau unjuk kerja
• Perfective maintenance : PL masih OK, tapi dibutuhkan fungsi-fungsi / fitur-fitur baru
• Preventive maintenance : reverse engineering dan re-engineering

Komponen SQA :

• Pre-proyek
• Daur hidup proyek PL
• Pencegahan kesalahan infrastruktur dan perbaikannya
• Manajemen Kualitas Perangkat Lunak (MKPL)
• Standarisasi, sertifikasi, dan penilaian SQA
• Manajemen SQA -> komponen manusia

Pre-proyek

• Review kontrak
  • Klarifikasi kebutuhan pengguna
  • Review jadwal proyek dan menaksir kebutuhan sumber daya
  • Evaluasi kapasitas staf yang profesional untuk menyelesaikan proyek
  • Evaluasi kapasitas pelanggan untuk memenuhi kewajibannya
  • Evaluasi risiko pengembangan
• Rencana pengembangan
  • Jadwal
  • Kebutuhan manpower dan sumber daya hardware
  • Evaluasi risiko
  • Organisasi issue : anggota tim, sub kontraktor, dan partnership
• Rencana kualitas
  • Tujuan kualitas dalam lingkup yang terukur
  • Kriteria untuk memulai dan mengakhiri setiap tahap proyek
  • List review, tes, verifikasi dan validasi

Daur hidup proyek PL :

• Review
• Pendapat ahli
• Pengujian PL
• Perawatan PL
• Jaminan kualitas sub kontraktor dan kesediaan pengguna

Pencegahan kesalahan infrastruktur dan perbaikannya :

• Prosedur dan petunjuk kerja
• Template dan checklist
• Training staf, training ulang, dan sertifikasi
• Langkah preventif dan korektif
• Manajemen konfigurasi
• Kontrol dokumentasi

Manajemen Kualitas Perangkat Lunak (MKPL) :

• Kontrol progress proyek
  • Penggunaan sumber daya
  • Jadwal
  • Manajemen risiko
  • Anggaran
• Metrik kualitas PL
  • Aktivitas pengembangan dan perawatan kualitas PL
  • Produktivitas tim pengembangan
  • Help desk dan produktivitas tim perawatan
  • Fault density PL
  • Perbedaan jadwal
• Biaya kualitas PL

Standarisasi, sertifikasi, dan penilaian SQA :

• Tujuan :
  • Penggunaan pengetahuan profesional internasional
  • Perbaikan koordinasi dengan kualitas sistem organisasi lain
  • Evaluasi profesional dan pengukuran pencapaian kualitas sistem organisasi
• Standar manajemen kualitas : ISO 9001 & ISO 9000-3
• Standar proses proyek : IEEE 1012 & ISO / IEC 12207

Manajemen SQA -> komponen manusia

• Definisi kebijakan kualitas
• Tindak lanjut efektif pelaksanaan kebijakan kualitas
• Alokasi kecukupan sumber daya untuk melaksanakan kebijakan kualitas
• Penugasan staf yang mampu
• Meninjak lanjuti pemenuhan prosedur manajemen kualitas
• Penyelesaian jadwal, anggaran, dan hubungan pelanggan yang sulit

Evolusi perangkat lunak (PL) :

• Pengembangan PL : requirements, specifications, design, coding, testing, inspection
  • Requirements : kebutuhan dari user
  • Specifications : analisis apa saja kebutuhan user
  • Design : buat model data dan model proses
  • Coding : coding desain
  • Testing : untuk menguji kelayakan PL, ada error atau tidak
  • Inspection : maintenance
    
• Perawatan PL : proses memperpanjang waktu pakai PL
• Migrasi PL : proses perpindahan PL ke setting yang baru

Evolusi PL harus bisa :

• Memenuhi requirement yang baru, contoh : menyediakan user interface yang berbasis web
• Mengurangi kompleksitas, biaya mendatang dan waktu ke pasaran
• Menggunakan bahasa yang modern
• Mengurangi defect : menyediakan violation standar coding

Definisi PL :

• Menurut Pressman
  • Instruksi atau program komputer yang ketika dijalankan menyediakan fungsi dan performance yang diinginkan dan
  • Struktur data yang memungkinkan program memanipulasi informasi dan
  • Dokumen yang menggambarkan cara menggunakan dan mengoperasikan program tersebut
• Menurut IEEE & ISO 1997
  • Program komputer (code)
  • Prosedur
  • Dokumentasi
  • Data yang diperlukan untuk mengoperasikan sistem PL
• Dalam perspektif Software Quality Assurance (SQA) / Jaminan Kualitas PL
  
  • PL adalah gabungan program komputer (code), prosedur, dokumentasi dan data yang diperlukan untuk mengoperasikan sistem PL
• Kombinasi keempat komponen ini diperlukan untuk menjamin kualitas proses pengembangan PL sebagus kepastian perawatan dalam jangka panjang.

Kesalahan PL :

• Software error : bagian code yang sebagiannya atau keseluruhannya salah, yang diakibatkan oleh kesalahan gramatical, logical, atau kesalahan lain yang dibuat oleh analis sistem, programmer atau anggota lain yang terlibat dalam tim pengembangan PL
• Software defect : bagian PL yang tidak memenuhi dokumentasi pengembangan PL
• Software fault : software error yang menyebabkan kesalahan fungsional
• Software failure : kesalahan PL yang terjadi ketika user meminta bagian PL yang fault. Sumber software failure adalah software error.

Definisi kualitas PL :

• Menurut IEEE
  • Derajat sistem, komponen, atau proses yang sesuai dengan spesifikasi atau
  • Derajat sistem, komponen, atau proses yang memenuhi kebutuhan customer atau ekspektasinya
• Menurut Pressman
  • Kesesuaian kebutuhan fungsional dan performance, adanya dokumentasi standar, dan memiliki sifat yang diharapkan oleh semua profesional pengembang PL

Definisi SQA :

• Menurut IEEE
  • Pola yang terencana dan sistematis dari semua tindakan yang diperlukan untuk menyediakan kepercayaan yang cukup terhadap suatu item atau produk disesuaikan ke kebutuhan teknis
  • Kumpulan aktivitas yang didesain untuk mengevaluasi proses di mana produk dihasilkan
• Definisi lanjut
  • Kumpulan aktivitas yang sistematis dan terencana untuk menyediakan proses pembangunan PL atau proses perawatan dari produk sistem PL yang memenuhi kebutuhan teknis fungsional, seperti halnya dengan kebutuhan managerial untuk memelihara jadwal dan operasi dalam anggaran yang terbatas

Tujuan SQA :

• Software development (process-oriented)
  • Menjamin suatu level penerimaan bahwa PL sesuai dengan requirement fungsional
  • Menjamin suatu level penerimaan bahwa PL sesuai dengan jadwal managerial dan kebutuhan biaya
  • Menginisialisasi dan mengatur aktivitas perbaikan dan peningkatan efisiensi pengembangan PL dan aktivitas SQA
• Software maintenance (product oriented)
  • Menjamin dengan level penerimaan bahwa aktivitas perawatan PL akan sesuai dengan kebutuhan fungsional
  • Menjamin dengan level penerimaan bahwa aktivitas perawatan PL akan sesuai dengan jadwal dan kebutuhan biaya
  • Menginisialisasi dan mengatur aktivitas perbaikan dan peningkatan efisiensi perawatan PL dan aktivitas SQA

Alasan memperhatikan kualitas PL : karena kualitas adalah :

• Masalah persaingan
• Penting supaya dapat survive
• Penting untuk global marketing
• Mengefektifkan biaya
• Mempertahankan customer dan meningkatkan keuntungan

Reaksi berantai Deming

Kualitas produk adalah :

• Kesesuaian dengan kebutuhan
• Kelayakan untuk digunakan
• Bebas dari error dan failure
• Kepuasan customer

Parameter kualitas PL :

• Parameter teknis (objektif) : solusi teknis
  • Correctness : ukuran tingkat defect
  • Reliability : ukuran failure
  • Capability : ukuran requirement coverage
  • Performance : ukuran kecepatan dan penggunaan sumber daya
  • Maintainability : ukuran change log
• Parameter user (subjektif) : solusi non teknis
  • Usability : berapa % user senang dengan interface dan kemudahan penggunaan
  • Installability : jumlah masalah instalasi yang dilaporan per instalasi
  • Documentation : berapa % user senang dengan dokumentasi
  • Availability : berapa % user melaporkan masalah akses

Prinsip-prinsip dasar :

• Pencapaian kualitas : tidak terjadi karena kebetulan, harus direncanakan sejak awal dan dimonitor setiap hari
• Tiga prinsip dasar :
  • Mengetahui apa yang sebaiknya dilakukan
  • Apa yang sedang dilakukan
  • Bagaimana mengukur perbedaan

Dukungan kualitas meliputi :

• Dokumentasi user
• Package dan penyusunan distribusi
• Training
• Help desk assistance
• Error reporting and correction
• Perbaikan