Yazılım Mühendisliği Pratikleri

TAI'de katıldığım bir eğitimde aldığım notlarımı sizinle paylaşmak istiyorum. Bunlar yazılım mühendisliği gerektiren işlerde göz önünde bulundurulması gereken pratiklerdir. Kaliteli bir iş için dikkat edilmesi gerekir.

PRATİKLER

1.Yönetim

• Planlama
• Check-list (Başlamadan önce yapılması gerekenler)
• Görev paylaşımı
• Risklerin tanımlanması
• Başarının ölçülmesi ve değerlendirilmesi
• Süreç yönetimi
• Kayıtlı çalışma

2.Kaynak Yönetimi

• İdeal ekip sayısı 5-7 (Tecrübe olarak söyleniyor)
• Çalışanlara değer verme, adil olma, ödüllendirme
• Eğitim
• Uzmanlaşma
• Etkin iletişim

3.Bütçe Yönetimi

• İşgücü, zaman, yatırım ve maliyetler
• Proje başlamadan önce deneysel kestirimler
• Sürekli izleme ve ölçme

4.Metrik Yönetimi

• Nokta atışı sayısal değerler
• Amaç, başarımı ölçmek ve riskleri tanımlamak
• Efor metrikleri
• Geliştirilen kodun metrikleri
• Gereksinim metrikleri
• Değişiklik istekleri metrikleri
• Hata metrikleri
• Test metrikleri

5.Disiplin*

• En önemlisi. Yetki ve sorumluluklar belli olmalı.
• Saha kurallarını koymak ve kurum kültürü (Birçok toplantının verimsiz geçmesinin nedeni saha kurallarının tam konulamaması)
• Son sözü söylememek projeye zarar verir. Hayır demeyi herkes bilmeli. Net olunmalı.
• Sonuç odaklı olunmalı.

6.Gereksinim Yönetimi

• Gereksinimlerin belirlenmesi
• Gereksinimlerin herkesce anlaşılması
• Gereksinim belirlemenin son aşaması olarak gereksinimlerin dondurulması.

7.Sistem Mühendisliği

• İç içe çalışma (Geliştiriciler ile)
• Sistem mimarisine hakim olma
• Sistem yazılım uyumunun sağlanması

8.Arayüz Tanımlama ve Denetleme

• Gereksinim analizi bitmeden önce tüm dış arayüzler tanımlanmalı
• Çökmeler genellikle arayüzlerde olur. Genellikle iç arayüzlerde değil dış arayüzlerde hata çıkar. Bunun nedeni ekipler arası iletişim eksikliğidir.

9.Tasarım

• Standartlara hakimiyet (178B, IEEE12207)
• Planlara uyum
• Sistem ve yazılım geliştirilmeye açık olmalı
• Bir arayüzün başka bir arayüzle bağlantısı mümkün olduğunca az olmalı
• Sadelik ve basitlik önemli
• İnsan makine arayüz(GUI) tasarımına dikkat edilmeli. (Bir istatistiğe göre burada harcanan efor projeye harcanan eforun %47’si kadarmış)

10.Kodlama

• Anlaşılabilir
• Kısa yordamlar
• Açıklamalar
• Sık sık yedekleme
• Hatalara teslim olmayın. Hatalar tecrübeleri arttırır.

11.Test

• Projenin kritik bileşenleri fonksiyonel olarak test edilmeli (White-Box)
• Aşırı yüklemelerle test edilmeli (Aşırı yükleme testi)
• Projenin sonuna doğru, en gerçekçi senaryolarla denenmeli

12.Hata ayıklama (Debugging)

• Hatalar birer birer ayıklanmalı

UML Diyagramları

YAPISAL DİYAGRAMLAR

  Sınıf (Class) diyagramı: Class odaklı tasarımlarda kullanılır. Sınıfların özelliklerini birbirleri arasındaki ilişkiyi göstermede kullanılır. Özellikle nesne yönelimli projelerde tercih edilirler. Kodlamada kolaylık sağlarlar.

  Nesne (Object) diyagramı: Bir nesne(object) sınıfın (class) bir örneğidir. Bu tür diyagramlarda sınıfın yerine gerçek nesneler kullanılır. Bu sayede modellenen sistemin yapısının belirli bir andaki bütün ya da kısmi  görünüşü tarif edilir.

  Bileşen (Component) diyagramı: Bir yazılım projesi birden fazla bileşene yani component’e ayrılarak programcılar arasında paylaştırılabilir. Bu component’ler programcılar tarafından birbirlerinden bağımsız geliştirilirler ve en sonunda da birleştirilirler. Bu birleştirme işlemi component diyagramındaki gibi olmalıdır.

  Paket (Package) diyagramı, bir sistemin hangi mantıksal gruplara bölündüğünü ve bu gruplar arasındaki bağımlılıkları betimler. Fazla detaya inmeden genel hatlarıyla modelleme yapılır, bu diyagram sistemin temel mantığı oluşturulurken kullanılmalıdır.

  Dağılım (Deployment) diyagramı, sistemde kullanılan donanımları, bu donanımların içinde yer alan bileşenleri ve bu bileşenlerin arasındaki bağlantıları gösterir.

  

  Birleşik Yapı (Composite Structure) diyagramı: bir sınıfın iç yapısını ve bu yapının mümkün kıldığı iletişimleri tarif eder. Bu daha detay bir diyagramdır. Deneyimsiz bir programcıya bu diyagram deneyimli bir programcı tarafından hazırlanıp bir yol haritası olması için verilebilir.

DAVRANIŞ DİYAGRAMLARI

