TUGAS 14 JARINGAN KOMPUTER

TUGAS 13 JARINGAN KOMPUTER

Tugas Rekayasa Perangkat Lunak 6

Ringkasan BAB 8 Pengujian

- Pengujian adalah metode yang dinamis untuk verifikasi dan validasi, di mana perangkat lunak untuk diuji dilaksanakan dengan hati-hati dirancang kasus uji dan perilaku sistem software diamati. Sebuah test case adalah seperangkat input dan kondisi pengujian bersama dengan hasil yang diharapkan dari pengujian. Sebuah test suite adalah seperangkat kasus uji yang umumnya dijalankan bersama-sama untuk menguji beberapa spesifik tingkah laku. Selama pengujian hanya kegagalan sistem yang diamati, dari mana kehadiran kesalahan disimpulkan; kegiatan yang terpisah harus dilakukan untuk mengidentifikasi kesalahan dan menghapus mereka.

- Tujuan dari pengujian adalah untuk meningkatkan kepercayaan dalam kebenaran perangkat lunak. Untuk ini, himpunan kasus uji yang digunakan untuk pengujian harus sedemikian rupa sehingga untuk cacat pada sistem, ada kemungkinan menjadi kasus uji yang akan mengungkapkannya. Untuk memastikan hal ini, penting bahwa uji kasus secara hati-hati dirancang dengan maksud mengungkapkan cacat.

- Karena keterbatasan metode verifikasi untuk tahap awal, desain dan kesalahan persyaratan juga muncul dalam kode. Pengujian ini digunakan untuk mendeteksi kesalahan ini juga, selain kesalahan diperkenalkan selama coding tahap. Oleh karena itu, berbagai tingkat pengujian yang sering digunakan untuk mendeteksi cacat disuntikkan selama tahap-tahap yang berbeda. Tingkat pengujian umum digunakan adalah unit testing, pengujian integrasi, pengujian sistem, dan pengujian penerimaan.

- Untuk menguji produk software, pengujian secara keseluruhan harus direncanakan, dan untuk menguji setiap unit diidentifikasi dalam rencana, uji kasus harus dirancang dengan hati-hati untuk mengungkapkan kesalahan dan ditetapkan dalam dokumen atau naskah tes.

- Ada dua pendekatan untuk merancang uji kasus: kotak hitam dan kotak putih.  Dalam pengujian black-box, logika internal dari sistem di bawah pengujian tidak dianggap dan uji kasus diputuskan dari spesifikasi atau persyaratan. Kesetaraan kelas partisi, analisis nilai batas, dan causeeffect grafik adalah contoh dari metode untuk memilih kasus uji untuk kotak hitam pengujian. pengujian berbasis negara adalah pendekatan lain di mana sistem dimodelkan sebagai mesin negara dan kemudian model ini digunakan untuk memilih uji kasus menggunakan beberapa transisi atau kriteria cakupan berbasis jalan. pengujian berbasis negara juga bisa dipandang sebagai abu-abu kotak pengujian dalam yang sering membutuhkan informasi lebih dari hanya persyaratan.

- Dalam pengujian white-box, uji kasus diputuskan berdasarkan logika internal dari program yang sedang diuji. Seringkali kriteria yang ditentukan, tetapi prosedur untuk memilih uji kasus untuk memenuhi kriteria yang tersisa untuk tester. Yang paling  Kriteria umum adalah cakupan pernyataan dan cakupan cabang.

- The metrik utama bunga selama pengujian adalah keandalan dari perangkat lunak di bawah pengujian. Jika cacat sedang login, keandalan dapat dinilai dalam hal dari tingkat kegagalan per minggu atau hari, meskipun model yang lebih baik untuk estimasi ada. Cakupan dicapai selama pengujian, dan efisiensi removal cacat, yang lainnya metrik bunga.

Tugas Rekayasa Perangkat Lunak 5

RINGKASAN BAB 7 CODING DAN PENGUJIAN UNIT

- Seperti membaca program adalah kegiatan jauh lebih umum daripada menulis program, tujuan dari kegiatan coding adalah untuk menghasilkan program yang, selain bebas dari cacat, mudah untuk memahami dan memodifikasi.

- Gunakan pemrograman terstruktur di mana program ini adalah urutan yang cocok tunggal single entry konstruksi exit membuat program yang mudah untuk memahami dan memverifikasi. praktek-praktek lainnya seperti menggunakan informasi bersembunyi, standar coding cocok, dan praktek pemrograman yang baik juga membantu meningkatkan pembacaan kode dan kualitas.

- Untuk pengembang, itu adalah yang paling efektif untuk mengembangkan kode secara bertahap. Hal ini dapat dilakukan dengan menulis kode sedikit demi sedikit, dan pengujian dan debugging setiap kenaikan sebelum menulis kode lebih. Atau, pengembangan uji-driven dapat diikuti di mana uji kasus yang ditulis pertama dan kemudian kode ditulis untuk lulus uji kasus ini. Meskipun coding dari modul umumnya dilakukan oleh programmer individu, alternatif adalah pasangan pemrograman, di mana coding dilakukan oleh sepasang programmer baik bersama-sama berkembang strategi, struktur data, algoritma dll

- Kode Berkembang perlu dikelola dengan baik. Hal ini dapat dilakukan melalui kontrol alat kode sumber yang tepat yang memungkinkan manajemen mudah dari versi yang berbeda yang bisa dibuat, serta mudah kehancuran perubahan yang perlu digulung kembali.

- Sebagai kode berubah dengan waktu, untuk memastikan bahwa kualitas kode tidak terus menurunkan karena evolusi, refactoring dapat dilakukan. Selama refactoring ada fungsi baru ditambahkan hanya perbaikan dilakukan agar desain kode membaik dengan penurunan kopling, peningkatan kohesi, dan lebih baik menggunakan hirarki.

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

