REKAYASA PERANGKAT LUNAK

Presentasi berjudul: "REKAYASA PERANGKAT LUNAK"— Transcript presentasi:

1 REKAYASA PERANGKAT LUNAK
DIAN NURDIANA, M.KOM

2 Proses PL Proses PL merupakan aktifitas yang saling terkait (koheren) untuk menspesifikasikan, merancang, implementasi dan pengujian sistem perangkat lunak

3 Fungsi Model Proses Fungsi utama model proses pengembangan perangkat lunak : Menentukan tahap-tahap yang diperlukan untuk pengembangan perangkat lunak. Menentukan urutan pelaksanaan dari tahap-tahap tersebut dalam rangka pengembangan perangkat lunak. Menentukan kriteria transisi/perpindahan dari satu tahap ke tahap berikutnya.

4 Model Proses yang baik Suatu model proses yang baik dan terstruktur akan (Boehm, 1988): menentukan urutan tahap dalam suatu proses menciptakan kriteria transisi untuk maju ke tahap selanjutnya Suatu proses model harus bisa menangani hal-hal sebagai berikut: Kualitas Requirement yang berubah-ubah Kompleksitas

5 PROSES PERANGKAT LUNAK
Serangkaian kegiatan dan hasil yang berhubungan dengannya, yang menuju pada dihasilkannya produk perangkat lunak. Kegiatan-kegiatan mendasar yang umum bagi semua proses Perangkat Lunak : Spesifikikasi Perangkat Lunak  Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan. Pengembangan (Perancangan dan Implementasi) Perangkat Lunak  Perangkat lunak yang memenuhi spesifikasi harus di produksi Validasi Perangkat Lunak  Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan. Evolusi Perangkat Lunak  Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.

6 System Development Proses
Sistem yang ada Perencanaan Analisis Perancangan Implementasi Pemeliharaan Metode, Teknik, atau Tools (alat bantu ) Pemicu Permasalahan Kesempatan Instruksi Pelaku Sistem Informasi Proses Evolusi Pengembangan Sistem Validasi Prinsip Pengembangan Libatkan Pengguna Sistem Gunakan Pendekatan Pemecahan Masalah Bentuklah Fase dan Aktivitas Dokumentasikan Sepanjang Pengembangan Bentuklah Estándar Kelola Proses dan Proyek Membenarkan System Informasi sebagai Investasi Modal Jangan Takut untuk Membatalkan atau Merevisi Lingkup Bagilah dan Takhlukkan Desainlah Sistem untuk Pertumbuhan dan Perubahan Keuntungan Sistem Informasi Peningkatan keuntungan perusahaan Pengurangan biaya bisnis Biaya dan keuntungan sistem Peningkatan pangsa pasar Perbaikan relasi pelanggan Peningkatan efisiensi Perbaikan pembuatan keputusan Pemenuhan peraturan lebih baik Kesalahan lebih sedikit Perbaikan keamanan Kapasitas lebih besar Memecahkan masalah meraih kesempatan memenuhi instruksi Sistem yang baru

7 Tujuan Proses Perangkat Lunak
Memperkenalkan model proses PL Menggambarkan beberapa model proses dan kapan digunakan Menggambarkan outline model proses untuk rekayasa kebutuhan, pengembangan PL, testing dan evolusi Mengenalkan teknolodi CASE untuk mendukung aktifitas proses PL

8 DEFINISI SIKLUS HIDUP Jika ditinjau dari sisi definisi, siklus hidup memiliki beberapa definisi sebagai berikut?? Dari Gustafson ( dalam buku Theory and Problems of Software Engineering, 2002 ) definisi ini menyatakan bahwa siklus hidup adalah urutan dari kegiatan yang ada di dalam sebuah pengembangan perangkat lunak. Dari Keyes ( dalam buku Software Engineering Handbook, 2005 ) definisi ini menekankan bahwa sebuah perangkat lunak bisa saja mengalami sebuah siklus hidup tergantung dari proses pengembangannya mulai dari ide dasar sampai lahir nya perangkat lunak itu sendiri. Dari IEEE ( IEEE Std 1016 – 1998 Recommended Practice for Software Design Description ) dari standar IEEE 1016, ditekankan bahwa siklus hidup adalah segala sesuatu yang lebih berdasar kepada urutan waktu dibandingkan proses yang terjadi.

