Yazılım Geliştirmede Programlama

yazılımEvet, şimdi sıra programlamaya geldi. Bu noktada eğer daha önceden deneyiminiz yoksa aklınıza gelen ilk soru “veri tabanından mı başlamalı yoksa arayüzden mi?” olabilir. Ya da önce arayüz elemanlarını mı oluşturmalı yoksa kodlamaları mı yazmalı?

Bence öncelikle test senaryolarını yazmak en iyisi!

“Test mi?” dediğiniz duyar gibiyim. Evet test…

Amacınız gerçekten kaliteli bir yazılım geliştirmekse, hem müşterinizi memnun etmek istiyor, hem de işi teslim ettikten sonra bir yazılım geliştirme süresi kadar da düzeltmelerle uğraşmak ve rezil olmak istemiyorsanız, önce test! Bu aynı zamanda şu sıralar moda: Önce testleri geliştir, sonra kodu yaz.

Tabii biz bu çapta bir uygulamada bu kadar detaya inmeyeceğiz. Ancak verdiğimiz emeğin en verimli şekilde sonuca dönüşmesi için müşteriyle tasarımla uygulama aşamaları arasında bir mutabakat oluşturmakta fayda var. Bunu sağlamanın en doğru ve kolay yolu da müşteriye sormak: Yaptığım şeyin doğru olduğunu nasıl kontrol edeceksiniz?

Aslında bu aşamaya kadar dikkat ettiyseniz test dediğimiz şeyin sadece kodla ilgili olmadığını fark etmişsinizdir. Dikkat ettiyseniz her ne kadar elimizden geldiğince dikkatli bir şekilde analiz yapmış olmamıza rağmen tasarım aşamasında analizimizle ilgili bir takım eksiklikler bulduk ve bunları düzelttik. Buna analizin doğrulaması demiştik. Kodu direkt olarak test adını verdiğimiz bir süreçle doğruluk kontrolünden geçirirken bu işlemi analiz ve tasarım için de uygulama boyunca doğrulama dediğimiz bir kavramla yürüteceğiz.

Ekran taslaklarını çizdiniz, güzel bir de belge hazırladınız ama hala müşterinin istediğini yaptığınızdan emin olamazsınız. Ama eğer yaptığınız her iş için onay alıp, ayrıcı o işin çalışır halinin tam olarak nasıl çalışması gerektiğini de müşteriden öğrenir ve bu konuda müşteriyle mutabakata varırsanız artık yükümlülük müşterinin demektir.

Şimdi biraz müşteriden yardım alıp,, biraz da kendiniz zaman ayırarak her bir ekran ve işlevle ilgili olası tüm kullanım senaryolarını çıkartmaya bakın (Aslında bu aşama birçok yazılım geliştirme yönteminde analiz öncesi yazılım isterlerinin belirlenmesinde de kullanılır. Ben bu uygulamada daha basit bir aşamadan başlayarak, işlemleri olabildiğince yalın anlatmaya çalıştığım için bu detaya girmedim.) Örnek olarak “Randevu Alma Ekranı”nı ele alalım. Bu ekranda yapılacak işlem basitçe sol taraftaki takvimden tarih seçip, sağ tarafta görülen günlük randevu saatlerinden müsait olana tıklayarak randevu almaktan ibaret olarak görünüyor. Aslında bu doğru ama eksiktir. Çünkü sadece hatasız normal bir işlemi test etmiş ancak istisnaları test etmemiş olursunuz.

İstisnalar mı?

Evet, istisnalar. İlk olarak şunu düşünün. Hasta randevu almak için bir tarih seçti. Web sayfası yüklendi ve hasta bir süre düşünerek kendisi için en uygun saate karar verdi. Daha sonra da bu karar verdiği saate tıkladı. Ancak bu geçen zaman aralığında (hastamız saate karar verirken) birisi o tarihi kendine rezerve etmiş olabilir. Peki, bu durumda uygulamanız nasıl davranacak? İşte istisna bu…

Tüm istisnaları gözden geçirip bunlar için de tasarımınızda ve belgelerinizdeki gerekli düzeltmeleri yapmalısınız. Sonra da ekranlar tamamlandığında yapılacak testler için test senaryolarını hazırlayın.

Test: Randevu Kaydı –Normal Kayıt

Kullanıcı: Hasta

Ön Koşul: Hasta telefon numarası ve parolasıyla sisteme girip menüden randevu alma ekranına gelmiş olmalı.

Adımlar:

1.            Kullanıcı sol taraftaki takvimden bir tarih seçer.

2.            Kullanıcı sağ taraftaki randevu listesinden rastgele bir satır seçerek “Randevu Al” linkine tıklar.

3.            Sistem randevuyu veritabanına kayıt eder ve ekranı yeniden yükler. İlgili seansı “Dolu” olarak günceller.

Kontrol: Veritabanında ilgili seans kaydında hasta numarasının olup olmadığı kontrol edilir.

——————————————————

Test: Randevu Kaydı –Kayıt Çakışması

Kullanıcı: Hasta

Ön Koşul: Hasta telefon numarası ve parolasıyla sisteme girip menüden randevu alma ekranına gelmiş olmalı.

Adımlar:

1.            Kullanıcı sol taraftaki takvimden bir tarih seçer.

2.            Eş zamanlı olarak bir başka web gezgininden başka bir kullanıcı hesabıyla belirli bir saate randevu alınır.

3.            Kullanıcı sağ taraftaki seans listesinden rastgele bir satır seçerek “Randevu Al” linkine tıklar.

4.            Sistem kullanıcıya ilgili seansın uygun olmadığı bilgisini verir ve ekranı yeniler.

Kontrol:

——————————————————-

Test: Randevu Kaydı –Seans dışı tarih seçimi

Kullanıcı: Hasta

Ön Koşul: Hasta telefon numarası ve parolasıyla sisteme girip menüden randevu alma ekranına gelmiş olmalı.

Adımlar:

1.            Kullanıcı sol taraftaki takvimden bir tarih seçer.

2.            Sistem ilgili günün tatil olduğu bilgisini verir.

Kontrol:

***

Yaptığınız şeyin doğru olup olmadığını kontrol edecek kadar test yazdığınızda artık programlamaya başlayabilirsiniz demektir. Programlamaya başlarken dilerseniz dikey, dilerseniz yatay olarak geliştirme yapabilirsiniz. Yani bir seçenek olarak tüm işlevler için veritabanı tasarımını yapıp, ardından yine tüm işlevler için yerleşik yordam, fonksiyon ve sorguları yazıyor ve yine tüm işlevler için veri erişim ve doğrulama kodlarını yazıyorsanız bu yatay programlamadır. Bu da bir tercihtir ancak ben dikey programlamayı öneririm. Yani öncelikle elinizdeki işlevleri bir öncelik sırasına koyup, sonra bunlardan biriyle başlayıp veritabanından arayüze kadar tüm süreçleri tamamlayın. Ve sonra da testini yapın ve bir sonraki işlevi ele alın. Böylece tüm işlevleri sırasıyla tamamlayarak projenizi bitirin ve test edip bir sonrakine geçin.

***

Kodlamayla ilgili detaylar bu blogun kapsamı dışında. Ancak kavramsal olarak konuşulabilecek çok şey var. Örneğin veritabanı tasarımı, veri erişimi, listeler, raporlar, veri işleme, arayüz tasarımı, kodlama ve kullanıcı girdilerinin doğrulanması. Bunların her biri ayrı birer başlık ve bu blogda bunların hepsini zamanla detaylı olarak işlemeyi düşünüyorum.

Diyetisyen uygulaması için söyleyebileceklerimse öncelikle veritabanı tasarımı çok kolay olduğu için o iki tabloyu aradan çıkartarak yola başlamaktır. Sonrasında seçtiğiniz işlev için arayüzü oluşturun. Geriye kalan arayı doldurmaktan ibaret.

Veri işleme için benim önerim yerleşik yordam (stored procedure) ve görünüm (view) kullanmanız. Yani kayıt ekleme, güncelleme ve silme için yerleşik yordam, kayıt listeleme, detay getirme işlemleri içinse görünüm kullanın.

Ön uçta, kullanıcıdan veri aldığınız yerdeyse öncelikle gerekiyorsa verinin doğrulamasını yapın. Yani kullanıcı parolasını yenileyecekse veritabanıyla işlem yapmadan önce parolanın karakter sayısını kontrol edin, parola ve parola onayı değerlerinin eşit olduğunu kontrol edin. Sonrasında gerekli sınıfları kullanarak yeni bilgileri veri tabanındaki yerleşik yordamları kullanarak kaydedin.

***

Kodlama yaparken mümkün olduğunca isimlendirme ve bloklama standartlarınız olsun ve bunlara uyun. Kod okunabilirliğini artırmak ve işin tesliminden sonra bakım aşamasında kolaylık olması açısından kodunuza mümkün olduğunca açıklama metinleri ilave edin.

Tüm işlevleri tamamladıktan sonra genel bir test yapın. Entegrasyon testi adı verilen bu süreçte bileşenleri ve işlevlerin birbirleriyle ilişkilerinin doğru çalışıp çalışmadığı test edilir. Sonra uygulama gerçek kullanımı öncesinde müşteri yerine kurulur ve kabul testleri yapılır. Her şey yolundaysa gerçek kullanım için yükleme yapılır, veri tabanı temizlenir ve uygulama devreye alınır. Hazırlanan kullanım kılavuzları vb. belgeler müşteriye teslim edilir ve müşteriye kullanıcı eğitimi verilir.

Sonra diyetisyen sağ siz selamet…

Kadir Çamoğlu


0 yorum

Bir yanıt yazın

Avatar placeholder

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Bu site, istenmeyenleri azaltmak için Akismet kullanıyor. Yorum verilerinizin nasıl işlendiği hakkında daha fazla bilgi edinin.