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.

Project progress control in SQA

Setelah membahas pentingnya sebuah pendokumentasian dalam sebuah proyek perangkat lunak, maka disini akan diulas tentang langkah focus pada progress. Project progress control menjadi salah satu bagian penting dalam memastikan kualitas pernagkat lunak dalam sebuah proyek. Dimana Project Progress Control atau bisa disebut PPC ini meliputi :

-          Memastikan pada kebutuhan fungsional teknis

-          Memastikan penjadwalan dan pendanaan

-          Proses pengembangan dan proses pembuatan

Yang dirangkum dalam beberapa komponen utama yakni :

1.       Pengelolaan resiko

                Merupakan tahapan identifikasi resiko – resiko yang mungkin timbul selama proses pengerjaan perangkat lunak. Beberapa standar yang sering dipakai IEEE (2001), Jones (2004), dimana melalui dokumen ini, manajer proyek akan lebih mudah dalam mengantisipasi dan melakukan perencanaan pengembangan

2.       Project schedule control

Merupakan pengelolaan yang focus pada penjadwalan pengerjaan. Berdasarkan milestone yang telah direncakan, terdapat aktivitas dalam identifikasi keberhasilan pengerjaan ataupun identifikasi masalah serta keterlambatan

3.       Project resource control

Seringkalinya keluar masuk anggota team membuat pengelolaan sumberdaya terutama manusia sangatlah penting. Kita harus memastikan setiap anggota tim memiliki tujuan yang sama dengan manajer proyek.

4.       Project budget control.

Seringkalinya proyek terhambat, ataupun terlambat, itu disebabkan oleh pendanaan. Manajemen keuangan sangatlah penting dalam sebuah proyek. Karena semua menyangkut kepada uang, yakni beberapa aspek dibawah :

§  Human resources

§  Development and testing facilities

§  Purchase of COTS software

§  Purchase of hardware

§  Payments to subcontractors.

Berikut contoh dari progress report menurut Galin :

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

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

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.