Dukungan Terhadap Program IGOS (Indonesia Go Open

3.7.2 Dukungan Terhadap Program IGOS (Indonesia Go Open

Source)

Penggunaan piranti lunak open source telah mulai mendapatkan momentum dan mendorong Pemerintah Provinsi Riau untuk mengembangkan teknologi informasi global melalui pengembangan dan pemanfaatan Open Source Software (OSS) dalam rangka memperkuat sistem teknologi informasi nasional.

Meski dalam tingkatan dan intensitas yang berbeda, namun momentum penerapan piranti lunak open source ini akan sekaligus menjadi inisiasi yang prospektif, jika hal itu dapat dilakukan dengan baik.

Dengan adanya produk Open Source saat ini, yang mesti dilakukan oleh instansi pemerintah dalam hal ini provinsi Riau, adalah adanya kemampuan untuk membangun, mengoperasikan dan mengembangkan Open Source software, sesuai dengan visi yang dicanangkan dalam Program Indonesia Go Open Source. Kemampuan tersebut tidak terlepas harus didukung oleh kualitas sumber daya manusianya, terutama adalah mengenai pengetahuan mengenai TI.

Beberapa manfaat yang diperoleh bagi pengguna dalam mengembangkan dan memanfaatkan Open Source Software diantaranya adalah :

1. Masyarakat Pengguna

a. Memberikan alternatif pilihan perangkat lunak desktop yang murah

b. Meningkatkan pengetahuan masyarakat tentang teknologi informasi

c. Memperkecial kesenjangan teknologi informasi

d. Meningkatkan akses informasi masyarakat d. Meningkatkan akses informasi masyarakat

2. Pemerintah

a. Memperkecil biaya pembelian perangkat lunak (khususnya pengguna sistem operasi desktop dan jaringan)

b. Menghemat devisa dalam pengadaan perangkat lunak

c. Menumbuhkan industri perangkat lunak dalam negeri sehingga dapat meningkakan inovasi bidang teknologi informasi

d. Memberi peluang untuk pengembangan perangkat lunak dalam permasalahan lokal spesifik

e. Perusahan institusi dapat lebih mengetahui business process dengan cara improvement modifikasi

f. Mengurangi permasalahan intellectual property right.

g. Mempromosikan kompetisi bidang teknologi informasi

h. Meningkatkan keterbukaan dan faktor keamanan sistem

3. Industri pengembangan

a. Meningkatkan pengembangan industri perangkat lunak nasional

b. Biaya rendah dalam memasuki industri perangkat lunak

c. Mengembangkan kemampuan sumber daya manusia bidang teknologi informasi

d. Pemindahan paradigma dari import TI menjadi export TI Pengembangan dan pemanfaatan Open Source Software (OSS) sangat

memungkinkan bagi Pemerintah Provinsi Riau untuk dapat menekan pengeluaran biaya untuk membeli perangkat lunak sehingga anggaran biaya dapat digunakan untuk peningkatan pelayanan dan mutu.

Beberapa layanan yang dapat dipertimbangkan sebagai suatu bentuk model bisnis teknologi informasi baru seperti :

a. Pelayanan instalasi,

b. kontrak perawatan,

c. pelatihan penggunaan,

d. penyesuaian (kustomisasi) perangkat lunak tersebut ke dalam lingkungan kerja, d. penyesuaian (kustomisasi) perangkat lunak tersebut ke dalam lingkungan kerja,

3.7.2.1 Standar Spesifikasi Perangkat Lunak 3.7.2.1.1 Pendahuluan

Standar Spesifikasi Perangkat Lunak diperlukan untuk memberikan acuan baku yang seragam bagi pengembangan perangkat lunak yang berkelanjutan. Standar Spesifikasi Perangkat Lunak ini ditujukan untuk diimplementasikan dalam bentuk dokumentasi perangkat lunak yang memberikan gambaran utuh dan menyeluruh dari sistem aplikasi perangkat lunak yang dibangun.

Dibawah ini merupakan bagian-bagian spesifikasi perangkat lunak dengan urutan sebagai berikut :

1. OCD (Operational Concept Description)

2. SSS (System/SubSystem Specification)

3. SD (System/SubSystem Design Description)

4. SRS (Software Requirement Specification)

5. SDD (Sofware Design Description)

6. SPS (Software Product Specification)

3.7.2.1.2 OCD (Operational Concept Description)

Gambaran sistem ini dikemukakan bagi kebutuhan pengguna dalam hubungannya dengan prosedur/sistem yang berlaku dan bagaimana cara penggunaannya.

OCD dimaksudkan untuk :

1. Menyediakan informasi yang dibutuhkan developer untuk memahami bagaimana mempertemukan kebutuhan para pengguna dengan menggambarkan

bermaksud untuk menggunakan sistem tersebut.

bagaimana

pengguna

2. Memberikan pengertian developer pada si pemeroleh tentang bagaimana si pengguna bermaksud untuk menggunakan sistem.

3. Menyediakan informasi bagi para agen pendukung yang dapat membantu menggambarkan persyaratan pendukung bagi long-lead items (misalnya fasilitas dan personil), mensahkan konsep pendukung, dan membantu personil agen pendukung untuk memahami sistem ketika modifikasi dan perbaikan diperlukan.

4. Menyediakan konfirmasi bagi pengguna dimana si pemeroleh telah menyediakan interpretasi yang benar bagi developer tentang kebutuhan pengguna dan prioritas untuk sistem tersebut.

Dibawah ini merupakan hal-hal yang harus dijelaskan dalam spesifikasi OCD.

1. Sistem atau situasi sekarang

1.1. Latar belakang, tujuan dan jangkauan

1.2. Kebijakan dan hambatan-hambatan operasional

1.3. Gambaran sistem sekarang atau situasi

1.3.1. Lingkungan operasional dan karakteristiknya

1.3.2. Komponen-komponen Mayor sistem dan interkoneksinya

1.3.3. Interfaces pada sistem eksternal atau prosedur

1.3.4. Kemampuan-kemampuan sistem/fungsi-fungsi

1.3.5. Diagram dan gambaran-gambaran input, output, data flow, dan manual dan proses otomatis yang cukup untuk memahami current sistem atau situasi dari sisi pandang pengguna.

1.3.6. Karakteristik keberhasilan (kecepatan, throughput, volume, frekuensi)

1.3.7. Perlengkapan kualitas (reliabilitas, maintainabilitas, availabilitas, flexibilitas, portabilitas, usabilitas, efisiensi)

1.3.8. Perlengkapan bagi keamanan, perlindungan, privasi dan kelanjutan operasi pada keadaan darurat

1.4. Pengguna atau personil yang terlibat.

1.5. Konsep pendukung.

2. Justifikasi dan sifat perubahan-perubahan

2.1. Justifikasi bagi perubahan.

2.1.1. Menggambarkan aspek-aspek kebutuhan pengguna, ancaman, misi, tujuan, lingkungan, interface, personil yang baru atau yang sudah dimodifikasi atau faktor-faktor lain yang membutuhkan sistem yang baru atau yang sudah dimodifikasi

2.1.2. Rangkuman defisisensi atau pembatasan pada current system atau situasi yang membuatnya memungkinkan untuk merespon pada faktor-faktor ini.

2.2. Gambaran perubahan-perubahan yang dibutuhkan.

2.3. Prioritas diantara perubahan-perubahan tersebut.

2.4. Perubahan-perubahan yang telah dipertimbangkan tetapi tidak termasuk.

2.5. Asumsi dan hambatan-hambatan.

3. Konsep bagi sistem baru atau yang telah dimodifikasi (idem dengan poin 1)

4. Skenario Operasional Peranan sistem baru atau sistem yang telah dimodifikasi, interaksinya

dengan pengguna lain, interfacenya dengan sistem lain dan segala keadaan dan cara-cara yang mengidentifikasikan sistem. Termasuk keadaan, tindakan, stimuli, informasi, interaksi, dan lain-lain.

5. Ringkasan pengaruh-pengaruh.

5.1. Pengaruh-pengaruh operasional. Pengaruh-pengaruh operasional yang diantisipasi pada pengguna,

pemeroleh, developer dan agen pendukung. Termasuk perubahan dalam interface dengan pusat-pusat operasi komputer; perubahan dalam pemeroleh, developer dan agen pendukung. Termasuk perubahan dalam interface dengan pusat-pusat operasi komputer; perubahan dalam

5.2. Pengaruh-pengaruh organisasi. Pengaruh-pengaruh organisasi yang diantisipasi pada pengguna,

pemeroleh, developer dan para agen pendukung, mungkin termasuk modifikasi tanggung jawab; tambahan atau penghapusan tanggung jawab atau jabatan; kebutuhan akan pelatihan dan pelatihan kembali; dan perubahan dalam jumlah,tingkat keahlian, pengidentifikasi posisi, atau tempat personil dalam beragam cara operasi.

5.3. Pengaruh-pengaruh selama perkembangan. Pengaruh-pengaruh yang diantisipasi pada pengguna, pemeroleh,

developer dan para agen pendukung selama berlangsung usaha pengembangan, mungkin termasuk pertemuan/diskusi mengenai sistem baru; pengembangan atau modifikasi database; pelatihan; operasi paralel sistem baru yang berlaku; pengaruh-pengaruh selama pengujian sistem baru; dan kegiatan lain yang memerlukan bantuan atau monitor perkembangan.

6. Analisis sistem yang diusulkan.

6.1. Ringkasan keuntungan. Kualitatif dan kuantitatif. Termasuk kemampuan-kemampuan baru,

kemampuan-kemampuan yang ditingkatkan, dan keberhasilan yang dikembangkan, dan hubungannya dengan kekurangan-kekurangan yang ditunjukan pada 2.1.

6.2. Rangkuman kerugian/pembatasan. Kualitatif dan kuantitatif. Termasuk kemampuan-kemampuan yang

hilang, keberhasilan yang kurang dari yang diharapkan, lebih besar daripada penggunaan yang diharapkan dari sumber-sumber hardware komputer, pengaruh-pengaruh opersional yang tidak diharapkan, konflik-konflik dengan asumsi pengguna, dan asumsi lain dan hambatan-hambatan yang lain.

6.3. Alternatif dan pertimbangan trade-offs. Mengidentifikasi dan menggambarkan alternatif pokok yang telah

dipertimbangkan pada sistem atau karakteristiknya, trade-offs diantara mereka, dan rasional bagi keputusan yang dicapai.

3.7.2.1.3 SSS (System/SubSystem Specification) SSS digunakan untuk menentukan persyaratan bagi sebuah sistem atau

subsistem dan metoda-metoda yang digunakan untuk memastikan bahwa setiap persyaratan telah bertemu sebagai dasar bagi pengujian desain dan kualifikasi sitem atau subsistem.

Syarat-syarat :

1. Keadaan dan cara-cara yang dibutuhkan.

2. Syarat-syarat kemampuan sistem. Mengidentifikasikan suatu kemampuan sistem yang diperlukan dan

memperinci persyaratan yang berhubungan dengan kemampuan. Persyaratan identik dengan menentukan perilaku yang dibutuhkan oleh

sistem yang terkait pada parameter yang berlaku, misalnya, response times, sekuensi, ketepatan, kapasitas, prioritas.

2.1. Syarat-syarat antarmuka eksternal sistem.

2.1.1. Identifikasi antarmuka dan diagram.

2.1.2. Pengidentifikasi proyek-unik antarmuka.

2.2. Syarat-syarat antarmuka internal sistem.

2.3. Syarat-syarat data internal sistem.

2.4. Syarat-syarat adaptasi. Data instalasi-dependen, parameter operasi yang mungkin bervariasi dan

tergantung pada kebutuhan operasi.

2.5. Syarat-syarat keamanan.

2.6. Syarat-syarat perlindungan kebebasan pribadi. Kebijakan, lingkungan operasi, tipe dan tingkatan, resiko, usaha

perlindungan yang diperlukan, kemampuan pertanggungjawaban, kriteria untuk sertifikasi/akreditasi.

2.7. Syarat-syarat lingkungan sistem. Hardware dan sistem pengoperasian software harus berjalan. Kondisi

lingkungan selama pengangkutan, penyimpanan dan pengoperasian.

2.8. Syarat-syarat sumber komputer.

2.8.1. Syarat-syarat hardware komputer.

2.8.2. Syarat-syarat penggunaan sumber hardware komputer.

2.8.3. Syarat-syarat software komputer.

Sistem operasi,

database, software komunikasi/jaringan kerja, kegunaan software, input dan simulator perlengkapan, tes software, dan software manufacturing.

sistem

manajemen

2.8.4. Syarat-syarat komunikasi komputer. Lokasi geografi yang berhubungan; konfigurasi dan topologi network;

teknik transmisi; tarif transfer data; pintu gerbang; sistem yang dibutuhkan dalam penggunaan waktu; tipe dan volume data yang akan dikirimkan/diterima;

waktu untuk pengiriman/penangkapan/jawaban; volume puncak data; dan ciri-ciri diagnosa.

batas

2.9. Faktor-faktor kualitas sistem. Suatu sistem yang memiliki kualitas baik harus memenuhi beberapa

faktor, diantaranya sebagai berikut :

a. maintainabilitas, kemampuan pemeliharaan, kemampuan untuk kemudahan servis, reparasi, atau pengoreksian.

b. availabilitas, kemampuan untuk dioperasikan dan diakses dengan mudah ketika diperlukan.

c. fleksibilitas, kemampuan untuk disesuaikan dengan mudah pada perubahan syarat-syarat atau aturan.

d. portabilitas software, kemampuan untuk dimodifikasi dengan mudah untuk suatu lingkungan baru.

e. Reusabilitas, kemampuan untuk digunakan dengan mudah dalam aplikasi yang beragam.

f. Testabilitas, kemampuan untuk diuji dengan mudah dan menyeluruh.

g. Usabilitas, kemampuan untuk dipelajari dan digunakan dengan mudah dan perlengkapan yang lain.

2.10. Hambatan-hambatan desain dan konstruksi. Persyaratan ini mungkin diperinci dengan referensi pada standar dan

spesifikasi yang sesuai. Sebagai contoh, persyaratan mengenai penggunaan arsitektur sistem yang khusus atau persyaratan pada arsitektur penggunaan desain khusus atau standar konstruksi; penggunaan bahasa pemrograman yang khusus; persyaratan workmanship dan tekhnik produksi, karakteristik sistem (misalnya batas berat, batas dimensi, warna, pencegah pelapisan); interchangeabilitas

bagian-bagian; kemampuan untuk diangkut dari suatu tempat ke tempat lain; kemampuan untuk dibawa atau dipasang oleh seseorang, atau nomor yang diberikan, orang, material yang bisa atau tidak bisa digunakan; persyaratan pada penanganan material yang mengandung racun; batas- batas pada radiasi elektromagnetik yang sistemnya dibolehkan untuk dibangkitkan, penggunaan pelat nama, penandaan bagian, serial dan sejumlah penandaan, dan penandaan identifikasi yang lain, fleksibilitas dan expandabilitas yang harus disediakan untuk mendukung antisipasi wilayah-wilayah yang berkembang atau berubah dalam teknologi, ancaman atau misi.

2.11. Syarat-syarat yang berhubungan dengan personal.

Sejumlah stasiun kerja, membangun pertolongan dan ciri-ciri pelatihan, faktor-faktor kemanusiaan persyaratan insinyur.

2.12. Syarat-syarat pelatihan yang bersangkutan. Pelatihan perlengkapan dan pelatihan material yang dimasukan di dalam

sistem.

2.13. Syarat-syarat logistik yang bersangkutan.

2.14. Syarat-syarat yang lain.

2.15. Syarat-syarat pengemasan.

2.16. Syarat-syarat preseden dan kekritisan/kritikalitas.

3. Penentuan kualifikasi. (untuk masing-masing persyaratan di dalam poin 1) Demonstrasi, Tes, Analisis, Inspeksi, Metoda-metoda kualifikasi khusus.

4. Syarat-syarat kemampuan pelacakan.

4.1. Kemampuan pelacakan dari setiap persyaratan subsistem di dalam spesifikasi ini pada persyaratan sistem yang dimaksud.

4.2. Kemampuan pelacakan dari setiap persyaratan sistem yang telah dialokasikan pada subsistem yang dilindungi oleh spesifikasi ini pada persyaratan subsistem yang dimaksud.

3.7.2.1.4 SD (System/SubSystem Design Description)

SD berfungsi untuk menggambarkan sistem atau subsistem dengan desain luas dan desain arsitektural sistem atau subsistem yang digunakan sebagai dasar bagi perkembangan sistem selanjutnya. Beberapa hal yang harus diperhatikan dalam menggambarkan sistem dan subsistem, diantaranya yaitu :

1. Keputusan-keputusan desain luar sistem. I/O & interface, perilaku (tindakan, keberhasilan) dalam respon, database,

pendekatan untuk persyaratan keamanan/perlindungan/privasi, pilihan untuk sistem hardware/software, pendekatan untuk menyediakan fleksibilitas /availabilitas /maintainabilitas.

2. Desain arsitektural sistem. Jika sebagian atau seluruh desain tergantung pada keadaan dan cara-

cara sistem, kepercayaan ini akan diusulkan. Dituliskan berkenaan dengan penyelenggaraan sistem yang langsung ke

dalam Hardware Configuration Items (HWCIs), Computer Software Configuration Items (CSCIs), dan operasi-operasi manual, tetapi sebaiknya dimaksudkan untuk meliputi penyelenggaraan sistem ke dalam subsistem, penyelenggaraan suatu subsistem ke dalam HWCIs, CSCIs, dan operasi-operasi manual atau variasi lain yang diperlukan.

2.1. Komponen-komponen sistem. Identifikasi komponen, hubungan-hubungan statis, perkembangan status,

penggunaan sumber, pohon spesifikasi.

2.2. Konsep pelaksanaan. Menggambarkan konsep pelaksanaan diantara komponen-komponen

sistem, mungkin termasuk diagram, dan deskripsi yang menunjukan hubungan komponen-komponen yang dinamis, yaitu bagaimana mereka akan berinteraksi selama operasi sistem, termasuk yang dapat dipakai, urutan kontrol pelaksanaan, data alir, sekuensing yang dikontrol secara dinamis, diagram transisi keadaan, diagram waktu, prioritas diantara komponen, penanganan interupsi, hubungan waktu/sekuensing, penanganan

yang bersamaan, alokasi/dealokasi yang dinamis, kreasi/penghapusan obyek yang dinamis, proses, tugas-tugas, dan aspek-aspek perilaku dinamis yang lain.

kekecualian,

pelaksanaan

2.3. Desain interface.

2.3.1. Diagram dan identifikasi interface.

2.3.2. Proyek unik pengidentifikasi interface. Deskripsi desain mungkin termasuk yang berikut ini, ditunjukan dalam

perintah yang sesuai dengan informasi yang disediakan, dan mungkin mencatat beberapa perbedaan dalam karakteristik ini dari sisi pandang kesatuan interfacing (misalnya perbedaan harapan mengenai ukuran, perintah yang sesuai dengan informasi yang disediakan, dan mungkin mencatat beberapa perbedaan dalam karakteristik ini dari sisi pandang kesatuan interfacing (misalnya perbedaan harapan mengenai ukuran,

3. Syarat traceability (kemampuan pelacakan).

3.7.2.1.5 SRS (Software Requirement Specification)

SRS berfungsi untuk menentukan persyaratan bagi Computer Software Configuration Item (CSCI) dan metoda-metoda yang digunakan untuk memastikan bahwa setiap persyaratan telah bertemu, dugunakan sebagai dasar bagi pengujian desain dan kualifikasi CSCI. Beberapa hal yang harus diperhatikan dalam menerapkan SRS, diantaranya yaitu :

1. Persyaratan. Kondisi-kondisi untuk penerimaan CSCI ini, persyaratan diadakan untuk

memenuhi sistem requirements yang dialokasikan pada CSCI ini, traceability, metoda-metoda kualifikasi.

Tingkatan aturannya secara rinci; Termasuk karakteristik CSCI yang dikondisikan bagi penerimaan CSCI; Menangguhkan untuk mendesain deskripsi karakteristik tersebut.

1.1. Keadaan dan cara-cara yang diperlukan.

1.2. Persyaratan kemampuan CSCI. Kemampuan identik dengan fungsi, subyek, obyek atau istilah lain

yang berguna untuk menyampaikan persyaratan.

1.2.1. (Kemampuan CSCI ). Mengidentifikasi kemampuan sistem yang diperlukan dan menguraikan

persyaratan yang berhubungan dengan kemampuan. Definisi persyaratan dalam konteks ini adalah menentukan perilaku

sistem yang diperlukan dan mungkin termasuk parameter yang biasa diterapkan, misalnya waktu respon, waktu throughput, hambatan- hambatan mengenai waktu yang lain, sekuensing, ketepatan, kapasitas, (seberapa banyak), prioritas, kelanjutan persyaratan operasi, dan penyimpangan yang dibolehkan berdasarkan kondisi- kondisi operasi.

Persyaratan termasuk perilaku yang diperlukan di bawah kondisi- kondisi yang tidak diperkirakan, tidak diijinkan, atau keluar batas sehingga diperlukan untuk penanganan kesalahan fatal dan segala sesuatu yang menjamin kelanjutan operasi pada keadaan darurat.

1.3. Persyaratan interface eksternal CSCI .

1.3.1. Diagram dan identifikasi interface. Berfungsi mengidentifikasi interface eksternal CSCI (yaitu, hubungan

dengan kesatuan yang lain yang melibatkan pembagian, menyediakan atau bertukar data). Identifikasi setiap interface termasuk sebuah pengidentifikasi proyek unik yang akan menandakan kesatuan interfacing (sistem, konfigurasi item, pengguna, dan lain-lain) dengan nama, nomor, versi, dan dokumentasi referensi. Identifikasi akan menyatakan kesatuan mana yang telah memiliki karakteristik interface yang tetap (dan oleh karena itu menentukan persyaratan dalam meng- interfacing kesatuan) yang dikembangkan atau dimodifikasi (sehingga memiliki persyaratan interface yang ditentukan). Satu atau lebih diagram interface akan disediakan untuk menggambarkan interfaces.

1.3.2. (Proyek unik pengidentifikasi interface).

1.4. Persyaratan interface internal CSCI.

1.5. Persyaratan data internal CSCI.

1.6. Persyaratan adaptasi.

Mengenai pemasangan data dependen yang akan disediakan oleh CSCI (seperti site-dependent latitude dan longitude atau site- dependent state tax codes) dan parameter operasional dimana CSCI perlu digunakan yang mana mungkin bervariasi tergantung pada kebutuhan operasional (seperti parameter yang mengindikasikan perekaman data atau operasi-dependent targeting constants).

1.7. Persyaratan keamanan.

1.8. Persyaratan sekuriti dan privasi. Persyaratan ini akan termasuk lingkungan, privasi/sekuriti yang harus

dioperakan oleh CSCI, tipe dan tingkatan sekuriti atau privasi yang disediakan, resiko-resiko sekuriti atau privasi yang harus antisipasi oleh CSCI, kebutuhan safeguards untuk mengurangi resiko-resiko tersebut, kebijaksanaan sekuriti atau privasi yang harus bertemu, countabilitas sekuriti atau privasi yang harus disediakan CSCI, dan kriteria yang harus dipertemukan untuk sertifikasi dan akreditasi sekuriti atau privasi.

1.9. Persyaratan lingkungan CSCI.

Termasuk hardware komputer dan sistem operasi dimana CSCI harus berjalan.

1.10. Persyaratan sumber komputer.

1.10.1. Persyaratan hardware komputer. Persyaratan ini termasuk nomor setiap tipe perangkat, tipe,

ukuran, kapasitas, dan karakteristik lain prosesor, memori, input/output devices, penyimpanan auxiliary yang diperlukan dan juga perangkat jaringan/komunikasi serta perangkat lain yang diperlukan.

1.10.2. Persyaratan penggunaan sumber hardware komputer. Misalnya penggunaan kapasitas prosesor maksimum yang

dibolehkan, kapasitas memori, kapasitas input/output device, kapasitas auxiliary storage device, dan kapasitas perangkat jaringan/komunikasi. Persyaratan (dinyatakan misalnya sebagai presentasi kapasitas setiap sumber hardware komputer) akan termasuk kondisi-kondisi, jika ada, dibawah penggunaan sumber yang akan diukur.

1.10.3. Persyaratan software komputer.

1.10.4. Persyaratan komunikasi komputer.

1.11. Faktor-faktor kualitas software. Faktor ini terdiri dari persyaratan kuantitatif berdasarkan

fungsionalitas CSCI (kemampuan untuk menyelenggarakan seluruh fungsi yang diperlukan), reliabilitas (kemampuan untuk menyelenggarakannya dengan benar dan hasil yang konsisten), maintainabilitas (kemampuan untuk dikoreksi dengan mudah), availabilitas (kemampuan untuk diakses dan dioperasikan ketika dibutuhkan), flexibilitas (kemampuan diadaptasi dengan mudah untuk perubahan persyaratan), portabilitas (kemampuan untuk dimodifikasi dengan mudah untuk sebuah lingkungan baru), reusabilitas (kemampuan untuk digunakan pada aplikasi multiple), testabilitas (kemampuan untuk diuji dengan mudah dan menyeluruh), usabilitas (kemampuan untuk dipelajari dan digunakan) dan perlengkapan yang lain.

1.12. Hambatan-hambatan desain and implementasi.

Hambatan ini dispesifikasikan dengan referensi untuk menyesuaikan standar komersial atau militer dan spesifikasi. Contoh-contoh yang termasuk persyaratan mengenai:

1.12.1. Penggunaan arsitektur CSCI tertentu atau persyaratan dalam arsitektur, misalnya unit software atau database yang diperlukan; penggunaan standar militer, atau komponen- komponen yang berlaku; atau penggunaan properti lengkap milik pemerintah/pemeroleh (peralatan, informasi, atau software)

1.12.2. Penggunaan standar-standar desain dan implementasi tertentu; penggunaan bahasa programing tertentu.

1.12.3. Flexibilitas dan expandabilitas yang harus disediakan untuk mendukung antisipasi kemajuan wilayah atau perubahan dalam teknologi, ancaman atau misi.

1.13. Persyaratan personil yang terlibat. Termasuk untuk mengakomodasi jumlah, tingkat keahlian, lingkaran tugas,

kebutuhan akan pelatihan atau informasi lain mengenai personil yang akan menggunakan atau mendukung CSCI. Contoh-contoh yang termasuk ke dalam persyaratan untuk sejumlah pengguna bersama dan untuk kebutuhan akan pelatihan atau informasi lain mengenai personil yang akan menggunakan atau mendukung CSCI. Contoh-contoh yang termasuk ke dalam persyaratan untuk sejumlah pengguna bersama dan untuk

1.14. Persyaratan pelatihan yang berhubungan. Termasuk pelatihan software dimasukan ke dalam CSCI.

1.15. Persyaratan logistik yang berhubungan. Pertimbangan-pertimbangan ini mungkin saja termasuk ke dalam: sistem

maintenance, software support, sistem transportasi modes, persyaratan supply-system, pengaruh pada fasilitas yang ada dan pengaruh pada perangkat yang berlaku.

1.16. Persyaratan lain.

1.17. Persyaratan pengemasan.

1.18. Persyaratan preseden dan kritikalitas.

2. Ketentuan kualifikasi. (untuk setiap persyaratan pada poin 1) Demonstrasi, Tes, Analisa, Inspeksi, metoda-metoda kualifikasi khusus.

3. Persyaratan traceability.

3.7.2.1.6 SDD (Sofware Design Description)

SDD berfungsi untuk menggambarkan keputusan desain luas CSCI, desain arsitektural CSCI, dan desain yang rinci yang diperlukan untuk mengimplementasikan software dan digunakan sebagai dasar bagi pengimplementasian software. Disamping itu SSD menyediakan jarak penglihatan bagi si pemeroleh ke dalam desain dan menyediakan informasi yang dibutuhkan bagi pendukung software.

Beberapa hal yang harus diperhatika dalam menerapkan SDD, diantaranya yaitu :

1. Keputusan-keputusan desain luas CSCI. Untuk memperkenalkan keputusan-keputusan mengenai desain perilaku

CSCI's dan keputusan-keputusan lain yang mempengaruhi seleksi dan desain unit-unit software yang menyusun CSCI.

1.1. Keputusan desain berdasarkan I/O CSCI dan interfaces-nya dengan sistem-sistem lain, HWCIs, CSCIs, dan para pengguna.

1.2. Keputusan desain pada perilaku dalam merespon setiap input atau kondisi, termasuk tindakan-tindakan CSCI akan terselenggara, waktu respon dan karakteristik keberhasilan lain, gambaran sistem-sistem fisik yang dimodelkan, equations/algorithms/rules yang telah diseleksi, dan penanganan input-input atau kondisi-kondisi yang tidak dibolehkan.

1.3. Keputusan desain pada bagaimana databases/data files akan muncul pada pengguna Pendekatan terseleksi untuk mempertemukan persyaratan keamanan, sekuriti dan privasi.

1.4. Keputusan desain luas CSCIlain yang dibuat dalam merespon persyaratan, seperti pendekatan yang terseleksi untuk menyediakan flexibilitas, availabilitas, dan maintainabilitas yang diperlukan.

2. Desain arsitektural CSCI.

2.1. Komponen-komponen CSCI .

2.1.1. Mengidentifikasi unit-unit software yang menyusun CSCI. Setiap unit akan ditetapkan sebuah pengidentifikasi proyek unik.

2.1.2. Menunjukan hubungan statis unit-unit software.

2.1.3. Menetapkan tujuan setiap unit software dan mengidentifikasi persyaratan CSCI dan keputusan desain luas CSCI

2.1.4. Mengidentifikasi setiap status perkembangan unit software/tipe (misalnya perkembangan baru, desain yang berlaku atau software yang digunakan kembali, desain yang berlaku atau software yang direkayasa kembali, software yang dikembangkan untuk digunakan kembali)

2.1.5. Menggambarkan CSCI's (dan setiap unit software) merencanakan penggunaan sumber hardware komputer (seperti kapasitas prosesor, kapasitas memori, kapasitas input/output device, kapasitas penyimpanan auxiliary, dan kapasitas perlengkapan jaringan/komunikasi). Gambaran tersebut akan meliputi seluruh sumber hardware komputer termasuk dalam persyaratan penggunaan sumber bagi CSCI, dalam tingkat sistem pengalokasian sumber mempengaruhi CSCI, dan pada 2.1.5. Menggambarkan CSCI's (dan setiap unit software) merencanakan penggunaan sumber hardware komputer (seperti kapasitas prosesor, kapasitas memori, kapasitas input/output device, kapasitas penyimpanan auxiliary, dan kapasitas perlengkapan jaringan/komunikasi). Gambaran tersebut akan meliputi seluruh sumber hardware komputer termasuk dalam persyaratan penggunaan sumber bagi CSCI, dalam tingkat sistem pengalokasian sumber mempengaruhi CSCI, dan pada

2.1.5.1. Persyaratan CSCI atau pengalokasian sumber system- level.

kondisi-kondisi (contohnya, pemakaian tipikal, pemakaian worst-case, asumsi-asumsi untuk even tertentu)

2.1.5.2. Asumsi-asumsi

dan

2.1.5.3. Pertimbangan-pertimbangan khusus yang mempengaruhi penggunaan (misalnya penggunaan memori virtual, overlays, atau multiprocessors atau pengaruh pengoperasian system overhead, library software, atau implementasi overhead yang lain)

2.1.5.4. Unit-unit pengukur yang digunakan (misalnya presentase kapasitas prosesor, putaran per detik, bytes of memory, kilobytes per detik.

2.1.5.5. Tingkatan dimana pengukuran akan dibuat (misalnya unit software, CSCI, atau program yang dapat dilaksanakan)

2.1.5.6. Mengidentifikasikan program library.

2.2. Konsep pelaksanaan. Terdiri dari diagram dan gambaran-gambaran yang menunjukan hubungan

dinamis unit software, yaitu bagaimana mereka akan berinteraksi selama operasi CSCI, termasuk alur kontrol pelaksanaan, data alir, sekuensing yang dikontrol secara dinamis, diagram-diagram transisi keadaan, diagram waktu, prioritas antar unit, penanganan interupsi, hubungan-hubungan sekuensin/pewaktuan, penanganan kekecualian, pelaksanaan concurrent , pengalokasian yang dinamis, penghapusan/penciptaan obyek yang dinamis, proses, tugas-tugas, dan aspek-aspek perilaku dinamis lain.

2.3. Desain interface.

2.3.1. Diagram dan identifikasi interface.

2.3.2. (Proyek-unik pengidentifikasi interface).

3. Desain rinci CSCI.

3.1. (Proyek-unik pengidentifikasi sebuah unit software atau pendesain sekelompok unit software).

3.1.1. Keputusan desain unit, jika ada, seperti algoritma yang digunakan.

3.1.2. Setiap hambatan, keterbatasan, atau ciri-ciri yang tidak biasa dalam desain unit software

3.1.3. Bahasa pemrograman dan alasan penggunaannya

3.1.4. Jika unit software terdiri dari atau berisi perintah-perintah prosedural (misalnya seleksi menu dalam sebuah sistem manajemen database (DBMS) untuk menjelaskan bentuk-bentuk dan laporan, pertanyaan-pertanyaan on-line DBMS untuk akses database dan manipulasi, input pada suatu pembuat interface pengguna grafis (GUI) untuk generasi kode otomatis, perintah untuk sistem operasi), sebuah daftar perintah-perintah prosedural dan referensi untuk pengguna manual atau dokumen lain yang menjelaskannya.

3.1.5. Jika unit software berisi, menerima, atau mengeluarkan data, suatu gambaran mengenai input, output, dan elemen-elemen data yang lain dan pemasangan elemen data. Data setempat pada unit software akan dijelaskan secara terpisah dari input data atau 3.1.5. Jika unit software berisi, menerima, atau mengeluarkan data, suatu gambaran mengenai input, output, dan elemen-elemen data yang lain dan pemasangan elemen data. Data setempat pada unit software akan dijelaskan secara terpisah dari input data atau

3.1.6. Jika unit software berisi logis, logis itu akan digunakan dengan unit software, termasuk:

3.1.6.1. Kondisi-kondisi pada pengaruh dalam unit software ketika pelaksanaannya dimulai

3.1.6.2. Kondisi-kondisi dimana kontrolnya dilalui unit software yang lain

3.1.6.3. Respon dan waktu respon bagi setiap input, termasuk konversi data, penamaan, dan operasi-operasi pengalihan data.

3.1.6.4. Sekuen operasi dan sekuensing yaang dikontrol secara dinamis selama pengoperasian unit software, termasuk:

3.1.6.4.1. Metoda untuk kontrol sekuen 3.1.6.4.2. Logis dan kondisi-kondisi input dari metoda tersebut,

seperti variasi waktu, tugas-tugas prioritas

3.1.6.4.3. Data transfer ke dalam dan ke luar memori 3.1.6.4.4. Sinyal-sinyal input sensing of discrete dan hubungan

pewaktuan diantara operasi interrupt dalam unit software 3.1.6.4.5. Kekecualian dan penanganan kesalahan

4. Persyaratan traceability.

3.7.2.1.7 SPS (Software Product Specification)

SPS berfungsi untuk menyediakan software yang dapat dijalankan, yang berisikan file-file sumber dan informasi pendukung software, termasuk deskripsi desain yang dirancang dan prosedur penyusunan, pembangunan dan modifikasi Computer Software Configuration Item (CSCI). Disamping itu pula digunakan untuk memesan software yang dapat dilaksanakan dan/atau file-file sumber bagi CSCI dan dokumen pendukung software yang pokok bagi CSCI.

Beberapa hal yang harus diperhatikan dalam menerapkan SPS, diantaranya yaitu :

1. Persyaratan.

Pengembangan software mempunyai kriteria yang harus disesuaikan pada sebuah tubuh software untuk dipertimbangkan menjadi sebuah copy-an CSCI- nya yang valid.

1.1. Software yang bisa dilaksanakan. Termasuk setiap sejumlah files, file-file perintah, file-file data atau file-

file software lain yang perlu dipasang dan dioperasikan softwarenya pada target komputernya. Supaya sebuah body software dipertimbangkan copian CSCI's softwarenya yang valid dan executable, maka ia harus menunjukan kecocokan file-file ini dengan tepat.

1.2. File-file sumber. Termasuk setiap sejumlah file, file-file perintah, file-file data atau file-

file lain yang perlu di regenerate software yang dapat dilaksanakannya untuk CSCI. Supaya sebuah body software dipertimbangkan copian CSCI's softwarenya yang valid dan executable, maka ia harus menunjukan kecocokan file-file ini dengan tepat.

1.3. Persyaratan pengemasan.

2. Ketentuan-ketentuan kualifikasi. Metoda-metoda yang digunakan untuk mendemonstrasikan bahwa sebuah

body software yang diberikan merupakan sebuah copy-an CSCI yang valid.

3. Informasi dukungan Software.

3.1. Desain software. Akan memuat, atau mereferensikan suatu apendiks atau dokumen

deliverable yang berisi informasi yang menggambarkan desain CSCI. Informasi akan sama seperti yang diperlukan dalam sebuah Software Design Description (SDD), Interface Design Description (IDD), dan Database Design Description (DBDD).

3.2. Prosedur penyusunan /pendirian. Akan menggambarkan, atau mereferensikan suatu apendiks yang

menggambarkan proses penyusunan/pendirian yang digunakan untuk menciptakan file-file yang executable dari file-file sumber dan untuk mempersiapkan file-file yang executable untuk dimasukan ke dalam firmware atau media distribusi lain. Hal ini akan menentukan menggambarkan proses penyusunan/pendirian yang digunakan untuk menciptakan file-file yang executable dari file-file sumber dan untuk mempersiapkan file-file yang executable untuk dimasukan ke dalam firmware atau media distribusi lain. Hal ini akan menentukan

pendirian CSCI dan sistem/subsistem software yang memuat CSCI, termasuk variasi untuk site-site yang berbeda, konvigurasi, versi, dan lain-lain. Membuat prosedur di atas level CSCI mungkin diselenggarakan dalam satu SPS dan direferensikan dari yang lain.

penyusunan/pemasangan,

dan

3.3. Prosedur modifikasi.

3.3.1. Mendukung fasilitas, peralatan, dan software dan prosedur untuk penggunaannya

3.3.2. Databases/data files yang digunakan oleh CSCI dan prosedur untuk menggunakan dan memodifikasikannya

3.3.3. Desain, pengkodean, dan konvensi lain yang diikuti

3.3.4. Prosedur penyusunan/penentuan jika berbeda dari yang ada di atas

3.3.5. Prosedur integrasi dan pengujian yang diikuti

3.4. Penggunaan sumber hardware komputer.

3.4.1. Persyaratan CSCI atau pengalokasian sumber system-level sudah dipenuhi.

3.4.2. Asumsi-asumsi dan kondisi-kondisi dimana penggunaan data adalah dasarnya (misalnya, penggunaan tipikal, penggunaan worst-case, asumsi even-even tertentu)

3.4.3. Setiap pertimbangan khusus yang mempengaruhi penggunaan (seperti

overlays, atau multiprocessor atau pengaruh-pengaruh pengoperasian sistem di atas, library software, atau implementasi lain)

3.4.4. Unit pengukuran yang digunakan (misalnya presentase kapasitas prosesor, putaran per detik, bytes memori, kilobytes per detik)

3.4.5. Tingkatan dimana pengukuran telah dibuat (misalnya unit software, CSCI atau program yang executable)

4. Persyaratan traceability.

4.1. Traceabilitas dari setiap file sumber CSCI pada unit-unit software yang dilaksanakan.

4.2. Traceabilitas dari setiap unit software pada file-file sumber yang melaksanakannya.

4.3. Traceabilitas dari setiap pengukuran penggunaan sumber hardware komputer

4.4. Traceabilitas dari setiap persyaratan mengenai penggunaan sumber hardware komputer pada pengukuran penggunaan

3.7.2.2 Kerangka Utama (Mainframe) Aplikasi Perangkat Lunak

3.7.2.2.1 Konsep Dasar 3.7.2.2.2 Arsitektur Siklus Perangkat Lunak

Kerangka utama aplikasi perangkat lunak ini merupakan arsitektur dari siklus perangkat lunak pada level paling atas. Siklus dimulai dengan sebuah gagasan atau kebutuhan yang dapat dipenuhi oleh perangkat lunak. Arsitektur dibangun dengan sekumpulan proses dan hubungan diantara proses-proses tersebut. Turunan dari proses didasarkan pada dua prinsip dasar, yaitu :

1. Modularitas. Proses-proses adalah modular, yaitu masing-masing proses secara maksimal bersifat kohesif dan secara individual proses tersebut di peruntukan bagi fungsi yang unik.

2. Tanggung Jawab. Suatu proses dipertimbangkan menjadi tanggung jawab dari suatu bagian siklus perangkat lunak. Dengan kata lain masing-maing bagian memiliki tanggung jawab yang berbeda. Tanggung Jawab merupakan salah satu kunci prinsipil dari manajemen kualitas keseluruhan.

3.7.2.2.3 Siklus Proses-Proses

Proses-proses dikelompokan ke dalam 3 kelas umum, yaitu :

1. Primer. Adalah penggerak utama dalam siklus; diantaranya akuisisi, suplai, pengembangan, operasi dan perawatan.

2. Pendukung. Adalah dokumentasi, manajemen konfigurasi, jaminan kualitas, pembahasan ulang, audit, verifikasi, validasi dan resolusi masalah. Proses-proses pendukung mendukung proses lain dalam melakukan fungsi khusus.

3. Organisasi. Adalah manajemen, infrastruktur, kemajuan dan pelatihan. Suatu organisasi dapat menempatkan suatu proses organisasi dalam membangun, kontrol dan memajukan siklus proses.

Perawatan Operasi Pengembangan Suplai Akuisisi

Primer

Siklus

Pendukung Dokumentasi Manajemen Konfigurasi Jaminan Kualitas Verifikasi Validasi Pembahasan Ulang

Audit Resolusi Masalah

Organisasi

Manajemen Infrastruktur Kemajuan Pelatihan

Gambar Siklus Proses-Proses

3.7.2.2.4 Proses-Proses Primer

Standar Internasional menguraikan proses-proses primer yang terjadi selama satu periode atau lebih pada siklus proyek perangkat lunak yang diperluas secara konseptual yang telah tidak digunakan lagi. Proses-proses primer menyediakan kunci-kunci bagian yang terlibat dalam akuisisi, pengembangan, suplai, operasi dan perawatan software. Masing –masing proses utama didefinisikan dan diuraikan dalam istilah-istilah pemilih kegiatan dan pekerjaan. Masing –masing proses utama dimulai dengan sebuah pendahuluan (tidak terlalu dibutuhkan), dilanjutkan dengan kegiatan tingkat- corporate (tidak terlalu dibutuhkan), dan dilanjutkan dengan serangkaian kegiatan dan asosiasi pekerjaan untuk menyediakan produk dan layanan perangkat lunak.

3.7.2.2.4.1 Proses Akuisisi

Siklus proses ini mendefinisikan kegiatan dan pekerjaan dari pemeroleh, yang secara implisit memperoleh produk dan layanan perangkat lunak. Organisasi mempunyai kebutuhan akan produk dan layanan yang mungkin dimiliki. Pemilik boleh menyewa seluruh atau sebagian dari pemeroleh pekerjaan Siklus proses ini mendefinisikan kegiatan dan pekerjaan dari pemeroleh, yang secara implisit memperoleh produk dan layanan perangkat lunak. Organisasi mempunyai kebutuhan akan produk dan layanan yang mungkin dimiliki. Pemilik boleh menyewa seluruh atau sebagian dari pemeroleh pekerjaan

Proses akuisisi dimulai dengan mendefinisikan kebutuhan untuk memperoleh sebuah produk atau layanan perangkat lunak. Proses ini kemudian dilanjutkan dengan mempersiapkan pertanyaan untuk proposal yang diterima, memilih suplier, dan mengatur proses akuisisi melalui penerimaan dari sistem.

Proses-proses ini terdiri dari kegiatan yang panjang dan pekerjaan-pekerjaan yang spesifik : Langkah pertama, Permintaan proposal; Persiapan dan perubahan kontrak; Pemantauan suplier dan Penerimaan dan penyempurnaan. Tiga kegiatan awal dikerjakan di awal kesepakatan dan dua kegiatan dikerjakan setelah kesepakatan.

3.7.2.2.4.2 Proses Suplai

Proses suplai terdiri dari kegiatan dan tugas-tugas seorang suplier. Proses- proses yang mungkin dilakukan diawal, salah satunya adalah keputusan untuk menyiapkan sebuah proposal untuk menjawab pertanyaan dari pemeroleh atau menandatangani sebuah kontrak atau sebuah kesepakatan dengan pemeroleh untuk menyediakan layanan perangkat lunak. Layanan dapat berupa pengembangan produk perangkat lunak atau sistem yang terdiri

dari : perangkat lunak, operasi dari sistem pendukung perangkat lunak, atau perawatan dari produk perangkat lunak. Proses-proses ini berkesinambungan dengan mengidentifikasi prosedur dan sumber yang dibutuhkan untuk mengatur dan menjamin layanan, yang melibatkan pengembangan dan eksekusi dari rencana melalui pengiriman dari layanan kepada pemeroleh. Proses suplai terdiri dari aktifitas yang panjang dengan tugas-tugas yang spesifik: Langkah awal ; Persiapan tanggapan; Kontrak; Perencanaan; Pelaksanaan dan kontrol; Peninjauan ulang dan evaluasi; dan Pengiriman dan penyempurnaan. Dua kegiatan awal dilaksanakan di awal kesepakatan dan lima kegiatan terakhir dilaksanakan setelah kesepakatan.

3.7.2.2.4.3 Proses Pengembangan

Siklus proses ini terdiri dari aktifitas dan tugas-tugas dari pengembang perangkat lunak. Istilah pengembang berarti pengembang software baru atau pengembang yang memodifikasi software yang telah ada. Proses pengembangan diperuntukan untuk dipekerjakan sekurang-kurangnya dengan dua cara: (1) sebagai sebuah metodologi untuk mengembangkan prototipe atau untuk pembelajaran kebutuhan dan rancangan dari produk atau

(2) sebagai sebuah proses untuk menghasilkan produk. Proses ini menyediakan pengembangan software sebagai sebuah entitas yang berdiri sendiri atau sebagai sebuah keseluruhan bagian yang besar dengan kata lain keseluruhan sistem.

Proses pengembangan terdiri dari aktifitas yang panjang dengan tugas-tugas yang spesifik. Proses impelementasi; Analisis kebutuhan sistem; Desain sistem; Analisis kebutuhan software; Desain arsitektur software; Desain detil software; Pengkodean dan pengujian software; Integrasi software; Pengujian kualifikasi software; Integrasi sistem; Pengujian kualifikasi sistem; Instalasi software; dan Pendukung software. Urutan posisi dari beberapa aktifitas tersebut tidaklah terlalu penting dimana harus sesuai dengan waktu yang telah ditetapkan. Beberapa aktifitas memungkinkan diulang kembali atau dilakukan lebih awal, atau sebuah aktifitas mungkin dilakukan berulang-ulang kali untuk memperbaiki beberapa proses yang belum optimal sesuai dengan konsep waterfall.

Semua aktifitas dan pekerjaan pada awalnya jauh dari kesempurnaan tetapi setelah mengalami beberapa iterasi ditemukan perubahan menuju kesempurnaan hingga dicapai iterasi terakhir sebagai tanda bahwa usaha dan

hasil telah optimal. Beberapa aktifitas dan pekerjaan yang digunakan untuk membangun satu atau lebih model-model (seperti, Waterfall, incremental, evolusi, spiral, atau yang lainnya atau kombinasi diantaranya) sebuah proyek atau sebuah organisasi. Sebagai contoh organisasi dari sebuah sistem yang dilukiskan pada gambar di bawah ini. Gambar tersebut menunjukan sistem yang terorganisasi, pada level pertama, terdapat hardware, software dan serangkaian beberapa operasi manual. Pada level kedua masing-masing item ditunjukan dengan komponen-komponennya, yang mana selanjutnya terorganisasi sesuai kebutuhannya. Organisasi ini memiliki pembagian sistem yang panjang dengan jalur top-down seperti yang diilustrasikan gambar di bawah ini. Tetapi, integrasi bottom-up tidak memungkinkan untuk diterapkan pada organisasi ini.

Keterangan : HW - Hardware; SW – Software; OM – Operasi Manual; P : Personil

Gambar. Contoh Organisasi Sistem

Standar mengizinkan untuk menentukan baselining, desain dan kode pada saat sebelum titik penentuan selama pengembangan produk, asalkan tanpa kendali dari proses-proses pengembangan. Suatu saat baselining melarang di awal-awal melakukan perubahan-perubahan yang tidak terencana pada beberapa kebutuhan dan promosi kontrol perubahan yang efektif. Standar juga menyediakan forum (yaitu pembahasan bersama dan proses audit) untuk bagian yang penting untuk dilibatkan dalam baselining.

Hal ini seharusnya menjadi catatan bahwa proses pengembangan bisa mengatur konfigurasi manajemen proses dan tugas-tugas baselining

3.7.2.2.4.4 Proses Operasi

Siklus proses ini terdiri dari aktifitas dan tugas-tugas dari operator sebuah sistem software. Operasi software diintegrasikan ke dalam operasi dari keseluruhan sistem. Proses penanganan operasi dari software dan pendukung operasi kepada user. Proses ini terdiri dari urutan kegiatan yang panjang dengan tugas yang spesifik : Proses-proses implementasi; Pengujian operasional. Sistem Operasi; dan Dukungan pengguna.

3.7.2.2.4.5 Proses Perawatan

Proses perawatan terdiri atas aktifitas dan tugas-tugas dari petugas perawatan. Proses ini dilaksanakan ketika sebuah sistem mengalami proses modifikasi terhadap kode dan dokumentasi yang terasosiasi dikarenakan error, kelemahan, kendala, atau perlunya untuk sebuah perbaikan atau adaptasi. Tujuan memodifikasi sebuah sistem yang telah ada adalah untuk menjaga integritas. Dimanapun produk software, pasti membutuhkan modifikasi, proses pengembangan selalu memerlukan proses modifikasi untuk Proses perawatan terdiri atas aktifitas dan tugas-tugas dari petugas perawatan. Proses ini dilaksanakan ketika sebuah sistem mengalami proses modifikasi terhadap kode dan dokumentasi yang terasosiasi dikarenakan error, kelemahan, kendala, atau perlunya untuk sebuah perbaikan atau adaptasi. Tujuan memodifikasi sebuah sistem yang telah ada adalah untuk menjaga integritas. Dimanapun produk software, pasti membutuhkan modifikasi, proses pengembangan selalu memerlukan proses modifikasi untuk

3.7.2.2.5 Proses-Proses Pendukung

Proses ini terdiri atas delapan proses pendukung. Sebuah proses pendukung mendukung beberapa proses lain sebagai sebuah bagian yang terintegrasi dengan sebuah tujuan yang berbeda dan kontribusi terhadap keberhasilan dan kualitas dari proyek. Sebuah proses pendukung diperlukan oleh proses akuisisi, suplai, pengembangan, operasi atau perawatan, atau proses pendukung lainnya. Proses pendukung memulai dengan sebuah pendahuluan, mungkin mengikuti dengan sebuah kumpulan aksi level- corporate (tidak diperlukan), dan dilanjutkan dengan serangkaian aktifitas dan tugas-tugas yang terasosiasi yang mendukung siklus proses.

3.7.2.2.5.1 Proses Dokumentasi

Ini adalah proses untuk merekam informasi yang dihasilkan oleh proses siklus. Proses ini mendefinisikan aktifitas, seperti perencanaan, desain, pengembangan, edit, distribusi dan perawatan dimana dokumen ini butuhkan oleh semua yang terkait seperti manager, perancang dan pengguna sistem. Empat aktifitas yang panjang dengan tugasnya diantaranya adalah: Proses implementasi; Desain dan pengembangan; Produksi; dan Perawatan.

3.7.2.2.5.2 Proses Manajemen Konfigurasi

Proses ini dilaksanakan untuk mengidentifikasi, mendefinisikan, dan sebagai dasar bagi komponen software dalam sebuah sistem; mengendalikan modifikasi dan merilis komponen software tersebut; merekam dan melaporkan status komponen software dan permintaan modifikasi; meyakinkan ketidaksempurnaan dan kesalahan komponen software; dan mengendalikan tempat penyimpanan, menangani dan mengirim komponen software. Proses ini terdiri dari : Proses implementasi; Konfigurasi identifikasi, Konfigurasi kontrol; Konfigurasi status akuntansi; Konfigurasi evaluasi; dan Rilis manajemen dan pengiriman.

3.7.2.2.5.3 Proses Jaminan Kualitas

Proses ini menyediakan kerangka kerja yang independen dan objektif yang menjamin (pemeroleh atau konsumen) dari keluhan produk atau layanan dengan kebutuhan yang implisit dan sesuai untuk rencana yang dibangun. Agar tidak saling berprasangka dan berpihak pada salah satu pilihan, jaminan kualitas software dibangun dengan kebebasan berorganisasi dari orang secara langsung yang bertanggungjawab untuk mengembangkan produk atau layanan. Proses ini terdiri dari : Proses implementasi; Produk jaminan; Proses jaminan; dan Jaminan kualitas sistem

3.7.2.2.5.4 Proses Verifikasi

Proses ini menyediakan evaluasi yang berhubungan dengan verifikasi dari sebuah produk atau layanan dari salah satu aktifitas. Verifikasi menentukan apakah kebutuhan untuk sebuah sistem telah sempurna dan benar begitu juga dengan outputnya dari sebuah aktifitas yang telah memenuhi kebutuhan atau kondisi yang belum terpenuhi saat aktifitas terdahulu. Proses penanganan verifikasi terdiri atas proses-proses, kebutuhan, desain, kode, integrasi, dan dokumentasi. Verifikasi tidak sama dengan evaluasi yang Proses ini menyediakan evaluasi yang berhubungan dengan verifikasi dari sebuah produk atau layanan dari salah satu aktifitas. Verifikasi menentukan apakah kebutuhan untuk sebuah sistem telah sempurna dan benar begitu juga dengan outputnya dari sebuah aktifitas yang telah memenuhi kebutuhan atau kondisi yang belum terpenuhi saat aktifitas terdahulu. Proses penanganan verifikasi terdiri atas proses-proses, kebutuhan, desain, kode, integrasi, dan dokumentasi. Verifikasi tidak sama dengan evaluasi yang

3.7.2.2.5.5 Proses Validasi

Validasi menentukan apa yang akan menjadi hasil akhir dari sistem yang dibangun yang memenuhi peruntukan spesifikasi yang digunakan. Sejumlah validasi bergantung kepada proyek yang tengah kritis. Validasi bukan berarti merubah evaluasi-evaluasi yang lain, tetapi sebagai pendukung evaluasi. Verifikasi atau validasi dapat dikonduksi oleh pemeroleh, suplier, atau bagian yang independen. Ketika kegiatan tersebut dilaksanakan oleh sebuah organisasi yang independen dari suplier atau pengembang, mereka menyebutnya proses verifikasi dan validasi yang independen.

3.7.2.2.5.6 Proses Pembahasan Ulang

Proses ini menyediakan kerangka kerja atau media untuk interaksi antara pembicara dan peserta diskusi. Mereka diperkenankan sebaik mungkin masing-masing menjadi posisi pemeroleh dan supplier. Pada proses pembahasan ulang, peserta diskusi menghadirkan status dan produk dari Proses ini menyediakan kerangka kerja atau media untuk interaksi antara pembicara dan peserta diskusi. Mereka diperkenankan sebaik mungkin masing-masing menjadi posisi pemeroleh dan supplier. Pada proses pembahasan ulang, peserta diskusi menghadirkan status dan produk dari

3.7.2.2.5.7 Proses Audit

Proses ini menyediakan kerangka kerja atau media untuk formal, dimana adanya keccenderungan ketidaksesuaian dengan kondisi sebenarnya maka didirikanlah audit untuk produk dan layanan suplier. Seorang audit, memeriksa dan mengaudit produk dan kegiatan dengan mengutamakan keluhan dari kebutuhan dan perencanaan. Seorang audit boleh dikonduksi oleh pemeroleh dan suplier.

3.7.2.2.5.8 Proses Resolusi Masalah

Proses ini menyediakan mekanisme untuk membangun sebuah proses pengulangan secara tertutup untuk penyelesaian masalah dan pengambilan tindakan untuk membenarkan masalah dari apa yang mereka deteksi. Sebagai tambahan, proses ini membutuhkan identifikasi dan analisis dari penyebab dan pembalikan masalah-masalah yang dilaporkan. Istilah masalah disini menyangkut juga mengenai ketidaksesuaian.

3.7.2.2.6 3 Proses-Proses Organisasi

Proses ini terdiri dari empat proses organisasi. Sebuah organisasi melaksanakan proses organisasi untuk menampilkan fungsi dari organisasi, tingkat corporate, diluar karakter organisasi atau diluar proyek. Proses-proses organisasi boleh mendukung beberapa proses yang lain sebaik mungkin. Proses ini membantu dalam pembangunan, pengendalian, dan improvisasi proses-proses yang lainnya.

3.7.2.2.6.1 Proses Manajemen

Proses ini mendefinisikan aktifitas generik dan tugas dari manager proses siklus software, seperti proses akuisisi, proses suplai, proses operasi, proses perawatan, atau proses pendukung. Aktifitas tersebut diantaranya menangani : Inisiasi dan definisi ruang lingkup; Perencanaan; Eksekusi dan kontrol; Peninjauan ulang dan evaluasi; dan Penutup. Proses primer, pada umumnya, mempunyai kesamaan kegiatan manajemen, tetapi cukup berbeda pada level detil karena memiliki target yang hasil akhirnya berbeda tujuan, dan metode operasi. Meskipun begitu, tetap masing-masing primer adalah sebuah instansiasi (sebuah implementasi yang spesifik) dari proses manajemen.

3.7.2.2.6.2 Proses Infrastruktur

Proses ini mendefinisikan kegiatan yang membutuhkan untuk pembangunan dan perawatan sebuah infrastruktur yang mendukung siklus proses. Proses ini mempunyai beberapa kegiatan: proses implementasi; Pembangunan infrastruktur; dan Perawatan dari infrastruktur. Infrastruktur ini melibatkan hardware, software, standar, tool, teknik dan fasilitas.

3.7.2.2.6.3 Proses Kemajuan

Proses ini menyediakan dasar, aktifitas tingkat atas suatu organisasi (seperti, proses akuisisi, suplai, pengembangan, operasi, perawatan, pendukung) membutuhkan ketetapan, ukuran, kontrol, dan improvisasi mengenai siklus proses. Kegiatan penanganan terdiri dari: Proses pembangunan, Proses Penetapan, dan Proses improvisasi. Organisasi melaksanakan beberapa kegiatan dalam tingkat organisasi. Pengalaman-pengalaman yang dicapai dari penerapan siklus proses pada proyek digunakan untuk mengimprovisasi proses-proses selanjutnya. Tujuan mengimprovisasi proses organisasi, secara luas adalah untuk meraih keuntungan organisasi secara keseluruhan Proses ini menyediakan dasar, aktifitas tingkat atas suatu organisasi (seperti, proses akuisisi, suplai, pengembangan, operasi, perawatan, pendukung) membutuhkan ketetapan, ukuran, kontrol, dan improvisasi mengenai siklus proses. Kegiatan penanganan terdiri dari: Proses pembangunan, Proses Penetapan, dan Proses improvisasi. Organisasi melaksanakan beberapa kegiatan dalam tingkat organisasi. Pengalaman-pengalaman yang dicapai dari penerapan siklus proses pada proyek digunakan untuk mengimprovisasi proses-proses selanjutnya. Tujuan mengimprovisasi proses organisasi, secara luas adalah untuk meraih keuntungan organisasi secara keseluruhan

3.7.2.2.6.4 Proses Pelatihan

Proses ini dilakukan untuk mengidentifikasi dan membuat suatu kegiatan pelatihan yang terjadual dengan baik yang diperuntukan bagi pemeroleh atau pengembang dan personil sebagai sumber daya manusia yang berada pada posisi tingkat manajemen dan teknis. Proses ini membutuhkan sebuah rencana pelatihan yang telah susun dengan baik dan pelatihan materi yang disediakan untuk personil dalam rentang waktu tertentu.