SOFTWARE ENGINEERING

SOFTWARE ENGINEERING
10th edition
Ian Sommerville

Disusun oleh :

Cristian Very                20180801201

Chapter 1

Introduction to Software Engineering

Professional software development

Banyak orang menulis program. Orang dalam bisnis menulis program spreadsheet ke

menyederhanakan pekerjaan mereka; ilmuwan dan insinyur menulis program untuk memproses data eksperimental mereka; penggemar menulis program untuk minat dan kesenangan mereka sendiri.

Namun, sebagian besar pengembangan perangkat lunak adalah aktivitas profesional di mana perangkat lunak berada

dikembangkan untuk tujuan bisnis, untuk dimasukkan dalam perangkat lain, atau sebagai produk perangkat lunak seperti sistem informasi dan sistem desain yang dibantu komputer. Perbedaan utama adalah bahwa perangkat lunak profesional dimaksudkan untuk digunakan oleh seseorang selain dari itu

pengembang dan tim daripada individu biasanya mengembangkan perangkat lunak. ini

dipelihara dan diubah sepanjang hidupnya.


Banyak orang berpikir bahwa perangkat lunak hanyalah kata lain untuk program komputer. Namun, ketika kita berbicara tentang rekayasa perangkat lunak, perangkat lunak tidak hanya program itu sendiri tetapi juga semua dokumentasi terkait, perpustakaan, situs web pendukung, dan data konfigurasi yang diperlukan untuk menjadikan program ini berguna. Sistem perangkat lunak yang dikembangkan secara profesional seringkali lebih dari satu program. Sebuah sistem dapat terdiri dari beberapa program dan file 

Ini adalah salah satu perbedaan penting antara pengembangan perangkat lunak profesional dan amatir. Jika Anda menulis program untuk diri sendiri, tidak ada orang lain yang akan menggunakannya

1. Produk generik Ini adalah sistem yang berdiri sendiri yang diproduksi oleh

organisasi pengembangan dan dijual di pasar terbuka untuk setiap pelanggan yang

mampu membelinya. Contoh dari jenis produk ini termasuk aplikasi untuk seluler

perangkat, perangkat lunak untuk PC seperti database, pengolah kata, paket gambar,

dan alat manajemen proyek. Perangkat lunak semacam ini juga termasuk "vertikal"

2. Perangkat lunak yang disesuaikan (atau dipesan lebih dahulu) Ini adalah sistem yang ditugaskan oleh

dan dikembangkan untuk pelanggan tertentu. Seorang kontraktor perangkat lunak mendesain dan

mengimplementasikan perangkat lunak terutama untuk pelanggan itu. Contoh jenis ini

perangkat lunak termasuk sistem kontrol untuk perangkat elektronik, sistem yang ditulis untuk

mendukung proses bisnis tertentu, dan sistem kontrol lalu lintas udara.

.

1.1.2 Software engineering

Rekayasa perangkat lunak adalah disiplin teknik yang berkaitan dengan semua aspek produksi perangkat lunak dari tahap awal spesifikasi sistem hingga memelihara sistem setelah mulai digunakan

pastikan bahwa pengguna jahat tidak dapat berhasil menyerang perangkat lunak kami dan itu

keamanan informasi tetap terjaga.

4. Skala Perangkat Lunak harus dikembangkan di berbagai skala, dari

sistem tertanam sangat kecil di perangkat portabel atau yang dapat dipakai hingga

Skala Internet, sistem berbasis cloud yang melayani komunitas global.

1.1.3 Software engineering diversity

Rekayasa perangkat lunak adalah pendekatan sistematis untuk produksi perangkat lunak yang memperhitungkan masalah biaya praktis, jadwal, dan ketergantungan, seperti serta kebutuhan pelanggan dan produsen perangkat lunak.

1.1.4 Internet software engineering

Perkembangan Internet dan World Wide Web telah mendalam

berpengaruh pada semua hidup kita. Awalnya, web terutama diakses secara universal

penyimpanan informasi, dan itu berdampak kecil pada sistem perangkat lunak.

1.2 Software engineering ethics

Seperti disiplin teknik lainnya, rekayasa perangkat lunak dilakukan dalam

kerangka kerja sosial dan hukum yang membatasi kebebasan orang yang bekerja di bidang itu. Sebagai

seorang insinyur perangkat lunak, Anda harus menerima bahwa pekerjaan Anda melibatkan tanggung jawab yang lebih luas

dari sekadar penerapan keterampilan teknis.

Tak perlu dikatakan bahwa Anda harus menegakkan standar kejujuran dan normal

integritas. Anda sebaiknya tidak menggunakan keterampilan dan kemampuan Anda untuk berperilaku dengan cara yang tidak jujur ​​atau

dengan cara yang akan membawa keburukan pada profesi rekayasa perangkat lunak. Namun,

ada area di mana standar perilaku yang dapat diterima tidak terikat oleh hukum tetapi oleh

gagasan tanggung jawab profesional yang lebih lemah. Beberapa di antaranya adalah:

1. Kerahasiaan Anda biasanya harus menghormati kerahasiaan majikan atau klien Anda terlepas dari apakah perjanjian kerahasiaan formal atau tidak telah ditandatangani.

2. Kompetensi Anda tidak boleh salah menggambarkan tingkat kompetensi Anda. Kamu harus

tidak secara sadar menerima pekerjaan yang berada di luar kompetensi Anda.

3. Hak kekayaan intelektual Anda harus mengetahui hukum setempat yang mengatur

penggunaan kekayaan intelektual seperti paten dan hak cipta. Kamu harus hati-hati

untuk memastikan bahwa kekayaan intelektual pengusaha dan klien dilindungi.

4. Penyalahgunaan komputer Anda tidak boleh menggunakan keterampilan teknis Anda untuk menyalahgunakan komputer orang lain. Penyalahgunaan komputer berkisar dari hal yang relatif sepele (bermain game

pada mesin majikan) hingga sangat serius (penyebaran virus atau

malware lain).

1.3 Case Studies

Untuk menggambarkan konsep rekayasa perangkat lunak, saya menggunakan contoh dari empat jenis berbeda

sistem. Saya sengaja tidak menggunakan studi kasus tunggal, sebagai salah satu pesan utama

dalam buku ini adalah bahwa praktik rekayasa perangkat lunak tergantung pada jenis system

diproduksi. Karena itu saya memilih contoh yang tepat ketika membahas konsep-konsep seperti keselamatan dan ketergantungan, pemodelan sistem, penggunaan kembali, dll.

Jenis sistem yang saya gunakan sebagai studi kasus adalah:

1. Sistem tertanam Ini adalah sistem di mana perangkat lunak mengontrol beberapa perangkat keras dan tertanam dalam perangkat itu. Masalah dalam sistem embedded biasanya mencakup ukuran fisik, daya tanggap, dan manajemen daya, dll

contoh sistem tertanam yang saya gunakan adalah sistem perangkat lunak untuk mengontrol sebuah

pompa insulin untuk orang yang menderita diabetes.

2. Sistem informasi Tujuan utama dari sistem jenis ini adalah untuk mengelola

dan memberikan akses ke database informasi. Masalah dalam sistem informasi

termasuk keamanan, kemudahan penggunaan, privasi, dan menjaga integritas data. Contoh

dari sistem informasi yang digunakan adalah sistem rekam medis.

3. Sistem pengumpulan data berbasis sensor Ini adalah sistem yang tujuan utamanya

adalah untuk mengumpulkan data dari satu set sensor dan untuk memproses data dengan cara tertentu.

Persyaratan utama dari sistem tersebut adalah keandalan, bahkan dalam kondisi lingkungan yang tidak bersahabat, dan pemeliharaan. Contoh dari sistem pengumpulan data

yang saya gunakan adalah stasiun cuaca hutan belantara.

4. Lingkungan pendukung. Ini adalah kumpulan alat perangkat lunak terintegrasi

digunakan untuk mendukung beberapa jenis kegiatan. Lingkungan pemrograman, seperti

Eclipse (Vogel 2012) akan menjadi jenis lingkungan yang paling akrab bagi pembaca

buku ini. Saya menggambarkan contoh di sini tentang lingkungan pembelajaran digital itu

digunakan untuk mendukung pembelajaran siswa di sekolah.

Chapter 2

Software processes

Software process models

model proses perangkat lunak (kadang-kadang disebut Perangkat Lunak

Pengembangan Siklus Hidup atau model SDLC) adalah representasi yang disederhanakan dari proses perangkat lunak. Setiap model proses mewakili proses dari perspektif tertentu

dan dengan demikian hanya menyediakan informasi parsial tentang proses itu. Misalnya, model aktivitas proses menunjukkan aktivitas dan urutannya tetapi mungkin tidak menunjukkan

peran orang-orang yang terlibat dalam kegiatan ini. Di bagian ini, saya memperkenalkan nomor

model proses yang sangat umum (kadang-kadang disebut paradigma proses) dan sekarang

ini dari perspektif arsitektur. Artinya, kita melihat kerangka prosesnya

tetapi tidak rincian kegiatan proses.

Model generik ini adalah deskripsi abstrak tingkat tinggi dari proses perangkat lunak

yang dapat digunakan untuk menjelaskan berbagai pendekatan pengembangan perangkat lunak. Kamu bisa

menganggapnya sebagai kerangka proses yang dapat diperluas dan disesuaikan untuk dibuat

proses rekayasa perangkat lunak yang lebih spesifik.

Model proses umum yang saya bahas di sini adalah:

1. Model air terjun Ini mengambil kegiatan proses mendasar dari spesifikasi, pengembangan, validasi, dan evolusi dan mewakili mereka sebagai terpisah, fase proses seperti spesifikasi kebutuhan, desain perangkat lunak, implementasi, dan pengujian.

2. Pengembangan tambahan. Pendekatan ini menghubungkan aktivitas spesifikasi, pengembangan, dan validasi. Sistem ini dikembangkan sebagai serangkaian versi(increments), dengan setiap versi menambahkan fungsionalitas ke versi sebelumnya.

3. Integrasi dan konfigurasi Pendekatan ini bergantung pada ketersediaan komponen atau sistem yang dapat digunakan kembali. Proses pengembangan sistem berfokus pada mengkonfigurasi komponen-komponen ini untuk digunakan dalam pengaturan baru dan mengintegrasikannya

ke dalam suatu sistem.

Berbagai upaya telah dilakukan untuk mengembangkan model proses "universal" itu

gambarkan semua model umum ini. Salah satu yang paling terkenal dari model-model universal ini

adalah Proses Bersatu Rasional (RUP) (Krutchen 2003), yang dikembangkan oleh

Rational, sebuah perusahaan rekayasa perangkat lunak A.S. RUP adalah model yang fleksibel

dapat dipakai dengan berbagai cara untuk membuat proses yang menyerupai

model proses umum yang dibahas di sini. RUP telah diadopsi oleh sebagian besar

perusahaan perangkat lunak (terutama IBM), tetapi belum mendapatkan penerimaan luas.

2.1The waterfall model

Model publikasi pertama dari proses pengembangan perangkat lunak berasal dari

model proses rekayasa yang digunakan dalam rekayasa sistem militer besar (Royce

1970). Ini menyajikan proses pengembangan perangkat lunak sebagai sejumlah tahap  Karena kaskade dari satu fase ke fase lain, model ini dikenal sebagai model air terjun atau siklus hidup perangkat lunak.

2.1.2.Incremental development

Pengembangan tambahan didasarkan pada gagasan untuk mengembangkan implementasi awal, mendapatkan umpan balik dari pengguna dan orang lain, dan mengembangkan perangkat lunak melalui

beberapa versi hingga sistem yang dibutuhkan telah dikembangkan .Spesifikasi, pengembangan, dan kegiatan validasi disisipkan daripada terpisah, dengan umpan balik cepat di seluruh kegiatan.

Pengembangan inkremental dalam beberapa bentuk sekarang adalah pendekatan yang paling umum untuk

pengembangan sistem aplikasi dan produk perangkat lunak. Pendekatan ini bisa

bisa didorong oleh rencana, gesit atau, lebih biasanya, campuran dari pendekatan-pendekatan ini. Di sebuah

pendekatan yang digerakkan oleh rencana, peningkatan sistem diidentifikasi sebelumnya; jika lincah

pendekatan diadopsi, kenaikan awal diidentifikasi, tetapi pengembangan

kenaikan nanti tergantung pada kemajuan dan prioritas pelanggan

2.1.3 Integration and configuration

Di sebagian besar proyek perangkat lunak, ada beberapa perangkat lunak yang digunakan kembali. Ini sering terjadi

informal ketika orang yang bekerja di proyek mengetahui atau mencari kode itu

mirip dengan apa yang dibutuhkan. Mereka mencari ini, memodifikasinya sesuai kebutuhan, dan mengintegrasikan

mereka dengan kode baru yang telah mereka kembangkan.

Tiga jenis komponen perangkat lunak yang sering digunakan kembali:

