RESUME REKAYASA PERANGKAT LUNAK

"SOFTWARE ENGINEERING"

Ian Sommerville

disusun oleh : Willi Kornellius

CHAPTER 1 Introduction

1.1  Rekayasa perangkat lunak adalah disiplin teknik yang berkaitan dengan semua aspek produksi perangkat lunak dari tahap awal spesifikasi sistem hingga pemeliharaan sistem setelah mulai digunakan. Dalam definisi ini,ada dua frase kunci:

-Engineering discipline membuat segala sesuatu bekerja. mereka menerapkan teori, metode, dan alat dimana ini sesuai dan menggunakannya secara selektif.

-All aspects of software production rekayasa perangkat lunak tidak hanya berkaitan dengan proses teknis pengembangan perangkat lunak. ini juga termasuk kegiatan seperti manajemen proyek perangkat lunak dan pengembangan alat, metode dan teori untuk mendukung produksi perangkat lunak.

1.2  Keragaman rekayasa perangkat lunak adalah pendekatan sistematis untuk produksi perangkat lunak itu sendiri dengan memperhitungkan biaya yang murah, jadwal, dan masalah ketergantungan, serta kebutuhan pelanggan dan produsen perangkat lunak. bagaimana pendekatan sistematis ini diimplementasikan sangat bervariasi tergantung pada organisasi yang mengembangkan jenis perangkat lunak tersebut dan orang-orang yang terlibat proses didalamnya. tidak ada metode dan teknik rekayasa perangkat lunak universal yang cocok untuk semua sistem dan semua perusahaan , melainkan beragam RPL metode dan alat telah berkembang selama 50 tahun terakhir.

1.3  Software Engineering and Web perkembangan world wide web memiliki efek mendalam karena pada awalnya informasi yang dapat diakses secara universal sangat minim, sekitar 2000 web mulai berevolusi dan semkain banyak fungsi yang ditambahkan ke browser.ini artinya sistem berbasis web dapat dikembangkan dimana, alih-alih pengguna dengan tujuan khusus antarmuka, sistem ini dapat diakses menggunakan browser web.ini menyebabkan pengembangan beragam produk sistem baru yang memberikan layanan inovatif, diakses melalui web.banyak bisnis telah pindah untuk berinteraksi berbasis web dengan sistem perangkat lunak.

CHAPTER 2 Software processes

2.1  Software process models seperti yang saya jelaskan dibab 1, model proses perangkat lunak adalaha representasi yang disederhanakan oleh proses perangkat lunak. Setiap model proses mewakili proses dari perspektif tertentu, dan dengan demikian hanya memberikan informasi parsial tentang proses itu. Sebagai contoh, model aktivitas proses menunjukkan aktivitas dan urutannya tetapi mungkin tidak ditampilkan peran orang-orang yang terlibat dalam kegiatan ini. Di bagian ini, saya memperkenalkan sejumlah model proses yang sangat umum (kadang-kadang disebut 'paradigma proses') dan menyajikan ini dari perspektif arsitektur. Artinya, kita melihat kerangka kerja proses tetapi tidak rincian kegiatan spesifik.

Model generik ini bukan deskripsi pasti dari proses perangkat lunak. mereka adalah abstraksi dari proses yang dapat digunakan untuk menjelaskan berbagai pendekatan pengembangan perangkat lunak. Anda bisa menganggapnya sebagai kerangka proses yang mungkin diperluas dan disesuaikan untuk menciptakan proses rekayasa perangkat lunak yang lebih spesifik.

2.2  Process activities

Proses perangkat lunak nyata adalah urutan yang saling terkait teknis, kolaboratif, dan

kegiatan manajerial dengan tujuan keseluruhan untuk menentukan, merancang, mengimplementasikan,

dan menguji sistem perangkat lunak. Pengembang perangkat lunak menggunakan berbagai perangkat lunak yang berbeda. Empat kegiatan dasar proses spesifikasi, pengembangan, validasi, dan evolusi diatur secara berbeda dalam proses pengembangan yang berbeda. Di air terjun model, mereka disusun secara berurutan, sedangkan dalam pengembangan tambahan merekadisisipkan. Bagaimana kegiatan ini dilakukan tergantung pada jenis perangkat lunak, orang, dan struktur organisasi yang terlibat. Dalam pemrograman ekstrim, misalnya, spesifikasi tertulis di kartu. Tes dapat dieksekusi dan dikembangkan sebelum program itu sendiri. Evolusi dapat melibatkan restrukturisasi atau refactoring sistem yang substansial.

2.3  Coping with change Perubahan tidak bisa dihindari dalam semua proyek perangkat lunak besar. Persyaratan sistem berubah karena bisnis pengadaan sistem merespons tekanan dan manajemen eksternal sehingga prioritas pun berubah. Ketika teknologi baru tersedia, desain baru dan kemungkinan implementasi muncul. Oleh karena itu model proses perangkat lunak apa pun yang digunakan, itu penting bahwa itu dapat mengakomodasi perubahan pada perangkat lunak yang dikembangkan.

2.4  The Rational unified Process

Proses Bersatu Rasional adalah contoh dari modern

model proses yang telah diturunkan dari pekerjaan di UML dan Unified terkait

Proses Pengembangan Perangkat Lunak.karena ini adalah contoh yang baik dari model proses hybrid.

Ini menyatukan elemen-elemen dari semua model proses generik menggambarkan praktik yang baik dalam spesifikasi dan desain dan mendukung pembuatan prototipe dan pengiriman tambahan.

RUP mengakui bahwa model proses konvensional menghadirkan pandangan tunggal proses. Sebaliknya, RUP biasanya digambarkan dari tiga perspektif:

1.  Perspektif dinamis, yang menunjukkan fase model dari waktu ke waktu.

2.  Perspektif statis, yang menunjukkan aktivitas proses yang diberlakukan.

3.  Perspektif praktik, yang menyarankan praktik yang baik untuk digunakan selama proses.

Sebagian besar deskripsi upaya RUP untuk menggabungkan perspektif statis dan dinamis dalam satu diagram. Saya pikir itu membuat prosesnya lebih sulit dimengerti, jadi saya menggunakan deskripsi terpisah dari masing-masing perspektif ini.

RUP adalah model bertahap yang mengidentifikasi empat fase diskrit dalam perangkat lunak proses. Namun, tidak seperti model air terjun di mana fase disamakan dengan proses kegiatan, fase dalam RUP lebih terkait erat dengan bisnis daripada masalah teknis. menunjukkan fase dalam RUP. Ini adalah:

1.  Pendahuluan Tujuan dari fase awal adalah untuk membangun kasus bisnis untuk sistem. Anda harus mengidentifikasi semua entitas eksternal (orang dan sistem) yang akan berinteraksi dengan sistem dan mendefinisikan interaksi ini. Anda kemudian menggunakan informasi ini untuk menilai kontribusi yang diberikan sistem kepada bisnis. Jika ini kontribusi kecil, maka proyek dapat dibatalkan setelah fase ini.

2.  Elaborasi Tujuan dari fase elaborasi adalah untuk mengembangkan pemahaman dari domain masalah, membangun kerangka kerja arsitektur untuk sistem,mengembangkan rencana proyek, dan mengidentifikasi risiko proyek utama. Setelah menyelesaikan ini fase Anda harus memiliki model persyaratan untuk sistem, yang mungkin merupakan set kasus penggunaan UML, deskripsi arsitektur, dan rencana pengembangan untuk perangkat lunak.

3.  Konstruksi Tahap konstruksi melibatkan desain sistem, pemrograman, dan pengujian. Bagian dari sistem dikembangkan secara paralel dan terintegrasi selama tahap ini. Setelah menyelesaikan fase ini, Anda harus memiliki sistem perangkat lunak yang berfungsi dan dokumentasi terkait yang siap dikirim ke pengguna.

4.  Transisi Fase terakhir dari RUP berkaitan dengan pemindahan sistem dari komunitas pengembangan ke komunitas pengguna dan membuatnya bekerja di lingkungan nyata. Ini adalah sesuatu yang diabaikan dalam sebagian besar proses perangkat lunak model tetapi, pada kenyataannya, kegiatan mahal dan kadang-kadang bermasalah.Setelah menyelesaikan fase ini, Anda harus memiliki sistem perangkat lunak yang terdokumentasi bekerja dengan benar di lingkungan operasional.

CHAPTER 3 Agile software and development

3.1  Agile Methods Pada 1980-an dan awal 1990-an, ada pandangan luas bahwa cara terbaik untuk melakukannya mencapai perangkat lunak yang lebih baik adalah melalui perencanaan proyek yang cermat, kualitas yang diformalkan jaminan, penggunaan metode analisis dan desain yang didukung oleh alat CASE, dan

proses pengembangan perangkat lunak yang terkontrol dan ketat. Pandangan ini berasal dari

komunitas rekayasa perangkat lunak yang bertanggung jawab untuk mengembangkan sistem perangkat lunak besar dan berumur panjang seperti ruang angkasa dan sistem pemerintah.Perangkat lunak ini dikembangkan oleh tim besar yang bekerja untuk perusahaan yang berbeda. Tim sering tersebar secara geografis dan bekerja pada perangkat lunak untuk jangka waktu yang lama. Contoh dari perangkat lunak jenis ini adalah sistem kontrol untuk pesawat terbang modern,yang mungkin membutuhkan waktu hingga 10 tahun dari spesifikasi awal hingga penempatan. Pendekatan plandriven ini melibatkan overhead yang signifikan dalam perencanaan, perancangan, dan dokumentasi sistem. Overhead ini dibenarkan ketika pekerjaan beberapa tim pengembang harus dikoordinasikan, ketika sistem itu sistem kritis, dan ketika banyak berbeda. Metode Agile telah sangat sukses untuk beberapa jenis pengembangan sistem :

