Metodologi Pengembangan Perangkat Lunak


Tujuan :

  1. Mahasiswa dapat mengetahui dan memahami pengertian dari metodologi pengembangan perangkat lunak.
  2. Mahasiswa dapat mengetahui dan memahami salah satu metodologi dan perangkat lunak yang dipakai, yaitu RUP (Rational Unified Process).

Teori :

Metode adalah suatu cara atau teknik yang sistematik untuk mengerjakan sesuatu. Metodologi adalah kesatuan, metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan dan postulat-postulat yang digunakan oleh suatu ilmu pengetahuan, seni atau disiplin ilmu lainnya.

Sehingga pengertian dari metodologi pengembangan perangkat lunak adalah metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan dan postulat-postulat yang akan digunakan untuk mengembangkan suatu sistem informasi dengan menggunakan suatu perangkat lunak tertentu.

Dalam mengembangkan suatu sistem informasi tersebut, perlu digunakan suatu metodologi dan perangkat lunak yang dapat digunakan sebagai pedoman bagaimana dan apa yang harus dikerjakan selama pengembangan tersebut. Salah satu metodologi dan perangkat lunak yang dipakai adalah RUP (Rational Unified Process), yang dikeluarkan oleh Rational Software.

RUP adalah sebuah perangkat lunak untuk proses  pembangunan sistem. RUP juga  dapat membuat atau menciptakan suatu metodologi yang dapat dilakukan berulang-ulang untuk menghasilkan mutu atau kualitas yang tinggi.

Langkah-langkah RUP adalah :

  1. Permulaan (Inception)
  2. Pengembangan (Elaboration)
  3. Pembangunan (Construction)
  4. Transisi (Transition)

Untuk membuat integrasi baru dalam bahasa pemodelan antar tool dan proses dalam RUP ini dibuatlah UML (Unified Modeling Language).

UML adalah sebuah bahasa untuk menentukan, memvisualisasi, membangun dan mendokumentasikan artifacts (bagian dari informasi yang digunakan atau dihasilkan oleh proses pembuatan perangkat lunak, artifact tersebut dapat berupa model, deskripsi atau perangkat lunak) dari sistem perangkat lunak, seperti pada pemodelan bisnis dan sistem non perangkat lunak lainnya [HAN98].

Selain itu, UML adalah bahasa pemodelan yang menggunakan konsep orientasi object. UML dibuat oleh Grady Booch , James Rumbaugh , dan Ivar Jacobson di bawah bendera Rational Software Corp [HAN98]. UML menyediakan notasi-notasi yang membantu memodelkan sistem dari berbagai perspektif. UML tidak hanya digunakan dalam pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan. UML juga merupakan suatu kumpulan teknik terbaik yang telah terbukti sukses dalam memodelkan sistem yang besar dan kompleks.

Tujuan Penggunaan UML :

1. Memberikan model yang siap pakai, bahasa pemodelan visual 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 yang terdapat dalam pemodelan.

Bagian-bagian dari UML

Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.

a.  View

View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram. Beberapa jenis view dalam UML antara lain: use case view, logical view, component view, concurrency view, dan deployment view.

‘  Use case view

Use-case view membantu untuk memahami dan menggunakan sistem yang dimodelkan. View melihat bagaimana actor dan use-case berinteraksi. Terdapat beberapa diagram yang digunakan dalam use-case view, yaitu : use-case diagram, sequence diagram, collaboration diagram, dan activity diagram.

‘    Logical view

Logical view mengarah pada persyaratan (requirements) fungsional sistem. View ini melihat pada kelas-kelas dan hubungan antar kelas-kelas tersebut. Diagram dalam view ini adalah : class diagram, sequence diagram, collaboration diagram, dan statechart diagram.

‘    Component view

Component view mengarah pada pengaturan perangkat lunak. View ini mengandung informasi mengenai komponen-komponen perangkat lunak, komponen tereksekusi (executable), dan library untuk sistem yang dimodelkan. Hanya ada satu jenis diagram yang ada di component view ini, yaitu component diagram.

‘     Concurrency view

Concurrency view membagi sistem ke dalam proses dan prosesor. View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

‘    Deployment view

Deployment view memperlihatkan pemetaan setiap proses ke dalam perangkat keras. View ini paling bermanfaat ketika akan membuat model sistem yang diterapkan dalam lingkungan arsitektur yang terdistribusi dan menerapkan aplikasi dan server pada lokasi yang berbeda. View ini hanya memiliki satu diagram, yaitu deployment diagram.

b. Diagram

Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain :

‘     Use Case Diagram

Menggambarkan sejumlah external actors dan hubungannya ke use case yang diberikan oleh sistem. Use case adalah deskripsi fungsi yang disediakan oleh sistem dalam bentuk teks sebagai dokumentasi dari use case symbol namun dapat juga dilakukan dalam activity diagrams. Use case digambarkan hanya yang dilihat dari luar oleh actor (keadaan lingkungan sistem yang dilihat user) dan bukan bagaimana fungsi yang ada di dalam sistem.

‘     Class Diagram