1. Sistem aplikasi yang berdiri sendiri yang dikonfigurasi untuk digunakan dalam lingkungan tertentu. Sistem ini adalah sistem tujuan umum yang memiliki banyak fitur,

tetapi mereka harus disesuaikan untuk digunakan dalam aplikasi tertentu.

2. Koleksi objek yang dikembangkan sebagai komponen atau sebagai paket yang akan dibuat

terintegrasi dengan kerangka kerja komponen seperti kerangka Java Spring (Wheeler dan Putih 2013).

3. Layanan web yang dikembangkan sesuai dengan standar layanan dan yang ada tersedia untuk doa jarak jauh melalui Internet.

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. Secara umum, proses sekarang didukung oleh alat. Ini

berarti bahwa pengembang perangkat lunak dapat menggunakan serangkaian alat perangkat lunak untuk membantu mereka, seperti itu

sebagai sistem manajemen persyaratan, editor model desain, editor program, alat pengujian otomatis, dan penentang.

2.2.1 Software specification

Spesifikasi perangkat lunak atau persyaratan rekayasa adalah proses pemahaman

dan mendefinisikan layanan apa yang diperlukan dari sistem dan mengidentifikasi kendala pada operasi dan pengembangan sistem. Rekayasa persyaratan adalah a

terutama tahap kritis dari proses perangkat lunak, karena kesalahan yang dilakukan pada tahap ini

mau tidak mau menyebabkan masalah kemudian dalam desain dan implementasi sistem.

2.2.2 Software design and implementation

Tahap implementasi pengembangan perangkat lunak adalah proses pengembangan

sistem yang dapat dieksekusi untuk pengiriman ke pelanggan. Terkadang ini melibatkan kegiatan yang terpisah dari desain dan pemrograman perangkat lunak. Namun, jika pendekatannya gesit

untuk pengembangan digunakan, desain dan implementasi disatukan, tanpa dokumen desain formal yang dihasilkan selama proses. Tentu saja, perangkat lunaknya

masih dirancang, tetapi desain direkam secara tidak resmi di papan tulis dan notebook programmer.

2.2.3 Software validation

Validasi perangkat lunak atau, lebih umum, verifikasi dan validasi (V & V) adalah

dimaksudkan untuk menunjukkan bahwa suatu sistem baik sesuai dengan spesifikasinya dan memenuhi

harapan pelanggan sistem. Pengujian program, di mana sistem dijalankan

menggunakan data uji simulasi, adalah teknik validasi utama. Validasi juga bisa

melibatkan proses pemeriksaan, seperti inspeksi dan ulasan, pada setiap tahap

proses perangkat lunak mulai dari definisi kebutuhan pengguna hingga pengembangan program.

Namun, sebagian besar waktu dan upaya V & V dihabiskan untuk pengujian program.

2.2.4 Software evolution

Fleksibilitas perangkat lunak adalah salah satu alasan utama mengapa semakin banyak perangkat lunak

sedang dimasukkan ke dalam sistem yang besar dan kompleks. Setelah keputusan dibuat

pembuatan perangkat keras, sangat mahal untuk melakukan perubahan pada desain perangkat keras.

Namun, perubahan dapat dilakukan ke perangkat lunak kapan saja selama atau setelah sistem

pengembangan. Bahkan perubahan ekstensif masih jauh lebih murah daripada yang sesuai

perubahan pada perangkat keras sistem.

2.3 Coping with change

Perubahan tidak bisa dihindari dalam semua proyek perangkat lunak besar. Persyaratan sistem

berubah ketika bisnis merespons tekanan eksternal, persaingan, dan perubahan

prioritas manajemen. Ketika teknologi baru tersedia, pendekatan baru untuk

desain dan implementasi menjadi mungkin. Oleh karena itu model proses perangkat lunak apa pun yang digunakan, penting untuk mengakomodasi perubahan pada perangkat lunak

sedang dikembangkan.

2.3.1 Prototyping

Prototipe adalah versi awal sistem perangkat lunak yang digunakan untuk menunjukkan konsep, mencoba opsi desain, dan mencari tahu lebih lanjut tentang masalah dan kemungkinannya

solusi. Pengembangan prototipe yang cepat dan berulang sangat penting agar biayanya

pemegang saham yang terkontrol dan sistem dapat bereksperimen dengan prototipe di awal

proses perangkat lunak.

2.3.2 Incremental delivery

Pengiriman tambahan adalah pendekatan pengembangan perangkat lunak tempat

beberapa peningkatan yang dikembangkan dikirim ke pelanggan dan digunakan untuk

gunakan di lingkungan kerja mereka. Dalam proses pengiriman tambahan, pelanggan

menentukan layanan mana yang paling penting dan mana yang paling tidak penting

mereka. Sejumlah peningkatan pengiriman kemudian ditentukan, dengan setiap peningkatan menyediakan subset dari fungsionalitas sistem. Alokasi layanan untuk peningkatan

tergantung pada prioritas layanan, dengan layanan prioritas tertinggi diimplementasikan dan

dikirim terlebih dahulu.

2.4 Process improvement

Saat ini, ada permintaan konstan dari industri untuk perangkat lunak yang lebih murah, lebih baik,

yang harus dikirim ke tenggat waktu yang semakin ketat. Akibatnya, banyak perangkat lunak

perusahaan telah beralih ke perbaikan proses perangkat lunak sebagai cara untuk meningkatkan

Chapter 3

Agile software 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 perangkat lunak, dan proses pengembangan perangkat lunak yang terkontrol dan ketat. Pandangan ini datang dari komunitas rekayasa perangkat lunak yang bertanggung jawab untuk mengembangkan besar, berumur panjang

sistem perangkat lunak seperti dirgantara dan sistem pemerintah.

Pendekatan yang digerakkan oleh rencana ini dikembangkan untuk perangkat lunak yang dikembangkan oleh tim besar,

bekerja untuk perusahaan yang berbeda. Tim sering tersebar secara geografis dan

bekerja pada perangkat lunak untuk jangka waktu yang lama. Contoh dari jenis perangkat lunak ini

adalah sistem kontrol untuk pesawat terbang modern, yang mungkin memerlukan waktu hingga 10 tahun dari

spesifikasi awal untuk penempatan. Pendekatan berbasis rencana melibatkan pendekatan yang signifikan

overhead dalam perencanaan, perancangan, dan dokumentasi sistem. Overhead ini dibenarkan ketika pekerjaan beberapa tim pengembangan harus dikoordinasikan, ketika

sistem adalah sistem kritis, dan ketika banyak orang yang berbeda akan terlibat

memelihara perangkat lunak selama masa pakainya.

3.2            Agile development techniques

Gagasan yang mendasari metode lincah dikembangkan sekitar waktu yang sama oleh sejumlah

dari orang yang berbeda pada 1990-an. Namun, mungkin pendekatan yang paling signifikan untuk

perubahan budaya pengembangan perangkat lunak adalah pengembangan Extreme Programming

(XP). Nama itu diciptakan oleh Kent Beck (Beck 1998) karena pendekatannya dikembangkan dengan mendorong praktik yang diakui yang baik, seperti pengembangan berulang, untuk Tingkat "ekstrim". Misalnya, di XP, beberapa versi baru dari suatu sistem dapat dikembangkan oleh pemrogram yang berbeda, terintegrasi, dan diuji dalam sehari. proses XP untuk menghasilkan peningkatan sistem yang sedang dikembangkan. Di XP, persyaratan dinyatakan sebagai skenario (disebut cerita pengguna), yaitu diimplementasikan secara langsung sebagai serangkaian tugas. Programmer bekerja berpasangan dan berkembang menguji untuk setiap tugas sebelum menulis kode. Semua tes harus berhasil dilaksanakan

ketika kode baru diintegrasikan ke dalam sistem. Ada jarak waktu yang singkat antara

rilis sistem.

3.2.1 User stories

Persyaratan perangkat lunak selalu berubah. Untuk menangani perubahan ini, metode tangkas tidak

memiliki kegiatan rekayasa persyaratan terpisah. Sebaliknya, mereka mengintegrasikan persyaratan

elisitasi dengan pembangunan. Untuk mempermudah ini, ide "cerita pengguna" dikembangkan di mana kisah pengguna adalah skenario penggunaan yang mungkin dialami oleh pengguna sistem.

3.2.2 Refactoring

Prinsip mendasar dari rekayasa perangkat lunak tradisional adalah Anda harus mendesain

untuk perubahan. Artinya, Anda harus mengantisipasi perubahan perangkat lunak dan desain di masa mendatang

sehingga perubahan ini dapat dengan mudah diimplementasikan. Pemrograman ekstrim, bagaimanapun,

telah membuang prinsip ini atas dasar bahwa merancang untuk perubahan sering kali sia-sia

upaya. Tidak perlu meluangkan waktu untuk menambahkan generalisasi ke suatu program untuk mengatasi perubahan.

Seringkali perubahan yang diantisipasi tidak pernah terwujud, atau perubahan yang sama sekali berbeda

permintaan sebenarnya bisa dibuat.

Tentu saja, dalam praktiknya, perubahan harus selalu dilakukan terhadap kode yang sedang dikembangkan. Untuk membuat perubahan ini lebih mudah, pengembang XP menyarankan agar kodenya

dikembangkan harus terus-menerus di refactored. Refactoring (Fowler et al. 1999) berarti itu

tim pemrograman mencari kemungkinan perbaikan pada perangkat lunak dan implementasinya

3.2.3 Test-first development

Seperti yang saya bahas dalam pengantar bab ini, salah satu perbedaan penting

antara pengembangan inkremental dan pembangunan yang digerakkan oleh rencana adalah seperti itu

sistem diuji. Dengan pengembangan tambahan, tidak ada spesifikasi sistem

yang dapat digunakan oleh tim pengujian eksternal untuk mengembangkan tes sistem. Sebagai akibatnya, beberapa pendekatan untuk pengembangan bertahap memiliki pengujian yang sangat informal

proses, dibandingkan dengan pengujian yang digerakkan oleh rencana.

Extreme Programming mengembangkan pendekatan baru untuk pengujian program untuk mengatasi

kesulitan pengujian tanpa spesifikasi. Pengujian otomatis dan merupakan pusat

ke proses pengembangan, dan pengembangan tidak dapat dilanjutkan sampai semua tes miliki

telah berhasil dieksekusi. Fitur utama pengujian di XP adalah:

1. tes pengembangan pertama,

2. pengembangan tes tambahan dari skenario,

3. keterlibatan pengguna dalam pengembangan dan validasi pengujian, dan

4. penggunaan kerangka kerja pengujian otomatis.

3.2.4 Pair programming

Praktik inovatif lain yang diperkenalkan di XP adalah programer yang bekerja

berpasangan untuk mengembangkan perangkat lunak. Pasangan pemrograman duduk di komputer yang sama dengan

mengembangkan perangkat lunak. Namun, pasangan yang sama tidak selalu memprogram bersama.

Sebaliknya, pasangan diciptakan secara dinamis sehingga semua anggota tim saling bekerja sama

selama proses pengembangan

3.3 Agile project management

Dalam bisnis perangkat lunak apa pun, manajer perlu mengetahui apa yang sedang terjadi dan apakah atau tidak

suatu proyek cenderung memenuhi tujuannya dan memberikan perangkat lunak tepat waktu dengan anggaran yang diusulkan. Pendekatan berbasis rencana untuk pengembangan perangkat lunak berkembang untuk memenuhi hal ini

perlu. Seperti yang saya bahas di Bab 23, manajer menyusun rencana untuk proyek yang diperlihatkan

apa yang harus disampaikan, kapan harus disampaikan, dan siapa yang akan mengerjakan pengembangan hasil proyek. Pendekatan berbasis rencana membutuhkan manajer untuk memilikinya

pandangan stabil dari segala sesuatu yang harus dikembangkan dan proses pengembangan.

Perencanaan informal dan kontrol proyek yang diusulkan oleh para penganut metode gesit awal bertentangan dengan persyaratan bisnis ini untuk visibilitas. Tim

mengorganisir diri, tidak menghasilkan dokumentasi, dan merencanakan pengembangan di

siklus yang sangat singkat. Meskipun ini dapat dan tidak bekerja untuk perusahaan kecil yang sedang berkembang

produk perangkat lunak, itu tidak pantas untuk perusahaan besar yang perlu tahu apa itu

terjadi di organisasi mereka.

3.4  Scaling agile methods

Metode tangkas dikembangkan untuk digunakan oleh tim pemrograman kecil yang bisa bekerja

bersama di ruangan yang sama dan berkomunikasi secara informal. Mereka awalnya digunakan

oleh untuk pengembangan sistem kecil dan menengah dan produk perangkat lunak.

Perusahaan kecil, tanpa proses formal atau birokrasi, awalnya antusias

