Cost of Software Quality

Project Progress Control

Documentation Control

Configuration Management

Review

Integrating SQA to PLC

Contract Review

The components of the software quality assurance system – overview

Development and Quality Plans

Staff Training and Certification

Software Testing

Untuk menjaga kualitas sebuah software, maka developer harus dilakukan testing terhadap software tesebut. Secara umum ada 2 jenis testing, yaitu white box testing dan black box testing. Berikut adalah penjelasan singkatnya.

Supporting Quality Devices

Pentingnya Manajemen

Solusi Laptop Panas

Laptop Anda panas, ini solusinya. Dijamin laptop Anda bebas panas dan AWET sepanjang masa.

Function Point

Pengertian Function Point

Function Point dikembangkan pertama kali oleh Allan J. Albrecht di pertengahan tahun 1970-an. Merupakan upaya untuk mengatasi kesulitan yang berhubungan dengan kode program sebagai ukuran dari ukuran perangkat lunak, dan untuk membantu dalam memprediksi effort dalam development perangkat lunkas.

Function Point pertama kali di terbitkan pada tahun 1979. Pada tahun 1984 Albrecht menyempurnakan metode Function Point.

Sejak Function Point Internasional User Group (IFPUG) didirikan, beberapa versi Function Point sebagai Pedoman telah diterbitkan oleh IFPUG. Secara global pengukuran Software dengan Function Point telah diterima secara luas dalam industri perangkat lunak lebih dari 40 tahun sebagai pengukuran standar perangkat lunak.

Nilai dari funtion point nantinya digunakan untuk mengetahui ukuran software yang akan dibuat, sehingga nantinya akan dapat diketahui estimasi biaya dalam memproduksi software tesebut.

Cara Menghitung Function Point

Berikut adalah beberapa langkah untuk menghitung nilai function point:

1. Hitung Nilai Crud Function Point

Crude Function Points (CFP) adalah untuk menghitung bobot nilai dari komponen-komponen Function Point yang dikaitkan dengan software yang akan dibuat.

Komponen-komponen Function Point terdiri dari 5 buah yaitu sebagai berikut.

• Tipe Input, Berkaitan dengan interface yang lakukan pengguna/user dalam memasukan data pada aplikasi.
• Tipe Output, Berkaitan dengan output yang dihasilkan aplikasi untuk pengguna/user yang dapat berupa laporan di print atau yang ditampilkan pada layar.
• Tipe Query/Search/View, Berkaitan dengan query terhadap data yang tersimpan.
• Tipe File/Tabel/Database, berkaitan dengan logic penyimpan data yang dapat berupa file atau semacam database relational.
• Tipe Interface Eksternal, Berkaitan dengan komunikasi data pada parangkat/mesin yang lain, contoh nya adalah membuat aplikasi SMS Server yang membutuhkan. koneksi pada perangkat keras Modem telepon.

Selanjutnya setiap tipe komponen tersebut diberikan bobot berdasarkan kompleksitasnya, seperti yang ditujukan pada table dibawah ini.

• Nilai-nilai Bobot dari setiap komponen diatas adalah ketetapan atau konstanta yang dibuat oleh Function Point Internasional User Group (IFPUG)

Requirement Traceability Matrix (RTM)

Requirements traceability matrix (RTM) ialah tabel yang berisi daftar requirements, atribut yang bervariasi untuk setiap requirement, dan status dari requirement untuk memastikan semua requirement telah terpenuhi. Dengan RTM kita bisa melakukan trace terhadap setiap requirement yang ada, mulai dari business requirement samapai pada testing. Ada banyak sekali tempalate RMT yang beredar di dunia maya. Namun RTM tersebut harus disesuaikan dengan kebutuhan kita. Tujuan utama dari RTM adalah agar semua anggota project mengetahui requirement yang ada.


Reqirement Treacibility Matrix digunakan dalam Quality Assurance sehingga dapat memastikan bahwa kebutuhan klien terpenuhi, dan perangkat lunak sesuai dengan yang diminta.



Siapa yang mengisi RTM?
Yang mengisi RTM adalah semua anggota project, mulai dari analist, programmer samapai dengan tester.


Bagaimana Kriteria RTM yang baik?

1. Berikut adalah beberapa saran dari saya agar RTM yang kita buat baik dan mudah digunakan.
2. Buat sebuah template RTM yang mudah dipahami oleh seluruh anggota proyek
3. Usahakan kolom-kolom yang ada pada RTM urut sesuai dengan fase proyek yang ada. Contoh: Biasanya testing dilakukan di akhir, maka kolom untuk tescase diletakkan di akhir tabel.
4. Berikan ID untuk setiap riquirement
5. Untuk proses selanjutnya, usahakan ada keterkaitan dalam penamaan ID, hal ini akan memudahkan kita dalam melakukan trace RTM

Contoh RTM
Berikut adalah contoh RTM.

Ketika Programmer Sejati Memperoleh Hukuman

Patut ditiru, hahaha ^_^

Architecture of SQA

Arsitektur SQA adalah

Pada arsitektur SQA terdapat 6 komponen, diantaranya:
1.       Pre-Project Component
2.       Software project life cycle components
3.       Component of infrastructure error prevention and improvement
4.       Management SQA component
5.       Components of standardization, certification, and SQA system assessment
6.       Organizing for SQA – The human component

