UAS REKAYASA PERANGKAT LUNAK. Software Quality Assurance HANSI ADITYA KURNIAWAN

dokumen-dokumen yang mirip
PERANAN TEAM SOFTWARE PROCESS PADA REKAYASA PERANGKAT LUNAK

Pertemuan 12 dan 13 SQA TIK : Menjelaskan konsep dan strategi Software Quality Assurance

JAMINAN KUALITAS PERANGKAT LUNAK

PROSES DESAIN. 1. Metodologi Pengembangan Sistem

Systems Development Life Cycle (SDLC)

Software Quality Assurance

Chapter 2 What is Software Quality?

Software Proses. Model Proses Perangkat Lunak. Pengembangan Perangkat Lunak. Framework activities 3/20/2018. System Development Life Cycle (SDLC)

3/17/16 Testing dan Audit Perangkat Lunak - Universitas Mercu Buana Yogyakarta

Chapter 11 Assuring the quality of software maintenance components

SDLC Concepts. Muhammad Yusuf D3 Manajemen Informatika Universitas Trunojoyo

Siklus Pengembangan Perangkat Lunak

Tujuan Perkuliahan. PENGANTAR RPL (Pert. 2 chapter 1 Pressman) Agenda. Definisi Software (Perangkat Lunak) Lunak) 23/09/2010

TESTING & IMPLEMENTASI SISTEM 4KA. Mengukur Produktivitas Perangkat Lunak. helen.staff.gunadarma.ac.id

Pertemuan 4 Manajemen Proyek (2) Rekayasa Perangkat Lunak

BAB 1. PENDAHULUAN. 1.1 Latar Belakang

3. Jaminan Kualaitas Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan kualitas adalah :

SOFTWARE ENGINEERING (REKAYASA PERANGKAT LUNAK)

TAHAPAN PENGEMBANGAN DESAIN, DAN VERIFIKASI DAN VALIDASI SISTEM YANG PENTING UNTUK KESELAMATAN BERBASIS KOMPUTER

JAMINAN KUALITAS PERANGKAT LUNAK

BAB 3 PENGUJIAN DALAM SIKLUS PENGEMBANGAN

BAB II TINJAUAN PUSTAKA

BAB III LANDASAN TEORI. yang disusun guna menyelesaikan masalah secara sistematis. Pada bab ini akan

Chapter 6. Development and quality plans

KONSEP MANAJEMEN PROYEK

Manajemen Resiko Nia Saurina 811

Manajemen Proyek Minggu 2

Jenis Metode Pengembangan Perangkat Lunak

BAB V SIMPULAN DAN SARAN. Dari hasil evaluasi penerapan manajemen pengendalian proyek South

Ratna Wardani. Department of Electronic Engineering Yogyakarta State University

PENTINGNYA PEMELIHARAAN SOFTWARE

AUDIT MANAJEMEN TEKNOLOGI INFORMASI DENGAN MENGGUNAKAN COBIT 4.1 PADA SISTEM TRANSAKSI KEUANGAN

BAB 1 PENDAHULUAN. Secara umum, diketahui bahwa dalam suatu siklus pengembaangan perangkat lunak selalu terdapat empat proses utama, yaitu :

BAB V KESIMPULAN. Pada bab ini akan menyatukan hasil temuan dalam penelitian ini. Pada bagian

PERHITUNGAN KOMPLEKSITAS FUNCTION POINT UNTUK SUATU WEB

Pemrograman Web Berbasis Framework. Pertemuan 13 : Pengembangan Project (Bag. 1) Hasanuddin, S.T., M.Cs. Prodi Teknik Informatika UAD

Teknik Informatika S1

LOGO Manajemen Proyek Teknologi Informasi

BAB III METODOLOGI PENELITIAN

PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK) PMBOK dikembangkan oleh Project Management. Institute (PMI) sebuah organisasi di Amerika yang

Scanned by CamScanner

PEMBUATAN APLIKASI MANAJEMEN PROYEK DALAM MENGELOLA PROYEK DI PT. X

ERP (Enterprise Resource Planning) Pertemuan 6

Software Quality Assurace 9/18/ :50 PM 1

PROJECT MANAGEMENT PLAN RANCANG BANGUN SISTEM INFORMASI PENERIMAAN DAN SELEKSI PEGAWAI MENGGUNAKAN METODE MANAGEMENT BY OBJECTIVE

Nama : Rendi Setiawan Nim :

Rekayasa Perangkat Lunak DEPARTEMEN PENDIDIKAN NASIONAL UNIVERSITAS PENDIDIKAN INDONESIA 2008

