Cara menghitung Function Point

Disini saya akan coba share hasil pekerjaan saya mengenai perhitungan function point. Untuk lebih jelasnya lihat pada link excel dibawah ini.

Project Progress Control

Penjelasan progress control dilihat pada PPT dibawah ini :

Progress control

View more PowerPoint from adri_cinno

Staff Training & Certification

Perkembangan staf  dari pengetahuan profesional yang terbaru adalah kunci untuk mencapai kualitas dalam pengembangan dan pemeliharaan. Cara dari meningkatkan perkembangan staff yaitu salah satunya dengan adanya staff training & certification. Tujuan dari adanya staff training & certification ini adalah :

1. Untuk mengembangkan pengetahuan dan keterampilan staf baru perlu melakukan tugas-tugas pembangunan perangkat lunak dan pemeliharaan di tingkat yang memadai efisiensi dan efektifitas. Pelatihan seperti menyatukan dengan anggota tim baru.
2.  Untuk dapat saling bertukar pikiran pengetahuan tentang prosedur SQA.
3. Untuk menjamin kesesuaian dengan standar organisasi dalam pengembangan perangkat lunak (dokumen dan kode) dengan saling menginformasikan struktur prosedur sesuai dengan instruksi kerja.

Dengan  itu diharapkan dengan adanya staff training dapat membantu dalam proses pengembangan perangkat lunak.




 

Documentation Control & Quality Records

Okay saat ini saya mencoba memberikan pengetahuan saya tentang documentation control & quality records pada pengembangan perangkat lunak...

Dokumen kontrol ini saat ini menjadi penting dalam pengembangan perangkat lunak. Karena dokumen kontrol ini berguna untuk pengembangan dan berguna sebagai pemeliharaan sistem perangkat lunak. Jika dokumen diberlakukan dalam sebuah proyek pengembangan perangkat lunak maka persiapan, penyimpanan, pencarian, serta pembuangan harus dikendalikan oleh prosedur pada dokumen kontrol.

Salah satu jenis dokumen kontrol yang baik yaitu quality records (catatan mutu).

- Dengan adanya sistem dokumen ini mentargetkan kepada customer sehingga customer mungkin akan lebih percaya kepada pihak pengembang dikarenakan dokumen ini bisa menunjukkan kepatuhan penuh dan operasional yang efektif dari sistem penjaminan kualitas perangkat lunak pada proses pembangunan dan pemeliharaan.

- Quality Records sendiri yaitu sebuah catatan dokumen yang memberikan informasi spesifik  yang berhubungan dengan prosedur dan instruksi kerja. 

- Seperti pada penjelasan diatas, dengan adanya Quality records ini memberikan sebuah bukti bahwa dalam pengembangan perangkat lunak ini tim pengembang (organisasi) telah melakukan sesuai dengan prosedur dan kebijakan.

Tujuan dari mengelola dokumen kontrol yaitu :

- Untuk menjamin kualitas dokumen.

- Untuk menjamin kelengkapan teknis sesuai dengan prosedur struktur dokumen dan instruksi.

- Untuk  keperluan masa depan, dokumen yang mungkin diperlukan untuk pemeliharaan perangkat lunak sistem, atau tanggapan pelanggan terhadap keluhan yang terjadi di masa mendatang.

- Untuk mendukung penyelidikan penyebab kegagalan perangkat lunak sebagai bagian dari tindakan korektif dan lainnya. 

Dokumen-dokumen tertentu memerlukan persetujuan. Untuk dokumen-dokumen yang harus disetujui, prosedur yang relevan harus adanya posisi orang berwenang untuk melakukannya untuk melakukan persetujuan setiap jenis dokumen dan rincian dari proses yang akan dilaksanakan. 

Persetujuan dapat diberikan oleh seseorang, beberapa orang, atau komite seperti desain review komite formal tergantung pada jenis dokumen dan preferensi organisasi. Pemegang posisi   prosedur dokumentasi kontrol diharapkan  memiliki pengalaman dan keahlian teknis yang cukup untuk tugas dokumen  meninjau. 

Typical controlled documents (including quality records)

 

Refrensi :

1. Buku Daniel Galin, Software Quality Assurance From theory to implementation

Configuration Management

Configuration Management yaitu sebuah proses untuk membangun dan mempertahankan konsistensi kinerja suatu produk, desain dan operasional. Tujuan dari configuration management yaitu :