- Sejumlah metrik ada untuk mengukur kualitas yang berbeda dari kode. Yang paling umum digunakan adalah metrik ukuran, karena mereka digunakan untuk menilai produktivitas orang dan sering digunakan dalam estimasi biaya. The ukuran paling umum adalah baris kode (LOC), yang juga digunakan di sebagian besar model biaya. Tujuan dari metrik kompleksitas adalah untuk mengukur kompleksitas perangkat lunak, seperti com plexity merupakan faktor penting yang mempengaruhi produktivitas proyek dan merupakan faktor dalam estimasi biaya. Sejumlah metrik yang berbeda ada, yang paling umum adalah kompleksitas cyclomatic, yang didasarkan pada logika internal program dan mendefinisikan kompleksitas sebagai jumlah siklus independen dalam grafik aliran program.

Tugas Rekayasa Perangkat Lunak 4

SOFTWARE ARSITEKTUR

- Setiap sistem yang kompleks terdiri dari subsistem yang berinteraksi di bawah kendali desain sistem sehingga sistem menyediakan perilaku yang diharapkan. Sebagai sistem perangkat lunak yang semakin menjadi didistribusikan dan lebih kompleks, arsitektur menjadi langkah penting dalam membangun sistem. Arsitektur juga merupakan tempat awal ketika properti seperti keandalan dan kinerja dapat dievaluasi untuk sistem, sebuah kemampuan yang semakin menjadi penting.

5.1 Peran Software Arsitektur

- Secara umum, arsitektur sistem memberikan pandangan tingkat yang sangat tinggi dari bagian-bagian dari sistem dan bagaimana mereka berhubungan untuk membentuk seluruh sistem. Setiap sistem yang kompleks dapat dipartisi dalam banyak cara berbeda. Hal yang sama berlaku untuk sistem-tidak ada struktur yang unik dari sistem.

- Deskripsi arsitektur sistem karena itu akan menggambarkan di perubahan struktur dari sistem. Pertanyaan alami berikutnya adalah mengapa harus tim membangun sistem perangkat lunak untuk beberapa pelanggan tertarik dalam menciptakan dan mendokumentasikan struktur dari sistem yang diusulkan.beberapa penting kegunaan software arsitektur:

1. Memahami dan komunikasi. Deskripsi arsitektur adalah utamanya untuk berkomunikasi arsitektur untuk berbagai pemangku kepentingan, yang di-clude pengguna yang akan menggunakan sistem, klien yang ditugaskan sistem, pembangun yang akan membangun sistem, dan, tentu saja. Melalui penjelasan ini para pemangku kepentingan memperoleh pemahaman tentang beberapa sifat makro dari sistem dan bagaimana sistem bermaksud untuk mengisi persyaratan fungsional dan kualitas.

2. Reuse. Jika seseorang ingin membangun sebuah produk perangkat lunak di mana komponen yang ada dapat digunakan kembali, maka arsitektur menjadi titik kunci. arsitektur harus mepilih sedemikian rupa bahwa komponen yang harus digunakan kembali dapat cocok dengan baik dan bersama-sama dengan komponen lain yang dapat dikembangkan. Arsitektur juga facili-tates menggunakan kembali antara produk-produk yang keluarga produk serupa dan bangunan sehingga bagian-bagian umum ini di berbeda tetapi produk serupa dapat digunakan kembali

3. Konstruksi dan Evolution. Arsitektur partisi sistem menjadi bagian-bagian, beberapa partisi arsitektur yang disediakan dapat digunakan secara alami untuk membangun sistem, yang juga mensyaratkan bahwa sistem akan dipecah menjadi bagian-bagian sehingga tim secara terpisah dapat bekerja pada bagian berbeda. bagian-bagian yang ditentukan dalam arsitektur relatif indepen-dent (ketergantungan antara bagian-bagian yang datang melalui hubungan mereka), mereka dapat dibangun secara mandiri.

4. Analisis. Hal ini sangat diinginkan jika dapat ditentukan beberapa sifat penting tentang tingkah laku dari sistem sebelum sistem ini benar-benar dibangun. Hal ini akan memungkinkan para desainer untuk mempertimbangkan alternatif dan memilih salah satu yang terbaik akan sesuai dengan kebutuhan.  Dalam beberapa proyek komunikasi mungkin sangat penting, tapi analisis kinerja rinci mungkin tidak diperlukan (karena sistem yang terlalu kecil atau dimaksudkan untuk hanya beberapa pengguna). Dalam beberapa sistem lain, analisis kinerja mungkin penggunaan utama arsitektur.

5.2 Arsitektur Views

- Dalam pandangan modul, sistem ini dipandang sebagai kumpulan unit kode, masing-masing menerapkan beberapa bagian dari fungsi sistem. Artinya, unsur-unsur utama dalam pandangan ini adalah modul. pandangan-pandangan ini adalah kode-based dan tidak secara eksplisit rep-membenci setiap struktur runtime dari sistem.

- Dalam komponen dan konektor sistem ini dipandang sebagai pembacaan entitas runtime Artinya, komponen adalah unit yang memiliki identitas dalam sistem mengeksekusi. Objects adalah sebuah kolektifitas benda, dan proses adalah contoh dari komponen. Sementara pelaksana adalah komponen yang harus berinteraksi dengan orang lain untuk mendukung layanan sistem. Konektor menyediakan sarana untuk interaksi ini.

