Rabu, 12 September 2012
handout rekayasa perangkat lunak
PENDAHULUAN
Perangkat Lunak
Merupakan program-program komputer dan dokumentasi yang berkaitan, Produk perangkat lunak dibuat untuk pelanggan tertentu ataupun untuk pasar umum Produk perangkat lunak tersebut:
• Generik – dibuat untuk dijual ke suatu kumpulan pengguna yang berbeda
• Bespoke (custom) – dibuat untuk suatu pengguna tunggal sesuai dengan spesifikasinya.
Rekayasa Perangkat Lunak:
• Adalah suatu disiplin rekayasa yang berkonsentrasi terhadap seluruh aspek produksi perangkat lunak.
• Mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya dan menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang akan dipecahkan, kendala pengembangan dan sumber daya yang tersedia
Proses Perangkat Lunak
Sekumpulan aktifitas yang memiliki tujuan untuk pengembangan ataupun evolusi perangkat lunak.
Aktifitas generic dalam semua proses perangkat lunak adalah:
• Spesifikasi – apa yang harus dilakukan oleh perangkat lunak dan batasan/kendala pengembangannya
• Pengembangan – proses memproduksi sistem perangkat lunak
• Validasi – pengujian perangkat lunak terhadap keinginan penggunak
• Evolusi – perubahan perangkat lunak berdasarkan perubahan keinginan.
Model Proses Perangkat Lunak
Suatu representasi proses perangkat lunak yang disederhanakan, dipresentasikan dar perspektif khusus
Contoh perspektif proses:
• Perspektif Alur-kerja (workflow) - barisan kegiatan
• Perspektif Alur Data (Data flow) – alur informasi
• Perspektif Peran/Aksi – siapa melakukan apa.
Model proses Generik:
• Waterfall (Air terjun)
• Pengembangan secara evolusi
• Transformasi formal
• Model SPiral
• Integrasi daru komponen yang reusable
Biaya rekayasa perangkat lunak
• Sekitar 60% untuk biaya pengembangan, 40% biaya pengujian. Untuk perangkat lunak berbasis pengguna (custom), biaya evolusi biasanya melebihi biaya pengembangan.
• Biaya beragam tergantung pada tipe sistem yang akan dikembangkan dan kebutuhan sistem seperti unjuk kerja dan kehandalan sistem,
• Distribusi biaya bergantung pada model pengembangan yang digunakan.
Metode Rekayasa Perangkat Lunak
Pendekatan terstruktur pengembangan PL termasuk model sistem, notasi, perancangan dan petunjuk pemrosesan,
Deskripsi Model: deskripsi pemodelan dengan grafik,
Aturan: Batasan yang digunakan pada model sistem
Rekomendasi: nasihat bentuk perancangan yang baik,
Petunjuk proses: Aktifitas yang harus diikuti,
Atribut Perangkat Lunak yang baik:
PL seharusnya memberikan pengguna kebutuhan fungsionalitas dan unjuk kerja yang dapat di rawat, berguna,
Maintanability (Dapat Dirawat)
PL harus dapat memenuhi perubahan kebutuhan
Dependability
PL harus dapat dipercaya
Efisiensi
PL harus efisien dalam penggunaan resource
Usability
PL harus dapat digunakan sesuai dengan yang direncanakan
Proses Perangkat Lunak
Suatu proses model adalah suatu representasi abstrak suatu model. Proses model menampilkan suatu deskripsi suatu proses dari beberapa perspektif tertentu,
Proses PL merupakan aktifitas yang saling terkait (koheren) untuk menspesifikasikan, merancang, implementasi dan pengujian sistem perangkat lunak.
Model Proses PL yang Generic
• Model Air terjun (Water fall)
o Memisahkan dan membedakan antara spesifikasi dan pengembangan
• Pengembangan yang berevolusi
o Spesifikasi dan pengembangan saling bergantian
• Pengembangan sistem Formal
o Menggunakan suatu model sistem matematika yang ditransformasikan ke implementasi,
• Pengembangan berbasis Re-use (penggunaan ulang)
Sistem dibangun dari komponen yang sudah ada.
Model Air Terjun (Water Fall)
Fase Model Air Terjun
1. Analisis Kebutuhan dan pendefinisiannya
2. Perancangan sistem dan Perangkat Lunak
3. Implementasi dan unit testing
4. Integrasi dan pengujian sistem
5. Pengoperasian dan perawatan
Proses kembali ke state sebelumnya untuk mengantisipasi perubahan setelah proses menuju ke suatu state di bawahnya adalah sangat sulit.
Masalah pada Model Air Terjun:
• Partisi projek ke stages yang berbeda tidak fleksibel.
• Hali ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna
• Oleh sebab itu model ini hanya cocok digunakan apabila kebutuhan pengguna sudah dimengerti dengan baik,
Pengembangan yang berevolusi (Evolutionary Development)
Pengembangan yang berdasarkan penyidikan
Tujuannya untuk mengaktifkan pengguna dan memperolah model final berasal dari initial spesifikasi awal. Seharusnya diawali dengan kebutuhan yang sudah dimengerti,
Throw-away prototyping
Tujuannya adalah untuk memahami kebutuhan sistem. Biasanya diawali dengan pemahaman kebutuhan yang minim.
Permasalahan dalam model pengembangan yang berevolusi:
• Kekurangan visibilitas proses
• Model sistem biasanya tidak terstruktur
• Membutuhkan kemampuan khusus (mis.: bahasa pemrograman untuk rapid prototyping).
Pemakaian model pengembangan yang berevolusi
• Untuk sistem interaktif yang kecil atau menengah
• Untuk salah satu bagian dari sistem yang besar (mis. User Interface)
• Untuk sistem yang digunakan tidak terlalu lama (short lifetime).
Pendekatan pengembangan sistem Formal
Berbasiskan pada transformasi spesifikasi secara matematik melalui representasi yang berbeda untuk suatu program yang dapat dieksekusi,
Trasformasi menyatakan spesifikasi program
Menggunakan pendekatan ‘Cleanroom’ untuk pengembangan PL.
Pengembangan menggunakan konsep Re-use (Penggunaan Ulang)
Proses dengan metode Iterasi
Model Iterasi dapat digunakan pada setiap model proses generic
Terdapat dua pendekatan:
• Pengembangan Incremental
• Model Spiral
Model Pengembangan Incremental
Pengembangan sistem berdasarkan model sistem yang dipecah sehingga model pengembangannya secara increament/bertahap
Kebutuhan pengguna diprioritaskan dan priritas tertinggi dimasukkan dalam awal increment
Setelah pengembangan suatu increment dimulai, kebutuhan dibekukan dulu hingga increment berikutnya dimulai
Keuntungan
Nilai penggunan dapat ditentukan pada setiap increament sehingga fungsionalitas sistem disediakan lebih awal,
Increment awal berupa prototype untuk membantu memahami kebutuhan pada increment berikutnya,
Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem,
Prioritas tertinggi pd pelayanan sistem adalah yang paling diuji.
Model Pengembangan Spiral
Proses direpresentasikan sebagai model spiral (bukan berupa barisan aktfitas yang dapat ditrack mundur)
Setiap loop dalam model spiral menyatakan fase proses,
Tidak terdapat fase tertentu seperti spesifikasi atau perancangan, tetapi loop dalam spiral ditentukan pada apa yang dibutuhkan,
Sektor pada model Spiral
Menentukan Tujuan ;
Mengidentifikasikan spesifikasi tujuan setiap fase
Menilai Resiko dan Pengurangannya ;
Resiko dinial dan aktifitas ditempatkan untuk mengurangi resiko kunci
Pengembangan dan validasi ;
Suatu model pengembangan sistem dipilih dari model generic
Perencanaan ;
Project di review dan fase spiral berikutnya direncanakan
Spesifikasi Perangkat Lunak
Proses untuk menentukan pelayanan (servis) apa yang dibutuhkan dan kendala-kendala pengoperasian sistem serta pengembangannya,
Proses Rekayasa Kebutuhan
• Studi Kelayakan
• Analisis kebutuhan
• Spesifikasi Kebutuhan
• Validasi spesifikasi
Proses Rekayasa Kebutuhan
Perancangan dan Implementasi Perangkat Lunak
Proses konversi sistem spesifikasi ke sistem yang dapat dieksekusi langsung
Perancangan Perangkat Lunak
Perancangan Struktur Perangkat Lunak
Implementasi
Translasi struktur ke dalam bentuk program
Aktifitas perancangan dan implementasi berhubungan dekat dan dapat saling berinteraksi
Aktifitas dalam Perancangan:
• Perancangan Arsitektur
• Spesifikasi Abstrak
• Perancangan Interface
• Perancangan Komponen
• Perancangan Struktur Data
• Perancangan Algoritma
Proses Perancangan Perangkat Lunak
Metode Perancangan
• Pendekatan sistematis untuk merancang perangkat lunak
• Perancangan biasanya didokumentasikan dengan model grafik
• Beberapa model yang dapat digunakan:
o Data Flow Model
o Model relasi atribut entitas
o Model terstruktur
o Model Object
Pemrograman dan Debug
• Translasi perancangan ke dalam pemrograman dan menghilangkan error dari program
• Pemrograman adalah aktifitas personal – tidak terdapat model program generic
• Pemrogram melakukan beberapa program testing untuk menemukan fault dalam program dan menghilangkan fault tersebut dalam proses debug.
Validasi Perangkat Lunak
• Verifikasi dan validasi bertujuan menunjukkan bahwa sistem sesuai dengan spesifikasinya dan yang diinginkan pengguna
• Melibatkan proses pengujian dan review sistem
• Pengujian sistem melibatkan eksekusi sistem dengan menggunakan kasus tes yang ditentukan dari spesifikasi data real yang akan diproses oleh sistem.
Stage Pengujian Perangkat Lunak
• Unit Testing: Pengujian Komponen-komponen secara individu
• Modul Testing: Pengujian terhadap komponen yang saling berhubungan,
• Sub-system Testing: Pengujian terhadap module-module sistem yang saling berhubungan. Fokus pada pengujian interface.
• System Testing: Pengujian keseluruhan sistem,
• Acceptance Testing: Pengujian yang dilakukan oleh pengguna untuk melihat apakah sistem sudah dapat diterima.
Evolusi Sistem
Perangkat lunak pada dasarnya sangat fleksibel dan mudah berubah
Karena adanya perubahan kebutuhan melalui perubahan proses bisnis dan teknologi, maka perangkat lunak yang mendukung kegiatan bisnis tersebut juga mengalamai perubahan
Walaupun demikian diharapkan perubahan proses bisnis tersebut berdampak pada perubahan yang sedikit terhadap perangkat lunak (re-engineering).
Klasifikasi Tool
Analisis Kebutuhan
Merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan.
Terdiri dari lima langkah pokok:
1. Identifikasi Masalah
2. Evaluasi dan sintesis
3. Pemodelan
4. Spesifikasi
5. Review
Dalam menemukan Area permasalahan, perlu adanya komunikasi yang intensif dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi.
Pertanyaan pertama memfokuskan pada pengertian dasar permasalahan:
1. Menemukan yang membutuhkan software tersebut:
a. Siapa yang membutuhkan sistem (serta personal di belakangnya) ?
b. Siapa yang akan menggunakan solusi
c. Apa yang akan menjadi keuntungan ekonomis dari solusi yang baik
d. Adakan sumber lain dari solusi yang dibutuhkan
2. Bentuk solusi yang diinginkan
a. Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan dihasilkan oleh solusi yang benar
b. Masalah-masalah apa yang akan dicarikan solusinya?
c. Lingkungan solusi yang akan digunakan
d. Adakah isu atau kendala khusus yang berdampak kepada solusi
3. Efektifitas
a. Mendapatkan person yang benar/berhak atas jawaban pertanyaan,
b. Apakah pertanyaan yang diajukan relevan dengan permasalahan
c. Adakah personal lain yang dapat menambah informasi
d. Adakah hal lain yang perlu ditambahkan?
Jenis Kebutuhan:
1. Kebutuhan Fungsional
Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem dilihat dari kacamata pengguna)
2. Kebutuhan Non-Fungsional
Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O, representasi sistem dll.
Domain Kebutuhan
Kebutuhan yang berasal dari domain aplikasi sistem dan merefleksikan karakteristik domain
Secara Prinsip, spesifikasi Kebutuhan harus:
1. Lengkap: Mendeskripsikan semua fasilitas yang diinginkan
2. Konsisten: Tidak adanya konflik dan kontradiksi
Tipe Non-Fungsional
Proses Rekayasa Kebutuhan
Studi Kelayakan
Studi Kelayakan memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek permasalahan
Melakukan studi untuk menguji apakah sistem:
• sudah sesuai dengan tujuan organisasi
• dapat dikembangkan dengan teknologi terkini dan dana yang tersedia
• dapat diintegrasikan dengan sistem lain yang sudah digunakan
Implementasi Studi Kelayakan
Berbasikan pada penilaian informasi (apa yg dibutuhkan), pengumpulan informasi dan penulisan laporan
Pertanyaan ke personal di organisasi:
• Apa yang akan terjadi apabila sistem tidak diimplementasikan?
• Masalah proses apa yang ada ?
• Apa yang dapat dibantu oleh sistem ?
• Masalah apa yang akan muncul pada proses Integrasi ?
• Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ?
• Fasilitas apa yang harus didukung oleh sistem ?
Permasalahan pada Analisis Kebutuhan
• Pengguna (stakeholders) tidak mengetahui apa yang mereka butuhkan
• Pengguna menjelaskan kebutuhan dengan cara mereka sendiri sehingga sulit untuk dipahami
• Pengguna yang berbeda memiliki konflik kebutuhan
• Faktor politik dan organisasi yang dapat mempengaruhi kebutuhan sistem
• Perubahan kebutuhan selama proses analisis. Stakeholder baru mungkin akan merubah lingkungan bisnis.
Proses Analisis Kebutuhan
Pemodelan Sistem
Dapat dilakukan dalam beberapa cara, seperti model structural, state machine, state chart, dll
Pemodelan tersebut dapat pula direpresentasikan sebagai formaliasi sudut pandang pengguna (viewpoint-oriented)
Viewpoint-oriented elicitation
Stakeholder merepresentatikan sudut pandang suatu masalah dalam beberapa cara.
Analisis Multi perspektif adalah penting jika tidak terdapat suatu cara yang benar untuk menganalisa kebutuhan sistem.
Contoh: Sistem ATM Bank
Sistem ATM dapat menyediakan pelayanan bank secara otomatis
Pelayanan tersebut mencakup: penarikan tunai, pengiriman pesan untuk permintaan layanan, pemensanan, dan transfer.
Autoteller viewpoint
• Bank customers
• Representatives of other banks
• Hardware and software maintenance engineers
• Marketing department
• Bank managers and counter staff
• Database administrators and security staff
• Communications engineers
• Personnel department
Identifikasi Viewpoint:
• Menemukan viewpoint sebagai penerima layanan sistem dan mengidentifikasikan layanan yang disediakan untuk masing-masing viewpoint
Pembentukan Struktur Viewpoint
• Mengelompokkan viewpoint yang saling berhubungan secara hierarki. Layanan umum disediakan pada level yang lebih tinggi dalam hierarki
Dokumentasi Viewpoint
• Memperbaiki deskripsi viewpoint dan layanan yang teridentifikasi
Viewpoint system mapping
• Transformasi analisis ke perancangan berorientasi objek
Viewpoint Service Information
Bentuk Standard VORD
Viewpoint templete service templete
Skenario
Penggambaran bagaiman sistem akan digunakan Membantu dalam menemukan kebutuhan dengan mempermudah dalam penggambaran proses dibandingkan pernyataan abstrak kebutuhan sistem
Menambahkan detail ke outline deskripsi kebutuhan
Deskripsi dalam Skenarion
• Sistem State pada awal scenario
• Alur Normal kejadian-kejadian di sistem
• Apa yang dapat berkembang dan bagaimana menanganinya
• Aktifitas-aktifitas yang bersamaan terjadi
• System state setelah proses selesai
Skenario Kejadian
• Skenario kejadian dapat digunakan untuk menggambarkan bagaimana sistem merespon ke suatu kejadian tertentu seperti awal transaksi
• VORD dapat berupa diagram untuk menggambarkan scenario kejadian
o Data yang dikirim dan disediakan
o Kontrol Informasi
o Pengecualiaan Proses
o Kejadian berikutnya
Notasi:
Elips menyatakan data yang disediakan oleh dan dikirim ke viewpoint
Data keluar dari sisi kanan setiap kotak
Eksepsi ditunjukkan di bawah maisng-masing box
Nama kejadian berikutnya berada di box dengan garis panah tebal
Pada contoh di atas, eksepsi adalah:
• Timeout: Pelanggan salah memasukkan nomor PIN selama waktu yang diberikan
• Invalid Card: Kartu tidak diknal oleh sistem dan dikembalikan
• Stolen Card: Kartu sudah diregister sebagai kartu yang sudah dicuri/hilang dan akan diambil oleh sistem (tidak dikembalikan)
Validasi Kebutuhan
• Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai dengan yang diinginkan pengguna
• Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan penambahan biaya yang besar
o Memperbaiki definisi kebutuhan stelah software dikirim akan menyebabkan peningkatan biaya hingga 100 kali.
Pengujian Pendefinisian Kebutuhan
• Validasi. Apakah sudah sesuai dengan yang diinginkan
• Konsistensi. Adakah konflik dengan kebutuhan lainnya
• Lengkap: Apakah sudah termasuk semua fungsi yang dibutuhkan
• Realisasi: Dapatkan kebutuhan diimplementasikan ke dana dan teknologi yang tersedia
• Dapat diverifikasi: Dapatkah spesifikasi kebutuhan dicek
Teknik Validasi Kebutuhan
Review:
Prototyping
Test-Case Generator
Analisis Konsistensi Otomatis
Managemen Perubahan Kebutuhan
Outline Spesifikasi Kebutuhan Software
1. Pendahuluan
a. Referensi Sistem
b. Deskripsi Umum Sistem
c. Kendala Projek Pengembangan Software
2. Deskripsi Informasi
a. Informasi representasi Alur
i. Alur Data
ii. Alur Kontrol
b. Representasi Isi Informasi
c. Deskripsi Interface Sistem
3. Deskripsi Fungsional
a. Partisi Fungsional
b. Deskripsi Fungsional
i. Deskripsi proses secara naratif
ii. Keterbatasan Sistem
iii. Performa yang dibutuhkan
iv. Perancangan kendala
v. Support diagram
c. Deskripsi Kontrol
i. Spesifikasi Kontrol
ii. Perancangan Kendala
4. Deskripsi Lingkungan
a. System State
b. Events dan Aksi
5. Kriteria Validasi
a. Performance Bound
b. Kelas Test
c. Respon Software yang diharapkan
d. Pertimbangan-pertimbangan khusus
6. Daftar Kepustakaan
7. Appendiks
Manajemen Projek Pengembangan Software
Manajemen Projek Software:
• Memfokuskan pada aktifitas pengembangan software sesuai dengan jadwal penyelesaian dan organisasi pengembangan software
• Manajemen projek dibutuhkan karena pengembangan software memiliki kendala pada biaya dan jadwal yang ditentukan oleh pengembang.
Aktifitas dalam Manajemen
• Pembuatan Proposal
• Perencanaan dan penjadwalan Projek
• Pembuatan rencana biaya projek
• Monitoring dan review projek
• Pemilihan dan evaluasi projek
• Pembuatan Laporan dan presentasi
Penguatan Project
• Penentuan Personal dalam Projek
o Dana projek terbatas untuk pembiayan staff yang tinggi
o Dimungkinkan tidak tersedianya staff yang memiliki kemampuan sesuai dengan yang diinginkan
o Pengembangan kemampuan(skill) pegawai pada projek software
• Menuntut kemampuan manager dalam menentukan staff sesuai dengan standar tenaga IT internasional
Perencanaan Projek
• Merupakan aktifitas manajemen projek yang membutuhkan waktu paling lama
• Merupakan aktifitas berkelanjutan dari tahap initial hingga pengiriman software sehingga secara regular harus diperbaharui ketika terdapat informasi baru,
• Beberapa tipe perencanaan (rencana validasi, rencana perubahan managemen, rencana pengembangan dan training staff, rencana perawatan) harus pula dikembangkan untuk mendukung perencanaan projek utama yang memiliki kendala terhadap waktu dan biaya
Jenis-jenis Perencanaan
Jenis Deskripsi
Perencanaan Kualitas Menentukan standar dan prosedur penentuan kualitas software yang digunakan
Perencanaan Validasi Menentukan teknik, jadwal, dan sumber daya yang digunakan untuk validasi software
Perencanaan Perubahan Manajemen Menggambarkan struktur dan prosedur perubahan manajemen
Perencanaan Perawatan Memprediksi kebutuhan, biaya dan usaha perawatan sistem
Perencanaan pengembangan staff Menggambarkan bagaimana perencanaan pengembangan kemampuan dan ketrampilan staff untuk menunjang projekS
Proses Manajemen Projek
Mendefinisikan kendala projek
Menentukan penilaian awal terhadap parameter projek
Menentukan projek milestone dan pengiriman
while projek belum selesai ataupun dibatalkan loop
Menyusun jadwal projek
Initiasi aktifitas sesuai dengan jadwal
delay (untuk sementara)
review perkembangan projek
revisi parameter dan estimasi projek
apply revisi ke jadwal
negosiasikan kembali kendala projek dan pengiriman
if (terdapat masalah) then
initiasi review teknis dan kemungkinan revisi
end if
end loop
Struktur perencanaan projek
1. Pendahuluan
2. Organisasi Projek
3. Analisis Resiko
4. Kebutuhan akan sumber daya hardware dan software
5. Work breakdown
6. Penjadwalan Projek
7. Mekanisme pemantauan dan pelaporan
Pengorganisasian Kegiatan Projek
• Aktifitas pada suatu pengembangan projek harus diorganisasikan untuk menghasilkan output yang terukur bagi manajemen dan penentuan progress
• Milestones merupakan titik akhir dari aktifitas proses
• Deliverable (pengiriman) merupakan hasil projek yang dikirim ke pelanggan
• Pada model proses air terjun (waterfall) boleh didefnisikan progress milestone secara langsung
Milestone dalam proses rekayasa kebutuhan
Penjadwalan Projek
• Membagi projek ke dalam bebtuk tugas dan estiamsi waktu serta sumber daya yang dibutuhkan untuk menyelesaikan tugas tsb
• Pengorganisasian tugas yang bersamaan untuk membuat jadwal yang optimum
• Meminimumkan ketergantungan tugas untuk menghindari adanya delay yg ditimbulkan oleh suatu tugas yang menunggu tugas lainnya selesai
• Ditentukan oleh intusi dan pengalaman manajer
Proses Penjadwalan Projek
Masalah dalam Penjadwalan
• Estimasi kesulitan masalah dan berakibat pada biaya pengembangan solusi menjadi cukup rumit
• Produktifitas tidak berbanding lurus dengan jumlah orang yang mengerjakan tugas
• Penambahan personal pada akhir projek menyebabkan adanya overhead komunikasi
• Segala sesuatu yang tidak diharapkan akan terjadi, sehingga membutuhkan suatu perencanaan contingency
Diagram Batang dan Jaringan Kerja
• Merupakan notasi grafis yang digunakan untuk mengilustrasikan jadwal projek
• Menyatakan suatu breakdown projek ke dalam tugas-tugas. Tugas seharusnya tidak terlalu kecil dan diestimasi waktunya selama satu atau dua minggu
• Bagan Aktifitas menyatakan ketergantungan dan jalur kritis
• Diagram batang menyatakan jadwal yang sesuai dengan waktu kalender.
Durasi dan Ketergantungan
Tugas Durasi (hari) Ketergantungan
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4(M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
Jaringan Aktifitas
Timeline Aktifitas
Alokasi Staf
Manajemen Risiko
• Manajemen risikon mengidentifikasikan risiko dan menggambarkan minimisasi dampak risiko
• Suatu risiko adalah kemungkinan munculnya dampak yang akan merugikan
o Risiko projek berdampak pada jadwal dan sumber daya
o Risiko produk berdampak pada kualitas dan unjuk kerja software yang dikembangkan
o Risiko Bisnis berdampak pada organisasi pengembang software
Risiko Software
Risiko Tipe Risiko Deskripsi
Pindahnya Staff Projek Perginya staff berpengalaman sebelum projek selesai
Perubahan Manajemen Projek Berubahnya manajemen maka berubah pula prioritas program
Hardware yang tidak tersedia Projek Harware penting tidak dapat dikirim sesuai dengan waktu yang sudah ditentukan
Perubahan Kebutuhan Projek dan Produk Munculnya perubahan kebutuhan yang lebih besar dibandingkan antisipasinya
Delay terhadap spesifikasi Projek dan Produk Spesifikasi pada interface penting tidak dapat disediakan tepat waktu
Estimasi ukuran yang rendah Projek dan Produk Estimasi ukuran sistem yang terlalu rendah
Unjuk kerja tool/sumber daya yang rendah Produk Tool (CASE) yang digunakan tidak menunjukkan performa yg baik dalam mengantisipasi masalah
Perubahan Teknologi Bisnis Adanya perubahan teknologi dalam implementasi software
Produk saingan Bisnis Produk saingan sudah dipasarkan sebelum software yang dikembangkan selesai
Proses Manajemen Risiko
• Identifikasi Risiko
o Identifikasi risiko projek, produk dan bisnis
• Analisis Risiko
o Menilai konsekuensi dan likelihood risiko
• Perencanaan Risiko
o Menggambarkan perencanaan untuk menghindari dan meminimisasi dampak risiko
• Memantau Risiko
o Memantau risiko selama projek pengembangan
Identifikasi Risiko
• Risiko Teknologi
• Risiko Personal
• Risiko Organisasi
• Estimasi Risiko
Jenis Risiko Kemungkinan Risiko
Teknologi Kecepatan Database-Engine yang digunakan tidak dapat melakukan proses transaksi sebanyak yang dinginkan,
Terdapat kerusakan pada komponen software yg digunakan sehingga tidak sesuai dengan fungsinya
Personal Tidak dimungkinkannya melakukan recruitment staff yang memiliki kemampuan sesuai dengan yang diingikan
Tidak tersedianya tempat training untuk staff yang dibutuhkan
Organisasi Organisasi direstrukturisasi sehingga manajemen yg berbeda bertanggung jawab ke projek
Masalah dalam keuangan organisasi mengakibatkan menurunkan biaya-biaya
Tools Code yang dibangkitkan oleh Tool tidak efisien
CASE tool tidak dapat diintegrasikan
Kebutuhan-kebutuhan Perubahan kebutuhan mengakibatkan perancangan ulang
Tidak pahamnya pelanggan terhadap dampak perubahan kebutuhan
Estimasi Perkiraan jumlah waktu yang diperlukan untuk menyelesaikan projek terlalu rendah
Perkiraan jumlah perbaikan kerusakan terlalu rendah
Perkiraan ukuran sistem software terlalu rendah
Analisis Risiko
• Menilai kemungkinan terjadinya risiko dan dampak risiko
• Kemungkinan risiko: sangat rendah, rendah, sedang, tinggi, dan sangat tinggi
• Dampak risiko: fatal, serius, dapat ditolerir, tidak signifikan
Risiko Kemungkinan Dampak
Masalah dalam keuangan organisasi mengakibatkan menurunkan biaya-biaya. Rendah Fatal
Tidak dimungkinkannya melakukan recruitment staff yang memiliki kemampuan sesuai dengan yang diingikan Tinggi Fatal
Staff penting sakit pada saat jalur kritis Sedang Serius
Terdapat kerusakan pada komponen software yg digunakan sehingga tidak sesuai dengan fungsinya Sedang Serius
Perubahan kebutuhan mengakibatkan perancangan ulang Sedang Serius
Organisasi direstrukturisasi sehingga manajemen yg berbeda bertanggung jawab ke projek High Serius
Kecepatan Database-Engine yang digunakan tidak dapat melakukan proses transaksi sebanyak yang dinginkan Sedang Serius
Perkiraan jumlah waktu yang diperlukan untuk menyelesaikan projek terlalu rendah Tinggi Serius
CASE tool tidak dapat diintegrasikan Tinggi Dapat ditolerir
Tidak pahamnya pelanggan terhadap dampak perubahan kebutuhan Sedang Dapat ditolerir
Tidak tersedianya tempat training untuk staff yang dibutuhkan Sedang Dapat ditolerir
Perkiraan jumlah perbaikan kerusakan terlalu rendah Sedang Dapat ditolerir
Perkiraan ukuran sistem software terlalu rendah High Dapat ditolerir
Code yang dibangkitkan oleh Tool tidak efisien Sedang Tidak Signifikan
Perencanaan Risiko
• Mempertimbangkan setiap risiko dan mengembangkan strategi untuk mengatur risiko tersebut
• Strategi penghindaran
o Kemungkinan risiko muncul dikurangi
• Strategi minimisasi
o Dampak risiko pada projek ataupun produk harus dikurangi
• Perencanaan Contigency
o Jika terjadi risiko, rencana contingency dilakukan untuk antisipasi risiko
Manajemen Strategi Risiko
Risiko Strategi
Masalah Keuangan Organisasi Membuat suatu dokumen singkat yang diajukan ke manajer senior untuk menggambarkan bahwa pentingnya projek terhadap kemajuan bisnis organisasi
Masalah Recruitment Memberitahukan ke pelanggan bahwa sulitnya memperoleh sumber daya sehingga dimungkinkan terjadinya penundaan
Staff yg sakit Mengorganisasikan pekerjaan sehingga yang menangani setiap tugas terdiri dari lebih dari satu orang ataupun bagian lainnya dapat memahmi proses bagian lain
Rusaknya komponen Mengganti komponen yg rusak dengan yg tersedia di pasaran yg sudah diketahui kehandalannya.
Perubahan Kebutuhan Mengatur informasi yang dapat ditelusuri untuk menilai dapak perubahan kebutuhan,
Restrukturisasi Organisasi Membuat suatu dokumen singkat yang diajukan ke manajer senior untuk menggambarkan bahwa pentingnya projek terhadap kemajuan bisnis organisasi
Unjuk Kerja Database Melihat kemungkinan pembelian database yang memiliki untuk kerja tinggi
Rendahnya perkiraan waktu pengembangan Menggunakan program generator ataupun pembelian komponen-komponen
Memantau Risiko
• Menilai setiap risiko yang teridentifikasi secara regular untuk memutuskan apakah kemungkinan munculnya risiko tersebut akan lebih banyak/sedikit
• Menilai apakah dampak risiko tersebut sudah berubah
• Setiap risiko harus didiskusikan pada pertemuan manajemen progress
Faktor-faktor Risiko
Tipe Risiko Indikator Potensial
Teknologi Pengiriman produk hardware/software yang terlambat karena adanya masalah teknologi
Personal Rendahnya moral staff, kurangnya team work, dan ketersediaan pekerjaan
Organisasi Gossip di organisasi, kurangnya aksi dari senior manajemen, reward & punishment
Tools Adanya komentar kerusakan CASE tool, butuhnya spesifikasi komputer yang tinggi,
Kebutuhan Complaints dr pelanggan, berubahnya kebutuhan
Estimasi Tidak adanya kesesuaian terhadap jadwal, tidak adanya laporan yang jelas terhadap kerusakan.
CASE Object Oriented Analysis and Design
Fokus pada object dimana sistem dibagi ke dalam beberapa object yang ada di dalamnya.
Function (behavior) dan data (state) yang berhubungan ke suatu object tunggal adalah self-contained atau encapsulated pada satu tempat.
Keuntungan object-oriented:
Reusability
Modularity
Maintainability
Object adalah suatu abstraksi dari sesuatu dalam suatu domain masalah, menyatakan kemampuan sistem untuk :
menyimpan informasi tentang object tsb,
berinteraksi dengan object tsb,
atau keduanya
Object adalah entitas suatu sistem software yang menyatakan kejadian (instances) dari real-world an entitas sistem
Object Class
Class adalah deskripsi dari sekumpulan object yang membagi (share) attributes, methods, relationship dan semantic yang sama;
Object class adalah template untuk object, yang dapat digunakan untuk membuat object,
Object menyatakan suatu kejadian khusus tertentu dari suatu class
Contoh:
Class Object
name: string
address: string 3
dateOfBirth: date
employeeNo: integer
socialecurityNo: string
department: string
manager: string
salary: real
status: {current, left, retired}
taxCode: integer name: John
address: M Street No.23
dateOfBirth: 02/10/65
employeeNo: 324
socialecurityNo:E342545
department: Sale
manager: Employee1
salary: 2340
status:current
taxCode: 3432
Join( )
Retire( )
ChnageDetail( ) Eployee16.join(02/05/1997)
Eployee16.retire(03/08/2005)
Eployee16.changeDetail(“X Street No. 12”)
Inheritance
Object classes dapat menurunkan atribut dan services dari object class yang lain,
Inheritance menyatakan suatu generalisasi suatu class,
Generalisasi
Library Class Hierarchy
Keuntungan Inheritance:
Merupakan mekanisme abstraksi yang dapat digunakan untuk mengklasifikasikan entitas
Merupakan mekanisme re-use pada tahap perancangan dan pemrograman
Grafik Inheritance adalah suatu bentuk gambaran tetang organisasi pada suatu domain dan sistem
Multiple Inheritance
Suatu object class dapat pula dibentuk dari turunan beberapa super-class,
Akan memberikan dampak konflik semantic dimana atribut/service dengan nama yang sama pada super-class yang berbeda memiliki semantic yang berbeda
Membentuk hierarchy yang lebih kompleks
Masalah dengan Inheritance
Object class tidak self-contain, sehingga tidak dapat diketahui tanpa referensi ke super-classnya
Perancang memiliki tendensi untuk melakukan reuse terhadap graph inheritance yang sudah dibuat sehingga dapat menimbulkan ketidak efisiensian yang signifikan
Object Agregasi
Model agregasi menunjukkan bagaimana class-class dibentuk dari class yang lainnya
Similar dengan relasi: part-of dalam model data semantic
Encapsulation
Private: attributes dan methods dienkapsulasi dalam class sehingga dapat diakses oleh clien akses tersebut -> hanya dapat diakses oleh member class tersebut.
Public: metode mendefinisikan inteface sebagai sarana mengakses class dari clint-nya.Dapat diakses oleh object manapun.
Protected: hanya dapat diakses oleh object-class turunannya
Komunikasi dalam object
Object berkomunikasi dengan object lain melalui pengiriman pesan (messages)
o Suatu pesan adalah suatu metode call dari suatu object pengirim-pesan ke suatu object penerima pesan
o Suatu pesan terdiri dari: Object referensi yang mengindikasikan penerima pesan, nama method dan parameter (argumen dari method)
Object penerima pesan disebut server ke object pengirim pesan, dan objek pengirim pesan adalah client dari server.
Object Cohesion dan Coupling
Cohesion suatu komponen adalah ukuran tentang hubungan antara komponen suatu object class. Setiap operasi menyediakan fungsi untuk mengubah, melihat, atau menggunakan atribut object sebagai layanan dasar,
Coupling adalah suatu indikasi kekuatan interkoneksi antara program units. Sistem dengan coupling yg kuat memiliki interkoneksi yang kuat sehingga setiap program unit sangat ketergantungan dengan yang lainnya (mis.: shared variables, interchange control function). Sistem dengan couple yang lemah tidak memiliki ketergantungan yang kuat antar program units.
Polymorphism
Kemampuan object yang berbeda untuk menjalankan method yang sesuai untuk merespon ke pesan yg sama
Pemilihan method yang sesuai tergantung pada class yg digunakan untuk membuat object
Contoh:
class Shape {
private String name;
public Shape(String aName) { name=aName; }
public String getName( ) { return name; }
public float calculateArea( ) { return 0.0f; }
} // End Shape class
class Circle extends Shape {
private float radius;
public Circle(String aName) { super(aName); radius = 1.0f; }
public Circle(String aName, float radius) {
super(aName); this.radius = radius;
}
public float calculateArea() { return (float)3.14f*radius*radius; }
} // End Circle class
class Square extends Shape {
private float side;
public Square(String aName) { super(aName); side = 1.0f; }
public Square(String aName, float side) {
super(aName); this.side = side;
}
public float calculateArea() { return (float) side*side; }
} // End Square classpublic class ShapeDemoClient {
public static void main(String argv[ ]) {
Shape c1 = new Circle("Circle C1");
Shape c2 = new Circle("Circle C2", 3.0f);
Shape s1 = new Square("Square S1");
Shape s2 = new Square("Square S2", 3.0f);
Shape shapeArray[ ] = {c1, s1, c2, s2};
for (int i = 0; i < shapeArray.length; i++) {
System.out.println("The area of " + shapeArray[i].getName( )
+ " is " + shapeArray[i].calculateArea( )
+ " sq. cm.");
}
} // End main
} // End ShapeDemoClient1 class
OO Analysis: mencari kebutuhan dari perpektif class dan object yang ditemukan dalam suatu vocabulary dari domain masalah. Dengan kata lain, world (system) dimodelkan dalam bentuk object dan class,
OO Design: Dekomposisi OO dan suatu notasi untuk menggambarkan model system pada tahap pengembangan. Struktur dibentuk setelah object yang berhubungan dengan system sudah didefinisikan.
OO-Analisis:
Menganalisa domain masalah
Menggambarkan proses system
Identifikasi object
Spesifikasi atribut
Mendefinisikan Operation
Inter-object Communication
Identifikasi Suatu Object
Entitas luar (mis.: system lain, alat, orang) yang menghasilkan / menggunakan informasi yang digunakan system
Benda (mis.: laporan, tampilan, surat, signal) yang merupakan bagian informasi
Peran (mis: manager, engineer, salesperson) yang dimainka oleh orang yang berinteraksi dengan system,
Tempat(mis.: ruangan) yang menyediakan konteks permasalah dan fungsi keseluruhan system,
Unit organisasi (mis.: divisi, group, team) yang relevan ke aplikasi,
Class Fitting
Object Relations
Package
Unified Modelling Language
The Unified Modeling Language (UML) is a standard language for writing software blueprints.
The UML may be used to visualize, specify, construct, and document the artifacts of a software-intensive system.
Building Blocks
Things
Relationships
Diagrams
Things:
Structural things
classes, interfaces, collaborations, use cases, active classes, components, nodes.
Behavioral things
interactions, state machines.
Grouping things
packages.
Annotational things
notes.
Class Inheritance
Class - DependenciesA change in specification of one thing may effect another thing that uses it
Class – Association
A structural relationship that specifies that objects of one thing are connected to objects of another.
Name: name of association
Role: a specific role of class in an association
Multiplicity, an association represent a structural relationship among objects: zero to one(0..1), many(0..*) or one or more (1..*)
Aggregation: a plain association between two classes represents a structural relationship “whole-a-part”Association, Multiplicity, Aggregation and Role
Structural Things – Use Case
Specifies the behavior of a system or a part of a system and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.
Use Case Diagram
One of the five diagrams (activity diag., statechart diag., sequence diag., collaboration diag.) in the UML for modeling the dynamic aspects of systems.
Central to modeling the behavior of a system, a subsystem, or a class,
Use Case Diagram
Statechart Diagram
A statechart diagram shows a state machine, consisting of states, transitions, events, and activities.
Activity DiagramAn activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system.
Sequence DiagramA sequence diagram is an interaction diagram that emphasizes the time¬ordering of messages.
Component DiagramComponent diagram shows an organization and dependencies of a group of components.
Deployment Diagram
Deployment diagram shows the configuration of run-time node processing and its components.
Langganan:
Posting Komentar (Atom)
Tidak ada komentar:
Posting Komentar