Sasaran Agar mahasiswa dapat: Memahami lingkup rekayasa perangkat lunak Latar belakang Definisi Tujuan rekayasa perangkat lunak Ciri perangkat lunak yang direkayasa dengan baik Aplikasi perangkat lunak Mitos perangkat lunak Memahami pengembangan perangkat lunak object oriented Memahami proses perangkat lunak Memahami model siklus hidup perangkat lunak Memahami penjaminan kualitas perangkat lunak

Definisi Menurut Ian Sommervile RPL berkaitan dengan TEORI METODA ALAT-ALAT (TOOLS) untuk pengembangan perangkat lunak berkualitas tinggi dengan cara- cara cost-effective Menurut Fritz Bauer RPL adalah penetapan dan penggunaan prinsip-prinsip rekayasa yang tangguh/teruji dalam upaya memperoleh perangkat lunak secara ekonomis, handal dan bekerja efisien di mesin nyata

Definisi Menurut Mynatt RPL secara sederhana dinyatakan sebagai pendekatan sistematis untuk penciptaan dan pemilikan perangkat lunak Menurut IEEE Standard Glossary of Set Terminology (IEEE 83) RPL adalah pendekatan sistematis untuk pengembangan, operasi, pemeliharaan dan penghentian pemakaian perangkat lunak

Institute of Electrical and Electronics Engineers adalah sebuah organisasi profesi non-profit yang terdiri dari banyak ahli di bidang teknik yang mempromosikan pengembangan standar-standar dan bertindak sebagai pihak yang mempercepat teknologi-teknologi baru dalam semua aspek dalam industri dan rekayasa (engineering), yang mencakup telekomunikasi, jaringan komputer, kelistrikan, aerospace, dan elektronika. IEEE memiliki lebih dari 300000 anggota individual yang tersebar dalam lebih dari 150 negara. Aktivitasnya mencakup beberapa panitia pembuat standar, publikasi terhadap standar-standar teknik, serta mengadakan konferensi. IEEE Indonesia Section berada pada IEEE Region 10 (Asia Pacific). Ketua IEEE Indonesia Section tahun 2009 adalah Prof. Dr. Arnold Ph Djiwatampu. Saat ini IEEE Indonesia Section memiliki beberapa chapter, yaitu: Communications Society Chapter Circuits and Systems Society Chapter Engineering in Medicine and Biology Chapter Join Chapter of Education Society, Electron Devices Society, Power Electronics Society, Signal Processing Society Joint chapter MTT/AP-S

Memecahkan permasalahan pelanggan: Definisi Suatu proses untuk menyelesaikan masalah pelanggan melalui pengembangan dan evolusi sistematik dari sistem software yang besar dan berkualitas di dalam kendala biaya, waktu dan lain-lain. Memecahkan permasalahan pelanggan: Ini merupakan sasaran dari software engineering Beberapa solusi adalah dibeli, bukan dibangun Menambahkan fitur-fitur yang tidak perlu tidak akan membantu pemecahan masalah Ahli software harus berkomunikasi secara efektif untuk mengenali dan memahami permasalahan

Definisi Pengembangan dan evolusi tersistematik Suatu proses perekayasaan dengan melibatkan teknik-teknik terstruktur di dalam cara yang terorganisir Banyak praktik-praktik yang sudah distandarisasi, misalnya IEEE atau ISO Kebanyakan pekerjaan development merupakan evolusi Sistem software yang besar dan berkualitas Teknik rekayasa software diperlukan karena sistem yang besar tidak dapat dipahami sepenuhnya oleh satu orang Kerja sama tim dan koordinasi sangat diperlukan Tantangan utama: membagi pekerjaan dan memastikan bahwa bagian-bagian dari sistem tersebut bekerja bersama Produk akhir yang dikeluarkan harus memenuhi syarat kualitas

Definisi Kendala waktu dan biaya SDM terbatas Keuntungan harus melebihi biaya Orang lain bisa berkompetisi untuk melakukan pekerjaan lebih murah dan lebih cepat Estimasi biaya yang tidak akurat akan menyebabkan kegagalan

Definisi PL bukan hanya program, tetapi juga dokumentasi untuk Memasang (INSTALL) Apa yang dibutuhkan Perangkat Keras Perangkat Lunak Kondisi yang harus dipersiapkan Prosedur yang harus dikerjakan Langkah-langkah yang diperlukan Apa yang boleh dan apa yang tidak boleh Memakai (Use) Prakondisi Apa yang perlu dilakukan sebelum memakai Poskondisi Apa yang perlu dilakukan setelah memakai

