Bu yazımızda; SPICE yazılım geliştirme ve organizasyonel olgunluk standardı hakkında genel bilgilerden, belge alım sürecindeki puanlama sisteminden, denetim aşamasından ve SPICE Seviye 2 süreçlerinde uygulanması gereken bazı noktalardan bahsedeceğiz.

ISO/IEC 15504 SPICE Nedir?

ISO/IEC 15504 SPICE, geliştirilen yazılımların süreçlerinin kalitesini iyileştirmek amacı ile Uluslararası Standardizasyon Kurumu (ISO) ve Uluslararası Elektronik Komisyonu (IEC) tarafından ortaklaşa oluşturulmuş bir standartdır. SPICE standardının zorunlu hale gelmesi, Devlet Planlama Teşkilatı Müsteşarlığı tarafından, kamunun bilgi ve iletişim teknolojileri alanındaki yatırımlarına ilişkin genel ilke ve esasların belirlendiği “Kamu Bilgi ve İletişim Teknolojileri Projeleri Hazırlama Kılavuzu” ile başlamıştır. Bu kılavuzda, SPICE standardının yazılım geliştirmede kamu yazılım projelerindeki başarısızlıkların önüne geçmenin yanı sıra, sektörde kalite sertifikasyonunun teşvik edilmesi ve uluslararası rekabet gücüne katkı sağlanması amacıyla kamu yazılım projelerinde 2007 yılından itibaren yüklenicilerden projenin doğasına ve tutarına uygun olarak ISO/IEC 15504 SPICE Seviye 2 yazılım kalite modellerinin uygulanması veya CMMI Seviye 3 olmaları şartı istenmektedir.

SPICE Seviye 2 için işletilmesi gereken süreçler:

• MAN.3 (Proje Yönetimi)
• MAN.5 (Risk Yönetimi)
• SPL.2 (Sürüm Yayınlama)
• SUP.1 (Kalite Güvence)
• SUP.2 (Doğrulama)
• SUP.7 (Dokümantsayon)
• SUP.8 (Konfigürasyon Yönetimi)
• SUP.9 (Problem Çözüm Yönetimi)
• SUP.10 (Değişiklik İsteği Yönetimi)
• ENG.1 (Gereksinimlerin Elde Edilmesi)
• ENG.4 (Yazılım Gereksinimlerinin Analizi)
• ENG.5 (Tasarım)
• ENG.6 (Yazılım Geliştirme)
• ENG.7 (Yazılım Entegrasyon)
• ENG.8 (Yazılım Testi)

Türk Standartları Enstitüsü (TSE)'nün Seviye 2 denetimlerinde 15 süreçten toplam 45 soru sorulur. Süreçler, basamaklara bölünerek puanlanır. Puanlar F (tam uygulanmış), L (büyük oranda uygulanmış), P (düşük seviyede uygulanmış), N (uygulanmamış veya geçersiz) şeklindedir. 45 sorudan 4 tanesi "N" olarak puanlandığında firma, SPICE'a uygunsuz olarak derecelendirilir ve başvuru sürecinin başına dönülür.

Genel Beklentiler

• Proje Yönetim Planı (PYP), fizibilite çalışması ve kod standardının mutlaka bulunması istenir. Bunlar dışındaki süreçlerin, standartlara uygun işletilip işletilmediğine bakılır ve süreçlerle ilgili kanıtlar incelenir.
• Süreçlerde işletilmeyen kısımların değerlendirilip neden işletilmediğinin yazılması istenir. Değerlendirme yapılmamışsa, süreç gözden kaçırılmış olarak kabul edilir.
• Başvuru yapan firmalar için en az bir yıl tecrübeli 1 çalışan istenir ancak SPICE uygunluğunun sağlanabilmesi en az 3 kişilik ekip olması mantıklıdır.
• Denetimde en az 2 projede SPICE uygulanması beklenir. SPICE'ın firma tarafından kavranıp kavranamadığı kontrol edilir.
   

Süreç Basamakları

• Seviye 1’de her süreç için farklı sayıda belirlenen temel uygulamalar (base practice-BP) değerlendirilir. Seviye 1: PA 1.1: Süreç Performansı.
• Seviye 2’de ise her süreç için aynı sayıda belirlenen genel uygulamalar (generic practice-GP) değerlendirilir. Seviye 2: PA 2.1: Performans Yönetimi ve PA 2.2: İş Çıktısı Yönetimi.

Süreç Puanlandırması

TSE denetimi sırasında her süreç ayrı ayrı değerlendirilir. Öncelikle ilgili sürecin BP'leri değerlendirilip PA 1.1 için puanlama yapılır. Daha sonra PA 2.1 süreç niteliğinin karakteristiğini oluşturan 6 tane GP ve PA 2.2 için 4 tane GP değerlendirilir.  Bu değerlendirmelere göre PA 2.1 ve PA 2.2 puanlanır. Not aralıkları:

• Not Achieved (N) %0-%15: Beklenen iş çıktıları yok veya gösterilen içerik kabul edilemez durumda.
• Partially Achieved (P) %16-%50: İstenilen iş çıktıları var fakat yetersiz.
• Largely Achieved (L) %51-%85: Sistematik bir yaklaşım olmasına rağmen istenilen çıktıları başarmada yer yer eksiklikler var.
• Fully Achieved (F) %86-%100: Tam ve sistematik bir yaklaşım var. İstenilen iş çıktıları elde edilebilir, bir risk bulunmuyor.

SPICE belgesine hak kazanabilmek için tüm PA 1.1'lerden "F" notu alınması, PA 2.1 ve PA 2.2 notlarının ortalamasında %51'lik başarı oranının sağlanması gereklidir.
 

15 Süreç İçin Yürütülmesi İstenen Ana Başlıklar

• Süreç planı/stratejisi: Hangi sürecin, neden, nasıl işletildiği sorularının cevabı verilir. Planların, süreci yöneten kişi/kişiler değiştiğinde veya yenileri geldiğinde bile süreci aksatmadan yürütülebilecekleri kadar açık ve bilgilendirici bir anlatımı olmalıdır.
• Süreç hedefleri: Süreç başarı kriterlerinin belirtilmesidir. Hedeflerin 2.seviyeyi karşılaması istenir. Örn. Müşteri memnuniyeti anketi için "müşterilerin tamamına anket gönderilmesi" hedefi kabul edilmez, seviye-2 için müşteri memnuniyeti veya anket cevaplama oranı kriterleştirilmesi uygundur.
• İç denetim/süreç kontrolü: Süreçlerin şirket planına uygunluğu, teknik olarak yeterliliği (dokümantasyon vb.) ve sürecin doğru işletilip işletilmediğinin kontrol edilmesidir. Onay mekanizmaları ve kurum/firma içi denetimler mümkün olduğunca çapraz bir sistematikte çalışmalıdır. Örn. A personeli B personelini, B personeli de C personelini denetlemelidir. B personeli B'yi yani kendisini denetlememelidir. İç tetkik veya benzer kalite kontrol faaliyetlerinin raporlaması için; sorulan soru açık ve anlaşılabilir olmalı, rapor edilen olumlu/olumsuz bulgulara nasıl ulaşıldığı hakkında açıklamalar mevcut olmalıdır:
  • En başarısız raporlama örneği:  "Performans hedefleri öngörülen haftalarda ölçülmüş mü?". Cevap: "Evet, yapıldı."
  • Uygun raporlama: "Performans hedefleri öngörülen haftalarda ölçülmüş mü?". Cevap: "9 Nisan 2018 haftası öngörülmüş ve ayın 10’unda ölçüm yapılmış."
  • Uygun raporlama: "Performans hedefleri öngörülen haftalarda ölçülmüş mü?". Cevap: "Hayır, elektrikler kesildi o hafta yapamadık. 2 hafta gecikme ile yapılacak."

• Performans: İç denetim sonrası süreç başarı/başarısızlığının ortaya çıkarılmasıdır. Belirlenen eşiklere göre önlem alınması veya düzeltmede bulunulması beklenir.
• Şablon (taslak doküman veya e-form): İlgili sürecin boş halinin tutulmasıdır. Bu şablonun yönlendiriciliği ve başka projelerde kullanılabilirliği ölçülür.

Ana Başlıklarla Beraber Süreç Bazında Denetlenen Bazı Kısımlar

• Proje Yönetimi - MAN3
  • Proje kullanım alanlarının belirtilmesi.
  • Proje ne amaçla yazıldığı (müşteri talebi/şirketin iş fikri).
  • Proje motivasyonu.
  • İş takibi, müşteri ilişkileri nasıl yönetilidiği.
  • İşin (projenin) değerlendirilme aşaması.
    • Müşteriden gereksinim (istek) toplama veya şirket içinde belirleme (toplantı vb. belgeleme).
    • Belirlenen gereksinimlerin şirket içi onaydan geçmesi (toplantı vb. belgeleme).
  • Proje yaşam döngüsüne (waterfall, spiral vs.) karar verilmesi ve nasıl karar verildiği.
  • Proje fizibilitesinin çıkarılması: Hangi teknolojiler kullanılacak, işin boyutu ve karmaşıklığı, işe dahil olacak kişilerin çalışma saati ve maliyeti, varsa donanım giderleri vb., bütçe gibi etkenleri içeren çalışmadır. Bu çalışmayı bütçenin ne kadarı kullanılmış, ne harcamalar yapılmış gibi bilgilerin tutulması için proje başında ve sonunda veya dönemsel olması istenir.
  • Proje yönetiminin nasıl yapıldığı.
  • Dönemsel veya proje dönem noktalarında proje durumuyla ilgili raporlama yapılması (maaliyet, sapma vb. izlenmesi).
  • İş dağılım ağacı (İDA) oluşturulması.
  • Süreçlerle ilgili rollerin belirlenmesi.
     
• Risk Yönetimi - MAN5
  • Risklerin belirlenmesi/tanımlanması.
  • Risklerin analiz edilmesi: Yaşanma olasılığı, etkisi vs. değerlendirilmesi. Bu olasılık ve etki derecelerinin nasıl belirlendiğine dair kayıt tutulması. Örneğin: 5. derece risk yaşanırsa işleri durdurur, 4. derece risk işleri aksatır vb.
    Risklerin dönemsel olarak raporlanması: Yaşanma olasılığının, etkisinin periyodik olarak yeniden gözden geçirilmesi ve yaşanma sayılarının yazılması.
     
• Dokümantasyon Süreci - SUP7
  • Doküman yönetim sistemi (DYS).
  • Revizyonlama, belge tarihçesi ve belgelerin eski hallerinin arşivlenmesi.
  • Kararların toplantıyla alınması ve katılımcılar tarafından imzalaması.
  • Dokümanların kontrolü: Kontrol dökümanlarının oluşturulması (şablona uygunluk, içerik uygunluğu vb. kontrolü/denetimi). Yapılan kontrolde bulunmuş uygun ve uygunsuz durumların ayrıntıları istenir.
  • Onay sürecinin "Yazan -> Gözden geçiren -> Onaylayan" olarak işletilmesi ve işletildiğine dair kanıt (ıslak imza, e-imza, e-posta vb.).
  • Düzeltici önleyici faaliyetlerin (DÖF) nasıl yapıldığı. Örn. Risk önlenmesi, dokümanda veya projede düzeltici faaliyet ilerin nasıl yapılacağının belirlenmesi.
  • DÖF kayıtlarının tutulması.
  • DÖF etkinliğinin izlenmesi: Bazı durumlarda düzeltici-önleyici faaliyetin işe yarayıp yaramadığının takibi.
  • DÖF'lerin içeriğinin açıklayıcı olması: Yaşanma sebebi (kök neden), ortaya çıkan durum, yapılan faaliyetin açıklanması vb.
  • Doküman isimlendirme kuralının belirlenmesi.
  • Doküman şablonların oluşturulması.
     
