=Paper=
{{Paper
|id=Vol-1980/UYMS17_paper_53
|storemode=property
|title=IRIS Gomulu Yazilim Urun Hattinda Yazilim Ekosistemine
Gecis Calismalari (Studies on Transitioning from IRIS Software Product Line to Software Ecosystem)
|pdfUrl=https://ceur-ws.org/Vol-1980/UYMS17_paper_53.pdf
|volume=Vol-1980
|authors=Berkhan Deniz
|dblpUrl=https://dblp.org/rec/conf/uyms/Deniz17
}}
==IRIS Gomulu Yazilim Urun Hattinda Yazilim Ekosistemine
Gecis Calismalari (Studies on Transitioning from IRIS Software Product Line to Software Ecosystem)==
https://ceur-ws.org/Vol-1980/UYMS17_paper_53.pdf
IRIS Gömülü Yazılım Ürün Hattında Yazılım Ekosistemine
Geçiş Çalışmaları
Berkhan Deniz
Gömülü ve Gerçek Zamanlı Yazılım Tasarım Müdürlüğü, SST Sektör Bşk.
ASELSAN A.Ş.
berkhand@aselsan.com.tr
Özet. Yazılım ürün hatları, geliştirilen farklı ürünlerdeki ortak bileşenlerin ye-
niden kullanımını sağlayarak, yazılım geliştirme sürelerinin ve maliyetlerinin
azaltılmasında önemli rol oynamaktadır. Ancak, yazılım ürün hatlarının kapsa-
mı genişledikçe ve hitap ettiği pazar arttıkça başta tasarlandığından çok daha
karmaşık hale gelebilmektedir. Bu duruma bir çözüm olarak yazılım ürün hatla-
rının yazılım ekosistemlerine dönüştürülmesi önerilmektedir. Yazılım ekosis-
temlerinde ana yüklenici firma, yazılım geliştirdiği platformu firma dışından
geliştiricilere açmakta ve bu geliştiricilerin var olan platforma eklemeler yap-
masına izin vermektedir. Burada anlatacağımız çalışmada ise, Aselsan’da geliş-
tirilen bir gömülü yazılım ürün hattının (IRIS), altyüklenici firmalar tarafından
kullanımı yoluyla, Aselsan’ın kendi ekosistemine geçişi yönünde yapılan çalış-
malar ve karşılaşılan zorluklar anlatılacaktır.
Anahtar Kelimeler: Gömülü yazılım geliştirme, Yazılım ekosistemi, Altyük-
lenici
Studies on transitioning from IRIS Software Product Line to
Software Ecosystem
Abstract. Software product lines (SPLs) play an important role in reducing
software development times and costs by ensuring the reuse of common com-
ponents in the different products being developed. However, as the scope of
SPLs and the market they address expand, they become increasingly more
complex than originally designed. As a solution to this situation, it is recom-
mended that software product lines be converted into software ecosystems
(SECOs). In software ecosystems, the leading company opens the SPL platform
to developers outside the company and allows developers to create extensions
to existing platform. In this paper we will describe the studies and difficulties
for the software ecosystem transition of an embedded software product line
(IRIS) developed by Aselsan after being used by subcontractors.
Keywords: Embedded software development, Software ecosystem, Subcon-
tractor
541
1 Giriş
Son yıllarda, Aselsan tarafından üretilen sistemlerin hem çeşitliliği hem de karma-
şıklığı oldukça artmıştır. Ancak bu duruma zıt bir şekilde sistemlerin geliştirme ve
teslimat süreleri her geçen gün azalmaktadır.
Bu gelişmelere paralel olarak, geliştirilen sistemleri yöneten gömülü sistem yazı-
lımları da her yeni projeyle birlikte daha da karmaşıklaşmakta ve de bu yazılımların
geliştirilmesi için ayrılan süreler azalmaktadır. Yazılımların geliştirilme süresini ve
maliyetini azaltmak için en etkili metotlardan birinin yeniden kullanımı artırmak ol-
duğu bilinmektedir. Yazılım ürün hatları geliştirilen farklı ürünlerdeki ortak bileşenle-
rin yeniden kullanımını sağlayarak, yazılım geliştirme sürelerinin ve maliyetlerinin
azaltılmasında önemli rol oynamaktadır. Ancak, yazılım ürün hatlarının kapsamı ge-
nişledikçe başta tasarlandığından çok daha karmaşık hale gelebilmektedir. Aynı za-
manda, yazılım ürün hattının sürdürülmesi ve gömülü sistemlere entegrasyonu için
ihtiyaç duyulan işçilik miktarı da artmaktadır.
Yazılım ürün hattının, onu geliştiren ana ekibin dışındaki kullanıcılara açılarak; ha-
rici geliştiriciler tarafından kullanılması ve genişletilmesi kavramı yazılım ekosistemi
olarak tanımlanmaktadır [1].
Burada anlatacağımız çalışmada, Aselsan’da geliştirilen IRIS gömülü yazılım ürün
hattının, altyüklenici firmaların kullanımına açılması ve iki farklı seviyede kullanımı
anlatılacaktır: IRIS ürün hattı için bileşen geliştirilmesi ve IRIS ürün hattının kulla-
nılmasıyla son ürün geliştirilmesi.
Çalışmanın geri kalanı su şekilde düzenlenmiştir: Bölüm 2’de yazılım ekosistemi
kavramı ile ilgili literatür bilgileri özetlenmiştir. Bölüm 3’te IRIS ekosisteminin alt-
yükleniciler tarafından kullanımı ve karşılaşılan zorluklar aktarılmıştır. Bölüm 4’te ise
sonuçlar ve gelecek için çalışma önerileri verilmiştir.
2 Literatür
Son yıllarda, araştırma-geliştirme ve inovasyon sürelerinin azalması ve bunun so-
nucunda yeni ürün ortaya çıkarmak için gerekli zamanların kısalması doğrultusunda,
yazılım ürün hatları (YÜH) ilk tasarımlarından uzaklaşmakta ve kapsamları genişle-
mektedir [2]. YÜH’lerde amaç, farklı ürünlerde yeniden kullanılabilir bileşenler kul-
lanarak ve hem platformda hem de bileşenlerde gerekli değişiklikleri yaparak, üretim
maliyetlerini azaltmaktır. Ancak, YÜH büyüklüğü ve kapsamı genişledikçe; yani
hattan çıkan ürün sayısı, ürün seviyesindeki gereksinimler, platformda ve bileşenlerde
farklılıklar arttıkça, YÜH karmaşıklığı artmakta; yönetimi ve sürdürmesi zorlaşmak-
tadır [4].
YÜH ekosistemi yaklaşımı, geniş kapsamlı ürün hatları için bir çözüm olarak öne-
rilmektedir [5]. Yazılım ekosistemlerinde ana yüklenici firma, yazılım geliştirdiği
platformu firma dışından geliştiricilere açmakta ve bu geliştiricilerin var olan plat-
forma eklemeler yapmasına izin vermektedir. Bu yaklaşımın başarılı olabilmesi için,
bağımsız ürünler (bileşenler) geliştirecek farklı ekiplerin birbirinden bağımsız sürüm
542
çıkartabilme özgürlüğü olması gerekmektedir [5]. Bu da ancak, bileşenlerin birbirine
olan bağımlılığının en aza indirgenmesiyle sağlanmaktadır.
Yazılım geliştirdiği platformu dış geliştiricilere açmak isteyen firmalar için iki
farklı yaklaşım önerilmektedir [5]: Doğrudan ve dolaylı olarak. İkisi arasındaki fark,
firmanın dış geliştiricilere herhangi bir erişim kısıtı koyup koymamasıdır. Güvenlik,
gizlilik gibi sebeplerle paylaşılmaması gerekli bilgiler, doğrudan erişim hakkı bulun-
mayan firmalarla paylaşılmamaktadır.
2.1 Yazılım ekosistemlerindeki ana roller
Yazılım ekosistemi kavramı, yazılım endüstrisinde yeni fırsatlar ve beraberinde
zorluklar ortaya çıkarmaktadır: Yeni iş yapış şekilleri, açık inovasyon, birlikte geliş-
tirme gibi fırsatlara karşın; sahiplenme konusu, stratejik planlamalar, değişkenlik
yönetimi gibi zorluklar.
Bir yazılım ekosisteminde üç ana unsur bulunmaktadır: Bir temel geliştirici (ana
yüklenici), bir yazılım geliştirme platformu (ürün hattı) ve dış geliştiriciler. Çevre
geliştiriciler platformu kullanarak kendileri için değer yaratırlar [15].
Bosch’a göre bir yazılım ekosisteminde dört seviye geliştirici bulunabilir [5]:
1. İç geliştiriciler: Ana yüklenici firmada bulunan geliştiricilerdir.
2. Stratejik geliştiriciler: Uzun süreli ortaklık için seçilmiş firmalardır, ürün hattına
doğrudan erişimleri vardır.
3. Kısıtlanmış geliştiriciler: Ürün hattına doğrudan erişimleri olmayan dış geliştiri-
cilerdir.
4. Bağımsız geliştiriciler: Platformu kullanarak, ana yüklenici firmadan bağımsız
ürün geliştirirler.
Yukarıda belirtilen farklı rollerdeki geliştiriciler, ortak geliştirme platformuna çe-
şitli erişim noktaları ya da arayüzler üzerinden erişirler. Bir API veya SDK üzerinden,
ya da çeşitli seviyede veri paylaşımı ve teknolojinin bir kısmını açık kaynaklı hale
getirerek, geliştirme platformuna erişim sağlanabilir.
Ortak platformun yeniden kullanabilir hale getirilmesi ve çeşitli şekillerle dış eri-
şime açılmasının ardından, ekosistemin gelişebilmesi için dış geliştiricilerin cesaret-
lendirilmesi ve ekosistem içerisinde aktif olmaları sağlanmalıdır [3]. Ana firmada
bulunan geliştiriciler ekosistemin düzgün işlemesinden sorumludur [13]. Ortak plat-
formun kullanıma yönelik oturmuş, tahmin edilebilir arayüzler ve dokümanlar ortaya
koymak ana firmadaki geliştiricilerin sorumluluğundadır.
Hanssen tarafından yapılan alan çalışması sonucunda, ana yüklenici firma temelli
yazılım ekosistemleri için kavramsal bir model oluşturulmuştur [3]. Bu modele göre,
aşağıdaki teorik önermelerin yazılım ekosistemlerine uygun olduğu belirtilmiştir:
1. Yönetici rolünde bir firma olmalı ve çevresindeki diğer firmalar, arayüz ilişkileri
ile bu firmaya bağlantılı olmalıdır.
2. Yazılım ekosistemleri kendi kendisini denetlemelidir; hem ana firma hem çevre
firmalar birbirine uyum sağlamalıdır.
3. Yazılım ekosistemlerinin, hem müşterilerle, hem üçüncü taraf şirketlerle ve hatta
rakiplerle ağ tabanlı bir ilişkisi vardır.
543
4. Yazılım ekosistemlerinin düzgün işlemesi açısından web toplantıları benzeri
teknoloji kullanımları önem arz etmektedir.
5. Yazılım ürün hattı, yazılım ürünleri ve iş alanı tüm ekosistemin ortak değerleri-
dir. Ürün hattı gelişimi de tüm ekosistemin ortak sorumluluğu altındadır.
2.2 Yazılım ekosistemlerinin gelişmesi ve sürdürülmesi
Harici paydaşlarla etkileşim ve iletişim halinde olunması ürün hattının birlikte ya-
ratılmasını sağlamaktadır. Ürün hattının harici kullanıcıları da yazılım süreçlerine
dâhil olmalıdır. Aynı zamanda, uzun vadeli stratejiler ve planlar paylaşılarak, harici
geliştiriciler desteklenmelidir. Ana geliştirici firmanın temel görevi, iş alanının gelişti-
rilmesi ve daha fazla harici geliştiricinin ekosisteme dâhil olmasını sağlamak olmalı-
dır [3].
Harici geliştiricilerle sağlıklı iletişim kurmanın en iyi yolunun, herkese açık olacak
şekilde ortak platformla (ürün hattı) ilgili uzun dönem yol haritasının paylaşılması
olduğu belirtilmiştir [5]. Bu sayede, harici geliştiriciler kendi stratejik planlamalarını
ve geliştirme hedeflerini ortak platformla uyumlu olarak ortaya koyabileceklerdir.
Ancak, ekosistemlerdeki hızlı değişiklikler ve şirketler arasındaki organizasyonel
sınırlar, tahmin etmesi ve yönetmesi daha zor süreçlere neden olmaktadır [7]. Bu
yüzden, geleneksel tanımlanmış süreçler gözden geçirilmeli ve süreçlerin basitleşti-
rilmesi değerlendirilmelidir.
Ürün planları ve yol haritalarının paylaşılması yazılım ekosistemlerinin gelişmesi-
ne yol açacağı gibi, aynı zamanda harici partner şirketlerle planlama ve geliştirme
konularında işbirliği yapılması da şirketler-arası inovasyonu güçlendirecektir. Seich-
ter ve arkadaşlarına göre [10], uzun vadeli stratejik planların paylaşılması kadar, daha
kısa vadeli geliştirme faaliyetlerinin de (gereksinim mühendisliği süreci, sürüm çı-
kartma planları vb.) harici paydaşlarla paylaşılması ekosistemin gelişimine katkıda
bulunacaktır.
Bir ekosistemi belirleyen temel özellikler, kullanılan araçlar ve teknolojilerdir [13].
Yeni bir aktör ekosisteme dâhil olmak istediğinde, öncelikle bu özelliklere uyum
sağlaması gerekmektedir.
Yazılım ekosistemlerinin var olması ve gelişimi açısından diğer temel iki prensip
ise şeffaflık ve modüler sistem tasarımıdır [8]. Şeffaflık, tasarımla ilgili dokümanların
(kaynak kod, tasarım dokümanları vb.) ekosistem aktörlerinin erişimine açık olmasıy-
la; modüler sistem tasarımı ise, sistemin birbiriyle etkileşimi azaltılmış, bağımsız
yönetilebilir bileşenlere parçalanabilmesiyle ilgilidir. Ancak bu prensipler faydalı
oldukları gibi, bazı zorlukları da beraberinde getirmektedir. Şeffaflık, çok fazla bilgi-
nin organize edilmesini gerektirir. Bunun da yönetimi zordur. Aynı zamanda, tam
şeffaflık fikri hakların korunması, ticaret sırları ya da güvenlik gibi konulardan dolayı
her zaman tercih edilmeyebilir. Modüler sistem tasarımı da, yazılım sistemlerinin
değişken doğası nedeniyle her zaman mümkün olamamaktadır.
Ekosistemde şeffaflık ilkesinin uygulanması sayesinde, ekosistem aktörleri ekosis-
tem içerisindeki iş yapış şekillerini, kullanılan teknik altyapıları öğrenebilirler. Ayrı-
ca, bu sayede ekosistem üyeleri geliştirme aktivitelerinin durumu hakkına bilgi sahibi
olur ve ekosistem içerisinde koordinasyon sağlanmış olur. Ancak, ortaya çıkabilecek
544
doküman ve bilgi yoğunluğu sebebiyle, ekosistemin işlemez hale gelmesini engelle-
yecek ayıklama ve güvenlik, gizlilik gibi sebeplerle paylaşılmaması gerekli bilgiler
için filtreleme mekanizmalarının da kurulması gerekmektedir [9].
Modüler birimler sayesinde ekosistemde farklı aktörlerin birbirinden etkilenmeden
ürün geliştirmesi sağlanmaktadır; ancak kesişen özellikler söz konusu olduğunda bu
farklı aktörlerin birlikte çalışması gerekliliği gibi sorunların da dikkate alınması ge-
rekmektedir. Bu probleme Cataldo [8] tarafından getirilen çözüm önerisi şu şekilde-
dir: Arayüzlerin belirsizliği, karmaşıklığı ve ölçeklenebilirliği belirlenmeli ve bu bil-
giler tüm ekosistemin erişimine açılmalı. Böylelikle, ekosistemin modülerliği ve farklı
paydaşların beraber çalışabilirliği bir seviye daha artmış olacaktır.
2.3 Yazılım ekosistemlerde etkileşim, iletişim ve yönetim
Yazılım ekosistemi yönetimi, ekosistem aktörlerinin ve karşılıklı ilişkilerinin koor-
dinasyonu ve yönetimi olarak tanımlanmaktadır. Kalite kriterlerini ve yazılım stan-
dartlarını paylaşmak, uzun vadeli planları paylaşmak, ortak bileşen havuzu oluştur-
mak, kalite standartlarını uygulatmak gibi yöntemler yönetim tekniklerine örnek ola-
rak gösterilebilir [13]. Bu tekniklerin uygulanması ve geliştirilmesi ihtiyacının iki
sebebi bulunmaktadır [10]: Ekosisteme yeni bir aktör katıldığında birden fazla payda-
şı ilgilendiren arayüzleri, dokümanları tek kaynaktan öğrenebilmek, benzer şekilde
ekosistemden ayrılan olduğunda da olası bilgi kayıplarını engellemek.
Bir yazılım ekosisteminde sürüm tarihleri, ürün yol haritası, proje hedefleri gibi
temel ürün geliştirme kararları aktörler arası bilgi paylaşımı gerektirdiği için, karar
verme süreci daha zorlayıcıdır. Bir ekosistem yöneticisi, hem aktörler arası, hem de
başka sağlayıcılar, müşteriler vb. arasındaki iletişimin hızlı ve ucuz olmasını sağlama-
lıdır [14].
Brinkkemper [16] bir yazılım ekosisteminde yazılım operasyon bilgisi adını verdi-
ği dokümanlarla ekosistemdeki ilişkilerin yönetilebileceğinden bahsetmiştir. Yol hari-
taları, ürün takvimleri, yeni sürümde bulunacak bileşenler, süreçlerdeki güncellemeler
gibi konuların ekosistem aktörleriyle yazılım operasyon bilgisi yoluyla paylaşılabile-
ceği önerilmiştir.
Seichter [10] ise, yazılım ekosistemlerinde farklı ekiplerce birlikte çalışılması ge-
reken çok fazla ortak yapı olduğundan bahsetmiştir: Geliştirme araçları, mimari karar-
lar, ortak geliştirilecek bileşenler, ürünler, vb. Bu soruna getirdikleri öneri şu şekilde-
dir: Paylaşılan bileşenlerin, ürünlerin, dokümanların birer ekosistem aktörü olarak
kabul edilmesi önerilmiştir. Böylelikle, önemli kararların ve bilgilerin geliştiricilerde
değil, ilgili yapının kendisinde saklanması ve tüm ekosisteme açık olması sağlanmak-
tadır. Bu sayede, ekosistemden bir aktör ayrıldığında olabilecek bilgi kayıplarının da
önüne geçilmektedir.
545
3 IRIS Ekosistemi
IRIS, Aselsan’da üretilen sensör ve silah sistemleri için geliştirilmiş bileşen tabanlı
bir yazılım ürün hattıdır [6]. IRIS kullanılarak, birim tipleri ve konfigürasyonları bir-
birinden farklı onlarca gömülü sistem yazılımı sistematik olarak üretilebilmektedir.
Geliştirilen sistematik konfigürasyon yaklaşımı [6] ile hem yazılımın üzerinde ko-
şacağı platform ve işletim sistemi; hem de hangi tip birimlerin yaratılacağı belirlen-
mektedir. IRIS yazılım ürün hattında daha önce kullanılmamış bir birim ya da bileşen-
le çalışılması gerektiğinde ise, ihtiyaç duyulan yapıların ortak bileşen havuzuna ek-
lenmesi ile ürün hattı genişletilmektedir.
IRIS kullanılarak hazırlanan sistem yazılımı sayısı arttıkça, sıfırdan geliştirilip or-
tak bileşenlere eklenmesi gereken bileşen sayısı da artmış ve IRIS geliştiricileri bu
ihtiyaca zaman ve kaynak ayıramamaya başlamıştır. Bu soruna çözüm olarak altyük-
lenici kullanımının artırılması hedeflenmiş ve IRIS altyapılarının uygun olması saye-
sinde aynı anda birçok altyükleniciyle çalışmaya başlanmıştır.
Altyüklenicinin kullanımına yönelik yazılım ürün hattında bazı altyapıların sağ-
lanmış olması ve geliştirilecek bileşenlerin ve son ürünlerin kalitesine yönelik birta-
kım kuralların önceden tanımlanmış olması sayesinde, bu çalışmalar Aselsan’ın kendi
ekosistemine geçişi yönünde atılmış bir adım olarak değerlendirilebilir.
Bildirinin ilerleyen bölümlerinde, IRIS yazılım ürün hattının altyüklenici firmalar
tarafından iki farklı seviyede kullanımı anlatılacaktır: IRIS için bileşen ve IRIS kulla-
nılarak son ürün geliştirilmesi. Ardından, altyüklenici kullanımı konusunda yaşanan
sıkıntılar ve çözüm önerileri aktarılacaktır.
3.1 IRIS için bileşen geliştirilmesi
IRIS yazılım ürün hattı, arayüz fonksiyonları ortaklanmış birim bileşenlerinden
oluşmaktadır. Yapılan alan analiz çalışmaları ve birçok farklı bileşenin çeşitli proje-
lerde kullanılmış olması sayesinde, bileşen arayüz fonksiyonları belli bir olgunluk
seviyesine ulaşmış durumdadır.
IRIS bileşenlerinde, o bileşen tipine ait yapılan alan analizlerinde ortaya çıkan or-
tak ve muhtemel yetenekler “Özellikler” matrisinde toplanmıştır. Benzer şekilde,
farklı proje isterlerine göre değişkenlik gösteren yetenekler de “Konfigürasyon” mat-
risi ile çözülmüştür [6].
Aynı zamanda, ekip içerisinde aktif olarak kullanımda olan kodlama stilleri ve ya-
zılım isimlendirme kuralları rehberleri bulunmaktadır. Ayrıca, MISRA C++ kodlama
standardının da seçilmiş bir altkümesi kullanılmaktadır. Ekip tarafından geliştirilen
programlar sayesinde ise, bileşenlerin kodlama stilleri ve isimlendirme kuralları reh-
berlerine ve MISRA altkümesine uygunlukları otomatik olarak ölçülebilmektedir. Bu
ölçümler sonucunda bileşen kalite puanı hesaplanmaktadır [12]. Geliştirilen bileşenle-
rin belirli bir puan seviyesinin altında olması durumunda, IRIS ürün hattına eklenme-
sine izin verilmemektedir.
Bileşen arayüzleri ile birim ve proje seviyesindeki olası değişkenlikler yukarıda an-
latıldığı gibi tanımlanmış durumdadır. IRIS ürün hattına eklenecek bileşenlerin uyma-
sı gereken kurallar da belirlenmiş ve dokümante edilmiş durumdadır. Bileşen geliş-
546
tirme yöntemlerinin var olması; ihtiyaç duyulduğunda, Aselsan haricindeki geliştirici-
lere bileşen geliştirme işinin verilmesinin önünü açmıştır.
Bu sayede Aselsan dışındaki geliştiriciler de, IRIS yazılım ürün hattı için, bileşen
geliştirmeye başlamışlardır. Altyüklenicilerle paylaşılan dokümanlar için bkz. Şekil 1.
Bileşen geliştirme süreci boyunca, altyüklenicilerle haftalık düzenli toplantılar ya-
pılmaktadır. Arayüzlerde -eğer varsa- altyükleniciler tarafından tespit edilen eksiklik-
ler, bu toplantılarda değerlendirilmekte, gerekli görülürse arayüz fonksiyonları, konfi-
gürasyon ya da özellik matrisleri güncellenebilmektedir.
Dokümanlar
Arayüz fonksiyonları * Arayüz tanımları
* Rehberler
Konfigürasyon Özellikler
* Limit açıları = (-5, 80) * Özellik_1 = Yok
* Algoritma numarası = 5 * Özellik_2 = Var
Şekil 1. Bileşen geliştirme sürecinde paylaşılan dokümanlar
3.2 IRIS kullanılarak son ürün geliştirilmesi
Aselsan’da uzun yıllar boyunca edindiğimiz gömülü sistem yazılımı geliştirme de-
neyimimiz göstermiştir ki, gömülü yazılım bileşenlerinin sistem entegrasyonu için
harcanan iş gücü, çoğunlukla bileşenin geliştirilme süresi ile kıyaslanabilir boyutta
olmaktadır.
IRIS ekosistemi kapsamında birçok bileşen altyüklenici tarafından geliştirilse dahi,
bileşenlerin sistem entegrasyonunun çoğunlukla Aselsan’daki geliştiricilerle beraber
yapıldığı gözlenmiştir. Bu durumun nedenleri şu şekilde sıralanabilir: Aselsan dışın-
daki geliştiricilerin sistem tecrübesinin tek başına çalışmaya yeterli olmaması, sistem
entegrasyon aşamasının bileşen geliştirildikten çok sonra başlaması, güvenlik nedenli
kaygılar.
Bu sorunların önüne geçmek ve Aselsan dışındaki geliştiricilere daha fazla sorum-
luluk vermek amacıyla, örnek bir projede ürün sorumluluğunun altyüklenicilere ve-
rilmesi kararlaştırılmıştır. Böylelikle, IRIS ekosisteminin bir seviye daha genişlemesi
hedeflenmiştir.
Şekil 2’de IRIS ekosistemindeki son ürün mimarisi gösterilmiştir. Ticaret sırları ve
güvenlik gibi sebeplerle altyüklenicilerle IRIS ürün hattı kaynak kodu paylaşılmamış-
tır. Bunun yerine IRIS kütüphane olarak derlenmiş ve altyükleniciyle bu paylaşılmış-
tır. Altyükleniciyle paylaşılan diğer dokümanlar: Sistem kontrolcüsü dış arayüz fonk-
siyonları ve IRIS konfigürasyon bilgileridir.
547
IRIS Kütüphanesi
Projeye ULAK [11]
Özel
Sistem Kontrolcüsü
Adaptör
Yeni Birim Bileşenleri
bileşenler
ULAK [11]
Platformdan
Bağımsızlık Bileşeni
Şekil 2. IRIS ekosisteminde son ürün mimarisi
Altyükleniciden IRIS ekosisteminde son ürün geliştirme sürecinde beklenenler:
IRIS konfigürasyon altyapılarını kullanarak IRIS ürün hattını geliştirilecek proje ihti-
yaçlarına göre ayarlaması, eğer IRIS bileşenleri içerisinde bulunmayan bir bileşen
entegrasyonu gerekiyorsa bu bileşeni kodlaması, proje seviyesinde IRIS kontrolcü-
sünde bulunmayan bir yetenek gerekiyorsa da “projeye özel adaptör” geliştirip isterle-
ri gerçeklemesi şeklinde sıralanabilir.
Şekil 2’de gösterildiği gibi, ihtiyaç halinde geliştirilecek projeye özel adaptör, IRIS
sistem kontrolcüsüyle ULAK [11] adını verdiğimiz arayüz katmanı üzerinden haber-
leşmektedir. Benzer şekilde, yeni kodlanması gereken birim bileşenleri de ULAK
yetenekleri sayesinde IRIS sistem kontrolcüsüne dışarıdan bağlanabilecektir. Altyük-
lenici tarafından geliştirilebilecek birim bileşenleri de Bölüm 3.1’de anlatıldığı gibi
hazırlanacaktır ve yeterli olgunluğa ulaşmasının adından IRIS bileşen havuzuna ekle-
necektir.
Bu yöntemle, altyüklenicinin tüm sistem entegrasyon faaliyetlerini, IRIS yazılım
ekibinin işçiliğinin minimum harcanmasını sağlayacak şekilde, tek başına yürütmesi
hedeflenmektedir. IRIS ekibiyle yapılacak düzenli toplantılarla, IRIS ortak bileşenle-
rinde ya da arayüzlerde görülen değişiklik ihtiyaçları değerlendirilecek ve gerekli
görülen arayüzler güncellenecektir.
3.3 Altyüklenici kullanımı sırasında karşılaşılan zorluklar
Bu bölümde IRIS yazılım ürün hattının, yoğun altyüklenici kullanımıyla beraber
ekosisteme geçiş sürecinde karşılaşılan sıkıntılar özetlenecektir.
Öncelikle, karşılaşılan en temel problem “geliştirici seçimi” olmuştur. Aselsan’ın
güvenlik ve emniyet gereksinimleri gereği bu süreç beklenenden uzun sürmüştür.
IRIS ekosistemi dâhilinde birlikte çalışılan altyüklenici sayısı arttıkça, bu konunun
sorun olmaktan çıkacağı değerlendirilmektedir.
Ekosistem kapsamındaki bir diğer sorun da, altyüklenici firmaların yapacağı çalış-
malar için yapılan işçilik saati tahminlerinin, ekosistem kapsamındaki bu çalışmaların
548
ilk kez yapılacağı için öngörülemeyişidir. Bu konunun da ekosistem çalışmaları de-
vam ettikçe, ortadan kalkacağı düşünülmektedir.
Ekip olarak görülen bir diğer sıkıntı da, süreç sırasında kullanılan birçok özelliğin
dokümantasyonun eksik olmasıdır. Birçok bilginin dokümante edilmediği ekip dışı
geliştiricilerin bu altyapıları kullanması sayesinde fark edilmiş ve hızlı bir şekilde bu
eksiklerin kapatılması çalışmalarına başlanmıştır.
Yazılım süreçleri konusunda da güncelleme ihtiyacı duyulmuştur. Birçok yazılım
geliştirme adımı hem Aselsan tarafında, hem altyükleniciler tarafında yapılmaktadır:
Konfigürasyon yönetimi, gereksinim yönetimi vb. Bu gibi durumlar için, altyüklenici-
lerle ortak erişilen alanlarda tek elden bu işlerin yönetilmesi hedeflenmektedir.
4 Sonuç ve gelecek için planlar
Bu çalışmada Aselsan’ın askeri ürünler geliştirmesinden dolayı dış geliştiricilere
kapalı bir yazılım ürün hattı olan IRIS’in, çeşitli ve güvenli seviyelerde altyüklenicile-
re açılması yoluyla IRIS ürün hattının IRIS ekosistemine dönüştürülmesi çalışmaları
anlatılmıştır.
Bundan sonraki süreçte, altyüklenici çeşitliliğinin artırılması hedeflenmektedir.
IRIS ekosistemi dokümantasyonunun ve ürün geliştirme rehberlerinin iyileştirilmesi
ve bu sayede ekosistem kalitesinin yükseltilmesi amaçlanmaktadır.
Teşekkür
Saygıdeğer hocam Prof. Semih Bilgen’e yazılım ekosistemi kavramıyla tanıştırdığı
için teşekkürlerimi sunarım.
IRIS yazılım ürün hattını birlikte geliştirdiğimiz ve ekosisteme dönüştürmekte ol-
duğumuz, Aselsan Savunma ve Sistem Teknolojileri (SST) Sektör Başkanlığı Hava
Savunma Silah Sistemleri ve Görüntü İşleme (HSSS-Gİ) yazılım ekip arkadaşlarıma
özverili çalışmaları ve verdikleri destekten dolayı teşekkür ederim.
Kaynaklar
1. Bosch, Jan, ve Bosch-Sijtsema, Petra. "From integration to composition: On the impact of
software product lines, global development and ecosystems." Journal of Systems and
Software 83.1 (2010): 67-76.
2. Bosch, Jan. "The challenges of broadening the scope of software product families."
Communications of the ACM 49.12 (2006): 41-44.
3. Hanssen, Geir K. "A longitudinal case study of an emerging software ecosystem:
Implications for practice and theory." Journal of Systems and Software 85.7 (2012): 1455-
1466.
4. van Gurp, Jilles; Prehofer, Christian; ve Bosch, Jan. "Comparing practices for reuse in
integration‐oriented software product lines and large open source software projects."
Software: Practice and Experience 40.4 (2010): 285-312.
549
5. Bosch, Jan. "From software product lines to software ecosystems." Proceedings of the 13th
international software product line conference. Carnegie Mellon University, 2009.
6. Deniz, Berkhan; Öztas, Gökhan ve Çinar, Soner. "Askeri bir Gömülü Yazılımın Bileşen
Tabanlı Bir Mimari Kullanılarak Refaktör Edilmesi." UYMS. 2015.
7. Hanssen, Geir Kjetil. "Opening up software product line engineering." Proceedings of the
2010 ICSE Workshop on Product Line Approaches in Software Engineering. ACM, 2010.
8. Cataldo, Marcelo; Herbsleb, James D. Architecting in software ecosystems: interface
translucence as an enabler for scalable collaboration. In: Proceedings of the Fourth
European Conference on Software Architecture: Companion Volume. ACM, 2010. p. 65-72.
9. Bosch, Jan. "Architecture challenges for software ecosystems." Proceedings of the Fourth
European Conference on Software Architecture: Companion Volume. ACM, 2010.
10. Seichter, Dominik, et al. "Knowledge management in software ecosystems: software
artefacts as first-class citizens." Proceedings of the Fourth European Conference on
Software Architecture: Companion Volume. ACM, 2010.
11. Karasoy, Burcu, ve Çinar, Soner. "Dağıtık Sistemler için Haberleşme Otomasyon Ara
Katmanı: ULAK." UYMS. 2014.
12. Deniz, Berkhan, ve Çinar, Soner. "Bileşen Kalitesi Ölçümünde Statik Kod Analizi
Yaklaşımı." UYMS. 2014.
13. Jansen, Slinger; Brinkkemper, Sjaak; Finkelstein, Anthony; ",Business network
management as a survival strategy: A tale of two software ecosystems,"Proccedings of the
1st International Workshop on Software Ecosystems, CEUR-WS",34-48,2009.
14. Boucharas, Vasilis; Jansen, Slinger; ve Brinkkemper, Sjaak. "Formalizing software
ecosystem modeling." Proceedings of the 1st international workshop on Open component
ecosystems. ACM, 2009.
15. van den Berk, Ivo; Jansen, Slinger; ve Luinenburg, Lútzen. "Software ecosystems: a
software ecosystem strategy assessment model." Proceedings of the Fourth European
Conference on Software Architecture: Companion Volume. ACM, 2010.
16. van der Schuur, Henk; Jansen, Slinger; ve Brinkkemper, Sjaak. "The power of propagation:
on the role of software operation knowledge within software ecosystems." Proceedings of
the International Conference on Management of Emergent Digital EcoSystems. ACM, 2011.
550