Pengertian OOA Object Oriented Analysis Pengertian OOD Object Oriented Design Syarat-syarat dan Tahap Pengembangan

2.8 Pengertian OOA Object Oriented Analysis

Object Oriented Analysis Analisis Berorientasi Objek adalah sebuah teknik model driven yang mengintegrasikan data dan proses kedalam konstruksi yangdisebut objek. Model-model OOA adalah gambar-gambar yang mengilustrasikanobjek-objek sistem dari berbagai macam perpsektif, seperti srtuktur, kelakuan, dan interaksi objek-objek Whitten et al. 2004.

2.9 Pengertian OOD Object Oriented Design

Object Oriented Design Perancangan Berorientasi Objek adalah sebuah pendekatan yang digunakan untuk menentukan solusi perangkat lunak khususnya pada objek yang berkolaborasi, atribut mereka dan metode mereka Whitten et al. 2004.

2.10 Syarat-syarat dan Tahap Pengembangan

1. Tahap Perencanaan Syarat Requirement Planning

Fase Perencanaan Syarat . Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk mengidentifikasi syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Fase ini memerlukan peran aktif mendalam dari kedua kelompok tersebut; tidak hanya menunjukkan proposal atau dokumen. Selain itu, juga melibatkan pengguna dari beberapa level yang berbeda dalam organisasi. Dalam fase ini pula, saat syarat-syarat informasi sedang disebut-sebut, Anda bisa bekerja dengan CEO bila ini merupakan sebuah organisasi besar serta dengan para perencana strategik, khususnya bila Anda bekerja dengan sebuah aplikasi e-commerce yang berusaha meneruskan tujuan-tujuan strategik organisasi. Orientasi dalam fase ini ialah menyelesaikan problem-problem perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan Kendall dan Kendall, 2008. Fase Requirement Planning menggabungkan fase Planning dan fase Systems Analysis di dalam elemen SDLC Systems Developement Life Cycle. Shelly dan Rosenblatt, 2012. Elemen SDLC pada fase planning dan analisis adalah sebagai berikut Whitten dan Bentley, 2008, yaitu: 1. Identifikasi kebutuhan sistem 2. Analisis sitem yang berjalan 3. Identifikasi masalah 4. Analisis sistem usulan

2. Tahap Desain Workshop Design RAD

