Sistem Analizi ve Tasarýmý

DERS NOTLARI
Ders Adı
: Sistem Analizi ve Tasarımı
Kısa Ders Özeti
Bu dersin I.Bölümünde genel sistem yaklaşımı kavramlarını ve işletmelerin sistem
yaklaşımı ile incelenmesini gösterdikten sonra, bilgisayara dayalı bilgi sistemlerini
anlatır. II.Bölümde ise yazılım gliştirme teknikleri, III.Bölümde yazılım mühendisliği
kriterleri anlatılmıştır.
Dersin Hedefleri
U
S
Bu ders sonunda öğrenciler, işletmeleri sistem yaklaşımı ile incelemeyi ve bu
yaklaşımla problemlere çözüm getirmeyi öğreneceklerdir. Ayrıca öğrenciler, bir
yönetim bilgi sisteminin nasıl tasarlanacağını da görecekler ve yapacakları bir proje
yardımıyla bu tasarımla ilgili becerileri de kazanacaklardır.
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Sistem Analizi ve Yazılım Tasarımı
1
K
A
Öğr. Gör. Mustafa AKSU
1.
SĐSTEM KAVRAMI
Çeşitli sistem tanımları:
-
Birden çok şey veya parçaların kombinasyonu veya bir araya getirilmesi
sonucunda oluşan karmaşık veya bölünmez bütündür.
-
Birbirleri ile etkileşimli elemanların oluşturduğu topluluktur.
-
Nesneler ve bu nesneler ile özelliklerinin arasındaki
getirdiği topluluktur.
-
Aralarında ilişkiler olan parçaların oluşturduğu topluluktur.
-
Plana uygun bir amacı gerçekleştirmek üzere tasarlanmış çeşitli bileşenlerin
oluşturduğu bütündür.
-
Bir işletmede bir faaliyeti gerçekleştirmek amacıyla bütünleştirilmiş bir plan
oluşturmak üzere birbirleri ile ilişkili çeşitli süreçlerin oluşturduğu bir şebekedir.
-
Birbirleri ile ilişkili bileşenlerin oluşturduğu karmaşık bütündür.
ilişkilerin meydana
U
S
K
A
Bu tanımları çoğaltmak mümkündür. Fakat sonuçta bu ve benzeri tanımların ortak
noktalarından faydalanılarak şu şekilde genel bir sistem tanımı yapmak uygun olacaktır:
Sistem; bir veya daha fazla amaca yada sonuca ulaşmak üzere bir arada bulunan ve
aralarında ilişkiler olan fiziksel ya da kavramsal birden çok bileşenin (öğenin) oluşturduğu
bütündür.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
1.1. Sistem Düşüncesinin Ortaya Çıkışı
Sistem düşüncesindeki temel gelişmeler ve olayların sistem görüşü ile incelenmesi isteklerinin
ortaya çıkışı 1940'lı yıllara rastlamaktadır. Bilim tarihine bakıldığı zaman en başta tüm
bilimlerin felsefe içinde açıklandığı görülmektedir. Zaman içinde, arayan ve soran insan aklının
sınırları belli inceleme alanlarına yönelip bu alanlara uygun araştırma yöntemleri geliştirerek
bilgi üretme gücünü elde etmesi sonucunda bilim felsefeden bağımsızlaşmıştır. Ardından
bilim yarar üretme yönünde ilerleyerek teknoloji denen kavramı meydana çıkardı.
Teknolojideki hızlı gelişmeler ve uzmanlaşma otomasyon kavramını ortaya çıkardı.
Uzmanlaşma ve otomasyon, bir yandan verimlilik açısından iyileşme taleplerini karşılarken bir
yandan da sorunların, sistemlerin ve işlevlerin giderek daha küçük parçalara ayrılmasına
sebep oldu. Bu ayrılma ise birbirinden oldukça farklı sistemlerin ortak yanlarını, ortak
işlevlerini, temel ilke ve niteliklerini anlamayı güçleştirdi. Bununla birlikte, sorunların
birbirlerinden soyutlanmaları ve sanki birbirlerinden ilgilisiz ve bağımsızmış gibi bir anlayışın
ve yaklaşım alışkanlığının doğması sonucunu getirdi. Bu anlayış ve yaklaşım alışkanlığına
karşı tepki olarak, sistemler arasındaki ortak ilkeleri, sorunları ve kavramları bilmek ve
koordine etmek, insan makine sistemlerindeki büyüme ve karmaşıklaşmanın getirdiği
sorunları aşmak amacıyla yeni bir yaklaşım ortaya çıktı. Bu yaklaşım sistem yaklaşımıdır.
.
r
g
Ö
Sistem düşüncesinin, diğer bir deyişle sistem yaklaşımının ortaya çıkmasına neden olan
etmenler aşağıdaki gibi toparlanabilir:
1.
Bilimin bir bütün oluşu: Bilim normalde bir bütündür. Bilimi ayrı disiplinler
içinde incelemek onu daha iyi anlayabilmek için yapılmışsa da zaman içinde
bütünlük bozulmuştur. Bilimi ayrı disiplinler içinde ele alıp incelemek
disiplinlerin çevredeki olayları anlayabilmek açısından kısıtlı görüş açısı
yüzünden yetersiz kalması sonucunu doğurmuştur. Sistem düşüncesi bu
bütünlüğü disiplinler arası bir yaklaşımla aşmayı amaçlar.
2.
Bilimde savurganlık: Yürütülen bilimsel çabalar kaynak savurganlığına yol
açmaya başlamıştır. Farklı disiplinleri bir arada ilgilendiren konular her disiplin
içinde ayrı ayrı ele alınıp incelenmekte ve bu yüzden gayretler gereksiz yere
Sistem Analizi ve Yazılım Tasarımı
2
Öğr. Gör. Mustafa AKSU
dağıtılmaktadır. Çoğu kez aynı sonuçlara ulaşılmakta bu da kaynak
savurganlığını doğurmaktadır
(jeofizik, fizikokimya, sosyo-ekonomi gibi).
Sistem düşüncesi ile bu savurganlığın aşılması amaçlanmıştır.
3.
Bilimsel yöntemin yetersizliği: Analiz ve senteze dayanan bilimsel yöntem,
bilimin o gün itibariyle ulaştığı noktada bilimsel problemlerin çözümü için
yetersiz kalmıştır. Sistem düşüncesi, içinde bilimsel yöntemi de içeren yeni bir
yaklaşım önermiştir.
4.
Tükenmeyen sorunlar: Yirminci yüzyılın ikinci yarısına gelindiğinde
insanoğlunun sahip olduğu bilgiler çevredeki olayları çok küçük ayrıntılarına
kadar çözmeye yetecek seviyede olmasına rağmen sorular ve sorunlar
bitmemektedir. Sistem düşüncesi ile sorunların daha etkin ve hızlı çözülmesi
amaçlanmıştır.
Yukarıda sayılan sebepler sonucu geliştirilen sistem yaklaşımının üç temel ilkesi vardır:
U
S
Bütünsel Yaklaşım: Đncelenen sistem bir bütün olarak görülmelidir. Sistemin
içerdiği sorunlar birbirlerinden soyutlanamaz. Sistemin içerdiği bir öğe ancak
sistemin diğer öğeleriyle birlikte düşünüldüğünde işlevsel bir anlam ifade eder.
Sistem, birbirleriyle etkileşimli öğelerden oluşmuş, çevresiyle etkileşimli bir
bütünlüktür.
1.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
2. Disiplinler Arası Yaklaşım: Bütünsel yaklaşımın tamamlayıcısıdır, şöyle ki;
incelenen sistemi bir bütün olarak görmenin ön koşulu ve aynı zamanda
gerekli sonucu, o sisteme farklı görüş açılarıyla yaklaşabilmektir. Bu ön koşulu
disiplinler arası yaklaşım sağlar. Eğer sorunlar üzerine tek bir bilim dalının
görüş açısı ile gidilirse ön yargılı ve gerçek dışı sonuçlara varılması
muhtemeldir. Disiplinleri insanlar ortaya çıkarmıştır ve disiplinler doğadaki
sorulara farklı görüş açıları ile çözümler üretmeyi hedefler. Disiplinler arası
yaklaşım sayesinde grup çalışması denen yöntem gündeme gelmiştir. Değişik
bilim dallarında eğitim görmüş bilim adamları bir araya gelerek karar ve çözüm
üretmeye yönelmişlerdir.
3. Bilimsel Yaklaşım: Sistem yaklaşımında sorunları bir bütün olarak görmenin ve
sorunlara değişik görüş açılarıyla yaklaşmanın somut yöntemidir. Sistemler
üzerinde çalışırken sorunların çözümü için bilimsel yöntem tercih edilir. Bu
yöntem temel bilimler ve toplumsal bilimler açısından farklılık göstermektedir.
Sistem analizinde sistemin işlevine göre bu yöntemlerden birisi kullanılabilir.
.
r
g
Ö
Temel bilimler için uygulanan bilimsel yöntem aşamaları şunlardır:
1.
Olayın gözlenmesi, problemin tanımlanması
2.
Hipotezin geliştirilmesi.
3.
Veri ve bilgilerin toplanması
4.
Deneyler yoluyla hipotezin test edilmesi
5.
Hipotez hakkında sonuçlara varılması
6.
Genelleme yardımıyla olayın kontrol altına alınması
Sistem Analizi ve Yazılım Tasarımı
3
Öğr. Gör. Mustafa AKSU
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 1.1 – Sistem Yaklaşımının Bilimsel Gelişim Evreleri
1.2. Sistem Tanımı ve Bileşenleri
.
r
g
Ö
Sistem, günümüzde çok sık kullanılan sözcüklerden birisidir. Hemen her türlü metinde
bu sözcükle karşılaşmak olasıdır. Çevremizde olup biten her türlü faaliyet bir sistem olarak
düşünülebilir. Böyle geniş anlamlar içeren bir sözcüğü tek bir tanımın içine sığdırmak
güçtür. Gene de sistem olarak adlandırılan tüm kavramların içerdiği ortak noktalar
bulunmaktadır. Bu noktalar öğe, özellik, faaliyet ve durumdur. Bunları kısaca açıklarsak:
Öğe
: Sistem içindeki herhangi bir nesne
Özellik : Sistem içindeki öğelerin nitelikleri
Faaliyet: Sistemde değişimi sağlayan süreçler (prosesler)
Durum
: Belli bir zaman noktasına sistemin öğe, nitelik ve faaliyetlerinin tanımı.
Tablo 1.1'de bu kavramlarla ilgili örnekler verilmiştir.
Sistem Analizi ve Yazılım Tasarımı
4
Öğr. Gör. Mustafa AKSU
Sistem
Öğeler
Özellikler
Faaliyetler
Đmalat
Makine
Hassas
Đmalat
Đşgücü
Nitelikli
Mamul
Bozuk
Taşıtlar
Hızlı
Yol
Uzun
Levhalar
Beyaz
Mesajlar
Kısa
Cihazlar
Yeni
Ulaşım
Đletişim
Taşıma
Haber
gönderme
Tablo 1.1 - Bazı sistem örnekleri
U
S
Bu noktada sistem tanımına geri dönersek:
"Sistem; bir veya daha fazla amaca yada sonuca ulaşmak üzere bir arada bulunan ve
aralarında ilişkiler olan fiziksel ya da kavramsal birden çok bileşenin (öğenin) oluşturduğu
bütündür." Bu tanıma göre:
• Sistem öğelerden oluşmuştur.
• Öğeler arasında ilişkiler vardır.
• Sistem belli bir amaca yönelmiştir.
1.2.3 Amaçlar
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Her sistemin yöneldiği bir ya da daha fazla amaç vardır. Örneğin bir otomobil sistemi taşıma
yapma amacına hizmet eder, üretim hattı imalat gerçekleştirir ya da bir eğitim sistemi
insanları eğitmeyi amaçlar.
Đnsan yapısı sistemler için amaçları tespit etmek çok zor değildir. Zaten bu sistemler bir amaca
ulaşmak için insanlar tarafından üretilmiştir. Fakat, insan yapısı olmayan sistemler için
amaçları tespit etmek her zaman kolay olmayabilir. Đnsanın sindirim sisteminin amacının
besinleri sindirip insana enerji sağlamak olduğunu söylemek kolaydır, ancak güneş sistemi
gibi daha geniş sistemler için bu amacı tespit edebilmek teolojik tartışmalara neden
olmaktadır.
1.3.
.
r
g
Ö
Genel bir Sistemin Şematik Gösterimi
Şekil 1.3 - Geri beslemeli sistem (dinamik sistem)
Sistem Analizi ve Yazılım Tasarımı
5
Öğr. Gör. Mustafa AKSU
U
S
Şekil 1.4 - Detaylı Sistem Gösterimi
1.4. Sistem Hiyerarşisi
K
A
Varolan tüm sistemleri barındıran ve piramit şeklinde gösterilebilecek bir sistemler
hiyerarşisinden söz etmek mümkündür. Bu hiyerarşi aşağıdaki şekilde incelenebilir.
Burada amaç bir işletme sisteminin tüm sistemler içindeki yerinin gösterilebilmesidir.
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Şekil 1.5- Đşletme Açısından Sistem Hiyerarşisi
1.5. Sistem Sınıflandırması
Sistemleri farklı şekillerde sınıflandırmak mümkündür:
(1) açık ve kapalı sistemler,
(2) canlı ve cansız sistemler,
(3) doğal ve insan yapısı sistemler,
(4) statik ve dinamik sistemler,
(5) soyut ve somut sistemler,
(6) basit ve karmaşık sistemler.
Sistem Analizi ve Yazılım Tasarımı
6
Öğr. Gör. Mustafa AKSU
1.5.1
Açık ve kapalı sistemler
Kapalı sistemler, çevreyle etkileşimi olmayan sistemlerdir. Açık sistemlerde çevre ile sistem
arasında bilgi, malzeme ve enerji değişimi vardır.
1.5.2 Canlı ve cansız sistemler
Doğum, ölüm ve çoğalma gibi biyolojik özelliklere sahip sistemlere "canlı sistemler" denir.
Biyolojik bir yaşam belirtisi göstermeyen sistemler ise cansız sistemlerdir. Bir insan ya da
hayvan canlı sistemler için örnek oluştururken, bir uçak ya da bir müessese cansız
sistemlere örnektir.
1.5.3 Doğal ve insan yapısı sistemler
Adından da anlaşılabileceği gibi insanlar tarafından belli amaçlar doğrultusunda meydana
getirilen sistemler insan yapısı sistemlerdir (artificial systems). Bunun tersi doğal yollarla
oluşmuş olan sistemler doğal sistemlerdir. Bir işletme ya da işletmeyi de içine alan ekonomik
sistem insan yapısı bir sistemdir. Güneş sistemi ya da dünyamızdaki tabi hayat ise doğal bir
sistemdir.
U
S
1.5.4 Statik ve dinamik sistemler
K
A
Çevredekileri değişmelere karşın durumunu koruyan sistemler statik sistem olarak
adlandırılırken, çevredeki değişikliklere göre zaman içinde değişikliğe uğrayan sistemlere
dinamik sistemler denir.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
1.5.5 Soyut ve somut sistemler
Eğer bir sistem somut öğelerden meydana geliyorsa o sistem bir somut sistemdir. Tüm
elemanları kavramlardan oluşan sistemler ise soyut sistemlerdir.
1.5.6 Basit ve karmaşık sistemler
Sistemde çok az öğe ve ilişki varsa basit sistemdir. Örneğin bir çörek pişirme işlemi basit bir
sistemdir. Karmaşık sistemler ise çok fazla öğe ve ilişki barındıran sistemlerdir. Makine
imalatı yapan bir işletme karmaşık bir sistem sayılabilir.
2.
.
r
g
Ö
SĐSTEM MODELLERĐ
Sistemlerin işleyişini ve durumlarını izah etmek ve göstermek
modellerden faydalanılır. Bu modeller aşağıdaki şekilde sınıflandırılabilir:
amacıyla
çeşitli
2.1. Sözlü (Kavramsal) Modeller
Sistem modelleri içinde en eski ve en genel olanı sözlü, diğer bir ifadeyle de kavramsal
modellerdir. Bu modeller, sistemi sözcüklerle açıklamaya çalışırlar. Bu modellerin
avantajları, düşük maliyetli olmaları, kolay kurulabilir olmaları ve karmaşık olmayan
sistemlerde kolay anlaşılabilir olmalarıdır. Ancak sözcüklerin kullanıldığı durumlarda, farklı
insanlar sözcüklere birbirlerinden farklı anlam yükleyebildiklerinden yanlış anlaşılmalarla
karşılaşılabilir.
2.2. Şematik Modeller
Đnsanların bilgileri gözle görerek algılama kabiliyetleri oldukça yüksektir. Bu nedenle doğru
tekniklerle oluşturulmuş şekillerle anlatılan bilgileri daha kolay ve çabuk kavrayabilirler.
Sistem modellemede de şematik modellerin kullanımı yanlış anlamaları önlemek
açısından önemlidir.
Sistem modelleme de kullanılabilecek bazı şematik model teknikleri şunlar olabilir:
Sistem Analizi ve Yazılım Tasarımı
7
Öğr. Gör. Mustafa AKSU
•
•
•
•
•
•
Grafikler
Gannt Şeması
Ağ Diyagramı
Karar Ağacı
Organizasyon Şeması
Süreç Akış Şeması
2.2.1. Süreç Akış Şeması
Sistemde bulunan genel sürecin (proses) yada alt süreçlerin nasıl işlediğini izah etmek
için kullanılan şematik bir gösterimdir. Süreç akış şeması için kullanılan şekiller ve
açıklamaları ile örnek bir süreç akış şeması aşağıda verilmiştir. NCC (National Computing
Centre - Đngiltere) tarafından geliştirilen bu simgeler bilgisayar programlarının akış
diyagramları için de kullanılır.
U
S
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Tablo 2.1 - Süreç Akış Şeması Sembolleri (NCC)
Sistem Analizi ve Yazılım Tasarımı
8
Öğr. Gör. Mustafa AKSU
U
S
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 2.7 - Bir Süreç Akış Şeması Örneği (Telefonla Satış)
Sistem Analizi ve Yazılım Tasarımı
9
Öğr. Gör. Mustafa AKSU
3.
Bu bölümde
anlatılacaktır.
sistem
analizi
SĐSTEM ANALĐZĐ
aşamaları
ile
yeni
sistemlerin
geçiş
yöntemleri
3.1. Sistem Analizi Aşamaları
Girdi ve çıktının incelenmesi / iç ve dış
çevrenin incelenmesi / Sistemi oluşturan
bileşenlerin incelenmesi /verilerin, bilgilerin
toplanması, işlenmesi, yorumlanması.
Tek bir problemin belirlenmesi ve çözüme
i) Hedef; açık ve ölçülebilir olmalı
ii) Anlaşılabilir olmalı
iii) Gerçekçi ve ulaşılabilir olmalı
U
S
K
A
Hedef problemin çözümü ve sistemin
kendisi için uygun mudur?
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Problemin çözümü için birden fazla öneri
geliştirilerek modeller kurulacaktır.
Hangi alternatifin hangi açılardan daha iyi
olduğunun değerlendirilmesi.
.
r
g
Ö
Seçilen alternatif uygulanırsa nelerle
karşılaşılacağının belirlenerek alternatifin
uygun olup olmadığına karar verme.
Uygulama için yapılacak işlerin
sıralanması, proje yönetimi için gerekli
faaliyetlerin belirlenmesi, diğer
faaliyetlerle ilişkilendirilmesi.
Uygulamanın başlaması ve aksayan
yönleri bulmak için uygulamanın
izlenmesi.
Gidişatın hedefe uygunluk
açısından değerlendirilmesi.
Şekil 3.1 - Sistem Analizi Aşamaları
Sistem Analizi ve Yazılım Tasarımı
10
Öğr. Gör. Mustafa AKSU
3.2. Sistem Analizinin Temel Faaliyetleri (Gannt Şeması)
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Şekil 3.2 - Sistem Analizi Faaliyetleri
K
A
Şekil 3.2'de sistem analizi faaliyetleri bir Gannt şeması üzerinde gösterilmiştir. Buna göre
yeni tasarımla eski tasarım arasında bir geçiş yaşanmaktadır.
3.3. Yeni Sisteme Geçiş Yaklaşımları
Dört adet geçiş yaklaşımı vardır. Bu geçiş yaklaşımları Şekil 3.3'te gösterilmiş ve bu şeklin
ardından her bir geçiş tipine ilişkin açıklama verilmiştir.
.
r
g
Ö
Şekil 3.3 - Geçiş Yaklaşımları
Sistem Analizi ve Yazılım Tasarımı
11
Öğr. Gör. Mustafa AKSU
3.3.1 Doğrudan Geçiş
Belirlenen bir günde, eski sistemden yeni sisteme doğrudan geçişi ifade etmektedir. Kurulan
yeni sistem yeni bir sistemin yerine geçmiyorsa yada eski sistem artık görevini ifa
edemiyor durumdaysa bu yaklaşım tercih edilebilir. Geriye dönüşü çok zor ve maliyetli
olduğu için genelde küçük firmalar tarafından tercih edilir. Riski fazladır.
3.3.2 Paralel Geçiş
Yeni sistemin tam olarak çalıştığı anlaşılana kadar eski sistemle yeni sistemin aynı anda
paralel olarak işletilmesidir. Eğer yeni sistem, eskiden çalışmakta olan ve istenildiği kadar
olmasa da verim sağlayan bir sistemin yerine tasarlanmışsa, bu durumda iki sistemin bir
müddet birlikte çalışmasında fayda vardır. Eski sistem ile yeni sistemi kıyaslama şansı
verir. Yeni sistemin istenildiği gibi çalışmaması durumunda eski sisteme dönüşe müsaade
ettiği için riski yüksek değildir. Buna karşılık aynı iş için iki ayrı sistem aynı anda kullanıldığı
için maliyeti yüksektir. Yeni sistemin yeterli olduğuna kanaat getirildiğinde eski sistemin
uygulamasına son verilir.
U
S
3.3.3 Safhalı (adım adım) Geçiş
K
A
Yeni sistemin, parça parça uygulamaya konulmasıdır. Örneğin, bir satış bilgi sisteminde,
ilk önce satışların muhasebelenmesi modülü, daha sonra stok yönetimi modülü vb.
Uygulamaya konabilir. Buna göre alt sistemlerden biri yeni sisteme geçerken diğer alt
sistemler yapılan plana göre bir müddet daha işlemeye devam etmektedir. Büyük ölçekli
sistemler için tercih edilen bir yöntemdir. Dezavantajı geçiş zamanının uzun vadeye
yayılmasıdır.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
3.3.4 Pilot Geçiş
Pilot, komple çalışma sisteminin bir alt kümesinde yürütülen bir deneme sistemidir. Yeni
sisteme geçiş bu şekilde bir pilot uygulama ile gerçekleştirilebilir. Örneğin yeni bir müessese
bir üretim sistemini 8 fabrikada uygulayacaksa önce bu fabrikalardan birini pilot olarak seçip
sistemi o fabrikada deneyebilir. Pilot yürütülürken genelde eski sistem muhafaza edilmekte
fakat aktif olmamaktadır. Pilot sistem başarıya ulaşırsa diğer fabrikalara da aynı sistem
kurulur.
r.
4.
BĐLGĐ SĐSTEMLERĐNE GĐRĐŞ (YBS)
g
Ö
4.1. Bilginin Karakteristikleri
Bilginin, yöneticilerin karar vermesine yardımcı olması, verilen kararların belirsizliğini
azaltabilmesi, yani yararlı ve değerli olabilmesi için aşağıdaki özelliklere sahip olması istenir:
(i) Bilginin Doğruluğu ve Doğrulanabilirliği: Bilginin doğruluk kalitesi, onun hatadan
bağımsız olma (hatasız olma) derecesine bağlıdır ve bilgi aksi ortaya konmadıkça
doğru kabul edilir. Çoğu kez %95 doğru bilgiye ulaşmak ekonomik olmayabilir.
Örneğin bir ürüne ait pazar araştırmasında müşterilerin ancak bir bölümüyle anket
yapabilir ve bu örneği kullanarak belli bir güvenlik seviyesinde (%95 gibi)
güvenlik seviyesinde tüm müşterilerin görüşünü ortaya koyabilirsiniz.
(ii) Bilginin Tamlığı: Bilgi tamamen doğru ve doğrulanabilir olmasına karşın tam
olmayabilir. Bir karar vericiye sağlanan bilgi miktarı ile o bilginin tamlığı arasında bir
ilişki yoktur. Örneğin fayda/maliyet analizine ilişkin bir analiz yaparken fayda
bilgisi tamken, maliyet bilgilerinde eksiklikler varsa bu eksiklik yanlış bir yatırım
kararı alınmasına yol açabilir. Bu açıdan sağlanan bilgi tam olmalı konuyla ilgili
bilinmesi gereken tüm yönleri kapsamalıdır.
(iii) Bilginin Zamanlılığı: Bilgi kendisine ihtiyaç duyulduğunda hazır olmalıdır. Bilgi
Sistem Analizi ve Yazılım Tasarımı
12
Öğr. Gör. Mustafa AKSU
doğru ve tam olmasına rağmen zamanında elde edilememişse, yönetici için
çok şey ifade etmeyecektir. O bilginin ihtiyaç duyduğu karar prosesi geçmiş ve
karar çoktan verilmiş olduğundan o bilgi anlamını yitirmiş olacaktır. Örneğin bir
müşterinin bir ürün için talepte bulunduğunu ve bir gün içinde ürünü kimden
alacaklarına karar vereceklerini ve hemen alım yapacaklarını söylediğini
varsayalım. Eğer biz o gün içinde, elimizdeki mevcut stokların sayısını elde
edemezsek müşteriye gün içinde istediği cevabı verememiş oluruz. Bu bilginin
ertesi gün elimizde olması ise pek bir şey ifade etmeyecektir.
(iv) Bilginin Đlgililiği: Bilginin ilgililik kalitesi, belirli bir kararda, bilginin girdi olarak ilgili
olmasına bağlıdır. Yani bilgi, karar vericinin karar vereceği konu ya da konularla
ilgili olmalıdır. Eğer bir restorandaki rezervasyon sistemiyle ilgili bir karar vermeye
çalışıyorsak restorandaki boş yer sayısı ilgili bir bilgidir, ancak o akşamki menüde
hangi yemeklerin olduğu bilgisi bu karar açısından yeterince ilgili bir bilgi
değildir.
U
S
(v) Bilginin ekonomikliği: Gerçek durum tam olarak bilinmese de, bilgi sağlamanın
belirli bir maliyeti vardır. Karar vericiler sürekli olarak, bilginin üretilme maliyet ile
sağladığı fayda arasında bir denge oluşturmak zorundadırlar.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
4.2. Yönetim ve Karar Verme Seviyeleri
K
A
Karar verme seviyeleri 3 şekilde sınıflandırılabilir. Başka bir ifadeyle, 3 yönetim seviyesi
bulunmaktadır.
(i) Stratejik Karar Verme: Üst seviye yöneticilerin verdiği kararlardır. Geleceğe yöneliktir
ve bu kararların belirsizlik seviyesi oldukça yüksektir. Stratejik karar verme,
organizasyonun amaçlarının belirlenmesi ve bu amaçlara ulaşmak için uzun dönem
planların yapılmasını içerir. Örneğin, yeni üretim tesisi inşa edilmesi, hangi
ürünlerin üretileceği ile ilgili kararlar gibi.
(ii) Taktik Karar Verme: Orta seviye yöneticilerin verdiği kararlardır. Stratejik seviyede
verilen kararların yerine getirilmesinde, kaynakların etkin ve verimli olarak elde
edilmesi ve kullanılmasına yöneliktir. Organizasyonel amaçları yerine getirmek için
kaynakların tahsis edilmesini içerir. Örnek olarak, tesis yerleşimi, bütçe tahsisi ve
üretim planlama gibi kararlar verilebilir.
.
r
g
Ö
(iii) Operasyonel Karar Verme: Alt seviye yöneticilerin verdiği kararlardır. Taktik
seviyedeki kararların yürütülmesi için gerekli görevlerin etkin ve verimi bir şekilde
yapılmasını içerir. Örneğin işlerin çalışanlara tahsisi, sipariş zamanlarının
belirlenmesi gibi.
Şekil 4.1 - Karar Verme (Yönetim) Seviyeleri
Sistem Analizi ve Yazılım Tasarımı
13
Öğr. Gör. Mustafa AKSU
Karar verme seviyelerinin ki buna yönetim seviyeleri de denir, şematik gösterimi Şekli
4.1'de görülmektedir. Şekilde de görüleceği gibi tüm seviyelerin altında veri işleme /
operatör adı verilen bir seviye bulunmaktadır. Bu seviye, değişik seviyelerce verilecek
olan kararlar için ihtiyaç duyulan bilgi üretimini gerçekleştirir.
4.6. Karar Verme Prosesi
Aşağıda verilen iki şekilde (Şekil 4.2 ve 4.3) genel olarak karar verme prosesi ve bir
yöneticinin karar verme prosesi gösterilmiştir.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 4.2 - Karar Verme Prosesi
.
r
g
Ö
Şekil 4.3 - Yöneticinin Karar Verme Prosesi
Sistem Analizi ve Yazılım Tasarımı
14
Öğr. Gör. Mustafa AKSU
4.7. Bilgi Sistemleri
Bilgi sistemi, karar vericiler için verileri işleyerek bilgi sağlayan çoğunlukla bilgisayara
dayalı sistemlerdir. Bilgi sistemleri yapay sistemlerdir ve karar verme prosesine
yardımcı olmak amacıyla tasarlanmışlardır. Bilgi sistemleri teorik olarak manuel
olabilse de artık günümüzde bilgi sistemleri bilgisayara dayalıdır. Şekil 4.4'da
bilgisayara bağlı bir bilgi sisteminin öğeleri ve birbirleriyle ilişkileri gösterilmiştir.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 4.4 - Bilgi Sistemi Öğeleri ve Đlişkileri
4.7.1
Bilgi sistemlerinin faydaları
Đyi tasarlanmış etkin bir bilgi sistemin kazandıracağı bazı faydalar şunlar olabilir:
i)
Daha iyi hizmet
ii)
Daha iyi güvenlik
iii)
iv)
v)
vi)
.
r
g
Ö
Rekabet avantajı
Daha az hata
Büyük ölçüde doğruluk
Yüksek kalitede çıktılar (ürünler)
vii) Sağlıklı haberleşme
viii) Etkinliğin artması
ix)
Verimliliğin artması
x)
Daha etkin yönetim
xi)
Daha fazla fırsatlar
xii) Đşgücü ihtiyacının azaltılması
xiii) Maliyetlerin azaltılması
xiv) Daha etkin finansal kararlar verebilme
xv) Aşırı faaliyetlerin daha etkin kontrolü
xvi) Daha etkin yönetimsel karar verme
Sistem Analizi ve Yazılım Tasarımı
15
Öğr. Gör. Mustafa AKSU
5.
BĐLGĐSAYARA DAYALI BĐLGĐ SĐSTEMLERĐ
Bilgi sistemleri denildiğinde genelde algılanan bilgisayara dayalı bilgi sistemleridir. Bu
dersin konusu olarak da bundan sonra bilgisayara dayalı bilgi sistemleri
anlatılacaktır.
Bilgisayara bağlı bilgi sistemleri şunlardır:
i) Kayıt/Veri Đşleme Sistemleri (VĐS) (Transaction/Data Processing Systems)
ii) Yönetim Bilgi Sistemleri (YBS) (Management Information Systems)
iii) Karar Destek Sistemleri (KDS) (Decision Support Systems)
iv) Ofis Otomasyon/Bilgi Sistemleri (OOS) (Office Automated/Information Systems)
v) Üst Yönetim Destek Sistemleri (ÜDS) (Executive Support Systems)
U
S
vi) Yapay Zeka ve Uzman Sistemler (YZ ve US) (Artificial Intelligence and Expert
Systems)
K
A
Devam eden kısımda yukarıda sıralanan bilgi sistemleri hakkında bilgi sunulmuştur:
5.1. Kayıt/Veri Đşleme Sistemleri (VĐS)
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Bir VĐS, işin yapılması için gerekli günlük rutin muameleleri (transaction) işleyen ve
kaydeden bilgisayara dayalı sistemdir. VĐS, organizasyonun operasyonel seviyesine
hizmet verir. Bu seviyede, görevler, kaynaklar ve amaçlar önceden tanımlanmış
kriterlere göre, düşük seviye bir yönetici tarafından verilebilir. Örneğin bir banka için
bir müşteriye araç kredisi verme kararı, tüm kriterler belirlenmiş olacağı için düşük
seviye bir yönetici tarafından verilebilir.
VĐS, günlük operasyonlarla ilgilenir. Yapılan işlemler, işlem yükü ve hacmi çok
yüksek olan tekrarlı işlemlerdir ve bu işlemlerin nitelikleri çok nadir olarak değişir.
VĐS, verinin saklanması ve çağrılmasına yöneliktir ve bu özelliğiyle asıl konumuz olan
YBS'nin destekleyicisi durumundadır. Bir VĐS'in genel işleyişi Şekil 5.1'de
gösterilmiştir.
.
r
g
Ö
Şekil 5.1 - Bir VĐS Uygulamasının Yapısı
Sistem Analizi ve Yazılım Tasarımı
16
Öğr. Gör. Mustafa AKSU
VĐS programı iki tip çıktı üretir:
i) Operatör terminaline gönderilen mesaj (soft copy)
ii)
Basılmış dokümanlar (hard copy)
Örneğin bilet rezervasyon sistemi için hazırlanan bir program, terminal üzerinde belirli bir
kişiye hangi koltukların satıldığını gösterebilir (soft copy) yada bilet basabilir (hard copy).
VĐS aşağıdaki temel özelliklere sahiptir:
i)
Kaydi işlemlerin elde edilip, kayıtların muhafaza edilmesine yöneliktir,
ii)
Dosya kökenlidir,
iii)
Çıktısı genellikle periyodiktir,
iv)
Öncelikle operasyonel seviye yönetim için bilgi üretir,
v) Yöneticinin özel bilgi istekleri için, sınırlı esnekliğe sahiptir.
U
S
K
A
vi) Bu sistemler tipik olarak fonksiyona dayalıdır. Uygulamalar birbirinden bağımsız olarak
geliştirilir.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
5.2. Yönetim Bilgi Sistemleri (YBS)
YBS, bir örgütün yönetiminde kullanılan bilgilerin işlenmesini ve iletilmesini sağlayan bir
sistemdir.
YBS, zaman içersinde VĐS'in yetersiz kaldığı noktaları kapatmak amacıyla geliştirilmiş
daha kapsamlı sistemlerdir. YBS'nin genel özellikleri şunlardır:
-
YBS, Veri/Kayıt işleme fonksiyonlarını destekler (kayıt saklama vb).
-
YBS, bütünleşik bir veritabanı kullanır ve fonksiyonel alanların çeşitliliğini
destekler.
-
YBS, operasyonel, taktik, ve stratejik seviye yöneticilerin bilgiye kolay ve
zamanında erişimini sağlar. Özellikle yoğun olarak taktik seviye yöneticiler için
hizmet sağlar.
-
YBS, kısmen esnektir ve organizasyonun bilgi ihtiyaçlarındaki değişmeye
adapte edilebilir.
-
YBS, sadece yetkili şahısların erişimine imkan veren sistem güvenliği sağlar.
-
YBS, günlük operasyonlarla ilgilenmez.
-
YBS, genellikle yapısal kararların desteklenmesine yöneliktir.
.
r
g
Ö
-
YBS, yöneticilere değişik raporlar sunar.
-
YBS, öncelikle çevresel ya da dış olaylarla değil büyük ölçüde firma içi
olaylara odaklanır.
Sistem Analizi ve Yazılım Tasarımı
17
Öğr. Gör. Mustafa AKSU
5.2.1
YBS ve VĐS'in farklılıkları
VĐS, YBS için önemli bir firma içi veri kaynağıdır. Zaten, YBS genel anlamda birkaç VĐS
üzerine kurulmuş, örgütün ya da birkaç alt sistemin yönetsel bilgi ihtiyacını karşılamaya
yönelik sistemlerden oluşurlar. VĐS ve YBS arasındaki farklar şunlardır:
-
Yöneticinin bilgi ihtiyacının karşılanmasında YBS'nin bütünleşik veritabanı,
VĐS'in düz dosya ortamına göre daha büyük esneklik sağlar.
-
VĐS, tek bir fonksiyonel alanı desteklemeye yönelmiştir, YBS ise fonksiyonel
alanlar arasındaki bilgi akışını bütünleştirir.
-
Bir YBS, taktik seviyeye yoğun olmakla beraber yönetimin tüm seviyelerine
bilgi ihtiyaçları için hizmet sunarken, VĐS sadece operasyonel seviyeye destek
sağlar.
-
VĐS kaydi işleme yapar. VĐS, bu şekilde YBS için bir veritabanı oluşturur.
VĐS'in çıktıları YBS için girdidir. YBS, VĐS verilerini yönetimin karar vermesi
için bilgi üretiminde kullanır.
U
S
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 5.2. VĐS, YBS ilişkisi
Örnek: Bir bilet rezervasyon sisteminde VĐS, siparişleri alma ve bilet basmada, YBS ise
bilet satan her bir acentenin performansını ölçmede ve rapor etmede kullanılabilir.
Sistem Analizi ve Yazılım Tasarımı
18
Öğr. Gör. Mustafa AKSU
5.2.2 YBS ve iş fonksiyonları
1: Fonksiyonel Bilgi Sistemleri 2: Muhasebe Uygulama Sistemleri 3: Bordro Programları
U
S
Şekil 5.3 - YBS ve Đş Fonksiyonları
Şekil 5.3'te de görülebileceği gibi YBS fonksiyonel bilgi sistemlerinin birleşiminden
meydana gelmiştir. Fonksiyonel bilgi sistemleri uygulama sistemlerinden onlar da
programlardan meydana gelmiştir. Veritabanı Yönetim Sistemleri (VTYS), bu
fonksiyonların aynı veriyi paylaşma yeteneğini artırır.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
5.2.3 YBS ve Veritabanı Yönetim Sistemi (VTYS)
Veri, bir YBS'nin ana kaynağıdır ve bu kaynağın yönetimi oldukça önemlidir. Bir VTYS,
veritabanı denen birleştirilmiş ve koordine edilmiş dosyaların kümesi ile uygulama
programları arasında arayüz olarak hizmet veren bir programdır. Bu ilişki şekil 5.4'te
gösterilmiştir.
.
r
g
Ö
Şekil 5.4 - YBS ile VTYS arasındaki ilişki
Sistem Analizi ve Yazılım Tasarımı
19
Öğr. Gör. Mustafa AKSU
6.
BĐLGĐ SĐSTEMLERĐNĐN GELĐŞTĐRĐLMESĐNDE KULLANILAN ARAÇLAR
Bilgi sistemlerinin analiz ve tasarımında kullanılan araçlardan en önemlileri bu
bölümde tanıtılacaktır.
6.1. Akış Şemaları
Daha önceki bölümlerde akış şemaları hakkında bilgi verilmiş ve kullanılan semboller
gösterilmişti. Akış şemaları genelde iki tiptir:
-
Sistem akış şeması (süreç akış şeması)
-
Program akış şeması
6.2. Veri Akış Diyagramları (VAD)
Veri Akış Diyagramları, sadece 4 adet sembol kullanarak sistemdeki veri akışını
grafiksel olarak izah etmeye yarayan çok kullanışlı bir araçtır. Bilgi sistemi
tasarımcıları tarafından sıklıkla kullanılan bir araçtır ve sistem ne kadar karmaşık olursa
olsun bu diyagramlar sistemi tarif etmek için yeterlidir.
Literatürde VAD'lar için kullanılan iki standart sembol kümesi bulunmaktadır. Her iki
kümede de dörder adet sembol bulunmakta ve semboller farklı olsa da aynı anlamları
ifade etmektedir. Bu derste kullanılacak olan semboller Şekil 6.1'de gösterilmiştir.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 6.1 - VAD Sembolleri
.
r
g
Ö
Bu sembollerin anlamlarını ve kullanılış şekillerini kısaca açıklayalım:
i) Veri Akışı: Bir veri akışı, bir sistemde bir yerden başka bir yere hareket eden veriyi
temsil eder. Yani veri akışı hareket halindeki veridir. Veri akışı bir ok ile gösterilir ve
bu ok üzerinde de o akışın içeriği yazılır. Bu içerik, tek bir veri olabileceği gibi
(Kayıt No gibi) kompozit bir veri de olabilir (satış raporları gibi).
ii) Proses: Prosesler, yapılan bir fonksiyonu ya da aktiviteyi tanımlar. Proseslere
genelde bir isim ve numara verilir. Bu numaralar proses sırasını gösteren
numaralar değildir. Proses ismi olarak da emir cümleleri kullanmak uygun
olacaktır (Brüt maaşı hesapla gibi).
iii) Dışsal Birimler: Bu birimler, veri/bilgi kaynağı ya da verinin/bilginin gideceği yerdir.
Sisteme veri sağlayan ya da sistemden veri alan birisi bu tanıma örnektir. Birimin adı
sembolün içine tekil olarak yazılır ve sembolün sol üst köşesinde de bu birimi
tanımlayan bir harf bulunabilir. Veri akış çizgilerinin kesişmesini önlemek için aynı
birim aynı diyagramda birden çok defa kullanılabilir. Aynı birim aynı diyagramda
birden çok defa kullanılıyorsa sembolün sağ alt köşesine bir diagonal çizilir.
iv) Veri Deposu: Analiz esnasında, verilerin depolanmasına ihtiyaç duyulan yerler olur. Bu
Sistem Analizi ve Yazılım Tasarımı
20
Öğr. Gör. Mustafa AKSU
yerler veri deposu olarak isimlendirilir. Veri deposu, bir raf, dosya kabini ya da bilgisayar
dosyası olabilir. Her bir veri deposu D ile tanımlanır ve referans olması amacıyla D'nin
yanına bir rakam verilir. Her bir veri deposu için ayrıca bir de isim verilir. Dışsal birimde
olduğu gibi aynı veri deposu aynı diyagramda birden çok kullanılırsa sembolün sol
tarafına dikey bir çizgi çekilir.
Genel bir veri akış diyagramı şekil 6.2'de verilmiştir.
Şekil 6.2 - Genel Bir VAD
6.3. Yapısal Şemalar
6.4. Yapısal Dil
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
U
S
K
A
Çoğu durumlarda, bilgi sistemi tasarımı için kullanılan akış şemaları, karar tabloları ve
HIPO gibi araçlardan gerçek programlara geçmek oldukça zor olabilir. YD, VAD'da
bulunan proseslerdeki dönüşüm işlemlerinin nasıl yapılacağını tarif etmek için kullanılır.
YD, bir nevi normal konuşma dilini kullanarak bilgisayar programları yazmaya benzer.
YD, Sahte Kod (SK) (Pseudocode) olarak da bilinir. Bu iki kavram arasında temelde bir
fark olmamakla beraber YD'nin konuşma diline, SK'nın ise programlama diline daha yakın
olduğu düşünülebilir.
Aşağıda bir YD örneği verilmiştir:
Örnek: Firmada Ayda brüt 250 dolardan fazla kazananların listesi
.
r
g
Ö
1- PRINT Rapor Başlığı
2- READ Her bir Personel Verisi
3- Brüt Ödemeyi Hesapla
4- Brüt Ödeme 250 Dolar'dan Fazla mı?
a. Evet ise, PRINT Numara, Oran, Brüt Ödeme
b. Hayır ise, Hiçbir şey Yazma
5- Tüm personel için 2-4 adımları tekrarla
6.5. Karar Tabloları
6.6. Karar Ağaçları
6.7. HIPO
Bilgi sistemi geliştirme araçlarından bir diğeri de IBM tarafından büyük ve karmaşık
çalışma sistemleri için geliştirilmiş olan HIPO (Hierarchy Plus Input-Processing-Output)
tekniğidir. "Nasıl" dan ziyade "Ne" yapılacağı üzerinde yoğunlaştığı için akış
şemalarından farklıdırlar. HIPO'nun 3 temel amacı vardır:
Sistem Analizi ve Yazılım Tasarımı
21
Öğr. Gör. Mustafa AKSU
1)
Sistem fonksiyonlarının parçalara ayrılmış hiyerarşik yapısını göstermek
2) Sistem fonksiyonlarının ayrıntılarını herhangi bir programlama diline bağlı
kalmaksızın göstermek.
3) Sistem fonksiyonları düzeyinde, girdiler ve çıktıları görsel olarak tarif etmek.
HIPO, iki ayrı diyagramdan oluşur:
1) Görsel Đçerik Tablosu: Hiyerarşi diyagramı olarak da bilinir. Đngilizce kısaca
VTOC (Visual Table Of Contents) olarak ifade edilir. Sistemi yukarıdan
aşağıya hiyerarşik bir yapıda modüler olarak ifade eden bir şemadır.
2) HIPO Özet Diyagramı: Đngilizce HIPO Overview Diagram olarak bilinir.
VTOC'taki her bir kutu (modül) için girdi, çıktı ve ana prosesleri gösterir.
Şekil 6.5 ve 6.6'da bir bordro sistemine ait VTOC ve HIPO özet diyagramı örneği verilmiştir.
U
S
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 6.9 - HIPO Özet Diyagramı
Sistem Analizi ve Yazılım Tasarımı
22
Öğr. Gör. Mustafa AKSU
U
S
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Sistem Analizi ve Yazılım Tasarımı
23
K
A
Öğr. Gör. Mustafa AKSU
1 . Yazılım Geliştirme Tekniklerine Giriş
1.1
Tanım
Yazılım sistemlerini tanımlamayı, geliştirmeyi, yönetmeyi ve yeni ihtiyaçlara uyarlamayı
disipline eden mühendisliğe, YAZILIM MÜHENDĐSLĐĞĐ denir.
1.2
Yazılım Ürünleri
YAZILIM ÜRÜNLERĐ
U
S
PAKET ÜRÜNLER
Paket ürünler, bir konu üzerinde
genel ihtiyaca cevap verebilen ve
kolayca satın alınabilen ürünlerdir.
1.3
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Yazılım Ürünlerinin Nitelikleri
Đyi bir yazılımın dört önemli niteliği vardır.
• Bakımı yapılabilir olmalı - Maintainability: Müşterinin değişen ihtiyaçlarına cevap
verebilir olmalı.
•
Güvenilir olmalı - Dependability: Yazılımların makul olan bir güvenirlilik sınırı olmalı.
Güvenilir yazılım, sistem çökmüş olsa dahi, fiziksel veya ekonomik olarak zarar
görmemeli.
•
Verimli Olmalı - Efficiency: Yazılım, hafıza (memory) ve işlemci gibi kaynakları heba
etmemelidir.
•
Kullanılabilir Olmalı - Usability: Yazılım, kullanıcı için kolay bir arayüze ve yeterli bir
dokümantasyona sahip olmalıdır.
.
r
g
Ö
(M) Maliyet
(V) Verimlilik
Şekil 1.1: Maliyet - Verimlilik Grafiği
Sistem Analizi ve Yazılım Tasarımı
24
Öğr. Gör. Mustafa AKSU
1.4
Yazılım Oluşturma Seyri
4 temel aşama vardır.
• Yazılım Tanımları: Yazılımın çalışma esnasındaki fonksiyonları ve sınırlarını
mutlaka tanımlamalı.
•
Yazılım Geliştirme: Yazılım tanımlarına uygun olarak üretilmeli.
•
Yazılımın Geçerliliği: Yazılım müşterinin istekleri sağlıyor olmalı .
•
Yazılımın Tekamül Edilebilirliği: Yazılım müşterinin değişen ihtiyaçlarına cevap
vermeli.
(X) Yapılan Đş
U
S
Đyi Analiz Yapılmış
(Sağlam) Analiz Yapılmamış
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
(T) Süre
Şekil 1.2: Analiz yaptıktan sonra, yazılım geliştirmenin önemini gösteren grafik.
1.5
Yazılım Geliştirme Modelleri
1.5.1 Şelale Modeli – Waterfall:
Yukarıdaki aktiviteler birbirini takip edecek şekilde uygulanır. Sırasıyla ihtiyaçlar
tanımlanır, yazılım tasarlanır, uygulanır, test edilir ve kullanılır.
Đhtiyaç
Tanımları
.
r
g
Ö
Sistem ve Yazılım
Tasarımı
Yükleme ve Birim
Testi
Entegrasyon ve
Sistem Testi
Operasyon ve
Bakım
Şekil 1.3: Şelale Modelinde Đş Akışı
Yazılım Mühendisliğinin en popüler yaklaşımıdır. Diğer mühendislik bilgilerinden
yararlanır. Her bir aşama diğerine zemin oluşturur. Dolayısıyla geliştirme aşamaları diğer
yaklaşımlara göre daha iyi ayrılabilir. Beş tane temel yazılım geliştirme aktivitesi vardır:
• Đhtiyaç analizi ve tanımlarının yapılması
Sistem Analizi ve Yazılım Tasarımı
25
Öğr. Gör. Mustafa AKSU
•
Sistem ve yazılımın tasarlanması
•
Uyarlama ve birim testlerinin yapılması
•
Sistemin bütünleştirilmesi ve sistem testlerinin yapılması
•
Uygulama ve bakım
Yazılım aşamaları düz bir yol takip etmezler. Her bir aşama kendinden önceki aşamalara
sürekli bilgi aktarır(feedback). Birbirini takip eden aşamalarda yapılan başarılı işler,
önceki aşamadaki problemin çözümüne katkı sağlar. Bunun için yazılım mühendisleri
problemleri iyi tanımlayabilmek ve çözümlerini üretebilmek için sık sık önceki aşamaların
bilgilerine geri dönerler.
Dezavantajları: Her bir aşamada önceki aşamalara geri dönülmesi projenin
yönetilmesini zorlaştırır. Bir diğer dezavantajı da şudur: Projenin belirgin kısımlara
ayrılması projenin esnekliğini azaltır.
Modelin Özü: Şelale yaklaşımı yazılım mühendislerinin tecrübelerinin yansımalarıdır.
SONUÇ: Bu yaklaşım büyük yazılım projelerinin geliştirilmesinde kullanılır.
U
S
1.5.2 Tekamül Edilebilir Geliştirme:
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Tanımlamalar
Taslak
Tanımlamalar
.
r
g
Ö
K
A
Đlk Versiyon
Geliştirme
Ara Versiyonlar
Geçerlilik
Son Versiyon
Şekil 1.4: Tekamül Edilebilir Geliştirme Modeli
Bu yaklaşıma göre, tanımlama, geliştirme ve geçerlilik safhaları iç içedir. Çok soyut
tanımlardan başlanılarak yazılım hızla geliştirilir. Daha sonra müşteri ihtiyaçlarına göre
tekrar düzeltmeler yapılır.
Đki çeşit Tekamül Edilebilir Geliştirme modeli vardır.
1.
Keşif programlama: Burada, müşteri ile birlikte onun ihtiyaçlarının tespiti yapılır ve
yazılım geliştirilir. Geliştirme süreci aşama aşamadır. Yazılımın geliştirilmesine en iyi
anlaşılan noktalardan başlanılır. Daha sonra yeni özellikler müşteri ile tartışılarak
eklenir.
2.
Prototip oluşturmak: Bu modelde, öncelikle müşterinin ihtiyaçları öğrenilmeye
çalışılır. Daha sonra oluşturulacak sistemin iyi bir ihtiyaç tanımları yapılır. Bu bilgiler
ışığında bir prototip yazılım oluşturulur.
Tekamül Edilebilir Geliştirme yaklaşımının üç önemli problemi vardır:
1. Aşamalar belirgin değildir.
Sistem Analizi ve Yazılım Tasarımı
26
Öğr. Gör. Mustafa AKSU
2. Sistem zayıf bir temel üzerindedir.
3. Özel beceri ve tecrübelere sık, sık ihtiyaç duyulur.
1.5.3 Biçimsel Dönüşme:
Bu yaklaşım bir yazılım için matematiksel metotlar kullanılarak biçimsel bir matematik
tanımını ve bu tanımın dönüşümünü temel alır. Bu dönüşümler yazılımda hataların
oluşmasını engeller. Yazılımın geliştirilmesi daha güvenli olur.
1.5.4 Tekrar Kullanılabilir Bileşenlerle Sistem Oluşturma:
Bu yaklaşım, öncelikle sistemde parçaların var olduğunu düşünür. Yazılımın zorlanarak
geliştirilmesi yerine, sistem geliştirme aşamaları, var olan bu parçalara odaklanır.
1.6
1.7
Đşlem Karakteristikleri
•
Anlaşılabilirlilik - Understandability
•
Görünebilirlilik - Visibility
•
Desteklenebilirlilik - Supportability
•
Kabul Edilebilirlilik - Acceptability
•
Rehabilite Edilebilirlilik - Reliability
•
Zindelik - Robustness
•
Bakımı Yapılabilir - Maintainability
•
Hız – Rapidity
Risk Yönetimi
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Belki bir projede en çok kontrol edilmesi gereken noktalardan bir risklerdir. Đyi bir risk
yönetimi için, risklerin belirlenmesi en başta gelen unsurdur. Daha sonra bu riskleri
indirgemek (düşürmek) için belli yöntemler kullanılır. Projede iyi bir risk yönetimi için
aşağıdaki noktalara dikkat edilmelidir.
• Hedefler
: Analizin amaçları
.
r
g
Ö
•
Sınırlamalar
•
Alternatifler
: Hedeflere ulaşmanın birden fazla yolları olması
•
Riskler
: Her alternatifin risklerinin belirlenmesi
•
Risk Çözümleri
: Risklerin azaltılması için uygulanan stratejiler
•
Sonuçlar
: Uygulanan strateji sonuçları
•
Planlar
: Bir sonraki aşama analizi için planlama
•
Taahhüt
: Aşamaların nasıl olacağını belirleme
: Proje sınırlarının en uygun şekilde belirlenmesi
Sistem Analizi ve Yazılım Tasarımı
27
Öğr. Gör. Mustafa AKSU
2 . Proje Yönetimi
Yazılım mühendisliğinin diğer mühendisliklerden temel farklılıkları:
a) Ürünleri sanaldır.
b) Yaptığı işlemlerde belli bir standartlık yoktur.
c) Büyük yazılım projeleri sıkça tekrarlanmaz.
2.1
Yönetim Aktiviteleri
Başarılı projeler gerçekleştirmek için, başarılı bir yönetim şarttır. Bir yazılım projesinde
başarısı öncelikle organizasyonun başarısına bağlıdır. Ayrıca yazılımın içeriği de çok
önemlidir. Bundan dolayı çoğu proje yöneticileri, projeyi belli aşamalara ayırır ve her bir
aşamada neleri yapması gerektiğini belirler. Bunları şöyle sıralayabiliriz:
a) Teklifin yazılması
U
S
b) Projenin fiyatlandırılması
c) Proje planı ve programı
d) Proje izleme ve yeniden inceleme
e) Personel seçimi ve değerlendirilmesi
f)
Rapor yazma ve projenin takdimi.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Bir projede en önemli noktalardan biri de personel seçimidir. Her proje yöneticisinin en
büyük arzusu ideal bir proje ekibi oluşturmaktır. Ama bu genellikle mümkün olmaz.
Temel neden olarak şunları sıralayabiliriz:
a) Proje bütçesi yeterli olmayışı
b) Proje personelinin birbirleri ile olan olumsuz ilişkilileri
c) Deneyimsiz personel veya tecrübe kazanması gereken personel kullanmak
zorunluluğunun oluşması.
2.2
Plan
Proje Planlaması
.
r
g
Ö
Açıklama
Kalite planı
Geçerlilik planı
Proje içinde kullanılacak kalite işlemleri ve standartlarının tanımları
Sistem geçerliliği için kullanılacak yaklaşımlar, kaynaklar ve
programlar açıklanır.
Konfigürasyon
planı
Kullanılacak yapılandırma yönetim aşamaları ve yapısının tanımları
Bakım planı
Sistemin bakım ihtiyaçları, bakım maliyeti ve bakım için gerekli
eforun tahmin edilmesi
Personel
yetiştirme
planı
Proje ekip üyelerinin deneyimlerinin ve mantığının nasıl artırılacağı
tanımlanmalı
2.2.1 Proje Planı
Proje planının genel kabul gören aşamalarını şöyle sıralayabiliriz.
1. Giriş (projenin hedefleri, sınırları, bütçesi,süresi vb.)
2. Proje organizasyonu (proje ekibinin oluşturulması )
3. Risk analizi
4. Donanım ve yazılım kaynak ihtiyacı
Sistem Analizi ve Yazılım Tasarımı
28
Öğr. Gör. Mustafa AKSU
5. Đş kesintileri (personelin hastalanması, teknik arızaların oluşma ihtimalleri
gibi.)
6. Proje Programı (ne kadar zaman hangi işlemlerin yapılıp, hangi aşamada
olduğunuzu belirlenmesi vb.)
7. Đzleme ve raporlama mekanizması
2.3
Aktivite Organizasyonu
Fizibilite
Çalışması
Đhtiyaç
Analizi
Prototip
Geliştirme
Tasarım
Çalışması
Đhtiyaç
Özellikleri
Fizibilite
Raporu
Đhtiyaç
Tanımları
Geliştirme
Raporları
Mimari Tasarım
Đhtiyaç
Özellikleri
Şekil 3,1: Đhtiyaç Analizi aşamalarını gösteren şema.
2.4
Proje Programı
U
S
K
A
Projenin her aşaması en detaya kadar programlanır. Bu cümleyi biraz açarsak, her bir
proje aktivitesi belli bir kriter altında detaylandırılır. Bu kriter genellikle adam/gün’dür.
Proje programını etkileyen bir diğer unsur, proje aşamalarının hatta aşama detaylarının
birbirleri ile olan ilişkileridir. Süreler ve ilişkiler şematik olarak gösterilir. Böylelikle hem
proje yöneticisi, hem de diğer personel projenin seyri hakkında bilgilenmiş olur.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
2.4.1 Aktivite Bar Grafiği ve Aktivite Ağı
Örnek 3.1: Tablo 3.1’de görev isimleri, süresi ve birbirlerine bağımlığı verilen projenin
işlem ağını ve aktivite bar grafiğini gösterin.
Görev
r.
g
Ö
Geçen Süre
(Gün)
Bağımlılığı
G1
8
-
G2
15
-
G3
15
G1
G4
10
-
G5
10
G2, G4
G6
5
G1, G2
G7
20
G1
G8
25
G4
G9
15
G3, G6
G10
15
G5, G7
G11
7
G12
10
G9
G11
Tablo 3.1: Görev isimleri, süreleri ve bağımlılıklarını gösteren tablo
Sistem Analizi ve Yazılım Tasarımı
29
Öğr. Gör. Mustafa AKSU
Đşlem (Aktivite) Ağı (Şekil 3.2)
8
gün
G1
03.06.2002
Başlangıç
13.06.2002
K1
15
gün
G2
20
gün
G7
11.07.2002
K7
15
gün
G3
05.07.2002
K4
5
gün
G6
01.07.2002
K6
10
gün
G5
17.06.2002
K3
G2
G4
G3 K1
.
r
g
Ö
G7
25
gün
G8
7
gün
G11
24/06
10
gün
G12
06.08.2002
K11
01.08.2002
K10
U
S
08.07.2002
K5
01/07
12/08
K
A
Bitiş
19.08.2002
Kritik Hat
22.07.2002
K8
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Aktivite Bar Grafiği
03/06 10/06 17/06
G1
26.07.2002
K9
15
gün
G10
24.06.2002
K2
10
gün
G4
15
gün
G9
08/07
19/08
15/07
Normal Hat
K
Kilometre Taşı
G
Görev
22/07
29/07
05/07
K8
G8
K6,K5
G5
G6
K9
G9
K10
G10
G11
G12
Yukarıdaki şekilde (K) harfleri kilometre taşlarını, (G) harfleri ise görevleri sembolize
ediyor. Şekil 3.2 bir projenin aktivite ağını gösteriyor. “Hangi aktiviteyi veya işi, hangi iş
takip ediyor?" sorusuna bu şekil cevap verebiliyor. Ayrıca kalın çizgi ve taralı hücrelerle
gösterilen dal, projenin kritik işlerinin olduğu iş sürecidir. Burada oluşabilecek bir gecikme
projenin gecikmesine sebep olur/olabilir.
Sistem Analizi ve Yazılım Tasarımı
30
Öğr. Gör. Mustafa AKSU
3 . Đhtiyaç Mühendisliği
3.1
Tanım
Sistem hizmetlerinin tespit edilmesini ve sistem hangi operasyonlar altında çalışıyorsa
onun sınırlarının belirlenmesini sağlayan mühendisliğe ĐHTĐYAÇ MÜHENDĐSLĐĞĐ (Đ.M.)
denir.
Fonksiyonel Đhtiyaçlar: Sistem fonksiyonun veya sunduğu hizmetlerin tanımlanması ile
ortaya çıkar.
Fonksiyonel Olmayan Đhtiyaçlar: Sistem sınırlarının veya geliştirme işlemlerinin
tanımlanması ile ortaya çıkar.
Đ.M.nin ihtiyaç tanımlamasını iki ana aşamaya ayırabiliriz. Birincisi, ihtiyaç tanımlarıdır ki,
soyut ihtiyaç tanımlarının yapılmasıdır. Đkincisi ise, ihtiyaç nitelikleridir; Bunlarda sistemin
ne yaptığını detaylandırarak tanımlanması ile ortaya çıkar. Bu iki aşamanın daha da
detaylandırılarak, Đ.M. ile tasarım aktiviteleri arasında bir köprü kurmasını sağlayan detay
tanımlamalar (yazılım nitelikleri) vardır.
Đhtiyaç Tanımları: Sistem hangi operasyonlar altında çalışması ve sınırlarının
belirlenmesi sonucunda, hangi hizmetleri sunacağının, konuşulan dil veya diyagramlar ile
belirlenmesidir.
Đhtiyaç Nitelikleri: Sistemin sunduğu hizmetlerin detaylı olarak anlatıldığı dokümandır.
Bu doküman, fonksiyonların nitelikleri diye de adlandırılır; çok iyi hazırlanmış olmalıdır.
Bu doküman sistem alıcısı ile yazılım geliştirici kurumlar arasındaki kontrat olabilmelidir.
Yazılım Nitelikleri: Yazılımın tasarımına ve uyarlanmasına temel olacak detaylı
tanımların ortaya konmasıdır. Bu niteliklere, ihtiyaç niteliklerinin detaylandırılması
esnasında da ekler yapılabilir.
Đ.M.nin işlevi, ihtiyaçların tanımlarını yazılı olarak yapmak, sonra da bu tanımları ihtiyaç
niteliklerine
göre
de
genişletebilmektir.
Aşağıda
ihtiyacın
tanımlanması
ve
detaylandırılmasına bir örnek verilmiştir.
U
S
3.2
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Đhtiyaç Mühendisliği Đşlevleri
Đ.M. ihtiyaç tespitini dört temel aşamada yapar.
1. Ön-Hazırlık - Feasibility: Fiyat- Performans ilişkisi
2. Đhtiyaç Analizi: Prototip Oluşturma
3. Đhtiyaç Tanımları: Aktiviteleri en detaylı şekilde
dokümantasyon.
4. Đhtiyaç Nitelikleri: Ayrıntılı ihtiyaç dokümantasyonu.
.
r
g
Ö
Ön
Hazırlık
Đhtiyaç
Analizi
Ön Hazırlık
Raporu
Sistem
Modelleri
yazılı
olarak
tutan
Đhtiyaçların
Tanımı
Đhtiyaç
Nitelikleri
Đhtiyaçların
Tanımı
Đhtiyaç
Nitelikleri
Đhtiyaç
Dokümantasyonu
Şekil 3.1: Đhtiyaç Mühendisliği Đşlevleri
Sistem Analizi ve Yazılım Tasarımı
31
Öğr. Gör. Mustafa AKSU
3.3
Yazılım Đhtiyaç Dokümantasyonu
Yazılım ihtiyaç dokümantasyonunun iyi olabilmesi için aşağıdaki 6 noktanın altı
çizilmelidir.
• Sadece sistemin genel yapısı olmalıdır.
•
Uyarlamadaki sınırlar belirlenmelidir.
•
Kolayca değiştirilebilir olmalıdır.
•
Sistem onarıcılarına referans belge olmalıdır.
•
Sistemin sürekliliği hakkında ön bilgiler içermelidir.
•
Đstenmeyen olaylar karşısında uygun çözümler içermelidir.
Yazılım ihtiyaç dokümantasyonunun genel yapısı şöyle olmalıdır.
Giriş: Sistemin genel olarak tanıtır.
Sözlük: Dokümanda kullanılan teknik terimleri açıklar.
Sistem Modelleri: Sistem bileşenleri ile sistemin çevresi arasındaki ilişkileri gösteren
modelin oluşturulması.
Fonksiyonel Đhtiyaç Tanımları: Kullanıcılara sağlanan hizmetlerin tanımlanmasını
içerir.
Dolaylı Đhtiyaç Tanımları: Yazılımın ve tasarımcının sınırlarının belirleyen doküman.
Sistem Geliştirme: Sistemin gelecekte ihtiyaç duyacağı değişikliklerin belirtilmesi.
Đhtiyaçların Detaylandırılması: Özellikler fonksiyonel ihtiyaçların detaylandırılmasını
içerir.
Ayrıca donanım ihtiyaçları, veri tabanı ihtiyaçları ve dokümanın sonunda da indeks yer
alır.
U
S
3.4
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Đhtiyaç Geçerliliği
Đhtiyaç belirlemedeki kriterler;
• Geçerlilik: Sistemin fonksiyonları düşünülmelidir; Ayrıntılı analiz yapılır.
•
Uyumluluk: Đhtiyaçların birbirleri ile çakışmaması.
•
Bütünlülük:
Kullanıcının
tanımlayabilmek.
•
Gerçeklilik : Detaylı Đhtiyaç tespiti gerçekçi olmalı.
.
r
g
Ö
tasarladığı
fonksiyonları
ve
sınırları
iyi
Bu noktalara gereken önemin verilmesi durumunda, yazılımın kabiliyeti ve gündemde
kalma süresi artar. Bu da yazılımın maliyet fiyatının azalmasında önemli bir etkendir.
Ayrıca şu noktalara da dikkat edilmelidir.
a) Doğruluğu kanıtlanabilir: Đhtiyaç olarak tespit edilenler, somut olarak test
edilebilirler mi?
b) Anlaşılabilirlilik: Đhtiyaç olarak tespit edilenler, kullanıcılar ve proje geliştiricileri
tarafından net bir şekilde anlaşılabilir midir?
c) Đzlenebilirlilik: Đhtiyacın doğuş nedeninden başlayarak, tüm aşamalarının takip
edilebilir olmasıdır.
d) Adapte edilebilirlilik: Đhtiyaçlardaki bir değişikliliğin, sistemin genel yapısı
bozmadan yapılabilir olmalıdır.
Sistem Analizi ve Yazılım Tasarımı
32
Öğr. Gör. Mustafa AKSU
Đhtiyaç Problem
Raporu
Đhtiyaç
Tespiti
Đhtiyaç
Tanımları
Đhtiyaç
Analizi
Đhtiyaç Veri Tabanı
Şekil 3.2: Đhtiyaç Kontrol Şeması
3.5
Đhtiyaç Gelişimi
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
U
S
K
A
Đhtiyaç geliştirme acısından bakıldığında, ihtiyaçlar iki sınıfa ayrılırlar.
a) Sürekli (Dayanıklı) Đhtiyaçlar: Bunlar organizasyonun ana faaliyetlerinden çıkarılan
ihtiyaçlardır. Doğrudan sistemin merkezi ile ilgilidir. Örnek; bir hastanede hastaların,
doktorların, hemşirelerin sürekli ihtiyaçları vardır.
b) Geçici Đhtiyaçlar: Sistemin geliştirilmesi esnasında veya sistemin çalıştırılmasında
sonra değişebilen ihtiyaçlardır. Örnek; hükümetleri sağlık politikalarındaki değişmelere
bağlı değişiklilerden kaynaklanan ihtiyaçlar.
4. Đhtiyaç Analizi
Giriş
Đhtiyaç Mühendisliğinin (Đ.M.) neler yaptığını bir önceki bölümde inceledik. Aslında
incelediğimiz konular Đ.M.nin yaptığı yegane işler değil. Đ.M.nin bir diğer önemli işlevi de
ihtiyaç analizidir.
Đhtiyaç analizi (Đ.A.), yazılım geliştirme ekibi ile müşteri yetkililerinin bir araya gelerek,
sistemin performansına bağlı olarak yapılır.
Đyi bir sistem geliştirebilmek için, kullanıcıların sistemden neler beklediğini çok iyi tespit
etmek gerekir. Đhtiyaçlar çok titiz bir incelemeye tâbi tutulmalıdır. Müşteri için gerçekten
gerekli olan ihtiyaçlara sağlıklı bir şekilde ulaşılmalıdır. Yoksa sistemin başarısı zedelenir.
Đ.A. iyi bir sistem oluşturmanın ilk adımlarından biridir; bu yüzden Đ.A. yapılırken bazı
zorluklarla karşılaşılır. Bunları şöyle sıralayabiliriz:
1. Müşteri sistemden tam olarak neler beklediğini ifade edemez. Bir başka
durumda, müşteri çok gerçekçi olmayan isteklerde bulunabilir.
.
r
g
Ö
2. Yazılım geliştirme ekibi, özelliklede Đ.M., müşterinin çalışma konusu ile ilgili
bilgileri ve deneyimi genellikle azdır. Dolayısıyla, yapılan işin sistemdeki tam
karşılıklarını bulmak Đ.M. için zor olabilir.
3. Kullanıcıların farklı istekleri olur. Đ.M. bu istekler arasındaki farklığı ve istekler
arasındaki uyumsuzluğu belirlemesi zordur.
4. Analiz esnasındaki politik isteklerin ortaya çıkardığı zorluklar.
5. Analiz esnasındaki ekonomik ve iş ile ilgili zorluklar.
Sistem Analizi ve Yazılım Tasarımı
33
Öğr. Gör. Mustafa AKSU
Đhtiyaç Tanımları
ve Nitelikleri
Đhtiyaç
Geçerliliği
Öncelikler
Yapının
Anlaşılması
Proje Girişi
Çakışmaların
Çözümü
Đhtiyaçların
Toplanması
U
S
Sınıflandırma
Şekil 4.1: Đhtiyaç Analizi Đşlemleri
K
A
Şekil 4.1’deki işlemler iteratif ve birbirleri arasında geri beslemesi çok olan bir yapıya
sahipler. Đşlemler, yapının anlaşılması ile başlayan ve ihtiyaç geçerliliği ile sona eren bir
dairesel yapıda görülebilir. Her bir döngüde ihtiyaç analistleri sistemin ihtiyaçlarını biraz
daha anlarlar.
Aktiviteler:
a) Yapının anlaşılması: Analistler, uygulama alanının anlaşılmasını geliştirmek
zorundadır. Dolayısıyla eğer sistem bir supermarket için geliştiriliyorsa,
analistler supermarket için gerekli bütün ihtiyaçları ortaya koymak zorundalar.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
b) Đhtiyaçların toplanması: Bu işlem kullanıcılar ile beraber çalışılarak yapılmalıdır.
Bu çalışma esnasında sistemin anlaşılması da netlik kazanır.
c) Sınıflandırma: Đhtiyaçların toplanması ve
sınıflandırılması bu işlemin içeriğini oluşturur.
birbirleri
ile
uyumlu
olarak
d) Çakışmaların çözümü: Bir çok kullanıcının isteklerini söylediği bir ortamda
isteklerin birbirleri ile uyumsuzluğu da kaçınılmaz olur. Burada yapılan iş, önce
hangi isteklerin çakıştığının tespiti, daha sonra bunlara çözümlerin
üretilmesidir.
.
r
g
Ö
e) Öncelikler: Đhtiyaçlar detaylı olarak belirlendikten sonra istekler önem sırasına
konulmasıdır.
f)
Đhtiyaçların geçerliliği: Đhtiyaçlar kullanıcıların istekleri doğrultusunda
belirlendikten sonra hangi ihtiyacın neden ortaya çıktığı ve öneminin ne
olduğunun belirlenerek, ihtiyacın gerekliliğinin ortaya konmasıdır.
Đhtiyaçların belirlenmesinde
incelemeye çalışacağız.
değişik
metotlar
uygulanabilir.
Bunlardan
iki
tanesini
4.1. Bakış Açısı Temelli Analiz
Herhangi bir orta boy veya büyük boy sistemlerde, değişik ilgili alanlarına sahip bir çok
kullanıcılar vardır. Her kullanıcı sistemin bütününe kendi bakış açısı ile bakar. Dolayısıyla
her birinin ihtiyacı farklı olur. Bütün ihtiyaçları toplayıp, çakışmalarını önleyebilmek çok
zordur. Bunu bir örnek ile açıklamaya çalışalım:
Bir banka için otomatik vezne işlemleri gerçekleştirecek bir sistem kurmaya çalışalım.
Örneğimizin içinde bulunabilecek aktörlerin ihtiyaçlarını ayrı, ayrı inceleyelim.
Banka müşterileri: Sistemden sağlıklı ve hızlı servis almayı isterler.
Bankamız ile ortak çalışan diğer banka yetkilileri: Karşılıklı olarak otomatik
makineleri kullanma izni veya kullanım anlaşması yapılmasını isterler.
Sistem Analizi ve Yazılım Tasarımı
34
Öğr. Gör. Mustafa AKSU
Sistemi kullanan diğer departmanların yöneticileri: Sistemden kendi bölümlerini
ilgilendiren bilgilerin sağlanmasını isterler.
Sistemin kurulduğu yerlerdeki makineden sorumlu görevliler: Bunlarda makinenin
sürekli çalışmasını isterler; bundan dolayı ortaya çıkabilecek sorunların çözümleri ile ilgili
istekleri olur.
Veri yöneticileri: Bankanın müşteri verilerini kullanabilme konusunda isteklerde
bulunabilirler.
Banka güvenlik yöneticileri: Herhangi bir tehlikeye karşı güvenliğin sağlanması ile ilgili
isteklerini ortaya koyarlar.
Đletişim mühendisleri: Otomatik vezne ile diğer makinelerin iletişimleri ile ilgili
sorumlulukları çerçevesinde isteklerini bildirirler.
Bankanın pazarlama bölümü: Otomatik veznenin, müşterilere nasıl daha cazip
sunulabileceği konusunda isteklerde bulunurlar.
Donanım ve yazılım mühendisleri: Kullanılacak donanım ve yazılımların bakımı ile ilgili
isteklerde bulunurlar.
Banka personel yöneticisi: Sistemin oluşturulmasında ve servisinin
sağlanmasın
kullanılacak personel ile ilgili istekleri olur.
Tabii yukarıda bahsi geçen kişilerin bazılarının ihtiyaç analizindeki etkileri diğerlerine göre
daha çok veya az olabilir. Ayrıcı bu kişilerin isteklerinin bazıları makul istekler olmayabilir.
Ama yukarıdaki listede belirtilen bütün kişiler sistemin bütününe, kendi açılarından veya
başka bir değişle farklı açılardan bakarlar. Bu kadar bakış acısı içinde hangilerinin ne
kadar önemli olduğunun belirlenmesi, ihtiyaçların belirlenmesindeki hataları da belirler.
Her bir bakış, sisteme, sistemin farklı bir yönünden bakar.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
PROBLEM!!!
.
r
g
Ö
Şekil 4.2: Ortada bulunan problemin çözümü için değişik bakış açıları
Bu metodun avantajlarını şunlardır.
• Çok büyük sistemlerde, kullanıcılar kendilerini sistemin alıcıları gibi görürler.
•
Ama kullanıcılar sisteme dışardan bakarlar.
•
Hangi bakış açısı ile sisteme bakıldığına ve bu bakış açısının sistem ile ne kadar
etkileşim içinde olduğuna daha kolay karar verilir.
•
Aynı bölümdeki değişik kullanıcılar, bölümleri ile ilgili fonksiyonel olmayan
fakat kullanışlı ihtiyaçlardan bahsedebilirler.
4.2
Metot Temelli Analiz
Bu analiz tipi, çok geniş uygulama alanı bulabilen bir analiz metodudur. Analiz sonuçları
bir sistemin modelini oluşturur. Metodik analizin değişik vurgu noktaları vardır. Aşağıda
bu noktalar veriliyor. Analiz yapılırken bazen bunların hepsi veya bazıları ön plana çıkar.
Đşlem modeli: Uygulanan metot içinde aktivitelerin tanımlanmasıdır. Aktivitelere örnek
olarak, veri akış analizi, ihtiyaç niteliklerini netleştiren senaryo çalışmaları gibi. Aktiviteler
Sistem Analizi ve Yazılım Tasarımı
35
Öğr. Gör. Mustafa AKSU
belli bir sırada yer alır.
Sistem modelleme işaretleri: Bu işaretlemeler, şemalarla, formlarla veya dilsel olabilir.
Örnek, veri akış şeması, nesne yapı diyagramı gibi.
Sistem modeli üzerinde tanımlanan kurallar: Kurallar bir modül veya modüller
üzerinde tanımlanırlar.
Tasarım rehberi: Uygulanması zorunlu olmayan bir faaliyettir. Fakat uygulanması
durumunda sistem her halükarda tasarlanır. Belki zayıf bir tasarım olabilir ama elinizde
bir yapı bulunur. Örnek, bir modelin en fazla 3 alt modülü olabilir kuralı gibi.
Rapor şablonları: Analiz esnasında elde edilen bilgilerin nasıl sunulacağını tanımlar.
4.3. Sistem Đçeriği
Analiz çalışmasının hemen başında yapılması gereken iş, sistemin sınırlarının
belirlenmesidir. Belki en önemli nokta, sistem ile sistemin çevresi tanımının iyi
yapılmasıdır. Bazı durumlarda sistem ile çevre ilişkisi çok net olarak ayırt edilebilir.
Örneğin, var olan manuel bir sistem yerine otomatik bir sistem getirilecek ise, eski çevre
tanımı değişmeden kalabilir.
Analiz şöyle de tanımlanabilir; bir sisteme neyin ekleneceğine ve neyin çıkarılacağına
karar verme işlevidir.
Sistemin sınırlarının belirlenmesi, sistemin içeriği ve bağımlılığının tanımlanması
demektir. Blok diyagramlar sistemin çevresini tanımlar. Fakat sistem ile diğer sistemler
arasındaki ilişkiyi anlatmaz.
Bu ilişkileri gösterebilmek için blok diyagram, çevrenin modellenmesindeki detayları
ortaya koymanın ilk aşamasıdır. Modelleme tiplerine örnekleri şöyle verebiliriz:
• Veri-Akış Modeli: Sistem içinde veri işlenen modelini gösterir.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
•
Semantik Veri Modeli: Sistem modellemenin bu tipi, sisteme verilen verinin
veya sistemden alınan verinin mantıksal yapısını tanımlar. Böylelikle sistemin
mevcudiyeti, nitelikleri ve diğer parçalarla olan ilişkileri kolayca gösterilir.
•
Nesne Modelleri: Bu modeller sistemin varlığının mantıksal bir tanımını yapar.
Sistemi tasnifler ve parçaları bir araya getirir. Đşlevsel model ile veri modelini
birleştirir. Son kullanıcıların anlamakta zorlandığı bir modeldir.
•
Veri Sözlüğü: Projenin başından sonuna kadar sistem ile ilgili bilgilerin
anlaşılabilmesi için çok önemli bir araçtır. Her türlü sistem modelini destekler.
Analize, tasarım esnasında veya her hangi bir zamanda eklenebilir.
.
r
g
Ö
Güvenlik
Sistemi
Hesap Sistemi
Hesap Veri
Tabanı
Otomatik Vezne
Sistemi
Sayaç Sistemi
Kullanılan Veri
Tabanı
Bakım Sistemi
Şekil 4.3: Otomatik vezne sisteminin içeriği
Sistem Analizi ve Yazılım Tasarımı
36
Öğr. Gör. Mustafa AKSU
4.4. Sosyal Organizasyon Faktörü
Çevre ihtiyaç analizini etkiler. Sosyal ve organizasyon faktörlerini dikkate almayan
metotlar zayıf metotlardır. Đnsan ve yapılan işin niteliği etki faktörleri olarak mutlaka
dikkate alınmalıdır. Đyi bir ihtiyaç analizi için, insan ve organizasyon etkilerine karşı
duyarlı olan bir çalışma yapılmalıdır. Bu etkilerin iyi tanımlanamaması, analiz donatılarını
sistematik bir yapıdan çıkarır ve sonucu kötü yönde etkiler.
Etnoloji, sosyolog ve sosyal antropologun ciddi bir zamanı, çalışma koşullarını
gözlemleme çalışması ile geçer. Bu çalışmada sosyal bilimciler gerçek organizasyon
işlemlerini keşfetmeyi hedeflerler.
Etnolojik
Analiz
Toplantılarda
Bilgilenme
Sistem
Geliştirme
Sistem
Prototipi
Sistem
Prototipi
Şekil 4.4: Đhtiyaç analizi için etnoloji ve prototip oluşturma
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Etnolojik
Analiz
Sistem
Prototipi
U
S
Prototip
Geliştirme
K
A
Yapısal Analiz
Đhtiyaç
Nitelikleri
Prototip
Geliştirme
Şekil 4.5: Etnolojik, prototip ve yapısal analiz
.
r
g
Ö
Şekil 4.4 ve 4.5 ihtiyaç analizi için kullanılan iki farklı model.
Sistem Analizi ve Yazılım Tasarımı
37
Öğr. Gör. Mustafa AKSU
5. Yazılım Tasarımı
Yazılım tasarımı için, üç önemli nokta.
1. Yazılımın içeriğinin iyi anlaşılması ve üzerinde detaylı bir çalışmanın yapılması,
2. En azından bir tane modelin oluşturulması,
3. Tasarımda kullanılan her bir soyut kavramın tanımlanması.
5.1.
Tasarım
Đnformal
Tasarım
Taslağı
Đnformal
Tasarım
Daha
Formal
Tasarım
Tasarım
Sonu
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Şekil 5.1: Tasarım Đnformal durumdan detay durumuna ilerlemesi
Tasarım esnasında, hatalardan, yanlış kararlardan veya gereksiz olduğuna karar verilen
aşamalardan proje ayıklanır. Ayıklama operasyonu ne kadar tasarımın başında olursa
aksamalarda da o kadar az olur. Bu da tasarım esnasında, aşamalara arasında kuvvetli
bir geri beslemenin (feedback) sağlanması ile mümkündür.
Şekil 6.2’de tasarımın değişik evrelerinde tasarım işlevleri ve tanımlamaları gösteriliyor.
Evreler arasında katı bir bağımlılık yok. Fakat projenin yönetimini kolaylaştırmak ve
tasarım evrelerini görünür kılabilmek için evreleri iyi tanımlamalıyız. Şekil 6.2’deki evreler
birbirlerini takip eden evreler veya işlemlerdir (process). Ama gerçekte tasarım
işlemlerinden bazıları paralel olarak gerçekleşir. Dolayısıyla işlemler, büyük bir yazılım
için, belli bir sırada yazılımın bütün parçalarını gösterirler.
.
r
g
Ö
Sistem Analizi ve Yazılım Tasarımı
38
Öğr. Gör. Mustafa AKSU
)
Ü
ĐHTĐYAÇ
TANIMLARI
Soyut
Tanımlar
Mimari
Tasarım
Sistem
Mimarisi
U
S
K
Ara Yüz
Tasarımı
Ara Yüz
Tanımları
Bileşenlerin
Tasarımı
Yazılım
Tanımları
Şekil 5.2: Tasarım işlemleri ve aralarındaki ilişkiler
fa
a
t
s
Bileşenlerin
Tanımları
r
ö
G
.
Ö
r
g
Sistem Analizi ve Yazılım Tasarımı
39
Veri Yapısı
Tasarımı
Algoritma
Tasarımı
A
u
M
.
.
S
.
(K
Öğr. Gör. Mustafa AKSU
Veri Yapısı
Tanımları
Algoritma
Tanımları
Şekil 6.2’deki aktiviteleri inceleyelim.
Mimari tasarım: Alt-sistemleri birleştirerek sistem oluşturulur. Alt-sistemlerin birbirleri ile
ilişkilerini ve sistem içindeki yerinin belirlenmesi. Bütün bunların dokümantasyonu.
Soyut tanımlar: Her bir alt-sistemin, işlevini gerçekleştirmesi esnasındaki sınırlarının
belirlenmesi, sunduğu servisin soyut tanımlarının yapılması.
Arayüz tasarımı: Her bir alt-sistemin, diğer alt-sistemler ile olan ara yüzlerinin tasarımı ve
dokümantasyonu.
Bileşenlerin tasarımı: Servisler farklı bileşenlerden oluşurlar. Bu bileşenlerin tasarımı ve her
birinin ara yüzlerinin tasarımı.
Veri yapısı tasarımı: Sistem uyarlanmasında kullanılacak veri yapısının detaylı ve açıkça
belirtilmiş bir şekilde tasarımı.
Algoritma tasarımı: Oluşturulan modüllerin oluşturulmasında kullanılacak algoritmaların
detaylı ve açıkça belirtilmiş bir şekilde tasarımı.
Bu aktiviteler her bir alt-sistem için tekrarlanır. Bunun sonucunda aşamaların her birinin
programlama dilindeki karşılıkları kolayca tespit edilir. Böylelikle sistemin dijital ortama
aktarımı sağlanır.
5.1.1.
U
S
Tasarım Metotları
K
A
Yapısal Metot:
Yapısal metotta, şekillerle ifade edilen detaylı bir dokümantasyonun hazırlanması en önemli
noktadır. Büyük ölçekli projelerde bu metodun kullanılmasında fayda vardır. Dikkatli
hazırlanan dokümantasyon, proje akışında karşılaşılması muhtemel bir çok problemin,
önceden tespit edilerek çözümlenmesini sağlar. Bu da proje maliyetinin aşağıya çekilmesine
önemli ölçüde katkı sağlar. Yapısal metodun daha öncede gördüğümüz gibi, işaretleme
hazırlığı, rapor formatı belirleme, kurallar belirleme ve tasarım rehberi hazırlama gibi bazı
faaliyetleri vardır. Yapısal metot birçok modelin kısmî veya bütün olarak destekler. Bunlar;
• Veri akış modeli: Sistemdeki verilerin akış diyagramları,
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
•
Varoluş-Bağlantı modeli: Mantıksal veri yapısının tanımlanması,
•
Yapısal model:
hazırlanması,
•
Nesne Tabanlı: Nesneler diğer nesnelerden oluşmaktadır.
Sistem
bileşenleri
ve
etkileşimlerinin
dokümantasyonunun
Matematiksel Metot:
Bu metodun stratejisi, uygulayıcısına bağımlı kalmadan, aynı sonuca ulaşabilmektir. Başka
bir değişle, tasarımcılar aynı verilerden hareket ederlerse, aynı sonuca ulaşırlar. Bu da,
takip edilen yolun detaylı belirlenmesi ve geçmiş tecrübelerin somutlaştırılarak sunulması ile
olur. Tasarımcı üretkenliğini hazır sunulan seçenekler içinde tercih yapmakta kullanır.
.
r
g
Ö
5.1.2.
Tasarım Tanımlama
Yazılım tasarımı, yaşadığımız dünyadaki herhangi bir sistemin varlık nedeni ve ilişkilerinin
tanımlanması demektir. Bu değişik şekillerde yapılmaktadır. Tasarımın temelinde iyi bir
dokümantasyon hazırlanması vardır. Dokümantasyon hazırlanmanın da en önemli noktası
kullanılan notasyondur. Temelde üç değişik notasyon kullanılır:
• Grafik Notasyon
•
Program Tanımlama Dili (PDL)
•
Đnformal Metinler
Çoğu zaman, yazılım tasarımı dokümantasyonlarında bu üç notasyon şekli de kullanılır.
5.2.
Tasarım Stratejileri
Temelde iki adet tasarım stratejisi vardır.
1. Fonksiyonel Tasarım
2. Nesne Yönelimli Tasarım
Sistem Analizi ve Yazılım Tasarımı
40
Öğr. Gör. Mustafa AKSU
5.2.1.
Fonksiyonel Tasarım:
•
Fonksiyonel bakış açısı temelli tasarım
•
Sistemin merkezileştirilmesi
•
Belli bir durum için uygulanan fonksiyon bilgisinin, sistem içindeki diğer durumlar
içinde paylaşılabilir olması
5.2.2.
Nesne Yönelimli Tasarım
•
Sistem, nesneler temel alınarak tasarlanır.
•
Sistem, merkezileşmeden uzak, nesnelerin yönetimi kendilerine özgüdür.
•
Nesneler tanımlanan kendi durum ve işlevlerine özgü niteliklere sahiptirler.
•
Nesneler aynı durum ve işlevlere sahip diğer nesnelerle aynı sınıftadırlar. Buna
nesne “class”ı denir.
•
Nesneler karşılıklı mesajlar ile haberleşirler. (Pratikte bir nesne bir başka nesneyi
içeren bir procedure çağırır.)
U
S
5.3.
Tasarım Kalitesi
K
A
Anlaşılabilirlilik: Tasarımın anlaşılabilirliliğini, yazılım kalitesi için en önemli kriter olarak
alabiliriz. Anlaşılabilirliği etkileyen faktörler şunlardır.
• Birleştirme ve kavrama: Sistemin her hangi bir bileşeninin kendi başına bir anlam
ifade etmesi.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
•
Đsimlendirme: Tasarım esnasında kullanılan isimlendirme metodumuz, verilen
isimlerin manalı isimler olması.
•
Dokümantasyon: Tasarımı detaylı bir şekilde anlatan doküman.
•
Karmaşıklık: Algoritma yapısının detaylı anlatılması.
Adapte edilebilirliliği: Yazılımın adapte edilebilirliliğini gösteren en iyi ayraç, yazılımda
rahatlıkla iz sürülebilmeli. (traceability)
.
r
g
Ö
6.1.
6. Mimari Tasarım
Tanım
Sistemin alt sistemlerinin tanımlanması, kontrollerinin oluşturulması ve iletişimlerinin
sağlanması, mimari tasarım diye adlandırılır.
Mimari tasarımda muhtemel olması gereken aktiviteler şunlardır.
1. Sistem Şekillendirilmesi: Sistemin alt sistemlerinin oluşturulması.
2. Kontrol Modelleri: Sistem içindeki ilişkilerin kontrolünün modellenmesi.
3. Modüler Yapının Oluşturulması: Alt sistemlerinde modüllere bölünmesi.
Soru 1: Alt sistem ile modül arasındaki fark nedir?
6.2.
Sistem Şekillendirme
Bu bölümde standart üç modelden bahsedeceğiz; ambar modeli (repository model), istemci
- sunucu modeli (client-server model) ve soyut makine modeli (abstract machine model).
6.2.1.
Ambar Modeli
a) Bu modelde, sistem ortak kullanılan bir veri tabanı üzerine kurulur.
b) Paylaştırılan veri bir yerde tutulur.
Sistem Analizi ve Yazılım Tasarımı
41
Öğr. Gör. Mustafa AKSU
c) Uygulamada üretilen veri ilgili bir alt-sistem tarafından üretilir, ortak veri
tabanına aktarılır ve diğer bütün alt-sistemlerde buradan veriyi kullanırlar.
6.2.2.
Đstemci – Sunucu Modeli
a) Sistem dağınık bir yapıdadır.
b) Belli bir sayıdaki sunucu diğer alt sistemler için hizmet üretir.
c) Đstemci sayısı bellidir.
d) Ağa girişler istemciler tarafından yönlendirilirler.
6.2.3.
Soyut Makine Modeli
a) Alt-sistemlerin aralarındaki arayüzler ile ilgili bir modellemedir.
b) Katmanlar arasındaki organizasyonu sağlar.
U
S
c) Her bir katman bir servis sunar.
d) Her katman soyut makinenin bir seviyesini oluşturur.
K
A
Açık sistem bağlantılarını (Open System Interconnection - OSI) örnek olarak ele alalım.
• Standart ağ iletişimini tanımlayalım.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
•
En alt katmanlar fiziksel olarak birbirlerine bağlıdır.
•
Orta katmanlar veri transferi ile ilgilidir.
•
Üst katmanlar mantıksal bir anlamı olan uygulamaların olduğu yerler.
6.3.
Kontrol Modelleri
Bir sistemin çalışabilmesi için, sistemin alt-sistemlerinin doğru çalışıp çalışmadığı kontrol
edilmelidir. Başka bir değişle, sunduğu hizmet doğru zamanda, doğru yerde olmalıdır.
Bunun sağlanabilmesi için iki temel yaklaşım vardır.
• Merkezileştirilmiş Kontrol: Bir alt sistem bütün kontrolden sorumlu olur. Diğer
sistemleri başlatır ve durdurur.
•
Olay-Tabanlı Kontrol (Event-Base Control): Her alt-sistem, kendi dışında üretilen
ve kendisi ile ilişkisi olan her olayın kontrolünden sorumludur.
.
r
g
Ö
6.4.
Modüler Ayrışma
Modül bir alt-sistemden daha küçük parçadır. Dolayısıyla alt-sistemler modüllere ayrılırlar.
Bir alt-sistem, veri akış modeli (data-flow model), başka bir değişle fonksiyon temelli model
veya nesne yönelimli modele (object oriented model) göre modüllere ayrılırlar.
6.4.1.
Nesne Yönelimli Tasarım
Nesne Yönelimli Tasarım (N.Y.T.), bir yazılımda kullanılan nesnelerin birbirleri ile iletişimini
içerir. Nesneler;
1. Sahip oldukları durumlarını korurlar. Genel yapı ile paylaşmazlar.
2. Her bir nesne tipi bir hizmet sağlar.
3. Bağımsıdırlar. Kolayca değişebilirler.
değişmek zorunda değildirler.
Diğer
nesnelerde
olan
değişimlerde,
4. Paylaşılan veri alanı yoktur. Nesnelerin iletişimi ile sağlanan veri hizmetlere
aktarılır. Bundan dolayı paylaşılan verinin kontrol problemi yoktur.
Sistem Analizi ve Yazılım Tasarımı
42
Öğr. Gör. Mustafa AKSU
6.4.1.1.
Nesneler, Nesne Sınıfları ve Mirasları
•
Nesne belli bir duruma sahip ve o duruma uygun bir çok operasyonunu çalıştıran
bağımsız bir varlıktır. Durum nesnenin niteliklerini gösterir.
•
Đşlem yapılması gerektiği zaman, ilgili nesne diğer bir nesneden alacağı bir uyarı
ile sağlayacağı hizmeti sunar.
•
Nesneler bir nesne sınıf tanımı üzerinden oluşturulur.
•
Nesne sınıfı, bir grup nesnenin, ortak nitelikleri ve hizmetleri veya işlemleri ki,
her bir nesne tarafından sağlanan, üzerinden tanımlanır.
•
Nesneler oluşturulduğu zaman, kendi sınıfının özelliklerini ve işlemlerini kalıtsal
olarak alırlar.
•
Nesne sınıfları da nesnedirler.
niteliklerini kalıtsal olarak alırlar.
•
Önemli bir soru, N.Y.T. nesneyi nasıl tanımlar? Đki temel yaklaşım vardır.
Bundan
dolayı,
onlarda
ebeveyn
sınıfının
U
S
o
Doğal dil yapısına benzetme: Nesne ve nitelikleri isim; Đşlemler ve
hizmetler ise fiildir.
o
Davranışsal yaklaşım: Tasarımcı sistemin bir çok farklı bileşenini alır,
onlar arasında etkileşim sağlar ve ayrıca başlangıç şartlarını ve ele
aldığı
bileşenlerin
davranışlarını
iyi
düşünüp,
değerlendirir.
Tasarımcılar, bileşenleri, aldıkları anlamlı roller ile nesne olarak
onaylar.
6.4.2.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Fonksiyon Yönelimli Tasarım
Bu tasarım metodolojisi, sistemi bir grup fonksiyona göre ayrıştırır. N.Y.T.in tersine
fonksiyonlar, belli ortak durumlara sahip olduklarında birbirlerinden bağımsız değildirler.
• Var olan durumdaki bir değişme diğer fonksiyonların davranışlarını da
etkileyebilir.
•
Ortak veri alanları vardır. Bakımları yapılmak zorundadır.
•
Oldukça eski bir metodolojidir fakat mükemmel değildir.
•
Fonksiyon yönelimli tasarımdaki aktiviteler;
g
Ö
r.
o
Veri-Akış tasarımı: Veri fonksiyondan nasıl geçer,
o
Yapısal ayrıştırma: Fonksiyonun modüllere göre ayrışması,
o
Detay tasarım tarifleri: Varlık tanımı (veri yapısı gibi), fonksiyonlar
arası arayüz, vs.
Sistem Analizi ve Yazılım Tasarımı
43
Öğr. Gör. Mustafa AKSU
U
S
.
r
g
Ö
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Sistem Analizi ve Yazılım Tasarımı
44
K
A
Öğr. Gör. Mustafa AKSU
1. GEREKSĐNĐMLERĐN YÖNETĐMĐ
Gereksinimlerin yönetiminin amacı, projenin müşterinin belirttiği ihtiyaçları
tamamıyla karşılayacak bir biçimde oluşturulmasıdır. Bu noktada önemli olan, amacı
gerçekleştirirken zaman ve maliyet açısından da en az çabanın sarf edilmesidir.
Şunu unutmamak gerekir ki insanlar
değiştirilebilirler ve gereksinimleri de değişebilir.
doğalarının
bir
gereği
olarak
fikir
Açıklamaları dikkate alarak daha detaylı olarak bakacak olursak, gereksinimler
yönetimi, tartışmalarla, raporlarla, iyi bir müşteri yönetimiyle birleşen ve neyin yazıya
dökülüp neyin dökülmediğini, gereksinimlerin analizi, değişiklikleri, geçerlilikleri gibi
konuları kapsayan bir süreçtir. Bu süreçte en önemli nokta yazılım geliştirici, kullanıcı,
müşteri tarafların üzerinde anlaşabildiği, doğru bir yazılım gereksinimleri dökümanı
hazırlamaktır. Bu gereksinimler dökümanı, yazılım geliştirme çabasının kapsamını ve yazılım
tasarımının, gerçekleştiriminin, testinin temelini oluşturur.
U
S
GEREKSĐNĐMLER
Yazılım
Gereksinimleri
Belirtimleri
Yazılım
Test
Planları
Kullanıcı
Belgeleri
Yazılım
Tasarım
Belirtimleri
.
r
g
Ö
Yazılım
Test
Yordamları
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Donanım
Gereksinimleri
Belirtimleri
Donanım
Test
Planları
Donanım
Test
Yordamları
Kod
Donanım
Tasarım
Belirtimleri
Donanım
Şekil-1.1 Gereksinimlerin Dokümanı Hiyerarşisi
Gereksinimlerin yönetiminin amacı, müşteri ve yazılım projesi tarafından belirlenen
müşteri gereksinimleri üzerinde ortak bir anlayış/bakış açısı sağlamaktır.
Müşteri ve geliştiriciler arasında oluşturulan anlaşmaya “yazılıma atanmış sistem
gereksinimleri” denir. Anlaşma teknik ve teknik olmayan konuları kapsar. Anlaşma, yazılım
projesinin tahminleme, planlama, gerçekleştirme gibi yazılım yaşam döngüsünün
aşamalarına temel oluşturur.
Sistem gereksinimlerinin yazılıma, donanıma, diğer sistemlere dağıtılması, dış
uzmanlar tarafından(sistem mühendisleri grubu) yapılabilir ve yazılım mühendisliği
Sistem Analizi ve Yazılım Tasarımı
45
Öğr. Gör. Mustafa AKSU
grubunun bu dağıtımda hiçbir şekilde söz hakkı olmayabilir. Proje sınırları içinde, yazılım
mühendisliği grubu, yazılıma atanan sistem gereksinimlerinin düzenli olarak kontrolünden
ve raporlanmasından sorumludur. Bu süreç de gereksinimlerin yönetimi ile başarıya ulaşır.
Sorumlu olunan kontrol ve raporlamanın başarıya ulaşabilmesi için, grup
başlangıçtaki ve değişikliğe uğrayan gereksinimleri inceler. Gereksinimlerin değişmesiyle
birlikte, etkilenecek olan yazılım planları, ürünleri, aktiviteleri değişen gereksinimleri
karşılayacak bir şekilde değiştirilir.
Son Kullanıcı Girdileri
Yeni Özellikler
Gereksinimler
Pazarlama
U
S
Tasarım
Yeni Gereksinimler
Kodlama
Karar
Aşaması
Yanlışlar
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Test
Test Girdileri
Bakım
Teknik Servis
Değişim Đhtiyacı
.
r
g
Ö
Şekil-1.2 Değişimlerin Yönetimi ve Gereksinimlerin Yönetimi
Buradan, gereksinimlerin yönetimindeki ilk adımın gereksinimlerin tanımlanması
–son kullanıcıdan gereksinimleri almak- olduğunu çıkarabiliriz. Eğer gereksinimler daha
önceden iş teklifi, iş anlaşması şeklinde ortaya konulduysa, yapılması gereken
gereksinimleri çıkarmak değil, sadece gereksinimlerin proje başlamadan önce detaylarını
belirlemek ve resmi bir formata sokmak olacaktır. Eğer gereksinimler belirsiz ise,
“gereksinimlerin tanımı” aşaması çok fazla analiz ve çalışma gerektirecektir.
Ayrıca, müşterinin ne istediği hakkında olabildiğince fazla bilgi elde etmek
gerekecektir. Đlk önce sistemin ne yapacağını belirleyecek olan kullanıcılar ve müşteriler
belirlenerek, bu kişilerle konuşarak onların tam olarak ne istediklerinin anlaşılmasına
çalışılmalıdır. Bunu yaparken, konuşma esnasında akla gelmeyen, gizli kalmış gereksinimler
ortaya çıkacaktır. Bu gizli gereksinimler, büyük ihtimalle konuştuğunuz kişinin alanında çok
açık şekilde bilinen ve gereksinim olarak söylenmeye ihtiyaç duyulmamış konular olacaktır.
Gereksinimlerin toplanmasında başka yollar da mevcuttur. Eğer yeni sistem var olan
bir sistemin yerine geçecekse, eski sistem ve dökümantasyonu incelenebilir. JAD (Joint
Application Design) Birleşik Uygulama Tasarımı toplantıları düzenlenebilir. Bu toplantılar
geliştiriciler ile müşterilerin tutarlı yapısal bir toplantı süreci içinde birlikte sistem tasarımı
yapmalarına dayanmaktadır. Prototipler, müşterinin erken bir zamanda ne elde edeceğini
görmesini sağlayacaktır.
Sistem Analizi ve Yazılım Tasarımı
46
Öğr. Gör. Mustafa AKSU
Gereksinimlerin toplanmasındaki önemli noktalar;
Gereksinimlerin detaylı bir şekilde analiz edilmesi
Gereksinimlerin birbiriyle uyumlu olması
Gereksinimlerin tutarlı, gerçekçi olması
Đzlenebilirlik matrisi, tüm gereksinimlerin sistem bileşenlerine atandığını
doğrulamaya yarar. Matris aynı zamanda gereksinimlerin kaynaklarını da gösterir.
Đzlenebilirlik matrisi, bir değişiklik olduğunda tüm gereksinimlerin karşılanacağını garanti
eder. Etkilenen bileşenlerin kolayca belirlenebilmesi, değişen gereksinimlerin sistem
üzerindeki etkisinin belirlenmesi, maliyetin tahmini, zaman çizelgelerinin hazırlanması gibi
konularda kolaylık sağlar.
Bu aşamalardan sonra elde edilecek olan gereksinim tanımlanma raporu, sistem
tarafından sağlanacak fonksiyonlar, performans gereksinimleri, tasarım ve gerçekleştirim
kısıtlamaları gibi teknik konuları; hangi ürünlerin teslim edileceği, ürünlerin teslim tarihleri,
ara raporlar gibi teknik olmayan konuları içermelidir.
U
S
Gereksinimlerinin yönetiminin önemli amaçlarından biri olan gereksinimlerin tanımı raporu
şu özelliklerde olmalıdır:
• Doğru
• Tamamlanmış, eksiksiz
• Tutarlı
• Kısa
• Đyi düzenlenmiş
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Bu aşamadan sonra, gereksinimlerin yönetiminin bir parçası olan gereksinimleri izleme
sürecinde, değişikliğe uğrayan gereksinimler geliştirici grup ve müşteri tarafından karşılıklı
onaylanmalıdır.
PROBLEM ALANI
Đhtiyaçlar
.
r
g
Ö
Özellikler
Đzlenebilirlik
Yazılım
ÇÖZÜM ALANI
Test Yordamları
Tasarım
Kullanıcı Belgeleri
Şekil-1.3 Gereksinimlerin Yönetimi Yapısı
Sistem Analizi ve Yazılım Tasarımı
47
Öğr. Gör. Mustafa AKSU
Gereksinimlerin yönetimindeki en önemli noktalar:
Gereksinimlerin planlanması aşaması
Gereksinim sürecini kurma aşaması
Gereksinimlerin değişimini kontrol etmek
Yeni gereksinimlerin eklenmesini en azda tutmak
Takip süreci
Müşteri ve geliştirici arasındaki sorunları çözmek
Belirli aralıklarla gereksinimleri gözden geçirmek
1.1. NEDEN GEREKSĐNĐMLERĐN YÖNETĐMĐ?
Bu soruyu verilecek en güzel yanıt şudur: “Tahminlerinizden çok, müşterinin istekleri
doğrultusunda bir yazılım üretebilmek için”.
Belirsizlik, tüm proje risklerinin kökünü oluşturur. Belirsizliğin büyük bir bölümünü
de yetersiz gereksinimler analizi oluşturur. Gereksiz veya tekrarlanmış gereksinimler,
projenin kapsamının, maliyetinin ne olacağının belirlenmesini engeller. Dahası, projeyi
durdurma noktasına getirir.
U
S
K
A
Gereksinimlerdeki eksikleri gidermek, tasarım sırasında 10 kat, gerçekleştirim
sırasında ise 100 kat daha fazla maliyettedir.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Đyi Gereksinim Yönetimi Nedir?
• Gereksinimlerin takibi, analizi için kullanıcı merkezli, organize bir yaklaşımdır.
• Gereksinimlerin nasıl ele alınacağını ve gereksinimlerin yönetimi planını kapsar
- Kimler nasıl iş ile ilgili olacak?
- Gereksinimler ile ilgili hangi bilginin bakımı yapılacak?
- Yeni gereksinimlerle karşılaşılınca hangi süreç izlenecek?
• Ek gereksinimlerin belirlenmesinde proje özellikleri de göz önüne alınmalıdır
Başarılı bir proje dikkatlice oluşturulmuş ve belgelendirilmiş gereksinimlerle başlar. Đyi
oluşturulmuş bir gereksinimlerin yönetimi süreci proje takımına tüm projeler boyunca
yardımcı olur.
.
r
g
Ö
2. YAZILIM KALĐTE GÜVENCESĐ
Giriş
Her yazılım geliştirme veya yazılım bakım projesi kalite güvence aktivitesi içerir.
Programcı farkında olmasa da, tek kişilik yazılım geliştirme projeleri bile kalite güvence
aktiviteleri içerir. Her programcının, kodun nasıl yazılması gerektiği hakkında bir düşüncesi
vardır ve bu düşünce tarzı o programcı için bir kodlama standardı olarak iş görür.
Benzer olarak, herkesin bir belgenin nasıl yazılması gerektiği hakkında fikirleri
vardır. Bu, kişisel bir standarttır. Đnsanlar, sahip oldukları bu standartlara göre belgeleri
gözden geçirirler. Aynı şekilde, programcılar da programlarının kendi standartlarına uygun
olup olmadığını anlamak için gözden geçirirler. Bu çalışmalara KG (Kalite Güvence)
incelemeleri denir.
Bir projenin resmi KG programı, her takım üyesinin yaptığı KG aktivitelerini içerir.
Fakat bu aktiviteleri kişi bazında değil de, proje azında KG planları olarak ele alır.
KG planlarının uzunluğu, detaylılığı projeye ve projenin risklerine göre değişir.
Sistem Analizi ve Yazılım Tasarımı
48
Öğr. Gör. Mustafa AKSU
Taşınabilirlik (Başka bir
bilgisayarda kullanabilir
miyim?)
Yeniden kullanılabilirlik (Aynı
yazılımı tekrar kullanabilir
Bakım (Sorun çıktığında
düzeltebilir miyim?)
Esneklik (Değiştirebilir
miyim?)
Test edilebilirlik (Test edebilir
YAZILIM KALĐTE
GÜVENCE YAPISI
Doğruluk (Đstediğim işi mi
yapıyor?)
Güvenilirlik (Her zmaan doğru
mu çalışıyor?)
Verimlilik (Donanımımda en
iyi şekilde mi çalışıyor?)
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
U
S
K
A
Kullanılabilirlik (Yazılım, kullanıcı için
2.2. KG Kavramları ve Tanımları
Kalite Güvence, yazılım yordamlarının ve ürünlerinin “gereksinimlere, standartlara”
uygunluğunu belirleyen planlı ve sistematik çalışmalardır.
.
r
g
Ö
Yazılım Kalite Güvencesi, yazılım geliştirme süresince her adımda uygulanan
bir şemsiye etkinliktir.
Gereksinimlerin düzgün olarak saptandığını ve ürünlerin, servislerin belirli
standartlarda olduğunu kanıtlayan planlı ve sistematik bir dizi aktivitelerdir.
Süreç, Tasarım, geliştirme, genişletme, yazılım bakımı aktivitelerini kapsar.
Ürün, yazılımı, ilgiyi veriyi, belgeleri ve tüm raporları kapsar.
KG, yazılım geliştirme süreci yaşam döngüsü boyunca standartların ve yordamların
uygulandığını ölçen süreci de kapsar.
Standartlar, yazılım ürünlerinin karşılaştırıldığı kriterlerdir.
Yordamlar, geliştirme ve kontrol süreçlerinin karşılaştırıldığı kriterlerdir.
Gereksinimlere, standartlara, yordamlara uygunluk, izleme, test yapma, inceleme,
değerlendirme ile ölçümlenir.
Yazılım geliştirme yaşam döngüsündeki üç destekleyici aktivite yönetim,
mühendislik, kalite güvencesidir.
Yazılım Yönetimi, planlama, kontrol yazılım projesini yönlendirme aktivitelerini kapsar.
Sistem Analizi ve Yazılım Tasarımı
49
Öğr. Gör. Mustafa AKSU
Yazılım Mühendisliği, gereksinimlerin analizi, tasarım geliştirme, kodlama, veritabanlarını
yaratma aktivitelerini kapsar.
KG, yönetim ve mühendislik aktivitelerinin tüm gereksinimleri karşıladığını garanti eder.
2. 3 Kalite Güvence Hedefleri
Yazılım geliştirme, diğer tüm karmaşık geliştirme aktiviteleri gibi risklerle doludur.
Bu riskler, teknik veya program ile ilgili olabilir. Bu da, yazılımın beklenildiği gibi olmasını
engelleyebilir.
KG’nin hedefi, bu riskleri azaltmaktır. Örneğin, kodlama standartları yazılan kod
kalitesini belirli bir seviyede tutmak için gereklidir. Eğer herhangi bir standart yoksa, oluşan
kodun, yeniden kullanılabilirlik ile ilgili gereksinimlere uygun olmaması riski vardır ve bu da
kodun üstünde tekrar çalışma yapmayı gerektirir.
KG süreci, riskleri azaltmak ve ürünün kalitesinin garantilenmesi için yapılması zorunlu bir
süreçtir. Hiç bir KG sürecinin olmaması, kabul edilemez bir kodun oluşma riskini arttırır.
U
S
2. 4 Kalite Güvence Takımı
K
A
KG’nin, ayrı, bağımsız bir takım tarafından ele alınması gerekir. KG fonksiyonları en
iyi, mühendislik ve yönetimden ayrı bir KG test ortamında yapılabilir. Yönetimsel olarak, KG
üst müdürlere ve proje yöneticisine raporlar verir.
Ayrı bir takım gerekmesinin nedeni, geliştirme sürecinde standartlara uyulduğunu
garantileyen, yönetimin sağ kolu olmasındandır. Eğer KG ayrı olmazsa, gerçekçi bir sonuç
elde edilemez. Ayrıca, testlerin tasarım veya kodlama detayları tarafından etkilenmediğini,
gereksinimlere göre yapıldığını garanti eder.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Sadece KG aktiviteleri ile ilgilenen takım geliştirme takımına göre daha küçüktür
ama sadece KG sorumluluğuna sahip bir takımın bulundurulmasının çok faydası vardır.
Yazılım
Proje
Yöneticisi
.
r
g
Ö
Proje
Yöneticisi
Proje
Yöneticisi
Kalite
Yöneticisi
Proje
Takımı
Proje
Takımı
Kalite
Güvence
Takımı
Şekil 2.2 - Yazılım Kalite Güvence Takımının Yeri
Sistem Analizi ve Yazılım Tasarımı
50
Öğr. Gör. Mustafa AKSU
2.5. KALĐTE GÜVENCE AKTĐVĐTELERĐ
2.5.1 Planlama
a) Kalite Güvencesini Projeye Uygun Hale Getirmek
b) Kalite Güvence Planını Yaratmak
c) Test-Durumu Yaratma
d) Standardları ve Yordamları Saptama
i) Belgeleme standardları
ii) Tasarım standardları,
iii) Belgelenmiş yordamlar
e) Tamamlanma Ölçütlerini Saptama
f) Standardlar ve Yordamları Denetlemek
g) Ürünleri ve Yordamları Đzleme, Kontrol Etme
U
S
h) Doğrulama ve Geçerlilik Đzleme
2.5.2 KG Testleri
Yazılım testleri ürünün
olduğunu/olmadığını belirler.
K
A
tamamlandığını/tamamlanmadığını
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
ve
dağıtıma
hazır
2.5.2.1 KG Testlerinin Hedefleri
Müşteriye verilecek olan ürünün kalitesini belirlemek
Tam olarak bir test yaşam döngüsünü tasarlamak, birleştirmek, çalıştırmak
Son ürünün tüm fonksiyonel yeteneklerini kontrol etmek
Son ürünün kararlılığını ve performansını test etmek
Ürünlerin müşteri beklentilerine ve gereksinimlerine uygun olup olmadığını test etmek
Kodu hatalara karşı test etmek, doğrulamak
2.5.2.3 Đyi Bir KG Testi Nasıl Yapılır?
.
r
g
Ö
Şunu unutmamak gerekir ki tüm testler, son ürünün müşteri beklentileri ve
gereksinimleri ile karşılaştırılarak yapılacaktır. Bu yüzden gereksinimler, gerektiğinde
değiştirilmelidir ve yazılımın tüm fonksiyonlarını göstermelidir. Beklenti dışı her fonksiyon
hata olarak var sayılacaktır.
2.5.3 Kalite Güvence Testleri
2.5.3.1 Birim Testi
Birim test durumları programın doğruluğunu ölçmek için kullanılır. “Beyaz kutu testi”
programın modüllerini ve süreçleri test eder. Bu testte programın fonksiyonelliği değil de
kod yapısı incelenir. Bunu başarabilmek için, bir durum tekniği kullanılır:
1. Programdaki her ifade test süresince en az bir kez doğru veya yanlış değer almalıdır.
2. Test süresince her durum olası sonuçların hepsini göstermelidir
2.5.3.2 Yapılandırma Yönetimi
Yapılandırma yönetimi takımı test ortamını hazırlar.
Sistem Analizi ve Yazılım Tasarımı
51
Öğr. Gör. Mustafa AKSU
2.5.3.3 Versiyon Doğrulama
Bir versiyon tamamlanma ölçütünü sağladığında ve test edilmeye hazır olduğunda,
KG takımı bu versiyonu test eder.
Eğer versiyon test edilemezse, KG takımı bu versiyonu reddeder
Eğer bazı parçaları test edilebilirken bazı parçaları henüz hazır değilse, KG takımı, proje
yöneticisi ile birlikte yeni bir zaman çizelgesi hazırlar.
2.5.3.4 Tamamlanma Testi
Tamamlanma testi, sistemin tüm parçalarının birbiriyle düzgün haberleştiğini ve veri
akışının doğru yapıldığını test eder. Son tamamlanma testi, sistem bir bütün olarak
çalışabildiğini gösterir.
2.5.3.5 Fonksiyonel Test
U
S
Fonksiyonel test, sistemin her elemanının gereksinimleri karşılamakta olduğunu,
sistem tasarım belirtimlerine, diğer fonksiyonel özelliklere uyumlu olduğunu gösterir.
2.5.3.6 Fonksiyonel Olmayan Test
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Fonksiyonel olmayan test, tüm belgelenmiş standartlara ve gereksinimlere
uygunluğu gösterir. Örneğin, cevap zamanı, diğer sistemlerle uyumluluk.
Eğer sistem donanımında sistemin belirli miktar eri trafiğine izin verdiği belirtilmişse, bu
durumlar da test edilmelidir.
2.5.3.7 Hata Düzeltme Doğrulama
Eğer geliştirme esnasında hatalar bulunup düzeltildiyse, KG bu bölümlerdeki
düzeltmelere ayrıca test uygular.
2.5.3.8 Anlık Test
Bu tip testler gerçek kullanıcı senaryolarını canlandırmada kullanılır. KG
mühendisleri, kullanıcın yapacağı davranışları yaparak sistemi test ederler. Örneğin sayfa
tam yüklenmeden “ileri” tuşuna basmak gibi.
.
r
g
Ö
2.5.3.9 Gerileme Testi
Gerileme testi, her yeni versiyon yayınlandıktan sonra, yeni versiyonun eski
versiyonlar üzerinde kötü etki bırakıp bırakmadığını ölçmeye yarar. Gerileme testi, projede
devamlı bir artmalı ilerleme olduğunu gösterir.
2.5.3.10 Hata Yönetimi
KG test aşamasında, tüm hatalar hata yönetimi iş akışı ile takıma sunulur. Takım
içinde düzenli toplantılar yapılır.
2.5.3.11 Kalite Güvence Raporu Hazırlama
Bu raporlar test sonuçlarını, bilinen hataları, önerilen çözümleri içerir.
Sistem Analizi ve Yazılım Tasarımı
52
Öğr. Gör. Mustafa AKSU
3. YAZILIM YAPILANIŞI YÖNETĐMĐ
GĐRĐŞ
Bir sistem, belirli fonksiyon ya da fonksiyonları yerine getiren bileşenler topluluğu
olarak tanımlanabilir. Bir sistemin yapılanışı yani konfigürasyonu ise sistemin donanım,
bellenim (firmware), yazılım karakteristiklerinin ve fonksiyonlarının tanımlanmasıdır. Ayrıca,
belirli bir amaca yönelik olarak yazılım, donanım ve bellenim öğelerinin belirli
versiyonlarının bir araya getirilmiş bir topluluğu olarak da düşünülebilinir.
Yukarıdaki açıklamaları dikkate alırsak, "Yapılanış Yönetimi (YY), sistem yaşam
döngüsü boyunca bir sistemin yapılanışını belirgin noktalar ile tanımlayan, değişiklikleri
sistematik olarak kontrol eden, yapılanışın bütünlüğünü ve izlenebilirliğini sağlayan bir
disiplindir." diyebiliriz.
U
S
Yapılanış Yönetimi (YY) resmi tanımı:
"Bir yapılanış öğesinin fonksiyonel ve fiziksel karakteristiklerini tanımlayan ve
belgeleyen,
bu karakteristiklerin değişimini kontrol eden, değişim sürecini ve gerçekleştirim durumunu
kaydeden ve denetleyen, belirlenmiş gereksinimlerle uyumluluğunu doğrulayan bir
disiplindir."
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Not: Donanım yapılanış yönetimi ile yazılım yapılanış yönetimi arasında farklar olsa da,
yapılanış yönetimi kavramları ikisine de aynı şekilde uygulanır.
3.1. YAZILIM YAPILANIŞI AKTĐVĐTELERĐ
Yazılım yapılanışını, en iyi olarak aktivitelerini inceleyerek anlayabiliriz. Bu bölümde
yazılım yapılanışın aktiviteleri detaylı olarak ele alınacaktır.
Yazılımsal Yapılanış Yönetimi (YYY) aktiviteleri genel olarak şu şekilde belirlenmiş ve
dünyada bir standard olarak kabul görmüştür:
* "Yazılım Yapılanışı Yönetimi" sürecinin yönetimi,
* Yazılım Yapılanışı tanımlaması,
* Yazılım Yapılanışı kontrolü,
* Yazılım Yapılanışı durumu kontrolü,
* Yazılım Yapılanışı denetlenmesi,
* Yazılım yayım yönetimi ve dağıtımı
.
r
g
Ö
Sistem Analizi ve Yazılım Tasarımı
53
Öğr. Gör. Mustafa AKSU
Kod Yönetimi
Bakım Takımı,
Müşteri Desteği
Fiziksel ve
Fonksiyonel
Tamamlanma
Değişikliklerin
Yetkilendirilmesi
Kontrol - Yönetim
Durum
Kontrolü
Yazılım Yapılanışı
Yönetim ve
Planlaması
Denetleme
Yayım
Đşleme
Kontrol – Geliştirme
Takımı
Yapılanış Tanımlama
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
U
S
K
A
Şekil 3.1 – Yazılım Yapılanış Aktiviteleri
Şimdi şekilde görmüş olduğumuz parçaları tek tek inceleyeceğiz:
3.1.1. "Yazılım Yapılanışı Yönetimi (YYY)" Sürecinin Yönetimi
YYY, yazılım yaşam döngüsünü destekleyen, geliştirme ve bakım aktivitelerine,
projenin tamamına, son kullanıcılara, müşterilere yarar sağlayan bir süreçtir.
Yönetimsel bir bakış açısıyla bakarsak, "YYY, bir ürünün gelişimini, ürünün öğelerini
tanımlayarak, değişimi yöneterek, kontrol ederek, yapılanış bilgisini raporlayarak kontrol
eder." diyebiliriz. Geliştirici bakış açısıyla bakacak olursak, "YYY, geliştirmeyi ve değişimleri
gerçekleştirmeyi kolaylaştıran bir süreçtir." diyebiliriz. Başarılı bir YYY, dikkatli bir planlama
ve yönetimi içerir. Bu da, YYY sürecinin kurumsal kavramını, sınırlarını, kavramını anlama
ile sağlanabilir.
.
r
g
Ö
3.1.1.1. Kurumsal Yapı ile Đlişki
Bir proje için bir Yazılım Yapılanışı Yönetimi planlayabilmek için kurumsal yapıyı
kurum içi bölümler arası ilişkileri bilmek gereklidir çünkü YYY, bazı kurumsal birimlerle ve
aktivitelerle iç içe olacaktır.
YYY, yazılım kalite güvencesi, yazılım doğrulama gibi süreçlerle birlikte yaşam
döngüsünü destekleyen bir süreç olarak görülmektedir. Kurumsal birimler bu süreçlerin
düzgün olarak yapılandırılmasından sorumludurlar. Bazı YYY aktivitelerini gerçekleştirmek
başka kurumlara bırakılsa da, genel sorumluluk direkt olarak kurumun kendisinde olmak
zorundadır.
Yazılım sık olarak donanım ve bellenim elemanlarını da içeren büyük sistemlerin bir
parçası olarak geliştirilir. Bu durumda, donanım ve bellenim ile paralel bir geliştirme
yapılması zorunlu duruma gelmektedir. Đşte bu yüzden, kurumun birimleri bilinmelidir.
Yazılım Yapılanışı Yönetimi, Yazılım Kalite Güvence süreci ile yakından ilgilidir. Hatta
bazı projelerde, Yazılım Kalite Güvencesi'nin önkoşulu Yazılım Yapılanışı Yönetimi
olmaktadır. Buna bağlı olarak, YYY içinde bulunan bazı öğeler, yazılım kalite güvencenin de
öğeleri olabilecek kadar birbirleriyle ilgili olabilirler.
Sistem Analizi ve Yazılım Tasarımı
54
Öğr. Gör. Mustafa AKSU
Tabi ki en yakın ilişki, yazılım geliştirme ile yazılım bakım arasında olmaktadır.
Yazılım ortamı aşağıdakileri içerir:
* Yazılım yaşam döngüsü modeli ve planları,
* Proje stratejileri
* Yazılım tekrar kullanılabilirlik süreçleri
* Geliştirme platformları
* Yazılım geliştirme araçları.
Bu ortam, gördüğünüz gibi, aynı zamanda birçok yazılım yapılanış kontrolleriyle de ilgilidir.
3.1.1.2. Yazılım Yapılanışı Yönetimi Rehberi ve Kısıtlamaları
YYY kısıtlamaları ve rehberlikleri birçok kaynaktan gelmektedir. Bir projenin yazılım
yapılanış yönetimini, yapılan birçok anlaşma ve önceden var olan anlaşmalar kısıtlanabilir.
Buna ek olarak, müşteri ile yapılan kontratta da süreci etkileyici maddeler bulunabilir.
Örneğin, kontratta bazı yapılanış denetlemelerinin istendiği belirtilmiş olabilir ya da bazı
belirlenmiş öğeler yazılım yapılanışı yönetimine özel olarak bırakılmış olabilir. Bunlardan
başka, seçilen yazılım geliştirme metodolojisi de etkileyici bir faktör olabilir.
U
S
K
A
YYY rehberi, Yazılım Mühendisliği Enstitüsü'nün yayımlamış olduğu CMM ya da ISO
SPICE gibi standartlardan, süreçlerden elde edilebilir.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
3.1.1.3. Planlama Aşaması
Yazılım Yapılanışı Yönetimi için yapılacak olan plan, kurumsal kavramlara,
kısıtlamalara ve rehberlere, projenin doğasına, yapısına uygun olarak hazırlanmalıdır.
Ele Alınan Planlama Adımları:
* Yazılım Yapılanış Tanımlamaları
* Yazılım Yapılanış Kontrolü
* Yazılım Yapılanış Durum Kontrolü
* Yazılım Yapılanış Denetlemesi
* Yazılım Yayım Denetimi ve Dağıtımı
Bunlara ek olarak, kurum, sorumluluklar, kaynaklar, zaman çizelgeleri, araç seçimi,
gerçekleştirim, ara yüz kontrolü gibi konular da planlama içinde değerlendirilir.
.
r
g
Ö
Planlama aktivitesinin sonucunda oluşan plan, Yazılım Yapılanış Yönetimi Planı olarak
adlandırılır. Bu plan, yazılım kalite güvencesi denetlemesi için bir kaynak olmaktadır.
3.1.1.3. Yazılım Yapılanış Yönetimi Organizasyonu ve Sorumlulukları
Yapılması gereken yazılım yapılanış yönetimi aktivitelerinin kimin yapacağını
karıştırmamak için, sorumluluklar, görevler tam olarak belirlenmek zorundadır. Belirli
yazılım yapılanışı yönetimi sorumlulukları ve görevleri, belirli kurumsal birimlere, kişilere
atanmalıdır. Yazılım yapılanışı yönetimi genel yetki mekanizması açıkça belirtilmelidir.
3.1.1.4. Yazılım Yapılanış Yönetimi Kaynakları ve Zaman Çizelgeleri
Yazılım yapılanış yönetimi planı, gerekli aktiviteleri yapabilmek için gerekli olan
arçları, grupları belirler. Görevlerin arasındaki ilişkileri ve sıralarını belirleyerek zaman
çizelgesi sorunlarını ortadan kaldırır. Gerekli olan herhangi bir eğitim de bu plan sayesinde
ortaya çıkar ve belirlenir.
3.1.1.5. Araç Seçimi ve Gerçekleştirim
Yazılım yapılanış yönetimi için, değişik özelliklerde araçlar mevcuttur. Đçinde
bulunulan duruma bağlı olarak bu araç özelliklerinin hangilerine ihtiyaç duyulduğu belirlenir
ve birden çok araç gerektiren durumlarda bu araçların kombinasyonu kullanılabilir.
Otomatik araçlar, büyüyen ve büyüdükçe karmaşıklaşan projelerde, büyük yarar
sağlarlar.
Sistem Analizi ve Yazılım Tasarımı
55
Öğr. Gör. Mustafa AKSU
Bu araçların destekledikleri konuları şöyle sıralayabiliriz:
* Yazılım Yapılanış Yönetimi Kütüphanesi
* Yazılım değişimi istekleri ve süreçleri
* Kod ve değişim yönetimi görevleri
* Yazılım yapılanış durumu raporlamaları
* Yazılım denetlemesi
* Yazılım build'leri oluşturmak
* Yazılım yayımlarını ve dağıtımlarını kontrol etmek.
Aşağıdaki şekilde, Yazılım Yapılanış Yönetimi Araçlarının yapabildikleri aktiviteleri ve
bunların Yazılım Yapılanış Yönetimi ile nasıl örtüştükleri gösterilmektedir.
Kod Yönetim Sistemi
Veritabanı Yönetimi Sistemleri, Kod
Yönetim Sistemi
U
S
Kütüphaneler,
Değişim Đstekleri
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Kontrol - Yönetim
Durum
Kontrolü
Yazılım Yapılanışı
Yönetim ve
Planlaması
K
A
Yayım
Đşleme
Denetleme
Kontrol – Geliştirme
Takımı
Yapılanış Tanımlama
.
r
g
Ö
Değişikliklerin Kabulü
Denetleme Yordamları
Şekil 3.2 – Yazılım Yapılanış Yordamları ve Araçları
Yukarıdaki şekilde, kod yönetim sistemleri yazılım kütüphanelerinin çalışmasını
kütüphane elemanlarına erişimi kontrol ederek, birden çok kullanıcının aktivitelerini kontrol
ederek desteklemektedir. Diğer araçlar yazılım ve yayım belgeleri oluşturmayı
desteklemektedir. Bunlar dışındaki araçlar ise veritabanı yönetimi desteği, yönetim için
raporlama mekanizmaları desteği sağlamaktadır. Araçların bazılarının yetenekleri yazılım
yapılanış yönetimi içine entegre edilebilir.
3.1.2. Yazılım Yapılanışı Yönetim Planı
Bir proje için belirlenen YYY planının sonuçları, Yazılım yapılanış Yönetimi Planında
tutulur. Bu belge, Yazılım Yapılanış Yönetimi süreci için bir kaynak olur. Süreç boyunca,
gerekli durumlarda güncellenir. Gerçekleştirim bölümünde ise, plandaki bazı parçaların daha
detaylı açıklanması gerekebilmektedir. Bu yüzden bu belgeye "yaşayan bir rapor" diyebiliriz.
Bir YYY Planında 6 kategoride bilgi bulunmaktadır:
1) Giriş -amaç, kavram, kullanılan terimler
Sistem Analizi ve Yazılım Tasarımı
56
Öğr. Gör. Mustafa AKSU
2)
3)
4)
5)
6)
YYY Sürecinin Yönetimi -organizasyon, sorumluluklar, yordamlar
YYY Aktiviteleri -yapılanış tanımlaması, yapılanış kontrolü
YYY Zaman çizelgeleri -diğer proje aktiviteleri ile olan koordinasyonu
YYY Kaynakları -araçlar, insan kaynakları
Planın bakımı, güncelleştirilmesi
3.1.3. Yazılım Yapılanış Tanımlaması
Yazılım Yapılanış Tanımlaması aktivitesi kontrol edilecek elemanları belirler ve bu
elemanların versiyonlarını kontrol eder. Ayrıca, bu kontrol edilen elemanların yönetiminde
kullanılacak araçları belirler.
3.2.3.1. Kontrol Edilecek Elemanların Tanımlanması
Değişim kontrolündeki ilk aşama, kontrol edilmesi gereken elemanların belirlenmesi
işlemidir. Bu işlem, yazılım yapılanışının sistem yapılanışı ile birlikte ele alınıp anlaşılmasını,
yapılanış elemanlarının seçimini, yazılım öğelerinin isimlendirilmesinde bir strateji
belirlenmesini, aralarındaki ilişkilerin belirlenmesini gerektirir.
U
S
Yazılım Yapılanış Öğesi:
Yazılım yapılanış öğesi, yapılanış yönetimi için tasarlanmış olan yazılımın bir
genellemesidir ve tek bir eleman olarak algılanır. Kod da dahil olmak üzere, çeşitli öğeler
YYY tarafından kontrol edilir.
Yazılım yapılanış öğeleri listesi:
- Planlar
- Belirtimler
- Test materyalleri
- Yazılım araçları
- Kod ve çalıştırılabilir kod
- Veri kütüphaneleri
- Bakım, kurulum belgeleri
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Yazılım Versiyonları:
Yazılım projesi ilerledikçe, öğeler gelişir. Bir karışıklık söz konusu olmaması için, bu
gelişmelerin tutarlı, kontrollü bir şekilde ele alınması gereklidir. Bu da versiyonlar ile
sağlanır.
Bir yazılım öğesinin versiyonu, belirli özelliklere sahip olan bir öğedir. Uyarlama, geliştirilmiş
olan bir yazılım versiyonuna verilen addır.
.
r
g
Ö
3.1.3.2. Yazılım Yapılanış Öğelerinin Bulunması
Yazılım yapılanış öğeleri farklı faklı zamanlarda bulunup farklı zamanlarda yazılım
yapılanış yönetimi kontrolüne verilebilir.(yazılım yaşam döngüsünün belirli adımlarında
bulunabilir) Genelde, bitirilmiş bir resmi görev, gözden geçirme yeni öğeler bulmayı
sağlamaktadır.
Aşağıdaki şekilde "Şelale Modeli" ile öğelerin bulunması örneklendirilmektedir.
Sistem Analizi ve Yazılım Tasarımı
57
Öğr. Gör. Mustafa AKSU
Gereksinimlerin Gözden
Yazılım Gereksinimleri Belirtimleri -
Tasarımın Gözden
Değişim
Đhtiyacı
Yazılım Gereksinimleri Belirtimleri –
B
Yazılım Tasarım Belirtimleri - A
Değişim
Đhtiyacı
Testlerin Gözden
Yazılım Gereksinimleri Belirtimleri –
C
Yazılım Tasarım Belirtimleri – B
Kod – A
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
U
S
K
A
Kabul Edilirlik
Yazılım Gereksinimleri Belirtimleri –
D
Yazılım Tasarım Belirtimleri – C
Kod – B
Test – B
Kullanım Klavuzu - A
Şekil 3.3 – Öğelerin Elde Edilmesi
3.1.4. Yazılım Yapılanış Kontrolü
.
r
g
Ö
Yazılım yapılanış kontrolü, yazılım yaşam döngüsü boyunca oluşan değişiklikleri
yönetir. Hangi değişikliklerin uygulanacağı, belirli değişikliklerin onaylanması, bu
değişikliklerin hayata geçirilmesinin desteği gibi konuları kapsar.
Yazılım değişiklikleri istekleri süreci, birçok araç kullanımını da beraberinde
gerektirir. Ve bu araçlar (belgeleme araçları, koordinasyon araçları...) genelde
geliştirme takımı tarafından yaratılır çünkü her projede, bu isteklerin tipi projeye
bağımlıdır.
Kabul edilmiş, onaylanmış değişiklikler belirlenen yazılım yordamlarına uyularak
gerçekleştirilir. Aynı anda birden çok değişikliğin gerçekleştirimi yapılabileceği için bu gibi
durumlarda gerçekleştirimlerin birbirine uyumlu olması sağlanmalıdır.
Değişikliklerin
gerçekleştirimleri bitirildikten sonra, sonuçların standardlara uygunluğu da test edilmelidir.
Aşağıdaki şekilde değişim sürecini daha iyi görmekteyiz.
Sistem Analizi ve Yazılım Tasarımı
58
Öğr. Gör. Mustafa AKSU
Değişiklik
Đhtiyacı
Ön Đnceleme
Değişikliğin
Tanımlanması
Değişikliği
Gözden
Geçirme
Değişikliği
önerene haber
ver
RED
U
S
KABUL
Yazılım
Değişikliği
Đsteğinin
Yaratılması
Yazılım
Mühendisi
Ataması Yap
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Tamamlanmama
Değişikliği
Değerlendirm
e
.
r
g
Ö
Analiz,
Tasarım,
Kodlama,
Test
Tamamlanma
Şekil 3.4 – Değişiklik Kontrolü
3.1.5. Yazılım Yapılanış Durumu Kontrolü
Yazılım Yapılanışı Durum Kontrolü, verimli bir yapılanış yönetimi için gerekli olan
bilgiyi, raporlamayı sağlar. Durum Kontrolü tasarımı, mevcut bilgi sistemlerinin
tasarımlarından yola çıkarak yapılabilir.
Durum kontrolü aktivitesi, yaşam döngüsü boyunca, bilgiyi yakalamayı ve
raporlamayı amaçlar. Her bilgi sisteminde olduğu gibi burada da, yapılanış durumu
tanımlanmalı ve bakımı yapılmalıdır. Bu işlem içinde çeşitli ölçütler ve bilgiler
gerekmektedir. Bu bilgiler yönetim kademesi, yazılım mühendisleri ve diğer kurumlardan
elde edilecektir. Bilgi toplama esnasında, karışıklıkları kontrol etmek için bazı araçların
kullanılmasında fayda vardır.
Raporlanan bilgiler, geliştirme akımı, bakım takımı, proje yönetimi, kalite güvence
takımı gibi gruplar tarafından kullanılacaktır. Raporlama rasgele ortaya çıkan isteklere bağlı
olarak hazırlanabildiği gibi düzenli aralıklarla da hazırlanabilmektedir.
Sistem Analizi ve Yazılım Tasarımı
59
Öğr. Gör. Mustafa AKSU
Durum kontrolünden elde edilen bilgi, raporlamada kullanılabildiği gibi yönetim
kademesinde bazı ölçütler için de kullanılabilir. Örnek olarak değişiklik isteklerinin sayısı ve
bir değişikliğin gerçekleştirme zamanı verilebilir.
3.1.6. Yazılım Yapılanışı Denetleme
Yazılım denetlemesi, yazılım ürünün kabul edilirliğinin, standartların, rehberlerin,
yordamların değerlendirildiği bağımsız olarak gerçekleştirilen bir aktivitedir. Denetlemeler,
iyi tanımlanmış olan birçok süreci kapsar. Bu süreçlerde, farklı farklı sorumluluklar
mevcuttur. Her denetleme, çok iyi olarak planlanmalıdır.
Denetlemeler, hangi öğelerin istenilen düzeyde olduğu, hangilerinin eksik olduğu
hakkında bilgi verir.
Bu denetlemeler proje yaşam döngüsünün önemli noktalarında
yapılmalıdır. 2 çeşit denetleme vardır: Fiziksel Denetleme ve Fonksiyonel Denetleme. Bu
denetlemelerin sağlıklı olarak yazılması, ortaya çıkarılacak olan ürünün kalitesini de ortaya
koyar.
U
S
3.2.6.1. Fonksiyonel Denetleme
Fonksiyonel denetlemenin amacı, denetlenen yazılımın belirtimlerle olan
uyumluluğunu ölçmektir.
Yazılım Doğrulama ve Testlerinin çıktıları, bu denetleme için iyi birer girdidirler.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
3.2.6.2. Fiziksel Denetleme
K
A
Fiziksel denetlemenin amacı, tasarım dökümanının geliştirilmekte olan yazılım ürünü
ile tutarlı olup olmadığını ölçmektir.
3.1.7. Yazılım Yayım Yönetimi
Yayım kelimesi, geliştirme aktivitesi boyunca ortaya çıkarılan farklı özelliklerdeki
öğeler anlamına gelmektedir. (Mesela bir aracın yeni, farklı özellikteki versiyonları) Bu
öğeler, müşteriye gönderilen dışsal öğeler olabileceği gibi geliştirme takımı içinde kalan içsel
öğeler de olabilir. Bir yazılımın yeni bir versionu oluşturulduğunda, bu versiyonun yayım
olarak açılanmadan önce diğer yazılımların hangi versiyonları ile uyumlu çalışabileceği
belirlenmeli ve buna göre bir paket oluşturulmalıdır. Bu iş için de kütüphaneler
kullanılmalıdır.
.
r
g
Ö
Çalıştırılabilir bir yazılım için, öğelerin doğru versiyonları bir araya getirilir ve
kurulum paketi hazırlanır. Bu işlem yapılırken, en önemli nokta yazılımın çalışacağı
donanımın yapılanışının doğu tespit edilmesidir. Çünkü donanım yapılanışı yanlış tespit
edilmiş bir paket, çalışmayacağı için sonuç tam anlamıyla hüsran olacaktır.
Buna göre, yazılım yayım yönetimi, bir ürünün öğelerinin tanımlanması, bir araya
getirilmesi, dağıtımı gibi konuları ele alan önemli bir aktivitedir. (Çalıştırılabilir kod,
dökümantasyonu, yapılanış bilgisi...)
Yazlım yayım yönetiminin diğer bir görevi de ne zaman bir yayım yaratmak
gerektiğine karar vermektir. Çözülen problemlerin önemi ve hataları ne kadar yok ettiği bu
kararı belirleyen etkileyici bir faktördür.
4. Yazılım Ürün Mühendisliği (YÜM)
YÜM, etkin ve verimli bir şekilde, doğru, tutarlı bir yazılım ürünü elde etmek için tüm
yazılım mühendisliği aktiviteleri boyunca devam eden tutarlı bir mühendislik sürecidir.
YÜM, uygun araçları ve metotları kullanarak, projenin yazılım sürecinde yazılım
ürünü üretmek için yürütülen mühendislik görevlerini içerir.
Sistem Analizi ve Yazılım Tasarımı
60
Öğr. Gör. Mustafa AKSU
Ayrıca;
yazılım sistemine atanmış olan sistem gereksinimlerini incelemeyi,
yazılım gereksinimleri geliştirmeyi, yazılım mimarisi geliştirmeyi,
yazılım tasarlamayı,
yazılımın kodlamasını,
yazılım bileşenlerini birleştirmeyi ,
yazılım doğrulama ve sınama süreçlerini analiz etmeyi içerir.
Yazılım mühendisliği görevleri için belgeleme gerekir (örneğin yazılım gereksinimler belgesi,
yazılım tasarım belgesi, test planları, test yordamları). Bu belgeleme işlerinde de YÜM’nin
önemi vardır.
4.1. Yazılım Ürün Mühendisliği Hedefleri
Yazılım ürünleri ölçütlerini pratiğe dökmek.
Maliyet, zaman çizelgesi, fonksiyonellik, kalite arasındaki ilişkiyi kurmak ve bu 4’lü
anlayışı geliştirmek.
Proje/program yönetimi, sistem mühendisliği, süreç geliştirme ile ilgili bir ölçümleme
yaklaşımı getirmek ve devam eden yazılım ölçütlerini kontrol etmek.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
4.2. Yazılım Ürün Mühendisliği Tanımları
K
A
Yazılım Ürünü Mühendisliği: Bir yazılım projesinde, müşterinin ihtiyaçlarını
karşılayacak şekilde ürün ortaya koymak için yapılan yazılım mühendisliği
aktiviteleridir.
Müşteri: Müşteri, yazılım ürünüyle ilişkisi olan herhangi bir kişi olabilir.(bir şahıs ya
da şirket) Müşterileri şu şekilde sınıflara ayırabiliriz: Kullanıcılar, Geliştiriciler, Bakım
takımı.
Yazılım Fonksiyonelliği: Sistem gereksinimlerinde müşteri tarafından belirtilmiş
olan ihtiyaçların yazılım sistemi tarafından karşılanabilme yeteneğidir.
Yazılım Kalitesi: Kalite, yazılım ürününün gereksinimleri karşılayabilme derecesidir.
Ayrıca müşterinin isteklerine cevap verebilme oranı olarak da düşünebiliriz.
.
r
g
Ö
4.3. Yazılım Ürünü Mühendisliği Kapsamı
Yazılım ürünü mühendisliği çalışmaları sırasında, tüm çaba, merak ve odaklanma
yazılım ürünü fonksiyonelliği ve kalitesi üzerine olmalıdır.
Tanımlanmış olan ölçütler, tek bir proje için fonksiyonelliği ve kaliteyi hedef
almalıdır. Đç içe geçmiş çoklu projeler hedef alınmamalıdır.
Yazılım ürünü mühendisliği sorunları üç değişik müşteri perspektiften bakarak ele
almalıdır: Kullanıcı, geliştirici ve bakımcı.
Sadece yazılım mühendisliği alanına giren konularda yazılım ürünü mühendisliği
çalışması yapılmalıdır. Eğitim ile ilgili aktiviteler ve materyaller bu kapsama
girmemektedir.
Ürün fonksiyonelliği ve kalitesi ile ilgili ölçütleri belirlerken, süreçler ve ürün ile ilgili
raporlar dikkate alınmalıdır.
Çalışmalar, müşterinin fonksiyonelliği ve kaliteyi tahminleyebileceği konuları da içine
almalıdır.
Çalışmalar, ürünü iyileştirmede yardımı olabilecek etkileri de incelemelidir.
Yazılım ürünü mühendisliği aktiviteleri içsel ve dışsal özellikleri de içermelidir.
Çalışmalar, kullanıcı beklentileri göz önünde tutularak tamamlanmışlık derecesini de
ölçmelidir. Bu da müşteri ihtiyaçlarını anlama ve belgelemede doğruluk ile
sağlanabilir.
Sistem Analizi ve Yazılım Tasarımı
61
Öğr. Gör. Mustafa AKSU
4.4. Yazılım Ürün Mühendisliği Temelleri
Tüm ölçütler sorunlara yönelik olmalıdır.
Ölçütler tek başlarına karar vermeye yeterli olmamalıdır. Genelde, karar aşamasında
birden çok ölçüt bir arada değerlendirilerek yazılım ürününün kapsamlı bir
karakteristiği çıkarılmalıdır.
Ürün değerlendirmede, yazılım ürünü mühendisliği ölçütleri 2 amaca hizmet eder:
o Yazılım ürününün kalitesini ölçme ve en sonunda elde edilecek olan ürünün
kalitesini tahminlemek. Bu ölçme ve tahminleme işlemleri süreçlere ve ürün
bileşenlerine uygulanmalıdır.
Ölçütler pozitif ve negatif sonuçları ortaya çıkarmalıdır.
Ölçütler tüm müşterileri desteklemelidir.
Ölçütler, ürünün fonksiyonelliğini ve kalitesini incelemeye yönelik olmalıdır.
U
S
Önerileri gözden geçir, değerlendir,
Takımı kur
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Yazılım ürün mühendisliği etkisini
Var olan ölçümleme yöntemlerini incele ve gözden
Gelişmeyi ölçmek için anaçerçeveyi incele
Ölçütleri
Durum çalışmaları geliştir
Ürün geliştir
.
r
g
Ö
Şekil – 4.1 Yazılım Ürün Geliştirme
5. Süreç ve Yazılım Değişimi Yönetimi
“Bir yazılım projesinde, değişim kaçınılmazdır. Değişim yönetimi, bu değişiklikleri
yönetmenizi ve koordine etmenizi sağlar. Bu sayede değişiklikler sorun olmaktan çıkar,
yazılımı geliştirir.”
!! Değişim Yönetimi, süreç içindeki değişiklikler üzerinde bir kontroldür.
Özet olarak bir değişim yönetimi senaryosu verecek olursak:
1. Değişimin gereksinimlerini analiz et
2. Değişimi planla
3. Değişimi gerçekleştir
4. Değişimi raporla
5. Değişim olası sonuçlarını incele
Yazılım geliştirmedeki tek sabit “değişim”dir. Đlk kapsamdan, tamamlanma fazına ve bakıma
Sistem Analizi ve Yazılım Tasarımı
62
Öğr. Gör. Mustafa AKSU
kadar, yazılım devamlı değişir. Bu değişiklikler, yazılımın gereksinimleri karşılayıp
karşılamadığını, yazılımın zamanında ve uygun bütçeyle tamamlanıp tamamlanamadığını
belirler. Proje yöneticilerinin de asıl görevlerinden biri, değişim yönetimidir.
Süreç Değişim Yönetimi’nin Amaçları:
1. Değişim isteklerine proje bağlamında servis vermek.
2. Her değişikliği resmi olarak belgelemek.
3. Her değişikliğin potansiyel etkisini değerlendirmek.
4. Değişim için gerekli süreçleri ve yetkiyi sağlamak.
5. Tüm grupları değişikliklerden haberdar etmek.
Değişim yönetimi, 2’ye ayrılır: Değişim Planlaması ve Değişim Yönetimi.
5.1. Değişim Planlaması
U
S
Değişim planlaması, değişimin risk seviyesini belirleyen ve değişimin başarılı olabilmesi için
gerekenleri tanımlayan bir süreçtir.
Değişim Planlamasının ana adımları şunlardır:
1. Değişim planı gereksinimlerine göre en az 3 risk seviyesi belirle.
2. Tüm değişimlere bir risk seviyesi ata.
3. Yazılım/donanım güncellemeleri, yapılanış değişimleri için yeni tanımlamalar yap.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
5. 2. Değişim Yönetimi
BAŞLA
RISK
DEĞERLENDĐRM
E
KAPSAM
DEĞĐŞĐM
KONTROLCÜSÜ
.
r
g
Ö
DEĞĐŞĐM
DEĞERLENDĐRMESĐ
DEĞĐŞĐM
YÖNETĐM TAKIMI
BELGELEME
TEST
ĐLETĐŞĐM
DEĞĐŞĐM
PLANLAMASI
GERÇEKLEŞTĐRĐM
TAKIMI
SON
Şekil – 5.1 Değişim Yönetimi
Değişim yönetimi adımları:
Değişim yönetimi aktivitelerini yönetebilecek olan, değişim isteklerini kabul edecek ve
inceleyecek, süreç değişim gelişmelerini yönetecek bir değişim kontrolcüsü ataması yap.
Sistem yöneticisi, uygulama geliştiricileri, kullanıcılar ile periyodik olarak değişim gözden
geçirme toplantıları düzenle.
Gereksinimleri düzenle, belgele.
Değişim çıktılarını belgele, düzenle.
Yüksek risk seviyeli değişimler için bir değişim onaylama yordamı belirle.
5.3. Değişim Yönetimi ve Yapılanış Yönetimi Đlişkisi
Yapılanış yönetimi, değişim yönetiminin ana bileşenlerinden biridir. Yazılım yapılanışı
yönetimi, yazılımın belirgin sürümlerini, ileride kullanılmak üzere tespit eder. Eğer yapılanış
Sistem Analizi ve Yazılım Tasarımı
63
Öğr. Gör. Mustafa AKSU
yönetimi alt seviyedeyse, proje yöneticisi değişiklikleri sadece uzaktan izlemekle yetinir.
Ayrıca, gelişimin tahminlenmesi de zorlaşır.
Yazılım değişimi yönetimi, hangi değişikliklerin doğru olduğunu belirleyen bir süreçtir.
Hangi değişikliklerin yapılması gerektiğini, hangilerinin önlenmesi gerektiğini proje zaman
çizelgesi ve bütçesine göre belirler. Değişim Yönetimi süreci, değişikliklerin kaynağını
belirler, kritik proje karar noktalarını tanımlar, proje sorumluluklarını belirler. Aşağıdaki
şekilde, süreç bileşenleri ve aralarındaki ilişkiler gösterilmektedir. Şekilden de görüldüğü
gibi, değişim yönetimi ile yapılanış yönetimi birbiriyle direkt ilişkilidir.
Süreç Poliçesi Tanımı
U
S
Süreç Değişim Yönetimi
Yazılım Yapılanış Yönetimi
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Değişiklik Verileri Havuzu
Şekil – 5.2 Süreç Bileşenleri, Đlişkileri
Yazılım Yapılanış Yönetimi (YYY) ve değişiklik takibi arasındaki ilişki, değişim yönetiminin
merkezindedirler. YYY standardları, değişim kontrolünü, yapılanışın tanımından sonra gelen
bir görev olarak görür. Bu da, bazı geliştiricilerin, YYY’nin değişimleri yönetmektense
değişimleri engellediğini düşündürebilir. Oysa Değişim Yönetimi, doğru değişiklikleri en
verimli şekilde seçerek uygulamayı hedefler. Bu bağlamda YYY sürümleri, versiyonları ele
alırken değişimden Değişim Yönetimi sorumludur diyebiliriz.
.
r
g
Ö
Şekil – 5.2’de görülen değişiklik verileri havuzu, süreç değişim yönetimini destekler.
Geliştiriciler, testçiler, kullanıcılar değişiklikler hakkındaki verileri buraya girerler. Değişiklik
verileri havuzu kullanılarak, sürüm ve yayımların tutarlılığı sağlanır. Ve havuzdaki veriler,
gerçekleştirim safhasında da gözönünde tutulurlar.
Süreç Değişim Yönetimi, proje yönetiminin bütünleşik bir parçasıdır. Geliştiriciler için,
yazılımlarının başarıya ulaşmasındaki tek yol, yazılımı değiştirmekten geçer. Değişim
Yönetimi de bu değişiklikleri koordine eder ve yönetir.
Sistem Analizi ve Yazılım Tasarımı
64
Öğr. Gör. Mustafa AKSU
Anlatılanları daha iyi kavrayabilmek için aşağıdaki şekil yardımcı olacaktır.
1. Değişikliği
Belgele
MÜŞTERĐ
Standartlar &
Yaşam
Döngüleri
3. Planlam
a
Değişikliği
Kaydet
Kalite Planı
4. Ona
y
2. Riskleri
Belirle
Plan &
Gerçekleştirim
5. Gerçekleştiri
mi Denetle
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
6. Kaydet ve
Müşteriye
Durum Bildir
U
S
K
A
Raporlar
7. Değişikliği
Gözden
Geçir
r.
Değişiklik
Tarihçesi
g
Ö
8. Değişiklik
Tarihçesini
Analiz Et
Yönetim
Raporları
Şekil – 5.3 Süreç Değişim Yönetimi
Bileşenleri
Sistem Analizi ve Yazılım Tasarımı
65
Öğr. Gör. Mustafa AKSU
5.4 Değişiklikler Nerelerden Kaynaklanır?
Birçok konu yazılımda değişikliklere yol açar. Bu gelecek değişikliklerin kaynaklarını
bulmak, öncelik sırasında koymamızda bize yardımcı olur. Değişimin kaynağı, planlı gelişim,
beklenmedik sorunlar, iyileştirmeler olarak tanımlanabilir.
Beklenmedik Sorunlar
Planlı Değişim
Kullanıcı Đstekleri
Đyileştirme
Çalışmaları
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
U
S
K
A
Şekil – 3 Değişikliği Oluşturan Kaynaklar
5.4.1.Planlı, Düzenli Yazılım Geliştirme
Đdeal
olarak,
tüm
yazılım
değişiklikleri,
planlı
geliştirme
çabasından
kaynaklanmaktadır. (Gereksinimler ve belirtimler tarafından ileriye sürülen gerçeklerle
ilgili.) Yeni bir kod eklemek, yönetilmesi gereken bir değişiklik anlamına gelmektedir.
Kullanılmayan fonksiyonların eklenmesi, projenin kaynaklarını tüketecek, hata oluşma
riskini arttıracaktır. Bazen istenen özellikler gerçekleştirilmeden bile değişiklik yapılmadan
önce üzerinde düşünülmesi gerekebilir. Maliyet-Yarar bağlamında, istenen her değişiklik,
detaylıca incelenmeli ve planlı bir şekilde ele alınmalıdır.
.
r
g
Ö
5.4.2.Beklenmeyen Problemler
Geliştirme esnasında, doğal olarak sorunlar keşfedecek ve bunları çözebilmek için
kaynaklarınızın bir kısmını bu sorunlara harcayacaksınız. Problemin büyüklüğüne göre
harcanan zaman ve çaba artacaktır. (küçük hatalar projenizin bütçesini harcayamaz)
Geliştirme takımı, kodun tasarımının düzgün olduğunu, gereksinimlerin karşılandığını
belirler. Son olarak, tasarım ve gereksinim hatalarının düzeltildiğinden emin olunmalıdır.
Sonraki bölümlerde anlatılacak olan bütünleşik süreç değişim yönetimi araçları, bir
değişiklik yapıldığında gerekli belgelerin gözden geçirilip düzeltilmesi gerektiğini belirtir. Bu
belge yenilemesinde, yeni problemler ortaya çıkabilir.
5.4.3.Đyileştirme Çabaları
Tüm yazılım projeleri, bir araştırma ve geliştirme çabasının ürünleridir. Bu yüzden
projelerde, iyileştirme fikirleri ortaya çıkar. Bu noktada proje yöneticisi öne çıkar. Fikir
Sistem Analizi ve Yazılım Tasarımı
66
Öğr. Gör. Mustafa AKSU
projeyi kestirmeden hedefine uaştırabilecek parlak bir fikir olabilir ya da projenin başarısını
tehdit eden bir yanlış fikir olabilir.
5.4.4. Kullanıcı Đstekleri
Yazılım değişimi yönünde zaman zaman kullanıcı istekleri de olur. Bu istekler proje
devamında yada bitiminde olabilir. Yalnız şuna dikkat edilmelidir: kullanıcı istekleri bir
yazılım projesini temelden değiştirecek şeyler içermemelidir.Çünkü bu istek yeniden farklı
bir proje hazırlamak demektir.
5.5. Değişim Sürecindeki Kritik Karar Noktaları
Değişiklikler, potansiyel değişiklikler olduğundan, henüz projenin kaynaklarını
tüketmeye başlamadan belirlenmelidirler. Her görev gibi, değişimin de takip edilmesi
gereken bir yaşam döngüsü yada değişim süreci vardır. Genelde, şekilde görülen 3 kritik
nokta, süreç değişimini belirler. Bu noktalar, değişim çerçevesini oluşturan etmenlerdir.
U
S
Orijinal Değişim Đsteği
Gözden Geçir
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Kavramı
Onayla
Kabul
Red
Değişim Analizi
Gözden Geçir
.
r
g
Ö
Đlerlemeyi
Onayla
Red
Pasif Đstekler
Kabul
Gerçekleştirim & Test
Red
Gözden Geçir
Kararlılığı
Onayla
Kabul
Planlı Gelişime Ekle
Şekil – 5.4 Süreç Değişimi & Kritik Noktalar
Sistem Analizi ve Yazılım Tasarımı
67
Öğr. Gör. Mustafa AKSU
Kavramı Onayla: Değişim istekleri, test grubundan, problemleri tanımlayan kullanıcılardan
ve gereksinim ekleyip çıkaran müşterilerden gelir. Belirli miktarda kaynağı bu değişimlere
ayırmadan önce, değişimleri onaylamak gerekir. Bu, Süreç Değişimi Yönetimi’nde ilk kritik
karar noktasıdır. Bu noktada eğer bir fikir kabul edilirse, gerekli kaynakların sağlanması için
o kavrama bir öncelik verilir.
Đlerlemeyi Onayla: Bir süreç değişimi onaylandıktan sonra, ikinci adımda bu değişimi
projenin gereksinimlerine, belirtimlerine, tasarımına, zaman çizelgesine, bütçesine karşı
değerlendirmek gerekir. Böyle kapsamlı bir analiz, değişim için gereklidir çünkü süreç
değişimi, büyük ihtimalle projenizi büyük ölçüde etkileyecektir. Maliyet-yarar bağlamında
analiz edilen değişim hakkında, ilerleme kararı veya durdurma kararı alınır.
Kararlılığı Onayla: Değişim isteği, planlı geliştirme fazına geçince tamamlanmış demektir.
Gereksinimlerin analizi ve tasarım aşamalarında bu adım, isteğin onaylanmasından hemen
sonra olur. Ama kodlama aşamasında ise, planlı olmayan tüm değişiklikler için ayrı ayrı test
ve gerçekleştirim yapılmalıdır. Bu testlerde hem orijinal durum hem de planlanan değişim
durumu test edilerek yeni durumun herhangi bir sorun yaratıp yaratmadığı belirlenir.
U
S
K
A
Testten sonra, değişimin diğer uygulama parçalarını nasıl etkilediğini gözlemlemelisiniz.
Örneğin, yanlış mantıkta olan bir kullanıcı girdisi alma modülü için doğru olan ara yüz
değiştirilirse, ileride açılacak problemler için bu değişiklik reddedilmelidir.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Reddedilen ve Ertelenen Đstekler: Herhangi bir karar aşamasında, bir istek reddedilebilir
veya ertelenebilir. Bu durumda, istek tüm dökümantasyonuyla birlikte rafa kaldırılmalıdır.
Böylelikle, aynı fikir tekrar ortaya atılacak olursa, neden reddedildiği hemen ortaya konur ve
sebepleri düşünmek üzerine zaman harcanmaz. Eğer şartlar değişirse, ertelenme veya red,
geri çekilebilir.
!! Eğer bir problem üretimi veya testi durduracak kadar aciliyet teşkil ediyorsa, kapsamlı bir
analiz zamanı veya resmi bir karar verme zamanı olmayacaktır. Süreç Değişim Yönetimi
mekanizmasının bir acil durum işleyişi olmak zorundadır. bu işleyiş, analizi ve karar
aşamalarını daha hızlı geçmeyi sağlayacaktır.
Mesela acil durum yaratan problem, biraz değiştirilerek durum aciliyetten çıkarılabilir ve
sonra normal işleyişe dönülebilir. Böylelikle sistem çalışır duruma getirilir ve kapsamlı bir
analiz yapılabilir. Ya da sorun tamamen bir aşamada çözülebilir. Seçimi proje yöneticisi
yapacaktır.
Giriş
.
r
g
Ö
6. HATA YÖNETĐMĐ
Yazılım hataları, ciddi sorunlardır. Bir hatanın bulunması ve düzeltilmesi işleminin
maliyeti, en pahalı yazılım geliştirme aktivitelerinden biridir. Yakın gelecekte, bu hatalar
olmadan yazılım geliştirmek için bir teknik de bulanamayacak gibi gözüküyor. Hatalar
önlemez olabilirler ama her ne kadar önlenemeseler de hataların sayısı ve etkileri “Hata
Yönetimi” sayesinde en az seviyede tutulabilir. Bunu sağlamak için, geliştirme takımlarının
hataları önlemeye, hataları olabildiğince erken yakalamaya yarayan, hataların etkisini
minimuma indiren etkin bir hata yönetimi süreci belirlemeleri gerekir. Bu konuya az
miktarda yapılacak olan yatırımın getirecekleri çok daha fazla olacaktır. Aşağıdaki
bölümlerde, Hata Yönetimi için tutarlı bir model anlatılacaktır. Bu model, bir standart
olmasa bile, Hata Yönetim Teorisi’nin ana noktalarını çok güzel açığa çıkararak bir rehber
olmaktadır.
Hata yönetimi süreci genel olarak aşağıdaki prensipleri temel alır:
Sistem Analizi ve Yazılım Tasarımı
68
Öğr. Gör. Mustafa AKSU
-
-
-
Asıl hedef hataları önlemektir. Bu koşulun mümkün olmadığı veya uygulanabilir olmadığı
durumlarda, hedef mümkün olduğu kadar hızlı bir şekilde hatayı bulmak ve etkisini en
aza indirmek olmalıdır.
Hata yönetimi süreci risk odaklı, risk merkezli olmalıdır. Örneğin stratejiler, öncelikler,
kaynaklar, risk azaltma fikrine uygun olmalıdır.
Hata ölçümü, süreci geliştirmek için geliştirme takımı tarafından kullanılmalıdır ve
yazılım geliştirme süreci ile bütünleşik olmalıdır. Başka bir deyişle, proje takımı işini
yaparken kaynaktaki sorunları da ortaya çıkarmalıdır. Bu işlem daha sonra projeyle ilgisi
olmayan insanlar tarafından yapılmamalıdır.
Bilgi yakalama ve analizi mümkün olduğu kadar çok otomatikleştirilmelidir.
Süreci geliştirmek için, hata bilgilerinden yararlanılmalıdır.
Hatalar genelde kusurlu, bozuk süreçlerden kaynaklandığı için bu süreçler
değiştirilmelidir.
6.1. HATA YÖNETĐM SÜRECĐ
U
S
Önceki konuda anlatılanları ve prensipleri hatırlayarak hata yönetimi için aşağıdaki
şekildeki gibi bir süreç yapısı çıkarılabilir:
HATA
ÖNLEME
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
HATA
BULMA
ANA
RAPOR
OLUŞT
1
-
-
-
-
-
K
A
HATA
ÇÖZÜMLEME
SÜREÇ
GELĐŞTĐRME
YÖNETĐMSEL RAPORLAMA
Hata Önleme: Hata riskini azaltacak teknikler, metodolojiler, standard süreçler
yaratma.
Ana Raporların Temelini Oluşturma: Geliştirmeye devam edilebilecek şekilde ana
raporları oluşturma. Herhangi bir ana rapor temeli hazırlanırsa, daha sonraki
değişiklikleri kontrol altına almak kolaylaşır. Raporlardaki hatalar, raporun temeli detaylı
şekilde oluşturulduktan sonra hata olarak kabul edilirler, daha önce hata olarak kabul
edilmezler.
Hata Bulma: Hataları, geliştirme takımını bilgilendirmek doğrultusunda tanımlama ve
raporlama. Bir hata, belgelenmeden ve geliştirme takımın ilgili birimleri bilgilendirilince
bulunmuş sayılmalıdır.
Hata Çözümleme: Geliştirme takımı tarafından yapılan, bir hatanın düzeltilmesi,
öncelik verilmesi, belgelenmesi işi. Bu işlem ayrıca, çözümlemenin doğru yapıldığının
kontrolünü de kapsar.
Süreç Geliştirme: Đçinde hata bulunan sürecin analizi ve tanımlanması yapılmasından
sonra, ileride bu ve buna benzer hataların yapılmaması için sürecin üzerinde çalışma
yapılmasıdır.
Yönetimsel Raporlama: Yönetime, risk yönetimi, proje yönetimi, süreç geliştirimi gibi
konularda yardımcı olabilmek için hata bilgisinin analizi ve raporlanmasıdır.
.
r
g
Ö
6.1.1 HATA ÖNLEME
Hiç şüphesiz, hatalar için en iyi yaklaşım onları ortadan kaldırmaktır. En çok istenen çözüm
bu olsa da şu anki teknolojiyle bunu sağlamak imkânsızdır. Bu yüzden geliştiricilere hataları
çok çabuk bulmak ve etkilerini en aza indirgemek için stratejiler gerekmektedir. Hata
Sistem Analizi ve Yazılım Tasarımı
69
Öğr. Gör. Mustafa AKSU
yönetimi programında, hata önleme teknikleri tanımlanması ve gerçekleştiriminin önceliği
yüksek olmak zorundadır.
Hata önleme, sistemdeki büyük riskleri bulmak ile başlamalıdır. Önemli risklerin
tanımlanmış olması, takımın en fazla etkiyi yapacak hataların ne olduğunu görmesinde
yarar sağlar. Daha sonra bu riskleri önlemek için stratejiler geliştirilebilir. Hata önlemedeki
ana adımlar şu şekildedir:
Kritik
Riskleri
Tanımla
-
Beklenen
Etkiyi
Tahminle
Beklenen
Etkiyi En Aza
Đndir
Kritik Riskleri Tanımla: Sistemin veya projenin karşı karşıya olduğu kritik riskleri
tanımla. Bu riskler sistemin oluşturulmasını, dağıtımını, işleyişini engelleyen risklerdir.
Beklenen Etkiyi Tahminle: Her kritik risk için, riskin gerçekleştiği anda oluşacak olan
finansal etkiyi hesapla.
Beklenen Etkiyi En Aza Đndir: En önemli riskler belirlendikten sonra, her riski yok
etmeye çalış. Yok edilemeyen riskler için, riskin problem olma ihtimalini ve etkisini en
aza indirmeye* çalış.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
*ETKĐYĐ EN AZA ĐNDĐRME TEKNĐKLERĐ
Hataların yaratacağı etkileri en aza indirme tekniklerinin bazıları aşağıda sıralanmıştır:
-
-
-
Kalite Güvence: Kullanılan süreçlerin istenilen sonuçları üretebilmesi için yeterli olup
olmadıklarını kontrol amaçlı olarak, kalite güvence teknikleri tasarlanır.
Eğitim ve Çalışma(Geliştirme Takımı Đçin): Đşgücü ne kadar iyi eğitilirse, işin kalitesi
o kadar yüksek olacaktır. Bir çok hata, çalışanların işlerini nasıl yapacaklarını tam
anlamamasından kaynaklanmaktadır. Bilgisayar teknolojisi gün geçtikçe ilerleyen bir
teknolojidir. Đlerideki yıllarda, gelişim sürdükçe bilgisayarlar daha karmaşık bir hal
alacaktır. Bu da yazılım projelerindeki eğitimin önemini göstermektedir.
Eğitim ve Çalışma(Müşteri Đçin): Daha fazla insan bilgisayar kullandıkça, sistemin
karmaşıklığı daha da büyür. Bu da kullanıcıların eğitiminin önemini artırır. Geliştirme
takımı eğitiminden farklı olarak, kullanıcı eğitimlerinde, teknik bilgiye sahip olmayan
kullanıcıları eğitmek için daha yaratıcı fikirlere ihtiyaç duyulur.
Metodoloji & Standardlar: Kalite artırımının bir yolu da varyasyonları azaltmaktır. Bu
da standartlar ve metodolojilerle sağlanabilir.
Dayanıklı Tasarım: Dayanıklı tasarımın birçok çeşidi vardır. Dayanıklı tasarımda, bir
hata oluşması için, birden fazla bağımsız birimin çökmesi gerekir. Teknoloji ilerledikçe
hataları engelleyen, bulan ve etkilerini en aza indiren sistemler tasarlamak da
kolaylaşmaktadır.
.
r
g
Ö
6.1.2. ANA RAPORLAR OLUŞTURMA & RAPOR OLUŞTURMA NOKTALARI
Raporlar, daha önce belirlenmiş olan kilometre aşlarına gelindiğinde hazırlanırlar. Bu
rapordan sonra projede geliştirme sürecinin diğer aşamasına geçilir. Proje kilometre
taşlarını geçtikçe, barındırdığı hataların sistem üzerinde daha büyük bir etkisi olur ve
değişiklikler yapmak için daha çok kaynak tüketilir.
Hata, projenin aşamaları bitirdikten sonra gereksinimleri karşılayamamasıdır. Bu yüzden
aşamalar, hatalar için önemlidirler. Örneğin bir programcı programlama ve testten sorumlu
ise, test yapılamadan diğer aşamaya geçilemeyecektir. Bu durumda, test şamasında
bulunacak bir “bug” hata olarak gösterilemeyecektir. Ama test ve kodlama iki ayrı takım
Sistem Analizi ve Yazılım Tasarımı
70
Öğr. Gör. Mustafa AKSU
halinde yapılsaydı, iki ayrı aşama olacaklardı. Bu durumda bulunan “bug”, hata olarak
gösterilebilecekti.
Aşamaları belirlemek iki aktiviteyi içerir:
-
Anahtar Raporları Belirle: Proje gelişiminde birçok rapor oluşturulur. Bu raporlardan
hangilerinin ana raporlar oldukları belirlenmelidir.
Her Ana Rapor Đçin Bir Standard Belirle: Her ana rapor için, gereksinimleri ve
kriterleri belirle.
6.1.3. HATA BULMA
Eğer bir teknoloji, hataların oluşmayacağını garanti edemiyorsa, hatalar onarılması
çok pahalıya mal olmadan bulunmalıdır. Bu modele göre, bir problem, hata bilinmeden de
bulunabilir. Böyle durumlarda, problem raporlanmadan önce, hata raporlanmalıdır.
Hataların çabuk bulunması önemli olduğu için, hata bulma, raporlama ile ilgili stratejiler
geliştirilmelidir.
U
S
K
A
Hataları daha kolay bulabilmek için, kuruluş, hataları katagorilendirmelidir. Bu iş bir
kez ya da yıllık olarak yapılan bir iştir. Đşe, tüm dallardan uzmanlaşmış kişiler dahil
olmalıdır. Oluşan grubun amacı, yazılım projesinde en çok oluşan hataları bulmaktır.
Bulunan her hata kategorisi isimlendirilmelidir. Bunun amacı kategorilerdeki karmaşıklığı
önlemektir.
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Hata bulma sürecinin adımları aşağıdaki gibidir:
1. Hatayı bul
2. Hatayı raporla
3. Hatayı doğrula
.
r
g
Ö
Hatayı
Doğrula
Hatayı
Raporla
Hatayı
Bul
Hata kaynağını belirleme stratejileri:
1. Hatayı yakalamak için araçlar kullanmak – Microsoft DrWatson gibi
2. Hatayı bulmak için ekstra kod yazmak – log tutmak için yazılan kodlar gibi.
3. Raporlanmış olan hatayı analiz ermek.
6.1.4. HATA ÇÖZÜMLEME
Geliştiriciler hatayı doğruladıktan sonra, çözümleme süreci başlar. Hata çözümleme
aşağıdaki şekilde olur:
1. Riske Öncelik Ataması Yap
2. Onarımı Planla
3. Hatayı Onar
4. Hatayı Raporla
Öncelik
Belirleme
Hata
Onarma
Onarımı
Planlama
Çözüm
Raporlama
Bu adımın amacı aşağıdaki soruları cevaplamak ve gerekli olan işlemleri başlatmaktır.
-
Bulunan eski bir hata mı, yeni mi?
Bu hatayı onarırken hangi öncelik sırası verilmelidir?
Sistem Analizi ve Yazılım Tasarımı
71
Öğr. Gör. Mustafa AKSU
-
Onarım sırasında etkiyi en aza nasıl indirebiliriz?Örneğin, kullanıcılara hatadan
bahsetmeli miyiz?
Hata onarımı için ön çalışma gerekli midir?
Hata onarıldıktan sonra ve onarım doğrulandıktan sonra, gerekli geliştiriciler,
kullanıcılar, testçiler hatanın onarıldığı hakkında bilgilendirilmelidirler. Bu bilgilendirme
aşağıdaki kısımları içermelidir:
-
Hatanın kaynağı
Onarımın ne zaman yapıldığı
Onarımın nasıl yapıldığı
6.1.5. SÜREÇ GELĐŞTĐRME
Bu aşama, birçok organizasyon tarafından ihmal edilmektedir ama aslında çok büyük
yararı vardır. NASA, her hatanın sistemin bir zayıflığı olduğunu söylemektedir. Buna göre
hatanın önemi ne olursa olsun, sistemin zayıflığını belirttiği için aynı derecede önemlidirler.
Hatanın çok büyük bir problem olmaması sadece geliştiricinin şansına bağlıdır. Bu yüzden
küçük hatalar bile, süreçlerin nasıl iyileştirileceği ve büyük problemlerin nasıl önleneceği
hakkında bize bir şans vermektedir. Hata, çok büyük bir şey olmayabilir ama o hatanın var
olması büyük bir şeydir.
U
S
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
Çalışmalardan elde edilen sonuçlara göre, katılımcılar sürece geri dönerek hatanın
nereden ve nasıl kaynaklandığını inceleyebilirler. Daha sonra, bu hatanın doğrulama
sürecini nasıl geçtiğini anlayabilmek için o doğrulama sürecini inceleyebilirler. Bu
incelemelerden sadece yararlı bilgiler kazanılmaz, aynı zamanda insanların işlerini daha
dikkatli yapmaları da sağlanır. Bu tip çalışmaların kuruluşlara çok büyük yararları vardır.
Örneğin NASA, bu işi bir adım daha ileriye götürür ve şu soruyu sorar: Eğer bu hata
projenin bu safhasına kadar fark edilmeden gelebildiyse, daha keşfedilmemiş ne gibi hatalar
olabilir? Böylece proje sadece problem oluşturan hataları bulma konusunda değil aynı
zamanda oluşmayan problemlerin hatalarını bulmada da güçlendirilir.
6.1.6. YÖNETĐMSEL RAPORLAMA
.
r
g
Ö
Hata bilgisi, hata yönetimi sürecinin doğal bir çıktısıdır ve bu çıktının analiz edildikten sonra
proje yönetimine ve üst yönetime iletilmesi önemlidir. Bu bilgi, hata tipleri, hata sıklıkları,
hata eğilimleri, maliyetleri… şeklindedir. Projenin, gerekli rotasında ilerlemesini belirlemede,
hataların ne kadar sıklıkla oluştuğunun bilinmesi yararlı olacaktır. Hata onarma etkinliği de
en yararlı bilgilerden biridir. Bu bilgiler yönetime karar aşamalarında yol gösterici olabilir.
Hata yönetimi sırasında bilgi toplamanın amaçları:
- Bireysel hataları raporlamak
- Proje yönetimin daha sağlıklı ve yerinde kararlar vermesine yardım etmek için gerekli
ölçümleri sağlamak.
- Üst yönetimin stratejik kararlar vermesi için bilgi sağlamak.
- Projenin geliştirilebilecek yönlerini belirlemek ve etkileri en azda tutabilmek.
Yönetime raporlar verilmesi, önemli bir adımdır ve her zaman yapılması gerekmektedir
fakat yönetimi daha ileriye götürmeyecek gereksiz raporlar da verilmemelidir. Verilen
raporların mutlaka birer amaçları olmalıdır.
Sistem Analizi ve Yazılım Tasarımı
72
Öğr. Gör. Mustafa AKSU
Kaynaklar
Sistem Analizi (Doç. Dr. Haluk Erkut- Kıyı Yayınları 1989)
Đşletme Yönetiminde Sistem Yaklaşımı (Prof. Dr. H. Öner Esen - Alfa Basım Yayın Dağıtım 1998)
Yönetim Bilgi Sistemleri (Doç. Dr. Hadi Gökçen - EPĐ Yayıncılık 2002)
Brackett, J.W. "Software Requirements." Curriculum Module SEI-CM-19-1.2, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, Pa., Jan 1990. This paper can be downloaded from
the web at http://www.asset.com/WSRD/abstracts/ABSTRACT_1715.html.
Romback, H. D. "Software Specification: A Framework." Curriculum Module SEI-CM-11-2.1, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., Jan. 1990. This paper can be
downloaded from the web at http://www.asset.com/WSRD/abstracts/ABSTRACT_1709.html.
McConnell, Steve "Software Project Survival Guide: How to Be Sure Your First Important Project Isn't
Your Last." Redmond, WA: Microsoft Press, 1998.
U
S
Establishing & Implementing Software QA, Arati Prabhkar, IonIdea Enterprise Solutions Pvt Ltd,
Banglore
Quality Assurance Concepts, QA Concepts and Implemetation Guidelines, August 2000, Nadeem
Kayani
Berczuk, Steve. "Configuration Management Patterns", 1997.
http://www.bell-labs.com/cgiuser/
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
K
A
OrgPatterns/OrgPatterns?ConfigurationManagementPatterns.
Compton, Stephen B, Configuration Management for Software, VNR Computer Library,
Van Nostrand Reinhold, 1993.
Continuus Software Corp., "Work Area Management", Continuus/CM: Change
Management for Software Development.
http://www.continuus.com/developers/developersACE.html.
Dart, Susan, "Spectrum of Functionality in Configuration Management Systems",
Software Engineering Institute, 1990.
http://www.sei.cmu.edu/technology/case/scm/tech_rep/TR11_90/TOC_TR11_90.html
Jameson, Kevin, Multi Platform Code Management, O'Reilly & Associates, 1994
Linenbach, Terris, "Programmers' Canvas: A pattern for source code management" 1996.
http://www.rahul.net/terris/ProgrammersCanvas.htm.
.
r
g
Ö
Lyon, David D, Practical CM, Raven Publishing, 1997
McConnell, Steve, "Best Practices: Daily Build and Smoke Test", IEEE Software, Vol.
13, No. 4, July 1996
van der Hoek, Andre, Hall, Richard S., Heimbigner, Dennis, and Wolf, Alexander L.,
"Software Release Management", Proceedings of the 6th European Software Engineering
Conference, Zurich, Switzerland, 1997.
Jones, Do-While "Repeatable Software Development, Part I: Quality Assurance." Software
Developement, May 1995.
Jones, Do-While "Repeatable Software Development, Part II: Configuration and Requirements
Management." Software Developement, June 1995.
A Field Guide to Effective Requirements Management Under SEI's Capability Maturity Model
CMM Key Practices for Level 2 - Requirements Management
LTInsights Managing Requirements for Successful Software Projects
Requirements Management Policies and Procedures
Requirements Management Using Tables
Sistem Analizi ve Yazılım Tasarımı
73
Öğr. Gör. Mustafa AKSU
Software Program Managers Network - 16 Critical Software Practices TM
Software QA and Testing Resource Center – FAQ
Software QA and Testing Resource Center - Other Resources
Software QA and Testing Resource Center – Tools
StickyMinds_com Article info Quality Assurance Section for a Design Specification
Practical Software Measurement, A foundation for objective project management, PSM SPE Workshop,
Office of the Under Secretary of Defense, Acquisition and Technology
SSC SAN DIEGO POLICY FOR SOFTWARE PRODUCT ENGINEERING, Version 1.1 - 10/9/97
Level 3 - Software Product Engineering, Software Product Engineering a key process area for level 3:
Defined, www.sei.org
U
S
Selected Key Practices, http://www.dfki.de/fluids/References.html#Paulk:93b
www.stickyminds.com
Software Product Engineering Workshop 1999.pdf
a
f
a
t
s
u Ü)
M
.
.
S
r
.
ö
K
(
G
Software Product Engineering Workshop 2000.pdf
K
A
http://www.dfki.de/fluids/Software_Quality_Assurance_Management.html
July 1999 Project Management Software Change Management.htm
Cisco - Change Management: Best Practices White Paper
Qwest Change Management Process Redesign Evaluation March 25, 2002 Version 3.0 Prepared for:
Arizona Corporation Commission
IIR-Presentation, Ivica Ivica Crnkovic
Tips for Collecting Customer Requirements, Author(s): Steve Miller
Best Pratices of Defect Prevention, Latha Rajesh
.
r
g
Ö
www.stickyminds.com
www.bugmonitor.com
Communicating and Managing Bugs Efficiently, Jitu Borah
http://www.defectmanagement.com/defectmanagement/
CMM Key Practices for Level 3 - Integrated Software Management.htm
www.sei.edu
www.google.com.tr
Key Pratcies of the CMM, Version 1.1, Mark C. Paulk Charles V. Weber Suzanne M. Garcia Mary Beth
Chrissis Marilyn Bush, Software Engineering Institute, Carnegie Mellon University, Pittsburgh,
Pennsylvania 15213, CMU/SEI-93-TR-25, ESC-TR-93-178
Sistem Analizi ve Yazılım Tasarımı
74
Öğr. Gör. Mustafa AKSU