A. Pengembangan Software

Transkripsi

1 A. Pengembangan Software BAB 6 FASE PENGEMBANGAN Terlepas dari perbedaan karakteristik yang melatarbelakangi ketiga jenis pengembangan tersebut, secara garis besar ada enam tahap yang biasa dijadikan sebagal batu pijakan atau model dalam melaksanakan aktivitas pengembangan software tersebut, yaitu: perencanaan, analisis, desain, konstruksi, implementasi, dan pascaimplementasi seperti digambarkan pada diagram di bawah ini. Gambar Konsep Pengembangan Sistem Informasi Secara umum tahapan pengembangan software informasi sbb: 1. Survei sistem / preliminary 2. Analisis Sistem 3. Desain Sistem 4. Pembuatan Sistem 5. Implementasi Sistem 6. Pemeliharaan Sistem MPSI 41

2 1. Survei Sistem (Preliminary) a. Identifikasi permasalahan, peluang atau arahan Investigasi awal untuk melihat kebutuhan pengguna. Berikut ini contoh investigasi awal. b. Definisi Lingkup Kerja Untuk mengetahui ruang lingkup aplikasi yang akan dikembangkan beserta rencana tahapan pengembangan (mulai dari nol atau prototype) c. Penyusunan Proposal Proposal yang disusun mencakup gambaran umum pelaksanaan proyek, jadwal pelaksanaan, rincian biaya, aplikasi yang akan dikembangkan, analisis keuntungan dan metodologi yang akan dipakai Proposal dinilai oleh klien dalam hal: a) Kelayakan operasional: apakah secara operasional, sistem yang diusulkan dapat dilaksanakan dengan sumber daya manusia yang tersedia, metode training yang ditawarkan, layanan purna jual/pemeliharaan serta efisiensi dan efektifitas sistem usulan. b) Kelayakan teknis: apakah hardware, software yang diusulkan tersedia, jadwal pelaksanaan proyek fisibel, dab bagaimana dengan sistem keamanan data. c) Kelayakan ekonomis: menyangkut biaya pembuatan, implementasi, dan keuntungan/benefit yang diperoleh MPSI 42

3 2. Analisis Sistem a. Analisis sistem adalah sebuah teknik pemecahan masalah yang mendekomposisi sebuah sistem menjadi komponen-komponen penyusunnya dalam rangka mempelajari lebih jauh bagaimana komponen sistem tersebut bekerja dan berinteraksi dengan komponen lainnya untuk suatu tujuan tertentu. b. Analisis sistem (sintesis sistem) adalah kelanjutan dari teknik pemecahan masalah yang merangkai kembali komponen-komponen sistem menjadi satu kesatuan sistem yang utuh dengan harapan telah terbentuk perbaikan sistem. c. Analisis sistem dapat diartikan juga sebagai proses untuk memahami sistem yang ada dengan menganalisis jabatan dan uraian tugas (business users), proses bisnis (business process), ketentuan/aturan yang ada (business rules), masalah dan mencari solusinya (business problems & solutions), business tools dan berbagai rencana perusahaan (business plans) d. Pendekatan analisis sistem biasanya include dalam metodologi pengembangan sistem, misal pendekatan Structured Analysis Design, Information Engineering, Object-Oriented Analysis, Accelerated Analysis, Requirements Discovery, Business Process Reengineering, FAST, dll Alasan perlunya analisis sistem Sebagai Problem solving, yakni mengasumsikan sistem lama tidak berfungsi sesuai kebutuhan dan memerlukan perbaikan untuk dapat digunakan secara baik. Kebutuhan baru dalam organisasi, sehingga perlu dilakukan modifikasi sistem Teknologi baru Keinginan meningkatkan performansi sistem secara keseluruhan Aktifitas dalam analisis sistem hendaknya dapat menjawab pertanyaan umum berikut: Sistem baru apa yang akan dibangun? Sistem apakah yang akan dimodifikasi atau ditambahkan pada sistem lama MPSI 43

