L

RPL #02 PARADIGMA PENGEMBANGAN P/L

TATA TERTIB KULIAH 1- Mahasiswa & Dosen hadir tepat waktu dikelas sesuai dengan jadwal yang disepakati. 2- Mahasiswa & Dosen mematikan nada panggil HP (silent mode). 3- Mahasiswa dan Dosen tidak menerima telpon di dalam kelas, bisa menerima telpon di luar kelas. 4- Mahasiswa tidak menggunakan Laptop dan HP kecuali kecuali pada saat mengerjakan tugas atau quiz. 5- Pada saat Dosen menjelaskan, mahasiswa memperhatikan dengan seksama. 6. Dosen memperlakukan Mahasiswa sebagai pribadi yang dewasa. 2

TATA TERTIB KULIAH 7- Mahasiswa mengerjakan dan mengumpulkan tugas sesuai dengan waktu yang disepakati. (ada konsekuensi keterlambatan) 8- Mahasiswa yang berhalangan mengikuti UTS/UAS harap segera mengikuti UTS/UAS susulan paling lambat dua minggu setelah jadwal UTS/UAS. Setelah nilai di-release tidak ada UTS/UAS susulan.

3

POKOK BAHASAN 01- PENDAHULUAN 02- PARADIGMA PENGEMBANGAN P/L 03- ANALISIS KEBUTUHAN P/L I 04- ANALISIS KEBUTUHAN P/L II 05- ANALISIS KEBUTUHAN P/L III 06- DESAIN P/L I 07- DESAIN P/L II 08- UTS 09- DESAIN P/L III 10- PEMBUATAN PROGRAM 11- PENGUJIAN PERANGKAT LINAK I 12- PENGUJIAN PERANGKAT LUNAK II 13- PENGENALAN UML 14- PENGENALAN UML 15- KONFIGURASI P/L 16- UAS

(Spesikasi Kebutuhan Fungsional) (Pemodelan Terstruktur) (Dokumen Spesifikasi P/L) (Desain Arsitektur P/L) (Desain Prosedur/Fungsi) (Desain Antarmuka) (Black Box Testing) (White Box testing) (Pemodelan Analisis) (Pemodelan Desain) (Versi Software)

4

ENGINEERING = REKAYASA = TEKNIK Definisi : Rekayasa (Engineering) Penerapan ilmu dan teknologi untuk menyelesaikan SOFTWARE ENGINEERING suatu permasalahan manusia. REKAYASA : TUJUAN nya : BAIK

DIREKAYASA ….???

5

SOFTWARE = PERANGKAT LUNAK  Instruksi atau program (aplikasi) komputer yang ketika dieksekusi akan memberi fungsi dan hasil yang diinginkan.  Struktur data, yang memungkinkan program memanipulasi informasi  Dokumen yang menggambarkan konfigurasi, operasi, cara penggunaan dan versi dari software itu sendiri. 6

SOFTWARE ENGINEERING = REKAYASA PERANGKAT LUNAK  Pengembangan perangkat lunak dengan menggunaan prinsipprinsip rekayasa sehingga dihasilkan produk perangkat lunak yang ekonomis, andal dan bekerja efisien pada mesin nyata.  Suatu disiplin rekayasa yang berkonsentrasi terhadap seluruh aspek produksi perangkat lunak (teknis & manajerial).  Mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaan yang dilakukan dan menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang akan dipecahkan, kendala pengembangan dan sumber daya yang tersedia. 7

SOFTWARE ENGINEERING = REKAYASA PERANGKAT LUNAK Proses manipulasi, membuat atau menciptakan sesuatu yang sifatnya khayalan logic yang di wujudkan dalam urutan-urutan perintah (coding) beserta data-datanya sehingga menjadi suatu aplikasi yang dapat digunakan.

8

Karena terjadi KRISIS P/L (SOFTWARE CRISIS) Yaitu : sekumpulan masalah yang ditemukan dalam pengembangan software. - Software yang dibuat tidak berfungsi sebagaimana mestinya,

MENGAPA PERLU - Software yg dibuat tidak berkualitas. SOFTWARE ENGINEERING...??

