Configuration Managament

Configuration management

View more presentations from inggrid_5209100069.

Documentation Control

Documentation Control

Dokumentasi dalam Kamus Besar Bahasa Indonesia didefinisikan sebagai sesuatu yang tertulis , tercetak atau terekam yang dapat dipakai sebagai bukti atau keterangan. Adapun definisi dokumentasi adalah pemberian atau pengumpulan bukti-bukti dan keterangan.

Sedangkan dokumen control adalah sebuah dokumen yang saat ini penting atau mungkin menjadi penting untuk pengembangan dan pemeliharaan sistem perangkat lunak serta untuk pengelolaan saat ini dan masa depan hubungan dengan pelanggan. Oleh karena itu, persiapan, penyimpanan, pengambilan dan pembuangan dikendalikan oleh prosedur dokumentasi.Tipe dokumen control :

1. Pre project document

·         Contract review report

·         Contract negotiation meeting minutes

·         Software development contract

·         Software maintenance contract

·         Software development subcontracting contract

·         Software development plan

2. Project life cycle documents

·         System requirements document

·         Software requirements document

·         Preliminary design document

·         Critical design document

·         Database description

·         Software test plan

·         Design review report

·         Follow-up records of design review action items

·         Software test procedure

·         Software test report

·         Software user manuals

·         Software maintenance manuals

·         Software installation plan

·         Version description document

·         Software change requests

·         Software change orders

·         Software maintenance requests

·         Maintenance services reports

·         Records of subcontractor evaluations

3. SQA infrastructure documents

·         SQA procedures

·         Template library

·         SQA forms library

·         CAB meeting minutes

4. Software quality management documents

·         Progress reports

·         Software metrics reports

5. SQA system audit documents

·         Management review report

·         Minutes of management review meeting

·         Internal quality audit report

·         External SQA certification audit report

6. Customer documents

·         Software project tender documents

·         Customer’s software change requests

Komponen prosedur dokumentasi control :

• The controlled documents list
• Controlled document preparation
• Controlled document approval issues
• Issues of controlled document storage and retrieval issues.

The controlled documents list

Konstruksi yang tepat dari daftar ini didasarkan pada pembentukan otoritas untuk menerapkan konsep ini, apakah yang terkandung pada orang atau komite. Secara khusus, otoritas ini bertanggung jawab untuk:

Menentukan jenis dokumen untuk dikategorikan sebagai dokumen terkendali dan yang jenis dokumen terkontrol harus diklasifikasikan sebagai kualitas rekaman.

• Menentukan apakah tingkat kontrol yang memadai untuk setiap jenis dokumen dikategorikan sebagai dokumen terkendali. 
• Menindaklanjuti kepatuhan dengan daftar jenis dokumen terkendali. Subjek ini dapat dimasukkan dalam rencana audit mutu internal.
• Menganalisis tindak lanjut temuan dan memulai pembaruan yang diperlukan, perubahan, kepindahan dan penambahan pada daftar jenis dokumen terkendali. Jenis dokumen yang paling dikendalikan adalah dokumen yang dibuat secara internal oleh organisasi itu sendiri. Meskipun demikian, sejumlah besar dokumen jenis eksternal, seperti dokumen kontrak dan risalah rapat komite bersama, juga termasuk dalam kategori ini.

Controlled document preparation

Persyaratan dokumentasi yang terlibat dalam penciptaan dokumen baru atau revisi fokus dokumen yang ada pada kelengkapan, meningkatkan keterbacaan dan ketersediaan. Persyaratan ini diwujudkan dalam dokumen :

• Struktur
• Cara identifikasi
• Standar orientasi dan informasi referensi

Struktur dokumen bebas atau ditentukan oleh template. Sebuah metode identifikasi ini dirancang untuk memberikan setiap dokumen, versi dan revisi dengan identitas yang unik. Metode ini biasanya memerlukan notasi dari (a) sistem perangkat lunak atau nama produk atau nomor, (b) dokumen (type) kode dan (c) nomor versi dan revisi. Metode ini dapat bervariasi untuk berbeda jenis dokumen.

