RESUME REKAYASA PERANGKAT LUNAK

“Software Engineering”

Seventh Edition

Roger S. Pressman

disusun oleh : Pipitia Dewi 

Chapter 1 : SOFTWARE AND SOFTWARE ENGINEERING

 
Perangkat lunak adalah elemen kunci dalam evolusi sistem berbasis komputer dan produk dan salah satu teknologi paling penting di panggung dunia. Di atas Selama 50 tahun terakhir, perangkat lunak telah berevolusi dari alat analisis pemecahan masalah dan informasi khusus menjadi industri sendiri. Namun kami masih kesulitan mengembangkan perangkat lunak berkualitas tinggi tepat waktu dan sesuai anggaran. Perangkat lunak — program, data, dan informasi deskriptif — membahas beragam bidang teknologi dan aplikasi. Software Legacy terus menghadirkan istimewa tantangan bagi mereka yang harus mempertahankannya. Sistem dan aplikasi berbasis web telah berkembang dari koleksi sederhana konten formasi menjadi sistem canggih yang menghadirkan fungsionalitas dan kompleks konten multimedia. Meskipun WebApps ini memiliki fitur unik dan memerlukan pengaturan, namun mereka adalah perangkat lunak. Rekayasa perangkat lunak mencakup proses, metode, dan alat yang memungkinkan sistem berbasis komputer yang kompleks harus dibangun tepat waktu dengan kualitas. Itu proses perangkat lunak menggabungkan lima kegiatan kerangka kerja — komunikasi, perencanaan, pemodelan, konstruksi, dan penyebaran — yang berlaku untuk semua proyek perangkat lunak. Praktek rekayasa perangkat lunak adalah kegiatan pemecahan masalah yang mengikuti serangkaian prinsip inti. Berbagai macam mitos perangkat lunak terus mengarah pada manajer dan praktisi sesat, bahkan seperti pengetahuan kolektif kita tentang perangkat lunak dan teknologi yang dibutuhkan untuk membangunnya tumbuh. Saat Anda mempelajari lebih lanjut tentang rekayasa perangkat lunak, Anda akan mulai memahami mengapa mitos ini harus dibantah setiap kali ditemui.

Chapter 2 : PROSESS MODEL

Model proses generik untuk rekayasa perangkat lunak mencakup serangkaian kerangka kerja

dan kegiatan payung, tindakan, dan tugas kerja. Masing-masing dari berbagai model proses

dapat dijelaskan oleh aliran proses yang berbeda — deskripsi tentang bagaimana kerangka kerja

kegiatan, tindakan, dan tugas diatur secara berurutan dan kronologis. Proses

pola dapat digunakan untuk memecahkan masalah umum yang ditemui sebagai bagian dari proses perangkat lunak.

Model proses preskriptif telah diterapkan selama bertahun-tahun dalam upaya menghadirkan ketertiban dan struktur untuk pengembangan perangkat lunak. Masing-masing model ini menunjukkan aliran proses yang berbeda, tetapi semua melakukan kerangka kerja generik yang sama kegiatan: komunikasi, perencanaan, pemodelan, konstruksi, dan penyebaran.

Model proses berurutan, seperti model air terjun dan V, adalah yang tertua

paradigma rekayasa perangkat lunak. Mereka menyarankan aliran proses linier yang sering tidak konsisten dengan realitas modern (mis., Perubahan terus-menerus, sistem yang berkembang, ketat

garis waktu) di dunia perangkat lunak. Namun, mereka memiliki penerapan dalam situasi di mana persyaratan didefinisikan dengan baik dan stabil.

Model proses tambahan bersifat iteratif dan menghasilkan versi yang berfungsi

perangkat lunak cukup cepat. Model proses evolusi mengenali iteratif, dalam sifat cremental dari sebagian besar proyek rekayasa perangkat lunak dan dirancang untuk mengakomodasi perubahan yang terjadi. Model evolusi, seperti prototyping dan model spiral, menghasilkan produk kerja tambahan (atau versi perangkat lunak yang berfungsi) dengan cepat.

Model-model ini dapat diadopsi untuk diterapkan di semua kegiatan rekayasa perangkat lunak dari pengembangan konsep hingga pemeliharaan sistem jangka panjang.

Model proses bersamaan memungkinkan tim perangkat lunak untuk mewakili berulang dan elemen bersamaan dari setiap model proses. Model khusus termasuk

model berbasis komponen yang menekankan penggunaan kembali dan perakitan komponen; model untuk metode mal yang mendorong pendekatan berbasis matematika untuk perangkat lunak pengembangan dan verifikasi; dan model berorientasi aspek yang mengakomodasi keprihatinan lintas sektoral yang mencakup seluruh arsitektur sistem. Proses Terpadu adalah "use case driven, arsitektur-centric, iterative dan incremental" perangkat lunak proses yang dirancang sebagai kerangka kerja untuk metode dan alat UML.

Model pribadi dan tim untuk proses perangkat lunak telah diusulkan. Kedua

menekankan pengukuran, perencanaan, dan pengarahan diri sendiri sebagai bahan utama untuk proses perangkat lunak yang sukses

Chapter 3 : AGILE DEVELOPMENT

Dalam ekonomi modern, kondisi pasar berubah dengan cepat, pelanggan dan pengguna akhir kebutuhan berevolusi, dan ancaman persaingan baru muncul tanpa peringatan. Praktisi harus mendekati rekayasa perangkat lunak dengan cara yang memungkinkan mereka tetap gesit untuk mendefinisikan manuver, adaptif, proses lean yang dapat mengakomodasi kebutuhan

bisnis modern.

