Yazılım Doğrulama ve Geçerleme

Mehmet Akşahin
Devops Türkiye☁️ 🐧 🐳 ☸️
10 min readNov 11, 2019

Yazılım kelimesi, çeşitli görevleri bilgisayar sistemleri üzerinde gerçekleştirmeye çalışan, belirli bir işlem adımı ve yapılan iş ile ilgili dokümanı olan bilgisayar programlarına denilir.

Bilgi sistemlerinin merkezi olarak bilinen yazılım sektörü, yüksek teknoloji sektörünün temelini oluşturmaktadır. İleri seviye ürün ve işlem yeniliği oranları, yüksek çapta bilgi yoğunluğu, hızla bir şekilde azalan ürün ömürleri, teknoloji yaşam döngüleri ve global pazara yayılmış bir değer zinciriyle karakterize edilebilir (Nambisan, 2002).

Bir bilgisayar programını yazılım yapan en temel unsur sadece kod yazılmış olmamasıdır. Aynı zamanda o koda ait ister dokümanı test dokümanı gibi dokümantasyonu yapılmış olmalıdır. [1]

Yazılımların geliştirilmesi aşamasında bazı süreçlere sahiptir. Aynı zamanda bu süreçleri uygulayan modellere de sahiptirler. Yazılım mühendisliği; bilgisayar bilimi, yönetim bilimi ve bilişim dallarından yararlanır ve sorun çözümünde mühendislik yöntemlerini kullanır. Yazılım mühendisliği; temelinde kalite bakış açısı olan, mühendislik yöntemleri, süreçler, metodolojiler ve yazılım araçlarını kullanan katmanlı bir yapıya sahiptir.

Yazılım geliştirmek için 4 temel süreç vardır. Bu süreçler;

  • Gereksinimin Analiz Edilmesi ve Belirlenmesi
  • Yazılımın Kodlanması
  • Kodlanan Yazılımın Test Edilmesi
  • Olgunlaşmış Yazılımın Bakım Tutumunun yapılması

Yazılımın hem üretim hem de kullanım süreci boyunca geçirdiği tüm aşamalar yazılım geliştirme yaşam döngüsü olarak tanımlanır. [2]

YAZILIM SÜREÇLERİ

Yazılım üretim işinin genel yapılma düzenine ilişkin rehber olarak yazılım geliştirme süreç modelleri baz alınmaktadır. Yazılım geliştirme süreci adımlarının hangi sırada ve düzende uygulanacağını tanımlar. Konu ne olursa olsun bir bilgisayar yazılımı geliştirme yalnızca kodlamadan oluşmamaktadır. Öncelikle yazılım geliştirme yaşam döngüsü bulunmaktadır. Yazılımın hem üretim hem de kullanım süreci boyunca geçirdiği tüm aşamalar yazılım geliştirme yaşam döngüsü olarak adlandırılır. Yazılım fonksiyonları ile alakalı gereksemeler sürekli olarak değiştiği ve genişlediğinden, söz konusu evreler devamlı bir döngü biçiminde ele alınır. Döngü içinde herhangi bir evrede geriye dönmek ve bir daha ilerlemek mevzu bahistir.

Bu döngünün de temel bazı adımları vardır. Bunlar;

  • Planlama aşaması, üretilecek yazılımla ilgili olarak personel ve donanım gereksinimlerinin çıkarıldığı fizibilite çalışmasının yapıldığı ve proje planının oluşturulduğu aşamadır.
  • Analiz aşaması, yazılım işlevleri ile gereksinimlerin ayrıntılı olarak çıkarıldığı aşamadır. Bu aşamada temel olarak mevcut sistemde var olan işler incelenir, temel sorunlar ortaya çıkarılarak, yazılımın yapabilecekleri vurgulanır. Temel amaç yazılım mühendisi gözüyle mevcut yapıdaki işlerin ortaya çıkarılması ve doğru olarak algılanıp algılanmadığının belirlenmesidir.
  • Tasarım aşaması, analiz aşamasından sonra belirlenen gereksinimlere yanıt verecek yazılım ya da bilgi sisteminin temel yapısının oluşturulması çalışmalarıdır. Bu çalışmalar, mantıksal tasarım ve fiziksel tasarım olarak iki gruba ayrılır. Mantıksal tasarımda, mevcut sistem değil, önerilen sistemin yapısı anlatılır. Olası örgütsel değişiklikler önerilir. Fiziksel tasarımda ise yazılımı içeren bileşenler ve bunların ayrıntıları yer alır.
  • Gerçekleştirim aşaması, tasarım aşaması biten yazılımın kodlama, sınama ve kurma çalışmalarının yapıldığı aşamadır.
  • Doğrulama ve geçerleme; İşletime alınan yazılımla ilgili olarak, hata giderme ve yeni eklentiler yapma aşamasıdır. Bu aşamada doğrulama ile ürünü kullanacak kişilerin isteklerinin karşılanıp karşılanmadığı, geçerleme ile, ürünün içsel niteliğine ilişkin izleme ve denetim etkinlikleri gerçekleştirilir.