9 SIKLUS HIDUP Kesimpulan dari 3 definisi Siklus Hidup diatas adalah bahwa siklus hidup perangkat lunak merupakan urutan hidup sebuah perangkat lunak berdasarkan perkembangan perangkat lunak yang ditentukan oleh pengembang perangkat lunak itu sendiri…

10 DEFINISI PROSES Jika ditinjau dari sisi definisi, prose perangkat lunak memiliki beberapa definisi sebagai berikut?? Dari Sommerville ( dalam buku Software Engineering Edisi 6, 2001 ) Proses dinyatakan sebagai kumpulan aktivitas yang menuju kesebuah produksi perangkat lunak. Dalam kegiatan/aktivitas melibatkan pemograman dengan bahasa pemograman tertentu, kegiatan lain seperti desain, hingga keproses evolusi. Dari Pressman ( dalam buku Software Engineering Edisi 5, 2001 ) Proses perangkat lunak dipandang sebagai suatu lapisan dari Rekayasa Perangkat Lunak. Dari Gustafson ( dalam buku Theory and Problems of Software Engineering, ) Proses lebih menekankan pada kegiatan atau aktivitas yang dijalankan dalam menyusun atau membangun sebuah perangkat lunak. Sehingga jenis proses perangkat lunak lebih banyak mengarah ke penggambaran diagram aktifitas (DFD), use case, dsb

11 Software Layer (Lapisan Perangkat Lunak)
Fokus kualitas : fondasi utama dari RPL adalah kualitas dari perangkat lunak itu sendiri. Proses : untuk mencapai kualitas yang diinginkan tersebut dibutuhkan sebuah proses dari pengembangan perangkat lunak. Metode : langkah – langkah teknis yang merupakan implementasi dari lapisan proses (pelaksanaan analisa, desain perangkat lunak dan implementasi program). Utilitas : utilitas – utilitas yang digunakan dalam proses pengembangan RPL. Utilitas itu berupa alat untuk pengembangan perangkat lunak untuk bahasa pemograman dan basis data.

12 Model Proses Perangkat Lunak
 Menurut Ian Sommerville: Model Pengembangan Waterfall Model Pengembangan Prototyping (Evolusioner) Model Pengembanagan formal Model Pengembangan perakitan komponen-komponen guna ulang

13 Model Proses Perangkat Lunak
Menurut Roger S.Pressman: Linier sequential model Prototyping model Rapid Aplication development (RAD) model Evolutionary software process model terdiri dari: Increment Model  Spiral model WINWIN Spiral Model Conccurent development model Component based development Formal method model 4th Generation technique paradigm

14 Alasan munculnya banyak model proses
Selain Model proses diatas masih banyak proses model lainnya, Model proses muncul dikarenakan : Kompleksitas masalah semakin besar  Melibatkan tim dalam pengembangan software sehingga membutuhkan abstraksi. Memelihara pengembangan sehingga membutuhkan standarisasi.

15 Linier sequential model

16 Linear sequential Model (Model Sekuensial Linear)/Model Waterfall
Model ini adalah model klasik yang mengusung pengembangan  perangkat lunak yang sistematis, berurutan/sekuensial dimulai pada tingkat dan kemajuan system pada seluruh persyaratan dalam analisis, perancangan (desain), pengkodean, pengujian (testing), hingga ke tahap pemeliharaan dalam membangun software (perangkat lunak).

17 Linear sequential Model (Model Sekuensial Linear)/Model Waterfall
Tahap analisis: pada tahap ini berlangsung proses pengumpulan kebutuhan secara lengkap untuk dianalisis dan didefinisikan kebutuhan apa saja yang harus dipenuhi oleh program yang akan dibuat, seperti memahami domain permasalahan, tingkah laku, unjuk kerja dan interface (antar muka). Tahap desain: proses ini melibatkan empat atribut sebuah program yaitu struktur data, arsitektur, perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Tahap pengkodean: proses penterjemahan desain ke dalam bentuk bahasa mesin yang dapat dilakukan secara mekanis. Tahap pengujian: proses ini dikerjakan setelah kode dirancang dan difokuskan pada fungsi dan jumlah kesalahan untuk diperbaiki. Tahap pemeliharaan: meliputi penyesuaian atau perubahan yang berkembang seiring dengan adaptasi perangkat lunak dengan kondisi atau situasi sebenarnya setelah disampaikan kepada konsumen atau pelanggan.