1.  Pengembangan produk di mana perusahaan perangkat lunak sedang mengembangkan atau kecil produk berukuran sedang untuk dijual.

2.  Pengembangan sistem khusus dalam suatu organisasi, di mana ada komitmen yang jelas dari pelanggan untuk terlibat dalam proses pengembangan dan di mana tidak banyak aturan dan regulasi eksternal yang memengaruhi perangkat lunak.

3.2  Plan-driven and agile development  

Pendekatan tangkas untuk pengembangan perangkat lunak mempertimbangkan desain dan implementasi. memasukkan kegiatan lain, seperti persyaratan elisitasi dan pengujian, ke dalam desain dan implementasi. Sebaliknya,pendekatan yang digerakkan oleh rencana ke rekayasa perangkat lunak mengidentifikasi tahap-tahap terpisah dalam proses perangkat lunak dengan output yang terkait dengan setiap tahap. Output dari satu tahap adalah digunakan sebagai dasar untuk merencanakan kegiatan proses berikut.Dalam pendekatan yang digerakkan oleh rencana, iterasi terjadi dalam kegiatan dengan dokumen formal yang digunakan untuk berkomunikasi antara tahap proses. Misalnya,persyaratan akan berkembang dan, pada akhirnya, spesifikasi persyaratan akan diproduksi.

Ini kemudian merupakan input untuk proses desain dan implementasi. Dalam pendekatan gesit, iterasi terjadi di seluruh kegiatan. Oleh karena itu, persyaratan dan desainnya adalah dikembangkan bersama, bukan terpisah.

3.3  Extreame Programming

Pemrograman ekstrim melibatkan sejumlah praktik :

1.  Pengembangan tambahan didukung melalui rilis kecil dan sering dari sistem. Persyaratan didasarkan pada cerita atau skenario pelanggan sederhana digunakan sebagai dasar untuk memutuskan fungsionalitas apa yang harus dimasukkan dalam suatu sistem kenaikan.

2.  Keterlibatan pelanggan didukung melalui keterlibatan berkelanjutan dari pelanggan dalam tim pengembangan. Perwakilan pelanggan mengambil bagian dalam pengembangan dan bertanggung jawab untuk menentukan tes penerimaan untuk sistem.

3. didukung melalui pemrograman berpasangan, kepemilikan kolektif atas kode sistem, dan proses pembangunan berkelanjutan yang tidak melibatkan jam kerja yang terlalu lama.

4.  Perubahan dianut melalui rilis sistem reguler ke pelanggan, uji-pertama pengembangan, refactoring untuk menghindari degenerasi kode, dan integrasi berkesinambungan fungsi baru.

5.  Mempertahankan kesederhanaan didukung oleh refactoring konstan yang meningkatkan kode kualitas dan dengan menggunakan desain sederhana yang tidak perlu mengantisipasi masa depan perubahan pada sistem.

3.4  Agile project management  Fitur inovatif Scrum adalah fase sentralnya, yaitu siklus sprint.

Scrum sprint adalah unit perencanaan di mana pekerjaan yang akan dilakukan dinilai, fitur

dipilih untuk pengembangan, dan perangkat lunak diimplementasikan. Di akhir a

sprint, fungsionalitas yang selesai dikirim ke pemangku kepentingan. Karakteristik utama

dari proses ini adalah sebagai berikut:

1.  Sprint adalah panjang tetap, biasanya 2-4 minggu. Mereka sesuai dengan pengembangan rilis sistem di XP.

2.  Titik awal untuk perencanaan adalah jaminan produk, yang merupakan daftar pekerjaan harus dilakukan pada proyek. Selama fase penilaian sprint, ini Ulasan, dan prioritas dan risiko ditugaskan. Pelanggan terlibat erat

dalam proses ini dan dapat memperkenalkan persyaratan atau tugas baru di awal setiap sprint.

3.  Tahap seleksi melibatkan semua tim proyek yang bekerja dengan pelanggan untuk memilih fitur dan fungsi yang akan dikembangkan selama sprint.

4.  Setelah ini disepakati, tim mengorganisir diri untuk mengembangkan perangkat lunak. Pertemuan harian singkat yang melibatkan semua anggota tim diadakan untuk meninjau kemajuan dan jika perlu, memprioritaskan pekerjaan. Selama tahap ini tim diisolasi dari pelanggan dan organisasi, dengan semua komunikasi disalurkan melalui 'master Scrum'. Peran master Scrum adalah untuk melindungi tim pengembangan dari gangguan eksternal. Cara kerjanya dilakukan tergantung pada masalah dan tim. Tidak seperti XP, Scrum tidak menghasilkan saran spesifik tentang cara menulis persyaratan, menguji pengembangan pertama, dll.

Namun, praktik XP ini dapat digunakan jika tim menganggapnya sesuai.

5.  Di akhir sprint, pekerjaan yang dilakukan ditinjau dan disajikan kepada para pemangku kepentingan.

Siklus sprint berikutnya kemudian dimulai. Gagasan di balik Scrum adalah bahwa seluruh tim harus diberdayakan untuk membuat keputusan sehingga istilah 'manajer proyek', telah sengaja dihindari.

CHAPTER 4 Requirements engineering

4.1  Functional and non-functional requirements Persyaratan sistem perangkat lunak sering diklasifikasikan sebagai persyaratan fungsional atau persyaratan nonfungsional:

1.  Persyaratan fungsional :Ini adalah pernyataan layanan yang seharusnya diberikan oleh sistem, bagaimana sistem harus bereaksi terhadap input tertentu, dan bagaimana sistem

harus berperilaku dalam situasi tertentu. Dalam beberapa kasus, persyaratan fungsional juga dapat secara eksplisit menyatakan apa yang seharusnya tidak dilakukan oleh sistem.

2.  Persyaratan non-fungsional : Ini adalah kendala pada layanan atau fungsi ditawarkan oleh sistem.termasuk kendala waktu, kendala pada proses pengembangan, dan kendala yang ditentukan oleh standar. Persyaratan non-fungsional sering berlaku untuk sistem secara keseluruhan, bukan sistem individual fitur atau layanan.

4.2 Requirements specification

Namun, pada level detail diperlukan untuk sepenuhnya menentukan sistem perangkat lunak yang kompleks ,Ada beberapa alasan untuk ini:

1. Anda mungkin harus merancang arsitektur awal sistem untuk membantu menyusunnya sesuai kebutuhan. Persyaratan sistem diatur sesuai dengan berbagai sub-sistem yang membentuk sistem. definisi arsitektur ini sangat penting jika Anda ingin menggunakan kembali perangkat lunak komponen saat menerapkan sistem.

2.  Dalam kebanyakan kasus, sistem harus beroperasi dengan sistem yang ada, yang menjadi kendala desain dan memaksakan persyaratan pada sistem baru.

3.  Penggunaan arsitektur tertentu untuk memenuhi persyaratan non-fungsional yang perlu untuk menyatakan bahwa sistem tersebut aman dan dapat menentukan bahwa desain arsitektur yang sudah disertifikasi dapat digunakan.

4.3  Requirements elicitation and analysis

1.  Penemuan persyaratan. Ini adalah proses berinteraksi dengan para pemangku kepentingan

sistem untuk menemukan persyaratan mereka.nanti di bagian ini.

2.  Klasifikasi dan organisasi persyaratan Kegiatan ini mengambil kumpulan persyaratan yang tidak terstruktur, persyaratan terkait kelompok, dan mengorganisir mereka menjadi kelompok yang koheren.

3.  Prioritas persyaratan dan negosiasi. Tidak dapat dihindari, ketika banyak pemangku kepentingan terlibat, persyaratan akan bertentangan. Kegiatan ini berkaitan dengan

memprioritaskan persyaratan dan menemukan serta menyelesaikan konflik persyaratan

melalui negosiasi.

4.  Spesifikasi persyaratan. Persyaratan didokumentasikan dan dimasukkan ke dalam

putaran spiral berikutnya.

CHAPTER 5 System modeling

Model digunakan selama proses rekayasa persyaratan untuk membantu menurunkan

persyaratan untuk suatu sistem.Anda dapat mengembangkan model dari sistem yang ada dan

sistem yang akan dikembangkan:

1.         Model sistem yang ada digunakan selama rekayasa kebutuhan. Mereka membantu memperjelas apa yang dilakukan sistem yang ada dan dapat digunakan sebagai dasar untuk mendiskusikan kekuatan dan kelemahannya. Ini kemudian mengarah pada persyaratan untuk sistem baru.

2.        Model sistem baru digunakan selama rekayasa untuk membantu menjelaskan persyaratan yang diajukan kepada pemandu kepentingan sistem lainnya. engineer menggunakan model-model ini untuk membahas proposal desain dan untuk mendokumentasikan sistem untuk implementasi. implementasi sistem lengkap atau sebagian dari model sistem.

untuk memperjelas penjelasan tentang system modeling kita harus bisa menjabarkan dalam bentuk diagram , seperti :

1.  Diagram aktivitas, yang menunjukkan aktivitas yang terlibat dalam suatu proses atau dalam data pengolahan.

2.  Gunakan diagram kasus, yang menunjukkan interaksi antara sistem dan lingkungannya.

