Rekayasa Perangkat Lunak (2). pdf

BAB I

PENGEMBANGAN SISTEM INFORMASI

Sistem Informasi

1. Suatu sistem adalah kombinasi sumber daya (entitas) untuk mengkonversi input menjadi output (informasi).

2. Dalam setiap sistem, masing-masing bagian sistem saling berkoordinasi untuk menyelesaikan suatu tugas, pekerjaan ataupun fungsi.

3. Informasi yang dihasilkan ditujukan ke bagian dalam organisasi yang relevan.ataupun pihak yang membutuhkan informasi.

Pengembangan Sistem Informasi

1. 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 DALAM

PENGEMBANGAN SISTEM INFORMASI

Pendekatan 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 Data

1. 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?)

Perencanaan

1. Mengidentifikasikan Nilai Bisnis. 2. Analisis Kelayakan.

3. Membuat Rencana Kerja. 4. Mengatur Staff.

5. Mengontrol dan Mengarahkan Proyek.

Analisis

1. Analisis.

2. Mencari informasi yang terkait dengan sistem. 3. Menentukan model proses.

4. Menentukan model data.

Perancangan

1. Perancangan Proses secara Fisik. 2. Perancangan Arsitektur Sistem. 3. Perancangan Interface.

RAPID APPLICATION DEVELOPMENT

CASE Tool

1. Join Application Development

2. Menggunakan Bahasa Pemrograman Generasi ke 4 / Visualisasi 3. Manggunakan Pembangkit Code (Code Generator)

Tiga Kategori RAD

 Pengembangan bertahap o Deretan Versi

 Prototype

o System Prototyping

MEMPEROLEH INFORMASI

Interviews

Lima langkah dalam melakukan Interview : 1. Memilih yg akan diinterview

2. Merancang pertanyaan untuk Interview 3. Menyiapkan Interview

4. Melaksanakan Interview 5. Follow-Up Interview

Memilih Yg Akan Di Interview

 Berbasis pd kebutuhan Informasi  Menari dari beberapa perspektif:

i. Manager ii. User

iii. Idealnya, seluruh yang berhubungan dengan sistem (stakeholder)

Tipe Pertanyaan

Tipe Pertanyaan Contoh

PertanyaanClosed-Ended Berapa jumlah pesanan melalui telepon? Bagaimana cara memesan?

Informasi tambahan apa yang diperlukan pada sistem yang baru?

PertanyaanOpen-Ended Bagaimana pendapat anda tentang sistem yang ada?

Masalah apa yang sering dihadapi sehari-hari?

Bagaimana memutuskan tipe pemasaran apa yang harus dilaksanakan?

PertanyaanProbing Kenapa?

Dapatkah Anda memberikan conoth? Dapatkah dijelaskan lebih detail lagi?

Merancang Pertanyaan Interview

Interview tidak terstruktur

 Luas, mmeberikan Informasi yang masih global Interview terstruktur

 Informasi yang lebih spsesifik

4. Menyiapkan yang diinterview

 Jadwal

 Menjelaskan alas an melakukan Interview

 Menjelaskan ruang lingkup diskusi

Melaksanakan Interview

1. Profesional dan tidak bias 2. Merekam semua Informasi

3. Mengerti semua issue dan istilah-istilah 4. Membedakan antara opini dan kenyataan

5. Memberikan kesempatan yg ditanya untuk menyanyakan beberapa hal yg belum jelas dr pertanyaan

6. Berterima kasih atas jawaban yg telah diberikan 7. Berakhir pada waktu yg tepat

Follow-up Interview

1. Menyiapkan beberapa catatan hasil interview 2. Menyiapkan Laporan hasil Interview

3. Memperhatikan kendala-kendala yg muncul ketika interview dan kemungkinan pertanyaan baru.

JOINT APPLICATION DESIGN

1. Pertama dilakukan oleh team IBM sekitar tahun 1970

2. Pertemuan terstruktur yang dihadiri oleh sekitar 10 – 20 peserta 3. Dilaksanakan sekitar 30 – 60 menit per agenda

4. Sering dilakukan break

Langkah Dalam JAD

1. Memilih peserta (participant) 2. Merancang pertemuan (session) 3. Menyaipakan pertemuan (session) 4. Pelaksanaan pertemuan (session) 5. Follow-up

Key Idea JAD

1. Memungkinkan adanya kerjasama yang lebih intensif antara manager, user dan pengembang

2. Dapat mengurangi informasi yang tidak sesuai/jelas hingga 50%

3. Menghindari kebutuhan user yang terlalu spesifik ataupun yang tidak jelas

Setting JAD

1. Mengatur tempat duduk berbentuk U-Shaped 2. Menghindari gangguan-gangguan

3. Whiteboard/flip chart 4. Prototyping tools 5. e-JAD

Pertemuan (Session) JAD

1. Diselenggarakan pada 5 – 10 hari terakhir untuk periode 3 bulanan 2. Menyiapkan pertanyaan sebagaimana Interview