4 Sebelum melakukan analisis sistem, hendaknya susun rencana ttg: Batasan analisis, fakta yang akan dikumpulkan dan dipelajari selama analisis, sumber dimana fakta dapat diperoleh, tujuan dan kendala yang mungkin dalam analisis, proyeksi kemungkinan masalah yang akan terjadi selama analisis, dan jadwal tentatif analisis Sumber-sumber fakta analisis sistem: Sistem yang ada. Sumber internal lain: orang, dokumen, hubungan antar orangorganisasi atau fungsi yang ada Sumber eksternal: Interface dengan sistem luar, seminar, vendor, jurnal, textbook, dll Aspek-aspek yang dianalisis dalam analisis sistem: 1. Business users 2. Analisis Jabatan 3. Proses bisnis (business process), 4. ketentuan/aturan yang ada (business rules), 5. Masalah dan mencari solusinya (business problems & solutions), 6. Business tools 7. Rencana perusahaan (business plans) 3. Desain Sistem Analisis sistem digunakan untuk menjawab pertanyaan what? Desain sistem digunakan untuk menjawab pertanyaan how? Desain berkonsentrasi pada bagaimana sistem dibangun untuk memenuhi kebutuhan pada fase analisis Manfaat desain sistem adalah memberikan gambaran rancang bangun (blue print) yang lengkap, sebagai penuntun (guideline) bagi programmer dalam membuat aplikasi Sistem informasi yang terkomputerisasi setidaknya terdiri dari: Hardware: terdiri dari komponen input, proses, output, dan jaringan MPSI 44

5 Software: terdiri dari sistem operasi, utilitas, dan aplikasi Data: mencakup struktur data, keamanan dan integritas data Prosedur: seperti dokumentasi, prosedur sistem, buku petunjuk operasional dan teknis Manusia: pihak yang terlibat dalam penggunaan sistem informasi Beberapa hal yang dilakukan dalam desain sistem adalah: 1. Pemodelan sistem 2. Desain Basis data 3. Desain Aplikasi 4. Desain Perangkat Keras/Jaringan 5. Desain Jabatan/Deskripsi Pengguna 4. Pembuatan Sistem Buatlah aplikasi berdasarkan rancangan yang telah dibuat Selain aplikasi, buatlah juga buku panduan penggunaan aplikasi agar mudah saat melakukan training pada saat implementasi. Lakukan testing aplikasi, diantaranya: * Testing performa * Testing program logic / sintaks * Testing implementasi bisnis rules * Testing faktor manusia * Testing bisnis proses / prosedur * Testing efisiensi input * Testing ouput 5. Implementasi Sistem Sebelum implementasi, lakukanlah persiapan secara matang mengenai perangkat keras, perangkat lunak, ruangan dan fasilitas pendukung lainnya. Beberapa hal yang juga penting diperhatikan dalam implementasi sistem adalah: 1. Konversi Biasanya diperlukan konversi dari sistem lama ke sistem baru, apalagi jika sebelumnya juga telah menggunakan aplikasi terkomputerisasi 2. Pelatihan MPSI 45

6 Lakukan pelatihan secara menyeluruh untuk setiap pihak yang menggunakan. Jangan lupa lakukan sosialisasi kepada pihak-pihak yang terlibat dalam sistem namun tidak menggunakan aplikasi sistem secara langsung. 3. Testing Penerimaan Lakukan testing selama periode tertentu sebagai proses belajar. 6. Pemeliharaan Sistem Tahapan pemeliharaan sistem mencakup seluruh proses yang diperlukan untuk menjamin kelangsungan, kelancaran, dan penyempurnaan sistem yang telah dioperasikan. Beberapa hal yang harus dilakukan: 1. Pemantauan pengoperasian Libatkan tim pengembang untuk memantau secara langsung pada waktuwaktu tertentu mengenai bagaimana pihak-pihak pengguna mengoperasikan sistem yang dibuat. 2. Antisipasi gangguan kecil (bug) Biasanya selalu ada gangguan kecil dalam suatu aplikasi yang baru dikembangkan. 3. Lakukan penyempurnaan 4. Antisipasi faktor-faktor luar 5. Virus, kerusakan/kehilangan data, atau sistem diakses oleh pihak luar B. Quality Assurance Software Quality Assurance (SQA) pengembangan software. SQA meliputi : diaplikasikan secara menyeluruh pada proses a. Analisis, perancangan, pengkodean, dan metode serta peralatan ujicoba. b. Tinjauan ulang teknikal secara formal yang diaplikasikan pada setiap tahapan pengembangan software. c. Strategi ujicoba dengan banyak tahapan (multitiered). d. Pengawasan terhadap dokumentasi software dan perubahan yang dialaminya. e. Suatu prosedur untuk menjamin pemenuhan standar pengembangan software (jika ada). f. Mekanisme pengukuran dan laporan. MPSI 46

