IF3250 · Proyek Perangkat Lunak · UAS Perbaikan (3 Juli 2026)

UAS IF3250 — Catatan Ujian Perbaikan CPMK 4

Tech StackToolsFrameworkArsitekturDSSEKonfigurasi

References: Pressman - Software Engineering, Lecture Slides IF3250, PROJECT_AUDIT.md

1. Overview — Konteks Proyek AutoSix

1. Overview — Konteks Proyek & Kontribusi Saya

AutoSix adalah platform otomasi workflow berbasis web untuk admin portal akademik ITB (Direktorat Pendidikan). Admin dapat menyusun aturan trigger + action secara visual via canvas drag-and-drop, lalu sistem mengeksekusinya di background.

Identitas & PeranM Hazim R Prajoda — 13523009 Peran: Development Team Member

Kontribusi per Sprint (dari Dokumen Scrum)

Sprint	Task ID	Deskripsi	PB
Sprint 1	SB-05	Membuat diagram komponen (bersama 13523037)	—
Sprint 1	SB-07	Menulis bab 1, 2, dan 3 dokumen teknis	—
Sprint 2	SB-11	Mengembangkan high-fidelity prototype dari modul workflow	PB-02
Sprint 2	SB-12	Mengimplementasikan kode frontend katalog trigger/action	PB-02
Sprint 2	SB-16	Melengkapi bab 4, 5, dan 6 dokumen teknis (bersama 13523026)	—
Sprint 3	SB-04	Merancang high-fidelity prototype CRUD workflow (canvas)	PB-02
Sprint 3	SB-05	Mengimplementasi kode frontend CRUD workflow (canvas)	PB-02
Sprint 4	SB-02	Mengimplementasi kode frontend multiple trigger	PB-02
Sprint 4	SB-08	Merancang high-fidelity prototype fitur logging (execution & task log)	PB-04
Sprint 4	SB-09	Mengimplementasi kode frontend untuk menampilkan task log	PB-04
Sprint 4	SB-14	Mengintegrasikan frontend & backend eksekusi workflow & logging (bersama 13523007)	PB-04, PB-09
Sprint 5	SB-05	Membuat tutorial interaktif penggunaan canvas	—
Sprint 5	SB-12	Membuat logo aplikasi	—
Sprint 5	SB-17	Menambahkan indikator persyaratan password pada halaman lupa password	PB-01
Sprint 5	SB-18	Melakukan unifikasi bahasa antarmuka ke Bahasa Inggris	—
Sprint 5	SB-25	Membuat video singkat proyek	—

Ringkasan Area Kontribusi

Frontend (dominan): Canvas workflow CRUD, multiple trigger UI, task log display, login prototype, tutorial interaktif, UI language unification, password indicator

Integrasi: Frontend ↔ backend eksekusi workflow & logging

Dokumentasi: Dokumen Teknis bab 1-6, diagram komponen

Aset: Logo aplikasi, video proyek

2. CPMK 4: Penggunaan Tools, Framework, Platform & Teknologi Data

Definisi CPMK 4 “Menggunakan alat bantu, framework, platform, data teknologi yang tepat pada proyek perangkat lunak” Artinya: dapat memilih teknologi yang sesuai, menjelaskan alasannya, dan mengevaluasi apakah pilihan tersebut tepat setelah proyek selesai.

Relevansi CPMK 4 ke Kontribusiku

Kontribusiku mayoritas di frontend — dan setiap task menuntut pemilihan & penerapan tools yang tepat:

Sprint	Task	Tools/Framework yang Saya Gunakan
Sprint 2	Hi-fi prototype modul workflow	Figma untuk prototyping
Sprint 2	Frontend katalog trigger/action	Next.js + TypeScript, komponen list dengan state management
Sprint 3	Hi-fi prototype CRUD workflow canvas	Figma — merancang UX canvas sebelum implementasi
Sprint 3	Frontend CRUD workflow canvas	@xyflow/react — library node-graph domain-specific
Sprint 4	Frontend multiple trigger	@xyflow/react, custom node types & state
Sprint 4	Hi-fi prototype fitur logging	Figma
Sprint 4	Frontend task log display	Next.js, tabel log dengan real-time update via SSE
Sprint 4	Integrasi eksekusi workflow & logging	Axios ke FastAPI endpoint, sinkronisasi state FE-BE
Sprint 5	Tutorial interaktif canvas	@xyflow/react + custom step/overlay logic
Sprint 5	Unifikasi bahasa antarmuka	Refactoring seluruh string FE ke Bahasa Inggris
Sprint 5	Password indicator	Regex validation + CSS strength indicator pada form

