Requirement Tracebility Matrix

Requirement Tracebility Matrix

Requirement Tracebility Matrix  (RTM) merupakan alat untuk membantu untuk memastikan bahwa ruang lingkup proyek , persyaratan, dan
delivery tetap "sebagaimana adanya" bila dibandingkan dengan baseline. Dengan demikian, "jejak" delivery dengan cara membentuk
thread untuk setiap kebutuhan dari inisiasi proyek untuk implementasi akhir.

Configuration Management

Configuration Management

Didalam menjalankan sebuah proyek, biasanya banyak masalah yang terjadi salah satunya adalah pada permasalahan manajemen konfigurasi. Biasanya kesalahan terjadi pada konfigurasi antara pengaturan versi perangkat lunak , pengaturan hasil dokumentasi perangkat lunak, dsb.
Perlu diperhatikan bahwa tidak ada perangkat lunak yang memang benar-benar bebas dari kesalahan, maka perangkat lunak terkadang memiliki versi. Pembaruan Versi perangkat lunak tersebut digunakan untuk memperbaiki kesalahan yang ditemukan pada versi sebelumnya. Jadi inti dari permasalahan di atas adalah bagaimana melakukan pengaturan pada perubahan perangkat lunak.
Manajemen Konfigurasi adalah serangkaian proses yang dilakukan guna membuat dan mempertahankan konsistensi kinerja suatu produk, desain, hingga operasionalnya.
Tujuan dari manajemen konfigurasi secara umum sebagai berikut :

• Untuk mengidentifikasi perubahan
• Untuk mengontrol perubahan
• Untuk memastikan perubahan telah dilaksanakan

 Laporan perubahan yang ditujukan untuk anggota, yang mana membutuhkan pengetahuan mengenai manajemen konfigurasi.
Perubahan yang dilakukan pada manajemen konfigurasi meliputi :

• Kode perangkat lunak
• Data (data testing dan file database)
• Dokumen dokumen yang terkait (SKPL, desain , jadwal proyek, rencana testing)

Beberapa faktor yang mempengaruhi keputusan dari perubahan yang akan diusulkan, antara lain :

• Tingkat kepentingan (urgency) dari perubahan.
• Besarnya kontribusi dari perubahan yang akan diusulkan.
• Pengaruh perubahan yang akan diusulkan pada jadwal proyek.
• Upaya yang diperlukan dalam membuat perubahan operasional.
• Regulasi pemerintah

Development and Quality Plan

Development and Quality Plan

Development merupakan mengenai tentang menjadi

sesuatu yang berbeda, apakah itu dalam pekerjaan  atau dalam hidup di luar pekerjaan. itu mencakup belajar dan melibatkan perubahan. Belajar keterampilan baru, sudut pandang baru, cara-cara baru menghadapi orang. Mengubah sudut pandang, mengubah cara bereaksi terhadap situasi, dan Berikut ini merupakan bagian elemen dari Development Plan, yaitu :

• Project products
• Project interfaces
• Project methodology and development tools
• SW development standards and procedures
• The mapping of the development process.
• Project milestones
• Project staff organization
• Development facilities
• Development risks
• Control methods
• Project cost estimation

Quality Plan
Merupakan proses sistematis yang menerjemahkan kebijakan mutu ke dalam tujuan yang terukur dan menetapkan urutan langkah-langkah untuk mewujudkannya dalam jangka waktu yang ditentukan.
Berikut ini merupakan bagian elemen dari Quality Plan, yaitu :

Quality goals

• Planned review activities (The scope of review activity, The type, The schedule ( priorities ), The specific, procedure to be applied , Who responsible for carrying out the rev. act. )
• Planned Software tests ( a complete list of planned SW tests should be provided ) each test (The unit, integration or the complete system to be tested , The type of testing activities to be carried out, The planned test schedule, The specific procedure, Who responsible)
• Planned acceptance tests for externally developed software
• Configuration management (change control procedures )

Documentation Control

Kontrol Dokumentasi

Kontrol dokumen merupakan sebuah langkah yang penting untuk melakukan proses pengembangan dan maintenance software.
Dimulai dari tahap persiapan hingga eksekusi semua dokumen harus dilakukan pengontrolan, dengan menggunakan prosedur pembuatan dokumen yang telah disepakati sebelumnya.
Salah satu bentuk dari kontrol dokumen yaitu quality records.
Quality records juga bisa dikatakan sebagai bukti kepedulian sebuah organisasi atau perusahaan terhadap kebijakan dan prosedur yang mereka miliki terhadap pemenuhan sebuah kualitas software.
 

Tujuan dari dokumen kontrol yaitu :

• Untuk menjamin kualitas dokumen yang dihasilkan
• Untuk menjamin kelengkapan teknis sesuai dengan prosedur struktur dokumen dan instruksi.
• Untuk keperluan di masa yang akan datang, dalam hal maintenance software
• Untuk mendukung dalam hal penyelidikan penyebab kegagalan sebuah perangkat lunak

