Senin, 27 Mei 2013

Document Control in SQA

Sebuah pengembangan suatu aplikasi atau perangkat lunak bukanla hal yang singkat dan mudah. Butuh sumberdaya berupa waktu, manusia serta berbagai kebutuhan. Tidak jarang perangkat lunak yang kompleks membutuhkan banyak tenaga manusia yang pastinya juga membutuhkan manajemen yang baik pula.
                Permasalahan yang sering timbul selama masa pengembangan perangkat lunak adalah masalah waktu pengerjaan, orang – orang yang keluar dan masuk dalam tim, budgeting, dsb. Salah satu factor utama yang menjadi kesulitan utama adalah perihal pendokumentasian. Dokumentasi yangtidak teratur menjadi penyebab utama molornya pengerjaan, tidak adanya progress, bahkan ketidaksesuaian antara code dan design serta permintaan pelanggan.
                Dokumentasi sangatlah penting dalam proses pembuatan suatu perangkat lunak karena selain memberikan informasi serta data, dapat pula menjadi alat untuk control proses pengerjaan perangkat lunak. Dalam penyusunan dokumen control yang baik pun perlu dipertimbangkan beberapa standar yang umum digunakan yakni :
-          ISO 9000-3
-          ISO (1997)
-          ISO/IEC (2001)
-          IEEE / EIA
Berbicara mengenai dokumen control adalah juga salah satu aspek pengelolaan kualitas dari perangkat lunak itu sendiri, Karena dokumentasi memastikan semua berjalan sesuai dengan rencana. Berikut beberapa tujuan utama dari pengelolaan dokumen control :
1.       Memastikan kualitas dari dokumentasi proyek
2.       Memastikan kelengkapan dan kebenaran struktur dokumen, prosedur, serta instruksi
3.       Mendukung investigasi dan pendeteksian kesalahan dalam pengembangan
4.       Memberikan kemudahan dalam maintenance, pengembangan perangkat lunak kedepan
Ada beberapa jenis dokumen control yang biasa digunakan dalam proses pendokumentasian, yakni
-          Pre-project document :
o   Contract review
o   Software development contract
o   Software development plan
-           Project life cycle documents
o   System requirements document
o   Software requirements document
o   Preliminary design document
o   Critical design document
o   Database description
o   Software test plan
o   Design review report
o   Follow-up records of design review action items
o   Software test procedure
-          SQA infrastructure documents :
o   SQA procedure
o   CAB meeting minutes
-          Quality management
o   Progress report
o   Software metrics report
-          Customer documents
o   Project tender dokumen
o   Change request
Berikut beberapa tahapan dalam merencakan dan membuat dokumen control :
1.       Memutuskan tipe – tipe dokumen mana saja yang kita butuhkan untuk quality record yakni dokumentasi kualitas
2.       Mendefinisikan level dari control
3.       Follow up kebenaran dari pengerjaan dengan perencanaan, bisa berupa quality audits plan

4.       Analisa adanya update, change dan perubahan apapun

Development and Quality Plans


Development Plan dibutuhkan sebagai penjadwalan untuk aktivitas development, mulai dari completion time, budget, resources. Dibutuhkan dalam menyelesaikan resiko dan sebagai proyek control. Adapun 11 elements dari Development Plan yaitu:
1.       Project products
2.       Project interfaces
3.       Project methodology and development tools
4.       SW development standards and procedures
5.       The mapping of the development process
6.       Project milestones
7.       Project staff organization
8.       Development facilities
9.       Development risks
10.   Control methods
11.   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. Adapun 5 element dari Quality Plan yaitu:
Quality goals
Tujuan kualitas (quality goals), dapat dilihat sebagai tingkatan kinerja yang hendak dicapai.
Planned review activities
Pada tahapan ini terdapat tahap-tahap yang harus dilakukan untuk menghasilkan rencana yang berkualitas yaitu:
  • Menentukan scope
  • Menentukan jenis kegiatan yang dilakukan
  • Menentukan jadwal kegiatan proses proyek
  • Menentukan prosedur yang akan diterapkan
  • Menentukan siapa yang bertanggung jawab untuk melakukan kegiatan review.