Kullanım Senaryosu (Use-Case) diyagramı: Aktörler vardır. Bu aktörlerin yaptıkları ve yapamadıkları şeyler bu diyagramla ifade edilir. Bu diyagramı oluşturmanın faydaları:

·         Müşteri ile geliştiriciler arasında iletişimi sağlamak

·         Sistemin sınırlarını belirlemek

·         User Guide oluşturmada yardımcı olmak

  Durum (Statechart) diyagramı: Bir nesnenin sahip olacağı tüm durumların modellendiği diyagramdır. Nesneler çeşitli durumlarda bulunabilirler ve birtakım olaylar sonucunda bir durumdan başka bir duruma geçebilirler ve bu geçiş esnasında başka olayların meydana gelmesini tetikleyebilirler. Tüm bu ilişkiler bu durum diyagramıyla ifade edilirler. Daha çok sistemin genel işleyişinde mantıksal bir hata yapılmaması için kullanılan diyagramlardır.

 Faaliyet (Activity) diyagramı: Modellenen sistemdeki iş akışını adım adım gösterir. Kapsamlı bir şekilde komut akışını tarif eder. En önemli özelliği paralel davranışları desteklemesidir. Multithreaded uygulamalar geliştirirken uygulamanın algoritmik mantığı bu diyagramla gösterilebilmektedir. Karmaşık algoritmalarda da tercih edilebilecek bir diyagramdır. Bu diyagramlar sayesinde gereksiz yere ardışık yapılan işlemler rahatlıkla görülebilir ve bunların paralel yapılması sağlanabilir.

ETKİLEŞİM DİYAGRAMLARI

 Sıralama (Sequence) diyagramı: Bir uygulamada nesnelerin birbirleri ile olan ilişkisi zamana göre değişiyorsa, statik bir ilişkiden bahsetmek mümkün değilse, ilişki yapısı dinamikse bu diyagramlar kullanılır. Nesnelerin yaşam süreleri de bu diyagramla gösterilir.

 İletişim (Communication) diyagramı: Sınıf, Sıralama ve Kullanım Senaryoları diyagramlarındaki bilgileri kullanarak sistemin hem statik yapısını hem de dinamik davranışını gösterir. Bu üç diyagramın üzerinde, onları kapsayıcı nitelikte bir diyagramdır ve sistemi daha genel hatlarıyla ortaya koymada kullanılır.

 Etkileşime Bakış (Interaction Overview) diyagramı: Farklı etkileşim diyagramları kullanarak, bunlar arasındaki komut akışını gösterir. Bir başka deyişle, elemanları etkileşim diyagramları olan faaliyet diyagramlarıdır.

  Zaman Akış (Timing) diyagramı: Odağın zaman kısıtlamaları olduğu etkileşim diyagramıdır. Nesnelerin bir zaman akışı içerisinde birbirleri ile etkileşimini göstermede kullanılır.

 KAYNAKLAR

1-) UML Weekend Crash Course, Thomas A. Pender, Wiley Publishing Inc., 2002.

2-) UML Bible, Tom Pender, John Wiley, 2003.

3-) UML Distilled: A Brief Guide to the Standard Object Modeling Language, Martin Fowler, Kendall Scott, Addison Wesley, 1999.

4-) The Elements of UML Style, Scott W. Ambler, Cambridge University, 2003.

5-) Visual Modeling with Rational Rose 2000 and UML, Terry Quatrani, Addison Wesley,1999.

6-) The Object Primer 3rd Edition: Agile Model Driven Development with UML2, Scott W. Ambler, 2003.

7-) UML in a Nutshell , Sinan Si Alhir, O’Reilly, 1998.

8-) UML 2 for Dummies, Michael Jesse Chonoles and James A. Schardt, Hungry Minds, 2003.

9-) www.adtmag.com/article.asp?id=2656

10-) www.visualuml.com/whitepapers/UML%20collaboration%20diagrams.pdf


Konuyla ilgili olarak aşağıdaki yazılarıma da bakabilirsiniz:

• UML Kullanmanın Avantajları
• UML Nedir?

UML Kullanmanın Avantajları

UML büyük projelerde kesinlikle kullanılması gereken bir modelleme dilidir.  

(Bakın: UML Nedir?) 

Bu dilin oldukça kapsamlı olduğunu ve bir yazılım projesinde gerekecek her modellemeyi bünyesinde barındırdığını ayrıca belirtmek isterim.  UML kullanmanın faydalarını aşağıdaki gibi sıralayabiliriz:

• Tasarım ve analiz UML ile yapıldıktan sonra ve mantıksal hatalar ayıklandıktan sonra kodlama işi oldukça kolaylaşacaktır.

• Takım çalışması yapmak kolaylaşacaktır.

• Ekipte meydana gelecek değişiklikte yeni gelenlere projenin anlatılması daha rahat olacaktır.

• Proje başkalarına devredilirken diyagramlar devralanın projeyi rahatlıkla anlamasını sağlayacaktır.

• Olası tüm senaryolar baştan belirlendiği için programın tutarlılığı artar.

• Tekrar kullanılabilecek kodların sayısı artar. Bu da maliyeti düşürür. 

Bir sonraki yazımda UML diyagramlarından da bahsetmek istiyorum, özellikle de favori diyagramım olan user case diyagramlarından. Projelerinizde UML kullanırsanız asla pişman olmazsınız, ancak dikkat etmeniz gereken bir nokta var: UML kullanmış olmak için kullanılmamalıdır, sağlayacağı fayda harcatacağı emekten daha az olmamalıdır.  Örneğin çok küçük bir yazılım projesinde gereksiz diyagramlar kullanıldığında bu vakit ve emek kaybına yol açabilir. Amaç kaliteli yazılım geliştirmektir, UML ise sadece araçtır, bunu unutmayalım.