• Kalite Süreci - SUP1
  • Kalite güvence planı.
  • Müşteri anketleri planı.
  • Her iş çıktısı (doküman, e-form, kodlamalar vb.) iç denetimden geçmeli, işin uygunluğu kontrol edilmeli. (TSE baz alınabilir)
  • İç denetim sorularıyla eldeki verilerin uygunluğunun denetlenmesi.
  • Şikayet yönetimi.
  • İşletilen her süreç için uygun hedef belirlenmesi.
  • Her faaliyetin/işin şablonunun oluşturulması.
  • Kontrol listeleri için objektif deliller tutulması. Örn. "Test Senaryoları (TS) ile Gereksinimler (G) eşleştirilmiş mi?" Cevap: "Evet: TS1 => G6, G14, G20" 
     
• Konfigürasyon Yönetimi - SUP8
  • Doküman, veritabanı, exe, kütüphane gibi konfigürasyon bileşenlerinin (proje bileşenleri) mutlaka kaydının tutulması (bileşen adı, sürümü ve projede ne amaçla kullanıldığına dair tablo/liste). Belirli aralıklarla bu listenin tekrar oluşturulması (periyodik veya versiyon değişiminde).
  • Veritabanı (vt) anahattı (baseline) alınması: VT'nin yapısal değişimini görebilmek için belirli periyotlarla boş yedeği alınmalı ve arşivlenmeli.
  • Projenin önceki haline dönüş kaydı sağlanması: Tüm projenin (kütüphane vb. dahil) yedeklenmesi. Proje kapsamına göre değişmekle beraber en az 2 adet anahat oluşturulmalı.
  • Branch stratejisi, paralel geliştirme için kurallar (parelel geliştirme yapılmıyorsa bunun değerlendirilip işletilmediğinin yazılmalı).
  • Yedek(backup), arşivleme kuralları.
     
• Gereksinim Toplama ve Analizi - ENG1, ENG4
  • Gereksinim belirleme/toplama toplantısı (müşteri veya şirket içi).
  • Toplanan gereksimlerin şirket içinde onaylanması ve onay kaydı (toplantı tutanağı vb. kanıt).
  • Gereksinimlerin tanımlanması.
  • Gereksinimlerin detaylandırılarak yazılması. Örn. Gereksinim olarak yer alan yeşil meyveler listesinde hangi yeşil meyvelerin yer alacağının belirtilmesi.
  • Gereksinimlerin analiz edilmesi: Modüle bölünmesi, sınıflandırılması (fonksiyonel gereksinim (FG), sistem gereksinimi (SG), performans gereksinimi (PG) gibi), etki analizinin yapılması ve testlerinin planlanması. Örn. FG = "Cep telefonu alanına sadece sayısal değer girilecektir" ise bunun test için başarı kriteri yazılmalıdır, test kriteri = Alana metin girildiğinde pencere (pop-up) ile "Sadece sayısal değer girelebilir" uyarısı verilecektir.
  • Gereksinimlerin takibi/izlenebilirliği: Gereksinimlerin nereden nereye geldikleri, yapılıp yapılmadığı, hangi testlerin uygulandığı, hangi ekranların tasarlandığı gibi diğer süreçlerinde içinde izlenebilirlik oluşturulması.
  • İş takip ortamında (JIRA, Redmine, TFS vb.) FG'lerin yer alması ve müşteri gereksinimleri (MG) ile eşleştirilmesi.
     
• Tasarım - ENG5
  • Yazılım mimarisinin ayrıntısız tanımı (topoloji vs. bilgileri).
  • Entegrasyon şekli, planı (iç veya dış).
  • Kullanıcı arayüzlerinin tanımlanması ve arayüzlerin FG'lerle eşleştirilmesi.
  • Her tasarımın test edilebilirik/gerçekleştirilebilirlik analizi.
  • Tasarımların onayı ve onay kanıtı (müşteri veya şirket içi).
  • VT tasarımının FG'ler ve ekran bileşenleriyle eşleştirilmesi.
  • Yazılım tasarım tanımlarının kodla eşleştirilmesi.
     
