Yazılım Ekibi Büyüklüğü

SON YORUMLAR

► Kaan çok eziksin
bsg. yazılımdan anlıyorsan bir işe gir.

► İREM
Veri yapıları sınavım var..sınav süresi 30dk ve test..Veri yapılarında bilgili biri ücret karşılığında yardımcı olabilirse çok mutlu olurum..

► Eray
29.8.2020 tarihli telefon numaram ile yaptığım yorum, ÖZEL DERS vermek, konu anlatımı yapmak veya freelancer olarak yazılım projelerinde yazılımcı olarak çalışmak içindir. Ödev yaptırmak, sınava girmek gibi isteklere geri dönüş yapmıyorum.

► Tatar Ramazan
CLASS (Inheritance, abstract, interface, static) Kurallar: 1- Abstract ve interface classlarda new ile obje oluşturulamaz. Bu kural static sınıflar için de geçerlidir. 2- Statik metotlardan yalnızca statik değişken ve metotlar çağırılır. 3- Sınıfın tüm objeleri statik alanın aynı değerini paylaşır. 4- Sınıftan her obje oluştuğunda statik değişken değeri sıfırlanmaz kaldığı yerden devam eder. 5- Statik alana sınıftan obje oluşturmadan direk ulaşılabilir. 6- Statik değişken her zaman bir değere sahiptir. Nümerik değerler için değer atanmadıysa değeri sıfırdır. 7- Virtual metod, abstract ya da static olamaz. 8- Bir metod ya da properties override edilirken tipi değiştirilmez. 9- Türetilen sınıfta metod override edilmemişse ana sınıftaki içerik geçerli olur. 10- Bir interface uygulayan metod public olmalıdır. 11- Static metod abstract, virtual, override olamaz. 12- Properties?ler abstract ya da virtual olabilir. 13- Türetilen sınıf ana sınıftaki tüm abstract metodları uygulamazsa o da abstract olmalıdır. 14- Abstract metod içeren sınıf da abstract olmalı. 15- Abstract metod otomatikman virtual olur. 16- Türetilen sınıf abstract classtaki tüm metodları uygulamalıdır. 17- Virtual metod birden fazla türetilen sınıfta yeniden tanımlanabilir. 18- Bir sınıf birden fazla interface?i aralarına virgül konularak kullanabilir. 19- Interface tek başına hiçbir uygulama sağlamaz. 20- Abstract metod gövde içermez ve ana sınıf tarafından uygulanamaz. 21- Abstract sınıf içinde statik ya da virtual metod tanımlanabilir. 22- Bir interface metod uygulanırken public değilse başına tanımlandığı interface koyulur. 23- Protected tanımlanan field?a sadece türev sınıf içinden erişilir. 24- Fields (alanlar) virtual ya da abstract olamaz. 25- Interface?ler fields içermez. Properties içerebilir. 26- Bir constructor base ile miras alıyorsa hem aldığı mirası hem kendi içindekini uygular. İçi boşsa yalnızca kalıtım aldığını uygular. Miras alırken de derived (türetilen) classtaki parametre değerini esas alır. 27- Interface metod implemente edilirken override yazılmaz. Override virtual ya da abstract metodlar uygulanırken kullanılır.

► World
Hello PIO

► PIO
hello world

► Tatar Ramazan
2009-10 yıllarında millet maaşını yazardı yüksek miktarlar alırlardı şimdi kimse yazmıyor zavallılar sürünüyorlar. Yanlışsam, durumunuz iyiyse çıkın yanlışlayın beni. Az bir kısmınız mutlu olacak diğerleri kıvransın dursun.

► Tatar Ramazan
çok para bayılacaklar osuracaklar, sıçacaklar size zort zort zort...muhahah, puahahah...

► tatminsiz
10.000 tl den aşağı çalışmam.

►
java ve c# ı yalayıp yuttum mssql oracle pl sql ibm db2 biliyorum. projeler yaptım kaç para alcam?

► memnun
Muhasebe bölümünden bilişime geçtim 2 ay geride kaldım şimdi geri muhasebeye nakîl verdim ama bu parayı duyunca çallşmaya başladım