18

19 Linear sequential Model (Model Sekuensial Linear)/Model Waterfall
Kelebihan metode ini antara lain mudah diaplikasikan karena urutan- urutan pengerjaan sudah sering dipakai; selain itu juga cocok untuk software berskala besar dan yang bersifat umum; yang paling penting, karena langkah-langkahnya sangat sekuensial, pengerjaan proyek akan mudah dikontrol dan terjadwal dengan baik. Namun, terdapat pula beberapa kelemahan yang menjadi kekurangan dari metode waterfall ini, seperti kurang fleksibel, dikarenakan rincian prosesnya harus benar-benar jelas dan tidak boleh diubah-ubah. Apabila dikerjakan dengan melampaui tahap yang seharusnya maka proses desain yang sebelumnya itu akan berubah total dan memakan waktu yang banyak jika harus mengulang proses. Model waterfal ini sangat sesuai digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas dan apabila kebutuhan pengguna telah dimengerti dengan baik. Selain itu, juga apabila waktu yang tersedia juga masih cukup banyak.

20

21 Prototyping model

22 Prototyping model Metode ini menyajikan gambaran yang lengkap dari sistem, terdiri atas model kertas, model kerja dan program. Pihak pengembang akan melakukan identifikasi kebutuhan pemakai, menganalisa sistem dan melakukan studi kelayakan serta studi terhadap kebutuhan pemakai, meliputi model interface, teknik prosedural dan teknologi yang akan dimanfaatkan. Model ini digunakan jika customer tidak menjelaskan detail kebutuhan input, proses atau output, sehingga developer tidak dapat memastikan algoritma yang akan dipakai, kesesuaian sistem operasi atau bentuk user interface. Prototyping model dimulai dengan mendengarkan kebutuhan user. Engineer dan customer bertemu dan menentukan semua tujuan software dan menentukan kebutuhan- kebutuhan. Developer kemudian membangun prototype dan user menguji coba prototype untuk memberikan feedback. Prototype dapat dijalankan sebagai sistem yang pertama. User bisa mendapatkan pengertian dari sistem yang sesungguhnya dan developer dapat membangun sistem dengan segera.

23 Prototyping model Tahap Pengumpulan kebutuhan: pada tahap ini, pelanggan dan pengembang saling bantu dalam mendefinisikan format seluruh perangkat lunak, menentukan keperluan dan garis besar sistem yang akan dirancang. Tahap Quick design: membangun rancangan global sebagai contoh bagi user Tahap Pembangunan Prototipe: proses perancangan sementara yang fokusnya kepada penyajian kepada pelanggan, termasuk pengujian dan penyempurnaan. Tahap Evaluasi Pelanggan: di mana pelanggan melakukan pengujian terhadap prototipe yang ada dan pengembang memperhalus analisis kebutuhan pemakai. Tahap Pembuatan dan Implementasi: tahap ini termasuk proses desain (rancang), pengkodean dan testing.

24 Prototyping model Keunggulan model ini adalah sifatnya yang sangat interaktif sehingga pengembang dan pengguna (pemakai) dapat terus berinteraksi selama pengerjaan tahapan-tahapan tersebut. Peran aktif pemakai ini dapat menghemat waktu dalam pengembangan sistem dan bila terdapat kesalahan atau ketidaksesuaian keinginan, pemakai dapat segera memberitahukannya sehingga pengembang dapat secepatnya melakukan penyesuaian. Kelemahan model ini antara lain, akibat adanya quick design, kadang pemakai tidak menyadari bahwa perangkat lunak yang ditunjukkan masih berupa blue print sehingga tidak ada jaminan terhadap kualitas secara keseluruhan dan pemeliharaan jangka panjangnya. Dari sisi pengembang, karena ingin menyegerakan selesainya proyek, sering menggunakan bahasa pemrograman yang sederhana dalam membuat prototipe tanpa memikirkan lebih lanjut program yang lebih kompleks untuk membangun sistem yang sebenarnya. Model Prototyping ini sangat sesuai diterapkan untuk kondisi yang beresiko tinggi di mana masalah-masalah tidak terstruktur dengan baik, terdapat fluktuasi kebutuhan pemakai yang berubah dari waktu ke waktu atau yang tidak terduga, bila interaksi dengan pemakai menjadi syarat mutlak dan waktu yang tersedia sangat terbatas sehingga butuh penyelesaian yang segera. Model ini juga dapat berjalan dengan maksimal pada situasi di mana sistem yang diharapkan adalah yang inovatif dan mutakhir sementara tahap penggunaan sistemnya relatif singkat.