Mengembangkan (Develop) Apa kebutuhan user saat dikembangkan Apa tujuan sistem Apa yang telah dicapai Apa yang belum dicapai Merawat (Maintain) Umur pakai Syarat penyimpanan Perubahan yang mungkin dilakukan Perubahan yang tidak mungkin dilakukan

Definisi Perekayasa PL harus menguasai Teknologi komputer Ilmu dasar komputer Pengetahuan perangkat keras Teknologi pengembangan PL meliputi teori, metodologi, alat-alat (tools) Kemampuan berkomunikasi baik lisan maupun tertulis Manajemen proyek Pembagian tugas & tanggung jawab di dalam kelompok Kendali waktu an biaya Memahami kesulitan user Awam dengan metodologi dan teknologi

Mitos Tentang PL Banyak permasalahan pada sebuah PL datang dari asumsi-asumsi yang kebenarannya tidak dapat dipertanggungjawabkan Tiga kelompok yang terkait dalam pengembangan PL MANAGEMENT (MANAJEMEN) Manajer Pengembang PL harus Mengatur anggaran Menjaga jadwal dari kelambatan Meningkatkan kualitas CUSTOMER (PEMAKAI) YANG MENGINGINKAN PL DIKEMBANGKAN REKAN KERJA BAGIAN LAIN PEMASARAN PERSONALIA PEMBUKUAN DLL PIHAK LUAR, BERDASARKAN KONTRAK KERJA PRACTITIONER (PENGEMBANG) YANG MENGEMBANGKAN PL DIANTARANYA PROGRAMMER

Mitos Tentang PL MITOS DIPIHAK MANAJEMEN MITOS KENYATAAN ADANYA PANDUAN & PROSEDUR, PASTI LANCAR KENYATAAN APAKAH: DISADARI KEBERADAANNYA ? LENGKAP ? DIPAKAI ? SESUAI KEBUTUHAN ? PERALATAN BARU & MODERN PENGUASAAN TOOL LEBIH PENTING DARI HARDWARE/SOFTWARE BILA TERLAMBAT, TAMBAH PROGRAMMER TAMBAH PROGRAMMER AKAN SEMAKIN LAMBAT

Mitos Tentang PL MITOS DIPIHAK PEMAKAI MITOS KENYATAAN TUJUAN SISTEM SECARA UMUM CUKUP UNTUK MEMBUAT PL, RINCIAN BELAKANGAN SAJA SAAT PROGRAM DIKEMBANGKAN KENYATAAN RINCIAN KEBUTUHAN SANGAT PENTING FUNGSI PERFORMANCE ANTAR-MUKA BATASAN RANCANGAN KRITERIA VALIDASI DLL HANYA BISA DIPEROLEH DENGAN KOMUNIKASI YANG INTENSIF PERANGKAT LUNAK BERSIFAT FLEKSIBEL PERUBAHAN KEBUTUHAN MUDAH DIAKOMODASI OLEH PENGEMBANG PL DAMPAK SANGAT BERGANTUNG PADA TAHAP MANA PERUBAHAN TERJADI

Mitos Tentang PL MITOS DIPIHAK PENGEMBANG MITOS KENYATAAN PROGRAM SELESAI, PEKERJAAN SELESAI KENYATAAN 50% - 70% USAHA DIHABISKAN SETELAH PROGRAM DISERAHKAN KE USER UNTUK PERTAMA KALINYA KUALITAS HANYA BISA DIKETAHUI SETELAH PROGRAM BERJALAN (RUNNING) KUALITAS DAPAT DIJAGA SEJAK PL DIKEMBANGKAN YANG DISERAHKAN KE USER ADALAH PROGRAM YANG DISERAHKAN ADALAH KONFIGURASI PERANGKAT LUNAK PROGRAM DITAMBAH DOKUMENTASI

Sasaran RPL Penerapan disiplin sistematika perangkat lunak ditujukan untuk membantu: Menghasilkan sistem RPL yang berkualitas dengan ongkos yang murah dan tepat waktu On Time delivery Memenuhi user requirement Dokumentasi yang baik Tanda-tanda terjadinya kekeliruan dalam penerapan RPL Produk diberikan terlambat Melebihi anggaran Tidak sesuai kebutuhan user Proyek besar ditinggalkan sebelum produk diberikan

Sasaran RPL RPL menghasilkan produk berbentuk perangkat lunak lengkap dengan dokumentasinya Dua macam RPL: Generik → Produkyang dikembangkan untuk dijual kepada publik Spesifik → Produck yang dikembangkan khusus untuk sebuah perusahaan

Sasaran RPL Ciri PL yang direkayasa dengan baik Mudah dirawat Dilengkapi dokumentasi Perubahan dapat dilakukan dengan biaya minimum Dapat diandalkan Bekerja seperti yang diharapkan Gagal hanya bila keluar dari spesifikasinya Bekerja Efisien Tidak memboroskan sumber daya : memori, prosesor, penyimpanan dll Mempunyai antar muka pemakai yang baik Dibuat sesuai dengan tingkat kemampuan pemakai

Pengembangan RPL menjadi suatu disiplin ilmu yang mempunyai landasan kuat Agar dapat memprediksi waktu, usaha, dan ongkos pengembangan PL Adanya kualitas buruk pada PL dan peran RPL sebagai upaya pencarian cara perbaikan kualitas PL Perubahan rasio antara biaya perangkat keras dan perangkat lunak yang saat ini cenderung menjadikan PL sebagai komponen vital/kritis dan lebih mahal dibandingkan perangkat keras Perkembangan pada perangkat keras memberi tantangan pembuatan PL baru yang dapat memanfaatkan fitur-fitur perangkat keras Perkembangan pada teknik-teknik PL Permintaan yang meningkat terhadap PL dengan spesifikasi yang lebih kompleks

Komponen RPL RPL merupakan aktifitas – aktifitas yang berkaitan dengan Proses Pengembangan PL sehingga rasional dan tepat waktu Metode Cara teknis dalam membangun RPL pada kegiatan penetapan kebutuhan, analisis, perancangan, pembangunan program, pengujian Alat / Kakas (Tools) Mendukung pelaksanaan proses dan metode

Komponen RPL Proses Metode Merupakan kerangka kerja untuk tugas-tugas yang diperlukan dalam membangun PL yang berkualitas tinggi Mendefinisikan kerangka kerja untuk sekumpulan bidang proses pokok ( key process area ) Tercapai sasaran penerapan RPL yang efektif Sebagai basis kendali manajemen Merupakan konteks penerapan metode teknis, produk kerja (model, dokumen, data, laporan, formulir-formulir, dsb) Metode Tata cara teknis untuk membangun PL Mencakup seluruh aktifitas dalam RPL yang meliputi rekayasa kebutuhan ( rekayasa sistem, rekayasa bisnis ), analisis dan perancangan, pengujian, prototyping dsb sesuai paradigma yang dipilih

Komponen RPL Alat / Kakas (Tools) CASE ( Computer Aided Software Engineering) merupakan PL untuk mendukung pengembangan PL CASE menggabungkan antara lain perangkat keras, PL dan basis data RPL ( berisi informasi/dokumen analisis, rancangan source code dan testing ) untuk menciptakan lingkungan RPL

Paradigma RPL ~1975-1985: Paradigma Terstruktur Analisis sistem terstruktur, desain komposit/terstruktur, pemrograman terstruktur, pengujian terstruktur. Membawa perkembangan besar terhadap industri software. Tetapi hanya baik untuk program kecil (katakan, 5.000-50.000 baris kode). Tidak begitu sesuai dengan program-program besar (katakan, 500.000-5.000.000 baris kode). Tidak begitu baik di dalam aspek pemeliharaan software (karena pemisahan antara action-oriented dan data-oriented di dalam paradigma terstruktur). Paradigma Object-Oriented Suatu obyek adalah suatu komponen software yang menggabungkan baik data maupun aksi yang menangani data tersebut.

Paradigma RPL Paradigma Terstruktur Tahap Kebutuhan Tahap Spesifikasi (Analisis) Tahap Perencanaan Tahap Desain Tahap Implementasi Tahap Integrasi Tahap Pemeliharaan Retirement Paradigma Object-Oriented Tahap Kebutuhan Tahap Analisis Object-Oriented Tahap Perencanaan Tahap Desain Object-Oriented Tahap Pemrograman Object-Oriented Tahap Integrasi Tahap Pemeliharaan Retirement

Aktifitas Pengembangan RPL 3 fase tahapan aktifitas RPL Fase pendefinisian Fokus pada pertanyaan apa, meliputi Informasi yang perlu diolah Fungsi / kinerja yang perlu dilakukan Perilaku sistem yang diharapkan Interface Konstrain dan validasi Fase pengembangan Fokus pada pertanyaan bagaimana, meliputi Struktur data Fungsi diimplementasikan Rincian prosedur Penerjemahan rancangan ke bahasa pemrograman Testing

Aktifitas Pengembangan RPL Fase Suporting Fokus pada perubahan Korekasi kesalahan Kebutuhan user Adaptasi jika ada evolusi lingkungan PL dan perangkat keras