Workshop Desain RAD . Fase ini merupakan fase perancangan serta perbaikan yang dapat digambarkan sebagai sebuah workshop. Selama workshop desain RAD, pengguna merespon prototype yang sedang dikerjakan dan penganalisis memperbaiki modul desain berdasarkan respon pengguna. Format workshop sangat mengagumkan dan memberikan dorongan, dan jika pengguna serta penganalisis merupakan orang yang berpengalaman, maka tidak diragukan lagi bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat terakselerasi. RAD fase Design Workshop pada konseptualis fase RAD James Martin menggabungkan fase user design dan fase construction menjadi satu, karena interaksi yang tinggi dan proses sifat visual design-and-refine dibutuhkan di dalam interaktif Kendall dan Kendall, 2008. Dalam fase User Design, pengguna berinteraksi dengan System Analysts dan model serta prototype yang dikembangkan yang mewakili semua proses sistem, output , dan input. Tim RAD secara khusus menggunakan kombinasi teknik JAD dan Case Tools untuk mengetahui kebutuhan user dalam mengerjakan model. User design akan terus berlanjut, proses interaksi yang akan memungkinkan pengguna untuk mengerti, memodifikasi, dan pada akhirnya menyetujui model sistem yang dikerjakan setelah memenuhi kebutuhan mereka Shelly dan Rosenblatt, 2012. Di fase construction berjalan banyak aktifitas yang berbeda. Desain yang buat pada fase sebelumnya akan dikembangkan oleh tools RAD. Setelah fungsi baru telah ada, fungsi akan memperlihatkan pada user untuk berinteraksi, berkomentar, dan me-review. Dengan tools RAD, analyst dapat membuat perubaha berkelanjutan pada desain aplikasi Kendall dan Kendall, 2008. A. Desain Proses Proses sistem informasi merespons kejadian dan kondisi bisnis dan mentransformasi data menjadi informasi yang berguna. Pemodelan proses membantu memahami interaksi dengan lingkungan sistem, sistem lain, dan proses lain Whitten dan Bentley, 2008. Model proses paling sederhana dari sebuah sistem didasarkan pada input, output, dan sistem itu sendiri yang ditampilkan sebagai proses. Simbol proses mendefinisikan batasan sistem. Sistem tersebut berada dalam batasan, sedangkan lingkungan sistem berada di luar batasan sistem tersebut. Sistem mempertukarkan input dan output dengan lingkungannya. Karena lingkungan selalu berubah, maka sistem yang didesain dengan baik memiliki loop umpan balik dan kontrol yang memungkinkan sistem menyesuaikan dirinya dengan perubahan kondisi Whitten dan Bentley, 2008. Proses adalah kerja yang dilakukan pada atau sebagai respon terhadap aliran data masuk atau kondisi. Sinonimnya adalah transformasi. Proses logika adalah pekerjaan atau tindakan yang harus dilakukan tidak peduli bagaimana mengimplementasikan sistem tersebut. Tiap proses logika adalah diimplementasikan sebagai satu proses fisik atau lebih yang dapat menyertakan pekerjaan yang dilakukan oleh orang, pekerjaan yang dilakukan oleh robot atau mesin, atau pekerjaan yang dilakukan oleh perangkat lunak komputer. Proses logika terdiri dari fungsi, kejadian, dan proses elementer Whitten dan Bentley, 2008. Fungsi function adalah kumpulan kegiatan yang saling terkait dan terus- menerus pada suatu bisnis. Fungsi tidak memiliki awal dan akhir; melainkan hanya bekerja terus-menerus pada saat dibutuhkan Whitten dan Bentley, 2008. Kejadian event adalah unit kerja logika yang harus diselesaikan secara keseluruhan. Suatu kejadian dipicu oleh input diskrit dan diselesaikan pada saat proses merespons dengan output yang sesuai. Kejadian kadang disebut transaksi. Fungsi terdiri dari proses yang merespons kejadian Whitten dan Bentley, 2008. Proses event selanjutnya di dekomposisi menjadi proses elementer yang mengilustrasikan secara detail bagaimana sistem harus merespons suatu event. Elementary process proses elementer adalah kegiatan atau tugas detail dan diskrit yang dibutuhkan untuk melengkapi respons terhadap suatu event Whitten dan Bentley, 2008. Proses pemodelan use-case persyaratan Whitten dan Bentley, 2008: 1. Mengidentifikasi Pelaku Bisnis Dengan memusatkan perhatian pada pelakunya, dan berkonsentrasi pada bagaimana sistem itu akan digunakan dan bagaimana akan dibangun. Mengidentifikasikan pelaku bisnis juga dapat membantu menyaring dan mendefinisikan lebih lanjut lingkup dan batasan sistem Armour dan Miller, 2001. Berikut beberapa pertanyaan untuk mencari pelaku bisnis Whitten dan Bentley, 2008:  Siapa atau apa yang menyediakan input ke dalam sistem?  Siapa atau apa yang menerima output dari sistem?  Antarmuka apa yang dibutuhkan bagi sistem yang lain?  Apakah ada kejadian yang dipicu secara otomatis pada waktu yang telah ditentukan sebelumnya?  Siapa yang akan mengurusi informasi dalam sistem? 2. Mengidentifikasi Use-case Persyaratan Bisnis Use-case menggambarkan bagaimana para pelaku sebenarnya berinteraksi dengan sistem, maka teknik yang bagus untuk mencari use-case persyaratan bisnis adalah dengan menyelidiki para pelaku dan bagaimana mereka akan menggunakan sistem tersebut. Berikut beberapa pertanyaan untuk mencari use-case Whitten dan Bentley, 2008:  Apa tugas utama pelaku tersebut?  Informasi apa yang dibutuhkan pelaku untuk sistem?  Apakah sistem tersebut perlu menginformasikan kepada pelaku tentang segala perubahan atau kejadian yang telah terjadi?  Apakah ada kebutuhan para pelaku untuk menginformasikan segala perubahan yang terjadi atau kejadian-kejadian yang muncul? 3. Membuat Diagram Model Use-case Setelah use-case dan pelaku teridentifikasi, diagram use-case pun dapat digunakan untuk menggambarkan secara grafis lingkup dan batasan sistem Whitten dan Bentley, 2008. 4. Mendokumentasikan Naratif Use-case Persyaratan Bisnis Sebelum mempersiapkan naratif, dilakukan pendokumentasian terlebih dahulu pada level tinggi high level agar dapat memahami event dan besar sistem. Naratif use- case mencakup beberapa hal berikut Whitten dan Bentley, 2008:  Pengarang – Nama individu yang membantu dalam penulisan use-case dan yang menyediakan titik kontak ke setiap orang yang memerlukan informasi tambahan tentang use-case tersebut.  Tanggal – Tanggal use-case dimodifikasi terakhir kali.  Versi – Versi terbaru use-case.  Nama use-case – Nama use-case harus menunjukkan tujuan yang akan dipenuhi use-case tersebut.Nama tersebut sebaiknya mulai dengan kata kerja.  Tipe use-case – Tipe use-case ini adalah business-oriented dan merefleksikan tampilan high-level dari behavior sistem yang diinginkan.  Use-case ID – Identifier yang secara unik mengidentifikasi use-case.  Prioritas – Prioritas mengkomunikasikan pentingnya use-case dalam konteks high, medium , atau low.  Sumber – Sumber mendefinisikan entitas yang memicu pembuatan use-case.  Pelaku bisnis primer – Pelaku bisnis primer adalah stake holder yang mendapatkan keuntungan utama dari eksekusi use-case dengan menerima nilai terukur atau teramati.  Pelaku peserta lain – Pelaku lain yang berpartisipasi dalam use-case untuk mencapai tujuannya meliputi pelaku penginisiasi, pelaku pemfasilitasi, pelaku server atau receiver, dan pelaku sekunder.  Stakeholder yang berminat – stakeholder adalah siapapun yang berperan dalam pengembangan dan operasi sistem perangkat lunak. Stakeholder yang berminat adalah orang selain pelaku yang tertarik dengan tujuan use-case.  Deskripsi – deskripsi ringkasan pendek yang berisi sejumlah kalimat yang menunjukkan secara garis besar tujuan use-case dan berbagai kegiatannya. Proses pemodelan objek ialah sebagai berikut Whitten dan Bentley, 2008: 1. Memodelkan fungsi sistem Dalam memodelkan fungsi sistem perlu memperluas model use-case analisis dengan melakukan langkah-langkah berikut:  Mengidentifikasi, mendefinisikan, dan mendokumentasikan pelaku-pelaku baru  Mengidentifikasi, mendefinisikan, dan mendokumentasikan use-case baru  Mengidentifikasi semua Reuse yang mungkin  Memperbaiki diagram model use-case jika perlu  Mendokumentasi naratif use-case analisis sistem 2. Menemukan dan mengidentifikasi objek bisnis Langkah 1: Menemukan Objek Potensial Langkah ini diselesaikan dengan cara meninjau setiap use-case untuk menemukan kata-kata benda yang berhubungan dengan keseluruhan bisnis atau event . Langkah 2: Menyeleksi Objek yang Diusulkan Tidak semua kata benda yang ditemukan dalam setiap use-case menggambarkan objek bisnis yang ada dalam lingkup domain masalah.Tiap-tiap kata benda tersebut harus dianalisis kembali, agar dapat ditentukan kata benda mana saja yang dipertahankan atau dihapus. 3. Mengorganisir Objek dan Mengidentifikasi Hubungan Objek Langkah 1: Mengidentifikasi Asosiasi dan Multiplicity Langkah 2: Mengidentifikasi Hubungan Generalisasispesialisasi Langkah 3: Mengidentifikasi Hubungan Agregasi Langkah 4: Menyiapkan Diagram Kelas B. Desain Input Data capture adalah identifikasi dan penambahan data baru. Penambahan data baru tersebut dapat berasal dari source document. Source document adalah form yang digunakan untuk menyimpan transaksi perusahaan, khususnya data-data yang ada pada transaksi tersebut Whitten dan Bentley, 2008. Desain source document sangat membutuhkan kecermatan, layout dan keterbacaan akan mempengaruhi kecepatan data entry. Data entry adalah suatu proses translasi source data atau dokumen ke dalam format yang mudah dibaca oleh komputer Whitten dan Bentley, 2008. Berikut langkah-langkah proses desain input Whitten dan Bentley, 2008: 1. Mengidentifikasi input sistem dan memeriksa persyaratan logika. 2. Memilih kontrol GUI yang sesuai. 3. Mendesain, memvalidasi, dan mengetes input. 4. Mendesain source document jika perlu. C. Desain Output Output menggambarkan informasi bagi pengguna sistem. Output adalah komponen yang paling dapat dilihat dari sistem informasi yang bekerja. Oleh karena itu, output menjadi basis penilaian akhir manajemen terhadap kesuksesan sebuah sistem Whitten dan Bentley, 2008. Output dapat digolongkan ke dalam dua karakteristik Whitten dan Bentley, 2008, yaitu: 1. Distribusi dan audiens output Salah satu cara untuk menggolongkan output adalah dengan melihat distribusi mereka apakah ke dalam atau di luar perusahaan, dan orang-orang yang membaca dan menggunakan output. Internal output digunakan untuk para pemilik dan pengguna sistem dalam sebuah perusahaan Whitten dan Bentley, 2008. Berikut tiga jenis output internal Whitten dan Bentley, 2008: 1. Detailed report – output internal yang menggambarkan informasi dengan sedikit atau bahkan tanpa pemeriksaan. 2. Summary report – output internal yang mengelompokkan berbagai informasi bagi manajer. 3. Exception report – output internal yang menyaring data untuk menunjukkan informasi yang berisi perkecualian-perkecualian atau standar tertentu. Eksternal output merupakan kebalikan dari internal output. Output ini ditujukan kepada konsumen, pemasok, mitra bisnis, dan badan pemerintahan. Output eksternal menyimpulkan dan melaporkan transaksi bisnis Whitten dan Bentley, 2008. 2. Metode Implementasinya. Printed output – media yang sering digunakan untuk output computer adalah kertas – printed output . Printed output dapat dihasilkan oleh impact printer Screen output – media output komputer yang mengalami pertumbuhan paling cepat adalah display online dari informasi pada peralatan display visual. Berikut beberapa langkah proses desain output Whitten dan Bentley, 2008: 1. Mengidentifikasi output sistem dan meninjau kembali persyaratan logika. 2. Menentukan persyaratan output fisik. 3. Desain, lakukan validasi, dan uji output. D. Desain Database Tujuan desain database adalah sebagai berikut Whitten dan Bentley, 2008:  Database harus menyediakan penyimpangan yang efisien, pembaruan, dan perolehan kembali sebuah data.  Database harus andal – data yang disimpan harus memiliki integritas tinggi untuk membuat pengguna mempercayai data.  Database harus dapat diadaptasi dan diskala untuk persyaratan dan aplikasi baru yang belum tampak atau muncul. Desain database digambarkan sebagai sebuah model khusus yang disebut skema database. Skema database adalah model fisik atau cetak biru untuk sebuah database . Skema ini menggambarkan implementasi teknis dari model data logis Whitten dan Bentley, 2008. Skema database relasional menentukan struktur database dalam hal tabel, key , index, dan aturan-aturan integritas. Skema database menentukan rincian-rincian berdasarkan kemampuan, terminologi, dan batasan dari sistem manajemen database yang telah dipilih. Setiap DBMS mendukung berbagai tipe data yang berbeda, aturan- aturan integritas, dan sebagainya Whitten dan Bentley, 2008. Integritas data menyediakan kontrol-kontrol internal pada sebuah database. Paling sedikit ada tiga tipe integritas data yang harus didesain pada semua database Whitten dan Bentley, 2008. Key integrity – setiap tabel harus memiliki primary key. Primary key harus dikontrol supaya tidak ada dua record pada tabel yang punya nilai primary key yang sama. Selain itu, primary key pada sebuah record tidak pernah boleh memiliki nilai Null . Nilai tersebut akan mengalahkan tujuan primary key yang secara unik mengidentifikasikan record Whitten dan Bentley, 2008. Domain integrity – kontrol-kontrol yang sesuai harus didesain untuk memastikan bahwa tidak ada field pada sebuah nilai di luar range nilai illegal Whitten dan Bentley, 2008. Referential integrity – arsitektur database relasional mengimplementasikan hubungan antara record pada tabel melalui foreign keys. Penggunaan foreign key meningkatkan fleksibilitas dan skalabilitas beberapa database, tetapi juga meningkatkan risiko kesalahan-kesalahan integritas referensial. Kesalahan integritas referensial muncul saat nilai foreign key pada satu tabel tidak sesuai dengan nilai primary key pada tabel terkait Whitten dan Bentley, 2008. E. Desain Interface Proses desain interface dimulai dengan menentukan jenis pengguna, human factor , dan petunjuk human engineering yang akan mempengaruhi desain antarmuka pengguna. Jenis pengguna sistem system user diklasifikasikan menjadi dua Whitten dan Bentley, 2008, yaitu:  Expert User, adalah pengguna komputer yang berpengalaman yang banyak menghabiskan waktunya untuk menggunakan program aplikasi khusus.  Novice User atau Casual User, adalah pengguna komputer yang pengalamannya lebih sedikit, atau bahkan pada saat-saat tertentu saja. Adapun masalah human factor adalah sebagai berikut Whitten dan Bentley, 2008:  Terlalu banyak menggunakan akronim komputer  Desain yang tidak jelas atau kurang intuitif  Tidak mampu membedakan antara tindakan pilihan “Apa yang harus saya lakukan selanjut nya?”  Pendekatan pemecahan masalah yang tidak konsisten  Ketidakkonsistenan desain Beberapa faktor human engineering penting harus digabungkan pada desain Whitten dan Bentley, 2008:  Pengguna sistem harus selalu menyadari apa yang harus dilakukan selanjutnya. Beberapa situasi membutuhkan beberapa tipe feedback:  Screen harus diformat sehingga segala jenis tipe informasi, perintah, dan pesan selalu muncul pada area tampilan umum yang sama.  Pesan, perintah, atau informasi harus ditampilkan dengan cukup panjang secukupnya sehingga pengguna sistem dapat membacanya.  Gunakan atribut tampilan display attributes dengan hemat.  Nilai yang salah pada field dan jawaban yang harus dimasukkan oleh pengguna harus ditentukan.  Berkenaan dengan error, pengguna seharusnya tidak diperkenankan untuk meneruskan langkah sebelum memperbaiki error tersebut.  Jika pengguna melakukan sesuatu yang dapat menimbulkan akibat yang parah, maka keyboard harus dikunci untuk mencegah semua input lain dan perintah untuk memanggil analis atau technical support harus ditampilkan. Antarmuka Menu-Driven ialah strategi dialog yang mengharuskan pengguna memilih sebuah action dari menu pilihan. Berikut langkah proses desain antarmuka pengguna adalah sebagai berikut Whitten dan Bentley, 2008:  Petakan dialog antarmuka pengguna, sebuah antarmuka pengguna dapat melibatkan banyak screen. Beberapa screen dapat muncul berulang sampai kondisi yang diinginkan tercapai agar tidak menimbulkan masalah yang lebih sulit. State Transition Diagram STD digunakan untuk menggambarkan urutan dan variasi screen yang dapat terjadi selama satu sesi pengguna.  Membuat prototype dialogue dan antarmuka pengguna  Dapatkan feedback dari pengguna

