Materi Ujian RPL

-->
MATERI 1: PERANCANGAN PERANGKAT LUNAK
1.    Tahapan Rancangan Perangkat Lunak
}  Pendekatan rancangan perangkat lunak
◦      Rancangan perangkat lunak terstruktur
◦      Rancangan perangkat lunak berorientasi objek
}  Tahap rancangan perangkat lunak :

2.    Alat perancangan perangkat lunak terstuktur
}  Kamus data
}  Model data logik
}  ERD
}  DFD
3.    Karakteristik rancangan untuk program terstruktur
}  Modul disusun secara hirarkis (bagan struktur,diagram jackson,diagram warnierorr)
}  Menggunakan Logika CALL-based atau PERFORM-based
}  Menggunakan control flow dan rancangan top-to-bottom dan pengkodean top-to-bottom atau bottom-to-top
}  Merancang repetisi atau loop
}  Menerapkan konsepsi kendali standar untuk urutan
4.    Tahapan Perancangan
}  Perancangan Data
}  Perancangan Arsitektural
}  Perancangan Antarmuka
}  Perancangan Prosedural
5.    Perancangan Data
}  Memilih representasi lojik dari objek data yang ditemukan pada proses analisis
}  Refinement terhadap Data Dictionary menjadi:
◦      struktur data (array, list, dll.)
◦      struktur file / basis data lengkap dengan fieldnya
}  Penentuan struktur data maupun struktur file /basis data membutuhkan kreativitas dan sistematika yang rapi agar tidak menyulitkan proses berikutnya, khususnya perancangan prosedur.
}  Petunjuk teknis perancangan data:
◦      menerapkan prinsip-prinsip analisis sistematis (pada tahap analisis)
◦      mengidentifikasi semua struktur data dan prosedur yang akan digunakan untuk mengakses data tsb
◦      me-refine isi data dictionary
}  menunda perancangan data yang ‘low-level’sampai di akhir-akhir proses perancangan
}  merepresentasikan struktur data sedemikian rupa sehingga hanya modul yang menggunakan data tersebut yang dapat mengaksesnya
}  membangun pustaka untuk struktur data dan prosedur yang sering digunakan
}  Hasil perancangan data adalah:
◦      struktur data siap diprogram
◦      struktur basis data siap dibuat oleh pemrogram
◦      prosedur/operasi untuk mengakses data, siap diprogram
6.    Perancangan Arsitektural
}  Objektif utama:
◦      membangun struktur program modular dan merepresentasikan keterkaitan kendali antar modul; dan
◦      memadukan struktur program dan struktur data, dan mendefinisikan antarmuka yang memungkinkan data dapat mengalir pada seluruh program.
}  Proses:
◦      pengubahan dari aliran informasi (direpresentasikan dengan DFD) menjadi struktur PL (direpresentasikan dengan Structure Chart).
}  Langkah:
◦      (1) menentukan jenis aliran informasi
◦      (2) menentukan batas aliran informasi
◦      (3) pemetaan dari DFD ke struktur program
◦      (4) menentukan hierarki kendali dengan cara faktorisasi
◦      (5) menghaluskan struktur program yang terbentuk, dengan mempertimbangkan faktor-faktor pengukuran PL dan heuristik.
}  Jenis aliran informasi:
}  (1) aliran transformasional

 }   (2) aliran transaksional

 








}  Langkah Pemetaan (untuk jenis aliran transformasional):
◦      kaji ulang model sistem dasarnya
◦      kaji ulang dan perhalus DFD-nya
◦      tentukan apakah DFD memiliki jenis aliran transformasional dan atau aliran transaksional
◦      isolasi pusat transaksi dengan menentukan batas aliran incoming dan outgoing
◦      lakukan faktorisasi level satu
◦      lakukan faktorisasi level dua
◦      perhalus struktur program yang diperoleh dari iterasi tahap pertama ini dengan heuristik.
}  Langkah Pemetaan (untuk jenis aliran transaksional):
◦      kaji ulang model sistem dasarnya
◦      kaji ulang dan perhalus DFD-nya
◦      tentukan apakah DFD memiliki jenis aliran transformasional dan atau aliran transaksional
◦      tentukan pusat transaksi dan jenis aliran di sepanjang setiap jalur aksi (action paths)
◦      petakan DFD ke dalam struktur program sesuai proses transaksinya
◦      faktorisasi dan perhalus struktur transaksi dan juga struktur di setiap jalur aksi
◦      perhalus struktur program yang diperoleh dari iterasi tahap pertama ini dengan heuristik.








Perancangan Arsitektural