- Pandangan alokasi berfokus pada bagaimana unit software erent dialokasikan ke sumber daya seperti perangkat keras, sistem file, dan orang-orang. Artinya, pandangan alokasi menentukan hubungan antara unsur-unsur perangkat lunak dan elemen lingkungan di mana sistem perangkat lunak dijalankan. Mereka mengekspos sifat struktural seperti dimana proses berjalan pada prosesor mana, dan bagaimana file sistem diatur pada sistem file.

- Deskripsi arsitektur terdiri dari pandangan jenis dengan setiap tampilan mengekspos beberapa struktur dari sistem. views modul menunjukkan bagaimana peranti lunak ini disusun sebagai satu set unit implementasi, C & C views menunjukkan bagaimana perangkat lunak ini disusun sebagai berinteraksi elemen runtime, dan pandangan alokasi menunjukkan bagaimana perangkat lunak berhubungan dengan struktur nonsoftware. Ketiga jenis pandang sistem yang sama membentuk arsitektur sistem.

- Perhatikan bahwa pandangan tersebut tidak berhubungan. Mereka semua merupakan sistem yang sama.

- Catatan tentang hubungan antara arsitektur dan desain adalah dalam rangka. Sebagai partisi sistem menjadi bagian-bagian yang lebih kecil dan menyusun sistem dari bagian-bagian ini juga merupakan tujuan dari desain. Ini bertujuan untuk mencapai tujuan yang sama dan tampaknya fundamental mengandalkan membagi dan menaklukkan aturan. Pertama, harus jelas bahwa arsitektur adalah desain dalam hal itu adalah dalam domain solusi dan berbicara tentang struktur dari sistem yang diusulkan. Selanjutnya, pandangan arsitektur memberikan tampilan tingkat tinggi dari sistem.

5.3 Komponen dan Konektor view

- Batas-batas antara arsitektur dan desain tingkat tinggi tidak sepenuhnya jelas. Pada tingkat arsitektur, salah satu kebutuhan untuk hanya menampilkan bagian-bagian yang diperlukan untuk melakukan evaluasi yang diinginkan. Struktur internal bagian-bagian ini tidak penting. Di sisi lain selama desain merancang struktur bagian-bagian. Namun, bagian mana dari struktur harus diperiksa terlebih dahulu. Dan arsitektur,desain adalah masalah pilihan. Secara umum, detail yang tidak diperlukan untuk melakukan jenis analisis yang ingin kita lakukan pada saat arsitektur yang tidak perlu dan harus dibiarkan untuk desain.

- Arsitektur sistem memiliki dua elemen utama yaitu,komponen dan konektor. Komponen biasanya elemen komputasi atau toko data yang memiliki beberapa kehadiran selama pelaksanaan sistem. Konektor menentukan sarana interaksi antara komponen-komponen ini. pandangan sistem dan komponen yang terhubung ke mana dan melalui konektor apa. Struktur pada dasarnya adalah sebuah grafik, dengan motivasional sebagai node dan konektor sebagai tepi.

5.3.1 Komponen

- Komponen adalah dari jenis komponen di mana jenis merupakan komponen generik, mendefinisikan komputasi umum dan interface komponen dari jenis yang harus memiliki. Perhatikan bahwa meskipun komponen memiliki tipe, di C & C tampilan arsitektur, kita memiliki komponen (yaitu, contoh aktual) dan tidak jenis. Contoh jenis ini adalah klien, server, filter, dll. Perbedaan domain mungkin memiliki jenis generik lainnya seperti kontroler, aktuator, dan sensor (untuk domain sistem kontrol).

- Dalam diagram mewakili C & C lihat arsitektur sistem, itu sangat diinginkan untuk memiliki perbedaan representasi untuk jenis komponen yang berbeda, sehingga jenis yg berbeda dapat diidentifikasi secara visual. Dalam diagram kotak-dan-line, sering semua komponen yang direpresentasikan sebagai kotak persegi panjang. Pendekatan seperti ini akan mengharuskan jenis komponen dijelaskan secara terpisah dan pembaca harus membaca deskripsi untuk mengetahui jenis-jenis komponen. Hal ini jauh lebih baik untuk menggunakan simbol yang berbeda/ notasi untuk setiap jenis komponen yg berbeda.

5.3.2 Konektor

- Komponen yang berbeda dari sistem cenderung berinteraksi sementara sistem dalam operasi untuk menyediakan layanan yang diharapkan dari sistem. Interaksi antar komponen dapat melalui cara sederhana yang didukung oleh infrastruktur pelaksanaan proses yang mendasari sistem operasi. Misalnya, komponen dapat berinteraksi dengan yang lain menggunakan mekanisme panggilan prosedur (konektor), yang disediakan oleh lingkungan runtime untuk bahasa pemrograman. Namun, interaksi mungkin melibatkan mekanisme yang lebih kompleks juga. Contoh mekanisme seperti panggilan prosedur jauh, port TCP / IP, dan protokol seperti HTTP. Beberapa simbol yang umum digunakan untuk mewakili jenis konektor yang biasa ditemukan ditunjukkan pada Gambar 5.2.

- Sebuah konektor juga memiliki nama yang harus menggambarkan sifat interaksi konektor mendukung. Perlu menunjukkan bahwa pelaksanaan konektor mungkin cukup kompleks. Jika konektor disediakan oleh sistem yang mendasari, maka komponen hanya perlu memastikan bahwa mereka menggunakan konektor sesuai spesifikasi mereka. Namun, jika sistem yang mendasarinya tidak menyediakan konektor yang digunakan dalam arsitektur, maka seperti disebutkan di atas, konektor harus dilaksanakan sebagai bagian dari proyek untuk membangun sistem. Artinya, selama pengembangan, tidak hanya akan komponen perlu dikembangkan, tetapi sumber daya harus ditugaskan untuk juga mengembangkan konektor. (Situasi ini mungkin timbul karena sistem khusus yang membutuhkan konektor yang khusus untuk masalah domain.) Secara umum, sekaligus menciptakan arsitektur, adalah bijaksana untuk arsitek untuk menggunakan konektor yang tersedia pada sistem di mana perangkat lunak akan dikerahkan.