25 Rapid Aplication development (RAD) model

26 Rapid Aplication development (RAD) model
RAD merupakan incremental software process yang menekankan pada siklus development yang singkat. Model ini mengunakan pembuatan berdasarkan komponen, menekankan penggunaan kembali code dan code generation. Jika requirement telah diketahui dengan pasti dan scope project mendesak, RAD proses memungkinkan team development untuk sistem fungsional keseluruhan dalam periode waktu yang sangat singkat (misalnya hari). RAD model dapat digunakan untuk project yang dapat dipisah, misalnya ada 1 project besar, dibagi 3, dikerjakan oleh team yang berbeda-beda (dari analisis sampai testing) kemudian diintegrasikan. Jika menggunkan RAD model, kualitas team harus solid dan punya disiplin tinggi.

27 Rapid Aplication development (RAD) model
Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan.[1] Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

28 Rapid Aplication development (RAD) model
Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan : Component based construction ( pemrograman berbasis komponen bukan prosedural). Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada. Pembangkitan kode program otomatis/semi otomatis. Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun. Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat. Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

29 Rapid Aplication development (RAD) model
Tahap Pemodelan Bisnis: dibuat agar dapat menjawab pertanyaan-pertanyaan berikut: informasi apa yang mengontrol proses bisnis? Informasi apa yang didapat? Siapa yang mendapatkannya? Untuk siapa informasi itu ditujukan? Siapa yang akan memprosesnya? Tahap Pemodelan Data: informasi-informasi yang dipadu dari pemodelan bisnis dipilah-pilah ke menjadi sekumpulan objek data yang masing-masing objek diidentifikasikan dan ditentukan hubungan antara objek- objek tersebut. Tahap Pemodelan Proses: aliran informasi yang didapat dalam proses pemodelan data diolah sedemikian untuk dapat menopang fungsi-fungsi bisnis. Prosesnya dikreasikan untuk menambah, memodifikasi, menghapus dan atau mendapatkan kembali sebuah objek data. Tahap Pembuatan Aplikasi: RAD dapat saja memakai kembali komponen program yang sudah ada bila dimungkinkan, atau membuat komponen yang dapat digunakan lagi bila diperlukan di masa mendatang. RAD juga diasumsikan menggunakan teknik generasi keempat (4GT). Tahap Pengujian dan Pergantian: Proses RAD menekankan pada pemakaian kembali yang memungkinkan berkurangnya keseluruhan waktu pengujian, namun komponen harus diuji dan harus dilatih secara penuh dan terintegrasi.

30 Rapid Aplication development (RAD) model
Kelebihan model RAD: tahap-tahap RAD membuatnya mampu untuk menggunakan kembali komponen yang ada (reusable object), karena setiap komponen software dikerjakan secara terpisah dengan tim-tim tersendiri sehingga dapat digunakan juga untuk aplikasi lain yang pada akhirnya akan menghemat waktu.  Penggunaan tim yang terpisah untuk mengerjakan pekerjaan yang berbeda membuat pekerjaan lebih cepat dalam proses integrasi dan efisien terhadap waktu tanpa mengacaukan aplikasi. Kelemahan model RAD: Tidak begitu cocok untuk proyek dengan skala besar karena dibutuhkan sumber daya manusia yang semakin banyak seiring dengan semakin banyaknya komponen yang dikerjakan, selain itu, semakin besar proyek, semakin kompleks pula koordinasi yang dibutuhkan.  Dalam waktu yang singkat, rasanya sulit untuk pengembang dan pemakai berkomitmen untuk melaksanakan berbagai kegiatan untuk melengkapi sistem. Apalagi bila sistem ternyata tidak dapat dimodularisasi sementara sistem mempunyai resiko teknik yang tinggi. Model RAD sangat tepat diterapkan untuk sistem yang telah jelas dan lengkap kebutuhannya, di mana terdapat komponen-komponen yang dapat dipakai kembali dalam proyek yang berskala kecil dengan waktu pengembangan perangkat lunak yang singkat.