Filosofi lincah untuk rekayasa perangkat lunak menekankan empat masalah utama: pentingnya tim yang mengatur diri sendiri yang memiliki kontrol atas pekerjaan yang mereka lakukan, komunikasi dan kolaborasi antara anggota tim dan antara praktisi

dan pelanggan mereka, pengakuan bahwa perubahan mewakili peluang, dan

"Tool set" itu mendukung lincah proses berfokus lebih lanjut tentang masalah orang daripada pada masalah teknologi.

penekanan pada pengiriman cepat perangkat lunak yang memuaskan pelanggan. Proses tangkas model telah dirancang untuk mengatasi masing-masing masalah ini.
Extreme programming (XP) adalah proses lincah yang paling banyak digunakan. Diorganisir sebagai empat kegiatan kerangka kerja — perencanaan, desain, pengkodean, dan pengujian — XP menyarankan a sejumlah teknik inovatif dan kuat yang memungkinkan tim tangkas untuk membuat seringnya rilis perangkat lunak yang menghadirkan fitur dan fungsi yang telah dijelaskan dan kemudian diprioritaskan oleh para pemangku kepentingan. Model proses gesit lainnya juga menekankan kolaborasi manusia dan organisasi mandiri tim, tetapi menentukan kegiatan kerangka kerja mereka sendiri dan memilih titik yang berbeda tekanan. Misalnya, ASD menggunakan proses berulang yang menggabungkan adaptif perencanaan siklus, metode pengumpulan persyaratan yang relatif ketat, dan berulang siklus pengembangan yang menggabungkan kelompok fokus pelanggan dan pandangan teknis formal sebagai mekanisme umpan balik waktu nyata. Scrum menekankan penggunaan serangkaian pola proses perangkat lunak yang telah terbukti efektif untuk proyek dengan garis waktu yang ketat, perubahan persyaratan, dan kekritisan bisnis. Setiap pola proses mendefinisikan satu set tugas pengembangan dan memungkinkan tim Scrum untuk membangun proses yang disesuaikan dengan kebutuhan proyek. Metode Pengembangan Sistem Dinamis (DSDM) menganjurkan penggunaan penjadwalan kotak waktu dan menyarankan itu hanya cukup pekerjaan diperlukan untuk setiap peningkatan perangkat lunak untuk memfasilitasi perpindahan ke tahap berikutnya kenaikan. Crystal adalah keluarga model proses gesit yang dapat diadopsi dengan karakteristik spesifik dari suatu proyek. Feature Driven Development (FDD) agak lebih "formal" daripada lincah lainnya metode, tetapi masih mempertahankan kelincahan dengan memfokuskan tim proyek pada pengembangan fitur — fungsi bernilai klien yang dapat diimplementasikan dalam dua minggu atau kurang. Lean Software Development (LSD) telah mengadaptasi prinsip-prinsip lean manufacturing ke dunia rekayasa perangkat lunak. Agile modelling (AM) menyatakan bahwa modelling adalah penting untuk semua sistem, tetapi kompleksitas, jenis, dan ukuran model harus disetel ke perangkat lunak yang akan dibangun. Agile Unified Process (AUP) mengadopsi “serial in filosofi besar "dan" berulang dalam kecil "untuk membangun perangkat lunak.

CHAPTER 4 : PRINCIPLES THAT GUIDE PRACTICE

Praktek rekayasa perangkat lunak mencakup prinsip, konsep, metode, dan alat yang diterapkan insinyur perangkat lunak selama proses perangkat lunak. Setiap perangkat lunak proyek teknik berbeda. Namun, seperangkat prinsip umum berlaku untuk proses tersebut secara keseluruhan dan untuk praktik setiap kegiatan kerangka kerja terlepas dari proyek atau produk. Seperangkat prinsip inti membantu dalam penerapan proses perangkat lunak yang bermakna dan pelaksanaan metode rekayasa perangkat lunak yang efektif. Di tingkat proses, prinsip inti membangun landasan filosofis yang memandu tim perangkat lunak sebagai itu menavigasi melalui proses perangkat lunak. Pada tingkat praktik, prinsip-prinsip inti membangun kumpulan nilai dan aturan yang berfungsi sebagai panduan saat Anda menganalisis masalah, merancang solusi, mengimplementasikan dan menguji solusi, dan akhirnya menyebarkan perangkat lunak di komunitas pengguna. Prinsip-prinsip komunikasi fokus pada kebutuhan untuk mengurangi kebisingan dan meningkatkan lebar pita saat percakapan antara pengembang dan pelanggan berlangsung. Kedua belah pihak harus berkolaborasi agar komunikasi terbaik terjadi. Prinsip-prinsip perencanaan memberikan pedoman untuk membangun peta terbaik untuk perjalanan ke sistem atau produk yang lengkap. Rencana tersebut dapat dirancang semata-mata untuk a peningkatan perangkat lunak tunggal, atau dapat didefinisikan untuk seluruh proyek. Bagaimanapun, itu harus membahas apa yang akan dilakukan, siapa yang akan melakukannya, dan kapan pekerjaan itu akan dilakukan lengkap.

Pemodelan meliputi analisis dan desain, menggambarkan representasi dari perangkat lunak yang semakin menjadi lebih rinci. Maksud dari model adalah untuk memperkuat pemahaman tentang pekerjaan yang harus dilakukan dan untuk memberikan bimbingan teknis mereka yang akan mengimplementasikan perangkat lunak. Prinsip pemodelan berfungsi sebagai dasar untuk metode dan notasi yang digunakan untuk membuat representasi perangkat lunak. Konstruksi menggabungkan siklus pengkodean dan pengujian di mana kode sumber untuk a komponen dihasilkan dan diuji. Prinsip pengkodean mendefinisikan tindakan umum itu harus terjadi sebelum kode ditulis, ketika sedang dibuat, dan setelah itu telah dibuat lengkap. Meskipun ada banyak prinsip pengujian, hanya satu yang dominan: pengujian adalah proses menjalankan program dengan tujuan menemukan kesalahan.

