Transcript 12. Hafta

1
KONU BAŞLIKLARI
Süreçlere Yönelik Öneriler
Tasarım Geliştirmeye Yönelik
Öneriler
Niteliği Arttırmak İçin Pratik
Öneriler
Toplantı Kuralları
2
Amacımız, uygulama alanının
özelliklerine bağlı olarak büyük
projelerde nitelik, maliyet,
müşteri memnuniyeti gibi
önemli ölçütleri sağlayabilmeniz
için pratikte uygulanabilir bir
dayanak sağlamaktır.
3
Gerek maddi gerekse insan
kaynaklarının en uygun şekilde
kullanımı çok büyük önem
taşır. Bunların hiç biri tek
başına yeterli olmayacaktır.
Örneğin: yalnızca çok başarılı
insanları bir araya toplayarak
projelerin iyi sonlanması
beklenemez.
4
A.Proje Yönetimi
Yazılımın boyut,iş gücü ve
takvim kestirimlerinin
yapılması.
Üst yönetimin onayının
alınması sonrasında projenin
başlatılması.
Proje yöneticisinin resmi
olarak atanması.
5
Projede tamamlanması gereken iş paketlerinin
oluşturulması
Proje ekibinde yer almaya aday çalışanların
özelliklerinin araştırılması ve belirlenmesi
Seçilen personeli proje iş grubuna atayarak
proje ekibinin oluşturulması.
Proje risklerinin tanımlanması ve izlenmesi.
İş paketleri için zaman ve kaynak bilgileri
girerek proje takviminin oluşturulması.
6
Projenin takvim,maliyet,nitelik
açılarından başarımını izlemek için belirli
ölçütler seçilmesi ve hedeflerin
belirlenmesi.
Proje süresince üretilecek düzenleşim
öğelerinin(belgeler,modüller)
tanımlanması ve izlenmesi
Onaylı proje takvimindeki iş paketlerinin
proje ekibindeki çalışanlara atanması.
7
Personelin proje kapsamında yapılan işler
için harcadığı zamanı bildirmesi
Geliştirme etkinlikleri sırasında
düzenleşim ögelerinde fark edilen yazılım
ve belge sorunlarının
tanımlanması,belirlenen sorunların
yönetim onayıyla düzeltilmesi ve bu
düzeltmenin doğrulanması.
8
Tanımlanan yazılım
birimleri,yapılan testler ve gözden
geçirmeler ile ilgili kayıtların
tutulması.
Projenin süreçlere uygun
yürütüldüğünü belirlemek amacıyla
denetlenmesi.
Proje takviminin, düzenleşim
ögelerinin ve diğer proje
bileşenlerinin gerektiğinde
güncellenmesi.
9
B.İnsan Kaynakları Planlaması
Personel yönetimi için bazı önerileri şu
şekilde sıralayabiliriz:
1. İyi bir örgütlenme için;
a)Yönetim personelinin konumları
oluşturulmalıdır.
b)Yetki ve sorumluluklar iyi tanımlanmalıdır.
c)Bu konumlarda proje boyunca sabit olarak
kalacak eleman bulunmalıdır.
10
2. Proje personelinin uyumu
çok önemlidir.
3. Proje yöneticisi tüm ekibine
kendilerini önemli
hissettirmeli aynı zamanda da
lider olduğunu göstermelidir.
11
4. Proje içinde aynı işle uğraşan
ekipler 5-7 kişiden
oluşmalıdır.Daha fazlası için
sorumluluklar ve yetkiler
bölünmelidir.
5. Proje yöneticisi planladığı
işlere personel ataması yaparken
adil olmalıdır
12
6. Personele her türlü teknik destek
sağlanmalıdır.
7. Çalışmalar personeli yıldırmamalı
,karşılıksız fazla mesai yaptırılmamalı ve
başarılı personel ödüllendirilmelidir.
8. Proje planları herkes tarafından
erişebilir olmalıdır.
9. Projeye yeni katılan personel için
proje içi eğitimler uygulanmalıdır.
13
10. Projede çalışan personel genel
olarak dikkate alınmalı yalnızca o
proje düşünülerek öldüresiye
çalıştırılmamalıdır.
11. Haberleşme ortamı proje için
son derece önemlidir.
12. Proje personelinin yazılım
teknolojilerinin değişik alanlarında
uzmanlaşmış olması önemlidir.
14
3.Maliyet Kestirimi ve Planlama
Maliyet ve öz kaynakların etkin bir
şekilde kullanılması için şu önerileri
sıralayabiliriz:
1. Proje maliyeti ve zaman planlaması
deneysel verilerle işe başlamadan
kestirilmeye çalışılır.
2. İlk yapılan yazılımla ilgili kestirimler
risk olarak görülür.Zamanla
yenilenmelidir.
15
3. Tüm kestirimler bir maliyet modeli ile
doğrulanmalıdır.
4. İşin ayrıştırmasının alt düzeylerinde
bulunan her bir iş için maliyet kestirimi
yapılmalıdır.
16
5. Tüm maliyet kestirimleri ve
planlamalar işe başlamadan önce
proje yönetimi tarafından
onaylanmalıdır.
6. Genel maliyet kestirimi işe
başlamadan önce
yapılmalıdır.Daha sonra bu
projenin başarımı için bir gereç
olarak kullanılabilir.
17
7. Yazılım maliyet kestirimi
geliştiricinin daha önceki
deneyimlerini ve uygulama alanında
yaygın olan bazı standartları dikkate
alarak hesaplanmalıdır.
8. Tüm yazılım maliyetleri proje
planındaki ayrıntılı yazılım işlerine
göre tanımlanarak hesaplanmalı ve
buna göre izlenmelidir.
18
4.Metrik Kullanımı
Metrik kullanımına ilişkin önerilerimiz
şunlardır:
Her türlü metrik tanımı uygulama alanını
ve sınırlarını içerecek şekilde açıklanmalı
,sayısal değerlere oturtulmalıdır.
Toplanamayacak verilere dayanan
metrikler kullanılmamalıdır.
Tüm projenin yaşam döngüsü boyunca
tanımlanan metriklerin tanımlanması,
incelenmesi ve gerekli yerlere rapor edilerek
geri besleme sağlaması için ekip içinde
19
sorumluluklar tanımlanmalıdır.
Metrik uygulaması süreklilikle
yapılmalıdır.
Proje planı hazırlanırken
metriklerden yararlanılmalıdır.
Metrikler geniş kapsamlı
olmalıdır.
Toplanan veriler ve
değerlendirmeler proje ekibinin
rahatlıkla ulaşabildiği güvenli bir
20
platformda saklanmalıdır.
5.Nitelik Hedeflerinin İzlenmesi
Sistem hatalarını geliştirme sürecinin en
erken zamanlarında bulabilmek ve
giderebilmek için şu önerileri sunuyoruz :
1. Proje yöneticileri hataların en kısa
zamanda bulunması ve giderilebilmesi için
uygun yöntemler geliştirmelidirler.
2. Denetimler taviz verilemeden
21
uygulanmalıdır.
3. Uygulamalar sonucunda ,sistemde
bulunmuş hata sayısı, yakalanamayan hata
sayısı,hatayı ortadan kaldırmadaki etkinlik
gibi metrikler toplanmalıdır.
4. Müşteri isteklerinin değişmesi nedeniyle
değişiklik yapılması gereken durumlarda
nitelik hedefleri de tekrar görüşümelidir.
5. Nitelik hedeflerine uygunluk, geliştirme
sırasında düzenli olarak müşteriye
bildirilmeli,teslim sırasında risk görülen
durumlar açıklanmalıdır.
22
6.Disiplinin Sağlanması
Hangi sektör olursa olsun
etkinliklerde mutlaka belirli bir
disiplin oluşturulması gerekir.Bunun
için sunulan öneriler:
Proje Yöneticisinin yetkileri en üst
düzey otorite tarafından
tanımlanmalıdır.
Teknik
kararlar
yapılan
tartışmalar
23
sonucunda kesin olarak verilmelidir.
Tüm personel işletme
yönetiminin koyduğu yönetsel
kararlara uymalıdır.
Tüm bu disipline rağmen biraz
esneklik her zaman olmalıdır.
Geliştirme ve test ortamında
kişisel yazılımlar
bulunmamalıdır.
İletişim ortam ve cihazları belirli
24
kurallara göre kullanılmalıdır.
25
Yazılım geliştirme sürecinin başarısı
için yazılım isterleri çözümlemenin
doğru yapılması son derece önemlidir.
Bir yazılım ne kadar iyi tasarlanırsa ya
da geliştirilirse geliştirilsin müşteri (ya
da son kullanıcı) ihtiyaçlarını
karşılamıyorsa başarılı sayılamaz.
26
Yazılım isterlerinin çözümlenmesi
aşamasında müşterinin yazılımdan ne
beklediği ayrıntılı olarak belirlenir,
gereksinimler açığa çıkarılır, yazılım
isterleri modellenir ve tanımlanarak
tasarım aşamasına geçilir.
Yazılım isterlerinin çözümlenmesi aşaması
müşteri ve geliştirme grubu arasında ciddi
bir işbirliği gerektirir.
27
Çözümleme aşaması bu iş için yeterince
deneyime sahip olan kişilerce yapılmalıdır. Bu
kişiler çözümleyici ya da gereksinim mühendisi
olarak adlandırılır.
1. Problemin Anlaşılması: Bu aşamada problem
derinlemesine incelenerek problemin ne
olduğu ve çözüm için yazılımın kapsamının ne
olacağı belirlenir. Problemi iyi anlamak
problemin yarısını çözmek demektir.
28
2. Problemin Çözümlenmesi: İlk aşamada
toplanan bilgilere göre, sistemi etkileyen
giriş/çıkış etkinlikleri ve kısıtlamaları dikkate
alınarak yazılım işlevleri tanımlanır. Yazılımın ne
yapması gerektiği bu aşamada ortaya konulur.
3. Modelleme: Sistemin çalışma şekli, veri akışı,
işlevsellik gibi parametreleri daha iyi
anlayabilmek için modeller yaratılır. Bu işlem
kağıt üzerinde çizimlerle yapılabileceği gibi
prototipler de kullanılabilir.
29
4. Belirtim: Bu aşamada kullanıcının sistemi nasıl
kullanacağını ortaya koyan taslak bir kullanım
kılavuzu hazırlanır.Temel işlevler, kısıtlar,
çalışma şekilleri, ara yüzler, başarım ölçütleri,
doğrulama ve geçerleme yöntemleri tanımlanır.
5. Gözden Geçirme: Çözümleme aşaması sonunda
ortaya çıkan belgeler müşteri ile birlikte gözden
geçirilir ve eğer gerekli görülürse güncelleme ya da
düzeltmeler yapılır.
30
Büyük ölçekli projelerde isterler genellikle
birkaç aşamada düşünülür.
1.Düzey 1: Uygulama Alanı İsterleri: Müşteri
görüşmeleri, yazılımın kullanılacağı ortamın
ve benzer uygulamaların incelenmesi
sonucunda temel gereksinimler çıkarılır ve
müşterinin onayına sunulur.
31
1. Düzey 2: Kullanıcı İsterleri: Bu aşamada sistemi
doğrudan kullanacak olan kullanıcıların
beklentileri, istekleri alınır, kullanıcı ara yüzleri
ve temel bileşenler ortaya konulur.
2. Düzey 3: İşlevsel İsterler: Bu aşamada
geliştirilecek sistem bir bütün olarak
düşünülerek işletim kuralları ve süreç yönetimi
ile ilgili ayrıntılar tam olarak ortaya konulur.
32
Sistem isterleri belgesi hazırlanırken
aşağıdaki sınıflardan uygun olanlar bu teknik
belgeye dahil edilir.
• İşlevsel Özellikler: Veri işleme özellikleri,
işlem hızı ve kapasitesi, hatayla baş edebilme
gibi.
• Güvenlik: Kesintisiz kullanabilme, erişim
güvenliği, veri güvenliği gibi.
33
• Kullanım kolaylığı: Kullanıcı dostu ara yüzler,
öğrenme kolaylığı, uygun kullanım kılavuzları
gibi.
• Diğer yazılımlar ile iletişim,
• Bakım kolaylığı, taşınabilirlik,
• Teknik belgeleme, veri yedekleme ve kurtarma,
• Geliştirme dili ve platformu,
• Uygunluk: Teknik şartnameler, standartlar, yasa
ve yönetmelikler gibi.
34
35
 Tasarım sürecinin tüm etkinlikleri Yazılım
