Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak

Tujuan

Mengenal masalah yang berkaitan dengan pembangunan software

Memahami kebutuhan perlunya pendekatan yang terstruktur untuk pembangunan software

Mampu mengambil kesimpulan tentang definisi software engineering (rekayasa perangkat lunak)

Kegagalan

Over budget / Anggaran yang membengkak

Over budget / Over schedule
-- anggaran dan jadwal yang membengkak

Lebih banyak lagi projek-projek yang gagal karena tidak menggunakan RPL. Kegagalan terjadi karena :

o        Ukuran projek tidak sebanding dengan usaha/SDM

o        Berhentinya personil  kunci

o        Gagal mengerti kebutuhan

o        Projek yang dihasilkan tidak sesuai dengan kualitas

o        Munculnya teknologi baru

o        dll

What makes software special?

1. Sulit bagi klien untuk menentukan kebutuhan secara lengkap
2. Sulit bagi pembangun untuk benar-benar mengerti keperluan klien
3. Dalam memastikan dan memahami kebutuhan, khususnya perubahan kebutuhan, informasi yang banyak perlu dikomunikasikan dan dipahamikan secara terus-menerus.
4. Software cenderung mudah untuk diubah
5. Pembangunan software memerlukan pengalaman, pemikiran dan imaginasi
6. Sulit menguji software secara teliti dan menyeluruh

q  Rekayasa Perangkat Lunak adalah

                cabang computer science yang                  berhubungan dengan pembangunan     sistem perangkat lunak yang besar                 dan        kompleks, sehingga dibangun    oleh suatu tim (Ghezzi).

v  Rekayasa Perangkat Lunak (IEEE) :

         aplikasi/penerapan dari pendekatan yang   sistematis, disiplin dan  terkuantifikasi untuk   mengembangkan, menjalankan dan          memelihara perangkat lunak

v  Rekayasa Perangkat Lunak (Fritz Baeur) :

                pembentukan dan penggunaan prinsip-prinsip teknik untuk mendapatkan perangkat lunak yang ekonomis yang dapat bekerja secara efisien pada mesin real.

Mitos-mitos dalam
Rekayasa Perangkat Lunak

v  Mitos Manajemen : mitos-mitos yang berkaitan dengan manajemen pembangunan software.

v  Mitos Klien : mitos-mitos yang berkaitan dengan kebutuhan-kebutuhan yang menentukan unjuk kerja software

v  Mitos Praktisi : mitos-mitos yang berkaitan dengan cara kerja dan pandangan praktisi terhadap kegiatan pembangunan software

Penutup

v  Banyak contoh kasus kegagalan rekayasa perangkat lunak

v  Kegagalan bisa karena sistem dibatalkan sebelum lengkap atau dihentikan karena beberapa alasan atau selesai tapi tidak lengkap, anggaran membengkak atau tidak tepat waktu

v  Software berbeda dari produk lain

v  Perlunya pendekatan yang teratur dalam pembangunan software

v  Software engineering memerlukan teori, metode dan alat-alat untuk membangun, mengatur, mengembangkan dan merawat produk software

TUJUAN RPL

—  Memberi kerangka kerja untuk membangun perangkat lunak yang berkualitas tinggi

—  Menghasilkan perangkat lunak yang terlihat dari segi biaya sangat efisien, berkualitas dengan sumber daya terbatas dan waktu terbatas

CIRI PERANGKAT LUNAK

—  Perangkat lunak tidak akan susut atau tidak memerlukan suku cadang

—  Perangkat lunak diperoleh dari proses pengembangan bukan pabrikasi

—  Dikembangkan melalui siklus pengembangan sistem

—  Rancangan yang buruk akan meningkatkan biaya pemeliharaan

—  Kegagalan pada perangkat lunak terjadi pada rancangan, bukan karena susut

CIRI PERANGKAT LUNAK YANG DIREKAYASA DENGAN BAIK

—  Mudah dirawat

P  Diberi dokumentasi

P  Perubahan dapat dilakukan dengan biaya minimum

—  Sistem yang dibangun dapat diandalkan atau bekerja seperti yang diharapkan

—  Bekerja efisien : tidak memboroskan sumber daya (memory, prosesor, dll)

—  Mempunyai antar muka yang baik (tampilannya sesuai dengan keinginan user)

APLIKASI DARI PERANGKAT LUNAK

—  Sistem Software (menangani program-program lain). Contoh : Windows, Linux, dll

—  Realtime Software (memonitor, menganalisa dan mengendalikan peristiwa yang terjadi saat itu juga)

—  Bussines Software (penggajian, penjualan, dll)

—  Enginering Scientific Software (astronomi, arkeologi, ramalan cuaca)

—  Embeded Software (tersimpan dalam memory ROM, mengatur perangkat keras)

—  Personal Computer Software (microsoft word, microsoft excel, dll)

—  Artificial Intellegence Software (bertindak seolah-olah seperti pakar, contoh : game simulasi pesawat terbang, deteksi manusia pada AC)