PENJAMINAN KUALITAS SOFTWARE pada SIKLUS HIDUP PENGEMBANGAN PERANGKAT LUNAK PROTOTYPING

SOFTWARE QUALITY ASSURANCE

SOFTWARE QUALITY ASSURANCE

Adrian Nugraha Putra

BAB III OBJEK DAN METODE PENELITIAN. struktur organisasi dan uraian tugas unit-unit organisasi Koperasi Karyawan

Aplikasi yang pendekatannya sistematis, disiplin, bisa terukur untuk pengembangan operasional dan pembuatan software. Tools. Methods.

A. Tujuan dan Ruang Lingkup Proyek Perancangan Rekayasa Perangkat Lunak

BAB 1 PENDAHULUAN. organisasi atau proyek. Pada proyek konstruksi TQM terdiri dari standart operating

TUGAS MANAJEMEN PROYEK I SOFTWARE ENGINEERING

Dibuat Oleh : 1. Andrey ( )

Chapter 4 SOFTWARE QUALITY ASSURANCE - REVIEW

Sehingga semua pihak merasa ikut memilki dan merasakan hasilnya. Pelatihan dan Kompetensi Kerja Sistem Manajemen K3 SMK3

136 Pemeliharaan Perangkat Lunak

BAB 3 METODOLOGI PENELITIAN

MANAJEMEN KUALITAS PROYEK

PEMELIHARAAN PERANGKAT LUNAK (SOFTWARE MAINTENANCE)

KRITERIA KEBERHASILAN SUATU PROYEK

KERANGKA KENDALI MANAJEMEN (KENDALI UMUM)

BAB 5 FAKTOR PENGUJIAN

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

PERANGKAT LUNAK & REKAYASA PERANGKAT LUNAK

PENDAHULUAN REKAYASA PERANGKAT LUNAK. By PresenterMedia.com

COMPUTER SYSTEM ENGINEERING

BAB 1 PENDAHULUAN Latar Belakang. Persaingan yang semakin ketat dalam dunia bisnis dan perkembangan

KENDALI MANAJEMEN MUTU

Materi Kuliah 5 Implementasi dan Pengujian Perangkat Lunak

FASE PERENCANAAN. MPSI sesi 4

The Process. A Layered Technology. Software Engineering. By: U. Abd. Rohim, MT. U. Abd. Rohim Rekayasa Perangkat Lunak The Process RPL

KONSEP MANAJEMEN PROYEK

TESTING DAN IMPLEMENTASI SISTEM. WAHYU PRATAMA, S.Kom., MMSI.

BAB II KONSEP PEMBANGUNAN SISTEM DARI PERSPEKTIF SOFTWARE ENGINEERING

PERANCANGAN SISTEM PENELUSURAN MATERIAL PT ALSTOM POWER ESI SURABAYA

Manajemen Proyek Perangkat Lunak Minggu 1

Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 1

PERENCANAAN PROYEK BERBASIS RISIKO PEMBANGUNAN SISTEM INFORMASI MANAJEMEN ASET DI PDAM KOTA MALANG BERBASIS ISO/FDIS 31000:2009

Pengembangan Sistem Informasi

Penyusunan Perangkat Kontrol Kualitas Perangkat Lunak Pada Aplikasi School Social Network (SSN) Berdasarkan ISO 25030

PERENCANAAN PROYEK BERBASIS RISIKO PEMBANGUNAN SISTEM INFORMASI MANAJEMEN ASET DI PDAM KOTAMADYA MALANG BERBASIS ISO/FDIS 31000:2009

SOFTWARE QUALITY ASSURANCE

Dimensi Kelembagaan. Kebijakan Kelembagaan 1. Perencanaan 0.5

MANAJEMEN KEBUTUHAN PERANGKAT LUNAK

BAB I PENDAHULUAN. Seiring dengan perkembangannya di perusahaan manufaktur, selain

Pertemuan 1 PENGENALAN REKAYASA PERANGKAT LUNAK

BAB I PENDAHULUAN. 1.1 Latar Belakang

BAB l Pengujian Perangkat Lunak

LAMPIRAN I. Kuisioner I : Management Awareness

A Layered Technology

Pengembangan Sistem Informasi

PENGANTAR RUP & UML. Pertemuan 2

Tugas Rekayasa Perangkat Lunak

MANAJEMEN RESIKO PROYEK PENGEMBANGAN PERANGKAT LUNAK MYBIZ 2 DI SOFTWARE HOUSE ABC

