Proses pengembangan perangkat lunak (Software development process)

Proses pengembangan perangkat lunak (Software development process) adalah suatu struktur yang diterapkan pada pengembangan suatu produk perangkat lunak yang bertujuan untuk mengembangkan sistem dan memberikan panduan yang bertujuan untuk menyukseskan proyek pengembangan sistem melalui tahap demi tahap.^[1] Proses ini memiliki beberapa model yang masing-masing menjelaskan pendekatan terhadap berbagai tugas atau aktivitas yang terjadi selama proses. Contoh model proses pengembangan perangkat lunak antara lain adalah proses iteratif, Extreme Programming, serta proses air terjun (waterfall).

Metode System Development Life Cycle (SDLC)

Systems Development Life Cycle, atau SDLC (Daur hidup pengembangan sistem) adalah proses yang digunakan oleh analis sistem untuk menggembangkan sistem informasi, mulai dari penentuan kebutuhan, perancangan, validasi, sampai pelatihan dan penyerahan kepada konsumen.

SDLC merupakan alur kerja baku yang biasa dipakai oleh perusahaan-perusahaan vendor software dalam mengembangkan software aplikasi produksinya. SDLC ini tidak hanya penting untuk proses produksi software saja, namun terlebih juga sangat penting untuk proses maintenance software itu sendiri, karena tanpa pengarsipan data-data development suatu software, maka akan sangat menyulitkan perusahaan dalam maintenance software tersebut dikemudian hari.


SDLC ini seharusnya dapat menghasilkan suatu sistem aplikasi yang sesuai dengan harapan konsumen, dapat diselesaikan dalam waktu dan biaya yang telah ditentukan, dapat berjalan efektif dan efisien dalam infrastrukur teknologi informasi sekarang dan pada masa yang akan datang. Sistem juga harus mudah untuk dikembangkan untuk merespon berbagai kebutuhan organisasi/perusahaan pemakainya.

Model – model proses untuk software engineering seperti model sekuensial  linier, model prototipe, model RAD, model inkremental, model spiral, model  asembli komponen, model pengembangan kongkuren, model metode formal, model teknik generasi keempat.

Linear sequential model (classic life cycle / model cycle)

  Model yang paling luas dipakai dan tertua. Mengusulkan suatu pendekatan sekuensial dan sistematis pada pengembangan PL. Meliputi aktivitas-aktivitas : 

• System / information engineering (rekayasa dan pemodelan sistem) : menyangkut pengumpulan kebutuhan (requirement gathering) pada level sistem dengan sejumlah kecil analisis serta top desain.
 
• Analisis : kebutuhan PL, proses requirement gathering diintesifkan dan difokuskan, khususnya pada PL. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan sistem maupun PL didokumentasikan dan direview bersama user.
 
• Desain : fokus pada 4 hal : desain database, arsitektur PL, interface, dan algoritma prosedural. Proses desain menerjemahkan kebutuhan ke dalam representasi PL sebelum dimulai coding.
 
• Coding : menerjemahkan desain ke dalam bahasa yang dimengerti mesin.
 
• Testing : fokus pada :
 
• Logika internal PL : memastikan bahwa semua statement telah diuji
   
• Fungsi eksternal : mengarahkan testing untuk menemukan kesalahan-kesalahan dan memastikan bahwa input yang diberikan akan menghasilkan output sesuai yang diinginkan.
   
• Maintenance
         
         
 

Kelemahan model :     

• Meskipun mengakomodasi iterasi, model linier melakukannya secara tidak langsung sehingga perubahan-perubahan dapat menyebabkan keraguan saat tim proyek berjalan
     
• Jika user sulit menyatakan semua kebutuhannya secara explisit, model ini sulit mengakomodasi ketidakpastian itu
     
• User harus bersabar karena hasil baru bisa dinikmati setelah testing (akhir waktu). Jika ada kesalahan besar yang tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.
     
• Pengembang sering melakukan penundaan yang tidak perlu. Anggota tim harus menunggu anggota tim lain selesai mengerjakan tugasnya yang mempunyai keterkaitan dan ketergantungan tinggi.

  Meski memiliki kelemahan, model ini masih lebih baik daripada pendekatan yang sembrono / sembarangan. 