Poin CPMK 4 yang Paling Bisa Saya Pertanggungjawabkan Pemilihan @xyflow/react — saya yang langsung mengimplementasikan canvas CRUD workflow (Sprint 3) dan multiple trigger (Sprint 4) menggunakan library ini. Alasan: domain kami adalah node-graph workflow → @xyflow adalah best-in-class untuk use case ini (aktif dikembangkan, custom node/edge API matang). Ini adalah keputusan DSSE: memilih domain-specific tool yang tepat.

Formula AKB — Draf Esai Siap Pakai

[!important] Gunakan formula AKB: Alat → Kenapa → Bukti implementasi

🟢 Esai 1: Canvas Workflow — @xyflow/react

(Ini yang paling kamu kuasai — kamu yang implementasi langsung)

“Untuk membangun antarmuka canvas drag-and-drop workflow, saya menggunakan @xyflow/react (React Flow). Library ini dipilih karena fitur inti aplikasi adalah manipulasi node-graph secara interaktif — membangunnya dari nol akan sangat tidak efisien dan rentan bug. @xyflow menyediakan abstraksi domain-specific untuk node, edge, dan handle yang langsung sesuai dengan kebutuhan kami. Saya mengimplementasikan custom node types untuk trigger dan action, mengelola state graph (node + edge), dan memastikan serialisasi ke format JSON yang bisa dieksekusi oleh execution engine backend.”

🟢 Esai 2: Prototyping — Figma

(Kamu yang buat hi-fi prototype di Sprint 2, 3, 4)

“Sebelum implementasi, saya selalu membuat high-fidelity prototype menggunakan Figma terlebih dahulu (Sprint 2: workflow canvas, Sprint 3: CRUD canvas, Sprint 4: fitur logging). Tools ini dipilih karena memungkinkan validasi desain UX dengan stakeholder sebelum ada kode — mengurangi risiko rework. Dengan Figma, saya bisa iterasi layout canvas dan flow interaksi secara cepat, lalu menggunakannya sebagai acuan saat implementasi di Next.js.”

🟢 Esai 3: Frontend Stack — Next.js + TypeScript

(Semua task frontend-mu menggunakan ini)

“Untuk seluruh antarmuka pengguna, saya menggunakan Next.js dengan TypeScript. TypeScript dipilih karena tipe data yang ketat sangat krusial di sisi frontend — terutama saat memetakan struktur node/edge dari canvas ke format JSON payload yang dikirim ke backend. Kesalahan tipe data yang terdeteksi di compile-time jauh lebih mudah diperbaiki daripada runtime error yang baru muncul saat user menjalankan workflow. App Router Next.js juga memberikan routing yang terstruktur untuk halaman dashboard, katalog, dan log eksekusi.”

🟡 Esai tentang Backend/Redis/ARQ — Framing yang Aman

(Kamu tahu cara kerjanya tapi bukan yang implement — jawab dari perspektif tim)

“Sebagai bagian dari tim, kami memutuskan menggunakan Redis dan ARQ untuk background job execution. Dari sisi saya sebagai frontend developer, saya mengintegrasikan hasil eksekusi tersebut ke tampilan task log (Sprint 4 SB-09) — di mana setiap node pada canvas menampilkan status real-time dari task_log yang dipush via SSE. Ini membutuhkan pemahaman tentang kontrak API backend dan struktur data task log agar state canvas di frontend tetap sinkron dengan hasil eksekusi di backend.”

Jangan Klaim Implementasi BackendFastAPI, Redis, ARQ, Alembic, PostgreSQL — kamu tahu cara kerjanya dan bisa jelaskan keputusannya sebagai keputusan tim, tapi jangan framing seolah kamu yang coding-nya. Yang implement backend adalah 13523007 dan 13523015.

3. Tech Stack AutoSix & Justifikasi

3.a Tabel Tech Stack