- Software yg dibuat, tidak dapat diselesaikan tepat waktu. - Software yg dibuat, over biaya. - Software yg dibuat sulit untuk dipelihara.

9

Bagaimana mengembangkan software yg berkualitas, tepat waktu, tepat biaya ?

SOFTWARE ENGINEERING

Bagaimana memelihara software yang ada, yang berkembang dalam jumlah besar? Berusaha menjawab : Bagaimana mengimbangi permintaan software yang makin besar ?

10

PENYEBAB KRISIS P/L 1. Karakteristik dari software itu sendiri Karakteristik software adalah software itu bersifat logika bukan fisik. Kesulitan dalam mengukur : - scope/ruang lingkup software (kompleksitas) - ketersediaan : sumber daya, waktu dan biaya - pada umumnya perangkat lunak dikembangkan tidak dengan merakit dari komponen-komponen yang sudah ada (????)

2.

Kompleksitas software semakin meningkat (sesuai dengan perkembangan teknologi dan kebutuhan)

3.

Kegagalan mereka yang pengembangan software .

bertanggung

jawab

dalam

Manajer, Software Analyst, Programmer, Software Tester, ... 11

SOFTWARE ENGINEERING Software Engineering mempunyai keterkaitan yang erat dengan System Engineering: karena pada umumnya perangkat lunak merupakan bagian dari sebuah sistim yang lebih besar. Analisis Kebutuhan

Perancangan Sistim

- Arsitektur sistim - Alokasi kebutuhan pada elemen sistim

Pengembangan Elemen Sistim

Integrasi sistim

Pengujian Sistim

Rekayasa Perangkat Lunak (RPL)

System Engineering 12

SOFTWARE ENGINEERING SECURE PARKING SYSTEM

AREA/ PORTAL BANGUNAN OTOMATIS

TOMBOL KAMERA KARCIS PARKIR

System Engineering

APLIKASI PARKIR

LAN

SYSTEM

HARDWARE

SOFTWARE

13

SOFTWARE ENGINEERING SECURE PARKING SYSTEM

AREA/ PALANG BANGUNAN OTOMATIS

TOMBOL KAMERA KARCIS PARKIR

APLIKASI PARKIR

LAN

SOFTWARE ENGINEERING

14

PROSES PENGEMBANGAN PERANGKAT LUNAK Rekayasa Sistim (Analisis & Perancangan) Analisis P/L

Perancangan P/L

Penulisan Program

Pengujian P/L

Pemeliharaan

15

PROSES PENGEMBANGAN PERANGKAT LUNAK

Rekayasa Sistim (Analisis & Perancangan) Analisis P/L

Perancangan P/L

Penulisan Program

Pengumpulan kebutuhan pada level sistim dengan sedikit perancangan dan analisis.

Kebutuhan perangkat lunak juga dialokasikan, yaitu dalam hal bagaimana interaksinya dengan perangkat keras, fungsi/operasional, orang/pengguna dan kebutuhan data/basis data.

Pengujian P/L

Pemeliharaan

Rekayasa Sistim (Analisis & Perancangan)

PROSES PENGEMBANGAN PERANGKAT LUNAK Analisis P/L

Perancangan P/L

Proses pengumpulan kebutuhan (requirement) lebih difokuskan pada kebutuhan perangkat lunak.

Penulisan Program

Pengujian P/L

Kebutuhan yang telah diidentifikasi kemudian dianalisis sehingga diperoleh domain informasi, fungsi-fungsi yang diperlukan, antarmuka, perilaku dan performansi perangkat lunak

Pemeliharaan

Hasil analisis didokumentasikan dan direview dengan pelanggan.



Perancangan P/L

Penulisan Program

Menentukan atribut program yaitu : , arsitektur perangkat lunak, struktur data, prosedur (algoritma) secara detil dan karakteristik antarmuka dari modul-modul perangkat lunak.

Pengujian P/L

Hasil perancangan ini juga didokumentasikan dan akan menjadi bagian dari dokumen teknis perangkat lunak.

Pemeliharaan


Rekayasa Sistim (Analisis & Perancangan) Analisis P/L

Perancangan P/L

Penulisan Program

Pengujian P/L