Penempatan terjadi karena setiap peningkatan perangkat lunak disajikan kepada pelanggan dan meliputi pengiriman, dukungan, dan umpan balik. Prinsip-prinsip kunci untuk pengiriman dipertimbangkan mengelola harapan pelanggan dan menyediakan pelanggan dengan informasi dukungan pelabuhan yang sesuai untuk perangkat lunak. Dukungan menuntut persiapan lebih lanjut. Umpan balik

memungkinkan pelanggan untuk menyarankan perubahan yang memiliki nilai bisnis dan memberikan pengembang dengan input untuk siklus rekayasa perangkat lunak berulang berikutnya.

CHAPTER 5 : UNDERSTANDING REQUIREMENT

Tugas-tugas rekayasa kebutuhan dilakukan untuk membangun dasar yang kuat untuk desain dan konstruksi. Rekayasa kebutuhan terjadi selama komunikasi

dan kegiatan pemodelan yang telah ditentukan untuk proses perangkat lunak generik.

Tujuh persyaratan fungsi rekayasa yang berbeda — permulaan, elisitasi, elaborasi, negosiasi, spesifikasi, validasi, dan manajemen — dilakukan oleh

anggota tim perangkat lunak.

Pada awal proyek, pemangku kepentingan menetapkan persyaratan masalah dasar, mendefinisikan mengatasi kendala proyek, dan mengatasi fitur dan fungsi utama yang harus hadir untuk sistem untuk memenuhi tujuannya. Informasi ini disempurnakan dan dikembangkan selama elisitasi — kegiatan pengumpulan persyaratan yang memanfaatkan pertemuan fasilitasi, QFD, dan pengembangan skenario penggunaan.

Elaborasi selanjutnya memperluas persyaratan dalam model — kumpulan elemen berbasis skenario, berbasis kelas, perilaku, dan berorientasi aliran. Model tersebut dapat merujuk pada pola analisis, solusi untuk masalah analisis yang telah terlihat

terulang kembali di berbagai aplikasi.

Ketika persyaratan diidentifikasi dan model persyaratan dibuat, the

tim perangkat lunak dan pemangku kepentingan proyek lainnya menegosiasikan prioritas, ketersediaan, dan biaya relatif dari setiap persyaratan. Maksud dari negosiasi ini adalah untuk mengembangkan rencana proyek yang realistis. Selain itu, setiap persyaratan dan model persyaratan secara keseluruhan

divalidasi terhadap kebutuhan pelanggan untuk memastikan bahwa sistem yang tepat akan dibangun.

CHAPTER 6 : REQUIREMENT MODELING : SCANARIOS, INFORMATION, AND ANALISYS CLASSES

Tujuan pemodelan persyaratan adalah untuk menciptakan berbagai representasi itu

menggambarkan apa yang dibutuhkan pelanggan, membangun dasar untuk pembuatan perangkat lunak

mendesain, dan menetapkan seperangkat persyaratan yang dapat divalidasi begitu perangkat lunaknya

dibangun di. Model persyaratan menjembatani kesenjangan antara representasi tingkat sistem

yang menggambarkan keseluruhan fungsi sistem dan bisnis dan desain perangkat lunak itu

menjelaskan arsitektur aplikasi perangkat lunak, antarmuka pengguna, dan struktur tingkat komponen.

Model berbasis skenario menggambarkan persyaratan perangkat lunak dari sudut pandang pengguna

melihat. Kasus penggunaan — deskripsi interaksi yang digerakkan oleh narasi atau template

antara aktor dan perangkat lunak — adalah elemen pemodelan utama. Berasal

selama elisitasi persyaratan, use case mendefinisikan langkah-langkah kunci untuk spesifik

fungsi atau interaksi. Tingkat formalitas dan detail use case bervariasi, tetapi

hasil akhir memberikan input yang diperlukan untuk semua kegiatan pemodelan analisis lainnya. Sce narios juga dapat dideskripsikan menggunakan diagram aktivitas — bagan bagan alir seperti grafik

representasi yang menggambarkan aliran pemrosesan dalam skenario tertentu. Diagram Swimlane menggambarkan bagaimana aliran pemrosesan dialokasikan untuk berbagai aktor atau

kelas.

Pemodelan data digunakan untuk menggambarkan ruang informasi yang akan dibangun

atau dimanipulasi oleh perangkat lunak. Pemodelan data dimulai dengan merepresentasikan data

objek — informasi gabungan yang harus dipahami oleh perangkat lunak. Itu

atribut dari setiap objek data diidentifikasi dan hubungan antara objek data dijelaskan.

Pemodelan berbasis kelas menggunakan informasi yang berasal dari skenario dan data

elemen pemodelan untuk mengidentifikasi kelas analisis. Penguraian gramatikal dapat digunakan untuk

ekstrak kelas kandidat, atribut, dan operasi dari narasi berbasis teks.

Kriteria untuk definisi kelas didefinisikan. Satu set kartu indeks kolaborator tanggung jawab kelas dapat digunakan untuk mendefinisikan hubungan antar kelas. Di Selain itu, berbagai notasi pemodelan UML dapat diterapkan untuk menentukan hierarki, hubungan, asosiasi, agregasi, dan dependensi di antara kelas-kelas. Paket sis analisis digunakan untuk mengelompokkan dan mengelompokkan kelas dengan cara yang membuatnya