3. Sequence diagram, yang menunjukkan interaksi antara aktor dan sistem dan

antara komponen sistem.

4.  Class diagram, yang menunjukkan kelas objek dalam sistem dan asosiasi antara kelas-kelas ini.

5.  State diagram, yang menunjukkan bagaimana sistem bereaksi terhadap peristiwa internal dan eksternal.

Biasa ada 3 cara model grafis yang paling umum digunakan :

1.        sebagai sarana memfasilitasi diskusi tentang sistem yang ada atau yang akan diusulkan.

2.        sebagai cara mendokumentasikan sistem yang ada.

3.        sebagai deskripsi sistem terperinci yang dapat digunakan untuk menghasilkan suatu sistem penerapan.

CHAPTER 6 Architectural design

Ada 2 jenis rancangan arsitektur perangkat lunak pada 2 tingkat abstraksi, yaitu arsitektur kecil & besar :

1.        Arsitektur kecil berkaitan dengan arsitektur program individu.

2.        Arsitektur besar biasanya berkaitan dengan sistem perusahaan yang kompleks karna mencakup sistem, program, dan komponen program lainnya.

Ada tiga keuntungan dari mendesain dan mendokumentasikan arsitektur perangkat lunak secara eksplisit :

1.        presentasi tingkat tinggi dari sistem yang dapat digunakan sebagai fokus diskusi oleh berbagi pemangku kepentingan yang berbeda.

2.        Analisis sistem menjadikan arsitektur sistem eksplisit pada tahap awal,keputusan ini memiliki efek,apakah sistem dapat memenuhi persyaratan kritis seperti kinerja,kendalam dan pemeliharaan.

3.        penggunaan kembali skala besar model aristektur sistem karena penggunaanya sangat mudah dikelola dan juga mudah diakses.

Sebagai perancang perangkat lunak, kita dapat menggunakan model arsitektur aplikasi dalam sejumlah cara:

1.        Sebagai titik awal untuk proses desain arsitektur.

2.        Sebagai daftar pemeriksan sistem aplikasi desain yang telah dikembangkan.

3.        Sebagai cara mengatur kerja tim, agar para anggota grup dapat mengimplementasikan berbagai komponen dalam arsitektur.

4.        Sebagai sarana menilai komponen untuk digunakan kembali.

5.        Sebagai kosakata untuk berbicara tentang konsep dalam arsitektur generik untuk membicarakan aplikasi.

CHAPTER 7 Design and implementation

Model konteks sistem dan model interaksi adalah :

1.        Model Konteks sistem adalah model struktural yang menunjukan sistem lain di lingkungan sistem yang sedang dikembangkan.

2.        Model interaksi adalah model dinamis yang menunjukan bagaimana sistem berinteraksi dengan lingkungannya seperti yang digunakan.

Pada tahap awal proses desain, ada 3 model yang sangat berguna untuk menambahkan detail arsitektur :

1.        Subsistem model, yang menunjukan pengelompokan objek yang logis menjadi koheren subsistem. Model subsistem bersifat statis model (Struktural).

2.        Sequence model, yang menunjukan urutan interaksi objek. biasa dipresentasikan menggunakan urutan UML atau diagram kolaborasi. Sequence model adalah model dinamis.

3.        State machine model , yang menunjukan bagaimana objek individu mengubah keadaan respons terhadap peristiwa. ini diwakili dalam UML menggunakan diagram keadaan.sama seperti Sequence model, model ini menggunakan model dinamis.

Oleh karena itu, ada 3 kegiatan manajemen konfigurasi dasar :

1.        Manajemen versi, dimana dukungan diberikan untuk melacak perbedaan versi komponen perangkat lunak. meeka menghentikan satu kode timpa pengembang yang telah dikirimkan ke sistem oleh orang lain.

2.        Integrasi sistem, di mana dukungan diberikan untuk membantu pengembang menentukan apa versi komponen  yang akan digunakan untuk membuat setiap versi sistem.

3.        Pelacakan masalah, dimana dukungan diberikan untuk memungkinkan pengguna melaporkan bug dan masalah lain, dan untuk memungkinkan semua pengembang melihat siapa yang mengerjakan masalah ini dan kapan mereka diperbaiki.

CHAPTER 8 Software testing

SOFTWARE TESTING

Proses pengujian memiliki 2 tujuan berbeda, yaitu :

1.        Untuk menunjukan kepada pengembang dan pelanggan bahwa perangkat lunak memenuhi persyaratan.itu berarti harus ada tes untuk semua fitur sistem, plus kombinasi fitur-fitur yang akan dimasukan kedalam produk.

2.        Untuk menemukan situasi dimana perilaku perangkat lunak salah,tidak diinginkan atau tidak sesuai dengan spesifikasinya. ini adalah konsekuensi dari cacat perangkat lunak. Pengujian ini berkaitan untuk membasmi sistem yang tidak diinginkan seperti crash sistem, perhitungan salah, dan korupsi data.

Biasanya, sistem perangkat lunak komersial harus melalui 3 tahap pengujian yaitu;

1.        Pengujian pengembangan, dimana sistem uji selama pengembangan untuk menemukan bug dan cacat.perancangan dan pemrograman sistem cenderung terlibat dalam proses pengujian.

2.        Uji rilis, dimana tim pengujian terpisah menguji versi lengkap dari sistem sebelum dirlis ke pengguna. Tujuan dari pengujian rilis adalah untuk memeriksa sistem apakah memenuhi persyaratan yang ditentukan.

3.        Pengujian pengguna, dimana pengguna atau pengguna potensial dari suatu sistem menguji sistem di dalam lingkungan nya sendiri.ini semua dilakukan agar dapat diputuskan apakah perangkat lunak dapat dipasarkan, dirilis, dan dijual.

4.        Pengujian penerimaan adalah salah satu jenis pengujian pengguna dimana pelanggan secara resmi menguji sistem untuk memutuskan apakah harus ditrima dari pemasok sistem.

masih banyak testing lain yang harus dilakukan sebelum meluncurkan Software seperti Scenario testing, User testing,Performance testing, Release testing dll.

                                                              

CHAPTER 9 Software Evolution

Pengembangan perangkat lunak tidak berhenti ketika suatu sistem dikirimkan tetapi berlanjut

sepanjang masa hidup sistem. Setelah suatu sistem dikerahkan, pasti harus terjadi perubahan  jika ingin tetap berguna. Perubahan bisnis dan perubahan harapan pengguna menghasilkan persyaratan baru untuk perangkat lunak yang ada. Bagian dari perangkat lunak mungkin harus dimodifikasi untuk memperbaiki kesalahan yang ditemukan dalam operasi, untuk menyesuaikannya perubahan pada platform perangkat keras dan lunaknya, dan untuk meningkatkan kinerjanya atau karakteristik non-fungsional lainnya.

Ada 3 jenis pemeliharaan perangkat lunak :

1.         Perbaikan kesalahan Kesalahan pengkodean biasanya relatif murah untuk dikoreksi; kesalahan desain lebih mahal karena mereka mungkin melibatkan penulisan ulang beberapa komponen program.Kesalahan persyaratan adalah yang paling mahal untuk diperbaiki karena luas perancangan ulang sistem yang mungkin diperlukan.

2.        Adaptasi lingkungan. Jenis pemeliharaan ini diperlukan saat beberapa orang aspek lingkungan sistem seperti perangkat keras, platform yang beroperasi sistem, atau perubahan perangkat lunak pendukung lainnya. Sistem aplikasi harus dimodifikasi untuk beradaptasi untuk mengatasi perubahan lingkungan ini.

3.         Penambahan fungsionalitas Jenis pemeliharaan ini diperlukan saat sistem perubahan persyaratan sebagai respons terhadap perubahan organisasi atau bisnis. Skala perubahan yang diperlukan untuk perangkat lunak seringkali jauh lebih besar daripada jenis perawatan yang lain.Dalam praktiknya, tidak ada yang jelas.

Data yang berguna dalam penilaian kualitas evolusi adalah :

1.         the number of system request Perubahan sistem biasanya merusak struktur sistem dan membuat perubahan lebih lanjut lebih sulit. Semakin tinggi nilai akumulasi ini, semakin rendah kualitas sistem.

2.        the number of user interface faktor penting dalam sistem berbasis formulir di mana setiap formulir dapat dianggap sebagai antarmuka pengguna yang terpisah.semakin besar kemungkinan akan ada inkonsistensi dan redundansi di antarmuka ini.

3.        the volume of data used by system Semakin tinggi volume data (angkafile, ukuran database, dll.), semakin besar kemungkinan akan ada dataketidakkonsistenan yang mengurangi kualitas sistem.

CHAPTER 10 Sociotechnical system

Dalam sistem komputer, perangkat lunak dan perangkat keras saling bergantung.. Tanpa perangkat keras, sistem perangkat lunak hanyalah abstraksi, yang hanya merupakan representasi dari beberapa pengetahuan dan gagasan manusia. Tanpa perangkat lunak, perangkat keras hanyalah seperangkat perangkat elektronik saja. Namun, jika Anda menyatukannya untuk membentuk sistem, Anda membuat mesin yang dapat melakukan perhitungan yang rumit dan memberikan hasil perhitungan ini dengan lingkungannya.

Sistem sosioteknik sangat rumit sehingga tidak mungkin memahaminya secara keseluruhan. Sebaliknya, Anda harus melihatnya layer per layer,berikut lapisan-lapisan yang membentuk sistem sosioteknik :

1.        Lapisan peralatan Lapisan ini terdiri dari perangkat perangkat keras.