1. Identifikasi Perubahan.
2. Mengontrol perubahan.
3. Memastikan perubahan telah dilaksanakan.
4. Laporan perubahan untuk setiap anggota yang ditunjuk untuk mengetahui tentang CM.

Perubahan yang dilakukan pada Configuration Management yaitu :

1. Kode Perangkat Lunak.
2. Data ( test data & file database).
3. Dokumen yang terdiri dari ( SRS, desain, jadwal proyek, test plans).

Faktor yang mempengaruhi persetujuan perubahan yang akan diusulkan yaitu :

1. Urgensi dari perubahan.
2. Upaya jaminan kualitas perangkat lunak yang disyaratkan software configuration management.
3. Kontribusi dari perubahan yang akan diusulkan.
4. Pengaruh perubahan yang akan diusulkan pada jadwal proyek.
5. Upaya yang diperlukan dalam membuat perubahan operasional.


* Software Change Control

Melakukan pengontrolan proses dengan memperkenalkan perubahan dengan aktivitas meneliti permintaan perubahan dan menyetujui pelaksanaan sesuai permintaan, kemudian melakukan penjaminan mutu setiap versi baru.

Kebutuhan untuk merilis versi konfigurasi software baru biasanya berasal dari banyak lebih kondisi seperti cacat software configuration item, fitur khusus yang diminta oleh pelanggan baru, dan inisiatif tim untuk memperkenalkan perbaikan SCi. Berikut merupakan bagian dari proses rilis software configuration :

1. Tipe rilis dari software configuration (baseline versions, intermediate versions, revisions)
2. Software configuration management plans.
3. Software configuration evolution models.
4. Dokumentasi dari software configuration versions.

*  Audits

- % dari perubahan yang tidak disetujui.
- % dari perintah perubahan yang selesai sesuai jadwal.
- % dari configuration item yang tidak diperiksa.
- % configuration item yang didokumentasikan.
- % Jumlah kegagalan proses configuration management.


Bagaiamana caranya melacak semua versi dari perubahan yang ada, ketergantungan antar komponen, catatan persetujuan dapat menjamin kualitas dari pengembangan perangkat lunak?

- Menggunakan Tools Software CM yang baik
- Adanya prosedur Software CM.

*  Format CM Plan

1. Introduction
    a) purpose b) scope c) definitions and acronyms d) references
2. Management
    a) organization
    b) SCM responsibilities
    c) interface control
    d) SCMP implementation
    e) policies, directives, procedures (naming conventions, version designations, problem report process)
3. SCM Activities
    a) configuration identification
    b) configuration control (change history, review authority, read/write control, member identification)
    c) configuration status accounting (status of requests, status of approved changes, …)
    d) audits and reviews
4. Tools, Techniques, and Methodologies
5. Supplier Control
6. Records Collection and Retention

Testing Software

Materi selanjutnya yang akan coba saya explore dalam mata kuliah Manjemen Kualitas yaitu mengenai testing software. . . .

Testing yaitu merupakan sebuah proses mencoba sebuah program yang nantinya berguna apabila terdapat kesalahan-kesalahan yang muncul. Pada fase testing ini juga berguna untuk mendeteksi dari perbedaan yang terjadi antara software dengan kebutuhan yang diinginkan, mungkin terjadi bug atau error.

Strategi testing ada 2 yaitu ;

1. Big bang Testing
   Big bang testing yaitu bertujuan menguji perangkat lunak secara keseluruhan, setelah menyelesaikan semua tahap. Dengan adanya strategi big bang dapat mengetahui kelemahan yang cukup parah.    

2. Incremental Testing
   Pengujian perangkat lunak yang dilakukan secara bertahap dalam modul, mulai dari menguji pada bagian terkecil (unit test) sampai menguji pada integration test (modul). Dilakukan sampai semua modul telah diuji dan kemudian melakukan system test. Incremental testing ini biasanya dilakukan pada software yang memiliki modul yang relatif kecil.

Terdapat dua metode pengujian yang telah dikembangkan yaitu ;

1. White box testing
   Disebut juga dengan struktural testing. Testing ini dilakukan dengan    melihat langsung kedalam modul untuk meneliti kodingan dari software dan    menganalisis apakah ada kesalahan atau tidak. Biasa digunakan untuk verifikasi. Keuntungan dari metode ini yaitu memprioritaskan kualitas software dari coding dan standard pengkodean dan. Namun metode ini memiliki kelemahan yaitu harus adanya SDM yang lebih dan ketidakmampuan dalam menguji perangkat lunak dalam hal waktu, kehandalan dan beban durabilitas.

