Bab 5 Pandangan Umum Praktek Tujuan Pembelajaran Umum Menjelaskan Perangkat Lunak Sebagai Proses Tujuan Pembelajaran Khusus Mampu Menjelaskan Pandangan Umum Praktik
Di dalam melakukan praktek terdiri dari : konsep prinsip metode alat Sesuatu yang harus diperhatikan ketika software direncanakan dan dikembangkan. Dia menunjukkan detail-bagaimana peralatan dari proses perangkat lunak. Esseni Praktek George Polya, dalam sebuah buku yang ditulis pada tahun 1945 (!), Menggambarkan esensi dari praktek rekayasa perangkat lunak ... Memahami masalah (komunikasi dan analisis). Merencanakan solusi (pemodelan dan desain PL). Melaksanakan rencana (pembuatan kode). Memeriksa akurasi hasil (menguji dan QA). Pada intinya, praktik yang baik adalah pemecahan masalah yang masuk akal Pertimbangkan kerangka proses generik komunikasi Perencanaan modeling analisis Pemodelan desain Modeling konstruksi coding pengujian penyebaran
Dalam mengembangkan perangkat lunak diperlukan kemampuan praktis. Prinsip-prinsip praktis yang ada di dalam pengembangan perangkat lunak antara lain : komunikasi praktis, perencanaan praktis, model praktis, model perancangan, model agile, mengkode dan mendeployment.
Prinsip-prinsip Komunikasi Praktis
Mendengarkan secara efektif Siapkan sebelum Anda berkomunikasi Seseorang harus memfasilitasi kegiatan Komunikasi tatap muka adalah yang terbaik Mencatat dan mendokumentasikan keputusan Upayakan untuk kolaborasi Tetap fokus, diskusi modularize Jika ada sesuatu yang tidak jelas, gambarkan Tahu kapan untuk melanjutkan Negosiasi bekerja paling baik maka kedua belah pihak menang
Prinisp-prinsip Perencanaan Praktis
Memahami ruang lingkup proyek Libatkan konsumen dalam perencanaan Mengakui bahwa perencanaan adalah iteratif Perkiraan didasarkan pada apa yang Anda tahu Pertimbangkan risiko sebagai Anda mendefinisikan rencana Bersikaplah realistis Sesuaikan granularity saat Anda mendefinisikan rencana Tentukan bagaimana Anda berniat untuk memastikan kualitas Jelaskan bagaimana Anda berniat untuk mengakomodasi perubahan Melacak rencana sering dan membuat penyesuaian yang diperlukan
Pengorganisasian Prinsip Bohem W5HH itu. Jawaban untuk pertanyaan-pertanyaan berikut mengarah pada rencana proyek, antara lain : 1. 2. 3. 4. 5. 6. 7.
Mengapa sistem mulai dikembangkan? Apa yang akan dilakukan? Kapan akan dilakukan? Siapa yang bertanggung jawab? Di mana mereka berada (organisatoris)? Bagaimana tugas diselesaikan secara teknis maupun manajerial? Berapa banyak dari setiap sumber daya yang dibutuhkan?
Prinsip-prinsip Modeling Praktis 1. 2. 3. 4.
Analisis prinsip pemodelan Mewakili domain informasi Merupakan fungsi perangkat lunak Mewakili perilaku perangkat lunak
5. Partisi representasi ini 6. Pindah dari esensi menuju implementasi Prinsip-prinsip Model Perancangan 1. 2. 3. 4. 5. 6. 7. 8. 9.
Desain harus dapat dilacak dari model analisis Selalu mempertimbangkan arsitektur Fokus pada desain data Antarmuka (pengguna maupun internal) harus dirancang User interface harus mempertimbangkan pengguna pertama Komponen harus menunjukkan independensi fungsional Komponen harus longgar digabungkan Representasi desain harus mudah dipahami Model desain harus dikembangkan secara iteratif
Prinsip-prinsip model agile (ambler 2002) 1. Tujuan utamanya adalah untuk membuat perangkat lunak, tidak membangun model 2. Jangan membuat model yang lebih dari yang Anda butuhkan 3. Memproduksi model sederhana yang akan menjelaskan masalah 4. Model yang mudah untuk mengubah Membangun 5. Bisa menyatakan tujuan yang jelas untuk masing-masing model 6. Sesuaikan model yang Anda kembangkan untuk sistem di tangan 7. Membangun model yang berguna, bukan yang sempurna 8. Fokus pada apa model berkomunikasi, tidak sintaks 9. Jika Anda merasa tidak nyaman dengan model, ada sesuatu yang mungkin salah 10. Dapatkan umpan balik sesegera mungkin Prinsip-prinsip mengkode Persiapan. Sebelum Anda menulis satu baris kode, pastikan Anda: 1. 2. 3. 4. 5.
Memahami dari masalah Anda mencoba untuk memecahkan Memahami prinsip-prinsip desain dan konsep dasar. Pilih sebuah bahasa pemrograman yang sesuai. Pilih lingkungan pemrograman yang tepat dan alat-alat. Buat unit test untuk setiap komponen Anda berencana untuk membuat.
Coding. Ketika Anda mulai menulis kode, pastikan Anda: 1. 2. 3. 4. 5.
Ikuti pemrograman terstruktur [BOH00] praktek. Pilih struktur data yang akan memenuhi kebutuhan desain. Membuat antarmuka yang konsisten dengan arsitektur perangkat lunak. Jaga logika kondisional sesederhana mungkin. Buat loop bersarang dalam cara yang membuat mereka mudah diuji.
6. Pilih nama variabel yang bermakna, dan ikuti standar lokal lainnya. 7. Menulis kode yang mendokumentasikan diri. 8. Membuat layout visual yang membantu pemahaman. Validasi. Setelah Anda menyelesaikan lulus pertama, pastikan Anda: 1. Melakukan pelacakan kode ketika dimungkinkan. 2. Melakukan tes unit dan memperbaiki kesalahan yang telah ditemukan. 3. Refactor kode.
Prinsip-prinsip pengujian 1. 2. 3. 4. 5.
Semua pengujian harus sesuai dengan persyaratan Pengujian harus direncanakan Prinsip Pareto berlaku untuk pengujian Pengujian dimulai "di kecil" dan bergerak ke arah "di besar" Pengujian mendalam tidak mungkin
Catatan: Sebuah tes yang sukses adalah salah satu yang mengungkap kesalahan yang belum ditemukan. Prinsip-prinsip Deployment 1. 2. 3. 4. 5.
Mengelola harapan pelanggan untuk setiap kenaikan Sebuah paket lengkap pengiriman harus dirakit dan diuji Sebuah rezim dukungan harus dibentuk Bahan ajar harus diberikan kepada pengguna akhir Buggy perangkat lunak harus diperbaiki terlebih dahulu, kemudian disampaikan
Bab 6 Rekayasa Sistem
Tujuan Pembelajaran Umum Mendeskripsikan Perangkat Lunak Praktis Tujuan Pembelajaran Khusus Mampu Mengidentifikasikan Rekayasa Sistem
Rekayasa Sistem Komputer (Computer system engineering) terdiri atas 2 bagian, yaitu : Hardware engineering Software engineering
Setiap disiplin ini berusaha menunjukkan pengembangan sistem berbasis komputer tehnik engineering. Untuk hardware komputer telah sedemikian maju dan relatif jenuh. Sebaliknya software komputer mulai berkembang, dan saat ini menggantikan peranan hardware sebagai elemen sistem yang sulit direncanakan, sedikit kemungkinan untuk berhasil dengan biaya rendah dan waktu yang cepat, serta paling sukar untuk dikelola. Apa Sistem itu ? Sistem adalah sekumpulan elemen yang saling berinteraksi untuk mencapai suatu tujuan. Sedangkan Computer Based System diorganisir untuk mendapatkan beberapa metode, prosedur atau pengontrolan dengan cara mengelola informasi. Elemen-elemen dari sistem berbasis komputer adalah : 1. Software Program komputer, struktur data dan dokumentasi yang saling berhubungan dan memberikan efek pada metode, prosedur dan kontrol yang diinginkan. 2. Hardware Peralatan elektronik, (misalnya CPU, memory) yang memberikan kemampuan komputasi serta peralatan elektromedia (misalnya sensor, motor, pompa) yang memberikan fungsi external.
3. People / Brainware User dan operator dari hardware dan software 4. Database Sekumpulan informasi yang besar, yang diorganisir agar dapat diakses oleh software dan merupakan bagian integral dari fungsi sistem. 5. Prosedur Langkah-langkah yang menetapkan pemakaian khusus untuk setiap elemen sistem.
PROCEDURE
DATABASE
INPUT
HARDWARE
OUTPUT
SYSTEM
DOCUMENT
SOFTWARE
PEOPLE
Gambar 6.1.: elemen system berbasis komputer Pemodelan system Menentukan proses yang melayani kebutuhan sesuai dengan konsideran yang ada. Menampilkan perilaku proses dan asumsi dimana perilaku itu berada. Secara eksplisit menentukan input exogen dan endogen pada model. Input exogen menghubungkan satu konstituen dan satu pandangan dengan konstituen lain pada tingkat yang sama di level yang lain. Input endogen menghubungkan komponen individu pada konstituen pada pandangan khusus. Menampilkan seluruh kaitan (termasuk output) yang memungkinkan engineer mempunya pemahaman yang lebih baik Pemodelan system secara hierarkhi
Gambar 6.2. : Pemodelan system hyrarkhi
Arsitektur Sistem Didalam pengembangan system gambaran mengenai arsitektur system diharuskan, adapun arsitektur yang dibutuhkan untuk mendukung proses analisis dan desain system sesuai tujuan bisnis Tiga arsitektur yang berbeda harus dianalisis dan didesain dalam konteks tujuan bisnis: Arsitektur data Arsitektur aplikasi Arsitektur teknologi Arsitektur data menyediakan bingkai kerja untuk kebutuhan infromasi dari bisnis atau fungsi bisnis Arsitektur aplikasi mencakup elemen-elemen sistem yang mentransformasi objek dalam arsitektur data untuk tujuan bisnis Infrastruktur teknologi menyediakan pondasi untuk arsitektur data dan arsitektur aplikasi
Hierarkhi BPE Information strategy planning (ISP) o o o
Tujuan strategis ditentukan Faktor sukses/aturan bisnis ditentukan Model perusahaan dibuat
Business area analysis (BAA) o o
Proses/layanan dimodelkan Inter-relasi proses dan data
Application Engineering o o
RPL Pemodelan aplikasi/prosedur yang merujuk pada BAA dan batasan-batasan ISP
Construction and delivery o
menggunakan CASE dan 4GTs, pengujian
Didalam melakukan informationa strategy planning (ISP) diperlukan informasi isu-isu seperti : Isu manajemen o o o o
Menentukan tujuan bisnis strategis Isolasi critical success factors Melakukan analisis pada pengaruh teknologi Melakukan analisis pada sistem strategis
Isu teknis o o o
Membuat model data tingkat tertinggi Dikelompokkan berdasar area bisnis/organisasi Memperbaiki model dan clustering
Menentukan tujuan dan sasaran : Tujuan—pernyataan umum tentang arahan
Sasaran—menentukan tujuan yang bisa diukur : mengurangi biaya pabrik pada produk o Sub Sasaran: Menurunkan angka reject dengan 20% di dalam 6 bulan pertama Memperoleh konsesi 10% dari supplier re-engineer 30% dari komponen untuk fabrikasi yang lebih mudah selama tahun pertama Tujuan cenderung strategis, sasaran cenderung taktis Business Area Analysis Menemukan “pengelompokan fungsi dan data bisnis yang secara natural kohesif” (Martin) Melakukan aktivitas yang banyak sama dengan ISP, tetapi lingkupnya lebih dekat ke area bisnis individual Mengenali sistem informasi yang telah ada sebelumnya/menentukan kompatibilitas dengan model ISP baru o Menentukan sistem yang bermasalah o Menemukan sistem yang tidak kompatibel dengan model informasi baru o Mulai membuat prioritas re-engineering
Gambar 6.3. : Proses BAA
Rekayasa Produk
Gambar 6.4. : Rekayasa Produk Template Arsitektur produk
Gambar 6.5. : Template Arsitektur Produk
Gambar 6.6. : Diagram Arsitektur Flow Diagram Pemodelan system dengan UML o
o
Deployment diagrams ê Setiap box 3D menggambarkan elemen perangkat keras yang merupakan bagian arsitektur fisik dari sistem Activity diagrams
o
ê Menampilkan aspek prosedural dari elemen sistem Class diagrams ê Menampilkan elemen tingkat sistem dalah hal data yang menjelaskan elemen dan operasi yang memanipulasi data tersebut
These and other UML models will be discussed later Deployment Diagram Deployment diagram digunakan untuk memvisualisasikan topologi komponen fisik dari sebuah sistem dimana komponen perangkat lunak yang digunakan. Jadi deployment diagram digunakan untuk menjelaskan pandangan penyebaran statis dari sebuah sistem. Deployment diagram terdiri dari node dan hubungan mereka. http://www.tutorialspoint.com/uml/uml_deployment_diagram.htm
CLSS processor
Operat or display
Sort ing subsyst em
Sensor dat a acquisit ion subsyst em
Conveyor Pulse t ach
shunt cont roller
Bar code reader
Shunt act uat or
Gambar 6.7. : Deployment Diagram Activity Diagram Activity diagram adalah diagram lain yang penting dalam UML untuk menggambarkan aspek dinamis dari sistem. Diagram aktivitas pada dasarnya adalah diagram alir untuk mewakili aliran bentuk satu kegiatan dengan kegiatan lain. Kegiatan dapat digambarkan sebagai operasi dari sistem. Jadi aliran kontrol diambil dari satu operasi yang lain. Aliran ini bisa berurutan, bercabang atau bersamaan. Activity diagram berhubungan dengan semua jenis kontrol aliran dengan menggunakan unsur-unsur yang berbeda seperti garpu, dll bergabung
st a rt c o n v e y o r l i n e
g e t c o n v e y o r sp e e d
re a d b a r c o d e
valid bar code
inv alid bar c ode
det er m ine bin loc at ion
se t f o r re j e c t b i n
se n d sh u n t c o n t ro l d a t a
g e t sh u n t st a t u s
g e t c o n v e y o r st a t u s
re a d b a r c o d e
p ro d u c e re p o rt e n t ry
c onveyor s t opped
c onveyor in m ot ion
Gambar 6.8. : Diagram Activity Class Diagram Class Diagram adalah diagram statis. Ini merupakan pandangan statis dari sebuah aplikasi. Diagram kelas tidak hanya digunakan untuk memvisualisasikan, menggambarkan dan mendokumentasikan aspek yang berbeda dari sistem tetapi juga untuk membangun kode dieksekusi dari aplikasi perangkat lunak. Diagram kelas menggambarkan atribut dan operasi kelas dan juga kendala yang dikenakan pada sistem. Diagram kelas yang banyak digunakan dalam pemodelan sistem berorientasi objek karena mereka adalah satu-satunya diagram UML yang dapat dipetakan secara langsung dengan bahasa berorientasi objek. Diagram kelas menunjukkan koleksi kelas, interface, asosiasi, kolaborasi dan kendala. Hal ini juga dikenal sebagai diagram struktural.
class name
Box barcode forwardSpeed conveyorLocat ion height widt h dept h weight cont ent s readBarcode( ) updat eSpeed ( ) readSpeed( ) updat eLocat ion( ) readLocat ion( ) get Dimensions( ) get Weight( ) checkCont ent s( )
at t ribut es not e use of capit al let t er f or mult i-word at t ribut e names
operat ions ( parent heses at end of name indicat e t he list of at t ribut es t hat t he operat ion requires)
Gambar 6.9. : Class Diagram