Aktifitas Pengembangan RPL Aktifitas pada RPL berbeda-beda sesuai paradigma atau model proses yang dipilih Aktifitas terdiri dari 2 bagian besar Aktifitas teknis / dasar pengembangan atau aktiitas operasional Aktifitas payung Aktifitas penjaminan kualitas PL ( software quality assurance ) Aktifitas manajemen konfigurasi Aktifitas manajemen proyek Aktifitas untuk peningkatan kematangan proses pengembangan dan kemampuan organisasi pengembang

Aktifitas Pengembangan RPL Sehingga ada 5 kategori kegiatan saat pengembangan PL Aktifitas teknis / dasar pengembangan Aktifitas penjaminan kualitas PL Aktifitas manajemen konfigurasi Aktifitas manajemen proyek Aktifitas peningkatan kematangan proses dan kemampuan organisasi

Aktifitas Pengembangan RPL Ditinjau dari aktivitasnya, maka PL adalah Mendefinisikan proses pengembangan yang digunakan Mengelola proyek pengembangan Mendeskripsikan / menspesifikasikan produk perangkat lunak yang dikehendaki Merancang produk Implementasi rancangan atau coding Testing Memadukan bagian-bagian produk dan testing secara keseluruhan Maintenain Manajemen konfigurasi Melakukan penjaminan kualitas produk yang dihasilkan Kegiatan untuk peningkatan kematangan proses pengembangan dan kemampuan organisasi pengembang

Aktifitas Pengembangan RPL

Aktifitas Pengembangan RPL Contoh Proses design terdiri dari aktifitas Melakukan perancangan sistem/arsitektur Melakukan perancangan basis data (optional) Melakukan perancangan interface Memilih atau mengembangkan algoritma (optional) Malakukan perancangan rinci (perancangan objek)

Aktifitas Pengembangan RPL Aktifitas perancangan basis data terdiri dari Melakukan review terhadap basis data relational Melakukan review terhadap basis data berorientasi objek Membuat rekomendasi pembelian

Aktifitas Payung Pengembangan RPL Berkaitan dengan administrasi dan pengelolaan aktivitas-aktivitas teknis Pelacakan dan pengendalian proyek perangkat lunak Review teknik secara formal Penjaminan kualitas PL Manajemen konfigurasi PL Penyiapan dan produksi dokumen Manajemen resiko

Kematangan Proses Software Engineering Institute (SEI) mengembangkan model kematangan kemampuan organisasi dalam mengelola proyek pengembangan PL → “process maturity” Model yang dikembangkan Capability Maturity Model (CMM) Kemampuan organisasi menciptakan produk berkualitasi bergantung pada banyak faktor baik teknis maupun manusia Faktor manusia menyangkut Kompetensi individu Manajemen Proses

Personal Software Process (PSP) Menyediakan metode estimasi dan perencanaan yang menunjukkan bagaimana cara melacak kinerja dibandingkan dengan rencana Mendefinisikan ketrampilan yang harus dimiliki rekayasawan Digunakan untuk mngembangkan kebiasaan pemrograman tertentu yang terukur ( lama coding, berapa linecode, berapa cacat )

Team Software Process (TSP) Sasaran: Membangun tim yang diarahkan sendiri 3-20 rekayasawan Menetapkan tujuan sendiri Menetapkan proses dan rencana sendiri Melakukan pelacakan pekerjaan Cara pengelolaan tim Meningkatkan CMM Menyediakan peningkatan untuk menuju organisasi yang matang Memberi fasilitas pengajaran mengenai tim di universitas dan industri

Team Software Process (TSP) TSP menekankan pada inisiatif tim dan interaksi bottom-up untuk peningkatan derajat profesionalisme di antara rekayasawan

CMM Ada 5 level Level 1: Initial Level 2: Repeatable Organisasi belum mempunyai metode formal, konsisten dan standar mengenai cara pembangunan sistem Masing-masing pengembang bertindak sebagai seniman, anarki Level 2: Repeatable Telah ada konsensus di organisasi mengenai cara melakukan sesuatu tapi belum diformalkan dan tertulis Proses pengembangan sistem stabil lewat manajemen biaya dan jadwal, namun keberhasilan bergantung pada intuisi manajer proyej

CMM Ada 5 level Level 3: Defined Level 4: Managed Level 5: Optimizing Telah terdapat proses pengembangan sistem yang formal dan terdokumentasi Inspeksi dilaksanakan Level 4: Managed Organisasi telah menerapkan pengukuran proses formal dan terhadap produknya Level 5: Optimizing Usaha meningkatkan bagian proses yang ditemukan masih lemah dan tidak efisien Gagasan dan teknologi yang inovatif