Layer	Teknologi yang Dipilih	Alternatif yang Dipertimbangkan	Alasan Memilih
Frontend	Next.js 16 + TypeScript	Vite/React SPA	SSR-capable, App Router untuk routing terstruktur, TypeScript untuk type safety
Styling	Tailwind CSS v4	Plain CSS, Bootstrap	Utility-first; semantic token system, tidak perlu naming convention CSS
Canvas/Workflow UI	@xyflow/react (React Flow)	Konvas manual, mxGraph	Best-in-class untuk node graph UI; dikembangkan aktif, API matang
Backend	FastAPI + Python	Django, Express.js	Async-native, auto-generate OpenAPI docs, performa tinggi, DX cepat
ORM	SQLAlchemy 2.0	Django ORM, Tortoise ORM	Type-safe queries, migrasi rapi dengan Alembic
Migrasi DB	Alembic	Flyway, Liquibase	Terintegrasi langsung dengan SQLAlchemy, revision auto-generate
Database	PostgreSQL	MySQL, SQLite	ACID-compliant, JSON column support, battle-tested untuk production
Auth	JWT (python-jose) + bcrypt	Session-based, OAuth only	Industry standard; bcrypt dipilih karena passlib sudah unmaintained
Queue/Worker	ARQ + Redis	Celery + RabbitMQ, SQS	ARQ async-native (cocok dengan FastAPI), Redis sudah dipakai untuk hal lain
Real-time Notif	Redis pub/sub + SSE	WebSocket, Polling	SSE lebih ringan dari WebSocket untuk one-way push; Redis pub/sub efisien
Testing BE	pytest	unittest	Framework-native Python, fixture system kuat, readability bagus
Testing FE	Vitest	Jest	Terintegrasi native dengan Vite/Next.js ecosystem, sangat cepat
CI/CD	GitLab CI	GitHub Actions, Jenkins	Proyek di GitLab ITB, native integration
Containerization	Docker + docker-compose	Podman, bare metal	Reproducible environment, mudah di-deploy di berbagai server

3.b Keputusan Penting: Menghapus n8n

[!important] Pivotal Decision — Hapus n8n Awalnya proyek menggunakan n8n sebagai execution backend (workflow orchestrator eksternal). Di sprint tengah, n8n dihapus dan diganti dengan custom Python execution engine (~400 baris di workflow_service.py).

Alasan penghapusan:

n8n adalah Node.js service → overhead infrastruktur tambahan

Kehilangan kontrol atas execution semantics (black box)

Tight coupling ke third-party API yang bisa berubah

Takeaway: Strategi “prototype dulu pakai tools existing, replace in-house saat requirement jelas” adalah pendekatan iteratif yang valid.

4. Evaluasi Pasca-Proyek: Apakah Tech Stack Tepat?

4.a Yang Terbukti Tepat ✅

Keputusan	Bukti Keberhasilan
FastAPI	Auto-generate Swagger docs `/docs` → langsung bisa dipakai untuk testing API tanpa effort tambahan
SQLAlchemy + Alembic	Schema drift terdeteksi otomatis; zero data loss pada semua migrasi sprint
Redis sebagai “glue”	Satu dependency Redis menangani 3 concern: rate limiter (sorted set), pub/sub notifikasi, ARQ job queue
Strategy Pattern untuk Action	Menambah action baru = 1 file baru + 1 baris di registry. Zero perubahan di execution engine
JWT di HttpOnly Cookie	Mitigasi XSS token theft; tidak ada kebocoran token di localStorage
ARQ + Redis untuk worker	Background eksekusi workflow tidak blocking event loop FastAPI

4.b Yang Bisa Diperbaiki ⚠️

Gap	Dampak	Alternatif yang Lebih Tepat
Tidak ada E2E test (Playwright/Cypress)	Interaksi canvas (drag-drop, connect node) tidak teruji otomatis	Playwright (sudah ada di requirements.txt tapi belum digunakan untuk E2E)
ARQ worker masih in-process	Jika server restart, job queue hilang	Dedicated ARQ worker process terpisah + persistent Redis queue
SchedulingTrigger belum ada cron loop	Trigger berbasis jadwal tidak berjalan saat restart	APScheduler atau celery-beat integration
Tidak ada JWT refresh token	User harus login ulang setiap `ACCESS_TOKEN_EXPIRE_MINUTES` menit	Sliding refresh token atau session extension
Validasi workflow_schema masih implicit	JSON blob bisa corrupt tanpa terdeteksi saat save	Pydantic model untuk validasi graph structure on write

Jawaban Singkat untuk Ujian Secara keseluruhan, pemilihan tech stack sudah tepat. FastAPI + PostgreSQL + Redis terbukti cukup untuk skala proyek ini. Keputusan paling signifikan adalah menghapus n8n dan membangun execution engine sendiri — keputusan ini terbukti benar karena meningkatkan kontrol, transparansi debugging, dan mengurangi complexity infrastruktur. Gap yang ada (E2E test, dedicated worker) bukan kesalahan pemilihan teknologi, melainkan keterbatasan waktu sprint.

