6 Şubat 2014 Perşembe

İş Modeli ve yazılım geliştirme ilişkisi

 Yazılım geliştirme süreçlerinde proje yönetimi standartlarının etkin bir şekilde kullanılmaması sonucu iş modelinin ve yazılım geliştirme süreçlerinin çatışması kuvvetle muhtemeldir..

 Genelde pek fazla zamanınız yoktur, ve yapılacak geliştirmenin son hali, yaratacağı etki net olarak tahmin edilememektedir. Toplantılar yapılır, iş modeli için ne tür bir geliştirme olması gerektiği belirtilir. Daha sonra geliştirme süreci başlar. Ancak bir süre sonra geliştirmesine başlanmış yada tamamlanmış bir işlemin iptal edilmesine yada değiştirilmesine karar verilir.

 Geliştirme için yapılan toplantılardaki kararlara sadık kalınmamıştır, ama müşteri yada yönetici haklıdır. Çünkü toplantıda  sadece teorik analizlere göre kararlar alınmıştır. İş pratiğe geldiğinde yapılan aksiyonun istenilen sonucu vermediği yada vermeyeceği düşünülmüş ve bir takım aksiyonların güncellenmesi gerekmektedir.

 IT ekibinde bu karar pek hoş karşılanmamıştır. Çünkü bu işlem projenin bir çok bölgesini etkileyebileceğinden tekrar mantık haritası çıkarılması gerekmektedir. (Yazılan kodların değiştirilmesi, veritabanının yeniden tasarlanması vb. gibi.)

 Eğer yapılacak proje yada geliştirme orta yada büyük ölçekli bir işlem ise bir süre sonra geliştirme süreci tıkanır ve sinirler gerilir. Her iki taraftan da birbirini suçlayıcı ifadeler gelmeye başlar, iş geliştirme istedikleri bir değişikliğin bu kadar uzun sürmemesi gerektiğini düşünür, yazılım geliştirme departmanı ise istenilen taleplerin değiştirilmemesi gerektiğini düşünür. Aslında her iki taraf da haklıdır.

 Çözüm?
  İş geliştirme ve yazılım geliştirme süreçlerinin bir standart a bağlanması ve tarafların da bu standartlara katı bir disiplin ile uyması gerekmektedir.

Nedir bu standartlar? 

 Proje yönetiminde yukarıda bahsettiğim gibi sorunları ortadan kaldırmak için geliştirilen modeller vardır. Detaylı bilgiye buradan ulaşabilirsiniz.
 Ben kısaca en sevdiğim ve Türkiye şartlarına en uygun model olarak gördüğüm Spiral model den bahsetmek istiyorum. Bu modelde projenin bir başlangıcı vardır, ancak bitiş zamanı yoktur.

  Her bir geliştirme bir iterasyondur. Talepler gelir, geliştirme yapılır,yayınlanır, sonrasında iş modeline uygunluğu test edilir. Bu işlemlerin sonucunda bir rapor çıkartılır. Yapılan geliştirmenin ne derecede faydalı olduğu uygulamalı olarak analiz edilir. Bu analizlere göre tekrar bir iterasyon planı yapılır. Süreç bu şekilde proje istenilen seviyeye gelinceye kadar devam eder.

 Bu model yukarıda bahsettiğim sorunları ortadan kaldırdığı gibi yazılım geliştirme ve iş geliştirme ekibinin performansının da ölçeklenebilmesini sağlar. Çünkü model sizi her iterasyonun kayıtlarını tutmaya zorlayacak ve bu kayıtlar üzerinde de kimlerin etkinliğinin ne şekilde olduğu açık bir şekilde görüntülenebilecektir.

 Spiral model hangi tür durumlarda kullanılmalıdır?
 Eğer projeniz yada yapılacak geliştirme daha önce kullanmadığınız özellikler içeriyorsa, ve yapacağınız aksiyonları yapmış birilerinden iş modeli hakkında danışmanlık almamışsanız, yaptığınız projenin kullanılabilirliğini hiç bir zaman net olarak bilemezsiniz. Çünkü uygulamalı tecrübeden gelen net datalarınız yok. Teorik, bu olursa böyle olur gibi tahminleriniz var. Örnek olarak start-up projelerini gösterebiliriz.

Spiral model hangi tür durumlarda kullanılmamalıdır? 
 Eğer yaptığınız projeyi daha önce birkaç kez tekrar yapmışsanız, ve elinizde yapılmış projenin kabul edilen sonuçları varsa bu modeli uygulamaya gerek yok, burada waterfall model kullanabilirsiniz. Bunun sonucu size + zaman olarak yansıyacaktır. Örnek olarak paket program satılan bir firmayı düşünebiliriz.

4 Şubat 2014 Salı

Database Engine Tuning Advisor Nedir? - Sql

 Veritabanında index,statistic konularına pek hakim değilseniz ve kullandığınız veritabanı günden güne daha fazla data depolayıp büyüyecek ise yakın bir tarihte performans sorunları ile karşılaşmanız kuvvetle muhtemel.

 T-Sql performansınızı arttırmak için index ve statistics yazmanız gerekli, ancak bu işlemler dikkat ve tecrübe gerektiren aksiyonlardır. Performansı arttırmak için yapacağınız bir işlem tam tersi etkiler de yaratabilir. İşte bu noktada Sql Server'in kısaca "DTA" tool u dediğimiz "Database Engine Tuning Advisor" devreye giriyor.

Ne yapıyor?
Sizin yerinize veritabanını inceliyor, query performansını ölçüyor. Indexleri statistics leri oluşturuyor ve size bir sql script halinde veriyor. Size sadece bu scripti çalıştırmak kalıyor (:

Nasıl yapacağız?

Database Engine Tuning Advisor'ün sql performansını denetleyebilmesi için bir sql trace dosyasına ihtiyacı var. Öncelikle Sql Server Profiller i açıp bir trace oluşturuyoruz. Trace çalışırken veritabanında mümkün olduğu kadar çok işlem yapmamız ve veritabanını zorlamamız gerekiyor. Olası tüm sorguların çalıştığına emin olduktan sonra trace dosyamızı kaydediyoruz. Sonrasında Sql Server de "Tools/Database Engine Tuning Advisor" e tıklıyoruz. Bizden analiz edebilmesi için bir trace dosyası isteyecektir. Trace dosyamızı secip Start Anaylze butonuna tıklıyoruz.
  Sonrasında aşağıda görüldüğü gibi trace kodlarını analiz etmeye başlayacak ve sizin için index ve statistics leri oluşturacaktır.