pengadopsi metode ini. Tentu saja, kebutuhan untuk pengiriman perangkat lunak yang lebih cepat, yang lebih sesuai dengan kebutuhan pelanggan, juga berlaku untuk sistem yang lebih besar dan perusahaan yang lebih besar. Karena itu,

selama beberapa tahun terakhir, banyak pekerjaan telah dimasukkan ke dalam metode tangkas berkembang

baik sistem perangkat lunak besar dan untuk digunakan di perusahaan besar.

Chapter 4

Requirements engineering

4.1 Functional and non-functional requirements

Persyaratan sistem perangkat lunak sering diklasifikasikan sebagai fungsional atau non-fungsional

Persyaratan:

1. Persyaratan fungsional Ini adalah pernyataan layanan yang seharusnya diberikan oleh sistem

memberikan, 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. Mereka termasuk kendala waktu, kendala pada proses pengembangan, dan kendala yang ditentukan oleh standar. Persyaratan non-fungsional sering berlaku untuk sistem secara keseluruhan daripada fitur sistem individual

atau layanan.

Pada kenyataannya, perbedaan antara berbagai jenis persyaratan tidak sejelas yang disarankan oleh definisi sederhana ini. Persyaratan pengguna yang berkaitan dengan keamanan,

seperti pernyataan yang membatasi akses ke pengguna yang sah, mungkin tampak sebagai persyaratan yang tidak berfungsi. Namun, ketika dikembangkan secara lebih rinci, persyaratan ini

dapat menghasilkan persyaratan lain yang jelas fungsional, seperti kebutuhan

termasuk fasilitas otentikasi pengguna dalam sistem.

4.2 Requirements engineering processes

Di awal proses, sebagian besar upaya akan dihabiskan untuk memahami bisnis tingkat tinggi

dan persyaratan non-fungsional, dan persyaratan pengguna untuk sistem. Kemudian di

proses, di lingkaran luar spiral, lebih banyak upaya akan dikhususkan untuk memunculkan dan

memahami persyaratan non-fungsional dan persyaratan sistem yang lebih rinci.

Model spiral ini mengakomodasi pendekatan untuk pengembangan di mana persyaratan dikembangkan ke berbagai tingkat detail. Jumlah iterasi di sekitar

spiral dapat bervariasi sehingga spiral dapat keluar setelah beberapa atau semua persyaratan pengguna telah diperoleh. Pengembangan lincah dapat digunakan alih-alih pembuatan prototipe

bahwa persyaratan dan implementasi sistem dikembangkan bersama.

4.3 Requirements elicitation

Tujuan dari proses elisitasi persyaratan adalah untuk memahami pekerjaan itu

pemangku kepentingan lakukan dan bagaimana mereka dapat menggunakan sistem baru untuk membantu mendukung pekerjaan itu. Selama persyaratan elisitasi, insinyur perangkat lunak bekerja dengan para pemangku kepentingan untuk menemukan

tentang domain aplikasi, aktivitas kerja, layanan, dan fitur sistem

yang diinginkan oleh para pemangku kepentingan, kinerja sistem yang diperlukan, kendala perangkat keras, dan sebagainya.

4.4 Requirements specification

Spesifikasi persyaratan adalah proses penulisan persyaratan pengguna dan sistem dalam dokumen persyaratan. Idealnya, persyaratan pengguna dan sistem harus menjadi jelas, tidak ambigu, mudah dimengerti, lengkap, dan konsisten

4.5 Requirements validation

Validasi persyaratan adalah proses memeriksa bahwa persyaratan menentukan sistem yang benar-benar diinginkan pelanggan. Itu tumpang tindih dengan elisitasi dan analisis, sebagaimana adanya berkaitan dengan menemukan masalah dengan persyaratan.

4.6 Requirements change

Persyaratan untuk sistem perangkat lunak besar selalu berubah. Salah satu alasannya

perubahan yang sering terjadi adalah bahwa sistem ini sering dikembangkan untuk mengatasi "orang jahat"

masalah — masalah yang tidak dapat sepenuhnya didefinisikan (Rittel dan Webber 1973).

Karena masalah tidak dapat sepenuhnya ditentukan, persyaratan perangkat lunak terikat

Namun, sebagian besar perubahan persyaratan sistem muncul karena perubahan lingkungan bisnis sistem

CHAPTER 5

System modeling

Pemodelan sistem adalah proses mengembangkan model abstrak suatu sistem, dengan masing-masingnya

model yang menyajikan pandangan atau perspektif yang berbeda dari sistem itu. Pemodelan sistem

sekarang biasanya berarti mewakili suatu sistem menggunakan semacam notasi grafis

berdasarkan pada jenis diagram dalam Unified Modeling Language (UML). Namun demikian

juga memungkinkan untuk mengembangkan model formal (matematis) suatu sistem, biasanya sebagai a

spesifikasi sistem terperinci. Saya membahas pemodelan grafis menggunakan UML di sini, dan

pemodelan formal.

Model digunakan selama proses rekayasa persyaratan untuk membantu menurunkan

persyaratan terperinci untuk suatu sistem, selama proses desain untuk menggambarkan sistem

untuk insinyur yang menerapkan sistem, dan setelah implementasi untuk mendokumentasikan

struktur dan operasi 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 mereka dapat digunakan untuk memfokuskan diskusi pemangku kepentingan pada kekuatan dan kelemahannya.

2. Model sistem baru digunakan selama rekayasa persyaratan untuk membantu

menjelaskan persyaratan yang diajukan kepada pemangku kepentingan sistem lainnya. Insinyur menggunakan

model-model ini untuk membahas proposal desain dan untuk mendokumentasikan sistem untuk implementasi. Jika Anda menggunakan proses rekayasa model-driven (Brambilla, Cabot,

dan Wimmer 2012), Anda dapat menghasilkan implementasi sistem yang lengkap atau sebagian dari model sistem.

5.1 Context model

Pada tahap awal dalam spesifikasi sistem, Anda harus memutuskan sistem

batas, yaitu, pada apa yang dan tidak merupakan bagian dari sistem yang dikembangkan. Ini

melibatkan bekerja dengan pemangku kepentingan sistem untuk memutuskan fungsi apa yang seharusnya

termasuk dalam sistem dan proses dan operasi apa yang harus dilakukan

lingkungan operasional sistem

5.2 Interaction models

Semua sistem melibatkan interaksi dari beberapa jenis. Ini bisa berupa interaksi pengguna, yang

melibatkan input dan output pengguna; interaksi antara perangkat lunak yang dikembangkan dan

sistem lain di lingkungannya; atau interaksi antara komponen perangkat lunak

sistem.

Bagian ini membahas dua pendekatan terkait untuk pemodelan interaksi:

1. Gunakan pemodelan kasus, yang sebagian besar digunakan untuk memodelkan interaksi antara sistem dan agen eksternal (pengguna manusia atau sistem lain).

2. Sequence diagram, yang digunakan untuk memodelkan interaksi antara komponen sistem, meskipun agen eksternal juga dapat dimasukkan.

5.3 Structural models

Model struktural perangkat lunak menampilkan organisasi sistem dalam hal

komponen yang membentuk sistem itu dan hubungannya. Model struktural mungkin

menjadi model statis, yang menunjukkan organisasi desain sistem, atau dinamis

model, yang menunjukkan organisasi sistem ketika dieksekusi.

5.4 Behavioral models

Model perilaku adalah model perilaku dinamis suatu sistem saat dijalankan. Mereka menunjukkan apa yang terjadi atau apa yang seharusnya terjadi ketika suatu sistem merespons

untuk stimulus dari lingkungannya. Stimulus ini dapat berupa data atau peristiwa:

1. Data menjadi tersedia yang harus diproses oleh sistem. Ketersediaan

dari data memicu pemrosesan.

2. Suatu peristiwa terjadi yang memicu pemrosesan sistem. Acara mungkin terkait

data, meskipun ini tidak selalu terjadi.

Chapter 6

Architectural design

6.1 Architectural design decisions

Desain arsitektur adalah proses kreatif di mana Anda merancang organisasi sistem

yang akan memenuhi persyaratan fungsional dan non-fungsional suatu sistem. Ada

tidak ada proses desain arsitektur formulaik. Itu tergantung pada jenis sistem yang sedang

dikembangkan, latar belakang dan pengalaman arsitek sistem, dan spesifik

persyaratan untuk sistem. Akibatnya, saya pikir yang terbaik adalah mempertimbangkan architect

6.2 Architectural views

Saya menjelaskan dalam pengantar bab ini bahwa model arsitektur suatu perangkat lunak

sistem dapat digunakan untuk memfokuskan diskusi tentang persyaratan atau desain perangkat lunak.

Atau, mereka dapat digunakan untuk mendokumentasikan desain sehingga dapat digunakan sebagai dasar

untuk desain dan implementasi sistem yang lebih rinci. Di bagian ini, saya membahas

dua masalah yang relevan dengan keduanya:

1. Pandangan atau perspektif apa yang berguna saat merancang dan mendokumentasikan arsitektur sistem?

2. Notasi apa yang harus digunakan untuk menggambarkan model arsitektur

6.3 Architectural patterns

Gagasan pola sebagai cara menyajikan, berbagi, dan menggunakan kembali pengetahuan tentang

sistem perangkat lunak telah diadopsi di sejumlah bidang rekayasa perangkat lunak. Itu

pemicu untuk ini adalah penerbitan buku tentang pola desain berorientasi objek

(Gamma et al. 1995).

6.4 Application architectures

Sistem aplikasi dimaksudkan untuk memenuhi kebutuhan bisnis atau organisasi. Semua

bisnis memiliki banyak kesamaan — mereka perlu merekrut orang, mengeluarkan faktur, mempertahankan

akun, dan sebagainya. Bisnis yang beroperasi di sektor yang sama menggunakan aplikasi spesifik sektor umum. Karena itu, seperti halnya fungsi bisnis umum, semua ponsel perusahaan membutuhkan sistem untuk menghubungkan dan mengukur panggilan, mengelola jaringan dan masalah mereka tagihan kepada pelanggan. Akibatnya, sistem aplikasi yang digunakan oleh bisnis ini juga memiliki banyak kesamaan.

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

1. Sebagai titik awal untuk proses desain arsitektur Jika Anda tidak terbiasa

dengan jenis aplikasi yang Anda kembangkan, Anda dapat mendasarkan inisial Anda

desain pada arsitektur aplikasi generik. Anda kemudian mengkhususkan ini untuk

sistem spesifik yang sedang dikembangkan.

2. Sebagai daftar periksa desain. Jika Anda telah mengembangkan desain arsitektur untuk sistem aplikasi, Anda dapat membandingkannya dengan arsitektur aplikasi umum.

Anda dapat memeriksa bahwa desain Anda konsisten dengan arsitektur generik.

3. Sebagai cara mengatur kerja tim pengembangan Arsitektur aplikasi mengidentifikasi fitur struktural yang stabil dari arsitektur sistem, dan dalam

banyak kasus, adalah mungkin untuk mengembangkan ini secara paralel. Anda dapat menetapkan pekerjaan

anggota grup untuk mengimplementasikan berbagai komponen dalam arsitektur.

4. Sebagai sarana menilai komponen untuk digunakan kembali Jika Anda memiliki komponen Anda

mungkin dapat menggunakan kembali, Anda dapat membandingkan ini dengan struktur generik untuk dilihat

apakah ada komponen yang sebanding dalam arsitektur aplikasi.

5. Sebagai kosakata untuk berbicara tentang aplikasi Jika Anda membahas spesifik

aplikasi atau mencoba membandingkan aplikasi, maka Anda dapat menggunakan konsep

diidentifikasi dalam arsitektur generik untuk membicarakan aplikasi ini

Chapter 7

Design and implementation

7.1 Object-oriented design using the UML

Sistem berorientasi objek terdiri dari benda-benda yang berinteraksi yang mempertahankan lokal mereka sendiri

negara dan menyediakan operasi di negara itu. Representasi negara bersifat pribadi dan

tidak dapat diakses langsung dari luar objek. Proses desain berorientasi objek

melibatkan mendesain kelas objek dan hubungan antara kelas-kelas ini. Ini

kelas mendefinisikan objek dalam sistem dan interaksinya. Ketika desain terwujud

sebagai program pelaksana, objek dibuat secara dinamis dari definisi kelas ini.

Untuk mengembangkan desain sistem dari konsep hingga detail, desain berorientasi objek, Anda

perlu:

1. Memahami dan mendefinisikan konteks dan interaksi eksternal dengan sistem.

2. Desain arsitektur sistem.

3. Identifikasi objek-objek utama dalam sistem.

4. Kembangkan model desain.

5. Tentukan antarmuka.

7.2 Design patterns

Pola desain berasal dari ide-ide yang diajukan oleh Christopher Alexander (Alexander 1979), yang menyarankan bahwa ada pola umum bangunan tertentu desain yang secara inheren menyenangkan dan efektif. Polanya adalah deskripsi dari masalah dan esensi solusinya, sehingga solusinya dapat digunakan kembali secara berbeda

