External Participants

Tipe dari External Participants

Subcontractors (Outsourcing)

Melaksanakan kegiatan dari proyek. Keuntungannya adalah ketersedian staf, keahlian khusus, dan low price.

Supplier dari software COTS dan penggunaan Software module

Keuntungannya adalah mengurangi waktu dan biaya, meningkatkan kualitas karena komponen ini telah teruji dan dikoreksi oleh para pengembang dan pelanggan sebelumnya.

Customer

Kekurangannya adalah membutuhkan hubungan yang baik antara pelanggan dengan supplier.

Type of External Participants

Kontribusi SQA tools untuk jaminan kualitas dari External Participants

1.Requirements document reviews

2.Participation in design reviews and software testing

3.Preparation of progress reports of development activities

4.Review of deliverables (documents) and acceptance tests

Software Maintenance

Pemeliharaan software dilakukan denga tujuan untuk mengehui  kebutuhan fungsionalitas software telah sesuai, memastikan kebutuhan manajerial jadwal dan budget, meningkatkan efisiensi software dan pemeliharaannya.

Komponen Pemeliharaan Software

Untuk mendapatkan software yang berkualitas tinggi dan baik, dibutuhkan komponen-komponen pemeliharaan software seperti berikut:

• Kebenaran/Corrective (menunjang perbaikan service pada software)
• Adaptive/Adaptive (menyesuaikan software dengan berbagai kebutuhan baru dan berbeda)
• Peninggkatan Fungsionalitas/functional improvements (peningkatan system reliabilitas dan infrastruktur)

Testing Implementation

Testing Implementation Process

Determining the test methodology

Standart kualitas yang sesuai dengan kebutuhan.

Standart kualitas monitoring perangkat lunak yang dibutuhkan.

Planning the test 

Unit test

Unit-unit kecil dari perangkat lunak atau modul (function, procedure, method). Untuk mengisolasi apakah setiap bagian dari program sudah dapat berjalan dengan benar dan baik.

Integration test

Penggabungan beberapa unit dengan subsistem. Untuk memastikan interaksi antara dua atau lebih komponen telah berjalan sesuai dengan persyaratan fungsionalnya. Misalnya dengan penerimaan data dari berbagai komponen dan bagaimana melewatkan data ke berbagai komponen.

System Test

Berhubungan dengan semua system yang ada di perangkat lunak.

Designing test

Menjelaskan proses design pengujian software yang dilakukan.

Perfoming the test

Menjelaskan bagaimana cara melakukan tes terhadap software yang sedang di tes.

Software Testing

Software testing merupakan proses menganalisis item dari software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang dibutuhkan. Selain itu juga untuk mengevaluasi fitur dari item perangkat lunak.

Pengujian perangkat lunak yang merupakan bagian dari verification dan validation

Verification

Mengevaluasi system atau komponen untuk menentukan apakah produk dari fase pembangunan yang diberikan memenuhi kondisi yang dikenakan pada awal fase itu.

Validation

• Mengevaluasi system atau komponen selama atau pada akhir proses pembangunan untuk menentukan apakah memenuhi persyaratan yang ditentukan.
• Apakah fitur yang telah dibangun ke dalam perangkat kunak memenuhi persyaratan pelanggan dan dapat dilacak dengan kebutuhan pelanggan

6 Type Testing

• Unit Testing
• Integration Testing
• Fungtional dan system testing
• Acceptance Testing
• Regression Testing
• Beta Testing

Contract Review

Contract review merupakan salah satu komponen yang terdapat pada SQA. Komponen ini dimaksudkan untuk memadukan guide review drafts dan dokumen kontrak. Dengan adanya contract review, kontrak yang telah dilakukan dengan mitra proyek dan subkontraktor akan mudah untuk diawasi.

Dua tahapa dalam proses contract review:

a.  Review  untuk perancangan draf proposal sebelum diajukan ke pelanggan

• Customer’s requirement documents
• kebutuhan detail customer dan penjelasan dari persyaratan
• perkiraan biaya dan sumberdaya
• Adanya kontrak atau draft kontrak antara supplier dengan partners and subcontractor