Perancangan Arsitektural
}  Optimasi rancangan arsitektural
◦      kesederhanaan struktur seringkali mencerminkan keindahan dan efisiensi PL
◦      optimasi rancangan harus diarahkan pada sesedikit mungkin modul yang terbentuk (dengan tetap mempertimbangkan kriteria perancangan modular efektif) dan sesedikit mungkin struktur data yang rumit/kompleks
}  Hasil perancangan arsitektural:
◦      Structure Chart yang merepresentasikan gambaran menyeluruh struktur PL / arsitektur PL, beserta seluruh hierarki kendali / passing parameter, yang siap dituliskan dalam bentuk modul program
Perancangan Antarmuka
}  Fokus perancangan antarmuka:
◦      antarmuka antar modul-modul PL
◦      antarmuka antara PL dengan sumber informasi, selain manusia (external entities)
◦      antarmuka antara manusia (user) dengan komputernya
}  Jenis antarmuka yang diperlukan adalah:
◦      antarmuka untuk input parameter process → layar
◦      antarmuka untuk output proses → layar
◦      antarmuka untuk input data → layar maupun parameter passing
◦      antarmuka untuk output data → layar maupun parameter passing
◦      antarmuka untuk pesan-pesan → layar
}  Hal-hal yang perlu diperhatikan dalam merancang antarmuka di layar:
◦      harus konsisten (warna, font, bahasa, dll)
◦      memberikan umpan balik ke pengguna
◦      meminta verifikasi untuk semua aksi destruktif penting
◦      memungkinkan aksi reversal
◦      mengurangi jumlah infomasi yang harus diingat antar aksi
◦      efisiensi dialog, gerak, dan pikiran pengguna (dekomposisi, nilai default, layout)
◦      mengelompokkan aktivitas berdasarkan fungsi & mengatur layar sesuai dengan pengelompokkan tersebut
◦      sediakan bantuan (help) yag context sensitve
◦      tampilkan info yang sesuai dengan konteks
}  perhatikan presentasi data:
◦      sedikit: form/tabel
◦      banyak: graph/chart
◦      pelihara konteks visual
◦      pesan kesalahan harus berarti
◦      gunakan analog display untuk hal yang sesuai, misalnya bar chart
◦      minimalkan jumlah aksi masukan yang diperlukan
◦      sesuaikan dengan kebutuhan/kebiasaan user, misalnya:
–  clerk - keyboard, manager - mouse
–  clerk - input, decision makers - update/delete
}  Perancangan antarmuka dapat dilakukan secara:
◦      manual, dilakukan pada kertas
◦      bantuan alat bantu, alat bantu pemrograman atau dengan CASE tools (misalnya dengan AppModeller pada Power Designer)
}   Hasil perancangan antarmuka adalah:
◦      definisi antarmuka modul yang siap untuk diprogram
◦      definisi / format rancangan layar yang siap diimplementasikan
Perancangan Prosedural
}  Tahapan terakhir pada proses perancangan
◦      Membentuk algoritma siap program dengan menggunakan dan mengacu pada:
◦      struktur data yang terbentuk pada perancangan data
◦      struktur modul dan kendali PL yang terbentuk pada Structure Chart yang diperoleh pada saat perancangan arsitektural
◦      struktur dan rancangan menu / format tampilan layar yang diperoleh pada perancangan antarmuka
}  Pada intinya perancangan prosedural harus memperhatikan dua hal utama yaitu:
◦      coupling (a measure of the interdependence among software module), yaitu ukuran kekuatan saling kebergantungan antar modul-modul software
◦      cohesion (a measure of the relative functional strength of a module), yaitu ukuran kekuatan modul-modul perangkat lunak secara fungsional relatif terhadap modul perangkat lunak itu sendiri
}  Untuk merancang prosedur/modul alat bantu yang dapat digunakan adalah:
◦      flow-chart
◦      algoritma/pseudocode/program design language
}  Alat bantu tersebut dapat dicapai secara:
◦       manual, dilakukan pada kertas atau pada text editor/shape editor
◦      dengan alat bantu menggunakan CASE tools misalnya PSpec pada Process Analyst (Power Designer)
Hasil Proses Perancangan
}  Hasil proses perancangan perangkat lunak dinyatakan dengan sebuah  dokumen yang diberi nama: Software Design Description (SDD).
◦      Isi SDD adalah paparan sistem yang umumnya disusun berdasarkan:
◦      tujuan
◦      tuntutan umum (general requirement)
◦      batasan
◦      asumsi
◦      Rancangan data
–  basis data
–  external file
◦      Rancangan arsitektural, yaitu faktorisasi modul & deskripsinya
◦      Rancangan antarmuka
◦      Rancangan prosedural
}  SDD menjadi patokan dalam melakukan pemrograman agar modulmodul yang dihasilkan terarah dan dapat dipertanggungjawabkan
Rancangan Perangkat Lunak Berorientasi Obyek
}  Adalah Strategi perancangan dimana perancang sistem memikirkan ‘benda’ dan bukan operasi atau fungsi.
}  Terdiri dari : Objek dan kelas objek
}  Objek
◦      Memberi identitas kepada orang atau benda
◦      Merepresentasikan entitas dari aplikasi yang dirancang
}  Kelas Objek
◦      Dibuat untuk menurut definisi kelas objek
◦       Definisi kelas objek berfungsi sebagai template untuk membuat objek
}  Kelas Objek
◦      Superkelas : kumpulan kelas
◦      Subkelas : kejadian dari suatu kelas
◦      Inheritance : kemampuan untuk mendefinisikan subkelas objek dari suatu kelas objek
Representasi alternatif dari kelas berorientasi objek
}  Kelas objek-> persegi panjang
}  Atribut objek ->bagian atas
}   Operasi /metode/servis ->bagian bawah
}  Pesan
}  Memodel pewarisan
◦      Satu dari pembeda kunci di antara sistem OO dan konvensional
Penelusuran rancangan perangkat lunak(software design walkthrough)
}  Derajat formalitas atau struktur dari penelusuran
}  Pengaturan waktu -> Selama SDLC atau SWDLC
Hirarki kelas

 Tahapan perancangan berorientasi objek
}  Mendefinisikan Konteks sistem dan model penggunaan
}  Merancang arsitektur sistem
}  Mengidentifikasi obyek utama sistem
}  Mengembangkan model desain
}  Menspesifikasi interface obyek
MATERI 2 : PENGUKURAN PERANGKAT LUNAK
Introduksi
n  Masuknya produk perangkat lunak dari luar negeri dapat di lihat dari 2 sisi :
n   Menguntungkan : Banyak pilihan produk dan harga
n  Mengkhawatirkan : Di Indonesia tidak ada institusi yg secara aktif membuat standard dalam pengukuran kualitas perangkat lunak.
n  Demikian juga dengan produk-produk perangkat lunak lokal, tentu akan semakin meningkat daya saing internasionalnya apabila pengembang dan software house di Indonesia mulai memperhatikan masalah kualitas perangkat lunak ini.
n  Lord Kelvin berkata :
n  Bila Anda dapat mengukur apa yg sedang Anda bicarakan dan mengekspresikannya dalam angka, berarti Anda memahaminya.
n  Kualitas perangkat lunak (software quality) adalah tema kajian  turun temurun
n  Kajian dimulai dari apa yang akan diukur (apakah proses atau produk), apakah memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter pengukuran kualitas perangkat lunak.
n  Tujuannya -> Software Baik
n  Tujuan pengukuran perangkat lunak adalah
n  Untuk menyatakan kualitas produk
n  Untuk menilai kulitas manusia yg terlibat dalam pembuatan produk.
n  Untuk menilai keuntungan pemakaian metode & alat bantu yg baru.
n  Sebagai dasar untuk melakukan perkiraan.
n  Untuk membantu penyesuaian pemakaian alat bantu yg baru atau pelatihan tambahan.
Pengukuran, Metrik, Dan Indikator
n  Measure (mengukur) :
n  Mengindikasikan kuantitatif dari luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut sebuah proses atau produk.
n  Measurement (pengukuran) :
n  Kegiatan menentukan sebuah measure (pengukuran)
n  Metrics (metrik) :
n  Ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen, atau proses memiliki atribut tertentu.
n  Kenapa kita melakukan pengukuran ?
n  Untuk melihat karakteristik sesuatu objek
n  Untuk mengevaluasi dari objek
n  Untuk memprediksi objek
n  Untuk mengimprovisasi objek tersebut terhadap perkembangan dan pengembangannya.
n  RPL  pengukuran & mengembangkan metrik sehingga diperolehsuatu indicator.
Pengukuran dilakukan melalui 2 tahapan
n  Pengaruh internal terhadap pengukuran :
n  Proses
n  Produk
n  Pengaruh eksternal terhadap pengukuran :
n  Proses Metrik
n  Proyek Metrik
n  Produk Metrik
Proses Metrik
n  Memungkinkan sebuah organisasi rekayasa perangkat lunak memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung”.
n  Proses ini dikumpulkan di seluruh proyek dan pada perkembangan proses perangkat lunak jangka panjang

Proyek Metrik
n  Memperkirakan status sebuah proyek yang sedang berlangsung
n  Menelusuri resiko-resiko potensial
n  Menemukan masalah sebelum masalah menjadi semakin kritis
n  Menyesuaikan aliran kerja dan tugas
n  Mengevaluasi kemampuan tim proyek (mengontrol kualitas kerja)
Produk Metrik
n  Memperhatikan kualitas yang akan diberikan
n  Mengukur dari hasil analisa model
n  Kompleksitas Design (Internal Algoritma, Arsitektur, Aliran Data)
n  Mengukur Kode
n  Mengukur efektifitas proses
Etika Metrik Perangkat Lunak
  1. Gunakan istilah umum dan kepekaan organisasi ketika menginterpretasi data metrik
  2. Berikan umpan balik reguler kepada individu dan tim yang telah bekerja untuk mengumpulkan pengukuran dan metrik
  3. Jangan menggunakan metrik untuk mengukur individu
  4. Jangan menggunakan metrik untuk mengancam individu dan tim
  5. Bekerja dengan pelaksana dan tim untuk menentukan tujuan dan metrik yang jelas yang akan digunakan
  6. Data-data yang didapat hanya sebagai indikator bagi peningkatan proses
  7. Tetap memperhatikan metrik yang lain dalam melakukan pengukuran.
NORMALISASI UNTUK METRIK
n  Normalisasi data digunakan untuk mengevaluasi proses dan produk
n  Ada 2 Teknik :
1.      Size Oriented Normalization : Pendekatan pada Baris kode
2.      Function Oriented Normalization : Pendekatan pada Fungsi Point
PENGUKURAN PERANGKAT LUNAK
  1. Metrics Size Oriented
n  Diukur dengan normalisasi kualitas dan atau pengukuran produktifitas mempertimbangkan ukuran perangkat lunak yang dihasilkan.
n  Pengembangan Metrics Size Oriented :
a.       Kesalahan per KLOC (Kilo Line Of Code)
b.      Biaya per LOC
c.       Cacat per LOC
d.      Halaman Dokumentasi per LOC
n  Metrik lain yang dapat dihitung
a.       Kesalahan perorang perbulan
b.      LOC perorang perbulan
c.       Biaya perhalaman dokumentasi
  1. Metrik Function Oriented