pengaturan. Polanya bukan spesifikasi terperinci. Sebaliknya, Anda dapat menganggapnya sebagai deskripsi dari akumulasi kebijaksanaan dan pengalaman, solusi yang telah dicoba dengan baik untuk masalah umum.

7.3 Implementation issues

Rekayasa perangkat lunak mencakup semua kegiatan yang terlibat dalam pengembangan perangkat lunak

dari persyaratan awal sistem hingga pemeliharaan dan manajemen dari sistem yang digunakan. Tahap kritis dari proses ini, tentu saja, implementasi sistem, di mana Anda membuat versi perangkat lunak yang dapat dieksekusi. Penerapan mungkin melibatkan pengembangan program dalam bahasa pemrograman tingkat tinggi atau rendah atau menyesuaikan dan mengadaptasi sistem generik, off-the-shelf untuk memenuhi persyaratan spesifik dari suatu organisasi.

7.4 Open-source development

Pengembangan open-source adalah pendekatan untuk pengembangan perangkat lunak di mana

kode sumber sistem perangkat lunak diterbitkan dan sukarelawan diundang untuk berpartisipasi dalam proses pengembangan (Raymond 2001). Akarnya ada di Perangkat Lunak Bebas

Foundation (www.fsf.org), yang menganjurkan bahwa kode sumber tidak boleh menjadi hak milik melainkan harus selalu tersedia bagi pengguna untuk memeriksa dan memodifikasi saat mereka

ingin. Ada asumsi bahwa kode akan dikontrol dan dikembangkan oleh

kelompok inti kecil, bukan pengguna kode.

Kebanyakan  lisensi open-source (Chapman 2010) adalah varian dari satu dari tiga

model umum:

1. GNU General Public License (GPL). Ini disebut lisensi timbal balik

yang disederhanakan berarti bahwa jika Anda menggunakan perangkat lunak sumber terbuka yang dilisensikan

di bawah lisensi GPL, maka Anda harus menjadikan perangkat lunak itu sumber terbuka.

2. Lisensi Publik Umum GNU (LGPL). Ini adalah varian dari GPL

lisensi tempat Anda dapat menulis komponen yang menautkan ke kode sumber terbuka tanpa

harus mempublikasikan sumber komponen ini. Namun, jika Anda mengubah

komponen berlisensi, maka Anda harus menerbitkan ini sebagai sumber terbuka.

3. Lisensi Berkley Standard Distribution (BSD). Ini adalah lisensi non-timbal balik,

yang berarti Anda tidak berkewajiban untuk menerbitkan kembali setiap perubahan atau modifikasi yang dilakukan

220 Bab 7 ■ Desain dan implementasi

kode sumber terbuka. Anda dapat memasukkan kode dalam sistem berpemilik yang dijual. Jika

Anda menggunakan komponen sumber terbuka, Anda harus mengakui pencipta asli

Kode. Lisensi MIT adalah varian dari lisensi BSD dengan kondisi serupa

Chapter 8

Software testing

8.1 Development testing

Pengujian pengembangan mencakup semua aktivitas pengujian yang dilakukan oleh tim

mengembangkan sistem. Penguji perangkat lunak biasanya adalah programmer yang

mengembangkan perangkat lunak itu.

Ada tiga tahap pengujian pengembangan:

1. Pengujian unit, di mana unit program individu atau kelas objek diuji. Satuan

pengujian harus fokus pada pengujian fungsionalitas objek atau metode.

2. Pengujian komponen, di mana beberapa unit individu diintegrasikan untuk membuat komponen komposit. Pengujian komponen harus fokus pada pengujian komponen

antarmuka yang menyediakan akses ke fungsi komponen.

3. Pengujian sistem, di mana beberapa atau semua komponen dalam suatu sistem terintegrasi

dan sistem diuji secara keseluruhan. Pengujian sistem harus fokus pada pengujian interaksi komponen.

8.2 Test-driven development

Test-driven development (TDD) adalah pendekatan untuk pengembangan program

Anda interleave pengujian dan pengembangan kode (Beck 2002; Jeffries dan Melnik 2007).

Anda mengembangkan kode secara bertahap, bersama dengan serangkaian tes untuk kenaikan itu. Kamu

jangan mulai mengerjakan kenaikan berikutnya sampai kode yang Anda kembangkan

lulus semua tesnya. Pengembangan berbasis tes diperkenalkan sebagai bagian dari XP lincah

metode pengembangan. Namun, sekarang telah mendapatkan penerimaan umum dan mungkin

digunakan dalam proses berbasis tangkas dan rencana.

8.3 Release testing

Pengujian rilis adalah proses pengujian rilis khusus dari sistem yang dimaksudkan

untuk digunakan di luar tim pengembangan. Biasanya, rilis sistem untuk pelanggan

dan pengguna. Namun, dalam proyek yang kompleks, perilisannya bisa untuk tim lain

mengembangkan sistem terkait. Untuk produk perangkat lunak, rilis bisa untuk produk

manajemen yang kemudian menyiapkannya untuk dijual.

8.4 User testing

Pengujian pengguna atau pelanggan adalah tahap dalam proses pengujian di mana pengguna atau pelanggan

memberikan masukan dan saran tentang pengujian sistem. Ini mungkin melibatkan pengujian secara formal sistem yang telah ditugaskan dari pemasok eksternal. Atau, mungkin saja proses informal di mana pengguna bereksperimen dengan produk perangkat lunak baru untuk melihat apakah mereka menyukainya dan memeriksa apakah itu sesuai dengan yang mereka butuhkan. Pengujian pengguna sangat penting, bahkan ketika sistem komprehensif dan pengujian rilis telah dilakukan. Pengaruh

dari lingkungan kerja pengguna dapat memiliki pengaruh besar pada keandalan, kinerja, kegunaan, dan ketahanan suatu sistem.

Chapter 9

Software evolution

9.1 Evolution processes

Seperti halnya semua proses perangkat lunak, tidak ada yang namanya perubahan perangkat lunak standar

atau proses evolusi. Proses evolusi yang paling tepat untuk sistem perangkat lunak tergantung pada jenis perangkat lunak yang dipelihara, proses pengembangan perangkat lunak yang digunakan dalam suatu organisasi, dan keterampilan orang-orang yang terlibat. Untuk beberapa tipe sistem, seperti aplikasi seluler, evolusi mungkin merupakan proses informal, di mana perubahan

sebagian besar permintaan berasal dari percakapan antara pengguna sistem dan pengembang. Untuk jenis sistem lain, seperti sistem kritis tertanam, evolusi perangkat lunak mungkin diformalkan, dengan dokumentasi terstruktur yang dihasilkan pada setiap tahap dalam proses.

9.2  Legacy systems

Perusahaan-perusahaan besar mulai mengkomputerisasi operasi mereka pada 1960-an, jadi selama 50 tahun terakhir

tahun atau lebih, semakin banyak sistem perangkat lunak telah diperkenalkan. Banyak dari ini sistem telah diganti (kadang beberapa kali) karena bisnis telah berubah dan berevolusi. Namun, banyak sistem lama masih digunakan dan memainkan peran penting dalam menjalankan bisnis. Sistem perangkat lunak yang lebih tua ini kadang-kadang disebut sistem warisan.

9.3 Software maintenance

Pemeliharaan perangkat lunak adalah proses umum untuk mengubah sistem setelah itu

telah dikirim. Istilah ini biasanya diterapkan pada perangkat lunak khusus, di mana terpisah

kelompok pengembangan terlibat sebelum dan sesudah melahirkan. Perubahan yang dilakukan pada

perangkat lunak mungkin perubahan sederhana untuk memperbaiki kesalahan pengkodean, lebih luas

perubahan untuk memperbaiki kesalahan desain, atau peningkatan signifikan untuk memperbaiki kesalahan spesifikasi atau untuk mengakomodasi persyaratan baru. Perubahan diterapkan oleh

memodifikasi komponen sistem yang ada dan, jika perlu, dengan menambahkan yang baru

komponen ke sistem.

Ada tiga jenis pemeliharaan perangkat lunak:

1. Perbaikan kesalahan untuk memperbaiki bug dan kerentanan. Kesalahan pengkodean biasanya relatif

murah untuk dikoreksi; kesalahan desain lebih mahal karena mungkin melibatkan

menulis ulang beberapa komponen program. Kesalahan persyaratan adalah yang paling mahal untuk diperbaiki karena desain ulang sistem yang luas mungkin diperlukan.

2. Adaptasi lingkungan untuk menyesuaikan perangkat lunak dengan platform dan lingkungan baru. Jenis pemeliharaan ini diperlukan saat beberapa aspek sistem

lingkungan, seperti perangkat keras, sistem operasi platform, atau perangkat lunak pendukung lainnya, berubah. Sistem aplikasi mungkin harus dimodifikasi untuk mengatasinya

dengan perubahan lingkungan ini.

3. Penambahan fungsi untuk menambah fitur baru dan untuk mendukung persyaratan baru.

Jenis perawatan ini diperlukan ketika persyaratan sistem berubah

respons terhadap perubahan organisasi atau bisnis. Skala perubahan yang dibutuhkan

untuk perangkat lunak seringkali jauh lebih besar daripada jenis pemeliharaan lainnya.

CHAPTER 10
Dependable Systems

10.1         Dependability Properties

Ketergantungan sistem komputer adalah properti dari sistem yang mencerminkan kepercayaannya. Kepercayaan di sini pada dasarnya berarti tingkat kepercayaan pengguna bahwa sistem akan beroperasi seperti yang mereka harapkan dan bahwa sistem tidak akan "gagal" dalam penggunaan normal. Tidaklah berarti mengekspresikan ketergantungan secara numerik. Sebaliknya, istilah relatif seperti "tidak bisa diandalkan," "sangat bisa diandalkan," dan "sangat bisa diandalkan" dapat mencerminkan tingkat kepercayaan yang mungkin kita miliki dalam suatu sistem.

10.2         Sociotechnical Systems

Dalam sistem komputer, perangkat lunak dan perangkat kerasnya saling tergantung. Tanpa perangkat keras, sistem perangkat lunak adalah sebuah abstraksi, yang hanya merupakan representasi dari beberapa pengetahuan dan gagasan manusia. Tanpa perangkat lunak, perangkat keras adalah seperangkat perangkat elektronik elektronik inert. Namun, jika Anda menyatukannya untuk membentuk sistem, Anda membuat mesin yang dapat melakukan perhitungan yang rumit dan memberikan hasil perhitungan ini ke lingkungannya.

10.3         Redundancy and Diversity

Kami menggunakan redundansi dan keragaman untuk meningkatkan ketergantungan dalam kehidupan kita sehari-hari. Umumnya, untuk mengamankan rumah kami, kami menggunakan lebih dari satu kunci (redundansi), dan, biasanya, kunci yang digunakan adalah dari berbagai jenis (keanekaragaman). Ini berarti bahwa jika penyusup menemukan cara untuk mengalahkan salah satu kunci, mereka harus menemukan cara yang berbeda untuk mengalahkan kunci lainnya sebelum mereka dapat masuk. Sebagai hal yang rutin, kita semua harus mencadangkan komputer kita dan mempertahankan salinan data kita yang berlebihan. Untuk menghindari masalah dengan kegagalan disk, cadangan harus disimpan pada perangkat eksternal yang terpisah dan beragam.

10.4         Dependable Processes

Proses perangkat lunak yang dapat diandalkan adalah proses perangkat lunak yang dirancang untuk menghasilkan perangkat lunak yang dapat diandalkan. Alasan untuk berinvestasi dalam proses yang dapat diandalkan adalah bahwa proses perangkat lunak yang baik cenderung mengarah pada perangkat lunak yang disampaikan yang mengandung lebih sedikit kesalahan dan karena itu lebih kecil kemungkinannya untuk gagal dalam pelaksanaannya. Sebuah perusahaan yang menggunakan proses yang dapat diandalkan dapat memastikan bahwa proses tersebut telah diberlakukan dan didokumentasikan dengan baik dan bahwa teknik pengembangan yang tepat telah digunakan untuk pengembangan sistem kritis.

10.5         Formal Methods and Dependability

Metode formal berdasarkan pengecekan model (Jhala dan Majumdar 2009) telah digunakan dalam sejumlah sistem (Bochot et al. 2009; Calinescu dan Kwiatkowska 2009). Sistem ini mengandalkan konstruksi atau menghasilkan model keadaan formal dari suatu sistem dan menggunakan pemeriksa model untuk memeriksa bahwa sifat-sifat model, seperti sifat keamanan, selalu berlaku. Program pengecekan model secara mendalam menganalisis spesifikasi dan melaporkan bahwa properti sistem dipenuhi oleh model atau menyajikan contoh yang menunjukkan tidak puas. Jika suatu model dapat dihasilkan secara otomatis atau sistematis dari suatu program, ini berarti bug dalam program tersebut dapat diungkap.

