SESI 2. Software Development Life Cycle (SDLC) Definisi Model SDLC WEDA A. DEWA, S.Kom., MMSI wedadewa@gmail.com 082125876733

Perangkat Lunak (Software) Merupakan program aplikasi berikut dengan dokumentasi dan data yang dibutuhkan agar program dapat beroperasi secara benar Software system terdiri atas : program2, file2, dokumentasi sistem, dokumentasi pengguna 2 tipe produk perangkat lunak : 1. generic; software stand-alone, dibuat suatu perusahaan & dijual di pasar terbuka Cth : wordprocessor, database 2. customised: dibuat berdasarkan permintaan klien Cth : sistem pengaturan lalulintas udara Pengenalan

Karakteristik Perangkat Lunak yang Baik Maintainability; perangkat lunak dimungkinkan untuk berevolusi sesuai kebutuhan perubahan klien Dependability; mencakup reliability, security & safety Perangkat lunak tidak mengalami kerugian fisik & ekonomi pada saat terjadi kerusakan sistem Efficiency; perangkat lunak tidak boros dalam meng-gunakan sumber daya sistem, seperti memory & processor Usability; perangkat lunak harus berguna bagi pengguna, mempunyai interface & dokumentasi yang sesuai dengan pengguna Pengenalan

Software Engineering Merupakan disiplin ilmu engineering yg memperhatikan semua aspek pembuatan perangkat lunak dari tahap awal spesifikasi s.d. pemeliharaan sistem Perbedaan software engineering dgn computer science adalah bahwa computer science lebih memperhatikan teori & metode komputerisasi, sedangkan software engineering menyangkut masalah praktikal pembuatan dan delivery(pengiriman) perangkat lunak Software engineering merupakan bagian dari system engineering, dimana system engineering memperhatikan semua aspek pembuatan sistem berbasis komputer, termasuk perangkat keras, p. lunak & proses.

Penyelesaian Masalah COMPUTER CUSTOMER SCIENCE SOFTWARE ENGINEERING Functions Theories Problem SOFTWARE ENGINEERING Tools and Techniques to Solve Problem

Pada awal pengembangan PL, para programmer langsung melakukan pengkodean PL tanpa menggunakan prosedur atau tahapan pengembangan PL. SDLC adalah proses mengembangkan atau mengubah suatu sistem PL dengan menggunakan model-model dan metodologi yang digunakan orang untuk mengembangkan sistem-sistem PL sebelumnya. Seperti halnya metamorfosis pada kupu-kupu, untuk menjadi kupu-kupu yang indah diperlukan tahapan untuk dilaluinya, sama halnya dengan PL.

Proses perangkat lunak Sebuah kerangka kerja untuk tugas-tugas yang di butuhkan untuk membangun perangkat lunak dengan kualitas tinggi. Pengembangan RPL dapat dikatakan merupakan sebuah teknologi layer/Lapisan Teknologi.

Proses perangkat lunak (lanj) Menurut IEEE, RPL adalah : Aplikasi yang pendekatannya sistematis, disiplin, bisa terukur untuk pengembangan operasional dan pembuatan software. tolls metode proses Fokus kualitas Lapisan Rekayasa Perangkat Lunak

Proses, metode dan tools RPL Pondasi RPL adalah lapisan proses, karena terkait dengan teknologi dan waktu pengembangan. Proses-proses RPL merupakan perekat yang menjaga bentangan-bentangan teknologi secara bersama-sama dan memungkinkan perkembangan perangkat lunak yang tepat waktu dan rasional Metode-metode RPL memberikan teknik bagaimana membangun software. Adapun metode-metode tersebut antara lain menyangkut analisa kebutuhan, desain, pembuatan program, pengujian dan perawatan. Tool-tool pada RPL digunakan untuk memberikan dukungan otomatisasi atau semi otomatis pada proses dan metode-metode yang ada. Sistem yang biasa digunakan untuk mendukung  pengembangan disebut Computer Aided Software Enginering (CASE). CASE mengkombinasikan software, hardware dan database RPL (berisi informasi mengenai analisa, desain, pembuatan program dan pengujian).

Proses, metode dan tools RPL (lanj) Rekayasa adalah analisa, desain, pembuatan, verifikasi dan manajemen teknis (atau sosial). Tanpa memandang entitas yang harus direkayasa, ada beberapa pertanyaan yang harus dijawab. Problem apa yang harus dicarikan solusinya ? Apa saja karakteristik entitas yang digunakan untuk menyelesaikan persoalan tersebut. Bagaimana entitas (dan solusinya) dapat direalisasikan ? Bagaimana entitas akan dibangun ? Pendekatan apa yang akan digunakan untuk mencegah terjadinya kesalahan desain dan pembuatan entitas? Bagaimana entitas akan didukung selama proses adaptasi yang lama, pada saat ada permintaan koreksi, adaptasi dan pengembangan oleh user.