Menggambarkan struktur statis class di dalam sistem. Class merepresentasikan sesuatu yang ditangani oleh sistem. Class dapat berhubungan dengan yang lain melalui berbagai cara : associated (terhubung satu sama lain), dependent (satu class tergantung/menggunakan class yang lain), specialed (satu class merupakan spesialisasi dari class lainnya), atau package (grup bersama sebagai satu unit). Sebuah sistem biasanya mempunyai beberapa class diagram.

‘     Sequence Diagram

Menggambarkan kolaborasi dinamis antara sejumlah object. Kegunaanya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antara object, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.

‘     Collaboration Diagram

Menggambarkan kolaborasi dinamis seperti sequence diagrams. Dalam menunjukkan pertukaran pesan, collaboration diagrams menggambarkan object dan hubungannya (mengacu ke konteks). Jika penekannya pada waktu atau urutan kejadian gunakan sequence diagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram.

‘     Activity Diagram

Menggambarkan rangkaian aliran dari aktivitas dan digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use case atau interaksi.

‘     Statechart Diagram

Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim pesan. State class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda. Statechart diagram khususnya digunakan untuk memodelkan tarap-tarap diskrit dari sebuah siklus hidup objek, sedangkan activity diagram paling cocok digunakan untuk memodelkan urutan aktivitas dalam suatu proses.

Component Diagram

Menggambarkan struktur fisik kode dari komponen. Komponen dapat berupa source code, komponen biner, atau executable component. Sebuah komponen berisi informasi tentang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view.

‘     Deployment Diagram

Menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes, executeable component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

Untuk praktikum Metodologi Pengembangan Perangkat Lunak modul yang pertama ini, aplikasi dari UML dibuat menggunakan perangkat lunak (software) yang dinamakan DIA Diagram.

Langkah-langkah untuk membuka perangkat lunak (software) DIA adalah sebagai berikut :

Dari Start, klik Program, Programming, cari program DIA, klik DIA. Maka akan tampil sebagai berikut :

Setelah itu, dari menu Assorted, cari UML, seperti dibawah ini :

Jika UML sudah diketemukan, maka kita akan bisa mengaplikasikan View, diagram, package, relasi dan lain-lain bagian dari UML dari program DIA ini.

Contoh  dibawah ini adalah Aplikasi dari USE CASE DIAGRAM :

Komponen-komponen yang terdapat didalam Use Case Diagram adalah :

  1. a. Actor

Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Actor digambarkan dengan stick man.. Actor dapat digambarkan secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship. Notasi UML untuk actor adalah :

a. Use Case

Use case merupakan bentuk fungsionalitas dari suatu sistem. Use case juga merupakan dialog antara actor dan sistem.

Cara menentukan use case pada sistem:

  • Pola perilaku perangkat lunak aplikasi
  • Gambaran tugas dari sebuah actor
  • Sistem atau benda yang memberikan sesuatu yang bernilai kepada actor
  • Apa yang dikerjakan oleh suatu perangkat lunak

.    Relasi dalam Use Case

Ada beberapa relasi yang terdapat pada use case diagram :

–          Association, menghubungkan link antar elemen.

–          Generalization, disebut juga inheritance (pewarisan) artinya sebuah elemen merupakan spesialisasi dari elemen lain.

–          Dependency, elemen bergantung dalam beberapa cara pada elemen lain.

–          Aggregation, merupakan bentuk asosiasi, dimana elemen dapat berisi elemen lain.

Tipe relasi/stereotype antara lain:

–          <<include>> yaitu perilaku yang harus terpenuhi agar sebuah event dapat terjadi, pada kondisi ini use case menjadi bagian dari use case lainnya.

–           <<extends>> yaitu perilaku yang hanya berjalan pada kondisi tertentu, misal : jam alarm.

–          <<communicates>> biasanya ditambahkan untuk asosiasi yang menunjukkan asosiasinya yaitu communicates association.

Cara untuk membuat relasi dalam Use Case pada DIA adalah :

Klik gambar , sesuaikan.

Maka, jika semua itu sudah dikerjakan, didapatkan gambar seperti di bawah ini :

      ~ oleh 12puby pada 9 Juni 2010.

      4 Tanggapan to “Metodologi Pengembangan Perangkat Lunak”

      1. Endi dap definisi MPPl nya ??????????????????

      2. halo semua salam kenal ya…. numpang nyelip nih…ane lagi TA ,mohon bantuannya nih buat isi survey ane. 3 menit aja.. ga lama2 ko.
        survey nya tentang metodologi pegembangan software. silakan diisi ya. trims… oh ia buat yang uda isi dan ngebantu nyebarin survei ini trims ya…..
        http://www.surveymonkey.com/s/YF5H5ZF

      3. bagaimana cara agar bsa muter lagu lngsung,tmpa loading.dweb apa skriptnya dan alamat link lagunya

      Tinggalkan Balasan

      Isikan data di bawah atau klik salah satu ikon untuk log in:

      Logo WordPress.com

      You are commenting using your WordPress.com account. Logout / Ubah )

      Gambar Twitter

      You are commenting using your Twitter account. Logout / Ubah )

      Foto Facebook

      You are commenting using your Facebook account. Logout / Ubah )

      Foto Google+

      You are commenting using your Google+ account. Logout / Ubah )

      Connecting to %s

       
      %d blogger menyukai ini: