Spice Belgelendirme Süreci
ISO Belge / DM Belgelendirme | Yazılım Süreç Değerlendirme ve Danışmanlık
SPICE Belgelendirme Süreci (ISO/IEC 15504) — Adım Adım Uygulama Rehberi
Bu sayfa “SPICE nedir?” yazısı değil. SPICE belgelendirme sürecinde hangi adımda ne yapılır, hangi kanıt üretilir, kim neyi teslim eder sorularına pratik cevap verir. Amaç; süreci doküman projesine çevirmeden, assessment gününe kadar kontrollü ilerlemektir.
Adres: Huzur Mahallesi 1218 Cadde No:13/B, Öveçler / Çankaya / Ankara · E-posta: dmbelgelendirme@gmail.com
Hızlı Not: SPICE kelimesi internette farklı anlamlarda geçebilir. Bu sayfa, yazılım süreç değerlendirmesi (ISO/IEC 15504 yaklaşımı ve devamındaki değerlendirme mantığı) odağında hazırlanmıştır. “Baharat/marka” gibi farklı niyetlerdeyseniz bu içerik hedeflediğiniz konu değildir.
SPICE belgelendirme süreci nedir, hangi ihtiyacı çözer?
SPICE belgelendirme süreci; yazılım geliştirme süreçlerinin planlı, izlenebilir ve tekrarlanabilir olduğunun kanıtlanmasına yönelik bir değerlendirme yolculuğudur. “Belge” kelimesi tek başına yanıltıcı olabilir: pratikte asıl çıktı, değerlendirme raporu ve bu raporu taşıyan kanıt (evidence) yapısıdır.
Bu süreç; özellikle dış müşteriye proje geliştiren ekiplerde, ana yüklenici veya kurumsal müşterinin “süreç kabiliyeti” beklentisini karşılamak için kullanılır. Süreçler kişiye bağlı ilerliyorsa; teslimat riski, kalite riski ve değişiklik yönetimi riski büyür. SPICE, bu riskleri ölçülebilir hale getirir.
- Öngörülebilirlik: Proje planı “kağıt” olmaktan çıkar.
- İzlenebilirlik: Gereksinim → Tasarım → Kod → Test zinciri kurulur.
- Kontrol: Değişiklikler kayıt altına alınır ve onay mekanizması işler.
- Kanıt: “Yaptık” yerine “şu kayıttan görebilirsiniz” düzeyi gelir.
SPICE çerçevesinin tamamını görmek isterseniz: SPICE Belgesi Rehberi sayfası üzerinden devam edebilirsiniz.
Süreç başlamadan önce: kapsam ve hedef seviye nasıl belirlenir?
SPICE’de en pahalı hata, “her şeye aynı anda başlamak”tır. Önce kapsam ve hedef seviye netleşir; aksi halde hem ekip yorulur hem de kanıt üretimi dağılır. Kapsam belirleme; değerlendirmeye girecek süreç alanlarını, proje tipini ve hedeflenen capability level’ı tanımlar.
Kapsam belirlemede sorulan 7 net soru
- Hedef seviye nedir (Level 2 mi, Level 3 mü)?
- Değerlendirilecek süreç alanları hangileri?
- Kaç proje/ekip değerlendirmenin parçası olacak?
- Gereksinim → test izlenebilirliği hangi araçlarla yürütülüyor?
- Değişiklik ve konfigürasyon kontrolü nasıl yapılıyor?
- Mevcut dokümantasyon ve kayıt kalitesi hangi düzeyde?
- Assessment takvimi var mı, yoksa hedef tarih mi belirleniyor?
Bu soruların amacı “teorik” konuşmak değil; süreci planlamaktır. Kapsam netleştiğinde hem zaman çizelgesi hem de teklif gerçekçi çıkar.
Gap analizi: ilk hafta ne yapılır, ne çıkar?
Gap analizi, mevcut durumun fotoğrafıdır. “Nerede eksik var?” sorusunu hissiyatla değil, kanıtla cevaplar. İyi bir gap analizi sonunda; hangi süreç alanında hangi pratik eksik, hangi kayıt yok, hangi rol belirsiz netleşir.
- Doküman inceleme: Süreç tanımları, planlar, şablonlar
- Tool inceleme: ALM/Jira/Req tool, test yönetimi, versiyon kontrol
- Mülakat: Proje yöneticisi, QA, analist, test lideri, teknik lider
- Örnek proje taraması: 1–2 projede izlenebilirlik ve kayıt örnekleri
Gap analizi çıktısı (teslim edilecek 5 şey)
- Hedef seviye için eksik haritası (madde madde)
- Önceliklendirilmiş yol haritası (hangi adım önce?)
- Rol ve sorumluluk netleştirme notları
- Kanıt (evidence) planı: hangi kaydı nereden üreteceğiz?
- Gerçekçi zaman çizelgesi: hafta hafta plan
Bu noktadan sonra süreç “doküman yazma” değil, iş yapma biçimini standardize etme safhasına geçer.
Süreç tasarımı: rol/sorumluluk ve iş akışı nasıl oturtulur?
Gap analizi “ne eksik” sorusunu cevapladıktan sonra, asıl kritik adım süreç tasarımıdır. Burada amaç; bir doküman seti üretmek değil, ekiplerin günlük iş yapma biçimini standardize etmektir. Eğer rol ve sorumluluklar net değilse kanıt üretimi dağılır ve assessment günü aynı soruya 4 farklı cevap çıkar.
Süreç tasarımında iki şey birlikte ele alınır: (1) Akış (kimden kime, hangi onayla ilerliyor?) ve (2) Kayıt (bu akışı nasıl kanıtlıyoruz?). Bu ikisinden biri eksikse, süreç kağıt üstünde kalır.
Süreç tasarımında “minimum sağlam” kurallar
- Her süreç için tek bir sahip (process owner) belirlenir.
- Her çıktının giriş–çıkış tanımı yapılır (input/output).
- Onay gerektiren adımlar görünür hale getirilir (review/approval).
- “Bitti” tanımı yazılır: Done kriteri net olur.
- Kayıtlar nerede tutuluyor: tool, repo, doküman havuzu netleşir.
Bu kurallar “kurumsal gösteriş” değildir. Değerlendirme sırasında sorulan soru şudur: “Bu iş tekrar yapılabilir mi?” Cevap, ancak rol ve akış netse “evet” olur.
Kanıt (Evidence) mantığı: “doküman” değil “uygulama kaydı”
SPICE belgelendirme sürecini rakiplerden ayıran en kritik fark kanıttır. Çünkü assessment’te genellikle “doküman var mı?” sorusu değil, “bu doküman yaşanıyor mu?” sorusu sorulur. Yani kanıt; tek başına süreç dokümanı değil, o sürecin sahada uygulandığını gösteren izlerdir.
| Kanıt Türü | Nereden Üretilir? | Ne Gösterir? |
|---|---|---|
| Plan Kayıtları | Proje planı / sprint planı | Planlama ve takip disiplinini |
| Review & Approval İzleri | PR review, doküman onayı, toplantı tutanağı | Kalite kontrol mekanizmasını |
| Traceability (İzlenebilirlik) | Req → test linkleri, ALM aracı | Gereksinimin testle doğrulandığını |
| Değişiklik Kayıtları | Change request / ticket / onay akışı | Değişikliklerin kontrol altında olduğunu |
| Test Kayıtları | Test planı, test raporu, sonuç logları | Doğrulama/validasyon disiplinini |
| Konfigürasyon İzleri | Repo tags, release notları, versiyon şeması | Versiyon kontrol ve release yönetimini |
Kanıt üretimi bu yüzden “doküman yazma”dan daha zordur. Çünkü alışkanlık değiştirir: ekip artık işin sonunda değil, işin içinde kayıt üretir.
Rol bazlı checklist: kim neyi üretir?
SPICE belgelendirme sürecinde “herkes her şeyi yapıyor” düzeni çalışmaz. Değerlendirme, net rol ve net çıktı ister. Aşağıdaki checklist, değerlendirme gününde kimden hangi kanıtın beklenebileceğini pratik şekilde gösterir.
Proje Yöneticisi
- Proje planı ve takip raporları
- Risk ve issue yönetimi kayıtları
- Milestone / teslimat izlencesi
- Değişiklik taleplerinin karar kayıtları
QA / Süreç Sorumlusu
- Süreç tanımları ve güncellemeler
- Review/approval mekanizması kayıtları
- İç denetim (prova) bulguları
- Düzeltici aksiyon takibi
Analist / Requirements
- Gereksinim setleri ve versiyon takibi
- Gereksinim değişiklik kayıtları
- Traceability (req → test) linkleri
- Review notları / onay kayıtları
Test Lideri
- Test stratejisi, test planı
- Test case setleri ve sonuç raporları
- Defect yönetimi ve kapatma kanıtları
- Validasyon/Doğrulama kayıtları
Bu checklist; ekipteki herkesin neyi sahiplenmesi gerektiğini netleştirir. Net sahiplik, kanıt üretimini “panik”ten çıkarır.
Zaman çizelgesi: 4 aşamada gerçekçi SPICE hazırlık planı
Aşağıdaki plan “her firmaya uyar” diye yazılmadı. Mantığı göstermek için hazırlandı: hangi haftada hangi çıktı üretilir. Kapsam büyüdükçe süre uzar; ancak akış aynı kalır.
| Aşama | Süre | Çıktı |
|---|---|---|
| 1) Kapsam + Gap | Hafta 1–2 | Eksik haritası + yol haritası + kanıt planı |
| 2) Süreç Tasarımı | Hafta 3–6 | Rol/akış standardı + şablon + onay mekanizması |
| 3) Uygulama + Kanıt | Hafta 7–10 | Gerçek proje üzerinde izlenebilir kayıtlar |
| 4) İç Değerlendirme | Hafta 11–12 | Denetim provası + aksiyon listesi |
Süreci hızlı planlamak ister misiniz?
15–20 dakikalık kapsam görüşmesiyle hedef seviye + süreç alanı + zaman planı netleşir. Sonrasında yol haritası ve teklif çerçevesi çıkar.
Resmi Assessment Günü: Ne Sorulur, Ne Beklenir?
Resmi assessment günü “doküman gösterme günü” değildir. Değerlendiriciler genellikle akış üzerinden ilerler: bir gereksinim seçilir, o gereksinimin tasarıma, koda ve teste nasıl yansıdığı sorulur.
Bu nedenle assessment öncesi prova yapılması kritik önemdedir. Prova sırasında ekip üyelerine şu tip sorular yöneltilir:
- Bu gereksinim değiştiğinde süreci nasıl başlatıyorsunuz?
- Bu değişiklik hangi onay mekanizmasından geçti?
- Bu test sonucu hangi gereksinimi doğruluyor?
- Riskleri nasıl izliyorsunuz ve kim raporluyor?
Sorular genellikle teknik detaydan çok süreç disiplini üzerinedir. Eğer kanıt zinciri kopmuyorsa, süreç güvenle ilerler.
Genel Uygulamalar vs Bu Yaklaşım
| Genel Uygulama | Bu Yaklaşım |
|---|---|
| Süreç dokümanı hazırlanır | Süreç uygulanır ve kanıt üretilir |
| Şablon dağıtılır | Rol bazlı sahiplik ve akış tanımlanır |
| Assessment günü hazırlanılır | Assessment öncesi iç denetim yapılır |
| Geçmeye odaklanılır | Sürdürülebilir süreç kültürü kurulur |
Amaç yalnızca seviye almak değil; seviye kaybetmeyecek yapı kurmaktır.
Süreç Sonrası: Sürdürülebilirlik Nasıl Sağlanır?
SPICE belgelendirme süreci assessment ile bitmez. Eğer ölçüm ve iç kontrol mekanizması kurulmazsa süreç zamanla gevşer.
- Periyodik iç değerlendirme planı
- Süreç performans göstergeleri (KPI)
- Değişiklik ve risk izleme disiplini
- Yeni ekip üyeleri için adaptasyon eğitimi
Süreç sürdürülebilir olduğunda SPICE, “proje” olmaktan çıkar; kurumsal alışkanlık haline gelir.
Sıkça Sorulan Sorular – SPICE Belgelendirme Süreci
SPICE süreci kaç ay sürer?
Kapsam ve hedef seviyeye bağlı olarak genellikle 3–6 ay arası planlanır.
Assessment’e doğrudan girilebilir mi?
Gap analizi ve iç değerlendirme yapılmadan girilmesi risklidir.
Dokümanlarımız var, yeterli mi?
Doküman tek başına yeterli değildir; uygulama kanıtı gerekir.
Süreç tüm projelere mi uygulanır?
Değerlendirme kapsamına giren projelerde uygulanması gerekir.
İç denetim zorunlu mu?
Resmi olarak zorunlu olmasa da assessment öncesi güçlü şekilde önerilir.
SPICE Belgelendirme Sürecini Net Planlayın
Kapsam, hedef seviye ve zaman planını birlikte netleştirerek süreci kontrollü ilerletin. İlk adım doğru atıldığında assessment günü sürpriz olmaz.