Teoriden pratiğe: GOST R ISO/IEC 25010:2015 yazılım kalitesini nasıl iyileştirir
GOST R ISO/IEC 25010:2015, uluslararası ISO/IEC 25010 standardıyla uyumlu hale getirilmiş ve yazılım kalitesinin değerlendirilmesi için tek bir model tanımlayan Rusya Federasyonu ulusal standardıdır. Temel amacı, "çalışıyor/çalışmıyor" şeklindeki öznel görüşü, 8 temel özellik (işlevsellik, güvenilirlik, güvenlik vb.) üzerinden ölçülebilir metriklere dayalı bir yaklaşımla değiştirmektir. Standardın uygulanması, ekiplerin riskleri erken aşamalarda tespit etmesine olanak tanır, devlet siparişlerinin kabulünü kolaylaştırır ve geliştiriciler ile müşteriler için şeffaf bir gereksinim sistemi oluşturur.
Standardın özü ve önceki versiyonlardan farkı
2015 yılına kadar Rusya'da öncelikli olarak teknik parametrelere odaklanan GOST 28195-89 standardı yürürlükteydi. Yeni standart, odağı kullanım kalitesine (Quality in Use) kaydırır. Bu, bir programın yalnızca hata içermemesi durumunda değil, aynı zamanda etkili, güvenli ve belirli bir bağlamda kullanıcı ihtiyaçlarını karşılaması durumunda kaliteli olarak kabul edildiği anlamına gelir.
Standart, birbirleriyle bağlantılı iki modeli tanımlar:
- Ürün kalite modeli — kodun ve sistemin kendi iç ve dış özellikleri.
- Kullanım kalitesi modeli — kullanıcının gerçek ortamda sistemle etkileşiminin sonucu.
Standardın zorunlu olduğu alanlar nelerdir? GOST R ISO/IEC 25010:2015, Gümrük Birliği teknik düzenlemeleri çerçevesinde (örneğin, TR TS 020/2011) yazılım sertifikasyonu için temel teşkil eder ve devlet bilgi sistemleri (GIS) ihalelerinde sıklıkla talep edilir.
Ürün kalitesinin 8 özelliği
Bu, standardın çekirdeğidir. 8 özelliğin her biri, kontrol listeleri ve otomatik testler için somut metriklere dönüştürülebilen alt özelliklere ayrılır.
| Özellik | Ne değerlendirilir? | Alt özellik örnekleri | Pratik metrik |
|---|---|---|---|
| İşlevsel uygunluk | Beyan edilen işlevlere uygunluk | Tamlık, doğruluk, uygunluk | Teknik şartnamedeki gereksinimlerin uygulanma yüzdesi; yanlış alarmların sayısı. |
| Performans | Kaynak verimliliği | Zamanlama özelliği, kaynak kullanımı | 1000 RPS yük altında yanıt süresi < 2 sn; RAM tüketimi < 512 MB. |
| Uyumluluk | Ortamla etkileşim | Birlikte var olma, değiştirilebilirlik | İş ortaklarının API'leri ile başarılı veri alışverişi; farklı OS sürümlerinde çalışma. |
| Kullanılabilirlik | İnsan için kolaylık | Anlaşılırlık, öğrenilebilirlik, hata koruması | Yeni bir kullanıcının hedef eylemi tamamlama süresi; memnuniyet düzeyi (SUS). |
| Güvenilirlik | Çalışma istikrarı | Olgunluk, erişilebilirlik, arıza toleransı | Çalışma süresi (Uptime) %99,9; ortalama kurtarma süresi (MTTR) < 1 saat. |
| Güvenlik | Veri ve erişim koruması | Gizlilik, bütünlük, inkar edilemezlik | Tarama sonuçlarına göre Kritik seviyede açıklık olmaması; 2FA'nın bulunması. |
| Bakım yapılabilirlik | Kod değişikliklerinin kolaylığı | Modülerlik, yeniden kullanılabilirlik, analiz edilebilirlik | Kodun testlerle kapsanma oranı > %80; fonksiyonların döngüsel karmaşıklığı < 10. |
| Taşınabilirlik | Yeni ortamlara adaptasyon | Uyarlanabilirlik, kurulabilirlik, değiştirilebilirlik | Yeni bir sunucuda dağıtım süresi; farklı Linux dağıtımlarına başarılı kurulum. |
Kullanım kalitesi: Müşteri gözüyle bakış
Teknik metriklerin aksine, bu grup nihai deneyimi değerlendirir. İş uygulamaları ve tüketici hizmetleri için kritik öneme sahiptir. Standart beş yönü vurgular:
- Etkililik: Kullanıcıların hedeflerine ne kadar doğru ve eksiksiz ulaştığı.
- Verimlilik: Hedefe ulaşmak için harcanan kaynaklar (zaman, para).
- Güvenlik (kullanım bağlamında): Kullanım sırasında insanlar, işletme veya mülkiyet için risk bulunmaması.
- Memnuniyet: Kullanımdan duyulan konfor, güven ve haz.
- Risklerden arınmışlık: Ekonomik zararın veya sağlık hasarının minimize edilmesi.
Metrikler için ipucu Her şeyi aynı anda ölçmeye çalışmayın. Erken aşamadaki bir startup için İşlevsel uygunluk ve Kullanılabilirlik önceliklidir. Fintech projeleri için ise her zaman ilk sırada Güvenlik ve Güvenilirlik yer alır. Mevcut sprint için en önemli 3 özelliği seçin.
Standardın geliştirmeye adım adım entegrasyon planı
GOST R ISO/IEC 25010:2015'in uygulanması, süreçlerini mevcut geliştirme döngüsüne (SDLC) entegre ederseniz bürokrasi gerektirmez.
Adım 1. Bağlam analizi ve önceliklerin belirlenmesi
Ekibi toplayın (yönetici, geliştirici, test uzmanı, müşteri temsilcisi). Ürününüz için hangi özelliklerin kritik olduğunu belirleyin.
- Örnek: Tıbbi yazılımlar için Güvenlik ve Güvenilirlik kritiktir. Oyunlar için ise Performans ve Kullanılabilirlik ön plandadır.
Adım 2. Metriklere ayırma
Soyut kavramları sayılara dönüştürün.
- "Sistem hızlı olmalı" yerine şunu yazın: "10 Mbit/s kanal hızında ana sayfa yükleme süresi 1,5 saniyeyi geçmemelidir".
- "Kod temiz olmalı" yerine — "SonarQube'deki bakım yapılabilirlik indeksi A'nın altında olmamalıdır".
Adım 3. Araç seti ve otomasyon
Metrikleri toplamak için CI/CD pipeline'larını yapılandırın:
- Statik analiz: SonarQube, PVS-Studio (Bakım yapılabilirlik ve Güvenlik için).
- Yük testi: JMeter, k6 (Performans ve Güvenilirlik için).
- UX analitiği: Yandex.Metrica, Hotjar, NPS anketleri (Kullanılabilirlik ve Memnuniyet için).
Adım 4. Düzenli denetim ve raporlama
Haftalık kalite panoları uygulayın. Bir metrik eşik değerin altına düşerse (örneğin, test kapsamı %85'ten %70'e düşerse), build üretim ortamına gönderilmemelidir.
Sık yapılan hata "Taşınabilirlik" özelliğinin göz ardı edilmesi. Geliştiriciler genellikle yazılımı yalnızca kendi makinelerinde test eder. Sonuç olarak, müşteri tarafında kurulum sırasında bağımlılık hataları veya erişim hakları sorunları ortaya çıkar ki bu, resmen standardın ihlali anlamına gelir.
Kalite değerlendirmesinde tipik hatalar
- Kavram karmaşası: Hata olmamasının yüksek kaliteye eşit olduğunu sanmak. Bir hata düzeltilebilir, ancak sistem kullanışsızsa (düşük kullanılabilirlik), kalite yine de düşük olur.
- Temel çizgilerin olmaması: Çalışmalara başlamadan önce "nasıl olduğu" göstergelerini kaydetmediyseniz, durumun iyileşip iyileşmediğini söylemek imkansızdır.
- Resmi yaklaşım: Geliştirme sürecinde metrikleri gerçekten kullanmak yerine, projeyi teslim etmeden hemen önce GOST uyumluluk tablolarını "sonradan" doldurmak.
Sıkça Sorulan Sorular (SSS)
Yazılımın bu GOST'a göre sertifikalandırılması zorunlu mudur? Ticari ürünler için hayır, bu gönüllü bir standarttır. Ancak, sözleşmenin (özellikle devlet siparişçileriyle) bunu gerektirdiği durumlarda veya ürün teknik düzenlemelere göre zorunlu sertifikasyona tabi ise (örneğin, şifreleme araçları veya tıbbi cihazlar) zorunlu hale gelir.
Bu standart teknik şartnameyi (TS) yerine mi alıyor? Hayır, onu tamamlar. Teknik şartnamede sistemin ne yapması gerektiğini yazarsınız, GOST R ISO/IEC 25010 ise bunun ne kadar iyi yapılması gerektiğini (kabul kriterleri) tanımlamanıza yardımcı olur.
Standart Agile ekibinde nasıl uygulanır? Özellik kontrollerini Definition of Done (DoD) içine entegre edin. Örneğin, performans testi geçilene ve kod seçilen alt özelliklere göre statik analizörden geçirilene kadar görev tamamlanmış sayılmaz.
Standart legacy kodun değerlendirilmesi için kullanılabilir mi? Evet, bu eski bir sistemi denetlemek için en iyi yollardan biridir. Kodu 8 özellik üzerinden tarayarak "dar boğazları" (teknik borcu) tespit edebilir ve yeniden yapılandırma planı oluşturabilirsiniz.