► muhendis
Eskidendi o çok eskiden..mühendisler artık aç..4 yıllık mühendisim aldığım ücret 5000 tl...

► cengiz
Ben de bilmiyorum faidesini...

► orhon
ilk önce sql sonra t-sql

Here is the website inspired me to use it as a guide when I tried to define myself as an engineer candidate a few years ago. It really helped me to work and study feeling in confidence with being on the right way. I suggest this website to whom it may direct her/his to find the right career path. It includes many articles varies from real life experiences to detailed software engineering issues. But the most dignified parts for me are the articles in general and career titles.

Bilgisayar Mühendisleri Portalı

Yazılım Ekibi Büyüklüğü

Yazılım Ekibi Büyüklüğü

Yazılım ekibinin büyüklüğü, ekibin üretkenliğini direk olarak etkileyen başlıca faktördür. Öncelikle belirtmek gerekir ki, ekip içerisindeki eleman sayısı arttıkça elemanlar arası iletişim yollarının da sayısı doğrusal olmayarak artmaktadır. Şekil 1’de, 5 kişilik ekibin kendi içerisindeki 10 iletişim yolu gösterilmiştir. Bu sayı 6’ya çıkarıldığında, iletişim yolu sayısı 15’e çıkmaktadır.

Şekil 1 – İletişim Yolları

Şimdi basit bir hesap yapalım. Her bir bireyin üretkenliğini 50 satır/adam-ay ve her bir iletişim yolunun üretkenliği %20 düşürdüğünü kabul eder isek, 5 kişilik ekibin üretkenliği 5*50–(10*10) ‘den 150 satır/adam-ay olarak ortaya çıkar. Biz ekip üretkenliğini arttırmak amacı ile 1 adam eklersek; ekibin üretkenliği 6*50 – (15*10) ’den 150 satır/adam-ay olarak hesaplanır. Organizasyon bakış açısı ile düşünüldüğünde ekibe adam eklemek fayda sağlamamakla birlikte giderler düşünüldüğünde zarardayız.
Peki bir yazılım geliştirme ekibinin optimum büyüklüğü nedir?
Bu sorunun cevabı “etkili iş gücü” hesabının yorumlanması ile ortaya çıkmaktadır. Şekil 2’de gösterilen eğrinin yorumu her açıdan çok önemlidir.

Şekil 2 – Etkili İş Gücü Eğrisi

Eğrinin maksimuma ulaştığı bölge, geliştirme ekibinin optimum büyüklüğünü göstermektedir. Bu büyüklük 4-5 kişidir. Fakat siz çok büyük projeleri gerçekliyor olabilirsiniz, böyle bir durumda projeyi uygun küçük yazılım birimlerine bölmeniz iyi bir metot olacaktır.
Bir diğer önemli nokta ise, yazılım dünyasının etkili isimlerinden Fred Brooks’un “gecikmiş bir projeye adam eklemek süreyi kısaltmaz aksine uzatır” kuralıdır.
Bu cümleyi değerlendirdiğimizde, sizin ekip yukarıdaki şekilde gösterilen eğrinin sol bölümünde ise yani 4’ten az kişi ile çalışıyor iseniz, projeye adam eklemek üretkenliği olumlu olarak etkileyecektir. Fakat eğrinin sağ tarafında iseniz adam eklemenin faydasını göremezsiniz. Bu yönden Brooks’un kuralı çoğu zaman işlemekte ve doğrudur. Bu tür durumlara düşmemek için proje başlangıcında, sistemi uygun büyüklükte alt yazılım parçalarına bölmemiz gerekmektedir. Geliştirme sürecinizde spiral metodolojisini uyguluyor iseniz, yazılımda 4-5 kişilik ekibin yapabileceği fonksiyonel parçaları (build) tanımlamanız gerekmektedir.

Her konuda görüşlerinizi bana e-posta yolu ile iletebilirsiniz.
Özgür ERALP
2003
www.software-turk.com

Bu makaleyi beğendin mi? Yorumunu Yaz!

Sizden Gelen Yorumlar:

Yorum Yazın