5.4 Gaya Arsitektur untuk C & C View

a. Pipa dan Filter
Pipa-dan-filter bergaya arsitektur cocok untuk sistem yang terutama melakukan transformasi data dan tujuan dari sistem ini adalah untuk menghasilkan beberapa data output dengan sesuai mengubah input data. Sebuah filter mungkin memiliki lebih dari satu input dan lebih dari satu output. Filter tidak perlu tahu identitas dari filter yang mengirim input data atau identitas filter yang akan mengkonsumsi data yang mereka hasilkan.

b. Data Bersama Style
- Ada dua variasi dari gaya ini. Dalam gaya papan, jika beberapa data yang diposting di repositori data, semua komponen accessor yang perlu tahu tentang hal itu diinformasikan. Dalam database, bentuk gaya sering didukung melalui pemicu. Yang lain adalah gaya repositori, dimana penyimpanan data hanya repositori pasif yang menyediakan penyimpanan permanen dan kontrol terkait untuk mengakses data.

- Banyak aplikasi database menggunakan gaya arsitektur ini. Banyak sistem Web sering mengikuti gaya ini di back end-dalam menanggapi permintaan pengguna, script erent di ff (accesor data) akses dan memperbarui beberapa data bersama.

- Komponen perhitungan yang berbeda tidak perlu berkomunikasi dengan satu sama lain dan bahkan tidak perlu tahu tentang keberadaan masing-masing.

- Misalnya, jika kemudian diputuskan bahwa penjadwalan kursus bisa otomatis berdasarkan data pada pendaftaran (dan informasi lain tentang ruang kelas dll), maka komponen lain yang disebut Penjadwalan hanya dapat menambahkan.

- Ada satu jenis konektor dalam gaya ini, baca / tulis. Perhatikan bagaimana gaya konektor umum  dapat mengambil bentuk yang lebih tepat dalam arsitektur tertentu. Misalnya,database dapat dilihat sebagai pendukung membaca dan update untuk program berinteraksi. Namun, sistem database dapat pula memberikan transaksi layanan.

c. Gaya Server Klien
- Gaya lain yang sangat umum digunakan untuk membangun sistem saat ini adalah gaya client-server. Server komputasi client adalah salah satu paradigma dasar komputasi terdistribusi.

- Dalam gaya ini, ada dua komponen, yaitu klien dan server. Kendala dari gaya ini adalah bahwa klien hanya dapat berkomunikasi dengan server, dan tidak dapat berkomunikasi dengan klien lainnya. Komunikasi antara komponen klien dan komponen server diprakarsai oleh klien ketika klien mengirimkan permintaan untuk beberapa layanan yang dimana server mendukung. server menerima permintaan,mendefinisikan, melakukan layanan, dan kemudian mengembalikan hasil perhitungan kepada klien yang meminta layanan.

- Ada satu jenis konektor dalam gaya ini. Sebuah konektor menghubungkan klien ke server. Jenis konektor asimetris akhir klien (end clien) konektor hanya dapat membuat permintaan (dan menerima balasan), sedangkan akhir server (end server) hanya dapat mengirim balasan dalam menanggapi permintaan itumelalui konektor ini. komunikasi sering sinkron, klien menunggu servermembawa hasil sebelum melanjutkan. Artinya, klien diblokir atas permintaan, sampai mendapatkan jawabannya.

- Sebuah bentuk umum dari gaya ini adalah struktur N-Tier. Dalam gaya ini, klien mengirimkan permintaan ke server, tetapi server hanya untuk melayani permintaan dan mengirim beberapa permintaan ke server lain. Server juga bertindak sebagai klien untuk tingkat berikutnya. Sebuah contoh umum ini adalah arsitektur 3-Tier. Dalam gaya ini, klien yang membuat permintaan dan menerima hasil akhir berada di tingkat client. Tingkat menengah yaitu tier bisnis, mengandung komponen yang memproses data yang diajukan oleh klien dan menerapkan aturan bisnis yang diperlukan. Tingkat ketiga adalah tingkat basis data di mana data berada.

- Dalam arsitektur client-server, klien dan komponen server berada pada mesin yang berbeda.Oleh karena itu, konektor antara klien dan server diharapkan untuk mendukung jenis permintaan / hasil dari hubungan di mesin yang berbeda. Akibatnya, konektor ini secara internal cukup kompleks dan melibatkan cukup banyak jaringan untuk mendukung. Banyak sistem client server saat port digunakan TCP untuk konektornya. Web menggunakan HTTP untuk mendukung konektor ini.

- Ada perbedaan antara arsitektur berlapis dan arsitektur berjenjang. Gaya berjenjang adalah komponen dan konektor tampilan arsitektur di mana setiap tier adalah komponen, dan komponen-komponen ini berkomunikasi dengan orang-orang yang berdekatan melalui protokol. Sebuah arsitektur berlapis adalah pandangan modul menyediakan bagaimana modul diatur dan digunakan.

d. Beberapa Gaya Lain
- Publish Subscribe Style,dalam gaya ini ada dua jenis komponen. Satu jenis komponen seperangkat yang didefinisikan. Dan yang kedua compo-motivasional, menghasilkan atau mempublikasikan acara.Peer-to-peer gaya, atau gaya berorientasi objek. Dalam gaya ini, komponen peer dan komponen komponen lain dapat meminta layanan dari komponen lainnya. Model ini adalah salah satu yang didukung melalui konektor middleware seperti CORBA atau NET.

