Rekayasa Perangkat Lunak

PENGERTIAN RPL : 

Perangkat lunak merupakan program komputer yang berfungsi sebagai sarana interaksi antara pengguna dan perangkat keras. Selain itu dapat juga dikatakan sebagai ‘penterjemah’ perintah-perintah yang dijalankan pengguna komputer untuk diteruskan ke atau diproses oleh perangkat keras.

A. Atribut Perangkat Lunak yang baik:

Perangkat Lunak seharusnya memberikan pengguna kebutuhan fungsionalitas dan unjuk kerja yang dapat :

• · Maintanability : PL harus dapat memenuhi perubahan kebutuhan
• · Dependability : PL harus dapat dipercaya
• · Efisiensi : PL harus efisien dalam penggunaan sumber daya
• · Usability : PL harus dapat digunakan sesuai dengan yang direncanakan

B. EVOLUSI PERANGKAT LUNAK

Evolusi Perangkat Lunak dibagi menjadi 4 Era yaitu:

1. 1. Era Pioner: sambungan-sambungan kabel ke antar bagian dalam komputer. Cara lain dalam mengakses komputer adalah menggunakan punched card yaitu kartu yang di lubangi. (contoh: ENIAC)
2. 2. Era Stabil: sistem basis data, yang memisahkan antara program (pemroses) dengan data (yang di proses) dan mampu menyelesaikan banyak pengguna (multi user) secara cepat/langsung (real time).
3. 3. Era Mikro: automisasi mengarah ke suatu jenis kecerdasan buatan.
4. 4. Era Modern: tingkat kecerdasan semakin meningkat , mulai bisa mengenal suara dan gambar. Contoh: Telephon, TV, AC

C. MACAM-MACAM PERANGKAT LUNAK

Macam Perangkat Lunak dibagi menjadi 3 bagian yaitu:

1. Perangkat Lunak Sistem

     a. Merupakan software yang mengelola perangkat keras dan perangkat lunak yang digunakan komputer.

     b. Contoh: DOS, Macintosh, Windows, dll

2. Perangkat Lunak Bahasa Pemrograman

• Merupakan software yang berfungsi untuk membantu melakukan pembuatan program aplikasi      komputer.
• Contoh: Visual Basic, C++, dll

3. .Perangkat Lunak Aplikasi

•  Merupakan software yang berfungsi utnuk membantu melakukan berbagai tugas perkantoran/aktivitas   sehari-hari.
•  Contoh: pengolah kata, pengolah gambar, lembar sebar, dll

D. REKAYASA PERANGKAT LUNAK ATAU SOFTWARE ENGINEERING

    Merupakan disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Dalam RPL mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya. Selain itu juga menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang akan dipecahkan, kendala pengembangan dan sumber daya yang tersedia.

Metode Rekayasa Perangkat Lunak:

Merupakan pendekatan terstruktur pengembangan PL termasuk model sistem, notasi, perancangan dan petunjuk pemrosesan. Terdiri dari:

• · Deskripsi Model: deskripsi pemodelan dengan grafik
• · Aturan: batasan yang digunakan pada model sistem
• · Rekomendasi: saran dalam membentuk perancangan yang baik
• · Petunjuk proses: aktifitas yang harus diikuti

E. MITOS SOFTWARE

1. Mitos Manajemen

a.Buku yang lengkap dan banyak sebagai referensi telah cukup untuk pengembangan sebuah software

b.Disediakan komputer terbaru

c.Jika pengembangan terlambat, tambahkan programmer baru

2. Mitos Pelanggan

a.Pernyataan umum sudah dapat digunakan untuk memulai pembuatan program

b.Kebutuhan proyek pengembangan software akan terus berubah, tapi perubahan dapat mudah diatasi

3. Praktisi

a.Sekali menulis programàdapat membuatnya bekerjaà pekerjaan selesai.

b.Untuk menilai kualitas programà membuat sendiri program itu bisa berjalan

c.Hasil akhir dari sebuah proyek à hanyalah dapat berjalan atau tidaknya program

F. SOFTWARE PROCESS

Merupakan serangkaian kegiatan dan hasil-hasil relevannya yang menghasilkan perangkat lunak sebagian besar dilakukan oleh perekayasa perangkat lunak. Ada 4 kegiatan/aktivitas pada proses PL :

• Spesifikasi Perangkat Lunak : Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
• Pengembangan (Perancangan dan Implementasi) Perangkat Lunak: Perangkat lunak yang memenuhi spesifikasi harus di produksi.
• Validasi Perangkat Lunak : Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan.
• · Evolusi Perangkat Lunak: Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.

G. MODEL KONVENSIONAL PROSES PL

