BAB II PROSES

2.1. PENDAHULUAN
RPL(rekayasa Perangkat Lunak) merupakan teknologi layer

Menurut IEEE, RPL adalah :

Aplikasi yang pendekatannya sistematis, disiplin, bisa terukur untuk pengembangan operasional dan    pembuatan software.

2.

2.2. PROSES, METODE DAN PERALATAN.

Tools
Methods
Process
A Quality Focus

�         Pondasi RPL adalah lapisan proses, karena terkait dengan teknologi dan waktu pengembangan.

Proses mendefinisikan framework key prosess Are (KPA) yang harus dibuat untuk penekanan teknologi RPL yang efektif.

�   Metode RPL memberikan teknik bagaimana membangun software.

Yang termasuk metode:

Analisa, desain, pembuatan program, pengujian dan perawatan.

�  Tool pad RPL digunakan untuk memberikan dukungan otomatisasi atau semi otomatis pada proses dan metode. Sistem yang biasa digunakan untuk mendukung  pengembangan disebut Computer Aided Software Enginering (CASE). CASE mengkombinasikan software, hardware dan database RPL (berisi informasi mengenai analisa, desain, pembuatan program dan pengujian).

Hal-hal Umum RPL

Rekayasa adalah analisa, desain, pembuatan, verifikasi dan manajemen teknis (atau sosial). Tanpa memandang entitas yang harus direkayasa, ada beberapa pertanyaan yang harus dijawab:

1.     Problem apa yang harus dicarikan solusinya ?
2.     Apa saja karakteristik entitas yang digunakan untuk menyelesaikan persoalan tersebut.
3.     Bagaimana entitas (dan solusinya) dapat direalisasikan ?
4.     Bagaimana entitas akan dibangun ?
5.     Pendekatan apa yang akan digunakan untuk mencegah terjadinya kesalahan desain dan pembuatan entitas?
6.     Bagaimana entitas akan didukung selama mungkin, pada saat ada permintaan koreksi, adaptasi dan    pengembangan oleh user.

Pekerjaan yang berhubungan dengan RPL bisa dikategorikan ke dalam 3 fase umum tanpa memandang area aplikasi, ukuran proyek atau kompleksitas. Fase tersebut yaitu:

1.      Definition Phase
2.      Development Phase
3.      Maintenance Phase

1.  Definition Phase

Selama fase ini, software developer berusaha untuk mengidentifikasi informasi apa saja yang harus diproses,    apa saja fungsi dan kinerja yang digunakan, tingkah laku sistem yang diharapkan, apa saja interface yang harus dibuat, apa saja kendala desain yang ada, dan kriteria validasi yang diperlukan untuk mendefinisikan kesuksesan sistem.

2.  Development Phase

Selama fase ini, software developer berusaha untuk mendefinisikan bagaimana data disusun, bagaimana fungsi bisa diimplementasikan sesuai dengan arsitektur software, bagaimana prosedur detil untuk implemetasi , bagaimana karakter interface, bagaimana hasil desain bisa ditranslasikan ke bahasa pemrograman dan bagaimana cara pengujiannya.

Ada tiga aktivftas teknis yang selalu terjadi:

1.      Desain software
2.      Pembuatan Program
3.      Pengujian Software

3.  Maintenance Phase

Difokuskan pada perubahan sehubungan dengan adanya koreksi kesalahan, adaptasi dan pengembangan yang dikehendaki customer.

Ada 4 tipe perubahan:

1.   1. Correction

Mengubah software untuk memperbaiki kesalahan-kesalahan yang ada.

2.    2. Adaption

Modifikasi yang dilakukan terhadap software dikarenakan adanya perubahan lingkungan eksternal (misal: CPU, sistem operasi, aturan bisnis, karakter produk eksternal).

3.  Enhancement

Pada saat sofrware dipakai, user meminta tambahan-tambahan fungsi. Sehingga software dikembangkan dari kebutuhan semula.

4.  Prevention

Sering disebut software re-enginering, harus dilakukan untuk memungkinkan software bisa sesuai dengan keinginan end user. Pada fase ini dilakukan perubahan-perubahan ke program komputer, sehingga program tersebut bisa dikoreksi, beradaptasi dan dikembangkan dengan mudah.

