rekayasa perangkat lunak
TRANSCRIPT
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 1
BAB I
PENGEMBANGAN SISTEM INFORMASISistem Informasi
1. Suatu sistem adalah kombinasi sumber daya (entitas) untuk mengkonversi input menjadioutput (informasi).
2. Dalam setiap sistem, masing-masing bagian sistem saling berkoordinasi untukmenyelesaikan suatu tugas, pekerjaan ataupun fungsi.
3. Informasi yang dihasilkan ditujukan ke bagian dalam organisasi yang relevan.ataupunpihak yang membutuhkan informasi.
Pengembangan Sistem Informasi1. Suatu proses pengaplikasian teknologi informasi untuk suatu tujuan atau menyelesaikan
suatu masalah.2. Memilah suatu masalah yang besar dan kompleks menjadi beberapa bagian kecil yang
dapat diatur.
Beberapa Bentuk
PENDEKATAN DALAMPENGEMBANGAN SISTEM INFORMASIPendekatan Berorientasi Proses
1. Fokus pada alur, penggunaan dan transformasi data dalam suatu sistem informasi.2. Menggunakan representasi grafik seperte Data Flow Diagram dan Bagan.3. Data mengalir dari sumber ke tujuan melalui beberapa tahapan diantaranya.4. Struktur data tidak dispesifikasikan.5. Kerugian: Berkas Data bergantung pada bentuk aplikasi.
Pendekatan Berorientasi Data1. Menggambarkan bentuk organisasi data yang tidak bergantung pada aplikasi.2. Model data menggambarkan data dan hubungan bisnis antar data.3. Aturan bisnis menggambarkan bagaimana organisasi merepresentasikan dan
memproses data.
SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)Fase Utama
1. Perencanaan : (Mengapa Mengembangkan Sistem ?)2. Analisis : (Siapa, apa, kapan dan dimana sistem ?)3. Perancangan : (Bagaimana kerja sistem?)4. Implementasi : (Bagaimana Sistem Dipasang/diinstal?)
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 2
Perencanaan1. Mengidentifikasikan Nilai Bisnis.2. Analisis Kelayakan.3. Membuat Rencana Kerja.4. Mengatur Staff.5. Mengontrol dan Mengarahkan Proyek.
Analisis1. Analisis.2. Mencari informasi yang terkait dengan sistem.3. Menentukan model proses.4. Menentukan model data.
Perancangan1. Perancangan Proses secara Fisik.2. Perancangan Arsitektur Sistem.3. Perancangan Interface.4. Perancangan Basis Data dan Berkas.5. Perancangan Program.
Implementasi1. Construction.2. Instalation.
Alternatif SDLC1. Pengembangan secara Pararel2. Rapid Application Development (RAD)3. Pengembangan Bertahap4. Pengembangan secara Prototype5. Model Spiral6. Model Paket
Process Product
Planning
Analysis
Design
Implementation
Project Plan
System Proposal
SystemSpecification
New System andMaintenance Plan
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 3
RAPID APPLICATION DEVELOPMENTCASE Tool
1. Join Application Development2. Menggunakan Bahasa Pemrograman Generasi ke 4 / Visualisasi3. Manggunakan Pembangkit Code (Code Generator)
Tiga Kategori RAD Pengembangan bertahap
o Deretan Versi Prototype
o System Prototyping Throw-Away Prototyping
o Perancangan Prototipe
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 4
MEMPEROLEH INFORMASIInterviewsLima langkah dalam melakukan Interview :
1. Memilih yg akan diinterview2. Merancang pertanyaan untuk Interview3. Menyiapkan Interview4. Melaksanakan Interview5. Follow-Up Interview
Memilih Yg Akan Di Interview Berbasis pd kebutuhan Informasi Menari dari beberapa perspektif:
i. Managerii. Useriii. Idealnya, seluruh yang berhubungan dengan sistem (stakeholder)
Tipe PertanyaanTipe Pertanyaan ContohPertanyaan Closed-Ended Berapa jumlah pesanan melalui telepon?
Bagaimana cara memesan?Informasi tambahan apa yang diperlukanpada sistem yang baru?
Pertanyaan Open-Ended Bagaimana pendapat anda tentang sistemyang ada?Masalah apa yang sering dihadapi sehari-hari?Bagaimana memutuskan tipe pemasaranapa yang harus dilaksanakan?
Pertanyaan Probing Kenapa?Dapatkah Anda memberikan conoth?Dapatkah dijelaskan lebih detail lagi?
Merancang Pertanyaan InterviewInterview tidak terstruktur
Luas, mmeberikan Informasi yang masih globalInterview terstruktur
Informasi yang lebih spsesifik
Strategi Dalam Bertanya
Langkah Persiapan Interview1. Menyiapkan Perencanaan Interview Global
Menyusun/mengumpulkan pertanyaan Mengantisipasi jawaban dan follow-up
2. Konfirmasi area knowledge3. Menentukan prioritas apabila waktu tidak mencukupi
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 5
4. Menyiapkan yang diinterview Jadwal Menjelaskan alas an melakukan Interview Menjelaskan ruang lingkup diskusi
Melaksanakan Interview1. Profesional dan tidak bias2. Merekam semua Informasi3. Mengerti semua issue dan istilah-istilah4. Membedakan antara opini dan kenyataan5. Memberikan kesempatan yg ditanya untuk menyanyakan beberapa hal yg belum jelas dr
pertanyaan6. Berterima kasih atas jawaban yg telah diberikan7. Berakhir pada waktu yg tepat
Follow-up Interview1. Menyiapkan beberapa catatan hasil interview2. Menyiapkan Laporan hasil Interview3. Memperhatikan kendala-kendala yg muncul ketika interview dan kemungkinan pertanyaan
baru.
JOINT APPLICATION DESIGN1. Pertama dilakukan oleh team IBM sekitar tahun 19702. Pertemuan terstruktur yang dihadiri oleh sekitar 10 – 20 peserta3. Dilaksanakan sekitar 30 – 60 menit per agenda4. Sering dilakukan break
Langkah Dalam JAD1. Memilih peserta (participant)2. Merancang pertemuan (session)3. Menyaipakan pertemuan (session)4. Pelaksanaan pertemuan (session)5. Follow-up
Key Idea JAD1. Memungkinkan adanya kerjasama yang lebih intensif antara manager, user dan
pengembang2. Dapat mengurangi informasi yang tidak sesuai/jelas hingga 50%3. Menghindari kebutuhan user yang terlalu spesifik ataupun yang tidak jelas
Setting JAD1. Mengatur tempat duduk berbentuk U-Shaped2. Menghindari gangguan-gangguan3. Whiteboard/flip chart4. Prototyping tools5. e-JAD
Pertemuan (Session) JAD1. Diselenggarakan pada 5 – 10 hari terakhir untuk periode 3 bulanan2. Menyiapkan pertanyaan sebagaimana Interview3. Menyiapkan agenda formal4. Memfasilitasi akrifitas-aktifitas
a. Menjaga pertemuan agar tetap pada pokok bahasan dan terkendalib. Membantu untuk menjelaskan istilah teknisc. Merekam input dari kelompokd. Membantu memecahkan isu-isu yang ada
5. Menindak lanjuti pertemuan berikutnya
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 6
Bentuk Ruang Pertemuan JAD
Mengatur Permasalahan Dalam JAD1. Reducing domination2. Encouraging non-contributors3. Side discussions4. Agenda merry-go-round5. Violent agreement6. Unresolved conflict7. True conflict8. Use humour
KUESIONERLangkah Dalam Menyusun Kuesioner1. Selecting participants, Using samples of the population2. Designing the questionnaire, Careful question selection3. Administering the questionnaire, Working to get good response rate4. Questionnaire follow-up, Send results to participants
Merancang Kuesioner Yang Baik Begin with non-threatening and interesting questions Group items into logically coherent sections Do not put important items at the very end of the questionnaireDo not crowd a page with
too many items Avoid abbreviations Avoid biased or suggestive items or termsNumber questions to avoid confusion Pretest the questionnaire to identify confusing questions Provide anonymity to respondents
Document Analysis Provides clues about existing “as-is” system Typical documents
o Formso Reportso Policy manuals
Look for user additions to forms Look for unused form elements
Observation1. Users/managers often don’t remember everything they do2. Checks validity of information gathered other ways3. Behaviours change when people are watched
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 7
4. Careful not to ignore periodic activitieso Weekly … Monthly … Annual
Criteria for Selecting the Appropriate Techniques Type of information Depth of information Breadth of information Integration of information User involvement Cost Combining techniques
Tabel Perbandingan Setiap TeknikInterview JAD Questionnaire Document
AnalysisObservation
TipeInformasi
As-IsImproveTo-Be
As-IsImproveTo-Be
As-IsImproveTo-Be
As-Is As-Is
KedalamanInformasi
High High Medium Low Low
LuasnyaInformasi
Low Medium High High Low
IntegrasiInformasi
Low High Low Low Low
KeterlibatanUser
Medium High Low Low Low
Biaya Mediu Low -Medium
Low Low Low -Medium
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 8
BAB II
KARAKTERISTIK PERANGKAT LUNAK1. PL selalu berkembang dan terencana.2. PL tidak pernah usang. Sedangkan PK memiliki keausan yang tinggi, ada getaran, panas
atau debu.3. PL dibuat karena kebutuhan.
KOMPONEN PERANGKAT LUNAK1. Dibuat melalui sederetan/kumpulan perintah.2. Struktur database.3. Rancangan/disain perangkat lunak.
JENIS APLIKASI PERANGKAT LUNAKSystem Software
Adalah kumpulan program yang ditulis untuk menunjang membuatan program. Misal :kompiler, editor, utilitas file.
Real Time SoftwareAdalah PL yang digunakan untuk mengontrol proses input data sampai menghasilkanlaporan.
Bussines SoftwarePL yang banyak digunakan dalam dunia bisnis. Misal : SPSS, MYOB, Access, Corel,Flash.
Engineering and Scientific SoftwarePL yang digunakan dalam bidang teknik dan rekayasa. Misal : GIS, Astronomi,Vulkanologi, Arc View.
Embeded SoftwarePL yang digunakan untuk mengontrol suatu proses dam pabrik, biasanya disimpandalam ROM.
PERANGKAT LUNAKMerupakan kumpulan program dan dokumentasi yang saling berkaitan. Produk perangkat lunakdibuat untuk pelanggan tertentu ataupun untuk pasar umum. Produk perangkat lunak tersebut :
1. Generik – dibuat untuk dijual ke suatu kumpulan pengguna yang berbeda.2. Bespoke (custom) – dibuat untuk suatu pengguna tunggal sesuai dengan spesifikasinya.
REKAYASA PERANGKAT LUNAK1. Adalah suatu disiplin rekayasa yang berkonsentrasi terhadap seluruh aspek produksi
perangkat lunak.2. Mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya dan
menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yangakan dipecahkan, kendala pengembangan dan sumber daya yang tersedia.
PROSES PERANGKAT LUNAKSekumpulan aktifitas yang memiliki tujuan untuk pengembangan atau pun evolusi perangkatlunak. Aktifitas generik dalam semua proses perangkat lunak adalah : Spesifikasi : apa yang dilakukan oleh perangkat lunak dan batasan pengembangannya ?. Pengembangan : proses memproduksi sistem perangkat lunak. Validasi : pengujian perangkat lunak terhadap keinginan penggunak. Evolusi : perubahan perangkat lunak berdasarkan perubahan keinginan.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 9
MODEL PROSES PERANGKAT LUNAKSuatu representasi proses perangkat lunak yang disederhanakan, dipresentasikan dariperspektif 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 dari 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 LUNAKPendekatan terstruktur pengembangan PL termasuk :
1. Deskripsi Model : deskripsi pemodelan dengan grafik.2. Aturan : Batasan yang digunakan pada model sistem.3. Rekomendasi : nasihat bentuk perancangan yang baik.4. Petunjuk proses : Aktifitas yang harus diikuti.
ATRIBUT PERANGKAT LUNAK YANG BAIKPL seharusnya memberikan pengguna kebutuhan fungsionalitas dan unjuk kerja yang dapat dirawat, berguna.
1. Maintanability : PL harus dapat memenuhi perubahan kebutuhan.2. Dependability : PL harus dapat dipercaya.3. Efisiensi : PL harus efisien dalam penggunaan resource.4. Usability : PL harus dapat digunakan sesuai dengan yang direncanakan.
PROSES PERANGKAT LUNAKSuatu proses model adalah suatu representasi abstrak suatu model. Proses modelmenampilkan suatu deskripsi suatu proses dari beberapa perspektif tertentu. Proses PLmerupakan 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 keimplementasi,
Pengembangan berbasis Re-use (penggunaan ulang)o Sistem dibangun dari komponen yang sudah ada.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 10
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.
Masalah pada Model Air Terjun : Partisi proyek 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 di
mengerti dengan baik.
PENGEMBANGAN YANG BEREVOLUSI(EVOLUTIONARY DEVELOPMENT)Pengembangan yang berdasarkan penyidikan :
Tujuannya untuk mengaktifkan pengguna dan memperolah model final berasal dari initialspesifikasi awal. Seharusnya diawali dengan kebutuhan yang sudah dimengerti.
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integr ation andsystem testing
Operation andmaintenance
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 11
Throw-away prototyping :Tujuannya adalah untuk memahami kebutuhan sistem. Biasanya diawali denganpemahaman kebutuhan yang minim.
Permasalahan dalam model pengembangan yang berevolusi : Kekurangan visibilitas proses. Model sistem biasanya tidak terstruktur. Membutuhkan kemampuan khusus (misal : 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 (misal User Interface). Untuk sistem yang digunakan tidak terlalu lama (short lifetime).
PENDEKATAN PENGEMBANGAN SISTEM FORMALBerbasiskan pada transformasi spesifikasi secara matematik melalui representasi yang berbedauntuk suatu program yang dapat dieksekusi. Trasformasi menyatakan spesifikasi program.Menggunakan pendekatan ‘Cleanroom’ untuk pengembangan PL.
PENGEMBANGAN MENGGUNAKANKONSEP RE-USE (PENGGUNAAN ULANG)
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 12
PROSES DENGAN METODE ITERASIMetode Iterasi dapat digunakan pada setiap model proses generik. Terdapat dua pendekatan:
Pengembangan Incremental Model Spiral
Model Pengembangan Incremental1. Pengembangan sistem berdasarkan model sistem yang dipecah sehingga model
pengembangannya secara increament/bertahap.2. Kebutuhan pengguna diprioritaskan dan priritas tertinggi dimasukkan dalam awal
increment.3. Setelah pengembangan suatu increment dimulai, kebutuhan dibekukan dulu hingga
increment berikutnya dimulai.
Keuntungan :1. Nilai penggunan dapat ditentukan pada setiap increament sehingga fungsionalitas sistem
disediakan lebih awal.2. Increment awal berupa prototype untuk membantu memahami kebutuhan pada
increment berikutnya.3. Memiliki resiko lebih rendah terhadap keseluruhan pengembagan sistem.4. Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji.
MODEL PENGEMBANGAN SPIRALProses direpresentasikan sebagai model spiral (bukan berupa barisan aktfitas yang dapat ditrack mundur). Setiap loop dalam model spiral menyatakan fase proses. Tidak terdapat fasetertentu seperti spesifikasi atau perancangan, tetapi loop dalam spiral ditentukan pada apa yangdibutuhkan.
Sektor pada Model Spiral1. Menentukan Tujuan, Mengidentifikasikan spesifikasi tujuan setiap fase.2. Menilai Resiko dan Pengurangannya, Resiko dinial dan aktifitas ditempatkan untuk
mengurangi resiko kunci.3. Pengembangan dan validasi, Suatu model pengembangan sistem dipilih dari model
generik.4. Perencanaan, Project di review dan fase spiral berikutnya direncanakan.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 13
SPESIFIKASI PERANGKAT LUNAKProses untuk menentukan pelayanan (servis) apa yang dibutuhkan dan kendala-kendalapengoperasian sistem serta pengembangannya.
Proses Rekayasa Kebutuhan Studi Kelayakan Analisis kebutuhan Spesifikasi Kebutuhan Validasi spesifikasi
Perancangan dan Implementasi Perangkat Lunak1. Proses konversi sistem spesifikasi ke sistem yang dapat dieksekusi langsung.2. Perancangan Perangkat Lunak.3. Perancangan Struktur Perangkat Lunak.4. Implementasi.5. Translasi struktur ke dalam bentuk program.6. 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
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 14
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 Modelo Model relasi atribut entitaso Model terstrukturo Model Object
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 mengalamaiperubahan.
Walaupun demikian diharapkan perubahan proses bisnis tersebut berdampak padaperubahan yang sedikit terhadap perangkat lunak (re-engineering).
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 15
BAB III
ANALISIS KEBUTUHANMerupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan. Terdiri darilima langkah pokok :
1. Identifikasi Masalah2. Evaluasi dan sintesis3. Pemodelan4. Spesifikasi5. Review
Dalam menemukan Area permasalahan, perlu adanya komunikasi yang intensif dengan user.Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi
PERTANYAAN FOKUS PADA DASAR PERMASALAHAN1. Menemukan yang membutuhkan software tersebut:
a. Siapa yang membutuhkan sistem (serta personal di belakangnya) ?b. Siapa yang akan menggunakan solusic. Apa yang akan menjadi keuntungan ekonomis dari solusi yang baikd. Adakan sumber lain dari solusi yang dibutuhkan
2. Bentuk solusi yang diinginkana. Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan
dihasilkan oleh solusi yang benarb. Masalah-masalah apa yang akan dicarikan solusinya?c. Lingkungan solusi yang akan digunakand. Adakah isu atau kendala khusus yang berdampak kepada solusi
3. Efektifitasa. Mendapatkan person yang benar/berhak atas jawaban pertanyaan,b. Apakah pertanyaan yang diajukan relevan dengan permasalahanc. Adakah personal lain yang dapat menambah informasid. Adakah hal lain yang perlu ditambahkan?
JENIS KEBUTUHAN1. Kebutuhan Fungsional
Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadapinput dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistemdilihat dari kacamata pengguna)
2. Kebutuhan Non-FungsionalKendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala prosespengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhanstorage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O,representasi sistem dll.
Domain KebutuhanKebutuhan 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.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 16
Tipe Non-Fungsional
PROSES REKAYASA KEBUTUHAN
STUDI KELAYAKANStudi Kelayakan memutuskan apakah sistem software yang akan dibuat sudahmencakup 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 KelayakanBerbasiskan pada penilaian informasi (apa yg dibutuhkan), pengumpulan informasi danpenulisan 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 ?
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 17
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 SISTEMDapat dilakukan dalam beberapa cara, seperti model structural, state machine, state chart danlain-lain. Pemodelan tersebut dapat pula direpresentasikan sebagai formaliasi sudut pandangpengguna (viewpoint-oriented).
Viewpoint-Oriented ElicitationStakeholder merepresentatikan sudut pandang suatu masalah dalam beberapa cara. AnalisisMulti perspektif adalah penting jika tidak terdapat suatu cara yang benar untuk menganalisakebutuhan sistem.
Contoh : Sistem ATM BankSistem ATM dapat menyediakan pelayanan bank secara otomatis. Pelayanan tersebutmencakup: penarikan tunai, pengiriman pesan untuk permintaan layanan, pemensanan, dantransfer.
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
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 18
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.
V i e w p o i n ti d e n t if i c a t io n
V i e w p o i n ts t r u c t u r i n g
V i ew p o i n td o c um e n ta t io n
V i e w p o i n ts y s te m m a p p i n g
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 19
Viewpoint Service Information
Bentuk Standard VORD
Viewpoint Templete Service Templete
SkenarioPenggambaran bagaimana sistem akan digunakan membantu dalam menemukan kebutuhandengan mempermudah dalam penggambaran proses dibandingkan pernyataan abstrakkebutuhan sistem. Menambahkan detail ke outline deskripsi kebutuhan.
Deskripsi dalam Skenario 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.
F O RE IG NC U S TO M ER
W i th draw c a shQ u e ry ba la nc e
S e rv i ce l is t
W i th draw c a shQ u e ry ba l a nc eO r d er c he q ue sS e n d m e s sa g eT ra ns a c ti on l is tO r d er st at em e n tT ra ns f e r fu nd s
S e rv i c e l is t
R u n d ia g no st ic sA d d c a shA d d pa p erS e n d m e s sa g e
S e rv i c e l is t
A C C O UN THO LD ER
B AN KTE LL ER
Cu st om er
Acco un t nu m berP INS t art t ran sac ti onS e l ec t s e rvi ceC ance lt ran sac ti onEn d tran sac ti on
C as h w it hd rawalB a lan ce en qu iry
Acco un t ho ld e rForei gncus to m er
Referen ce:
Attr i bu tes:
E ven ts:
S ervi ces:
Sub -V Ps :
C as h w it hd rawal
To im p rove cu st om er s e rvi ceand redu ce p ap erw o rk
Us ers cho os e th is s e rvi ce byp res si ng t he cas h wi th draw alb ut to n. They t hen ent e r t heam ou nt req ui red. Th is iscon firm ed an d, if fu nd s a ll ow ,t he b a lan ce is d e li ve red .
C u st om er
Del iv e r cas h w it hi n 1 m i nu teo f am ou nt be i ng co nfi rm ed
Fi ll ed in la ter
Referen ce:
Ra tio na le :
Sp ec i fi cati on :
VP s:
No n -fun ct.requ i remen ts :
Prov id er:
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 20
Notasi :1. Elips menyatakan data yang disediakan oleh dan dikirim ke viewpoint.2. Data keluar dari sisi kanan setiap kotak.3. Eksepsi ditunjukkan di bawah maisng-masing box.4. 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 besaro 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 Review1. Prototyping2. Test-Case Generator3. Analisis Konsistensi Otomatis
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 21
MANAJEMEN PERUBAHAN KEBUTUHAN
Outline Spesifikasi Kebutuhan Software1. Pendahuluan
a. Referensi Sistemb. Deskripsi Umum Sistemc. Kendala Proyek Pengembangan Software
2. Deskripsi Informasia. Informasi representasi Alur
i. Alur Dataii. Alur Kontrol
b. Representasi Isi Informasic. Deskripsi Interface Sistem
3. Deskripsi Fungsionala. Partisi Fungsionalb. Deskripsi Fungsional
i. Deskripsi proses secara naratifii. Keterbatasan Sistemiii. Performa yang dibutuhkaniv. Perancangan kendalav. Support diagram
c. Deskripsi Kontroli. Spesifikasi Kontrolii. Perancangan Kendala
4. Deskripsi Lingkungana. System Stateb. Events dan Aksi
5. Kriteria Validasia. Performance Boundb. Kelas Testc. Respon Software yang diharapkand. Pertimbangan-pertimbangan khusus
6. Daftar Kepustakaan7. Appendiks
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 22
BAB IV
MANAJEMEN PROYEK PENGEMBANGAN SOFTWARE Memfokuskan pada aktifitas pengembangan software sesuai dengan jadwal
penyelesaian dan organisasi pengembangan software. Manajemen proyek dibutuhkan karena pengembangan software memiliki kendala pada
biaya dan jadwal yang ditentukan oleh pengembang.
AKTIFITAS DALAM MANAJEMEN Pembuatan Proposal. Perencanaan dan penjadwalan Proyek. Pembuatan rencana biaya proyek. Monitoring dan review proyek. Pemilihan dan evaluasi proyek. Pembuatan Laporan dan presentasi.
PENGUATAN PROYEK Penentuan Personal dalam Proyek
o Dana proyek terbatas untuk pembiayan staff yang tinggio Dimungkinkan tidak tersedianya staff yang memiliki kemampuan sesuai dengan
yang diinginkano Pengembangan kemampuan(skill) pegawai pada proyek software
Menuntut kemampuan manager dalam menentukan staff sesuai dengan standar tenagaIT internasional
PERENCANAAN PROYEK Merupakan aktifitas manajemen proyek 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 untukmendukung perencanaan proyek utama yang memiliki kendala terhadap waktu danbiaya
JENIS-JENIS PERENCANAANJenis Deskripsi
Perencanaan Kualitas Menentukan standar dan prosedur penentuankualitas software yang digunakan
Perencanaan Validasi Menentukan teknik, jadwal, dan sumber daya yangdigunakan untuk validasi software
Perencanaan PerubahanManajemen
Menggambarkan struktur dan prosedur perubahanmanajemen
Perencanaan Perawatan Memprediksi kebutuhan, biaya dan usaha perawatansistem
Perencanaan pengembangan staff Menggambarkan bagaimana perencanaanpengembangan kemampuan dan ketrampilan staffuntuk menunjang proyekS
PROSES MANAJEMEN PROYEKMendefinisikan kendala proyekMenentukan penilaian awal terhadap parameter proyekMenentukan proyek milestone dan pengirimanwhile proyek belum selesai ataupun dibatalkan loop
Menyusun jadwal proyekInitiasi aktifitas sesuai dengan jadwal
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 23
delay (untuk sementara)review perkembangan proyekrevisi parameter dan estimasi proyekapply revisi ke jadwalnegosiasikan kembali kendala proyek dan pengiriman
if (terdapat masalah) theninitiasi review teknis dan kemungkinan revisi
end ifend loop
STRUKTUR PERENCANAAN PROYEK1. Pendahuluan2. Organisasi Proyek3. Analisis Resiko4. Kebutuhan akan sumber daya hardware dan software5. Work breakdown6. Penjadwalan Proyek7. Mekanisme pemantauan dan pelaporan
PENGORGANISASIAN KEGIATAN PROYEK1. Aktifitas pada suatu pengembangan proyek harus diorganisasikan untuk menghasilkan
output yang terukur bagi manajemen dan penentuan progress.2. Milestones merupakan titik akhir dari aktifitas proses.3. Deliverable (pengiriman) merupakan hasil proyek yang dikirim ke pelanggan.4. Pada model proses air terjun (waterfall) boleh didefnisikan progress milestone secara
langsung.
MILESTONE DALAM PROSES REKAYASA KEBUTUHAN
PENJADWALAN PROYEK Membagi proyek ke dalam bebtuk tugas dan estiamsi waktu serta sumber daya yang
dibutuhkan untuk menyelesaikan tugas tersebut. 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 Proyek
Masalah Dalam Penjadwalan1. Estimasi kesulitan masalah dan berakibat pada biaya pengembangan solusi menjadi
cukup rumit.2. Produktifitas tidak berbanding lurus dengan jumlah orang yang mengerjakan tugas.3. Penambahan personal pada akhir proyek menyebabkan overhead komunikasi.4. Segala sesuatu yang tidak diharapkan akan terjadi, sehingga membutuhkan suatu
perencanaan contingency.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 24
Diagram Batang Dan Jaringan Kerja1. Merupakan notasi grafis yang digunakan untuk mengilustrasikan jadwal proyek.2. Menyatakan suatu breakdown proyek ke dalam tugas-tugas. Tugas seharusnya tidak
terlalu kecil dan diestimasi waktunya selama satu atau dua minggu.3. Bagan Aktifitas menyatakan ketergantungan dan jalur kritis.4. Diagram batang menyatakan jadwal yang sesuai dengan waktu kalender.
Durasi Dan KetergantunganTugas Durasi (hari) Ketergantungan
T1 8T2 15T3 15 T1 (M1)T4 10T5 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
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 25
Timeline Aktifitas
Alokasi Staf
MANAJEMEN RESIKO1. Manajemen resikon mengidentifikasikan resiko dan menggambarkan minimisasi dampak
resiko.2. Suatu resiko adalah kemungkinan munculnya dampak yang akan merugikan.
o Resiko proyek berdampak pada jadwal dan sumber daya.o Resiko produk berdampak pada kualitas dan unjuk kerja software yang
dikembangkan.o Resiko Bisnis berdampak pada organisasi pengembang software.
Resiko SoftwareResiko Tipe
ResikoDeskripsi
Pindahnya Staff Proyek Perginya staff berpengalaman sebelum proyekselesai
Perubahan Manajemen Proyek Berubahnya manajemen maka berubah pulaprioritas program
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 26
Hardware yang tidaktersedia
Proyek Harware penting tidak dapat dikirim sesuai denganwaktu yang sudah ditentukan
Perubahan Kebutuhan ProyekdanProduk
Munculnya perubahan kebutuhan yang lebih besardibandingkan antisipasinya
Delay terhadapspesifikasi
ProyekdanProduk
Spesifikasi pada interface penting tidak dapatdisediakan tepat waktu
Estimasi ukuran yangrendah
ProyekdanProduk
Estimasi ukuran sistem yang terlalu rendah
Unjuk kerjatool/sumber daya yangrendah
Produk Tool (CASE) yang digunakan tidak menunjukkanperforma yg baik dalam mengantisipasi masalah
Perubahan Teknologi Bisnis Adanya perubahan teknologi dalam implementasisoftware
Produk saingan Bisnis Produk saingan sudah dipasarkan sebelum softwareyang dikembangkan selesai
Proses Manajemen Resiko1. Identifikasi Resiko, Identifikasi resiko proyek, produk dan bisnis2. Analisis Resiko, Menilai konsekuensi dan likelihood resiko3. Perencanaan Resiko, Menggambarkan perencanaan untuk menghindari dan
meminimisasi dampak resiko4. Memantau Resiko, Memantau resiko selama proyek pengembangan
Identifikasi Resiko1. Resiko Teknologi2. Resiko Personal3. Resiko Organisasi4. Estimasi Resiko
JenisResiko
Kemungkinan Resiko
Teknologi Kecepatan Database-Engine yang digunakan tidak dapat melakukan prosestransaksi sebanyak yang dinginkan,Terdapat kerusakan pada komponen software yg digunakan sehingga tidaksesuai dengan fungsinya
Personal Tidak dimungkinkannya melakukan recruitment staff yang memilikikemampuan sesuai dengan yang diingikanTidak tersedianya tempat training untuk staff yang dibutuhkan
Organisasi Organisasi direstrukturisasi sehingga manajemen yg berbeda bertanggungjawab ke proyekMasalah dalam keuangan organisasi mengakibatkan menurunkan biaya-biaya
Tools Code yang dibangkitkan oleh Tool tidak efisienCASE tool tidak dapat diintegrasikan
Kebutuhan-kebutuhan
Perubahan kebutuhan mengakibatkan perancangan ulangTidak pahamnya pelanggan terhadap dampak perubahan kebutuhan
Estimasi Perkiraan jumlah waktu yang diperlukan untuk menyelesaikan proyek terlalurendahPerkiraan jumlah perbaikan kerusakan terlalu rendahPerkiraan ukuran sistem software terlalu rendah
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 27
Analisis Resiko1. Menilai kemungkinan terjadinya resiko dan dampak resiko.2. Kemungkinan resiko: sangat rendah, rendah, sedang, tinggi, dan sangat tinggi.3. Dampak resiko: fatal, serius, dapat ditolerir, tidak signifikan.
Risiko Kemungkinan DampakMasalah dalam keuangan organisasi mengakibatkanmenurunkan biaya-biaya.
Rendah Fatal
Tidak dimungkinkannya melakukan recruitment staff yangmemiliki kemampuan sesuai dengan yang diingikan
Tinggi Fatal
Staff penting sakit pada saat jalur kritis Sedang SeriusTerdapat kerusakan pada komponen software ygdigunakan sehingga tidak sesuai dengan fungsinya
Sedang Serius
Perubahan kebutuhan mengakibatkan perancangan ulang Sedang SeriusOrganisasi direstrukturisasi sehingga manajemen ygberbeda bertanggung jawab ke projek
High Serius
Kecepatan Database-Engine yang digunakan tidak dapatmelakukan proses transaksi sebanyak yang dinginkan
Sedang Serius
Perkiraan jumlah waktu yang diperlukan untukmenyelesaikan projek terlalu rendah
Tinggi Serius
CASE tool tidak dapat diintegrasikan Tinggi Dapat ditolerirTidak pahamnya pelanggan terhadap dampak perubahankebutuhan
Sedang Dapat ditolerir
Tidak tersedianya tempat training untuk staff yangdibutuhkan
Sedang Dapat ditolerir
Perkiraan jumlah perbaikan kerusakan terlalu rendah Sedang Dapat ditolerirPerkiraan ukuran sistem software terlalu rendah High Dapat ditolerirCode yang dibangkitkan oleh Tool tidak efisien Sedang Tidak
Signifikan
Perencanaan Risiko Mempertimbangkan setiap risiko dan mengembangkan strategi untuk mengatur risiko
tersebut. Strategi penghindaran, Kemungkinan risiko muncul dikurangi. Strategi minimisasi, Dampak risiko pada projek ataupun produk harus dikurangi. Perencanaan Contigency, Jika terjadi risiko, rencana contingency dilakukan untuk
antisipasi risiko.
Manajemen Strategi RisikoRisiko Strategi
Masalah KeuanganOrganisasi
Membuat suatu dokumen singkat yang diajukan ke manajer senioruntuk menggambarkan bahwa pentingnya projek terhadapkemajuan bisnis organisasi
Masalah Recruitment Memberitahukan ke pelanggan bahwa sulitnya memperolehsumber daya sehingga dimungkinkan terjadinya penundaan
Staff yg sakit Mengorganisasikan pekerjaan sehingga yang menangani setiaptugas terdiri dari lebih dari satu orang ataupun bagian lainnyadapat memahmi proses bagian lain
Rusaknya komponen Mengganti komponen yg rusak dengan yg tersedia di pasaran ygsudah diketahui kehandalannya.
Perubahan Kebutuhan Mengatur informasi yang dapat ditelusuri untuk menilai dapakperubahan kebutuhan,
RestrukturisasiOrganisasi
Membuat suatu dokumen singkat yang diajukan ke manajer senioruntuk menggambarkan bahwa pentingnya projek terhadapkemajuan bisnis organisasi
Unjuk Kerja Database Melihat kemungkinan pembelian database yang memiliki untukkerja tinggi
Rendahnya perkiraanwaktu pengembangan
Menggunakan program generator ataupun pembelian komponen-komponen
Memantau Risiko1. Menilai setiap risiko yang teridentifikasi secara regular untuk memutuskan apakah
kemungkinan munculnya risiko tersebut akan lebih banyak/sedikit.2. Menilai apakah dampak risiko tersebut sudah berubah.3. Setiap risiko harus didiskusikan pada pertemuan manajemen progress.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 28
Faktor-faktor RisikoTipe Risiko Indikator PotensialTeknologi Pengiriman produk hardware/software yang terlambat karena adanya
masalah teknologiPersonal Rendahnya moral staff, kurangnya team work, dan ketersediaan pekerjaanOrganisasi Gossip di organisasi, kurangnya aksi dari senior manajemen, reward &
punishmentTools Adanya komentar kerusakan CASE tool, butuhnya spesifikasi komputer
yang tinggi,Kebutuhan Complaints dr pelanggan, berubahnya kebutuhanEstimasi Tidak adanya kesesuaian terhadap jadwal, tidak adanya laporan yang jelas
terhadap kerusakan.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 29
BAB V
OBJECT ORIENTED ANALYSIS AND DESIGN1. Fokus pada object dimana sistem dibagi ke dalam beberapa object yang ada di
dalamnya.2. Function (behavior) dan data (state) yang berhubungan ke suatu object tunggal adalah
self-contained atau encapsulated pada satu tempat.
Keuntungan Object-Oriented1. Reusability.2. Modularity.3. Maintainability.
Object adalah suatu abstraksi dari sesuatu dalam suatu domain masalah, menyatakankemampuan 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 dan entitas sistem.
Object ClassClass adalah deskripsi dari sekumpulan object yang membagi (share) attributes, methods,relationship dan semantic yang sama. Object class adalah template untuk object, yang dapatdigunakan untuk membuat object. Object menyatakan suatu kejadian khusus tertentu dari suatuclass.
Contoh:Class Objectname: stringaddress: string 3dateOfBirth: dateemployeeNo: integersocialecurityNo: stringdepartment: stringmanager: stringsalary: realstatus: {current, left, retired}taxCode: integer
name: Johnaddress: M Street No.23dateOfBirth: 02/10/65employeeNo: 324socialecurityNo:E342545department: Salemanager: Employee1salary: 2340status:currenttaxCode: 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,
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 30
Generalisasi
Library Class Hierarchy
Keuntungan Inheritance1. Merupakan mekanisme abstraksi yang dapat digunakan untuk mengklasifikasikan
entitas.2. Merupakan mekanisme re-use pada tahap perancangan dan pemrograman.3. Grafik Inheritance adalah suatu bentuk gambaran tetang organisasi pada suatu domain
dan sistem.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 31
Multiple Inheritance
1. Suatu object class dapat pula dibentuk dari turunan beberapa super-class.2. Akan memberikan dampak konflik semantic dimana atribut/service dengan nama yang
sama pada super-class yang berbeda memiliki semantic yang berbeda.3. 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 Agregasi1. Model agregasi menunjukkan bagaimana class-class dibentuk dari class yang lainnya2. 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.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 32
Komunikasi Dalam Object1. Object berkomunikasi dengan object lain melalui pengiriman pesan (messages)
Suatu pesan adalah suatu metode call dari suatu object pengirim-pesan ke suatu objectpenerima pesan
Suatu pesan terdiri dari: Object referensi yang mengindikasikan penerima pesan, namamethod dan parameter (argumen dari method)
2. Object penerima pesan disebut server ke object pengirim pesan, dan objek pengirim pesanadalah client dari server.
Object Cohesion Dan CouplingCohesion suatu komponen adalah ukuran tentang hubungan antara komponen suatu objectclass. Setiap operasi menyediakan fungsi untuk mengubah, melihat, atau menggunakan atributobject sebagai layanan dasar.
Coupling adalah suatu indikasi kekuatan interkoneksi antara program units. Sistem dengancoupling yg kuat memiliki interkoneksi yang kuat sehingga setiap program unit sangatketergantungan dengan yang lainnya (mis.: shared variables, interchange control function).Sistem dengan couple yang lemah tidak memiliki ketergantungan yang kuat antar program units.
Polymorphism1. Kemampuan object yang berbeda untuk menjalankan method yang sesuai untuk
merespon ke pesan yg sama.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 33
2. Pemilihan method yang sesuai tergantung pada class yg digunakan untuk membuatobject.
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 classclass 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 classclass 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 Analysismencari kebutuhan dari perpektif class dan object yang ditemukan dalam suatu vocabulary daridomain masalah. Dengan kata lain, world (system) dimodelkan dalam bentuk object dan class.
OO DesignDekomposisi OO dan suatu notasi untuk menggambarkan model system pada tahappengembangan. Struktur dibentuk setelah object yang berhubungan dengan system sudahdidefinisikan.
OO-Analisis1. Menganalisa domain masalah.2. Menggambarkan proses system.3. Identifikasi object.4. Spesifikasi atribut.5. Mendefinisikan Operation.6. Inter-object Communication.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 34
Identifikasi Suatu Object1. Entitas luar (mis.: system lain, alat, orang) yang menghasilkan / menggunakan informasi
yang digunakan system.2. Benda (mis.: laporan, tampilan, surat, signal) yang merupakan bagian informasi.3. Peran (mis: manager, engineer, salesperson) yang dimainka oleh orang yang
berinteraksi dengan system.4. Tempat(mis.: ruangan) yang menyediakan konteks permasalah dan fungsi keseluruhan
system.5. Unit organisasi (mis.: divisi, group, team) yang relevan ke aplikasi.
Class Fitting
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 35
Object Relations
Package
The Unified Modeling Language (UML) is a standard language for writing softwareblueprints.
The UML may be used to visualize, specify, construct, and document the artifacts of asoftwareintensive system.
Building Blocks1. Things2. Relationships3. Diagrams
Things : Structural things : classes, interfaces, collaborations, use cases, active classes,
components, nodes. Behavioral things : interactions, state machines. Grouping things : packages. Annotational things : notes.
Sha pe
origin
mov e()resize()display ()
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 36
Class Inheritance
Class – Dependencies A change in specification of one thing may effect another thing that usesit.
Class – AssociationA structural relationship that specifies that objects of one thing are connected to objects ofanother.
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.
Shapeorigin : Variant
move()res ize()display()
< <Cl ass Mo dul e>>
Rectanglecorner : Point
Circleradius : Double
Po lygonpoint : List
Square
FilpClipname
playOn()start()stop()reset()
Channel
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 37
Structural Things – Use CaseSpecifies the behavior of a system or a part of a system and is a description of a set ofsequences of actions, including variants, that a system performs to yield an observable result ofvalue 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.
Statechart DiagramA statechart diagram shows a state machine, consisting of states, transitions, events, andactivities.
Activity Diagram An activity diagram is a special kind of a statechart diagram that shows the flowfrom activity to activity within a system.
R e c o n c i l e T ra n sa c t i o n
C u st o m e r
P e rf o r m C a rd T r a n sa ct io n
R e t a i l I n st i t u t i o n
P ro c e ss C u st o m e r B i l l
M a n a g e C u st o m e r A c c o u n t
S p o n so ri n gF i n a n c i a l
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 38
Sequence Diagram A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages.
Component DiagramComponent diagram shows an organization and dependencies of a groupof components.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 39
DEPLOYMENT DIAGRAMDeployment diagram shows the configuration of run-time node processing and its components.
Rekayasa Perangkat Lunak/SI-TI
Oleh : Wahju Tjahjo S. 40
LAMPIRAN-LAMPIRAN
Berikut ini dilampirkan tabel-tabel yang diperlukan pada saat melakukan rekayasa perangkatlunak dari tahap survei sampai uji program. Tabel-tabel berikut biasanya digunakan dan diisiketika rekayasa berlangsung. Data yang tercantum dalam tabel hanya sebai contoh saja.
Tabel 1.
Tabel 2.
Tabel 3.