CHAPTER 11
Reliability Engineering

11.1         Availability and Reliability

Dalam Bab 10, saya memperkenalkan konsep keandalan sistem dan ketersediaan sistem. Jika kita menganggap sistem sebagai pengiriman beberapa jenis layanan (untuk mengirimkan uang tunai, mengontrol rem, atau menghubungkan panggilan telepon, misalnya), maka ketersediaan layanan tersebut adalah apakah layanan itu berjalan atau tidak dan keandalannya adalah apakah atau tidak. bukan layanan yang memberikan hasil yang benar. Ketersediaan dan keandalan keduanya dapat dinyatakan sebagai probabilitas. Jika ketersediaannya 0,999, ini berarti bahwa, selama periode waktu tertentu, sistem tersedia untuk 99,9% dari waktu itu. Jika, rata-rata, 2 input dalam setiap 1000 menghasilkan kegagalan, maka keandalan, dinyatakan sebagai tingkat terjadinya kegagalan, adalah 0,002.

11.2         Reliability Requirements

keseluruhan keandalan suatu sistem tergantung pada keandalan perangkat keras, keandalan perangkat lunak, dan keandalan operator sistem. Perangkat lunak sistem harus mempertimbangkan persyaratan ini. Selain mencakup persyaratan yang mengkompensasi kegagalan perangkat lunak, mungkin juga ada persyaratan keandalan terkait untuk membantu mendeteksi dan memulihkan dari kegagalan perangkat keras dan kesalahan operator.

11.3         Fault Tolerant Architectures

Toleransi kesalahan adalah pendekatan runtime untuk ketergantungan di mana sistem menyertakan mekanisme untuk melanjutkan operasi, bahkan setelah kesalahan perangkat lunak atau perangkat keras terjadi dan kondisi sistem salah. Mekanisme toleransi kesalahan mendeteksi dan memperbaiki keadaan yang salah ini sehingga terjadinya kesalahan tidak mengarah pada kegagalan sistem. Toleransi kesalahan diperlukan dalam sistem yang kritis terhadap keselamatan atau keamanan dan di mana sistem tidak dapat pindah ke kondisi aman saat kesalahan terdeteksi.

11.4         Programming for reliability

Saya sengaja memfokuskan buku ini pada aspek independen bahasa pemrograman dari rekayasa perangkat lunak. Hampir tidak mungkin membahas pemrograman tanpa masuk ke perincian bahasa pemrograman tertentu. Namun, ketika mempertimbangkan rekayasa keandalan, ada serangkaian praktik pemrograman yang baik yang diterima yang cukup universal dan yang membantu mengurangi kesalahan dalam sistem yang disampaikan.

11.5         Reability Measurement

The process of measuring the reliability of a system is sometimes called statistical testing (Figure 11.13). The statistical testing process is explicitly geared to reliability measurement rather than fault finding. Prowell et al. (Prowell et al. 1999) give a good description of statistical testing in their book on Cleanroom software engineering.

CHAPTER 12
Safety Engineering

12.1         Safety critical systems

Safety-critical systems are systems in which it is essential that system operation is always safe. That is, the system should never damage people or the system’s environ-ment, irrespective of whether or not the system conforms to its specification. Examples of safety-critical systems include control and monitoring systems in aircraft, process control systems in chemical and pharmaceutical plants, and automobile control systems.

12.2         Safety Requirements

Persyaratan keselamatan terutama persyaratan perlindungan dan tidak mementingkan operasi sistem normal. Mereka dapat menentukan bahwa sistem harus dimatikan sehingga keselamatan tetap terjaga. Dalam menurunkan persyaratan keselamatan, Anda perlu menemukan keseimbangan yang dapat diterima antara keselamatan dan fungsionalitas dan menghindari proteksi berlebih. Tidak ada gunanya membangun sistem yang sangat aman jika tidak beroperasi dengan cara yang hemat biaya.

12.3         Safety Engineering Processes

The software processes used to develop safety-critical software are based on the processes used in software reliability engineering. In general, a great deal of care is taken in developing a complete, and often very detailed, system specification. The design and implementation of the system usual follow a plan-based, waterfall model, with reviews and checks at each stage in the process. Fault avoidance and fault detection are the drivers of the process. For some types of system, such as aircraft systems, fault-tolerant architectures, may be used.

12.4         Safety Cases

Seperti yang telah saya bahas, banyak sistem keamanan-intensif, perangkat lunak-intensif diatur. Otoritas eksternal memiliki pengaruh signifikan terhadap pengembangan dan penyebaran mereka. Regulator adalah badan pemerintah yang tugasnya memastikan bahwa perusahaan komersial tidak menggunakan sistem yang mengancam keselamatan publik dan lingkungan atau ekonomi nasional. Pemilik sistem yang kritis terhadap keselamatan harus meyakinkan regulator bahwa mereka telah melakukan upaya sebaik mungkin untuk memastikan bahwa sistem mereka aman. Regulator menilai safety case untuk sistem, yang menyajikan bukti dan argumen bahwa pengoperasian normal sistem tidak akan membahayakan pengguna.

CHAPTER 13
Security Engineering

Anda harus memperhitungkan tiga dimensi keamanan dalam rekayasa sistem yang aman:
1. Kerahasiaan Informasi dalam suatu sistem dapat diungkapkan atau diakses oleh orang atau program yang tidak berwenang untuk memiliki akses ke informasi itu. Misalnya, pencurian data kartu kredit dari sistem e-commerce adalah masalah kerahasiaan.
2. Integritas Informasi dalam suatu sistem dapat rusak atau rusak, menjadikannya tidak biasa atau tidak dapat diandalkan. Misalnya, worm yang menghapus data dalam suatu sistem adalah masalah integritas.
3. Ketersediaan. Akses ke suatu sistem atau datanya yang biasanya tersedia mungkin tidak dimungkinkan. Serangan denial-of-service yang membebani server adalah contoh situasi di mana ketersediaan sistem terganggu.

13.1  Security and dependability

Keamanan adalah atribut sistem yang mencerminkan kemampuan sistem untuk melindungi dirinya dari serangan internal atau eksternal yang berbahaya. Serangan eksternal ini dimungkinkan karena sebagian besar komputer dan perangkat seluler berjejaring dan karenanya dapat diakses oleh orang luar. Contoh serangan mungkin adalah pemasangan virus dan kuda Troya, penggunaan layanan sistem yang tidak sah, atau modifikasi sistem atau data yang tidak sah.

Gambar Security Terminology

13.1  Security and organizations

Manajemen risiko keamanan karena itu adalah bisnis daripada masalah teknis. Ini harus memperhitungkan kerugian finansial dan reputasi dari serangan sistem yang berhasil serta biaya prosedur keamanan dan teknologi yang dapat mengurangi kerugian ini. Agar manajemen risiko menjadi efektif, organisasi harus memiliki kebijakan keamanan informasi yang terdokumentasi yang menetapkan:
1. Aset yang harus dilindungi Tidak selalu masuk akal untuk menerapkan prosedur keamanan yang ketat untuk semua aset organisasi. Banyak aset tidak bersifat rahasia, dan perusahaan dapat meningkatkan citranya dengan membuat aset ini tersedia secara bebas. Biaya untuk menjaga keamanan informasi yang berada dalam domain publik jauh lebih murah daripada biaya menjaga keamanan informasi yang aman.
2.Tingkat perlindungan yang diperlukan untuk berbagai jenis aset Tidak semua aset memerlukan tingkat perlindungan yang sama. Dalam beberapa kasus (mis., Untuk informasi pribadi yang sensitif), tingkat keamanan yang tinggi diperlukan; untuk informasi lain, konsekuensi kerugiannya mungkin kecil, sehingga tingkat keamanan yang lebih rendah memadai. Oleh karena itu, beberapa informasi dapat disediakan untuk pengguna yang diizinkan dan login; informasi lain mungkin jauh lebih sensitif dan hanya tersedia bagi pengguna dalam peran atau posisi tanggung jawab tertentu.
3. Tanggung jawab masing-masing pengguna, manajer, dan organisasi. Kebijakan keamanan harus menetapkan apa yang diharapkan dari pengguna — misalnya, gunakan kata sandi yang kuat, logout dari komputer, dan kunci kantor. Ini juga mendefinisikan apa yang dapat diharapkan pengguna dari perusahaan, seperti layanan cadangan dan pengarsipan informasi, dan penyediaan peralatan.
4. Prosedur dan teknologi keamanan yang ada yang harus dipertahankan Untuk alasan kepraktisan dan biaya, mungkin penting untuk terus menggunakan pendekatan yang ada untuk keamanan bahkan ketika ini telah diketahui keterbatasannya. Sebagai contoh, sebuah perusahaan mungkin memerlukan penggunaan nama login / kata sandi untuk otentikasi, hanya karena pendekatan lain cenderung ditolak oleh pengguna.

13.2  Security requirements

Spesifikasi persyaratan keamanan untuk sistem memiliki banyak kesamaan dengan spesifikasi persyaratan keselamatan. Anda tidak dapat menentukan persyaratan keselamatan atau keamanan sebagai probabilitas. Seperti persyaratan keselamatan, persyaratan keamanan seringkali merupakan persyaratan “tidak boleh” yang mendefinisikan perilaku sistem yang tidak dapat diterima daripada fungsionalitas sistem yang disyaratkan. Namun, keamanan adalah masalah yang lebih menantang daripada keselamatan, karena sejumlah alasan:
1. Ketika mempertimbangkan keselamatan, Anda dapat mengasumsikan bahwa lingkungan di mana sistem diinstal tidak bermusuhan. Tidak ada yang mencoba menyebabkan insiden terkait keselamatan. Ketika mempertimbangkan keamanan, Anda harus mengasumsikan bahwa serangan pada sistem disengaja dan bahwa penyerang mungkin memiliki pengetahuan tentang kelemahan sistem.
2. Ketika terjadi kegagalan sistem yang menimbulkan risiko keselamatan, Anda mencari kesalahan atau kelalaian yang menyebabkan kegagalan. Ketika serangan yang disengaja menyebabkan kegagalan sistem, menemukan akar penyebabnya mungkin lebih sulit karena penyerang dapat mencoba menyembunyikan penyebab kegagalan tersebut.
3. Biasanya dapat diterima untuk mematikan sistem atau menurunkan layanan sistem untuk menghindari yang terkait dengan keselamatan. kegagalan. Namun, serangan pada suatu sistem dapat berupa serangan penolakan layanan, yang dimaksudkan untuk membahayakan ketersediaan sistem. Mematikan sistem berarti bahwa serangan itu telah berhasil.
4. Kejadian yang berhubungan dengan keselamatan tidak disengaja dan tidak diciptakan oleh pengiklan yang cerdas. Seorang penyerang dapat menyelidiki pertahanan sistem dalam serangkaian serangan, memodifikasi serangan saat dia mempelajari lebih lanjut tentang sistem dan responsnya.

13.3         Secure Systems Design

Desain sistem yang aman berarti merancang keamanan ke dalam sistem aplikasi. Namun, selain berfokus pada keamanan pada tingkat desain, penting juga untuk mempertimbangkan keamanan saat memprogram sistem perangkat lunak. Banyak serangan yang berhasil pada perangkat lunak mengandalkan kerentanan program yang diperkenalkan ketika program dikembangkan. Serangan pertama yang dikenal luas pada sistem berbasis Internet terjadi pada tahun 1988 ketika worm diperkenalkan ke sistem Unix di seluruh jaringan (Spafford 1989). Ini mengambil keuntungan dari kerentanan pemrograman yang terkenal. Jika sistem diprogram dalam C, tidak ada pemeriksaan batas array otomatis. Penyerang dapat memasukkan string panjang dengan perintah program sebagai input, dan ini menimpa tumpukan program dan dapat menyebabkan kontrol ditransfer ke kode berbahaya. Kerentanan ini telah dieksploitasi di banyak sistem lain yang diprogram dalam C atau C ++ sejak saat itu. Contoh ini menggambarkan dua aspek penting dari pemrograman sistem yang aman:
1. Kerentanan seringkali spesifik-bahasa. Pemeriksaan batas array otomatis dalam bahasa seperti Java, jadi ini bukan kerentanan yang dapat dieksploitasi dalam program Java. Namun, jutaan program ditulis dalam C dan C ++ karena ini memungkinkan pengembangan perangkat lunak yang lebih efisien. Jadi. hanya menghindari penggunaan bahasa-bahasa ini bukanlah pilihan yang realistis. 2. Kerentanan keamanan terkait erat dengan keandalan program. Contoh di atas menyebabkan program terkait macet, sehingga tindakan yang diambil untuk meningkatkan keandalan program juga dapat meningkatkan keamanan sistem.

13.4         Security Testing and Assurance

