Metodologi Pengembangan P/L dan SDLC

 

Josua Siregar_11321012_D3TI

Metodologi Pengembangan P/L dan SDLC

Process Model (Model-Model Proses) 

Apa itu Proses Perangkat Lunak? Proses Software adalah sebuah peta jalan (road map) untuk melaksanakan pekerjaan dalam menghasilkan sebuah produk yaitu sebuah Perangkat Lunak yang berkualitas Tinggi.

FRAMEWORK DAN UMBRELA ACTIVITIES

Framework adalah cara standar untuk membangun dan menyebarkan aplikasi. Kerangka Proses Perangkat Lunak adalah dasar dari proses rekayasa perangkat lunak yang lengkap. Kerangka Proses Perangkat Lunak mencakup kumpulan semua umbrela activities. Ini juga mencakup sejumlah aktivitas kerangka kerja yang berlaku untuk semua proyek perangkat lunak.

5 Aktivitas Utama Kerangka Kerja (Framework)

1. Komunikasi (Communication)

Dalam kegiatan ini, komunikasi yang intens dengan pelanggan dan pemangku kepentingan lainnya, serta pengumpulan kebutuhan dilakukan.

2. Perencanaan (Planning)

Dalam kegiatan ini, membahas tugas terkait teknis, jadwal kerja, risiko, sumber daya yang dibutuhkan, dll.

3. Pemodelan (Modeling)

Pemodelan adalah tentang membangun representasi hal-hal di 'dunia nyata'. Dalam aktivitas pemodelan, model produk dibuat untuk lebih memahami persyaratan.

4. Konstruksi (Construction)

Dalam rekayasa perangkat lunak, konstruksi adalah penerapan serangkaian prosedur yang diperlukan untuk merakit produk. Dalam kegiatan ini, membuat kode dan menguji produk untuk membuat produk yang lebih baik.

5. Deployment

Dalam kegiatan ini, produk atau perangkat lunak yang lengkap atau tidak lengkap direpresentasikan kepada pelanggan untuk dievaluasi dan memberikan umpan balik. Atas dasar umpan balik mereka, dilakukan memodifikasi produk untuk pasokan produk yang lebih baik.

Aktivitas-Aktivitas Penyangga (Umbrella Activities)

  1. Risk Management (Manajemen Resiko)
  2. Software Quality Assurance (SQA) (Jaminan Kualitas Perangkat Lunak)
  3. Software Configuration Management (SCM) (Manajemen Konfigurasi Perangkat Lunak)
  4. Measurement (Pengukuran)
  5. Formal Technical Reviews (FTR) (Tinjau Teknis Formal)
MENDEFINISIKAN AKTIVITAS FRAMEWORK
Tindakan-tindakan apa yang sesuai untuk satu aktivitas Framework tertentu sesuai dengan permasalahan yang akan diselesaikan, bagaimana karakteristik-karakteristik orang-orang yang akan mengerjakan pekerjaan, serta siapa para stakeholder yang akan membiayai proyek?

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

Untuk mendeskripsikan bagaimana aktivitas-aktivitas Kerangka Kerja (Framework) dan tindakan-tindakan yang harus dilakukan di dalam masing-masing aktivitas Kerangka Kerja diorganisasi dengan urutan tertentu dan waktu tertentu dibutuhkan sebuah aliran proses (Process Flow).  (Pressman, Roger S., Ph.D. 2002.)



CONTOH MENDEFINISIKAN AKTIVITAS FRAMEWORK