5.5 Mendokumentasikan Desain Arsitektur

- Sejauh ini kita telah berfokus pada pandangan melalui diagram. Ketika merancang berakhir, arsitektur harus mengkomunikasikan kepada seluruh stakeholder untuk negosiasidan kesepakatan. Arsitektur harus dengan tepat mendokumentasikaninformasi yang cukup untuk melakukananalisis. Mendokumentasikan arsitektur itu sangat penting. Pada bagian ini, kita akan membahas dokumen arsitektur.

- Tanpa penjelasan didokumentasikan dengan baik arsitektur, itu tidak mungkin untuk memiliki pemahaman yang sama jelas. Oleh karena itu, benar mendokumentasikan arsitektur adalah sama pentingnya dengan membuat satu diagram. Pada bagian ini, kita membahas apa dokumen arsitektur harus berisi:
Sistem dan konteks arsitektur
Melihat deskripsi arsitektur
Across views documentation

- Sebuah diagram konteks yang menetapkan ruang lingkup sistem, batas-batasnya, aktor kunci yang berinteraksi dengan sistem, dan sumber dan tenggelam data juga bisa sangat berguna. Sebuah diagram konteks sering diwakili dengan menunjukkan sistem di tengah, dan menunjukkan hubungan dengan orang dan sistem, termasuk sumber dan mengambil data. Dengan konteks didefinisikan, dokumen dapat melanjutkan dengan menggambarkan struktur atau pandangan yg berbeda. Beberapa tampilan dari jenis yg berbeda mungkin diperlukan, dan yang dilihat dipilih tergantung pada kebutuhan proyek dan saham.

- Dokumen pendukung yang diperlukan untuk tampilan diagram. dokumen pendukung ini harus memiliki beberapa atau semua hal berikut:

a.) Elemen Katalog. Memberikan informasi lebih lanjut tentang unsur-unsur yang ditampilkan dalam representasi utama. Selain menjelaskan tujuan dari elemen, juga harus menjelaskan antarmuka elemen '(ingat bahwa semua elemen memiliki antarmuka di mana mereka berinteraksi dengan unsur-unsur lain). Semua antarmuka yang disediakan oleh elemen harus dispesifikasikan. Interface harus memiliki identitas yang unik, dan spesifikasi harus memberikan kedua informasi sintaksis dan semantik. informasi sintaksis sering dalam hal tanda tangan, yang menggambarkan semua item data yang terlibat dalam antarmuka dan jenis mereka. informasi semantik harus menjelaskan apa antarmuka tidak. deskripsi juga harus jelas menyatakan kondisi kesalahan bahwa antarmuka dapat kembali.

b.) Arsitektur Dasar pemikiran. Meskipun pandangan spesifik elemen es dan hubungan di antara mereka, tidak memberikan wawasan ke dalam mengapa arsitek memilih struktur tertentu. Arsitektur alasan memberikan alasan untuk memilih elemen erent di ff dan menyusun mereka dengan cara itu dilakukan. Bagian ini juga dapat memberikan beberapa diskusi tentang alternatif yang dipertimbangkan dan mengapa mereka ditolak. Diskusi ini, selain menjelaskan pilihan, juga berguna kemudian ketika seorang analis membuat perubahan bertanya-tanya mengapa arsitektur tidak harus diubah dalam beberapa cara (yang mungkin bisa membuat perubahan mudah).

c.) Tingkah Laku. Pandangan memberikan informasi struktural. Tidak mewakili perilaku aktual atau eksekusi. Akibatnya, dalam struktur, semua interaksi yang mungkin selama eksekusi akan ditampilkan. Kadang-kadang, perlu untuk mendapatkan beberapa gagasan tentang perilaku aktual dari sistem dalam beberapa skenario. seperti deskripsi berguna untuk berdebat tentang sifat seperti kebuntuan. deskripsi perilaku dapat diberikan untuk membantu pemahaman bantuan eksekusi sistem. Sering diagram seperti diagram kolaborasi atau urutan diagram (kita akan membahas ini lebih lanjut dalam Bab 6 tentang desain OO) digunakan.

d.) Informasi Lainnya. Ini mungkin termasuk keterangan tentang semua keputusan-keputusan yang belum diambil selama pembuatan arsitektur tetapi telah sengaja untuk masa depan, seperti, pilihan server atau protokol. Jika ini dilakukan, maka harus dispesifikasikan sebagai fi xing ini akan memiliki dampak pada arsitektur.

- Menggabungkan pandangan, bagaimanapun, harus dilakukan hanya jika hubungan antara pandangan kuat dan mudah. Jika tidak, menempatkan beberapa pandangan dalam satu diagram akan mengacaukan pandangan dan membuatnya membingungkan. Tujuan mengungkapkan beberapa pandangan dalam satu bukan hanya untuk mengurangi jumlah tampilan, tetapi harus dilakukan terutama untuk membantu pemahaman dan menunjukkan hubungan.

Ringkasan

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

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

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

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

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

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

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

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

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

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

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

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

Tugas Rekayasa Perangkat Lunak 2

RINGKASAN MASALAH PERANGKAT LUNAK

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

- Industri perangkat lunak sebagian besar tertarik untuk mengembangkan perangkat lunak kekuatan industri, dan bidang rekayasa perangkat lunak berfokus pada bagaimana membangun sistem tersebut. Artinya, masalah domain untuk rekayasa perangkat lunak adalah perangkat lunak kekuatan industri.

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

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

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

- Dalam domain software kekuatan industri, ada tiga kekuatan dasar dengan biaya bermain, jadwal, dan kualitas. Perangkat lunak ini harus diproduksi dengan biaya murah, dalam waktu yang wajar, dan harus berkualitas baik. Ketiga parameter sering berkendara dan menentukan proyek software.

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