Penyerang dapat mencoba menemukan asumsi yang dibuat oleh pengembang sistem dan kemudian menantang asumsi ini untuk melihat apa yang terjadi. Mereka berada dalam posisi untuk menggunakan dan menjelajahi suatu sistem selama periode waktu tertentu dan menganalisanya dengan menggunakan perangkat lunak untuk menemukan kerentanan yang mungkin dapat mereka eksploitasi. Mereka mungkin, pada kenyataannya, memiliki lebih banyak waktu untuk mencari kerentanan daripada insinyur pengujian sistem, karena penguji juga harus fokus pada pengujian sistem. Anda dapat menggunakan kombinasi pengujian, analisis berbasis alat, dan verifikasi formal untuk memeriksa dan menganalisis keamanan sistem aplikasi:
1. Pengujian berbasis pengalaman Dalam kasus ini, sistem dianalisis terhadap jenis serangan yang diketahui oleh tim validasi. Ini mungkin melibatkan pengembangan kasus pengujian atau memeriksa kode sumber suatu sistem. Misalnya, untuk memeriksa bahwa sistem tidak rentan terhadap serangan keracunan SQL yang terkenal, Anda dapat menguji sistem menggunakan input yang menyertakan perintah SQL. Untuk memeriksa bahwa kesalahan buffer overflow tidak akan terjadi, Anda dapat memeriksa semua buffer input untuk melihat apakah program memeriksa apakah tugas untuk elemen buffer berada dalam batasan. Daftar periksa masalah keamanan yang diketahui dapat dibuat untuk membantu proses. Pemeriksaan apakah pedoman desain dan pemrograman untuk keamanan telah diikuti juga dapat dimasukkan dalam daftar periksa masalah keamanan.
2. Pengujian penetrasi Ini adalah bentuk pengujian berbasis pengalaman di mana dimungkinkan untuk memanfaatkan pengalaman dari luar tim pengembangan untuk menguji. sebuah sistem aplikasi. Tim pengujian penetrasi diberi tujuan untuk melanggar keamanan sistem. Mereka mensimulasikan serangan pada sistem dan menggunakan kecerdikan mereka untuk menemukan cara-cara baru untuk membahayakan keamanan sistem. Anggota tim pengujian penetrasi harus memiliki pengalaman sebelumnya dengan pengujian keamanan dan menemukan kelemahan keamanan dalam sistem.
3. Analisis berbasis alat Dalam pendekatan ini, alat keamanan seperti pemeriksa kata sandi digunakan untuk menganalisis sistem. Pemeriksa kata sandi mendeteksi kata sandi yang tidak aman seperti nama umum atau rangkaian huruf berturut-turut. Pendekatan ini benar-benar merupakan perpanjangan dari validasi berbasis pengalaman, di mana pengalaman kelemahan keamanan diwujudkan dalam alat yang digunakan. Analisis statis, tentu saja, jenis lain dari analisis berbasis alat, yang telah menjadi semakin digunakan. Analisis statis berbasis alat (Bab 12) adalah pendekatan yang sangat berguna untuk pemeriksaan keamanan. Analisis statis suatu program dapat dengan cepat memandu tim pengujian ke area program yang mungkin mencakup kesalahan dan kerentanan. Anomali yang diungkapkan dalam analisis statis dapat langsung diperbaiki atau dapat membantu mengidentifikasi tes yang perlu dilakukan untuk mengungkapkan apakah anomali ini benar-benar mewakili risiko sistem. Microsoft menggunakan analisis statis secara rutin untuk memeriksa perangkat lunaknya untuk kemungkinan kerentanan keamanan (Jenney 2013). Hewlett-Packard menawarkan alat yang disebut Fortify (Hewlett-Packard 2012) yang dirancang khusus untuk memeriksa program Java untuk kerentanan keamanan.
4. Verifikasi normal Saya telah membahas penggunaan verifikasi program formal pada Bab 10 dan 12. Pada dasarnya, ini melibatkan pembuatan formal, argumen matematis yang menunjukkan bahwa suatu program sesuai dengan spesifikasinya. Hall dan Chapman (Hall dan Chapman 2002) menunjukkan kelayakan membuktikan bahwa suatu sistem memenuhi persyaratan keamanan formal lebih dari 10 tahun yang lalu, dan telah ada sejumlah percobaan lain sejak itu. Namun, seperti di daerah lain, verifikasi formal untuk keamanan tidak banyak digunakan. Ini membutuhkan keahlian khusus dan tidak mungkin seefektif biaya analisis statis.

CHAPTER 14
Resilience Engineering

Pekerjaan mendasar pada ketahanan sistem dimulai pada komunitas sistem yang kritis terhadap keselamatan, di mana tujuannya adalah untuk memahami faktor-faktor apa yang menyebabkan kecelakaan dihindari dan selamat. Namun, meningkatnya jumlah serangan siber pada sistem jaringan berarti ketahanan sekarang sering dipandang sebagai masalah keamanan. Sangat penting untuk membangun sistem yang dapat menahan serangan siber jahat dan terus memberikan layanan kepada penggunanya.

14.1         Cybersecurity

Seperti halnya aspek-aspek lain dari ketergantungan sistem, cara mendasar melindungi terhadap serangan siber tergantung pada redundansi dan keragaman. Ingat bahwa redun-dancy berarti memiliki kapasitas cadangan dan sumber daya yang digandakan dalam suatu sistem. Keragaman berarti bahwa berbagai jenis peralatan, perangkat lunak, dan prosedur digunakan sehingga kegagalan umum lebih kecil kemungkinannya terjadi di sejumlah sistem. Contoh di mana redundansi dan keragaman berharga untuk ketahanan cyber adalah:
1. Untuk setiap sistem, salinan data dan perangkat lunak harus dipertahankan pada sistem komputer yang terpisah. Disk bersama harus dihindari jika memungkinkan. Ini mendukung pemulihan setelah serangan cyber yang berhasil (pemulihan dan pemulihan).
2. Otentikasi beragam multi-tahap dapat melindungi terhadap serangan kata sandi. Selain otentikasi login / kata sandi, langkah-langkah otentikasi tambahan mungkin terlibat yang mengharuskan pengguna untuk memberikan beberapa informasi pribadi atau kode yang dibuat oleh perangkat seluler mereka (resistansi) .
3. Server kritis mungkin terlalu banyak disediakan; yaitu, mereka mungkin lebih kuat daripada yang dibutuhkan untuk menangani beban yang diharapkan. Kapasitas cadangan berarti bahwa serangan dapat dilawan tanpa perlu menurunkan respons normal server. Selain itu, jika server lain rusak, kapasitas cadangan tersedia untuk menjalankan perangkat lunak mereka saat sedang diperbaiki (resistansi dan pemulihan).

14.2         Sociotechnical resilience

Pada dasarnya, rekayasa ketahanan lebih bersifat sosioteknik daripada aktivitas teknis. Seperti yang saya jelaskan di Bab 10, sistem sosioteknik mencakup perangkat keras, perangkat lunak, dan orang-orang dan dipengaruhi oleh budaya, kebijakan, dan prosedur organisasi yang memiliki dan menggunakan sistem. Untuk merancang sistem yang tangguh, Anda harus memikirkan desain sistem sosioteknik dan tidak hanya fokus pada perangkat lunak. Rekayasa ketahanan berkaitan dengan kejadian eksternal yang merugikan yang dapat menyebabkan kegagalan sistem. Berurusan dengan peristiwa ini seringkali lebih mudah dan lebih efektif dalam sistem sosioteknik yang lebih luas.
Misalnya, sistem Mentcare memelihara data pasien yang rahasia, dan serangan siber eksternal yang mungkin bertujuan untuk mencuri data itu. Perlindungan teknis seperti otentikasi dan enkripsi dapat digunakan untuk melindungi data, tetapi ini tidak efektif jika penyerang memiliki akses ke kredensial pengguna sistem asli. Anda dapat mencoba menyelesaikan masalah ini di tingkat teknis dengan menggunakan prosedur otentikasi yang lebih kompleks. Namun, prosedur ini mengganggu pengguna dan dapat menyebabkan kerentanan saat mereka menuliskan informasi otentikasi. Strategi yang lebih baik mungkin untuk memperkenalkan kebijakan dan prosedur organisasi yang menekankan pentingnya tidak membagikan kredensial login dan yang memberi tahu pengguna tentang cara mudah untuk membuat dan memelihara kata sandi yang kuat.

14.3         Resilient system design

Sistem yang tangguh dapat menahan dan pulih dari insiden buruk seperti kegagalan perangkat lunak dan serangan siber. Mereka dapat memberikan layanan kritis dengan gangguan minimal dan dapat dengan cepat kembali ke kondisi operasi normal setelah insiden terjadi. Dalam mendesain sistem yang tangguh, Anda harus mengasumsikan bahwa kegagalan sistem atau penetrasi oleh penyerang akan terjadi, dan Anda harus memasukkan fitur yang berlebihan dan beragam untuk mengatasi peristiwa-peristiwa buruk ini. Sistem desain untuk ketahanan melibatkan dua aliran pekerjaan yang saling terkait:
1 . Mengidentifikasi layanan dan aset penting Layanan dan aset penting adalah elemen-elemen dari sistem yang memungkinkan suatu sistem untuk memenuhi tujuan utamanya. Sebagai contoh, tujuan utama dari sistem yang menangani pengiriman ambulans dalam menanggapi panggilan darurat adalah untuk mendapatkan bantuan kepada orang-orang yang membutuhkannya secepat mungkin. Layanan penting adalah mereka yang terkait dengan menerima panggilan dan mengeluarkan ambulans ke darurat medis. Layanan lain seperti panggilan log-ging dan pelacakan ambulans kurang penting.
2. Mendesain komponen sistem yang mendukung pengenalan masalah, resistensi, pemulihan, dan pemulihan kembali Misalnya, dalam sistem pengiriman ambulans, pengawas waktu (lihat Bab 12) mungkin disertakan untuk mendeteksi jika sistem tidak merespons peristiwa. Operator mungkin harus mengautentikasi dengan token perangkat keras untuk menolak kemungkinan akses tidak sah. Jika sistem gagal, panggilan dapat dialihkan ke pusat lain sehingga layanan penting tetap terjaga. Salinan database sistem dan perangkat lunak pada perangkat keras alternatif dapat dipertahankan untuk memungkinkan pemulihan setelah pemadaman.

CHAPTER 15
Software Reuse

15.1         The Reuse Landscape

Selama 20 tahun terakhir, banyak teknik telah dikembangkan untuk mendukung penggunaan kembali perangkat lunak. Teknik-teknik ini mengeksploitasi fakta bahwa sistem dalam domain aplikasi yang sama serupa dan memiliki potensi untuk digunakan kembali, bahwa penggunaan kembali dimungkinkan pada tingkat yang berbeda dari fungsi sederhana hingga aplikasi yang lengkap, dan bahwa standar untuk komponen yang dapat digunakan kembali memfasilitasi penggunaan kembali. Gambar 15.3 menunjukkan "lanskap penggunaan ulang" - cara berbeda untuk menerapkan penggunaan kembali perangkat lunak. Masing-masing pendekatan untuk menggunakan kembali dijelaskan secara singkat pada Gambar 15.4. Diberikan berbagai teknik ini untuk digunakan kembali, pertanyaan kuncinya adalah "teknik mana yang paling tepat untuk digunakan dalam situasi tertentu?" Jelas, jawaban untuk pertanyaan ini tergantung pada persyaratan untuk sistem yang dikembangkan, teknologi dan aset yang dapat digunakan kembali tersedia, dan keahlian tim pengembangan. Faktor-faktor kunci yang harus Anda pertimbangkan ketika merencanakan penggunaan kembali adalah:
1. Jadwal pengembangan untuk perangkat lunak Jika perangkat lunak harus dikembangkan dengan cepat, Anda harus mencoba untuk menggunakan kembali sistem yang lengkap daripada masing-masing komponen. Meskipun kecocokan dengan persyaratan mungkin tidak sempurna, pendekatan ini meminimalkan jumlah pengembangan yang diperlukan.
2.Umur perangkat lunak yang diharapkan Jika Anda mengembangkan sistem umur panjang, Anda harus fokus pada pemeliharaan sistem. Anda seharusnya tidak hanya memikirkan manfaat langsung dari penggunaan kembali tetapi juga implikasi jangka panjangnya. Selama masa pakainya, Anda harus menyesuaikan sistem dengan persyaratan baru, yang berarti membuat perubahan pada bagian-bagian sistem. Jika Anda tidak memiliki akses ke kode sumber komponen yang dapat digunakan kembali, Anda dapat memilih untuk menghindari komponen dan sistem yang tidak tersedia dari pemasok eksternal. Pemasok ini mungkin tidak dapat melanjutkan dukungan untuk perangkat lunak yang digunakan kembali. Anda dapat memutuskan bahwa lebih aman untuk menggunakan kembali sistem dan komponen open-source (Bab 7) karena ini berarti Anda dapat mengakses dan menyimpan salinan kode sumber.
3. Latar belakang, keterampilan dan pengalaman tim pengembangan Semua teknologi yang digunakan kembali cukup rumit, dan Anda perlu cukup banyak waktu untuk memahami dan menggunakannya secara efektif. Oleh karena itu, Anda harus memfokuskan upaya reuse Anda di area di mana tim pengembangan Anda memiliki keahlian.
4. Kekritisan perangkat lunak dan persyaratan non-fungsionalnya Untuk sistem kritis yang harus disertifikasi oleh regulator eksternal, Anda mungkin harus menciptakan keselamatan atau kasus keamanan untuk sistem (dibahas pada Bab 12). Ini sulit jika Anda tidak memiliki akses ke kode sumber perangkat lunak. Jika perangkat lunak Anda memiliki persyaratan kinerja yang ketat, mungkin tidak mungkin untuk menggunakan strategi seperti rekayasa model (MDE) (Bab 5). MDE bergantung pada menghasilkan kode dari model sistem khusus domain yang dapat digunakan kembali. Namun, generator kode yang digunakan dalam MDE sering menghasilkan kode yang relatif tidak efisien.
5. Domain aplikasi Dalam banyak domain aplikasi, seperti sistem informasi manufaktur dan medis, ada produk generik yang dapat digunakan kembali dengan mengonfigurasinya ke situasi lokal. Ini adalah salah satu pendekatan paling efektif untuk digunakan kembali, dan hampir selalu lebih murah untuk membeli daripada membangun sistem baru.
6. Platform tempat sistem akan menjalankan Beberapa model komponen, seperti .NET, khusus untuk platform Microsoft. Demikian pula, sistem aplikasi generik mungkin khusus untuk platform, dan Anda hanya dapat menggunakannya kembali jika sistem Anda dirancang untuk platform yang sama.