7 Setiap pengembang software pasti setuju jika dikatakan bahwa kualitas software merupakan salah satu tujuan yang penting. Banyak definisi mengenai kualitas software, tetapi disini kualitas software didefinisikan sebagai : penyesuaian kebutuhan fungsional dan performa yang ditetapkan secara eksplisit, standar pengembangan yang terdokumentasi secara eksplisit, dan karakteristik implisit yang diharapkan dari seluruh software yang dikembangkan secara professional. Definisi diatas menjelaskan 3 hal penting, yaitu : 1. Kebutuhan software merupakan pondasi/dasar dari kualitas yang akan diukur. Sedikitnya penyesuaian terhadap kebutuhan, maka semakin tidak berkualitas. 2. Standar yang dispesifikasikan mendefinisikan sekumpulan kriteria pengembangan yang memandu pengembangan software. Jika kriteria tidak disertakan, maka dapat dipastikan hasil akhir akan berkualitas rendah. 3. Terdapat kebutuhan implisit (implicit requirements) yang terkadang tidak disebutkan (misalkan, keinginan untuk kemampuan pemeliharaan yang mudah). Jika software menyesuaikan kepada kebutuhan eksplisit, tetapi tidak kepada kebutuhan implisit, maka kualitas software akan dipertanyakan. Faktor-faktor kualitas software(software quality factors) mempengaruhi kualitas software dibagi menjadi 2 kategori : Faktor-faktor yang dapat 1. Faktor-faktor yang dapat diukur secara langsung (misalkan : error ) 2. Faktor-faktor yang dapat diukur secara tidak langsung (misalkan : usability dan maintainability). Menurut McCall terdapat 3 aspek penting dari suatu produk software, yaitu : karakteristik operasional, kemampuan perubahan ketika software sudah berjalan, dan kemampuan beradaptasi terhadap lingkungan baru, seperti terlihat pada gambar diatas. Berdasarkan gambar diatas, McCall menyediakan beberapa dekripsi yaitu : 1. Correctness (kebenaran), tingkat pemenuhan program terhadap kebutuhan yang dispesifikasikan dan memenuhi tujuan/misi pengguna. MPSI 47

8 2. Reliability (Keandalan), tingkat kemampuan program yang diharapkan dapat menampilkan fungsi yang dimaksud dengan presisi yang ditetapkan. 3. Efficiency (efisiensi), jumlah sumberdaya yang diproses dan kode yang diperlukan oleh program untuk melaksanakan fungsinya. 4. Integrity (Integritas), tingkat kemampuan pengawasan akses terhadap data atau software oleh orang-orang tertentu. 5. Usability, usaha yang diperlukan untuk mempelajari, mengoperasikan, menyiapkan masukan dan mengartikan keluaran program. 6. Maintainability, usaha yang diperlukan untuk menetapkan dan memperbaiki kesalahan dalam program. 7.Flexibility, usaha yang diperlukan untuk memodifikasi program operasional. 8. Testability, usaha yang diperlukan untuk menguji program untuk memastikan bahwa program melaksanakan fungsi yang telah ditetapkan. 9. Portability, usaha yang diperlukan untuk memindahkan program dari hardware/lingkungan sistem software tertentu ke yang lainnya. 10. Reusability, tingkat kemampuan program/bagian dari program yang dapat dipakai ulang dalam aplikasi lainnya, berkaitan dengan paket dan lingkup dari fungsi yang dilakukan oleh program. 11. Interoperability, usaha yang diperlukan untuk menggabungkan satu sistem dengan sistem lainnya. Untuk membentuk pengukuran langsung mengenai faktor-faktor kualitas tidaklah mudah. Terdapat beberapa ukuran (metric) yang didefinisikan dan penilaiannya diukur secara objektif. Pengukuran biasanya dalam bentuk checklist dengan menggunakan skala McCall menetapkan beberapa pengukuran yang dapat digunakan, diantaranya : 1. Auditability, kemudahan yaitu penyesuaian terhadap standar yang dapat diperiksa. 2. Accuracy, ketepatan perhitungan dan kontrol. 3. Communication commonality, tingkatan dimana interface standar, protokol dan bandwidth digunakan. 4. Completeness, tingkatan dimana implementasi lengkap dari fungsi yang dibutuhkan telah tercapai. 5. Conciseness, kepadatan program dalam jumlah baris kode. 6. Consistency, penggunaan rancangan dan teknik dokumentasi dalam satu bentuk diseluruh proyek pengembangan software. 7. Data commonality, penggunaan struktur dan tipe data standar diseluruh program. 8. Error tolerance, kerusakan yang muncul ketika program menemukan kesalahan/kegagalan. 8. Execution efficiency, performa run-time suatu program. 9. Expandability, tingkatan dimana rancangan arsitektural, data atau prosedur dapat dikembangkan. 10. Generality, lingkup aplikasi potensial dari suatu komponen program. MPSI 48