Geliştirme Planı’nda belirtilen yöntemlere göre
yapılmalıdır.
 Ortaya çıkan ürünün özelliklerinin doğrulanması
için testler yapılması tasarım standartlarının bir
parçası olarak değerlendirilmelidir.
İzlenebilirlik, tasarım, gerçekleştirim ve test
sırasında devam ettirilebilmelidir.
 Her türlü tasarım düzenleşim yönetim sistemine
girmeden önce yapısal bir incelemeden
geçirilmelidir.
36
 Artımlı geliştirme modeli kullanıldığı
taktirde tasarım da artımlı olarak
yapılabilir. Ancak düzenleşim yönetim
sisteminin bu yapıya uygun destek vermesi
gereklidir.
 Var olan yazılımın tekrar kullanımı
planlandığı taktirde sistem ve yazılım
mimarisi tasarımı uygun şekilde
yapılmalıdır.
 Sistem ve yazılım mimarileri üzerinde
Yazılım Geliştirme Planı’nda belirtildiği
şekilde doğrulama işlemi uygulanmalıdır.
37
Tasarımcıya Kendi Deneyimlerini
Geliştirmesi İçin Öneriler
• 1. Yapmak istediğiniz şeyin ne olduğunu
önceden tam olarak belirleyiniz.
• 2. Amaçlarınız açık ve somut olmasına dikkat
edin.
• 3. Sosyolojik problemlere teknolojik açıdan
yaklaşmayınız.
• 4. Var olan sistemlerden esinlenerek başlangıç
noktası oluşturacak bir model belirleyiniz.
• 5. Tasarımı esneklik, geliştirme, taşıma ve tekrar
kullanım özelliklerini karşılaştırabilecek şekilde
yapın.
38
• 6. Tekrar kullanım yazılım parçalarını
belgeleri ile birlikte kullanıma sunulacak
şekilde hazırlayın.
• 7. Ayrıntılı düşünme çabalarınızı tüm yazılımın
değil de onu oluşturan yazılım birimlerinin
tasarımı üzerine yoğunlaştırın.
• 8. Bir arayüzün başka arayüzlere bağlılığını en
aza indirin.
• 9. Arayüzleri , gereksinimi karşılamaya
yetecek en az miktarda bilgi sağlayacak şekilde
sağlayın.
39
• 10. Tasarımı ve sonra da
gerçekleştirimi tekrar tekrar gözden
geçirip gerekli gördüğünüz
düzenlemeleri yapın.
• 11. Tasarımı ve gerçekleştirimi test
edip sonuçlarını değerlendirebilecek
yazılım geliştirme yardımcı araçlar
kullanın.
• 12. Her şeyi olabildiğince basit halde ve
küçük boyutta tutun.
40
• 13. Tasarımcıların, kodlayıcıların ve
kullanıcıların da birer insan olduklarını ve her
zaman hata yapabileceklerini unutmayın.
• 14. Kullanıcıların her zaman bir mühendis
kadar dikkatli ve bilgili olmayacağını
düşünerek insan- makine arayüzlerinin
uygunluğuna ve sistemin sağlamlığına gerekli
önemi verin.
• 15. Çevrenize tasarımın, kütüphanelerin ve
soyut veri tiplerinin tekrar kullanımı fikrini
yayın ve bu fikri somut örneklerle destekleyin.
41
TEKRAR KULLANIM
1. Tekrar kullanım esasları Yazılım Geliştirme
Planı’nda yer almalıdır.
2. Tekrar kullanılacak ürünler, önce proje
isterlerine göre kendi başlarına test edilmelidir.
3. Tekrar kullanıma esas olacak öğeler, hazır ticari
ürünler ve özel üretilmiş birimler gibi geliştirme
sürecinde üretilmeyecek yazılımlar birer risk
unsuru olarak ele alınmalıdır.
4. Geliştirme süreci dışında temin edilecek öğelerin
tekrar kullanımı ancak bu tür öğelerin özel bir
denetim sonucu kabul edilmesinden sonra
yapılmalıdır.
42
5. Bu tür öğelerin kullanıma karar verebilmek için tüm
yaşam boyunca gerekecek bakım maliyeti, üst
sürümlere yükseltme, garanti, lisans ve diğer öğelerle
olan uyumluluk hususları dikkate alınmalıdır.
6. Bu tür öğelerin kullanımı için verilecek karar mimari
ve tasarım tanımlamaları ile müşteri isteklerine uygun
olmalıdır.
7. Sistemin yaşam çevrimi boyunca hazır olarak
kullanılacak kritik öğelerin sorunsuzca
kullanılabilmesi için gerekli çalıştırma lisansları,
bakım ve destek olanakları ile mümkünse kaynak kod
ve geliştirme lisanslarının temin edilmesi, bunların
şimdiki ve gelecekti maliyetleri konusunda
kestirimlerde bulunularak geliştirici ve müşteri
arasında bire bir anlaşmaya varılmalıdır.
43
İSTEKLERİN VE TASARIMIN
DENETLENMESİ
Geliştirilen yazılım ürünleri düzgün iletişim
yönetim sistemi altına alınmadan önce resmi
bir test ve denetimden geçirilmelidir.
Bundan sonra bu ürünler başka ürünlerin
geliştirmelerinde temel alınırlar.
 Denetim, yazılım geliştirme planında