4.c Pertanyaan Jebakan CPMK 4 & Cara Menjawabnya

Framing Penting Bedakan antara yang kamu kerjakan sendiri (bisa dijawab teknis detail) vs keputusan tim (jawab dari sudut pandang tim, bukan seolah kamu yang implementasi).

❓ “Kenapa pilih PostgreSQL bukan MongoDB, padahal struktur workflow (node & edge) biasanya lebih cocok NoSQL?”

Jawaban: Memang struktur graph (node + edge) terlihat cocok untuk document store, tapi kami menyimpannya sebagai JSON column di PostgreSQL — yang memberi fleksibilitas NoSQL tetapi tetap dengan jaminan ACID transaksional.

Alasannya: tabel executions dan task_logs punya relasi terstruktur ke workflows dan accounts — membutuhkan foreign key integrity dan JOIN query yang hanya bisa dilakukan dengan baik di RDBMS. Kalau pakai MongoDB, integritas data antar collection harus dijaga manual di application layer → lebih rawan bug.

Kesimpulan: PostgreSQL dengan JSON column adalah trade-off yang tepat — struktur data relasional tetap terjaga, tapi definisi node/edge tetap fleksibel.

❓ “Bagaimana error handling kalau Action ‘Send Email’ gagal di tengah eksekusi workflow?”

Jawaban (dari sudut pandang kamu sebagai FE dev): Di sisi frontend yang saya kerjakan, setiap node pada canvas memiliki status yang ditampilkan secara real-time dari task_log — jadi user bisa langsung melihat node mana yang gagal dan pesan errornya.

Jawaban (tim — backend): ARQ worker mencatat setiap action ke task_logs dengan status SUCCESS/FAILED. Jika action gagal, execution engine berhenti dan mencatat error message ke log. Sprint 5 juga menambahkan timeout & retry logic (SB-08, oleh 13523007) — jika action tidak selesai dalam batas waktu, otomatis di-retry atau ditandai failed.

❓ “Kenapa pilih SSE bukan WebSocket untuk real-time notification?”

Jawaban: SSE (Server-Sent Events) dipilih karena komunikasinya one-directional (server → client) — cocok untuk kasus notifikasi status eksekusi workflow di mana client hanya perlu menerima update, bukan mengirim balik. WebSocket lebih tepat untuk komunikasi bi-directional (contoh: chat). Overhead WebSocket (full-duplex connection) tidak perlu untuk use case kami. Dari sudut pandang saya: di task log display (SB-09, Sprint 4), saya mengkonsumsi SSE stream untuk update status task secara real-time tanpa perlu polling.

❓ “Apa kontribusi spesifik Anda yang menunjukkan penerapan CPMK 4?”

Jawaban terbaik (langsung & spesifik): Kontribusi paling konkret saya ke CPMK 4 adalah implementasi canvas workflow menggunakan @xyflow/react (Sprint 3 SB-05 & Sprint 4 SB-02).

Pemilihan @xyflow bukan keputusan sembarangan — saya harus memahami API library ini, mengimplementasikan custom node types untuk trigger dan action, mengelola state graph (node + edge), dan memastikan serialisasi ke format JSON yang bisa dieksekusi backend. Ini adalah contoh langsung “menggunakan framework yang tepat” sesuai CPMK 4.

Di Sprint 4, saya juga mengintegrasikan frontend dengan backend untuk eksekusi workflow & logging (SB-14) — yang berarti saya harus memahami kontrak API FastAPI dan memastikan state di canvas sinkron dengan hasil eksekusi di backend.

5. Soal: Software Measurement (Bagian I No 2)

Pertanyaan Khas “Apa kegunaan measurement pada pengembangan software?” / “Jelaskan perbedaan Measure, Metric, dan Indicator”

5.a Mengapa Mengukur Software?

“You cannot control what you cannot measure.” — Tom DeMarco (1982) “What is not measurable, make measurable.” — Galileo

Tujuan	Yang Diukur
Understand — pahami kondisi proyek	progress, kompleksitas kode
Control — kendalikan proses	defect rate, velocity per sprint
Improve — tingkatkan kualitas & produktivitas	usability, maintainability, reliability

5.b Measure, Metric, dan Indicator

Term	Definisi	Contoh Umum	Contoh di AutoSix
Measure	Penilaian/penetapan dengan membandingkan ke suatu standar	Suhu tubuh Joe = 99°F	Jumlah test pass = 47 dari 50
Metric	Ukuran kuantitatif dari derajat suatu atribut pada elemen software — lebih bermakna karena ada konteks	”2 error ditemukan customer dalam 18 bulan” (bukan sekadar “ada 2 error”)	“3 bug ditemukan selama 5 sprint di fitur canvas”
Indicator	Device/variable/metric yang menunjukkan apakah suatu state atau goal tercapai; biasanya untuk menarik perhatian	Bendera setengah tiang = ada yang meninggal	Burndown chart naik di Day 3 = ada sprint risk

[!important] Jebakan Ujian Metric ≠ Measure — Measure sekadar pengukuran vs standar. Metric lebih bermakna karena mengandung konteks atribut yang diukur dan tujuan pengukurannya. Indicator adalah sinyal dari metric/variable untuk mencapai goal.

5.c Skala Pengukuran

Dari paling lemah ke paling kuat (bisa turun, tidak bisa naik):

Skala	Sifat	Contoh
Nominal	Kategori, tidak ada urutan	Jenis bug: UI / Logic / Performance
Ordinal	Ada urutan, jarak tidak bermakna	Prioritas: Low / Medium / High
Interval	Ada jarak bermakna, tidak ada nol mutlak	Tanggal kalender
Ratio	Ada nol mutlak, semua operasi valid	LOC, jumlah defect, waktu eksekusi

Most powerful analysis → Ratio → Interval → Ordinal → Nominal → Least powerful

5.d Direct vs Indirect Measures

Tipe	Cara Ukur	Contoh Umum	Contoh di AutoSix
Direct (internal)	Diukur langsung dari atribut, biasanya dengan menghitung	LOC, durasi proses, jumlah defect	Jumlah endpoint API: 24, jumlah sprint: 5
Indirect (external)	Dihitung dari measure lain	Module Defect Density = defect / LOC	Bug rate = bug per sprint = 3 bug / 5 sprint

5.e Properti Metrik yang Baik

Metrik yang baik harus: Valid (mengukur yang seharusnya diukur) + Reliable (konsisten).

Analogi dartboard:

Reliable tapi not valid → titik berkumpul rapat tapi jauh dari pusat
Valid tapi not reliable → titik tersebar tapi rata-rata di pusat
Valid & reliable → titik rapat di pusat ✅

Properti lengkap: valid, reliable, objective, precise, intuitive, robust, automatable, economical.

5.f Pengukuran di Proyek AutoSix

Metric yang Kami Gunakan	Tipe	Kegunaan
Burndown chart per sprint	Indicator	Menunjukkan apakah sprint goal akan tercapai
Jumlah test pass/fail (pytest, Vitest)	Direct measure	Mengukur correctness implementasi
Jumlah MR di-reject	Indirect metric	Proxy untuk code quality
Sprint velocity (story point selesai)	Metric	Kontrol kapasitas tim per sprint
Jumlah bug ditemukan saat UAT	Direct measure	Evaluasi kesiapan release

Koneksi ke CPMK 4 Measurement termasuk CPMK 4 jika framing-nya: “alat bantu pengukuran yang kamu gunakan” — pytest (unit test), Vitest, GitLab CI pipeline (automation), dan burndown chart adalah tools pengukuran yang kami pilih dan gunakan dalam proyek.

6. Soal: Alat Bantu Konfigurasi Perangkat Lunak (No 3 Tahun Lalu)

Pertanyaan “Bagaimana kelompok Anda memanfaatkan alat bantu dalam mengelola konfigurasi perangkat lunak yang dibangun? Menurut Anda, apa yang perlu diperbaiki dalam pemanfaatan alat bantu tersebut?“

5.a Alat Bantu Konfigurasi yang Digunakan

Version Control:

GitLab (gitlab-edu.itb.ac.id) — semua kode di-track, branching per fitur/sprint
Branch strategy: main (production), feature branches per issue
Merge Request dengan review sebelum merge ke main

CI/CD Pipeline (.gitlab-ci.yml):

Auto-lint dan test pada setiap push ke MR
Build dan deploy otomatis ke staging saat merge ke main
Pipeline mencegah kode broken masuk ke main branch

Manajemen Environment:

.env.example di-commit, .env di-gitignore → credentials tidak pernah masuk VCS
Konfigurasi berbeda untuk dev/staging/production via environment variables
pydantic-settings di backend untuk type-safe config loading

Containerization:

Dockerfile untuk backend dan frontend
docker-compose.prod.yml untuk production deployment
docker-compose.worker.yml untuk ARQ worker terpisah

Database Migration:

Alembic dengan alembic revision --autogenerate → schema drift terdeteksi otomatis
run_migrations.py dengan auto-stamp logic untuk fresh DB

