Uzun süredir .Net ve C# ile içli dışlıyım. Fakat şu varki .Net ve C# %100 kusursuz değil maalesef özellikle platform bağımlılığı en büyük eksiklik. Bu eksiklik dilde olunca doğal olarak bende de olmuş oluyor. Yani microsoft ve netframework e %100 bağımlı bir yazılımcı oluyorum. Uzun süredir düşünüyordum bu durumu baktım ki Microsoft bu konuda bir açılım (!) yapmayacak dedim bari ben yapayım :). Java Ruby Python arasında yaşadığım gel-gitler sonucunda Java da durmaya karar verdim.


Artık çalışmalarımın bir kısmını Java üzerinden yapacağım :). C# ve .Net i bıraktım mı kesinlikle hayır. Sadece artık Java yı da öğrenip biraz bu dil üzerinde çalışacağım.

Türk ve Japon şirketleri arasında bir kürek yarışı düzenlenmesine karar verilir.

Her iki takımda performanslarının en üst düzeyine varabilmek için uzun ve zorlu bir hazırlık döneminden geçer.

Büyük gün gelir, her iki takımda kendini hazır hissediyordur. Japonlar yarışı bir kilometre farkla kazanırlar....

Yarış sonrası Türk takımı çok sarsılır. Türk Şirket yönetimi yarışın açık farkla kaybedilmesinin nedeninin bulunmasına karar verir.

Yapılan araştırmalar, analizler ve uzun çalışmalar sonucu hata bulunur ve çözüm önerisi getirilir. 

Japonların takımında 8 kişi kürek çekiyor, 1 kişi dümencilik yapıyordu. 

Türk Takımında ise 1 kişi kürek çekiyor, 8 kişi dümeni kullanıyordu.   

9 kişilik Türk takımı  Japonlarla bir yarış yapmak üzere yeniden yapılanır. Yeni yapılanma şekli şöyledir;

·         1 Dümen Genel Müdürü

·         3 Dümen Müdürü

·         3 Bölgesel Dümen Müdürü

·         Kürek çekmekle görevli kişinin performansından sorumlu bir Dümen Yöneticisi

·         Kürek Çekme Elemanı. 

İkinci yarışı bu sefer Japonlar iki kilometre arayla kazanır.

Tepesi atan Türk şirketi yönetim kurulu Hemen harekete geçer;

Yarışın kaybedilmesinden sorumlu tutulan kürekçi kovulur ve müdürlere Sorunun çözümüne olan katkılarından dolayı ikramiye verilir.

 

“Sabah namazı yüzünden Ateist oldum”
Dindarların çocuklara dini sevdirme hatalarını konuştuğumuz bir arkadaşım, işyerinde ki “ateist” bir arkadaşından dinlediklerini bana anlatmıştı.“Sabah namazına beni kaldırmaya gelen babam, bir sürahi su dökerek beni kaldırırdı. O zamanlar babamdan korktuğum için kalkardım. Tabi ne abdest alırdım ne de namaz kılardım. Abdest alıyormuş gibi yapar, namaz kılmış gibi geri yatardım. Ancak babama olan öfkem artardı.Babama olan öfkem evden uzaklaşınca babamın savunduğu tüm değerlerden uzaklaşmak olarak hayatım da yerini aldı. Babama olan öfkem beni bugün ateist yaptı.”

Ateist haklı değil elbette, ancak “bir sürahi su ile” oğlunu sabah namazına kaldırmaya çalışan baba da masum değil.

* * * * * * *

Sabah namazına çocukları alıştırmak için öğrendiğim bir yöntem çok hoşuma gitmişti. Eskiden alimler sabah namazına kalkınca, çocukları kaç aylık yada kaç yaşında olursa olsun, yanına gider çocuğun burnundan hafifçe sıkar, evladına dua eder, sonra da namaza gider yada namaz sonrası yatarmış.
Her gün sabah namazı vaktinde burnu sıkılarak, uykusuna hafif bir “sekte” vurulan çocuğun sabah namazına kalkma alışkanlığı kazanması çok daha kolaydır. Bir sürahi sudan daha etkili, daha kalıcı, daha faydalı bir yol olduğu kesin.

 * * * * * * *

Türkiye’de dindar insanlar yıllarca, Peygamber efendimizin tek bir çocuk dövmediğini bildiği halde, “Dayak cennetten çıkmıştır” yalanına inanarak, çocuklara dine sevdirmek için, dayak yöntemini kullandık.Hata yaptığımızı itiraf etmeliyiz.
Namaz kılmayı çocuklara sevdirmenin “kalıcı” yöntemlerini bilmeyen dindar insanlar, yıllarca çocuklara namazı sevdirme adına hatalar yaptılar.

Hata yaptığımızı itiraf etmeliyiz.
Hatalarımızı itiraf etmeyip, doğru yöntemleri öğrenmeye ve kullanmaya başlamazsak, “sabah namazı yüzünden ateist olan” insanların sayısı artmaya devam edecek.

Sait ÇAMLICA Eğitimci – Yazar

Yazılım geliştirmede en önemli unsur uygun süreç modelinin belirlenmesidir. Uygun süreç modeli seçilirken öncelikle tüm modellerin bilmesi gerekmektedir. Daha kaliteli daha başarılı yazılımlar geliştirmek için projeye ve içeriğe en uygun model seçilmelidir.Yazılım geliştirme süreç modelleri şunlardır:

1. Gelişigüzel Model

Bu süreç modelinde herhangi bir yöntem yoktur. Yazılım tamamen geliştiren kişiye bağlıdır. İleri zamanlarda geliştirilen yazılımı hazırlayan kişi bile anlamakta zorluk çekebilir. Bu yüzden izlenebilirliği ve bakımı çok zordur. Daha çok 1960'lı yıllarda kullanılan bir yöntemdir. Genellikle tek başına yazılım geliştirenler tarafından tercih edilmiştir. Geliştirilen yazılımın programlaması diğer metotlarla geliştirilen yazılımların programlamasına göre basittir.

2. Barok Modeli

Bu modelde yazılım yaşam döngüsünün temel adımları doğrusal bir biçimde takip edilir. Daha çok 1970'li yıllarda kullanılmış bir yöntemdir. Adımlar arası ilişkilerin tanımlı olmadığı bir yöntemdir. Günümüzde pek kullanılmayan bir yöntemdir. Bunun en büyük nedeni ise "Belgeleme" adımının bu modelde ayrı bir adım gibi ele alınıp yazılımın geliştirilmesi ve testinin ardından yapılmasıdır.

3. Çağlayan (Şelale) Modeli

Bu modelde yazılım yaşam döngüsü adımları baştan sona en az bir kez izlenir. İyi tanımlanmış projelerde ve yapımı için az süre gerektiren projelerde tercih edilen bir yöntemdir. Geleneksel model olarak da adlandırılır. Ancak günümüzde pek fazla kullanılmamaktadır. Barok modeline göre "Belgeleme" adımını ayrı bir adım gibi almaz ve yazılımın ürünü olarak ele alır. Ayrıca Barok modelinde olmayan adımlar arası ilişkiler bu modelde tanımlanmıştır. Ancak bu modelde karşılaşılacak problemler vardır. Adımlar arası ilişkilerden dolayı yineleme olabilir. Yazılımın kullanıcıya ulaşma zamanı uzundur. Gereksinimi analizi iyi yapılmadığı takdirde adımlarda yineleme meydana gelir ve bu sebeple maliyet artar.   

4. V Modeli

Bu modelde adından da anlaşılacağı gibi "V" yapısında bir yol izlenir ve adımlar bu şekilde gerçekleştirilir. Bu yol üzerinde sol taraf üretimi sağ taraf ise test işlemini ifade eder. Bu modelde yer alan çıktıları "Kullanıcı Modeli", "Mimari Model" ve "Gerçekleştirim Modeli" adı altında toplayabiliriz. Kullanıcı modelinde geliştirme sürecinin kullanıcı ile olan ilişkileri tanımlanmakta ve sistemin nasıl kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır. Mimari modelde sistem tasarımı ve oluşacak alt sistem ile tüm sistemin sınama işlemlerine ilişkin işlevler ele alınmaktadır.

5. Helezonik (Spiral) Model

Bu modelde risk analizi ön plana çıkmıştır. Yinelemeli artımsal bir yaklaşım vardır. Her döngü bir fazı ifade eder ve doğrudan adım tanımlama gibi bir faz yoktur. Ayrıca prototip yaklaşımı vardır. Bu modelde süreç 4 gruba ayrılır. Bu süreçler planlama, risk analizi, üretim, kullanıcı değerlendirmesidir. Planlama üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirmeyi sağlar. Risk analizi risk seçeneklerinin araştırılması ve risklerin belirlenmesini sağlar. Üretim ara ürünün üretilmesini sağlar. Kullanıcı değerlendirmesi ise ara ürün ile ilgili olarak kullanıcı tarafından yapılan sınama ve değerlendirmelerini ele alır. Bu modelin avantajları vardır. İlki üretim süreci boyunca ara ürün üretme ve üretilen ara ürünün kullanıcı tarafından sınanması temeline dayanır.

6. Evrimsel Model

Bu model ilk tam ölçekli modeldir. Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları). Her adımda üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler. Modelin başarısı ilk evrimin başarısına bağımlıdır. Zor kısımları mevcuttur. Değişiklik denetimi ve konfigürasyon yönetimi bu modelin zorluklarıdır.

7. Artırımsal Model

Bu modelde üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan sayıda işlev içerecek şekilde geliştirilir. Uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir. Örneğin öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama ödevinin 2 haftada bir gelişiminin izlenmesi gibi (bitirme tezleri). Bir taraftan kullanım, diğer taraftan üretim yapılır.

8. Araştırma Tabanlı Model

Bu model yap-at prototipi olarak da bilinir. Araştırma ortamları bütünüyle belirsizlik üzerine çalışan ortamlardır. Yapılacak işlerden edinilecek sonuçlar belirgin değildir. Geliştirilen yazılımlar genellikle sınırlı sayıda kullanılır ve kullanım bittikten sonra işe yaramaz hale gelir ve atılır. Model-zaman-fiyat kestirimi olmadığı için sabit fiyat sözleşmelerinde uygun değildir. Bu model için örnek yazılım projeleri olarak şu örnekleri verebiliriz: en hızlı çalışan asal sayı test programı, en büyük asal sayıyı bulma programı, satranç programı gibi.

Kaynak:http://webbote427.blogcu.com/proje-gelistirmede-surecinde-gelistirme-asamasi/6387264