TM S 4 REKAYASA PERANGKAT LUNAK

REKAYASA PERANGKAT LUNAK

Oleh:

Imam Satria

123410084

­TUGAS MANDIRI

REKAYASA PERANGKAT LUNAK

Hlaman judul

PROGRAM STUDI SISTEM INFORMASI

UNIVERSITAS PUTERA BATAM

TAHUN 2014

Kata pengantar

Syukur Alhamdulillah kehadirat Allah SWT yang telah melimpahkan segala rahmat dan karuniaNya, sehingga penulis dapat menyelesaikan laporan tugas mandiri mata kuliah rekayasa perangkat lunak. Penulis menyadari bahwa laporan tugas mandiri ini masih jauh dari sempurna. Karena itu, kritik dan saran akan senantiasa penulis terima dengan senang hati.

Dengan segala keterbatasan, penulis menyadari pula bahwa laporan tugas mandiri ini takkan terwujud tanpa bantuan, bimbingan, dan dorongan dari berbagai pihak. Untuk itu, dengan segala kerendahan hati, penulis menyampaikan ucapan terima kasih kepada:

1.      Bapak Muhammad Taufik Syastra., S.Kom., M.SI. selaku dosen mata kuliah rekayasa perangkat lunak pada Program Studi Sistem Informasi Universitas Putera Batam/STMIK Putera Batam.

2.      Dosen dan Staff Universitas Putera Batam/STMIK Putera Batam.

Semoga Allah SWT membalas kebaikan dan selalu mencurahkan hidayah serta taufikNya, Amin.

Batam,   April 2014

Imam Satria

123410084

Dartar isi

Halaman

Halaman judul i

Kata pengantar ii

Dartar isi iii

1.     Pendahuluan. 1

2.     Analisis dan Desain. 5

3.     System Development Life Cycle (SDLC) 9

4.     Basis Data. 12

5.     Pemograman Terstruktur 15

6.     Pemograman Berorientasi Objek. 16

7.     Analisis dan Desain Berorientasi Objek. 17

8.     Pemodelan dan UML.. 19

9.     Perancangan Pola Berorientasi Objek. 25

10.   Manajemen Proyek Perangkat Lunak. 26

Daftar Pustaka

1.                Pendahuluan

Ada 4 hal yang harus di perhatikan dalam bab satu ini:

1.      Perangkat Lunak

2.      Rekayasa Perangkat Lunak

3.      Proses Rekayasa Perangkat Lunak

4.      Teknologi Informasi Sosial

1.1.         Perangkat Lunak (software)

Adalah program komputer yang terasosiasi dengan dokumentasi perangkat lunak seperti dokumentasi kebutuhan, model desain, dan cara penggunaan (user manual).

Contoh : Ms Office, Nero, Avira Antivirus, AVG Antivirus, WinAmp

Perangkat Lunak (Software) untuk memenuhi kebutuhan pelanggan (Customer)

·       Karakteristik perangkat lunak

Karakteristik perangkat lunak adalah sebagai berikut :

1.      Perangkat Lunak dibangun dengan rekayasa (software engineering) bukan diproduksi secara manufaktur atau pabrikan.

2.      Perangkat lunak tidak pernah usang (“wear out”) karena kecacatan dalam perangkat lunak dapat diperbaiki.

3.      Barang produksi pabrikan biasanya komponen barunya akan terus diproduksi, sedangkan perangkat lunak biasanya terus diperbaiki seiring bertambahnya kebutuhan.

·       Aplikasi dari perangkat lunak

Aplikasi dari perangkat lunak adalah sebagai berikut :

1.      Perangkat lunak sistem (system software)

2.      Perangkat lunak waktu nyata (real-time software)

3.      Perangkat lunak bisnis (business software)

4.      Perangkat lunak untuk keperluan rekayasa dan keilmuan (engineering and scientific software)

5.      Perangkat lunak tambahan untuk membantu mengerjakan suatu fungsi dari perangkat lunak lainnya (embedded software)

6.      Perangkat lunak komputer personal (personal computer software)

7.      Perangkat lunak berbasis web (web based software)

8.      Perangkat lunak berintelijensia buatan (artificial intelligence software)

·       Produk perangkat lunak

Produk perangkat lunak dibuat oleh pengembang terdiri dari 2 (dua) jenis :

1.      Produk Generik

            Produk yang dibuat oleh pengembang untuk dijual atau dipopulerkan tanpa ada pemesanan terlebih dahulu.

            Contoh : Antivirus, Ms Office, Adobe Acrobat.

2.      Produk Pemesanan

            Produk yang dibuat karena ada pelanggan yang melakukan  pemesanan.

            Contoh : Aplikasi Persediaan Barang, POS (Point of Sales),  Sistem Informasi Akademik Mahasiswa.

1.2.         Rekayasa perangkat lunak

Merupakan pembangunan dengan menggunakan prinsip atau konsep rekayasa dengan tujuan menghasilkan perangkat lunak yang bernilai ekonomi yang dipercaya dan bekerja secara efisien menggunakan mesin.

Fokus rekayasa perangkat lunak adalah sebagai berikut :

1.      Dapat terus diperlihara setelah perangkat lunak selesai dibuat seiring berkembangnya teknologi dan lingkungan (maintability)

2.      Dapat diandalkan dengan proses bisnis yang dijalankan dan perubahan yang terjadi

3.      Efisiensi dari segi sumber daya  dan penggunaan

4.      Kemampuan dipakai sesuai dengan kebutuhan (usability)