Dependency Management:

requirements.txt (semua) dan requirements-prod.txt (production only) — memisahkan dev tools dari prod
package-lock.json di-commit untuk reproducible installs di frontend

5.b Yang Perlu Diperbaiki

Tidak ada semantic versioning — aplikasi tidak punya version tag (v1.0.0, dll). Sulit melacak release.
Belum ada E2E automated test di pipeline — CI hanya menjalankan unit/integration test, interaksi UI canvas tidak teruji otomatis.
Secrets management masih manual — .env file di-manage manual. Idealnya menggunakan GitLab CI/CD Variables atau HashiCorp Vault.
Monitoring & observability belum ada — tidak ada logging aggregation (ELK/Loki) atau alerting. Sulit mendeteksi masalah production.

6. Soal: DSSE — Domain-Specific Software Engineering

6.a Definisi & Motivasi DSSE

DefinitionDSSE (Domain-Specific Software Engineering) adalah pendekatan software engineering yang dicirikan oleh pemanfaatan ekstensif existing domain knowledge (leveraging existing domain knowledge).

Logika dasarnya: Similar problem → Similar solution → Similar software. Begitu kita membangun sejumlah sistem yang melakukan hal serupa, kita memperoleh pengetahuan untuk mengeksploitasi solusi umum. Secara teori, kita cukup membangun “the difference” antara sistem target baru dan sistem sebelumnya.

Mengapa DSSE? Pandangan tradisional mengajarkan solusi de novo (dari nol) — tidak feasible karena akan banyak “menemukan ulang roda”.

6.b Spektrum Pendekatan SE

Pendekatan	Cara Kerja
Traditional SE	1 masalah → tak terhitung cara (“too many choices”)
Architecture-Based SE	1 masalah → pilih dari segelintir architectural styles → implementasi spesifik
Domain-Specific SE	Region problem space (domain) → DSSA → application-specific arch → implementasi

Alur DSSE: Which domain? → Reference architecture → Application-specific arch → How to implement?

6.c Tiga Faktor Kunci DSSE (“Three Lampposts”)

[!important] Tiga Faktor DSSE berada di irisan tiga faktor: Domain · Business · Technology

Faktor	Penjelasan
Domain	Harus ada domain untuk membatasi problem space dan memfokuskan pengembangan
Business	Motivasi bisnis: minimizing costs (reuse aset) dan maximize market (banyak aplikasi terkait untuk berbagai end user)
Technology	Harus ada beragam solusi teknologi (tools, patterns, architectures & styles) untuk diterapkan pada domain

Kombinasi irisan:

Kombinasi	Hasil
Domain + Business	Corporate Core Competencies — keahlian domain diperkuat business acumen & pengetahuan pasar
Domain + Technology	Application Family Architectures — semua solusi teknologi untuk masalah dalam domain
Business + Technology	Domain Independent Infrastructure — tools & teknik lepas dari domain (UML, compiler, word processor)
Domain + Business + Technology	→ Domain-Specific Software Engineering

6.d Jenis Domain & Konsep Pendukung

Domain Vertikal (industry-specific): Perbankan, Pertambangan, Pendidikan, Airline
Domain Horizontal: Office Automation, ERP, CRM, CASE Tools, Compiler bahasa pemrograman
Product-Line Architecture — sekumpulan solusi spesifik yang terkait; fokus pada commonalities dan variability antar solusi individual
Domain-Specific Tools / DSL — memberi pengembangan lebih cepat, menyatukan native problem concepts dengan programming concepts. Contoh: Unity3D untuk game, SQL, HTML, Actulus Modeling Language

6.e DSSE dalam Proyek AutoSix

Elemen DSSE	Implementasi di AutoSix
Domain	Otomasi workflow akademik ITB — domain vertikal (pendidikan)
DSL-like abstraction	Canvas trigger/action = vocabulary domain-specific (bukan general programming)
Domain-specific framework	`@xyflow/react` — dipilih karena domain = node-graph workflow
Variability	Strategy Pattern untuk action/trigger → variasi tanpa ubah engine
Commonality	Semua workflow: node + edge + execution context
Catalog = feature model	Katalog trigger/action = representasi variabilities yang tersedia

6.f Kapan DSSE Cocok ✅ dan Kurang Tepat ❌

Cocok ✅	Kurang Tepat ❌
Domain sudah matang & stabil	Domain baru / masih berubah
Banyak produk terkait (product line)	Proyek one-off, tidak ada rencana replikasi
User = domain expert, bukan programmer	Reference arch dibuat terlalu awal (not too-early, not too-late)
Kebutuhan reuse tinggi antar produk	Overhead membangun framework > benefit