ISO/DIS 9001:2015 Pengenalan Revisi dan Transisi

Kebijakan Manajemen Risiko PT Semen Indonesia (Persero) Tbk.

Transkripsi:

UAS REKAYASA PERANGKAT LUNAK Software Quality Assurance HANSI ADITYA KURNIAWAN 9106205405 PROGRAM MAGISTER MANAJEMEN TEKNOLOGI INFORMASI INSTITUT TEKNOLOGI SEPULUH NOPEMBER SURABAYA 2007

Tujuan dari topik Software Quality Assurance (SQA) sebenarnya adalah untuk menghasilkan suatu produk perangkat lunak (software) yang berkualitas tinggi. SQA merupakan salah satu aktivitas yang harus dijalani dalam suatu proses pengembangan software seperti dapat terlihat pada Gambar 1.1. Common process framework Framework activities Task Sets Tasks Milestones, Deliverables SQA Points Umbrella activities Gambar 1.1 Proses Pengembangan Software SQA meliputi beberapa konsep sebagai berikut: 1. Pendekatan kualitas manajemen, 2. Teknologi rekayasa perangkat lunak yang efektif (metode dan tools yang digunakan), 3. Tinjauan teknis secara formal yang diaplikasikan melalui proses pengembangan software, 4. Strategi uji coba software yang multitier, 5. Kontrol terhadap dokumentasi software dan perubahannya, 6. Prosedur untuk memastikan pemenuhan standar pengembangan software, jika software tersebut diaplikasikan, dan 7. Mekanisme pengukuran dan laporan.

KONSEP KUALITAS Kontrol terhadap kualitas yang umum digunakan adalah kontrol terhadap variasi. Maksudnya adalah meminimalkan variasi terhadap sesuatu sehingga kualitas suatu produk dapat terjaga. Hal ini berlaku juga pada pengembangan software. Dari satu proyek pengembangan software ke proyek lainnya, maka sedapat mungkin diminimalkan perbedaan antara sumber daya yang diperkirakan dengan sumber daya yang sesungguhnya digunakan dalam proyek seperti staf, peralatan, waktu, dan sebagainya. Selain itu, pada umumnya, kontrol kualitas ini berlaku juga pada uji coba software dari versi satu ke pengembangan versi berikutnya. Tidak hanya meminimalkan kesalahan (bugs / errors) dari sebuah versi, akan tetapi juga harus dapat menurunkan kesalahan ketika mengembangkan versi berikutnya. Hal yang lain berhubungan dengan kontrol terhadap kualitas suatu software dapat terlihat pada minimalisasi terhadap perbedaan kecepatan dan akurasi dari respon dukungan masalah yang dialami customer. Kualitas Kualitas suatu software dapat diukur melalui karakteristiknya, seperti kompleksitas, kohesi, jumlah function points (FP), jumlah kode baris (lines of codes (LOC)), dan masih banyak lagi. Ketika dilakukan pengukuran terhadap karakteristik-karakteristik tersebut, maka akan muncul 2 jenis kualitas yaitu sebagai berikut: Quality of design Kualitas ini sangat erat hubungannya dengan desain dari suatu produk software. Tingkat material, toleransi, dan performa suatu spesifikasi berkontribusi besar kepada kualitas. Selama semakin tinggi tingkat material yang digunakan, semakin ketat toleransinya, dan semakin tinggi performa level yang dispesifikasikan, maka kualitas software semakin meningkat, jika produk tersebut sesuai spesifikasi pembuatannya. Dalam pengembangan software, hal ini meliputi kebutuhan user, spesifikasi, dan desain sistem.

Quality of conformance Kualitas ini sangat erat hubungannya dengan tingkat spesifikasi desain yang digunakan selama pembuatan software. Semakin tinggi tingkat spesifikasinya, maka semakin tinggi pula kualitasnya. Dalam pengembangan software, hal ini fokus pada implementasi. Jika implementasi software mengikuti desain, dan hasilnya memenuhi kebutuhan user serta mencapai tujuan, maka kualitas software tersebut semakin tinggi. Akan tetapi, tidak hanya kedua jenis kualitas tersebut yang harus diperhatikan oleh para software engineers. Menurut Robert Glass, lebih dari sekedar itu, yaitu: User satisfaction = compliant product + good quality + delivery within budget and schedule Menurut Glass, yang terpenting adalah kepuasan user, lebih dari hanya sekedar kualitas yang bagus. Kualitas bagus tetapi user tidak puas, maka semuanya sia-sia. Kontrol Kualitas Kontrol kualitas dilakukan dengan inspeksi, review, dan pengujian untuk memastikan suatu produk telah memenuhi kebutuhan yang diinginkan. Kontrol kualitas termasuk feedback, yang berjalan terus menerus dalam proses menciptakan suatu produk. Kombinasi dari pengukuran dan feedback dapat membantu menghindarkan kegagalan proses untuk memenuhi kebutuhan. Aktivitas pada kontrol kualitas dapat dilakukan secara otomatis, manual, atau kombinasi dari keduanya. Jaminan Kualitas Jaminan kualitas terdiri dari proses audit dan melaporkan fungsi dari manajemen. Tujuannya adalah untuk menyediakan data yang diperlukan kepada manajemen tentang kualitas produk dan menunjukkan bahwa produk tersebut sudah memenuhi kebutuhan yang ingin dicapai.

Biaya Kualitas Studi tentang biaya kualitas menyediakan dasar dari biaya kualitas itu sendiri, mengidentifikasi peluang untuk mengurangi biaya kualitas, dan menyediakan normalisasi perbandingan. Biaya kualitas dapat dibagi menjadi beberapa biaya yang berkaitan dengan pencegahan, penilaian, dan kegagalan. Yang termasuk biaya pencegahan adalah: Perencanaan kualitas Review teknis formal Perlengkapan pengujian Pelatihan Yang termasuk biaya penilaian adalah aktivitas untuk mendapatkan informasi tentang kondisi produk dari setiap proses. Contohnya adalah: Inspeksi proses dan antar-proses Pengujian dan perawatan peralatan Pengujian Biaya kegagalan adalah biaya yang akan dihilangkan ketika tidak ada kerusakan produk saat diberikan ke konsumen. Biaya kegagalan dibagi menjadi 2 yaitu biaya kegagalan internal dan eksternal. Biaya kegagalan internal muncul ketika produk diberikan kepada konsumen. Yang termasuk dalam biaya kegagalan internal adalah: Pengerjaan ulang Perbaikan Analisis kegagalan Biaya kegagalan eksternal berkaitan dengan kerusakan produk setelah produk tersebut sudah sampai kepada konsumen. Contoh dari biaya kegagalan eksternal adalah:

Adanya komplain konsumen Pengembalian dan penggantian produk Dukungan bantuan Jaminan SOFTWARE QUALITY ASSURANCE Banyak literatur yang mengungkapkan definisi dari kualitas software. Salah satunya, kualitas software didefinisikan sebagai pemenuhan kebutuhan fungsional dan performansi, yang secara eksplisit didokumentasikan sesuai standar yang ada, serta secara implisit merupakan pemenuhan harapan dari para pengembang software. Latar Belakang Seperti sudah disinggung sedikit di atas, jaminan kualitas adalah suatu aktivitas tambahan dari semua bisnis yang menghasilkan produk untuk digunakan oleh orang lain, yang sudah menjadi tanggung jawab dari pembuat produk tersebut. Pada jaman sekarang ini, setiap perusahaan mempunyai mekanisme masing-masing untuk menjamin kualitas dari produk tersebut, dimana hal ini sudah menjadi kepedulian dari perusahaan. Sejarah dari SQA berkembang secara paralel dengan sejarah dari kualitas hardware. SQA diperkenalkan pertama kali pada saat kontrak pembuatan software di bidang militer pada tahun 1970an, dimana kemudian berkembang ke dunia komersial. Sebelumnya pada tahun 1950an dan 1960an, jaminan kualitas suatu software merupakan tanggung jawab tunggal dari seorang programmer. Akan tetapi, sekarang jaminan kualitas software sudah menjadi tanggung jawab beberapa pihak, seperti software engineer, manajer proyek software, konsumen, produsen, distributor, dan masing-masing individu yang terkait dengan produk tersebut.