fase dalam rekayasa perangkat lunak adalah sebagai berikut :

1.      Fase pendefinisian “what”

            Mencari tahu atau mengidentifikasi informasi apa yang harus           diproses, seperti apa fungsi dan performansi yang diinginkan.

2.      Fase pengembangan “how”

            Mendefinisikan bagaimana data distrukturkan dan bagaimana fungsi-fungsi yang dibutuhkan diimplementasikan di dalam arsitektur perangkat lunak, bagaimana detail prosedural diimplementasikan, bagaimana karakter antarmuka tampilan, bagaimana desain ditranslasikan ke bahasa pemrograman, dan bagaimana pengujian akan dijalankan.

3.      Fase pendukung (support phase)

            Perbaikan pada kesalahan, adaptasi yang dibutuhkan, perbaikan akibat perubahan kebutuhan pelanggan.

            Pada fase ini ada 4 tipe perubahan :

a.       Koreksi (correction)

b.      Adaptasi (adaptation)

c.       Perbaikan (enhacement)

d.      Pencegahan (prevention)

Tantangan Rekayasa Perangkat Lunak, Ada beberapa tantangan dalam rekayasa perangkat lunak :

1.      Tantangan warisan dimana perangkat lunak dikembangkan selama bertahun-tahun oleh orang-orang yang berbeda, hal ini dapat menyebabkan ketidak pahaman atau perubahan tujuan pembuatan perangkat lunak.

2.      Tantangan heterogenitas dimana perangkat lunak harus dapat beradaptasi dengan teknologi yang tersu berkembang dengan semakin luasnya lingkungan distribusi perangkat lunak.

3.      Tantangan pengiriman dimana perangkat lunak dengan skala besar dan kompleks sekalipun dapat sampai ke tangan pelanggan (customer) dengan cepat dan kualitas terjamin.

1.3.         Proses rekayasa perangkat lunak

 Proses rekayasa perangkat lunak umumnya adalah sebagai berikut :

1.      Pengumpulan spesifikasi (specification)

            Mengetahui apa saja yang harus dapat dikerjakan sistem perangkat lunak.

2.      Pengembangan (development)

            Pengembangan perangkat lunak untuk menghasilkan sistem perangkat lunak.

3.      Validasi (Validation)

            Memeriksa apakah perangkat lunak sudah memenuhi keinginan pelanggan (customer)

4.      Evolusi (Evolution)

            Mengubah perangkat lunak untuk memenuhi perubahan kebutuhan pelanggan (customer)

1.4.         Teknologi Informasi Sosial

Hal-hal yang harus dilakukan sebelum mengembangkan perangkat lunak di lingkungan tertentu maka harus dicari tahu :

1.      Pengetahuan lingkungan tentang teknologi informasi dan komputer

2.      “social knowledge” atau “local knowledge” (pengetahuan mengenai budaya lokal) di lingkungan yang akan dikembangkan perangkat lunak, apakah memungkinkan untuk dikembangkan perangkat lunak

3.      Pengetahuan tentang apa saja yang bisa dibatasi dan yang tidak, sehingga saat pengembangan perangkat lunak dapat mendefinisikan aturan main dari perangkat lunak

·       Konversi paralel

Sistem lama dan sistem baru:

Konversi paralel dilakukan dengan melakukan beberapa waktu transisi dimana ada waktu dimana kedua sistem (sistem lama dan sistem baru) berjalan bersama untuk keperluan transisi sampai sistem baru dapat berjalan mandiri. Sumber daya yang dibutuhkan pada konversi paralel akan banyak terkuras pada waktu transisi.

·       Konversi langsung

Sistem lama dan sistem baru:

Konversi langsung dilakukan di mana sistem lama secara ekstrim langsung diganti dengan sistem yang baru. Konversi ini akan mengalami waktu yang sangat sulit di awal berjalannya sistem baru.

·       Konversi per fase

Sistem lama dan sistem baru:

Konversi per fase dilakukan dengan berpindah per fase dari sistem lama ke sistem baru misalkan pada awal konversi hanya pada pekerjaan memasukkan data-data saja, pada tahap berikutnya mulai menggunakan proses perhitungan, lalu fase berikutnya mulai menggunakan proses pelaporan sistem baru, dan seterusnya (lebih fokus pada per fungsi sistem).

·       Konversi pilot atau single location

Sistem lama dan sistem baru:

Konversi pilot dilakukan dengan melakukan konversi per unit kerja atau per lokasi di dalam sebuah lingkungan kerja. Misalnya pada tahap awal unit kerja yang sistemnya berubah adalah bagian keuangan, berikutnya pada bagian sumber daya manusia, dan seterusnya.

2.                Analisis dan Desain

Ada 4 hal yang harus di perhatikan dalam bab satu ini:

1.      Definisi Analisis Sistem

2.      Teknik Pengumpulan Data

3.      Jenis Kebutuhan

4.      Definisi Desain Sistem

2.1.         Definisi Analisis Sistem

Kegiatan Analisis Sistem

Kegiatan untuk melihat sistem yang sudah berjalan, melihat bagian mana yang bagus dan tidak bagus, dan kemudian mendokumentasikan kebutuhan yang akan dipenuhi dalam sistem yang baru.

Analisis dan desain sering kali dilakukan secara bersamaan.

2.2.         Teknik Pengumpulan Data

1.         Teknik Wawancara

Panduan dalam melakukan wawancara memperoleh data :