31 Evolutionary software: Increment Model

32 Evolutionary software: Increment Model
Pada tahun 1971 Harlan Mills (IBM) mengusulkan semestinya perkembangansoftware lebih tepat daripada membuatnya. Kita mulai membangun system sangat sederhanayang mendukung, memiliki fungsi sederhana, kemudian menambahkan dan mengembangkansoftware tersebut. Semestinya software pengembangan seperti bunga atau pohon. Nama lainperangkat lunak tersebut adalah incremental model Model incremental (Incremental waterfall model) merupakan perbaikan dari modelwaterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini adalahmembangun software secara meningkat (increment) berdasarkan kemampuan fungsional.Model incremental ini diaplikasikan pada sistem pakar dengan penambahan rules yangmengakibatkan bertambahnya kemampuan fungsional sistem. Model incremental merupakanmodel continous rapid prototype dengan durasi yang diperpanjang hingga akhir prosespengembangan. Pada model prototipe biasa, prototipe hanya dibuat pada tahap awal untuk mendapatkan kebutuhan user.Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa perangkatlunak perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses membangunberhenti jika produk telah mencapai seluruh fungsi yang diharapkan.Pada awal tahapan dilakukan penentuan kebutuhan dan spesifikasi. Kemudian dilakukanperancangan arsitektur software yang terbuka, agar dapat diterapkan pembangunan per-bagian pada tahapan selanjutnya.

33 Evolutionary software: Increment Model

34 Evolutionary software: Increment Model
Kombinasikan element-element dari waterfall dengan sifat iterasi/perulangan. Element-element 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. 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. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup. Mampu mengakomodasi perubahan secara fleksibel. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

35 Evolutionary software: Increment Model
Kelebihan model ini adalah mampu mengakomodasi perubahan secara fleksibel, dengan waktu yang relatif singkat dan tidak dibutuhkan anggota/tim yang banyak untuk menjalankannya. Kekurangannya adalah tidak cocok untuk proyek berukuran besar (lebih dari baris coding) dan sulit untuk memetakan kebutuhan pemakai ke dalam rencana spesifikasi tiap-tiap hasil dari increament. Model ini cocok dipakai untuk proyek kecil dengan anggota tim yang sedikit dan ketersediaan waktu yang terbatas.

36 Evolutionary software: Spiral model

37 Evolutionary software: Spiral model
Tahap Liason: pada tahap ini dibangun komunikasi yang baik dengan calon pengguna/pemakai Tahap Planning (perencanaan): pada tahap ini ditentukan sumber-sumber informasi, batas waktu dan informasi-informasi yang dapat menjelaskan proyek. Tahap Analisis Resiko: mendefinisikan resiko, menentukan apa saja yang menjadi resiko baik teknis maupun manajemen. Tahap Rekayasa (engineering): pembuatan prototipe Tahap Konstruksi dan Pelepasan (release): pada tahap ini dilakukan pembangunan perangkat lunak yang dimaksud, diuji, diinstal dan diberikan sokongan-sokongan tambahan untuk keberhasilan proyek. Tahap Evaluasi: Pelanggan/pemakai/ pengguna biasanya memberikan masukan berdasarkan hasil yang didapat dari tahap engineering dan instalasi.

38 Evolutionary software: Spiral model
Kelebihan model ini adalah sangat mempertimbangkan resiko kemungkinan munculnya kesalahan sehingga sangat dapat diandalkan untuk pengembangan perangkat lunak skala besar. Pendekatan model ini dilakukan melalui tahapan- tahapan yang sangat baik dengan menggabungkan model waterfall ditambah dengan pengulangan-pengulangan sehingga lebih realistis untuk mencerminkan keadaan sebenarnya. Baik pengembang maupun pemakai dapat cepat mengetahui letak kekurangan dan kesalahan dari sistem karena proses-prosesnya dapat diamati dengan baik. Kekurangan model ini adalah waktu yang dibutuhkan untuk mengembangkan perangkat lunak cukup panjang demikian juga biaya yang besar. Selain itu, sangat tergantung kepada tenaga ahli yang dapat memperkirakan resiko. Terdapat pula kesulitan untuk mengontrol proses. Sampai saat ini, karena masih relatif baru, belum ada bukti apakah metode ini cukup handal untuk diterapkan. Model Boehm sangat cocok diterapkan untuk pengembangan sistem dan perangkat lunak skala besar di mana pengembang dan pemakai dapat lebih mudah memahami kondisi pada setiap tahapan dan bereaksi terhadap kemungkinan terjadinya kesalahan. Selain itu, diharapkan juga waktu dan dana yang tersedia cukup memadai.