4 AKTIFITAS YANG DILAKUKAN OLEH PEREKAYASA

—  Spesifikasi (perancangan)

—  Pengembangan (mengembangkan sesuai spesifikasi)

—  Validasi / Testing (pengujian)

—  Evolusi (penyesuaian sesuai perubahan yang ada)

MODEL PERANGKAT LUNAK

WATERFALL

KEUNTUNGAN

—  Berurut-urutan

—  Paling banyak dipakai

—  Masih sesuai dengan jaman sekarang

PROBLEM

—  Mengalami perulangan bila ada perubahan

—  Kerja lambat

—  Tidak bisa dilakukan tanpa melihat urutan

—  Sulit mendefinisikan kebutuhan secara jelas

PROTOTYPE

—  Model ini dipakai apabila ditemui kondisi tertentu. Apabila user mendefinisikan kebutuhan secara umum, adanya ketidakpastian user, definisi user bersifat tidak rinci

—  Sistem ini sering digunakan karena adanya usaha menyamakan persepsi

KEUNTUNGAN

—  Adanya komunikasi antar user dan pengembang

—  Meminimalkan salah persepsi

—  Peran user menjadi meningkat

—  Pengembangan lebih cepat

—  User melihat pembuatan program tahap demi tahap

—  Implementasi lebih mudah

PROBLEM

—  Waktu yang dibutuhkan lebih banyak maka diperlukan komitmen untuk menyelesaikannnya

—  User berharap terlalu banyak ; user sering berubah keinginan

—  Bekerja tidak efisien ; hanya mementingkan program selesai sehingga kurang memperhatikan hal-hal lain

SPIRAL

Merupakan gabungan antara keunggulan waterfall dan prototype.

—   Customer communication

—   Planning

—   Analisis

—   Enginering

—   Evaluasi

MEREKAYASA KEBUTUHAN

TUJUAN

—  Mampu merekayasa kebutuhan

—  Mampu membedakan kebutuhan fungsional dan non-fungsional

Apa itu Kebutuhan???

—  Pernyataan gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem atau definisi fungsi dari sistem.

—  Pernyataan dalam bahasa alami, ditambah dengan gambar tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya.

FUNGSI GANDA KEBUTUHAN

—  Menjadi dasar penawaran suatu kontrak

                à harus terbuka untuk masukkan, namun belum tentu disetujui

—  Menjadi dasar kontrak

                à harus didefinisikan secara detail

SPESIFIKASI KEBUTUHAN

Gambaran layanan sistem secara detail dan terstruktur. Ditulis sebagai kontrak.

MASALAH PENDEFINISIAN KEBUTUHAN

—  Sulit mengantisipasi efek dari sistem baru terhadap orang

—  Beda user, beda kebutuhan

—  End user sistem dan orang yang membiayai sistem berbeda kebutuhan

Masalah perbedaan bahasa alami

Bagaimana Kebutuhan Bisa Didapatkan?

—  Interview

P  Memberi informasi terbaik

P  Waktu

—  Questionnaires

P  Bagus jika banyak orang terlibat dan tersebar

P  Respon cenderung kurang baik

—  Observasi

P  Akurat, jika dilakukan dengan baik

P  Waktu

KEBUTUHAN FUNGSIONAL

—  Penjelasan tentang layanan yang perlu disediakan oleh sistem

—  Menggambarkan sistem kebutuhan secara detil, seperti input dan output

—  Harus komplit (kebutuhan layanan yang jelas dan lengkap) dan konsisten (tidak kontradiksi dengan yang didefinisikan)

Contoh kasus di perpustakaan

P  Bisa mencari informasi tentang buku

P  Memiliki pengenal yang unik (peminjam)

P  Sistem mampu mencatat transaksi secara lengkap

P  Hari libur sejak awal harus di-set dan bisa menerima perubahan dengan otoritas khusus

KEBUTUHAN NON-FUNGSIONAL

—  Berisi batasan-batasan layanan yang diperlukan sistem atau batasan-batasan pada pelayanan/fungsi yang disediakan oleh sistem. Contoh :

P  Kecepatan akses

P  Keamanan data

P  Besarnya kapasitas penyimpanan yang diperlukan

P  Privasi masing-masing profil / user account

P  Bahasa pemrograman & sistem operasi yang digunakan

—  Berkaitan dengan kebutuhan sistem secara keseluruhan

Pemodelan (Modeling)

Adalah proses merancang piranti lunak sebelum melakukan pengkodean (coding).

Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung.

Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat.

Kesuksesan suatu pemodelan perangkat lunak ditentukan oleh tiga unsur :

Memahami metode pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.

APA ITU UML???

Unified Modelling Language (UML) adalah “bahasa” yang telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak.

Menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras dan jaringan apapun, dengan memperhatikan sistem operasi serta bahasa pemrogramannya.

METODE-METODE PEMODELAN

—  Use case diagram

terdiri dari : Use cases, actors, hubungan antar use case

—  Class diagram