3. Tahap Implementasi Implementation

Fase Implementasi . Penganalisis bekerja dengan para pengguna secara intens selama workshop untuk merancang aspek-aspek bisnis dan nonteknis dari perusahaan. Segera sesudah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem diuji coba dan kemudian diperkenalkan kepada organisasi. Karena RAD dapat digunakan untuk menciptakan aplikasi-aplikasi e-commerce baru dimana dalam hal itu sistem lama tidak digunakan lagi, seringnya tidak perlu dan memang tidak bisa menjalankan sistem lama dan sistem baru secara paralel sebelum implementasi Kendall dan Kendall, 2008.

A. Fase Konstruksi

Tujuan fase konstruksi adalah untuk membangun dan menguji sebuah sistem fungsional yang memenuhi persyaratan bisnis dan desain dan untuk mengimplementasi antarmuka sistem yang baru. Aspek utama dari fase ini ialah pemrograman sistem Whitten dan Bentley, 2008.

B. Fase Implementasi

Kemampuan pengujian perangkat lunak hanya seberapa mudah program komputer dapat diuji. Karakteristik sebagai berikut menyebabkan perangkat lunak diuji. Pengoperasian . Semakin baik bekerja, lebih efisien dapat diuji. Jika sistem yang dirancang dan dilaksanakan dengan kualitas dalam pikiran, relatif sedikit bug akan memblokir pelaksanaan tes, yang memungkinkan pengujian untuk kemajuan tanpa cocok dan mulai. Observabilitas . Apa yang Anda lihat adalah apa yang Anda uji. Input disediakan sebagai bagian dari pengujian menghasilkan output yang berbeda. Menyatakan sistem dan variabel yang terlihat atau queriable selama eksekusi. Keluaran yang salah dengan mudah diidentifikasi. Kesalahan internal dideteksi secara otomatis dan dilaporkan. Source code dapat diakses. Pengendalian . Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian dapat diotomatisasi dan dioptimalkan. Perangkat lunak dan Pernyataan perangkat keras dan variabel dapat dikontrol langsung oleh teknisi tes. Uji dapat dengan mudah ditentukan, diotomatisasi, dan diproduksi ulang. Decomposability . Dengan mengontrol ruang lingkup pengujian, kita bisa lebih cepat mengisolasi masalah dan melakukan pengujian ulang yang lebih cerdas. Sistem perangkat lunak dibangun dari modul independen yang dapat diuji secara independen. Kemudahan . Semakin sedikit ada untuk menguji, semakin cepat kita bisa mengujinya. Program ini harus menunjukkan kemudahan fungsional, kemudahan struktural, dan kode kemudahan. Stabilitas . Semakin sedikit perubahan, semakin sedikit gangguan pengujian. Perubahan ke perangkat lunak jarang terjadi, dikendalikan saat mereka melakukan dan tidak membatalkan tes yang ada. Pemulihan perangkat lunak dengan baik dari kegagalan. Dimengerti . Semakin banyak informasi yang kita miliki, semakin cerdas kita akan menguji. Desain arsitektur dan ketergantungan antara komponen internal, eksternal, dan berbagi dipahami dengan baik. Dokumentasi teknis adalah langsung diakses, terorganisasi dengan baik, spesifik, rinci, dan akurat.Perubahan desain dikomunikasikan kepada penguji.