SQA Komponen

 

1. Pre-project components
Tahap Pre-project components ini memiliki tujuan untuk meningkatkan tahap persiapan, dengan cara memahami prioritas-prioritas kebutuhan dari projek tersebut, sehingga yang dilakukan pada tahap ini ada 2 aktivitas yaitu Contract Review dan Development & Quality Plans.

• Contract Review

Kegiatan-kegiatan yang termasuk dalam contract review adalah mengklarifikasi kebutuhan dari pelanggan, melakukan review terhadap jadwal proyek dan estimasikan jumlah sumber daya yang dibutuhkan, evaluasi kapasitas dari professional staff untuk diusulkan ke dalam proyek, evaluasi kapasitas pelanggan untuk memenuhi kewajibannya, evaluasi  dari resiko-resiko yang ada

• Development and Quality Plans

Berkaitan dengan proposal proyek terhadap perencanaan kualitas terhadap sebuah proyek,setelah proposal tersebut ditanda tangani baru masuk pada tahap pengembangan dari perencanaan kualitas tersebut. Beberapa issue yang ditangani dalam project development plan adalah

• Schedules
• Required manpower and hardware resources
• Risk evaluations
• Organizational issues: team members, subcontractors and partnerships
• Project methodology, development tools, etc.
• Software reuse plans.

Beberapa issue yang ditangani dalam project quality plan adalah :

• Quality goals, expressed in the appropriate measurable terms
• Criteria for starting and ending each project stage
• Lists of reviews, tests, and other scheduled verification and validation activities.

2. Software Project Life Cycle components
Pada bagian ini terdiri dari 2 tahap :

• Tahap Development Life Cycle

Pada tahap ini bertujuan untuk mendeteksi desain dan error programming, pada tahap ini dibagi menjadi beberapa komponen yaitu Review (Formal design review, peer review) , Expert opinion ( quality assessment efforts), Software Tesing, Assurance of the quality of the subcontractor’s work and customer-supplied parts.

• Tahap Operation-Maintenance 

Tujuan utamanya secara fungsional adalah meningkatkan maintenance task.

3. Infrastructure Components for Error Prevention and ImprovementKomponen ketiga pada SQA memiliki tujuan utama melakukan pencegahan terhadap kegagalan suatu software, menurukan tingkat kegagalan software, dan meningkatkan produktifitas. Untuk mendukung tujuan-tujuan utama tersebut didalamnya terdapat Procedures and work instructions, Templates and checklists, Staff training, retraining and certification, Preventive and corrective actions, Configuration management, Documentation control

 

4. Management SQA ComponentKomponen ini berisi tentang :

Project Progress Control (termasuk Maintenance Contract Control) dimana berfokus pada penggunaan resource, schedule, manajemen resiko dan budget, Software Quality Metrics yang berisi pengukuran dari berbagai aspek kualitas software, Software Quality Cost
 

5. SQA Standards, System Certification, and Assessment ComponentsKomponen SQA yang kelima bertujuan untuk pemanfaatan pengetahuan professional eksternal, peningkatan koordinasi dengan organisasi lain yang berhubungan dengan kualitas system, mengevaluasi dan mengukur pencapaian dari kualitas system organisasi .Oleh karena tujuan tersebut pada komponen SQA berikut kita mengenal adanya Standards ,dimana standard dibagi menjadi 2 kelas yaitu Quality Management Standards (standard yang mengatur pengembangan software,maintenance dan infrastructure suatu software, contoh : ISO 9001) , Project Process Standards (menyediakan metodhological guidelines untuk tim pengembang)
 

6. Organizing for SQA – The Human ComponentsKomponen keenam dari SQA ini bertujuan untuk menginisiasi dan mendukung implementasi dari komponen SQA, mendeteksi penyimpangan dari SQA procedure  dan methodology-nya, menyarankan peningkatatan.SQA Organizational base meliputi Managers, Testing personnel, SQA unit and practioners interested in SQ

Staff Sertification

Proses untuk Training dan Sertifikasi yaitu :

1. Menentukan Persyaratan Pengetahuan Professional
Pada tahap ini seorang staff memperoleh pendidikan professional sementara ditambah dengan pengetahuan internal dan keterampilan yang dibutuhkan oleh organisasi

2.Menentukan professional training dan memperbarui kebutuhan
Ada beberapa kebutuhan yang dibutuhkan yaitu pelatihan untuk karyawan baru, pelatihan ulang untuk karyawan yang ditugaskan untuk posisi baru, professional update untuk staff lainnya

3.Merencanakan program pelatihan, merencanakan program pembaharuan (update)
Perencanaan training dan updating program meliputi penggunaan tim “House Training” dan fasilitas atau dengan outsource, menggunakan program e-learning untuk pelatihan