belirtildiği şekilde, o ürün için geçerli
olabilecek kabul esaslarına dayalı bir süreci
şeklinde yapılmalıdır.
44
 Denetim sırasında belirli bir takım metrikler
toplanmalı ve izlenmelidir. Bu metrikler arasında,
yazılım kusurları, kusurların bulunduğu yerler,
bu kusurları gidermek için gerekli gayretler ve
denetim için harcanan öz kaynakların miktarı
bulunabilir.
 Denetimler, kavram tanımlamasıyla başlar,
mühendislik etkinliklerinin tamamlanmasıyla son
bulur.
 Program veya proje için ayrılan mali kaynaklar
denetim ve sorun giderme için gerekli harcamaları
da içermelidir.
45
Denetimlerin başarılı sonuçlanması ürünün
veya tanımlanmış işin resmi bitişini
göstermelidir.
Denetim ve gözden geçirme süreci ürünün
tanımlanması ve ilk isterlerinin belirlenmesi
ile başlar, mimari, tasarım, kodlama,
tümleştirme, test ve belgelendirme
aşamalarında devam eder.
46
GERÇEKLEŞTİRİM
Yordamlarınızı 20 satır fazla uzatmamaya
çalışınız.
Bir kod dosyasının çok fazla uzamamasına
gayret gösterin.
Büyük dosyalar yerine modüler bir dosya
yapısı oluşturun.
 Kod yazarken küçük ve mantıklı bölümler
halinde yazıp sık sık derleme yapın.
47
Kullanılan bilgisayar mimarisinin
özelliklerini dikkate alın.
Kod içerisinde sıkça kullandığınız sayı
değerlerini sabit değerler olarak
yazılımın tümü tarafından
erişilebilecek bir yerde tasarlayın.
Yordamlara parametre geçirirken
mümkün olan yerlerde nesnelerin
adreslerini kullanın.
48
Kodlama da kullanılan programlama dili
desteklese dahi ‘go to ‘deyimi
kullanmayınız.
Mümkün oldukça açıklama satırı
kullanınız.
Metinin şekilsel düzenine dikkat edin.
Kodlamada ilerlerken yazdıklarınızı sık
sık değişik ortamlarda yedekleyiniz.
49
Dizin isimlerini mantıklı ve disiplinli
bir şekilde oluşturunuz.
Yazılımı denetlerken hata oluştuğunda
hemen donanım hatası olması yerine
yazılımımızdaki mantık hatası
arayınız.
Hiçbir zaman hatalara teslim olmayın.
Hiçbir yazılım geliştirici hata ayıklama
işleminden kaçamaz.
KOD YAZMAK BİR SANATTIR.
50
SÜREKLİ TEST
1) Kritik bileşenler saydam kutu yöntemiyle
test edilmelidir.
2) Her türlü test işlemi önceden üzerinde
karar kılınmış ilkelere göre yapılmalı ve
belirli bir plan izlenmelidir. Bu amaç için
gerekli olan harcamalar önceden
bütçelendirilmelidir.
3) Düzenleşim yönetim sistemi altına alınıp
sabitlenecek her ürün ya da her öğe
mutlaka bir test sürecinden geçirilmelidir.
51
4) Testler yalnızca ortalama sistem durumlarını değil,
aynı zamanda anormal ve arıza durumlarını, aşırı
yüklemeleri de içermelidir.
5) Test için kullanılacak her türlü araç ve gereç, test
durumları, senaryolar, kabul koşulları, beklenen
değerler denetim altına alınmalı ve düzenleşim
yönetim sistemi altında tutulmalıdır.
6) Her test için giriş ve çıkış değerleri, izlenecek yollar
ve kabul esasları tanımlanmalı, sonunda “geçti” veya
“kaldı” gibi bir değerlendirme yapılmalıdır.
52
7) Test planı belirli amaçlar içermelidir. Üretilen ve
hazır olarak kullanılan öğelerle oluşturulan
sistemin doğru çalıştığının gösterilmesi en büyük
amaç olmalı, bu gerçekleştikten sonra ürün
kullanıma sürülmelidir.
8) Test işlemlerinin olabildiğince kendiliğinden
yapılması, çıkan hataların ivedi olarak düzeltilip
tekrar test yapılabilmesini sağlar. Bu test çevrimi
ne kadar hızlı olursa testler için kullanılması
gereken toplam süre de o kadar düşer.
53
SIK DERLEME VE TEST
 Ana sistem testleri tamamlandıktan sonra hedef
