Chapter 9 - Software Testing (Strategies)

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100004

Chapter 9 : Software Testing (Strategies)

Pada kali ini, kami akan membahas salah satu materi pada bab project life cycle SQA components, yakni Software Testing.

Software Testing adalah proses formal dalam mengeksekusi software dalam unit, integrasi, maupun sistem untuk menganalisa perbandingan antara kebutuhan pelanggan dan kenyataan pada program 

Untuk lebih jelasnya, kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

http://prezi.com/pdskxdk4xnpg/untitled-prezi/

Terima kasih :)

Chapter 20 Project Progress Control

Project Progress Control digunakan sebagai cara untuk mendeteksi lebih dini event-event yang tidak biasa terjadi. Adapun komponen-komponen utama pada Project Progress Control sebagai berikut :
- Aktifitas kontrol manajemen resiko
Berkaitan tentang aktifitas melakukan pengelolaan resiko dimana mengidentifikasi resiko-resiko yang mengancam proyek.
- Kontrol jadwal proyek
Berkaitan tentang pengawasan terdahap penjadwalan proyek dan mencegah terjadinya keterlambatan proyek .
- Kontrol Sumberdaya proyek
Berfokus kepada sumberdaya manusianya dan juga fasilitas testingnya.
- Kontrol budget proyek

Adalah sebuah pengawasan terkait dengan budget proyek. Adapun yang dikontrol pada bagian ini adalah :
• Sumberdaya manusia
• Pengmbangan dan fasilitas untuk testing
• Pembelian software
• Pembelian hardware
• Pembayaran kepada sub kontraktor

Pengimplementasian dari control progress proyek harus sesuai dengan prosedur yang menentukan hal-hal berikut :
Alokasi Tanggung jawab (siapa saja yang bertanggung jawab dalam melakukan tugas control progress)
• Frekuensi dari pelaporan yang dibutuhkan pada setiap unit proyek
• Suatu situasi yang membutuhkan manajemen bawah untuk melaporkan secepatnya kepada atasan.

Peranan tools dalam melakukan control progress dari proyek
Tools sangat membantu dalam meringankan beban kita sebagai manusia untuk melakukan sesuatu. Adapun manfaat menggunakan tools ini dapat membantu pada area sebagai berikut :
- Aktifitas kontrol manajemen resiko
- Dapat mebantu mengkategorikan resiko dan juga pengelolaan tanggal pemecahan solusi
Kontrol jadwal proyek
- Membuat daftar klasifikasi dari aktifitas yang tertunda
- Membuat daftar klasifikasi dari aktifitas kritkal
- Memperbaharui jadwal aktifitas yang dibuat berdasarkan laporan progress

Kontrol sumberdaya proyek
- Rencana pengalokasian sumberdaya proyek
- Pemanfaatan sumberdaya proyek
Pada control budget
- Membantu merencanakan budget proyek
- Membuat daftar pemanfaatan budget

Chapter 19 Documentation Control

Controlled Document (Dokumentasi yang terkontrol) adalah dokumen yang berisi dokumentasi pengembangan dan maintenance sebuah software yang dibuat di Internal perusahaan sendiri. Dalam implementasinya control dokumen sangat perlu dilakukan untuk menjaga sebuah software tersebut tetap terdokumentasi dengan baik. Bayangkan saja ketika kita ingin mengembangkan sebuah software yang sudah ada tanpa ada dokumentasi sebelumnya tentu akan memakan waktu lama dan juga biaya yang sangat besar, oleh karena itu akan lebih memudahkan programmer ketika pengembangan sebelumnya programmer-programer terdahulu melakukan pendokumentasian dengan baik. Pendokumentasian ini merupakan salah satu bagian dari SQA (Software Quality Assurance) untuk memastikan sebuah software tersebut terjaga kualitasnya. Aada juga yang disebut dengan Quality Record (catatan kualitas) dimana merupakan dokumen special yang berfokus pada kebutuhan kustomer dan keefektifan pengoperasian dari system SQA.Untuk prosedurnya sendiri terbagi menjadi 4:

- List dokumen yang sudah terkontrol
- Persiapan dokumen control
- Persetujuan dokumen control
- Permasalahan dari penyimpanan dan pengambilan dokumen  control