terdiri dari: Class, objek, attribute, operasi/behaviour/methods

hubungan antar class atau objek: association,  aggregation, composition generalization/inheritance

USE CASE DIAGRAM

Digunakan untuk menjelaskan kebutuhan.

—  Actors adalah inisiator (tidak selalu orang)

—  Use case adalah  fungsi sistem atau transaksi yang dilakukan  atau merupakan gambaran lengkap dari fungsi sistem secara umum

ACTOR

—  Actor adalah entity luar yang berkomunikasi dengan sistem, bisa berupa:

User/ pengguna/orang

External system/sistem luar

—  Actor mempunyai nama yang unik dan terkadang dengan penjelasannya

—  Contoh:

Penumpang : orang di dalam kereta

GPS satellite : menyediakan koordinat GPS

 USE CASE

Use case mewakili suatu fungsi yang disediakan sistem sebagai aliran kejadian.

Use case terdiri dari :

—   Unique name

—   Participating actors

—   Entry conditions

—   Flow of events

 Exit conditions

Contoh uses case

Unique Name : Membeli tiket

Participating actor : Penumpang

Entry condition :

*   Penumpang antri depan loket

*   Penumpang menyediakan uang untuk beli tiket

Exit condition:

*   Penumpang sudah punya tiket.

Flow of event:

1. Penumpang pilih tujuan

2. Penjual tunjukkan harga

3. Penumpang masukan uang yang sesuai.

4. Penjual beri kembalian uang (kalau ada)

5. Penjual memberikan tiket.

Jenis-Jenis Hubungan Antara Actor Dan Use Case

Extend : hubungan yang menyatakan per-kecualian --”terjadi jika..”

—  Perkecualian terjadi untuk memberi kejelasan ttg apa yang terjadi

—  Perkecualian bisa terjadi lebih dari satu

—  Arah selalu ke use case dimana perkecualian terjadi

Include :

 use case yang bisa digunakan lagi, atau digunakan oleh use case lain (tidak karena ada per-kecualian)

—  Arah  include selalu ke use case yang digunakan

USE CASE DIAGRAM

•          Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.

•          Menggambarkan kebutuhan system dari sudut pandang user

•          Mengfokuskan pada proses komputerisasi (automated processes)

•          Menggambarkan hubungan antara use case dan actor

•          Use case menggambarkan proses system (kebutuhan system dari sudut pandang user)

•          Secara umum use case adalah:

–        Pola perilaku system

–        Urutan transaksi yang berhubungan yang dilakukan oleh satu actor

•          Use case diagram terdiri dari

–        Use case

–        Actors

–        Relationship

–        System boundary boxes (optional)

–        Packages (optional)

USE CASE

•          Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya

•          Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor.

•          Use case dinotasikan dengan gambar (horizontal ellipse)

•          Use case biasanya menggunakan  kata kerja

•          Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama

ACTOR

•          Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system

•          Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan

•          Actor memberi input atau menerima informasi dari system

•          Actor biasanya menggunakan Kata benda

•          Tidak boleh ada komunikasi langsung antar actor kecuali bersifat turunan.

•          Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system

•          Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan)

Letakkan actor utama anda pada pojok kiri atas dari diagram

ASSOCIATIONS

•          Associations bukan menggambarkan aliran data/informasi

•          Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case

•          Ada 4 jenis relasi yang bisa timbul pada use case diagram

1.       Association antara actor dan use case

2.       Association antara use case

3.       Generalization/Inheritance antara use case

Generalization/Inheritance antara actors

Association antara actor dan use case

•          Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data

•          Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case   -----

•          association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda ----à

<<include>>       termasuk didalam use case lain (required) / (diharuskan)             

–        Pemanggilan use case oleh use case lain, contohnya adalah  pemanggilan sebuah fungsi program

–        Tanda panah terbuka harus terarah ke sub use case

–        Gambarkan association include secara horizontal

<<extend>> perluasan dari use case lain jika kondisi atau syarat terpenuhi

–        Kurangi penggunaan association Extend ini, terlalu banyak  pemakaian association ini membuat diagram sulit dipahami.

–        Tanda panah terbuka harus terarah ke parent/base use case

–        Gambarkan association extend secara vertical

Generalization/inheritance antara use case

•          Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum

•          Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case

•          Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition)

Generalization/inheritance antara actor

•          Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case

Use case System boundary boxes

•          Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system).

•          Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan

•          System boundary boxes dalam penggunaannya optional

ACTIVITY DIAGRAM

•          Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses

•          Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis

•          Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur

•          Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan

•          Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram

CLASS DIAGRAM

•          Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek.

•          Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

•          Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

•          Class memiliki tiga area pokok :

–        1. Nama (dan stereotype)

–        2. Atribut

–        3. Metoda

•          Atribut dan metoda dapat memiliki salah satu sifat berikut :

–        Private, tidak dapat dipanggil dari luar class yang bersangkutan

–        Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya

Public, dapat dipanggil oleh siapa saja

HUBUNGAN ANTAR CLASS

. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.

2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).

3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.

4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.