Pengebangan Perangkat Lunak

 1    Pengembangan Sekuensial Linier (Waterfall Model)

Metode pengembangan sistem sekuensial linier atau yang sering disebut juga dengan siklus kehidupan klasik atau model air terjun (waterfall model) memberikan sebuah pendekatan pengembangan sistem yang sistematik dan sekuensial, dimulai pada fase perencanaan sistem, analisis, desain, kode, pengujian, dan pemeliharaan. 

1. Perencanaan atau rekayasa dan pemodelan sistem

Pada fase ini dilakukan identifikasi sistem, studi kebutuhan pengguna, dan studi kelayakan sistem baik secara teknis maupun teknologi serta penjadwalan pengembangan sistem.

2. Analisis kebutuhan perangkat lunak

Pada fase ini pengumpulan kebutuhan diintensifkan dan difokuskan pada sistem yang akan dibangun meliputi identifikasi domain informasi, tingkah laku sistem, unjuk kerja, dan antarmuka sistem. Kebutuhan untuk sistem didokumentasikan dan dikonsultasikan lagi dengan pengguna.

3. Desain

Fase ini difokuskan pada proses desain struktur data, arsitektur sistem, representasi interface, dan algoritma program.

4. Kode

Setelah proses desain selesai maka hasilnya harus diterjemahkan kedalam bentuk program komputer yang kemudian menghasilkan suatu sistem.

5. Pengujian

Pengujian dilakukan untuk menemukan kesalahan-kesalahan yang mungkin terjadi pada proses pengkodean serta memastikan bahwa input yang dibatasi memberikan hasil yang sesuai dengan kebutuhan.

6. Pemeliharaan

Proses ini dilakukan setelah sistem yang dihasilkan disampaikan kepada pengguna, terutama jika sistem mengalami permasalahan yang belum ditemukan pada saat proses pengujian, permasalahan ini dapat berkaitan dengan permintaan pengguna yang membutuhkan perkembangan fungsional sistem maupun adanya penyesuaian dengan lingkungan eksternal seperti adanya perubahan periperal atau perubahan sistem operasi. Fase pemeliharaan akan mengakibatkan pengembang mengaplikasikan lagi setiap fase pengembangan sistem mulai dari awal, namun tidak membuat sistem yang baru.

• Kelebihan dan kekurangan sekuensial linear

KEKURANGAN MODEL SEKUENSIAL LINEAR

Masalah yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah :

1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.

2. Kadang kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan halini dan mengalami kesulitan untuk mengakomodasi ketidakpastiannatural yang ada pada bagian awal beberapa proyek.

3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka

KELEBIHAN MODEL SEKUENSIL LINIER

1. software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.

2. Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

2.    Pengembangan Prototipe

Prototype adalah sebuah Javascript Framework yang dibuat untuk lebih memudahkan proses dalam membangun aplikasi berbasis web.

Paradigma dari metode prototyping adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.

Model ini digunakan jika customer tidak menjelaskan detail kebutuhan input, proses atau output, sehingga developer tidak dapat memastikan algoritma yang akan dipakai, kesesuaian sistem operasi atau bentuk user interface.

Metode pengembangan perangkat lunak ini dimulai dengan pengumpulan kebutuhan. Pendekatan prototyping model digunakan jika pemakai hanya mendefenisikan secara umum dari perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya, sementara pengembang tidak begitu yakin akan efisiensi algoritma, adaptasi sistem operasi, atau bentuk antarmuka manusia-mesin yang harus diambil. Cakupan aktivitas dari prototyping model terdiri dari :

1.      Mendefinisikan objektif secara keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.

2.      Melakukan perancangan secara cepat sebagai dasar untuk membuat prototype.

3.      Menguji coba dan mengevaluasi prototype dan kemudian melakukan penambahan dan perbaikan-perbaikan terhadap prototype yang sudah dibuat.

Empat langkah yang menjadi karakteristik metode Prototyping yaitu : 

1              1  Pemilihan fungsi

Mengacu pada pemilahan fungsi yang harus ditampilkan oleh prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-tugas yang relevan yang sesuai dengan contoh kasus yang akan diperagakan.

2                    2.   Penyusunan Sistem Informasi

Bertujuan untuk memenuhi permintaan akan tersedianya prototype

      3.   Evaluasi

      4.   Penggunaan Selanjutnya.

Tahapan-tahapan Prototyping :

1. Pengumpulan kebutuhan : Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

2. Membangun prototyping : Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output)

3. Evaluasi prototyping : Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.

4. Mengkodekan sistem : Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai

5. Menguji sistem : Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain

6. Evaluasi Sistem : Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.

7. Menggunakan sistem : Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

Jenis-jenis Prototyping

Feasibility prototyping digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.

Requirement prototyping digunakan untuk mengetahui kebutuhan aktivitas bisnis user.

Desain Prototyping - digunakan untuk mendorong perancangan system informasi yang akan digunakan.

Implementation prototyping merupakan lanjytan dari rancangan protipe, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.

Keunggulan dan Kelemahan Prototyping

Keunggulan Prototyping :

1. End user dapat berpartisipasi aktif

2. Penentuan kebutuhan lebih mudah diwujudkan

3. Mempersingkat waktu pengembangan SI

1. Adanya komunikasi yang baik antara pengembang dan pelanggan

2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

3. Pelanggan berperan aktif dalam pengembangan sistem

4. Lebih menghemat waktu dalam pengembangan sistem

5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kelemahan Prototyping :

1. Proses analisis dan perancangan terlalu singkat

2. Mengesampingkan alternatif pemecahan masalah

3. Bisanya kurang fleksible dalam mengahadapi perubahan

4. Prototype yang dihasilkan tidak selamanya mudah dirubah

5. Prototype terlalu cepat selesai

3.     Model Pengembangan RAD (RAPID APPLICATION DEVELOPMENT)

Model RAD adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik increment (bertingkat). RAD menekankan pada siklus pembangunan pendek/singkat/cepat. Waktu yang singkat adalah batasan yang penting untuk model ini.Model RAD ini merupakan sebuah adaptasi ”kecepatan tinggi” dari model waterfall dimana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan ”sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari).Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi

fase-fase sebagai berikut :

1. Business modeling

Aliran informasi di antara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut: informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkannya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

2. Data modeling

Aliran informasi yang didefinisikan sebagai bagian dari fase business modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik masing-masing objek diidentifikasikan dan hubungan antara objek-objek tersebut didefinisikan.

3. Proses modeling

Aliran informasi yang didefinisikan di dalam fase data modeling   ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.

4. Application Generation

RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang ada (pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat-alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

5. Testing dan turnover 

Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.

Beberapa kelebihan dan kekurangan yang perlu diperhatikan dalam implementasi

pengembangan menggunakan model RAD :

1. Model RAD memerlukan sumber dara yang cukup besar, terutama untuk proyek

dengan skala besar.

2. Model ini cocok untuk proyek dengan skala besar.

3. Model RAD memerlukan komitmen yang kuat antara pengembang dan pemessan,

bahkan keduanya dapat tergabung dalam 1 tim.

4. Kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala

kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan

dengan model ini kurang bagus.

5. Sistem yang tidak dapat dimodularisasi tidak cocok untuk model ini.

6. Penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan

dan ini memerlukan kerja keras.

7. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi.

8. Resiko teknis yang tinggi juga kurang cocok untuk model ini.

9. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia

yang memadai untuk menciptakan jumlah tim RAD yang baik.

10. RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas

rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka

waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan

gagal.

11. Tidak cocok untuk proyek skala besar.

12. Proyek dapat gagal karena waktu yang disepakati tidak dipenuhi.

13. Sistem yang tidak dapat dimodularisasi tidak cocok untuk model ini.

14. Resiko teknis yang tinggi juga kurang cocok untuk model ini.

5.1 Rencana Kebutuhan (Requirement Planning)

Pada tahap ini, user dan analyst melakukan semacam pertemuan untuk melakukan identifikasi tujuan dari aplikasi atau sistem dan melakukan identifikasi kebutuhan informasi untuk mencapai tujuan. Pada tahap ini hal terpenting adalah adanya keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi, melainkan beberapa tingkatan organisasi sehingga informasi yang dibutuhkan untuk masingmasing user dapat terpenuhi dengan baik. Di samping itu, dapat juga melakukan koordinasi dengan Chief Information Office (CIO) atau bagian perencana strategis terutama untuk mengembangkan suatu aplikasi E-commerce berbasis Web untuk mendapatkan informasi yang lebih detail akan tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication Development.

5.2 Proses Desain (Design Workshop)

Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan-perbaikan apabila masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini maka keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user bisa langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing orang bisa melihat satu dengan yang lain tanpa ada halangan.

Apabila memungkinkan, maka masingmasing user diberikan satu komputer yang terhubung satu dengan yang lain, sehingga masing-masing bisa melihat desain yang dibuat dan langsung memberikan komentar. Hal ini sering kali disebut dengan Group Decision Support System (GDSS). Pada beberapa kasus, GDSS ini merupakan suatu langkah yang ideal, karena user dan analyst dapat menyetujui desain yang dibuat untuk kemudian dilanjutkan oleh programmer dalam pembuatan prototype dari aplikasi yang dimaksud dengan langsung menampilkan kepada user hasilnya dengan cepat. Pada tahap desain ini membutuhkan waktu beberapa hari, akan tetapi bisa semakin lebih lama, tergantung dari besar kecilnya sistem yang dibuat. Pada selang waktu tersebut, user bisa memberikan tanggapan akan sistem yang sudah dikembangkan untuk selanjutnya dilakukan perbaikan-perbaikan. Dengan demikian proses pengembangan suatu sistem membutuhkan waktu yang cepat.

5.3 Implementasi (Implementation)

Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh user dan Analyst, maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu organisasi. Pada saat ini maka user bisa memberikan tanggapan akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut. Adapun hal terpenting adalah bahwa keterlibatan user sangat diperlukan supaya sistem yang dikembangkan dapat memberikan kepuasan kepada user, dan di samping itu, sistem yang lama tidak perlu dijalankan secara paralel dengan sistem yang baru.

5.4 Tahapan keseluruhan

Dengan berdasarkan pada tahapantahapan tersebut di atas maka proses utama pengembangan suatu sistem dengan menggunakan metode RAD adalah sebagai berikut :

- Pengembang membuat prototype berdasarkan kebutuhan-kebutuhan yang sudah didefinisikan sebelumnya

- Desainer melakukan penilaian terhadap prototype

- User melakukan uji coba pada prototype dan memberikan masukan mengenai kebutuhan-kebutuhan yang      kurang.

- User dan developer melakukan pertemuan untuk memberikan penilaian terhadap produk secara bersama-      sama, menyesuaikan kebutuhan serta memberikan komentar apabila diperlukan perubahan.

- Semua kebutuhan akan sistem dan perubahan-perubahan yang terjadi dilakukan proses “timeboxed”             dengan mempunyai

Sejarah Rekayasa Perangkat LunakI

SEJARAH RekayasaPerangkat Lunak

 

Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Fokus utama pengembangannya adalah untuk mengembangkan praktek dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat lunak dan kualitas aplikasi yang dapat digunakan oleh pemakai.
Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat perdebatan tajam mengenai aspek engineering dari pengembangan perangkat lunak. Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap pengembangan rekayasa perangkat lunak. Banyak yang menganggap dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak.
Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak project yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari project yang melebihi anggaran, hingga kasus yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak.
Selama bertahun-tahun, para peneliti memfokuskan usahanya untuk menemukan teknik jitu untuk memecahkan masalah krisis perangkat lunak. Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi objek, perangkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal dipakai sebagai senjata pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu.
Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembanan perangkat lunak dalam tempo 10 tahun.
Sebagian berpendapat, No Silver Bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.

PENGERTIAN REKAYASA PERANGKAT LUNAK

1. Pengertian dari Perangkat Lunak adalah kumpulan beberapa perintah komputer yang dieksekusi oleh mesin komputer dalam menjalankan pekerjaannya yaitu memproses informasi. perangkat lunak ini merupakan catatan bagi mesin komputer untuk menyimpan perintah, maupun dokumen serta arsip lainnya. Perangkat lunak tidak dapat disentuh dan dilihat secara fisik, software memang tidak tampak secara fisik dan tidak berwujud benda tapi bisa di operasikan.

2. Pengertian Rekayasa Perangkat Lunak (RPL) adalah aplikasi ilmu komputer untuk membangun sistem perangkat lunak praktis yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan.

3. Perbedaan perangkat lunak dengan ilmu komputer Ilmu komputer seringkali didiskripsikan sebagai suatu studi sistematis pada proses-proses algoritma yang menjelaskan dan mentransformasikan informasi seperti halnya di sini adalah teori, analisis, disain, efisiensi, penerapan dan aplikasinya. Sedangkan perangkat lunak merupakan data elektronik yang disimpan sedemikian rupa oleh komputer itu sendiri, data yang disimpan ini dapat berupa program atau instruksi yang akan dijalankan oleh perintah, maupun catatan-catatan yang diperlukan oleh komputer untuk menjalankan perintah yang dijalankannya. Jadi perangkat lunak itu dapat berupa program atau prosedur. Perbedaan antara RPL dengan ilmu komputer adalah Intinya, imu komputer berhubungan dengan teori dan metode yang mendasari sistem komputer dan perangkat lunak, sedangkan RPL berhubungan dengan praktek dalam memproduksi perangkat lunak.

4. Perbedaan rekayasa perangkat lunak dengan rekayasa sistem Rekayasa system mempunyai pengertian suatu sistem yang mampu memilih alat bantu yang baik dalam perencanaan maupun dalam penerapan perangkat lunak dan memiliki teknik yang baik untuk menilai kualitas dari perangkat lunak yang dihasilkan, serta mampu mengkoordinasikan, mengontrol, dan mengatur pelaksanaan pekerjaan pembuatan perangkat lunak. Sedangkan rekayasa pernagkat lunak itu adalah aplikasi dari ilmu computer yang membangun system perangkat lunak yang nantinya perangkat lunak itu akan dipilih kualitas dan tekniknya oleh rekayasa system. Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem. Perbedaan RPL dengan Rekayasa Sistem intinya Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem.

5. Proses perangkat lunak sebagai berikut Serangkaian kegiatan dan hasil-hasil relevannya yang menghasilkan perangkat lunak sebagian besar dilakukan oleh perekayasa perangkat lunak. Ada 4 kegiatan/aktivitas pada proses PL : • Spesifikikasi Perangkat Lunak : Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan. • Pengembangan 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.

6. Model proses perangkat lunak

 Model aliran kerja (workflow) : menunjukkan kegiatan pada proses bersama dengan input, output, dan ketergantungannya. Merepresentasikan pekerjaan manusia.

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

 Model peran/aksi : merepresentasikan peran orang yang terlibat pada PL dan kegiatan yg menjadi tanggung jawab mereka.

Model atau paradigma umum pada proses PL 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.

Pengembangan evolusioner : Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian di perbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan kebutuhan pelanggan.

Pengembangan Sistem Formal : Pendekatan ini menghasilkan suatu sistem matematis yang formal dan mentransformasikan spesifikasi ini, dengan menggunakan metode matematik menjadi sebuah program.

Pengembangan berdasarkan pemakaian ulang (Reusable) : Teknik ini menganggap bahwa bagian-bagian sistem sudah ada. Proses pengembangan sistem terfokus pada pengintegrasian bagian-bagian sistem dan bukan pengembangannya dari awal.

7. Metode rekayasa perangkat lunak Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC)

• Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah.

• Tahapan-tahapan pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis – design – coding – testing – maintenance

• Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut.

• Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan.

• Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah di-rupiah-kan. Namun efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi, efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.

8. Computer-aided software engineering Adalah suatu system untuk menunjang pengembangan software sehingga informasi yang diciptakan oleh satu alat dapat digunakan oleh alat lain.


Sumber : http://smktridharma2.sch.id/Isi_beritaok.php?no=20&cetak=ok