C. Uji karakteristik

1. Tes yang baik memiliki probabilitas tinggi untuk menemukan kesalahan. Untuk mencapai tujuan ini, penguji harus memahami perangkat lunak dan berusaha untuk mengembangkan gambaran mental tentang bagaimana perangkat lunak mungkin gagal. Idealnya, kelas kegagalan yang diperiksa. Misalnya, satu kelas dari potensi kegagalan di GUI graphical user interface adalah kegagalan mengenali posisi mouse yang tepat. Satu set tes akan dirancang untuk melaksanakan mouse dalam upaya untuk menunjukkan kesalahan dalam posisi pengakuan Mouse. 2. Tes yang baik tidak berlebihan. Pengujian waktu dan sumber daya yang terbatas. Tidak ada gunanya melakukan tes yang memiliki tujuan yang sama dengan tes lain. Setiap tes harus memiliki tujuan yang berbeda. 3. Tes yang baik harus berkembang lebih baik. Dalam kelompok tes yang memiliki niat yang sama, waktu dan sumber daya keterbatasan dapat mengurangi terhadap pelaksanaan hanya subset dari tes ini. Dalam kasus tersebut, tes yang memiliki kemungkinan tertinggi mengungkap seluruh kelas kesalahan harus digunakan. 4. Tes yang baik harus tidak terlalu sederhana dan tidak terlalu rumit. Meskipun kadang-kadang mungkin untuk menggabungkan serangkaian tes menjadi satu uji kasus, efek samping yang mungkin terkait dengan pendekatan ini dapat menutupi kesalahan. Secara umum, setiap tes harus dijalankan secara terpisah.

