Kalite kavramı, doğumundan bu yana içinde bulunduğu koşullardan da etkilenerek değişik tanımlara sahip olmuştur.

 

 

Giderek artan ölçüde ilgi görmesinin (popülarite) getirdiği olumlu yönlerin yanısıra, kavramın giderek bulanıklaşma tehlikesini de gözden kaçırmamamız gerekiyor. Bu amaçla “yazılımda kalite” konusuna girmeden önce, kalite ile ilgili kavramları tekrar gözden geçirmekte fayda görüyoruz.

 

 

TS 9005’e göre kalite denince "bir ürün veya hizmetin belirlenen veya olabilecek ihtiyaçları karşılama kabiliyetine dayanan özelliklerinin toplamını”, kalite kontrol denilince “kalite isteklerini sağlamak için kullanılan uygulama teknikleri ve faaliyetlerini”, kalite güvencesi denilince “ürün veya hizmetin kalite için belirlenen istekleri karşılamak maksadıyla yeterli güveni sağlaması için gereken planlı ve sistematik faaliyetlerin bütününü”, kalite yönetimi denilince “genel yönetim fonksiyonunun kalite politikasını tesbit eden ve uygulayan bölümünü”, kalite sistemi denilince "kalite yönetiminin uygulanması için gerekli olan kuruluş yapısı, sorumluluklar, prosedürler, işlemler ve kaynakları”, kalite denetimi denilince “kalite ile ilgili faaliyetlerin ve sonuçlarının, planlanan düzenlemelere uyup uymadığının, bu düzenlemelerin etkili olarak uygulanıp uygulanmadığının ve amaca ulaşmak için uygun olup olmadığının sistematik ve tarafsız olarak incelenmesini” anlıyoruz.

 

 

TANIMLAR VE YAZILIMIN ÖNEMİ

 

ISO tanımlarına göre yazılım, bir veri işleme sistemi operasyonuna bağlı olan programlar, yordamlar ve dokümantasyonudur. Yazılım ürünü ise kullanıcıya ulaştırılmak üzere tamınlanmış bilgisayar programları kümesi, yordamları ve dokümanlarıdır.

 

İşletme yazılımları diye tabir edebileceğimiz yazılımlar genelde 3 temel gruba ayrılır. 1000 $’lar civarında maliyete sahip olan en alt kategoride küçük çaplı kullanıcıların gereksinimlerini karşılayan, çok fazla destek istemeyen, kullanımı kolay yazılımları sayabiliriz. 100.000$’lar civarında maliyete sahip olan orta kategoride kullanıcı sayısı 50’lere varmaktadır. En son kategoride ise milyon $ civarında maliyete ve yüzlerce kullanıcıya sahip olan yazılımlar vardır. Bunların içinde en hızlı gelişme sırası en alt kategoriden, üst kategoriye doğru bir sıra izlemektedir. Öte yandan ofis (workgroup) yazılımları, kişisel (eğitim, oyun vb.), endüstriyel ve finansal fonksiyonlara odaklanmış yazılımlar (cad, cam, cae, istatistik, bankalar), yüksek teknoloji yazılımları (telekom, uydu, füze, nükleer santraller vb.) gibi çeşitli sınıflandırmalar da yapılabilir.

 

Yazılım, içinde yaşadığımız “bilgi toplumu” çağının en önemli mekanizması olmak yolundadır. Ülkemizde kamu ve özel sektöre ait her boyuttaki yazılım çalışmalarının yanısıra, toplumsal boyuta sahip bilişim projelerinden MERNİS (Nüfus ve Vatandaşlık İşleri Genel Müdürlüğü), BDE (Milli Eğitim Bakanlığı Temel Eğitim Projesi), VEDOP (vergi Dairelerinin Otomasyonu Projesi), Sağlık Enformasyon Sistemi (Sağlık Bakanlığı) gibi projeler, konunun önemini anlamak için yeterlidir.

 

 

 