sistem testleri olabildiğince kısa sürede
yapılmalıdır. Bu şekilde, sık derleme ve üretme
kullanılarak olası hataların daha çabuk
bulunması sağlanır.
 Test sistemi üzerinde en küçük yazılım yapısı
oluşur oluşmaz testlere başlanmalıdır. Bu
maksatla kullanılacak yazılımlar sık sık derlenip
üretilmelidir.
54
 Test için kullanılacak tüm yazılımlar düzenleşim
yönetim sisteminden alınarak kurulmalıdır. Yeni bir
sürüm ortaya çıkmışsa başka bileşenlerin
testlerinde kullanılmadan önce bu yeni sürüm
testlerden geçirilmelidir.
 Eklenen bir özellik veya tümleştirilen bir bileşen için
gerekli testler ancak ana sistemin sabitlenmesi ve
testlerinin başarılı olmasından yapılmalıdır.
 Testler sırasında bulunan tüm kusurlar tanımlanmalı
ve belgelendirilmelidir. Aksi durumda, bir sonraki
testlerde yine aynı kusurların tekrarlanmasından
kaçınılmaz.
55
Testlerin sonuçları tüm proje
personeline açık olmalı, hatta sıkça
sorulan sorular belirli bir yerde
toplanmalı ve bilgiler başkaları ile
paylaşılmalıdır.
Asıl kullanılacak sisteme en yakın bir
sistem düzeneği, alt sistemler veya
onların benzeticileri (simülatör)
geliştirme yapılan yerde kurularak
testlerin olabildiğince gerçekçi
ortamda yapılması sağlanmalıdır.
56
HATA AYIKLAMA
o Test aşaması için kapsamlı test senaryoları
hazırlanmalı ve her senaryo mutlaka sonuna
kadar çalıştırılmalıdır. Bu şekilde, olası yazılım
kusurlarının varlığının belirlenmesine
çalışılmalı, kusur belirlendikten sonra
temizleme aşamasına geçilmelidir.
o Testler kötümser bir yaklaşımla yapılmalıdır ki
kusurlar ortaya çıksın. Yakalanan her kusur
ileride olası bir yazılım hatasına engel
olacaktır.
57
o Hata ayıklama sırasında yeri belirlenen yazılım
kusurunun giderilmesi sırasında yeni bir kusur
katılması yüksek bir olasılıktır. Bu nedenle,
kusurlar birer birer ele alınmalı, çok fazla
değişiklik yaparak birden fazla kusuru bir defada
gidermeye çalışılmamalıdır.
o Çoklu programlama ortamlarında hata ayıklama
son derece güçtür. Bu tür ortamlar tasarlanırken,
modüllerin ayrı ayrı test edilebilmelerine olanak
tanınması çok önemlidir.
58
o Birden fazla modülde hata bulunması
durumunda kusurlar bir sıraya göre
düzeltilmeli, birden fazla modül bir anda
değiştirilmemelidir.
o Kodlama sırasında, her bir yordam içine hata
yakalama tuzakları yerleştirilmeli, yakalanan
hatalar nedenleriyle birlikte standart bir hata
raporlama düzeneğine bildirmelidir. Bu
şekilde, yürütme sırasında oluşan bir hataya
neyin neden olduğunu ve ne zaman oluştuğunu
bulmak kolaylaşır.
59
o Dağıtık ortamlarda, yazılımda meydana gelen bir hatayı
bulmak için hangi düğümde hangi modüllerin
çalıştığının takip edilmesi gereklidir. Bu tür ortamlarda,
küçük ölçekli de olsa mutlaka bir ara katman
kullanılmalı, kodlama, hata yakalama ve raporlamada
belirli düzenekler bulunmalıdır.
o Testler sürerken hata düzeltme işlemi
sürdürülmemelidir. Her hata durumunda da testi
durdurup hatayı düzeltmek, sonra teste kaldığı yerden
devam etmek de her zaman doğru değildir. Eğer
testlerin gidişini etkileyecek derecede büyük hata varsa,
test durdurulmalı, ileriki bir tarihte tekrar edilmelidir.
60
ÖLÇME SÜRECİ UYGULAMASI
1. Örgüt içindeki herkesin ölçme sürecinin
yeteneklerini ve kısıtlarını anlaması
sağlanmalıdır.
2. Metriklerin bir anlam ifade edebilmesi için
herkesin ölçülen verilerin ne anlama geldiği
hakkında aynı düşünceye sahip olması
gereklidir.
3. Önce küçük hedeflerle işe başlanmalı, yalnızca
birkaç temel ölçüm kullanılmalı ve etkileri
kontrol edilmelidir.
61
4.Yalnızca tanımlanan ve kullanılacak
olan metrikler toplanmalı, veriler
kullanılmayacaksa boşuna
toplanmamalıdır.
5.Ölçme için bir kişi görevlendirilmeli,
metrikleri doğru şekilde toplaması ve
birleştirmesi için geliştiricilerle yakın
temasta olması sağlanmalıdır.
62
6. Metrik toplamak ve sağlamak için basit de
olsa bir araç kullanılmalıdır.
7. Ölçümlere dayanarak belirli bir grubu ya da
kişiyi değerlendirme yoluna gidilmemeli,
kimsenin de böyle düşünmesine izin
verilmemelidir.
8. Ölçüm sonuçları iyi ya da kötü olsun,
mutlaka raporlanmalıdır.
63
64
Bu kısımda bir yazılım ürünün genel
niteliğini arttırmak için izlenmesi yararlı
olan bazı önerilerde bulunmaktayız.
• İŞLEVSEL NİTELİK
İşlevlerin tutarlılığı ve doğru uygulanması
isterler çözümlemesi aşamasından
başlayarak yönetilmelidir.
 Ürün mümkünse ayrı işlevlere sahip, ayrı