D. Pengujian Sistem

Setiap produk rekayasa dan banyak hal lainnya dapat diuji di salah satu dari dua cara: 1 Mengetahui fungsi tertentu bahwa suatu produk telah dirancang untuk melakukan, tes dapat dilakukan yang menunjukkan fungsi masing-masing adalah saat beroperasi penuh pada saat yang sama mencari kesalahan dalam setiap fungsi, 2 Mengetahui cara kerja internal produk, pengujian dapat dilakukan untuk memastikan bahwa semua gigi jala, yaitu operasi internal dilakukan sesuai dengan spesifikasi yang dan semua komponen internal telah dilaksanakan secara memadai. Pendekatan uji disebut pengujian black-box dan yang kedua, pengujian white-box. Pengujian black-box menyinggung tes yang dilakukan pada antarmuka perangkat lunak.Pengujian black-box mengkaji beberapa aspek fundamental dari sistem tanpa memperhatikan struktur logika internal perangkat lunak. Pengujian white-box perangkat lunak didasarkan pada pemeriksaan dekat detail prosedural. Jalur logis melalui perangkat lunak dan kolaborasi antara komponen diuji dengan memberikan kasus uji bahwa olahraga set kondisi yang spesifik dan atau loop. Pada pandangan pertama akan terlihat bahwa sangat melalui pengujian white- box akan menyebabkan 100 persen program yang benar. Semua yang perlu kita lakukan adalah mengidentifikasi semua jalur logis, mengembangkan uji kasus untuk latihan mereka, dan mengevaluasi hasil, yaitu, menghasilkan kasus uji untuk menjalankan logika program secara mendalam. Sayangnya, pengujian lengkap menyajikan masalah logistik tertentu.pengujian white-box tidak, bagaimana pun, diberhentikan sebagai tidak praktis. Sejumlah terbatas jalur logis yang penting dapat dipilih dan dilaksanakan.Struktur data penting dapat diperiksa untuk validitas.