lebih mudah dikelola untuk sistem besar.

CHAPTER 7 : REQUIREMENT MODELING : FLOW, BEHAVIOR, PATTERNS AND WEBAPPS

Model berorientasi aliran fokus pada aliran objek data saat mereka ditransformasikan oleh fungsi pemrosesan. Berasal dari analisis terstruktur, penggunaan model berorientasi aliran diagram alir data, notasi pemodelan yang menggambarkan bagaimana input ditransformasikan menjadi output sebagai objek data bergerak melalui suatu sistem. Setiap fungsi perangkat lunak itu Transformasi data dijelaskan oleh spesifikasi proses atau narasi. Sebagai tambahannya aliran data, elemen pemodelan ini juga menggambarkan aliran kontrol — representasi yang menggambarkan bagaimana peristiwa mempengaruhi perilaku sistem. Pemodelan perilaku menggambarkan perilaku dinamis. Model perilaku menggunakan input dari elemen berbasis skenario, berorientasi aliran, dan berbasis kelas untuk mewakili status kelas analisis dan sistem secara keseluruhan. Untuk mencapai ini, negara adalah diidentifikasi, peristiwa yang menyebabkan kelas (atau sistem) melakukan transisi dari satu negara ke negara lain didefinisikan, dan tindakan yang terjadi saat transisi selesai juga diidentifikasi. State diagram dan diagram urutan adalah notasi yang digunakan untuk pemodelan perilaku.

Pola analisis memungkinkan insinyur perangkat lunak untuk menggunakan pengetahuan domain yang ada

memfasilitasi pembuatan model persyaratan. Pola analisis menjelaskan fitur atau fungsi perangkat lunak tertentu yang dapat dijelaskan oleh serangkaian kasus penggunaan yang koheren.

Ini menentukan maksud dari pola, motivasi untuk penggunaannya, batasan yang membatasi

penggunaannya, penerapannya dalam berbagai domain masalah, keseluruhan struktur pola, perilaku dan kolaborasi, dan informasi tambahan lainnya.

Pemodelan persyaratan untuk WebApps dapat menggunakan sebagian besar, jika tidak semua, elemen pemodelan yang dibahas dalam buku ini. Namun, elemen-elemen ini diterapkan dalam satu set model khusus yang membahas konten, interaksi, fungsi, navigasi, dan konfigurasi client-server di mana WebApp berada.

CHAPTER 8 : DESIGN AND CONCEPTS

Desain perangkat lunak dimulai sebagai iterasi pertama dari rekayasa kebutuhan sampai pada suatu kesimpulan. Maksud dari desain perangkat lunak adalah untuk menerapkan seperangkat prinsip, konsep, dan praktik yang mengarah pada pengembangan sistem atau berkualitas tinggi produk. Tujuan dari desain adalah untuk membuat model perangkat lunak yang akan mengimplementasikan semua persyaratan pelanggan dengan benar dan membawa kesenangan bagi mereka yang menggunakannya. Perangkat lunak penandatangan harus menyaring banyak alternatif desain dan menyatu pada solusi itu paling sesuai dengan kebutuhan pemangku kepentingan proyek. Proses desain bergerak dari pandangan "gambaran besar" perangkat lunak ke yang lebih sempit tampilan yang mendefinisikan detail yang diperlukan untuk mengimplementasikan suatu sistem. Prosesnya dimulai dengan berfokus pada arsitektur. Subsistem didefinisikan; mekanisme komunikasi di antara subsistem didirikan; komponen diidentifikasi, dan penjelasan rinci dari setiap komponen dikembangkan. Selain itu, eksternal, internal, dan pengguna antarmuka dirancang. Konsep desain telah berkembang selama 60 tahun pertama rekayasa perangkat lunak kerja. Mereka menggambarkan atribut dari perangkat lunak komputer yang harus hadir, kurang dari proses rekayasa perangkat lunak yang dipilih, metode desain yang ada diterapkan, atau bahasa pemrograman yang digunakan. Intinya, konsep desain menekankan perlunya abstraksi sebagai mekanisme untuk membuat perangkat lunak yang dapat digunakan kembali komponen; pentingnya arsitektur sebagai cara untuk lebih memahami struktur semua sistem; manfaat rekayasa berbasis pola sebagai teknik untuk merancang perangkat lunak dengan kemampuan yang terbukti; nilai pemisahan keprihatinan dan modularitas efektif sebagai cara untuk membuat perangkat lunak lebih dimengerti, lebih dapat diuji, dan lebih bisa dipelihara; konsekuensi dari penyembunyian informasi sebagai mekanisme untuk mengurangi penyebaran efek samping ketika kesalahan terjadi; Dampak dari kemandirian fungsional sebagai kriteria untuk membangun modul yang efektif; penggunaan penyempurnaan sebagai mekanisme desain; pertimbangan aspek yang memotong sistem Persyaratan; penerapan refactoring untuk mengoptimalkan desain yang diturunkan; dan pentingnya kelas berorientasi objek dan karakteristik yang terkait ke mereka.

Model desain mencakup empat elemen yang berbeda. Ketika masing-masing elemen ini dikembangkan, pandangan yang lebih lengkap dari desain berkembang. Arsitekturnya

elemen menggunakan informasi yang berasal dari domain aplikasi, persyaratan

model, dan katalog yang tersedia untuk pola dan gaya untuk mendapatkan struktur yang lengkap

representasi perangkat lunak, subsistem, dan komponennya. Desain antarmuka menambah model antarmuka eksternal dan internal dan antarmuka pengguna. Elemen tingkat komponen menentukan setiap modul (komponen) yang mengisi Arsitektur. Akhirnya, elemen desain tingkat penempatan mengalokasikan arsitektur, nya

komponen, dan antarmuka ke konfigurasi fisik yang akan menampung perangkat lunak.

CHAPTER 9 : ARCHITECTURAL DESIGN

Arsitektur perangkat lunak memberikan pandangan holistik terhadap sistem yang akan dibangun. Ini menggambarkan struktur dan organisasi komponen perangkat lunak, sifat-sifatnya, dan hubungan di antara mereka. Komponen perangkat lunak termasuk modul program dan berbagai representasi data yang dimanipulasi oleh program. Karena itu, data desain merupakan bagian integral dari derivasi arsitektur perangkat lunak. Arsitektur

menyoroti keputusan desain awal dan menyediakan mekanisme untuk mempertimbangkan manfaat struktur sistem alternatif.

Sejumlah gaya dan pola arsitektur yang berbeda tersedia untuk insinyur perangkat lunak dan dapat diterapkan dalam genre arsitektur tertentu. Setiap gaya menggambarkan kategori sistem yang mencakup serangkaian komponen yang melakukan a fungsi yang dibutuhkan oleh suatu sistem; satu set konektor yang memungkinkan komunikasi, koordinasi, dan kerja sama antar komponen; kendala yang menentukan bagaimana komponen dapat diintegrasikan untuk membentuk sistem; dan model semantik yang memungkinkan a

desainer untuk memahami keseluruhan sifat suatu sistem.

Secara umum, desain arsitektur dilakukan dengan menggunakan empat langkah berbeda.

Pertama, sistem harus diwakili dalam konteks. Artinya, perancang harus mendefinisikan entitas eksternal yang berinteraksi dengan perangkat lunak dan sifat interaksi. Setelah konteks telah ditentukan, perancang harus mengidentifikasi satu set tingkat atas abstraksi, yang disebut arketipe, yang mewakili elemen-elemen penting dari sistem menjadi havior atau fungsi. Setelah abstraksi telah ditentukan, desain mulai bergerak

lebih dekat ke domain implementasi. Komponen diidentifikasi dan diwakili dalam konteks arsitektur yang mendukungnya. Akhirnya, inovasi spesifik dari arsitektur dikembangkan untuk “membuktikan” desain dalam konteks dunia nyata.

Sebagai contoh sederhana dari desain arsitektur, metode pemetaan disajikan dalam

bab ini menggunakan karakteristik aliran data untuk memperoleh arsitektur yang umum digunakan

gaya. Diagram aliran data dipetakan ke dalam struktur program menggunakan pendekatan transformasi peta ping. Transformasi pemetaan diterapkan pada aliran informasi yang dipamerkan

batas yang berbeda antara data yang masuk dan keluar. DFD dipetakan menjadi a

struktur yang mengalokasikan kontrol untuk input, pemrosesan, dan output sepanjang tiga hierarki modul yang terpisah. Setelah sebuah arsitektur diturunkan, ia dieksplorasi dan dianalisis menggunakan kriteria kualitas.

CHAPTER 10 : COMPONENT LEVEL DESIGN

Proses desain tingkat komponen mencakup serangkaian kegiatan yang

perlahan-lahan mengurangi tingkat abstraksi dengan mana perangkat lunak diwakili.

Desain tingkat komponen pada akhirnya menggambarkan perangkat lunak pada tingkat abstraksi itu

dekat dengan kode.

Tiga pandangan berbeda dari desain tingkat komponen dapat diambil, tergantung pada

sifat perangkat lunak yang akan dikembangkan. Tampilan berorientasi objek berfokus pada

elaborasi kelas desain yang berasal dari masalah dan infrastruktur

domain. Tampilan tradisional memurnikan tiga jenis komponen atau modul:

modul kontrol, modul domain bermasalah, dan modul infrastruktur. Di keduanya

kasus, prinsip-prinsip desain dasar dan konsep yang mengarah ke perangkat lunak berkualitas tinggi diterapkan. Ketika dipertimbangkan dari sudut pandang proses, desain tingkat komponen mengacu pada

komponen perangkat lunak yang dapat digunakan kembali dan pola desain yang merupakan elemen penting

rekayasa perangkat lunak berbasis komponen.

Sejumlah prinsip dan konsep penting memandu perancang kelas

diuraikan. Gagasan yang dicakup dalam Prinsip Terbuka-Tertutup dan Ketergantungan

Prinsip dan konsep inversi seperti kopling dan kohesi memandu perangkat lunak

insinyur dalam membangun komponen perangkat lunak yang dapat diuji, diimplementasikan, dan dipelihara. Untuk melakukan desain tingkat komponen dalam konteks ini, kelas diuraikan oleh

menentukan detail pengiriman pesan, mengidentifikasi antarmuka yang sesuai, menguraikan atribut dan mendefinisikan struktur data untuk mengimplementasikannya, menjelaskan aliran pemrosesan dalam setiap operasi, dan mewakili perilaku di tingkat kelas atau komponen. Di setiap kasus, perulangan desain (refactoring) adalah kegiatan yang penting.

Desain tingkat komponen tradisional memerlukan representasi struktur data, antarmuka, dan algoritma untuk modul program secara terperinci untuk memandu dalam generasi kode sumber bahasa pemrograman. Untuk mencapai ini, perancang menggunakan salah satu dari sejumlah notasi desain yang mewakili tingkat komponen

detail dalam format berbasis grafik, tabel, atau berbasis teks.

Desain tingkat komponen untuk WebApps mempertimbangkan konten dan fungsionalitas

itu disampaikan oleh sistem berbasis web. Desain konten di tingkat komponen berfokus

pada objek konten dan cara mereka dikemas untuk presentasi

ke pengguna akhir WebApp. Desain fungsional untuk WebApps berfokus pada fungsi pemrosesan yang memanipulasi konten, melakukan perhitungan, permintaan dan mengakses database, dan membangun antarmuka dengan sistem lain. Semua prinsip desain tingkat komponen dan pedoman berlaku.

Pemrograman terstruktur adalah filosofi desain prosedural yang membatasi jumlah dan jenis konstruksi logis yang digunakan untuk merepresentasikan detail algoritmik. Tenda pemrograman terstruktur adalah untuk membantu desainer dalam mendefinisikan algoritma itu kurang kompleks dan karenanya lebih mudah dibaca, diuji, dan dipelihara.

Rekayasa perangkat lunak berbasis komponen mengidentifikasi, membuat, membuat katalog, dan mendesain satu set komponen perangkat lunak dalam domain aplikasi tertentu. Ini komponen kemudian dikualifikasi, diadaptasi, dan diintegrasikan untuk digunakan dalam sistem baru.

Komponen yang dapat digunakan kembali harus dirancang dalam lingkungan yang terbentuk struktur data standar, protokol antarmuka, dan arsitektur program untuk masing-masing domain aplikasi.

CHAPTER 11 : USER INTERFACE DESIGN

Antarmuka pengguna dapat dikatakan sebagai elemen terpenting dari sistem atau produk berbasis komputer. Jika antarmuka dirancang dengan buruk, kemampuan pengguna untuk memanfaatkan daya informasi dan konten informasi aplikasi mungkin sangat parah. terhalang. Bahkan, antarmuka yang lemah dapat menyebabkan yang dirancang dengan baik dan solid aplikasi yang diimplementasikan gagal. Tiga prinsip penting memandu desain antarmuka pengguna yang efektif: (1) tempat pengguna yang memegang kendali, (2) mengurangi beban memori pengguna, dan (3) membuat antarmuka konsisten. Untuk mencapai antarmuka yang mematuhi prinsip-prinsip ini, desain yang terorganisir proses harus dilakukan. Pengembangan antarmuka pengguna dimulai dengan serangkaian tugas analisis. Pengguna analisis mendefinisikan profil berbagai pengguna akhir dan dikumpulkan dari berbagai sumber bisnis dan teknis. Analisis tugas menentukan tugas dan tindakan pengguna menggunakan baik pendekatan elaboratif atau berorientasi objek, menerapkan kasus penggunaan, tugas dan obyektif elaborasi, analisis alur kerja, dan representasi tugas hierarkis untuk sepenuhnya memahami interaksi manusia-komputer. Analisis lingkungan mengidentifikasi struktur fisik dan sosial tempat antarmuka harus beroperasi.
Setelah tugas telah diidentifikasi, skenario pengguna dibuat dan dianalisis untuk didefinisikan satu set objek antarmuka dan tindakan. Ini memberikan dasar untuk pembuatan layar tata letak yang menggambarkan desain grafis dan penempatan ikon, definisi deskriptif teks layar, spesifikasi dan titling untuk windows, dan spesifikasi mayor dan minor item menu. Masalah desain seperti waktu respons, struktur perintah dan tindakan, penanganan eror, dan fasilitas bantuan dianggap sebagai model disempurnakan. Varietas alat implementasi digunakan untuk membangun prototipe untuk evaluasi oleh pengguna. Seperti desain antarmuka untuk perangkat lunak konvensional, desain antarmuka WebApp menjelaskan struktur dan organisasi dari antarmuka pengguna dan termasuk repre sentation tata letak layar, definisi mode interaksi, dan deskripsi mekanisme navigasi. Seperangkat prinsip desain antarmuka dan alur kerja desain antarmuka memandu seorang desainer WebApp ketika desain tata letak dan kontrol antarmuka dirancang.
Antarmuka pengguna adalah jendela ke dalam perangkat lunak. Dalam banyak kasus, antarmuka membentuk persepsi pengguna tentang kualitas sistem. Jika "jendela" tercoreng, bergelombang, atau rusak, pengguna dapat menolak sistem berbasis komputer yang kuat.

CHAPTER 12 : PATTERN BASED DESIGN

Pola desain menyediakan mekanisme yang dikodifikasikan untuk menggambarkan masalah dan masalahnya

solusi dengan cara yang memungkinkan komunitas rekayasa perangkat lunak untuk menangkap desain

pengetahuan untuk digunakan kembali. Pola menjelaskan masalah, menunjukkan konteks yang memungkinkan

pengguna untuk memahami lingkungan di mana masalah itu berada, dan daftar sistem kekuatan yang menunjukkan bagaimana masalah dapat ditafsirkan dalam konteksnya dan

bagaimana solusinya dapat diterapkan. Dalam pekerjaan rekayasa perangkat lunak, kami mengidentifikasi dan mendokumentasikan pola generatif yang menggambarkan aspek sistem yang penting dan dapat diulang dan kemudian memberi kami cara untuk membangun aspek itu dalam suatu sistem kekuatan.

itu unik untuk konteks tertentu.

Pola arsitektur menggambarkan masalah desain berbasis luas yang diselesaikan

menggunakan pendekatan struktural. Pola data menggambarkan masalah berorientasi data berulang dan solusi pemodelan data yang dapat digunakan untuk menyelesaikannya. Komponen