Plan SW test
Plan testing software yang harus dilakukan meliputi:
  • Unit, integrasi atau sistem untuk diuji.
  • Jenis kegiatan pengujian yang akan dilakukan.
  • Jadwal direncanakan uji.
  • Siapa yang bertanggung jawab untuk melaksanakan ujian.
  • Spesifik prosedur yang harus diterapkan.
Planned acceptance tests for externally developed software
Configuration management

Senin, 25 Maret 2013

Detailed : Analisa Software Quality Factor pada RANCANG BANGUN SISTEM PENILAIAN TINGKAT KESEHATAN LEMBAGA KEUANGAN MIKRO SYARIAH (NON-BANK) DENGAN METODE PEARLS

Yap, sebelumnya kita telah ulas kebutuhan fungsional serta non fungsional dari

RANCANG BANGUN SISTEM PENILAIAN TINGKAT KESEHATAN LEMBAGA KEUANGAN MIKRO SYARIAH (NON-BANK) DENGAN METODE PEARLS


berikut merupakan file detail dari ulasan dan korelasi dengan Software Quality Factor ala Mc'Calls

http://www.ziddu.com/download/21881986/DetailedPengukuranSoftwareQualityFactor.pdf.html

Kamis, 14 Maret 2013

Model McCall


Model ini merupakan model kualitas tertua yang dikembangkan pada tahun 1976. Model ini digunakan dengan tujuan agar sebuah kualitas dapat diukur secara eksplisit dengan menjelaskan 11 faktor kualitas atau karakteristik yang memiliki pengaruh penting terhadap kualitas. Faktor-faktor tersebut antara lain :

Product Revision (Kemampuan untuk mengalami perubahan)
·         Maintainability
      Usaha yang dibutuhkan untuk menempatkan dan menyelesaikan kesalahan program dalam lingkungan  
      operasi
·         Flexibility
      Kemudahan membuat perubahan yang butuhkan oleh perubahan dalam lingkungan pengoperasian
·         Testability
      Kemudahan pengujian program, untuk meyakinkan bahwa program bebeas error dan memenuhi 
      spesifikasinya
Product Transition (Beradaptasi pada lingkungan yang baru)
·          Portability
       Usaha yang dibutuhkan untuk memindahkan program dari satu lingkungan ke lingkungan lain
·         Reusability
      Kemudahan penggunaan kembali osftware dalam konteks yang berbeda.
·         Iteroperability
      Usaha yang dibutuhkan untuk memasangkan sistem dengan sistem yang lain

Product Operations (Karakteristik pengoperasian)
·         Correctness
      Tingkatan dimana software mencapai spesifikasinya
·         Reliability
      Kemampusan sistem untuk tidak gagal
·          Efficiency
       Efisien dalam eksekusi dan penyimpanan. Umumnya diartikan penggunaan resource, seperti: waktu 
       processor, memori, dsb.
·          Integrity
       Perlindungan program dari akses yang tidak berkepentingan
·          Usability
       Kemudahan penggunaan software

Studi Kasus
Menganalisis salah satu aplikasi yang dirancang dari hasil tugas akhir mahasiswa Sistem Informasi ITS dengan Judul “Rancang Bangung Sistem Informasi untuk Monitoring Mobilisasi Penduduk Bedasar Nomor Induk (NIK)” bedasarkan pada 11 faktor yang ada pada Metode McCall.
·         Kebutuhan Fungsional yang ada pada Software
  • UC.01 : Login
  • UC.02 : Logout
  • UC.03 : Mengirim Data Penduduk
  • UC.04 : Mencari Lokasi Penduduk
  • UC.05 : Mencari Lokai Penduduk Bedasarkan NIK
  • UC.06 : Mencari Lokasi Bedasarkan Tanggal Tinggal
  • UC.07 : Menambah Tamu Inap
  • UC.08 : Membuat Surat Pengantar
  • UC.09 : Mencetak Surat Pengantar
  • UC.10 : Menambah Data Penduduk
  • UC.11 : Menghapus Data Penduduk

·         Kebutuhan Non-Fungsional
   
  Usability
  • Adanya Use case untuk mencari data sehingga akan jauh lebih mempermudah pengguda dalam       pencarian data.
  • Tampilan antarmuka aplikasi User Friendly.