Orientasi dokumen dan informasi referensi mungkin diperlukan juga. Orientasi dan referensi informasi dukungan akses masa depan diperlukan dokumen dengan menyediakan informasi tentang isi dokumen dan kesesuaian dengan kebutuhan pengguna masa depan. Tergantung pada jenis dokumen, proporsi yang lebih besar atau lebih kecil dari informasi berikut item yang biasa dibutuhkan:

• Penulis dokumen
• Tanggal penyelesaian
• Orang yang menyetujui dokumen, termasuk posisi yang diselenggarakan
• Tanggal persetujuan
• Tanda tangan dari penulis dan orang-orang yang disetujui
• Deskripsi dari perubahan dalam rilis baru
• Daftar mantan versi dan revisi
• Sirkulasi daftar
• Kerahasiaan pembatasan

Requirement Traceability Matrix

Sebuah dokumen Requirement Traceability Matrix, biasanya dalam bentuk tabel, yang berkorelasi setiap dua dokumen dasar yang memerlukan banyak hubungan banyak untuk menentukan kelengkapan hubungan tersebut. Hal ini sering digunakan dengan tingkat persyaratan yang tinggi (ini sering terdiri dari persyaratan pemasaran) dan persyaratan rinci tentang produk perangkat lunak ke bagian pencocokan desain tingkat tinggi , perancangan detil, rencana uji , dan uji kasus .

Sebuah dokumen Requirement Traceability Matrix dapat digunakan untuk memeriksa serta melihat apakah persyaratan proyek saat ini telah terpenuhi, dan untuk membantu dalam penciptaan sebuah Request for Proposal , penyerahan berbagai  dokumen, dan rencana proyek.

Penggunaan umum adalah untuk mengambil identifier untuk setiap item dari satu dokumen dan menempatkan mereka di kolom kiri. Pengenal untuk dokumen lain ditempatkan di baris atas. Ketika sebuah item dalam kolom kiri yang berhubungan dengan item di bagian atas, tanda ditempatkan di sel berpotongan. Jumlah hubungan yang ditambahkan untuk setiap baris dan setiap kolom. Nilai ini menunjukkan pemetaan dari dua item. Nilai nol menunjukkan bahwa hubungan tidak ada. Harus ditentukan jika salah satu harus dilakukan. Nilai yang besar berarti bahwa hubungan yang terlalu kompleks dan harus disederhanakan.

Untuk memudahkan pembuatan dokumen Requirement Traceability Matrix, disarankan untuk menambahkan hubungan ke dokumen sumber untuk kedua penelusuran mundur dan mampu menelusuri ke depan. Dengan kata lain, ketika suatu item berubah dalam satu dokumen dasar, mudah untuk melihat apa yang perlu diubah di lain.

Diagram RTM dapat digunakan selama seluruh tahapan proyek untuk:

•        Melacak semua kebutuhan dan apakah sedang atau tidak mereka penuhi pada saat proses dan desain

•        Membantu dalam penciptaan RFP, Rencana Proyek, Dokumen Deliverable, dan Test Scripts

•        Membantu memastikan bahwa semua persyaratan sistem telah terpenuhi selama proses Verifikasi

Penggunaan RTM meningkatkan proses manajemen ruang lingkup. Hal ini juga membantu dengan kontrol proses dan kualitas manajemen. RTM juga dapat dianggap sebagai proses mendokumentasikan koneksi dan hubungan antara persyaratan awal dari proyek dan produk akhir atau jasa yang dihasilkan.

Dalam setiap langkah-langkah di atas, kebutuhan masing-masing harus unik dan jelas. Persyaratan kemudian bagian dari setiap komponen penting dari proyek tersebut. Referensi seluruh seluruh proses harus konsisten dan unik. Untuk memastikan bahwa hal ini terjadi, Matrix menelusuri kebutuhan masing-masing dan menciptakan hubungan antara masing-masing proses.

