Proje bağlam diyagramı, değiştirilen konuyu ve çevresindeki kişileri, kuruluşları veya sistemleri gösterir. Amacı sınırı netleştirmektir: projenin nelerden sorumlu olduğu, nelerle etkileştiği ve kapsam dışında ne kaldığı. Bir görev takvimi ya da ayrıntılı süreç haritası değildir.
Terimi dikkatle kullanmak gerekir. Bir yazılım sistemi bağlam diyagramı tek bir sisteme ve dış ilişkilerine odaklanır. Daha geniş bir proje bağlam taslağında sponsorlar, tedarikçiler, operasyon ekipleri ve kısıtlar da gösterilebilir. İzleyicilerin sınırı doğru yorumlaması için hangi türü hazırladığınızı belirtin.
Çizmeden önce konuyu kesin olarak belirleyin
Diyagramın üzerine şu cümleyi yazın: “Bu diyagram, ___ amacına yönelik olarak ___ konusunu açıklar.” Örneğin: “Bu diyagram, teslimat ve operasyon ekiplerinin entegrasyon sorumluluklarında anlaşması için yeni randevu hizmetini açıklar.”
Ortadaki kutuya belirsiz bir program adı koymayın. “Müşteri dönüşümü” bir yazılım sistemini, proje grubunu veya tüm işletim modelini ifade edebilir. Bu sınırlar iç içe geçerse diyagram kapsam anlaşmazlığını çözmez.
C4 modelinin sistem bağlamı kılavuzu tek bir yazılım sistemine, kullanıcılarına ve doğrudan bağlı dış sistemlere odaklanır. Soru yazılım mimarisiyle ilgiliyse bu yaklaşımı kullanın. Aşağıdaki daha geniş proje atölyesi kapsam ve koordinasyon için bir uyarlamadır; yeni bir C4 diyagram türü değildir.
Bu görünümün hangi kararı desteklemesi gerektiğini sorun. Kimse bir karar söyleyemiyorsa daha fazla kutu eklemeden durun. Yararlı bir diyagram, başarısız bir bildirimin kime ait olduğunu, hangi entegrasyonun onay gerektirdiğini veya operasyon devrini hangi kuruluşun alacağını netleştirebilir.
İşlenmiş bağlam örneği: randevu hatırlatmaları
Bu senaryo varsayımsaldır. Bir ekip, klinik ağı için randevu hatırlatma hizmeti sunuyor. Diyagramın merkezindeki konu tüm klinik operasyonu değil, hatırlatma hizmetidir.
Çizime başlamadan önce çevredeki ilişkiler şu tabloda kaydedilebilir:
| Dış aktör veya sistem | Hatırlatma hizmetiyle ilişkisi | Sınır sorusu |
|---|---|---|
| Randevu sistemi | Randevu değişikliklerini ve iptallerini sağlar | İptal güncellemelerinin zamanında ulaştığını kim doğrular? |
| Klinik yöneticisi | Onaylanmış hatırlatma zamanlarını yapılandırır | Zamanlama kurallarındaki değişiklikleri kim onaylar? |
| Hasta | Hatırlatma alır ve yanıt seçer | İzin ve iletişim tercihlerinin yönetimi kimin sorumluluğunda? |
| Mesaj sağlayıcısı | Mesaj isteklerini kabul eder ve teslimat durumunu döndürür | Reddedilen bir mesajı kim inceler? |
| Operasyon ekibi | Hizmet sağlığını izler ve eskalasyonları yönetir | Operasyonel kabulden önce hangi kanıt gerekir? |
Hizmeti ortaya, dış tarafları çevresine çizin. İlişkileri “randevu güncellemeleri sağlar” gibi bir fiil ve nesneyle etiketleyin. Etiketsiz bir ok veri, yetki, sahiplik veya sıra anlamına gelebilir; okuyucular tahmin yürütmek zorunda kalmamalıdır.
Diyagrama gizli hasta bilgileri koymayın. Roller, kategoriler ve temsili ilişkiler kullanın. Özel gizlilik ve operasyon gereksinimleri yine de kendi onaylı belgelerini ve uzman incelemesini gerektirir.
İlk sürüm eksik bir kararı ortaya çıkarır: ekip, iletişim tercihlerini randevu sisteminin yönettiğini sanırken sistemin sahibi yeni hizmetin yöneteceğini düşünür. Bu bir kapsam boşluğudur. Daha ayrıntılı çizim sorunu çözmez; açık bir sorumluluk kararı gerekir.
35 dakikalık bir sınır atölyesi düzenleyin
Hazırlık: Önemli her dış ilişkiyi anlayan birini davet edin. Mevcut proje kapsamını ve iki gerçekçi kullanım senaryosunu getirin. Katılımcılardan birlikte tartışmadan önce varsayımlarını ayrı ayrı belirlemelerini isteyin.
0–5. dakikalar: konuyu doğrulayın. Amacı, merkez sınırını ve hedef kitleyi kararlaştırın. Yanlış anlaşılması olası kapsam dışı konuları yazın. Bir istisna yalnızca “kapsam dışında” demek yerine sorumluluğun nereye geçtiğini belirtmelidir.
5–15. dakikalar: ilişkileri haritalayın. Doğrudan ilgili kullanıcıları, kuruluşları veya sistemleri ekleyin. Her ilişkinin ne anlama geldiğini etiketleyin. Belirsiz ilişkileri doğrulanmış gerçekler gibi göstermek yerine soru olarak işaretleyin.
15–25. dakikalar: senaryoları izleyin. Normal bir durumu, istisnayı ve operasyonel arızayı takip edin. Hatırlatma hizmetinde iptal edilmiş bir randevuyu, ulaşılamayan bir mesaj sağlayıcısını ve tercihini değiştiren bir hastayı deneyin. Sorumluluğun nerede el değiştirdiğini sorun.
25–35. dakikalar: boşlukları çözün ya da atayın. Her sınır kararını, sorumlusunu ve gereken kanıtı kaydedin. Çözülmemiş varsayımların listesini görünür bırakın. Bir ekibin onayladığı diyagramı, toplantıda olmayan paydaşların da onayı saymayın.
Bu süreler önerilen bir atölye biçimidir, resmî bir modelleme gereksinimi değildir.
Üç farklı görünümü ayrı tutun
Bağlam diyagramı konuyla kimin ve neyin etkileştiğini yanıtlar. Süreç diyagramı işin faaliyetler ve kararlar arasında nasıl ilerlediğini yanıtlar. Proje takvimi faaliyetlerin ve kilometre taşlarının ne zaman beklendiğini yanıtlar.
Üçüne de ihtiyaç duyabilirsiniz, ancak her şeyi tek bir yoğun görsele yüklemek genellikle iyi sonuç vermez. Görüşme onay adımlarının sırasına kayarsa bu soruyu süreç haritası için not edin. Tarihler ve kaynak uygunluğu konuşuluyorsa takvime ekleyin.
Bağlam diyagramını organizasyon şemasına da dönüştürmeyin. Projeye sponsor olan biri yazılımla doğrudan etkileşmese bile proje ilişki taslağında önemli olabilir. Bu ilişkiyi bilinçli biçimde gösterin ve gösterim anahtarını açıklayın.
Yazılım diyagramlarında kitaplıklar ve veri tabanı dizinleri gibi teknoloji tercihleri genellikle daha ayrıntılı bir görünüme aittir. Bunları dışarıda bırakmak hedef kitle ve kapsamla ilgili bir tercihtir; bu ayrıntıların önemsiz olduğu anlamına gelmez.
Sınır değiştiğinde diyagramı gözden geçirin
Bir bakım sorumlusu ve inceleme tetikleyicisi belirleyin. Yeni entegrasyon eklemek, operasyon sahipliğini aktarmak, tedarikçiyi değiştirmek veya yeni bir kullanıcı grubu keşfetmek iyi tetikleyicilerdir. Güncel bir sorumlusu olmayan diyagram, geçerliliğini yitirmiş bir anlaşmanın ikna edici görseline dönüşebilir.
Proje incelemesinde şunları sorun: “Hangi ilişki bizi şaşırttı, hangi sınır yeniden çalışmaya yol açtı ve bir dahaki sefere hangi varsayımı daha erken sınamalıyız?” Bunlar bir ekip retrospektifi için yararlı girdilerdir.
Yetkili diyagramı ekibin diyagram veya mimari çalışma alanında tutun. NextRetro görüşmeyi ve takibi destekleyebilir, ancak özel bir bağlam diyagramı hazırlama aracı değildir. Diyagramın ortaya çıkardığı koordinasyon sorunlarını incelemek için retrospektif fikirlerinden bir biçim seçin.
Bağlam diyagramı inceleme kontrol listesi
Paylaşmadan önce konunun kesin bir adı olduğunu, hedef kitle ve amacın belirtildiğini, her çizginin anlaşılır bir etiketi bulunduğunu, belirsiz ilişkilerin işaretlendiğini, gerekiyorsa kapsam dışı konularda başka bir sorumlunun belirtildiğini ve sürümde tarih ile bakım sorumlusunun yer aldığını doğrulayın.
Ardından, diyagramı çizmeyen birinden temsili bir senaryoyu açıklamasını isteyin. Soruları anlaşılırlık için pratik bir sınamadır. Veri ilişkisini onay yetkisiyle karıştırırsa, diyagramı üzerinde anlaşılmış sınır olarak paylaşmadan önce etiketleri değiştirin.
Sık sorulan sorular
Proje bağlam diyagramı, C4 bağlam diyagramıyla aynı mıdır?
Her zaman değil. C4 sistem bağlam diyagramı tek bir yazılım sistemini, dış kullanıcılarını ve sistemlerini açıklar. Proje bağlam taslağı daha geniş kurumsal ilişkileri kapsayabilir. Bu kapsamları sessizce karıştırmak yerine görünümün adını ve amacını açıkça belirtin.
Bağlam diyagramında ne kadar ayrıntı olmalı?
Sınır kararını desteklemeye ve önemli dış ilişkileri belirlemeye yetecek kadar ayrıntı ekleyin. Faaliyet sıraları, tarihler ve iç teknik ayrıntılar bağlamı anlamayı zorlaştırıyorsa bunları ayrı görünümlere taşıyın.
Bağlam diyagramı kapsam bildiriminin yerini tutabilir mi?
Hayır. İnsanların kapsamı tartışmasına yardımcı olur ancak her gereksinimi, kabul ölçütünü, yükümlülüğü veya kapsam dışı konuyu kaydetmez. Onaylı proje belgeleriyle tutarlı olmasını sağlayın ve görüşmede alınan kararları kaydedin.