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 :

Template & Checklist

Template
Tempalate merupakan sebagai metode alat ukur, pola, langkah yang digunakan sebagai panduan untuk membuat sebuah dokumentasi yang berkualitas. Pada pengembangan perangkat lunak, template mengacu pada format standard yang dibuat oleh suatu organisasi, diterapkan ketika akan membuat laporan atau beberapa jenis dokumen lain. Penggunaan tempalate bisa menjadi wajib dalam beberapa kasus, seperti pada bab-bab tertentu yang terdapat pada dokumentasi dan struktur umum.

Terdapat 3 contoh tempalate :

1. Software test plan.
2. Software test description.
3. Software test report.



Dan terdapat tambahan template yang dapat digunakan :

1. Software change request.
2. Documentation of software configuration release.

Kontribusi tempalate pada kualitas perangkat lunak

Penggunaan tempalate sangat menguntungkan untuk tim pengembangan dan untuk tim riview. Pada tim pengembang tempalate digunakan :

1. Untuk memfasilitasi proses persiapan dokumen.
2. Memastikan bahwa dokumen yang disiapkan oleh pengembang sudah lengkap.
3. Memudahkan bagi anggota tim baru untuk saling teritegrasi dengan anggota lain.
4. Fasilitas untuk review dokumen.

 Pada tim perawatan template digunakan untuk :
1. Mendapatkan informasi menjadi lebih mudah dalam melakukan perawatan.

Yang harus dipersiapkan organisasi dalam mempersiapkan, melaksanakan dan memperbarui template :

1. Preparation of new templates
Sumber informasi yang paling umum digunakan dalam mempersiapkan template adalah :
- Template sudah dipersiapkan dalam organisasi.
- Contoh template dapat dimengerti publik profesional.
- Template yang digunakan oleh organisasi-organisasi serupa.

2. Penerapan Template
Penggunaan template dalam organisasi biasanya ditemukan pada prosedur oragnisasi atau instruksi kerja. Anggota staff senior berwenang untuk menentukan daftar template yang wajib digunakan sesuai dengan prosedur yang dipilih. Pada penerapan template pada organisasi bisa berupa adanya komunikasi internal seperti e-mail, intranet,dll sehingga memudahkan setiap anggota.

3. Memperbarui template
Keputusan yang bisa diambil dalam memperbarui template yang bisa menjadi tolak ukur untuk sebuah organisasi yaitu :
1. Penggunaan usulan dan saran.
2. Analisis kegagalan dan keberhasilan.
3. Adanaya tim SQA inisiatif.
4. Proposal yang dibuat oleh tim desain dan tim inspeksi berdasarkan penelaahan dokumen disiapkan sesuai template.


Checklist

Checklist meruapakan suatu daftar yang berisi faktor-faktor yang akan akan segera dikerjakan. Checklist ini sebagai alat untuk membantu memudahkan dalam setiap kegatan yang dilakukan dengan memberi tanda check pada langkah-langkah yang sudah dilalui.

Contoh dari dokumen checklist dari buku Galin:

Kontribusi Checklist pada kualitas software

1. Membantu pengembang dalam melakukan pemerikasaan.
2. Membantu pengembang dalam mepersiapkan tugas-tugas yang aka dilakukan berikutnya.

Keuntungan  bagi tim review :

1. Memastikan kelengkapan review dokumen oleh anggota review bahwa semua item review telah dibuat.
2. Efisiesi dalam mereview, semisal agenda-agenda yang penting dalam pengembangan bisa dibuat subjek yang dapat diketahui secara mudah.

Keterkaitan SQA dengan SDLC

SQA

Software Quality Assurance (jaminan kualitas perangkat lunak) merupakan aktivitas pelindung yang mendukung dan diaplikasikan pada semua proses perangkat lunak.

Penjaminan kualitas perangkat lunak ini meliputi :

1.      Pendekatan manajemen kualitas.

2.      Kontrol dokumentasi perangkat lunak dan melakukan perubahan yang dibuat.

3.      Prosedur yang dapat menjamin kesesuaian dengan standar pengembangan perangkat lunak.

4.      Prosedur pengukuran dan pelaporan.

5.      Strategi pengujian yang bertingkat.

6.      Teknologi rekayasa perangkat lunak yang efektif.

A.              Konsep Kualitas

Konsep kualitas dibagi menjadi :

1.      Kualitas

Kualitas adalah sebuah karekteristik dari sesuatu. Karekteristik ini nantinya dapat diukur dengan membandingkan sesuai standar yang sudah ditetapkan sehingga mendapatkan suatu kualitas. Karekteristik pada perangkat lunak seperti jumlah function point, baris kode, dll. Jenis kualitas berdasarkan pengukurannya ada 2 jenis yaitu kualitas desain dan kualitas konformansi.

·         Kualitas desain mengacu pada karekteristik yang sudah ditentukan desainer pada suatu utem tertentu.

·         Kualitas konformansi merupakan tingkat spesifikasi desain akan dipantau selama pembuatan.

2.      Kontrol kualitas

Kontrol kualitas adalah serangkaian pengujian dan pemeriksaan terhadap seluruh proses pengembangan untuk dapat memastikan bahwa setiap tahap proses pengembangan dapat memenuhi syarat yang sudah disepakati atau yang sudah ditetapkan.

3.      Jaminan Kualitas

Jaminan kualitas ini bertujuan untuk memberikan informasi yang diperlukan manajemen untuk dapat memberitahukan masalah kualitas produk, sehingga hasilnya kualitas produk dapat memenuhi sasaran yang ditetapkan.

4.      Biaya kualitas

Biaya kualitas ini merupakan semua biaya yang dianggarkan untuk dapat mengejar kualitas atau menampilkan kualitas yang berhubungan dengan aktivitas. Dengan adanya dokumentasi tentang biaya kualitas ini memberikan rincian dasar tentang biaya kualitas yang sedang digunakan.

Biaya kualitas dibagi menjadi berbagai macam biaya :

1.      Biaya pencegahan.

2.      Biaya penilaian

3.      Biaya kegagalan external & internal.

B.     Jaminan Kualitas Perangkat Lunak

Kualitas perangkat lunak dapat diartikan sebagai penjagaan terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara standar perkembangan yang didokumentasikan secara explisit dan karateristik yang secara implisit untuk semua perangkat lunak yang akan ikembangkan secara profesional.

Pada kualitas perangkat lunak perlu diperhatikan berbagai hal yaitu :

1.      Kurang adanya penyesuaian terhadap kebutuhan yang menunjukkan rendahnya kualitas perangkat lunak.

2.      Standar yang telah ditentukan untuk setiap kriteria  pengembangan yang dapat menuntun cara perangkat lunak dapat berkualitas. Namun pada kenyataannya banyak kriteria tersebut tidak diikuti, yang mengakibatkan kualitas kurang baik.

3.      Kurang adanya dokumentasi tentang kebutuhan implisit membuat kualitas perangkat lunak diragukan kualitasnya.

C.              Aktivitas SQA

Penjaminan kualitas perangkat lunak merupakan perekayasa perangkat lunak yang mengerjakan kerja teknis dan kelompok SQA yang bertanggung jawab terhadap penjaminan kualitas, analisis, dan pelaporan. Tugas kelompok ini berguna untuk membantu tim proyek dalam pencapaian perangkat lunak akhir yang berkualitas.

Aktivitas yang dilakukan oleh kelompok SQA yaitu :

1.      Menyiapkan rencana SQA dalam proyek.

Rencana ini dikembangkan pada perencanaan proyek dan disepakati oleh semua tim yang terkait. Aktivitas penjaminan kualitas perangkat lunak yang dilakukan tim rekayasa perangkat lunak dan kelompok SQA dikendalikan oleh rencana yang sudah dipersiapkan.

2.      Berpartisipasi pada pengembangan deskripsi proses pengembangan proyek.

3.      Memantau aktivitas rekayasa perangkat lunak untuk mengidentifikasi apakah pemenuhan proses perangkat lunak sudah dijalankan sesuai dengan yang ditentukan.