Contoh RTM :

Konten Software Quality Assurance

Software Quality Assurance (SQA) diaplikasikan secara menyeluruh pada proses pengembangan software. SQA meliputi : 

1. Analisis, perancangan, pengkodean, dan metode serta peralatan ujicoba.
2. Tinjauan ulang teknikal secara formal yang diaplikasikan pada setiap tahapan pengembangan software.
3. Strategi ujicoba dengan banyak tahapan (multitiered).
4. Pengawasan terhadap dokumentasi software dan perubahan yang dialaminya. 
5. Suatu prosedur untuk menjamin pemenuhan standar pengembangan software (jika ada).
6. Mekanisme pengukuran dan laporan . 

Setiap pengembang software pasti setuju jika dikatakan bahwa kualitas software merupakan salah satu tujuan yang penting. Banyak definisi mengenai kualitas software, tetapi disini kualitas software didefinisikan sebagai :

“penyesuaian kebutuhan fungsional dan performa yang ditetapkan secara eksplisit, standar pengembangan yang terdokumentasi secara eksplisit, dan karakteristik implisit yang diharapkan dari seluruh software yang dikembangkan secara professional.” 

Definisi diatas menjelaskan 3 hal penting, yaitu :

1. Kebutuhan software merupakan pondasi/dasar dari kualitas yang akan diukur. Sedikitnya penyesuaian terhadap kebutuhan, maka semakin tidak berkualitas.
2. Standar yang dispesifikasikan mendefinisikan sekumpulan kriteria pengembangan yang memandu pengembangan software. Jika kriteria tidak disertakan, maka dapat dipastikan hasil akhir akan berkualitas rendah. 
3. Terdapat kebutuhan implisit (implicit requirements) yang terkadang tidak disebutkan (misalkan, keinginan untuk kemampuan pemeliharaan yang mudah). Jika software menyesuaikan kepada kebutuhan eksplisit, tetapi tidak kepada kebutuhan implisit, maka kualitas software akan dipertanyakan. 

Menurut McCall terdapat 3 aspek penting dari suatu produk software, yaitu : karakteristik operasional, kemampuan perubahan ketika software sudah berjalan, dan kemampuan beradaptasi terhadap lingkungan baru, seperti terlihat pada gambar diatas. Berdasarkan gambar diatas, McCall menyediakan beberapa dekripsi yaitu :

1. Correctness (kebenaran), tingkat pemenuhan program terhadap kebutuhan yang dispesifikasikan dan memenuhi tujuan/misi pengguna. 
2. Reliability (Keandalan), tingkat kemampuan program yang diharapkan dapat menampilkan fungsi yang dimaksud dengan presisi yang ditetapkan. 
3. Efficiency (efisiensi), jumlah sumberdaya yang diproses dan kode yang diperlukan oleh program untuk melaksanakan fungsinya. 
4. Integrity (Integritas), tingkat kemampuan pengawasan akses terhadap data atau software oleh orang-orang tertentu. 
5. Usability, usaha yang diperlukan untuk mempelajari, mengoperasikan, menyiapkan masukan dan mengartikan keluaran program. 
6. Maintainability, usaha yang diperlukan untuk menetapkan dan memperbaiki kesalahan dalam program. 
7. Flexibility, usaha yang diperlukan untuk memodifikasi program operasional. 
8. Testability, usaha yang diperlukan untuk menguji program untuk memastikan bahwa program melaksanakan fungsi yang telah ditetapkan. 
9. Portability, usaha yang diperlukan untuk memindahkan program dari hardware/lingkungan sistem software tertentu ke yang lainnya.
10. Reusability, tingkat kemampuan program/bagian dari program yang dapat dipakai ulang dalam aplikasi lainnya, berkaitan dengan paket dan lingkup dari fungsi yang dilakukan oleh program.
11. Interoperability, usaha yang diperlukan untuk menggabungkan satu sistem dengan sistem lainnya. 