Hasil perancangan diubah menjadi bentuk yang bisa dimengerti oleh mesin, dengan menuliskan kode-nya sesuai dengan bahasa permograman yang dipilih.

Pemeliharaan



Perancangan P/L

Penulisan Program

Pengujian P/L

Setelah penulisan program selesai dilanjutkan dengan pengujian.

Pengujian difokuskan pada logika internal, fungsi eksternal, dan mencari segala kemungkinan kesalahan dengan menerapkan kasus uji dan skenario tertentu kemudian diamati hasilnya sesuai dengan yang diinginkan atau tidak.

Pemeliharaan



Analisis P/L

Perancangan P/L

Penulisan Program

Setelah diberikan kepada pelanggan dan dijalankan, dimungkinkan masih/akan ditemukan lagi adanya kesalahan pada perangkat lunak karena adanya perubahan lingkungan eksternal/kesalahan yang tidak terdeteksi pada saat pengujian.

Pengujian P/L

Pemeliharaan

Sehingga perlu adanya aktifitas pemeliharaan. Pemeliharaan juga diperlukan jika pelanggan meminta penambahan fungsi-fungsi baru karena adanya perkembangan kebutuhan.

ANALISIS KEBUTUHAN PERANGKAT LUNAK (SOFTWARE REQUIREMENT ANALYSIS) Kebutuhan / Persyaratan / Requirement adalah pernyataan kemampuan fungsional dan persyaratan lain (non fungsional) dari perangkat lunak yang akan dikembangkan. Kebutuhan/Persayaratan/Requirement harus dipahami, disepakati oleh kedua belah pihak dan ditulis dalam dokumen (buku).

Dokumen (buku) yang berisi spesifikasi P/L disebut dengan : dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement Specification (SRS) document

Analsis Kebutuhan P/L (Software Requirement Analysis) adalah aktivitas penentuan (pendefinisian) kebutuhan/persyaratan (requirement) perangkat lunak yang akan dibuat, yang dilakukan oleh anggota tim software developer dan kustomer (pengguna)

ANALISIS KEBUTUHAN PERANGKAT LUNAK (SOFTWARE REQUIREMENT ANALYSIS)

Waktu Biaya Teknologi Hukum

Di bawah ini adalah percakapan antara Manager suatu hotel dan Developer perangkat lunak

Manager Hotel : Halo, apakah benar ini dengan DataReka..? (Datareka adalah nama sebuah software developer) Developer: Iya benar Pak! Ada yang bisa kami bantu Pak? Manager Hotel : Bisakah DataReka membuatkan sistem informasi untuk hotel kami..? Developer : Dengan senang hati kami akan membantu pembangunan sistem informasi hotel bapak. Manager Hotel : Kira2 bisa cepat, gak? Apa bisa Senin depan kami gunakan..? Soalnya, ini sangat mendesak dan perlu segera digunakan..! (telponnya hari jumat) Developer : ha…..????? (Data aja belum diberikan, undah minta selesai..!) Maaf, pak kami akan pelajari terlebih dahulu.. Kami belum bisa memutuskan sebelum tim kami melakukan observasi pada hotel bapak.. Manager Hotel : Udah…., buat yang sederhana aja tidak apa2. Soal harga kami bisa menyediakan. Developer : Maaf, pak kami tidak bisa membantu, silakan mencari developer yang lain. Manager Hotel : Tut..tut..tut..

KEGUNAAN SPESIFIKASI P/L Menyatukan pemahaman antara developer dengan konsumen Membuat perencanaan : ruang lingkup pekerjaan, perkiraan harga, perkiraan biaya dan perkiraan sumber daya (resources) Ikatan hukum, dasar kontrak kerja antara software developer dengan kustomer

Faktor Utama Kegagalan P/L • Kebutuhan kustomer tidak disampaikan dengan baik. • Kebutuhan kustomer tidak bisa dipahami dan ditangkap dengan tepat oleh developer • Kustomer tidak bisa bekerja sama dengan developer • Kebutuhan kustomer sering mengalami perubahan • Developer kurang memiliki kecakapan dalam menjalankan tugas • Sistem yang dikembangkan tidak terlalu banyak memberikan manfaat kepada kustomer

Software yang benarbenar diinginkan oleh Kustomer