3. Menyiapkan agenda formal 4. Memfasilitasi akrifitas-aktifitas

a. Menjaga pertemuan agar tetap pada pokok bahasan dan terkendali b. Membantu untuk menjelaskan istilah teknis

c. Merekam input dari kelompok

Bentuk Ruang Pertemuan JAD

Mengatur Permasalahan Dalam JAD

1. Reducing domination

2. Encouraging non-contributors 3. Side discussions

4. Agenda merry-go-round 5. Violent agreement 6. Unresolved conflict 7. True conflict 8. _{Use humour}

KUESIONER

Langkah Dalam Menyusun Kuesioner

1. Selecting participants, Using samples of the population 2. Designing the questionnaire, Careful question selection

3. Administering the questionnaire, Working to get good response rate 4. 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

4. Careful not to ignore periodic activities o 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 Teknik

Interview JAD Questionnaire Document

Analysis

High High Medium Low Low

Luasnya Informasi

Low Medium High High Low

Integrasi Informasi

Low High Low Low Low

Keterlibatan User

Medium High Low Low Low

Biaya Mediu Low

-Medium

Low Low Low

BAB II

KARAKTERISTIK PERANGKAT LUNAK

1. 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 LUNAK

1. Dibuat melalui sederetan/kumpulan perintah. 2. Struktur database.

3. Rancangan/disain perangkat lunak.

JENIS APLIKASI PERANGKAT LUNAK

System Software

Adalah kumpulan program yang ditulis untuk menunjang membuatan program. Misal : kompiler, editor, utilitas file.

Real Time Software

Adalah PL yang digunakan untuk mengontrol proses input data sampai menghasilkan laporan.

Bussines Software

PL yang banyak digunakan dalam dunia bisnis. Misal : SPSS, MYOB, Access, Corel, Flash.

Engineering and Scientific Software

PL yang digunakan dalam bidang teknik dan rekayasa. Misal : GIS, Astronomi, Vulkanologi, Arc View.

Embeded Software

PL yang digunakan untuk mengontrol suatu proses dam pabrik, biasanya disimpan dalam ROM.

PERANGKAT LUNAK

Merupakan kumpulan program dan dokumentasi yang saling berkaitan. Produk perangkat lunak dibuat 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 LUNAK

MODEL PROSES PERANGKAT LUNAK

Suatu representasi proses perangkat lunak yang disederhanakan, dipresentasikan dari 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 dari komponen yangreusable.

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 :

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 BAIK

PL seharusnya memberikan pengguna kebutuhan fungsionalitas dan unjuk kerja yang dapat di rawat, berguna.

1. Maintanability: PL harus dapat memenuhi perubahan kebutuhan. 2. Dependability: PL harus dapat dipercaya.

3. Efisiensi : PL harus efisien dalam penggunaanresource.

4. 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,

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.

Requirements

definition

System and

software design

Implementation

and unit testing

Integr ation and

system testing

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 (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 (misalUser 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

PROSES DENGAN METODE ITERASI

Metode Iterasi dapat digunakan pada setiap model proses generik. Terdapat dua pendekatan:

 Pengembangan Incremental

 Model Spiral

Model Pengembangan Incremental

1. Pengembangan sistem berdasarkan model sistem yang dipecah sehingga model pengembangannya secaraincreament/bertahap.

2. Kebutuhan pengguna diprioritaskan dan priritas tertinggi dimasukkan dalam awal increment.

3. Setelah pengembangan suatu increment dimulai, kebutuhan dibekukan dulu hingga incrementberikutnya dimulai.

Keuntungan :

1. Nilai penggunan dapat ditentukan pada setiapincreamentsehingga fungsionalitas sistem disediakan lebih awal.

2. Increment awal berupa prototype untuk membantu memahami kebutuhan pada

incrementberikutnya.

3. Memiliki resiko lebih rendah terhadap keseluruhan pengembagan sistem. 4. Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji.

MODEL PENGEMBANGAN SPIRAL

Proses direpresentasikan sebagai model spiral (bukan berupa barisan aktfitas yang dapat di track mundur). Setiap loop dalam model spiral menyatakan fase proses. Tidak terdapat fase tertentu seperti spesifikasi atau perancangan, tetapiloopdalam spiral ditentukan pada apa yang dibutuhkan.

Sektor pada Model Spiral

1. Menentukan Tujuan, Mengidentifikasikan spesifikasi tujuan setiapfase.

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.

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

Perancangan dan Implementasi Perangkat Lunak

1. 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

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 FlowModel

o Model relasi atribut entitas o Model terstruktur

o ModelObject

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.

BAB III

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 FOKUS PADA 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 :

Tipe Non-Fungsional

 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 dan lain-lain. 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

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

V i e w p o i n t i d e n t if i c a t io n

V i e w p o i n t s t r u c t u r i n g

V i ew p o i n t d o c u m e n ta t io n

Viewpoint Service Information

Bentuk Standard VORD

Viewpoint Templete Service Templete

Skenario

Penggambaran bagaimana 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 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.

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 besar

MANAJEMEN PERUBAHAN KEBUTUHAN

Outline Spesifikasi Kebutuhan Software

1. Pendahuluan

a. Referensi Sistem b. Deskripsi Umum Sistem

c. Kendala Proyek 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 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

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 tinggi

o Dimungkinkan tidak tersedianya staff yang memiliki kemampuan sesuai dengan yang diinginkan

o Pengembangan kemampuan(skill) pegawai pada proyek software

 Menuntut kemampuan manager dalam menentukan staff sesuai dengan standar tenaga IT 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 untuk mendukung perencanaan proyek utama yang memiliki kendala terhadap waktu dan biaya

JENIS-JENIS PERENCANAAN

Jenis Deskripsi

Perencanaan Kualitas Menentukan standar dan prosedur penentuan kualitas software yang digunakan

delay(untuk sementara) review perkembangan proyek

revisi parameter dan estimasi proyek apply revisi ke jadwal

negosiasikan kembali kendala proyek dan pengiriman

if(terdapat masalah) then

initiasi review teknis dan kemungkinan revisi

end if

4. Kebutuhan akan sumber daya hardware dan software 5. Work breakdown

6. Penjadwalan Proyek

7. Mekanisme pemantauan dan pelaporan

PENGORGANISASIAN KEGIATAN PROYEK

1. Aktifitas pada suatu pengembangan proyek harus diorganisasikan untuk menghasilkan output yang terukur bagi manajemen dan penentuan progress.

2. Milestonesmerupakan 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 Penjadwalan

1. 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.

Diagram Batang Dan Jaringan Kerja

1. 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 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)

Timeline Aktifitas

Alokasi Staf

MANAJEMEN RESIKO

1. 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 Software

Resiko Tipe

Resiko

Deskripsi

Pindahnya Staff Proyek Perginya staff berpengalaman sebelum proyek selesai

Hardware yang tidak tersedia

Proyek Harware penting tidak dapat dikirim sesuai dengan waktu yang sudah ditentukan

Perubahan Kebutuhan Proyek dan Produk

Munculnya perubahan kebutuhan yang lebih besar dibandingkan antisipasinya

Spesifikasi pada interface penting tidak dapat disediakan tepat waktu

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 Resiko

1. Identifikasi Resiko, Identifikasi resiko proyek, produk dan bisnis 2. Analisis Resiko, Menilai konsekuensi dan likelihood resiko

3. Perencanaan Resiko, Menggambarkan perencanaan untuk menghindari dan meminimisasi dampak resiko

4. Memantau Resiko, Memantau resiko selama proyek pengembangan

Identifikasi Resiko

Teknologi Kecepatan Database-Engine yang digunakan tidak dapat melakukan proses transaksi sebanyak yang dinginkan,

Analisis Resiko

1. 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 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, 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 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

1. 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.

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

BAB V

OBJECT ORIENTED ANALYSIS AND DESIGN

1. 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-Oriented

1. Reusability. 2. Modularity. 3. 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 dan 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.

status: {current, left, retired} taxCode: integer

name: John

address: M Street No.23 dateOfBirth: 02/10/65

Eployee16.changeDetail(“X Street No. 12”)

Inheritance

Generalisasi

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 Agregasi

1. Model agregasi menunjukkan bagaimana class-class dibentuk dari class yang lainnya 2. 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.

Komunikasi Dalam Object

1. Object berkomunikasi dengan object lain melalui pengiriman pesan (messages)

 Suatu pesan adalah suatu metode call dari suatu object pengirim-pesan ke suatu object penerima pesan

 Suatu pesan terdiri dari: Object referensi yang mengindikasikan penerima pesan, nama method dan parameter (argumen dari method)

2. 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

1. Menganalisa domain masalah. 2. Menggambarkan proses system. 3. Identifikasi object.

4. Spesifikasi atribut.

Identifikasi Suatu Object

1. 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.

Object Relations

Package

 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 softwareintensive system.

Building Blocks

1. Things 2. Relationships 3. 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

Class Inheritance

Class – Dependencies A 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.

Statechart Diagram

A statechart diagram shows a state machine, consisting of states, transitions, events, and activities.

Activity Diagram An activity diagram is a special kind of a statechart diagram that shows the flow from 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

Sequence Diagram A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages.

DEPLOYMENT DIAGRAM

LAMPIRAN-LAMPIRAN

Berikut ini dilampirkan tabel-tabel yang diperlukan pada saat melakukan rekayasa perangkat lunak dari tahap survei sampai uji program. Tabel-tabel berikut biasanya digunakan dan diisi ketika rekayasa berlangsung. Data yang tercantum dalam tabel hanya sebai contoh saja.

Tabel 1.

Tabel 2.

Tabel 4.

Tabel 5.

Tabel 8.

Tabel 9.

Tabel 12.

Tabel 13.

Tabel 15.

Tabel 16.

Tabel 18.

Tabel 19.

Tabel 20.