YAZILIM VE KALİTE

 

Tekrar kalite kavramına geri dönersek, kalite olgusunun üretim alanında, bitmiş ürünün kontrolundan, giderek üretim aşamasına ve tasarımına doğru ilerlerken, hizmet alanına da bir çok cepheden girdiğini görürüz. Durum böyle iken, bünyesinde ürün olma özelliklerini, süreç olma özelliklerini ve ayrıca yaratım aşamasında birbirinden farklı bir çok disiplini (teknoloji yönetimi, proje yönetimi, süreç yönetimi, kalite yönetimi, insan kaynakları yönetimi vb.) kullanan yazılım sektöründe de kalite arayışlarının olmaması mümkün değildir.

 

 

 

Geçmiş dönemlerde bir ürünün son (final) kontrolunda aldığı onay, onun kalitesini belirlerken, yazılımın kod satırlarında program geliştiriciye yönelik olarak yer alan ve “*rem” diye anılan program açıklamalarının varlığı da yazılımın kaliteli olduğunun belirtisiydi. Ardından yazılımın bitiminde uygulanan inceleme (review), teftiş (inspection), gözlem (walkthrough), denetim (audit) diye tanımlanan değişik kalite çalışmaları geldi. Bugün ise yazılım sektörü, yazılımın her aşamasında kalite olgusunu tam anlamıyla gerçekleştirebilmek için değişik modelleri, metodolojileri, resmi ve gayri resmi standartları kullanmaya çalışıyor, bunların dünya çapında kullanılır olması için çaba veriyor.

 

 

 

ÜRÜN OLARAK YAZILIM

 

Yazılımın ürün olma özelliği açısından –yazılım sınıflandırmalarından bağımsız olarak- kalitesini belirleyen temel özellikleri aşağıdaki gibi sayabiliriz:

 

.doğruluk

 

.bütünlük

 

.kullanım kolaylığı (kullanılabilirlik)

 

.çok amaçlı kullanılabilirlik (değişik ortamlarda kullanılabilirlik)

 

.tekrar kullanılabilirlik (reuse)

 

.test edilebilirlik

 

.kapasite

 

.performans

 

.performansın kontrolu (kaynakların etkili kullanımı)

 

.işletim sürekliliği

 

.güvenilirlik

 

.korunabilirlik

 

.düzenlenebilirlik (esneklik),

 

.belgeleme

 

.hazır bulunabilirlik

 

.bakım kolaylığı

 

.transfer kolaylığı

 

.geliştirme kolaylığı

 

.sorgulama yetenekleri

 

.raporlama yetenekleri

 

.grafik yetenekleri

 

.veri alma-veri aktarma yetenekleri

 

.müşteri tatmini

 

Yukarıda sayılan özelliklerden performans ve kapasitenin çakışmamasına dikkat edilmelidir. Tekrar kullanılabilirlik (reuse) ise üzerinde dikkatle durulması gereken bir konudur. Tekrar kullanım sadece kodun tekrar kullanımını değil, tasarımın, test ortamının, dokümanların ve benzeri bilgilerin kullanımını kapsamaktadır. Yazılım, esnek bir ürün olma özelliği kullanılarak, önceden belli bir disiplin ile üretilirse, bir formdan diğerine geçebilir. Bir başka deyişle yeniden kullanılabilirlik özelliği ile önceden belli bir gereksinime göre üretilmiş olan bir yazılım, farklı bir gereksinime göre yeniden düzenlenebilir. Diğer bir önemli konu ise; her sektörde tüm ürünlerin ortak sorunu olan “müşteri tatmini nedir, nasıldır?” sorusunu da gerçekçi bir şekilde çözebilmek gerekmektedir. Oldukça soyut ve değişken bir olgu olan “müşteri tatmini” konusunda ilerleme sağlamanın ön koşulu, müşteriyi yazılım ve kalite unsurları hakkında –üründen bağımsız olarak- bilgilendirmektir.

 