n  Diukur dengan menggunakan sebuah pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi.
n  Typical Function-Oiented Metrics
a.       Kesalahan per FP (Function Point)
b.      Cacat per FP
c.       Biaya per FP
d.      Halaman Dokumentasi per FP
e.       FP perorang perbulan.
n  Function Point ditentukan berdasarkan bagian-bagian software yang sedang dihitung seperti :
a.       Jumlah input dari pengguna
b.      Jumlah output untuk pengguna
c.       Jumlah user inquiry
d.      Jumlah external interface




  1. Metrik Function Point yang Diperluas
n  Secara Orisinil dirancang untuk diterapkan pada aplikasi informasi bisnis yang ditekankan pada pengeluaran dimensi tingkah laku dan fungsional.
n  Feature Points à Teknik pengukuran function point yang diterapkan
n  Fp à Mengakomodasi aplikasi yang kompleksitas algoritmanya tinggi (Real Time, Kontrol Proses, Karakteristik perangkat lunak yang baru/Algoritma, dll)
MENGUKUR KUALITAS
  1. Correctness. Program harus beroperasi dengan benar, dimana perangkat lunak melakukan fungsi yang ditentukan.
  2. Maintainability. Pemeliharaan memberikan kemudahan pada aktifitas dan perbaikan terhadap kesalahan sistem.
  3. Integrity. Mengukur kemampuan sistem untuk menahan serangan terhadap keamanannya.
  4. Usability à User Friendly

MATERI 3 : Metrik untuk Kualitas Perangkat Lunak
Pendahuluan
l  Tujuan rekayasa perangkat lunak adalah untuk menghasilkan sistem, aplikasi atau produk berkualitas tinggi.
l  Kualitas sistem, aplikasi atau produk merupakan persyaratan yang menjelaskan masalah, desain model solusi, kode yang dapat membuat program dapat dieksekusi,dan pengujian yang menguji perangkat lunak untuk menemukan kesalahan.
l  Perangkat lunak yang baik menggunakan pengukuran untuk menilai kualitas model analisis dan desain, kode sumber yang dibuat ketika perangkat lunak direkayasa.
l  Pengukuran digunakan untuk memperkirakan kualitas produk yang direkayasa atau sistem yang kita bangun.
Definisi Metrik
l  Merupakan suatu standar pengukuran dan digunakan untuk evaluasi tingkat kualitas yang dicapai
Definisi Kualitas
l  Kesesuaian dengan pelanggan
l  Memenuhi kriteria yang ditetapkan oleh pelanggan, bukan oleh produsen
l  Kualitas perangkat lunak yang tepat waktu sesuai dengan anggaran dan memenuhi keinginan pemakai
Mengukur Kualitas
l  Cara yang benar
Program harus beroperasi dengan benar atau program tersebut dapat memberikan nilai bagi para pemakainya
l  Maintainabilitas
Kemudahan dimana program dapat dikoreksi jika ditemukan kesalahan, diadaptasi jika lingkungannya berubah atau pelanggan menginginkan perubahan kebutuhan.
l  Integritas
Digunakan untuk mengukur kemampuan sistem untuk menahan serangan terhadap sekuritasnya.
l  Usabilitas
Digunakan untuk mengukur user friendly
Kualitas Perangkat Lunak
l  Performance (kinerja)
l  Perangkat lunak mempunyai kualitas yang baik jika dapat melakukan sesuai dengan standar yang ditetapkan
l  Feature
l  Fungsi-fungsi tambahan untuk melengkapi atau meningkatkan fungsi dasar tersebut.
l  Realibility
l  Kemampuan produk untuk berfungsi secara benar selama masa penggunaan yang telah ditentukan
l  Conformance (kesesuaian)
l  Sejauh mana kesesuaian produk tersebut dengan standar     yang ditetapkan oleh customer atau standar-standar acuan lain.
l  Durability (daya tahan)
l  Ukuran umur produk yang digunakan pada situasi,dan kondisi yang dipersyaratkan.
l  Serviceability
l  Produk yang dirancang agar mudah diperbaiki dapat meningkatkan nilai produk tersebut
Tahapan-tahapan kualitas
l  Identifikasi Pelanggan
l  Identifikasi siapa customernya
l  Lakukan komunikasi yang baik antara customer dengan produsen
l  Defenisikan kebutuhan pelanggan
 l  Rancang perangkat lunak sesuai dengan keinginan pelanggan dengan metode wawancara
l  Tetapkan qualitas metrik
l  Tentukan standar pengukuran yang digunakan untuk mencapai tingkat kualitas yang baik
l  Definisikan strategi kualitas perangkat lunak
l  Feature yang diinginkan pelanggan
l  User interface yang diinginkan
l  Uji perangkat lunak yang telah dibuat
l  Terapkan program-program kualitas perangkat lunak
l  Implementasikan program yang telah dikembangkan dan untuk melihat hasilnya diperlukan waktu
l  Pantau kinerja kualitas perangkat lunak         
l  Adanya input dari pemakai
Trilogi Kualitas
l  Perencanaan Kualitas (Quality Planning)      
l  1. Identifikasi siapa customer
l  2. Tentukan kebutuhan atau keinginan customer
l  3. Buat feature produk / perangkat lunak untuk memenuhi keinginan customer
l  4. Tetapkan sasaran kualitas seperti yang diinginkan  customer
l  Pengendalian
l  1. Tetapkan cara pengukuran
l  2. Tetapkan standar kinerja
l  Perbaikan
l  1. Buktikan perlu adanya perbaikan
l  2. Formulasikan cara-cara mengidentifikasi dan    menyelesaikan masalah yang ditemukan
l  3. Lakukan pengujian kembali perangkat lunak yang telah diperbaiki
Faktor Kualitas
l  Faktor yang mempengaruhi kualitas perangkat lunak dikategorikan dua kelompok besar yaitu :
l  Faktor yang dapat secara langsung diukur (cacat per function point)
l  Faktor yang dapat diukur secara tidak langsung (usabilitas dan maintainabilitas)
l  Kebenaran
Tingkat dimana program memenuhi spesifikasinya dan memenuhi sasaran misi pelanggan
l  Reliabilitas
Tingkat dimana sebuah program dapat diharapkan melakukan fungsi yang diharapkan dengan ketelitian yang diminta
l  Efisensi
Jumlah sumber daya penghitungan dan kode yang diperlukan oleh program untuk melakukan fungsinya
l  Integritas
Akses keperangkat lunak oleh orang yang tidak berhak dapat dikontrol
l  Usabilitas
Usaha untuk mempelajari, mengoperasikan, menyiapkan input, dan menginterpretasikan output suatu program
l  Maintainabilitas
Usaha yang diperlukan untuk mencari dan membetulkan kesalahan pada sebuah progra
l  Fleksibilitas
Usaha yang diperlukan untuk memodifikasi program operasional
l  Testabilitas
Usaha yang diperlukan untuk menguji sebuah program untuk memastikan apakah program melakukan fungsi-fungsi yang dimaksudkan
l  Portabilitas
Usaha untuk memindahkan program dari satu perangkat keras atau lingkungan sistem perangkat lunak ke yang lainnya
l  Reusabilitas
Tingkat dimana suatu program dapat digunakan kembali didalam aplikasi yang lain
l  Interoperabilitas
Usaha yang diperlukan untuk merangkai satu sistem dengan yang lainnya


Kerugian Kualitas Buruk
l  Lost bussines (Kehilangan Bisnis)
l  Liability judgment (Tuntutan Hukum)
l  Kehilangan produktifitas
l  Cost (Biaya)
Penutup
l  Persyaratan perangkat lunak adalah dasar dimana kualitas diukur. Kurangnya penyesuaian ke persyaratan berarti kurangnya kualitas
l  Standar yang spesifikasi menentukan serangkaian kriteria pengembangan dimana perangkat lunak direkayasa
l  Ada serangkaian persyaratan implisit yang sering tidak dicantumkan (ex : keinginan akan maintainabilitas yang bagus). Bila perangkat lunak tidak sesuai dengan standar yang telah ditetapkan, maka kualitas perangkat lunak patut diragukan.

