Chapter 9 – Software Evolution

30/10/2014 Chapter 9 Software Evolution 1

Topics covered

 Evolution processes
 Legacy systems
 Software maintenance
 Evrim süreçleri
 Eski sistemler
 Yazılım bakımı

30/10/2014 Chapter 9 Software Evolution 2

Software change

 Yazılım değişikliği kaçınılmaz

 Yazılım kullanıldığında yeni gereksinimler ortaya çıkıyor;
 İş ortamı değişir;
 Hatalar onarılmalıdır;
 Sisteme yeni bilgisayarlar ve ekipmanlar eklenir;
 Sistemin performansının veya güvenilirliğinin
iyileştirilmesi gerekebilir.
 Tüm kuruluşlar için temel sorun, mevcut yazılım
sistemlerinde değişikliği uygulamak ve yönetmektir.

30/10/2014 Chapter 9 Software Evolution 3

Importance of evolution

 İşletme için bu varlıkların değerini korumak için

değiştirilmeleri ve güncellenmeleri gerekir.
 Kuruluşların yazılım sistemlerine büyük yatırımları vardır
- bunlar kritik iş varlıklarıdır.
 Büyük şirketlerde yazılım bütçesinin büyük bir kısmı,
yeni yazılım geliştirmek yerine mevcut yazılımları
değiştirmeye ve geliştirmeye ayrılmıştır.

30/10/2014 Chapter 9 Software Evolution 4

A spiral model of development and evolution

30/10/2014 Chapter 9 Software Evolution 5

Evolution and servicing

30/10/2014 Chapter 9 Software Evolution 6

Evolution and servicing

 Evrim
 Bir yazılım sisteminin yaşam döngüsünde operasyonel
kullanımda olduğu ve sistemde yeni gereksinimler
önerilip uygulandıkça gelişen aşama.
 Servis
 Bu aşamada, yazılım yararlı olmaya devam eder, ancak
yapılan değişiklikler yazılımı çalışır durumda tutmak için
gerekli olanlardır, yani hata düzeltmeleri ve yazılım
ortamındaki değişiklikleri yansıtacak değişiklikler. Yeni
işlevsellik eklenmez.
 aşamalı
 Yazılım yine de kullanılabilir
30/10/2014
ancak üzerinde herhangi bir 7
Chapter 9 Software Evolution
 Evolution processes

30/10/2014 Chapter 9 Software Evolution 8

Evolution processes

 Yazılım geliştirme süreçleri şunlara bağlıdır:

 Bakımı yapılan yazılımın türü;
 Kullanılan geliştirme süreçleri;
 İlgili kişilerin becerileri ve deneyimleri.
 Değişim önerileri, sistem evriminin itici gücüdür.
 Değişiklikten etkilenen bileşenlerle bağlantılı olmalı,
böylece değişikliğin maliyetinin ve etkisinin tahmin
edilmesine olanak sağlamalıdır.
 Değişiklik belirleme ve evrim, sistem ömrü boyunca
devam eder.
30/10/2014 Chapter 9 Software Evolution 9
Change identification and evolution processes

30/10/2014 Chapter 9 Software Evolution 10

The software evolution process

30/10/2014 Chapter 9 Software Evolution 11

Change implementation

30/10/2014 Chapter 9 Software Evolution 12

Change implementation

 Iteration of the development process where the revisions to the system are designed,
implemented and tested.
 A critical difference is that the first stage of change implementation may involve
program understanding, especially if the original system developers are not
responsible for the change implementation.
 During the program understanding phase, you have to understand how the program
is structured, how it delivers functionality and how the proposed change might affect
the program.
 Sistem revizyonlarının tasarlandığı, uygulandığı ve test edildiği geliştirme sürecinin
yinelenmesi.
 Kritik bir fark, özellikle orijinal sistem geliştiricileri değişikliğin uygulanmasından
sorumlu değilse, değişiklik uygulamasının ilk aşamasının programın anlaşılmasını
içerebilmesidir.
 Programı anlama aşamasında, programın nasıl yapılandırıldığını, işlevselliği nasıl
sağladığını ve önerilen değişikliğin programı nasıl etkileyebileceğini anlamanız
gerekir.
30/10/2014 Chapter 9 Software Evolution 13
Urgent change requests

 Urgent changes may have to be implemented without going through all

stages of the software engineering process
 If a serious system fault has to be repaired to allow normal operation to continue;
 If changes to the system’s environment (e.g. an OS upgrade) have unexpected
effects;
 If there are business changes that require a very rapid response (e.g. the release
of a competing product).
Yazılım mühendisliği sürecinin tüm aşamalarından geçmeden acil değişikliklerin
uygulanması gerekebilir.
Normal çalışmaya devam edebilmek için ciddi bir sistem arızasının onarılması
gerekiyorsa;
Sistem ortamındaki değişikliklerin (ör. bir işletim sistemi yükseltmesi) beklenmeyen
etkileri varsa;
Çok hızlı müdahale gerektiren iş değişiklikleri varsa (örn. rakip bir ürünün piyasaya
sürülmesi).

30/10/2014 Chapter 9 Software Evolution 14

The emergency repair process

30/10/2014 Chapter 9 Software Evolution 15

Agile methods and evolution

 Çevik yöntemler artımlı geliştirmeye dayalıdır, bu nedenle geliştirmeden evrime geçiş

sorunsuzdur.
 Evrim, sık sistem sürümlerine dayalı geliştirme sürecinin basit bir devamıdır.
 Otomatik regresyon testi, bir sistemde değişiklik yapıldığında özellikle değerlidir.
 Değişiklikler ek kullanıcı hikayeleri olarak ifade edilebilir.

30/10/2014 Chapter 9 Software Evolution 16

Handover problems

 Geliştirme ekibinin çevik bir yaklaşım kullandığı ancak

geliştirme ekibinin çevik yöntemlere aşina olmadığı ve
plana dayalı bir yaklaşımı tercih ettiği yer.
 Evrim ekibi, evrimi desteklemek için ayrıntılı belgeler
bekleyebilir ve bu, çevik süreçlerde üretilmez.
 Geliştirme için plana dayalı bir yaklaşımın kullanıldığı
ancak geliştirme ekibinin çevik yöntemleri kullanmayı
tercih ettiği durumlarda.
 Evrim ekibi, otomatik testler geliştirmeye sıfırdan
başlamak zorunda kalabilir ve sistemdeki kod, çevik
geliştirmede beklendiği gibi yeniden düzenlenmemiş ve
basitleştirilmemiş olabilir.
30/10/2014 Chapter 9 Software Evolution 17
 Legacy systems

30/10/2014 Chapter 9 Software Evolution 18

Legacy systems

 Eski sistemler, artık yeni sistem geliştirme için

kullanılmayan dillere ve teknolojiye dayanan eski
sistemlerdir.
 Eski yazılımlar, anabilgisayarlar gibi daha eski
donanımlara bağlı olabilir ve ilişkili eski süreçlere ve
prosedürlere sahip olabilir.
 Eski sistemler sadece yazılım sistemleri değil, donanım,
yazılım, kitaplıklar ve diğer destekleyici yazılım ve iş
süreçlerini içeren daha geniş sosyo-teknik sistemlerdir.

30/10/2014 Chapter 9 Software Evolution 19

The elements of a legacy system

30/10/2014 Chapter 9 Software Evolution 20

Legacy system components

 Sistem donanımı Eski sistemler, artık mevcut olmayan

donanımlar için yazılmış olabilir.
 Destek yazılımı Eski sistem, eski veya desteklenmeyen
bir dizi destek yazılımına bağlı olabilir.
 Uygulama yazılımı İş hizmetlerini sağlayan uygulama
sistemi genellikle bir dizi uygulama programından oluşur.
 Uygulama verileri Bunlar, uygulama sistemi tarafından
işlenen verilerdir. Tutarsız, yinelenmiş veya farklı
veritabanlarında tutulmuş olabilirler.

30/10/2014 Chapter 9 Software Evolution 21

Legacy system components

 İş süreçleri Bunlar, işletmede bazı iş hedeflerine ulaşmak

için kullanılan süreçlerdir.
 İş süreçleri, eski bir sistem etrafında tasarlanabilir ve
sağladığı işlevsellik tarafından kısıtlanabilir.
 İş politikaları ve kuralları Bunlar, işin nasıl yürütülmesi
gerektiğine ilişkin tanımlar ve iş üzerindeki
kısıtlamalardır. Eski uygulama sisteminin kullanımı bu
politikalara ve kurallara dahil edilebilir.

30/10/2014 Chapter 9 Software Evolution 22

Legacy system layers

30/10/2014 Chapter 9 Software Evolution 23

Legacy system replacement

 Eski sistem değişimi riskli ve pahalı olduğundan

işletmeler bu sistemleri kullanmaya devam ediyor
 Sistem değişimi birkaç nedenden dolayı risklidir
 Eksiksiz sistem spesifikasyonu eksikliği
 Sistem ve iş süreçlerinin sıkı entegrasyonu
 Eski sisteme gömülü belgelenmemiş iş kuralları
 Yeni yazılım geliştirme gecikebilir ve/veya bütçeyi aşabilir

30/10/2014 Chapter 9 Software Evolution 24

Legacy system change

 Eski sistemlerin değiştirilmesi birkaç nedenden dolayı

pahalıdır:
 Tutarlı programlama stili yok
 Eski programlama dillerinin bu dil becerilerine sahip
birkaç kişiyle kullanılması
 Yetersiz sistem dokümantasyonu
 Sistem yapısı bozulması
 Program optimizasyonları, bunların anlaşılmasını
zorlaştırabilir
 Veri hataları, yineleme ve tutarsızlık
30/10/2014 Chapter 9 Software Evolution 25
Legacy system management

 Eski sistemlere güvenen kuruluşlar, bu sistemleri

geliştirmek için bir strateji seçmelidir.
 Sistemi tamamen hurdaya çıkarın ve iş süreçlerini artık
gerekli olmayacak şekilde değiştirin;
 Sistemi korumaya devam edin;
 Sürdürülebilirliğini iyileştirmek için yeniden mühendislik
yaparak sistemi dönüştürün;
 Sistemi yeni bir sistemle değiştirin.
 Seçilen strateji, sistem kalitesine ve onun iş değerine
bağlı olmalıdır.
30/10/2014 Chapter 9 Software Evolution 26
Figure 9.13 An example of a legacy system
assessment

30/10/2014 Chapter 9 Software Evolution 27

Legacy system categories

 Düşük kalite, düşük iş değeri

 Bu sistemler rafa kaldırılmalıdır.
 Düşük kaliteli, yüksek iş değeri
 Bunlar önemli bir iş katkısı sağlar, ancak bakımı
pahalıdır. Uygun bir sistem mevcutsa yeniden
tasarlanmalı veya değiştirilmelidir.
 Yüksek kaliteli, düşük iş değeri
 COTS ile değiştirin, tamamen hurdaya çıkarın veya
bakım yapın.
 Yüksek kaliteli, yüksek iş değeri
 Normal sistem bakımını
30/10/2014
kullanarak çalışmaya devam
Chapter 9 Software Evolution 28
Business value assessment

 Değerlendirme farklı bakış açılarını dikkate almalıdır

 Sistem son kullanıcıları;
 Ticari Müşteriler;
 Çizgi yöneticileri;
 BT yöneticileri;
 Üst düzey yöneticiler.
 Farklı paydaşlarla görüşün ve sonuçları harmanlayın.

30/10/2014 Chapter 9 Software Evolution 29

Issues in business value assessment

 sistemin kullanımı
 Sistemler yalnızca ara sıra veya az sayıda kişi tarafından
kullanılıyorsa, düşük bir iş değerine sahip olabilirler.
 Desteklenen iş süreçleri
 Verimsiz iş süreçlerinin kullanımını zorlayan bir sistem,
düşük bir iş değerine sahip olabilir.
 Sistem güvenilirliği
 Bir sistem güvenilir değilse ve sorunlar ticari müşterileri
doğrudan etkiliyorsa, sistemin iş değeri düşüktür.
 Sistem çıkışları
 İş, sistem çıktılarına Chapter
30/10/2014 bağlıysa, sistem yüksek bir iş
9 Software Evolution 30
System quality assessment

 İş süreci değerlendirmesi
 İş süreci, işletmenin mevcut hedeflerini ne kadar iyi
destekliyor?
 Çevre değerlendirmesi
 Sistemin ortamı ne kadar etkilidir ve bakımı ne kadar
pahalıdır?
 Uygulama değerlendirmesi
 Uygulama yazılım sisteminin kalitesi nedir?

30/10/2014 Chapter 9 Software Evolution 31

Business process assessment

 Bakış açısı odaklı bir yaklaşım kullanın ve sistem

paydaşlarından cevaplar arayın
 Tanımlanmış bir süreç modeli var mı ve izleniyor mu?
 Kuruluşun farklı bölümleri aynı işlev için farklı süreçler mi
kullanıyor?
 Süreç nasıl uyarlandı?
 Diğer iş süreçleriyle ilişkileri nelerdir ve bunlar gerekli
midir?
 Süreç, eski uygulama yazılımı tarafından etkili bir şekilde
destekleniyor mu?
 Örnek - web tabanlı siparişin yaygın kullanımı nedeniyle
bir seyahat siparişi sisteminin ticari değeri düşük olabilir.
30/10/2014 Chapter 9 Software Evolution 32
Factors used in environment assessment

Factor Questions
Supplier stability Is the supplier still in existence? Is the supplier financially stable and
likely to continue in existence? If the supplier is no longer in business,
does someone else maintain the systems?
Tedarikçi hala var mı? Tedarikçi finansal olarak istikrarlı mı ve varlığını
sürdürmesi muhtemel mi? Tedarikçi artık faaliyet göstermiyorsa
sistemlerin bakımını başka biri mi yapıyor?
Failure rate Does the hardware have a high rate of reported failures? Does the
support software crash and force system restarts?
Donanımda bildirilen arıza oranı yüksek mi? Destek yazılımı çöküyor
ve sistemi yeniden başlatmaya zorluyor mu?
Age How old is the hardware and software? The older the hardware and
support software, the more obsolete it will be. It may still function
correctly but there could be significant economic and business
benefits to moving to a more modern system.
Donanım ve yazılım kaç yaşında? Donanım ve destek yazılımı ne
kadar eskiyse, o kadar eski olacaktır. Yine de doğru şekilde çalışabilir,
ancak daha modern bir sisteme geçmenin önemli ekonomik ve ticari
30/10/2014 faydaları olabilir.
Chapter 9 Software Evolution 33
Factors used in environment assessment

Factor Questions
Support requirements Donanım ve yazılım için hangi yerel destek gereklidir? Bu
destekle ilgili yüksek maliyetler varsa, sistem değiştirmeyi
düşünmeye değer olabilir.
Maintenance costs Donanım bakım ve destek yazılım lisanslarının maliyetleri
nelerdir? Eski donanım, modern sistemlerden daha yüksek
bakım maliyetlerine sahip olabilir. Destek yazılımlarının yıllık
lisanslama maliyetleri yüksek olabilir.
Interoperability Sistemi diğer sistemlere bağlarken sorunlar var mı?
Örneğin, derleyiciler işletim sisteminin güncel sürümleriyle
birlikte kullanılabilir mi? Donanım emülasyonu gerekli mi?

30/10/2014 Chapter 9 Software Evolution 34

Factors used in application assessment

Factor Questions
Understandability Mevcut sistemin kaynak kodunu anlamak ne kadar zor? Kullanılan
kontrol yapıları ne kadar karmaşık? Değişkenlerin işlevlerini
yansıtan anlamlı adları var mı?
Documentation Hangi sistem belgeleri mevcut? Dokümantasyon eksiksiz, tutarlı
ve güncel mi?
Data Sistem için açık bir veri modeli var mı? Veriler dosyalar arasında
ne ölçüde çoğaltılır? Sistem tarafından kullanılan veriler güncel ve
tutarlı mı?
Performance IUygulamanın performansı yeterli mi? Performans sorunlarının
sistem kullanıcıları üzerinde önemli bir etkisi var mı?

30/10/2014 Chapter 9 Software Evolution 35

Factors used in application assessment

Factor Questions
Programming language Sistemi geliştirmek için kullanılan programlama dili için
modern derleyiciler mevcut mu? Programlama dili hala yeni
sistem geliştirme için kullanılıyor mu?
Configuration Sistemin tüm bölümlerinin tüm sürümleri bir yapılandırma
management yönetim sistemi tarafından yönetiliyor mu? Mevcut sistemde
kullanılan bileşenlerin sürümlerinin açık bir açıklaması var
mı?
Test data Sistem için test verileri mevcut mu? Sisteme yeni özellikler
eklendiğinde yapılan regresyon testlerinin kaydı var mı?
Personnel skills Uygulamayı sürdürme becerisine sahip kişiler var mı?
Sistemle ilgili tecrübesi olan kişiler var mı?

30/10/2014 Chapter 9 Software Evolution 36

System measurement

 Başvuru sisteminin kalitesini değerlendirmek için nicel

veriler toplayabilirsiniz.
 Sistem değişikliği isteklerinin sayısı; Bu birikmiş değer ne
kadar yüksek olursa, sistemin kalitesi o kadar düşük olur.
 Sistem tarafından kullanılan farklı kullanıcı arayüzlerinin
sayısı; Ne kadar çok arayüz olursa, bu arayüzlerde
tutarsızlıklar ve fazlalıklar olma olasılığı o kadar artar.
 Sistem tarafından kullanılan veri hacmi. Sistem
tarafından işlenen veri hacmi (dosya sayısı, veritabanı
boyutu vb.) arttıkça, bu verilerdeki tutarsızlıklar ve
hatalar da artmaktadır.
 Eski verileri temizlemek
30/10/2014 Chapterçok pahalı
9 Software Evolution ve zaman alan bir 37
 Software maintenance

30/10/2014 Chapter 9 Software Evolution 38

Software maintenance

 Kullanıma alındıktan sonra bir programı değiştirmek.

 Terim çoğunlukla özel yazılımı değiştirmek için kullanılır.
Jenerik yazılım ürünlerinin yeni sürümler oluşturmak için
geliştiği söyleniyor.
 Bakım normalde sistem mimarisinde büyük değişiklikler
içermez.
 Değişiklikler, mevcut bileşenleri değiştirerek ve sisteme
yeni bileşenler ekleyerek uygulanır.

30/10/2014 Chapter 9 Software Evolution 39

Types of maintenance

 Arıza onarımları
 Hataları/güvenlik açıklarını düzeltmek ve eksiklikleri
gidermek için bir sistemi değiştirmek, gereksinimlerini
karşılar.
 çevresel adaptasyon
 Yazılımı farklı bir işletim ortamına uyarlamak için bakım
 Bir sistemi, ilk uygulamasından farklı bir ortamda
(bilgisayar, işletim sistemi vb.) çalışacak şekilde
değiştirmek.
 İşlevsellik ekleme ve değiştirme
 Yeni gereksinimleri karşılamak
30/10/2014
için sistemi değiştirmek.
Chapter 9 Software Evolution 40
Maintenance effort distribution

30/10/2014 Chapter 9 Software Evolution 41

Maintenance costs

 Genellikle geliştirme maliyetlerinden daha fazladır

(uygulamaya bağlı olarak 2* ila 100* arası).
 Hem teknik hem de teknik olmayan faktörlerden etkilenir.
 Yazılım korundukça artar. Bakım, yazılım yapısını bozar,
bu nedenle daha fazla bakımı zorlaştırır.
 Eskiyen yazılımlar yüksek destek maliyetlerine sahip
olabilir (ör. eski diller, derleyiciler vb.).

30/10/2014 Chapter 9 Software Evolution 42

Maintenance costs

 Bakım sırasında bir sisteme yeni özellikler eklemek, aynı

özellikleri geliştirme sırasında eklemekten genellikle
daha pahalıdır.
 Yeni bir ekip sürdürülmekte olan programları anlamalıdır.
 Bakım ve geliştirmeyi birbirinden ayırmak, geliştirme
ekibinin bakımı yapılabilir yazılım yazması için herhangi
bir teşvik olmadığı anlamına gelir.
 Program bakım çalışması popüler değil
 Bakım personeli genellikle deneyimsizdir ve sınırlı alan
bilgisine sahiptir.
 Programlar eskidikçe yapıları bozulur ve değiştirilmeleri
zorlaşır
30/10/2014 Chapter 9 Software Evolution 43
Maintenance prediction

 Bakım tahmini, sistemin hangi bölümlerinin sorunlara yol

açabileceğini ve yüksek bakım maliyetlerine sahip
olabileceğini değerlendirmekle ilgilidir.
 Değişiklik kabulü, değişiklikten etkilenen bileşenlerin
sürdürülebilirliğine bağlıdır;
 Değişiklikleri uygulamak, sistemi bozar ve
sürdürülebilirliğini azaltır;
 Bakım maliyetleri değişiklik sayısına, değişiklik
maliyetleri ise sürdürülebilirliğe bağlıdır.

30/10/2014 Chapter 9 Software Evolution 44

Maintenance prediction

30/10/2014 Chapter 9 Software Evolution 45

Change prediction

 Değişiklik sayısını tahmin etmek, bir sistem ile çevresi

arasındaki ilişkilerin anlaşılmasını ve anlaşılmasını
gerektirir.
 Sıkıca bağlı sistemler, ortam değiştiğinde değişiklik
gerektirir.
 Bu ilişkiyi etkileyen faktörler şunlardır:
 Sistem arayüzlerinin sayısı ve karmaşıklığı;
 Doğası gereği değişken sistem gereksinimlerinin sayısı;
 Sistemin kullanıldığı iş süreçleri.

30/10/2014 Chapter 9 Software Evolution 46

Complexity metrics

 Sürdürebilirlik tahminleri, sistem bileşenlerinin

karmaşıklığı değerlendirilerek yapılabilir.
 Çalışmalar, bakım çabalarının çoğunun nispeten az
sayıda sistem bileşenine harcandığını göstermiştir.
 Karmaşıklık bağlıdır
 Kontrol yapılarının karmaşıklığı;
 veri yapılarının karmaşıklığı;
 Nesne, yöntem (prosedür) ve modül boyutu.

30/10/2014 Chapter 9 Software Evolution 47

Process metrics

 Sürdürebilirliği değerlendirmek için süreç ölçümleri

kullanılabilir
 Düzeltici bakım taleplerinin sayısı;
 Etki analizi için gereken ortalama süre;
 Bir değişiklik talebini uygulamak için geçen ortalama
süre;
 Bekleyen değişiklik isteklerinin sayısı.
 Bunlardan herhangi biri veya tümü artıyorsa, bu
sürdürülebilirlikte bir düşüşe işaret edebilir.

30/10/2014 Chapter 9 Software Evolution 48

Software reengineering

 Eski bir sistemin işlevselliğini değiştirmeden kısmen veya

tamamen yeniden yapılandırılması veya yeniden
yazılması.
 Daha büyük bir sistemin tüm alt sistemlerinin olmasa da
bazılarının sık bakım gerektirdiği durumlarda geçerlidir.
 Yeniden yapılanma, bakımlarını kolaylaştırmak için çaba
eklemeyi içerir. Sistem yeniden yapılandırılabilir ve
yeniden belgelenebilir.

30/10/2014 Chapter 9 Software Evolution 49

Advantages of reengineering

 Azaltılmış risk
 Yeni yazılım geliştirmede yüksek risk vardır. Geliştirme
sorunları, personel sorunları ve şartname sorunları
olabilir.
 Düşük maliyet
 Yeniden yapılandırmanın maliyeti genellikle yeni yazılım
geliştirmenin maliyetlerinden önemli ölçüde daha azdır.

30/10/2014 Chapter 9 Software Evolution 50

The reengineering process

30/10/2014 Chapter 9 Software Evolution 51

Reengineering process activities

 Kaynak kodu çevirisi

 Kodu yeni bir dile dönüştürün.
 Tersine mühendislik
 Programı anlamak için analiz edin;
 Program yapısı iyileştirmesi
 Anlaşılabilirlik için otomatik olarak yeniden yapılandırın;
 Program modülerleştirme
 Program yapısını yeniden düzenleyin;
 Veri yeniden mühendisliği
 Sistem verilerini temizleyin
30/10/2014 ve Evolution
Chapter 9 Software yeniden yapılandırın. 52
Reengineering approaches

30/10/2014 Chapter 9 Software Evolution 53

Reengineering cost factors

 Yeniden yapılandırılacak yazılımın kalitesi.

 Yeniden yapılandırma için araç desteği mevcuttur.
 Gerekli olan veri dönüştürmenin kapsamı.
 Yeniden yapılanma için uzman personelin mevcudiyeti.
 Bu, artık yaygın olarak kullanılmayan teknolojiye dayalı
eski sistemlerde bir sorun olabilir.

30/10/2014 Chapter 9 Software Evolution 54

Refactoring

 Yeniden düzenleme, değişiklik yoluyla bozulmayı

yavaşlatmak için bir programda iyileştirmeler yapma
sürecidir.
 Yeniden düzenlemeyi, gelecekteki değişimin sorunlarını
azaltan "önleyici bakım" olarak düşünebilirsiniz.
 Yeniden düzenleme, yapısını iyileştirmek, karmaşıklığını
