JARKOM

Nama : Annisa Prilya

NPM : 43A87007150334

Jurusan : Sistem Informasi

PENGUJIAN

ANNISA APRILYA
43A87007150334
SI/S1/3B Pagi

PENGUJIAN

Ada dua jenis pendekatan untuk mengidentifikasi cacat pada statis dengan peranti lunak dan dinamis. Dalam analisis statis, kode ini tidak dijalankan tetapi dievaluasi melalui beberapa proses atau beberapa alat untuk mencari cacat. inspeksi kode, yang kita bahas dalam bab sebelumnya, adalah salah satu pendekatan statis. Lain adalah analisis statis kode melalui penggunaan alat-alat. Dalam analisis dinamis, kode dijalankan, dan eksekusi yang digunakan untuk menentukan cacat. Pengujian adalah teknik yang dinamis yang paling umum yang digunakan. Memang, pengujian adalah teknik yang paling umum digunakan untuk mendeteksi cacat, dan melakukan peran yang sangat penting untuk memastikan kualitas.
Dalam bab ini kita akan membahas:

- Konsep dasar dan definisi yang berkaitan dengan pengujian, seperti kesalahan, kesalahan, kegagalan, ujian, test suite, memanfaatkan uji, dll

- Pengujian proses pengujian-bagaimana direncanakan dan bagaimana pengujian unit dilakukan.

- Temukan Uji kasus menggunakan pendekatan pengujian black-box.

- Temukan Uji kasus menggunakan pendekatan kotak putih.

- Beberapa metrik seperti cakupan dan kehandalan yang dapat digunakan selama pengujian-ing.


8.1 Konsep Pengujian

Pada bagian ini kita akan mendefinisikan beberapa istilah yang biasa digunakan ketika membahas pengujian. Kemudian kita akan membahas beberapa masalah dasar yang berkaitan dengan bagaimana pengujian dilakukan, dan pentingnya psikologi tester.

8.1.1 Eror, Kesalahan, dan Kegagalan
Kesalahan istilah digunakan dalam dua cara berbeda. Hal ini mengacu pada perbedaan antara nilai dihitung, mengamati, atau diukur dan nilai sebenarnya, ditentukan, atau secara
teoritis benar. Artinya, kesalahan mengacu pada selisih antara output aktual dari perangkat lunak dan output yang benar. Dalam penafsiran ini, kesalahan pada dasarnya adalah ukuran dari selisih antara aktual dan ideal. Kesalahan ini digunakan untuk merujuk pada tindakan manusia yang menghasilkan perangkat lunak yang mengandung cacat atau kesalahan. Definisi ini cukup umum dan mencakup semua tahap.
Kegagalan adalah ketidakmampuan sistem atau komponen untuk melakukan fungsi yang diperlukan sesuai dengan spesifikasinya. Sebuah kegagalan perangkat lunak terjadi jika perilakudari software ini di ff erent dari perilaku ditentukan. Kegagalan dapat disebabkan oleh faktor fungsional atau kinerja. Perhatikan bahwa definisi tidak berarti bahwa kegagalan harus diperhatikan. Ada kemungkinan bahwa kegagalan mungkin terjadi tetapi tidak terdeteksi.
Perlu dicatat bahwa selama proses pengujian, hanya kegagalan yang ob-dilayani, dimana kehadiran kesalahan disimpulkan. Artinya, pengujian hanya mengungkapkan adanya kesalahan. Kesalahan yang sebenarnya diidentifikasi oleh kegiatan terpisah, sering disebut sebagai "debugging." Dengan kata lain, untuk mengidentifikasi kesalahan, pengujian af-ter telah mengungkapkan adanya kesalahan, tugas mahal debugging harus dilakukan. Ini adalah salah satu alasan mengapa pengujian adalah metode mahal untuk identifikasi kesalahan.

8.1.2 Uji Kasus, Test Suite, dan Test Harness
Perhatikan bahwa dalam kasus uji, masukan uji dan kondisi eksekusi disebutkan secara terpisah. Uji input adalah nilai-nilai tertentu dari parameter atau input lain yangdiberikan kepada SUT baik oleh pengguna atau program lain. Kondisi eksekusi, di sisi lain, mencerminkan keadaan dari sistem dan lingkungan yang juga mempengaruhi perilaku SUT. Jadi, misalnya, saat uji coba fungsi untuk menambahkan catatan jika tidak ada dalam database, perilaku fungsi akan tergantung baik pada nilai catatan masukan serta keadaan database. Dan uji kasus perlu menentukan baik. Misalnya, kasus uji untuk fungsi ini mungkin menentukan rekor r sebagai masukan, dan mungkin menentukan bahwa keadaan database sedemikian rupa sehingga r sudah ada di dalamnya.
Pengujian dapat dilakukan secara manual dengan tester melaksanakan uji kasus dalam test suite dan kemudian memeriksaperilaku tersebut sebagaimana ditetapkan dalam uji kasus. Iniproses yang sangat rumit, terutama ketika test suite berisi sejumlah besar kasus uji. Itu menjadi lebih rumit karena test suite harus sering dijalankan setiap kali SUT berubah. Oleh karena itu, tren saat ini adalah untuk mengotomatisasi pengujian.
Untuk memiliki suite tes dieksekusi secara otomatis, kitamembutuhkan kerangka di mana masukan uji dapat didefinisikan, input didefinisikan dapat digunakan oleh fungsi mewakili uji kasus, tes script otomatis dapat ditulis, SUT dapat dieksekusi oleh script ini, dan hasil seluruh pengujian dilaporkan tester. Banyak kerangka pengujian sekarang ada yang izin semua ini harus dilakukan dengan cara yang sederhana. Sebuah kerangka pengujian juga kadang-kadang disebut memanfaatkan tes. Sebuah memanfaatkan tes atau kerangka tes membuat kehidupan seorang tester sederhana dengan menyediakan cara mudah mendefinisikan test suite, dijalankan, dan pelaporan hasil. Dengan kerangka tes, tes suite didefinisikan sekali, dan kemudian setiap kali diperlukan, pengujian lengkap dapat dilakukan dengan klik tombol atau memberikan perintah.

8.1.3 Psikologi Pengujian
Sebuah tujuan dasar pengujian adalah untuk mendeteksi kesalahan yang mungkin dalam program. Oleh karena itu, seseorang tidak harus memulai pengujian dengan maksud menunjukkan bahwa program bekerja, bukan maksud harus menunjukkan bahwa program tidak bekerja, untuk mengungkapkan cacat yang mungkin ada. Karena ini, pengujian juga telah didefinisikan sebagai proses eksekusi program dengan maksud menemukan kesalahan.
Jadi, tujuannya adalah untuk menunjukkan program kerjanya, kita secara sadar atau tidak sadar pilih uji kasus yang mencoba untuk menunjukkan tujuan itu dan yang mengalahkan tujuan dasar pengujian. Di sisi lain, jika tujuannya untuk menunjukkan bahwa program ini tidak bekerja, kami akan menantang akal kita untuk menemukan kasus uji untuk mencapai tujuan itu, dan kita cenderung untuk mendeteksi lebih banyak kesalahan. Pengujian pada dasarnya adalah sebuah proses yang merusak, di mana tester harus memperlakukan program sebagai musuh yang harus dikalahkan oleh tester dengan menunjukkan adanya kesalahan. Ini adalah salah satu alasan mengapa banyak organisasi mempekerjakan pengujian independen di mana pengujian dilakukan oleh tim yang tidak terlibat dalam membangun sistem.
8.1.4 Level Pengujian
Tingkat dasar unit testing, pengujian integrasi, pengujian sistem, dan pengujian penerimaan. tingkat di ff erent ini pengujian upaya untuk mendeteksi jenis di ff erent dari kesalahan. Hubungan antara kesalahan diperkenalkan secara bertahap, dan di tingkatpengujian ditunjukkan pada Gambar 8.1.
Unit pengujian pada dasarnya untuk verifikasi kode yang dihasilkan oleh programmer individu, dan biasanya dilakukan oleh programmer dari modul. Umumnya, modul programmer untuk integrasi dan digunakan orang lain setelah telah unit diuji memuaskan.
Tingkat berikutnya pengujian disebut pengujian integrasi. Dalam hal ini, banyak unit modul diuji digabungkan menjadi subsistem, yang kemudian diuji. Tujuannya adalah untuk melihat apakah modul dapat diintegrasikan dengan benar.

Tingkat berikutnya adalah pengujian sistem dan pengujian penerimaan. Berikut seluruh sistem perangkat lunak diuji. Dokumen acuan proses ini adalah dokumen persyaratan, dan tujuannya adalah untuk melihat apakah perangkat lunak memenuhi nya.
Tingkat ini pengujian dilakukan ketika sistem sedang dibangun dari komponen yang telah dikodekan. Ada lagi tingkat pengujian, yang disebut pengujian regresi, yang dilakukan ketika beberapa perubahan yang dibuat untuk sistem yang ada.
Untuk pengujian regresi, beberapa kasus uji yang telah dijalankan pada sistem yang lama dipertahankan, bersama dengan output yang dihasilkan oleh sistem yang lama. uji kasus ini dijalankan lagi pada sistem dimodifikasi dan output dibandingkan dengan output sebelumnya untuk memastikan bahwa sistem ini bekerja seperti sebelumnya pada uji kasus ini. Hal ini sering merupakan tugas besar ketika modifikasi yang dibuat untuk sistem yang ada.

8.2 Proses Pengujian

Tujuan dasar dari proses pengembangan perangkat lunak adalah untuk menghasilkan perangkat lunak yang tidak memiliki kesalahan atau sangat sedikit kesalahan. Pengujian adalah kegiatan pengendalian kualitas yang berfokus pada identifikasi cacat (yang kemudian dihapus). Kita telah melihat bahwa tingkat pengujian cacat disuntikkan untuk mendeteksi selama berbagai tugas dalam proyek.

8.2.1 Uji Rencana
Secara umum, dalam sebuah proyek, pengujian dimulai dengan rencana uji dan berakhir dengan keberhasilan pelaksanaan pengujian penerimaan. Sebuah uji rencana adalah dokumen umum untuk seluruh proyek yang mendefinisikan ruang lingkup, pendekatan yang akan diambil, dan jadwal pengujian, serta mengidentifikasi item tes untuk pengujian dan personil yang bertanggung jawab untuk kegiatan pengujian. Rencana pengujian dapat dilakukan dengan baik sebelum pengujian yang sebenarnya dimulai dan dapat dilakukan di par-alel dengan kegiatan coding dan desain. Input untuk membentuk rencana uji adalah: (1) rencana proyek, (2) dokumen persyaratan, dan (3) arsitektur ataudokumen desain.
Dokumen persyaratan dan dokumen desain adalah dokumen-dokumen dasar yang digunakan untuk memilih unit tes dan decid-ing pendekatan yang akan digunakan selama pengujian. Sebuah rencana uji harus berisi sebagai berikut:



- Uji Spesifikasi Unit
- Fitur yang akan diuji
- Pendekatan untuk pengujian
- Kiriman Uji
- Jadwal dan tugas alokasi
Fitur yang akan diuji mencakup semua fitur perangkat lunak dan kombinasi yang harus diuji. Sebuah fitur software adalah karakteristik software tersirat oleh persyaratan atau dokumen desain. Termasuk fungsi, kinerja, kendala desain, dan atribut.
Rencana uji biasanya juga menentukan jadwal dan e ff ortir akan dihabiskan untuk di kegiatan ff erent pengujian, dan alat-alat yang akan digunakan. Jadwal ini harus konsisten dengan jadwal proyek secara keseluruhan. Rencana rinci dapat daftar semua tugas pengujian dan
mengalokasikan mereka untuk menguji sumber daya yang bertanggung jawab untuk melakukan mereka. Banyak produk besar memiliki tim pengujian terpisah dan karena rencana tes terpisah. Sebuah proyek yang lebih kecil mungkin termasuk rencana uji sebagai bagian dari rencana kualitas dalam rencana manajemen proyek.

8.2.2 Desain Kasus Uji
Rencana uji berfokus pada bagaimana proyek pengujian tersebutdilanjutkan, unit akan diuji, dan pendekatan (alat) yang digunakan selama berbagai tahap pengujian. Namun, itu tidak berurusan dengan rincian pengujian unit, juga tidak menentukan uji kasus yang akan digunakan.
Desain kasus uji harus dilakukan secara terpisah untuk masing-masing unit. Berdasarkan pendekatan yang ditentukan dalam rencana uji, dan fitur yang akan diuji, kasus uji
dirancang dan ditetapkan untuk menguji unit.

8.2.3 Uji Kasus Eksekusi
Dengan spesifikasi kasus uji, langkah berikutnya dalam proses pengujian adalah untukmengeksekusi mereka. Langkah ini juga tidak mudah. Spesifikasi kasus ujihanya menentukan set kasus uji untuk unit yang akan diuji. Namun, mengeksekusiuji kasus mungkin memerlukan pembangunan modul driver atau bertopik. Mungkin jugamembutuhkan modul untuk mengatur lingkungan sebagaimana tercantum dalam rencana uji dan ujispesifikasi kasus.
Hanya setelah semua iniuji kasus dieksekusi. Jika kerangka uji yang digunakan, maka pengaturan lingkungan sebagaiserta masukan untuk kasus uji dilakukan di skrip pengujian, dan eksekusisangat mudah.Selama tes eksekusi kasus, cacat yang ditemukan. Cacat kemudian diperbaikidan tesing dilakukan lagi untuk memverifikasi perbaikan. Untuk memfasilitasi pelaporan dan pelacakan.


