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.

Proccess Metrics

Proccess Metrics

Product Metrics

Product Metrics

Product operation software quality factors

Product operation software quality factors

Sumber :

PEMBUATAN APLIKASI PERHITUNGAN TARIF PREMI ASURANSI UNTUK KARGO ANGKUTAN LAUT: STUDI KASUS DI PERUSAHAAN ASURANSI TUGU PRATAMA INDONESIA CABANG SURABAYA

Latar Belakang

Dalam sebuah tingkatan perusahaan asuransi terdapat bagian tarif premi yang sangat dibutuhkan oleh pembuatan keputusan. Perusahaan Asuransi PT. Tugu Pratama Indonesia cabang Surabaya merupakan salah satu perusahaan asuransi terhadap suatu perusahaan bukan individu. Pemberian tarif premi ini sangat berpengaruh pada perputaran uang yang dilakukan oleh perusahaan asuransi tersebut dengan demikian pemutusan besar kecilnya statu tarif premi asuransi akan sangat penting. Perhitungan ini sangat dibutuhkan pada sistem dikarenakan resiko yang muncul akibat dari persetujuan dan tarif premi asuransi tersebut. Resiko yang muncul yaitu terjadinya klaim asuransi yang disebabkan karena kerusakan dan kerugian yang disebabkan oleh alam atau faktor-faktor lainnya. Penggunaan perhitungan tarif premi asuransi dalam perusahaan sangat dibutuhkan untuk menghitung faktor-faktor apa saja yang diperlukan oleh perusahaan dalam menentukan besar kecilnya tarif premi.  


Tujuan Pembuatan Aplikasi 
Tujuan dibuatnya Aplikasi Perhitungan Tarif Premi Asuransi adalah untuk mengelola dan mengkomputerisasi tarif premi asuransi sehingga akan semakin dapat mengikuti perkembangan jaman yang mengarah ke paperless serta agar dapat dimanfaatkan sebaik-baiknya oleh pihak manajemen dan pembuat keputusan. Aplikasi sistem pendukung keputusan untuk pihak manajemen yang digunakan untuk menentukan jumlah premi yang harus dibayar oleh pelanggan/klien. Sistem yang akan diimplementasikan ini diharapkan mampu menjadi salah satu sumber informasi yang dibutuhkan pihak manajemen untuk menjalankan tugasnya sebagai pemberi keputusan untuk penentuan tarif premi asuransi.

Usability

Usability berurusan dengan ruang lingkup sumber daya staf yang diperlukan untuk melatih karyawan baru dan untuk mengoperasikan sistem perangkat lunak.

Dalam Studi kasus disini untuk menggunakan aplikasi perlu adanya pelatihan yang dilakukan karena disini merupakan sebuah aplikasi baru yang mana membutuhkan pengetahuan baru untuk menjalankannya. Tidak perlu menambahkan resource baru karena yang baru disini adalah sistemnya sehingga hanya perlu adanya pelatihan penggunaan aplikasi.

Integrity

Integrity  berhubungan dengan keamanan sistem perangkat lunak, yaitu persyaratan untuk mencegah akses dari orang yang tidak berhak, untuk membedakan antara mayoritas personil yang diizinkan untuk melihat informasi dan kelompok yang ijinya terbatas dan mengubah data.

Dalam studi kasus untuk akses controlnya ada dua user yaitu administrator dan Producer/Insured. Untuk administrator merupakan seorang aktor yang berinteraksi dengan aplikasi bertugas mendaftarkan seorang klien dan pengguna. Administrator juga dapat mengubah, menambah serta menghapus asuransi sampul terbuka. Insured adalah seorang aktor yang menggunakan aplikasi ini, insured yaitu tertanggung. Producer yaitu seorang aktor yang merupakan penengah antara penanggung dan tertanggung. Producer/insured dapat dikatakan sebagai klien atau pengguna dalam penggunaan aplikasi ini.

1. Roodhin Firmana    (5209100050)
2. Hendra Prasetya     (5209100126)

Causes of Software Errors