Jawaban Singkat DSSE = leveraging existing domain knowledge (similar problem → similar solution, bangun “the difference”). Tiga faktor: Domain × Business × Technology. Cocok untuk domain matang dengan banyak produk terkait. Kurang tepat untuk domain baru atau proyek one-off. Di AutoSix: kami menggunakan DSSE → tools domain-specific (@xyflow, ARQ) + vocabulary trigger/action sebagai DSL informal untuk otomasi workflow akademik.

7. Soal: Arsitektur UML (No 4 Tahun Lalu)

7.a Arsitektur Backend (3-Layer)

┌─────────────────────────────────────────┐
│              CLIENT (Browser)            │
│           Next.js 16 Frontend            │
└────────────────────┬────────────────────┘
                     │ HTTP / SSE
┌────────────────────▼────────────────────┐
│           FastAPI Backend               │
│  ┌──────────────────────────────────┐   │
│  │  Routers (app/api/)              │   │  ← thin HTTP handlers
│  │  auth, workflow, webhook, notif  │   │
│  └──────────────────┬───────────────┘   │
│  ┌──────────────────▼───────────────┐   │
│  │  Services (app/services/)        │   │  ← all business logic
│  │  WorkflowService, AuthService    │   │
│  │  NotificationService, etc.       │   │
│  └──────────────────┬───────────────┘   │
│  ┌──────────────────▼───────────────┐   │
│  │  Models (app/models/)            │   │  ← SQLAlchemy ORM
│  │  Account, Workflow, Execution    │   │
│  └──────────────────────────────────┘   │
└────────────┬──────────────┬─────────────┘
             │              │
    ┌─────────▼──┐    ┌─────▼──────┐
    │ PostgreSQL  │    │   Redis     │
    │  (data)     │    │ (queue/pub) │
    └────────────┘    └────────────┘
                             │
                    ┌────────▼───────┐
                    │  ARQ Worker     │
                    │ (background     │
                    │  execution)     │
                    └────────────────┘

7.b Workflow Execution Flow (Sequence)

User/System         WebhookController    WorkflowService      ARQ Worker
    │                      │                   │                  │
    │── POST /webhook/{id}─►│                   │                  │
    │                      │─ validate ────────►│                  │
    │                      │                   │─ create Execution │
    │                      │                   │─ enqueue job ────►│
    │◄── 202 Accepted ──────│                   │                  │
    │                      │                   │                  │─ DFS traverse nodes
    │                      │                   │                  │─ execute each Action
    │                      │                   │                  │─ write TaskLog per node
    │                      │                   │◄─ update status ──│

7.c Strategy Pattern untuk Extensibility

ActionStrategy (abstract)
├── SendEmailAction
├── CompressImageAction
├── ConditionalAction
├── DelayAction
├── WebhookCallbackAction
└── [tambah action baru = 1 file baru]

Registry:
action_key → Class (dinamis, tidak ada hardcode di engine)

8. Soal: Perencanaan Evaluasi (Bagian II No 2)

8.a Strategi Pengujian AutoSix

Backend — pytest:

tests/unit/services/ → 10 test file, testing service layer secara isolated (mock DB)
- test_actions.py, test_auth_service.py, test_workflow_engine.py, dll.
tests/unit/core/test_security.py → pengujian JWT & security utils
tests/integration/test_api_routes.py → integration test endpoint dengan DB nyata

Frontend — Vitest:

test/unit/api.test.ts → API client utilities
test/unit/auth.test.ts → autentikasi dan session management
test/unit/components.test.tsx → React component rendering
test/unit/itbSso.test.ts → SSO ITB integration logic
test/unit/useProfile.test.ts → custom hooks

Manual Testing:

User Acceptance Testing (UAT) dengan user Direktorat Pendidikan
Pengujian tiap product backlog sebelum sprint review

Gap dalam Evaluasi:

Belum ada E2E test untuk alur canvas (drag-drop, connect node, eksekusi)
Belum ada load/stress testing untuk concurrent workflow execution
Code coverage belum diukur secara formal

9. Soal: Large Scale Software Development (Bagian I No 1)

Pertanyaan “Karakteristik utama large scale software development dan efeknya ke manajemen proyek”

9.a “Bukan Sekadar Ukuran Besar”

[!important] Poin Inti dari Materi Kuliah “Development in a large scale software is not just the issue of the large size software application.” Tantangan utama bukan hanya jumlah baris kode, melainkan kompleksitas interaksi, koordinasi, lokasi, platform, dan politik organisasi.

9.b Dimensi Kompleksitas

Dimensi	Contoh
Complexity in Software	High LOC, banyak data access, banyak elemen komputasi
Complexity in Requirements	Ukuran requirement besar, sering berubah, kadang konflik
Complexity in Location	Tim lintas lokasi / zona waktu
Complexity in Platform	Multiple hardware, OS, programming language
Complexity in Politics	Perbedaan aturan dan kebijakan antar pihak
Complexity in Resources	Alokasi SDM, budget, waktu

9.c Ciri Khas Large-Scale Software

Source code jutaan baris (contoh: OTHR radar ±3 juta LOC)
Ratusan developer, sering tersebar geografis
Kompleksitas interaksi antar komponen tinggi
Penggunaan komponen off-the-shelf ekstensif
Multiple programming languages dan multiple persistence mechanisms
Concurrency tinggi

9.d Masalah Teknis Khas

Masalah	Penjelasan
Memory	Harus dikelola hati-hati karena terbatas hardware
Time (rebuild)	Compile time mahal — sekali build menghabiskan banyak waktu
Performance	Bahasa interpreted tidak menyamai compiled; ada beban GC
Threads	Race condition, deadlock — jauh lebih kompleks dari sequential
Safety	”The bigger the problem is, the riskier it becomes”
Portability	Thread scheduling beda antar platform, non-standard API

9.e Estimasi Effort & Implikasinya

Estimasi Effort (dari slide kuliah) Sistem 5 juta LOC × 22 lines/day → ±947 person-years → butuh ±380 developer untuk selesai dalam 2,5 tahun.

Dua implikasi:

Sistem harus dipartisi menjadi komponen kecil yang relatif independen

Jauh lebih baik reuse komponen yang ada — sisakan kode baru hanya untuk requirement baru (prinsip yang sama dengan DSSE!)

9.f Prinsip & Relevansi ke AutoSix

Prinsip Large-Scale	Implementasi di AutoSix
Reproducibility	Docker + docker-compose → reproducible di semua environment
Automation	GitLab CI/CD pipeline → automate test, lint, deploy
Continuous Integration	Setiap MR auto-trigger pipeline, branch strategy ketat
Koordinasi (3C)	Communication (MR + daily), Capacity (Scrum sprint), Cooperation (shared repo)

Akar Kesulitan = KOORDINASI3C: Communication · Capacity · Cooperation

10. Quick Reference — Jawaban Singkat Untuk Ujian

Bullet Points Kunci

Tech Stack — Apakah Tepat?

Ya, secara keseluruhan tepat. FastAPI + PostgreSQL + Redis cukup untuk skala ini.
Keputusan terbaik: menghapus n8n → custom engine lebih transparan & controllable.
Gap: E2E test belum ada, dedicated ARQ worker belum fully deployed.

Alat bantu konfigurasi:

GitLab (VCS + CI/CD), Docker (containerization), Alembic (DB migration), .env management, pydantic-settings.
Yang perlu diperbaiki: secrets management (masih manual), belum ada monitoring/observability.

DSSE — Three Lampposts:

Domain × Business × Technology
Irisan: Corporate Core Competencies | Application Family Arch | Domain Independent Infra
Cocok: domain matang, banyak produk terkait, user = domain expert
Kurang tepat: domain baru, proyek one-off, reference arch terlalu dini
⚠️ Jebakan kecuali: Kelebihan GPL = banyak dukungan IDE (bukan DSL); Komponen DSSA ≠ reference model

Large Scale:

Bukan sekadar ukuran kode → 6 dimensi kompleksitas
Akar masalah = KOORDINASI (3C: Communication, Capacity, Cooperation)
Prinsip: Reproducibility, Automation, CI, Policy enforcement

Arsitektur AutoSix:

3-layer backend: Router → Service → Model
Strategy pattern untuk Action/Trigger: extensible tanpa ubah engine
Redis sebagai single dependency untuk 3 concerns: rate limit, pub/sub, ARQ

References

Pressman, R.S. (2014) - Software Engineering: A Practitioner’s Approach, 8th Ed.
Sommerville, I. (2016) - Software Engineering, 10th Ed.
if-notes.naufarrel.dev — Catatan IF3250 PPL (DSSE, Large Scale, Measurement, UAS)
PROJECT_AUDIT.md — AutoSix internal retrospective (June 2026)
FastAPI Documentation — fastapi.tiangolo.com