<!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>Elektronik Seyir Sistemleri Yazılım Ürün Ailesi İçin Analiz ve Tasarım Süreci</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Selçuk BOZCAN</string-name>
          <email>sbozcan@aselsan.com.tr1</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Ahmet Erdinç YILMAZ</string-name>
          <email>aeyilmaz@aselsan.com.tr2</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: Yazılım Ürün Ailesi</institution>
          ,
          <addr-line>Yazılım Mimarisi, Yetenek Yönelimli Alan Analizi</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Aselsan A.Ş. SST-KKYTM</institution>
          ,
          <addr-line>P.K. 1 06172, Yenimahalle, Ankara</addr-line>
        </aff>
      </contrib-group>
      <fpage>179</fpage>
      <lpage>184</lpage>
      <abstract>
        <p>Özetçe. Yetenek yönelimli olarak modellenen bir yazılım ürün ailesindeki farklı yazılım ürünleri tarafından ortak olarak kullanılan yazılım yapıtaşlarının belirlenmesi büyük önem taşımaktadır. Yazılım yapıtaşlarının; ürün ailesine ait belirli bir fonksiyonel yeteneği gerçekler, birbirleri aralarındaki bağımlılıkların en aza indirilmiş, birbirinden bağımsız olarak geliştirilebilecek ve idame ettirilebilecek şekilde belirlenmesi, hem yazılımın ölçeklenebilirliği hem de idame edilebilirliği açısından çok önemlidir. Proje kapsamında alt yüklenicilerle çalışılması ihtiyacı doğduğunda, yazılım yapıtaşlarının belirlenmesinin önemi daha da artmaktadır. Bu çalışmada, Elektronik Seyir Sistemleri projesi kapsamında geliştirilecek yazılım ürün ailesi için, yetenek tabanlı modellemeden, alt yüklenicilere verilebilecek yazılım yapıtaşlarının belirlenmesine kadar yapılan çalışmalara değinilecek ve bu kapsamda önerilen referans yazılım sistem mimarisi sunulacaktır.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Denizcilik terminolojisinde seyir, bir gemi veya deniz aracının bir konumdan