8.3 Pengujian Black-Box
Tujuannya uji coba SUT adalah untuk mendeteksi sebagian besar (mudah-mudahan semua) dari cacat,melalui sekecil serangkaian uji kasus mungkin. Karena tujuan dasar ini,
penting untuk memilih kasus uji dengan hati-hati-yang terbaik adalah uji kasus-kasus yang memilikiprobabilitas tinggi mendeteksi cacat, jika ada, dan juga yang eksekusiakan memberikan keyakinan bahwa tidak ada kegagalan selama pengujian menunjukkan bahwa ada beberapa(Mudah-mudahan tidak ada) cacat dalam perangkat lunak.
Ada dua pendekatan dasar untuk merancang uji kasus untuk digunakan dalampengujian: black-box dan white-box. Dalam kotak hitam pengujian strukturProgram tidak dianggap. Uji kasus diputuskan hanya berdasarkan daripersyaratan atau spesifikasi program atau modul, dan internalmodul atau program tidak dipertimbangkan untuk pemilihan kasus uji. Dalam pengujian black-box, tester hanya memasukan yangdiberikan sistem kepada keluaran sistem. Dengan kata lain, dasaruntuk memutuskan uji kasus adalah persyaratan atau spesifikasi dari sistem ataumodul. Bentuk pengujian juga disebut uji fungsional atau perilaku.Salah satu kriteria untuk menghasilkan uji kasus adalah untuk menghasilkan mereka secara acak.Strategi ini memiliki sedikit kesempatan untuk menghasilkan satu set kasus uji yangdekat optimal (yaitu, mendeteksi kesalahan maksimum dengan uji minimumkasus).


8.3.1 Equivalence Class Partisi
Pendekatan alami berikutnya adalah membagidomain input ke dalam satu set kelas kesetaraan, sehingga jika karya Programbenar bernilai, maka akanbenar bekerja untuk semua nilai-nilai lain dalamkelas. Jika memang mengidentifikasi kelas tersebut, maka pengujian program dengan satu nlai dari masing-masing kelas kesetaraan setara dengan melakukan tes lengkapprogramstruktur.
Metode kesetaraan kelas partisimencoba untuk ideal. Kelas kesetaraan terbentuk dari inputdimana perilaku sistem ditentukan atau diharapkan untuk menjadi serupa. Setiap
kelompok masukan yang perilaku tersebut diharapkan akan berbeda dari orang laindianggap sebagai kelas kesetaraan yang terpisah. Dasar pemikiran pembentukan kesetaraankelas seperti ini asumsi bahwa jika spesifikasi memerlukanperilaku sama untuk setiap elemen dalam kelas nilai-nilai, maka program akan cenderungdibangun sehingga baik berhasil atau gagal untuk masing-masing nilai di kelas itu.
Misalnya, spesifikasi modul yang menentukan nilai absolutuntuk bilangan bulat menentukan satu perilaku untuk bilangan bulat positif dan satu lagi untuk negatifbilangan bulat. Dalam hal ini, kita akan membentuk dua kesetaraan kelas-satu yang terdiri daribilangan bulat positif dan terdiri lainnya dari bilangan bulat negatif.Untuk perangkat lunak yang kuat, kita juga harus mempertimbangkan masukan tidak valid. Artinya, kita harusmendefinisikan kelas kesetaraan untuk input tidak valid juga. Kelas kesetaraan biasanya dibentuk dengan mempertimbangkan setiap kondisi yang ditentukanpada masukan sebagai menentukan kelas kesetaraan valid dan satu atau lebih validkelas kesetaraan.

8.3.2 Analisis Nilai Batas
Ia telah mengamati bahwa program yang bekerja dengan benar untuk satu set nilai-nilai dikelas kesetaraan gagal pada beberapa nilai khusus. Nilai-nilai ini sering berbaring dibatas dari kelas kesetaraan. Uji kasus yang memiliki nilai-nilai pada batas-bataskesetaraan kelas karena itu cenderung "-yield tinggi" uji kasus, danmemilih uji kasus tersebut adalah tujuan dari analisis nilai batas. dalam batasanalisis nilai, kita memilih masukan untuk kasus uji dari kesetaraan
kelas, sehingga input terletak di tepi kelas ekivalen. Batasnilai untuk setiap kelas kesetaraan, termasuk kelas ekivalen dari output,harus ditutup. batas nilai uji kasus juga disebut "kasus-kasus ekstrim."Oleh karena itu, kita dapat mengatakan bahwa kasus uji batas nilai adalah seperangkat input data yangterletak di tepi atau batas dari kelas data input atau yang menghasilkan keluaranyang terletak pada batas kelas data output.

8.3.3 Pengujian Pasangan
Ada banyak umumnya parameter yang menentukan perilaku perangkat lunak
sistem. Parameter ini bisa menjadi masukan langsung ke perangkat lunak atau implisitpengaturan seperti untuk perangkat. Parameter ini dapat mengambil nilai yang berbeda, danuntuk beberapa dari mereka perangkat lunak mungkin tidak bekerja dengan benar. Banyak cacat disoftware umumnya melibatkan satu syarat, yaitu, beberapa nilai khusus salah satu.
parameter. Cacat seperti ini disebut kesalahan single-mode. contoh sederhana kesalahan dari single-mode lunak tidak mampu mencetak jenis tertentuprinter, sebuah perangkat lunak yang tidak dapat menghitung ongkosminor, dan perangkat lunak penagihan telepon yang tidak menghitung tagihan dengan benaruntuk negara tertentu.
Kesalahan single-mode dapat dideteksi dengan menguji untuk nilai yang berbeda dari yang berbedaparameter. Jadi, jika ada n parameter untuk sistem, dan masing-masing dari
mereka dapat mengambil nilai-nilai m yang berbeda (atau m kelas yang berbeda dari nilai-nilai, masing-masing kelasyang dianggap sebagai tujuan untuk pengujian seperti di kelas kesetaraan
partisi), maka dengan setiap kasus uji kita dapat menguji satu nilai yang berbeda dari masing-masingparameter. Dengan kata lain, kita dapat menguji untuk semua nilai yang berbeda di tes mkasus.

8.3.4 Kasus Khusus
Uji kasus yang ditulis untuk situasi ini. Misalnya, dalam masalah menemukan jumlah kata yang berbeda dalam filebeberapa kasus khusus dapat: file kosong,hanya satu kata dalam file, hanya satu kata dalam satu baris, beberapa baris kosong di inputFile, kehadiran lebih dari
satu kosong antara kata-kata, semua kata yang sama,kata-kata yang sudah disortir, dan kosong di awal dan akhir file. Asumsi yang salah biasanya dibuat karena spesifikasi yang tidak
menyelesaikan atau penulis spesifikasi mungkin tidak telah menyatakan beberapa properti,
dengan asumsi mereka untuk menjadi jelas. Setiap kali ada ketergantungan pada pemahaman diam-diamdaripada pernyataan eksplisit dari spesifikasi, ada ruang untuk membuat salah
asumsi. Sering, asumsi yang salah yang dibuat tentang lingkungan.
Namun, harus dicatat bahwa kasus-kasus khusus sangat tergantung pada
masalah, dan tester harus benar-benar mencoba untuk "masuk ke sepatu" dari desainer
dan coder untuk menentukan kasus ini.


8.3.5 Pengujian Negara Berbasis
Namun demikian, banyaksistem yang perilakunya negara-berbasis di bahwa untuk masukan identik mereka berperilakuberbeda pada waktu yang berbeda dan dapat menghasilkan output yang berbeda. Alasannyauntuk perilaku yang berbeda adalah bahwa keadaan dari sistem mungkin berbeda. di lainkata-kata, perilaku dan output dari sistem tidak hanya tergantung pada inputtersedia, tetapi juga pada keadaan dari sistem. Keadaan dari sistem tergantungpada input terakhir sistem telah menerima.
Dengan kata lain, negara merupakandampak kumulatif dari semua input terakhir pada sistem. Dalam perangkat keras,sistem sekuensial jatuh dalam kategori ini. Dalam perangkat lunak, banyak sistem yang besar jatuhkategori ini sebagai negara terakhir yang ditangkap di database atau file dan digunakan untuk kontrolperilaku sistem. Untuk sistem seperti ini, pendekatan lain untuk memilihuji kasus adalah berbasis negara pendekatan pengujian [22].
Secara teoritis, perangkat lunak yang menyelamatkan negara dapat dimodelkan sebagai mesin negara.Namun, ruang keadaan dari setiap program yang wajar adalah hampir tak terbatas,
karena merupakan produk silang dari domain dari semua variabel yang membentuk negara.
Bagi banyak sistem ruang keadaan dapat dibagi menjadi beberapa negara, masing-masing
mewakili kombinasi logis dari nilai-nilai variabel negara yang berbeda yang berbagi beberapa properti yang menarik. Jika himpunan negara dari suatu sistem adalah dikelola,
model keadaan dari sistem dapat dibangun.
Sebuah model negara untuk sistem memilikiempat komponen:
- Serikat. Merupakan dampak dari input masa lalu ke sistem.
- Transisi. Mewakili bagaimana keadaan sistem berubah dari satu negara
yang lain dalam menanggapi beberapa peristiwa.
- Acara. Input ke sistem.
 - Tindakan. Output untuk acara.






8.4 Pengujian White-Box
Pengujian White-box, di sisi lain tangan, berkaitan dengan pengujian pelaksanaan program. Tujuannyapengujian ini bukan untuk melaksanakan semua input atau output kondisi yang berbeda (meskipunmerupakan produk) tapi melaksanakan pemrograman yang berbeda
struktur dan struktur data yang digunakan dalam program ini. Pengujian kotak putih juga
disebut pengujian struktural.

8.4.1 Kriteria Basis Flow Kontrol
Kriteria berbasis struktur yang paling umum didasarkan pada aliran kontrol
program. Dalam kriteria ini, grafik aliran kontrol dari program dianggap
dan cakupan berbagai aspek grafik ditetapkan sebagai kriteria. Karenanya,
sebelum kita mempertimbangkan kriteria, mari kita tepat menentukan grafik aliran kontrol untuksebuah program.Biarkan grafik kontrol aliran (atau hanya mengalir grafik) dari program P G. Anode dalam grafik ini merupakan blok pernyataan yang selalu dieksekusi
bersama-sama, yaitu, setiap kali pernyataan pertama dijalankan, semua pernyataan lain
juga dieksekusi. Tepi (i, j) (dari simpul i ke simpul j) merupakan kemungkinan
transfer kontrol setelah mengeksekusi pernyataan terakhir dari blok diwakili
oleh simpul i ke pernyataan pertama dari blok yang diwakili oleh simpul j. Sebuah node
sesuai dengan blok yang pernyataan pertama adalah pernyataan awal P adalah
disebut node awal G, dan node sesuai dengan blok yang lalu
Pernyataan adalah pernyataan keluar disebut node keluar [73]. Sebuah jalan adalah terbatas
urutan node (n1, n2, ..., nk), k> 1, sehingga ada tepi (ni, ni + 1)
untuk semua node ni dalam urutan (kecuali node nk terakhir).

8.4.2 Uji Generation Kasus dan Dukungan Perangkat
Setelah kriteria cakupan diputuskan, dua masalah harus dipecahkan untuk menggunakankriteria yang dipilih untuk pengujian. Yang pertama adalah untuk memutuskan apakah satu set kasus uji memuaskankriteria, dan yang kedua adalah untuk menghasilkan satu set kasus uji untuk kriteria tertentu.Memutuskan apakah satu set kasus uji memenuhi kriteria
tanpa bantuan apapunalat adalah tugas yang rumit, meskipun secara teoritis mungkin untuk melakukan secara manual.Untuk hampir semua teknik pengujian struktural, alat yang digunakan untuk menentukanapakah kriteria tersebut telah puas. Umumnya, alat ini akan memberikanumpan balik mengenai apa yang perlu diuji untuk sepenuhnya memenuhi kriteria.
Untuk menghasilkan uji kasus, alat-alat yang tidak mudah tersedia, dan karena
sifat dari masalah (yaitu, undecidability dari "kelayakan" dari jalan), sepenuhnya
alat otomatis untuk memilih uji kasus untuk memenuhi kriteria umumnya tidak
mungkin. Oleh karena itu, alat bisa, di terbaik, membantu tester. Salah satu metode untuk menghasilkanuji kasus adalah untuk secara acak memilih data uji sampai kriteria yang diinginkan puas(Yang ditentukan oleh alat). Hal ini dapat mengakibatkan banyak berlebihan uji kasus,karena banyak kasus uji akan melaksanakan jalur yang sama.

8.5 Metrik
Kita telah melihat bahwa selama pengujian perangkat lunak yang uji dijalankan dengan set
kasus uji. Sebagai kualitas perangkat lunak yang dikirimkan tergantung substansial pada
kualitas pengujian, sebuah pertanyaan alami beberapa muncul saat uji coba:
- Seberapa baik adalah pengujian yang telah dilakukan?
- Bagaimana kualitas atau keandalan software setelah pengujian selesai?
Selama pengujian, tujuan utama dari metrik adalah mencoba untuk menjawab ini dan
pertanyaan terkait lainnya. Kita akan membahas beberapa metrik yang dapat digunakan untuktujuan.

8.5.1 Analisis Cakupan
Salah satu pendekatan yang paling umum digunakan untuk mengevaluasi ketelitian yang
pengujian adalah dengan menggunakan beberapa langkah cakupan. Kami telah dibahas di atas beberapalangkah-langkah cakupan umum yang digunakan dalam cakupan praktek-pernyataan
dan cakupan cabang. Untuk menggunakan langkah-langkah cakupan ini untuk mengevaluasi kualitaspengujian, alat analisis cakupan yang tepat harus digunakan yang dapat
menginformasikan tidak hanya cakupan dicapai selama pengujian tetapi juga yang bagian
belum tercakup.
Cakupan ukuran di sini adalah persentase persyaratan atau klausa mereka / -
kondisi yang setidaknya satu kasus uji ada. Seringkali cakupan penuh mungkin
diperlukan pada tingkat kebutuhan sebelum pengujian dianggap sebagai diterima.

8.5.2 Keandalan
Sebagai keandalan software tergantungjauh pada kualitas pengujian, dengan menilai kehandalan kami juga dapat menilaikualitas pengujian. Atau, estimasi reliabilitas dapat digunakan untuk memutuskanapakah pengujian cukup telah dilakukan.
Dengan kata lain, selain karakteristikproperti kualitas penting dari produk yang disampaikan, kehandalan estimasimemiliki peran langsung dalam proyek manajemen-dapat digunakan oleh proyekManajer untuk memutuskan apakah pengujian cukup telah dilakukan dan kapan harus berhentipengujian.Keandalan produk menentukan kemungkinan operasi kegagalan-bebasbahwa produk untuk durasi waktu tertentu. Kebanyakan model kehandalan mengharuskanterjadinya kegagalan menjadi fenomena acak.

8.5.3 Cacat Removal Efficiency
Analisis lain yang menarik adalah efisiensi removal cacat, meskipun ini hanya dapat
ditentukan beberapa saat setelah perangkat lunak telah dirilis. Tujuan dari ini
analisis adalah untuk mengevaluasi efektivitas proses pengujian yang digunakan,
bukan kualitas pengujian untuk sebuah proyek. Analisis ini berguna untuk meningkatkan
proses pengujian di masa depan.
Ini jelas bahwa DRE adalah konsep umum yang dapat diterapkan untuk
aktivitas penghapusan cacat. Sebagai contoh, kita dapat menghitung DRE desain
review, atau unit testing. Hal ini dapat dilakukan jika setiap cacat, selain logging saat
dan di mana cacat ditemukan, fase di mana cacat diperkenalkanjuga dianalisis dan dicatat. Dengan informasi ini, ketika semua cacat yanglogin, DRE tugas kontrol kualitas utama dapat ditentukan. Informasi ini sangat berguna dalam meningkatkan kualitas proses keseluruhan.

8.6 Ringkasan

· Pengujian adalah metode yang dinamis untuk verifikasi dan validasi, di mana perangkat lunakuntuk diuji dilaksanakan dengan hati-hati dirancang kasus uji danperilaku sistem software diamati. Sebuah test case adalah seperangkat inputdan kondisi pengujian bersama dengan hasil yang diharapkan dari pengujian. Sebuah test suiteadalahseperangkat kasus uji yang umumnya dijalankan bersama-sama untuk menguji beberapa spesifiktingkah laku. Selama pengujian hanya kegagalan sistem yang diamati,dari mana kehadiran kesalahan disimpulkan; kegiatan yang terpisah harusdilakukan untuk mengidentifikasi kesalahan dan menghapus mereka.
· Tujuan dari pengujian adalah untuk meningkatkan kepercayaan dalam kebenaran perangkat lunak.Untuk ini, himpunan kasus uji yang digunakan untuk pengujian harus sedemikian rupa sehingga untukcacat pada sistem, ada kemungkinan menjadi kasus uji yang akan mengungkapkannya.Untuk memastikan hal ini, penting bahwa uji kasus secara hati-hati dirancang denganmaksud mengungkapkan cacat.
· Karena keterbatasan metode verifikasi untuk tahap awal, desaindan kesalahan persyaratan juga muncul dalam kode. Pengujian ini digunakan untuk mendeteksikesalahan ini juga, selain kesalahan diperkenalkan selama codingtahap. Oleh karena itu, berbagai tingkat pengujian yang sering digunakan untuk mendeteksi cacatdisuntikkan selama tahap-tahap yang berbeda. Tingkat pengujian umum digunakan adalahunit testing, pengujian integrasi, pengujian sistem, dan pengujian penerimaan.
· Untuk menguji produk software, pengujian secara keseluruhan harus direncanakan, dan untukmenguji setiap unit diidentifikasi dalam rencana, uji kasus harus dirancang dengan hati-hatiuntuk mengungkapkan kesalahan dan ditetapkan dalam dokumen atau naskah tes.Ada dua pendekatan untuk merancang uji kasus: kotak hitam dan putih-kotak.Dalam pengujian black-box, logika internal dari sistem di bawah pengujian tidak dianggapdan uji kasus diputuskan dari spesifikasi atau persyaratan.Kesetaraan kelas partisi, analisis nilai batas, dan causeeffectgrafik adalah contoh dari metode untuk memilih kasus uji untuk kotak hitampengujian. pengujian berbasis negara adalah pendekatan lain di mana sistem dimodelkansebagai mesin negara dan kemudian model ini digunakan untuk memilih uji kasus menggunakanbeberapa transisi atau kriteria cakupan berbasis jalan. pengujian berbasis negara juga bisadipandang sebagai abu-abu kotak pengujian dalam yang sering membutuhkan informasi lebih darihanya persyaratan.
· Dalam pengujian white-box, uji kasus diputuskan berdasarkan logika internaldari program yang sedang diuji. Seringkali kriteria yang ditentukan, tetapi proseduruntuk memilih uji kasus untuk memenuhi kriteria yang tersisa untuk tester. Yang palingKriteria umum adalah cakupan pernyataan dan cakupan cabang.
· Metrik utama bunga selama pengujian adalah keandalan dari perangkat lunak di bawah pengujian. Jika cacat sedang login, keandalan dapat dinilai dalam haldari tingkat kegagalan per minggu atau hari, meskipun model yang lebih baik untuk estimasi ada.Cakupan dicapai selama pengujian, dan efisiensi removal cacat, yang lainnyametrik bunga.

CODING AND UNIT TESTING

NAMA       : ANNISA APRILYA
NPM           : 43A87007150346
KELAS       : S1/SI/3B/P

BAB 7

CODING DAN PENGUJIAN UNIT

Tujuan dari coding atau pemrograman kegiatan adalah untuk menerapkan desain dengan cara terbaik mungkin. Aktivitas coding mempengaruhi baik pengujian dan pemeliharaan mendalam. Seperti membaca program adalah kegiatan jauh lebih umum daripada menulis program, tujuan dari kegiatan coding adalah untuk menghasilkan program yang, selain bebas dari cacat, mudah untuk memahami dan memodifikasi.

7.1 Pemrograman Prinsip dan Pedoman
Tugas utama sebelum programmer untuk menulis kode yang dapat dibaca dengan beberapa kesalahan di dalamnya. Sebuah gol tambahan adalah untuk menulis kode cepat. Menulis kode padat adalah keterampilan yang hanya dapat diperoleh dengan praktek. Namun, berdasarkan pengalaman, beberapa aturan umum dan pedoman dapat diberikan untuk programmer. pemrograman yang baik (Memproduksi program yang benar dan sederhana) adalah independen praktek target bahasa pemrograman, meskipun bahasa pemrograman yang terstruktur dengan baik membuat pekerjaan programmer sederhana. Pada bagian ini, kita akan membahas beberapa konsep dan praktek yang dapat membantu programmer menulis kode berkualitas tinggi yang juga lebih mudah untuk dipahami.


7.1.1 Pemrograman Terstruktur
Seperti yang dinyatakan sebelumnya tujuan dasar dari kegiatan coding adalah untuk menghasilkan pro-gram yang mudah dimengerti. Telah dikemukakan oleh banyak bahwa praktek pemrograman terstruktur membantu mengembangkan program yang lebih mudah untuk dipahami. Gerakan pemrograman terstruktur dimulai pada tahun 1970-an, dan banyak yang telah dikatakan dan ditulis tentang hal itu. Meskipun ekstensif menggunakan gotos tentu tidak diinginkan, program terstruktur dapat ditulis dengan menggunakan gotos. Berikut kami berikan diskusi singkat tentang apa pemrograman terstruktur adalah.


Sebuah program memiliki struktur statis serta struktur yang dinamis. Struktur statis adalah struktur teks dari program, yang hanya orga-nization linear laporan program. Struktur dinamis dari program ini adalah urutan pernyataan dijalankan selama pelaksanaan program. Dengan kata lain, baik struktur statis dan perilaku dinamis adalah urutan laporan; sedangkan urutan mewakili struktur statis dari sebuah program adalah tetap, urutan laporan dijalankan dapat berubah dari eksekusi eksekusi.
Ini jelas akan lebih mudah untuk memahami perilaku dinamis jika struktur dalam perilaku dinamis menyerupai struktur statis. Semakin dekat persesuaian antara pelaksanaan dan struktur teks, semakin mudah program ini adalah untuk memahami, dan lebih dipahami struktur selama eksekusi, semakin sulit akan berdebat tentang perilaku dari teks program. Tujuan dari pemrograman terstruktur adalah untuk memastikan bahwa struktur statis dan struktur dinamis adalah sama. Artinya, tujuan dari pemrograman terstruktur adalah menulis program sehingga urutan laporan dijalankan selama mantan ecution dari sebuah program adalah sama dengan urutan pernyataan dalam teks program itu. Seperti pernyataan dalam teks program yang diselenggarakan secara linear, tujuan dari pemrograman terstruktur menjadi mengembangkan program yang kontrol aliran selama eksekusi adalah linier dan mengikuti organisasi linear dari teks program.
Menggunakan notasi Hoare ini , untuk memverifikasi program, pernyataan dasar tentang segmen program ini dalam bentuk
         P {S}Q.
Penafsiran ini adalah bahwa jika pernyataan P benar sebelum mengeksekusi S, maka pernyataan Q akan menjadi kenyataan setelah melaksanakan S, jika eksekusi S berakhir. Sikap tegas P adalah pra-kondisi program dan Q adalah pasca-kondisi. pernyataan ini adalah tentang nilai-nilai yang diambil oleh variabel dalam program sebelum dan setelah pelaksanaannya. Pernyataan umumnya tidak menentukan nilai nominal tertentu untuk variabel, tetapi mereka menentukan sifat umum dari nilai-nilai dan hubungan di antara mereka.
Gunakan pemrograman terstruktur di mana program ini adalah urutan yang sesuai single-entry konstruksi single-exit membuat program yang mudah untuk memahami dan memverifikasi. praktek-praktek lainnya seperti menggunakan menyembunyikan informasi, cocok coding stan-dards, dan praktek pemrograman yang baik juga membantu meningkatkan pembacaan kode dan kualitas. Tujuan dasar menggunakan konstruksi terstruktur adalah untuk linearize aliran kontrol sehingga perilaku eksekusi lebih mudah untuk di bawah-berdiri dan berdebat tentang. Dalam aliran kontrol linier, jika kita memahami perilaku masing-masing konstruksi dasar benar, perilaku program dapat dianggap sebagai komposisi perilaku dari laporan. Untuk pendekatan ini untuk bekerja, itu tersirat bahwa kita dapat dengan jelas memahami dan menentukan perilaku setiap konstruk.

Titik utama adalah bahwa setiap konstruk tidak terstruktur harus digunakan hanya jika alternatif terstruktur lebih sulit untuk memahami. Pandangan ini dapat diambil hanya karena kita berfokus pada pembacaan. Jika tujuannya adalah pemastian formal, pemrograman terstruktur mungkin akan diperlukan.

7.1.2 Informasi Menyembunyikan
Sebuah solusi perangkat lunak untuk masalah selalu berisi struktur data yang dimaksudkan untuk mewakili informasi dalam domain masalah. Artinya, ketika perangkat lunak dikembangkan untuk memecahkan masalah, perangkat lunak menggunakan beberapa struktur data untuk menangkap informasi dalam domain masalah.
Secara umum, hanya operasi tertentu dilakukan pada beberapa informasi. Artinya, sepotong informasi dalam masalah domain hanya digunakan dalam sejumlah cara dalam domain masalah. Sebagai contoh, sebuah buku besar di akuntan memiliki beberapa kegunaan yang sangat jelas: debit, kredit, memeriksa saldo, dll Sebuah operasi di mana semua debet dikalikan bersama-sama dan kemudian dibagi dengan jumlah semua kredit biasanya tidak dilakukan.
Ketika informasi tersebut direpresentasikan sebagai struktur data, prinsip yang sama harus diterapkan, dan hanya beberapa operasi yang didefinisikan harus dilakukan pada struktur data. Ini, pada dasarnya, adalah prinsip bersembunyi informasi. Informasi yang ditangkap dalam struktur data harus disembunyikan dari sisa dari sistem, dan hanya akses fungsi pada struktur data yang mewakili operasi yang dilakukan pada informasi yang harus terlihat. Dengan kata lain, ketika informasi tersebut ditangkap di struktur data dan kemudian pada struktur data yang mewakili beberapa informasi, untuk setiap operasi pada informasi fungsi akses harus disediakan.
Untuk pengembang, hal ini sangat efektif untuk mengembangkan kode secara bertahap. Hal ini dapat dilakukan dengan menulis kode sedikit demi sedikit, dan pengujian dan debugging setiap kenaikan sebelum menulis kode lebih. Atau, pengembangan uji-driven dapat diikuti di mana uji kasus yang ditulis pertama dan kemudian kode ditulis untuk lulus uji kasus ini. Meskipun coding dari modul umumnya dilakukan oleh programmer individu, alternatif adalah pasangan pemrograman, di mana coding dilakukan oleh sepasang programmer-baik strategi bersama-sama berkembang, struktur data, algoritma dll.

7.1.3 Beberapa Praktek Pemrograman
Konsep yang dibahas di atas dapat membantu dalam menulis kode sederhana dan jelas dengan beberapa bug. Ada banyak praktek pemrograman yang juga dapat membantu ke arah tujuan itu. Kita bahas di sini beberapa aturan yang telah ditemukan untuk membuat kode lebih mudah dibaca serta menghindari beberapa kesalahan.
Informasi Menyembunyikan: Seperti telah dibahas sebelumnya, informasi bersembunyi harus didukung mana mungkin. Hanya fungsi akses untuk struktur data harus dibuat terlihat saat bersembunyi struktur data di balik fungsi tersebut.
Jenis Buatan Pengguna: bahasa modern memungkinkan pengguna untuk menentukan jenis seperti tipe enumerasi. Ketika fasilitas tersebut tersedia, mereka harus ex-ploited mana yang berlaku.
Nesting: Jika bersarang jika-maka-lain konstruksi menjadi terlalu dalam, maka logika menjadi sulit untuk memahami.
Modul Ukuran: Kami membahas masalah ini selama desain sistem. Seorang programmer harus hati-hati memeriksa setiap fungsi dengan terlalu banyak laporan (mengatakan lebih dari 100). modul besar sering tidak akan fungsional kohesif. Tidak ada aturan keras-dan-cepat tentang ukuran modul; prinsip harus kohesi dan kopling.
Modul Interface: Sebuah modul dengan antarmuka yang kompleks harus diteliti dengan seksama. Sebagai aturan praktis, setiap modul yang antarmuka memiliki lebih dari lima parameter harus diteliti dengan seksama dan patah menjadi beberapa modul dengan antarmuka sederhana jika mungkin.
Kode Berkembang perlu dikelola dengan baik. Hal ini dapat dilakukan melalui kontrol alat kode sumber yang tepat yang memungkinkan manajemen mudah dari versi berbeda yang bisa dibuat, serta mudah kehancuran perubahan yang perlu digulung kembali.