MATERI 4 :
JAMINAN KUALITAS PERANGKAT LUNAK (Software Quality Assurance )
Pendahuluan
n  Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak.
n  SQA meliputi :
1.      pendekatan manajemen kualitas
2.      teknologi rekayasa perangkat lunak yang efektif (metode dan peranti)
3.      kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak
4.      strategi pengujian multitiered (deret bertingkat)
5.      kontrol dokumentasi perangkat lunak dan perubahan
6.      prosedur untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak
7.      mekanisme pengukuran dan pelaporan.
Kontrol Kualitas
n  Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan
n  Tujuannya untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan.
n  Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan output dari setiap proses.
n  Kalang (loop) menjadi penting untuk meminimalkan cacat yang dihasilkan.
n  Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen.
n  Tujuan jaminan kualitas adalah :
n  untuk memberikan data yang diperlukan oleh manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian & konfidensi bahwa kulitas produk dapat memenuhi sasaran.
Biaya Kualitas
n  Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas.
n  Studi tentang biaya kualitas dilakukan untuk memberikan garis dasar bagi biaya kualitas yang sedang digunakan, untuk mengidentifikasi kemungkinan pengurangan biaya kualitas serta memberikan basis perbandingan yang ternormalisasi.
n  Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan :
n  Pencegahan
n  Penilaian
n  kegagalan.
n  Biaya pencegahan meliputi :
n  Perencanaan
n  Kajian teknis formal
n  Perlengkapan pengujian
n  Pelatihan
n  Biaya penilaian meliputi :
n  Inspeksi in-proses dan interproses
n  Pemeliharaan dan kalibrasi peralatan
n  Pengujian
n  Biaya kegagalan
n  Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul sebelum produk disampaikan kepada pelanggan.
n  Biaya kegagalan internal adalah biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan, meliputi: Pengerjaan kembali, Perbaikan, Analisis mode kegagalan
n  Biaya kegagalan eksternal adalah biaya yang berhubungan dengan cacat yang ditemukan setelah produk disampaikan kepada pelanggan.
n  Biaya kegagalan eksternal meliputi: Resolusi keluhan ,  Penggantian dan pengembalian produk, Dukungan help line, Kerja jaminan
DEFINISI KUALITAS PL
n  Kualitas perangkat lunak didefinisikan sebagai:
àKonformansi terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak dikembangkan secara profesional.
n  Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu:
q  Kebutuhan perangkat lunak merupakan fondasi yang melaluinya kualitas diukur.
q  Standar yang telah ditentukan menetapkan serangkaian kriteria pengembangan yang menuntun cara perangkat lunak direkayasa.
q  Ada serangkaian kebutuhan implisit yang sering dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik).
n  Kelompok SQA berfungsi sebagai perwakilan in-house pelanggan, yaitu orang yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan.
q  Apakah perangkat lunak cukup memenuhi faktor kualitas
q  Sudahkah pengembangan perangkat lunak dilakukan sesuai dengan standar yang telah ditetapkan sebelumnya?
q  Sudahkah disiplin teknik dengan tepat memainkan perannya sebagi bagian dari aktivitas SQA?
AKTIVITAS SQA
n  Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda :
q  perekayasa perangkat lunak yang mengerjakan kerja teknis
q  kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan.
KAJIAN PERANGKAT LUNAK
n  Kajian perangkat lunak merupakan salah satu aktivitas SQA yang terpenting.
n  Kajian perangkat lunak adalah suatu filter bagi proses rekayasa perangkat lunak, yaitu kajian yg diterapkan pd berbagai titik selama pengembangan PL & berfungsi untuk mencari kesalahan yg kemudian akan dihilangkan.
n  Kajian perangkat lunak berfungsi untuk “memurnikan” produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain, dan pengkodean.
KAJIAN TEKNIK FORMAL  (Formal Technic Review – FTR)
n  FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak.
n  Kajian teknik formal atau walktrough adalah pertemuan kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk menemukan kesalahan.
n  Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak.
n  Tujuan FTR adalah
n  Menemukan kesalahan dlm fungsi, logika, / implementasinya dlm berbagai representasi PL;
n  Membuktikan bahwa perangkat lunak di bawah kajian memenuhi syarat;
n  Memastikan bahwa PL disajikan  sesuai dgn  standar yg sudah ditentukan sebelumnya;
n  Mencapai perangkat lunak yg dikembangkan dengan cara yang seragam;
n  Membuat proyek lebih dapat dikelola.
n  FTR berfungsi
àdasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang berbeda terhadap analisis perangkat lunak, desain, dan implementasi.
àmengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak yang tidak mereka ketahui sebelumnya.
n  FTR berfungsi
àdasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang berbeda terhadap analisis perangkat lunak, desain, dan implementasi.
àmengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak yang tidak mereka ketahui sebelumnya.
PERTEMUAN KAJIAN
n  Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan ....(ada 3) à kemudian ambil keputusan
n  Setelah pertemuan kajian akan dilakukan
q  Pelaporan Kajian & Penyimpanan Rekaman
n  Apa yang dikaji ?
n  Siapa yang melakukan?
n  penemuan apa yang dihasilkan dan apa kesimpulannya?
q  Adanya Pedoman Kajian
PENDEKATAN FORMAL TERHADAP SQA
n  Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar pengembangan perangkat lunak yang diterima


Materi Ujian TTS
Soal Tugas 1
1.      Jelaskan apa yang dimaksud dengan software tidak pernah usang?
2.      Ukuran Kualitas software diantaranya Usabilitas (mudah digunakan), jelaskan?
3.      Jelaskan secara lengkap model software yang anda ketahui?
4.      Sebutkan dan jelaskan orang-orang yang terlibat dalam pengembangan Perangkat Lunak?
5.      Menurut anda apa yang dimaksud kualitas pada perangkat lunak?
Jawaban
1.       Perangkat lunak dikatakan tidak pernah usang karena perangkat lunak tersebut selalu update(diperbarui) agar selalu sesuai dengan kebutuhan pengguna sehingga pengguna tetap menggunakan perangkat lunak tersebut.
2.      Karena pada penggunaan software/ PL tersebut memiliki tools atau interface yang mudah dipahami oleh user begitupun software yang disediakan memiliki ukuran yang rendah dan menambah kenyaman dalam pemakaiannya bahkan dengan desain yang unik sehingga menarik perhatian para user yang mencobanya.
3.      Model incremental (Incremental waterfall model) merupakan perbaikan dari model waterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini adalah membangun software secara meningkat (increment) berdasarkan kemampuan fungsional.Model incremental ini diaplikasikan pada sistem pakar dengan penambahan rules yang mengakibatkan bertambahnya kemampuan fungsional sistem. Model incremental merupakan model continous rapid prototype dengan durasi yang diperpanjang hingga akhir proses pengembangan.
 
 4. Orang yg terlibat dalam proyek perangkat lunak, diantaranya :
a.       manajer senior : yang menentukan usaha yang dikerjakan, dan pemegang keputusan dalam proyek.
b.      manajer proyek (teknis)– pemimpin tim: yang membuat rencana, memotivasi, mengatur dan mengendalikan praktisi yang mengerjakan PL.
c.       praktisi : yang mengerjakan Perangkat Lunak.
d.      klien : yang menentukan kebutuhan Perangkat Lunak dan pihak lain yang berkaitan dengan hasil produk
e.       pengguna PL : yang berinteraksi langsung dengan Perangkat Lunak yang dibangun.
5.   Kualitas perangkat lunak yaitu suatu pengukuran tentang baik dan buruknya suatu software yang dibuat dan pemakaian yang efektif dan efisien bagi user sehingga merasa puas dan nyaman dalam menggunakan software tersebut.
Materi 1 Pendahuluan
Evolusi Software  
 Tahun-tahun awal (1)
  • Orientasi Batch
  • Dstribusi terbatas
  • Custom software   
            The Second era (2)
  • Multi User
  • Realtime
  • Database
  • Software produk 
     Era ketiga (3)
  • System terdistribusi
  • Embeded Intelligent
  • Low Cost Hardware
  Era keempat(4)
  • Powerful desktop system
  • Object Oriented Technologies
  • Expert systems
  • Artificial Neural Network
  • Parallel Computing
  • Network Computer