-  Mengurangi biaya dan waktu siklus untuk pengembangan perangkat lunak adalah tujuan utama dari rekayasa perangkat lunak.

- Produktivitas dalam hal output (KLOC) per orang memadai dapat menangkap kedua kekhawatiran biaya dan jadwal. Jika produktivitas lebih tinggi, itu harus jelas bahwa biaya dalam hal perorang akan lebih rendah (pekerjaan yang sama kini dapat dilakukan dengan orang yang lebih sedikit). Demikian pula, jika produktivitas lebih tinggi, potensi pengembangan perangkat lunak dalam waktu kurang meningkatkan tim produktivitas yang lebih tinggi akan menyelesaikan pekerjaan dalam waktu kurang dari tim yang sama, ukuran dengan produktivitas rendah. (Waktu yang sebenarnya proyek ini akan mengambil, tentu saja, tergantung juga pada jumlah orang yang dialokasikan untuk mengerjakan proyek.) Oleh karena itu, mengejar produktivitas yang lebih tinggi adalah kekuatan pendorong dasar di balik rekayasa perangkat lunak dan alasan utama untuk menggunakan alat dan teknik yang berbeda .

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

- Standar internasional tentang kualitas produk software menunjukkan bahwa kualitas perangkat lunak terdiri dari 6 atribut utama,. Atribut ini dapat didefinisikan sebagai berikut:
1.)  Fungsi. kemampuan untuk menyediakan fungsi yang memenuhi dinyatakan dan tersirat kebutuhan ketika perangkat lunak yang digunakan.
2.)  Kehandalan. Kemampuan untuk menyediakan layanan gratis kegagalan.
3.)  Pengujian. kemampuan untuk dipahami, dipelajari, dan digunakan.
4.)  Efisiensi. kemampuan untuk memberikan kinerja yang relatif sesuai dengan jumlah sumber daya yang digunakan.
5.)  Perawatan. kemampuan yang akan dimodifikasi untuk keperluan membuat koreksi, perbaikan, atau adaptasi.
6.)  Portabilitas. kemampuan yang akan disesuaikan untuk lingkungan tertentu yang berbeda tanpa tindakan menerapkan atau berarti selain yang disediakan untuk tujuan ini dalam produk.

- Meskipun biaya, jadwal, dan kualitas adalah kekuatan pendorong utama untuk sebuah proyek di domain masalah kita (perangkat lunak kekuatan industri), ada beberapa karakteristik lain dari domain masalah yang juga mempengaruhi solusi pendekatan yang digunakan. Kami fokus pada dua karakteristik tersebut yaitu skala dan perubahan

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

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

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

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

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

- Kualitas Software memiliki banyak atribut yang meliputi fungsi, keandalan, kegunaan, efisiensi, pemeliharaan, dan portabilitas. Keandalan sering dianggap sebagai atribut kualitas utama, dan seperti tidak dapat diandalkan dalam perangkat lunak adalah disebabkan oleh cacat pada perangkat lunak, kualitas dapat ditandai dengan jumlah cacat per seribu baris kode.

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

Tugas Rekayasa Perangkat Lunak 1

1. WATERFALL MODEL


     Model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat  lunak. model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun. Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan. Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.


Diagram Waterfall Model :

Proses / Cara Kerja Waterfall Model
Cara kerja waterfall model dilakukan dengan berbagai macam tahapan yaitu :

1). System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari  kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.

2). Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.

3). Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

4). Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.

5). Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.

6). Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut.


 Waterfall Advantages :

       1). Merupakan model pengembangan paling handal dan paling lama digunakan.
       2). Cocok untuk system software berskala besar.
       3). Cocok untuk system software yang bersifat generic.
       4). Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.


 Waterfall Disvantages :

1). Waktu pengembangan lama. hal ini dikarenakan input tahap berikutnya adalah output dari         tahap sebelumnya. Jika satu tahap waktunya molor, maka waktu keseluruhan pengembangan juga ikut molor.
2). Biaya juga mahal, hal ini juga dikarenakan waktu pengembangan yang lama.                         
3). Terkadang perangkat lunak yang dihasilkan tidak akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer. hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan waterfall merupakan aliran yang linear, sehingga jika requirement berubah proses tidak dapat diulang lagi.
4). Karena tahap-tahapan pada waterfall tidak dapat berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek yang memiliki kompleksitas tinggi.
5). Meskipun waterfall memiliki banyak kelemahan yang dinilai cukup fatal, namun model ini  merupakan dasar bagi model-model lain yang dikembangkan setelahnya.



   2. PROTOTYPING

              Adalah bagian dari produk yang mengekspresikan logika maupun fisik antarmuka eksternal yang ditampilkan. Konsumen potensial menggunakan prototipe dan menyediakan masukan untuk tim pengembang sebelum pengembangan skal besar dimulai. Melihat dan mempercayai menjadi hal yang diharapkan untuk dicapai dalam prototipe. Dengan menggunakan pendekatan ini, konsumen dan tim pengembang dapat mengklarifikasi kebutuhan dan interpretasi merek.
               Prototyping perangkat lunak (software prototyping) atau siklus hidup menggunakan protoyping (life cycle using prototyping) adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat dari pada metode tradisional dan biayanya menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.
              Dengan prototype yang terbuka, model sebuah sistem (atau bagiannya) dikembangkan secara cepat dan dipoles dalam diskusi yang berkali-kali dengan klien. Model tersebut menunjukkan kepada klien apa yang akan dilakukan oleh sistem, namun tidak didukung oleh rancangan desain struktur yang mendetil. Pada saat perancang dan klien melakukan percobaan dengan berbagai ide pada suatu model dan setuju dengan desain final, rancangan yang sesungguhnya dibuat tepat seperti model dengan kualitas yang lebih bagus.
              Protoyping membantu dalam menemukan kebutuhan di tahap awal pengembangan,terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.

 Diagram Prototyping : 
                                              

 Proses/Cara Kerja Prototyping :

