Yazılımda Bakım Süreci ve IEEE 1219 Standardı

16 Haz

Sınama işlemleri bitirilen yazılımın kullanıcı ortamına yüklenmesi ve uygulamanın başlatılması gerekmektedir. Kullanıcı ortamı sunucu, desktop veya mobil platformalar olabilir. Yazılım devreye alındıktan sonra, yaşam döngüsünün en önemli ve hiç bitmeyecek aşaması olan “bakım” aşaması başlar.

Maintenance-Job

Müşteriye teslim edilmiş ve devreye alınmış çalışmakta olan yazılımın üç tür bakım gereksinimi bulunmaktadır.

1-Düzeltici bakım

Bir yazılımın 100% sınanabilmesi teorik olarak mümkün olsa da pratikte pek mümkün değildir. Bu nedenle hata ile karşılaşabilme olasılığı her zaman vardır. Zamanla ortaya çıkan hataların düzeltilmesi “düzeltici bakım” olarak adlandırılır.

2-Uyarlayıcı bakım

Uygulamaya alınmış yazılımlar kurumların, şirketleri veya kişilerin günlük hayattaki işlerini bilgisayar ortamında takip etmesini sağlayan araçlardır. Gün geçtikçe iş süreçlerinde yeni gereksinimler veya var olan gereksinimlerin iptali söz konusu olabilmektedir. Örneğin mevzuatların değişmesi, bir kurum yazılımında ilgili bölümün değişmesi anlamına gelmektedir. Bu tür uyarlamalar yazılımda “uyarlayıcı bakım” olarak adlandırılır.

3-En iyileyici bakım

Uygulama yazılımının performansının zamanla arttırılması gerekebilir. Bu tür bakımlar “en iyileyici bakım” olarak adlandırılır.

Yazılım bakımı, uluslararası standart belirleme organizasyonu olan IEEE(i triple e) tarafından belirli kriterlere ve aşamalara göre gerçekleştirilmektedir. Bakıma ilişkin standart IEEE 1219-1998 baz alınarak gerçekleştirilmektedir. IEEE tarafından sunulan bakım süreci şu adımları içermektedir:

  1. Sorun tanımlama süreci
  2. Çözümleme süreci
  3. Tasarım süreci
  4. Gerçekleştirim süreci
  5. Sistem test süreci
  6. Kabul test süreci
  7. Kurulum süreci

Bu adımlar aslında yazılım geliştirme yaşam döngüsünün çekirdek adımlarının tekrarlanması şeklindedir. Ancak tekrarlanan kısım sadece değişiklik isteklerinin mevcut koda aktarılması amacıyla yapılmaktadır.

Adsız

Süreç adımları IEEE 1219-1998 tarafından girdi, çıktı ve kontrol şeklinde belirlenmiştir.

1- Sorun Tanımlama Süreci

Adsız

Girdi: Sürecinin temel girdisi, “bakım isteği” şeklindedir. Örneğin;

  • Sistemde beklenen ve yeni düzenlemelere ilişkin değişiklikler.
  • Yeni fonksiyonel talepler.

İşlem/Süreç: Bakım isteği oluşturulduğunda yapılması gereken işlemlerdir.

  1. Değişiklik isteğine bir tanım numarası atamak.
  2. Değişiklik türünü belirlemek.
  3. Değişiklik isteğinin kabul edilmesi ya da ayrıntılı incelenmesine karar verilmesi.
  4. Değişiklik isteği ile ilgili zaman/boyut/işgücü kestirimi yapılması.
  5. Değişiklik isteğinin önceliklendirilmesi.
  6. Değişiklik isteğinin diğerleri ile birlikte zaman ve iş planına kaydedilmesi.

Bu adımların uygulanmasına değişiklik talebinde bulunan müşteri, kullanıcı temsilcileri, yazılım mühendisleri ve iş uzmanları ile birlikte çalışılarak karar verilir.

Denetim: Sorun tanımlama aşamasında ise değişiklik talebinin daha önceden yapılıp yapılmadığı denetlenir ve tek olduğu belirlenir. Mükerrer iş yapmaktan kaçınmak adına daha önceki değişiklik talepleri taranır.