Projenin hedeflerine ulaşabilmesi için türlü süreç ve yöntemler mevcuttur. Her bir süreç modeli, başarılı olmak için yazılım geliştirmede bu yaşam döngüsünü takip eder. Yazılım süreç modelleri üretilenlerin kalitesine pozitif etkisinin yanında, projelerin karışıklığını hafifletip karmaşıklıkları önler. Bunlar yazılım üretim faaliyetinin genel yapılma düzenine dair rehberler olarak adlandırılırlar. Bu modeller asla süreçlere ilişkin ayrıntılarla ilgilenmezler. [3][4]

En çok kullanılan yazılım geliştirme süreç modelleri;

  • Gelişigüzel Model
  • Barok Modeli
  • Çağlayan (Şelale) Modeli
  • V Modeli
  • Helezonik yani Spiral Model
  • Evrimsel Model
  • Artırımsal Model
  • Araştırma Tabanlı Modeli

Yazılım firmaları bu modellerden yeri geldiğinde bir tanesini yeri geldiğinde d projeye göre birden fazlasını kendisine rehber edinebilir. Bu modelleri uygulamayan bir firma ise daha önce defalarca karşılaşılmış hatalar ile tekrar tekrar karşılaşarak zaman ve para kaybına uğrayacaktır.

Bu modelleri uygulayan ve karşılaştığı hataları düzelten bazı kurum ve kuruluşlar, bir yazılım firmasında olması gereken çalışma prensiplerini standart hale getirmiştir. Bunlardan en çok bilinenleri:

  • CMMI
  • SPICE

Bunlar zorunlu olmayan lakin bir firmanın yazılım geliştirme adımlarında hata yapmasının önüne geçen kabul görmüş süreçlerdir.

Yazımızda bu sistemlerden CMMI 5 modelini kendine örnek almış bir firmanın maliyet süre hesaplamaları ve yazılım süreci bahsedilecektir.

CMMI 5

CMMI 5 MODELİ

CMMI (Yetenek Olgunluk Modeli Entegrasyonu) modelleri, organizasyonların süreçlerini iyileştirmesine yardımcı olan en iyi yazılım süreci destekçisidir. Bu modeller, sanayi, hükümet ve Yazılım Mühendisliği Enstitüsü (SEI) üyeleri ile ürün ekipleri tarafından geliştirilmiştir. Geliştirme için CMMI (CMMI-DEV) adı verilen bu model, ürün ve hizmetleri geliştirmeye yönelik kapsamlı bir kılavuz kümesi sağlamaktadır. CMMI-DEV modeli, CMMI en iyi uygulamalarını bir geliştirme organizasyonuna uygulamak için yazılımcıya rehberlik etmeye yaramaktadır. Modeldeki en iyi uygulamalar, müşterilerin ve son kullanıcıların ihtiyaçlarını karşılamak için kaliteli ürünler ve hizmetler geliştirme faaliyetlerine odaklanmaktadır.

Artık şirketler, ürün ve hizmetleri daha iyi, daha hızlı ve daha ucuz sunmak istemekteler. Aynı zamanda, yirmi birinci yüzyılın yüksek teknoloji ortamında, hemen hemen tüm kuruluşlar giderek daha karmaşık ürün ve hizmetler geliştirdiklerini keşfettiler. Bugün tek bir organizasyonun karmaşık bir ürün veya hizmet oluşturan tüm bileşenleri geliştirmesi olağan değildir. Daha yaygın olarak, bazı bileşenler dahili olarak inşa edilir ve bazıları kazanılır; tüm bileşenler nihai ürüne veya hizmete entegre olur. Kuruluşlar, bu karmaşık geliştirme ve bakım sürecini yönetebilir ve denetleyebilir olmalıdır.

Bu örgütlerin bugün hitap ettiği sorunlar, tümleşik bir yaklaşım gerektiren kurum genelinde çözümler içermektedir. İşletmelerin başarısı için örgütsel varlıkların etkili yönetimi kritik önem taşımaktadır. Özünde, bu kuruluşlar, işletme hedeflerine ulaşmanın bir parçası olarak geliştirme faaliyetlerini yönetmenin bir yoluna ihtiyaç duyan ürün ve hizmet geliştiricileridir.

