Diagram konteks proyek menunjukkan hal yang sedang diubah serta orang, organisasi, atau sistem di sekelilingnya. Tujuannya memperjelas batas: tanggung jawab proyek, hal yang berinteraksi dengannya, dan hal yang tetap berada di luar cakupan. Diagram ini bukan jadwal tugas atau peta proses terperinci.
Istilahnya perlu digunakan dengan cermat. Diagram konteks sistem perangkat lunak berfokus pada satu sistem dan hubungan eksternalnya. Sketsa konteks proyek yang lebih luas juga dapat menunjukkan sponsor, pemasok, tim operasi, dan batasan. Sebutkan jenis diagram yang dibuat agar audiens dapat menafsirkan batasnya dengan benar.
Pilih subjek yang tepat sebelum menggambar
Tulis kalimat di atas diagram: “Diagram ini menjelaskan ___ untuk tujuan ___.” Contoh: “Diagram ini menjelaskan layanan janji temu baru agar tim pengiriman dan operasi dapat menyepakati tanggung jawab integrasi.”
Jangan menaruh nama program yang ambigu di kotak tengah. “Transformasi pelanggan” bisa berarti sistem perangkat lunak, kumpulan proyek, atau keseluruhan model operasi. Jika batas-batas itu tercampur, diagram tidak akan menyelesaikan perbedaan cakupan.
Panduan konteks sistem dari model C4 berfokus pada satu sistem perangkat lunak, para penggunanya, dan sistem eksternal yang terhubung langsung. Gunakan pendekatan itu untuk pertanyaan arsitektur perangkat lunak. Lokakarya proyek yang lebih luas di bawah merupakan adaptasi untuk cakupan dan koordinasi, bukan jenis diagram C4 baru.
Tanyakan keputusan apa yang harus didukung oleh tampilan ini. Jika tak seorang pun dapat menyebutkannya, berhenti sebelum menambah kotak. Diagram yang berguna dapat menetapkan siapa yang menangani notifikasi gagal, integrasi mana yang perlu disetujui, atau organisasi mana yang menerima serah terima operasional.
Contoh konteks lengkap: pengingat janji temu
Skenario ini hipotetis. Sebuah tim memperkenalkan layanan pengingat janji temu untuk jaringan klinik. Subjek di tengah diagram adalah layanan pengingat, bukan seluruh operasi klinik.
Hubungan di sekitarnya dapat dicatat dalam tabel ini sebelum digambar:
| Aktor atau sistem eksternal | Hubungan dengan layanan pengingat | Pertanyaan tentang batas |
|---|---|---|
| Sistem janji temu | Memberikan perubahan dan pembatalan jadwal | Siapa yang memastikan pembaruan pembatalan tiba tepat waktu? |
| Administrator klinik | Mengonfigurasi waktu pengingat yang disetujui | Siapa yang mengizinkan perubahan aturan waktu? |
| Pasien | Menerima pengingat dan memilih tanggapan | Di mana persetujuan dan pengelolaan preferensi kontak dilakukan? |
| Penyedia pesan | Menerima permintaan pesan dan mengembalikan status pengiriman | Siapa yang menyelidiki pesan yang ditolak? |
| Tim operasi | Memantau kesehatan layanan dan menangani eskalasi | Bukti apa yang diperlukan sebelum penerimaan operasional? |
Letakkan layanan di tengah, lalu tempatkan setiap pihak eksternal di sekelilingnya. Beri label hubungan dengan kata kerja dan objek, seperti “mengirim pembaruan janji temu”. Panah tanpa label bisa berarti data, wewenang, kepemilikan, atau urutan; pembaca tidak seharusnya harus menebak.
Jangan masukkan detail pasien yang rahasia ke dalam diagram. Gunakan peran, kategori, dan hubungan yang mewakili. Persyaratan khusus privasi dan operasi tetap memerlukan dokumentasi yang disetujui serta tinjauan spesialis.
Versi pertama mengungkap keputusan yang belum dibuat: tim mengira sistem janji temu menangani preferensi kontak, sementara pemilik sistem itu mengira layanan baru yang akan melakukannya. Ini adalah celah cakupan. Gambar yang lebih rinci tidak akan memperbaikinya; yang dibutuhkan adalah keputusan eksplisit tentang kepemilikan.
Adakan lokakarya batas selama 35 menit
Persiapan: Undang orang yang memahami setiap hubungan eksternal penting. Bawa cakupan proyek saat ini dan dua kasus penggunaan yang realistis. Minta peserta menuliskan asumsi secara mandiri sebelum membahasnya bersama.
Menit 0–5: pastikan subjek. Sepakati tujuan, batas utama, dan audiens. Catat pengecualian yang mungkin disalahpahami. Pengecualian harus menyebutkan kepada siapa tanggung jawab beralih, bukan hanya mengatakan “di luar cakupan”.
Menit 5–15: petakan hubungan. Tambahkan pengguna, organisasi, atau sistem yang terkait langsung. Beri label makna setiap hubungan. Tandai hubungan yang belum pasti sebagai pertanyaan, bukan sebagai fakta yang sudah terbukti.
Menit 15–25: telusuri skenario. Ikuti satu kasus normal, satu pengecualian, dan satu kegagalan operasi. Untuk layanan pengingat, coba jadwal yang dibatalkan, penyedia pesan yang tidak dapat dihubungi, dan pasien yang mengubah preferensi. Tanyakan kapan tanggung jawab berpindah tangan.
Menit 25–35: selesaikan atau tetapkan celah. Catat setiap keputusan batas, pemiliknya, dan bukti yang diperlukan. Biarkan daftar asumsi yang belum terselesaikan tetap terlihat. Jangan menganggap diagram yang disetujui satu tim sebagai persetujuan dari pemangku kepentingan yang tidak hadir.
Durasi ini adalah saran format lokakarya, bukan persyaratan pemodelan formal.
Pisahkan tiga tampilan yang berbeda
Diagram konteks menjawab siapa dan apa yang berinteraksi dengan subjek. Diagram proses menjawab bagaimana pekerjaan bergerak melalui aktivitas dan keputusan. Jadwal proyek menjawab kapan aktivitas dan tonggak diperkirakan terjadi.
Anda mungkin memerlukan ketiganya, tetapi satu gambar yang penuh sesak jarang melayani semua kebutuhan dengan baik. Jika diskusi berubah menjadi urutan langkah persetujuan, catat untuk peta proses. Jika pembicaraan beralih ke tanggal dan ketersediaan sumber daya, masukkan ke jadwal.
Jangan juga mengubah diagram konteks menjadi bagan organisasi. Orang yang menjadi sponsor proyek mungkin penting dalam sketsa hubungan proyek meski tidak berinteraksi langsung dengan perangkat lunak. Tampilkan hubungan itu dengan sengaja dan jelaskan legendanya.
Untuk diagram perangkat lunak, pilihan teknologi seperti pustaka dan indeks basis data biasanya berada di tampilan yang lebih terperinci. Mengeluarkannya adalah keputusan tentang audiens dan cakupan, bukan klaim bahwa detail tersebut tidak penting.
Tinjau diagram saat batas berubah
Tetapkan pemelihara dan pemicu tinjauan. Pemicu yang berguna antara lain penambahan integrasi, perpindahan kepemilikan operasi, pergantian pemasok, atau ditemukannya kelompok pengguna baru. Tanpa pemilik terkini, diagram dapat menjadi gambar meyakinkan dari kesepakatan yang sudah usang.
Dalam tinjauan proyek, tanyakan: “Hubungan mana yang mengejutkan kita, batas mana yang menyebabkan pengerjaan ulang, dan asumsi apa yang seharusnya diuji lebih awal pada kesempatan berikutnya?” Pertanyaan ini dapat menjadi masukan bagi retrospektif tim.
Simpan diagram resmi di ruang kerja diagram atau arsitektur tim. NextRetro dapat mendukung diskusi dan tindak lanjut, tetapi bukan alat khusus untuk membuat diagram konteks. Gunakan ide retrospektif untuk memilih format yang membahas masalah koordinasi yang terungkap oleh diagram.
Daftar periksa tinjauan diagram konteks
Sebelum membagikan diagram, pastikan subjek diberi nama yang tepat; audiens dan tujuan dinyatakan; setiap garis memiliki label yang dapat dipahami; hubungan yang belum pasti ditandai; pengecualian menyebutkan pemilik lain bila perlu; dan versi memiliki tanggal serta pemelihara.
Lalu, minta seseorang yang tidak menggambarnya untuk menjelaskan satu skenario yang mewakili proses. Pertanyaan orang itu menjadi uji praktis atas kejelasan. Jika ia mengira hubungan data sebagai wewenang persetujuan, ubah label sebelum menyebarkan diagram sebagai batas yang disepakati.
Pertanyaan umum
Apakah diagram konteks proyek sama dengan diagram konteks C4?
Tidak selalu. Diagram konteks sistem C4 menjelaskan satu sistem perangkat lunak beserta pengguna dan sistem eksternalnya. Sketsa konteks proyek dapat mencakup hubungan organisasi yang lebih luas. Sebutkan tampilan dan tujuannya dengan jelas, jangan diam-diam mencampur cakupan.
Seberapa banyak detail yang perlu dimasukkan ke diagram konteks?
Masukkan cukup detail untuk mendukung keputusan batas dan mengenali hubungan eksternal yang penting. Pindahkan urutan aktivitas, tanggal, serta detail teknis internal ke tampilan terpisah jika membuat konteks sulit dipahami.
Bisakah diagram konteks menggantikan pernyataan cakupan?
Tidak. Diagram membantu orang membahas cakupan, tetapi tidak mencatat setiap persyaratan, kriteria penerimaan, kewajiban, atau pengecualian. Jaga keselarasan dengan dokumen proyek yang disetujui dan catat keputusan yang diambil melalui diskusi.