7.1.4 Standar Coding
Secara umum, standar coding memberikan pedoman bagi programmer mengenai
penamaan, organisasi berkas, pernyataan dan deklarasi, dan tata letak dan komentar. Untuk memberikan gambaran tentang standar pengkodean (sering disebut konvensi atau gaya
pedoman), kita membahas beberapa panduan untuk Java, berdasarkan tersedia untuk umum standar (dari www.geosoft.no atau java.sun.com/docs).
Mengomentari dan Layout Komentar adalah pernyataan tekstual yang dimaksudkan
untuk program pembaca untuk membantu pemahaman kode. Tujuan dari komentar tidak menjelaskan dalam bahasa Inggris logika program-jika logika begitu kompleks yang memerlukan komentar untuk menjelaskannya, lebih baik untuk menulis ulang dan
menyederhanakan kode sebaliknya.
Secara umum, komentar harus menjelaskan apa kode melakukan atau mengapa kode yang ada, sehingga kode dapat menjadi hampir-standar dalone untuk memahami sistem. Komentar umumnya harus disediakan untuk blok kode, dan dalam banyak kasus, hanya komentar untuk modul perlu disediakan.

Menyediakan komentar untuk modul yang paling berguna, sebagai modul membentuk unit
pengujian, kompilasi, verifikasi, dan modifikasi. Komentar untuk modul yang sering disebut prolog untuk modul, yang menggambarkan fungsi dan Tujuan dari modul, antarmuka publik dan bagaimana modul yang akan digunakan, parameter antarmuka, asumsi itu membuat tentang parameter, dan efek samping itu. Fitur lain dapat juga dimasukkan. Perlu dicatat bahwa prolog berguna hanya jika mereka tetap konsisten dengan logika modul. Jika modul tersebut dimodifikasi, maka prolog juga harus diubah jika diperlukan.
Java menyediakan komentar dokumentasi yang dibatasi oleh "/ ** ... * /", dan yang bisa diambil ke file HTML. Komentar ini sebagian besar digunakan sebagai prolog untuk kelas dan metode-metode dan bidang, dan dimaksudkan untuk memberikan dokumentasi untuk pengguna kelas yang mungkin tidak memiliki akses ke sumber kode. Selain prolog untuk modul, standar pengkodean dapat menentukan bagaimana dan di mana komentar harus berada. Beberapa pedoman tersebut adalah:
- Satu baris komentar untuk blok kode harus sejajar dengan kode mereka dimaksudkan untuk.
- Harus ada komentar untuk semua variabel utama menjelaskan apa yang mereka wakili.
- Sebuah blok komentar harus didahului oleh kosong baris komentar hanya dengan "/ *" dan diakhiri dengan baris yang berisi hanya "* /".
- Trailing komentar setelah laporan harus singkat, pada baris yang sama, dan bergeser cukup jauh untuk memisahkan mereka dari laporan.
Pedoman tata letak fokus pada bagaimana program harus menjorok, bagaimana seharusnya menggunakan baris kosong, ruang putih, dll, untuk membuatnya lebih mudah dibaca. Lekukan
pedoman kadang-kadang disediakan untuk setiap jenis pemrograman membangun.
Namun, kebanyakan programmer belajar ini dengan melihat kode dari orang lain dan
Kode fragmen dalam buku-buku dan dokumen, dan banyak dari ini telah menjadi cukup
standar selama bertahun-tahun. Kita tidak akan membahas mereka lebih jauh kecuali untuk mengatakan bahwa programmer harus menggunakan beberapa konvensi, dan menggunakannya secara konsisten.

7.2 Bertahap Mengembangkan Kode
Aktivitas coding dimulai ketika beberapa bentuk desain yang telah dilakukan dan spesifikasi dari modul untuk dikembangkan tersedia. Dengan desain, modul ditugaskan untuk pengembang untuk coding. Ketika modul ditugaskan untuk pengembang, mereka menggunakan beberapa proses untuk mengembangkan kode.

7.2.1 Sebuah Incremental Coding Proses
Proses diikuti oleh banyak pengembang untuk menulis kode untuk modul yang saat ini ditetapkan, dan ketika dilakukan, melakukan unit testing di atasnya dan memperbaiki bug yang ditemukan. Maka kode tersebut akan diperiksa dalam repositori proyek untuk membuatnya tersedia untuk orang lain dalam proyek tersebut. (Kami akan menjelaskan proses memeriksa kemudian.)
Sebuah proses yang lebih baik untuk coding, yang sering diikuti oleh berpengalaman pengembang, adalah untuk mengembangkan kode secara bertahap. Artinya, menulis kode untuk im-plementing hanya bagian dari fungsi modul. Kode ini disusun dan diuji dengan beberapa tes cepat untuk memeriksa kode yang telah ditulis sejauh ini. Ketika kode melewati tes ini, pengembang hasil untuk menambah fungsionalitas lebih lanjut untuk kode, yang kemudian diuji lagi.

7.2.2 Uji-Driven Development
Test-Driven Development (TDD) adalah proses coding yang berbalik pendekatan umum untuk coding. Alih-alih menulis kode dan kemudian mengembangkan kasus uji untuk memeriksa kode, di TDD itu adalah sebaliknya-programmer pertama menulis skrip tes, dan kemudian menulis kode untuk lulus tes. Seluruh proses dilakukan secara bertahap, dengan tes yang ditulis berdasarkan spesifikasi dan kode yang ditulis untuk lulus tes.
Beberapa poin yang perlu diperhatikan tentang TDD. Pertama, pendekatan mengatakan bahwa Anda menulis kode hanya cukup untuk lulus tes. Dengan mengikuti ini, kode ini selalu sinkron dengan tes. Hal ini tidak selalu terjadi dengan pendekatan kode-pertama, di mana itu semua terlalu umum untuk menulis sepotong panjang kode, tapi kemudian hanya menulis beberapa tes yang hanya mencakup beberapa bagian kode.


Tulisan ini kasus uji sebelum kode ditulis membuat pengembangan penggunaan-driven. Sejak kasus uji harus tertulis pertama dari spesifikasi, bagaimana kode tersebut akan digunakan mendapat perhatian pertama. Ini akan membantu memastikan bahwa interface dari perspektif pengguna kode dan skenario penggunaan kunci. Hal ini dapat membantu mengurangi kesalahan antarmuka.
Dalam TDD, beberapa jenis prioritas untuk pengembangan kode alami hap-pena. Hal ini kemungkinan besar bahwa beberapa tes pertama cenderung fokus pada menggunakan fungsi utama. Umumnya, kasus uji untuk fitur-prioritas yang lebih rendah atau func-tionality akan dikembangkan kemudian.

7.2.3 Pair Programming
Pair programming juga merupakan proses coding yang telah diusulkan sebagai metodologi kunci tech-nique dalam pemrograman ekstrim (XP) [7]. Dalam pemrograman pasangan, kode tidak ditulis oleh programmer individu tetapi oleh sepasang programmer. Artinya, pekerjaan coding ditugaskan untuk tidak individu tetapi untuk sepasang individu. Pasangan ini bersama-sama menulis kode.
Proses dipertimbangkan adalah bahwa satu orang akan ketik program sementara yang lain akan secara aktif berpartisipasi dan terus-menerus meninjau apa yang sedang diketik. Ketika kesalahan perhatikan, mereka menunjukkan dan diperbaiki. Jika diperlukan, pasangan membahas algoritma, struktur data, atau strategi yang akan digunakan dalam kode yang akan ditulis. Peran yang diputar sering membuat kedua pasangan sama dan memiliki peran yang sama.

7.3 Mengelola Berkembang Kode
Selama proses coding, kode yang ditulis oleh programmer (atau sepasang) berevolusi-mulai dari nol untuk akhirnya memiliki modul teruji. Selama proses ini kode mengalami perubahan. Selain perubahan karena proses pembangunan, perubahan kode juga dibutuhkan karena perubahan spesifikasi modul, yang mungkin terjadi karena perubahan persyaratan. Sedemikian skenario dinamis, mengelola kode berkembang adalah sebuah tantangan. Di sini kita membahas dua aspek ini-bagaimana mengelola perbedaaan versi yang bisa dibuat, dan bagaimana mempertahankan kualitas kode di bawah perubahan.

7.3.1 Source Code Control dan Build
Dalam proyek banyak beberapa orang mengembangkan kode sumber. Setiap programmer membuat file sumber, yang akhirnya digabungkan bersama-sama untuk menciptakan executable. Programmer terus berubah file sumber mereka sebagai kode berevolusi, seperti yang kita lihat dalam proses dibahas di atas, dan sering membuat perubahan dalam file sumber lain juga. Dalam rangka menjaga kontrol atas sumber dan evolusi mereka, kontrol kode sumber hampir selalu digunakan dalam proyek-proyek menggunakan alat seperti CVS pada UNIX (www.cvshome.org) atau sumber visual aman (VSS) pada Windows (msdn.microsoft.com / VStudio / sebelumnya / ssafe). Di sini kita memberikan penjelasan singkat tentang bagaimana alat ini digunakan dalam proses coding. Diskusi kita didasarkan pada CVS.
Sebuah sistem kontrol sumber kode yang modern berisi repositori, yang essen-tially struktur direktori dikontrol, yang membuat sejarah revisi penuh dari semua file yang dihasilkan oleh programmer didalam tim proyek. Untuk e FFI efisiensi, sejarah berkas umumnya disimpan sebagai delta atau increment dari file base. Hal ini memungkinkan setiap versi lama dari file yang akan dibuat ulang, sehingga memberikan fleksibilitas untuk dengan mudah membuang perubahan, harus perlu timbul. repositori adalah juga "o FFI resmi" sumber untuk semua file.

7.3.2 Refactoring
Refactoring adalah teknik untuk meningkatkan kode yang ada dan mencegah kerusakan desain ini dengan waktu. Refactoring adalah bagian dari coding di bahwa itu dilakukan selama masa coding, tetapi tidak coding biasa. Refactoring telah dipraktekkan di masa lalu oleh programmer, tetapi baru-baru ini telah mengambil bentuk yang lebih konkrit, dan telah diusulkan sebagai langkah kunci dalam praktek XP. Refactoring juga memainkan peran penting dalam test-driven development-kode perbaikan langkah dalam proses TDD benar-benar melakukan refactoring.
Refactoring didefinisikan sebagai perubahan yang dibuat dengan struktur internal perangkat lunak untuk membuatnya lebih mudah untuk memahami dan lebih murah untuk memodifikasi tanpa mengubah perilaku yang dapat diamati yang titik kunci di sini adalah bahwa perubahan sedang dibuat dengan desain yang terkandung dalam kode sumber (yaitu, struktur internal) secara eksklusif untuk tujuan perbaikan.

Tujuan dasar dari refactoring adalah untuk memperbaiki desain. Namun, perlu diketahui bahwa ini bukan tentang meningkatkan desain selama tahap desain untuk menciptakan desain yang akan kemudian dilaksanakan (yang merupakan fokus dari desain metode-ologies), tetapi tentang meningkatkan desain kode yang sudah ada. Dengan kata lain, refactoring, meskipun dilakukan pada kode sumber, memiliki tujuan untuk meningkatkan desain yang kode mengimplementasikan. Oleh karena itu, prinsip-prinsip dasar desain memandu proses refactoring. Akibatnya, refactoring umumnya menghasilkan satu atau lebih hal berikut:

1. Mengurangi kopling
2. kohesi Peningkatan
3. kepatuhan yang lebih baik untuk membuka-menutup prinsip

Kapan refactoring diperlukan? Ada beberapa tanda-tanda yang mudah-spot dalam kode, yang kadang-kadang disebut "bau buruk" [36], yang sering menunjukkan bahwa beberapa sifat desain yang diinginkan dapat mendapatkan melanggar atau bahwa ada potensi untuk meningkatkan desain. Dengan kata lain, jika Anda "bau" salah satu dari ini "bau buruk," ini mungkin merupakan tanda bahwa refactoring diperlukan. Beberapa dari bau buruk dari yang diberikan di sini.

1. Kode Duplikat. Ini sangat umum. Salah satu alasan untuk ini adalah bahwa beberapa fungsi kecil sedang dijalankan di beberapa tempat (misalnya, usia dari tanggal lahir dapat dihitung di setiap tempat yang membutuhkan tanggal). Alasan lain yang umum adalah bahwa ketika ada beberapa subclass dari kelas, maka setiap subclass mungkin berakhir melakukan hal yang sama. kode duplikat berarti bahwa jika logika ini atau fungsi harus diubah, itu harus diubah di semua tempat yang ada, membuat perubahan jauh lebih sulit dan lebih mahal.
2. Metode Long. Jika metode besar, sering menggambarkan situasi di mana ia mencoba untuk melakukan terlalu banyak hal dan karena itu tidak kohesif.
3. Panjang Class. Demikian pula, kelas besar dapat menunjukkan bahwa itu encapsulating beberapa konsep, membuat kelas tidak kohesif.
4. Panjang Parameter Daftar. interface yang kompleks jelas tidak diinginkan-mereka membuat kode lebih sulit untuk mengerti. Seringkali, kompleksitas tidak intrinsik tetapi tanda desain yang tidak tepat.
5. Beralih Laporan. Dalam program berorientasi objek, jika polimorfisme yang tidak digunakan dengan benar, kemungkinan untuk menghasilkan pernyataan switch di mana-mana perilaku adalah untuk menjadi perbedaan tergantung pada properti. Kehadiran laporan beralih simi-lar di ditempat berbeda adalah tanda bahwa alih-alih menggunakan hirarki kelas, beralih pernyataan sedang digunakan. Kehadiran pernyataan switch membuat lebih sulit untuk memperpanjang kode-jika kategori baru yang akan ditambahkan, semua pernyataan switch akan harus diubah.
6. Generality spekulatif. Beberapa hierarki kelas mungkin ada karena benda-benda di subclass tampaknya berbeda. Namun, jika perilaku objek subclass erent di ff adalah sama, dan tidak ada alasan mendesak untuk berpikir bahwa perilaku mungkin berubah, maka itu adalah kasus kompleksitas yang tidak perlu.
7. 
   Terlalu Banyak Komunikasi Antara Objek. Jika metode dalam satu kelas membuat banyak panggilan ke metode objek lain untuk mencari tahu tentang keadaan, ini adalah tanda kopling kuat. Ada kemungkinan bahwa ini mungkin tidak diperlukan dan karenanya situasi tersebut harus diperiksa untuk refactoring.

8. Pesan Chaining. Salah satu metode panggilan metode lain, yang hanya melewati panggilan ini ke objek lain, dan sebagainya. rantai ini berpotensi menyebabkan kopling yang tidak perlu.
   Ini bau buruk secara umum adalah indikasi dari desain miskin. Jelas ada kemungkinan tak terbatas dari bagaimana kode dapat refactored untuk meningkatkan desain.Namun demikian, beberapa "standar" refactorings yang dapat diterapkan dalam banyak situasi. Untuk katalog refactorings umum, dan langkah-langkah untuk melakukan masing-masing, pembaca disebut .

7.4 Satuan Pengujian
Unit testing adalah sangat populer dan paling sering digunakan praktek oleh programmer untuk memverifikasi kode yang mereka tulis. Dalam unit testing, programmer menguji / nya kode nya dalam isolasi. Untuk bahasa prosedural ini sering satu set kecil prosedur atau fungsi, dan untuk bahasa berorientasi objek ini umumnya kelas atau satu set kecil kelas. pengujian unit membutuhkan driver dan stub, dan dapat difasilitasi oleh penggunaan kerangka yang memungkinkan tes otomatis eksekusi script. kerangka yang baik seperti Cunit dan Junit ada untuk kedua bahasa prosedural dan bahasa berorientasi objek.

7.4.1 Pengujian Unit Prosedural
Dalam unit testing, satu, atau koleksi kecil, modul ini adalah untuk diuji dengan serangkaian uji kasus. Sebagai perilaku modul tergantung pada nilai parameter serta negara secara keseluruhan sistem yang merupakan bagian (misalnya, negara variabel global), kasus uji untuk modul f () akan melibatkan pengaturan baik keadaan sistem yang perilaku f () tergantung serta nilai parameter. Nilai yang sebenarnya dan keadaan sistem untuk kasus uji tergantung pada tujuan yang tester telah merancang uji kasus ini.
Pengujian modul f () dengan kasus uji maka akan melibatkan langkah-langkah berikut:

1. Mengatur sistem negara yang diperlukan oleh uji kasus ini.
2. Nilai Set parameter sesuai.
3. Panggil prosedur f () dengan parameter.
4. Bandingkan hasil f dengan hasil yang diharapkan.
5. Menyatakan apakah kasus uji telah berhasil atau gagal.

7.4.2 Pengujian Unit Kelas
Untuk pengujian dari CUT kelas (kelas yang diuji) dengan Junit, tester harus menciptakan kelas lain yang mewarisi dari Junit (misalnya, kelas cuttest meluas Junit). Kerangka Junit harus diimpor oleh kelas ini. kelas ini adalah driver untuk pengujian CUT.
Inspeksi kode adalah teknik lain yang sering diterapkan pada tingkat unit. Hal ini dapat dilihat sebagai "pengujian statis" di mana cacat terdeteksi dalam kode tidak dengan mengeksekusi kode tetapi melalui proses manual. inspeksi kode, seperti pengujian, diterapkan hampir seluruhnya di tingkat unit, yaitu, hanya unit program menjadi sasaran pemeriksaan. Oleh karena itu, kami menganggap itu sebagai bentuk lain dari unit testing. Ini harus menunjukkan bahwa pemeriksaan adalah pendekatan verifikasi umum yang dapat diterapkan untuk mendeteksi cacat pada dokumen.
Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode dengan menemukan cacat. Beberapa karakteristik kunci dari inspeksi adalah:
- Inspeksi Kode dilakukan oleh programmer dan programmer
- Ini adalah proses yang terstruktur dengan peran yang ditetapkan untuk peserta.
- Fokusnya adalah pada identifikasi cacat, tidak memperbaiki mereka.
-Inspeksi data yang dicatat dan digunakan untuk memantau efektifitas dari proses pemeriksaan.

7.5.1 Perencanaan
Tujuan dari tahap perencanaan adalah untuk mempersiapkan untuk pemeriksaan. Sebuah tim inspeksi terbentuk, yang harus mencakup programmer yang kode untuk ditinjau. Tim harus terdiri dari setidaknya tiga orang, meskipun kadang-kadang tim empat atau lima anggota juga terbentuk. Sebuah moderator ditunjuk.
Penulis kode memastikan bahwa kode siap untuk diperiksa dan bahwa kriteria entri puas. Umumnya kriteria masuk yang digunakan adalah bahwa kode mengkompilasi dengan benar dan alat analisis statis yang tersedia telah diterapkan. moderator memeriksa bahwa kriteria masuk puas dengan kode.

7.5.2 Self-Ulasan
   Pada fase ini, setiap resensi melakukan self-review kode. Selama self-review, resensi melewati seluruh kode dan log semua cacat potensial ia menemukan di log diri persiapan. Seringkali pengulas akan menandai cacat pada produk pekerjaan itu sendiri, dan dapat memberikan ringkasan dari diri-review dalam log.
 Idealnya, diri-review harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam.

7.5.3 Group Meeting Ulasan
Tujuan dasar dari pertemuan kajian kelompok adalah untuk datang dengan daftar cacat akhir, berdasarkan daftar awal dari cacat yang dilaporkan oleh pengulas dan yang baru ditemukan selama pembahasan dalam pertemuan tersebut. Kriteria masuk untuk langkah ini adalah bahwa moderator puas bahwa semua pengulas siap untuk pertemuan. Keluaran utama dari tahap ini adalah log cacat dan ringkasan laporan cacat.

7.6 Metrik
Secara tradisional, bekerja pada metrik telah difokuskan pada produk akhir, yaitu, kode. Dalam arti, semua metrik untuk produk antara persyaratan dan desain pada dasarnya digunakan untuk memastikan bahwa produk akhir memiliki kualitas tinggi dan produktivitas proyek tetap tinggi. Artinya, tujuan dasar dari metrik untuk produk antara adalah untuk memprediksi atau mendapatkan beberapa ide tentang metrik dari produk akhir.

7.6.1 Tindakan Ukuran
Ukuran produk adalah ukuran sederhana, yang dapat mudah untuk menghitung. Alasan utama untuk kepentingan dalam tindakan ukuran adalah bahwa ukuran adalah faktor utama yang ff sebuah proyek-biaya proyek. Ukuran sendiri adalah menggunakan sedikit; itu adalah hubungan ukuran dengan biaya dan kualitas yang membuat ukuran metrik penting. Hal ini juga digunakan untuk mengukur produktivitas selama proyek (misalnya, KLOC per orang-bulan).
Sejumlah metrik ada untuk kuantitasnya di kualitas kode. Yang paling umum digunakan adalah metrik ukuran, karena mereka digunakan untuk menilai produksi-tivity orang dan sering digunakan dalam estimasi biaya.Untuk ukuran paling umum adalah baris kode (LOC), yang juga digunakan di sebagian besar model biaya. Tujuan dari metrik kompleksitas adalah untuk mengukur kompleksitas perangkat lunak, sebagai com-plexity merupakan faktor penting sebuah produktivitas proyek dan merupakan faktor dalam estimasi biaya. Sejumlah metrik di ff erent ada, yang paling umum adalah kompleksitas cyclomatic, yang didasarkan pada logika internal program dan mendefinisikan kompleksitas sebagai jumlah siklus independen dalam grafik aliran program. Dalam program kita mendefinisikan jumlah terukur berikut:

- N1 adalah jumlah operator yang berbeda
- N2 adalah jumlah operan yang berbeda
- F1, j adalah jumlah kejadian dari j Operator yang paling sering
- F2, j adalah jumlah kemunculan j paling operan sering Kemudian kosakata n dari sebuah program didefinisikan sebagai
n = n1 + n2.

7.6.2 Kompleksitas Metrik
Produktivitas, jika diukur hanya dari segi baris kode per satuan waktu, dapat bervariasi banyak tergantung pada kompleksitas sistem yang akan dikembangkan. Jelas, seorang programmer akan menghasilkan jumlah yang lebih rendah dari kode untuk program sistem yang sangat kompleks, dibandingkan dengan program aplikasi sederhana.
Cyclomatic Kompleksitas Berdasarkan kemampuan pikiran manusia dan pengalaman orang, umumnya diakui bahwa kondisi dan pernyataan kontrol menambahkan kompleksitas program. Mengingat dua program dengan ukuran yang sama, program dengan jumlah yang lebih besar dari pernyataan keputusan cenderung lebih kompleks.
kesederhanaan, seperti pada contoh). Dalam grafik tersebut akan ada jalur dari node masuk ke setiap node dan jalur dari setiap node ke node keluar (dengan asumsi program tidak memiliki anomali seperti kode unreachable). Untuk grafik tersebut, jumlah cyclomatic dapat 0 jika kode adalah urutan linear dari laporan tanpa pernyataan kontrol. Jika kita menarik busur dari node keluar ke node entri, grafik akan sangat terhubung karena ada jalur antara dua node. Jumlah cyclomatic dari grafik untuk program apapun maka akan nol, dan itu diinginkan untuk memiliki kompleksitas nol untuk program yang sederhana tanpa persyaratan apa pun (setelah semua, ada beberapa kompleksitas dalam program seperti itu).
Untuk modul, kompleksitas cyclomatic didefinisikan sebagai jumlah cyclomatic dari grafik tersebut untuk modul.
Ternyata kompleksitas cyclomatic dari modul (atau cyclomatic num-ber grafik nya) adalah sama dengan jumlah maksimum sirkuit bebas linear dalam grafik. Satu set rangkaian linear jika ada sirkuit yang benar-benar terkandung dalam sirkuit lain atau merupakan kombinasi dari sirkuit lainnya.
Jumlah cyclomatic merupakan salah satu ukuran kuantitatif kompleksitas modul. Hal ini dapat diperluas untuk menghitung kompleksitas seluruh program, meskipun itu lebih cocok pada tingkat modul.
Jumlah ini juga dapat digunakan sebagai jumlah jalur yang harus diuji selama pengujian. kompleksitas cyclomatic adalah salah satu kompleksitas mea-langkah-paling banyak digunakan. Percobaan menunjukkan bahwa kompleksitas cyclomatic sangat berkorelasi dengan ukuran modul di LOC (setelah semua, lebih baris kode semakin besar jumlah keputusan).


7.4.2 Pengujian Unit Kelas
Unit testing adalah sangat populer dan paling sering digunakan praktek oleh programmer untuk memverifikasi kode yang mereka tulis. Dalam unit testing, programmer menguji / nya kode nya dalam isolasi. Untuk bahasa prosedural ini sering satu set kecil prosedur atau fungsi, dan untuk bahasa berorientasi objek ini umumnya kelas atau satu set kecil kelas. pengujian unit membutuhkan driver dan stub, dan dapat difasilitasi oleh penggunaan kerangka yang memungkinkan tes otomatis eksekusi script. kerangka yang baik seperti Cunit dan Junit ada untuk kedua bahasa prosedural dan bahasa berorientasi objek.
Inspeksi kode adalah teknik lain yang sering diterapkan pada tingkat unit. Hal ini dapat dilihat sebagai "pengujian statis" di mana cacat terdeteksi dalam kode tidak dengan mengeksekusi kode tetapi melalui proses manual. inspeksi kode, seperti pengujian, diterapkan hampir seluruhnya di tingkat unit, yaitu, hanya unit program menjadi sasaran pemeriksaan. Oleh karena itu, kami menganggap itu sebagai bentuk lain dari unit testing. Ini harus menunjukkan bahwa pemeriksaan adalah pendekatan verifikasi umum yang dapat diterapkan untuk mendeteksi cacat pada dokumen.
Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode dengan menemukan cacat. Beberapa karakteristik kunci dari inspeksi adalah:
- Inspeksi Kode dilakukan oleh programmer dan programmer
- Ini adalah proses yang terstruktur dengan peran yang ditetapkan untuk peserta.
- Fokusnya adalah pada identifikasi cacat, tidak memperbaiki mereka.
- Inspeksi data yang dicatat dan digunakan untuk memantau efektifitas dari proses pemeriksaan.

7.5.1 Perencanaan
Tujuan dari tahap perencanaan adalah untuk mempersiapkan untuk pemeriksaan. Sebuah tim inspeksi terbentuk, yang harus mencakup programmer yang kode untuk ditinjau. Tim harus terdiri dari setidaknya tiga orang, meskipun kadang-kadang tim empat atau lima anggota juga terbentuk. Sebuah moderator ditunjuk.
Penulis kode memastikan bahwa kode siap untuk diperiksa dan bahwa kriteria entri puas. Umumnya kriteria masuk yang digunakan adalah bahwa kode mengkompilasi dengan benar dan alat analisis statis yang tersedia telah diterapkan. moderator memeriksa bahwa kriteria masuk puas dengan kode.

7.5.2 Self-Ulasan
Pada fase ini, setiap resensi melakukan self-review kode. Selama self-review, resensi melewati seluruh kode dan log semua cacat potensial ia menemukan di log diri persiapan. Seringkali pengulas akan menandai cacat pada produk pekerjaan itu sendiri, dan dapat memberikan ringkasan dari diri-review dalam log.
Idealnya, diri-review harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam.

7.5.3 Group Meeting Ulasan
Tujuan dasar dari pertemuan kajian kelompok adalah untuk datang dengan daftar cacat akhir, berdasarkan daftar awal dari cacat yang dilaporkan oleh pengulas dan yang baru ditemukan selama pembahasan dalam pertemuan tersebut.
 Idealnya, diri-review harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam. Fase ini dari proses peninjauan berakhir ketika semua pengulas telah benar dilakukan mereka diri review dan mengisi diri log peninjauan.

Software Architecture

Nama: Annisa Aprilya
NPM: 43A87007150334
Kelas: S1/SI/3/B P


