2 pengantar uml

Pengantar UML …

I Dewa Md. Adi Baskara Joni S.Kom., M.Kom

Metode Pengembangan s/w Object Oriented Analysis Object oriented Design Rational Unified Process

Sistem Yang Tepat?

Cerita tentang pria & wanita tuna netra Opini yg kuat Masing-masing benar Masing-masing salah Tidak satupun dari

mereka pernah melihat gajah

Bagaimana Sistem Dibangun?

Spesifikasi -> Solusi

Requirements

Requirements

Object Oriented Software Product

Object Oriented Software Product

Analisis, desain, implementasi, pengujian & perbaikan

USER Needs Solution

Pendekatan Berorientasi Objek Proses yang lebih teliti Banyak waktu yg disediakan utk mendapatkan

requirement, membangun model requirement dan model analisis, selanjutnya diubah menjadi model desain

Tidak perlu melihat code sampai waktu pembangunan 25%

Proses Pengembangan S/W

“Proses untuk mengubah, memperbaiki, transformasi dan menambah produk yg ada”

Transformasi I (Analisis)Menerjemahkan kebutuhan user ke dalam

requirements & tanggung jawab (resposibilities) sistem Bagaimana sistem akan digunakan dapat

menambahkan informasi requirement

Proses Pengembangan S/W

“Proses untuk mengubah, memperbaiki, transformasi dan menambah produk yg ada”

Transformasi II (Desain)Dimulai dengan pernyataan permasalahaan,

berakhir dengan detil desain yg dapat diwujudkan menjadi sistem operasional Kegiatan pembangunan, termasuk definisi tentang

bagaimana membangun perangkat lunak, pengembangan, pengujian, deskripsi desain dan program

Proses Pengembangan S/W

“Proses untuk mengubah, memperbaiki, transformasi dan menambah produk yg ada”

Transformasi III (Implementasi)Menyempurnakan detil desain ke deployment

sistem yang akan memenuhi kebutuhan user Memperhitungkan peralatan, prosedur, SDM, dll Bagaimana perwujudan produk (s/w) dalam

lingkungan operasionalnya

Konsep ObyekObyek dalam “Software Analysis & Design”

adalah sesuatu berupa konsep, benda, dan sesuatu yg membedakannya dari lingkungannya

• Tinggi• Berat badan• Bentuk wajah• (Bernafas)• (Makan)• (Bertumbuh)

Dasar OOA & OOD

Kaidah-kaidah standar Subyektifitas software analyst

Suatu permasalahan pasti memiliki lebih dari satu solusi

Dasar OOA & OOD

Terdapat 3 konsep dasar OOA & OOD:1. Pemodulan (Encapsulation)2. Penurunan (Inheritance)3. Polymorphism

EncapsulationInformation hidingPembungkusan,

menjaga proses agar tidak dapat diakses sembarangan atau diintervensi

Dilakukan utk menjaga keutuhan program agar dapat diakses sewaktu-waktu

Inheritance

Hubungan dua kelas atau lebih

Kelas parent mewariskan atribut dan metodenya kepada kelas child

Terdapat atribut dan metode tambahan dari kelas child yg menjadi sifat khusus yg membedakannya

BIKE

PolymorphismDapat menimpa

(override) suatu method dari parent yg diturunkan, sehingga memiliki kelakuan yg berbeda

Obyek child melakukan metode yg sama dengan algoritma yg berbeda dengan parent

Gejala Permasalahan S/W Development

Kebutuhan bisnis dan user tidak sesuaiPergolakan RequirementsModules tidak terintegrasiSusah untuk dikelolaKelemahan yang terlambat diketahuiKualitas buruk Kinerja buruk Tidak ada upaya terkoordinasi dari tim

Kebutuhan bisnis dan user tidak sesuaiPergolakan RequirementsModules tidak terintegrasiSusah untuk dikelolaKelemahan yang terlambat diketahuiKualitas buruk Kinerja buruk Tidak ada upaya terkoordinasi dari tim

Yang umumnya terjadi, in fact !Yang umumnya terjadi, in fact !

Gejala -> Penyebab -> Solusi

Symptoms Root Causes

Tidak sesuai

Requirements kacau

Modules tdk sesuai

Susah dikelola

Penemuan yg lambat

Kualitas rendah

Kinerja rendah

Masalah pengembang

Kurangnya requirements

Komunikasi yg ambigu

Arsitektur rapuh

Terlalu kompleks

Tidak konsisten

Kurangnya testing

Penilaian subyektif

Metode waterfall

Perubahan tak terkontrol

Kurangnya otomatisasi

Best Practices

Bangun secara iteratif

Kelola requirements

Gunakan arsitektur komponen

Pemodelan Visual (UML)

Verfifikasi kualitas berkerlanjutan

Mengontrol perubahan (UCM)

Software Development Best Practices

Best PracticesBest Practices

Develop IterativelyManage Requirements

Develop IterativelyManage Requirements

Waterfall

Penemuan Masalah yang Terlambat Subyektif dan Kesalahan Pengukuran

Progress Integrasi dan Testing yang Terlambat Menghalangi deployment awal

TimeTime

Subsystem integration

Requirements analysisDesign

Code and unit test

System test

Pengembangan Iteratif

TimeTime

Requirements analysis

Design

Code and unit test

Subsystem integration

System test

Iteration 1 Iteration 2 Iteration 3

Requirements analysis

Design

Code and unit test

Subsystem integration

System test

Requirements analysis

Design

Code and unit test

Subsystem integration

System test

Resiko dikendalikan perencanaan iterasi

Setiap iterasi menghasilkan rilis executable Penilaian melalui tes obyektif

Integrasi dan Testing berkelanjutan

Waterfall VS Iterative

Risk Reduction

TimeTime

Iterative Risk

Waterfall Risk

Ris

kR

isk

PrototypingVersi dari pembangunan produk s/w pada

tahap awal life cycle produkDibuat prototype dari key component

sistem yang akan dibangunDengan prototype menjadi dasar yang

lebih konsisten dengan requirements yg telah ditetapkan

Prototype disempurnakan menjadi produk akhir

Rapid Application Development

Teknik untuk membangun aplikasi lebih cepat

Seringkali digunakan dengan software protoptyping

Pengembangan secara iterasiDimulai ketika desain selesai

Apakah problem sudah jelas? (Analisis)

Apakah sistem dapat melakukan apa yg seharusnya? (Desain)

Dilakukan perbaikan dalam setiap iterasi

Menghasilkan Rilis Executable

Initial Planning

Planning

RequirementsAnalysis & Design

Implementation

Test

DeploymentEvaluation

ManagementEnvironment

Setiap iterasi menghasilkan rilis executable

Pendekatan Pengembangan Sistem Object-Oriented

Rational Unified Process

Proses pengembangan perangkat lunak dibuat praktis untuk semua anggota tim

Terbukti sebagai software development (out-of-the-box)

Mudah diadopsi

Terotomatisasi dengan Rational tools

Rational Unified ProcessRational Unified Process

Software Development Best Practices

Best PracticesBest Practices

Develop IterativelyManage RequirementsDevelop IterativelyManage Requirements

Pengelolaan Requirements

Berfokus pada requirements kunci Tangkap dan dokumentasikan Kelola dan prioritaskan

Requirements akan berubah Evaluasi dampak dari perubahan dan tentukan perubahan

apa yg akan diimplementasikan Sosialisasikan perubahan ke seluruh anggota tim

Buat requirements accessible

Requirements management leverages your ability to deliver products

that meet users current needs

Menangkap dan Mengelola Requirements

Our UML …