2. Black box testing
   Disebut juga dengan fungsional testing. Testing ini hanya  sebatas    pengujian terhadap fitur - fitur dalam    software. Biasa digunakan untuk validasi. Black box testing ini membutuhkan sumber daya yang relatif lebih sedikit karena pada metode ini memungkinkan untuk melakukan testing class, yang sebagian besar dapat dilakukan sendiri oleh penguji blackbox. Namun kelemahan metode ini yaitu sulitnya untuk megidentifikasi error yang terjadi untuk menghasilkan output yang benar dan tidak adanya kontrol yang spesifik, sehingga testing ini tidak mengeksekusi sebagian besar dari baris kode yang tidak tercakup dalam seperangkat tes cases.

Tipe dari software testing diabgi menjadi 6 yaitu :
1. Unit Testing
 - Testing terhadap hardware atau software dari unit - unit yang berhubungan
 - White box testing
 - Kode struktur

2. Integrasi testing
 - Pengujian dimana komponen software, hardware atau keduanya sudah menyatu dan sudah diuji to mengevaluasi interaksi dari 2 hal tersebut
 - Black dan white box testing
 - desain level rendah - tinggi

3. Fungsional & sistem testing
 - Fungsional testing memastikan spesifikasi fungsional dalam kebutuhan terpenuhi
 - Sistem testing melibatkan penempatan program baru kedalam lingkungan lingkungan yang berbeda - beda untuk memastikan dapat bekerja pada    lingkungan pelanggan dengan berbagai versi dan tipe sostem opereasi
 - Black box testing
 - Spesifikasi : desain level tinggi, spesifikasi kebutuhan

4. Acceptance testing
 - Testing Formal yang dilakukan untuk memastikan apakah sistem memenuhi    kriteria apa tidak dan agar pelanggan tahu apakah software dapat    diterima oleh sistem
 - Kriteria dari sistem harus memuaskan agar diterima oleh pelanggan
 - Black box testing
 - Spesifikasi kebutuhan

5. Regression testing
 - Tes ulang sistem untuk verifikasi jika modifikasi yang dilakukan tidak    menyebabkan effect yang tidak diinginkan dan sistem masih sesuai dengan    spesifikasi kebutuhan
 - Dilakukan disemua siklus testing setelah terjadi perubahan yang    signifikan (memperbaiki bug)
 - Black dan white box
 - Setiap perubahan dari dokumentasi, desain level tinggi

6. Beta Testing
 - Testing melibatkan potensial user dan beta tester
 - User mengisntal software dan menggunakannya, dan selanjutnya memberikan    laporan dari setiap error yang ditemukan selama penggunaan kepada    pengembang
 - Black box testing

Requirements traceability matrix

Sekarang saya akan menjelaskan tentang apa itu Requirements traceability matrix ? dan apa kegunannya dalam penjaminan kualitas sebuah software. . . . . . .

Requirements traceability matrix (RTM)  merupakan alat yang digunakan untuk mengetahui kebutuhan pada pengembangan perangkat lunak pada fase testing. Disini RTM berguna melakukan verifikasi apakah kebutuhan tersebut sudah terpenuhi atau belum. RTM ini berupa daftar-daftar kebutuhan yang nantinya dapat memudahkan dalam melakukan testing. Matrix ini menghubungkan antara kebutuhan pada tingkat yang paling tinggi, spesifikasi desain, kebutuhan testing, dan coding. Karena matrix ini menyediakan link yang diperlukan berguna menentukan informasi yang dibutuhkan. Dengan adanya RTM juga sebagai alat untuk memastikan adanya penjaminan kualitas software, karena RTM memastikan bahwa kebutuhan yang diinginkan customers telah sesuai.

Tujuan dari RTM yaitu ;

1. Memastikan bahwa seluruh test case yang ada harus sesuai dengan kebutuhan.
2. Memastikan bahwa ketentuan yang telah disetujui sudah mencakup semua pada fase pengembangan. Dari spesifikasi kebutuhan, pengembangan perangkat lunak, testing, sampai perangkat lunak itu jadi.

Contoh dari RTM bisa dilihat dari gambar dibawah ini :