Causes of Software Errors

Procedure Error

Prosedur eror merupakan sebuah proses atau tahapan-tahapan yang dapat membuat suatu software menjadi eror. Kesalahan atau eror disini dapat mempengaruhi suatu software baik itu ketika awal proses ataupun juga ketika diakhir sebuah proses. Ketika tahapan-tahapan tersebut salah kita jalankan maka program akan memberikan peringatan yang bertujuan mengingatkan bahwa tahapan-tahapan yang kita lakukan tidak sesuai. Sehingga biasanya prosedur selalu memberikan panduan untuk menanggulangi terjadinya prosedur eror.

Procedure Erorr pada Microsoft Office 2010 Beta
(Activation Failure with Code Error : 0x8007232B)

Beberapa waktu lalu Microsoft corp, merilis sebuah versi terbaru  software office-nya yaitu Microsoft office 2010 Beta. Pada versi beta ini user akan dapat mencoba menggunakan fitur-fitur office terbaru secara free pada versi beta ini.

Studi kasus:

Pada kasus ini akan dipaparkan suatu kasus, dimana seorang user yang mengalami kesalahan dalam melakukan aktivasi produk Microsoft Office 2010 Beta. Kronologi yang dilakukan user tersebut sebagai berikut.

Seorang user telah menginstal software Microsoft Office 2010 Beta. User mencoba membuka salah satu fungsi office (misal Microsoft Word 2010), setelah Microsoft Word tersebut terbuka muncul pesan dengan mencantumkan kode erorrnya : 0x8007232B serta diminta  untuk memasukkan product key. Produk Key tersebut dapat diisikan dengan kode MAK (Multiple Activation Key), yang mana MAK tersebut dapat merupakan kode aktifasi yang dapat dipakai banyak user. Setelah memasukkan kode MAK tersebut, muncul pesan erorr kembali yang berisi aktifasi Microsoft Office 2010 Beta gagal dilakukan. Lantas user melakukan restart software, namun tetap saja muncul pesan kegalgalan aktifasi tersebut. Hingga pada waktu tersebut user memutuskan melakukan uninstal dan menginstal kembali, namun hal tersebut belum berhasil dan menghasilkan pesan yang sama (kegagalan aktifasi).

Solusinya:

User mencari solusi dan akhirnya menemukannya, ternyata ada salah satu proses aktifasi yang belum terpenuhi. Kesalahan prosedur menjadi hal klasik, namun menjadi penyebab utamanya. Berikut ini merupakan proses aktifasi yang harus dilakukan:

1. Instal terlebih dahulu Microsoft Office 2010.
2. Pastikan pula tidak ada Aplikasi Microsoft Office 2010 yang terbuka (aktif).
3. Masuk pada menu Start > Control Panel > Programs > Programs and Features.
4. Klik kanan pada program Microsoft Office 2010 dan pilih Change.
5. Maka akan muncul pilihan, lalu pilih Enter a Product Key > klik Continue.
6. Masukkan kode MAK, lalu akan berlangsung proses validasi MAK.
7. Lalu klik Continue.
8. Coba anda buka salah satu aplikasi Microsoft Office (Misal Microsoft Office Word), maka akan muncul jendela Microsoft Office Activation Wizard. Langkah ini mengharuskan anda aktifasi secara online. Karena apabila tidak di aktifkan, maka akan berlaku hanya 30 hari saja. Klik Next (pastikan komputer anda terkoneksi internet).
9. Muncul progress bar Connecting, tunggu hingga muncul notifikasi aktifasi berhasil
10. Setelah selesai, tutup aplikasi Microsoft Word dan restart kembali aplikasi tersebut.
11. Buka tab File > Help sudah ada tulisan Product Activated.

Anggota Kelompok :

1. Roodhin Firmana     (5209100050)
2. Hendra Prasetya      (5209100126)

Software Quality Challenge

Software Quality Challenge
Untuk mengetahui lebih jelas seperti apakah software quality challenge bisa dilihat disini

Software Quality Challenge on Prezi