<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>IRIS Gömülü Yazılım Ürün Hattında Yazılım Ekosistemine Geçiş Çalışmaları</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Berkhan Deniz</string-name>
          <email>berkhand@aselsan.com.tr</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Anahtar Kelimeler: Gömülü yazılım geliştirme</institution>
          ,
          <addr-line>Yazılım ekosistemi, Altyüklenici</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Gömülü ve Gerçek Zamanlı Yazılım Tasarım Müdürlüğü, SST Sektör Bşk. ASELSAN A.Ş</institution>
        </aff>
      </contrib-group>
      <fpage>541</fpage>
      <lpage>550</lpage>
      <abstract>
        <p>Software product lines (SPLs) play an important role in reducing software development times and costs by ensuring the reuse of common components 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 recommended 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.</p>
      </abstract>
      <kwd-group>
        <kwd>Embedded software development</kwd>
        <kwd>Software ecosystem</kwd>
        <kwd>Subcontractor</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>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.</p>
      <p>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
olduğu bilinmektedir. Yazılım ürün hatları geliştirilen farklı ürünlerdeki ortak
bileşenlerin 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ı
genişledikçe başta tasarlandığından çok daha karmaşık hale gelebilmektedir. Aynı
zamanda, 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.</p>
      <p>
        Yazılım ürün hattının, onu geliştiren ana ekibin dışındaki kullanıcılara açılarak;