2.3. PROSES SOFTWARE

Keterangan Gambar:

�   Sebuah �common process Network� di bentuk dengan mendefinisikan sejumlah �framework activities� yang bisa diterapkan  untuk semua proyek software, tanpa memandang ukuran dan kompleksitasnya.

�   �Task Sets�, masing-masing berisi kumpulan pekerjaan rekayasa software, project milestone, product software dan deriverable, quality assurance point.

Dengan adanya task set ini, memungkinkan aktifitas framework diadaptasikan dengan karakteristik proyek software dan kebutuhan tim pelaksana.

�   �Umbrella Activities� seperti software quality assurance, manajemen konfigurasi software.

2.4. MODEL PROSES SOFTWARE

LINIER SEQUENCIAL MODEL

Kadang-kadang disebut �Classic Life Cycle� atau �Waterfall model�.

Pendekatan pengembangan software dimulai pada level sistem dan prosesnya melalui:

�         Analysis
�         Design
�         Coding
�         Testing
�         Maintenance

Aktifitasnya:

�  Rekayasa dan Pemodelan Sistem/Informasi

Pekerjaan dimulai dengan mengumpulkan semua kebutuhan elemen sistem. Hal ini penting terutama pada saat sistem melakukan antarmuka dengan elemen lain,  seperti hardware, orang dan database.

Pekerjaan ini dilakukan pada level sistem dengan sejumlah analisa dan desain top level. Kebutuhan rekayasa informasi dilakukan pada level strategi bisnis dan area bisnis.

�  Analisa Kebutuhan Software

Untuk memahami program yang harus dibuat, analis harus mengetahui domain informasi untuk software tersebut seperti:

–         Fungsi
–         Tingkah Laku
–         Kinerja
–         Antarmuka

Kebutuhan sistem dan software dokumentasi didiskusikan dengan customer.

�  Desain

Desain software ini sebenarnya merupakan proses beberapa tahap yang difokuskan pada 4 atribut yang berbeda dari sebuah program yaitu:

–         Struktur Data
–         Arsitektur software
–         Tampilan antarmuka
–         Algoritma (prosedur)

Desain ini didokumentasikan dan menjadi bagian dari konfigurasi software.

�  Pembuatan program

Berdasarkan desain yang ada, dilakukan translasi ke bentuk yang bisa dibaca �Mesin�.

�  Pengujian

Setelah program dibuat, maka dilakukan pengujian program. Pengujian difokuskan pada:

�   Logika internal software (untuk menjamin semua statement telah diuji).

�   Fungsi eksternal test untuk menguji jikalau terjadi kesalahan.

�  Perawatan

Perubahan mesin mungkin terjadi setelah software diserahkan ke customer. Perubahan tersebut antara lain:

�        Terjadi error
�        Terjadi perubahan lingkungan eksternal (misal: sistem operasi baru atau peralatan baru).
�        Kebutuhan peningkatan fungsional.
�        Peningkatan kinerja.

Problem pada Model Linier Sequencial

  1. Jarang sekali proyek yang prosesnya bisa dilakukan secara sequencial.
  2. Sukar bagi customer untuk secara explicit mengemukakan semua kebutuhannya.
  3. Customer harus sabar.
  4. Developer sering menunda pekerjaan. Anggota tim harus menunggu anggota lainnya menyelesaikan tugasnya.

THE PROTOTYPE MODEL

Sering terjadi customer menjabarkan objectif umum mengenai software yang diminta, tetapi tidak bisa mendefinisakan input, proses, output yang diminta secara detail.

Disisi lain, developer menjadi tidak yakin terhadap efisiensi algoritma, kemampuan adaptasi terhadap sistem operasi, atau bentuk interaksi mesin dengan orang. Untuk mengatasi situasi tersebut, bisa digunakan pendekatan

Prototype Paradigm.

Keterangan Gambar:

�   Prototype Paradigm dimulai dengan mengumpulkan kebutuhan-kebutuhan customer.