39 RUP

40 RUP Life Cycle (Ambler, 2005)

41 Penjelasan RUP Inception. Tahapan ini merupakan tahapan paling awal dimana aktivitas penilaian terhadap sebuah proyek perangkat lunak dilakukan. Elaboration. Tujuan dari tahap ini adalah untuk mendapatkan gambaran umum kebutuhan, persyaratan dan fungsi-fungsi utama perangkat lunak. Construction. Tujuan dari tahapan ini adalah membangun perangkat lunak sampai dengan saat perangkat lunak tersebut siap digunakan. Transition. Tahap ini difokuskan pada bagaimana menyampaikan perangkat lunak yang sudah jadi pada pengguna

42 Microsoft Solutions Framework

43 Microsoft Solutions Framework
MSF Adalah seperangkat Proses software Engineering yang Terdiri dari prinsip, model, disiplin, konsep, Dan pedoman Yang flexible dan Scalable untuk memberikan Solusi Teknologi Informasi Bagi developers agar mencapai sukses dalam SDLC, tidak terbatas hanya untuk pengembangan aplikasi tetapi juga untuk deployment, jaringan atau proyek infrastruktur lainnya. Versi pertama diperkenalkan tahun dan hingga saat ini versi terakhir (versi 4) dikeluarkan tahun 2005.

44 Microsoft Solutions Framework
Envisioning: think about what needs to be accomplished and identify constraints Planning: plan and design a solution to meet the needs and expectations within those constraints Developing: build the solution Stabilizing: validate that the solution meets the needs and expectations... "synch and stabilize“ Deploying: deploy the solution

45 Tahapan MSF Envisioning, merupakan tahapan bagi tim pengembang untuk menentukan tujuan dan batasan masalah yang akan dibuat. Planning, merupakan tahapan bagi tim pengembang untuk mengidentifikasi sistem yang telah ada dan yang akan dikembangkan, termasuk mempersiapkan rencana kerja, identifikasi kebutuhan, analisis persyaratan sistem, melakukan estimasi biaya dan jadwal pengerjaan, serta melakukan desain sebagai solusi. Developing, merupakan tahapan bagi tim pengembang untuk mengimplementasikan hasil desain melalui pembuatan kode program, membuat dokumentasi kode program, dan mempersiapkan daftar test case untuk tahap selanjutnya. Stabilizing, merupakan tahapan bagi tim pengembang untuk melakukan pengujian hasil implementasi (component testing; database testing; infrastructure testing; security testing; integration testing; user acceptance and usability testing; stress, capacity, and performance testing) dan membuat dokumentasi proyek pengembangan aplikasi. Deploying, merupakan tahapan bagi tim pengembang untuk menginstalasi sistem aplikasi di tempat konsumen dan melakukan review pekerjaan, serta meminta persetujuan akhir dari konsumen atas kesesuaian aplikasi yang dikembangkan.

46 Kelebihan dan kekurangan MSF
Mencakup solusi SDLC mulai dari project inception sampai live deployment, terutama dengan adanya pendefinisian visi dan scope yang jelas dan disepakati bersama (customer-focused mindset). Menggunakan gabungan Waterfall model Dan Spiral model sehingga tahapan proses lebih terarah namun tetap dapat di-iterasi. Organisasi team dalam kelompok-kelompok kerja kecil dengan model peers (tanpa project manager), tidak seperti model tradisional (top-down dan hierarchical ) Informasi terbuka bagi semua team (zero-defect mindset) sehingga menjamin kualitas (team menjadi lebih commit dan accountable). Kekurangan Tahap proses selanjutnya harus menunggu penyelesaian tahap sebelumnya Tidak dapat mennentukan dengan pasti waktu proses karena adanya kemungkinan iterasi Memerlukan team yang cukup berpengalaman dan matang di bidangnya