Saya ingin dibuatkan kendaraan yang bisa membawa saya keliling kota , bebas macet

Kustomer

OK, siaap..!!

Kontraktor

Iswanto…., ada beberapa perubahan requirements lagi dari kustomer, minta segera implementasikan

METODE UNTUK MENENTUKAN KEBUTUHAN P/L

– Wawancara(Interviews) – Kuisioner(Questionnaires) – Pertemuan strukutral (Structured meeting) – Skenario operasi (Operation Scenarios) – Prototipe(Prototyping)

METODE UNTUK MENENTUKAN KEBUTUHAN P/L WAWANCARA : Wawancara adalah cara mendapatkan kebutuhan informasi tentang software yang akan dibuat dari kustomer atau memastikan kebutuhan yang diinginkan Adalah sangat penting antara pewawancara dengan yang diwawancara jelas tentang apa yang dibicarakan dan apa yang ingin didapatkan dari interview tersebut. Kemampuan untuk mendengarkan secara baik dan mengidentifikasikan apa yang penting adalah keahlian yang penting dalam rekayasa kebutuhan. Memilih orang yang tepat untuk di interview adalah hal yang penting untuk mendapatkan kebutuhan yang sesungguhnya dari sistem yang baru.

METODE UNTUK MENENTUKAN KEBUTUHAN P/L D&B System – Interview Plan Interview Plan : DB System System:Just A Line System : Sistem Informasi Rumah Sakit

Project Reference:JaL/MB/00 SIRS/DR/2011

Participant: Sue Preston (Just a line) Iswanto Harry Preston (Just a line) Cestaka Wali Barnes Muhammad Mark (D&B) Date: 10/4/2002 10/04/2011

Time: 14:00

Duration: 45 Minutes

Place: Sue officeSadikin RS. Hasan

Purpose of Interview: Pertemuan meeting untuk mengidentifikasi permasalahan dan requirements Preliminary to identify problems and requirements regardingkeamanan security atdari theSIRS Just A Line Agenda: Problem with security and any other concerns Current security procedures Initial ideas Follow-up actions Document to be brought into interview” Rough plan of building and sites Any documents relating to current security procedures

METODE UNTUK MENENTUKAN KEBUTUHAN P/L

WAWANCARA Sebuah wawancara yang baik adalah wawancara yang menghasilkan sejumlah informasi untuk rekayasa kebutuhan yang berbeda-berbeda seperti :

Informasi yang sudah ada dalam struktured list , form, guidelines, dan peraturan. Informasi tentang prosedur perusahaan Ukuran seberapa banyak pelanggan dan rata-rata ukuran order; Problem klien yang teridentifikasi dari sistem yang sekarang Kebutuhan awal yang diinginkan dalam sistem yang baru.

METODE UNTUK MENENTUKAN KEBUTUHAN P/L PERTEMUAN STRUKTURAL Suksesnya pencarian kebutuhan seringkali didapatkan dengan pertemuan struktural dengan stakeholder, siapa saja yang mungkin ikut tidak hanya klien dan user tetapi juga manager, marketing staff dan juga trainner. Pertemuan seperti ini mengambil waktu dari banyak orang dan oleh karena itu harus dengan hati-hati direncanakan dan dengan agenda yang jelas. Managemen yang efektif selama pertemuan sangat penting untuk mencegah konflik yang tidak perlu dalam mencapai tujuan utama.

METODE UNTUK MENENTUKAN KEBUTUHAN P/L SKENARIO Skenario adalah sebuah deskripsi dengan bahasa sehari-hari yang mengambarkan urutan interaksi antara user dengan sistem. PROTOTYPING Prototyping sangat baik digunakan pada user yang kurang yakin dengan apa yang mereka butuhkan. Lebih mudah memberikan komentar kepada sesuatu yang nyata.

MENCARI INFORMASI

Sumber lain seperti: Literatur tentang problem doomain seperti koran dan market survey Informasi dari web (WWW)

LANGKAH UNTUK MENENTUKAN SPESIFIKASI Memahami Kebutuhan User Memahami Proses Bisnis Menyatakan Kebutuhan dalam Kalimat yang benar Membuat Model untuk memperjelas kalimat. Membuat Dokumen SKPL