9 11. Hardware independece, tingkatan dimana software dipisahkan dari hardware yang mengoperasikannya. 12. Instrumentation, tingkatan dimana pengawasan program memiliki operasi tersendiri dan mengidentifikasikesalahan yang terjadi. 13. Modularity, kemandirian fungsional dari suatu komponen program. 14. Operability, kemudahan pengoperasian program. 15. Security, ketersediaan mekanisme yang mengontrol atau menproteksi program dan data. 16. Self-documentation, tingkatan dimana kode sumber menyediakan dokumentasi yang berarti. 17. Simplicity, tingkatan dimana program dapat dimengerti tanpa kesulitan. 18. Software system independence, tingkatan dimana program mandiri terhadap feature bahasa pemrograman 19. nonstandar, karakteristik sistem operasi, dan batasan-batasan lingkungan lainnya. 20. Traceability, kemampuan penelusuran ulang representasi rancangan atau komponen program yang sesungguhnya dengan kebutuhan awal (requirements). C. Software Quality Assurance Jaminan kualitas merupakan aktivitas mendasar untuk setiap bisnis yang menghasilkan produksi yang digunakan oleh orang lain. Diawal abad ke-20, jaminan kualitas merupakan tanggungjawab yang ditawarkan oleh produsen yang membuat suatu produk. Jaminan kualitas secara formal diperkenalkan pertamakalinya oleh Bell Laboratory pada tahun 1916 dan berkembang cepat serta meluas keseluruh dunia. Disaat ini, setiap perusahaan telah memiliki mekanisme untuk menentukan kualitas dari produknya. Sejarah jaminan kualitas dalam pengembangan perangkat lunak sejajar/paralel dengan sejarah dalam pembuatan hardware. Diawal tahun 1950 dan 1960 kualitas perangkat lunak merupakan tanggung jawab dari pembuat program. Standar untuk jaminan kualitas perangkat lunak diperkenalkan dalam kontrak pengembangan perangkat lunak militer selama tahun 1970 dan mulai berkembang secara pesat secara komersil. SQA merupakan pola aksi yang terencana dan sistematis yang dibutuhkan untuk memastikan kualitas suatu software. Lingkup dari SQA dalam software sangat beragam, mencakup : pembuat software, manajer proyek, customer, sales peoples, dan orang-orang yang dilayani dalam SQA. Orang-orang yang melaksanakan SQA harus dapat melihat software dari sudut pandang konsumen. Aktivitas-aktivitas SQA (SQA Activities) SQA terdiri dari berbagai jenis aktivitas yang terhubung dengan 7 aktivitas utama, yaitu : 1. Aplikasi metode-metode teknikal (Application of technical methods) Kualitas software didesain kedalam sebuah produk atau sistem. Pada kenyataannya SQA dimulai dengan sekumpulan metode teknikal dan tool yang membantu analis untuk mencapai spesifikasi dengan kualitas yang tinggi dan para perancang membangun desain yang berkualitas tinggi. 2. Mengadakan review teknikal formal (conduct of formal technical reviews) Ketika spesifikasi (atau prototype) dan desain telah dibuat, maka masing-masing harus di perkirakan untuk kualitas. Aktivitas utama yang memenuhi penaksiran kualitas adalah MPSI 49