pola (juga disebut sebagai pola desain) mengatasi masalah yang terkait dengan

pengembangan subsistem dan komponen, cara mereka berkomunikasi satu sama lain, dan penempatannya dalam arsitektur yang lebih besar.

Antarmuka pola desain menggambarkan masalah antarmuka pengguna umum dan solusinya

sistem kekuatan yang mencakup karakteristik spesifik pengguna akhir. Aplikasi website

pola mengatasi set masalah yang dihadapi saat membangun WebApps dan sepuluh menggabungkan banyak kategori pola lain yang baru saja disebutkan. Kerangka kerja

menyediakan infrastruktur di mana pola dapat tinggal dan idiom menggambarkan detail implementasi spesifik-bahasa pemrograman untuk semua atau sebagian dari algo rithm atau struktur data tertentu. Formulir atau templat standar digunakan untuk deskripsi pola.

Bahasa pola meliputi koleksi pola, masing-masing dijelaskan menggunakan a

template terstandarisasi dan saling terkait untuk menunjukkan bagaimana pola-pola ini berkolaborasi

menyelesaikan masalah di seluruh domain aplikasi.

Desain berbasis pola digunakan bersama dengan arsitektur, tingkat komponen,

dan metode desain antarmuka pengguna. Pendekatan desain dimulai dengan pemeriksaan model persyaratan untuk mengisolasi masalah, mendefinisikan konteks, dan menggambarkan sistem kekuatan. Selanjutnya, bahasa pola untuk domain masalah dicari tentukan apakah ada pola untuk masalah yang telah diisolasi. Setelah pola makan yang tepat telah ditemukan, mereka digunakan sebagai panduan desain..

CHAPTER 13 : WEBAPP DESIGN

Kualitas WebApp - didefinisikan dalam hal kegunaan, fungsi, keandalan, efisiensi, pemeliharaan, keamanan, skalabilitas, dan waktu-ke-pasar - diperkenalkan selama desain. Untuk mencapai atribut kualitas ini, desain WebApp yang baik harus dipamerkan karakteristik berikut: kesederhanaan, konsistensi, identitas, ketahanan, kemampuan navigasi, dan daya tarik visual. Untuk mencapai karakteristik ini, aktivitas desain WebApp berfokus pada enam elemen desain yang berbeda. Desain antarmuka menggambarkan struktur dan organisasi dari antarmuka pengguna dan termasuk representasi tata letak layar, definisi mode interaksi, dan deskripsi mekanisme navigasi. Seperangkat prinsip desain antarmuka dan alur kerja desain antarmuka memandu Anda saat tata letak dan mekanisme kontrol antarmuka dirancang. Desain estetika, juga disebut desain grafis, menggambarkan "tampilan dan nuansa" dari WebApp dan termasuk skema warna; tata letak geometris; ukuran teks, font, dan tempat; penggunaan grafik; dan keputusan estetika terkait. Seperangkat desain grafis pedoman memberikan dasar untuk pendekatan desain. Desain konten menentukan tata letak, struktur, dan garis besar untuk semua konten yang dikirim sebelumnya sebagai bagian dari WebApp dan membangun hubungan antara konten benda. Desain konten dimulai dengan representasi objek konten, sebagai sosiasi, dan hubungan. Satu set primitif penjelajahan menetapkan dasar untuk desain navigasi. Desain arsitektur mengidentifikasi keseluruhan struktur hypermedia untuk WebApp dan mencakup arsitektur konten dan arsitektur WebApp. Arsitektur gaya untuk konten meliputi struktur linier, kisi, hierarkis, dan jaringan. Aplikasi website arsitektur menggambarkan infrastruktur yang memungkinkan sistem atau aplikasi berbasis Web untuk mencapai tujuan bisnisnya.

Desain navigasi mewakili aliran navigasi antara objek konten dan

untuk semua fungsi WebApp. Semantik navigasi didefinisikan dengan menggambarkan satu set

unit semantik navigasi. Setiap unit terdiri dari cara navigasi dan naviga link dan node nasional. Sintaks navigasi menggambarkan mekanisme yang digunakan untuk mempengaruhi

navigasi digambarkan sebagai bagian dari semantik.

Desain komponen mengembangkan logika pemrosesan terperinci yang diperlukan untuk diimplementasikan

komponen fungsional yang menerapkan fungsi WebApp lengkap. Desain

teknik yang diuraikan dalam Bab 10 berlaku untuk rekayasa WebApp

komponen.

Metode Desain Hypermedia Berorientasi Objek (OOHDM) adalah salah satu dari sejumlah

metode yang diusulkan untuk desain WebApp. OOHDM menyarankan proses desain itu

termasuk desain konseptual, desain navigasi, desain antarmuka abstrak, dan

penerapan.

CHAPTER 14 : QUALITY CONCEPTS

Kepedulian terhadap kualitas sistem berbasis perangkat lunak telah tumbuh sebagai perangkat lunak

menjadi terintegrasi ke dalam setiap aspek kehidupan kita sehari-hari. Tetapi sulit untuk dikembangkan

deskripsi komprehensif kualitas perangkat lunak. Dalam bab ini kualitas telah didefinisikan sebagai proses perangkat lunak yang efektif diterapkan dengan cara yang menciptakan yang bermanfaat produk yang memberikan nilai terukur bagi mereka yang memproduksinya dan mereka yang gunakan.

