Yazılım geliştirme ekiplerinin süreç belgelendirme projelerine mesafeli yaklaşmasının en yaygın nedeni, geçmişte yanlış kurgulanmış ağır dokümantasyon şablonlarıdır. Oysa doğru mühendislik danışmanlığıyla kurgulanan bir TS ISO/IEC 33061 sistemi, iki haftalık Scrum sprintleriyle çalışan bir yazılım ekibine tek bir gereksiz Word tablosu bile doldurtmadan tam denetim uyumu sağlar.
Çift Yönlü İzlenebilirlik (Bi-Directional Traceability) Nasıl Otomatikleştirilir?
ISO/IEC 33061 Seviye 2 ve Seviye 3 değerlendirmelerinde Başdeğerlendiricinin en titizlikle incelediği konu, müşteri ihtiyacından canlı ortamdaki sürüme kadar uzanan kesintisiz izlenebilirlik zinciridir. Proxy Eğitim ve Danışmanlık projelerinde bu zinciri 5 katmanda otomatikleştiriyoruz:
- Katman 1 — Paydaş İhtiyacı (Epic / Müşteri Talebi): İş birimi veya ihale teknik şartname maddelerinin benzersiz kimliklerle Jira/Azure DevOps üzerinde tanımlanması.
- Katman 2 — Yazılım Gereksinimi (User Story + Kabul Kriterleri): Her User Story'nin test edilebilir kabul kriterleri, güvenlik gereksinimleri (ISO 27001 Ek-A 8.26) ve üst Epic bağlantısıyla açılması.
- Katman 3 — Mimari ve Detaylı Tasarım: Servis kontratları (OpenAPI/Swagger), veritabanı şema değişiklikleri ve bileşen diyagramlarının ilgili Story'lere doğrudan bağlanması.
- Katman 4 — Kaynak Kod ve Akran İncelemesi (Git Branch / PR): Dal (branch) ve commit mesajlarında Jira anahtarının zorunlu kılınması; en az bir kıdemli geliştirici incelemesi olmadan ana dala birleştirmeye (merge) izin verilmemesi.
- Katman 5 — Doğrulama Testleri ve Sürüm Etiketi (Test Case & Release Tag): Birim, entegrasyon ve sistem test koşumlarının CI/CD ve test yönetimi eklentileri üzerinden ilgili gereksinime ve sürüm etiketine bağlanması.
Denetim Öncesi Kendinizi Test Edin: 4 Hızlı Kontrol Sorusu
Eğer önümüzdeki 6 ay içinde bir kamu bilişim ihalesine veya KTS tesciline girmeyi planlıyorsanız ekibinize şu dört soruyu sorun: (1) Son 3 sprintte tahmin edilen Story Point ile gerçekleşen hız sapmasını analiz ettik mi? (2) Her Pull Request'te gerçek kod inceleme yorumu var mı? (3) Bağımsız bir QA/SQA sorumlusu süreç uyumunu denetliyor mu? (4) Canlıdaki v2.4.1 sürümünün tam olarak hangi gereksinimleri ve test raporlarını içerdiğini 2 dakikada gösterebiliyor muyuz? Bu sorulardan herhangi birine yanıtınız "hayır" ise Proxy Danışmanlık mühendislik ekibiyle iletişime geçerek ücretsiz boşluk analizi planlayabilirsiniz.
Sprint İçinde PA 2.1 ve PA 2.2 Kanıtlarını Üreten Pratik Scrum Ritüelleri
Çevik takımlarda var olan Scrum toplantılarını hiçbir ek toplantı icat etmeden doğrudan ISO/IEC 33020 süreç niteliği kanıtına dönüştürmek mümkündür:
- Sprint Planning (Planlama): Kapasite hesabı, Story Point tahmini, bağımlılık ve sprint risklerinin Jira üzerinde kayda geçirilmesi doğrudan PA 2.1 Performans Yönetimi kanıtıdır.
- Definition of Done (Tamamlanma Tanımı — DoD): Kod incelemesi yapılmamış, birim testi yazılmamış ve kabul kriterleri doğrulanmamış hiçbir işin "Done" sütununa geçirilmemesi doğrudan PA 2.2 İş Ürünü Yönetimi kanıtıdır.
- Sprint Review ve Retrospective: Ürün sahibinin sürüm kabulü (SPL.2 / Geçerleme) ve retrospektif iyileştirme aksiyonlarının takibi ise sürekli süreç iyileştirme kültürünü belgelendirir.
Daha fazla teknik detay için ISO 33061 ve ISO 15504 SPICE Farkları rehberimizi de inceleyebilirsiniz.