Mevcut pazarda, bir organizasyonun iş yapma şeklini iyileştirmesine yardımcı olabilecek olgunluk modelleri, standartlar, metodolojiler ve yönergeler bulunmaktadır. Bununla birlikte, mevcut iyileştirme yaklaşımlarının çoğu işin belirli bir bölümüne odaklanır ve çoğu kuruluşun karşılaştığı sorunlara sistematik bir yaklaşım getirmemektedir. Bir işletmenin bir alanının geliştirilmesine odaklanarak bu modeller maalesef kuruluşlarda bulunan tıkanıklıkları ve bariyeri sürdürebilir. CMMI Geliştirme İçin (CMMI-DEV), bu engelleri önlemek veya ortadan kaldırmak için bizlere bir fırsat sağlamaktadır. CMMI for Development, ürün ve hizmetlere uygulanan geliştirme faaliyetlerine yönelik en iyi uygulamalardan oluşur. Ürünün yaşam döngüsünü, kavramadan teslimata ve bakıma kadar kapsayan uygulamaları ele alır. Burada temel vurgu, toplam ürünü inşa etmek ve korumak için gerekli iş planı üzerinedir.

CMMI-DEV, 22 işlem alanı içermektedir. Bu işlem alanlarının 16'sı çekirdek işlem alanları, 1'i paylaşılan bir işlem alanı ve 5'i geliştirme özel süreç alanlarını ifade etmektedir.

Tüm CMMI-DEV model uygulamaları, geliştirici organizasyonun faaliyetlerine odaklanmaktadır.

Toplamda beş süreç alanı gelişime özgü uygulamalara odaklanır:

  • İhtiyaçların geliştirilmesi,
  • Teknik çözüm,
  • Ürün entegrasyonu,
  • Doğrulama ve geçerleme

konularına yöneliktir.

CMMI süreçlerinin açıklaması;

0. Seviye / Incomplete: Sürecin belirlenen hedeflerinden biri ya da daha fazlası başarılamamıştır.

1. Seviye / Performed: Ürün ortaya çıkarken yapılması gereken iş yapılır ancak bu gelişim kurumsallaşmadığı takdirde zamanla kaybolacaktır.

2. Seviye / Managed : Süreç planlanır ve plana bağlı kalınır.

3. Seviye / Defined: Bu seviyeyi bir öncekinden ayıran en büyük fark, standartların kapsamı, süreç tanımlamaları ve uygulanan prosedürlerin işlevselliğidir.

4. Seviye / Quantitatively Managed: Kalite açısından amaçlanan ölçümlere ve süreç performansına ulaşılmıştır. Bu veriler istatistiksel terimlerle ifade edilir ve süreç devam ettiği sürece inceleme devam eder.

5. Seviye / Optimizing: Sürekli iyileşen ve gelişen yenilikçi bir süreç performansı gözlenir.

Türkiye’de birçok önemli kurumsal firma CMMI süreçlerine riayet etmektedir. Bunlar genelde savunma sanayi firmalarıdır.

SPICE MODELİ

Yazılım projeleri büyük, endüstriyel üretim süreçleri haline geldiğinde, süreç değerlendirmesinin süreç iyileştirme için güçlü ve etkin bir sürücü olabileceği fark edilmiştir. Buna dayanarak, büyük ve kritik yazılımlara sahip yoğun sistemlere sahip firmalarr tarafından, süreç değerlendirmesi için, uluslararası standardın kullanılmasının uygun olduğu değerlendirilmiştir. [6]

Yüksek kaliteli yazılım, yazılımı üretmek için kullanılan işleme sıkıca bağlıdır. Yüksek kaliteli yazılımlar üretmek için kuruluşların üretim süreçlerini sürekli iyileştirmesi gerekir. SPICE yazılım süreç değerlendirmesi için uluslararası bir standarttır ve süreç iyileştirme ve süreç kapasitesi belirlemede kullanılabilir. [7]

SPICE, yazılım süreci değerlendirmesi için büyük bir uluslararası girişimdir. Projenin üç ana hedefi vardır:

  • Yazılım süreç değerlendirmesi için bir standart için çalışan bir taslak geliştirmek
  • Ortaya çıkan standardın sanayi denemelerini yapmak
  • Yazılım süreç değerlendirmesi yazılımının dünyadaki yazılım endüstrisine aktarımı için destek sağlamak

SPICE, iki boyutlu bir model olup içe dönük süreç iyileştirme ile içe ve dışa dönük yetenek belirleme amacını taşır. Birinci boyutta süreçler, ikinci boyutta yetenek düzeyleri vardır.