Berbagai dimensi dan faktor kualitas perangkat lunak telah diajukan selama bertahun-tahun. Semua mencoba untuk mendefinisikan serangkaian karakteristik yang, jika tercapai, akan mengarah pada kualitas perangkat lunak yang tinggi. Faktor kualitas McCall dan ISO 9126 menetapkan karakteristik karakter seperti keandalan, kegunaan, pemeliharaan, fungsionalitas, dan portabilitas sebagai indikator bahwa kualitas ada.

Setiap organisasi perangkat lunak dihadapkan pada dilema kualitas perangkat lunak. Di

Intinya, semua orang ingin membangun sistem berkualitas tinggi, tetapi waktu dan upaya

diperlukan untuk menghasilkan perangkat lunak "sempurna" hanya tidak tersedia di pasar-driven

dunia. Pertanyaannya menjadi, haruskah kita membangun perangkat lunak yang "cukup baik"?

Meskipun banyak perusahaan melakukan hal itu, ada kelemahan signifikan yang harus terjadi dipertimbangkan.

Terlepas dari pendekatan yang dipilih, kualitas memang memiliki biaya yang bisa

dibahas dalam hal pencegahan, penilaian, dan kegagalan. Biaya pencegahan termasuk semua

tindakan rekayasa perangkat lunak yang dirancang untuk mencegah cacat sejak awal.

Biaya penilaian dikaitkan dengan tindakan-tindakan yang menilai produk kerja perangkat lunak untuk menentukan kualitasnya. Biaya kegagalan mencakup harga kegagalan internal dan efek eksternal yang mengendap dengan kualitas buruk.

Kualitas perangkat lunak dicapai melalui penerapan rekayasa perangkat lunak

metode, praktik manajemen yang solid, dan kontrol kualitas yang komprehensif — semuanya didukung oleh infrastruktur jaminan kualitas perangkat lunak.

CHAPTER 15 : REVIEW TECHNIQUES

Maksud dari setiap tinjauan teknis adalah untuk menemukan kesalahan dan mengungkap masalah yang mungkin terjadi dampak negatif pada perangkat lunak yang akan digunakan. Semakin cepat kesalahan terungkap dan

dikoreksi, semakin kecil kemungkinan kesalahan akan menyebar ke pekerjaan rekayasa perangkat lunak lainnya

produk dan memperkuat dirinya sendiri, sehingga secara signifikan lebih banyak upaya untuk memperbaikinya.

Untuk menentukan apakah kegiatan kontrol kualitas berfungsi, satu set metrik harus dikumpulkan. Tinjau metrik fokus pada upaya yang diperlukan untuk melakukan tampilan ulang dan jenis serta tingkat kesalahan yang ditemukan selama peninjauan. Sekali metrik Data dikumpulkan, mereka dapat digunakan untuk menilai kemanjuran ulasan yang Anda lakukan. Data industri menunjukkan bahwa ulasan memberikan pengembalian investasi yang signifikan.

Model referensi untuk formalitas ulasan mengidentifikasi peran yang dimainkan orang, perencanaan

dan persiapan, struktur pertemuan, pendekatan koreksi, dan verifikasi sebagai karakteristik yang menunjukkan tingkat formalitas yang dengannya suatu tinjauan dilakukan. Ulasan informal sifatnya kasual, tetapi masih dapat digunakan secara efektif untuk mengatasi kesalahan. Ulasan formal lebih terstruktur dan memiliki probabilitas tertinggi mengarah ke perangkat lunak berkualitas tinggi.

Ulasan informal ditandai oleh perencanaan dan persiapan minimal dan sedikit

pencatatan. Pemeriksaan meja dan pemrograman pasangan termasuk dalam kategori tinjauan informal.

Tinjauan teknis formal adalah pertemuan bergaya yang telah terbukti sangat efektif dalam mengungkap kesalahan. Panduan dan inspeksi menetapkan peran yang ditentukan untuk setiap pengulas, mendorong perencanaan dan persiapan terlebih dahulu, diperlukan penerapan pedoman peninjauan yang ditetapkan, dan mandat pencatatan dan pelaporan staf. Ulasan berbasis sampel dapat digunakan jika tidak memungkinkan untuk dilakukan

Ulasan teknis formal untuk semua produk kerja.

CHAPTER 16 : SOFTWARE QUALITY ASSURANCE

Jaminan kualitas perangkat lunak adalah kegiatan payung rekayasa perangkat lunak yang diterapkan

pada setiap langkah dalam proses perangkat lunak. SQA mencakup prosedur untuk yang efektif penerapan metode dan alat, pengawasan kegiatan kontrol kualitas seperti ulasan teknis dan pengujian perangkat lunak, prosedur untuk manajemen perubahan, prosedur untuk memastikan kepatuhan terhadap standar, dan mekanisme pengukuran dan pelaporan.

Untuk melakukan penjaminan kualitas perangkat lunak dengan benar, data tentang proses pengerjaan perangkat lunak harus dikumpulkan, dievaluasi, dan disebarluaskan. SQA statistik membantu meningkatkan kualitas produk dan proses perangkat lunak itu sendiri. Perangkat lunak model keandalan memperluas pengukuran, memungkinkan data cacat yang dikumpulkan diekstrapolasi ke dalam tingkat kegagalan yang diproyeksikan dan prediksi keandalan.

Jaminan kualitas adalah pemetaan aturan manajerial dan disiplin desain

jaminan kualitas ke ruang manajerial dan teknologi yang berlaku

rekayasa perangkat lunak. ”Kemampuan untuk memastikan kualitas adalah ukuran orang dewasa

disiplin teknik. Ketika pemetaan berhasil dilakukan, matang

hasilnya adalah rekayasa perangkat lunak.

Resume 17-selesai KLIK DISINI

Sumber Buku  KLIK DISINI