gidilmesi istenilen diğer bir konuma emniyetle götürülmesi işi olarak tarif edilmektedir [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
Geçmişte kâğıt haritalar ve çeşitli denizcilik araçları kullanılarak gerçekleştirilen seyir
yöntemleri, artık günümüzde yerini elektronik sensör ve sistemlerin kullanıldığı
elektronik seyre bırakmıştır. Elektronik Seyir Sistemi (ESS), gemi üzerindeki çeşitli
sensörlerden aldığı verileri kullanarak oluşturduğu durum bilgisi üzerinden sürekli olarak
tehlikeli durum analizi yapar ve bunu sergiler.
      </p>
      <p>Farklı büyüklük ve nitelikteki gemiler, farklı özellikleri ön plana çıkan ESS’lere
ihtiyaç duymaktadırlar. Bu nedenle günümüzde, ESS olarak isimlendirilen ürün ailesinin
içerisinde, farklı yeteneklerin ön plana çıktığı ürünler yer almaktadır. Örneğin; büyük
gemilerde daha büyük ekranlı ve çok daha fazla sensör bilgisinin sergilendiği ESS’ler
kullanılırken, daha küçük gemilerde ise daha az yeteneği barındıran ESS’ler tercih
edilmektedir. İlave olarak, askeri gemiler ve denizaltılarda ise askeri deniz haritalarının
görüntülenmesi, su altına özel seyir tekniklerinin uygulanması gibi daha farklı
yeteneklere sahip ESS’ler kullanılmaktadır.</p>
      <p>
        ASELSAN’da sürmekte olan ESS Projesi kapsamında farklı nitelikte su üstü ve su
altı platformlarda kullanılmak üzere çeşitli yeteneklerde ESS’lerin bir ürün ailesi olarak
geliştirilmesi planlanmıştır. Proje kapsamında geliştirilecek olan ve aynı yazılım ürün
ailesi [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] kapsamında yer alan ESS yazılımlarının geliştirilmesi için yetenek yönelimli
alan analizi [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] yöntemi tercih edilmiştir.
      </p>
      <p>Proje kapsamında öncelikle, ESS ürün ailesinde farklılaşan yeteneklerin
belirlenmesi için, yetenek yönelimli alan analizi yöntemi kullanılarak sistem seviyesi
gereksinim analizi gerçekleştirilmiştir. Ardından, proje kapsamında önemli ölçüde yazılım alt
yüklenicisinin de kullanılacağı göz önünde bulundurularak, farklı yeteneklerin
birbirinden bağımsız olarak geliştirilebilmesini sağlayan bir sistem tasarımı
gerçekleştirilmiş ve ortaya bir Referans Sistem Yazılım Mimarisi (RSYM) konulmuştur. Ortaya
konulan bu RSYM’nin doğrulanması amacıyla bir konsept uygulama sistem tasarımı
aşamasında geliştirilmiştir. Sonrasında, ayrıntılı senaryolar ve kullanıcı arayüzü taslakları
hazırlanarak yazılım gereksinim analizi aşaması tamamlanmıştır. Son olarak da, ortaya
konan RSYM’ye uygun olarak yazılım tasarımı gerçekleştirilmiştir.</p>
      <p>Bu makalede, ESS projesi kapsamında sistem gereksinimlerinin belirlenmesinden
yazılım tasarımının gerçekleştirilmesine kadar geçen süreçte izlenen yöntem ve
edinilen tecrübeler aktarılmaktadır.
2</p>
      <p>Yapılan Çalışma</p>
      <p>ESS Ürün Ailesi Projesi kapsamında gerçekleştirilen tüm analiz ve tasarım süreci
Şekil 1’de verilmiştir. Aşağıda sürecin her adımında gerçekleştirilen faaliyetler detaylı
olarak açıklanmaktadır.</p>
      <p>Şekil 1. Analiz ve Tasarım Süreci
2.1</p>
    </sec>
    <sec id="sec-2">
      <title>Sistem Analizi</title>
      <p>ESS alanında, farklı üreticiler tarafından geliştirilen ürünler arasında belirli bir
standardı sağlamak amacıyla, IMO (International Maritime Organization) ve IHO
(International Hydrographic Organization) gibi kuruluşlar tarafından yayınlanan standartlar
bulunmaktadır. Bu standartlarda, ESS alanında yer alan ürünlerin temel işlevlerini ve
sağlaması gereken temel özellikleri tariflenmektedir.</p>
      <p>Sistem analizi aşamasına bu alandaki mevcut standartlar incelenerek başlanmıştır.
Standartlar incelenerek alan bilgisinin edinilmesi sonrasında bu alanda yer alan
ürünlerin hangi yeteneklere sahip olacağını tarifleyen sistem seviyesi senaryolar
hazırlanmıştır. Hazırlanan bu senaryolar, sistem gereklerinin hazırlanmasına temel teşkil etmiştir.</p>
      <p>
        Sistem seviyesi senaryolar ile beraber bu alandaki ürünlerin yeteneklerini kapsayan
bir yetenek ağacı [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] hazırlanmıştır. ESS Projesi kapsamında farklı nitelikteki gemilerin
ihtiyaçlarını karşılamak adına belirlenen ürünler için yetenek ağacından farklı yetenek
kümeleri seçilerek bu ürünlerin yapılandırmaları oluşturulmuştur. Şekil 2’de yetenek
ağacından farklı ürün yapılandırmalarının oluşturulması örneklenmektedir.
      </p>
      <p>Şekil 2. Yetenek Ağacı ve Farklı Ürün Yapılandırmaları</p>
      <p>Sistem analizi aşamasında hazırlanan sistem seviyesi senaryolar ve yetenek ağacı
kullanılarak proje kapsamında geliştirilecek olan her bir ürün için sistem gereksinimleri
hazırlanmıştır.
2.2</p>
    </sec>
    <sec id="sec-3">
      <title>Sistem Tasarımı</title>
      <p>Sistem analizi aşamasından sonra ASELSAN süreçlerine uygun olarak sistem
tasarımı aşamasına geçilmiştir. Bu aşamada gerçekleştirilen çalışmalar sırasıyla aşağıdaki
alt başlıklarda verilmiştir:
RSYM’nin Belirlenmesi. Ürün ailesi yetenek ağacındaki yeteneklerin yazılım
konfigürasyon birimlerine eşlenmesi ve sonradan belirlenecek yeni yeteneklerin sisteme
nasıl ekleneceğinin ortaya konması amacıyla bir RSYM belirlenmiştir. Proje kapsamında
önemli ölçüde yazılım alt yüklenici işçiliğinin kullanılması planlandığından, RSYM
belirlenirken aşağıdaki kıstaslar göz önünde bulundurulmuştur:
1. Ürünlerin yetenekleri birbirinden bağımsız olarak geliştirilebilmelidir.
2. Ürünlere kolaylıkla yeni yetenek eklenebilmeli veya var olan bir yetenek
çıkartılabilmelidir.
3. Ürünün idame sürecinde alt yüklenici bağımlılığı en az seviyede olmalıdır.</p>
      <p>Ortaya konan RSYM’de ürünler, yapıtaşı adı verilen yazılım birimlerinden
oluşmaktadır. Yapıtaşı, bir veya daha fazla yeteneği sunan, birbirinden bağımsız yazılım
birimleridir. RSYM’de sundukları yeteneklere göre özelleşmiş (İş, Grafiksel Kullanıcı
Arayüzü (GKA), Taktik Resim (TR) vb.) yapıtaşları tanımlanmıştır. ESS Ürün Ailesi için
ortaya konan RSYM Şekil 3’te verilmiştir.</p>
      <p>Şekil 3. Referans Sistem Yazılım Mimarisi</p>
      <p>ESS RSYM’de yer alan yapıtaşı tipleri aşağıda verildiği gibidir:
• Model: Yapıtaşları arasında değişilecek olan ESS alanına özgü veri tanımlamalarını
içeren altyapı yapıtaşıdır.
• Çatı: Yapıtaşlarının çalışma ortamını oluşturan ve yapıtaşlarının birbirleri ile
iletişimini sağlayan altyapı yapıtaşıdır.
• TR-A: TR Ana Yapıtaşı, taktik resmin oluşturulmasını ve görüntülenmesini
sağlayan Coğrafi Bilgi Sistemi (CBS) altyapısını içeren yapıtaşıdır.
• TR-PRC: TR Parça Yapıtaşları, TR-A yapıtaşına eklenerek, farklı CBS içeriklerinin</p>
      <p>TR üzerinde görüntülenmesini sağlayan yapıtaşlarıdır.
• GKA-A: GKA Ana Yapıtaşı, GKA altyapısını içeren yapıtaşıdır.
• GKA-PRC: GKA Parça yapıtaşları, GKA-A yapıtaşına eklenerek, farklı GKA
öğelerinin görüntülenmesini sağlayan yapıtaşlarıdır.
• SY-A: Sensör Yönetimi Ana Yapıtaşı, sensör altyapılarını oluşturan yapıtaşıdır.
• SY-PRC: SY Parça Yapıtaşı, SY-A Yapıtaşına eklenerek, farklı iletişim
protokollerine sahip sensörler ile iletişim kurulabilmesini sağlayan yapıtaşlarıdır.
• VK-A: Veri Kayıt Ana Yapıtaşı, veri kayıt altyapısını içeren yapıtaşıdır.
• VK-PRC: VK Parça Yapıtaşları, VK-A yapıtaşına eklenerek, farklı verilerin
istenilen şekilde kayıt edilmesini sağlayan yapıtaşlarıdır.
• IS: İş Yapıtaşları, iş mantıklarını ve algoritmaları içeren yapıtaşlarıdır.
• DELTA: Ürün Ailesi kapsamında tanımlanan ürünün yapıtaşı yapılandırmasıdır.
Konsept Uygulamanın Geliştirilmesi. ESS Ürün Ailesi için bir RSYM
tanımlandıktan sonra, bu mimarinin gerçeklenebilirliğinin doğrulanabilmesi için bir konsept
uygulama tanımlanmış ve geliştirilmiştir. Konsept uygulamanın geliştirilmesi esnasında ise
RSYM ile ilgili teknik sorunlar adreslenmiş ve bu sorunlara çözümler aranmıştır.</p>
    </sec>
    <sec id="sec-4">
      <title>RSYM’ye Uygun Yapıtaşı Listesinin Belirlenmesi. Sistem analizi aşamasında belir</title>
      <p>lenen sistem yetenekleri esas alınarak, RSYM’ye uygun yapıtaşları belirlenmiştir.
Yapıtaşlarının belirlenmesi için gerçekleştirilen bu ilk çalışmada 80 kadar yapıtaşı
belirlenmiştir. İlerleyen aşamalarda gerçekleştirilen çalışmalarla ortaya konan bu ilk
yapıtaşı listesi güncellenmiş ve yapıtaşı sayısı 60’a indirilmiştir.</p>
      <p>
        Senaryoların Ayrıntılandırılması. Sistem analizi aşamasında hazırlanan sistem
seviyesi senaryolar, RSYM’nin ortaya konmasından sonra bu aşamada detaylandırılmıştır.
Sistem seviyesi senaryolar için herhangi bir şablon kullanılmamışken, sistem tasarımı
seviyesi senaryoların detaylandırılması aşamasında bir senaryo şablonuna ihtiyaç
duyulduğu anlaşılmış ve bir senaryo şablonu hazırlanmıştır. Kullanım durumu
senaryolarının dokümante yöntemi ile ilgili bilgi [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]’te mevcuttur.
      </p>
      <p>Yazılım analizi aşamasında hazırlanacak olan yazılım gereklerinin kolaylıkla
belirlenebilmesi için bu aşamada ayrıntılı senaryolar yazılım yapıtaşları detaylarını içerecek
şekilde yazılmıştır. Uygulanan bu senaryo yazım yöntemi, sistem tasarımı aşamasını
uzatmasına rağmen, yazılım gereksinimlerinin daha kolay belirlenmesini sağlamış ve
toplam analiz ve tasarım sürecini kısaltmıştır.</p>
      <p>Senaryo ayrıntılandırma aşamasında senaryoların anlaşılırlığının artırılması için
senaryolarla birlikte kullanıcı arayüzü taslakları da hazırlanmıştır. Kullanıcı arayüzü
taslakları, senaryoların daha iyi anlaşılmasında önemli rol oynamaktadır. Bu aşamada
gerek hız kazanmak, gerekse detaylı kullanıcı arayüzü taslaklarına henüz ihtiyaç
olmaması sebebiyle, kullanıcı arayüzü taslakları kâğıt ve kalem kullanılarak hazırlanmıştır.</p>
      <p>Sistem tasarımı aşamasında operasyonel ve operasyonel olmayan yetenekler ile
ilişkili toplam 370 ayrıntılı senaryo hazırlanmıştır. Ayrıntılı senaryoların ve beraberinde
kullanıcı arayüzü taslaklarının hazırlanması ile sistem gereksinimlerin netleşmesi
sağlanmıştır. Bu nedenle, sistem analizi aşamasında hazırlanan gereksinimler ve belirlenen
yapıtaşları bu aşamada güncellenmiştir.
2.3</p>
    </sec>
    <sec id="sec-5">
      <title>Yazılım Analizi</title>
      <p>Sistem tasarımı aşamasından sonra ASELSAN süreçlerine uygun olarak yazılım
analizi aşamasına geçilmiştir. Bu aşamada, sistem tasarımı aşamasında hazırlanan
ayrıntılı senaryolar kullanılarak her bir yapıtaşı için gereksinimler belirlenmiştir.</p>
      <p>Sistem tasarımı aşamasında hazırlanan taslak grafiksel kullanıcı arayüzleri, bu
aşamada ayrıntılandırılmıştır. Taslak kullanıcı arayüzlerinin hazırlanmasında kâğıt ve
kalem kullanılmasına karşın, detaylı kullanıcı arayüzlerinin hazırlanması için çizim
uygulamaları kullanılmıştır. Bu aşamada detaylı kullanıcı arayüzlerinin hazırlanması
gereksinimlerin netleştirilmesine önemli katkı sağlamıştır.</p>
      <p>Sistem tasarımı aşamasında hazırlanan 370 detaylı senaryodan toplamda 3500
yazılım gereksinimi hazırlanmıştır.</p>
      <p>Yazılım tasarımı aşamasında, yazılım analizi aşamasında ortaya konan yazılım
gerekleri ve detaylı kullanıcı arayüzü taslakları esas alınarak, RSYM’ye uygun bir yazılım
tasarımı hazırlanmıştır. Bu aşamada, RSYM’nin doğrulanması için sistem tasarımı
aşamasında geliştirilen konsept uygulamadan önemli faydalar elde edilmiştir. Konsept
uygulamanın geliştirilmesi esnasında teknik sorunlara üretilen çözümler, yazılım
tasarımının ortaya konulmasında dikkate alınmıştır.</p>
      <p>Bu aşamada, yazılım analizi aşamasında hazırlanan detaylı kullanıcı arayüzü
taslaklarının üzerinden geçilmiş ve güncellemeler gerçekleştirilmiştir. Bu güncellemeler
sonrasında ayrıntılı senaryolar da uygun şekilde güncellenmiştir.
3</p>
      <p>Değerlendirme</p>
      <p>ESS ürün ailesi için izlenen analiz ve tasarım sürecinde, yukarıda anlatılan
çalışmalar gerçekleştirilmiştir. Proje yönetimi tarafından belirlenen 3 muhtemel ürün için bir
yetenek ağacı hazırlanmış, ardından bu yetenekler doğrultusunda sistem seviyesi
senaryolar hazırlanmıştır. Sonrasında gerçekleştirilen analiz ve tasarım çalışmalarında
toplam 370 ayrıntılı senaryo ve detaylı kullanıcı arayüzü taslağı ve bunlara karşılık olarak
toplam 3500 yazılım gereksinimi hazırlanmıştır.</p>
      <p>Analiz ve tasarım sürecinde yetenek modelleme, RSYM belirleme ve doğrulama,
senaryo ve kullanıcı arayüzü taslakları hazırlama yöntemlerinin kullanımı ile analiz ve
tasarım süreçlerini daha etkin kılıp, alt yüklenici ile çalışmalardaki riskler azaltılmaya
çalışılmıştır. Bu yöntemlerin kullanımı hem gereksinimlerin yeterli ayrıntıda
oluşturulmasını mümkün kılmış, hem de alt yükleniciyi yönlendirecek teknik altyapıların
oluşturulmasını da sağlamıştır.</p>
      <p>ESS Projesinde uygulanan yukarıda bahsedilen analiz ve tasarım sürecinin gerek
gereksinimlerin belirlenmesinde gerekse yazılım tasarımının ortaya konmasında faydalar
sağladığı görülmüştür. ESS alanı için ortaya konan RSYM benzer diğer alanlar için de
uyumlandırılarak bu alanlardaki projeler için de kullanılmaya başlanmıştır.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Aytaç</surname>
          </string-name>
          , Turgay. SGK Denizci Dili Sözlüğü. [Çevrimiçi]
          <year>2016</year>
          . http://www.sgk.tsk.tr/baskanliklar/istihbarat/denizci_dili/dd/denizcidili.htm.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Clements</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Northrop</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          <string-name>
            <surname>Software Product</surname>
          </string-name>
          <article-title>Lines: Practices and Patterns</article-title>
          . Upper Saddle River, NJ :
          <string-name>
            <surname>Addison-Wesley</surname>
          </string-name>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Kang</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cohen</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hess</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nowak</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Peterson</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <string-name>
            <surname>Feature-Oriented Domain Analysis (FODA) Feasibility</surname>
            <given-names>Study</given-names>
          </string-name>
          ,
          <source>Technical Report CMU/SEI-90-TR-21</source>
          , Pittsburgh, PA, Software Engineering Institute, Carnegie Mellon Üniversitesi (
          <year>1990</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Riebisch</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Towards a more precise definition of feature models</article-title>
          . In: Riebisch,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Coplien</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.O.</given-names>
            ,
            <surname>Streitferdt</surname>
          </string-name>
          ,
          <string-name>
            <surname>D</surname>
          </string-name>
          . (eds.)
          <source>ECOOP</source>
          <year>2003</year>
          ,
          <article-title>LNCS</article-title>
          , vol.
          <volume>2743</volume>
          , s.
          <fpage>64</fpage>
          -
          <lpage>76</lpage>
          . Springer, Heidelberg (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Schneider</surname>
          </string-name>
          , Geri ve Winters, Jason P.
          <article-title>Applying Use Cases: A Practical Guide</article-title>
          . Michigan Ünversitesi:
          <string-name>
            <surname>Addison-Wesley</surname>
          </string-name>
          ,
          <year>2001</year>
          , s.
          <fpage>111</fpage>
          -
          <lpage>159</lpage>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>