Tindakan-tindakan yang dapat dilakukan pada tahap Komunikasi yaitu :

  1. Pertemuan awal (Inception)
  2. Proses bertanya dan melakukan penelitian (Elicitation
  3. Mendapatkan rincian (Elaboration
  4. Pembicaraan lebih serius (Negotiation
  5. Penulisan spesifikasi (Spesification
  6. Pemeriksaan kembali (Validation)

MENGIDENTIFIKASI HIMPUNAN PEKERJAAN

Elicitation (lebih sering disebut "requirements gathering") adalah tindakan software engineering penting yang terjadi selama aktivitas komunikasi. Tujuan dari requirements gathering adalah untuk memahami apa yang diinginkan berbagai pemangku kepentingan dari perangkat lunak yang akan dibangun.

Untuk proyek kecil yang relatif sederhana, kumpulan tugas untuk pengumpulan persyaratan mungkin terlihat seperti ini:
  1. Buat daftar pemangku kepentingan untuk proyek tersebut.
  2. Undang semua pemangku kepentingan ke pertemuan informal.
  3. Minta setiap pemangku kepentingan untuk membuat daftar fitur dan fungsi yang diperlukan.
  4. Diskusikan persyaratan dan buat daftar akhir.
  5. Memprioritaskan persyaratan.
  6. Perhatikan area ketidakpastian

POLA-POLA PROSES (PROCESS PATTERN)

Process pattern

  1. Menggambarkan proses yang berhubungan masalah yang dihadapi selama pekerjaan rekayasa perangkat lunak,
  2. Mengidentifikasi lingkungan yang menjadi masalah ditemui, dan
  3. Menyarankan satu atau lebih terbukti solusi untuk masalah.
  4. Dinyatakan dalam istilah yang lebih umum, pola proses memberi Anda dengan template [Amb98]—a
  5. Metode yang konsisten untuk menggambarkan solusi masalah dalam konteks proses perangkat lunak.

PRESCRIPTIVE MODELS

Model Proses Perspektif merupakan sebuah Pendekatan yang dianjurkan untuk Software Engineering

THE WATERFALL MODEL 

Model Proses Perspektif merupakan sebuah Pendekatan yang dianjurkan untuk Software Engineering 

Catatan Penting :

  1. Spesifikasi kebutuhan sudah terdefinisi dengan baik dan Stabil
  2. Dilakukan secara linier dari komunikasi sampai deployment
  3. Disebut dengan Classic Life Cycle – pendekatan yang sistematis dan sekuensial

THE V-MODEL



Catatan :

  1. Model V merupakan Varian dari Waterfall Model
  2. Model V menyediakan cara secara visual bagaimana tindakan verifikasi dan validasi yang seharusnya diterapkan pada bagian-bagian pekerjaan di awal
FAKTA TENTANG WATERFALL MODEL
  1. Waterfall merupakan paradigma tertua dalam Software Engineering 
  2. Permasalahan yang muncul pada Waterfall Model 
    • Praktik Software Engineering jarang mengikuti aliran sekuensial, walaupun waterfall dapat mengakomodasi perulangan (iterasi) 
    • Sulitnya costumer membuat spesifikasi kebutuhan secara eksplisit (ketidakpastian alami) 
    • Ketidak sabaran costumer 
  3. Tahapan dalam Waterfall Model cenderung ―Terkunci (Blocking State)

THE INCREMENTAL MODEL



Model Inkremental dapat diterapkan apabila spesifikasi kebutuhan sudah terdefinisi dengan baik, namun lingkup keseluruhan Software Engineering tidak bisa dilakukan secara linear.

Hasil pada tahap pertama seringkali berupa produk inti (core product) dan menjawab Spesifikasi Kebutuhan

EVOLUTIONARY MODELS

  1. Bisnis dan Spesifikasi Kebutuhan Produk sering berubah saat pengembangan Software
  2. Jadwal peluncuran ke pasar yang ketat membuat penyelesaian software yang bersifat lengkap menjadi tidak mungkin
  3. Pada pengembangan selanjutnya kompleksitas semakin tinggi

Kunci Sukses Mengapa Evolutionary Model

  1. Customer Satisfaction
  2. Ketepatan Waktu
  3. Fleksibilitas
  4. Extensibility

PERSONAL SOFTWARE PROCESS (PSP)

PSP membantu insinyur perangkat lunak untuk:

  • Meningkatkan keterampilan memperkirakan dan merencanakan mereka.
  • Buatlah komitmen yang dapat mereka tepati.
  • Mengelola kualitas proyek mereka.
  • Mengurangi jumlah cacat dalam pekerjaan mereka

TEAM SOFTWARE PROCESS (TSP)

Proses perangkat lunak tim (TSP) menyediakan operasional yang ditentukan kerangka proses yang dirancang untuk membantu tim manajer dan insinyur mengatur proyek dan menghasilkan perangkat lunak prinsip-prinsip produk yang ukurannya berkisar dari proyek kecil beberapa ribu baris kode (KLOC) ke proyek yang sangat besar lebih dari setengah juta baris kode. 

TSP dimaksudkan untuk meningkatkan kualitas dan produktivitas proyek pengembangan perangkat lunak tim, agar untuk membantu mereka memenuhi komitmen biaya dan jadwal dengan lebih baik mengembangkan sistem perangkat lunak

AGILE MODEL

Agile adalah proses di mana tim dapat mengelola proyek dengan memecahnya menjadi beberapa tahap dan melibatkan kolaborasi yang konstan dengan para pemangku kepentingan dan peningkatan berkelanjutan dan iterasi di setiap tahap.

Ada 4 poin utama dari Agile:

  • Individu dan interaksi atas proses dan tools
  • Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif
  • Kolaborasi pelanggan atas negosiasi kontrak 
  • Adaptasi terhadap perubahan setelah mengikuti rencana

Agile dapat merujuk pada kerangka kerja untuk mengimplementasikannya, di antaranya:

a. Scrum

b. Kanban

c. Extreme Programming (XP)

d. Adaptive Project Framework (APF).

Yang paling sering digunakan adalah Scrum.

CARA IMPLEMENTASI SCRUM

  1. Tentukan tim scrum pertama anda
  2. Tentukan panjang atau lamanya sprint anda
  3. Tunjuk seorang master scrum
  4. Tunjuk pemilik produk (Product Owner)
  5. Buat backlog produk awal
  6. Rencanakan dan mulailah sprint pertama Anda
  7. Tutup arus dan mulai sprint berikutnya

Referensi:
  1. Pressman, Roger S., Ph.D. 2002. Rekayasa Perangkat Lunak Pendekatan Praktisi (Buku Satu). Yogyakarta: ANDI. 
  2. https://www.scrumguides.org/scrum-guide.html

Komentar

Postingan populer dari blog ini

Matakuliah PPL_Tugas1_D3TI-01_012

Activity Diagram