2.        Lapisan sistem operasi : Lapisan ini berinteraksi dengan perangkat keras dan menyediakan seperangkat fasilitas umum untuk lapisan perangkat lunak yang lebih tinggi dalam sistem.

3.        Lapisan manajemen komunikasi : data Lapisan ini memperluas fasilitas sistem operasi dan menyediakan antarmuka yang memungkinkan interaksi dengan lebih banyak fungsi yang luas, seperti akses ke sistem jarak jauh, akses ke sistem database, dll. Ini kadang-kadang disebut middleware, seperti di antara aplikasi dan sistem operasi.

4.        Lapisan aplikasi : Lapisan ini memberikan fungsionalitas khusus aplikasi itu wajib. Mungkin ada banyak program aplikasi berbeda di lapisan ini.

5.        Lapisan proses bisnis : Pada tingkat ini, proses bisnis organisasi,yang menggunakan sistem perangkat lunak, didefinisikan dan diberlakukan.

6.        Lapisan organisasi : Lapisan ini mencakup proses strategis tingkat yang lebih tinggi juga sebagai aturan bisnis, kebijakan, dan norma yang harus diikuti ketika menggunakan sistem.

7.        Lapisan sosial : Pada lapisan ini, hukum dan peraturan masyarakat yang mengatur operasi sistem didefinisikan.

Faktor organisasi dari lingkungan sistem yang dapat mempengaruhi persyaratan, desain, dan pengoperasian sistem sosioteknik meliputi :

1.        Perubahan proses Sistem, mungkin memerlukan perubahan pada proses kerja di lingkungan Hidup. Jika demikian, pelatihan tentu akan diperlukan. Jika perubahan signifikan,atau jika mereka melibatkan orang-orang yang kehilangan pekerjaan, ada bahaya bahwa para pengguna akan melakukannya menolak pengenalan sistem.

2.        Perubahan pekerjaan Sistem baru dapat mengurangi keterampilan pengguna di lingkungan atau sebab mereka untuk mengubah cara mereka bekerja. Jika demikian, pengguna dapat secara aktif menolak pengenalan sistem ke dalam organisasi. Desain yang melibatkan manajer harus mengubah cara mereka bekerja agar sesuai dengan sistem komputer.. Manajer harus sadar bahwa status mereka dalam organisasi sedang dikurangi oleh sistem.

3.        Perubahan organisasi Sistem dapat mengubah struktur kekuasaan politik disebuah organisasi. Sebagai contoh, jika suatu organisasi bergantung  pada sistem yang kompleks, mereka yang mengontrol akses ke sistem itu memiliki banyak kekuatan politik.

Sistem sosioteknik memiliki tiga karakteristik yang sangat penting ketika mempertimbangkan keamanan dan ketergantungan:

1.         Mereka memiliki properti yang merupakan properti dari sistem secara keseluruhan,daripada terkait dengan bagian-bagian individual dari sistem. Properti yang muncul tergantung pada komponen sistem dan hubungan di antara mereka.Dengan kompleksitas ini, properti yang muncul hanya dapat dievaluasi begitu sistem telah dirakit. properti adalah Keamanan dan ketergantungan dari sistem yang munculi.

2.        Mereka sering tidak deterministik. Ini berarti ketika disajikan dengan spesifik input, mereka mungkin tidak selalu menghasilkan output yang sama. Perilaku sistem tergantung pada operator manusia dan orang-orang tidak selalu bereaksi dengan cara yang sama. Selanjutnya, penggunaan sistem dapat menciptakan hubungan baru antara komponen sistem dan karenanya mengubah perilaku yang muncul.

3.        Sejauh mana sistem mendukung tujuan organisasi tidak adil tergantung pada sistem itu sendiri. Itu juga tergantung pada stabilitas tujuan-tujuan ini, hubungan dan konflik antara tujuan organisasi dan bagaimana orang dalam organisasi menafsirkan tujuan ini. Manajemen baru dapat menafsirkan kembali tujuan organisasi yang dirancang oleh suatu sistem untuk mendukungnya sistem ‘berhasil’ kemudian dapat dilihat sebagai ‘kegagalan’.

Evolusi sistem, seperti evolusi perangkat lunak ,bisa dibilang mahal karena beberapa alasan:

1.        Perubahan yang diajukan harus dianalisis dengan sangat hati-hati dari sudut pandang bisnis dan teknis. Perubahan harus berkontribusi pada tujuan sistem dan seharusnya tidak hanya termotivasi secara teknis.

2.        Karena subsistem tidak pernah sepenuhnya independen, perubahan pada satu subsistem dapat mempengaruhi kinerja atau perilaku subsistem lainnya.Oleh karena itu perubahan yang diperlukan untuk subsistem ini mungkin diperlukan.

3.        Alasan untuk keputusan desain asli sering tidak dicatat. Mereka yang bertanggung jawab atas evolusi sistem harus mengetahui mengapa keputusan desain tertentu telah dibuat.

4.        Seiring bertambahnya usia sistem, struktur mereka biasanya menjadi rusak karena perubahan biaya untuk membuat perubahan lebih lanjut meningkat.

CHAPTER 11 Depandibility and security

Ketergantungan sistem sekarang biasanya lebih penting daripada fungsionalitas karena alasan berikut:

1.        Kegagalan sistem mempengaruhi banyak orang. Banyak sistem menyertakan fungsionalitas yang jarang digunakan. Jika fungsi ini tidak disertakan dalam sistem, hanya sejumlah kecil pengguna akan terpengaruh. Kegagalan sistem, yang mempengaruhi ketersediaan suatu sistem, berpotensi mempengaruhi semua pengguna sistem..

2.        Pengguna sering menolak sistem yang tidak dapat diandalkan, tidak aman, atau tidak terpercaya. Jika pengguna menemukan bahwa suatu sistem tidak dapat diandalkan atau tidak aman, mereka akan menolak untuk menggunakannya. Selanjutnya,mereka juga dapat menolak untuk membeli atau menggunakan produk lain dari perusahaan yang sama. karena mereka percaya bahwa produk ini juga cenderung tidak dapat diandalkan atau tidak aman.

3.        Biaya kegagalan sistem mungkin sangat besar. Untuk beberapa aplikasi, seperti reaktor sistem kontrol atau sistem navigasi pesawat terbang, biaya kegagalan sistem biasanya persenan-nya lebih besar dari biaya sistem kontrol.

4.        Sistem yang tidak dapat diandalkan dapat menyebabkan hilangnya informasi. Data sangat mahal untuk dikumpulkan dan didapatkan .Biaya untuk memulihkan data yang hilang atau rusak biasanya sangat tinggi.

Beberapa kegagalan dalam sebuah sistem, yaitu :

1.        Kegagalan perangkat keras, perangkat keras sistem mungkin gagal karena kesalahan desainnya, komponen didalamnya gagal karena kesalahan dalam pembuatan, atau karena komponen telah mencapai akhir kehidupan alami mereka.

2.        Kegagalan perangkat lunak, perangkat lunak sistem mungkin gagal karena kesalahan dalam hal spesifikasi, desain, ataupun implementasi.

3.        Kegagalan Operasional, Pengguna mungkin gagal menggunakan atau mengoperasikan sistem dengan benar.

Dalam sistem jaringan apa pun, ada tiga jenis utama ancaman keamanan:

1.        Ancaman terhadap kerahasiaan sistem dan datanya. Ini dapat mengungkapkan informasi kepada orang-orang atau program yang tidak berwenang memiliki akses ke sana.

2.        Ancaman terhadap integritas sistem dan datanya. Ancaman ini dapat merusak perangkat lunak atau datanya.

3.        Ancaman terhadap ketersediaan sistem dan datanya,Ancaman ini dapat membatasi akses ke perangkat lunak atau datanya untuk pengguna yang berwenang.

Kontrol yang mungkin Anda lakukan untuk meningkatkan keamanan sistem :

1.        Strateginya di sini adalah merancang sistem sehingga masalah keamanan dapat dihindari. Misalnya, sistem militer sensitif tidak terhubung ke publik sehingga akses eksternal tidak mungkin terjadi. Anda juga harus menganggap enkripsi sebagai kontrol berdasarkan penghindaran. Setiap akses dianggap tidak sah ke data terenkripsi,berarti itu tidak dapat dibaca oleh penyerang. Dalam prakteknya, itu sangat rumit dan memakan waktu untuk memecahkan enkripsi yang kuat.

2.        Deteksi serangan dan Kontrol netralisasi yang dimaksudkan untuk mendeteksi dan mengusir serangan. Kontrol ini melibatkan termasuk fungsionalitas dalam sistem itu memantau operasinya dan memeriksa pola kegiatan yang tidak biasa. Jika ini terdeteksi, maka tindakan dapat diambil, seperti mematikan bagian dari sistem,membatasi akses ke pengguna tertentu, dll.

3.        Batasan paparan dan pemulihan Kontrol yang mendukung pemulihan dari masalah. Ini dapat berkisar dari strategi dan informasi cadangan otomatis 'Mirroring' ke polis asuransi yang mencakup biaya yang terkait dengan serangan yang berhasil pada sistem.

CHAPTER 12 Dependability and Security specifiation

Kegiatan dalam proses spesifikasi berbasis risiko umum dapat dijabarkan secara spesifik sebagai berikut :

1.        Identifikasi risiko Dalam spesifikasi keselamatan, ini adalah identifikasi bahaya  yang mengidentifikasi bahaya yang dapat mengancam sistem.