1.       Pre-project components

Tahapan ini adalah tahapan awal sebelum memulai proyek, yang harus dilakukan oleh pihak developer adalah:

• Contract review

Bertujuan untuk mengembangkan software melalui kerangka negosiai kontrak dengan pelanggan. Sehingga melalui Review kontrak dapat disepakati kebutuhan apa yang diperlukan dalam proses pengembangan perangkat lunak.
Aktifitas kontak review, meliputi:
o   Klarifikasi kebutuhan pelanggan
o   Review jadwal proyek dan perkiraan kebutuhan sumber daya
o   Evaluasi kapasitas staf profesional untuk melaksanakan proyek
o   Evaluasi kapasitas pelanggan untuk memenuhi kewajibannya
o   Evaluasi risiko pengembangan.

• Development and quality plans

Setelah proposal proyek selesai ditinjau, lalu kontrak telah di tandatangani. Maka tahap selanjutnya menyusun Development and quality plans. Berikut merupakan hal-hal yang harus dipersiapkan:
Tantangan utama dalam mengatur pengembangan proyek , yaitu:
·         Jadwal
·         Tenaga kerja yang diperlukan dan sumber Hardware
·         Evaluasi Resiko
·         Keorganisasian : anggota tim, subkontraktor dan kemitraan
·         Metodologi proyek, perangkat pengembangan,dll
·         Penggunaan kembali rencana software

Tantangan utama dalam mengatur rencana kualitas proyek, yaitu :
·         Pencapaian akhir kualitas
·         Kriteria awal dan akhir setiap tahap proyek
·         Daftar review, tes dan jadwal verifikasi lainnya serta kegiatan validasi

Software yang Berkualitas

Seperti apa sih software yang berkualitas itu? Apa sekedar software yang bebas dari bug? Sebenarnya ada banyak pendapat dari para ahli yang mendefinisikan kapan sebuah software itu dikatakan berkualitas. Wah kalau banyak seperti ini, kita juga yang repot, pendapat siapa yang kita jadikan pegangan hidup??? Namun itulah indahnya perbedaan.

Disini saya akan memaparkan sedikit mengenai ciri-ciri software yang berkualitas menurut McCall. McCall mendefinisikan ada 11 faktor yang mempengaruhi kualitas dari sebuah software, yaitu:

1. Portability
2. Reusability
3. Interoperability
4. Correctness
5. Reliability
6. Efficiency
7. Integrity
8. Usability
9. Testability
10. Flexibility
11. Maintability

Nah, ke-sebelas faktor ini disebut MacCall's factor model tree, yang dapat divisualisasikan sebagai berikut.

Software Metrics

Software Quality Metrics

Untuk memastikan kualitas dari pernagkat lunak yang kita bangun, pastinya kita harus melakukan pengukuran. Pengukuran ini bisa kita sebut dengan istilah metrics. Pengukuran-pengukuran tersebut bisa dari segi bug software, keefektifan human resource, kecepatan dalam pemebenah error dan lain-lain. Secara garis besar ada 2 pengukuran (metrics) yang ada, yaitu process metrics dan product metrics. Penjelasan secara singkat divisualisasikan pada gambar berikut:

Users VS Programmers ^_^

Bagaimana dengan Anda?

Ulah Manusia

Beginilah ulah kita, yang membuat kerusakan di bumi ini.

Software Quality Factors

Banyak sekali hal yang dapat mempengaruhi kualitas sebuah software. Namun Mc Call membagi faktor-faktor yang mempengaruhi kualitas perangkat lunak menjadi 11 faktor:

• Product operation factors: Correctness, Reliability, Efficiency, Integrity, Usability.
• Product revision factors: Maintainability, Flexibility, Testability.
• Product transition factors: Portability, Reusability, Interoperability.

Pada artikel ini, saya akan membahas dua faktor dari 11 faktor tersebut, yaiut Efficiency dan testability. Penjelasan dan studi kasusnya adalah sebagai berikut:

Review TA : software quality factors

View more presentations from seyfert130.

Faulty Requirement Definition

Salah satu penyebab besar dari kegagalan perangkat lunak adalah kesalahan dalam mendefinisika kebutuhan (Faulty Requirement Definition). Banyak hal yang dapat mempengaruhi kesalahan dalam mendefinisika kebutuhan. Sehingga banyak pakar yang mendefinisikan metode-metode untuk mengidentifikasi kebutuhan perangkat lunak.

Faulty requirement definition

View more PowerPoint from seyfert130

Software Quality Challenge

Jaminan Kualitas Perangkat Lunak (Software Quality Assurance) atau biasa disingkat SQA adalah 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.

Namun dalam melakukan jaminan kualitas terhadap sebuah perangkat lunak tidaklah mudah. Banyak sekali tantangan yang dihadapi para pengembang. Berikut penjelasan singkat mengnai tantangan dalam SQA.

Jaminan Kualitas Perangkat Lunak

--Selayang pangdang SQA--

Jaminan Kualitas Perangkat Lunak (Software Quality Assurance) atau biasa disingkat SQA adalah 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.

Pembahasan Secara menyeluruh Mengenai SQA akan saya paparkan lebih detail pada POSTING berikutnya. ^_^