04.05.2007

Prototip (ilkörnek) Yazılım Geliştirme

spYazılım geliştirmek artık sadece kod yazmaktan ibaret değil. Gün geçtikçe tasarımcılar mühendislik, mühendisler de tasarım bilgi ve becerilerini artırıyorlar.

Ticari bir yazılım projesinde prototip kullanılması işleri kolaylaştıracaktır. Hem profesyonelce sunumlar yapabilmek hem de ürünün karşı tarafa daha iyi ifade edilebilmesi açısından çeşitli katkıları olacak, iletişimi artıracaktır.

Bu konuda Hal Helms tarafından yazılmış bir yazıyı sizlerle paylaşmak istedim, orijinali (ingilizce) burada.


Emotional Design: Why We Love (Or Hate) Everyday Things (Donald Norman) sadece kullanışlılığın tek başına yeterli olmadığını savunuyor. Norman, nesneleri değerlendirişimizde üç etken olduğunu belirtiyor: sezgi, etkileşim ve yansıma. Sezgisel çekim, bir Ferrari ya da iPod’a karşı hissettiklerinizle açıklanabilir. Güzel görünüşlü, içinde oturmak (Ferrari) ya da ona dokunmak (iPod) istiyorsunuz. Etkileşim çekimi, çok iyi çalışan bir nesnenin takdir edilegelmesidir diyebiliriz. Yansıma ise, anlamlandırma ve kendini bulma gibi açıklanabilir.

Norman, iyi tasarımın bu üç öğeyi de içerdiğini, aynı zamanda bu nesnelerin insanların daha iyi çalışmalarını sağladığını iddia ediyor. Düşünce bana haklarında bir çok kez konuştuğum prototipleri (ilkörnek) çağrıştırdı.

Tasarım dünyasında, prototip bir zorunluluktur diyebiliriz. Palm Pilot’un tasarımcısı bu cihazı tasarlarken cebinde bir tahta parçası ile dolaşıyordu. Bu nesne rahat kullanılabilecek bir şey mi? Hangi ebat çok büyük olarak algılanırdı? Ya da çok küçük? Düğmeler doğru tasarlandı mı?

Nedense, bir çok geliştirici (developer) tasarımın ancak grafik sanatçılarına bırakılması durumunda iyi sonuçlar elde edilebileceği kanaatindedir. Prototip gereksiniminden bahsederken altını çizmek istiyorum, olası beklentilerimizin açığa çıkartabilmesi, görünüşünden ve hissedilişinden (look & feel) ziyade, tasarlama süreci içerisinde çalıştırılması, kullanılması ile sağlanabilir. iPod’un çevirmeli arayüzünü görene kadar, onu isteyip istemeyeceğimi bilemezdim.

İş yazılımı geliştirme aşamalarında prototiplerle çalışmanın, hem geliştiren hem de işverenin sırtından bir takım riskleri aldığını düşünüyorum. Şartname dokümanları avukatlar için kullanışlı olabilir, bizler için değil. Prototipler, yeni fikirleri denememize ve kullanıcı reaksiyonlarını gözlememize imkan sağlar. Bu sayede tasarlanan nesnenin sezgisel ve etkileşime dayalı etkilerini, hatta belki yansımalarını görebiliriz.

Uzun bir süredir prototipler kullanıyorum. İlk denemelerim sadece etkileşim amaçları üzerine keşifler yapmak ile sınırlıydı. “Görünüşe takılmayın” derdim sunum yaparken. Deneyimle sabitlendi ki neredeyse her işveren, görünüşe takıldı. Sonunda anladım ki, onların bu ihtiyacını karşılamadan – her ne kadar bana ikincil bir ihtiyaçmış gibi gelirse gelsin – benim için daha önemli olabilecek aşamalara geçmek zorlaşıyordu, örneğin yazılımın işleyişine.


Abraham Maslow “İhtiyaçlar Hiyerarşisi Teorisi“nde tipik gereksinimlerimizi şöyle sıralar:

  1. Fizyolojik gereksinimler : su, yiyecek, uyuma, barınma
  2. Güvenlik gereksinimi : fiziksel, ekonomik, konfor
  3. Ait olma gereksinimi : kabul görme, aidiyet
  4. Sevgi, sevecenlik gereksinimi : sevgi, tutku
  5. Saygınlık gereksinimi : ustalığın saygınlığı, prestij, statü
  6. Kendini geliştirme gereksinimi : yenilikçilik, yaratıcılık, derin öğrenme

Maslow, “Belirli bir kategorideki gereksinimler tam olarak karşılanmadan kişi bir üst düzeydeki kategorinin gereksinimlerini algılamaz, böyle gereksinimleri yoktur” demektedir. Şartnameler veya ihtiyaçlar dokümanları ile çalışmaya başlamak konusunda sorun, UML diyagramlarının ve benzerlerinin aslında işverenin temel kaygılarına hitap etmeyecek olmasıdır: nasıl görünecek ve hissedilecek? Onunla çalışmak nasıl olacak?

Prototipler tüm bu sorulara cevap verir, fikirlerimizi sergileyebilmemiz ve işverenin konu hakkındaki düşüncelerini anlayabilmemiz için en uygun araçtır. Bu sayede, sözcüklerin ötesinde bir iletişim kurabiliriz. İyi uygulamaların da – iyi tasarımların olduğu gibi – sezgisel, etkileşim tabanlı ve yansıma albenilerine sahip olması gerektiğine inanıyorum. İşe başlamak için doğrudan kapsamlı bir prototip (ilkörnek) hazırlamaktan daha iyi bir yol düşünemiyorum.

Etiketler

, , , , , , ,

6 Yorum

  1. Mert

    Çok güzel bir yazı, bunu bizimle paylaştığın için teşekkürler Cenk. Prototiplendirme aşamasında beni en çok korkutan şey ipin ucunu kaçırmak. Prototip yazılımı geliştirmeye başlamadan önce sanırım nerede dur diyeceğini ve sınırı iyi çizmek gerekiyor. Yoksa bir bakmışsın ki prototip olmuş yazılımın aslı. Bu da bence kaçınılması gereken bir konu.

  2. arikan

    Yazı ve çeviri için çok sağol Cenk.

    İster online proje yönetim sistemi geliştirin ister dinamik grafikler programlayın yazılım geliştirmek genelde çok karmaşık bir süreç. Bu durumda yazılım geliştirmeye en basit ve bariz olan fonksiyonlardan başlayıp karmaşaya adım adım ilerlemek oldukça işe yarıyor. Bu ilerleme sırasında küçük yani yutulabilir adımlarla yürümek çok önemli, çünkü karmaşıklık arttıkça program içinden çıkılmaz bir hal alacaktır. Ben genelde işi şu adımlara, yani sürümlere (“version”) bölüyorum:

    Alfa Sürüm – Sadece bariz fonksiyonların olduğu, kaba, bize sadece nasıl bir şey olacağı hakkında fikir veren sürüm.

    Beta Sürüm – Amaçlanan bütün fonksiyonların çalıştığı ama hala düzenlenmesi gereken sürüm.

    Sürüm 1.0 – Tümüyle tamamlanmış yazılım. Tüm fonksiyonlar ve arzulanan davranışlar çalışıyor.

    Sürüm 1.1 – Geliştirme boyunca öğrenilen, farkedilen davranışların eklendiği daha cilalı arıtılmış sürüm.

  3. Mert

    “Palm Pilot’un tasarımcısı bu cihazı tasarlarken cebinde bir tahta parçası ile dolaşıyordu.” Bir tahta parçası bir cep bilgisayarının prototipi olabiliyorsa, sizce bir yazılımın prototipi ne kadar basite indirgenebilir? Bu konuda fikirlerinizi paylaşabilirseniz sevinirim.

  4. arikan

    Mert bu soru çok nefis ve akıl açıcı. Bir nesnenin prototipi tahta bu örnekde. Bütün mimarlık pratiği gözümün önüne geliyor. Bina modelleri, içinde küçük insanlar ve modelin etrafında dönüp duran orasına burasına bakan tasarımcılar. Modellemek burda sanırım anahtar kelime gibi. Fiziksel şeyler kartondan tahtadan modellenebilir ama yazılımı oluşturan soyut işlemler nasıl modellenir?

    Genelde bir kağıda yemek tarifesi gibi yazı yazarak ve resimler çizerek başlıyorum programlamaya. Önce modelleri çiziyorum sonra arasındaki ilişkileri. Sanırım prototip süreci böyle başlıyor yazılım için.

    Bu işlem yazma işini yazılım dışında da uygulamaya başladım. Yaptığım bir tipografik çalışmada elle çizdiğim fontları nasıl çizmem gerektiğini yazmıştım tarife olarak. Yani kendimi bilgisayar gibi kabul edip komutlar verdim ve bunlara uyarak elle harfler çizdim.

  5. engin

    Mert, yazilim prototipini test edecegin potansiyel kullanicilara ve test etmek istedigin unsurlara bagli olarak epey basitlestirebilirsin. Ozellikle gelistirmenin ilk asamalarinda kagit uzerinde yapacagin son derece basit arayuz cizimlerini potansiyel kullanicilara gostererek uygulamanin ana akislari ile ilgili faydali fikirler alabilirsin (bir email uygulamasinin ana akislarindan biri yeni email hesabi acmak olabilir). Bu tarz prototiplerde detayin ne oldugu kadar, test edecegin kisiyi teste nasil hazirladigin ve prototipi nasil sundugun son derece onemli. Mesela, bir cep telefonu uygulamasi icin, eger basit kagit cizimleri gercek bir cep telefonu uzerinde gosterirsen kullaniciya daha gercekci bir ortam hazirlamis olursun. Mesela:
    Cep prototip

  6. cenk

    Prototip geliştirme aşamasında, üretim yapacağımız ortamı da kullanabiliriz. Mert’in dediği gibi, bir yerde dur demek de lazım. Bu çizgileri baştan belirlemeliyiz, sonrasından iş karışabilir. Mümkün olduğunca basit tutmakta, bu aşamaları önceden belirlemekte fayda var.

    Bir altyapı, asıl ürüne prototiplik yapacak şekilde de kullanılabilir. Basitçe bir örnek, karmaşık bir site tasarımı için pasif HTML sayfalar kullanılarak prototip geliştirilir. Final fazlarda PHP, ROR, ColdFusion, Java, Asp ile çalıştırılır. Elimizde hem çalışan bir ilkörnek olur, hem de bu ilk süreç içerisinde değişiklikleri çok rahat uygulayabiliriz.

    Engin’in notlarından yola çıkayım, mesela aslında Symbian üzerinde çalışacak muhtemel Java uygulamasını Adobe Flash ile canlandırıp sunabiliriz.

    Gerçekten çalışması gerekmiyor. Kullanıcının alışık olduğu nesnelerle (loading animasyonlar butonlar vb) bezenmiş bir tanıtım epey iş görecektir. İşi sunduğumuz tarafta “hmm, anladım” etkisi uyandıracaktır. İşi teslim alacak arkadaşlara bu demonun son görüntü ve fonksiyonları yansıtmadığının belirtilmesi yerinde olur.

    Azcık da estetik unsurlar içerdi mi tamamdır. Hibrid tasarımcıların elinden zaten doğal olarak estetik çözümler çıkar, geliştiriciler de bu konuda grafik tasarımcılardan destek alabilir, sunumlarını daha albenili hale getirebilirler.

    Bir yöntem de, benzeri uygulamaların ekran görüntülerini keserek kullanmaktır. Bu da çok faydalı bir anlatım tarzı, grafiğine inciğine boncuğuna vakit harcamaktansa, tanıdık simgelerle (posta ikonunu gözünüz bir yerlerden ısırdı mı?) kolayca sonuca varılabilir.

    Tüm bu çalışmalardan önce, ben de kağıt üzerinde çizerek düşünürüm.

Yorum Yaz