Terdapat 4 jenis model, antara lain:

1. Model aliran kerja (workflow): menunjukkan kegiatan pada proses bersama dengan input, output, dan ketergantungannya. Merepresentasikan pekerjaan manusia.
2. Model aliran data (data flow): merepresentasikan proses sebagai suatu set kegiatan yang melakukan transformasi data. Menunjukkan bagaimana input ke proses, misalnya spesifikasi ditransformasi menjadi output, misalnya menjadi desain.
3. Model peran/aksi: merepresentasikan peran orang yang terlibat pada PL dan kegiatan yg menjadi tanggung jawab mereka.
4. Model air terjun (waterfall): Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.

H. MODEL EVOLUSIONER

Model ini bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses. Selain itu tidak ada kegiatan spesifikasi, pengembangan, dan validasi yang terpisah. Kegiatan tersebut dilakukan pada saat yang bersamaan dengan umpan balik yang cepat untuk masing-masing kegiatan.

Gambar 1. Model Evolusioner

Kelebihan:

• § Lebih efektif dari pendekatan air terjun dalam menghasilkan sistem yang dibutuhkan
• § user mendapat pemahaman yang lebih baik dari masalah mereka

Kekurangan:

• § Tidak ada visibilitas proses
• § Sistem biasanya tidak terstruktur dengan baik
• § Kemampuan khusus (misalnya bahasa untuk
• § Prototipe cepat) kemungkinan diperlukan

Aplikasi:

• § Untuk sistem interaktif berukuran kecil atau medium
• § Untuk bagian dari sistem besar (misalnya user interface)
• § Untuk sistem dengan daur hidup pendek
• Terdapat 2 jenis model evolusioner yaitu:

1. Pengembangan Eksplotari

Tujuan: bekerja dengan pelanggan untuk menyelidiki persyaratan mereka dan mengirimkan sistem akhir.

Obyektif : bekerja dengan konsumen dan melibatkan sistem akhir dari spesifikasi skema inisial. Dimulai dengan kebutuhan yang dimengerti dengan baik.

2. Prototipe yang dapat dibuang (throw-away) à

Berkonsentrasi pada eksperimen, dengan persyaratan pelanggan yang tidak dipahami dengan baik.

Obyektif : mengerti kebutuhan sistem. Dimulai dengan kebutuhan yang tidak dimengerti dengan baik.

Selain 2 model di atas, masih terdapat 2 jenis model berdasarkan Mills dan Boehm yaitu:

1.  Incremental Model (Original: Mills)

Berdasarkan model sistem yang dipecah sehingga model pengembangannya secara increment/bertahap.

Masalah :

1) cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)

2) mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment

Gambar 2. Incremental Model

2. Spiral Model (Original: Boehm)

• · Setiap loop mewakili satu fase dari software process.
• · Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya

Masalah :

Membutuhkan waktu yang cukup panjang , sehingga waktu yang lama sama dengan biaya yang lebih besar.

3. Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

• · Penentuan dan analisis spesifikasi : Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.
• · Desain sistem dan perangkat lunak : Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan.
• · Implementasi dan ujicoba unit :  Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.
• · Integrasi dan ujicoba sistem : Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke kastamer
• · Operasi dan pemeliharaan : Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.

Gambar 1. Pemodelan Waterfall

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

1.  Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini :

1) Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti.

Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.

Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.

Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk

2) Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan, tidak terlalu mahal.

3) Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

4) Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe).

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya.

Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

------------------------------------------------------------------------------------------------------------

1. Model Waterfall

Biasa juga disebut siklus hidup perangkat lunak. Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.

Keterangan di atas adalah sebagai berikut :

Analisis dan Definisi Persyaratan : Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem.

Perancangan sistem dan Perangkat Lunak : Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Menentukan arsitektur sistem secara keseluruhan.

Implementasi dan pengujian unit : Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.

Integrasi dan Pengujian Sistem : Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim ke User.

Operasi dan Pemeliharaan : Biasanya merupakan fase siklus yg paling lama (walaupun tidak seharusnya). Sistem diinstall dan di pakai. Pemeliharaan mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap-tahap sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.

Kekurangan model waterfall:

• · Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.
• · Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna (user).
• · Model air terjun harus digunakan hanya ketika persyaratan dipahami dengan baik.

2. Model RAD

• · RAD adalah model proses pembangunan PL yang incremental.
• · RAD menekankan pada siklus pembangunan yang pendek/singkat.
• ·RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction.
• · Waktu yang singkat adalah batasan yang penting untuk model ini.
• · Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.

Kelemahan model RAD:

• · Tidak cocok untuk proyek skala besar
• · Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
• · Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini
• · Resiko teknis yang tinggi juga kurang cocok untuk model ini