Developer dan customer bertemu dan mendefinisikan obyektif software secara menyeluruh, mengidentifikasi kebutuhan-kebutuhan yang diketahui dari area pekerjaan.

�   Setelah itu dibuat �Quick Design�. Quick Design difokuskan pada representasi aspek software yang bisa dilihat customer/user (misal: format input dan output).

Quick Design cenderung ke pembuatan prototipe.

�   Prototipe dievaluasi customer/user dan digunakan untuk menyempurnakan kebutuhan software yang akan dikembangkan.

Kelemahan Prototyping Model

1.  Customer melihat prototipe tersebut sebagai versi dari software tersebut. Pada saat produk tersebut harus dibangun ulang supaya level kualitas  bisa terjamin, customer akan mengeluh dan meminta �sedikit perubahan� saja supaya prototipe tersebut bisa berjalan.

2.  Development membuat implemetasi yang kompromitas dengan tujuan untuk memperoleh prototipe pekerjaan secara cepat. Dampaknya adalah sistem operasi atau bahasa pemrograman yang dipergunakan tidak tepat, algoritma tidak efisien.

THE RAD MODEL

Rapid Application Development (RAD) merupakan model proses pengembangan software yang linier sequencial yang menggunakan siklus pengembangan yang singkat.

Model RAD merupakan adaptasi �High-speed� dari model linier sequencial yang pengembangannya dilakukan dengan menggunakan pendekatan komponen-based.

Proses RAD memungkinkan untuk membuat �fully functional System� dalam waktu yang sangat singkat (60 � 90 hari).

Pendekatan RAD melalui beberapa fase:

Business Modeling

Aliaran informasi fungsi bisnis dimodelkan untuk bisa menjawab pertanyaan sebagai berikut:

1.      Informasi apa yang dibutuhkan proses bisnis ?

2.      Informasi apa saja yang dihasilkan ?

3.      Siapa yang membuat informasi tersebut ?

4.      Informasi itu dibutuhkan siapa saja ?

5.      Siapa yang memproses informasi tersebur ?

Data Modelling

Aliran informasi yang telah didefinisikan disempurnakan lagi menjadi kumpulan object data, yang   dibutuhkan untuk mendukung sistem tersebut.

Karakteristik (Atau atribut) masing-masing object diidentifikasi dan relasi antara object tersebut didefinisikan.

Proses Modelling

Object data yang telah didefinisikan ditransformasi untuk mendapatkan aliran informasi yang mungkin    mengimplementasikan fungsi bisnis.

Deskripsi proses dibuat untuk menambah, modifikasi, penghapusan, atau pencarian object data.

Application Generation

Pekerjaan proses RAD dilakukan dengan menggunakan kembali komponen program yang sudah ada (jika memungkinkan) atau membuat komponen yang bisa dipergunakan kembali (jika memungkinkan). Untuk itu, dibutuhkan �automated tool� untuk pembuatan software tersebut.

Testing & Turnover

Karena proses RAD mempergunakan kembali komponen yang sudah ada, maka beberapa komponen program telah teruji. Hal ini bisa mengurangi waktu pengujian secara keseluruhan, akan tetapi komponen harus tetap di uji.

Business Modeling
Data Modeling
Proses Modeling
Application Modeling
Testing & Turnover
Business Modeling
Data Modeling
Proses Modeling
Application Modeling
Testing & Turnover
Business Modeling
Data Modeling
Proses Modeling
Application Modeling
Testing & Turnover
Team #1
Team #2
Team #3
60 � 90 days

Kelebihan RAD:

Dibuat dalam komponen..

Kelemahan Model RAD:

Untuk proyek dengan skala besar, RAD memerlukan jumlah orang yang lebih banyak untuk membentuk sejumlah tim RAD.
RAD memerlukan developer dan customer yang Commit terhadap aktifitas yang ketat sesuai dengan time frame yang diberikan.
RAD tidak cocok pada saat resiko teknis tinggi. Hal ini bisa terjadi pada saat aplikasi baru menggunakan teknologi baru atau pada saat software yang baru memerlukan derajat kebergantungan yang tinggi terhadap program komputer yang sudah ada.

Satu Tanggapan

  1. MAKASIH

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: