Rata-rata industri perangkat lunak pada tahun 1980-an adalah 30 hingga 60 defect per seribu baris kode. Tim Cleanroom IBM mengirimkan increment compiler 20.000 baris dengan 53 defect yang ditemukan dalam pengujian. Itu adalah 2,6 per KLOC. Beberapa increment individual sebesar 10.000 baris masuk ke system test tanpa defect yang ditemukan sama sekali.

Bagian paling aneh? Programmer dilarang menjalankan kode mereka sendiri.

Apa yang sebenarnya dimaksud dengan Cleanroom software engineering

Cleanroom software engineering, dikembangkan oleh matematikawan Harlan Mills di IBM pada tahun 1980-an, adalah proses berbasis teori yang mengandalkan formal specification, structured design, dan mathematical correctness verification alih-alih Unit Testing dan debugging. Nama tersebut berasal dari manufaktur semikonduktor. Di pabrik chip, Anda tidak memperkenalkan debu lalu menyekanya nanti. Anda mencegah kontaminasi sejak awal.

Di Cleanroom, developer tidak melakukan Unit Testing. Mereka tidak debug. Mereka verifikasi.

Proses ini mempartisi perangkat lunak menjadi increment, biasanya 5.000 hingga 15.000 baris kode. Setiap increment dispesifikasikan, didesain, diverifikasi, lalu diuji secara statistik sebagai satu unit utuh. Developer menulis kode, tetapi mereka tidak diizinkan untuk mengompilasi atau mengeksekusinya selama pengembangan. Pertama kalinya kode berjalan adalah selama system testing formal.

Bagaimana box structure verification menggantikan debugging

Mekanisme intinya adalah box structure specification. Setiap komponen didefinisikan pada tiga tingkatan.

black box menspesifikasikan perilaku eksternal. Ini mendefinisikan stimulus dan respons tanpa menyebutkan state internal.

state box menambahkan variabel state internal dan fungsi transisi state.

clear box adalah implementasi aktual, yang harus merupakan penyempurnaan terstruktur dari state box.

Hierarki ini penting karena memungkinkan Anda memverifikasi kebenaran pada setiap tingkatan secara independen. Anda membuktikan bahwa state box mengimplementasikan black box, dan bahwa clear box mengimplementasikan state box.

Berikut ini penampakannya dalam praktik untuk sebuah fungsi dengan correctness argument yang tidak sepele:

from typing import Optional

def binary_search(arr: list[int], target: int) -> Optional[int]:
    """
    Black box spec:
      Pre:  arr is sorted in non-decreasing order.
      Post: Returns index i such that arr[i] == target,
            or None if target is not present.
    """
    low, high = 0, len(arr) - 1

    while low <= high:
        mid = (low + high) // 2

        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            low = mid + 1
        else:
            high = mid - 1

    return None

verification argument untuk loop adalah yang terpenting. Tim meninjau ini bersama-sama dan mengonfirmasi tiga fakta. Pertama, jika arr[mid] == target, postcondition terpenuhi segera. Kedua, jika arr[mid] < target, target hanya dapat ada pada index yang lebih besar dari mid, sehingga menetapkan low = mid + 1 mempertahankan invariant bahwa target berada di arr[low:high+1] jika memang ada. Ketiga, jika arr[mid] > target, argumen simetris berlaku untuk high = mid - 1.

Ini bukan Code Review di mana seseorang bertanya apakah Anda memikirkan array kosong. Ini adalah bukti grup terstruktur bahwa setiap input yang mungkin menghasilkan output yang dispesifikasikan.

Angka IBM di balik klaim zero-defect

IBM menerapkan Cleanroom pada tiga proyek besar pada akhir 1980-an dan awal 1990-an: COBOL Structuring Facility (40.000 baris), program penerbangan helikopter Angkatan Udara (35.000 baris), dan sistem perencanaan transportasi antariksa NASA (45.000 baris).

Data COBOL/SF adalah yang paling detail. Increment pertama sebesar 20.000 baris dikembangkan dengan formal specifications, box structure design, dan grup correctness verification. Developer tidak diizinkan untuk mengompilasi atau menjalankan module mereka selama pengembangan. Kode langsung masuk ke system test.

Hasil: 53 defect ditemukan selama pengujian. Lebih dari 90% dari semua defect tertangkap selama fase verifikasi sebelum kode dieksekusi.

Sebagai perbandingan, proyek IBM konvensional pada saat itu menemukan sekitar 60% defect sebelum eksekusi. Cleanroom membalik rasio tersebut.

Beberapa increment, khususnya yang lebih kecil di bawah 10.000 baris, melaporkan nol defect ditemukan dalam system testing. Dari sinilah asal klaim “10.000 baris dengan nol defect”. Itu memang terjadi. Tidak universal, tetapi cukup dapat direproduksi sehingga IBM menjadikannya benchmark standar.

Mengapa tidak menjalankan kode sendiri menghasilkan lebih sedikit bug

Ini adalah bagian yang membuat developer pusing. Bagaimana tidak melakukan testing bisa menghasilkan kode yang lebih baik?

Jawabannya adalah kognitif, bukan teknis. Ketika Anda tahu bahwa Anda tidak dapat menjalankan kode untuk memeriksa pekerjaan Anda, Anda merancang dengan lebih hati-hati. Anda menulis fungsi yang lebih kecil. Anda memikirkan Edge Cases sebelum mengetik. Anda mengandalkan Type System dan pemrograman terstruktur karena Anda tidak memiliki jaring pengaman.

Ini adalah alasan yang sama mengapa ahli bedah menggunakan checklist. Kendala memaksa mode mental yang berbeda.

Ada juga lapisan kontrol kualitas statistik. Cleanroom menggunakan statistical usage testing berdasarkan operational profile. Kasus uji diambil dari distribusi probabilitas perilaku pengguna aktual, bukan dari tebakan developer tentang di mana bug berada. Ini berarti Anda mengukur reliabilitas, bukan hanya berburu bug.

Trade-off yang membuat Cleanroom tetap menjadi niche

Cleanroom tidak menguasai dunia. Ada alasannya.

Pertama, hambatan pelatihan berat. Anda membutuhkan tim yang dapat menulis formal specifications dan membangun mathematical correctness arguments. Sebagian besar lulusan CS pada tahun 2025 belum pernah melakukan bukti formal untuk fungsi yang tidak sepele.

Kedua, biaya desain awal tinggi. IBM melaporkan bahwa teks specification melebihi teks design dengan rasio empat berbanding satu pada proyek COBOL/SF. Anda menukar waktu desain dengan waktu pengujian. Itu berhasil untuk compiler dan flight software. Tidak berhasil untuk aplikasi CRUD dengan kebutuhan pivot mingguan.

Ketiga, klaim zero-defect adalah tentang defect density, bukan ketiadaan semua bug. Sebuah increment Cleanroom masih bisa memiliki specification errors. Jika black box salah, clear box yang terverifikasi juga salah, hanya saja karena konstruksi.

Cara mencuri disiplin Cleanroom tanpa birokrasi

Anda mungkin tidak dapat mengadopsi Cleanroom sepenuhnya. Product Manager Anda tidak akan menunggu rasio specification-ke-kode empat banding satu. Tetapi Anda dapat mencuri bagian-bagian yang bernilai tinggi.

1. Tulis contract sebelum implementasi.

Gunakan preconditions, postconditions, dan invariants untuk mendefinisikan black box Anda. Bahkan komentar informal memaksa Anda untuk berpikir tentang batasan sebelum mengoptimalkan.

from typing import List, Tuple

def partition(nums: List[int], pivot: int) -> Tuple[List[int], List[int]]:
    """
    Black box spec:
      Pre:  True (any list of integers is valid).
      Post: left contains exactly the elements of nums where x <= pivot.
            right contains exactly the elements of nums where x > pivot.
            len(left) + len(right) == len(nums).
    """
    left = [x for x in nums if x <= pivot]
    right = [x for x in nums if x > pivot]

    # Runtime checks act as lightweight verification witnesses.
    assert all(x <= pivot for x in left)
    assert all(x > pivot for x in right)
    assert len(left) + len(right) == len(nums)

    return left, right

2. Ganti beberapa Unit Tests dengan verification arguments.

Sebelum Anda menulis test, tulis argumen satu kalimat tentang mengapa kode tersebut benar. Jika Anda tidak dapat membangun kalimat itu, desainnya terlalu kompleks. Ini adalah praktik Cleanroom paling efektif untuk tim modern.

3. Gunakan property-based testing sebagai statistical usage testing.

Tool seperti Hypothesis di Python atau fast-check di JavaScript menghasilkan input dari distribusi. Ini secara spiritual lebih dekat dengan statistical testing milik Cleanroom daripada Unit Tests berbasis contoh.

4. Pisahkan kompilasi dari verifikasi.

Jika Anda secara kebiasaan menulis satu baris, mengompilasi, memperbaiki typo, menulis baris lain, Anda sedang debug dengan refleks kejang. Coba tulis satu unit logis lengkap sebelum menjalankannya. Ketidaknyamanan adalah intinya.

FAQ

Apakah Cleanroom masih digunakan saat ini?

Ia bertahan di domain safety-critical dan mission-critical. NASA, FAA, dan beberapa producer perangkat medis menggunakan varian proses ini. Ia jarang ditemukan di perangkat lunak komersial.

Bisakah saya benar-benar mengirimkan kode tanpa Unit Testing?

Hanya jika Anda menggantinya dengan sesuatu yang sama rigornya. Tim Cleanroom menghabiskan lebih banyak jam untuk verifikasi daripada kebanyakan tim untuk testing. Waktunya tidak hilang. Ia dipindahkan ke kiri.

Apakah Cleanroom menjamin nol bug?

Tidak. Ia menjamin bahwa implementasi sesuai dengan specification dengan probabilitas tinggi. Jika specification salah, bug tersebut dipertahankan dengan sempurna.

Bagaimana dampaknya terhadap produktivitas?

IBM melaporkan produktivitas lebih dari 400 baris kode per orang-bulan pada proyek COBOL/SF, sebagian besar karena waktu pengujian yang berkurang drastis mengimbangi peningkatan upaya desain.

Kesimpulan

Lain kali seseorang mengklaim bahwa sebuah metodologi menghasilkan perangkat lunak zero-defect, mintalah data proyeknya. Angka-angka Cleanroom IBM nyata, tetapi berasal dari konteks spesifik: tim berpengalaman, pelatihan formal, pengiriman inkremental, dan kesediaan untuk memverifikasi alih-alih debug.

Increment 10.000 baris dengan nol defect dapat dicapai. Hanya saja biayanya lebih besar dalam bentuk kebijaksanaan daripada yang kebanyakan organisasi bersedia bayar.