Sonuçta yukarıda sayılan özelliklerin tümü, yazılımın bir ürün olarak (süreç değil!) giriş (input), işlem (proces), çıkış (output) ve çıktıların çıkış kurallarına uygunluğunu kontrol eden kalite kontrol kriterlerine uyumunu sağlarlar.

 

Ancak yazılımlar, türlerine göre sınıflandırıldıklarında yukarıda sayılan genel özellikler daha detaylı özelliklere dönüşmektedirler. Örneğin iletişim ve eşgüdüm odaklı “groupware” çalışmalarında yazılımın dış ortamlarla entegrasyonu, platform bağımsız çalışabilme özelliklerini desteklemesi önemli kalite kriterleridir. Bir başka örnek olarak, yüksek teknoloji alanında (nükleer santral, uydu vb.) çalıştırılan yazılımlardaki “aksaklığa dayanıklılık” özelliklerini verebiliriz. Çeşitli denetim metodlarıyla hata bulma, giderek hatayı sınırlama, ileriye ve geriye dönük olarak hatayı kurtarma, aksaklığı giderme vb. özellikler, ilgili yazılımın kalite göstergeleridir. Yine bir başka örnek olarak, akıllı yazılımları verebiliriz. Bu tür yazılımlardaki, kullanıcı denetimi altında olmadan çalışabilme, başka sistemler ve kullanıcılarla diyalog kurabilme, dış ortam değişikliklerine tepki verebilme, işin o durumda en iyi nasıl yapılacağına karar verebilme, “on line” ya da “off line” çalışabilme vb. özellikleri ise yazılımın türüne bağlı olan farklı kalite göstergeleridir. Uygulama yazılımlarında ise genellikle, “açık sistem” anlayışına uygun olarak üretilmiş yazılımlar, önemli kalite kriterlerini yerine getirmiş sayılmaktadırlar. Bu tür yazılımların özellikleri, en az değişiklikle taşınabilirlik, verilerin paylaşılabilmesi ve kullanım kolaylığı amaçlı, açık destek yeteneklerine sahip olmalarıdır.

 

Öte yandan tüm bu yazılımlarda ortak özellik olarak bulunması gereken ve yazılımın kullanıcı ile ilişkiye girdiği nokta olan “kullanıcı (grafik) ara yüzleri”ndeki kalite kriterlerine de göz atmak gerekmektedir. Aşağıda bunlardan bazıları başlıklar halinde sayılmıştır:

 

.komut satırı, menü ve sembolik erişim tuşları

 

.koşullu sorgulama,çoklu seçim, arama, değiştirme özellikleri

 

.takvim ve tarih bilgileri

 

.standart ekran ve rapor düzeni

 

.rapor, liste oluşturma yeteneği

 

.detaylı bilgiye ulaşım (drill down)

 

.kodlu bilgi (combo box)

 

.kaydırma çubuğu (scroll bar)

 

.sıralama (sorting)

 

.on line help, kılavuzluk

 

.onay kutusu (check box)

 

.seçim kümesi (radio group)

 

.hata ve sesli ileti yönetimi (dialog window)

 

.öndeğer kullanımı (default value)

 

.çoklu pencere

 

.işlem durumu (kum saati)

 

.çok satırlı alanlar

 

.alanlarda renk ve biçim (format) kullanımı

 

.minimum hareket, öğretim ve anımsama yükü

 

.maksimum yardım ve bilgilendirme

 

.dilin anlaşılabilirliği ve tutarlılığı

 

.ergonomik kullanım ve estetik görünüm

 

.hatayı uyarma ve önleyebilme, hataya dayanma

 

.veri ve erişim güvenliği

 

.farklı sistemlere ve yeni kullanıcı isteklerine uyarlanabilme

 