Contoh : model Waterfall terdiri dari fase investigasi -> analisis -> desain -> implementasi (coding) -> testing -> maintenance.

    Prototyping Model  
  Berfungsi sebagai mekanisme pendefinisian kebutuhan. Pertama, developer menggali semua kebutuhan user secara cepat kemudian membangun prototipe yang sesuai dengan yang diinginkan dengan cepat pula dan ditunjukkan ke user, baru dibuat PL yang sesungguhnya berdasarkan komentar user terhadap prototipe.
  Kelebihan model : user dapat langsung melihat wujud PL yang akan dibangun meskipun sederhana dan dari sana dapat digali kebutuhan yang lebih dalam sebagai bahan penyusunan PL berikutnya.
   
 
   
      Masalah yg muncul :    

• User merasa prototipe merupakan PL yang sesungguhnya, padahal ketika membuat prototipe belum disertakan kualitas PL secara keseluruhan / kemampuan pemeliharaan untuk jangka panjang
 
• Developer sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat sehingga akan ditemui ketidakcocokan pada prototipe ketika prototipe dibangun dengan bahasa yang sederhana
 
• Program dibuat ulang / prototipe selalu baru

  Contoh : model Iterative : investigasi -> membuat PL -> testing / deliver ke user dengan program prototipe.
     
  Rapid Application Development (RAD) Model  
  Model proses perkembangan PL sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Menekankan perkembangan komponen program yang bisa dipakai lagi sehingga mendasari konsep Object-Oriented. 
  Fase2 pendekatan RAD : 
  • Bussines modeling
  • Data modeling
  • Proses modeling
  • Application generation : RAD mengasumsikan pemakaian teknik 4G (generasi keempat). Selain menciptakan PL dengan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program atau menciptakan komponen yang bias dipakai lagi.
  • Testing and Turn Over : karena menekankan pada reusability, banyak komponen program yang telah diuji sehingga mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.
   
   
   
    The Incremental Model  
  Mengadopsi model sekuensial linier dan model prototipe. Fungsi dasar sama, tapi ada tambahan asesoris (contoh : ada M.Word 1997, 2000). Fungsi tambahan ditambahkan terus untuk membuat sistem menjadi lebih baik. Pada increment pertama PL yang jadi, mengakomodasi kebutuhan inti. Baru pada tahap berikutnya ditambahkan kemampuan baru. 
  Contoh : pengembangan microsoft word. 
  • Increment 1 : hanya memberi fungsi inti –> hanya bisa mengetik saja
  • Increment 2 : bisa word art, spelling, dll
  Kelebihan model : cocok untuk produksi masal. 
 
   
   
    An Evolutionary (Spiral) Model  
     
  Penomoran dimulai dari arsiran paling dalam. Proses yang terjadi : 
  • Proyek pengembangan konsep
  • Proyek pengembangan produk baru
  • Proyek perbaikan produk
  • Proyek pemeliharaan produk
 
  Semua proyek tersebut dibangun dengan mengikuti model spiral melalui tahap : 
  • Customer communication
  • Planning
  • Risk analysis
  • Engineering
  • Construction and release
  • Customer evaluation
     

 
   
   
    Win-Win Spiral Model  
  Eliciting kebutuhan PL yang didefinisikan melalui negosiasi antara pelanggan dan developer, di mana tiap pihak berusaha menyeimbangkan teknik dan batasan bisnis.
  Concurrent Development Model Mirip Spiral model, biasa digunakan dalam pengembangan aplikasi client / server.
  Component-Based Development Variasi Spiral model di mana aplikasi dibangun dari komponen PL prepackage yang disebut class.
   
The Concurrent Development Model
Model pembangunan yang bersamaan, kadang-kadang disebut concurrent engineering, telah digambarkan dalam cara berikut oleh Davis dan Sitaram [DAV94]:

Manajer proyek yang melacak status proyek dalam bentuk fase utama [dari kehidupan klasik siklus] tidak tahu tentang status proyek-proyek mereka. Ini adalah contoh perusahaan berusaha untuk melacak sangat kompleks kegiatan set terlalu sederhana menggunakan model. Perhatikan bahwa walaupun. . . [a besar] Proyek ini dalam tahap pengkodean, ada personil pada proyek yang terlibat dalam kegiatan biasanya dikaitkan dengan banyak tahapan pembangunan secara simultan.

Misalnya   . . . personil persyaratan menulis, merancang, coding, pengujian, dan pengujian integrasi  [semua pada saat yang sama]. Model proses rekayasa perangkat lunak oleh Humphrey dan Kellner [[HUM89], [KEL89]] telah menunjukkan concurrency yang ada untuk kegiatan-kegiatan yang terjadi selama setiap satu fase. Kellner yang lebih baru kerja [KEL91] menggunakan statecharts [notasi yang mewakili negara bagian dari suatu proses] untuk mewakili hubungan bersamaan ada kegiatan antara dikaitkan dengan peristiwa tertentu (misalnya, sebuah persyaratan berubah selama perkembangan akhir),  tetapi gagal untuk menangkap kekayaan concurrency yang ada di semua pengembangan perangkat lunak dan kegiatan pengelolaan dalam proyek. . . .