Aktivitas SQA SQA mengandung bermacam-macam tugas yang berhubungan dengan konstituensi yang berbeda, dimana para pembuat software akan mengerjakan pekerjaan-pekerjaan teknikal sedangkan grup SQA mempunyai tanggung jawab untuk merencanakan penilaian kualitas software, pencatatan, analisis, dan pembuatan laporan atas kualitas software yang telah dibuat. Dari sini, kualitas para pembuat software dapat dinilai melalui ukuran-ukuran dan metode-metode tertentu, serta melalui pengujian-pengujian software. Oleh karena itu, para pembuat software diharapkan dapat membuat suatu produk software yang berkualitas tinggi. Berikut adalah aktivitas-aktivitas SQA: Mempersiapkan perencanaan SQA untuk sebuah proyek. Berpartisipasi dalam pengembangan sebuah deskripsi proyek software. Meninjau aktivitas pembuatan software untuk memverifikasi pemenuhan kebutuhan software yang telah didefinisikan sebelumnya. Melakukan audit terhadap produk software untuk memverifikasi pemenuhan kebutuhan software yang telah didefinisikan sebelumnya. Memastikan deviasi dari pengerjaan software dan produknya didokumentasikan sesuai format yang ditentukan. Mencatat adanya ketidaksesuaian dan masalah yang terjadi untuk dilaporkan ke manajemen senior. Berikut akan dijelaskan satu studi kasus tentang SQA yang digunakan di Departemen Pertahanan Energi Nuklir. Departemen ini merasa adanya masalah yang terjadi dan dibutuhkan suatu SQA untuk melakukan audit dan analisis terhadap masalah tersebut. Tools yang digunakan di studi kasus ini adalah Integrated Safety Management (IST).

STUDI KASUS SOFTWARE QUALITY ASSURANCE (SQA) YANG BERKAITAN DENGAN KEAMANAN DI DEPARTEMEN PERTAHANAN ENERGI NUKLIR Pendahuluan Departemen Energi dan kontraktornya melakukan pekerjaan berbahaya yang diperlukan untuk keamanan negara dan memperbaiki lingkungan di fasilitas produksi energi pertahanan nuklir. Performa dari pekerjaan ini yang paling penting adalah perlindungan keselamatan bagi publik, pekerja, dan lingkungan itu sendiri. Kunci dan tools yang digunakan untuk mencapai tujuan tersebut adalah Integrated Safety Management (ISM), yaitu suatu sistem yang didesain untuk menjamin syarat suatu keamanan yang terintegrasi dengan perencanaan dan eksekusi suatu pekerjaan. Fungsi dari ISM adalah melakukan analisis tingkat bahaya yang muncul dari pekerjaan tersebut dan mengidentifikasi kontrol tindakan pencegahannya. Tujuan dari software quality assurance (SQA) di sini adalah untuk memastikan bahwa software yang dibuat dapat memenuhi syarat yang disebutkan di ISM. Kode-kode komputer dan model-model serta data yang berhubungan merupakan data yang penting untuk digunakan. Semuanya itu digunakan sebagai pendekatan untuk menentukan SQA ketika software tersebut diimplementasikan. SQA menyediakan ukuran yang didesain untuk memastikan suatu software berjalan sesuai fungsinya secara konsisten dan modifikasi terhadap software tersebut tidak menghasilkan suatu masalah yang besar. Ukuran tersebut harus dipakai sepanjang pengembangan software secara sistematik, mulai testing, dokumentasi, sampai eksekusi suatu software, dan saat pemeliharaan software. Adanya pengarahan yang tidak jelas terhadap standar dan kebutuhan dari SQA dan penggunaannya memunculkan bahaya yang harus segera dianalisis. Dari sini, beberapa aspek ISM yang dapat digunakan sebagai tools SQA adalah sebagai berikut:

Definisi dan batasan kerja harus diprioritaskan sebagai basis yang signifikan untuk keamanan, dimana sering diputuskan dengan menggunakan bantuan tools software. Analisis terhadap bahaya membutuhkan kode berkualitas tinggi untuk estimasi kepentingan dan konsekuensi akan potensi terjadinya kecelakaan. Identifikasi terhadap kontrol membutuhkan kode berkualitas tinggi untuk diputuskan terhadap kontrol administrasi dan signifikasi terhadap sistem, struktur, dan komponen akan adanya keamanan. Tingkah laku kerja yang aman membutuhkan konfidensi yang tinggi dimana software komputer yaitu Software Instrumentation and Control (I&C) akan beroperasi lebih tangguh. Status SQA Sekarang Software di Departemen Pertahanan Energi Nuklir Suatu integrasi dan infrastruktur yang efektif untuk implementasi SQA belum ada di Departemen Pertahanan Energi Nuklir. Suatu infrastruktur yang efektif termasuk riset yang sedang berjalan dan pengembangan dari kode-kode program, program kontrol konfigurasi kode, pelatihan yang terstandar, dan petunjuk dari kode-kode program tersebut. Dengan hal-hal ini, yang ditunjang dengan elemen-elemen lainnya dapat diintegrasikan menjadi suatu infrastruktur yang dapat memperbaiki masalah SQA di Departemen tersebut. Berikut adalah fokus detail yang dilakukan: Kode-kode untuk analisis masalah Kode-kode tersebut digunakan untuk menghitung adanya konsekuensi terjadinya masalah untuk mendukung identifikasi dan klasifikasi kontrol serta analisis bahaya. Software Instrumentation and Control (I&C) Software ini digunakan untuk kontrol terhadap kinerja serta menyediakan informasi tentang status proses atau sistem secara fisik.