.hafıza (öğrenebilme yeteneği)

 

.bakıma elverişlilik

 

 

 

SÜREÇ OLARAK YAZILIM

 

Yazılımın ürün olma özelliği açısından, gereksinim duyduğu kalite kriterleri hakkında bilgi verdikten sonra sıra, yazılımı bir süreç olarak değerlendirmeye geliyor. Artık yazılımda kalite kriterlerini, yazılım süreçleri içerisinde arıyoruz.

 

Kalitenin uygulanabilir olduğu yazılım geliştirme süreçleri hakkında, değişik görüşler vardır. Bir görüşe göre iki aşamalı bir süreç tanımı yeterlidir:

 

Geliştirme (analiz/tasarım/program/test) ile geçiş ve sonrası (geçiş/işletim/bakım) süreçleri. Öte yandan daha detaylandırılmış süreçler de söz konusu olabilir: İhtiyaç analizi, sistem tasarımı, kodlama, test ve bakım süreçleri gibi. Ya da hedeflenen ürünün tanımı, yöntem geliştirme, uygun teknoloji araştırması ve seçimi, analiz, görsel tasarım, teknik tasarım, geliştirme, iç testler, dış testler ve pilot proje süreçleri sayılabilir. Proje yönetimi açısından ele alındığında bunlara maliyet tahmini, risk analizi, kaynak ayırma ve koordinasyon, süreç planlaması ve zamanlama süreçleri de eklenebilir.

 

Yazılımı, süreç olma özelliği içerisinde etkileyen en önemli kriterlerden birisi, onun entellektüel bir ürün olmasından ileri gelir. Onun bu özelliği, kullanıcıya yansıyan üst yapı (görsel ara yüz) ile performans ve programcıya yansıyan alt yapıyı etkileyebilecek güçtedir. Dolayısı ile yazılım geliştiren şirketlerde insan kaynakları politikasının sürekli eğitim, iş tatmini vb. unsurlarla beraber dikkatle planlanması ve yürütülmesi gerekmektedir.

 

Resmi ve gayri resmi standartlara (modeller) girmeden önce yazılım süreçlerinde kalitenin nasıl sağlanması gerektiği hakkındaki genel düşünceleri toparlarsak;

 

.Kalite güvence, organizasyona bir fonksiyon olarak yerleştirilir (kalite güvence grubu belirlenir, kaliteyle ilgili politika ve prosedürler saptanır, kalite güvence yönetimi seçilir, kalite kontrol sonuçları toplanır ve değerlendirilir, kalite kontrol sonuçlarına göre iyileştirme çalışmaları yapılır, iyileştirme sonuçlarına göre standartlar revize edilir)

 

.Yazılım çevrim süresi azaltılır (müşteri gereksinimleri önceden ve somut bir şekilde tesbit edilir, tekrar kullanım artırılır, değişiklik yapmak azaltılır, süreçler iyileştirilir-basitleştirilir, çalışma ortamı ve ergonomide iyileştirmeler sağlanır, iş için en iyi personel kullanılır, sorunlara proaktif bir şekilde yaklaşılır, standartlar

 

kullanılır, kod ve algoritma karmaşıklığı engellenir)

 

.Yazılımlarda sık kullanılan ve standart (popüler) fonksiyonlar kullanılır, bilgi, uyarı ve hata iletişimi, güvenlik (yetki), performans, diğer platformlarla ilişki kurabilme ve uyarlanabilme yeteneği (customizing) için uygun alt yapı oluşturulur.

 

 

 

SÜREÇ MODELLERİ

 