47 Metodologi FAST

48

49

50 Component Assembly Model (CAM/Model Perakitan Komponen)

51 Component Assembly Model
Model ini merupakan gabungan dari berbagai sifat dan karakter dari model spiral Boehm dan sangat erat keterikatannya dengan model RAD (Rapid Application Development) model karena model CAM ini menggunakan peralatan-peralatan dan GUI (Graphic User Interface) untuk membangun software. Dengan kata lain, pembuatan aplikasinya dibuat dari paket perangkat lunak yang berisi serangkaian komponen yang telah ada sebelumnya. Namun, waktu yang dibutuhkan dapat disesuaikan atau lebih efektif ketimbang harus mengerjakan program dari awal.

52 Component Assembly Model
Tahapan-tahapan Model ini adalah: Tahap Identifikasi calon-calon komponen (kelas objek); Tahap melihat komponen-komponen dalam pustaka; Tahap mengekstrak komponen jika ada; Tahap membangun komponen jika tidak ada; Tahap menyimpan komponen baru pada pustaka; Tahap mengkonstruksi iterasi ke-n dari sistem.

53 Component Assembly Model
Kelebihan model ini adalah tinggal mencaplok atau menggunakan program atau komponen yang sudah ada dan menyusunnya menjadi sebuah program yang lebih kompleks dan berkembang sesuai dengan kebutuhan user/pengguna sehingga dapat mengefisienkan penggunaan waktu dan tenaga.  Selain itu, model ini juga menyediakan kemampuan untuk memvisualisasikan hasil rakitan dengan kesanggupan untuk mengukur, menganalisa, merancang dan merancang ulang program. Kekurangan model ini adalah seringnya program atau komponen-komponen terdahulu tidak kompatibel atau sejalan dengan model perakitan komponen ini sehingga untuk perusahaan berskala kecil akan kesulitan menemukan komponen yang sesuai untuk dirakit. Model ini sangat sesuai digunakan oleh perusahaan besar yang sudah berpengalaman mengembangkan software. Mereka dapat memanfaatkan software-software yang telah umum dikembangkan sebelumnya menjadi bentuk baru dari software yang ingin dikomersilkan.

54 The Concurrent Development Model

55 The Concurrent Development Model
Concurrent process model cocok digunakan untuk pengembangan aplikasi client/server yang terdiri atas satu set komponen yang fungsional. Terdapat dua dimensi aktivitas yang digambarkan oleh model ini sebagai berikut. Dimensi sistem: terdapat tiga proses di dalamnya yakni perancangan, perakitan (assembly) dan penggunaan (use). Dimensi komponen: terdapat dua kegiatan utama yaitu perancangan dan realisasi. Concurrency (pertemuan) dapat diperoleh dengan dua cara: 1) sistem dan komponen kegiatan (aktifitas) terjadi secara simultan dan dapat diperagakan dengan memanfaatkan pendekatan yang berdasar pada status sebelumnya; 2) aplikasi client/server yang bersifat unik/khas di mana dapat diterapkan pada banyak komponen yang tiap-tiap komponen bisa dirancang dan direalisasikan secara serentak.

56 Fourth Generation Techniques/Model Teknik Generasi ke-4/4GT

57 Fourth Generation Techniques/Model Teknik Generasi ke-4/4GT
Istilah Fourth Generation Techniques (4GT) mencakup seperangkat peralatan perangkat lunak yang berfungsi sebagai perangkat bantu yang memudahkan seorang pengembang software mengaplikasi beberapa karakteristik software pada tingkat yang tinggi, yang akan menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi (persyaratan khusus) yang dibuat oleh sang pengembang perangkat lunak. Dewasa ini, 4GT tools dipakai sebagai bahasa non prosedur untuk DataBase Query, Pembentukan laporan (Report Generation), Manipulasi data, Definisi dan interaksi layar (screen), Pembentukan object dan source ( Object and source generation ), Kemampuan grafik yang tinggi, dan Kemampuan spreadsheet.