Model berfungsi untuk : - Alat mendokumentasikan kebutuhan P/L - Membantu pembagian lingkup sistem sehingga lebih mudah diatur - Alat untuk mengkomunikasikan fungsionalitas sistem pada pengguna dan stakeholder lain - Membantu melakukan estimasi lingkup, usaha, biaya dan jadwal sebuah proyek

SOFTWARE REQUIREMENTS ANALYSIS Contoh Dokumen SKPL

SOFTWARE REQUIREMENTS ANALYSIS

Untuk kasus kedua tujuan SKPL adalah :

SOFTWARE REQUIREMENTS ANALYSIS KEGUNAAN SKPL ADALAH

SOFTWARE REQUIREMENTS ANALYSIS SYARAT SKPL

Pada saat di jalankan (diklik 2x), maka software akan menampillkan splash screen sebentar kemudian muncul menu utama Pada saat di jalankan (diklik 2x), maka software akan menampillkan Splash screen maksimal selama 5 detik kemudian muncul menu utama

Nilai

0

Nilai benar

100

0,100,75 Test Case

Nilai tdk benar

-1, 101, a





PROSES BISNIS PROSES BISNIS adalah aturan dan alur dari suatu proses kerja suatu sistem

Proses Bisnis Penjualan

Order Barang

Menangani pembayaran

Melayani order

Menyiapkan barang Pengiriman

Penjelasan Gambar: Customer ingin memesan sesuatu barang dari sebuah toko. Kemudian menelpon customer service dari toko tersebut. Customer service melayani order & mengecek pembayaran dari customer apakah sudah diterima bagian finance Bagian finance memproses/memvalidasi pembayaran Jika pembayaran selesai kemudian customer service meminta warehouse menyiapkan barang pesanan. Warehouse kemudian melakukan delivery untuk mengirim barang ke customer

SPESIFIKASI KEBUTUHAN

SECURE PARKING SYSTEM

1. DESKRIPSI SISTEM • Secure Parking adalah sebuah sistem yang berfungsi untuk mengelola parkir kendaraan bermotor, sehingga kendaraan parkir dijamin keamanannya dan pengelola parkir dapat memonitor data kendaraan yang parkir dan mendapatkan laporan kendaraan parkir dengan cepat dan tepat. • Pengguna Secure Parking adalah Administrator, Manajemen Pengelola Parkir, Operator dan Pengemudi Kendaraan.

1. DESKRIPSI SISTEM (cont’d) • Secara garis besar proses parkir menggunakan Secure Parking adalah sebagai berikut : – pencatatatan kendaraan masuk secara manual oleh operator masuk atau secara otomatis, pencetakan karcis parkir, pembukaan palang pintu masuk jika registrasi berhasil secara otomatis atau oleh operator, kemudian kendaraan dibolehkan parkir pada tempat yang sesuai. – Pencatatan kendaraan keluar oleh operator keluar, pengecekan kendaraan apakah sesuai dengan karcis parkir jika sesuai akan dilakukan pembayaran, pencetakan bukti pembayaran dan pembukaan pintu keluar secara manual oleh operator keluar.

1. DESKRIPSI SISTEM (cont’d) – Semua pengguna selain pengemudi kendaraan, bisa menggunakan Secure Parking jika telah terdaftar sebagai user oleh Administrator. Administrator juga bisa melakukan pengaturan tarif parkir. – Manajemen Pengelola Parkir dapat memonitor kendaraan yang sedang parkir dan bisa mendapatkan laporan data parkir untuk periode harian, perbulan dan pertahun.

2. PERSYARATAN PENGGUNA Pengguna sistem terdiri dari Administrator, Manajemen Pengelola Parkir, Operator Masuk, Operator Keluar, Pengemudi. a) Administrator mampu melakukan : mendaftar, menghapus, merubah data pengguna dan melakukan pengaturan perhitungan (tarif) parkir. b) Operator Masuk mampu melakukan : mencatat data kendaraan masuk, membuka palang pintu masuk, mencetak karcis parkir.

