Her derde deva bir yazılım alt yapısı yoktur. Ne kadar esnek yazılırsa yazılsın her alt yapının tıkandığı noktaları ve zafiyetleri vardır. Böyle bir şey mümkün olsaydı, tüm uygulamalar aldığı sürenin çok daha altında bir sürede biterdi. Probleme özel esnek bir alt yapının oluşturulması mümkündür fakat başarılı olması ilgili probleme dair “ihtiyaç analizi”nin ne kadar iyi yapıldığı ile doğru orantılıdır.

“İhtiyaç analizi” kendini anlatan bir deyim. Süreç sonunda elde edilecek olan ürünün ne olacağı, nasıl çalışacağı, neler yapacağı, hatta nasıl yapılacağı ihtiyaç analizi sırasında mümkün olduğunca eksiksiz hazırlanmalıdır.

İhtiyaç analizinin hazırlanmasından sonra yazılımcı, arayüz tasarımcısı ve kullanıcı deneyimi tasarımcısı “müşteri” ile toplanır ve ihtiyaç analizini ve işin sonunda ürün olarak ortaya çıkacak olan uygulamayı tartışırlar. Bu aşamada yazılımcı veritabanın nasıl olacağını, kullanıcı deneyimi tasarımcısı uygulamanın kullanım akışını, görsel tasarımcı da bu akışın nasıl görüneceğinin eskizlerini kafalarında oluştururlar.

İlk toplantının sonrasında yapılacak ikinci toplantıda bu eskizler üzerinde tartışılabilir görüntülere dökülmüş haliyle tartışmaya açılır ve görsel olarak uygulamanın akış şeması ve tüm ekran görüntüleri belirlenir. Bu konunun netleşmesi için gerekirse üçüncü bir toplantı da yapılır. Tüm ekran görüntüleri bittikten sonra sadece resimlerden oluşan uygulamanın akış şeması ve uygulamada yer alacak bilgiler konusu “müşteri” ile tekrar tartışılır ve yazılım öncesi uygulamanın tüm görselleri ve altyapısına dair bilgiler netleştirilir.

Biten görseller yazılımcının kullanabileceği forma dönüştürülür (Ör: Web uygulamaları için HTML formatında). Yazılımcı da bu süreçte tasarladığı veritabanını ve bu arayüz dosyalarını kullanarak uygulamanın motor kısmını geliştirir ve uygulamayı nihayete erdirir. Yazılımın kodlanmaya başlanmadan önce tüm ekranların tasarlanmış olması sonuçta çalışacak olan uygulamanın nasıl olacağını net bir şekilde ortaya koyacağından yazılım bittikten sonra düzeltme olarak geri dönen istekler sadece fonksiyonel olarak uygulamaya dahil edilmesi atlanmış istekler ve yanlış çalışan fonksiyonların düzeltilmesi olacaktır. Bu noktada altyapıyı kökten değiştirmeye gidecek istekler büyük bir ihtimalle gelmeyecektir. Gelmesi durumunda bu “müşteri”nin süreci kendi açısından iyi yönetemediğinin göstergesi olacağından ilgili zaman ve emek kaybının sorumluluğu ve “masrafı” “müşteri”de olacaktır.

İlk bakışta süreci uzatıyor gibi görünebilir fakat bir oyuncunun kendi yazdığı bir senaryoda kendi yönetmenliğinde başrol oynayıp filmin müziklerini de hazırlayıp prodüksiyonunu yapması gibi bir yazılımcıyı kendi başına bırakmak hem zaman konusunda hem de ortaya çıkan iş karşısında müşteri memnuniyeti konusunda büyük bir ihtimalle sıkıntılar çıkaracaktır. Herkesin kendi uzman olduğu işi yapması gerektiği bir işte bir yazılımcıdan yazılımın düzgün çalışmasını sağlamak dışında fazla bir şey beklememeyi öğrenmek gerekiyor sanırım.