List dokumen yang terkontrol
Pada bagian ini pihak yang bertanggung jawab melakukan control dokumen melakukan :
- Menentukan tipe dokumen mana yang dapat dikategorikan sebagai dokumen yang terkontrol dan tipe dokumen control yang diklasifikasikan sebagai quality record.
- Menentukan level dari control yang memungkinkan untuk setiap dokumen yang dikategorikan sebagai dokumen control.
- Menganalisa temuan terbaru dan melakukan pembaharuan, perubahan, dan tambahan-tambahan lainnya pada dokumen control.

Persiapan dokumen control
Pada bagian ini pihak yang melakukan control mempersiapkan 3 kebutuhan yaitu : Structure (Template), Identification Method (Memberikan kode versi dan revisi), dan Standart Orientation and reference information (Berisi tentang data si penulis dokumen ). Untuk reference information diberi data tentang penulis yang berisi tentang :
- Penulis dokumen
- Tanggal pembuatan
- Orang yang menyetujui dokumen (beserta jabatan)
- Tanggal persetujuan
- Tanda tangan dari penulis dan orang yang menyetujui
- Penjelasan dari perubahan yang telah dilakukan pada dokumen yang baru
- Daftar dari versi dan revisi sebelumnya
- Daftar orang-orang yang pernah melihat dokumen tersebut

Persetujuan dokumen control
Pada bagian ini hanya menjelaskan tentang siapa yang boleh dan bertanggung jawab dalam menyetujui dokumen dan tipe-tipe dokumen apa saja yang dapat disetujui. Untuk orang yang boleh melakukan persetujuan adalah orang orang yang telah dipercayakan perusahaan sebagai reviewer yang memiliki keahlian di bidangnya. Selanjutnya ada proses persetujuan, untuk proses persetujuannya memerlukan persetujuan dari pihak reviewer untuk verifikasi dan validasi dokumen control sehingga kualitas dapat terjaga.

Permasalahan dokumen control terkait penyimpanan dan pengambilan dokumen
Dokumen control ini harus dijaga dengan baik, sehingga tidak terjadi kerusakan dan kehilangan. Bayangkan saja jika sebuah software sensitive seperti perbankkan itu mengalami kerusakan ataupun kehilangan akan merugikan bank tersebut. Dan pada bagian ini menentukan bagaimana dokumen yang tidak terpakai itu dibuang dan cara membuangnya. Hal ini dibuat agar tidak jatuh ketangan yang salah.

Chapter 8 - Review

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100004

Chapter 8 : Review

Pada kali ini, kami akan membahas salah satu materi pada bab project life cycle SQA components, yakni review.
Review adalah.

Proses pertemuan antara satu set elemen suatu pekerjaan (project personnel, manajer, pengguna, pelanggan, dan pihak lainnya) untuk merumuskan suatu persetujuan (IEEE,1990)

Untuk lebih jelasnya, kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

http://prezi.com/qpw9fnd7vbnc/untitled-prezi/

Terima Kasih :)

Chapter 6 Development and Quality Plans

Pada bab ini akan membahas tentang elemen-elemen apa saja yang ada pada saat pengembangan dan juga pada saat quality plan. Lalu mengidentifikasikan resikonya.
Planning (perencanaan) , memiliki beberapa tujuan ditiap tujuan tersebut harus memiliki beberapa landasan yang memadai seperti :
- Penjadwalan aktifitas pengembangan, sehingga semua dapat tersusun rapi serta dapat dibuat perkiraan waktu, sumberdaya, dan budget.
- Merekrut anggota tim dalam proses pengembangan proyek
- Mencari solusi terkait dengan resiko pengembangan
- Mengimplementasikan aktifitas SQA yang dibutuhkan
- Memberikan manajemen data-data yang diperlukan untuk mengontrol proyek

Pada bagian ini perencanaan dibagi menjadi 2 :
1. Perencanaan Pengembangan
2. Perencanaan Kualitas

