MODEL PENGEMBANGAN PERANGKAT LUNAk

 Model 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 siste 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. PengujianPengujian 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 

• 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.
• 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.
• 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
• Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier

KELEBIHAN MODEL SEKUENSIL LINIER

•  software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
• Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

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. Prototyping model dimulai dengan mendengarkan kebutuhan user. Engineer dan customer bertemu dan menentukan semua tujuan software dan menentukan kebutuhan-kebutuhan. Developer kemudian membangun prototype dan user menguji coba prototype untuk memberikan feedback. Prototype dapat dijalankan sebagai sistem yang pertama. User bisa mendapatkan pengertian dari sistem yang sesungguhnya dan developer dapat membangun sistem dengan segera. Kekurangan : kontrak akan merugikan, dirugikan oleh keinginan customer yang meminta penambahan-penambahan. Kelebihan : akan mengurangi waktu pembuatan program, kebutuhan customer akan lebih terpenuhi dengan baik, jika kebutuhannya belum jelas, maka dengan prototype akan lebih menguntungkan.

 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

•  Mendefinisikan objektif secara keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.
•  Melakukan perancangan secara cepat sebagai dasar untuk membuat prototype.
• 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. 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. 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 :

• End user dapat berpartisipasi aktif
• Penentuan kebutuhan lebih mudah diwujudkan
• Mempersingkat waktu pengembangan SI
• Adanya komunikasi yang baik antara pengembang dan pelanggan
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
• Pelanggan berperan aktif dalam pengembangan sistem
• Lebih menghemat waktu dalam pengembangan sistem
• Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kelemahan Prototyping :

• Proses analisis dan perancangan terlalu singkat
• Mengesampingkan alternatif pemecahan masalah
• Bisanya kurang fleksible dalam mengahadapi perubahan
• Prototype yang dihasilkan tidak selamanya mudah dirubah
• Prototype terlalu cepat selesai

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.

 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.

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.

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.

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 2 kemungkinan :

• Perubahan yang tidak dapat ditampung seperti yang sudah direncanakan harus dihilangkan.
• Jika diperlukan, kebutuhan-kebutuhan yang bersifat sekunder ditiadakan

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.

   

Sejarah dan pengertian Rekayasa Perangkat Lunak

Rekayasa perangkat lunak

 Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Fokus utama pengembangannya adalah untuk mengembangkan praktik 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 debat 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 perkembangan rekayasa perangkat lunak. Banyak yang menganggap bahwa dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak. jangan pernah menganggap kalau software itu akn menjadi yang terbaik karena itu adalah sebuah karya yang bersifat sementara.

1965 - 1985: krisis perangkat lunak

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak projek yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari projek 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.

1985 - kini: tidak ada senjata pamungkas

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 object, perangkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan 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 praktik yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembangan 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 dan tujuan RPL

Pengertiaan dan Definisi 

Menurut Wikipedia : Rekayasa perangkat lunak adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen kualitas.

Menurut IEEE Computer Society : Rekayasa perangkat lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.

Rekayasa Perangkat Lunak adalah pengubahan perangkat lunak itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan menggunakan prinsip reakayasa untuk menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif untuk pengguna.

Dari beberapa definisi dan penjelasan diatas ada beberapa kategori dari suatu rekayasa perangkat lunak yaitu :

1. Maintainability yang artinya perangkat lunak dapat terus dirawat dan dipelihara.

Pengertian lain dari maintainability adalah suatu usaha yang diperlukan untuk menemukan dan memperbaiki kesalahan dalam perangkat lunak. maintanability diperlukan untuk pemeliharaan perangkat lunak dimana setelah dikembangkan dan diimplementasikan terdapat beberapa hal yang perlu diperbaiki berdasarkan hasil ujicoba maupun evaluasi. Suatu perangkat lunak yang baik dikatakan maintainability dapat dengan mudah direvisi apabila diperlukan.

2. Dependability yang artinya perangkat lunak dapat mengikuti perkembangan teknologi.

Dependability maksudnya suatu perangkat lunak dapat diandalkan dan mengikuti perkembangan, secara kasarnya dependability itu maksudnya adalah kepercayaan konsumen terhadap suatu perangkat lunak.  Sebenarnya dependability itu sendiri tergantung dari beberapa faktor diantaranya availability (ketersediaan sistem pada setiap waktu diperlukan oleh sistem) , reliability (kecenderungan sistem gagal dalam melaksanakan perintah), security(bagian dari sistem yang mencerminkan kemampuan untuk berjalan secara normal tanpa menyebabkan resiko bagi pengguna) dan safety(berkaitan dengan kehandalan sistem dalam menangkal ancaman dari luar sistem).

3. Robust yang artinya perangkat lunak dapat mengikuti keinginan pengguna.

Maksud dari robust perangkat lunak adalah kinerja atau hasil yang diharapkan meskipun dalam kondisi yang tidak ideal seperti adanya gangguan yang tidak terkendali yang dapat mempengaruhi kinerja perangkat lunak.

4. efektif dan efisien dalam menggunakan energi dan penggunaannya

suatu perangkat lunak dikatakan efektif dan efisien artinya pengguna tidak harus melakukan proses yang berulang-ulang hanya untuk menghasilkan beberapa output yang diinginkan.

5. Usability yang artinya dapat memenuhi kebutuhan yang diinginkan

Usability adalah tingkat kualitas dari perangkat lunak yang mudah dipelajari, mudah digunakan dan mendorong pengguna untuk menggunakan perangkat lunak sebagai alat bantu positif dalam menyelesaikan tugas. Usability adalah suatu ukuran, dimana pengguna dapat mengakses fungsionalitas dari sebuah perangkat lunak dengan efektif, efisien dan memuaskan dalam mencapai tujuan tertentu

Tujuan Rekayasa Perangkat Lunak

Secara lebih khusus kita dapat menyatakan tujuan dan Rekaya Perangkat Lunak ini adalah:

1. Memperoleh biaya produksi perangkat lunak yang rendah.
2. Menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
3. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
4. Menghasilkan perangkat lunak yang biaya perawatannya rendah

Kriteria Dalam Merekayasa Perangkat Lunak

1. Dapat terus dirawat dan dipelihara (maintainability)
2. Dapat mengikuti perkembangan teknologi (dependability)
3. Dapat mengikuti keinginan pengguna (robust).
4. Efektif dan efisien dalam menggunakan energi dan penggunaannya.
5. Dapat memenuhi kebutuhan yang diinginkan (usability).

Ruang Lingkup Rekayasa Perangkat Lunak

1. Software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.
2. Software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak.
3. Software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk. algoritma, pengkodean, pengujian dan pencarian kesalahan.
4. Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
5. Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan.
6. Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.
7. Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak.
8. Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL.

Rekayasa Perangkat Lunak dan Disiplin Ilmu Lain

Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin dengan bidang ilmu lain. tidak saja sub bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain diluar ilmu komputer.

Keterkaitan RPL dengan bidang ilmu lain

• Bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis. 
• Bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit.
• Bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif.