Pert Emu an 2

Pengenalan Rekayasa Perangkat Lunak

1

Cakupan materiKonsep dasar Perangkat lunak dan Rekayasa Perangkat Lunak (Software Engineering) :

Biaya PL Software Quality Attribute Standar kualitas Takaran Jaminan Kualitas Pemahaman dasar tentang software engineering Keberadaan software engineering

Tanggung Jawab profesional dan etika Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)

Rekayasa Perangkat Lunak

2

Biaya perangkat lunak (software cost)


3

Software Quality Attribute (1)Ciri-ciri (atribut) kualitas menurut lembaga penjamin mutu PL (ISO, ANSI, IEEE, dll): Correctness (kebenaran), dg mengacu pada:

Kesesuaian antara kode program dg spesifikasi Kebebasan aplikasi aktual pada sistem PL

Reliability (tahan uji) Didasari pada correctness dan availability (ketersediaannya) Sebagai suatu kemungkinan bahwa sistem ini mampu memenuhi suatu kegunaan (tergantung spesifikasinya) untuk sejumlah masukan percobaan di bawah kondisi masukan dan rentang waktu yang telah ditentukan.Rekayasa Perangkat Lunak 4

Software Quality Attribute (2)User friendliness (mudah digunakan), dibagi 3:

Adequacy (kecukupan) Learnability (mudah dipelajari) Robustness (antisipasi kesalahan)Readability (mudah dibaca) Extensibility (mudah diperluas) Testability (mudah untuk diuji/ditelusuri)

Maintenatibility (mudah dirawat)

Efficiency (efisiensi) Portability (mudah didistribusikan)Rekayasa Perangkat Lunak 5

Ukuran jaminan kualitasUkuran membangun (constructive measures)

Aplikasi yg konsisten pada metode di seluruh fase proses pembangunan Penggunaan perlatan/ tools yang memadai Pembangunan PL pd basis kualitas yg tinggi di akhir tahapan Perawatan yang konsisten pada dokumenasi pengembangan Analisis program yang statis Analisis program yang dinamis Pemeilihan test case yang sistematis Pencatatan yang konsisten pada analisis produk Pengalaman pengembang (developer) dalam mempelajari strategi dan teknik yang tepat dalam membangun PLRekayasa Perangkat Lunak 6

Ukuran analitik (analytical measures)

Ukuran organisasi (organization measures)

Krisis perangkat lunakMasalah yang muncul:

Estimasi jadwal dan biaya yang seringkali tidak tepat Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software Kualitas software yang kurang baik.Bagaimana mengembangkan software Bagaimana memelihara software ynag ada, yang berkembang dalam jumlah besar Bagaimana mengimbangi permintaan software yang makin besar.Rekayasa Perangkat Lunak 7

Kurangnya pengetahuan tentang:

Mitos dalam perangkat lunak (Management)Mitos1:

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 program sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments

Mitos2:

Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software.Realitasnya : Memang buku tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan jaman ( out of date ).

Mitos3:

Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian harde concept.Rekayasa Perangkat Lunak 8

Mitos dalam perangkat lunak (Customer)Mitos1:

Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian. Realitasnya : Definisi awal yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pem-bentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting. Karakteristik di atas dapat ditentukan hanya sete-lah adanya komunikasi antara customer dan developer. Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Kenyataannya memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu. 9 Rekayasa Perangkat Lunak

Mitos2:

Mitos dalam perangkat lunak (Praktisi)Mitos1:

Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding.Realitasnya : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software.

Mitos2:

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 or-ganisasi.Rekayasa Perangkat Lunak 10

Tantangan PL:Tantangan warisan (dikembangkan bertahuntahun dengan org2 yang berbeda Tantangan heterogensis (distribusi & teknologi Tantangan pengiriman (bagaiaman mengirim sistem yang besar dan kompleks cepat dan dg kualitas tetap terjaga.


11

Pemahaman SE:Definisi (1)IEEE Standar 610.12The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. R. FairleyTechnological and managerial discipline of software products that are developed and modified on time and within cost estimates. D.L. ParnasMulti-person construction of multiversion software. Bauer, 1969...the establishment and use of sound engineering principles in order to obtainRekayasa Perangkat Lunak 12

Pemahaman SE:Definisi (2)Parnas, 1974Software engineering is programming under at last one of the following two conditions: (1). More than one person is involved in the construction an/or use of the programs. (2). More than one version of the program will be produced Dennis, 1975Software engineering is the application of principles, skills, and art to the design and construction of programs and systems of programs Boehm,1979The practical aaplication of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operatie, and mainten themRekayasa Perangkat Lunak 13

Pemahaman SE:Definisi (3)Boehm, 1981The application of sicence and mathematics by which the capabilitites of computer equipment are made useful to man via computer programs., procedures, and associated documentation. Fairley, 1985Software engineering is the technological and managerial discipline concerned with the systematic production and maintenance of software products that are developed and modified on time and within cost estimates Sommerville, 1989Software engineering is concerned with building software systems which are large than would normally be tackled by a single individual, uses engineering principles in the development of these systems and is made up of both technical and non technical aspects.


14

Pemahaman SE:Definisi (4)IEEE, 1993The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; tha is the application of engineering to software Pomberger, 1996Software enigeering is the practical application of scientific knowledge for the economical production and use of highquality software


15

Pemahaman SE:Definisi (5)Rangkumansoftware engineering (Rekayasa Perangkat Lunak) merupakan disiplin ilmu pengetahuan (sains) dan seni serta ilmu rekayasa atau teknik yang berkaitan dengan semua aspek dalam membangun/menghasilkan sebuah perangkat lunak yang mampu:

Tepat waktu Tepat anggaran Meningkatkan kinerja Mengoperasikan prosedur sistem dengan benar

RPL merupakan teknologi yang harus digunakan oleh setiap orang yang akan membangun PL, dg melalui serangkaian proses, menggunakan sekumpulan metode dan alat bantu (tools) Intinyabagaimana melakukan usaha supaya sebuah PL yang dibuat dapat memenuhi kriteria yang diinginkan.Rekayasa Perangkat Lunak 16

Pelaku dalam RPLManajer

Manajer Manajer Manajer Manajer

proyek konfigurasi penjamin kulitas PL bidang lainnya (sesuai kebutuhan)

Software Developer

Analis sitem Desainer Programmer Inspektor PL Pengontrol perubahan Staf administrasi Humas Pencatat teknis Administrator database Administrator jaringan

Pendukung


17

Kode etik profesiKonfidensialitas (menghormati klien) Tidak boleh menerima pekerjaan di luar kompetensinya Hak kekayaan intelektual (HaKI) Penyalahgunaan komputer, hack, crack, ngegame, dll


18

Kode etik internasionalDigagas oleh masyarakat profesional di Amerika (1999) yang tergabung dalam ACM/IEEE Makna yang terkandung:

Prinsip-prinsip kesepakatan yang dihubungkan dg tingkah laku dan keputusan yg dibuat oleh para ahli profesional Masyarakat profesional: praktisi, pengajar, manajer, supervisor, pengambil kebijakan. Yang diatur: Masyarakat dan kepentingannya Klien dan atasan (pelayanan terbaik) Produk (jaminan mutu)

Manajemen Profesi Kolega Diri sendiri (ada usaha untuk mengupdate ipteknya)Rekayasa Perangkat Lunak 19

Hubungan RPL, ilkom, & Rekayasa SistemIlmu komputer berkaitan erat dengan teori dan konsep-konsep dasar tentang komputer dan aplikasinya. RPL berkaitan dengan praktik pembangnan perangkat lunak hingga pengiriman PL ke pelanggan. Teori ilmu komputer masih kurang memadai jika dijadikan sebagai penyangga RPL sehingga ada bahasan khusus mengenai RPL


20

CASE tools (1)CASE Computer Aided Software Engineering Suatu peralatan baik HW maupun SW komputer yg digunakan untuk menyediakan pendukung otomatis dalam aktivitas pembangunan PL. 7-anmeningkatkan produktivitas dlm proses pembangunan PL secara signifikan Dikelompokkan dalam 2 kategori:

Upper-CASE Mendukung aktivitas proses pembangunan tahap awal (tahap

analisis kebutuhan dan desain)

LowerMendukung aktivitas pembangunan di tahap akhir 9programming, programming, debuging, dan testing)Rekayasa Perangkat Lunak 21

CASE tools (2)Penggunaan CASE tools:

Graphical editorsmembuat model sistem Data dictionariesmengatur unit-unit proyek GUI builders mengkonstruksi antarmuka pemakai Debuggermencari kesalahan yg mungkin terjadi Automated translatorspembangkitan source code program otomatis Compilator integratedmembuat antarmuka, koding, hingga membentuk aplikasi yg bisa dijalankan Instalator kitmembuat file instalasi/setup dllRekayasa Perangkat Lunak 22

SOFTWARE DEVELOPMENT LIFE CYCLERekayasa Perangkat Lunak 23

Proses GenerikSpesifikasi 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.


24

Proses Rekayasa Perangkat LunakBiasanya, spesifikasi tidak lengkap/menyimpang dari biasanya (anomalous) Lebih menghilangkan pembedaan sampai spesifikasi, desain, dan manufacture Tidak dalam bentuk fisik untuk menguji sistem Software tidak bisa wear-out. maintenance bukan berarti mengganti komponen


25

Berbagai model proses perangkat lunakModel waterfall, Model prototyping, Model evolutionary Model Spiral Reuse Based Development


26

Model WaterfallRequirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance


27

Model waterfall (Count)Requirements analysis and definition Pembentukan kebutuhan System and software design Mengubah kebutuhan-kebutuhan menjadi bentuk karakteristik yang dimerngerti perangkat lunak Implementation and unit testing Penulisan program Integration and system testing Memeriksa program, mencari kesalahan Operation and maintenance Pemeliharaan sistem, menambahkan fungsiRekayasa Perangkat Lunak 28

Problems Model WaterfallJarang sekali proyek yang prosesnya bisa dilakukan secara sequencial. Sukar bagi customer untuk secara explisit mengemukakan semua kebutuhannya. Customer harus sabar. Developer sering menunda pekerjaan. Anggota tim harus menunggu anggota lainnya menyelesaikan tugasnya.


29

Model PrototypingSering terjadi customer menjabarkan objektif umum mengenai software yang diminta, tetapi tidak bisa mendefinisakan input, proses, output yang diminta secara detail. Disisi lain, developer menjadi tidak yakin terhadap efisiensi algoritma, kemampuan adaptasi terhadap sistem operasi, atau bentuk interaksi mesin dengan orang. Untuk mengatasi situasi tersebut, bisa digunakan pendekatan Prototype Paradigm.Rekayasa Perangkat Lunak

30

Model Prototyping (Count.1)listen to customer build/revise mockup

customer testdrives mock-up


31

Model Prototyping (Count.2)


32

Model prototyping (Count.3)Prototype Paradigm dimulai dengan mengumpulkan kebutuhan-kebutuhan customer. Developer dan customer bertemu dan mendefinisikan obyektif software secara menyeluruh, mengidentifikasi kebutuhan-kebutuhan yang diketahui dari area pekerjaan. Setelah itu dibuat Quick Design. Quick Design difokuskan pada representasi aspek software yang bisa dilihat customer/user (misal: format input dan output). Quick Design cenderung ke pembuatan prototipe. Prototipe dievaluasi customer/user dan digunakan untuk menyempurnakan kebutuhan software yang akan dikembangkan.Rekayasa Perangkat Lunak 33

Problems Prototyping ModelCustomer melihat prototipe tersebut sebagai versi dari software.

Pada saat produk tersebut harus dibangun ulang supaya level kualitas bisa terjamin, customer akan mengeluh dan meminta sedikit perubahan saja supaya prototipe tersebut bisa berjalan.

Development membuat implemetasi yang kompromitas dengan tujuan untuk memperoleh prototipe pekerjaan secara cepat. Dampaknya adalah sistem operasi atau bahasa pemrograman yang dipergunakan tidak tepat, algoritma tidak efisien.


34

Evolutionary Model


35

Evolutionary Model (Count.1)


36

Evolutionary Model (Count.2)Evolutionary Model (Componen Assembly)

Bangun komponen jika ada


37

Evolutionary Model (Count.3)


38

Reuse BasedSoftware Re-engineering

Apakah itu? Restrukturisasi atau menulis ulang sebagian atau keseluruhan dari sistem yang telah ada tanpa merubah fungsionalitasnya.

Kapan? Ketika sebagian tetapi tidak semua sub sistem yg besar membutuhkan perawatan yg sering

Ketika HW dan SW sudah lama hampir tak berfungsi

Bagaimana? Sistem bisa di restrukturisasi dan didokumentasi ulang untuk membuat menjadi mudah dalam perawatan

Mengapa? Mengurangi resiko

SW yang baru dibangun membawa resiko yg tinggi Biaya untuk re-engineering sering lebih kecil dibanding membangun SW baru. Rekayasa Perangkat Lunak 39

Mengurangi biaya

Software Reengineering (Count.1)System specificationForward engineering Forward engineering

Design and implementation

Ne w system

Existing software system Software re-engineering Software re-engineering

Understanding and transformation

Re-engineered system

cost cost


40

Reverse engineeringAnalisis SW kembali dalam tahap pemahaman dlm desain dan spesifikasinya Bisa sebagian proses re-engineering atau sebagian spesifikasi sistem untuk diimplementasi ulang Membangun database dan bangkitkan program informasi dari proses ini Mengapa? Kode aslinya telah dalam keterbatasan dimana sudah terlalu lama, misal kebutuhan memori, kinerja, dll Perawatan terbentur pada struktur dan program yang rusak sehingga membutuhkan kerja yg sangat keras Program secara otomatis distrukturisasi ulang untuk menghilangkan beberapa bagian yang tidak beres dalam kondisi yang sangat kompleks.Rekayasa Perangkat Lunak 41

Pert Emu an 2

Documents

Transcript of Pert Emu an 2