2. PERSYARATAN PENGGUNA (cont’d) c) Operator Keluar mampu melakukan : mencatat data kendaraan keluar, membuka palang pintu keluar, mencetak bukti pembayaran parkir. d) Manajemen Pengelola Parkir mampu melakukan: monitor data kendaraan parkir dan melihat laporan kendaraan parkir.

3. KEMAMPUAN FUNGSIONAL 3.1 Pengelolaan Pengguna Sistem (SP_3100) - SP_3101 : Sistem mampu melakukan pendaftaran pengguna dengan memasukkan nama account (user account), password default, tipe pengguna, nama pengguna .... - SP_3102 Pengguna yang sudah terdaftar bisa melakukan penggantian password.

3. KEMAMPUAN FUNGSIONAL (cont’d) 3.2 Pengelolaan Login - SP_3201 : Setiap pengguna yang akan menggunakan sistem harus melakukan login. - SP_3202 : Jika login berhasil maka pengguna bisa menggunakan sistem sesuai dengan tipe pengguna.

3. KEMAMPUAN FUNGSIONAL (cont’d) 3.3 Pencatatan Kendaraan Masuk -SP_3301 : Sistem mampu melakukan pencatatan kendaraan masuk secara otomatis, yaitu jika sensor mendeteksi kendaraan yang berada di pintu masuk, kemudian pengemudi menekan tombol, kamera merekam data kendaraan (gambar : plat nomor dan wajah pengemudi), dan kemudian sistem mencetak karcis parkir.

3. KEMAMPUAN FUNGSIONAL (cont’d) 3.3 Pencatatan Kendaraan Masuk (cont’d) -SP_3302 : Jika pencatatan kendaraan masuk secara otomatis berhasil maka sistem akan membukakan palang pintu masuk. -SP_3303 : Sistem mampu melakukan pencatan kendaraan masuk secara manual, jika pencatatan secara otomatis tidak bisa dilakukan, yaitu dengan cara opertaor mencatat nomor kendaraan, jenis kendaraan, mencetak karcis parkir, kemudian membukakan palang pintu masuk dengan cara menekan tombol buka pintu.

3. KEMAMPUAN FUNGSIONAL (cont’d) 3.3 Pencatatan Kendaraan Masuk (cont’d) -SP_3304 : Sistem mempu mencatat waktu masuk kendaraan baik melalui pencatatan otomatis maupun pencatatan secara manual. -SP_3305 : Semua data kendaraan masuk disimpan dalam data base untuk keperluan pencocokan kendaraan pada saat keluar parkir.

3. KEMAMPUAN FUNGSIONAL (cont’d) 3.4 Pencatatan Kendaraan Keluar -SP_3401 : Sistem mampu menampilkan data kendaraan yang akan keluar sesuai dengan data karcis parkir yang diberikan oleh pengemudi. -SP_3402 : Operator Keluar memastikan bahwa kendaraan yang akan keluar sesuai dengan data yang ditampilkan oleh sistem. Jika data sesuai maka Operator melakukan pembayaran sesuai dengan tarif yang berlaku, mencetak bukti pembayaran, kemudian membukakan palang pintu keluar.

3. KEMAMPUAN FUNGSIONAL (cont’d) 3.5 Perhitungan Tarif Parkir -SP_3501 : Sistem mampu menyediakan fasilitas untuk melakukan pengaturan tarif parkir.

3. KEMAMPUAN FUNGSIONAL (cont’d) 3.6 Pengelolaan Laporan -SP_3601 : Sistem mampu menyediakan fasilitas untuk pembuatan laporan berdasarkan tanggal, bulan dan tahun.

TUGAS 1 (KELOMPOK) 1. Pilih sebuah sistem informasi (software / aplikasi) yang ingin saudara tinjau 2. Buat Spesifikasi Kebutuhan Perangkat Lunak dari sistem informasi yang anda pilih, dengan format sebagai berikut : JUDUL : “Nama Sistem yang saudara pilih.” BAB 1. Deskripsi Umum Sistem <menjelaskan gambaran secara umum fungsi dari software yang dipilih> BAB 2. Persyaratan Pengguna (Format penulisan lihat contoh pada materi kuliah) BAB 3. Kebutuhan Fungsional (Format penulisan lihat contoh pada materi kuliah)

L

Recommend Documents