Yazılım Notları
Bilgi Paylaştıkça Çoğalır...

Yazılım Geliştirme Süreciniz “Böyle Olmayaydı İyiydi”

ISO 27001, ISO 20000, ITIL, CMMI gibi birçok Uluslararası kabul görmüş standart ve çerçeve IT sektöründe faaliyet gösteren işletmelerin ve müşterilerin imdadına yetişmektedir. Çünkü bu standartlar iki tarafın da beklentilerini netleştirmekle kalmıyor, aslında iki tarafa da hangi işi, nasıl, ne zaman ve hangi yolla yapmaları gerektiği konusunda rehberlik yapıyor. BU standart ve çerçevelere uygun bir şekilde yapılan her işin dokümante edilmesi ve karşılıklı olarak teyit edilmesi gerekiyor (Söz uçar yazı kalır).

Bilindiği üzere, Bilgi ve İletişim Teknolojileri alanında yapılan çalışmalarda Uluslararası standart ve çerçevelerin etkisi her geçen gün biraz daha etkili bir şekilde hissedilmektedir. IT sektöründe faaliyet gösteren firmalar, günümüzdeki çetin rekabet koşullarında gelirlerini artırmanın ve daha fazla müşteri portföyüne sahip olmanın bir yolu olarak müşteri memnuniyetini artırmanın gerekliliğinin daha fazla farkındalar artık. (En azında öyle olmasını hepimiz umuyoruz) Diğer taraftan müşteriler ise, IT taleplerini yaparken, Bilgi Güvenliği başta olmak üzere, sürdürülebilirlik, esneklik gibi konularda daha fazla talepkâr duruma gelmişlerdir.

İşte tam da bu noktada, ISO 27001, ISO 20000, ITIL, CMMI gibi birçok Uluslararası kabul görmüş standart ve çerçeve IT sektöründe faaliyet gösteren işletmelerin ve müşterilerin imdadına yetişmektedir. Çünkü bu standartlar iki tarafın da beklentilerini netleştirmekle kalmıyor, aslında iki tarafa da hangi işi, nasıl, ne zaman ve hangi yolla yapmaları gerektiği konusunda rehberlik yapıyor. BU standart ve çerçevelere uygun bir şekilde yapılan her işin dokümante edilmesi ve karşılıklı olarak teyit edilmesi gerekiyor (Söz uçar yazı kalır).

Bu yazıda, “yazılım geliştirme yaşam döngüsü(Software Development Life Cycle)” metoduna göre yazılım geliştirilmesi düşünüldüğü zaman yapılan yanlışlar ve doğrular gösterilmeye çalışılacaktır.

Yazılım Geliştirme Süreciniz “Böyle OLMAYAYDI İyiydi”

Kamu Kurumlarında yazılım geliştirme iş yapış şekli genelde şu şekilde gerçekleşmektedir:

1.      Yazılım talebi, ön analizler yapılmaksızın ansızın ortaya çıkabililir

2.      Eğer Kurumda bu yazılımı geliştirecek teknik bir ekip ya da yazılım uzmanı varsa,

a.      Talep edilen yazılımı kullanacak birimden, konu hakkında az çok bilgisi olan bir personel, yazılım uzmanının (programcının) yanına oturup, konuyu anlatır ve o anda programcı bir not defterine bazı notlar alır (not defteri olarak hafızasını kullanan bile olabilir)

b.      Yazılım uzmanı, söz konusu personel odasından çıktıktan sonra, hemen veri tabanını oluşturur, veri tabanı nesnelerini create eder, sonrasında da Visual Studio’da bir proje açar ve kodlamaya başlar. Öyle ya kervan yolda dizilir…

 

Analist, Tasarımcı, Veri Tabanı Yöneticisi, developer, Release & Deployment manager,  Bilgi Güvenliği Uzmanı, Tester, Standartlardan Sorumlu Uzman ve daha bir çok şey… Hepsi aslında tek kişidir: Yazılım Uzmanımız.

c.      Uygulamayı herhangi bir standarda bağlı kalmaksızın birkaç gün gibi çok çok çok kısa bir süre içinde geliştirip bitirdiğini düşünür ve devreye alır.

d.      Telefonla, ilgili personele bilgi verir ve “ ‘bi’ kontrol eder misiniz” diye sorar. (Buradaki “bi” ye dikkat lütfen.)

e.      Bundan sonra işler karışır(En eğlenceli yer geliyor işteJ). Şöyle ki:

                                                    i.     Herhangi bir versiyonlama zaten yoktur.

                                                   ii.     Herhangi bir analiz, gereksinim, tasarım dokümanı hazırlanıp müşteriye teyit ettirilmediği için müşteri(diğer birim personeli) büyük olasılıkla “orası öyle değil şöyle olacak” der. Ama istediği değişiklik belki de bütün veri tabanını yeniden tasarlamaya sebep olacaktır.

                                                  iii.     Yazılım uzmanı hemen işe koyulur, Veritabanında, tasarımda, kodlarda gerekli değişiklikleri yapar ve uygulamayı devreye aldığı dizinde bir copy paste yapıp, önceki publish dosyalarının kopyasını aldığına inanır. Ancak, bu aşamada veri tabanını da kendisinin değiştirdiğini ve aslında o kopyasını almış olduğu publish klasörünün artık çalışmayacağını düşünmez. Çünkü veritabanında bir değişiklik yapmadan önce restore edilebilir bir backup’ını almamıştır. Bu süreç aylar içinde o kadar yinelenir ki, uygulama sunucusunda uygulamanın yayınlandığı publish dosyalarının backupları onlarca olabilir ve isimleri genelde “Copy of Copy of Copy of Copy of … IKYS” gibi anlamsızlaşır.

                                                  iv.     Herhangi bir zaman gelir ve iş talep eden birim herhangi bir sebepten dolayı uygulamayı 3 ay önceki haline getirmesini ister yazılımcıdan. Bu durumda işler bir kez daha karışır ve yazılımcı gece gündüz çalışarak, uygulamanın 3 ay önceki halini elde etmeye çalışır ama bu durumda kaynak kodlar da evrim geçirdiğinden dolayı, uygulamayı yeniden kodlamaya kadar giden bir süreç içinde bulur kendini.

                                                   v.     Sonuçta iş isteyen birim mutsuzdur ve Yazılım Birimi bir işe yaramıyor, isteklerimizi karşılayamıyor, bir programı yazamadılar gibi serzenişlerde bulunur. Yazılım uzmanı da mutsuzdur, o da karşı tarafı suçlar: “Onlar sürekli isteklerini değiştiriyorlar, bi dedikleri bi dediklerini tutmuyor vs.”

3.      Yukarıda 2nci maddede yaşanan süreç bir kez gerçekleştiğinde, zaten bundan sonra en dar kapsamlıdan en geniş kapsamlısına kadar tüm yazılımlar artık ihale edilir. Bu durum, ilk başta özel sektörde iş yapan firmalar için avantaj gibi görülebilir ancak bu en büyük hatadır. Çünkü, iş talep eden kurum ya da kuruluş çalışanlarına ihaleyi alan firmanın yapacağı çalışmaları denetleyecek ya da kontrol edecek ne bir yetki verir, ne de sorumluluk. İhaleyi alan firma da, en kısa zamanda, en düşük personel maliyetiyle (part-time çalışan üniversite öğrencilerine harçlık vererek) söz konusu işi sonuçlandırıp bir an önce parasını almanın yolunu arar.

 

İhaleyi alan firmanın iş yapış şekli ise genelde şu şekildedir:

a.      Çok büyük bir enerjiyle “kick-off” toplantısı yapar. Powerpoint sunumlarına birkaç jargon da eklendi mi tamamdır.

b.      Sonra kalabalık toplantılar yaparlar, birkaç tane

c.      Sonra kaybolurlar

d.      3 ay sonra yeni bir İnsan Kaynakları Yönetim Sistemi’yle karşınıza çıkıverirler

e.      Kurumdan 32 CPU 64 GB RAM li bir sunucu isterler

f.       Veri tabanı da uygulama sunucusu da budur zaten.

g.      Uygulamayı devreye alırlar bu sunucu üzerinde. Hadi test edin derler ama testler test ortamında değil, production ortamında yapılıyordur.

h.      Kurum kullanıcıları istedikleri gibi bir uygulama göremezler. Ya performans sorunları vardır, ya user-friendly değildir ekranlar, ya Business yanlış anlaşılmıştır onlara göre, ya yetkilendirme konuları görüşülmemiştir, ya da raporlamalar yoktur vs.

i.       Firma hemen notlarını alır ve ofisine döner

j.       2 ay sonra yepyeni bir IKYS ile geri dönerler.

k.      Bu arada, kabul süreci de yaklaşmıştır. Firma parasını almak istiyordur. Kurum çalışanları da zaten haberleri olmadan bir “Muayene ve Kabul Komisyonu” na dahil edilmiştir.

l.       Artık durumu idare etmenin yolları aranır ve bulunur

m.    Muayene kabul komisyonu öyle ya da böyle, bir şekilde atar o kabul imzalarını ve firmanın parası ödenir.

Sonuçta, firma etkin ve etkili bir şekilde çalışmayan bir yazılım üretmiştir. Kurum ihtiyaçlarını karşılamıyordur bu yazılım, tam olarak. Ne bir dokümantasyon vardır ortada, ne bir plan, ne karşılıklı teyitleşmeler, ne bir versiyonlama, ne bir geri dönüş politikası, hiçbirşey olmadan “Çalışıyor mu? Çalışıyor” şeklinde bir yazılım bırakır Kuruma.

 

O IKYS uygulaması böyle bir Kurumda sürekli geliştirilir. Sürekli yamalar yapılır. Sürekli farklı uygulamalarla ihtiyaçlar karşılanmaya çalışılır ve İnsan Kaynakları Biriminde çalışan bir personel excel de ya da “akses” te bir uygulama geliştirip kendi ihtiyaçlarına çözüm üretir.

 

Aslında gerçekten de herkes kaybetmiştir. Çünkü:

1.      İK Personeli :KAYBEDER

Uzmanlık alanının tamamen dışındaki bir konuda iş ürettiği için, asıl ilgi alanında daha fazla uzmanlaşamaz.

 

2.      Yazılım Uzmanı         :KAYBEDER

Artık birçok iş ihale ile dış kaynaklara verileceği ve bu işler doğru bir şekilde yapılmayacağı için, önündeki yazılımın hatalarını ya da eksikliklerini tamamlamak için aralıksız çalışır. Kendini daha fazla geliştiremez. Verimliliği azalır. Mutsuzdur…

 

3.      İhaleyi Alan Firma    :KAYBEDER

Elinde tüm süreçleri dokümante edilmiş, etkin ve etkili bir şekilde en az hatayla çalışan bir yazılım olmayacağı için, katma değer yarattığı bir yazılım uygulamasına da sahip olmayacaktır. Elindeki yazılımı farklı kurumlarda devreye almak için çok daha fazla işgücünü daha uzun süre ile çalıştırmak zorunda kalacaktır. Bu da maliyetlerini artıracak ve karlılığını azaltacaktır.

 

Banka Hesap Numaralarınızı, IBAN Numaralarınızı bir kere telefonunuza kaydedin. İhtiyaç duyduğunuzda elinizin altında olsun.

Banka Hesaplarım

En Güzel Sözler Uygulaması İçin


En Çok Rating Alanlar
Ana Sayfa       Arama       Valid CSS!