SOFTWARE
Software adalah:
  • Instruksi (Program komputer) yang pada saat dieksekusi menghasilkan fungsi dan unjuk kerja yang dikehendaki.
  • Struktur data yang memungkinkan program untuk memanipulasi informasi secukupnya.
  • Dokumen yang menjelaskan operasional dan penggunaan program.
          Karakteristik software:
  • Software dikembangkan atau direkayasa, bukan dipabrikasi dengan cara klasik.
  • Software tidak bisa wear-out (tidak pernah usang).
  • Kebanyakan software adalah  “Custom-built diassembly “ , serta tidak dapat dirakit berdasar komponen-komponen yang sudah ada.
Menurut McCall yang dikutip oleh Roger Pressman dalam bukunya
Rekayasa Perangkat Lunak (2002 : 611) mengusulkan kategori yang berguna mengenai faktor – faktor yang mempengaruhi perangkat lunak. Berfokus pada 3 hal penting produk perangkat lunak karakteristik operasional, kemampuannya untuk beradaptasi dengan lingkungan yang baru. Faktor – faktor kualitas perangkat lunak McCall terdiri dari :
1. Kebenaran adalah tingkat dimana program memenuhi spesifikasinya dan memenuhi sasaran misi karyawan.
2. Reliabilitas adalah tingkat dimana sebuah program dapat diharapkan melakukan fungsi yang diharapkan dengan ketelitian yang diminta.
3. Efisiensi adalah jumlah sumber daya penghitungan kode yang diperlukan oleh program untuk melakukan fungsinya.
4. Integritas adalah tingkat dimana akses ke perangkat lunak atau data oleh orang yang tidak berhak dapat di kontrol.
5. Usabilitas adalah usaha yang dibutuhkan untuk mempelajari, mengoperasikan, menyiapkan input, dan mengintrepretasikan output suatu program.
6. Maintanabilitas adalah usaha yang diperlukan untuk mencari dan membetulkan kesalahan pada sebuah program.
7. Flexibilitas adalah usaha yang diperlukan untuk memodifikasi program operasional.
8. Testabilitas adalah usaha yang diperlukan untuk menguji sebuah program untuk memastikan apakah program melakukan fungsi – fungsi yang dimaksudkan.
9. Portabilitas adalah usaha yang diperlukan untuk memindahkan program dari satu perangkat keras dan atau lingkungan.
10. Reusabilitas adalah tingkat dimana sebuah program ( bagian dari suatu program ) dapat digunakan kembali di dalam aplikasi lain.
11. Interperabilitas adalah usaha yang diperlukan untuk merangkai satu system dengan yang lainnya.

Aplikasi Software
System Software
1.      Sekumpulan program yang dibuat untuk melayani program lainnya.
2.      Misal: compiler, editor dan program manajemen utilities.
Real Time Software Program yang memonitor atau menganalisa atau mengontrol aktifitas sehari-hari.
3.      Elemen dari Real Time Software:
a.       Komponen pengumpulan data, yang mengumpulkan dan menformat informasi dari lingkungan ekternal.
b.      Komponen analisa, yang mentransformasikan informasi yang diperlukan atau aplikasi tersebut.
c.       Komponen kontrol/output, yang memberikan respon terhadap lingkungan eksternal.
d.      Komponen monitoring, yang mengkoordinasi komponen-komponen lainnya sehingga bisa memberikan respon yang Real Time (biasanya antara 1 milidetik/1 menit).
4.      Business SoftwareSoftware MIS yang mengakses satu atau beberapa database yang berisi informasi bisnis.
5.      Enginering and Scientific Software
6.      Batasan aplikasinya mulai dari astronomi sampai vulkanologi, dari otomotif sampai pesawat ruang angkasa, dari molekul biologi sampai automated manufacturing.
7.      Embeded SoftwareBiasanya diletakkan pada read only memory dan digunakan untuk mengontrol produk dan sistem untuk pelanggan dan pasar industri. Misal: key pad untuk mengontrol microwave oven.
8.      Personal Computer Software
9.      Misal: Wordprocessing, spreadsheet, computer graphic, multimedia, entertaintment, database management, personal and business financial application, akses database atau jaringan external, dan lain-lain.
10.  Artificial Intelligent Software Software yang menggunakan algoritma non numerik untuk menyelesaikan permasalahan yang komplek. Areal AI yang aktif dikenal dengan expert system atau knowledge based system. Cabang baru dari AI adalah Artificial Network.
Proses
  1. RPL merupakan teknologi layer
  2. Menurut IEEE, RPL adalah :
  3. Aplikasi yang pendekatannya sistematis, disiplin, bisa terukur untuk pengembangan operasional dan    pembuatan software.
  4. Pondasi RPL adalah lapisan proses, karena terkait dengan teknologi dan waktu pengembangan.
  5. Proses mendefinisikan framework key prosess Are (KPA) yang harus dibuat untuk penekanan teknologi RPL yang efektif.
  6. Metode RPL memberikan teknik bagaimana membangun software.  Yang termasuk metode: Analisa, desain, pembuatan program, pengujian dan perawatan.
  7. Tool pad RPL digunakan untuk memberikan dukungan otomatisasi atau semi otomatis pada proses dan metode. Sistem yang biasa digunakan untuk mendukung  pengembangan disebut Computer Aided Software Enginering (CASE). CASE mengkombinasikan software, hardware dan database RPL (berisi informasi mengenai analisa, desain, pembuatan program dan pengujian).

Hal-hal Umum RPL
  1. Rekayasa adalah analisa, desain, pembuatan, verifikasi dan manajemen teknis (atau sosial). Tanpa memandang entitas yang harus direkayasa, ada beberapa pertanyaan yang harus dijawab:
a.       Problem apa yang harus dicarikan solusinya ?
b.      Apa saja karakteristik entitas yang digunakan untuk menyelesaikan persoalan tersebut.
c.       Bagaimana entitas (dan solusinya) dapat direalisasikan ?
d.      Bagaimana entitas akan dibangun ?
e.       Pendekatan apa yang akan digunakan untuk mencegah terjadinya kesalahan desain dan pembuatan entitas?
f.       Bagaimana entitas akan didukung selama mungkin, pada saat ada permintaan koreksi, adaptasi dan    pengembangan oleh user.
  1. Pekerjaan yang berhubungan dengan RPL bisa dikategorikan ke dalam 3 fase umum tanpa memandang area aplikasi, ukuran proyek atau kompleksitas. Fase tersebut yaitu:
    1. Definition Phase
    2. Development Phase
    3. Maintenance Phase
  1. Definition Phase
Selama fase ini, software developer berusaha untuk mengidentifikasi informasi apa saja yang harus diproses,    apa saja fungsi dan kinerja yang digunakan, tingkah laku sistem yang diharapkan, apa saja interface yang harus dibuat, apa saja kendala desain yang ada, dan kriteria validasi yang diperlukan untuk mendefinisikan kesuksesan sistem.
  1. Development Phase
Selama fase ini, software developer berusaha untuk mendefinisikan bagaimana data disusun, bagaimana fungsi bisa diimplementasikan sesuai dengan arsitektur software, bagaimana prosedur detil untuk implemetasi , bagaimana karakter interface, bagaimana hasil desain bisa ditranslasikan ke bahasa pemrograman dan bagaimana cara pengujiannya
  1. Ada tiga aktivftas teknis yang selalu terjadi:
    1. Desain software
    2. Pembuatan Program
    3. Pengujian Software
  2. Maintenance Phase