E. Pengujian White-Box

Pengujian White-Box, kadang-kadang disebut pengujian glass-box, adalah kasus uji filosofi desain yang menggunakan struktur kontrol digambarkan sebagai bagian dari desain komponen-tingkat untuk mendapatkan uji kasus. Menggunakan metode pengujian white-box, insinyur perangkat lunak dapat memperoleh uji kasus yang 1 menjamin bahwa semua jalur independen dalam modul telah latihan setidaknya sekali, 2 melaksanakan semua keputusan logis pada sisi mereka benar dan salah, 3 mengeksekusi semua loop pada batas mereka dan dalam batas-batas operasional mereka, dan 4 latihan struktur data internal untuk memastikan validitasnya Whitten dan Bentley, 2008.

F. Pengujian Black-Box

Pengujian black-box juga disebut pengujian perilaku, berfokus pada persyaratan fungsional perangkat lunak. Itu adalah pengujian black box memungkinkan perekayasa perangkat lunak untuk mendapatkan set kondisi input yang sepenuhnya akan melaksanakan persyaratan fungsional untuk suatu program. Pengujian black-box bukan merupakan alternatif untuk teknik pengujian white-box. Sebaliknya, itu adalah pendekatan komplementer yang kemungkinan akan mengungkap kelas yang berbeda dari kesalahan daripada metode white-box Whitten dan Bentley, 2008. Pengujian black-box berusaha menemukan kesalahan dalam kategori berikut: 1 tidak benar atau hilang fungsi, 2 kesalahan interface, 3 kesalahan dalam struktur data atau akses basis data eksternal, 4 perilaku atau kinerja kesalahan, dan 5 inisialisasi dan kesalahan terminasi. Tidak seperti pengujian white-box, yang dilakukan pada awal proses pengujian, pengujian black box cenderung diaplikasikan selama tahap akhir pengujian. Karena pengujian black box sengaja mengabaikan struktur pengendalian, perhatian difokuskan pada domain informasi. Tes ini dirancang untuk menjawab pertanyaan-pertanyaan berikut: • Bagaimana validitas fungsional diuji? • Apa kelas input akan membuat kasus uji yang baik? • Apakah sistem sangat sensitif terhadap nilai input tertentu? • Bagaimana batas-batas kelas data terisolasi? • Apa efek akan kombinasi spesifik data terhadap operasi sistem? Dengan menerapkan teknik black-box, kita memperoleh satu set kasus uji yang memenuhi kriteria sebagai berikut: 1 uji kasus yang mengurangi, dengan jumlah yang lebih besar dari satu, jumlah kasus uji tambahan yang harus dirancang untuk mencapai wajar pengujian, dan 2 uji kasus yang memberitahu kita sesuatu tentang ada atau tidak adanya layani kesalahan, daripada kesalahan yang terkait hanya dengan tes khusus di tangan.

2.11 Unified Modelling Language UML