b.  Review draft proposal sebelum penandatanganan

Tujuan dari contract Review

• Customer memiki requirement yang telah diklarifikasi dan telah di  dokumenkan
• Merupakan  aspek normal dalam hubungan antar pelanggan dengan perusahaan yang telah ditetapkan
• Untuk identifikasi resiko dalam pengembangan
• Untuk penyusunan estimasi biaya dan sumberdaya proyek
• Semua pemahaman dapat dicapai antara pelanggan dan perusahaan harus didokumentasikan secara lengkap dan benar
• Tidak ada perubahan, penambahanm atau kelalaian yang belum dibahas dan disepakati harus terdapat pada draf kontrak.

Siapa yang melakukan kontrak review

• Pimpinan atau anggota dari proposal team
• Para anggota dari team proposal
• Seorang team ahli
• Seorang dari luar yang professional atau staf dari perusahaan yang bukan merupakan anggota team proposal.

Contract review untuk Proyek Internal

• Titik utama dari hubungan internal
• Hubungan yang baik dengan adanya pemeriksaan yang cukup pada persyaratan proyek, sumber daya, dan resiko pembangunan.

Formal Design Review dan Peer Review dalam pengembangan software

Dalam sebuah SQA Architecture, yang memastikan langkah pengerjaan software berjalan dengan  baik adalah pada langkah Project Life Cycle. Dalam beberapa tahapan dalam langkah tersebut yang pertama adalah formal design review dan peer review.

                Sebelum membahas lebih lanjut mengenai kedua jenis review tersebut, kita coba melihat terlebih dahulu review dalam konteks pengembangan sebuah software. Review dilakukan saat setelah perencanaan software telah disahkan oleh pihak pengembang dan pelanggan. Setelah itu, dilakukan uji kembali guna melihat design keselurhan dari pengembangan software untuk di verifikasi kemudian di validasi.

                Kemudian dari situ kita bisa memastikan bahwa design dan pengembangan software telah memenuhi syarat yang telah kita inginkan. Dari jenis review yang ada, menurut Galin, ada 2 yakni Formal design review dan peer review, berikut detail penjelasannya :

Formal Design Review :

                Secara umum, Formal Design review atau biasa disebut dengan Design Review (DR) merupakan suatu review yang menjadi syarat mutlak. Tanpa ada persetujuan dari review ini, pengembangan software tidak dapat dilakukan. Menurut Galin, jenis – jenis dari DR antara lain :

-          DPR – Development Plan Review

-          SRSR – Software Requirement Specification Review

-          PDR – Preliminary Design Review

-          DDR – Detailed Design Review

-          DBDR – Data Base Design Review

-          TPR – Test Plan Review

-          STPR – Software Test Procedure Review

-          VDR – Version Description Review

-          OMR – Operator Manual Review

-          SMR – Support Manual Review

-          TRR – Test Readiness Review

-          PRR – Product Release Review

-          IPR – Installation Plan Review

Menurut Sauer dan Jeffery (200), diskusi dan focus dalam DR meliputi :

-          The participants

-          The prior preparations

-          The DR session

-          The recommended post-DR activities.

1.       Participant

Participant dalam formal design review terdiri dari :

§  Review leader

Memastikan bahwa review berjalan dengan baik, dengan syarat biasanya telah memiliki pengalaman dalam pengembangan software sebelumnya serta memiliki relasi yang kuat dengan project leader.

§   Review Team

Bagian dari tim yang terdiri dari orang2 yang dipercaya oleh ketua review untuk membantu pelaksanaan review

2.       Preparations

Persiapan yang dapat dilakukan antara lain :

§  Menyiapkan jobdesk untuk review tim serta segala persiapannya

§  Menyiapkan review tools yang dapat digunakan dalam proses review secara keseluruhan

§  Persiapan teknis dan administratif

3.       DR sessions

Merupakan sesi pelaksanaan review yang terdiri dari aktifitas