2.        Analisis risiko Ini adalah proses penilaian bahaya untuk memutuskan bahaya yang ada atau paling mungkin terjadi. Ini harus diprioritaskan ketika menurunkan persyaratan keselamatan.

3.        Penguraian risiko, Proses ini berkaitan dengan penemuan peristiwa itu. Dalam spesifikasi keselamatan, prosesnya adalah dikenal sebagai analisis bahaya.

4.        Pengurangan risiko Proses ini didasarkan pada hasil analisis bahaya dan mengarah pada identifikasi persyaratan keselamatan. Ini mungkin berkaitan dengan memastikan bahwa suatu bahaya tidak timbul atau menyebabkan kecelakaan atau jika terjadi kecelakaan setidaknya bersifat minimal.

Hazard analysis

adalah proses menemukan akar penyebab bahaya dalam sistem kritis keselamatan. Tujuannya adalah untuk mengetahui cara atau kombinasi cara apa yang bisa dilakukan menyebabkan kegagalan sistem yang menyebabkan bahaya. Untuk melakukan ini, Anda dapat menggunakan pendekatan top down atau bottom-up. Teknik deduktif, top-down, yang cenderung lebih mudah digunakan, mulai dengan bahaya dan bekerja mulai dari kemungkinan kegagalan sistem.

Teknik induktif, bottom-up dimulai dengan kegagalan sistem yang diusulkan dan mengidentifikasi bahaya apa yang mungkin timbul dari kegagalan itu.

Setelah potensi risiko dan akar penyebabnya telah diidentifikasi, Anda kemudian dapat melakukan persyaratan keselamatan yang mengelola risiko dan memastikan bahwa insiden atau kecelakaan tidak terjadi. Ada tiga strategi yang dapat Anda gunakan:

1. Penghindaran bahaya Sistem dirancang agar bahaya tidak terjadi.

2. Deteksi dan penghapusan bahaya Sistem ini dirancang sedemikian rupa sehingga bahaya tersebut terdeteksi dan dinetralkan sebelum mereka mengakibatkan kecelakaan.

3. Batasan kerusakan Sistem dirancang agar konsekuensi kecelakaan dapat diminimalkan.

Ada tiga jenis persyaratan keandala fungsional untuk suatu sistem:

1.         Memeriksa persyaratan, Persyaratan ini mengidentifikasi pemeriksaan pada input ke sistem untuk memastikan bahwa input yang salah atau di luar jangkauan terdeteksi sebelum masuk diproses oleh sistem.

2.        Persyaratan pemulihan, Persyaratan ini ditujukan untuk membantu sistem pulih setelah kegagalan terjadi. Biasanya, persyaratan ini diperhatikan dengan memelihara salinan sistem dan datanya serta menentukan cara memulihkan layanan sistem setelah kegagalan.

3.        Persyaratan redundansi Ini menentukan fitur redundan dari sistem itu memastikan bahwa kegagalan satu komponen tidak menyebabkan hilangnya layanan sepenuhnya.

CHAPTER 13 Depandibility engineering

Dependability engineering berkaitan dengan teknik yang digunakan untuk

meningkatkan ketergantungan sistem kritis dan non kritis. Teknik-teknik ini

mendukung tiga pendekatan pelengkap yang digunakan dalam mengembangkan ketergantungan

perangkat lunak:

1.        Penghindaran kesalahan Desain perangkat lunak dan proses implementasi harus dilakukan pendekatan, untuk pengembangan perangkat lunak yang membantu menghindari desain dan kesalahan pemrograman dan dengan demikian meminimalkan jumlah kesalahan yang mungkin muncul ketika sistem mengeksekusi. Lebih sedikit kesalahan berarti lebih sedikit kemungkinan kegagalan run-time.

2.        Deteksi dan koreksi kesalahan Proses verifikasi dan validasi harus dirancang untuk menemukan dan menghapus kesalahan dalam suatu program, sebelum digunakan untuk penggunaan operasional. Sistem kritis memerlukan verifikasi dan validasi yang sangat luas untuk menemukan kesalahan sebanyak mungkin sebelum penyebaran.

3.        Toleransi kesalahan Sistem dirancang sedemikian rupa sehingga terjadi kesalahan atau sistem yang tidak terduga perilaku selama eksekusi terdeteksi pada saat run-time dan dikelola sedemikian rupa agar kegagalan sistem tidak terjadi. Pendekatan sederhana untuk toleransi kesalahan berdasarkan built-in run-time checking dapat dimasukkan dalam semua sistem. Namun,teknik toleransi kesalahan yang lebih terspesialisasi (seperti penggunaan toleransi kesalahan arsitektur sistem) umumnya hanya digunakan ketika tingkat sistem yang sangat tinggi diperlukan ketersediaan dan keandalan.

Contoh kegiatan yang mungkin termasuk kedalam Dependability engineering :

1.        Requirements reviews untuk memeriksa bahwa persyaratannya sejauh mungkin lengkap dan konsisten.

2.        Requirements management untuk memastikan bahwa perubahan pada persyaratan dikontrol dan bahwa dampak dari perubahan persyaratan yang diusulkan dipahami oleh semua pengembang yang terpengaruh oleh perubahan.

3.        Formal specification dimana model matematika dari perangkat lunak dibuat dan dianalisis, manfaat yang paling penting adalah bahwa ia memaksa analisis yang sangat rinci dari persyaratan sistem.

4.        System modeling dimana desain perangkat lunak secara eksplisit didokumentasikan  sebagai satu set model grafis.

5.        Design and program inspection dimana deskripsi berbeda dari sistem diperiksa oleh orang yang berbeda, biasanya inspeksi didorong dari banyaknya kesalahan umum pada desain dan pemrograman.

6.        Static analysis dimana pemeriksaan otomatis dilakukan pada kode sumber program.ini berguna untuk mencari anomali yang bisa menunjukan kesalahan program atau kelalaian.

7.        Test planning and management  tempat serangkaian uji sistem komprehensif dirancang. Proses pengujian harus dikelola dengan hati-hati untuk menunjukan hal itu. tes ini memberikan cakupan persyaratan sistem telah benar ketika diterapkan dalam proses pengujian.

Para perancang sistem Airbus telah mencoba berbagai cara seperti :

1.        Komputer kontrol penerbangan utama menggunakan prosesor yang berbeda dari sistem kontrol penerbangan sekunder.

2.        Chipset yang digunakan di setiap saluran dalam sistem primer dan sekunder dipasok dari pabrik yang berbeda

3.        Perangkat lunak dalam sistem kontrol penerbangan sekunder hanya menyediakan fungsionalitas kritis, perangkat lunak ini tidak serumit perangkat lunak utama.

4.        Perangkat lunak untuk setiap saluran di sistem primer dan sekunder dikembangkan menggunakan bahasa pemrograman yang berbeda dan oleh tim yang berbeda.

5.        Bahasa pemrograman yang berbeda digunakan dalam sistem sekunder dan primer.

CHAPTER 14 SECURITY ENGINEERING

Pertimbangan risiko dimulai sebelum sistem diputuskan untuk diciptakan dan harus terus berlanjut selama proses pengembangan sistem dan setelah sistem tersebut mulai digunakan. Ada 3 tahap pertimbangan :

1.        Preliminary risk assessment, dilakukan sebelum dirumuskan rancangan dan implementasi sistem, untuk memutuskan tingkat kecanggihan dari sistem keamanan dan biaya yang diperlukan.

2.        Life-cycle risk assessment, dilakukan ketika  pengembangan sistem, hasilnya untuk memutuskan apakah akan ada perubahan sistem keamanan dan bertambahnya requirements.

3.        Operational risk assessment, dilakukan ketika sistem sudah diluncurkan dan digunakan, untuk mengawasi jalannya sistem dan merumuskan perubahan keamanan sistem seperlunya.

Ada 4 jenis ancaman terhadap sistem :

1.        Interception, dimana penyerang bisa mengakses aset suatu sistem.

2.        Interruption, dimana penyerang bisa mematikan suatu bagian dalam sistem.

3.        Modification, dimana penyerang bisa mengubah komponen dalam sistem.

4.        Fabrication, dimana penyerang bisa memasukkan informasi palsu dalam sistem.

Untuk mengakses dan mengubah record penyerang harus menembus tiga lapisan sistem :

1.        Platform-level protection, sistem keamanan dari platform tempat record terletak.

2.        Application level protection, sistem keamanan yang sudah dirancang dalam aplikasi itu sendiri.

3.        Record-level protection, sistem keamanan dari sebuah record spesifik.

Ketahanan sistem dapat dicapai melalui 3 strategi :

1.        Resistance, merancang sebuah fitur kedalam sistem untuk menangkal penyerangan.

2.        Recognition, merancang sebuah fitur untuk mendeteksi penyerangan.

3.        Recovery, merancang sebuah fitur untuk memulihkan sistem setelah diserang.

CHAPTER 15 DEPENDABILITY AND SECURITY ASSURANCE

Jaminan keamanan sistem diperiksa melalui analisis source code dan programnya langsung. Selain analisis, ada beberapa cara lain :

1.        Formal verification, program diperiksa secara matematis apakah sudah memenuhi kebutuhan dan spesifikasinya.

2.        Model checking, digunakan pembuktian teorema untuk mengecek ketidakkonsistenan.

3.        Automated program analysis, pengecekan source code untuk mendeteksi code yang berkemungkinan menimbulkan error.

Reliability testing adalah proses untuk mengukur keandalan sistem. Ada 4 tahapan :

1.        Mempelajari sistem sejenis yang sudah ada untuk memahami implementasi sistemnya.