Çıktı: Doğrulanmış, geçerlenmiş ve karar verilmiş “bakım İsteğidir”. Bakım isteğinin ayrıntıları bir veritabanında saklanır ve isteğe ait bilgiler şu şekilde olmalıdır:

  1. Sorun ya da yeni gereksinimin tanımı,
  2. Sorun ya da gereksinimin değerlendirmesi,
  3. Başlangıç önceliği,
  4. Geçerleme verisi (Düzeltici bakım için gereklidir),
  5. Başlangıç kaynak gereksinimi,
  6. Mevcut ve gelecekte kullanıcılar üzerindeki etkileri,
  7. Yararlı ve aksak yönleri

Ölçüt: Sorun tanımlama sırasında kullanılabilecek ölçütler

  • Bakım taleplerinde kabul edilmeyen madde sayısı,
  • Gelen bakım istekleri sayısı,
  • Sorunun aşılması için harcanan kaynak ve zaman biçimindedir.

Bu adımların tamamlanmasıyla birlikte çözüm süreci başlatılabilir.

2- Çözümleme Süreci

Çözümleme sürecinde, veri tabanında saklanmış ve geçerlenmiş bakım isteği girdi olarak alınır, projeye ilişkin bilgi ve belgeleri kullanarak söz konusu isteğin yerine getirilmesi için gerekli genel plan yapılır.

Girdi: Çözümleme sürecinin girdileri:

  1. Geçerlenmiş bakım isteği,
  2. Başlangıç kaynak gereksinimleri ve diğer veriler ve
  3. Mevcut proje yada sistem bilgi ve belgeleri biçimindedir.

İşlem/Süreç: Çözümleme süreci temel olarak iki aşamadan oluşur. Bunlar olurluk aşaması ve ayrıntılı çözümleme aşamasıdır.

Olurluk çalışmasında, yapılan değişikliğin etkileri, güvenlik ve emniyet zorunlulukları, insan faktörleri, kısa ve uzun vadeli maliyetler ve yapılacak olan değişikliğin yararları değerlendirilir.

Ayrıntılı çözüm aşamasında, değişiklik isteği için ayrıntılı gereksenim tanımlaması yapılır. Bu çalışmada etkilenen yazılım öğeleri (yazılım tanımları, yazılım gereksinimleri, tasarım, kod, vb) belirlenir. Yazılım bileşenlerinin değişmesi gereken kısımları belirlenir. Bu aşamada en az üç düzeyli test stratejisi (birim testleri, bütünleştirme testleri ve kabul kabul testleri) oluşturulur. Bu aşamada kullanıcıya en az etki yapacak şekilde değişiklik gereksinimlerinin nasıl karşılanacağı bilgilerini içeren “Başlangıç gerçekleştirim planı” da hazırlanır.

Denetim: Çözümleme çalışmasının denetiminde gerçekleştirilen işlemler şu şekildedir.

  1. Gerekli proje yada sistem bilgi/belgelerine erişimin sağlanması.
  2. Önerilen değişikliklerin  ve çözümleme çalışmasının teknik ve ekonomik olurluğunun gözden geçirilmesi,
  3. Güvenlik ve emniyet konularının tanımlanması,
  4. Önerilen değişikliğin, mevcut yazılımla bütünleştirilmesinin dikkate alınması,
  5. Proje belgelerinin düzgün olarak günlendiğinin denetimi,
  6. Çözümleme belgelerinin düzgün olarak hazırlanmasının sağlanması,
  7. Sınama stratejilerinin uygun olarak belirlenmesi.

Çıktı: Çözümleme çalışmasının çıktıları:

  • Değişiklik isteklerine ilişkin olurluk çalışması,
  • Ayrıntılı çözümleme raporu,
  • İzlenebilirlik listesini içeren günlenmiş gereksinim tanımları,
  • Başlangıç değişiklik listesi,
  • Sınama stratejisi,
  • Gerçekleştirim planı şeklindedir.