Yazılım geliştirmede uygulanan çeşitli süreç modelleri vardır. Karmaşık yazılım sistemleri için zaman kontrollu bir model olarak “Şelale” modeli kullanılmaktadır. “Şelale” modeline alternatif olarak ise Evolutionary Delivery (Tom Gilb) modeli önerilmiştir. Bu modelde ürün teslimi, katma değerin ölçümlenmesi, hedef ve tasarımın güncellenmesi aşamaları (3 aşamada) uygulanmaktadır. Risk yönetimi ve prototiplemenin kullanılabileceği Spiral modelde (Boehm) ise hedef ve alternatif belirleme, alternatifleri ve riskleri değerlendirme, bir sonraki seviye ürününün tasarlanması ve bu adımların tekrarlanması aşamaları (4 aşamada) kullanılır. Rapid Application Development-RAD (James Martin) çevrim süresini azaltmak; hızlı ön modelleme, tekrar kullanım, kalitenin iyileştirilmesi gibi daha detaylı teknikler kullanan Rapid Evolutionary Development ise proje takımının üretkenliğini artırmak amacıyla geliştirilmiştir. Yine çevrim süresini azaltmak amacıyla Concurrent-Development Process Model (Fujitsu) geliştirilmiştir.

 

Microsoft, Şelale ve Spiral modellerinin avantajlarını kendisine uyarlayarak “kilometre taşı bazlı geliştirme” modelini kullanmıştır. IBM kaynaklı Cleanroom metodolojisi ise, yazılım geliştirmeye matematiksel temelli mühendislik işlemleri olarak yaklaşarak, test aşamasında hataları düzeltmekten ziyade, yazılım aşamasında hataları önlemeye odaklanmıştır. Nesne yaklaşımlı (object oriented) metodolojilerin yanısıra işlem yaklaşımlı (process oriented) bir metodoloji olan

 

Yourdon/De Marco metodunda her süreç için dış dünya ile olan ilişkileri gösteren içerik diyagramları (context diagrams) hazırlanır. İçerik diyagramlarının açılmasından sonra üçüncü dereceye kadar süreç diyagramları (data flow diagrams) çizilir.

 

 

 

OLGUNLUK VE YETENEK MODELLERİ

 

 

 

TRILLIUM

 

Teknolojik olgunluk içeren ve iyileşmeyi bu olgunlukla düzenleyen yol haritası (road-map) yaklaşımını getiren Trillium modeli, Kanada telekom sektörü tarafından geliştirilmiştir. Yol haritası kavramı, ürün geliştirme süreci içerisinde bir organizasyon alanı, ihtiyacı ya da öğesine odaklanan ilgili uygulamalar seti olarak tanımlanabilir.

 

 

 

Trillium 5 seviye sunar:

 

1.Başarının sadece bireylere bağlı ve riskin yüksek olduğu “yapılanmamış” seviye (unstructured).

 

2.Başarının iyi bir proje yönetimi ile ancak sağlanabildiği “tekrarlanabilen ve proje yönelimli" seviye (repeatable and project oriented).

 

3.Tanımlı süreçlerin değerlendirilebildiği “tanımlı ve süreç yönetimli” seviye (defined and process oriented).

 

4.Süreç değişim yönetiminin uygulanabildiği “yönetilen ve bütünleşik” seviye (managed and integrated).

 

5.Metodolojilerin yaygın olarak kullanıldığı ve riskin düşük olduğu “tam bütünleşik” seviye (fully integrated).

 

 

 

Trillium 8 yetenek alanından oluşur:

 

1.Organizasyon süreç kalitesi

 

2.İnsan kaynakları geliştirme ve yönetimi

 

3.Süreç

 

4.Yönetim

 

5.Kalite

 

6.Sistem geliştirme uygulamaları

 

7.Geliştirme ortamı

 

8.Müşteri desteği

 

 

 

CMM (Capability Maturity Model)

 

