Definisi software adalah sekumpulan item atau objek yang membentuk konfigurasi yang mencakup Program Dokumen Data

n Data Program komputer, prosedur, dan kemungkinan terkait dokumentasi dan data yang terkait dengan pengoperasian dari sistem komputer (IEEE Standard Glossary of Software Engineering Terminology, 1990) Software merupakan sebuah produk dan kendaraan untuk memberikan suatu produk (informasi). Perangkat lunak direkayasa tidak diproduksi. Perangkat lunak tidak rusak, tetapi memburuk.

Jenis-Jenis Aplikasi Perangkat Lunak System software Application software Embedded software Engineering/Scientific software Product software Web Applications Artificial intelligence software

Mitos Software Dari sudut pandang Client Mitos : Sebuah pernyataan umum dari tujuan cukup untuk mendapatkan selanjutnya. Isian secara rinci dilakukan kemudian. Realita : Definisi yang tidak rinci diawal requirement atau kebutuhan adalah penyebab utama kegagalan dan keterlambatan perangkat lunak. M : Kebutuhan Proyek terus berubah, tetapi perubahan dapat dengan mudah diakomodasi karena software fleksibel. R : Biaya dari perubahan untuk perangkat lunak untuk memperbaiki suatu kesalahan meningkat secara dramatis pada tahap selanjutnya dari kehidupan software. Mitos : pertanyaan umum tentang objektivitas sudah cukup untuk memulai menulis progam. Kita dapat mengisi detailnya nanti Kenyataan : definis awal yang buruk merupakan sebab utama gagalnya kerja perangkat lunak. Deskripsi yang detail dan formal tentang domain informasi, fungsi, unjuk kerja, interface, design constraint dan kriteria validasi merupakan hal yang mendasar. Ciri-ciri ini dapat ditentukan hanya melalui komunikasi yang hati-hati antara pelanggan dan pengembang

Mitos :Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : Memang benar bahwa kebutuhan software berubah tetapi dampak dari perubahan berbeda dari waktu ke waktu. Mitos Software Dari sudut pandang Developer M : Setelah program ditulis dan bekerja, pekerjaan pengembang telah selesai. R : 50% -70% dari usaha pengeluaran program terjadi setelah dikirim ke pelanggan. M : Sampai program berjalan, tidak ada cara untuk menilai kualitas. R : Review Software dapat lebih efektif dalam menemukan kesalahan daripada pengujian untuk kelas-kelas tertentu yang memiliki kesalahan. M : Hanya diserahkan untuk proyek yang sukses adalah program yang jalan R : Suatu konfigurasi perangkat lunak meliputi dokumentasi, regenerasi file, masukan (input) data uji, dan hasil data uji. Mitos : satu-satunya yang dapat disampaikan untuk sebuah proyek yang sukses adalah program yang bekerja Kenyataan : Program yang bekerja hanya merupakan salah satu bagian dari konfigurasi perangkat lunak yang menyangkut program, dokumen, dan data. Dokumentasi yang membentuk fondasi bagi perkembangan yang berhasil, serta yang lebih penting lagi, memberikan tuntutan bagi tugas pemeliharaan perangkat lunak. Mitos :Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara :Catch as Catch CAM. Realitasnya : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus diorganisir, direncanakan dan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi. Mitos Software Dari sudut pandang Manajemen M : Ada Buku standar sehingga perangkat lunak yang dikembangkan akan memuaskan. R : Buku mungkin ada, tetapi mereka biasanya tidak up to date dan tidak digunakan. M : Komputer dan kakas (tools) perangkat lunak yang tersedia sudah cukup. R : CASE tools diperlukan tetapi biasanya tidak diperoleh atau tidak digunakan.

M : Kita selalu dapat menambahkan jumlah programmer jika proyek terlambat penyelesaiannya R : "Menambahkan orang untuk proyek yang terlambat akan membuat penyelesaian perangkat lunak lebih terlambat "-. Brooks Mitos : kita sudah memiliki buku yang penuh dengan standar dan prosedur untuk membuat perangkat lunak. Apakah buku itu tidak memberikan semua yang ingin diketahui oleh staff saya ? Kenyataan : buku standar mungkin ada, tetapi apakah buku-buku tersebut dipakai ? Apakah praktisi perangkat lunak sadar akan keberadaan buku-buku tersebut ? Apakah dia benarbenar mencerminkan praktik pengembangan perangkat lunak modern ? Apakah sudah lengkap ? Dalam banyak hal, jawaban untuk semua pertanyaan diatas adalah tidak Mitos :Kita tidak perlu mengubah pendekatan terhadap pengembangan software karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu. Realitasnya : walau hasil pemrograman sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments. Mitos :Kita sudah punya buku yang berisis standarisasi dan prosedur untuk pembentukan software. Realitasnya : Memang buku tersebut ada tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan zaman. Software Engineering Rekayasa Perangkat Lunak adalah pembentukan dan prinsip-prinsip rekayasa yang tepat untuk mendapatkan perangkat lunak yang ekonomis, dapat dipercaya dan bekerja efisien pada mesin sesungguhnya (Fritz Bauer, 1969) Rekayasa Perangkat Lunak adalah [1] penerapan secara sistematis, disiplin, pendekatan terukur terhadap pembangunan, operasi, dan pemeliharaan perangkat lunak, dan [2] studi tentang pendekatan seperti pada [1] (IEEE, 1993)

Kenapa RPL Untuk membuat perangkat lunak dengan benar (proses) dan mendapatkan perangkat lunak yang benar (produk) Adanya Kompleksitas Perangkat Lunak o Domain problem: Business Rule o Ukuran Data : Digital and Non Digital o Solution: Algorithm o Tempat atau Situs

Perangkat Lunak harus benar Kebenaran perangkat lunak harus bisa dipelihara

Produk RPL Produk diperoleh melalui tahapan Pengembangan = Software Development Lifem Cycle (SDLC) Contoh siklus hidup (SDLC): o Waterfall model o V model o Spiral model o Fountain model o Prototyping

Definisi proses Proses : kumpulan aktifitas-aktifitas(activities), tindakan-tindakan (actions) dan tugastugas (tasks) yang dilakukan ketika suatu produk (PL) dibuat Tiap aktivitas terdiri dari beberapa tindakan, tiap tindakan terdiri dari beberapa tugas

Proses RPL Management Process meliputi: o Project management o Configuration management o Quality Assurance management Technical Process, digambarkan sebagai metode yang akan diterapkan dalam tahap tertentu dari SDLC o Analysis methods o Design methods o Programming methods o Testing methods Metode teknis ini yang memunculkan paradigma seperti berorientasi terstruktur, objek, aspek, dll

Yang Terlibat RPL Manager o Project Manager o Configuration Manager o Quality Assurance Manager Software Developer: o Analyst o Designer

o Programmer Support o Administration o Technical Support for Customer (help desk, customer care) o Welfare (Kesejahteraan)

Software quality atribut Ciri-ciri (Atribut) Kualitas menurut lembaga penjamin PL ( ISO, IEEE, dll) o o o o o o Correctness (Kebenaran) Reliability ( tahan uji) User Friendliness (mudah digunakan) Maintenatibility (mudah dirawat) Efficiency Portability (Mudah didistribusikan)

Hubungan RPL, ILKomp & Rekasaya Sistem Ilmu Komputer berkaitan erat dengan teori dan konsep-konsep dasar tentang komputer dan aplikasinya. RPL berkaitan dengan praktek pembangunan PL hingga pengiriman PL ke pelanggan. Teori ilmu komputer masih kurang memadai jika dijadikan sebagai penyangga RPL sehingga ada bahasan khusus mengenai RPL.

Proses Generik Spesifikasi apa yang harus dilakukan oleh perangkat lunak dan batasan/kendala pengembangannya Pengembangan proses memproduksi sistem perangkat lunak Validasi pengujian perangkat lunak terhadap keinginan pengguna Evolusi perubahan perangkat lunak berdasarkan perubahan keinginan.