Model, temel uygulamalar ve genel uygulamalar adlı bir dizi uygulama içerir. Süreçlere ve süreç kategorilerine gruplandırılmış temel uygulamalar, belirli bir sürecin temel faaliyetleridir. Buna karşın, herhangi bir işleme uygulanabilir jenerik uygulamalar, bir süreci yönetmek ve gerçekleştirme kabiliyetini geliştirmek için gerekli faaliyetleri temsil etmektedir.

Modeldeki beş işlem kategorisine sınıflandırılan işlemler aşağıda açıklanmıştır:

  • Müşteri/Tedarikçi: Müşteriyi doğrudan etkileyen süreçler, yazılımın müşteriye gelişimini ve geçişini destekler ve doğru kullanım ve kullanımını sağlar.
  • Mühendislik: Bir sistemi ve yazılım ürününü ve kullanıcı belgelerini doğrudan belirleyen, uygulayan veya koruyan süreçler.
  • Proje: Projeyi oluşturan, ürünlerini üretmek veya müşteriyi tatmin edecek bir hizmet sunmak için kaynaklarını koordine edip yöneten süreçler.
  • Destek: Bir projedeki diğer süreçlerin performansını etkinleştiren ve destekleyen süreçler.
  • Organizasyon: organizasyonun iş hedeflerini belirleyen ve organizasyonun iş hedeflerine ulaşmasına yardımcı olacak süreç, ürün ve kaynak varlıklarını geliştirme süreçleridir.

Modeldeki ilerlemeler, benzersiz yazılım mühendisliği veya yönetim faaliyetleri olan temel uygulamalarla açıklanmaktadır. Süreç kategorileri, süreçleri ve temel uygulamalar, faaliyet türüne göre gruplandırmayı sağlar. [8]

Süreç yetenek seviyeleri, ortak özellikler ve genel uygulamalar, süreç kapasitesinin gelişmesinde kullanılır. Yetenek seviyesi, temel olarak, bir işlemi gerçekleştirme kabiliyetini artıran bir dizi ortak özellikten (faaliyet grupları) oluşur. Öncellere kıyasla, her seviye, bir işlemin performansında önemli bir iyileşme sağlamaktadır.

Yukarıdaki açıklamalar ile SPICE, Yazılım Süreç İyileştirme ve Yetenek Belirleme kavramı tanıtılmıştır. SPICE, “Software Process Improvement and Capability Determination” standartlarının geliştirilmesini desteklemek için büyük bir uluslararası girişimdir. Dokümanlar, süreç geliştirme ve / veya işlem kapasitesi belirleme için kullanılabilen dokuz ayrı belgeyi içerir.

YAZILIM MALİYET TAHMİNLEME TECRÜBELERİ

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. Bir yazılım firması maliyet hesabını en baştan doğru hesaplamalıdır. Yoksa gerek yüksek mühendis maaşları gerek müşteriye ödenecek gecikme cezaları şirketin belini doğrultamayacağı hal alır.

Yazılım toplamda kaç Adam/Ay tutar sorusu temel sorudur. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Yani adam/ay ifadesi kaç yazılımcı ile kaç günde yapılacağıdır. Tabi bu noktada yine karışıklıklar başlayabilir.

Örneğin 1 çalışana sahip bir firma elinde 10 adam aylık bir iş bulundurmaktadır. Firma süreyi 5 adam/ay yapılma hedefindedir. Mantıken ilgili firma 1 kişi daha işe alarak toplamda 2 kişi ile bu süreyi 5 güne düşürebilir. Ancak gerçek hayatta durum böyle değildir. Öncelikle firmanın yöneticilerinin şunu bilmesi gereklidir. Yazılım işleri inşaat işleri gibi değildir. Projeye alacağınız yeni kişinin projeye alışma süresi vardır. Bu alışma süresinde mevcut işteki personeli de işinden alıkoyacaktır. Çünkü yeni gelen kişi öğrenmek için mevcut çalışanlara danışacaktır. Bu da işi hızlandırmak isterken yavaşlatmak demektir. Bu aşamada doğru maliyet hesabı yapmak gereklidir.

The Mythical Man-Month

Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi metotlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına) ve bunun gibi birçok duruma bağlı olabilir.

Yine başka bir örnekte; ürünün/projenin teslim aşamasında, pilotta (beta test) olunduğunu varsayalım. Bir takım süreç içerisindeki eksikliklerden dolayı, iş kritik olduğu için gece-gündüz geliştirme yapıldığı düşünülsün. Hedef odaklı işi bitirmek ve projeyi tamamlamak zorunda olan bir firma bunu uygulayabilir. Fakat firma bu ekstra maliyeti mevcut plana mutlaka yansıtılmalıdır.