Difokuskan pada perubahan sehubungan dengan adanya koreksi kesalahan, adaptasi dan pengembangan yang dikehendaki customer.
  1.  Ada 4 tipe perubahan:
    1. Correction Mengubah software untuk memperbaiki kesalahan-kesalahan yang ada.
    2. Adaption Modifikasi yang dilakukan terhadap software dikarenakan adanya perubahan lingkungan eksternal (misal: CPU, sistem operasi, aturan bisnis, karakter produk eksternal).
    3. Enhancemen Pada saat sofrware dipakai, user meminta tambahan-tambahan fungsi. Sehingga software dikembangkan dari kebutuhan semula.
    4. Prevention Sering disebut software re-enginering, harus dilakukan untuk memungkinkan software bisa sesuai dengan keinginan end user. Pada fase ini dilakukan perubahan-perubahan ke program komputer, sehingga program tersebut bisa dikoreksi, beradaptasi dan dikembangkan dengan mudah. 

Materi 2 Model-model Software
Model sekuensial linear
Model sekuensial linear disebut juga model waterfall atau air terjun.  Model ini peertama kali muncul pada tahun1970 yang diperkenalkan oleh WinstonW.Royce. walaupun sudah dikenal dalam waktu yang lama dan sering di anggap kuno tetapi model ini paling banyak dipakai dalam industri perangkat lunak .
Model sekuensial linear berisi rangkaian proses yang disajikan secara terpisah, yaitu analisis kebutuhan,perancangan,pemgkodean,pemgujian, seta implementasi dan pemeliharaan. Setelah setiap proses dilakukan, proses tersebut ditutup dan pengembangan dilanjutkan pada proses berikutnya.
Untuk mengatasi kekurangna-kekurangan tersebut, dibuatlah model sekuensial linear yang dimodifikasis. Keunggulan model ini dibandingkan model sekuensial linear biasa adalah model ini memungkinkan tahap-tahap yang telah dilalui ditinjau kembali sehinnga jika ternyata terjadi  kesalahan atau kekurangan dalam menentukan kebutuhan di tahap awal, bisa dilakukan perbaikan atau peambahan lagi.
Model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut :
1       Rekayasa dan pemodelan sistem/informasi
Karena sistem merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan anasisis system menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
2       Analisis kebutuhan Software
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan dilihat lagi dengan pelanggan.
3       Desain
Desain software sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.
4       Generasi Kode
Desain harus diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
5       Pengujian
Sekali program dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
6       Pemeliharaan
Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah software yangdilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.
Kekurangan model sekuensial linear
Masalah yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah :
1.     Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.
2.     Kadang – kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan halini dan mengalami kesulitan untuk mengakomodasi ketidakpastiannatural yang ada pada bagian awal beberapa proyek.
3.     Pelanggan harus bersifat sabar. Sebuah versi kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.
4.     Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier.
Kelebihan model sekuensial linier
1.     software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
2.     Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.
Model Prototype
Prototype adalah sebuah Javascript Framework yang dibuat untuk lebih memudahkan proses dalam membangun aplikasi berbasis web.
Paradigma dari metode prototyping adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.
Model ini digunakan jika customer tidak menjelaskan detail kebutuhan input, proses atau output, sehingga developer tidak dapat memastikan algoritma yang akan dipakai, kesesuaian sistem operasi atau bentuk user interface. Prototyping model dimulai dengan mendengarkan kebutuhan user. Engineer dan customer bertemu dan menentukan semua tujuan software dan menentukan kebutuhan-kebutuhan. Developer kemudian membangun prototype dan user menguji coba prototype untuk memberikan feedback. Prototype dapat dijalankan sebagai sistem yang pertama. User bisa mendapatkan pengertian dari sistem yang sesungguhnya dan developer dapat membangun sistem dengan segera. Kekurangan : kontrak akan merugikan, dirugikan oleh keinginan customer yang meminta penambahan-penambahan. Kelebihan : akan mengurangi waktu pembuatan program, kebutuhan customer akan lebih terpenuhi dengan baik, jika kebutuhannya belum jelas, maka dengan prototype akan lebih menguntungkan.
Empat langkah yang menjadi karakteristik metode Prototyping yaitu
1. Pemilihan fungsi
Mengacu pada pemilahan fungsi yang harus ditampilkan oleh prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-tugas yang relevan yang sesuai dengan contoh kasus yang akan diperagakan.
2. Penyusunan Sistem Informasi
Bertujuan untuk memenuhi permintaan akan tersedianya prototype.
3. Evaluasi
4. Penggunaan Selanjutnya
Tahapan-tahapan Prototyping
1. Pengumpulan kebutuhan : Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2. Membangun prototyping : Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output)
3. Evaluasi prototyping : Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.
4. Mengkodekan sistem : Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai
5. Menguji sistem : Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain
6. Evaluasi Sistem : Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.
7. Menggunakan sistem : Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.
Jenis-jenis Prototyping
ð  Feasibility prototyping – digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.
ð  Requirement prototyping – digunakan untuk mengetahui kebutuhan aktivitas bisnis user.
ð  Desain Prototyping -  digunakan untuk mendorong perancangan system informasi yang akan digunakan.
ð  Implementation prototyping – merupakan lanjytan dari rancangan protipe, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.
Teknik-teknik Prototyping meliputi
1. Perancangan Mode
2. Perancangan Dialog
3. Simulasi
Keunggulan dan Kelemahan Prototyping
Keunggulan Prototyping :
1.     End user dapat berpartisipasi aktif
2.     Penentuan kebutuhan lebih mudah diwujudkan
3.     Mempersingkat waktu pengembangan SI
1.     Adanya komunikasi yang baik antara pengembang dan pelanggan
2.     Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
3.     Pelanggan berperan aktif dalam pengembangan sistem
4.     Lebih menghemat waktu dalam pengembangan sistem
5.     Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.
Kelemahan Prototyping :
1.     Proses analisis dan perancangan terlalu singkat
2.     Mengesampingkan alternatif pemecahan masalah
3.     Bisanya kurang fleksible dalam mengahadapi perubahan
4.     Prototype yang dihasilkan tidak selamanya mudah dirubah
   5.     Prototype terlalu cepat selesai
 
Rapid Application Development (RAD) Model
RAD merupakan incremental software process yang menekankan pada siklus development yang singkat. Model ini mengunakan pembuatan berdasarkan komponen, menekankan penggunaan kembali code dan code generation. Jika requirement telah diketahui dengan pasti dan scope project mendesak, RAD proses memungkinkan team development untuk sistem fungsional keseluruhan dalam periode waktu yang sangat singkat (misalnya 60-90 hari). RAD model dapat digunakan untuk project yang dapat dipisah, misalnya ada 1 project besar, dibagi 3, dikerjakan oleh team yang berbeda-beda (dari analisis sampai testing) kemudian diintegrasikan. Jika menggunkan RAD model, kualitas team harus solid dan punya disiplin tinggi. Kekurangan : (1). untuk project yang besar dan membutuhkan sumber daya manusia yang cukup. (2) Jika developer dan customer berkomitmen untuk menyelesaikan project dalam waktu yang singkat, maka project akan gagal. (3). Jika pemodulan project tidak tepat, maka pembangunan komponen untuk RAD akan bermasalah.
Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan.[1] Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.
Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :
1.   Component based construction ( pemrograman berbasis komponen bukan prosedural).
2.   Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.
3.   Pembangkitan kode program otomatis/semi otomatis.
4.   Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.
Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.
Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.
Kelemahan
Beberapa hal (kelebhan dan kekurangan) yang perlu diperhatikan dalam implementasi pengembangan menggunakan model RAD :
1.   Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.
2.   Model ini cocok untuk proyek dengan skala besar.
3.   Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam 1 tim
4.   kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus.
5.   sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
6.   penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras.
7.   proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
8.   risiko teknis yang tinggi juga kurang cocok untuk model ini.
Kelebihan
1.     Fleksibilitas yang lebih besar
2.     Sangat mengurangi manual coding
3.     Peningkatan keterlibatan pengguna
4.     Mungkin lebih sedikit cacat
5.     Mungkin dikurangi biaya
6.     Singkat siklus pengembangan
 Incremental Model
            Pada tahun 1971 Harlan Mills (IBM) mengusulkan semestinya perkembangansoftware lebih tepat daripada membuatnya. Kita mulai membangun system sangat sederhanayang mendukung, memiliki fungsi sederhana, kemudian menambahkan dan mengembangkansoftware tersebut. Semestinya software pengembangan seperti bunga atau pohon. Nama lainperangkat lunak tersebut adalah incremental model.