bileşenler halinde geliştirilmeli ve her
bileşen ayrı bir ürün gibi kabul edilerek
kullanıcı memnuniyeti ölçülmelidir.
65
İşlevler karmaşıklıklarına göre
sınıflandırılmalı ve kullanıcıya
yapılan sunumlarda bu
sınıflandırmaya dikkat
edilmelidir.
Yazılımın sahip olması gereken
tüm işlevlerin yerine getirildiğini
kanıtlamak üzere doğrulama ve
geçerleme etkinlikleri
uygulanmalıdır.
66
Veri ve işlev arasındaki ilişkilerin
kullanıcılar açısından belirgin olmasına
önem verilmeli, doğru işlevlerle hatalı
verilerin ayrışımı kolayca sağlanmalıdır.
 Bir akış izleyen işlevler ayrıştırılmalı ve
kullanıcının bu akışı bilmesi, izlemesi ve
kabul testleri sırasındaki senaryoları
anlaması sağlanmalıdır.
 İlk örnekler kullanıcının ön
değerlendirmesinden geçirilmeli
düzeltme istekleri dikkate alınmalı, ürün
teslimi alınan geri beslemelerden sonra
yapılmalıdır.
67
GÜVENİLİRLİK
1. Yazılım ürününün kesintisiz çalışabilme
özelliği, kullanıcıya teslim etmeden önce
yapılan denenmelerle, kullanıcının
gözetiminde izlenerek belirlenmelidir.
2. Geliştirme sırasında yapılan
denemelerde, aynı ortamda olabildiğince
çok ve değişik yazılım ve donanım
bileşeninin beraber çalışabildiği
gözlemlenmelidir. Bu amaçla gerekirse
tanımlı sistem yapılanması dışında testler
uygulanmalıdır.
68
3. Üründen kaynaklanmayan
kısıtlayıcı koşullar test ortamında
oluşturulup ürün davranışları
yakından izlenmelidir.
4. Ürünün güvenilirliğini etkileyecek
bilgisayar mimarisi, işletim
sistemi, veritabanı gibi ortam
koşulları sistemde kullanılacak
diğer bileşenlerin üreticileriyle
ortak çalışılarak belirlenmelidir.
69
BAKIM KOLAYLIĞI
Ürün bileşenlerinin bakım kapsamında yer
alacak değişiklikleri sorunsuz içerebilmeleri
için tasarımda ekler yapılmalı, esnek
tasarımlar geliştirilmelidir.
Tasarım sırasında, problemin yalnızca
bugünkü şeklini çözmeye değil, gelecekteki
gereksinimlerini de karşılamak
hedeflenmelidir.
70
 Üründe oluşabilecek temel