1. Buatlah jadwal wawancara dengan narasumber dan beritahukan maksud dan tujuan wawancara
2. Buatlah panduan wawancara yang akan anda jadikan arahan agar pertanyaan fokus kepada hal-hal yang dibutuhkan
3. Gunakan pertanyaan yang jelas dan mudah dipahami
4. Cobalah untuk menggali mengenai kelebihan dan kekurangan sistem yang telah berjalan sebelumnya
5. Anda boleh berimprovisasi dengan mencoba menggali bagian-bagian tertentu yang menurut anda penting
6. Catat hasil wawancara tersebut

Keuntungan :

1. Lebih mudah dalam menggali bagian sistem mana yang dianggap baik dan bagian mana yang dianggap kurang baik
2. Jika ada bagian tertentu yang menurut anda perlu untuk digali lebih dalam, anda dapat langsung menanyakan kepada narasumber
3. Dapat menggali kebutuhan user secara lebih bebas
4. User dapat mengungkapkan kebutuhannya secara lebih bebas

Kerugian :

1. Wawancara akan sulit dilakukan jika narasumber kurang dapat mengungkapkan kebutuhannya
2. Pertanyaan dapat menjadi tidak terarah, terlalu fokus pada hal-hal tertentu dan mengabaikan bagian lainnya

2.         Teknik Observasi

Petunjuk dalam melakukan observasi :

1. Tentukan hal-hal apa saja yang akan diobservasi agar kegiatan observasi menghasilkan sesuai dengan yang diharapkan
2. Mintalah izin kepada orang yang berwenang pada bagian yang akan diobservasi
3. Berusaha sesedikit mungkin agar tidak mengganggu pekerjaan orang lain
4. Jika ada yang anda tidak mengerti, cobalah bertanya. Jangan membuat asumsi sendiri

Keuntungan :

1. Analis dapat melihat langsung bagaimana sistem lama berjalan
2. Mampu menghasilkan gambaran lebih baik jika dibanding dengan teknik lainnya

Kelemahan :

1. Membutuhkan waktu cukup lama karena jika observasi waktunya sangat terbatas maka gambaran sistem secara keseluruhan akan sulit untuk diperoleh
2. Orang-orang yang sedang diamati biasanya perilakunya akan berbeda dengan perilaku sehari-hari (cenderung terlihat baik). Hal ini akan menyebabkan gambaran yang diperoleh selama observasi akan berbeda dengan perilaku sehari-hari
3. Dapat mengganggu pekerjaan orang-orang pada bagian yang sedang diamati

3.         Teknik Kuisioner

Teknik dalam membuat kuisioner yang baik :

1. Hindari pertanyaan isian, lebih baik pilihan ganda, karena responden biasanya malas untuk menulis banyak, dan jika responden menuliskan sesuatu sering kali susah untuk dipahami. Dan juga dengan pertanyaan pilihan ganda, akan memudahkan anda untuk melakukan rekapitulasi data hasil kuisioner
2. Buatlah pertanyaan yang tidak terlalu banyak
3. Buatlah pertanyaan yang singkat, padat dan jelas

Keuntungan :

1. Hasilnya lebih objektif, karena kuisioner dapat dilakukan kepada banyak orang sekaligus
2. Waktunya lebih singkat

Kelemahan :

1. Responden cenderung malas untuk mengisi kuisioner
2. Sulit untuk membuat pertanyaan yang singkat, jelas dan mudah dipahami

2.3.         Jenis Kebutuhan

Kebutuhan (requirement) yang dikumpulkan dengan menggunakan wawancara, observasi, kuisioner, atau gabungan dari ketiga hal tersebut dapat dikelompokkan menjadi kategori sebagai berikut :

1. Functional requirement

Kebutuhan yang terkait dengan fungsi produk, misalnya sistem informasi harus mampu mencetak laporan, sistem informasi harus mampu menampilkan grafik, dll

2. Development requirement

Kebutuhan yang terkait tools untuk pengembangan sistem informasi baik perangkat keras maupun perangkat lunak, misalnya sistem informasi dikembangkan dengan menggunakan alat bantu Eclipse untuk pengembangan dan StarUML untuk pemodelan

3. Deployment requirement

Kebutuhan terkait dengan lingkungan dimana sistem informasi akan digunakan baik perangkat lunak maupun perangkat keras

4. Performance requirement

   Kebutuhan terkait dengan ukuran kualitas maupun kuantitas khususnya terkait dengan kecepatan, skalabilitas, dan kapasitas.

5. Documentation requirement

Kebutuhan ini terkait dengan dokumen apa saja yang disertakan pada akhir produk akhir

6. Support requirement

Kebutuhan yang terkait dukungan yang diberikan setelah sistem informasi digunakan. Dukungan teknis tersebut misalnya adanya pelatihan bagi calon pengguna

7. Miscellaneous requirement

Kebutuhan ini adalah kebutuhan-kebutuhan tambahan lainnya yang belum tercakup pada beberapa kategori kebutuhan yang telah terdefinisi di atas.

2.4.         Definisi Desain Sistem

Desain atau perancangan dalam pembangunan perangkat lunak. Merupakan upaya untuk mengkonstruksi sebuah sistem yang memberikan kepuasan (mungkin informal) akan spesifikasi kebutuhan fungsional, memenuhi target, memenuhi kebutuhan secara implisit atau eksplisit dari segi performansi maupun penggunaan sumber daya, kepuasan batasan pada proses desain dari segi biaya, waktu, dan perangkat.

3.                System Development Life Cycle (SDLC)

3.1.         Pengertian SDLC