Aslında iyi bir yazılım maliyet tahminlemesi için aşağıdaki adımlar temel alınmalıdır;

Öncelikle geliştirilecek olan yazılım is ̧ihtiyacı ve yazılımın kapsamı net bir şekilde belirlenmelidir.

  • Hesaplama maliyet işlemlerini yapacak çalışanın sistemin altyapısını ve yazılımın tasarımını iyi bilmesi gerekmektedir. Bu konuda eğitim almış bir mühendislik geçmişi olan bir yönetici seçilmesi tavsiye olunur.
  • Hesaplama maliyet işlemlerini yapacak çalışanın yazılıma ait mevcut kaynakları ve elde edilebilecek kaynakları iyi tanıması gerekmektedir.
  • Hesaplama esnasında kesinlikle oluşabilecek risklerin risk hesabının işin içine katılması gereklidir. Çıkan sonuç değeri maliyete eklenmelidir. Özellikle yazılımın başka sistemler ile entegrasyonu varsa, belirli bir yüzdelikte risk koyulması gereklidir. Bu risk değeri bağlı olunan entegre olunan yazılımdan kaynaklanabilecek riskler içindir.
  • Yapılan maliyet çalışmasında Analiz, Kodlama/Tasarım, Test, Dokümantasyon, Dağıtım gibi safhalar için ayrıca hesaplama detaylandırılmalıdır. Projenin büyüklüğüne göre bu süreçlere ayrı yöneticiler atanabilir.

Yapılacak bu işlemlerde dahi hesaplamada mutlaka sapmalar olacaktır. Lakin, zamanla edinilen tecrübelerle ve süreçlerin iyileştirilmesiyle, gerçeğe yakın yazılım maliyet tahminlemeleri yapılabilir.

Kendi iş tecrübemde de gördüğüm, kurumsal firmalarda bile bir yazılım beklenen sürede bitirilememektedir.

KISALTMALAR

BT Bilgi Teknolojileri
CMMI Capability Maturity Model Integration
SEI Software Engineering Institute
SPICE International Standard for Software Process Assessment CPU Central Proccessor Unit
RAM Random Access Memory

KAYNAKLAR

[1] M. M. AYKOL, “Yazılım süreçlerini etkileyen faktörlerin belirlenmesine ilişkin bir ölçüm ve iyileştirme modeli ve uygulaması,” Ph.D. dissertation, İSTANBUL UNIVERSITY, 2013.

[2] A. TARHAN, “An assessment model for the applicability of statistical process control for software processes,” Ph.D. dissertation, MIDDLE EAST TECHNICAL UNIVERSITY, 2006.

[3] S. KIRBAŞ, “An assessment and analysis tool for statistical process control of software processes,” M.S. thesis, MIDDLE EAST TECHNICAL UNIVERSITY, 2007.

[4] RELA Inc, Boulder, CO, USA, Software verification and validation 4–6 Nov. 1996 Date Added to IEEE Xplore: 06 August 2002 Print ISBN: 0–7803–3277–6

[5] “Waterfall model”, http://en.wikipedia.org/wiki/Waterfall_model (Erişim tarihi: 02.11.2017)

[6] Borandağ Emin, Yücalar Fatih, Erdoğan Şenol Zafer, İnce Fuat (2009). Basamaklı CMMI Modeli ile Extreme Programming Metodunun Değerlendirilmesi, Yayın Yeri:Trakya Univ J. Sci

[7] Yücalar Fatih, Erdoğan Şenol Zafer (2009). A Questionnaire Based Method for CMMI Level 2 Maturity Assessment, Yayın Yeri:Journal of Aeronautics and Space Technologies

[8] S. A. ALPARSLAN, “CMMI ile yazılım süreçlerinin iyileştirilmesi ve yazılım şirketlerinin CMMI 3 seviyesine göre değerlendirilmesi,” M.S. thesis, ALANYA ALAADDİN KEYKUBAT UNIVERSITY, 2017.

[9] Anderson’un, David j., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003.

[10] S. KIRBAŞ, A. TARHAN, and O. DEMİRÖRS, “İstatistiksel Süreç Kontrolünün Yazılım Süreçlerine Uygulanabilirligini Degerlendirme ve Analiz Aracı,” presented at the III. Ulusal Yazılım Mühendisligi Sempozyumu ve Sergisi (UYMS), Ankara, 2007.

--

--