sorunlar önceden tanımlanmalı,
bir sorunla karşılaşıldığında o
anda olası düzeltme yöntemleri
kullanıcıya sunulmalıdır. Bakım
için gerekli temel etkinlikler
belgelenmeli, süreçler
tanımlanmalıdır.
Bakımdan sorumlu personel,
değişikliklerin uyarlanabilmesi
için eğitilmelidir.
71
72
Pek çok işyerinde çalışma grubu
büyüdükçe eşgüdümü ve bilgi
paylaşımını sağlamak amacıyla
toplantı yapılır.Bazen bu toplantılar o
kadar çok ve uzun olur ki asıl işi
yapmaya zaman kalmaz.
73
 Kötü yönetilen,kötü planlanan,iyi
hazırlanılmamış toplantılar insan
kaynağının önemli miktarda zaman
dilimini yok eder.O nedenle evrensel
nitelikte olan toplantı kurallarını
incelemekte yarar vardır.
74
a.Toplantı Verimi
 Toplantıların verimli geçmesi ve amacına
ulaşması için birkaç ilke sıralanabilir:
Toplantı Duyurusu:
 Toplantıların başarıya ulaşabilmesi ve amacına
uygun sonlanabilmesi için katılımcılara önceden
toplantıların gündemi ile ilgili bilgi verilmesi
gerekir. Katılımcıların hazırlanması için gerekli
süre mutlaka göz önüne alınmalı,toplantının
yapılacağı yer,tarih ve saat bilgileri ile süresi de
kesintisiz olarak bildirilmelidir.
75
Toplantı Zamanı:
o Katılımcıların istekliliğini etkileyecek
önemli bir unsur da toplantı
zamanıdır.Yemek veya mola saati
öncesi,mesai bitimine yakın veya bir
tatil arifesinde planlanan toplantıların
verimsiz geçme olasılığı yüksektir.
76
Toplantı Lideri:
 Bir toplantı mutlaka bir kişinin liderliğinde
yürütülmeli ve bunuda bütün katılımcılar
önceden bilmelidirler.Genelde
önerilen,toplantıyı düzenleyen kişinin
toplantı liderliğini üstlenmesidir.
 Toplantı liderinin amacı,konuşmaları