Model incremental (Incremental waterfall model) merupakan perbaikan dari model waterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini adalah membangun software secara meningkat (increment) berdasarkan kemampuan fungsional.Model incremental ini diaplikasikan pada sistem pakar dengan penambahan rules yang mengakibatkan bertambahnya kemampuan fungsional sistem. Model incremental merupakan model continous rapid prototype dengan durasi yang diperpanjang hingga akhir proses pengembangan. Pada model prototipe biasa, prototipe hanya dibuat pada tahap awal untuk mendapatkan kebutuhan user.Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa perangkatlunak perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses membangunberhenti jika produk telah mencapai seluruh fungsi yang diharapkan.Pada awal tahapan dilakukan penentuan kebutuhan dan spesifikasi. Kemudian dilakukanperancangan arsitektur software yang terbuka, agar dapat diterapkan pembangunan per-bagian pada tahapan selanjutnya.
Tahapan Incremental Model
1.Requirement
2.Specification
3.Architecture Design
Incremental model menerapkan rangkaian linear. Setiap rangkaian linear mendelivery increment dari software. Sebagai contoh, software word-processing, dibangun menggunakan incremental model, mendelivery fungsi dasar file management, editing, dan fungsi document production pada increment pertama. Kemampuan editing, dan fungsi document production yang lebih baik pada increment kedua, checking dan grammar spelling pada increment ketiga. Proses akan diulangi sampai produk yang lengkap telah dihasilkan. Jika menggunakan Incremental model, increment yang pertama merupakan inti product. Incremental model fokus pada pendeliverian opertional product pada tiap increment.
Kelebihan Model Incremental
1.  Penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi dandapat menurunkan biaya yang dikeluarkan untuk memperbaiki system.
2. Nilai penggunaan dapat ditentukan pada setiap increament sehingga fungsionalitas sistemdisediakan lebih awal
3. Increment awal berupa prototype untuk membantu memahami kebutuhan pada incrementberikutnya.
4. Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem.
5. Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji
Kekurangan Model Incremental
1. Tiap bagian tidak dapat diintegrasikan
2. Setiap tambahan yang dibangun harus dimasukkan kedalam struktur yang ada tanpamenurunkan kualitas dari yang telah dibangun system tersebut sampai saat ini.
3.     Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut.
 
Model assembly
Model assembly teknologi dan metode yang digunakan oleh komputer-aided design dan produk visualisasi sistem perangkat lunak komputer untuk menangani beberapa file yang mewakili komponen dalam suatu produk. Komponen dalam perakitan direpresentasikan sebagai padat atau permukaan model.
Desainer umumnya memiliki akses ke model yang lain bekerja pada secara bersamaan. Sebagai contoh, beberapa orang dapat merancang satu mesin yang memiliki banyak bagian. Bagian-bagian baru yang ditambahkan ke model perakitan karena mereka diciptakan. Setiap desainer memiliki akses ke model perakitan, sementara pekerjaan yang sedang berlangsung, dan saat bekerja di bagian mereka sendiri. Evolusi desain dapat dilihat oleh semua orang yang terlibat.
File-file data individu menggambarkan geometri 3D dari komponen individu dirakit bersama-sama melalui sejumlah sub-perakitan tingkat untuk membuat perakitan menggambarkan seluruh produk.Semua CAD dan CPD sistem mendukung bentuk bottom-up konstruksi. Beberapa sistem, melalui penyalinan asosiatif geometri antar komponen juga memungkinkan top-down metode desain.
Komponen dapat diposisikan dalam perakitan produk menggunakan metode koordinat penempatan absolut atau melalui kondisi kawin. Kondisi kawin adalah definisi dari posisi relatif komponen antara satu sama lain; untuk penyelarasan contoh sumbu dua lubang atau jarak dari dua wajah dari satu sama lain. Posisi akhir dari semua komponen berdasarkan hubungan ini dihitung menggunakan mesin geometri kendala dibangun ke dalam CAD atau paket visualisasi.
Pentingnya model perakitan dalam mencapai manfaat penuh dari PLM telah menyebabkan kemajuan yang sedang berlangsung dalam teknologi ini. Ini termasuk penggunaan struktur data ringan seperti JT yang memungkinkan visualisasi dan interaksi dengan data dalam jumlah besar produk, antarmuka langsung ke antara Mock up digital dan sistem PDM dan aktif digital mock up teknologi yang menyatukan kemampuan untuk memvisualisasikan perakitan mengejek atas dengan kemampuan untuk mengukur, menganalisis, mensimulasikan, desain dan merancang ulang.

 
Fourth Generation Tehnique Paradigm - Model tehnik generasi   ke 4 / 4G
Istilah Fourth Generation Technique (4GT) meliputi seperangkat peralatan software yang memungkinkan seorang developer software menerapkan beberapa karakteristik software pada tingkat yang tinggi, yang kemudian menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi yang ditentukan developer. Saat ini peralatan / tools 4GT adalah bahasa non prosedur untuk :
·        DataBase Query
·        Pembentukan laporan ( Report Generation )
·        Manipulasi data
·        Definisi dan interaksi layar (screen)
·        Pembentukan object dan source ( Object and source generation )
·        Kemampuan grafik yang tinggi, dan
·        Kemampuan spreadsheet
Keterangan:
 Model 4GT untuk software engineering dimulai dengan rangkaian pengumpulan kebutuhan. Idealnya, seorang customer menjelaskan kebutuhan-kebutuhan yang selanjutnya diterjemahkan ke dalam prototype. Tetapi ini tidak dapat dilakukan karena customer tidak yakin dengan apa yang diperlukan, tidak jelas dalam menetapkan faktafakta yang diketahui dan tidak dapat menentukan informasi yang diinginkan oleh peralatan 4GT.
Untuk aplikasi kecil adalah mungkin bergerak langsung dari langkah pengumpulan kebutuhan ke implementasi yang menggunakan bahasa non prosedur fourth generation (generasi ke 4). Tetapi untuk proyek besar, pengembangan strategi desain sistem tetapdiperlukan, sekalipun kita menggunakan 4GL. Penggunaan 4GT tanpa desain untuk proyek besar akan menyebabkan masalah yang sama yang ditemui dalam pengembangan software yang menggunakan pendekatan konvensional.
Implementasi yang menggunakan 4GL memungkinkan developer software menjelaskan hasil yang diinginkan yang kemudian diterjemahkan ke dalam bentuk source code dan object code secara otomatis.
Langkah yang terakhir adalah mengubah implementasi 4GT ke dalam sebuah product. Selanjutnya developer harus melakukan pengetesan, pengembangan dokumentasi dan pelaksanaan semua aktifitas lainnya yang diwujudkan dalam model software engineering. Masalah yang dihadapi dalam model 4GT adalah  sebagian orang  beranggapan bahwa :
ð  peralatan 4GT tidak semudah penggunaan bahasa pemrograman,
ð  source code yang dihasilkan oleh peralatan ini tidak efisien,
ð pemeliharaan sistem software besar yang dikembangkan dengan 4GT masih merupakan tanda tanya.

Materi 3
KONSEP MANAJEMEN PROYEK
Rekayasa Perangkat Lunak
  1. Manajemen proyek perangkat lunak merupakan bagian yang penting dalam pembangunan perangkat lunak.
  2. Sekalipun tidak bersifat teknis seperti pengkodean, hal-hal dalam manajemen proyek PL ini mampu menentukan apakah proyek akan berjalan dengan baik sehingga menghasilkan produk yang baik.
Manajemen Personel, Produk dan Proses
             3. Manajemen proyek perangkat lunak mengatur 4 hal penting :
a.       Personel
b.      Masalah (problem) à berkaitan dengan Produk
c.       proses dan
d.      Proyek à tambahan (tapi sangat penting)
  1. Empat hal ini berurutan mulai dari yang paling penting.