Perencanaan Pengembangan
Perencanaan pengembangan dipersiapkan untuk memenuhi landasan tujuan perencanaan,diantaranya :
1. Produk dari proyek
2. Interface Proyek ( Interface terhadap software yang sudah ada ataupun software lainnya)
3. Metodelogi proyek dan tools pengembangan
4. Standart pengembangan software dan prosedur
5. Memetakan proses pengembangan ( agar lebih detail tiap fase proyek)
6. Titik temu proyek (berkaitan tentang waktu penyelesaian dan produk)
7. Pengelolaan staff proyek (dibagi bedasarkan tugas masing-masing, dan untuk menjadi professional diperlukan sertifikasi dan training)
8. Fasilitas pengembangan (hardware, infrastruktur,dsb)
9. Resiko pengembangan (berkaitan tentang resiko kesenjangan teknologi,kurangnnya staff, dsb)
10. Metode pengendalian (control) (berkaitan tentang monitoring proyek)
11. Perkiraan biaya proyek (merupakan perkiraan biaya yang harus dikeluarkan dalam mengembangkan proyek)

Perencanaan Kualitas
Didalam perencanaan kualitas maka perlu adanya elemen berikut :
1. Tujuan Kualitas (Quality Goals)
2. Aktifitas review yang terencana (berisi review scope,type,jadwal,prosedur,yang bertanggung jawab untuk me-review)
3. Uji coba software secara terencana (tes integration, tipe tes (white , black box testing), Jadwal yang terencana, prosedur, dan yang bertanggung jawab melakukan tes)
4. Merencanakan tes acceptance untuk software yang di kembangkan diluar (sesuai apa tidak, dengan yang dibutuhkan)
5. Manajemen Konfigurasi (berkaitan tentang tools yang berkaitan dengan managemen dan juga prosedur)
Rencana kualitas dapat berupa dokumen yang dipersiapkan sebagai bagian dari rencana pengembangan dimana dibuat sebagai dokumen independent. Review dan persetujuan dari rencana kualitas perlu dilakukan sesuai dengan standart perusahaa dam prosedur yang berlaku.

Keuntungan dalam membuat rencana persiapan , jika dilihat dari segi
Departemen Developer(pengembang)
1. Menghindari overbudget.
2. Menghindari kerusakan dari proyek lainnya yang mengalami keterlambatan
3. Menhindari kehilangan “status” pasar, seperti reputasi yang di akibatkan dari keterlambatan proyek.

Pelanggan internal (pengguna si divisi itu sendri) :
1. Meminimalkan penyimpangan dari tanggal yang direncanakan dan tidak overbudget
2. Memiliki pengawasan terhadap proses pengembangan( identifikasi sejak dini terkait permasalahan yang akan menghambat di kemudian hari)
3. Dampak yang ditimbulkan oleh keterlambatan internal sedikit.

Organisasi :
1. Mengurangi resiko kehilangan pasar (market loss) dikarenakan keterlambatan datangnnya produk
2. Mengurangi resiko dituntut oleh customer karena keterlambatan supply
3. Mengurangi resiko kerusakan reputasi perusahaan
4. Mengurangi resiko permintaan penambahan budget

Chapter 5 Contract Review

Dalam melakukan kontrak pasti kita akan melakukan  analisa sebelum deal dengan kontrak yang dibuat oleh software house atau perusahaan developer lainnya. Jangan sampai kontrak yang sudah buat tidak kita lihat dan dapat menyebabkan kesalahpahaman karena segala kebutuhan customer dijelaskan di dalam kontrak, oleh karena itu perlu dilakukan review kontrak. Dalam prosesnya dibagi menjadi 2 tahapan :
- Tahap 1 : Mereview terlebih dahulu draft proposal sebelium mengajukan ke customer potensial
- Tahap 2 : Mereview kontrak sebelum menandatanganinya

Kontrak ini baik digunakan pada saat :
- Berpartisipasi dalam tender
- Menerima pesanan software dari customer
- Mendapat permintaan pengembangan software dari internal perusahaan atau dari divisi lainnya di dalam satu organisasi.
Jadi kontrak wajib hukumnya dibuat jika customer ingin melakukan kerjasama dibidang pengembangan software. Review kontrak  terbagi menjadi 2:
- Review draft proposal
- Review draft kontrak

Dan ditiap review diatas terdapat tujuan-tujuan dan apa saja yang harus dipenuhi ketika melakukan review.
Review draft proposal dibuat untuk mengetahui apakah draft yang dibuat telah memenuhi hal-hal dibawah ini:
- Kebutuhan Kustomer telah terdokumentasi dengan baik
- Semua pendekatan dalam proyek telah di periksa dengan baik
- Aspek formal kustomer dengan software house telah dibuat
- Identifikasi resiko
- Perkiraan sumberdaya dan jadwal yang memadai
- Memeriksa kapasitas perusahaan di proyek
- Memeriksa kapasitas kustomer dalam proyek
- Keterlibatan kontraktor dan Sub kontraktor
- Pendefinisian hak kepemilikan

