Rekayasa Perangkat Lunak 1. Pendahuluan RPL ... - WordPress.com

Rekayasa Perangkat Lunak Prosess, Metode dan Peralatan

2

1. Pendahuluan RPL merupakan teknologi layer Menurut IEEE, RPL adalah : Aplikasi yang pendekatannya sistematis, disiplin, bisa terukur untuk pengembangan operasional dan pembuatan software.

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

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

Problem apa yang harus dicarikan solusinya ? Apa saja karakteristik entitas yang digunakan untuk menyelesaikan persoalan tersebut. Bagaimana entitas (dan solusinya) dapat direalisasikan ? Bagaimana entitas akan dibangun ? Pendekatan apa yang akan digunakan untuk mencegah terjadinya kesalahan desain dan pembuatan entitas? 1

Bab 2 | Proses Metode dan Peralatan | reviewed by Donny Ariwibowo, S.Kom

Rekayasa Perangkat Lunak •

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: •

•

•

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. 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: • Desain software • Pembuatan Program • Pengujian Software Maintenance Phase Difokuskan pada perubahan sehubungan dengan adanya koreksi kesalahan, adaptasi dan pengembangan yang dikehendaki customer. Ada 4 tipe perubahan: 1. Correction Mengubah software untuk memperbaiki kesalahan-kesalahan yang ada. 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


Rekayasa Perangkat Lunak 3. Proses Software

Frame Work Activities Task Sets Milestone, Deliverable Task SQA Points Umbrella Activities

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.

3


Rekayasa Perangkat Lunak 4. Model Proses Software 4.1. Linier Sequencial Model Kadang-kadang disebut “Classic Life Cycle” atau “Waterfall model”.

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


Rekayasa Perangkat Lunak Pendekatan pengembangan software dimulai pada level sistem dan prosesnya melalui: •

•

• •

•

Analysis 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. Design 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. Coding Berdasarkan desain yang ada, dilakukan translasi ke bentuk yang bisa dibaca “Mesin”. Testing 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. Maintenance 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. 2. 3. 4.

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

5


Rekayasa Perangkat Lunak

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

Build/Revise mackup Listen to Customer

Customer test-drives Mackup 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 •

•

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

6



4.3. 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 pengembangannya dilakukan dengan menggunakan pendekatan komponen-based.

yang

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.

7



Team 1

Team 2

Business Modeling

Team 3

Business Modeling

Data Modeling

Business Modeling Data

Data

Modeling

Modeling

Process

Process

Process

Modeling

Modeling

Modeling

Application Modeling

Application Modeling Testing & Turnover

Application Modeling Testing & Turnover

Testing & Turnover

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.

8



4.4.

The Incremental Model

System/Information Enginering Increment 1 Analysis

Design

Code

Test

Delivery of 1st increment

Increment 2 Analysis

Design

Code

Test

Delivery of 2nd increment


Design

Code

Test

Delivery of 3rd increment


Design

Code

Test

Delivery of 4th increment

Calendar Time

4.5. SPIRAL MODEL Model spiral dibagi menjadi beberapa framework activities : • •

• • •

•

Customer Communications Dibutuhkan untuk menghasilkan komunikasi yang efektif antara developer dan customer Planning Dibutuhkan untuk mendefinisikan resource, time line dan info lainya yang berhubungan dengan proyek. Risk Analysis Untuk mengetahui resiko management dan teknis yang akan terjadi. Enginering Untuk membangun representasi aplikasi. Construction & Release Untuk membangun, menguji, menginstall dan menghasilkan “user support” (misal: dokumentasi, training). Customer Evaluation Untuk mendapatkan masukan dari customer berdasarkan evaluasi representasi software pada saat itu.

9


Rekayasa Perangkat Lunak 4.6. COMPONEN ASSEMBLY MODEL Model ini membangun aplikasi dari pre package software component (atau class). Identifikasi calon komponen

Cari komponen di library

Ekstrak jika ada

Letakkan komponen baru di library

Bangun komponen jika tidak ada

Bangun Iterasi Sistem

4.7. CONCURRENT DEVELOPMENT MODEL Model ini dapat direpresentasikan secara sistematis sebagai sederatan aktifitas teknis utama, pekerjaan dan state berikutnya. None

Analysis activities:

Under Development

Under Riview

A Waiting Changes

Under Revision

Based Line

Done

Salah satu model Proses Konkuren : Menyatakan software Enginered activity 10


Rekayasa Perangkat Lunak 4.8.

FORMAL METHODS MODEL

Model ini jarang sekali digunakan, sedangkan sederetan aktifitas dinyatakan dalam bentuk matematik 4.9.

FOURTH GENERATION TECHNIQUES

Dengan cara ini, memungkinkan untuk menyatakan karakteristik software pada level yang lebih tinggi. Source code dapat secara otomatis dihasilkan berdasarkan spesifikasi developer.

11


Rekayasa Perangkat Lunak Referensi 1. Roger S Pressman, "Software Enginering: A Practitioners Approach" 2. Bob Hughes, "Software Project Management"

12