Ölçüt: Çözümleme çalışmasında kullanılabilecek ölçütler:

  1. Gereksinimlerdeki değişiklik sayısı,
  2. Belgeleme hata oranı,
  3. Her işlev alanı için gerekecek işgücü,
  4. Toplam zaman biçimindedir.

3- Tasarım Süreci

Tasarım aşamasında, değişiklikten etkilenebilecek tüm proje bilgi ve belgeleri üzerinde çalışma yapılıp söz konusu bilgi ve belgeler değişiklikle ilgili olarak güncellenir.

Girdi: Tasarım çalışmasının girdileri:

  1. Çözümleme çalışması çıktıları,
  2. Ayrıntılı çözümleme,
  3. Güncellenmiş gereksinim tanımları,
  4. Başlangıç değişiklik listesi,
  5. Sınama stratejisi,
  6. Gerçekleştirim planı,
  7. Sistem ve proje belgeleri ve
  8. Var olan kaynak kodları ve veritabanları biçimindedir.

İşlem/Süreç: Tasarım için gerekli temel işlemler aşağıda belirtilmektedir.

  1. Etkilenen yazılım modüllerinin tanımlanması,
  2. Yazılım modül belgelerinin değiştirilmesi,
  3. Yeni tasarım için, güvenlik ve emniyet konularını da içeren test senaryolarının hazırlanması,
  4. İlişki testleri tanımlanması,
  5. Kullanıcı belgelerinin güncelleme gereksinimlerinin tanımlanması,
  6. Değişiklik listesinin güncellenmesi şeklindedir.

Denetim: Tasarımın belirlenen standartlara uygunluğunun denetlenmesi gerekmektedir.

Çıktı: Bakım tasarımı çalışmasının çıktıları:

  1. Gözden geçirilmiş değişiklik listesi,
  2. Güncellenmiş tasarım
  3. Güncellenmiş test planları,
  4. Güncellenmiş ayrıntılı çözümleme,
  5. Güncellenmiş gereksinimler,
  6. Gözden geçirilmiş gerçekleştirim planı,
  7. Risk ve kısıtlar listesi biçimindedir.

Ölçüt: Tasarım çalışması için kullanılabilecek ölçütler aşağıda verilmektedir.

  • Yazılım karmaşıklığı,
  • Tasarım değişiklikleri
  • Her işlev alanı için gerekecek işgücü,
  • Toplam zaman,
  • Sınama yönerge ve plan değişiklikleri,
  • Önceliklendirmedeki hata oranları,
  • Varolan kodda, eklenen, çıkarılan ve değiştirilen satır sayısı,
  • Uygulama sayısı.

4- Gerçekleştirim Süreci

Gerçekleştirim sürecinde, temel olarak tasarım çıktılarını ve kaynak kodları girdi olarak alınmakta ve değişiklik isteğini gerçekleştiren kod parçaları ile güncellenmiş yazılım kodları üretilmektedir.  Güncellenmiş yazılıma ilişkin test bilgi ve belgelerinin ve eğitim belgelerinin üretimi de bu süreçte yapılmaktadır.

Girdi: Gerçekleştirim sürecinin girdileri:

  1. Tasarım çalışması sonuçları,
  2. Varolan kaynak kodlar, açıklamalar, belgeler ve
  3. Proje ve sistem belgeleri biçimindedir.

İşlem/Süreç: Gerçekleştirim sürecinin dört ana işlemi vardır:

  1. Kodlama ve birim testleri
  2. Bütünleştirme
  3. Risk çözümleme
  4. Sınama hazırlığı gözden geçirme

Kodlama işleminde, değişiklik isteğini karşılayan yazılım kodları, varolan yazılıma eklenmektedir. İşlem sonucunda elde edilen yeni, değişmiş modüllere birim testleri uygulanmaktadır.  Birim test işlemini, bütünleştirme testleri izlemekte, tüm sistem yeniden test edilmektedir.Uygulamadaki riskleri gidermek amacıyla, gerçekleştirim aşamasında sürekli risk çözümleme yapılmaktadır.

