Hata Yonetimi
Yazılım Mühendisliğine Hata Yönetimi, çok önemli bir konudur. Yazılım hataları, ciddi sorunlardır. Bir hatanın bulunması ve düzeltilmesi işleminin maliyeti, en pahalı yazılım geliştirme aktivitelerinden biridir. Yakın gelecekte, bu hatalar olmadan yazılım geliştirmek için bir teknik de bulanamayacak gibi gözüküyor. Hatalar önlemez olabilirler ama her ne kadar önlenemeseler de hataların sayısı ve etkileri “Hata Yönetimi” sayesinde en az seviyede tutulabilir. Bunu sağlamak için, geliştirme takımlarının hataları önlemeye, hataları olabildiğince erken yakalamaya yarayan, hataların etkisini minimuma indiren etkin bir hata yönetimi süreci belirlemeleri gerekir. Bu konuya az miktarda yapılacak olan yatırımın getirecekleri çok daha fazla olacaktır. Aşağıdaki bölümlerde, Hata Yönetimi için tutarlı bir model anlatılacaktır. Bu model, bir standard olmasa bile, Hata Yönetim Teorisi’nin ana noktalarını çok güzel açığa çıkararak bir rehber olmaktadır.
Hata yönetimi süreci genel olarak aşağıdaki prensipleri temel alır:
• Asıl hedef hataları önlemektir. Bu koşulun mümkün olmadığı veya uygulanabilir olmadığı durumlarda, hedef mümkün olduğu kadar hızlı bir şekilde hatayı bulmak ve etkisini en aza indirmek olmalıdır.
• Hata yönetimi süreci risk odaklı, risk merkezli olmalıdır. Örneğin stratejiler, öncelikler, kaynaklar, risk azaltma fikrine uygun olmalıdır.
• Hata ölçümü, süreci geliştirmek için geliştirme takımı tarafından kullanılmalıdır ve yazılım geliştirme süreci ile bütünleşik olmalıdır. Başka bir deyişle, proje takımı işini yaparken kaynaktaki sorunları da ortaya çıkarmalıdır. Bu işlem daha sonra projeyle ilgisi olmayan insanlar tarafından yapılmamalıdır.
• Bilgi yakalama ve analizi mümkün olduğu kadar çok otomatikleştirilmelidir.
• Süreci geliştirmek için, hata bilgilerinden yararlanılmalıdır.
• Hatalar genelde ksuurlu, bozuk süreçlerden kaynaklandığı için bu süreçler değiştirilmelidir.
2. HATA YÖNETİM SÜRECİ
Önceki konuda anlatılanları ve prensipleri hatırlayarak hata yönetimi için aşağıdaki şekildeki gibi bir süreç yapısı çıkarılabilir:
• Hata Önleme: Hata riskini azaltacak teknikler, metodolojiler, standard süreçler yaratma.
• Ana Raporların Temelini Oluşturma: Geliştirmeye devam edilebilecek şekilde ana raporları oluşturma. Herhangi bir ana rapor temeli hazırlanırsa, daha sonraki değişiklikleri kontrol altına almak kolaylaşır. Raporlardaki hatalar, raporun temeli detaylı şekilde oluşturulduktan sonra hata olarak kabul edilirler, daha önce hata olarak kabul edilmezler.
• Hata Bulma: Hataları, geliştirme takımını bilgilendirmek doğrultusunda tanımlama ve raporlama. Bir hata, belgelenmeden ve geliştirme takımın ilgili birimleri bilgilendirilince bulunmuş sayılmalıdır.
• Hata Çözümleme: Geliştirme takımı tarafından yapılan, bir hatanın düzeltilmesi, öncelik verilmesi, belgelenmesi işi. Bu işlem ayrıca, çözümlemenin doğru yapıldığının kontrolünü de kapsar.
• Süreç Geliştirme: İçinde hata bulunan sürecin analizi ve tanımlanması yapılmasından sonra, ileride bu ve buna benzer hataların yapılmaması için sürecin üzerinde çalışma yapılmasıdır.
• Yönetimsel Rapolama: Yönetime, risk yönetimi, proye yönetimi, süreç geliştirimi gibi konularda yardımcı olabilmek için hata bilgisinin analizi ve raporlanmasıdır.
2.1. Hata Önleme
Hiç şüphesiz, hatalar için en iyi yaklaşım onları ortadan kaldırmaktır. En çok istenen çözüm bu olsa da şu anki teknolojiyle bunu sağlamak imkansızdır. Bu yüzden geliştiricilere hataları çok çabuk bulmak ve etkilerini en aza indirgemek için stratejiler gerekmektedir. Hata yönetimi programında, hata önleme teknikleri tanımlanması ve gerçekleştiriminin önceliği yüksek olmak zorundadır.
Hata önleme, sistemdeki büyük riskleri bulmak ile başlamalıdır. Önemli risklerin tanımlanmış olması, takımın en fazla etkiyi yapacak hataların ne olduğunu görmesinde yarar sağlar. Daha sonra bu riskleri önlemek için stratejiler geliştirilebilir. Hata önlemedeki ana adımlar şu şekildedir:
• Kritik Riskleri Tanımla: Sistemin veya projenin karşı karşıya olduğu kritik riskleri tanımla. Bu riskler sistemin oluşturulmasını, dağıtımını, işleyişini engelleyen risklerdir.
• Beklenen Etkiyi Tahminle: Her kritik risk için, riskin gerçekleştiği anda oluşacak olan finansal etkiyi hesapla.
• Beklenen Etkiyi En Aza İndir: En önemli riskler belirlendikten sonra, her riski yok etmeye çalış. Yok edilemeyen riskler için, riskin problem olma ihtimalini ve etkisini en aza indirmeye çalış.
2.1.1 Kritik Riskleri Tanımla
Hata önlemedeki ilk adım, sistemin karşı karşıya kaldığı en önemli, kritik riskleri bulmak, tanımlamaktır. Bunu yapmanın en iyi yolu, en büyük tehdit olan hata tiplerini belirlemektir. Kısaca, sistemi işlemez hale getirecek hataları bulmaktır diyebiliriz. Bu riskler, projeden projeye sistem tipine, teknolojiye, yazılım kullanıcısına vs göre değişen risklerdir.
Riskler:
• Önemli bir gereksinimi atlamak
• Düzgün işlemeyen kritik bir uygulama yazılımı
• Satın alınan yazılımın düzgün çalışmaması
• Performansın kabul edilemeyecek kadar düşük olması
• Donanımın çalışmaması
• Donanım ve yazılım düzgün birleştirilememesi
• Donanımın kurulacağı alanda yeni olması
• Donanımın zamanında sağlanmaması
• Kullanıcının yeni sistemi kullanmaya istekli olmaması
• kullanıcının proje içinde aktif bir şekilde rol alamaması
• vs…
|
Bu adımın amacının her türlü riski tanımlamak değil, sadece sistemi çökertebilecek kritik riskleri tanımlamak olduğunu unutmayınız.
2.1.2 Beklenen Etkiyi Tahminle
Kritik riskler tanımlandıktan sonra, her riskin finansal etkisi tahminlenmelidir. Bu tahminleme şu şekilde yapılmaktadır: riskin bir sorun yarattığı zaman olacak (parasal) etkisi ve riskin sorun çıkarma olasılığı sayılarının çarpımı riskin beklenen etkisini verecektir.
Beklenen etki (E) bu durumda;
E = P * I olur.
P = riskin sorun olma olasılığı
I = riskin sorun olşturduğu zamanki (parasal) etkisi
|
Beklenen etkiler tahminlendikten sonra riskler, beklenen etkiye ve etkinin azaltılabilirliğine göre derecelendirilir. Bu işlemlerdeki tahmin payı büyük olsa da, doğruluğu tam olarak önemli değildir. Burada asıl önemli olan, risklerin tanımlanması ve etkisinin büyüklüğünün incelenmesidir.
Büyük, karmaşık sistemlerin birçok kritik riski olacaktır. Bu kritik risklerin olabilme olasılıklarını minimuma indirmek zor olur fakat bu işlemi yapmak projenin başarılı olma olasılığını arttıracaktır.
Kritik bir riskin problem olma olasılığı, eğer o konu hakkında belirli bilgiye sahipseniz çok düşüktür. Örneğin, önemli bir gereksinimi unutma olasılığı, eğer kullanıcılar takıma alınmadıysa yüksek olacaktır. Eğer kullanıcılar aktif olarak görev alıyorsa ve yeni sistem çok radikal değişiklikler getiren bir sistem değilse, bu olasılık düşük olacaktır.
Beklenen etkiyi tahminlemenin en etkin yöntemlerinden birisi Yıllık Kayıp Beklentisi (Annual Lost Exception, ALE) yöntemidir.
Yıllık Kayıp Beklentisi (YKB):
• Bir riskin oluşmasına “olay” denir.
• Olay başına oluşan kayıp, bir örnek olay kümesinin ortalama kaybına eşittir.
• YKB, olay sayısı ile olay başına kaybın çarpımına eşittir.
• Örneğin riskimiz yazılım sisteminin anormal bir şekilde sonlanması ise, bu sorunu düzeltmenin ortlama maliyeti hesaplanır ve bu risk ile ilgili beklenen anormal sonlanma sayısı ile çarpılır.
• Yıllık hesaplama için, olay sayısı, bir yıldaki olay sayısı olarak alınmalıdır.
|
2.1.3 Beklenen Etkiyi En Aza İndir
Beklenen etki, bir riskin sorun olmasına bağlı olduğu kadar, problemin ne kadar sürede farkedildiği ve ne kadar sürede tamir edildiğine de bağlıdır. Örnek olarak, Avrupa’daki bir telefon şirketinin kullandığı ücretlendirme sistemi, müşterileri 30 milyon dolar daha az ücretlendirmiştir. Bu durumda, kanunen 30 gün içinde şirketin doğru faturaları göndermek zorundadır. Problemin farkedilme zamanı geç olduğundan şirket tüm faturaları gönderemediği için gerçek ücretleri isteme hakkını yitirmiştir.
Beklenen etki, bir problem farkedildiğinde yapılan işlere de bağlıdır. Bir sorun farkedildiğinde eğer gerekli yerlere bunu duyurursanız, bu durumda etkisini cok daha fazla azaltmış olursunuz.
Beklenen etkiyi en aza indirmek, aşağıdaki 3 stratejinin kombinasyonunun kullanılmasıyla yapılabilir:
• Riskleri Yok Et: Bu, her zaman olası bir durum değildir ve pratikte uygulanması da çok zordur. Örneğin, bir sistemin kapsamını daraltırsanız, kendini kanıtlamamış son teknolojileri kullanmazsanız riskleri yok edebilirsiniz.
• Riskin bir Problem Oluşturma Olasılığını Azalt: Birçok strateji bu kategoriye girmektedir. Test aşaması ve incelemeler, riskleri yok etmeyen ancak olasılığını azaltan yöntemlerdir.
• Problemin Etkisini Azalt: Bazı durumlarda risk yok edilemez ve riskin oluşma ihtimali düşük olsa bile etkisi büyüktür. Bu durumlarda uygulanacak en iyi yöntem, problem oluşursa etkisinin nasıl en aza indirilebileceğinin düşünülmesidir. Beklenmeyen olay planları, felaket sonrası planları, kurtarma planları bu duruma örnek olarak verilebilir.
Dikkatli inceleyecek olursak, riski en aza indirmenin iki yolu vardır. Bunlar, Yıllık Kayıp Beklentisi formülünden elde edilir. Bu iki yöntem, olay başına düşen beklenen kaybı azaltmak ve bir olayın tekrarlanma sıklığını azaltmaktır. Eğer bu iki faktör de sıfıra indirilebilirse, risk yok edilmiş demektir. Eğer tekrarlama sıklığı azaltılırsa, riskin problem olma olasılığı azalmış demektir. Eğer olay başına kayıp azaltılırsa, problem olduğunda etki azaltılmış olur.
Çok bilinen bir mühendislik prensibi, “Eğer çok fazla bileşenden oluşan bir makineniz varsa, bileşenlerin tek başlarına sorun çıkarma ihtimali çok düşük bile olsa, makinenin sorun çıkarma olasığı yüksek olacaktır” diye öngörür. Buna göre, eğer beklenen etki en aza indirilememişse, sistem geliştirilmemelidir.
Ek - ETKİYİ EN AZA İNDİRME TEKNİKLERİ
Hataların yaratacağı etkileri en aza indirme tekniklerinin bazıları aşağıda sıralanmıştır:
• Kalite Güvence: Kullanılan süreçlerin istenilen sonuçları üretebilmesi için yeterli olup olmadıklarını kontrol amaçlı olarak, kalite güvence teknikleri tasarlanır.
• Eğitim ve Çalışma(Geliştirme Takımı İçin): İşgücü ne kadar iyi eğitilirse, işin kalitesi o kadar yüksek olacaktır. Bir çok hata, çalışanların işlerini nasıl yapacaklarını tam anlamamasından kaynaklanmaktadır. Bilgisayar teknolojisi gün geçtikçe ilerleyen bir teknolojidir. İlerideki yıllarda, gelişim sürdükçe bilgisayarlar daha karmaşık bir hal alacaktır. Bu da yazılım projelerindeki eğitimin önemini göstermektedir.
• Eğitim ve Çalışma(Müşteri İçin): Daha fazla insan bilgisayar kullandıkça, sistemin karmaşıklığı daha da büyür. Bu da kullanıcıların eğitiminin önemini artırır. Geliştirme takımı eğitiminden farklı olarak, kullanıcı eğitimlerinde, teknik bilgiye sahip olmayan kullanıcıları eğitmek için daha yaratıcı fikirlere ihtiyaç duyulur.
• Metodoloji & Standardlar: Kalite arttırımının bir yolu da varyasyonları azaltmaktır. Bu da standardlar ve metodolojilerle sağlanabilir.
• Dayanıklı Tasarım: Dayanıklı tasarımın birçok çeşidi vardır. Dayanıklı tasarımda, bir hata oluşması için, birden fazla bağımsız birimin çökmesi gerekir. Teknoloji ilerledikçe hataları engelleyen, bulan ve etkilerini en aza indiren sistemler tasarlamak da kolaylaşmaktadır.
2.2 Ana Rapor Olışturma ve Rapor Oluşturma Noktaları
Raporlar, daha önce belirlenmiş olan kilometretaşlarına gelindiğinde hazırlanırlar. Bu rapordan sonra projede geliştirme sürecinin diğer aşamasına geçilir. Proje kilometretaşlarını geçtikçe, barındırdığı hataların sistem üzerinde daha büyük bir etkisi olur ve değişiklikler yapmak için daha çok kaynak tüketilir.
Hata, projenin aşamaları bitirdikten sonra gereksinimleri karşılayamamasıdır. Bu yüzden aşamalar, hatalar için önemlidirler. Örneğin bir programcı programlama ve testden sorumlu ise, test yapılamadan diğer aşamaya geçilemeyecektir. Bu durumda, test şamasında bulınacak bir “bug” hata olarak gösterilemeyecektir. Ama test ve kodlama iki ayrı takım halinde yapılsaydı, iki ayrı aşama olacaklardı. Bu durumda bulunan “bug”, hata olarak gösterilebilecekti.
Aşamaları belirlemek iki aktiviteyi içeir:
• Anahtar Raporları Belirle: Proje gelişiminde birçok rapor oluşturulur. Bu raporlardan hangilerinin ana raporlar oldukları belirlenmelidir.
• Her Ana Rapor İçin Bir Standard Belirle: Her ana rapor için, gereksinimleri ve kriterleri belirle.
2.3 HATA BULMA
Eğer bir teknoloji, hataların oluşmayacağını garanti edemiyorsa, hatalar onarılması çok pahalıya mal olmadan bulunmalıdır. Bu modele göre, bir problem, hata bilinmeden de bulunabilir. Böyle durumlarda, problem raporlanmadan önce, hata raporlanmalıdır. Hataların çabuk bulunması önemli olduğu için, hata bulma, raporlama ile ilgili stratejiler geliştirilmelidir.
Hataları daha kolay bulabilmek için, kuruluş, hataları kategorilendirmelidir. Bu iş bir kez ya da yıllık olarak yapılan bir iştir. İşe, tüm dallardan uzmanlaşmış kişiler dahil olmalıdır. Oluşan grubun amacı, yazılım projesinde en çok oluşan hataları bulmaktır. Bulunan her hata kategorisi isimlendirilmelidir. Bunun amacı kategorilerdeki karmaşıklığı önlemektir.
Hata bulma sürecinin adımları aşağıdaki gibidir:
• Hatayı bul
• Hatayı raporla
• Hatayı doğrula
2.3.1 Hatayı Bul
Hatalar, ya daha önceden planlanmış hata bulma aktiviteleri ile (test, kalite kontrolü, inceleme) ya da kazara (kullanım sırasında) bulunur. Hata bulma teknikleri 3 sınıfta toplanır:
• Statik Teknikler: Programı veya sistemi çalıştırmadan yapılan testlerdir. Kodu gözden geçirme, statik tekniklere bir örnektir.
• Dinamik Teknikler: Hataları bulmak için sistem bileşenlerinin çalıştırılması gerekir.
• Operasyonel Teknikler: Bu durumda hatalar, sistemin yanlış çalışması sonucunda kullanıcılar yöneticiler tarafından bulunur.
• Etkili bir hata yönetimi programı için, hem statik hem dinamik tekniklere ihtiyaç duyulur. İki teknik ne kadar iyi birleştirilirse o kadar etkin bir çözüm elde edilir.
|
2.3.2 Hatayı Raporla
Hatalar bulunduktan sonra, hatalar gelişitiricilere sunulmalıdır. Bu sunum da raporlarla mümkün olur. Raporlama zaman kaybına yol açabileceği için başka hata raporlama yöntemleri de mevcuttur. Bunlar elektronik dökümanlar, elektronik formlar, e-posta, teknik servise bildirim ve benzeridir.
Sağlanan bu raporlama mekanizması sayesinde hata mümkün olduğu kadar az sürede geliştirme takımına ulaşır ve onarım başlar.
2.3.3 Hatayı Doğrula
Bir hata bulunup raporlanıp geliştiriciye getirildikten sonra, geliştirici bunun gerçekten bir hata olduğunu doğrular. Doğrulama safhasındaki gecikmeler pahalıya mal olabilir. Bu gecikmeye örnek olarak hatanın tekrar oluşmasının sağlanamaması gösterilebilir. Eğer hata tekrarlanamaz ve geliştiriye gösterilemezse, geliştirci büyük ölçüde hatayı doğrulamayacaktır ve yanlış anlama olduğu düşünülecektir. Bu noktada hatanın sebebini belirlemek çok önem kazanır.
Hata kaynağını belirleme stratejileri:
• Hatayı yakalamak için araçlar kullanmak – Microsoft DrWatson gibi
• Hatayı bulmak için ekstra kod yazmak – log tutmak için yazılan kodlar gibi.
• Raporlanmış olan hatayı analiz ermek.
2.4 Hata Çözümleme
Geliştiriciler hatayı doğruladıktan sonra, çözümleme süreci başlar. Hata çözümleme aşağıdaki şekilde olur:
• Riske Öncelik Ataması Yap
• Onarımı Planla
• Hatayı Onar
• Hatayı Raporla
2.4.1 Riske Öncelik Ataması Yap
Bu adımın amacı aşağıdaki soruları cevaplamak ve gerekli olan işlemleri başlatmaktır.
• Bulunan eski bir hata mı, yeni mi?
• Bu hatayı onarırken hangi öncelik sırası verilmelidir?
• Onarım sırasında etkiyi en aza nasıl indirebiliriz?Örneğin, kullanıclara hatadan bahsetmeli miyiz?
• Hata onarımı için ön çalışma gerekli midir?
Aşağıda, örnek bir 3 seviyeli öncelik tablosu görmektesiniz:
Kritik: Yazılımın durmasına neden olacaktır.
Büyük: Yazılımın yanlış çıktılar vermesine neden olacaktır.
Küçük: Yanlış olan modül, direk olarak sistem kullanıcısını etkilememektedir. Belgeleme hatası veya
arayüz tasarım hatası olabilir.
2.4.2 Onarımı Planla
• Hata Onarımı Planlama: Hatanın önceliğine göre, hata onarımı planı yapılmalıdır. Tüm hataların aynı hızla düzeltilmesi gerektiği düşünülmemelidir.
• Hata Onarımı: bu adım, hatayı sistemden kaldırmak için birden çok parçayı (raporlar, program…) düzeltip doğrulamayı gerektirir. Buna ek olarak, test verisi ve kontroller gözden geçirilerek gelecekteki hataların daha erken bulunması sağlanır.
2.4.3 Çözüm Raporlama
Hata onarıldıktan sonra ve onarım doğrulandıktan sonra, gerekli geliştiriciler, kullanıcılar, testçiler hatanın onarıldığı hakkında ilgilendirilmelidirler. Bu bilgilendirme aşağıdakikısımları içermelidir:
• Hatanın kaynağı
• Onarımın ne zaman yapıldığı
• Onarımın nasıl yapıldığı
Hata yönetiminin bu aşamasında, otomasyonun çok fazla yararı olabilir. Bir çok Hata Yönetimi araçları, problemi kim bulduğu, onardığı bilgilerini saklar. Bu da ilk olarak hata ile ilgili bir gelişme olduğunda kimin haberdar olması gerektiğini belirler.
Geliştirici, problemlere yol açan hatayı tanımlar ve onarır. Sonra geliştirici, hatalar ile ilgili bir çözümleme ilgisi tutar. Bu çözümleme bilgisi daha sonra ilgili gruplara geçirilir. Bu gibi durumlarda, bilgisayar formları ve e-posta hızlı bir çözüm olabilir.
2.5 Süreç Geliştirme
Bu aşama, birçok organizasyon tarafından ihmal edilmektedir ama aslında çok büyük yararı vardır. NASA, her hatanın sistemin bir zayıflığı olduğunu söylemektedir. Buna göre hatanın önemi ne olıursa olsun, sistemin zayıflığını belirttiği için aynı derecede önemlidirler. Hatanın çok büyük bir problem olmaması sadece geliştiricinin şansına bağlıdır. Bu yüzden küçük hatalar bile, süreçlerin nasıl iyilşetirileceği ve büyük problemlerin nasıl önleneceği hakkında bize bir şans vermektedir. Hata, çok büyük bir şey olmayabilir ama o hatanaın varolması büyük bir şeydir.
Çalışmalardan elde edilen sonuçlara göre, katılımcılar sürece geri dönerek hatanın nereden ve nasıl kaynaklandığını inceleyebilirler. Daha sonra, bu hatanın doğrulama sürecini nasıl geçtiğini anlayabilmek için o doğrulama sürecini inceleyebilirler. Bu incelemelerden sadece yararlı bilgiler kazanılmaz, aynı zamanda insanların işlerini daha dikkatli yapmaları da sağlanır. Bu tip çalışmaların kuruluşlara çok büyük yararları vardır.
Örneğin NASA, bu işi bir adım daha ileriye götürür ve şu soruyu sorar: Eğer bu hata projenin bu safhasına kadar farkedilmeden gelebildiyse, daha keşfedilmemiş ne gibi hatalar olabilir? Böylece proje sadece problem oluşturan hataları bulma konusunda değil aynı zamanda oluşmayan problemlerin hatalarını bulmada da güçlendirilir.
2.6 Yönetimsel Raporlama
Hata bilgisi, hata yönetimi sürecinin doğal bir çıktısıdır ve bu çıktının analiz edildikten sonra proje yönetimine ve üst yönetime iletilmesi önemlidir. Bu bilgi, hata tipleri, hata sıklıkları, hata eğilimleri, maliyetleri… şeklindedir. Projenin, gerekli rotasında ilerlemesini belrlemede, hataların ne kadar sıklıkla oluştuğunun bilinmesi yararlı olacaktır. Hata onarma etkinliği de en yararlı bilgilerden biridir. Bu bilgiler yönetime karar aşamalarında yol gösterici olabilir.
Hata yönetimi sırasında bilgi toplamanın amaçları:
• Bireysel hataları raporlamak
• Proje yönetimin daha sağlıklı ve yerinde kararlar vermesine yardım etmek için gerekli ölçümleri sağlamak.
• Üst yönetimin stratejik kararlar vermesi için bilgi sağlamak.
• Projenin geliştirilebilecek yönlerini belirlemek ve etkileri en azda tutabilmek.
Yönetime raporlar verilmesi, önemli bir adımdır ve her zaman yapılması gerekmektedir fakat yönetimi daha ileriye götürmeyecek gereksiz raporlar da verilmemelidir. Verilen raporlanrın mutlaka birer amaçları olmalıdır.
3. KAYNAKLAR
Tips for Collecting Customer Requirements, Author(s): Steve Miller
Best Pratices of Defect Prevention, Latha Rajesh
www.stickyminds.com
www.bugmonitor.com
Communicating and Managing Bugs Efficiently, Jitu Borah
http://www.defectmanagement.com/defectmanagement/
Makale:
Hata Yönetimi Süreci Yazılım Mühendisliği Tanıl Ergin
|