Software Process Maturity & QA Attributes

Capability Maturity Model

İlk tanımlaması 1987 yılında Watts Humphrey tarafından yapılmıştır. CMMI, bir süreç modeli olup, örgütlerin yazılım süreçlerinin (Yazılım planlama, geliştirme, yapılandırma vb.) olgunluğunu değerlendirme modelidir.

Genel Fikirleri:

  • Efektif yazılım sürecinin anahtar elemanlarını tanımlar.
  • Olgunlaşmamış bir süreçten olgunlaşma sürecine geçiş evresini açıklar.
  • CMM, beş olgunluk düzeyinden oluşur; ancak ilk seviyede (Level 1) key process areas (KPA) dan oluşur. Her bir KPA, temel uygulamaları belirten ortak özellikler adı verilen beş bölüm halinde düzenlenmiştir. Anahtar uygulamalar, toplu olarak alındığında verilen KPA’nın hedeflerine ulaşır.
  • Bir kuruluş, KPA’ları destekleyen temel uygulamaların varlığına göre derecelendirilir.

SE Division of Hughes Aircraft şirketi üç yıllık periyotta CMM seviyesini level 3’e getirmek için 500k $ para harcadı. Ancak level 3 seviyesine geldikten sonra 2m $ para tasarruf etmiş oldu.

CMMI Maturity Levels

Level 1 – Initial / En Düşük Kalite- En Yüksek Risk
Level 2 – Managed / Düşük Kalite- Ortalama Risk
Level 3 – Defined / Ortalama Kalite- Ortalama Risk
Level 4 – Quantitatively Managed / Yüksek Kalite- Düşük Risk
Level 5 – Optimizing / En Yüksek Kalite/ En Düşük Risk

Maturity Level 1: Initial

Bu seviyede süreçler oldukça ad hoc ve kaotiktir. Bu seviyedeki şirketler ürünlerinde stabil bir çevre sağlayamazlar. Bu tip şirketlerde ürünlerin başarılı olabilmesi genellikle bazı insanların kahramanlıklarına (?) bağlıdır.
Bu seviyede ürünler ve servisler sık sık çalışır ancak, bütçe yönetimi oldukça kötüdür.
Şirketlerin kriz anındaki yönetimlerinde aşırı bağlılık veya kriz anında projeleri bırakma, daha önceden başarılı oldukları şeyleri tekrarlayamama gibi sorunları mevcuttur.

Maturity Level 2: Managed

2. seviyedeki şirketler spesifik ve genel amaçlarını başarmıştır. Yani, projenin gereksinimleri planlı, performanslı, hesaplı bir şekilde yönetilmiştir. Bu seviyede, kriz anında mevcut olan uygulamaların korunmasını sağlamaya yardımcı olur. Bu uygulamalar, yapıldığında, projeler belgelendirilmiş planlarına göre gerçekleştirilir ve yönetilir.

Ek özellikleri:

  • Project Planning
  • Project Monitoring and Control
  • Tedarikçi Sözleşme Yönetimi (Supplier Agreement Management)
  • Ölçüm ve Analiz (Measurement and Analysis)
  • Süreç ve Ürün Kalite Güvencesi (Process and Product Quality Assurance)
  • Konfigürasyon Yönetimi (Configuration Management)

Maturity Level 3: Defined

Bu seviyede 2. seviyeden farklı olarak level 3’de standartların kapsamı, prosedürler, metotlar ve araçlar açıklanır. Aralarındaki en önemli fark ise bu süreçte süreçler oldukça detaylı bir şekilde açıklanır. Bu da sürecin anlaşılabilirliğini arttırdığı için müşteri ile ilişkiler konusunda yardımcı olur.

Gereksinim Geliştirme (Requirement Development)
Teknik Çözüm (Technical Solution)
Ürün Entegrasyonu (Product Integration)
Verification
Validation
Organizasyonel Süreç Odağı
Organizasyonel Süreç Tanımı
Organizasyonel Eğitim
Entegre Proje Yönetimi
Risk Yönetimi
Karar Analizi ve Çözümü