4.      Melakukan audit terhadap produk kerja perangkat lunak yang sudah ditentukan untuk mengetahui bahwa kesesuaian dengan produk kerja yang ditentukan sebagai bagian dari proses perangkat lunak. Melakukan audit terhadap produk kerja perangkat lunak yang sudah ditentukan untuk mengetahui bahwa kesesuaian dengan produk kerja yang ditentukan sebagai bagian dari proses perangkat lunak.

5.      Memantau bahwa produk kerja perangkat lunak didokumentasikan sesuai dengan prosedur pendokumentasian.

Penjaminan kualitas perangkat lunak merupakan aktivitas pelindung yang akan diaplikasikan pada setiap langkah dalam proses perangkat lunak. Dengan berbagai macam metode yang telah ada akan membantu tercapainya penjaminan kualitas sebuah perangkat lunak.

SDLC dan Keterkaitan dengan SQA

System Development Life Cycle (SDLC) yaitu proses pembuatan sistem serta melakukan pengubahannya dan model yang digunakan untuk mengembangkan suatu sistem terebut. Langkah yang ada pada SDLC ini yaitu meliputi :

1. Analisis sistem yang akan dikembangkan.
2. Mencari tahu kebutuhan dari pengembangan sistem dan melakukan perencanaan.
3. Merancang sistem.
4. Melakukan pengembangan sistem.
5. Pengujian sistem.
6. Maintenance.

Langkah-langkah yang ada diatas dijalankan secara berurutan. Pada setiap langkah yang sudah dikerjakan harus dianalisis ulang, terutama pada langkah mencari tahu kebutuhan dan perencanaan, karena pada tahap ini harus benar-benar sesuai dengan yang diinginkan. Jika tidak cocok maka langkah ini harus kembali pada tahap sebelumnya atau dilakukan control kembali (quality control). Yang dilakukan oleh internal tim.

Sedangkan pada tahap pengujian ini dilakukannya testing yag bersifat SQA, yang dilakukan oleh tim external untuk menguji sistem yang telah dikembangkan apakah sudah berkualitas. 

Dan semua tahap pada SDLC ini didokumentasikan secara formal untuk menghasilkan sistem pengembangan yang lebih berkualitas dan mempermudah dalam maintenance dan peningkatan fungsi sistem tersebut.

Development and Quality Plan

Selanjutnya saya akan mencoba mengexplore lagi tentang apa pentingnya tentang software development dan Quality Plan itu,,, Mengapa tahap ini bisa menjadi tahap yang penting?? Berikut penjelasan yang saya ketahui.

Pengembangan perangkat lunak berkualitas tinggi adalah masalah besar dan penting untuk industri perangkat lunak (Gillies, 1992).
 
Perencanaan, sebagai suatu proses yang memiliki beberapa tujuan. Masing-masing yang dimaksudkan untuk membentuk suatu fondasi yang memadai untuk :

1. Penjadwalan kegiatan pembangunan yang akan mengarah pada keberhasilan dan tepat waktu penyelesaian proyek, dan memperkirakan tenaga kerja yang diperlukan sumber daya dan anggaran.
2. Anggota tim merekrut dan mengalokasikan sumber daya pembangunan (menurut jadwal kegiatan dan perkiraan sumber daya tenaga kerja kebutuhan).
3. Menyelesaikan risiko pembangunan.
4. Menerapkan aktivitas SQA.
5. Menyediakan manajemen dengan data yang diperlukan untuk pengendalian proyek.

Elemen pada development plan untuk memenuhi dari tujuan yang ada diatas terdiri dari :