Sebagian besar model Proses pengembangan perangkat lunak didorong oleh waktu; yang kemudian itu, yang kemudian dalam proses pengembangan Anda. [A berbarengan  Model proses] didorong oleh kebutuhan pengguna, keputusan manajemen, dan hasil review.

Model proses yang konkuren dapat digambarkan secara skematik sebagai rangkaian besar  kegiatan teknis, tugas, dan negara-negara terkait. Sebagai contoh, rekayasa  kegiatan yang ditetapkan untuk model spiral (Subbab 2.7.2) dapat dilakukan dengan menerapkan tugas berikut: prototyping dan / atau analisis pemodelan, persyaratan spesifikasi, Dan design.9

  Gambar 2.10 memberikan representasi skematis dari satu kegiatan dengan bersamaan   model proses. Kegiatan-analisis-mungkin dalam salah satu dari states10 dicatat   pada waktu tertentu. Demikian pula, kegiatan lainnya (misalnya, desain atau komunikasi pelanggan) dapat dinyatakan dalam cara yang analog. Semua kegiatan ada secara bersamaan tetapi berada di negara yang berbeda. Sebagai contoh, di awal proyek komunikasi pelanggan Aktivitas (tidak ditampilkan pada gambar) telah menyelesaikan iterasi pertama dan ada di perubahan menunggu negara. Kegiatan analisis (yang ada dalam negara tidak ada sementara komunikasi pelanggan awal selesai) sekarang membuat sebuah transisi ke dalam pembangunan di bawah negara. Namun, jika pelanggan menunjukkan bahwa perubahan dalam persyaratan harus dilakukan, kegiatan analisis bergerak dari pembangunan di bawah negara ke negara perubahan menunggu.

Model proses yang concurrent mendefinisikan sebuah rangkaian peristiwa yang akan memicu transisi dari negara bagian untuk masing-masing kegiatan rekayasa perangkat lunak. Sebagai contoh, selama tahap-tahap awal desain, sebuah inkonsistensi dalam model analisis terungkap. Ini menghasilkan model analisis peristiwa koreksi yang akan memicu aktivitas analisis dari negara yang dilakukan ke negara perubahan menunggu.

Model proses yang konkuren sering digunakan sebagai paradigma untuk pengembangan dari client/server11 aplikasi (Bab 28). Seorang klien / server yang terdiri sistem dari serangkaian komponen fungsional. Ketika diterapkan ke klien / server, model proses concurrent mendefinisikan kegiatan dalam dua dimensi [SHE94]: sebuah sistem dimensi dan dimensi komponen. Masalah tingkat sistem ditangani dengan menggunakan tiga kegiatan: desain, perakitan, dan penggunaan.

Dimensi komponen disapa dengan dua kegiatan: desain dan realisasi.
Concurrency dicapai dalam dua cara:
(1) sistem dan kegiatan komponen terjadi secara simultan dan dapat dimodelkan   menggunakan pendekatan yang berorientasi negara yang telah dijelaskan sebelumnya;
(2) khas klien / server Aplikasi ini diimplementasikan dengan banyak komponen, yang masing-masing dapat dirancang dan menyadari secara bersamaan.

Pada kenyataannya, proses konkuren model ini berlaku untuk semua jenis pengembangan perangkat lunak dan memberikan gambaran yang akurat tentang keadaan sekarang dari suatu proyek. Alih-alih membatasi kegiatan rekayasa perangkat lunak ke urutan peristiwa, itu mendefinisikan sebuah jaringan kegiatan. Masing-masing kegiatan pada jaringan ada bersamaan dengan kegiatan lain. Acara yang dihasilkan dalam suatu kegiatan atau di tempat lain dalam kegiatan memicu jaringan di antara negara-negara transisi dari suatu kegiatan.

  Formal Methods Model  
  Menggunakan notasi Matematika yang teliti untuk menentukan desain dan menguji sistem berbasis komputer. formal methode dapat diterapkan di berbagai aspek atau properti dari sistem yang kompleks. formal methode digunakan untuk spesifikasi detail,design dan verifikasi pada bagian-bagian sistem yang bersifat critical (misal avionics atau aerospace systems), serta pada safety critical system (contoh hearts monitor, ATM,banking)
     
  Fourth Generation (4GT) Techniques  
  Menggunakan alat PL untuk menggenerate source code untuk sistem PL dari representasi perincian level tinggi.