Upload presentasi
Presentasi sedang didownload. Silahkan tunggu
1
Software Development Life Cycle (SDLC)
Rekayasa Perangkat Lunak Ramos Somya
2
Definisi SDLC Software Development Life Cycle (SDLC) adalah proses mengembangkan atau mengubah suatu sistem perangkat lunak dengan menggunakan model-model dan metodologi yang digunakan orang-orang untuk mengembangkan sistem perangkat lunak sebelumnya (berdasarkan best practice atau cara-cara yang sudah teruji baik). SDLC muncul pada tahun 1960an untuk mengembangkan sistem skala besar secara fungsional untuk para konglomerat pada saat itu.
3
Tahapan Umum dalam SDCL
Inisiasi (initiation) ditandai dengan pembuatan proposal proyek PL. Pengembangan konsep sistem (system concept development) mendefinisikan lingkup konsep termasuk dokumen lingkup sistem, analisis manfaat biaya, manajemen rencana, pembelajaran kemudahan sistem.
4
... Perancanaan (planning)
mengembangan rencana manajemen proyek dan dokumen perancanaan lainnya. Menyediakan dasar untuk mendapatkan sumber daya yang dibutuhkan untuk memperoleh solusi. Analisis kebutuhan (requirement analysis) menganalisis kebutuhan pemakai sistem perangkat lunak (user) dan mengembangkan kebutuhan user. Membuat dokumen kebutuhan fungsional.
5
... Desain (desaign) dokumen desain fokus pada bagaimana dapat memenuhi fungsi-fungsi yang dibutuhkan. Pengembangan (development) mengkonversi desain sistem ke sistem informasi yang lengkap termasuk melakukan instalasi lingkungan sistem yang dibutuhkan, membuat basis data dan menyiapkan prosedur pengujian, pengkodean, memperbaiki program.
6
... Integrasi dan pengujian (integration and test)
mendemonstrasikan sistem perangkat lunak bahwa telah memenuhi kebutuhan yang dispesifikasikan dalam dokumen kebutuhan fungsional. Implementasi (implementation) implementasi perangkat lunak pada lingkungan produksi (lingkungan user).
7
... Operasi dan pemeliharaan (operations and maintenance)
memelihara sistem informasi pada lingkungan produksi. Disposisi (disposition) mendeskripsikan aktifitas akhir dari pengembangan perangkat lunak dan membangan data yang sebenarnya sesuai dengan aktifitas user.
8
Model Proses Analisis dan desain sering dikelompokkan sebagai proses sistem / rekayasa informasi karena pada tahapan inilah informasi mengenai kebutuhan perangkat lunak dikumpulkan dan diintegrasikan. Ada beberapa model proses SDLC yang tersedia dan masing-masing memiliki kelebihan dan kelemahan. Hal terpenting adalah mengenali pelanggan (customer) dan memilih model proses SDLC yang sesuai dengan karakter pelanggan dan pengembang.
9
... Model proses yang ada sekarang adalah model proses yang memodifikasi model dasar SDLC, yaitu: Model Waterfall Model Prototype Model Rapid Application Development (RAD) Model Iteratif (Evolutionary Model) Model Spiral Model V Model Componentbased Development Model Model Extreme Programming
10
Model Waterfall Model SDLC air terjun (waterfall) sering juga disebut model sekuensial linier (sequential linear) atau alur hidup klasik (classic life cycle). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengkodean, pengujian dan tahap pendukung (support).
11
...
12
... Analisis kebutuhan perangkat lunak
proses pengumpulan kebutuhan dilakukan dengan intensif untuk menspesifikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan user. Spesifikasi kebutuhan PL pada tahap ini perlu didokumentasikan. Desain mengubah kebutuhan PL dari tahap analisis ke bentuk desain sistem agar dapat diimplementasikan menjadi program. Mencakup desain PL, basis data, arsitektur PL, antar muka dan prosedur pengkodean.
13
... Pembuatan kode program
desain diubah ke program perangkat lunak melalui proses pengkodean sistem. Hasil tahap ini adalah program komputer yang sesuai dengan desain pada tahap sebelumnya. Pengujian pengujian dari sisi lojik dan fungsional dan memastikan semua modul telah diuji untuk menghindari error.
14
... Pendukung (support) meliputi tahap pemeliharaan, backup dan restore data saat program dipakai oleh user di lingkungannya.
15
... Pada penerapannya, sangat jarang mode air terjun dapat dilakukan sesuai urutannya, karena: Perubahan spefisikasi perangkat lunak terjadi di tengah alur pengembangan. Sangat sulit bagi pelanggan untuk mendefinisikan semua spesifikasi di awal pengembangan. Pelanggan sering kali butuh contoh (prototype) untuk menjabarkan spesifikasi kebutuhan sistem secara lengkap. Pelanggan tidak sabar untuk mengakomodasi perubahan yang diperlukan di akhir pengembangan.
16
... Model air terjun menjadi dasar bagi model proses lain dalam melakukan perbaikan model pengembangan perangkat lunak. Model air terjun sangat cocok dipakai bagi pelanggan yang sudah dipahami dan kemungkinan terjadinya perubahan kebutuhan selama pengembangan PL kecil. Model air terjun struktur tahap pengembangan sistem telas, dokumentasi dihasilkan di setiap tahap. Tahap dijalankan setelah tahap sebelumnya dijalankan.
17
Model Prototype Sebagian besar customer hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Model Prototype dimulai dari tahap mengumpulkan kebutuhan pelanggan terhadap PL yang akan dibuat. Lalu dibuatlah program prototype agar pelanggan lebih terbayang dengan apa yang sebenarnya dibutuhkan. Program prototype biasanya program yang belum jadi dan akan dievaluasi sampai sesuai dengan kebutuhan dan keinginan pelanggan.
18
...
19
... Mock-up adalah sesuatu yang digunakan sebagai model desain yang digunakan untuk mengajar, evaluasi sistem, promosi atau keperluan lain. Sebuah mock-up disebut sebagai prototype perangkat lunak jika mampu menyediakan sebagian fungsi sistem perangkat lunak dan memungkinkan pengujian desain sistem PL. Iterasi terjadi pada pembuatan prototype sampai sesuai dengan kebutuhan dan keinginan pelanggan.
20
... Kelemahan model Prototype:
Pelanggan dapat sering mengubah atau menambahkan spesifikasi kebutuhan. Pengembang lebih sering memgambil kompromi dengan pelanggan untuk mendapatkan prototype dengan waktu yang cepat sehingga pengembang lebih sering melakukan segala cara (tanpa idealis) guna menghasilkan prototype untuk didemokan kepada pelanggan.
21
... Catatan dalam Model Prototype:
Melakukan perjanjian antara pengembang dan pelanggan agar tidak terjadi iteratif tanpa akhir. Hal ini juga untuk mencegah membengkaknya biaya pembuatan dan efisiensi waktu. Model Prototype cocok dipakai untuk menjabarkan kebutuhan pelanggan secara detail karena pelanggan sering kali kesulitan menyampaikan kebutuhannya. Model Prototype kurang cocok untuk aplikasi dengan skala besar, karena membuat prototype untuk aplikasi skala besar akan sangat memakan waktu, tenaga dan biaya.
22
Model RAD (Rapid Application Development)
RAD adalah model proses pembangunan PL yang incremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini. Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.
23
... Model RAD akan membagi tim pengembang menjadi beberapa tim untuk mengerjakan beberapa komponen secara paralel.
24
...
25
... Pemodelan bisnis memodelkan fungsi bisnis untuk mengetahui informasi apa yang terkait proses bisnis, informasi apa saja yang harus dibuat, siapa yang membuat informasi itu dan proses apa saja yang berkaitan dengan informasi itu. Pemodelan data memodelkan data apa saja yang dibutuhkan berdasarkan pemodelan bisnis dan mendefinisikan atribut dan relasinya dengan data-data yang lain.
26
... Pemodelan proses mengimplementasikan fungsi bisnis yang sudah didefinisikan terkait dengan pendefinisian data. Pembuatan aplikasi mengimplemantasikan pemodelan proses dan data menjadi program. RAD menganjurkan pemakaian komponen yang sudah ada jika dimungkinkan. Pengujian dan pergantian menguji komponen yang sudah dibuat. Jika sudah teruji maka beralih ke pembuatan komponen berikutnya.
27
... Kelemahan model RAD: Untuk pengembangan PL skala besar memerlukan sumber daya manusia yang besar pula, yaitu untuk membentuk tim-tim untuk mengembangkan komponen-komponen. Jika tidak ada persetujuan untuk mengembangkan proyek secara cepat (rapid), maka proyek dengan model ini akan gagal karena akan bingung mendefinisikan kebutuhan user. Jika PL yang akan dibuat tidak bisa dimodulkan, maka model RAD tidak dapat digunakan. Tidak cocok untuk PL dengan resiko teknis sangat tinggi, misalnya melibatkan teknologi baru yang belum dikuasai pengembang.
28
... Model RAD cocok diterapkan jika:
Anggota tim sudah berpengalaman mengembangkan perangkat lunak yang sejenis. Pengembang sudah memiliki komponen-komponen sistem yang bisa dipakai kembali dalam proyek tersebut.
29
... Dari dasar konsep model RAD ini, kemudian muncul model-model yang memodifikasi model RAD, yaitu Pengembangan Perangkat Lunak Tangkas (Agile Software). Pada model ini, diperlukan interaksi yang baik antara tim pengembang dan pelanggan supaya pelanggan dapat tangkas menangani perubahan yang terjadi. Contoh model tangkas ini adalah: Pengembangan Scrum (Scrum Programming) Pengembangan Pemrograman Ekstrim (Extreme Programming)
30
Model Extreme Programming
Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini mengijinkan tim pengembang untuk berkomunikasi langsung dengan pelanggan atau user atau sesama pembuat program (programmer). Ciri khas dari model ini adalah adanya komunikasi yang dilakukan setiap hari atau setiap kali ditemukan hal-hal yang kurang jelas. Model ini sangat memerlukan umpan balik (feedback) sehingga diperlukan anggota tim yang aktif dan berkualitas.
31
... 4 nilai penting dalam XP:
Communication/Komunikasi : komunikasi antara developer dan klien sering menjadi masalah. Karena itu komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas juga diperhitungkan.
32
... Simplicity/sederhana: Menekankan pada kesederhanaan dalam pengkodean : “What is the simplest thing that could possibly work?” Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
33
... Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu). Courage / Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.
34
...
35
Model Iteratif (Evolutionary Model)
Model iteratif mengkombinasikan proses-proses pada model air terjun dan iteratif pada model prototype. Model iteratif akan menghasilkan versi-versi perangkat lunak yang sudah mengalami perubahan fungsi untuk setiap penambahannya (increment). Bersifat Iteratif, hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses.
36
...
37
... Elementelement dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
38
... Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan.
39
... Model iteratif cocok digunakan jika staff yang dimiliki memiliki tingkat pergantian (turnover) yang tinggi sehingga staff tidak dapat terus ikut dalam pengembangan PL. Mampu mengakomodasi perubahan secara fleksibel. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.
40
Model Spiral Model Spiral memasangkan iteratif pada model prototype dengan kontrol dan aspek sistematik yang diambil dari model air terjun. Model Spiral menyediakan pengembangan dengan cara cepat dengan perangkat lunak yang memiliki versi yang terus bertambah fungsinya (increment). Pada iterasi awal yang akan dihasilkan adalah prototype, sedangkan pada iterasi akhir adalah PL yang sudah lengkap.
41
... Model Spiral dibagi menjadi beberapa kerangka aktifitas atau disebut juga wilayah kerja (task region), yaitu: Komunikasi dengan pelanggan (customer communication) membangun komunikasi yang baik antara pengembang dan pelanggan. Perancanaan (planning) mendefinisikan sumber daya, waktu dan informasi terkait dengan proyek.
42
... Analisis Resiko (risk analysis)
diperlukan untuk memperkirakan resiko dari sisi teknis maupun manajemen Rekayasa (engineering) membangun satu atau lebih representasi dari aplikasi perangkat lunak (dapat juga berupa prototype)
43
... Konstruksi dan peluncuran (construction and release)
mengkonstruksi, mengkaji, melakukan instalasi dan menyediakan dukungan terhadap user (dokumentasi dan pelatihan) Evaluasi pelanggan (customer evaluation) mendapatkan umpan balik berdasarkan evaluasi .
44
... Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik.
45
...
46
... Setiap wilayah kerja terdiri dari kumpulan pekerjaan (task set) yang tergantung pada karakteristik proyek yang sedang dikerjakan. Semakin besar suatu proyek, maka kumpulan pekerjaan di dalam setiap wilayah juga semakin banyak. Model Spiral dilakukans searah jarum jam dimulai dari sumbu proyek.
47
... Model Spiral merupakan model yang bisa memberikan jaminan kualitas yang paling baik untuk aplikasi berskala besar. Cocok untuk suatu proyek dengan target waktu dan biaya yang tidak terlalu ketat.
48
Model V V model adalah metode pengembangan perangkat lunak yang mengijinkan pada setiap prosesnya untuk dilakukan testing dan validasi. Jadi proses baru menggunakan hasil dari proses lama sebagai acuannya. Ini memungkinkan meminimalisasikan kesalahan pada prosesnya.
49
...
50
... Kelebihan V Model: Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frame Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya Penyesuaian yang cepat pada projek yang baru Memudahkan dalam pembuatan dokumen projek Biaya yang murah dalam perawatan dan modifikasinya
51
... Kekurangan V Model: Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi. Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.
52
... Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik. Toolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment). Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT.
53
Terima Kasih
Presentasi serupa