58 Fourth Generation Techniques/Model Teknik Generasi ke-4/4GT
Tahapan-tahapan model 4GT dapat diringkas sebagai berikut. Tahap Pengumpulan Kebutuhan: tahap ini dimulai dengan mengumpulkan serangkaian kebutuhan yang nantinya akan diterjemahkan ke dalam prototipe. Namun, apabila pelanggan tidak yakin dengan apa yang diperlukan dan fakta-fakta tidak jelas diketahui maka prototipe tidak dapat dikerjakan oleh peralatan 4GT. Tahap Merancang Strategi: tahap ini dibutuhkan untuk proyek besar yakni dengan menterjemahkan kebutuhan menjadi prototipe operasional  agar tidak timbul masalah yang sama jika dibuat dengan model konvensional. Namun, untuk proyek skala kecil tahap ini dapat dihilangkan dengan  langsung melakukan implementasi dengan menggunakan bahasa generasi keempat (4GT). Tahap Implementasi Menggunakan Bahasa Keempat: untuk skala kecil tahap ini dapat langsung dilakukan ketika kebutuhan telah jelas, dan untuk proyek besar tahapan ini dijalankan setelah dirancang prototipe operasional. Implementasi yang menggunakan 4GT memudahkan pengembang software untuk menjelaskan hasil yang diharapkan yang nantinya akan diterjemahkan ke dalam bentuk kode sumber dan kode objek. Tahap Produksi: Tahap ini merupakan langkah terakhir yakni mengubah implementasi  4GT ke dalam hasil akhir berupa produk.

59 Fourth Generation Techniques/Model Teknik Generasi ke-4/4GT
Kelebihan model ini adalah pengurangan waktu dan peningkatan produktivitas yang besar. Kekurangan model ini adalah kemungkinan akan sulit memanfaatkan alat bantu/peralatan/tools 4GT dibandingkan dengan menggunakan bahasa pemrograman yang konvensional, selain itu terdapat juga masalah dalam hal kode sumber yang tidak efisien. Di samping itu, pemeliharaan sistem software besar yang dikembangkan oleh 4GT juga masih sedang dalam proses pengkajian. Model ini diaplikasikan untuk mengembangkan perangkat lunak yang memakai bentuk bahasa khusus atau notasi grafik yang dieksekusi/diselesaikan dengan syarat atau ketentuan yang dipahami oleh pemakai/pengguna/kustomer.

60 Validasi Perangkat Lunak
Validasi perangkat lunak, atau verifikasi dan validasi (V&V) ditujukan untuk menunjukkan bahwa sistem sesuai dengan spesifikasinya dan bahwa sistem memenuhi harapan pelanggan. Validasi melibatkan proses pemeriksaan pada setiap tahap proses perangkat lunak dari definisi persyaratan user sampai pengembangan program. Namun demikian mayoritas biaya validasi disediakan setelah implementasi dan sistem operasional diuji.

61 Validasi Perangkat Lunak
Tahap-tahap pengujian: Pengujian unit. Komponen individual diuji untuk menjamin operasi yang benar. Setiap komponen diuji secara independen. Pengujian modul. Modul merupakan sekumpulan komponen yg berhubungan seperti kelas, objek, tipe data abstrak, atau sekumpulan prosedur. Sebuah modul dapat diuji tanpa modul sistem yang lain. Pengujian sub sistem. Fase ini melibatkan pengujian sekumpulan modul yg telah diintegrasikan menjadi sub sistem. Pengujian sistem. Penemuan kesalahan akibat dari interaksi yg tidak diharapkan antara sub sistem dan masalah interface sub sistem. Proses ini berhubungan dengan validasi bahwa sistem telah memenuhi persyaratan fungsional dan non fungsionalnya. Pengujian penerimaan. Sistem diuji dengan data yang dipasok oleh pelanggan sistem dan bukan data uii simulasi.

62 Evolusi Perangkat Lunak
Pengembangan perangkat lunak merupakan kegiatan kreatif dimana sistem perangkat lunak dikembangkan dari konsep awal menjadi sistem yang dapat berjalan. Pemeliharaan perangkat lunak merupakan proses perubahan sistem tersebut setelah digunakan. Rekayasa perangkat lunak dianggap sebagai proses evolusioner dimana perangkat lunak terus diubah selama waktu hidupnya sebagai jawaban atas perubahan lingkungan dan kebutuhan pelanggan.