2.        Membuat sekumpulan data testing yang mencerminkan profil operasional sistem.

3.        Mengetes sistem dengan data diatas dan menghitung jumlah dan tipe eror yang muncul.

4.        Setelah observasi testing dan kegagalan sistem, dirumuskan nilai keandalan software.

Pengkajian keamanan sistem semakin penting karena kebanyakan sistem penting terintegrasi dengan internet sehingga mudah diserang. Ada beberapa cara yang bisa digunakan untuk memeriksa keamanan sistem :

1.        Experience-based testing, analisis terhadap beberapa tipe serangan yang diketahui.

2.        Tiger teams, dimana dibentuk “tiger team” yang ditugaskan menerobos sistem dengan mencari kelemahan sistem, kemudian dibentuk penangkal untuk hasil tes yang didapat.

3.        Tool-based testing, dimana digunakan berbagai tools seperti password checker untuk menganalisis sistem.

Safety and dependability case mengumpulkan semua bukti yang menunjukkan bahwa suatu sistem aman dan dapat diandalkan. Safety cases diperlukan ketika regulator eksternal harus mengesahkan sistem sebelum digunakan.

Safety case biasanya didasarkan pada argumen terstruktur. Argumen keselamatan terstruktur menunjukkan bahwa kondisi berbahaya yang diidentifikasi tidak akan pernah terjadi dengan mempertimbangkan semua jalur program yang mengarah ke kondisi tidak aman, dan menunjukkan bahwa kondisi tersebut tidak dapat terjadi.

CHAPTER 16 SOFTWARE REUSE

Reuse-based software adalah strategi rekayasa software dimana pengembangan dilakukan dengan menggunakan kembali software yang sudah ada. Ada beberapa faktor yang harus dipertimbangkan :

1.        Schedule pengembangan software

2.        Jangka hidup software

3.        Latarbelakang, keahlian, dan pengalaman dari pengembang

4.        Kepentingan software dan requirement non-fungsionalnya

5.        Domain aplikasi

6.        Platform dimana sistem akan diluncurkan

Framework adalah struktur generik yang diperluas untuk menciptakan subsistem atau aplikasi yang lebih spesifik. Framework mendukung fitur generik yang mungkin digunakan dalam semua aplikasi yang satu tipe. Ada 3 kelas framework :

1.        System infrastructure frameworks, mendukung infrastruktur sistem seperti komunikasi, UI, dan compiler.

2.        Middleware integration frameworks, terdiri dari seperangkat standar dan object class terkait yang mendukung komunikasi komponen dan pertukaran informasi.

3.        Enterprise application frameworks, berkaitan dengan domain aplikasi spesifik seperti telekomunikasi atau sistem finansial.

Web Application Frameworks(WAF) adalah model framework terbaru dan paling penting. WAF biasanya menggabungkan satu atau lebih framework khusus yang mendukung fitur aplikasi tertentu. Meskipun setiap framework mencakup fungsi yang sangat berbeda, sebagian besar WAF mendukung fitur berikut :

1.        Security, menyertakan class untuk membantu mengimplementasikan user authentication dan access control untuk memastikan bahwa pengguna hanya dapat mengakses fungsi yang diizinkan dalam sistem.

2.        Dynamic web pages, class disediakan untuk membantu menentukan template halaman web dan mengisi ini secara dinamis dengan data spesifik dari database sistem.

3.        Database support, framework tak menyediakan databse tapi biasanya mengasumsikan bahwa sistem database lain seperti MySQL akan digunakan.

4.        Session management, class untuk mengelola sesi (sejumlah tindakan bersama dengan sistem oleh pengguna) biasanya merupakan bagian dari WAF.

5.        User Interaction, sebagian besar web framework sekarang didukung AJAX, yang memungkinkan lebih banyak halaman web interaktif dibuat.

Software product line adalah seperangkat aplikasi dengan arsitektur dan komponen sama, dengan masing-masing aplikasi khusus untuk mencerminkan persyaratan yang berbeda. Beberapa tipe spesialisasi software product line ialah :

1.        Platform specialization, aplikasi dikembangkan untuk platform yang lain(versi aplikasi tersedia untuk windows, linux, mac os dst).

2.        Environment specialization, aplikasi dikembangkan untuk menangani lingkungan pengoperasian khusus dan perangkat periferal.

3.        Functional specialization, aplikasi dikembangkan untuk pelanggan tertentu yang memiliki requirement berbeda.

4.        Process specialization, sistem ini disesuaikan untuk mengatasi proses tertentu.

Langak-langkah yang ditempuh dalam software product line ialah :

1.        Mendapatkan requirement dari konsumen

2.        Memilih sistem tersedia yang paling memenuhi requirement

3.        Negosiasi ulang requirement

4.        Adaptasi sistem yang ada

5.        Mengirimkan software anakkan terbaru

Commercial-off-the-shelf(COTS) product adalah sistem software yang dapat disesuaikan dengan kebutuhan pengguna tanpa perlu mengubah source code dari sistem tersebut. Metode ini memberikan beberapa keuntungan :

1.        Memungkinkan pengerahan software yang dapat diandalkan dengan lebih cepat

2.        Memungkinkan memperlihatkan fungsi apa saja yang tersedia dan memudahkan penilaian kecocokan software dengan kegunaan.

3.        Beberapa resiko pengembangan software dapat dihindari.

4.        Bisnis dapat memfokuskan ke kegiatan inti mereka tanpa harus mengerahkan banyak sumber daya untuk pengembangan IT.

5.        Seiring perkembangan, update dapat disederhanakan karena ini adalah tanggung jawab vendor produk COTS daripada pelanggan.

CHAPTER 17 COMPONENT BASED SOFTWARE ENGINEERING

Component-based software engineering(CBSE) muncul sebagai pendekatan terhadap pengembangan sistem perangkat lunak berdasarkan penggunaan kembali komponen perangkat lunak. Beberapa hal penting dalam CBSE adalah :

1.        Komponen independen yang sepenuhnya ditentukan oleh interface mereka.

2.        Standar komponen yang memfasilitasi integrasi komponen.

3.        Middleware yang menyediakan dukungan perangkat lunak untuk integrasi komponen.

4.        Proses pengembangan yang diarahkan untuk rekayasa perangkat lunak berbasis komponen

Component adalah unit perangkat lunak independen yang dapat disusun dengan component lain untuk membuat sistem software. Melihat component sebagai penyedia layanan menekankan dua karakteristik penting dari component yang dapat digunakan kembali :

1.        Komponen adalah entitas yang dapat dieksekusi secara independen yang dapat dipahami dari interfacenya.

2.        Layanan yang ditawarkan oleh component disediakan melalui interface dan semua interaksi dilakukan melalui interface tersebut.

Interface ini berisi layanan yang disediakan component dan layanan yang diperlukan component untuk beroperasi dengan benar :

1.        Interface ‘provide’ mendefinisikan layanan yang disediakan oleh component.

2.        Interface ‘require’ menentukan layanan apa yang harus disediakan oleh component lain dalam sistem jika component ingin beroperasi dengan benar.

CBSE processes adalah proses software yang mendukung CBSE. Mereka memperhitungkan kemungkinan penggunaan kembali dan berbagai aktivitas proses yang terlibat dalam mengembangkan dan menggunakan component yang dapat digunakan kembali. Ada 2 tipe proses CBSE :

1.        Development for reuse, pengembangan component atau layanan yang akan digunakan kembali dalam aplikasi lain.

2.        Development with reuse, proses mengembangkan aplikasi baru menggunakan component dan layanan yang sudah ada.

Component composistion adalah proses mengintegrasikan komponen satu sama lain, dan dengan 'glue code' yang ditulis khusus untuk membuat sistem atau komponen lain. Namun, ketika component dikembangkan secara independen untuk digunakan kembali, akan sering dihadapkan dengan ketidakcocokan interface. Ini berarti bahwa interface component yang ingin dbuat tidak sama. Tiga jenis ketidakcocokan dapat terjadi :

1.        Parameter incompability, ketidakcocokan pada jenis parameter atau jumlah parameternya.

2.        Operation incompability, ketidakcocokan nama operasi pada sisi interface.

3.        Operation incompleteness, component dalam interface ‘provide’ merupakan bagian dari interface ‘require’.

CHAPTER 18 DISTRIBUTED SOFTWARE ENGINEERING

Sistem distribusi adalah sistem yang melibatkan beberapa komputer, berbeda dengan sistem terpusat di mana semua komponen sistem dijalankan pada satu komputer. Berikut keuntungan menggunakan pendekatan terdistribusi untuk pengembangan sistem :

1.        Resource sharing, memperbolehkan berbagi hardware dan software seperti disk, file, printer, dan compiler.

2.        Openness, sistem yang terbuka memperbolehkan peralatan dan software dari vendor lain untuk digabungkan.

3.        Concurrency, beberapa proses dapat dijalankan bersamaan.

4.        Scalability, skalanya bisa diatur karena kemampuan sistem dapat ditingkatkan dengan menambahkan sumber daya baru untuk memenuhi kebutuhan baru.

5.        Fault tolerance, karena sistemnya merupakan resource sharing maka tidak akan terlalu berdampak buruk apabila terjadi error selama terjalin dengan sistem lainnya.

Sistem client-server adalah sistem terdistribusi di mana sistem terstruktur menjadi beberapa lapisan, dengan lapisan presentasi diimplementasikan pada komputer klien. Server menyediakan layanan pengelolaan data, aplikasi, dan basis data.