§  Presentasi design dokumen yang telah dibuat

§  Komentar serta evaluasi dari review team

§  Verifikasi dan validasi berdasarkan dari hasil komentar dan evaluasi yang didiskusikan bersama

§  Keputusan yang berupa :

·         FULL APPROVAL : disutujui semua design yang telah dibuat

·         PARTIAL APPROVAL : ada beberapa bagian yang harus direvisi dan proyek akan berjalan setelah revisi

·         DENIAL OF APPROVAL : penolakan dari design sehinngga development team harus mendesign ulang

4.       Recommended post DR terdiri dari hasil evaluasi dari proses revie

PEER REVIEW

                Sedangkan peer review cenderung lebih kompleks dan menyeluruh dimana terdiri dari beebrapa participant yang lebih yakni :

-          A review leader

-          The author

-          Specialized professional

Yakni ada tambahan review dari professional yang memang ditujukan untuk membantu proses review. Dimana disarankan berupa :

o   A designer : seorang yang mendesain system

o   A coder : yang melakukan code dari pengembang

o   A tester ; seorang tester professional

Sedangkan untuk walkthrough beberapa professional yang disarankan antara lain :

o   A standar enforcer : dimana seorang yang telah berpengalaman dalam penentuan standard an prosedur.

o   A maintenance expert : seseorang yang telah ahli dalam proses maintenance software sehingga bisa didapat masukan untuk proses implementasi software.

o   A user representative : calon user yang telah berpengalaman dalam penggunaan software sejenis

Peer review proses :

Dilaksanakan dalam sebuah dokumen dalam petunjuk2 Appendix C of MIL-STD-498 (DOD, 1994) dimana untuk system penilaian error didasarkan pada penilaian skala berikut :

Severity               Description

5 (critical)                     (1) Prevents accomplishment of essential capabilities.

(2) Jeopardizes safety, security or other critical requirements.

4                                  (1) Adversely affects the accomplishment of essential capabilities,

where no work-around solution is known.

(2) Adversely affects technical, cost or schedule risks to project or

system maintenance, where no work-around solution is known.

3                                  (1) Adversely affects the accomplishment of essential capabilities,

where a work-around solution is known.

(2) Adversely affects technical, cost or schedule risks to the

development project or to the system maintenance, where a work-around solution is known.

2                                  (1) User/operator inconvenience that does not affect required mission

or operational essential capabilities.

(2) Inconvenience for developmentor maintenance personnel, but

does not prevent the realization of those responsibilities.

1                              (minor) Any other effect.

Mengenal SQA architecture

                Dalam sebuah pengembangan perangkat lunak atau biasa kita sebut software, tentunya diperlukan suatu pengelolaan kualitas agar dapat memenuhi tuntutan dan juga kebutuhan akan software tersebut. Pengelolaan kualitas tersebut biasa disebut quality manajemen atau software quality manajemen (SQA). SQA yang sebenarnya adalah Software Quality Assurance merupakan suatu tatanan dan tahapan – tahapan yang ditempuh guna mendapatkan kualitas dari software yang diinginkan.

                SQA menuurut Galin, memberikan suatu pedoman dalam suatu proyek pengembangan software. Jadi focus dari SQA adalah memberikan tatanan dalam proses proyek pengembangannya. Struktur dalam SQA sendiri telah diatur jelas dalam SQA Architecture berikut :

Secara umum, SQA architecture terdiri dari 5 proses utama :

1.       Pre project components

Adalah proses persiapan dalam memulai proyek pembuatan software, yang terdiri dari contract review dan project development plan dan quality plan

2.       Project life cycle components

Pada proses ini adalah tahapan dalam proses pengembangan software nya yang memastikan kualitas saat proyek berjalan yang terdiri dari :

o   Formal desain review

o   Peer reviews

o   Expert opinion

o   Software testing

o   Software maintenance

o   Sqa of external participant

3.       Quality infrastucture components

4.       Quality management

5.       Standart serta Organizational base

Untuk detail lebih lanjut tiap proses akan dibahas detail lebih lanjut.