1.Project products
   Meliputi :
   - Desain dokumen (menentukan tanggal penyelasaian, menunjukkan pada customers)
   - Software Product (menentukan tanggal penyelasaian, menunjukkan pada customers)
   - Pelatihan ((menentukan tanggal penyelasaian, peserta, dll) 
2.Project interfaces
   Interfaces proyek meliputi :
   - Antar muka dengan perangkat lunak
   - Antarmuka dengan perangkat lunak lain dan / atau tim pengembangan perangkat keras yang bekerja pada sistem yang sama atau proyek
   - Antarmuka dengan perangkat keras yang ada
3.Project methodology and development tools
   Ketika mengevaluasi kesesuaian metodologi proyek yang diusulkan dan alat pembangunan, perlu dipertimbangkan lagi mengenai  profesional dalam staf, termasuk personil subkontraktor.
4.SW development standards and procedures
   Sebuah daftar harus disiapkan dari standar pengembangan perangkat lunak dan prosedur yang harus diterapkan dalam proyek.
5.The mapping of the development process.( proj. mgt. Gant )
6.Project milestones ( documents , code , report )
7.Project staff organization ( org. stru., prof. req., no of team mem., names of team leaders )
8.Development facilities ( SW, HW tools, space, period req. for each use )
9.Development risks ( see next slide )
10.Control methods
11.Project cost estimation
      Perkiraan biaya proyek didasarkan pada perkiraan usulan biaya, diikuti dengan identifikasi secara menyeluruh terhadap relevansi lanjutan  berdasarkan adanya sumber daya manusia diperbarui,perkiraan kontrak dinegosiasikan dengan subkontraktor dan pemasok, dan sebagainya.

Elemen pada quality plan untuk memenuhi dari tujuan yang ada diatas terdiri dari : 


1. Tujuan Kualitas
Dengan adanya tujuan kualitas ini sebuah pengembangan proyek akan lebih jelas untuk mengacu kepada proses hasil yang rencana yang berkualitas.
2. Tinjauan rencana kegiatan
Untuk menghasilkan rencana  yang berkualitas harus adanya daftar lengkap dari tinjauan kegiatan yang akan direncanakan. Pada tahap ini dilakukan kegiatan sebagai berikut :
- Mempertimbangkan scope
- Mempertimbangkan jenis kegiatan yang dilakukan
- Mempertimbangkan jadwal kegiatan proses proyek
- Menentukan prosedur yang akan diterapkan
- Menentukan siapa yang bertanggung jawab untuk melakukan kegiatan review.


3. Rencana testing software
Untuk menghasilkan rencana yang berkualitas juga perlunya adanya dokumen mengenai rencana testing software. Rencana testing software 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.

4. Rencana dokumen testing untuk pihak luar
5. Manajemen konfigurasi
Pada tahap ini menentukan configuration tools yang tepat dan prosedur yang dimaksudkan dapat diterapkan dalam proyek.


Dengan menerapkan yang ada pada penjelasan diatas nantinya diharapkan bisa menghasilkan perangkat lunak yang berkualitas tinggi.

Adrian (5209100057)

Arsitektur Software Quality Assurance & Components SQA

 Di sini saya akan mencoba mengexplore dari pengetahuan yang sudah saya pelajari pada mata kuliah Manajemen Kualitas tentang Arsitektur SQA .

Bentuk skema dari arsitektur SQA yaitu seperti pada gambar dibawah ini yang saya ambil pada buku Galin SQA :

Dari gambar diatas terdapat 6 komponen yang merupakan fondasi dari pembentuk SQA :

1. Pre- Project components

2. Project life cycle SQA components

3. Infrastructure components

4. Quality Management

5. SQA standards

6. Organizational SQA

• Pre- Project Components

  Pada langkah ini merupakan langkah awal pada tahap arsitektur SQA yang didalamnya terdapat dua komponen lagi pembentuk pre-project components:
  
  
  
  • Contract Review
  Yang dilakukan pada contract review melakukan negoisasi kontrak pada customers atau pada sebuah organisasi. Setelah dilakukan contract review nantinya akan didapatkan sebuah hasil yang disepakati oleh kedua belah pihak tentang berbagai kebutuhan yang akan diperlukan pada proses pengembangan. Pada contract review ini dilakukan seperti klarisifikasi kebutuhan dari customers,kebutuhan sumber daya dan review jadwal proyek, evaluasi staff yang ada, evaluasi resiko pada proses pengembangan. 
  •  Development plan & Quality Plan
            Pada tahap ini yaitu melakukan tahap yang dilakukan setelah contract review telah disetujui dan             ditandangani. Pada tahap ini yang dilakukan yaitu merinci :

                    1. Tantangan utama yang terjadi dalam mengatur proyek.
                    2. Tantangan utama dalam menghasilkan kualitas proyek.

•  Project life cycle SQA components

   Siklus hidup proyek dibagi menjadi dua tahap :
  - Tahap pengembangan
  - Tahap operasi dan maintenance
  
  Tahap pengembangan 
  - Review
  Review yang dilakukan disini yaitu review dokumen testing, review laporan desain yang telah dibuat, user manual,dll.
  Review terdapat 2 yaitu Formal design review dan Peer review.
  Yang terkait pada formal design review yaitu : Pimpinan proyek, Manejer Departemen, Ahli Software, dan Ketua departemen.
  Sedangkan pada Peer review yaitu bertujuan untuk mendeteksi kesalahan yang akan terjadi pada design dan code.
  
  - Pendapat Para Ahli
  Pada tahap pengembangan mengapa dibutuhkan tenaga para ahli? karena para ahli dibutuhkan untuk melakukan kritikan agar mendeteksi kesalahan dari code atau design dikarenakan tim pengembang kurang bisa menangani hal tersebut.
  
  - Melakukan Pengujian Software
  Pengujian dilakukan juga untuk mendeteksi kesalahan yang akan terjadi pada design ataupun code. Pengujian yang dilakukan yaitu pengujian modul , intgerasi, dan  keseluruhan sistem software.
  
  Tahap Maintenance
  
  Tahap pemeliharaan ini bertujuan untuk meningkatkan kualitas dari pengembangan software. 
  
  Layanan pemeliharaan software dikategorikan sebagai berikut :
  • Pemeliharaan Korektif : Koreksi kesalahan perangkat lunak dan kegagalan.
  • Pemeliharaan Adaptif : Mengadaptasi software saat ini untuk keadaan tambahan tanpa mengubah software.
  • Pemeliharaan Fungsi Perbaikan : Peningkatan dan perbaikan software.
   
  Dan pada tahap ini juga dilakukan pengontrolan terhadap penjaminan kualitas. Sehingga menjadikan pemeliharaan ini menjadi lebih efektif. 
   

• Infrastructure Components

   Pada tahap ini yaitu bertujuan untuk mengurangi dari tingkat kegagalan software. Pada tahap terdapat komponen pendukung yaitu :
                          •        Prosedur dan instruksi kerja.
  
  •        Template dan checklist.
  •        Pelatihan staf, pelatihan ulang, dan sertifikasi.
  •        Pencegahan dan tindakan korektif.
  •        Konfigurasi manajemen.
                          •        Kontrol Dokumentasi.

•  Quality Management

  Tahap ini bertujuan untuk mengontrol dalam pengembangan dan pemeliharaan proyek. Quality management dibagi menjadi 3 yaitu :
  1. Project Progress Control
  
  Tujuan utama dari project progress control ini yaitu untuk untuk mengetahui progres dari proyek itu samapai mana agar tidak terjadi penyimpangan dari rencana proyek yang sudah dibuat.
  Tahap ini berfokus pada sumber daya, jadwal, menejemen resiko, dan biaya.

           2. Software Quality Metrics
                     Tahap ini melakukan berbagai pengukuran terhadap berbagai aspek kualitas untuk mendukung                        kegiatan pengendalian dan inisiasi.Pengukuran berlaku untuk kualitas fungsional,produktivitas,                          dan aspek proyek organisasi.

           3. Biaya Kualitas Software

• SQA Standards

  Pada tahap ini memiliki tujuan :
  
  • Pemanfaatan pengetahuan profesional internasional.
  •  Peningkatan koordinasi dengan sistem mutu organisasi lain .
  •  Evaluasi profesional tujuan dan pengukuran prestasi.
  Standards yang ada pada SQA ini seperti : ISO, IEEE, dll sebagai acuan untuk proyek itu agar lebih akurat.

• Organizational SQA

  Tujuan dari organizational SQA yaitu :
  ·         Mengembangkan dan mendukung pelaksanaan komponen SQA. 
  ·         Mendeteksi penyimpangan dari prosedur SQA dan metodologi.
  ·         Menunjukkan perbaikan komponen SQA.  

          Tahap ini mengacu pada manejemen dalam sebuah proyek.

Adrian (5209100057)