Yazılım projeleri sonuç olarak bireyler tarafından geliştirildikleri için
bireylerin yetenek ve çalışma disiplinleri bir projenin başarısında
doğrudan etkilidir.Yazılım mühendisliği alanında bugüne kadar tasarım ,
test ve yönetim alanlarında bir çok çalışmalar yapılmakla beraber yazılım
geliştirmede bireysel disiplinin üzerine fazla
gidilmemiştir.Bu alandaki eksiklik ise Watt Humprey ‘ in PSP(Personal
Software Process) ve TSP(Team Software Process)
konularındaki çalışmaları ile giderilmiştir. PSP bireysel TSP ise takım içinde
yer alan disiplini belirtir. Açıkça anlaşılabileceği gibi TSP PSP ‘ yi kapsar
fakat şu gerçek unutulmamalı ki takımlar bireylerden oluşur ve PSP nin önemi
buradan anlaşılmaktadır.
Takım Çalışmasını Başarıya Eriştirmek
Takım iki yada daha fazla sayıdaki bireyin oluşturduğu , ortak bir hedef için ve
birbirleri ile ilişkili görevleri bulunan gruba verilen isimdir. Günümüzün
yazılım projeleri tek kişi için fazlasıyla büyük ve karışıktır.Bir yazılım
projesi için takım çalışması çok önemlidir çünkü tasarım , kodlama ,
gözden geçirme ,test,konfigurasyon yönetimini tek kişinin yapması
düşünülemez.Takım oyuncuları arasındaki iletişim sorunlarını ortadan kaldıran
organizasyonlar görevlerini başarılı olarak gerçekleştirebilir.Bu tür
organizasyonlar takım ruhunu çalışanlarına aşılayabilmiş demektir. Bir takımın
görevlerini yerine getirebilmesi için , içinde bulunduğu organizasyonun
önceden tanımlı süreçlerinin olması gerekir. Böylece takım üyeleri hangi
kurallar ve standartlar ile çalışacaklarını bilirler.
Alttaki tabloda bir takımın başarısını etkileyen faktörler yer
almaktadır.Farklı takım türleri olmakla beraber hepsinde ortak olan özellik “bireysel
yetenekler ve bu yeteneklerin geliştirilmesi ve en uygun şeklide kullanılması
”dır.
| Başarı Faktörü |
Yazılım Geliştirme |
Amerikan Futbolu |
Askeriye |
| Bireysel Yetenek |
Kalıtımları kullanabilme, Zeka, Dil yetenekleri |
Hız,dayanıklılık,büyüklük,çeviklik |
Dayanıklılık,tahammül,zeka,görme duyusu |
| Bireysel Temeller |
Yeniden inceleme, Tasarım.. |
Bloklama, atak ,pas |
Bomba atma nişancılık |
| Ayrıntılı Plan |
Proje planı |
Oyunlar(blok,pas yöntemleri) |
Hava görevi emirleri |
| Takım Çalışması |
Haftalık proje toplantıları |
Periyodik toplantılar,oyun planları |
Birim çalışmaları |
| Tanımlı Süreçler |
Kurumsal yazılım süreçleri |
Haftalık antremanlar |
Birim çalışmaları |
| Takımı Oluşturma |
Projenin başlaması |
Bahar kampları |
Birim çalışmaları |
2. Bireysel başarıyı sağlamak için geliştirilen teknolojiler
Bireysel disiplinin gelişmesinde iki yöntem vardır.Birisi genel amaçlı
olan diğeri ise yazılım geliştirmeye yönelik olandır.
Franklin Covey sistemi genel amaçlı olandır. Bu sistemin amacı
da bireysel disiplini geliştirmektir fakat teknik konuları içermez. Daha çok
kitaplar , eğitimler , önceliklerin tanımı ve zaman yönetimi gibi temel
kavramlar ile ilgilidir.
Watts Humprey’ in PSP yöntemi ise tamamen yazılım mühendisliğini ilgilendiren
teknik konulara yönelik çözümler ortaya koyar.
3. PSP
İlk olarak şunu bilmek gerekir. PSP giriş ve çıkış kriterleri , süreç hedefleri
, belirlenen hedefleri olan bir süreç değildir. PSP yi anlamak için üzerinde
geliştirilen fikirleri , kalite ve süreç geliştirme modelleri hakkında bilgi
sahibi olmak gerekir. Zamanla birlikte PSP nin bir süreçten çok bir felsefe
barındırdığı gözlemlenmiştir.
3.1. PSP Tarihçesi
PSP ’ nin temel amacı birey olarak program geliştiricinin yeteneklerini
geliştirerek yüksek kalitede yazılım ürünleri oluşturmasına yardımcı olmaktır.
Yazılım geliştirme sürecine odaklanarak bazı alışkanlıkları aşılmaya
çalışır. Anlaşılacağı üzere PSP yeni bir teknoloji olup halen gelişmektedir.
Bu teknik Watts Humprey tarafından CMM çalışmaları tarafından
temelleri atılıp geliştirimeye başlanmıştır.
Temel olarak , CMM ’ in küçük şirketler tarafından uygulanamadığını
gözlemleyen Watts CMM Seviye 5 ’ i optimize ederek
mümkün olan en küçük, takım yani birey için yazılım
geliştirme kalite sürecini tanımlaya gitmiştir. 1995 yılından beri ise SEI
tarafından bu konu üzerinden danışmanlık ve eğitim hizmetleri verilmektedir.
| PSP Süreç Bileşenleri |
Amaç |
Örnek |
| Kayıtlar |
Süreçlerin ölçülebilmesi |
Zaman kaydı , hata kaydı , Sorunların takibi |
| Talimatlar |
Süreçleri tamamlamak için tanımlanmış direktifler (kayıtlar şablonlar,formlar) |
Her şablon ve form ile ilgili talimatlar bulunmaktadır |
| Skriptler |
Bir sürecin tamamlanabilmesi için gerekli adımlar |
Her PSP sürecine ilişkinplanlama ,geliştirme ve inceleme scriptleri vardır |
| Formlar ve Şablonlar |
Verileri kaydetmek ve kullanmak için hazırlanmış
standart mekanizmalar.Bu şekilde proje tamamlandıktan
sonra projenin incelenebilmesi için bu verilere
kolaylıkla başvurmak mümkündür. |
7 sürecin hepsinde de bir özet doküman vardır bunlara döngü formları denir. Şablonlardan bazıları ise Rapor şablonu , test şablonu , görev şablonları , zamanlama şablonlarıdır. |
| Standartlar |
Belli işleri yapmamızda rehberlik eden kurallardır. |
Hata türü standardı , kodlama standardı(çoğu zaman göz ardı ederiz) ve LOC(line of code standardı) Sayma standardı |
| CheckList |
Bir süreci yolunda gitmesi için zorlayan mekanizmadır. |
Tasarım ve kodun gözden geçirilmesi checklisti |
PSP Süreci Bileşenleri
3.1 PSP ’ nin Kapsamı
En basit tanımıyla PSP bireyin yazılımı nasıl geliştirmesi gerektiğini tanınlar.
PSP yazılım mühendisliğinin temellerini kapsar , kodlamadan önce tasarım ve gözden geçirme ,
yüksek seviyeli tasarım gibi . Görevin bir kişiye atanmasından tutun da unit test
safhasına kadar her evreyi kapsar. Yazılımın geliştirme evrelerinin dışında kalan fazlar ise
PSP kapsamının da dışında kalır. Aşağıdaki animasyonda PSP nin kapsamı açıkça görülmektedir.
3.2 PSP Süreç Bileşenleri
Yazılım kalite sistemlerinin genelinde olduğu gibi PSP de uygulama olarak dokümantasyona dayanır.
Standart PSP prosedürü birbirleri ile hiyerarşi içinde bulunan 7 katmandan oluşur ve toplam 31 script ,
8 özet formu , 3 kayıt defteri, 9 şablon , 20 tane talimat , 2 standart ve 4 tane de kontrol listesi içerir.
İlk etapta bu denli çok sayıdaki dokümantasyonkorkutucu gözükse de bu kişiden kişiye özelleştirilebilir.
Fakat uzun vadede uygulayanının yararına olacağı kesindir.
3.3 PSP Süreç Fazları
PSP de geliştirme fazları ve geliştirme aktiviteleri vardır. Bu ikisinin ayrımına varabilmek çok önemlidir.
PSP evreleri ; planlama , yüksek seviyeli bir tasarım , bu tasarımın gözden geçirilmesi , kodun tasarımı ,
kodlama , kodların gözden geçirilmesi , derleme , test ve son incelemedir (standartta burası otopsi olarak adlandırılır).
Bütün bu evreler bir sıra halindedir. Yani bir önceki evreye geri dönmemeniz gerekir.(Tasarımın önemi burada açıkca anlaşılıyor)
Geliştirme evreleri mühendisin ne yaptığı ile ilgilenir. Eğer bir hata yok ise geliştirme evresi ve aktivitesi beraber ilerler.
Fakat hata ile karşılaşınca o anki aktivite içerisinde bunun düzeltilmesi gerekir. Özetlemek gerekirse temelde 3 tane PSP evresi vardır.
Bunlar planlama , geliştirme ve otopsidir. Otopsi fazında sürecin gidişatına bakılarak ilerisi için planlama ve iyileştirmeler yapılır.
Geliştirme fazı ise teknik konularla uğraşılan evredir. Bu evre tasarım ve test olarak ayrılır çünkü yazılımın yönetimi ve kontrolü için
hayati önem taşır aksi takdirde siz projeyi değil proje sizi yönetir.
3.4 PSP Süreçlerinin Ölçülmesi
Bu son bölümde ise PSP süreçlerinin nasıl ölçülebileceğini ve bu ölçümlerin bize nasıl bir fayda getireceğini üzerinde duracağız.
Gayet açıktır ki ölçülemeyen bir süreç fazla bir şey ifade etmez. PSP bunu yapabilmemiz için alternatifler sunar.
En çok kullanılanı ise zaman , hata ve boyut ölçümleridir.
Zaman ölçümü time log da tutulur ve geliştirme sürecinin süresini dakika olarak kayıt etmemizi ister.
Daha sonra bu metriklere bakarak proje zamanlaması ,üretkenliğimizin ölçümü ve ne kadar etkin olduğumuz konusundabilgi verir.
Hatalar defect log da tutulur. Burada saptanan hatanın açıklaması , hangi geliştirme evresinde görüldüğü , ve hangisinde ortadan kaldırıldığı ,
bunu yapmak için harcanan süre ve eğer bu hata başka bir hatayı düzeltirken yapılmışsa bununla ilgili not (çoğu zamanda başımıza gelen bu değil midir ? )
kayıdı tutulur.Defect log da tür ve açıklama alanları daha sonra gözden geçirme evresinde kullanılmak amacıyla tutulur. PSP ‘ nin buradaki amacı
bireyin ne tür hataları yapmaya elverişli olduğunu ve buna karşı önlem/önlemler almasını sağlamaktır (bunun için bir önlemler checklist i hazırlanabilir).
Hatanın düzeltilmesi için harcanan zaman ise tekrarlanan iş anlamına gelir.Bu hatanın hangi fazda yapıldığı ve hangisinde düzeltildiği ise evrelerin
hataya ne oranla açık oldukları hakkında bilgi verir. Bu oran ve hataları yönetebilme yeteneği ise ortaya çıkardığımız yazılım ürünlerinin kalitesi ile
doğru orantılı olacaktır.
Boyut ölçümü ise hatalarımızın ve üretkenliğimizin normalizasyonunu sağlamak için gerekli olup birimi LOC (kodun satır sayısı) dur.
LOC sayısına bakarak projenin gidişatı hakkında genel bilgiye sahip olabilir ve ilerisi için tahminler yapabiliriz.
Mesela geliştirme evresinin hemen başında LOC sayısı beklediğimizden çok fazla ise tasarımı tekrar gözden geçirmek gerekebilir.
Çünkü ne kadar çok kod o kadar çok hata olasılığı anlamına gelir ve buda tekrarlanan çalışma demektir.
3.5 Sonuç
Son olarak , hızla gelişen günümüz yazılım dünyasında daha kaliteli ürünler meydana getirmek ve rekabeti sürdürebilmek
adına yapılan bir çok çalışma , getirilen bir çok standart olduğunu yazılım mühendisliğine ilgi duyan herkes bilmektedir.
Fakat bunların çoğunda birey ikinci planda yer alır yada adı bile anılmaz. İşte bu noktada PSP devreye giriyor.
Yukarıda adı geçen metotlar uygulandığı takdirde uzun vadede , yapılan hataların azalacağı , bunların kontrol altına alınacağı ve
takımda rolü olan herkesin kendi metriklerine bakarak hangi yöne ağırlık vermeleri gerektiğini belirlemeleri kaçınılmaz olacaktır.
Kaynaklar :Disciplined Software Development,A review of Personal Software
Process and Team Software Process , STSC
Makale:
Yazılım Geliştirmede Disiplin ve PSP Yöntemi Yazılım Mühendisliği Tuğrul Güçlü
|