15.2         Application Frameworks

Fayad dan Schmidt (Fayad dan Schmidt 1997) membahas tiga kelas kerangka kerja lainnya:
1. Kerangka kerja infrastruktur sistem mendukung pengembangan infrastruktur sistem seperti komunikasi, antarmuka pengguna, dan penyusun.
2. Kerangka kerja integrasi perangkat lunak terdiri dari seperangkat standar dan kelas objek terkait yang mendukung komunikasi komponen dan pertukaran informasi. Contoh dari kerangka kerja ini termasuk Microsoft .NET dan Enterprise Java Beans (EJB). Kerangka kerja ini memberikan dukungan untuk model komponen yang terstandar, seperti dibahas dalam Bab 16.
3. Kerangka kerja aplikasi kejutan berkaitan dengan domain aplikasi spesifik seperti telekomunikasi atau sistem keuangan (Baumer et al. 1997). Ini menanamkan pengetahuan domain aplikasi dan mendukung pengembangan aplikasi pengguna akhir. Ini sekarang tidak banyak digunakan dan sebagian besar telah digantikan oleh lini produk perangkat lunak.

Aplikasi yang dibangun menggunakan kerangka kerja dapat menjadi dasar untuk digunakan kembali lebih lanjut melalui konsep lini produk perangkat lunak atau keluarga aplikasi. Karena aplikasi ini dibangun menggunakan kerangka kerja, memodifikasi anggota keluarga untuk membuat contoh sistem seringkali merupakan proses yang mudah. Ini melibatkan penulisan ulang kelas dan metode konkret yang telah Anda tambahkan ke kerangka kerja. Pekerjaan adalah pendekatan yang sangat efektif untuk digunakan kembali. Namun, biayanya mahal untuk dimasukkan ke dalam proses pengembangan perangkat lunak karena proses itu rumit dan butuh waktu beberapa bulan untuk belajar menggunakannya. Mungkin sulit dan mahal untuk mengevaluasi kerangka kerja yang tersedia untuk memilih yang paling tepat. Aplikasi berbasis kerangka debugging lebih sulit daripada debugging kode asli karena Anda mungkin tidak memahami bagaimana metode kerangka kerja berinteraksi. Alat debugging dapat memberikan informasi tentang komponen kerangka yang digunakan kembali, yang pengembang tidak mengerti.

15.3         Software product lines

Kerangka kerja aplikasi dan lini produk perangkat lunak memiliki banyak kesamaan. Keduanya mendukung arsitektur dan komponen yang sama, dan membutuhkan pengembangan baru untuk membuat versi sistem tertentu. Perbedaan utama antara pendekatan ini adalah sebagai berikut:
1. Kerangka kerja aplikasi bergantung pada fitur berorientasi objek seperti warisan dan polimorfisme untuk mengimplementasikan ekstensi ke kerangka kerja. Secara umum, frameworkcode tidak dimodifikasi, dan kemungkinan modifikasi terbatas pada apa pun yang didukung oleh framework. Lini produk perangkat lunak tidak perlu dibuat menggunakan pendekatan berorientasi objek. Komponen aplikasi diubah, dihapus, atau ditulis ulang. Tidak ada batasan, pada prinsipnya setidaknya, untuk perubahan yang dapat dibuat.
2. Kerangka kerja aplikasi yang paling memberikan dukungan umum daripada dukungan domain-spesifik. Misalnya, ada kerangka kerja aplikasi untuk membuat aplikasi berbasis web. Lini produk perangkat lunak biasanya menyertakan informasi domain dan plat-form yang terperinci. Misalnya, mungkin ada lini produk perangkat lunak yang memperhatikan aplikasi berbasis web untuk manajemen catatan kesehatan.
3. Lini produk perangkat lunak seringkali mengontrol aplikasi untuk peralatan. Sebagai contoh, mungkin ada lini produk perangkat lunak untuk keluarga printer. Ini berarti bahwa lini produk harus menyediakan dukungan untuk antarmuka perangkat keras. Kerangka kerja aplikasi biasanya berorientasi perangkat lunak, dan mereka biasanya tidak termasuk komponen interaksi perangkat keras.
4. Lini produk perangkat lunak terdiri dari keluarga aplikasi terkait, dimiliki oleh organisasi yang sama. Saat Anda membuat aplikasi baru, titik awal Anda seringkali merupakan anggota terdekat dari keluarga aplikasi, bukan aplikasi inti generik.

15.4         Application system reuse

Pendekatan ini untuk penggunaan kembali perangkat lunak telah sangat banyak diadopsi oleh perusahaan besar sejak akhir 1990-an, karena ia menawarkan manfaat yang signifikan atas pengembangan perangkat lunak yang disesuaikan:
1. Seperti dengan jenis lain penggunaan kembali, penyebaran yang lebih cepat dari sistem yang andal mungkin mungkin.

2. Adalah mungkin untuk melihat fungsionalitas apa yang disediakan oleh aplikasi, sehingga lebih mudah untuk menilai apakah mereka cocok atau tidak. Perusahaan lain mungkin sudah menggunakan aplikasi ini, sehingga pengalaman sistem tersedia.

3. Beberapa risiko pengembangan dihindari dengan menggunakan perangkat lunak yang ada. Namun, pendekatan ini memiliki risiko sendiri, seperti yang saya bahas di bawah ini.

4. Bisnis dapat fokus pada kegiatan inti mereka tanpa harus mencurahkan banyak sumber daya untuk pengembangan sistem TI.

5. Saat platform operasi berkembang, pembaruan teknologi dapat disederhanakan karena ini adalah tanggung jawab vendor sistem aplikasi daripada pelanggan

CHAPTER 16
Component based software engineering

Rekayasa perangkat lunak berbasis komponen (CBSE) muncul pada akhir 1990-an sebagai pendekatan untuk pengembangan sistem perangkat lunak yang didasarkan pada penggunaan kembali komponen perangkat lunak. Penciptaannya dimotivasi oleh frustrasi bahwa pengembangan berorientasi objek tidak menyebabkan penggunaan kembali yang luas, seperti yang telah disarankan sebelumnya. Kelas objek tunggal terlalu rinci dan spesifik dan sering harus diikat dengan aplikasi pada waktu kompilasi. Anda harus memiliki pengetahuan terperinci tentang kelas untuk menggunakannya, yang biasanya berarti bahwa Anda harus memiliki kode sumber komponen. Oleh karena itu, menjual atau mendistribusikan objek sebagai komponen yang dapat digunakan kembali secara individu adalah mustahil.

16.1         Components and Component models

Cara berpikir yang berguna tentang komponen adalah sebagai penyedia satu atau lebih layanan, bahkan jika komponen tersebut tertanam daripada diimplementasikan sebagai layanan. Ketika suatu sistem membutuhkan sesuatu untuk dilakukan, ia memanggil komponen untuk menyediakan layanan itu tanpa peduli di mana komponen itu dieksekusi atau bahasa pemrograman yang digunakan untuk mengembangkan komponen. Misalnya, komponen dalam sistem yang digunakan di perpustakaan umum mungkin menyediakan layanan pencarian yang memungkinkan pengguna untuk mencari katalog perpustakaan. Komponen yang mengubah dari satu format grafis ke format lain (misalnya, TIFF ke JPEG) menyediakan layanan konversi data dan sebagainya. Melihat komponen sebagai penyedia layanan menekankan dua karakteristik penting dari komponen yang dapat digunakan kembali:

1. Komponen tersebut merupakan entitas yang dapat dieksekusi independen yang ditentukan oleh antar-wajahnya. Anda tidak perlu mengetahui kode sumbernya untuk menggunakannya. Ia dapat direferensikan sebagai layanan eksternal atau dimasukkan secara langsung dalam suatu program.

2. Layanan yang ditawarkan oleh suatu komponen tersedia melalui suatu antarmuka, dan semua interaksi dilakukan melalui antarmuka itu. Antarmuka komponen dinyatakan dalam operasi parameter, dan keadaan internalnya tidak pernah diekspos.

Pada prinsipnya, semua komponen memiliki dua antarmuka terkait. Antarmuka ini mencerminkan layanan yang disediakan oleh komponen dan layanan yang diperlukan komponen untuk beroperasi dengan benar:

1. Antarmuka "menyediakan" mendefinisikan layanan yang disediakan oleh komponen. Antarmuka ini adalah API komponen. Ini mendefinisikan metode yang dapat dipanggil oleh pengguna komponen. Dalam diagram komponen UML, antarmuka "menyediakan" untuk komponen ditunjukkan oleh lingkaran di akhir garis dari ikon komponen.

2. Antarmuka "wajib" menentukan layanan yang harus disediakan oleh komponen lain dalam sistem jika suatu komponen untuk beroperasi dengan benar. Jika layanan ini tidak tersedia, maka komponen tidak akan berfungsi. Ini tidak membahayakan independensi atau penerapan komponen karena antarmuka “memerlukan” tidak menentukan bagaimana layanan ini harus disediakan. Dalam UML, simbol untuk antarmuka "memerlukan" adalah setengah lingkaran di ujung garis dari ikon komponen. Perhatikan bahwa "menyediakan" dan "membutuhkan" ikon antarmuka dapat cocok bersama seperti bola dan soket.

16.2         CBSE Processes

Proses CBSE adalah proses perangkat lunak yang mendukung rekayasa perangkat lunak berbasis komponen. Mereka memperhitungkan kemungkinan penggunaan kembali dan berbagai kegiatan proses yang terlibat dalam mengembangkan dan menggunakan komponen yang dapat digunakan kembali. menyajikan gambaran umum proses di CBSE. Pada level tertinggi, ada dua jenis proses CBSE:

1. Pengembangan untuk digunakan kembali Proses ini berkaitan dengan pengembangan komponen atau layanan yang akan digunakan kembali dalam aplikasi lain. Biasanya melibatkan komponen umum yang sudah ada.

2. Pengembangan dengan menggunakan kembali Proses ini adalah proses pengembangan aplikasi baru menggunakan komponen dan layanan yang ada.

Proses ini memiliki tujuan yang berbeda dan oleh karena itu mencakup berbagai kegiatan. Dalam pengembangan untuk proses penggunaan kembali, tujuannya adalah untuk menghasilkan satu atau lebih komponen yang dapat digunakan kembali. Anda tahu komponen yang akan Anda kerjakan, dan Anda memiliki akses ke kode sumbernya untuk menggeneralisasikannya. Dalam pengembangan dengan penggunaan kembali, Anda tidak tahu komponen apa yang tersedia, jadi Anda perlu menemukan komponen ini dan merancang sistem Anda untuk memanfaatkannya secara paling efektif.
Anda mungkin tidak memiliki akses ke kode sumber komponen. bahwa proses dasar CBSE dengan dan untuk digunakan kembali memiliki proses pendukung yang berkaitan dengan akuisisi komponen, manajemen komponen, dan sertifikasi komponen:

1. Pengambilan komponen adalah proses memperoleh komponen untuk digunakan kembali atau dikembangkan menjadi komponen yang dapat digunakan kembali. Ini mungkin melibatkan pengaksesan komponen atau layanan yang dikembangkan secara lokal atau menemukan komponen-komponen ini dari sumber eksternal.