Pada awal pengembangan perangkat lunak, para pembuat program (programmer) langsung melakukan pengkodean perangkat lunak tanpa menggunakan prosedur atau tahapan pengembangan perangkat lunak. Dan ditemuilah kendala-kendala seiring dengan perkembangan skala sistem-sistem perangkat semakin besar.

SDLC dimulai dari tahun 1960-an, untuk mengembangkan sistem skala usaha besar secara fungsional untuk para konglomerat pada zaman itu. Sistem-sistem yang dibangun mengelola informasi kegiatan dan rutinitas dari perusahaan-perusahaan yang berpotensi memiliki data yang besar dalam perkembangannya.

Berikut tahapan-tahapan dalam SDLC :

1. Inisiasi (initiation)
2. Pengembangan konsep sistem (system concept development)
3. Perencanaan (planning)
4. Analisis kebutuhan (requirement analysis)
5. Desain (design)
6. Pengembangan (development)
7. Integrasi dan pengujian (integration and test)
8. Implementasi (implementation)
9. Operasi dan pemeliharaan (operations and maintenance)
10. Disposisi (disposition)

SDLC memiliki beberapa model dalam penerapan prosesnya. Berikut model-model dari SDLC :

1. Model Waterfall / Sekuensial Linier
2. Model Prototipe
3. Model RAD (Rapid Application Development)
4. Model Iteratif / Inkremental
5. Model Spiral
6. Model Rakitan Komponen
7. Model Perkembangan Konkuren

A.       Model Waterfall  / Sekuensial linier

Model waterfall menyediakan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengkodean, pengujian, dan tahap pendukung (support).

Model Waterfall adalah model SDLC yang paling sederhana. Model ini hanya cocok untuk pengembangan perangkat lunak dengan spesifikasi yang tidak berubah-ubah.

B.       Model Prototipe

Model prototipe dapat digunakan untuk menyambung ketidakpahaman pelanggan mengenai hal teknis dan memperjelas spesifikasi kebutuhan yang diinginkan pelanggan kepada pengembang perangkat lunak.

Model prototipe cocok digunakan menggali spesifikasi kebutuhan pelanggan secara lebih detail tetapi beresiko tinggi terhadap membengkaknya biaya dan waktu proyek.

C.       Model RAD (Rapid Application Development )

Rapid Application Development (RAD) adalah model proses pengembangan perangkat lunak yang bersifat inkremental terutama untuk waktu pengerjaan pendek.

Model RAD adalah adaptasi dari model air terjun (model waterfall) versi kecepatan tinggi dengan menggunakan model air terjun untuk pengembangan setiap komponen perangkat lunak.

Jika kebutuhan perangkat lunak dipahami dengan baik dan lingkup perangkat lunak dibatasi dengan baik sehingga tim dapat menyelesaikan pembuatan perangkat lunak dengan waktu yang pendek.

Model RAD cocok diterapkan apabila memenuhi kriteria proyek sebagai berikut :

1)      Anggota tim sudah berpengalaman mengembangkan perangkat lunak sejenis

2)      Pengembang sudah memiliki komponen-komponen sistem yang bisa digunakan kembali dalam proyek tersebut

D.       Model Inkremental / Iteratif

Model inkremental mengkombinasikan proses-proses pada model air terjun (model waterfall) dan iteratif pada model prototipe. Model inkremental akan menghasilkan versi-versi perangkat lunak yang sudah mengalami penambahan fungsi untuk setiap pertambahannya (inkremen / increment).

Model inkremental dibuat untuk mengatasi kelemahan dari model air terjun yang tidak mengakomodasi iterasi, dan mengatasi kelemahan dari metode prototipe yang memiliki proses terlalu pendek dan setiap iteratif prosesnya tidak selalu menghasilkan produk (bisa jadi hanya prototipe). Model inkremental menghasilkan produk/aplikasi untuk setiap tahapan inkremen, Model inkremental merupakan dari model watefall dan model prototipe. Model ini cocok digunakan pengembang dengan turnover staff tinggi.

E.        Model Spiral

Model spiral (spiral model) memasangkan iteratif pada model prototipe dengan kontrol dan aspek sistematik yang diambil dari model air terjun.

Model spiral menyediakan pengembangan dengan cara cepat dengan perangkat lunak yang memiliki versi yang terus bertambah fungsinya (increment).

Model spiral cocok digunakan untuk mengembangkan sistem perangkat lunak berskala besar karena memiliki proses analisis resiko yang dapat sangat meminimalisir resiko yang mungkin terjadi dan dengan target waktu dan biaya yang tidak terlalu mengikat.

Model spiral memungkinkan pengembang untuk menggunakan prototipe pada setiap tahap untuk mengurangi resiko

F.        Model Rakitan Komponen

Teknologi objek yang memberikan kerangka kerja teknis untuk sebuah model proses berbasis komponen bagi rekayasa perangkat lunak, Model ini menggabungkan beberapa karakteristik model spiral, sehingga membutuhkan pendekatan iteratif untuk menciptakan perangkat lunak.

G.       Model Perkembangan Konkuren

Model perkembangan konkuren disebut juga rekayasa konkuren, Model ini dapat disajikan secara skematis sebagai sederetan aktivitas teknis mayor, tugas-tugas dan keadaan yang lain. Kenyataannya model proses konkuren bisa diaplikasikan ke dalam semua tipe perkembangan perangkat lunak dan memberikan gambaran akurat mengenai keadaan tertentu dari sebuah proyek.