Olgunluk anketini (maturity questionnaire) kullanarak yazılım sürecini değerlendiren CMM, Amerikan Savunma Bakanlığı’nın 1970-80’lerde yaşanan yazılım krizine çözüm bulması amacıyla Carnegie Mellon Üniversitesi’nden yardım istemesi üzerine, üniversite bünyesinde kurulan Yazılım Mühendisliği Enstitüsü (Software Engineering Institute-SEI) tarafından geliştirildi. Genellikle büyük boyutlu firmalara hitap eden CMM’de, hem dışa karşı belgelendirme, hem de iç süreçlerin detaylı bir şekilde değerlendirilmesi söz konusudur.

 

 

 

CMM 5 seviye (1-5 arası) sunar. Parantez içerisinde her seviyeye ait anahtar süreç alanları verilmiştir:

 

1.Başarının sadece bireylere bağlı olduğu “başlangıç” seviyesi (initial).

 

2.Yazılı olmayan ve kısmen tutarlı süreçlerin olduğu “tekrarlanabilir” seviye (repeatable-isterler yönetimi, proje planlaması, proje takibi, taşeron yönetimi, kalite güvencesi, konfigürasyon yönetimi).

 

3.Şirket kültürünün yazılı hale geldiği “tanımlı” seviye (defined-süreç odaklaması,

 

süreç tanımı, eğitim programı, bütünleşik yazılım yönetimi, yazılım ürün mühendisliği, gruplararası koordinasyon, ayrıntılı değerlendirme)

 

4.Tanımlı hale gelen süreçlerin artık ölçülebildiği, performans göstergelerinin değerlendirilebildiği “yönetilen” seviye (managed-nicel süreç yönetimi,

 

yazılım kalite yönetimi)

 

5.Kurumsallaşmanın gerçekleşip, geri beslemelerin sistematik bir şekilde değerlendirilmeye başlandığı “en iyilenen” seviye (optimizing-hata önleme

 

teknoloji değişim yönetimi, süreç değişim yönetimi)

 

CMM uygulaması için hiyerarşik olarak, seviye belirleme, bir sonraki seviyeye geçmeden önce eksiklikleri belirleme, eksiklikleri hiyerarşik sıraya dizme, eksikliklerin giderilmesi için plan yapma, planı hayata geçirmek için kaynak ayırma ve uygulama, döngüye yeni baştan başlama aşamaları uygulanır.

 

 

 

CMM değerlendirme süreci 6 aşamadan oluşur:

 

1.Kurumun şeçildiği “seçim” aşaması.

 

2.Değerlendirme sürecinin onaylandığı “taahhüt” aşaması.

 

3.Değerlendirme grubunun eğitildiği “hazırlık” aşaması.

 

4.Uygulamalanın değerlendirildiği “değerlendirme” aşaması.

 

5.Değerlendirmenin raporlandığı “rapor” aşaması.

 

6.Değerlendirme izlendiği “takip” aşaması.

 

 

 

ISO 9000

 

International Standards Organization tarafından 1987 yılında yayınlanan, ISO 9000 serisi Kalite Sistemi ve Güvencesi Standartları özellikle Avrupa’da büyük ilgi gördü. ISO 9000 kalite yönetimi ve kalite güvencesi için, ISO 9000-3 yazılımda kalite sistemi denetleyicileri ve uygulayıcılarına rehberlik için bir standarttır. Yazılımda kalite için ISO 9001 ön görülebilir. Ancak bu standartlar bir süreç modelinden farklı olarak, dışarıya kalite güvencesi vermeye yönelik belgelendirmeye önem verirler. Denetim mekanizmasına gereksinim duyan bu standartlar, şirket seviyesi hakkında detay değil, genel bir bilgi verirler.

 

Kalite değerlendirme uygulaması için hiyerarşik olarak, belgelendirilecek kurumunun seçilmesi, ön değerlendirme aktiviteleri, değerlendirme süreci,sürekli gözaltı aktiviteleri, yeniden değerlendirme aşamaları uygulanır.

 

 

 

TICKIT

 