• Yazılım Geliştirme - ENG6 
  • Birim (unit) testlerin ve sonuç raporlarının oluşturulması.
  • Ana hattın (baseline) oluşturulması. Proje kapsamına göre değişmekle beraber en az 2 adet.
  • Kodlama standardı oluşturulması.
  • İç denetimle FG'lerin ve kod standardının uygunluğun kontrol edilmesi.
     
• Yazılım Entegrasyon - ENG7
  • İç veya dış entegrasyon bilgilerinin verilmesi

• Yazılım Testi - ENG8
  • Kategorize edilmiş test durumları/senaryoları oluşturulması (entegrasyon, regrasyon, performans vb.)
  • Kategoriler için ayrı raporlar oluşturulması.
  • Regrasyon testlerinin oluşturulması (yapılan değişiklik/yenilik sistemi bozmuş mu?)
  • Değişiklerle ilgili ağ oluşturulması: "FG10 değişikliği FG1-FG5-FG7'yi etkiler" gibi ve bu FG'ler için regresyon testi yapılması.
  • Tüm gereksinimlerin test edilmesi.
     
• Sürüm Yayınlama - SPL2
  • Hangi ürünler, nasıl teslim edileceğinin belirlenmesi.
  • Build süreci.
  • Sürümleme kurallarının belirlenmesi.
  • Sürüm notlarının çıkarılması, "changelog" oluşturulması.
  • Müşterilere yazılımsal destek süresinin belirlenmesi.
  • Sürüm bazında müşteri kabul/onay tutanağı vb. oluşturulması.
  • Kurulum ve kullanım kılavuzu oluşturulması.
     
• Doğrulama - SUP2
  • İşletilen süreçlerin uygunluğunun kontrol edilmesi.
  • Devam eden süreçlerin periyodik olarak denetlenmesi.
  • Her sürecin teknik yeterliliğinin ve raporlarının incelenmesi.
  • Hangi personelin hangi personeli denetleyeceğinin belirlenmesi.
  • Denetim sorularının ve cevaplarının uygunluğunun kontrolü.
  • Doğrulamada tespit edilen uygunsuzlukların takibinin yapılması.
  • Yazılım/kod için kontrol listesi oluşturulması
  • Paydaşlarla doğrulamaların paylaşılması: Doğrulama sonuçlarının tamamının veya bir bölümünün e-bülten, web sayfası, infografik vb. aracılığıyla paylaşılması.
     
• Problem Çözüm ve Değişiklik İsteği Yönetimi - SUP9, SUP10
  • Problemlerin kaydedilmesi ve sınıflandırılması.
  • Problem/değişiklik kayıt oluşturma formu şablonu. Form dışında varsa telefon, e-posta vb. kayıtları.
  • Gelen işlerin kişilere atamasının yapılması, çözülmesi vb. durumlarda bildirim yapılması.
  • Problem çözüm yönteminin açıklanması.
  • Problem yönetimi.
  • Hangi hataların neden kabul edildiğinin açıklanması.
  • Değişiklik yönetimi.
  • Değişiklik etki analizi yapılması, gereksinim ve bileşen eşleştirilmesi.
  • Değişikliklerle ilgili regrasyon testleri yapılması.
  • Değişikliği talep edenin (şirket içi veya dışı) değişiklikle ilgili yapılan işlemi onaylaması/kapatması.
     

SPICE belgesine hak kazanabilmek için süreçlerin Seviye 1 değerlendirmelerinin tümünden "F" notu alınması, Seviye 2 değerlendirmelerinin ortalamasından ise %51'lik başarı oranı yakalanmalıdır. Bu başarı oranı yakalanamazsa firma tekrar denetimine bırakılır, düzeltmeler istenir. 4 adet "N" notu alınması SPICE uygunsuzluğuna sebep olur ve süreçte başa dönülür. SPICE sürecinde tüm firmalara başarılar dileriz :)