Maturity Level 4: Quantitatively Managed

Bu seviyede total sürece yardımcı olarak alt süreçler üretilir. Bu alt süreçler istatistikler ve diğer teknikler kullanılarak seçilir.
Süreç performansı ve kalite için nicel hedefler (quantitative objectives) üretilir. Bu hedefler müşterinin, kullanıcıların üzerine yoğunlaşır. Kalite ve süreç performansı istatistiksel olarak yönetilir.
Bu seviyenin diğer seviyelerden farkı ise tahmin edilebilir süreç performansıdır. Seviye 4’de süreç istatiksel ve nicel bir şekilde yönetildiği için performans oldukça tahmin edilebilirdir.

Maturity Level 5: Optimizing

Bu seviyede seviye 4’deki quantitative (nicel) kısım daha geliştirilmiştir. Bu seviyede, süreç performansı inovatif teknik geliştirmeler ile geliştirilir.
Level 4 ile 5 arasındaki en kritik fark ise, bu seviyede süreçler seviye 4’deki gibi nicel hedefler ile birlikte tahmini edilebilir olmasına rağmen ek olarak değiştirilmeye müsaittir (flexible).

Software Quality Attributes

Bu yazımda bazı kelimeleri İngilizce halleri ile bıraktım çünkü çevrilmeye gerek olmadığını, neredeyse herkesin bu kelimeleri bildiğini düşünüyorum.

  1. Safety-Security
  2. Reliability(Güvenilirlik)
  3. Resilience(Direnç)
  4. Robustness(Sağlamlık)
  5. Portability
  6. Understandability
  7. Adaptability
  8. Modularity
  9. Complexity
  10. Usability
  11. Efficiency
  12. Learnabilty

İlk yazımda yazılım kalitesinin belirli standartlarının olduğundan bahsetmiştim. Ancak bu standartların nasıl belirlendiği hakkında bilgi vermemiştim.
SQA planlarında kullanılan organizasyonlar:

  • ISO 9000-3
  • ANSI/IEEE standards

SQA Aktiviteleri

Analistin yüksek kaliteli bir spesifikasyon ve yüksek kaliteli bir tasarım elde etmesine yardımcı olmak için teknik yöntemleri uygulanır.

Teknik personel tarafından yalnızca kalite sorunlarını ortaya çıkarmak amacıyla gerçekleştirilen stilize bir toplantı yapılır.

Etkili hata tespiti sağlamaya yardımcı olan bir dizi test senaryosu tasarım yöntemi ile birlikte yazılım testi yapılır.

Standartlar uygulanır.

Yazılım geliştirme ve bakım sırasında değişikliklere uygun olup olmaması kontrol edilir.

Yazılım kalitesini izler ve yazılım kalitesini iyileştirmek için metodolojik ve prosedürel değişikliklerin yeteneğini değerlendirir.

SQA bilgilerinin toplanması ve yayılması için Kayıt tutulur ve raporlama yapılır.

SQA Avantajları

Yazılımın gizli şekilde ortaya çıkan defect sayısı azalır.
Testing ve maintenance aşamalarındaki efor azalır.
Yüksek güvenirlirlik ile birlikte müşteri memnuniyeti sağlanır.
Maintenance bakımı azalır.
Genel yazılım projesi maliyeti azalır.

SQA Dezavantajları

Küçük organizasyonlarda (şirketlerde) uygulanması zordur.
Kültürel bir değişiklik gerektirir ve değişim bazı şirketler için zorlayıcı olabilir.
İlk zamanlarda ek maliyete yol açabilir.

Bu yazımı burada sonlandırıyorum. Bir sonraki QA konusunda, QA Review nedir ve farklı alanlarda reviewlerde sorulması gereken soruların checklistlerini paylaşacağım.