Proses, metode dan tools RPL (lanj) Pekerjaan yang berhubungan dengan RPL bisa dikategorikan ke dalam 3 fase umum tanpa memandang area aplikasi, ukuran proyek atau kompleksitas. Fase tersebut yaitu: Fase Definisi Berfokus pada “apa”(what) => pengembang perangkat lunak harus mengidentifikasi informasi apa yang akan di proses, fungsi dan unjuk kerja apa yang dibutuhkan, tingkah laku sistem seperti apa yang akan di bangun, batasan desain apa yanga ada, dan kriteria validasi apa yang dibutuhkan untuk mendefinisikan sistem yang sukses Fase Pengembangan Berfokus pada bagaimana (how) => bagaimana data dikonstruksikan, bagaimana fungsi-fungsi diimplementasikan sebagai sebuah arsitektur perangkat lunak, bagaimana detail prosedur akan diimplementasikan, bagaimana interface ditandai, bagaimana rancangan akan diterjemanhkan ke dalam bahasa pemrograman serta bagaimana pengujian akan dilakukan. Fase Pemeliharaan Berfokus pada change(perubahan) => berhubungan dengan koreksi kesalahan, penyesuaian dengan lingkungan serta perkembangan yang disebabkan perubahan kebutuhan pelanggan

Proses, metode dan tools RPL (lanj Fase pemeliharaan mengaplikasikan lagi langkah-langkah pada fase definisi dan fase pengembangan, tetapi semua tergantung pada konteks perangkat lunak yang ada. Ada empat tipe perubahan yang terjadi selama fase pengembangan yaitu: Correction => Mengubah software untuk memperbaiki kesalahan-kesalahan yang ada Adaption =>Modifikasi yang dilakukan terhadap software dikarenakan adanya perubahan lingkungan eksternal (misal: CPU, sistem operasi, aturan bisnis, karakter produk eksternal). Enhancement =>Pada saat sofrware dipakai, user meminta tambahan- tambahan fungsi. Sehingga software dikembangkan dari kebutuhan semula. Prevention => Sering disebut software re-enginering, harus dilakukan untuk memungkinkan software bisa sesuai dengan keinginan end user. Pada fase ini dilakukan perubahan-perubahan ke program komputer, sehingga program tersebut bisa dikoreksi, beradaptasi dan dikembangkan dengan mudah.

Model SDLC Waterfall Prototipe Rapid Application Development (RAD) Spiral

Waterfall Model Air terjun menyediakan pendekatan alur hidup PL secara sekuensial atau terurut secara analisis, desain, pengkodean, pengujian dan tahap pendukung.

Waterfall lanj… Tahapan waterfall  Analisis kebutuhan PL Desain Pembuatan Kode program Pengujian Pendukung

Kekurangan waterfall Perubahan spesifikasi PL terjadi di tengah alur pengembangan. Sangat sulit bagi pelanggan untuk mendefinisikan semua spesifikasi di awal alur pengembangan. Pelanggan tidak mungkin bersabar mengamodaasi perubahan yang diperlukan di akhir alur pengembangan.

Kelebihan Struktur tahap pengembangan sistem jelas, dokumentasi dihasilkan setiap tahap pengembangan, dan sebuah tahap dijalankan setelah tahap sebelumnya selesai dijalankan.

Model Waterfall adalah model SDLC yang paling sederhana. Model ini hanya cocok untuk pengembangan PL dengan spesifikasi yang tidak berubah-ubah.

Model Prototipe Sering customer membayangkan kumpulan kebutuhan yang diinginkan tapi tidak terspesifikasikan secara detail dari segi input, proses maupun output. Seorang pengembang PL harus menspesifikasikan sebuah kebutuhan secara detail dari segi teknis dimana pelanggan sering kurang mengerti hal teknis seperti ini.

Model Prototipe Model prototipe dimulai dari mengumpulkan kebutuhan pelanggan terhadap PL yang akan dibuat. Kemudian dibuat program, biasanya program belum jadi hanya simulasi.

Model Prototipe Membangun Memperbaiki Market Mendengarkan pelanggan Uji Pelanggan Mengendalikan Mendengarkan pelanggan

Kelemahan model prototipe Customer sering mengubah-ubah atau menambah spesifikasi kebutuhan karena aplikasi sudah dengan cepat dikembangkan. Pengembang sering mengambil kompromi dengan pelanggan untuk mendapatkan prototipe dengan waktu dengan cepat.

Model Prototipe Model prototipe cocok digunakan untuk menggali spesifikasi kebutuhan pelanggan secara lebih detail tetapi berisiko tinggi terhadap membengkaknya biaya dan waktu proyek

Model Rapid Application Development (RAD)

RAD Rapid Application Development (RAD) merupakan model proses pengembangan software yang linier sequencial yang menggunakan siklus pengembangan yang singkat. Proses RAD memungkinkan untuk membuat �fully functional System� dalam waktu yang sangat singkat (60 � 90 hari).

Fase RAD Bisnis Modelling Aliaran informasi fungsi bisnis dimodelkan untuk bisa menjawab pertanyaan sebagai berikut: 1.      Informasi apa yang dibutuhkan proses bisnis ? 2.      Informasi apa saja yang dihasilkan ? 3.      Siapa yang membuat informasi tersebut ? 4.      Informasi itu dibutuhkan siapa saja ? 5.      Siapa yang memproses informasi tersebur ? Data Modelling Aliran informasi yang telah didefinisikan disempurnakan lagi menjadi kumpulan object data, yang   dibutuhkan untuk mendukung sistem tersebut. Karakteristik (Atau atribut) masing-masing object diidentifikasi dan relasi antara object tersebut didefinisikan.

Fase RAD Proses Modelling - Object data yang telah didefinisikan ditransformasi untuk mendapatkan aliran informasi yang mungkin    mengimplementasikan fungsi bisnis. - Deskripsi proses dibuat untuk menambah, modifikasi, penghapusan, atau pencarian object data. Application Generation Pekerjaan proses RAD dilakukan dengan menggunakan kembali komponen program yang sudah ada (jika memungkinkan) atau membuat komponen yang bisa dipergunakan kembali (jika memungkinkan). Untuk itu, dibutuhkan �automated tool� untuk pembuatan software tersebut. Testing TurnOver Karena proses RAD mempergunakan kembali komponen yang sudah ada, maka beberapa komponen program telah teruji. Hal ini bisa mengurangi waktu pengujian secara keseluruhan, akan tetapi komponen harus tetap di uji

Kelebihan dan kekurangan RAD Rad menekankan perkembangan komponen program yang bisa pakai lagi/Reusabilitas Kekurangan  - Untuk proyek dengan skala besar, RAD memerlukan jumlah orang yang lebih banyak untuk membentuk sejumlah tim RAD. - RAD memerlukan developer dan customer yang Commit terhadap aktifitas yang ketat sesuai dengan time frame yang diberikan - RAD tidak cocok pada saat resiko teknis tinggi. Hal ini bisa terjadi pada saat aplikasi baru menggunakan teknologi baru atau pada saat software yang baru memerlukan derajat kebergantungan yang tinggi terhadap program komputer yang sudah ada.

Model Spiral

Model Spiral Model spiral dibagi menjadi beberapa kerangka aktifitas atau disebut juga wilayah kerja (task region). Banyaknya wilayah kerja biasanya diantara 3 sampai 6 wilayah sebagai berikut : Komunikasi dengan pelanggan (customer communication) Perencanaan (planning) Analisis Risiko (risk analysis) Rekayasa (engineering) Kontruksi dan peluncuran (construction and release) Evaluasi pelanggan (evaluation)

Model Spiral Penerapan model spiral cocok digunakan untuk suatu proyek dengan target waktu dan biaya yang tidak terlalu ketat. Setiap perubahan spesifikasi pasti berisiko pada molornya waktu pekerjaan dan membengkaknya biaya proyek.

Buatlah desain dari kasus berikut Seorang pembeli membeli barang dari internet secara online. sebelum berbelanja dia harus login lebih dahulu. setelah login dia bisa memilih produk dan memasukkan ke dalam keranjang. pelanggan juga dapat mengedit produk yang dibelinya.pelanggan harus mendaftar dulu ke web tersebut. Ketika pembeli membeli barang dagangan untuk pakaian minimal 10 akan mendapat bonus 1 kaos, untuk membeli 5 sepatu akan mendapat bonus 1 tas. Setelah membeli pelanggan dapat membayar melalui transfer bank atau kredit card. Pelanggan juga dapat menerima notifikasi pembayaran dan pembelian setelah melakukan transaksi tersebut. Pelanggan juga dapat membeli barang dg kategori yg berbeda Setelah dibayar barang akan dikirim dalam waktu 15 hari Setelah barang diterima oleh pembeli, pembeli bisa complain terhadap barang yang dikirim karena rusak atau cacat. Barang dijual adalah sepatu dan pakaian.