Perancang sistem terdistribusi harus mengatur desain sistem mereka untuk menemukan keseimbangan antara kinerja, keandalan, keamanan, dan pengelolaan sistem. Ada 5 gaya arsitektural sistem :

1.        Master-slave architecture, untuk sistem real-time di mana waktu respons interaksi yang pasti diperlukan.

2.        Two-tier client-server architecture, untuk sistem klien-server sederhana, dan dalam situasi di mana penting untuk memusatkan sistem untuk alasan keamanan

3.        Multitier client-server architecture, ketika ada volume transaksi yang tinggi untuk diproses oleh server.

4.        Distributed component architecture, ketika sumber daya dari sistem dan basis data yang berbeda perlu digabungkan.

5.        Peer-to-peer architecture, ketika klien bertukar informasi yang disimpan secara lokal dan peran server adalah untuk memperkenalkan klien satu sama lain

CHAPTER 19 SERVICE ORIENTED ARCHITECTURE

Service-oriented architecture (SOA) adalah cara mengembangkan sistem terdistribusi di mana komponen sistem adalah layanan yang berdiri sendiri, dijalankan pada komputer yang terdistribusi secara geografis. Standar utama untuk SOA web adalah sebagai berikut:

1.        SOAP, standar pertukaran pesan yang mendukung komunikasi antara layanan. Ini mendefinisikan komponen-komponen penting dan opsional dari pesan yang dilewati antara layanan.

2.        Web Service Definition Language (WSDL) adalah standar untuk definisi layanan interface. Ini menetapkan bagaimana operasi layanan (nama operasi, parameter, dan jenisnya) dan binding layanan harus didefinisikan.

3.        WS-BPEL, standar untuk bahasa alur kerja yang digunakan untuk mendefinisikan program proses yang melibatkan beberapa layanan berbeda.

Standar SOA utama didukung oleh serangkaian standar pendukung yang fokus pada aspek SOA yang lebih khusus. Beberapa standar ini meliputi :

1.        WS-Reliable Messaging, standar untuk pertukaran pesan yang memastikan pesan akan dikirimkan hanya sekali dan sekali saja.

2.        WS-Security, serangkaian standar yang mendukung keamanan layanan web termasuk standar yang menetapkan definisi kebijakan dan standar keamanan yang menutupi penggunaan tanda tangan digital.

3.        WS-Adressing,  yang mendefinisikan bagaimana informasi alamat harus diwakili dalam pesan SOAP.

4.        WS-Transaction, yang mendefinisikan bagaimana transaksi lintas layanan yang didistribusikan harus dikoordinasikan.

Service engineering adalah proses pengembangan layanan untuk digunakan kembali dalam aplikasi berorientasi layanan. Ada 3 tahapan dalam service engineering :

1.        Service candidate identification, mengidentifikasi service yang mungkin digunakan dan merumuskan requirement servicenya.

2.        Service design, mendesain interface logical dan WSDL servicenya.

3.        Service implementation and deployment, mengimplementasikan serta membuat service beroperasi.

Software development with services didasarkan pada gagasan bahwa Anda menyusun dan mengonfigurasi layanan untuk membuat layanan gabungan baru. Ada 6 tahap utama dalam proses Software development with services :

1.        Formulate outline workflow, gunakan requirement untuk service komposit sebagai dasar untuk menciptakan desain service 'ideal'.

2.        Discover services, mencari service dalam register atau katalog, siapa yang membuat servie itu, dan aoa yang disediakan service tersebut.

3.        Select possible services, dari semua service yang dicari dipilih yang paling sesuai dengan workflow dan memenuhi requirement.

4.        Refine workflow, menyempurnakan workflow yang sebelumnya abstrak dengan memperjelas dan menambah atau mengurangi kegiatan.

5.        Create workflow program, workflow yang abstrak tadi diubah menjadi program executable dan interface servicenya dirumuskan.

6.        Test completed service or application, mengetes service dan memastikan service beroperasi dengan benar dan mencari bug atau error apabila ada.

CHAPTER 20 EMBEDDED SOFTWARE

Embedded Software adalah bagian yang tertanam dalam hardware/software dan bereaksi terhadap peristiwa di lingkungannya. Embedded software biasanya adalah sistem berbasis real-time. Perilaku sistem real-time bisa ditentukan dari ‘rangsangan’ yang diterima, respons terhadapnya, dan kapan respons tersebut harus dilakukan. Rangsangan ini terbagi menjadi 2 :

1.        Periodic stimuli, dimana rangsangan terjadi dalam jangka waktu terprediksi, seperti setiap 2 detik.

2.        Aperiodic stimuli, tidak terjadi secara beraturan dan biasa dilakukan menggunakan mekanisme komputer.

Sistem real-time harus merespons rangsangan yang terjadi pada waktu yang berbeda. Maka harus mengatur arsitektur sistem sehingga, segera setelah stimulus diterima, kontrol ditransfer ke penanganan yang benar. Dalam mendesain proses software real-time dilakukan aktivitas berikut :

1.        Platform selection, memilih platform untuk eksekusi sistem.

2.        Stimuli/response identification, menentukan rangsangan yang diterima sistem dan respons yang sesuai.

3.        Timing analysis, menentukan jangka waktu untuk proses rangsangan dan responsnya.

4.        Process design, menyatukan rangsangan dan respons dalam sejumlah proses bersamaan.

5.        Algorithm design, mendesain algoritma yang diperlukan untuk menjalankan komputasi.

6.        Data design, merumuskan data yang ditukar antar proses dan peristiwa yang memicu pertukaran informasi, serta mendesain struktur data untuk mengelola pertukaran informasi tersebut.

7.        Process scheduling,  mendesain sistem penjadwalan untuk memastikan setiap proses berjalan tepat waktu.

CHAPTER 21 ASPECT ORIENTED SOFTWARE ENGINEERING

Aspect oriented software engineering adalah pendekatan pengembangan software yang didasari konsep abstraksi yang disebut ‘aspect’ yang mengimplementasikan fungsionalitas sistem yang mungkin diperlukan di beberapa tempat berbeda dalam suatu program.

Separation of concern berarti penyusunan software sehingga tiap elemen dalam program hanya melakukan satu kegiatan saja. Ada beberapa tipe concern :

1.        Functional concerns, terkait fungsionalitas spesifik yang akan dimasukkan dalam sistem.

2.        Quality of service concerns, terkait perilaku non-fungsional dari suatu sistem.

3.        Policy concerns, terkait keseluruhan kebijakan yang mengatur penggunaan sistem.

4.        System concerns, terkait atribut-atribut dari sistem sebagai suatu kesatuan.

5.        Organizational concerns, terkait tujuan dan prioritas dari suatu organisasi.

Ada beberapa extension yang berasal dari concern-concern tadi, yakni :

1.        Secondary functional extensions, menambahkan kapabilitas dari fungsi yang disediakan.

2.        Policy extensions, menambahkan kapabilitas fungsionalitas yang mendukung kebijakan organisasi.

3.        QoS extensions, menambahkan kapabilitas untuk mencapai quality of service yang sudah ditentukan sistem.

4.        Infrastucture extensions, menambahkan kapabilitas untuk mendukung implementasi sistem di suatu platform tertentu.

CHAPTER 22 PROJECT MANAGEMENT

Project perlu dikelola karena software engineering profesional selalu tunduk pada anggaran organisasi dan kendala jadwal. Tugas manajer project adalah memastikan bahwa project perangkat lunak memenuhi dan mengatasi kendala ini serta memberikan perangkat lunak berkualitas tinggi. Beberapa tujuan penting dalam project adalah :

1.        Mengirimkan software pada pelanggan pada waktu yang ditentukan.

2.        Menjaga biaya keseluruhan dibawah anggaran.

3.        Mengirimkan software yang memenuhi harapan pelanggan.

4.        Menjaga tim pengembang yang baik dan senang.

Manajer project biasa bertanggungjawab untuk kegiatan berikut :

1.        Project planning, merencanakan, memperkirakan dan menjadwalkan project, serta menugaskan orang-orang pekerjaan tertentu untuk menyelesaikan project.

2.        Reporting, melaporkan kemajuan dari project kepada pelanggan.

3.        Risk management, menilai, memonitor, dan mengambil tindakan terhadap resiko-resiko yang memengaruhi project.

4.        People management, mengelola tim pengembang yang akan mengerjakan project.

5.        Proposal writing, menuliskan proposal untuk mendapatkan kontrak persetujuan project.

Dalam pengelolaan resiko, ada beberapa hal yang harus diketahui. Pertama-tama, ada 3 kategori resiko :

1.        Project risks, resiko yang mempengaruhi sumber daya atau schedule project.

2.        Product risks, resiko yang memengaruhi kualitas atau performa software yang dikembangkan.

3.        Business risks, resiko yang memengaruhi organisasi yang mengembangkan software.

Kemudian, ada tahapan mengelola resiko, yakni :

1.        Risk identification, menemukan resiko terhadap project, produk, dan bisnis yang bisa terjadi.

2.        Risk analysis, analisis kemungkinan resiko terjadi dan dampak dari resiko tersebut.

3.        Risk planning, merencanakan cara mengusut resiko, baik dengan menghindari resiko tersebut atau meminimalisir dampak resiko tersebut.

4.        Risk assessing, menilai resiko secara reguler dan merencanakan penanganan resiko kedepannya.

Terakhir, dalam people management ada 4 faktor penting yang harus diingat :

1.        Consistency, setiap anggota project harus diperlakukan secara sama dan konsisten.