4.                Basis Data

4.1.         Ada 7 Pokok Hal Basis Data

·         Pengertian Basis Data

·         DBMS (Database Management System)

·         SQL (Structured Query Language)

·         Alur Hidup Basis Data

·         ERD (Entity Relationship Diagram)

·         CDM (Conceptual Data Model)

·         PDM (Physical Data Model)

4.2.         Pengertian Basis Data

Sekumpulan data dalam file yang saling terhubung (interrelated file), record dalam file harus mengizinkan adanya kerelasian ke record-record lain dalam file yang lain. (J.L. Whitten & L.D Bentley, 1998, dalam Sutanta, 2011: 12)

Sistem Basis Data

Sistem terkomputerisasi yang tujuan utamanya adalah memelihara data yang sudah diolah atau informasi dan membuat informasi tersedia saat dibutuhkan.

4.3.         DBMS

Database Management System (DBMS) dalam bahasa indonesia sering disebut sebagai Sistem Manajemen Basis Data. Suatu sistem aplikasi yang digunakan untuk menyimpan, mengelola, dan menampilkan data.

Contoh : Ms Access, MySQL, Oracle

Syarat minimal DBMS :

1. Menyediakan fasilitas untuk mengelola akses data
2. Mampu menangani integritas data
3. Mampu menangani akses data yang dilakukan secara bersamaan (konkuren)
4. Mampu menangani backup data

4.4.         SQL

SQL (Structured Query Language) adalah bahasa yang digunakan untuk mengelola data pada RDBMS (Relational Database Management System). SQL berkembang pada tahun 1970. SQL mulai digunakan sebagai standar yang resmi pada tahun 1986 oleh ANSI (American National Standards Institute) dan pada tahun 1987 oleh ISO (International Organization for Standardization) dan disebut sebagai SQL-86.

Contoh pengaksesan data pada DBMS dengan SQL yang secara umum terdiri dari 4 hal sebagai berikut :

1. Memasukkan data (insert)
2. Mengubah data (update)
3. Menghapus data (delete)
4. Menampilkan data (select)

4.5.         Alur Hidup Basis Data

Tidak hanya perangkat lunak yang memiliki alur hidup, dalam membuat perencanaan basis data juga memiliki alur hidup atau Database Life Cycle (DBLC). Fase-fase DBLC antara lain :

1. Analisis kebutuhan / Requirement Analysis
1. Didefinisikan dengan mewawancarai produsen dan pemakai data
2. Membuat kontrak spesifikasi basis data
3. Entity Relationship Diagram (ERD)
2. Desain lojik basis data / Logical Database Design

            Membuat rancangan logik basis data (Conceptual Data Model – CDM)

3. Desain fisik basis data / Physical Database Design

            Membuat rancangan fisik basis data (Physical Data Model – PDM)

4. Implementasi
1. Membuat query SQL
2. Aplikasi ke DBMS atau file

4.5.         RRD

Pemodelan awal basis data yang paling banyak digunakan adalah menggunakan Entity Relationship Diagram (ERD). ERD digunakan untuk memodelkan basis data relasional.

Simbol-simbol yang digunakan pada ERD :

4.6.         CDM

CDM (Conceptual Data Model) atau model konseptual data merupakan konsep yang berkaitan dengan pandangan terhadap data yang disimpan dalam basis data. CDM merupakan hasil penjabaran lebih lanjut dari ERD. Aturan-aturan yang harus diikuti dalam melakukan konversi ERD menjadi CDM.

Simbol-simbol yang ada pada CDM :

Simbol	Deskripsi
Entitas/table Nama_tabel	Entitas atau tabel yang menyimpan data dalam basis data
Relasi        1..*             nama relasi        1..*	Relasi antar tabel yang terdiri atas nama relasi dan multiplicity

4.7.         PDM

PDM adalah model yang menggunakan sejumlah tabel untuk menggambarkan data serta hubungan antara data-data tersebut

Simbol PDM :

Simbol	Deskripsi
Tabel	Tabel yang menyimpan data dalam basis data
Relasi	Relasi antar tabel yang terdiri dari persamaan antara primary key (kunci primer) tabel yang diacu dengan kunci referensi acuan di tabel lain

5.                Pemograman Terstruktur

5.1.         Pengertian Pemrograman terstruktur

Konsep atau paradigma atau sudut pandang pemrograman yang membagi-bagi program berdasarkan fungsi-fungsi atau prosedur-prosedur yang dibutuhkan program komputer. Fungsi-fungsi atau prosedur-prosedur ditulis secara sekuensial atau terurut dari atas ke bawah dengan kebergantungan antar fungsi.

5.2.         DFD (Data Flow Diagram)

DFD awalnya dikembangkan oleh Chris Gane dan Trish Sarson pada tahun 1979 yang termasuk dalam Structured Systems Analysis and Design Methodology (SSADM). Sistem yang dikembangkan ini berbasis pada dekomposisi fungsional dari sebuah sistem. Berikut adalah contoh DFD yang dikembangkan oleh Chris Gane dan Trish Sarson.

6.                Pemograman Berorientasi Objek

6.1.         Pengertian Pemograman Berorientasi Objek

Metodologi Berorientasi Objek

Suatu strategi pembangunan perangkat lunak yang mengorganisasikan perangkat lunak sebagai sekumpulan objek yang berisi data dan operasi yang diberlakukan terhadapnya. Metode berorientasi objek meliputi rangkaian aktivitas analisis berorientasi objek, perancangan berorientasi objek, pemrograman berorientasi objek dan pengujian berorientasi objek.

Keuntungan menggunakan metodologi berorientasi objek :

1. Meningkatkan produktivitas
2. Kecepatan pengembangan
3. Kemudahan pemeliharaan
4. Adanya konsistensi
5. Meningkatkan kualitas perangkat lunak

Beberapa bahasa pemrograman yang mendukung pemrograman berorientasi objek:

1. Bahasa Pemrograman Smalltalk
2. Bahasa Pemrograman Eiffel
3. Bahasa Pemrograman C++
4. Bahasa Pemrograman (web) PHP (PHP5)
5. Bahasa Pemrograman Java

6.2.         Konsep Dasar Berorientasi Objek

Pendekatan berorientasi objek merupakan suatu teknik atau pendekatan dalam melihat permasalahan dan sistem (sistem perangkat lunak, sistem informasi). Pendekatan berorientasi objek akan memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata.

7.                Analisis dan Desain Berorientasi Objek

7.1.         OOA

Analisis Berorientasi Objek (Object Oriented Analysis – OOA)

Merupakan tahapan untuk menganalisis spesifikasi atau kebutuhan akan sistem yang akan dibangun dengan konsep berorientasi objek, apakah benar kebutuhan yang ada dapat diimplementasikan menjadi sebuah sistem berorientasi objek.

OOA biasanya menggunakan kartu CRC (Component, Responsibility, Collaborator) untuk membangun kelas-kelas yang akan digunakan menggunakan UML (Unified Modelling Language).

7.2.         OOD

Desain berorientasi objek (Object Oriented Design – OOD) Merupakan tahapan perantara untuk memetakan spesifikasi atau kebutuhan sistem yang akan dibangun dengan konsep berorientasi objek ke desain pemodelan agar lebih mudah diimplementasikan dengan pemrograman berorientasi objek.

Pemrograman berorientasi objek dimodelkan dengan UML (Unified Modelling Language), OOA dan OOD dalam proses yang berulang-ulang seringnya memiliki batasan yang samar, sehingga kedua tahapan ini sering juga disebut OOAD (Object Oriented Analysis and Design).

7.3.         CASE Tools

CASE (Computer Aided Software Engineering) tools atau perangkat pembantu berbasis komputer untuk rekayasa perangkat lunak

Merupakan aplikasi atau perangkat lunak yang membantu pembuatan sebuah sistem perangkat lunak.

CASE Tools mulai digunakan oleh pelaku rekayasa perangkat lunak sejak awak tahun 1980-an dimana fokus pada :

1. Tahap pengumpulan data
2. Desain dan analisis

CASE tools dapat dikelompokkan menjadi dimensi yang berbeda sebagai berikut :

1. Pendukung alur hidup perangkat lunak
2. Dimensi integrasi
3. Dimensi konstruksi
4. Dimensi CASE berbasis keilmuan

7.4.         RUP

RUP (Rational Unified Process)

Pendekatan pengembangan perangkat lunak yang dilakukan berulang-ulang (iterative), fokus pada arsitektur (architecture-centric), lebih diarahkan berdasarkan penggunaan kasus (use case driven).

Setiap iterasi akan menghasilkan produk yang langsung bisa digunakan, dan pada saat itu juga produk tersebut di-analisis kembali untuk menciptakan produk baru dengan versi berbeda. Misalnya : Produk X versi 1.0 (iterasi 1), Produk X versi 1.2 (iterasi 2), demikian seterusnya.

Akhir dari keempat fase ini adalah produk perangkat lunak yang sudah lengkap. Keempat fase pada RUP dijalankan secara berurutan dan iteratif dimana setiap iterasi dapat digunakan untuk memperbaiki iterasi berikutnya

8.                Pemodelan dan UML

8.1.         Kompleksitas Pengembangan Perangkat Lunak

Secara umum, perangkat lunak perlu dikembangkan dengan alasan-alasan sebagai berikut :

1. Adanya permasalahan yang dijumpai pada sistem/perangkat lunak lama
2. Pertumbuhan organisasi
3. Untuk meraih kesempatan-kesempatan
4. Menyesuaikan diri dengan visi, misi, strategi organisasi yang baru

Kompleksitas perangkat lunak dapat dilihat dari hal-hal berikut :

1. Kompleksitas domain atau permasalahan perangkat lunak
2. Kesulitan mengelola proses pengembangan perangkat lunak
3. Kemungkinan fleksibilitas perubahan perangkat lunak
4. Permasalahan karakteristik bagian-bagian perangkat lunak secara diskrit

Karena berbagai masalah dan resiko yang mungkin timbul didalam pengembangan perangkat lunak, maka perlu adanya perencanaan dan pemodelan perangkat lunak.

8.2.         Pemodelan

Pemodelan adalah Gambaran dari realita yang simpel dan dituangkan dalam bentuk pemetaan dengan aturan tertentu. Pemodelan dapat menggunakan bentuk yang sama dengan realitas, misalnya seorang arsitek ingin memodelkan sebuah gedung yang akan dibangun, maka dia akan memodelkannya dengan membuat sebuah maket (tiruan) arsitektur gedung tersebut.

Perangkat pemodelan adalah suatu model yang digunakan untuk menguraikan sistem menjadi bagian-bagian yang dapat diatur dan mengkomunikasikan ciri konseptual dan fungsional kepada pengamat.

Peran perangkat pemodelan :