10 formal technical review (FTR). FTR merupakan pertemuan khusus yang diadakan oleh staff teknikal dengan tujuan untuk menemukan masalah. Dalam berbagai situasi, review merupakan hal yang efektif seperti ujicoba dalam mengungkap kerusakan dalam software. 3. Ujicoba perangkat lunak (software testing) Ujicoba software mengkombinasikan strategi beberapa tahapan/langkah dengan sejumlah desain metode uji kasus yang membantu memastikan pendeteksian kesalahan yang efektif. Banyak pengembang software menggunakan ujicoba software sebagai jaminan kualitas. 4. Pelaksanaan standar (enforcement of standards) Tingkatan dimana prosedur dan standar formal diaplikasikan dalam proses pengembangan software, sangat bervariasi antara satu perusahaan dengan yang lainnya. Dalam banyak kasus, standar ditentukan oleh konsumen atau pembuat kebijakan. Jika standar disediakan(secara formal tertulis) maka aktivitas SQA harus dilaksanakan untuk memastikan standar-standar tersebut dilakukan. 5. Pengawasan terhadap perubahan (control of change) Ancaman utama dalam kualitas software adalah perubahan yang dilakukan terhadap sumber. Setiap perubahan yang dilakukan pada software sangat potensial untuk menghasilkan kesalahan atau membuat efek sampingan yang mengakibatkan kesalahan. Proses pengawasan perubahan memberikan kontribusi secara langsung terhadap kualitas software dengan permintaan perubahan yang diformalkan. Pengawasan perubahan diaplikasikan selama pengembangan software dan setelahnya, atau selama tahapan pemeliharaan software. 6. Pengukuran (measurement) Pengukuran (measurement) merupakan aktivitas yang melengkapi setiap bidang pengembangan. Tujuan utama dari SQA adalah untuk menelusuri kualitas software dan memperkirakn pengaruh dari perubahan secara metodologi maupun prosedur pada peningkatan kualitas software. Untuk itu, ukuran-ukuran software (software metrics) harus dikumpulkan. 3. Penyimpanan catatan dan laporan (record keeping and re porting) Penyimpanan catatan dan perekaman (record keeping and recording) pada SQA menyediakan prosedur untuk mengumpulkan dan penyebaran informasi SQA. Hasil dari review, audit, pengawasan perubahan, ujicoba, dan aktivitas SQA lainnyaharus menjadi bagian dari record history untuk proyek dan harus disebarkan untuk staff pengembangan untuk pengetahuan. D. Tinjauan Ulang Perangkat Lunak (Software Review) Software review merupakan filter selama proses pengembangan software. Review diaplikasikan pada beberapa titik selama pengembangan software dan dilakukan untuk membongkat cacat yang kemudian dapat dihilangkan. Software review dilakukan untuk memperbaiki aktivitas pengembangan software yang seperti analisis, perancangan dan MPSI 50