gündem maddeleri üzerinde
yoğunlaştırmaya çalışmak ve sonuç
almaktır.Toplantı kayıtlarını tutmak üzere
de bir kişi görev almalıdır.
77
Toplantı Ortamının Hazır Olması:
• Toplantıdan önce,toplantı sırasında gerekli
olacak araç gerecin hazırlanması ve
denetimini önemlidir.Düzgün ve büyük bir
masa,yeteri kadar sandalye,çalışır
durumda ve ayarları tam olarak yapılmış
yansı makinesi,çizim tahtası ve yazı
malzemeleri,taşınabilir bilgisayarlar için
elektrik prizleri ve ağ bağlantıları bu
gereçlerden bazılarıdır.
78
• Hazırlığı yapılmamış bir toplantı
salonu,toplantının geç başlamasına veya
gereksiz yere bölünmesine neden olabilir.Çok
önemli ve süre kısııı olan toplantılardaa kritik
gereçlerin bir yedeğinin hazırda
tutulması,hatta yedek güç kaynağının hazır
bulunddurulması yararlı olur.
79
Zamanında Başlama:
• Toplantılara mutlaka bildirilen
zamanda
başlanılmalıdır.Katılımcıların
zamanlamaya gerekli özeni
göstermeleri bir kültür ve disipilin
unsuru olmasına rağmen gerekirse bu
konudaa önceden uyarı yapılmalıdır.
80
• Toplantı yöneticisi,zamanında
toplantıyı başlatmalı ve geç
kalaanlara ayrı bir açıklama yapmak
üzere toplantıyı bölmemelidir.Bu
konudaki ciddiyet,katılımcıların da
toplantıya tam zamanında gelme
konusunda hassasiyet göstermelerine
neden olur .
81
Toplantının Bölünmemesi:
• Toplantı sırasında yapılan yiyecek ve içecek
servisleri, telefon görüşmeleri,dışarı
çağrılmalar, imza almaya gelenler
katılımcıların dikkatini dağıtır.Bu tür
gereksinimler bir saatten fazla sürecek
toplantılarda düzenli aralar verilerek toplantı
salonunun dışında gerçekleştirilmelidir.
82
Toplantı Amaçlarının Korunması:
• Toplantı sırasında karşılaştırılan en büyük
sorunun “konudan sapma” olduğu
belirlenmiştir.Toplantı liderinin ve
katılımcıların toplantı gündemine sadık
kalması ve problemin özüne yönelik
tartışmaların yapılması önemlidir. Akışı
denetim altında tutulmayan toplantılarda
problemlerin etrafında dönülür,kişisel
düşünceler açıklanır,fakat hiçbir zaman öze
inilemez.
83
Toplantının Başarısı:
• Toplantının başarılı olması katılımcıların
arasında düşüncelerin ve bilgilerin açnıkça
dolaşmasına bağlıdır.Katılımcılar,kişisel
çatışmalarından veya ast-üst bürokrasisinden
kaçınmalı,problemlere
odaklanmalıdırlar.Toplantının hedeflerine
ulaşıldığında,kilit noktalar ,önemli
görev,sorumluluk ve yetki atamaları
tamamlandığında, bir özetleme yapılmalı ve
toplantıya ilişkin belgelerin dağıtımı
hakkında bilgi verilmelidir.
84
Toplantının Sonlandırılması:
• Toplantı lideri toplantıyı önceden duyurulan
saatte bitirmeye özen göstermelidir.Eğer
tartışma konuları henüz bitmemiş ise, ya tüm
katılımcıların onayıyla ugun bir süre
uzatılmasına gidilmeli ya da yine ortak olarak
belirlenecek başka bir tarih ve saatte buluşma
düzenlenmelidir.
85
Toplantı Belgeleri:
• Tutanaklar, toplantıda yapılan konuşmaların
ve alınan kararların saptanmasını sağlar.
Ancak tutanak, konuşulan her kelimenin
tespiti demek değildir. Tutanaklarda, yapılan
konuşmalar özlü bir şekilde yazılır. Sonra
sonuç ve öneriler dikkatle not edilir. Çok
önemli toplantılarda söylenenlerin aynen
tespiti gerekebilir.
86
• Bu durumda toplantıdan önce tutanağı
tutacaklara bilgi verilmelidir. Tutanağı,
eğer varsa stenografın tutması ya da
elektronik kayda alınması uygun olur.
Tutanaklar sık sık başvurulan
kaynaklar olduğundan, kayıtların açık,
doğru ve eksiksiz olmasına dikkat
edilmelidir.
87
• Toplantı Tutanağı aşağıdaki kısımlardan
oluşur.
Tanım:
• Proje adı,toplantı gündemi,ilgili
girdiler,tarih,zaman,yer,süre.
Katılımcılar:
• Her katılımcının adı,bulunduğu bölüm ve
görevi,telefon numarası,e-posta adresi,imzası.
88
 Denetim:
• Toplantıya katılan taraflardan yetkili kişilerin
imzaları.
 Görüşülen Konular:
• Toplantıda görüşülen konular,kişilerin kayıt
altına alınması gereken önemli ifadeleri,alınan
kararlar.
 Eylem Maddeleri:
• Belirli bir sıra numarası ile bir sonuca
bağlanması gereken eylem maddeleri, her bir
maddenin sorumlusu, planlanan bitiş tarihi.
89
HAZIRLAYANLAR
MEVLÜT İNAN
90