5.7 Ringkasan

- Arsitektur dari sistem perangkat lunak menyediakan tampilan tingkat tinggi yang sangat dari sistem dalam hal bagian dari sistem dan bagaimana mereka berhubungan untuk membentuk seluruh sistem.

- Tergantung pada bagaimana sistem dipartisi, kita mendapatkan di ff erent lihat arsitektur sistem. Akibatnya, arsitektur sistem perangkat lunak didefinisikan sebagai struktur dari sistem yang terdiri dari unsur perangkat lunak, sifat eksternal terlihat mereka, dan hubungan di antara mereka.

- Arsitektur memfasilitasi pengembangan sistem berkualitas tinggi. Hal ini juga memungkinkan analisis dari banyak sifat sistem seperti kinerja yang tergantung sebagian besar pada arsitektur harus dilakukan di awal siklus hidup perangkat lunak.

- Ada tiga pandangan arsitektur utama dari sistem-modul, komponen dan konektor, dan alokasi. Dalam pandangan modul, sistem ini dipandang sebagai struktur modul pemrograman seperti paket, kelas, fungsi, dll dalam komponen dan konektor (C & C) lihat, sistem adalah kumpulan dari entitas runtime disebut komponen, yang saling berinteraksi melalui konektor. Pandangan alokasi menggambarkan bagaimana unit software erent di ff dialokasikan ke sumber daya perangkat keras dalam sistem.

- C & C lihat adalah yang paling umum, dan sering pusat dari deskripsi arsitektur. Pandangan ini sering digambarkan oleh diagram blok menentukan di ff komponen erent dan di ff konektor erent antara komponen.

- Ada beberapa gaya umum untuk C & C tampilan yang telah ditemukan berguna untuk membuat arsitektur ini tampilan untuk sistem. Ini termasuk pipa dan filter, data bersama, client-server, mempublikasikan-berlangganan, peer to peer, dan KOMUNIKASI-ing proses gaya. Masing-masing gaya ini menggambarkan jenis komponen dan konektor yang ada dan kendala pada bagaimana mereka digunakan.

- Pipa dan filter memiliki satu jenis komponen (filter) dan satu jenis konektor (pipa) dan komponen dapat dihubungkan melalui pipa.

- Gaya client-server memiliki dua jenis komponen (client dan server) dan ada satu konektor (permintaan / reply). Seorang klien hanya dapat berkomunikasi dengan server, dan interaksi yang diprakarsai oleh klien.

- Dalam gaya data bersama dua jenis komponen yang repositori dan data accesor. accesor Data membaca / menulis repositori dan berbagi informasi di antara mereka sendiri melalui repositori.

- Arsitektur membentuk dasar untuk sistem dan sisanya dari kegiatan desain dan pengembangan, dan perlu didokumentasikan dengan baik. Yang tepat


- Setiap sistem yang kompleks terdiri dari subsistem yang berinteraksi di bawah kendali desain sistem sehingga sistem menyediakan perilaku yang diharapkan.
- Beberapa penting menggunakan itu deskripsi arsitektur perangkat lunak bermain adalah
1. Memahami dan komunikasi. Deskripsi arsitektur adalah primar-ily untuk berkomunikasi arsitektur untuk berbagai pemangku kepentingan,dan pengguna yang akan menggunakan sistem, Melalui penjelasan ini para pemangku kepentingan memperoleh pemahaman tentang beberapa sifat makro dari sistem dan bagaimana sistem bermaksud untuk mengisi persyaratan fungsional dan kualitas bermaksud untuk ful mengisi persyaratan fungsional dan kualitas. Sebagai gambaran menyediakan bahasa umum antara pemangku kepentingan, itu juga menjadi kendaraan untuk negosiasi dan kesepakatan di antara para pemangku kepentingan, yang mungkin memiliki tujuan konflik-ing.
2. Reuse. Dunia rekayasa perangkat lunak telah, untuk waktu yang lama, telah bekerja menuju suatu disiplin di mana perangkat lunak dapat dirakit dari bagian-bagian yang dikembangkan oleh orang dan tersedia bagi orang lain untuk digunakan.
3. Konstruksi dan Evolution. Arsitektur partisi sistem menjadi bagian-bagian, beberapa partisi arsitektur yang disediakan dapat digunakan secara alami untuk membangun sistem
4. Analisis. Hal ini sangat diinginkan jika dapat ditentukan beberapa sifat penting tentang be-havior dari sistem sebelum sistem ini benar-benar dibangun. Hal ini akan memungkinkan para desainer untuk mempertimbangkan alternatif dan memilih salah satu yang terbaik akan sesuai dengan kebutuhan.
Ada pandangan umum yang muncul bahwa tidak ada arsitektur yang unik dari sistem. Definisi yang kita anut (diberikan di atas) juga mengungkapkan sentimen ini. Akibatnya, tidak ada gambar salah satu arsitektur sistem.
Banyak jenis views telah diusulkan. Sebagian besar dari pandangan diusulkan umumnya termasuk salah satu dari ketiga jenis :
- Modul
- Komponen dan konektor
- Alokasi
Dalam pandangan modul, sistem ini dipandang sebagai kumpulan unit kode, masing-masing menerapkan beberapa bagian dari fungsi sistem. Artinya, unsur-unsur utama dalam pandangan ini adalah modul. Contoh modul paket, kelas, prosedur, metode, koleksi fungsi, dan koleksi kelas. Dalam komponen dan konektor (C & C) lihat, sistem ini dipandang sebagai col-pembacaan entitas runtime disebut komponen. Artinya, komponen adalah unit yang memiliki identitas dalam sistem mengeksekusi. Objects (tidak kelas), sebuah kolektif-tion benda, dan proses adalah contoh dari komponen. Sementara pelaksana, komponen harus berinteraksi dengan orang lain untuk mendukung layanan system.
Pandangan alokasi berfokus pada bagaimana unit software dialokasikan ke sumber daya seperti perangkat keras, sistem file, dan orang-orang. Artinya, pandangan alokasi menentukan hubungan antara unsur-unsur perangkat lunak dan elemen lingkungan di mana sistem perangkat lunak dijalankan. Mereka mengekspos sifat struktural seperti dimana proses berjalan pada prosesor mana, dan bagaimana file sistem diatur pada sistem file.
Catatan tentang hubungan antara arsitektur dan desain adalah dalam rangka. Sebagai partisi sistem menjadi bagian-bagian yang lebih kecil dan menyusun sistem dari bagian-bagian ini juga merupakan tujuan dari desain, pertanyaan alami adalah apa yang perbedaan selisih antara desain dan arsitektur karena keduanya bertujuan untuk mencapai tujuan yang sama dan tampaknya fundamental mengandalkan membagi dan menaklukkan aturan?
Pertama, harus jelas bahwa arsitektur adalah desain dalam hal itu adalah dalam domain solusi dan berbicara tentang struktur dari sistem yang diusulkan. Selanjutnya, pandangan arsitektur memberikan tampilan tingkat tinggi dari sistem, mengandalkan abstraksi untuk menyampaikan makna-sesuatu yang desain juga tidak. Jadi, arsitektur desain.
Kita bisa melihat arsitektur sebagai desain tingkat tinggi yang sangat, hanya berfokus pada komponen utama, dan aktivitas arsitektur sebagai langkah pertama dalam desain. Apa yang kita jangka desain benar-benar tentang modul yang pada akhirnya akan ada sebagai kode. Artinya, mereka adalah representasi yang lebih konkret pelaksanaan (meskipun belum implementasi). Akibatnya, selama desain isu-tingkat yang lebih rendah seperti struktur data, file, dan sumber data, harus ditangani, sementara isu-isu tersebut umumnya tidak signifikan pada tingkat arsitektur.


Batas-batas antara arsitektur dan desain tingkat tinggi tidak sepenuhnya jelas. Cara lapangan telah berkembang, kita dapat mengatakan bahwa garis antara Architec-mendatang dan desain benar-benar sampai ke desainer atau arsitek. Pada tingkat arsitektur, salah satu kebutuhan untuk hanya menampilkan bagian-bagian yang diperlukan untuk melakukan evaluasi yang diinginkan. Struktur internal bagian-bagian ini tidak penting.
Komponen umumnya unit perhitungan atau menyimpan data dalam sistem. Sebuah komponen memiliki nama, yang umumnya dipilih untuk mewakili peran komponen atau fungsi melakukan.
Nama ini juga menyediakan identitas unik untuk komponen, yang diperlukan untuk referensi rincian tentang komponen dalam dokumen pendukung, sebagai C & C menggambar hanya akan menampilkan nama-nama komponen.
Komponen adalah dari jenis komponen, di mana jenis merupakan komponen generik, mendefinisikan komputasi umum dan interface komponen dari jenis yang harus memiliki.


120 5. Arsitektur Software


Dokumen arsitektur harus menjelaskan konteks di mana arsitektur dirancang, pandangan arsitektur di ff erent yang diciptakan, dan bagaimana pandangan erent di ff berhubungan satu sama lain. Deskripsi arsitektur harus menentukan jenis di ff erent elemen dan perilaku eksternal mereka, dan alasan arsitektur.

- Arsitektur harus dievaluasi untuk melihat bahwa itu memenuhi persyaratan. Pendekatan yang umum adalah untuk melakukan evaluasi subjektif sehubungan dengan sifat yang diinginkan.

Latihan Penilaian Diri

1. Mengapa arsitektur tidak hanya satu struktur yang terdiri dari di ff bagian erent dan hubungan mereka?

2. Apa di ff erent gaya arsitektur untuk komponen dan konektor struc-mendatang dari sistem?

3. Pertimbangkan sebuah website interaktif yang menyediakan banyak fitur di ff erent untuk melakukan berbagai tugas. Menunjukkan bahwa arsitektur untuk ini dapat direpresentasikan sebagai gaya bersama-data serta gaya client-server. Mana yang akan Anda sukai dan mengapa?

4. Apa yang harus dokumen arsitektur untuk sebuah sistem mengandung?

5. Sarankan bagaimana Anda akan mengevaluasi arsitektur yang diusulkan dari modifiability per prospektif?
6. Setiap sistem yang kompleks terdiri dari subsistem yang berinteraksi di bawah kendali desain sistem sehingga sistem menyediakan perilaku yang diharapkan?

SOFTWARE PROBLEM

Nama : Annisa Aprilya
Npm : 43A87007150334
Kelas : S1/SI/3/B P

BAB 1

PERMASALAHAN PERANGKAT LUNAK

Mengapa ini menjadi perbedaan selisih produktivitas dalam dua skenario? Mengapa siswa yang sama yang dapat menghasilkan software pada produktivitas beberapa ribu LOC per bulan saat kuliah berakhir hanya memproduksi sekitar seribu LOC per bulan ketika bekerja di sebuah perusahaan?

Jawabannya, tentu saja, adalah bahwa dua hal perbedaan sedang dibangun dalam dua skenario. Pada bagian pertama, sistem mahasiswa sedang dibangun yang terutama dimaksudkan untuk tujuan demonstrasi, dan tidak diharapkan untuk digunakan kemudian. Karena tidak digunakan, tidak ada signifikansi tergantung pada perangkat lunak dan adanya bug dan kurangnya kualitas tidak menjadi perhatian utama. Tidak adalah masalah kualitas lainnya seperti kegunaan, pemeliharaan, portabilitas dll.

Di sisi lain, sistem perangkat lunak industri-kekuatan dibangun untuk memecahkan beberapa masalah klien dan digunakan oleh organisasi klien untuk operasi beberapa bagian dari bisnis, dan kerusakan sistem tersebut dapat memiliki dampak besar dalam hal keuangan atau kerugian bisnis, ketidaknyamanan kepada pengguna, atau kerugian harta benda dan kehidupan. Akibatnya, sistem perangkat lunak harus berkualitas tinggi sehubungan dengan sifat seperti keandalan, kegunaan, portabilitas, dll

Kebutuhan ini untuk kualitas tinggi dan untuk memenuhi pengguna akhir memiliki dampak yang besar pada perangkat lunak cara dikembangkan dan biaya. Aturan praktis Brooks memberikan menunjukkan bahwa perangkat lunak kekuatan industri mungkin biaya sekitar 10 kali perangkat lunak siswa.

Industri perangkat lunak sebagian besar tertarik untuk mengembangkan perangkat lunak industri-kekuatan, dan bidang rekayasa perangkat lunak berfokus pada bagaimana membangun sistem tersebut. Artinya, masalah domain untuk rekayasa perangkat lunak adalah perangkat lunak kekuatan industri. Di sisa lain, ketika kita menggunakan software jangka, kita berarti perangkat lunak kekuatan industri. Dalam sisa bab ini, kita akan belajar:

- Bahwa kualitas, biaya, dan jadwal adalah kekuatan utama yang mendorong (kekuatan industri) proyek perangkat lunak.


- Bagaimana biaya dan produktivitas didefinisikan dan diukur untuk proyek semacam itu, dan bagaimana kualitas software ditandai dan diukur.

- Bahwa skala besar dan perubahan adalah atribut penting dari masalah domain dan solusi pendekatan harus menangani mereka.

1.1. Biaya, Jadwal, dan Kualitas

Software industri-kekuatan sangat mahal terutama karena fakta bahwa pengembangan perangkat lunak sangat padat karya. Untuk mendapatkan ide dari biaya yang terlibat, mari kita perhatikan keadaan saat praktik di industri. Baris kode (LOC) atau ribuan baris kode (KLOC) disampaikan adalah yang palingumum digunakan ukuran ukuran software di industri. Karena biaya utama memproduksi perangkat lunak adalah tenaga yang digunakan, biaya pengembangan perangkat lunak biasanya diukur dalam hal orang-bulan dari usaha menghabiskan dalam pembangunan. Dan produktivitas sering diukur dalam industri dalam hal LOC (atau KLOC) per orang per bulan.