Aktivitas-aktivitas SQA (SQA Activities) SQA terdiri dari berbagai jenis aktivitas yang terhubung dengan 7 aktivitas utama, yaitu :

1. Aplikasi metode-metode teknikal (Application of technical methods) Kualitas software didesain kedalam sebuah produk atau sistem. Pada kenyataannya SQA dimulai dengan sekumpulan metode teknikal dan tool yang membantu analis untuk mencapai spesifikasi dengan kualitas yang tinggi dan para perancang membangun desain yang berkualitas tinggi. 
2. Mengadakan review teknikal formal (conduct of formal technical reviews) Ketika spesifikasi (atau prototype) dan desain telah dibuat, maka masing-masing harus di perkirakan untuk kualitas. Aktivitas utama yang memenuhi penaksiran kualitas adalah formal technical review (FTR). FTR merupakan pertemuan khusus yang diadakan oleh staff teknikal dengan tujuan untuk menemukan masalah. Dalam berbagai situasi, review merupakan hal yang efektif seperti ujicoba dalam mengungkap kerusakan dalam software. 
3. Ujicoba perangkat lunak (software testing) Ujicoba software mengkombinasikan strategi beberapa tahapan/langkah dengan sejumlah desain metode uji kasus yang membantu memastikan pendeteksian kesalahan yang efektif. Banyak pengembang software menggunakan ujicoba software sebagai jaminan kualitas. 
4. Pelaksanaan standar (enforcement of standards) Tingkatan dimana prosedur dan standar formal diaplikasikan dalam proses pengembangan software, sangat bervariasi antara satu perusahaan dengan yang lainnya. Dalam banyak kasus, standar ditentukan oleh konsumen atau pembuat kebijakan. Jika standar disediakan(secara formal tertulis) maka aktivitas SQA harus dilaksanakan untuk memastikan standar-standar tersebut dilakukan. 
5. Pengawasan terhadap perubahan (control of change) Ancaman utama dalam kualitas software adalah perubahan yang dilakukan terhadap sumber. Setiap perubahan yang dilakukan pada software sangat potensial untuk menghasilkan kesalahan atau membuat efek sampingan yang mengakibatkan kesalahan. Proses pengawasan perubahan memberikan kontribusi secara langsung terhadap kualitas software dengan permintaan perubahan yang diformalkan. Pengawasan perubahan diaplikasikan selama pengembangan software dan setelahnya, atau selama tahapan pemeliharaan software.
6. Pengukuran (measurement) Pengukuran (measurement) merupakan aktivitas yang melengkapi setiap bidang pengembangan. Tujuan utama dari SQA adalah untuk menelusuri kualitas software dan memperkirakn pengaruh dari perubahansecara metodologi maupun prosedur pada peningkatan kualitas software. Untuk itu, ukuran-ukuran software (software metrics) harus dikumpulkan. 
7. Penyimpanan catatan dan laporan (record keeping and reporting) Penyimpanan catatan dan perekaman (record keeping and recording) pada SQA menyediakan prosedur untuk mengumpulkan dan penyebaran informasi SQA. Hasil dari review, audit, pengawasan perubahan, ujicoba, dan aktivitas SQA lainnyaharus menjadi bagian dari record history untuk proyek dan harus disebarkan untuk staff pengembangan untuk pengetahuan.

Staff Training and Sertification

Staff training and sertification

View more presentations from inggrid_5209100069.

Komponen Software Quality Assurance (SQA)

Berikut saya tampilkan slideshow PPT mengenai komponen SQA :

Komponen SQA

View more presentations from inggrid_5209100069.

Software Quality Metrics

Software quality metrics dikategorikan menjadi dua :

1. Product Metrics 
2. Product metrics 

Yang tiap kategori terdiri dari beberapa sub kategori. Berikut merupakan gambaran visualisasi untuk software quality metrics dalam bentuk mindmap nya. Semoga bermanfaat :)