1. Komunikasi, perangkat pemodelan dapat digunakan sebagai alat komunikasi antara pemakai dengan analis sistem maupun developer dalam pengembangan sistem
2. Eksperimen, pengembangan sistem yang bersifat “trial and error”
3. Prediksi, model meramalkan bagaimana suatu sistem akan bekerja

8.3.         Pengenalan UML

UML muncul karena adanya kebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan, membangun, dan dokumentasi dari sistem perangkat lunak. UML  (Unified Modelling Language) Bahasa Pemodelan.

Tujuan UML diantaranya untuk :

1. Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum
2. Memberikan bahasa pemodelan yang bebas dari berbagai bahasa pemrograman dan proses rekayasa
3. Menyatukan praktek-praktek terbaik (best practice) dalam pemodelan

Pada UML versi 2.3 terdiri dari 13 macam diagram yang dikelompokkan dalam 3 kategori, berikut gambar diagram UML :

Berikut ini penjelasan singkat dari pembagian kategori berikut :

1. Structure Diagrams yaitu kumpulan diagram yang digunakan untuk menggambarkan suatu struktur statis dari sistem yang dimodelkan.
2. Behaviour Diagrams yaitu kumpulan diagram yang digunakan untuk menggambarkan kelakuan sistem atau rangkaian perubahan yang terjadi pada sebuah sistem.
3. Interaction Diagrams yaitu kumpulan diagram yang digunakan untuk menggambarkan interaksi sistem dengan sistem lain maupun interaksi antar subsistem pada suatu sistem.

8.4.         Component Diagram

Diagram komponen atau component diagram dibuat untuk menunjukkan organisasi dan ketergantungan diantara kumpulan komponen dalam sebuah sistem. Diagram komponen fokus pada komponen sistem yang dibutuhkan dan ada di dalam sistem. Diagram komponen juga dapat digunakan untuk memodelkan hal-hal berikut :

1. Source code program perangkat lunak
2. Komponen executable yang dilepas ke user
3. Basis data secara fisik
4. Sistem yang harus beradaptasi dengan sistem lain
5. Framework sistem

Komponen dasar yang biasanya ada dalam suatu sistem adalah sebagai berikut :

1. Komponen user interface yang menangani tampilan
2. Komponen bussines processing yang menangani tampilan
3. Komponen data yang menangani fungsi-fungsi proses bisnis
4. Komponen security yang menangani keamanan sistem

8.5.         Composite Structure Diagram

Diagram ini digunakan untuk menggambarkan struktur dari bagian-bagian yang saling terhubung maupun mendeskripsikan struktur pada saat berjalan (runtime) dari instance yang saling terhubung.

Contoh : Menggambarkan deskripsi dari setiap bagian mesin yang saling terkait untuk menjalankan fungsi mesin tersebut, menggambarkan aliran router pada jaringan komputer.

8.6.         Package Diagram

Package diagram menyediakan cara mengumpulkan elemen-elemen yang saling terkait dalam diagram UML. Hampir semua diagram dalam UML dapat dikelompokkan menggunakan package diagram.

Simbol	Deskripsi
Package	Package merupakan sebuah bungkusan dari satu atau lebih kelas atau elemen diagram UML lainnya

8.7.         Deployment Diagram

Diagram deployment menunjukkan konfigurasi komponen dalam proses eksekusi aplikasi. Diagram deployment juga digunakan untuk memodelkan hal-hal berikut :

1. Sistem tambahan (embedded system) yang menggambarkan rancangan device, node dan hardware
2. Sistem client/server misalnya seperti gambar berikut
3. Sistem terdistribusi murni
4. Rekayasa ulang aplikasi

8.8.         Use Case Diagram

Use Case diagram merupakan pemodelan untuk kelakukan sistem informasi yang akan dibuat. Use Case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang dibuat. Use Case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem dan siapa saja yang berhak menggunakan fungsi-fungsi itu.

Ada 2 (dua) hal utama pada use case yaitu pendefinisian apa yang disebut aktor dan use case :

1. Aktor, merupakan orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi.
2. Use Case, merupakan fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit atau aktor.

8.9.         Activity Diagram

Activity Diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis.Yang perlu diperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan aktor, jadi aktivitas yang dapat dilakukan oleh sistem.

Diagram aktivitas juga banyak digunakan untuk mendefinisikan hal-hal berikut :

1. Rancangan proses bisnis dimana setiap urutan aktivitas yang digambarkan merupakan proses bisnis sistem yang didefinisikan
2. Urutan atau pengelompokkan tampilan dari sistem / user interface dimana setiap aktivitas dianggap memiliki sebuah rancangan antarmuka tampilan
3. Rancangan pengujian dimana setiap aktivitas dianggap memerlukan sebuah pengujian yang perlu didefinisikan kasus ujinya.

8.10.    State Machine Diagram

State machine diagram digunakan untuk menggambarkan perubahan status atau transisi status dari sebuah mesin atau sistem. Perubahan tersebut digambarkan dalam suatu graf berarah.State Machine Diagram merupakan pengembangan dari diagram Finite State Automata dengan penambahan beberapa fitur dan konsep baru.

8.11.    Sequence Diagram

Diagram sekuen menggambarkan kelakuan objek pada use case dengan mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima objek.

Untuk menggambar diagram sekuen perlu diketahui objek-objek yang terlibat didalam sebuah use case beserta metode-metode yang dimiliki kelas yang diinstanisasi menjadi objek itu. Banyaknya diagram sekuen yang harus digambar sesuai dengan pendefinisian use case yang memiliki proses sendiri.

8.12.    Communication Diagram