Produktivitas di industri perangkat lunak untuk menulis kode segar biasanya berkisar antara beberapa ratus sampai sekitar 1000 + LOC per orang bulan. Ini produktivity adalah atas seluruh siklus pengembangan, bukan hanya tugas coding. perusahaan perangkat lunak sering mengeluarkan biaya kepada klien untuk siapa mereka yang sedang mengembangkan perangkat lunak menjadi $ 3000 - $ 15.000 per orang per bulan. Dengan produktivitas 1000 LOC per orang per bulan, itu berarti bahwa setiap baris dari biaya kode disampaikan antara $ 3 dan $ 15! Dan bahkan proyek-proyek kecil dapat dengan mudah berakhir dengan software dari 50.000 LOC. Dengan produktivitas ini, seperti proyek software akan biaya antara $ 150.000 dan $ 750.000!

Jadwal merupakan faktor penting dalam banyak proyek. tren bisnis mendikte bahwa waktu ke pasar dari produk harus dikurangi; yaitu, waktu siklus dari konsep untuk pengiriman harus kecil. Untuk software ini berarti bahwa perlu dikembangkan lebih cepat, dan dalam waktu yang ditentukan. Sayangnya, sejarah perangkat lunak ini penuh dengan kasus di mana proyek telah secara substansial terlambat.

Jelas, oleh karena itu, mengurangi biaya dan waktu siklus untuk perangkat lunak de-Pembangunan adalah tujuan utama dari rekayasa perangkat lunak. Produktivitas dalam hal output (KLOC) satu orang perbulan memadai dapat menangkap biaya dan kekhawatiran schedule. Jika produktivitas lebih tinggi, itu harus jelas bahwa biaya dalam hal satu orang perbulan akan lebih rendah (kerjasama dapatdilakukan dengan lebih sedikit satu orang per bulan). Demikian pula, jika produktivitas lebih tinggi, potensi pengembangan perangkat lunak dalam waktu kurang meningkatkan-tim produktivitas yang lebih tinggi akan menyelesaikan pekerjaan dalam waktu kurang dari tim ukuran yang sama dengan produktivitas rendah. (Waktu yang sebenarnya proyek ini akan mengambil, tentu saja, tergantung juga pada jumlah orang al-terletak proyek.) Oleh karena itu, mengejar produktivitas yang lebih tinggi adalah kekuatan pendorong dasar di balik rekayasa perangkat lunak dan alasan utama untuk menggunakan alat yang berbeda dan teknik.

Selain biaya dan jadwal, yang lain software faktor utama pendorong insinyur-neering adalah kualitas. Hari ini, kualitas adalah salah satu mantra utama, dan strategi bisnis yang dirancang di sekitar itu. Sayangnya, sejumlah besar kasus terjadi mengenai tidak dapat diandalkan perangkat lunak-perangkat lunak sering tidak melakukan apa yang seharusnya dilakukan atau melakukan sesuatu tidak seharusnya dilakukan. Jelas, mengembangkan perangkat lunak berkualitas tinggi adalah tujuan mendasar lain dari rekayasa soft-ware. Namun, sementara biaya umumnya dipahami, konsep kualitas dalam konteks perangkat lunak perlu penjelasan lebih lanjut.
Kualitas perangkat lunak terdiri dari enam atribut utama, Atribut ini dapat didefinisikan sebagai berikut:

- Fungsi. kemampuan untuk menyediakan fungsi yang memenuhi dinyatakan dan tersirat kebutuhan ketika perangkat lunak yang digunakan.

- Keandalan. kemampuan untuk menyediakan layanan kegagalan bebas.

- Usability. kemampuan untuk dipahami, dipelajari, dan digunakan.

- Efisiensi. kemampuan untuk memberikan kinerja yang relatif sesuai dengan jumlah sumber daya yang digunakan.

- Rawatan. kemampuan yang akan dimodifikasi untuk keperluan membuat cor-rections, perbaikan, atau adaptasi.

- Portabilitas. kemampuan yang akan disesuaikan untuk menetapkan perbedaan lingkungan tanpa menerapkan aksi atau cara lain dengan syarat untuk tujuan di dalam produk.

1.2. Skala dan Perubahan 5

Pendekatan yang digunakan, maka diharapkan proyek ini akan memiliki kerapatan cacat yang sama sebagai proyek masa lalu.

Perlu menunjukkan bahwa menggunakan definisi kualitas, apa cacat yang harus didefinisikan secara jelas. Sebuah cacat bisa ada beberapa masalah dalam perangkat lunak yang menyebabkan perangkat lunak untuk crash atau masalah yang menyebabkan output untuk tidak selaras dengan benar atau yang salah mengeja beberapa kata, dll yang tepat definisi apa yang dianggap cacat jelas akan tergantung pada proyek atau standar organisasi mengembangkan penggunaan proyek (biasanya itu adalah yang terakhir).

Selain kehandalan, atribut kualitas lain yang sangat menarik adalah menjaga-kemampuan. Setelah perangkat lunak disampaikan dan disebarkan, memasuki tahap pemeliharaan. Mengapa pemeliharaan diperlukan untuk perangkat lunak, ketika perangkat lunak tidak memiliki komponen fisik yang dapat menurunkan dengan usia? Software perlu dipertahankan be-penyebab cacat sisa yang tersisa dalam sistem. Hal ini umumnya percaya bahwa keadaan seni saat ini adalah terbatas dan mengembangkan perangkat lunak dengan nol de-fect density tidak mungkin. cacat ini, sekali ditemukan, perlu dihapus, yang mengarah ke apa yang disebut pemeliharaan korektif. Pemeliharaan juga diperlukan untuk mengubah perangkat lunak yang dikirimkan untuk memenuhi kebutuhan disempurnakan pengguna dan lingkungan, yang mengarah ke adaptif pemeliharaan. Selama hidup dari sistem perangkat lunak, biaya pemeliharaan jauh dapat melebihi biaya pengembangan asli.

Setiap proyek software melibatkan penggunaan teknik dan proyek mengelola-ment. Dalam proyek-proyek kecil, metode informal bagi pengembangan dan pengelolaan dapat digunakan. Namun, untuk proyek-proyek besar, keduanya harus jauh lebih ketat, seperti yang diilustrasikan pada Gambar 1.2. Dengan kata lain, untuk berhasil melaksanakan proyek, metode yang tepat untuk rekayasa sistem harus bekerja dan proyek harus dikelola ketat untuk memastikan bahwa biaya, jadwal, dan kualitas berada di bawah kontrol. skala besar adalah karakteristik kunci dari domain masalah dan pendekatan solusi harus menggunakan alat dan teknik yang memiliki kemampuan untuk membangun sistem perangkat lunak besar.

Perubahan adalah karakteristik lain dari domain masalah yang ap-proaches untuk pembangunan harus menangani. Sebagai set lengkap persyaratan untuk sistem ini umumnya tidak diketahui (sering tidak bisa diketahui pada awal proyek) atau menyatakan, sebagai hasil pengembangan dan waktu berlalu, persyaratan tambahan diidentifikasi, yang perlu dimasukkan dalam perangkat lunak menjadi- ing dikembangkan. Hal ini perlu untuk perubahan mengharuskan metode untuk pengembangan merangkul perubahan dan mengakomodasi efisien. permintaan perubahan bisa sangat mengganggu proyek, dan jika tidak ditangani dengan baik, dapat mengkonsumsi sampai 30 sampai 40% dari biaya pembangunan.
Seperti dibahas di atas, software harus berubah bahkan setelah dikerahkan. Meskipun secara tradisional perubahan software selama pemeliharaan telah dibedakan dari perubahan yang terjadi saat pembangunan berlangsung, garis ini kabur, sebagai fundamental perubahan kedua skenario tersebut.

Secara keseluruhan, karena dunia berubah lebih cepat, software harus berubah lebih cepat, bahkan saat dalam pengembangan. Oleh karena itu perubahan kebutuhan adalah characteris-tic dari domain masalah. Dalam dunia sekarang ini, pendekatan yang tidak dapat menerima dan mengakomodasi perubahan yang sedikit digunakan-mereka dapat memecahkan hanya mereka beberapa masalah yang tahan perubahan.

1.3. Ringkasan

- Masalah domain untuk rekayasa perangkat lunak adalah perangkat lunak kekuatan industri. Perangkat lunak ini dimaksudkan untuk memecahkan beberapa masalah beberapa set pengguna, dan diharapkan menjadi berkualitas tinggi.

- Dalam domain masalah ini, biaya, jadwal, dan kualitas kekuatan pendorong dasar. Oleh karena itu, metode dan alat-alat yang akan digunakan untuk memecahkan masalah dalam domain ini harus memastikan produktivitas yang tinggi dan kualitas tinggi.

- Produktivitas diukur sebagai jumlah output per unit dari sumber daya input. Dalam perangkat lunak, output dapat diukur dalam hal baris kode disampaikan, dan sebagai waktu manusia adalah sumber daya utama, input dapat diukur sebagai orang-bulan. Produktivitas sehingga dapat diukur sebagai baris kode disampaikan per orang bulan.

- Kualitas Software memiliki banyak atribut yang meliputi fungsi, reliabil-ity, kegunaan, e FFI efisiensi, maintainability, dan portabilitas. Keandalan sering


1.4. Masalah Perangkat Lunak

- Dianggap sebagai atribut kualitas utama, dan seperti tidak dapat diandalkan dalam perangkat lunak adalah disebabkan oleh cacat pada perangkat lunak, kualitas dapat ditandai dengan jumlah cacat per seribu baris kode.

- Masalah dalam domain ini sering cenderung sangat besar dan di mana kebutuhan pelanggan berubah cepat. Oleh karena itu teknik yang digunakan untuk mengembangkan perangkat lunak industri-kekuatan harus sedemikian rupa sehingga mereka mampu membangun sistem perangkat lunak besar, dan memiliki kemampuan untuk menangani perubahan.

TUGAS 1 RPL (Sistem Pengembangan Software)

NAMA: ANNISA APRILYA

KELAS: S1/SI/3/B/P

NPM: 43A87007150334

 

1. WATERFALL MODEL

 

Pengertian Waterfall Model

Model waterfall adalah sesuatu proses perkembangan perangkat lunak secara beruntun, dimana kemajuan dari perangkat lunak dipandang sebagai terus mengalir ke bawah diibaratkan seperti air terjun yang melewati fase-fase perencanaan,implementasi (kontruksi), dan pengujian. Model Pengembangan Air Terjun, merupakan paradigma model pengembangan perangkat lunak paling tua, dan paling banyak dipakai. Model ini mengusulkan sebuah pendekatan perkembangan perangkat lunak yang sistematik dan sekunsial yang dimulai pada tingkat dan kemajuan sistem pada seluruh tahapan analisis, desain , kode, pengujian, dan pemeliharaan. 

DIAGRAM WATERFALL MODEL

Proses Kerja Waterfall Model

• Rekayasa dan pemodelan sistem/informasi

Langkah pertama dimulai dengan membangun keseluruhan elemen sistem dan memilah bagian-bagian mana yang akan dijadikan bahan pengembangan perangkat lunak, dengan memperhatikan hubungannya dengan Hardware, User, dan Database.

• Analisis kebutuhan perangkat lunak

Pada proses ini, dilakukan penganalisaan dan pengumpulan kebutuhan sistem yang meliputi Domain informasi, fungsi yang dibutuhkan unjuk kerja/performansi dan antarmuka. Hasil penganalisaan dan pengumpulan tersebut didokumentasikan dan diperlihatkan kembali kepada pelanggan.

• Desain

Pada proses Desain, dilakukan penerjemahan syarat kebutuhan sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuatnya proses pengkodean (coding). Proses ini berfokus pada struktur data, arsitektur perangkat lunak, representasi interface, dan detail algoritma prosedural.

• Pengkodean

Pengkodean merupakan proses menterjemahkan perancangan desain ke bentuk yang dapat dimengerti oleh mesin, dengan menggunakan bahasa pemrograman.

• Pengujian

Setelah Proses Pengkodean selesai, dilanjutkan dengan proses pengujian pada program perangkat lunak, baik Pengujian logika internal, maupun Pengujian eksternal fungsional untuk memeriksa segala kemungkinan terjadinya kesalahan dan memeriksa apakah hasil dari pengembangan tersebut sesuai dengan hasil yang diinginkan.

• Pemeliharaan

Proses Pemeliharaan erupakan bagian paling akhir dari siklus pengembangan dan dilakukan setelah perangkat lunak dipergunakan. Kegiatan yang dilakukan pada proses pemeliharaan antara lain :

• Corrective Maintenance : yaitu mengoreksi apabila terdapat kesalahan pada perangkat lunak, yang baru terdeteksi pada saat perangkat lunak dipergunakan.
• Adaptive Maintenance : yaitu dilakukannya penyesuaian/perubahan sesuai dengan lingkungan yang baru, misalnya hardware, periperal, sistem operasi baru, atau sebagai tuntutan atas perkembangan sistem komputer, misalnya penambahan driver, dll.
• Perfektive Maintenance : Bila perangkat lunak sukses dipergunakan oleh pemakai. Pemeliharaan ditujukan untuk menambah kemampuannya seperti memberikan fungsi-fungsi tambahan, peningkatan kinerja dan sebagainya.

• Contoh Penerapan dari Pengembangan Waterfall Model

Contoh dari penerapan model pengembangan ini adalah pembuatan program pendaftaran online ke suatu Instansi Pendidikan. Program ini akan sangat membantu dalam proses pendaftaran, karena dapat meng-efektifkan waktu serta pendaftar tidak perlu repot-repot langsung mendatangi Instansi Pendidikan. Teknisnya adalah sebagai berikut :

• Sistem program untuk pendaftaran dibuat menggunakan bahasa pemrograman PHP, dengan Sistem Database yang dibuat menggunakan MySQL, dan diterapkan (diaplikasikan) pada PC (personal computer) dengan sistem operasi berbasis Microsoft Windows, Linux, dan sebagainya.
• Setelah program selesai dibuat dan kemudian dipergunakan oleh user, programmer akan memelihara serta menambah atau menyesuaikan program dengan kebutuhan serta kondisi user.

• Kelebihan Waterfall Model :
• Tahapan proses pengembangannya tetap (pasti), mudah diaplikasikan, dan prosesnya teratur.
• Cocok digunakan untuk produk software/program yang sudah jelas kebutuhannya di awal, sehingga minim kesalahannya.
• Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
• Documen pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