2.        Respect, tiap anggota memiliki perbedaan keahlian dan seorang manajer harus menghargai perbedaan tersebut.

3.        Inclusion, mengikutsertakan setiap anggota, sekecil apapun keahliannya.

4.        Honesty, bersikap jujur atas apa yang berjalan dengan baik dan buruk dalam project, serta mengenai pengetahuan teknis manajer dan meminta pendapat dari anggota yang lebih paham.

CHAPTER 23 PROJECT PLANNING

 Project planning terjadi pada 3 tahap project :

1.        Saat proposal project, dibutuhkan rencana untuk menentukan apakah resource yang ada memenuhi requirement dan menentukan harga untuk pelanggan.

2.        Saat startup project, menentukan siapa yang akan mengerjakan project, bagaimana pembagian pekerjaan project, bagaimana resource akan digunakan dalam project, dan lain-lain.

3.        Selama project berjalan, mengubah rencana project seiring perkembangan dari project, baik perkembangan bagus atau buruk.

Project scheduling adalah proses memutuskan bagaimana pekerjaan dalam suatu project akan dikelola sebagai tugas yang terpisah, dan kapan dan bagaimana tugas ini akan dilaksanakan. Ada 2 representasi schedule project yang sering digunakan :

1.        Bar charts, berdasarkan tanggal, menunjukkan siapa yang mengerjakan suatu pekerjaan, perkiraan waktu yang berlalu, dan kapan pekerjaan dimulai dan selesai.

2.        Activity networks, merupakan diagram jaringan yang menunjukkan ketergantungan antar aktivitas yang membentuk sebuah project.

Project activities adalah elemen dasar project planning. Setiap aktivitas memiliki :

1.        Durasi dalam harian atau bulanan kalendar.

2.        Perkiraan kinerja, mencerminkan jumlah orang yang diperlukan untuk menyelesaikan aktivitas dalam harian atau bulanan.

3.        Deadline dimana aktivitas sudah harus diselesaikan.

4.        Titik akhir yang menunjukkan hasil dari penyelesaian aktivitas.

CHAPTER 24 SOFTWARE QUALITY MANAGEMENT

Software quality management berkaitan dengan memastikan bahwa software hanya memiliki sedikit error dan mencapai standar yang disyaratkan dalam pemeliharaan, keandalan, portabilitas, dan seterusnya. Ini termasuk mendefinisikan standar untuk proses dan produk dan menetapkan proses untuk memeriksa bahwa standar-standar ini telah diikuti.

Software standards penting untuk jaminan kualitas karena mereka mewakili identifikasi 'praktik terbaik'. Saat mengembangkan software, standar memberikan fondasi yang kuat untuk software berkualitas tinggi.

Diperlukan pendokumentasian serangkaian prosedur jaminan kualitas dalam manual kualitas organisasi. Ini mungkin didasarkan pada model generik untuk manual kualitas yang disarankan dalam standar ISO 9001.

Ulasan software process  melibatkan tim  yang mengecekdiikuti. Ulasan adalah teknik yang paling banyak digunakan untuk menilai kualitas.

Dalam inspeksi program atau peer review, tim kecil secara sistematis memeriksa kode. Mereka membaca kode secara detail dan mencari kemungkinan kesalahan dan kelalaian. Masalah yang terdeteksi dibahas pada pertemuan tinjauan kode.

Pengukuran perangkat lunak dapat digunakan untuk mengumpulkan data kuantitatif tentang perangkat lunak dan proses softwarenya. Anda mungkin dapat menggunakan nilai-nilai metrik perangkat lunak yang dikumpulkan untuk membuat konferensi tentang kualitas produk dan proses.

Product quality metrics sangat berguna untuk menyoroti komponen anomali yang mungkin memiliki masalah kualitas. Komponen-komponen ini kemudian harus dianalisis secara lebih rinci.

CHAPTER 25 CONFIGURATION MANAGEMENT

Configuration management sebuah produk sistem software meliputi 4 aktivitas yang berkaitan :

1.        Change management, melacak permintaan untuk perubahan ke software dari pelanggan dan pengembang, menghitung biaya dan dampak dari perubahan ini, dan memutuskan apakah dan kapan perubahan harus dilaksanakan.

2.        Version management, melacak banyaknya versi component sistem dan memastikan perubahan terhadap komponen dari pengembang yang berbeda tidak akan mengganggu satu sama lain.

3.        System building, proses menyusun component, data, dan library program, lalu mengcompile dan menghubungkannya untuk menciptakan sebuah sistem executable.

4.        Release management, menyiapkan software untuk release ke pasaran dan melacak versi sistem yang direlease untuk penggunaan konsumen.

Ada beberapa faktor yang harus dipertimbangkan sebelum menyetujui sebuah perubahan :

1.        Konsekuensi apabila perubahan tidak dilakukan

2.        Keuntungan dari perubahan

3.        Jumlah user yang dipengaruhi perubahan

4.        Biaya yang diperlukan untuk melakukan perubahan

5.        Siklus release produk

Sistem version management biasanya menyediakan fitur berikut :

1.        Version and release identification, versi-versi yang dikelola dikenakan pengenal ketika disubmit ke sistem.

2.        Storage management, sistem menyimpan daftar perbedaan antara satu versi dan lainnya.

3.        Change history recording, perubahan terhadap code dari sistem atau componentnya akan direcord dan masuk kedalam daftar.

4.        Independent development, melacak component yang sedang dipakai untuk editing dan memastikan perubahan terhadap suatu component dari pengembang yang lain tidak akan saling menganggu.

5.        Project support, mendukung pengembangan sekumpulan project yang memakai component yang sama.

System building adalah proses menyatukan komponen sistem menjadi sebuah program executable untuk dioperasikan pada sistem komputer target.

Software harus sering dibuat ulang dan dites segera setalh versi terbaru sudah diciptakan. Ini supaya bug dan permasalahan lain pada build yang lama lebih mudah dideteksi.

System release meliputi executable code, file data, file configurasi, dan dokumentasi. Release management meliputi mengambil keputusan pada tanggal rilis sistem, menyiapkan semua informasi untuk distribusi, dan mendokumentasi setiap release sistem baru.

CHAPTER 26 PROCESS IMPROVEMENT

Ada 2 pendekatan untuk perkembangan dan perubahan sistem :

1.        Process maturity approach, berfokus pada peningkatan proses dan manajemen project dan memperkenalkan praktik software engineering yang baik dalam suatu organisasi.

2.        Agile approach, berfokus pada pengembangan berulang dan pengurangan overhead dalam proses software.

Proses dari process improvement adalah sebuah siklus sirkular, yang berupa 3 subproses :

1.        Process measurement, atribut dari project atau produk yang sedang dikembangkan diukur.

2.        Process analysis, proses saat ini dinilai, dan kelemahan dari proses diidentifikasi.

3.        Process change, perubahan proses diusulkan untuk mengatasi beberapa kelemahan proses yang diidentifikasi.

Process measurement adalah data kuantitatif tentang proses software. Process measurement dapat digunakan untuk menilai apakah efisiensi proses telah ditingkatkan. Ada 3 tipe process metrics yang bisa didapat :

1.        Waktu yang dibutuhkan supaya proses diselesaikan

2.        Resource yang dibutuhkan untuk sebuah proses tertentu

3.        Jumlah kejadian suatu peristiwa tertentu

Process analysis adalah pembelajaran proses untuk membantu memahami karakteristiknya dan bagaimana proses tersebut dipraktekkan. Ada 3 tujuan dalam process analysis :

1.        Memahami aktivitas yang terlibat dalam proses dan relasi antar aktivitas.

2.        Memahami relasi antara aktivitas proses dan ukuran yang diperoleh dalam process measurements.

3.        Untuk mengaitkan proses yang sudah  dianalisis dengan proses yang dapat dibandingkan di tempat lain dalam organisasi, atau dengan proses yang diidealkan dari jenis yang sama.

Teknik yang paling sering digunakan dalam analisis adalah :

1.        Questionnaire and interviews, para insinyur dan manajer yang mengerjakan project ditanyai tentang apa yang sebenarnya dikerjakan dalam project.

2.        Ethnographic studies, di mana peserta proses diamati saat mereka bekerja, dapat digunakan untuk memahami sifat pengembangan software sebagai aktivitas manusia.

Process change meliputi membuat modifikasi terhadap proses yang telah ada. Process change harus bertujuan untuk meningkatkan kualitas dari proses. Ada 5 tahapan process change :

1.        Improvement identification, menggunakan hasil analisis proses untuk mengidentifikasi cara untuk mengatasi masalah kualitas, hambatan, atau inefisiensi biaya yang telah diidentifikasi selama analisis proses.

2.        Improvement prioritization, menilai kemungkinan perubahan pada proses, dan memprioritaskannya untuk implementasi. Ketika banyak kemungkinan perubahan telah diidentifikasi, biasanya tidak mungkin untuk memperkenalkan semuanya sekaligus, dan harus diputuskan mana yang paling penting.

3.        Process change introduction, menempatkan prosedur baru, metode, dan alat pada tempatnya dan mengintegrasikannya dengan kegiatan proses lainnya.

4.        Process training, tanpa pelatihan tidak mungkin mendapatkan manfaat penuh dari perubahan proses. Para insinyur yang terlibat perlu memahami perubahan yang telah diusulkan dan bagaimana melakukan proses yang baru dan berubah

5.        Change tuning, di mana masalah kecil dapat ditemukan, dan modifikasi pada proses dapat diusulkan dan diperkenalkan.