4.Tentukan posisi yang memerlukan sertifikasi
Beberapa posisi yang dibutuhkan dalam sertifikasi adalah Software Developmant team leader, Programming Team Leader, Software Testing Team Leader.

5.Rencana proses sertifikasi
Untuk menyediakan kerangka kerja untuk penyelidikan secara menyeluruh terhadap kualifikasi dari kandidat

6.Memberikan pelatihan, memperbarui dan sertifikasi program

Dengan memberikan pelatihan, diharapkan para karyawan dapat lebih mengerti dan mendalami tentang program yang dikerjakan
 

7.Lakukan tindak lanjut dari staff yang terlatih dan bersertifikat.

Tindak lanjut yang dilakukan dapat berupa memberikan studi kasus untuk melatih kemampuannya.

Software Testing

Software Testing

Software testing dapat diartikan sebagai serangkaian proses yang digunakan untuk membantu mengverifikasi dan mengvalidasi perangkat lunak yang dihasilkan dari proses developing. Proses inti yang dilakukan adalah mengevaluasi dan memastikan apa yang dihasilkan dalam pengembangan perangkat lunak sesuai dengan apa yang diinginkan dan sudah sesuai dengan kebutuhan. Testing ini dilakukan hingga akhir proses pengembangan perangkat lunak untuk menentukan apakah yang dibuat sudah benar. Testing ini memang dapat dikorelasikan dengan “requirement tracebility matrix” atau RTM karena dengan adanya hasil testing ini maka developer dapat memastikan kembali dengan kebutuhan yang telah dicantumkan pada dokumen plannig pada fase inisiasi project.

Pada dasarnya software testing terbagi atas 2 macam, antara lain :

Blackbox Testing
Blackbox Testing adalah proses mengidentifikasi bugs ataupun error berdasarkan pada gangguan yang terlihat pada fungsi outputnya atau interface. Dengan kata lain yang diperiksa hanyalah jalannya fungsionalitas perangkat lunak tersebut, dan  mengabaikan penyebab kesalahan dalam program dalam codenya. keuntungan dari black box memungkinkan tester melakukan semua test pada setiap modul, dan kekurangan dari black box sendiri adalah lemahnya proses pengidentifikasian gangguan dari code.  

Whitebox Testing
Whitebox Testing merupakan proses mengidentifikasi kesalahan bugs atau error pada internal program (code). kelebihan dapat melakukan didalam program untuk mengetahui apa yang menyebabkan error yang di karenakan oleh code, kekurangannya adalah membutuhkan banyak resource karena yang dianalisa adalah setiap baris code yang dihasilkan.

Costs of Software Quality

Costs of Software Quality

Secara umum Cost of software quality memungkinkan manajemen untuk mencapai kontrol ekonomi terhadap kegiatan SQA dan hasilnya dan secara khusus tujuannya adalah:

§ Sebagai evaluasi rencana untuk menambah atau mengurangi aktivitas SQA atau untuk berinvestasi dalam infrastruktur SQA berdasarkan history kinerja ekonomi yang telah terjadi.

§ Sebagai Kontrol organisasi yang dimulai untuk mencegah dan mendeteksi kesalahan perangkat lunak.

§ Sebagai evaluasi kerusakan ekonomi dari kegagalan perangkat lunak yang mana dasar untuk merevisi anggaran SQA.

Bagaimana manajerial dapat mengontrol biaya kualitas perangkat lunak?

Kontrol manajerial atas biaya kualitas perangkat lunak ini dicapai dengan perbandingan kinerja aktual dengan:

-          Mengontrol pengeluaran yang dianggarkan (untuk pencegahan SQA dan penilaian kegiatan)

-          Biaya kegagalan tahun-tahun sebelumnya

-          Biaya kualitas proyek-proyek sebelumnya (kontrol biaya dan biaya kegagalan)

-          Biaya kualitas departemen-departemen lain (kontrol biaya dan biaya kegagalan)

Didalam penjelasana ini, Anda akan diperkenalkan dua model biaya kualitas perangkat lunak.

-          Model Klasik

-          Model Lanjutan

Model Classic Biaya Kualitas Perangkat Lunak

·         Model ini dikembangkan pada awal 1950-an oleh Feigenbaum et al.

·         Menyediakan metodologi untuk mengklasifikasi biaya yang berkaitan dengan jaminan kualitas produk dari sudut pandang ekonomi

·         Dikembangkan untuk memenuhi situasi kualitas yang ditemukan dalam organisasi manufaktur

Model ini mengklasifikasikan biaya yang berkaitan dengan kualitas produk menjadi dua kelas umum:

 

Cost Control : Kontrol biaya yang dihabiskan untuk pencegahan dan pendeteksian kesalahan perangkat lunak untuk mengurangi resiko.

 Cost Failur : Biaya kegagalan yang disebabkan karena kegagalan untuk mencegah dan mendeteksi kesalahan perangkat lunak.