Yazılım Konfigürasyon Yönetimi Örüntüleri Arasında Otomatik Geçiş

Yaz m Konfigürasyon Yönetimi Örüntüleri Aras nda Otomatik
Geçi
Automatic Transition Between Software Configuration Management
Patterns
Fatma Gül ah Kandemir
Yaz m Test ve Yönetim Birimi
ASELSAN MGEO, Ankara
kandemir@mgeo.aselsan.com.tr
Özet
Bu bildirinin amac irketlerin yaz m konfigürasyon
yönetimi uzmanlar n kar la
bir problemi
anlat p, çözüm önerisi sunmakt r. Ayn anda birden
fazla ya da art arda birbiri ile alakal proje yöneten
irketlerin de en proje ili kilerine göre yaz m
geli tirme
yönetim
yap lar
de tirmesi
gerekmektedir. Yaz m konfigürasyon yönetimi de
de en yönetim yap na göre de melidir. Amac z
var olan yaz m yönetim yap lar na uyarlanm
konfigürasyon yönetimi örüntüleri aras ndaki geçi leri,
kullan lan konfigürasyon yönetimi arac üzerinde elle
yapmak yerine otomatikle tirmektir.
Abstract
This paper’s aim is to address a problem which is
commonly
faced
by
software
configuration
management specialists of the companies. Companies
developing multiple projects at a time or one after
another, usually need to change their software
governance structures according to the changing
interactions between ongoing projects. Since software
configuration management is one of the most
important activities done in software governance,
transition between management patterns must be
handled carefully and efficiently. Our proposal is to do
the transition among configuration management
patterns automatically using a configuration
management tool.
1. Giri
Yaz m geli tirme süreci birçok önemli aktivitenin
koordine edilmesini gerektirir ve bu sebeple yaz m
geli tirme yönetiminin projelere uygun bir ekilde
titizlikle yap lmas
gerekmektedir.
Yaz m
konfigürasyon yönetimi de bu önemli aktivitelerden
biridir ve uygun yaz m geli tirme yönetim yap yla
çal ld nda verimli sonuçlar al nmas
sa lar.
Yaz m geli tirme yönetim yap
ile e lenmi bir
konfigürasyon yönetimi sistemi, de
yap na da adapte olmal r.
en yönetim
1.1. Yaz m Geli tirme Yönetimi Yap lar
Yaz m ürünleri geli tirilen irketlerde i gücünün
verimli bir ekilde kullan lmas amac yla projelerin
öngörülen gidi atlar na göre yaz m geli tirme yönetim
yap lar
kullan lmaktad r. Bu yönetim yap lar
TCE(Transaction Cost Economics Maliyet
Ekonomisi) konusu alt nda daha ayr nt bir biçimde
lenmi tir[1]. Yaz m Mühendisli i i lemlerinin
yürütülmesi için TCE bak aç uyarland nda ortaya
3 ana yaz m geli tirme yönetim yap
yakla
km r[2].
Bunlar
s ras yla;
yukar dan
ya(planl ), tabandan tepeye(uyarlamal ) ve yaz m
yeniden kullan (piyasa) yönetim yakla mlar r.
Yukar dan a
ya ayr m, bir projenin nas l
yap laca önceden tahmin ediliyorsa yani projenin alt
birimlerini nelerin olu turaca ve bu birimlere nas l
ayr
laca
biliniyorsa uygulanan, uygulan rsa
verimli olan bir proje yönetim eklidir.
Tabandan tepeye in a, alt birimlerin projenin tasar m
sürecinde tam olarak belirlenemedi i durumlarda
uygulanan ve de ime kar toleransl olan bir proje
yönetim eklidir. E er yap lacak projenin nas l
geli tirilece i konusunda deneyim yoksa ve daha çok
deneme-yan lma yöntemi ile geli tirme devam
edecekse, tasar m a amas nda belirlenen alt birimler ya
da bile enler projenin gidi at na göre de ebilir. Böyle
durumlarda tabandan-tepeye in a yönetim
ekli
uygundur.
Yaz m yeniden kullan
ise yeniden kullan lacak alt
birimlerin bir k sm ya da hepsi haz r bir ekilde
bulundu u zaman veya daha önce yürütülmü bir
projeden tedarik edilebilece i zaman rahatça
uygulanabilecek bir yönetim eklidir. Yaz m yeniden
kullan
i lemlerin maliyetlerini oldukça dü ürür.
1.2. Yaz m Konfigürasyon Yönetimi Örüntüleri
Yaz m geli tirme yönetim yap lar n uygulama
ba ar , her türlü yaz m i leminin/aktivitesinin
verimli bir ekilde yap lmas için yaz m geli tirme
araçlar n projeye uygun bir ekilde kullan lmas ile
do rudan ilgilidir. Yaz m konfigürasyon yönetimi de
yaz m geli tirme sürecinin önemli aktivitelerinden
biridir. Yaz m konfigürasyon yönetimi iki önemli
amaca hizmet eder: Biri yaz m geli tirme süresince
geli tiricilerin birbirleri ile kod entegrasyonunu
sa lamak di eri de yaz m ürününde yap lan
de ikliklerin kontrol mekanizmas
sa lamak[2].
Yaz m konfigürasyon yönetimi do ru strateji ile
uyguland nda projelerde i lem verimlili ini ciddi bir
ekilde artt rmaktad r. [2]’de hangi konfigürasyon
yönetimi örüntüsünün hangi yaz m geli tirme
yönetimi yap
ile ili kilendirilebilece i üzerine bir
çal ma sunulmu tur. Yukar da bahsedilen 3 yönetim
yap için 3 de ik konfigürasyon örüntüsü üzerinde
durulmu tur. Bu örüntüler s ras yla: Tek-dizi, ana-dizi
ve üretici-tüketici örüntüleridir.
Tek-dizi örüntüsü bir tane projenin tek bir dal(branch)
üzerinde her bir yaz m geli tiricisinin ayr geli tirme
dallar n oldu u, bu sayede geli tiricilerin hem
birbirinden izole olarak çal
hem de istedikleri
zaman i lerini di er geli tiricilere teslim edip di er
geli tiricilerin yapt klar
alabildi i bir ortam sunar.
Uygulamas en basit olan örüntülerden biri oldu u ve
tek bir proje yönetiminde ortak kullan lan alt
birimlerin(bile enlerin) olmamas sebebiyle tabandan
tepeye in a yönetim ekli için uygun bir örüntü
durumundad r.
Ana-dizi örüntüsü birden fazla benzer projenin
geli tirilmesi s ras nda projelerin ortak alt birimlere
eri imlerinin kolay olmas
sa lamaktad r. Bu alt
birimler tek bir proje taraf ndan geli tirilip di erleri
taraf ndan sadece kullan yor olmak zorunda de ildir.
Aksine her proje ortak alt birimlerin geli tirilmesine
katk da bulunuyor olabilir. Böyle projelerde yap lan
de ikliklerin kar kl k ç karmamas için ana-dizi
örüntüsü kullan lmaktad r. Bu örüntü yukar danya yönetim ekli için uygun bir örüntüdür.
Üretici-tüketici örüntüsü ise sadece üretici projenin
ortak alt birimi/birimleri geli tirdi i, tüketici
projenin/projelerin ise sadece kullanma yetkisinin
oldu u bir yaz m konfigürasyon yönetim örüntüsüdür.
Böylelikle sadece bir projenin geli tiricileri ortak
birimlerde de iklik yapaca
için di er proje ile
aralar nda de iklik kar kl klar ç kmas engellenir.
Bu özellikleri ile yaz m yeniden kullan
yönetim
ekli ile birebir ili kilendirilebilen bir örüntüdür.
2. Araç Üzerinde Yaz m Konfigürasyon
Yönetimi Örüntülerinin Uygulanmas
ASELSAN MGEO grubu bünyesinde yaz m
konfigürasyon yönetimi arac olarak IBM Rational
ClearCase UCM(Unified Change Management) arac
kullan lmaktad r[5].
Giri
k sm nda
belirtilen
konfigürasyon örüntülerinin daha iyi anla lmas için
ClearCase UCM arac üzerinde örnek uygulan biçimi
bu k mda anlat lmaktad r. Öncesinde ClearCase UCM
arac n
bu
bildiride
de
kullanaca
z
terminolojisinden k saca bahsedelim.
VOB (Versioned Object Base): Konfigürasyon
birimlerinin sürümlerinin tutuldu u yaz m
havuzu
Proje VOB’u: Projelerin, bile enlerin ve
etiketlerin meta bilgilerinin tutuldu u proje
havuzu
Bile en (Component): Birbirileriyle anlamsal
olarak bütünle mi , versiyonlar
birlikte
tutulan, belirli bir amaca hizmet eden
konfigürasyon
birimleri
toplulu udur.
Etiketler bile enler üzerinde al r.
Etiket (Baseline): Bir bile enin
zamanlarda ald sürüm isimleri
belirli
UCM Projesi: Yaz m projesi
Dizgi (Stream): Entegrasyon ve geli tirme
dizgisi olmak üzere 2 tür kullan labilir.
Geli tiriciler için, kendilerine ait di er
geli tirenlerden izole edilmi kod geli tirme
ortam
Teslim etmek (Deliver): Geli tiricilerin
konfigürasyon
birimlerine
yapt klar
de iklikleri
ortak
havuza
teslim
etmesi/göndermesi
Çal ma alan
güncellemek (Rebase):
Geli tiricilerin kendi çal ma alanlar
belirli
etiketlerdeki bile enlere güncellemesi
[3]’te ClearCase arac n kulland
terminolojinin
genel
yaz m
konfigürasyon
yönetimi
terminolojisindeki e le tirmesi ayr nt
bir ekilde
verilmi tir.
2.1. Tek-Dizi Örüntüsü
Tek-dizi örüntüsü, di er projelerden ba ms z çal an
projelerde kullan ld
için ClearCase arac ndaki
uygulamas nda tek bir UCM projesi yarat lmas
yeterlidir. ekil 1’de tek-dizi örüntüsü uygulanan bir
projenin geli tirilmekte olan bir bile eninin de iklik
aç yap verilmi tir. ekildeki her bir daire bile enin
alm oldu u sürümleri belirtmektedir. K rm
oklar
entegrasyon dizgisine yap lan versiyon teslimlerini ya
da entegrasyon dizgisinden yap lan güncellemeleri
göstermektedir. Bu yap da yaz mc lar n yapt klar
lerin birle tirildi i bir entegrasyon dizgisi ve her
geli tiriciye ait geli tirme dizgisi mevcuttur.
Yaz mc lar konfigürasyon birimlerine yapt klar
de iklikleri entegrasyon dizgisine teslim ederek
birle tirirler.
Bu örüntü daha önce de bahsetti imiz gibi irketin ilk
kez tecrübe edece i proje türleri için, henüz di er
projelerle ortak kullan lmas dü ünülmeyen bile enlerin
geli tirilmesinin h zl bir ekilde ilerlemesini sa lar.
Geli tiricilerin çal malar
birle tirmesi, entegrasyon
dizgisine çal malar
teslim etmeleri ve daha sonra
güncellemeleri ile kolay bir ekilde mümkündür.
birden fazla projenin paralel
kullan lmas mümkün de ildir.
yürütülmesi
için
Ortak_VOB
Ortak_Bile en
Ana_Proje
Proje2
Proje1
1
Teslim
Güncelle
1
Güncelle
1
Teslim
2
Tek-Dizi Proje
2
2
1
Geli tirici1
2
ekil 2 Ana-dizi örüntüsü uygulanan 2 projenin ortak
kulland klar bile enin de iklik birle tirme yap
Teslim
3
1
Geli tirici2
Teslim
2
1
Güncelle
3
2
4
ekil 1 Tek-dizi örüntüsü uygulanan projenin
birle tirme ve geli tirme dizgilerinin teslim-güncelle
yap
2.2. Ana-Dizi Örüntüsü
Ana-dizi örüntüsü paralel yürütülen projelerin ortak
bile en kullanmas durumunda kullan r. Ortak bile en
üzerinde her bir projenin yapt
de ikliklerin
birbirleri ile kar mamas ve olas kar kl klar n
giderilmesi için harcanacak zaman n en aza indirilmesi
ancak ana-dizi örüntüsü ile sa lan r. Tek-dizi örüntüsü
sadece tek bir projenin konfigürasyonu sa lad
için
ekil 2’de görüldü ü üzere iki proje taraf ndan
geli tirilmekte olan Ortak_Bile en’in konfigürasyon
birimlerine de ikli i do rudan yapan tek proje Anadizi projesi olan Ana_Proje’dir. Proje1 ve Proje2’nin
Ortak_Bile en’e
do rudan
müdahale
etmesi
de ikliklerin birle tirilmesini çok kar
r ve
de ikliklerin kontrolünü çok zorla
rd . Bu sebeple,
her bir proje yapt
de iklikleri önce Ana_Proje’ye
gönderiyor, de iklikler orada birle tiriliyor, daha
sonra da di er proje bile enin son halini Ana_Proje’den
al yor.
2.3. Üretici-Tüketici Örüntüsü
Üretici-tüketici örüntüsünde ortak kullan lan bile en
sadece onun üretici projesi taraf ndan geli tirilip di er
projeler taraf ndan kullan ld
için, Ana-dizi
örüntüsünde oldu u gibi tepede ba ka bir projeye gerek
yoktur. Sadece kullan
olan projenin belirli
zamanlarda üretici olan projenin yapt de iklikleri
alabilmesi için entegrasyon dizgisini güncellemesi
gerekmektedir. Daha sonra tüketici projenin
geli tiricileri,
entegrasyon
dizgisinden
son
güncellemeleri alabilirler.
bile enlerin daha alt bile enlere ayr
lmas i lemidir.
Bir bile enin ba ka bile enlere ayr p ayr amayaca
veya hangi bile enlere ayr aca na karar vermek gözle
yap lacak kadar basit bir i lem de ildir. Bu i lemin baz
yaz m tasar na yard mc olabilecek araçlarla
yap lmas , ç kacak sonucun da güvenilirli ini art r.
kincisi ise, de en bile en yap na ve ortakl na göre
uygulanmakta olan yaz m konfigürasyon yönetimi
örüntüsünün de tirilme i lemidir. Bizim önerimiz bu
iki i lemin yaz m geli tirme ve yönetme araçlar ile
otomatik bir ekilde yap lmas sa lamakt r.
Üretici_Proje
1
2
Tüketici_Proje1
3
3.1. Yaz m Geli tirme Yönetim Yap lar Aras nda Geçi
4
Tüketici_Proje2
5
Yaz m yönetim yap lar
aras nda bir geçi
ya anmas n en önemli nedenlerinden biri bile en
yap lar n de ip yeniden kullan ma uygun hale
getirme amac r. Bir bile enin ise ba ka bile enlere
ayr p ayr mayaca
belirlemek çok kolay bir süreç
de ildir.
6
ekil 3 Üretici-Tüketici örüntüsünde tüketici
projelerin ortak bile ene tek yönlü eri imleri
ekil 3’te bu örüntünün projelerin entegrasyon dizgileri
üzerinden nas l uygulanabilece i sembolik olarak
gösterilmi tir.
3. Yaz m Geli tirme Yönetim Yap lar ve
Konfigürasyon Örüntüleri Aras ndaki Geçi
Birçok projeyi e zamanl ya da artarda yürüten
irketlerde daha önce de bahsedildi i gibi baz
bile enlerin ortak kullan lmas gerekmektedir. Ya da
dan-yukar ya in a ile yönetilmekte olan bir
projenin alt birimleri ekillenmeye ba lay p yeni
bile enlere ayr yor olabilir. Bu yeni bile enler veya var
olan bile enler de ba ka bir proje ile ortak yürütülmeye
ba layabilir. Bu durum irketin ihtiyac na ya da
projelerin durumlar na göre bir yaz m yönetim
yap ndan di er bir yaz m yönetim yap na geçi i
gerektirmektedir. Çünkü daha önce yürütülen projenin
di er bir proje ile paralel gitmek durumunda olmas , o
projenin yönetim yap
n de tirilmesine sebep olur.
Ayn ekilde, yaz m yönetim yap
n de mesi
konfigürasyon yönetimi örüntüsünün de de mesi
demektir. Çok da kolay olmayan bu geçi leri
gerçekle tirmek konfigürasyon yönetimi sorumlular na
aittir.
Biz bu bildiride, bir yönetim yap ndan di er yönetim
yap na geçi i 2 farkl taraftan ele al yoruz. Birincisi,
daha çok yaz m tasar
çat alt na giren, var olan
Bir bile en birbirlerine ba
birçok kod parças ndan
yani konfigürasyon biriminden olu maktad r. Bu
ba
klar n analiz edilerek bile enlerin nas l
ayr aca
belirlemek gerekmektedir. Ba ml k yap
matrisleri(BYM) (Dependency Structure MatrixDSM)[4] kod ba ml klar
analiz etmek için
kullan labilir.
Ba ml k yap matrisleri kullan larak bir yaz m
bile eninin kar k olan ba ml klar düzenlenebilir ve
daha önce fark edilmemi , kendi aralar nda
gruplanabilir olan alt-bile enler ortaya ç kabilir.
Kod A
Kod B
Kod C
Kod D
1 2 3
1 .
X
2
. X
3 X
.
4
4
X
X
.
Tablo 1 Basit bir BYM
Kod D
Kod A
Kod C
Kod B
1 2 3 4
1 .
2 X . X
3 X X .
4
X .
Tablo 2 Bölmeden sonra olu an
blok üçgen BYM
Kod D
Kod A-C
1 2 3
1 .
2 X .
Kod B
3
ancak otomatik geçi ini hedefledi imiz sisteminin
yapmas gerekenleri anlatmak için öncelikle ilk
projenin ClearCase’de nas l tutuldu unu görelim.
X .
Tablo 3 Alt üçgen matris
BYM basit bit kom uluk matrisidir ve amaç bu matrisi
alt üçgen matris haline getirerek kodlar n bile en
parçalar n birbirine ba ml
en düzenli hale
getirmektir. Bu amaç için geli tirilmi
bölme
algoritmalar ve yaz m araçlar bulunmaktad r. Lattix
LDM bu araçlardan bir tanesidir[6]. Tablo 1 BYM’nin
basit bir örne ini göstermektedir. Tabloda X ile
gösterilen hücreler kodlar n birbirlerine ba ml
göstermektedir. Örne in Tablo 1’ in ilk sat , A
kodunun C ve D kodlar na ba ml
bulundu unu
göstermektedir. Tablo 2 ise ilk matrise bölme
algoritmas uyguland ktan sonra ortaya ç kan blok
haline getirilmi üçgen matrisi göstermektedir. Bölme
algoritmas , BYM’deki birbirine ba ml kodlar n grup
haline
getirilerek
kodlar
aras ndaki
kar k
ba ml klar n çözümlenmesini sa lar. Kod A ve
C’nin bir araya getirilmesinden olu an ve istenen
düzeye getirilen alt üçgen matris ise Tablo 3’te
verilmi tir[4].
Böylece BYM kullan larak, tabandan tepeye yönetim
yap
ile yönetilen projenin kulland
bir bile enin
ba ka bir proje ile ortak kullan labilecek ba ka
bile enlere dönü türülmesi i lemi gerçekle tirilebilir.
Tabandan-tepeye yönetim yap ndan yukar danya yönetim yap na geçilebilece i gibi yeniden
kullan m yönetim yap na da geçi te de bile enler bu
ekilde olu turulabilir.
3.2. Yaz m
Konfigürasyon
Aras nda Geçi
Yönetimi
ekil 4’te ilk sistemin ClearCase arac ndaki yap
gösterilmi tir. Önemli olan noktalar s ras ile:
1. Proje1_PVOB; Proje1’in tutuldu u Proje
VOB’udur.
2.
Proje1_VOB; Bile en1 ve Bile en2’nin
tutuldu u VOB’dur.
3.
Admin_PVOB;
Proje1_PVOB
ve
Proje1_VOB’un yöneticili ini yapan proje
VOB’udur.
4.
Bile en1 ve Bile en2; Proje1 taraf ndan
geli tirilmekte olan bile enlerdir.
Admin_PVOB
Proje1_PVOB
Proje1_VOB
Bile en1
Örüntüleri
Projenin ya da projelerin yeni yönetim yap
n
belirlenmesinin ard ndan hangi konfigürasyon yönetimi
örüntüsünün uygulanmas gerekti i bellidir. Önemli
olan var olan örüntüden di er örüntüye geçi te
gereksinimlerin ne oldu u ve bu gereksinimlerin nas l
kar lanabilece idir. Daha önce de belirtti imiz gibi
Aselsan MGEO grubu bünyesinde konfigürasyon
yönetimi arac olarak IBM Rational ClearCase arac
kulland
z için hedefledi imiz otomatik geçi
sisteminin de bu araç üzerinde yap lmas
istiyoruz.
Bunu da arac n kullan ya sa lad
cleartool ad
verilen komut sat betikleri(command line scripts) ile
ba araca
dü ünüyoruz.
Tabandan tepeye in a ile yönetilmekte olan projenin bir
bile eninin yeni ba layacak olan bir proje ile e zamanl
geli tirilece i senaryosunu ele alal m. Basit olmas
aç ndan da bile enin alt bile enlere ayr mayaca
varsayal m. Tabandan tepeye in adan yukar dan
ya ayr ma geçi te, normalde el ile yapt
z
Bile en2
Proje1
ekil 4 lk projenin ClearCase arac ndaki yap
Bile en1 ikinci projede de ortak olarak kullan lmaya
ba lad
zaman ana-dizi örüntüsüne geçi ten sonra
olu mas gereken ClearCase yap
ekil 5’teki gibidir.
ClearCase’de bu yap kurmak için s ras ile:
1.
Ana-dizi projesi olan Ana_Proje’si için
öncelikle Ana_PVOB’un yarat lmas
2.
Bundan
sonra
ortak kullan lmaya
ba layacak
Bile en1’in
tutulaca
Ana_VOB’un yarat lmas
3.
kinci proje
yarat lmas
için
Proje2_PVOB’un
4.
Proje2’nin sadece kendi geli tirece i
Bile en3’ün tutulaca
Proje2_VOB’un
yarat lmas
bir araç, insandan kaynaklanabilecek geri dönülemez
hatalar n engellenmesini sa lar.
4. Sonuç
5.
Ana_Proje’nin yarat lmas
6.
Proje2’nin yarat lmas
7.
Bile en1’in
Proje1_VOB’dan
silinip
Ana_VOB’a kopyalanmas
Yeni
Bile en1’in
Ana_Proje’nin,
Proje1’in ve Proje2’nin konfigürasyonuna
eklenmesi
8.
9.
Bile en3’ün yarat lmas
konfigürasyonuna
gerekmektedir.
ve Proje2’nin
eklenmesi
Biz bu ad mlar n el ile yap lmas yerine, ClearCase
arac na tasarlad
z betiklerle müdahale edip
otomatik hale getirmek istiyoruz. Bu ad mlar el ile
takip etmesi vakit ald
gibi, baz gerçekle mesini
istemedi imiz sonuçlar da kabullenmek zorunda
kal yoruz. Örne in 7. ve 8. ad mlardaki, eski projedeki
Bile en1’in bir VOB’dan di er VOB’a aktar lmas
asl nda istemedi imiz bir durum olan versiyon
geçmi ini kaybetmemize neden oluyor. Bir bile eni bir
VOB’dan silip di erine el ile kopyalamak u an
ClearCase’de geçmi in kaybedilmesine sebep olurken,
araca betiklerle müdahale edersek bu kayb ortadan
kald rabilme ihtimalimiz olu ur.
Admin_PVOB
Proje1_PVOB Proje1_VOB
Ana_PVOB
Ana_VOB
Proje2_PVOB Proje2_VOB
Bile en
Yeni_Bile en1
Bile en3
Proje1
Ana_Proj
Proje2
ekil 5 Yeni eklenen proje ile ana-dizi örüntüsünün
yap
Ayr ca otomatik geçi ile insan hatalar n en aza
inece ini dü ünüyoruz. Güvenilirli i test edilmi olan
irketlerin yürütülmekte olan projelerine uygun
yönetim yap lar
seçmek ve uygulamak al nacak
verimi büyük ölçüde etkilemektedir. Uygun yaz m
konfigürasyon yönetimi örüntüsünü kullanmak ise
yaz m yönetimi aktivitelerinin en önemlilerinden
biridir. Projeler de tikçe yaz m yönetim yap
n
de mesi ve ayn ekilde konfigürasyon yönetimi
örüntüsünün de mesi gerekti i için bu de imlerin
otomatik olarak gerçekle mesi hem vakit hem de
geçi in güvenilirli i aç ndan çok faydal olacakt r.
Otomatik geçi önerimizi uygulamak için çal malara
ba lam durumday z ve uyguland
takdirde çok
verim alaca
z dü ünüyoruz. Aselsan MGEO grubu
bünyesinde konfigürasyon yönetimi arac olarak IBM
Rational ClearCase kulland
z için önceli imiz bu
araç üzerinde uygulamam
geli tirmek, ancak
gerekirse u an dünyada kullan lmakta olan di er
yaz m konfigürasyon yönetimi araçlar üzerinde de
çal maya ba layabiliriz.
5. Kaynaklar
[1] Erbas, C., and Erbas, B.C. 2009. Software Development
under Bounded Rationality and Opportunism. Software
Development Governance Workshop (Vancouver,
Canada, May 17, 2009). ICSE’09.
[2] Pala Er, N., Erba , C. 2010. Aligning Software
Configuration Management with Governance Structures.
Workshop on Software Development Governance.
ICSE’2010
[3] Berczuk, S. P., and Appleton, B. 2002. Software
Configuration
Management
Patterns:
Effective
Teamwork, Practical Integration. Addison Wesley (Nov.
2002).
[4] Sangal, N., Jordan, E., Sinha, V., Jackson, D. 2005.
Using Dependency Models to Manage Complex
Software Architecture. OOPSLA’05
[5] IBM
Rational
ClearCase,
http://www01.ibm.com/software/awdtools/clearcase/index.html
[6] Lattix LDM, http://www.lattix.com/