Denetim: Gerçekleştirim sürecinde oluşturulacak denetim yapısı, aşağıdaki özellikleri sağlamalıdır:

  • Belirlenen standartlara uygun olarak kod ve yazılım gözden geçirmeleri yapılması,
  • Birim ve bütünleştirme testleri ile ilgili bilgilerin derlenmesi ve kaydedilmesinin sağlanması,
  • Test belgelerinin güncellenmesi ve oluşturulmasının sağlanması,
  • Test hazırlıklarının gözden geçirilmesi sırasında risk çözümlemenin yapılması,
  • Yeni yazılımın, yazılım ortam yönetimi altında kaydedilmesi ve denetlenmesinin sağlanması,
  • Teknik ve eğitim belgelerinin güncellenmesi,

Çıktı: Gerçekleştirim süreci aşağıdaki çıktıları vermelidir:

  1. Güncellenmiş Yazılım,
  2. Güncellenmiş tasarım bilgi/belgeleri,
  3. Güncellenmiş sınama belgeleri,
  4. Güncellenmiş kullanıcı belgeleri,
  5. Güncellenmiş eğitim kılavuzları,
  6. Riskler ve kullanıcılara etkileri,
  7. Sınama hazırlığı gözden geçirme raporu

Ölçüt: Gerçekleştirim çalışmasında kullanılabilecek ölçütler kodlama ile ilgili olması gerekmektedir. Bu nedenle teknik ölçütler kullanılmaktadır:

  1. Değişiklik oranı
  2. Hata oranı

5- Sistem Test Süreci

Değişikliklerin mevcut yazılıma yansıtılmasından sonra elde edilen yeni yazılım sürümünün belirlenen standartlara uygun olarak tümüyle bütünleşik sistem üzerinde testlerin yapılması gerekmektedir.  Sistem testlerinin, kullanıcı ve üretici ekiplerin tanıklığında bağımsız bir yapı tarafından gerçekleştirilmeleri önerilmektedir.

Girdi: Sistem test sürecinin girdileri:

  1. Test hazırlık raporu
  2. Belgeler
  3. Sistem test planları,
  4. Sistem testleri,
  5. Sistem test yönergeleri,
  6. Kullanıcı kılavuzları,
  7. Tasarım
  8. Güncellenmiş sistem biçimindedir.

İşlem/Süreç: Sistem testleri, tümüyle bütünleşik bir sistem üzerinde yapılmalıdır. Bu aşamada, işlevsel sistem testi, arayüz testi, regresyon testi ve test hazırlık raporunun gözden geçirilmesi işlemleri yapılır.

Denetim: Sistem testleri, üretici ve kullanıcılardan bağımsız bir grup tarafından gerçekleştirilmelidir. Yazılım kodları ve her türlü bilgi belge, yazılım ortam yönetimi tarafından saklanır.

Çıktı: Bu aşamanın temel çıktıları:

  1. Tümüyle test edilmiş bütünleşik bir sistem,
  2. Test raporu,
  3. Gözden geçirilmiş test hazırlık raporu şeklindedir.

Ölçüt: Bu aşamada kullanılabilecek ölçütler, üretilen ve düzeltilen hata oranlarıdır.

6- Kabul Test Süreci

Kabul test süreci, kullanıcılar ya da kullanıcı temsilcileri tarafından gerçekleştirilen bir süreçtir.  Kullanıcıların, değişiklikleri içeren yeni yazılımı test etmeleri ve kabul etmeleri beklenmektedir.

Girdi: Kabul test sürecinin girdileri:

  1. Gözden geçirilmiş test hazırlık raporu,
  2. Tümüyle bütünleşik sistem,
  3. Kabul test planları,
  4. Kabul testleri ve
  5. Kabul test yönergeleri biçimindedir.

İşlem/Süreç: Kabul test işlemleri:

  1. İşlevsel kabul testlerinin yapılması,
  2. Birlikte çalışabilirlik testleri,
  3. Regresyon testleri biçimindedir.

Denetim: Kabul testleri sırasında denetimi aşağıdaki işlemleri içermektedir.

  1. Kabul testlerinin uygulanması,
  2. Sınama sonuçlarının raporlanması,
  3. İşlevsel denetim yapılması,
  4. Yeni sistemin oluşturulması,
  5. Kabul test belgelernin yazılım konfigürasyonuna yerleştirilmesi.

Çıktı: Kabul testlerinin çıktıları, yeni sistem, işlevsel konfigürasyon denetim raporu ve kabul  sınaması raporudur.

Ölçüt: Bu aşamada kullanılabilecek ölçütler: üretilen ve düzeltilen hata oranlarıdır.

6- Kurulum Süreci

Kurulum süreci, geliştirilen ya da  değiştirilmiş yeni yazılım sürümünün, uygulama sahasına aktarılma işlemlerini içerir.

Girdi: Bu sürecin temel girdisi, tümüyle sınanmış ve kabul edilmiş yeni yazılım sürümüdür.
İşlem/Süreç: Bu sürecin işlemleri:

  • Fiziksel ortam denetiminin yapılması,
  • Kullanıcıların bilgilendirilmesi,
  • Mevcut sistemin yedeklerinin alınması,
  • Kullanıcı tarafında kurulum ve eğitimlerin yapılması şeklindedir.

Denetim: Denetim işlemleri:

  1. Fiziksel ortam denetiminin yapılması,
  2. Sistem ile ilgili bilgi ve belgelerin kullanıcıya ulaştırılması,
  3. Sürüm Tanımlama raporunun tamamlanması,
  4. Yazılım konfigürasyon ortamına aktarımın sağlanması şeklindedir.

Çıktı: Bu sürecin temel çıktıları, fiziksel ortam denetim raporu ve Sürüm tanımlama raporudur.

Ölçüt: Bu süreçte kullanılabilecek ölçüt, belgeleme değişiklikleridir.

Tüm süreçlerin tamamlanmasıyla yazılım bakım döngüsü tamamlanmış ve müşteri istekleri eksiksiz yerine getirilmiş olmaktadır. Tekrar belirtmekte fayda var ki bu standartlar dizisi IEEE tarafından belirlenmiştir.

Neden Ciddi Yazılım Üretemiyoruz?

29 Şub

Aslında sorunun “Neden üretemiyoruz?” olması gerekirdi ama, kendimi fazla alan dışına çıkarmak istemediğimden iğneyi kendimize batıralım dedim. Evet “Neden ciddi yazılımlar üretemiyoruz?” sorusunu sormaya başladım. Yazılım sektörünün liderlerinin görüşlerini, kitaplarını okudukça ve yazılıma bakış açılarını gördükçe, yavaş yavaş sorumun cevabına yaklaşmaya başladım.

Öncelikle yazılıma ne olarak bakıyoruz, buradan sorgulamaya başlayabiliriz. Piyasada milyonlarca yazılım var. Bu yazılımlara ulaşmak için ne yapıyoruz? Hemen gidip pasajlardan “CD var oyun var, program var..” diye bağıran emek hırsızlarının ekmeğine yağ sürüyoruz. Aylar, yıllar süren çalışmaların karşılığını korsanlardan üç beş kuruşa satın alıyoruz. Bu ortamı gören kimse yazılım üretmek ister mi? Tabiki istemez. İsteyenler de kalitesizse, alın size kalitesiz yazılım üretimi için bir sebep.

Bir diğer soru, yeterince çalışkan yetiştirildik mi? Üşenmeden sıkılmadan bir işin sonucunu bekleyebiliyor muyuz? Olayın bu yönüne farklı bir alandan bakmak istiyorum aslında. Senelerimizi yiyen bitiren şu test sınav mantığı yokmu? Ham bilgi peşinde değilde, dersanelerde kısa yol kısa çözüm peşinde geçen gençliğimiz yok mu? İşte bu mantık; basma kalıp bilgilerle beynimizi doldurdu, bilgiye ulaşmamızı engelledi, bilmemiz gerekenleri hep pas geçerek seçiciliğimizi törpüledi, bizi kısa yol peşinde koşan tembeller haline getirdi. Maalesef yazılımı da aynı mantıkla öğreniyoruz. Forumlara bir göz atmanız bunu açık açık görmenize yardımcı olacak. “Şu ödevim için örnek kod var mı?”, “Bitirme çalışması için örnek konu var mı?” şeklinde açılmış konuları ve aklıma gelmeyen hazır kod isteklerini forumlarda bolca göreceksiniz. Böyle yetişen yazılımcıların ürettiği yazılımdaki ciddiyeti tahmin edebilirsiniz. O da olmadı dönüyoruz kursların peşinde. Hadi bana yazılım öğret diye. Yazılımcı kendi kendini yetiştiremiyorsa onu kimse yazılımcı yapamaz.

Takım çalışmasında başarılı mıyız? Yönetilmiş olmadan yönetmeye çalışan bireyler, takım çalışmasında başarısız olurlar. Sebebi ise bulunduğu konumu benimseyememiş olması ve gözünü yükseklere(maaşlara) dikmiş olmasıdır. Bu yüzden, kişi bulunduğu konumu kendi konumu olarak görmez ve hep yükseklere gözünü diker. Bu yüzdende yaptığı işe konsantre olamaz. Kafa hep başka yerlerdedir. Bu tarz insanlar takım arkadaşlarından bilgi saklar, aklınca arkadaşlarının kendi seviyesine çıkmasını engellemeye çalır, takım liderlerinden aldığı bilgileri takım arkadaşlarına tam iletmezler ve stres yüklü insanlar haline gelirler. Bir çıkış noktası yakalayıp yükselme peşindedirler. Bu şekildeki yazılımcıların iş kalitesini bir düşünün. Yazılım ekibi kesinlikle paylaşımcı olamlı ve o anda yaptığı işe odaklanmalıdır. Paylaşımcı olmayan takımlar başarısız olur.

Sistematik çalışma prensibine sahip miyiz? Yapılan yazılımlar da kişilere bağlı değil sistemlere bağlı olmalıdır. Kişiler herzaman değişkendir ancak sistemler sabittir. Modüler yapıda ve branşlaşmış çalışma ekipleriyle üretilen işler herzaman kaliteli olmuştur. Kariyer sitelerinde ilk defa iş ilanlarına baktığımda “vay be, insanlar ne kadar çok şek biliyormuş” diyordum hep. Sonraları komedinin farkına varmıştım. Bir yazılımcıdan istenen özellikler; Veritabanı yönetimi, programlama bilgisi, web bilgisi, tasarım bilgisi, sistem bilgisi v.s. Aklına geleni yazmış adamlar. En ilgi çekeni de esnek çalışma koşullarına ayak uydurmak. Artık gece onikide mi biret mesai bilinmez. Unutulmamalıdır ki her fazla mesainin altında bir plansızlık yatar. Her neyse, bunların hepsini yapacak bir kişi daldan dala atlamaktan ve google araması yapmaktan işini yapamaz. Çünkü kişi her konuda tecrübeli olamayacağına göre birsürü sorunla karşılaşacak. Böyle bir proje ne kadar başarılı olabilir ki?

Benimsenmiş yazılım prensiplerini uyguluyor musunuz? Bunların başında gelen çevik  süreçlerdir. Devamında ise temiz kodlama, teste dayalı programlama  gibi teknikler gelmektedir. Bu yöntemler sayesinde üretilen projeler tertemiz ve testleri yapılmış bir şekilde ortaya çıkar. Kodun yeniden düzenlenmesi için tüm yazılımın ayıklanıp incelenmesi gerekmez ve zaman kaybı önlenmiş olur.

Bence yazılım, kesinlikle kuralları olan bir süreçtir. Başarı için bu kurallara uyulması gerekmektedir. Kurallara uymadan yapılan kodlamalar sonucunda sadece çalışan kod yazılmış olunur. Bu yüzden, piyasa koşullarında rekabet edemeyen, sadece çalışan kodlarımız olur.