2. Manajemen komponen berkenaan dengan mengelola komponen yang dapat digunakan kembali perusahaan, memastikan bahwa komponen-komponen tersebut didaftarkan, disimpan, dan dibuat tersedia untuk digunakan kembali. Sertifikasi komponen adalah proses pengecekan komponen dan mensertifikasi bahwa komponen tersebut memenuhi spesifikasinya.
Komponen yang dikelola oleh suatu organisasi dapat disimpan dalam repositori komponen yang mencakup komponen dan informasi tentang penggunaannya.

16.3         Component composition

Komposisi komponen adalah proses mengintegrasikan komponen satu sama lain, dan dengan "kode lem" yang ditulis khusus untuk membuat sistem atau komponen lain. Dari kiri ke kanan diagram ini menggambarkan komposisi berurutan, komposisi hierarkis, dan komposisi aditif. Dalam diskusi di bawah ini, saya berasumsi bahwa Anda menyusun dua komponen (A dan B) untuk membuat komponen baru:

1. Komposisi yang penting Dalam komposisi yang berurutan, Anda membuat komponen baru dari dua komponen yang ada dengan memanggil yang sudah ada komponen secara berurutan. Anda dapat menganggap komposisi sebagai komposisi dari "menyediakan antarmuka". Artinya, layanan yang ditawarkan oleh komponen A dipanggil, dan hasilnya dikembalikan oleh A kemudian digunakan dalam panggilan ke layanan yang ditawarkan oleh komponen B. Komponen tidak saling memanggil dalam komposisi berurutan tetapi dipanggil oleh aplikasi eksternal. Jenis komposisi ini dapat digunakan dengan komponen yang disematkan atau layanan. Beberapa kode lem tambahan mungkin diperlukan untuk memanggil layanan komponen dengan urutan yang benar dan untuk memastikan bahwa hasil yang disampaikan oleh komponen A kompatibel dengan input yang diharapkan oleh komponen B. "Kode lem" mengubah output ini menjadi bentuk yang diharapkan oleh komponen B.

2. Komposisi hirarki Jenis komposisi ini terjadi ketika satu komponen memanggil langsung pada layanan yang disediakan oleh komponen lain. Yaitu, komponen A memanggil komponen B. Komponen yang dipanggil menyediakan layanan yang diperlukan oleh komponen panggilan. Oleh karena itu, antarmuka "menyediakan" dari komponen yang disebut harus kompatibel dengan antarmuka "memerlukan" komponen pemanggil. Komponen A memanggil komponen B secara langsung, dan, jika antarmuka mereka cocok, mungkin tidak perlu kode tambahan . Namun, jika ada ketidaksesuaian antara antarmuka “membutuhkan” A dan antarmuka “menyediakan” B, maka beberapa kode konversi mungkin diperlukan. Karena layanan tidak memiliki antarmuka "memerlukan", mode komposisi ini tidak digunakan ketika komponen diterapkan ketika layanan diakses melalui web.

3. Komposisi tambahan Ini terjadi ketika dua atau lebih komponen disatukan (ditambahkan) untuk membuat komponen baru, yang menggabungkan fungsi mereka. Antarmuka "pro-vides" dan antarmuka "memerlukan" komponen baru adalah kombinasi dari antarmuka yang sesuai dalam komponen A dan B. Komponen-komponen tersebut dipanggil secara terpisah melalui antarmuka eksternal dari komponen yang dikomposisikan dan dapat dipanggil dalam urutan apa pun. A dan B tidak tergantung dan tidak saling memanggil. Jenis komposisi ini dapat digunakan dengan komponen yang disematkan atau layanan.

CHAPTER 17
Distributed software engineering

Sebagian besar sistem berbasis komputer sekarang merupakan sistem terdistribusi. Sistem terdistribusi adalah sistem yang melibatkan beberapa komputer daripada satu aplikasi yang berjalan pada satu mesin. Bahkan aplikasi yang tampaknya mandiri pada PC atau laptop, seperti editor gambar, adalah sistem terdistribusi.
Mereka mengeksekusi pada sistem komputer tunggal tetapi seringkali bergantung pada sistem cloud jarak jauh untuk memperbarui, menyimpan, dan layanan lainnya. Tanenbaum dan Van Steen (Tanenbaum dan Van Steen 2007) mendefinisikan sistem terdistribusi menjadi “kumpulan komputer independen yang tampak bagi pengguna sebagai sistem koheren tunggal”.

17.1         Distributed systems

Skalabilitas suatu sistem mencerminkan kemampuannya untuk memberikan layanan berkualitas tinggi karena tuntutan pada sistem meningkat. Tiga dimensi skalabilitas adalah ukuran, distribusi, dan pengelolaan.

1.Ukuran Seharusnya dimungkinkan untuk menambahkan lebih banyak sumber daya ke sistem untuk mengatasi peningkatan jumlah pengguna. Idealnya, kemudian, ketika jumlah pengguna meningkat, sistem harus meningkatkan ukuran secara otomatis untuk menangani peningkatan jumlah pengguna.

2. Distribusi Harus dimungkinkan untuk secara geografis membubarkan komponen-komponen suatu sistem tanpa menurunkan kinerjanya. Ketika komponen baru ditambahkan, seharusnya tidak masalah di mana ini berada. Perusahaan-perusahaan besar sering dapat menggunakan sumber daya komputasi di berbagai fasilitas mereka di seluruh dunia.

3. Pengelolaan Harus dimungkinkan untuk mengelola suatu sistem karena ukurannya bertambah, bahkan jika bagian-bagian dari sistem tersebut terletak di organisasi independen. Ini adalah salah satu tantangan skala yang paling sulit karena melibatkan manajer yang berkomunikasi dan menyetujui kebijakan manajemen. Dalam praktiknya, pengelolaan suatu sistem seringkali merupakan faktor yang membatasi sejauh mana hal itu dapat ditingkatkan.

17.2         Client server computing

antara lapisan-lapisan ini. Ini memungkinkan setiap lapisan untuk didistribusikan ke komputer yang berbeda. Gambar 17.6 mengilustrasikan model ini, menunjukkan aplikasi yang terstruktur menjadi empat lapisan:

1.Sebuah lapisan presentasi yang berkaitan dengan penyajian informasi kepada pengguna dan mengelola semua interaksi pengguna.
2. Lapisan penanganan data yang mengelola data yang diteruskan ke dan dari klien. Lapisan ini dapat menerapkan pemeriksaan pada data, menghasilkan halaman web, dan sebagainya.
3. Lapisan pemrosesan aplikasi yang berkaitan dengan penerapan logika aplikasi dan menyediakan fungsionalitas yang diperlukan untuk pengguna akhir.
4. Lapisan basis data yang menyimpan data dan menyediakan manajemen transaksi dan layanan permintaan.

17.3         Architectural patterns for distributed systems

Pada bagian ini, saya membahas lima gaya arsitektur:
1.Master-slave architecture, yang digunakan dalam sistem waktu nyata di mana waktu respons interaksi guaran-teed diperlukan.
2. Arsitektur client-server dua tingkat, yang digunakan untuk sistem client-server sederhana dan dalam situasi di mana penting untuk memusatkan sistem untuk alasan keamanan.
3. Arsitektur client-server multi-tier, yang digunakan ketika server harus memproses volume transaksi yang tinggi.
4. Didistribusikan arsitektur komponen, yang digunakan ketika sumber daya dari sistem dan basis data yang berbeda perlu digabungkan, atau sebagai model implementasi untuk sistem klien-server multi-tier.
5. Arsitektur arsitektur peer-to-peer, yang digunakan ketika klien bertukar secara lokal informasi yang tersimpan dan peran server adalah untuk memperkenalkan klien satu sama lain. Ini juga dapat digunakan ketika sejumlah besar perhitungan independen mungkin harus dibuat.

17.4         Software as a service

Gagasan perangkat lunak sebagai layanan (SaaS) ini melibatkan hosting perangkat lunak dari jarak jauh dan menyediakan akses ke sana melalui Internet. Elemen-elemen kunci SaaS adalah sebagai berikut:
1.Software dikerahkan di server (atau lebih umum di cloud) dan diakses melalui browser web. Ini tidak digunakan pada PC lokal.
2. Perangkat lunak ini dimiliki dan dikelola oleh penyedia perangkat lunak daripada organisasi yang menggunakan perangkat lunak tersebut.
3. Pengguna dapat membayar perangkat lunak sesuai dengan berapa banyak penggunaan yang mereka lakukan atau melalui tahunan. atau berlangganan bulanan. Terkadang perangkat lunak ini gratis bagi siapa saja untuk digunakan, tetapi pengguna kemudian harus setuju untuk menerima iklan, yang mendanai layanan perangkat lunak.

CHAPTER 18
Service oriented software engineering

18.1         Service oriented Architecture

standar dasar untuk arsitektur berorientasi layanan adalah:
1.SOAP Ini adalah standar pertukaran pesan yang mendukung komunikasi antar layanan. Ini mendefinisikan komponen esensial dan opsional dari pesan yang dilewati antar layanan. Layanan dalam arsitektur berorientasi layanan kadang-kadang disebut layanan berbasis SOAP.
2.WSDL Bahasa Deskripsi Layanan Web (WSDL) adalah standar untuk definisi antarmuka layanan. Ini menetapkan bagaimana operasi layanan (nama operasi, parameter, dan jenisnya) dan binding layanan harus didefinisikan.
3.WS-BPEL Ini adalah standar untuk bahasa alur kerja yang digunakan untuk menentukan program proses yang melibatkan beberapa layanan berbeda.

18.2         RESTful Service

Web adalah contoh dari sistem yang memiliki arsitektur yang tenang. Halaman web adalah sumber daya, dan pengidentifikasi unik dari halaman web adalah URL-nya. Protokol web http dan https didasarkan pada empat tindakan, yaitu POST, GET, PUT, dan DELETE. Peta ini ke operasi sumber daya dasar:
1. POST digunakan untuk membuat sumber daya. Ini memiliki data terkait yang menentukan sumber daya.
2. GET digunakan untuk membaca nilai sumber daya dan mengembalikannya ke pemohon dalam representasi yang ditentukan, seperti XHTML, yang dapat dirender dalam browser web .
3. PUT digunakan untuk perbarui nilai sumber daya.
4. DELETE digunakan untuk menghapus sumber daya.

18.3         Service engineering

Service engineering adalah proses pengembangan layanan untuk digunakan kembali dalam aplikasi berorientasi layanan. Ini memiliki banyak kesamaan dengan rekayasa komponen. Teknisi layanan harus memastikan bahwa layanan tersebut mewakili abstraksi yang dapat digunakan kembali yang dapat berguna dalam sistem yang berbeda. Mereka harus merancang dan mengembangkan fungsionalitas yang umumnya bermanfaat yang terkait dengan abstraksi itu dan memastikan bahwa layanan ini kuat dan dapat diandalkan. Mereka harus mendokumentasikan layanan sehingga dapat ditemukan dan dipahami oleh pengguna potensial.
ada tiga tahapan logis dalam proses rekayasa layanan:
1. Identifikasi calon layanan, di mana Anda mengidentifikasi kemungkinan layanan yang mungkin diimplementasikan dan mendefinisikan persyaratan layanan.
2. Desain layanan, di mana Anda merancang antarmuka layanan logis dan antarmuka implementasinya (berbasis SOAP dan atau tenang).
3. Implementasi layanan dan penyebaran, di mana Anda menerapkan dan menguji layanan. dan membuatnya tersedia untuk digunakan.

18.4         Service composition

Prinsip mendasar dari rekayasa perangkat lunak berorientasi layanan adalah Anda menyusun dan mengonfigurasi layanan untuk membuat layanan komposit baru. Ini dapat diintegrasikan dengan antarmuka pengguna yang diimplementasikan dalam browser untuk membuat aplikasi web, atau mereka dapat digunakan sebagai komponen dalam beberapa komposisi layanan lainnya. Layanan yang terlibat dalam komposisi dapat dikembangkan secara khusus untuk aplikasi, layanan bisnis yang dikembangkan dalam perusahaan, atau layanan dari penyedia eksternal. Baik layanan berbasis RESTful dan SOAP dapat dikomposisikan untuk menciptakan layanan dengan fungsionalitas yang diperluas.
Banyak perusahaan telah mengubah aplikasi perusahaan mereka menjadi sistem yang berorientasi layanan, di mana blok bangunan aplikasi dasar adalah layanan daripada komponen. Ini memungkinkan untuk digunakan kembali secara luas di dalam perusahaan. Kami sekarang melihat munculnya aplikasi antar-organisasi antara pemasok tepercaya, yang menggunakan layanan satu sama lain. Realisasi akhir dari visi jangka panjang dari sistem yang berorientasi layanan akan bergantung pada pengembangan "pasar layanan," di mana layanan dibeli dari pemasok eksternal yang tepercaya.