o   Safety
  • Setiap user memilik account untuk memasukkan data.
  • Sementara itu untuk menghindari penggunaan sistem oleh pihak yang tidak memiliki hak, digunakan sistem password. Dimana masing-masing user diharuskan mengisikan username dan password terlebih dahulu.

o   Reliability and up-time requirement
  •  Adanya back up data secara berkala untuk keamanan data.

o   Supportability and operability requirement
  •  Panduan penggunaan Aplikasi

-      Korelasi dengan Software Quality Factor


1
correctness
Use Case yang telah diuji dengan menggunakan test case telah sesuai dengan kebutuhan yang diinginkan.
2
Usability
Aplikasi telah teruji dan berjalan dengan baik dapat dilihat pada test case.
3
Reliability
Keamanan dalam penyimpanan data telah teruji dengan testcase terhadap SQL injection
4
Efficiency
Bahasa yang diginakan dalam pembuatan aplikasi ini adalah dengan menggunakan bahasa pemprograman java, javascript, HTML.
5
Integrity
Uji keamanan telah terbukti dan di uji.
6
Maintainability
Adanya back up data secara berkala.
7
Testability
Aspek ini telah terpenuhi karena untuk kebutuhan fungsional dan non-fungsional telah di uji.
8
Flexibility
Tidak ada keterangan untuk aspek ini
9
Portability
Pada dokumen, software dapat berjalan pada spesifikasi dan ketentuan tertentu.
10
Interoperability
Pada dokumen telah dijelaskan bahwa aplikasi ini dapat berjalan sesuai dengan minimal dan ketentuan spesifikasi yang telah di jabarkan.
11
Reusability
Tidak ada keterangan untuk aspek ini.

Senin, 11 Maret 2013

Pengukuran Software Quality Factor ‘ala’ MC Calls pada RANCANG BANGUN SISTEM PENILAIAN TINGKAT KESEHATAN LEMBAGA KEUANGAN MIKRO SYARIAH (NON-BANK) DENGAN METODE PEARLS



                Mc Calls model merupakan sebuah model pengukuran yang menjelaskan tentang factor – factor penentu kualitas software atau perangkat lunak. Model ini bias dikatakan yang tertua karena telah ada dan dikembangkan pada tahun 1976.
             Awalnya model ini dibuat untuk menjawab kurang jelasnya kebutuhan yang dijelaskan dalam pembuatan software entah itu Kebutuhan FUngsional maupun non fungsional.berupa 11 factor – factor penentu kualiats dari sebuah perangkat lunak yang dikembangkan. Apa sajakah Factor – factor tersebut?

mc call's model
product operation merupakan karakteristik dari operasional system atau software yang dibangun dimana terdiri atas :
- correctness,      : kesesuaian antara perangkat lunak sesuai dengan spesifikasi yang ada
- usability,           : kegunaan dan kemampuan software untuk dapat digunakan oleh manusia,
- reliability,          : kemampuan untuk dapat memberikan layanannya, apakah gagal atau mampu
- efficiency,         : Code, pemrogaman, OS , aksesibilitas dan operasional dari Sofware apakah efisien atau   tidak
- integrity            : ketangguhan dan keamanan dari system itu sendiri
product revision merupakan karakteristik dan kemampuan untuk mengalami perubahan yang terdiri atas :
 - maintainability                 : kemampuan software atau usaha user untuk pemeliharaan dan juga untuk memperbaiki kegagalan
- testability,                        : berkaitan tentang pengujian system dengan operasionalnya untuk memastikan kebutuhan terpenuhi
- flexibility                           : kemampuan dan usaha yang dilakukan untuk dapat melakukan pengembangan
product transition merupakan karakteristik untuk dapat diterapkan di lingkungan baru, yanh terdiri atas:
 - portability,                      : kecenderungan untuk dapat adaptasi dengan lingkungan yang berbeda
- reusability,                       : kemampuan akan transfer fungsi atau program untuk aplikasi lainnya
- interoperability                 : antar muka dengan system atau software lainnya