azaltmak veya anlaşılmasını kolaylaştırmak için bir
programı değiştirmeyi içerir.
 Bir programı yeniden düzenlediğinizde, işlevsellik
eklememeli, bunun yerine programı iyileştirmeye
odaklanmalısınız.
30/10/2014 Chapter 9 Software Evolution 55
Refactoring and reengineering

 Yeniden yapılanma, bir sistemin bakımı bir süre

yapıldıktan sonra gerçekleşir ve bakım maliyetleri artar.
Bakımı daha kolay olan yeni bir sistem oluşturmak için
eski bir sistemi işlemek ve yeniden tasarlamak için
otomatik araçlar kullanırsınız.
 Yeniden düzenleme, geliştirme ve evrim süreci boyunca
sürekli bir iyileştirme sürecidir. Bir sistemi sürdürmenin
maliyetlerini ve zorluklarını artıran yapı ve kod
bozulmasını önlemek amaçlanmaktadır.

30/10/2014 Chapter 9 Software Evolution 56

‘Bad smells’ in program code

 Yinelenen kod
 Aynı veya çok benzer kod, bir programın farklı yerlerinde
bulunabilir. Bu, gerektiğinde çağrılan tek bir yöntem veya
işlev olarak kaldırılabilir ve uygulanabilir.
 Uzun yöntemler
 Bir yöntem çok uzunsa, birkaç kısa yöntem olarak
yeniden tasarlanmalıdır.
 Anahtar (durum) ifadeleri
 Bunlar genellikle, anahtarın bir değerin türüne bağlı
olduğu çoğaltmayı içerir. Switch ifadeleri bir programın
etrafına dağılmış olabilir. Nesne yönelimli dillerde, aynı
şeyi elde etmek için genellikle
30/10/2014
polimorfizmi
Chapter 9 Software Evolution 57
‘Bad smells’ in program code

 Veri kümelenmesi
 Veri kümeleri, aynı veri öğeleri grubu (sınıflardaki alanlar,
yöntemlerdeki parametreler) bir programda birkaç yerde
yeniden ortaya çıktığında ortaya çıkar. Bunlar genellikle
tüm verileri kapsayan bir nesneyle değiştirilebilir.
 spekülatif genellik
 Bu, geliştiriciler gelecekte gerekli olması durumunda bir
programa genelliği dahil ettiğinde ortaya çıkar. Bu
genellikle basitçe kaldırılabilir.

30/10/2014 Chapter 9 Software Evolution 58

Key points

 Yazılım geliştirme ve evrim, sarmal bir model kullanılarak

temsil edilebilen entegre, yinelemeli bir süreç olarak
düşünülebilir.
 Özel sistemler için, yazılım bakım maliyetleri genellikle
yazılım geliştirme maliyetlerini aşar.
 Yazılım evrimi süreci, değişiklik talepleri tarafından
yönlendirilir ve değişiklik etki analizi, sürüm planlaması
ve değişiklik uygulamasını içerir.
 Eski sistemler, bir işletme için faydalı olmaya devam
eden, eski yazılım ve donanım teknolojileri kullanılarak
geliştirilen eski yazılım sistemleridir.
30/10/2014 Chapter 9 Software Evolution 59
Key points

 Eski bir sistemi sürdürmek, modern teknolojiyi kullanarak

yeni bir sistem geliştirmekten genellikle daha ucuz ve
daha az risklidir.
 Bir sistemin değiştirilmesi, dönüştürülmesi veya
bakımının yapılması gerekip gerekmediğine karar
vermeye yardımcı olmak için eski bir sistemin iş değeri
ve uygulamanın kalitesi değerlendirilmelidir.
 Hata düzeltme, yazılımı yeni bir ortamda çalışacak
şekilde değiştirme ve yeni veya değiştirilmiş
gereksinimleri uygulama olmak üzere 3 tür yazılım
bakımı vardır.

30/10/2014 Chapter 9 Software Evolution 60

Key points

 Yazılım yeniden mühendisliği, anlaşılmasını ve

değiştirilmesini kolaylaştırmak için yazılımın yeniden
yapılandırılması ve yeniden belgelenmesi ile ilgilidir.
 İşlevselliği koruyan program değişiklikleri yapan yeniden
düzenleme, önleyici bakımın bir biçimidir.

30/10/2014 Chapter 9 Software Evolution 61