Workshop
Responsi UAS Software Engineering — Rangkuman Materi
Part 1 — System Analysis & Risk Identification (20%)
Definisi Risk
Risk ditentukan oleh dua komponen utama:
- Probability — kemungkinan gagal mencapai outcome tertentu
- Consequences — dampak dari kegagalan tersebut
Internal risk = risiko yang bisa kita kendalikan
External risk = risiko yang tidak bisa kita kendalikan
Reactive vs Proactive Risk Management
Reactive — tim bereaksi setelah risiko terjadi:
- Mitigation — siapkan resource ekstra untuk "fire fighting"
- Fix on failure — resource diterapkan setelah risiko muncul
- Crisis management — kegagalan tidak tertangani, proyek terancam
Proactive — risiko diidentifikasi dan ditangani sebelum terjadi (prevention, elimination of root causes)
7 Prinsip Software Risk
- Global perspective — lihat risiko dalam konteks sistem dan bisnis
- Forward-looking view — antisipasi risiko masa depan, buat contingency plan
- Open communication — jangan abaikan risiko yang dikemukakan orang lain
- Integrate — pertimbangan risiko harus jadi bagian dari proses software
- Continuous process — pantau terus, modifikasi risiko yang teridentifikasi
- Shared product vision — semua stakeholder berbagi visi yang sama
- Teamwork — gabungkan keahlian semua stakeholder
Kategori Identifikasi Risiko
| Kategori | Deskripsi |
|---|---|
| Product size | Risiko terkait ukuran software |
| Business impact | Batasan dari manajemen/pasar |
| Customer characteristics | Kecanggihan customer dan komunikasi |
| Process definition | Sejauh mana proses sudah didefinisikan |
| Development environment | Ketersediaan dan kualitas tools |
| Technology to be built | Kompleksitas dan novelty teknologi |
| Staff size and experience | Pengalaman teknis dan proyek tim |
Level Risk Management (dari terendah ke tertinggi)
- Crisis management — fire fighting setelah masalah terjadi
- Fix on failure — deteksi dan reaksi cepat setelah terjadi
- Risk mitigation — siapkan resource, tapi tidak eliminasi penyebab
- Prevention — identifikasi dan cegah sebelum menjadi masalah
- Elimination of root causes — hilangkan faktor yang memungkinkan risiko ada
Komponen Risiko
- Performance risk — ketidakpastian produk memenuhi requirements
- Cost risk — ketidakpastian budget terjaga
- Support risk — ketidakpastian software mudah dikoreksi dan ditingkatkan
- Schedule risk — ketidakpastian jadwal dan delivery tepat waktu
Risk Projection (Risk Estimation)
Menilai setiap risiko dari dua sisi: likelihood dan consequences.
4 Langkah risk projection:
- Tentukan skala kemungkinan risiko
- Delineasi konsekuensi risiko
- Estimasi dampak pada proyek dan produk
- Catat akurasi proyeksi
Risk Table — sort berdasarkan probability dan impact (1=catastrophic, 2=critical, 3=marginal, 4=negligible)
Risk Exposure: RE = P × C
(P = probability, C = cost if risk occurs)
Contoh: 80% kemungkinan komponen reuse gagal → 18 komponen harus dibuat manual → biaya $25,200 → RE = 0.80 × $25,200 ≈ $20,200
Risk Mitigation, Monitoring, Management (RMMM)
- Mitigation — bagaimana menghindari risiko?
- Monitoring — faktor apa yang bisa dipantau untuk mendeteksi perubahan probabilitas?
- Management — contingency plan jika risiko menjadi kenyataan?
Part 2 — Testing & Quality Engineering (25%)
Internal vs External Quality
- Internal quality — struktur kode, keterbacaan, dokumentasi
- External quality — crash, pemenuhan requirements, desain UI
7 Prinsip Testing
- Absence of defects fallacy — testing membuktikan ada defect, bukan tidak ada
- Exhaustive testing is impossible — tidak mungkin test semua kemungkinan input
- Start testing early — temukan bug sedini mungkin, biaya fix lebih murah
- Defects are clustered — bug cenderung terkonsentrasi di komponen tertentu
- Pesticide paradox — test suite yang sama terus-menerus tidak akan menemukan bug baru; variasikan
- Context-dependent — pendekatan testing bergantung pada jenis aplikasi
- Verification ≠ Validation
- Verification: "Are we building the software right?" (sesuai spec?)
- Validation: "Are we building the right software?" (sesuai kebutuhan user?)
Level Testing
| Level | Fokus | Contoh |
|---|---|---|
| Unit Testing | Komponen/fungsi individual secara isolasi | Test fungsi login secara terpisah |
| Integration Testing | Interaksi antar modul | Test login mengambil data dari database |
| System Testing | Sistem lengkap terintegrasi | Test seluruh modul e-commerce |
| Acceptance Testing | Perspektif end-user (alpha/beta) | User test fitur social media di real-world |
Teknik Testing
- Black-Box — test berdasarkan requirements, tanpa melihat kode internal → cocok untuk functional & usability
- White-Box — memerlukan pengetahuan struktur kode internal → cocok untuk unit & integration
- Grey-Box — kombinasi keduanya, partial knowledge → cocok untuk integration & API testing
Static vs Dynamic Analysis
| Static Analysis | Dynamic Analysis | |
|---|---|---|
| Eksekusi kode | Tidak | Ya |
| Input | Hanya source code | Build + test inputs |
| Hasil | Bisa ada false positives | Real problems (no false positives) |
| Kelemahan | — | Subject to false negatives |
| Contoh | SonarQube, code review | Code coverage, profiling, testing |
Software Reliability
Definisi: Probabilitas software beroperasi bebas-failure dalam periode tertentu di kondisi tertentu.
Metrik:
- MTBF (Mean Time Between Failures) = MTTF + MTTR
- MTTF = Mean Time to Failure
- MTTR = Mean Time to Repair
Fault Tolerance Techniques
- Redundancy — duplikasi sistem/komponen (contoh: load balancer)
- Graceful Degradation — sistem tetap jalan di kapasitas tereduksi saat komponen gagal
- Recovery Mechanisms:
- Checkpointing & Rollback — simpan state secara berkala
- Failover Systems — otomatis switch ke backup
- Self-Healing — deteksi dan koreksi error tanpa intervensi manusia
Reliability Patterns
- Circuit Breaker — cegah percobaan berulang ke service yang gagal
- Bulkhead — isolasi komponen agar kegagalan satu tidak cascading ke yang lain
- Event-Driven Architecture — decoupled services untuk high availability
Performance Testing
| Jenis | Tujuan |
|---|---|
| Performance Regression | Ukur & bandingkan execution time antar versi |
| Profiling | Temukan bottleneck CPU/memory (flame graphs) |
| Load Testing (JMeter) | Simulasi beban user (throughput, error rate) |
| Stress Testing | Test di luar batas normal → fokus robustness & error handling |
| Soak Testing | Load signifikan dalam durasi panjang → deteksi memory leak |
Part 3 — DevOps, SCM, and Deployment (20%)
Software Configuration Management (SCM)
Definisi: Disiplin yang mengontrol dan melacak perubahan software untuk menjaga integritas sepanjang SDLC.
Mengapa penting:
- Control of Change — cegah error dan inkonsistensi
- Team Collaboration — koordinasi tim besar
- Quality Assurance — jaga integritas software
- Compliance & Traceability — audit trail untuk perubahan
Software Configuration Items (SCI): source code, design docs, user manuals, test scripts, build scripts, requirements specs.
Baseline — versi SCI yang sudah disetujui secara formal; hanya bisa diubah via formal change control.
- Functional Baseline — dari requirements analysis
- Design Baseline — setelah design phase
- Product Baseline — produk final
DevOps
Definisi: Praktik, prinsip, dan budaya yang menyatukan Dev dan Ops untuk deliver software berkualitas tinggi dengan cepat melalui kolaborasi, otomasi, dan feedback loop.
Prinsip:
- Automation — otomasi repetitive task
- CI (Continuous Integration) — merge dan test kode sering ke shared repo (tools: Jenkins, GitHub Actions)
- CD (Continuous Delivery) — kode selalu siap di-deploy ke production
DevOps Toolchain
| Kategori | Tools |
|---|---|
| Planning | Jira |
| Version Control | Git, GitLab |
| Build & CI/CD | Jenkins, Travis CI, GoCD, Spinnaker |
| Containerization | Docker |
| Orchestration | Kubernetes |
| IaC | Terraform, Ansible |
| Monitoring | Prometheus, Grafana |
| Logging | ELK Stack (Elasticsearch, Logstash, Kibana) |
Software Deployment Strategies
| Strategi | Deskripsi |
|---|---|
| Basic | Update semua node sekaligus |
| Rolling | Update subset instance bertahap |
| Multi-Service | Update semua node dengan multiple service serentak |
| Blue/Green | Deploy 2 versi bersamaan, switch traffic |
| Canary | Rilis bertahap ke sebagian kecil user |
| A/B Testing | Route subset kecil user ke fitur baru untuk analisis |
| Shadow | Fork request ke versi baru secara paralel (user tidak sadar) |
Part 4 — Reliability, Security, and Maintenance (20%)
Tipe Software Maintenance
| Tipe | Definisi | Contoh |
|---|---|---|
| Corrective | Fix bug setelah deployment | Koreksi crash di kondisi tertentu |
| Adaptive | Sesuaikan dengan environment baru | Update app untuk iOS versi baru |
| Perfective | Tingkatkan/refinement fitur existing | Tambah filter pencarian baru |
| Preventive | Cegah masalah masa depan, kurangi technical debt | Refactoring kode |
Tantangan Maintenance
- High Complexity — legacy code dan dependencies
- Inadequate Documentation — dokumentasi kurang lengkap
- Resource Constraints — waktu, budget, tenaga terbatas
- Technical Debt — shortcut yang menumpuk
- Changing Requirements — perubahan bisnis/regulasi
Security Vulnerabilities & Threats
- Sniffing/Eavesdropping — mendengarkan traffic jaringan
- Spoofing — menyamar sebagai entitas lain (IP, email, DNS)
- Injection Attacks — injeksi kode via input fields
- Broken Authentication — autentikasi lemah
- XSS — inject script ke halaman web
- Insecure Deserialization — exploitasi data serial
- Insider Threats — user authorized yang menyebabkan harm
- APTs — serangan terus-menerus menarget data sensitif
The "Big Three" Network Security Concepts
- Authentication — memastikan identitas pihak yang berkomunikasi
- Authorization — user punya privilege untuk operasi tertentu
- Confidentiality — komunikasi tanpa diketahui/diubah pihak lain
Security Testing
- Static Analysis — analisis kode tanpa eksekusi (SonarQube)
- Dynamic Analysis — test aplikasi berjalan (Burp Suite)
- Penetration Testing — simulasi serangan nyata
- Fuzz Testing — kirim data random untuk temukan loophole
Part 5 — Metrics, Ethics, and Improvement Strategy (15%)
Software Process Improvement (SPI)
Definisi: Menilai dan meningkatkan proses pengembangan software untuk meningkatkan kualitas, produktivitas, dan prediktabilitas.
Manfaat: Peningkatan kualitas, efisiensi biaya, reduksi risiko, kepuasan customer, keunggulan kompetitif.
Capability Maturity Model (CMM)
Framework yang mendeskripsikan elemen-elemen proses software yang efektif.
| Level | Nama | Deskripsi |
|---|---|---|
| 1 | Initial | Proses tidak terprediksi, reaktif |
| 2 | Repeatable | Manajemen proyek dasar untuk track cost/schedule |
| 3 | Defined | Proses terdokumentasi dan terstandarisasi |
| 4 | Managed | Pengukuran detail dikumpulkan dan dikontrol |
| 5 | Optimizing | Peningkatan berkelanjutan via feedback kuantitatif |
Model SPI Lainnya
- ISO/IEC 15504 (SPICE) — standar internasional penilaian proses software; 6 level: Incomplete → Performed → Managed → Established → Predictable → Optimizing
- Six Sigma — pendekatan data-driven eliminasi defect; metodologi DMAIC (Define, Measure, Analyze, Improve, Control)
Strategi Peningkatan Proses
- Process Assessment — evaluasi proses saat ini (audit, survey)
- Process Modeling & Analysis — visualisasi proses, temukan bottleneck (flowchart, UML)
- Change Management — kelola aspek manusiawi perubahan (komunikasi, training, involvement)
- Continuous Improvement:
- Kaizen — perubahan kecil incremental berkelanjutan
- PDCA Cycle — Plan → Do → Check → Act
Aspek Legal dalam Software Engineering
Intellectual Property Rights:
- Copyright — melindungi kode dan dokumentasi sebagai karya original
- Patent — melindungi invensi baru yang unik (contoh: algoritma page-rank Google)
- Trademark — melindungi nama, simbol, atau logo (contoh: logo Windows)
Software Licenses:
- Proprietary — batasi modifikasi dan redistribusi
- Open Source — izinkan akses, modifikasi, dan berbagi kode (MIT, GPL)
- Freeware/Shareware — gratis atau trial terbatas
Privacy Laws:
- GDPR — regulasi Eropa untuk privasi data; right to be forgotten, consent
- CCPA — regulasi California untuk data collection dan sharing
Prinsip dasar: Data Minimization, Purpose Limitation, Data Security
Etika Profesional Software
Menurut Harvard's Human Flourishing Program, flourishing mencakup: happiness & life satisfaction, mental & physical health, meaning & purpose, character & virtue, close social relationships.
Tanggung jawab software profesional:
- Kepada User — pastikan software aman, secure, dan accessible
- Kepada Masyarakat — pertimbangkan dampak lingkungan dan kesejahteraan sosial