Communication merupakan penyederhanaan dari diagram kolaborasi, Diagram komunikasi menggambarkan interaksi antar objek/bagian dalam bentuk urutan pengiriman pesan. Diagram merepresentasikan informasi yang diperoleh dari diagram kelas, diagram sekuen, dan diagram use case untuk mendeskripsikan gabungan antara struktur statis dan tingkah laku dinamis dari suatu sistem. Diagram komunikasi mengelompokkan message pada kumpulan diagram sekuen menjadi sebuah diagram.

8.13.    Timing Diagram

Timing diagram merupakan penggambaran yang fokus pada penggambaran terkait waktu. Timing diagram digunakan untuk menggambarkan sistem dalam periode waktu tertentu.Timing diagram biasa digunakan untuk mendeskripsikan operasi dari alat digital karena penggambaran secara visual akan lebih mudah dipahami daripada dengan kata-kata.

8.14.    Interactive Overview Diagram

Interaction overview diagram mirip dengan diagram aktivitas yang berfungsi untuk menggambarkan sekumpulan urutan aktivitas. Interaction overview diagram bentuk aktivitas diagram setiap titik merepresentasikan diagram interaksi Interaksi diagram dapat meliputi diagram sekuen, diagram komunikasi, interaction overview diagram dan timing diagram.

Hampir semua notasi pada interaction overview diagram sama dengan notasi pada diagram aktivitas. Tambahan pada interaction overview diagram adalah interaction occurrence dan interaction element.

9.                Perancangan Pola Berorientasi Objek

9.1.         Design Pattern

Design Pattern / Pola Desain

Merupakan sebuah pola atau cara untuk mendesain komponen-komponen dalam pemrograman berorientasi objek yang baik, sehingga komponen-komponen yang ada dapat digunakan kembali untuk aplikasi lain.

Cara membuat Pola Desain yang baik adalah: Dengan memperhatikan kemungkinan perubahan sistem yang mungkin terjadi di masa mendatang.

Pola yang baik juga memperhatikan :

1. Cohesion à keeratan keterkaitan metode dalam sebuah kelas
2. Coupling à keeratan hubungan antar kelas

9.2.         Anti Pattern

Anti Pattern

Merupakan pola yang dihasilkan dari penelusuran solusi-solusi buruk yang pernah digunakan untuk mencari solusi yang baik.

Langkah-langkah membuat anti pattern yang baik adalah :

1. Tidak menganggap separuh langkah buruk yang sudah ada sebagai bagian sesuatu yang buruk, tapi dipandang sebagai sebuah bagian langkah untuk menghasilkan pola yang positif untuk kedepannya
2. Mencoba mencari tahu apa yang salah dengan pola sebelumnya untuk menghasilkan pola yang baik (menangani pola yang sudah ada).

10.           Manajemen Proyek Perangkat Lunak

10.1.    Pengertian Proyek Perangkat Lunak

Proyek: Merupakan urutan kegiatan yang unik, kompleks, dan saling terkait, memiliki satu tujuan dan urutan harus diselesaikan dalam waktu tertentu sesuai dengan anggaran dan spesifikasi.

Macam-macam Proyek IT yang dapat diperoleh adalah

1.      Pengadaan Perangkat Keras (Hardware)

2.      Pengembangan Perangkat Lunak (Software)

3.      Pemeliharaan Perangkat Lunak (Maintenance)

4.      Konsultasi IT (IT Consulting)

Manajemen Proyek Perangkat Lunak adalah bertujuan agar perangkat lunak yang dibuat sampai ke tangan pelanggan (customer) tepat waktu dan sesuai dengan harapan pelanggan (customer).

10.2.    Perencanaan Proyek

Hal-hal yang harus masuk dalam perencanaan proyek adalah sebagai berikut :

1. Pernyataan kerja yang merepresentasikan produk seperti spesifikasi perangkat lunak, rencana pengujian perangkat lunak, perencanaan kode program perangkat lunak, perencanaan laporan kesalahan/kecacatan (defect) dan semua perencanaan pekerjaan selama proyek berjalan
2. Daftar semua sumber daya (resource) yang dibutuhkan pada rekayasa perangkat lunak beserta ketersediaannya
3. Rincian struktur pekerjaan dan kumpulan perkiraan pekerjaan yang dilakukan selama proses rekayasa perangkat lunak
4. Perencanaan Jadwal dan Biaya Proyek
5. Perencanaan Resiko

10.3.    Pengujian Perangkat Lunak

Perangkat Lunak perlu dijaga kualitasnya, dengan tujuan sebagai berikut :

1. Agar dapat “survive” bertahan hidup di dunia bisnis perangkat lunak
2. Dapat bersaing dengan perangkat lunak lain
3. Penting untuk pemasaran global (Global Marketing)
4. Mengefektifkan biaya agar tidak banyak membuang perangkat lunak karena kegagalan pemasaran atau kegagalan produksi
5. Mempertahankan pelanggan (customer) dan meningkatkan keuntungan

Pengujian merupakan satu set aktifitas yang direncanakan dan sistematis untuk menguji atau mengevaluasi kebenaran yang diinginkan. Pengujian tidak hanya untuk meminimalisasi kesalahan secara teknis tapi juga kesalahan non teknis.

Daftar Pustaka

Shalahuddin, Muhammad dan Rosa Ariani S.. 2011. Modul Pembelajaran Rekayasa Perangkat Lunak (Terstruktur dan Berorientasi Objek). Bandung : Penerbit Modula.