Çip tasarımı ve elektronik sistem tasarımı ekipleri, testlerin sayısını artırmanın veya regresyon süreçlerini otomatikleştirmenin ötesine geçen bir sorunla karşı karşıya. Ürünlerin yazılıma daha fazla dayanan mimarilere yönelmesi ve donanım, yazılım ve alt sistem bileşenlerinin entegre edilmesiyle doğrulama kanıtları farklı araçlara, ekiplere ve aşamalara dağılıyor; bu sırada gereksinimler ve ayarlar değişiyor, fikrî mülkiyet ise yeni bağlamlarda yeniden kullanılıyor.
Bu bağlamda Jake Wiltgen ve Mike Andrews, temel zorluğun daha fazla kayıt üretmek değil, yaşam döngüsü boyunca anlamı ve bağlantıyı korumak olduğunu belirtiyor. Sponsor Blog formatında yayımlanan makale, «doğrulama ipliği» kavramını gereksinimler, standartlar, doğrulama faaliyetleri, ayarlar ve sonuçlar arasında yapılandırılmış bir dijital bağlantı olarak sunuyor.
Sorun veri eksikliği değil
Doğrulama ortamları hâlihazırda kayıtlar, dalga biçimleri, sinyaller, onaylar, kapsam ölçümleri ve başarılı ya da başarısız sonuçlar üretiyor. Ancak başarılı bir test sonucu tek başına hangi gereksinimi ele aldığını, kullanılan tasarım sürümünü, test ortamını ve ayarları ya da senaryoya yön veren varsayımları açıklamıyor.
Aynı durum kapsam sayıları için de geçerli. Bunlar bir faaliyete veya ilerlemeye işaret ediyor, ancak tek başlarına doğrulamanın yeterli olduğunu kanıtlamıyor. Gereksinimler veya ayarlar değiştiğinde ekipler, etkilenen testleri ve önceki sonuçların hâlâ geçerli olup olmadığını belirlemek için bağlamı manuel olarak yeniden oluşturmak zorunda kalıyor.
Doğrulama ipliği ne ekliyor?
Yazarlar, her doğrulama olayının yalnızca bir regresyon raporundaki satır olarak değil, yeniden kullanılabilir bir mühendislik kanıtı olarak ele alınmasını öneriyor. Buna faaliyetin gereksinim veya mühendislik amacıyla ilişkilendirilmesi, standartların, tasarım sürümünün, yürütme ortamının, tetikleyicilerin, kısıtların ve ilişkili kanıtların kaydedilmesi dâhil.
Bu bağlantı, ekiplerin «testi gerçekleştirdik» ifadesinden daha belirli bir yanıta geçmesini sağlıyor: Gereksinim nasıl, hangi koşullar altında ve hangi kanıtlarla doğrulandı; geriye hangi boşluklar kaldı? Ayrıca birimler yeniden kullanıldığında veya türetilmiş tasarımlar geliştirildiğinde önceki sonuçların geçerliliğini değerlendirmeye yardımcı oluyor; böylece iş rastgele tekrarlanmıyor veya analiz yapılmadan dışlanmıyor.
Araç entegrasyonundan anlamın birleştirilmesine
Makale, uygulamaları birbirine bağlamanın veya dosya alışverişi yapmanın gerçek bir doğrulama ipliği oluşturmak için yeterli olmadığını vurguluyor. Donanım doğrulama, yazılım doğrulama, sistem testleri, güvenlik analizleri ve gereksinim yönetimi farklı soyutlamalar ve başarı ölçütleri kullanıyor.
Bu nedenle önerilen model, farklı ortamlarda ortaya çıktıklarında bile gereksinimleri, standartları, ayarları ve kanıt nesnelerini birbirine bağlayan ortak anlamlara ihtiyaç duyuyor. Sonuç, eksik, yinelenen veya güncelliğini yitirmiş kanıtların belirlenebildiği ve bir gereksinimdeki değişikliğin ilgili testler ve sonuçlar üzerindeki etkisinin izlenebildiği bir mühendislik bilgi ağına benziyor.
Bu haber neden önemli?
Yaklaşımın önemi, doğrulamayı sonradan gerçekleştirilen bir belgeleme aşaması olarak değil, sürekli bir mühendislik mimarisi meselesi olarak yeniden tanımlamasında yatıyor. Farklı ekipler, tedarikçiler ve coğrafi konumlar arasında dağıtılan geliştirme, örtük bilgiye olan bağımlılığı azaltıyor; ayrıca onay aşamalarında gecikmenin ve belirsizliğin artan maliyeti, kanıtların eksiksiz ve savunulabilir olmasını daha önemli hâle getiriyor.
Ancak makale açık bir sınırlama getiriyor: Hiçbir araç veya dijital iplik, belirsiz gereksinimleri, tanımlanmamış ölçütleri ya da tutarsız biçimde kaydedilmiş kanıtları çözüme kavuşturamaz. Yaklaşımın başarılı olması için gereksinimlerin doğrulanabilir beklentilere ayrıştırılması, ölçütlerin açık hâle getirilmesi ve doğrulama olaylarının yapılandırılmış bir biçimde kaydedilmesi gerekiyor.
Sunulan gerçeklere dayanıldığında, temel pratik değer yeni bir gösterge paneli eklemekte değil, doğrulama sonuçlarını anlaşılabilir, yeniden kullanılabilir ve etki analizi yapılabilir hâle getirmekte. Questa One VeriThreader çözümüne ve «Rethinking Traceability for Modern Systems» başlıklı teknik incelemeye yapılan atıf ise tanıtım metninin sonunda yer alıyor ve ürünü değerlendirmek veya diğer alternatiflerle karşılaştırmak için yeterli bağımsız ayrıntı içermiyor.