11 pengkodean. Sebuah tinjauan ulang/review merupakan suatu cara yang memanfaatkan keberagaman sekelompok orang untuk : 1. Mengetahui peningkatan yang diperlukan oleh suatu produk seseorang atau tim 2. Mengkonfirmasikan bahwa peningkatan bagian-bagian suatu produk tidak diiinginkan atau tidak diperlukan 3. Pencapaian pekerjaan secara teknis yang lebih seragam, atau sedikitnya lebih dapat diramalkan, mutu yang dapat dicapai tanpa tinjauan ulang, dalam rangka membuat pekerjaan teknis yang lebih dapat dikendalikan 4. Review Teknikal Formal (Formal Technical Review) FTR merupakan aktivitas SQA yang dilakukan oleh praktisi pengembang software. Tujuan dari FTR adalah : 1. Untuk menemukan kesalahan dalam fungsi, logika atau implementasi untuk semua representasi software 2. Untuk memverifikasi bahwa software yang sedang di-review telah memenuhi kebutuhan 3. Untuk memastikan bahwa software yang direpresentasikan sesuai dengan standar yang didefinisikan diawal (predefined) 4. Untuk mendapatkan software yang dikembangkan dengan bentuk yang sama uniform) 5. Untuk membuat suatu proyek lebih mudah diatur (manageable) Sebagai tambahan, FTR diberikan sebagai pelatihan dasar, sehingga memungkinkan pengembang junior mengamati pendekatan yang berbeda terhadap analisis, desain dan implementasi software. Pertemuan Review (review meeting) Ketika format FTR telah ditetapkan, maka diadakan pertemuan yang memiliki batasanbatasan : a. Menyertakan sedikitnya 3 atau 5 orang (Khusus) b. Persiapan yang baik harus ada tetapi harus memerlukan waktu tidak lebih dari 2 jam kerja untuk setiap orangnya c. Durasi dari pertemuan tidak lebih dari 2 jam FTR difokuskan pada hal yang spesifik, seperti produk komponen dari software (spesifikasi kebutuhan, detail desain modul). akhir dari sebuah review, seluruh peserta FTR harus memutuskan : 1. Menerima produk tanpa modifikasi lanjutan 2. Menolak produk sampai dengan kesalahan yang ada teratasi (dan melakukan review kembali) 3. Menerima produk dengan syarat (kesalahan minor terdeteksi dan harus diperbaiki) Laporan review dan penyimpanan catatan (Review Reporting and Record Keeping) MPSI 51

12 Selama FTR, terdapat peserta yang merekam seluruh hal yang telah dicapai, kemudian dirangkum pada akhir dari meeting. Laporan rangkuman dari review menjawab 3 pertanyaan berikut : 1. Apa yang telah di-review? 2. Siapa yang me-review? 3. Apa yang ditemukan dan penanganannya? Daftar hal-hal yang di-review memiliki 2 kegunaan : (1) Untuk identifikasi area masalah dalam produk dan (2) untuk diberikan sebagai checklist aktifitas yang membimbing produser ketika perbaikan dilakukan. Review Guidelines Hal-hal dibawah ini merepresentasikan sekumpulan panduan minimum untuk FTR, yaitu : 1. Me-review produk, bukan pembuatnya 2. Buatlah Agenda dan tetap mengaturnya 3. Batasi debat dan bantahan 4. Menjelaskan area permasalahan, tetapi jangan berusahan untuk menyelesaikan setiap permasalahan yang ada Buatlah catatan 5. Batasi jumlah partisipan dan mintalah persiapan yang matang 6. Buatlah checklist untuk setiap produk yang akan direview 7. Alokasikan sumberdaya dan waktu untuk FTR 8. Selenggarakan pelatihan yang berarti untul seluruh reviewer 9. Review terlebih dahulu hasil review sebelumnya Review Checklist FTR dapat dilaksanakan pada setiap tahapan selama proses pengembangan software berlangsung. Berikut ini merupakan checklist yang dapat digunakan untuk menaksir produk yang merupakan bagian dari pengembangan software : 1. Software engineering Spesifikasi sistem mengalokasikan fungsi-fungsi dan performa untuk beberapa elemen yang fokus pada masing-masing bagian, baik hardware maupun software. Quality assurance menaksir validasi tingkat kebutuhan sistem dan layanan fungsi MPSI 52