harici geliştiriciler tarafından kullanılması ve genişletilmesi kavramı yazılım ekosistemi
olarak tanımlanmaktadır [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>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
kullanılmasıyla son ürün geliştirilmesi.</p>
      <p>Ç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
altyü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</p>
    </sec>
    <sec id="sec-2">
      <title>Literatür</title>
      <p>
        Son yıllarda, araştırma-geliştirme ve inovasyon sürelerinin azalması ve bunun
sonucunda 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şlemektedir [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. YÜH’lerde amaç, farklı ürünlerde yeniden kullanılabilir bileşenler
kullanarak 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şmaktadır [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
      <p>
        YÜH ekosistemi yaklaşımı, geniş kapsamlı ürün hatları için bir çözüm olarak
önerilmektedir [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. 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
platforma 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
çıkartabilme özgürlüğü olması gerekmektedir [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. Bu da ancak, bileşenlerin birbirine
olan bağımlılığının en aza indirgenmesiyle sağlanmaktadır.
      </p>
      <p>
        Yazılım geliştirdiği platformu dış geliştiricilere açmak isteyen firmalar için iki
farklı yaklaşım önerilmektedir [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]: 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ı
bulunmayan firmalarla paylaşılmamaktadır.
2.1
      </p>
      <sec id="sec-2-1">
        <title>Yazılım ekosistemlerindeki ana roller</title>
        <p>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.</p>
        <p>
          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 [
          <xref ref-type="bibr" rid="ref15">15</xref>
          ].
        </p>
        <p>
          Bosch’a göre bir yazılım ekosisteminde dört seviye geliştirici bulunabilir [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ]:
1. İç geliştiriciler: Ana yüklenici firmada bulunan geliştiricilerdir.
        </p>
        <p>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.</p>
        <p>3. Kısıtlanmış geliştiriciler: Ürün hattına doğrudan erişimleri olmayan dış
geliştiricilerdir.</p>
        <p>4. Bağımsız geliştiriciler: Platformu kullanarak, ana yüklenici firmadan bağımsız
ürün geliştirirler.</p>
        <p>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.</p>
        <p>
          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
cesaretlendirilmesi ve ekosistem içerisinde aktif olmaları sağlanmalıdır [
          <xref ref-type="bibr" rid="ref3">3</xref>
          ]. Ana firmada
bulunan geliştiriciler ekosistemin düzgün işlemesinden sorumludur [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ]. Ortak
platformun kullanıma yönelik oturmuş, tahmin edilebilir arayüzler ve dokümanlar ortaya
koymak ana firmadaki geliştiricilerin sorumluluğundadır.
        </p>
        <p>
          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 [
          <xref ref-type="bibr" rid="ref3">3</xref>
          ]. 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.
        </p>
        <p>2. Yazılım ekosistemleri kendi kendisini denetlemelidir; hem ana firma hem çevre
firmalar birbirine uyum sağlamalıdır.</p>
        <p>3. Yazılım ekosistemlerinin, hem müşterilerle, hem üçüncü taraf şirketlerle ve hatta
rakiplerle ağ tabanlı bir ilişkisi vardır.
4. Yazılım ekosistemlerinin düzgün işlemesi açısından web toplantıları benzeri
teknoloji kullanımları önem arz etmektedir.</p>
        <p>5. Yazılım ürün hattı, yazılım ürünleri ve iş alanı tüm ekosistemin ortak
değerleridir. Ürün hattı gelişimi de tüm ekosistemin ortak sorumluluğu altındadır.
2.2</p>
      </sec>
      <sec id="sec-2-2">
        <title>Yazılım ekosistemlerinin gelişmesi ve sürdürülmesi</title>
        <p>
          Harici paydaşlarla etkileşim ve iletişim halinde olunması ürün hattının birlikte
yaratı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ştirilmesi ve daha fazla harici geliştiricinin ekosisteme dâhil olmasını sağlamak
olmalıdır [
          <xref ref-type="bibr" rid="ref3">3</xref>
          ].
        </p>
        <p>
          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 [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ]. 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 [
          <xref ref-type="bibr" rid="ref7">7</xref>
          ]. Bu
yüzden, geleneksel tanımlanmış süreçler gözden geçirilmeli ve süreçlerin
basitleştirilmesi değerlendirilmelidir.
        </p>
        <p>
          Ürün planları ve yol haritalarının paylaşılması yazılım ekosistemlerinin
gelişmesine 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.
Seichter ve arkadaşlarına göre [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ], 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.
        </p>
        <p>
          Bir ekosistemi belirleyen temel özellikler, kullanılan araçlar ve teknolojilerdir [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ].
Yeni bir aktör ekosisteme dâhil olmak istediğinde, öncelikle bu özelliklere uyum
sağlaması gerekmektedir.
        </p>
        <p>
          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 [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ]. Şeffaflık, tasarımla ilgili dokümanların
(kaynak kod, tasarım dokümanları vb.) ekosistem aktörlerinin erişimine açık
olmasıyla; 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
bilginin 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.
        </p>
        <p>
          Ekosistemde şeffaflık ilkesinin uygulanması sayesinde, ekosistem aktörleri
ekosistem 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
doküman ve bilgi yoğunluğu sebebiyle, ekosistemin işlemez hale gelmesini
engelleyecek ayıklama ve güvenlik, gizlilik gibi sebeplerle paylaşılmaması gerekli bilgiler
için filtreleme mekanizmalarının da kurulması gerekmektedir [
          <xref ref-type="bibr" rid="ref9">9</xref>
          ].
        </p>
        <p>
          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ı
gerekmektedir. Bu probleme Cataldo [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ] tarafından getirilen çözüm önerisi şu
şekildedir: Arayüzlerin belirsizliği, karmaşıklığı ve ölçeklenebilirliği belirlenmeli ve bu
bilgiler 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
        </p>
      </sec>
      <sec id="sec-2-3">
        <title>Yazılım ekosistemlerde etkileşim, iletişim ve yönetim</title>
        <p>
          Yazılım ekosistemi yönetimi, ekosistem aktörlerinin ve karşılıklı ilişkilerinin
koordinasyonu ve yönetimi olarak tanımlanmaktadır. Kalite kriterlerini ve yazılım
standartlarını paylaşmak, uzun vadeli planları paylaşmak, ortak bileşen havuzu
oluşturmak, kalite standartlarını uygulatmak gibi yöntemler yönetim tekniklerine örnek
olarak gösterilebilir [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ]. Bu tekniklerin uygulanması ve geliştirilmesi ihtiyacının iki
sebebi bulunmaktadır [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ]: 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.
        </p>
        <p>
          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ğlamalıdır [
          <xref ref-type="bibr" rid="ref14">14</xref>
          ].
        </p>
        <p>
          Brinkkemper [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ] 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
haritaları, ü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şılabileceği önerilmiştir.
        </p>
        <p>
          Seichter [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ] ise, yazılım ekosistemlerinde farklı ekiplerce birlikte çalışılması
gereken çok fazla ortak yapı olduğundan bahsetmiştir: Geliştirme araçları, mimari
kararlar, ortak geliştirilecek bileşenler, ürünler, vb. Bu soruna getirdikleri öneri şu
şekildedir: 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ğlanmaktadır. Bu sayede, ekosistemden bir aktör ayrıldığında olabilecek bilgi kayıplarının da
önüne geçilmektedir.
        </p>
        <p>
          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 [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ]. IRIS kullanılarak, birim tipleri ve konfigürasyonları
birbirinden farklı onlarca gömülü sistem yazılımı sistematik olarak üretilebilmektedir.
        </p>
        <p>
          Geliştirilen sistematik konfigürasyon yaklaşımı [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ] ile hem yazılımın üzerinde
koşacağı platform ve işletim sistemi; hem de hangi tip birimlerin yaratılacağı
belirlenmektedir. IRIS yazılım ürün hattında daha önce kullanılmamış bir birim ya da
bileşenle çalışılması gerektiğinde ise, ihtiyaç duyulan yapıların ortak bileşen havuzuna
eklenmesi ile ürün hattı genişletilmektedir.
        </p>
        <p>IRIS kullanılarak hazırlanan sistem yazılımı sayısı arttıkça, sıfırdan geliştirilip
ortak 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üklenici kullanımının artırılması hedeflenmiş ve IRIS altyapılarının uygun olması
sayesinde aynı anda birçok altyükleniciyle çalışmaya başlanmıştır.</p>
        <p>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
birtakı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.</p>
        <p>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
kullanı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</p>
      </sec>
      <sec id="sec-2-4">
        <title>IRIS için bileşen geliştirilmesi</title>
        <p>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
projelerde kullanılmış olması sayesinde, bileşen arayüz fonksiyonları belli bir olgunluk
seviyesine ulaşmış durumdadır.</p>
        <p>
          IRIS bileşenlerinde, o bileşen tipine ait yapılan alan analizlerinde ortaya çıkan
ortak ve muhtemel yetenekler “Özellikler” matrisinde toplanmıştır. Benzer şekilde,
farklı proje isterlerine göre değişkenlik gösteren yetenekler de “Konfigürasyon”
matrisi ile çözülmüştür [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ].
        </p>
        <p>
          Aynı zamanda, ekip içerisinde aktif olarak kullanımda olan kodlama stilleri ve
yazı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ı
rehberlerine ve MISRA altkümesine uygunlukları otomatik olarak ölçülebilmektedir. Bu
ölçümler sonucunda bileşen kalite puanı hesaplanmaktadır [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ]. Geliştirilen
bileşenlerin belirli bir puan seviyesinin altında olması durumunda, IRIS ürün hattına
eklenmesine izin verilmemektedir.
        </p>
        <p>Bileşen arayüzleri ile birim ve proje seviyesindeki olası değişkenlikler yukarıda
anlatıldığı gibi tanımlanmış durumdadır. IRIS ürün hattına eklenecek bileşenlerin
uyması gereken kurallar da belirlenmiş ve dokümante edilmiş durumdadır. Bileşen
geliştirme yöntemlerinin var olması; ihtiyaç duyulduğunda, Aselsan haricindeki
geliştiricilere bileşen geliştirme işinin verilmesinin önünü açmıştır.</p>
        <p>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.</p>
        <p>Bileşen geliştirme süreci boyunca, altyüklenicilerle haftalık düzenli toplantılar
yapılmaktadır. Arayüzlerde -eğer varsa- altyükleniciler tarafından tespit edilen
eksiklikler, bu toplantılarda değerlendirilmekte, gerekli görülürse arayüz fonksiyonları,
konfigürasyon ya da özellik matrisleri güncellenebilmektedir.</p>
        <p>Arayüz fonksiyonları
Konfigürasyon
* Limit açıları = (-5, 80)
* Algoritma numarası = 5</p>
        <p>Dokümanlar
* Arayüz tanımları
* Rehberler
Özellikler
* Özellik_1 = Yok
* Özellik_2 = Var
Şekil 1. Bileşen geliştirme sürecinde paylaşılan dokümanlar
3.2</p>
      </sec>
      <sec id="sec-2-5">
        <title>IRIS kullanılarak son ürün geliştirilmesi</title>
        <p>Aselsan’da uzun yıllar boyunca edindiğimiz gömülü sistem yazılımı geliştirme
deneyimimiz 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.</p>
        <p>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ışındaki 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.</p>
        <p>Bu sorunların önüne geçmek ve Aselsan dışındaki geliştiricilere daha fazla
sorumluluk vermek amacıyla, örnek bir projede ürün sorumluluğunun altyüklenicilere
verilmesi kararlaştırılmıştır. Böylelikle, IRIS ekosisteminin bir seviye daha genişlemesi
hedeflenmiştir.</p>
        <p>Ş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
fonksiyonları ve IRIS konfigürasyon bilgileridir.</p>
        <p>Yeni
bileşenler</p>
        <p>Projeye</p>
        <p>Özel
Adaptör</p>
        <p>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
ihtiyaç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
isterleri gerçeklemesi şeklinde sıralanabilir.</p>
        <p>
          Şekil 2’de gösterildiği gibi, ihtiyaç halinde geliştirilecek projeye özel adaptör, IRIS
sistem kontrolcüsüyle ULAK [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ] adını verdiğimiz arayüz katmanı üzerinden
haberleşmektedir. Benzer şekilde, yeni kodlanması gereken birim bileşenleri de ULAK
yetenekleri sayesinde IRIS sistem kontrolcüsüne dışarıdan bağlanabilecektir.
Altyüklenici 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
eklenecektir.
        </p>
        <p>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şenlerinde ya da arayüzlerde görülen değişiklik ihtiyaçları değerlendirilecek ve gerekli
görülen arayüzler güncellenecektir.</p>
        <p>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.</p>
        <p>Ö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.</p>
        <p>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
ilk kez yapılacağı için öngörülemeyişidir. Bu konunun da ekosistem çalışmaları
devam ettikçe, ortadan kalkacağı düşünülmektedir.</p>
        <p>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.</p>
        <p>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üklenicilerle ortak erişilen alanlarda tek elden bu işlerin yönetilmesi hedeflenmektedir.
4</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Sonuç ve gelecek için planlar</title>
      <p>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üklenicilere açılması yoluyla IRIS ürün hattının IRIS ekosistemine dönüştürülmesi çalışmaları
anlatılmıştır.</p>
      <p>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.</p>
      <p>Teşekkür</p>
    </sec>
    <sec id="sec-4">
      <title>Kaynaklar</title>
      <p>Saygıdeğer hocam Prof. Semih Bilgen’e yazılım ekosistemi kavramıyla tanıştırdığı
için teşekkürlerimi sunarım.</p>
      <p>IRIS yazılım ürün hattını birlikte geliştirdiğimiz ve ekosisteme dönüştürmekte
olduğ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.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Bosch</surname>
          </string-name>
          , Jan, ve Bosch-Sijtsema,
          <article-title>Petra. "From integration to composition: On the impact of software product lines, global development and ecosystems</article-title>
          .
          <source>" Journal of Systems and Software 83.1</source>
          (
          <year>2010</year>
          ):
          <fpage>67</fpage>
          -
          <lpage>76</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Bosch</surname>
            ,
            <given-names>Jan. "</given-names>
          </string-name>
          <article-title>The challenges of broadening the scope of software product families."</article-title>
          <source>Communications of the ACM 49.12</source>
          (
          <year>2006</year>
          ):
          <fpage>41</fpage>
          -
          <lpage>44</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Hanssen</surname>
          </string-name>
          ,
          <string-name>
            <surname>Geir K</surname>
          </string-name>
          .
          <article-title>"A longitudinal case study of an emerging software ecosystem: Implications for practice and theory</article-title>
          .
          <source>" Journal of Systems and Software 85.7</source>
          (
          <year>2012</year>
          ):
          <fpage>1455</fpage>
          -
          <lpage>1466</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4. van Gurp, Jilles; Prehofer, Christian; ve Bosch, Jan.
          <article-title>"Comparing practices for reuse in integration‐oriented software product lines and large open source software projects</article-title>
          .
          <source>" Software: Practice and Experience 40.4</source>
          (
          <year>2010</year>
          ):
          <fpage>285</fpage>
          -
          <lpage>312</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Bosch</surname>
          </string-name>
          , Jan.
          <article-title>"From software product lines to software ecosystems." Proceedings of the 13th international software product line conference</article-title>
          . Carnegie Mellon University,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Deniz</surname>
          </string-name>
          , Berkhan; Öztas, Gökhan ve Çinar,
          <source>Soner. "Askeri bir Gömülü Yazılımın Bileşen Tabanlı Bir Mimari Kullanılarak Refaktör Edilmesi." UYMS</source>
          .
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Hanssen</surname>
            ,
            <given-names>Geir</given-names>
          </string-name>
          <string-name>
            <surname>Kjetil</surname>
          </string-name>
          .
          <article-title>"Opening up software product line engineering."</article-title>
          <source>Proceedings of the 2010 ICSE Workshop on Product Line Approaches in Software Engineering. ACM</source>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Cataldo</surname>
            , Marcelo; Herbsleb,
            <given-names>James D.</given-names>
          </string-name>
          <article-title>Architecting in software ecosystems: interface translucence as an enabler for scalable collaboration</article-title>
          .
          <source>In: Proceedings of the Fourth European Conference on Software Architecture: Companion Volume. ACM</source>
          ,
          <year>2010</year>
          . p.
          <fpage>65</fpage>
          -
          <lpage>72</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Bosch</surname>
          </string-name>
          , Jan.
          <article-title>"Architecture challenges for software ecosystems</article-title>
          .
          <source>" Proceedings of the Fourth European Conference on Software Architecture: Companion Volume. ACM</source>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Seichter</surname>
          </string-name>
          ,
          <string-name>
            <surname>Dominik</surname>
          </string-name>
          , et al.
          <article-title>"Knowledge management in software ecosystems: software artefacts as first-class citizens</article-title>
          .
          <source>" Proceedings of the Fourth European Conference on Software Architecture: Companion Volume. ACM</source>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Karasoy</surname>
          </string-name>
          , Burcu, ve Çinar,
          <source>Soner. "Dağıtık Sistemler için Haberleşme Otomasyon Ara Katmanı: ULAK." UYMS</source>
          .
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Deniz</surname>
          </string-name>
          , Berkhan, ve Çinar,
          <source>Soner. "Bileşen Kalitesi Ölçümünde Statik Kod Analizi Yaklaşımı." UYMS</source>
          .
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Jansen</surname>
          </string-name>
          , Slinger; Brinkkemper, Sjaak; Finkelstein,
          <article-title>Anthony; ",Business network management as a survival strategy: A tale of two software ecosystems,"</article-title>
          <source>Proccedings of the 1st International Workshop on Software Ecosystems, CEUR-WS"</source>
          ,
          <volume>34</volume>
          -
          <fpage>48</fpage>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Boucharas</surname>
          </string-name>
          , Vasilis; Jansen, Slinger; ve Brinkkemper,
          <source>Sjaak. "Formalizing software ecosystem modeling." Proceedings of the 1st international workshop on Open component ecosystems. ACM</source>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15. van den Berk, Ivo; Jansen, Slinger; ve Luinenburg, Lútzen.
          <article-title>"Software ecosystems: a software ecosystem strategy assessment model</article-title>
          .
          <source>" Proceedings of the Fourth European Conference on Software Architecture: Companion Volume. ACM</source>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>van der Schuur</surname>
          </string-name>
          , Henk; Jansen, Slinger; ve Brinkkemper,
          <article-title>Sjaak. "The power of propagation: on the role of software operation knowledge within software ecosystems</article-title>
          .
          <source>" Proceedings of the International Conference on Management of Emergent Digital EcoSystems. ACM</source>
          ,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>