Spektrum Manajemen
     5. Personel mendapat tempat paling penting karena tanpa personel yang baik dan tepat maka 3 hal lain tidak bisa berjalan dengan baik.
  1. Manajemen proyek per. lunak merupakan layer pertama pada proses software engineering & sangat penting untuk kesuksesan proyek
People
  1. Lima konstituen proyek PL:
    1. Manajer Senior -> menentukan isu-isu bisnis
    2. Manajer (teknik) Proyek -> merencanakan, memotivasi, mengorganisir, mengontrol produk
    3. Pelaksana -> menyampaikan ketrampilan teknik
    4. Pelanggan -> menentukan jenis kebutuhan PL
    5. Pemakai Akhir -> berinteraksi dg PL
  1. Efektifitas kerja masing-masing personel di atas harus diusahakan oleh pemimpin tim. Pemimpin tim ini yang mengatur tim proyek agar dapat memberikan yang terbaik dari masing-masing personel.
  2. Pimpinan Tim (1)
    1. Pemimpin Tim PL = manager proyek.
    2. Seorang pemimpin tim diharuskan mempunyai ketrampilan memimpin yang cukup.
    3. Kemampuan yang dibutuhkan dalam kepemimpinan seperti:
      • Motivasi -> kemampuan memberi dorongan utk menghasilkan sesuatu
      • Organisasi -> kemampuan membentuk proses yg sedang berlangsung yg memungkinkan konsep dasar diterjemahkan ke hasil akhir
      • Gagasan dan Inovasi -> kemampuan mendorong manusia utk menciptakan & bertindak kreatif 

3. Pimpinan Tim (2)
    1. Karakteristik yg menentukan manajer proyek yg efektif memberi tekanan :
      • Pemecahan masalah -> dapat mendiagnosis isu-isu organisasi & teknis, secara sistematis membentuk sebuah pemecahan atau dgn tepat memotivasi pelaskana, menerapkan hasil pengalaman, fleksibel utk mengubah arah
      • Identifikasi manajerial -> bersentuhan langsung dengan proyek
      • Prestasi -> memiliki inisiatif dan prestasi, pengambilan resiko tdk ada hukuman
      • Pengaruh dam pembentukan tim -> mampu “membaca” manusia
  1. Tim Perangkat Lunak (1)
    1. Struktur tim “terbaik” tergantung gaya manajemen sebuah organisasi, jumlah orang dalam tim, tingkat ketrampilannya, kesulitan masalah secara keseluruhan.
    2. Contoh Struktur Organisasi Tim :
      • Demokratis terdesentralisasi (DD) -> tidak memiliki pimpinan yg permanen, “koordinator” dipilih dlm jangka pendek, keputusa & pendekatan masalah dibuat oleh konsensus kelompok
      • Terkontrol terdesentralisasi (CD) -> memiliki pimpinan tertentu & sekunder, pemecahan masalah aktivitas kelompok tapi implementasinya dipecah diantara sub2 kelompok oleh pimpinan, komunikasi horisontal & vertikal
      • Terkontrol tersentralisasi (CC) -> koordinasi pemecahan masalah tingkat puncak & internal tim diatur pimpinan tim
  2. Tim Perangkat Lunak (2)
    1. Faktor proyek yg harus dipertimbangkan saat merencanakan struktur tim RPL:
      • Kesulitan masalah yg akan dipecahkan
      • Ukuran program2 resultan pd baris kode & titik fungsi
      • Waktu tim akan tinggal bersama
      • Tingkat dimana masalah dapat dimodularisasikan
      • Kualitas yg diperlukan serta keandalan sistem yg dibangun
      • Kepastian tanggal penyampaian
      • Tingkat sosiabilitas (komunikasi) yg dibutuhkan oleh proyek
  3. Tim Perangkat Lunak (3)
    1. Pengaruh Karakteristik Proyek pada Struktur Tim

1.     
                             7. Tim perangkat Lunak (4)
    1. Paradigma organisasional tim RPL:
·         Paradigma tertutup ->membentuk tim di sepanjang hirarki otoritas tradisional
·         Paradigma random -> membentuk tim secara longgar & tergantung inisiatif individual anggota tim
·         Paradigma terbuka -> cenderung membentuk tim dgn cara tertentu, tercapai banyak kontrol dan inovasi
·         Paradigma sinkron -> bertumpu pd penggolongan alami suatu masalah
                  8. Alasan RPL menemui kesulitan:
    1. Skala usaha pengembangan besar, kompleksitas tinggi, kesulitan mengkoordinasi tim
    2. Ketidakpastian -> aliran perubahan terus menerus
    3. Interoperabilitas -> PL baru berkomunikasi dgn PL yg sudah ada atau menyesuaikan diri dgn batasan yg sudah ditentukan
            9. Teknik koordinasi proyek:
    1. Pendekatan impersonal, formal -> penyampaian & dokumen RPL, memo2 teknis, kejadian penting pd proyek, jadual & piranti kontrol proyek, kebutuhan akan perubahan, laporan pelacakan kesalahan, data cadangan
    2. Prosedur interpersonal, formal -> aktivitas jaminan kualitas yg diterapkan pd produk kerja RPL; pertemuan pengkajian, perancangan & inspeksi kode
    3. Prosedur interpersonal, informal -> pertemuan kelompok utk penyebaran informasi & pemecahan masalah
    4. Komunikasi elektronik -> e-mail, papan buletin elektronik, web site, sistem konferensi berbasis video
    5. Jaringan interpersonal -> diskusi informal dg orang2 diluar proyek
 
Problem
  1. Ruang lingkup PL:
    • Konteks -> Bagaimana PL dibangun utk memenuhi sebuah sistem, produk atau konteks bisnis yg lebih besar, batasan yg ditentukan
    • Tujuan informasi -> Obyek data sebagai input atau output
    • Fungsi dan unjuk kerja -> Fungsi PL utk transformasi input data menjadi output
  1. Dekomposisi masalah (partitioning/ pembagian):
    • Fungsionalitas yg harus disampaikan
    • Proses yg dipakai utk menyampaikannya
Process
  1. Fase2 generik proses PL – definisi, pengembangan dan pemeliharaan –diaplikasikan pd semua PL
  2. Manajer proyek harus memutuskan model proses mana yang paling sesuai untuk proyek etrtentu, yang kemudian menentukan sebuah rencana utama yang didasarkan pada sejumlah aktivitas kerangka kerja proses yang umum.
  3. Menggabungkan masalah dan proses -> aktivitas kerangka kerja :
    • Komunikasi pelanggan – membangun komunikasi yg efektif antara pengembang & pelanggan
    • Perencanaan – menentukan sumber daya, ketepatan waktu, & informasi proyek lain
    • Analisis resiko – memperkirakan resiko2 manajemen & teknis
    • Rekayasa – membangun satu perwakilan aplikasi atau lebih
    • Konstruksi & peluncuran – membangun , menguji, memasang (instal) & memberikan dukungan pd pemakai
    • Evaluasi pelanggan – memperoleh umpan balik dr pelanggan didasarkan evaluasi representasi PL selama masa perekayasaan& diimplementasi selama masa instalasi
  4. Dekomposisi proses  :
    • Proyek relatif kecil – menggunakan pendekatan linier
    • Batasan waktu ketat & masalah dpt dipecah2 – model RAD
    • Batasan waktu ketat & fungsionalitas tdk dpt disampaikan – model pertambahan
Proyek
  1. Kesulitan proyek  :
·         Cara dimana kemajuan dinilai adalah cacat
·         Tidak ada cara utk mengkalibrasi kemajuan, tidak diperoleh metrik kuantitatif
·         Rencana proyek belum dirancang utk mengakomodasi sumber daya yg diperlukan pd akhir proyek
·         Resiko2 belum dipertimbangkan secara eksplisit, belum dibuat rencana utk mengurangi, memonitor, mengaturnya
·         Jadual yg ada tidak realistis dan cacat
MAter 







. 

READ MORE - Materi Ujian RPL
Diposting oleh AndhysdotCom Githu loh... di 01.09 0 komentar
Langganan: Postingan (Atom)