13 memeriksa kebutuhan diagnostik. Berikut beberapa daftar pertanyaan yang fokus pada area-area penting dalam software engineering : a) Apakah fungsi-fungsi utama telah didefinisikan dalam batasan dan bentuk yang telah ditetapkan? b) Apakah interface antar elemen sistem telah didefinisikan? c) Apakah batasan performa telah ditentukan bagi keseluruhan sistem maupun setiap elemen sistem? d) Apakah mekanisme untuk validasi dan verifikasi sistem telah ditetapkan? 2. Software project planning Tahapan ini menilai resiko dan mengembangkan estimasi sumber daya, biaya dan jadwal berdasarkan alokasi software yang ada sebagai bagian dari aktivitas pengembangan sistem. Checklist yang dapat digunakan : a) Apakah terminologi sistem telah jelas? b) Apakah sumberdaya yang terperlukan tersedia dan mudah didapat? c) Apakah seluruh resiko telah didefinisikan? d) Apakah seluruh pekerjaan telah didefinisikan dan diurutkan? Apakah dengan pekerjaan paralel dapat memberikan sumberdaya lebih? 3. Software requirements analysis Menitikberatkan pada kemampuan menelusur ulang kebutuhan sistem dan konsistensi serta ketepatan dari model analisis. FTR yang dapat digunakan : a) Apakah batasan informasi analisis telah lengkap, konsisten, dan akurat? b) Apakah pembagian masalah telah lengkap? c) Apakah interface internal dan eksternal telah didefinisikan dengan tepat? d) Apakah model data merefleksikan objek data, atributnya dan relasinya? e) Apakah disediakan prototyping untuk para end user/costomer? 4. Software design MPSI 53

14 Meninjau ulang rancangan software dengan fokus kepada rancangan data, rancangan arsitektural dan rancangan prosedural. Menitikberatkan kepada ketepatan algoritma yang diimplementasikan dalam modul/program. Pada review preliminary design : a) Apakah kebutuhan software direfleksikan dalam arsitektur software? b) Apakah efektivitas modular terpenuhi? Apakah modul-modul dapat berfungsi secara independen? c) Apakah struktur data konsisten dengan batasan informasi? d) Apakah struktur data konsisten dengan kebutuhan software? e) Apakah pemeliharaan telah dipertimbangkan? Pada saat perancangan : a) Apakah algoritma yang digunakan dapat memenuhu fungsi yang diinginkan? b) Apakah logika algoritma yang digunakan sudah benar? c) Apakah interface yang dihasilkan konsisten dengan rancangan arsitektural? d) Apakah penanganan kesalahan dan antibugging telah dispesifikasikan? 5. Coding Kesalahan biasanya terjadi pada saat proses merubah rancangan kedalam sebuah bahasa pemrograman. Memeriksa ulang program merupakan cara yang efektif untuk mencari kesalahan translasi. Checklist yang digunakan paada fase perancangan memastikan bahwa algoritma yang benar telah diterapkan. a) Apakah terdapat kesalahan eja dan pengetikan program? b) Apakah terdapat ketidak sesuaian dengan standar pemrograman seperti cara penulisan, komentar, dan prolog modul? c) Apakah terdapat komentar yang tidak benar/ambigu? d) Apakah tipe data dan deklarasi data telah sesuai? 6. Software testing Ujicoba software merupakan salah satu aktivitas jaminan kualitas. Kelengkapan dan MPSI 54

15 efektivitas ujicoba secara dramatis dapat meningkatkan dengan menilai rencana uji dan prosedur yang akan dilakukan. Pada rencana ujicoba : a) Apakah tahapan ujicoba utama telah diidentifikasikan dan diurutkan? b) Apakah kemampuan penelusuran kriteria validasi telah dibuat sebagai bagian dari analisis kebutuhan software? c) Apakah rencana ujicoba konsisten dengan rencana proyek keseluruhan? d) Apakah jadwal ujicoba telah didefinisikan secara eksplisit? e) Apakah mekanisme penyimpanan catatan ujicoba telah disediakan? Pada prosedur ujicoba : a) Apakah ujicoba white box dan black box telah dispesifikasikan? b) Apakah seluruh jalur logika yang independen telah diuji? c) Apakah penanganan kesalahan telah diuji? d) Apakah batasan-batasan nilai telah diuji? e) Apakah respon waktu performa telah diperiksa? 7. Maintenance Checklist review untuk pengembangan software sama halnya dengan tahap pemeliharaan software. Terdapat beberapa pertimbangan yang harus tetap diperhatikan : a) Apakah efek samping dari suatu perubahan telah dipertimbangkan? b) Apakah permintaan perubahan software telah didokumentasikan, dievaluasi dan disetujui? c) Apakah suatu perubahan yang dilaksanakan telah didokumentasikan dan dilaporkan kepada seluruh pihak yang terkait? MPSI 55