Lalu, setelah mengetahui factor pada MC Calls, kita akan bahas salah satu rancang bangun perangkat lunak yang dilakukan oleh alumni Sistem Infofmasi yakni RANCANG BANGUN SISTEM PENILAIAN TINGKAT KESEHATAN LEMBAGA KEUANGAN MIKRO SYARIAH (NON-BANK) DENGAN METODE PEARLS

Kita akan melihat dari kebutuhan fungsional dan non-fungsional korelasi antara keduanya dengan Mc Calls factor. Berikut merupakan kebutuhan Fungsional dari software diatas :
-          Pengelolaan Sistem
o    UC-01.01 : Login
o    UC-01.02 : Logout
-          Pengelolaan akun
o     UC-02.01 : Lihat Daftar Pengguna LKM/S
o     UC-02.02 : Tambah Pengguna Baru LKM/S
o     UC-02.03 : Ubah Pengguna LKM/S
o     UC-02.04 : Hapus Pengguna LKM/S
-          Pengelolaanmaster data
o     UC-03.01 : Tambah Inflasi
o     UC-03.02 : Hapus Inflasi
o     UC-03.03 : Tambah Tahun
o     UC-03.04 : Hapus Tahun
-          Pengelolaan data laporan keuangan
o     UC-04.01 : Isi Form Data Laporan
o     UC-04.02 : Ubah Data Laporan
-          Pengelolaan hasil penilaian
o     UC-05.01 : Lihat Daftar Hasil Penilaian
o     UC-05.02 : Lihat Hasil Penilaian
Berikut merupakan kebutuhan Non – Fungsional Software :
-          Usability
o   NF-01.01 Rancangan antarmuka yang mudah digunakan pengguna (user friendly)
o   NF-01.02 Tipe input untuk kata sandi bertipekan password
o   NF-01.03 Tipe input untuk field yang berisikan uang adalah menggunakan numeric
-          Reliability and uptime
o   NF-02.01 Kehilangan data tidak dapat ditoleransi
-          Security
o   NF-03.01  Hanya  administrator  yang  akan  memiliki akses ke fungsi-fungsi administrative
o   NF-03.02 Administrator dapat mengubah password pengguna
-          Maintainability
o   NF-04.01  Terdapat dokumentasi tertulis mengenai pengembangan sistem dengan menggunakan standar ReadySet.
-          Supportability
o   NF-05.01  Terdapat panduan pengguna yaitu cara penginstalan dan pengoperasian terhadap sistem ini
-          Hardware requirement
o   Spesifikasi minimal untuk komputer server adalah:
  Pentium Core 2 Duo 2,8 GHz
  1 GB DDR2
  HD 250GB SATA
  Mainboard Intel 945 + VGA + SC
  Monitor 14 Inch mendukung resolusi 1024 x 768
o   Spesifikasi minimal untuk komputer klien adalah:
  Pentium II 400 Mhz
  128 Mb SDRam
  HD 4,3 GB
KORELASI dengan Software Quality Factor
1
correctness
Software yang dibuat telah sesuai dengan design. Sesuai dengan Test case yang telah dibuat untuk tiap use case
2
Usability
Aplikasi telah berjalan dengan baik dan juga tampilan telah berfungsi dengan baik
3
Reliability
Keamanan system belum diuji di test case, pengujian sql injection juga belum dilakukan
4
Efficiency
Bahasa pemrogaman PHP dan DB MYSQL yang cenderung mudah dan baik untuk aplikasi berbasis web seperti ini. Coding yang dilakukan cenderung sederhana hanya focus kepada  Retrieve Update Delete
5
Integrity
Test case telah dilakukan ,namun ketangguhan belum teruji untuk load data banyak belum teruji
6
Maintainability
Tidak terdefinisikan
7
testability
Telah dapat digunakan dengan baik
8
Flexibility
System dapat berjalan di system selain windows namun yang mendukung aplikasi webservice
9
Portability
Server terbatas pada windos untuk lebih optimal
10
Interoperability
Tidak terdefinisikan dengan jelas
11
reusability
Modul atau fungsi yang ada hanya terbatas pada system ini

KESIMPULAN
                Dari segi kemampuan system, telah teruji, namun keamanan dan ketangguhan tidak terdefinisikan dengan jelas keamanan terhadap serangan – serangan yang mungkin dilakukan. Juga untuk interopability tidak terdefinisikan dengan baik