ISO 9001’in karşılaştığı bir takım güçlükler nedeniyle ISO 9000-3 çıkarılmış, onun da yetersiz kalması üzerine İngiltere kaynaklı TICKIT modeli ortaya çıkarılmıştır. TICKIT, değerlendirdiği kalite sisteminde ISO 9001 standardına göre uyumsuzluk olup olmadığını araştırır.

 

SPICE (Software Process Improvement and Capability Determination ISO 15504)

 

ISO/IEC, yazılım sürecinin iyileştirilmesi ve yetenek düzeyinin belirlenmesi amacıyla 1993’ten bu yana SPICE adı altında standartlar geliştirmektedir. Her boyutta firmaya hitap eden SPICE, ISO’daki genellemelerin aksine detay bilgi verir.

 

SPICE süreç değerlendirmesi, kendi kendine değerlendirme ile (organizasyon içerisinden), grup tabanlı değerlendirme ile (organizasyon içerisinden bir grup), sürekli değerlendirme ile (otomasyona girmiş bir veri toplama süreci ile) ya da bağımsız değerlendirme ile (organizasyondan bağımsız uzman tarafından) yapılabilir.

 

 

 

İki boyuttan (yazılım süreçleri ve yetenek düzeyleri) oluşan SPICE’a göre, birinci boyutu (yazılım süreçleri) oluşturan kategoriler 5 sınıfa ayrılır:

 

1.Müşteri-satıcıya direkt etkisi olan süreçler

 

2.Mühendislik süreçleri

 

3.Projeyi oluşturan ve yöneten süreçler (yönetim)

 

4.Destek süreçleri

 

5.Organizasyon süreçleri

 

 

 

İkinci boyut olan yetenek boyutunda ise 6 yetenek seviyesi (0-5 arası) vardır:

 

0.Başarının sadece bireylere bağlı olduğu “eksik” seviye (incomplete).

 

1.Planlama yapılmadan, süreçlerin genel olarak yerine getirildiği “var olan” seviye (performed).

 

2.Süreçlerin tanımlandığı, iş planının uygulandığı “yönetilen” seviye (managed).

 

3.Organizasyonda belgelendirilmiş standart süreçler ve uygulamaların olduğu

 

“yerleşmiş” seviye (established).

 

4.Denetim altındaki süreçte detaylı performans ölçümleri toplanabildiği “kestirilebilir” seviye (predictable)

 

5.Geribeslemelerle sürekli iyileştirilen “en iyilenen” seviye (optimizing)

 

 

 

Türkiye’de ise, yazılım kalitesi hakkında ve kurumsal çapta; KALDER “Yazılımda Kalite Uzmanlık Grubu” ve sponsoru bulunduğu Türkiye-SPIN’in (Yazılım Süreç İyileştirme Ağı, Software Process Improvement Network -Türkiye) ve TÜBİTAK-MAM Bilişim Teknolojileri Araştırma Enstitüsü’nün (BTAE) Yazılım Sistemleri Grubu içinde faaliyet gösteren Yazılım Kalite Merkezi’nin (YKM) kayda değer çalışmaları bulunmaktadır.

 

 

 

Yararlanılan kaynaklar:

 

1.Jenner, Software Quality Management and Iso 9001, John Wiley and Sons, 1995

 

2.IBM Systems Journal, Vol 33, No:1, 1994, Software Quality

 

3.ISO/IEC TR15504:1998(E) International Standart Organization, 1998

 

4.www.sei.cmu.edu

 

5.www.swebok.org

 

6.Bu yazıda ayrıca, KALDER’den Sn. Seçkin İkiz’in, TÜBİTAK’tan Sn. Funda Bağcıoğulları’nın ve Sn. Elif Demirörs’ün verdiği değerli bilgilerden yararlanılmıştır.  

 

 

 

 

Memet Özkan 

 

 

 

 

Yazarın notu: Bu yazı, Computer Life dergisinin 11 Haziran 2001 tarihli, 53. sayısında yayınlanmıştır.

occonsbanner06