Sasaran Agar mahasiswa dapat:

Presentasi berjudul: "Sasaran Agar mahasiswa dapat:"— Transcript presentasi:

1 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

2 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

3 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

4 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 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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, baris kode). Tidak begitu sesuai dengan program-program besar (katakan, 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.

23 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

24 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

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

26 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

27 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

28 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

29 Aktifitas Pengembangan RPL

30 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)

31 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

32 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

33 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

34 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 )

35 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

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

37 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

38 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