1). Pengumpulan kebutuhan, developer akan bertemu terlebih dahulu dan kemudian menentukan  tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya.
2). Perancangan, dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuata prototype.
3). Evaluasi prototyping, klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
  
 Prototyping Advantages :

1). Adanya komunikasi yang baik antara pengembang dan pelanggan.
2). Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
3). Pelanggan berperan aktif dalam pengembangan system.
4). Lebih menghemat waktu dalam pengembangan system.
5). Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.
6). Membuat klien mendapat gambaran awal dari prototype.
7) . Membantu mendapatkan kebutuhan detil lebih baik.


 Prototyping Disadvantages :

1). Pelanggan tidak paham bahwa perangkat lunak yang ada belum mencantumkan kualitas dan pemeliharaan untuk jangka waktu yang lama.
2). Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa yang sederhana agar lebih cepat, tanpa memikirkan program tersebut merupakan blue print system.
3). Hubungan pelanggan dengan komputer yang disediakan tidak mencerminkan teknik perancangan yang baik.



   3. ITERATIVE DEVELOPMENT

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


 Diagram Iterative Development

                             

 Proses / Cara kerja Iteravtive Development.

1). Mendefinisikan tujuan dan kebutuhan bisnis, mengembangkan desain konseptual, rancangan konsep, rencana pengujian, dan analis terhadap resiko dengan melibatkan pemakai.
2). Mendefinisikan kebutuhan sistem, mengembangkan desail logikal, mengkompilasi (software-build) rancangan awal, mengevaluasi hasil dengan melibatkan pemakai.
3). Mendefinisikan kebutuhan subsistem, menghasilkan desain fisikal, mengkompilasi rancangan berikutnya, mengevaluasi hasil dengan melibatkan pemakai.
4). Mendefinisikan kebutuhan setiap unit, menghasilkan desain akhir, mengkompilasi rancangan akhir.


 Iterative Development Advantages.
 
1). User dapat mencoba sistem yang sudah dikembangkan dan kemudian dapat memberikan masukkan keterlibatan user semakin intens dampak positif dalam pengembangan.
2). Prototype relatif lebih mudah dibangun dan tidak memerlukan waktu yang lama.
3). Dengan prototype, kesalahan & kelalaian dalam pengembangan dapat segera diketahui.


 Iterative Development Disadvantages.

1).  Setiap iterasi bergantung prototype sebelumnya solusi final umumnya terjadi apabila ada perbedaan yang nyata pada prototype sebelumnya.
2).  Formal end-of-phase mungkin tidak terjadi, karena sangat sulit menentukan scope dari suatu prototype, proyek tidak pernah selesai.
 3).  Dokumentasi seringkali tidak lengkap,fokus pada pembuatan prototype.
4).  Isu2 mengenai system backup & recovery, system performance dan system security, kurang/tidak diperhatikan dan sering terlupakan.



   4. RATIONAL UNIFIED PROCESS

       Suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. Rational Unified Processn bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.
      Pada Rational Unified Process didefinisikan terdapat 4 fasa siklus proyek. Fasa-fasa ini memungkinkan untuk disajikan dalam bentuk umum mirip dengan pendekatan air terjun, walaupun esensi kunci dari proses terdapat dalam iterasi dalam setiap fasenya. Setiap fase memiliki sebuah objektif kunci dan titik pencapaian akhir yang menandakan ketercapaian objektif. Visualisasi dari fase Rational Unified Process berikut dengan sumbu waktu dinamakan sebagai grafik Rational Unified Process.


 Diagram Rational Unified Process

   

 Proses / Cara kerja Rational Unified Process

Ada dua jenis aliran kerja (workflow) pada RUP, yaitu aliran kerja utama dan aliran kerja    pendukung.

  Aliran Kerja Utama
  
      1. Pemodelan bisnis (business modeling)
          Mendeskripsikan struktur dan proses-proses bisnis organisasi.

      2. Kebutuhan (requirements)
          Mendefinisikan kebutuhan perangkat lunak dengan menggunakan metode use case.

      3. Analisis dan perancangan (analysis and design)
          Mendeskripsikan berbagai arsitektur perangkat lunak dari berbagai sudut pandang.

     4. Implementasi (implementation)
         Menulis kode-kode program, menguji, dan mengintegrasikan unit-unit programnya.

     5. Pengujian (testing)
         Mendeskripsikan kasus uji, prosedur, dan alat ukur pengujian.

     6. Deployment
         Menangani konfigurasi sistem yang akan diserahkan.


  Aliran Kerja Pendukung

     1. Manajemen konfigurasi dan perubahan(configuration and change management)
         Mengendalikan perubahan dan memelihara artifak-artifak proyek.

     2. Manajemen proyek (project management)
         Mendeskripsikan berbagai strategi pekerjaan dengan proses yang berulang.

     3. Lingkungan (environment)
         Menangani infrastruktur yang dibutuhkan untuk mengembangkan sistem.


 Rational Unified Process Advantages

1). Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
2). Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
3). Mendukung proses pengulangan dalam pengembangan software.
4). Memungkinkan adanya penambahan-penambahan pada proses.
5). Memungkinkan untuk secara sistematis mengontrol perubahan - perubahan yang terjadi    pada software selama proses pengembangannya.


 Rational Unified Process Disadvantages

1). Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yang berorientasi     objek dengan berfokus pada UML (Unified Modeling Language).
2). Membutuhkan waktu yang cukup lama dibandingkan XP dan Scrum.

   

   5. TIMEBOXING MODEL

           Proses menunda fitur untuk versi aplikasi di masa mendatang untuk melengkapi versi saat ini sebagai ketepatan waktu.Ketepatan waktu merupakan aspek penting dari RAD, karena tanpa itu ruang lingkup dapat mengancam untuk memperpanjang iterasi pembangunan, sehingga membatasi umpan balik dari klien, meminimalkan manfaat dari pembangunan berulang, dan berpotensi mengembalikan proses kembali ke pendekatan metodologi air terjun. Timeboxing model dengan jenis kotak waktu, dapat menggunakan pipelining untuk mengurangi waktu siklus seperti pipelining hardware-view iterasi setiap instruksi sebagai tahap telah mendedikasikan tim, eksekusi simultan dari iterasi yang berbeda.


 Diagram Timeboxing Model

 Proses / Cara Kerja Timeboxing Model

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


 Advantages Timeboxing Model

1). Kecepatan model ini sampai proses pengerjaan dan dapat mempersingkat waktu pengiriman.
2). Model ini cocok untuk mengembangkan projek dengan beberapa fitur dalam waktu singkat.


 Disvantages Timeboxing Model

1). Managemen projek akan menjadi lebih kompleks
2). Tidak cocok untuk projek dimana seluruh pengerjaan tidak dapat dibagi menjadi beberapa iterations.


    
   6. EXTREME PROGAMMING & AGILE PROCESS

   EXTREME PROGAMMING

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


 Diagram Extreme Programming

 Proses / Cara kerja Extreme Programming

Berikut merupakan proses Extreme Programming menurut Pressman (2010):

Planning.
     Tahap planning dimulai dengan membuat user stories yangmenggambarkan output, fitur, dan fungsi-fungsi dari software yang akan dibuat. User stories tersebut kemudian diberikan bobot seperti prioritas dan dikelompokkan untuk selanjutnya dilakukan prosesdelivery secara incremental.

Design.
     Design di Extreme Programming mengikuti prinsip Keep It Simple (KIS). Untuk design yang sulit, Extreme Programming akan menggunaan Spike Solution dimana pembuatan design dibuat langsung ke tujuannya. Extreme Programming juga mendukung adanya refactoring dimana software system diubah sedemikian rupa dengan cara mengubah stuktur kode dan menyederhanakannya namun hasil dari kode tidak berubah.

Coding.
      Proses coding pada XP diawali dengan membangun serangkaian unittest. Setelah itu pengembang akan berfokus untukmengimplementasikannya. Dalam Extreme Programming diperkenalkan istilah Pair Programming dimana proses penulisan program dilakukan secara berpasangan. Dua orang programmersaling bekerjasama di satu komputer untuk menulis program. Denganmelakukan ini akan didapat real-time problem solving dan real-time quality assurance.

Testing.
      Tahap ini dilakukan pengujian kode pada unit test. Dalam Extreme Programming, diperkenalkan XP acceptance test atau biasa disebutcustomer test. Tes ini dilakukan oleh customer yang berfokus kepada fitur dan fungsi sistem secara keseluruhan. Acceptance test ini berasal dari user stories yang telah diimplementasikan.


 Advantages Extreme Programming

1). Menjalin komunikasi yang baik dengan klien. (planning phase)
2). Menurunkan biaya pengembangan. (implementation phase)
3). XP merupakan metodologi yang semi formal. (planning phase)
4). Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima atau dengan  kata lain fleksibel. (maintenace phase)


 Disadvantages Extreme Programming

1). Tidak bisa membuat kode yang detail diawal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga) XP juga memiliki keunggulan yang sekaligus menjadi kelemahannya yaitu XP tidak memiliki dekumentasi formal yang dibuat selama pengembangan. Satu satunya dokumentasi adalah dekumentasi awal yang dilakukan oleh user.

     
  
   AGILE PROCESS

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

Agile Process terbagi menjadi beberapa bentuk, diantaranya adalah:

1). Adaptive Software Development (ASD)
2). Dynamic Systems Development Method (DSDM)3). Scrum
4). Crystal
5). Feature Driven Development (FDD)
6). Agile Modeling (AM)
7). Lean Software Development (LSD)
8). Agile Unified Process (AUP)

  
 Diagram Agile Process

  
 Proses / Cara kerja Agile Process

1). Perencanaan XP: pengumpulan user stories dari klien yang klien tetapkan prioritasnya. Setiap story ditetapkan harga dan lama pembangunan, jika terlalu besar, story dapat dipecah menjadi beberapa story yang lebih kecil. Periksa dan pertimbangkan resiko

2). Desain XP berprinsip: sederhana memanfaatkan kartu CRC (Class-Responsibility-Collaborator) untuk identifikasi dan mengatur class-class di konsep OO. Jika temui kesulitan, prototype dibangun (ini namanya spike solution). Lakukan refactoring, yaitu mengembangkan desain dari program setelah ditulis.

3). Pengkodean XP: siapkan unit test sebelum pengkodean dipakai sebagai fokus pemrogram untuk membuat program. Pair programming dilakukan untuk real time program solving dan real time quality assurance


Pengujian XP: menggunakan unit test yang dipersiapkan sebelum pengkodean.


 Advantages Agile Process

1). Meningkatkan kepuasan kepada klien.
2). Dapat melakukan review pelanggan mengenai software yang dibuat lebih awal.3). Pembangunan system dibuat lebih cepat.
4). Mengurangi resiko kegagalan implementasi software dari segi non-teknis.
5). Jika pada saat pembangunan system terjadi kegagalan kerugian dari segi materi relatif kecil.


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