Review draft Kontrak , dilakukan untuk melihat aktifitas berikut telah terpenuhi :
- Tidak ada lagi isu-isu atau masalah terkait dengan kebutuhan data yang belum terklarifikasi
- Kesepemahaman antara customer dan juga software house telah terdokumentasi dengan baik
- Ketika membuat draft kontrak tidak lagi tambahan, perubahan, ataupun kelalaian. Intinya harus fix ketika dikasikan draft ini ke customer

Dalam Implementasinya,  ada beberapa factor yang dapat mempengaruhi review kontrak :
- Besarnya proyek
- Kompleks atau tidakya proyek itu
- Tingkat pendidikan staff dan pengalaman kerja
- Organisasi proyek yang kompleks (jika banyak kontraktor,sub,partner,dan customer yang terlibat , maka akan perlu  usaha yang lebih pula dalam proses review kontrak).

Dalam review kontrak semua orang berhak melakukan review kontrak namun hanya orang-orang yang berkepentingan saja seperti pimpinan dan juga staff yang di tunjuk untuk mengangani proposal kontrak , orang lain juga berhak untuk menangangi review kontrak namun yang di tunjuk oleh perusahaan. Ketika perusahaan mengambil orang lain dalam menangani kontrak  biasanya kontrak-kontrak yang besar. Didalam implementasinya ada permasalahan terkait dengan kontrak yang besar(yang biasanya terkait dengan proyek-proyek besar) :
- Waktu
- Review kontrak memerlukan pekerjaan yang professional (tidak boleh sembarang orang bisa melakukan review)
- Tim yang bisasanya melakukan review sangat sibuk.

Untuk menangani masalah diatas maka perlu dilakukan :
- Membuat jadwal ,kapan dilakukan review kontrak
- Dilakukan secara team sehingga meringankan kerja tim reviewer
- Menunjuk pimpinan reviewer

Jika melakukan pengembangan proyek internal (in-house proyek), perusahaan perlu juga membuat kontrak hal ini untuk menjelaskan apa saja kebutuhan proyek dan kapasitas tiap individunya dalam mengembangkannya, namun permasalahan pada umumnya yang terjadi adalah :
- Informasi terkait kebutuhan proyek yang kurang memadai
- Kesalahan perkiraan sumberdaya
- Kesalahan penjadwalan
- Informasi terkait resiko yang kurang memadai
Untuk itu jika melakukan in-house proyek perlu adanya hubungan dan komunikasi yang baik antar divisi dan pengembang yang ingin mengembangkan proyek internal tersebut. Karena hampir tidak mungkin proyek dapat berjalan dengan baik jika tidak ada komunikasi yang baik pula.

Flexibility Vs Reuseability

Reuseability Vs. Flexibility 

Menurut standart IEEE
Flexibility : The ease with which a system or component can be modified for use in application or environments other than those for which it was specifically designed .
Dengan kata lain flexibility adalah kemampuan software untuk beradaptasi dengan lingkungan yang baru.




Cotohnya :
- Software mampu berjalan di sistem operasi yang berbeda
- Pada konteks database, software xyz mampu mengakses 2 proses, OLTP dan OLAP dalam 2 database yang berbeda. Misalnya menggunakan OLTP pada MySQL dan OLAP pada Oracle.
- Software eclipse dapat digunakan untuk membuat program dalam berbagai bahasa pemrograman.(misalnya java,php,dan html)

Reuseability :The extent to witch part of the software system can be reused in other application.
Contohnya :
- Misalnya modul finansial dari aplikasi Finansial x, bisa digunakan berikutnya pada aplikasi manajemen proyek untuk mengelola finansial proyek.
- Pada matlab ketika akan memerlukan rumus fuzzy untuk peramalan, kita hanya perlu memanggil fungsi fuzzy yang disediakan pada matlab.
- Menggunakan ulang kode pemrograman atau software library yang sudah dibuat sebelumnya kemudian memodifikasi untuk keperluan berikutnya.