Perbedaan (Gap) Infratruktur di Departemen Pertahanan Energi Nuklir Sumber masalah yang dialami Departemen ini adalah tidak adanya infrastruktur yang efektif untuk melakukan SQA. Fungsi umum dari SQA sudah didefinisikan, akan tetapi tidak dijalankan secara efektif secara teknikal. Selain itu tidak ada panduan dan training terhadap penggunaan kode-kode yang ada di Departemen tersebut. Berikut adalah tindakan-tindakan yang dapat digunakan untuk mengembangkan SQA menjadi lebih baik: Cari keuntungan dari penemuan Accident Phenomenology and Consequence (APAC). APAC adalah suatu metodologi program yang dibuat pada tahun 1994 yang digunakan untuk memastikan penggunaan kode-kode untuk analisis keselamatan dan dapat digunakan untuk pengembangan kode-kode di masa mendatang. Tanggung jawab SQA terhadap hal ini adalah: - Performa verifikasi dan validasi setelah pengembangan kode analisis masalah. - Perawatan dan distribusi dari kode analisis masalah. - Identifikasi lingkup analisis masalah dimana kode yang sekarang tidak ada dan tidak sesuai, sehingga dibutuhkan teknik dan tools. - Pengarahan dari riset dan pengembangan yang sesuai dan fokus pada pengembangan kode baru untuk memenuhi kebutuhan lingkup analisis masalah yang sudah didefinisikan sebelumnya dan menjamin SQA diintegrasikan ke dalamnya. Mengintegrasikan semua usaha dan program Departemen yang terkait dengan SQA, seperti usaha untuk memperoleh efek yang produktif dan realisasi yang kompleks. Berikut adalah pengukuran yang dapat dilakukan: - Pengembangan atau identifikasi dari standar verifikasi dan validasi, serta menyetujui kriteria yang wajar di dalam penggunaannya. - Memindahkan putusan kepada Departemen untuk memilih standar SQA yang akan digunakan di dalam operasinya. Termasuk di dalamnya adalah dengan menggunakan sistem software I&C.

Kesimpulan Karena di Departemen Pertahanan Energi Nuklir masih belum ada SQA yang dijalankan, maka diharapkan Departmen dapat melakukan SQA dengan menggunakan tools ISM. Untuk menerapkan hal tersebut, maka pihak Departemen membutuhkan hal-hal sebagai berikut: Membuat standar di Departemen untuk secara praktis diterapkan di SQA. Mengidentifikasi semua elemen organisasi yang seharusnya terlibat peda pembuatan, pengujian, dokumentasi, perawatan, serta eksekusi software. Menyediakan dana yang cukup untuk menjalankan SQA. Menediakan manajemen proyek yang fokus dan terintegrasi untuk menjalankan SQA.

LAMPIRAN Berikut adalah lampiran beberapa hasil yang didapatkan dari program APAC. Tabel-tabel tersebut diambil dari informasi pembuat kode, organisasi, dan status SQA dari kode. Pada bagian kolom Status SQA/V&V merupakan status dari SQA yang ada di Departemen hasil dari analisa APAC pada Departemen tersebut.

Keterangan: Code adalah kode yang menjalankan suatu fungsi tertentu, sebagai contoh adalah MACCS2 (MELCOR Accident Consequence Code System 2) adalah suatu kode yang digunakan untuk menghitung kesehatan dan konsekuensi ekonomi ketika ada kecelakaan akibat radioaktif. Code Developer / Sponsor adalah pembuat kode atau sponsor dari pembuat kode Current Owner / Technical Support adalah pemilik dari pembuat kode. Status Of SQA/V&V adalah status dari SQA suatu kode General Comments adalah komentar dari internal Departemen

DAFTAR PUSTAKA Defense Nuclear Facility Safety Board (2000), Quality Assurance For Safety- Related Software At Department Of Energy Defense Nuclear Facility, Technical Report Pressman, R. (2005), Software Engineering : A Practitioner Approach, McGraw- Hill