• Kekurangan Waterfall Model :
• Proyek yang sebenarnya jarang mengikuti alur sekuensial seperti diusulkan, sehingga perubahan yang terjadi dapat menyebabkan hasil yang sudah didapatkan tim pengembang harus diubah kembali/iterasi sering menyebabkan masalah baru.
• Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.
• Sulit untuk mengalami perubahan kebutuhan yang diinginkan oleh customer/pelanggan.
• Pelanggan harus sabar untuk menanti produk selesai, karena dikerjakan tahap per tahap, dan proses pengerjaanya akan berlanjut ke setiap tahapan bila tahap sebelumnya sudah benar-benar selesai.
• Perubahan ditengah-tengah pengerjaan produk akan membuat bingung tim pengembang yang sedang membuat produk.
• Adanya waktu kosong (menganggur) bagi pengembang, karena harus menunggu anggota tim proyek lainnya menuntaskan pekerjaannya.

2. PROTOTYPING

Pengertian Prototyping

Prototyping adalah sebuah proses penampilan persyaratan, pengaplikasian prinsip analisis, dan penyusuna model perangkat lunakyang akan dibangun untuk penilaian dan pengembangan. Akhirnya ada lingkungan yang membutuhkan kontruksi prototype pada awal analisis, karena model adalah satu satunya alat dimana persyaratan dapat ditarik secara efektf. Model tersebut kemudian dikembangan dalam perangkat lunak produksi..

DIAGRAM PROTOTYPING

Proses Kerja Prototyping

• Pengumpulan kebutuhan

Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

• Membangun prototyping

Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).

• Evaluasi protoptyping

Evaluasi ini dilakukan oleh pelanggan, apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan atau belum. Jika sudah sesuai, maka langkah selanjutnya akan diambil. Namun jika tidak, prototyping direvisi dengan mengulang langkah-langkah sebelumnya.

• Mengkodekan sistem

Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

• Menguji sistem

Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, kemudian dilakukan proses Pengujian. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur, dll.

• Evaluasi Sistem

Pelanggan mengevaluasi apakah perangkat lunak yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, maka proses akan dilanjutkan ke tahap selanjutnya, namun jika perangkat lunak yang sudah jadi tidak/belum sesuai dengan apa yang diharapkan, maka tahapan sebelumnya akan diulang.

• Menggunakan sistem

Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan. Model Prototyping ini sangat sesuai diterapkan untuk kondisi yang beresiko tinggi di mana masalah-masalah tidak terstruktur dengan baik, terdapat fluktuasi kebutuhan pemakai yang berubah dari waktu ke waktu atau yang tidak terduga, bila interaksi dengan pemakai menjadi syarat mutlak dan waktu yang tersedia sangat terbatas sehingga butuh penyelesaian yang segera. Model ini juga dapat berjalan dengan maksimal pada situasi di mana sistem yang diharapkan adalah yang inovatif dan mutakhir sementara tahap penggunaan sistemnya relatif singkat.

Kelebihan Model Prototype :

• Pelanggan berpartisipasi aktif dalam pengembangan sistem, sehingga hasil produk pengembangan akan semakin mudah disesuaikan dengan keinginan dan kebutuhan pelanggan.
• Penentuan kebutuhan lebih mudah diwujudkan.
• Mempersingkat waktu pengembangan produk perangkat lunak.
• Adanya komunikasi yang baik antara pengembang dan pelanggan.
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
• Lebih menghemat waktu dalam pengembangan sistem.
• Penerapan menjadi lebih mudah karena pelanggan mengetahui apa yang diharapkannya.

Kekurangan Model Prototype :

• Proses analisis dan perancangan terlalu singkat.
• Biasanya kurang fleksibel dalam mengahadapi perubahan.
• Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang.
• Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien.

3. ITERATIVE DEVELOPMENT

Penjelasan Iterative Development

Iterative Development adalah metode yang merupakan pengembangan dari prototyping model dan digunakan ketika requirement dari software akan terus berkembang dalam tahapan-tahapan pengembangan aplikasi tersebut. Sedikit pengertian tentang requirement software dari developer yang diterapkan pada tahap pertama iterasi, akan mendapatkan tanggapan dari user. Ketika requirement menjadi jelas, tahapan iterasi selanjutnya akan dilaksanakan.

DIAGRAM ITERATIVE DEVELOPMENT

Proses Iterative Development

1. Mendefinisikan tujuan dan kebutuhan bisnis, mengembangkan desain konseptual,

2. Rancangan konsep, rencana pengujian, dan analis terhadap resiko dengan melibatkan pemakai.

3. Mendefinisikan kebutuhan sistem, mengembangkan desail logikal, mengkompilasi (software-build)   rancangan awal, mengevaluasi hasil dengan melibatkan pemakai.

4. Mendefinisikan kebutuhan subsistem, menghasilkan desain fisikal, mengkompilasi rancangan berikutnya, mengevaluasi hasil dengan melibatkan pemakai.

5. Mendefinisikan kebutuhan setiap unit, menghasilkan desain akhir, mengkompilasi rancangan akhir.

Keuntungan Iterative Development 

1. User dapat mencoba sistem yg sudah dikembangkan dan kemudian dapat memberikan masukkan >  keterlibatan user semakin intens dampak positif dalam pengembangan

2. Prototype relatif lebih mudah dibangun dan tidak memerlukan waktu yang lama

3. Dengan prototype, kesalahan & kelalaian dalam pengembangan dapat segera diketahui

Kelemahan Iterative Development

1. Setiap iterasi bergantung prototype sebelumnya solusi final umumnya terjadi apabila ada perbedaan yg nyata pada prototype sebelumnya

2. Formal end-of-phase mungkin tidak terjadi, karena sangat sulit menentukan scope dari suatu prototype > proyek tidak pernah selesai

3. Dokumentasi seringkali tdk lengkap > fokus pada pembuatan prototype

4. Isu2 mengenai system backup & recovery, system performance dan system security, kurang/tidak diperhatikan dan sering terlupakan

4. RATIONAL UNIFIED PROCESS

Penjelasan RUP

RUP , singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software , suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan merka.

DIAGRAM RATIONAL UNIFIED PROCESS

Proses Kerja RUP

1. Inception
Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan user , dan melakukan perancangan awal perangkat lunak (perancangan arsitektural dan user case). Pada akhir fase ini, prototipe perangakat lunak versi Alpha harus sudah dirilis.

2. Elaboration
Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikan fitur perangkat lunak hingga perilisan prototipe versi Betha dari perangkat lunak.

3.Contruction
Pengimplentasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis beserta dokumentasi perangkata lunak.

4.Transition
Instalasi, deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.

Keuntungan RUP

• Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
• Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
• Mendukung proses pengulangan dalam pengembangan software.
• Memungkinkan adanya penambahan-penambahan pada proses.
• Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang terjadi pada software selama proses pengembangannya.
• Memungkinkan untuk menjalankan test case dengan menggunakan Rational Test

Kekurangan RUP

• Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yang berorientasi objek dengan berfokus pada UML (Unified Modeling Language)

5. TIMEBOXING MODEL

Penjelsan Time boxing

Time boxing adalah proses menunda fitur untuk versi aplikasi di masa mendatang untuk melengkapi versi saat ini sebagai ketepatan waktu.Ketepatan waktu merupakan aspek penting dari RAD, karena tanpa itu ruang lingkup dapat mengancam untuk memperpanjang iterasi pembangunan, sehingga membatasi umpan balik dari klien, meminimalkan manfaat dari pembangunan berulang, dan berpotensi mengembalikan proses kembali ke pendekatan metodologi air terjun.

DIAGRAM TIMEBOXING MODEL

Proses Kerja Timeboxing Model

Timeboxing model menentukan jangka waktu tertentu yang dialokasikan untuk menyelesaikan berbagai macam Proses / Cara Kerja Timeboxing Model. Apabila waktu yang ditentukan tersebut selesai, maka pembangunan sistem akan pindah ke tugas berikutnya, dengan harapan bahwa sebagian besar dari critical work telah berhasil diselesaikan sebelum waktu keseluruhan berakhir.

Kelebihan Timeboxing Model

a. Kecepatan model ini sampai proses pengerjaan dan dapat mempersingkat waktu pengiriman.

b. Model ini cocok untuk mengembangkan projek dengan beberapa fitur dalam waktu singkat.

Kelemahan Timeboxing Model

a. Managemen projek akan menjadi lebih kompleks 

b. Tidak cock untuk projek dimana seluruh pengerjaan tidak dapat dibagi menjadi beberapa iterations.

6. EXTREME PROGRAMMING

 

Pengertian Extreme Programming (XP)

Extreme Programming (XP) merupakan salah satu metode pengembangan software yang termasuk dalam Agile Software Development. XP menggunakan pendekatan object-oriented.

Dalam XP, terdapat 5 nilai yang menjadi pondasi yaitu communication, simplicity, feedback, courage, dan respect. Komunikasi yang efektif antara pengembang perangkat lunak dan pihak-pihak yang terlibat sangatlah penting. Dalam XP, desain dijadikan kebutuhan intermediate. Desain dibuat sesederhana mungkin agar mudah mengimplementasikan code. Disini dapat terjadi perubahan struktur desain atau perubahan source code tanpa mengubah fungsi utamanya (refactoring). Feedback akan diberikan saat peningkatan dan pengimplementasian perangkat lunak.

DIAGRAM EXTREME PROGRAMMING

Proses Extreme Programming

1. Planning. Tahap planning dimulai dengan membuat user stories yang menggambarkan output, fitur, dan fungsi-fungsi dari software yang akan dibuat. User stories tersebut kemudian diberikan bobot seperti prioritas dan dikelompokkan untuk selanjutnya dilakukan proses delivery secara incremental.
2. Design. Design di Extreme Programming mengikuti prinsip Keep It Simple (KIS). Untuk design yang sulit, Extreme Programming akan menggunaan Spike Solution dimana pembuatan design dibuat langsung ke tujuannya. Extreme Programming juga mendukung adanya refactoring dimana software system diubah sedemikian rupa dengan cara mengubah stuktur kode dan menyederhanakannya namun hasil dari kode tidak berubah.
3. Coding. Proses coding pada XP diawali dengan membangun serangkaian unit test. Setelah itu pengembang akan berfokus untuk mengimplementasikannya. Dalam Extreme Programming diperkenalkan istilah Pair Programming dimana proses penulisan program dilakukan secara berpasangan. Dua orang programmer saling bekerjasama di satu komputer untuk menulis program. Dengan melakukan ini akan didapat real-time problem solving dan real-time quality assurance.
4. Testing. Tahap ini dilakukan pengujian kode pada unit test. Dalam Extreme Programming, diperkenalkan XP acceptance test atau biasa disebut customer test. Tes ini dilakukan oleh customer yang berfokus kepada fitur dan fungsi sistem secara keseluruhan. Acceptance test ini berasal dari user stories yang telah diimplementasikan.

Kelebihan Extreme Programming

1. Menjalin komunikasi yang baik dengan klien. (Planning Phase)

2. Menurunkan biaya pengembangan (Implementation Phase)

3. Meningkatkan komunikasi dan sifat saling menghargai antar developer. (Implementation Phase)

4. XP merupkan metodologi yang semi formal. (Planning Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima, atau dengan kata lain eksibel (Maintenance Phase)

Kelemahan Extreme Programming

1. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukanapa yang diperlukan hari itu juga).

2. Selain dari keunggulan dan kelemahan XP yang telah disebutkan diatas, XP juga memiliki keunggulan yang sekaligus menjadi kelemahannya, yaitu XP tidak memiliki dokumentasi formal yang dibuat selama pengembangan.

3. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

7. AGILE PROCESS

Penjelasan Agile methods
Agile Process merupakan sekelompok aktifitas pembangunan perangkat lunak secara iteratif yang menekankan pada aktifitas konstruksi (desain dan koding). Agile Process mengeliminasi sebagian besar waktu untuk melakukan perencanaan sistem dan berusaha sebisa mungkin mematuhi jadwal deliver sistem yang telah dijanjikan. Requirements yang dibutuhkan secara langsung di-drive oleh pelanggan itu sendiri, dan apabila terjadi perubahan terhadap requirements tersebut, pengembang dituntut mampu beradaptasi dengan perubahan yang terjadi.

DIAGRAM AGILE PROCESS

Metode Kerja Agile
Dalam proses pengembangan agile, jika suatu proyek pengembangan software dikerjakan dengan menggunakan metode Agile, maka selama waktu pengerjaannya akan selalu dijumpai proses pengembangan yang dilakukan berulang. Setiap perulangan (iterasi) meliputi berbagai kegiatan yang wajib dilakukan dalam proyek pengembangan software itu sendiri yaitu :  

1. Perencanaan
2. Requirements Analysis : Langkah ini merupakan analisa terhadap kebutuhan sistem. Pengumpulan data dalam tahap ini bisa malakukan sebuah penelitian, wawancara atau study literatur. Seorang sistemanalis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requirment atau bisa dikatakan sebagaidata yang berhubungan dengan keinginan
user dalam pembuatan sistem. Dokumen ini yang akan menjadi acuan sistem analis untuk menterjemahkan ke dalam bahasa pemprogram.
3. Desain : Proses desain akan menerjemahkan syarat kebutuhan kesebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada : struktur data, arsitektur perangkat lunak, representasi interface, dan detail(algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirment. Dokumen yang akan digunakan proggrammer untuk melakukan aktivitas pembuatan sistemnya.
4. Coding : Coding merupakan penerjemahan design dalam bahasa yangbisa dikenali oleh komputer. Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user. Tahapan ini yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem.Dalam artian penggunaan komputer akan dimaksimalkan dalam tahapan ini.
5. Testing :adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki
6. Dokumentasi

Kelebihan dari agile

• Meningkatkan kepuasan kepada klien.

•  Dapat melakukan review pelanggan mengenai software yang dibuat lebih awal.

• Pembangunan system dibuat lebih cepat.

• Mengurangi resiko kegagalan implementasi software dari segi non-teknis.

•  Jika pada saat pembangunan system terjadi kegagalan kerugian dari segi materi relatif kecil.

Kekurangan dari agile

•  Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
•  Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
•  Tidak cocok dalam skala tim yang besar (>20 orang).
•  Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.